http://www.coreboot.org/api.php?action=feedcontributions&user=Rminnich&feedformat=atom 2013-05-19T12:06:58Z User contributions MediaWiki 1.20.5 http://www.coreboot.org/File:Clipper_caltrain.jpeg 2011-12-06T05:39:21Z

<p>Rminnich: </p> <hr /> <div></div>

Rminnich http://www.coreboot.org/Fun_Stuff 2011-12-06T05:38:52Z

<p>Rminnich: </p> <hr /> <div><br /> == Failure at scale ==<br /> <br /> A BIOS gets confused in a very visible way: <br /> <br /> [[File:Billboard_bios_fail.jpeg|640px]]<br /> <br /> Photo courtesy Greg Kurtzer of LBL.<br /> <br /> <br /> == What floor am I on? ==<br /> <br /> An elevator in Spain: <br /> <br /> [[File:Elevator_spain.jpeg|640px]]<br /> <br /> Photo courtesy Gorka Guardiola<br /> <br /> == Confused payphone ==<br /> <br /> A payphone in trouble. Taken during the LinuxBIOS summit in Hamburg, Germany in October 2006. Bonus: two coreboot hackers visible in the reflection.<br /> <br /> [[File:Dscn3815.jpg|640px]]<br /> <br /> Photo by Ward Vandewege<br /> <br /> == Clipper Machine ==<br /> <br /> At the Palo Alto Caltrain station<br /> <br /> [[File:Clipper_caltrain.jpeg|640px]]<br /> <br /> From Ed Swierik</div>

Rminnich http://www.coreboot.org/Fun_Stuff 2011-12-06T05:38:07Z

<p>Rminnich: </p> <hr /> <div><br /> == Failure at scale ==<br /> <br /> A BIOS gets confused in a very visible way: <br /> <br /> [[File:Billboard_bios_fail.jpeg|640px]]<br /> <br /> Photo courtesy Greg Kurtzer of LBL.<br /> <br /> <br /> == What floor am I on? ==<br /> <br /> An elevator in Spain: <br /> <br /> [[File:Elevator_spain.jpeg|640px]]<br /> <br /> Photo courtesy Gorka Guardiola<br /> <br /> == Confused payphone ==<br /> <br /> A payphone in trouble. Taken during the LinuxBIOS summit in Hamburg, Germany in October 2006. Bonus: two coreboot hackers visible in the reflection.<br /> <br /> [[File:Dscn3815.jpg|640px]]<br /> <br /> Photo by Ward Vandewege<br /> <br /> == Clipper Machine ==<br /> <br /> At the Palo Alto Caltrain station<br /> <br /> From Ed Swierik</div>

Rminnich http://www.coreboot.org/Fun_Stuff 2011-12-04T22:51:56Z

<p>Rminnich: </p> <hr /> <div><br /> == Failure at scale ==<br /> <br /> A BIOS gets confused in a very visible way: [[File:Billboard_bios_fail.jpeg]]<br /> Photo courtesy Greg Kurtzer of LBL.<br /> <br /> <br /> == What floor am I on? ==<br /> <br /> An elevator in Spain: [[File:Elevator_spain.jpeg]]<br /> <br /> Photo courtesy Gorka Guardiola</div>

Rminnich http://www.coreboot.org/File:Elevator_spain.jpeg 2011-12-04T22:50:33Z

<p>Rminnich: An elevator in Spain.</p> <hr /> <div>An elevator in Spain.</div>

Rminnich http://www.coreboot.org/Fun_Stuff 2011-12-04T22:47:44Z

<p>Rminnich: Created page with &quot; == Failure at scale == A BIOS gets confused in a very visible way: File:Billboard_bios_fail.jpeg Photo courtesy Greg Kurtzer of LBL.&quot;</p> <hr /> <div><br /> == Failure at scale ==<br /> <br /> A BIOS gets confused in a very visible way: [[File:Billboard_bios_fail.jpeg]]<br /> Photo courtesy Greg Kurtzer of LBL.</div>

Rminnich http://www.coreboot.org/File:Billboard_bios_fail.jpeg 2011-12-04T22:46:02Z

<p>Rminnich: A BIOS that fails on a very large scale</p> <hr /> <div>A BIOS that fails on a very large scale</div>

Rminnich http://www.coreboot.org/GSoC 2010-03-31T16:23:42Z

<p>Rminnich: </p> <hr /> <div>= Google Summer of Code 2010 =<br /> <br /> http://3.bp.blogspot.com/_fxRR_bT3LgA/S5U3rk2J-eI/AAAAAAAACE8/mBRYQwSqvqQ/s400/2010_NoURL_300x267px.jpg<br /> <br /> Welcome to the [http://code.google.com/soc/ Google Summer of Code(tm)] page of the [[Welcome to coreboot|coreboot project]]. Apply for a coreboot GSoC project at http://socghop.appspot.com/.<br /> <br /> This year, coreboot also tries to host some flashrom projects.<br /> <br /> == Deadlines ==<br /> <br /> Make sure you check the [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline Deadlines]<br /> <br /> = Why work for coreboot =<br /> <br /> Why would you like to work for coreboot?<br /> <br /> * coreboot offers you the opportunity to work with modern technology &quot;right on the iron&quot;.<br /> * Your application will be available to users worldwide and promoted along with all other coreboot projects.<br /> * We are a very passionate team - so you will interact directly with the project initiators and project leaders. <br /> * We have a large, helpful community. Over 100 experts in hardware and firmware lurk on our mailing list, many of them waiting to help you.<br /> <br /> <br /> = Summer of Code Application =<br /> <br /> Please complete the standard [http://code.google.com/soc/ Google SoC 2010 application]. Additionally, please provide information on the following:<br /> <br /> # Who are you? What are you studying?<br /> # Why are you the right person for this task?<br /> # Do you have any other commitments that we should know about?<br /> # List your C, Assembler and hardware experience.<br /> # List your history with open source projects.<br /> # What is your preferred method of contact? (Phone, email, Skype, etc) <br /> <br /> Feel free to keep your application short. A 15 page essay is no better than a 2 page summary. If you wish to write 15 pages, you are of course welcome to do so, and we will gladly put your paper up on the web page. But it is not required for the application.<br /> <br /> == How to apply ==<br /> <br /> The Drupal project has a great page on [http://drupal.org/node/59037 How to write an SOC application].<br /> <br /> Please also read Google's [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Advice for Students].<br /> <br /> == Some Caveats ==<br /> <br /> * Google Summer-of-Code projects are a full (day-) time job. This means we expect roughly 30-40 hours per week on your project, during the three months of coding. Obviously we have flexibility, but if your schedule (exams, courses) does not give you this amount of spare time, then maybe you should not apply.<br /> * Getting paid by Google requires that you meet certain milestones. First, you must be in good standing with the community before the official start of the program. We suggest you post some design emails to the mailing list, and get feedback on them, both before applying, and during the &quot;community bonding period&quot; between acceptance and official start. Also, you must have made progress and committed significant code before the mid-term point.<br /> * We are thinking of requiring accepted students to have a blog, where you will write about your project on a regular basis. This is so that the community at large can be involved and help you. SoC is not a private contract between your mentor and you.<br /> <br /> Note that &quot;regular basis&quot; in the last item does _not_ mean &quot;3 days before evaluation deadlines&quot;. You should be &quot;around&quot; all the time (reporting your feedback, sending in partial successes).<br /> We don't expect our students to be experts in our problem domain, but we don't want you to fail because some basic misunderstanding was in your way of completing the task.<br /> <br /> == Time Frame ==<br /> <br /> '''DEADLINE FOR STUDENT APPLICATIONS:''' Students who are interested in working on a coreboot-related GSoC project must apply between '''March 29, 2010''' and '''April 9, 2010'''! If you want to apply, please get in contact with us right away, not just when you send your application!<br /> <br /> == Student requirements ==<br /> <br /> We will only accept your proposal if you have demonstrated that you can work with our codebase. For that, you have to send a patch to the list which is acceptable. Just ask for simple tasks on the mailing list or on IRC.<br /> <br /> = Contact =<br /> <br /> If you are interested in becoming a GSoC student, please contact [mailto:stepan@coresystems.de Stefan Reinauer].<br /> <br /> There is also an IRC channel on irc.freenode.net: #coreboot<br /> <br /> = Possible ideas =<br /> <br /> == Infrastructure for automatic code checking ==<br /> <br /> We already have a build bot that builds various configurations of coreboot. It would be nice to extend it with various code validation routines, for example:<br /> * Validate that there's no regression in doxygen documentation (eg. are all arguments to functions still explained in @param tags, eg. after new arguments were added?)<br /> * Make code lint clean (and maybe extend lint to not fall into our traps), and run lint over the tree. Report regressions<br /> * Use LLVM's static code checking facilities, report regressions.<br /> * Work on code coverage support for coreboot code (dump data into ram, or via serial. Provide tools to fetch it). Analyse that data.<br /> <br /> === Links ===<br /> * LLVM tools: [http://clang.llvm.org/StaticAnalysis.html Clang static analyser], [http://llvm.org/ProjectsWithLLVM/#Calysto SSA assertion checker]<br /> * Lint tools: [http://lclint.cs.virginia.edu/ Splint]<br /> * Coverage: [http://ltp.sourceforge.net/test/coverage/lcov.php LCOV], [http://ggcov.sourceforge.net GGCOV]<br /> <br /> === Mentors ===<br /> * [[User:MJones|Marc Jones]]<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == TianoCore on coreboot ==<br /> <br /> [[Image:Tianocoreboot.png|160px|right]]<br /> <br /> [http://www.tianocore.org/ Tiano Core] is Intel's EFI implementation. Unlike coreboot, it is not a firmware, but rather a bootloader. In 2008 there was an initial port of TianoCore to run on coreboot, but there are many things left to do.<br /> <br /> * Improve Tiano Core / EDK2 running as a coreboot payload<br /> * Implement a coreboot framebuffer driver for Tiano Core<br /> * Implement a coreboot flash filesystem (CBFS) driver for Tiano Core<br /> * Integrate and automate check out and build process of Tiano Core<br /> * Create CorebootPkg using OVMF instead of DUET.<br /> * Provide a script that creates working binaries for the EDK shell, EDK apps, FAT driver(?), ...<br /> * The final work must compile on a cross gcc, and coreboot's crossgcc script has to be adapted so it can build this compiler (if the default script is not capable of doing so yet)<br /> <br /> This project requires no hardware skills, but especially in case of TianoCore will require knowledge of Microsoft compilers as well as the GNU tool chain.<br /> <br /> === Links ===<br /> * [http://www.tianocore.org/ Tiano Core]<br /> * https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/<br /> <br /> === Mentors ===<br /> * [[User:Rminnich|Ron Minnich]]<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> ==coreboot port to Marvell ARM SOC's with PCIe==<br /> [http://www.marvell.com/products/processors/embedded/kirkwood/ Marvell Processors] These ARM SOC's with PCIe will become popular in netbooks later this year. These systems can take advantage of coreboot's strength in properly configuring PCI devices, fast boot time and payload support.<br /> <br /> Note that coreboot has in the past supported three different CPUs (x86, Alpha, PPC), so the structure is there for adding in a new processor family. <br /> We will need to find the right platform to do the work, but I (Ron) can provide a board and JTAG debugger if needed. <br /> <br /> === Mentors ===<br /> * Bari Ari<br /> * [[User:Rminnich|Ron Minnich]]<br /> <br /> == coreboot port to AMD 800 series chipsets ==<br /> (probably too big of a task)<br /> :I'm not sure that this is too of a big task. I think 800 is closely related to 780 and would be slightly harder than a 780 board port. ---[[User:MJones|MJones]]<br /> <br /> === Mentors ===<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> == coreboot mass-porting to AMD 780 series mainboards ==<br /> <br /> Grab a couple of AMD 780 based mainboards and port coreboot to it.<br /> <br /> === Mentors ===<br /> * [[User:Rminnich|Ron Minnich]]<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> == coreboot panic room ==<br /> <br /> Create a safe boot solution for coreboot to easily and cheaply recover the system in case of a panic(). <br /> <br /> I would like to base this solution around SerialICE. The basic idea is that the system always boots to SerialICE. There is a test in CMOS for 'last boot worked' and, if this is set, SerialICE finds a coreboot in cbfs and runs it. If 'last boot worked' is not set, or the user hits some magic keyboard sequence, SerialICE takes control. <br /> <br /> SerialICE needs to be extended (not much) to make this work. Having this capability would make it possible for me to get some very hard ports working that are just not possible today. At the same time, there are lots of hardware boards to test this idea on, so it should be easy to get it working. <br /> <br /> === Mentors ===<br /> * [[User:Rminnich|Ron Minnich]]<br /> <br /> == coreboot cheap testing rig ==<br /> The goal of this project is to create a cheap testing rig which works with the existing board test infrastructure. We have a hardware test system since 2006:<br /> * [http://www.coresystems.de/PDFs/LinuxBIOS-testing/Slides-LinuxBIOS-QA.pdf Quality Assurance Talk (Slides)]<br /> * [http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestIntegrationManual.pdf Test Integration Manual]<br /> * [http://www.coresystems.de/PDFs/LinuxBIOS-testing/DevelopersManual.pdf Test Developers Manual]<br /> * [http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestSpecification.pdf Test Specification]<br /> <br /> The initial version of our testing rig used a remote power switch and was rather expensive. With cheaper technologies such as X10, it's possible to drop the testing costs per board significantly.<br /> <br /> === Links ===<br /> * http://qa.coresystems.de<br /> <br /> === Mentors ===<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot GeodeLX port from v3 to v4 ==<br /> <br /> significant parts of that are already done, so it's hard to fill a full GSoC with that. One thing could be &quot;verify that everything is brought over&quot;, but that's nothing that can be reasonably proven (and it might also be too close to &quot;documentation tasks&quot;, which are not allowed)<br /> <br /> === Links ===<br /> * ?<br /> <br /> === Mentors ===<br /> * ?<br /> <br /> == drivers for libpayload ==<br /> <br /> IDE, AHCI, Bluetooth, Firewire, Smartcards, maybe filesystems. Work towards making FILO only a shell, which uses libpayload for the &quot;real&quot; work.<br /> <br /> Notice that libpayload code must be licensed BSD-style (so ports from FILO, SeaBIOS or Linux won't work).<br /> Pick a given set and tell us why it's enough work for the allocated time, but not too much for you. Also, which sources (if any) you want to draw from. We will not accept code that has been taken from other (GPL) projects. If you are taking this project you have to be willing and capable of writing your own hardware drivers.<br /> <br /> === Links ===<br /> * ?<br /> <br /> === Mentors ===<br /> * Stefan Reinauer<br /> <br /> == Board config infrastructure ==<br /> <br /> Design data structures that host information about the board layout so coreboot can better initialize components and generate all kinds of tables (mptable, pirq, acpi, ...) from that dynamically (at build or runtime, as appropriate). Adapt boards to use that instead of the current hardcodes.<br /> <br /> === Links ===<br /> * ?<br /> <br /> === Mentors ===<br /> * ?<br /> <br /> == Refactor AMD code ==<br /> <br /> AMD K8 and AMD Fam10 are different enough to have their own code. This is unfortunate, as you have to decide which CPU type you use in a given mainboard. Refactor AMD code so a single image can support both chip types on a given board. Also move tables from get_bus_conf and the like to the device tree or kconfig options (or runtime detection), as appropriate.<br /> <br /> === Links ===<br /> * ?<br /> <br /> === Mentors ===<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == Payload infrastructure ==<br /> <br /> Incorporate payload building into the coreboot build. kconfig options could be added for supported payloads, those payload could be updated to build with kconfig as well. Payloads that build with libpayload need would need default configs. Payloads should also be built with the crossgcc tools. This is related to the libpayload and board config infrastructure above. ---[[User:MJones|MJones]]<br /> <br /> === Links ===<br /> * ?<br /> <br /> === Mentors ===<br /> * ?<br /> <br /> == flashrom ==<br /> <br /> Note: The list below is an idea collection. Individual list items are simple enough to serve only as partial GSoC task, but they are grouped to reasonable tasks. If you're interested, please talk to us on the flashrom mailing list and/or on IRC irc://irc.freenode.net/#flashrom<br /> <br /> ''[http://www.flashrom.org/GSoC/2010 http://www.flashrom.org/GSoC/2010] has more flashrom ideas and suggestions.''<br /> <br /> === Multiple GUIs for flashrom ===<br /> <br /> * flashrom text mode GUI (for command line and flashrom-as-payload)<br /> * flashrom graphics mode GUI (should be cross-platform, Sean Nelson has preliminary code you can base this on)<br /> <br /> === Recovery of dead boards and onboard flash updates ===<br /> <br /> * flashrom as payload<br /> * flashrom remote flashing for coreboot panic room mode<br /> * flashrom remote flashing with modified SerialICE<br /> <br /> === SPI bitbanging hardware support ===<br /> <br /> * flashrom support for Nvidia SPI chipset hardware<br /> * flashrom support for RayeR SPIPGM hardware<br /> * flashrom support for [[Paraflasher]] hardware<br /> * flashrom support for Willem hardware<br /> * flashrom support for some-yet-uninvented cheap universal LPC/FWH/SPI flasher hardware<br /> * flashrom support for bitbanging LPC/FWH (code exists, Uwe Hermann <br /> * flashrom support for bitbanging Parallel<br /> <br /> === Generic flashrom infrastructure improvements ===<br /> <br /> * flashrom support for automatic recovery in case something goes wrong<br /> * flashrom support for partial reflashing<br /> * flashrom support for bytewise flashing (similar to the point above)<br /> <br /> === Laptop support ===<br /> <br /> This one is really HARD. If you're lucky and if you have datasheets, you can do it in maybe 1 month. If you're unlucky, it can take the whole GSoC or more. If there is interest, we'll try to find an embeddec controller which won't cause you to give up in frustration. Still, it might be beneficial if you're willing to solder.<br /> * flashrom support for embedded controllers (ECs) in laptops<br /> <br /> <br /> === Links ===<br /> * [http://www.flashrom.org/ flashrom]<br /> <br /> === Mentors ===<br /> * ?<br /> <br /> == Your own Project Ideas ==<br /> <br /> We have come up with some ideas for cool Summer of Code projects here. These are projects that we think can be managed in the short period of GSoC, and they cover areas where coreboot is trying to reach new users and new use cases.<br /> <br /> But of course your application does not need to be based on any of the ideas listed below. The opposite: Maybe you have a great idea that we just didn't think of yet. Please let us know!<br /> <br /> Feel free to contact us at the email address above, and don't hesitate to suggest whatever you have in mind.<br /> <br /> = Previous Summer of Code projects =<br /> <br /> We successfully participated in Google's Summer of Code in 2007, 2008 and 2009. See our [[Previous GSoC Projects|list of previous GSoC projects]].</div>

Rminnich http://www.coreboot.org/GSoC 2010-03-31T16:21:53Z

<p>Rminnich: </p> <hr /> <div>= Google Summer of Code 2010 =<br /> <br /> http://3.bp.blogspot.com/_fxRR_bT3LgA/S5U3rk2J-eI/AAAAAAAACE8/mBRYQwSqvqQ/s400/2010_NoURL_300x267px.jpg<br /> <br /> Welcome to the [http://code.google.com/soc/ Google Summer of Code(tm)] page of the [[Welcome to coreboot|coreboot project]]. Apply for a coreboot GSoC project at http://socghop.appspot.com/.<br /> <br /> This year, coreboot also tries to host some flashrom projects.<br /> <br /> == Deadlines ==<br /> <br /> Make sure you check the [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline Deadlines]<br /> <br /> = Why work for coreboot =<br /> <br /> Why would you like to work for coreboot?<br /> <br /> * coreboot offers you the opportunity to work with modern technology &quot;right on the iron&quot;.<br /> * Your application will be available to users worldwide and promoted along with all other coreboot projects.<br /> * We are a very passionate team - so you will interact directly with the project initiators and project leaders. <br /> * We have a large, helpful community. Over 100 experts in hardware and firmware lurk on our mailing list, many of them waiting to help you.<br /> <br /> <br /> = Summer of Code Application =<br /> <br /> Please complete the standard [http://code.google.com/soc/ Google SoC 2010 application]. Additionally, please provide information on the following:<br /> <br /> # Who are you? What are you studying?<br /> # Why are you the right person for this task?<br /> # Do you have any other commitments that we should know about?<br /> # List your C, Assembler and hardware experience.<br /> # List your history with open source projects.<br /> # What is your preferred method of contact? (Phone, email, Skype, etc) <br /> <br /> Feel free to keep your application short. A 15 page essay is no better than a 2 page summary. If you wish to write 15 pages, you are of course welcome to do so, and we will gladly put your paper up on the web page. But it is not required for the application.<br /> <br /> == How to apply ==<br /> <br /> The Drupal project has a great page on [http://drupal.org/node/59037 How to write an SOC application].<br /> <br /> Please also read Google's [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Advice for Students].<br /> <br /> == Some Caveats ==<br /> <br /> * Google Summer-of-Code projects are a full (day-) time job. This means we expect roughly 30-40 hours per week on your project, during the three months of coding. Obviously we have flexibility, but if your schedule (exams, courses) does not give you this amount of spare time, then maybe you should not apply.<br /> * Getting paid by Google requires that you meet certain milestones. First, you must be in good standing with the community before the official start of the program. We suggest you post some design emails to the mailing list, and get feedback on them, both before applying, and during the &quot;community bonding period&quot; between acceptance and official start. Also, you must have made progress and committed significant code before the mid-term point.<br /> * We are thinking of requiring accepted students to have a blog, where you will write about your project on a regular basis. This is so that the community at large can be involved and help you. SoC is not a private contract between your mentor and you.<br /> <br /> Note that &quot;regular basis&quot; in the last item does _not_ mean &quot;3 days before evaluation deadlines&quot;. You should be &quot;around&quot; all the time (reporting your feedback, sending in partial successes).<br /> We don't expect our students to be experts in our problem domain, but we don't want you to fail because some basic misunderstanding was in your way of completing the task.<br /> <br /> == Time Frame ==<br /> <br /> '''DEADLINE FOR STUDENT APPLICATIONS:''' Students who are interested in working on a coreboot-related GSoC project must apply between '''March 29, 2010''' and '''April 9, 2010'''! If you want to apply, please get in contact with us right away, not just when you send your application!<br /> <br /> == Student requirements ==<br /> <br /> We will only accept your proposal if you have demonstrated that you can work with our codebase. For that, you have to send a patch to the list which is acceptable. Just ask for simple tasks on the mailing list or on IRC.<br /> <br /> = Contact =<br /> <br /> If you are interested in becoming a GSoC student, please contact [mailto:stepan@coresystems.de Stefan Reinauer].<br /> <br /> There is also an IRC channel on irc.freenode.net: #coreboot<br /> <br /> = Possible ideas =<br /> <br /> == Infrastructure for automatic code checking ==<br /> <br /> We already have a build bot that builds various configurations of coreboot. It would be nice to extend it with various code validation routines, for example:<br /> * Validate that there's no regression in doxygen documentation (eg. are all arguments to functions still explained in @param tags, eg. after new arguments were added?)<br /> * Make code lint clean (and maybe extend lint to not fall into our traps), and run lint over the tree. Report regressions<br /> * Use LLVM's static code checking facilities, report regressions.<br /> * Work on code coverage support for coreboot code (dump data into ram, or via serial. Provide tools to fetch it). Analyse that data.<br /> <br /> === Links ===<br /> * LLVM tools: [http://clang.llvm.org/StaticAnalysis.html Clang static analyser], [http://llvm.org/ProjectsWithLLVM/#Calysto SSA assertion checker]<br /> * Lint tools: [http://lclint.cs.virginia.edu/ Splint]<br /> * Coverage: [http://ltp.sourceforge.net/test/coverage/lcov.php LCOV], [http://ggcov.sourceforge.net GGCOV]<br /> <br /> === Mentors ===<br /> * [[User:MJones|Marc Jones]]<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == TianoCore on coreboot ==<br /> <br /> [[Image:Tianocoreboot.png|160px|right]]<br /> <br /> [http://www.tianocore.org/ Tiano Core] is Intel's EFI implementation. Unlike coreboot, it is not a firmware, but rather a bootloader. In 2008 there was an initial port of TianoCore to run on coreboot, but there are many things left to do.<br /> <br /> * Improve Tiano Core / EDK2 running as a coreboot payload<br /> * Implement a coreboot framebuffer driver for Tiano Core<br /> * Implement a coreboot flash filesystem (CBFS) driver for Tiano Core<br /> * Integrate and automate check out and build process of Tiano Core<br /> * Create CorebootPkg using OVMF instead of DUET.<br /> * Provide a script that creates working binaries for the EDK shell, EDK apps, FAT driver(?), ...<br /> * The final work must compile on a cross gcc, and coreboot's crossgcc script has to be adapted so it can build this compiler (if the default script is not capable of doing so yet)<br /> <br /> This project requires no hardware skills, but especially in case of TianoCore will require knowledge of Microsoft compilers as well as the GNU tool chain.<br /> <br /> === Links ===<br /> * [http://www.tianocore.org/ Tiano Core]<br /> * https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/<br /> <br /> === Mentors ===<br /> * [[User:Rminnich|Ron Minnich]]<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> ==coreboot port to Marvell ARM SOC's with PCIe==<br /> [http://www.marvell.com/products/processors/embedded/kirkwood/ Marvell Processors] These ARM SOC's with PCIe will become popular in netbooks later this year. These systems can take advantage of coreboot's strength in properly configuring PCI devices, fast boot time and payload support.<br /> <br /> === Mentors ===<br /> * Bari Ari<br /> <br /> == coreboot port to AMD 800 series chipsets ==<br /> (probably too big of a task)<br /> :I'm not sure that this is too of a big task. I think 800 is closely related to 780 and would be slightly harder than a 780 board port. ---[[User:MJones|MJones]]<br /> <br /> === Mentors ===<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> == coreboot mass-porting to AMD 780 series mainboards ==<br /> <br /> Grab a couple of AMD 780 based mainboards and port coreboot to it.<br /> <br /> === Mentors ===<br /> * [[User:Rminnich|Ron Minnich]]<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> == coreboot panic room ==<br /> <br /> Create a safe boot solution for coreboot to easily and cheaply recover the system in case of a panic(). <br /> <br /> I would like to base this solution around SerialICE. The basic idea is that the system always boots to SerialICE. There is a test in CMOS for 'last boot worked' and, if this is set, SerialICE finds a coreboot in cbfs and runs it. If 'last boot worked' is not set, or the user hits some magic keyboard sequence, SerialICE takes control. <br /> <br /> SerialICE needs to be extended (not much) to make this work. Having this capability would make it possible for me to get some very hard ports working that are just not possible today. At the same time, there are lots of hardware boards to test this idea on, so it should be easy to get it working. <br /> <br /> === Mentors ===<br /> * [[User:Rminnich|Ron Minnich]]<br /> <br /> == coreboot cheap testing rig ==<br /> The goal of this project is to create a cheap testing rig which works with the existing board test infrastructure. We have a hardware test system since 2006:<br /> * [http://www.coresystems.de/PDFs/LinuxBIOS-testing/Slides-LinuxBIOS-QA.pdf Quality Assurance Talk (Slides)]<br /> * [http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestIntegrationManual.pdf Test Integration Manual]<br /> * [http://www.coresystems.de/PDFs/LinuxBIOS-testing/DevelopersManual.pdf Test Developers Manual]<br /> * [http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestSpecification.pdf Test Specification]<br /> <br /> The initial version of our testing rig used a remote power switch and was rather expensive. With cheaper technologies such as X10, it's possible to drop the testing costs per board significantly.<br /> <br /> === Links ===<br /> * http://qa.coresystems.de<br /> <br /> === Mentors ===<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot GeodeLX port from v3 to v4 ==<br /> <br /> significant parts of that are already done, so it's hard to fill a full GSoC with that. One thing could be &quot;verify that everything is brought over&quot;, but that's nothing that can be reasonably proven (and it might also be too close to &quot;documentation tasks&quot;, which are not allowed)<br /> <br /> === Links ===<br /> * ?<br /> <br /> === Mentors ===<br /> * ?<br /> <br /> == drivers for libpayload ==<br /> <br /> IDE, AHCI, Bluetooth, Firewire, Smartcards, maybe filesystems. Work towards making FILO only a shell, which uses libpayload for the &quot;real&quot; work.<br /> <br /> Notice that libpayload code must be licensed BSD-style (so ports from FILO, SeaBIOS or Linux won't work).<br /> Pick a given set and tell us why it's enough work for the allocated time, but not too much for you. Also, which sources (if any) you want to draw from. We will not accept code that has been taken from other (GPL) projects. If you are taking this project you have to be willing and capable of writing your own hardware drivers.<br /> <br /> === Links ===<br /> * ?<br /> <br /> === Mentors ===<br /> * Stefan Reinauer<br /> <br /> == Board config infrastructure ==<br /> <br /> Design data structures that host information about the board layout so coreboot can better initialize components and generate all kinds of tables (mptable, pirq, acpi, ...) from that dynamically (at build or runtime, as appropriate). Adapt boards to use that instead of the current hardcodes.<br /> <br /> === Links ===<br /> * ?<br /> <br /> === Mentors ===<br /> * ?<br /> <br /> == Refactor AMD code ==<br /> <br /> AMD K8 and AMD Fam10 are different enough to have their own code. This is unfortunate, as you have to decide which CPU type you use in a given mainboard. Refactor AMD code so a single image can support both chip types on a given board. Also move tables from get_bus_conf and the like to the device tree or kconfig options (or runtime detection), as appropriate.<br /> <br /> === Links ===<br /> * ?<br /> <br /> === Mentors ===<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == Payload infrastructure ==<br /> <br /> Incorporate payload building into the coreboot build. kconfig options could be added for supported payloads, those payload could be updated to build with kconfig as well. Payloads that build with libpayload need would need default configs. Payloads should also be built with the crossgcc tools. This is related to the libpayload and board config infrastructure above. ---[[User:MJones|MJones]]<br /> <br /> === Links ===<br /> * ?<br /> <br /> === Mentors ===<br /> * ?<br /> <br /> == flashrom ==<br /> <br /> Note: The list below is an idea collection. Individual list items are simple enough to serve only as partial GSoC task, but they are grouped to reasonable tasks. If you're interested, please talk to us on the flashrom mailing list and/or on IRC irc://irc.freenode.net/#flashrom<br /> <br /> ''[http://www.flashrom.org/GSoC/2010 http://www.flashrom.org/GSoC/2010] has more flashrom ideas and suggestions.''<br /> <br /> === Multiple GUIs for flashrom ===<br /> <br /> * flashrom text mode GUI (for command line and flashrom-as-payload)<br /> * flashrom graphics mode GUI (should be cross-platform, Sean Nelson has preliminary code you can base this on)<br /> <br /> === Recovery of dead boards and onboard flash updates ===<br /> <br /> * flashrom as payload<br /> * flashrom remote flashing for coreboot panic room mode<br /> * flashrom remote flashing with modified SerialICE<br /> <br /> === SPI bitbanging hardware support ===<br /> <br /> * flashrom support for Nvidia SPI chipset hardware<br /> * flashrom support for RayeR SPIPGM hardware<br /> * flashrom support for [[Paraflasher]] hardware<br /> * flashrom support for Willem hardware<br /> * flashrom support for some-yet-uninvented cheap universal LPC/FWH/SPI flasher hardware<br /> * flashrom support for bitbanging LPC/FWH (code exists, Uwe Hermann <br /> * flashrom support for bitbanging Parallel<br /> <br /> === Generic flashrom infrastructure improvements ===<br /> <br /> * flashrom support for automatic recovery in case something goes wrong<br /> * flashrom support for partial reflashing<br /> * flashrom support for bytewise flashing (similar to the point above)<br /> <br /> === Laptop support ===<br /> <br /> This one is really HARD. If you're lucky and if you have datasheets, you can do it in maybe 1 month. If you're unlucky, it can take the whole GSoC or more. If there is interest, we'll try to find an embeddec controller which won't cause you to give up in frustration. Still, it might be beneficial if you're willing to solder.<br /> * flashrom support for embedded controllers (ECs) in laptops<br /> <br /> <br /> === Links ===<br /> * [http://www.flashrom.org/ flashrom]<br /> <br /> === Mentors ===<br /> * ?<br /> <br /> == Your own Project Ideas ==<br /> <br /> We have come up with some ideas for cool Summer of Code projects here. These are projects that we think can be managed in the short period of GSoC, and they cover areas where coreboot is trying to reach new users and new use cases.<br /> <br /> But of course your application does not need to be based on any of the ideas listed below. The opposite: Maybe you have a great idea that we just didn't think of yet. Please let us know!<br /> <br /> Feel free to contact us at the email address above, and don't hesitate to suggest whatever you have in mind.<br /> <br /> = Previous Summer of Code projects =<br /> <br /> We successfully participated in Google's Summer of Code in 2007, 2008 and 2009. See our [[Previous GSoC Projects|list of previous GSoC projects]].</div>

Rminnich http://www.coreboot.org/FAQ 2008-09-04T23:55:16Z

<p>Rminnich: Update the location of the compiler.</p> <hr /> <div>== General ==<br /> <br /> === What is coreboot? ===<br /> <br /> coreboot (formerly known as LinuxBIOS) is a Free Software project aimed at replacing the proprietary BIOS (firmware) you can find in most of today's computers.<br /> <br /> It performs just a little bit of hardware initialization and then executes a so-called [[Payloads|payload]].<br /> <br /> Some of the many possible payloads are: a [[Linux]] kernel, [[FILO]], [[GRUB2]], [http://www.openbios.org/ OpenBIOS], [http://www.openbios.org/Open_Firmware Open Firmware], [http://www.openbios.org/SmartFirmware SmartFirmware], [http://www.gnu.org/software/gnufi/ GNUFI] (UEFI), [[Etherboot]], [[ADLO]] (for booting [http://en.wikipedia.org/wiki/Windows_2000 Windows 2000] and [http://openbsd.org/ OpenBSD]), [[Plan 9]], or [[memtest86]].<br /> <br /> The initial motivation for the project was maintenance of large clusters, but unsurprisingly, interest and contributions have come from people with varying backgrounds. The latest version of coreboot can be used in a wide variety of scenarios including clusters, embedded systems, desktop PCs, servers, and more.<br /> <br /> For more information, see [[History]].<br /> <br /> === Why do we need coreboot? ===<br /> <br /> ==== Why do we need coreboot for cluster maintainance? ====<br /> <br /> Current PCs used as cluster nodes depend on a vendor-supplied BIOS for booting. The BIOS in turn relies on inherently unreliable devices such as floppy disks and hard drives to boot the operating system. In addition, current BIOS software is unable to accommodate non-standard hardware making it difficult to support experimental work. The BIOS is slow and often erroneous and redundant and, most importantly, maintenance is a nightmare. Imagine walking around with a keyboard and monitor to every one of the 128 nodes in a cluster to change one BIOS setting. <br /> <br /> coreboot with Linux as a [[Payloads|payload]] (other payloads are possible!) gunzip's the Linux kernel straight out of NVRAM and essentially requires no moving parts other than the fan. It does a minimal amount of hardware initialization before jumping to the kernel start and lets Linux do the rest. As a result, it is much faster (current record 3 seconds), which has sparked interest in the consumer electronics community as well. Moreover, updates can be performed over the network. <br /> <br /> Using a real operating system to boot another operating system provides much greater flexibility than using a simple netboot program or the BIOS. Because Linux is the boot mechanism, it can boot over standard Ethernet or over other interconnects such as Myrinet, Quadrics, or SCI. It can use SSH connections to load the kernel, or it can use the InterMezzo caching file system or traditional NFS. Cluster nodes can be as simple as they need to be – perhaps as simple as a CPU and memory, no disk, no floppy, and no file system. The nodes will be much less autonomous thus making them easier to maintain.<br /> <br /> ==== Why do we need coreboot for other purposes? ====<br /> <br /> Some aspects of DRM are not travelling well with the idea of a free computer system. As many computer magazines already pointed out, there may be future restrictions imposed by BIOSes, that a customer is little aware of before purchase and might not harmonize with the idea of freedom and/or security in some cases.<br /> <br /> === Who is working on coreboot? ===<br /> <br /> The coreboot project was started in the winter of 1999 in the Advanced Computing Laboratory at Los Alamos National Laboratory (LANL) by [[User:Rminnich|Ron Minnich]]. Two undergraduate students, James Hendricks and Dale Webster spent their winter vacation putting together the proof of concept implementation. <br /> <br /> Since then, a [[Contributors|long list of people have contributed]] both in discussions and actual code. Please don't be shy and let us know if you are missing from the list. It's not a purposeful omission, just an unfortunate mistake.<br /> <br /> === Who is funding coreboot? ===<br /> <br /> The LinuxBIOS project is funded by the Los Alamos Computer Science Institute and the Department of Energy's Office of Science.<br /> <br /> See also the [[Sponsors|list of LinuxBIOS sponsors]].<br /> <br /> == Users ==<br /> <br /> === Will coreboot work on my machine? ===<br /> <br /> See the [[Supported Motherboards]] page for which mainboards are supported, and also the list of [[Supported Chipsets and Devices]]. See the [[Products]] page for a list of vendors selling products running coreboot.<br /> <br /> If the above sources don't help, please send the following to the [[Mailinglist|mailing list]]:<br /> <br /> * Step 1: A very brief description of your system: CPU, northbridge, southbridge, mainboard and optionally other important details.<br /> * Step 2: Linux lspci output for your system, generated by booting Linux via the original BIOS and runnning lspci.<br /> * Step 3: Super I/O chip on the mainboard (report the model numbers on the actual chip, for example &quot;Winbond W83627HF&quot;).<br /> * Step 4: Type of BIOS device (see the question &quot;How do I identify the BIOS chip on my mainboard?&quot; below).<br /> * Step 5: URL to the mainboard specifications page (optional).<br /> * Step 6: Any other relevant information you can provide.<br /> <br /> If you can't do step 1 above, please describe (as best you can) the specific CPU chip and the chipset used on the mainboard.<br /> <br /> Usually in less than a day, someone will respond on the coreboot mailing list saying your mainboard is supported in the main coreboot source tree, it is currently in development, it is not yet supported or the manufacturer will not release information needed to provide coreboot support. In the latter case, please let the manufacturer know that you want coreboot support and his failure to release chipset information is making that very difficult.<br /> <br /> === What commercial products use coreboot? ===<br /> <br /> See the [[products]] page.<br /> <br /> === Which different operating systems will coreboot boot? ===<br /> <br /> coreboot should support almost any modern operating system '''which does not make [http://en.wikipedia.org/wiki/BIOS_interrupt_call BIOS calls]''':<br /> <br /> * Linux (of course)<br /> * Plan 9<br /> * Windows 2000 (via [[ADLO]])<br /> <br /> coreboot does '''not''' support:<br /> <br /> * We have tested some of the BSD OSes and have seen, that FreeBSD for example makes BIOS calls, which is not supported by coreboot. Possibly with help of the tool ''ADLO'', it may be possible to boot FreeBSD like it is now, but the right thing to do, is to remove FreeBSD's dependence on BIOS calls.<br /> * any DOS <br /> * Windows versions older than Windows 2000 (they make BIOS calls) &amp;mdash; (Does [[ADLO]] work with those versions?)<br /> * [http://www.menuetos.net/ MenuetOS] (makes BIOS calls)<br /> <br /> It appears feasible, however, to introduce some &quot;legacy support&quot; to coreboot in the future to support OSes like the abovementioned.<br /> <br /> === What chipsets and Super I/O devices are supported? ===<br /> <br /> See the [[Supported Chipsets and Devices]] page.<br /> <br /> === Where is the mailing list archived? ===<br /> <br /> See [[Mailinglist]].<br /> <br /> === Is there a coreboot IRC channel? ===<br /> <br /> Yes, see [[IRC]].<br /> <br /> === Where do I get the code? ===<br /> <br /> See the [[Download LinuxBIOS|download page]].<br /> <br /> === How do I build coreboot? ===<br /> <br /> See the [[documentation]].<br /> <br /> === How can I help with coreboot? ===<br /> <br /> There are many ways how you can help us:<br /> * Promote coreboot, tell all your friends about it, blog about it etc.<br /> * Test coreboot, [http://tracker.linuxbios.org/trac/LinuxBIOS/newticket report] any bugs you find, or let us know about any suggestions for improvements you have.<br /> * Help us to make the list of [[Supported Motherboards]] and the list of [[Supported Chipsets and Devices]] bigger by contributing code. Please also read the [[Development Guidelines]] in that case.<br /> * If you have a mainboard with USB2 (EHCI-controller) you can look if it supports the ''[[EHCI_Debug_Port|Debug Port]]'' and mail the information to us, if it is not already there.<br /> * If you are familiar with microcontroller development, you might be able to build a debugging tool for the [[EHCI_Debug_Port|Debug Port]]. If you are successful, we like to hear about it.<br /> * Test, if QNX or Solaris are able to boot on a mainboard with coreboot.<br /> * Have a look at the [http://tracker.linuxbios.org/trac/LinuxBIOS/report/1 list of open issues/bugs] and try to reproduce them or (preferrably) fix them.<br /> * Contact [[User:Rminnich|Ron Minnich]] or [[User:Stepan|Stefan Reinauer]] for bigger projects related to coreboot.<br /> * Contact us on the [[Mailinglist|mailing list]] if you have any further questions or suggestions.<br /> <br /> === What do the abbreviations in this wiki stand for? ===<br /> <br /> See [[Glossary]].<br /> <br /> == Developers ==<br /> <br /> === Where can I buy BIOS chips (empty or pre-flashed)? ===<br /> <br /> When developing or simply trying out coreboot you always need a means to revert to your old BIOS in case something goes wrong. One way to do this is to get an extra BIOS chip (PLCC or DIP) and copy your original BIOS image onto that chip (using [[Flashrom]], for example). If you have a socketed BIOS (not soldered onto the mainboard), you can hot-swap the chips while your computer is running. <br /> <br /> You have several options to get spare BIOS chips:<br /> * Most local or online electronics dealers carry some, for example:<br /> ** Germany:<br /> *** http://www.bios-chip.de<br /> *** http://www.bios-fix.de<br /> *** http://www.bios-shop.com<br /> *** http://www.bios-chips.com<br /> *** http://www.conrad.de<br /> *** http://www.endrich.com/de/site.php/47385 (it's unknown whether they ship small quantities)<br /> *** http://www.chip-service.de<br /> ** UK:<br /> *** http://bios-repair.co.uk/<br /> ** US:<br /> *** http://avnet.com<br /> *** http://mouser.com<br /> *** http://semiconductorstore.com/<br /> * You can search eBay for BIOS chips (either empty ones or pre-flashed ones).<br /> * You can rip out chips from old/broken mainboards and re-use them (you can check flea markets, eBay, etc. for cheap and/or broken mainboards).<br /> <br /> === What kind of hardware tools do I need? ===<br /> <br /> A motherboard (or mainboard as coreboot calls it) that has a supported chipset on it. Ok... well not exactly. As long as you have the documentation for the chipset/mainboard and it's free of any NDA issues you can use an unsupported chipset/mainboard, but you have a twisty road ahead of you.<br /> <br /> And of course you need a Linux development machine. The coreboot build environment is not supported on Windows. It may be possible to do it under cygwin but nobody has tried.<br /> <br /> It's also handy to have one/some/all of the following:<br /> <br /> ==== PLAICE Programmer, Logic Analyzer and In-Circuit Emulator ====<br /> <br /> [http://flash-plaice.wikispaces.com PLAICE (In Development)] see also [http://hardware.slashdot.org/article.pl?sid=07/05/01/0017244 /.slashdot ]<br /> The PLAICE is a powerful in circuit development tool that combines the features of programming and emulating FLASH devices as well as high speed multi-channel logic analysis into one device.<br /> <br /> The FLASH BIOS emulator feature will help speed development of coreboot porting since the developer will no longer have to wait for either swapping FLASH devices or for lengthy FLASH programming cycles.<br /> <br /> The design will also perform as a multi-channel logic analyzer with a JAVA client.<br /> <br /> The PLAICE will make use of an adapter cable that will interface to the mainboard via the FLASH BIOS socket or onto the pins of a soldered in place FLASH device. It may also be used to program a FLASH device or emulate a FLASH device in circuit. Since the PLAICE attaches directly to the in-circuit FLASH device, the FLASH may be programmed without the need to reverse engineer any FLASH WRITE/ENABLE &quot;security through obscurity&quot; protection schemes incorporated into a mainboard.<br /> <br /> ==== Artecgroup programmable LPC dongle ====<br /> <br /> [http://www.artecgroup.com/products/hardware-products/programmable-lpc-dongle.html] and [http://www.opencores.org/projects.cgi/web/usb_dongle_fpga/overview]<br /> <br /> ==== PC Engines lpc1A ====<br /> <br /> [http://pcengines.ch/lpc1a.htm This board] is most useful if you are working on machines from the ALIX family, but could also be useful if you can expose an LPC header on another board.<br /> <br /> ==== External EPROM/Flash programmer that can program the flash on your motherboard ====<br /> <br /> external programmers are not always necessary. Use your mainboard as a programmer instead. Boot up with a known-good image, then unplug the plcc32 while powered on.<br /> Reflash that secondary piece and try a reboot. Many boards allow for more than one type of flash to be programmed, but clearly are less versatile than real programmers.<br /> <br /> * [http://www.mcumall.com/ Willem Universal EPROM Programmer] DOS,Windows software, work has started on Linux drivers, quite many types of eprom asf. ~ €35<br /> * [http://www.loet.de/flasher_en.html IDE adapter for PLCC32 &amp; DIP32 sockets] Has Linux 2.4 &amp; 2.6 drivers $/€ ~48 (kit €33) free manual with schematics &amp; component list downloadable (component cost approx. €5)<br /> * [http://www.conitec.net/english/software.htm GALEP-4] Has [http://www.conitec.net/hardware/down/galep-linux-alpha1.html beta linux drivers] ~$300. See [[Galep IV]] for a description on how to get the more modern windows software working in Linux with wine<br /> <br /> ==== Bios Savior ====<br /> <br /> [[Image:Bios savior.jpg|thumb|right|An installed BIOS saviour.]]<br /> <br /> A tool that plugs into and replaces the original mainboard Flash device. The BIOS Savior has its own Flash device and a socket for the original mainboard Flash device. The Bios Savior features a switch to allow the developer to choose between which Flash device is accessed by the mainboard during read and write cycles.<br /> <br /> * http://www.ioss.com.tw/web/English/RD1BIOSSavior.html<br /> * http://www.cwlinux.com/eng/products/products_lbmb.php<br /> <br /> ==== Top Hat Flash ====<br /> <br /> A similar function is achieved by the &quot;'''top hat flash'''&quot; which comes at no extra cost with many Elitegroup, and some Gigabyte and Albatron mainboards like ECS KN3 SLI2 Extreme with MCP55 southbridge (which is getting severely out of stock around central europe as of 8/2007 unfortunately). After bootup, it can manually be lifted off the original BIOS chip, so the original BIOS can be reflashed after a failure. /rst is wired to /oe on the spare chip otherwise 1:1. top hat flash is equipped with a Winbond W39V040AP FWH. It may rely on particular circuitry on the mainboard to operate.<br /> <br /> [[Image:Top_hat_flash.JPG|thumb|right|Top Hat Flash, PCB side to flip over soldered-on PLCC.]]<br /> <br /> ==== Chip removal tools ====<br /> <br /> If you're hot-swapping your BIOS chips (i.e., removing the chip while your computer is running, then inserting another one) you'll usually need some tools.<br /> <br /> There are different tools for DIP and PLCC chips (see photos). You can find them in most electronics stores, usually. Both types cost roughly 5-10 Euros.<br /> <br /> Another very nifty idea is [http://www.linuxbios.org/pipermail/linuxbios/2007-April/019809.html clipping off the needle point of normal office push pins], and then attaching them to (PLCC) ROM chips with super glue. That makes it pretty easy to insert and remove the ROM chips without extra tools.<br /> <br /> Since after bootup, flash mem is not accessed anymore, you can even hot plug (plug in and out '''while PC powered on''') push pin flashes. This way you save an external eprom programmer and mimic the procedure of top hat flash. Make sure you do not short circuit anything, though.<br /> <br /> &lt;gallery&gt;<br /> Image:Plcc tool.jpg|PLCC BIOS removal tool.<br /> Image:Dip tool.jpg|DIP BIOS removal tool.<br /> Image:Pushpin roms 1.jpg|Push pins with cut off needles, attached to ROM chips with super glue.<br /> Image:Pushpin roms 2.jpg|More push pins on ROM chips.<br /> &lt;/gallery&gt;<br /> <br /> ==== POST card ====<br /> <br /> A POST card will save your life: it's the only output device (beside beeper) you have during the boot process. The term POST means Power On Self Test and comes from the original IBM specifications for the BIOS. Port 80 is a pre-defined port to which programs can output a byte. The POST card displays the byte in hex on its 2 digit display. We use a lot of POST codes in coreboot, so if you can tell us the POST code you see, we will have some idea of what happened. <br /> <br /> If your coreboot machine is working properly, you will see it count up from 0xd0 to 0xd9 (while it is gunzipping the kernel) and then display 0x98 (Linux idle loop). There are POST cards with ISA bus, PCI bus, USB und parallel port connectors (the latter for laptops).<br /> <br /> Often they carry status LEDs for ISA/PCI signals such as: IRDY, BIOS-access, FRAME, OSC, PCI-CLK, RESET, 12V, -12V, 5V, -5V, 3.3V. Some cards were known to not function because the mainboard switches off the CLK on their slot after non-standard registration on PCI.<br /> <br /> &lt;gallery&gt;<br /> Image:Post card1.jpg|BIOS POST card for PCI.<br /> Image:Post card2.jpg|BIOS POST card for PCI and ISA.<br /> &lt;/gallery&gt;<br /> <br /> PCI POST cards can be found in various places.<br /> <br /> See also [http://www.linuxbios.org/FAQ#How_can_I_write_to_port_0x80_from_userspace.3F How can I write to port 0x80 from userspace].<br /> <br /> * http://siliconkit.dnsalias.com/cart/index.tpcip.html<br /> * http://www.elstonsystems.com/prod/pc_analyzer.html<br /> * http://shopv2.elstonsystems.com/product_info.php/products_id/57<br /> * http://www.uxd.com/trio.html<br /> * http://www.soyousa.com/products/proddesc.php?id=261<br /> <br /> ==== Null-modem cable ====<br /> <br /> A so-called null-modem cable is used for transmitting the output from a serial coreboot (or GRUB- or Linux-) console to another computer where a terminal program (such as [[minicom]]) can be used to display/save the messages.<br /> <br /> &lt;gallery&gt;<br /> Image:Null modem cable.jpg|A null-modem cable.<br /> &lt;/gallery&gt;<br /> <br /> ==== Compact Flash IDE adaptor ====<br /> <br /> solid state disk save time during the repeated boot process compared with regular hard disks.<br /> <br /> * http://siliconkit.dnsalias.com/cart/index.tcfdp.html<br /> * http://www.cwlinux.com/eng/products/products_ide2cf.php<br /> * http://www.mini-box.com/s.nl/sc.8/category.14/.f<br /> * http://www.acscontrol.com/Index_ACS.asp?Page=/Pages/Products/CompactFlash/IDE_To_CF_Adapter.htm<br /> * http://www.pcengines.ch/cflash.htm<br /> * http://www.psism.com/adcf.htm<br /> * http://www.hsc-us.com/industrial/adapter/ATP.html (2xCF, one with hotswap!)<br /> * http://www.mesanet.com/ (Choose DISK EMULATORS then CFADPTHD in the menu. 2xCF)<br /> <br /> ==== Oscilloscope ====<br /> <br /> For hardware debugging purposes when it goes down the most atomic details. Consider '''logic analyzers''' as alternative.<br /> <br /> ==== In Circuit Emulator hardware debugger ====<br /> <br /> allows very time-saving burn/debug cycles with added tracing capabilities but somewhat costly. Ownership makes you a true geek, however ;-)<br /> <br /> ==== coreboot SDK ====<br /> <br /> * http://www.cwlinux.com/eng/products/products_sdk.php<br /> <br /> ==== In Circuit chip programmer ====<br /> <br /> Should allow you to program your BIOS even if it is soldered to the motherboard.<br /> <br /> * http://www.xeltek.com/pages.php?pageid=8<br /> <br /> ==== EPROM emulators ====<br /> <br /> These hardware devices pretend to be an EPROM chip.<br /> <br /> * http://www.tech-tools.com/romtools.htm<br /> * http://xtronics.com/memory/pktROM.htm<br /> * http://www.tribalmicro.com/multirom/<br /> * http://www.linuxselfhelp.com/HOWTO/Diskless-HOWTO-10.html (a larger list -- outdated)<br /> <br /> ==== USB debug devices ====<br /> <br /> An alternative to a serial console may be a USB debug device. They are not so common yet. Their advantage is higher speed than a serial console. One might hook an FPGA to it for profiling purposes or some automated checks. Accessing a USB debug device from within BIOS is not different than other USB devices, and is part of the USB standard.<br /> <br /> See also [[EHCI Debug Port]].<br /> <br /> === How do I use a null-modem cable to get coreboot debugging output over a serial port? ===<br /> <br /> * First, you'll want to set up a terminal program, e.g. '''minicom''' correctly.<br /> $ minicom -s<br /> -&gt; Serial port setup<br /> -&gt; Press A and enter your COM device (ttyS0 or ttyS1 or ttyUSB0, depending on your COM port)<br /> -&gt; Press E and choose &quot;115200 8N1&quot; (default)<br /> -&gt; Disable Hardware and Software Flow Control (via F and G)<br /> -&gt; Press enter to leave the menu<br /> -&gt; Save setup as..<br /> -&gt; Enter &quot;lb&quot;<br /> -&gt; Exit from minicom<br /> * From now on, you can start minicom with the obove settings simply by typing:<br /> $ minicom -o lb<br /> <br /> === What documentation do I need? ===<br /> <br /> As much documentation as you can possibly get your hands on. At minimum, you will need the docs for the chipset.<br /> <br /> There have been reports of people getting coreboot working by booting with the OEM BIOS. Then, they would read the static contents of the PCI config registers after boot. coreboot is then built to match the static contents read from the PCI config registers. <br /> <br /> The problem with this approach is that chipsets generally require dynamic vs static configuration values during their initialization. The configuration register contents will change from one stage of initialization to the next. Since the contents of the registers read is only the final state of the configuration registers, the chipset won't be properly initialized if these are the only configuration values used.<br /> <br /> Getting a mainboard up without chipset docs can be a very long and involved process.<br /> <br /> === What if my chipset docs are covered by an NDA? ===<br /> <br /> If the documentation for your chipset covered by a NDA with no source release agreement, you won't be able to release your code back to the coreboot project in general, or you will violate the GPL.<br /> Many vendors accept releasing the source code, produced after reading such specs, while they don't allow the specs themselves to be revealed. Also, you can offer them the opportunity to review your code, before releasing it to the public.<br /> <br /> === Why is the code so complicated and what can I do to make it easier? ===<br /> <br /> The reason is the complexity of the problem. We support a lot of hardware, and a given chip on a given board will most likely not be configured quite the same as the same chip on some other board. To help make code navigation easier, pick a target and build that target. Then, in the build directory, type make tags or make etags to get your favorite tags file. <br /> <br /> === How do I contribute my changes? ===<br /> <br /> Please carefully read the [http://linuxbios.org/Development_Guidelines Development Guidelines] for more information.<br /> <br /> === How do I identify the BIOS chip on my mainboard? ===<br /> <br /> Modern mainboards store the BIOS in a reprogrammable flash ROM chip. There are hundreds of different flash ROMs, with variables such as memory size, speed, communication bus (LPC vs. ISA/PCI) and packaging to name just a few. The three most common packages are called DIP, PLCC and TSOP. The BIOS copyright holders often place a fancy sticker on the BIOS chip showing a name or logotype, BIOS version, serial number and copyright notice.<br /> <br /> ==== DIP: Dual In-line Package ====<br /> <br /> [[Image:ROM BIOS.jpg|thumb|right|A DIP BIOS chip.]]<br /> <br /> A rectangular black plastic block with lots of pins along the two longer sides of the package. DIP ROMs can be socketed which means they are detachable from the mainboard using physical force. Since they haven't been moved in and out of the socket very much (yet, hehe) they can appear to be quite difficult to release from the socket. One way to remove a DIP from a socket is by prying a thin screwdriver in between the plastic package and the socket, along the shorter sides where there are no pins, and then gently bending the screwdriver to push the DIP upwards, away from the mainboard. Alternate between the two sides to avoid bending the pins, and don't touch any of the pins with the screwdriver, see FAQ about ESD, electro-static discharge. If the DIP is soldered directly to the mainboard, it has to be desoldered in order to be reprogrammed outside the mainboard. If you do this, it's a good idea to solder a socket to the mainboard instead, to ease any future experiments.<br /> <br /> ==== PLCC: Plastic Leaded Chip Carrier ====<br /> <br /> [[Image:2 W39V040BPZ.png|thumb|right|A socketed PLCC BIOS chip.]]<br /> <br /> Black plastic block again, but this one is much more square. PLCC is becoming the standard for mainboards because of it's smaller physical size. PLCC can also be socketed or soldered directly to the mainboard. Socketed PLCC chips can be removed using a special PLCC removal tool, or using a piece of nylon line tied in a loop around the chip and pulled swiftly straight up, or bending/prying using small screwdrivers if one is careful. PLCC sockets are often fragile so the screwdriver approach is not recommended. While the nylon line method sounds onorthodox it works well. Desoldering PLCC can be painful without specialized desoldering equipment particularly because PLCC chips have leads on all four sides of the package.<br /> <br /> ==== TSOP: Thin Small-Outline Package ====<br /> <br /> [http://www.isipkg.com/images/adp_tsop_dip.jpg TSOP chip on a TSOP-&gt;DIP adapter]<br /> <br /> TSOPs are often used in embedded systems where size is important and there is no need for replacement in the field. It is possible to (de)solder TSOPs by hand, but it comes close to wizardry.<br /> <br /> === How do I (re-)flash the BIOS? ===<br /> <br /> ==== Out of mainboard BIOS (re)flash ====<br /> <br /> If the BIOS chip is socketed, it can be removed and flashed in a rom/flash burner and quickly re-installed. Some of these burners cost $1000 and more plus they complete a flash in 1-2 minutes, but if you are willing to wait 5 minutes for a flash and manually set DIP switches, The Enhanced Willem Universal Programmer will do the job for only $40-60 USD. There are several models of the Willem Programmer, each supporting many chips, but not all, so be sure to get one that supports your BIOS chip. If your chip is PLCC, you will also need a PLCC chip extractor/puller or just thread nylon string under the PLCC chip from corner to corner and yank up it straight up.<br /> <br /> ==== Inside mainboard BIOS (re)flash ====<br /> <br /> Download the appropriate flash update utility. Build the romimage as explained above and use the flash update utility to update the BIOS. Be warned that not all update utilities allow you to load your own BIOS image. For example, Intel decided to disallow it for the MS440GX mainboard (probably after hearing about us!) Here are some mainboard specific directions: <br /> <br /> ===== General =====<br /> coreboot v2 contains a flash utility called flashrom in the util/flashrom directory. (Old versions had &quot;util/flash_and_burn/flash_rom&quot; instead).<br /> <br /> Example:<br /> bash$ sudo ./flashrom -V<br /> Calibrating delay loop... Setting up microsecond timing loop<br /> 216M loops per second<br /> ok<br /> Found canidate at: 00000530-00000bc4<br /> Found LinuxBIOS table at: 00000530<br /> lb_table found at address 0xb7e1c530<br /> LinuxBIOS header(24) checksum: 404a table(1684) checksum: 2766 entries: 14<br /> vendor id: via part id: epia-m<br /> Enabling flash write on VT8235...OK<br /> Trying Am29F040B, 512 KB<br /> probe_29f040b: id1 0x20, id2 0xe2<br /> Trying ST29F040B, 512 KB<br /> probe_29f040b: id1 0x20, id2 0xe2<br /> ST29F040B found at physical address: 0xfff80000<br /> Flash part is ST29F040B<br /> OK, only ENABLING flash write, but NOT FLASHING.<br /> <br /> <br /> If neither utility supports your chip, then you could either use the DOS [http://www.uniflash.org/ uniflash] utility, or use its source code, which is also available for download from the uniflash site (in Turbo Pascal 7) as a reference for adding support for your flash chip to &quot;flash_rom&quot;. Uniflash supports a lot of different flash chips, and chip interfaces. It has untested support for PCI expansion card flash BIOS, such as on RTL8139 Ethernet card (32pin DIL), which allows flashing on the NIC if manufacturer provides the circuitry.<br /> Another tool which runs in linux is [http://sourceforge.net/projects/ctflasher/ flasher].<br /> <br /> ===== SiS 630/950 M/Bs =====<br /> Ollie Lho provided us with flash utilities for these boards under freebios/util/sis. <br /> flash_on turns on the flash write enable. This needs to be run before loading the DoC drivers. <br /> flash_rom allows you to use your SiS 630/950 M/Bs as a flash programmer. It currently supports JEDEC flash parts, AMD am29f040b models, MXIC MX29F002 models, and SST28SF040C models. <br /> <br /> ===== Intel L440GX =====<br /> Get the System Update Package directly from Intel. mcopy the ten files created from running make phlash onto the Intel flash burner disk and use the update utility to burn the BIOS. To restore the original BIOS, set the recovery boot jumper on the motherboard, put the floppy in, and it will load and reflash the original BIOS. <br /> How do I actually burn a flash ROM? <br /> <br /> Buy your favorite flash burner (we use a Needham Electronics EMP 30). Use make floppy to create the romimage and copy it to a floppy. Then use the provided software to burn the flash.<br /> <br /> <br /> ===== BIOS Savior RD1 =====<br /> <br /> [http://www.ioss.com.tw/web/English/RD1BIOSSavior.html BIOS Savior RD1]<br /> <br /> There are some posts about the BIOS Savior RD1 that suggest its integrated flash device is of low quality; it may take 10 or more flash programming attempts to get a good update to the RD1 flash device. As a result, the following steps have proven to be successful while using the RD1:<br /> <br /> * Step 1 - While the system is powered down, remove the original BIOS device from the mainboard and insert it into the RD1's socket.<br /> <br /> * Step 2 - Insert the RD1 into the mainboard's flash BIOS socket.<br /> <br /> * Step 3 - Boot the system with the RD1 set to boot from the original flash device from the mainboard.<br /> <br /> * Step 4 - Program the original BIOS image (or other known good BIOS image) into the RD1's integrated flash device. Do this as many times as needed until the device is properly programmed and the system boots corectly from the RD1's integrated flash device. Be sure to check the settings on the RD1 so that the proper flash device is now being programmed. If the RD1 is not set correctly the working BIOS image will be erased and the system will not boot!<br /> <br /> * Step 5 - Program the test BIOS image (usually coreboot images are among this group) into the original flash device from the mainboard. The original BIOS device usually programs OK on the first attempt. Be sure to check the settings again on the RD1 so that the proper flash device is being programmed!<br /> <br /> <br /> The RD1 has been used in the above fashion with great success on the Tyan S2885 mainboard. Unfortunately the RD1 does not work on the nVidia CK8-04 CRB mainboard. The CK8-04 CRB may require a flash device that the RD1 does not support. <br /> <br /> The RD1 has worked well as a &quot;do nothing&quot; adapter that allows swapping the BIOS flash device between a flash burner and a mainboard without any wear to the mainboard's BIOS socket.<br /> <br /> === Can I do any serious damage mucking around with this stuff? ===<br /> <br /> Any time you stick your hand into an open machine while the power is on, you're risking life and limb. That said, there are also some other not-so-nice things that can happen if you mess up (not that we would know). <br /> <br /> * Incorrect insertion of the flash (1 casualty) <br /> * Incorrect jumper settings (1 casualty) <br /> * Aggressive and/or inappropriate use of metal objects such as screwdrivers (2 casualties) <br /> * Miscellaneous miswirings and mishandlings (3+ casualties)<br /> <br /> remember: make sure your important data is on a disconnected drive while you experiment.<br /> <br /> === A note on electrostatic discharge (ESD) and ESD protection (thanks to Bari Ari) ===<br /> <br /> ESD can damage disk drives, boards, DoC's and other parts. The majority of the time, ESD events cause the component to degrade, but not fail testing procedures, resulting in failure at a later date. Because components do not fail immediately, technicians often underestimate the cost of not using ESD prevention measures. Provide at minimum some ESD protection by wearing an antistatic wrist strap attached to the chassis ground on your system when handling parts. <br /> <br /> Always handle boards carefully. They can be extremely sensitive to ESD. Hold boards only by their edges. After removing a board from its protective wrapper or from the system, place it component side up on a grounded, static free surface. Use a conductive foam pad if available. Do not slide the board over any surface. <br /> <br /> To further reduce the chances of ESD, you should create an ESD safe workstation that includes at minimum: <br /> <br /> * Conductive rubber mat, with a lead wire that can be connected to a metal surface to create a ground. <br /> <br /> * ESD wrist strap, which has a resistor inside the strap and a lead wire that can be connected to a metal surface as a ground. The grounding wire on the wrist strap should have between 1 and 10 Megaohms of resistance. The resistor should protect you in case you come in contact with a voltage source. If the resistor is bad or not included, the wrist strap is useless. An accidental shock could be serious and even deadly! <br /> <br /> * Table or workspace that is clean, clear of dust, and away from electrical machinery or other equipment that generates electrical currents. <br /> <br /> The idea is to ensure that all components you are going to interact with have the same charge. By connecting everything to the computer case, you ensure that the components of the case, the chair, and your body all have the same charge. If every object has the same charge, the electrons will not jump from one object to another minimizing the risk of ESD damage.<br /> <br /> === What is a PIRQ table? ===<br /> <br /> There's a good description of the BIOS implementation of the PIRQ in the ''red PCI book'', and here's a [http://www.microsoft.com/whdc/archive/pciirq.mspx description of the $PIR data structure].<br /> <br /> coreboot saves the $PIR data structure between 0xf0000 &amp; 0x100000. Search for $PIR and then save it before copying over the BIOS.<br /> <br /> See also the [http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv1/util/ADLO/pirq/README ADLO README] for more information.<br /> <br /> === How do I set up etherboot with coreboot? ===<br /> <br /> Note from Ron: I have edited this somewhat to remove Geode-specific items. <br /> <br /> Christer Weinigel writes: <br /> To: rminnich@lanl.gov<br /> Cc: linuxbios@lanl.gov<br /> Subject: Re: LinuxBIOS + Etherboot HOWTO?<br /> <br /> I had some trouble using LinuxBIOS + etherboot... <br /> <br /> My bad, I messed up and used mkelfImage-1.6 that I got from ftp.lnxi.com, when I realized that I ought to use the one from freebios/util everything started working. <br /> <br /> Here's what I did to get LinuxBIOS + Etherboot loading and booting a Linux kernel using TFTP. <br /> <br /> /Christer <br /> <br /> Get etherboot-5.0 from the CVS tree on etherboot.sourceforge.net. <br /> <br /> Modify etherboot-5.0/src/Config, comment out: <br /> <br /> # BIOS select don't change unless you know what you are doing<br /> #CFLAGS32+= -DPCBIOS<br /> <br /> and uncomment the following: <br /> <br /> # Options to make a version of Etherboot that will work under linuxBIOS.<br /> CFLAGS32+= -DLINUXBIOS -DCONFIG_TSC_CURRTICKS -DCONSOLE_SERIAL \<br /> -DCOMCONSOLE=0x3f8 -DCOMPRESERVE -DCONFIG_PCI_DIRECT -DELF_IMAGE <br /> <br /> Compile Etherboot to make an elf file for your ethernet card: <br /> <br /> make bin32/natsemi.elf<br /> <br /> Compile and install mkelfImage from freebios/util/mkelfImage. <br /> <br /> Create a bootimage to put on your TFTP server: <br /> <br /> mkelfImage --command-line=&quot;root=/dev/hda2 console=ttyS0,38400&quot; \<br /> --kernel vmlinux -o /tftpboot/kernel<br /> <br /> Finally, make sure that your BOOT/DCHP server is answering and that the TFTP server is active. <br /> <br /> Tell LinuxBIOS to boot an elf Image, and tell LinuxBIOS where it is: <br /> <br /> option USE_ELF_BOOT=1<br /> <br /> I have placed natsemi.elf in the first 64k of my BIOS flash chip, and LinuxBIOS in the second 64k. <br /> <br /> insmod bios.o<br /> dd if=natsemi.elf of=/dev/bios bs=64k<br /> dd if=linuxbios.rom of=/dev/bios bs=64k seek=1<br /> <br /> Finally boot LinuxBIOS.<br /> <br /> === How do I set GEODE graphics and video? ===<br /> <br /> There is no Geode graphics support in coreboot. Install the Geode framebuffer driver for console graphics and the X driver for X support on your Geode Linux image. Current kernel and X distributions contain the required drivers. Until the driver loads there is only serial console output.<br /> <br /> Driver source:<br /> <br /> [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=tree;f=drivers/video/geode;hb=3968cb49ab01588cbf6896951780a1e411a0ec38 2.6.23 kernel framebuffer driver]<br /> <br /> [http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-amd.git;a=summary X.org driver]<br /> <br /> === How do I set up testbios? ===<br /> <br /> Please read the [http://linuxbios.org/FAQ/Obsolete#How_do_I_set_up_testbios.3F testbios FAQ].<br /> <br /> === /usr/sbin/iasl: Command not found ===<br /> <br /> If you see this error, you have to install ''iasl'', Intel's ASL Optimizing Compiler:<br /> <br /> * '''SUSE''' ships it in the '''pmtools''' package ([ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse/x86_64/pmtools-20050823-3.x86_64.rpm pmtools-20050823-3.x86_64.rpm], [ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse/i586/pmtools-20050823-3.i586.rpm pmtools-20050823-3.i586.rpm]). If you want to run rpmbuild --rebuild: [ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse/src/pmtools-20050823-3.src.rpm pmtools-20050823-3.src.rpm].<br /> * '''Debian''' ships it in the '''iasl''' package (''apt-get install iasl'').<br /> * You can also download the [http://acpica.org/downloads/unix_source_code.php latest version of the source code].<br /> <br /> === How can I write to POSTcard port 0x80 from userspace? ===<br /> <br /> [http://www.linuxbios.org/pipermail/linuxbios/2006-November/017012.html This] might be useful in some situations, and to output a number to a POST card:<br /> <br /> printf &quot;\001&quot; | dd bs=1 seek=128 of=/dev/port<br /> <br /> In DOS (not Windows XP) use:<br /> mov al, 42; out al, 80h<br /> To output 42 type<br /> o 80 42<br /> in DOS debug.exe.<br /> <br /> === Is coreboot applying x86 microcode patches? ===<br /> <br /> And if yes, can they be modified?<br /> <br /> Answer: this field is little documented. Few people think, however, that system design can seriously be improved by modifications here ( µCode patches mostly disable erraneous functions and opcodes).<br /> <br /> === How can I retrieve a good video BIOS? ===<br /> <br /> Note: If you are following these instructions to build coreboot for your motherboard, this is only necessary if you have a motherboard with an embedded VGA card. If your VGA is a PCI / PCI-Express add-on card, coreboot will find and run the ROM by itself.<br /> <br /> Anton Borisov has released a number of tools under the GPL (v2) to extract the VGA BIOS from the BIOS ROM images provided by the supplier of your motherboard.<br /> <br /> You can download them here:<br /> <br /> * Award BIOS:<br /> ** http://kaos.ru/biosgfx/download/awardeco-0.2.src.tar.gz<br /> ** http://ftp.debian.org/debian/pool/main/a/awardeco/awardeco_0.2.orig.tar.gz<br /> * AMI BIOS:<br /> ** http://www.kaos.ru/biosgfx/download/AmiDeco_0.31e.src.tar.gz<br /> ** http://ftp.debian.org/debian/pool/main/a/amideco/amideco_0.31e.orig.tar.gz<br /> * Phoenix BIOS:<br /> ** http://www.kaos.ru/biosgfx/download/PhoenixDeco_0.33.src.tar.gz<br /> ** http://ftp.debian.org/debian/pool/main/p/phnxdeco/phnxdeco_0.33.orig.tar.gz<br /> * Insyde BIOS:<br /> ** http://www.kaos.ru/biosgfx/download/InsyDeco_0.3.src.tar.gz<br /> ** (no alternative download location available, sorry)<br /> <br /> See the [[Tyan S2881 Build Tutorial]] for more information on how to use these tools.<br /> <br /> == Can I put coreboot into a PCI expansion ROM? ==<br /> <br /> There's little use in doing that, as a lots of initialization has already been done by the proprietary BIOS (or coreboot) by the time the PCI expansion ROM is executed. It won't be possible to run coreboot from a PCI expansion ROM after a proprietary BIOS has already been running for instance.<br /> <br /> Note: The Intel ICH7 southbridge seems to allows booting from PCI ROMs ('''not''' arbitrary PCI expansion ROMs as used on graphics cards, SCSI controllers, etc.) -- maybe this should be investigated in order to check if or how it might be useful.<br /> <br /> == Obsolete FAQ items ==<br /> <br /> Please see [[FAQ/Obsolete]] for (probably) obsolete FAQ items.</div>

Rminnich http://www.coreboot.org/Welcome_to_coreboot 2008-08-19T15:48:20Z

<p>Rminnich: </p> <hr /> <div>&lt;table width=&quot;100%&quot; valign=&quot;top&quot;&gt;&lt;tr valign=&quot;top&quot;&gt;&lt;td width=&quot;80%&quot;&gt;<br /> <br /> &lt;div style=&quot;margin-top:0.5em; margin-bottom:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;&quot;&gt;<br /> '''coreboot''' (formerly known as LinuxBIOS) is a Free Software project aimed at replacing the proprietary BIOS (firmware) you can find in most of today's computers. It performs just a little bit of hardware initialization and then executes a so-called [[Payloads|payload]].<br /> &lt;/div&gt;<br /> <br /> {| cellspacing=0 cellpadding=3 border=0 margin=0 padding=0 align=&quot;top&quot; width=100%<br /> |-<br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {{Box|<br /> BORDER = #8898bf|<br /> BACKGROUND = yellow|<br /> WIDTH = 100%|<br /> ICON = &lt;small&gt;[[Benefits|More...]]&lt;/small&gt;|<br /> HEADING = [[Benefits]]|<br /> CONTENT =<br /> &lt;small&gt;<br /> * 100% Free Software (GPL), no royalties, no license fees!<br /> * Fast boot times (3 seconds to Linux console)<br /> * Avoids the need for a slow/buggy/proprietary BIOS<br /> &lt;!-- * Runs in 32-Bit protected mode almost from the start --&gt;<br /> * Written in C, contains virtually no assembly code<br /> * Supports many [[Supported Motherboards|mainboards]], [[Supported Chipsets and Devices|devices]], and [[payloads]]<br /> &lt;!-- * Further features: netboot, serial console, remote flashing, ... --&gt;<br /> &lt;/small&gt;<br /> }}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {{Box|<br /> BORDER = #8898bf|<br /> BACKGROUND = #d1adf6|<br /> WIDTH = 100%|<br /> ICON = &lt;small&gt;[[Use Cases|More...]]&lt;/small&gt;|<br /> HEADING = [[Use Cases]]|<br /> CONTENT =<br /> &lt;small&gt;<br /> * Desktop PCs, servers, clusters, thin clients<br /> * [[Clusters]], high-performance computing<br /> &lt;!-- * Set-Top-Boxes, thin clients --&gt;<br /> * Embedded solutions, STBs/HTPC, appliances, terminals<br /> &lt;!-- * [http://en.wikipedia.org/wiki/Small_form_factor Small form factor computers], [http://en.wikipedia.org/wiki/Home_theater_PC Home-theater PCs] --&gt;<br /> * No-moving-parts solutions (ROM chip as &quot;disk&quot;)<br /> * Non-standard scenarios (e.g. FPGA in Opteron socket)<br /> &lt;/small&gt;<br /> }}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {{Box|<br /> BORDER = #8898bf|<br /> BACKGROUND = lime|<br /> WIDTH = 100%|<br /> ICON = &lt;small&gt;[[Payloads|More...]]&lt;/small&gt;|<br /> HEADING = [[Payloads]]|<br /> CONTENT =<br /> &lt;small&gt;<br /> * [[GRUB2]] / [[FILO]]<br /> * [[Linux]] / [[Booting Windows using coreboot|Windows]] / [[Booting FreeBSD using coreboot|FreeBSD]] / [http://openbsd.org/ OpenBSD]<br /> * [[OpenFirmware]] et. al.<br /> * [[Etherboot]]<br /> * [[Memtest86]]<br /> &lt;/small&gt;<br /> }}<br /> <br /> |}<br /> <br /> {| cellspacing=5 cellpadding=5 border=0 valign=&quot;top&quot; width=100%<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_lb.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''About'''&lt;br /&gt;&lt;small&gt;Find out more about coreboot.&lt;hr /&gt;[[News]] | [[Press]] | [[Current events|Events]] | [[History]] | [[Screenshots|Screenshots &amp; Videos]] | [[Contributors]] | [[Sponsors]] | [[Products]] | [[Clusters]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_devel.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Developers'''&lt;br /&gt;&lt;small&gt;Get involved! Help us make coreboot better.&lt;hr /&gt;[[Development Guidelines]] | [[Developer Manual]] | [http://qa.coreboot.org/docs/doxygen.php Doxygen] | [http://tracker.coreboot.org/trac/coreboot/browser/trunk Browse Source] | [[JTAG/BSDL Guide|JTAG]] | [[EHCI Debug Port]] | [[Distributed and Automated Testsystem|Testsystem]] | [[GSoC]] | [[Ideas]] | [[Laptop]] | [[Desktops]]&lt;/small&gt;<br /> |}<br /> <br /> |-<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_status.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Status'''&lt;br /&gt;&lt;small&gt;Find out whether your hardware is already supported.&lt;hr /&gt;[[Supported Motherboards]] | [[Supported Chipsets and Devices|Supported Chipsets &amp; Devices]] | [http://qa.coreboot.org Build Status] | [[Flashrom#Supported_devices|Flashrom support]] | [[Superiotool#Supported_devices|Superiotool support]] | [[Notes for v3 ports]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_tools.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Related Tools'''&lt;br /&gt;&lt;small&gt;Tools and libraries related to coreboot.&lt;hr /&gt;[[Flashrom]] | [[Superiotool]] | [[Nvramtool]] | [[Buildrom]] | [[Libpayload]] | [[Mkelfimage]]&lt;/small&gt;<br /> |}<br /> <br /> |-<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_101.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Getting Started'''&lt;br /&gt;&lt;small&gt;Download coreboot and get started.&lt;hr /&gt;[[Download coreboot|Downloads]] | [[Documentation]] | [[:Category:Tutorials|Build Tutorials]] | [[Payloads]] | [[QEMU]] | [[AMD SimNow]] | [[Confirmed working svn revisions|Confirmed Working SVN Revisions]] | [[Misc]] | [[Papers on memory training]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_support.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Support'''&lt;br /&gt;&lt;small&gt;Learn how to contact us and find help and support.&lt;hr /&gt;[[FAQ]] | [[Mailinglist]] | [[IRC]] | [http://tracker.coreboot.org/trac/coreboot/ Issue Tracker] | [[Glossary]] | [[coreboot Options|corebootv2 Options]]&lt;/small&gt;<br /> |}<br /> <br /> |}<br /> &lt;/td&gt;&lt;td width=&quot;20%&quot;&gt;<br /> <br /> [[Image:Coreboot libpayload tint.png|center|thumb|coreboot [[tint]] payload]]<br /> <br /> &lt;br clear=all /&gt;<br /> <br /> '''&lt;span style=&quot;font-variant:small-caps;&quot;&gt;[[News]]&lt;/span&gt;'''&lt;hr /&gt;<br /> &lt;!-- Please always make this list 7 items long (7 most recent news items). --&gt;<br /> &lt;small&gt;<br /> * '''2008/08/04:''' [[News#2008.2F08.2F04_ASI_MB-5BLGP_.2F_Neoware_Eon_4000s_now_supported|ASI MB-5BLGP support]]<br /> * '''2008/07/01:''' [[News#2008.2F07.2F01_New_logo_announced|The new logo is announced]]<br /> * '''2008/07/01:''' [[News#2008.2F07.2F01_coreboot_booth_at_OpenExpo_in_Z.C3.BCrich|OpenExpo and Hackontest]]<br /> * '''2008/06/27:''' [[News#2008.2F06.2F27_A-Trend_ATC-6240_now_supported|A-Trend ATC-6240 support]]<br /> * '''2008/05/28:''' [[News#2008.2F05.2F28_coreboot_booth_at_LinuxTag_in_Berlin|coreboot @ LinuxTag]]<br /> * '''2008/05/19:''' [[News#2008.2F05.2F19_VIA_EPIA-CN_now_supported|VIA EPIA-CN support]]<br /> * '''2008/05/16:''' [[News#2008.2F05.2F16_Thomson_IP1000_now_supported|Thomson IP1000 support]]<br /> &lt;/small&gt;<br /> <br /> '''&lt;span style=&quot;font-variant:small-caps;&quot;&gt;Contact&lt;/span&gt;'''&lt;hr /&gt;<br /> &lt;small&gt;<br /> * [[Mailinglist|Mailing list]]: [mailto:coreboot@coreboot.org coreboot@coreboot.org]<br /> * [[IRC]]: '''#coreboot''' (on [http://www.freenode.net/ irc.freenode.net])<br /> &lt;/small&gt;<br /> &lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;<br /> __NOTOC__<br /> __NOEDITSECTION__</div>

Rminnich http://www.coreboot.org/Notes_for_v3_ports 2008-08-14T03:43:47Z

<p>Rminnich: </p> <hr /> <div>== Note for those porting to v3 ==<br /> <br /> There are a lot of changes with v3, and they are basically good. I am doing the K8 port now, and I'd like to accumulate wisdom on this page. V3 really is very different and you don't realize it until you get into it.<br /> <br /> <br /> == Compile once, link once, use everywhere. ==<br /> <br /> <br /> The first thing to remember is that v2 is very much shaped by the romcc legacy. So you will see comments like this in v2 commits: &quot;get more code compiling in both places&quot; or some such. <br /> <br /> What does this mean? It means, for example, that the function '''xyz(device_t)''' has to compile and work when device_t is a u32 (as in the ROM-based code that starts RAM) and as a '''struct device *''' (as in the RAM-based code). This schizophrenia pervades v2, even when it is not needed (as in v2 targets that can run with cache-as-ram). A lot of v2 code is still compiled twice. <br /> <br /> This is especially true of the .h files with inlined functions. In v2, a lot of SMBUS functions are inlined, meaning they get compiled into the ROM and RAM code. <br /> <br /> A dramatic change in v3 is that the ROM-based code can be called from the RAM-based code. This change in turn means that many support functions should be built into the ROM-based code, one example being the functions that support PCI config space. <br /> <br /> ''Note: stage0 is very early assembly, and stage1 is ROM-based C code. For reasons of history the Makefiles call some code STAGE0, though we ought to call it STAGE1. Sorry.'' <br /> <br /> What does this imply? In v3, you should plan to move code to stage1, and then mark certain functions as SHARED, so they can be called from stage2. However, if the code will only be used in stage2, don't move it to stage1 because only stage2 code can be compressed.<br /> <br /> Here's an example: there is code that calls die(). In the bad old days die was compiled in to several places. Now it just has to be callable from anywhere. <br /> <br /> Die() is defined in include/console.h as:<br /> <br /> &lt;nowiki&gt;void die(const char *mst);<br /> &lt;/nowiki&gt;<br /> <br /> We just change it:<br /> <br /> &lt;nowiki&gt;SHARED(die, void, const char *msg);&lt;/nowiki&gt;<br /> <br /> <br /> Result: we only compile a lot of code once, with the same compiler, and it can be called from anywhere.<br /> <br /> I just now did the same with pci_conf1_* functions. They are built into stage0 and SHARED. The names of these functions are used in initram. The functions are used to init the pci_cf8_conf1 struct in stage2. Three users, one copy of the code. <br /> <br /> <br /> == ROMCC artifacts ==<br /> <br /> Carl-Daniel writes: <br /> '''(and why does the nowiki tag not defeat formatting? Sorry -- Ron)<br /> '''<br /> <br /> &lt;nowiki&gt;Hi,<br /> <br /> attached is a list of occurences where we use the plain &quot;unsigned&quot; type<br /> which was once the preferred type for ROMCC compiled code. For v3, an<br /> adjustment to the real desired sizes of these types would be beneficial.<br /> Be warned that this can't be automated.<br /> <br /> Regards,<br /> Carl-Daniel<br /> <br /> --<br /> http://www.hailfinger.org/<br /> <br /> <br /> ./southbridge/nvidia/mcp55/smbus.c: unsigned device;<br /> ./southbridge/nvidia/mcp55/smbus.c: unsigned device;<br /> ./southbridge/nvidia/mcp55/smbus.c: unsigned device;<br /> ./southbridge/nvidia/mcp55/smbus.c: unsigned device;<br /> ./southbridge/nvidia/mcp55/smbus.c:unsigned pm_base;<br /> ./southbridge/nvidia/mcp55/lpc.c: unsigned link;<br /> ./southbridge/nvidia/mcp55/lpc.c:static void lpci_set_subsystem(struct device *dev, unsigned vendor, unsigned device)<br /> ./southbridge/nvidia/mcp55/stage1_usbdebug.c:static void set_debug_port(unsigned port)<br /> ./southbridge/nvidia/mcp55/stage1_usbdebug.c:static void mcp55_enable_usbdebug_direct(unsigned port)<br /> ./southbridge/nvidia/mcp55/usb2.c: unsigned base;<br /> ./southbridge/nvidia/mcp55/usb2.c: unsigned old_debug;<br /> ./southbridge/nvidia/mcp55/mcp55.c:static struct device *find_lpc_dev( struct device *dev, unsigned devfn)<br /> ./southbridge/nvidia/mcp55/mcp55.c: unsigned index = 0;<br /> ./southbridge/nvidia/mcp55/mcp55.c: unsigned index2 = 0;<br /> ./southbridge/nvidia/mcp55/mcp55.c: unsigned deviceid;<br /> ./southbridge/nvidia/mcp55/mcp55.c: unsigned vendorid;<br /> ./southbridge/nvidia/mcp55/mcp55.c: unsigned devfn;<br /> ./southbridge/nvidia/mcp55/stage1.c: int set_ht_link_buffer_counts_chain(u8 ht_c_num, unsigned vendorid, unsigned val);<br /> ./southbridge/nvidia/mcp55/stage1.c: unsigned vendorid = 0x10de;<br /> ./southbridge/nvidia/mcp55/stage1.c: unsigned val = 0x01610109;<br /> ./southbridge/nvidia/mcp55/stage1.c:void setup_ss_table(unsigned index, unsigned where, unsigned control, const unsigned int *register_values, int max)<br /> ./southbridge/nvidia/mcp55/stage1.c: unsigned val;<br /> ./southbridge/nvidia/mcp55/stage1.c:static void mcp55_early_set_port(unsigned mcp55_num, unsigned *busn, unsigned *devn, unsigned *io_base)<br /> ./southbridge/nvidia/mcp55/stage1.c:static void mcp55_early_clear_port(unsigned mcp55_num, unsigned *busn, unsigned *devn, unsigned *io_base)<br /> ./southbridge/nvidia/mcp55/stage1.c:static void mcp55_early_pcie_setup(unsigned busnx, unsigned devnx, unsigned anactrl_io_base, unsigned pci_e_x)<br /> ./southbridge/nvidia/mcp55/stage1.c:static void mcp55_early_setup(unsigned mcp55_num, unsigned *busn, unsigned *devn, unsigned *io_base, unsigned *pci_e_x)<br /> ./southbridge/nvidia/mcp55/stage1.c: unsigned busn[HT_CHAIN_NUM_MAX];<br /> ./southbridge/nvidia/mcp55/stage1.c: unsigned devn[HT_CHAIN_NUM_MAX];<br /> ./southbridge/nvidia/mcp55/stage1.c: unsigned io_base[HT_CHAIN_NUM_MAX];<br /> ./southbridge/nvidia/mcp55/stage1.c: unsigned pci_e_x[HT_CHAIN_NUM_MAX] = {MCP55_PCI_E_X_0, MCP55_PCI_E_X_1, MCP55_PCI_E_X_2, MCP55_PCI_E_X_3 };<br /> ./southbridge/nvidia/mcp55/stage1.c: unsigned busnx;<br /> ./southbridge/nvidia/mcp55/stage1.c: unsigned devnx;<br /> ./southbridge/nvidia/mcp55/stage1.c:void enable_fid_change_on_sb(unsigned sbbusn, unsigned sbdn)<br /> ./northbridge/amd/geodelx/vsmsetup.c: unsigned eax, ebx, ecx, edx;<br /> ./northbridge/amd/geodelx/vsmsetup.c: unsigned eax, ebx, ecx, edx;<br /> ./northbridge/amd/k8/northbridge.c:static u32 f1_read_config32(unsigned reg)<br /> ./northbridge/amd/k8/northbridge.c:static void f1_write_config32(unsigned reg, u32 value)<br /> ./northbridge/amd/k8/northbridge.c:static unsigned int amdk8_scan_chain(struct device * dev, unsigned nodeid, unsigned link, unsigned sblink, unsigned int max, unsigned offset_unitid)<br /> ./northbridge/amd/k8/northbridge.c: unsigned free_reg, config_reg;<br /> ./northbridge/amd/k8/northbridge.c: unsigned ht_unitid_base[4]; // here assume only 4 HT device on chain<br /> ./northbridge/amd/k8/northbridge.c: unsigned max_bus;<br /> ./northbridge/amd/k8/northbridge.c: unsigned min_bus;<br /> ./northbridge/amd/k8/northbridge.c: unsigned max_devfn;<br /> ./northbridge/amd/k8/northbridge.c: unsigned temp = 0;<br /> ./northbridge/amd/k8/northbridge.c: unsigned nodeid;<br /> ./northbridge/amd/k8/northbridge.c: unsigned link;<br /> ./northbridge/amd/k8/northbridge.c: unsigned sblink = 0;<br /> ./northbridge/amd/k8/northbridge.c: unsigned offset_unitid = 0;<br /> ./northbridge/amd/k8/northbridge.c:static int reg_useable(unsigned reg,<br /> ./northbridge/amd/k8/northbridge.c: struct device * goal_dev, unsigned goal_nodeid, unsigned goal_link)<br /> ./northbridge/amd/k8/northbridge.c: unsigned nodeid, link;<br /> ./northbridge/amd/k8/northbridge.c:static struct resource *amdk8_find_iopair(struct device * dev, unsigned nodeid, unsigned link)<br /> ./northbridge/amd/k8/northbridge.c: unsigned free_reg, reg;<br /> ./northbridge/amd/k8/northbridge.c:static struct resource *amdk8_find_mempair(struct device * dev, unsigned nodeid, unsigned link)<br /> ./northbridge/amd/k8/northbridge.c: unsigned free_reg, reg;<br /> ./northbridge/amd/k8/northbridge.c:static void amdk8_link_read_bases(struct device * dev, unsigned nodeid, unsigned link)<br /> ./northbridge/amd/k8/northbridge.c: unsigned nodeid, link;<br /> ./northbridge/amd/k8/northbridge.c:static void amdk8_set_resource(struct device * dev, struct resource *resource, unsigned nodeid)<br /> ./northbridge/amd/k8/northbridge.c: unsigned reg, link;<br /> ./northbridge/amd/k8/northbridge.c:static void amdk8_create_vga_resource(struct device * dev, unsigned nodeid)<br /> ./northbridge/amd/k8/northbridge.c: unsigned link;<br /> ./northbridge/amd/k8/northbridge.c: unsigned reg;<br /> ./northbridge/amd/k8/northbridge.c: unsigned nodeid, link;<br /> ./northbridge/amd/k8/northbridge.c: unsigned reg;<br /> ./northbridge/amd/k8/northbridge.c: unsigned nodeid, link;<br /> ./northbridge/amd/k8/northbridge.c: unsigned hole_startk;<br /> ./northbridge/amd/k8/northbridge.c: unsigned base_k, limit_k;<br /> ./northbridge/amd/k8/northbridge.c: unsigned reset_memhole = 1;<br /> ./northbridge/amd/k8/northbridge.c: unsigned basek, limitk, sizek;<br /> ./northbridge/amd/k8/northbridge.c: unsigned pre_sizek;<br /> ./northbridge/amd/k8/northbridge.c: unsigned reg;<br /> ./northbridge/amd/k8/northbridge.c: unsigned nb_cfg_54;<br /> ./northbridge/amd/k8/northbridge.c: unsigned siblings;<br /> ./northbridge/amd/k8/northbridge.c: unsigned jj;<br /> ./northbridge/amd/k8/incoherent_ht.c:static void ht_collapse_previous_enumeration(u8 bus, unsigned offset_unitid)<br /> ./northbridge/amd/k8/incoherent_ht.c: u32 bdf1, u8 pos1, unsigned offs1,<br /> ./northbridge/amd/k8/incoherent_ht.c: u32 bdf2, u8 pos2, unsigned offs2)<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned offset_unitid, struct sys_info *sysinfo);<br /> ./northbridge/amd/k8/incoherent_ht.c:int scan_pci_bus( unsigned bus , struct sys_info *sysinfo)<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned new_bus;<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned max_bus;<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned offset_unitid, struct sys_info *sysinfo)<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned uoffs;<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned real_last_unitid;<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned offs;<br /> ./northbridge/amd/k8/incoherent_ht.c:void ht_setup_chain(u32 bdf, unsigned upos, struct sys_info *sysinfo)<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned offset_unitid = 0;<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned devn = 1;<br /> ./northbridge/amd/k8/incoherent_ht.c:int set_ht_link_buffer_count(u8 node, u8 linkn, u8 linkt, unsigned val)<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned regpos;<br /> ./northbridge/amd/k8/incoherent_ht.c:int set_ht_link_buffer_counts_chain(u8 ht_c_num, unsigned vendorid, unsigned val)<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned devn;<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned regpos;<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned bus;<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned offset_unitid = 0;<br /> ./northbridge/amd/k8/incoherent_ht.c:unsigned get_nodes(void);<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned next_io_base;<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned regpos;<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned regpos;<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned regpos;<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned regpos;<br /> ./northbridge/amd/k8/incoherent_ht.c: unsigned link_pair_num = sysinfo-&gt;link_pair_num;<br /> ./northbridge/amd/k8/coherent_ht.c: unsigned tmp = (pci_read_config32(NODE_MC(0), 0xe8) &gt;&gt; 12) &amp; 3;<br /> ./northbridge/amd/k8/coherent_ht.c:unsigned setup_smp2(void)<br /> ./northbridge/amd/k8/coherent_ht.c: unsigned nodes;<br /> ./northbridge/amd/k8/coherent_ht.c:unsigned setup_smp4(void)<br /> ./northbridge/amd/k8/coherent_ht.c: unsigned nodes;<br /> ./northbridge/amd/k8/coherent_ht.c:unsigned setup_smp6(void)<br /> ./northbridge/amd/k8/coherent_ht.c: unsigned nodes;<br /> ./northbridge/amd/k8/coherent_ht.c:unsigned setup_smp8(void)<br /> ./northbridge/amd/k8/coherent_ht.c: unsigned nodes;<br /> ./northbridge/amd/k8/coherent_ht.c:unsigned setup_smp(void)<br /> ./northbridge/amd/k8/coherent_ht.c: unsigned nodes;<br /> ./northbridge/amd/k8/coherent_ht.c:unsigned verify_mp_capabilities(unsigned nodes)<br /> ./northbridge/amd/k8/coherent_ht.c: unsigned node, mask;<br /> ./northbridge/amd/k8/coherent_ht.c:void clear_dead_routes(unsigned nodes)<br /> ./northbridge/amd/k8/coherent_ht.c:unsigned verify_dualcore(unsigned nodes)<br /> ./northbridge/amd/k8/coherent_ht.c: unsigned node, totalcpus, tmp;<br /> ./northbridge/amd/k8/coherent_ht.c:void coherent_ht_finalize(unsigned nodes)<br /> ./northbridge/amd/k8/coherent_ht.c: unsigned node;<br /> ./northbridge/amd/k8/coherent_ht.c: unsigned total_cpus;<br /> ./northbridge/amd/k8/coherent_ht.c:int apply_cpu_errata_fixes(unsigned nodes)<br /> ./northbridge/amd/k8/coherent_ht.c: unsigned node;<br /> ./northbridge/amd/k8/coherent_ht.c:int optimize_link_read_pointers(unsigned nodes)<br /> ./northbridge/amd/k8/coherent_ht.c: unsigned node;<br /> ./northbridge/amd/k8/coherent_ht.c: unsigned reg;<br /> ./northbridge/amd/k8/coherent_ht.c:inline unsigned get_nodes(void)<br /> ./northbridge/amd/k8/coherent_ht.c: unsigned nodes;<br /> ./northbridge/amd/k8/coherent_ht.c: unsigned nodes;<br /> ./northbridge/amd/k8/get_sblk_pci1234.c:unsigned node_link_to_bus(unsigned node, unsigned link)<br /> ./northbridge/amd/k8/get_sblk_pci1234.c: unsigned reg;<br /> ./northbridge/amd/k8/get_sblk_pci1234.c: unsigned dst_node;<br /> ./northbridge/amd/k8/get_sblk_pci1234.c: unsigned dst_link;<br /> ./northbridge/amd/k8/get_sblk_pci1234.c: unsigned bus_base;<br /> ./northbridge/amd/k8/get_sblk_pci1234.c: * unsigned pci1234[] = {<br /> ./northbridge/amd/k8/get_sblk_pci1234.c: * unsigned pci1234[] = {<br /> ./northbridge/amd/k8/get_sblk_pci1234.c: * unsigned pci1234[] = {<br /> ./northbridge/amd/k8/get_sblk_pci1234.c: * unsigned pci1234[] = {<br /> ./northbridge/amd/k8/get_sblk_pci1234.c: * unsigned pci1234[] = {<br /> ./northbridge/amd/k8/raminit.c:static struct dimm_size spd_get_dimm_size(unsigned device)<br /> ./northbridge/amd/k8/raminit.c:static void set_dimm_size(const struct mem_controller *ctrl, struct dimm_size sz, unsigned index)<br /> ./northbridge/amd/k8/raminit.c:static void set_dimm_map(const struct mem_controller *ctrl, struct dimm_size sz, unsigned index)<br /> ./northbridge/amd/k8/raminit.c: static const unsigned cs_map_aa[] = {<br /> ./northbridge/amd/k8/raminit.c: unsigned node_id;<br /> ./northbridge/amd/k8/raminit.c: unsigned limit;<br /> ./northbridge/amd/k8/raminit.c: unsigned base;<br /> ./northbridge/amd/k8/raminit.c: unsigned index;<br /> ./northbridge/amd/k8/raminit.c: unsigned limit_reg, base_reg;<br /> ./northbridge/amd/k8/raminit.c:static void set_top_mem(unsigned tom_k, unsigned hole_startk)<br /> ./northbridge/amd/k8/raminit.c: unsigned common_size;<br /> ./northbridge/amd/k8/raminit.c: unsigned common_cs_mode;<br /> ./northbridge/amd/k8/raminit.c: unsigned size;<br /> ./northbridge/amd/k8/raminit.c: unsigned cs_mode;<br /> ./northbridge/amd/k8/raminit.c: unsigned index, candidate;<br /> ./northbridge/amd/k8/raminit.c: unsigned size;<br /> ./northbridge/amd/k8/raminit.c: unsigned node_id;<br /> ./northbridge/amd/k8/raminit.c: unsigned end_k;<br /> ./northbridge/amd/k8/raminit.c: unsigned index;<br /> ./northbridge/amd/k8/raminit.c:static long disable_dimm(const struct mem_controller *ctrl, unsigned index, long dimm_mask)<br /> ./northbridge/amd/k8/raminit.c: unsigned dimm_mask;<br /> ./northbridge/amd/k8/raminit.c: unsigned device;<br /> ./northbridge/amd/k8/raminit.c: unsigned device0, device1;<br /> ./northbridge/amd/k8/raminit.c: unsigned addr;<br /> ./northbridge/amd/k8/raminit.c:static const struct mem_param *get_mem_param(unsigned min_cycle_time)<br /> ./northbridge/amd/k8/raminit.c: unsigned min_cycle_time, min_latency, bios_cycle_time;<br /> ./northbridge/amd/k8/raminit.c: static const unsigned latencies[] = { DTL_CL_2, DTL_CL_2_5, DTL_CL_3 };<br /> ./northbridge/amd/k8/raminit.c: unsigned clocks, old_clocks;<br /> ./northbridge/amd/k8/raminit.c: unsigned clocks, old_clocks;<br /> ./northbridge/amd/k8/raminit.c: unsigned clocks, old_clocks;<br /> ./northbridge/amd/k8/raminit.c: unsigned clocks, old_clocks;<br /> ./northbridge/amd/k8/raminit.c: unsigned clocks, old_clocks;<br /> ./northbridge/amd/k8/raminit.c: unsigned clocks, old_clocks;<br /> ./northbridge/amd/k8/raminit.c: unsigned tref, old_tref;<br /> ./northbridge/amd/k8/raminit.c: unsigned index;<br /> ./northbridge/amd/k8/raminit.c: unsigned latency;<br /> ./northbridge/amd/k8/raminit.c: unsigned clocks;<br /> ./northbridge/amd/k8/raminit.c: unsigned clocks;<br /> ./northbridge/amd/k8/raminit.c: unsigned rdpreamble;<br /> ./northbridge/amd/k8/raminit.c: unsigned async_lat;<br /> ./northbridge/amd/k8/raminit.c:static u32 hoist_memory(int controllers, const struct mem_controller *ctrl,unsigned hole_startk, int i)<br /> ./northbridge/amd/k8/raminit.c: unsigned base_k;<br /> ./northbridge/amd/k8/raminit.c: unsigned base_k, limit_k;<br /> ./northbridge/amd/k8/raminit.c: unsigned end_k;<br /> ./northbridge/amd/k8/raminit.c:void set_sysinfo_in_ram(unsigned val)<br /> ./superio/winbond/w83627hf/superio.c: unsigned hwm_reg_values[] = {<br /> ./device/hypertransport.c:static unsigned ht_read_freq_cap(struct device *dev, unsigned pos)<br /> ./device/hypertransport.c: unsigned freq_cap;<br /> ./device/pci_device.c: unsigned ctl;<br /> ./device/pci_device.c: unsigned short intBits = inb(0x4d0) | (((unsigned)inb(0x4d1)) &lt;&lt; 8);<br /> ./include/uart8250.h:unsigned char uart8250_rx_byte(unsigned base_port);<br /> ./include/uart8250.h:int uart8250_can_rx_byte(unsigned base_port);<br /> ./include/uart8250.h:void uart8250_tx_byte(unsigned base_port, unsigned char data);<br /> ./include/uart8250.h:void uart8250_init(unsigned base_port, unsigned divisor, unsigned lcs);<br /> ./include/device/agp.h: unsigned min_devfn, unsigned max_devfn, unsigned int max);<br /> ./include/device/hypertransport.h: unsigned min_devfn, unsigned max_devfn, unsigned int max, unsigned *ht_unit_base, unsigned offset_unitid);<br /> ./include/device/device.h: unsigned bridge_ctrl; /* Bridge control register */<br /> ./include/device/device.h: unsigned reset_needed : 1;<br /> ./include/device/device.h: unsigned disable_relaxed_ordering : 1;<br /> ./include/device/pcix.h: unsigned min_devfn, unsigned max_devfn, unsigned int max);<br /> ./include/device/pcix.h:const char *pcix_speed(unsigned sstatus);<br /> ./include/device/path.h: unsigned domain;<br /> ./include/device/path.h: unsigned bus;<br /> ./include/device/path.h: unsigned devfn;<br /> ./include/device/path.h: unsigned port;<br /> ./include/device/path.h: unsigned device;<br /> ./include/device/path.h: unsigned device;<br /> ./include/device/path.h: unsigned apic_id;<br /> ./include/device/path.h: unsigned node_id;<br /> ./include/device/path.h: unsigned core_id;<br /> ./include/device/path.h: unsigned cluster;<br /> ./include/device/path.h: unsigned id;<br /> ./include/device/path.h: unsigned id;<br /> ./include/device/path.h: unsigned iobase;<br /> ./include/device/pci_ops.h:u8 pci_read_config8(struct device * dev, unsigned where);<br /> ./include/device/pci_ops.h:u16 pci_read_config16(struct device * dev, unsigned where);<br /> ./include/device/pci_ops.h:u32 pci_read_config32(struct device * dev, unsigned where);<br /> ./include/device/pci_ops.h:void pci_write_config8(struct device * dev, unsigned where, u8 val);<br /> ./include/device/pci_ops.h:void pci_write_config16(struct device * dev, unsigned where, u16 val);<br /> ./include/device/pci_ops.h:void pci_write_config32(struct device * dev, unsigned where, u32 val);<br /> ./include/device/pci.h: void (*set_subsystem)(struct device * dev, unsigned vendor, unsigned device);<br /> ./include/device/pci.h:struct device * pci_probe_dev(struct device * dev, struct bus *bus, unsigned devfn);<br /> ./include/device/pci.h: unsigned min_devfn, unsigned max_devfn, unsigned int max));<br /> ./include/device/pci.h:unsigned int pci_scan_bus(struct bus *bus, unsigned min_devfn, unsigned max_devfn, unsigned int max);<br /> ./include/device/pci.h:u8 pci_moving_config8(struct device *dev, unsigned reg);<br /> ./include/device/pci.h:u16 pci_moving_config16(struct device *dev, unsigned reg);<br /> ./include/device/pci.h:u32 pci_moving_config32(struct device *dev, unsigned reg);<br /> ./include/device/pci.h:unsigned pci_find_next_capability(struct device * dev, unsigned cap, unsigned last);<br /> ./include/device/pci.h:unsigned pci_find_capability(struct device * dev, unsigned cap);<br /> ./include/device/pci.h:void pci_dev_set_subsystem(struct device * dev, unsigned vendor, unsigned device);<br /> ./include/device/pnp.h:void pnp_set_iobase(struct device * dev, unsigned index, unsigned iobase);<br /> ./include/device/pnp.h:void pnp_set_irq(struct device * dev, unsigned index, unsigned irq);<br /> ./include/device/pnp.h:void pnp_set_drq(struct device * dev, unsigned index, unsigned drq);<br /> ./include/device/pnp.h: unsigned mask, set;<br /> ./include/device/pnp.h: unsigned function;<br /> ./include/device/pnp.h: unsigned flags;<br /> ./include/device/pnp.h:struct resource *pnp_get_resource(struct device * dev, unsigned index);<br /> ./include/device/pnp.h: unsigned functions, struct pnp_info *info);<br /> ./include/device/resource.h:extern struct resource *probe_resource(struct device *dev, unsigned index);<br /> ./include/device/resource.h:extern struct resource *new_resource(struct device * dev, unsigned index);<br /> ./include/device/resource.h:extern struct resource *find_resource(struct device * dev, unsigned index);<br /> ./include/device/pcie.h: unsigned min_devfn, unsigned max_devfn, unsigned int max);<br /> ./include/device/cardbus.h: unsigned min_devfn, unsigned max_devfn, unsigned int max);<br /> ./include/arch/x86/amd/k8/raminit.h: unsigned node_id;<br /> ./include/arch/x86/amd/k8/sysconf.h: unsigned nodes;<br /> ./include/arch/x86/amd/k8/sysconf.h: unsigned hc_possible_num;<br /> ./include/arch/x86/amd/k8/sysconf.h: unsigned pci1234[HC_POSSIBLE_NUM];<br /> ./include/arch/x86/amd/k8/sysconf.h: unsigned hcdn[HC_POSSIBLE_NUM];<br /> ./include/arch/x86/amd/k8/sysconf.h: unsigned hcid[HC_POSSIBLE_NUM]; //record ht chain type<br /> ./include/arch/x86/amd/k8/sysconf.h: unsigned sbdn;<br /> ./include/arch/x86/amd/k8/sysconf.h: unsigned sblk;<br /> ./include/arch/x86/amd/k8/sysconf.h: unsigned hcdn_reg[4]; // it will be used by get_sblk_pci1234<br /> ./include/arch/x86/amd/k8/sysconf.h: unsigned lift_bsp_apicid;<br /> ./include/arch/x86/amd/k8/k8.h: unsigned node_id;<br /> ./include/arch/x86/amd/k8/k8.h: unsigned nodeid;<br /> ./include/arch/x86/amd/k8/k8.h: unsigned coreid;<br /> ./include/arch/x86/amd/k8/k8.h:unsigned get_apicid_base(unsigned ioapic_num);<br /> ./include/arch/x86/mtrr.h:void x86_setup_var_mtrrs(unsigned address_bits);<br /> ./include/arch/x86/mtrr.h:void x86_setup_mtrrs(unsigned address_bits);<br /> ./lib/nrv2b.c: (((bb = bb &amp; 0x7f ? bb*2 : ((unsigned)src[ilen++]*2+1)) &gt;&gt; 8) &amp; 1)<br /> ./lib/nrv2b.c: unsigned bc = 0;<br /> ./lib/uart8250.c:static inline int uart8250_can_tx_byte(unsigned base_port)<br /> ./lib/uart8250.c:static inline void uart8250_wait_to_tx_byte(unsigned base_port)<br /> ./lib/uart8250.c:static inline void uart8250_wait_until_sent(unsigned base_port)<br /> ./lib/uart8250.c:void uart8250_tx_byte(unsigned base_port, unsigned char data)<br /> ./lib/uart8250.c:int uart8250_can_rx_byte(unsigned base_port)<br /> ./lib/uart8250.c:unsigned char uart8250_rx_byte(unsigned base_port)<br /> ./lib/uart8250.c:void uart8250_init(unsigned base_port, unsigned divisor, unsigned lcs)<br /> ./doc/design/newboot.lyx: The simplest function is called smbus_read_byte(unsigned device, unsigned<br /> ./arch/x86/resourcemap.c: unsigned where;<br /> ./arch/x86/serial.c: unsigned ttysx_div;<br /> ./arch/x86/serial.c: unsigned ttysx_index;<br /> ./arch/x86/archtables.c: unsigned mptable_size = new_low_table_end - low_table_end - SMP_FLOATING_TABLE_LEN;<br /> ./arch/x86/mc146818rtc.c: unsigned sum, old_sum;<br /> ./arch/x86/mc146818rtc.c: unsigned sum;<br /> ./arch/x86/mc146818rtc.c:unsigned read_option(unsigned start, unsigned size, unsigned def)<br /> ./arch/x86/mc146818rtc.c: unsigned byte;<br /> ./arch/x86/pci_ops_auto.c: unsigned bus;&lt;/nowiki&gt;</div>

Rminnich http://www.coreboot.org/Notes_for_v3_ports 2008-08-11T19:42:52Z

<p>Rminnich: </p> <hr /> <div>== Note for those porting to v3 ==<br /> <br /> There are a lot of changes with v3, and they are basically good. I am doing the K8 port now, and I'd like to accumulate wisdom on this page. V3 really is very different and you don't realize it until you get into it.<br /> <br /> <br /> == Compile once, link once, use everywhere. ==<br /> <br /> <br /> The first thing to remember is that v2 is very much shaped by the romcc legacy. So you will see comments like this in v2 commits: &quot;get more code compiling in both places&quot; or some such. <br /> <br /> What does this mean? It means, for example, that the function '''xyz(device_t)''' has to compile and work when device_t is a u32 (as in the ROM-based code that starts RAM) and as a '''struct device *''' (as in the RAM-based code). This schizophrenia pervades v2, even when it is not needed (as in v2 targets that can run with cache-as-ram). A lot of v2 code is still compiled twice. <br /> <br /> This is especially true of the .h files with inlined functions. In v2, a lot of SMBUS functions are inlined, meaning they get compiled into the ROM and RAM code. <br /> <br /> A dramatic change in v3 is that the ROM-based code can be called from the RAM-based code. This change in turn means that many support functions should be built into the ROM-based code, one example being the functions that support PCI config space. <br /> <br /> ''Note: stage0 is very early assembly, and stage1 is ROM-based C code. For reasons of history the Makefiles call some code STAGE0, though we ought to call it STAGE1. Sorry.'' <br /> <br /> What does this imply? In v3, you should plan to move code to stage1, and then mark certain functions as SHARED, so they can be called from stage2. Here's an example: there is code that calls die(). In the bad old days die was compiled in to several places. Now it just has to be callable from anywhere. <br /> <br /> Die() is defined in include/console.h as:<br /> <br /> &lt;nowiki&gt;void die(const char *mst);<br /> &lt;/nowiki&gt;<br /> <br /> We just change it:<br /> <br /> &lt;nowiki&gt;SHARED(die, void, const char *msg);&lt;/nowiki&gt;<br /> <br /> <br /> Result: we only compile a lot of code once, with the same compiler, and it can be called from anywhere.</div>

Rminnich http://www.coreboot.org/Notes_for_v3_ports 2008-08-11T18:53:14Z

<p>Rminnich: </p> <hr /> <div>== Note for those porting to v3 ==<br /> <br /> There are a lot of changes with v3, and they are basically good. I am doing the K8 port now, and I'd like to accumulate wisdom on this page. V3 really is very different and you don't realize it until you get into it.<br /> <br /> <br /> == Compile once, link once, use everywhere. ==<br /> <br /> <br /> The first thing to remember is that v2 is very much shaped by the romcc legacy. So you will see comments like this in v2 commits: &quot;get more code compiling in both places&quot; or some such. <br /> <br /> What does this mean? It means, for example, that the function '''xyz(device_t)''' has to compile and work when device_t is a u32 (as in the ROM-based code that starts RAM) and as a '''struct device *''' (as in the RAM-based code). This schizophrenia pervades v2, even when it is not needed (as in v2 targets that can run with cache-as-ram). A lot of v2 code is still compiled twice. <br /> <br /> This is especially true of the .h files with inlined functions. In v2, a lot of SMBUS functions are inlined, meaning they get compiled into the ROM and RAM code. <br /> <br /> A dramatic change in v3 is that the ROM-based code can be called from the RAM-based code. This change in turn means that many support functions should be built into the ROM-based code, one example being the functions that support PCI config space. <br /> <br /> ''Note: stage0 is very early assembly, and stage1 is ROM-based C code. For reasons of history the Makefiles call some code STAGE0, though we ought to call it STAGE1. Sorry.'' <br /> <br /> What does this imply? In v3, you should plan to move code to stage1, and then mark certain functions as SHARED, so they can be called from stage2. Here's an example: (example to come -- the first one I did was wrong)<br /> <br /> Result: we only compile a lot of code once, with the same compiler, and it can be called from anywhere.</div>

Rminnich http://www.coreboot.org/Notes_for_v3_ports 2008-08-11T15:53:29Z

<p>Rminnich: New page: == Note for those porting to v3 == There are a lot of changes with v3, and they are basically good. I am doing the K8 port now, and I'd like to accumulate wisdom on this page. V3 really i...</p> <hr /> <div>== Note for those porting to v3 ==<br /> <br /> There are a lot of changes with v3, and they are basically good. I am doing the K8 port now, and I'd like to accumulate wisdom on this page. V3 really is very different and you don't realize it until you get into it.<br /> <br /> <br /> == Compile once, link once, use everywhere. ==<br /> <br /> <br /> The first thing to remember is that v2 is very much shaped by the romcc legacy. So you will see comments like this in v2 commits: &quot;get more code compiling in both places&quot; or some such. <br /> <br /> What does this mean? It means, for example, that the function '''xyz(device_t)''' has to compile and work when device_t is a u32 (as in the ROM-based code that starts RAM) and as a '''struct device *''' (as in the RAM-based code). This schizophrenia pervades v2, even when it is not needed (as in v2 targets that can run with cache-as-ram). A lot of v2 code is still compiled twice. <br /> <br /> This is especially true of the .h files with inlined functions. In v2, a lot of SMBUS functions are inlined, meaning they get compiled into the ROM and RAM code. <br /> <br /> A dramatic change in v3 is that the ROM-based code can be called from the RAM-based code. This change in turn means that many support functions should be built into the ROM-based code, one example being the functions that support PCI config space. <br /> <br /> ''Note: stage0 is very early assembly, and stage1 is ROM-based C code. For reasons of history the Makefiles call some code STAGE0, though we ought to call it STAGE1. Sorry.'' <br /> <br /> What does this imply? In v3, you should plan to move code to stage1, and then mark certain functions as SHARED, so they can be called from stage2. Here's an example: on boards using the MCP55, I moved all the inlined SMBUS functions from ''mcp55_smbus.h'' to ''stage1_smbus.c''. In the m57sli mainboard Makefile, the STAGE0 defines look like this:<br /> <br /> &lt;nowiki&gt;STAGE0_MAINBOARD_OBJ := $(obj)/mainboard/$(MAINBOARDDIR)/stage1.o \<br /> $(obj)/mainboard/$(MAINBOARDDIR)/option_table.o \<br /> $(obj)/southbridge/nvidia/mcp55/stage1_smbus.o&lt;/nowiki&gt;<br /> <br /> So that the stage1_smbus code is built in. How do we make it shared? We add these lines to mcp55_smbus.h<br /> <br /> &lt;nowiki&gt;#include &lt;shared.h&gt;&lt;/nowiki&gt;<br /> &lt;nowiki&gt;SHARED(do_smbus_recv_byte, int, u16 smbus_io_base, u8 device);&lt;/nowiki&gt;<br /> &lt;nowiki&gt;SHARED(do_smbus_send_byte, int, u16 smbus_io_base, u8 device, u8 val);&lt;/nowiki&gt;<br /> &lt;nowiki&gt;SHARED(do_smbus_read_byte, int, u16 smbus_io_base, u8 device, u8 address);&lt;/nowiki&gt;<br /> &lt;nowiki&gt;SHARED(do_smbus_write_byte, int, u16 smbus_io_base, u8 device, u8 address, u8 val);&lt;/nowiki&gt;<br /> &lt;nowiki&gt;SHARED(enable_smbus, void, void);&lt;/nowiki&gt;<br /> <br /> <br /> Result: we only compile a lot of code once, with the same compiler, and it can be called from anywhere.</div>

Rminnich http://www.coreboot.org/Welcome_to_coreboot 2008-08-11T15:34:59Z

<p>Rminnich: add a link for v3 port notes</p> <hr /> <div>&lt;table width=&quot;100%&quot; valign=&quot;top&quot;&gt;&lt;tr valign=&quot;top&quot;&gt;&lt;td width=&quot;80%&quot;&gt;<br /> <br /> &lt;div style=&quot;margin-top:0.5em; margin-bottom:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;&quot;&gt;<br /> '''coreboot''' (formerly known as LinuxBIOS) is a Free Software project aimed at replacing the proprietary BIOS (firmware) you can find in most of today's computers. It performs just a little bit of hardware initialization and then executes a so-called [[Payloads|payload]].<br /> &lt;/div&gt;<br /> <br /> {| cellspacing=0 cellpadding=3 border=0 margin=0 padding=0 align=&quot;top&quot; width=100%<br /> |-<br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {{Box|<br /> BORDER = #8898bf|<br /> BACKGROUND = yellow|<br /> WIDTH = 100%|<br /> ICON = &lt;small&gt;[[Benefits|More...]]&lt;/small&gt;|<br /> HEADING = [[Benefits]]|<br /> CONTENT =<br /> &lt;small&gt;<br /> * 100% Free Software (GPL), no royalties, no license fees!<br /> * Fast boot times (3 seconds to Linux console)<br /> * Avoids the need for a slow/buggy/proprietary BIOS<br /> &lt;!-- * Runs in 32-Bit protected mode almost from the start --&gt;<br /> * Written in C, contains virtually no assembly code<br /> * Supports many [[Supported Motherboards|mainboards]], [[Supported Chipsets and Devices|devices]], and [[payloads]]<br /> &lt;!-- * Further features: netboot, serial console, remote flashing, ... --&gt;<br /> &lt;/small&gt;<br /> }}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {{Box|<br /> BORDER = #8898bf|<br /> BACKGROUND = #d1adf6|<br /> WIDTH = 100%|<br /> ICON = &lt;small&gt;[[Use Cases|More...]]&lt;/small&gt;|<br /> HEADING = [[Use Cases]]|<br /> CONTENT =<br /> &lt;small&gt;<br /> * Desktop PCs, servers, clusters, thin clients<br /> * [[Clusters]], high-performance computing<br /> &lt;!-- * Set-Top-Boxes, thin clients --&gt;<br /> * Embedded solutions, STBs/HTPC, appliances, terminals<br /> &lt;!-- * [http://en.wikipedia.org/wiki/Small_form_factor Small form factor computers], [http://en.wikipedia.org/wiki/Home_theater_PC Home-theater PCs] --&gt;<br /> * No-moving-parts solutions (ROM chip as &quot;disk&quot;)<br /> * Non-standard scenarios (e.g. FPGA in Opteron socket)<br /> &lt;/small&gt;<br /> }}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {{Box|<br /> BORDER = #8898bf|<br /> BACKGROUND = lime|<br /> WIDTH = 100%|<br /> ICON = &lt;small&gt;[[Payloads|More...]]&lt;/small&gt;|<br /> HEADING = [[Payloads]]|<br /> CONTENT =<br /> &lt;small&gt;<br /> * [[GRUB2]] / [[FILO]]<br /> * [[Linux]] / [[Booting Windows using coreboot|Windows]] / [[Booting FreeBSD using coreboot|FreeBSD]] / [http://openbsd.org/ OpenBSD]<br /> * [[OpenFirmware]] et. al.<br /> * [[Etherboot]]<br /> * [[Memtest86]]<br /> &lt;/small&gt;<br /> }}<br /> <br /> |}<br /> <br /> {| cellspacing=5 cellpadding=5 border=0 valign=&quot;top&quot; width=100%<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_lb.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''About'''&lt;br /&gt;&lt;small&gt;Find out more about coreboot.&lt;hr /&gt;[[News]] | [[Press]] | [[Current events|Events]] | [[History]] | [[Screenshots|Screenshots &amp; Videos]] | [[Contributors]] | [[Sponsors]] | [[Products]] | [[Clusters]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_devel.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Developers'''&lt;br /&gt;&lt;small&gt;Get involved! Help us make coreboot better.&lt;hr /&gt;[[Development Guidelines]] | [[Developer Manual]] | [http://qa.coreboot.org/docs/doxygen.php Doxygen] | [http://tracker.coreboot.org/trac/coreboot/browser/trunk Browse Source] | [[JTAG/BSDL Guide|JTAG]] | [[EHCI Debug Port]] | [[Distributed and Automated Testsystem|Testsystem]] | [[GSoC]] | [[Ideas]] | [[Laptop]] | [[Desktops]]&lt;/small&gt;<br /> |}<br /> <br /> |-<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_status.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Status'''&lt;br /&gt;&lt;small&gt;Find out whether your hardware is already supported.&lt;hr /&gt;[[Supported Motherboards]] | [[Supported Chipsets and Devices|Supported Chipsets &amp; Devices]] | [http://qa.coreboot.org Build Status] | [[Flashrom#Supported_devices|Flashrom support]] | [[Superiotool#Supported_devices|Superiotool support]] | [[Notes for v3 ports]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_tools.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Related Tools'''&lt;br /&gt;&lt;small&gt;Tools and libraries related to coreboot.&lt;hr /&gt;[[Flashrom]] | [[Superiotool]] | [[Nvramtool]] | [[Buildrom]] | [[Libpayload]] | [[Mkelfimage]]&lt;/small&gt;<br /> |}<br /> <br /> |-<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_101.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Getting Started'''&lt;br /&gt;&lt;small&gt;Download coreboot and get started.&lt;hr /&gt;[[Download coreboot|Downloads]] | [[Documentation]] | [[:Category:Tutorials|Build Tutorials]] | [[Payloads]] | [[QEMU]] | [[AMD SimNow]] | [[Confirmed working svn revisions|Confirmed Working SVN Revisions]] | [[Misc]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_support.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Support'''&lt;br /&gt;&lt;small&gt;Learn how to contact us and find help and support.&lt;hr /&gt;[[FAQ]] | [[Mailinglist]] | [[IRC]] | [http://tracker.coreboot.org/trac/coreboot/ Issue Tracker] | [[Glossary]] | [[coreboot Options|corebootv2 Options]]&lt;/small&gt;<br /> |}<br /> <br /> |}<br /> &lt;/td&gt;&lt;td width=&quot;20%&quot;&gt;<br /> <br /> [[Image:Coreboot libpayload tint.png|center|thumb|coreboot [[tint]] payload]]<br /> <br /> &lt;br clear=all /&gt;<br /> <br /> '''&lt;span style=&quot;font-variant:small-caps;&quot;&gt;[[News]]&lt;/span&gt;'''&lt;hr /&gt;<br /> &lt;!-- Please always make this list 7 items long (7 most recent news items). --&gt;<br /> &lt;small&gt;<br /> * '''2008/08/04:''' [[News#2008.2F08.2F04_ASI_MB-5BLGP_.2F_Neoware_Eon_4000s_now_supported|ASI MB-5BLGP support]]<br /> * '''2008/07/01:''' [[News#2008.2F07.2F01_New_logo_announced|The new logo is announced]]<br /> * '''2008/07/01:''' [[News#2008.2F07.2F01_coreboot_booth_at_OpenExpo_in_Z.C3.BCrich|OpenExpo and Hackontest]]<br /> * '''2008/06/27:''' [[News#2008.2F06.2F27_A-Trend_ATC-6240_now_supported|A-Trend ATC-6240 support]]<br /> * '''2008/05/28:''' [[News#2008.2F05.2F28_coreboot_booth_at_LinuxTag_in_Berlin|coreboot @ LinuxTag]]<br /> * '''2008/05/19:''' [[News#2008.2F05.2F19_VIA_EPIA-CN_now_supported|VIA EPIA-CN support]]<br /> * '''2008/05/16:''' [[News#2008.2F05.2F16_Thomson_IP1000_now_supported|Thomson IP1000 support]]<br /> &lt;/small&gt;<br /> <br /> '''&lt;span style=&quot;font-variant:small-caps;&quot;&gt;Contact&lt;/span&gt;'''&lt;hr /&gt;<br /> &lt;small&gt;<br /> * [[Mailinglist|Mailing list]]: [mailto:coreboot@coreboot.org coreboot@coreboot.org]<br /> * [[IRC]]: '''#coreboot''' (on [http://www.freenode.net/ irc.freenode.net])<br /> &lt;/small&gt;<br /> &lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;<br /> __NOTOC__<br /> __NOEDITSECTION__</div>

Rminnich http://www.coreboot.org/Coreboot_Symposium_2008 2008-03-31T05:56:30Z

<p>Rminnich: /* Who is bringing what */</p> <hr /> <div>== Agenda ==<br /> <br /> general: breaks at 10-10:30, 12-1, 3-3:30<br /> <br /> === Thursday ===<br /> <br /> <br /> <br /> {| border=&quot;0&quot; style=&quot;font-size: smaller&quot; valign=&quot;top&quot;<br /> |- bgcolor=&quot;#6699dd&quot;<br /> ! align=&quot;left&quot; | Time<br /> ! align=&quot;left&quot; | Speaker<br /> ! align=&quot;left&quot; | Topic<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 1:00-2:00<br /> | Ron Minnich<br /> | Opening of the meeting and discussion of the last year<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 2:00-3:00<br /> | Stefan Reinauer<br /> | Automated Testbed, GSoC 2007, 2008<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 3:00-3:30<br /> | <br /> | break<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 3:30-4:00<br /> | Stefan Reinauer<br /> | coresystems' various BIOS customers, recent ports and other related work<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 4:00-end<br /> | <br /> | hack session -- set up boards and prioritize the goals of the rest of the time<br /> <br /> |}<br /> <br /> === Friday ===<br /> <br /> <br /> <br /> {| border=&quot;0&quot; style=&quot;font-size: smaller&quot; valign=&quot;top&quot;<br /> |- bgcolor=&quot;#6699dd&quot;<br /> ! align=&quot;left&quot; | Time<br /> ! align=&quot;left&quot; | Speaker<br /> ! align=&quot;left&quot; | Topic<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 8:30-10:00<br /> | Marc Jones (AMD)<br /> | AMD talks about whatever they want :-)<br /> - consumer issues<br /> <br /> - what's going on<br /> <br /> - new ports this year<br /> <br /> - K10?<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 10:00-10:30<br /> | <br /> | break<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 10:30-12:00<br /> | Marc Karasek (Sun)<br /> | Marc talks about his work at Sun with SimNow<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 12:00-1:00<br /> | <br /> | Lunch<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 1:00-3:00<br /> | Ron Minnich<br /> | Ron gives an overview of v3, from the smallest to the large bits.<br /> Sample build/burn session<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 3:00-3:30<br /> | <br /> | break<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 3:30-4:00<br /> | <br /> | open questions (please add some)<br /> 1. how do we tell when a board is good enough to move from v2 to v3?<br /> <br /> What's the test?<br /> <br /> 2. What pending issues are there?<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 4:00-5:00<br /> | Ward Vandewege<br /> | The view from the FSF -- what's going on, etc.<br /> <br /> |}<br /> <br /> === Saturday ===<br /> <br /> * hack all day. We hope to fix the problems we prioritized Thursday.<br /> <br /> == What needs to be brought ==<br /> <br /> * monitor<br /> * power supplies<br /> <br /> == Who is bringing what ==<br /> <br /> <br /> '''Ron:''' dbe61 and dbe62. Alix 1C. Alix LPC pod. Artec LPC pod. MINI PCI and PCI post cards. T23 with ubuntu. Outlet strips. FS2 if it arrives from LANL on time (it may not). USB hubs? ISDN card that causes Alix 1.c failure. <br /> Ethernet switch. USB PCI card for testing Alix 1.C. Somebody bring some cat 5 cables -- I forgot mine! Camera.<br /> I'm now in Denver!<br /> <br /> <br /> '''Ward:''' alix2c3, Artec LPC dongle. I can bring an alix.1c too but Ron's already bringing one.<br /> <br /> '''Stefan:''' Advantech PCM-5820, possibly other boards, Artec LPC Dongle, ByteBlaster II (if it arrives in time), other JTAG cables on Request, Galep-5 Flash Writer, Flash Plaice(?)<br /> <br /> '''Jordan:''' Norwich, FS2, ROM emulator, monitor, PS/2 keyboard, serial cable, laptop and lots of code.<br /> <br /> '''MarcJ:''' Norwich, DB800, DBE61, ROM emulators, fs2, keyboard, cables, monitor, hd, atx power, etc. - any requests?<br /> <br /> == Current show stopper issues ==<br /> <br /> * ALIX1.C and DB800 lockup if MFGPT are enabled in kernel.<br /> * ALIX1.C interrupt flood if ISDN card is enabled (may be related to MFGPT issue).<br /> * DBE62 RAM timing is wrong.<br /> * DBE62 PLL reset gives wrong value on auto setting.<br /> * SiS card can't program 2M flash part.<br /> <br /> See also [http://www.coreboot.org/pipermail/coreboot/2008-March/032455.html Denver meeting discussion topics] for more ideas.</div>

Rminnich http://www.coreboot.org/Welcome_to_coreboot 2008-03-28T04:42:26Z

<p>Rminnich: just a headline, remove in 10 days, about coreboot summit</p> <hr /> <div>&lt;table width=&quot;100%&quot; valign=&quot;top&quot;&gt;&lt;tr valign=&quot;top&quot;&gt;&lt;td width=&quot;80%&quot;&gt;<br /> <br /> &lt;div style=&quot;margin-top:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;&quot;&gt;<br /> '''coreboot''' (formerly known as LinuxBIOS) is a Free Software project aimed at replacing the proprietary BIOS (firmware) you can find in most of today's computers. It performs just a little bit of hardware initialization and then executes a so-called [[Payloads|payload]].<br /> <br /> The 2008 coreboot summit is in 1 week! Hope to see you there. See the link in Current events for more information. <br /> <br /> Thanks to AMD for being a Silver supporter of the 2008 coreboot summit!<br /> &lt;/div&gt;<br /> {| cellspacing=2 cellpadding=2 border=0 valign=&quot;top&quot; width=100%<br /> |-<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps;&quot;&gt;[[Benefits]]&lt;/span&gt;'''<br /> &lt;hr /&gt;<br /> &lt;small&gt;<br /> * 100% Free Software (GPL), no royalties, no license fees!<br /> * Fast boot times (3 seconds to Linux console)<br /> * Avoids the need for a slow/buggy/proprietary BIOS<br /> * Runs in 32-Bit protected mode almost from the start<br /> * Written in C, contains virtually no assembly code<br /> * Supports many [[Supported Motherboards|mainboards]], [[Supported Chipsets and Devices|devices]], and [[payloads]]<br /> * Further features: netboot, serial console, remote flashing, ...<br /> &lt;/small&gt;<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps;&quot;&gt;[[Use Cases]]&lt;/span&gt;'''<br /> &lt;hr /&gt;<br /> &lt;small&gt;<br /> * Standard desktop computers and servers<br /> * [[Clusters]], high-performance computing<br /> * Set-Top-Boxes, thin clients<br /> * Embedded solutions, appliances, terminals<br /> * [http://en.wikipedia.org/wiki/Small_form_factor Small form factor computers], [http://en.wikipedia.org/wiki/Home_theater_PC Home-theater PCs] <br /> * No-moving-parts solutions (ROM chip as &quot;disk&quot;)<br /> * Non-standard scenarios (e.g. FPGA in Opteron socket)<br /> &lt;/small&gt;<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps;&quot;&gt;[[Payloads]]&lt;/span&gt;'''<br /> &lt;hr /&gt;<br /> &lt;table&gt;&lt;tr style=&quot;vertical-align:top&quot;&gt;&lt;td&gt;<br /> &lt;small&gt;<br /> * [[Linux]]<br /> * [[FILO]]<br /> * [[GRUB2]]<br /> * [[Booting Windows using coreboot|Windows]] ([[ADLO]])<br /> * [[Booting FreeBSD using coreboot|FreeBSD]] ([[ADLO]])<br /> * [http://openbsd.org/ OpenBSD] ([[ADLO]])<br /> * [[memtest86]]<br /> &lt;/small&gt;<br /> &lt;/td&gt;&lt;td&gt;<br /> &lt;small&gt;<br /> * [http://www.openbios.org/ OpenBIOS]<br /> * [http://www.openbios.org/Open_Firmware Open Firmware]<br /> * [http://www.openbios.org/SmartFirmware SmartFirmware]<br /> * [http://www.gnu.org/software/gnufi/ GNUFI] (UEFI)<br /> * [[Etherboot]]<br /> * [[Plan 9]]<br /> * [[coreinfo]]<br /> &lt;/small&gt;<br /> &lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;<br /> |}<br /> &lt;hr /&gt;<br /> {| cellspacing=5 cellpadding=5 border=0 valign=&quot;top&quot; width=100%<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_lb.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''About'''&lt;br /&gt;&lt;small&gt;Find out more about coreboot.&lt;hr /&gt;[[News]] | [[Press]] | [[Current events|Events]] | [[History]] | [[Screenshots|Screenshots &amp; Videos]] | [[Contributors]] | [[Sponsors]] | [[Products]] | [[Clusters]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_devel.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Developers'''&lt;br /&gt;&lt;small&gt;Get involved! Help us make coreboot better.&lt;hr /&gt;[[Development Guidelines]] | [[Developer Manual]] | [http://qa.coreboot.org/docs/doxygen.php Doxygen] | [http://tracker.coreboot.org/trac/coreboot/browser/trunk/coreboot-v2 Browse Source] | [[JTAG/BSDL Guide|JTAG]] | [[EHCI Debug Port]] | [[Distributed and Automated Testsystem|Testsystem]] | [[GSoC]] | [[Ideas]] | [[Laptop]] | [[Desktops]]&lt;/small&gt;<br /> |}<br /> <br /> |-<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_status.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Status'''&lt;br /&gt;&lt;small&gt;Find out whether your hardware is already supported.&lt;hr /&gt;[[Supported Motherboards]] | [[Supported Chipsets and Devices|Supported Chipsets &amp; Devices]] | [http://qa.coreboot.org Build Status] | [[Flashrom#Supported_devices|Flashrom support]] | [[Superiotool#Supported_devices|Superiotool support]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_tools.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Related Tools'''&lt;br /&gt;&lt;small&gt;Tools and libraries related to coreboot.&lt;hr /&gt;[[Flashrom]] | [[Superiotool]] | [[Nvramtool]] | [[Buildrom]] | [[Libpayload]] | [[Mkelfimage]] &lt;/small&gt;<br /> |}<br /> <br /> |-<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_101.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Getting Started'''&lt;br /&gt;&lt;small&gt;Download coreboot and get started.&lt;hr /&gt;[[Download coreboot|Downloads]] | [[Documentation]] | [[:Category:Tutorials|Build Tutorials]] | [[Payloads]] | [[QEMU]] | [[AMD SimNow]] | [[Confirmed working svn revisions|Confirmed Working SVN Revisions]] | [[Misc]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_support.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Support'''&lt;br /&gt;&lt;small&gt;Learn how to contact us and find help and support.&lt;hr /&gt;[[FAQ]] | [[Mailinglist]] | [[IRC]] | [http://tracker.coreboot.org/trac/coreboot/ Issue Tracker] | [[Glossary]] | [[coreboot Options|corebootv2 Options]]&lt;/small&gt;<br /> |}<br /> <br /> |}<br /> &lt;/td&gt;&lt;td width=&quot;20%&quot;&gt;<br /> <br /> [[Image:Coreinfo pci.png|thumb|The [[coreinfo|coreinfo payload]].]]<br /> &lt;br clear=all /&gt;<br /> <br /> '''&lt;span style=&quot;font-variant:small-caps;&quot;&gt;[[News]]&lt;/span&gt;'''&lt;hr /&gt;<br /> &lt;small&gt;<br /> * '''2008/04/03:''' [[News#2008.2F04.2F03_coreboot_Symposium_in_Denver|coreboot Symposium Denver]]<br /> * '''2008/03/17:''' [[News#2008.2F03.2F17_MSI_MS-6119_now_supported|MSI MS-6119 support]]<br /> * '''2008/03/17:''' [[News#2008.2F03.2F17_Intel_3100_chipset_and_Intel_devkit_.28Mt._Arvon.29_board_now_supported|Intel 3100 / Mt.Arvon support]]<br /> * '''2008/03/09:''' [[News#2008.2F03.2F09_RCA_RM4100_now_supported|RCA RM4100 support]]<br /> * '''2008/03/07:''' [[News#2008.2F03.2F07_ASUS_A8V-E_Deluxe_now_supported|ASUS A8V-E Deluxe support]]<br /> * '''2008/02/20:''' [[News#2008.2F02.2F20_MSI_MS-7135_.28K8N_Neo3.29_now_supported|MSI MS-7135 (K8N Neo3) support]]<br /> * '''2008/01/27:''' [[News#2008.2F01.2F27_Abit_BE6-II_V2.0_now_supported|Abit BE6-II V2.0 support]]<br /> &lt;/small&gt;<br /> <br /> '''&lt;span style=&quot;font-variant:small-caps;&quot;&gt;Contact&lt;/span&gt;'''&lt;hr /&gt;<br /> &lt;small&gt;<br /> * [[Mailinglist|Mailing list]]: [mailto:coreboot@coreboot.org coreboot@coreboot.org]<br /> * [[IRC]]: '''#coreboot''' (on [http://www.freenode.net/ irc.freenode.net])<br /> &lt;/small&gt;<br /> <br /> &lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;<br /> __NOTOC__<br /> __NOEDITSECTION__</div>

Rminnich http://www.coreboot.org/Coreboot_Symposium_2008 2008-03-27T20:28:29Z

<p>Rminnich: /* Current show stopper issues */</p> <hr /> <div>== Agenda ==<br /> <br /> general: breaks at 10-10:30, 12-1, 3-3:30<br /> <br /> === Thursday ===<br /> <br /> <br /> <br /> {| border=&quot;0&quot; style=&quot;font-size: smaller&quot; valign=&quot;top&quot;<br /> |- bgcolor=&quot;#6699dd&quot;<br /> ! align=&quot;left&quot; | Time<br /> ! align=&quot;left&quot; | Speaker<br /> ! align=&quot;left&quot; | Topic<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 1:00-2:00<br /> | Ron Minnich<br /> | Opening of the meeting and discussion of the last year<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 2:00-3:00<br /> | Stefan Reinauer<br /> | Automated Testbed, GSoC 2007, 2008<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 3:00-3:30<br /> | <br /> | break<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 3:30-4:00<br /> | Stefan Reinauer<br /> | coresystems' various BIOS customers, recent ports and other related work<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 4:00-end<br /> | <br /> | hack session -- set up boards and prioritize the goals of the rest of the time<br /> <br /> |}<br /> <br /> === Friday ===<br /> <br /> <br /> <br /> {| border=&quot;0&quot; style=&quot;font-size: smaller&quot; valign=&quot;top&quot;<br /> |- bgcolor=&quot;#6699dd&quot;<br /> ! align=&quot;left&quot; | Time<br /> ! align=&quot;left&quot; | Speaker<br /> ! align=&quot;left&quot; | Topic<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 8:30-10:00<br /> | Marc Jones (AMD)<br /> | AMD talks about whatever they want :-)<br /> - consumer issues<br /> <br /> - what's going on<br /> <br /> - new ports this year<br /> <br /> - K10?<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 10:00-10:30<br /> | <br /> | break<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 10:30-12:00<br /> | Marc Karasek (Sun)<br /> | Marc talks about his work at Sun with SimNow<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 12:00-1:00<br /> | <br /> | Lunch<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 1:00-3:00<br /> | Ron Minnich<br /> | Ron gives an overview of v3, from the smallest to the large bits.<br /> Sample build/burn session<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 3:00-3:30<br /> | <br /> | break<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 3:30-4:00<br /> | <br /> | open questions (please add some)<br /> 1. how do we tell when a board is good enough to move from v2 to v3?<br /> <br /> What's the test?<br /> <br /> 2. What pending issues are there?<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 4:00-5:00<br /> | Ward Vandewege<br /> | The view from the FSF -- what's going on, etc.<br /> <br /> |}<br /> <br /> === Saturday ===<br /> <br /> * hack all day. We hope to fix the problems we prioritized Thursday.<br /> <br /> == What needs to be brought ==<br /> <br /> * monitor<br /> * power supplies<br /> <br /> == Who is bringing what ==<br /> <br /> <br /> '''Ron:''' dbe61 and dbe62. Alix 1C. Alix LPC pod. Artec LPC pod. T23 with ubuntu. OLPC devel board for v3 test. (No OLPC, it's too distracting). Outlet strips. FS2 if it arrives from LANL on time (it may not). USB hubs? ISDN card that causes Alix 1.c failure. The new SiS card (if I can find a way to bring a monitor)<br /> What else?<br /> <br /> '''Ward:''' alix2c3, Artec LPC dongle. I can bring an alix.1c too but Ron's already bringing one.<br /> <br /> '''Stefan:''' Advantech PCM-5820, possibly other boards, Artec LPC Dongle, ByteBlaster II (if it arrives in time), other JTAG cables on Request, Galep-5 Flash Writer, Flash Plaice(?)<br /> <br /> '''Jordan:''' Norwich, FS2, ROM emulator, monitor, PS/2 keyboard, serial cable, laptop and lots of code.<br /> <br /> == Current show stopper issues ==<br /> <br /> Alix 1.c lockup if MFGPT are enabled in kernel<br /> <br /> Alix 1.c interrupt flood if ISDN card is enabled. (may be related to MFGPT issue)<br /> <br /> DBE62 RAM timing is wrong<br /> <br /> DBE62 PLL reset gives wrong value on auto setting.<br /> <br /> SiS card can't program 2M flash part</div>

Rminnich http://www.coreboot.org/Coreboot_Symposium_2008 2008-03-27T20:28:02Z

<p>Rminnich: </p> <hr /> <div>== Agenda ==<br /> <br /> general: breaks at 10-10:30, 12-1, 3-3:30<br /> <br /> === Thursday ===<br /> <br /> <br /> <br /> {| border=&quot;0&quot; style=&quot;font-size: smaller&quot; valign=&quot;top&quot;<br /> |- bgcolor=&quot;#6699dd&quot;<br /> ! align=&quot;left&quot; | Time<br /> ! align=&quot;left&quot; | Speaker<br /> ! align=&quot;left&quot; | Topic<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 1:00-2:00<br /> | Ron Minnich<br /> | Opening of the meeting and discussion of the last year<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 2:00-3:00<br /> | Stefan Reinauer<br /> | Automated Testbed, GSoC 2007, 2008<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 3:00-3:30<br /> | <br /> | break<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 3:30-4:00<br /> | Stefan Reinauer<br /> | coresystems' various BIOS customers, recent ports and other related work<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 4:00-end<br /> | <br /> | hack session -- set up boards and prioritize the goals of the rest of the time<br /> <br /> |}<br /> <br /> === Friday ===<br /> <br /> <br /> <br /> {| border=&quot;0&quot; style=&quot;font-size: smaller&quot; valign=&quot;top&quot;<br /> |- bgcolor=&quot;#6699dd&quot;<br /> ! align=&quot;left&quot; | Time<br /> ! align=&quot;left&quot; | Speaker<br /> ! align=&quot;left&quot; | Topic<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 8:30-10:00<br /> | Marc Jones (AMD)<br /> | AMD talks about whatever they want :-)<br /> - consumer issues<br /> <br /> - what's going on<br /> <br /> - new ports this year<br /> <br /> - K10?<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 10:00-10:30<br /> | <br /> | break<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 10:30-12:00<br /> | Marc Karasek (Sun)<br /> | Marc talks about his work at Sun with SimNow<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 12:00-1:00<br /> | <br /> | Lunch<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 1:00-3:00<br /> | Ron Minnich<br /> | Ron gives an overview of v3, from the smallest to the large bits.<br /> Sample build/burn session<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 3:00-3:30<br /> | <br /> | break<br /> <br /> |- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br /> | 3:30-4:00<br /> | <br /> | open questions (please add some)<br /> 1. how do we tell when a board is good enough to move from v2 to v3?<br /> <br /> What's the test?<br /> <br /> 2. What pending issues are there?<br /> <br /> |- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br /> | 4:00-5:00<br /> | Ward Vandewege<br /> | The view from the FSF -- what's going on, etc.<br /> <br /> |}<br /> <br /> === Saturday ===<br /> <br /> * hack all day. We hope to fix the problems we prioritized Thursday.<br /> <br /> == What needs to be brought ==<br /> <br /> * monitor<br /> * power supplies<br /> <br /> == Who is bringing what ==<br /> <br /> <br /> '''Ron:''' dbe61 and dbe62. Alix 1C. Alix LPC pod. Artec LPC pod. T23 with ubuntu. OLPC devel board for v3 test. (No OLPC, it's too distracting). Outlet strips. FS2 if it arrives from LANL on time (it may not). USB hubs? ISDN card that causes Alix 1.c failure. The new SiS card (if I can find a way to bring a monitor)<br /> What else?<br /> <br /> '''Ward:''' alix2c3, Artec LPC dongle. I can bring an alix.1c too but Ron's already bringing one.<br /> <br /> '''Stefan:''' Advantech PCM-5820, possibly other boards, Artec LPC Dongle, ByteBlaster II (if it arrives in time), other JTAG cables on Request, Galep-5 Flash Writer, Flash Plaice(?)<br /> <br /> '''Jordan:''' Norwich, FS2, ROM emulator, monitor, PS/2 keyboard, serial cable, laptop and lots of code.<br /> <br /> == Current show stopper issues ==<br /> <br /> Alix 1.c lockup if MFGPT are enabled in kernel<br /> <br /> Alix 1.c interrupt flood if ISDN card is enable. <br /> <br /> DBE62 RAM timing is wrong<br /> <br /> DBE62 PLL reset gives wrong value on auto setting.<br /> <br /> SiS card can't program 2M flash part</div>

Rminnich http://www.coreboot.org/Coreboot_Symposium_2008 2008-03-27T18:57:07Z

<p>Rminnich: /* Agenda */</p> <hr /> <div>== Agenda ==<br /> <br /> general: breaks at 10-10:30, 12-1, 3-3:30<br /> <br /> 1-2 Ron opens the meeting and discusses the last year<br /> <br /> 2-3 Stepan talks about the automated testbed, and GSOC 2007 and 2008<br /> <br /> 3-330 break<br /> <br /> 330-400 Stepan talks about<br /> - his work with the german army etc.<br /> - his recent ports<br /> <br /> 400-rest of day hack session -- set up boards and prioritize the goals of the rest of the time<br /> <br /> friday<br /> <br /> 0830-1000 AMD talks about whatever they want :-)<br /> - consumer issues<br /> - what's going on<br /> - new ports this year<br /> - K10?<br /> <br /> 1000-1030 break<br /> <br /> 1030-1200 Marc talks about his work at Sun with simnow<br /> <br /> 1200-0100 lunch<br /> <br /> 0100- 0300 Ton gives an overview of v3, from the smallest to the large bits.<br /> Sample build/burn session<br /> <br /> 0300-0330 break<br /> <br /> 0330- 0400<br /> open questions (please add some)<br /> 1. how do we tell when a board is good enough to move from v2 to v3?<br /> What's the test?<br /> 2. What pending issues are there?<br /> <br /> 0400-0500 The view from the FSF -- what's going on, etc.<br /> <br /> saturday -- hack all day. We hope to fix the problems we prioritized thursday.<br /> <br /> == What needs to be brought ==<br /> <br /> == Who is bringing what ==<br /> <br /> <br /> '''Ron:''' dbe61 and dbe62. Alix 1C. Alix LPC pod. Artec LPC pod. T23 with ubuntu. OLPC devel board for v3 test. (No OLPC, it's too distracting). Outlet strips. FS2 if it arrives from LANL on time (it may not). USB hubs? <br /> What else?</div>

Rminnich http://www.coreboot.org/Coreboot_Symposium_2008 2008-03-27T18:56:38Z

<p>Rminnich: /* Agenda */</p> <hr /> <div>== Agenda ==<br /> <br /> general: breaks at 10-10:30, 12-1, 3-3:30<br /> <br /> 1-2 Ron opens the meeting and discusses the last year<br /> <br /> 2-3 Stepan talks about the automated testbed, and GSOC 2007 and 2008<br /> <br /> 3-330 break<br /> <br /> 330-400 Stepan talks about<br /> - his work with the german army etc.<br /> - his recent ports<br /> <br /> 400-rest of day hack session -- set up boards and prioritize the goals of the rest of the time<br /> <br /> friday<br /> <br /> 0830-1000 AMD talks about whatever they want :-)<br /> - consumer issues<br /> - what's going on<br /> - new ports this year<br /> - K10?<br /> <br /> 1000-1030 break<br /> <br /> 1030-1200 Marc talks about his work at Sun with simnow<br /> <br /> 1200-0100 lunch<br /> <br /> 0100- 0300 Ton gives an overview of v3, from the smallest to the large bits.<br /> Sample build/burn session<br /> <br /> 0300-0330 break<br /> <br /> 0330- 0400<br /> open questions (please add some)<br /> 1. how do we tell when a board is good enough to move from v2 to v3?<br /> What's the test?<br /> 2. How do we avoid what happened with the SiS-based board?<br /> 3. Could OLPC have been &quot;saved&quot;? What went right/wrong?<br /> 4. What pending issues are there.<br /> <br /> 0400-0500 The view from the FSF -- what's going on, etc.<br /> <br /> saturday -- hack all day. We hope to fix the problems we prioritized thursday.<br /> <br /> == What needs to be brought ==<br /> <br /> == Who is bringing what ==<br /> <br /> <br /> '''Ron:''' dbe61 and dbe62. Alix 1C. Alix LPC pod. Artec LPC pod. T23 with ubuntu. OLPC devel board for v3 test. (No OLPC, it's too distracting). Outlet strips. FS2 if it arrives from LANL on time (it may not). USB hubs? <br /> What else?</div>

Rminnich http://www.coreboot.org/Coreboot_Symposium_2008 2008-03-27T18:54:56Z

<p>Rminnich: New page for denver. Primitive.</p> <hr /> <div><br /> == Agenda ==<br /> <br /> general: breaks at 10-10:30, 12-1, 3-3:30<br /> <br /> 1-2 Ron opens the meeting and discusses the last year<br /> 2-3 Stepan talks about the automated testbed, and GSOC 2007 and 2008<br /> <br /> 3-330 break<br /> 330-400 Stepan talks about<br /> - his work with the german army etc.<br /> - his recent ports<br /> 400-rest of day hack session -- set up boards and prioritize the goals of the rest of the time<br /> <br /> next day<br /> 0830-1000 AMD talks about whatever they hell they want :-)<br /> - consumer issues<br /> - what's going on<br /> - new ports this year<br /> - K10?<br /> 1000-1030 break<br /> 1030-1200 Marc talks about his work at Sun with simnow<br /> 1200-0100 lunch<br /> 0100- 0300 Ton gives an overview of v3, from the smallest to the large bits.<br /> Sample build/burn session<br /> 0300-0330 break<br /> 0330- 0400<br /> open questions (please add some)<br /> 1. how do we tell when a board is good enough to move from v2 to v3?<br /> What's the test?<br /> 2. How do we avoid what happened with the SiS-based board?<br /> 3. Could OLPC have been &quot;saved&quot;? What went right/wrong?<br /> 4. What pending issues are there.<br /> <br /> 0400-0500 The view from the FSF -- what's going on, etc.<br /> <br /> saturday -- hack all day. We hope to fix the problems we prioritized thursday.<br /> <br /> <br /> <br /> == What needs to be brought ==<br /> <br /> == Who is bringing what ==<br /> <br /> <br /> '''Ron:''' dbe61 and dbe62. Alix 1C. Alix LPC pod. Artec LPC pod. T23 with ubuntu. OLPC devel board for v3 test. (No OLPC, it's too distracting). Outlet strips. FS2 if it arrives from LANL on time (it may not). USB hubs? <br /> What else?</div>

Rminnich http://www.coreboot.org/Current_events 2008-03-27T18:44:35Z

<p>Rminnich: add a page for denver 2008 meeting</p> <hr /> <div>There will be a coreboot symposium in Denver, April 3 – 5, 2008 held during the High Performance Computer Science Week (HPCSW). Register for the summit at [http://www.hpcsw.org LinuxBIOS Summit]. When registering, don't forget to check the 'Linuxbios Summit' check box. [[Here]] is more information. <br /> <br /> Another coreboot symposium will probably take place in 2009 in Europe.<br /> <br /> Coreboot will also be exhibiting at [http://www.linuxtag.org/2008/en/home/welcome.html LinuxTag 2008] in Berlin, May 28-31.<br /> <br /> Please contact [[User:Stepan|Stefan Reinauer]] or [[User:Rminnich|Ronald Minnich]] for more information on the events.<br /> <br /> == Older Events ==<br /> <br /> * There was a [[News#2007.2F05.2F23_LinuxBIOS_booth_at_LinuxTag_in_Berlin.2C_29.2F5-2.2F6|LinuxBIOS booth at the LinuxTag in Berlin, May 29 - June 6, 2007]], as well as a hands-on workshop by Peter Stuge.<br /> * Ron Minnich gave [http://www.fosdem.org/2007/schedule/events/linuxbios a talk about LinuxBIOS] on February 24, 2007 at [http://www.fosdem.org/2007/ FOSDEM 2007].<br /> * The [[LinuxBIOS Symposium 2006]] took place on October 1-3, 2006 in Hamburg, Germany<br /> * The [[LinuxBIOS Summit 2005]] took place on October 11-13 in Santa Fe, NM.</div>

Rminnich http://www.coreboot.org/GSoC 2008-03-11T00:54:07Z

<p>Rminnich: </p> <hr /> <div>= Google Summer of Code 2008 =<br /> <br /> Welcome to the [http://code.google.com/soc/ Google Summer of Code(tm)] page of the [[Welcome to coreboot|coreboot project]].<br /> <br /> = Your own Projects =<br /> <br /> We've listed some ideas for projects here, but we're more than happy to entertain other ideas if you've got any.<br /> Feel free to contact us under the address below, and don't hesitate to suggest whatever you have in mind.<br /> <br /> = Summer of Code 2008 Application =<br /> <br /> Please complete the standard [http://code.google.com/soc/ Google SoC 2008 application]. Additionally, please provide information on the following:<br /> <br /> # Who are you? What are you studying?<br /> # Why are you the right person for this task?<br /> # Do you have any other commitments that we should know about?<br /> # List your C, Assembler or Java experience. (Depending on the project)<br /> # List your history with open source projects.<br /> # What is your preferred method of contact? (Phone, email, Skype, etc) <br /> <br /> Feel free to keep your application short. A 15 page essay is no better than a 2 page summary. If you wish to write 15 pages, you are of course welcome to do so, and we will gladly put your paper up on the web page. But it is not required for the application.<br /> <br /> The Drupal project has a great page on [http://drupal.org/node/59037 How to write an SOC application].<br /> <br /> '''DEADLINE FOR STUDENT APPLICATIONS:''' Students who are interested in working on a coreboot-related GSoC project must apply between '''March 24, 2008''' and '''March 30, 2008'''!<br /> <br /> = Contact =<br /> <br /> If you are interested in becoming a GSoC student, please contact [mailto:stepan@coresystems.de Stefan Reinauer].<br /> <br /> There is also an IRC channel on irc.freenode.net: #coreboot<br /> <br /> = Projects 2008 =<br /> <br /> == VGA BIOS for Geode LX ==<br /> <br /> This project's goal is to write a VGA BIOS (PCI option rom) for AMD Geode LX systems (such as the Linutop, Thincan or XO). There exists a [http://savannah.nongnu.org/projects/vgabios free VGA BIOS] but it knows nothing about real hardware. If you really want to kick the iron, this project could be enhanced to contain a complete infrastructure for including hardware initialization code for many different graphics cards.<br /> <br /> == SCSI booting in coreboot ==<br /> <br /> Currently coreboot can not boot from an arbitrary SCSI controller. There are two solutions for the problem:<br /> * Use Linux and Kexec. This requires to keep the SCSI driver in the flash chip.<br /> * Use x86emu/vm86/[[ADLO]] and the int13 method. This would allow to use the PCI option rom available on all modern SCSI controllers.<br /> <br /> So we obviously need a solution based on the later. This could as well be implemented as a Linux program, as an intermediate payload, or as a shared library.<br /> <br /> The code you are going to write needs to catch the int13 interrupt vector that the SCSI option rom installs and make it available to arbitrary (firmware/payload) code trying to load something from disk.<br /> <br /> This is a coreboot v3 project.<br /> <br /> == coreboot graphical port creator ==<br /> <br /> In coreboot v2, every port to a new mainboard requires that you touch a lot of source files with only minimal changes. In version 3 we try to fix this issue and pack all mainboard specific information into a configuration file that we call the Device Tree Source (DTS). <br /> This Device Tree config file is a simple text file describing what static (non-detectable and/or soldered on) devices are used on the mainbard and how they are wired (SPD-ROM, Interrupt Routing, SuperIO, Northbridge, Southbridge, Hypertransport,..). It is mostly organized as a tree (with some special cases, Hypertransport allows cycles for instance)<br /> <br /> The idea is to create a tool, based on the [www.eclipse.org/ Eclipse IDE], Swing, or your favourite portable toolkit, which allows you to drag and drop those components together and describe how they are wired. <br /> <br /> This would be a great help for mainboard vendors that build mainboards of already supported components. No more reading of coreboot code would be required, but rather only the understanding of the hardware, and probably the mainboard schematics.<br /> <br /> This is a coreboot v3 project. It requires good Java and/or Eclipse skills (or whatever toolkit/language you choose)<br /> <br /> == TianoCore on coreboot ==<br /> <br /> [http://www.tianocore.org/ Tiano Core] is Intel's EFI implementation. Unlike coreboot, it is not a firmware, but rather a bootloader. Last year we started porting TianoCore to run on coreboot, but there are many things left to do. Improve Tiano Core running as a coreboot payloads, or change coreboot so it can load Tiano Core as a payloads.<br /> <br /> This project requires no hardware skills, but especially in case of TianoCore might require knowledge of Windows compilers (VC2005?)<br /> <br /> == libpayload ==<br /> <br /> There are many, many &quot;payloads&quot; for coreboot these days: Linux, FILO, GRUB2, Tiano Core, Open Firmware, etherboot, and some more to count. All these payloads have a few functions in common that they use to read information from coreboot or change coreboot settings in NVRAM. It would be incredibly useful to unify all this code and enhance it, so that not every coreboot payload has to keep reinventing the wheel.<br /> <br /> == All Virtual All The Time (AVATT) ==<br /> <br /> The goal here is to build a system that comes up running Linux and KVM from power on reset. From that<br /> point the system could boot anything -- Windows, Linux, *BSD, Plan 9 -- anything that runs<br /> on x86 32 and 64-bit architectures. Coreboot would be <br /> integrated with a Linux kernel and initrd that had KVM built in. The initrd would include the minimal set of tools needed for starting new KVM virtual machine guests. Note that Linux booting from coreboot is a solved <br /> problem, using the buildrom tool, so the main effort here is to develop a minimal KVM infrastructure that<br /> can fit in a 2Mbyte FLASH part. Linux + X11 have been demonstrated in a 1Mbyte part, so we feel that this<br /> task is not impossible, but will be a terrific learning experience for a student, and will provide<br /> the community with a valuable resource when it is finished. The Xen and KVM communities have both asked<br /> for this capability for some time now, so there is a group of people ready to use this system when it is<br /> finished. <br /> <br /> = Projects 2007 =<br /> <br /> <br /> == Booting Windows and other Operating Systems in LinuxBIOS [http://linuxbios.org/Booting_Windows_using_LinuxBIOS]==<br /> <br /> The goal of this sub project is to figure out how to boot Windows Vista/XP/2003. There are three approaches that might proof successful:<br /> <br /> * using a dedicated LinuxBIOS loader (ie. adapting [http://www.reactos.org/ ReactOS] FREELDR)<br /> * booting Windows on top of Linux using [http://www.xmission.com/~ebiederm/files/kexec/README kexec]/[http://kboot.sourceforge.net/ kboot]<br /> * fixing [[ADLO]] so that it boots Vista/XP and removing the mainboard dependencies in it's code.<br /> * Some information on usage of bios services in Windows can be found [http://www.missl.cs.umd.edu/winint/index1.html here] and [http://www.missl.cs.umd.edu/winint/index2.html here].<br /> <br /> == Port GRUB2 to work in LinuxBIOS ==<br /> <br /> [[GRUB2]] is going to be _the_ bootloader of choice in the forseeable future. As such, it could replace both Grub legacy and FILO, the LinuxBIOS hack for grub compatibility. FILO lacks many features that come with GRUB2 with no extra effort.<br /> <br /> This task splits into four sub-problems:<br /> <br /> * Add a target i386-linuxbios, next to i386-pc and i386-efi to the configuration process<br /> * Add an IDE driver that does direct access instead of intXX calls<br /> * Make the build process generate a single static ELF image, like it is done on Sparc<br /> * Add support for reading the memory size from the LinuxBIOS table.<br /> <br /> <br /> == CMOS Config / Device Tree Browser Payload ==<br /> <br /> Unlike other BIOSes, Linux has no such thing as a &quot;CMOS setup&quot;. This does not mean that you can not configure it. There is a nice and small Linux command line utility called [http://lxbios.sf.net lxbios] for that purpose. But people are often asking for a builtin config tool. Such a config tool could feature VGA graphics (maybe even VESA?), it should be easy to use, allow to browse information from LinuxBIOS' central structure: the device tree, and provide lxbios functionality with some sex appeal.<br /> <br /> This is a LinuxBIOSv3 project.<br /> <br /> == Open Firmware payload for LinuxBIOS ==<br /> <br /> Mitch Bradley from [http://www.firmworks.com/ Firmworks, Inc.] released the [http://www.openbios.org/OpenFirmware Open Firmware sources] under a BSD license. The released code does work in LinuxBIOS, but could use some proper integration and testing on some hardware or in [http://fabrice.bellard.free.fr/qemu/ Qemu]. <br /> <br /> Some ideas:<br /> <br /> * The released Open Firmware code is very much optimized towards the OLPC. A lot of things don't work yet on other systems, such as using a graphical framebuffer. Therefore things in LinuxBIOS need to be changed. For example, if LinuxBIOS initializes a graphics mode, it should add a LinuxBIOS table entry that specifies the address of the framebuffer and the depth and resolution.<br /> * Add words to view the LinuxBIOS table in OFW<br /> * Add words to change LinuxBIOS CMOS settings from OFW<br /> * For LinuxBIOSv3, the start address of the payload can be variable. This is a fundamental change to v2, and will make life a lot easier and LinuxBIOS a lot more flexible. OFW requires to know its in-rom address at build time. This needs to be fixed to a dynamic behavior<br /> * Also, there's no good documentation on what features can be used and how they can be used. Like the graphical OLPC menu, the built-in web server.<br /> * Get a STOP-A like behavior working in Linux<br /> * Get Smart Firmware working with new compilers<br /> * Get Smart Firmware working as a payload<br /> * Enhance the [[Distributed and Automated Testsystem]] to work with FILO and OpenFirmware payloads, and add The Hayes ANS Forth testsuite.<br /> <br /> Some parts might require cooperation with other GSoC projects:<br /> <br /> * Boot from Non-OFW SCSI controllers by running their int13 handler<br /> * Boot Windows XP/2003/Vista in OFW<br /> <br /> This project might benefit from Forth skills.<br /> <br /> == GNUFI or TianoCore payloads ==<br /> <br /> There are two open source EFI implementations out there. [http://gnufi.blogspot.com/ GNUFI] (or [http://www.hermann-uwe.de/blog/gnufi-the-gnu-firmware-implementation here] or [http://www.gnu.org/software/gnufi/ here]) and [http://www.tianocore.org/ TianoCore]. Try getting those to work as LinuxBIOS payloads, or change LinuxBIOS so it can load them as payloads.<br /> <br /> This project requires no hardware skills, but especially in case of TianoCore might require knowledge of Windows compilers (VC2005?)<br /> <br /> == Boot OpenSolaris, FreeBSD, NetBSD, OpenBSD or other free OSes ==<br /> <br /> LinuxBIOS has (despite its name) been a little Linux centric. A nice project would be to analyze what it takes to get OpenSolaris, the BSDs or other free operating systems to work in LinuxBIOS, without the need for legacy emulation (ie. no [[ADLO]])<br /> <br /> == Improve Linux as a BIOS [http://linuxbios.org/Build_LinuxBIOS_using_LBdistro]==<br /> <br /> There's a small project called [http://www.linuxbios.org/viewvc/?root=buildrom buildrom] which creates a payload from a Linux kernel and some user space utilities. It has been written to work with the OLPC. This project could be enhanced to work on all supported LinuxBIOS motherboards.<br /> <br /> == Porting Flashrom utility to Windows 2000/XP ==<br /> <br /> Flashrom is used to burn LinuxBIOS binary to flash chips in the target motherboards. It runs on Unix/Linux. In this project the flashrom utility is ported from Linux/Unix to Windows 2000/XP. The Windows port is called Winflashrom. The project is divided into two tasks. The first task is to port most of the user space flashrom source code to MinGW and the second task is to code a Windows device driver to provide direct hardware access for the user space code. The difficulty of this task is in providing a reliable Windows device driver for the user space code.</div>

Rminnich http://www.coreboot.org/Welcome_to_coreboot 2007-10-03T22:22:04Z

<p>Rminnich: Remove OLPC reference</p> <hr /> <div>&lt;table width=&quot;100%&quot; valign=&quot;top&quot;&gt;&lt;tr valign=&quot;top&quot;&gt;&lt;td width=&quot;80%&quot;&gt;<br /> <br /> &lt;div style=&quot;margin-top:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;&quot;&gt;<br /> '''LinuxBIOS''' is a Free Software project aimed at replacing the proprietary BIOS (firmware) you can find in most of today's computers.<br /> <br /> It performs just a little bit of hardware initialization and then executes a so-called [[Payloads|payload]], for example a [[Linux]] kernel, [[FILO]], [[GRUB2]], [http://www.openbios.org/ OpenBIOS], [http://www.openbios.org/Open_Firmware Open Firmware], [http://www.openbios.org/SmartFirmware SmartFirmware], [http://www.gnu.org/software/gnufi/ GNUFI] (UEFI), [[Etherboot]], [[ADLO]] (for [[Booting Windows using LinuxBIOS|booting Windows]] and [http://openbsd.org/ OpenBSD]), [[Plan 9]], or [[memtest86]].<br /> &lt;/div&gt;<br /> {| cellspacing=5 cellpadding=5 border=0 valign=&quot;top&quot; width=100%<br /> |-<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps;&quot;&gt;[[Benefits]]&lt;/span&gt;''' &amp;mdash;<br /> &lt;small&gt;There are many reasons for using LinuxBIOS.&lt;/small&gt;<br /> &lt;hr /&gt;<br /> * 100% Free Software (GPL), no royalties, no license fees!<br /> * Fast boot times (3 seconds from power-on to Linux console)<br /> * Avoids the need for a slow, buggy, proprietary BIOS<br /> * Runs in 32-Bit protected mode almost from the start<br /> * Written in C, contains virtually no assembly code<br /> * Supports a wide variety of [[Supported Chipsets and Devices|hardware]] and [[payloads]]<br /> * Further features: netboot, serial console, remote flashing, ...<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps;&quot;&gt;[[Use Cases]]&lt;/span&gt;''' &amp;mdash;<br /> &lt;small&gt;LinuxBIOS can be deployed in a wide range of scenarios.&lt;/small&gt;<br /> &lt;hr /&gt;<br /> * Standard desktop computers and servers<br /> * [[Clusters]], high-performance computing<br /> * Embedded solutions, appliances, terminals<br /> * [http://en.wikipedia.org/wiki/Small_form_factor Small form factor computers], [http://en.wikipedia.org/wiki/Home_theater_PC Home-theater PCs] (HTPC)<br /> * No-moving-parts solutions (ROM chip as &quot;hard drive&quot;)<br /> * Various non-standard scenarios (e.g. FPGA in Opteron socket)<br /> |}<br /> &lt;hr /&gt;<br /> {| cellspacing=5 cellpadding=5 border=0 valign=&quot;top&quot; width=100%<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_lb.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''About'''&lt;br /&gt;&lt;small&gt;Find out more about LinuxBIOS.&lt;hr /&gt;[[News]] | [[Press]] | [[History]] | [[Screenshots|Screenshots &amp; Videos]] | [[Contributors]] | [[Sponsors]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_devel.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Developers'''&lt;br /&gt;&lt;small&gt;Get involved! Help us make LinuxBIOS better.&lt;hr /&gt;[[Development Guidelines]] | [[Developer Manual]] | [http://qa.linuxbios.org/docs/doxygen.php Doxygen] | [http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv2 Browse Source] | [[JTAG/BSDL Guide|JTAG]] | [[EHCI Debug Port]] | [[Distributed and Automated Testsystem|Testsystem]] | [[GSoC]] | [[Ideas]] | [[Superiotool]]&lt;/small&gt;<br /> |}<br /> <br /> |-<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_status.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Status'''&lt;br /&gt;&lt;small&gt;Find out whether your hardware is already supported.&lt;hr /&gt;[[Supported Motherboards]] | [[Supported Chipsets and Devices|Supported Chipsets &amp; Devices]] | [http://qa.linuxbios.org Build Status] | [[Flashrom#Supported_devices|Flashrom support]] | [[Superiotool#Supported_devices|Superiotool support]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_vendors.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Vendors &amp; Products'''&lt;br /&gt;&lt;small&gt;Find out in which products LinuxBIOS is used.&lt;hr /&gt;[[Products]] | [[Clusters]] | [[Laptop]] | [[Desktops]]&lt;/small&gt;<br /> |}<br /> <br /> |-<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_101.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Getting Started'''&lt;br /&gt;&lt;small&gt;Download LinuxBIOS and get started.&lt;hr /&gt;[[Download LinuxBIOS|Downloads]] | [[Documentation]] | [[Documentation#How-To.27s|Build Tutorials]] | [[Payloads]] | [[QEMU]] | [[Confirmed working svn revisions|Confirmed Working SVN Revisions]] | [[Buildrom]] | [[Flashrom]] | [[Misc]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_support.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''Support'''&lt;br /&gt;&lt;small&gt;Learn how to contact us and find help and support.&lt;hr /&gt;[[FAQ]] | [[Mailinglist]] | [[IRC]] | [http://tracker.linuxbios.org/trac/LinuxBIOS/ Issue Tracker] | [[Glossary]] | [[LinuxBIOS Options|LinuxBIOSv2 Options]]&lt;/small&gt;<br /> |}<br /> <br /> |}<br /> &lt;/td&gt;&lt;td width=&quot;20%&quot;&gt;<br /> <br /> [[Image:Msi_ms7260_k9n_neo.jpg|thumb|The latest supported board, the MSI [[MSI MS-7260 Build Tutorial|MS-7260 (K9N Neo)]].]]<br /> &lt;br clear=all /&gt;<br /> <br /> '''&lt;span style=&quot;font-variant:small-caps;&quot;&gt;[[News]]&lt;/span&gt;'''&lt;hr /&gt;<br /> &lt;small&gt;<br /> * '''2007/09/22:''' [[News#2007.2F09.2F22_MSI_MS-7260_now_supported|MSI MS-7260 support]]<br /> * '''2007/09/13:''' [[News#2007.2F09.2F13_MSI_MS-6178_now_supported|MSI MS-6178 support]]<br /> * '''2007/09/08:''' [[News#2007.2F09.2F08_PC_Engines_ALIX1.C_now_supported|PC Engines ALIX1.C support]]<br /> * '''2007/06/14:''' [[News#2007.2F06.2F14_Intel_810_chipset_and_ASUS_MEW-VM_now_supported|Intel 810 &amp;amp; ASUS MEW-VM support]]<br /> * '''2007/06/13:''' [[News#2007.2F06.2F13_AMD_DB800_.28Salsa.29_now_supported|AMD DB800 support]]<br /> * '''2007/06/07:''' [[News#2007.2F06.2F07_IEI_JUKI-511P_and_ROCKY-512_now_supported|IEI JUKI-511P &amp;amp; ROCKY-512 support]]<br /> * '''2007/05/24:''' [[News#2007.2F05.2F24_ASUS_A8N-E_now_supported|ASUS A8N-E support]]<br /> &lt;/small&gt;<br /> <br /> '''&lt;span style=&quot;font-variant:small-caps;&quot;&gt;Contact&lt;/span&gt;'''&lt;hr /&gt;<br /> &lt;small&gt;<br /> * [[Mailinglist|Mailing list]]: [mailto:linuxbios@linuxbios.org linuxbios@linuxbios.org]<br /> * [[IRC]]: '''#linuxbios''' (on [http://www.freenode.net/ irc.freenode.net])<br /> &lt;/small&gt;<br /> <br /> &lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;<br /> __NOTOC__<br /> __NOEDITSECTION__</div>

Rminnich http://www.coreboot.org/Products 2007-09-25T23:15:17Z

<p>Rminnich: </p> <hr /> <div>Here's a list of vendors and their products running LinuxBIOS. Please [[Mailinglist|contact us]] if you wish to add your product to the following list. <br /> <br /> == Artec Group ==<br /> <br /> [http://www.artecgroup.com Artec Group] runs LinuxBIOS on their Geode LX based [http://www.thincan.com DBE61 ThinCan] system.<br /> <br /> == Cluster Labs ==<br /> [http://www.cluster-labs.com/ Cluster Labs] sells a 1.1 GHz PIII cluster node with 1 GB memory, fast ethernet, and boots LinuxBIOS. <br /> <br /> == coresystems GmbH ==<br /> [http://www.coresystems.de/ coresystems GmbH] is offering LinuxBIOS based services and products. As a LinuxBIOS contributor, coresystems is hosting the LinuxBIOS development repository and web page.<br /> <br /> == Cray ==<br /> The Cray [http://www.cray.com/products/xd1/ Xd1] is an Opteron-based system which runs LinuxBIOS. <br /> <br /> == CW Linux == <br /> [http://www.cwlinux.com CW Linux] offers pre-installed LinuxBIOS motherboards, SDK and related hardware for people want to use or develop applications on LinuxBIOS. It also provides professional services for custom LinuxBIOS-based system development. <br /> <br /> == i-TECH Corp. ==<br /> [http://www.i-tech.com/ i-TECH] is selling test and analysis tools with LinuxBIOS, including all its &quot;Satellite&quot; Fibre Channel analyzers (IFC-3016, IFC-4016, IFC-30, IFC40) and &quot;PassPort&quot;-based test and analysis tools. <br /> <br /> == Linutop ==<br /> [http://linutop.com/ Linutop] is shipping LinuxBIOS on their diskless computers.<br /> <br /> == Linux Labs ==<br /> [http://www.linuxlabs.com Linux Labs] is selling [http://www.linuxlabs.com/starterclusters.html LinuxBIOS Beowulf clusters] comprised of 1U x86-based nodes with LinuxBIOS installed. <br /> <br /> == Linux NetworX == <br /> [http://www.linuxnetworx.com Linux NetworX], a major contributor to the LinuxBIOS project, sells a variety of cluster solutions with LinuxBIOS installed. <br /> <br /> == MikroTik ==<br /> [http://www.routerboard.com MikroTik] is offering the [http://216.239.59.104/search?q=cache:pT2IZCrEZEsJ:www.routerboard.com/pdf/RouterBOARD200SeriesA4-3-0.pdf+routerboard+linuxbios&amp;hl=de&amp;ct=clnk&amp;cd=1&amp;gl=de Routerboard 200 series] which seems to be shipped with LinuxBIOS (devices from other Routerboard series might use LinuxBIOS, too).<br /> <br /> == O.N.E. Technologies ==<br /> [http://www.onelabs.com/ O.N.E. Technologies] offers LinuxBIOS on all their x86 products.<br /> <br /> __NOTOC__</div>

Rminnich http://www.coreboot.org/Welcome_to_coreboot 2005-11-21T04:26:16Z

<p>Rminnich: /* Welcome to the LinuxBIOS homepage */</p> <hr /> <div>= Welcome to the LinuxBIOS homepage =<br /> <br /> LinuxBIOS Summit was Oct. 11-13, Santa Fe, New Mexico, USA. See [[Current events]] for more information or the [http://www.linuxbios.org/data/LB_Summit.pdf agenda]. <br /> <br /> LinuxBIOS is a Free Software project aimed at replacing the normal BIOS with a little bit of hardware initialization and a compressed Linux kernel that can be booted from a cold start. The project was started as part of clustering research work in the Cluster Reseach Lab at the Advanced Computing Laboratory at Los Alamos National Laboratory. The primary motivation behind the project was the desire to have the operating system gain control of a cluster node from power on. Other beneficial consequences of using LinuxBIOS include needing only two working motors to boot (cpu fan and power supply), fast boot times (current fastest is 3 seconds), and freedom from proprietary (buggy) BIOS code, to name a few. These secondary benefits are numerous and have helped gain support from many vendors in both the high performance computing as well as embedded computing markets.<br /> <br /> Note that, on newer systems, there need be no moving parts at all. At LANL, we are building a new 'no moving parts' 16-node cluster to demonstrate this capability. The cluster will fit in a toolbox, run from a battery, boot in 10 seconds, and be controlled from your laptop (which, sadly, will still have a few moving parts).<br /> <br /> * [[Download LinuxBIOS]] (Download LinuxBIOS v2 and older versions)<br /> * [https://openbios.org/roundup/linuxbios/ LinuxBIOS Issue Tracker] (See current LinuxBIOS issues and status)<br /> * [[FAQ]] (Frequently Asked Questions)<br /> * [[Supported Motherboards]]<br /> * [[Supported Chipsets &amp; Devices]]<br /> * [[Documentation]]<br /> * [[Payloads]]<br /> * [http://www.linuxbios.org/data/Options.html Configuration Options]<br /> * [[Port Guides]] <br /> * [[News]]<br /> * [[Mailinglist]]<br /> * [[Contributors]]<br /> * [[Products]]<br /> * [[Press]]<br /> * [[Clusters]]<br /> * [[Misc]]<br /> * [[Laptop]]</div>

Rminnich http://www.coreboot.org/File:Homework.pdf 2005-10-17T01:14:25Z

<p>Rminnich: These are the homework assignments</p> <hr /> <div>These are the homework assignments</div>

Rminnich http://www.coreboot.org/File:Openefi.pdf 2005-10-17T01:12:28Z

<p>Rminnich: Ron's proposal to create a truly open EFI, assuming we care about EFI enough to do this.</p> <hr /> <div>Ron's proposal to create a truly open EFI, assuming we care about EFI enough to do this.</div>

Rminnich http://www.coreboot.org/File:The_real_linuxbios.pdf 2005-10-17T01:02:45Z

<p>Rminnich: This is Ron's crazy idea for using Linux as the BIOS.</p> <hr /> <div>This is Ron's crazy idea for using Linux as the BIOS.</div>

Rminnich http://www.coreboot.org/Welcome_to_coreboot 2005-09-27T21:00:11Z

<p>Rminnich: </p> <hr /> <div>= Welcome to the LinuxBIOS homepage =<br /> <br /> LinuxBIOS Summit Oct. 11-13, Santa Fe, New Mexico, USA. See [[Current events]] for information. Richard Bruner, AMD Fellow, will be a featured speaker. We have a number of interesting speakers lined up, and will be describing new developments, such as the use of Linux Kconfig for LinuxBIOS configuration. Hope too see you there!<br /> <br /> Here's his talk:<br /> <br /> This should whet your appetite for the 3-day linuxbios summit Oct. 11, 2005 in santa fe!<br /> <br /> For more information, http://lacsi.rice.edu/symposium/<br /> <br /> <br /> Title: AMD's Roadmap for Free Firmware (as in Beer)<br /> <br /> Speaker: Rich Brunner, AMD Fellow<br /> <br /> Abstract: This will be a discussion of the upcoming AMD Processor<br /> roadmap, AMD plans for supporting LinuxBIOS, and AMD's<br /> directions for the future of firmware.<br /> <br /> Speaker BIO:<br /> <br /> Richard A. Brunner is the Software Architect for Advanced Micro<br /> Devices' AMD64 Architecture. He is an AMD fellow and is responsible<br /> for driving the technical direction of AMD's AMD64 software strategy<br /> for operating systems, device drivers, compilers, libraries, OS/firmware<br /> interaction, performance optimizations, and 3rd party tools. Richard<br /> led AMD's initial involvement into the Unified Extensible Firmware<br /> Interface (UEFI) forum.<br /> <br /> Richard holds a Masters of Science degree in Computer Engineering from<br /> Rensselaer Polytechnic Institute and a Bachelor of Science degree in<br /> Electrical Engineering from Case Western Reserve University. He holds<br /> patents in computer architecture and has presented<br /> extensively including Hot Chips, Siggraph, WinHec,<br /> Linux Kernel Summit, Linux World, Ottawa Linux Symposium.<br /> <br /> <br /> LinuxBIOS is a Free Software project aimed at replacing the normal BIOS with a little bit of hardware initialization and a compressed Linux kernel that can be booted from a cold start. The project was started as part of clustering research work in the Cluster Reseach Lab at the Advanced Computing Laboratory at Los Alamos National Laboratory. The primary motivation behind the project was the desire to have the operating system gain control of a cluster node from power on. Other beneficial consequences of using LinuxBIOS include needing only two working motors to boot (cpu fan and power supply), fast boot times (current fastest is 3 seconds), and freedom from proprietary (buggy) BIOS code, to name a few. These secondary benefits are numerous and have helped gain support from many vendors in both the high performance computing as well as embedded computing markets.<br /> <br /> Note that, on newer systems, there need be no moving parts at all. At LANL, we are building a new 'no moving parts' 16-node cluster to demonstrate this capability. The cluster will fit in a toolbox, run from a battery, boot in 10 seconds, and be controlled from your laptop (which, sadly, will still have a few moving parts).<br /> <br /> * [[Download LinuxBIOS]] (Download LinuxBIOS v2 and older versions)<br /> * [[FAQ]] (Frequently Asked Questions)<br /> * [[Supported Motherboards]]<br /> * [[Supported Chipsets &amp; Devices]]<br /> * [[Documentation]]<br /> * [[Payloads]]<br /> * [http://www.linuxbios.org/data/Options.html Configuration Options]<br /> * [[Port Guides]] <br /> * [[News]]<br /> * [[Mailinglist]]<br /> * [[Contributors]]<br /> * [[Products]]<br /> * [[Press]]<br /> * [[Clusters]]<br /> * [[Misc]]<br /> * [[Laptop]]</div>

Rminnich http://www.coreboot.org/Welcome_to_coreboot 2005-09-07T19:20:55Z

<p>Rminnich: </p> <hr /> <div>= Welcome to the LinuxBIOS homepage =<br /> <br /> LinuxBIOS Summit Oct. 11-13, Santa Fe, New Mexico, USA. See http://lacsi.rice.edu/symposium/ for information. Richard Bruner, AMD Fellow, will be a featured speaker. We have a number of interesting speakers lined up, and will be describing new developments, such as the use of Linux Kconfig for LinuxBIOS configuration. Hope too see you there!<br /> <br /> LinuxBIOS is a Free Software project aimed at replacing the normal BIOS with a little bit of hardware initialization and a compressed Linux kernel that can be booted from a cold start. The project was started as part of clustering research work in the Cluster Reseach Lab at the Advanced Computing Laboratory at Los Alamos National Laboratory. The primary motivation behind the project was the desire to have the operating system gain control of a cluster node from power on. Other beneficial consequences of using LinuxBIOS include needing only two working motors to boot (cpu fan and power supply), fast boot times (current fastest is 3 seconds), and freedom from proprietary (buggy) BIOS code, to name a few. These secondary benefits are numerous and have helped gain support from many vendors in both the high performance computing as well as embedded computing markets.<br /> <br /> Note that, on newer systems, there need be no moving parts at all. At LANL, we are building a new 'no moving parts' 16-node cluster to demonstrate this capability. The cluster will fit in a toolbox, run from a battery, boot in 10 seconds, and be controlled from your laptop (which, sadly, will still have a few moving parts).<br /> <br /> * [[Download LinuxBIOS]] (Download LinuxBIOS v2 and older versions)<br /> * [[FAQ]] (Frequently Asked Questions)<br /> * [[Supported Motherboards]]<br /> * [[Supported Chipsets &amp; Devices]]<br /> * [[Documentation]]<br /> * [[Payloads]]<br /> * [http://www.linuxbios.org/data/Options.html Configuration Options]<br /> * [[Port Guides]] <br /> * [[News]]<br /> * [[Mailinglist]]<br /> * [[Contributors]]<br /> * [[Products]]<br /> * [[Press]]<br /> * [[Clusters]]<br /> * [[Misc]]<br /> * [[Laptop]]</div>

Rminnich http://www.coreboot.org/News 2005-04-25T02:18:32Z

<p>Rminnich: </p> <hr /> <div>== ''2005/04/22'' How Many People Are Using LinuxBIOS? Would you believe 1,000,000? ==<br /> <br /> This question comes up to us all the time. Last week, I got an amazing answer. First, let<br /> me mention that I tell skeptical people at vendors all the time, when <br /> asked this question: &quot;A lot more than just the <br /> cluster community. The real use is in the embedded world&quot;. Well, again, last week, <br /> I found out just how real that use is. <br /> <br /> The system in question is the STPC Consumer. Evidently, this chipset is used in <br /> an internet terminal sold in India. It runs LinuxBIOS and Linux. <br /> <br /> There are at least one MILLION (1,000,000) of these things in use. I realize that is not much compared to the size of some markets, but had you told me six years ago that <br /> one million systems would be using LinuxBIOS in 2005, I don't think I would have believed you.<br /> <br /> --Ron<br /> <br /> == ''2005/03/01'' LinuxBIOS Wiki up and running ==<br /> <br /> After a week of testing and playing around, LinuxBIOS has a brand new Wiki now.<br /> <br /> <br /> == ''2005/02/28'' LinuxBIOS slashdotted again. ==<br /> After Richard Stallman's call for support of free BIOS LinuxBIOS was slashdotted this weekend.</div>

Rminnich http://www.coreboot.org/Products 2005-03-25T03:38:33Z

<p>Rminnich: </p> <hr /> <div>Here's a list of vendors and their products running LinuxBIOS. Please contact us if you wish to add your product to the following list. <br /> <br /> <br /> == Cluster Labs ==<br /> [http://www.cluster-labs.com/ Cluster Labs] sells a 1.1 GHZ PIII cluster node with 1 GB memory, fast ethernet, and boots LinuxBIOS. <br /> <br /> == Cray ==<br /> The Cray [http://www.cray.com/products/xd1/ Xd1] is an Opteron-based system which runs LinuxBIOS . <br /> <br /> <br /> == CW Linux == <br /> [http://www.cwlinux.com CW Linux] offers pre-installed LinuxBIOS motherboards, SDK and related hardware for people want to use or develope applications on LinuxBIOS. It also provides professional services for custom LinuxBIOS-based system development. <br /> <br /> <br /> == i-TECH Corp. ==<br /> [http://www.i-tech.com/ i-TECH] is selling test and analysis tools with LinuxBIOS, including all its &quot;Satellite&quot; Fibre Channel analyzers (IFC-3016, IFC-4016, IFC-30, IFC40) and &quot;PassPort&quot;-based test and analysis tools. <br /> <br /> <br /> == Linux Labs ==<br /> [http://www.linuxlabs.com Linux Labs] is selling [http://www.linuxlabs.com/starterclusters.html LinuxBIOS Beowulf clusters] comprised of 1U x86-based nodes with LinuxBIOS installed. <br /> <br /> <br /> == Linux NetworX == <br /> [http://www.linuxnetworx.com Linux NetworX], a major contributor to the LinuxBIOS project, sells a variety of cluster solutions with LinuxBIOS installed. <br /> <br /> <br /> == O.N.E. Technologies ==<br /> [http://www.onelabs.com/ O.N.E. Technologies] offers LinuxBIOS on all their x86 products.<br /> <br /> <br /> == Orion Multisystems ==<br /> [http://www.orionmulti.com// Orion Multisystems] builds &quot;personal supercomputers&quot; based on the TransMeta Efficeon process that run LinuxBIOS. .<br /> <br /> <br /> == Tyan Computer ==<br /> [http://www.tyan.com/ Tyan] offers LinuxBIOS on all their Opteron based products.</div>

Rminnich http://www.coreboot.org/Products 2005-03-25T03:37:59Z

<p>Rminnich: </p> <hr /> <div>Here's a list of vendors and their products running LinuxBIOS. Please contact us if you wish to add your product to the following list. <br /> <br /> <br /> == Cluster Labs ==<br /> [http://www.cluster-labs.com/ Cluster Labs] sells a 1.1 GHZ PIII cluster node with 1 GB memory, fast ethernet, and boots LinuxBIOS. <br /> <br /> == Cray ==<br /> The Cray [http://www.cray.com/products/xd1/ Xd1] is an Opteron-based system which runs LinuxBIOS . <br /> <br /> == CW Linux == <br /> [http://www.cwlinux.com CW Linux] offers pre-installed LinuxBIOS motherboards, SDK and related hardware for people want to use or develope applications on LinuxBIOS. It also provides professional services for custom LinuxBIOS-based system development. <br /> <br /> <br /> == i-TECH Corp. ==<br /> [http://www.i-tech.com/ i-TECH] is selling test and analysis tools with LinuxBIOS, including all its &quot;Satellite&quot; Fibre Channel analyzers (IFC-3016, IFC-4016, IFC-30, IFC40) and &quot;PassPort&quot;-based test and analysis tools. <br /> <br /> <br /> == Linux Labs ==<br /> [http://www.linuxlabs.com Linux Labs] is selling [http://www.linuxlabs.com/starterclusters.html LinuxBIOS Beowulf clusters] comprised of 1U x86-based nodes with LinuxBIOS installed. <br /> <br /> <br /> == Linux NetworX == <br /> [http://www.linuxnetworx.com Linux NetworX], a major contributor to the LinuxBIOS project, sells a variety of cluster solutions with LinuxBIOS installed. <br /> <br /> <br /> == O.N.E. Technologies ==<br /> [http://www.onelabs.com/ O.N.E. Technologies] offers LinuxBIOS on all their x86 products.<br /> <br /> == Orion Multisystems ==<br /> [http://www.orionmulti.com// Orion Multisystems] builds &quot;personal supercomputers&quot; based on the TransMeta Efficeon process that run LinuxBIOS. .<br /> <br /> <br /> <br /> == Tyan Computer ==<br /> [http://www.tyan.com/ Tyan] offers LinuxBIOS on all their Opteron based products.</div>

Rminnich http://www.coreboot.org/Products 2005-03-25T03:35:08Z

<p>Rminnich: </p> <hr /> <div>Here's a list of vendors and their products running LinuxBIOS. Please contact us if you wish to add your product to the following list. <br /> <br /> <br /> == Cluster Labs ==<br /> [http://www.cluster-labs.com/ Cluster Labs] sells a 1.1 GHZ PIII cluster node with 1 GB memory, fast ethernet, and boots LinuxBIOS. <br /> <br /> == Cray ==<br /> The Cray [http://www.cray.com/products/xd1/ Xd1] is an Opteron-based system which runs LinuxBIOS . <br /> <br /> == CW Linux == <br /> [http://www.cwlinux.com CW Linux] offers pre-installed LinuxBIOS motherboards, SDK and related hardware for people want to use or develope applications on LinuxBIOS. It also provides professional services for custom LinuxBIOS-based system development. <br /> <br /> <br /> == i-TECH Corp. ==<br /> [http://www.i-tech.com/ i-TECH] is selling test and analysis tools with LinuxBIOS, including all its &quot;Satellite&quot; Fibre Channel analyzers (IFC-3016, IFC-4016, IFC-30, IFC40) and &quot;PassPort&quot;-based test and analysis tools. <br /> <br /> <br /> == Linux Labs ==<br /> [http://www.linuxlabs.com Linux Labs] is selling [http://www.linuxlabs.com/starterclusters.html LinuxBIOS Beowulf clusters] comprised of 1U x86-based nodes with LinuxBIOS installed. <br /> <br /> <br /> == Linux NetworX == <br /> [http://www.linuxnetworx.com Linux NetworX], a major contributor to the LinuxBIOS project, sells a variety of cluster solutions with LinuxBIOS installed. <br /> <br /> <br /> == O.N.E. Technologies ==<br /> [http://www.onelabs.com/ O.N.E. Technologies] offers LinuxBIOS on all their x86 products.<br /> <br /> <br /> == Tyan Computer ==<br /> [http://www.tyan.com/ Tyan] offers LinuxBIOS on all their Opteron based products.</div>

Rminnich http://www.coreboot.org/Download_coreboot 2005-03-22T15:11:48Z

<p>Rminnich: /* GNU Arch Repository */</p> <hr /> <div>= GNU Arch Repository =<br /> <br /> There is an experimental [http://www.gnuarch.org/ GNU arch] tree available which is likely to become the main repository soon. You may need to install arch. You can find a tar at ftp://ftp.gnu.org/pub/gnu/gnu-arch/. <br /> <br /> == Anonymous access ==<br /> <br /> You can check it out as follows (instead of tla you can also use baz):<br /> <br /> &lt;code&gt;&lt;pre&gt;<br /> % # get gpg key for checking signed archives<br /> % wget \<br /> http://wiki.linuxbios.org/data/arch/linuxbios-developers-keyring.gpg<br /> % gpg --import &lt; linuxbios-developers-keyring.gpg<br /> % # now do some one time registrations<br /> % tla my-id &quot;John Doe &lt;doe@example.com&gt;&quot; # Add your email address here<br /> % tla register-archive \<br /> ftp://openbios.org/pub/arch/linuxbios@linuxbios.org--devel<br /> % # now check out the archive<br /> % tla get linuxbios@linuxbios.org--devel/freebios--devel--2.0 freebios2<br /> &lt;/pre&gt;&lt;/code&gt;<br /> <br /> == Developer Access ==<br /> <br /> === Prerequisites ===<br /> If you want to get write access to the LinuxBIOS repository, you need the following:<br /> <br /> * GnuPG key (can be created with gpg --gen-key)<br /> * SSH v2 key (can be created with ssh-keygen -t dsa)<br /> <br /> === Preparation ===<br /> <br /> * Get the arch key I created for the import from CVS.<br /> <br /> $ wget 'http://wiki.linuxbios.org/data/arch/linuxbios-developers-keyring.gpg'<br /> $ gpg --import linuxbios-developers-keyring.gpg<br /> <br /> * Prepare GNU arch for LinuxBIOS<br /> <br /> # Set your default id:<br /> $ tla my-id &quot;John Doe &lt;doe@example.com&gt;&quot;<br /> <br /> # similar to cvs login, tell gnuarch where to find the archive:<br /> $ tla register-archive sftp://lxbios@openbios.org/srv/arch/linuxbios@linuxbios.org--devel<br /> <br /> # prepare gnupg signature checking:<br /> $ mkdir -p ~/.arch-params/signing<br /> $ echo &quot;gpg --clearsign&quot; &gt; ~/.arch-params/signing/\=default<br /> $ echo &quot;gpg --verify-files -&quot; &gt; ~/.arch-params/signing/\=default.check<br /> <br /> === Check out ===<br /> <br /> $ tla get linuxbios@linuxbios.org--devel/freebios--devel--2.0 freebios2<br /> <br /> === Working on the tree ===<br /> <br /> Now you can start editing the files. The following applies for symlinks and directories as well.<br /> <br /> * New files are added with<br /> $ tla add filename<br /> <br /> * files can also be renamed using:<br /> $ tla mv fileA fileB<br /> <br /> * files can also be renamed using:<br /> $ tla mv fileA fileB<br /> <br /> * files can be deleted:<br /> $ tla rm file<br /> <br /> When you're done editing/patching:<br /> <br /> * Look at your changes:<br /> $ tla changes<br /> or<br /> $ tla changes --diffs<br /> <br /> * Check the tree:<br /> <br /> You can do consistency checks on your tree with:<br /> $ tla tree-lint<br /> $ tla inventory -Bu<br /> <br /> Check if your tree is current:<br /> $ tla missing<br /> <br /> This will output a list of missing changesets in your local tree, ie:<br /> <br /> patch-15<br /> patch-16<br /> patch-17<br /> patch-18<br /> <br /> In which case you should do a<br /> $ tla update<br /> before you commit.<br /> <br /> === Commiting ===<br /> <br /> Write a changelog. PLEASE DO NOT CREATE EMPTY CHANGELOG MESSAGES:<br /> $ $EDITOR $( tla make-log )<br /> <br /> Commit your local tree<br /> $ tla commit<br /> <br /> This will ask you for your gpg passphrase (and possibly your ssh key<br /> password if you set one). Then it will create a new revision in the<br /> repository.<br /> <br /> == Source code browsing ==<br /> <br /> You can also [http://www.openbios.org/cgi-bin/viewarch.cgi/linuxbios@linuxbios.org--devel browse the LinuxBIOS arch repository online].<br /> <br /> == Snapshots ==<br /> <br /> To be done<br /> <br /> == Source code browsing ==<br /> <br /> http://www.openbios.org/cgi-bin/viewarch.cgi<br /> <br /> == Mirroring the repository ==<br /> <br /> This is very simple. Do:<br /> <br /> wget -m ftp://ftp.openbios.org/pub/arch<br /> <br /> Which gives you a snapshot in time of the archive.<br /> To create a mirror usable by arch:<br /> <br /> tla register-archive linuxbios@linxubios.org--devel-SOURCE ftp://openbios.org/pub/arch/linuxbios@linuxbios.org--devel <br /> tla register-archive linuxbios@linuxbios.org--devel ~/{archives}/linuxbios@linuxbios.org--devel<br /> <br /> echo gpg --clearsign &gt; ~/.arch-params/signing/=default<br /> echo gpg --verify-files - &gt; ~/.arch-params/signing/=default.check<br /> echo linuxbios@linuxbios.org--devel--SOURCE &gt; ~/.arch-params/signing/linuxbios@linuxbios.org--devel<br /> <br /> To update the mirror with the most recent contents:<br /> tla archive-mirror linuxbios@linuxbios.org --devel<br /> <br /> Just don't do this in an account where you plan to commit to the upstream<br /> archive.<br /> <br /> == Creating a branch you can edit in local archive ==<br /> <br /> tla tag -S linuxbios@linuxbios.org--devel/freebios--devel--2.0 you@yourarchive/freebios--devel--2.0<br /> <br /> == More on tla ==<br /> <br /> * http://www.openbios.org/experience/gnuarch.html<br /> * http://wiki.gnuarch.org/<br /> <br /> = CVS Repository (obsolete) =<br /> <br /> The CVS repository is maintained at SourceForge.net (project name &quot;FreeBIOS&quot;). A daily snapshot of the entire source tree is created nightly. <br /> <br /> * [http://cvs.sourceforge.net/cvstarballs/freebios-cvsroot.tar.bz2 Download latest daily snapshot from CVS]<br /> <br /> <br /> Or, to use CVS directly: <br /> <br /> &lt;code&gt;% cvs -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios login&lt;/code&gt;<br /> <br /> Hit return when it asks you for a password (no password needed). Then checkout (or update) the freebios2 source tree: <br /> <br /> &lt;code&gt;% cvs -z3 -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios co freebios2&lt;/code&gt;<br /> <br /> <br /> == Snapshots ==<br /> <br /> There is an archive of daily snapshots available at snapshots.linuxbios.org. There is a .bz2 tar file that gets updated when the CVS changes. Older snapshots are maintained as well. <br /> <br /> * [http://snapshots.linuxbios.org/ Download snapshots]<br /> <br /> == Source code browsing ==<br /> <br /> You can also browse the CVS source tree directly using the link below.<br /> <br /> * [http://cvs.sourceforge.net/viewcvs.py/freebios/ Browse CVS source code tree]</div>

Rminnich http://www.coreboot.org/Welcome_to_coreboot 2005-03-22T04:18:40Z

<p>Rminnich: </p> <hr /> <div>Welcome to the LinuxBIOS Wiki.<br /> <br /> LinuxBIOS is a Free Software project aimed at replacing the normal BIOS with a little bit of hardware initialization and a compressed Linux kernel that can be booted from a cold start. The project was started as part of clustering research work in the Cluster Reseach Lab at the Advanced Computing Laboratory at Los Alamos National Laboratory. The primary motivation behind the project was the desire to have the operating system gain control of a cluster node from power on. Other beneficial consequences of using LinuxBIOS include needing only two working motors to boot (cpu fan and power supply), fast boot times (current fastest is 3 seconds), and freedom from proprietary (buggy) BIOS code, to name a few. These secondary benefits are numerous and have helped gain support from many vendors in both the high performance computing as well as embedded computing markets.<br /> <br /> Note that, on newer systems, there need be no moving parts at all. At LANL, we are building a new 'no moving parts' 16-node cluster to demonstrate this capability. The cluster will fit in a toolbox, run from a battery, boot in 10 seconds, and be controlled from your laptop (which, sadly, will still have a few moving parts).<br /> <br /> * [[Download freebios v2]]<br /> <br /> * [[FAQ]]<br /> <br /> * [[Supported Motherboards]] (was [[MB supported in freebios v2]])<br /> <br /> * [[Documentation]]<br /> <br /> * [[Payloads]]<br /> <br /> * [http://wiki.linuxbios.org/data/Options.html Configuration Options]<br /> <br /> * [[Port Guides]] <br /> <br /> * [[News]]<br /> <br /> * [[Mailinglist]]<br /> <br /> * [[Contributors]]<br /> <br /> * [[Products]]<br /> <br /> * [[Press]]<br /> <br /> * [[Clusters]]<br /> <br /> * [[Misc]]</div>

Rminnich http://www.coreboot.org/FAQ 2005-03-09T18:18:19Z

<p>Rminnich: /* Which different operating systems will LinuxBIOS boot? */</p> <hr /> <div>== General ==<br /> <br /> === What is LinuxBIOS? ===<br /> <br /> LinuxBIOS aims to replace the normal BIOS found on PCs, Alphas, and other machines with a Linux kernel that can boot Linux from a cold start. LinuxBIOS is primarily Linux - about 10 lines of patches to the current Linux kernel. Additionally, the startup code - about 500 lines of assembly and 5000 lines of C - executes 16 instructions to get into 32-bit mode and then performs DRAM and other hardware initialization required before Linux can take over. <br /> <br /> Our primary motivation for the project was maintenance of large clusters, but not surprisingly interest and contributions have come from people with varying backgrounds. <br /> <br /> === Why do we need LinuxBIOS? ===<br /> <br /> Current PCs used as cluster nodes depend on a vendor-supplied BIOS for booting. The BIOS in turn relies on inherently unreliable devices such as floppy disks and hard drives to boot the operating system. In addition, current BIOS software is unable to accommodate non-standard hardware making it difficult to support experimental work. The BIOS is slow and often erroneous and redundant and, most importantly, maintenance is a nightmare. Imagine walking around with a keyboard and monitor to every one of the 128 nodes in a cluster to change one BIOS setting. <br /> <br /> The LinuxBIOS gunzip's the Linux kernel straight out of NVRAM and essentially requires no moving parts other than the fan. It does a minimal amount of hardware initialization before jumping to the kernel start and lets Linux do the rest. As a result, it is much faster (current record 3 seconds), which has sparked interest in the consumer electronics community as well. Moreover, updates can be performed over the network. <br /> <br /> Using a real operating system to boot another operating system provides much greater flexibility than using a simple netboot program or the BIOS. Because Linux is the boot mechanism, it can boot over standard Ethernet or over other interconnects such as Myrinet, Quadrics, or SCI. It can use SSH connections to load the kernel, or it can use the InterMezzo caching file system or traditional NFS. Cluster nodes can be as simple as they need to be - perhaps as simple as a CPU and memory, no disk, no floppy, and no file system. The nodes will be much less autonomous thus making them easier to maintain. <br /> <br /> === Who is working on LinuxBIOS? ===<br /> <br /> The LinuxBIOS project was started in the winter of 1999 in the Advanced Computing Laboratory at Los Alamos National Laboratory by Ron Minnich. Two undergraduate students, James Hendricks and Dale Webster spent their winter vacation putting together the proof of concept implementation. <br /> <br /> Since then, a long list of people have contributed both in discussions and actual code. See our contributors page for details. Please don't be shy and let us know if you are missing from the list. It's not a purposeful omission, just an unfortunate mistake. <br /> <br /> === Who is funding LinuxBIOS? ===<br /> <br /> The LinuxBIOS project is funded by the Los Alamos Computer Science Institute and the Department of Energy's Office of Science. <br /> <br /> === Will LinuxBIOS work on my machine? ===<br /> <br /> See the [[Supported Motherboards]] page for which mainboards are supported. Also, see the products page for a list of vendors selling products running LinuxBIOS.<br /> <br /> === What commercial products use LinuxBIOS? ===<br /> <br /> See the [[products]] page.<br /> <br /> === Which different operating systems will LinuxBIOS boot? ===<br /> <br /> Linux (of course)<br /> <br /> Plan 9<br /> <br /> Windows 2000 (via [[ADLO]])<br /> <br /> We have look at some of the BSD OSes but (e.g.) FreeBSD makes BIOS calls, and we don't support<br /> BIOS calls. Possibly ADLO could be used to support FreeBSD, but the right thing to do is remove<br /> FreeBSD's dependence on BIOS calls.<br /> <br /> === How can I help with LinuxBIOS? ===<br /> <br /> Contact [[User:Rminnich|Ron Minnich]] for projects related to LinuxBIOS.<br /> <br /> == Developer ==<br /> <br /> === What kind of hardware tools do I need? ===<br /> <br /> A motherboard (or mainboard as LinuxBIOS calls it) that has a supported chipset on it. Ok.. Well not exactly. As long as you have the documentation for the chipset/mainboard and its free of any NDA issues you can use an unsupported chipset/Mainboard but you have a twisty road ahead of you.<br /> <br /> And of course you need a Linux developemnet machine. The LinuxBIOS build enviroment is not supported on Windows. It may be possilbe to do in under cygwin but nobody has tried.<br /> <br /> It's also handy to have one/some/all of the following:<br /> <br /> - EPROM/Flash programmer that can program the flash on your motherboard.<br /> http://www.mcumall.com/<br /> - ROM emulator<br /> - Bios Savior <br /> http://www.ioss.com.tw/web/English/RD1BIOSSavior.html<br /> http://www.cwlinux.com/eng/products/products_lbmb.php<br /> - POST card<br /> &lt;Need some more links to POST cards&gt;<br /> - Compact Flash IDE adaptor <br /> http://www.cwlinux.com/eng/products/products_ide2cf.php<br /> http://www.mini-box.com/s.nl/sc.8/category.14/.f<br /> http://www.acscontrol.com/Index_ACS.asp?Page=/Pages/Products/CompactFlash/IDE_To_CF_Adapter.htm<br /> - Oscilliscope<br /> - In Circuit Emulator hardware debugger<br /> - LinuxBIOS SDK<br /> http://www.cwlinux.com/eng/products/products_sdk.php<br /> <br /> === What documentation do I need? ===<br /> <br /> As much as you can possibly get your hands on. Minimum you need the docs for your chipset. Without chipset docs you are basically lost. <br /> <br /> There have been some reports of people making things work by booting with the BIOS that comes with the board. Dumping the PCI config registers and then making LinuxBIOS match those registers. But since sometimes you have to set different bits in a given register at different times so that intermediate info will be lost. Getting a mainboard up with out chipset docs can be a very long and involved process.<br /> <br /> === What if my chipset docs are covered by an NDA? ===<br /> <br /> If the documentation for your chipset covered by and NDA with no source release agreement you won't be able to release your code back to to the LinuxBIOS project in general or you will violate the GPL.<br /> Many vendors accept releasing the source code produced after reading such specs while they don't allow the specs themselves to be revealed. Also, you can offer them to review the code before releasing it.<br /> <br /> === Where is the mailing list archived? ===<br /> <br /> The best archive out there is at the University of Maryland. <br /> <br /> http://www.mail-archive.com/linuxbios@clustermatic.org/<br /> <br /> In addition, we've pieced together an archive that dates back to about the beginning of 2000 (including messages that were going to the freebios and openbios mailing lists).<br /> <br /> === Where do I get the code? ===<br /> <br /> See the [[Download_freebios_v2|download page]].<br /> <br /> === How do I build? ===<br /> <br /> See the documentation. For help generating a config file, see Generate a config file. (jdarby: this needs to be wikiized)<br /> <br /> === Why is the code so complicated and what can I do to make it easier? ===<br /> <br /> The reason is the complexity of the problem. We support a lot of hardware, and a given chip on a given board will most likely not be configured quite the same as the same chip on some other board. <br /> <br /> To help make code navigation easier, pick a target and build that target. Then, in the build directory, type make tags or make etags to get your favorite tags file. <br /> <br /> === What chipsets are supported? ===<br /> <br /> See status for the most up-to-date info.. (jdarby: this needs to be wikiized)<br /> <br /> === How can I tell if my motherboard is supported by LinuxBIOS? ===<br /> <br /> There are 2 methods:<br /> <br /> 1) Check [[Supported Motherboards]]<br /> <br /> If you don't see your chipset/Mainboard listed there then boot linux on your target and send the output of 'lspci -vvv' to the linuxBIOS list asking if this chipset is supported.<br /> <br /> 2) &quot;Use the source Luke&quot;<br /> <br /> Check out the latest copy of LinuxBIOS from CVS [[Download freebios v2]] and look in the freebios2/src/mainboard directory. (The LinuxBios module is called 'freebios2' in CVS for legacy reasons) There are directories for each manufacturer of mainboards that LinuxBIOS supports. Below the manufacturer directory is a directory for each mainboard or family of<br /> mainboard. If a directory for your mainboad dosen't exist then theres a good chance LinuxBIOS dosen't support your mainboard out-of-the-box. Posting to the list would probally be the next option. See 'the lspci -vvv' in the earlier part of the question.<br /> <br /> If the directory does exist then it still dosen't mean 100% the mainboard will work but at least it probally worked at one time. Posting to the list will probally get you the latest info for that mainboard.<br /> <br /> === What is this POST card thing? ===<br /> <br /> A POST card will save your life. The term POST means Power On Self Test and comes from the original IBM specifications for the BIOS. Port 80 is a pre-defined port to which programs can output a byte. The POST card displays the byte in hex on its 2 digit display. We use a lot of POST codes in LinuxBIOS, so if you can tell us the POST code you see, we will have some idea of what happened. <br /> <br /> If your LinuxBIOS machine is working properly, you will see it count up from 0xd0 to 0xd9 (while it is gunzipping the kernel) and then display 0x98 (Linux idle loop). <br /> <br /> === How do I contribute my changes? ===<br /> <br /> Any one without commit privileges (which is most of you) need to get changes approved by Ron Minnich. <br /> <br /> === How do I (re-)flash the BIOS? ===<br /> <br /> Download the appropriate flash update utility. Build the romimage as explained above and use the flash update utility to update the BIOS. Be warned that not all update utilities allow you to load your own BIOS image. For example, Intel decided to disallow it for the MS440GX mainboard (probably after hearing about us!) Here are some mainboard specific directions: <br /> <br /> ==== General ====<br /> LinuxBIOS v2 contains a flash utility called &quot;flash_rom&quot;. It can be found at freebios2/util/flash_and_burn.<br /> <br /> Example:<br /> bash# ./flash_rom<br /> Calibrating timer since microsleep sucks ... takes a second<br /> Setting up microsecond timing loop<br /> 515M loops per second<br /> OK, calibrated, now do the deed<br /> Enabling flash write on AMD8111...OK<br /> Trying Am29F040B, 512 KB<br /> probe_29f040b: id1 0x4e, id2 0x41<br /> Trying At29C040A, 512 KB<br /> probe_jedec: id1 0xbf, id2 0x51<br /> Trying Mx29f002, 256 KB<br /> probe_29f002: id1 0xbf, id2 0x51<br /> Trying SST29EE020A, 256 KB<br /> probe_jedec: id1 0xbf, id2 0x51<br /> Trying SST28SF040A, 512 KB<br /> probe_28sf040: id1 0x4e, id2 0x41<br /> Trying SST39SF020A, 256 KB<br /> probe_jedec: id1 0xbf, id2 0x51<br /> Trying SST39VF020, 256 KB<br /> probe_jedec: id1 0xbf, id2 0x51<br /> Trying SST49LF040, 512 KB<br /> probe_jedec: id1 0xbf, id2 0x51<br /> SST49LF040 found at physical address: 0xfff80000<br /> Part is SST49LF040<br /> OK, only ENABLING flash write, but NOT FLASHING<br /> bash# flash_rom --help<br /> usage: ./flash_rom [-rwv] [-c chipname] [-s exclude_start] [-e exclude_end] [file]<br /> -r: read flash and save into file<br /> -w: write file into flash (default when file is specified)<br /> -v: verify flash against file<br /> -c: probe only for specified flash chip<br /> -s: exclude start position<br /> -e: exclude end postion<br /> If no file is specified, then all that happens<br /> is that flash info is dumped<br /> <br /> Besides that, OpenBIOS contains a flash driver called [http://www.openbios.org/development/devbios.html /dev/bios] which may support some systems and flash chips unsupported by flash_rom.<br /> <br /> ==== SiS 630/950 M/Bs ====<br /> Ollie Lho provided us with flash utilities for these boards under freebios/util/sis. <br /> flash_on turns on the flash write enable. This needs to be run before loading the DoC drivers. <br /> flash_rom allows you to use your SiS 630/950 M/Bs as a flash programmer. It currently supports JEDEC flash parts, AMD am29f040b models, MXIC MX29F002 models, and SST28SF040C models. <br /> <br /> ==== Intel L440GX ====<br /> Get the System Update Package directly from Intel. mcopy the ten files created from running make phlash onto the Intel flash burner disk and use the update utility to burn the BIOS. To restore the original BIOS, set the recovery boot jumper on the motherboard, put the floppy in, and it will load and reflash the original BIOS. <br /> How do I actually burn a flash ROM? <br /> <br /> Buy your favorite flash burner (we use a Needham Electronics EMP 30). Use make floppy to create the romimage and copy it to a floppy. Then use the provided software to burn the flash.<br /> <br /> === How do I burn a DoC? ===<br /> <br /> Currently, only the DoC Millennium is supported. See the documentation. <br /> <br /> === Can I do any serious damage mucking around with this stuff? ===<br /> <br /> Any time you stick your hand into an open machine while the power is on, you're risking life and limb. That said, there are also some other not-so-nice things that can happen if you mess up (not that we would know). <br /> <br /> * Incorrect insertion of the flash (1 casualty) <br /> * Incorrect jumper settings (1 casualty) <br /> * Aggressive and/or inappropriate use of metal objects such as screwdrivers (2 casualties) <br /> * Miscellaneous miswirings and mishandlings (3+ casualties)<br /> <br /> === A note on electrostatic discharge (ESD) and ESD protection (thanks to Bari Ari) ===<br /> <br /> ESD can damage disk drives, boards, DoC's and other parts. The majority of the time, ESD events cause the component to degrade, but not fail testing procedures, resulting in failure at a later date. Because components do not fail immediately, technicians often underestimate the cost of not using ESD prevention measures. Provide at minimum some ESD protection by wearing an antistatic wrist strap attached to the chassis ground on your system when handling parts. <br /> <br /> Always handle boards carefully. They can be extremely sensitive to ESD. Hold boards only by their edges. After removing a board from its protective wrapper or from the system, place it component side up on a grounded, static free surface. Use a conductive foam pad if available. Do not slide the board over any surface. <br /> <br /> To further reduce the chances of ESD, you should create an ESD safe workstation that includes at minimum: <br /> <br /> * Conductive rubber mat, with a lead wire that can be connected to a metal surface to create a ground. <br /> <br /> * ESD wrist strap, which has a resistor inside the strap and a lead wire that can be connected to a metal surface as a ground. The grounding wire on the wrist strap should have between 1 and 10 Megaohms of resistance. The resistor should protect you in case you come in contact with a voltage source. If the resistor is bad or not included, the wrist strap is useless. An accidental shock could be serious and even deadly! <br /> <br /> * Table or workspace that is clean, clear of dust, and away from electrical machinery or other equipment that generates electrical currents. <br /> <br /> The idea is to ensure that all components you are going to interact with have the same charge. By connecting everything to the computer case, you ensure that the components of the case, the chair, and your body all have the same charge. If every object has the same charge, the electrons will not jump from one object to another minimizing the risk of ESD damage. <br /> <br /> === How do I put a filesystem on DoC? ===<br /> OK, here is a little HOWTO on how to set up MTD with a file system. <br /> <br /> This is a m810lmr, booting out of DoC. I am going to reserve the first 2M for kernel. So the layout will be the first 2M for linuxbios and kernel, and 6M for a file system. Kernel is 2.4.17, with linux-2.4.17-sis.patch from linuxbios source tree, and config-2.4.17-sis from the linuxbios source tree. Mainboard is the pcchips m810lmr. <br /> <br /> So I: <br /> modprobe doc2001 <br /> modprobe docprobe <br /> dmesg <br /> <br /> which shows: <br /> <br /> DiskOnChip Millennium found at address 0xFFFC8000 <br /> Flash chip found: Manufacturer ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC) <br /> 1 flash chips found. Total DiskOnChip size: 8 MiB <br /> mtd: Giving out device 0 to DiskOnChip Millennium <br /> Ignoring DiskOnChip Millennium at 0xFFFCA000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFCC000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFCE000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFD0000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFD2000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFD4000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFD6000 - already configured <br /> (etc..) <br /> Now I need MTD utilities. <br /> So I: <br /> cvs -d :pserver:anoncvs@cvs.infradead.org:/home/cvs login <br /> CVS password: <br /> <br /> (password is anoncvs) <br /> Then: <br /> cvs -d :pserver:anoncvs@cvs.infradead.org:/home/cvs co mtd <br /> <br /> Forget the drivers and such, you don't need them. What you need is the tools. <br /> cd mtd/tools <br /> make <br /> <br /> Go ahead and copy the executables somewhere handy, you'll need them. <br /> <br /> Now we need to make the last 6M into a &quot;disk&quot;. We need to format it. The tool is nftl_format, so:<br /> <br /> [root@carly util]# ./nftl_format <br /> $Id: nftl_format.c,v 1.17 2001/08/29 14:28:48 dwmw2 Exp $ <br /> Usage: ./nftl_format [ []] <br /> [root@carly util]# expr 2048 \* 1024 <br /> 2097152 <br /> [root@carly util]# expr 6 \* 1024 \* 1024 <br /> 6291456 <br /> [root@carly util]# ./nftl_format /dev/mtd0 2097152 6291456 <br /> $Id: nftl_format.c,v 1.17 2001/08/29 14:28:48 dwmw2 Exp $ <br /> Phase 1. Checking and erasing Erase Zones from 0x00200000 to 0x00800000 <br /> Phase 2.a Writing NFTL Media Header and Bad Unit Table <br /> Phase 2.b Writing Spare NFTL Media Header and Spare Bad Unit Table <br /> Phase 3. Writing Unit Control Information to each Erase Unit <br /> <br /> <br /> we now have a formatted disk in there. We can now partition it. <br /> <br /> [root@carly util]# modprobe nftl <br /> <br /> dmesg shows LOTS of errors, since this was never partitioned ... <br /> <br /> Also, if you don't have /dev/nftla, <br /> <br /> [root@carly util]# mknod /dev/nftla b 93 0 <br /> <br /> <br /> Don't use the script just yet, it makes /dev/nftla as b 93 16, which is the wrong unit #. <br /> <br /> now fdisk /dev/nftla <br /> <br /> [root@carly util]# fdisk /dev/nftlA <br /> Command (m for help): n <br /> Command action <br /> e extended <br /> p primary partition (1-4) <br /> p <br /> Partition number (1-4): 1 <br /> First cylinder (1-1, default 1): <br /> Using default value 1 <br /> Command (m for help): p <br /> Disk /dev/nftlA: 1 heads, 12224 sectors, 1 cylinders <br /> Units = cylinders of 12224 * 512 bytes <br /> Device Boot Start End Blocks Id System <br /> /dev/nftlA1 1 1 6111+ 83 Linux <br /> Partition 1 has different physical/logical endings: <br /> phys=(768, 0, 0) logical=(0, 0, 12224) <br /> Partition 1 does not end on cylinder boundary: <br /> phys=(768, 0, 0) should be (768, 0, 12224) <br /> Command (m for help): w <br /> The partition table has been altered! <br /> Calling ioctl() to re-read partition table. <br /> WARNING: If you have created or modified any DOS 6.x partitions, please see the fdisk manual page for additional information. <br /> Syncing disks. <br /> [root@carly util]# mknod /dev/nftlA1 b 93 1 <br /> [root@carly util]# mke2fs /dev/nftlA1 <br /> mke2fs 1.23, 15-Aug-2001 for EXT2 FS 0.5b, 95/08/09 <br /> Filesystem label= <br /> OS type: Linux <br /> Block size=1024 (log=0) <br /> Fragment size=1024 (log=0) <br /> 1528 inodes, 6111 blocks <br /> 305 blocks (4.99%) reserved for the super user <br /> First data block=1 <br /> 1 block group <br /> 8192 blocks per group, 8192 fragments per group <br /> 1528 inodes per group <br /> Writing inode tables: done <br /> Writing superblocks and filesystem accounting information: done <br /> <br /> This filesystem will be automatically checked every 37 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. <br /> <br /> [root@carly util]# mount /dev/nftlA1 /mnt <br /> [root@carly util]# cd /mnt <br /> [root@carly mnt]# df . <br /> Filesystem 1k-blocks Used Available Use% Mounted on <br /> /dev/nftlA1 5915 13 5597 1% /mnt <br /> [root@carly mnt]# <br /> <br /> and so you now have an ext2 file system on the DoC. <br /> <br /> (Above is from [[User:Rminnich|Ron Minnich]])<br /> <br /> === How do I turn off embedded sis630 devices? ===<br /> <br /> From aip@cwlinux.com Mon Mar 25 08:54:07 2002 <br /> Date: Mon, 25 Mar 2002 22:07:54 +0800 <br /> From: Andrew Ip <br /> To: Kei Furuuchi <br /> Cc: linuxbios@lanl.gov <br /> Subject: Re: How to turn off unused pci device. <br /> Hi, <br /> &gt; I have pcchips m758lmr which has audio chip besides sis630. <br /> &gt; those functions in sis630 are not used in the motherboard. <br /> &gt; But, the functions keep coming up. How do I turn off those? <br /> The following is from Nikolai Valdych previous message. Hope this help. <br /> -Andrew <br /> -- <br /> Andrew Ip <br /> Email: aip@cwlinux.com <br /> Actualy, it was pretty simple 0x7c00 - All devices enabled, You play with first 4 bits only. Cos there are 4 devices, so you have any combination of 4 bits. <br /> Set bit to 1 to turn off the device, bit 0 to enable it. <br /> This is the device list: <br /> Multimedia Audio controler <br /> Modem controler <br /> Ethernet sis930 controler <br /> USB controler. <br /> For example, to turn off Ethernet + USB it would be: <br /> 0x7c0c -&gt; 1100 in binary (first 4 bits) <br /> To turn off Multimedia audio : <br /> 0x7c01 -&gt; 0001 <br /> in binary and so on... maybe there are more detail, but this is enogh for me, Ollie, again thanks! <br /> nikolai <br /> p.s. though my modem is not yet working..... damn driver...... <br /> <br /> === What is a PIRQ table? ===<br /> <br /> From Adam Sulmicki: <br /> <br /> I found beautfiul descrition of the BIOS implementation of the PIRQ in the red PCI book.<br /> <br /> I found the description of the $PIR data structure in the<br /> (broken)http://www.microsoft.com/hwdev/archive/BUSBIOS/pciirq.asp<br /> Anyone have a better link or a copy of what was there? --[[User:RSmith|RSmith]] 23:34, 1 Mar 2005 (CET)<br /> <br /> looking over linuxbios sources I see that it saves the $PIR data structure<br /> somewhere between 0xf0000 &amp; 0x100000.<br /> <br /> so it seems I'll have to search for $PIR and then save it before copying<br /> over our bios. sigh. hoped for some fixed address in mem.<br /> <br /> -- <br /> Adam<br /> http://www.eax.com The Supreme Headquarters of the 32 bit registers<br /> <br /> === How do I set up etherboot with LinuxBIOS? ===<br /> <br /> Note from Ron: I have edited this somewhat to remove Geode-specific items. <br /> <br /> Christer Weinigel writes: <br /> To: rminnich@lanl.gov<br /> Cc: linuxbios@lanl.gov<br /> Subject: Re: LinuxBIOS + Etherboot HOWTO?<br /> <br /> <br /> I had some trouble using LinuxBIOS + etherboot... <br /> <br /> <br /> My bad, I messed up and used mkelfImage-1.6 that I got from ftp.lnxi.com, when I realized that I ought to use the one from freebios/util everything started working. <br /> <br /> <br /> Here's what I did to get LinuxBIOS + Etherboot loading and booting a Linux kernel using TFTP. <br /> <br /> <br /> /Christer <br /> <br /> <br /> Get etherboot-5.0 from the CVS tree on etherboot.sourceforge.net. <br /> <br /> <br /> Modify etherboot-5.0/src/Config, comment out: <br /> <br /> # BIOS select don't change unless you know what you are doing<br /> #CFLAGS32+= -DPCBIOS<br /> <br /> <br /> <br /> and uncomment the following: <br /> <br /> # Options to make a version of Etherboot that will work under linuxBIOS.<br /> CFLAGS32+= -DLINUXBIOS -DCONFIG_TSC_CURRTICKS -DCONSOLE_SERIAL \<br /> -DCOMCONSOLE=0x3f8 -DCOMPRESERVE -DCONFIG_PCI_DIRECT -DELF_IMAGE <br /> <br /> <br /> <br /> Compile Etherboot to make an elf file for your ethernet card: <br /> <br /> make bin32/natsemi.elf<br /> <br /> <br /> <br /> Compile and install mkelfImage from freebios/util/mkelfImage. <br /> <br /> <br /> Create a bootimage to put on your TFTP server: <br /> <br /> mkelfImage --command-line=&quot;root=/dev/hda2 console=ttyS0,38400&quot; \<br /> --kernel vmlinux -o /tftpboot/kernel<br /> <br /> <br /> <br /> Finally, make sure that your BOOT/DCHP server is answering and that the TFTP server is active. <br /> <br /> <br /> Tell LinuxBIOS to boot an elf Image, and tell LinuxBIOS where it is: <br /> <br /> option USE_ELF_BOOT=1<br /> <br /> <br /> <br /> I have placed natsemi.elf in the first 64k of my BIOS flash chip, and LinuxBIOS in the second 64k. <br /> <br /> insmod bios.o<br /> dd if=natsemi.elf of=/dev/bios bs=64k<br /> dd if=linuxbios.rom of=/dev/bios bs=64k seek=1<br /> <br /> <br /> <br /> Finally boot LinuxBIOS. <br /> <br /> === How do I set GEODE video? ===<br /> <br /> From christer@weinigel.se Wed Nov 27 07:47:17 2002<br /> Date: 27 Nov 2002 10:55:01 +0100<br /> From: Christer Weinigel <br /> To: Adam Bezanson <br /> Cc: linuxbios@clustermatic.org<br /> Subject: Re: Geode Kernel Config <br /> <br /> &quot;Adam Bezanson&quot; writes:<br /> <br /> &gt; I've got an Eval card from National Semi that contains<br /> &gt; the SC1200. I'd like to try LinuxBios on it.<br /> &gt; I've downloaded both the 2.4.18 and 2.4.19 kernels to start with.<br /> &gt; What patches do I need to apply to the kernel?<br /> &gt; Is there a config file I can use to configure the kernel, or<br /> &gt; should I do it manually? <br /> <br /> A normal 2.4 Linux kernel will work fine as long as you compile for a<br /> 586 CPU (CONFIG_M586), not Pentium or higher (CONFIG_M586TSC and up)<br /> since the TSC behaves a bit differently. <br /> <br /> If you want support for the watchdog or the GPIO pins in a 2.4 kernel,<br /> you can find an old patch from me at:<br /> <br /> http://groups.google.com/groups?selm=20020226015215.20118F5B%40acolyte.hack.org&amp;oe=UTF-8&amp;output=gplain<br /> <br /> An updated version of this patch has been included in Linux 2.5. Alan<br /> Cox' 2.5 kernel also has support for doing DMA on the SC1200 IDE<br /> controller; I don't know if there is a corresponding patch for 2.4. <br /> <br /> Other than that, take a look at the freebios/src/mainboard/nano/nano<br /> directory and make a copy of it. All you should have to do is to<br /> modify the Pin Multiplexing Register (PMR) and Miscellaneous Config<br /> Register (MCR) in the Config file and to modify the irq assignments.<br /> <br /> Depending on what you want to do, there are a few limitations with<br /> the current LinuxBIOS on the SC1200: <br /> <br /> There is no video support in LinuxBIOS itself, so you won't get<br /> any video until you have loaded the NatSemi Geode Linux<br /> framebuffer driver (can be found at www.linux4.tv under the<br /> heading SP1SC10 Platform Image).<br /> <br /> There is no SMM/VSA support at all, this means that anything<br /> relying on it won't work. What this means is that Audio won't<br /> work.<br /> <br /> Other than that everything works fine, IDE in PIO mode, the PCI bus,<br /> watchdog, GPIOs, everything.<br /> <br /> /Christer<br /> <br /> -- <br /> &quot;Just how much can I get away with and still go to heaven?&quot;<br /> <br /> Freelance consultant specializing in device driver programming for Linux <br /> Christer Weinigel http://www.weinigel.se<br /> _______________________________________________<br /> Linuxbios mailing list<br /> Linuxbios@clustermatic.org<br /> http://www.clustermatic.org/mailman/listinfo/linuxbios<br /> <br /> <br /> === How do I set up testbios? ===<br /> <br /> From daubin@actuality-systems.com Wed Oct 6 10:23:10 2004<br /> Date: Tue, 5 Oct 2004 15:19:24 -0400<br /> From: Dave Aubin <br /> To: linuxbios@clustermatic.org<br /> Subject: RE: Testbios help with nvidia 6800Gt and simple how to<br /> <br /> I've taken the time to put together a simple testbios faq.<br /> I hope it is helpful. Feedback and additions are welcome. <br /> <br /> Thanks,<br /> Dave<br /> <br /> ==== Testbios (vgabios) Faq ====<br /> <br /> Date: 10/5/2004<br /> Author(s): David Aubin daubin@actuality-systems.com<br /> <br /> Purpose: Testbios is an i386 emulator that sits on top of userspace linux. It's primary purpose is to provide program video rom's in to the cached memory area.<br /> <br /> ===== Where to obtain testbios =====<br /> <br /> Testbios(vgabios) can be retrieved from the linuxbios/freebios source tree: [http://www.linuxbios.org/developer/download/index.html]<br /> <br /> ===== Prerequisites =====<br /> <br /> You must have installed pci-utils<br /> * Get http://atrey.karlin.mff.cuni.cz/~mj/pciutils.shtml<br /> <br /> ===== How to build testbios =====<br /> * cd freebios/util/vgabios<br /> * Edit ./Makefile and fill in the correct values for your environment (I build on a 64 AMD so my makefile looks like this)<br /> <br /> Begin ./Makefile for x64:<br /> CC = gcc<br /> ARCH := $(shell uname -m | sed -e s,i[3456789]86,i386,)<br /> INCLUDE = -I ../pciutils-2.1.11<br /> CFLAGS = -Wall -Ix86emu/include -O2 -g $(INCLUDE)<br /> <br /> INTOBJS = int10.o int15.o int16.o int1a.o inte6.o<br /> OBJECTS = testbios.o helper_exec.o helper_mem.o $(INTOBJS)<br /> LDFLAGS = -static-libgcc -static<br /> <br /> LIBS = x86emu/src/x86emu/libx86emu.a ../pciutils-2.1.11/lib/libpci.a<br /> <br /> # user space pci is the only option right now.<br /> OBJECTS += pci-userspace.o<br /> <br /> ifeq ($(shell if test &quot;$(ARCH)&quot; == &quot;x86_64&quot; ; then echo 1; fi), 1)<br /> CFLAGS +=-m32 -march=i386<br /> endif<br /> <br /> all: testbios<br /> <br /> testbios: $(OBJECTS) $(LIBS)<br /> $(CC) $(CFLAGS) -o testbios $(OBJECTS) $(LDFLAGS)<br /> $(LIBS)<br /> <br /> helper_exec.o: helper_exec.c test.h<br /> <br /> x86emu/src/x86emu/libx86emu.a:<br /> $(MAKE) -C x86emu/src/x86emu/ -f makefile.linux<br /> <br /> clean:<br /> $(MAKE) -C x86emu/src/x86emu/ -f makefile.linux clean<br /> rm -f *.o *~ testbios <br /> <br /> distclean: clean<br /> $(MAKE) -C x86emu/src/x86emu/ -f makefile.linux clean<br /> <br /> <br /> End ./Makefile<br /> <br /> * Edit ~vgabios/x86emu/src/x86emu/makefile.linux and fill in the correct values for your environment (I build on a 64 AMD so my makefile looks like this)<br /> <br /> Begin ~vgabios/x86emu/src/x86emu/makefile.linux:<br /> #############################################################################<br /> #<br /> # Realmode X86 Emulator Library<br /> #<br /> # Copyright (C) 1996-1999 SciTech Software, Inc.<br /> #<br /> #<br /> &lt;nowiki&gt;========================================================================&lt;/nowiki&gt;<br /> #<br /> # Permission to use, copy, modify, distribute, and sell this software and<br /> # its documentation for any purpose is hereby granted without fee,<br /> # provided that the above copyright notice appear in all copies and that<br /> # both that copyright notice and this permission notice appear in<br /> # supporting documentation, and that the name of the authors not be used<br /> # in advertising or publicity pertaining to distribution of the software<br /> # without specific, written prior permission. The authors makes no<br /> # representations about the suitability of this software for any purpose.<br /> # It is provided &quot;as is&quot; without express or implied warranty.<br /> #<br /> # THE AUTHORS DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,<br /> # INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO<br /> # EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR<br /> # CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF<br /> # USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR<br /> # OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR<br /> # PERFORMANCE OF THIS SOFTWARE.<br /> #<br /> #<br /> &lt;nowiki&gt;========================================================================&lt;/nowiki&gt;<br /> #<br /> # Descripton: Linux specific makefile for the x86emu library.<br /> #<br /> #############################################################################<br /> <br /> TARGETLIB = libx86emu.a<br /> <br /> <br /> OBJS=\<br /> debug.o \<br /> decode.o \<br /> fpu.o \<br /> ops.o \<br /> ops2.o \<br /> prim_ops.o \<br /> sys.o<br /> <br /> $(TARGETLIB): $(OBJS)<br /> ar rv $(TARGETLIB) $(OBJS)<br /> <br /> INCS = -I. -Ix86emu -I../../include<br /> CFLAGS += -D__DRIVER__ -DFORCE_POST -D_CEXPORT= -DNO_LONG_LONG -DDEBUG<br /> ARCH := $(shell uname -m | sed -e s,i[3456789]86,i386,)<br /> ifeq ($(shell if test &quot;$(ARCH)&quot; == &quot;x86_64&quot; ; then echo 1; fi), 1)<br /> CFLAGS +=-m32 -march=i386<br /> endif<br /> <br /> <br /> .c.o:<br /> # gcc -m32 -march=i386 -g -O -Wall -c $(CFLAGS) $(INCS) $*.c<br /> gcc -g -O -Wall -c $(CFLAGS) $(INCS) $*.c<br /> <br /> .cpp.o:<br /> # gcc -m32 -march=i386 -c $(CFLAGS) $(INCS) $*.cpp<br /> gcc -c $(CFLAGS) $(INCS) $*.cpp <br /> <br /> clean:<br /> rm -f *.a *.o<br /> <br /> validate: validate.o libx86emu.a<br /> gcc -o validate validate.o -lx86emu -L.<br /> <br /> End ~vgabios/x86emu/src/x86emu/makefile.linux<br /> <br /> * Once built you could have a 32bit testbios executable made. Depending on your embedded environment you might want to have it built shared as the above example makes it static. Just remove -static-libgcc -static from the LDFLAGS on ./Makefile if you wish to have it built shared.<br /> <br /> ===== How to retrieve a good video bios =====<br /> There are sites that have video bios roms on their website. (I know of this one for nvidia cards: [http://whitebunny.demon.nl/hardware/chipset_nvidia.html])<br /> <br /> However you should be able to retrieve your own video bios as well with linux.<br /> * Boot up a machine with a commercial bios (not linux bios) with the video card you wish to work under linux bios.<br /> ** From the command line enter:&lt;br /&gt;&lt;code&gt;dd if=/dev/mem of=vgabios.bin skip=1536 count=128 or &lt;br /&gt;dd if=/dev/mem of=vgabios.bin bs=1k count=64 skip=786432&lt;br /&gt;This assumes you card's bios is cached in 0xc0000. You&lt;br /&gt;can see where and how much your card's bios is using by&lt;br /&gt;doing a cat iomem | grep &quot;Video ROM&quot;&lt;br /&gt;&lt;/code&gt;<br /> *** dd Explained (man dd to learn more):<br /> **** if is the location to retrieve from.<br /> **** of is the output file (your rom image)<br /> **** skip jumps n blocks where the default n is 512 bytes<br /> **** count is how many blocks you wish to read<br /> **** bs is the block size<br /> ** You now have a video bios image<br /> <br /> ===== How to use testbios =====<br /> * Currently testbios only works from user space linux (10/4/04)<br /> * Example from a linux command line or script enter the following to get your video bios programmed:&lt;br /&gt;&lt;code&gt;./testbios -s 65536 --abseg /dev/mem ./vgabios.bin&lt;/code&gt;<br /> ** Testbios explained<br /> *** -s how much of the video bios is there<br /> *** --abseg where would you like to write this (/dev/mem default)<br /> *** filename of video bios<br /> *** -d diag mode <br /> **** How to get pci busdevfn<br /> **** lspci<br /> **** look for your video card<br /> ***** Example:&lt;br /&gt;&lt;code&gt;2:00:00&lt;br /&gt;2 (00 &lt;&lt; 3) | 00 = 0x200&lt;/code&gt;<br /> ***** Example:&lt;br /&gt;&lt;code&gt;00:12.0:&lt;br /&gt;0 (12 &lt;&lt; 3) | 0 = 0x90&lt;/code&gt;<br /> *** -t dump <br /> *** -c codesegment Where do you want to start, default is 0xc0000<br /> *** -b base Where do you want base to be default is 0xc000<br /> *** -i instruction pointer usually left off as the default<br /> <br /> ==== Followup to Testbios FAQ ====<br /> -----Original Message-----<br /> From: linuxbios-admin@clustermatic.org<br /> [mailto:linuxbios-admin@clustermatic.org] On Behalf Of Dave Aubin<br /> Sent: Tuesday, October 05, 2004 2:22 PM<br /> To: Richard Smith<br /> Cc: linuxbios@clustermatic.org<br /> Subject: RE: Testbios help with nvidia 6800Gt and simple how to<br /> <br /> Hi,<br /> <br /> Thank you:) Yes, it was at 0xc0000-0xc7fff, which is only 32k.<br /> But the image I got from the windows tool was 64k (double 8000).<br /> Weird. I would like to stay away from window tools.<br /> The info you provided is nice. I wish there was a way for us To make<br /> a faq and we could add this to the testbios faq. There Is a lot of good<br /> info on the clustermatic list, but it is all Dispersed. <br /> Ron if I write a simple faq can you provide some mechanism to Allow<br /> updates to it?<br /> <br /> Thanks,<br /> Dave <br /> <br /> -----Original Message-----<br /> From: Richard Smith [mailto:rsmith@bitworks.com]<br /> Sent: Tuesday, October 05, 2004 2:16 PM<br /> To: Dave Aubin<br /> Cc: linuxbios@clustermatic.org<br /> Subject: Re: Testbios help with nvidia 6800Gt and simple how to<br /> <br /> Dave Aubin wrote:<br /> <br /> &gt; It seems my dd returned an unusable binary. I found a good binary for<br /> <br /> &gt; The nvidia card from here:<br /> &gt; http://whitebunny.demon.nl/hardware/chipset_nvidia.html<br /> &gt; <br /> <br /> I was wondering about your dd command that but I had not had a chance to<br /> respond yet.<br /> <br /> This is what I use:<br /> <br /> dd if=/dev/mem of=vbios.bin bs=1k count=64 skip=786432<br /> <br /> That will rip the bios from 0x0c0000. You can verify that you actually<br /> have bios there with<br /> <br /> 'hd -s 0x0c0000 -n 256 /dev/mem'<br /> <br /> in some cases it may be located at 0x0e0000 rather than 0x0c0000.<br /> <br /> It should start with the 0x55aa (Little endian) or 0xaa55 (big endian)<br /> and futher on you should see some text identifying the bios.<br /> <br /> <br /> --<br /> Richard A. Smith<br /> <br /> <br /> _______________________________________________<br /> Linuxbios mailing list<br /> Linuxbios@clustermatic.org<br /> http://www.clustermatic.org/mailman/listinfo/linuxbios</div>

Rminnich http://www.coreboot.org/FAQ 2005-03-09T18:18:08Z

<p>Rminnich: /* Which different operating systems will LinuxBIOS boot? */</p> <hr /> <div>== General ==<br /> <br /> === What is LinuxBIOS? ===<br /> <br /> LinuxBIOS aims to replace the normal BIOS found on PCs, Alphas, and other machines with a Linux kernel that can boot Linux from a cold start. LinuxBIOS is primarily Linux - about 10 lines of patches to the current Linux kernel. Additionally, the startup code - about 500 lines of assembly and 5000 lines of C - executes 16 instructions to get into 32-bit mode and then performs DRAM and other hardware initialization required before Linux can take over. <br /> <br /> Our primary motivation for the project was maintenance of large clusters, but not surprisingly interest and contributions have come from people with varying backgrounds. <br /> <br /> === Why do we need LinuxBIOS? ===<br /> <br /> Current PCs used as cluster nodes depend on a vendor-supplied BIOS for booting. The BIOS in turn relies on inherently unreliable devices such as floppy disks and hard drives to boot the operating system. In addition, current BIOS software is unable to accommodate non-standard hardware making it difficult to support experimental work. The BIOS is slow and often erroneous and redundant and, most importantly, maintenance is a nightmare. Imagine walking around with a keyboard and monitor to every one of the 128 nodes in a cluster to change one BIOS setting. <br /> <br /> The LinuxBIOS gunzip's the Linux kernel straight out of NVRAM and essentially requires no moving parts other than the fan. It does a minimal amount of hardware initialization before jumping to the kernel start and lets Linux do the rest. As a result, it is much faster (current record 3 seconds), which has sparked interest in the consumer electronics community as well. Moreover, updates can be performed over the network. <br /> <br /> Using a real operating system to boot another operating system provides much greater flexibility than using a simple netboot program or the BIOS. Because Linux is the boot mechanism, it can boot over standard Ethernet or over other interconnects such as Myrinet, Quadrics, or SCI. It can use SSH connections to load the kernel, or it can use the InterMezzo caching file system or traditional NFS. Cluster nodes can be as simple as they need to be - perhaps as simple as a CPU and memory, no disk, no floppy, and no file system. The nodes will be much less autonomous thus making them easier to maintain. <br /> <br /> === Who is working on LinuxBIOS? ===<br /> <br /> The LinuxBIOS project was started in the winter of 1999 in the Advanced Computing Laboratory at Los Alamos National Laboratory by Ron Minnich. Two undergraduate students, James Hendricks and Dale Webster spent their winter vacation putting together the proof of concept implementation. <br /> <br /> Since then, a long list of people have contributed both in discussions and actual code. See our contributors page for details. Please don't be shy and let us know if you are missing from the list. It's not a purposeful omission, just an unfortunate mistake. <br /> <br /> === Who is funding LinuxBIOS? ===<br /> <br /> The LinuxBIOS project is funded by the Los Alamos Computer Science Institute and the Department of Energy's Office of Science. <br /> <br /> === Will LinuxBIOS work on my machine? ===<br /> <br /> See the [[Supported Motherboards]] page for which mainboards are supported. Also, see the products page for a list of vendors selling products running LinuxBIOS.<br /> <br /> === What commercial products use LinuxBIOS? ===<br /> <br /> See the [[products]] page.<br /> <br /> === Which different operating systems will LinuxBIOS boot? ===<br /> <br /> Linux (of course)<br /> Plan 9<br /> <br /> Windows 2000 (via [[ADLO]])<br /> <br /> We have look at some of the BSD OSes but (e.g.) FreeBSD makes BIOS calls, and we don't support<br /> BIOS calls. Possibly ADLO could be used to support FreeBSD, but the right thing to do is remove<br /> FreeBSD's dependence on BIOS calls.<br /> <br /> === How can I help with LinuxBIOS? ===<br /> <br /> Contact [[User:Rminnich|Ron Minnich]] for projects related to LinuxBIOS.<br /> <br /> == Developer ==<br /> <br /> === What kind of hardware tools do I need? ===<br /> <br /> A motherboard (or mainboard as LinuxBIOS calls it) that has a supported chipset on it. Ok.. Well not exactly. As long as you have the documentation for the chipset/mainboard and its free of any NDA issues you can use an unsupported chipset/Mainboard but you have a twisty road ahead of you.<br /> <br /> And of course you need a Linux developemnet machine. The LinuxBIOS build enviroment is not supported on Windows. It may be possilbe to do in under cygwin but nobody has tried.<br /> <br /> It's also handy to have one/some/all of the following:<br /> <br /> - EPROM/Flash programmer that can program the flash on your motherboard.<br /> http://www.mcumall.com/<br /> - ROM emulator<br /> - Bios Savior <br /> http://www.ioss.com.tw/web/English/RD1BIOSSavior.html<br /> http://www.cwlinux.com/eng/products/products_lbmb.php<br /> - POST card<br /> &lt;Need some more links to POST cards&gt;<br /> - Compact Flash IDE adaptor <br /> http://www.cwlinux.com/eng/products/products_ide2cf.php<br /> http://www.mini-box.com/s.nl/sc.8/category.14/.f<br /> http://www.acscontrol.com/Index_ACS.asp?Page=/Pages/Products/CompactFlash/IDE_To_CF_Adapter.htm<br /> - Oscilliscope<br /> - In Circuit Emulator hardware debugger<br /> - LinuxBIOS SDK<br /> http://www.cwlinux.com/eng/products/products_sdk.php<br /> <br /> === What documentation do I need? ===<br /> <br /> As much as you can possibly get your hands on. Minimum you need the docs for your chipset. Without chipset docs you are basically lost. <br /> <br /> There have been some reports of people making things work by booting with the BIOS that comes with the board. Dumping the PCI config registers and then making LinuxBIOS match those registers. But since sometimes you have to set different bits in a given register at different times so that intermediate info will be lost. Getting a mainboard up with out chipset docs can be a very long and involved process.<br /> <br /> === What if my chipset docs are covered by an NDA? ===<br /> <br /> If the documentation for your chipset covered by and NDA with no source release agreement you won't be able to release your code back to to the LinuxBIOS project in general or you will violate the GPL.<br /> Many vendors accept releasing the source code produced after reading such specs while they don't allow the specs themselves to be revealed. Also, you can offer them to review the code before releasing it.<br /> <br /> === Where is the mailing list archived? ===<br /> <br /> The best archive out there is at the University of Maryland. <br /> <br /> http://www.mail-archive.com/linuxbios@clustermatic.org/<br /> <br /> In addition, we've pieced together an archive that dates back to about the beginning of 2000 (including messages that were going to the freebios and openbios mailing lists).<br /> <br /> === Where do I get the code? ===<br /> <br /> See the [[Download_freebios_v2|download page]].<br /> <br /> === How do I build? ===<br /> <br /> See the documentation. For help generating a config file, see Generate a config file. (jdarby: this needs to be wikiized)<br /> <br /> === Why is the code so complicated and what can I do to make it easier? ===<br /> <br /> The reason is the complexity of the problem. We support a lot of hardware, and a given chip on a given board will most likely not be configured quite the same as the same chip on some other board. <br /> <br /> To help make code navigation easier, pick a target and build that target. Then, in the build directory, type make tags or make etags to get your favorite tags file. <br /> <br /> === What chipsets are supported? ===<br /> <br /> See status for the most up-to-date info.. (jdarby: this needs to be wikiized)<br /> <br /> === How can I tell if my motherboard is supported by LinuxBIOS? ===<br /> <br /> There are 2 methods:<br /> <br /> 1) Check [[Supported Motherboards]]<br /> <br /> If you don't see your chipset/Mainboard listed there then boot linux on your target and send the output of 'lspci -vvv' to the linuxBIOS list asking if this chipset is supported.<br /> <br /> 2) &quot;Use the source Luke&quot;<br /> <br /> Check out the latest copy of LinuxBIOS from CVS [[Download freebios v2]] and look in the freebios2/src/mainboard directory. (The LinuxBios module is called 'freebios2' in CVS for legacy reasons) There are directories for each manufacturer of mainboards that LinuxBIOS supports. Below the manufacturer directory is a directory for each mainboard or family of<br /> mainboard. If a directory for your mainboad dosen't exist then theres a good chance LinuxBIOS dosen't support your mainboard out-of-the-box. Posting to the list would probally be the next option. See 'the lspci -vvv' in the earlier part of the question.<br /> <br /> If the directory does exist then it still dosen't mean 100% the mainboard will work but at least it probally worked at one time. Posting to the list will probally get you the latest info for that mainboard.<br /> <br /> === What is this POST card thing? ===<br /> <br /> A POST card will save your life. The term POST means Power On Self Test and comes from the original IBM specifications for the BIOS. Port 80 is a pre-defined port to which programs can output a byte. The POST card displays the byte in hex on its 2 digit display. We use a lot of POST codes in LinuxBIOS, so if you can tell us the POST code you see, we will have some idea of what happened. <br /> <br /> If your LinuxBIOS machine is working properly, you will see it count up from 0xd0 to 0xd9 (while it is gunzipping the kernel) and then display 0x98 (Linux idle loop). <br /> <br /> === How do I contribute my changes? ===<br /> <br /> Any one without commit privileges (which is most of you) need to get changes approved by Ron Minnich. <br /> <br /> === How do I (re-)flash the BIOS? ===<br /> <br /> Download the appropriate flash update utility. Build the romimage as explained above and use the flash update utility to update the BIOS. Be warned that not all update utilities allow you to load your own BIOS image. For example, Intel decided to disallow it for the MS440GX mainboard (probably after hearing about us!) Here are some mainboard specific directions: <br /> <br /> ==== General ====<br /> LinuxBIOS v2 contains a flash utility called &quot;flash_rom&quot;. It can be found at freebios2/util/flash_and_burn.<br /> <br /> Example:<br /> bash# ./flash_rom<br /> Calibrating timer since microsleep sucks ... takes a second<br /> Setting up microsecond timing loop<br /> 515M loops per second<br /> OK, calibrated, now do the deed<br /> Enabling flash write on AMD8111...OK<br /> Trying Am29F040B, 512 KB<br /> probe_29f040b: id1 0x4e, id2 0x41<br /> Trying At29C040A, 512 KB<br /> probe_jedec: id1 0xbf, id2 0x51<br /> Trying Mx29f002, 256 KB<br /> probe_29f002: id1 0xbf, id2 0x51<br /> Trying SST29EE020A, 256 KB<br /> probe_jedec: id1 0xbf, id2 0x51<br /> Trying SST28SF040A, 512 KB<br /> probe_28sf040: id1 0x4e, id2 0x41<br /> Trying SST39SF020A, 256 KB<br /> probe_jedec: id1 0xbf, id2 0x51<br /> Trying SST39VF020, 256 KB<br /> probe_jedec: id1 0xbf, id2 0x51<br /> Trying SST49LF040, 512 KB<br /> probe_jedec: id1 0xbf, id2 0x51<br /> SST49LF040 found at physical address: 0xfff80000<br /> Part is SST49LF040<br /> OK, only ENABLING flash write, but NOT FLASHING<br /> bash# flash_rom --help<br /> usage: ./flash_rom [-rwv] [-c chipname] [-s exclude_start] [-e exclude_end] [file]<br /> -r: read flash and save into file<br /> -w: write file into flash (default when file is specified)<br /> -v: verify flash against file<br /> -c: probe only for specified flash chip<br /> -s: exclude start position<br /> -e: exclude end postion<br /> If no file is specified, then all that happens<br /> is that flash info is dumped<br /> <br /> Besides that, OpenBIOS contains a flash driver called [http://www.openbios.org/development/devbios.html /dev/bios] which may support some systems and flash chips unsupported by flash_rom.<br /> <br /> ==== SiS 630/950 M/Bs ====<br /> Ollie Lho provided us with flash utilities for these boards under freebios/util/sis. <br /> flash_on turns on the flash write enable. This needs to be run before loading the DoC drivers. <br /> flash_rom allows you to use your SiS 630/950 M/Bs as a flash programmer. It currently supports JEDEC flash parts, AMD am29f040b models, MXIC MX29F002 models, and SST28SF040C models. <br /> <br /> ==== Intel L440GX ====<br /> Get the System Update Package directly from Intel. mcopy the ten files created from running make phlash onto the Intel flash burner disk and use the update utility to burn the BIOS. To restore the original BIOS, set the recovery boot jumper on the motherboard, put the floppy in, and it will load and reflash the original BIOS. <br /> How do I actually burn a flash ROM? <br /> <br /> Buy your favorite flash burner (we use a Needham Electronics EMP 30). Use make floppy to create the romimage and copy it to a floppy. Then use the provided software to burn the flash.<br /> <br /> === How do I burn a DoC? ===<br /> <br /> Currently, only the DoC Millennium is supported. See the documentation. <br /> <br /> === Can I do any serious damage mucking around with this stuff? ===<br /> <br /> Any time you stick your hand into an open machine while the power is on, you're risking life and limb. That said, there are also some other not-so-nice things that can happen if you mess up (not that we would know). <br /> <br /> * Incorrect insertion of the flash (1 casualty) <br /> * Incorrect jumper settings (1 casualty) <br /> * Aggressive and/or inappropriate use of metal objects such as screwdrivers (2 casualties) <br /> * Miscellaneous miswirings and mishandlings (3+ casualties)<br /> <br /> === A note on electrostatic discharge (ESD) and ESD protection (thanks to Bari Ari) ===<br /> <br /> ESD can damage disk drives, boards, DoC's and other parts. The majority of the time, ESD events cause the component to degrade, but not fail testing procedures, resulting in failure at a later date. Because components do not fail immediately, technicians often underestimate the cost of not using ESD prevention measures. Provide at minimum some ESD protection by wearing an antistatic wrist strap attached to the chassis ground on your system when handling parts. <br /> <br /> Always handle boards carefully. They can be extremely sensitive to ESD. Hold boards only by their edges. After removing a board from its protective wrapper or from the system, place it component side up on a grounded, static free surface. Use a conductive foam pad if available. Do not slide the board over any surface. <br /> <br /> To further reduce the chances of ESD, you should create an ESD safe workstation that includes at minimum: <br /> <br /> * Conductive rubber mat, with a lead wire that can be connected to a metal surface to create a ground. <br /> <br /> * ESD wrist strap, which has a resistor inside the strap and a lead wire that can be connected to a metal surface as a ground. The grounding wire on the wrist strap should have between 1 and 10 Megaohms of resistance. The resistor should protect you in case you come in contact with a voltage source. If the resistor is bad or not included, the wrist strap is useless. An accidental shock could be serious and even deadly! <br /> <br /> * Table or workspace that is clean, clear of dust, and away from electrical machinery or other equipment that generates electrical currents. <br /> <br /> The idea is to ensure that all components you are going to interact with have the same charge. By connecting everything to the computer case, you ensure that the components of the case, the chair, and your body all have the same charge. If every object has the same charge, the electrons will not jump from one object to another minimizing the risk of ESD damage. <br /> <br /> === How do I put a filesystem on DoC? ===<br /> OK, here is a little HOWTO on how to set up MTD with a file system. <br /> <br /> This is a m810lmr, booting out of DoC. I am going to reserve the first 2M for kernel. So the layout will be the first 2M for linuxbios and kernel, and 6M for a file system. Kernel is 2.4.17, with linux-2.4.17-sis.patch from linuxbios source tree, and config-2.4.17-sis from the linuxbios source tree. Mainboard is the pcchips m810lmr. <br /> <br /> So I: <br /> modprobe doc2001 <br /> modprobe docprobe <br /> dmesg <br /> <br /> which shows: <br /> <br /> DiskOnChip Millennium found at address 0xFFFC8000 <br /> Flash chip found: Manufacturer ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC) <br /> 1 flash chips found. Total DiskOnChip size: 8 MiB <br /> mtd: Giving out device 0 to DiskOnChip Millennium <br /> Ignoring DiskOnChip Millennium at 0xFFFCA000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFCC000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFCE000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFD0000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFD2000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFD4000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFD6000 - already configured <br /> (etc..) <br /> Now I need MTD utilities. <br /> So I: <br /> cvs -d :pserver:anoncvs@cvs.infradead.org:/home/cvs login <br /> CVS password: <br /> <br /> (password is anoncvs) <br /> Then: <br /> cvs -d :pserver:anoncvs@cvs.infradead.org:/home/cvs co mtd <br /> <br /> Forget the drivers and such, you don't need them. What you need is the tools. <br /> cd mtd/tools <br /> make <br /> <br /> Go ahead and copy the executables somewhere handy, you'll need them. <br /> <br /> Now we need to make the last 6M into a &quot;disk&quot;. We need to format it. The tool is nftl_format, so:<br /> <br /> [root@carly util]# ./nftl_format <br /> $Id: nftl_format.c,v 1.17 2001/08/29 14:28:48 dwmw2 Exp $ <br /> Usage: ./nftl_format [ []] <br /> [root@carly util]# expr 2048 \* 1024 <br /> 2097152 <br /> [root@carly util]# expr 6 \* 1024 \* 1024 <br /> 6291456 <br /> [root@carly util]# ./nftl_format /dev/mtd0 2097152 6291456 <br /> $Id: nftl_format.c,v 1.17 2001/08/29 14:28:48 dwmw2 Exp $ <br /> Phase 1. Checking and erasing Erase Zones from 0x00200000 to 0x00800000 <br /> Phase 2.a Writing NFTL Media Header and Bad Unit Table <br /> Phase 2.b Writing Spare NFTL Media Header and Spare Bad Unit Table <br /> Phase 3. Writing Unit Control Information to each Erase Unit <br /> <br /> <br /> we now have a formatted disk in there. We can now partition it. <br /> <br /> [root@carly util]# modprobe nftl <br /> <br /> dmesg shows LOTS of errors, since this was never partitioned ... <br /> <br /> Also, if you don't have /dev/nftla, <br /> <br /> [root@carly util]# mknod /dev/nftla b 93 0 <br /> <br /> <br /> Don't use the script just yet, it makes /dev/nftla as b 93 16, which is the wrong unit #. <br /> <br /> now fdisk /dev/nftla <br /> <br /> [root@carly util]# fdisk /dev/nftlA <br /> Command (m for help): n <br /> Command action <br /> e extended <br /> p primary partition (1-4) <br /> p <br /> Partition number (1-4): 1 <br /> First cylinder (1-1, default 1): <br /> Using default value 1 <br /> Command (m for help): p <br /> Disk /dev/nftlA: 1 heads, 12224 sectors, 1 cylinders <br /> Units = cylinders of 12224 * 512 bytes <br /> Device Boot Start End Blocks Id System <br /> /dev/nftlA1 1 1 6111+ 83 Linux <br /> Partition 1 has different physical/logical endings: <br /> phys=(768, 0, 0) logical=(0, 0, 12224) <br /> Partition 1 does not end on cylinder boundary: <br /> phys=(768, 0, 0) should be (768, 0, 12224) <br /> Command (m for help): w <br /> The partition table has been altered! <br /> Calling ioctl() to re-read partition table. <br /> WARNING: If you have created or modified any DOS 6.x partitions, please see the fdisk manual page for additional information. <br /> Syncing disks. <br /> [root@carly util]# mknod /dev/nftlA1 b 93 1 <br /> [root@carly util]# mke2fs /dev/nftlA1 <br /> mke2fs 1.23, 15-Aug-2001 for EXT2 FS 0.5b, 95/08/09 <br /> Filesystem label= <br /> OS type: Linux <br /> Block size=1024 (log=0) <br /> Fragment size=1024 (log=0) <br /> 1528 inodes, 6111 blocks <br /> 305 blocks (4.99%) reserved for the super user <br /> First data block=1 <br /> 1 block group <br /> 8192 blocks per group, 8192 fragments per group <br /> 1528 inodes per group <br /> Writing inode tables: done <br /> Writing superblocks and filesystem accounting information: done <br /> <br /> This filesystem will be automatically checked every 37 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. <br /> <br /> [root@carly util]# mount /dev/nftlA1 /mnt <br /> [root@carly util]# cd /mnt <br /> [root@carly mnt]# df . <br /> Filesystem 1k-blocks Used Available Use% Mounted on <br /> /dev/nftlA1 5915 13 5597 1% /mnt <br /> [root@carly mnt]# <br /> <br /> and so you now have an ext2 file system on the DoC. <br /> <br /> (Above is from [[User:Rminnich|Ron Minnich]])<br /> <br /> === How do I turn off embedded sis630 devices? ===<br /> <br /> From aip@cwlinux.com Mon Mar 25 08:54:07 2002 <br /> Date: Mon, 25 Mar 2002 22:07:54 +0800 <br /> From: Andrew Ip <br /> To: Kei Furuuchi <br /> Cc: linuxbios@lanl.gov <br /> Subject: Re: How to turn off unused pci device. <br /> Hi, <br /> &gt; I have pcchips m758lmr which has audio chip besides sis630. <br /> &gt; those functions in sis630 are not used in the motherboard. <br /> &gt; But, the functions keep coming up. How do I turn off those? <br /> The following is from Nikolai Valdych previous message. Hope this help. <br /> -Andrew <br /> -- <br /> Andrew Ip <br /> Email: aip@cwlinux.com <br /> Actualy, it was pretty simple 0x7c00 - All devices enabled, You play with first 4 bits only. Cos there are 4 devices, so you have any combination of 4 bits. <br /> Set bit to 1 to turn off the device, bit 0 to enable it. <br /> This is the device list: <br /> Multimedia Audio controler <br /> Modem controler <br /> Ethernet sis930 controler <br /> USB controler. <br /> For example, to turn off Ethernet + USB it would be: <br /> 0x7c0c -&gt; 1100 in binary (first 4 bits) <br /> To turn off Multimedia audio : <br /> 0x7c01 -&gt; 0001 <br /> in binary and so on... maybe there are more detail, but this is enogh for me, Ollie, again thanks! <br /> nikolai <br /> p.s. though my modem is not yet working..... damn driver...... <br /> <br /> === What is a PIRQ table? ===<br /> <br /> From Adam Sulmicki: <br /> <br /> I found beautfiul descrition of the BIOS implementation of the PIRQ in the red PCI book.<br /> <br /> I found the description of the $PIR data structure in the<br /> (broken)http://www.microsoft.com/hwdev/archive/BUSBIOS/pciirq.asp<br /> Anyone have a better link or a copy of what was there? --[[User:RSmith|RSmith]] 23:34, 1 Mar 2005 (CET)<br /> <br /> looking over linuxbios sources I see that it saves the $PIR data structure<br /> somewhere between 0xf0000 &amp; 0x100000.<br /> <br /> so it seems I'll have to search for $PIR and then save it before copying<br /> over our bios. sigh. hoped for some fixed address in mem.<br /> <br /> -- <br /> Adam<br /> http://www.eax.com The Supreme Headquarters of the 32 bit registers<br /> <br /> === How do I set up etherboot with LinuxBIOS? ===<br /> <br /> Note from Ron: I have edited this somewhat to remove Geode-specific items. <br /> <br /> Christer Weinigel writes: <br /> To: rminnich@lanl.gov<br /> Cc: linuxbios@lanl.gov<br /> Subject: Re: LinuxBIOS + Etherboot HOWTO?<br /> <br /> <br /> I had some trouble using LinuxBIOS + etherboot... <br /> <br /> <br /> My bad, I messed up and used mkelfImage-1.6 that I got from ftp.lnxi.com, when I realized that I ought to use the one from freebios/util everything started working. <br /> <br /> <br /> Here's what I did to get LinuxBIOS + Etherboot loading and booting a Linux kernel using TFTP. <br /> <br /> <br /> /Christer <br /> <br /> <br /> Get etherboot-5.0 from the CVS tree on etherboot.sourceforge.net. <br /> <br /> <br /> Modify etherboot-5.0/src/Config, comment out: <br /> <br /> # BIOS select don't change unless you know what you are doing<br /> #CFLAGS32+= -DPCBIOS<br /> <br /> <br /> <br /> and uncomment the following: <br /> <br /> # Options to make a version of Etherboot that will work under linuxBIOS.<br /> CFLAGS32+= -DLINUXBIOS -DCONFIG_TSC_CURRTICKS -DCONSOLE_SERIAL \<br /> -DCOMCONSOLE=0x3f8 -DCOMPRESERVE -DCONFIG_PCI_DIRECT -DELF_IMAGE <br /> <br /> <br /> <br /> Compile Etherboot to make an elf file for your ethernet card: <br /> <br /> make bin32/natsemi.elf<br /> <br /> <br /> <br /> Compile and install mkelfImage from freebios/util/mkelfImage. <br /> <br /> <br /> Create a bootimage to put on your TFTP server: <br /> <br /> mkelfImage --command-line=&quot;root=/dev/hda2 console=ttyS0,38400&quot; \<br /> --kernel vmlinux -o /tftpboot/kernel<br /> <br /> <br /> <br /> Finally, make sure that your BOOT/DCHP server is answering and that the TFTP server is active. <br /> <br /> <br /> Tell LinuxBIOS to boot an elf Image, and tell LinuxBIOS where it is: <br /> <br /> option USE_ELF_BOOT=1<br /> <br /> <br /> <br /> I have placed natsemi.elf in the first 64k of my BIOS flash chip, and LinuxBIOS in the second 64k. <br /> <br /> insmod bios.o<br /> dd if=natsemi.elf of=/dev/bios bs=64k<br /> dd if=linuxbios.rom of=/dev/bios bs=64k seek=1<br /> <br /> <br /> <br /> Finally boot LinuxBIOS. <br /> <br /> === How do I set GEODE video? ===<br /> <br /> From christer@weinigel.se Wed Nov 27 07:47:17 2002<br /> Date: 27 Nov 2002 10:55:01 +0100<br /> From: Christer Weinigel <br /> To: Adam Bezanson <br /> Cc: linuxbios@clustermatic.org<br /> Subject: Re: Geode Kernel Config <br /> <br /> &quot;Adam Bezanson&quot; writes:<br /> <br /> &gt; I've got an Eval card from National Semi that contains<br /> &gt; the SC1200. I'd like to try LinuxBios on it.<br /> &gt; I've downloaded both the 2.4.18 and 2.4.19 kernels to start with.<br /> &gt; What patches do I need to apply to the kernel?<br /> &gt; Is there a config file I can use to configure the kernel, or<br /> &gt; should I do it manually? <br /> <br /> A normal 2.4 Linux kernel will work fine as long as you compile for a<br /> 586 CPU (CONFIG_M586), not Pentium or higher (CONFIG_M586TSC and up)<br /> since the TSC behaves a bit differently. <br /> <br /> If you want support for the watchdog or the GPIO pins in a 2.4 kernel,<br /> you can find an old patch from me at:<br /> <br /> http://groups.google.com/groups?selm=20020226015215.20118F5B%40acolyte.hack.org&amp;oe=UTF-8&amp;output=gplain<br /> <br /> An updated version of this patch has been included in Linux 2.5. Alan<br /> Cox' 2.5 kernel also has support for doing DMA on the SC1200 IDE<br /> controller; I don't know if there is a corresponding patch for 2.4. <br /> <br /> Other than that, take a look at the freebios/src/mainboard/nano/nano<br /> directory and make a copy of it. All you should have to do is to<br /> modify the Pin Multiplexing Register (PMR) and Miscellaneous Config<br /> Register (MCR) in the Config file and to modify the irq assignments.<br /> <br /> Depending on what you want to do, there are a few limitations with<br /> the current LinuxBIOS on the SC1200: <br /> <br /> There is no video support in LinuxBIOS itself, so you won't get<br /> any video until you have loaded the NatSemi Geode Linux<br /> framebuffer driver (can be found at www.linux4.tv under the<br /> heading SP1SC10 Platform Image).<br /> <br /> There is no SMM/VSA support at all, this means that anything<br /> relying on it won't work. What this means is that Audio won't<br /> work.<br /> <br /> Other than that everything works fine, IDE in PIO mode, the PCI bus,<br /> watchdog, GPIOs, everything.<br /> <br /> /Christer<br /> <br /> -- <br /> &quot;Just how much can I get away with and still go to heaven?&quot;<br /> <br /> Freelance consultant specializing in device driver programming for Linux <br /> Christer Weinigel http://www.weinigel.se<br /> _______________________________________________<br /> Linuxbios mailing list<br /> Linuxbios@clustermatic.org<br /> http://www.clustermatic.org/mailman/listinfo/linuxbios<br /> <br /> <br /> === How do I set up testbios? ===<br /> <br /> From daubin@actuality-systems.com Wed Oct 6 10:23:10 2004<br /> Date: Tue, 5 Oct 2004 15:19:24 -0400<br /> From: Dave Aubin <br /> To: linuxbios@clustermatic.org<br /> Subject: RE: Testbios help with nvidia 6800Gt and simple how to<br /> <br /> I've taken the time to put together a simple testbios faq.<br /> I hope it is helpful. Feedback and additions are welcome. <br /> <br /> Thanks,<br /> Dave<br /> <br /> ==== Testbios (vgabios) Faq ====<br /> <br /> Date: 10/5/2004<br /> Author(s): David Aubin daubin@actuality-systems.com<br /> <br /> Purpose: Testbios is an i386 emulator that sits on top of userspace linux. It's primary purpose is to provide program video rom's in to the cached memory area.<br /> <br /> ===== Where to obtain testbios =====<br /> <br /> Testbios(vgabios) can be retrieved from the linuxbios/freebios source tree: [http://www.linuxbios.org/developer/download/index.html]<br /> <br /> ===== Prerequisites =====<br /> <br /> You must have installed pci-utils<br /> * Get http://atrey.karlin.mff.cuni.cz/~mj/pciutils.shtml<br /> <br /> ===== How to build testbios =====<br /> * cd freebios/util/vgabios<br /> * Edit ./Makefile and fill in the correct values for your environment (I build on a 64 AMD so my makefile looks like this)<br /> <br /> Begin ./Makefile for x64:<br /> CC = gcc<br /> ARCH := $(shell uname -m | sed -e s,i[3456789]86,i386,)<br /> INCLUDE = -I ../pciutils-2.1.11<br /> CFLAGS = -Wall -Ix86emu/include -O2 -g $(INCLUDE)<br /> <br /> INTOBJS = int10.o int15.o int16.o int1a.o inte6.o<br /> OBJECTS = testbios.o helper_exec.o helper_mem.o $(INTOBJS)<br /> LDFLAGS = -static-libgcc -static<br /> <br /> LIBS = x86emu/src/x86emu/libx86emu.a ../pciutils-2.1.11/lib/libpci.a<br /> <br /> # user space pci is the only option right now.<br /> OBJECTS += pci-userspace.o<br /> <br /> ifeq ($(shell if test &quot;$(ARCH)&quot; == &quot;x86_64&quot; ; then echo 1; fi), 1)<br /> CFLAGS +=-m32 -march=i386<br /> endif<br /> <br /> all: testbios<br /> <br /> testbios: $(OBJECTS) $(LIBS)<br /> $(CC) $(CFLAGS) -o testbios $(OBJECTS) $(LDFLAGS)<br /> $(LIBS)<br /> <br /> helper_exec.o: helper_exec.c test.h<br /> <br /> x86emu/src/x86emu/libx86emu.a:<br /> $(MAKE) -C x86emu/src/x86emu/ -f makefile.linux<br /> <br /> clean:<br /> $(MAKE) -C x86emu/src/x86emu/ -f makefile.linux clean<br /> rm -f *.o *~ testbios <br /> <br /> distclean: clean<br /> $(MAKE) -C x86emu/src/x86emu/ -f makefile.linux clean<br /> <br /> <br /> End ./Makefile<br /> <br /> * Edit ~vgabios/x86emu/src/x86emu/makefile.linux and fill in the correct values for your environment (I build on a 64 AMD so my makefile looks like this)<br /> <br /> Begin ~vgabios/x86emu/src/x86emu/makefile.linux:<br /> #############################################################################<br /> #<br /> # Realmode X86 Emulator Library<br /> #<br /> # Copyright (C) 1996-1999 SciTech Software, Inc.<br /> #<br /> #<br /> &lt;nowiki&gt;========================================================================&lt;/nowiki&gt;<br /> #<br /> # Permission to use, copy, modify, distribute, and sell this software and<br /> # its documentation for any purpose is hereby granted without fee,<br /> # provided that the above copyright notice appear in all copies and that<br /> # both that copyright notice and this permission notice appear in<br /> # supporting documentation, and that the name of the authors not be used<br /> # in advertising or publicity pertaining to distribution of the software<br /> # without specific, written prior permission. The authors makes no<br /> # representations about the suitability of this software for any purpose.<br /> # It is provided &quot;as is&quot; without express or implied warranty.<br /> #<br /> # THE AUTHORS DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,<br /> # INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO<br /> # EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR<br /> # CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF<br /> # USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR<br /> # OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR<br /> # PERFORMANCE OF THIS SOFTWARE.<br /> #<br /> #<br /> &lt;nowiki&gt;========================================================================&lt;/nowiki&gt;<br /> #<br /> # Descripton: Linux specific makefile for the x86emu library.<br /> #<br /> #############################################################################<br /> <br /> TARGETLIB = libx86emu.a<br /> <br /> <br /> OBJS=\<br /> debug.o \<br /> decode.o \<br /> fpu.o \<br /> ops.o \<br /> ops2.o \<br /> prim_ops.o \<br /> sys.o<br /> <br /> $(TARGETLIB): $(OBJS)<br /> ar rv $(TARGETLIB) $(OBJS)<br /> <br /> INCS = -I. -Ix86emu -I../../include<br /> CFLAGS += -D__DRIVER__ -DFORCE_POST -D_CEXPORT= -DNO_LONG_LONG -DDEBUG<br /> ARCH := $(shell uname -m | sed -e s,i[3456789]86,i386,)<br /> ifeq ($(shell if test &quot;$(ARCH)&quot; == &quot;x86_64&quot; ; then echo 1; fi), 1)<br /> CFLAGS +=-m32 -march=i386<br /> endif<br /> <br /> <br /> .c.o:<br /> # gcc -m32 -march=i386 -g -O -Wall -c $(CFLAGS) $(INCS) $*.c<br /> gcc -g -O -Wall -c $(CFLAGS) $(INCS) $*.c<br /> <br /> .cpp.o:<br /> # gcc -m32 -march=i386 -c $(CFLAGS) $(INCS) $*.cpp<br /> gcc -c $(CFLAGS) $(INCS) $*.cpp <br /> <br /> clean:<br /> rm -f *.a *.o<br /> <br /> validate: validate.o libx86emu.a<br /> gcc -o validate validate.o -lx86emu -L.<br /> <br /> End ~vgabios/x86emu/src/x86emu/makefile.linux<br /> <br /> * Once built you could have a 32bit testbios executable made. Depending on your embedded environment you might want to have it built shared as the above example makes it static. Just remove -static-libgcc -static from the LDFLAGS on ./Makefile if you wish to have it built shared.<br /> <br /> ===== How to retrieve a good video bios =====<br /> There are sites that have video bios roms on their website. (I know of this one for nvidia cards: [http://whitebunny.demon.nl/hardware/chipset_nvidia.html])<br /> <br /> However you should be able to retrieve your own video bios as well with linux.<br /> * Boot up a machine with a commercial bios (not linux bios) with the video card you wish to work under linux bios.<br /> ** From the command line enter:&lt;br /&gt;&lt;code&gt;dd if=/dev/mem of=vgabios.bin skip=1536 count=128 or &lt;br /&gt;dd if=/dev/mem of=vgabios.bin bs=1k count=64 skip=786432&lt;br /&gt;This assumes you card's bios is cached in 0xc0000. You&lt;br /&gt;can see where and how much your card's bios is using by&lt;br /&gt;doing a cat iomem | grep &quot;Video ROM&quot;&lt;br /&gt;&lt;/code&gt;<br /> *** dd Explained (man dd to learn more):<br /> **** if is the location to retrieve from.<br /> **** of is the output file (your rom image)<br /> **** skip jumps n blocks where the default n is 512 bytes<br /> **** count is how many blocks you wish to read<br /> **** bs is the block size<br /> ** You now have a video bios image<br /> <br /> ===== How to use testbios =====<br /> * Currently testbios only works from user space linux (10/4/04)<br /> * Example from a linux command line or script enter the following to get your video bios programmed:&lt;br /&gt;&lt;code&gt;./testbios -s 65536 --abseg /dev/mem ./vgabios.bin&lt;/code&gt;<br /> ** Testbios explained<br /> *** -s how much of the video bios is there<br /> *** --abseg where would you like to write this (/dev/mem default)<br /> *** filename of video bios<br /> *** -d diag mode <br /> **** How to get pci busdevfn<br /> **** lspci<br /> **** look for your video card<br /> ***** Example:&lt;br /&gt;&lt;code&gt;2:00:00&lt;br /&gt;2 (00 &lt;&lt; 3) | 00 = 0x200&lt;/code&gt;<br /> ***** Example:&lt;br /&gt;&lt;code&gt;00:12.0:&lt;br /&gt;0 (12 &lt;&lt; 3) | 0 = 0x90&lt;/code&gt;<br /> *** -t dump <br /> *** -c codesegment Where do you want to start, default is 0xc0000<br /> *** -b base Where do you want base to be default is 0xc000<br /> *** -i instruction pointer usually left off as the default<br /> <br /> ==== Followup to Testbios FAQ ====<br /> -----Original Message-----<br /> From: linuxbios-admin@clustermatic.org<br /> [mailto:linuxbios-admin@clustermatic.org] On Behalf Of Dave Aubin<br /> Sent: Tuesday, October 05, 2004 2:22 PM<br /> To: Richard Smith<br /> Cc: linuxbios@clustermatic.org<br /> Subject: RE: Testbios help with nvidia 6800Gt and simple how to<br /> <br /> Hi,<br /> <br /> Thank you:) Yes, it was at 0xc0000-0xc7fff, which is only 32k.<br /> But the image I got from the windows tool was 64k (double 8000).<br /> Weird. I would like to stay away from window tools.<br /> The info you provided is nice. I wish there was a way for us To make<br /> a faq and we could add this to the testbios faq. There Is a lot of good<br /> info on the clustermatic list, but it is all Dispersed. <br /> Ron if I write a simple faq can you provide some mechanism to Allow<br /> updates to it?<br /> <br /> Thanks,<br /> Dave <br /> <br /> -----Original Message-----<br /> From: Richard Smith [mailto:rsmith@bitworks.com]<br /> Sent: Tuesday, October 05, 2004 2:16 PM<br /> To: Dave Aubin<br /> Cc: linuxbios@clustermatic.org<br /> Subject: Re: Testbios help with nvidia 6800Gt and simple how to<br /> <br /> Dave Aubin wrote:<br /> <br /> &gt; It seems my dd returned an unusable binary. I found a good binary for<br /> <br /> &gt; The nvidia card from here:<br /> &gt; http://whitebunny.demon.nl/hardware/chipset_nvidia.html<br /> &gt; <br /> <br /> I was wondering about your dd command that but I had not had a chance to<br /> respond yet.<br /> <br /> This is what I use:<br /> <br /> dd if=/dev/mem of=vbios.bin bs=1k count=64 skip=786432<br /> <br /> That will rip the bios from 0x0c0000. You can verify that you actually<br /> have bios there with<br /> <br /> 'hd -s 0x0c0000 -n 256 /dev/mem'<br /> <br /> in some cases it may be located at 0x0e0000 rather than 0x0c0000.<br /> <br /> It should start with the 0x55aa (Little endian) or 0xaa55 (big endian)<br /> and futher on you should see some text identifying the bios.<br /> <br /> <br /> --<br /> Richard A. Smith<br /> <br /> <br /> _______________________________________________<br /> Linuxbios mailing list<br /> Linuxbios@clustermatic.org<br /> http://www.clustermatic.org/mailman/listinfo/linuxbios</div>

Rminnich http://www.coreboot.org/Payloads 2005-03-01T22:07:53Z

<p>Rminnich: </p> <hr /> <div>LinuxBIOS in itself is &quot;only&quot; minimal code for initializing a<br /> mainboard with peripherals just enough for a Linux kernel to take<br /> over and to the rest. LinuxBIOS does not contain a kernel per se.<br /> <br /> After the initialization, LinuxBIOS jumps to a payload and while<br /> there has been discussion about stacking payloads that's currently<br /> not in practice.<br /> <br /> The payload was originally intended to be a Linux kernel stored in<br /> flash. Flash ROM growth rate was anticipated optimistically however,<br /> today there are not many mainboards that actually have enough flash<br /> ROM room for a kernel. 512KB can be seen here-and-there and a few<br /> boards come with 1MB. Recent kernels really want that MB, and then<br /> you'll only have room for 3-400 KB of initial ramdisk, which could<br /> be too small too, depending on the application.<br /> <br /> So, other payloads are used; the two major ones are FILO and<br /> Etherboot. FILO loads a kernel from a filesystem on an IDE device and<br /> Etherboot loads a kernel from the network or from a filesystem on an<br /> IDE device.<br /> <br /> If you're using FILO there is no Linux kernel until FILO loads it,<br /> and the kernel loaded by FILO (or Etherboot) can absolutely be the<br /> one you want to run in your system. Just set it up with the correct<br /> root and init commandline so that it can start init.<br /> <br /> <br /> [[Etherboot]] --- it includes FILO, and its FILO support SATA and USB booting.<br /> <br /> [[FILO]] - Simple bootloader with filesystem support<br /> <br /> [http://www.openbios.org OpenBIOS]</div>

Rminnich http://www.coreboot.org/PCCHIPS_M810LR 2005-03-01T17:23:46Z

<p>Rminnich: </p> <hr /> <div>My experience getting LinuxBios working on a PC-Chips M810LR motherboard with an M-Systems Millennium MD-2800-D08 Disk-on-Chip<br /> <br /> <br /> by Antony Stone <br /> <br /> <br /> <br /> Background<br /> <br /> <br /> I first came across LinuxBios at the LBW workshop at Doolin, Ireland, and it seemed like such a great project that I just wanted to get home and build one of my own. <br /> <br /> <br /> Thanks to Lance Davis and John Hearns for supplying hardware, Bill Boughton and Richard Russon for persevering with the software, and Chuck Moss for supplying some DoCs to play with. <br /> <br /> <br /> Even better, I recognised the PC-Chips motherboard they were using there - an M810LMR, and I knew I had two of these in systems already. So all I had to do was get myself a Disk-on-Chip device, and I'd have an instant-booting system, right ? <br /> <br /> <br /> Well, things were not quite so simple as that, so after managing to get my system working from a combination of: <br /> <br /> reading what documentation I could find <br /> knowing that I'd seen one working already <br /> guesswork and reading bits of the source code <br /> invaluable help and assistance from Ron Minnich and Andrew Ip <br /> <br /> I decided to write up my experiences to let other people know what I had to do to get things working, in the hope that this may make it easier for other people later on. <br /> <br /> <br /> <br /> Vendors<br /> <br /> <br /> It seems that PC-Chips have recently (August 2002) decided to rename their motherboard product range, so this is going to lead to even more confusion over which particular board you are working with. <br /> <br /> <br /> However, PC-Chips does appear to be one of the more helpful motherboard vendors as far as the LinuxBios project is concerned, and they certainly do seem to make some good value-for-money highly-integrated motherboards. <br /> <br /> <br /> The Disk-on-Chip devices are something I'd never worked with before, and I had no idea where to get them from, either. I live in the UK, so I simply went to M-Systems' website and looked for UK or European distributors. There were two distributors listed for the UK, so I phoned them up, and bought three MD-2800-D08 devices from one of them. I have my own company, so I qualified as a trade customer. I have no idea where you would buy these as a private individual, but I'll stick my neck out here and say that anyone who has trouble getting the Millennium DoC devices in the UK can email me and I'll try to help. <br /> <br /> <br /> As well as PC-Chips renumbering their motherboards, it also turns out that M-Systems are discontinuing the MD-2800 series and replacing them with the MD-2802 range, which are apparently &quot;hardware and software interchangeable&quot;. The MD-2800 devices are being discontinued, but the MD-2802 should work identically in all designs. I bought the last three MD-2800s the supplier had :-) <br /> <br /> <br /> <br /> Getting started<br /> <br /> <br /> So, I had a motherboard, and a Disk-on-Chip device. How to get LinuxBios up and running ? <br /> <br /> <br /> The first thing is to read the LinuxBios FAQ and the documentation for the SiS630 motherboards. This should give you a good idea of the overall process, and the steps involved. <br /> <br /> <br /> The steps listed in the documentation are:<br /> (Note: the following list should be numbered from 0 to 8 (as should the next list further down) for consistency with the original documentation. If your browser shows a list numbered from 1 to 9, you may want to consider updating it.) <br /> <br /> Get Linux installed on your LinuxBios machine <br /> <br /> Get LinuxBios source from the sourceforge <br /> <br /> Get a 2.4 kernel, patch it, then build it <br /> <br /> Configure and build LinuxBios <br /> <br /> Get the MTD utilities from http://www.linux-mtd.infradead.org and build the 'erase' utility <br /> <br /> Set up the 'flash_on' program in your path <br /> <br /> Remove the Bios from its socket and put a Disk-on-Chip in its place <br /> <br /> Burn the LinuxBios image into the Disk-on-Chip <br /> <br /> Hit reset. <br /> <br /> The details<br /> <br /> Step 0 should be easy enough for people who are attempting LinuxBios in the first place, however note that the kernel you are running must have support for MTD (Memory Technology Devices), which most people won't have turned on as standard. <br /> <br /> Therefore you should recompile your kernel on your machine with modules enabled (I generally don't use a modular kernel, but for programming the DoC devices in the Bios socket of the motherboard, you have to run a command before loading the DoC modules, therefore you can't compile this support directly into the kernel), and support for the Millennium DoC devices. <br /> <br /> <br /> I generally use 'make menuconfig' to configure my kernel; here are the options you need to select (accurate for a 2.4.19 kernel) in order to build LinuxBios into a DoC device: <br /> <br /> Loadable module support<br /> [*] Enable loadable module support<br /> [ ] Set version information on all module symbols<br /> [*] Kernel module loader<br /> <br /> Memory Technology Devices (MTD)<br /> &lt;M&gt; Memory Technology Device (MTD) support<br /> [ ] Debugging<br /> &lt; &gt; MTD partitioning support<br /> &lt; &gt; MTD concatenating support<br /> --- User Modules and Transition Layers<br /> &lt;M&gt; Direct char device access to MTD devices<br /> &lt; &gt; Caching block device access to MTD devices<br /> &lt; &gt; Readonly block device access to MTD devices<br /> &lt; &gt; FTL (Flash Transition Layer) support<br /> &lt; &gt; NFTL (NAND Flash Transition Layer) support<br /> RAM/ROM/Flash chip drivers ---&gt;<br /> Mapping drivers for chip access ---&gt;<br /> Self-contained MTD device drivers ---&gt;<br /> &lt; &gt; Ramix PMC551 PCI Mezzanine RAM card support<br /> &lt; &gt; Uncached system RAM<br /> &lt; &gt; Test driver using RAM<br /> &lt; &gt; MTD emulation using block device<br /> --- Disk-On-Chip Device Drivers<br /> &lt; &gt; M-Systems Disk-On-Chip 1000<br /> &lt; &gt; M-Systems Disk-On-Chip 2000 and Millennium<br /> &lt;M&gt; M-Systems Disk-On-Chip Millennium-only alternative driver<br /> [*] Advanced detection options for DiskOnChip<br /> (0) Physical address of DiskOnChip<br /> [*] Probe high addresses<br /> [ ] Probe for 0x55 0xAA BIOS Extension Signature<br /> <br /> NAND Flash Device Drivers ---&gt;<br /> <br /> <br /> There is also a highly impressive 'gotcha' in the MTD driver support - you must edit one of the kernel source files before compiling with MTD support, in order to be able to write (ie erase or program) the DoC devices. If you do not do this you will get errors when you try to erase or program the device, such as: <br /> <br /> <br /> /dev/mtd0: No such device<br /> /dev/mtd0: Bad file descriptor<br /> <br /> <br /> The change required is in /usr/src/linux/drivers/mtd/devices/docprobe.c <br /> <br /> <br /> Change the line which reads: <br /> <br /> #define DOC_SINGLE_DRIVER<br /> <br /> so that it becomes: <br /> #undef DOC_SINGLE_DRIVER<br /> <br /> You may want to read the comment just above the line you're editing, and be grateful that someone told you where to find this file to change it.... <br /> <br /> You also need to have Python installed on your system, because the LinuxBios build process is based around a Python program. <br /> <br /> <br /> It is also highly recommended that you install a 32-pin ZIF (Zero Insertion Force) socket on your motherboard, because later on you will need to swap chips in the Bios socket while the motherboard is powered on. This is not something you want to make any mistakes with, eg using a metal tool, getting the Bios or DoC pins misaligned or bent, shorting out some nearby components or connectors... <br /> <br /> <br /> Note the orientation of the Bios chip in its socket (there is a notch at one end, or a dot in one corner, of the chip), remove the chip, and plug a 32-pin ZIF socket into the motherboard socket (you will probably need to bend the pins of some nearby connectors to get it to fit - I found an unused 3-pin fan connector in the way). Place the lever of the ZIF socket at the end where the notch or dot was on the Bios chip. Make sure you plug the ZIF socket cleanly into all 32 holes on the socket on the motherboard - it's easy to miss a couple of pins at one end and get the whole thing moved along one place. You will probably want to do this with the motherboard not installed in a case, so you can look underneath the ZIF socket as you are inserting it. <br /> <br /> <br /> Once the ZIF socket is in place, lift the lever, insert the original Bios chip (notch or dot at the lever end of the socket) and lower the lever to secure the chip in place. <br /> <br /> <br /> If you see the usual Bios startup screen when you power on your motherboard, then you know you've done this bit correctly, and you can easily swap the chips over later on in the instructions. <br /> <br /> <br /> Get the LinuxBios source by CVS: <br /> <br /> export CVS_RSH=ssh<br /> cvs -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios login<br /> cvs -z3 -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios co freebios<br /> <br /> <br /> (Press return at the password prompt and ignore errors about &quot;failed to open ./cvspass for reading&quot; and even &quot;login aborted: fatal error: exiting&quot;. Press on regardless.) <br /> <br /> <br /> Before you get a fresh kernel source to patch with LinuxBios, check the LinuxBios kernel patches to see which kernel version is supported for your motherboard / chipset. You may be able to apply the patches to a different kernel, but at this stage in the game it's probably best to build an old kernel strictly by the instructions, and make sure you can get LinuxBios working at all, and then afterwards you can try to bring the kernel up to the version you'd like it to be. <br /> <br /> I used kernel version 2.4.19 because (a) this was already installed on my machine, and (b) there was a linux-2.4.19-sis.patch file available, which matched my motherboard. <br /> <br /> <br /> You can find the kernel patches in the FreeBios source you just downloaded from CVS by looking in freebios/src/kernel-patches This directory contains both the patches for the kernels, and also the config files for building the new kernel (note that not all these are guaranteed to work in all situations - you may need to look at other config files and make some manual adjustments to get your particular setup working). <br /> <br /> <br /> Note that the kernel patches and config files are for the kernel you will program into the DoC device and eventually boot your machine from. They may not be the best choice for the kernel you use to build LinuxBios and burn the DoC before trying to boot it. <br /> <br /> <br /> When you build the kernel, use 'make bzImage' and then just leave the kernel where it is. LinuxBios will later look for the file /usr/src/linux/vmlinux <br /> <br /> <br /> LinuxBios was developed from an earlier project called FreeBios, and therefore the source code you have downloaded is in a directory called 'freebios' <br /> <br /> You need to create your own config file, and make the build images for programming into the DoC device, in a different directory so that they are not deleted when you update your copy of the source code from the CVS repository. <br /> <br /> <br /> Because of the way the directory names worked out, I chose to create a new directory called 'linuxbios' side by side with 'freebios', and built my DoC images in there. <br /> <br /> <br /> Here is what I did to build LinuxBios: <br /> <br /> mkdir linuxbios<br /> cd linuxbios<br /> cp ../freebios/util/config/NLBConfig.py .<br /> cp ../freebios/util/config/pcchips.config .<br /> <br /> I then edited pcchips.config, making the following changes: <br /> Removed 'single' from the end of the kernel commandline, because I wanted my machine to boot into standard multiuser mode <br /> Added 'cpu k7' because I'm using an Athlon processor <br /> Added 'option ENABLE_MII=1' to get the onboard ethernet working (Thanks to Andrew Ip for telling me how to do this) <br /> Changed 'option HAVE_FRAMEBUFFER' to 'option HAVE_FRAMEBUFFER=1' (this eliminates a warning message later but is not essential) <br /> <br /> I also edited one of the LinuxBios source files in order to get the keyboard working on my motherboard (again, thanks to Andrew Ip for this): <br /> <br /> <br /> In the file freebios/src/arch/i386/lib/hardwaremain.c uncomment the function call keyboard_on() around line 344. If you do not do this, then when you finally boot your LinuxBios machine, you will get several hundred error messages &quot;pc_keyb: controller jammed (0xFF)&quot;, and your keyboard will not work. It will not stop your LinuxBios system from working, however - you will still be able to log in on the serial port, and ssh across the network. <br /> <br /> <br /> I then ran the Python program to create the build files: <br /> <br /> python NLBConfig.py pcchips.config ~/freebios<br /> <br /> This creates a subdirectory within linuxbios (where you are now) called pcchips, and creates the following files in it: <br /> <br /> LinuxBIOSDoc.config<br /> <br /> Makefile<br /> <br /> Makefile.settings<br /> <br /> crt0_includes.h<br /> <br /> nsuperio.c<br /> <br /> Once you have these files, and you have compiled your target kernel (which is then sitting in /usr/src/linux/vmlinux), you can run the makefile and build your LinuxBios image: <br /> <br /> cd pcchips<br /> <br /> make<br /> <br /> Note that if this is not the first time you're building the image, you may want to do a 'make clean' before the 'make'. <br /> <br /> I then copied the 'burn_mtd' utility into the newly-created pcchips directory, because by default it looks in the current directory for the source files to burn into the DoC device, so there's a lot less typing if the utility is in the same place. <br /> <br /> cp ../../freebios/util/mtd/burn_mtd .<br /> <br /> I made a couple of changes to the burn_mtd utility, in order to match the filenames generated by the Makefile a few moments ago: <br /> <br /> Change the first two occurrences of 'vmlinux' (one in the comment on line 3, the other in 'linux=vmlinux.bin.gz' on line 16) to 'linux' (so that line 16 now reads 'linux=linux.bin.gz'). <br /> <br /> <br /> Building the MTD 'erase' utility was pretty straightforward - I assume you'll have no problems here. <br /> <br /> Go into the freebios/util/sis directory and build the 'flash_on' utility by doing: <br /> make flash_on<br /> <br /> Copy the 'erase' and 'flash_on' utilities which you just built into your search path (I put them into /usr/local/sbin) <br /> <br /> This is the point where you are grateful you got yourself a 32-pin ZIF socket and plugged it into your motherboard. <br /> <br /> While the power is on and your system is running, release the lever on the ZIF socket, remove the original Flash Bios chip, replace it with a DoC (check the orientation ! The notch in the end of the chip goes at the lever end of the socket), and secure it in place with the lever. <br /> <br /> <br /> Run the command<br /> <br /> ./burn_mtd<br /> <br /> and with any luck it will program a LinuxBios chip for you ! <br /> <br /> The output of burn_mtd should look like this: <br /> <br /> # ./burn_mtd<br /> rmmod: module docprobe is not loaded<br /> rmmod: module doc2001 is not loaded<br /> rmmod: module docecc is not loaded<br /> 11+1 records in<br /> 12+0 records out<br /> 0+1 records in<br /> 1+0 records out<br /> Erase Total 1024 Units<br /> Performing Flash Erase of length 8192 at offset 0x7fe000 done<br /> 1+0 records in<br /> 1+0 records out<br /> 1+0 records in<br /> 1+0 records out<br /> 126+0 records in<br /> 126+0 records out<br /> 1536+0 records in<br /> 1536+0 records out<br /> # <br /> <br /> If at this stage you get the following instead: <br /> # ./burn_mtd<br /> rmmod: module docprobe is not loaded<br /> rmmod: module doc2001 is not loaded<br /> rmmod: module docecc is not loaded<br /> 11+1 records in<br /> 12+0 records out<br /> 0+1 records in<br /> 1+0 records out<br /> File open error<br /> dd: opening '/dev/mtd0': No such device<br /> dd: opening '/dev/mtd0': No such device<br /> dd: opening '/dev/mtd0': No such device<br /> dd: opening '/dev/mtd0': No such device<br /> # <br /> <br /> then you should check that you selected the correct MTD options when building your development kernel (you did reboot after building that so you're running it now, right ?), and also that you edited the file /usr/src/linux/drivers/mtd/devices/docprobe.c to undefine DOC_SINGLE_DRIVER before building that kernel. <br /> <br /> Press reset. <br /> <br /> If your system reboots and you see a penguin in the top corner of your screen instead of an AMI or Award Bios startup message, then you should jump up and down, punch the air, say things like &quot;Wow!&quot;, and generally be pleased with yourself. <br /> <br /> <br /> Problems?<br /> <br /> Do not worry if bits of the system do seem to get started properly (eg hard disk, ethernet, keyboard, root filing system...). They can almost certainly get sorted out later. <br /> <br /> If you do not get a penguin on your screen (in fact, you get nothing at all), then try plugging a serial cable into your RS232 port (the M810LR boards only have one RS232 port), connect a terminal emulator set to 115200 baud, 8 bits, no parity, and press reset again. You should get some debugging information and general startup message out of the serial port which might help you or someone else to work out what's not quite right. <br /> <br /> <br /> If absolutely nothing happens, then it's possible that you haven't got a suitable image burned into the DoC, so power off the motherboard, remove the DoC and put the original Bios back in again, power the system back up, and see if you've missed something from the above instructions. <br /> <br /> <br /> If you think I've missed something from these instructions, then please email me so I can update them for other users. <br /> <br /> <br /> For general help with LinuxBios, there is a current mailing list at http://www.clustermatic.org/mailman/listinfo/linuxbios and archives of earlier lists at http://www.acl.lanl.gov/linuxbios/faq/archive and http://www.missl.cs.umd.edu/archives/linuxbios. <br /> <br /> <br /> Good luck. <br /> <br /> <br /> -- <br /> <br /> <br /> Antony Stone.</div>

Rminnich http://www.coreboot.org/PCCHIPS_M810LR 2005-03-01T17:22:52Z

<p>Rminnich: </p> <hr /> <div>My experience getting LinuxBios working on a PC-Chips M810LR motherboard with an M-Systems Millennium MD-2800-D08 Disk-on-Chip<br /> <br /> <br /> by Antony Stone <br /> <br /> <br /> <br /> Background<br /> <br /> <br /> I first came across LinuxBios at the LBW workshop at Doolin, Ireland, and it seemed like such a great project that I just wanted to get home and build one of my own. <br /> <br /> <br /> Thanks to Lance Davis and John Hearns for supplying hardware, Bill Boughton and Richard Russon for persevering with the software, and Chuck Moss for supplying some DoCs to play with. <br /> <br /> <br /> Even better, I recognised the PC-Chips motherboard they were using there - an M810LMR, and I knew I had two of these in systems already. So all I had to do was get myself a Disk-on-Chip device, and I'd have an instant-booting system, right ? <br /> <br /> <br /> Well, things were not quite so simple as that, so after managing to get my system working from a combination of: <br /> <br /> reading what documentation I could find <br /> knowing that I'd seen one working already <br /> guesswork and reading bits of the source code <br /> invaluable help and assistance from Ron Minnich and Andrew Ip <br /> <br /> I decided to write up my experiences to let other people know what I had to do to get things working, in the hope that this may make it easier for other people later on. <br /> <br /> <br /> <br /> Vendors<br /> <br /> <br /> It seems that PC-Chips have recently (August 2002) decided to rename their motherboard product range, so this is going to lead to even more confusion over which particular board you are working with. <br /> <br /> <br /> However, PC-Chips does appear to be one of the more helpful motherboard vendors as far as the LinuxBios project is concerned, and they certainly do seem to make some good value-for-money highly-integrated motherboards. <br /> <br /> <br /> The Disk-on-Chip devices are something I'd never worked with before, and I had no idea where to get them from, either. I live in the UK, so I simply went to M-Systems' website and looked for UK or European distributors. There were two distributors listed for the UK, so I phoned them up, and bought three MD-2800-D08 devices from one of them. I have my own company, so I qualified as a trade customer. I have no idea where you would buy these as a private individual, but I'll stick my neck out here and say that anyone who has trouble getting the Millennium DoC devices in the UK can email me and I'll try to help. <br /> <br /> <br /> As well as PC-Chips renumbering their motherboards, it also turns out that M-Systems are discontinuing the MD-2800 series and replacing them with the MD-2802 range, which are apparently &quot;hardware and software interchangeable&quot;. The MD-2800 devices are being discontinued, but the MD-2802 should work identically in all designs. I bought the last three MD-2800s the supplier had :-) <br /> <br /> <br /> <br /> Getting started<br /> <br /> <br /> So, I had a motherboard, and a Disk-on-Chip device. How to get LinuxBios up and running ? <br /> <br /> <br /> The first thing is to read the LinuxBios FAQ and the documentation for the SiS630 motherboards. This should give you a good idea of the overall process, and the steps involved. <br /> <br /> <br /> The steps listed in the documentation are:<br /> (Note: the following list should be numbered from 0 to 8 (as should the next list further down) for consistency with the original documentation. If your browser shows a list numbered from 1 to 9, you may want to consider updating it.) <br /> <br /> Get Linux installed on your LinuxBios machine <br /> <br /> Get LinuxBios source from the sourceforge <br /> <br /> Get a 2.4 kernel, patch it, then build it <br /> <br /> Configure and build LinuxBios <br /> <br /> Get the MTD utilities from http://www.linux-mtd.infradead.org and build the 'erase' utility <br /> <br /> Set up the 'flash_on' program in your path <br /> <br /> Remove the Bios from its socket and put a Disk-on-Chip in its place <br /> <br /> Burn the LinuxBios image into the Disk-on-Chip <br /> <br /> Hit reset. <br /> <br /> The details<br /> <br /> Step 0 should be easy enough for people who are attempting LinuxBios in the first place, however note that the kernel you are running must have support for MTD (Memory Technology Devices), which most people won't have turned on as standard. <br /> <br /> Therefore you should recompile your kernel on your machine with modules enabled (I generally don't use a modular kernel, but for programming the DoC devices in the Bios socket of the motherboard, you have to run a command before loading the DoC modules, therefore you can't compile this support directly into the kernel), and support for the Millennium DoC devices. <br /> <br /> <br /> I generally use 'make menuconfig' to configure my kernel; here are the options you need to select (accurate for a 2.4.19 kernel) in order to build LinuxBios into a DoC device: <br /> <br /> Loadable module support<br /> [*] Enable loadable module support<br /> [ ] Set version information on all module symbols<br /> [*] Kernel module loader<br /> <br /> Memory Technology Devices (MTD)<br /> &lt;M&gt; Memory Technology Device (MTD) support<br /> [ ] Debugging<br /> &lt; &gt; MTD partitioning support<br /> &lt; &gt; MTD concatenating support<br /> --- User Modules and Transition Layers<br /> &lt;M&gt; Direct char device access to MTD devices<br /> &lt; &gt; Caching block device access to MTD devices<br /> &lt; &gt; Readonly block device access to MTD devices<br /> &lt; &gt; FTL (Flash Transition Layer) support<br /> &lt; &gt; NFTL (NAND Flash Transition Layer) support<br /> RAM/ROM/Flash chip drivers ---&gt;<br /> Mapping drivers for chip access ---&gt;<br /> Self-contained MTD device drivers ---&gt;<br /> &lt; &gt; Ramix PMC551 PCI Mezzanine RAM card support<br /> &lt; &gt; Uncached system RAM<br /> &lt; &gt; Test driver using RAM<br /> &lt; &gt; MTD emulation using block device<br /> --- Disk-On-Chip Device Drivers<br /> &lt; &gt; M-Systems Disk-On-Chip 1000<br /> &lt; &gt; M-Systems Disk-On-Chip 2000 and Millennium<br /> &lt;M&gt; M-Systems Disk-On-Chip Millennium-only alternative driver<br /> [*] Advanced detection options for DiskOnChip<br /> (0) Physical address of DiskOnChip<br /> [*] Probe high addresses<br /> [ ] Probe for 0x55 0xAA BIOS Extension Signature<br /> <br /> NAND Flash Device Drivers ---&gt;<br /> <br /> <br /> There is also a highly impressive 'gotcha' in the MTD driver support - you must edit one of the kernel source files before compiling with MTD support, in order to be able to write (ie erase or program) the DoC devices. If you do not do this you will get errors when you try to erase or program the device, such as: <br /> <br /> <br /> /dev/mtd0: No such device<br /> /dev/mtd0: Bad file descriptor<br /> <br /> <br /> The change required is in /usr/src/linux/drivers/mtd/devices/docprobe.c <br /> <br /> <br /> Change the line which reads: <br /> <br /> #define DOC_SINGLE_DRIVER<br /> <br /> so that it becomes: <br /> #undef DOC_SINGLE_DRIVER<br /> <br /> You may want to read the comment just above the line you're editing, and be grateful that someone told you where to find this file to change it.... <br /> <br /> You also need to have Python installed on your system, because the LinuxBios build process is based around a Python program. <br /> <br /> <br /> It is also highly recommended that you install a 32-pin ZIF (Zero Insertion Force) socket on your motherboard, because later on you will need to swap chips in the Bios socket while the motherboard is powered on. This is not something you want to make any mistakes with, eg using a metal tool, getting the Bios or DoC pins misaligned or bent, shorting out some nearby components or connectors... <br /> <br /> <br /> Note the orientation of the Bios chip in its socket (there is a notch at one end, or a dot in one corner, of the chip), remove the chip, and plug a 32-pin ZIF socket into the motherboard socket (you will probably need to bend the pins of some nearby connectors to get it to fit - I found an unused 3-pin fan connector in the way). Place the lever of the ZIF socket at the end where the notch or dot was on the Bios chip. Make sure you plug the ZIF socket cleanly into all 32 holes on the socket on the motherboard - it's easy to miss a couple of pins at one end and get the whole thing moved along one place. You will probably want to do this with the motherboard not installed in a case, so you can look underneath the ZIF socket as you are inserting it. <br /> <br /> <br /> Once the ZIF socket is in place, lift the lever, insert the original Bios chip (notch or dot at the lever end of the socket) and lower the lever to secure the chip in place. <br /> <br /> <br /> If you see the usual Bios startup screen when you power on your motherboard, then you know you've done this bit correctly, and you can easily swap the chips over later on in the instructions. <br /> <br /> <br /> Get the LinuxBios source by CVS: <br /> <br /> export CVS_RSH=ssh<br /> cvs -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios login<br /> cvs -z3 -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios co freebios<br /> <br /> <br /> (Press return at the password prompt and ignore errors about &quot;failed to open ./cvspass for reading&quot; and even &quot;login aborted: fatal error: exiting&quot;. Press on regardless.) <br /> <br /> <br /> Before you get a fresh kernel source to patch with LinuxBios, check the LinuxBios kernel patches to see which kernel version is supported for your motherboard / chipset. You may be able to apply the patches to a different kernel, but at this stage in the game it's probably best to build an old kernel strictly by the instructions, and make sure you can get LinuxBios working at all, and then afterwards you can try to bring the kernel up to the version you'd like it to be. <br /> <br /> I used kernel version 2.4.19 because (a) this was already installed on my machine, and (b) there was a linux-2.4.19-sis.patch file available, which matched my motherboard. <br /> <br /> <br /> You can find the kernel patches in the FreeBios source you just downloaded from CVS by looking in freebios/src/kernel-patches This directory contains both the patches for the kernels, and also the config files for building the new kernel (note that not all these are guaranteed to work in all situations - you may need to look at other config files and make some manual adjustments to get your particular setup working). <br /> <br /> <br /> Note that the kernel patches and config files are for the kernel you will program into the DoC device and eventually boot your machine from. They may not be the best choice for the kernel you use to build LinuxBios and burn the DoC before trying to boot it. <br /> <br /> <br /> When you build the kernel, use 'make bzImage' and then just leave the kernel where it is. LinuxBios will later look for the file /usr/src/linux/vmlinux <br /> <br /> <br /> LinuxBios was developed from an earlier project called FreeBios, and therefore the source code you have downloaded is in a directory called 'freebios' <br /> <br /> You need to create your own config file, and make the build images for programming into the DoC device, in a different directory so that they are not deleted when you update your copy of the source code from the CVS repository. <br /> <br /> <br /> Because of the way the directory names worked out, I chose to create a new directory called 'linuxbios' side by side with 'freebios', and built my DoC images in there. <br /> <br /> <br /> Here is what I did to build LinuxBios: <br /> <br /> mkdir linuxbios<br /> cd linuxbios<br /> cp ../freebios/util/config/NLBConfig.py .<br /> cp ../freebios/util/config/pcchips.config .<br /> <br /> I then edited pcchips.config, making the following changes: <br /> Removed 'single' from the end of the kernel commandline, because I wanted my machine to boot into standard multiuser mode <br /> Added 'cpu k7' because I'm using an Athlon processor <br /> Added 'option ENABLE_MII=1' to get the onboard ethernet working (Thanks to Andrew Ip for telling me how to do this) <br /> Changed 'option HAVE_FRAMEBUFFER' to 'option HAVE_FRAMEBUFFER=1' (this eliminates a warning message later but is not essential) <br /> <br /> I also edited one of the LinuxBios source files in order to get the keyboard working on my motherboard (again, thanks to Andrew Ip for this): <br /> <br /> <br /> In the file freebios/src/arch/i386/lib/hardwaremain.c uncomment the function call keyboard_on() around line 344. If you do not do this, then when you finally boot your LinuxBios machine, you will get several hundred error messages &quot;pc_keyb: controller jammed (0xFF)&quot;, and your keyboard will not work. It will not stop your LinuxBios system from working, however - you will still be able to log in on the serial port, and ssh across the network. <br /> <br /> <br /> I then ran the Python program to create the build files: <br /> <br /> python NLBConfig.py pcchips.config ~/freebios<br /> <br /> This creates a subdirectory within linuxbios (where you are now) called pcchips, and creates the following files in it: <br /> <br /> LinuxBIOSDoc.config<br /> <br /> Makefile<br /> <br /> Makefile.settings<br /> <br /> crt0_includes.h<br /> <br /> nsuperio.c<br /> <br /> Once you have these files, and you have compiled your target kernel (which is then sitting in /usr/src/linux/vmlinux), you can run the makefile and build your LinuxBios image: <br /> <br /> cd pcchips<br /> <br /> make<br /> <br /> Note that if this is not the first time you're building the image, you may want to do a 'make clean' before the 'make'. <br /> <br /> I then copied the 'burn_mtd' utility into the newly-created pcchips directory, because by default it looks in the current directory for the source files to burn into the DoC device, so there's a lot less typing if the utility is in the same place. <br /> <br /> cp ../../freebios/util/mtd/burn_mtd .<br /> <br /> I made a couple of changes to the burn_mtd utility, in order to match the filenames generated by the Makefile a few moments ago: <br /> <br /> Change the first two occurrences of 'vmlinux' (one in the comment on line 3, the other in 'linux=vmlinux.bin.gz' on line 16) to 'linux' (so that line 16 now reads 'linux=linux.bin.gz'). <br /> <br /> <br /> Building the MTD 'erase' utility was pretty straightforward - I assume you'll have no problems here. <br /> <br /> Go into the freebios/util/sis directory and build the 'flash_on' utility by doing: <br /> make flash_on<br /> <br /> Copy the 'erase' and 'flash_on' utilities which you just built into your search path (I put them into /usr/local/sbin) <br /> <br /> This is the point where you are grateful you got yourself a 32-pin ZIF socket and plugged it into your motherboard. <br /> <br /> While the power is on and your system is running, release the lever on the ZIF socket, remove the original Flash Bios chip, replace it with a DoC (check the orientation ! The notch in the end of the chip goes at the lever end of the socket), and secure it in place with the lever. <br /> <br /> <br /> Run the command<br /> <br /> ./burn_mtd<br /> <br /> and with any luck it will program a LinuxBios chip for you ! <br /> <br /> The output of burn_mtd should look like this: <br /> <br /> # ./burn_mtd<br /> rmmod: module docprobe is not loaded<br /> rmmod: module doc2001 is not loaded<br /> rmmod: module docecc is not loaded<br /> 11+1 records in<br /> 12+0 records out<br /> 0+1 records in<br /> 1+0 records out<br /> Erase Total 1024 Units<br /> Performing Flash Erase of length 8192 at offset 0x7fe000 done<br /> 1+0 records in<br /> 1+0 records out<br /> 1+0 records in<br /> 1+0 records out<br /> 126+0 records in<br /> 126+0 records out<br /> 1536+0 records in<br /> 1536+0 records out<br /> # <br /> <br /> If at this stage you get the following instead: <br /> # ./burn_mtd<br /> rmmod: module docprobe is not loaded<br /> rmmod: module doc2001 is not loaded<br /> rmmod: module docecc is not loaded<br /> 11+1 records in<br /> 12+0 records out<br /> 0+1 records in<br /> 1+0 records out<br /> File open error<br /> dd: opening '/dev/mtd0': No such device<br /> dd: opening '/dev/mtd0': No such device<br /> dd: opening '/dev/mtd0': No such device<br /> dd: opening '/dev/mtd0': No such device<br /> # <br /> <br /> then you should check that you selected the correct MTD options when building your development kernel (you did reboot after building that so you're running it now, right ?), and also that you edited the file /usr/src/linux/drivers/mtd/devices/docprobe.c to undefine DOC_SINGLE_DRIVER before building that kernel. <br /> <br /> Press reset. <br /> <br /> If your system reboots and you see a penguin in the top corner of your screen instead of an AMI or Award Bios startup message, then you should jump up and down, punch the air, say things like &quot;Wow!&quot;, and generally be pleased with yourself. <br /> <br /> <br /> Problems?<br /> <br /> Do not worry if bits of the system do seem to get started properly (eg hard disk, ethernet, keyboard, root filing system...). They can almost certainly get sorted out later. <br /> <br /> If you do not get a penguin on your screen (in fact, you get nothing at all), then try plugging a serial cable into your RS232 port (the M810LR boards only have one RS232 port), connect a terminal emulator set to 115200 baud, 8 bits, no parity, and press reset again. You should get some debugging information and general startup message out of the serial port which might help you or someone else to work out what's not quite right. <br /> <br /> <br /> If absolutely nothing happens, then it's possible that you haven't got a suitable image burned into the DoC, so power off the motherboard, remove the DoC and put the original Bios back in again, power the system back up, and see if you've missed something from the above instructions. <br /> <br /> <br /> If you think I've missed something from these instructions, then please email me so I can update them for other users. <br /> <br /> <br /> For general help with LinuxBios, there is a current mailing list at http://www.clustermatic.org/mailman/listinfo/linuxbios and archives of earlier lists at http://www.acl.lanl.gov/linuxbios/faq/archive and http://www.missl.cs.umd.edu/archives/linuxbios. <br /> <br /> <br /> Good luck. <br /> <br /> <br /> -- <br /> <br /> <br /> Antony Stone.</div>

Rminnich http://www.coreboot.org/PCCHIPS_M810LR 2005-03-01T17:20:46Z

<p>Rminnich: </p> <hr /> <div>My experience getting LinuxBios working on a PC-Chips M810LR motherboard with an M-Systems Millennium MD-2800-D08 Disk-on-Chip<br /> <br /> <br /> by Antony Stone <br /> <br /> <br /> <br /> Background<br /> <br /> <br /> I first came across LinuxBios at the LBW workshop at Doolin, Ireland, and it seemed like such a great project that I just wanted to get home and build one of my own. <br /> <br /> <br /> Thanks to Lance Davis and John Hearns for supplying hardware, Bill Boughton and Richard Russon for persevering with the software, and Chuck Moss for supplying some DoCs to play with. <br /> <br /> <br /> Even better, I recognised the PC-Chips motherboard they were using there - an M810LMR, and I knew I had two of these in systems already. So all I had to do was get myself a Disk-on-Chip device, and I'd have an instant-booting system, right ? <br /> <br /> <br /> Well, things were not quite so simple as that, so after managing to get my system working from a combination of: <br /> <br /> reading what documentation I could find <br /> knowing that I'd seen one working already <br /> guesswork and reading bits of the source code <br /> invaluable help and assistance from Ron Minnich and Andrew Ip <br /> <br /> I decided to write up my experiences to let other people know what I had to do to get things working, in the hope that this may make it easier for other people later on. <br /> <br /> <br /> <br /> Vendors<br /> <br /> <br /> It seems that PC-Chips have recently (August 2002) decided to rename their motherboard product range, so this is going to lead to even more confusion over which particular board you are working with. <br /> <br /> <br /> However, PC-Chips does appear to be one of the more helpful motherboard vendors as far as the LinuxBios project is concerned, and they certainly do seem to make some good value-for-money highly-integrated motherboards. <br /> <br /> <br /> The Disk-on-Chip devices are something I'd never worked with before, and I had no idea where to get them from, either. I live in the UK, so I simply went to M-Systems' website and looked for UK or European distributors. There were two distributors listed for the UK, so I phoned them up, and bought three MD-2800-D08 devices from one of them. I have my own company, so I qualified as a trade customer. I have no idea where you would buy these as a private individual, but I'll stick my neck out here and say that anyone who has trouble getting the Millennium DoC devices in the UK can email me and I'll try to help. <br /> <br /> <br /> As well as PC-Chips renumbering their motherboards, it also turns out that M-Systems are discontinuing the MD-2800 series and replacing them with the MD-2802 range, which are apparently &quot;hardware and software interchangeable&quot;. The MD-2800 devices are being discontinued, but the MD-2802 should work identically in all designs. I bought the last three MD-2800s the supplier had :-) <br /> <br /> <br /> <br /> Getting started<br /> <br /> <br /> So, I had a motherboard, and a Disk-on-Chip device. How to get LinuxBios up and running ? <br /> <br /> <br /> The first thing is to read the LinuxBios FAQ and the documentation for the SiS630 motherboards. This should give you a good idea of the overall process, and the steps involved. <br /> <br /> <br /> The steps listed in the documentation are:<br /> (Note: the following list should be numbered from 0 to 8 (as should the next list further down) for consistency with the original documentation. If your browser shows a list numbered from 1 to 9, you may want to consider updating it.) <br /> <br /> Get Linux installed on your LinuxBios machine <br /> Get LinuxBios source from the sourceforge <br /> Get a 2.4 kernel, patch it, then build it <br /> Configure and build LinuxBios <br /> Get the MTD utilities from http://www.linux-mtd.infradead.org and build the 'erase' utility <br /> Set up the 'flash_on' program in your path <br /> Remove the Bios from its socket and put a Disk-on-Chip in its place <br /> Burn the LinuxBios image into the Disk-on-Chip <br /> Hit reset. <br /> <br /> The details<br /> <br /> Step 0 should be easy enough for people who are attempting LinuxBios in the first place, however note that the kernel you are running must have support for MTD (Memory Technology Devices), which most people won't have turned on as standard. <br /> <br /> Therefore you should recompile your kernel on your machine with modules enabled (I generally don't use a modular kernel, but for programming the DoC devices in the Bios socket of the motherboard, you have to run a command before loading the DoC modules, therefore you can't compile this support directly into the kernel), and support for the Millennium DoC devices. <br /> <br /> <br /> I generally use 'make menuconfig' to configure my kernel; here are the options you need to select (accurate for a 2.4.19 kernel) in order to build LinuxBios into a DoC device: <br /> <br /> Loadable module support<br /> [*] Enable loadable module support<br /> [ ] Set version information on all module symbols<br /> [*] Kernel module loader<br /> <br /> Memory Technology Devices (MTD)<br /> &lt;M&gt; Memory Technology Device (MTD) support<br /> [ ] Debugging<br /> &lt; &gt; MTD partitioning support<br /> &lt; &gt; MTD concatenating support<br /> --- User Modules and Transition Layers<br /> &lt;M&gt; Direct char device access to MTD devices<br /> &lt; &gt; Caching block device access to MTD devices<br /> &lt; &gt; Readonly block device access to MTD devices<br /> &lt; &gt; FTL (Flash Transition Layer) support<br /> &lt; &gt; NFTL (NAND Flash Transition Layer) support<br /> RAM/ROM/Flash chip drivers ---&gt;<br /> Mapping drivers for chip access ---&gt;<br /> Self-contained MTD device drivers ---&gt;<br /> &lt; &gt; Ramix PMC551 PCI Mezzanine RAM card support<br /> &lt; &gt; Uncached system RAM<br /> &lt; &gt; Test driver using RAM<br /> &lt; &gt; MTD emulation using block device<br /> --- Disk-On-Chip Device Drivers<br /> &lt; &gt; M-Systems Disk-On-Chip 1000<br /> &lt; &gt; M-Systems Disk-On-Chip 2000 and Millennium<br /> &lt;M&gt; M-Systems Disk-On-Chip Millennium-only alternative driver<br /> [*] Advanced detection options for DiskOnChip<br /> (0) Physical address of DiskOnChip<br /> [*] Probe high addresses<br /> [ ] Probe for 0x55 0xAA BIOS Extension Signature<br /> <br /> NAND Flash Device Drivers ---&gt;<br /> <br /> <br /> There is also a highly impressive 'gotcha' in the MTD driver support - you must edit one of the kernel source files before compiling with MTD support, in order to be able to write (ie erase or program) the DoC devices. If you do not do this you will get errors when you try to erase or program the device, such as: <br /> <br /> <br /> /dev/mtd0: No such device<br /> /dev/mtd0: Bad file descriptor<br /> <br /> <br /> The change required is in /usr/src/linux/drivers/mtd/devices/docprobe.c <br /> <br /> <br /> Change the line which reads: <br /> <br /> #define DOC_SINGLE_DRIVER<br /> <br /> so that it becomes: <br /> #undef DOC_SINGLE_DRIVER<br /> <br /> You may want to read the comment just above the line you're editing, and be grateful that someone told you where to find this file to change it.... <br /> <br /> You also need to have Python installed on your system, because the LinuxBios build process is based around a Python program. <br /> <br /> <br /> It is also highly recommended that you install a 32-pin ZIF (Zero Insertion Force) socket on your motherboard, because later on you will need to swap chips in the Bios socket while the motherboard is powered on. This is not something you want to make any mistakes with, eg using a metal tool, getting the Bios or DoC pins misaligned or bent, shorting out some nearby components or connectors... <br /> <br /> <br /> Note the orientation of the Bios chip in its socket (there is a notch at one end, or a dot in one corner, of the chip), remove the chip, and plug a 32-pin ZIF socket into the motherboard socket (you will probably need to bend the pins of some nearby connectors to get it to fit - I found an unused 3-pin fan connector in the way). Place the lever of the ZIF socket at the end where the notch or dot was on the Bios chip. Make sure you plug the ZIF socket cleanly into all 32 holes on the socket on the motherboard - it's easy to miss a couple of pins at one end and get the whole thing moved along one place. You will probably want to do this with the motherboard not installed in a case, so you can look underneath the ZIF socket as you are inserting it. <br /> <br /> <br /> Once the ZIF socket is in place, lift the lever, insert the original Bios chip (notch or dot at the lever end of the socket) and lower the lever to secure the chip in place. <br /> <br /> <br /> If you see the usual Bios startup screen when you power on your motherboard, then you know you've done this bit correctly, and you can easily swap the chips over later on in the instructions. <br /> <br /> <br /> Get the LinuxBios source by CVS: <br /> <br /> export CVS_RSH=ssh<br /> cvs -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios login<br /> cvs -z3 -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios co freebios<br /> <br /> <br /> (Press return at the password prompt and ignore errors about &quot;failed to open ./cvspass for reading&quot; and even &quot;login aborted: fatal error: exiting&quot;. Press on regardless.) <br /> <br /> <br /> Before you get a fresh kernel source to patch with LinuxBios, check the LinuxBios kernel patches to see which kernel version is supported for your motherboard / chipset. You may be able to apply the patches to a different kernel, but at this stage in the game it's probably best to build an old kernel strictly by the instructions, and make sure you can get LinuxBios working at all, and then afterwards you can try to bring the kernel up to the version you'd like it to be. <br /> <br /> I used kernel version 2.4.19 because (a) this was already installed on my machine, and (b) there was a linux-2.4.19-sis.patch file available, which matched my motherboard. <br /> <br /> <br /> You can find the kernel patches in the FreeBios source you just downloaded from CVS by looking in freebios/src/kernel-patches This directory contains both the patches for the kernels, and also the config files for building the new kernel (note that not all these are guaranteed to work in all situations - you may need to look at other config files and make some manual adjustments to get your particular setup working). <br /> <br /> <br /> Note that the kernel patches and config files are for the kernel you will program into the DoC device and eventually boot your machine from. They may not be the best choice for the kernel you use to build LinuxBios and burn the DoC before trying to boot it. <br /> <br /> <br /> When you build the kernel, use 'make bzImage' and then just leave the kernel where it is. LinuxBios will later look for the file /usr/src/linux/vmlinux <br /> <br /> <br /> LinuxBios was developed from an earlier project called FreeBios, and therefore the source code you have downloaded is in a directory called 'freebios' <br /> <br /> You need to create your own config file, and make the build images for programming into the DoC device, in a different directory so that they are not deleted when you update your copy of the source code from the CVS repository. <br /> <br /> <br /> Because of the way the directory names worked out, I chose to create a new directory called 'linuxbios' side by side with 'freebios', and built my DoC images in there. <br /> <br /> <br /> Here is what I did to build LinuxBios: <br /> <br /> mkdir linuxbios<br /> cd linuxbios<br /> cp ../freebios/util/config/NLBConfig.py .<br /> cp ../freebios/util/config/pcchips.config .<br /> <br /> I then edited pcchips.config, making the following changes: <br /> Removed 'single' from the end of the kernel commandline, because I wanted my machine to boot into standard multiuser mode <br /> Added 'cpu k7' because I'm using an Athlon processor <br /> Added 'option ENABLE_MII=1' to get the onboard ethernet working (Thanks to Andrew Ip for telling me how to do this) <br /> Changed 'option HAVE_FRAMEBUFFER' to 'option HAVE_FRAMEBUFFER=1' (this eliminates a warning message later but is not essential) <br /> <br /> I also edited one of the LinuxBios source files in order to get the keyboard working on my motherboard (again, thanks to Andrew Ip for this): <br /> <br /> <br /> In the file freebios/src/arch/i386/lib/hardwaremain.c uncomment the function call keyboard_on() around line 344. If you do not do this, then when you finally boot your LinuxBios machine, you will get several hundred error messages &quot;pc_keyb: controller jammed (0xFF)&quot;, and your keyboard will not work. It will not stop your LinuxBios system from working, however - you will still be able to log in on the serial port, and ssh across the network. <br /> <br /> <br /> I then ran the Python program to create the build files: <br /> <br /> python NLBConfig.py pcchips.config ~/freebios<br /> <br /> This creates a subdirectory within linuxbios (where you are now) called pcchips, and creates the following files in it: <br /> LinuxBIOSDoc.config<br /> Makefile<br /> Makefile.settings<br /> crt0_includes.h<br /> nsuperio.c<br /> <br /> Once you have these files, and you have compiled your target kernel (which is then sitting in /usr/src/linux/vmlinux), you can run the makefile and build your LinuxBios image: <br /> cd pcchips<br /> make<br /> <br /> Note that if this is not the first time you're building the image, you may want to do a 'make clean' before the 'make'. <br /> <br /> I then copied the 'burn_mtd' utility into the newly-created pcchips directory, because by default it looks in the current directory for the source files to burn into the DoC device, so there's a lot less typing if the utility is in the same place. <br /> <br /> cp ../../freebios/util/mtd/burn_mtd .<br /> <br /> I made a couple of changes to the burn_mtd utility, in order to match the filenames generated by the Makefile a few moments ago: <br /> <br /> Change the first two occurrences of 'vmlinux' (one in the comment on line 3, the other in 'linux=vmlinux.bin.gz' on line 16) to 'linux' (so that line 16 now reads 'linux=linux.bin.gz'). <br /> <br /> <br /> Building the MTD 'erase' utility was pretty straightforward - I assume you'll have no problems here. <br /> <br /> Go into the freebios/util/sis directory and build the 'flash_on' utility by doing: <br /> make flash_on<br /> <br /> Copy the 'erase' and 'flash_on' utilities which you just built into your search path (I put them into /usr/local/sbin) <br /> <br /> This is the point where you are grateful you got yourself a 32-pin ZIF socket and plugged it into your motherboard. <br /> <br /> While the power is on and your system is running, release the lever on the ZIF socket, remove the original Flash Bios chip, replace it with a DoC (check the orientation ! The notch in the end of the chip goes at the lever end of the socket), and secure it in place with the lever. <br /> <br /> <br /> Run the command <br /> ./burn_mtd<br /> <br /> and with any luck it will program a LinuxBios chip for you ! <br /> <br /> The output of burn_mtd should look like this: <br /> <br /> # ./burn_mtd<br /> rmmod: module docprobe is not loaded<br /> rmmod: module doc2001 is not loaded<br /> rmmod: module docecc is not loaded<br /> 11+1 records in<br /> 12+0 records out<br /> 0+1 records in<br /> 1+0 records out<br /> Erase Total 1024 Units<br /> Performing Flash Erase of length 8192 at offset 0x7fe000 done<br /> 1+0 records in<br /> 1+0 records out<br /> 1+0 records in<br /> 1+0 records out<br /> 126+0 records in<br /> 126+0 records out<br /> 1536+0 records in<br /> 1536+0 records out<br /> # <br /> <br /> If at this stage you get the following instead: <br /> # ./burn_mtd<br /> rmmod: module docprobe is not loaded<br /> rmmod: module doc2001 is not loaded<br /> rmmod: module docecc is not loaded<br /> 11+1 records in<br /> 12+0 records out<br /> 0+1 records in<br /> 1+0 records out<br /> File open error<br /> dd: opening '/dev/mtd0': No such device<br /> dd: opening '/dev/mtd0': No such device<br /> dd: opening '/dev/mtd0': No such device<br /> dd: opening '/dev/mtd0': No such device<br /> # <br /> <br /> then you should check that you selected the correct MTD options when building your development kernel (you did reboot after building that so you're running it now, right ?), and also that you edited the file /usr/src/linux/drivers/mtd/devices/docprobe.c to undefine DOC_SINGLE_DRIVER before building that kernel. <br /> <br /> Press reset. <br /> <br /> If your system reboots and you see a penguin in the top corner of your screen instead of an AMI or Award Bios startup message, then you should jump up and down, punch the air, say things like &quot;Wow!&quot;, and generally be pleased with yourself. <br /> <br /> <br /> Problems?<br /> <br /> Do not worry if bits of the system do seem to get started properly (eg hard disk, ethernet, keyboard, root filing system...). They can almost certainly get sorted out later. <br /> <br /> If you do not get a penguin on your screen (in fact, you get nothing at all), then try plugging a serial cable into your RS232 port (the M810LR boards only have one RS232 port), connect a terminal emulator set to 115200 baud, 8 bits, no parity, and press reset again. You should get some debugging information and general startup message out of the serial port which might help you or someone else to work out what's not quite right. <br /> <br /> <br /> If absolutely nothing happens, then it's possible that you haven't got a suitable image burned into the DoC, so power off the motherboard, remove the DoC and put the original Bios back in again, power the system back up, and see if you've missed something from the above instructions. <br /> <br /> <br /> If you think I've missed something from these instructions, then please email me so I can update them for other users. <br /> <br /> <br /> For general help with LinuxBios, there is a current mailing list at http://www.clustermatic.org/mailman/listinfo/linuxbios and archives of earlier lists at http://www.acl.lanl.gov/linuxbios/faq/archive and http://www.missl.cs.umd.edu/archives/linuxbios. <br /> <br /> <br /> Good luck. <br /> <br /> <br /> -- <br /> <br /> <br /> Antony Stone.</div>

Rminnich http://www.coreboot.org/The_EPIA-M/MII 2005-03-01T17:18:40Z

<p>Rminnich: </p> <hr /> <div>From nick.barker9@btinternet.com Wed Oct 6 10:56:16 2004<br /> Date: Wed, 6 Oct 2004 06:47:08 +0100<br /> From: Nick Barker <br /> To: Ronald G. Minnich <br /> Subject: EPIA-M / MII a large patch<br /> <br /> [ The following text is in the &quot;iso-8859-1&quot; character set. ]<br /> [ Your display is set for the &quot;UTF-8&quot; character set. ]<br /> [ Some special characters may be displayed incorrectly. ]<br /> <br /> Ron,<br /> <br /> As announced on the list, here is my patch for freebios2 - epia-m/mii<br /> <br /> The patch contains both bug fixes and new features as follows:<br /> <br /> - ACPI power management and interrupt routing<br /> - Boot from onboard compact flash<br /> - Legacy VGA Bios working<br /> - mtrr's set up correctly for VGA<br /> - AGP and GART set up correctly<br /> - vt1211 h/w monitor, com ports, lpt and fdc enabled<br /> - 1/2 speed baud rate problem resolved<br /> <br /> Caveat<br /> The patch uses the memory setup code ported into C from version 1 for the<br /> EPIA-M, but has been adjusted for 256Mb only - i.e. the size that I'm<br /> currently using. This code, in northbridge/raminit.c, is an ugly hack to get<br /> the system up and booted, and I do not particularly offer it as the 'final<br /> solution'. I've always assumed that one day it would be replaced with proper<br /> autodetection - a job for someone with access to the appropriate<br /> documentation i.e. vt8623 datasheets.<br /> <br /> I have tried to restrict any changes to epia-m specific files, however there<br /> are a few generic files that I have had to make some changes in,<br /> particularly in the ACPI, vga bios and mtrr areas. These changes 'should' be<br /> benign to other platforms.<br /> <br /> There are other areas which I consider 'hackish', in particular the setting<br /> up of the cardbus bridge. This device is ignored altogether by the PCI<br /> detection code because it has a header type of PCI to cardbus bridge (type 2<br /> I think). Having failed to understand the intricacies of the pci detection<br /> and configuration mechanism, I have resorted to setting up the bridge<br /> manually, and with fixed memory resources, as annotated in the code.<br /> <br /> The Config.lb provided is set up for filo and legacy vga bios. In other<br /> words it makes an image 192K big to which a captured vga bios should be<br /> prepended.<br /> <br /> The patch is relative to the web based CVS snapshot of 20041004-1100.<br /> <br /> <br /> <br /> ACPI power management and interrupt routing<br /> -------------------------------------------<br /> I have added the code which creates three new ACPI tables, and sets up the<br /> southbridge power management unit into ACPI mode.<br /> <br /> The new tables are the:<br /> Fixed ACPI Description Table (FADT)<br /> Firmware ACPI Control Structure (FACS)<br /> Differentiated System Description Table (DSDT)<br /> <br /> The FADT mostly describes the power management unit, and is declared in<br /> fadt.c in the mainboard/via/epia-m directory.<br /> <br /> The FACS is intended to provide non volatile memory to the ACPI system for<br /> suspend to disk activities. However it is currently implemented as a zeroed<br /> table. I have only included it because Linux ACPI complains if there isn't<br /> one if a FADT has been provided.<br /> <br /> The DSDT describes the interrupt routing and power management capabilities<br /> of devices, and is what Linux uses for interrupt routing if it can. The<br /> DSDT, defined in mainboard/via/epia-m/dsdt.c is exactly that provided with<br /> the original Award bios. It has been created using the following approximate<br /> steps:<br /> 1) Under Award Bios, 'cat /proc/acpi/dsdt &gt; dsdt'<br /> 2) Decompile dsdt with Intel's iasl - 'iasl -d dsdt'<br /> 3) Compile to C table with Intel's iasl - 'iasl -tc dsdt.dsl'<br /> 4) Copy output to mainboard/via/epia-m/dsdt.c<br /> <br /> The award dsdt may carry the same IPR situation as the VGA bios, and it<br /> could be that the file dsdt.c should not be distributed with the code.<br /> However it is easy enough to create your own using the steps above.<br /> <br /> The ACPI code seems to be fully functional - giving software off and reset,<br /> as well as providing power button click events (the whole reason I wrote<br /> this !!).<br /> I assume the ACPI subsystem in Linux is also shifting the processor into S1<br /> and S2 states, and doing other things that ACPI should do, but I haven't<br /> confirmed that yet.<br /> <br /> Boot from onboard Compact Flash<br /> -------------------------------<br /> I have added a new device to the southbridge tree -<br /> southbridge/ricoh/rl5c476, which is the setup code for the Ricoh cardbus<br /> bridge found on the MII. I wasn't quite sure where to put it in the source<br /> tree, but I guessed it was more like a southbridge than anything else.<br /> <br /> The code sets up a compact flash in the CF slot as an IDE drive based at<br /> address 0x1e8, in other words the standard address for the third IDE<br /> controller as used by Filo, Linux, and I guess Etherboot.<br /> <br /> The code is a bit clunky in as much as it allocates fixed addresses for<br /> memory windows - which ought to be allocated by the pci detection code, but<br /> I can't figure out how to make this happen.<br /> <br /> Filo detects the CF as drive 'hde' as long as filo has been compiled with<br /> SUPPORT_PCI=1 commented out. With SUPPORT_PCI included, filo only searches<br /> for PCI devices of the IDE controller type, whereas without it, filo will<br /> check its standard addresses for an IDE controller.<br /> <br /> You can configure Linux to support the CF in one of two ways, depending upon<br /> your needs:<br /> <br /> - Standard IDE disk support. Just let the standard IDE detection code in<br /> Linux pick up the CF as a standard device. This has the advantage of being<br /> quick and easy to get going. However if you then start up pcmcia utils to<br /> deal with the pcmcia slot, you will run into difficulties as the<br /> pcmcia-utils package resets the CF slot. There might be options you can use<br /> to instruct pcmcia-utils to ignore the CF slot entirely, but I haven't found<br /> them yet.<br /> <br /> - PCMCIA-UTILS support. Firstly you have to tell the standard IDE detection<br /> code NOT to look for the third IDE controller, do so with a linux command<br /> line option of 'ide2=noprobe'. Next you need to set up an initrd. The<br /> pcmcia-utils HOWTO describes how to do this with 'pcinitrd'. In addition you<br /> have to add the program 'resetcf' from freebios2/util directory to the<br /> initrd, and make sure it is called just before the socket driver is loaded<br /> in the linuxrc file. This step is necessary because the yenta socket driver<br /> does not correctly clear down the state of the CF socket as left by<br /> freebios2 (detail - yenta socket driver never clears the io offset used by<br /> freebios2 to make the CF look like /dev/hde - I guess it normally relies on<br /> the power on default being zero!!!). My linux command line in filo looks<br /> like:<br /> <br /> AUTOBOOT_FILE = &quot;hde:/vmlinuz initrd=hde:/initrd.gz root=/dev/hde<br /> console=tty0 ide2=noprobe&quot;<br /> <br /> Legacy VGA BIOS<br /> ---------------<br /> I struggled for some time getting the VGA bios to work properly, as others<br /> on the mailing list seem to be also. Here is a list of my findings:<br /> <br /> Some people are finding that the bios initialisation code is crashing with a<br /> random interrupt vector. This always seemed to happen at cs:ip=c000:0188. A<br /> look at the actual instruction at that location reveals that it is an STI<br /> instruction which enables hardware interrupt processing, not an INTXX<br /> instruction. On freebios2, the i8259 interrupt controller is never<br /> initialised, so it is understandable that if the vga bios has been playing<br /> with interrupts that after the STI intruction a random interupt vector is<br /> issued by the i8259 - and hence the problems as reported. My fix is to<br /> include the version 1 i8259 initialisation code, and that allows the bios to<br /> finish.<br /> <br /> The next problem encounterred was that after vga initialisation, the screen<br /> didn't come on. After groping around the XFree sources for the CLE266 I<br /> discovered a bios call to select which output device(s) to enable, and have<br /> added a call to that function to turn on the standard console. Anyone<br /> wanting the TV output or LCD panel output are recommended to look at the<br /> Xserver sources for that bios call.<br /> <br /> The final problem was that the freebios2 code was setting up the video<br /> memory window at 0xa0000 - 0xbffff as cacheable in its fixed mtrr code. This<br /> was resolved by getting sizeram() in northbridge.c to break the main area of<br /> memory into 2 chuncks either side of this window.<br /> <br /> MTRR's for VGA<br /> --------------<br /> I have added code to create correct mtrr's for the VGA framebuffer and the<br /> AGP. This has meant some minor changes in mtrr.c<br /> <br /> AGP port and GART<br /> -----------------<br /> The AGP bridge seems to work correctly after setting it up like award. The<br /> GART window is hard coded at address 0xd0000000, as per award, and<br /> could/should be set by the pci_device allocation code. Linux AGP support<br /> does not crash the system and I believe it to be fully working.<br /> <br /> VT1211<br /> ------<br /> I have created a new superio device for the vt1211, which sets up the<br /> hardware monitor, com ports, lpt and fdc. The h/w monitor set up values are<br /> taken from v1. None of this has been tested beyond Linux correctly spotting<br /> the devices.<br /> <br /> 1/2 speed baud rate problem<br /> ---------------------------<br /> I believe that the 1/2 speed baud rate problem is down to trying to do<br /> things before the southbridge and certain clocks have fully settled down. By<br /> putting a delay after the rtc_init() and before trying to use the SMB bus,<br /> the problem seems to be rectified. The counter in the delay loop could be<br /> optimised if anyone out there has the desire - 1000 isn't enough, whilst<br /> 5000 is.<br /> <br /> And Finally<br /> -----------<br /> As an indicator that the BIOS is going, I've got the power LED to blink<br /> rapidly from early on, until the BIOS has just about finished its job. Could<br /> be first thing for newcomers to look for when they don't get any other form<br /> of output.</div>

Rminnich http://www.coreboot.org/Technoland_SBC_710 2005-03-01T16:21:19Z

<p>Rminnich: </p> <hr /> <div>This document is intended to help people bring up new LinuxBIOS targets. Our first example will be the Technoland SBC 710, since it has a set of chips that are for the most part already supported. <br /> <br /> '''Bringing up LinuxBIOS on the SBC710'''<br /> <br /> The SBC710 is sold by Technoland and consists of a PGA370 socket for support of Pentium 3s and Celerons; a 440BX northbridge; a PIIX4e South Bridge; a C&amp;T video chip; and two winbond SuperIO chips (83977EF and 83877TF). As it happens most of these chips are supported by LinuxBIOS, which is one reason we chose the board. Another reason we chose the board is because PC motherboard vendors are in the habit of hiding the things you need to know to get LinuxBIOS working. This card, we are finding, is an open book. It is as a result pretty easy to get it going. Finally, it is cheap: $380 without CPU or memory and about $600 with PIII/800 CPU and 256MB memory. Getting LinuxBIOS up involves several steps: <br /> <br /> Enumerating the chips on the board <br /> <br /> Figuring out the FLASH type to be used, given the sockets available <br /> <br /> Figure out if there are devices in the 640K-960K (0xa0000-0xeffff) space <br /> <br /> Determining how to configure DRAM<br /> <br /> Determining if and how to run the serial ports for debug messages <br /> <br /> Building in any new chipset support<br /> <br /> Setting up a &quot;mainboard&quot; tree for LinuxBIOS in the LinuxBIOS source<br /> <br /> Building a LinuxBIOS for your target <br /> <br /> Burning a FLASH or DoC part <br /> <br /> Running it; fixing problems<br /> <br /> <br /> Enumerating the chips on the board <br /> <br /> For the SBC 710, the chips we need to be concerned with are: Intel 82443BX North Bridge (also known as 440BX); Intel PIIX4E South Bridge; C&amp;T video chip; and two Winbond Super IO chips, the 83977EF and the 83877TF. All of these chips except the 83877 and the C&amp;T chip are supported. We don't care about the C&amp;T chip because we don't do graphics in LinuxBIOS (yet). We will have to add support for the 83877 later; we'll go into that. <br /> <br /> Figuring out the FLASH type to be used, given the sockets available <br /> <br /> The SBC 710 supports BOTH a 256 KB (4 Mbit) flash part and a DoC flash part. This is an ideal situation. We can boot a fairly complex LinuxBIOS from the FLASH part, as it is at least 8 times larger than the largest LinuxBIOS rom image; and we can put a very large Linux kernel in even the smallest 8 MB DoC part, and even an initial ram disk (initrd) if we wish. The FLASH part is addressed at the normal 0xf0000 address, and the DoC is addressed (via jumper) at 0xd0000. <br /> <br /> Figure out if there are devices in the 640K-960K (0xa0000-0xeffff) space <br /> <br /> Some systems have just normal RAM or VGA memory in the 0xa0000-0xeffff space, so this space can actually be used as a type of memory -- namely, cacheable for reads and write-invalidate for writes. Other systems have I/O devices in this address space, so the memory must be configured as completely non-cacheable. The determination of how this area is treated is controlled by the Fixed-address Memory Type Range Registers (Fixed MTRRs). To leave this address space as RAM, we don't have to do anything. To use it as a device space, we have to set <br /> option MTRR_ONLY_TOP_64K_FLASH<br /> <br /> in the mainboard Config file. The SBC 710 has devices in the 0xa0000-0xeffff address space -- namely, the Disk On Chip. The mainboard Config file will need to have this option set. <br /> <br /> Determining how to configure SDRAM<br /> <br /> SDRAM configuration is the single biggest problem for LinuxBIOS. In part it is due to the complexity of SDRAM, since we need to check over 17 different parameters to figure out how to determine the SDRAM control registers. That is only one of the problems. By definition, memory is not functioning before we program the SDRAM, so our code is very limited in what it can do, which makes for some very complex and hard-to-read assembly. Finally, poor chipset designs can make it hard to get it all right. Actual SDRAM parameters such as CAS latency, speed, etc. are maintained on a Serial EEPROM (SEEPROM) on the SDRAM module. The SEEPROM is accessed over a serial motherboard link called the SMBUS. LinuxBIOS needs to access the data in the SEEPROM and then configure SDRAM control registers. The actual SDRAM control registers are on the North Bridge, as expected; the South Bridge controls the SMBUS. To actually program the SDRAM control registers on the North Bridge, we must direct the South Bridge to send packets on the SMBUS to query the Serial EPROM on the SDRAM modules to find out their configuration. Fortunately, thanks to our many contributors, both these chips are supported. If the board vendor has not done anything to make it difficult to operate the SMBUS, everything should work fine. <br /> <br /> Test one: can we read the SMBUS? <br /> <br /> This program can be used to test SPD accessibility on systems with a PIIX4E. We were not sure if it would work, given that IBM on the Thinkpad T22 obscures this information. <br /> <br /> A quick note on the SMBUS <br /> <br /> A note on this program. You need to understand a bit about SMBUS to understand it. If you're doing a port you should understand it anyway! Here is a quick introduction. The data rate is roughly 100 Kbits/second. SMBUS is a serial bus found on most new motherboards. SMBUS is also sometimes called I2C, although that usage is being deprecated. SMBUS is a packet-oriented bus and is used for communications with many different systems on PCs, including smart batteries, sensor chips, and SDRAM. SMBUS packets contain a 7-bit address for selecting devices. This address in the SMBUS packet is shifted left one bit and, for read operations, OR'ed with a 1 in the low-order bit. Certain devices are assigned fixed addresses; SDRAM is one of them. Currently SDRAM occupies addresses 0x50 to 0x53. One thing that complicates SMBUS usage is that a system may have more than one SMBUS. For example, ASUS motherboards sometimes have two; IBM thinkpads also seem to have more than one. The motherboard vendors often obscure the existence of the SDRAM SMBUS by hiding it in hardware. On the ASUS CUA we had to find the enable control for SDRAM SMBUS by using a PCI analyzer to capture the I/O operations. <br /> <br /> Program operation <br /> <br /> Our simple program probes the SMBUS by enabling SMBUS access in the PIIX4E and then, first, enumerating all accessible devices on the SMBUS; and, second, seeing if any SDRAM devices can be accessed. We won't describe how the program does this, since if you're doing a port you need to have a thorough understanding of how it works. Walk through it line by line until you know what it does. <br /> <br /> Program output <br /> <br /> When we run the program we find that it correctly probes SDRAM in slot 0, the only SDRAM slot on the SBC 710. This result is very encouraging, since it means that the LinuxBIOS SDRAM setup code will probably work with no changes whatsoever. We have cleared the worst hurdle. <br /> <br /> Determining if and how to run the serial ports for debug messages <br /> <br /> The SBC 710 supports two serial ports. What we don't know is which of the two Winbond Super IO chips supports which serial port. There is no real question about our ability to drive the serial ports, the work will be in figuring out which chip to drive, and how to drive it. <br /> <br /> Which Super IO does what? <br /> <br /> There are two Super IOs on this card. They are both capable of running floppy, keyboard, serial, etc. For configuring LinuxBIOS we need to know which Super IO does which function. Fortunately we can probe the Super IOs from user mode and figure out, for all of the devices, which device is turned. This information will in turn guide the LinuxBIOS configuration. <br /> <br /> Building in new chipset support <br /> <br /> The only new chipset to this board is the Winbond w83877tf superio. Most winbond Super IO parts are pretty much the same. To start, we can borrow code from another winbond. Since the w83627hf has the most complete support, we borrow the code from that one. To set up the new Super IO, we generally need two files: superio.c (C setup) and setup_serial.inc (needed for very early low-level debug printing). The w83627hf provides both of these. To set up the new superio: <br /> cd src/superio/winbond<br /> mkdir w83877tf<br /> cp w83627hf/* w83877tf<br /> <br /> Next you need to look at the superio.c file and fix it up. You can see what needs to be done by comparing the three winbond superio directories. The differences are actually quite minor. Luckily this was the only new support needed for LinuxBIOS on the SBC 710. <br /> <br /> Setting up a &quot;mainboard&quot; tree for LinuxBIOS in the LinuxBIOS source<br /> <br /> The next step is to set up a mainboard directory for the mainboard. The general form of the tree for components and mainboards is src/part-type/vendor name/mainboard name, so for example for the ASUS CUA the tree in LinuxBIOS is: src/mainboard/asus/cua. The mainboard directory contains one mandatory file: Config. Config is used by the Python-based configuration tool to build several files for building LinuxBIOS for the mainboard. These files include a Makefile, ldscript file, crt0.S file, and several other files depending on what is in the Config file. Optional files include mainboard.c, for setting up mainboard-specific features of the mainboard; irq_tables.c, for setting up irq tables for the mainboard (irq tables are ALWAYS mainboard-specific); and config.example, so users have a sample config file for the mainboard when they build it. There are enough existing mainboard targets for LinuxBIOS that we can usually find a mainboard that is close enough to use as a starting point. Thanks to one of our contributors there is a generic 440bx mainboard directory (not really guaranteed to work for everyone) called src/mainboard/intel/l440bx. The Config file in this directory is definitely wrong, since it specifies the wrong superio. Here is the original Config file. As you can see it specifies most things correctly save for the wrong Super IO part (it uses and SMC part). Here is the corrected version of Config for the SBC 710. The differences are minor: <br /> 7c7<br /> &lt; mainboardinit superio/NSC/pc87309/setup_serial.inc<br /> ---<br /> &gt; # mainboardinit superio/NSC/pc87309/setup_serial.inc<br /> 13c13,15<br /> &lt; superio NSC/pc87309<br /> ---<br /> &gt; #superio NSC/pc87309<br /> &gt; nsuperio winbond/w83977ef keyboard=1<br /> &gt; nsuperio winbond/w83877tf<br /> 24a27,29<br /> &gt; <br /> &gt; option UPDATE_MICROCODE<br /> &gt; option MTRR_ONLY_TOP_64K_FLASH<br /> <br /> We have to comment out the setup_serial.inc (we don't know which one to use yet); and we change the Super IO parts. Finally we always enable UPDATE_MICROCODE since this board always uses PIIIs and we know that some of them will need microcode patches. If you check out the CVS tree, you can see we also add a mainboard.c: <br /> mainboard_fixup()<br /> {<br /> void southbridge_fixup(void);<br /> southbridge_fixup();<br /> }<br /> <br /> This code is needed to fix up the PIIX4E for Linux use. The other code files, irq_tables.c and do_ramtest.inc, are also used for the SBC 710. Finally we provide an example.config to make it easy to build LinuxBIOS for the SBC 710. <br /> <br /> Building a LinuxBIOS for your target <br /> <br /> To build LinuxBIOS, you need to create a config file. Here is the starting point for this mainboard. <br /> # Sample config file for technoland sbc710<br /> <br /> target tlsbc710<br /> <br /> mainboard technoland/sbc710<br /> <br /> # Enable Serial Console for debugging<br /> option SERIAL_CONSOLE<br /> option NO_KEYBOARD<br /> <br /> option INBUF_COPY<br /> option DEFAULT_CONSOLE_LOGLEVEL=9<br /> option DEBUG<br /> option USE_GENERIC_ROM=1<br /> <br /> # Path to your kernel (vmlinux)<br /> linux ~/src/bios/linux-2.4.7-sis<br /> <br /> # Kernel command line parameters<br /> commandline root=/dev/hda6 console=ttyS0,115200 FS_MODE=ro hda=flash hdb=flash<br /> <br /> We name the target directory, the mainboard, and set some options. For more information on the options in a configuration file see the CVS tree; look in Documentation at the configmanual.ps document. To build this linuxbios tree, you need to figure out where you want to build it, figure out where you linux is, and fix the file as needed. For testing we take the file as is and run the config tool: <br /> python ~/src/freebios/util/config/NLBConfig.py config.example ~/src/freebios/<br /> <br /> The build is fine. <br /> <br /> Burning a FLASH or DoC part <br /> <br /> You will next need to burn the 256KB flash part used in the SBC 710. For this purpose we use our AMD SMP systems and either the MTD utilities or a user-mode program. We will be experimenting with MTD on the SBC 710 as well. <br /> <br /> Running it; fixing problems</div>

Rminnich http://www.coreboot.org/Technoland_SBC_710 2005-03-01T16:20:30Z

<p>Rminnich: </p> <hr /> <div>This document is intended to help people bring up new LinuxBIOS targets. Our first example will be the Technoland SBC 710, since it has a set of chips that are for the most part already supported. <br /> <br /> '''Bringing up LinuxBIOS on the SBC710'''<br /> <br /> The SBC710 is sold by Technoland and consists of a PGA370 socket for support of Pentium 3s and Celerons; a 440BX northbridge; a PIIX4e South Bridge; a C&amp;T video chip; and two winbond SuperIO chips (83977EF and 83877TF). As it happens most of these chips are supported by LinuxBIOS, which is one reason we chose the board. Another reason we chose the board is because PC motherboard vendors are in the habit of hiding the things you need to know to get LinuxBIOS working. This card, we are finding, is an open book. It is as a result pretty easy to get it going. Finally, it is cheap: $380 without CPU or memory and about $600 with PIII/800 CPU and 256MB memory. Getting LinuxBIOS up involves several steps: <br /> Enumerating the chips on the board <br /> Figuring out the FLASH type to be used, given the sockets available <br /> Figure out if there are devices in the 640K-960K (0xa0000-0xeffff) space <br /> Determining how to configure DRAM<br /> <br /> Determining if and how to run the serial ports for debug messages <br /> Building in any new chipset support<br /> <br /> Setting up a &quot;mainboard&quot; tree for LinuxBIOS in the LinuxBIOS source<br /> <br /> Building a LinuxBIOS for your target <br /> Burning a FLASH or DoC part <br /> Running it; fixing problems<br /> <br /> <br /> Enumerating the chips on the board <br /> <br /> For the SBC 710, the chips we need to be concerned with are: Intel 82443BX North Bridge (also known as 440BX); Intel PIIX4E South Bridge; C&amp;T video chip; and two Winbond Super IO chips, the 83977EF and the 83877TF. All of these chips except the 83877 and the C&amp;T chip are supported. We don't care about the C&amp;T chip because we don't do graphics in LinuxBIOS (yet). We will have to add support for the 83877 later; we'll go into that. <br /> <br /> Figuring out the FLASH type to be used, given the sockets available <br /> <br /> The SBC 710 supports BOTH a 256 KB (4 Mbit) flash part and a DoC flash part. This is an ideal situation. We can boot a fairly complex LinuxBIOS from the FLASH part, as it is at least 8 times larger than the largest LinuxBIOS rom image; and we can put a very large Linux kernel in even the smallest 8 MB DoC part, and even an initial ram disk (initrd) if we wish. The FLASH part is addressed at the normal 0xf0000 address, and the DoC is addressed (via jumper) at 0xd0000. <br /> <br /> Figure out if there are devices in the 640K-960K (0xa0000-0xeffff) space <br /> <br /> Some systems have just normal RAM or VGA memory in the 0xa0000-0xeffff space, so this space can actually be used as a type of memory -- namely, cacheable for reads and write-invalidate for writes. Other systems have I/O devices in this address space, so the memory must be configured as completely non-cacheable. The determination of how this area is treated is controlled by the Fixed-address Memory Type Range Registers (Fixed MTRRs). To leave this address space as RAM, we don't have to do anything. To use it as a device space, we have to set <br /> option MTRR_ONLY_TOP_64K_FLASH<br /> <br /> in the mainboard Config file. The SBC 710 has devices in the 0xa0000-0xeffff address space -- namely, the Disk On Chip. The mainboard Config file will need to have this option set. <br /> <br /> Determining how to configure SDRAM<br /> <br /> SDRAM configuration is the single biggest problem for LinuxBIOS. In part it is due to the complexity of SDRAM, since we need to check over 17 different parameters to figure out how to determine the SDRAM control registers. That is only one of the problems. By definition, memory is not functioning before we program the SDRAM, so our code is very limited in what it can do, which makes for some very complex and hard-to-read assembly. Finally, poor chipset designs can make it hard to get it all right. Actual SDRAM parameters such as CAS latency, speed, etc. are maintained on a Serial EEPROM (SEEPROM) on the SDRAM module. The SEEPROM is accessed over a serial motherboard link called the SMBUS. LinuxBIOS needs to access the data in the SEEPROM and then configure SDRAM control registers. The actual SDRAM control registers are on the North Bridge, as expected; the South Bridge controls the SMBUS. To actually program the SDRAM control registers on the North Bridge, we must direct the South Bridge to send packets on the SMBUS to query the Serial EPROM on the SDRAM modules to find out their configuration. Fortunately, thanks to our many contributors, both these chips are supported. If the board vendor has not done anything to make it difficult to operate the SMBUS, everything should work fine. <br /> <br /> Test one: can we read the SMBUS? <br /> <br /> This program can be used to test SPD accessibility on systems with a PIIX4E. We were not sure if it would work, given that IBM on the Thinkpad T22 obscures this information. <br /> <br /> A quick note on the SMBUS <br /> <br /> A note on this program. You need to understand a bit about SMBUS to understand it. If you're doing a port you should understand it anyway! Here is a quick introduction. The data rate is roughly 100 Kbits/second. SMBUS is a serial bus found on most new motherboards. SMBUS is also sometimes called I2C, although that usage is being deprecated. SMBUS is a packet-oriented bus and is used for communications with many different systems on PCs, including smart batteries, sensor chips, and SDRAM. SMBUS packets contain a 7-bit address for selecting devices. This address in the SMBUS packet is shifted left one bit and, for read operations, OR'ed with a 1 in the low-order bit. Certain devices are assigned fixed addresses; SDRAM is one of them. Currently SDRAM occupies addresses 0x50 to 0x53. One thing that complicates SMBUS usage is that a system may have more than one SMBUS. For example, ASUS motherboards sometimes have two; IBM thinkpads also seem to have more than one. The motherboard vendors often obscure the existence of the SDRAM SMBUS by hiding it in hardware. On the ASUS CUA we had to find the enable control for SDRAM SMBUS by using a PCI analyzer to capture the I/O operations. <br /> <br /> Program operation <br /> <br /> Our simple program probes the SMBUS by enabling SMBUS access in the PIIX4E and then, first, enumerating all accessible devices on the SMBUS; and, second, seeing if any SDRAM devices can be accessed. We won't describe how the program does this, since if you're doing a port you need to have a thorough understanding of how it works. Walk through it line by line until you know what it does. <br /> <br /> Program output <br /> <br /> When we run the program we find that it correctly probes SDRAM in slot 0, the only SDRAM slot on the SBC 710. This result is very encouraging, since it means that the LinuxBIOS SDRAM setup code will probably work with no changes whatsoever. We have cleared the worst hurdle. <br /> <br /> Determining if and how to run the serial ports for debug messages <br /> <br /> The SBC 710 supports two serial ports. What we don't know is which of the two Winbond Super IO chips supports which serial port. There is no real question about our ability to drive the serial ports, the work will be in figuring out which chip to drive, and how to drive it. <br /> <br /> Which Super IO does what? <br /> <br /> There are two Super IOs on this card. They are both capable of running floppy, keyboard, serial, etc. For configuring LinuxBIOS we need to know which Super IO does which function. Fortunately we can probe the Super IOs from user mode and figure out, for all of the devices, which device is turned. This information will in turn guide the LinuxBIOS configuration. <br /> <br /> Building in new chipset support <br /> <br /> The only new chipset to this board is the Winbond w83877tf superio. Most winbond Super IO parts are pretty much the same. To start, we can borrow code from another winbond. Since the w83627hf has the most complete support, we borrow the code from that one. To set up the new Super IO, we generally need two files: superio.c (C setup) and setup_serial.inc (needed for very early low-level debug printing). The w83627hf provides both of these. To set up the new superio: <br /> cd src/superio/winbond<br /> mkdir w83877tf<br /> cp w83627hf/* w83877tf<br /> <br /> Next you need to look at the superio.c file and fix it up. You can see what needs to be done by comparing the three winbond superio directories. The differences are actually quite minor. Luckily this was the only new support needed for LinuxBIOS on the SBC 710. <br /> <br /> Setting up a &quot;mainboard&quot; tree for LinuxBIOS in the LinuxBIOS source<br /> <br /> The next step is to set up a mainboard directory for the mainboard. The general form of the tree for components and mainboards is src/part-type/vendor name/mainboard name, so for example for the ASUS CUA the tree in LinuxBIOS is: src/mainboard/asus/cua. The mainboard directory contains one mandatory file: Config. Config is used by the Python-based configuration tool to build several files for building LinuxBIOS for the mainboard. These files include a Makefile, ldscript file, crt0.S file, and several other files depending on what is in the Config file. Optional files include mainboard.c, for setting up mainboard-specific features of the mainboard; irq_tables.c, for setting up irq tables for the mainboard (irq tables are ALWAYS mainboard-specific); and config.example, so users have a sample config file for the mainboard when they build it. There are enough existing mainboard targets for LinuxBIOS that we can usually find a mainboard that is close enough to use as a starting point. Thanks to one of our contributors there is a generic 440bx mainboard directory (not really guaranteed to work for everyone) called src/mainboard/intel/l440bx. The Config file in this directory is definitely wrong, since it specifies the wrong superio. Here is the original Config file. As you can see it specifies most things correctly save for the wrong Super IO part (it uses and SMC part). Here is the corrected version of Config for the SBC 710. The differences are minor: <br /> 7c7<br /> &lt; mainboardinit superio/NSC/pc87309/setup_serial.inc<br /> ---<br /> &gt; # mainboardinit superio/NSC/pc87309/setup_serial.inc<br /> 13c13,15<br /> &lt; superio NSC/pc87309<br /> ---<br /> &gt; #superio NSC/pc87309<br /> &gt; nsuperio winbond/w83977ef keyboard=1<br /> &gt; nsuperio winbond/w83877tf<br /> 24a27,29<br /> &gt; <br /> &gt; option UPDATE_MICROCODE<br /> &gt; option MTRR_ONLY_TOP_64K_FLASH<br /> <br /> We have to comment out the setup_serial.inc (we don't know which one to use yet); and we change the Super IO parts. Finally we always enable UPDATE_MICROCODE since this board always uses PIIIs and we know that some of them will need microcode patches. If you check out the CVS tree, you can see we also add a mainboard.c: <br /> mainboard_fixup()<br /> {<br /> void southbridge_fixup(void);<br /> southbridge_fixup();<br /> }<br /> <br /> This code is needed to fix up the PIIX4E for Linux use. The other code files, irq_tables.c and do_ramtest.inc, are also used for the SBC 710. Finally we provide an example.config to make it easy to build LinuxBIOS for the SBC 710. <br /> <br /> Building a LinuxBIOS for your target <br /> <br /> To build LinuxBIOS, you need to create a config file. Here is the starting point for this mainboard. <br /> # Sample config file for technoland sbc710<br /> <br /> target tlsbc710<br /> <br /> mainboard technoland/sbc710<br /> <br /> # Enable Serial Console for debugging<br /> option SERIAL_CONSOLE<br /> option NO_KEYBOARD<br /> <br /> option INBUF_COPY<br /> option DEFAULT_CONSOLE_LOGLEVEL=9<br /> option DEBUG<br /> option USE_GENERIC_ROM=1<br /> <br /> # Path to your kernel (vmlinux)<br /> linux ~/src/bios/linux-2.4.7-sis<br /> <br /> # Kernel command line parameters<br /> commandline root=/dev/hda6 console=ttyS0,115200 FS_MODE=ro hda=flash hdb=flash<br /> <br /> We name the target directory, the mainboard, and set some options. For more information on the options in a configuration file see the CVS tree; look in Documentation at the configmanual.ps document. To build this linuxbios tree, you need to figure out where you want to build it, figure out where you linux is, and fix the file as needed. For testing we take the file as is and run the config tool: <br /> python ~/src/freebios/util/config/NLBConfig.py config.example ~/src/freebios/<br /> <br /> The build is fine. <br /> <br /> Burning a FLASH or DoC part <br /> <br /> You will next need to burn the 256KB flash part used in the SBC 710. For this purpose we use our AMD SMP systems and either the MTD utilities or a user-mode program. We will be experimenting with MTD on the SBC 710 as well. <br /> <br /> Running it; fixing problems</div>

Rminnich http://www.coreboot.org/Technoland_SBC_710 2005-03-01T16:18:02Z

<p>Rminnich: </p> <hr /> <div>This document is intended to help people bring up new LinuxBIOS targets. Our first example will be the Technoland SBC 710, since it has a set of chips that are for the most part already supported. <br /> <br /> Bringing up LinuxBIOS on the SBC710<br /> <br /> The SBC710 is sold by Technoland and consists of a PGA370 socket for support of Pentium 3s and Celerons; a 440BX northbridge; a PIIX4e South Bridge; a C&amp;T video chip; and two winbond SuperIO chips (83977EF and 83877TF). As it happens most of these chips are supported by LinuxBIOS, which is one reason we chose the board. Another reason we chose the board is because PC motherboard vendors are in the habit of hiding the things you need to know to get LinuxBIOS working. This card, we are finding, is an open book. It is as a result pretty easy to get it going. Finally, it is cheap: $380 without CPU or memory and about $600 with PIII/800 CPU and 256MB memory. Getting LinuxBIOS up involves several steps: <br /> Enumerating the chips on the board <br /> Figuring out the FLASH type to be used, given the sockets available <br /> Figure out if there are devices in the 640K-960K (0xa0000-0xeffff) space <br /> Determining how to configure DRAM<br /> <br /> Determining if and how to run the serial ports for debug messages <br /> Building in any new chipset support<br /> <br /> Setting up a &quot;mainboard&quot; tree for LinuxBIOS in the LinuxBIOS source<br /> <br /> Building a LinuxBIOS for your target <br /> Burning a FLASH or DoC part <br /> Running it; fixing problems<br /> <br /> <br /> Enumerating the chips on the board <br /> <br /> For the SBC 710, the chips we need to be concerned with are: Intel 82443BX North Bridge (also known as 440BX); Intel PIIX4E South Bridge; C&amp;T video chip; and two Winbond Super IO chips, the 83977EF and the 83877TF. All of these chips except the 83877 and the C&amp;T chip are supported. We don't care about the C&amp;T chip because we don't do graphics in LinuxBIOS (yet). We will have to add support for the 83877 later; we'll go into that. <br /> <br /> Figuring out the FLASH type to be used, given the sockets available <br /> <br /> The SBC 710 supports BOTH a 256 KB (4 Mbit) flash part and a DoC flash part. This is an ideal situation. We can boot a fairly complex LinuxBIOS from the FLASH part, as it is at least 8 times larger than the largest LinuxBIOS rom image; and we can put a very large Linux kernel in even the smallest 8 MB DoC part, and even an initial ram disk (initrd) if we wish. The FLASH part is addressed at the normal 0xf0000 address, and the DoC is addressed (via jumper) at 0xd0000. <br /> <br /> Figure out if there are devices in the 640K-960K (0xa0000-0xeffff) space <br /> <br /> Some systems have just normal RAM or VGA memory in the 0xa0000-0xeffff space, so this space can actually be used as a type of memory -- namely, cacheable for reads and write-invalidate for writes. Other systems have I/O devices in this address space, so the memory must be configured as completely non-cacheable. The determination of how this area is treated is controlled by the Fixed-address Memory Type Range Registers (Fixed MTRRs). To leave this address space as RAM, we don't have to do anything. To use it as a device space, we have to set <br /> option MTRR_ONLY_TOP_64K_FLASH<br /> <br /> in the mainboard Config file. The SBC 710 has devices in the 0xa0000-0xeffff address space -- namely, the Disk On Chip. The mainboard Config file will need to have this option set. <br /> <br /> Determining how to configure SDRAM<br /> <br /> SDRAM configuration is the single biggest problem for LinuxBIOS. In part it is due to the complexity of SDRAM, since we need to check over 17 different parameters to figure out how to determine the SDRAM control registers. That is only one of the problems. By definition, memory is not functioning before we program the SDRAM, so our code is very limited in what it can do, which makes for some very complex and hard-to-read assembly. Finally, poor chipset designs can make it hard to get it all right. Actual SDRAM parameters such as CAS latency, speed, etc. are maintained on a Serial EEPROM (SEEPROM) on the SDRAM module. The SEEPROM is accessed over a serial motherboard link called the SMBUS. LinuxBIOS needs to access the data in the SEEPROM and then configure SDRAM control registers. The actual SDRAM control registers are on the North Bridge, as expected; the South Bridge controls the SMBUS. To actually program the SDRAM control registers on the North Bridge, we must direct the South Bridge to send packets on the SMBUS to query the Serial EPROM on the SDRAM modules to find out their configuration. Fortunately, thanks to our many contributors, both these chips are supported. If the board vendor has not done anything to make it difficult to operate the SMBUS, everything should work fine. <br /> <br /> Test one: can we read the SMBUS? <br /> <br /> This program can be used to test SPD accessibility on systems with a PIIX4E. We were not sure if it would work, given that IBM on the Thinkpad T22 obscures this information. <br /> <br /> A quick note on the SMBUS <br /> <br /> A note on this program. You need to understand a bit about SMBUS to understand it. If you're doing a port you should understand it anyway! Here is a quick introduction. The data rate is roughly 100 Kbits/second. SMBUS is a serial bus found on most new motherboards. SMBUS is also sometimes called I2C, although that usage is being deprecated. SMBUS is a packet-oriented bus and is used for communications with many different systems on PCs, including smart batteries, sensor chips, and SDRAM. SMBUS packets contain a 7-bit address for selecting devices. This address in the SMBUS packet is shifted left one bit and, for read operations, OR'ed with a 1 in the low-order bit. Certain devices are assigned fixed addresses; SDRAM is one of them. Currently SDRAM occupies addresses 0x50 to 0x53. One thing that complicates SMBUS usage is that a system may have more than one SMBUS. For example, ASUS motherboards sometimes have two; IBM thinkpads also seem to have more than one. The motherboard vendors often obscure the existence of the SDRAM SMBUS by hiding it in hardware. On the ASUS CUA we had to find the enable control for SDRAM SMBUS by using a PCI analyzer to capture the I/O operations. <br /> <br /> Program operation <br /> <br /> Our simple program probes the SMBUS by enabling SMBUS access in the PIIX4E and then, first, enumerating all accessible devices on the SMBUS; and, second, seeing if any SDRAM devices can be accessed. We won't describe how the program does this, since if you're doing a port you need to have a thorough understanding of how it works. Walk through it line by line until you know what it does. <br /> <br /> Program output <br /> <br /> When we run the program we find that it correctly probes SDRAM in slot 0, the only SDRAM slot on the SBC 710. This result is very encouraging, since it means that the LinuxBIOS SDRAM setup code will probably work with no changes whatsoever. We have cleared the worst hurdle. <br /> <br /> Determining if and how to run the serial ports for debug messages <br /> <br /> The SBC 710 supports two serial ports. What we don't know is which of the two Winbond Super IO chips supports which serial port. There is no real question about our ability to drive the serial ports, the work will be in figuring out which chip to drive, and how to drive it. <br /> <br /> Which Super IO does what? <br /> <br /> There are two Super IOs on this card. They are both capable of running floppy, keyboard, serial, etc. For configuring LinuxBIOS we need to know which Super IO does which function. Fortunately we can probe the Super IOs from user mode and figure out, for all of the devices, which device is turned. This information will in turn guide the LinuxBIOS configuration. <br /> <br /> Building in new chipset support <br /> <br /> The only new chipset to this board is the Winbond w83877tf superio. Most winbond Super IO parts are pretty much the same. To start, we can borrow code from another winbond. Since the w83627hf has the most complete support, we borrow the code from that one. To set up the new Super IO, we generally need two files: superio.c (C setup) and setup_serial.inc (needed for very early low-level debug printing). The w83627hf provides both of these. To set up the new superio: <br /> cd src/superio/winbond<br /> mkdir w83877tf<br /> cp w83627hf/* w83877tf<br /> <br /> Next you need to look at the superio.c file and fix it up. You can see what needs to be done by comparing the three winbond superio directories. The differences are actually quite minor. Luckily this was the only new support needed for LinuxBIOS on the SBC 710. <br /> <br /> Setting up a &quot;mainboard&quot; tree for LinuxBIOS in the LinuxBIOS source<br /> <br /> The next step is to set up a mainboard directory for the mainboard. The general form of the tree for components and mainboards is src/part-type/vendor name/mainboard name, so for example for the ASUS CUA the tree in LinuxBIOS is: src/mainboard/asus/cua. The mainboard directory contains one mandatory file: Config. Config is used by the Python-based configuration tool to build several files for building LinuxBIOS for the mainboard. These files include a Makefile, ldscript file, crt0.S file, and several other files depending on what is in the Config file. Optional files include mainboard.c, for setting up mainboard-specific features of the mainboard; irq_tables.c, for setting up irq tables for the mainboard (irq tables are ALWAYS mainboard-specific); and config.example, so users have a sample config file for the mainboard when they build it. There are enough existing mainboard targets for LinuxBIOS that we can usually find a mainboard that is close enough to use as a starting point. Thanks to one of our contributors there is a generic 440bx mainboard directory (not really guaranteed to work for everyone) called src/mainboard/intel/l440bx. The Config file in this directory is definitely wrong, since it specifies the wrong superio. Here is the original Config file. As you can see it specifies most things correctly save for the wrong Super IO part (it uses and SMC part). Here is the corrected version of Config for the SBC 710. The differences are minor: <br /> 7c7<br /> &lt; mainboardinit superio/NSC/pc87309/setup_serial.inc<br /> ---<br /> &gt; # mainboardinit superio/NSC/pc87309/setup_serial.inc<br /> 13c13,15<br /> &lt; superio NSC/pc87309<br /> ---<br /> &gt; #superio NSC/pc87309<br /> &gt; nsuperio winbond/w83977ef keyboard=1<br /> &gt; nsuperio winbond/w83877tf<br /> 24a27,29<br /> &gt; <br /> &gt; option UPDATE_MICROCODE<br /> &gt; option MTRR_ONLY_TOP_64K_FLASH<br /> <br /> We have to comment out the setup_serial.inc (we don't know which one to use yet); and we change the Super IO parts. Finally we always enable UPDATE_MICROCODE since this board always uses PIIIs and we know that some of them will need microcode patches. If you check out the CVS tree, you can see we also add a mainboard.c: <br /> mainboard_fixup()<br /> {<br /> void southbridge_fixup(void);<br /> southbridge_fixup();<br /> }<br /> <br /> This code is needed to fix up the PIIX4E for Linux use. The other code files, irq_tables.c and do_ramtest.inc, are also used for the SBC 710. Finally we provide an example.config to make it easy to build LinuxBIOS for the SBC 710. <br /> <br /> Building a LinuxBIOS for your target <br /> <br /> To build LinuxBIOS, you need to create a config file. Here is the starting point for this mainboard. <br /> # Sample config file for technoland sbc710<br /> <br /> target tlsbc710<br /> <br /> mainboard technoland/sbc710<br /> <br /> # Enable Serial Console for debugging<br /> option SERIAL_CONSOLE<br /> option NO_KEYBOARD<br /> <br /> option INBUF_COPY<br /> option DEFAULT_CONSOLE_LOGLEVEL=9<br /> option DEBUG<br /> option USE_GENERIC_ROM=1<br /> <br /> # Path to your kernel (vmlinux)<br /> linux ~/src/bios/linux-2.4.7-sis<br /> <br /> # Kernel command line parameters<br /> commandline root=/dev/hda6 console=ttyS0,115200 FS_MODE=ro hda=flash hdb=flash<br /> <br /> We name the target directory, the mainboard, and set some options. For more information on the options in a configuration file see the CVS tree; look in Documentation at the configmanual.ps document. To build this linuxbios tree, you need to figure out where you want to build it, figure out where you linux is, and fix the file as needed. For testing we take the file as is and run the config tool: <br /> python ~/src/freebios/util/config/NLBConfig.py config.example ~/src/freebios/<br /> <br /> The build is fine. <br /> <br /> Burning a FLASH or DoC part <br /> <br /> You will next need to burn the 256KB flash part used in the SBC 710. For this purpose we use our AMD SMP systems and either the MTD utilities or a user-mode program. We will be experimenting with MTD on the SBC 710 as well. <br /> <br /> Running it; fixing problems</div>

Rminnich http://www.coreboot.org/Welcome_to_coreboot 2005-03-01T16:16:17Z

<p>Rminnich: </p> <hr /> <div>Welcome to the LinuxBIOS Wiki.<br /> <br /> LinuxBIOS is an Open Source project aimed at replacing the normal BIOS with a little bit of hardware initialization and a compressed Linux kernel that can be booted from a cold start. The project was started as part of clustering research work in the Cluster Reseach Lab at the Advanced Computing Laboratory at Los Alamos National Laboratory. The primary motivation behind the project was the desire to have the operating system gain control of a cluster node from power on. Other beneficial consequences of using LinuxBIOS include needing only two working motors to boot (cpu fan and power supply), fast boot times (current fastest is 3 seconds), and freedom from proprietary (buggy) BIOS code, to name a few. These secondary benefits are numerous and have helped gain support from many vendors in both the high performance computing as well as embedded computing markets.<br /> <br /> [[MB supported in freebios v2]]<br /> <br /> [[Download freebios v2]]<br /> <br /> [[Payloads]]<br /> <br /> [[FAQ]]<br /> <br /> [[Port Guides]]</div>

Rminnich http://www.coreboot.org/FAQ 2005-03-01T16:07:29Z

<p>Rminnich: </p> <hr /> <div>General<br /> <br /> <br /> What is LinuxBIOS? <br /> <br /> Why do we need LinuxBIOS? <br /> <br /> Who is working on LinuxBIOS? <br /> <br /> Who is funding LinuxBIOS? <br /> <br /> Will LinuxBIOS work on my machine? <br /> <br /> What commercial products use LinuxBIOS? <br /> <br /> How can I help with LinuxBIOS? <br /> <br /> Developer<br /> <br /> <br /> Where is the mailing list archived? <br /> Where do I get the code? <br /> <br /> How do I build? <br /> <br /> Why is the code so complicated and what can I do to make it easier? <br /> <br /> What chipsets are supported? <br /> <br /> What is this POST card thing? <br /> <br /> How do I contribute my changes? <br /> <br /> How do I re-flash the BIOS? <br /> <br /> How do I actually burn a flash ROM? <br /> <br /> How do I burn a DoC? <br /> <br /> Can I do any serious damage mucking around with this stuff? <br /> <br /> How do I put a filesystem on DoC? <br /> <br /> How do I turn off embedded sis630 devices? <br /> <br /> What is a PIRQ table? <br /> <br /> How do I set up etherboot with LinuxBIOS? <br /> <br /> How do I set GEODE video? <br /> <br /> How do I set up testbios? <br /> <br /> <br /> <br /> <br /> General<br /> <br /> What is LinuxBIOS? <br /> <br /> LinuxBIOS aims to replace the normal BIOS found on PCs, Alphas, and other machines with a Linux kernel that can boot Linux from a cold start. LinuxBIOS is primarily Linux - about 10 lines of patches to the current Linux kernel. Additionally, the startup code - about 500 lines of assembly and 5000 lines of C - executes 16 instructions to get into 32-bit mode and then performs DRAM and other hardware initialization required before Linux can take over. <br /> <br /> <br /> Our primary motivation for the project was maintenance of large clusters, but not surprisingly interest and contributions have come from people with varying backgrounds. <br /> <br /> Why do we need LinuxBIOS? <br /> <br /> Current PCs used as cluster nodes depend on a vendor-supplied BIOS for booting. The BIOS in turn relies on inherently unreliable devices such as floppy disks and hard drives to boot the operating system. In addition, current BIOS software is unable to accommodate non-standard hardware making it difficult to support experimental work. The BIOS is slow and often erroneous and redundant and, most importantly, maintenance is a nightmare. Imagine walking around with a keyboard and monitor to every one of the 128 nodes in a cluster to change one BIOS setting. <br /> <br /> <br /> The LinuxBIOS gunzip's the Linux kernel straight out of NVRAM and essentially requires no moving parts other than the fan. It does a minimal amount of hardware initialization before jumping to the kernel start and lets Linux do the rest. As a result, it is much faster (current record 3 seconds), which has sparked interest in the consumer electronics community as well. Moreover, updates can be performed over the network. <br /> <br /> <br /> Using a real operating system to boot another operating system provides much greater flexibility than using a simple netboot program or the BIOS. Because Linux is the boot mechanism, it can boot over standard Ethernet or over other interconnects such as Myrinet, Quadrics, or SCI. It can use SSH connections to load the kernel, or it can use the InterMezzo caching file system or traditional NFS. Cluster nodes can be as simple as they need to be - perhaps as simple as a CPU and memory, no disk, no floppy, and no file system. The nodes will be much less autonomous thus making them easier to maintain. <br /> <br /> Who is working on LinuxBIOS? <br /> <br /> The LinuxBIOS project was started in the winter of 1999 in the Advanced Computing Laboratory at Los Alamos National Laboratory by Ron Minnich. Two undergraduate students, James Hendricks and Dale Webster spent their winter vacation putting together the proof of concept implementation. <br /> <br /> <br /> Since then, a long list of people have contributed both in discussions and actual code. See our contributors page for details. Please don't be shy and let us know if you are missing from the list. It's not a purposeful omission, just an unfortunate mistake. <br /> <br /> Who is funding LinuxBIOS? <br /> <br /> The LinuxBIOS project is funded by the Los Alamos Computer Science Institute and the Department of Energy's Office of Science. <br /> <br /> Will LinuxBIOS work on my machine? <br /> <br /> See the status page for which mainboards are supported. Also, see the products page for a list of vendors selling products running LinuxBIOS. <br /> <br /> What commercial products use LinuxBIOS? <br /> <br /> See the products page. <br /> <br /> How can I help with LinuxBIOS? <br /> <br /> Contact Ron Minnich for projects related to LinuxBIOS. <br /> <br /> <br /> <br /> Developer<br /> <br /> Where is the mailing list archived? <br /> <br /> The best archive out there is at the University of Maryland. <br /> <br /> <br /> In addition, we've pieced together an archive that dates back to about the beginning of 2000 (including messages that were going to the freebios and openbios mailing lists). <br /> <br /> Where do I get the code? <br /> <br /> See download. <br /> <br /> How do I build? <br /> <br /> See the documentation. For help generating a config file, see Generate a config file. <br /> <br /> Why is the code so complicated and what can I do to make it easier? <br /> <br /> The reason is the complexity of the problem. We support a lot of hardware, and a given chip on a given board will most likely not be configured quite the same as the same chip on some other board. <br /> <br /> <br /> To help make code navigation easier, pick a target and build that target. Then, in the build directory, type make tags or make etags to get your favorite tags file. <br /> <br /> What chipsets are supported? <br /> <br /> See status for the most up-to-date info.. <br /> <br /> What is this POST card thing? <br /> <br /> A POST card will save your life. The term POST means Power On Self Test and comes from the original IBM specifications for the BIOS. Port 80 is a pre-defined port to which programs can output a byte. The POST card displays the byte in hex on its 2 digit display. We use a lot of POST codes in LinuxBIOS, so if you can tell us the POST code you see, we will have some idea of what happened. <br /> <br /> <br /> If your LinuxBIOS machine is working properly, you will see it count up from 0xd0 to 0xd9 (while it is gunzipping the kernel) and then display 0x98 (Linux idle loop). <br /> <br /> How do I contribute my changes? <br /> <br /> Any one without commit privileges (which is most of you) need to get changes approved by Ron Minnich. <br /> <br /> How do I re-flash the BIOS? <br /> <br /> Download the appropriate flash update utility. Build the romimage as explained above and use the flash update utility to update the BIOS. Be warned that not all update utilities allow you to load your own BIOS image. For example, Intel decided to disallow it for the MS440GX mainboard (probably after hearing about us!) Here are some mainboard specific directions. <br /> <br /> SiS 630/950 M/Bs<br /> Ollie Lho provided us with flash utilities for these boards under freebios/util/sis. <br /> flash_on turns on the flash write enable. This needs to be run before loading the DoC drivers. <br /> flash_rom allows you to use your SiS 630/950 M/Bs as a flash programmer. It currently supports JEDEC flash parts, AMD am29f040b models, MXIC MX29F002 models, and SST28SF040C models. <br /> Intel L440GX<br /> Get the System Update Package directly from Intel. mcopy the ten files created from running make phlash onto the Intel flash burner disk and use the update utility to burn the BIOS. To restore the original BIOS, set the recovery boot jumper on the motherboard, put the floppy in, and it will load and reflash the original BIOS. <br /> How do I actually burn a flash ROM? <br /> <br /> Buy your favorite flash burner (we use a Needham Electronics EMP 30). Use make floppy to create the romimage and copy it to a floppy. Then use the provided software to burn the flash. <br /> <br /> How do I burn a DoC? <br /> <br /> Currently, only the DoC Millennium is supported. See the documentation. <br /> <br /> Can I do any serious damage mucking around with this stuff? <br /> <br /> Any time you stick your hand into an open machine while the power is on, you're risking life and limb. That said, there are also some other not-so-nice things that can happen if you mess up (not that we would know). <br /> <br /> Incorrect inserstion of the flash (1 casualty) <br /> Incorrect jumper settings (1 casualty) <br /> Aggressive and/or inappropriate use of metal objects such as screwdrivers (2 casualties) <br /> Miscellaneous miswirings and mishandlings (3+ casualties) <br /> <br /> And finally a note on electrostatic discharge (ESD) and ESD protection thanks to Bari Ari. <br /> <br /> <br /> ESD can damage disk drives, boards, DoC's and other parts. The majority of the time, ESD events cause the component to degrade, but not fail testing procedures, resulting in failure at a later date. Because components do not fail immediately, technicians often underestimate the cost of not using ESD prevention measures. Provide at minimum some ESD protection by wearing an antistatic wrist strap attached to the chassis ground on your system when handling parts. <br /> <br /> <br /> Always handle boards carefully. They can be extremely sensitive to ESD. Hold boards only by their edges. After removing a board from its protective wrapper or from the system, place it component side up on a grounded, static free surface. Use a conductive foam pad if available. Do not slide the board over any surface. <br /> <br /> <br /> To further reduce the chances of ESD, you should create an ESD safe workstation that includes at minimum: <br /> <br /> Conductive rubber mat, with a lead wire that can be connected to a metal surface to create a ground. <br /> ESD wrist strap, which has a resistor inside the strap and a lead wire that can be connected to a metal surface as a ground. The grounding wire on the wrist strap should have between 1 and 10 Megaohms of resistance. The resistor should protect you in case you come in contact with a voltage source. If the resistor is bad or not included, the wrist strap is useless. An accidental shock could be serious and even deadly! <br /> Table or workspace that is clean, clear of dust, and away from electrical machinery or other equipment that generates electrical currents. <br /> The idea is to ensure that all components you are going to interact with have the same charge. By connecting everything to the computer case, you ensure that the components of the case, the chair, and your body all have the same charge. If every object has the same charge, the electrons will not jump from one object to another minimizing the risk of ESD damage. <br /> How do I put a filesystem on DoC? <br /> OK, here is a little HOWTO on how to set up MTD with a file system. <br /> <br /> This is a m810lmr, booting out of DoC. I am going to reserve the first 2M for kernel. So the layout will be the first 2M for linuxbios and kernel, and 6M for a file system. Kernel is 2.4.17, with linux-2.4.17-sis.patch from linuxbios source tree, and config-2.4.17-sis from the linuxbios source tree. Mainboard is the pcchips m810lmr. <br /> <br /> <br /> So I: <br /> modprobe doc2001 <br /> modprobe docprobe <br /> dmesg <br /> <br /> <br /> <br /> which shows: <br /> <br /> <br /> DiskOnChip Millennium found at address 0xFFFC8000 <br /> Flash chip found: Manufacturer ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC) <br /> 1 flash chips found. Total DiskOnChip size: 8 MiB <br /> mtd: Giving out device 0 to DiskOnChip Millennium <br /> Ignoring DiskOnChip Millennium at 0xFFFCA000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFCC000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFCE000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFD0000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFD2000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFD4000 - already configured <br /> Ignoring DiskOnChip Millennium at 0xFFFD6000 - already configured <br /> (etc..) <br /> Now I need MTD utilities. <br /> So I: <br /> cvs -d :pserver:anoncvs@cvs.infradead.org:/home/cvs login <br /> CVS password: <br /> <br /> (password is anoncvs) <br /> Then: <br /> cvs -d :pserver:anoncvs@cvs.infradead.org:/home/cvs co mtd <br /> <br /> <br /> Forget the drivers and such, you don't need them. What you need is the tools. <br /> cd mtd/tools <br /> make <br /> <br /> <br /> Go ahead and copy the executables somewhere handy, you'll need them. <br /> <br /> <br /> Now we need to make the last 6M into a &quot;disk&quot;. We need to format it. The tool is nftl_format, so: <br /> [root@carly util]# ./nftl_format <br /> $Id: nftl_format.c,v 1.17 2001/08/29 14:28:48 dwmw2 Exp $ <br /> Usage: ./nftl_format [ []] <br /> [root@carly util]# expr 2048 \* 1024 <br /> 2097152 <br /> [root@carly util]# expr 6 \* 1024 \* 1024 <br /> 6291456 <br /> [root@carly util]# ./nftl_format /dev/mtd0 2097152 6291456 <br /> $Id: nftl_format.c,v 1.17 2001/08/29 14:28:48 dwmw2 Exp $ <br /> Phase 1. Checking and erasing Erase Zones from 0x00200000 to 0x00800000 <br /> Phase 2.a Writing NFTL Media Header and Bad Unit Table <br /> Phase 2.b Writing Spare NFTL Media Header and Spare Bad Unit Table <br /> Phase 3. Writing Unit Control Information to each Erase Unit <br /> <br /> <br /> we now have a formatted disk in there. We can now partition it. <br /> <br /> <br /> [root@carly util]# modprobe nftl <br /> dmesg shows LOTS of errors, since this was never partitioned ... <br /> <br /> <br /> Also, if you don't have /dev/nftla, <br /> [root@carly util]# mknod /dev/nftla b 93 0 <br /> <br /> <br /> Don't use the script just yet, it makes /dev/nftla as b 93 16, which is the wrong unit #. <br /> <br /> <br /> now fdisk /dev/nftla <br /> <br /> <br /> [root@carly util]# fdisk /dev/nftlA <br /> Command (m for help): n <br /> Command action <br /> e extended <br /> p primary partition (1-4) <br /> p <br /> Partition number (1-4): 1 <br /> First cylinder (1-1, default 1): <br /> Using default value 1 <br /> Command (m for help): p <br /> Disk /dev/nftlA: 1 heads, 12224 sectors, 1 cylinders <br /> Units = cylinders of 12224 * 512 bytes <br /> Device Boot Start End Blocks Id System <br /> /dev/nftlA1 1 1 6111+ 83 Linux <br /> Partition 1 has different physical/logical endings: <br /> phys=(768, 0, 0) logical=(0, 0, 12224) <br /> Partition 1 does not end on cylinder boundary: <br /> phys=(768, 0, 0) should be (768, 0, 12224) <br /> Command (m for help): w <br /> The partition table has been altered! <br /> Calling ioctl() to re-read partition table. <br /> WARNING: If you have created or modified any DOS 6.x partitions, please see the fdisk manual page for additional information. <br /> Syncing disks. <br /> [root@carly util]# mknod /dev/nftlA1 b 93 1 <br /> [root@carly util]# mke2fs /dev/nftlA1 <br /> mke2fs 1.23, 15-Aug-2001 for EXT2 FS 0.5b, 95/08/09 <br /> Filesystem label= <br /> OS type: Linux <br /> Block size=1024 (log=0) <br /> Fragment size=1024 (log=0) <br /> 1528 inodes, 6111 blocks <br /> 305 blocks (4.99%) reserved for the super user <br /> First data block=1 <br /> 1 block group <br /> 8192 blocks per group, 8192 fragments per group <br /> 1528 inodes per group <br /> Writing inode tables: done <br /> Writing superblocks and filesystem accounting information: done <br /> <br /> <br /> This filesystem will be automatically checked every 37 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. <br /> <br /> <br /> [root@carly util]# mount /dev/nftlA1 /mnt <br /> [root@carly util]# cd /mnt <br /> [root@carly mnt]# df . <br /> Filesystem 1k-blocks Used Available Use% Mounted on <br /> /dev/nftlA1 5915 13 5597 1% /mnt <br /> [root@carly mnt]# <br /> <br /> <br /> and so you now have an ext2 file system on the DoC. <br /> <br /> <br /> ron <br /> <br /> How do I turn off embedded sis630 devices? <br /> From aip@cwlinux.com Mon Mar 25 08:54:07 2002 <br /> Date: Mon, 25 Mar 2002 22:07:54 +0800 <br /> From: Andrew Ip <br /> To: Kei Furuuchi <br /> Cc: linuxbios@lanl.gov <br /> Subject: Re: How to turn off unused pci device. <br /> Hi, <br /> &gt; I have pcchips m758lmr which has audio chip besides sis630. <br /> &gt; those functions in sis630 are not used in the motherboard. <br /> &gt; But, the functions keep coming up. How do I turn off those? <br /> The following is from Nikolai Valdych previous message. Hope this help. <br /> -Andrew <br /> -- <br /> Andrew Ip <br /> Email: aip@cwlinux.com <br /> Actualy, it was pretty simple 0x7c00 - All devices enabled, You play with first 4 bits only. Cos there are 4 devices, so you have any combination of 4 bits. Set bit to 1 to turn off the device, bit 0 to enable it. This is the device list: <br /> Multimedia Audio controler <br /> Modem controler <br /> Ethernet sis930 controler <br /> USB controler. <br /> For example, to turn off Ethernet + USB it would be: <br /> 0x7c0c -&gt; 1100 in binary (first 4 bits) <br /> To turn off Multimedia audio : <br /> 0x7c01 -&gt; 0001 <br /> in binary and so on... maybe there are more detail, but this is enogh for me, Ollie, again thanks! <br /> nikolai <br /> p.s. though my modem is not yet working..... damn driver...... <br /> What is a PIRQ table? <br /> <br /> From Adam Sulmicki: <br /> <br /> <br /> I found beautfiul descrition of the BIOS implementation of the PIRQ in<br /> the red PCI book.<br /> <br /> I found the description of the $PIR data structure in the<br /> http://www.microsoft.com/hwdev/archive/BUSBIOS/pciirq.asp<br /> <br /> looking over linuxbios sources I see that it saves the $PIR data structure<br /> somewhere between 0xf0000 &amp; 0x100000.<br /> <br /> so it seems I'll have to search for $PIR and then save it before copying<br /> over our bios. sigh. hoped for some fixed address in mem.<br /> <br /> -- <br /> Adam<br /> http://www.eax.com The Supreme Headquarters of the 32 bit registers<br /> <br /> How do I set up etherboot with LinuxBIOS? <br /> <br /> Note from Ron: I have edited this somewhat to remove Geode-specific items. <br /> <br /> Christer Weinigel writes: <br /> To: rminnich@lanl.gov<br /> Cc: linuxbios@lanl.gov<br /> Subject: Re: LinuxBIOS + Etherboot HOWTO?<br /> <br /> <br /> I had some trouble using LinuxBIOS + etherboot... <br /> <br /> <br /> My bad, I messed up and used mkelfImage-1.6 that I got from ftp.lnxi.com, when I realized that I ought to use the one from freebios/util everything started working. <br /> <br /> <br /> Here's what I did to get LinuxBIOS + Etherboot loading and booting a Linux kernel using TFTP. <br /> <br /> <br />    /Christer <br /> <br /> <br /> Get etherboot-5.0 from the CVS tree on etherboot.sourceforge.net. <br /> <br /> <br /> Modify etherboot-5.0/src/Config, comment out: <br /> <br /> # BIOS select don't change unless you know what you are doing<br /> #CFLAGS32+= -DPCBIOS<br /> <br /> <br /> <br /> and uncomment the following: <br /> <br /> # Options to make a version of Etherboot that will work under linuxBIOS.<br /> CFLAGS32+= -DLINUXBIOS -DCONFIG_TSC_CURRTICKS -DCONSOLE_SERIAL \<br /> -DCOMCONSOLE=0x3f8 -DCOMPRESERVE -DCONFIG_PCI_DIRECT -DELF_IMAGE <br /> <br /> <br /> <br /> Compile Etherboot to make an elf file for your ethernet card: <br /> <br /> make bin32/natsemi.elf<br /> <br /> <br /> <br /> Compile and install mkelfImage from freebios/util/mkelfImage. <br /> <br /> <br /> Create a bootimage to put on your TFTP server: <br /> <br /> mkelfImage --command-line=&quot;root=/dev/hda2 console=ttyS0,38400&quot; \<br /> --kernel vmlinux -o /tftpboot/kernel<br /> <br /> <br /> <br /> Finally, make sure that your BOOT/DCHP server is answering and that the TFTP server is active. <br /> <br /> <br /> Tell LinuxBIOS to boot an elf Image, and tell LinuxBIOS where it is: <br /> <br /> option USE_ELF_BOOT=1<br /> <br /> <br /> <br /> I have placed natsemi.elf in the first 64k of my BIOS flash chip, and LinuxBIOS in the second 64k. <br /> <br /> insmod bios.o<br /> dd if=natsemi.elf of=/dev/bios bs=64k<br /> dd if=linuxbios.rom of=/dev/bios bs=64k seek=1<br /> <br /> <br /> <br /> Finally boot LinuxBIOS. <br /> <br /> How do I set GEODE video? <br /> From christer@weinigel.se Wed Nov 27 07:47:17 2002<br /> Date: 27 Nov 2002 10:55:01 +0100<br /> From: Christer Weinigel <br /> To: Adam Bezanson <br /> Cc: linuxbios@clustermatic.org<br /> Subject: Re: Geode Kernel Config<br /> <br /> &quot;Adam Bezanson&quot; writes:<br /> <br /> &gt; I've got an Eval card from National Semi that contains<br /> &gt; the SC1200. I'd like to try LinuxBios on it.<br /> &gt; I've downloaded both the 2.4.18 and 2.4.19 kernels to start with.<br /> &gt; What patches do I need to apply to the kernel?<br /> &gt; Is there a config file I can use to configure the kernel, or<br /> &gt; should I do it manually?<br /> <br /> A normal 2.4 Linux kernel will work fine as long as you compile for a<br /> 586 CPU (CONFIG_M586), not Pentium or higher (CONFIG_M586TSC and up)<br /> since the TSC behaves a bit differently.<br /> <br /> If you want support for the watchdog or the GPIO pins in a 2.4 kernel,<br /> you can find an old patch from me at:<br /> <br /> http://groups.google.com/groups?selm=20020226015215.20118F5B%40acolyte.hack.org&amp;oe=UTF-8&amp;output=gplain<br /> <br /> An updated version of this patch has been included in Linux 2.5. Alan<br /> Cox' 2.5 kernel also has support for doing DMA on the SC1200 IDE<br /> controller; I don't know if there is a corresponding patch for 2.4.<br /> <br /> Other than that, take a look at the freebios/src/mainboard/nano/nano<br /> directory and make a copy of it. All you should have to do is to<br /> modify the Pin Multiplexing Register (PMR) and Miscellaneous Config<br /> Register (MCR) in the Config file and to modify the irq assignments.<br /> <br /> Depending on what you want to do, there are a few limitations with<br /> the current LinuxBIOS on the SC1200: <br /> <br /> There is no video support in LinuxBIOS itself, so you won't get<br /> any video until you have loaded the NatSemi Geode Linux<br /> framebuffer driver (can be found at www.linux4.tv under the<br /> heading SP1SC10 Platform Image).<br /> <br /> There is no SMM/VSA support at all, this means that anything<br /> relying on it won't work. What this means is that Audio won't<br /> work.<br /> <br /> Other than that everything works fine, IDE in PIO mode, the PCI bus,<br /> watchdog, GPIOs, everything.<br /> <br /> /Christer<br /> <br /> -- <br /> &quot;Just how much can I get away with and still go to heaven?&quot;<br /> <br /> Freelance consultant specializing in device driver programming for Linux <br /> Christer Weinigel http://www.weinigel.se<br /> _______________________________________________<br /> Linuxbios mailing list<br /> Linuxbios@clustermatic.org<br /> http://www.clustermatic.org/mailman/listinfo/linuxbios<br /> <br /> How do I set up testbios? <br /> From daubin@actuality-systems.com Wed Oct 6 10:23:10 2004<br /> Date: Tue, 5 Oct 2004 15:19:24 -0400<br /> From: Dave Aubin <br /> To: linuxbios@clustermatic.org<br /> Subject: RE: Testbios help with nvidia 6800Gt and simple how to<br /> <br /> I've taken the time to put together a simple testbios faq.<br /> I hope it is helpful. Feedback and additions are welcome.<br /> <br /> Thanks,<br /> Dave<br /> <br /> Testbios (vgabios) Faq<br /> <br /> Date: 10/5/2004<br /> Author(s): David Aubin daubin@actuality-systems.com<br /> <br /> Purpose: Testbios is an i386 emulator that sits on top of user<br /> space linux. It's primary purpose is to provide program video rom's in<br /> to<br /> the cached memory area.<br /> <br /> Faq Contents:<br /> 1. Where to obtain testbios<br /> 2. Prerequisites<br /> 3. How to build testbios<br /> 4. How to retrieve a good video bios<br /> 5. How to use testbios<br /> <br /> 1. Where to obtain testbios<br /> A. Testbios(vgabios) can be retrieved from the<br /> linuxbios/freebios source tree:<br /> http://www.linuxbios.org/developer/download/index.html<br /> <br /> 2. Prerequisites<br /> A. You must have installed pci-utils<br /> i. Get<br /> http://atrey.karlin.mff.cuni.cz/~mj/pciutils.shtml<br /> <br /> 3. How to build testbios:<br /> A. cd freebios/util/vgabios<br /> B. Edit ./Makefile and fill in the correct values for your<br /> environment<br /> I build on a 64 AMD so my makefile looks like this<br /> <br /> --Being ./Makefile for x64--<br /> CC = gcc<br /> ARCH := $(shell uname -m | sed -e s,i[3456789]86,i386,)<br /> INCLUDE = -I ../pciutils-2.1.11<br /> CFLAGS = -Wall -Ix86emu/include -O2 -g $(INCLUDE)<br /> <br /> INTOBJS = int10.o int15.o int16.o int1a.o inte6.o<br /> OBJECTS = testbios.o helper_exec.o helper_mem.o $(INTOBJS)<br /> LDFLAGS = -static-libgcc -static<br /> <br /> LIBS = x86emu/src/x86emu/libx86emu.a<br /> ../pciutils-2.1.11/lib/libpci.a<br /> <br /> # user space pci is the only option right now.<br /> OBJECTS += pci-userspace.o<br /> <br /> ifeq ($(shell if test &quot;$(ARCH)&quot; == &quot;x86_64&quot; ; then echo 1; fi), 1)<br /> CFLAGS +=-m32 -march=i386<br /> endif<br /> <br /> all: testbios<br /> <br /> testbios: $(OBJECTS) $(LIBS)<br /> $(CC) $(CFLAGS) -o testbios $(OBJECTS) $(LDFLAGS)<br /> $(LIBS)<br /> <br /> helper_exec.o: helper_exec.c test.h<br /> <br /> x86emu/src/x86emu/libx86emu.a:<br /> $(MAKE) -C x86emu/src/x86emu/ -f makefile.linux<br /> <br /> clean:<br /> $(MAKE) -C x86emu/src/x86emu/ -f makefile.linux clean<br /> rm -f *.o *~ testbios<br /> <br /> distclean: clean<br /> $(MAKE) -C x86emu/src/x86emu/ -f makefile.linux clean<br /> <br /> --End ./Makefile--<br /> <br /> C. Edit ~vgabios/x86emu/src/x86emu/makefile.linux and fill in<br /> the correct values for your environment<br /> I build on a 64 AMD so my makefile looks like this<br /> <br /> --Begin ~vgabios/x86emu/src/x86emu/makefile.linux--<br /> ########################################################################<br /> #####<br /> #<br /> # Realmode X86 Emulator<br /> Library<br /> #<br /> # Copyright (C) 1996-1999 SciTech Software, Inc.<br /> #<br /> #<br /> ========================================================================<br /> #<br /> # Permission to use, copy, modify, distribute, and sell this software<br /> and<br /> # its documentation for any purpose is hereby granted without fee,<br /> # provided that the above copyright notice appear in all copies and<br /> that<br /> # both that copyright notice and this permission notice appear in<br /> # supporting documentation, and that the name of the authors not be<br /> used<br /> # in advertising or publicity pertaining to distribution of the<br /> software<br /> # without specific, written prior permission. The authors makes no<br /> # representations about the suitability of this software for any<br /> purpose.<br /> # It is provided &quot;as is&quot; without express or implied warranty.<br /> #<br /> # THE AUTHORS DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,<br /> # INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN<br /> NO<br /> # EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR<br /> # CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS<br /> OF<br /> # USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR<br /> # OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE<br /> OR<br /> # PERFORMANCE OF THIS SOFTWARE.<br /> #<br /> #<br /> ========================================================================<br /> #<br /> # Descripton: Linux specific makefile for the x86emu library.<br /> #<br /> ########################################################################<br /> #####<br /> <br /> TARGETLIB = libx86emu.a<br /> <br /> <br /> OBJS=\<br /> debug.o \<br /> decode.o \<br /> fpu.o \<br /> ops.o \<br /> ops2.o \<br /> prim_ops.o \<br /> sys.o<br /> <br /> $(TARGETLIB): $(OBJS)<br /> ar rv $(TARGETLIB) $(OBJS)<br /> <br /> INCS = -I. -Ix86emu -I../../include<br /> CFLAGS += -D__DRIVER__ -DFORCE_POST -D_CEXPORT= -DNO_LONG_LONG<br /> -DDEBUG<br /> ARCH := $(shell uname -m | sed -e s,i[3456789]86,i386,)<br /> ifeq ($(shell if test &quot;$(ARCH)&quot; == &quot;x86_64&quot; ; then echo 1; fi),<br /> 1)<br /> CFLAGS +=-m32 -march=i386<br /> endif<br /> <br /> <br /> .c.o:<br /> # gcc -m32 -march=i386 -g -O -Wall -c $(CFLAGS) $(INCS) $*.c<br /> gcc -g -O -Wall -c $(CFLAGS) $(INCS) $*.c<br /> <br /> .cpp.o:<br /> # gcc -m32 -march=i386 -c $(CFLAGS) $(INCS) $*.cpp<br /> gcc -c $(CFLAGS) $(INCS) $*.cpp<br /> <br /> clean:<br /> rm -f *.a *.o<br /> <br /> validate: validate.o libx86emu.a<br /> gcc -o validate validate.o -lx86emu -L.<br /> <br /> --End ~vgabios/x86emu/src/x86emu/makefile.linux--<br /> <br /> D. Once built you could have a 32bit testbios executable made.<br /> Depending on your embedded environment you might want to have it built<br /> shared as the above example makes it static. Just remove -static-libgcc<br /> -static from the LDFLAGS on ./Makefile if you wish to have it built<br /> shared.<br /> <br /> 4. How to retrieve a good video bios<br /> A. There are sites that have video bios roms on their website.<br /> I know of this one for nvidia cards:<br /> http://whitebunny.demon.nl/hardware/chipset_nvidia.html<br /> B. However you should be able to retrieve your own video bios<br /> as well<br /> with linux.<br /> i. Boot up a machine with a commercial bios (not linux<br /> bios) with<br /> the video card you wish to work under linux bios.<br /> ii. From the command line enter:<br /> dd if=/dev/mem of=vgabios.bin skip=1536 count=128 or <br /> dd if=/dev/mem of=vgabios.bin bs=1k count=64 skip=786432<br /> <br /> This assumes you card's bios is cached in 0xc0000. You<br /> can see where and how much your card's bios is using by<br /> doing a cat iomem | grep &quot;Video ROM&quot;<br /> <br /> a. dd Explained (man dd to learn more):<br /> 1. if is the location to retrieve from.<br /> 2. of is the output file (your rom image)<br /> 3. skip jumps n blocks where the default n is<br /> 512 bytes<br /> 4. count is how many blocks you wish to read<br /> 5. bs is the block size<br /> C. You now have a video bios image<br /> <br /> 5. How to use testbios<br /> A. Currently testbios only works from user space linux<br /> (10/4/04)<br /> B. Example from a linux command line or script enter the<br /> following to<br /> get your video bios programmed:<br /> ./testbios -s 65536 --abseg /dev/mem ./vgabios.bin<br /> i. Testbios explained<br /> a. -s how much of the video bios is there<br /> b. --abseg where would you like to write this (/dev/mem<br /> default)<br /> c. filename of video bios<br /> d. -d diag mode <br /> 1. How to get pci busdevfn<br /> A. lspci<br /> B. look for your video card<br /> Example:<br /> 2:00:00<br /> 2 (00 &lt;&lt; 3) | 00 = 0x200<br /> Example:<br /> 00:12.0:<br /> 0 (12 &lt;&lt; 3) | 0 = 0x90<br /> e. -t dump <br /> f. -c codesegment Where do you want to start, default is<br /> 0xc0000<br /> g. -b base Where do you want base to be default is<br /> 0xc000<br /> h. -i instruction pointer usually left off as the<br /> default<br /> <br /> <br /> <br /> -----Original Message-----<br /> From: linuxbios-admin@clustermatic.org<br /> [mailto:linuxbios-admin@clustermatic.org] On Behalf Of Dave Aubin<br /> Sent: Tuesday, October 05, 2004 2:22 PM<br /> To: Richard Smith<br /> Cc: linuxbios@clustermatic.org<br /> Subject: RE: Testbios help with nvidia 6800Gt and simple how to<br /> <br /> Hi,<br /> <br /> Thank you:) Yes, it was at 0xc0000-0xc7fff, which is only 32k.<br /> But the image I got from the windows tool was 64k (double 8000).<br /> Weird. I would like to stay away from window tools.<br /> The info you provided is nice. I wish there was a way for us To make<br /> a faq and we could add this to the testbios faq. There Is a lot of good<br /> info on the clustermatic list, but it is all Dispersed. <br /> Ron if I write a simple faq can you provide some mechanism to Allow<br /> updates to it?<br /> <br /> Thanks,<br /> Dave <br /> <br /> -----Original Message-----<br /> From: Richard Smith [mailto:rsmith@bitworks.com]<br /> Sent: Tuesday, October 05, 2004 2:16 PM<br /> To: Dave Aubin<br /> Cc: linuxbios@clustermatic.org<br /> Subject: Re: Testbios help with nvidia 6800Gt and simple how to<br /> <br /> Dave Aubin wrote:<br /> <br /> &gt; It seems my dd returned an unusable binary. I found a good binary for<br /> <br /> &gt; The nvidia card from here:<br /> &gt; http://whitebunny.demon.nl/hardware/chipset_nvidia.html<br /> &gt; <br /> <br /> I was wondering about your dd command that but I had not had a chance to<br /> respond yet.<br /> <br /> This is what I use:<br /> <br /> dd if=/dev/mem of=vbios.bin bs=1k count=64 skip=786432<br /> <br /> That will rip the bios from 0x0c0000. You can verify that you actually<br /> have bios there with<br /> <br /> 'hd -s 0x0c0000 -n 256 /dev/mem'<br /> <br /> in some cases it may be located at 0x0e0000 rather than 0x0c0000.<br /> <br /> It should start with the 0x55aa (Little endian) or 0xaa55 (big endian)<br /> and futher on you should see some text identifying the bios.<br /> <br /> <br /> --<br /> Richard A. Smith<br /> <br /> <br /> _______________________________________________<br /> Linuxbios mailing list<br /> Linuxbios@clustermatic.org<br /> http://www.clustermatic.org/mailman/listinfo/linuxbios<br /> <br /> <br /> <br /> <br />  </div>

Rminnich