http://www.coreboot.org/api.php?action=feedcontributions&user=Hailfinger&feedformat=atom 2013-05-20T09:21:37Z User contributions MediaWiki 1.20.5 http://www.coreboot.org/Project_Ideas 2013-03-30T01:39:07Z

<p>Hailfinger: /* Board config infrastructure */</p> <hr /> <div>The following are some ideas that have come up in the community. Some are more or less suitable for [[GSoC]] and prospective students' application should expand on some ideas and pair back others.<br /> <br /> == Linux Firmware Kit, BITS ==<br /> <br /> There are various test suites for firmware aspects, esp. those that interacts with the operating systems. Unfortunately, some of these projects are dead, some seem to be forked and developed semi-publically, and having all that stuff in lots of different places is a big hassle.<br /> <br /> The goal of this project is to pick up the pieces, and create a single tool (most likely a bootable CD/USB drive image) that can be booted on vendor BIOS (for the Red Hat and Canonical developers that work on these) as well as coreboot (preferably seabios and FILO to improve testability - is an issue created/fixed by coreboot or seabios?). This can then be improved in various ways.<br /> <br /> There's also intel-gpu-tools that might have some useful tests (at least for intel-boards): http://article.gmane.org/gmane.comp.video.dri.devel/63948<br /> <br /> When applying for this task, please state in your proposal what you think might be worthy extensions to the existing tests.<br /> <br /> Required knowledge for this task: Minimal coreboot and firmware experience, but you should have some idea of the boot process of a Linux system (as these test suites are mostly Linux based). GSoC probably won't provide enough time to learn all that (Linux boot process, firmware interfaces such as ACPI) and still develop the tools in some useful way.<br /> <br /> '''Links'''<br /> * https://wiki.ubuntu.com/Kernel/Reference/fwts<br /> * http://biosbits.org/ <br /> * http://linuxfirmwarekit.org/<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]]<br /> <br /> == Infrastructure for automatic code checking ==<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 /> <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/<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 /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]], [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> == Implement coreboot features for more boards ==<br /> A lot of cool coreboot features are only available for a subset of the supported mainboards:<br /> * global variables in romstage<br /> * relocatable ramstage<br /> * cbmem console<br /> * timestamps<br /> <br /> This project would analyze how to bring those features forward to more boards and work on doing so.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot test suite ==<br /> Create a test suite to gather and report coreboot mainboard and payload settings. This project may leverage libpayload, coreinfo, memtest86, BITS, and other tools like benchmarks for CPU and RAM performance. Konstantin Aladyshev reported according to the benchmark [http://www.cs.virginia.edu/stream/ STREAM], RAM access on his system with coreboot is four times slower than with the proprietary vendor BIOS. Such issues should be easily spotted with the test suite.<br /> <br /> The suite should gather result and report them at summary and detailed levels. The goal is to help coreboot developers identify problems and to test coreboot features. This project should work closely with the testing rig and test reporting projects. 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://biosbits.org/ BITS]<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]], [[User:PatrickGeorgi|Patrick Georgi]]<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 /> * [[InSystemFlasher]] is a cheap DIY hardware prototype for building an automated testing rig for modern SPI-based boards. This could be used as a starting point.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot mainboard test result reporting ==<br /> One of the biggest challenges in coreboot is support many systems in the same codebase. As systems age and coreboot continues to develop, the condition of mainboards becomes unknown. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. 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.coreboot.org/Supported_Motherboards<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> <br /> == coreboot ports for mainboards == <br /> Identify potential mainboards to port based on the recently release cpu and chipset support. The goal would be to support publicly available platforms with a number of payloads and operating systems.<br /> <br /> '''Mentors'''<br /> <br /> * [[User:ruik|Rudolf Marek]]<br /> <br /> == Tianocore as payload ==<br /> <br /> What SeaBIOS is for PC-BIOS interfaces, Tianocore is for UEFI - in fact, it's the reference implementation that most commercial UEFIs are built on. While coreboot favors other design goals than UEFI, it's really useful to support this standard that's being pushed on the market, just like SeaBIOS really helped coreboot by providing a BIOS &quot;frontend&quot;.<br /> <br /> There's already some code, but there's still much room for improvement: A graphics driver that uses a preinitialized (by coreboot) framebuffer. A CBFS driver so Tiano can access coreboot flash storage. Based on that, a flash driver (maybe adapted from flashrom) to implement non-volatile variable storage by writing to flash.<br /> <br /> Possible tasks depend a lot on existing knowledge of the candidate. Few of the tasks are large enough to fill the entire GSoC time frame with one of them. Feel free to discuss with us on IRC what a suitable target could be for you.<br /> <br /> '''Links'''<br /> * http://www.tianocore.org/<br /> * https://github.com/pgeorgi/edk2/tree/coreboot-pkg<br /> <br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> <br /> == coreboot ACPI 4.0 and S3 power management support ==<br /> coreboot has support for ACPI tables and S3 support for some platforms, but it is very mainboard specific and mostly based on ACPI 2.0. Create a generic solution for ACPI 4.0 table generation and S3 support.<br /> <br /> '''Mentors'''<br /> * Rudolf Marek?<br /> <br /> ==coreboot port to ARM SoC's with PCIe==<br /> <br /> While the links below are still relevant, we nowadays have a coreboot port for ARM Exynos. It was contributed by Google and the chip is used in a Chromebook. This means porting to other ARM SoCs is now easier due to generic infrastructure being in place.<br /> <br /> [http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm Xilinx Zynq-7030]<br /> <br /> [http://www.altera.com/devices/fpga/cyclone-v-fpgas/hard-processor-system/cyv-soc-hps.html Altera Cyclone V ]<br /> <br /> [http://www.st.com/internet/mcu/product/251211.jsp ST spear1340]<br /> <br /> <br /> [[ARM]] SoC's with PCIe are available. 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 /> There was an ARM project started in 2011. <br /> <br /> http://blogs.coreboot.org/blog/2011/05/11/gsoc2011-project-porting-coreboot-to-arm-architecture/<br /> <br /> '''Mentors'''<br /> * Bari Ari<br /> * [[User:Rminnich|Ron Minnich]]<br /> * [[User:Jason Wang|QingPei Wang]]<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 /> <br /> '''Mentors'''<br /> * [[User:Rminnich|Ron Minnich]]<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 /> * Depends on your choice of data structures (different mentors have different areas of expertise for this)<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 /> Alternatively, figure out a way how to build them in parallel and have coreboot select the right one on runtime.<br /> <br /> '''Links'''<br /> * src/cpu/amd/ inside the coreboot source tree<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == AMD VSA ==<br /> <br /> Get the source code of AMD's VSA compiled and working with an open source toolchain. Integrate the it into the current build system.<br /> <br /> '''Links'''<br /> * [[OpenVSA]], [[AMD Geode Porting Guide]]<br /> <br /> '''Mentors'''<br /> * Marc Jones?</div>

Hailfinger http://www.coreboot.org/Project_Ideas 2013-03-30T01:37:45Z

<p>Hailfinger: /* Board config infrastructure */</p> <hr /> <div>The following are some ideas that have come up in the community. Some are more or less suitable for [[GSoC]] and prospective students' application should expand on some ideas and pair back others.<br /> <br /> == Linux Firmware Kit, BITS ==<br /> <br /> There are various test suites for firmware aspects, esp. those that interacts with the operating systems. Unfortunately, some of these projects are dead, some seem to be forked and developed semi-publically, and having all that stuff in lots of different places is a big hassle.<br /> <br /> The goal of this project is to pick up the pieces, and create a single tool (most likely a bootable CD/USB drive image) that can be booted on vendor BIOS (for the Red Hat and Canonical developers that work on these) as well as coreboot (preferably seabios and FILO to improve testability - is an issue created/fixed by coreboot or seabios?). This can then be improved in various ways.<br /> <br /> There's also intel-gpu-tools that might have some useful tests (at least for intel-boards): http://article.gmane.org/gmane.comp.video.dri.devel/63948<br /> <br /> When applying for this task, please state in your proposal what you think might be worthy extensions to the existing tests.<br /> <br /> Required knowledge for this task: Minimal coreboot and firmware experience, but you should have some idea of the boot process of a Linux system (as these test suites are mostly Linux based). GSoC probably won't provide enough time to learn all that (Linux boot process, firmware interfaces such as ACPI) and still develop the tools in some useful way.<br /> <br /> '''Links'''<br /> * https://wiki.ubuntu.com/Kernel/Reference/fwts<br /> * http://biosbits.org/ <br /> * http://linuxfirmwarekit.org/<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]]<br /> <br /> == Infrastructure for automatic code checking ==<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 /> <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/<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 /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]], [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> == Implement coreboot features for more boards ==<br /> A lot of cool coreboot features are only available for a subset of the supported mainboards:<br /> * global variables in romstage<br /> * relocatable ramstage<br /> * cbmem console<br /> * timestamps<br /> <br /> This project would analyze how to bring those features forward to more boards and work on doing so.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot test suite ==<br /> Create a test suite to gather and report coreboot mainboard and payload settings. This project may leverage libpayload, coreinfo, memtest86, BITS, and other tools like benchmarks for CPU and RAM performance. Konstantin Aladyshev reported according to the benchmark [http://www.cs.virginia.edu/stream/ STREAM], RAM access on his system with coreboot is four times slower than with the proprietary vendor BIOS. Such issues should be easily spotted with the test suite.<br /> <br /> The suite should gather result and report them at summary and detailed levels. The goal is to help coreboot developers identify problems and to test coreboot features. This project should work closely with the testing rig and test reporting projects. 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://biosbits.org/ BITS]<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]], [[User:PatrickGeorgi|Patrick Georgi]]<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 /> * [[InSystemFlasher]] is a cheap DIY hardware prototype for building an automated testing rig for modern SPI-based boards. This could be used as a starting point.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot mainboard test result reporting ==<br /> One of the biggest challenges in coreboot is support many systems in the same codebase. As systems age and coreboot continues to develop, the condition of mainboards becomes unknown. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. 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.coreboot.org/Supported_Motherboards<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> <br /> == coreboot ports for mainboards == <br /> Identify potential mainboards to port based on the recently release cpu and chipset support. The goal would be to support publicly available platforms with a number of payloads and operating systems.<br /> <br /> '''Mentors'''<br /> <br /> * [[User:ruik|Rudolf Marek]]<br /> <br /> == Tianocore as payload ==<br /> <br /> What SeaBIOS is for PC-BIOS interfaces, Tianocore is for UEFI - in fact, it's the reference implementation that most commercial UEFIs are built on. While coreboot favors other design goals than UEFI, it's really useful to support this standard that's being pushed on the market, just like SeaBIOS really helped coreboot by providing a BIOS &quot;frontend&quot;.<br /> <br /> There's already some code, but there's still much room for improvement: A graphics driver that uses a preinitialized (by coreboot) framebuffer. A CBFS driver so Tiano can access coreboot flash storage. Based on that, a flash driver (maybe adapted from flashrom) to implement non-volatile variable storage by writing to flash.<br /> <br /> Possible tasks depend a lot on existing knowledge of the candidate. Few of the tasks are large enough to fill the entire GSoC time frame with one of them. Feel free to discuss with us on IRC what a suitable target could be for you.<br /> <br /> '''Links'''<br /> * http://www.tianocore.org/<br /> * https://github.com/pgeorgi/edk2/tree/coreboot-pkg<br /> <br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> <br /> == coreboot ACPI 4.0 and S3 power management support ==<br /> coreboot has support for ACPI tables and S3 support for some platforms, but it is very mainboard specific and mostly based on ACPI 2.0. Create a generic solution for ACPI 4.0 table generation and S3 support.<br /> <br /> '''Mentors'''<br /> * Rudolf Marek?<br /> <br /> ==coreboot port to ARM SoC's with PCIe==<br /> <br /> While the links below are still relevant, we nowadays have a coreboot port for ARM Exynos. It was contributed by Google and the chip is used in a Chromebook. This means porting to other ARM SoCs is now easier due to generic infrastructure being in place.<br /> <br /> [http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm Xilinx Zynq-7030]<br /> <br /> [http://www.altera.com/devices/fpga/cyclone-v-fpgas/hard-processor-system/cyv-soc-hps.html Altera Cyclone V ]<br /> <br /> [http://www.st.com/internet/mcu/product/251211.jsp ST spear1340]<br /> <br /> <br /> [[ARM]] SoC's with PCIe are available. 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 /> There was an ARM project started in 2011. <br /> <br /> http://blogs.coreboot.org/blog/2011/05/11/gsoc2011-project-porting-coreboot-to-arm-architecture/<br /> <br /> '''Mentors'''<br /> * Bari Ari<br /> * [[User:Rminnich|Ron Minnich]]<br /> * [[User:Jason Wang|QingPei Wang]]<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 /> <br /> '''Mentors'''<br /> * [[User:Rminnich|Ron Minnich]]<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 /> == 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 /> Alternatively, figure out a way how to build them in parallel and have coreboot select the right one on runtime.<br /> <br /> '''Links'''<br /> * src/cpu/amd/ inside the coreboot source tree<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == AMD VSA ==<br /> <br /> Get the source code of AMD's VSA compiled and working with an open source toolchain. Integrate the it into the current build system.<br /> <br /> '''Links'''<br /> * [[OpenVSA]], [[AMD Geode Porting Guide]]<br /> <br /> '''Mentors'''<br /> * Marc Jones?</div>

Hailfinger http://www.coreboot.org/Project_Ideas 2013-03-30T01:31:23Z

<p>Hailfinger: /* coreboot port to ARM SOC's with PCIe */</p> <hr /> <div>The following are some ideas that have come up in the community. Some are more or less suitable for [[GSoC]] and prospective students' application should expand on some ideas and pair back others.<br /> <br /> == Linux Firmware Kit, BITS ==<br /> <br /> There are various test suites for firmware aspects, esp. those that interacts with the operating systems. Unfortunately, some of these projects are dead, some seem to be forked and developed semi-publically, and having all that stuff in lots of different places is a big hassle.<br /> <br /> The goal of this project is to pick up the pieces, and create a single tool (most likely a bootable CD/USB drive image) that can be booted on vendor BIOS (for the Red Hat and Canonical developers that work on these) as well as coreboot (preferably seabios and FILO to improve testability - is an issue created/fixed by coreboot or seabios?). This can then be improved in various ways.<br /> <br /> There's also intel-gpu-tools that might have some useful tests (at least for intel-boards): http://article.gmane.org/gmane.comp.video.dri.devel/63948<br /> <br /> When applying for this task, please state in your proposal what you think might be worthy extensions to the existing tests.<br /> <br /> Required knowledge for this task: Minimal coreboot and firmware experience, but you should have some idea of the boot process of a Linux system (as these test suites are mostly Linux based). GSoC probably won't provide enough time to learn all that (Linux boot process, firmware interfaces such as ACPI) and still develop the tools in some useful way.<br /> <br /> '''Links'''<br /> * https://wiki.ubuntu.com/Kernel/Reference/fwts<br /> * http://biosbits.org/ <br /> * http://linuxfirmwarekit.org/<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]]<br /> <br /> == Infrastructure for automatic code checking ==<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 /> <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/<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 /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]], [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> == Implement coreboot features for more boards ==<br /> A lot of cool coreboot features are only available for a subset of the supported mainboards:<br /> * global variables in romstage<br /> * relocatable ramstage<br /> * cbmem console<br /> * timestamps<br /> <br /> This project would analyze how to bring those features forward to more boards and work on doing so.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot test suite ==<br /> Create a test suite to gather and report coreboot mainboard and payload settings. This project may leverage libpayload, coreinfo, memtest86, BITS, and other tools like benchmarks for CPU and RAM performance. Konstantin Aladyshev reported according to the benchmark [http://www.cs.virginia.edu/stream/ STREAM], RAM access on his system with coreboot is four times slower than with the proprietary vendor BIOS. Such issues should be easily spotted with the test suite.<br /> <br /> The suite should gather result and report them at summary and detailed levels. The goal is to help coreboot developers identify problems and to test coreboot features. This project should work closely with the testing rig and test reporting projects. 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://biosbits.org/ BITS]<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]], [[User:PatrickGeorgi|Patrick Georgi]]<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 /> * [[InSystemFlasher]] is a cheap DIY hardware prototype for building an automated testing rig for modern SPI-based boards. This could be used as a starting point.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot mainboard test result reporting ==<br /> One of the biggest challenges in coreboot is support many systems in the same codebase. As systems age and coreboot continues to develop, the condition of mainboards becomes unknown. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. 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.coreboot.org/Supported_Motherboards<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> <br /> == coreboot ports for mainboards == <br /> Identify potential mainboards to port based on the recently release cpu and chipset support. The goal would be to support publicly available platforms with a number of payloads and operating systems.<br /> <br /> '''Mentors'''<br /> <br /> * [[User:ruik|Rudolf Marek]]<br /> <br /> == Tianocore as payload ==<br /> <br /> What SeaBIOS is for PC-BIOS interfaces, Tianocore is for UEFI - in fact, it's the reference implementation that most commercial UEFIs are built on. While coreboot favors other design goals than UEFI, it's really useful to support this standard that's being pushed on the market, just like SeaBIOS really helped coreboot by providing a BIOS &quot;frontend&quot;.<br /> <br /> There's already some code, but there's still much room for improvement: A graphics driver that uses a preinitialized (by coreboot) framebuffer. A CBFS driver so Tiano can access coreboot flash storage. Based on that, a flash driver (maybe adapted from flashrom) to implement non-volatile variable storage by writing to flash.<br /> <br /> Possible tasks depend a lot on existing knowledge of the candidate. Few of the tasks are large enough to fill the entire GSoC time frame with one of them. Feel free to discuss with us on IRC what a suitable target could be for you.<br /> <br /> '''Links'''<br /> * http://www.tianocore.org/<br /> * https://github.com/pgeorgi/edk2/tree/coreboot-pkg<br /> <br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> <br /> == coreboot ACPI 4.0 and S3 power management support ==<br /> coreboot has support for ACPI tables and S3 support for some platforms, but it is very mainboard specific and mostly based on ACPI 2.0. Create a generic solution for ACPI 4.0 table generation and S3 support.<br /> <br /> '''Mentors'''<br /> * Rudolf Marek?<br /> <br /> ==coreboot port to ARM SoC's with PCIe==<br /> <br /> While the links below are still relevant, we nowadays have a coreboot port for ARM Exynos. It was contributed by Google and the chip is used in a Chromebook. This means porting to other ARM SoCs is now easier due to generic infrastructure being in place.<br /> <br /> [http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm Xilinx Zynq-7030]<br /> <br /> [http://www.altera.com/devices/fpga/cyclone-v-fpgas/hard-processor-system/cyv-soc-hps.html Altera Cyclone V ]<br /> <br /> [http://www.st.com/internet/mcu/product/251211.jsp ST spear1340]<br /> <br /> <br /> [[ARM]] SoC's with PCIe are available. 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 /> There was an ARM project started in 2011. <br /> <br /> http://blogs.coreboot.org/blog/2011/05/11/gsoc2011-project-porting-coreboot-to-arm-architecture/<br /> <br /> '''Mentors'''<br /> * Bari Ari<br /> * [[User:Rminnich|Ron Minnich]]<br /> * [[User:Jason Wang|QingPei Wang]]<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 /> <br /> '''Mentors'''<br /> * [[User:Rminnich|Ron Minnich]]<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 /> <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 /> Alternatively, figure out a way how to build them in parallel and have coreboot select the right one on runtime.<br /> <br /> '''Links'''<br /> * src/cpu/amd/ inside the coreboot source tree<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == AMD VSA ==<br /> <br /> Get the source code of AMD's VSA compiled and working with an open source toolchain. Integrate the it into the current build system.<br /> <br /> '''Links'''<br /> * [[OpenVSA]], [[AMD Geode Porting Guide]]<br /> <br /> '''Mentors'''<br /> * Marc Jones?</div>

Hailfinger http://www.coreboot.org/Project_Ideas 2013-03-30T01:24:10Z

<p>Hailfinger: /* coreboot ACPI 4.0 and S3 power management support */</p> <hr /> <div>The following are some ideas that have come up in the community. Some are more or less suitable for [[GSoC]] and prospective students' application should expand on some ideas and pair back others.<br /> <br /> == Linux Firmware Kit, BITS ==<br /> <br /> There are various test suites for firmware aspects, esp. those that interacts with the operating systems. Unfortunately, some of these projects are dead, some seem to be forked and developed semi-publically, and having all that stuff in lots of different places is a big hassle.<br /> <br /> The goal of this project is to pick up the pieces, and create a single tool (most likely a bootable CD/USB drive image) that can be booted on vendor BIOS (for the Red Hat and Canonical developers that work on these) as well as coreboot (preferably seabios and FILO to improve testability - is an issue created/fixed by coreboot or seabios?). This can then be improved in various ways.<br /> <br /> There's also intel-gpu-tools that might have some useful tests (at least for intel-boards): http://article.gmane.org/gmane.comp.video.dri.devel/63948<br /> <br /> When applying for this task, please state in your proposal what you think might be worthy extensions to the existing tests.<br /> <br /> Required knowledge for this task: Minimal coreboot and firmware experience, but you should have some idea of the boot process of a Linux system (as these test suites are mostly Linux based). GSoC probably won't provide enough time to learn all that (Linux boot process, firmware interfaces such as ACPI) and still develop the tools in some useful way.<br /> <br /> '''Links'''<br /> * https://wiki.ubuntu.com/Kernel/Reference/fwts<br /> * http://biosbits.org/ <br /> * http://linuxfirmwarekit.org/<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]]<br /> <br /> == Infrastructure for automatic code checking ==<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 /> <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/<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 /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]], [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> == Implement coreboot features for more boards ==<br /> A lot of cool coreboot features are only available for a subset of the supported mainboards:<br /> * global variables in romstage<br /> * relocatable ramstage<br /> * cbmem console<br /> * timestamps<br /> <br /> This project would analyze how to bring those features forward to more boards and work on doing so.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot test suite ==<br /> Create a test suite to gather and report coreboot mainboard and payload settings. This project may leverage libpayload, coreinfo, memtest86, BITS, and other tools like benchmarks for CPU and RAM performance. Konstantin Aladyshev reported according to the benchmark [http://www.cs.virginia.edu/stream/ STREAM], RAM access on his system with coreboot is four times slower than with the proprietary vendor BIOS. Such issues should be easily spotted with the test suite.<br /> <br /> The suite should gather result and report them at summary and detailed levels. The goal is to help coreboot developers identify problems and to test coreboot features. This project should work closely with the testing rig and test reporting projects. 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://biosbits.org/ BITS]<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]], [[User:PatrickGeorgi|Patrick Georgi]]<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 /> * [[InSystemFlasher]] is a cheap DIY hardware prototype for building an automated testing rig for modern SPI-based boards. This could be used as a starting point.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot mainboard test result reporting ==<br /> One of the biggest challenges in coreboot is support many systems in the same codebase. As systems age and coreboot continues to develop, the condition of mainboards becomes unknown. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. 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.coreboot.org/Supported_Motherboards<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> <br /> == coreboot ports for mainboards == <br /> Identify potential mainboards to port based on the recently release cpu and chipset support. The goal would be to support publicly available platforms with a number of payloads and operating systems.<br /> <br /> '''Mentors'''<br /> <br /> * [[User:ruik|Rudolf Marek]]<br /> <br /> == Tianocore as payload ==<br /> <br /> What SeaBIOS is for PC-BIOS interfaces, Tianocore is for UEFI - in fact, it's the reference implementation that most commercial UEFIs are built on. While coreboot favors other design goals than UEFI, it's really useful to support this standard that's being pushed on the market, just like SeaBIOS really helped coreboot by providing a BIOS &quot;frontend&quot;.<br /> <br /> There's already some code, but there's still much room for improvement: A graphics driver that uses a preinitialized (by coreboot) framebuffer. A CBFS driver so Tiano can access coreboot flash storage. Based on that, a flash driver (maybe adapted from flashrom) to implement non-volatile variable storage by writing to flash.<br /> <br /> Possible tasks depend a lot on existing knowledge of the candidate. Few of the tasks are large enough to fill the entire GSoC time frame with one of them. Feel free to discuss with us on IRC what a suitable target could be for you.<br /> <br /> '''Links'''<br /> * http://www.tianocore.org/<br /> * https://github.com/pgeorgi/edk2/tree/coreboot-pkg<br /> <br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> <br /> == coreboot ACPI 4.0 and S3 power management support ==<br /> coreboot has support for ACPI tables and S3 support for some platforms, but it is very mainboard specific and mostly based on ACPI 2.0. Create a generic solution for ACPI 4.0 table generation and S3 support.<br /> <br /> '''Mentors'''<br /> * Rudolf Marek?<br /> <br /> ==coreboot port to ARM SOC's with PCIe==<br /> <br /> [http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm Xilinx Zynq-7030]<br /> <br /> [http://www.altera.com/devices/fpga/cyclone-v-fpgas/hard-processor-system/cyv-soc-hps.html Altera Cyclone V ]<br /> <br /> [http://www.st.com/internet/mcu/product/251211.jsp ST spear1340]<br /> <br /> <br /> [[ARM]] SOC's with PCIe are available. 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 /> There was an ARM project started in 2011. <br /> <br /> http://blogs.coreboot.org/blog/2011/05/11/gsoc2011-project-porting-coreboot-to-arm-architecture/<br /> <br /> '''Mentors'''<br /> * Bari Ari<br /> * [[User:Rminnich|Ron Minnich]]<br /> * [[User:Jason Wang|QingPei Wang]]<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 /> <br /> '''Mentors'''<br /> * [[User:Rminnich|Ron Minnich]]<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 /> <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 /> Alternatively, figure out a way how to build them in parallel and have coreboot select the right one on runtime.<br /> <br /> '''Links'''<br /> * src/cpu/amd/ inside the coreboot source tree<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == AMD VSA ==<br /> <br /> Get the source code of AMD's VSA compiled and working with an open source toolchain. Integrate the it into the current build system.<br /> <br /> '''Links'''<br /> * [[OpenVSA]], [[AMD Geode Porting Guide]]<br /> <br /> '''Mentors'''<br /> * Marc Jones?</div>

Hailfinger http://www.coreboot.org/Project_Ideas 2013-03-30T01:23:38Z

<p>Hailfinger: /* Refactor AMD code */</p> <hr /> <div>The following are some ideas that have come up in the community. Some are more or less suitable for [[GSoC]] and prospective students' application should expand on some ideas and pair back others.<br /> <br /> == Linux Firmware Kit, BITS ==<br /> <br /> There are various test suites for firmware aspects, esp. those that interacts with the operating systems. Unfortunately, some of these projects are dead, some seem to be forked and developed semi-publically, and having all that stuff in lots of different places is a big hassle.<br /> <br /> The goal of this project is to pick up the pieces, and create a single tool (most likely a bootable CD/USB drive image) that can be booted on vendor BIOS (for the Red Hat and Canonical developers that work on these) as well as coreboot (preferably seabios and FILO to improve testability - is an issue created/fixed by coreboot or seabios?). This can then be improved in various ways.<br /> <br /> There's also intel-gpu-tools that might have some useful tests (at least for intel-boards): http://article.gmane.org/gmane.comp.video.dri.devel/63948<br /> <br /> When applying for this task, please state in your proposal what you think might be worthy extensions to the existing tests.<br /> <br /> Required knowledge for this task: Minimal coreboot and firmware experience, but you should have some idea of the boot process of a Linux system (as these test suites are mostly Linux based). GSoC probably won't provide enough time to learn all that (Linux boot process, firmware interfaces such as ACPI) and still develop the tools in some useful way.<br /> <br /> '''Links'''<br /> * https://wiki.ubuntu.com/Kernel/Reference/fwts<br /> * http://biosbits.org/ <br /> * http://linuxfirmwarekit.org/<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]]<br /> <br /> == Infrastructure for automatic code checking ==<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 /> <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/<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 /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]], [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> == Implement coreboot features for more boards ==<br /> A lot of cool coreboot features are only available for a subset of the supported mainboards:<br /> * global variables in romstage<br /> * relocatable ramstage<br /> * cbmem console<br /> * timestamps<br /> <br /> This project would analyze how to bring those features forward to more boards and work on doing so.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot test suite ==<br /> Create a test suite to gather and report coreboot mainboard and payload settings. This project may leverage libpayload, coreinfo, memtest86, BITS, and other tools like benchmarks for CPU and RAM performance. Konstantin Aladyshev reported according to the benchmark [http://www.cs.virginia.edu/stream/ STREAM], RAM access on his system with coreboot is four times slower than with the proprietary vendor BIOS. Such issues should be easily spotted with the test suite.<br /> <br /> The suite should gather result and report them at summary and detailed levels. The goal is to help coreboot developers identify problems and to test coreboot features. This project should work closely with the testing rig and test reporting projects. 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://biosbits.org/ BITS]<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]], [[User:PatrickGeorgi|Patrick Georgi]]<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 /> * [[InSystemFlasher]] is a cheap DIY hardware prototype for building an automated testing rig for modern SPI-based boards. This could be used as a starting point.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot mainboard test result reporting ==<br /> One of the biggest challenges in coreboot is support many systems in the same codebase. As systems age and coreboot continues to develop, the condition of mainboards becomes unknown. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. 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.coreboot.org/Supported_Motherboards<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> <br /> == coreboot ports for mainboards == <br /> Identify potential mainboards to port based on the recently release cpu and chipset support. The goal would be to support publicly available platforms with a number of payloads and operating systems.<br /> <br /> '''Mentors'''<br /> <br /> * [[User:ruik|Rudolf Marek]]<br /> <br /> == Tianocore as payload ==<br /> <br /> What SeaBIOS is for PC-BIOS interfaces, Tianocore is for UEFI - in fact, it's the reference implementation that most commercial UEFIs are built on. While coreboot favors other design goals than UEFI, it's really useful to support this standard that's being pushed on the market, just like SeaBIOS really helped coreboot by providing a BIOS &quot;frontend&quot;.<br /> <br /> There's already some code, but there's still much room for improvement: A graphics driver that uses a preinitialized (by coreboot) framebuffer. A CBFS driver so Tiano can access coreboot flash storage. Based on that, a flash driver (maybe adapted from flashrom) to implement non-volatile variable storage by writing to flash.<br /> <br /> Possible tasks depend a lot on existing knowledge of the candidate. Few of the tasks are large enough to fill the entire GSoC time frame with one of them. Feel free to discuss with us on IRC what a suitable target could be for you.<br /> <br /> '''Links'''<br /> * http://www.tianocore.org/<br /> * https://github.com/pgeorgi/edk2/tree/coreboot-pkg<br /> <br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> <br /> == coreboot ACPI 4.0 and S3 power management support ==<br /> coreboot has support for ACPI tables and S3 support for some platforms, but it is very mainboard specific and moslty based on ACPI 2.0. Create a generic solution for ACPI 4.0 table generation and S3 support.<br /> <br /> '''Mentors'''<br /> *<br /> <br /> <br /> ==coreboot port to ARM SOC's with PCIe==<br /> <br /> [http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm Xilinx Zynq-7030]<br /> <br /> [http://www.altera.com/devices/fpga/cyclone-v-fpgas/hard-processor-system/cyv-soc-hps.html Altera Cyclone V ]<br /> <br /> [http://www.st.com/internet/mcu/product/251211.jsp ST spear1340]<br /> <br /> <br /> [[ARM]] SOC's with PCIe are available. 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 /> There was an ARM project started in 2011. <br /> <br /> http://blogs.coreboot.org/blog/2011/05/11/gsoc2011-project-porting-coreboot-to-arm-architecture/<br /> <br /> '''Mentors'''<br /> * Bari Ari<br /> * [[User:Rminnich|Ron Minnich]]<br /> * [[User:Jason Wang|QingPei Wang]]<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 /> <br /> '''Mentors'''<br /> * [[User:Rminnich|Ron Minnich]]<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 /> <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 /> Alternatively, figure out a way how to build them in parallel and have coreboot select the right one on runtime.<br /> <br /> '''Links'''<br /> * src/cpu/amd/ inside the coreboot source tree<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == AMD VSA ==<br /> <br /> Get the source code of AMD's VSA compiled and working with an open source toolchain. Integrate the it into the current build system.<br /> <br /> '''Links'''<br /> * [[OpenVSA]], [[AMD Geode Porting Guide]]<br /> <br /> '''Mentors'''<br /> * Marc Jones?</div>

Hailfinger http://www.coreboot.org/Project_Ideas 2013-03-30T01:19:12Z

<p>Hailfinger: /* AMD VSA */</p> <hr /> <div>The following are some ideas that have come up in the community. Some are more or less suitable for [[GSoC]] and prospective students' application should expand on some ideas and pair back others.<br /> <br /> == Linux Firmware Kit, BITS ==<br /> <br /> There are various test suites for firmware aspects, esp. those that interacts with the operating systems. Unfortunately, some of these projects are dead, some seem to be forked and developed semi-publically, and having all that stuff in lots of different places is a big hassle.<br /> <br /> The goal of this project is to pick up the pieces, and create a single tool (most likely a bootable CD/USB drive image) that can be booted on vendor BIOS (for the Red Hat and Canonical developers that work on these) as well as coreboot (preferably seabios and FILO to improve testability - is an issue created/fixed by coreboot or seabios?). This can then be improved in various ways.<br /> <br /> There's also intel-gpu-tools that might have some useful tests (at least for intel-boards): http://article.gmane.org/gmane.comp.video.dri.devel/63948<br /> <br /> When applying for this task, please state in your proposal what you think might be worthy extensions to the existing tests.<br /> <br /> Required knowledge for this task: Minimal coreboot and firmware experience, but you should have some idea of the boot process of a Linux system (as these test suites are mostly Linux based). GSoC probably won't provide enough time to learn all that (Linux boot process, firmware interfaces such as ACPI) and still develop the tools in some useful way.<br /> <br /> '''Links'''<br /> * https://wiki.ubuntu.com/Kernel/Reference/fwts<br /> * http://biosbits.org/ <br /> * http://linuxfirmwarekit.org/<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]]<br /> <br /> == Infrastructure for automatic code checking ==<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 /> <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/<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 /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]], [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> == Implement coreboot features for more boards ==<br /> A lot of cool coreboot features are only available for a subset of the supported mainboards:<br /> * global variables in romstage<br /> * relocatable ramstage<br /> * cbmem console<br /> * timestamps<br /> <br /> This project would analyze how to bring those features forward to more boards and work on doing so.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot test suite ==<br /> Create a test suite to gather and report coreboot mainboard and payload settings. This project may leverage libpayload, coreinfo, memtest86, BITS, and other tools like benchmarks for CPU and RAM performance. Konstantin Aladyshev reported according to the benchmark [http://www.cs.virginia.edu/stream/ STREAM], RAM access on his system with coreboot is four times slower than with the proprietary vendor BIOS. Such issues should be easily spotted with the test suite.<br /> <br /> The suite should gather result and report them at summary and detailed levels. The goal is to help coreboot developers identify problems and to test coreboot features. This project should work closely with the testing rig and test reporting projects. 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://biosbits.org/ BITS]<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]], [[User:PatrickGeorgi|Patrick Georgi]]<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 /> * [[InSystemFlasher]] is a cheap DIY hardware prototype for building an automated testing rig for modern SPI-based boards. This could be used as a starting point.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot mainboard test result reporting ==<br /> One of the biggest challenges in coreboot is support many systems in the same codebase. As systems age and coreboot continues to develop, the condition of mainboards becomes unknown. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. 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.coreboot.org/Supported_Motherboards<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> <br /> == coreboot ports for mainboards == <br /> Identify potential mainboards to port based on the recently release cpu and chipset support. The goal would be to support publicly available platforms with a number of payloads and operating systems.<br /> <br /> '''Mentors'''<br /> <br /> * [[User:ruik|Rudolf Marek]]<br /> <br /> == Tianocore as payload ==<br /> <br /> What SeaBIOS is for PC-BIOS interfaces, Tianocore is for UEFI - in fact, it's the reference implementation that most commercial UEFIs are built on. While coreboot favors other design goals than UEFI, it's really useful to support this standard that's being pushed on the market, just like SeaBIOS really helped coreboot by providing a BIOS &quot;frontend&quot;.<br /> <br /> There's already some code, but there's still much room for improvement: A graphics driver that uses a preinitialized (by coreboot) framebuffer. A CBFS driver so Tiano can access coreboot flash storage. Based on that, a flash driver (maybe adapted from flashrom) to implement non-volatile variable storage by writing to flash.<br /> <br /> Possible tasks depend a lot on existing knowledge of the candidate. Few of the tasks are large enough to fill the entire GSoC time frame with one of them. Feel free to discuss with us on IRC what a suitable target could be for you.<br /> <br /> '''Links'''<br /> * http://www.tianocore.org/<br /> * https://github.com/pgeorgi/edk2/tree/coreboot-pkg<br /> <br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> <br /> == coreboot ACPI 4.0 and S3 power management support ==<br /> coreboot has support for ACPI tables and S3 support for some platforms, but it is very mainboard specific and moslty based on ACPI 2.0. Create a generic solution for ACPI 4.0 table generation and S3 support.<br /> <br /> '''Mentors'''<br /> *<br /> <br /> <br /> ==coreboot port to ARM SOC's with PCIe==<br /> <br /> [http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm Xilinx Zynq-7030]<br /> <br /> [http://www.altera.com/devices/fpga/cyclone-v-fpgas/hard-processor-system/cyv-soc-hps.html Altera Cyclone V ]<br /> <br /> [http://www.st.com/internet/mcu/product/251211.jsp ST spear1340]<br /> <br /> <br /> [[ARM]] SOC's with PCIe are available. 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 /> There was an ARM project started in 2011. <br /> <br /> http://blogs.coreboot.org/blog/2011/05/11/gsoc2011-project-porting-coreboot-to-arm-architecture/<br /> <br /> '''Mentors'''<br /> * Bari Ari<br /> * [[User:Rminnich|Ron Minnich]]<br /> * [[User:Jason Wang|QingPei Wang]]<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 /> <br /> '''Mentors'''<br /> * [[User:Rminnich|Ron Minnich]]<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 /> <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 /> Alternatively, figure out a way how to build them in parallel and have coreboot select the right one on runtime.<br /> <br /> '''Links'''<br /> * ?<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> <br /> == AMD VSA ==<br /> <br /> Get the source code of AMD's VSA compiled and working with an open source toolchain. Integrate the it into the current build system.<br /> <br /> '''Links'''<br /> * [[OpenVSA]], [[AMD Geode Porting Guide]]<br /> <br /> '''Mentors'''<br /> * Marc Jones?</div>

