From uwe at hermann-uwe.de Fri Sep 1 00:11:35 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 1 Sep 2006 00:11:35 +0200 Subject: [LinuxBIOS] IT8718F support. In-Reply-To: <44F6247B.6080008@gmx.net> References: <20060829162747.GA25404@aragorn> <44F47D8B.7060707@onelabs.com> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <20060830122414.GB28991@aragorn> <20060830151437.GB28321@coresystems.de> <44F5BA1F.2060204@gmx.net> <20060830183857.GB16201@coresystems.de> <44F6247B.6080008@gmx.net> Message-ID: <20060831221135.GB6142@aragorn> On Thu, Aug 31, 2006 at 01:51:23AM +0200, Carl-Daniel Hailfinger wrote: > That's the question. Do we want to continue supporting highly expensive > boards like Tyan where hardly anyone will sacrifice a system to LinuxBIOS > testing or do we want to reach the masses. Ideally, both. I guess the corporate contributors will continue to (mainly) support boards they have use-cases for (which makes sense from an economical point of view). For cheap, old, or mainstream boards you can buy in your favorite computer shop, ebay etc. random interested contributors/coders are important, IMHO. Given enough such contributors and enough popularity of the project among hacker-type Free Software users/programmers it won't take too long to have support for a good bunch of popular boards. > I'm for supporting slightly outdated systems (like AMD Socket 754/939) > and against putting any effort into the latest and greatest. ACK. Although I don't think putting effort into "the latest and greatest" is a problem, it's just that the older stuff should be worked on, too. Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Fri Sep 1 00:24:38 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 1 Sep 2006 00:24:38 +0200 Subject: [LinuxBIOS] IT8718F support. In-Reply-To: <20060830151015.GA28321@coresystems.de> References: <20060829162747.GA25404@aragorn> <44F47D8B.7060707@onelabs.com> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060830151015.GA28321@coresystems.de> Message-ID: <20060831222438.GC6142@aragorn> On Wed, Aug 30, 2006 at 05:10:15PM +0200, Stefan Reinauer wrote: > Supporting all of them for the sake of it makes no sense, by your leave. > SuperIO chips alone dont do the deed. if we manage to get a > "coordinated effort", i'd much rather go and support "80% of the common > superio chips out there" with in the end 50% of the effort and instead > try to get some more southbridge/northbridge combinations supported with > this effort. Sure, that's important as well. But Super IOs are (comparatively) easy to understand and support, and the amount of code needed is small, so we can add support for many of them quite fast... > I completely agree. The key to success here is, in my opinion, to > provide ready-built and tested images on an automated base for certain > hardware. I fully agree. > Unlike normal userspace programs or even kernels, recovering from a bad > bios can be quite some work. How do we overcome this? Not everyone is > going to buy a galep iv for 400$, nor a bios savior for 30. Here's what I did: I created a backup BIOS image of the BIOS on my test machine; then I got a few chips of the same size/type. I wrote the original image to 1-2 of the chips (all with Uniflash), so I had 3 identical, working proprietary BIOS chips (just in case) and put them in a drawer. Of course, I tested them all. So from now on I can easily just write/overwrite all other chips, because I always have a few backup chips I can use if something goes wrong. Mabye a "How to recover" section in the wiki would be nice... > > 3) Create pressure on those companies which do not give out datasheets > > for various hardware parts. This is much easier if 1) is successful > > and many people/customers demand LinuxBIOS support. > > what do you mean by pressure? Peaceful, non-violent pressure, of course ;-) The "damn, today there were another 14 customers calling our help-desk and asking for LinuxBIOS support, maybe we should give out specs, after all"-type of pressure. Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From stepan at coresystems.de Fri Sep 1 01:20:50 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 1 Sep 2006 01:20:50 +0200 Subject: [LinuxBIOS] IT8718F support. In-Reply-To: <20060831221135.GB6142@aragorn> References: <20060829162747.GA25404@aragorn> <44F47D8B.7060707@onelabs.com> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <20060830122414.GB28991@aragorn> <20060830151437.GB28321@coresystems.de> <44F5BA1F.2060204@gmx.net> <20060830183857.GB16201@coresystems.de> <44F6247B.6080008@gmx.net> <20060831221135.GB6142@aragorn> Message-ID: <20060831232050.GA3099@coresystems.de> * Uwe Hermann [060901 00:11]: > Ideally, both. I guess the corporate contributors will continue to > (mainly) support boards they have use-cases for (which makes sense from an > economical point of view). > > For cheap, old, or mainstream boards you can buy in your favorite > computer shop, ebay etc. random interested contributors/coders are > important, IMHO. Given enough such contributors and enough popularity of > the project among hacker-type Free Software users/programmers it won't > take too long to have support for a good bunch of popular boards. time is playing with us. The north and south bridges that are expensive, fast and modern today will be old and cheap tomorrow, so when K8 et al see a successor, we might automatically our potential userbase might automatically become broader. Notice that at the moment on K8 all server chipsets are supported but none of the consumer chipsets (Via, ATI, some NVidia hw). > ACK. Although I don't think putting effort into "the latest and greatest" > is a problem, it's just that the older stuff should be worked on, too. In the old Amiga games scene there is a concept called abandonware. If the technology does not make a "unique selling point" for the vendor anymore, it is released to the public for the sake of the community. Is this a concept that hw vendors on this list could life with? Regards, Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Fri Sep 1 01:22:40 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 1 Sep 2006 01:22:40 +0200 Subject: [LinuxBIOS] flashrom, uniflash. In-Reply-To: <20060831215532.GA6142@aragorn> References: <20060829162747.GA25404@aragorn> <44F47D8B.7060707@onelabs.com> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060830151015.GA28321@coresystems.de> <44F5AEA8.1020204@gmx.net> <20060830175454.GA16201@coresystems.de> <20060831215532.GA6142@aragorn> Message-ID: <20060831232240.GB3099@coresystems.de> * Uwe Hermann [060831 23:55]: > Another important issue is that flashrom should support many, many chips > and baords, as few people will be willing to buy expensive hardware just > for flashing. > There's Uniflash, but that has the problem of being Pascal+DOS, > currently. I tried for a few minutes to build it with GNU Pascal or > FreePascal, but that didn't work easily (needs more work, maybe). > Has anybody else managed to build it for Linux? Uniflash works so well because it does 16bit bios calls itself. I am not sure we want to do this. Maybe we do? Maybe with x86emu? Ollie? Ron? 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 uwe at hermann-uwe.de Fri Sep 1 01:24:05 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 1 Sep 2006 01:24:05 +0200 Subject: [LinuxBIOS] License clarification, round 1 In-Reply-To: <20060829163331.GA23377@coresystems.de> References: <20060829101600.GE6649@aragorn> <20060829163331.GA23377@coresystems.de> Message-ID: <20060831232405.GD6142@aragorn> Hi, On Tue, Aug 29, 2006 at 06:33:31PM +0200, Stefan Reinauer wrote: > The answer here is easy. Every line of LinuxBIOS code is GPL. And > every line of code we will include in the future will become GPL by the > implicit agreement of the contributor to use LinuxBIOS and to enhance > it. I agree, _if_ the code is contributed willingly and knowingly by the third-party, _and_ that fact is documented in the file (by adding a copyright line and the GPL license header). It's an entirely different situation if the code was taken from some other project, in which case it's not necessarily GPL'd. > This is why we have been doing code reviews and have been in close > contact with the contributors to make sure we do not include otherwise > licensed or protected code. That's great to hear! > All of them are GPLed, as a consequence of the inclusion in LinuxBIOS. > Also, files do not need a header stating their license, as the license > is absolutely obvious to everyone downloading the code. Yes and no. The license of the project might be obvious, but I've come over many GPL'd projects which are not actually 100% GPL'd even if they say so. Many contained files from some other sources which were copied in the code-base and had no proper license, or a non-free one... It's very important in my opinion that every file states the exact year, copyright owner, and license of the code. * Year, because this may become relevant in jurisdictions which have laws that (for example) code becomes public domain after X years etc. * Copyright owner, so that everyone knows whom to contact in case of legal questions, license questions etc. etc. * License, so that it's clear under which license terms the file may be distributed. Even for the "normal case" of the GPL this is important, as it makes a difference whether the respective contributor licensed his code under the terms of the "GPL, version 2 (or any later version)" or "GPL, version 2" (or version 1, or version 3 in future). AFAIK "GPL, version 2 (or any later version)" and "GPL, version 2" are compatible, but version 2 and 3 might not be, for example... I've seen both variants (v2, and v2 or later) in the code, so maybe that should be standardized (by asking all contributors of one variant if they agree to relicensing their code to the other variant). Maybe some FSF people on this list can comment on this issue. > > I noticed that many files do not have any license header at all (some don't > > even say who the author is); such files have an unclear status and must be > > considered non-free usually, so in cases where that's just an oversight, > > please add a respective license note. > > No they must not. Who would say they must? Legally absolutely obvious > that the files have been checked by those with checkin capabilities to > be free. The problem is that no license header means you cannot be sure whether the file is GPL'd or was simply copied from some other project and didn't have a license header there either, or the header was removed when copying the file (which is always a bad idea). Therefore I think it's a lot better to add a license note to _all_ source code files, just to make things perfectly clear and to prevent guess-work and having to ask around, or search svn commit logs or mailinglists just to find out which license applies. > > If the file was taken from another > > project, please add a note saying so, and mention the license of that project > > in the file. > > As we are using GPL as the license, only files with GPL license or with > licenses compatible to the GPL license have been included. All files in > the repository are licensed under the GPL. No exceptions. Well, except for the ones which say something different, of course. Say there was a BSD-licensed file in the repository (I don't know if there really is one). That file will remain BSD-licensed, of course, no matter what the license of the LinuxBIOS project is. It's just the fact that the (revised) BSD license is GPL-compatible that would make it possible to use the code in LinuxBIOS. But it would still be BSD-licensed. > > The biggest problems I notices so far is the code from IBM and AMD, which says > > things like "Copyright 2005 ADVANCED MICRO DEVICES, INC. All Rights Reserved" > > There is no problem with this. The fact that AMD released these files to > the public as GPL does not touch the fact that they own a copyright to > it. In fact, in Europe signing over copyrights is impossible as of > current law, so these notes are just fine. That's entirely correct. Copyright is a different concept from a license, and in Germany (maybe other parts of Europe) you cannot re-assign copyright ("Urheberrecht", actually) to other people. It's perfectly fine that AMD has the copyright, as long as the code is licensed under the terms of the GPL. It's the "All Rights Reserved" that makes me nervous. If that would read "This file is licensed under the GPL" (or better just the usual GPL header was there), everything would be fine. The current text in there is at least confusing, maybe even worse. It simply doesn't state _any_ license which applies to the code. > > or stuff like: > > > LICENSED MATERIAL - PROGRAM PROPERTY OF I B M > > > That alone (which no additional "this is GPL'd" text would make the > > code non-free and GPL-incompatible, I guess. I hope this can be > > resolved or clarified somehow. > > I would not see a legal regulation to back your assumption. The fact > that it is "licensed" does not make it non-free. the license is GPL, > because IBM acknowledged making it GPL by contributing to a GPL project. If that's the case, great! Then it's just a matter of making this clear in the file. The text as it is right now, is confusing and doesn't state that the code is GPL'd. It rather sounds very restrictive and from reading just that text, I'd have severe doubts whether I can legally include it in a GPL'd project. > > src/arch/i386/boot/acpi.c: > > "Copyright 2005 ADVANCED MICRO DEVICES, INC. All Rights Reserved." > > which is bad as it means it's NOT GPL'd and you cannot use it for anything > > where does it say that it is not GPL? Could not find the paragraph you > are talking about. It doesn't state _that_ it's GPL'd, which is should. > So unless we have an indication stating something different I suggest > what we do is emphasize that the whole of LinuxBIOS is GPL licensed by > the respective copyright holders. Sure, that should definately be done (for example in a README file). It should say which license applies to the code written explicitly for LinuxBIOS, and that some parts (taken from other projects) may have different (but GPL-compatible) licenses. It should also state very clearly whether the code is licensed under the "GPL, version 2 (or any later version)" or "GPL, version 2". > To make things clearer, I also suggest removing license descriptions > from every single source file in the tree and only have a single license > file stating the only valid project license. Please don't. I'm pretty sure single files will some day be copied and incorporated into other GPL projects, therefore it's important to have the copyright and license lines in each file. I'd rather do the opposite - add a license header to all files which don't yet have one. Disk space is cheap, and legal clarity should be more important than a slightly larger code base. If you absolutely must, I'd rather use something short, e.g. Copyright 200x John Doe This code is licensed under the GPL, version 2 (or any later version) than no license header at all. HTH, Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From stepan at coresystems.de Fri Sep 1 01:25:26 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 1 Sep 2006 01:25:26 +0200 Subject: [LinuxBIOS] flashrom, uniflash. In-Reply-To: <20060831215532.GA6142@aragorn> References: <20060829162747.GA25404@aragorn> <44F47D8B.7060707@onelabs.com> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060830151015.GA28321@coresystems.de> <44F5AEA8.1020204@gmx.net> <20060830175454.GA16201@coresystems.de> <20060831215532.GA6142@aragorn> Message-ID: <20060831232525.GC3099@coresystems.de> * Uwe Hermann [060831 23:55]: > Another important issue is that flashrom should support many, many chips > and baords, as few people will be willing to buy expensive hardware just > for flashing. > > There's Uniflash, but that has the problem of being Pascal+DOS, > currently. I tried for a few minutes to build it with GNU Pascal or > FreePascal, but that didn't work easily (needs more work, maybe). > Has anybody else managed to build it for Linux? And then there's /dev/bios. It supports quite a lot of hardware and it talks to the hardware in a smarter way than most flash drivers in "flashrom". This is why I still get regular mails for the driver. But it should be all integrated in flashrom, its architecture is a lot more sane. (And it does not need to recompile the software for every kernel update :-/) Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Fri Sep 1 01:30:13 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 1 Sep 2006 01:30:13 +0200 Subject: [LinuxBIOS] IT8718F support. In-Reply-To: <20060831222438.GC6142@aragorn> References: <20060829162747.GA25404@aragorn> <44F47D8B.7060707@onelabs.com> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060830151015.GA28321@coresystems.de> <20060831222438.GC6142@aragorn> Message-ID: <20060831233013.GD3099@coresystems.de> * Uwe Hermann [060901 00:24]: > > what do you mean by pressure? > > Peaceful, non-violent pressure, of course ;-) > > The "damn, today there were another 14 customers calling our help-desk > and asking for LinuxBIOS support, maybe we should give out specs, after > all"-type of pressure. Usually if you come with a big enough number, they will open the specs. From c-d.hailfinger.devel.2006 at gmx.net Fri Sep 1 02:07:29 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 01 Sep 2006 02:07:29 +0200 Subject: [LinuxBIOS] flashrom, uniflash. In-Reply-To: <20060831232240.GB3099@coresystems.de> References: <20060829162747.GA25404@aragorn> <44F47D8B.7060707@onelabs.com> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060830151015.GA28321@coresystems.de> <44F5AEA8.1020204@gmx.net> <20060830175454.GA16201@coresystems.de> <20060831215532.GA6142@aragorn> <20060831232240.GB3099@coresystems.de> Message-ID: <44F779C1.3020205@gmx.net> Stefan Reinauer wrote: > * Uwe Hermann [060831 23:55]: >> Another important issue is that flashrom should support many, many chips >> and baords, as few people will be willing to buy expensive hardware just >> for flashing. > >> There's Uniflash, but that has the problem of being Pascal+DOS, >> currently. I tried for a few minutes to build it with GNU Pascal or >> FreePascal, but that didn't work easily (needs more work, maybe). >> Has anybody else managed to build it for Linux? > > Uniflash works so well because it does 16bit bios calls itself. I am not > sure we want to do this. Maybe we do? Maybe with x86emu? Ollie? Ron? Most PC BIOSes have a flash program in ROM, so x86emu won't help us much. The 16bit BIOS calls are just calls to that flash program. I know for sure that all recent Asus boards have awdflash or similar in their ROM image. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Fri Sep 1 02:11:01 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 01 Sep 2006 02:11:01 +0200 Subject: [LinuxBIOS] flashrom, uniflash. In-Reply-To: <20060831232525.GC3099@coresystems.de> References: <20060829162747.GA25404@aragorn> <44F47D8B.7060707@onelabs.com> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060830151015.GA28321@coresystems.de> <44F5AEA8.1020204@gmx.net> <20060830175454.GA16201@coresystems.de> <20060831215532.GA6142@aragorn> <20060831232525.GC3099@coresystems.de> Message-ID: <44F77A95.6010903@gmx.net> Stefan Reinauer wrote: > > And then there's /dev/bios. It supports quite a lot of hardware > and it talks to the hardware in a smarter way than most flash drivers > in "flashrom". This is why I still get regular mails for the driver. > > But it should be all integrated in flashrom, its architecture is a lot > more sane. Oh. I had assumed flashrom was the successor of /dev/bios and other flashing tools. Porting the code from /dev/bios to flashrom will probably be a lot easier than trying to find out what uniflash does. Stefan, do you have any plans in that direction? Regards, Carl-Daniel From stepan at coresystems.de Fri Sep 1 02:52:52 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 1 Sep 2006 02:52:52 +0200 Subject: [LinuxBIOS] flashrom, uniflash. In-Reply-To: <44F779C1.3020205@gmx.net> References: <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060830151015.GA28321@coresystems.de> <44F5AEA8.1020204@gmx.net> <20060830175454.GA16201@coresystems.de> <20060831215532.GA6142@aragorn> <20060831232240.GB3099@coresystems.de> <44F779C1.3020205@gmx.net> Message-ID: <20060901005252.GA10189@coresystems.de> * Carl-Daniel Hailfinger [060901 02:07]: > Most PC BIOSes have a flash program in ROM, so x86emu won't help us > much. The 16bit BIOS calls are just calls to that flash program. Except Asus: Not really a flash program but functions to enable / disable write protection of the bios chips and address spaces. There's an AWDFLASH structure that points into this. I reverse engineered this many years ago until I found out that I want to support hardware that is supported by its vendor. > I know for sure that all recent Asus boards have awdflash or similar > in their ROM image. Thats definitely not what the user land bios flashers like uniflash use. it seems they want to get rid of bios updates while the os is running completely. Not dumb, really. 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 uwe at hermann-uwe.de Fri Sep 1 13:42:46 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 1 Sep 2006 13:42:46 +0200 Subject: [LinuxBIOS] PATCH: flashrom support for all ICH chipsets. Message-ID: <20060901114246.GA16214@aragorn> Hi, I've added support in flashrom for all ICH chipsets (maybe I missed one or two; if so, please tell me). Tested on real hardware: ICH2, ICH6-M (the rest is untested). HTH, Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org -------------- next part -------------- Index: util/flashrom/flash_enable.c =================================================================== --- util/flashrom/flash_enable.c (Revision 2394) +++ util/flashrom/flash_enable.c (Arbeitskopie) @@ -3,6 +3,7 @@ * * Copyright (C) 2000-2004 ??? * Copyright (C) 2005 coresystems GmbH + * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -101,20 +102,16 @@ return 0; } -enum { - ICH4_BIOS_CNTL = 0x4e, - /* see page 375 of "Intel ICH7 External Design Specification" - * http://download.intel.com/design/chipsets/datashts/30701302.pdf */ - ICH7_BIOS_CNTL = 0xdc, -}; static int enable_flash_ich(struct pci_dev *dev, char *name, int bios_cntl) { /* register 4e.b gets or'ed with one */ uint8_t old, new; /* 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. - */ + * that it is hard to argue that we should quit at this point. */ + /* Note: the ICH0-ICH5 BIOS_CNTL register is actually 16 bit wide, but + * just treating it as 8 bit wide seems to work fine in practice. */ + old = pci_read_byte(dev, bios_cntl); new = old | 1; @@ -132,14 +129,14 @@ return 0; } -static int enable_flash_ich4(struct pci_dev *dev, char *name) +static int enable_flash_ich_4e(struct pci_dev *dev, char *name) { - return enable_flash_ich(dev, name, ICH4_BIOS_CNTL); + return enable_flash_ich(dev, name, 0x4e); } -static int enable_flash_ich7(struct pci_dev *dev, char *name) +static int enable_flash_ich_dc(struct pci_dev *dev, char *name) { - return enable_flash_ich(dev, name, ICH7_BIOS_CNTL); + return enable_flash_ich(dev, name, 0xdc); } static int enable_flash_vt8235(struct pci_dev *dev, char *name) @@ -384,10 +381,23 @@ static FLASH_ENABLE enables[] = { {0x1039, 0x0630, "sis630", enable_flash_sis630}, {0x8086, 0x2480, "E7500", enable_flash_e7500}, - {0x8086, 0x24c0, "ICH4", enable_flash_ich4}, - {0x8086, 0x24cc, "ICH4-M", enable_flash_ich4}, - {0x8086, 0x24d0, "ICH5", enable_flash_ich4}, - {0x8086, 0x27b8, "ICH7", enable_flash_ich7}, + {0x8086, 0x2410, "ICH", enable_flash_ich_4e}, + {0x8086, 0x2420, "ICH0", enable_flash_ich_4e}, + {0x8086, 0x2440, "ICH2", enable_flash_ich_4e}, + {0x8086, 0x244c, "ICH2-M", enable_flash_ich_4e}, + {0x8086, 0x2480, "ICH3-S", enable_flash_ich_4e}, + {0x8086, 0x248c, "ICH3-M", enable_flash_ich_4e}, + {0x8086, 0x24c0, "ICH4/ICH4-L", enable_flash_ich_4e}, + {0x8086, 0x24cc, "ICH4-M", enable_flash_ich_4e}, + {0x8086, 0x24d0, "ICH5/ICH5R", enable_flash_ich_4e}, + {0x8086, 0x2640, "ICH6/ICH6R", enable_flash_ich_dc}, + {0x8086, 0x2641, "ICH6-M", enable_flash_ich_dc}, + {0x8086, 0x27b8, "ICH7/ICH7R", enable_flash_ich_dc}, + {0x8086, 0x27b9, "ICH7M", enable_flash_ich_dc}, + {0x8086, 0x27bd, "ICH7MDH", enable_flash_ich_dc}, + {0x8086, 0x2810, "ICH8/ICH8R", enable_flash_ich_dc}, + {0x8086, 0x2812, "ICH8DH", enable_flash_ich_dc}, + {0x8086, 0x2814, "ICH8DO", enable_flash_ich_dc}, {0x1106, 0x8231, "VT8231", enable_flash_vt8231}, {0x1106, 0x3177, "VT8235", enable_flash_vt8235}, {0x1078, 0x0100, "CS5530", enable_flash_cs5530}, -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From jsturges at speakeasy.net Fri Sep 1 15:02:01 2006 From: jsturges at speakeasy.net (Jonathan Sturges) Date: Fri, 01 Sep 2006 09:02:01 -0400 Subject: [LinuxBIOS] Geode GX1/5530: How to forward SMI to a regular IRQ In-Reply-To: <200608091802.00104.juergen127@kreuzholzen.de> References: <200608071119.17303.juergen127@kreuzholzen.de> <200608082053.42949.juergen127@kreuzholzen.de> <1155137190.24601.14.camel@logarithm.lanl.gov> <200608091802.00104.juergen127@kreuzholzen.de> Message-ID: <44F82F49.9020104@speakeasy.net> An HTML attachment was scrubbed... URL: From bg.anil at gmail.com Fri Sep 1 16:08:45 2006 From: bg.anil at gmail.com (Anil B G) Date: Fri, 1 Sep 2006 19:38:45 +0530 Subject: [LinuxBIOS] Enabling USB 2.0 Message-ID: <8b0974ca0609010708j2cacda7cuf7562bfd9aa77267@mail.gmail.com> Hi, I am trying to enable USB on a board similar to Tyan s2892 (CK804) chipset? Is there anything that else that needs to be done separately other than setting the irqs et al correctly? Specifically do we need to write some sort of a driver to enable the USB host controller. Thanks Anil -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsturges at speakeasy.net Fri Sep 1 17:23:10 2006 From: jsturges at speakeasy.net (Jonathan Sturges) Date: Fri, 01 Sep 2006 11:23:10 -0400 Subject: [LinuxBIOS] Enabling USB 2.0 In-Reply-To: <8b0974ca0609010708j2cacda7cuf7562bfd9aa77267@mail.gmail.com> References: <8b0974ca0609010708j2cacda7cuf7562bfd9aa77267@mail.gmail.com> Message-ID: <44F8505E.6060805@speakeasy.net> Anil B G wrote: > Hi, > I am trying to enable USB on a board similar to Tyan s2892 (CK804) > chipset? > Is there anything that else that needs to be done separately other > than setting the irqs et al correctly? Specifically do we need to > write some sort of a driver to enable the USB host controller. > > Thanks > Anil Assuming you don't hope to boot from USB, all you really should need is to setup the IRQ map, AFAIK. Then the Linux kernel will detect it and be able to attach the appropriate driver. -Jonathan From bg.anil at gmail.com Fri Sep 1 17:40:01 2006 From: bg.anil at gmail.com (Anil B G) Date: Fri, 1 Sep 2006 21:10:01 +0530 Subject: [LinuxBIOS] Enabling USB 2.0 In-Reply-To: <44F8505E.6060805@speakeasy.net> References: <8b0974ca0609010708j2cacda7cuf7562bfd9aa77267@mail.gmail.com> <44F8505E.6060805@speakeasy.net> Message-ID: <8b0974ca0609010840u683c7d6em83d3b495c916324c@mail.gmail.com> Thanks. I plan to boot from SATA and not from USB. Do any other boards supported by LinuxBIOS (whose source is available in the source tree) bringup USB that I could use as a reference? On 9/1/06, Jonathan Sturges wrote: > > > > Anil B G wrote: > > > Hi, > > I am trying to enable USB on a board similar to Tyan s2892 (CK804) > > chipset? > > Is there anything that else that needs to be done separately other > > than setting the irqs et al correctly? Specifically do we need to > > write some sort of a driver to enable the USB host controller. > > > > Thanks > > Anil > > > Assuming you don't hope to boot from USB, all you really should need is > to setup the IRQ map, AFAIK. Then the Linux kernel will detect it and > be able to attach the appropriate driver. > > -Jonathan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsturges at speakeasy.net Fri Sep 1 17:50:21 2006 From: jsturges at speakeasy.net (Jonathan Sturges) Date: Fri, 01 Sep 2006 11:50:21 -0400 Subject: [LinuxBIOS] Enabling USB 2.0 In-Reply-To: <8b0974ca0609010840u683c7d6em83d3b495c916324c@mail.gmail.com> References: <8b0974ca0609010708j2cacda7cuf7562bfd9aa77267@mail.gmail.com> <44F8505E.6060805@speakeasy.net> <8b0974ca0609010840u683c7d6em83d3b495c916324c@mail.gmail.com> Message-ID: <44F856BD.40302@speakeasy.net> Probably most boards enable USB. The irq_tables.c for each mainboard has the IRQ map in it. I believe this file can be generated automatically if you boot using the stock BIOS and run the generator tool. I am working mostly on a system without a standard BIOS and am coddling this file together manually. Either way, take a look at it to get an idea of what it does. There have also been a fair number of posts related to constructing this file, so search the archives too. -Jonathan Anil B G wrote: > Thanks. I plan to boot from SATA and not from USB. Do any other > boards supported by LinuxBIOS (whose source is available in the source > tree) bringup USB that I could use as a reference? > > On 9/1/06, *Jonathan Sturges* > wrote: > > > > Anil B G wrote: > > > Hi, > > I am trying to enable USB on a board similar to Tyan s2892 > (CK804) > > chipset? > > Is there anything that else that needs to be done separately other > > than setting the irqs et al correctly? Specifically do we need to > > write some sort of a driver to enable the USB host controller. > > > > Thanks > > Anil > > > Assuming you don't hope to boot from USB, all you really should > need is > to setup the IRQ map, AFAIK. Then the Linux kernel will detect it and > be able to attach the appropriate driver. > > -Jonathan > > From yinghai.lu at amd.com Fri Sep 1 18:27:13 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 1 Sep 2006 09:27:13 -0700 Subject: [LinuxBIOS] Enabling USB 2.0 Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42070041EA@ssvlexmb2.amd.com> You can not boot from sata on ck804, the reason is that the sata controller can not work on compatible mode. If you real want to boot from SATA 1. you need to porting driver from kernel to FILO_IN_ETHERBOOT to make use simple scsi interface to access the sata disk. 2. or easy way is boot one tiny kernel ( with ck804 sata support and kexec support) from IDE(FILO, Etherboot), USB(FILO_IN_ETHERBOOT), Network(Etherboot) and use kexec tools to boot the kernel on your SATA disk. Current USB IRQ setting in LinuxBIOS should be good enough to make use device working. Please make sure setting on mptable.c is right. Also you may need to set apic for kernel to enable io-apic to be used. YH ________________________________ From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Anil B G Sent: Friday, September 01, 2006 8:40 AM To: Jonathan Sturges Cc: linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] Enabling USB 2.0 Thanks. I plan to boot from SATA and not from USB. Do any other boards supported by LinuxBIOS (whose source is available in the source tree) bringup USB that I could use as a reference? On 9/1/06, Jonathan Sturges wrote: Anil B G wrote: > Hi, > I am trying to enable USB on a board similar to Tyan s2892 (CK804) > chipset? > Is there anything that else that needs to be done separately other > than setting the irqs et al correctly? Specifically do we need to > write some sort of a driver to enable the USB host controller. > > Thanks > Anil Assuming you don't hope to boot from USB, all you really should need is to setup the IRQ map, AFAIK. Then the Linux kernel will detect it and be able to attach the appropriate driver. -Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From uwe at hermann-uwe.de Fri Sep 1 21:46:00 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 1 Sep 2006 21:46:00 +0200 Subject: [LinuxBIOS] IT8716F support. Message-ID: <20060901194559.GA11859@aragorn> Hi, here's code for the IT8716F, untested as always. The patch also includes some smaller cosmetic fixes... Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org -------------- next part -------------- Index: src/superio/ite/it8712f/it8712f_early_serial.c =================================================================== --- src/superio/ite/it8712f/it8712f_early_serial.c (Revision 2394) +++ src/superio/ite/it8712f/it8712f_early_serial.c (Arbeitskopie) @@ -31,7 +31,7 @@ #define IT8712F_CONFIG_REG_CLOCKSEL 0x23 /* Clock Selection. */ #define IT8712F_CONFIG_REG_SWSUSP 0x24 /* Software Suspend, Flash I/F. */ -#define IT8712F_CONFIGURATION_PORT 0x2E /* Write-only. */ +#define IT8712F_CONFIGURATION_PORT 0x2e /* Write-only. */ /* The content of IT8712F_CONFIG_REG_LDN (index 0x07) must be set to the * LDN the register belongs to, before you can access the register. */ Index: src/superio/ite/it8712f/it8712f.h =================================================================== --- src/superio/ite/it8712f/it8712f.h (Revision 2394) +++ src/superio/ite/it8712f/it8712f.h (Arbeitskopie) @@ -16,6 +16,9 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +/* Datasheet: http://www.ite.com.tw/product_info/PC/Brief-IT8712_2.asp */ +/* Status: untested on real hardware, but it compiles. */ + #define IT8712F_FDC 0x00 /* Floppy */ #define IT8712F_SP1 0x01 /* Com1 */ #define IT8712F_SP2 0x02 /* Com2 */ Index: src/superio/ite/it8671f/it8671f_early_serial.c =================================================================== --- src/superio/ite/it8671f/it8671f_early_serial.c (Revision 2394) +++ src/superio/ite/it8671f/it8671f_early_serial.c (Arbeitskopie) @@ -20,9 +20,9 @@ #include "it8671f.h" /* The base address is 0x3f0, 0x3bd, or 0x370, depending on config bytes. */ -#define SIO_BASE 0x3f0 -#define SIO_INDEX SIO_BASE -#define SIO_DATA SIO_BASE+1 +#define SIO_BASE 0x3f0 +#define SIO_INDEX SIO_BASE +#define SIO_DATA SIO_BASE+1 /* Global Configuration Registers. */ #define IT8671F_CONFIG_REG_CC 0x02 /* Configure Control (write-only). */ @@ -31,7 +31,6 @@ #define IT8671F_CONFIG_REG_SWSUSP 0x24 /* Software Suspend. */ #define IT8671F_CONFIGURATION_PORT 0x0279 /* Write-only. */ -#define IT8671F_WRITE_DATA_PORT 0x0A79 /* Write-only. */ /* Special values used for entering MB PnP mode. The first four bytes of * each line determine the address port, the last four are data. */ Index: src/superio/ite/it8671f/it8671f.h =================================================================== --- src/superio/ite/it8671f/it8671f.h (Revision 2394) +++ src/superio/ite/it8671f/it8671f.h (Arbeitskopie) @@ -16,6 +16,9 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +/* Datasheet: Not available online, got it from ITE per request. */ +/* Status: Com1 is tested and works. */ + #define IT8671F_FDC 0x00 /* Floppy */ #define IT8671F_SP1 0x01 /* Com1 */ #define IT8671F_SP2 0x02 /* Com2 */ Index: src/superio/ite/it8716f/Config.lb =================================================================== --- src/superio/ite/it8716f/Config.lb (Revision 0) +++ src/superio/ite/it8716f/Config.lb (Revision 0) @@ -0,0 +1,2 @@ +config chip.h +object superio.o Index: src/superio/ite/it8716f/it8716f_early_serial.c =================================================================== --- src/superio/ite/it8716f/it8716f_early_serial.c (Revision 0) +++ src/superio/ite/it8716f/it8716f_early_serial.c (Revision 0) @@ -0,0 +1,87 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include "it8716f.h" + +/* The base address is 0x2e or 0x4e, depending on config bytes. */ +#define SIO_BASE 0x2e +#define SIO_INDEX SIO_BASE +#define SIO_DATA SIO_BASE+1 + +/* Global Configuration Registers. */ +#define IT8716F_CONFIG_REG_CC 0x02 /* Configure Control (write-only). */ +#define IT8716F_CONFIG_REG_LDN 0x07 /* Logical Device Number. */ +#define IT8716F_CONFIG_REG_CONFIGSEL 0x22 /* Configuration Select. */ +#define IT8716F_CONFIG_REG_CLOCKSEL 0x23 /* Clock Selection. */ +#define IT8716F_CONFIG_REG_SWSUSP 0x24 /* Software Suspend, Flash I/F. */ + +#define IT8716F_CONFIGURATION_PORT 0x2e /* Write-only. */ + +/* The content of IT8716F_CONFIG_REG_LDN (index 0x07) must be set to the + * LDN the register belongs to, before you can access the register. */ +static void it8716f_sio_write(uint8_t ldn, uint8_t index, uint8_t value) +{ + outb(IT8716F_CONFIG_REG_LDN, SIO_BASE); + outb(ldn, SIO_DATA); + outb(index, SIO_BASE); + outb(value, SIO_DATA); +} + +/* Enable the peripheral devices on the IT8716F Super IO chip. */ +static void it8716f_enable_serial(device_t dev, unsigned iobase) +{ + /* (1) Enter the configuration state (MB PnP mode). */ + + /* Perform MB PnP setup to put the SIO chip at 0x2e. */ + /* Base address 0x2e: 0x87 0x01 0x55 0x55. */ + /* Base address 0x4e: 0x87 0x01 0x55 0xaa. */ + outb(0x87, IT8716F_CONFIGURATION_PORT); + outb(0x01, IT8716F_CONFIGURATION_PORT); + outb(0x55, IT8716F_CONFIGURATION_PORT); + outb(0x55, IT8716F_CONFIGURATION_PORT); + + /* (2) Modify the data of configuration registers. */ + + /* Select the chip to configure (if there's more than one). + * Set bit 7 to select JP3=1, clear bit 7 to select JP3=0. + * If this register is not written, both chips are configured. */ + /* it8716f_sio_write(0x00, IT8716F_CONFIG_REG_CONFIGSEL, 0x00); */ + + /* Enable all devices. */ + it8716f_sio_write(IT8716F_FDC, 0x30, 0x1); /* Floppy */ + it8716f_sio_write(IT8716F_SP1, 0x30, 0x1); /* Serial port 1 */ + it8716f_sio_write(IT8716F_SP2, 0x30, 0x1); /* Serial port 2 */ + it8716f_sio_write(IT8716F_PP, 0x30, 0x1); /* Parallel port */ + it8716f_sio_write(IT8716F_EC, 0x30, 0x1); /* Environment controller */ + it8716f_sio_write(IT8716F_KBCK, 0x30, 0x1); /* Keyboard */ + it8716f_sio_write(IT8716F_KBCM, 0x30, 0x1); /* Mouse */ + it8716f_sio_write(IT8716F_MIDI, 0x30, 0x1); /* MIDI port */ + it8716f_sio_write(IT8716F_GAME, 0x30, 0x1); /* GAME port */ + it8716f_sio_write(IT8716F_IR, 0x30, 0x1); /* Consumer IR */ + + /* Select 24MHz/48MHz CLKIN (set/clear bit 0). TODO: Needed? */ + /* it8716f_sio_write(0x00, IT8716F_CONFIG_REG_CLOCKSEL, 0x00); */ + + /* Clear software suspend mode (clear bit 0). TODO: Needed? */ + /* it8716f_sio_write(0x00, IT8716F_CONFIG_REG_SWSUSP, 0x00); */ + + /* (3) Exit the configuration state (MB PnP mode). */ + it8716f_sio_write(0x00, IT8716F_CONFIG_REG_CC, 0x02); +} + Index: src/superio/ite/it8716f/superio.c =================================================================== --- src/superio/ite/it8716f/superio.c (Revision 0) +++ src/superio/ite/it8716f/superio.c (Revision 0) @@ -0,0 +1,91 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include "chip.h" +#include "it8716f.h" + +static void init(device_t dev) +{ + struct superio_ITE_it8716f_config *conf; + struct resource *res0, *res1; + + if (!dev->enabled) { + return; + } + + conf = dev->chip_info; + + switch (dev->path.u.pnp.device) { + case IT8716F_FDC: /* TODO. */ + break; + case IT8716F_SP1: + res0 = find_resource(dev, PNP_IDX_IO0); + init_uart8250(res0->base, &conf->com1); + break; + case IT8716F_SP2: + res0 = find_resource(dev, PNP_IDX_IO0); + init_uart8250(res0->base, &conf->com2); + break; + case IT8716F_PP: /* TODO. */ + break; + case IT8716F_EC: /* TODO. */ + break; + case IT8716F_KBCK: + res0 = find_resource(dev, PNP_IDX_IO0); + res1 = find_resource(dev, PNP_IDX_IO1); + init_pc_keyboard(res0->base, res1->base, &conf->keyboard); + break; + case IT8716F_KBCM: /* TODO. */ + break; + case IT8716F_MIDI: /* TODO. */ + break; + case IT8716F_GAME: /* TODO. */ + break; + case IT8716F_IR: /* TODO. */ + break; + } +} + +static struct device_operations ops = { + .read_resources = pnp_read_resources, + .set_resources = pnp_set_resources, + .enable_resources = pnp_enable_resources, + .enable = pnp_enable, + .init = init, +}; + +/* TODO: FDC, PP, EC, KBCM, MIDI, GAME, IR. */ +static struct pnp_info pnp_dev_info[] = { + { &ops, IT8716F_SP1, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, }, + { &ops, IT8716F_SP2, PNP_IO0 | PNP_IRQ0 | PNP_DRQ0 | PNP_DRQ1, { 0x7f8, 0 }, }, + { &ops, IT8716F_KBCK, PNP_IO0 | PNP_IO1 | PNP_IRQ0, { 0x7f8, 0 }, { 0x7f8, 0x4}, }, +}; + +static void enable_dev(struct device *dev) +{ + pnp_enable_devices(dev, &pnp_ops, + sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info); +} + +struct chip_operations superio_ITE_it8716f_ops = { + CHIP_NAME("ITE it8716f") + .enable_dev = enable_dev, +}; + Index: src/superio/ite/it8716f/chip.h =================================================================== --- src/superio/ite/it8716f/chip.h (Revision 0) +++ src/superio/ite/it8716f/chip.h (Revision 0) @@ -0,0 +1,33 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef _SUPERIO_ITE_IT8716F +#define _SUPERIO_ITE_IT8716F + +#include +#include + +extern struct chip_operations superio_ITE_it8716f_ops; + +struct superio_ITE_it8716f_config { + struct uart8250 com1, com2; + struct pc_keyboard keyboard; +}; + +#endif /* _SUPERIO_ITE_IT8716F */ + Index: src/superio/ite/it8716f/it8716f.h =================================================================== --- src/superio/ite/it8716f/it8716f.h (Revision 0) +++ src/superio/ite/it8716f/it8716f.h (Revision 0) @@ -0,0 +1,32 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* Datasheet: http://www.ite.com.tw/product_info/PC/Brief-IT8716_2.asp */ +/* Status: untested on real hardware, but it compiles. */ + +#define IT8716F_FDC 0x00 /* Floppy */ +#define IT8716F_SP1 0x01 /* Com1 */ +#define IT8716F_SP2 0x02 /* Com2 */ +#define IT8716F_PP 0x03 /* Parallel port */ +#define IT8716F_EC 0x04 /* Environment controller */ +#define IT8716F_KBCK 0x05 /* Keyboard */ +#define IT8716F_KBCM 0x06 /* Mouse */ +#define IT8716F_MIDI 0x08 /* MIDI port */ +#define IT8716F_GAME 0x09 /* GAME port */ +#define IT8716F_IR 0x0a /* Consumer IR */ + Index: src/superio/ite/it8673f/it8673f.h =================================================================== --- src/superio/ite/it8673f/it8673f.h (Revision 2394) +++ src/superio/ite/it8673f/it8673f.h (Arbeitskopie) @@ -16,6 +16,9 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +/* Datasheet: http://www.datasheet4u.com/html/I/T/8/IT8673F_ITE.pdf.html */ +/* Status: untested on real hardware, but it compiles. */ + #define IT8673F_FDC 0x00 /* Floppy */ #define IT8673F_SP1 0x01 /* Com1 */ #define IT8673F_SP2 0x02 /* Com2 */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From juergen127 at kreuzholzen.de Fri Sep 1 22:48:32 2006 From: juergen127 at kreuzholzen.de (Juergen Beisert) Date: Fri, 1 Sep 2006 22:48:32 +0200 Subject: [LinuxBIOS] Geode GX1/5530: How to forward SMI to a regular IRQ In-Reply-To: <44F82F49.9020104@speakeasy.net> References: <200608071119.17303.juergen127@kreuzholzen.de> <200608091802.00104.juergen127@kreuzholzen.de> <44F82F49.9020104@speakeasy.net> Message-ID: <200609012248.32978.juergen127@kreuzholzen.de> Hi Jonathan, On Friday 01 September 2006 15:02, you wrote: > I am catching up on some LB threads in my Inbox, and found this one. I > don't have anything technical to contribute, but am definitely interested > in your progress! To have Kahlua audio without VSA would be fantastic! > > Good luck, and keep us updated on your progress. Thanks, here it comes. Its state is: "it works for me". I can play sounds and MP3s with it. It was easier to poll the SMI status bits than to forward an SMI to a regular IRQ. So I divide my driver into two parts: One for SMI polling, and one for kahlua sound. The sound drivers registers itself by the SMI handler, to get called whenever an SMI related to the sound chip occures. That does not work very well under heavy load! But: On a 233MHz Geode with VSA BIOS playing network radio the system has 50% to 60% load (Sound Blaster Emulation with 2.4.x kernel). On my 300Mhz Geode with LinuxBios and my native sound driver playing an MP3 has a load of 3% to 5%. Some problems are still unresolved: - very short sounds do not stop at the end. The stop command from the ALSA framework is always to late, so a little piece of the last period will be repeated like an echo (due to ring buffering) - I'm not sure if the AC97 codec programming interface works correctly. Sometimes the ALSA framework finds two codecs, sometime only one (but one is correct). And most of the times the alsamixer "forgets" that the master volume also has a "mute" bit. So I have to change the bit manually to hear anything. - capturing is completely untested, it only compiles yet. - high system load increases the SMI polling latency. So some sound periods gets repeated. Comments are welcome (and recommendations how to solve the increasing SMI polling latency under heavy system load). Attached a quilt stack for a 2.6.17 kernel. Regards Juergen PS: I'm on holiday next week, without email access ;-) Back Sun, 10th. -------------- next part -------------- A non-text attachment was scrubbed... Name: kahlua-native-sound-2.6.17.tar.bz2 Type: application/x-tbz Size: 12325 bytes Desc: not available URL: From ben at hewson-venieri.com Fri Sep 1 23:28:06 2006 From: ben at hewson-venieri.com (Ben Hewson) Date: Fri, 01 Sep 2006 22:28:06 +0100 Subject: [LinuxBIOS] question regarding build Options Message-ID: <44F8A5E6.4010504@hewson-venieri.com> Ok after some playing around I have managed to get my EPIA board partly booting. I had commented out the fallback section in LinuxBIOSv2/targets/via/epia/Config.lb however the LinuxBIOSv2/src/mainboard/via/epia/Options.lb had uses USE_FALLBACK_IMAGE Anyway after booting I get the following LinuxBIOS-1.1.8.0Normal Fri Sep 1 22:07:37 BST 2006 starting... vt8601 init starting Slot 00 is SDRAM 04000000 bytes x2 Slot 01 is SDRAM 04000000 bytes x2 Slot 02 is empty Slot 03 is empty vt8601 done I have 2 x 128Mb DIMMS installed so I think they are being detected ok, however that is as far as things get. What I am trying to do, without much success is to enable the debug output. I guess I am missing the obvious, but how do I do it ? I assume I will need to modify LinuxBIOSv2/src/mainboard/via/epia/Options.lb Anyway any help would be much appreciated. Ben From smithbone at gmail.com Fri Sep 1 23:46:59 2006 From: smithbone at gmail.com (Richard Smith) Date: Fri, 1 Sep 2006 16:46:59 -0500 Subject: [LinuxBIOS] question regarding build Options In-Reply-To: <44F8A5E6.4010504@hewson-venieri.com> References: <44F8A5E6.4010504@hewson-venieri.com> Message-ID: <8a0c36780609011446u7f91c7f8uce39e9c278c6fa1f@mail.gmail.com> > LinuxBIOS-1.1.8.0Normal Fri Sep 1 22:07:37 BST 2006 starting... > vt8601 init starting > Slot 00 is SDRAM 04000000 bytes x2 > Slot 01 is SDRAM 04000000 bytes x2 > Slot 02 is empty > Slot 03 is empty > vt8601 done > We really need to update the webpage. vt8601 is broken. Has been for awhile. RAM code does not work. To fix, either: 1) Figure out from factory bios and data sheets what is wrong. Note: the data sheets _lie_ whats in them doesn't really work. Ron had this hardcoded but somewhere it broke. or 2) Go through every version of V2 (and perhaps V1) that changes the raminit code on the vt8601 and find the Rev that breaks the vt8601 ram init. Then we can revert that change. There are 3 of you now trying to get this to work so coordinate on the list and start going. Sorry I can't be more help. -- Richard A. Smith From uwe at hermann-uwe.de Sat Sep 2 19:22:21 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 2 Sep 2006 19:22:21 +0200 Subject: [LinuxBIOS] LinuxBIOS on Laptops. In-Reply-To: <44F6F327.6040201@gmx.net> References: <20060829162747.GA25404@aragorn> <44F47D8B.7060707@onelabs.com> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060831141622.GA6982@countzero.vandewege.net> <44F6F327.6040201@gmx.net> Message-ID: <20060902172221.GB14377@aragorn> HI, On Thu, Aug 31, 2006 at 04:33:11PM +0200, Carl-Daniel Hailfinger wrote: > I'm working on an updated text. Once it is finished (and has reached > consensus here), I'll tell you about it. Another very interesting issue is laptop support. I know about http://linuxbios.org/index.php/Laptop_survey but more information is surely helpful. Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | 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 Sep 2 21:16:37 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 02 Sep 2006 21:16:37 +0200 Subject: [LinuxBIOS] LinuxBIOS on Laptops. In-Reply-To: <20060902172221.GB14377@aragorn> References: <20060829162747.GA25404@aragorn> <44F47D8B.7060707@onelabs.com> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060831141622.GA6982@countzero.vandewege.net> <44F6F327.6040201@gmx.net> <20060902172221.GB14377@aragorn> Message-ID: <44F9D895.8060606@gmx.net> Uwe Hermann wrote: > > On Thu, Aug 31, 2006 at 04:33:11PM +0200, Carl-Daniel Hailfinger wrote: >> I'm working on an updated text. Once it is finished (and has reached >> consensus here), I'll tell you about it. > > Another very interesting issue is laptop support. I know about > http://linuxbios.org/index.php/Laptop_survey but more information is > surely helpful. I'd say we postpone laptop support until we have LinuxBIOS running on a few cheap mainboards because laptops present additional problems: * usually the flash chip is not socketed * video bios is tightly integrated * superios are different from what we know * most of the time, embedded controllers have to be initialized as well if you don't want to kill the hardware * wrong video initialization has the potential to kill the display Stories about LinuxBIOS frying laptops are the worst we can get now, but if we are successful enough in the traditional PC market, maybe one laptop vendor will get interested, too. And with support from a manufacturer, porting is a lot easier. Regards, Carl-Daniel From kevinpurcell at pobox.com Sat Sep 2 22:05:08 2006 From: kevinpurcell at pobox.com (Kevin Purcell) Date: Sat, 2 Sep 2006 13:05:08 -0700 Subject: [LinuxBIOS] LinuxBIOS on Laptops. In-Reply-To: <44F9D895.8060606@gmx.net> References: <20060829162747.GA25404@aragorn> <44F47D8B.7060707@onelabs.com> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060831141622.GA6982@countzero.vandewege.net> <44F6F327.6040201@gmx.net> <20060902172221.GB14377@aragorn> <44F9D895.8060606@gmx.net> Message-ID: (not a troll) What would be the selling point to the laptop maker of using LinuxBIOS? Why would they want LinuxBIOS rather than buying (and modifying) a solution from a commercial BIOS company and their CPU/chipset(s) suppliers? If you can answer this question in a way that would convince an MBA you might be able to persuade a maker to do this. If you can't give an argument that saves the company money I doubt you will get any traction. As regards the "let's get it on cheaper motherboards" I agree entirely. On Sep 2, 2006, at 12:16 PM, Carl-Daniel Hailfinger wrote: > Stories about LinuxBIOS frying laptops are the worst we can get now, > but if we are successful enough in the traditional PC market, maybe > one laptop vendor will get interested, too. And with support from > a manufacturer, porting is a lot easier. -- Kevin Purcell kevinpurcell at pobox.com From stepan at coresystems.de Sat Sep 2 22:07:27 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 2 Sep 2006 22:07:27 +0200 Subject: [LinuxBIOS] Enabling USB 2.0 In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A42070041EA@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A42070041EA@ssvlexmb2.amd.com> Message-ID: <20060902200727.GA30268@coresystems.de> * Lu, Yinghai [060901 18:27]: > You can not boot from sata on ck804, the reason is that the sata controller can > not work on compatible mode. If you real want to boot from SATA > > 1. you need to porting driver from kernel to FILO_IN_ETHERBOOT to make use > simple scsi interface to access the sata disk. or to the real filo. USB and SATA have both been backported. > 2. or easy way is boot one tiny kernel ( with ck804 sata support and kexec > support) from IDE(FILO, Etherboot), USB(FILO_IN_ETHERBOOT), Network > (Etherboot) and use kexec tools to boot the kernel on your SATA disk. > > > > Current USB IRQ setting in LinuxBIOS should be good enough to make use device > working. Please make sure setting on mptable.c is right. Also you may need to > set apic for kernel to enable io-apic to be used. > > > > YH > > > > ??????????????????????????????????????????????????????????????????????????????? > > From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] > On Behalf Of Anil B G > Sent: Friday, September 01, 2006 8:40 AM > To: Jonathan Sturges > Cc: linuxbios at linuxbios.org > Subject: Re: [LinuxBIOS] Enabling USB 2.0 > > > > Thanks. I plan to boot from SATA and not from USB. Do any other boards > supported by LinuxBIOS (whose source is available in the source tree) bringup > USB that I could use as a reference? > > On 9/1/06, Jonathan Sturges wrote: > > > > Anil B G wrote: > > > Hi, > > I am trying to enable USB on a board similar to Tyan s2892 (CK804) > > chipset? > > Is there anything that else that needs to be done separately other > > than setting the irqs et al correctly? Specifically do we need to > > write some sort of a driver to enable the USB host controller. > > > > Thanks > > Anil > > > Assuming you don't hope to boot from USB, all you really should need is > to setup the IRQ map, AFAIK. Then the Linux kernel will detect it and > be able to attach the appropriate driver. > > -Jonathan > > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Sat Sep 2 22:17:51 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 2 Sep 2006 22:17:51 +0200 Subject: [LinuxBIOS] LinuxBIOS on Laptops. In-Reply-To: References: <44F47D8B.7060707@onelabs.com> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060831141622.GA6982@countzero.vandewege.net> <44F6F327.6040201@gmx.net> <20060902172221.GB14377@aragorn> <44F9D895.8060606@gmx.net> Message-ID: <20060902201750.GB30424@coresystems.de> * Kevin Purcell [060902 22:05]: > If you can answer this question in a way that would convince an MBA > you might be able to persuade a maker to do this. If you can't give > an argument that saves the company money I doubt you will get any > traction. This is easy: It makes costs more reliable as you have fixed one time development costs and no per motherboards license fee. In addition it is a lot cheaper that its competitors, if you look out there. The fact that it is a technical superior product is of no interest to some MBAs so I do not mention this seperately in detail here ;-) 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 uwe at hermann-uwe.de Sun Sep 3 01:46:52 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 3 Sep 2006 01:46:52 +0200 Subject: [LinuxBIOS] IT8705F (and IT8705FA) support. Message-ID: <20060902234652.GA27909@aragorn> Hi, you know the drill... patch attached. Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org -------------- next part -------------- Index: src/superio/ite/it8705f/Config.lb =================================================================== --- src/superio/ite/it8705f/Config.lb (Revision 0) +++ src/superio/ite/it8705f/Config.lb (Revision 0) @@ -0,0 +1,2 @@ +config chip.h +object superio.o Index: src/superio/ite/it8705f/it8705f_early_serial.c =================================================================== --- src/superio/ite/it8705f/it8705f_early_serial.c (Revision 0) +++ src/superio/ite/it8705f/it8705f_early_serial.c (Revision 0) @@ -0,0 +1,88 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include "it8705f.h" + +/* The base address is 0x2e or 0x4e, depending on config bytes. */ +#define SIO_BASE 0x2e +#define SIO_INDEX SIO_BASE +#define SIO_DATA SIO_BASE+1 + +/* Global Configuration Registers. */ +#define IT8705F_CONFIG_REG_CC 0x02 /* Configure Control (write-only). */ +#define IT8705F_CONFIG_REG_LDN 0x07 /* Logical Device Number. */ +#define IT8705F_CONFIG_REG_CONFIGSEL 0x22 /* Configuration Select. */ + +/* WTF? 0x23 and 0x24 are swapped here (when compared to other IT87xx). */ +#define IT8705F_CONFIG_REG_CLOCKSEL 0x24 /* Clock Selection. */ +#define IT8705F_CONFIG_REG_SWSUSP 0x23 /* Software Suspend, Flash I/F. */ + +#define IT8705F_CONFIGURATION_PORT 0x2e /* Write-only. */ + +/* The content of IT8705F_CONFIG_REG_LDN (index 0x07) must be set to the + * LDN the register belongs to, before you can access the register. */ +static void it8705f_sio_write(uint8_t ldn, uint8_t index, uint8_t value) +{ + outb(IT8705F_CONFIG_REG_LDN, SIO_BASE); + outb(ldn, SIO_DATA); + outb(index, SIO_BASE); + outb(value, SIO_DATA); +} + +/* Enable the peripheral devices on the IT8705F Super IO chip. */ +static void it8705f_enable_serial(device_t dev, unsigned iobase) +{ + /* (1) Enter the configuration state (MB PnP mode). */ + + /* Perform MB PnP setup to put the SIO chip at 0x2e. */ + /* Base address 0x2e: 0x87 0x01 0x55 0x55. */ + /* Base address 0x4e: 0x87 0x01 0x55 0xaa. */ + outb(0x87, IT8705F_CONFIGURATION_PORT); + outb(0x01, IT8705F_CONFIGURATION_PORT); + outb(0x55, IT8705F_CONFIGURATION_PORT); + outb(0x55, IT8705F_CONFIGURATION_PORT); + + /* (2) Modify the data of configuration registers. */ + + /* Select the chip to configure (if there's more than one). + * Set bit 7 to select JP3=1, clear bit 7 to select JP3=0. + * If this register is not written, both chips are configured. */ + /* it8705f_sio_write(0x00, IT8705F_CONFIG_REG_CONFIGSEL, 0x00); */ + + /* Enable all devices. */ + it8705f_sio_write(IT8705F_FDC, 0x30, 0x1); /* Floppy */ + it8705f_sio_write(IT8705F_SP1, 0x30, 0x1); /* Serial port 1 */ + it8705f_sio_write(IT8705F_SP2, 0x30, 0x1); /* Serial port 2 */ + it8705f_sio_write(IT8705F_PP, 0x30, 0x1); /* Parallel port */ + it8705f_sio_write(IT8705F_EC, 0x30, 0x1); /* Environment controller */ + /* GPIO */ + it8705f_sio_write(IT8705F_GAME, 0x30, 0x1); /* GAME port */ + it8705f_sio_write(IT8705F_IR, 0x30, 0x1); /* Consumer IR */ + it8705f_sio_write(IT8705F_MIDI, 0x30, 0x1); /* MIDI port */ + + /* Select 24MHz/48MHz CLKIN (set/clear bit 0). TODO: Needed? */ + /* it8705f_sio_write(0x00, IT8705F_CONFIG_REG_CLOCKSEL, 0x00); */ + + /* Clear software suspend mode (clear bit 0). TODO: Needed? */ + /* it8705f_sio_write(0x00, IT8705F_CONFIG_REG_SWSUSP, 0x00); */ + + /* (3) Exit the configuration state (MB PnP mode). */ + it8705f_sio_write(0x00, IT8705F_CONFIG_REG_CC, 0x02); +} + Index: src/superio/ite/it8705f/superio.c =================================================================== --- src/superio/ite/it8705f/superio.c (Revision 0) +++ src/superio/ite/it8705f/superio.c (Revision 0) @@ -0,0 +1,86 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* This chip doesn't seem to have keyboard and mouse support. */ + +#include +#include "chip.h" +#include "it8705f.h" + +static void init(device_t dev) +{ + struct superio_ITE_it8705f_config *conf; + struct resource *res0, *res1; + + if (!dev->enabled) { + return; + } + + conf = dev->chip_info; + + switch (dev->path.u.pnp.device) { + case IT8705F_FDC: /* TODO. */ + break; + case IT8705F_SP1: + res0 = find_resource(dev, PNP_IDX_IO0); + init_uart8250(res0->base, &conf->com1); + break; + case IT8705F_SP2: + res0 = find_resource(dev, PNP_IDX_IO0); + init_uart8250(res0->base, &conf->com2); + break; + case IT8705F_PP: /* TODO. */ + break; + case IT8705F_EC: /* TODO. */ + break; + case IT8705F_GPIO: /* TODO. */ + break; + case IT8705F_GAME: /* TODO. */ + break; + case IT8705F_IR: /* TODO. */ + break; + case IT8705F_MIDI: /* TODO. */ + break; + } +} + +static struct device_operations ops = { + .read_resources = pnp_read_resources, + .set_resources = pnp_set_resources, + .enable_resources = pnp_enable_resources, + .enable = pnp_enable, + .init = init, +}; + +/* TODO: FDC, PP, EC, GPIO, GAME, IR, MIDI. */ +static struct pnp_info pnp_dev_info[] = { + { &ops, IT8705F_SP1, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, }, + { &ops, IT8705F_SP2, PNP_IO0 | PNP_IRQ0 | PNP_DRQ0 | PNP_DRQ1, { 0x7f8, 0 }, }, +}; + +static void enable_dev(struct device *dev) +{ + pnp_enable_devices(dev, &pnp_ops, + sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info); +} + +struct chip_operations superio_ITE_it8705f_ops = { + CHIP_NAME("ITE it8705f") + .enable_dev = enable_dev, +}; + Index: src/superio/ite/it8705f/chip.h =================================================================== --- src/superio/ite/it8705f/chip.h (Revision 0) +++ src/superio/ite/it8705f/chip.h (Revision 0) @@ -0,0 +1,33 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef _SUPERIO_ITE_IT8705F +#define _SUPERIO_ITE_IT8705F + +/* This chip doesn't seem to have keyboard and mouse support. */ + +#include + +extern struct chip_operations superio_ITE_it8705f_ops; + +struct superio_ITE_it8705f_config { + struct uart8250 com1, com2; +}; + +#endif /* _SUPERIO_ITE_IT8705F */ + Index: src/superio/ite/it8705f/it8705f.h =================================================================== --- src/superio/ite/it8705f/it8705f.h (Revision 0) +++ src/superio/ite/it8705f/it8705f.h (Revision 0) @@ -0,0 +1,34 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* Datasheet: http://www.ite.com.tw/product_info/PC/Brief-IT8705_2.asp */ +/* Status: untested on real hardware, but it compiles. */ +/* Note: This should also work on an IT8705AF, they're almost the same. */ + +/* This chip doesn't seem to have keyboard and mouse support. */ + +#define IT8705F_FDC 0x00 /* Floppy */ +#define IT8705F_SP1 0x01 /* Com1 */ +#define IT8705F_SP2 0x02 /* Com2 */ +#define IT8705F_PP 0x03 /* Parallel port */ +#define IT8705F_EC 0x04 /* Environment controller */ +#define IT8705F_GPIO 0x05 /* GPIO */ +#define IT8705F_GAME 0x06 /* GAME port */ +#define IT8705F_IR 0x07 /* Consumer IR */ +#define IT8705F_MIDI 0x08 /* MIDI port */ + -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From yinghailu at gmail.com Sun Sep 3 01:48:25 2006 From: yinghailu at gmail.com (yhlu) Date: Sat, 2 Sep 2006 16:48:25 -0700 Subject: [LinuxBIOS] Enabling USB 2.0 In-Reply-To: <20060902200727.GA30268@coresystems.de> References: <6F7DA19D05F3CF40B890C7CA2DB13A42070041EA@ssvlexmb2.amd.com> <20060902200727.GA30268@coresystems.de> Message-ID: <2ea3fae10609021648m16f4d2e8rab1d8b6b52871924@mail.gmail.com> those two are working on FILO? YH On 9/2/06, Stefan Reinauer wrote: > * Lu, Yinghai [060901 18:27]: > > You can not boot from sata on ck804, the reason is that the sata controller can > > not work on compatible mode. If you real want to boot from SATA > > > > 1. you need to porting driver from kernel to FILO_IN_ETHERBOOT to make use > > simple scsi interface to access the sata disk. > > or to the real filo. USB and SATA have both been backported. > > > 2. or easy way is boot one tiny kernel ( with ck804 sata support and kexec > > support) from IDE(FILO, Etherboot), USB(FILO_IN_ETHERBOOT), Network > > (Etherboot) and use kexec tools to boot the kernel on your SATA disk. > > > > > > > > Current USB IRQ setting in LinuxBIOS should be good enough to make use device > > working. Please make sure setting on mptable.c is right. Also you may need to > > set apic for kernel to enable io-apic to be used. > > > > > > > > YH > > > > > > > > ??????????????????????????????????????????????????????????????????????????????? > > > > From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] > > On Behalf Of Anil B G > > Sent: Friday, September 01, 2006 8:40 AM > > To: Jonathan Sturges > > Cc: linuxbios at linuxbios.org > > Subject: Re: [LinuxBIOS] Enabling USB 2.0 > > > > > > > > Thanks. I plan to boot from SATA and not from USB. Do any other boards > > supported by LinuxBIOS (whose source is available in the source tree) bringup > > USB that I could use as a reference? > > > > On 9/1/06, Jonathan Sturges wrote: > > > > > > > > Anil B G wrote: > > > > > Hi, > > > I am trying to enable USB on a board similar to Tyan s2892 (CK804) > > > chipset? > > > Is there anything that else that needs to be done separately other > > > than setting the irqs et al correctly? Specifically do we need to > > > write some sort of a driver to enable the USB host controller. > > > > > > Thanks > > > Anil > > > > > > Assuming you don't hope to boot from USB, all you really should need is > > to setup the IRQ map, AFAIK. Then the Linux kernel will detect it and > > be able to attach the appropriate driver. > > > > -Jonathan > > > > > > > > > -- > > linuxbios mailing list > > linuxbios at linuxbios.org > > http://www.openbios.org/mailman/listinfo/linuxbios > > -- > coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. > Tel.: +49 761 7668825 ? Fax: +49 761 7664613 > Email: info at coresystems.de ? http://www.coresystems.de/ > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios From uwe at hermann-uwe.de Sun Sep 3 01:56:21 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 3 Sep 2006 01:56:21 +0200 Subject: [LinuxBIOS] LinuxBIOS on Laptops. In-Reply-To: <44F9D895.8060606@gmx.net> References: <20060829162747.GA25404@aragorn> <44F47D8B.7060707@onelabs.com> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060831141622.GA6982@countzero.vandewege.net> <44F6F327.6040201@gmx.net> <20060902172221.GB14377@aragorn> <44F9D895.8060606@gmx.net> Message-ID: <20060902235621.GB27909@aragorn> Hi, On Sat, Sep 02, 2006 at 09:16:37PM +0200, Carl-Daniel Hailfinger wrote: > I'd say we postpone laptop support until we have LinuxBIOS running on Yeah, that's probably a good idea (for the FSF campaign text). > a few cheap mainboards because laptops present additional problems: > * usually the flash chip is not socketed Most probably, yes. Luckily I do have a working test-laptop which has the chip in a socket... More details in my other post... > * video bios is tightly integrated > * superios are different from what we know Do you have more details? As far as I can see at least some seem to be very similar to non-laptop superios. If there's a datasheet it shouldn't be too hard to support them. > * most of the time, embedded controllers have to be initialized as > well if you don't want to kill the hardware > * wrong video initialization has the potential to kill the display Hm, that doesn't sound good. Which controllers in particular can become problem? > Stories about LinuxBIOS frying laptops are the worst we can get now, ACK. Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Sun Sep 3 02:03:51 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 3 Sep 2006 02:03:51 +0200 Subject: [LinuxBIOS] LinuxBIOS on a SIS 650 / SIS 691 laptop? Message-ID: <20060903000350.GC27909@aragorn> Hi, I have a test-laptop I'm going to try to port LinuxBIOS to. It's a SIS 650 / SIS 691 based system which is probably not so good, as SIS doesn't seem to be very cooperative when asked for datasheets, AFAIK. The good news is that the laptop has a PLCC chip in a socket. I'm currently trying to find out what parts I can get working... The Super IO (PC87393) shouldn't be a problem (yes, the laptop has a serial port, fortunately). Using flashrom doesn't work as there's no support for the SIS 650/691. I tried using the SIS 630/950 code, but that fails... Does anybody have datasheets for these parts? I'll definately bring the laptop to the LinuxBIOS summit for hacking purposes... Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From yinghailu at gmail.com Sun Sep 3 04:21:13 2006 From: yinghailu at gmail.com (yhlu) Date: Sat, 2 Sep 2006 19:21:13 -0700 Subject: [LinuxBIOS] LinuxBIOS on Laptops. In-Reply-To: <20060902235621.GB27909@aragorn> References: <20060829162747.GA25404@aragorn> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060831141622.GA6982@countzero.vandewege.net> <44F6F327.6040201@gmx.net> <20060902172221.GB14377@aragorn> <44F9D895.8060606@gmx.net> <20060902235621.GB27909@aragorn> Message-ID: <2ea3fae10609021921m398c2d78ne8b0a6f9cad418c3@mail.gmail.com> Arima has one Laptop with Nvidia CK804 chipset. That should be more easier, and I hope Arima could work it out to make it support LinuxBIOS. YH On 9/2/06, Uwe Hermann wrote: > Hi, > > On Sat, Sep 02, 2006 at 09:16:37PM +0200, Carl-Daniel Hailfinger wrote: > > I'd say we postpone laptop support until we have LinuxBIOS running on > > Yeah, that's probably a good idea (for the FSF campaign text). > > > > a few cheap mainboards because laptops present additional problems: > > * usually the flash chip is not socketed > > Most probably, yes. Luckily I do have a working test-laptop which has > the chip in a socket... More details in my other post... > > > > * video bios is tightly integrated > > * superios are different from what we know > > Do you have more details? As far as I can see at least some seem to be > very similar to non-laptop superios. If there's a datasheet it shouldn't > be too hard to support them. > > > > * most of the time, embedded controllers have to be initialized as > > well if you don't want to kill the hardware > > * wrong video initialization has the potential to kill the display > > Hm, that doesn't sound good. Which controllers in particular can become > problem? > > > > Stories about LinuxBIOS frying laptops are the worst we can get now, > > ACK. > > > Uwe. > -- > Uwe Hermann > http://www.hermann-uwe.de > http://www.it-services-uh.de | http://www.crazy-hacks.org > http://www.holsham-traders.de | http://www.unmaintained-free-software.org > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (GNU/Linux) > > iD8DBQFE+holXdVoV3jWIbQRArT1AJ9Z+BuLxfSqz1UsJ1Uh6vgQeJsxBQCfQVUH > xUcmYdBUYxjTjeFIQRLwboE= > =H1LG > -----END PGP SIGNATURE----- > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > > From rogelio.serrano at gmail.com Sun Sep 3 04:59:49 2006 From: rogelio.serrano at gmail.com (Rogelio Serrano) Date: Sun, 3 Sep 2006 10:59:49 +0800 Subject: [LinuxBIOS] LinuxBIOS on Laptops. In-Reply-To: References: <20060829162747.GA25404@aragorn> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060831141622.GA6982@countzero.vandewege.net> <44F6F327.6040201@gmx.net> <20060902172221.GB14377@aragorn> <44F9D895.8060606@gmx.net> Message-ID: On 9/3/06, Kevin Purcell wrote: > (not a troll) > > What would be the selling point to the laptop maker of using LinuxBIOS? > > Why would they want LinuxBIOS rather than buying (and modifying) a > solution from a commercial BIOS company and their CPU/chipset(s) > suppliers? > many things that go beyond the bios. you cant make an argument with the bios alone. you have to show what an open bios would bring and actually link that to higher sales. for example if it allows ubiquitous computing where you would rather use your laptop instead of pen and paper then that would be convincing. instant accessibility is a very big thing now. imagine getting a phone call and your super compact laptop is off. you turn it on then wait for it to bootup. then you login and wait a little more. then you look for that text editor. then when you find it you double click on it. then you start typing notes on it then you need to look at contacts then you need to lookup your to do list. you would rather have a common low cost paper based organizer. now if your pc can bootup in 3 seconds that changes a whole lot of things. with software suspend you can have almost instant access to your apps. you can leave your whole office suite "running" all the time without killing your batteries. or burning your lap. now thats a convincing argument. -- the thing i like with my linux pc is that i can sum up my complaints in 5 items From bari at onelabs.com Sun Sep 3 05:00:39 2006 From: bari at onelabs.com (Bari Ari) Date: Sat, 02 Sep 2006 22:00:39 -0500 Subject: [LinuxBIOS] LinuxBIOS on Laptops. In-Reply-To: <20060902235621.GB27909@aragorn> References: <20060829162747.GA25404@aragorn> <44F47D8B.7060707@onelabs.com> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060831141622.GA6982@countzero.vandewege.net> <44F6F327.6040201@gmx.net> <20060902172221.GB14377@aragorn> <44F9D895.8060606@gmx.net> <20060902235621.GB27909@aragorn> Message-ID: <44FA4557.8030305@onelabs.com> Uwe Hermann wrote: >> * video bios is tightly integrated >> * superios are different from what we know >> > > Do you have more details? As far as I can see at least some seem to be > very similar to non-laptop superios. If there's a datasheet it shouldn't > be too hard to support them. > > > >> * most of the time, embedded controllers have to be initialized as >> well if you don't want to kill the hardware >> * wrong video initialization has the potential to kill the display >> > > Hm, that doesn't sound good. Which controllers in particular can become > problem? > > The Keyboard Scan/ Power Management Controllers are the non-standard parts of laptops. Laptops use microcontrollers that do combined operations such as keyboard scan, Flash write enable, battery management, power management, lid open/close, power buttons etc. These are the areas that we would need documentation for. The chipset docs may all be available but not docs to the power management/keyboard scan controller firmware. The docs for the micros describe the general purpose micro itself, but that won't tell you how they are using all of its gpio pins and ports. Bari From stepan at coresystems.de Sun Sep 3 12:28:11 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 3 Sep 2006 12:28:11 +0200 Subject: [LinuxBIOS] Enabling USB 2.0 In-Reply-To: <2ea3fae10609021648m16f4d2e8rab1d8b6b52871924@mail.gmail.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A42070041EA@ssvlexmb2.amd.com> <20060902200727.GA30268@coresystems.de> <2ea3fae10609021648m16f4d2e8rab1d8b6b52871924@mail.gmail.com> Message-ID: <20060903102811.GA27717@coresystems.de> * yhlu [060903 01:48]: > those two are working on FILO? they need more testing, but yes. > YH -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Sun Sep 3 13:02:31 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 3 Sep 2006 13:02:31 +0200 Subject: [LinuxBIOS] LinuxBIOS on a SIS 650 / SIS 691 laptop? In-Reply-To: <20060903000350.GC27909@aragorn> References: <20060903000350.GC27909@aragorn> Message-ID: <20060903110230.GC28740@coresystems.de> * Uwe Hermann [060903 02:03]: > The Super IO (PC87393) shouldn't be a problem (yes, the laptop has a > serial port, fortunately). Using flashrom doesn't work as there's no > support for the SIS 650/691. I tried using the SIS 630/950 code, > but that fails... > > Does anybody have datasheets for these parts? If so they would not be allowed to pass it to you unless they hire you. But you could try to get them yourself. Maybe Ollie Lho can help you? He worked for SIS in his earlier life. > I'll definately bring the laptop to the LinuxBIOS summit for hacking > purposes... Cool. Then I will also bring an eeprom burner. -- 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 lanl.gov Sun Sep 3 23:01:14 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Sun, 03 Sep 2006 15:01:14 -0600 Subject: [LinuxBIOS] LinuxBIOS on Laptops. In-Reply-To: <44F9D895.8060606@gmx.net> References: <20060829162747.GA25404@aragorn> <44F47D8B.7060707@onelabs.com> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060831141622.GA6982@countzero.vandewege.net> <44F6F327.6040201@gmx.net> <20060902172221.GB14377@aragorn> <44F9D895.8060606@gmx.net> Message-ID: <44FB429A.4050401@lanl.gov> Carl-Daniel Hailfinger wrote: > I'd say we postpone laptop support until we have LinuxBIOS running on > a few cheap mainboards because laptops present additional problems: Carl-Daniel, as you well know, the laptop mass market came first with OLPC :-) all we need to do is get quanta to well OLPC with adult-size keyboards :-) ron From bari at onelabs.com Mon Sep 4 01:11:50 2006 From: bari at onelabs.com (Bari Ari) Date: Sun, 03 Sep 2006 18:11:50 -0500 Subject: [LinuxBIOS] LinuxBIOS on Laptops. In-Reply-To: <200609030908.20653.gfiala@s.netic.de> References: <20060829162747.GA25404@aragorn> <20060902235621.GB27909@aragorn> <44FA4557.8030305@onelabs.com> <200609030908.20653.gfiala@s.netic.de> Message-ID: <44FB6136.3050605@onelabs.com> Guido Fiala wrote: > In the age of USB i wonder if we still need a keyboard/mouse controller for > other than that. > > How would a (linux) mainboard look like? Is there a parts list, e.g. one for > desktop, one for laptop that would be great? > > Look for laptops that have the firmware Flash write enable lines controlled only by the chipset and not also by the keyboard/system management controller. This will allow a developer to rewrite the Flash with LinuxBIOS. Most efforts to port LinuxBIOS on laptops in the past could not get past this hurdle. Designing and manufacturing for a laptop for mass market using LinuxBIOS is simple. The bill of material and hardware design are the same as a laptop using a closed source BIOS. Laptop mainboards are typically manufactured in high volumes in single runs (much the same as desktop/platform mainboards). The LinuxBIOS would be developed for the mainboard during the design stage of the project and then programmed into the flash before manufacture or after the flash devices are installed on the boards. There hasn't been much demand for laptops to have LinuxBIOS yet. The first major project to demand LinuxBIOS on a laptop has probably been the OLPC project. I doubt if Quanta had much experience with or knowledge of LinuxBIOS before OLPC. The keyboard scan/system management controllers also use closed source firmware. Multikey is one example. It is used for port swap and hot plug of keyboard and mouse, power management, battery charging, Flash-BIOS control, SMbus, Gate A20, Security, hotkeys, etc. Renesas is one vendor of micros that are used in laptops: http://america.renesas.com/fmwk.jsp?cnt=h8s_family_landing.jsp&fp=/products/mpumcu/h8s_family/ For more Multikey info: http://www.phoenix.com/NR/rdonlyres/B9F4AEFF-EF92-4A45-B304-161FF728EFDC/0/multikey.pdf Bari From rogelio.serrano at gmail.com Mon Sep 4 06:03:06 2006 From: rogelio.serrano at gmail.com (Rogelio Serrano) Date: Mon, 4 Sep 2006 12:03:06 +0800 Subject: [LinuxBIOS] LinuxBIOS on Laptops. In-Reply-To: <44FB429A.4050401@lanl.gov> References: <20060829162747.GA25404@aragorn> <44F4AC69.20006@gmx.net> <20060829213123.GB21904@coresystems.de> <44F4BB82.2030109@gmx.net> <20060830123758.GC28991@aragorn> <20060831141622.GA6982@countzero.vandewege.net> <44F6F327.6040201@gmx.net> <20060902172221.GB14377@aragorn> <44F9D895.8060606@gmx.net> <44FB429A.4050401@lanl.gov> Message-ID: On 9/4/06, Ronald G Minnich wrote: > Carl-Daniel Hailfinger wrote: > > > I'd say we postpone laptop support until we have LinuxBIOS running on > > a few cheap mainboards because laptops present additional problems: > > Carl-Daniel, as you well know, the laptop mass market came first with > OLPC :-) > > all we need to do is get quanta to well OLPC with adult-size keyboards :-) > of course. that would be great! -- the thing i like with my linux pc is that i can sum up my complaints in 5 items From eswierk at arastra.com Mon Sep 4 20:22:46 2006 From: eswierk at arastra.com (Ed Swierk) Date: Mon, 4 Sep 2006 11:22:46 -0700 Subject: [LinuxBIOS] LinuxBIOS+FILO hangs on qemu Message-ID: Hello, I'm trying to boot Linux on qemu (0.8.2) with LinuxBIOSv2 (svn 2394) and FILO (0.5). I built filo.elf, ran buildtarget emulation/qemu-i386, changed Config.lb to use filo.elf as the payload, and built LinuxBIOS. I then copied the resulting qemu-bios.rom to bios.bin, and started qemu with the -L option to use this bios.bin, and -nographic to use the serial console. When I try to boot a 2.6 bzImage kernel (using diskboot.img from Fedora), FILO gets as far as "Jumping to entry point..." and then hangs: ----- > qemu -L ~ -hda diskboot.img -m 256 -nographic -no-kqemu -d in_asm,exec (qemu) LinuxBIOS-1.1.8-FILO Mon Sep 4 10:07:27 PDT 2006 starting... Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.8-FILO Mon Sep 4 11:01:19 PDT 2006 booting... Enumerating buses... Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled PCI: pci_scan_bus for bus 0 PCI: 00:00.0 [8086/1237] enabled PCI: 00:01.0 [8086/7000] enabled PCI: 00:01.1 [8086/7010] enabled PCI: 00:01.3 [8086/7113] enabled PCI: 00:02.0 [1013/00b8] enabled PCI: 00:03.0 [10ec/8029] enabled PCI: pci_scan_bus returning with max=00 done Allocating resources... Reading resources... Done reading resources. Setting resources... PCI: 00:01.1 20 <- [0x0000001400 - 0x000000140f] io PCI: 00:02.0 10 <- [0x00fc000000 - 0x00fdffffff] prefmem PCI: 00:02.0 14 <- [0x00fe000000 - 0x00fe000fff] mem PCI: 00:03.0 10 <- [0x0000001000 - 0x00000010ff] io Done setting resources. Done allocating resources. Enabling resources... PCI: 00:00.0 subsystem <- 00/00 PCI: 00:00.0 cmd <- 140 PCI: 00:01.0 subsystem <- 00/00 PCI: 00:01.0 cmd <- 147 PCI: 00:01.1 cmd <- 141 PCI: 00:01.3 cmd <- 140 PCI: 00:02.0 cmd <- 143 PCI: 00:03.0 cmd <- 141 done. Initializing devices... Root Device init PCI: 00:00.0 init PCI: 00:01.0 init PCI: 00:01.1 init PCI: 00:01.3 init PCI: 00:02.0 init PCI: 00:03.0 init Devices initialized Moving GDT to 0x500...ok Wrote linuxbios table at: 00000530 - 00000b74 checksum 841b Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 rom_stream: 0xfffe0000 - 0xfffeffff Found ELF candiate at offset 0 New segment addr 0x100000 size 0x236e0 offset 0xc0 filesize 0x9748 (cleaned up) New segment addr 0x100000 size 0x236e0 offset 0xc0 filesize 0x9748 New segment addr 0x1236e0 size 0x48 offset 0x9820 filesize 0x48 (cleaned up) New segment addr 0x1236e0 size 0x48 offset 0x9820 filesize 0x48 Dropping non PT_LOAD segment Dropping non PT_LOAD segment Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000000236e0 filesz: 0x0000000000009748 Clearing Segment: addr: 0x0000000000109748 memsz: 0x0000000000019f98 Loading Segment: addr: 0x00000000001236e0 memsz: 0x0000000000000048 filesz: 0x0000000000000048 Jumping to boot code at 0x106924 FILO version 0.5 (eswierk at bianchi.arastra.com) Mon Sep 4 11:00:39 PDT 2006 collect_sys_info: boot eax = 0xe1fb007 collect_sys_info: boot ebx = 0x3ff77a0 collect_sys_info: boot arg = 0x3ff77a0 malloc_diag: alloc: 0 bytes (0 blocks), free: 16376 bytes (1 blocks) malloc_diag: alloc: 24 bytes (1 blocks), free: 16352 bytes (1 blocks) collect_elfboot_info: Bootloader: elfboot collect_elfboot_info: Version: 1.3 malloc_diag: alloc: 40 bytes (2 blocks), free: 16336 bytes (1 blocks) collect_linuxbios_info: Searching for LinuxBIOS tables... find_lb_table: Found canidate at: 00000530 find_lb_table: header checksum o.k. find_lb_table: table checksum o.k. find_lb_table: record count o.k. collect_linuxbios_info: Found LinuxBIOS table at: 00000530 malloc_diag: alloc: 128 bytes (3 blocks), free: 16248 bytes (1 blocks) convert_memmap: 0x00000000000000 0x00000000000bdc 16 convert_memmap: 0x00000000000bdc 0x0000000009f424 1 convert_memmap: 0x000000000c0000 0x00000000030000 1 convert_memmap: 0x000000000f0000 0x00000003f10000 1 convert_memmap: 0x000000000f0000 0x00000000000000 16 collect_sys_info: 0000000000000bdc-00000000000a0000 collect_sys_info: 00000000000c0000-00000000000f0000 collect_sys_info: 00000000000f0000-0000000004000000 collect_sys_info: RAM 64 MB relocate: Current location: 0x100000-0x123727 relocate: Relocating to 0x3fdc8d0-0x3fffff7... ok setup_timers: CPU 797 MHz pci_init: Scanning PCI: found 6 devices malloc_diag: alloc: 208 bytes (4 blocks), free: 16168 bytes (1 blocks) pci_init: 00:00.0 8086:1237 0600 00 pci_init: 00:01.0 8086:7000 0601 00 pci_init: 00:01.1 8086:7010 0101 80 pci_init: 00:01.3 8086:7113 0680 00 pci_init: 00:02.0 1013:00b8 0300 00 pci_init: 00:03.0 10ec:8029 0200 00 Press for default boot, or for boot prompt... timed out boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200 malloc_diag: alloc: 280 bytes (5 blocks), free: 16096 bytes (1 blocks) malloc_diag: alloc: 296 bytes (6 blocks), free: 16080 bytes (1 blocks) file_open: dev=hda1, path=/vmlinuz find_ide_controller: found PCI IDE controller 8086:7010 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 init_drive: Testing for hda init_drive: Probing for hda init_drive: LBA mode, sectors=16384 init_drive: LBA48 mode, sectors=16384 init_drive: Init device params... ok hda: LBA48 8192KB: QEMU HARDDISK devopen: Partition 1 start 3020518592 length 506638 Disk read error dev=1 drive=0 sector=3020518592 devread: read sector failed Disk read error dev=1 drive=0 sector=3020518594 devread: read sector failed Disk read error dev=1 drive=0 sector=3020518720 devread: read sector failed Disk read error dev=1 drive=0 sector=3020518608 devread: read sector failed Disk read error dev=1 drive=0 sector=3020518656 devread: read sector failed Unknown filesystem type malloc_diag: alloc: 280 bytes (5 blocks), free: 16096 bytes (1 blocks) malloc_diag: alloc: 208 bytes (4 blocks), free: 16168 bytes (1 blocks) boot: hda:/vmlinuz console=ttyS0 malloc_diag: alloc: 248 bytes (5 blocks), free: 16128 bytes (1 blocks) malloc_diag: alloc: 264 bytes (6 blocks), free: 16112 bytes (1 blocks) file_open: dev=hda, path=/vmlinuz Mounted fat malloc_diag: alloc: 248 bytes (5 blocks), free: 16128 bytes (1 blocks) elf_load: Not a bootable ELF image malloc_diag: alloc: 264 bytes (6 blocks), free: 16112 bytes (1 blocks) file_open: dev=hda, path=/vmlinuz devopen: already open malloc_diag: alloc: 248 bytes (5 blocks), free: 16128 bytes (1 blocks) Found Linux version 2.6.15-1.2054_FC5 (bhcompile at hs20-bc1-2.build.redhat.com) #1 Tue Mar 14 15:48:03 EST 2006 (protocol 0x204) (loadflags 0x1) bzImage. init_linux_params: Setting up paramters at 0x90000 set_memory_size: 0000000000000bdc - 00000000000a0000 set_memory_size: 00000000000c0000 - 00000000000f0000 set_memory_size: 00000000000f0000 - 0000000004000000 set_memory_size: ramtop=0x4000000 set_memory_size: ext_mem_k=64512, alt_mem_k=64512 parse_command_line: original command line: "console=ttyS0" parse_command_line: kernel command line at 0x91000 parse_command_line: kernel command line (13 bytes): "console=ttyS0" load_linux_kernel: offset=0x2000 addr=0x100000 size=0x16d7f5 Loading kernel... ok start_linux: eip=0x100000 Jumping to entry point... ----- At this point, even qemu becomes unresponsive, so it's hard to figure out exactly what it's doing while running in a tight loop. The last entry in the qemu debug log file is the "Load new stack segment with new GDT" movl instruction in __switch_context: ----- 0x03fe3213: pop %ebx 0x03fe3214: sub $0x106943,%ebx 0x03fe321a: cli 0x03fe321b: mov %esp,%esi 0x03fe321d: sub %ebx,%esi 0x03fe321f: xchg %esi,0x109700(%ebx) 0x03fe3225: add %ebx,%esi 0x03fe3227: movzwl (%esi),%edx 0x03fe322a: mov 0x14(%esi),%eax 0x03fe322d: lgdtl 0x2(%esi) 0x03fe3231: mov %edx,%ss ----- I've also tried an older qemu (0.7.2), an older LinuxBIOS (svn 2302) and an older kernel (2.4.something from Fedora Core 1), all with the same result. Any suggestions would be appreciated. --Ed From rminnich at gmail.com Tue Sep 5 02:03:04 2006 From: rminnich at gmail.com (ron minnich) Date: Mon, 4 Sep 2006 18:03:04 -0600 Subject: [LinuxBIOS] LinuxBIOS+FILO hangs on qemu In-Reply-To: References: Message-ID: <13426df10609041703o7969c01fq23d20d42c550ee69@mail.gmail.com> your problem right now is with filo. Can you try an older one? OR, better yet: if you want to work with me and make linux your boot loader, a la OLPC, that would be better: no filo at all! (not that I don't like FILO, it's wonderful, but Linux as a boot-loader is wonderful-er). let me know. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From eswierk at arastra.com Tue Sep 5 03:25:20 2006 From: eswierk at arastra.com (Ed Swierk) Date: Mon, 4 Sep 2006 18:25:20 -0700 Subject: [LinuxBIOS] LinuxBIOS+FILO hangs on qemu In-Reply-To: <13426df10609041703o7969c01fq23d20d42c550ee69@mail.gmail.com> References: <13426df10609041703o7969c01fq23d20d42c550ee69@mail.gmail.com> Message-ID: On 9/4/06, ron minnich wrote: > your problem right now is with filo. Can you try an older one? OR, better > yet: if you want to work with me and make linux your boot loader, a la OLPC, > that would be better: no filo at all! (not that I don't like FILO, it's > wonderful, but Linux as a boot-loader is wonderful-er). Figures, the only part I didn't try downgrading is filo :-) I would love to use Linux as my boot loader, but is it possible to cram LinuxBIOS plus a kernel and initrd into a puny 256 kByte EEPROM? --Ed From eswierk at arastra.com Tue Sep 5 03:35:27 2006 From: eswierk at arastra.com (Ed Swierk) Date: Mon, 4 Sep 2006 18:35:27 -0700 Subject: [LinuxBIOS] LinuxBIOS+FILO hangs on qemu In-Reply-To: References: <13426df10609041703o7969c01fq23d20d42c550ee69@mail.gmail.com> Message-ID: On 9/4/06, Ed Swierk wrote: > I would love to use Linux as my boot loader, but is it possible to > cram LinuxBIOS plus a kernel and initrd into a puny 256 kByte EEPROM? Correction: we're using a 1 MByte EEPROM, which I notice is the same size specified for the OLPC. I'll start digging into the instructions on wiki.laptop.org for building the OLPC LinuxBIOS. Any idea what configuration parameters I'd need to twiddle in emulation/qemu-i386/Config.lb to build the proper size image for qemu? --Ed From smithbone at gmail.com Tue Sep 5 03:46:23 2006 From: smithbone at gmail.com (Richard Smith) Date: Mon, 4 Sep 2006 20:46:23 -0500 Subject: [LinuxBIOS] LinuxBIOS+FILO hangs on qemu In-Reply-To: References: <13426df10609041703o7969c01fq23d20d42c550ee69@mail.gmail.com> Message-ID: <8a0c36780609041846y5027cba7sc3f7e686a28c4695@mail.gmail.com> > I'll start digging into the instructions on wiki.laptop.org for > building the OLPC LinuxBIOS. Any idea what configuration parameters > I'd need to twiddle in emulation/qemu-i386/Config.lb to build the > proper size image for qemu? Change the ROM_SIZE to be 1024*1024 or 0x100000 -- Richard A. Smith From jfaslist at yahoo.fr Tue Sep 5 12:46:26 2006 From: jfaslist at yahoo.fr (jf simon) Date: Tue, 05 Sep 2006 12:46:26 +0200 Subject: [LinuxBIOS] VGA bios and i/o access for powerpc Message-ID: <44FD5582.7030205@yahoo.fr> Hi, I have read the excellent paper on FreeVGA http://www.linuxbios.org/data/vgabios/ and I am thinking on using it on a powerpc design we have made based on IBM 970fx ppc64 CPU (after it runs linuxbios of course, but I am trying to plan ahead and see what is needed to have PCI graphic cards running on it). I have looked at the x86emu code, and more precisely to the X86EMU_pioFuncs function which is in charge of I/O accesses whenever the VGA BIOS makes an x86 int/out instruction to some I/O port (for example to the range of VGA control registers in the 0x3XX region). The graphic I intend to use is an ATI Radeon RV100 PCI card. So it looks like I will have to program the X86EMU_pioFuncs with a function that will redirect I/O accesses from the low 0x3XX addresses, to the ATI PCI I/O region that contains VGA registers. Here is an excerpt of an "lspci -vv" on my graphic card (see below). I am planning to re-direct all these I/O accesses to the region 1 (I/O ports at f4015000). The VGA registers have to be in there...where else? So it shouldn't be too hard. Am I overlooking things? The FreeVGA paper said he should be rather complicated to do on powerpc....so i may be to optimistic 02:01.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon) Subsystem: ATI Technologies Inc: Unknown device 013b Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Ste- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- References: <13426df10609041703o7969c01fq23d20d42c550ee69@mail.gmail.com> Message-ID: <44FD7825.7020106@lanl.gov> Ed Swierk wrote: > On 9/4/06, ron minnich wrote: > >>your problem right now is with filo. Can you try an older one? OR, better >>yet: if you want to work with me and make linux your boot loader, a la OLPC, >>that would be better: no filo at all! (not that I don't like FILO, it's >>wonderful, but Linux as a boot-loader is wonderful-er). > > > Figures, the only part I didn't try downgrading is filo :-) > > I would love to use Linux as my boot loader, but is it possible to > cram LinuxBIOS plus a kernel and initrd into a puny 256 kByte EEPROM? > > --Ed > no, but this is qemu ... can't you grow qemu emulated flash? ron From eswierk at arastra.com Tue Sep 5 16:27:01 2006 From: eswierk at arastra.com (Ed Swierk) Date: Tue, 5 Sep 2006 07:27:01 -0700 Subject: [LinuxBIOS] LinuxBIOS+FILO hangs on qemu In-Reply-To: <44FD7825.7020106@lanl.gov> References: <13426df10609041703o7969c01fq23d20d42c550ee69@mail.gmail.com> <44FD7825.7020106@lanl.gov> Message-ID: On 9/5/06, Ronald G Minnich wrote: > no, but this is qemu ... can't you grow qemu emulated flash? Yes, but we plan to eventually run on actual hardware and would prefer to keep the qemu environment as close to the real thing as possible. --Ed From kononov195-lbl at yahoo.com Tue Sep 5 18:58:05 2006 From: kononov195-lbl at yahoo.com (Roman Kononov) Date: Tue, 05 Sep 2006 11:58:05 -0500 Subject: [LinuxBIOS] LinuxBIOS+FILO hangs on qemu In-Reply-To: References: Message-ID: <44FDAC9D.8030906@yahoo.com> Maybe this will help: http://sourceforge.net/mailarchive/forum.php?thread_id=10216054&forum_id=48022 Roman On 09/04/2006 13:22, Ed Swierk wrote: > Hello, > > I'm trying to boot Linux on qemu (0.8.2) with LinuxBIOSv2 (svn 2394) > and FILO (0.5). I built filo.elf, ran buildtarget emulation/qemu-i386, > changed Config.lb to use filo.elf as the payload, and built LinuxBIOS. > I then copied the resulting qemu-bios.rom to bios.bin, and started > qemu with the -L option to use this bios.bin, and -nographic to use > the serial console. > > When I try to boot a 2.6 bzImage kernel (using diskboot.img from > Fedora), FILO gets as far as "Jumping to entry point..." and then > hangs: > > ----- >> qemu -L ~ -hda diskboot.img -m 256 -nographic -no-kqemu -d in_asm,exec > (qemu) > > LinuxBIOS-1.1.8-FILO Mon Sep 4 10:07:27 PDT 2006 starting... > Copying LinuxBIOS to ram. > Jumping to LinuxBIOS. > LinuxBIOS-1.1.8-FILO Mon Sep 4 11:01:19 PDT 2006 booting... > Enumerating buses... > Finding PCI configuration type. > PCI: Using configuration type 1 > PCI_DOMAIN: 0000 enabled > PCI: pci_scan_bus for bus 0 > PCI: 00:00.0 [8086/1237] enabled > PCI: 00:01.0 [8086/7000] enabled > PCI: 00:01.1 [8086/7010] enabled > PCI: 00:01.3 [8086/7113] enabled > PCI: 00:02.0 [1013/00b8] enabled > PCI: 00:03.0 [10ec/8029] enabled > PCI: pci_scan_bus returning with max=00 > done > Allocating resources... > Reading resources... > Done reading resources. > Setting resources... > PCI: 00:01.1 20 <- [0x0000001400 - 0x000000140f] io > PCI: 00:02.0 10 <- [0x00fc000000 - 0x00fdffffff] prefmem > PCI: 00:02.0 14 <- [0x00fe000000 - 0x00fe000fff] mem > PCI: 00:03.0 10 <- [0x0000001000 - 0x00000010ff] io > Done setting resources. > Done allocating resources. > Enabling resources... > PCI: 00:00.0 subsystem <- 00/00 > PCI: 00:00.0 cmd <- 140 > PCI: 00:01.0 subsystem <- 00/00 > PCI: 00:01.0 cmd <- 147 > PCI: 00:01.1 cmd <- 141 > PCI: 00:01.3 cmd <- 140 > PCI: 00:02.0 cmd <- 143 > PCI: 00:03.0 cmd <- 141 > done. > Initializing devices... > Root Device init > PCI: 00:00.0 init > PCI: 00:01.0 init > PCI: 00:01.1 init > PCI: 00:01.3 init > PCI: 00:02.0 init > PCI: 00:03.0 init > Devices initialized > Moving GDT to 0x500...ok > Wrote linuxbios table at: 00000530 - 00000b74 checksum 841b > > Welcome to elfboot, the open sourced starter. > January 2002, Eric Biederman. > Version 1.3 > > rom_stream: 0xfffe0000 - 0xfffeffff > Found ELF candiate at offset 0 > New segment addr 0x100000 size 0x236e0 offset 0xc0 filesize 0x9748 > (cleaned up) New segment addr 0x100000 size 0x236e0 offset 0xc0 filesize 0x9748 > New segment addr 0x1236e0 size 0x48 offset 0x9820 filesize 0x48 > (cleaned up) New segment addr 0x1236e0 size 0x48 offset 0x9820 filesize 0x48 > Dropping non PT_LOAD segment > Dropping non PT_LOAD segment > Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000000236e0 > filesz: 0x0000000000009748 > Clearing Segment: addr: 0x0000000000109748 memsz: 0x0000000000019f98 > Loading Segment: addr: 0x00000000001236e0 memsz: 0x0000000000000048 > filesz: 0x0000000000000048 > Jumping to boot code at 0x106924 > FILO version 0.5 (eswierk at bianchi.arastra.com) Mon Sep 4 11:00:39 PDT 2006 > collect_sys_info: boot eax = 0xe1fb007 > collect_sys_info: boot ebx = 0x3ff77a0 > collect_sys_info: boot arg = 0x3ff77a0 > malloc_diag: alloc: 0 bytes (0 blocks), free: 16376 bytes (1 blocks) > malloc_diag: alloc: 24 bytes (1 blocks), free: 16352 bytes (1 blocks) > collect_elfboot_info: Bootloader: elfboot > collect_elfboot_info: Version: 1.3 > malloc_diag: alloc: 40 bytes (2 blocks), free: 16336 bytes (1 blocks) > collect_linuxbios_info: Searching for LinuxBIOS tables... > find_lb_table: Found canidate at: 00000530 > find_lb_table: header checksum o.k. > find_lb_table: table checksum o.k. > find_lb_table: record count o.k. > collect_linuxbios_info: Found LinuxBIOS table at: 00000530 > malloc_diag: alloc: 128 bytes (3 blocks), free: 16248 bytes (1 blocks) > convert_memmap: 0x00000000000000 0x00000000000bdc 16 > convert_memmap: 0x00000000000bdc 0x0000000009f424 1 > convert_memmap: 0x000000000c0000 0x00000000030000 1 > convert_memmap: 0x000000000f0000 0x00000003f10000 1 > convert_memmap: 0x000000000f0000 0x00000000000000 16 > collect_sys_info: 0000000000000bdc-00000000000a0000 > collect_sys_info: 00000000000c0000-00000000000f0000 > collect_sys_info: 00000000000f0000-0000000004000000 > collect_sys_info: RAM 64 MB > relocate: Current location: 0x100000-0x123727 > relocate: Relocating to 0x3fdc8d0-0x3fffff7... ok > setup_timers: CPU 797 MHz > pci_init: Scanning PCI: found 6 devices > malloc_diag: alloc: 208 bytes (4 blocks), free: 16168 bytes (1 blocks) > pci_init: 00:00.0 8086:1237 0600 00 > pci_init: 00:01.0 8086:7000 0601 00 > pci_init: 00:01.1 8086:7010 0101 80 > pci_init: 00:01.3 8086:7113 0680 00 > pci_init: 00:02.0 1013:00b8 0300 00 > pci_init: 00:03.0 10ec:8029 0200 00 > Press for default boot, or for boot prompt... timed out > boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200 > malloc_diag: alloc: 280 bytes (5 blocks), free: 16096 bytes (1 blocks) > malloc_diag: alloc: 296 bytes (6 blocks), free: 16080 bytes (1 blocks) > file_open: dev=hda1, path=/vmlinuz > find_ide_controller: found PCI IDE controller 8086:7010 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 > init_drive: Testing for hda > init_drive: Probing for hda > init_drive: LBA mode, sectors=16384 > init_drive: LBA48 mode, sectors=16384 > init_drive: Init device params... ok > hda: LBA48 8192KB: QEMU HARDDISK > devopen: Partition 1 start 3020518592 length 506638 > Disk read error dev=1 drive=0 sector=3020518592 > devread: read sector failed > Disk read error dev=1 drive=0 sector=3020518594 > devread: read sector failed > Disk read error dev=1 drive=0 sector=3020518720 > devread: read sector failed > Disk read error dev=1 drive=0 sector=3020518608 > devread: read sector failed > Disk read error dev=1 drive=0 sector=3020518656 > devread: read sector failed > Unknown filesystem type > malloc_diag: alloc: 280 bytes (5 blocks), free: 16096 bytes (1 blocks) > malloc_diag: alloc: 208 bytes (4 blocks), free: 16168 bytes (1 blocks) > boot: hda:/vmlinuz console=ttyS0 > malloc_diag: alloc: 248 bytes (5 blocks), free: 16128 bytes (1 blocks) > malloc_diag: alloc: 264 bytes (6 blocks), free: 16112 bytes (1 blocks) > file_open: dev=hda, path=/vmlinuz > Mounted fat > malloc_diag: alloc: 248 bytes (5 blocks), free: 16128 bytes (1 blocks) > elf_load: Not a bootable ELF image > malloc_diag: alloc: 264 bytes (6 blocks), free: 16112 bytes (1 blocks) > file_open: dev=hda, path=/vmlinuz > devopen: already open > malloc_diag: alloc: 248 bytes (5 blocks), free: 16128 bytes (1 blocks) > Found Linux version 2.6.15-1.2054_FC5 > (bhcompile at hs20-bc1-2.build.redhat.com) #1 Tue Mar 14 15:48:03 EST > 2006 (protocol 0x204) (loadflags 0x1) bzImage. > init_linux_params: Setting up paramters at 0x90000 > set_memory_size: 0000000000000bdc - 00000000000a0000 > set_memory_size: 00000000000c0000 - 00000000000f0000 > set_memory_size: 00000000000f0000 - 0000000004000000 > set_memory_size: ramtop=0x4000000 > set_memory_size: ext_mem_k=64512, alt_mem_k=64512 > parse_command_line: original command line: "console=ttyS0" > parse_command_line: kernel command line at 0x91000 > parse_command_line: kernel command line (13 bytes): "console=ttyS0" > load_linux_kernel: offset=0x2000 addr=0x100000 size=0x16d7f5 > Loading kernel... ok > start_linux: eip=0x100000 > Jumping to entry point... > ----- > > At this point, even qemu becomes unresponsive, so it's hard to figure > out exactly what it's doing while running in a tight loop. The last > entry in the qemu debug log file is the "Load new stack segment with > new GDT" movl instruction in __switch_context: > > ----- > 0x03fe3213: pop %ebx > 0x03fe3214: sub $0x106943,%ebx > 0x03fe321a: cli > 0x03fe321b: mov %esp,%esi > 0x03fe321d: sub %ebx,%esi > 0x03fe321f: xchg %esi,0x109700(%ebx) > 0x03fe3225: add %ebx,%esi > 0x03fe3227: movzwl (%esi),%edx > 0x03fe322a: mov 0x14(%esi),%eax > 0x03fe322d: lgdtl 0x2(%esi) > 0x03fe3231: mov %edx,%ss > ----- > > I've also tried an older qemu (0.7.2), an older LinuxBIOS (svn 2302) > and an older kernel (2.4.something from Fedora Core 1), all with the > same result. > > Any suggestions would be appreciated. > > --Ed > From ollie at lanl.gov Tue Sep 5 19:22:28 2006 From: ollie at lanl.gov (ollie) Date: Tue, 05 Sep 2006 11:22:28 -0600 Subject: [LinuxBIOS] VGA bios and i/o access for powerpc In-Reply-To: <44FD5582.7030205@yahoo.fr> References: <44FD5582.7030205@yahoo.fr> Message-ID: <1157476948.2099.4.camel@logarithm.lanl.gov> On Tue, 2006-09-05 at 12:46 +0200, jf simon wrote: > Hi, > I have read the excellent paper on FreeVGA > http://www.linuxbios.org/data/vgabios/ > > and I am thinking on using it on a powerpc design we have made based on > IBM 970fx ppc64 CPU (after it runs linuxbios of course, but I am trying > to plan ahead and see what is needed to have PCI graphic cards running > on it). > I have looked at the x86emu code, and more precisely to the > X86EMU_pioFuncs function which is in charge of I/O accesses whenever > the VGA BIOS makes an x86 int/out instruction to some I/O port (for > example to the range of VGA control registers in the 0x3XX region). The > graphic I intend to use is an ATI Radeon RV100 PCI card. So it looks > like I will have to program the X86EMU_pioFuncs with a function that > will redirect I/O accesses from the low 0x3XX addresses, to the ATI PCI > I/O region that contains VGA registers. Here is an excerpt of an "lspci > -vv" on my graphic card (see below). I am planning to re-direct all > these I/O accesses to the region 1 (I/O ports at f4015000). The VGA > registers have to be in there...where else? > So it shouldn't be too hard. Am I overlooking things? The FreeVGA paper > said he should be rather complicated to do on powerpc....so i may be to > optimistic > > Those legacy IO ports are NOT necessary mapped to the PCI IO address. Some VGA card does and some others come with some kind of remapping or offset. Your system chipset should have a way to map legacy VGA IO ports to memory address. You have to read the doc to the PPC chipset carefully to find it out. Ollie From ollie at lanl.gov Tue Sep 5 19:33:42 2006 From: ollie at lanl.gov (ollie) Date: Tue, 05 Sep 2006 11:33:42 -0600 Subject: [LinuxBIOS] LinuxBIOS on a SIS 650 / SIS 691 laptop? In-Reply-To: <20060903110230.GC28740@coresystems.de> References: <20060903000350.GC27909@aragorn> <20060903110230.GC28740@coresystems.de> Message-ID: <1157477622.2099.9.camel@logarithm.lanl.gov> On Sun, 2006-09-03 at 13:02 +0200, Stefan Reinauer wrote: > * Uwe Hermann [060903 02:03]: > > The Super IO (PC87393) shouldn't be a problem (yes, the laptop has a > > serial port, fortunately). Using flashrom doesn't work as there's no > > support for the SIS 650/691. I tried using the SIS 630/950 code, > > but that fails... > > > > Does anybody have datasheets for these parts? > > If so they would not be allowed to pass it to you unless they hire you. > But you could try to get them yourself. Maybe Ollie Lho can help you? He > worked for SIS in his earlier life. > They definitely won't release their docs without lot of hassles. I don't even know if they are still interested in anything related to Linux. You can still try anyway. Ollie From gfiala at s.netic.de Tue Sep 5 19:55:19 2006 From: gfiala at s.netic.de (Guido Fiala) Date: Tue, 5 Sep 2006 19:55:19 +0200 Subject: [LinuxBIOS] LinuxBIOS on Laptops. In-Reply-To: <44FB6136.3050605@onelabs.com> References: <20060829162747.GA25404@aragorn> <200609030908.20653.gfiala@s.netic.de> <44FB6136.3050605@onelabs.com> Message-ID: <200609051955.20254.gfiala@s.netic.de> On Monday 04 September 2006 01:11, Bari Ari wrote: > Look for laptops that have the firmware Flash write enable lines > controlled only by the chipset and not also by the keyboard/system > management controller. This will allow a developer to rewrite the Flash > with LinuxBIOS. Most efforts to port LinuxBIOS on laptops in the past > could not get past this hurdle. > > Designing and manufacturing for a laptop for mass market using LinuxBIOS > is simple. The bill of material and hardware design are the same as a > laptop using a closed source BIOS. Laptop mainboards are typically > manufactured in high volumes in single runs (much the same as > desktop/platform mainboards). The LinuxBIOS would be developed for the > mainboard during the design stage of the project and then programmed > into the flash before manufacture or after the flash devices are > installed on the boards. > > There hasn't been much demand for laptops to have LinuxBIOS yet. The > first major project to demand LinuxBIOS on a laptop has probably been > the OLPC project. I doubt if Quanta had much experience with or > knowledge of LinuxBIOS before OLPC. I was thinking more along the way, how hardware could be simplified on one side and at the same time enhanced by nice-to-have features. Just some ideas: +Large enough (partitioned) Flash(s) already on the board +as low as possible number of parts +get rid of stone-age hardware and replace with modern parts +new concepts to replace error prone complex initialisation sequences +combine just the best of the best (with options to scale on purpose) +open, fully documented standards +KISS =a more advanced PC/Laptop/Node...whatever (IMHO) --- As my original post got accidently PM, here what i wrote before that mail: > The chipset docs may all be available but not docs to the power > management/keyboard scan controller firmware. The docs for the micros > describe the general purpose micro itself, but that won't tell you how > they are using all of its gpio pins and ports. Isn't that a pity? Those parts are not the complex parts, it are the most simple parts and some of them are just to control hardware that is available for eons as a standard. In the age of USB i wonder if we still need a keyboard/mouse controller for other than that. (i mean: why not just USB without PS2? Why COM,LPT? ) How would a (linux) mainboard look like? Is there a parts list, e.g. one for desktop, one for laptop that would be great? Maybe, just maybe, one of the manufacturers takes a deep breath... Or just maybe they notice, that the selection of parts is so carefully optimized, that it would be great to do it that way for a decent windows PC as well. - (As for the price of energy i would say, both should only use mobile-hardware) I'am reading at that least for a while and i got the feeling, that most hardware is not support, only a few work fully - i liked to have it for my Centrino-Mini-itx but the memory controller is a problem, howe does it look now for turion based mini-itx-systems? (I use those as a desktop pc because they use so little energy to run and are fast anyway - beside such a tiny little box is not so intrusive in the living room ;-) Part of the problem is certainly the very difficult installation and the risk of failure - i once fried a mainboard while updating the standard flash with an update from the manufacturer - it just stopped half way through. I got a replacement part, let it flash somewhere else but it didn't help. Though i work in embedded control area, flashing ECU's without trouble hundred times a day. Those ECU's are designed in a way, that they can even be reflashed when the flash-process interrupted __anywhere__ - despite the propability that this feature is actually required out there in the field is very low, maybe once in the lifetime of a car. The (missing) content of the flash can be delivered via certain serial line protocols during the flashing process from an external hardware/software (K-Line, CAN, ...) - wouldn't that be a nice thing to have for Linux as well? From jfaslist at yahoo.fr Tue Sep 5 20:02:03 2006 From: jfaslist at yahoo.fr (jean-francois simon) Date: Tue, 5 Sep 2006 20:02:03 +0200 (CEST) Subject: [LinuxBIOS] RE : Re: VGA bios and i/o access for powerpc In-Reply-To: <1157476948.2099.4.camel@logarithm.lanl.gov> Message-ID: <20060905180203.6365.qmail@web27512.mail.ukl.yahoo.com> Those legacy IO ports are NOT necessary mapped to the PCI IO address. Some VGA card does and some others come with some kind of remapping or offset. Your system chipset should have a way to map legacy VGA IO ports to memory address. You have to read the doc to the PPC chipset carefully to find it out. I have read the chipset doc and there is no such VGA support. But could you plse explain more on the different ways for VGA cards to map the VGA registers? Since the registers are located on a PCI agent (the graphic card), there must be a way to access them by generating PCI cycles? Thanks -jf simon --------------------------------- D?couvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/R?ponses pour partager vos connaissances, vos opinions et vos exp?riences. Cliquez ici. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bari at onelabs.com Tue Sep 5 20:51:53 2006 From: bari at onelabs.com (Bari Ari) Date: Tue, 05 Sep 2006 13:51:53 -0500 Subject: [LinuxBIOS] Why LinuxBIOS is Better Message-ID: <44FDC749.2090801@onelabs.com> Rogelio Serrano wrote: > On 9/3/06, Kevin Purcell wrote: > >> (not a troll) >> >> What would be the selling point to the laptop maker of using LinuxBIOS? >> >> Why would they want LinuxBIOS rather than buying (and modifying) a >> solution from a commercial BIOS company and their CPU/chipset(s) >> suppliers? >> > > many things that go beyond the bios. you cant make an argument with > the bios alone. you have to show what an open bios would bring and > actually link that to higher sales. for example if it allows > ubiquitous computing where you would rather use your laptop instead of > pen and paper then that would be convincing. instant accessibility is > a very big thing now. ... if your pc can bootup in 3 seconds > that changes a whole lot of things. Some selling points might include: LinuxBIOS is a much lower cost solution than commercial BIOSes. LinuxBIOS has no royalty fees, no cost for source or software development tools. LinuxBIOS is technically superior to commercial BIOSes. LinuxBIOS is written almost entirely in C. LinuxBIOS operates mainly in 32 bit mode. LinuxBIOS offers faster boot times than commercial BIOSes. LinuxBIOS has lower complexity than commercial BIOSes. LinuxBIOS has lower latencies than commercial BIOSes. LinuxBIOS is far better at detecting and configuring hardware than commercial BIOSes. LinuxBIOS can load a kernel over any device, network, protocol, and file system that Linux supports. LinuxBIOS supports low level cryptographic support for strong pre-boot authentication, secure remote console support and secure configuration management. LinuxBIOS is easier to develop than commercial BIOSes. LinuxBIOS is easier to maintain than commercial BIOSes. LinuxBIOS is released under GPL. LinuxBIOS is more fun, does not cause cancer and allows you to sleep at night. (feel free for anyone else to chime in here) Commercial BIOSes have royalty fees, high costs for source and software development tools. Commercial BIOSes are mostly written in assembler, operate mostly in 16 bit mode, and provides services that few modern 32 bit operating systems require. Commercial BIOSes have long boot times. Commercial BIOSes are complex and have long latencies. The ACL team found that commercial BIOSes do a poor job of setting up a PC for modern OSes. They found: Commercial BIOSes configure memory in a suboptimal way. For example, some BIOSes were discovered to use memory capable of CAS2 speeds at a much slower CAS3 setting. Commercial BIOSes incorrectly configured PCI address spaces that opened up security holes when memory-mapped cards (e.g. Myrinet) were used. Commercial BIOSes had suboptimal assignments of interrupt requests. Some BIOSes were found to share IRQs between multiple devices when such sharing was not required. This sharing of IRQs added latency upon interrupts needlessly. Commercial BIOSes incorrectly configured BIOS tables such as the $PIR table, so that the critical information Linux needs for IRQ assignment was not available. So pervasive are some of the errors that they have impacted the Linux 2.4.19 kernel; in this version, GEODE IRQ setup was changed, incorrectly, to accommodate some broken motherboards. Commercial BIOSes had incorrect ID strings, for example the string``Mainboard vendor name here'' was in the BIOS instead of the mainboard vendor name. Commercial BIOSes had no way to upgrade the BIOS from a modern OS (some vendors shipped DOS diskettes for a BIOS upgrade; others required that you boot a Windows 3.1 CD and run an upgrade program). Commercial BIOSes had no way to preserve CMOS settings when a BIOS is upgraded (one vendor recommended we record the settings on paper and then re-enter them for each machine; a difficult task on a 960-node system with no keyboard or console). Commercial BIOSes also have structural problems that derive from therequirements for supporting DOS. One of these is the requirement that the BIOS zero memory. This requirement makes postmortem debugging virtually impossible, as a reset results in erasing the memory image of the previously running operating system. Commercial BIOSes also have problems accommodating custom built hardware, and can take considerable time to boot. Commercial BIOS bugs or errors are almost impossible to fix. (feel free for anyone else to chime in here again) Bari From stepan at coresystems.de Tue Sep 5 21:50:08 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 5 Sep 2006 21:50:08 +0200 Subject: [LinuxBIOS] LinuxBIOS+FILO hangs on qemu In-Reply-To: References: <13426df10609041703o7969c01fq23d20d42c550ee69@mail.gmail.com> Message-ID: <20060905195008.GA16200@coresystems.de> * Ed Swierk [060905 03:35]: > I'll start digging into the instructions on wiki.laptop.org for > building the OLPC LinuxBIOS. Any idea what configuration parameters > I'd need to twiddle in emulation/qemu-i386/Config.lb to build the > proper size image for qemu? Richard described how to do this. Qemu can cope with different sizes of "flash". It can do 64k-512k for sure, but I am not sure about 1M. If it does not work, contact Fabrice Bellard or try to find the lines that read the rom. It should be a minor change. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Tue Sep 5 21:54:55 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 5 Sep 2006 21:54:55 +0200 Subject: [LinuxBIOS] LinuxBIOS+FILO hangs on qemu In-Reply-To: <44FDAC9D.8030906@yahoo.com> References: <44FDAC9D.8030906@yahoo.com> Message-ID: <20060905195455.GB16200@coresystems.de> * Roman Kononov [060905 18:58]: > Maybe this will help: > http://sourceforge.net/mailarchive/forum.php?thread_id=10216054&forum_id=48022 > > Roman Thanks a lot! Commited! -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From smithbone at gmail.com Tue Sep 5 22:42:46 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 5 Sep 2006 15:42:46 -0500 Subject: [LinuxBIOS] LinuxBIOS+FILO hangs on qemu In-Reply-To: <20060905195455.GB16200@coresystems.de> References: <44FDAC9D.8030906@yahoo.com> <20060905195455.GB16200@coresystems.de> Message-ID: <8a0c36780609051342p3eefe626p27e014899da8c229@mail.gmail.com> On 9/5/06, Stefan Reinauer wrote: > * Roman Kononov [060905 18:58]: > > Maybe this will help: > > http://sourceforge.net/mailarchive/forum.php?thread_id=10216054&forum_id=48022 > > So is etherboot mantaining its own copy of FILO now? -- Richard A. Smith From stepan at coresystems.de Tue Sep 5 22:47:04 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 5 Sep 2006 22:47:04 +0200 Subject: [LinuxBIOS] LinuxBIOS+FILO hangs on qemu In-Reply-To: <8a0c36780609051342p3eefe626p27e014899da8c229@mail.gmail.com> References: <44FDAC9D.8030906@yahoo.com> <20060905195455.GB16200@coresystems.de> <8a0c36780609051342p3eefe626p27e014899da8c229@mail.gmail.com> Message-ID: <20060905204704.GA21624@coresystems.de> * Richard Smith [060905 22:42]: > On 9/5/06, Stefan Reinauer wrote: > >* Roman Kononov [060905 18:58]: > >> Maybe this will help: > >> > >http://sourceforge.net/mailarchive/forum.php?thread_id=10216054&forum_id=48022 > >> > > So is etherboot mantaining its own copy of FILO now? Since a while. Yinghai created the possibility to have both filo and etherboot as a payload as far as I can tell. He also added SATA and USB to Filo/Etherboot, which I backported to the "official Filo" that features a lot of other things that Filo/Etherboot does not do (grub menus for example) Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Tue Sep 5 22:50:25 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 5 Sep 2006 22:50:25 +0200 Subject: [LinuxBIOS] LinuxBIOS+FILO hangs on qemu In-Reply-To: References: Message-ID: <20060905205025.GB21624@coresystems.de> * Ed Swierk [060904 20:22]: > hda: LBA48 8192KB: QEMU HARDDISK > devopen: Partition 1 start 3020518592 length 506638 > Disk read error dev=1 drive=0 sector=3020518592 > devread: read sector failed Nasty. The Filo IDE driver makes some assumptions about the IDE hw that QEMU does not fulfill. I am not particularly familiar with that code, but I know the OpenBIOS IDE driver works on QEMU. It might be worth porting that fine driver written by the famous kernel hacker Jens Axboe. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From smithbone at gmail.com Tue Sep 5 22:54:25 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 5 Sep 2006 15:54:25 -0500 Subject: [LinuxBIOS] LinuxBIOS+FILO hangs on qemu In-Reply-To: <20060905204704.GA21624@coresystems.de> References: <44FDAC9D.8030906@yahoo.com> <20060905195455.GB16200@coresystems.de> <8a0c36780609051342p3eefe626p27e014899da8c229@mail.gmail.com> <20060905204704.GA21624@coresystems.de> Message-ID: <8a0c36780609051354v41b4f432x88a30a7b0ca2d804@mail.gmail.com> > Since a while. Yinghai created the possibility to have both filo and > etherboot as a payload as far as I can tell. He also added SATA and USB > to Filo/Etherboot, which I backported to the "official Filo" that > features a lot of other things that Filo/Etherboot does not do (grub > menus for example) Thanks. Just making sure I didn't lose track of where the official FILO was. -- Richard A. Smith From acassis at gmail.com Tue Sep 5 23:23:08 2006 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Tue, 5 Sep 2006 15:23:08 -0600 Subject: [LinuxBIOS] Flashrom is not detecting 2MiB flash Message-ID: <37367b3a0609051423r73d291bcw61cd12e6a9819f40@mail.gmail.com> Hi LinuxBIOS' hackers, I am trying to get a SST49LF160C (ID1=0xbf and ID2=0x4c) working on my MB (chipset VIA8237), but I get a strange error. If the flash_probe (probe_jedec) attempt to detect flash more than 512KB it don't get the flash IDs. Some time ago I see a Ron mail about MB can detect until 2MiB flash with no problem, but I don't know why it is not working them. I added these lines to flashchips.c: {"SST49LF160C", SST_ID, SST_49LF160C, NULL, 2048, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec, NULL}, Someone know why my MB doesn't detect flash it this size is more than 512MB? Look to flashrom output: diderot:/home/alan/LinuxBIOSv2/util/flashrom# ./flashrom -V Calibrating delay loop... Setting up microsecond timing loop 781M loops per second ok No LinuxBIOS table found. Enabling flash write on VT8235...OK Trying Am29F040B, 512 KB probe_29f040b: id1 0xbf, id2 0x4c Trying Am29F016D, 2048 KB probe_29f040b: id1 0xff, id2 0xff Trying At29C040A, 512 KB probe_jedec: id1 0xbf, id2 0x4c Trying AT49LH002, 256 KB probe_jedec: id1 0xbf, id2 0x4c Trying Mx29f002, 256 KB probe_29f002: id1 0xbf, id2 0x4c Trying SST29EE020A, 256 KB probe_jedec: id1 0xbf, id2 0x4c Trying SST28SF040A, 512 KB probe_28sf040: id1 0xbf, id2 0x4c Trying SST39SF020A, 256 KB probe_jedec: id1 0xbf, id2 0x4c Trying SST39VF020, 256 KB probe_jedec: id1 0xbf, id2 0x4c Trying SST49LF040B, 512 KB probe_jedec: id1 0xbf, id2 0x4c Trying SST49LF040, 512 KB probe_jedec: id1 0xbf, id2 0x4c Trying SST49LF080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Trying SST49LF160C, 2048 KB probe_jedec: id1 0xff, id2 0xff Trying SST49LF002A/B, 256 KB probe_jedec: id1 0xbf, id2 0x4c Trying SST49LF003A/B, 384 KB probe_jedec: id1 0xbf, id2 0x4c Trying SST49LF004A/B, 512 KB probe_jedec: id1 0xbf, id2 0x4c Trying SST49LF008A, 1024 KB probe_jedec: id1 0xff, id2 0xff Trying Pm49FL004, 512 KB probe_jedec: id1 0xbf, id2 0x4c Trying W29C011, 128 KB probe_jedec: id1 0xbf, id2 0x4c Trying W29C020C, 256 KB probe_jedec: id1 0xbf, id2 0x4c Trying W49F002U, 256 KB probe_jedec: id1 0xbf, id2 0x4c Trying W39V040A, 512 KB probe_jedec: id1 0xbf, id2 0x4c Trying M29F040B, 512 KB probe_29f040b: id1 0xbf, id2 0x4c Trying M29F400BT, 512 KB probe_m29f400bt: id1 0xbf, id2 0xbf Trying 82802ab, 512 KB probe_82802ab: id1 0xbf, id2 0x4c Trying 82802ac, 1024 KB probe_82802ab: id1 0xff, id2 0xff Trying LHF00L04, 1024 KB probe_lhf00l04: id1 0xff, id2 0xff No EEPROM/flash device found. diderot:/home/alan/LinuxBIOSv2/util/flashrom# Cheers, -- ------------------------------------------------------------ | Alan Carvalho de Assis | ------------------------------------------------------------ -- N?o importa o que os outros ir?o pensar, A cura para a infelicidade ? a felicidade -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at lanl.gov Tue Sep 5 22:53:16 2006 From: ollie at lanl.gov (ollie) Date: Tue, 05 Sep 2006 14:53:16 -0600 Subject: [LinuxBIOS] RE : Re: VGA bios and i/o access for powerpc In-Reply-To: <20060905180203.6365.qmail@web27512.mail.ukl.yahoo.com> References: <20060905180203.6365.qmail@web27512.mail.ukl.yahoo.com> Message-ID: <1157489596.2099.12.camel@logarithm.lanl.gov> On Tue, 2006-09-05 at 20:02 +0200, jean-francois simon wrote: > Those legacy IO ports are NOT necessary mapped to the PCI IO > address. > Some VGA card does and some others come with some kind of > remapping > or offset. Your system chipset should have a way to map legacy > VGA IO > ports to memory address. You have to read the doc to the PPC > chipset > carefully to find it out. > > I have read the chipset doc and there is no such VGA support. > But could you plse explain more on the different ways for VGA cards to > map the VGA registers? Since the registers are located on a PCI agent > (the graphic card), there must be a way to access them by generating > PCI cycles? > Thanks I don't know how exactly those legacy IO address is implemented by the HW and/or the bus protocol. But the Appendix G of PCI sepc says it is possible for PCI device to decode those legacy ports independent of the base address register. Ollie > From eswierk at arastra.com Wed Sep 6 00:11:54 2006 From: eswierk at arastra.com (Ed Swierk) Date: Tue, 5 Sep 2006 15:11:54 -0700 Subject: [LinuxBIOS] LinuxBIOS+FILO hangs on qemu In-Reply-To: <44FDAC9D.8030906@yahoo.com> References: <44FDAC9D.8030906@yahoo.com> Message-ID: On 9/5/06, Roman Kononov wrote: > Maybe this will help: > http://sourceforge.net/mailarchive/forum.php?thread_id=10216054&forum_id=48022 Bingo! Works like a charm. Thanks! --Ed From ollie at lanl.gov Wed Sep 6 01:20:49 2006 From: ollie at lanl.gov (ollie) Date: Tue, 05 Sep 2006 17:20:49 -0600 Subject: [LinuxBIOS] Flashrom is not detecting 2MiB flash In-Reply-To: <37367b3a0609051423r73d291bcw61cd12e6a9819f40@mail.gmail.com> References: <37367b3a0609051423r73d291bcw61cd12e6a9819f40@mail.gmail.com> Message-ID: <1157498449.1854.2.camel@logarithm.lanl.gov> On Tue, 2006-09-05 at 15:23 -0600, Alan Carvalho de Assis wrote: > Hi LinuxBIOS' hackers, > I am trying to get a SST49LF160C (ID1=0xbf and ID2=0x4c) working on my > MB (chipset VIA8237), but I get a strange error. > > If the flash_probe (probe_jedec) attempt to detect flash more than > 512KB it don't get the flash IDs. > > Some time ago I see a Ron mail about MB can detect until 2MiB flash > with no problem, but I don't know why it is not working them. > > I added these lines to flashchips.c: > > {"SST49LF160C", SST_ID, SST_49LF160C, NULL, 2048, 64 * 1024, > probe_jedec, erase_chip_jedec, write_jedec, NULL}, > > Someone know why my MB doesn't detect flash it this size is more than > 512MB? > There is some register in the chipset which control how large of the flash rom address are writable. Your mainboard probably only enabled 256kB of rom address so flash rom have problem working on a 512kB flash part. Ollie From acassis at gmail.com Wed Sep 6 02:04:43 2006 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Tue, 5 Sep 2006 18:04:43 -0600 Subject: [LinuxBIOS] Flashrom is not detecting 2MiB flash In-Reply-To: <1157498449.1854.2.camel@logarithm.lanl.gov> References: <37367b3a0609051423r73d291bcw61cd12e6a9819f40@mail.gmail.com> <1157498449.1854.2.camel@logarithm.lanl.gov> Message-ID: <37367b3a0609051704l7f6e7db0y7beab7e5243dcc89@mail.gmail.com> Hi Ollie, On 9/5/06, ollie wrote: > There is some register in the chipset which control how large of the > flash rom address are writable. Your mainboard probably only enabled > 256kB of rom address so flash rom have problem working on a 512kB > flash part. Is possible to figure out it? Some idea how can I fix it? Thank you, Ollie Alan -- ------------------------------------------------------------ | Alan Carvalho de Assis | ------------------------------------------------------------ -- N?o importa o que os outros ir?o pensar, A cura para a infelicidade ? a felicidade -------------- next part -------------- An HTML attachment was scrubbed... URL: From bari at onelabs.com Wed Sep 6 02:15:47 2006 From: bari at onelabs.com (Bari Ari) Date: Tue, 05 Sep 2006 19:15:47 -0500 Subject: [LinuxBIOS] Flashrom is not detecting 2MiB flash In-Reply-To: <1157498449.1854.2.camel@logarithm.lanl.gov> References: <37367b3a0609051423r73d291bcw61cd12e6a9819f40@mail.gmail.com> <1157498449.1854.2.camel@logarithm.lanl.gov> Message-ID: <44FE1333.2010203@onelabs.com> ollie wrote: > On Tue, 2006-09-05 at 15:23 -0600, Alan Carvalho de Assis wrote: > >> Hi LinuxBIOS' hackers, >> I am trying to get a SST49LF160C (ID1=0xbf and ID2=0x4c) working on my >> MB (chipset VIA8237), but I get a strange error. >> >> If the flash_probe (probe_jedec) attempt to detect flash more than >> 512KB it don't get the flash IDs. >> >> Some time ago I see a Ron mail about MB can detect until 2MiB flash >> with no problem, but I don't know why it is not working them. >> >> I added these lines to flashchips.c: >> >> {"SST49LF160C", SST_ID, SST_49LF160C, NULL, 2048, 64 * 1024, >> probe_jedec, erase_chip_jedec, write_jedec, NULL}, >> >> Someone know why my MB doesn't detect flash it this size is more than >> 512MB? >> >> > There is some register in the chipset which control how large of the > flash rom address are writable. Your mainboard probably only enabled > 256kB of rom address so flash rom have problem working on a 512kB > flash part. > > Ollie > You're probably going to need access to the VT8237 programming guide. You are going to run into issues with the VT8237 accessing address space with block locking registers in the SST49LF160C or SST49LF016C. Are you sure the SST49LF160C follows jedec routines completely? I seem to recall the SST 16Mb parts vary some. Bari From stuge-linuxbios at cdy.org Wed Sep 6 06:30:46 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Wed, 6 Sep 2006 06:30:46 +0200 Subject: [LinuxBIOS] EPIA-MII 6000E 115k2, VGA and FILO on first flash Message-ID: <20060906043046.20515.qmail@cdy.org> I picked up an EPIA-MII board a while ago and some 4Mbit flash today. I put together a linuxbios.rom in a few hours, then booted LB after one hotswap flash. It is simply amazing. Thank you, everyone who have, and continue to, put effort into LinuxBIOS, FILO and Etherboot! I'll try to get the board into my car before the symposium. //Peter -------------- next part -------------- 0 LinuxBIOS-1.1.8.0Fallback Tue Sep 5 05:23:39 CEST 2006 starting... Enabling mainboard devices Enabling shadow ram vt8623 init starting Detecting Memory Number of Banks 04 Number of Rows 0d Priamry DRAM width08 No Columns 0a MA type e0 Bank 0 (*16 Mb) 10 No Physical Banks 01 Total Memory (*16 Mb) 10 CAS Supported 2 2.5 3 Cycle time at CL X (nS)50 Cycle time at CL X-0.5 (nS)60 Cycle time at CL X-1 (nS)75 Starting at CAS 3 We can do CAS 2.5 We can do CAS 2 tRP 3c tRCD 3c tRAS 28 Low Bond 00 High Bondb2 Setting DQS delay76vt8623 done 00:06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00 10:08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00 20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00 50:c8 de cf 88 e0 07 00 00 e0 00 10 10 10 10 00 00 60:02 ff 00 30 52 32 01 38 42 2d 43 58 00 44 00 00 70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 00 12 80:0f 61 00 00 80 00 00 00 02 00 00 00 00 00 00 00 90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0:02 c0 20 00 07 02 00 1f 04 00 00 00 2f 02 04 00 b0:00 00 00 00 80 00 00 00 8a 00 00 00 00 00 00 00 c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0:00 dd 00 00 00 00 01 00 40 00 00 00 00 00 00 00 f0:00 00 00 00 00 00 11 13 00 00 00 00 00 00 00 00 AGP Doing MTRR init. Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.8.0Fallback Tue Sep 5 05:23:39 CEST 2006 booting... clocks_per_usec: 930 Enumerating buses... Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled APIC_CLUSTER: 0 enabled PCI: pci_scan_bus for bus 0 PCI: 00:00.0 [1106/3123] enabled PCI: 00:01.0 [1106/b091] enabled PCI: 00:0a.0 [1180/0476] enabled PCI: 00:0a.1 [1180/0476] enabled In vt8235_enable 1106 3038. PCI: 00:10.0 [1106/3038] enabled In vt8235_enable 1106 3038. PCI: 00:10.1 [1106/3038] enabled In vt8235_enable 1106 3038. PCI: 00:10.2 [1106/3038] enabled In vt8235_enable 1106 3104. PCI: 00:10.3 [1106/3104] enabled In vt8235_enable 1106 3177. Initialising Devices PCI: 00:11.0 [1106/3177] enabled In vt8235_enable 1106 0571. PCI: 00:11.1 [1106/0571] enabled In vt8235_enable 1106 3059. PCI: 00:11.5 [1106/3059] enabled In vt8235_enable ffff ffff. In vt8235_enable 1106 3065. PCI: 00:12.0 [1106/3065] enabled PCI: pci_scan_bus for bus 1 PCI: 01:00.0 [1106/3122] enabled PCI: pci_scan_bus returning with max=01 PCI: pci_scan_bus for bus 2 PCI: pci_scan_bus returning with max=02 PCI: pci_scan_bus for bus 3 PCI: pci_scan_bus returning with max=03 vt1211 enabling PNP devices. PNP: 002e.0 enabled vt1211 enabling PNP devices. PNP: 002e.1 enabled vt1211 enabling PNP devices. PNP: 002e.2 enabled vt1211 enabling PNP devices. PNP: 002e.3 enabled vt1211 enabling PNP devices. PNP: 002e.b enabled PCI: pci_scan_bus returning with max=03 done Allocating resources... Reading resources... Done reading resources. Setting resources... I would set ram size to 0x40000 Kbytes PCI: 00:0a.0 In set resources PCI: 00:0a.0 10 <- [0x00febfb000 - 0x00febfbfff] mem PCI: 00:0a.0 2c <- [0x0000001870 - 0x000000286f] io PCI: 00:0a.0 34 <- [0x0000002870 - 0x000000386f] io PCI: 00:0a.0 1c <- [0x00f6bfb000 - 0x00f8bfafff] prefmem PCI: 00:0a.0 24 <- [0x00f8bfb000 - 0x00fabfafff] mem PCI: 00:0a.1 In set resources PCI: 00:0a.1 1 ==> febfc000 PCI: 00:0a.1 10 <- [0x00febfd000 - 0x00febfdfff] mem PCI: 00:0a.1 2c <- [0x0000003870 - 0x000000486f] io PCI: 00:0a.1 34 <- [0x0000004870 - 0x000000586f] io PCI: 00:0a.1 1c <- [0x00fabfb000 - 0x00fcbfafff] prefmem PCI: 00:0a.1 24 <- [0x00fcbfb000 - 0x00febfafff] mem PCI: 00:10.0 20 <- [0x0000001800 - 0x000000181f] io PCI: 00:10.1 20 <- [0x0000001820 - 0x000000183f] io PCI: 00:10.2 20 <- [0x0000001840 - 0x000000185f] io PCI: 00:10.3 10 <- [0x00febfe000 - 0x00febfe0ff] mem PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] io PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] io PNP: 002e.1 70 <- [0x0000000007 - 0x0000000007] irq PNP: 002e.1 74 <- [0x0000000003 - 0x0000000003] drq PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq PNP: 002e.3 60 <- [0x00000002f8 - 0x00000002ff] io PNP: 002e.3 70 <- [0x0000000003 - 0x0000000003] irq PNP: 002e.b 60 <- [0x000000ec00 - 0x000000ecff] io PCI: 00:11.1 20 <- [0x0000001860 - 0x000000186f] io PCI: 00:11.5 10 <- [0x0000001000 - 0x00000010ff] io PCI: 00:12.0 10 <- [0x0000001400 - 0x00000014ff] io PCI: 00:12.0 14 <- [0x00febff000 - 0x00febff0ff] mem Done setting resources. Done allocating resources. Enabling resources... PCI: 00:00.0 cmd <- 146 PCI: 00:01.0 bridge ctrl <- 000f PCI: 00:01.0 cmd <- 147 PCI: 01:00.0 cmd <- 140 PCI: 00:0a.0 bridge ctrl <- 0503 PCI: 00:0a.0 cmd <- 143 PCI: 00:0a.1 bridge ctrl <- 0503 PCI: 00:0a.1 cmd <- 143 PCI: 00:10.0 subsystem <- 00/00 PCI: 00:10.0 cmd <- 141 PCI: 00:10.1 subsystem <- 00/00 PCI: 00:10.1 cmd <- 141 PCI: 00:10.2 subsystem <- 00/00 PCI: 00:10.2 cmd <- 141 PCI: 00:10.3 subsystem <- 00/00 PCI: 00:10.3 cmd <- 142 PCI: 00:11.0 cmd <- 147 PNP: 002e.0 - enabling PNP: 002e.1 - enabling PNP: 002e.2 - enabling PNP: 002e.3 - enabling PNP: 002e.b - enabling PCI: 00:11.1 cmd <- 147 PCI: 00:11.5 subsystem <- 00/00 PCI: 00:11.5 cmd <- 141 PCI: 00:12.0 cmd <- 1c3 done. Initializing devices... Root Device init PCI: 00:10.0 init PCI: 00:10.1 init PCI: 00:10.2 init PCI: 00:10.3 init PCI: 00:11.0 init vt8235 init RTC Init Invalid CMOS LB checksum pci_routing_fixup: dev is 00010200 setting firewire setting usb Assigning IRQ 5 to 0:10.0 Readback = 5 pci_level_irq: lower order bits are wrong: want 0x0, got 0x20 Assigning IRQ 9 to 0:10.1 Readback = 9 pci_level_irq: lower order bits are wrong: want 0x0, got 0x20 Assigning IRQ 9 to 0:10.2 Readback = 9 pci_level_irq: lower order bits are wrong: want 0x0, got 0x20 Assigning IRQ 5 to 0:10.3 Readback = 5 pci_level_irq: lower order bits are wrong: want 0x0, got 0x20 setting vt8235 Assigning IRQ 5 to 0:11.1 Readback = 5 pci_level_irq: lower order bits are wrong: want 0x0, got 0x20 Assigning IRQ 9 to 0:11.5 Readback = 9 pci_level_irq: lower order bits are wrong: want 0x0, got 0x20 setting ethernet Assigning IRQ 5 to 0:12.0 Readback = 5 pci_level_irq: lower order bits are wrong: want 0x0, got 0x20 setting vga Assigning IRQ 5 to 1:0.0 Readback = 5 pci_level_irq: lower order bits are wrong: want 0x0, got 0x20 setting pci slot setting cardbus slot Assigning IRQ 5 to 0:a.0 Readback = 5 pci_level_irq: lower order bits are wrong: want 0x0, got 0x20 Assigning IRQ 5 to 0:a.1 Readback = 5 pci_level_irq: lower order bits are wrong: want 0x0, got 0x20 setting riser slot PNP: 002e.0 init PNP: 002e.1 init PNP: 002e.2 init PNP: 002e.3 init PNP: 002e.b init PCI: 00:11.1 init Enabling VIA IDE. ide_init: enabling compatibility IDE addresses enables in reg 0x42 0x0 enables in reg 0x42 read back as 0x0 enables in reg 0x40 0x3 enables in reg 0x40 read back as 0x3 enables in reg 0x9 0x8a enables in reg 0x9 read back as 0x8a command in reg 0x4 0x7 command in reg 0x4 reads back as 0x7 PCI: 00:11.5 init PCI: 00:12.0 init Configuring VIA Rhine LAN PCI: 00:0a.0 init rl5c476 init CF Base = febfc000 PCI: 00:0a.1 init rl5c476 init CF Base = febfc000 CF Config = ff APIC_CLUSTER: 0 init Initializing CPU #0 CPU: vendor Centaur device 673 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB Setting fixed MTRRs(24-88) Type: WB DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 128MB, type WB Setting variable MTRR 1, base: 128MB, range: 64MB, type WB Setting variable MTRR 2, base: 192MB, range: 32MB, type WB DONE variable MTRRs Clear out the extra MTRR's MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Disabling local apic...done. CPU #0 Initialized PCI: 00:00.0 init VT8623 random fixup ... Frame buffer at d0000000 PCI: 00:01.0 init VT8623 AGP random fixup ... PCI: 01:00.0 init VGA random fixup ... INSTALL REAL-MODE IDT DO THE VGA BIOS found VGA: vid=1106, did=3122 rom base, size: fffc0000 write_protect_vgabios bus/devfn = 0x100 biosint: INT# 0x15 biosint: eax 0x5f00 ebx 0x18538 ecx 0x17fa0 edx 0xa biosint: ebp 0x17f70 esp 0xff2 edi 0xec70 esi 0x18538 biosint: ip 0x641c cs 0xc000 flags 0x46 biosint: INT# 0x1a biosint: eax 0xb108 ebx 0x10000 ecx 0x10000 edx 0x3d5 biosint: ebp 0x17f70 esp 0xfcc edi 0xf6 esi 0x1c01b biosint: ip 0x40f0 cs 0xc000 flags 0x46 0xb108: bus 0 devfn 0x0 reg 0xf6 val 0x11 biosint: INT# 0x15 biosint: eax 0x5f02 ebx 0x18538 ecx 0x7f01 edx 0x3d5 biosint: ebp 0x17f70 esp 0xfdc edi 0x44 esi 0x1c01b biosint: ip 0x6468 cs 0xc000 flags 0x46 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x401 edx 0x112 biosint: ebp 0x17f70 esp 0xfa4 edi 0x44 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x46 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x401 edx 0x112 biosint: ebp 0x17f70 esp 0xfa4 edi 0x44 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x46 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x401 edx 0x112 biosint: ebp 0x17f70 esp 0xf92 edi 0x44 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x46 biosint: INT# 0x15 biosint: eax 0x5f02 ebx 0x10002 ecx 0x401 edx 0x0 biosint: ebp 0x17f70 esp 0xfb8 edi 0x44 esi 0x1c01b biosint: ip 0x6468 cs 0xc000 flags 0x46 biosint: INT# 0x15 biosint: eax 0x5f02 ebx 0x10002 ecx 0x401 edx 0x0 biosint: ebp 0x17f70 esp 0xfb8 edi 0x44 esi 0x1c01b biosint: ip 0x6468 cs 0xc000 flags 0x46 biosint: INT# 0x15 biosint: eax 0x5f02 ebx 0x10002 ecx 0x401 edx 0x0 biosint: ebp 0x17f70 esp 0xfb8 edi 0x44 esi 0x1c01b biosint: ip 0x6468 cs 0xc000 flags 0x46 biosint: INT# 0x15 biosint: eax 0x5f0f ebx 0x18538 ecx 0x7fa0 edx 0x3d5 biosint: ebp 0x17f70 esp 0xfee edi 0x44 esi 0x18538 biosint: ip 0x651b cs 0xc000 flags 0x6 biosint: INT# 0x15 biosint: eax 0x5f02 ebx 0x18538 ecx 0x7f01 edx 0x3d5 biosint: ebp 0x17f70 esp 0xfdc edi 0x44 esi 0x18538 biosint: ip 0x6468 cs 0xc000 flags 0x46 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x700 edx 0x112 biosint: ebp 0x10fca esp 0xf8e edi 0xac51 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x46 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x700 edx 0x112 biosint: ebp 0x10fca esp 0xf7e edi 0xb880 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x101 edx 0x112 biosint: ebp 0x10fca esp 0xf7e edi 0xb880 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x7a0 edx 0x112 biosint: ebp 0x10fca esp 0xf88 edi 0xb880 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x700 edx 0x112 biosint: ebp 0x10fca esp 0xf7e edi 0xb880 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x700 edx 0x112 biosint: ebp 0x10fca esp 0xf90 edi 0xb880 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x701 edx 0x112 biosint: ebp 0x10fca esp 0xf90 edi 0xb880 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f18 ebx 0x18538 ecx 0x7f01 edx 0x3d5 biosint: ebp 0x17f70 esp 0xfde edi 0x44 esi 0x18538 biosint: ip 0x6533 cs 0xc000 flags 0x46 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0xc01 ecx 0x300 edx 0x112 biosint: ebp 0x10fc8 esp 0xf8c edi 0xac49 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x46 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0xc01 ecx 0x300 edx 0x112 biosint: ebp 0x10fc8 esp 0xf7c edi 0xb840 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0xc01 ecx 0x101 edx 0x112 biosint: ebp 0x10fc8 esp 0xf7c edi 0xb840 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0xc01 ecx 0x3a0 edx 0x112 biosint: ebp 0x10fc8 esp 0xf86 edi 0xb840 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0xc01 ecx 0x300 edx 0x112 biosint: ebp 0x10fc8 esp 0xf7c edi 0xb840 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0xc01 ecx 0x300 edx 0x112 biosint: ebp 0x10fc8 esp 0xf8e edi 0xb840 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0xc01 ecx 0x301 edx 0x112 biosint: ebp 0x10fc8 esp 0xf8e edi 0xb840 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f06 ebx 0x18001 ecx 0x80010001 edx 0x0 biosint: ebp 0x10fd6 esp 0xfb4 edi 0x0 esi 0x146a7 biosint: ip 0x6479 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x80010000 edx 0x112 biosint: ebp 0x10fd6 esp 0xf88 edi 0x0 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x80010000 edx 0x112 biosint: ebp 0x10fd6 esp 0xf78 edi 0x0 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x80010101 edx 0x112 biosint: ebp 0x10fd6 esp 0xf78 edi 0x0 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x80010001 edx 0x112 biosint: ebp 0x10fd6 esp 0xf82 edi 0x0 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x80010000 edx 0x112 biosint: ebp 0x10fd6 esp 0xf78 edi 0x0 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x80010000 edx 0x112 biosint: ebp 0x10fd6 esp 0xf8a edi 0x0 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f01 ebx 0x10c01 ecx 0x80010001 edx 0x112 biosint: ebp 0x10fd6 esp 0xf8a edi 0x0 esi 0x1aacd biosint: ip 0x6448 cs 0xc000 flags 0x246 biosint: INT# 0x15 biosint: eax 0x5f08 ebx 0x18001 ecx 0x80010001 edx 0x0 biosint: ebp 0x10fd6 esp 0xfb4 edi 0x0 esi 0x146a7 biosint: ip 0x6485 cs 0xc000 flags 0x202 Devices initialized Copying IRQ routing tables to 0xf0000...done. Verifing copy of IRQ routing tables at 0xf0000...done Checking IRQ routing table consistency... check_pirq_routing_table() - irq_routing_table located at: 0x000f0000 done. ACPI: Writing ACPI tables at f0400... ACPI: * FACS ACPI: * DSDT @ 000f049e Length 3f0 ACPI: * FADT ACPI: added table 1/5 Length now 40 ACPI: done. Moving GDT to 0x500...ok Wrote linuxbios table at: 00000530 - 00000b4c checksum 1c33 Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 rom_stream: 0xfffd0000 - 0xfffeffff Found ELF candiate at offset 0 New segment addr 0x100000 size 0x3bfe0 offset 0xe0 filesize 0x121c8 (cleaned up) New segment addr 0x100000 size 0x3bfe0 offset 0xe0 filesize 0x121c8 New segment addr 0x13bfe0 size 0x48 offset 0x122c0 filesize 0x48 (cleaned up) New segment addr 0x13bfe0 size 0x48 offset 0x122c0 filesize 0x48 Dropping non PT_LOAD segment Dropping non PT_LOAD segment Dropping non PT_LOAD segment Loading Segment: addr: 0x0000000000100000 memsz: 0x000000000003bfe0 filesz: 0x00000000000121c8 Clearing Segment: addr: 0x00000000001121c8 memsz: 0x0000000000029e18 Loading Segment: addr: 0x000000000013bfe0 memsz: 0x0000000000000048 filesz: 0x0000000000000048 Jumping to boot code at 0x10da58 FILO version 0.5 (stuge at carepad4) Tue Sep 5 05:22:36 CEST 2006 menu: hde1:/boot/filo/menu.lst IDE channel 2 not found Press any key to continue. Press any key to continue. Press any key to continue. Press any key to continue. Press any key to continue. From jfaslist at yahoo.fr Wed Sep 6 07:47:02 2006 From: jfaslist at yahoo.fr (jean-francois simon) Date: Wed, 6 Sep 2006 07:47:02 +0200 (CEST) Subject: [LinuxBIOS] RE : Re: VGA bios and i/o access for powerpc Message-ID: <20060906054702.39098.qmail@web27508.mail.ukl.yahoo.com> Hi, Maybe there is a way to do without the emulation layer altogether: Since in our case we use PCI graphics, I can record all the PCI cycles made by the VGA BIOS to the graphic card on a BIOS based system (using a PCI analyser), put them into a listing, run a perl script on it and include them in the firmware of the non BIOS system....an redo the process whenever we need to use a different graphic which doesn't happen very often -jf simon I think a sure way is to record all the PCI cycles generated by the VGA BIOS jean-francois simon a ?crit : Those legacy IO ports are NOT necessary mapped to the PCI IO address. Some VGA card does and some others come with some kind of remapping or offset. Your system chipset should have a way to map legacy VGA IO ports to memory address. You have to read the doc to the PPC chipset carefully to find it out. I have read the chipset doc and there is no such VGA support. But could you plse explain more on the different ways for VGA cards to map the VGA registers? Since the registers are located on a PCI agent (the graphic card), there must be a way to access them by generating PCI cycles? Thanks -jf simon --------------------------------- D?couvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/R?ponses pour partager vos connaissances, vos opinions et vos exp?riences. Cliquez ici. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at coresystems.de Wed Sep 6 09:47:06 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 6 Sep 2006 09:47:06 +0200 Subject: [LinuxBIOS] EPIA-MII 6000E 115k2, VGA and FILO on first flash In-Reply-To: <20060906043046.20515.qmail@cdy.org> References: <20060906043046.20515.qmail@cdy.org> Message-ID: <20060906074706.GA7414@coresystems.de> * Peter Stuge [060906 06:30]: > I picked up an EPIA-MII board a while ago and some 4Mbit flash today. > > It is simply amazing. Thank you, everyone who have, and continue to, > put effort into LinuxBIOS, FILO and Etherboot! Very glad you like it. :-) If you are looking for CF support for FILO 0.5, check out the latest revision and enable the line #PCMCIA_CF = 1. > FILO version 0.5 (stuge at carepad4) Tue Sep 5 05:22:36 CEST 2006 > menu: hde1:/boot/filo/menu.lst > IDE channel 2 not found > Press any key to continue. > Press any key to continue. > Press any key to continue. > Press any key to continue. > Press any key to continue. -- 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 acassis at gmail.com Wed Sep 6 13:42:00 2006 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Wed, 6 Sep 2006 08:42:00 -0300 Subject: [LinuxBIOS] Flashrom is not detecting 2MiB flash In-Reply-To: <44FE1333.2010203@onelabs.com> References: <37367b3a0609051423r73d291bcw61cd12e6a9819f40@mail.gmail.com> <1157498449.1854.2.camel@logarithm.lanl.gov> <44FE1333.2010203@onelabs.com> Message-ID: <37367b3a0609060442p4f6853c5tb2529148cacbfb5e@mail.gmail.com> Hi Bari, On 9/5/06, Bari Ari wrote: > You're probably going to need access to the VT8237 programming guide. I asked VIA for one VT8237 programming guide, but they don't supply me one. You are going to run into issues with the VT8237 accessing address > space with block locking registers in the SST49LF160C or SST49LF016C. Sure, the original MB flash part is 256KB, but I see it detect 512KB flashes too. Are you sure the SST49LF160C follows jedec routines completely? I seem > to recall the SST 16Mb parts vary some. Well, I am not a flash expert, but I don't see any warnning on SST49LF160C datashet. Bari, do you know whether VT8237 can work with LinuxBIOS VT8235 code or not? Stefan suggest me it maybe has just minor changes, as you has the VT8237 datasheet, can you please confirm it? Bari > > Cheers, Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at coresystems.de Wed Sep 6 16:18:03 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 6 Sep 2006 16:18:03 +0200 Subject: [LinuxBIOS] Flashrom is not detecting 2MiB flash In-Reply-To: <37367b3a0609060442p4f6853c5tb2529148cacbfb5e@mail.gmail.com> References: <37367b3a0609051423r73d291bcw61cd12e6a9819f40@mail.gmail.com> <1157498449.1854.2.camel@logarithm.lanl.gov> <44FE1333.2010203@onelabs.com> <37367b3a0609060442p4f6853c5tb2529148cacbfb5e@mail.gmail.com> Message-ID: <20060906141803.GA28232@coresystems.de> * Alan Carvalho de Assis [060906 13:42]: > You are going to run into issues with the VT8237 accessing address > space with block locking registers in the SST49LF160C or SST49LF016C. > > > Sure, the original MB flash part is 256KB, but I see it detect 512KB flashes > too. The LF160 is 2048KB, right? So on the VT8237 you see maximum 1/4 of the flash. > Well, I am not a flash expert, but I don't see any warnning on SST49LF160C > datashet. You need to compare it command per command with another Jedec chip to find out :-} 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 acassis at gmail.com Wed Sep 6 16:56:50 2006 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Wed, 6 Sep 2006 11:56:50 -0300 Subject: [LinuxBIOS] Flashrom is not detecting 2MiB flash In-Reply-To: <20060906141803.GA28232@coresystems.de> References: <37367b3a0609051423r73d291bcw61cd12e6a9819f40@mail.gmail.com> <1157498449.1854.2.camel@logarithm.lanl.gov> <44FE1333.2010203@onelabs.com> <37367b3a0609060442p4f6853c5tb2529148cacbfb5e@mail.gmail.com> <20060906141803.GA28232@coresystems.de> Message-ID: <37367b3a0609060756p15ea755fsad5afbe46188b327@mail.gmail.com> Hi Stefan, On 9/6/06, Stefan Reinauer wrote: > > * Alan Carvalho de Assis [060906 13:42]: > The LF160 is 2048KB, right? So on the VT8237 you see maximum 1/4 of the > flash. Yes, it is true. You need to compare it command per command with another Jedec chip to > find out :-} Do you can suggest one wich follow completly the jedec spec ? Stefan Alan -- > 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/ > -- ------------------------------------------------------------ | Alan Carvalho de Assis | ------------------------------------------------------------ -- N?o importa o que os outros ir?o pensar, A cura para a infelicidade ? a felicidade -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at coresystems.de Wed Sep 6 17:05:24 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 6 Sep 2006 17:05:24 +0200 Subject: [LinuxBIOS] Flashrom is not detecting 2MiB flash In-Reply-To: <37367b3a0609060756p15ea755fsad5afbe46188b327@mail.gmail.com> References: <37367b3a0609051423r73d291bcw61cd12e6a9819f40@mail.gmail.com> <1157498449.1854.2.camel@logarithm.lanl.gov> <44FE1333.2010203@onelabs.com> <37367b3a0609060442p4f6853c5tb2529148cacbfb5e@mail.gmail.com> <20060906141803.GA28232@coresystems.de> <37367b3a0609060756p15ea755fsad5afbe46188b327@mail.gmail.com> Message-ID: <20060906150524.GA849@coresystems.de> * Alan Carvalho de Assis [060906 16:56]: > You need to compare it command per command with another Jedec chip to > find out :-} > > > Do you can suggest one wich follow completly the jedec spec ? SST49LF040A for example. This part is 512kbyte (4mbit) -- 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 bari at onelabs.com Wed Sep 6 17:16:12 2006 From: bari at onelabs.com (Bari Ari) Date: Wed, 06 Sep 2006 10:16:12 -0500 Subject: [LinuxBIOS] Flashrom is not detecting 2MiB flash In-Reply-To: <20060906141803.GA28232@coresystems.de> References: <37367b3a0609051423r73d291bcw61cd12e6a9819f40@mail.gmail.com> <1157498449.1854.2.camel@logarithm.lanl.gov> <44FE1333.2010203@onelabs.com> <37367b3a0609060442p4f6853c5tb2529148cacbfb5e@mail.gmail.com> <20060906141803.GA28232@coresystems.de> Message-ID: <44FEE63C.3060603@onelabs.com> Stefan Reinauer wrote: > * Alan Carvalho de Assis [060906 13:42]: > >> You are going to run into issues with the VT8237 accessing address >> space with block locking registers in the SST49LF160C or SST49LF016C. >> >> >> Sure, the original MB flash part is 256KB, but I see it detect 512KB flashes >> too. >> > > The LF160 is 2048KB, right? So on the VT8237 you see maximum 1/4 of the > flash. > > The VT8237 has a 4MB FWH/LPC address range. The SST 49LF devices have control registers located outside of the address range of the 8237. There are work-arounds that require the programming guide. Bari From rminnich at lanl.gov Wed Sep 6 17:23:13 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Wed, 06 Sep 2006 09:23:13 -0600 Subject: [LinuxBIOS] RE : Re: VGA bios and i/o access for powerpc In-Reply-To: <20060906054702.39098.qmail@web27508.mail.ukl.yahoo.com> References: <20060906054702.39098.qmail@web27508.mail.ukl.yahoo.com> Message-ID: <44FEE7E1.8070608@lanl.gov> jean-francois simon wrote: > Hi, > Maybe there is a way to do without the emulation layer altogether: > Since in our case we use PCI graphics, I can record all the PCI cycles > made by the VGA BIOS to the graphic card on a BIOS based system (using a > PCI analyser), put them into a listing, run a perl script on it and > include them in the firmware of the non BIOS system....an redo the > process whenever we need to use a different graphic which doesn't happen > very often we've had poor luck with that approach. Plus, even in graphics card of same model, memory programming can change quite a bit between cards. I am not sure this will work. ron From uwe at hermann-uwe.de Wed Sep 6 17:41:13 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 6 Sep 2006 17:41:13 +0200 Subject: [LinuxBIOS] PATCH: Simplify ROM_SIZE config options. In-Reply-To: <8a0c36780609041846y5027cba7sc3f7e686a28c4695@mail.gmail.com> References: <13426df10609041703o7969c01fq23d20d42c550ee69@mail.gmail.com> <8a0c36780609041846y5027cba7sc3f7e686a28c4695@mail.gmail.com> Message-ID: <20060906154113.GA15261@aragorn> On Mon, Sep 04, 2006 at 08:46:23PM -0500, Richard Smith wrote: > Change the ROM_SIZE to be 1024*1024 or 0x100000 Here's a patch which makes all "option ROM_SIZE" lines use x*y format which is a lot easier to read and modify, without having to use your brain or a calculator ;-) Tested with abuild, no errors. Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org -------------- next part -------------- Index: src/drivers/pci/onboard/onboard.c =================================================================== --- src/drivers/pci/onboard/onboard.c (Revision 2394) +++ src/drivers/pci/onboard/onboard.c (Arbeitskopie) @@ -20,7 +20,7 @@ in your MB mainboard Config.lb 2. add # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 in your MB targets Config.lb, afer romimage "normal" 3. create you vgabios.bin under normal bios and put that in dir that targets Config residues. # dd if=/dev/mem of=atix.rom skip=1536 count=96 Index: documentation/RFC/config.tex =================================================================== --- documentation/RFC/config.tex (Revision 2394) +++ documentation/RFC/config.tex (Arbeitskopie) @@ -173,7 +173,7 @@ target x # over-ride the default rom size in the mainboard file -option ROM_SIZE=0x100000 +option ROM_SIZE=1024*1024 mainboard amd/solo end Index: targets/lippert/frontrunner/Config.lb =================================================================== --- targets/lippert/frontrunner/Config.lb (Revision 2394) +++ targets/lippert/frontrunner/Config.lb (Arbeitskopie) @@ -4,7 +4,7 @@ target frontrunner mainboard lippert/frontrunner -option ROM_SIZE=1024*256 +option ROM_SIZE=256*1024 romimage "normal" option USE_FALLBACK_IMAGE=0 Index: targets/via/epia-m/Config-abuild.lb =================================================================== --- targets/via/epia-m/Config-abuild.lb (Revision 2394) +++ targets/via/epia-m/Config-abuild.lb (Arbeitskopie) @@ -7,7 +7,7 @@ option DEFAULT_CONSOLE_LOGLEVEL=8 option CONFIG_CONSOLE_SERIAL8250=1 -option ROM_SIZE=524288 +option ROM_SIZE=512*1024 option HAVE_OPTION_TABLE=1 Index: targets/via/epia-m/Config.512kflash.lb =================================================================== --- targets/via/epia-m/Config.512kflash.lb (Revision 2394) +++ targets/via/epia-m/Config.512kflash.lb (Arbeitskopie) @@ -9,7 +9,7 @@ option DEFAULT_CONSOLE_LOGLEVEL=8 option CONFIG_CONSOLE_SERIAL8250=1 -option ROM_SIZE=524288 +option ROM_SIZE=512*1024 option HAVE_OPTION_TABLE=1 Index: targets/via/epia/Config.512kflash.lb =================================================================== --- targets/via/epia/Config.512kflash.lb (Revision 2394) +++ targets/via/epia/Config.512kflash.lb (Arbeitskopie) @@ -4,7 +4,7 @@ target epia.512kflash mainboard via/epia -option ROM_SIZE=524288 +option ROM_SIZE=512*1024 # # Via Epia Index: targets/via/epia/Config.512kflash.linuxtiny.lb =================================================================== --- targets/via/epia/Config.512kflash.linuxtiny.lb (Revision 2394) +++ targets/via/epia/Config.512kflash.linuxtiny.lb (Arbeitskopie) @@ -4,7 +4,7 @@ target epia.512kflash.linuxtiny mainboard via/epia -option ROM_SIZE=524288 +option ROM_SIZE=512*1024 option FALLBACK_SIZE=ROM_SIZE option MAXIMUM_CONSOLE_LOGLEVEL=10 option DEFAULT_CONSOLE_LOGLEVEL=10 Index: targets/dell/s1850/Config.lb =================================================================== --- targets/dell/s1850/Config.lb (Revision 2394) +++ targets/dell/s1850/Config.lb (Arbeitskopie) @@ -1,7 +1,7 @@ target s1850 mainboard dell/s1850 -option ROM_SIZE=0x100000 +option ROM_SIZE=1024*1024 option MAXIMUM_CONSOLE_LOGLEVEL=10 option DEFAULT_CONSOLE_LOGLEVEL=10 Index: targets/Iwill/dk8htx/Config.lb =================================================================== --- targets/Iwill/dk8htx/Config.lb (Revision 2394) +++ targets/Iwill/dk8htx/Config.lb (Arbeitskopie) @@ -125,9 +125,9 @@ # romimage "normal" # 48K for SCSI FW -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" option USE_FALLBACK_IMAGE=0 option ROM_SECTION_SIZE = (ROM_SIZE - FALLBACK_SIZE) Index: targets/Iwill/dk8s2/Config.lb =================================================================== --- targets/Iwill/dk8s2/Config.lb (Revision 2394) +++ targets/Iwill/dk8s2/Config.lb (Arbeitskopie) @@ -10,7 +10,7 @@ option HAVE_OPTION_TABLE=1 option HAVE_MP_TABLE=1 -option ROM_SIZE=1048576 +option ROM_SIZE=1024*1024 option HAVE_FALLBACK_BOOT=1 @@ -125,9 +125,9 @@ # romimage "normal" # 48K for SCSI FW -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" option USE_FALLBACK_IMAGE=0 option ROM_SECTION_SIZE = (ROM_SIZE - FALLBACK_SIZE) Index: targets/totalimpact/briq/Config.lb =================================================================== --- targets/totalimpact/briq/Config.lb (Revision 2394) +++ targets/totalimpact/briq/Config.lb (Arbeitskopie) @@ -25,7 +25,7 @@ option IDE_OFFSET=0 # ROM is 1Mb -option ROM_SIZE=1048576 +option ROM_SIZE=1024*1024 # Set stack and heap sizes (stage 2) option STACK_SIZE=0x10000 Index: targets/broadcom/blast/Config.lb =================================================================== --- targets/broadcom/blast/Config.lb (Revision 2394) +++ targets/broadcom/blast/Config.lb (Arbeitskopie) @@ -7,11 +7,11 @@ romimage "normal" # 48K for ATI rom - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x13800 # option ROM_IMAGE_SIZE=0x17800 Index: targets/arima/hdama/Config.lb =================================================================== --- targets/arima/hdama/Config.lb (Revision 2394) +++ targets/arima/hdama/Config.lb (Arbeitskopie) @@ -6,7 +6,7 @@ target hdama mainboard arima/hdama -option ROM_SIZE=487424 +option ROM_SIZE=512*1024-36*1024 # Arima hdama romimage "normal" Index: targets/arima/hdama/Config.kernelimage.lb =================================================================== --- targets/arima/hdama/Config.kernelimage.lb (Revision 2394) +++ targets/arima/hdama/Config.kernelimage.lb (Arbeitskopie) @@ -64,7 +64,7 @@ option k7=1 option k8=1 -option ROM_SIZE=0x100000 +option ROM_SIZE=1024*1024 option HAVE_OPTION_TABLE=1 Index: targets/motorola/sandpoint/Config.lb.ide_stream =================================================================== --- targets/motorola/sandpoint/Config.lb.ide_stream (Revision 2394) +++ targets/motorola/sandpoint/Config.lb.ide_stream (Arbeitskopie) @@ -57,7 +57,7 @@ option IDE_OFFSET=0 # ROM is 1Mb -option ROM_SIZE=1048576 +option ROM_SIZE=1024*1024 # Set stack and heap sizes (stage 2) option STACK_SIZE=0x10000 Index: targets/sunw/ultra40/Config.lb =================================================================== --- targets/sunw/ultra40/Config.lb (Revision 2394) +++ targets/sunw/ultra40/Config.lb (Arbeitskopie) @@ -9,13 +9,13 @@ # sunw ultra40 romimage "normal" # 48K for SCSI FW -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 # 64K for NIC option 48K for Raid option rom -# option ROM_SIZE = 409600 +# option ROM_SIZE = 512*1024-64*1024-48*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13800 Index: targets/emulation/qemu-i386/Config.lb =================================================================== --- targets/emulation/qemu-i386/Config.lb (Revision 2394) +++ targets/emulation/qemu-i386/Config.lb (Arbeitskopie) @@ -3,7 +3,7 @@ target qemu-i386 mainboard emulation/qemu-i386 -option ROM_SIZE=0x40000 +option ROM_SIZE=256*1024 option CC="gcc -m32" Index: targets/embeddedplanet/ep405pc/Config.lb =================================================================== --- targets/embeddedplanet/ep405pc/Config.lb (Revision 2394) +++ targets/embeddedplanet/ep405pc/Config.lb (Arbeitskopie) @@ -38,7 +38,7 @@ option CONFIG_FS_FAT=1 option AUTOBOOT_CMDLINE="hda1:/vmlinuz" - option ROM_SIZE=1048576 + option ROM_SIZE=1024*1024 ## Board has fixed size RAM option EMBEDDED_RAM_SIZE=64*1024*1024 Index: targets/advantech/som_gx533c/Config.lb =================================================================== --- targets/advantech/som_gx533c/Config.lb (Revision 2394) +++ targets/advantech/som_gx533c/Config.lb (Arbeitskopie) @@ -5,7 +5,7 @@ target som_gx533c mainboard advantech/som_gx533c -option ROM_SIZE=1024*512 +option ROM_SIZE=512*1024 option MAXIMUM_CONSOLE_LOGLEVEL=9 option DEFAULT_CONSOLE_LOGLEVEL=9 Index: targets/olpc/rev_a/Config.kernel.lb =================================================================== --- targets/olpc/rev_a/Config.kernel.lb (Revision 2394) +++ targets/olpc/rev_a/Config.kernel.lb (Arbeitskopie) @@ -3,7 +3,7 @@ target rev_a mainboard olpc/rev_a -option ROM_SIZE=1024*128*7 +option ROM_SIZE=7*128*1024 option FALLBACK_SIZE=ROM_SIZE #romimage "normal" Index: targets/olpc/rev_a/Config.lb =================================================================== --- targets/olpc/rev_a/Config.lb (Revision 2394) +++ targets/olpc/rev_a/Config.lb (Arbeitskopie) @@ -5,7 +5,7 @@ # leave 64k for vsa option CONFIG_COMPRESSED_ROM_STREAM=0 -option ROM_SIZE=1024*512-64*1024 +option ROM_SIZE=512*1024-64*1024 option FALLBACK_SIZE=ROM_SIZE option DEFAULT_CONSOLE_LOGLEVEL = 11 Index: targets/eaglelion/5bcm/Config.lb =================================================================== --- targets/eaglelion/5bcm/Config.lb (Revision 2394) +++ targets/eaglelion/5bcm/Config.lb (Arbeitskopie) @@ -4,7 +4,7 @@ target 5bcm mainboard eaglelion/5bcm -option ROM_SIZE=1024*256 +option ROM_SIZE=256*1024 romimage "normal" option USE_FALLBACK_IMAGE=0 Index: targets/amd/rumba/Config.lb =================================================================== --- targets/amd/rumba/Config.lb (Revision 2394) +++ targets/amd/rumba/Config.lb (Arbeitskopie) @@ -4,7 +4,7 @@ target rumba mainboard amd/rumba -option ROM_SIZE=1024*256 +option ROM_SIZE=256*1024 romimage "normal" option USE_FALLBACK_IMAGE=0 Index: targets/amd/rumba/Config.nofallback.lb =================================================================== --- targets/amd/rumba/Config.nofallback.lb (Revision 2394) +++ targets/amd/rumba/Config.nofallback.lb (Arbeitskopie) @@ -4,7 +4,7 @@ target rumba mainboard amd/rumba -option ROM_SIZE=1024*128 +option ROM_SIZE=128*1024 option FALLBACK_SIZE=ROM_SIZE #option FALLBACK_SIZE=65535 Index: targets/amd/serengeti_leopard/Config.lb =================================================================== --- targets/amd/serengeti_leopard/Config.lb (Revision 2394) +++ targets/amd/serengeti_leopard/Config.lb (Arbeitskopie) @@ -8,11 +8,11 @@ # serengeti_leopard romimage "normal" # 48K for SCSI FW -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x13800 # option ROM_IMAGE_SIZE=0x17800 Index: targets/amd/solo/Config-8MBit.lb =================================================================== --- targets/amd/solo/Config-8MBit.lb (Revision 2394) +++ targets/amd/solo/Config-8MBit.lb (Arbeitskopie) @@ -5,7 +5,7 @@ target solo-8mbit mainboard amd/solo -option ROM_SIZE=0x100000 +option ROM_SIZE=1024*1024 romimage "only" option USE_FALLBACK_IMAGE=1 Index: targets/newisys/khepri/Config.lb =================================================================== --- targets/newisys/khepri/Config.lb (Revision 2394) +++ targets/newisys/khepri/Config.lb (Arbeitskopie) @@ -17,7 +17,7 @@ option CONFIG_CONSOLE_SERIAL8250=1 # Size of the image. Khepri comes with 512k per default. -option ROM_SIZE=524288 +option ROM_SIZE=512*1024 option HAVE_OPTION_TABLE=1 option CONFIG_ROM_STREAM=1 Index: targets/bitworks/ims/Config.lb =================================================================== --- targets/bitworks/ims/Config.lb (Revision 2394) +++ targets/bitworks/ims/Config.lb (Arbeitskopie) @@ -4,7 +4,7 @@ target ims mainboard bitworks/ims -option ROM_SIZE=524288 +option ROM_SIZE=512*1024 romimage "normal" option USE_FALLBACK_IMAGE=0 Index: targets/intel/xe7501devkit/Config.lb =================================================================== --- targets/intel/xe7501devkit/Config.lb (Revision 2394) +++ targets/intel/xe7501devkit/Config.lb (Arbeitskopie) @@ -1,37 +1,37 @@ -target xe7501devkit -mainboard intel/xe7501devkit - -## ROM_SIZE is the total number of bytes allocated for LinuxBIOS use -## (normal AND fallback images and payloads). -option ROM_SIZE = 0x30000 - -## ROM_IMAGE_SIZE is the maximum number of bytes allowed for a LinuxBIOS image, -## not including any payload. -option ROM_IMAGE_SIZE = 0x1B000 - -## FALLBACK_SIZE is the amount of the ROM the complete fallback image -## (including payload) will use -option FALLBACK_SIZE = 0 - - - -romimage "normal" - option USE_FALLBACK_IMAGE=0 -# option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" -# payload ../../../../../../../memtest86/memtest -# payload ../../../../../../../etherboot/src/bin/e1000.zelf - payload ../../../../../../../etherboot/src/bin/e1000--filo.zelf -# payload ../../../../../../../QNX/BSP/images/qnxbasesmp.elf -end - -#NOTE: CMOS currently not supported due to conflicts with factory BIOS -# Thus no support for fallback boot. -#romimage "fallback" -# option USE_FALLBACK_IMAGE=1 -# option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" -# payload ../../../../../../../memtest86/memtest -# payload ../../../../../../../etherboot/src/bin/e1000.zelf -# payload ../../../../../../../etherboot/src/bin/e1000--filo.zelf -#end - -buildrom ./linuxbios.rom ROM_SIZE "normal" +target xe7501devkit +mainboard intel/xe7501devkit + +## ROM_SIZE is the total number of bytes allocated for LinuxBIOS use +## (normal AND fallback images and payloads). +option ROM_SIZE = 192*1024 + +## ROM_IMAGE_SIZE is the maximum number of bytes allowed for a LinuxBIOS image, +## not including any payload. +option ROM_IMAGE_SIZE = 0x1B000 + +## FALLBACK_SIZE is the amount of the ROM the complete fallback image +## (including payload) will use +option FALLBACK_SIZE = 0 + + + +romimage "normal" + option USE_FALLBACK_IMAGE=0 +# option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" +# payload ../../../../../../../memtest86/memtest +# payload ../../../../../../../etherboot/src/bin/e1000.zelf + payload ../../../../../../../etherboot/src/bin/e1000--filo.zelf +# payload ../../../../../../../QNX/BSP/images/qnxbasesmp.elf +end + +#NOTE: CMOS currently not supported due to conflicts with factory BIOS +# Thus no support for fallback boot. +#romimage "fallback" +# option USE_FALLBACK_IMAGE=1 +# option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" +# payload ../../../../../../../memtest86/memtest +# payload ../../../../../../../etherboot/src/bin/e1000.zelf +# payload ../../../../../../../etherboot/src/bin/e1000--filo.zelf +#end + +buildrom ./linuxbios.rom ROM_SIZE "normal" Index: targets/tyan/s2850/Config.lb =================================================================== --- targets/tyan/s2850/Config.lb (Revision 2394) +++ targets/tyan/s2850/Config.lb (Arbeitskopie) @@ -8,11 +8,11 @@ # Tyan s2850 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x16000 Index: targets/tyan/s2735/Config.lb =================================================================== --- targets/tyan/s2735/Config.lb (Revision 2394) +++ targets/tyan/s2735/Config.lb (Arbeitskopie) @@ -8,11 +8,11 @@ # Tyan s2735 romimage "normal" # 48K for SCSI FW -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 option ROM_IMAGE_SIZE=0x11800 option XIP_ROM_SIZE=0x20000 Index: targets/tyan/s2880/Config.lb =================================================================== --- targets/tyan/s2880/Config.lb (Revision 2394) +++ targets/tyan/s2880/Config.lb (Arbeitskopie) @@ -8,11 +8,11 @@ # Tyan s2880 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13800 Index: targets/tyan/s2881/Config.lb =================================================================== --- targets/tyan/s2881/Config.lb (Revision 2394) +++ targets/tyan/s2881/Config.lb (Arbeitskopie) @@ -8,11 +8,11 @@ # Tyan s2881 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13000 Index: targets/tyan/s2882/Config.lb =================================================================== --- targets/tyan/s2882/Config.lb (Revision 2394) +++ targets/tyan/s2882/Config.lb (Arbeitskopie) @@ -8,11 +8,11 @@ # Tyan s2882 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x16000 Index: targets/tyan/s2891/Config.lb.com2 =================================================================== --- targets/tyan/s2891/Config.lb.com2 (Revision 2394) +++ targets/tyan/s2891/Config.lb.com2 (Arbeitskopie) @@ -8,11 +8,11 @@ # Tyan s2891 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13000 Index: targets/tyan/s2891/Config.lb =================================================================== --- targets/tyan/s2891/Config.lb (Revision 2394) +++ targets/tyan/s2891/Config.lb (Arbeitskopie) @@ -8,13 +8,13 @@ # Tyan s2891 romimage "normal" # 48K for ATI ROM in 1M - option ROM_SIZE = 999424 + option ROM_SIZE = 1024*1024-48*1024 # 48K for SCSI FW or ATI ROM -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13000 Index: targets/tyan/s4880/Config.lb =================================================================== --- targets/tyan/s4880/Config.lb (Revision 2394) +++ targets/tyan/s4880/Config.lb (Arbeitskopie) @@ -8,11 +8,11 @@ # Tyan s4880 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x19000 # option ROM_IMAGE_SIZE=0x19c00 Index: targets/tyan/s2892/Config.lb =================================================================== --- targets/tyan/s2892/Config.lb (Revision 2394) +++ targets/tyan/s2892/Config.lb (Arbeitskopie) @@ -8,13 +8,13 @@ # Tyan s2892 romimage "normal" # 48K for ATI ROM in 1M - option ROM_SIZE = 999424 + option ROM_SIZE = 1024*1024-48*1024 # 48K for SCSI FW or ATI ROM -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13800 Index: targets/tyan/s2875/Config.lb =================================================================== --- targets/tyan/s2875/Config.lb (Revision 2394) +++ targets/tyan/s2875/Config.lb (Arbeitskopie) @@ -8,11 +8,11 @@ # Tyan s2875 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13800 Index: targets/tyan/s4882/Config.lb =================================================================== --- targets/tyan/s4882/Config.lb (Revision 2394) +++ targets/tyan/s4882/Config.lb (Arbeitskopie) @@ -8,11 +8,11 @@ # Tyan s4882 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x19000 # option ROM_IMAGE_SIZE=0x19c00 Index: targets/tyan/s2885/Config.lb =================================================================== --- targets/tyan/s2885/Config.lb (Revision 2394) +++ targets/tyan/s2885/Config.lb (Arbeitskopie) @@ -8,11 +8,11 @@ # Tyan s2895 romimage "normal" # 48K for SCSI FW -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x13800 # option ROM_IMAGE_SIZE=0x17800 Index: targets/tyan/s2895/Config.lb =================================================================== --- targets/tyan/s2895/Config.lb (Revision 2394) +++ targets/tyan/s2895/Config.lb (Arbeitskopie) @@ -8,13 +8,13 @@ # Tyan s2895 romimage "normal" # 48K for SCSI FW -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 # 64K for NIC option 48K for Raid option rom -# option ROM_SIZE = 409600 +# option ROM_SIZE = 512*1024-64*1024-48*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13800 Index: targets/agami/aruma/Config.lb =================================================================== --- targets/agami/aruma/Config.lb (Revision 2394) +++ targets/agami/aruma/Config.lb (Arbeitskopie) @@ -15,8 +15,7 @@ option HAVE_ACPI_TABLES=1 romimage "normal" - # 512-36 k - option ROM_SIZE = 487424 + option ROM_SIZE = 512*1024-36*1024 option USE_FALLBACK_IMAGE=0 option ROM_IMAGE_SIZE=0x20000 option XIP_ROM_SIZE=0x20000 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From svn at openbios.org Wed Sep 6 17:48:48 2006 From: svn at openbios.org (svn at openbios.org) Date: Wed, 06 Sep 2006 17:48:48 +0200 Subject: [LinuxBIOS] r2395 - trunk/LinuxBIOSv2/util/flashrom Message-ID: Author: stepan Date: 2006-09-06 17:48:48 +0200 (Wed, 06 Sep 2006) New Revision: 2395 Modified: trunk/LinuxBIOSv2/util/flashrom/flash_enable.c Log: Add patch from Uwe Hermann to support more ICH southbridges Modified: trunk/LinuxBIOSv2/util/flashrom/flash_enable.c =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/flash_enable.c 2006-08-29 17:41:14 UTC (rev 2394) +++ trunk/LinuxBIOSv2/util/flashrom/flash_enable.c 2006-09-06 15:48:48 UTC (rev 2395) @@ -3,6 +3,7 @@ * * Copyright (C) 2000-2004 ??? * Copyright (C) 2005 coresystems GmbH + * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -76,43 +77,21 @@ return 0; } -static int enable_flash_e7500(struct pci_dev *dev, char *name) +static int enable_flash_ich(struct pci_dev *dev, char *name, int bios_cntl) { /* register 4e.b gets or'ed with one */ uint8_t old, new; + /* 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. */ - old = pci_read_byte(dev, 0x4e); + /* Note: the ICH0-ICH5 BIOS_CNTL register is actually 16 bit wide, but + * just treating it as 8 bit wide seems to work fine in practice. + */ - new = old | 1; - - if (new == old) - return 0; - - pci_write_byte(dev, 0x4e, new); - - if (pci_read_byte(dev, 0x4e) != new) { - printf("tried to set 0x%x to 0x%x on %s failed (WARNING ONLY)\n", - 0x4e, new, name); - return -1; - } - return 0; -} - -enum { - ICH4_BIOS_CNTL = 0x4e, - /* see page 375 of "Intel ICH7 External Design Specification" - * http://download.intel.com/design/chipsets/datashts/30701302.pdf */ - ICH7_BIOS_CNTL = 0xdc, -}; -static int enable_flash_ich(struct pci_dev *dev, char *name, int bios_cntl) -{ - /* register 4e.b gets or'ed with one */ - uint8_t old, new; - /* 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. + /* see ie. page 375 of "Intel ICH7 External Design Specification" + * http://download.intel.com/design/chipsets/datashts/30701302.pdf */ old = pci_read_byte(dev, bios_cntl); @@ -132,14 +111,14 @@ return 0; } -static int enable_flash_ich4(struct pci_dev *dev, char *name) +static int enable_flash_ich_4e(struct pci_dev *dev, char *name) { - return enable_flash_ich(dev, name, ICH4_BIOS_CNTL); + return enable_flash_ich(dev, name, 0x4e); } -static int enable_flash_ich7(struct pci_dev *dev, char *name) +static int enable_flash_ich_dc(struct pci_dev *dev, char *name) { - return enable_flash_ich(dev, name, ICH7_BIOS_CNTL); + return enable_flash_ich(dev, name, 0xdc); } static int enable_flash_vt8235(struct pci_dev *dev, char *name) @@ -382,12 +361,24 @@ } FLASH_ENABLE; static FLASH_ENABLE enables[] = { - {0x1039, 0x0630, "sis630", enable_flash_sis630}, - {0x8086, 0x2480, "E7500", enable_flash_e7500}, - {0x8086, 0x24c0, "ICH4", enable_flash_ich4}, - {0x8086, 0x24cc, "ICH4-M", enable_flash_ich4}, - {0x8086, 0x24d0, "ICH5", enable_flash_ich4}, - {0x8086, 0x27b8, "ICH7", enable_flash_ich7}, + {0x1039, 0x0630, "SIS630", enable_flash_sis630}, + {0x8086, 0x2410, "ICH", enable_flash_ich_4e}, + {0x8086, 0x2420, "ICH0", enable_flash_ich_4e}, + {0x8086, 0x2440, "ICH2", enable_flash_ich_4e}, + {0x8086, 0x244c, "ICH2-M", enable_flash_ich_4e}, + {0x8086, 0x2480, "ICH3-S", enable_flash_ich_4e}, + {0x8086, 0x248c, "ICH3-M", enable_flash_ich_4e}, + {0x8086, 0x24c0, "ICH4/ICH4-L", enable_flash_ich_4e}, + {0x8086, 0x24cc, "ICH4-M", enable_flash_ich_4e}, + {0x8086, 0x24d0, "ICH5/ICH5R", enable_flash_ich_4e}, + {0x8086, 0x2640, "ICH6/ICH6R", enable_flash_ich_dc}, + {0x8086, 0x2641, "ICH6-M", enable_flash_ich_dc}, + {0x8086, 0x27b8, "ICH7/ICH7R", enable_flash_ich_dc}, + {0x8086, 0x27b9, "ICH7M", enable_flash_ich_dc}, + {0x8086, 0x27bd, "ICH7MDH", enable_flash_ich_dc}, + {0x8086, 0x2810, "ICH8/ICH8R", enable_flash_ich_dc}, + {0x8086, 0x2812, "ICH8DH", enable_flash_ich_dc}, + {0x8086, 0x2814, "ICH8DO", enable_flash_ich_dc}, {0x1106, 0x8231, "VT8231", enable_flash_vt8231}, {0x1106, 0x3177, "VT8235", enable_flash_vt8235}, {0x1078, 0x0100, "CS5530", enable_flash_cs5530}, From stepan at coresystems.de Wed Sep 6 18:09:08 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 6 Sep 2006 18:09:08 +0200 Subject: [LinuxBIOS] PATCH: Simplify ROM_SIZE config options. In-Reply-To: <20060906154113.GA15261@aragorn> References: <13426df10609041703o7969c01fq23d20d42c550ee69@mail.gmail.com> <8a0c36780609041846y5027cba7sc3f7e686a28c4695@mail.gmail.com> <20060906154113.GA15261@aragorn> Message-ID: <20060906160908.GB11446@coresystems.de> * Uwe Hermann [060906 17:41]: > On Mon, Sep 04, 2006 at 08:46:23PM -0500, Richard Smith wrote: > > Change the ROM_SIZE to be 1024*1024 or 0x100000 > > Here's a patch which makes all "option ROM_SIZE" lines use x*y format > which is a lot easier to read and modify, without having to use your > brain or a calculator ;-) > > Tested with abuild, no errors. comments anyone? -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From svn at openbios.org Wed Sep 6 18:12:39 2006 From: svn at openbios.org (svn at openbios.org) Date: Wed, 06 Sep 2006 18:12:39 +0200 Subject: [LinuxBIOS] r2396 - in trunk/LinuxBIOSv2/src/superio/ite: . it8671f it8673f it8712f it8716f Message-ID: Author: stepan Date: 2006-09-06 18:12:39 +0200 (Wed, 06 Sep 2006) New Revision: 2396 Added: trunk/LinuxBIOSv2/src/superio/ite/it8716f/ trunk/LinuxBIOSv2/src/superio/ite/it8716f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f.h trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f.h trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f.h trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f.h trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c Log: Patch from Uwe Hermann: * support for it8716f. * minor fixes for it8712f, it8671f, it8673f Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f.h 2006-09-06 15:48:48 UTC (rev 2395) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f.h 2006-09-06 16:12:39 UTC (rev 2396) @@ -16,6 +16,9 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +/* Datasheet: Not available online, got it from ITE per request. */ +/* Status: Com1 is tested and works. */ + #define IT8671F_FDC 0x00 /* Floppy */ #define IT8671F_SP1 0x01 /* Com1 */ #define IT8671F_SP2 0x02 /* Com2 */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c 2006-09-06 15:48:48 UTC (rev 2395) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c 2006-09-06 16:12:39 UTC (rev 2396) @@ -20,9 +20,9 @@ #include "it8671f.h" /* The base address is 0x3f0, 0x3bd, or 0x370, depending on config bytes. */ -#define SIO_BASE 0x3f0 -#define SIO_INDEX SIO_BASE -#define SIO_DATA SIO_BASE+1 +#define SIO_BASE 0x3f0 +#define SIO_INDEX SIO_BASE +#define SIO_DATA SIO_BASE+1 /* Global Configuration Registers. */ #define IT8671F_CONFIG_REG_CC 0x02 /* Configure Control (write-only). */ @@ -31,7 +31,6 @@ #define IT8671F_CONFIG_REG_SWSUSP 0x24 /* Software Suspend. */ #define IT8671F_CONFIGURATION_PORT 0x0279 /* Write-only. */ -#define IT8671F_WRITE_DATA_PORT 0x0A79 /* Write-only. */ /* Special values used for entering MB PnP mode. The first four bytes of * each line determine the address port, the last four are data. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f.h 2006-09-06 15:48:48 UTC (rev 2395) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f.h 2006-09-06 16:12:39 UTC (rev 2396) @@ -16,6 +16,9 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +/* Datasheet: http://www.datasheet4u.com/html/I/T/8/IT8673F_ITE.pdf.html */ +/* Status: untested on real hardware, but it compiles. */ + #define IT8673F_FDC 0x00 /* Floppy */ #define IT8673F_SP1 0x01 /* Com1 */ #define IT8673F_SP2 0x02 /* Com2 */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f.h 2006-09-06 15:48:48 UTC (rev 2395) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f.h 2006-09-06 16:12:39 UTC (rev 2396) @@ -16,6 +16,9 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +/* Datasheet: http://www.ite.com.tw/product_info/PC/Brief-IT8712_2.asp */ +/* Status: untested on real hardware, but it compiles. */ + #define IT8712F_FDC 0x00 /* Floppy */ #define IT8712F_SP1 0x01 /* Com1 */ #define IT8712F_SP2 0x02 /* Com2 */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c 2006-09-06 15:48:48 UTC (rev 2395) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c 2006-09-06 16:12:39 UTC (rev 2396) @@ -31,7 +31,7 @@ #define IT8712F_CONFIG_REG_CLOCKSEL 0x23 /* Clock Selection. */ #define IT8712F_CONFIG_REG_SWSUSP 0x24 /* Software Suspend, Flash I/F. */ -#define IT8712F_CONFIGURATION_PORT 0x2E /* Write-only. */ +#define IT8712F_CONFIGURATION_PORT 0x2e /* Write-only. */ /* The content of IT8712F_CONFIG_REG_LDN (index 0x07) must be set to the * LDN the register belongs to, before you can access the register. */ Added: trunk/LinuxBIOSv2/src/superio/ite/it8716f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/Config.lb (rev 0) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/Config.lb 2006-09-06 16:12:39 UTC (rev 2396) @@ -0,0 +1,2 @@ +config chip.h +object superio.o Added: trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h (rev 0) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h 2006-09-06 16:12:39 UTC (rev 2396) @@ -0,0 +1,33 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef _SUPERIO_ITE_IT8716F +#define _SUPERIO_ITE_IT8716F + +#include +#include + +extern struct chip_operations superio_ITE_it8716f_ops; + +struct superio_ITE_it8716f_config { + struct uart8250 com1, com2; + struct pc_keyboard keyboard; +}; + +#endif /* _SUPERIO_ITE_IT8716F */ + Added: trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f.h (rev 0) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f.h 2006-09-06 16:12:39 UTC (rev 2396) @@ -0,0 +1,32 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* Datasheet: http://www.ite.com.tw/product_info/PC/Brief-IT8716_2.asp */ +/* Status: untested on real hardware, but it compiles. */ + +#define IT8716F_FDC 0x00 /* Floppy */ +#define IT8716F_SP1 0x01 /* Com1 */ +#define IT8716F_SP2 0x02 /* Com2 */ +#define IT8716F_PP 0x03 /* Parallel port */ +#define IT8716F_EC 0x04 /* Environment controller */ +#define IT8716F_KBCK 0x05 /* Keyboard */ +#define IT8716F_KBCM 0x06 /* Mouse */ +#define IT8716F_MIDI 0x08 /* MIDI port */ +#define IT8716F_GAME 0x09 /* GAME port */ +#define IT8716F_IR 0x0a /* Consumer IR */ + Added: trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c (rev 0) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c 2006-09-06 16:12:39 UTC (rev 2396) @@ -0,0 +1,87 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include "it8716f.h" + +/* The base address is 0x2e or 0x4e, depending on config bytes. */ +#define SIO_BASE 0x2e +#define SIO_INDEX SIO_BASE +#define SIO_DATA SIO_BASE+1 + +/* Global Configuration Registers. */ +#define IT8716F_CONFIG_REG_CC 0x02 /* Configure Control (write-only). */ +#define IT8716F_CONFIG_REG_LDN 0x07 /* Logical Device Number. */ +#define IT8716F_CONFIG_REG_CONFIGSEL 0x22 /* Configuration Select. */ +#define IT8716F_CONFIG_REG_CLOCKSEL 0x23 /* Clock Selection. */ +#define IT8716F_CONFIG_REG_SWSUSP 0x24 /* Software Suspend, Flash I/F. */ + +#define IT8716F_CONFIGURATION_PORT 0x2e /* Write-only. */ + +/* The content of IT8716F_CONFIG_REG_LDN (index 0x07) must be set to the + * LDN the register belongs to, before you can access the register. */ +static void it8716f_sio_write(uint8_t ldn, uint8_t index, uint8_t value) +{ + outb(IT8716F_CONFIG_REG_LDN, SIO_BASE); + outb(ldn, SIO_DATA); + outb(index, SIO_BASE); + outb(value, SIO_DATA); +} + +/* Enable the peripheral devices on the IT8716F Super IO chip. */ +static void it8716f_enable_serial(device_t dev, unsigned iobase) +{ + /* (1) Enter the configuration state (MB PnP mode). */ + + /* Perform MB PnP setup to put the SIO chip at 0x2e. */ + /* Base address 0x2e: 0x87 0x01 0x55 0x55. */ + /* Base address 0x4e: 0x87 0x01 0x55 0xaa. */ + outb(0x87, IT8716F_CONFIGURATION_PORT); + outb(0x01, IT8716F_CONFIGURATION_PORT); + outb(0x55, IT8716F_CONFIGURATION_PORT); + outb(0x55, IT8716F_CONFIGURATION_PORT); + + /* (2) Modify the data of configuration registers. */ + + /* Select the chip to configure (if there's more than one). + * Set bit 7 to select JP3=1, clear bit 7 to select JP3=0. + * If this register is not written, both chips are configured. */ + /* it8716f_sio_write(0x00, IT8716F_CONFIG_REG_CONFIGSEL, 0x00); */ + + /* Enable all devices. */ + it8716f_sio_write(IT8716F_FDC, 0x30, 0x1); /* Floppy */ + it8716f_sio_write(IT8716F_SP1, 0x30, 0x1); /* Serial port 1 */ + it8716f_sio_write(IT8716F_SP2, 0x30, 0x1); /* Serial port 2 */ + it8716f_sio_write(IT8716F_PP, 0x30, 0x1); /* Parallel port */ + it8716f_sio_write(IT8716F_EC, 0x30, 0x1); /* Environment controller */ + it8716f_sio_write(IT8716F_KBCK, 0x30, 0x1); /* Keyboard */ + it8716f_sio_write(IT8716F_KBCM, 0x30, 0x1); /* Mouse */ + it8716f_sio_write(IT8716F_MIDI, 0x30, 0x1); /* MIDI port */ + it8716f_sio_write(IT8716F_GAME, 0x30, 0x1); /* GAME port */ + it8716f_sio_write(IT8716F_IR, 0x30, 0x1); /* Consumer IR */ + + /* Select 24MHz/48MHz CLKIN (set/clear bit 0). TODO: Needed? */ + /* it8716f_sio_write(0x00, IT8716F_CONFIG_REG_CLOCKSEL, 0x00); */ + + /* Clear software suspend mode (clear bit 0). TODO: Needed? */ + /* it8716f_sio_write(0x00, IT8716F_CONFIG_REG_SWSUSP, 0x00); */ + + /* (3) Exit the configuration state (MB PnP mode). */ + it8716f_sio_write(0x00, IT8716F_CONFIG_REG_CC, 0x02); +} + Added: trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c (rev 0) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c 2006-09-06 16:12:39 UTC (rev 2396) @@ -0,0 +1,91 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include "chip.h" +#include "it8716f.h" + +static void init(device_t dev) +{ + struct superio_ITE_it8716f_config *conf; + struct resource *res0, *res1; + + if (!dev->enabled) { + return; + } + + conf = dev->chip_info; + + switch (dev->path.u.pnp.device) { + case IT8716F_FDC: /* TODO. */ + break; + case IT8716F_SP1: + res0 = find_resource(dev, PNP_IDX_IO0); + init_uart8250(res0->base, &conf->com1); + break; + case IT8716F_SP2: + res0 = find_resource(dev, PNP_IDX_IO0); + init_uart8250(res0->base, &conf->com2); + break; + case IT8716F_PP: /* TODO. */ + break; + case IT8716F_EC: /* TODO. */ + break; + case IT8716F_KBCK: + res0 = find_resource(dev, PNP_IDX_IO0); + res1 = find_resource(dev, PNP_IDX_IO1); + init_pc_keyboard(res0->base, res1->base, &conf->keyboard); + break; + case IT8716F_KBCM: /* TODO. */ + break; + case IT8716F_MIDI: /* TODO. */ + break; + case IT8716F_GAME: /* TODO. */ + break; + case IT8716F_IR: /* TODO. */ + break; + } +} + +static struct device_operations ops = { + .read_resources = pnp_read_resources, + .set_resources = pnp_set_resources, + .enable_resources = pnp_enable_resources, + .enable = pnp_enable, + .init = init, +}; + +/* TODO: FDC, PP, EC, KBCM, MIDI, GAME, IR. */ +static struct pnp_info pnp_dev_info[] = { + { &ops, IT8716F_SP1, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, }, + { &ops, IT8716F_SP2, PNP_IO0 | PNP_IRQ0 | PNP_DRQ0 | PNP_DRQ1, { 0x7f8, 0 }, }, + { &ops, IT8716F_KBCK, PNP_IO0 | PNP_IO1 | PNP_IRQ0, { 0x7f8, 0 }, { 0x7f8, 0x4}, }, +}; + +static void enable_dev(struct device *dev) +{ + pnp_enable_devices(dev, &pnp_ops, + sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info); +} + +struct chip_operations superio_ITE_it8716f_ops = { + CHIP_NAME("ITE it8716f") + .enable_dev = enable_dev, +}; + From stepan at coresystems.de Wed Sep 6 18:13:21 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 6 Sep 2006 18:13:21 +0200 Subject: [LinuxBIOS] PATCH: flashrom support for all ICH chipsets. In-Reply-To: <20060901114246.GA16214@aragorn> References: <20060901114246.GA16214@aragorn> Message-ID: <20060906161321.GA29097@coresystems.de> * Uwe Hermann [060901 13:42]: > Hi, > > I've added support in flashrom for all ICH chipsets (maybe I missed one > or two; if so, please tell me). > > Tested on real hardware: ICH2, ICH6-M (the rest is untested). committed. -- 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 ollie at lanl.gov Wed Sep 6 18:13:18 2006 From: ollie at lanl.gov (ollie) Date: Wed, 06 Sep 2006 10:13:18 -0600 Subject: [LinuxBIOS] RE : Re: VGA bios and i/o access for powerpc In-Reply-To: <20060906054702.39098.qmail@web27508.mail.ukl.yahoo.com> References: <20060906054702.39098.qmail@web27508.mail.ukl.yahoo.com> Message-ID: <1157559198.1996.1.camel@logarithm.lanl.gov> On Wed, 2006-09-06 at 07:47 +0200, jean-francois simon wrote: > Hi, > Maybe there is a way to do without the emulation layer altogether: > Since in our case we use PCI graphics, I can record all the PCI cycles > made by the VGA BIOS to the graphic card on a BIOS based system (using > a PCI analyser), put them into a listing, run a perl script on it and > include them in the firmware of the non BIOS system....an redo the > process whenever we need to use a different graphic which doesn't > happen very often > -jf simon > Unfortunately, this is no going to work. The VGA BIOS still use the legacy IO ports. All you will get in the listing is in/out to port 0x3xx. You just have to figure out how to forward IO to legacy ports. Ollie > From stepan at coresystems.de Wed Sep 6 18:13:39 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 6 Sep 2006 18:13:39 +0200 Subject: [LinuxBIOS] IT8716F support. In-Reply-To: <20060901194559.GA11859@aragorn> References: <20060901194559.GA11859@aragorn> Message-ID: <20060906161339.GB29097@coresystems.de> * Uwe Hermann [060901 21:46]: > Hi, > > here's code for the IT8716F, untested as always. The patch also includes > some smaller cosmetic fixes... committed. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From svn at openbios.org Wed Sep 6 18:15:03 2006 From: svn at openbios.org (svn at openbios.org) Date: Wed, 06 Sep 2006 18:15:03 +0200 Subject: [LinuxBIOS] r2397 - in trunk/LinuxBIOSv2/src/superio/ite: . it8705f Message-ID: Author: stepan Date: 2006-09-06 18:15:02 +0200 (Wed, 06 Sep 2006) New Revision: 2397 Added: trunk/LinuxBIOSv2/src/superio/ite/it8705f/ trunk/LinuxBIOSv2/src/superio/ite/it8705f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f.h trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c Log: Add support for ITE it8705f from Uwe Hermann Added: trunk/LinuxBIOSv2/src/superio/ite/it8705f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/Config.lb (rev 0) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) @@ -0,0 +1,2 @@ +config chip.h +object superio.o Added: trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h (rev 0) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h 2006-09-06 16:15:02 UTC (rev 2397) @@ -0,0 +1,33 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef _SUPERIO_ITE_IT8705F +#define _SUPERIO_ITE_IT8705F + +/* This chip doesn't seem to have keyboard and mouse support. */ + +#include + +extern struct chip_operations superio_ITE_it8705f_ops; + +struct superio_ITE_it8705f_config { + struct uart8250 com1, com2; +}; + +#endif /* _SUPERIO_ITE_IT8705F */ + Added: trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f.h (rev 0) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f.h 2006-09-06 16:15:02 UTC (rev 2397) @@ -0,0 +1,34 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* Datasheet: http://www.ite.com.tw/product_info/PC/Brief-IT8705_2.asp */ +/* Status: untested on real hardware, but it compiles. */ +/* Note: This should also work on an IT8705AF, they're almost the same. */ + +/* This chip doesn't seem to have keyboard and mouse support. */ + +#define IT8705F_FDC 0x00 /* Floppy */ +#define IT8705F_SP1 0x01 /* Com1 */ +#define IT8705F_SP2 0x02 /* Com2 */ +#define IT8705F_PP 0x03 /* Parallel port */ +#define IT8705F_EC 0x04 /* Environment controller */ +#define IT8705F_GPIO 0x05 /* GPIO */ +#define IT8705F_GAME 0x06 /* GAME port */ +#define IT8705F_IR 0x07 /* Consumer IR */ +#define IT8705F_MIDI 0x08 /* MIDI port */ + Added: trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c (rev 0) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c 2006-09-06 16:15:02 UTC (rev 2397) @@ -0,0 +1,88 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include "it8705f.h" + +/* The base address is 0x2e or 0x4e, depending on config bytes. */ +#define SIO_BASE 0x2e +#define SIO_INDEX SIO_BASE +#define SIO_DATA SIO_BASE+1 + +/* Global Configuration Registers. */ +#define IT8705F_CONFIG_REG_CC 0x02 /* Configure Control (write-only). */ +#define IT8705F_CONFIG_REG_LDN 0x07 /* Logical Device Number. */ +#define IT8705F_CONFIG_REG_CONFIGSEL 0x22 /* Configuration Select. */ + +/* WTF? 0x23 and 0x24 are swapped here (when compared to other IT87xx). */ +#define IT8705F_CONFIG_REG_CLOCKSEL 0x24 /* Clock Selection. */ +#define IT8705F_CONFIG_REG_SWSUSP 0x23 /* Software Suspend, Flash I/F. */ + +#define IT8705F_CONFIGURATION_PORT 0x2e /* Write-only. */ + +/* The content of IT8705F_CONFIG_REG_LDN (index 0x07) must be set to the + * LDN the register belongs to, before you can access the register. */ +static void it8705f_sio_write(uint8_t ldn, uint8_t index, uint8_t value) +{ + outb(IT8705F_CONFIG_REG_LDN, SIO_BASE); + outb(ldn, SIO_DATA); + outb(index, SIO_BASE); + outb(value, SIO_DATA); +} + +/* Enable the peripheral devices on the IT8705F Super IO chip. */ +static void it8705f_enable_serial(device_t dev, unsigned iobase) +{ + /* (1) Enter the configuration state (MB PnP mode). */ + + /* Perform MB PnP setup to put the SIO chip at 0x2e. */ + /* Base address 0x2e: 0x87 0x01 0x55 0x55. */ + /* Base address 0x4e: 0x87 0x01 0x55 0xaa. */ + outb(0x87, IT8705F_CONFIGURATION_PORT); + outb(0x01, IT8705F_CONFIGURATION_PORT); + outb(0x55, IT8705F_CONFIGURATION_PORT); + outb(0x55, IT8705F_CONFIGURATION_PORT); + + /* (2) Modify the data of configuration registers. */ + + /* Select the chip to configure (if there's more than one). + * Set bit 7 to select JP3=1, clear bit 7 to select JP3=0. + * If this register is not written, both chips are configured. */ + /* it8705f_sio_write(0x00, IT8705F_CONFIG_REG_CONFIGSEL, 0x00); */ + + /* Enable all devices. */ + it8705f_sio_write(IT8705F_FDC, 0x30, 0x1); /* Floppy */ + it8705f_sio_write(IT8705F_SP1, 0x30, 0x1); /* Serial port 1 */ + it8705f_sio_write(IT8705F_SP2, 0x30, 0x1); /* Serial port 2 */ + it8705f_sio_write(IT8705F_PP, 0x30, 0x1); /* Parallel port */ + it8705f_sio_write(IT8705F_EC, 0x30, 0x1); /* Environment controller */ + /* GPIO */ + it8705f_sio_write(IT8705F_GAME, 0x30, 0x1); /* GAME port */ + it8705f_sio_write(IT8705F_IR, 0x30, 0x1); /* Consumer IR */ + it8705f_sio_write(IT8705F_MIDI, 0x30, 0x1); /* MIDI port */ + + /* Select 24MHz/48MHz CLKIN (set/clear bit 0). TODO: Needed? */ + /* it8705f_sio_write(0x00, IT8705F_CONFIG_REG_CLOCKSEL, 0x00); */ + + /* Clear software suspend mode (clear bit 0). TODO: Needed? */ + /* it8705f_sio_write(0x00, IT8705F_CONFIG_REG_SWSUSP, 0x00); */ + + /* (3) Exit the configuration state (MB PnP mode). */ + it8705f_sio_write(0x00, IT8705F_CONFIG_REG_CC, 0x02); +} + Added: trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c (rev 0) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c 2006-09-06 16:15:02 UTC (rev 2397) @@ -0,0 +1,86 @@ +/* + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* This chip doesn't seem to have keyboard and mouse support. */ + +#include +#include "chip.h" +#include "it8705f.h" + +static void init(device_t dev) +{ + struct superio_ITE_it8705f_config *conf; + struct resource *res0, *res1; + + if (!dev->enabled) { + return; + } + + conf = dev->chip_info; + + switch (dev->path.u.pnp.device) { + case IT8705F_FDC: /* TODO. */ + break; + case IT8705F_SP1: + res0 = find_resource(dev, PNP_IDX_IO0); + init_uart8250(res0->base, &conf->com1); + break; + case IT8705F_SP2: + res0 = find_resource(dev, PNP_IDX_IO0); + init_uart8250(res0->base, &conf->com2); + break; + case IT8705F_PP: /* TODO. */ + break; + case IT8705F_EC: /* TODO. */ + break; + case IT8705F_GPIO: /* TODO. */ + break; + case IT8705F_GAME: /* TODO. */ + break; + case IT8705F_IR: /* TODO. */ + break; + case IT8705F_MIDI: /* TODO. */ + break; + } +} + +static struct device_operations ops = { + .read_resources = pnp_read_resources, + .set_resources = pnp_set_resources, + .enable_resources = pnp_enable_resources, + .enable = pnp_enable, + .init = init, +}; + +/* TODO: FDC, PP, EC, GPIO, GAME, IR, MIDI. */ +static struct pnp_info pnp_dev_info[] = { + { &ops, IT8705F_SP1, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, }, + { &ops, IT8705F_SP2, PNP_IO0 | PNP_IRQ0 | PNP_DRQ0 | PNP_DRQ1, { 0x7f8, 0 }, }, +}; + +static void enable_dev(struct device *dev) +{ + pnp_enable_devices(dev, &pnp_ops, + sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info); +} + +struct chip_operations superio_ITE_it8705f_ops = { + CHIP_NAME("ITE it8705f") + .enable_dev = enable_dev, +}; + From smithbone at gmail.com Wed Sep 6 18:17:08 2006 From: smithbone at gmail.com (Richard Smith) Date: Wed, 6 Sep 2006 11:17:08 -0500 Subject: [LinuxBIOS] PATCH: Simplify ROM_SIZE config options. In-Reply-To: <20060906160908.GB11446@coresystems.de> References: <13426df10609041703o7969c01fq23d20d42c550ee69@mail.gmail.com> <8a0c36780609041846y5027cba7sc3f7e686a28c4695@mail.gmail.com> <20060906154113.GA15261@aragorn> <20060906160908.GB11446@coresystems.de> Message-ID: <8a0c36780609060917x3043192fl7137e847beaa3374@mail.gmail.com> > > Here's a patch which makes all "option ROM_SIZE" lines use x*y format > > which is a lot easier to read and modify, without having to use your > > brain or a calculator ;-) > > > > Tested with abuild, no errors. > > comments anyone? Fine with me. As long as we don't go crazy and make the build system require it. It is easier to look at, understand and modify. Consistency is good. -- Richard A. Smith From rminnich at lanl.gov Wed Sep 6 18:16:49 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Wed, 06 Sep 2006 10:16:49 -0600 Subject: [LinuxBIOS] PATCH: Simplify ROM_SIZE config options. In-Reply-To: <20060906160908.GB11446@coresystems.de> References: <13426df10609041703o7969c01fq23d20d42c550ee69@mail.gmail.com> <8a0c36780609041846y5027cba7sc3f7e686a28c4695@mail.gmail.com> <20060906154113.GA15261@aragorn> <20060906160908.GB11446@coresystems.de> Message-ID: <44FEF471.3090303@lanl.gov> Stefan Reinauer wrote: > * Uwe Hermann [060906 17:41]: > >>On Mon, Sep 04, 2006 at 08:46:23PM -0500, Richard Smith wrote: >> >>>Change the ROM_SIZE to be 1024*1024 or 0x100000 >> >>Here's a patch which makes all "option ROM_SIZE" lines use x*y format >>which is a lot easier to read and modify, without having to use your >>brain or a calculator ;-) >> >>Tested with abuild, no errors. > > > comments anyone? > > works for me. I put that arithmetic stuff in the parser for this type of usage -- nice to see it used. ron From smithbone at gmail.com Wed Sep 6 18:31:42 2006 From: smithbone at gmail.com (Richard Smith) Date: Wed, 6 Sep 2006 11:31:42 -0500 Subject: [LinuxBIOS] Need help on epia vt8601 issues Message-ID: <8a0c36780609060931m40690b70o48141bd276cf2526@mail.gmail.com> Alex Mauer did some looking into the changelog and came up with some possibilities for when the Epia vt8601 may have actually worked. Since the epia is _long_ overdue for some maintaince I spent a bit of time pulling those versions and trying to make them compile for him. Compililng old versions of V2 on a new toolchain is an exercise in frustration. I'm going to have to pull my suggestion that someone pull versions until they find the one that broke it. Its a non-trivial exercise. I had to resort to forward porting the raminit code from 1176 into the latest rev. But alas it did not work. We need a confirmed working Linuxbios rom and a dump of the northbridge settings to verify against. If anyone has machines around with older toolchains ( or machines you can install older toolchains on) we could really use some help trying to get an older rev to compile. If anyone has a toolchain that will compile anthing from r1176 to r1258 then please compile a rom for the epia and send it to Alex Mauer for testing. Please do a clean pull for each rev you try. That way we can rule out any wierdness that my happen from a rev to rev switch. Thanks. -- Richard A. Smith From jfaslist at yahoo.fr Wed Sep 6 18:24:11 2006 From: jfaslist at yahoo.fr (jf simon) Date: Wed, 06 Sep 2006 18:24:11 +0200 Subject: [LinuxBIOS] RE : Re: VGA bios and i/o access for powerpc In-Reply-To: <1157559198.1996.1.camel@logarithm.lanl.gov> References: <20060906054702.39098.qmail@web27508.mail.ukl.yahoo.com> <1157559198.1996.1.camel@logarithm.lanl.gov> Message-ID: <44FEF62B.4070606@yahoo.fr> ollie wrote: > > >Unfortunately, this is no going to work. The VGA BIOS still use the >legacy IO ports. All you will get in the listing is in/out to port >0x3xx. You just have to figure out how to forward IO to legacy ports. > >Ollie > > > If you snoop the PCI bus right on the PCI slot for the graphic card, you see "real" pci i/o cycles bound to the PCI i/o BAR of the graphic card. If the address is outside of the BAR the access will not be decoded byte graphic PCI agent, I would think. -jf simon ___________________________________________________________________________ D?couvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/R?ponses pour partager vos connaissances, vos opinions et vos exp?riences. http://fr.answers.yahoo.com From jfaslist at yahoo.fr Wed Sep 6 18:25:26 2006 From: jfaslist at yahoo.fr (jf simon) Date: Wed, 06 Sep 2006 18:25:26 +0200 Subject: [LinuxBIOS] RE : Re: VGA bios and i/o access for powerpc In-Reply-To: <44FEE7E1.8070608@lanl.gov> References: <20060906054702.39098.qmail@web27508.mail.ukl.yahoo.com> <44FEE7E1.8070608@lanl.gov> Message-ID: <44FEF676.7030008@yahoo.fr> Ronald G Minnich wrote: > jean-francois simon wrote: > >> Hi, >> Maybe there is a way to do without the emulation layer altogether: >> Since in our case we use PCI graphics, I can record all the PCI >> cycles made by the VGA BIOS to the graphic card on a BIOS based >> system (using a PCI analyser), put them into a listing, run a perl >> script on it and include them in the firmware of the non BIOS >> system....an redo the process whenever we need to use a different >> graphic which doesn't happen very often > > > we've had poor luck with that approach. Plus, even in graphics card of > same model, memory programming can change quite a bit between cards. I > am not sure this will work. > > ron > Thanks. I'll give it a quick try. If it works I'll let you know. -jfs ___________________________________________________________________________ D?couvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/R?ponses pour partager vos connaissances, vos opinions et vos exp?riences. http://fr.answers.yahoo.com From svn at openbios.org Wed Sep 6 18:42:52 2006 From: svn at openbios.org (svn at openbios.org) Date: Wed, 06 Sep 2006 18:42:52 +0200 Subject: [LinuxBIOS] r2398 - in trunk/LinuxBIOSv2: documentation/RFC src/drivers/pci/onboard targets/Iwill/dk8htx targets/Iwill/dk8s2 targets/advantech/som_gx533c targets/agami/aruma targets/amd/rumba targets/amd/serengeti_leopard targets/amd/solo targets/arima/hdama targets/bitworks/ims targets/broadcom/blast targets/dell/s1850 targets/eaglelion/5bcm targets/embeddedplanet/ep405pc targets/emulation/qemu-i386 targets/intel/xe7501devkit targets/lippert/frontrunner targets/motorola/sandpoint targets/newisys/khepri targets/olpc/rev_a targets/sunw/ultra40 targets/totalimpact/briq targets/tyan/s2735 targets/tyan/s2850 targets/tyan/s2875 targets/tyan/s2880 targets/tyan/s2881 targets/tyan/s2882 targets/tyan/s2885 targets/tyan/s2891 targets/tyan/s2892 targets/tyan/s2895 targets/tyan/s4880 targets/tyan/s4882 targets/via/epia targets/via/epia-m Message-ID: Author: stepan Date: 2006-09-06 18:42:51 +0200 (Wed, 06 Sep 2006) New Revision: 2398 Modified: trunk/LinuxBIOSv2/documentation/RFC/config.tex trunk/LinuxBIOSv2/src/drivers/pci/onboard/onboard.c trunk/LinuxBIOSv2/targets/Iwill/dk8htx/Config.lb trunk/LinuxBIOSv2/targets/Iwill/dk8s2/Config.lb trunk/LinuxBIOSv2/targets/advantech/som_gx533c/Config.lb trunk/LinuxBIOSv2/targets/agami/aruma/Config.lb trunk/LinuxBIOSv2/targets/amd/rumba/Config.lb trunk/LinuxBIOSv2/targets/amd/rumba/Config.nofallback.lb trunk/LinuxBIOSv2/targets/amd/serengeti_leopard/Config.lb trunk/LinuxBIOSv2/targets/amd/solo/Config-8MBit.lb trunk/LinuxBIOSv2/targets/arima/hdama/Config.kernelimage.lb trunk/LinuxBIOSv2/targets/arima/hdama/Config.lb trunk/LinuxBIOSv2/targets/bitworks/ims/Config.lb trunk/LinuxBIOSv2/targets/broadcom/blast/Config.lb trunk/LinuxBIOSv2/targets/dell/s1850/Config.lb trunk/LinuxBIOSv2/targets/eaglelion/5bcm/Config.lb trunk/LinuxBIOSv2/targets/embeddedplanet/ep405pc/Config.lb trunk/LinuxBIOSv2/targets/emulation/qemu-i386/Config.lb trunk/LinuxBIOSv2/targets/intel/xe7501devkit/Config.lb trunk/LinuxBIOSv2/targets/lippert/frontrunner/Config.lb trunk/LinuxBIOSv2/targets/motorola/sandpoint/Config.lb.ide_stream trunk/LinuxBIOSv2/targets/newisys/khepri/Config.lb trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.kernel.lb trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.lb trunk/LinuxBIOSv2/targets/sunw/ultra40/Config.lb trunk/LinuxBIOSv2/targets/totalimpact/briq/Config.lb trunk/LinuxBIOSv2/targets/tyan/s2735/Config.lb trunk/LinuxBIOSv2/targets/tyan/s2850/Config.lb trunk/LinuxBIOSv2/targets/tyan/s2875/Config.lb trunk/LinuxBIOSv2/targets/tyan/s2880/Config.lb trunk/LinuxBIOSv2/targets/tyan/s2881/Config.lb trunk/LinuxBIOSv2/targets/tyan/s2882/Config.lb trunk/LinuxBIOSv2/targets/tyan/s2885/Config.lb trunk/LinuxBIOSv2/targets/tyan/s2891/Config.lb trunk/LinuxBIOSv2/targets/tyan/s2891/Config.lb.com2 trunk/LinuxBIOSv2/targets/tyan/s2892/Config.lb trunk/LinuxBIOSv2/targets/tyan/s2895/Config.lb trunk/LinuxBIOSv2/targets/tyan/s4880/Config.lb trunk/LinuxBIOSv2/targets/tyan/s4882/Config.lb trunk/LinuxBIOSv2/targets/via/epia-m/Config-abuild.lb trunk/LinuxBIOSv2/targets/via/epia-m/Config.512kflash.lb trunk/LinuxBIOSv2/targets/via/epia/Config.512kflash.lb trunk/LinuxBIOSv2/targets/via/epia/Config.512kflash.linuxtiny.lb Log: Uwe Hermann: Here's a patch which makes all "option ROM_SIZE" lines use x*y format which is a lot easier to read and modify, without having to use your brain or a calculator ;-) Tested with abuild, no errors. Modified: trunk/LinuxBIOSv2/documentation/RFC/config.tex =================================================================== --- trunk/LinuxBIOSv2/documentation/RFC/config.tex 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/documentation/RFC/config.tex 2006-09-06 16:42:51 UTC (rev 2398) @@ -173,7 +173,7 @@ target x # over-ride the default rom size in the mainboard file -option ROM_SIZE=0x100000 +option ROM_SIZE=1024*1024 mainboard amd/solo end Modified: trunk/LinuxBIOSv2/src/drivers/pci/onboard/onboard.c =================================================================== --- trunk/LinuxBIOSv2/src/drivers/pci/onboard/onboard.c 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/src/drivers/pci/onboard/onboard.c 2006-09-06 16:42:51 UTC (rev 2398) @@ -20,7 +20,7 @@ in your MB mainboard Config.lb 2. add # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 in your MB targets Config.lb, afer romimage "normal" 3. create you vgabios.bin under normal bios and put that in dir that targets Config residues. # dd if=/dev/mem of=atix.rom skip=1536 count=96 Modified: trunk/LinuxBIOSv2/targets/Iwill/dk8htx/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/Iwill/dk8htx/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/Iwill/dk8htx/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -125,9 +125,9 @@ # romimage "normal" # 48K for SCSI FW -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" option USE_FALLBACK_IMAGE=0 option ROM_SECTION_SIZE = (ROM_SIZE - FALLBACK_SIZE) Modified: trunk/LinuxBIOSv2/targets/Iwill/dk8s2/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/Iwill/dk8s2/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/Iwill/dk8s2/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -10,7 +10,7 @@ option HAVE_OPTION_TABLE=1 option HAVE_MP_TABLE=1 -option ROM_SIZE=1048576 +option ROM_SIZE=1024*1024 option HAVE_FALLBACK_BOOT=1 @@ -125,9 +125,9 @@ # romimage "normal" # 48K for SCSI FW -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" option USE_FALLBACK_IMAGE=0 option ROM_SECTION_SIZE = (ROM_SIZE - FALLBACK_SIZE) Modified: trunk/LinuxBIOSv2/targets/advantech/som_gx533c/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/advantech/som_gx533c/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/advantech/som_gx533c/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -5,7 +5,7 @@ target som_gx533c mainboard advantech/som_gx533c -option ROM_SIZE=1024*512 +option ROM_SIZE=512*1024 option MAXIMUM_CONSOLE_LOGLEVEL=9 option DEFAULT_CONSOLE_LOGLEVEL=9 Modified: trunk/LinuxBIOSv2/targets/agami/aruma/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/agami/aruma/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/agami/aruma/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -15,8 +15,7 @@ option HAVE_ACPI_TABLES=1 romimage "normal" - # 512-36 k - option ROM_SIZE = 487424 + option ROM_SIZE = 512*1024-36*1024 option USE_FALLBACK_IMAGE=0 option ROM_IMAGE_SIZE=0x20000 option XIP_ROM_SIZE=0x20000 Modified: trunk/LinuxBIOSv2/targets/amd/rumba/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/amd/rumba/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/amd/rumba/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -4,7 +4,7 @@ target rumba mainboard amd/rumba -option ROM_SIZE=1024*256 +option ROM_SIZE=256*1024 romimage "normal" option USE_FALLBACK_IMAGE=0 Modified: trunk/LinuxBIOSv2/targets/amd/rumba/Config.nofallback.lb =================================================================== --- trunk/LinuxBIOSv2/targets/amd/rumba/Config.nofallback.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/amd/rumba/Config.nofallback.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -4,7 +4,7 @@ target rumba mainboard amd/rumba -option ROM_SIZE=1024*128 +option ROM_SIZE=128*1024 option FALLBACK_SIZE=ROM_SIZE #option FALLBACK_SIZE=65535 Modified: trunk/LinuxBIOSv2/targets/amd/serengeti_leopard/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/amd/serengeti_leopard/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/amd/serengeti_leopard/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -8,11 +8,11 @@ # serengeti_leopard romimage "normal" # 48K for SCSI FW -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x13800 # option ROM_IMAGE_SIZE=0x17800 Modified: trunk/LinuxBIOSv2/targets/amd/solo/Config-8MBit.lb =================================================================== --- trunk/LinuxBIOSv2/targets/amd/solo/Config-8MBit.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/amd/solo/Config-8MBit.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -5,7 +5,7 @@ target solo-8mbit mainboard amd/solo -option ROM_SIZE=0x100000 +option ROM_SIZE=1024*1024 romimage "only" option USE_FALLBACK_IMAGE=1 Modified: trunk/LinuxBIOSv2/targets/arima/hdama/Config.kernelimage.lb =================================================================== --- trunk/LinuxBIOSv2/targets/arima/hdama/Config.kernelimage.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/arima/hdama/Config.kernelimage.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -64,7 +64,7 @@ option k7=1 option k8=1 -option ROM_SIZE=0x100000 +option ROM_SIZE=1024*1024 option HAVE_OPTION_TABLE=1 Modified: trunk/LinuxBIOSv2/targets/arima/hdama/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/arima/hdama/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/arima/hdama/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -6,7 +6,7 @@ target hdama mainboard arima/hdama -option ROM_SIZE=487424 +option ROM_SIZE=512*1024-36*1024 # Arima hdama romimage "normal" Modified: trunk/LinuxBIOSv2/targets/bitworks/ims/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/bitworks/ims/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/bitworks/ims/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -4,7 +4,7 @@ target ims mainboard bitworks/ims -option ROM_SIZE=524288 +option ROM_SIZE=512*1024 romimage "normal" option USE_FALLBACK_IMAGE=0 Modified: trunk/LinuxBIOSv2/targets/broadcom/blast/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/broadcom/blast/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/broadcom/blast/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -7,11 +7,11 @@ romimage "normal" # 48K for ATI rom - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x13800 # option ROM_IMAGE_SIZE=0x17800 Modified: trunk/LinuxBIOSv2/targets/dell/s1850/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/dell/s1850/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/dell/s1850/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -1,7 +1,7 @@ target s1850 mainboard dell/s1850 -option ROM_SIZE=0x100000 +option ROM_SIZE=1024*1024 option MAXIMUM_CONSOLE_LOGLEVEL=10 option DEFAULT_CONSOLE_LOGLEVEL=10 Modified: trunk/LinuxBIOSv2/targets/eaglelion/5bcm/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/eaglelion/5bcm/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/eaglelion/5bcm/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -4,7 +4,7 @@ target 5bcm mainboard eaglelion/5bcm -option ROM_SIZE=1024*256 +option ROM_SIZE=256*1024 romimage "normal" option USE_FALLBACK_IMAGE=0 Modified: trunk/LinuxBIOSv2/targets/embeddedplanet/ep405pc/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/embeddedplanet/ep405pc/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/embeddedplanet/ep405pc/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -38,7 +38,7 @@ option CONFIG_FS_FAT=1 option AUTOBOOT_CMDLINE="hda1:/vmlinuz" - option ROM_SIZE=1048576 + option ROM_SIZE=1024*1024 ## Board has fixed size RAM option EMBEDDED_RAM_SIZE=64*1024*1024 Modified: trunk/LinuxBIOSv2/targets/emulation/qemu-i386/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/emulation/qemu-i386/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/emulation/qemu-i386/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -3,7 +3,7 @@ target qemu-i386 mainboard emulation/qemu-i386 -option ROM_SIZE=0x40000 +option ROM_SIZE=256*1024 option CC="gcc -m32" Modified: trunk/LinuxBIOSv2/targets/intel/xe7501devkit/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/intel/xe7501devkit/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/intel/xe7501devkit/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -1,37 +1,37 @@ -target xe7501devkit -mainboard intel/xe7501devkit - -## ROM_SIZE is the total number of bytes allocated for LinuxBIOS use -## (normal AND fallback images and payloads). -option ROM_SIZE = 0x30000 - -## ROM_IMAGE_SIZE is the maximum number of bytes allowed for a LinuxBIOS image, -## not including any payload. -option ROM_IMAGE_SIZE = 0x1B000 - -## FALLBACK_SIZE is the amount of the ROM the complete fallback image -## (including payload) will use -option FALLBACK_SIZE = 0 - - - -romimage "normal" - option USE_FALLBACK_IMAGE=0 -# option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" -# payload ../../../../../../../memtest86/memtest -# payload ../../../../../../../etherboot/src/bin/e1000.zelf - payload ../../../../../../../etherboot/src/bin/e1000--filo.zelf -# payload ../../../../../../../QNX/BSP/images/qnxbasesmp.elf -end - -#NOTE: CMOS currently not supported due to conflicts with factory BIOS -# Thus no support for fallback boot. -#romimage "fallback" -# option USE_FALLBACK_IMAGE=1 -# option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" -# payload ../../../../../../../memtest86/memtest -# payload ../../../../../../../etherboot/src/bin/e1000.zelf -# payload ../../../../../../../etherboot/src/bin/e1000--filo.zelf -#end - -buildrom ./linuxbios.rom ROM_SIZE "normal" +target xe7501devkit +mainboard intel/xe7501devkit + +## ROM_SIZE is the total number of bytes allocated for LinuxBIOS use +## (normal AND fallback images and payloads). +option ROM_SIZE = 192*1024 + +## ROM_IMAGE_SIZE is the maximum number of bytes allowed for a LinuxBIOS image, +## not including any payload. +option ROM_IMAGE_SIZE = 0x1B000 + +## FALLBACK_SIZE is the amount of the ROM the complete fallback image +## (including payload) will use +option FALLBACK_SIZE = 0 + + + +romimage "normal" + option USE_FALLBACK_IMAGE=0 +# option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" +# payload ../../../../../../../memtest86/memtest +# payload ../../../../../../../etherboot/src/bin/e1000.zelf + payload ../../../../../../../etherboot/src/bin/e1000--filo.zelf +# payload ../../../../../../../QNX/BSP/images/qnxbasesmp.elf +end + +#NOTE: CMOS currently not supported due to conflicts with factory BIOS +# Thus no support for fallback boot. +#romimage "fallback" +# option USE_FALLBACK_IMAGE=1 +# option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" +# payload ../../../../../../../memtest86/memtest +# payload ../../../../../../../etherboot/src/bin/e1000.zelf +# payload ../../../../../../../etherboot/src/bin/e1000--filo.zelf +#end + +buildrom ./linuxbios.rom ROM_SIZE "normal" Modified: trunk/LinuxBIOSv2/targets/lippert/frontrunner/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/lippert/frontrunner/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/lippert/frontrunner/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -4,7 +4,7 @@ target frontrunner mainboard lippert/frontrunner -option ROM_SIZE=1024*256 +option ROM_SIZE=256*1024 romimage "normal" option USE_FALLBACK_IMAGE=0 Modified: trunk/LinuxBIOSv2/targets/motorola/sandpoint/Config.lb.ide_stream =================================================================== --- trunk/LinuxBIOSv2/targets/motorola/sandpoint/Config.lb.ide_stream 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/motorola/sandpoint/Config.lb.ide_stream 2006-09-06 16:42:51 UTC (rev 2398) @@ -57,7 +57,7 @@ option IDE_OFFSET=0 # ROM is 1Mb -option ROM_SIZE=1048576 +option ROM_SIZE=1024*1024 # Set stack and heap sizes (stage 2) option STACK_SIZE=0x10000 Modified: trunk/LinuxBIOSv2/targets/newisys/khepri/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/newisys/khepri/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/newisys/khepri/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -17,7 +17,7 @@ option CONFIG_CONSOLE_SERIAL8250=1 # Size of the image. Khepri comes with 512k per default. -option ROM_SIZE=524288 +option ROM_SIZE=512*1024 option HAVE_OPTION_TABLE=1 option CONFIG_ROM_STREAM=1 Modified: trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.kernel.lb =================================================================== --- trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.kernel.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.kernel.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -3,7 +3,7 @@ target rev_a mainboard olpc/rev_a -option ROM_SIZE=1024*128*7 +option ROM_SIZE=7*128*1024 option FALLBACK_SIZE=ROM_SIZE #romimage "normal" Modified: trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -5,7 +5,7 @@ # leave 64k for vsa option CONFIG_COMPRESSED_ROM_STREAM=0 -option ROM_SIZE=1024*512-64*1024 +option ROM_SIZE=512*1024-64*1024 option FALLBACK_SIZE=ROM_SIZE option DEFAULT_CONSOLE_LOGLEVEL = 11 Modified: trunk/LinuxBIOSv2/targets/sunw/ultra40/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/sunw/ultra40/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/sunw/ultra40/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -9,13 +9,13 @@ # sunw ultra40 romimage "normal" # 48K for SCSI FW -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 # 64K for NIC option 48K for Raid option rom -# option ROM_SIZE = 409600 +# option ROM_SIZE = 512*1024-64*1024-48*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13800 Modified: trunk/LinuxBIOSv2/targets/totalimpact/briq/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/totalimpact/briq/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/totalimpact/briq/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -25,7 +25,7 @@ option IDE_OFFSET=0 # ROM is 1Mb -option ROM_SIZE=1048576 +option ROM_SIZE=1024*1024 # Set stack and heap sizes (stage 2) option STACK_SIZE=0x10000 Modified: trunk/LinuxBIOSv2/targets/tyan/s2735/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/tyan/s2735/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/tyan/s2735/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -8,11 +8,11 @@ # Tyan s2735 romimage "normal" # 48K for SCSI FW -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 option ROM_IMAGE_SIZE=0x11800 option XIP_ROM_SIZE=0x20000 Modified: trunk/LinuxBIOSv2/targets/tyan/s2850/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/tyan/s2850/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/tyan/s2850/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -8,11 +8,11 @@ # Tyan s2850 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x16000 Modified: trunk/LinuxBIOSv2/targets/tyan/s2875/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/tyan/s2875/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/tyan/s2875/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -8,11 +8,11 @@ # Tyan s2875 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13800 Modified: trunk/LinuxBIOSv2/targets/tyan/s2880/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/tyan/s2880/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/tyan/s2880/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -8,11 +8,11 @@ # Tyan s2880 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13800 Modified: trunk/LinuxBIOSv2/targets/tyan/s2881/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/tyan/s2881/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/tyan/s2881/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -8,11 +8,11 @@ # Tyan s2881 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13000 Modified: trunk/LinuxBIOSv2/targets/tyan/s2882/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/tyan/s2882/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/tyan/s2882/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -8,11 +8,11 @@ # Tyan s2882 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x16000 Modified: trunk/LinuxBIOSv2/targets/tyan/s2885/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/tyan/s2885/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/tyan/s2885/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -8,11 +8,11 @@ # Tyan s2895 romimage "normal" # 48K for SCSI FW -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x13800 # option ROM_IMAGE_SIZE=0x17800 Modified: trunk/LinuxBIOSv2/targets/tyan/s2891/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/tyan/s2891/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/tyan/s2891/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -8,13 +8,13 @@ # Tyan s2891 romimage "normal" # 48K for ATI ROM in 1M - option ROM_SIZE = 999424 + option ROM_SIZE = 1024*1024-48*1024 # 48K for SCSI FW or ATI ROM -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13000 Modified: trunk/LinuxBIOSv2/targets/tyan/s2891/Config.lb.com2 =================================================================== --- trunk/LinuxBIOSv2/targets/tyan/s2891/Config.lb.com2 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/tyan/s2891/Config.lb.com2 2006-09-06 16:42:51 UTC (rev 2398) @@ -8,11 +8,11 @@ # Tyan s2891 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13000 Modified: trunk/LinuxBIOSv2/targets/tyan/s2892/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/tyan/s2892/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/tyan/s2892/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -8,13 +8,13 @@ # Tyan s2892 romimage "normal" # 48K for ATI ROM in 1M - option ROM_SIZE = 999424 + option ROM_SIZE = 1024*1024-48*1024 # 48K for SCSI FW or ATI ROM -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13800 Modified: trunk/LinuxBIOSv2/targets/tyan/s2895/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/tyan/s2895/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/tyan/s2895/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -8,13 +8,13 @@ # Tyan s2895 romimage "normal" # 48K for SCSI FW -# option ROM_SIZE = 475136 +# option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 # 64K for NIC option 48K for Raid option rom -# option ROM_SIZE = 409600 +# option ROM_SIZE = 512*1024-64*1024-48*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13800 Modified: trunk/LinuxBIOSv2/targets/tyan/s4880/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/tyan/s4880/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/tyan/s4880/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -8,11 +8,11 @@ # Tyan s4880 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x19000 # option ROM_IMAGE_SIZE=0x19c00 Modified: trunk/LinuxBIOSv2/targets/tyan/s4882/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/tyan/s4882/Config.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/tyan/s4882/Config.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -8,11 +8,11 @@ # Tyan s4882 romimage "normal" # 48K for SCSI FW or ATI ROM - option ROM_SIZE = 475136 + option ROM_SIZE = 512*1024-48*1024 # 48K for SCSI FW and 48K for ATI ROM -# option ROM_SIZE = 425984 +# option ROM_SIZE = 512*1024-48*1024-48*1024 # 64K for Etherboot -# option ROM_SIZE = 458752 +# option ROM_SIZE = 512*1024-64*1024 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x19000 # option ROM_IMAGE_SIZE=0x19c00 Modified: trunk/LinuxBIOSv2/targets/via/epia/Config.512kflash.lb =================================================================== --- trunk/LinuxBIOSv2/targets/via/epia/Config.512kflash.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/via/epia/Config.512kflash.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -4,7 +4,7 @@ target epia.512kflash mainboard via/epia -option ROM_SIZE=524288 +option ROM_SIZE=512*1024 # # Via Epia Modified: trunk/LinuxBIOSv2/targets/via/epia/Config.512kflash.linuxtiny.lb =================================================================== --- trunk/LinuxBIOSv2/targets/via/epia/Config.512kflash.linuxtiny.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/via/epia/Config.512kflash.linuxtiny.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -4,7 +4,7 @@ target epia.512kflash.linuxtiny mainboard via/epia -option ROM_SIZE=524288 +option ROM_SIZE=512*1024 option FALLBACK_SIZE=ROM_SIZE option MAXIMUM_CONSOLE_LOGLEVEL=10 option DEFAULT_CONSOLE_LOGLEVEL=10 Modified: trunk/LinuxBIOSv2/targets/via/epia-m/Config-abuild.lb =================================================================== --- trunk/LinuxBIOSv2/targets/via/epia-m/Config-abuild.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/via/epia-m/Config-abuild.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -7,7 +7,7 @@ option DEFAULT_CONSOLE_LOGLEVEL=8 option CONFIG_CONSOLE_SERIAL8250=1 -option ROM_SIZE=524288 +option ROM_SIZE=512*1024 option HAVE_OPTION_TABLE=1 Modified: trunk/LinuxBIOSv2/targets/via/epia-m/Config.512kflash.lb =================================================================== --- trunk/LinuxBIOSv2/targets/via/epia-m/Config.512kflash.lb 2006-09-06 16:15:02 UTC (rev 2397) +++ trunk/LinuxBIOSv2/targets/via/epia-m/Config.512kflash.lb 2006-09-06 16:42:51 UTC (rev 2398) @@ -9,7 +9,7 @@ option DEFAULT_CONSOLE_LOGLEVEL=8 option CONFIG_CONSOLE_SERIAL8250=1 -option ROM_SIZE=524288 +option ROM_SIZE=512*1024 option HAVE_OPTION_TABLE=1 From uwe at hermann-uwe.de Wed Sep 6 18:45:51 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 6 Sep 2006 18:45:51 +0200 Subject: [LinuxBIOS] Need help on epia vt8601 issues In-Reply-To: <8a0c36780609060931m40690b70o48141bd276cf2526@mail.gmail.com> References: <8a0c36780609060931m40690b70o48141bd276cf2526@mail.gmail.com> Message-ID: <20060906164551.GA19990@aragorn> On Wed, Sep 06, 2006 at 11:31:42AM -0500, Richard Smith wrote: > If anyone has machines around with older toolchains ( or machines you > can install older toolchains on) we could really use some help trying > to get an older rev to compile. Just an idea - you could use QEMU to install an older (virtual) Linux distro which has the required tools and build everything in QEMU, then copy the files to you host OS... HTH, Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | 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 Wed Sep 6 19:03:20 2006 From: smithbone at gmail.com (Richard Smith) Date: Wed, 6 Sep 2006 12:03:20 -0500 Subject: [LinuxBIOS] Need help on epia vt8601 issues In-Reply-To: <20060906164551.GA19990@aragorn> References: <8a0c36780609060931m40690b70o48141bd276cf2526@mail.gmail.com> <20060906164551.GA19990@aragorn> Message-ID: <8a0c36780609061003u61604b8co61791929f91cd376@mail.gmail.com> > > Just an idea - you could use QEMU to install an older (virtual) Linux distro > which has the required tools and build everything in QEMU, then copy the > files to you host OS... > My idea for Alex exactly but I thought I'd put out a larger call. I don't currently have the cycles available. I went a bit overbudget last night. So all you folks asking about epia vt8601 support. Here's your chance. -- Richard A. Smith From ben at hewson-venieri.com Wed Sep 6 19:38:26 2006 From: ben at hewson-venieri.com (Ben Hewson) Date: Wed, 06 Sep 2006 18:38:26 +0100 Subject: [LinuxBIOS] Need help on epia vt8601 issues In-Reply-To: <8a0c36780609061003u61604b8co61791929f91cd376@mail.gmail.com> References: <8a0c36780609060931m40690b70o48141bd276cf2526@mail.gmail.com> <20060906164551.GA19990@aragorn> <8a0c36780609061003u61604b8co61791929f91cd376@mail.gmail.com> Message-ID: <44FF0792.8030801@hewson-venieri.com> An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Wed Sep 6 20:49:15 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Wed, 06 Sep 2006 12:49:15 -0600 Subject: [LinuxBIOS] RE : Re: VGA bios and i/o access for powerpc In-Reply-To: <44FEF676.7030008@yahoo.fr> References: <20060906054702.39098.qmail@web27508.mail.ukl.yahoo.com> <44FEE7E1.8070608@lanl.gov> <44FEF676.7030008@yahoo.fr> Message-ID: <44FF182B.1030800@lanl.gov> jf simon wrote: > Ronald G Minnich wrote: > >> jean-francois simon wrote: >> >>> Hi, >>> Maybe there is a way to do without the emulation layer altogether: >>> Since in our case we use PCI graphics, I can record all the PCI >>> cycles made by the VGA BIOS to the graphic card on a BIOS based >>> system (using a PCI analyser), put them into a listing, run a perl >>> script on it and include them in the firmware of the non BIOS >>> system....an redo the process whenever we need to use a different >>> graphic which doesn't happen very often >> >> >> >> we've had poor luck with that approach. Plus, even in graphics card of >> same model, memory programming can change quite a bit between cards. I >> am not sure this will work. >> >> ron >> > Thanks. I'll give it a quick try. If it works I'll let you know. > -jfs keep in mind that, if it works on one *instance* of a card from vendor X, it may fail on the same model card from vendor X, purchased on the same day, from the same store, on the same shelf. PC hardware is wonderful. ron From rminnich at lanl.gov Wed Sep 6 20:51:10 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Wed, 06 Sep 2006 12:51:10 -0600 Subject: [LinuxBIOS] Need help on epia vt8601 issues In-Reply-To: <8a0c36780609061003u61604b8co61791929f91cd376@mail.gmail.com> References: <8a0c36780609060931m40690b70o48141bd276cf2526@mail.gmail.com> <20060906164551.GA19990@aragorn> <8a0c36780609061003u61604b8co61791929f91cd376@mail.gmail.com> Message-ID: <44FF189E.1060703@lanl.gov> I will attempt to get you a rom image of a working linuxbios rom tonight. I have one. ron From rminnich at lanl.gov Wed Sep 6 20:52:17 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Wed, 06 Sep 2006 12:52:17 -0600 Subject: [LinuxBIOS] Need help on epia vt8601 issues In-Reply-To: <44FF0792.8030801@hewson-venieri.com> References: <8a0c36780609060931m40690b70o48141bd276cf2526@mail.gmail.com> <20060906164551.GA19990@aragorn> <8a0c36780609061003u61604b8co61791929f91cd376@mail.gmail.com> <44FF0792.8030801@hewson-venieri.com> Message-ID: <44FF18E1.8050808@lanl.gov> there's one other nasty possibility here. If the chips have been changed in some way, then it could be not linuxbios, but the chip. oh boy oh boy. ron From smithbone at gmail.com Wed Sep 6 21:13:36 2006 From: smithbone at gmail.com (Richard Smith) Date: Wed, 6 Sep 2006 14:13:36 -0500 Subject: [LinuxBIOS] Need help on epia vt8601 issues In-Reply-To: <44FF0792.8030801@hewson-venieri.com> References: <8a0c36780609060931m40690b70o48141bd276cf2526@mail.gmail.com> <20060906164551.GA19990@aragorn> <8a0c36780609061003u61604b8co61791929f91cd376@mail.gmail.com> <44FF0792.8030801@hewson-venieri.com> Message-ID: <8a0c36780609061213u57010ebfuc305e7155234e8a6@mail.gmail.com> > > I have been going over the vt8601 code, although only the stuff in > raminit.c as I assume that is probably where the problem lies. > I did pull off rev 1179 (not 100% sure) managed to build it ok, but when I > booted it, it was coming up with smbus errors. > Then tries version 1159, this wouldn't build, there were files missing. Yea! A hacker who has the hardware. > I have found a slight problem, maybe stack related ( what does linuxbios do > for a stack before ram is initialised ? ) Just like the matrix.. There is no stack. oh wait, that was spoon. sorry. Seriously. Thats waht romcc does. It compiles code that runs only with CPU registers. No stack. No RAM of any kind. > At this point register 0x64 has 0xec in it, which it shouldn't. The extra > bit(b3) is not used and should be 0. Now no where in the code is this set so > whats happening ? Thats actually a good sign. Perhaps you are finding some of the problems. > I put a print at the end of the sdram_set_registers() function and it is > wrong there also. However putting in that extra print hangs the code. So I > am thinking maybe its a stack issue. print_* uses a lot of resources. You may be running out of registers or the romcc maybe corrupting the register that has the return address. Try to be much simpler about things. Like hook up a serial terminal that can display hex values and just out() the value directly. romcc does amazing things but its still pretty easy to trip it up. > Have been through the vt8601 datasheet quite a few times now, must be one > of the worst I have seen, anyway does anyone have any idea what the "DRAM > Controller Command Register Output" bit is used for ? Ron said that the datasheet is also incorrect in some places. If you do it like the data sheet says then it doesn't work. Thats why we need to find a working version so we can figure what the magic incantation is. > Also are the any utilities to dump the northbridge register contents on a > running system ? 'lspci -s 0:0.0 -xxx' will dump the entire northbridge pci space. man lspci for more details. > What sort of tools are we talking about to compile the earlier stuff ? Older toolchains. gcc-2.95, gcc-3.x, and the various binutils that came with them. Basically grabbing some older distributions and using their toolchain. Newer toolchains have issues with older romcc. Newer romcc's have issues with the constructs in older revs. -- Richard A. Smith From smithbone at gmail.com Wed Sep 6 21:22:30 2006 From: smithbone at gmail.com (Richard Smith) Date: Wed, 6 Sep 2006 14:22:30 -0500 Subject: [LinuxBIOS] Need help on epia vt8601 issues In-Reply-To: <44FF189E.1060703@lanl.gov> References: <8a0c36780609060931m40690b70o48141bd276cf2526@mail.gmail.com> <20060906164551.GA19990@aragorn> <8a0c36780609061003u61604b8co61791929f91cd376@mail.gmail.com> <44FF189E.1060703@lanl.gov> Message-ID: <8a0c36780609061222q3b513172r37189dcf883cf0d4@mail.gmail.com> On 9/6/06, Ronald G Minnich wrote: > I will attempt to get you a rom image of a working linuxbios rom > tonight. I have one. > That would be a magic bullet. If we can boot that, dump the northbridge settings and compare vs what LB is currently doing then we know a _lot_. If they are the same then I think we have strong evidence that something in the newer chips is different. Please send it to "Alex Mauer" and cc me. -- Richard A. Smith From ben at hewson-venieri.com Wed Sep 6 22:22:45 2006 From: ben at hewson-venieri.com (Ben Hewson) Date: Wed, 06 Sep 2006 21:22:45 +0100 Subject: [LinuxBIOS] Need help on epia vt8601 issues In-Reply-To: <8a0c36780609061222q3b513172r37189dcf883cf0d4@mail.gmail.com> References: <8a0c36780609060931m40690b70o48141bd276cf2526@mail.gmail.com> <20060906164551.GA19990@aragorn> <8a0c36780609061003u61604b8co61791929f91cd376@mail.gmail.com> <44FF189E.1060703@lanl.gov> <8a0c36780609061222q3b513172r37189dcf883cf0d4@mail.gmail.com> Message-ID: <44FF2E15.7050407@hewson-venieri.com> An HTML attachment was scrubbed... URL: From stuge-linuxbios at cdy.org Thu Sep 7 02:58:24 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Thu, 7 Sep 2006 02:58:24 +0200 Subject: [LinuxBIOS] EPIA-MII 6000E 115k2, VGA and FILO on first flash In-Reply-To: <20060906074706.GA7414@coresystems.de> References: <20060906043046.20515.qmail@cdy.org> <20060906074706.GA7414@coresystems.de> Message-ID: <20060907005824.22864.qmail@cdy.org> On Wed, Sep 06, 2006 at 09:47:06AM +0200, Stefan Reinauer wrote: > * Peter Stuge [060906 06:30]: > > I picked up an EPIA-MII board a while ago and some 4Mbit flash today. > > > > It is simply amazing. Thank you, everyone who have, and continue to, > > put effort into LinuxBIOS, FILO and Etherboot! > > Very glad you like it. :-) If you are looking for CF support for FILO > 0.5, check out the latest revision and enable the line #PCMCIA_CF = 1. Right, this is as stated in the EPIA-M-howto. I applied the patch per the howto for the second flash and it probably works, but I fried my CF and haven't picked up a new one yet. (The MII CF socket requires some force to insert the CF, and required less force to insert the CF upside down.) How about those IO ports though? Apparently they're offset some ports from normal ide4 and hence Linux needs to be told ide4=noprobe to not hang, according to same howto. If still true, it's not very neat - can I do something to improve it? //Peter From cybercorecentre at gmail.com Thu Sep 7 03:07:31 2006 From: cybercorecentre at gmail.com (Jax) Date: Thu, 07 Sep 2006 03:07:31 +0200 Subject: [LinuxBIOS] Tyan S2466N bios request Message-ID: <44FF70D3.7050205@gmail.com> Hi! I want my motherboard become supported as soon as it's possible. I think there are many servers out there with this board eg. beowulf cluster computers so it's all of us interest creating a working bios. I offer my help in testing if it's safe for my computer. Thanks Regards, JaX From mark.wilkinson at 2pmtech.com Thu Sep 7 09:02:48 2006 From: mark.wilkinson at 2pmtech.com (Mark Wilkinson) Date: Thu, 07 Sep 2006 08:02:48 +0100 Subject: [LinuxBIOS] Need help on epia vt8601 issues In-Reply-To: <44FF2E15.7050407@hewson-venieri.com> References: <8a0c36780609060931m40690b70o48141bd276cf2526@mail.gmail.com> <20060906164551.GA19990@aragorn> <8a0c36780609061003u61604b8co61791929f91cd376@mail.gmail.com> <44FF189E.1060703@lanl.gov> <8a0c36780609061222q3b513172r37189dcf883cf0d4@mail.gmail.com> <44FF2E15.7050407@hewson-venieri.com> Message-ID: <44FFC418.8050909@2pmtech.com> Hello Richard, Ben, Uwe, et all I've been following this thread for a little while, and have this 2 pence ( or 2 cents for the US/rest of Europe) to add. Based on the conversations, I've pulled the following rev's (based on changes to the raminit.c) and tried building using the gcc 3.4.4 toolset. *REV* *Build* *linuxbios.rom* *Reason for Failure* 1131 Failed No Target !! - looks like the via/epia target directory only exists from rev 1138 1138 no src/arc/i386/config/crt0.bast 1151 1154 1155 1156 1157 1159 1177 1179 1180 1227 1228 1259 Couldn't Parse Config file 1618 compile error - unsigned long long no supported 1619 1726 Success 1808 1952 Failed No rule to make target src/southbrigde/via/vt8231/vt8231_lpc.c needed by vt8321_lpc.o 1954 Success 1978 Output from Manufacturers Bios :- 00:00.0 Host bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia] (rev 05) 00: 06 11 01 06 06 00 90 a2 05 00 00 06 00 08 00 00 10: 08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 10 60 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: fe df c8 98 00 00 10 10 80 00 08 10 10 10 10 10 60: 3f 2a 00 20 e6 95 95 c4 42 ac 65 0d 08 7f 00 00 70: c0 88 ec 0c 0e 81 52 00 01 f4 01 00 00 00 00 00 80: 0f 40 00 00 00 00 00 00 03 00 68 07 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 00 20 00 07 02 00 07 00 00 00 00 6e 02 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 01 01 22 42 00 b0 00 08 00 00 Out of the 4 successes, I've trued the first 2 and have only gotten as far as the 'vt8601 done' I've not modified the code to dump the registers yet, and the problem could be that the default config of PC100 and CL3 doesn't work for my ram which is causing it to hang after the raminit. Hope this helps. I'm going to try and get my system here install with serveral version of the gcc toolchain if I can If there's anything you want me to try, or a particular version of gcc to try, I'll give it a go if I can as I'd love to see this board (I have both an epia 800 and epia 5000 ) working on LBv2 just as it did uner LBv1 Regards Mark Wilkinson. Ben Hewson wrote: > Richard Smith wrote: > >>On 9/6/06, Ronald G Minnich wrote: >> >> >>>I will attempt to get you a rom image of a working linuxbios rom >>>tonight. I have one. >>> >>> >>> >> >>That would be a magic bullet. If we can boot that, dump the >>northbridge settings and compare vs what LB is currently doing then we >>know a _lot_. If they are the same then I think we have strong >>evidence that something in the newer chips is different. >> >>Please send it to "Alex Mauer" and cc me. >> >> >> > when I get another PSU I'll boot my board up with the original bios > and dump the northbridge settings. > The board I am working on is rev D. I have another board in use as a > firewall and that is a rev A so I could possibly see if that works any > better or if there are any details. > > There are a couple of bits in the code I don't quite get. Also the > VT8601A datasheet mentions a BIOS porting guide. Does anyone have a > copy of that. The actual VT8601A datasheet doesn't go into any detail > on configuring ram. > > Have also been looking at an SDRAM datasheet to see how that gets > initialised. One of the bits I don't quite get is writing the SDRAM > mode register (either 0x150 or 0x1d0 ). Can't see how that matches up > to the SDRAM mode register bits and would'nt the MA mapping have an > effect on that. The MA mapping register doesn't get written until later. > > > Currently using v3 something of gcc will need to check, again when I > get a PSU. > > Ben > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at coresystems.de Thu Sep 7 13:21:35 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 7 Sep 2006 13:21:35 +0200 Subject: [LinuxBIOS] (fwd) Re: USB bootloader Message-ID: <20060907112135.GA27624@coresystems.de> Hi, anyone has an idea on this one? ----- Forwarded message from Al Boldi ----- Date: Thu, 7 Sep 2006 13:52:28 +0300 From: Al Boldi To: Stefan Reinauer Cc: openbios at lists.openbios.org, etherboot-discuss at lists.sourceforge.net Subject: Re: USB bootloader Thanks for your response! Stefan Reinauer wrote: > * Al Boldi [060904 20:58]: > > FILO version 0.5 .... > > Can't get memory map from firmware. Using hardcoded default. > > Press ... > > boot: uda1:/vmlinuz > > LinuxLabs USB bootloader > > New USB device, setting address 2 (repeats 1-4 times) > > boot: uda1:/vmlinuz > > LinuxLabs USB bootloader > > Out of heap space > > Please try increasing the heap space in i386/ldscript by changing the > following lines: > /* 16KB heap and stack */ > HEAP_SIZE = 16384; > to > /* 32KB heap and 16K stack */ > HEAP_SIZE = 32768; > > > And, how can filo 0.5 be fixed to boot USB? > > If the message stays, try all the way up to 262144. Ok, the message is gone, but it still does not boot. Turning on debug repeats this: FILO version 0.5 (root at localhost) Thu Sep 7 13:40:13 AST 2006 collect_sys_info: boot eax = 0x0 collect_sys_info: boot ebx = 0x0 collect_sys_info: boot arg = 0xfeee330 collect_elfboot_info: Bootloader: Etherboot collect_elfboot_info: Version: 5.4.1 malloc_diag: alloc: 0 bytes (0 blocks), free: 262136 bytes (1 blocks) malloc_diag: alloc: 16 bytes (1 blocks), free: 262120 bytes (1 blocks) collect_elfboot_info: Image name: /tftpboot/boot/pxelinux.0 malloc_diag: alloc: 32 bytes (2 blocks), free: 262104 bytes (1 blocks) collect_linuxbios_info: Searching for LinuxBIOS tables... Can't get memory map from firmware. Using hardcoded default. malloc_diag: alloc: 72 bytes (3 blocks), free: 262064 bytes (1 blocks) collect_sys_info: 0000000000000000-00000000000a0000 collect_sys_info: 0000000000100000-0000000002000000 collect_sys_info: RAM 32 MB relocate: Current location: 0x100000-0x16d827 relocate: Relocating to 0x1f927d0-0x1fffff7... ok setup_timers: CPU 413 MHz pci_init: Scanning PCI: found 9 devices malloc_diag: alloc: 192 bytes (4 blocks), free: 261944 bytes (1 blocks) pci_init: 00:00.0 8086:7120 0600 00 pci_init: 00:01.0 8086:7121 0300 00 pci_init: 00:1e.0 8086:2418 0604 00 pci_init: 01:04.0 1282:9102 0200 00 pci_init: 01:05.0 10ec:8139 0200 00 pci_init: 01:0a.0 1191:8040 0100 00 pci_init: 00:1f.0 8086:2410 0601 00 pci_init: 00:1f.1 8086:2411 0101 80 pci_init: 00:1f.2 8086:2412 0c03 00 boot: uda1:/vmlinuz malloc_diag: alloc: 216 bytes (5 blocks), free: 261920 bytes (1 blocks) malloc_diag: alloc: 232 bytes (6 blocks), free: 261904 bytes (1 blocks) file_open: dev=uda1, path=/vmlinuz LinuxLabs USB bootloader uhc_init: Found UHCI at ffffd000 uhc_reset: Resetting UHCI uhc_init: uhc_init setting framelist to: 01e927d0 uhc_start: Starting UHCI dump_uhci: HCI at ffffd000 malloc_diag: alloc: 8432 bytes (7 blocks), free: 253704 bytes (1 blocks) init_framelist: frame_list is at 12a000 dump_link: frame_list_link: addr: 00125850 dump_link: frame_list_link: raw addr: 1fb8020 dump_link: frame_list_link: terminate: 0 dump_link: frame_list_link: queue: 1 dump_link: frame_list_link: depth: 0 malloc_diag: alloc: 11512 bytes (8 blocks), free: 250624 bytes (1 blocks) poll_usb: poll_usb1 i=0 poll_u_root_hub1 v=00001083 poll_u_root_hub2 v=00001083 poll_u_root_hub21 v=00001083 Connection on port d010 New USB device, setting address 2 uhci_control_msg: uhci_control_msg: request_type = 0 request = 5 wLength=0 malloc_diag: alloc: 15616 bytes (9 blocks), free: 246520 bytes (1 blocks) dump_uhci: HCI at ffffd000 dump_td: failed_transaction: TD(0011d860): dump_td: failed_transaction: type: SETUP dump_td: failed_transaction: retries: 3 dump_td: failed_transaction: IOC dump_td: failed_transaction: active: 0001 dump_td: failed_transaction: device_addr: 00 dump_td: failed_transaction: endpoint: 0 dump_td: failed_transaction: data_toggle: 0 dump_td: failed_transaction: max_transfer: 7 dump_td: failed_transaction: actual: 0 dump_td: failed_transaction: link: dump_link: failed_transaction: addr: 0011d880 dump_link: failed_transaction: raw addr: 1fb0050 dump_link: failed_transaction: terminate: 0 dump_link: failed_transaction: queue: 0 dump_link: failed_transaction: depth: 0 dump_td: failed_transaction: TD(0011d880): dump_td: failed_transaction: type: IN dump_td: failed_transaction: retries: 0 dump_td: failed_transaction: active: 0001 dump_td: failed_transaction: device_addr: 00 dump_td: failed_transaction: endpoint: 0 dump_td: failed_transaction: data_toggle: 1 dump_td: failed_transaction: max_transfer: 7ff dump_td: failed_transaction: actual: 0 dump_td: failed_transaction: link: dump_link: failed_transaction: addr: fe16d830 dump_link: failed_transaction: raw addr: 0000 dump_link: failed_transaction: terminate: 1 dump_link: failed_transaction: queue: 0 dump_link: failed_transaction: depth: 0 malloc_diag: alloc: 11512 bytes (8 blocks), free: 250624 bytes (1 blocks) configure_device: configure_device: set_address failed! poll_u_root_hub: poll_u_root_hub1 v=00001080 poll_usb1 i=0 poll_u_root_hub1 v=00001083 poll_u_root_hub2 v=00001083 poll_u_root_hub21 v=00001083 Connection on port d010 New USB device, setting address 2 uhci_control_msg: uhci_control_msg: request_type = 0 request = 5 wLength=0 malloc_diag: alloc: 15616 bytes (9 blocks), free: 246520 bytes (1 blocks) dump_uhci: HCI at ffffd000 dump_td: failed_transaction: TD(0011d860): dump_td: failed_transaction: type: SETUP dump_td: failed_transaction: retries: 3 dump_td: failed_transaction: IOC dump_td: failed_transaction: active: 0001 dump_td: failed_transaction: device_addr: 00 dump_td: failed_transaction: endpoint: 0 dump_td: failed_transaction: data_toggle: 0 dump_td: failed_transaction: max_transfer: 7 dump_td: failed_transaction: actual: 0 dump_td: failed_transaction: link: dump_link: failed_transaction: addr: 0011d880 dump_link: failed_transaction: raw addr: 1fb0050 dump_link: failed_transaction: terminate: 0 dump_link: failed_transaction: queue: 0 dump_link: failed_transaction: depth: 0 dump_td: failed_transaction: TD(0011d880): dump_td: failed_transaction: type: IN dump_td: failed_transaction: retries: 0 dump_td: failed_transaction: active: 0001 dump_td: failed_transaction: device_addr: 00 dump_td: failed_transaction: endpoint: 0 dump_td: failed_transaction: data_toggle: 1 dump_td: failed_transaction: max_transfer: 7ff dump_td: failed_transaction: actual: 0 dump_td: failed_transaction: link: dump_link: failed_transaction: addr: fe16d830 dump_link: failed_transaction: raw addr: 0000 dump_link: failed_transaction: terminate: 1 dump_link: failed_transaction: queue: 0 dump_link: failed_transaction: depth: 0 malloc_diag: alloc: 11512 bytes (8 blocks), free: 250624 bytes (1 blocks) configure_device: configure_device: set_address failed! (...repeats...) Thanks again! -- Al ----- End forwarded message ----- -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From smithbone at gmail.com Thu Sep 7 17:27:25 2006 From: smithbone at gmail.com (Richard Smith) Date: Thu, 7 Sep 2006 10:27:25 -0500 Subject: [LinuxBIOS] Symposium roomate Message-ID: <8a0c36780609070827u2904b250j3f5b8892535177a2@mail.gmail.com> I'm comming to the Symposium!! Woohoo. Anybody comming that wants to share a room? I'd like try and keep my expenses down to a minimum. -- Richard A. Smith From svn at openbios.org Thu Sep 7 17:31:27 2006 From: svn at openbios.org (svn at openbios.org) Date: Thu, 07 Sep 2006 17:31:27 +0200 Subject: [LinuxBIOS] r2399 - trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a Message-ID: Author: rminnich Date: 2006-09-07 17:31:27 +0200 (Thu, 07 Sep 2006) New Revision: 2399 Modified: trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a/failover.c Log: remove dangerous call to normal image; no backup on OLPC Modified: trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a/failover.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a/failover.c 2006-09-06 16:42:51 UTC (rev 2398) +++ trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a/failover.c 2006-09-07 15:31:27 UTC (rev 2399) @@ -8,6 +8,7 @@ static unsigned long main(unsigned long bist) { +#if 0 /* This is the primary cpu how should I boot? */ if (do_normal_boot()) { goto normal_image; @@ -28,5 +29,6 @@ : /* clobbers */ ); fallback_image: +#endif return bist; } From jfaslist at yahoo.fr Thu Sep 7 17:55:46 2006 From: jfaslist at yahoo.fr (jf simon) Date: Thu, 07 Sep 2006 17:55:46 +0200 Subject: [LinuxBIOS] RE : Re: VGA bios and i/o access for powerpc In-Reply-To: <44FF182B.1030800@lanl.gov> References: <20060906054702.39098.qmail@web27508.mail.ukl.yahoo.com> <44FEE7E1.8070608@lanl.gov> <44FEF676.7030008@yahoo.fr> <44FF182B.1030800@lanl.gov> Message-ID: <45004102.3060705@yahoo.fr> Ronald G Minnich wrote: > > keep in mind that, if it works on one *instance* of a card from vendor > X, it may fail on the same model card from vendor X, purchased on the > same day, from the same store, on the same shelf. > > PC hardware is wonderful. > Thanks. I will run a trace and see first how large it is (100's or 1000's of cycles). Maybe there are pci cycles that are checking from flags to be set on the vga chipset, and these could explain the behavior differences you are mentionning, in case the flags hasn't changed to the expected value before the init process goes on. Or timings between cycles that need to be respected. I think I can write some perl script that will extract these informations from the analyser trace and produce the right C code. I hope the pci graphic card doesn't rise interrupts during that process though.. -jfs ___________________________________________________________________________ D?couvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/R?ponses pour partager vos connaissances, vos opinions et vos exp?riences. http://fr.answers.yahoo.com From stuge-linuxbios at cdy.org Thu Sep 7 21:46:42 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Thu, 7 Sep 2006 21:46:42 +0200 Subject: [LinuxBIOS] EPIA-MII RL5C476 CF and Linux Message-ID: <20060907194642.14264.qmail@cdy.org> southbridge/ricoh/rl5c476/rl5c476.c configures the CF slot to use io ports 0x1e0 through 0x1ef. There are some comments in the file explaining that this is done because "the pcmcia package within Linux then could not re-initialise the device as it tried to take control of it." but maybe this has changed now? When forcing the ide driver to look in the right place (ide2=0x1e0,0x1ec,5) it does indeed find the CF but it seems that the pccard code takes over later on since it notices that a card is inserted in slot 1. Trying to open /dev/hde once the system has booted also fails. (I'm running off NFS root for now.) Where do we want to go with this? The common case is likely a CF memory card, but on the other hand we want to support any CF device that Linux can handle in the slot. Treating the CF slot as a PCMCIA slot appears to require an initrd, which I'd like to avoid if possible. (My kernel has ide-cs, but it doesn't pick up the CF card even though pccard reports it is inserted.) Treating the CF slot as an IDE drive will work for LB, FILO and kernel when booting off of a CF card, but is useless for people wanting to use some other CF device. Is the problem really that I haven't set up PCMCIA properly in my kernel? (I would expect ide-cs to attach to the card when pccard says there's something in the slot?) Shouldn't this happen by way of the pccardd kernel thread? I really don't want an initrd with pcmcia-cs just for this.. //Peter From yinghailu at gmail.com Thu Sep 7 22:11:36 2006 From: yinghailu at gmail.com (yhlu) Date: Thu, 7 Sep 2006 13:11:36 -0700 Subject: [LinuxBIOS] (fwd) Re: USB bootloader In-Reply-To: <20060907112135.GA27624@coresystems.de> References: <20060907112135.GA27624@coresystems.de> Message-ID: <2ea3fae10609071311ke3cd53bi6b906774b9ba874@mail.gmail.com> did you try filo on Etherboot? I remember I first tried out on UHCI, and then added OHCI support. YH On 9/7/06, Stefan Reinauer wrote: > Hi, > > anyone has an idea on this one? > > ----- Forwarded message from Al Boldi ----- > > Date: Thu, 7 Sep 2006 13:52:28 +0300 > From: Al Boldi > To: Stefan Reinauer > Cc: openbios at lists.openbios.org, etherboot-discuss at lists.sourceforge.net > Subject: Re: USB bootloader > > > Thanks for your response! > > Stefan Reinauer wrote: > > * Al Boldi [060904 20:58]: > > > FILO version 0.5 .... > > > Can't get memory map from firmware. Using hardcoded default. > > > Press ... > > > boot: uda1:/vmlinuz > > > LinuxLabs USB bootloader > > > New USB device, setting address 2 (repeats 1-4 times) > > > boot: uda1:/vmlinuz > > > LinuxLabs USB bootloader > > > Out of heap space > > > > Please try increasing the heap space in i386/ldscript by changing the > > following lines: > > /* 16KB heap and stack */ > > HEAP_SIZE = 16384; > > to > > /* 32KB heap and 16K stack */ > > HEAP_SIZE = 32768; > > > > > And, how can filo 0.5 be fixed to boot USB? > > > > If the message stays, try all the way up to 262144. > > Ok, the message is gone, but it still does not boot. > > Turning on debug repeats this: > > FILO version 0.5 (root at localhost) Thu Sep 7 13:40:13 AST 2006 > collect_sys_info: boot eax = 0x0 > collect_sys_info: boot ebx = 0x0 > collect_sys_info: boot arg = 0xfeee330 > collect_elfboot_info: Bootloader: Etherboot > collect_elfboot_info: Version: 5.4.1 > malloc_diag: alloc: 0 bytes (0 blocks), free: 262136 bytes (1 blocks) > malloc_diag: alloc: 16 bytes (1 blocks), free: 262120 bytes (1 blocks) > collect_elfboot_info: Image name: /tftpboot/boot/pxelinux.0 > malloc_diag: alloc: 32 bytes (2 blocks), free: 262104 bytes (1 blocks) > collect_linuxbios_info: Searching for LinuxBIOS tables... > Can't get memory map from firmware. Using hardcoded default. > malloc_diag: alloc: 72 bytes (3 blocks), free: 262064 bytes (1 blocks) > collect_sys_info: 0000000000000000-00000000000a0000 > collect_sys_info: 0000000000100000-0000000002000000 > collect_sys_info: RAM 32 MB > relocate: Current location: 0x100000-0x16d827 > relocate: Relocating to 0x1f927d0-0x1fffff7... ok > setup_timers: CPU 413 MHz > pci_init: Scanning PCI: found 9 devices > malloc_diag: alloc: 192 bytes (4 blocks), free: 261944 bytes (1 blocks) > pci_init: 00:00.0 8086:7120 0600 00 > pci_init: 00:01.0 8086:7121 0300 00 > pci_init: 00:1e.0 8086:2418 0604 00 > pci_init: 01:04.0 1282:9102 0200 00 > pci_init: 01:05.0 10ec:8139 0200 00 > pci_init: 01:0a.0 1191:8040 0100 00 > pci_init: 00:1f.0 8086:2410 0601 00 > pci_init: 00:1f.1 8086:2411 0101 80 > pci_init: 00:1f.2 8086:2412 0c03 00 > > boot: uda1:/vmlinuz > malloc_diag: alloc: 216 bytes (5 blocks), free: 261920 bytes (1 blocks) > malloc_diag: alloc: 232 bytes (6 blocks), free: 261904 bytes (1 blocks) > file_open: dev=uda1, path=/vmlinuz > LinuxLabs USB bootloader > uhc_init: Found UHCI at ffffd000 > uhc_reset: Resetting UHCI > uhc_init: uhc_init setting framelist to: 01e927d0 > uhc_start: Starting UHCI > dump_uhci: HCI at ffffd000 > malloc_diag: alloc: 8432 bytes (7 blocks), free: 253704 bytes (1 blocks) > init_framelist: frame_list is at 12a000 > dump_link: frame_list_link: addr: 00125850 > dump_link: frame_list_link: raw addr: 1fb8020 > dump_link: frame_list_link: terminate: 0 > dump_link: frame_list_link: queue: 1 > dump_link: frame_list_link: depth: 0 > malloc_diag: alloc: 11512 bytes (8 blocks), free: 250624 bytes (1 blocks) > poll_usb: poll_usb1 i=0 poll_u_root_hub1 v=00001083 poll_u_root_hub2 > v=00001083 poll_u_root_hub21 v=00001083 Connection on port d010 > New USB device, setting address 2 > uhci_control_msg: uhci_control_msg: request_type = 0 request = 5 wLength=0 > malloc_diag: alloc: 15616 bytes (9 blocks), free: 246520 bytes (1 blocks) > dump_uhci: HCI at ffffd000 > dump_td: failed_transaction: TD(0011d860): > dump_td: failed_transaction: type: SETUP > dump_td: failed_transaction: retries: 3 > dump_td: failed_transaction: IOC > dump_td: failed_transaction: active: 0001 > dump_td: failed_transaction: device_addr: 00 > dump_td: failed_transaction: endpoint: 0 > dump_td: failed_transaction: data_toggle: 0 > dump_td: failed_transaction: max_transfer: 7 > dump_td: failed_transaction: actual: 0 > dump_td: failed_transaction: link: > dump_link: failed_transaction: addr: 0011d880 > dump_link: failed_transaction: raw addr: 1fb0050 > dump_link: failed_transaction: terminate: 0 > dump_link: failed_transaction: queue: 0 > dump_link: failed_transaction: depth: 0 > dump_td: failed_transaction: TD(0011d880): > dump_td: failed_transaction: type: IN > dump_td: failed_transaction: retries: 0 > dump_td: failed_transaction: active: 0001 > dump_td: failed_transaction: device_addr: 00 > dump_td: failed_transaction: endpoint: 0 > dump_td: failed_transaction: data_toggle: 1 > dump_td: failed_transaction: max_transfer: 7ff > dump_td: failed_transaction: actual: 0 > dump_td: failed_transaction: link: > dump_link: failed_transaction: addr: fe16d830 > dump_link: failed_transaction: raw addr: 0000 > dump_link: failed_transaction: terminate: 1 > dump_link: failed_transaction: queue: 0 > dump_link: failed_transaction: depth: 0 > malloc_diag: alloc: 11512 bytes (8 blocks), free: 250624 bytes (1 blocks) > configure_device: configure_device: set_address failed! > > poll_u_root_hub: poll_u_root_hub1 v=00001080 poll_usb1 i=0 poll_u_root_hub1 > v=00001083 poll_u_root_hub2 v=00001083 poll_u_root_hub21 v=00001083 > Connection on port d010 > New USB device, setting address 2 > uhci_control_msg: uhci_control_msg: request_type = 0 request = 5 wLength=0 > malloc_diag: alloc: 15616 bytes (9 blocks), free: 246520 bytes (1 blocks) > dump_uhci: HCI at ffffd000 > dump_td: failed_transaction: TD(0011d860): > dump_td: failed_transaction: type: SETUP > dump_td: failed_transaction: retries: 3 > dump_td: failed_transaction: IOC > dump_td: failed_transaction: active: 0001 > dump_td: failed_transaction: device_addr: 00 > dump_td: failed_transaction: endpoint: 0 > dump_td: failed_transaction: data_toggle: 0 > dump_td: failed_transaction: max_transfer: 7 > dump_td: failed_transaction: actual: 0 > dump_td: failed_transaction: link: > dump_link: failed_transaction: addr: 0011d880 > dump_link: failed_transaction: raw addr: 1fb0050 > dump_link: failed_transaction: terminate: 0 > dump_link: failed_transaction: queue: 0 > dump_link: failed_transaction: depth: 0 > dump_td: failed_transaction: TD(0011d880): > dump_td: failed_transaction: type: IN > dump_td: failed_transaction: retries: 0 > dump_td: failed_transaction: active: 0001 > dump_td: failed_transaction: device_addr: 00 > dump_td: failed_transaction: endpoint: 0 > dump_td: failed_transaction: data_toggle: 1 > dump_td: failed_transaction: max_transfer: 7ff > dump_td: failed_transaction: actual: 0 > dump_td: failed_transaction: link: > dump_link: failed_transaction: addr: fe16d830 > dump_link: failed_transaction: raw addr: 0000 > dump_link: failed_transaction: terminate: 1 > dump_link: failed_transaction: queue: 0 > dump_link: failed_transaction: depth: 0 > malloc_diag: alloc: 11512 bytes (8 blocks), free: 250624 bytes (1 blocks) > configure_device: configure_device: set_address failed! > > (...repeats...) > > > Thanks again! > > -- > Al > > > > ----- End forwarded message ----- > > -- > coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. > Tel.: +49 761 7668825 ? Fax: +49 761 7664613 > Email: info at coresystems.de ? http://www.coresystems.de/ > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios From uwe at hermann-uwe.de Thu Sep 7 22:19:04 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 7 Sep 2006 22:19:04 +0200 Subject: [LinuxBIOS] romcc manpage. Message-ID: <20060907201904.GC21078@aragorn> Hi, here's a preliminary manpage for romcc. Some details need to be added, e.g. the author, the extact license, bug-report address etc. Who wrote romcc, and which license applies? There's a COPYING file in the directory, so it's probably the GPL. Version 2 or v2 and later? Btw, is romcc still maintained? The romcc.c file says RELEASE_DATE "15 November 2004". Also, the test-suite doesn't build for me (I simply typed 'make'): [...] :1.0: simple_test26.c:20.26: warning: used: %mm7 :1.0: simple_test26.c:20.26: too few registers make: *** [tests/simple_test26.S-O2-mmmx] Error 1 Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org -------------- next part -------------- .\" Copyright (C) 2006 Uwe Hermann . .\" This manpage is licensed under the terms of the GNU GPL. .TH ROMCC 1 "September 7, 2006" .SH NAME romcc \- compile C programs into binaries that don't use any RAM .SH SYNOPSIS .B romcc .BR [ OPTIONS ] .IR "" ".c" .SH DESCRIPTION .B romcc is a C compiler which produces binaries which do not rely on RAM, but instead only use CPU registers. .br It is prominently used in the LinuxBIOS project to compile C code which needs to run before the (Linux)BIOS has initialized the RAM, but can be used for other purposes, too. .SH OPTIONS .B "\-o" Output file name. .PP .B "\-f