https://www.coreboot.org/api.php?action=feedcontributions&user=Rminnich&feedformat=atomcoreboot - User contributions [en]2024-03-19T07:38:52ZUser contributionsMediaWiki 1.40.0https://www.coreboot.org/index.php?title=Project_Ideas&diff=23691Project Ideas2017-01-30T15:04:02Z<p>Rminnich: </p>
<hr />
<div>The following are ideas that have been proposed in the community. 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. But of course these are not the only things that could be done. Maybe you have a great idea that we just didn't think of yet. Please let us know! <br />
<br />
<br />
Prospective [[GSoC]] students' application should expand on the ideas and provide specific information in the application. If you have questions or comments, please please contact the coreboot [[Mailinglist|mailing list]] or visit our [[IRC]] channel <code>#coreboot</code> on [https://webchat.freenode.net irc.freenode.net]. Our [[GSoC#Mentors]] are here to help.<br />
<br />
<br />
= coreboot Projects =<br />
<br />
== coreboot mainboard test suite ==<br />
<br />
Create a tool (possibly a bootable CD/USB drive image) to be run on a platform booted with coreboot (using SeaBIOS, GRUB, FILO or some other method) that runs a suite of tests and gathers the results. The tool may also be run on vendor BIOS to verify an issue created/fixed by coreboot or SeaBIOS.<br />
<br />
When applying for this task, please state in your proposal what you think the base image/kernel would be used, the method of generating the image, what test you are targeting, and how results are gathered.<br />
<br />
Possibilities for a container for the tool could include:<br />
* Downloading a script that sets up a live image to run various tests (Limits the number of tests)<br />
* Creating a script that builds a new live image for this purpose (More flexibility)<br />
* Customizing a distro or something to do what is needed - see the fwts-live image or BITS as examples. Create a new bootable ISO (Most flexible, and the most work)<br />
<br />
Possibilities for tests:<br />
* Extending FWTS to check for coreboot specific items (ubuntu & FWTS-live specific)<br />
* Parsing output of cbmem timestamps and coreboot boot log <br />
* Rebooting with various kernel parameters to test different items<br />
* Working with the community & coreboot vendors to develop additional tests<br />
<br />
'''Links'''<br />
* https://wiki.ubuntu.com/Kernel/Reference/fwts<br />
* https://wiki.ubuntu.com/FirmwareTestSuite/FirmwareTestSuiteLive<br />
* http://biosbits.org/ <br />
* https://help.ubuntu.com/community/LiveCDCustomization<br />
* https://os-autoinst.github.io/openQA/<br />
* [[Supported Motherboards]]<br />
<br />
'''Skill Level'''<br />
* coreboot and firmware: novice<br />
* Linux scripting and application development: competent<br />
<br />
'''Requirements'''<br />
* A coreboot mainboard <br />
<br />
'''Mentors'''<br />
* [https://www.coreboot.org/User:MartinRoth Martin Roth]<br />
<br/><br/><br />
<br />
== coreboot mainboard test suite reporting ==<br />
<br />
One of the biggest challenges in coreboot is that it supports many systems in the same codebase. As coreboot develop and systems age, the condition of mainboards becomes unknown. Because of this, we have an increasing interest in automated tests on real hardware, with reporting. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. Build something more scalable than the current system of [https://review.coreboot.org/gitweb?p=board-status.git;a=tree git repository] + [[Supported Motherboards]].<br />
<br />
There should be an authenticated reporting endpoint and some web frontend, that can run on a typical linux system (ultimately hosted on coreboot.org). It should be possible to filter for various criteria. Feature extraction from log files would be a good idea, too. It should also be possible to import the existing data set.<br />
Language/framework/library is pretty much your choice, but shouldn't be too exotic unless you can convince us that you intend to maintain it for the long term.<br />
<br />
This project would work closely with the coreboot test suite project and/or the hardware test rig project. A good example of test results gathering and reporting is done by the Phoronix/Openbenchmark. The student should investigate other test and reporting solutions to leverage the best options for coreboot. It is important the the student considers how testing and reporting can be extended as features and tests are added in the future.<br />
<br />
'''Links'''<br />
* http://openbenchmarking.org/<br />
* http://www.flashrom.org/Supported_hardware<br />
* [[Supported Motherboards]]<br />
* [https://review.coreboot.org/gitweb?p=board-status.git;a=tree Board status git repo]<br />
<br />
'''Skill Level'''<br />
* coreboot and firmware: novice<br />
* web development: competent<br />
* machine learning: certainly helps building a good project<br />
<br />
'''Requirements'''<br />
* web development environment<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
== coreboot on the open source Berkeley RISC V processor ==<br />
<br />
As RISCV continues to evolve, so must coreboot. There are three major tasks here:<br />
* revive the 32-bit port, which got kind of overwritten in 2015 by the 64-bit port<br />
* bring the 64-bit port inline with the silicon lowrisc.org is shipping. <br />
* work on the 128-bit port for QEMU<br />
<br />
'''Links'''<br />
* http://http://riscv.org/<br />
<br />
'''Skill Level'''<br />
* coreboot and firmware: competent<br />
* linux: competent<br />
<br />
'''Requirements'''<br />
* Need a system on which to build and run the RISCV toolchain, coreboot, and run simulators.<br />
<br />
'''Mentors'''<br />
<br/>Ron Minnich<br/><br />
<br />
<br />
== Infrastructure for automatic code checking ==<br />
<br />
coreboot has a build bot that builds various configurations of coreboot on every gerrit commit. We would like to extend the current build infrastructure 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 />
* Implement automatic building on various OS types - FreeBSD, NetBSD, OSX, and Windows all seem to be used.<br />
<br />
<br />
'''Links'''<br />
* LLVM tools: [http://clang.llvm.org/StaticAnalysis.html Clang static analyser], [http://llvm.org/ProjectsWithLLVM/#Calysto SSA assertion checker], http://klee.llvm.org/, http://oclint.org/<br />
* Lint tools: [http://lclint.cs.virginia.edu/ Splint]<br />
* Semantic Tester: https://code.google.com/p/c-semantics/<br />
* [http://frama-c.com/ Frama-C]<br />
<br />
'''Skill Level'''<br />
* coreboot and firmware: novice<br />
* compiler build and makefile knowledge: competent<br />
* Jenkins and test automation: novice<br />
<br />
'''Requirements'''<br />
* coreboot build environment <br />
<br />
<br />
'''Mentors'''<br />
* [https://www.coreboot.org/User:MartinRoth Martin Roth]<br />
<br/><br/><br />
<br />
<br />
== Implement advanced coreboot features on existing mainboards ==<br />
<br />
A lot of cool new coreboot features are only available on a small subset of the supported mainboards. Those features include:<br />
* global variables in romstage<br />
* relocatable ramstage<br />
* cbmem console<br />
* timestamps/performance data<br />
<br />
This project would identify how to bring those features forward to more boards and complete porting of said mainboards.<br />
<br />
'''Skill Level'''<br />
* coreboot and firmware: competent<br />
<br />
'''Requirements'''<br />
* coreboot mainboard(s)<br />
<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
== coreboot ACPI 4.0 and S3 power management ==<br />
<br />
coreboot has support for ACPI tables and S3 support for some platforms, but the implementations are mainboard specific and mostly based on ACPI 2.0. Create a generic solution for ACPI 4.0 table generation and S3 support across all mainboards. <br />
<br />
'''Skill Level'''<br />
* coreboot and firmware: competent to expert<br />
* ACPI and power management: novice to competent<br />
<br />
'''Requirements'''<br />
* coreboot mainboard<br />
* flash recovery mechanism <br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
== coreboot panic room ==<br />
<br />
Create a safe boot solution for coreboot to easily and cheaply recover the system. <br />
<br />
The basic idea is that the system flash image always contains executable for SerialICE. Instead of loading a coreboot romstage, firmware can boot to SerialICE based on some GPIO state, a keypress sequence or a logged failure on earlier boots. It is possible to integrate this into the coreboot build tree as a bootblock option, in the same spot as the fallback/normal switch and the simple loader.<br />
<br />
Having this capability opens up new possibilities:<br />
<br />
During the lifetime of a mainboard, new requirements for ACPI hacks and CPU microcodes introduce the need to update boot firmware at customer site. The firmware shall have recovery path against any failures during the firmware update process. The most straight-forward solution is to do intelligent allocation of files in the CBFS such that files critical to the recovery are located on write-protected pages. The recovery path shall require only an USB mass-storage with compatible filesystem (ext2, fat32).<br />
<br />
The ability to dual-boot reduces the amount of tools required to reverse-engineer proprietary BIOS on ports for new mainboards. It is increasingly common that the flash chips are a) not socketed or b) physically hard to access (laptops). Even if chipset support existed already for a board, there are a lot of configuration registers for PCI-e links and GPIO signals that are difficult to get right by code disassembly only. With panic room implementation there would be no need to use external programmers or flashchip hot-swap method to alternate between SerialICE (for proprietary BIOS) and coreboot romstage boots.<br />
<br />
SerialICE requires minimal hardware resources and does not require installed RAM or display hardware. It could be used as the first power-on environment after mainboard PCB verification and assembly to verify integrated components enumerate correctly. At the end of this first power-on, actual board firmware can be programmed without the need for external programmers and SOIC-8 clips, as the SPI controller embedded in the chipset can be used instead. As setting up EHCI debug port console is fairly simple across different chipsets, it can be used to print detailed diagnostics instead of POST codes on LPC bus.<br />
<br />
<br />
GSoC 2011 project [http://blogs.coreboot.org/blog/2011/05/09/gsoc-project-coreboot-panic-room-diagnostics-also-remote-flashing/] was able to:<br />
* Link flashrom with libpayload and flash from USB drive in a pre-OS environment.<br />
* Optimise flashrom memory usage to flash in pre-ram/cache-as-ram environment.<br />
* Build SerialICE boot ROM inside the coreboot tree and share some of the PnP/SuperIO source code.<br />
* Demonstrate booting alternative payload on keypress.<br />
<br />
<br />
There are remaining open tasks to:<br />
* Bring the GSoC 2011 patches up-to-date with current flashrom and libpayload trees.<br />
* Create generic solution to jump to recovery mode using input from GPIOs and/or use of power-button override.<br />
* Use SMBus/SMLink to send POST failure codes over ethernet using integrated network controllers.<br />
* After panic(), dump RAM contents before they are overwritten.<br />
<br />
'''Skill Level'''<br />
* coreboot: competent to expert<br />
<br />
'''Requirements'''<br />
* coreboot mainboard<br />
* flash recovery mechanism<br />
<br />
<br />
'''Mentors'''<br />
<br/><br/><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 />
We had some data structure work being done in coreboot v3 (based on DTS device tree source), but the approach back then didn't have the desired results. Still, if you want to tackle this task you can get some valuable information in past coreboot v3 discussions about what's feasible and what's infeasible.<br />
<br />
'''Links'''<br />
* Check out the various devicetree.cb files in the src/ directory of the coreboot repository.<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
== Infrastructure for accessing block devices ==<br />
<br />
Create a simple interface to access block devices, such as NAND, SD cards, MMC, etc. This is needed on some lower-end ARM SoCs in order to load successive coreboot stages.<br />
<br />
'''Example:''' On Allwinner A10 SoCs, the hardware bootloader will load up to a 24KiB bootblock. That's barely sufficient to initialize DRAM and load the next stage from MMC, and is nowhere near enough to run all stages of coreboot. Coreboot will need to know how to read MMC.<br />
<br />
'''Links'''<br />
* [[User_talk:MrNuke/Block_Device_API | Initial proposal]]<br />
* [[Board:cubietech/cubieboard | Cubieboard page]]<br />
<br />
'''Skill Level'''<br />
* coreboot and ARM firmware: competent<br />
<br />
'''Requirements'''<br />
* An ARM board with low-end SoC (for example, Cubieboard, with Allwinner A10)<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
<br />
== Native graphics init ==<br />
<br />
Implement native initialization of the graphics hardware (probably AMD or Intel) so no Video BIOS is needed.<br />
<br />
<br />
<br />
A test and performance possibility, like a payload testing the correct initialization, needs to be added too.<br />
<br />
This could be done in combination with making a board port.<br />
<br />
'''Links'''<br />
* [http://www.coreboot.org/pipermail/coreboot/2013-March/075512.html Small discussion about initialization of AMD graphics hardware]<br />
<br />
'''Skill Level'''<br />
* coreboot: competent<br />
* Linux graphics stack: competent<br />
<br />
'''Requirements'''<br />
* coreboot mainboard<br />
* flash recovery mechanism<br />
<br />
'''Mentors'''<br />
* Ron Minnich, unless someone better comes along<br />
<br/><br/><br />
<br />
== End user flash tool ==<br />
<br />
A tool that takes a coreboot image without payload, and payload binaries (so the user can select which payload to use), combines them according to user wishes. <br />
It copies other required components (EC/ME firmware, VGABIOS) from the running system (ie. dump flash, extract data) and compares their hash against a white list (so we can vouch for their compatibility), then writes the result to flash, unlocking flash if necessary.<br />
<br />
Ideally it's a portable graphical tool (assuming that flashrom is available for the target OS). It could use libflashrom, the bios_extract tools, and cbfstool in the background and provide the glue to make things work.<br />
<br />
Additional info about the purpose of this tool:<br />
The challenge is to give users a simple way to create a '''working''' coreboot image with all the necessary components, including the components we can't provide as coreboot.org downloads for technical or legal reasons. This tool is intended as one-stop shop (one-click tool by default) to create working images without the user having to worry about which options are correct for his/her system. If any options are not applicable for a given system or if those options might result in a system not booting as expected, they should not be shown at all. It is explicitly not desired to just get a GUI exposing the complexity of the underlying tools (we have that, and it's called the command line).<br />
<br />
Technical challenges for the design and implementation:<br />
To provide a working image for a given board, hardware peculiarities have to be handled automatically as much as possible. The tool has to<br />
* extract/dump some data/contents from the running system while coreboot is not yet installed, zero or more of the following<br />
** EDID data<br />
** PCI configuration (lspci -nn)<br />
** old flash chip contents<br />
** VGA BIOS in its mangled form dumped from memory (C segment)<br />
** VGA BIOS in its original form extracted from the flash chip contents<br />
** onboard network firmware/configuration/MACaddr, possibly extracted from the flash chip contents or other in-system data sources<br />
* possibly download and mangle BIOS update files from a vendor site<br />
** mostly in case the data mentioned above can't be extracted from the running system or in case newer data is available as download from the vendor<br />
* detect the exact variant of the hardware including any special handling needed (e.g. there are dozens of different Thinkpad T60/T60p variants all using the exact same coreboot code, but some need a VGA option ROM and some don't, the TFT panel definitions differ, etc.)<br />
* check whether the extracted data (mostly VGA BIOS etc.) matches the data that's known to work, e.g. by comparing hashes<br />
* check whether the extracted data has correct internal checksums and if not, check whether fixups are needed or wanted for this particular hardware (e.g. some C segment dumps from VGA option ROMs have broken checksums and their checksums should be fixed automatically by the tool, other VGA option ROMs should yield an error instead)<br />
* present the end user only with the choices that make sense for this specific piece of hardware<br />
* warn the user if hardware with this exact hardware has no complete (or none at all) rule set for working images<br />
* provide a way to import or store rules for doing all the stuff above for multiple boards or board variants<br />
<br />
The complexity of that logic is very hard to handle if you're open-coding everything, and it might make sense to either invent a language for the rules and actions mentioned above or use JSON or XML wisely. Please note that the tool itself is not supposed to be written in JSON or XML, but rather a cross-platform capable language, preferably with a graphical (i.e. not text mode) user interface.<br />
<br />
Providing example logic for one supported coreboot mainboard (not qemu!) based on wiki contents (e.g. for Thinkpad T60) would be a goal as well.<br />
<br />
'''Skill Level'''<br />
* coreboot: novice<br />
* Systems programming, GUI programming: competent<br />
<br />
'''Requirements'''<br />
* coreboot mainboard<br />
* flash recovery mechanism<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
<br />
== proper configuration support in upstream (devtree -> kconfig -> runtime values) ==<br />
'''Skill Level'''<br />
* coreboot: medium<br />
* C, build system.<br />
<br />
'''Requirements'''<br />
* knowledge of what types of configuration exist in coreboot<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
==<br />
This would involve refactoring the current print system, and allowing sections to enable/disable different levels of output. coreboot currently has a very basic way to do this, turning debug on and off for various sections at build time. Something that is significantly more granular would be nice, and something that could be updated at runtime would be good.<br />
<br />
'''Skill Level'''<br />
* coreboot: novice<br />
* Systems programming<br />
<br />
'''Requirements'''<br />
* none - this can be tested with coreboot booting in QEMU<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
== console via SMBus ==<br />
<br />
Not all boards have an accessible serial port, but all boards with socketed RAM have a somehow accessible SMBus (used for reading the SPD-EEPROMs), which can be used very early in the boot process. As a device to receive the logs for example a beaglebone black or a cheap stm32 board with the i2c-star firmware can be used. The console via SMBus isn't that much slower than a serial console and ways faster than the speakermodem output.<br />
<br />
'''Skill Level'''<br />
* coreboot: medium<br />
* soldering: medium<br />
<br />
'''Requirements'''<br />
* none<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
== ARM64 qemu port ==<br />
<br />
Develop mainboard/chipset support for a ARM64 qemu target. In order to work on ARM64 code one usually needs a ARM64 board. To reduce that barrier, work on a ARM64 qemu port.<br />
<br />
'''Skill Level'''<br />
* coreboot: medium<br />
<br />
'''Requirements'''<br />
* none<br />
<br />
'''Mentors'''<br />
* adurbin<br />
<br/><br/><br />
<br />
== Add U-Boot as a generic coreboot payload ==<br />
<br />
U-Boot already will run as a coreboot payload, but it needs to be modified for each different platform. Some work has already been done to add it to the coreboot build as a payload, but it still doesn't work correctly in a generic fashion. It also won't currently build with the coreboot toolchain.<br />
<br />
This project will require work on both the coreboot and U-Boot projects.<br />
<br />
'''Skill Level'''<br />
* coreboot: novice<br />
* Makefile and toolchain skills: medium<br />
<br />
'''Requirements'''<br />
* none<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
== Provide toolchain binaries ==<br />
<br />
Provides packages/installers of our compiler toolchain for Linux distros, Windows, Mac OS. For Windows, this should also include the environment (shell, make, ...).<br />
<br />
'''Skill Level'''<br />
* coreboot: novice<br />
<br />
'''Requirements'''<br />
* knowledge of package/installer tooling on their target OS<br />
<br />
'''Mentors'''<br />
<br/>pgeorgi<br/><br />
<br />
= flashrom Projects =<br />
<br />
Flashrom is a project that is closely associated with coreboot and we work together where possible. They maintain a list of project ideas on their own website:<br />
<br />
[http://www.flashrom.org/GSoC flashrom project ideas]<br />
<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
= SerialICE Projects =<br />
<br />
SerialICE is a project that started out as tool for coreboot development. They maintain a list of project ideas on their own website:<br />
<br />
<br />
* [http://serialice.com/GSoC SerialICE project ideas]<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
= ROM-O-Matic =<br />
<br />
The ROM-O-Matic is envisioned to be a build server that would be usable by the general public to build ROMS for their mainboards without the need to set up coreboot build system themselves. The coreboot project does not distribute ROM files, requiring users to build their own ROMs.<br />
<br />
== Creation of the server ==<br />
It could be developed in a series of steps:<br />
# Build a very limited number of Mainboards, only from known good versions contained in the board-status repository. These would be boards that are blob-free or have all necessary blobs contained in the 3rd-party/blobs repo.<br />
#* Either the toolchain required for the mainboard would be re-built for each build, or a cached toolchain could be used.<br />
#* The build can be verified to match the MD5 sum of the original build.<br />
#* User gets binaries along with source tree to satisfy licenses.<br />
# Extend the board list to boards that needed external blobs which can be found freely available on the internet. This would be cases where the OEM BIOS can be downloaded, and the pieces can be extracted. Still only versions that are listed in board-status would be available for building.<br />
#* Tools to automate the download and extraction of these blobs would need to be created.<br />
# Allow building from any valid git commit<br />
# Allow building any valid board.<br />
# Allow including patches into the build for customization of the build.<br />
#* At this point, security becomes an issue, and the build would need to be locked down, similar to the current jenkins setup, which builds in a chroot with network disabled.<br />
# Allow additional binaries to be uploaded to be included into the build.<br />
<br />
'''Mentors'''<br />
* [https://www.coreboot.org/User:MartinRoth Martin Roth]<br />
<br/><br/></div>Rminnichhttps://www.coreboot.org/index.php?title=Project_Ideas&diff=23690Project Ideas2017-01-30T15:02:22Z<p>Rminnich: </p>
<hr />
<div>The following are ideas that have been proposed in the community. 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. But of course these are not the only things that could be done. Maybe you have a great idea that we just didn't think of yet. Please let us know! <br />
<br />
<br />
Prospective [[GSoC]] students' application should expand on the ideas and provide specific information in the application. If you have questions or comments, please please contact the coreboot [[Mailinglist|mailing list]] or visit our [[IRC]] channel <code>#coreboot</code> on [https://webchat.freenode.net irc.freenode.net]. Our [[GSoC#Mentors]] are here to help.<br />
<br />
<br />
= coreboot Projects =<br />
<br />
== coreboot mainboard test suite ==<br />
<br />
Create a tool (possibly a bootable CD/USB drive image) to be run on a platform booted with coreboot (using SeaBIOS, GRUB, FILO or some other method) that runs a suite of tests and gathers the results. The tool may also be run on vendor BIOS to verify an issue created/fixed by coreboot or SeaBIOS.<br />
<br />
When applying for this task, please state in your proposal what you think the base image/kernel would be used, the method of generating the image, what test you are targeting, and how results are gathered.<br />
<br />
Possibilities for a container for the tool could include:<br />
* Downloading a script that sets up a live image to run various tests (Limits the number of tests)<br />
* Creating a script that builds a new live image for this purpose (More flexibility)<br />
* Customizing a distro or something to do what is needed - see the fwts-live image or BITS as examples. Create a new bootable ISO (Most flexible, and the most work)<br />
<br />
Possibilities for tests:<br />
* Extending FWTS to check for coreboot specific items (ubuntu & FWTS-live specific)<br />
* Parsing output of cbmem timestamps and coreboot boot log <br />
* Rebooting with various kernel parameters to test different items<br />
* Working with the community & coreboot vendors to develop additional tests<br />
<br />
'''Links'''<br />
* https://wiki.ubuntu.com/Kernel/Reference/fwts<br />
* https://wiki.ubuntu.com/FirmwareTestSuite/FirmwareTestSuiteLive<br />
* http://biosbits.org/ <br />
* https://help.ubuntu.com/community/LiveCDCustomization<br />
* https://os-autoinst.github.io/openQA/<br />
* [[Supported Motherboards]]<br />
<br />
'''Skill Level'''<br />
* coreboot and firmware: novice<br />
* Linux scripting and application development: competent<br />
<br />
'''Requirements'''<br />
* A coreboot mainboard <br />
<br />
'''Mentors'''<br />
* [https://www.coreboot.org/User:MartinRoth Martin Roth]<br />
<br/><br/><br />
<br />
== coreboot mainboard test suite reporting ==<br />
<br />
One of the biggest challenges in coreboot is that it supports many systems in the same codebase. As coreboot develop and systems age, the condition of mainboards becomes unknown. Because of this, we have an increasing interest in automated tests on real hardware, with reporting. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. Build something more scalable than the current system of [https://review.coreboot.org/gitweb?p=board-status.git;a=tree git repository] + [[Supported Motherboards]].<br />
<br />
There should be an authenticated reporting endpoint and some web frontend, that can run on a typical linux system (ultimately hosted on coreboot.org). It should be possible to filter for various criteria. Feature extraction from log files would be a good idea, too. It should also be possible to import the existing data set.<br />
Language/framework/library is pretty much your choice, but shouldn't be too exotic unless you can convince us that you intend to maintain it for the long term.<br />
<br />
This project would work closely with the coreboot test suite project and/or the hardware test rig project. A good example of test results gathering and reporting is done by the Phoronix/Openbenchmark. The student should investigate other test and reporting solutions to leverage the best options for coreboot. It is important the the student considers how testing and reporting can be extended as features and tests are added in the future.<br />
<br />
'''Links'''<br />
* http://openbenchmarking.org/<br />
* http://www.flashrom.org/Supported_hardware<br />
* [[Supported Motherboards]]<br />
* [https://review.coreboot.org/gitweb?p=board-status.git;a=tree Board status git repo]<br />
<br />
'''Skill Level'''<br />
* coreboot and firmware: novice<br />
* web development: competent<br />
* machine learning: certainly helps building a good project<br />
<br />
'''Requirements'''<br />
* web development environment<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
== coreboot on the open source Berkeley RISC V processor ==<br />
<br />
As RISCV continues to evolve, so must coreboot. There are three major tasks here:<br />
* revive the 32-bit port, which got kind of overwritten in 2015 by the 64-bit port<br />
* bring the 64-bit port inline with the silicon lowrisc.org is shipping. <br />
* work on the 128-bit port for QEMU<br />
<br />
'''Links'''<br />
* http://http://riscv.org/<br />
<br />
'''Skill Level'''<br />
* coreboot and firmware: competent<br />
* linux: competent<br />
<br />
'''Requirements'''<br />
* Need a system on which to build and run the RISCV toolchain, coreboot, and run simulators.<br />
<br />
'''Mentors'''<br />
<br/>Ron Minnich<br/><br />
<br />
<br />
== Infrastructure for automatic code checking ==<br />
<br />
coreboot has a build bot that builds various configurations of coreboot on every gerrit commit. We would like to extend the current build infrastructure 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 />
* Implement automatic building on various OS types - FreeBSD, NetBSD, OSX, and Windows all seem to be used.<br />
<br />
<br />
'''Links'''<br />
* LLVM tools: [http://clang.llvm.org/StaticAnalysis.html Clang static analyser], [http://llvm.org/ProjectsWithLLVM/#Calysto SSA assertion checker], http://klee.llvm.org/, http://oclint.org/<br />
* Lint tools: [http://lclint.cs.virginia.edu/ Splint]<br />
* Semantic Tester: https://code.google.com/p/c-semantics/<br />
* [http://frama-c.com/ Frama-C]<br />
<br />
'''Skill Level'''<br />
* coreboot and firmware: novice<br />
* compiler build and makefile knowledge: competent<br />
* Jenkins and test automation: novice<br />
<br />
'''Requirements'''<br />
* coreboot build environment <br />
<br />
<br />
'''Mentors'''<br />
* [https://www.coreboot.org/User:MartinRoth Martin Roth]<br />
<br/><br/><br />
<br />
<br />
== Implement advanced coreboot features on existing mainboards ==<br />
<br />
A lot of cool new coreboot features are only available on a small subset of the supported mainboards. Those features include:<br />
* global variables in romstage<br />
* relocatable ramstage<br />
* cbmem console<br />
* timestamps/performance data<br />
<br />
This project would identify how to bring those features forward to more boards and complete porting of said mainboards.<br />
<br />
'''Skill Level'''<br />
* coreboot and firmware: competent<br />
<br />
'''Requirements'''<br />
* coreboot mainboard(s)<br />
<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
== coreboot ACPI 4.0 and S3 power management ==<br />
<br />
coreboot has support for ACPI tables and S3 support for some platforms, but the implementations are mainboard specific and mostly based on ACPI 2.0. Create a generic solution for ACPI 4.0 table generation and S3 support across all mainboards. <br />
<br />
'''Skill Level'''<br />
* coreboot and firmware: competent to expert<br />
* ACPI and power management: novice to competent<br />
<br />
'''Requirements'''<br />
* coreboot mainboard<br />
* flash recovery mechanism <br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
== coreboot panic room ==<br />
<br />
Create a safe boot solution for coreboot to easily and cheaply recover the system. <br />
<br />
The basic idea is that the system flash image always contains executable for SerialICE. Instead of loading a coreboot romstage, firmware can boot to SerialICE based on some GPIO state, a keypress sequence or a logged failure on earlier boots. It is possible to integrate this into the coreboot build tree as a bootblock option, in the same spot as the fallback/normal switch and the simple loader.<br />
<br />
Having this capability opens up new possibilities:<br />
<br />
During the lifetime of a mainboard, new requirements for ACPI hacks and CPU microcodes introduce the need to update boot firmware at customer site. The firmware shall have recovery path against any failures during the firmware update process. The most straight-forward solution is to do intelligent allocation of files in the CBFS such that files critical to the recovery are located on write-protected pages. The recovery path shall require only an USB mass-storage with compatible filesystem (ext2, fat32).<br />
<br />
The ability to dual-boot reduces the amount of tools required to reverse-engineer proprietary BIOS on ports for new mainboards. It is increasingly common that the flash chips are a) not socketed or b) physically hard to access (laptops). Even if chipset support existed already for a board, there are a lot of configuration registers for PCI-e links and GPIO signals that are difficult to get right by code disassembly only. With panic room implementation there would be no need to use external programmers or flashchip hot-swap method to alternate between SerialICE (for proprietary BIOS) and coreboot romstage boots.<br />
<br />
SerialICE requires minimal hardware resources and does not require installed RAM or display hardware. It could be used as the first power-on environment after mainboard PCB verification and assembly to verify integrated components enumerate correctly. At the end of this first power-on, actual board firmware can be programmed without the need for external programmers and SOIC-8 clips, as the SPI controller embedded in the chipset can be used instead. As setting up EHCI debug port console is fairly simple across different chipsets, it can be used to print detailed diagnostics instead of POST codes on LPC bus.<br />
<br />
<br />
GSoC 2011 project [http://blogs.coreboot.org/blog/2011/05/09/gsoc-project-coreboot-panic-room-diagnostics-also-remote-flashing/] was able to:<br />
* Link flashrom with libpayload and flash from USB drive in a pre-OS environment.<br />
* Optimise flashrom memory usage to flash in pre-ram/cache-as-ram environment.<br />
* Build SerialICE boot ROM inside the coreboot tree and share some of the PnP/SuperIO source code.<br />
* Demonstrate booting alternative payload on keypress.<br />
<br />
<br />
There are remaining open tasks to:<br />
* Bring the GSoC 2011 patches up-to-date with current flashrom and libpayload trees.<br />
* Create generic solution to jump to recovery mode using input from GPIOs and/or use of power-button override.<br />
* Use SMBus/SMLink to send POST failure codes over ethernet using integrated network controllers.<br />
* After panic(), dump RAM contents before they are overwritten.<br />
<br />
'''Skill Level'''<br />
* coreboot: competent to expert<br />
<br />
'''Requirements'''<br />
* coreboot mainboard<br />
* flash recovery mechanism<br />
<br />
<br />
'''Mentors'''<br />
<br/><br/><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 />
We had some data structure work being done in coreboot v3 (based on DTS device tree source), but the approach back then didn't have the desired results. Still, if you want to tackle this task you can get some valuable information in past coreboot v3 discussions about what's feasible and what's infeasible.<br />
<br />
'''Links'''<br />
* Check out the various devicetree.cb files in the src/ directory of the coreboot repository.<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
== Infrastructure for accessing block devices ==<br />
<br />
Create a simple interface to access block devices, such as NAND, SD cards, MMC, etc. This is needed on some lower-end ARM SoCs in order to load successive coreboot stages.<br />
<br />
'''Example:''' On Allwinner A10 SoCs, the hardware bootloader will load up to a 24KiB bootblock. That's barely sufficient to initialize DRAM and load the next stage from MMC, and is nowhere near enough to run all stages of coreboot. Coreboot will need to know how to read MMC.<br />
<br />
'''Links'''<br />
* [[User_talk:MrNuke/Block_Device_API | Initial proposal]]<br />
* [[Board:cubietech/cubieboard | Cubieboard page]]<br />
<br />
'''Skill Level'''<br />
* coreboot and ARM firmware: competent<br />
<br />
'''Requirements'''<br />
* An ARM board with low-end SoC (for example, Cubieboard, with Allwinner A10)<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
<br />
== Native graphics init ==<br />
<br />
Implement native initialization of the graphics hardware (probably AMD or Intel) so no Video BIOS is needed.<br />
<br />
<br />
<br />
A test and performance possibility, like a payload testing the correct initialization, needs to be added too.<br />
<br />
This could be done in combination with making a board port.<br />
<br />
'''Links'''<br />
* [http://www.coreboot.org/pipermail/coreboot/2013-March/075512.html Small discussion about initialization of AMD graphics hardware]<br />
<br />
'''Skill Level'''<br />
* coreboot: competent<br />
* Linux graphics stack: competent<br />
<br />
'''Requirements'''<br />
* coreboot mainboard<br />
* flash recovery mechanism<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
== End user flash tool ==<br />
<br />
A tool that takes a coreboot image without payload, and payload binaries (so the user can select which payload to use), combines them according to user wishes. <br />
It copies other required components (EC/ME firmware, VGABIOS) from the running system (ie. dump flash, extract data) and compares their hash against a white list (so we can vouch for their compatibility), then writes the result to flash, unlocking flash if necessary.<br />
<br />
Ideally it's a portable graphical tool (assuming that flashrom is available for the target OS). It could use libflashrom, the bios_extract tools, and cbfstool in the background and provide the glue to make things work.<br />
<br />
Additional info about the purpose of this tool:<br />
The challenge is to give users a simple way to create a '''working''' coreboot image with all the necessary components, including the components we can't provide as coreboot.org downloads for technical or legal reasons. This tool is intended as one-stop shop (one-click tool by default) to create working images without the user having to worry about which options are correct for his/her system. If any options are not applicable for a given system or if those options might result in a system not booting as expected, they should not be shown at all. It is explicitly not desired to just get a GUI exposing the complexity of the underlying tools (we have that, and it's called the command line).<br />
<br />
Technical challenges for the design and implementation:<br />
To provide a working image for a given board, hardware peculiarities have to be handled automatically as much as possible. The tool has to<br />
* extract/dump some data/contents from the running system while coreboot is not yet installed, zero or more of the following<br />
** EDID data<br />
** PCI configuration (lspci -nn)<br />
** old flash chip contents<br />
** VGA BIOS in its mangled form dumped from memory (C segment)<br />
** VGA BIOS in its original form extracted from the flash chip contents<br />
** onboard network firmware/configuration/MACaddr, possibly extracted from the flash chip contents or other in-system data sources<br />
* possibly download and mangle BIOS update files from a vendor site<br />
** mostly in case the data mentioned above can't be extracted from the running system or in case newer data is available as download from the vendor<br />
* detect the exact variant of the hardware including any special handling needed (e.g. there are dozens of different Thinkpad T60/T60p variants all using the exact same coreboot code, but some need a VGA option ROM and some don't, the TFT panel definitions differ, etc.)<br />
* check whether the extracted data (mostly VGA BIOS etc.) matches the data that's known to work, e.g. by comparing hashes<br />
* check whether the extracted data has correct internal checksums and if not, check whether fixups are needed or wanted for this particular hardware (e.g. some C segment dumps from VGA option ROMs have broken checksums and their checksums should be fixed automatically by the tool, other VGA option ROMs should yield an error instead)<br />
* present the end user only with the choices that make sense for this specific piece of hardware<br />
* warn the user if hardware with this exact hardware has no complete (or none at all) rule set for working images<br />
* provide a way to import or store rules for doing all the stuff above for multiple boards or board variants<br />
<br />
The complexity of that logic is very hard to handle if you're open-coding everything, and it might make sense to either invent a language for the rules and actions mentioned above or use JSON or XML wisely. Please note that the tool itself is not supposed to be written in JSON or XML, but rather a cross-platform capable language, preferably with a graphical (i.e. not text mode) user interface.<br />
<br />
Providing example logic for one supported coreboot mainboard (not qemu!) based on wiki contents (e.g. for Thinkpad T60) would be a goal as well.<br />
<br />
'''Skill Level'''<br />
* coreboot: novice<br />
* Systems programming, GUI programming: competent<br />
<br />
'''Requirements'''<br />
* coreboot mainboard<br />
* flash recovery mechanism<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
<br />
== proper configuration support in upstream (devtree -> kconfig -> runtime values) ==<br />
'''Skill Level'''<br />
* coreboot: medium<br />
* C, build system.<br />
<br />
'''Requirements'''<br />
* knowledge of what types of configuration exist in coreboot<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
==<br />
This would involve refactoring the current print system, and allowing sections to enable/disable different levels of output. coreboot currently has a very basic way to do this, turning debug on and off for various sections at build time. Something that is significantly more granular would be nice, and something that could be updated at runtime would be good.<br />
<br />
'''Skill Level'''<br />
* coreboot: novice<br />
* Systems programming<br />
<br />
'''Requirements'''<br />
* none - this can be tested with coreboot booting in QEMU<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
== console via SMBus ==<br />
<br />
Not all boards have an accessible serial port, but all boards with socketed RAM have a somehow accessible SMBus (used for reading the SPD-EEPROMs), which can be used very early in the boot process. As a device to receive the logs for example a beaglebone black or a cheap stm32 board with the i2c-star firmware can be used. The console via SMBus isn't that much slower than a serial console and ways faster than the speakermodem output.<br />
<br />
'''Skill Level'''<br />
* coreboot: medium<br />
* soldering: medium<br />
<br />
'''Requirements'''<br />
* none<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
== ARM64 qemu port ==<br />
<br />
Develop mainboard/chipset support for a ARM64 qemu target. In order to work on ARM64 code one usually needs a ARM64 board. To reduce that barrier, work on a ARM64 qemu port.<br />
<br />
'''Skill Level'''<br />
* coreboot: medium<br />
<br />
'''Requirements'''<br />
* none<br />
<br />
'''Mentors'''<br />
* adurbin<br />
<br/><br/><br />
<br />
== Add U-Boot as a generic coreboot payload ==<br />
<br />
U-Boot already will run as a coreboot payload, but it needs to be modified for each different platform. Some work has already been done to add it to the coreboot build as a payload, but it still doesn't work correctly in a generic fashion. It also won't currently build with the coreboot toolchain.<br />
<br />
This project will require work on both the coreboot and U-Boot projects.<br />
<br />
'''Skill Level'''<br />
* coreboot: novice<br />
* Makefile and toolchain skills: medium<br />
<br />
'''Requirements'''<br />
* none<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
== Provide toolchain binaries ==<br />
<br />
Provides packages/installers of our compiler toolchain for Linux distros, Windows, Mac OS. For Windows, this should also include the environment (shell, make, ...).<br />
<br />
'''Skill Level'''<br />
* coreboot: novice<br />
<br />
'''Requirements'''<br />
* knowledge of package/installer tooling on their target OS<br />
<br />
'''Mentors'''<br />
<br/>pgeorgi<br/><br />
<br />
= flashrom Projects =<br />
<br />
Flashrom is a project that is closely associated with coreboot and we work together where possible. They maintain a list of project ideas on their own website:<br />
<br />
[http://www.flashrom.org/GSoC flashrom project ideas]<br />
<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
= SerialICE Projects =<br />
<br />
SerialICE is a project that started out as tool for coreboot development. They maintain a list of project ideas on their own website:<br />
<br />
<br />
* [http://serialice.com/GSoC SerialICE project ideas]<br />
<br />
'''Mentors'''<br />
<br/><br/><br />
<br />
= ROM-O-Matic =<br />
<br />
The ROM-O-Matic is envisioned to be a build server that would be usable by the general public to build ROMS for their mainboards without the need to set up coreboot build system themselves. The coreboot project does not distribute ROM files, requiring users to build their own ROMs.<br />
<br />
== Creation of the server ==<br />
It could be developed in a series of steps:<br />
# Build a very limited number of Mainboards, only from known good versions contained in the board-status repository. These would be boards that are blob-free or have all necessary blobs contained in the 3rd-party/blobs repo.<br />
#* Either the toolchain required for the mainboard would be re-built for each build, or a cached toolchain could be used.<br />
#* The build can be verified to match the MD5 sum of the original build.<br />
#* User gets binaries along with source tree to satisfy licenses.<br />
# Extend the board list to boards that needed external blobs which can be found freely available on the internet. This would be cases where the OEM BIOS can be downloaded, and the pieces can be extracted. Still only versions that are listed in board-status would be available for building.<br />
#* Tools to automate the download and extraction of these blobs would need to be created.<br />
# Allow building from any valid git commit<br />
# Allow building any valid board.<br />
# Allow including patches into the build for customization of the build.<br />
#* At this point, security becomes an issue, and the build would need to be locked down, similar to the current jenkins setup, which builds in a chroot with network disabled.<br />
# Allow additional binaries to be uploaded to be included into the build.<br />
<br />
'''Mentors'''<br />
* [https://www.coreboot.org/User:MartinRoth Martin Roth]<br />
<br/><br/></div>Rminnichhttps://www.coreboot.org/index.php?title=Project_Ideas&diff=15704Project Ideas2015-03-07T04:25:30Z<p>Rminnich: </p>
<hr />
<div></div>Rminnichhttps://www.coreboot.org/index.php?title=Project_Ideas&diff=15703Project Ideas2015-03-07T04:23:32Z<p>Rminnich: </p>
<hr />
<div></div>Rminnichhttps://www.coreboot.org/index.php?title=Blob_Matrix&diff=13340Blob Matrix2014-02-17T16:36:31Z<p>Rminnich: </p>
<hr />
<div>This the the Blob Matrix. What is the Blob Matrix? It is a table in which we define, for different systems, what blobs there are. The goal is to have a common reference of types of blobs. Until we're sure we have the right list we don't need the matrix yet.<br />
<br />
Consider, for example, the Google Pixel laptop. We can identify the following CPUs that affect coreboot or that it uses:<br />
EC, <br />
ME, <br />
main CPU.<br />
<br />
For this example, we have the following blobs:<br />
ME, blob from Intel (replaceable, signed);<br />
main CPU: microcode (not practically replaceable), MRC (not practically replaceable), VGA BIOS (replaceable, proof of concept in repo).<br />
<br />
Here is another system, the Snow Chromebook. It has an EC and a main CPU. The blobs are<br />
main CPU: BL0 (not replaceable), and BL1 (replaceable, signed). <br />
<br />
My old x60, with coreboot on it:<br />
EC: EC OS (not replaceable);<br />
ME, blob from Intel (replaceable, signed); <br />
main CPU: microcode, BIOS, VGA BIOS<br />
<br />
Let's consider the first coreboot systems, the l440gx, PowerPC, and Alpha<br />
<br />
The l440GX had no CPUs save the main CPU, and all of linuxbios was open. There was no ACPI or SMM. <br />
<br />
The PowerPC was, similarly, blob free.<br />
<br />
We think the Alpha had an EC, which was closed and had a blob; it was otherwise blob free.<br />
<br />
So: <br />
<br />
<br />
{| border="0" style="font-size: smaller"<br />
|- bgcolor="#6699ff"<br />
! align="left" | Mainboard<br />
! align="left" | Chipset<br />
! align="left" | EC Blob<br />
! align="left" | ME Blob / Signed & Type<br />
! align="left" | Mask ROM blob<br />
! align="left" | Reset vector blob / Signed?<br />
! align="left" | Microcode Blob<br />
! align="left" | VGA blob<br />
! align="left" | SMM Blob<br />
! align="left" | ACPI Blob<br />
! align="left" | Runtime Blob <br />
! align="left" | Notes<br />
<br />
|- bgcolor="#dddddd"<br />
| Google Pixel<br />
| Sandybridge<br />
| No<br />
| Yes / Yes; Unknown<br />
| No<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
|<br />
<br />
|- bgcolor="#dddddd"<br />
| Intel Galileo<br />
| Quark<br />
| No EC<br />
| No ME<br />
| Yes<br />
| Yes; see notes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes EFI<br />
| We make a key, Intel signs the key, we use the signing tool to sign our binary.<br />
The signing utility is part of the BSP on communities.intel.com.<br />
( https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23197)<br />
The Customer is required to provide a public RSA key that is derived from a Private key that conforms to the following:<br />
* Each RSA keypair shall be 2048 bits in length.<br />
* Each RSA keypair shall be formatted as an ASN1 RSAPrivateKey DER certificate as defined in the RSA PKCS#1 document.<br />
<br />
We expect to receive a .pem file that contains only the public components of the Customer RSA 2048 key.</div>Rminnichhttps://www.coreboot.org/index.php?title=Blob_Matrix&diff=13339Blob Matrix2014-02-17T16:12:40Z<p>Rminnich: </p>
<hr />
<div>This the the Blob Matrix. What is the Blob Matrix? It is a table in which we define, for different systems, what blobs there are. The goal is to have a common reference of types of blobs. Until we're sure we have the right list we don't need the matrix yet.<br />
<br />
Consider, for example, the Google Pixel laptop. We can identify the following CPUs that affect coreboot or that it uses:<br />
EC, <br />
ME, <br />
main CPU.<br />
<br />
For this example, we have the following blobs:<br />
ME, blob from Intel (replaceable, signed);<br />
main CPU: microcode (not practically replaceable), MRC (not practically replaceable), VGA BIOS (replaceable, proof of concept in repo).<br />
<br />
Here is another system, the Snow Chromebook. It has an EC and a main CPU. The blobs are<br />
main CPU: BL0 (not replaceable), and BL1 (replaceable, signed). <br />
<br />
My old x60, with coreboot on it:<br />
EC: EC OS (not replaceable);<br />
ME, blob from Intel (replaceable, signed); <br />
main CPU: microcode, BIOS, VGA BIOS<br />
<br />
Let's consider the first coreboot systems, the l440gx, PowerPC, and Alpha<br />
<br />
The l440GX had no CPUs save the main CPU, and all of linuxbios was open. There was no ACPI or SMM. <br />
<br />
The PowerPC was, similarly, blob free.<br />
<br />
We think the Alpha had an EC, which was closed and had a blob; it was otherwise blob free.<br />
<br />
So: <br />
<br />
<br />
{| border="0" style="font-size: smaller"<br />
|- bgcolor="#6699ff"<br />
! align="left" | Mainboard<br />
! align="left" | Chipset<br />
! align="left" | EC Blob<br />
! align="left" | ME Blob / Signed & Type<br />
! align="left" | Mask ROM blob<br />
! align="left" | Reset vector blob / Signed?<br />
! align="left" | Microcode Blob<br />
! align="left" | VGA blob<br />
! align="left" | SMM Blob<br />
! align="left" | ACPI Blob<br />
! align="left" | Runtime Blob <br />
! align="left" | Notes<br />
<br />
|- bgcolor="#dddddd"<br />
| Google Pixel<br />
| Sandybridge<br />
| No<br />
| Yes / Yes; Unknown<br />
| No<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
|<br />
<br />
|- bgcolor="#dddddd"<br />
| Intel Galileo<br />
| Quark<br />
| No EC<br />
| No ME<br />
| Yes<br />
| Yes; see notes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes EFI<br />
| We make a key, Intel signs the key, we use the signing tool to sign our binary.<br />
The signing utility is part of the BSP on communities.intel.com.<br />
The Customer is required to provide a public RSA key that is derived from a Private key that conforms to the following:<br />
* Each RSA keypair shall be 2048 bits in length.<br />
* Each RSA keypair shall be formatted as an ASN1 RSAPrivateKey DER certificate as defined in the RSA PKCS#1 document.<br />
<br />
We expect to receive a .pem file that contains only the public components of the Customer RSA 2048 key.</div>Rminnichhttps://www.coreboot.org/index.php?title=Blob_Matrix&diff=13338Blob Matrix2014-02-16T20:59:34Z<p>Rminnich: </p>
<hr />
<div>This the the Blob Matrix. What is the Blob Matrix? It is a table in which we define, for different systems, what blobs there are. The goal is to have a common reference of types of blobs. Until we're sure we have the right list we don't need the matrix yet.<br />
<br />
Consider, for example, the Google Pixel laptop. We can identify the following CPUs that affect coreboot or that it uses:<br />
EC, <br />
ME, <br />
main CPU.<br />
<br />
For this example, we have the following blobs:<br />
ME, blob from Intel (replaceable, signed);<br />
main CPU: microcode (not practically replaceable), MRC (not practically replaceable), VGA BIOS (replaceable, proof of concept in repo).<br />
<br />
Here is another system, the Snow Chromebook. It has an EC and a main CPU. The blobs are<br />
main CPU: BL0 (not replaceable), and BL1 (replaceable, signed). <br />
<br />
My old x60, with coreboot on it:<br />
EC: EC OS (not replaceable);<br />
ME, blob from Intel (replaceable, signed); <br />
main CPU: microcode, BIOS, VGA BIOS<br />
<br />
Let's consider the first coreboot systems, the l440gx, PowerPC, and Alpha<br />
<br />
The l440GX had no CPUs save the main CPU, and all of linuxbios was open. There was no ACPI or SMM. <br />
<br />
The PowerPC was, similarly, blob free.<br />
<br />
We think the Alpha had an EC, which was closed and had a blob; it was otherwise blob free.<br />
<br />
So: <br />
<br />
<br />
{| border="0" style="font-size: smaller"<br />
|- bgcolor="#6699ff"<br />
! align="left" | Mainboard<br />
! align="left" | EC Blob<br />
! align="left" | ME Blob<br />
! align="left" | Mask blob<br />
! align="left" | VGA blob<br />
! align="left" | Reset vector blob<br />
! align="left" | Microcode Blob<br />
<br />
|- bgcolor="#dddddd"<br />
| pixel<br />
| No<br />
| Yes<br />
| No<br />
| Yes<br />
| No<br />
| Yes</div>Rminnichhttps://www.coreboot.org/index.php?title=User_talk:MrNuke&diff=12668User talk:MrNuke2014-01-09T21:44:14Z<p>Rminnich: </p>
<hr />
<div>== Ideas for generic handling of devices ==<br />
<br />
Chan is an IO channel. <br />
<br />
This struct is used in Inferno and has been for a long time; so it works. <br />
It's also in the opcodes somewhat like what we did for EMMC on ARM.<br />
<br />
<br />
struct Dev<br />
{<br />
char* name;<br />
<br />
void (*reset)(void);<br />
<br />
void (*init)(void);<br />
<br />
void (*shutdown)(void);<br />
<br />
Chan* (*attach)(char*); /* tell the device you want to use it */<br />
<br />
Walkqid* (*walk)(Chan*, Chan*, char**, int); /* walk to a name in the device's managed name space; return a handle */<br />
<br />
int (*stat)(Chan*, uchar*, int); // status info<br />
<br />
Chan* (*open)(Chan*, int); /* get access to a resource in the device name space */<br />
<br />
void (*close)(Chan*); /* tell it you are done with whatever it is. */<br />
<br />
long (*read)(Chan*, void*, long, vlong);<br />
<br />
long (*write)(Chan*, void*, long, vlong);<br />
<br />
void (*power)(int); /* power mgt: power(1) ? on, power (0) ? off */<br />
<br />
};</div>Rminnichhttps://www.coreboot.org/index.php?title=Blob_Matrix&diff=12649Blob Matrix2014-01-08T05:18:25Z<p>Rminnich: </p>
<hr />
<div>This the the Blob Matrix. What is the Blob Matrix? It is a table in which we define, for different systems, what blobs there are. The goal is to have a common reference of types of blobs. Until we're sure we have the right list we don't need the matrix yet.<br />
<br />
Consider, for example, the Google Pixel laptop. We can identify the following CPUs that affect coreboot or that it uses:<br />
EC, <br />
ME, <br />
main CPU.<br />
<br />
For this example, we have the following blobs:<br />
ME, blob from Intel (replaceable, signed);<br />
main CPU: microcode (not practically replaceable), MRC (not practically replaceable), VGA BIOS (replaceable, proof of concept in repo).<br />
<br />
Here is another system, the Snow Chromebook. It has an EC and a main CPU. The blobs are<br />
main CPU: BL0 (not replaceable), and BL1 (replaceable, signed). <br />
<br />
My old x60, with coreboot on it:<br />
EC: EC OS (not replaceable);<br />
ME, blob from Intel (replaceable, signed); <br />
main CPU: microcode, BIOS, VGA BIOS<br />
<br />
Let's consider the first coreboot systems, the l440gx, PowerPC, and Alpha<br />
<br />
The l440GX had no CPUs save the main CPU, and all of linuxbios was open. There was no ACPI or SMM. <br />
<br />
The PowerPC was, similarly, blob free.<br />
<br />
We think the Alpha had an EC, which was closed and had a blob; it was otherwise blob free.</div>Rminnichhttps://www.coreboot.org/index.php?title=Blob_Matrix&diff=12648Blob Matrix2014-01-08T05:14:43Z<p>Rminnich: This page allows us to define what blobs different systems have. It is not intended to be complete.</p>
<hr />
<div>This the the Blob Matrix. What is the Blob Matrix? It is a table in which we define, for different systems, what blobs there are. The goal is to have a common reference of types of blobs. Until we're sure we have the right list we don't need the matrix yet.<br />
<br />
Consider, for example, the Google Pixel laptop. We can identify the following CPUs that affect coreboot or that it uses:<br />
EC, <br />
ME, <br />
main CPU.<br />
<br />
For this example, we have the following blobs:<br />
ME, blob from Intel (replaceable, signed);<br />
main CPU: microcode (not practically replaceable), MRC (not practically replaceable), VGA BIOS (replaceable, proof of concept in repo).<br />
<br />
Here is another system, the Snow Chromebook. It has an EC and a main CPU. The blobs are<br />
main CPU: BL0 (not replaceable), and BL1 (replaceable, signed). <br />
<br />
My old x60, with coreboot on it:<br />
EC: EC OS (not replaceable);<br />
ME, blob from Intel (replaceable, signed); <br />
main CPU: microcode, BIOS, VGA BIOS</div>Rminnichhttps://www.coreboot.org/index.php?title=Welcome_to_coreboot&diff=12647Welcome to coreboot2014-01-08T05:06:46Z<p>Rminnich: </p>
<hr />
<div><table width="100%" valign="top"><tr valign="top"><td width="80%"><br />
<br />
<div style="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;"><br />
'''coreboot''' is a Free Software project aimed at replacing the proprietary [http://wikipedia.org/wiki/BIOS BIOS] (firmware) found in most computers. coreboot performs a little bit of hardware initialization and then executes additional boot logic, called a [[Payloads|payload]].<br />
<br />
With the separation of hardware initialization and later boot logic, coreboot can scale from specialized applications that run directly from firmware, run operating systems in flash, load custom bootloaders, or implement firmware standards, like [[SeaBIOS | PC BIOS services]] or [[TianoCore | UEFI]]. This allows for systems to only include the features necessary in the target application, reducing the amount of code and flash space required.<br />
<br />
coreboot currently supports over '''[[Supported Motherboards|230]]''' different mainboards. Check the [[Support]] page to see if your system is supported.<br />
<br />
<small><br />
coreboot was formerly known as [http://www.coreboot.org/pipermail/coreboot/2008-January/029135.html LinuxBIOS]. <br />
</small><br />
</div><br />
<br />
<div style="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;"><br />
coreboot recently switched to [[git]] and [http://review.coreboot.org gerrit] is now used as patch review tool.<br />
</div><br />
<br />
{| cellspacing=0 cellpadding=8 border=0 margin=0 padding=0 align="top" width=100%<br />
|-<br />
|style="vertical-align:top"|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = yellow|<br />
WIDTH = 100%|<br />
ICON = <small>[[Benefits|More...]]</small>|<br />
HEADING = <span style="font-variant:small-caps; font-size:120%">[[Benefits]]</span>|<br />
CONTENT =<br />
<small><br />
* 100% Free Software (GPL), no royalties, no license fees!<br />
* Fast boot times (500 milliseconds to verified Linux kernel)<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|chipsets]], and [[payloads]]<br />
<!-- * Further features: netboot, serial console, remote flashing, ... --><br />
</small><br />
}}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = #d1adf6|<br />
WIDTH = 100%|<br />
ICON = <small>[[Use Cases|More...]]</small>|<br />
HEADING = <span style="font-variant:small-caps; font-size:120%">[[Use Cases]]</span>|<br />
CONTENT =<br />
<small><br />
* Desktop PCs, servers, [[Laptop|laptops]]<br />
* [[Clusters]]<br />
<!-- * Set-Top-Boxes, thin clients --><br />
* Embedded solutions<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 "disk") --><br />
<!-- * Non-standard scenarios (e.g. FPGA in Opteron socket) --><br />
</small><br />
}}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = lime|<br />
WIDTH = 100%|<br />
ICON = <small>[[Payloads|More...]]</small>|<br />
HEADING = <span style="font-variant:small-caps; font-size:120%">[[Payloads]]</span>|<br />
CONTENT =<br />
<small><br />
* [[SeaBIOS]] / [[FILO]] / [[GRUB2]] / [[Payloads|...]] <!-- / [[OpenFirmware]] / [[OpenBIOS]] --><br />
* [[Linux]] / [[Windows]] / [[FreeBSD]] / [[NetBSD]] / [[Payloads|...]] <!-- / [http://openbsd.org/ OpenBSD]--><br />
* [[Etherboot]] / [[GPXE]] / [[iPXE]] / [[Payloads|...]]<br />
<!--* [[Memtest86]]<br />
* [[Bayou]] / [[Coreinfo]] / [[Tint]] / [[Libpayload]]--><br />
</small><br />
}}<br />
<br />
|}<br />
<br />
{| cellspacing=5 cellpadding=15 border=0 valign="top" width=100%<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_cb.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">About</span>'''<br /><small>Find out more about coreboot.</small><small><hr />[[Press]] | [[Logo]] | [[History]] | [[Screenshots|Screenshots/Videos]] | [[Contributors]] | [[Sponsors]] | [[Products]] | [[Vendors]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_devel.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">Developers</span>'''<br /><small>Get involved! Help us make coreboot better.</small><small><hr />[[Development Guidelines]] | [[Developer Manual]] | [http://qa.coreboot.org/docs/doxygen.php Doxygen] | [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree Browse Source] | [[GSoC]] | [[Where to start]] | [[Distributed and Automated Testsystem|Testsystem]]</small><br />
|}<br />
<br />
|-<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_status.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">Status</span>'''<br /><small>Find out whether your hardware is already supported.</small><small><hr />[[Supported Motherboards|Supported Boards]] | [[Supported Chipsets and Devices|Supported Chipsets]] | [[:Category:Tutorials|Board Status Pages]] | [[Blob Matrix|Blob Matrix]] | [http://qa.coreboot.org Build Status]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_tools.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">Related Tools</span>'''<br /><small>Tools and libraries related to coreboot.</small><small><hr />[http://www.flashrom.org flashrom] | [[Superiotool]] | [[Nvramtool]] | [[Buildrom]] | [[Mkelfimage]] | [[Inteltool]] | [[Msrtool]] | [[Ectool]] | [[Developer_Manual/Tools|Hardware tools]] | [[Abuild]] | [http://serialice.com SerialICE]</small><br />
|}<br />
<br />
|-<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_101.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">Getting Started</span>'''<br /><small>Download coreboot and get started.</small><small><hr />[[Build HOWTO]] | [[Download coreboot|Downloads]] | [[Documentation]] | [[QEMU]] | [[AMD SimNow]] | [[Build from Windows]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_support.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">Support</span>'''<br /><small>Learn how to contact us and find help and support.</small><small><hr />[[FAQ]] | [[Mailinglist]] | [[IRC]] | [http://tracker.coreboot.org/trac/coreboot/ Issue Tracker] | [[Glossary]] | [[coreboot Options|coreboot Options]]</small><br />
|}<br />
<br />
|}<br />
</td><td width="20%"><br />
<br />
[[File:Coreboot menuconfig.png|center|thumb|[[Build HOWTO|make menuconfig]] in coreboot]]<br />
<br />
<br clear=all /><br />
<br />
'''<span style="font-variant:small-caps; font-size:120%">[http://blogs.coreboot.org News (blog)]</span>'''<hr /><br />
<small><br />
<rss max=5>http://blogs.coreboot.org/feed/</rss><br />
</small><br />
<br />
<br />
'''<span style="font-variant:small-caps; font-size:120%">[[Current events|Upcoming Events]]</span>'''<hr /><br />
<!-- List of upcoming events (remove events after they have taken place). --><br />
<small><br />
<!-- * '''2011/mon/day:''' coreboot event at [[Link]] in somecity --><br />
</small><br />
<br />
<br />
<br clear=all /><br />
{{#widget:Ohloh Project|id=coreboot|type=partner_badge}}<br />
{{#widget:Ohloh Project|id=coreboot|type=cocomo}}<br />
<br />
<br />
</td></tr></table><br />
<br />
__NOTOC__<br />
__NOEDITSECTION__</div>Rminnichhttps://www.coreboot.org/index.php?title=File:Clipper_caltrain.jpeg&diff=10947File:Clipper caltrain.jpeg2011-12-06T05:39:21Z<p>Rminnich: </p>
<hr />
<div></div>Rminnichhttps://www.coreboot.org/index.php?title=Fun_Stuff&diff=10946Fun Stuff2011-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>Rminnichhttps://www.coreboot.org/index.php?title=Fun_Stuff&diff=10945Fun Stuff2011-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>Rminnichhttps://www.coreboot.org/index.php?title=Fun_Stuff&diff=10941Fun Stuff2011-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>Rminnichhttps://www.coreboot.org/index.php?title=File:Elevator_spain.jpeg&diff=10940File:Elevator spain.jpeg2011-12-04T22:50:33Z<p>Rminnich: An elevator in Spain.</p>
<hr />
<div>An elevator in Spain.</div>Rminnichhttps://www.coreboot.org/index.php?title=Fun_Stuff&diff=10939Fun Stuff2011-12-04T22:47:44Z<p>Rminnich: Created page with " == Failure at scale == A BIOS gets confused in a very visible way: File:Billboard_bios_fail.jpeg Photo courtesy Greg Kurtzer of LBL."</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>Rminnichhttps://www.coreboot.org/index.php?title=File:Billboard_bios_fail.jpeg&diff=10938File:Billboard bios fail.jpeg2011-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>Rminnichhttps://www.coreboot.org/index.php?title=GSoC&diff=9479GSoC2010-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 "right on the iron".<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 "community bonding period" 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 "regular basis" in the last item does _not_ mean "3 days before evaluation deadlines". You should be "around" 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 "verify that everything is brought over", but that's nothing that can be reasonably proven (and it might also be too close to "documentation tasks", 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 "real" 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>Rminnichhttps://www.coreboot.org/index.php?title=GSoC&diff=9478GSoC2010-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 "right on the iron".<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 "community bonding period" 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 "regular basis" in the last item does _not_ mean "3 days before evaluation deadlines". You should be "around" 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 "verify that everything is brought over", but that's nothing that can be reasonably proven (and it might also be too close to "documentation tasks", 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 "real" 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>Rminnichhttps://www.coreboot.org/index.php?title=FAQ&diff=7015FAQ2008-09-04T23:55:16Z<p>Rminnich: Update the location of the compiler.</p>
<hr />
<div></div>Rminnichhttps://www.coreboot.org/index.php?title=Welcome_to_coreboot&diff=6769Welcome to coreboot2008-08-19T15:48:20Z<p>Rminnich: </p>
<hr />
<div><table width="100%" valign="top"><tr valign="top"><td width="80%"><br />
<br />
<div style="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;"><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 />
</div><br />
<br />
{| cellspacing=0 cellpadding=3 border=0 margin=0 padding=0 align="top" width=100%<br />
|-<br />
|style="vertical-align:top"|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = yellow|<br />
WIDTH = 100%|<br />
ICON = <small>[[Benefits|More...]]</small>|<br />
HEADING = [[Benefits]]|<br />
CONTENT =<br />
<small><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 />
</small><br />
}}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = #d1adf6|<br />
WIDTH = 100%|<br />
ICON = <small>[[Use Cases|More...]]</small>|<br />
HEADING = [[Use Cases]]|<br />
CONTENT =<br />
<small><br />
* Desktop PCs, servers, clusters, thin clients<br />
* [[Clusters]], high-performance computing<br />
<!-- * Set-Top-Boxes, thin clients --><br />
* Embedded solutions, STBs/HTPC, 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 "disk")<br />
* Non-standard scenarios (e.g. FPGA in Opteron socket)<br />
</small><br />
}}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = lime|<br />
WIDTH = 100%|<br />
ICON = <small>[[Payloads|More...]]</small>|<br />
HEADING = [[Payloads]]|<br />
CONTENT =<br />
<small><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 />
</small><br />
}}<br />
<br />
|}<br />
<br />
{| cellspacing=5 cellpadding=5 border=0 valign="top" width=100%<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_lb.png]]<br />
|style="vertical-align:top"|<br />
'''About'''<br /><small>Find out more about coreboot.<hr />[[News]] | [[Press]] | [[Current events|Events]] | [[History]] | [[Screenshots|Screenshots & Videos]] | [[Contributors]] | [[Sponsors]] | [[Products]] | [[Clusters]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_devel.png]]<br />
|style="vertical-align:top"|<br />
'''Developers'''<br /><small>Get involved! Help us make coreboot better.<hr />[[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]]</small><br />
|}<br />
<br />
|-<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_status.png]]<br />
|style="vertical-align:top"|<br />
'''Status'''<br /><small>Find out whether your hardware is already supported.<hr />[[Supported Motherboards]] | [[Supported Chipsets and Devices|Supported Chipsets & Devices]] | [http://qa.coreboot.org Build Status] | [[Flashrom#Supported_devices|Flashrom support]] | [[Superiotool#Supported_devices|Superiotool support]] | [[Notes for v3 ports]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_tools.png]]<br />
|style="vertical-align:top"|<br />
'''Related Tools'''<br /><small>Tools and libraries related to coreboot.<hr />[[Flashrom]] | [[Superiotool]] | [[Nvramtool]] | [[Buildrom]] | [[Libpayload]] | [[Mkelfimage]]</small><br />
|}<br />
<br />
|-<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_101.png]]<br />
|style="vertical-align:top"|<br />
'''Getting Started'''<br /><small>Download coreboot and get started.<hr />[[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]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_support.png]]<br />
|style="vertical-align:top"|<br />
'''Support'''<br /><small>Learn how to contact us and find help and support.<hr />[[FAQ]] | [[Mailinglist]] | [[IRC]] | [http://tracker.coreboot.org/trac/coreboot/ Issue Tracker] | [[Glossary]] | [[coreboot Options|corebootv2 Options]]</small><br />
|}<br />
<br />
|}<br />
</td><td width="20%"><br />
<br />
[[Image:Coreboot libpayload tint.png|center|thumb|coreboot [[tint]] payload]]<br />
<br />
<br clear=all /><br />
<br />
'''<span style="font-variant:small-caps;">[[News]]</span>'''<hr /><br />
<!-- Please always make this list 7 items long (7 most recent news items). --><br />
<small><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 />
</small><br />
<br />
'''<span style="font-variant:small-caps;">Contact</span>'''<hr /><br />
<small><br />
* [[Mailinglist|Mailing list]]: [mailto:coreboot@coreboot.org coreboot@coreboot.org]<br />
* [[IRC]]: '''#coreboot''' (on [http://www.freenode.net/ irc.freenode.net])<br />
</small><br />
</td></tr></table><br />
__NOTOC__<br />
__NOEDITSECTION__</div>Rminnichhttps://www.coreboot.org/index.php?title=Welcome_to_coreboot&diff=6759Welcome to coreboot2008-08-11T15:34:59Z<p>Rminnich: add a link for v3 port notes</p>
<hr />
<div><table width="100%" valign="top"><tr valign="top"><td width="80%"><br />
<br />
<div style="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;"><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 />
</div><br />
<br />
{| cellspacing=0 cellpadding=3 border=0 margin=0 padding=0 align="top" width=100%<br />
|-<br />
|style="vertical-align:top"|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = yellow|<br />
WIDTH = 100%|<br />
ICON = <small>[[Benefits|More...]]</small>|<br />
HEADING = [[Benefits]]|<br />
CONTENT =<br />
<small><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 />
</small><br />
}}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = #d1adf6|<br />
WIDTH = 100%|<br />
ICON = <small>[[Use Cases|More...]]</small>|<br />
HEADING = [[Use Cases]]|<br />
CONTENT =<br />
<small><br />
* Desktop PCs, servers, clusters, thin clients<br />
* [[Clusters]], high-performance computing<br />
<!-- * Set-Top-Boxes, thin clients --><br />
* Embedded solutions, STBs/HTPC, 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 "disk")<br />
* Non-standard scenarios (e.g. FPGA in Opteron socket)<br />
</small><br />
}}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = lime|<br />
WIDTH = 100%|<br />
ICON = <small>[[Payloads|More...]]</small>|<br />
HEADING = [[Payloads]]|<br />
CONTENT =<br />
<small><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 />
</small><br />
}}<br />
<br />
|}<br />
<br />
{| cellspacing=5 cellpadding=5 border=0 valign="top" width=100%<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_lb.png]]<br />
|style="vertical-align:top"|<br />
'''About'''<br /><small>Find out more about coreboot.<hr />[[News]] | [[Press]] | [[Current events|Events]] | [[History]] | [[Screenshots|Screenshots & Videos]] | [[Contributors]] | [[Sponsors]] | [[Products]] | [[Clusters]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_devel.png]]<br />
|style="vertical-align:top"|<br />
'''Developers'''<br /><small>Get involved! Help us make coreboot better.<hr />[[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]]</small><br />
|}<br />
<br />
|-<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_status.png]]<br />
|style="vertical-align:top"|<br />
'''Status'''<br /><small>Find out whether your hardware is already supported.<hr />[[Supported Motherboards]] | [[Supported Chipsets and Devices|Supported Chipsets & Devices]] | [http://qa.coreboot.org Build Status] | [[Flashrom#Supported_devices|Flashrom support]] | [[Superiotool#Supported_devices|Superiotool support]] | [[Notes for v3 ports]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_tools.png]]<br />
|style="vertical-align:top"|<br />
'''Related Tools'''<br /><small>Tools and libraries related to coreboot.<hr />[[Flashrom]] | [[Superiotool]] | [[Nvramtool]] | [[Buildrom]] | [[Libpayload]] | [[Mkelfimage]]</small><br />
|}<br />
<br />
|-<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_101.png]]<br />
|style="vertical-align:top"|<br />
'''Getting Started'''<br /><small>Download coreboot and get started.<hr />[[Download coreboot|Downloads]] | [[Documentation]] | [[:Category:Tutorials|Build Tutorials]] | [[Payloads]] | [[QEMU]] | [[AMD SimNow]] | [[Confirmed working svn revisions|Confirmed Working SVN Revisions]] | [[Misc]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_support.png]]<br />
|style="vertical-align:top"|<br />
'''Support'''<br /><small>Learn how to contact us and find help and support.<hr />[[FAQ]] | [[Mailinglist]] | [[IRC]] | [http://tracker.coreboot.org/trac/coreboot/ Issue Tracker] | [[Glossary]] | [[coreboot Options|corebootv2 Options]]</small><br />
|}<br />
<br />
|}<br />
</td><td width="20%"><br />
<br />
[[Image:Coreboot libpayload tint.png|center|thumb|coreboot [[tint]] payload]]<br />
<br />
<br clear=all /><br />
<br />
'''<span style="font-variant:small-caps;">[[News]]</span>'''<hr /><br />
<!-- Please always make this list 7 items long (7 most recent news items). --><br />
<small><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 />
</small><br />
<br />
'''<span style="font-variant:small-caps;">Contact</span>'''<hr /><br />
<small><br />
* [[Mailinglist|Mailing list]]: [mailto:coreboot@coreboot.org coreboot@coreboot.org]<br />
* [[IRC]]: '''#coreboot''' (on [http://www.freenode.net/ irc.freenode.net])<br />
</small><br />
</td></tr></table><br />
__NOTOC__<br />
__NOEDITSECTION__</div>Rminnichhttps://www.coreboot.org/index.php?title=Welcome_to_coreboot&diff=6070Welcome to coreboot2008-03-28T04:42:26Z<p>Rminnich: just a headline, remove in 10 days, about coreboot summit</p>
<hr />
<div><table width="100%" valign="top"><tr valign="top"><td width="80%"><br />
<br />
<div style="margin-top:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;"><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 />
</div><br />
{| cellspacing=2 cellpadding=2 border=0 valign="top" width=100%<br />
|-<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps;">[[Benefits]]</span>'''<br />
<hr /><br />
<small><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 />
</small><br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps;">[[Use Cases]]</span>'''<br />
<hr /><br />
<small><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 "disk")<br />
* Non-standard scenarios (e.g. FPGA in Opteron socket)<br />
</small><br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps;">[[Payloads]]</span>'''<br />
<hr /><br />
<table><tr style="vertical-align:top"><td><br />
<small><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 />
</small><br />
</td><td><br />
<small><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 />
</small><br />
</td></tr></table><br />
|}<br />
<hr /><br />
{| cellspacing=5 cellpadding=5 border=0 valign="top" width=100%<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_lb.png]]<br />
|style="vertical-align:top"|<br />
'''About'''<br /><small>Find out more about coreboot.<hr />[[News]] | [[Press]] | [[Current events|Events]] | [[History]] | [[Screenshots|Screenshots & Videos]] | [[Contributors]] | [[Sponsors]] | [[Products]] | [[Clusters]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_devel.png]]<br />
|style="vertical-align:top"|<br />
'''Developers'''<br /><small>Get involved! Help us make coreboot better.<hr />[[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]]</small><br />
|}<br />
<br />
|-<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_status.png]]<br />
|style="vertical-align:top"|<br />
'''Status'''<br /><small>Find out whether your hardware is already supported.<hr />[[Supported Motherboards]] | [[Supported Chipsets and Devices|Supported Chipsets & Devices]] | [http://qa.coreboot.org Build Status] | [[Flashrom#Supported_devices|Flashrom support]] | [[Superiotool#Supported_devices|Superiotool support]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_tools.png]]<br />
|style="vertical-align:top"|<br />
'''Related Tools'''<br /><small>Tools and libraries related to coreboot.<hr />[[Flashrom]] | [[Superiotool]] | [[Nvramtool]] | [[Buildrom]] | [[Libpayload]] | [[Mkelfimage]] </small><br />
|}<br />
<br />
|-<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_101.png]]<br />
|style="vertical-align:top"|<br />
'''Getting Started'''<br /><small>Download coreboot and get started.<hr />[[Download coreboot|Downloads]] | [[Documentation]] | [[:Category:Tutorials|Build Tutorials]] | [[Payloads]] | [[QEMU]] | [[AMD SimNow]] | [[Confirmed working svn revisions|Confirmed Working SVN Revisions]] | [[Misc]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_support.png]]<br />
|style="vertical-align:top"|<br />
'''Support'''<br /><small>Learn how to contact us and find help and support.<hr />[[FAQ]] | [[Mailinglist]] | [[IRC]] | [http://tracker.coreboot.org/trac/coreboot/ Issue Tracker] | [[Glossary]] | [[coreboot Options|corebootv2 Options]]</small><br />
|}<br />
<br />
|}<br />
</td><td width="20%"><br />
<br />
[[Image:Coreinfo pci.png|thumb|The [[coreinfo|coreinfo payload]].]]<br />
<br clear=all /><br />
<br />
'''<span style="font-variant:small-caps;">[[News]]</span>'''<hr /><br />
<small><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 />
</small><br />
<br />
'''<span style="font-variant:small-caps;">Contact</span>'''<hr /><br />
<small><br />
* [[Mailinglist|Mailing list]]: [mailto:coreboot@coreboot.org coreboot@coreboot.org]<br />
* [[IRC]]: '''#coreboot''' (on [http://www.freenode.net/ irc.freenode.net])<br />
</small><br />
<br />
</td></tr></table><br />
__NOTOC__<br />
__NOEDITSECTION__</div>Rminnichhttps://www.coreboot.org/index.php?title=Current_events&diff=6039Current events2008-03-27T18:44:35Z<p>Rminnich: add a page for denver 2008 meeting</p>
<hr />
<div></div>Rminnichhttps://www.coreboot.org/index.php?title=GSoC&diff=5867GSoC2008-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 "payloads" 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 "CMOS setup". 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>Rminnichhttps://www.coreboot.org/index.php?title=Welcome_to_coreboot&diff=5005Welcome to coreboot2007-10-03T22:22:04Z<p>Rminnich: Remove OLPC reference</p>
<hr />
<div><table width="100%" valign="top"><tr valign="top"><td width="80%"><br />
<br />
<div style="margin-top:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;"><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 />
</div><br />
{| cellspacing=5 cellpadding=5 border=0 valign="top" width=100%<br />
|-<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps;">[[Benefits]]</span>''' &mdash;<br />
<small>There are many reasons for using LinuxBIOS.</small><br />
<hr /><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="vertical-align:top"|<br />
'''<span style="font-variant:small-caps;">[[Use Cases]]</span>''' &mdash;<br />
<small>LinuxBIOS can be deployed in a wide range of scenarios.</small><br />
<hr /><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 "hard drive")<br />
* Various non-standard scenarios (e.g. FPGA in Opteron socket)<br />
|}<br />
<hr /><br />
{| cellspacing=5 cellpadding=5 border=0 valign="top" width=100%<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_lb.png]]<br />
|style="vertical-align:top"|<br />
'''About'''<br /><small>Find out more about LinuxBIOS.<hr />[[News]] | [[Press]] | [[History]] | [[Screenshots|Screenshots & Videos]] | [[Contributors]] | [[Sponsors]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_devel.png]]<br />
|style="vertical-align:top"|<br />
'''Developers'''<br /><small>Get involved! Help us make LinuxBIOS better.<hr />[[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]]</small><br />
|}<br />
<br />
|-<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_status.png]]<br />
|style="vertical-align:top"|<br />
'''Status'''<br /><small>Find out whether your hardware is already supported.<hr />[[Supported Motherboards]] | [[Supported Chipsets and Devices|Supported Chipsets & Devices]] | [http://qa.linuxbios.org Build Status] | [[Flashrom#Supported_devices|Flashrom support]] | [[Superiotool#Supported_devices|Superiotool support]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_vendors.png]]<br />
|style="vertical-align:top"|<br />
'''Vendors & Products'''<br /><small>Find out in which products LinuxBIOS is used.<hr />[[Products]] | [[Clusters]] | [[Laptop]] | [[Desktops]]</small><br />
|}<br />
<br />
|-<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_101.png]]<br />
|style="vertical-align:top"|<br />
'''Getting Started'''<br /><small>Download LinuxBIOS and get started.<hr />[[Download LinuxBIOS|Downloads]] | [[Documentation]] | [[Documentation#How-To.27s|Build Tutorials]] | [[Payloads]] | [[QEMU]] | [[Confirmed working svn revisions|Confirmed Working SVN Revisions]] | [[Buildrom]] | [[Flashrom]] | [[Misc]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_support.png]]<br />
|style="vertical-align:top"|<br />
'''Support'''<br /><small>Learn how to contact us and find help and support.<hr />[[FAQ]] | [[Mailinglist]] | [[IRC]] | [http://tracker.linuxbios.org/trac/LinuxBIOS/ Issue Tracker] | [[Glossary]] | [[LinuxBIOS Options|LinuxBIOSv2 Options]]</small><br />
|}<br />
<br />
|}<br />
</td><td width="20%"><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 />
<br clear=all /><br />
<br />
'''<span style="font-variant:small-caps;">[[News]]</span>'''<hr /><br />
<small><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; 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; ROCKY-512 support]]<br />
* '''2007/05/24:''' [[News#2007.2F05.2F24_ASUS_A8N-E_now_supported|ASUS A8N-E support]]<br />
</small><br />
<br />
'''<span style="font-variant:small-caps;">Contact</span>'''<hr /><br />
<small><br />
* [[Mailinglist|Mailing list]]: [mailto:linuxbios@linuxbios.org linuxbios@linuxbios.org]<br />
* [[IRC]]: '''#linuxbios''' (on [http://www.freenode.net/ irc.freenode.net])<br />
</small><br />
<br />
</td></tr></table><br />
__NOTOC__<br />
__NOEDITSECTION__</div>Rminnichhttps://www.coreboot.org/index.php?title=Welcome_to_coreboot&diff=1151Welcome to coreboot2005-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 & 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>Rminnichhttps://www.coreboot.org/index.php?title=File:Homework.pdf&diff=2331File:Homework.pdf2005-10-17T01:14:25Z<p>Rminnich: These are the homework assignments</p>
<hr />
<div>These are the homework assignments</div>Rminnichhttps://www.coreboot.org/index.php?title=File:Openefi.pdf&diff=2330File:Openefi.pdf2005-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>Rminnichhttps://www.coreboot.org/index.php?title=File:The_real_linuxbios.pdf&diff=2329File:The real linuxbios.pdf2005-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>Rminnichhttps://www.coreboot.org/index.php?title=Welcome_to_coreboot&diff=1134Welcome to coreboot2005-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 & 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>Rminnichhttps://www.coreboot.org/index.php?title=Welcome_to_coreboot&diff=1128Welcome to coreboot2005-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 & 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>Rminnichhttps://www.coreboot.org/index.php?title=Download_coreboot&diff=1007Download coreboot2005-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 />
<code><pre><br />
% # get gpg key for checking signed archives<br />
% wget \<br />
http://wiki.linuxbios.org/data/arch/linuxbios-developers-keyring.gpg<br />
% gpg --import < linuxbios-developers-keyring.gpg<br />
% # now do some one time registrations<br />
% tla my-id "John Doe <doe@example.com>" # 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 />
</pre></code><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 "John Doe <doe@example.com>"<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 "gpg --clearsign" > ~/.arch-params/signing/\=default<br />
$ echo "gpg --verify-files -" > ~/.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 > ~/.arch-params/signing/=default<br />
echo gpg --verify-files - > ~/.arch-params/signing/=default.check<br />
echo linuxbios@linuxbios.org--devel--SOURCE > ~/.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 "FreeBIOS"). 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 />
<code>% cvs -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios login</code><br />
<br />
Hit return when it asks you for a password (no password needed). Then checkout (or update) the freebios2 source tree: <br />
<br />
<code>% cvs -z3 -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios co freebios2</code><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>Rminnichhttps://www.coreboot.org/index.php?title=Welcome_to_coreboot&diff=1012Welcome to coreboot2005-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>Rminnichhttps://www.coreboot.org/index.php?title=FAQ&diff=963FAQ2005-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 />
<Need some more links to POST cards><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) "Use the source Luke"<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 "flash_rom". 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 "disk". 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 />
> I have pcchips m758lmr which has audio chip besides sis630. <br />
> those functions in sis630 are not used in the motherboard. <br />
> 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 -> 1100 in binary (first 4 bits) <br />
To turn off Multimedia audio : <br />
0x7c01 -> 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 & 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="root=/dev/hda2 console=ttyS0,38400" \<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 />
"Adam Bezanson" writes:<br />
<br />
> I've got an Eval card from National Semi that contains<br />
> the SC1200. I'd like to try LinuxBios on it.<br />
> I've downloaded both the 2.4.18 and 2.4.19 kernels to start with.<br />
> What patches do I need to apply to the kernel?<br />
> Is there a config file I can use to configure the kernel, or<br />
> 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&oe=UTF-8&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 />
"Just how much can I get away with and still go to heaven?"<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 "$(ARCH)" == "x86_64" ; 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 />
<nowiki>========================================================================</nowiki><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 "as is" 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 />
<nowiki>========================================================================</nowiki><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 "$(ARCH)" == "x86_64" ; 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:<br /><code>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 />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 "Video ROM"<br /></code><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:<br /><code>./testbios -s 65536 --abseg /dev/mem ./vgabios.bin</code><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:<br /><code>2:00:00<br />2 (00 << 3) | 00 = 0x200</code><br />
***** Example:<br /><code>00:12.0:<br />0 (12 << 3) | 0 = 0x90</code><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 />
> It seems my dd returned an unusable binary. I found a good binary for<br />
<br />
> The nvidia card from here:<br />
> http://whitebunny.demon.nl/hardware/chipset_nvidia.html<br />
> <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>Rminnichhttps://www.coreboot.org/index.php?title=FAQ&diff=960FAQ2005-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 />
<Need some more links to POST cards><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) "Use the source Luke"<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 "flash_rom". 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 "disk". 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 />
> I have pcchips m758lmr which has audio chip besides sis630. <br />
> those functions in sis630 are not used in the motherboard. <br />
> 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 -> 1100 in binary (first 4 bits) <br />
To turn off Multimedia audio : <br />
0x7c01 -> 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 & 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="root=/dev/hda2 console=ttyS0,38400" \<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 />
"Adam Bezanson" writes:<br />
<br />
> I've got an Eval card from National Semi that contains<br />
> the SC1200. I'd like to try LinuxBios on it.<br />
> I've downloaded both the 2.4.18 and 2.4.19 kernels to start with.<br />
> What patches do I need to apply to the kernel?<br />
> Is there a config file I can use to configure the kernel, or<br />
> 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&oe=UTF-8&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 />
"Just how much can I get away with and still go to heaven?"<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 "$(ARCH)" == "x86_64" ; 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 />
<nowiki>========================================================================</nowiki><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 "as is" 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 />
<nowiki>========================================================================</nowiki><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 "$(ARCH)" == "x86_64" ; 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:<br /><code>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 />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 "Video ROM"<br /></code><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:<br /><code>./testbios -s 65536 --abseg /dev/mem ./vgabios.bin</code><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:<br /><code>2:00:00<br />2 (00 << 3) | 00 = 0x200</code><br />
***** Example:<br /><code>00:12.0:<br />0 (12 << 3) | 0 = 0x90</code><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 />
> It seems my dd returned an unusable binary. I found a good binary for<br />
<br />
> The nvidia card from here:<br />
> http://whitebunny.demon.nl/hardware/chipset_nvidia.html<br />
> <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>Rminnichhttps://www.coreboot.org/index.php?title=Payloads&diff=95Payloads2005-03-01T22:07:53Z<p>Rminnich: </p>
<hr />
<div>LinuxBIOS in itself is "only" 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>Rminnichhttps://www.coreboot.org/index.php?title=PCCHIPS_M810LR&diff=2067PCCHIPS M810LR2005-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 "hardware and software interchangeable". 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 />
<M> Memory Technology Device (MTD) support<br />
[ ] Debugging<br />
< > MTD partitioning support<br />
< > MTD concatenating support<br />
--- User Modules and Transition Layers<br />
<M> Direct char device access to MTD devices<br />
< > Caching block device access to MTD devices<br />
< > Readonly block device access to MTD devices<br />
< > FTL (Flash Transition Layer) support<br />
< > NFTL (NAND Flash Transition Layer) support<br />
RAM/ROM/Flash chip drivers ---><br />
Mapping drivers for chip access ---><br />
Self-contained MTD device drivers ---><br />
< > Ramix PMC551 PCI Mezzanine RAM card support<br />
< > Uncached system RAM<br />
< > Test driver using RAM<br />
< > MTD emulation using block device<br />
--- Disk-On-Chip Device Drivers<br />
< > M-Systems Disk-On-Chip 1000<br />
< > M-Systems Disk-On-Chip 2000 and Millennium<br />
<M> 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 ---><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 "failed to open ./cvspass for reading" and even "login aborted: fatal error: exiting". 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 "pc_keyb: controller jammed (0xFF)", 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 "Wow!", 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>Rminnichhttps://www.coreboot.org/index.php?title=PCCHIPS_M810LR&diff=30PCCHIPS M810LR2005-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 "hardware and software interchangeable". 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 />
<M> Memory Technology Device (MTD) support<br />
[ ] Debugging<br />
< > MTD partitioning support<br />
< > MTD concatenating support<br />
--- User Modules and Transition Layers<br />
<M> Direct char device access to MTD devices<br />
< > Caching block device access to MTD devices<br />
< > Readonly block device access to MTD devices<br />
< > FTL (Flash Transition Layer) support<br />
< > NFTL (NAND Flash Transition Layer) support<br />
RAM/ROM/Flash chip drivers ---><br />
Mapping drivers for chip access ---><br />
Self-contained MTD device drivers ---><br />
< > Ramix PMC551 PCI Mezzanine RAM card support<br />
< > Uncached system RAM<br />
< > Test driver using RAM<br />
< > MTD emulation using block device<br />
--- Disk-On-Chip Device Drivers<br />
< > M-Systems Disk-On-Chip 1000<br />
< > M-Systems Disk-On-Chip 2000 and Millennium<br />
<M> 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 ---><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 "failed to open ./cvspass for reading" and even "login aborted: fatal error: exiting". 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 "pc_keyb: controller jammed (0xFF)", 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 "Wow!", 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>Rminnichhttps://www.coreboot.org/index.php?title=PCCHIPS_M810LR&diff=29PCCHIPS M810LR2005-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 "hardware and software interchangeable". 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 />
<M> Memory Technology Device (MTD) support<br />
[ ] Debugging<br />
< > MTD partitioning support<br />
< > MTD concatenating support<br />
--- User Modules and Transition Layers<br />
<M> Direct char device access to MTD devices<br />
< > Caching block device access to MTD devices<br />
< > Readonly block device access to MTD devices<br />
< > FTL (Flash Transition Layer) support<br />
< > NFTL (NAND Flash Transition Layer) support<br />
RAM/ROM/Flash chip drivers ---><br />
Mapping drivers for chip access ---><br />
Self-contained MTD device drivers ---><br />
< > Ramix PMC551 PCI Mezzanine RAM card support<br />
< > Uncached system RAM<br />
< > Test driver using RAM<br />
< > MTD emulation using block device<br />
--- Disk-On-Chip Device Drivers<br />
< > M-Systems Disk-On-Chip 1000<br />
< > M-Systems Disk-On-Chip 2000 and Millennium<br />
<M> 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 ---><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 "failed to open ./cvspass for reading" and even "login aborted: fatal error: exiting". 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 "pc_keyb: controller jammed (0xFF)", 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 "Wow!", 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>Rminnichhttps://www.coreboot.org/index.php?title=The_EPIA-M/MII&diff=1152The EPIA-M/MII2005-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 "iso-8859-1" character set. ]<br />
[ Your display is set for the "UTF-8" 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 > 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 = "hde:/vmlinuz initrd=hde:/initrd.gz root=/dev/hde<br />
console=tty0 ide2=noprobe"<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>Rminnichhttps://www.coreboot.org/index.php?title=Technoland_SBC_710&diff=163Technoland SBC 7102005-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&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 "mainboard" 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&T video chip; and two Winbond Super IO chips, the 83977EF and the 83877TF. All of these chips except the 83877 and the C&T chip are supported. We don't care about the C&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 "mainboard" 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 />
< mainboardinit superio/NSC/pc87309/setup_serial.inc<br />
---<br />
> # mainboardinit superio/NSC/pc87309/setup_serial.inc<br />
13c13,15<br />
< superio NSC/pc87309<br />
---<br />
> #superio NSC/pc87309<br />
> nsuperio winbond/w83977ef keyboard=1<br />
> nsuperio winbond/w83877tf<br />
24a27,29<br />
> <br />
> option UPDATE_MICROCODE<br />
> 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>Rminnichhttps://www.coreboot.org/index.php?title=Technoland_SBC_710&diff=28Technoland SBC 7102005-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&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 "mainboard" 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&T video chip; and two Winbond Super IO chips, the 83977EF and the 83877TF. All of these chips except the 83877 and the C&T chip are supported. We don't care about the C&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 "mainboard" 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 />
< mainboardinit superio/NSC/pc87309/setup_serial.inc<br />
---<br />
> # mainboardinit superio/NSC/pc87309/setup_serial.inc<br />
13c13,15<br />
< superio NSC/pc87309<br />
---<br />
> #superio NSC/pc87309<br />
> nsuperio winbond/w83977ef keyboard=1<br />
> nsuperio winbond/w83877tf<br />
24a27,29<br />
> <br />
> option UPDATE_MICROCODE<br />
> 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>Rminnichhttps://www.coreboot.org/index.php?title=Technoland_SBC_710&diff=27Technoland SBC 7102005-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&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 "mainboard" 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&T video chip; and two Winbond Super IO chips, the 83977EF and the 83877TF. All of these chips except the 83877 and the C&T chip are supported. We don't care about the C&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 "mainboard" 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 />
< mainboardinit superio/NSC/pc87309/setup_serial.inc<br />
---<br />
> # mainboardinit superio/NSC/pc87309/setup_serial.inc<br />
13c13,15<br />
< superio NSC/pc87309<br />
---<br />
> #superio NSC/pc87309<br />
> nsuperio winbond/w83977ef keyboard=1<br />
> nsuperio winbond/w83877tf<br />
24a27,29<br />
> <br />
> option UPDATE_MICROCODE<br />
> 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>Rminnichhttps://www.coreboot.org/index.php?title=Welcome_to_coreboot&diff=66Welcome to coreboot2005-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>Rminnichhttps://www.coreboot.org/index.php?title=FAQ&diff=31FAQ2005-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 "disk". 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 />
> I have pcchips m758lmr which has audio chip besides sis630. <br />
> those functions in sis630 are not used in the motherboard. <br />
> 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 -> 1100 in binary (first 4 bits) <br />
To turn off Multimedia audio : <br />
0x7c01 -> 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 & 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="root=/dev/hda2 console=ttyS0,38400" \<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 />
"Adam Bezanson" writes:<br />
<br />
> I've got an Eval card from National Semi that contains<br />
> the SC1200. I'd like to try LinuxBios on it.<br />
> I've downloaded both the 2.4.18 and 2.4.19 kernels to start with.<br />
> What patches do I need to apply to the kernel?<br />
> Is there a config file I can use to configure the kernel, or<br />
> 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&oe=UTF-8&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 />
"Just how much can I get away with and still go to heaven?"<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 "$(ARCH)" == "x86_64" ; 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 "as is" 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 "$(ARCH)" == "x86_64" ; 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 "Video ROM"<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 << 3) | 00 = 0x200<br />
Example:<br />
00:12.0:<br />
0 (12 << 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 />
> It seems my dd returned an unusable binary. I found a good binary for<br />
<br />
> The nvidia card from here:<br />
> http://whitebunny.demon.nl/hardware/chipset_nvidia.html<br />
> <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>Rminnichhttps://www.coreboot.org/index.php?title=FAQ&diff=25FAQ2005-03-01T16:06:44Z<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 "disk". 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 />
> I have pcchips m758lmr which has audio chip besides sis630. <br />
> those functions in sis630 are not used in the motherboard. <br />
> 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 -> 1100 in binary (first 4 bits) <br />
To turn off Multimedia audio : <br />
0x7c01 -> 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 & 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="root=/dev/hda2 console=ttyS0,38400" \<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 />
"Adam Bezanson" writes:<br />
<br />
> I've got an Eval card from National Semi that contains<br />
> the SC1200. I'd like to try LinuxBios on it.<br />
> I've downloaded both the 2.4.18 and 2.4.19 kernels to start with.<br />
> What patches do I need to apply to the kernel?<br />
> Is there a config file I can use to configure the kernel, or<br />
> 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&oe=UTF-8&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 />
"Just how much can I get away with and still go to heaven?"<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 "$(ARCH)" == "x86_64" ; 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 "as is" 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 "$(ARCH)" == "x86_64" ; 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 "Video ROM"<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 << 3) | 00 = 0x200<br />
Example:<br />
00:12.0:<br />
0 (12 << 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 />
> It seems my dd returned an unusable binary. I found a good binary for<br />
<br />
> The nvidia card from here:<br />
> http://whitebunny.demon.nl/hardware/chipset_nvidia.html<br />
> <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 />
Linuxbios mailing list<br />
Linuxbios@clustermatic.org<br />
http://www.clustermatic.org/mailman/listinfo/linuxbios<br />
<br />
<br />
<br />
</div>Rminnichhttps://www.coreboot.org/index.php?title=FAQ&diff=24FAQ2005-03-01T16:04:59Z<p>Rminnich: This is the FAQ page.</p>
<hr />
<div>General<br />
<br />
<br />
What is LinuxBIOS? <br />
Why do we need LinuxBIOS? <br />
Who is working on LinuxBIOS? <br />
Who is funding LinuxBIOS? <br />
Will LinuxBIOS work on my machine? <br />
What commercial products use LinuxBIOS? <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 />
How do I build? <br />
Why is the code so complicated and what can I do to make it easier? <br />
What chipsets are supported? <br />
What is this POST card thing? <br />
How do I contribute my changes? <br />
How do I re-flash the BIOS? <br />
How do I actually burn a flash ROM? <br />
How do I burn a DoC? <br />
Can I do any serious damage mucking around with this stuff? <br />
How do I put a filesystem on DoC? <br />
How do I turn off embedded sis630 devices? <br />
What is a PIRQ table? <br />
How do I set up etherboot with LinuxBIOS? <br />
How do I set GEODE video? <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 "disk". 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 />
> I have pcchips m758lmr which has audio chip besides sis630. <br />
> those functions in sis630 are not used in the motherboard. <br />
> 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 -> 1100 in binary (first 4 bits) <br />
To turn off Multimedia audio : <br />
0x7c01 -> 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 & 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="root=/dev/hda2 console=ttyS0,38400" \<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 />
"Adam Bezanson" writes:<br />
<br />
> I've got an Eval card from National Semi that contains<br />
> the SC1200. I'd like to try LinuxBios on it.<br />
> I've downloaded both the 2.4.18 and 2.4.19 kernels to start with.<br />
> What patches do I need to apply to the kernel?<br />
> Is there a config file I can use to configure the kernel, or<br />
> 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&oe=UTF-8&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 />
"Just how much can I get away with and still go to heaven?"<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 "$(ARCH)" == "x86_64" ; 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 "as is" 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 "$(ARCH)" == "x86_64" ; 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 "Video ROM"<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 << 3) | 00 = 0x200<br />
Example:<br />
00:12.0:<br />
0 (12 << 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 />
> It seems my dd returned an unusable binary. I found a good binary for<br />
<br />
> The nvidia card from here:<br />
> http://whitebunny.demon.nl/hardware/chipset_nvidia.html<br />
> <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 />
Linuxbios mailing list<br />
Linuxbios@clustermatic.org<br />
http://www.clustermatic.org/mailman/listinfo/linuxbios<br />
<br />
<br />
<br />
</div>Rminnichhttps://www.coreboot.org/index.php?title=Welcome_to_coreboot&diff=26Welcome to coreboot2005-03-01T16:02:46Z<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]]</div>Rminnich