Hailfinger http://www.coreboot.org/Project_Ideas 2013-03-30T00:50:43Z

<p>Hailfinger: Undo revision 11699 by me, it was a bad idea</p> <hr /> <div>The following are some ideas that have come up in the community. Some are more or less suitable for [[GSoC]] and prospective students' application should expand on some ideas and pair back others.<br /> <br /> == Linux Firmware Kit, BITS ==<br /> <br /> There are various test suites for firmware aspects, esp. those that interacts with the operating systems. Unfortunately, some of these projects are dead, some seem to be forked and developed semi-publically, and having all that stuff in lots of different places is a big hassle.<br /> <br /> The goal of this project is to pick up the pieces, and create a single tool (most likely a bootable CD/USB drive image) that can be booted on vendor BIOS (for the Red Hat and Canonical developers that work on these) as well as coreboot (preferably seabios and FILO to improve testability - is an issue created/fixed by coreboot or seabios?). This can then be improved in various ways.<br /> <br /> There's also intel-gpu-tools that might have some useful tests (at least for intel-boards): http://article.gmane.org/gmane.comp.video.dri.devel/63948<br /> <br /> When applying for this task, please state in your proposal what you think might be worthy extensions to the existing tests.<br /> <br /> Required knowledge for this task: Minimal coreboot and firmware experience, but you should have some idea of the boot process of a Linux system (as these test suites are mostly Linux based). GSoC probably won't provide enough time to learn all that (Linux boot process, firmware interfaces such as ACPI) and still develop the tools in some useful way.<br /> <br /> '''Links'''<br /> * https://wiki.ubuntu.com/Kernel/Reference/fwts<br /> * http://biosbits.org/ <br /> * http://linuxfirmwarekit.org/<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]]<br /> <br /> == Infrastructure for automatic code checking ==<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 /> <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/<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 /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]], [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> == Implement coreboot features for more boards ==<br /> A lot of cool coreboot features are only available for a subset of the supported mainboards:<br /> * global variables in romstage<br /> * relocatable ramstage<br /> * cbmem console<br /> * timestamps<br /> <br /> This project would analyze how to bring those features forward to more boards and work on doing so.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot test suite ==<br /> Create a test suite to gather and report coreboot mainboard and payload settings. This project may leverage libpayload, coreinfo, memtest86, BITS, and other tools like benchmarks for CPU and RAM performance. Konstantin Aladyshev reported according to the benchmark [http://www.cs.virginia.edu/stream/ STREAM], RAM access on his system with coreboot is four times slower than with the proprietary vendor BIOS. Such issues should be easily spotted with the test suite.<br /> <br /> The suite should gather result and report them at summary and detailed levels. The goal is to help coreboot developers identify problems and to test coreboot features. This project should work closely with the testing rig and test reporting projects. 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://biosbits.org/ BITS]<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]], [[User:PatrickGeorgi|Patrick Georgi]]<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 /> * [[InSystemFlasher]] is a cheap DIY hardware prototype for building an automated testing rig for modern SPI-based boards. This could be used as a starting point.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot mainboard test result reporting ==<br /> One of the biggest challenges in coreboot is support many systems in the same codebase. As systems age and coreboot continues to develop, the condition of mainboards becomes unknown. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. 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.coreboot.org/Supported_Motherboards<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> <br /> == coreboot ports for mainboards == <br /> Identify potential mainboards to port based on the recently release cpu and chipset support. The goal would be to support publicly available platforms with a number of payloads and operating systems.<br /> <br /> '''Mentors'''<br /> <br /> * [[User:ruik|Rudolf Marek]]<br /> <br /> == Tianocore as payload ==<br /> <br /> What SeaBIOS is for PC-BIOS interfaces, Tianocore is for UEFI - in fact, it's the reference implementation that most commercial UEFIs are built on. While coreboot favors other design goals than UEFI, it's really useful to support this standard that's being pushed on the market, just like SeaBIOS really helped coreboot by providing a BIOS &quot;frontend&quot;.<br /> <br /> There's already some code, but there's still much room for improvement: A graphics driver that uses a preinitialized (by coreboot) framebuffer. A CBFS driver so Tiano can access coreboot flash storage. Based on that, a flash driver (maybe adapted from flashrom) to implement non-volatile variable storage by writing to flash.<br /> <br /> Possible tasks depend a lot on existing knowledge of the candidate. Few of the tasks are large enough to fill the entire GSoC time frame with one of them. Feel free to discuss with us on IRC what a suitable target could be for you.<br /> <br /> '''Links'''<br /> * http://www.tianocore.org/<br /> * https://github.com/pgeorgi/edk2/tree/coreboot-pkg<br /> <br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> <br /> == coreboot ACPI 4.0 and S3 power management support ==<br /> coreboot has support for ACPI tables and S3 support for some platforms, but it is very mainboard specific and moslty based on ACPI 2.0. Create a generic solution for ACPI 4.0 table generation and S3 support.<br /> <br /> '''Mentors'''<br /> *<br /> <br /> <br /> ==coreboot port to ARM SOC's with PCIe==<br /> <br /> [http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm Xilinx Zynq-7030]<br /> <br /> [http://www.altera.com/devices/fpga/cyclone-v-fpgas/hard-processor-system/cyv-soc-hps.html Altera Cyclone V ]<br /> <br /> [http://www.st.com/internet/mcu/product/251211.jsp ST spear1340]<br /> <br /> <br /> [[ARM]] SOC's with PCIe are available. 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 /> There was an ARM project started in 2011. <br /> <br /> http://blogs.coreboot.org/blog/2011/05/11/gsoc2011-project-porting-coreboot-to-arm-architecture/<br /> <br /> '''Mentors'''<br /> * Bari Ari<br /> * [[User:Rminnich|Ron Minnich]]<br /> * [[User:Jason Wang|QingPei Wang]]<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 /> <br /> '''Mentors'''<br /> * [[User:Rminnich|Ron Minnich]]<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 /> <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 /> Alternatively, figure out a way how to build them in parallel and have coreboot select the right one on runtime.<br /> <br /> '''Links'''<br /> * ?<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> <br /> == AMD VSA ==<br /> <br /> Get the source code of AMD's VSA compiled and working with an open source toolchain. Integrate the it into the current build system.<br /> <br /> '''Links'''<br /> * ?<br /> <br /> '''Mentors'''<br /> * ?</div>

Hailfinger http://www.coreboot.org/Project_Ideas 2013-03-30T00:34:24Z

<p>Hailfinger: Mention that some links are missing.</p> <hr /> <div>The following are some ideas that have come up in the community. Some are more or less suitable for [[GSoC]] and prospective students' application should expand on some ideas and pair back others.<br /> <br /> '''''NOTE: Some links/mentors are missing. Those will be filled in before the org application review starts (April 1st, see official GSoC timeline).'''''<br /> <br /> == Linux Firmware Kit, BITS ==<br /> <br /> There are various test suites for firmware aspects, esp. those that interacts with the operating systems. Unfortunately, some of these projects are dead, some seem to be forked and developed semi-publically, and having all that stuff in lots of different places is a big hassle.<br /> <br /> The goal of this project is to pick up the pieces, and create a single tool (most likely a bootable CD/USB drive image) that can be booted on vendor BIOS (for the Red Hat and Canonical developers that work on these) as well as coreboot (preferably seabios and FILO to improve testability - is an issue created/fixed by coreboot or seabios?). This can then be improved in various ways.<br /> <br /> There's also intel-gpu-tools that might have some useful tests (at least for intel-boards): http://article.gmane.org/gmane.comp.video.dri.devel/63948<br /> <br /> When applying for this task, please state in your proposal what you think might be worthy extensions to the existing tests.<br /> <br /> Required knowledge for this task: Minimal coreboot and firmware experience, but you should have some idea of the boot process of a Linux system (as these test suites are mostly Linux based). GSoC probably won't provide enough time to learn all that (Linux boot process, firmware interfaces such as ACPI) and still develop the tools in some useful way.<br /> <br /> '''Links'''<br /> * https://wiki.ubuntu.com/Kernel/Reference/fwts<br /> * http://biosbits.org/ <br /> * http://linuxfirmwarekit.org/<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]]<br /> <br /> == Infrastructure for automatic code checking ==<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 /> <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/<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 /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]], [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> == Implement coreboot features for more boards ==<br /> A lot of cool coreboot features are only available for a subset of the supported mainboards:<br /> * global variables in romstage<br /> * relocatable ramstage<br /> * cbmem console<br /> * timestamps<br /> <br /> This project would analyze how to bring those features forward to more boards and work on doing so.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot test suite ==<br /> Create a test suite to gather and report coreboot mainboard and payload settings. This project may leverage libpayload, coreinfo, memtest86, BITS, and other tools like benchmarks for CPU and RAM performance. Konstantin Aladyshev reported according to the benchmark [http://www.cs.virginia.edu/stream/ STREAM], RAM access on his system with coreboot is four times slower than with the proprietary vendor BIOS. Such issues should be easily spotted with the test suite.<br /> <br /> The suite should gather result and report them at summary and detailed levels. The goal is to help coreboot developers identify problems and to test coreboot features. This project should work closely with the testing rig and test reporting projects. 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://biosbits.org/ BITS]<br /> * [[Supported Motherboards]]<br /> <br /> '''Mentors'''<br /> * [[User:MJones|Marc Jones]], [[User:PatrickGeorgi|Patrick Georgi]]<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 /> * [[InSystemFlasher]] is a cheap DIY hardware prototype for building an automated testing rig for modern SPI-based boards. This could be used as a starting point.<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == coreboot mainboard test result reporting ==<br /> One of the biggest challenges in coreboot is support many systems in the same codebase. As systems age and coreboot continues to develop, the condition of mainboards becomes unknown. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. 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.coreboot.org/Supported_Motherboards<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> <br /> == coreboot ports for mainboards == <br /> Identify potential mainboards to port based on the recently release cpu and chipset support. The goal would be to support publicly available platforms with a number of payloads and operating systems.<br /> <br /> '''Mentors'''<br /> <br /> * [[User:ruik|Rudolf Marek]]<br /> <br /> == Tianocore as payload ==<br /> <br /> What SeaBIOS is for PC-BIOS interfaces, Tianocore is for UEFI - in fact, it's the reference implementation that most commercial UEFIs are built on. While coreboot favors other design goals than UEFI, it's really useful to support this standard that's being pushed on the market, just like SeaBIOS really helped coreboot by providing a BIOS &quot;frontend&quot;.<br /> <br /> There's already some code, but there's still much room for improvement: A graphics driver that uses a preinitialized (by coreboot) framebuffer. A CBFS driver so Tiano can access coreboot flash storage. Based on that, a flash driver (maybe adapted from flashrom) to implement non-volatile variable storage by writing to flash.<br /> <br /> Possible tasks depend a lot on existing knowledge of the candidate. Few of the tasks are large enough to fill the entire GSoC time frame with one of them. Feel free to discuss with us on IRC what a suitable target could be for you.<br /> <br /> '''Links'''<br /> * http://www.tianocore.org/<br /> * https://github.com/pgeorgi/edk2/tree/coreboot-pkg<br /> <br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:PatrickGeorgi|Patrick Georgi]]<br /> <br /> <br /> == coreboot ACPI 4.0 and S3 power management support ==<br /> coreboot has support for ACPI tables and S3 support for some platforms, but it is very mainboard specific and moslty based on ACPI 2.0. Create a generic solution for ACPI 4.0 table generation and S3 support.<br /> <br /> '''Mentors'''<br /> *<br /> <br /> <br /> ==coreboot port to ARM SOC's with PCIe==<br /> <br /> [http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm Xilinx Zynq-7030]<br /> <br /> [http://www.altera.com/devices/fpga/cyclone-v-fpgas/hard-processor-system/cyv-soc-hps.html Altera Cyclone V ]<br /> <br /> [http://www.st.com/internet/mcu/product/251211.jsp ST spear1340]<br /> <br /> <br /> [[ARM]] SOC's with PCIe are available. 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 /> There was an ARM project started in 2011. <br /> <br /> http://blogs.coreboot.org/blog/2011/05/11/gsoc2011-project-porting-coreboot-to-arm-architecture/<br /> <br /> '''Mentors'''<br /> * Bari Ari<br /> * [[User:Rminnich|Ron Minnich]]<br /> * [[User:Jason Wang|QingPei Wang]]<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 /> <br /> '''Mentors'''<br /> * [[User:Rminnich|Ron Minnich]]<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 /> <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 /> Alternatively, figure out a way how to build them in parallel and have coreboot select the right one on runtime.<br /> <br /> '''Links'''<br /> * ?<br /> <br /> '''Mentors'''<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> <br /> == AMD VSA ==<br /> <br /> Get the source code of AMD's VSA compiled and working with an open source toolchain. Integrate the it into the current build system.<br /> <br /> '''Links'''<br /> * ?<br /> <br /> '''Mentors'''<br /> * ?</div>

Hailfinger http://www.coreboot.org/GSoC 2013-03-28T23:24:49Z

<p>Hailfinger: /* coreboot Mentors */ add myself</p> <hr /> <div>Welcome to coreboot [http://www.google-melange.com/gsoc/homepage/google/gsoc2013 Google Summer of Code, 2013]. <br /> <br /> coreboot has many [[Project Ideas]] for various firmware ability levels. The coreboot project also hosts [http://flashrom.org/GSoC flashrom] and [http://serialice.com/GSoC SerialICE] projects.<br /> <br /> __FORCETOC__<br /> <br /> == Important dates ==<br /> <br /> * March 29: Mentoring organization application deadline.<br /> * April 1–5: Google program administrators review organization applications.<br /> * April 8: List of accepted mentoring organizations published on the Google Summer of Code 2013 site.<br /> * April 9–21: Would-be student participants discuss application ideas with mentoring organizations.<br /> * April 22: Student application period opens.<br /> * May 3: Student application deadline.<br /> <br /> == coreboot contact ==<br /> <br /> If you are interested in becoming a GSoC student, please contact the coreboot [[Mailinglist|mailing list]] or visit our [[IRC]] channel &lt;code&gt;#coreboot&lt;/code&gt; on [https://webchat.freenode.net irc.freenode.net].<br /> <br /> If you need to contact someone directly, [mailto:marcj303@gmail.com Marc Jones] is the GSoC admin for coreboot.<br /> <br /> = Why work on coreboot for GSoC 2013? =<br /> <br /> * coreboot offers you the opportunity to work with modern technology “right on the iron”. coreboot supports current silicon from AMD and Intel. <br /> * coreboot has a worldwide developer and user base.<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. coreboot has some extremely talented and helpful experts in firmware involved in the project. They are ready to assist and mentor students participating in GSoC 2013.<br /> * One of the last areas where open source software is not common is firmware. Running proprietary firmware can have severe effects on user's freedom and security. coreboot changes that by providing a common framework for initial hardware initialization and you can help us succeed.<br /> <br /> = GSoC Student requirements =<br /> <br /> What will be required of you to be a coreboot GSoC student?<br /> <br /> Google Summer of Code is a full (day)time job. This means we expect roughly 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 /> <br /> # Prior to project acceptance, you have demonstrated that you can work with the coreboot codebase. <br /> #* By the time you have submitted your application, you should have downloaded, built and booted coreboot in QEMU, SimNow, or on real hardware. Please, email your serial output results to the mailing list. <br /> #* Send a patch to Gerrit for review. Check [[Easy projects]] or ask for simple tasks on the mailing list or on IRC.<br /> # To pass and to be paid by Google requires that you meet certain milestones. <br /> #* First, you must be in good standing with the community before the official start of the program. We suggest you post some design emails to the mailing list, and get feedback on them, both before applying, and during the &quot;community bonding period&quot; between acceptance and official start.<br /> #* You must have made progress and committed significant code before the mid-term point and by the final.<br /> # We require that accepted students to maintain a blog, where you will write about your project weekly. This is a way to measure progress and for the community at large to be able to help you. SoC is not a private contract between your mentor and you. http://blogs.coreboot.org/<br /> # Student must be active on IRC and the mailing list. <br /> <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 /> = Projects =<br /> There are many development tasks available in coreboot. Please visit the following pages for some ideas or come up with your own idea. <br /> * [[Project Ideas|coreboot project ideas]]<br /> * [http://www.flashrom.org/GSoC flashrom project ideas]<br /> * [http://serialice.com/GSoC SerialICE project ideas]<br /> <br /> We keep a list of [[previous GSoC Projects]] which might be of interest to you to see what others have accomplished.<br /> Similarly the [http://blogs.coreboot.org/blog/category/gsoc/ blog posts related to previous GSoC projects] might give some insights to what it is like to be a coreboot GSoC student.<br /> <br /> == Your own Project Ideas ==<br /> <br /> We have come up with some ideas for cool Summer of Code projects. 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. The opposite: Maybe you have a great idea that we just didn't think of yet. Please let us know!<br /> <br /> = coreboot Mentors =<br /> <br /> The following coreboot developers are interested in being GSoC mentors. Please stop by IRC and say hi to them and ask them questions about coreboot.<br /> <br /> Note to mentors: Each accepted project will have a lead mentor and a backup mentor. We will match mentors and students based on the project, experience level, and geographic location (native language, culture and time zone). <br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Name !! Role !! Comms<br /> |-<br /> | Marc Jones || coreboot: co-organizer and mentor || IRC: marcj<br /> |-<br /> | Patrick Georgi || coreboot: possible co-organizer and mentor || IRC: patrickg, pgeorgi<br /> |-<br /> | Stefan Reinauer || coreboot/serialice: mentor || IRC: stepan<br /> |-<br /> | David Hendricks || flashrom: possible mentor || IRC: dhendrix, [http://www.flashrom.org/mailman/listinfo/flashrom flashrom ML]<br /> |-<br /> | Joshua Roys || flashrom: possible mentor || IRC: roysjosh<br /> |-<br /> | Rudolf Marek || coreboot: possible mentor || IRC: ruik<br /> |-<br /> | QingPei Wang || coreboot: possible mentor || IRC:QingPei<br /> |-<br /> | Martin Roth || coreboot: possible mentor || IRC: martinr<br /> |-<br /> | Carl-Daniel Hailfinger || flashrom: possible mentor || IRC: carldani<br /> |-<br /> |}<br /> <br /> = coreboot Summer of Code Application =<br /> <br /> Please complete the standard Google SoC application and project proposal. Prospective coreboot GSoC student should provide the following information as part of their application. If you are applying for a flashrom or SerialICE project use common sense when using the template below, this is part of the test. ;)<br /> <br /> :Name:<br /> :Email:<br /> :IM/IRC/Skype/other contact:<br /> <br /> :Country/Timezone:<br /> :School:<br /> :Degree Program:<br /> :Expected graduation date:<br /> <br /> :Most students have some time off planned during GSoC. Do you have any vacations? When and how long?<br /> <br /> coreboot welcomes students from all backgrounds and levels of experience. To be seriously considered for coreboot GSoC, we recommend joining the mailing list and IRC channel. Introduce yourself and mention that you are a prospective GSoC student. Ask questions and discuss the project that you are considering. Community involvement is a key component of coreboot development. By the time you have submitted your application, you should have downloaded, built a and booted coreboot in QEMU, SimNow, or on real hardware. Please, email your serial output results to the mailing list. <br /> <br /> The following information will help coreboot match students with mentors and projects.<br /> <br /> Please comment on your software and firmware experience.<br /> <br /> Have you participated in the coreboot community before?<br /> <br /> Have you contributed to an open source project? Which one? What was your experience?<br /> <br /> Have you built and run coreboot? Did you have problems?<br /> <br /> Did you find and fix a coreboot bug? Did you send a patch to Gerrit? Please provide a link to the Gerrit page. <br /> <br /> Please provide an overview of your project and a break down of your project in small specific goals. Think about the potential timeline. Explain what risks or potential problems your project might experience. What would you expect as a minimum level of success? Do you have a stretch goal? <br /> <br /> == Advice on how to apply ==<br /> <br /> Your application should include a complete project proposal. You should document that you have the knowledge and the ability to complete your proposed project. This may require a little research and understanding of coreboot prior to sending your application. Mentors are your best resource in flushing out your project ideas and helping with a project timeline. We recommend that you get feedback and recommendations on your proposal before the application deadline.<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].</div>

Hailfinger http://www.coreboot.org/Fun_Stuff 2012-06-11T22:23:01Z

<p>Hailfinger: /* Train ticket machine */ typo in url</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 Swierk<br /> <br /> == Train ticket machine ==<br /> <br /> Somewhere in Berlin<br /> <br /> [http://www.tagesspiegel.de/images/foto_1/5914068/2.jpg?format=format36]</div>

Hailfinger http://www.coreboot.org/Fun_Stuff 2012-06-11T22:21:57Z

<p>Hailfinger: </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 Swierk<br /> <br /> == Train ticket machine ==<br /> <br /> Somewhere in Berlin<br /> <br /> [http://www.tagesspiegel.de/images/foto_1/5914068/2.jpg?format=format3]</div>

Hailfinger http://www.coreboot.org/GSoC 2012-03-04T18:15:06Z

<p>Hailfinger: /* SPI bitbanging hardware support */ update status</p> <hr /> <div>= Google Summer of Code 2011 = <br /> <br /> http://1.bp.blogspot.com/-61a6mHfP1bU/TWbmtb5TAAI/AAAAAAAAABo/w56YXLjXDGY/s400/GSOC_2011_300x200px.png<br /> <br /> Welcome to the [http://www.google-melange.com/ Google Summer of Code(tm)] page of the [[Welcome to coreboot|coreboot project]]. <br /> <br /> Apply for a coreboot GSoC project at: http://www.google-melange.com/gsoc/org/show/google/gsoc2011/coreboot<br /> <br /> This year, coreboot also tries to host some flashrom projects.<br /> <br /> <br /> == Deadlines ==<br /> <br /> Make sure you check the https://socghop.appspot.com/document/show/gsoc_program/google/gsoc2011/timeline<br /> <br /> <br /> = Why work for coreboot =<br /> <br /> Why would you like to work for coreboot?<br /> <br /> * coreboot offers you the opportunity to work with modern technology &quot;right on the iron&quot;.<br /> * Your application will be available to users worldwide and promoted along with all other coreboot projects.<br /> * We are a very passionate team - so you will interact directly with the project initiators and project leaders. <br /> * We have a large, helpful community. Over 100 experts in hardware and firmware lurk on our mailing list, many of them waiting to help you.<br /> <br /> <br /> = Summer of Code Application =<br /> <br /> Please complete the standard Google SoC 2011 application. Prospective corebot GSoC student should provide the following information as part of their application. <br /> <br /> :Name:<br /> :Email:<br /> :IM/IRC/Skype/other contact:<br /> <br /> :Country/Timezone:<br /> :School:<br /> :Degree Program:<br /> :Year:<br /> <br /> :Most students have some time off planned during GSoC. Do you have any vacations? When and how long?<br /> <br /> <br /> :coreboot welcomes students from all backgrounds and levels of experience. To be seriously consider for coreboot GSoC, we recommend joining the mailing list and IRC channel. Introduce yourself and mention that you are a prospective GSoC student. Ask questions and discuss the project that you are considering. Community involvement is a key component of coreboot development. By the time you have submitted your application, you should have downloaded, built a and booted coreboot in QEMU, SimNow, or on real hardware. Please, email your serial output results to the mailing list. <br /> <br /> :The following information will help coreboot match students with mentors and projects.<br /> <br /> :Please comment on your software and firmware experience.<br /> <br /> :Have you participated in the coreboot community before?<br /> <br /> :Have you contributed to an open source project? Which one? What was your experience?<br /> <br /> :Have you built and run coreboot? Did you have problems?<br /> <br /> :Bonus, Did you find and fix a coreboot bug? Did you send a patch to the email list?<br /> <br /> <br /> :Please provide an overview of your project and a break down your project in small specific goals. Explain what risks or potential problems your project might experience. What would you expect as a minimum level of success? Do you have a stretch goal? <br /> <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 /> <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 /> <br /> == Some Caveats ==<br /> <br /> * Google Summer-of-Code projects are a full (day-) time job. This means we expect roughly 30-40 hours per week on your project, during the three months of coding. Obviously we have flexibility, but if your schedule (exams, courses) does not give you this amount of spare time, then maybe you should not apply.<br /> * Getting paid by Google requires that you meet certain milestones. First, you must be in good standing with the community before the official start of the program. We suggest you post some design emails to the mailing list, and get feedback on them, both before applying, and during the &quot;community bonding period&quot; between acceptance and official start. Also, you must have made progress and committed significant code before the mid-term point.<br /> * We require 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. http://blogs.coreboot.org/<br /> <br /> Note that &quot;regular basis&quot; in the last item does _not_ mean &quot;3 days before evaluation deadlines&quot;. You should be &quot;around&quot; all the time (reporting your feedback, sending in partial successes).<br /> We don't expect our students to be experts in our problem domain, but we don't want you to fail because some basic misunderstanding was in your way of completing the task.<br /> <br /> <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 28, 2011''' and '''April 8, 2011'''! If you want to apply, please get in contact with us right away, not just when you send your application!<br /> <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 /> <br /> = Contact =<br /> <br /> If you are interested in becoming a GSoC student, please contact [mailto:marcj303@gmail.com Marc Jones].<br /> <br /> There is also an IRC channel on irc.freenode.net: #coreboot<br /> <br /> <br /> = coreboot GSoC Mentor =<br /> Please add you name to this list and follow the coreboot mentor link to [http://www.google-melange.com/gsoc/profile/mentor/google/gsoc2011?org=coreboot apply to be a coreboot mentor]<br /> <br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> * [[User:Jason Wang|QingPei Wang]]<br /> <br /> http://www.google-melange.com/gsoc/profile/mentor/google/gsoc2011?org=coreboot<br /> <br /> <br /> = Possible ideas =<br /> The following are some ideas that have come up in the community. Some are more or less suitable for GSoC and prospective students' application should expand on some ideas and pair back others.<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 UIs for flashrom ===<br /> * flashrom TUI (text mode user interface) (for command line and flashrom-as-payload)<br /> * flashrom GUI (graphics mode user interface) (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 /> * 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 /> * flashrom support for Nvidia SPI chipset hardware (DONE)<br /> * flashrom support for RayeR SPIPGM hardware (DONE)<br /> * flashrom support for [[Paraflasher]] hardware<br /> * flashrom support for Willem hardware (unfinished patch exists)<br /> * flashrom support for some-yet-uninvented cheap universal LPC/FWH/SPI flasher hardware (e.g. Raspberry Pi, patch exists)<br /> * flashrom support for bitbanging LPC/FWH (code exists, Uwe Hermann needs to post it somewhere)<br /> * flashrom support for bitbanging Parallel (total coding time estimated ~2-3 days, not sufficient for GSOC)<br /> <br /> === Generic flashrom infrastructure improvements ===<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 /> == Linux Firmware Kit, BITS ==<br /> <br /> There are various test suites for firmware aspects, esp. those that interacts with the operating systems. Unfortunately, some of these projects are dead, some seem to be forked and developed semi-publically, and having all that stuff in lots of different places is a big hassle.<br /> <br /> The goal of this project is to pick up the pieces, and create a single tool (most likely a bootable CD/USB drive image) that can be booted on vendor BIOS (for the Red Hat and Canonical developers that work on these) as well as coreboot (preferably seabios and FILO to improve testability - is an issue created/fixed by coreboot or seabios?). This can then be improved in various ways.<br /> <br /> There's also intel-gpu-tools that might have some useful tests (at least for intel-boards): http://article.gmane.org/gmane.comp.video.dri.devel/63948<br /> <br /> When applying for this task, please state in your proposal what you think might be worthy extensions to the existing tests.<br /> <br /> Required knowledge for this task: Not so much coreboot/firmware level, but you should have some idea of the boot process of a Linux system (as these test suites are mostly Linux based). GSoC probably won't provide enough time to learn all that (Linux boot process, firmware interfaces such as ACPI) and still develop the tools in some useful way.<br /> <br /> == Infrastructure for automatic code checking ==<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:Stepan|Stefan Reinauer]]<br /> <br /> <br /> == coreboot test suite ==<br /> Create a test suite to gather and report coreboot mainboard and payload settings. This project may leverage libpayload, coreinfo, memtest86, BITS, and other tools. The suite should gather result and report them at summary and detailed levels. The goal is to help coreboot developers identify problems and to test coreboot features. This project should work closely with the testing rig and test reporting projects. 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://biosbits.org/ BITS]<br /> http://www.coreboot.org/Supported_Motherboards<br /> <br /> === Mentor ===<br /> * [[User:MJones|Marc Jones]] <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 /> * [[InSystemFlasher]] is a cheap DIY hardware prototype for building an automated testing rig for modern SPI-based boards. This could be used as a starting point.<br /> <br /> === Mentors ===<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> <br /> == coreboot mainboard test result reporting ==<br /> One of the biggest challenges in coreboot is support many systems in the same codebase. As systems age and coreboot continues to develop, the condition of mainboards becomes unknown. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. 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.coreboot.org/Supported_Motherboards<br /> <br /> === Mentor ===<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> <br /> == coreboot ports for Family14 mainboards == <br /> Identify potential mainboards to port based on the recently released AMD Family 14 support. The goal would be to support publicly available plaftorms with a number of payloads and operating systems.<br /> <br /> === Mentor ===<br /> *[[User:Jason Wang|QingPei Wang]]<br /> <br /> <br /> == coreboot ACPI/S3/power managment ==<br /> coreboot has support for ACPI tables and S3 support for some platforms, but it is very mainboard specific. Create a generic solution for ACPI table generation and S3 support.<br /> <br /> === Mentor ===<br /> *<br /> <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 /> * [[User:Jason Wang|QingPei Wang]]<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 /> Ron 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 Ron 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 /> It might be possible to integrate this into the coreboot build as a bootblock option (in the same spot as the fallback/normal switch and the simple loader).<br /> <br /> === Mentors ===<br /> * [[User:Rminnich|Ron Minnich]]<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 /> === Links ===<br /> * ?<br /> <br /> === Mentors ===<br /> * ?<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 /> <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 embedded 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 /> <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, 2009, and 2010. See our [[Previous GSoC Projects|list of previous GSoC projects]].</div>

Hailfinger http://www.coreboot.org/Talk:FOSDEM_2012 2012-02-03T20:57:41Z

<p>Hailfinger: /* Carl-Daniel */</p> <hr /> <div>=Who is coming?=<br /> <br /> * Idwer Vollering<br /> * Sven Schnelle<br /> * Peter Stuge<br /> * Rudolf Marek<br /> * Carl-Daniel Hailfinger<br /> <br /> <br /> =Who brings what?=<br /> <br /> ==Idwer==<br /> <br /> ==Sven==<br /> Xeon i5000 system + Thinkpad T60, both running coreboot<br /> <br /> ==Peter==<br /> <br /> ==Rudolf==<br /> <br /> * Asus M2V-MX SE CPU + ATX PSU + keyboard + HDD (sata and IDE)<br /> * A8V-E SE + PCIe Radeon + port80<br /> * bifferboard<br /> * USB serial<br /> * JTAG xilinx<br /> * flash chips<br /> * openflashprog for USB SPI flashing<br /> <br /> ==Carl-Daniel==<br /> * Lots of power sockets and extension cords<br /> * Bus Pirate<br /> * HP 635 laptop<br /> * Various flash chips<br /> * Artec FlexyICE<br /> * 19&quot; flat screen monitor with DVI+VGA incl. cables<br /> * flashrom flyers<br /> * posters<br /> * thousands of cables<br /> <br /> ==Stuff we need (please check if you can bring it)==<br /> * Thinkpad X60/T60 with working VGA out for the beamer so it can be demoed at the talk. (Preferably two of them.)<br /> * Flyers for coreboot and flashrom. Who has the PDFs for our latest flyers (probably Carl-Daniel)?</div>

Hailfinger http://www.coreboot.org/FOSDEM_2012 2012-02-03T20:46:56Z

<p>Hailfinger: /* coreboot+flashrom booth/stand */</p> <hr /> <div>== Time and Place ==<br /> <br /> Saturday and Sunday, 4th and 5th of February 2012, at FOSDEM2012 in Brussels, Belgium.<br /> <br /> == FOSDEM? ==<br /> <br /> [http://www.fosdem.org FOSDEM] is simply the biggest free software developers event in Europe. For the last 11 years, on one weekend in February, a campus from the Brussels Free University gets raided by some 5000 open source developers and enthusiasts. There are main tracks with high profile talks, there are project specific devrooms with talks and hands on session, there are booths, and all of it is free (although donations are appreciated).<br /> <br /> == coreboot+flashrom talk ==<br /> <br /> [http://fosdem.org/2012/schedule/event/coreboot_laptops coreboot - The last frontier: Laptops]<br /> *Speaker: Carl-Daniel Hailfinger<br /> *Day: Sunday<br /> *Room: Janson<br /> *Start time: 12:00<br /> *End time: 12:50<br /> <br /> == coreboot+flashrom booth/stand ==<br /> <br /> coreboot+flashrom have a joint booth at FOSDEM, AW building. Please stop by.<br /> <br /> == Organizational info ==<br /> <br /> See [[Talk:FOSDEM 2012]]<br /> <br /> See [[FOSDEM 2011]] and [[Talk:FOSDEM 2011]] for info on what we did last year.</div>

Hailfinger http://www.coreboot.org/Talk:FOSDEM_2012 2012-02-02T23:19:04Z

<p>Hailfinger: /* Carl-Daniel */</p> <hr /> <div>=Who is coming?=<br /> <br /> * Idwer Vollering<br /> * Sven Schnelle<br /> * Peter Stuge<br /> * Rudolf Marek<br /> * Carl-Daniel Hailfinger<br /> <br /> <br /> =Who brings what?=<br /> <br /> ==Idwer==<br /> <br /> ==Sven==<br /> Xeon i5000 system + Thinkpad T60, both running coreboot<br /> <br /> ==Peter==<br /> <br /> ==Rudolf==<br /> <br /> ==Carl-Daniel==<br /> * Lots of power sockets and extension cords<br /> * Bus Pirate<br /> * HP 635 laptop<br /> * Various flash chips<br /> * Openbench Logic sniffer (if I can find it)<br /> * Artec FlexyICE (if I can find it)<br /> * 19&quot; flat screen monitor with DVI+VGA incl. cables<br /> * flashrom flyers<br /> * posters (need to check if they are usable)<br /> <br /> ==Stuff we need (please check if you can bring it)==<br /> * Thinkpad X60/T60 with working VGA out for the beamer so it can be demoed at the talk. (Preferably two of them.)<br /> * Flyers for coreboot and flashrom. Who has the PDFs for our latest flyers (probably Carl-Daniel)?</div>

Hailfinger http://www.coreboot.org/FOSDEM_2012 2012-02-02T23:17:44Z

<p>Hailfinger: /* coreboot+flashrom talk */</p> <hr /> <div>== Time and Place ==<br /> <br /> Saturday and Sunday, 4th and 5th of February 2012, at FOSDEM2012 in Brussels, Belgium.<br /> <br /> == FOSDEM? ==<br /> <br /> [http://www.fosdem.org FOSDEM] is simply the biggest free software developers event in Europe. For the last 11 years, on one weekend in February, a campus from the Brussels Free University gets raided by some 5000 open source developers and enthusiasts. There are main tracks with high profile talks, there are project specific devrooms with talks and hands on session, there are booths, and all of it is free (although donations are appreciated).<br /> <br /> == coreboot+flashrom talk ==<br /> <br /> [http://fosdem.org/2012/schedule/event/coreboot_laptops coreboot - The last frontier: Laptops]<br /> *Speaker: Carl-Daniel Hailfinger<br /> *Day: Sunday<br /> *Room: Janson<br /> *Start time: 12:00<br /> *End time: 12:50<br /> <br /> == coreboot+flashrom booth/stand ==<br /> <br /> coreboot+flashrom have a joint booth at FOSDEM, FIXME building, booth FIXME. Please stop by.<br /> <br /> == Organizational info ==<br /> <br /> See [[Talk:FOSDEM 2012]]<br /> <br /> See [[FOSDEM 2011]] and [[Talk:FOSDEM 2011]] for info on what we did last year.</div>

Hailfinger http://www.coreboot.org/Talk:FOSDEM_2012 2012-01-29T03:07:18Z

<p>Hailfinger: /* Stuff we need (please check if you can bring it) */</p> <hr /> <div>=Who is coming?=<br /> <br /> * Idwer Vollering<br /> * Sven Schnelle<br /> * Peter Stuge<br /> * Rudolf Marek<br /> * Carl-Daniel Hailfinger<br /> <br /> <br /> =Who brings what?=<br /> <br /> ==Idwer==<br /> <br /> ==Sven==<br /> <br /> ==Peter==<br /> <br /> ==Rudolf==<br /> <br /> ==Carl-Daniel==<br /> * Lots of power sockets and extension cords<br /> * Bus Pirate<br /> * HP 635 laptop<br /> * Various flash chips<br /> * Openbench Logic sniffer (if I can find it)<br /> * Artec FlexyICE (if I can find it)<br /> * 19&quot; flat screen monitor with DVI+VGA (if needed)<br /> <br /> ==Stuff we need (please check if you can bring it)==<br /> * Thinkpad X60/T60 with working VGA out for the beamer so it can be demoed at the talk. (Preferably two of them.)<br /> * Flyers for coreboot and flashrom. Who has the PDFs for our latest flyers (probably Carl-Daniel)?</div>

Hailfinger http://www.coreboot.org/Talk:FOSDEM_2012 2012-01-29T03:06:38Z

<p>Hailfinger: /* Carl-Daniel */</p> <hr /> <div>=Who is coming?=<br /> <br /> * Idwer Vollering<br /> * Sven Schnelle<br /> * Peter Stuge<br /> * Rudolf Marek<br /> * Carl-Daniel Hailfinger<br /> <br /> <br /> =Who brings what?=<br /> <br /> ==Idwer==<br /> <br /> ==Sven==<br /> <br /> ==Peter==<br /> <br /> ==Rudolf==<br /> <br /> ==Carl-Daniel==<br /> * Lots of power sockets and extension cords<br /> * Bus Pirate<br /> * HP 635 laptop<br /> * Various flash chips<br /> * Openbench Logic sniffer (if I can find it)<br /> * Artec FlexyICE (if I can find it)<br /> * 19&quot; flat screen monitor with DVI+VGA (if needed)<br /> <br /> ==Stuff we need (please check if you can bring it)==<br /> * Thinkpad X60/T60 with working VGA out for the beamer so it can be demoed at the talk. (Preferably two of them.)</div>

Hailfinger http://www.coreboot.org/Talk:FOSDEM_2012 2012-01-29T02:59:19Z

<p>Hailfinger: typo</p> <hr /> <div>=Who is coming?=<br /> <br /> * Idwer Vollering<br /> * Sven Schnelle<br /> * Peter Stuge<br /> * Rudolf Marek<br /> * Carl-Daniel Hailfinger<br /> <br /> <br /> =Who brings what?=<br /> <br /> ==Idwer==<br /> <br /> ==Sven==<br /> <br /> ==Peter==<br /> <br /> ==Rudolf==<br /> <br /> ==Carl-Daniel==<br /> * Lots of power sockets and extension cords<br /> * Bus Pirate<br /> * HP 635 laptop<br /> * Openbench Logic sniffer (if I can find it)<br /> * Artec FlexyICE (if I can find it)<br /> * Various flash chips<br /> <br /> <br /> ==Stuff we need (please check if you can bring it)==<br /> * Thinkpad X60/T60 with working VGA out for the beamer so it can be demoed at the talk. (Preferably two of them.)</div>

Hailfinger http://www.coreboot.org/Talk:FOSDEM_2012 2012-01-29T02:58:59Z

<p>Hailfinger: Who brings what</p> <hr /> <div>=Who is coming??<br /> <br /> * Idwer Vollering<br /> * Sven Schnelle<br /> * Peter Stuge<br /> * Rudolf Marek<br /> * Carl-Daniel Hailfinger<br /> <br /> <br /> =Who brings what?=<br /> <br /> ==Idwer==<br /> <br /> ==Sven==<br /> <br /> ==Peter==<br /> <br /> ==Rudolf==<br /> <br /> ==Carl-Daniel==<br /> * Lots of power sockets and extension cords<br /> * Bus Pirate<br /> * HP 635 laptop<br /> * Openbench Logic sniffer (if I can find it)<br /> * Artec FlexyICE (if I can find it)<br /> * Various flash chips<br /> <br /> <br /> ==Stuff we need (please check if you can bring it)==<br /> * Thinkpad X60/T60 with working VGA out for the beamer so it can be demoed at the talk. (Preferably two of them.)</div>

Hailfinger http://www.coreboot.org/Current_events 2012-01-29T02:42:46Z

<p>Hailfinger: FOSDEM 2012</p> <hr /> <div>Please contact [[User:Stepan|Stefan Reinauer]], [[User:Rminnich|Ronald Minnich]] or [[User:Stuge|Peter Stuge]] for more information on the events.<br /> <br /> == Upcoming Events ==<br /> <br /> '''2012'''<br /> <br /> * coreboot and flashrom share a booth at [[FOSDEM 2012]] in Brussels on February 4-5, 2012, and a presentation about coreboot on laptops will be held by [[User:Hailfinger|Carl-Daniel Hailfinger]].<br /> <br /> == Past Events ==<br /> <br /> '''2011'''<br /> <br /> * coreboot and flashrom exhibit at [http://www.linuxtag.org/ LinuxTag] in Berlin on May 11-14, 2011.<br /> <br /> * coreboot and flashrom shared a booth at [[FOSDEM 2011]] in Brussels on February 5-6, 2011, and several presentations were held by [[User:Ruik|Rudolf Marek]] and [[User:Hailfinger|Carl-Daniel Hailfinger]].<br /> <br /> <br /> '''2010'''<br /> <br /> * coreboot exhibited at [http://www.linuxtag.org/ LinuxTag 2010] in Berlin on June 9-12, 2010.<br /> * coreboot had its [[FOSDEM 2010|very first DevRoom]] at [http://www.fosdem.org/ FOSDEM] in Brussels on February 6, 2010.<br /> <br /> '''2009'''<br /> <br /> * [[User:Stuge|Peter Stuge]] presented [http://events.ccc.de/congress/2009/Fahrplan/events/3661.en.html coreboot] at [http://events.ccc.de/congress/2009/ the 26th Chaos Communication Congress (26C3)] in Berlin on December 27, 2009.<br /> * [[User:Stuge|Peter Stuge]] presented [http://www.databadge.net/ifsec2009/reg/lin/show_sessions.php coreboot] at [http://www.linux-world.nl/nl-NL/Bezoeker.aspx?sc_lang=en LinuxWorld Conference &amp; Expo] in Utrecht on November 4, 2009.<br /> * [[User:Stuge|Peter Stuge]] presented [https://har2009.org/program/events/210.en.html coreboot] at [https://wiki.har2009.org/page/Main_Page HAR2009] in Vierhouten on August 13, 2009.<br /> * coreboot had a booth at [[LinuxTag 2009|LinuxTag]] in Berlin on June 24-27, 2009.<br /> * [[User:Stuge|Peter Stuge]] presented coreboot at [http://freedomhectaipei.pbworks.com/ FreedomHEC Taipei] on June 11, 2009.<br /> * [[User:Stuge|Peter Stuge]] presented coreboot at [http://goopen2009.friprog.no/ GoOpen 2009] in Oslo on April 16-17, 2009.<br /> * [[User:Stepan|Stefan Reinauer]], [[User:Stuge|Peter Stuge]] and [[User:Ruik|Rudolf Marek]] made a visit at [http://www.embedded-world.de/ embedded world 2009] in Nürnberg on March 3-5.<br /> * [[User:Rminnich|Ron Minnich]] had a [http://scale7x.socallinuxexpo.org/dotorg/coreboot coreboot booth] at the [http://scale7x.socallinuxexpo.org/ Southern California Linux Expo] (SCALE 7x) on February 20-22, 2009.<br /> <br /> '''2008'''<br /> <br /> * [[User:Stuge|Peter Stuge]] presented [http://events.ccc.de/congress/2008/Fahrplan/events/2970.en.html coreboot: Beyond The Final Frontier] and held a coreboot workshop at [http://events.ccc.de/congress/2008/ the 25th Chaos Communication Congress (25C3)] on December 27-30.<br /> * [[User:Stuge|Peter Stuge]] presented coreboot at the [http://www.nluug.nl/events/nj08/ NLUUG Autumn Conference on Mobile Computing] and [http://www.embeddedlinuxconference.com/elc_europe08/ CE Linux Forum - Embedded Linux conference Europe 2008] on November 6-7.<br /> * [[User:Rminnich|Ronald Minnich]], [[User:Stuge|Peter Stuge]] and [[User:Stepan|Stefan Reinauer]] presented coreboot in a [[Screenshots#Google_Tech_Talks_2008:_coreboot_.28aka_LinuxBIOS.29:_The_Free.2FOpen-Source_x86_Firmware|Google TechTalk]] on October 30.<br /> * [[User:Stuge|Peter Stuge]] presented [http://fscons.org/events/?action=event&amp;id=32 coreboot] at the [http://fscons.org/ Free Society Conference and Nordic Summit 2008] on October 24-26.<br /> * [[User:Stuge|Peter Stuge]] presented coreboot at the [http://slackathon.se/2008/ Slackathon 2008] OpenBSD meeting in September.<br /> * Coreboot was exhibiting at [[LinuxTag 2008]] in Berlin on May 28-31.<br /> * The [[Coreboot Symposium 2008|coreboot symposium 2008]] was held in Denver, April 3 – 5, 2008 during the High Performance Computer Science Week [http://www.hpcsw.org HPCSW].<br /> <br /> '''2007'''<br /> <br /> * There was a [[News#2007.2F05.2F23_LinuxBIOS_booth_at_LinuxTag_in_Berlin.2C_29.2F5-2.2F6|LinuxBIOS booth at the LinuxTag in Berlin, May 29 - June 6, 2007]], as well as a hands-on workshop by Peter Stuge.<br /> * Ron Minnich gave [http://www.fosdem.org/2007/schedule/events/linuxbios a talk about LinuxBIOS] on February 24, 2007 at [http://www.fosdem.org/2007/ FOSDEM 2007].<br /> <br /> '''2006'''<br /> <br /> * The [[LinuxBIOS Symposium 2006]] took place on October 1-3, 2006 in Hamburg, Germany.<br /> <br /> '''2005'''<br /> <br /> * The [[LinuxBIOS Summit 2005]] took place on October 11-13 in Santa Fe, NM.</div>

Hailfinger http://www.coreboot.org/Welcome_to_coreboot 2012-01-29T02:41:01Z

<p>Hailfinger: FOSDEM 2012</p> <hr /> <div>&lt;table width=&quot;100%&quot; valign=&quot;top&quot;&gt;&lt;tr valign=&quot;top&quot;&gt;&lt;td width=&quot;80%&quot;&gt;<br /> <br /> &lt;div style=&quot;margin-top:0.5em; margin-bottom:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;&quot;&gt;<br /> '''coreboot''' 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 /> &lt;small&gt;<br /> coreboot was formerly known as [http://www.coreboot.org/pipermail/coreboot/2008-January/029133.html LinuxBIOS]. <br /> &lt;/small&gt;<br /> &lt;/div&gt;<br /> <br /> &lt;div style=&quot;margin-top:0.5em; margin-bottom:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;&quot;&gt;<br /> coreboot recently switched to [[git]] and [http://review.coreboot.org gerrit] is now used as patch review tool.<br /> &lt;/div&gt;<br /> <br /> {| cellspacing=0 cellpadding=8 border=0 margin=0 padding=0 align=&quot;top&quot; width=100%<br /> |-<br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {{Box|<br /> BORDER = #8898bf|<br /> BACKGROUND = yellow|<br /> WIDTH = 100%|<br /> ICON = &lt;small&gt;[[Benefits|More...]]&lt;/small&gt;|<br /> HEADING = &lt;span style=&quot;font-variant:small-caps; font-size:120%&quot;&gt;[[Benefits]]&lt;/span&gt;|<br /> CONTENT =<br /> &lt;small&gt;<br /> * 100% Free Software (GPL), no royalties, no license fees!<br /> * Fast boot times (3 seconds to Linux console)<br /> &lt;!-- * Avoids the need for a slow/buggy/proprietary BIOS --&gt;<br /> &lt;!-- * Runs in 32-Bit protected mode almost from the start --&gt;<br /> &lt;!-- * Written in C, contains virtually no assembly code --&gt;<br /> * Supports many [[Supported Motherboards|mainboards]], [[Supported Chipsets and Devices|chipsets]], and [[payloads]]<br /> &lt;!-- * Further features: netboot, serial console, remote flashing, ... --&gt;<br /> &lt;/small&gt;<br /> }}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {{Box|<br /> BORDER = #8898bf|<br /> BACKGROUND = #d1adf6|<br /> WIDTH = 100%|<br /> ICON = &lt;small&gt;[[Use Cases|More...]]&lt;/small&gt;|<br /> HEADING = &lt;span style=&quot;font-variant:small-caps; font-size:120%&quot;&gt;[[Use Cases]]&lt;/span&gt;|<br /> CONTENT =<br /> &lt;small&gt;<br /> * Desktop PCs, servers, [[Laptop|laptops]]<br /> * [[Clusters]]<br /> &lt;!-- * Set-Top-Boxes, thin clients --&gt;<br /> * Embedded solutions<br /> &lt;!-- * [http://en.wikipedia.org/wiki/Small_form_factor Small form factor computers], [http://en.wikipedia.org/wiki/Home_theater_PC Home-theater PCs] --&gt;<br /> &lt;!-- * No-moving-parts solutions (ROM chip as &quot;disk&quot;) --&gt;<br /> &lt;!-- * Non-standard scenarios (e.g. FPGA in Opteron socket) --&gt;<br /> &lt;/small&gt;<br /> }}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {{Box|<br /> BORDER = #8898bf|<br /> BACKGROUND = lime|<br /> WIDTH = 100%|<br /> ICON = &lt;small&gt;[[Payloads|More...]]&lt;/small&gt;|<br /> HEADING = &lt;span style=&quot;font-variant:small-caps; font-size:120%&quot;&gt;[[Payloads]]&lt;/span&gt;|<br /> CONTENT =<br /> &lt;small&gt;<br /> * [[SeaBIOS]] / [[FILO]] / [[GRUB2]] / [[Payloads|...]] &lt;!-- / [[OpenFirmware]] / [[OpenBIOS]] --&gt;<br /> * [[Linux]] / [[Windows]] / [[FreeBSD]] / [[NetBSD]] / [[Payloads|...]] &lt;!-- / [http://openbsd.org/ OpenBSD]--&gt;<br /> * [[Etherboot]] / [[GPXE]] / [[Payloads|...]]<br /> &lt;!--* [[Memtest86]]<br /> * [[Bayou]] / [[Coreinfo]] / [[Tint]] / [[Libpayload]]--&gt;<br /> &lt;/small&gt;<br /> }}<br /> <br /> |}<br /> <br /> {| cellspacing=5 cellpadding=15 border=0 valign=&quot;top&quot; width=100%<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_cb.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;About&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Find out more about coreboot.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[Press]] | [[Logo]] | [[History]] | [[Screenshots|Screenshots/Videos]] | [[Contributors]] | [[Sponsors]] | [[Products]] | [[Vendors]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_devel.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;Developers&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Get involved! Help us make coreboot better.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[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]] | [[Flag Days]] | [[Distributed and Automated Testsystem|Testsystem]]&lt;/small&gt;<br /> |}<br /> <br /> |-<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_status.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;Status&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Find out whether your hardware is already supported.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[Supported Motherboards|Supported Boards]] | [[Supported Chipsets and Devices|Supported Chipsets]] | [[:Category:Tutorials|Board Status Pages]] | [http://qa.coreboot.org Build Status]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_tools.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;Related Tools&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Tools and libraries related to coreboot.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[Flashrom]] | [[Superiotool]] | [[Nvramtool]] | [[Buildrom]] | [[Mkelfimage]] | [[Inteltool]] | [[Msrtool]] | [[Ectool]] | [[Developer_Manual/Tools|Hardware tools]] | [[Abuild]] | [[SerialICE]]&lt;/small&gt;<br /> |}<br /> <br /> |-<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_101.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;Getting Started&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Download coreboot and get started.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[Build HOWTO]] | [[Download coreboot|Downloads]] | [[Documentation]] | [[QEMU]] | [[AMD SimNow]] | [[Build from Windows]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_support.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;Support&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Learn how to contact us and find help and support.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[FAQ]] | [[Mailinglist]] | [[IRC]] | [http://tracker.coreboot.org/trac/coreboot/ Issue Tracker] | [[Glossary]] | [[coreboot Options|coreboot Options]]&lt;/small&gt;<br /> |}<br /> <br /> |}<br /> &lt;/td&gt;&lt;td width=&quot;20%&quot;&gt;<br /> <br /> [[File:Coreboot menuconfig.png|center|thumb|[[Build HOWTO|make menuconfig]] in coreboot]]<br /> <br /> &lt;br clear=all /&gt;<br /> <br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:120%&quot;&gt;[http://blogs.coreboot.org News (blog)]&lt;/span&gt;'''&lt;hr /&gt;<br /> &lt;small&gt;<br /> &lt;rss max=5&gt;http://blogs.coreboot.org/feed/&lt;/rss&gt;<br /> &lt;/small&gt;<br /> <br /> <br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:120%&quot;&gt;[[Current events|Upcoming Events]]&lt;/span&gt;'''&lt;hr /&gt;<br /> &lt;!-- List of upcoming events (remove events after they have taken place). --&gt;<br /> &lt;small&gt;<br /> &lt;!-- * '''2011/mon/day:''' coreboot event at [[Link]] in somecity --&gt;<br /> * '''2012/02/04-05:''' coreboot and flashrom booths and talk at [[FOSDEM 2012]] in Brussels, Belgium<br /> * '''2011/05/11-14:''' coreboot and [[Flashrom|flashrom]] booths at [http://www.linuxtag.org/ LinuxTag] in Berlin<br /> * [[GSoC|2011 Google Summer of Code]]<br /> &lt;/small&gt;<br /> <br /> <br /> &lt;br clear=all /&gt;<br /> {{#widget:Ohloh Project|id=coreboot|type=partner_badge}}<br /> {{#widget:Ohloh Project|id=coreboot|type=cocomo}}<br /> <br /> <br /> &lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;<br /> <br /> __NOTOC__<br /> __NOEDITSECTION__</div>

Hailfinger http://www.coreboot.org/FOSDEM_2012 2012-01-29T02:38:27Z

<p>Hailfinger: New page.</p> <hr /> <div>== Time and Place ==<br /> <br /> Saturday and Sunday, 4th and 5th of February 2012, at FOSDEM2012 in Brussels, Belgium.<br /> <br /> == FOSDEM? ==<br /> <br /> [http://www.fosdem.org FOSDEM] is simply the biggest free software developers event in Europe. For the last 11 years, on one weekend in February, a campus from the Brussels Free University gets raided by some 5000 open source developers and enthusiasts. There are main tracks with high profile talks, there are project specific devrooms with talks and hands on session, there are booths, and all of it is free (although donations are appreciated).<br /> <br /> == coreboot+flashrom talk ==<br /> <br /> FIXME<br /> <br /> == coreboot+flashrom booth/stand ==<br /> <br /> coreboot+flashrom have a joint booth at FOSDEM, FIXME building, booth FIXME. Please stop by.<br /> <br /> == Organizational info ==<br /> <br /> See [[Talk:FOSDEM 2012]]<br /> <br /> See [[FOSDEM 2011]] and [[Talk:FOSDEM 2011]] for info on what we did last year.</div>

Hailfinger http://www.coreboot.org/Embedded_controller 2011-02-23T00:27:05Z

<p>Hailfinger: /* Supported by coreboot */ other ECs</p> <hr /> <div>[[File:Dell_latitude_cpi_a366xt_superio.jpg|thumb|right|SMSC FDC37N958FR]]<br /> [[File:Dell_latitude_c610_superio.jpg|thumb|right|SMSC LPC47N252]]<br /> <br /> The '''embedded controller''' is a small microcontroller typically used in laptops for various purposes.<br /> <br /> == Supported by coreboot ==<br /> <br /> === Renesas M3885/M3886 ===<br /> <br /> These ECs are supported by coreboot. There are several versions, with flash and with mask ROMs. Only the flash versions are update-able. These ECs are Family 740 based. A development environment including compiler and simulator is available from Renesas.<br /> <br /> === Other ECs ===<br /> ECs are supportable if you either have<br /> * interface docs for the vendor supplied closed source EC firmware or<br /> * complete docs for the EC, and docs for the hardware it should control (backlight, battery charging, power sequencing of the mainboard)<br /> * open source EC firmware<br /> Some of the info (interface docs) can be reverse engineered to some degree, but that is very tedious.<br /> <br /> == Embedded controller table ==<br /> <br /> {| border=&quot;0&quot; style=&quot;font-size: smaller&quot;<br /> |- bgcolor=&quot;#6699dd&quot;<br /> ! align=&quot;left&quot; | Vendor<br /> ! align=&quot;left&quot; | Model<br /> ! align=&quot;left&quot; | Type<br /> ! align=&quot;left&quot; | Architecture<br /> ! align=&quot;left&quot; | Datasheet(s)<br /> ! align=&quot;left&quot; | Comments<br /> <br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || KB910 || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || KB926C || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || KB926D || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || KB3310 || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || KB3700 || EC || 8bit, 8051 core || [http://wiki.laptop.org/images/a/ab/KB3700-ds-01.pdf] || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&amp;id=2256 KB3910] || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&amp;id=2268 KB3920] || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&amp;id=2269 KB3925] || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&amp;id=2270 KB3926] || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> <br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://www.fujitsu.com Fujitsu] || MB90378 || EC || 16bit, F&lt;sup&gt;2&lt;/sup&gt;MC-16LX family || [http://edevice.fujitsu.com/fj/DATASHEET/e-ds/e713740.pdf] || &amp;mdash;<br /> <br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || IT8500 || EC &amp; Super I/O || ? || ? || Source: [http://gmb.viatech.com.cn/resource/downloads/VGTF-Autumn/ITE/ITE.pdf]<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || IT8502E || EC &amp; Super I/O || 8bit, 8032 core (8051 compatible) || on request || Source: [http://de.viatech.com/de/initiatives/spearhead/surfboard_c855/] [http://gmb.viatech.com/resource/jsp/PartnersSolutions/Partners/ITE/index.jsp]<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&amp;ID=6,79 IT8510E/TE/G] || EC &amp; Super I/O || 8bit, 8032 core (8051 compatible) || on request || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&amp;ID=6,80 IT8511E/TE/G] || EC &amp; Super I/O || 8bit, 8032 core (8051 compatible) || on request || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&amp;ID=6,81 IT8512E/F/G] || EC &amp; Super I/O || 8bit, 8032 core (8051 compatible) || on request || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&amp;ID=6,82 IT8513E/F/G] || EC &amp; Super I/O || 8bit, 8032 core (8051 compatible) || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || IT8516 || EC &amp; Super I/O || ? || ? || Source: [http://gmb.viatech.com.cn/resource/downloads/VGTF-Autumn/ITE/ITE.pdf]<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&amp;ID=6,84 IT8301E] || External GPIO chip || ? || ? || &amp;mdash;<br /> <br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || 87541V || EC || 16 bit, CR16B core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || PC97551&lt;sup&gt;3&lt;/sup&gt; || EC || 16 bit, CR16B core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/ECAndNBKeyboardController/W83L951DG_W83L951FG.htm W83L951DG/FG]&lt;sup&gt;4&lt;/sup&gt; || EC || 8 bit, 8051 core || on request || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/ECAndNBKeyboardController/W83L951ADG_W83L951AFG.htm W83L951ADG/AFG]&lt;sup&gt;4&lt;/sup&gt; || EC || 8 bit, 8051 core || on request || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/AdvancedEmbeddedController/WPC8769L.htm WPC8765L/WPC8769L]&lt;sup&gt;4&lt;/sup&gt; || EC || 16 bit, ? core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/AdvancedEmbeddedController/WPC8763L.htm WPC8763L]&lt;sup&gt;4&lt;/sup&gt; || EC || 16 bit, CR16CPlus core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/AdvancedEmbeddedController/WPCE775x.htm WPCE775x]&lt;sup&gt;4&lt;/sup&gt; || EC || 16 bit, CR16CPlus core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || NPCE78nx || EC || ? || ? || &amp;mdash;<br /> <br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://eu.renesas.com/ Renesas] || [http://eu.renesas.com/fmwk.jsp?cnt=3885_root.jsp&amp;fp=/products/mpumcu/740_family/38000_740_series/3885_group/ M38859]&lt;sup&gt;1&lt;/sup&gt; || EC || 8bit, 740 family || [http://documentation.renesas.com/eng/products/mpumcu/e3885g.pdf] || &amp;mdash;<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://eu.renesas.com/ Renesas] || [http://eu.renesas.com/fmwk.jsp?cnt=3886_root.jsp&amp;fp=/products/mpumcu/740_family/38000_740_series/3886_group/ M38867M8A]&lt;sup&gt;1&lt;/sup&gt; || EC || 8bit, 740 family || [http://documentation.renesas.com/eng/products/mpumcu/e3886g.pdf] || &amp;mdash;<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://eu.renesas.com/ Renesas] || [http://eu.renesas.com/fmwk.jsp?cnt=h8s2117_root.jsp&amp;fp=/products/mpumcu/h8s_family/h8s2100_series/h8s2117_group H8S/2117R]&lt;sup&gt;2&lt;/sup&gt; || EC || 16 bit, H8S family || ? || Source: [http://www.intelcommsalliance.com/kshowcase/view/view_item/4ddd1dbe78eb6b235cc4f07eabb79ae562ae690e]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://eu.renesas.com/ Renesas] || H8S/2161B&lt;sup&gt;2&lt;/sup&gt; || EC || 16 bit, H8S family || ? || Source: [http://www.thinkwiki.org/wiki/Embedded_Controller_Chips], [http://www.thinkwiki.org/wiki/Embedded_Controller_Firmware], [http://forum.thinkpads.com/viewtopic.php?t=20958], [http://www.thinkwiki.org/wiki/Renesas_H8S/2161BV]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://eu.renesas.com/ Renesas] || H8S/2169AV &lt;sup&gt;2&lt;/sup&gt; || EC || 16 bit, H8S family || ? || Source: [http://www.thinkwiki.org/wiki/Embedded_Controller_Chips], [http://www.thinkwiki.org/wiki/Embedded_Controller_Firmware], [http://forum.thinkpads.com/viewtopic.php?t=20958]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://eu.renesas.com/ Renesas] || H8S/64F3169ATE10&lt;sup&gt;2&lt;/sup&gt; || EC || 16 bit, H8S family || ? || &amp;mdash;<br /> <br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.national.com NSC] || PC87570 || EC &amp; Super I/O || ? || ? || &amp;mdash;<br /> <br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://www.smsc.com/ SMSC] || FDC37N958FR || EC &amp; Super I/O || ? || ? || &amp;mdash;<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://www.smsc.com/ SMSC] || LPC47N252 || EC &amp; Super I/O || ? || ? || &amp;mdash;<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://www.smsc.com/ SMSC] || [http://www.smsc.com/index.php?tid=252&amp;pid=173 MEC1308] || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://www.smsc.com/ SMSC] || [http://www.smsc.com/index.php?tid=252&amp;pid=172 KBC1122/KBC1122P] || EC &amp; Super I/O || 8bit, 8051 core || ? || &amp;mdash;<br /> <br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.sst.com/ SST] || [http://www.sst.com/about_sst/news/detail.dot?crumbTitle=NewsDetail&amp;id=320 SST79LF008] || EC &amp; Super I/O &amp; BIOS flash || 8bit, 8051 core || ? || &amp;mdash;<br /> <br /> |}<br /> <br /> &lt;small&gt;<br /> &lt;sup&gt;1&lt;/sup&gt; Previously Mitsubishi, now Renesas.&lt;br /&gt;<br /> &lt;sup&gt;2&lt;/sup&gt; Previously Hitachi, now Renesas.&lt;br /&gt;<br /> &lt;sup&gt;3&lt;/sup&gt; Previously National (NSC), then Winbond, now Nuvoton.&lt;br /&gt;<br /> &lt;sup&gt;4&lt;/sup&gt; Previously Winbond, now Nuvoton.&lt;br /&gt;<br /> &lt;/small&gt;<br /> <br /> == Resources ==<br /> <br /> === ENE KB3310/KB3910/KB3920 ===<br /> <br /> Very common ECs in netbooks are the KB3310, KB3910 and KB3920 from [http://www.ene.com.tw/en/index.asp ENE Technology]. The ENE ECs are 8051 based.<br /> <br /> The Quanta IL1 reference design seems to use ENE3310 controller. The q1d25i.rom was examined. The EC code is on 0xFFF00000 on One Mini A110. Its 64KB big HOLE0.ROM.<br /> <br /> More discussion and info on the ENE ECs: <br /> <br /> * [http://wiki.laptop.org/images/a/ab/KB3700-ds-01.pdf ENE KB3700 datasheet].<br /> * [http://forum.eeeuser.com/viewtopic.php?pid=99076 eeeUser Discussion] <br /> * [http://code.google.com/p/eeetune/wiki/KBMemoryMap Memory map of ENE KB3310]<br /> * [https://sdcc.svn.sourceforge.net/svnroot/sdcc/trunk/ 8051 simulator]<br /> * [http://dev.laptop.org/git?p=projects/olpcflash;a=blob;f=olpcflash.c;hb=HEAD OpenEC Firmware] <br /> * [http://wiki.laptop.org/go/OpenEC OpenEC Project]<br /> * [http://www.cagnulein.com/tmp/eee.c-20080812 Example code] that makes use of the KB3310's &quot;Index IO&quot; access functions.<br /> <br /> === Renesas H8 ===<br /> <br /> Some ECs are H8 based.<br /> <br /> * [http://www.gnuh8.org/ Port of the GNU compiler suite to the H8]<br /> * [http://wunderkis.de/h8-gcc/h8tools.tar.gz H8 bootloader]<br /> * [http://h8300-hms.sourceforge.net/ Sourceforge project for H8/300]<br /> <br /> == Toolchains ==<br /> <br /> TODO<br /> <br /> {{PD-self}}</div>

Hailfinger http://www.coreboot.org/Laptop 2011-02-23T00:20:23Z

<p>Hailfinger: /* Recent progress of coreboot on laptops */ Thinpad X60s</p> <hr /> <div>== Recent progress of coreboot on laptops ==<br /> <br /> * coreboot supports the [http://en.getac.com/products/P470/P470_overview.html Getac P470] semi rugged notebook, based on Intel 82945GM/ICH7.<br /> * coreboot supports the [http://www.roda-computer.com/en/products/notebooks/rocky-iii-rk886ex.html Roda RK886EX (Rocky III+)] laptop, based on Intel 82945GM/ICH7.<br /> * VIA has recently released open documentation for the VX700 and VX800 chipsets at the [http://linux.via.com.tw/support/downloadFiles.action VIA Download Portal].<br /> * coreboot supports one variant of the Lenovo [[Thinkpad X60s]].<br /> <br /> == Embedded controllers ==<br /> <br /> The remaining issue with supporting netbooks may be open firmware support for the [[Embedded controller]] (EC).<br /> These ECs used to support keyboard scan, lid open/closed, battery charging, power management, etc.<br /> <br /> coreboot should work with the &quot;stock&quot; EC firmware. This may still be a challenge because &quot;we don't know what we don't know&quot;. Behavior at runtime is fairly standardized, but we don't know what we need to do for initialization - do we need to set up registers, put in tables, kick things, or will it all Just Work (TM)?<br /> <br /> == HOWTO to find a way ==<br /> <br /> * find a model and manufacturer of your laptop<br /> * download these tools:<br /> # superiotool ( svn co svn://coreboot.org/coreboot/trunk/util/superiotool )<br /> # inteltool ( svn co svn://coreboot.org/coreboot/trunk/util/inteltool )<br /> # ectool ( svn co svn://coreboot.org/coreboot/trunk/util/ectool )<br /> # dmidecode ( cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/dmidecode co dmidecode )<br /> # msrtool (svn co svn://coreboot.org/coreboot/trunk/util/msrtool )<br /> # nvramtool ( svn co svn://coreboot.org/coreboot/trunk/util/nvramtool )<br /> # flashrom ( svn co svn://coreboot.org/flashrom/trunk flashrom )<br /> * make and install them (make; sudo make install) - you need at least libpci/pciutils<br /> * check that your distro have this tools and install them:<br /> # lspci<br /> # dmesg<br /> # acpitool<br /> # lspnp<br /> # lsusb<br /> * Do this commands:<br /> # lspci -nnvvvxxxx &gt; lscpi.log<br /> # lspnp -vv &gt; lspnp.log<br /> # lsusb -vvv &gt; lsusb.log<br /> # superiotool -deV &gt; superiotool.log<br /> # inteltool -a &gt; inteltool.log<br /> # ectool &gt; ectool.log<br /> # msrtool &gt; msrtool.log<br /> # dmidecode &gt; dmidecode.log<br /> # biosdecode &gt; biosdecode.log<br /> # nvramtool -x &gt; nvramtool.log<br /> # dmesg &gt; dmesg.log<br /> # flashrom -V -p internal:laptop=force_I_want_a_brick &gt; flashrom_info.log<br /> # flashrom -V -p internal:laptop=force_I_want_a_brick -r rom.bin &gt; flashrom_read.log<br /> * Save all logs in safe place, and also rom.bin file. <br /> * try to find information - what EC or Super I/O chip is used in your laptop (may be some info in Service Manuals or Disassembly guides)<br /> * if you see that ectool return some fake staff - like only 'FF' or '00' - so you have custom EC configuration, it's a hard work for support<br /> * if you see that ectool return looks like 'right' output - you have a big chances for support<br /> * you need to find from thease outputs Super I/O / EC chip name, or if not see this - disassembly your laptop<br /> * try to find your Super I/O / EC chip datasheet<br /> <br /> == Laptop survey ==<br /> <br /> This page attempts to list chipsets, Super I/Os, flash chips, and especially [[embedded controller]]s used in various laptops.<br /> <br /> {| border=&quot;0&quot; style=&quot;font-size: smaller&quot;<br /> |- bgcolor=&quot;#6699dd&quot;<br /> ! align=&quot;left&quot; | Vendor<br /> ! align=&quot;left&quot; | Model<br /> ! align=&quot;left&quot; | CPU<br /> ! align=&quot;left&quot; | Chipset NB<br /> ! align=&quot;left&quot; | Chipset SB<br /> ! align=&quot;left&quot; | Super&amp;nbsp;I/O<br /> ! align=&quot;left&quot; | [[Embedded controller|EC]]<br /> ! align=&quot;left&quot; | Flash Chip<br /> ! align=&quot;left&quot; | Flash Size<br /> ! align=&quot;left&quot; | Flash S.<br /> ! align=&quot;left&quot; | Flash T.<br /> ! align=&quot;left&quot; | Owner<br /> <br /> |- bgcolor=&quot;#dddddd&quot;<br /> | ASUS || S96F/Z96F || Intel&amp;nbsp;Core&amp;trade;2 Duo T7400 || Intel&amp;nbsp;i945 || Intel ICH7 || ITE IT8510E || in Super I/O || ? || ? || ? || ? || [http://www.flashrom.org/pipermail/flashrom/2010-January/001986.html macavity]<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | Acer || Aspire One ZG5 || Intel Atom N270 1.6GHz || Intel 82945GME || Intel NH82801GBM ICH7-M || Winbond WPCE775LA0DG || in Super I/O || Winbond 25x80AVSIG || 8Mb || no || SOIP/DIP || [[User:XVilka|XVilka]]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | Acer || Aspire 3613LC || Intel Celeron M 370 1.5GHz L2: 1MB || Intel 82910GML || Intel FW82801FBM SL7W6 ICH6-M || ? || ? || PMC 0537 PM39LV040-70JCE || 1Mb || no || SOIP/DIP || [[User:XVilka|XVilka]]<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | Dell || [[Dell Latitude CPi A366XT|Latitude CPi A366XT]] || PII, 360 MHz || Intel 440BX |||| SMSC&amp;nbsp;FDC37N958FR || in Super I/O || AMD AM29F040B || 512KB || yes || PLCC || [[User:Uwe|UH]]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | Dell || [[Dell Latitude C610|Latitude C610]] || PIII, 1.2 GHz || Intel i830 |||| SMSC&amp;nbsp;LPC47N252 || in Super I/O || SST SST49LF004A || 512KB || no || PLCC || [mailto:coreboot@miradou.com CybFr]<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | Dell || [[Dell Vostro V13]] || Intel Celeron 743 1.2GHz, L2: 1MB (Ultra Low Voltage) || Mobile Intel GS45 Express GHMC ||Intel 82801IEM ICH9M-E|| none || ITE IT8502E || Winbond 25Q16BVSIG || 2Mb || no || SOIP/PDIP || [[User:XVilka|XVilka]]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | Dell || XPS M1530 || Intel&amp;nbsp;Core&amp;trade;2 Duo T7700 || Intel PM965 || Intel ICH8 || none || Winbond WPC8763L || Winbond 25X16VSIG || 16Mb || ?? || SPI || Corey Osgood<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | Fujitsu-S. || Lifebook S-4572 || PIII, 750 MHz || Intel 82440MX |||| SMSC FDC37N769 || ? || Fujitsu&amp;nbsp;MBM29F400T&lt;sup&gt;1&lt;/sup&gt; || ? || no || TSOP(?) || [[User:Uwe|UH]]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | Fujitsu-S. || Lifebook S7110 || Intel&amp;nbsp;Core&amp;trade;2 Duo T7200 || Intel&amp;nbsp;i945 || Intel ICH7 || SMSC&amp;nbsp;LPC47N217 || Fujitsu MB90378 || Spansion S25FL008A&lt;sup&gt;2&lt;/sup&gt; || 1024 kB || no || SO8 / SPI || twice11<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | Gateway || [[Gateway W730-K8X | W730-K8X]] || Socket 754 |||| ?? || ?? || ?? || SST 39VF040 || ?? || yes || PLCC || [[User:Juri|Juri]]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | Gateway || [[Gateway 6020GZ|6020GZ]] || Celeron M 1.4Ghz || Intel 855GME |||| ?? || ?? || ?? || ?? || no || ?? || [[User:Juri|Juri]]<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | Gericom || Webboy 340S2 || PIII || SiS630 |||| NSC PC87393VJG || NSC PC87570 || Winbond&amp;nbsp;29C020 || 256 kB || yes || PLCC || [http://thread.gmane.org/gmane.linux.bios/13081 NS]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | Getac || P470 || Intel&amp;reg;&amp;nbsp;Core 2 Duo Mobile || Intel 945 || Intel ICH7 || ? || ? || ? || 8Mb || no || SPI / SOIC8 || [[User:Stepan|Stefan Reinauer]]<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | Highscreen || XD 14-C1700 || Intel&amp;nbsp;Celeron&amp;nbsp;1.7&amp;nbsp;GHz || SiS650 |||| NSC&amp;nbsp;PC87391(?) || ? || EON EN29F040(A) || 512 kB || yes || PLCC || [[User:Uwe|UH]]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | HP || Omnibook XE3(L) || PIII, 750 MHz || Intel&amp;nbsp;82371MB ||Intel PIIX4M || SMSC&amp;nbsp;FDC37N869 || NSC&amp;nbsp;PC87570 || SST 28SF040A || 512 kB || no || PLCC || [[User:Uwe|UH]]<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | IBM || Thinkpad T30 || Intel P4 Mobile, 1.8 GHz || Intel&amp;nbsp;i845 || Intel ICH3-M || NSC&amp;nbsp;PC87392 || Renesas H8S&amp;nbsp;64F3169ATE10 || ST&amp;nbsp;M50FW080N5 || 1024 kB || no || TSOP40 / FWH || edgecase<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | IBM || Thinkpad X60s || Intel Core Duo CPU L2300 || Intel&amp;nbsp;i945GM || Intel ICH7-M || NSC&amp;nbsp;PC87392 (in Ultrabase) || Renesas H8S2161B || MX25L1605D || 2048 kB || no || SOIC-8 || [[User:SvenS|Sven Schnelle]]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | MSI || Wind U100 || Intel Atom N280 1.66Ghz || Intel 945GSE || Intel ICH7-M || ? || ENE KB3310 || SST MX25L8005 || 8 Mb|| no || TSOP40 / SPI || ?<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | One || [http://www.a110wiki.de A110] || VIA&amp;nbsp;C7-M&amp;nbsp;ULV&amp;nbsp;1.0&amp;nbsp;GHz || VIA VX800 |||| none || ENE KB3310 || ? || ? || no || ? || [[User:Uwe|UH]]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | Panasonic || Toughbook&amp;nbsp;CF-25 || P166MMX || FW82439TX&amp;nbsp;(430TX) || FW82371AB || NSC PC87336VJG || Renesas&amp;nbsp;3886 || SST SST29EE020 || 256 kB || no || ? || [[User:Miernik|Miernik]]<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | Roda || Rocky III+ RK886EX || Intel&amp;reg;&amp;nbsp;Core 2 Duo Mobile T5500 || Intel 945 || Intel ICH7 || SMSC&amp;reg;&amp;nbsp;LPC47N227 || Renesas&amp;nbsp;M38859 || SST SST49LF080 || 8Mb || yes || PLCC || [[User:Stepan|Stefan Reinauer]]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | Roda || Rocky II+ RT686 || Intel&amp;nbsp;Pentium III || Intel 430BX || Intel FW82371EB || SMSC&amp;reg;&amp;nbsp;FDC37N769 || Renesas&amp;nbsp;M38867M8A || SST SST29LE020 || 256KB || yes || PLCC/parallel || [[User:Uwe|UH]]<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | Sony || Vaio&amp;nbsp;Picturebook&amp;nbsp;PCG-C1XD || P2 400 || 443ZX |||| ? || ? || ST M29W004BT || 512 kB || no || || [[User:Miernik|Miernik]]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | Sony || Vaio&amp;nbsp;Picturebook&amp;nbsp;PCG-C1X || P266MMX || 430TX |||| ? || ? || ? || ? || ? || ? || [[User:Miernik|Miernik]]<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | Toshiba || Libretto&amp;nbsp;50M PA1243CM || P133 || custom FPGA |||| ? || ? || ? || ? || ? || ? || [[User:Miernik|Miernik]]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | Toshiba || Satellite&amp;nbsp;A80-117 || Intel&amp;nbsp;Celeron || Intel&amp;nbsp;915GM || Intel ICH6 || SMSC&amp;nbsp;LPC47N217 || ENE KB910 || ? || 1024 kB || no || TSOP (?) || [[User:Uwe|UH]]<br /> <br /> |}<br /> <br /> &lt;small&gt;<br /> &lt;sup&gt;1&lt;/sup&gt; According to the vendor BIOS update tool.&lt;br /&gt;<br /> &lt;sup&gt;2&lt;/sup&gt; Nice thing: EC/Flash is not shared, so you can erase the whole flash during system operation (this was tested).&lt;br /&gt;<br /> &lt;/small&gt;<br /> <br /> Further links:<br /> <br /> * [http://tuxmobil.org/mylaptops.html Tuxmobil Laptop Survey]<br /> * [http://mcelrath.org/laptops.html Laptops/Notebooks with Linux Preinstalled]<br /> * [http://www.fsf.org/campaigns/free-bios.html The Free Software Foundation's Campaign for Free BIOS]<br /> <br /> == Mailinglist discussion ==<br /> <br /> A few earlier coreboot discussions on laptops are linked here, you might get useful information out of them: <br /> <br /> * [http://www.coreboot.org/pipermail/linuxbios/2005-February/010985.html Any update on coreboot for laptops] <br /> * [http://comments.gmane.org/gmane.linux.bios/13081 Notebook 340s2 (sis630) 256k Flash] <br /> * [http://www.coreboot.org/pipermail/linuxbios/2005-February/010972.html yet another reason to use coreboot in laptops I guess] <br /> * [http://www.coreboot.org/pipermail/linuxbios/2005-April/011429.html coreboot laptop hunt wiki page] <br /> * [http://www.coreboot.org/pipermail/linuxbios/2005-March/011140.html HP Pavillion ZV5000 (Laptop)] <br /> * [http://www.coreboot.org/pipermail/linuxbios/2005-July/011942.html SA1100] <br /> * [http://www.coreboot.org/pipermail/linuxbios/2003-September/004954.html Laptop with Sis 650 chipset] <br /> * [http://www.coreboot.org/pipermail/linuxbios/2006-September/015551.html coreboot on Laptops]<br /> <br /> == Who really makes your laptop? ==<br /> <br /> There are several various brands of laptops, but there are only a few actual laptop makers.<br /> <br /> Name brand companies like Hewlet Packard, Compaq, IBM, Dell, Gateway, Sony, Micron, Toshiba and others; including Alienware and Voodoo do not make their own laptops. The exceptions are Asus and Apple, and even Apple doesn't make all of their laptops.<br /> <br /> Original Design Manufacturers (ODM) make the laptops for Original Equipment Manufacturers (OEM). They in turn, add their preloaded hard drives and sell them to consumers. This is why a laptop is a bit more complicated to support with coreboot. The OEM's may not even have all the specifications for the laptop since the ODM has done all the design and assembly.<br /> <br /> Some laptop ODMs are:<br /> <br /> * [http://www.quantatw.com Quanta] makes laptops for Sony, Dell, and IBM <br /> * [http://www.inventec.com/ Inventec] and [http://www.arima.com.tw/ Arima] make the Compaq line<br /> * [http://www.compal.com/ Compal] also makes IBM and Dell lines, as well as Hewlett Packard<br /> * [http://www.clevo.com.tw/ Clevo] makes the popular Alienware and Voodoo gaming laptops<br /> <br /> Further links:<br /> <br /> * [http://www.laptopworldwide.com/laptops.html Makers of Laptops]<br /> * [http://tuxmobil.org/laptop_oem.html Laptop and NoteBook Manufacturer - OEM/ODM Relation Matrix]<br /> * [http://tuxmobil.org/reseller.html Where to Buy a Preinstalled Linux Laptop, Notebook, Mobile Phone or PDA? - Vendor Overview]<br /> <br /> == Random product links ==<br /> <br /> VIA has a list of many netbooks at [http://via.com.tw/en/products/notebook/notebook.jsp VIA Partner Mobility Devices]. <br /> <br /> VIA also has information on other mobile platforms at [http://via.com.tw/en/products/notebook/index.jsp VIA Mobility Platform]. <br /> <br /> The [http://www.a110wiki.de Quanta IL1] vx800 based reference design covers similar models/clones such as: <br /> <br /> *[http://www.one.de/shop/one-notebooks-one-mini-notebooks-c-213_214.html One Mini A110/A115/A120/A140/A150/A470] <br /> *[http://preview.tinyurl.com/5zbzl6 Airis Kira 100/350/740] <br /> *[http://www.norhtec.com/products/gecko/index.html Norhtec Gecko] <br /> *[http://www.pioneercomputers.com.au/products/configure.asp?c1=3&amp;c2=12&amp;id=2458 Pioneer DreamBook Light IL1] <br /> *[http://www.ctlcorp.com/v4/p-697-ctl-il1a-89-netbook-with-windows-xp-home.aspx CTL IL1] More [http://www.a110wiki.de/wiki/CTL_IL1 CTL IL1 info] with tear-down pics. <br /> *[http://www.aci-asia.com/html/Ethos_7.html ACi Ethos 7] <br /> *[http://www.ilikeblue.net/products/umpc.htm BDSI Deep Blue H1]<br /> <br /> Other vx800 based netbooks: <br /> <br /> *[http://www.everex.com/products/cloudbook_max/cloudbook_max.htm Everex CloudBook MAX] <br /> *[http://www.fic.com.tw/product/ce2a1.aspx FIC CE2A1]<br /> <br /> There are still a few netbook designs currently on the market that use the VIA vx700 chipset:<br /> <br /> *[http://www.sylvaniacomputers.com/products.php?p=g Sylvania G] <br /> *[http://www.everex.com/products/cloudbook/cloudbook.htm Everex Cloudbook] <br /> *[http://www.fic.com.tw/product/ce260.aspx FIC CE260] <br /> *[http://www.fic.com.tw/product/ce268.aspx FIC CE268]<br /> <br /> There are also several AMD 690/600 laptops still available that may be candidates as well: <br /> <br /> *[http://reviews.cnet.com/laptops/acer-extensa-4420-5963/4505-3121_7-33361062.html Acer Extensa 4420] <br /> *[http://www.raondigital.com EVERUN NOTE]<br /> <br /> Intel Atom with i945 chipset netbooks: <br /> <br /> *[http://en.wikipedia.org/wiki/Aspire_One Acer Aspire One] <br /> *[http://en.wikipedia.org/wiki/MSI_Wind_PC MSI Wind] <br /> *[http://en.wikipedia.org/wiki/ASUS_Eee_PC ASUS eeePC]</div>

Hailfinger http://www.coreboot.org/Embedded_controller 2011-02-23T00:01:28Z

<p>Hailfinger: /* Embedded controller table */ I have docs for IT8502, IT8510, IT8511, IT8512, W83L951DG/FG, W83L951ADG</p> <hr /> <div>[[File:Dell_latitude_cpi_a366xt_superio.jpg|thumb|right|SMSC FDC37N958FR]]<br /> [[File:Dell_latitude_c610_superio.jpg|thumb|right|SMSC LPC47N252]]<br /> <br /> The '''embedded controller''' is a small microcontroller typically used in laptops for various purposes.<br /> <br /> == Supported by coreboot ==<br /> <br /> === Renesas M3885/M3886 ===<br /> <br /> These ECs are supported by coreboot. There are several versions, with flash and with mask ROMs. Only the flash versions are update-able. These ECs are Family 740 based. A development environment including compiler and simulator is available from Renesas.<br /> <br /> == Embedded controller table ==<br /> <br /> {| border=&quot;0&quot; style=&quot;font-size: smaller&quot;<br /> |- bgcolor=&quot;#6699dd&quot;<br /> ! align=&quot;left&quot; | Vendor<br /> ! align=&quot;left&quot; | Model<br /> ! align=&quot;left&quot; | Type<br /> ! align=&quot;left&quot; | Architecture<br /> ! align=&quot;left&quot; | Datasheet(s)<br /> ! align=&quot;left&quot; | Comments<br /> <br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || KB910 || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || KB926C || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || KB926D || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || KB3310 || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || KB3700 || EC || 8bit, 8051 core || [http://wiki.laptop.org/images/a/ab/KB3700-ds-01.pdf] || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&amp;id=2256 KB3910] || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&amp;id=2268 KB3920] || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&amp;id=2269 KB3925] || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&amp;id=2270 KB3926] || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> <br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://www.fujitsu.com Fujitsu] || MB90378 || EC || 16bit, F&lt;sup&gt;2&lt;/sup&gt;MC-16LX family || [http://edevice.fujitsu.com/fj/DATASHEET/e-ds/e713740.pdf] || &amp;mdash;<br /> <br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || IT8500 || EC &amp; Super I/O || ? || ? || Source: [http://gmb.viatech.com.cn/resource/downloads/VGTF-Autumn/ITE/ITE.pdf]<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || IT8502E || EC &amp; Super I/O || 8bit, 8032 core (8051 compatible) || on request || Source: [http://de.viatech.com/de/initiatives/spearhead/surfboard_c855/] [http://gmb.viatech.com/resource/jsp/PartnersSolutions/Partners/ITE/index.jsp]<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&amp;ID=6,79 IT8510E/TE/G] || EC &amp; Super I/O || 8bit, 8032 core (8051 compatible) || on request || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&amp;ID=6,80 IT8511E/TE/G] || EC &amp; Super I/O || 8bit, 8032 core (8051 compatible) || on request || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&amp;ID=6,81 IT8512E/F/G] || EC &amp; Super I/O || 8bit, 8032 core (8051 compatible) || on request || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&amp;ID=6,82 IT8513E/F/G] || EC &amp; Super I/O || 8bit, 8032 core (8051 compatible) || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || IT8516 || EC &amp; Super I/O || ? || ? || Source: [http://gmb.viatech.com.cn/resource/downloads/VGTF-Autumn/ITE/ITE.pdf]<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&amp;ID=6,84 IT8301E] || External GPIO chip || ? || ? || &amp;mdash;<br /> <br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || 87541V || EC || 16 bit, CR16B core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || PC97551&lt;sup&gt;3&lt;/sup&gt; || EC || 16 bit, CR16B core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/ECAndNBKeyboardController/W83L951DG_W83L951FG.htm W83L951DG/FG]&lt;sup&gt;4&lt;/sup&gt; || EC || 8 bit, 8051 core || on request || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/ECAndNBKeyboardController/W83L951ADG_W83L951AFG.htm W83L951ADG/AFG]&lt;sup&gt;4&lt;/sup&gt; || EC || 8 bit, 8051 core || on request || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/AdvancedEmbeddedController/WPC8769L.htm WPC8765L/WPC8769L]&lt;sup&gt;4&lt;/sup&gt; || EC || 16 bit, ? core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/AdvancedEmbeddedController/WPC8763L.htm WPC8763L]&lt;sup&gt;4&lt;/sup&gt; || EC || 16 bit, CR16CPlus core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/AdvancedEmbeddedController/WPCE775x.htm WPCE775x]&lt;sup&gt;4&lt;/sup&gt; || EC || 16 bit, CR16CPlus core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.nuvoton.com/ Nuvoton] || NPCE78nx || EC || ? || ? || &amp;mdash;<br /> <br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://eu.renesas.com/ Renesas] || [http://eu.renesas.com/fmwk.jsp?cnt=3885_root.jsp&amp;fp=/products/mpumcu/740_family/38000_740_series/3885_group/ M38859]&lt;sup&gt;1&lt;/sup&gt; || EC || 8bit, 740 family || [http://documentation.renesas.com/eng/products/mpumcu/e3885g.pdf] || &amp;mdash;<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://eu.renesas.com/ Renesas] || [http://eu.renesas.com/fmwk.jsp?cnt=3886_root.jsp&amp;fp=/products/mpumcu/740_family/38000_740_series/3886_group/ M38867M8A]&lt;sup&gt;1&lt;/sup&gt; || EC || 8bit, 740 family || [http://documentation.renesas.com/eng/products/mpumcu/e3886g.pdf] || &amp;mdash;<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://eu.renesas.com/ Renesas] || [http://eu.renesas.com/fmwk.jsp?cnt=h8s2117_root.jsp&amp;fp=/products/mpumcu/h8s_family/h8s2100_series/h8s2117_group H8S/2117R]&lt;sup&gt;2&lt;/sup&gt; || EC || 16 bit, H8S family || ? || Source: [http://www.intelcommsalliance.com/kshowcase/view/view_item/4ddd1dbe78eb6b235cc4f07eabb79ae562ae690e]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://eu.renesas.com/ Renesas] || H8S/2161B&lt;sup&gt;2&lt;/sup&gt; || EC || 16 bit, H8S family || ? || Source: [http://www.thinkwiki.org/wiki/Embedded_Controller_Chips], [http://www.thinkwiki.org/wiki/Embedded_Controller_Firmware], [http://forum.thinkpads.com/viewtopic.php?t=20958], [http://www.thinkwiki.org/wiki/Renesas_H8S/2161BV]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://eu.renesas.com/ Renesas] || H8S/2169AV &lt;sup&gt;2&lt;/sup&gt; || EC || 16 bit, H8S family || ? || Source: [http://www.thinkwiki.org/wiki/Embedded_Controller_Chips], [http://www.thinkwiki.org/wiki/Embedded_Controller_Firmware], [http://forum.thinkpads.com/viewtopic.php?t=20958]<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://eu.renesas.com/ Renesas] || H8S/64F3169ATE10&lt;sup&gt;2&lt;/sup&gt; || EC || 16 bit, H8S family || ? || &amp;mdash;<br /> <br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.national.com NSC] || PC87570 || EC &amp; Super I/O || ? || ? || &amp;mdash;<br /> <br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://www.smsc.com/ SMSC] || FDC37N958FR || EC &amp; Super I/O || ? || ? || &amp;mdash;<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://www.smsc.com/ SMSC] || LPC47N252 || EC &amp; Super I/O || ? || ? || &amp;mdash;<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://www.smsc.com/ SMSC] || [http://www.smsc.com/index.php?tid=252&amp;pid=173 MEC1308] || EC || 8bit, 8051 core || ? || &amp;mdash;<br /> |- bgcolor=&quot;#dddddd&quot;<br /> | [http://www.smsc.com/ SMSC] || [http://www.smsc.com/index.php?tid=252&amp;pid=172 KBC1122/KBC1122P] || EC &amp; Super I/O || 8bit, 8051 core || ? || &amp;mdash;<br /> <br /> |- bgcolor=&quot;#eeeeee&quot;<br /> | [http://www.sst.com/ SST] || [http://www.sst.com/about_sst/news/detail.dot?crumbTitle=NewsDetail&amp;id=320 SST79LF008] || EC &amp; Super I/O &amp; BIOS flash || 8bit, 8051 core || ? || &amp;mdash;<br /> <br /> |}<br /> <br /> &lt;small&gt;<br /> &lt;sup&gt;1&lt;/sup&gt; Previously Mitsubishi, now Renesas.&lt;br /&gt;<br /> &lt;sup&gt;2&lt;/sup&gt; Previously Hitachi, now Renesas.&lt;br /&gt;<br /> &lt;sup&gt;3&lt;/sup&gt; Previously National (NSC), then Winbond, now Nuvoton.&lt;br /&gt;<br /> &lt;sup&gt;4&lt;/sup&gt; Previously Winbond, now Nuvoton.&lt;br /&gt;<br /> &lt;/small&gt;<br /> <br /> == Resources ==<br /> <br /> === ENE KB3310/KB3910/KB3920 ===<br /> <br /> Very common ECs in netbooks are the KB3310, KB3910 and KB3920 from [http://www.ene.com.tw/en/index.asp ENE Technology]. The ENE ECs are 8051 based.<br /> <br /> The Quanta IL1 reference design seems to use ENE3310 controller. The q1d25i.rom was examined. The EC code is on 0xFFF00000 on One Mini A110. Its 64KB big HOLE0.ROM.<br /> <br /> More discussion and info on the ENE ECs: <br /> <br /> * [http://wiki.laptop.org/images/a/ab/KB3700-ds-01.pdf ENE KB3700 datasheet].<br /> * [http://forum.eeeuser.com/viewtopic.php?pid=99076 eeeUser Discussion] <br /> * [http://code.google.com/p/eeetune/wiki/KBMemoryMap Memory map of ENE KB3310]<br /> * [https://sdcc.svn.sourceforge.net/svnroot/sdcc/trunk/ 8051 simulator]<br /> * [http://dev.laptop.org/git?p=projects/olpcflash;a=blob;f=olpcflash.c;hb=HEAD OpenEC Firmware] <br /> * [http://wiki.laptop.org/go/OpenEC OpenEC Project]<br /> * [http://www.cagnulein.com/tmp/eee.c-20080812 Example code] that makes use of the KB3310's &quot;Index IO&quot; access functions.<br /> <br /> === Renesas H8 ===<br /> <br /> Some ECs are H8 based.<br /> <br /> * [http://www.gnuh8.org/ Port of the GNU compiler suite to the H8]<br /> * [http://wunderkis.de/h8-gcc/h8tools.tar.gz H8 bootloader]<br /> * [http://h8300-hms.sourceforge.net/ Sourceforge project for H8/300]<br /> <br /> == Toolchains ==<br /> <br /> TODO<br /> <br /> {{PD-self}}</div>

Hailfinger http://www.coreboot.org/Current_events 2011-02-04T15:06:22Z

<p>Hailfinger: link FOSDEM 2011</p> <hr /> <div>Please contact [[User:Stepan|Stefan Reinauer]], [[User:Rminnich|Ronald Minnich]] or [[User:Stuge|Peter Stuge]] for more information on the events.<br /> <br /> == Upcoming Events ==<br /> <br /> '''2011'''<br /> <br /> * [[FOSDEM 2011]]<br /> * Linux Tag?<br /> <br /> == Past Events ==<br /> <br /> '''2010'''<br /> <br /> * coreboot exhibited at [http://www.linuxtag.org/ LinuxTag 2010] in Berlin on June 9-12, 2010.<br /> * coreboot had its [[FOSDEM 2010|very first DevRoom]] at [http://www.fosdem.org/ FOSDEM] in Brussels on February 6, 2010.<br /> <br /> '''2009'''<br /> <br /> * [[User:Stuge|Peter Stuge]] presented [http://events.ccc.de/congress/2009/Fahrplan/events/3661.en.html coreboot] at [http://events.ccc.de/congress/2009/ the 26th Chaos Communication Congress (26C3)] in Berlin on December 27, 2009.<br /> * [[User:Stuge|Peter Stuge]] presented [http://www.databadge.net/ifsec2009/reg/lin/show_sessions.php coreboot] at [http://www.linux-world.nl/nl-NL/Bezoeker.aspx?sc_lang=en LinuxWorld Conference &amp; Expo] in Utrecht on November 4, 2009.<br /> * [[User:Stuge|Peter Stuge]] presented [https://har2009.org/program/events/210.en.html coreboot] at [https://wiki.har2009.org/page/Main_Page HAR2009] in Vierhouten on August 13, 2009.<br /> * coreboot had a booth at [[LinuxTag 2009|LinuxTag]] in Berlin on June 24-27, 2009.<br /> * [[User:Stuge|Peter Stuge]] presented coreboot at [http://freedomhectaipei.pbworks.com/ FreedomHEC Taipei] on June 11, 2009.<br /> * [[User:Stuge|Peter Stuge]] presented coreboot at [http://goopen2009.friprog.no/ GoOpen 2009] in Oslo on April 16-17, 2009.<br /> * [[User:Stepan|Stefan Reinauer]], [[User:Stuge|Peter Stuge]] and [[User:Ruik|Rudolf Marek]] made a visit at [http://www.embedded-world.de/ embedded world 2009] in Nürnberg on March 3-5.<br /> * [[User:Rminnich|Ron Minnich]] had a [http://scale7x.socallinuxexpo.org/dotorg/coreboot coreboot booth] at the [http://scale7x.socallinuxexpo.org/ Southern California Linux Expo] (SCALE 7x) on February 20-22, 2009.<br /> <br /> '''2008'''<br /> <br /> * [[User:Stuge|Peter Stuge]] presented [http://events.ccc.de/congress/2008/Fahrplan/events/2970.en.html coreboot: Beyond The Final Frontier] and held a coreboot workshop at [http://events.ccc.de/congress/2008/ the 25th Chaos Communication Congress (25C3)] on December 27-30.<br /> * [[User:Stuge|Peter Stuge]] presented coreboot at the [http://www.nluug.nl/events/nj08/ NLUUG Autumn Conference on Mobile Computing] and [http://www.embeddedlinuxconference.com/elc_europe08/ CE Linux Forum - Embedded Linux conference Europe 2008] on November 6-7.<br /> * [[User:Rminnich|Ronald Minnich]], [[User:Stuge|Peter Stuge]] and [[User:Stepan|Stefan Reinauer]] presented coreboot in a [[Screenshots#Google_Tech_Talks_2008:_coreboot_.28aka_LinuxBIOS.29:_The_Free.2FOpen-Source_x86_Firmware|Google TechTalk]] on October 30.<br /> * [[User:Stuge|Peter Stuge]] presented [http://fscons.org/events/?action=event&amp;id=32 coreboot] at the [http://fscons.org/ Free Society Conference and Nordic Summit 2008] on October 24-26.<br /> * [[User:Stuge|Peter Stuge]] presented coreboot at the [http://slackathon.se/2008/ Slackathon 2008] OpenBSD meeting in September.<br /> * Coreboot was exhibiting at [[LinuxTag 2008]] in Berlin on May 28-31.<br /> * The [[Coreboot Symposium 2008|coreboot symposium 2008]] was held in Denver, April 3 – 5, 2008 during the High Performance Computer Science Week [http://www.hpcsw.org HPCSW].<br /> <br /> '''2007'''<br /> <br /> * There was a [[News#2007.2F05.2F23_LinuxBIOS_booth_at_LinuxTag_in_Berlin.2C_29.2F5-2.2F6|LinuxBIOS booth at the LinuxTag in Berlin, May 29 - June 6, 2007]], as well as a hands-on workshop by Peter Stuge.<br /> * Ron Minnich gave [http://www.fosdem.org/2007/schedule/events/linuxbios a talk about LinuxBIOS] on February 24, 2007 at [http://www.fosdem.org/2007/ FOSDEM 2007].<br /> <br /> '''2006'''<br /> <br /> * The [[LinuxBIOS Symposium 2006]] took place on October 1-3, 2006 in Hamburg, Germany.<br /> <br /> '''2005'''<br /> <br /> * The [[LinuxBIOS Summit 2005]] took place on October 11-13 in Santa Fe, NM.</div>

Hailfinger http://www.coreboot.org/FOSDEM_2011 2011-02-04T14:47:56Z

<p>Hailfinger: /* coreboot+flashrom lightning talks */</p> <hr /> <div>== Time and Place ==<br /> <br /> Saturday and Sunday, 5th and 6th of February 2011, at FOSDEM2011 in Brussels, Belgium.<br /> <br /> == FOSDEM? ==<br /> <br /> [http://www.fosdem.org FOSDEM] is simply the biggest free software developers event in Europe. For the last 11 years, on one weekend in February, a campus from the Brussels Free University gets raided by some 5000 open source developers and enthusiasts. There are main tracks with high profile talks, there are project specific devrooms with talks and hands on session, there are booths, and all of it is free (although donations are appreciated).<br /> <br /> == coreboot+flashrom talks ==<br /> <br /> Sat 14:00-14:15 [http://fosdem.org/2011/schedule/event/coreboot Coreboot: x86 system boot and initialization] Rudolf Marek, Room Ferrer (Lightning talks)<br /> <br /> Sat 14:20-14:35 [http://fosdem.org/2011/schedule/event/flashrom flashrom: Run your BIOS/EFI/firmware updates under any free OS] Carl-Daniel Hailfinger, Room Ferrer (Lightning talks)<br /> <br /> Sun 14:00-14:30 [http://fosdem.org/2011/schedule/event/ram Cold boot attacks on RAM readout] Carl-Daniel Hailfinger, Room Lameere (Embedded devroom)<br /> <br /> Sun 14:30-15:00 [http://fosdem.org/2011/schedule/event/fast_x86_boot Really fast x86 boot] Rudolf Marek, Room Lameere (Embedded devroom)<br /> <br /> == coreboot+flashrom booth/stand ==<br /> <br /> coreboot+flashrom have a joint booth at FOSDEM, AW building, booth 08. Please stop by.<br /> <br /> == Organizational info ==<br /> <br /> See [[Talk:FOSDEM 2011]]</div>

Hailfinger http://www.coreboot.org/FOSDEM_2011 2011-02-04T14:44:56Z

<p>Hailfinger: /* coreboot+flashrom booth/stand */</p> <hr /> <div>== Time and Place ==<br /> <br /> Saturday and Sunday, 5th and 6th of February 2011, at FOSDEM2011 in Brussels, Belgium.<br /> <br /> == FOSDEM? ==<br /> <br /> [http://www.fosdem.org FOSDEM] is simply the biggest free software developers event in Europe. For the last 11 years, on one weekend in February, a campus from the Brussels Free University gets raided by some 5000 open source developers and enthusiasts. There are main tracks with high profile talks, there are project specific devrooms with talks and hands on session, there are booths, and all of it is free (although donations are appreciated).<br /> <br /> == coreboot+flashrom lightning talks ==<br /> <br /> [http://fosdem.org/2011/schedule/event/coreboot Coreboot: x86 system boot and initialization] Saturday 14:00-14:15, Rudolf Marek, Room Ferrer (Lightning talks)<br /> <br /> [http://fosdem.org/2011/schedule/event/flashrom flashrom: Run your BIOS/EFI/firmware updates under any free OS] Saturday 14:20-14:35, Carl-Daniel Hailfinger, Room Ferrer (Lightning talks)<br /> <br /> == coreboot+flashrom booth/stand ==<br /> <br /> coreboot+flashrom have a joint booth at FOSDEM, AW building, booth 08. Please stop by.<br /> <br /> == Organizational info ==<br /> <br /> See [[Talk:FOSDEM 2011]]</div>

Hailfinger http://www.coreboot.org/FOSDEM_2011 2011-02-04T14:41:11Z

<p>Hailfinger: /* coreboot+flashrom lightning talks */ names</p> <hr /> <div>== Time and Place ==<br /> <br /> Saturday and Sunday, 5th and 6th of February 2011, at FOSDEM2011 in Brussels, Belgium.<br /> <br /> == FOSDEM? ==<br /> <br /> [http://www.fosdem.org FOSDEM] is simply the biggest free software developers event in Europe. For the last 11 years, on one weekend in February, a campus from the Brussels Free University gets raided by some 5000 open source developers and enthusiasts. There are main tracks with high profile talks, there are project specific devrooms with talks and hands on session, there are booths, and all of it is free (although donations are appreciated).<br /> <br /> == coreboot+flashrom lightning talks ==<br /> <br /> [http://fosdem.org/2011/schedule/event/coreboot Coreboot: x86 system boot and initialization] Saturday 14:00-14:15, Rudolf Marek, Room Ferrer (Lightning talks)<br /> <br /> [http://fosdem.org/2011/schedule/event/flashrom flashrom: Run your BIOS/EFI/firmware updates under any free OS] Saturday 14:20-14:35, Carl-Daniel Hailfinger, Room Ferrer (Lightning talks)<br /> <br /> == coreboot+flashrom booth/stand ==<br /> <br /> coreboot+flashrom will have a joint booth at FOSDEM this year.<br /> <br /> === Schedule ===<br /> <br /> * Sat 14h00 -- Coreboot: x86 system boot and initialization (Rudolf Marek)<br /> * Sat 14h20 -- flashrom: Run your BIOS/EFI/firmware updates under any free OS (Carl-Daniel Hailfinger) <br /> * XXX Cold boot attacks on RAM readout (Carl-Daniel Hailfinger)<br /> <br /> == Organizational info ==<br /> <br /> See [[Talk:FOSDEM 2011]]</div>

Hailfinger http://www.coreboot.org/FOSDEM_2011 2011-02-04T14:40:27Z

<p>Hailfinger: /* coreboot+flashrom lightning talks */ links to lightning talks</p> <hr /> <div>== Time and Place ==<br /> <br /> Saturday and Sunday, 5th and 6th of February 2011, at FOSDEM2011 in Brussels, Belgium.<br /> <br /> == FOSDEM? ==<br /> <br /> [http://www.fosdem.org FOSDEM] is simply the biggest free software developers event in Europe. For the last 11 years, on one weekend in February, a campus from the Brussels Free University gets raided by some 5000 open source developers and enthusiasts. There are main tracks with high profile talks, there are project specific devrooms with talks and hands on session, there are booths, and all of it is free (although donations are appreciated).<br /> <br /> == coreboot+flashrom lightning talks ==<br /> <br /> [http://fosdem.org/2011/schedule/event/coreboot Coreboot: x86 system boot and initialization] Saturday 14:00-14:15, Room Ferrer (Lightning talks)<br /> <br /> [http://fosdem.org/2011/schedule/event/flashrom flashrom: Run your BIOS/EFI/firmware updates under any free OS] Saturday 14:20-14:35, Room Ferrer (Lightning talks)<br /> <br /> == coreboot+flashrom booth/stand ==<br /> <br /> coreboot+flashrom will have a joint booth at FOSDEM this year.<br /> <br /> === Schedule ===<br /> <br /> * Sat 14h00 -- Coreboot: x86 system boot and initialization (Rudolf Marek)<br /> * Sat 14h20 -- flashrom: Run your BIOS/EFI/firmware updates under any free OS (Carl-Daniel Hailfinger) <br /> * XXX Cold boot attacks on RAM readout (Carl-Daniel Hailfinger)<br /> <br /> == Organizational info ==<br /> <br /> See [[Talk:FOSDEM 2011]]</div>

Hailfinger http://www.coreboot.org/Talk:FOSDEM_2011 2011-02-01T23:41:28Z

<p>Hailfinger: /* Who brings what */</p> <hr /> <div>== Useful info ==<br /> <br /> Question:<br /> Is there a limit for the power we can draw at our booth? The coreboot/flashrom projects have a joint booth and we have lots of hardware for demos, and some of that hardware is a bit hungry... the number of outlets is not a problem for us, we have our own multi-socket extender.<br /> <br /> Answer:<br /> In that case, please bring a sufficiently long extension cord so we can hook you up directly to the power distribution cabinets in the hallway. I'm not sure how much they can cope with, it's all ULB infrastructure, but I suppose it should be enough :)<br /> <br /> <br /> == Who brings what ==<br /> <br /> * carldani<br /> ** 1x Schuko multi-outlet power strip with 10 sockets and CEE 7/7 hybrid Schuko/French plug<br /> ** long power cable (length TBD)<br /> * ruik<br /> ** 1x LCD monitor<br /> ** 1x usb2serial + serial cable<br /> ** 1x PSU 400W<br /> ** 1x Asus M2V-MX SE + CPU + RAM<br /> ** 1x Asrock 939A785GMH/128M + CPU + RAM<br /> ** 1x IDE system HDD + CABLE<br /> ** 1x SATA hdd (no system so far)<br /> ** 1x POST card<br /> ** 1x CDROM IDE<br /> ** couple of SPI flash chips (1M winbonds some 512KB AMICs)<br /> ** 1x PS2 keyboard and mouse + usb2ps2<br /> * Svens<br /> ** Thinkpad X60s running coreboot <br /> * mbertens<br /> ** Nokia IP530 coreboot development machine <br /> ** Nokia IP330 <br /> ** Some Compact PCI cards<br /> <br /> == Hotel ==<br /> <br /> We mostly stay in http://www.booking.com/hotel/be/hibrusselscc.html?aid=304142;label=postbooking_confemail<br /> <br /> So far we know that following Coreboot fellows stays there:<br /> <br /> * Ruik (plus 2 colleagues Pavel and Milan)<br /> * CareBear<br /> * Carldani<br /> * Svens<br /> * MBertens</div>

Hailfinger http://www.coreboot.org/Talk:FOSDEM_2011 2011-01-08T15:39:12Z

<p>Hailfinger: Initial page skeleton</p> <hr /> <div>== Useful info ==<br /> <br /> Question:<br /> Is there a limit for the power we can draw at our booth? The coreboot/flashrom projects have a joint booth and we have lots of hardware for demos, and some of that hardware is a bit hungry... the number of outlets is not a problem for us, we have our own multi-socket extender.<br /> <br /> Answer:<br /> In that case, please bring a sufficiently long extension cord so we can hook you up directly to the power distribution cabinets in the hallway. I'm not sure how much they can cope with, it's all ULB infrastructure, but I suppose it should be enough :)<br /> <br /> <br /> == Who brings what ==<br /> <br /> * Schuko multi-outlet power strip with 10 sockets and CEE 7/7 hybrid Schuko/French plug (carldani)</div>

Hailfinger http://www.coreboot.org/FOSDEM_2011 2011-01-08T15:26:26Z

<p>Hailfinger: Initial page skeleton</p> <hr /> <div>== Time and Place ==<br /> <br /> Saturday and Sunday, 5th and 6th of February 2011, at FOSDEM2011 in Brussels, Belgium.<br /> <br /> == FOSDEM? ==<br /> <br /> [http://www.fosdem.org FOSDEM] is simply the biggest free software developers event in Europe. For the last 11 years, on one weekend in February, a campus from the Brussels Free University gets raided by some 5000 open source developers and enthusiasts. There are main tracks with high profile talks, there are project specific devrooms with talks and hands on session, there are booths, and all of it is free (although donations are appreciated).<br /> <br /> == coreboot+flashrom lightning talks ==<br /> <br /> coreboot will have a lightning talk, time TBA<br /> <br /> flashrom will have a lightning talk, time TBA<br /> <br /> == coreboot+flashrom booth/stand ==<br /> <br /> coreboot+flashrom will have a joint booth at FOSDEM this year.<br /> <br /> === Schedule ===<br /> <br /> TBA<br /> <br /> == Organizational info ==<br /> <br /> See [[Talk:FOSDEM 2011]]</div>

Hailfinger http://www.coreboot.org/Datasheets 2011-01-01T23:58:14Z

<p>Hailfinger: /* AMD SB800 */ Update wanted document number</p> <hr /> <div>This page lists '''publically available datasheets''' and programming guides from various vendors. It includes CPU, chipset, Super I/O, and many other datasheets.<br /> <br /> = x86 architecture =<br /> <br /> == AMD ==<br /> <br /> AMD provides their [http://support.amd.com/us/psearch/Pages/psearch.aspx?type=2.1&amp;product=5.7&amp;contentType=Tech+Doc+Processor&amp;ostype=&amp;keywords=&amp;items=20 AMD64 Architecture and Software manuals], which are a very useful reference for AMD systems, of course (but also explain lots of non-AMD-specific x86 stuff too):<br /> <br /> * [http://support.amd.com/us/Processor_TechDocs/24592.pdf Volume 1: Application Programming]<br /> * [http://support.amd.com/us/Processor_TechDocs/24593.pdf Volume 2: System Programming 24593]<br /> * [http://support.amd.com/us/Processor_TechDocs/24594.pdf Volume 3: General-Purpose and System Instructions]<br /> * [http://support.amd.com/us/Processor_TechDocs/26568.pdf Volume 4: 128-Bit Media Instructions]<br /> * [http://support.amd.com/us/Processor_TechDocs/26569.pdf Volume 5: 64-Bit Media and x87 Floating-Point Instructions]<br /> * [http://support.amd.com/us/Processor_TechDocs/43479.pdf Volume 6: 128-Bit and 256-Bit XOP and FMA4 Instructions]<br /> <br /> Other AMD documents:<br /> * [http://support.amd.com/us/Processor_TechDocs/43724.pdf Lightweight Profiling Specification]<br /> * [http://support.amd.com/us/Processor_TechDocs/34434-IOMMU-Rev_1.26_2-11-09.pdf AMD I/O Virtualization Technology (IOMMU) Specification]<br /> * [http://support.amd.com/us/Processor_TechDocs/32200.pdf Open Platform Management Architecture Specification]<br /> * [http://support.amd.com/us/Processor_TechDocs/25481.pdf CPUID Specification]<br /> * [http://support.amd.com/us/Processor_TechDocs/41918.pdf Advanced Platform Management Link (APML) Specification]<br /> <br /> == Intel ==<br /> <br /> Intel provides their [http://developer.intel.com/products/processor/manuals/index.htm Intel&amp;reg; 64 and IA-32 Architectures Software Developer's Manuals] which are a very useful reference to the x86 architecture in general:<br /> <br /> * [http://developer.intel.com/Assets/PDF/manual/253665.pdf Volume 1: Basic Architecture]<br /> * [http://developer.intel.com/Assets/PDF/manual/253666.pdf Volume 2A: Instruction Set Reference, A-M]<br /> * [http://developer.intel.com/Assets/PDF/manual/253667.pdf Volume 2B: Instruction Set Reference, N-Z]<br /> * [http://developer.intel.com/Assets/PDF/manual/253668.pdf Volume 3A: System Programming Guide]<br /> * [http://developer.intel.com/Assets/PDF/manual/253669.pdf Volume 3B: System Programming Guide]<br /> * [http://www.intel.com/Assets/PDF/manual/252046.pdf Intel® 64 and IA-32 Architectures Software Developer's Manual Documentation Changes]<br /> <br /> Other Intel documents:<br /> <br /> * [http://www.intel.com/Assets/PDF/manual/318148.pdf Intel® 64 Architecture x2APIC Specification]<br /> * [http://www.intel.com/Assets/PDF/manual/248966.pdf Intel® 64 and IA-32 Architectures Optimization Reference Manual]<br /> * [http://www.intel.com/Assets/PDF/manual/323640.pdf Intel® Carry-Less Multiplication Instruction and its Usage for Computing the GCM Mode White Paper]<br /> * [http://www.intel.com/Assets/PDF/manual/323641.pdf Intel® Advanced Encryption Standard New Instructions (Intel® AES-NI) Set White Paper]<br /> * [http://www.intel.com/Assets/PDF/manual/323850.pdf Intel® Virtualization Technology FlexMigration (Intel® VT FlexMigration) Application Note]<br /> <br /> = CPU =<br /> <br /> == AMD ==<br /> <br /> === AMD Fam11h ===<br /> <br /> * [http://support.amd.com/us/Processor_TechDocs/41256.pdf BIOS and Kernel Developer's Guide (BKDG) for AMD Family 11h Processors]<br /> ** [http://support.amd.com/us/Processor_TechDocs/41788.pdf Revision Guide for AMD Family 11h Processors]<br /> ** [http://support.amd.com/us/Processor_TechDocs/43373.pdf AMD Family 11h Processor Power and Thermal Data Sheet for Notebooks]<br /> <br /> Turion64:<br /> * [http://support.amd.com/us/Processor_TechDocs/32816.pdf AMD Turion™ 64 Mobile Technology Product Data Sheet]<br /> * [http://support.amd.com/us/Processor_TechDocs/41407.pdf AMD Turion™ 64 X2 Mobile Technology Dual-Core Processor Product Data Sheet]<br /> <br /> Athlon64:<br /> * [http://support.amd.com/us/Processor_TechDocs/30430.pdf AMD Athlon™ Processor Power and Thermal Data Sheet]<br /> <br /> === AMD Fam10h ===<br /> <br /> * [http://support.amd.com/us/Processor_TechDocs/31116.pdf BIOS and Kernel Developer’s Guide (BKDG) For AMD Family 10h]<br /> ** [http://support.amd.com/us/Processor_TechDocs/41322.pdf Revision Guide for AMD Family 10h Processors]<br /> * [http://support.amd.com/us/Processor_TechDocs/40546-PUB-Optguide_3-11_5-21-09.pdf Software Optimization Guide for AMD Family 10h Processors]<br /> * [http://support.amd.com/us/Processor_TechDocs/43374.pdf AMD Family 10h Server and Workstation Processor Power and Thermal Data Sheet]<br /> * [http://support.amd.com/us/Processor_TechDocs/43375.pdf AMD Family 10h Desktop Processor Power and Thermal Data Sheet]<br /> <br /> Opteron:<br /> * [http://support.amd.com/us/Processor_TechDocs/40036.pdf Family 10h AMD Opteron Processor Product Data Sheet]<br /> <br /> Phenom:<br /> * [http://support.amd.com/us/Processor_TechDocs/44109.pdf Family 10h AMD Phenom&amp;trade; Processor Product Data Sheet]<br /> * [http://support.amd.com/us/Processor_TechDocs/46878.pdf Family 10h AMD Phenom&amp;trade; II Processor Product Data Sheet]<br /> <br /> === AMD K8 ===<br /> <br /> Athlon64/Opteron:<br /> * [http://support.amd.com/us/Processor_TechDocs/26094.PDF BIOS and Kernel Developer's Guide for AMD Athlon&amp;trade; and AMD Opteron&amp;trade; Processors]<br /> ** [http://support.amd.com/us/Processor_TechDocs/25759.pdf Revision Guide for AMD Athlon&amp;trade; and AMD Opteron&amp;trade; Processors]<br /> ** [http://support.amd.com/us/Processor_TechDocs/26633_5649.pdf AMD Athlon&amp;trade; and AMD Opteron&amp;trade; Processors Thermal Design Guide]<br /> * [http://support.amd.com/us/Processor_TechDocs/40555.pdf Performance Guidelines for AMD Athlon&amp;trade; and AMD Opteron&amp;trade; ccNUMA Multiprocessor Systems]<br /> * [http://support.amd.com/us/Processor_TechDocs/24707_PUB.PDF Clock Generator Specification for AMD Athlon&amp;trade; and AMD Opteron&amp;trade; Processors]<br /> <br /> Opteron:<br /> * [http://support.amd.com/us/Processor_TechDocs/23932.pdf AMD Opteron&amp;trade; Processor Product Data Sheet]<br /> ** [http://support.amd.com/us/Processor_TechDocs/30417.pdf AMD Opteron&amp;trade; Processor Power and Thermal Data Sheet]<br /> * [http://support.amd.com/us/Processor_TechDocs/40820_PUB_AMD_Opteron_Processor_Production_Notice_rev_3_08.pdf AMD Opteron&amp;trade; x52 and x54 Production Notice]<br /> * [http://support.amd.com/us/Processor_TechDocs/30925.pdf Builders Guide for AMD Opteron&amp;trade; Processor-Based Servers and Workstations]<br /> * [http://support.amd.com/us/Processor_TechDocs/33340.pdf AMD Opteron&amp;trade; Multiprocessor Systems Running Linux Technical Bulletin for AMD OEMs and Partners]<br /> <br /> Family 0Fh:<br /> * [http://support.amd.com/us/Processor_TechDocs/32559.pdf BIOS and Kernel Developer's Guide for AMD NPT Family 0Fh Processors]<br /> ** [http://support.amd.com/us/Processor_TechDocs/33610.pdf Revision Guide for AMD NPT Family 0Fh Processors]<br /> ** [http://support.amd.com/us/Processor_TechDocs/31119.pdf AMD NPT Family 0Fh Processor Electrical Data Sheet]<br /> * [http://support.amd.com/us/Processor_TechDocs/33954.pdf AMD NPT Family 0Fh Desktop Processor Power and Thermal Data Sheet]<br /> <br /> === Athlon64 ===<br /> <br /> * [http://support.amd.com/us/Processor_TechDocs/24659.pdf AMD Athlon™ Processor Product Data Sheet]<br /> ** [http://support.amd.com/us/Processor_TechDocs/30430.pdf AMD Athlon™ Processor Power and Thermal Data Sheet]<br /> ** [http://support.amd.com/us/Processor_TechDocs/31783.pdf AMD Athlon™ Processor Competitive Performance Guide]<br /> * [http://support.amd.com/us/Processor_TechDocs/43042.pdf AMD Athlon™ X2 Dual-Core Processor Product Data Sheet]<br /> ** [http://support.amd.com/us/Processor_TechDocs/33425.pdf AMD Athlon™ X2 Dual-Core Processor Product Data Sheet] (ver 3.10, 1/21/2007)<br /> ** [http://support.amd.com/us/Processor_TechDocs/42989.pdf AMD Athlon™ X2 Dual-Core Processor for Notebooks Product Data Sheet]<br /> * [http://support.amd.com/us/Processor_TechDocs/30431.pdf AMD Athlon™ FX Processor Product Data Sheet]<br /> ** [http://support.amd.com/us/Processor_TechDocs/31366.pdf AMD Athlon™ FX-60 Processor Competitive Performance Guide]<br /> * [http://support.amd.com/us/Processor_TechDocs/31225.pdf Mobile AMD Athlon™ Processor 3400+ Competitive Performance Guide]<br /> * [http://support.amd.com/us/Processor_TechDocs/31684.pdf Builder's Guide for AMD Athlon™ Processor-Based Desktops and Workstations]<br /> <br /> === Athlon (32bit) ===<br /> <br /> * [http://support.amd.com/us/Processor_TechDocs/21016.pdf AMD Athlon™ Processor Module Data Sheet] (rev. M-0, 5/31/2000)<br /> ** [http://support.amd.com/us/Processor_TechDocs/22054.pdf AMD Athlon™ Processor Technical Brief]<br /> * [http://support.amd.com/us/Processor_TechDocs/26237.PDF AMD Athlon™ XP Processor Model 10 Data Sheet]<br /> ** [http://support.amd.com/us/Processor_TechDocs/27375.pdf AMD Athlon XP Processor Model 10 with 256K L2 Cache]<br /> ** [http://support.amd.com/us/Processor_TechDocs/27532.pdf AMD Athlon™ Processor Model 10 Revision Guide]<br /> ** [http://support.amd.com/us/Processor_TechDocs/26426.PDF AMD Athlon™ MP Processor Model 10 Data Sheet for Multiprocessor Platforms]<br /> * [http://support.amd.com/us/Processor_TechDocs/25175.pdf AMD Athlon™ XP Processor Model 8 Data Sheet]<br /> ** [http://support.amd.com/us/Processor_TechDocs/25703.pdf AMD Athlon™ Processor Model 8 Revision Guide]<br /> ** [http://support.amd.com/us/Processor_TechDocs/25722.pdf AMD Athlon™ MP Processor Model 8 Data Sheet for Multiprocessor Platforms]<br /> * [http://support.amd.com/us/Processor_TechDocs/24685.pdf AMD Athlon™ MP Processor Model 6 Data Sheet]<br /> ** [http://support.amd.com/us/Processor_TechDocs/24309.pdf AMD Athlon™ XP Processor Model 6 Data Sheet]<br /> ** [http://support.amd.com/us/Processor_TechDocs/24332.pdf AMD Athlon™ Processor Model 6 Revision Guide]<br /> ** [http://support.amd.com/us/Processor_TechDocs/25480.pdf AMD Athlon™ MP Processor Model 6 OPGA Data Sheet for Multiprocessor Platforms]<br /> * [http://support.amd.com/us/Processor_TechDocs/23792.pdf AMD Athlon™ Processor Model 4 Data Sheet]<br /> ** [http://support.amd.com/us/Processor_TechDocs/23614.pdf AMD Athlon™ Processor Model 4 Revision Guide]<br /> * [http://support.amd.com/us/Processor_TechDocs/22651.pdf AMD Athlon™ Processor Voltage Regulation Application Note]<br /> * [http://support.amd.com/us/Processor_TechDocs/23811.pdf AMD Athlon™ Processor Module Signal and Power-Up Requirements Application Note]<br /> * [http://support.amd.com/us/Processor_TechDocs/25823.pdf Builder’s Guide for 2P Capable Servers and Workstations]<br /> * [http://support.amd.com/us/Processor_TechDocs/25325.pdf System Considerations for Dual AMD Athlon™ MP Processors in Tower and 1U Form Factors]<br /> * [http://support.amd.com/us/Processor_TechDocs/24387.pdf One Page AMD Athlon™ and AMD Duron™ Processor-Based System Build Checklist]<br /> * [http://support.amd.com/us/Processor_TechDocs/24228.pdf Methodologies for Measuring Temperature on AMD Athlon™ and AMD Duron™ Processors]<br /> * [http://support.amd.com/us/Processor_TechDocs/22007.pdf AMD Athlon™ Processor x86 Code Optimization Guide]<br /> <br /> === Sempron ===<br /> <br /> * [http://support.amd.com/us/Processor_TechDocs/31805.pdf AMD Sempron™ Processor Product Data Sheet]<br /> * [http://support.amd.com/us/Processor_TechDocs/31994.pdf AMD Sempron™ Processor Model 10 with 256K L2 Cache Data Sheet]<br /> * [http://support.amd.com/us/Processor_TechDocs/31993.pdf AMD Sempron™ Processor Model 10 Data Sheet]<br /> * [http://support.amd.com/us/Processor_TechDocs/31693.pdf AMD Sempron™ Processor Model 8 Data Sheet]<br /> <br /> === Duron ===<br /> <br /> * [http://support.amd.com/us/Processor_TechDocs/TN13.pdf AMD Duron™ Processor Rev. A0: CPUID Reporting of L2 Cache Size]<br /> * [http://support.amd.com/us/Processor_TechDocs/25848.PDF AMD Duron™ Processor Model 8 Data Sheet]<br /> * [http://support.amd.com/us/Processor_TechDocs/24310.pdf AMD Duron™ Processor Model 7 Data Sheet]<br /> ** [http://support.amd.com/us/Processor_TechDocs/24806.pdf AMD Duron™ Processor Model 7 Revision Guide]<br /> * [http://support.amd.com/us/Processor_TechDocs/23802.pdf AMD Duron™ Processor Model 3 Data Sheet]<br /> ** [http://support.amd.com/us/Processor_TechDocs/23865.pdf AMD Duron™ Processor Model 3 Revision Guide]<br /> * [http://support.amd.com/us/Processor_TechDocs/24387.pdf One Page AMD Athlon™ and AMD Duron™ Processor-Based System Build Checklist]<br /> <br /> === Socket specs ===<br /> <br /> * [http://support.amd.com/us/Processor_TechDocs/25766.pdf AMD Socket 940 Design Specification]<br /> ** [http://support.amd.com/us/Processor_TechDocs/31412.pdf AMD Functional Data Sheet, 940 Pin Package]<br /> ** [http://support.amd.com/us/Processor_TechDocs/30353.pdf AMD Socket 940 Qualification Plan]<br /> * [http://support.amd.com/us/Processor_TechDocs/31700.pdf Socket F (1207) Design Specification]<br /> ** [http://support.amd.com/us/Processor_TechDocs/32800.pdf Thermal Design Guide for Socket F (1207) Processors]<br /> * [http://support.amd.com/us/Processor_TechDocs/31875.pdf Socket AM2 Design Specification]<br /> * [http://support.amd.com/us/Processor_TechDocs/40523.pdf Socket AM3 Design Specification]<br /> * [http://support.amd.com/us/Processor_TechDocs/31839.pdf Low-Profile Socket S1 Design Specification]<br /> * [http://support.amd.com/us/Processor_TechDocs/31410.pdf AMD Functional Data Sheet, 754 Pin Package]<br /> ** [http://support.amd.com/us/Processor_TechDocs/24850.PDF Socket 754 Design and Qualification Requirements]<br /> * [http://support.amd.com/us/Processor_TechDocs/31411.pdf AMD Functional Data Sheet, 939-Pin Package]<br /> * [http://support.amd.com/us/Processor_TechDocs/23986.pdf Socket A AMD Processor and Heatsink Installation Guide]<br /> <br /> === Misc ===<br /> <br /> * [http://support.amd.com/us/Processor_TechDocs/20734.pdf AMD Processor Recognition Application Note]<br /> * [http://support.amd.com/us/Processor_TechDocs/22466.pdf AMD Extensions to the 3DNow!™ and MMX™ Instruction Sets Manual]<br /> * [http://support.amd.com/us/Processor_TechDocs/21928.pdf 3DNow!™Technology Manual]<br /> ** [http://support.amd.com/us/Processor_TechDocs/22621.pdf 3DNow!™ Instruction Porting Guide Application Note]<br /> * [http://support.amd.com/us/Processor_TechDocs/23794.pdf AMD Thermal, Mechanical, and Chassis Cooling Design Guide]<br /> * [http://support.amd.com/us/Processor_TechDocs/30579_3_74.pdf AMD Processor Performance Evaluation Guide]<br /> * [http://support.amd.com/us/Processor_TechDocs/32035.pdf Compiler Usage Guidelines for AMD64 Platforms Application Note]<br /> * [http://support.amd.com/us/Processor_TechDocs/25112.PDF Software Optimization Guide for AMD64 Processors]<br /> * [http://support.amd.com/us/Processor_TechDocs/26951.pdf Thermal Interface Material Comparison: Thermal Pads vs. Thermal Grease]<br /> * [http://support.amd.com/us/Processor_TechDocs/26003.pdf Builders Guide for Desktop/Tower Systems]<br /> * [http://support.amd.com/us/Processor_TechDocs/26698.pdf Linux Kernel Issue with Systems Using AGP Graphics]<br /> * [http://support.amd.com/us/Processor_TechDocs/32979.pdf Microsoft&amp;reg; Windows&amp;reg; XP and Windows&amp;reg; Server 2003 Processor Speed Reporting]<br /> * [http://support.amd.com/us/Processor_TechDocs/30887.pdf Building AMD64 Applications with the Microsoft Platform SDK]<br /> * [http://support.amd.com/us/Processor_TechDocs/30888.pdf Creating an AMD64 Build Enviroment for DirectX-Based Applations]<br /> * [http://support.amd.com/us/Processor_TechDocs/33609.pdf Processor Utilization with Microsoft&amp;reg; Windows&amp;reg; Media Center Edition on Systems Enabled with Cool'n'Quiet&amp;trade; and AMD PowerNow&amp;trade; Technologies]<br /> * [http://support.amd.com/us/Processor_TechDocs/32979.pdf Microsoft® Windows® XP and Windows® Server 2003 Processor Speed Reporting]<br /> * [http://support.amd.com/us/Processor_TechDocs/tn17.pdf Microsoft Windows® 2000 Patch for AGP Applications on AMD Athlon™ and AMD Duron™ Processors]<br /> <br /> == Intel ==<br /> <br /> === Intel Pentium III ===<br /> <br /> * [http://www.intel.com/p/en_US/support/highlights/processors/pentiumiii Highlights/Overview]<br /> * [http://ark.intel.com/ProductCollection.aspx?familyID=590&amp;MarketSegment=DT List of Pentium III models, steppings, etc.]<br /> * [http://www.intel.com/support/processors/pentiumiii/sb/CS-023730.htm Intel® Pentium® III Processor: Datasheets]<br /> ** [http://download.intel.com/support/processors/pentiumiii/sb/24965705.pdf Intel® Pentium® III Processor with 512-KB L2 Cache at 1.13GHz to 1.40 GHz Datasheet] (PDF)<br /> ** [http://download.intel.com/support/processors/pentiumiii/sb/24976503.pdf Intel® Pentium® III Processor Based on 0.13 Micron Process Up to 1.33 GHz Datasheet] (PDF)<br /> ** [http://download.intel.com/support/processors/pentiumiii/sb/24526408.pdf Intel® Pentium® III Processor for the PGA370 Socket at 500 MHz to 1.13 GHz] (PDF)<br /> ** [http://download.intel.com/support/processors/pentiumiii/sb/24445209.pdf Intel® Pentium® III Processor for the SC242 at 450 MHz to 1.0 GHz Datasheet] (PDF)<br /> ** [http://download.intel.com/support/processors/pentiumiii/sb/27367306.pdf Low Voltage Intel® Pentium® III Processor 512-KB] (PDF)<br /> * [http://www.intel.com/design/intarch/specupdt/244453.htm Intel® Pentium® III Processor Specification Update] ([http://download.intel.com/design/intarch/specupdt/24445358.pdf PDF])<br /> <br /> Mobile:<br /> * [http://www.intel.com/p/en_US/support/highlights/processors/pentiumiii-m Highlights/Overview]<br /> * [http://www.intel.com/support/processors/mobile/pentiumiii/sb/CS-023739.htm Mobile Intel® Pentium® III Processor - M Datasheet] ([http://download.intel.com/support/processors/mobile/pentiumiii/sb/29834006.pdf PDF])<br /> * [http://www.intel.com/support/processors/mobile/pentiumiii/sb/CS-023740.htm Mobile Intel® Pentium® III Processor and Mobile Intel® Pentium® III Processor-M Specification Update] ([http://download.intel.com/support/processors/mobile/pentiumiii/sb/24530659.pdf PDF])<br /> * [http://www.intel.com/design/intarch/specupdt/245306.htm Mobile Intel® Pentium® III Processor and Mobile Intel® Pentium® III Processor-M Specification Update] ([http://download.intel.com/design/intarch/specupdt/24530663.pdf PDF])<br /> * [http://developer.intel.com/design/mobile/datashts/245302.htm Mobile Pentium® III Processor in BGA2 and Micro-PGA2 Packages] ([http://download.intel.com/design/mobile/datashts/24530202.pdf PDF])<br /> <br /> Embedded:<br /> * [http://www.intel.com/design/intarch/pentiumiii/docs_pentiumiii.htm Embedded Intel® Architecture Processors: Intel® Pentium® III Processors: Technical Documents]<br /> ** [http://www.intel.com/design/intarch/pentiumiii/docs_pentiumiii_pga370.htm Intel® Pentium® III Processor - PGA370]<br /> ** [http://www.intel.com/design/intarch/pentiumiii/docs_pentiumiii_low.htm Intel® Pentium® III Processor - Low Power]<br /> ** [http://www.intel.com/design/intarch/pentiumiii/docs_pentiumiii_vol.htm Low Voltage Intel® Pentium® III Processor]<br /> <br /> Xeon:<br /> * [http://www.intel.com/p/en_US/support/highlights/processors/pentiumiii-xeon Highlights/Overview]<br /> <br /> == VIA ==<br /> <br /> === VIA Padlock ===<br /> <br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=181&amp;fid=281 Security Application note]<br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=181&amp;fid=261 PadLock Programming Guide]<br /> <br /> = Northbridge =<br /> <br /> == AMD ==<br /> <br /> === AMD RS880 ===<br /> <br /> * [http://support.amd.com/us/Embedded_TechDocs/46143_rs880_BDG_pub_3.00.pdf AMD RS880 Family BIOS Developer's Guide] (BDG)<br /> * [http://support.amd.com/us/Embedded_TechDocs/46141_rs880_rpr_pub_3.00.pdf AMD RS880 Family Register Programming Requirements] (RPR)<br /> * [http://support.amd.com/us/Embedded_TechDocs/46142_rs880_rrg_pub_3.00.pdf AMD RS880 Family Register Reference Guide] (RRG)<br /> <br /> === AMD RD890 ===<br /> <br /> Not public (yet?). However, some of the information may be contained in the public docs in the RS880 section.<br /> <br /> * AMD RD890 BIOS Developer's Guide (Publication #43606)<br /> * AMD RD890 Register Reference Guide (Publication #43607)<br /> <br /> === AMD RS780 ===<br /> <br /> * [http://support.amd.com/us/Embedded_TechDocs/43734_rs780_bdg_pub_1.01.pdf AMD 780G Family BIOS Developer’s Guide] (BDG)<br /> * [http://support.amd.com/us/Embedded_TechDocs/43291_rs780_rpr_pub_1.01.pdf AMD 780G Family Register Programming Requirements] (RPR)<br /> * [http://support.amd.com/us/Embedded_TechDocs/43451_rs780_rrg_pub_1.01.pdf AMD 780G Family Register Reference Guide] (RRG)<br /> * [http://support.amd.com/us/Embedded_TechDocs/45732_rs780e_ds_pub_3.10.pdf AMD 780E Databook]<br /> * [http://support.amd.com/us/Embedded_TechDocs/48319.pdf AMD 780 Product Errata]<br /> <br /> Apparently there are other docs as well, not sure if they provide any additional information or if they are part of the public documents above:<br /> <br /> * AMD RD780 Register Reference Guide<br /> * AMD RX780 Register Reference Guide<br /> * AMD RS780M Hybrid Graphics – System BIOS Detailed Design Document (Publication #44969)<br /> * AMD RD790 Register Programming Requirements (Publication #42462)<br /> * AMD RD790 Register Reference Guide (Publication #42988)<br /> * AMD RD790 BIOS Developer's Guide (Publication #43093)<br /> <br /> === AMD RS690 ===<br /> <br /> * [http://support.amd.com/us/Embedded_TechDocs/43372_rs690_rrg_3.00o.pdf AMD RS690 Register Reference Guide] (RRG)<br /> * [http://support.amd.com/us/ChipsetMotherboard_TechDocs/41977_rs690_ds_3.06.pdf AMD 690G Databook]<br /> * [http://support.amd.com/us/ChipsetMotherboard_TechDocs/41978_rs690m_ds_3.06.pdf AMD M690 Databook (Notebook Solutions)]<br /> * [http://support.amd.com/us/Embedded_TechDocs/42437_m690t_ds_3_08.pdf AMD M690T/M690E Databook]<br /> * [http://support.amd.com/us/ChipsetMotherboard_TechDocs/AMD690Series_LogoGuide.pdf AMD 690 Chipset Logos]<br /> <br /> === Misc ===<br /> <br /> * [http://support.amd.com/us/ChipsetMotherboard_TechDocs/AMD_7-Series_Chipsets_-_Guidelines.pdf AMD 7-Series Chipsets - Guidelines.pdf]<br /> * [http://support.amd.com/us/ChipsetMotherboard_TechDocs/42655A_S1DBM680T_PB.pdf AMD Model S1 DBM690T, Socket S1 and M690T/SB600 Chipset Development Board]<br /> * [http://support.amd.com/us/ChipsetMotherboard_TechDocs/AMDCrossFire_LogoGuide.pdf AMD 480X Chipset Logos]<br /> <br /> == Intel ==<br /> <br /> === Intel Atom Z5xx and SCH US15Wx ===<br /> <br /> * [http://ark.intel.com/ProductCollection.aspx?codeName=24973 Overview of products formerly named Poulsbo]<br /> * [http://edc.intel.com/Platforms/Atom-Z5xx/#hardware Overview: Intel® Atom™ Processor Z5xx Series and Intel® System Controller Hub US15Wx]<br /> ** [http://edc.intel.com/Link.aspx?id=1387 Datasheet: Intel® System Controller Hub (Intel® SCH)] (PDF)<br /> ** [http://edc.intel.com/Link.aspx?id=1905 Datasheet: Intel® System Controller Hub (Intel® SCH) (large form factor)] (PDF)<br /> <br /> === Intel NM10 Express ===<br /> <br /> * [http://www.intel.com/Products/Internet_Device/Chipsets/NM10/NM10-technicaldocuments.htm Overview]<br /> ** [http://www.intel.com/Assets/PDF/datasheet/322896.pdf Intel® NM10 Express Chipset Datasheet]<br /> ** [http://www.intel.com/Assets/PDF/specupdate/322897.pdf Intel® NM10 Express Chipset Specification Update]<br /> <br /> === Intel 860 ===<br /> <br /> * [http://www.intel.com/design/archives/chipsets/860/index.htm Hardware Design: Archives - Intel&amp;reg; 860 Chipset Family Technical Documentation]<br /> ** [http://www.intel.com/design/chipsets/datashts/290713.htm Intel® 860 Chipset: 82860 Memory Controller Hub (MCH) Datasheet]: [http://download.intel.com/design/chipsets/datashts/29071301.pdf PDF]<br /> *** [http://www.intel.com/design/chipsets/specupdt/290715.htm Intel® 860 Chipset: 82860 Memory Controller Hub (MCH) Specification Update]: [http://www.intel.com/design/chipsets/specupdt/29071501.pdf PDF]<br /> ** [http://www.intel.com/design/chipsets/applnots/292269.htm Intel® 860 Chipset Thermal Considerations Application Note (AP-721)]: [http://download.intel.com/design/chipsets/datashts/29071301.pdf PDF]<br /> ** [http://www.intel.com/design/chipsets/designex/298252.htm Intel® Xeon® Processor and Intel® 860 Chipset Platform Design Guide]: [http://download.intel.com/design/chipsets/designex/29825204.pdf PDF]<br /> ** [http://www.intel.com/design/chipsets/designex/298302.htm Intel® 860 Chipset Memory Expansion Card (MEC) Design Guide]: [http://download.intel.com/design/chipsets/designex/29830201.pdf PDF]<br /> ** [http://www.intel.com/design/chipsets/schematics/860_crb.htm Intel 860 Chipset CRB Schematics]: [http://download.intel.com/design/chipsets/schematics/860_crb.pdf PDF]<br /> <br /> === Intel 82815E ===<br /> <br /> * [http://download.intel.com/design/chipsets/datashts/29068801.pdf 82815 Chipset Family]<br /> * [http://download.intel.com/design/chipsets/designex/29823401.pdf 82815E Chipset Platform Design Guide]<br /> * [http://download.intel.com/design/chipsets/designex/29824906.pdf 82815E Chipset Platform Design Guide update]<br /> <br /> === Intel 440BX ===<br /> <br /> * [http://download.intel.com/design/chipsets/datashts/29063301.pdf Datasheet]<br /> * [http://download.intel.com/design/chipsets/datashts/27321903.pdf Electrical and Thermal Timing Specification]<br /> <br /> === Intel 440LX ===<br /> <br /> * [http://download.intel.com/design/chipsets/datashts/29056402.pdf Datasheet]<br /> * [http://www.intel.com/design/chipsets/specupdt/29765505.pdf Spec update]<br /> <br /> == VIA ==<br /> <br /> VIA has a [http://linux.via.com.tw portal] with some source code and datasheets.<br /> <br /> === VIA VX800 ===<br /> <br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=161&amp;fid=241 VIA VX800 Programming Manual]<br /> <br /> === VIA CX700M/VX700 ===<br /> <br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=141&amp;fid=221 VIA CX700M/VX700 Programming Manual]<br /> <br /> = Southbridge =<br /> <br /> == AMD ==<br /> <br /> === AMD SB820M ===<br /> <br /> * [http://support.amd.com/us/Embedded_TechDocs/47283_sb820m_ds_pub_2.00.pdf AMD SB820M Southbridge Databook]<br /> <br /> === AMD SB810/SB850 ===<br /> <br /> * [http://support.amd.com/us/Embedded_TechDocs/44758.pdf AMD SB810/SB850 Southbridge Databook]<br /> <br /> === AMD SB800 ===<br /> <br /> Not available yet, but here are the numbers for the document we'd like to get. (Mentioned in the AMD SB810/850 Southbridge Databook.)<br /> <br /> * AMD SB800-Series Southbridges Register Reference Guide (Publication #45482)<br /> <br /> === AMD SB700/SB710/SB750 ===<br /> <br /> * [http://support.amd.com/us/Embedded_TechDocs/43366_sb7xx_bdg_pub_1.00.pdf AMD SB700/710/750 BIOS Developer’s Guide] (BDG)<br /> * [http://support.amd.com/us/Embedded_TechDocs/43009_sb7xx_rrg_pub_1.00.pdf AMD SB700/710/750 Register Reference Guide] (RRG)<br /> * [http://support.amd.com/us/Embedded_TechDocs/42413_sb7xx_rpr_pub_1.00.pdf AMD SB700/710/750 Register Programming Requirements] (RPR)<br /> * [http://support.amd.com/us/Embedded_TechDocs/45215_sb710_ds_pub_1.25.pdf AMD SB710 Databook]<br /> * [http://support.amd.com/us/Embedded_TechDocs/46837.pdf AMD SB700 Family Product Errata]<br /> <br /> === AMD SB600 ===<br /> <br /> * [http://support.amd.com/us/Embedded_TechDocs/46157_sb600_bdg_pub.3.00.pdf AMD SB600 BIOS Developer's Guide] (BDG)<br /> * [http://support.amd.com/us/Embedded_TechDocs/46155_sb600_rrg_pub_3.03.pdf AMD SB600 Register Reference Manual] (RRG)<br /> * [http://support.amd.com/us/Embedded_TechDocs/46156_sb600_rpr_pub_3.02b.pdf AMD SB600 Register Programming Requirements] (RPR)<br /> * [http://support.amd.com/us/ChipsetMotherboard_TechDocs/42119_sb600_ds_3.05.pdf AMD SB600 Databook] (rev. 3.05)<br /> * [http://support.amd.com/us/Embedded_TechDocs/42119_sb600_ds_pub_3.07.pdf AMD SB600 Databook] (rev. 3.07)<br /> <br /> === AMD 8111 ===<br /> <br /> * [http://support.amd.com/us/ChipsetMotherboard_TechDocs/24674.pdf AMD-8111™ HyperTransport™ I/O Hub Data Sheet]<br /> * [http://support.amd.com/us/ChipsetMotherboard_TechDocs/26036.pdf AMD-8111™ HyperTransport™ I/O Hub Product Brief]<br /> * [http://support.amd.com/us/ChipsetMotherboard_TechDocs/25720.pdf AMD-8111™ HyperTransport™ I/O Hub Revision Guide]<br /> <br /> == Intel ==<br /> <br /> === Intel 82801BA/BAM (ICH2) ===<br /> <br /> * [http://developer.intel.com/design/chipsets/datashts/290687.htm Datasheet]<br /> <br /> = Super I/O =<br /> <br /> == ITE ==<br /> <br /> * [http://www.ite.com.tw/EN/products_kind.aspx?CategoryID=3&amp;ID=5 PC Desktop/Notebook Super I/Os]<br /> ** [http://www.ite.com.tw/EN/products_kind.aspx?CategoryID=3&amp;ID=5 Desktop Super I/Os]<br /> ** [http://www.ite.com.tw/EN/products_kind.aspx?CategoryID=3&amp;ID=6 Notebook Super I/Os]<br /> <br /> == Winbond / Nuvoton ==<br /> <br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/ISASuperIO/ ISA Super I/Os]<br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/LPCSuperIOforDesktopAndServer/ LPC Super I/O for Desktop &amp; Server]<br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/AdvancedSuperIOforDesktop/ Advanced Super I/O for Desktop]<br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/AdvancedSuperIOforNotebook/ Advanced Super I/O for Notebook]<br /> <br /> == Fintek ==<br /> <br /> * [http://www.fintek.com.tw/eng/products.asp?BID=1&amp;SID=17&amp;layer=0 Super Hardware Monitor + SIO]<br /> <br /> == NSC ==<br /> <br /> (bought by Winbond, now Nuvoton)<br /> <br /> == ALi ==<br /> <br /> == SMSC ==<br /> <br /> * [http://www.smsc.com/main/catalog/ioprods.html Products / datasheets overview]<br /> * [http://www.smsc.com/main/datasheet.html Various product datasheets]<br /> <br /> = Other =<br /> <br /> == ACPI ==<br /> <br /> * http://www.acpi.info<br /> <br /> == USB ==<br /> <br /> == Misc ==<br /> <br /> * [http://support.amd.com/us/Pages/techdocs.aspx AMD public documents]<br /> ** The [http://www.amd.com/us/products/embedded/develop-and-design/Pages/processor-chipset-linux-supprt.aspx AMD64 Embedded Processors and Chipset Linux Support] web page features links to supported projects (like coreboot) and links to documentation.<br /> <br /> = Resources =<br /> <br /> There are many datasheet archives on the web which may have other (usually older) datasheets which already disappeared from vendor websites.</div>

Hailfinger http://www.coreboot.org/GCI2010 2010-10-31T00:56:56Z

<p>Hailfinger: point to flashrom.org</p> <hr /> <div>We hope to participate in Google Code-in 2010 (basically Google Summer of code for 13-18 year old students)<br /> <br /> Please note that the task list is not finished, and we will add more tasks once we know how long individual tasks are supposed to take.<br /> <br /> See http://www.flashrom.org/GCI2010 for a huge list of flashrom related tasks.<br /> <br /> =Code: Tasks related to writing or refactoring code=<br /> =Documentation: Tasks related to creating/editing documents=<br /> =Outreach: Tasks related to community management and outreach/marketing=<br /> =Quality Assurance: Tasks related to testing and ensuring code is of high quality=<br /> =Research: Tasks related to studying a problem and recommending solutions=<br /> =Training: Tasks related to helping others learn more=<br /> =Translation: Tasks related to localization=<br /> =User Interface: Tasks related to user experience research or user interface design and interaction=</div>

Hailfinger http://www.coreboot.org/GCI2010 2010-10-30T23:47:10Z

<p>Hailfinger: comment about unfinished list</p> <hr /> <div>We hope to participate in Google Code-in 2010 (basically Google Summer of code for 13-18 year old students)<br /> <br /> Please note that the task list is not finished, and we will add more tasks once we know how long individual tasks are supposed to take.<br /> <br /> =Code: Tasks related to writing or refactoring code=<br /> =Documentation: Tasks related to creating/editing documents=<br /> =Outreach: Tasks related to community management and outreach/marketing=<br /> =Quality Assurance: Tasks related to testing and ensuring code is of high quality=<br /> =Research: Tasks related to studying a problem and recommending solutions=<br /> =Training: Tasks related to helping others learn more=<br /> =Translation: Tasks related to localization=<br /> =User Interface: Tasks related to user experience research or user interface design and interaction=</div>

Hailfinger http://www.coreboot.org/GCI2010 2010-10-30T21:50:21Z

<p>Hailfinger: </p> <hr /> <div>We hope to participate in Google Code-in 2010 (basically Google Summer of code for 13-18 year old students)<br /> <br /> =Code: Tasks related to writing or refactoring code=<br /> =Documentation: Tasks related to creating/editing documents=<br /> =Outreach: Tasks related to community management and outreach/marketing=<br /> =Quality Assurance: Tasks related to testing and ensuring code is of high quality=<br /> =Research: Tasks related to studying a problem and recommending solutions=<br /> =Training: Tasks related to helping others learn more=<br /> =Translation: Tasks related to localization=<br /> =User Interface: Tasks related to user experience research or user interface design and interaction=</div>

Hailfinger http://www.coreboot.org/GCI2010 2010-10-30T21:49:12Z

<p>Hailfinger: Headlines</p> <hr /> <div>=Code: Tasks related to writing or refactoring code=<br /> =Documentation: Tasks related to creating/editing documents=<br /> =Outreach: Tasks related to community management and outreach/marketing=<br /> =Quality Assurance: Tasks related to testing and ensuring code is of high quality=<br /> =Research: Tasks related to studying a problem and recommending solutions=<br /> =Training: Tasks related to helping others learn more=<br /> =Translation: Tasks related to localization=<br /> =User Interface: Tasks related to user experience research or user interface design and interaction=</div>

Hailfinger http://www.coreboot.org/FAQ 2010-05-20T08:20:10Z

<p>Hailfinger: /* Inside mainboard BIOS (re)flash */ Update flashrom log+features, update information about uniflash+ctflasher.</p> <hr /> <div>== General ==<br /> <br /> === What is coreboot? ===<br /> <br /> '''coreboot''' (formerly known as LinuxBIOS) is a Free Software project aimed at replacing the proprietary BIOS (firmware) you can find in most of today's computers.<br /> <br /> It performs just a little bit of hardware initialization and then executes a so-called [[Payloads|payload]].<br /> <br /> Some of the many possible payloads are: a [[Linux]] kernel, [[FILO]] (a GRUB-like bootloader for booting from disk), [[GRUB2]], [http://www.openbios.org/Open_Firmware Open Firmware], [[Etherboot]]/[[GPXE]], [[SeaBIOS]] (for booting Windows XP, Windows Vista, Windows 7, NetBSD and Linux), and [[Payloads|many others]].<br /> <br /> The initial motivation for the project was maintenance of large clusters, but unsurprisingly, interest and contributions have come from people with varying backgrounds. The latest version of coreboot can be used in a wide variety of scenarios including clusters, embedded systems, desktop PCs, servers, and more.<br /> <br /> For more information, see [[History]].<br /> <br /> === Why do we need coreboot? ===<br /> <br /> ==== Why do we need coreboot for cluster maintainance? ====<br /> <br /> Current PCs used as cluster nodes depend on a vendor-supplied BIOS for booting. The BIOS in turn relies on inherently unreliable devices such as floppy disks and hard drives to boot the operating system. In addition, current BIOS software is unable to accommodate non-standard hardware making it difficult to support experimental work. The BIOS is slow and often erroneous and redundant and, most importantly, maintenance is a nightmare. Imagine walking around with a keyboard and monitor to every one of the 128 nodes in a cluster to change one BIOS setting. <br /> <br /> coreboot with Linux as a [[Payloads|payload]] (other payloads are possible!) gunzip's the Linux kernel straight out of NVRAM and essentially requires no moving parts other than the CPU 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 &amp;mdash; perhaps as simple as a CPU and memory, no disk, no floppy, and no file system. The nodes will be much less autonomous thus making them easier to maintain.<br /> <br /> ==== Why do we need coreboot for other purposes? ====<br /> <br /> Some aspects of '''DRM''' are not travelling well with the idea of a free computer system. As many computer magazines already pointed out, there may be future restrictions imposed by BIOSes, that a customer is little aware of before purchase and might not harmonize with the idea of freedom and/or security in some cases.<br /> <br /> === Who is working on coreboot? ===<br /> <br /> The coreboot project was started in the winter of 1999 in the '''Advanced Computing Laboratory at Los Alamos National Laboratory (LANL)''' by [[User:Rminnich|Ron Minnich]]. Two undergraduate students, James Hendricks and Dale Webster spent their winter vacation putting together the proof of concept implementation. <br /> <br /> Since then, a [[Contributors|long list of people have contributed]] both in discussions and actual code. Please don't be shy and let us know if you are missing from the list. It's not a purposeful omission, just an unfortunate mistake.<br /> <br /> === Who is funding coreboot? ===<br /> <br /> The coreboot project was initially funded by the Los Alamos Computer Science Institute and the Department of Energy's Office of Science.<br /> <br /> See also the [[Sponsors|list of coreboot sponsors]].<br /> <br /> == Users ==<br /> <br /> === Will coreboot work on my machine? ===<br /> <br /> See the [[Supported Motherboards]] page for which mainboards are supported, and also the list of [[Supported Chipsets and Devices]]. See the [[Products]] page for a list of vendors selling products running coreboot.<br /> <br /> If the above sources don't help, please send the following to the [[Mailinglist|mailing list]]:<br /> <br /> * Step 1: A very brief description of your system: board vendor, board name, CPU, northbridge, southbridge, and optionally other important details.<br /> * Step 2: Linux &quot;'''lspci -tvnn'''&quot; output for your system, generated by booting Linux via the original BIOS and runnning lspci.<br /> * Step 3: Super I/O chip on the mainboard (report the model numbers on the actual chip, for example &quot;Winbond W83627HF&quot; and/or run &quot;'''[[superiotool]] -dV'''&quot;).<br /> * Step 4: Type of BIOS device (see the question &quot;How do I identify the BIOS chip on my mainboard?&quot; below). Please send us the output of &quot;'''[[flashrom]] -V'''&quot;<br /> * Step 5: URL to the mainboard specifications page (optional).<br /> * Step 6: Any other relevant information you can provide.<br /> <br /> If you can't do step 1 above, please describe (as best you can) the specific CPU chip and the chipset used on the mainboard.<br /> <br /> Usually in less than a day, someone will respond on the coreboot mailing list saying your mainboard is supported in the main coreboot source tree, it is currently in development, it is not yet supported or the manufacturer will not release information needed to provide coreboot support. In the latter case, please let the manufacturer know that you want coreboot support and his failure to release chipset information is making that very difficult.<br /> <br /> === What commercial products use coreboot? ===<br /> <br /> See the [[products]] page.<br /> <br /> === Which different operating systems will coreboot boot? ===<br /> <br /> coreboot should support almost any modern operating system. To support operating systems that use [http://en.wikipedia.org/wiki/BIOS_interrupt_call BIOS calls], [[SeaBIOS]] is mandantory, as coreboot doesn't provide these by itself:<br /> <br /> * Linux<br /> * Plan 9<br /> * FreeDOS (via [[SeaBIOS]])<br /> * Windows 2000, XP, Vista, 7(RC) (via [[SeaBIOS]], the boot loader requires BIOS)<br /> * NetBSD, MirBSD (via [[SeaBIOS]] as at least the boot loader requires BIOS)<br /> <br /> coreboot does '''not''' natively support:<br /> <br /> * We have tested some of the BSD OSes and have seen, that FreeBSD for example makes BIOS calls, which is not supported by coreboot. Possibly with help of [[SeaBIOS]], it may be possible to boot FreeBSD like it is now, but the right thing to do, is to remove FreeBSD's dependence on BIOS calls.<br /> * Windows versions older than Windows 2000, as they make BIOS calls ([[SeaBIOS]] might help)<br /> * [http://www.menuetos.net/ MenuetOS], as it makes BIOS calls ([[SeaBIOS]] might help)<br /> <br /> Please feel free to test booting any of the above using [[SeaBIOS]] and report to the coreboot mailing list.<br /> <br /> === What chipsets and Super I/O devices are supported? ===<br /> <br /> See the [[Supported Chipsets and Devices]] page.<br /> <br /> === Where is the mailing list archived? ===<br /> <br /> See [[Mailinglist]].<br /> <br /> === Is there a coreboot IRC channel? ===<br /> <br /> Yes, see [[IRC]].<br /> <br /> === Where do I get the code? ===<br /> <br /> See the [[Download coreboot|download page]].<br /> <br /> === How do I build coreboot? ===<br /> <br /> See the [[documentation]].<br /> <br /> === How can I help with coreboot? ===<br /> <br /> There are many ways how you can help us:<br /> <br /> * Promote coreboot, tell all your friends about it, blog about it etc.<br /> * Test coreboot, [http://tracker.coreboot.org/trac/coreboot/newticket report] any bugs you find, or let us know about any suggestions for improvements you have.<br /> * Help us to make the list of [[Supported Motherboards]] and the list of [[Supported Chipsets and Devices]] bigger by contributing code. Please also read the [[Development Guidelines]] in that case.<br /> * If you have a mainboard with USB2 (EHCI-controller) you can look if it supports the [[EHCI Debug Port]] and mail the information to us, if it is not already there.<br /> ** If you are familiar with microcontroller development, you might be able to build a debugging tool for the [[EHCI Debug Port]]. If you are successful, we like to hear about it.<br /> * Test, if QNX or Solaris are able to boot on a mainboard with coreboot.<br /> * Have a look at the [http://tracker.coreboot.org/trac/coreboot/report/1 list of open issues/bugs] and try to reproduce them or (preferrably) fix them.<br /> * Contact [[User:Rminnich|Ron Minnich]] or [[User:Stepan|Stefan Reinauer]] for bigger projects related to coreboot.<br /> * Contact us on the [[Mailinglist|mailing list]] if you have any further questions or suggestions.<br /> <br /> === What do the abbreviations in this wiki stand for? ===<br /> <br /> See [[Glossary]].<br /> <br /> == Developers ==<br /> <br /> === Where can I buy BIOS chips (empty or pre-flashed)? ===<br /> <br /> When developing or simply trying out coreboot you always need a means to revert to your old BIOS in case something goes wrong. One way to do this is to get an extra BIOS chip (PLCC32, DIP32, DIP8, or other) and copy your original BIOS image onto that chip (using [[Flashrom]], for example). If you have a socketed BIOS (not soldered onto the mainboard), you can hot-swap the chips while your computer is running. <br /> <br /> You have several options to get spare BIOS chips:<br /> * Most local or online electronics dealers carry some, for example:<br /> ** Germany:<br /> *** http://www.bios-chip.com / http://www.bios-express.de (same company)<br /> *** http://www.bios-fix.de<br /> *** http://www.bios-chips.com<br /> *** http://www.conrad.de<br /> *** http://www.endrich.com/de/site.php/47385 (it's unknown whether they ship small quantities)<br /> *** http://www.chip-service.de<br /> *** http://www.cramertronic.de/index.php?cPath=37<br /> *** http://www.neumueller.com/<br /> ** UK:<br /> *** http://bios-repair.co.uk/<br /> ** US:<br /> *** http://avnet.com<br /> *** http://mouser.com<br /> *** http://semiconductorstore.com/<br /> * You can search eBay for BIOS chips (either empty ones or pre-flashed ones).<br /> * You can rip out chips from old/broken mainboards and re-use them (you can check flea markets, eBay, etc. for cheap and/or broken mainboards).<br /> <br /> === What kind of hardware tools do I need? ===<br /> <br /> See the [[Developer Manual#Required_hardware_and_software_tools_for_developers|hardware tools section]] of the [[Developer Manual|developer's manual]].<br /> <br /> === How do I use a null-modem cable to get coreboot debugging output over a serial port? ===<br /> <br /> * First, you'll want to set up a terminal program, e.g. '''minicom''' correctly.<br /> $ minicom -s<br /> -&gt; Serial port setup<br /> -&gt; Press A and enter your COM device (ttyS0 or ttyS1 or ttyUSB0, depending on your COM port)<br /> -&gt; Press E and choose &quot;115200 8N1&quot; (default)<br /> -&gt; Disable Hardware and Software Flow Control (via F and G)<br /> -&gt; Press enter to leave the menu<br /> -&gt; Save setup as..<br /> -&gt; Enter &quot;lb&quot;<br /> -&gt; Exit from minicom<br /> * From now on, you can start minicom with the obove settings simply by typing:<br /> $ minicom -o lb<br /> <br /> === What documentation do I need? ===<br /> <br /> As much documentation as you can possibly get your hands on. At minimum, you will need the docs for the chipset.<br /> <br /> There have been reports of people getting coreboot working by booting with the OEM BIOS. Then, they would read the static contents of the PCI config registers after boot. coreboot is then built to match the static contents read from the PCI config registers. <br /> <br /> The problem with this approach is that chipsets generally require dynamic vs static configuration values during their initialization. The configuration register contents will change from one stage of initialization to the next. Since the contents of the registers read is only the final state of the configuration registers, the chipset won't be properly initialized if these are the only configuration values used.<br /> <br /> Getting a mainboard up without chipset docs can be a very long and involved process.<br /> <br /> === What if my chipset docs are covered by an NDA? ===<br /> <br /> If the documentation for your chipset covered by a NDA with no source release agreement, you won't be able to release your code back to the coreboot project in general, or you will violate the GPL.<br /> Many vendors accept releasing the source code, produced after reading such specs, while they don't allow the specs themselves to be revealed. Also, you can offer them the opportunity to review your code, before releasing it to the public.<br /> <br /> === Why is the code so complicated and what can I do to make it easier? ===<br /> <br /> The reason is the complexity of the problem. We support a lot of hardware, and a given chip on a given board will most likely not be configured quite the same as the same chip on some other board. To help make code navigation easier, pick a target and build that target. Then, in the build directory, type make tags or make etags to get your favorite tags file. <br /> <br /> === How do I contribute my changes? ===<br /> <br /> Please carefully read the [http://linuxbios.org/Development_Guidelines Development Guidelines] for more information.<br /> <br /> === How do I identify the BIOS chip on my mainboard? ===<br /> <br /> Please see [[Flashrom#ROM_chip_overview]].<br /> <br /> === How do I (re-)flash the BIOS? ===<br /> <br /> ==== Out of mainboard BIOS (re)flash ====<br /> <br /> If the BIOS chip is socketed, it can be removed and flashed in a rom/flash burner and quickly re-installed.<br /> <br /> You have the option of using the [http://www.flashrom.org/Supported_hardware external programmers supported by flashrom] or some other external programmer which comes with its own software. Depending on the flash chip type, various options exist. For older parallel flash chips, some of these burners cost $700 and more plus they complete a flash in 30 seconds (like the [http://www.conitec.net/english/galep5.php Conitec Galep V]), but if you are willing to wait 5 minutes for a flash and manually set DIP switches, the Enhanced Willem Universal Programmer will do the job for only $40-60 USD. There are several models of the Willem Programmer, each supporting many chips, but not all, so be sure to get one that supports your BIOS chip. You could also use the [[Paraflasher]] which is a really low-cost programmer with parts sold for $20 or less. The [[flashrom]] wiki has a list of hardware you can use for programming.<br /> <br /> If your chip is PLCC, you will also need the push pin trick or a PLCC chip extractor/puller or just thread nylon string under the PLCC chip from corner to corner and yank up it straight up. Read more about chip extraction in the [[Developer_Manual/Tools#Chip_removal_tools|developer manual]].<br /> <br /> ==== Inside mainboard BIOS (re)flash ====<br /> <br /> Download the appropriate flash update utility. Build the coreboot image 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. NOTE: Many vendor specific flash utilities refuse to write &quot;foreign&quot; BIOS images, such as coreboot.<br /> <br /> Therefore we suggest that you use the universal flash utility called [http://www.flashrom.org/ flashrom] which was developed and improved by many coreboot developers, and it works under Linux/*BSD/MacOSX/Solaris/DOS.<br /> <br /> Example:<br /> bash$ sudo ./flashrom -V<br /> flashrom v0.9.2-r1000 on Linux 2.6.34-rc7-git5 (x86_64), built with libpci 3.1.7, GCC 4.4.3<br /> flashrom is free software, get the source code at http://www.flashrom.org<br /> <br /> No coreboot table found.<br /> Found chipset &quot;Intel ICH9&quot;, enabling flash write... OK.<br /> This chipset supports the following protocols: FWH,SPI.<br /> Calibrating delay loop... 663M loops per second, 100 myus = 199 us. OK.<br /> Found chip &quot;Winbond W25x80&quot; (1024 KB, SPI) at physical address 0xfff00000.<br /> No operations were specified.<br /> <br /> Alternatively you could either use the DOS [http://www.rainbow-software.org/uniflash/ uniflash] utility, or use its source code, which is also available for download from the uniflash site (in Turbo Pascal 7) as a reference for adding support for your flash chip to [[flashrom]]. Uniflash supports a lot of different flash chips, and chip interfaces, but so far SPI support is only present in flashrom. You can use flashrom and uniflash for PCI expansion card flashing, such as on RTL8139 Ethernet card (32pin DIL), which allows flashing of your BIOS chip on the NIC if manufacturer provides the circuitry. Please note that flashrom and uniflash support different cards and you should check which utility supports the programmer hardware you own.<br /> <br /> Another tool which runs in linux is [http://sourceforge.net/projects/ctflasher/ ctflasher], but it is not maintained anymore and might not work with current Linux kernels.<br /> <br /> <br /> ===== BIOS Savior RD1 =====<br /> <br /> [http://www.ioss.com.tw/web/English/RD1BIOSSavior.html BIOS Savior RD1]<br /> <br /> There are some posts about the BIOS Savior RD1 that suggest its integrated flash device is of low quality; it may take 10 or more flash programming attempts to get a good update to the RD1 flash device. As a result, the following steps have proven to be successful while using the RD1:<br /> <br /> * Step 1 - While the system is powered down, remove the original BIOS device from the mainboard and insert it into the RD1's socket.<br /> <br /> * Step 2 - Insert the RD1 into the mainboard's flash BIOS socket.<br /> <br /> * Step 3 - Boot the system with the RD1 set to boot from the original flash device from the mainboard.<br /> <br /> * Step 4 - Program the original BIOS image (or other known good BIOS image) into the RD1's integrated flash device. Do this as many times as needed until the device is properly programmed and the system boots corectly from the RD1's integrated flash device. Be sure to check the settings on the RD1 so that the proper flash device is now being programmed. If the RD1 is not set correctly the working BIOS image will be erased and the system will not boot!<br /> <br /> * Step 5 - Program the test BIOS image (usually coreboot images are among this group) into the original flash device from the mainboard. The original BIOS device usually programs OK on the first attempt. Be sure to check the settings again on the RD1 so that the proper flash device is being programmed!<br /> <br /> <br /> The RD1 has been used in the above fashion with great success on the Tyan S2885 mainboard. Unfortunately the RD1 does not work on the nVidia CK8-04 CRB mainboard. The CK8-04 CRB may require a flash device that the RD1 does not support. <br /> <br /> The RD1 has worked well as a &quot;do nothing&quot; adapter that allows swapping the BIOS flash device between a flash burner and a mainboard without any wear to the mainboard's BIOS socket.<br /> <br /> === Can I do any serious damage mucking around with this stuff? ===<br /> <br /> Any time you stick your hand into an open machine while the power is on, you're risking life and limb. That said, there are also some other not-so-nice things that can happen if you mess up (not that we would know). <br /> <br /> * Incorrect insertion of the flash (1 casualty) <br /> * Incorrect jumper settings (1 casualty) <br /> * Aggressive and/or inappropriate use of metal objects such as screwdrivers (2 casualties) <br /> * Miscellaneous miswirings and mishandlings (3+ casualties)<br /> <br /> remember: make sure your important data is on a disconnected drive while you experiment.<br /> <br /> === A note on electrostatic discharge (ESD) and ESD protection (thanks to Bari Ari) ===<br /> <br /> ESD can damage disk drives, boards, DoC's and other parts. The majority of the time, ESD events cause the component to degrade, but not fail testing procedures, resulting in failure at a later date. Because components do not fail immediately, technicians often underestimate the cost of not using ESD prevention measures. Provide at minimum some ESD protection by wearing an antistatic wrist strap attached to the chassis ground on your system when handling parts. <br /> <br /> Always handle boards carefully. They can be extremely sensitive to ESD. Hold boards only by their edges. After removing a board from its protective wrapper or from the system, place it component side up on a grounded, static free surface. Use a conductive foam pad if available. Do not slide the board over any surface. <br /> <br /> To further reduce the chances of ESD, you should create an ESD safe workstation that includes at minimum: <br /> <br /> * Conductive rubber mat, with a lead wire that can be connected to a metal surface to create a ground. <br /> <br /> * ESD wrist strap, which has a resistor inside the strap and a lead wire that can be connected to a metal surface as a ground. The grounding wire on the wrist strap should have between 1 and 10 Megaohms of resistance. The resistor should protect you in case you come in contact with a voltage source. If the resistor is bad or not included, the wrist strap is useless. An accidental shock could be serious and even deadly! <br /> <br /> * Table or workspace that is clean, clear of dust, and away from electrical machinery or other equipment that generates electrical currents. <br /> <br /> The idea is to ensure that all components you are going to interact with have the same charge. By connecting everything to the computer case, you ensure that the components of the case, the chair, and your body all have the same charge. If every object has the same charge, the electrons will not jump from one object to another minimizing the risk of ESD damage.<br /> <br /> === What is a PIRQ table? ===<br /> <br /> There's a good description of the BIOS implementation of the PIRQ in the ''red PCI book'', and here's a [http://www.microsoft.com/whdc/archive/pciirq.mspx description of the $PIR data structure].<br /> <br /> coreboot saves the $PIR data structure between 0xf0000 &amp; 0x100000. Search for $PIR and then save it before copying over the BIOS.<br /> <br /> See also the [http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv1/util/ADLO/pirq/README ADLO README] for more information.<br /> <br /> === How do I set up etherboot with coreboot? ===<br /> <br /> Note from Ron: I have edited this somewhat to remove Geode-specific items. <br /> <br /> Christer Weinigel writes: <br /> To: rminnich@lanl.gov<br /> Cc: linuxbios@lanl.gov<br /> Subject: Re: LinuxBIOS + Etherboot HOWTO?<br /> <br /> I had some trouble using LinuxBIOS + etherboot... <br /> <br /> My bad, I messed up and used mkelfImage-1.6 that I got from ftp.lnxi.com, when I realized that I ought to use the one from freebios/util everything started working. <br /> <br /> Here's what I did to get LinuxBIOS + Etherboot loading and booting a Linux kernel using TFTP. <br /> <br /> /Christer <br /> <br /> Get etherboot-5.0 from the CVS tree on etherboot.sourceforge.net. <br /> <br /> Modify etherboot-5.0/src/Config, comment out: <br /> <br /> # BIOS select don't change unless you know what you are doing<br /> #CFLAGS32+= -DPCBIOS<br /> <br /> and uncomment the following: <br /> <br /> # Options to make a version of Etherboot that will work under linuxBIOS.<br /> CFLAGS32+= -DLINUXBIOS -DCONFIG_TSC_CURRTICKS -DCONSOLE_SERIAL \<br /> -DCOMCONSOLE=0x3f8 -DCOMPRESERVE -DCONFIG_PCI_DIRECT -DELF_IMAGE <br /> <br /> Compile Etherboot to make an elf file for your ethernet card: <br /> <br /> make bin32/natsemi.elf<br /> <br /> Compile and install mkelfImage from freebios/util/mkelfImage. <br /> <br /> Create a bootimage to put on your TFTP server: <br /> <br /> mkelfImage --command-line=&quot;root=/dev/hda2 console=ttyS0,38400&quot; \<br /> --kernel vmlinux -o /tftpboot/kernel<br /> <br /> Finally, make sure that your BOOT/DCHP server is answering and that the TFTP server is active. <br /> <br /> Tell LinuxBIOS to boot an elf Image, and tell LinuxBIOS where it is: <br /> <br /> option USE_ELF_BOOT=1<br /> <br /> I have placed natsemi.elf in the first 64k of my BIOS flash chip, and LinuxBIOS in the second 64k. <br /> <br /> insmod bios.o<br /> dd if=natsemi.elf of=/dev/bios bs=64k<br /> dd if=linuxbios.rom of=/dev/bios bs=64k seek=1<br /> <br /> Finally boot LinuxBIOS.<br /> <br /> === How do I set GEODE graphics and video? ===<br /> <br /> There is no Geode graphics support in coreboot. Install the Geode framebuffer driver for console graphics and the X driver for X support on your Geode Linux image. Current kernel and X distributions contain the required drivers. Until the driver loads there is only serial console output.<br /> <br /> Driver source:<br /> <br /> [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=tree;f=drivers/video/geode;hb=3968cb49ab01588cbf6896951780a1e411a0ec38 2.6.23 kernel framebuffer driver]<br /> <br /> [http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-amd.git;a=summary X.org driver]<br /> <br /> === How do I set up testbios? ===<br /> <br /> Please read the [http://linuxbios.org/FAQ/Obsolete#How_do_I_set_up_testbios.3F testbios FAQ].<br /> <br /> === /usr/sbin/iasl: Command not found ===<br /> <br /> If you see this error, you have to install ''iasl'', Intel's ASL Optimizing Compiler:<br /> <br /> * '''SUSE''' ships it in the '''pmtools''' package ([ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse/x86_64/pmtools-20050823-3.x86_64.rpm pmtools-20050823-3.x86_64.rpm], [ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse/i586/pmtools-20050823-3.i586.rpm pmtools-20050823-3.i586.rpm]). If you want to run rpmbuild --rebuild: [ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse/src/pmtools-20050823-3.src.rpm pmtools-20050823-3.src.rpm].<br /> * '''Debian''' ships it in the '''iasl''' package (''apt-get install iasl'').<br /> * You can also download the [http://acpica.org/downloads/unix_source_code.php latest version of the source code].<br /> <br /> === How can I write to POSTcard port 0x80 from userspace? ===<br /> <br /> [http://www.linuxbios.org/pipermail/linuxbios/2006-November/017012.html This] might be useful in some situations, and to output a number to a POST card:<br /> <br /> printf &quot;\001&quot; | dd bs=1 seek=128 of=/dev/port<br /> <br /> In DOS (not Windows XP) use:<br /> mov al, 42; out al, 80h<br /> To output 42 type<br /> o 80 42<br /> in DOS debug.exe.<br /> <br /> === Is coreboot applying x86 microcode patches? ===<br /> <br /> And if yes, can they be modified?<br /> <br /> Answer: Yes, coreboot is applying microcode patches on AMD and Intel CPUs. However, this field is little documented, so coreboot uses only unmodified, vendor-provided microcode. Few people think, that system design can seriously be improved by modifications here ( µCode patches mostly disable erraneous functions and opcodes).<br /> <br /> === How can I retrieve a good video BIOS? ===<br /> <br /> Note: If you are following these instructions to build coreboot for your motherboard, this is only necessary if you have a motherboard with an embedded VGA card. If your VGA is a PCI / PCI-Express add-on card, coreboot will find and run the ROM by itself.<br /> <br /> Anton Borisov has released a number of tools under the GPL (v2) to extract the VGA BIOS from the BIOS ROM images provided by the supplier of your motherboard.<br /> <br /> You can download them here:<br /> <br /> * Award BIOS:<br /> ** http://kaos.ru/biosgfx/download/awardeco-0.2.src.tar.gz<br /> ** http://ftp.debian.org/debian/pool/main/a/awardeco/awardeco_0.2.orig.tar.gz<br /> * AMI BIOS:<br /> ** http://www.kaos.ru/biosgfx/download/AmiDeco_0.31e.src.tar.gz<br /> ** http://ftp.debian.org/debian/pool/main/a/amideco/amideco_0.31e.orig.tar.gz<br /> * Phoenix BIOS:<br /> ** http://www.kaos.ru/biosgfx/download/PhoenixDeco_0.33.src.tar.gz<br /> ** http://ftp.debian.org/debian/pool/main/p/phnxdeco/phnxdeco_0.33.orig.tar.gz<br /> * Insyde BIOS:<br /> ** http://www.kaos.ru/biosgfx/download/InsyDeco_0.3.src.tar.gz<br /> ** (no alternative download location available, sorry)<br /> <br /> See the [[Tyan S2881|Tyan S2881 Build Tutorial]] for more information on how to use these tools.<br /> <br /> == Can I put coreboot into a PCI expansion ROM? ==<br /> <br /> Short answer: NO.<br /> <br /> Long answer:<br /> <br /> There's little use in doing that, as a lots of initialization has already been done by the proprietary BIOS (or coreboot) by the time the PCI expansion ROM is executed. It won't be possible to run coreboot from a PCI expansion ROM after a proprietary BIOS has already been running for instance.<br /> <br /> Note: The Intel ICH7 southbridge seems to allows booting from PCI ROMs ('''not''' arbitrary PCI expansion ROMs as used on graphics cards, SCSI controllers, etc.) -- maybe this should be investigated in order to check if or how it might be useful.<br /> <br /> == Obsolete FAQ items ==<br /> <br /> Please see [[FAQ/Obsolete]] for (probably) obsolete FAQ items.</div>

Hailfinger http://www.coreboot.org/FAQ 2010-05-20T08:07:13Z

<p>Hailfinger: /* Out of mainboard BIOS (re)flash */ More info, point to Paraflasher and flashrom</p> <hr /> <div>== General ==<br /> <br /> === What is coreboot? ===<br /> <br /> '''coreboot''' (formerly known as LinuxBIOS) is a Free Software project aimed at replacing the proprietary BIOS (firmware) you can find in most of today's computers.<br /> <br /> It performs just a little bit of hardware initialization and then executes a so-called [[Payloads|payload]].<br /> <br /> Some of the many possible payloads are: a [[Linux]] kernel, [[FILO]] (a GRUB-like bootloader for booting from disk), [[GRUB2]], [http://www.openbios.org/Open_Firmware Open Firmware], [[Etherboot]]/[[GPXE]], [[SeaBIOS]] (for booting Windows XP, Windows Vista, Windows 7, NetBSD and Linux), and [[Payloads|many others]].<br /> <br /> The initial motivation for the project was maintenance of large clusters, but unsurprisingly, interest and contributions have come from people with varying backgrounds. The latest version of coreboot can be used in a wide variety of scenarios including clusters, embedded systems, desktop PCs, servers, and more.<br /> <br /> For more information, see [[History]].<br /> <br /> === Why do we need coreboot? ===<br /> <br /> ==== Why do we need coreboot for cluster maintainance? ====<br /> <br /> Current PCs used as cluster nodes depend on a vendor-supplied BIOS for booting. The BIOS in turn relies on inherently unreliable devices such as floppy disks and hard drives to boot the operating system. In addition, current BIOS software is unable to accommodate non-standard hardware making it difficult to support experimental work. The BIOS is slow and often erroneous and redundant and, most importantly, maintenance is a nightmare. Imagine walking around with a keyboard and monitor to every one of the 128 nodes in a cluster to change one BIOS setting. <br /> <br /> coreboot with Linux as a [[Payloads|payload]] (other payloads are possible!) gunzip's the Linux kernel straight out of NVRAM and essentially requires no moving parts other than the CPU 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 &amp;mdash; perhaps as simple as a CPU and memory, no disk, no floppy, and no file system. The nodes will be much less autonomous thus making them easier to maintain.<br /> <br /> ==== Why do we need coreboot for other purposes? ====<br /> <br /> Some aspects of '''DRM''' are not travelling well with the idea of a free computer system. As many computer magazines already pointed out, there may be future restrictions imposed by BIOSes, that a customer is little aware of before purchase and might not harmonize with the idea of freedom and/or security in some cases.<br /> <br /> === Who is working on coreboot? ===<br /> <br /> The coreboot project was started in the winter of 1999 in the '''Advanced Computing Laboratory at Los Alamos National Laboratory (LANL)''' by [[User:Rminnich|Ron Minnich]]. Two undergraduate students, James Hendricks and Dale Webster spent their winter vacation putting together the proof of concept implementation. <br /> <br /> Since then, a [[Contributors|long list of people have contributed]] both in discussions and actual code. Please don't be shy and let us know if you are missing from the list. It's not a purposeful omission, just an unfortunate mistake.<br /> <br /> === Who is funding coreboot? ===<br /> <br /> The coreboot project was initially funded by the Los Alamos Computer Science Institute and the Department of Energy's Office of Science.<br /> <br /> See also the [[Sponsors|list of coreboot sponsors]].<br /> <br /> == Users ==<br /> <br /> === Will coreboot work on my machine? ===<br /> <br /> See the [[Supported Motherboards]] page for which mainboards are supported, and also the list of [[Supported Chipsets and Devices]]. See the [[Products]] page for a list of vendors selling products running coreboot.<br /> <br /> If the above sources don't help, please send the following to the [[Mailinglist|mailing list]]:<br /> <br /> * Step 1: A very brief description of your system: board vendor, board name, CPU, northbridge, southbridge, and optionally other important details.<br /> * Step 2: Linux &quot;'''lspci -tvnn'''&quot; output for your system, generated by booting Linux via the original BIOS and runnning lspci.<br /> * Step 3: Super I/O chip on the mainboard (report the model numbers on the actual chip, for example &quot;Winbond W83627HF&quot; and/or run &quot;'''[[superiotool]] -dV'''&quot;).<br /> * Step 4: Type of BIOS device (see the question &quot;How do I identify the BIOS chip on my mainboard?&quot; below). Please send us the output of &quot;'''[[flashrom]] -V'''&quot;<br /> * Step 5: URL to the mainboard specifications page (optional).<br /> * Step 6: Any other relevant information you can provide.<br /> <br /> If you can't do step 1 above, please describe (as best you can) the specific CPU chip and the chipset used on the mainboard.<br /> <br /> Usually in less than a day, someone will respond on the coreboot mailing list saying your mainboard is supported in the main coreboot source tree, it is currently in development, it is not yet supported or the manufacturer will not release information needed to provide coreboot support. In the latter case, please let the manufacturer know that you want coreboot support and his failure to release chipset information is making that very difficult.<br /> <br /> === What commercial products use coreboot? ===<br /> <br /> See the [[products]] page.<br /> <br /> === Which different operating systems will coreboot boot? ===<br /> <br /> coreboot should support almost any modern operating system. To support operating systems that use [http://en.wikipedia.org/wiki/BIOS_interrupt_call BIOS calls], [[SeaBIOS]] is mandantory, as coreboot doesn't provide these by itself:<br /> <br /> * Linux<br /> * Plan 9<br /> * FreeDOS (via [[SeaBIOS]])<br /> * Windows 2000, XP, Vista, 7(RC) (via [[SeaBIOS]], the boot loader requires BIOS)<br /> * NetBSD, MirBSD (via [[SeaBIOS]] as at least the boot loader requires BIOS)<br /> <br /> coreboot does '''not''' natively support:<br /> <br /> * We have tested some of the BSD OSes and have seen, that FreeBSD for example makes BIOS calls, which is not supported by coreboot. Possibly with help of [[SeaBIOS]], it may be possible to boot FreeBSD like it is now, but the right thing to do, is to remove FreeBSD's dependence on BIOS calls.<br /> * Windows versions older than Windows 2000, as they make BIOS calls ([[SeaBIOS]] might help)<br /> * [http://www.menuetos.net/ MenuetOS], as it makes BIOS calls ([[SeaBIOS]] might help)<br /> <br /> Please feel free to test booting any of the above using [[SeaBIOS]] and report to the coreboot mailing list.<br /> <br /> === What chipsets and Super I/O devices are supported? ===<br /> <br /> See the [[Supported Chipsets and Devices]] page.<br /> <br /> === Where is the mailing list archived? ===<br /> <br /> See [[Mailinglist]].<br /> <br /> === Is there a coreboot IRC channel? ===<br /> <br /> Yes, see [[IRC]].<br /> <br /> === Where do I get the code? ===<br /> <br /> See the [[Download coreboot|download page]].<br /> <br /> === How do I build coreboot? ===<br /> <br /> See the [[documentation]].<br /> <br /> === How can I help with coreboot? ===<br /> <br /> There are many ways how you can help us:<br /> <br /> * Promote coreboot, tell all your friends about it, blog about it etc.<br /> * Test coreboot, [http://tracker.coreboot.org/trac/coreboot/newticket report] any bugs you find, or let us know about any suggestions for improvements you have.<br /> * Help us to make the list of [[Supported Motherboards]] and the list of [[Supported Chipsets and Devices]] bigger by contributing code. Please also read the [[Development Guidelines]] in that case.<br /> * If you have a mainboard with USB2 (EHCI-controller) you can look if it supports the [[EHCI Debug Port]] and mail the information to us, if it is not already there.<br /> ** If you are familiar with microcontroller development, you might be able to build a debugging tool for the [[EHCI Debug Port]]. If you are successful, we like to hear about it.<br /> * Test, if QNX or Solaris are able to boot on a mainboard with coreboot.<br /> * Have a look at the [http://tracker.coreboot.org/trac/coreboot/report/1 list of open issues/bugs] and try to reproduce them or (preferrably) fix them.<br /> * Contact [[User:Rminnich|Ron Minnich]] or [[User:Stepan|Stefan Reinauer]] for bigger projects related to coreboot.<br /> * Contact us on the [[Mailinglist|mailing list]] if you have any further questions or suggestions.<br /> <br /> === What do the abbreviations in this wiki stand for? ===<br /> <br /> See [[Glossary]].<br /> <br /> == Developers ==<br /> <br /> === Where can I buy BIOS chips (empty or pre-flashed)? ===<br /> <br /> When developing or simply trying out coreboot you always need a means to revert to your old BIOS in case something goes wrong. One way to do this is to get an extra BIOS chip (PLCC32, DIP32, DIP8, or other) and copy your original BIOS image onto that chip (using [[Flashrom]], for example). If you have a socketed BIOS (not soldered onto the mainboard), you can hot-swap the chips while your computer is running. <br /> <br /> You have several options to get spare BIOS chips:<br /> * Most local or online electronics dealers carry some, for example:<br /> ** Germany:<br /> *** http://www.bios-chip.com / http://www.bios-express.de (same company)<br /> *** http://www.bios-fix.de<br /> *** http://www.bios-chips.com<br /> *** http://www.conrad.de<br /> *** http://www.endrich.com/de/site.php/47385 (it's unknown whether they ship small quantities)<br /> *** http://www.chip-service.de<br /> *** http://www.cramertronic.de/index.php?cPath=37<br /> *** http://www.neumueller.com/<br /> ** UK:<br /> *** http://bios-repair.co.uk/<br /> ** US:<br /> *** http://avnet.com<br /> *** http://mouser.com<br /> *** http://semiconductorstore.com/<br /> * You can search eBay for BIOS chips (either empty ones or pre-flashed ones).<br /> * You can rip out chips from old/broken mainboards and re-use them (you can check flea markets, eBay, etc. for cheap and/or broken mainboards).<br /> <br /> === What kind of hardware tools do I need? ===<br /> <br /> See the [[Developer Manual#Required_hardware_and_software_tools_for_developers|hardware tools section]] of the [[Developer Manual|developer's manual]].<br /> <br /> === How do I use a null-modem cable to get coreboot debugging output over a serial port? ===<br /> <br /> * First, you'll want to set up a terminal program, e.g. '''minicom''' correctly.<br /> $ minicom -s<br /> -&gt; Serial port setup<br /> -&gt; Press A and enter your COM device (ttyS0 or ttyS1 or ttyUSB0, depending on your COM port)<br /> -&gt; Press E and choose &quot;115200 8N1&quot; (default)<br /> -&gt; Disable Hardware and Software Flow Control (via F and G)<br /> -&gt; Press enter to leave the menu<br /> -&gt; Save setup as..<br /> -&gt; Enter &quot;lb&quot;<br /> -&gt; Exit from minicom<br /> * From now on, you can start minicom with the obove settings simply by typing:<br /> $ minicom -o lb<br /> <br /> === What documentation do I need? ===<br /> <br /> As much documentation as you can possibly get your hands on. At minimum, you will need the docs for the chipset.<br /> <br /> There have been reports of people getting coreboot working by booting with the OEM BIOS. Then, they would read the static contents of the PCI config registers after boot. coreboot is then built to match the static contents read from the PCI config registers. <br /> <br /> The problem with this approach is that chipsets generally require dynamic vs static configuration values during their initialization. The configuration register contents will change from one stage of initialization to the next. Since the contents of the registers read is only the final state of the configuration registers, the chipset won't be properly initialized if these are the only configuration values used.<br /> <br /> Getting a mainboard up without chipset docs can be a very long and involved process.<br /> <br /> === What if my chipset docs are covered by an NDA? ===<br /> <br /> If the documentation for your chipset covered by a NDA with no source release agreement, you won't be able to release your code back to the coreboot project in general, or you will violate the GPL.<br /> Many vendors accept releasing the source code, produced after reading such specs, while they don't allow the specs themselves to be revealed. Also, you can offer them the opportunity to review your code, before releasing it to the public.<br /> <br /> === Why is the code so complicated and what can I do to make it easier? ===<br /> <br /> The reason is the complexity of the problem. We support a lot of hardware, and a given chip on a given board will most likely not be configured quite the same as the same chip on some other board. To help make code navigation easier, pick a target and build that target. Then, in the build directory, type make tags or make etags to get your favorite tags file. <br /> <br /> === How do I contribute my changes? ===<br /> <br /> Please carefully read the [http://linuxbios.org/Development_Guidelines Development Guidelines] for more information.<br /> <br /> === How do I identify the BIOS chip on my mainboard? ===<br /> <br /> Please see [[Flashrom#ROM_chip_overview]].<br /> <br /> === How do I (re-)flash the BIOS? ===<br /> <br /> ==== Out of mainboard BIOS (re)flash ====<br /> <br /> If the BIOS chip is socketed, it can be removed and flashed in a rom/flash burner and quickly re-installed.<br /> <br /> You have the option of using the [http://www.flashrom.org/Supported_hardware external programmers supported by flashrom] or some other external programmer which comes with its own software. Depending on the flash chip type, various options exist. For older parallel flash chips, some of these burners cost $700 and more plus they complete a flash in 30 seconds (like the [http://www.conitec.net/english/galep5.php Conitec Galep V]), but if you are willing to wait 5 minutes for a flash and manually set DIP switches, the Enhanced Willem Universal Programmer will do the job for only $40-60 USD. There are several models of the Willem Programmer, each supporting many chips, but not all, so be sure to get one that supports your BIOS chip. You could also use the [[Paraflasher]] which is a really low-cost programmer with parts sold for $20 or less. The [[flashrom]] wiki has a list of hardware you can use for programming.<br /> <br /> If your chip is PLCC, you will also need the push pin trick or a PLCC chip extractor/puller or just thread nylon string under the PLCC chip from corner to corner and yank up it straight up. Read more about chip extraction in the [[Developer_Manual/Tools#Chip_removal_tools|developer manual]].<br /> <br /> ==== Inside mainboard BIOS (re)flash ====<br /> <br /> Download the appropriate flash update utility. Build the coreboot image 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. NOTE: Many vendor specific flash utilities refuse to write &quot;foreign&quot; BIOS images, such as coreboot.<br /> <br /> Therefore we suggest that you use the universal flash utility called [http://www.flashrom.org/ flashrom] which was developed and improved by many coreboot developers.<br /> <br /> Example:<br /> bash$ sudo ./flashrom -V<br /> Calibrating delay loop... Setting up microsecond timing loop<br /> 216M loops per second<br /> ok<br /> Found canidate at: 00000530-00000bc4<br /> Found LinuxBIOS table at: 00000530<br /> lb_table found at address 0xb7e1c530<br /> LinuxBIOS header(24) checksum: 404a table(1684) checksum: 2766 entries: 14<br /> vendor id: via part id: epia-m<br /> Enabling flash write on VT8235...OK<br /> Trying Am29F040B, 512 KB<br /> probe_29f040b: id1 0x20, id2 0xe2<br /> Trying ST29F040B, 512 KB<br /> probe_29f040b: id1 0x20, id2 0xe2<br /> ST29F040B found at physical address: 0xfff80000<br /> Flash part is ST29F040B<br /> OK, only ENABLING flash write, but NOT FLASHING.<br /> <br /> <br /> Alternatively you could either use the DOS [http://www.rainbow-software.org/uniflash/ uniflash] utility, or use its source code, which is also available for download from the uniflash site (in Turbo Pascal 7) as a reference for adding support for your flash chip to &quot;flashrom&quot;. Uniflash supports a lot of different flash chips, and chip interfaces. It has untested support for PCI expansion card flash BIOS, such as on RTL8139 Ethernet card (32pin DIL), which allows flashing on the NIC if manufacturer provides the circuitry.<br /> <br /> Another tool which runs in linux is [http://sourceforge.net/projects/ctflasher/ flasher].<br /> <br /> <br /> ===== BIOS Savior RD1 =====<br /> <br /> [http://www.ioss.com.tw/web/English/RD1BIOSSavior.html BIOS Savior RD1]<br /> <br /> There are some posts about the BIOS Savior RD1 that suggest its integrated flash device is of low quality; it may take 10 or more flash programming attempts to get a good update to the RD1 flash device. As a result, the following steps have proven to be successful while using the RD1:<br /> <br /> * Step 1 - While the system is powered down, remove the original BIOS device from the mainboard and insert it into the RD1's socket.<br /> <br /> * Step 2 - Insert the RD1 into the mainboard's flash BIOS socket.<br /> <br /> * Step 3 - Boot the system with the RD1 set to boot from the original flash device from the mainboard.<br /> <br /> * Step 4 - Program the original BIOS image (or other known good BIOS image) into the RD1's integrated flash device. Do this as many times as needed until the device is properly programmed and the system boots corectly from the RD1's integrated flash device. Be sure to check the settings on the RD1 so that the proper flash device is now being programmed. If the RD1 is not set correctly the working BIOS image will be erased and the system will not boot!<br /> <br /> * Step 5 - Program the test BIOS image (usually coreboot images are among this group) into the original flash device from the mainboard. The original BIOS device usually programs OK on the first attempt. Be sure to check the settings again on the RD1 so that the proper flash device is being programmed!<br /> <br /> <br /> The RD1 has been used in the above fashion with great success on the Tyan S2885 mainboard. Unfortunately the RD1 does not work on the nVidia CK8-04 CRB mainboard. The CK8-04 CRB may require a flash device that the RD1 does not support. <br /> <br /> The RD1 has worked well as a &quot;do nothing&quot; adapter that allows swapping the BIOS flash device between a flash burner and a mainboard without any wear to the mainboard's BIOS socket.<br /> <br /> === Can I do any serious damage mucking around with this stuff? ===<br /> <br /> Any time you stick your hand into an open machine while the power is on, you're risking life and limb. That said, there are also some other not-so-nice things that can happen if you mess up (not that we would know). <br /> <br /> * Incorrect insertion of the flash (1 casualty) <br /> * Incorrect jumper settings (1 casualty) <br /> * Aggressive and/or inappropriate use of metal objects such as screwdrivers (2 casualties) <br /> * Miscellaneous miswirings and mishandlings (3+ casualties)<br /> <br /> remember: make sure your important data is on a disconnected drive while you experiment.<br /> <br /> === A note on electrostatic discharge (ESD) and ESD protection (thanks to Bari Ari) ===<br /> <br /> ESD can damage disk drives, boards, DoC's and other parts. The majority of the time, ESD events cause the component to degrade, but not fail testing procedures, resulting in failure at a later date. Because components do not fail immediately, technicians often underestimate the cost of not using ESD prevention measures. Provide at minimum some ESD protection by wearing an antistatic wrist strap attached to the chassis ground on your system when handling parts. <br /> <br /> Always handle boards carefully. They can be extremely sensitive to ESD. Hold boards only by their edges. After removing a board from its protective wrapper or from the system, place it component side up on a grounded, static free surface. Use a conductive foam pad if available. Do not slide the board over any surface. <br /> <br /> To further reduce the chances of ESD, you should create an ESD safe workstation that includes at minimum: <br /> <br /> * Conductive rubber mat, with a lead wire that can be connected to a metal surface to create a ground. <br /> <br /> * ESD wrist strap, which has a resistor inside the strap and a lead wire that can be connected to a metal surface as a ground. The grounding wire on the wrist strap should have between 1 and 10 Megaohms of resistance. The resistor should protect you in case you come in contact with a voltage source. If the resistor is bad or not included, the wrist strap is useless. An accidental shock could be serious and even deadly! <br /> <br /> * Table or workspace that is clean, clear of dust, and away from electrical machinery or other equipment that generates electrical currents. <br /> <br /> The idea is to ensure that all components you are going to interact with have the same charge. By connecting everything to the computer case, you ensure that the components of the case, the chair, and your body all have the same charge. If every object has the same charge, the electrons will not jump from one object to another minimizing the risk of ESD damage.<br /> <br /> === What is a PIRQ table? ===<br /> <br /> There's a good description of the BIOS implementation of the PIRQ in the ''red PCI book'', and here's a [http://www.microsoft.com/whdc/archive/pciirq.mspx description of the $PIR data structure].<br /> <br /> coreboot saves the $PIR data structure between 0xf0000 &amp; 0x100000. Search for $PIR and then save it before copying over the BIOS.<br /> <br /> See also the [http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv1/util/ADLO/pirq/README ADLO README] for more information.<br /> <br /> === How do I set up etherboot with coreboot? ===<br /> <br /> Note from Ron: I have edited this somewhat to remove Geode-specific items. <br /> <br /> Christer Weinigel writes: <br /> To: rminnich@lanl.gov<br /> Cc: linuxbios@lanl.gov<br /> Subject: Re: LinuxBIOS + Etherboot HOWTO?<br /> <br /> I had some trouble using LinuxBIOS + etherboot... <br /> <br /> My bad, I messed up and used mkelfImage-1.6 that I got from ftp.lnxi.com, when I realized that I ought to use the one from freebios/util everything started working. <br /> <br /> Here's what I did to get LinuxBIOS + Etherboot loading and booting a Linux kernel using TFTP. <br /> <br /> /Christer <br /> <br /> Get etherboot-5.0 from the CVS tree on etherboot.sourceforge.net. <br /> <br /> Modify etherboot-5.0/src/Config, comment out: <br /> <br /> # BIOS select don't change unless you know what you are doing<br /> #CFLAGS32+= -DPCBIOS<br /> <br /> and uncomment the following: <br /> <br /> # Options to make a version of Etherboot that will work under linuxBIOS.<br /> CFLAGS32+= -DLINUXBIOS -DCONFIG_TSC_CURRTICKS -DCONSOLE_SERIAL \<br /> -DCOMCONSOLE=0x3f8 -DCOMPRESERVE -DCONFIG_PCI_DIRECT -DELF_IMAGE <br /> <br /> Compile Etherboot to make an elf file for your ethernet card: <br /> <br /> make bin32/natsemi.elf<br /> <br /> Compile and install mkelfImage from freebios/util/mkelfImage. <br /> <br /> Create a bootimage to put on your TFTP server: <br /> <br /> mkelfImage --command-line=&quot;root=/dev/hda2 console=ttyS0,38400&quot; \<br /> --kernel vmlinux -o /tftpboot/kernel<br /> <br /> Finally, make sure that your BOOT/DCHP server is answering and that the TFTP server is active. <br /> <br /> Tell LinuxBIOS to boot an elf Image, and tell LinuxBIOS where it is: <br /> <br /> option USE_ELF_BOOT=1<br /> <br /> I have placed natsemi.elf in the first 64k of my BIOS flash chip, and LinuxBIOS in the second 64k. <br /> <br /> insmod bios.o<br /> dd if=natsemi.elf of=/dev/bios bs=64k<br /> dd if=linuxbios.rom of=/dev/bios bs=64k seek=1<br /> <br /> Finally boot LinuxBIOS.<br /> <br /> === How do I set GEODE graphics and video? ===<br /> <br /> There is no Geode graphics support in coreboot. Install the Geode framebuffer driver for console graphics and the X driver for X support on your Geode Linux image. Current kernel and X distributions contain the required drivers. Until the driver loads there is only serial console output.<br /> <br /> Driver source:<br /> <br /> [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=tree;f=drivers/video/geode;hb=3968cb49ab01588cbf6896951780a1e411a0ec38 2.6.23 kernel framebuffer driver]<br /> <br /> [http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-amd.git;a=summary X.org driver]<br /> <br /> === How do I set up testbios? ===<br /> <br /> Please read the [http://linuxbios.org/FAQ/Obsolete#How_do_I_set_up_testbios.3F testbios FAQ].<br /> <br /> === /usr/sbin/iasl: Command not found ===<br /> <br /> If you see this error, you have to install ''iasl'', Intel's ASL Optimizing Compiler:<br /> <br /> * '''SUSE''' ships it in the '''pmtools''' package ([ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse/x86_64/pmtools-20050823-3.x86_64.rpm pmtools-20050823-3.x86_64.rpm], [ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse/i586/pmtools-20050823-3.i586.rpm pmtools-20050823-3.i586.rpm]). If you want to run rpmbuild --rebuild: [ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse/src/pmtools-20050823-3.src.rpm pmtools-20050823-3.src.rpm].<br /> * '''Debian''' ships it in the '''iasl''' package (''apt-get install iasl'').<br /> * You can also download the [http://acpica.org/downloads/unix_source_code.php latest version of the source code].<br /> <br /> === How can I write to POSTcard port 0x80 from userspace? ===<br /> <br /> [http://www.linuxbios.org/pipermail/linuxbios/2006-November/017012.html This] might be useful in some situations, and to output a number to a POST card:<br /> <br /> printf &quot;\001&quot; | dd bs=1 seek=128 of=/dev/port<br /> <br /> In DOS (not Windows XP) use:<br /> mov al, 42; out al, 80h<br /> To output 42 type<br /> o 80 42<br /> in DOS debug.exe.<br /> <br /> === Is coreboot applying x86 microcode patches? ===<br /> <br /> And if yes, can they be modified?<br /> <br /> Answer: Yes, coreboot is applying microcode patches on AMD and Intel CPUs. However, this field is little documented, so coreboot uses only unmodified, vendor-provided microcode. Few people think, that system design can seriously be improved by modifications here ( µCode patches mostly disable erraneous functions and opcodes).<br /> <br /> === How can I retrieve a good video BIOS? ===<br /> <br /> Note: If you are following these instructions to build coreboot for your motherboard, this is only necessary if you have a motherboard with an embedded VGA card. If your VGA is a PCI / PCI-Express add-on card, coreboot will find and run the ROM by itself.<br /> <br /> Anton Borisov has released a number of tools under the GPL (v2) to extract the VGA BIOS from the BIOS ROM images provided by the supplier of your motherboard.<br /> <br /> You can download them here:<br /> <br /> * Award BIOS:<br /> ** http://kaos.ru/biosgfx/download/awardeco-0.2.src.tar.gz<br /> ** http://ftp.debian.org/debian/pool/main/a/awardeco/awardeco_0.2.orig.tar.gz<br /> * AMI BIOS:<br /> ** http://www.kaos.ru/biosgfx/download/AmiDeco_0.31e.src.tar.gz<br /> ** http://ftp.debian.org/debian/pool/main/a/amideco/amideco_0.31e.orig.tar.gz<br /> * Phoenix BIOS:<br /> ** http://www.kaos.ru/biosgfx/download/PhoenixDeco_0.33.src.tar.gz<br /> ** http://ftp.debian.org/debian/pool/main/p/phnxdeco/phnxdeco_0.33.orig.tar.gz<br /> * Insyde BIOS:<br /> ** http://www.kaos.ru/biosgfx/download/InsyDeco_0.3.src.tar.gz<br /> ** (no alternative download location available, sorry)<br /> <br /> See the [[Tyan S2881|Tyan S2881 Build Tutorial]] for more information on how to use these tools.<br /> <br /> == Can I put coreboot into a PCI expansion ROM? ==<br /> <br /> Short answer: NO.<br /> <br /> Long answer:<br /> <br /> There's little use in doing that, as a lots of initialization has already been done by the proprietary BIOS (or coreboot) by the time the PCI expansion ROM is executed. It won't be possible to run coreboot from a PCI expansion ROM after a proprietary BIOS has already been running for instance.<br /> <br /> Note: The Intel ICH7 southbridge seems to allows booting from PCI ROMs ('''not''' arbitrary PCI expansion ROMs as used on graphics cards, SCSI controllers, etc.) -- maybe this should be investigated in order to check if or how it might be useful.<br /> <br /> == Obsolete FAQ items ==<br /> <br /> Please see [[FAQ/Obsolete]] for (probably) obsolete FAQ items.</div>

Hailfinger http://www.coreboot.org/Mailinglist 2010-04-13T18:40:34Z

<p>Hailfinger: More info about the flashrom mailing list, most of it being redirects to flashrom.org</p> <hr /> <div>The coreboot project currently runs three mailing lists:<br /> <br /> '''coreboot'''<br /> <br /> For questions and general information about coreboot, please subscribe to the [http://www.coreboot.org/mailman/listinfo/coreboot coreboot mailing list]. Note: This list currently gets an average of about 1000-1500 mails per month. If you're not subscribed, your post will be held temporarily for moderator approval (to combat spam).<br /> <br /> '''coreboot-announce'''<br /> <br /> If you want to get brief news about coreboot's progress, please subscribe to the [http://www.coreboot.org/mailman/listinfo/coreboot-announce coreboot-announce mailing list]. This list is moderated and will only get very few posts per month.<br /> <br /> '''flashrom'''<br /> <br /> [[Flashrom]] related mails are welcome on the [[Flashrom/Mailinglist|flashrom mailing list]]. Please note that the list is moderated for non-subscribers and we recommend to subscribe first. Please do not send BIOS images to the list.<br /> <br /> == Archives ==<br /> <br /> '''coreboot'''<br /> <br /> * A mailing list archive dating back as far as August 2002 can be found at http://www.coreboot.org/pipermail/coreboot/.<br /> * A complete archive of the coreboot-announce list can be found at http://www.coreboot.org/pipermail/coreboot-announce/.<br /> * A searchable (but incomplete) archive is available at http://www.mail-archive.com/linuxbios@clustermatic.org/.<br /> * Yet another (searchable) archive is available at http://blog.gmane.org/gmane.linux.bios/.<br /> <br /> '''coreboot-announce'''<br /> <br /> * http://www.coreboot.org/pipermail/coreboot-announce/<br /> <br /> '''flashrom'''<br /> <br /> * http://www.flashrom.org/pipermail/flashrom/<br /> <br /> == IRC ==<br /> <br /> You can also contact us via [[IRC]] if you prefer that.</div>

Hailfinger http://www.coreboot.org/GSoC 2010-03-19T15:56:21Z

<p>Hailfinger: /* flashrom */ link to flashrom gsoc page</p> <hr /> <div>= Google Summer of Code 2010 =<br /> <br /> http://3.bp.blogspot.com/_fxRR_bT3LgA/S5U3rk2J-eI/AAAAAAAACE8/mBRYQwSqvqQ/s400/2010_NoURL_300x267px.jpg<br /> <br /> Welcome to the [http://code.google.com/soc/ Google Summer of Code(tm)] page of the [[Welcome to coreboot|coreboot project]]. Apply for a coreboot GSoC project at http://socghop.appspot.com/.<br /> <br /> This year, coreboot also tries to host some flashrom projects.<br /> <br /> == Deadlines ==<br /> <br /> Make sure you check the [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline Deadlines]<br /> <br /> = Why work for coreboot =<br /> <br /> Why would you like to work for coreboot?<br /> <br /> * coreboot offers you the opportunity to work with modern technology &quot;right on the iron&quot;.<br /> * Your application will be available to users worldwide and promoted along with all other coreboot projects.<br /> * We are a very passionate team - so you will interact directly with the project initiators and project leaders. <br /> * We have a large, helpful community. Over 100 experts in hardware and firmware lurk on our mailing list, many of them waiting to help you.<br /> <br /> <br /> = Summer of Code Application =<br /> <br /> Please complete the standard [http://code.google.com/soc/ Google SoC 2010 application]. Additionally, please provide information on the following:<br /> <br /> # Who are you? What are you studying?<br /> # Why are you the right person for this task?<br /> # Do you have any other commitments that we should know about?<br /> # List your C, Assembler and hardware experience.<br /> # List your history with open source projects.<br /> # What is your preferred method of contact? (Phone, email, Skype, etc) <br /> <br /> Feel free to keep your application short. A 15 page essay is no better than a 2 page summary. If you wish to write 15 pages, you are of course welcome to do so, and we will gladly put your paper up on the web page. But it is not required for the application.<br /> <br /> == How to apply ==<br /> <br /> The Drupal project has a great page on [http://drupal.org/node/59037 How to write an SOC application].<br /> <br /> Please also read Google's [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Advice for Students].<br /> <br /> == Some Caveats ==<br /> <br /> * Google Summer-of-Code projects are a full (day-) time job. This means we expect roughly 30-40 hours per week on your project, during the three months of coding. Obviously we have flexibility, but if your schedule (exams, courses) does not give you this amount of spare time, then maybe you should not apply.<br /> * Getting paid by Google requires that you meet certain milestones. First, you must be in good standing with the community before the official start of the program. We suggest you post some design emails to the mailing list, and get feedback on them, both before applying, and during the &quot;community bonding period&quot; between acceptance and official start. Also, you must have made progress and committed significant code before the mid-term point.<br /> * We are thinking of requiring accepted students to have a blog, where you will write about your project on a regular basis. This is so that the community at large can be involved and help you. SoC is not a private contract between your mentor and you.<br /> <br /> Note that &quot;regular basis&quot; in the last item does _not_ mean &quot;3 days before evaluation deadlines&quot;. You should be &quot;around&quot; all the time (reporting your feedback, sending in partial successes).<br /> We don't expect our students to be experts in our problem domain, but we don't want you to fail because some basic misunderstanding was in your way of completing the task.<br /> <br /> == Time Frame ==<br /> <br /> '''DEADLINE FOR STUDENT APPLICATIONS:''' Students who are interested in working on a coreboot-related GSoC project must apply between '''March 29, 2010''' and '''April 9, 2010'''! If you want to apply, please get in contact with us right away, not just when you send your application!<br /> <br /> == Student requirements ==<br /> <br /> We will only accept your proposal if you have demonstrated that you can work with our codebase. For that, you have to send a patch to the list which is acceptable. Just ask for simple tasks on the mailing list or on IRC.<br /> <br /> = Contact =<br /> <br /> If you are interested in becoming a GSoC student, please contact [mailto:stepan@coresystems.de Stefan Reinauer].<br /> <br /> There is also an IRC channel on irc.freenode.net: #coreboot<br /> <br /> = Possible ideas =<br /> <br /> == Infrastructure for automatic code checking ==<br /> <br /> We already have a build bot that builds various configurations of coreboot. It would be nice to extend it with various code validation routines, for example:<br /> * Validate that there's no regression in doxygen documentation (eg. are all arguments to functions still explained in @param tags, eg. after new arguments were added?)<br /> * Make code lint clean (and maybe extend lint to not fall into our traps), and run lint over the tree. Report regressions<br /> * Use LLVM's static code checking facilities, report regressions.<br /> * Work on code coverage support for coreboot code (dump data into ram, or via serial. Provide tools to fetch it). Analyse that data.<br /> <br /> === Links ===<br /> * LLVM tools: [http://clang.llvm.org/StaticAnalysis.html Clang static analyser], [http://llvm.org/ProjectsWithLLVM/#Calysto SSA assertion checker]<br /> * Lint tools: [http://lclint.cs.virginia.edu/ Splint]<br /> * Coverage: [http://ltp.sourceforge.net/test/coverage/lcov.php LCOV], [http://ggcov.sourceforge.net GGCOV]<br /> <br /> === Mentors ===<br /> * [[User:MJones|Marc Jones]]<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == TianoCore on coreboot ==<br /> <br /> [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 /> === Links ===<br /> * [http://www.tianocore.org/ Tiano Core]<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 /> == 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 /> == coreboot mass-porting to AMD 780 series mainboards ==<br /> (since code is now available)<br /> <br /> == coreboot panic room ==<br /> (maybe just reuse the SerialICE core, too small project for full GSoC)<br /> <br /> == coreboot cheap testing rig ==<br /> create a cheap testing rig which works with the existing board test infrastructure<br /> <br /> == coreboot GeodeLX port from v3 to v4 ==<br /> significant parts of that are already done, so it's hard to fill a full GSoC with that. One thing could be &quot;verify that everything is brought over&quot;, but that's nothing that can be reasonably proven (and it might also be too close to &quot;documentation tasks&quot;, which are not allowed)<br /> <br /> == drivers for libpayload ==<br /> IDE, AHCI, Bluetooth, Firewire, Smartcards, maybe filesystems. Work towards making FILO only a shell, which uses libpayload for the &quot;real&quot; work. 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.<br /> <br /> == Board config infrastructure ==<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 /> == Payload infrastructure ==<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 /> == 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 /> === Already done ===<br /> <br /> Sorry, the list of ideas caused some people to attack and solve them. ;-)<br /> * flashrom under DOS (Rudolf Marek)<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>

Hailfinger http://www.coreboot.org/GSoC 2010-03-17T01:21:04Z

<p>Hailfinger: /* flashrom */ Elaborate a bit more</p> <hr /> <div>= Google Summer of Code 2010 =<br /> <br /> http://3.bp.blogspot.com/_fxRR_bT3LgA/S5U3rk2J-eI/AAAAAAAACE8/mBRYQwSqvqQ/s400/2010_NoURL_300x267px.jpg<br /> <br /> Welcome to the [http://code.google.com/soc/ Google Summer of Code(tm)] page of the [[Welcome to coreboot|coreboot project]]. Apply for a coreboot GSoC project at http://socghop.appspot.com/.<br /> <br /> This year, coreboot also tries to host some flashrom projects.<br /> <br /> == Deadlines ==<br /> <br /> Make sure you check the [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline Deadlines]<br /> <br /> = Why work for coreboot =<br /> <br /> Why would you like to work for coreboot?<br /> <br /> * coreboot offers you the opportunity to work with modern technology &quot;right on the iron&quot;.<br /> * Your application will be available to users worldwide and promoted along with all other coreboot projects.<br /> * We are a very passionate team - so you will interact directly with the project initiators and project leaders. <br /> * We have a large, helpful community. Over 100 experts in hardware and firmware lurk on our mailing list, many of them waiting to help you.<br /> <br /> <br /> = Summer of Code Application =<br /> <br /> Please complete the standard [http://code.google.com/soc/ Google SoC 2010 application]. Additionally, please provide information on the following:<br /> <br /> # Who are you? What are you studying?<br /> # Why are you the right person for this task?<br /> # Do you have any other commitments that we should know about?<br /> # List your C, Assembler and hardware experience.<br /> # List your history with open source projects.<br /> # What is your preferred method of contact? (Phone, email, Skype, etc) <br /> <br /> Feel free to keep your application short. A 15 page essay is no better than a 2 page summary. If you wish to write 15 pages, you are of course welcome to do so, and we will gladly put your paper up on the web page. But it is not required for the application.<br /> <br /> == How to apply ==<br /> <br /> The Drupal project has a great page on [http://drupal.org/node/59037 How to write an SOC application].<br /> <br /> Please also read Google's [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Advice for Students].<br /> <br /> == Some Caveats ==<br /> <br /> * Google Summer-of-Code projects are a full (day-) time job. This means we expect roughly 30-40 hours per week on your project, during the three months of coding. Obviously we have flexibility, but if your schedule (exams, courses) does not give you this amount of spare time, then maybe you should not apply.<br /> * Getting paid by Google requires that you meet certain milestones. First, you must be in good standing with the community before the official start of the program. We suggest you post some design emails to the mailing list, and get feedback on them, both before applying, and during the &quot;community bonding period&quot; between acceptance and official start. Also, you must have made progress and committed significant code before the mid-term point.<br /> * We are thinking of requiring accepted students to have a blog, where you will write about your project on a regular basis. This is so that the community at large can be involved and help you. SoC is not a private contract between your mentor and you.<br /> <br /> Note that &quot;regular basis&quot; in the last item does _not_ mean &quot;3 days before evaluation deadlines&quot;. You should be &quot;around&quot; all the time (reporting your feedback, sending in partial successes).<br /> We don't expect our students to be experts in our problem domain, but we don't want you to fail because some basic misunderstanding was in your way of completing the task.<br /> <br /> == Time Frame ==<br /> <br /> '''DEADLINE FOR STUDENT APPLICATIONS:''' Students who are interested in working on a coreboot-related GSoC project must apply between '''March 29, 2010''' and '''April 9, 2010'''! If you want to apply, please get in contact with us right away, not just when you send your application!<br /> <br /> == Student requirements ==<br /> <br /> We will only accept your proposal if you have demonstrated that you can work with our codebase. For that, you have to send a patch to the list which is acceptable. Just ask for simple tasks on the mailing list or on IRC.<br /> <br /> = Contact =<br /> <br /> If you are interested in becoming a GSoC student, please contact [mailto:stepan@coresystems.de Stefan Reinauer].<br /> <br /> There is also an IRC channel on irc.freenode.net: #coreboot<br /> <br /> = Possible ideas =<br /> <br /> == Infrastructure for automatic code checking ==<br /> <br /> We already have a build bot that builds various configurations of coreboot. It would be nice to extend it with various code validation routines, for example:<br /> * Validate that there's no regression in doxygen documentation (eg. are all arguments to functions still explained in @param tags, eg. after new arguments were added?)<br /> * Make code lint clean (and maybe extend lint to not fall into our traps), and run lint over the tree. Report regressions<br /> * Use LLVM's static code checking facilities, report regressions.<br /> * Work on code coverage support for coreboot code (dump data into ram, or via serial. Provide tools to fetch it). Analyse that data.<br /> <br /> === Links ===<br /> * LLVM tools: [http://clang.llvm.org/StaticAnalysis.html Clang static analyser], [http://llvm.org/ProjectsWithLLVM/#Calysto SSA assertion checker]<br /> * Lint tools: [http://lclint.cs.virginia.edu/ Splint]<br /> * Coverage: [http://ltp.sourceforge.net/test/coverage/lcov.php LCOV], [http://ggcov.sourceforge.net GGCOV]<br /> <br /> === Mentors ===<br /> * [[User:MJones|Marc Jones]]<br /> * [[User:Stepan|Stefan Reinauer]]<br /> <br /> == TianoCore on coreboot ==<br /> <br /> [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 /> === Links ===<br /> * [http://www.tianocore.org/ Tiano Core]<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 /> == coreboot port to AMD 800 series chipsets ==<br /> (probably too big of a task)<br /> <br /> == coreboot mass-porting to AMD 780 series mainboards ==<br /> (since code is now available)<br /> <br /> == coreboot panic room ==<br /> (maybe just reuse the SerialICE core, too small project for full GSoC)<br /> <br /> == coreboot cheap testing rig ==<br /> create a cheap testing rig which works with the existing board test infrastructure<br /> <br /> == coreboot GeodeLX port from v3 to v4 ==<br /> significant parts of that are already done, so it's hard to fill a full GSoC with that. One thing could be &quot;verify that everything is brought over&quot;, but that's nothing that can be reasonably proven (and it might also be too close to &quot;documentation tasks&quot;, which are not allowed)<br /> <br /> == drivers for libpayload ==<br /> IDE, AHCI, Bluetooth, Firewire, Smartcards, maybe filesystems. Work towards making FILO only a shell, which uses libpayload for the &quot;real&quot; work. 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.<br /> <br /> == Board config infrastructure ==<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 /> == 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 /> === 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 /> === Already done ===<br /> <br /> Sorry, the list of ideas caused some people to attack and solve them. ;-)<br /> * flashrom under DOS (Rudolf Marek)<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>

Hailfinger http://www.coreboot.org/Welcome_to_coreboot 2010-03-16T01:56:07Z

<p>Hailfinger: RS780/SB700 now supported</p> <hr /> <div>&lt;table width=&quot;100%&quot; valign=&quot;top&quot;&gt;&lt;tr valign=&quot;top&quot;&gt;&lt;td width=&quot;80%&quot;&gt;<br /> <br /> &lt;div style=&quot;margin-top:0.5em; margin-bottom:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;&quot;&gt;<br /> '''coreboot''' (formerly known as LinuxBIOS) is a Free Software project aimed at replacing the proprietary BIOS (firmware) you can find in most of today's computers. It performs just a little bit of hardware initialization and then executes a so-called [[Payloads|payload]].<br /> <br /> With this separation of hardware initialization and later boot logic, coreboot is capable of scaling from specialized applications run directly from firmware, operating systems in Flash, and custom bootloaders to implementations of firmware standards like PCBIOS and EFI without having to carry features not necessary in the target application, reducing the amount of code and flash space required.<br /> <br /> We currently support '''[[Supported Motherboards|214]]''' different mainboards.<br /> <br /> &lt;/div&gt;<br /> <br /> {| cellspacing=0 cellpadding=8 border=0 margin=0 padding=0 align=&quot;top&quot; width=100%<br /> |-<br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {{Box|<br /> BORDER = #8898bf|<br /> BACKGROUND = yellow|<br /> WIDTH = 100%|<br /> ICON = &lt;small&gt;[[Benefits|More...]]&lt;/small&gt;|<br /> HEADING = &lt;span style=&quot;font-variant:small-caps; font-size:120%&quot;&gt;[[Benefits]]&lt;/span&gt;|<br /> CONTENT =<br /> &lt;small&gt;<br /> * 100% Free Software (GPL), no royalties, no license fees!<br /> * Fast boot times (3 seconds to Linux console)<br /> &lt;!-- * Avoids the need for a slow/buggy/proprietary BIOS --&gt;<br /> &lt;!-- * Runs in 32-Bit protected mode almost from the start --&gt;<br /> &lt;!-- * Written in C, contains virtually no assembly code --&gt;<br /> * Supports many [[Supported Motherboards|mainboards]], [[Supported Chipsets and Devices|chipsets]], and [[payloads]]<br /> &lt;!-- * Further features: netboot, serial console, remote flashing, ... --&gt;<br /> &lt;/small&gt;<br /> }}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {{Box|<br /> BORDER = #8898bf|<br /> BACKGROUND = #d1adf6|<br /> WIDTH = 100%|<br /> ICON = &lt;small&gt;[[Use Cases|More...]]&lt;/small&gt;|<br /> HEADING = &lt;span style=&quot;font-variant:small-caps; font-size:120%&quot;&gt;[[Use Cases]]&lt;/span&gt;|<br /> CONTENT =<br /> &lt;small&gt;<br /> * Desktop PCs and servers<br /> * [[Clusters]]<br /> &lt;!-- * Set-Top-Boxes, thin clients --&gt;<br /> * Embedded solutions<br /> &lt;!-- * [http://en.wikipedia.org/wiki/Small_form_factor Small form factor computers], [http://en.wikipedia.org/wiki/Home_theater_PC Home-theater PCs] --&gt;<br /> &lt;!-- * No-moving-parts solutions (ROM chip as &quot;disk&quot;) --&gt;<br /> &lt;!-- * Non-standard scenarios (e.g. FPGA in Opteron socket) --&gt;<br /> &lt;/small&gt;<br /> }}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {{Box|<br /> BORDER = #8898bf|<br /> BACKGROUND = lime|<br /> WIDTH = 100%|<br /> ICON = &lt;small&gt;[[Payloads|More...]]&lt;/small&gt;|<br /> HEADING = &lt;span style=&quot;font-variant:small-caps; font-size:120%&quot;&gt;[[Payloads]]&lt;/span&gt;|<br /> CONTENT =<br /> &lt;small&gt;<br /> * [[FILO]] / [http://grub.enbug.org/CoreBoot GRUB2] &lt;!-- / [[OpenFirmware]] / [[OpenBIOS]] --&gt;<br /> * [[Linux]] / [[Booting Windows using coreboot|Windows]] / [[Booting FreeBSD using coreboot|FreeBSD]]&lt;!-- / [[Coreboot and NetBSD|NetBSD]] / [http://openbsd.org/ OpenBSD]--&gt;<br /> * [[Etherboot]]<br /> &lt;!--* [[SeaBIOS]] / [[Memtest86]]<br /> * [[Etherboot]] / [[GPXE]]<br /> * [[Bayou]] / [[Coreinfo]] / [[Tint]] / [[Libpayload]]--&gt;<br /> &lt;/small&gt;<br /> }}<br /> <br /> |}<br /> <br /> {| cellspacing=5 cellpadding=15 border=0 valign=&quot;top&quot; width=100%<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_cb.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;About&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Find out more about coreboot.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[Press]] | [[Logo]] | [[History]] | [[Screenshots|Screenshots/Videos]] | [[Contributors]] | [[Sponsors]] | [[Products]] | [[Clusters]] | [[Vendors]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_devel.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;Developers&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Get involved! Help us make coreboot better.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[Development Guidelines]] | [[Developer Manual]] | [http://qa.coreboot.org/docs/doxygen.php Doxygen] | [http://tracker.coreboot.org/trac/coreboot/browser/trunk Browse Source] | [[GSoC]] | [[SerialICE]]&lt;/small&gt;<br /> |}<br /> <br /> |-<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_status.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;Status&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Find out whether your hardware is already supported.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[Supported Motherboards|Supported Boards]] | [[Supported Chipsets and Devices|Supported Chipsets]] | [http://qa.coreboot.org Build Status]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_tools.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;Related Tools&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Tools and libraries related to coreboot.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[Flashrom]] | [[Superiotool]] | [[Nvramtool]] | [[Buildrom]] | [[Mkelfimage]] | [[Inteltool]] | [[Msrtool]] | [[Ectool]] | [[Developer_Manual/Tools|Hardware tools]]&lt;/small&gt;<br /> |}<br /> <br /> |-<br /> | width=50% style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_101.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;Getting Started&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Download coreboot and get started.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[Build HOWTO]] | [[Download coreboot|Downloads]] | [[Documentation]] | [[:Category:Tutorials|Board Tutorials]] | [[QEMU]] | [[AMD SimNow]]&lt;/small&gt;<br /> |}<br /> <br /> |style=&quot;vertical-align:top&quot;|<br /> <br /> {|<br /> |style=&quot;vertical-align:top&quot;|<br /> [[Image:chip_support.png]]<br /> |style=&quot;vertical-align:top&quot;|<br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;Support&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Learn how to contact us and find help and support.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[FAQ]] | [[Mailinglist]] | [[IRC]] | [http://tracker.coreboot.org/trac/coreboot/ Issue Tracker] | [[Glossary]] | [[coreboot Options|coreboot Options]]&lt;/small&gt;<br /> |}<br /> <br /> |}<br /> &lt;/td&gt;&lt;td width=&quot;20%&quot;&gt;<br /> <br /> [[File:Coreboot menuconfig.png|center|thumb|[[Build HOWTO|make menuconfig]] in coreboot]]<br /> <br /> &lt;br clear=all /&gt;<br /> <br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:120%&quot;&gt;[[News]]&lt;/span&gt;'''&lt;hr /&gt;<br /> &lt;!-- Please always make this list 7 items long (7 most recent news items). --&gt;<br /> &lt;small&gt;<br /> * '''2010/03/15:''' [[News#2010.2F03.2F15_AMD_RS780_and_SB700_now_supported|AMD RS780 and SB700 now supported]]<br /> * '''2010/03/05:''' [[News#2010.2F03.2F05_ASUS_P2B-LS_now_supported|ASUS P2B-LS now supported]]<br /> * '''2010/01/17:''' [[News#2010.2F01.2F17_Roda_RK886EX_.28Rocky_III.2B.29_now_supported|Roda RK886EX (Rocky III+) support]]<br /> * '''2009/10/21:''' [[News#2009.2F10.2F21_HP_e-Vectra_P2706T_now_supported|HP e-Vectra P2706T support]]<br /> * '''2009/10/13:''' [[News#2009.2F10.2F13_MSI_MS-6156_now_supported|MSI MS-6156 support]]<br /> * '''2009/10/13:''' [[News#2009.2F10.2F13_TechNexion_TIM-5690_now_supported|TechNexion TIM-5690 support]]<br /> * '''2009/09/25:''' [[News#2009.2F09.2F25_coreboot_on_the_cover_of_the_Linux_Journal|coreboot @ Linux Journal]]<br /> &lt;/small&gt;<br /> <br /> <br /> '''&lt;span style=&quot;font-variant:small-caps; font-size:120%&quot;&gt;[[Current events|Upcoming Events]]&lt;/span&gt;'''&lt;hr /&gt;<br /> &lt;!-- List of upcoming events (remove events after they have taken place). --&gt;<br /> &lt;small&gt;<br /> &lt;!-- * '''2009/mon/day:''' coreboot event at [[Link]] in somecity --&gt;<br /> * Currently none.<br /> &lt;/small&gt;<br /> <br /> &lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;<br /> <br /> __NOTOC__<br /> __NOEDITSECTION__</div>

Hailfinger http://www.coreboot.org/Datasheets 2010-03-11T15:06:42Z

<p>Hailfinger: </p> <hr /> <div>This page lists '''publically available datasheets''' and programming guides from various vendors. It includes CPU, chipset, Super I/O, and many other datasheets.<br /> <br /> If datasheets are expected to become public in the near future, they may get listed as well to make sure people know what to expect.<br /> <br /> = CPU =<br /> <br /> == AMD K8 ==<br /> <br /> * AMD K8 BKDG (BIOS and kernel developer's guide) [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26094.PDF revision E] and [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf revision F]<br /> <br /> == AMD Fam10 ==<br /> <br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.PDF AMD Fam10 BKDG] (BIOS and kernel developer's guide)<br /> <br /> == VIA Padlock ==<br /> <br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=181&amp;fid=281 Security Application note]<br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=181&amp;fid=261 PadLock Programming Guide]<br /> <br /> = Northbridge =<br /> <br /> == AMD RS690 ==<br /> <br /> * [http://developer.amd.com/gpu_assets/43372_rs690_rrg_3.00o.pdf AMD RS690 RRG] (Register Reference Guide)<br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/41977_rs690_ds_3.06.pdf AMD RS690 Databook]<br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/41978_rs690m_ds_3.06.pdf AMD RS690M Databook]<br /> * [http://support.amd.com/us/Embedded_TechDocs/42437_m690t_ds_3_08.pdf AMD M690T/E Databook]<br /> <br /> == AMD RS780 ==<br /> <br /> * [http://developer.amd.com/Assets/43291_rs780_rpr_pub_1.01.pdf AMD RS780 Register Programming Requirements]<br /> * [http://developer.amd.com/Assets/43451_rs780_rrg_pub_1.01.pdf AMD RS780 ASIC Family Register Reference Guide]<br /> * [http://developer.amd.com/Assets/43734_rs780_bdg_pub_1.01.pdf AMD RS780 ASIC Family BIOS Developer’s Guide]<br /> * [http://developer.amd.com/assets/45732_rs780e_ds_pub_3.10.pdf AMD RS780E Databook]<br /> <br /> Apparently there are other docs as well, not sure if they provide any additional information or if they are part of the public documents above:<br /> * AMD RD780 Register Reference Guide<br /> * AMD RX780 Register Reference Guide<br /> * AMD RS780M Hybrid Graphics – System BIOS Detailed Design Document (Publication #44969)<br /> * AMD RD790 Register Programming Requirements (Publication #42462)<br /> * AMD RD790 Register Reference Guide (Publication #42988)<br /> * AMD RD790 BIOS Developer's Guide (Publication #43093)<br /> <br /> == AMD RD890 ==<br /> Not public (yet?). However, some of the information may be contained in the public docs in the RS780 section<br /> <br /> * AMD RD890 BIOS Developer's Guide (Publication #43606)<br /> * AMD RD890 Register Reference Guide (Publication #43607)<br /> <br /> == VIA CX700M/VX700 ==<br /> <br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=141&amp;fid=221 VIA CX700M/VX700 Programming Manual]<br /> <br /> == VIA VX800 ==<br /> <br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=161&amp;fid=241 VIA VX800 Programming Manual]<br /> <br /> = Southbridge =<br /> <br /> == AMD SB600 ==<br /> <br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/46155_sb600_rrg_pub_3.03.pdf AMD SB600 RRG] (Register Reference Guide)<br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/46156_sb600_rpr_pub_3.02b.pdf AMD SB600 RPR] (Register Programming Requirements)<br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/46157_sb600_bdg_pub300.pdf AMD SB600 BDG] (BIOS Developer's Guide)<br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/42119_sb600_ds_3.05.pdf AMD SB600 Databook]<br /> <br /> == AMD SB700/SB710/SB750 ==<br /> <br /> * [http://developer.amd.com/assets/43009_sb7xx_rrg_pub_1.00.pdf AMD SB700/710/750 Register Reference Guide]<br /> * [http://developer.amd.com/assets/43366_sb7xx_bdg_pub_1.00.pdf AMD SB700/710/750 BIOS Developer’s Guide]<br /> * [http://developer.amd.com/assets/42413_sb7xx_rpr_pub_1.00.pdf AMD SB700/710/750 Register Programming Requirements]<br /> * [http://developer.amd.com/assets/45215_sb710_ds_pub_1.25.pdf AMD SB710 Databook]<br /> <br /> == AMD SB800 ==<br /> Not available yet, but here are the numbers for the documents we'd like to get. I found these numbers with a creative internet search.<br /> <br /> * AMD SB800 Databook (Publication #44758)<br /> <br /> = Super I/O =<br /> <br /> == ITE ==<br /> <br /> * [http://www.ite.com.tw/EN/products_kind.aspx?CategoryID=3&amp;ID=5 PC Desktop/Notebook Super I/Os]<br /> ** [http://www.ite.com.tw/EN/products_kind.aspx?CategoryID=3&amp;ID=5 Desktop Super I/Os]<br /> ** [http://www.ite.com.tw/EN/products_kind.aspx?CategoryID=3&amp;ID=6 Notebook Super I/Os]<br /> <br /> == Winbond / Nuvoton ==<br /> <br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/ISASuperIO/ ISA Super I/Os]<br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/LPCSuperIOforDesktopAndServer/ LPC Super I/O for Desktop &amp; Server]<br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/AdvancedSuperIOforDesktop/ Advanced Super I/O for Desktop]<br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/AdvancedSuperIOforNotebook/ Advanced Super I/O for Notebook]<br /> <br /> == Fintek ==<br /> <br /> * [http://www.fintek.com.tw/eng/products.asp?BID=1&amp;SID=17&amp;layer=0 Super Hardware Monitor + SIO]<br /> <br /> == NSC ==<br /> <br /> (bought by Winbond, now Nuvoton)<br /> <br /> == ALi ==<br /> <br /> == SMSC ==<br /> <br /> * [http://www.smsc.com/main/catalog/ioprods.html Products / datasheets overview]<br /> * [http://www.smsc.com/main/datasheet.html Various product datasheets]<br /> <br /> = Other =<br /> <br /> * [http://www.amd.com/us-en/Processors/TechnicalResources/1,,30_182_739,00.html AMD public documents]<br /> ** The [http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_15872,00.html AMD64 Embedded Processors and Chipset Linux Support] web page features links to supported projects (like coreboot) and links to documentation.<br /> <br /> = Resources =<br /> <br /> There are many datasheet archives on the web which may have other (usually older) datasheets which already disappeared from vendor websites.</div>

Hailfinger http://www.coreboot.org/Datasheets 2010-03-11T15:04:43Z

<p>Hailfinger: /* AMD RS780 */ Add some mysterious documents to the RS780 list, create a new RD890 list</p> <hr /> <div>This page lists '''publically available datasheets''' and programming guides from various vendors. It includes CPU, chipset, Super I/O, and many other datasheets.<br /> <br /> = CPU =<br /> <br /> == AMD K8 ==<br /> <br /> * AMD K8 BKDG (BIOS and kernel developer's guide) [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26094.PDF revision E] and [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf revision F]<br /> <br /> == AMD Fam10 ==<br /> <br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.PDF AMD Fam10 BKDG] (BIOS and kernel developer's guide)<br /> <br /> == VIA Padlock ==<br /> <br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=181&amp;fid=281 Security Application note]<br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=181&amp;fid=261 PadLock Programming Guide]<br /> <br /> = Northbridge =<br /> <br /> == AMD RS690 ==<br /> <br /> * [http://developer.amd.com/gpu_assets/43372_rs690_rrg_3.00o.pdf AMD RS690 RRG] (Register Reference Guide)<br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/41977_rs690_ds_3.06.pdf AMD RS690 Databook]<br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/41978_rs690m_ds_3.06.pdf AMD RS690M Databook]<br /> * [http://support.amd.com/us/Embedded_TechDocs/42437_m690t_ds_3_08.pdf AMD M690T/E Databook]<br /> <br /> == AMD RS780 ==<br /> <br /> * [http://developer.amd.com/Assets/43291_rs780_rpr_pub_1.01.pdf AMD RS780 Register Programming Requirements]<br /> * [http://developer.amd.com/Assets/43451_rs780_rrg_pub_1.01.pdf AMD RS780 ASIC Family Register Reference Guide]<br /> * [http://developer.amd.com/Assets/43734_rs780_bdg_pub_1.01.pdf AMD RS780 ASIC Family BIOS Developer’s Guide]<br /> * [http://developer.amd.com/assets/45732_rs780e_ds_pub_3.10.pdf AMD RS780E Databook]<br /> <br /> Apparently there are other docs as well, not sure if they provide any additional information or if they are part of the public documents above:<br /> * AMD RD780 Register Reference Guide<br /> * AMD RX780 Register Reference Guide<br /> * AMD RS780M Hybrid Graphics – System BIOS Detailed Design Document (Publication #44969)<br /> * AMD RD790 Register Programming Requirements (Publication #42462)<br /> * AMD RD790 Register Reference Guide (Publication #42988)<br /> * AMD RD790 BIOS Developer's Guide (Publication #43093)<br /> <br /> == AMD RD890 ==<br /> Not public (yet?). However, some of the information may be contained in the public docs in the RS780 section<br /> <br /> * AMD RD890 BIOS Developer's Guide (Publication #43606)<br /> * AMD RD890 Register Reference Guide (Publication #43607)<br /> <br /> == VIA CX700M/VX700 ==<br /> <br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=141&amp;fid=221 VIA CX700M/VX700 Programming Manual]<br /> <br /> == VIA VX800 ==<br /> <br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=161&amp;fid=241 VIA VX800 Programming Manual]<br /> <br /> = Southbridge =<br /> <br /> == AMD SB600 ==<br /> <br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/46155_sb600_rrg_pub_3.03.pdf AMD SB600 RRG] (Register Reference Guide)<br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/46156_sb600_rpr_pub_3.02b.pdf AMD SB600 RPR] (Register Programming Requirements)<br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/46157_sb600_bdg_pub300.pdf AMD SB600 BDG] (BIOS Developer's Guide)<br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/42119_sb600_ds_3.05.pdf AMD SB600 Databook]<br /> <br /> == AMD SB700/SB710/SB750 ==<br /> <br /> * [http://developer.amd.com/assets/43009_sb7xx_rrg_pub_1.00.pdf AMD SB700/710/750 Register Reference Guide]<br /> * [http://developer.amd.com/assets/43366_sb7xx_bdg_pub_1.00.pdf AMD SB700/710/750 BIOS Developer’s Guide]<br /> * [http://developer.amd.com/assets/42413_sb7xx_rpr_pub_1.00.pdf AMD SB700/710/750 Register Programming Requirements]<br /> * [http://developer.amd.com/assets/45215_sb710_ds_pub_1.25.pdf AMD SB710 Databook]<br /> <br /> == AMD SB800 ==<br /> Not available yet, but here are the numbers for the documents we'd like to get. I found these numbers with a creative internet search.<br /> <br /> * AMD SB800 Databook (Publication #44758)<br /> <br /> = Super I/O =<br /> <br /> == ITE ==<br /> <br /> * [http://www.ite.com.tw/EN/products_kind.aspx?CategoryID=3&amp;ID=5 PC Desktop/Notebook Super I/Os]<br /> ** [http://www.ite.com.tw/EN/products_kind.aspx?CategoryID=3&amp;ID=5 Desktop Super I/Os]<br /> ** [http://www.ite.com.tw/EN/products_kind.aspx?CategoryID=3&amp;ID=6 Notebook Super I/Os]<br /> <br /> == Winbond / Nuvoton ==<br /> <br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/ISASuperIO/ ISA Super I/Os]<br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/LPCSuperIOforDesktopAndServer/ LPC Super I/O for Desktop &amp; Server]<br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/AdvancedSuperIOforDesktop/ Advanced Super I/O for Desktop]<br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/AdvancedSuperIOforNotebook/ Advanced Super I/O for Notebook]<br /> <br /> == Fintek ==<br /> <br /> * [http://www.fintek.com.tw/eng/products.asp?BID=1&amp;SID=17&amp;layer=0 Super Hardware Monitor + SIO]<br /> <br /> == NSC ==<br /> <br /> (bought by Winbond, now Nuvoton)<br /> <br /> == ALi ==<br /> <br /> == SMSC ==<br /> <br /> * [http://www.smsc.com/main/catalog/ioprods.html Products / datasheets overview]<br /> * [http://www.smsc.com/main/datasheet.html Various product datasheets]<br /> <br /> = Other =<br /> <br /> * [http://www.amd.com/us-en/Processors/TechnicalResources/1,,30_182_739,00.html AMD public documents]<br /> ** The [http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_15872,00.html AMD64 Embedded Processors and Chipset Linux Support] web page features links to supported projects (like coreboot) and links to documentation.<br /> <br /> = Resources =<br /> <br /> There are many datasheet archives on the web which may have other (usually older) datasheets which already disappeared from vendor websites.</div>

Hailfinger http://www.coreboot.org/Datasheets 2010-03-11T14:31:16Z

<p>Hailfinger: /* AMD SB800 */</p> <hr /> <div>This page lists '''publically available datasheets''' and programming guides from various vendors. It includes CPU, chipset, Super I/O, and many other datasheets.<br /> <br /> = CPU =<br /> <br /> == AMD K8 ==<br /> <br /> * AMD K8 BKDG (BIOS and kernel developer's guide) [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26094.PDF revision E] and [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf revision F]<br /> <br /> == AMD Fam10 ==<br /> <br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.PDF AMD Fam10 BKDG] (BIOS and kernel developer's guide)<br /> <br /> == VIA Padlock ==<br /> <br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=181&amp;fid=281 Security Application note]<br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=181&amp;fid=261 PadLock Programming Guide]<br /> <br /> = Northbridge =<br /> <br /> == AMD RS690 ==<br /> <br /> * [http://developer.amd.com/gpu_assets/43372_rs690_rrg_3.00o.pdf AMD RS690 RRG] (Register Reference Guide)<br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/41977_rs690_ds_3.06.pdf AMD RS690 Databook]<br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/41978_rs690m_ds_3.06.pdf AMD RS690M Databook]<br /> * [http://support.amd.com/us/Embedded_TechDocs/42437_m690t_ds_3_08.pdf AMD M690T/E Databook]<br /> <br /> == AMD RS780 ==<br /> <br /> * [http://developer.amd.com/Assets/43291_rs780_rpr_pub_1.01.pdf AMD RS780 Register Programming Requirements]<br /> * [http://developer.amd.com/Assets/43451_rs780_rrg_pub_1.01.pdf AMD RS780 ASIC Family Register Reference Guide]<br /> * [http://developer.amd.com/Assets/43734_rs780_bdg_pub_1.01.pdf AMD RS780 ASIC Family BIOS Developer’s Guide]<br /> * [http://developer.amd.com/assets/45732_rs780e_ds_pub_3.10.pdf AMD RS780E Databook]<br /> <br /> == VIA CX700M/VX700 ==<br /> <br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=141&amp;fid=221 VIA CX700M/VX700 Programming Manual]<br /> <br /> == VIA VX800 ==<br /> <br /> * [http://linux.via.com.tw/support/beginDownload.action?eleid=161&amp;fid=241 VIA VX800 Programming Manual]<br /> <br /> = Southbridge =<br /> <br /> == AMD SB600 ==<br /> <br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/46155_sb600_rrg_pub_3.03.pdf AMD SB600 RRG] (Register Reference Guide)<br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/46156_sb600_rpr_pub_3.02b.pdf AMD SB600 RPR] (Register Programming Requirements)<br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/46157_sb600_bdg_pub300.pdf AMD SB600 BDG] (BIOS Developer's Guide)<br /> * [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/42119_sb600_ds_3.05.pdf AMD SB600 Databook]<br /> <br /> == AMD SB700/SB710/SB750 ==<br /> <br /> * [http://developer.amd.com/assets/43009_sb7xx_rrg_pub_1.00.pdf AMD SB700/710/750 Register Reference Guide]<br /> * [http://developer.amd.com/assets/43366_sb7xx_bdg_pub_1.00.pdf AMD SB700/710/750 BIOS Developer’s Guide]<br /> * [http://developer.amd.com/assets/42413_sb7xx_rpr_pub_1.00.pdf AMD SB700/710/750 Register Programming Requirements]<br /> * [http://developer.amd.com/assets/45215_sb710_ds_pub_1.25.pdf AMD SB710 Databook]<br /> <br /> == AMD SB800 ==<br /> Not available yet, but here are the numbers for the documents we'd like to get. I found these numbers with a creative internet search.<br /> <br /> * AMD SB800 Databook (Publication #44758)<br /> <br /> = Super I/O =<br /> <br /> == ITE ==<br /> <br /> * [http://www.ite.com.tw/EN/products_kind.aspx?CategoryID=3&amp;ID=5 PC Desktop/Notebook Super I/Os]<br /> ** [http://www.ite.com.tw/EN/products_kind.aspx?CategoryID=3&amp;ID=5 Desktop Super I/Os]<br /> ** [http://www.ite.com.tw/EN/products_kind.aspx?CategoryID=3&amp;ID=6 Notebook Super I/Os]<br /> <br /> == Winbond / Nuvoton ==<br /> <br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/ISASuperIO/ ISA Super I/Os]<br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/LPCSuperIOforDesktopAndServer/ LPC Super I/O for Desktop &amp; Server]<br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/AdvancedSuperIOforDesktop/ Advanced Super I/O for Desktop]<br /> * [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/SuperIO/AdvancedSuperIOforNotebook/ Advanced Super I/O for Notebook]<br /> <br /> == Fintek ==<br /> <br /> * [http://www.fintek.com.tw/eng/products.asp?BID=1&amp;SID=17&amp;layer=0 Super Hardware Monitor + SIO]<br /> <br /> == NSC ==<br /> <br /> (bought by Winbond, now Nuvoton)<br /> <br /> == ALi ==<br /> <br /> == SMSC ==<br /> <br /> * [http://www.smsc.com/main/catalog/ioprods.html Products / datasheets overview]<br /> * [http://www.smsc.com/main/datasheet.html Various product datasheets]<br /> <br /> = Other =<br /> <br /> * [http://www.amd.com/us-en/Processors/TechnicalResources/1,,30_182_739,00.html AMD public documents]<br /> ** The [http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_15872,00.html AMD64 Embedded Processors and Chipset Linux Support] web page features links to supported projects (like coreboot) and links to documentation.<br /> <br /> = Resources =<br /> <br /> There are many datasheet archives on the web which may have other (usually older) datasheets which already disappeared from vendor websites.</div>

Hailfinger http://www.coreboot.org/GSoC 2010-03-07T00:44:06Z

<p>Hailfinger: GSoC 2010</p> <hr /> <div>= Google Summer of Code 2010 =<br /> <br /> This year, coreboot and flashrom are applying as one big project.<br /> <br /> == Deadlines ==<br /> <br /> http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline<br /> <br /> == Ideas ==<br /> <br /> === coreboot ===<br /> <br /> * coreboot port to AMD 800 series chipsets (probably too big of a task)<br /> * coreboot mass-porting to AMD 780 series mainboards (if the code is available until then)<br /> * coreboot panic room (maybe just reuse the SerialICE core, too small project for full GSoC)<br /> * coreboot cheap testing rig which works with the existing board test infrastructure<br /> * coreboot GeodeLX port from v3 to v4<br /> <br /> === flashrom ===<br /> <br /> Note: The list below is an idea collection. Many of the projects are simple enough to serve only as partial GSoC task<br /> <br /> * flashrom text mode GUI<br /> * flashrom graphics mode GUI (Sean Nelson has preliminary code)<br /> * flashrom as payload<br /> * flashrom under DOS<br /> * flashrom remote flashing for coreboot panic room mode<br /> * flashrom remote flashing with modified SerialICE<br /> * flashrom support for Nvidia SPI chipset hardware<br /> * flashrom support for Paraflasher hardware<br /> * flashrom support for RayeR SPIPGM 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<br /> * flashrom support for bitbanging Parallel<br /> * flashrom support for partial reflashing<br /> * flashrom support for automatic recovery in case something goes wrong<br /> * flashrom support for embedded controllers (ECs) in laptops<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 /> = Google Summer of Code 2009 =<br /> <br /> http://code.google.com/images/2009socwithlogo.gif<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 /> = Your own Projects =<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 below, and don't hesitate to suggest whatever you have in mind.<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:PatrickGeorgi|Patrick Georgi]]<br /> * [[User:MJones|Marc Jones]]<br /> * [[User:Stepan|Stefan Reinauer]]<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 /> === Links ===<br /> * [http://www.tianocore.org/ Tiano Core]<br /> <br /> === Mentors ===<br /> * [[User:Rminnich|Ron Minnich]]<br /> * [[User:Stepan|Stefan Reinauer]]<br /> * [[User:MJones|Marc Jones]]<br /> <br /> = Previous Summer of Code projects =<br /> <br /> We successfully participated in Google's Summer of Code in 2007 and 2008. See our [[Previous GSoC Projects|list of previous GSoC projects]].<br /> <br /> = Why work for coreboot =<br /> <br /> Why would you like to work for coreboot?<br /> <br /> * coreboot offers you the opportunity to work with modern technology &quot;right on the iron&quot;.<br /> * Your application will be available to users worldwide and promoted along with all other coreboot projects.<br /> * We are a very passionate team - so you will interact directly with the project initiators and project leaders. <br /> * We have a large, helpful community. Over 100 experts in hardware and firmware lurk on our mailing list, many of them waiting to help you.<br /> <br /> <br /> = Summer of Code Application =<br /> <br /> Please complete the standard [http://code.google.com/soc/ Google SoC 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 and hardware experience.<br /> # List your history with open source projects.<br /> # What is your preferred method of contact? (Phone, email, Skype, etc) <br /> <br /> Feel free to keep your application short. A 15 page essay is no better than a 2 page summary. If you wish to write 15 pages, you are of course welcome to do so, and we will gladly put your paper up on the web page. But it is not required for the application.<br /> <br /> == How to apply ==<br /> <br /> The Drupal project has a great page on [http://drupal.org/node/59037 How to write an SOC application].<br /> <br /> Please also read Google's [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Advice for Students].<br /> <br /> == Some Caveats ==<br /> <br /> * Google Summer-of-Code projects are a full (day-) time job. This means we expect roughly 30-40 hours per week on your project, during the three months of coding. Obviously we have flexibility, but if your schedule (exams, courses) does not give you this amount of spare time, then maybe you should not apply.<br /> * Getting paid by Google requires that you meet certain milestones. First, you must be in good standing with the community before the official start of the program. We suggest you post some design emails to the mailing list, and get feedback on them, both before applying, and during the &quot;community bonding period&quot; between acceptance and official start. Also, you must have made progress and committed significant code before the mid-term point.<br /> * We are thinking of requiring accepted students to have a blog, where you will write about your project on a regular basis. This is so that the community at large can be involved and help you. SoC is not a private contract between your mentor and you. <br /> <br /> == Time Frame ==<br /> <br /> '''DEADLINE FOR STUDENT APPLICATIONS:''' Students who are interested in working on a coreboot-related GSoC project must apply between '''March 23, 2009''' and '''April 3, 2009'''! If you want to apply, please get in contact with us right away!<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</div>

Hailfinger http://www.coreboot.org/Reverse_Engineering_PCI_Drivers 2010-02-25T00:46:29Z

<p>Hailfinger: /* Decoding traces */</p> <hr /> <div>by Vikram Ambrose -- [[User:Vambrose|Vambrose]] 01:44, 22 February 2010 (UTC)<br /> <br /> ==Getting traces==<br /> This is a short guide demonstrating how I used the PCI Passthrough framework in KVM to reverse engineer atiflash.exe – a video BIOS flashing tool for DOS.<br /> <br /> atiflash.exe is a real dos application that flashes the video BIOS on ATi graphics cards. There are numerous ATi video BIOS flashing tools for Windows, but none for Linux as the code for doing this has not been made publicly available by AMD.<br /> <br /> This technique allowed me to trace all PCI configuration space and memory mapped i/o (mmio) accesses to the PCI-E device from the closed source flashing tool.<br /> <br /> Tools needed:<br /> * CPU with virtualisation support (eg, AMD-V, Intel VT-x, an IOMMU is not necessary)<br /> * Newer-the-better Linux kernel with KVM support<br /> * Special KVM branch of QEMU (git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git)<br /> * Guest operating system (I used FreeDOS from UBCD - http://www.ultimatebootcd.com/)<br /> * Secondary video card to boot Linux with while the Radeon is used in the virtual machine<br /> <br /> In order to give the virtual machine direct pci access, the host operating system cannot register a driver for the device. In my case, this simply meant blacklisting the radeon and drm kernel modules.<br /> <br /> All the tracing is done from QEMU. Using the special qemu-kvm branch mentioned above, go into qemu-kvm/hw/device-assignments.c and ensure:<br /> <br /> #define DEVICE_ASSIGNMENT_DEBUG 1 <br /> <br /> This will turn on logging for assigned_dev_pci_{read,write}_config() functions (Config space) and slow_bar_read{b,w,l} and slow_bar_write{b,w,l} functions (MMIO). You may also want to add d-&gt;e_physbase to the prints to get the physical assigned address.<br /> <br /> In order to trace the write commands to the ROM space, you will need to write your own _write{b,w,l} functions. Eg:<br /> static void slow_rom_writeb(void *opaque, target_phys_addr_t addr, uint32_t val)<br /> {<br /> DEBUG(&quot; addr=0x&quot; TARGET_FMT_plx &quot; val=0x%02x\n&quot;, addr, val);<br /> }<br /> ...<br /> static CPUWriteMemoryFunc * const slow_rom_write[] = {<br /> &amp;slow_rom_writeb,<br /> &amp;slow_rom_writew,<br /> &amp;slow_rom_writel<br /> };<br /> <br /> Then register your function array in assigned_dev_iomem_map_slow(), Eg:<br /> ...<br /> if (region_num == PCI_ROM_SLOT)<br /> - m = cpu_register_io_memory(slow_bar_read, NULL, region);<br /> + m = cpu_register_io_memory(slow_bar_read, slow_rom_write, region);<br /> ...<br /> <br /> Now modify assigned_dev_register_regions() to get QEMU to use the slow path otherwise KVM will let the guest write directly to the device.<br /> ...<br /> if (cur_region-&gt;type &amp; IORESOURCE_MEM) {<br /> - int slow_map = 0;<br /> + int slow_map = 1;<br /> ...<br /> <br /> You can also get the Programmed I/O (PIO) by logging assigned_dev_ioport_{read,write)*(), but otherwise this should give you a good idea of what the flashing tool is doing.<br /> <br /> <br /> Now use lspci to get the location of the PCI device:<br /> 02:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870]<br /> 02:00.1 Audio device: ATI Technologies Inc HD48x0 audio<br /> <br /> Pass the device to qemu, along with your virtual machine disk image. Eg;<br /> <br /> qemu-system-x86 -hda disk.img -cdrom ubcd411.iso -boot order=d -pcidevice host=02:00:0,dma=none<br /> <br /> Run the flashing tool from the VM and watch the traces appear on the console.<br /> <br /> ==Decoding traces==<br /> Here are some traces from my trials (graciously decoded by Carl-D):<br /> * http://coreboot.pastebin.com/f73df946c<br /> * http://coreboot.pastebin.com/f3b85711d (complete decode with comments)<br /> * http://coreboot.pastebin.com/f6c21856e<br /> * http://coreboot.pastebin.com/YMYkrZGs (automated decode)<br /> <br /> ==Notes==<br /> Useful links:<br /> * VGA Bios database - http://www.techpowerup.com/vgabios/<br /> * Chapter 12, PCI device drivers of &quot;Linux Device Drivers (3rd Edition)&quot; by J.Corbet et al, downloadable for free from - http://lwn.net/Kernel/LDD3/<br /> * If you would like to use the same technique on a native Linux application/driver, see the mmiotrace project - http://nouveau.freedesktop.org/wiki/MmioTrace <br /> <br /> <br /> ''Special thanks go out to Carl-Daniel Hailfinger, Twice#11 and the entire KVM and QEMU team for making this possible.''</div>

Hailfinger http://www.coreboot.org/Reverse_Engineering_PCI_Drivers 2010-02-24T23:20:20Z

<p>Hailfinger: /* Decoding traces */ one more trace</p> <hr /> <div>by Vikram Ambrose -- [[User:Vambrose|Vambrose]] 01:44, 22 February 2010 (UTC)<br /> <br /> ==Getting traces==<br /> This is a short guide demonstrating how I used the PCI Passthrough framework in KVM to reverse engineer atiflash.exe – a video BIOS flashing tool for DOS.<br /> <br /> atiflash.exe is a real dos application that flashes the video BIOS on ATi graphics cards. There are numerous ATi video BIOS flashing tools for Windows, but none for Linux as the code for doing this has not been made publicly available by AMD.<br /> <br /> This technique allowed me to trace all PCI configuration space and memory mapped i/o (mmio) accesses to the PCI-E device from the closed source flashing tool.<br /> <br /> Tools needed:<br /> * CPU with virtualisation support (eg, AMD-V, Intel VT-x, an IOMMU is not necessary)<br /> * Newer-the-better Linux kernel with KVM support<br /> * Special KVM branch of QEMU (git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git)<br /> * Guest operating system (I used FreeDOS from UBCD - http://www.ultimatebootcd.com/)<br /> * Secondary video card to boot Linux with while the Radeon is used in the virtual machine<br /> <br /> In order to give the virtual machine direct pci access, the host operating system cannot register a driver for the device. In my case, this simply meant blacklisting the radeon and drm kernel modules.<br /> <br /> All the tracing is done from QEMU. Using the special qemu-kvm branch mentioned above, go into qemu-kvm/hw/device-assignments.c and ensure:<br /> <br /> #define DEVICE_ASSIGNMENT_DEBUG 1 <br /> <br /> This will turn on logging for assigned_dev_pci_{read,write}_config() functions (Config space) and slow_bar_read{b,w,l} and slow_bar_write{b,w,l} functions (MMIO). You may also want to add d-&gt;e_physbase to the prints to get the physical assigned address.<br /> <br /> In order to trace the write commands to the ROM space, you will need to write your own _write{b,w,l} functions. Eg:<br /> static void slow_rom_writeb(void *opaque, target_phys_addr_t addr, uint32_t val)<br /> {<br /> DEBUG(&quot; addr=0x&quot; TARGET_FMT_plx &quot; val=0x%02x\n&quot;, addr, val);<br /> }<br /> ...<br /> static CPUWriteMemoryFunc * const slow_rom_write[] = {<br /> &amp;slow_rom_writeb,<br /> &amp;slow_rom_writew,<br /> &amp;slow_rom_writel<br /> };<br /> <br /> Then register your function array in assigned_dev_iomem_map_slow(), Eg:<br /> ...<br /> if (region_num == PCI_ROM_SLOT)<br /> - m = cpu_register_io_memory(slow_bar_read, NULL, region);<br /> + m = cpu_register_io_memory(slow_bar_read, slow_rom_write, region);<br /> ...<br /> <br /> Now modify assigned_dev_register_regions() to get QEMU to use the slow path otherwise KVM will let the guest write directly to the device.<br /> ...<br /> if (cur_region-&gt;type &amp; IORESOURCE_MEM) {<br /> - int slow_map = 0;<br /> + int slow_map = 1;<br /> ...<br /> <br /> You can also get the Programmed I/O (PIO) by logging assigned_dev_ioport_{read,write)*(), but otherwise this should give you a good idea of what the flashing tool is doing.<br /> <br /> <br /> Now use lspci to get the location of the PCI device:<br /> 02:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870]<br /> 02:00.1 Audio device: ATI Technologies Inc HD48x0 audio<br /> <br /> Pass the device to qemu, along with your virtual machine disk image. Eg;<br /> <br /> qemu-system-x86 -hda disk.img -cdrom ubcd411.iso -boot order=d -pcidevice host=02:00:0,dma=none<br /> <br /> Run the flashing tool from the VM and watch the traces appear on the console.<br /> <br /> ==Decoding traces==<br /> Here are some traces from my trials (graciously decoded by Carl-D):<br /> * http://coreboot.pastebin.com/f73df946c<br /> * http://coreboot.pastebin.com/f3b85711d (complete decode with comments)<br /> * http://coreboot.pastebin.com/f6c21856e<br /> <br /> ==Notes==<br /> Useful links:<br /> * VGA Bios database - http://www.techpowerup.com/vgabios/<br /> * Chapter 12, PCI device drivers of &quot;Linux Device Drivers (3rd Edition)&quot; by J.Corbet et al, downloadable for free from - http://lwn.net/Kernel/LDD3/<br /> * If you would like to use the same technique on a native Linux application/driver, see the mmiotrace project - http://nouveau.freedesktop.org/wiki/MmioTrace <br /> <br /> <br /> ''Special thanks go out to Carl-Daniel Hailfinger, Twice#11 and the entire KVM and QEMU team for making this possible.''</div>

Hailfinger