https://www.coreboot.org/api.php?action=feedcontributions&user=Stepan&feedformat=atomcoreboot - User contributions [en]2024-03-29T05:08:35ZUser contributionsMediaWiki 1.40.0https://www.coreboot.org/index.php?title=ACPI&diff=30744ACPI2017-12-08T02:26:44Z<p>Stepan: /* Potential Issues */</p>
<hr />
<div>This page contains some (developer) documentation about how ACPI can be used in coreboot.<br />
<br />
= ACPI setup HOWTO =<br />
<br />
Please have a look at the files in [http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/mainboard/asus/a8v-e_se src/mainboard/asus/a8v-e_se]. Please also check out http://acpi.info, which contains the ACPI specification.<br />
<br />
== Set up hardware ==<br />
<br />
Set the '''PMIO base address''' to some known address, and set up the desired ACPI IRQ (usually IRQ9; sometimes it is called the SCI interrupt).<br />
<br />
== Fixed ACPI Description Table (FADT) ==<br />
<br />
You may skip this section if your SB has it already. Just call it from your MB ACPI setup code (check M2V-MX SE for details).<br />
<br />
Now you will need to create an ACPI table which describes the I/O port location for kernel ACPI implementation. This is the '''FACP''' table. You will need to create the '''fadt.c''' file and fill in the I/O port values plus IRQ:<br />
<br />
<pre><br />
fadt->sci_int = 9;<br />
fadt->pm1a_evt_blk = VT8237R_ACPI_IO_BASE;<br />
fadt->pm1b_evt_blk = 0x0;<br />
fadt->pm1a_cnt_blk = VT8237R_ACPI_IO_BASE + 0x4;<br />
fadt->pm1b_cnt_blk = 0x0;<br />
fadt->pm2_cnt_blk = 0x0;<br />
fadt->pm_tmr_blk = VT8237R_ACPI_IO_BASE + 0x8;<br />
fadt->gpe0_blk = VT8237R_ACPI_IO_BASE + 0x20;<br />
fadt->gpe1_blk = 0x0;<br />
</pre><br />
<br />
In this example the ACPI IRQ is 9, and the '''PM1A event block''' starts at VT8237R_ACPI_IO_BASE. You may obtain some values from '''cat /proc/ioport''' if running with the proprietary BIOS. Not all blocks are necessary&mdash;usually only PM1A PMTMR and GPE0 are used. Please note that this table has the I/O port information stored twice using different formats. Please consult the ACPI specification for details. Most settings in '''fadt.c''' can use their default values.<br />
<br />
If Linux complains about "IRQ 9 nobody cared", recheck these values. The gpeX_blk must span both status and enable bits (which is easy to get wrong given the unclear documentation on this). If GPE0_STS is 64bit, you have to configure 16 bytes (or 128 bits in the x_* variant).<br />
<br />
ACPI spec says to set only one of FIRMWARE_CTRL and X_FIRMWARE_CTRL, which is different to how other x_* values are handled. Set firmware_ctrl if located at <4GB, x_firmware_ctrl if located at >=4GB, and set the other value to 0. It's generally more useful to set firmware_ctrl (to support 32bit operating systems).<br />
<br />
== Differentiated System Description Table (DSDT) ==<br />
<br />
The '''DSDT table''' contains a bytecode that is executed by a driver in the kernel. This table stores also '''ACPI routing information''' in '''_PRT''' methods. You may add those _PRT methods later.<br />
<br />
==== Generic part of DSDT ====<br />
<br />
A very generic DSDT table would look similar to the ASUS A8V-E/ASUS M2V-MX SE [http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/mainboard/asus/a8v-e_se/dsdt.asl src/mainboard/asus/a8v-e_se/dsdt.asl] file.<br />
<br />
<pre><br />
Scope (\_PR)<br />
{<br />
Processor (\_PR.CPU0, 0x00, 0x000000, 0x00) {}<br />
Processor (\_PR.CPU1, 0x01, 0x000000, 0x00) {}<br />
}<br />
</pre><br />
<br />
This is here for compatibility. More interesting is:<br />
<br />
<pre><br />
/* For now only define 2 power states:<br />
* - S0 which is fully on<br />
* - S5 which is soft off<br />
* any others would involve declaring the wake up methods<br />
*/<br />
Name (\_S0, Package () {0x00, 0x00, 0x00, 0x00 })<br />
Name (\_S5, Package () {0x02, 0x02, 0x00, 0x00 })<br />
</pre><br />
<br />
This defines the SLP_TYP fields in PM1A register. In my case I need to store 010 to perform soft-off, and 000 to wake up. Modify it to fit your chipset needs.<br />
<br />
==== Interrupt routing in DSDT ====<br />
<br />
The _PRT methods define the routing, similar to PIR and MP Table.<br />
<br />
<pre><br />
Package (0x04) { 0x000BFFFF, 0x00, 0x00, 0x10 }, //slot 0xB<br />
Package (0x04) { 0x000BFFFF, 0x01, 0x00, 0x11 },<br />
Package (0x04) { 0x000BFFFF, 0x02, 0x00, 0x12 },<br />
Package (0x04) { 0x000BFFFF, 0x03, 0x00, 0x13 },<br />
</pre><br />
<br />
This defines the slot 0xB (all functions FFFF) routing as follows:<br />
<br />
<pre><br />
INTA -> IRQ16<br />
INTB -> IRQ17<br />
INTC -> IRQ18<br />
INTD -> IRQ19<br />
</pre><br />
<br />
Note: you cannot indicate the special functions like:<br />
<br />
<pre><br />
Package (0x04) { 0x000F0001, 0x00, 0x00, 0x14 }, // 0xf Native IDE IRQ 20<br />
</pre><br />
<br />
It means 0:0f.1 INTA is routed to IRQ20. Linux likes it. Windows does not (code 12). The ACPI standard requires that function is always 0xffff.<br />
<br />
Please note that the 0x10, 0x11 are called '''GSI (global system interrupt)'''. All your interrupts routed through first APIC will start with 0x00, second APIC will perhaps start at IRQ24 etc. This example has no support for legacy PIC routing. For PIC routing you would need to alter the rest of the fields in the _PRT package and also crete PIRQA-PIRQD special devices.<br />
<br />
The described above uses static IRQ assignments. Some chipsets like MPC55/CK804 have a configuration register which indicates what APIC pins are routed to what interrupt. Those typically use dynamic IRQ routing which provides a '''_CRS''' and '''_SRS''' methods to set such registers. For now, those registers are filled in MP-Table setup of each MCP55/CK804 board. All you need is to have static wiring like the MP-Table has.<br />
<br />
The rest of the file contains just some legacy devices to make certain OS installers happy. Don't forget to install the '''iasl''' compiler and also adjust the coreboot buildsystem to build the binary DSDT for you.<br />
<br />
=== CPU Power Management ===<br />
<br />
The CPU power management is hardware specific. It is described in ACPI specs and also in AMD BIOS and Kernel Developer guide. The rest of this section describes the AMD specific part. AMD needs ACPI objects which describe the similar info as the legacy PowerNow table. Check the BKDG for details.<br />
<br />
The content of the tables must be generated at runtime, which is a bit of a problem, because the AML code must be generated or DSDT patched. There is an '''acpigen''' infrastructure to generate the AML code.<br />
<br />
The actual content for family 0fh revF and later P-States can be generated by complex algorithm implemented in amd_model_fxx_generate_powernow(). This function should be called in acpi_fill_ssdt_generator() callback. Up to revE, all P state info must be hardcoded in tables (not supported).<br />
<br />
=== C States ===<br />
<br />
C states are processor power states. C1 is mandantory and reached on IA32 compatible processors using the HLT instruction, C2 and C3 are optional and must be configured.<br />
<br />
C states can be configured in ACPI using two methods:<br />
# by defining the P_BLK base address in the Processor() Definition, and P_LVLx_LAT values in the FADT<br />
# using the _CST object<br />
<br />
P_BLK is easier to configure, if the hardware supports that method. ACPI defines that there must be two registers at P_BLK+4 and P_BLK+5 that initiate a transition to C2 or C3 when the register is read. After sleep, the read returns 0. P_LVLx_LAT define the worst case latency of the state transition.<br />
<br />
_CST is necessary if you want to support more than 3 C states, or if the transition procedure doesn't follow the ACPI requirement.<br />
<br />
=== PCI root bus _CRS method ===<br />
<br />
Windows needs to know the actual decode ranges for PCI root bus (and any other). Windows needs to know platform independent way, how is I/O routed on PCI0 bus (and other busses). <br />
* For K8 this means to read the I/O and MMIO routing registers (same as '''k8resdump''' provides) and use them to create ACPI objects. The actual PCI regs are read in acpi-k8 in modelf and stored as SSDT table. The k8-util.asl code will construct the resources from that SSDT table. One can use the k8-util.asl code which will construct the resource objects. Check the ASUS M2V-MX mainboard ACPI code.<br />
* For i945 the required registers are read in the ASL code in northbridge/intel/i945/acpi/i945_hostbridge.asl.<br />
<br />
=== DSDT debugging ===<br />
<br />
There are two ways. You can store values in "debug" object, which will print it in dmesg. Check http://www.linuxhq.com/kernel/v2.6/28-rc6/Documentation/acpi/debug.txt how to turn that on. In DSDT use store method to write to Debug object. You can write buffers, ints etc:<br />
<br />
* Store ("The answer to the question of life, the universe, and everything is:", Debug) <br />
* Store (42, Debug) <br />
<br />
Second method is userspace interpretation of DSDT table. This can be achieved with ACPI CA Unix package. It is located in '''acpica-unix-20081204/tools/acpiexec'''. You can eval the objects and run the methods, like _CRS for example.<br />
<br />
If you receive a BSOD with '''STOP code 0xa5''', check this: http://support.microsoft.com/kb/314830.<br />
<br />
== Other tables ==<br />
<br />
Rest of the ACPI tables is located at acpi_tables.c. I will describe briefly all methods:<br />
<br />
=== acpi_fill_mcfg ===<br />
<br />
If your platform supports MMCONFIG (memory mapped PCI configuration registers, aka extended PCIe configuration) just modify the function with correct base address.<br />
<br />
=== acpi_fill_madt ===<br />
<br />
[[Image:ApicSystem.svg|thumb|right|A system with 8259s and APICs]] <br />
<br />
This table describes the ACPI IRQ information, as well as IRQ override. For code example check the M2V-MX SE acpi_tables. You will need to create the sub-table for LAPIC (the APIC counterpart in CPU) and describe the APICs and also deal with so called IRQ overrides. <br />
<br />
<br />
<br />
The interrupt sources are on the right side. The legacy IRQs and the PCI IRQs are connected to both APIC and 8259. <br />
<br />
In the legacy case, the APIC is programmed in virtual wire mode. It will just interconnect pin0 of APIC with its output, bypassing APIC completely. OS uses 8259s, and ignores APICs at all.<br />
<br />
The APIC should be in this mode in BIOS, to do that for your SB, check the setup_ioapic in vt8237r_lpc.c. Please note that there is some bit which also says if APIC is delivering through wires, or through FSB messages.<br />
<br />
<br />
<br />
Last thing in this table are IRQ overrides. Usually there are two IRQ overrides. IRQ0 override means that IRQ0 is not connected to pin 0 on APIC but to another, most likely pin 2. Check the figure above why. Second IRQ override is for ACPI IRQ. This overrides the 'level' of the interrupt to 'active low'. The rest of the table is filled with NMI entries for the processor.<br />
<br />
<br clear="all" /><br />
<br />
=== write_acpi_tables ===<br />
<br />
This is the main function which constructs the tables. Functions described above are callbacks from the "construct" functions called here. You may omit the HPET and MCFG tables.<br />
<br />
=== FACS table ===<br />
<br />
This table must be aligned to 64B boundary (Windows checks this).<br />
<br />
= Suspend to RAM =<br />
<br />
There are patches on the mailing list which add support for suspend to RAM in coreboot. The resume start of the computer does not differ until OS waking vector is executed instead of payload.<br />
<br />
Checklist of things which needs to be setup correctly:<br />
<br />
* Supend clocks, SUSA/B/C plane pins<br />
* Often the Super I/O has some pin to toggle the power for RAM<br />
* SLP_TYPE with S3 definition to your DSDT<br />
* Support for exit-self-refresh in your RAM controller<br />
* An NVRAM which stores the memory configuration, which is known runtime (DQS)<br />
* Chipset tweaks for S3 (like various signal delays)<br />
* CPU tweaks (for AMD the PM1 and PM2 registers and SMAF codes)<br />
* _RAMBASE of coreboot setup to 31MB and set LB_MEM_TOPK to 32MB<br />
* Make sure new code does not corrupt any memory<br />
* Make sure that you reserve _RAMBASE - LB_MEM_TOPK<br />
* SMP might need some fixes<br />
<br />
= Interfacing mainboard and EC ASL =<br />
<br />
Coreboot has strict requirements for interfacing EC and mainboard ACPI files. This is done in order to minimize the dependency on the preprocessor, and to provide efficient bytecode execution. This specification is documented in detail on [[ACPI/Board-EC_interaction | this page]].<br />
<br />
= ACPI bytecode generator =<br />
<br />
Some ACPI stuff is generated runtime. To achieve this goal we have a AML code generator which generates binary ACPI bytecode. Such code then resides typically in SSDT table. There is a helper function which creates such a table - acpi_create_ssdt_generator(). The content of the table is created through the callback function acpi_fill_ssdt_generator(). So far we have two big users of the generator k8acpi_write_vars() and amd_model_fxx_generate_powernow(). The first function will generate some runtime configuration of HT bus and PCI decode ranges. Second function generates the P-States.<br />
<br />
The available functions are in acpigen.h. Mostly there are functions generating some primitive named data structures. However sometimes it's necessary to put more data to a package. ACPI AML code needs to know the block lengths. The len is unknown until we have filled the payload of such package. Therefore when we are done, we need<br />
to call function acpigen_patch_len(int len) which will patch last object (package) which need patching. It uses stack internally so more structures can be nested. Look to acpigen.c and learn what functions call acpigen_write_len_f() - those needs patching.<br />
<br />
= Debugging ACPI =<br />
<br />
When CONFIG_ACPI_DEBUG is compiled into the kernel, the ACPI debug level can be specified on the kernel command line:<br />
<br />
acpi.debug_level=0x2003<br />
(warn, error und tables debug enabled)<br />
<br />
The values can be checked at runtime:<br />
# cat /sys/module/acpi/parameters/debug_level<br />
Description Hex SET <br />
ACPI_LV_ERROR 0x00000001 [*]<br />
ACPI_LV_WARN 0x00000002 [*]<br />
ACPI_LV_INIT 0x00000004 [*]<br />
ACPI_LV_DEBUG_OBJECT 0x00000008 [ ]<br />
ACPI_LV_INFO 0x00000010 [ ]<br />
ACPI_LV_INIT_NAMES 0x00000020 [ ]<br />
ACPI_LV_PARSE 0x00000040 [ ]<br />
ACPI_LV_LOAD 0x00000080 [ ]<br />
ACPI_LV_DISPATCH 0x00000100 [ ]<br />
ACPI_LV_EXEC 0x00000200 [ ]<br />
ACPI_LV_NAMES 0x00000400 [ ]<br />
ACPI_LV_OPREGION 0x00000800 [ ]<br />
ACPI_LV_BFIELD 0x00001000 [ ]<br />
ACPI_LV_TABLES 0x00002000 [ ]<br />
ACPI_LV_VALUES 0x00004000 [ ]<br />
ACPI_LV_OBJECTS 0x00008000 [ ]<br />
ACPI_LV_RESOURCES 0x00010000 [ ]<br />
ACPI_LV_USER_REQUESTS 0x00020000 [ ]<br />
ACPI_LV_PACKAGE 0x00040000 [ ]<br />
ACPI_LV_ALLOCATIONS 0x00100000 [ ]<br />
ACPI_LV_FUNCTIONS 0x00200000 [ ]<br />
ACPI_LV_OPTIMIZATIONS 0x00400000 [ ]<br />
ACPI_LV_MUTEX 0x01000000 [ ]<br />
ACPI_LV_THREADS 0x02000000 [ ]<br />
ACPI_LV_IO 0x04000000 [ ]<br />
ACPI_LV_INTERRUPTS 0x08000000 [ ]<br />
ACPI_LV_AML_DISASSEMBLE 0x10000000 [ ]<br />
ACPI_LV_VERBOSE_INFO 0x20000000 [ ]<br />
ACPI_LV_FULL_TABLES 0x40000000 [ ]<br />
ACPI_LV_EVENTS 0x80000000 [ ]<br />
--<br />
debug_level = 0x00000007 (* = enabled)<br />
<br />
= Random ACPI wisdom =<br />
== Windows Errors ==<br />
At first, not an error, but something to take note: Windows might cache system information and only detect ACPI changes if you modify the table versions. So tweak them liberally when debugging ACPI issues with Windows.<br />
<br />
=== STOP 0xa5 ===<br />
A Blue Screen Of Death with STOP code 0x000000A5 is ACPI related, and it seems that Microsoft is very strict when it comes to ACPI compliance. https://support.microsoft.com/en-us/kb/314830 explains some of the error codes, but not all of them.<br />
* Parameter1 == 0x00001000 means that some memory resource is claimed by ACPI that, according to memory tables, belongs to the OS. Parameter3 is the start address, Parameter4 is the length of the range. They can probably be found somewhere in the ASL code.<br />
<br />
* Parameter1 == 0x0000000D means that some _ADR or _HID Symbol is missing in the dsdt.asl.<br />
* Parameter1 == 0x00000011 is "something in the ACPI init". This can be (among other things)<br />
** improper object names, like an object "\._PR_foo" inside the "\._PR" scope (it should be just "foo" instead, or the surrounding scope killed)<br />
** the use of qwords, which XP doesn't like (known error code tuple in this case: (0x11, 0x8, address of SSDT, unknown value))<br />
** improper aml code, acpica as used by Linux is very lenient. (Wrong length field encoding in new acpigen code led to (0x11, 0x8, address of SSDT, unknown value))<br />
<br />
The documentation of windbg has more detailed information about STOP 0xa5 than the MSDN article.<br />
STOP 0xa5 can be debugged by using checked builds of ntoskrnl and hal.dll and a second machine connected with a null-modem cable and windbg as kernel debugger.<br />
<br />
=== "unexpected error" in Windows XP / Server 2003 setup ===<br />
(from http://www.coreboot.org/pipermail/coreboot/2011-May/065179.html)<br />
<br />
Windows XP or Server 2003 setup might fail with an error message such as:<br />
<br />
"An unexpected error (805262864) occurred at line 1768 of d:\xpclient\base\boot\setup\arcdisp.c"<br />
<br />
The value 805262864 varies, and is the physical address, in decimal, of one of the ACPI tables.<br />
<br />
The error message is displayed when a 1024 dword page table array used by setupldr runs out of space.<br />
<br />
This table is used for mapping various physical addresses, such as those of ACPI tables (a separate table identity maps the lower 16MB used by setupldr code and data). Setupldr only looks at ACPI tables (FACP) to determine make and model of the system. The make and model of the system is needed when setupldr scans the good/bad bios lists contained in txtsetup.sif. The good/bad bios lists are used to bypass installation of the ACPI enabled kernel on certain systems known to have ACPI problems. The code loop that scans the lists creates a new mapping each time it reads an ACPI table, and never frees mappings. The code uses FACP OEM ID to determine the system model. The code sequentially reads tables listed in the RSDT array until the FACP is found. Each read consumes one page table entry. If more that 4 tables precede the FACP in the RSDT array, the 1024 entry page table array will run out of space before the good/bad bios list processing completes.<br />
<br />
BIOS can work around this Windows XP/Server 2003 limitation by placing the FACP early in the RSDT array.<br />
<br />
=== Other errors ===<br />
* Quoting [http://support.microsoft.com/?scid=kb%3Ben-us%3B935806&x=14&y=18 MSDN]: A "Stop: 0x0000007E" error message or a "Stop: 0x0000008E" error message typically means that a kernel mode component, such as a driver, encountered an error that could not be handled by the built-in Windows error handler.<br />
<br />
=== Using checked builds ===<br />
There's a faulty assert in acpi.sys that trips only on checked builds. Get rid of "else" statements in ASL code that the compiler can't optimize away (ie. "if () { Return Foo } else { Return Bar }" is changed to "if () { Return Foo } Return Bar" and thus won't trigger this assert). We primarily had that with acpigen generated ElseOps (since those see no optimizer pass).<br />
<br />
=== Don't nest scopes improperly ===<br />
Windows ACPI doesn't like<br />
Scope(\foo) {<br />
Name(\foo.bar) { ... }<br />
}<br />
<br />
Either make that <br />
Scope(\foo) {<br />
Name (bar) { .. }<br />
}<br />
or eliminate the scope:<br />
Name(\foo.bar) { ... }<br />
<br />
=== Removable Devices ===<br />
<br />
Windows does not like to install on removable devices. And some devices (like eMMC) are assumed to be removable, unless you tell Windows they are not, by adding a node under your eMMC controller device providing an _RMV method:<br />
<br />
/* eMMC is non-removable device */<br />
Device (CARD)<br />
{<br />
Name (_ADR, 0x00000008)<br />
Method(_RMV, 0x0, NotSerialized)<br />
{<br />
Return (0)<br />
}<br />
}<br />
<br />
== Linux Errors ==<br />
=== ACPI 2.0/3.0 without XSDT ===<br />
Linux 2.6.12.x requires an XSDT if the RSDP revision is larger than 0 as it's hardcoded to use that instead of the RSDT then. Fixed in later Linux versions.<br />
=== PCI Hotplug _BBN fail ===<br />
<br />
<br />
<br />
pci_hotplug: PCI Hot Plug PCI Core version: 0.5<br />
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5<br />
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5<br />
<br />
Add the following under PCI0 device to get rid of the error:<br />
Name(_ADR, 0) <br />
Name(_BBN, 0)<br />
== Random Notes ==<br />
=== Shutdown sequences differ between systems ===<br />
Success with shutting down a system from Windows doesn't mean that Linux properly shuts down the system (and this probably applies the other way around, too)<br />
<br />
= Further Resources =<br />
<br />
* A good FAQ: http://www.acpi.info/acpi_faq.htm<br />
* [ftp://ftp.suse.com/pub/people/trenn/ACPI_BIOS_on_Linux_guide/acpi_guideline_for_vendors.pdf ACPI BIOS Guideline for Linux] by Thomas Renninger<br />
* [http://lwn.net/Articles/237085/ How to debug ACPI Problems] by Thomas Renninger<br />
* [http://www.coreboot.org/pipermail/coreboot/2009-January/044210.html ACPI table dump script]<br />
* [http://en.opensuse.org/S2ram Suspend to RAM utility]<br />
* [http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/CPA002_WH06.ppt Windows Vista ACPI information, incl. advice on common problems in ACPI implementations]<br />
* [http://smackerelofopinion.blogspot.com/2010/03/debugging-acpi-using-acpiexec.html Debugging ACPI using acpiexec]<br />
* How events work [https://wiki.ubuntu.com/KernelTeam/HardwareEnableWithDSDT Ubuntu wiki DSDT]</div>Stepanhttps://www.coreboot.org/index.php?title=Board:lenovo/x201&diff=18518Board:lenovo/x2012016-05-14T00:25:25Z<p>Stepan: /* Flashing */ Thanks to Charles Goyard for a better diagram</p>
<hr />
<div>== Status ==<br />
Thanks for your interest in Lenovo X201 port.<br />
<br />
Issues:<br />
* Sometimes Gnome starts to think that battery is 10 time larger than real. Information from sysfs remains correct. Doesn't appear in newer gnome<br />
* Yellow USB port is not powered when computer is shut down or in S3.<br />
* Most times after suspend an EC IRQ hangs in the queue and all functions keys stopped working until cold boot.<br />
* '''Commit 456f495d broke USB and PCI-E''' (unable to boot from live ISO on USB), a hard reset to commit a3e41c08 fixed the boot issue, however the '''following issues occured/persisted''':<br />
** The X201 immedeatly powers off after resuming from suspend resulting a completely lost session sometimes (Race condition)<br />
** See http://review.coreboot.org/#/c/10352/ for more details<br />
<br />
Tested:<br />
* RAM module combinations of 4G+4G, 4G, 2G+2G,4G+2G, 2G<br />
* suspend to RAM (S3) '''(see issue mentioned above)'''<br />
* USB '''(see issues mentioned above)'''<br />
* Video (both internal and VGA)<br />
* Expresscard slot (including hotplug)<br />
* Sound<br />
* LAN<br />
* mini-PCIe slots (both wlan and wwan)<br />
* Linux (through GRUB-as-payload & SeaBIOS-as-payload)<br />
* Windows (through GRUB-as-payload loading SeaBIOS image from disk; you have to use extracted VGA blob, dumped from memory isn't good enough)<br />
* SD card slot<br />
* Thermal management<br />
* Fingerprint reader<br />
* Webcam<br />
* Bluetooth<br />
* Digitizer on X201t variant.<br />
<br />
Not tested:<br />
* Modem<br />
<br />
== proprietary components status ==<br />
* CPU Microcode<br />
* VGA Option ROM (optional): you need it if you want graphics in SeaBIOS but most payloads (e.g. GRUB2) work just fine without it (text mode or corebootfb mode)<br />
* [[Intel_Management_Engine|ME(Management Engine)] => you do not have to touch it (just leave it where it is)<br />
* EC(Embedded Controller) => you do not have to touch it (just leave it where it is)<br />
<br />
== Code ==<br />
{{MergedIntoMaster|review_url=http://review.coreboot.org/#/c/4514/}}<br />
<br />
== Flashing ==<br />
Flash in X201 is divided roughly in 4 parts:<br />
<br />
* Descriptor (12K)<br />
* ME firmware (5M-12K)<br />
* Rewriteable flash (3M-96K)<br />
* Locked bootblock (96K)<br />
<br />
Descriptor and bootblock are read-only. ME firmware is not readable.<br />
Rewriteable region can be rewritten easily with flashrom.<br />
<br />
For coreboot we need to preserve descriptor and ME firmware while overwriting<br />
rewriteable region and bootblock. To achieve this there are 2 ways:<br />
<br />
* External flasher.<br />
* Unlock bootblock<br />
<br />
For the first one proceeds as follows:<br />
* Turn off your laptop, remove battery and AC adapter.<br />
* Remove the keyboard.<br />
* Connect your external SPI flasher to the SPI chip which is under keyboard,<br />
around the position of trackpoint under protective layer. <br />
{|<br />
|[[File:Lenovo-x201-bios-location-arrow.png |200px|thumb|center|found it!]]<br />
|[[File:X201_flash_location.png |200px|thumb|center|under the keyboard]]<br />
|}<br />
[[File:Spi-soic8-25L6445E.png|200px|thumb|right|The flash chip]]<br />
<br />
I recommend using SOIC-8 clip. Depending on the flasher you use, you may have to use separate<br />
3.3V source. Make sure not to feed more than 3.3V ot the chip. I used<br />
buspirate as flasher and 3.3V power lines from another computer.<br />
The pinout is as follows, the colors are buspirate colors<br />
<br />
Screen (furthest from you)<br />
<br />
(red) (violet) (gray)<br />
3.3V N/C CLK MOSI<br />
_|_____|_____|_____|_<br />
| |<br />
| |<br />
|_____________________|<br />
| | | |<br />
CS MISO N/C GND<br />
(white) (black) (brown)<br />
<br />
Touchpad (closest to you)<br />
<br />
* Read the flash. Twice. Compare the files to be sure. Save a copy of it on external media.<br />
flashrom -p <yourprogrammer> -r flash.bin<br />
flashrom -p <yourprogrammer> -r flash2.bin<br />
diff flash.bin flash2.bin<br />
<br />
If you have trouble reading the chip successfully, the most common problems are<br />
*insufficient power supply <br />
*bad contacts<br />
*too long wires<br />
*bad pinout<br />
The cable shipped with buspirate was too long, and needed to be trimmed.<br />
<br />
See also [http://flashrom.org/ISP In-System Programming]<br />
<br />
<br />
* Recover descriptor and ME firmare:<br />
dd if=flash.bin of=coreboot/3rdparty/mainboard/lenovo/x201/descriptor.bin \<br />
count=12288 bs=1M iflag=count_bytes<br />
dd if=flash.bin of=coreboot/3rdparty/mainboard/lenovo/x201/me.bin \<br />
skip=12288 count=5230592 bs=1M iflag=count_bytes,skip_bytes<br />
* Compile coreboot. Remember to enable HAVE_IFD and HAVE_ME_BIN<br />
* Flash the resulting build/coreboot.rom<br />
<br />
The other way has never been successfully used but it's known that the<br />
locking mechanism is in bootblock itself and that original firmware has<br />
a way to update it as follows:<br />
* Flash an update of rewriteable region. On next boot bootblock parses the<br />
image and sees that it contains a compressed copy of new bootblock. That<br />
copy is uncompressed and flashed.<br />
A way to unlock the bootblock would be to modify a firmware update to have a<br />
copy of bootblock without protection. For this you need to compress the<br />
modified block to fit into original space. The compression used is Lempel-Ziv-<br />
Huffman variant. I've written a compressor for it but unfortunately it's not<br />
performant enough.<br />
<br />
<br />
===identify the regions===<br />
[root@x201 ~]# flashrom -r bios.bin -pinternal:laptop=force_I_want_a_brick<br />
flashrom v0.9.6.1-r1563 on Linux 3.10-1-grml-amd64 (x86_64)<br />
flashrom is free software, get the source code at http://www.flashrom.org<br />
<br />
Calibrating delay loop... OK.<br />
Found chipset "Intel QM57". Enabling flash write... WARNING: SPI Configuration Lockdown activated.<br />
FREG0: WARNING: Flash Descriptor region (0x00000000-0x00000fff) is read-only.<br />
FREG2: WARNING: Management Engine region (0x00003000-0x004fffff) is locked.<br />
PR0: WARNING: 0x007d0000-0x01ffffff is read-only.<br />
Please send a verbose log to flashrom@flashrom.org if this board is not listed on<br />
http://flashrom.org/Supported_hardware#Supported_mainboards yet.<br />
Writes have been disabled. You can enforce write support with the<br />
ich_spi_force programmer option, but it will most likely harm your hardware!<br />
If you force flashrom you will get no support if something breaks.<br />
OK.<br />
Found Macronix flash chip "MX25L6405" (8192 kB, SPI) at physical address 0xff800000.<br />
Reading flash... FAILED.<br />
<br />
it will print the ME regions:<br />
FREG2: WARNING: Management Engine region (0x00003000-0x004fffff) is locked.<br />
it will also print the chip:<br />
Found Macronix flash chip "MX25L6405" (8192 kB, SPI) at physical address 0xff800000.<br />
'''But as in this case, flashrom might misidentify the chip''', this output is from [[Media:Spi-soic8-25L6445E.png|this MX25L6445E]]<br />
<br />
visually verify your chip's part number and find an [http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/3F21BAC2E121E17848257639003A3146/$File/MX25L6445E,%203V,%2064Mb,%20v1.8.pdf appropriate datasheet ]<br />
<br />
=>verify that its voltage matches with the programmer voltage...<br />
* Use flashrom layouts:<br />
-l, --layout <file><br />
<br />
X201 Layout<br />
000000000:00000fff fd<br />
000001000:00002fff gbe<br />
000003000:004fffff me<br />
000500000:007fffff bios<br />
<br />
<br />
To flash only the bios partition (coreboot + payload) do:<br />
flashrom -l <layout> -i bios -w coreboot.rom</div>Stepanhttps://www.coreboot.org/index.php?title=Board:lenovo/x220&diff=18517Board:lenovo/x2202016-05-14T00:22:45Z<p>Stepan: /* Flashing */ Better diagram from Charles Goyard</p>
<hr />
<div>== Status ==<br />
Thanks for your interest in Lenovo X220 port.<br />
Issues:<br />
* no MRC cache (longer boot time)<br />
* yellow USB port isn't powered in power-off state.<br />
* Badly seated RAM may prevent booting (not really a problem but coreboot is more suspicious to this than vendor BIOS)<br />
<br />
Tested (and works):<br />
* RAM module combinations of 4G+0, 4G+4G, 8G+8G<br />
* S3 (Suspend to RAM)<br />
* Digitizer on x220t variant<br />
* WLAN (first minipcie slot)<br />
* Linux (through GRUB-as-payload)<br />
* Trackpoint<br />
* Fn hotkeys<br />
* Video (internal, VGA and Displayport, including native gfx init)<br />
* Touchpad<br />
* Battery indicator<br />
* Fingerprint reader<br />
* Thermal management<br />
* Webcam<br />
* Expresscard slot (including hotplugging)<br />
* USB (all 3 ports)<br />
* Bluetooth<br />
* SD card slot<br />
* LAN<br />
* Sound (integrated speakers, integrated mic, external headphones, external mic)<br />
* WWAN<br />
* WLAN slot USB<br />
* Windows (through SeaBIOS; you have to use extracted VGA blob, dumped from memory isn't good enough)<br />
* msata (second minipcie slot)<br />
* Thinklight<br />
* dock (Mini Dock Series 3 TYPE 4337 tested)<br />
<br />
Not tested:<br />
* USB 3.0 in some models (probably doesn't work)<br />
<br />
== proprietary components status ==<br />
* CPU Microcode<br />
* VGA option rom (optional): you need it if you want graphics in SeaBIOS but most payloads should work without it (text mode or corebootfb mode), SeaBIOS works with coreboot native gfx init<br />
* ME(Management Engine) => you do not have to touch it(just leave it where it is), but you can use a 1.5MB one from a sandybridge chromebook, to save some space<br />
* EC(Embedded Controller) => you do not have to touch it(just leave it where it is)<br />
<br />
== Flashing ==<br />
X220 has 1 flash chip of 8M. It's subdivided in roughly in 3 parts:<br />
<br />
* Descriptor (12K)<br />
* ME firmware (5M-12K)<br />
* System flash (7M)<br />
<br />
ME firmware is not readable.<br />
Vendor firmware locks the flash and so you need to flash externally (unless until someone figures out a way around it).<br />
<br />
<gallery><br />
File:X220_palmrest.jpg<br />
File:X220_flashchip.jpg<br />
File:X220_clip.jpg<br />
</gallery><br />
<br />
Proceeds as follows:<br />
* Turn off your laptop, remove battery and AC adapter.<br />
* Remove the keyboard.<br />
* Lift the left side of the plating (see pictures above)<br />
* Connect your external SPI flasher to the top SPI chip (pictured). It's a 8M chip. The chip is layout is as so:<br />
<br />
Screen (furthest from you)<br />
__<br />
MOSI 5 --| |-- 4 GND<br />
CLK 6 --| |-- 3 N/C<br />
N/C 7 --| |-- 2 MISO<br />
VCC 8 --|__|-- 1 CS<br />
<br />
Edge (closest to you)<br />
<br />
I recommend using SOIC clip, you can find a decent one from Pomona online. Depending on the flasher you use, you may have to use separate<br />
3.3V source. Make sure not to feed more than 3.3V to the chip. You can use any device such as <br />
Raspberry Pi, BeagleBoard or Buspirate -- the latter being the slowest. For how to wire up the<br />
clip, see [https://github.com/bibanon/Coreboot-ThinkPads/wiki/Hardware-Flashing-with-Raspberry-Pi this guide] (just for the setup). Then connect the clip to the chip, aligning it with the diagram above.<br />
<br />
* Read the flash. Twice. Compare the files to be sure. Save a copy of it on external media.<br />
flashrom -c "<yourchipname>" -p <yourprogrammer> -r flash.bin<br />
flashrom -c "<yourchipname>" -p <yourprogrammer> -r flash2.bin<br />
diff flash.bin flash2.bin<br />
<br />
If they don't match, do not proceed.<br />
<br />
* Recover descriptor and me firmware; you can use dd:<br />
dd if=flash.bin of=coreboot/3rdparty/blobs/mainboard/lenovo/x220/descriptor.bin \<br />
count=12288 bs=1M iflag=count_bytes<br />
dd if=flash.bin of=coreboot/3rdparty/blobs/mainboard/lenovo/x220/me.bin \<br />
skip=12288 count=5230592 bs=1M iflag=count_bytes,skip_bytes<br />
<br />
Or a much simpler solution is to just use ifdtool (coreboot/util/ifdtool, you may need to compile it):<br />
<br />
ifdtool -x </path/to/extracted/flash.bin><br />
<br />
Which will give you your flashdescriptor, bios, intel_me and gbe .bin files. <br />
<br />
* Compile coreboot. Before you do this, you will need to make a folder for the .bin files and copy them there:<br />
<br />
cd </path/to/coreboot><br />
mkdir -p 3rdparty/blobs/mainboard/lenovo/x220<br />
cd 3rdparty/blobs/mainboard/lenovo/x220<br />
cp </path/to/flashregion_0_flashdescriptor.bin> descriptor.bin<br />
cp <flashregion_2_intel_me.bin> me.bin<br />
cp <flashregion_3_gbe.bin> gbe.bin<br />
<br />
* Follow the [[Build HOWTO]] page and flash the resulting build/coreboot.rom<br />
<br />
If you have trouble reading the chip successfully,<br />
the most common problems are<br />
*insufficient power supply <br />
*bad contacts<br />
*too long wires<br />
*bad pinout<br />
The cable shipped with buspirate was too long, and needed to be trimmed.<br />
<br />
Once you are running coreboot any subsequent flashes can be done internally, however you will have to force flashrom:<br />
<br />
flashrom -c "<yourchip>" -p internal:laptop=force_I_want_a_brick <-r/-w> file.rom<br />
<br />
See also [http://flashrom.org/ISP In-System Programming]<br />
<br />
== Bigger SPI ROM ==<br />
<br />
Soldering in a bigger SPI ROM from the same manufacturer with the same specs except for size just works. I used a Winbond W25Q128FVSG and flashed the<br />
existing coreboot ROM for a 64mbit chip, due to the way the Intel Flash Descriptor works it still boots with a smaller image. For soldering I recommend a heat soldering gun. Disassemble the whole device, so the plasic doesn't melt, you could try using tin foil to protect the case and other components so you do not have to disassemble everything, but I do not recommend this, especially considering how easy it is to disassemble a thinkpad. If you try the tinfoil method and do not take the speakers out of the case they WILL melt. It looks like lenovo used lead free solder, so this will take a while until the solder is hot enough. Be careful not to heat the surrounding elements, you could accidentally dislodge them. CAREFULLY lift the chip, if the solder is not fully molten on both sides and you apply too much force, you will damage the board.<br />
<br />
To actually benefit from the bigger chip you need to modify the Intel Flash Descriptor. There are two changes you need to make: <br />
<br />
1. Change the flash layout to encompass the whole chip.<br />
<br />
2. change the chip density in the descriptor to the new size.<br />
<br />
<br />
You can do both with ifdtool, as long as it is recent enough. (I patched it to do 2. in early march 2016)<br />
<br />
For 1. run `ifdtool --layout layout.txt coreboot.rom`, edit the layout file and update it with `ifdtool --newlayout layout.txt coreboot.rom`. You may need to remove the overlap check in ifdtool as somehow that sometimes fails and prevents you from changing the layout. Make sure you run this on an actual image, not just the 4kb descriptor or ifdtool will segfault, as it tries to actually move the sections, not just change the layout in the header. In this case also pad the file to 16MB as we're increasing the size, this is not needed if you change to a smaller chip.<br />
<br />
my layout:<br />
00000000:00000fff fd<br />
00500000:00ffffff bios<br />
00003000:004fffff me<br />
00001000:00002fff gbe<br />
00fff000:00000fff pd<br />
00fff000:00ffffff res1<br />
00fff000:00ffffff res2<br />
00fff000:00ffffff res3<br />
00000000:00a0bfff ec<br />
<br />
if you use a smaller ME than the stock 5MB one you can also reduce the size of the me area:<br />
00000000:00000fff fd<br />
00183000:00ffffff bios<br />
00003000:00182fff me<br />
00001000:00002fff gbe<br />
00fff000:00000fff pd<br />
00fff000:00ffffff res1<br />
00fff000:00ffffff res2<br />
00fff000:00ffffff res3<br />
00000000:00a0bfff ec<br />
<br />
Layout of this file is:<br />
<start address>:<end address> <section name><br />
Start addresses need to end in 000 and end addresses in fff, due to the way the addresses are stored in the IFD. Note that the fd section needs to be at the start. Ignore pd, res[1,2,3] and ec.<br />
<br />
This should result in a coreboot.rom.new file.<br />
<br />
2. Run `ifdtool -D 16 coreboot.rom.new` to change the chip density to 128mbit. You can select a chip using -C but this doesn't matter because if there is no second chip the density is ignored and you cannot set it to 0 in this version of the IFD.<br />
<br />
Soldering in a second SPI chip doesn't just work because lenovo was cheap and left out a few required resistors, if you are up for an adventure you can try soldering them also in, but they are tiny smd ones. Theoretically should work.<br />
<br />
Now you can extract the new IFD (first 4k bytes) from the (probably now broken) coreboot image and <br />
build a new Image using it.<br />
<br />
Now you can flash it externally as internal flashing doesn't work with an IFD smaller than the chip present. From now on internal flashing should work.<br />
<br />
All of these steps can be done beforehand or on a different computer, but I did it in this order because I only got that one laptop and a raspberry pi for external flashing.</div>Stepanhttps://www.coreboot.org/index.php?title=Msrtool&diff=18250Msrtool2016-04-29T23:00:57Z<p>Stepan: </p>
<hr />
<div>'''msrtool''' is a small utility that dumps chipset-specific MSR registers.<br />
<br />
== Supported OSes and chipsets ==<br />
<br />
'''OSes:'''<br />
<br />
* Linux with /dev/cpu/*/msr<br />
* Darwin / OS X with DirectIO<br />
* FreeBSD with /dev/cpuctl*<br />
<br />
'''Chipsets:'''<br />
<br />
* AMD Geode GX2<br />
* AMD Geode LX<br />
* AMD Geode CS5536<br />
* AMD K8<br />
* Intel Pentium III and later<br />
<br />
== Installation ==<br />
<br />
'''Manual installation'''<br />
<br />
$ '''git clone http://review.coreboot.org/p/coreboot.git'''<br />
$ '''cd coreboot/util/msrtool'''<br />
$ '''./configure'''<br />
$ '''make'''<br />
$ '''sudo make install'''<br />
<br />
You can browse the [https://review.coreboot.org/gitweb/cgit/coreboot.git/tree/util/msrtool msrtool source code in cgit].<br />
<br />
== Usage ==<br />
<br />
Show basic information:<br />
<br />
$ '''msrtool'''<br />
<br />
Please see '''msrtool -h''' for information on various other options.<br />
<br />
<br />
{{PD-self}}</div>Stepanhttps://www.coreboot.org/index.php?title=SeaBIOS&diff=18249SeaBIOS2016-04-29T22:56:53Z<p>Stepan: /* Manual build */ gitweb -> cgit</p>
<hr />
<div>[http://seabios.org '''SeaBIOS'''] is an open-source legacy BIOS implementation which can be used as a coreboot [[Payloads|payload]]. It implements the standard [https://secure.wikimedia.org/wikipedia/en/wiki/BIOS BIOS] calling interfaces that a typical x86 proprietary BIOS implements.<br />
<br />
This page describes using SeaBIOS with coreboot. SeaBIOS can also run natively in [[QEMU]] and [http://bochs.sourceforge.net/ bochs] &mdash; see the [http://seabios.org SeaBIOS website] for information on non-coreboot uses.<br />
<br />
= Use cases =<br />
<br />
Any software requiring 16-bit BIOS services benefits from SeaBIOS (eg, Windows and DOS). SeaBIOS also enables booting Linux out of the box (using standard boot-loaders like GRUB and Syslinux).<br />
<br />
SeaBIOS supports booting from ATA hard drives, ATAPI CDROMs, USB hard drives, USB CDROMs, payloads in flash, and from [http://en.wikipedia.org/wiki/Option_ROM Option ROMs] (eg, SCSI or network cards). SeaBIOS can initialize and use a PS/2 keyboard or USB keyboard.<br />
<br />
== Windows ==<br />
<br />
SeaBIOS has been tested with Windows XP, Windows 2008, Windows Vista (64/32 bit), Windows 7 (32 bit and 64 bit).<br />
<br />
However, Windows has a very strict ACPI interpreter, and some coreboot boards do not have a complete [[ACPI|ACPI definition]]. As a result, some coreboot boards may fail during Windows boot (eg, it may fail with a '''STOP 0xA5''' code).<br />
<br />
Many boards do have working ACPI and are able to boot XP/Vista/Windows 7. Please check the board documentation or ask on the [[Mailinglist|mailing list]] if unsure of the status.<br />
<br />
== Linux ==<br />
<br />
SeaBIOS has been tested with GRUB, LILO, and Syslinux. Linux booting works well.<br />
<br />
== Other ==<br />
<br />
SeaBIOS has also been tested with FreeDOS, NetBSD, and OpenBSD.<br />
<br />
Because SeaBIOS implements the standard x86 BIOS interfaces, it is expected many other operating systems and boot-loaders will work.<br />
<br />
= Building =<br />
<br />
== Building via coreboot's menuconfig ==<br />
<br />
Probably the easiest way to use SeaBIOS as coreboot payload is to simply use the coreboot build process, which downloads and builds SeaBIOS as payload by default nowadays. You just have to run the following in your coreboot checkout:<br />
<br />
<source lang="bash"><br />
$ make menuconfig<br />
$ make<br />
</source><br />
<br />
Both SeaBIOS and coreboot will be built, and SeaBIOS will be added as payload to the '''coreboot.rom''' image that is being built.<br />
<br />
== Manual build ==<br />
<br />
One can download the latest version of SeaBIOS through a git repository:<br />
<br />
<source lang="bash"><br />
$ git clone git://git.seabios.org/seabios.git seabios<br />
$ cd seabios<br />
</source><br />
<br />
There's also a [https://review.coreboot.org/gitweb/cgit/seabios.git/ cgit] facility to browse the latest source code online.<br />
<br />
Run '''make menuconfig''' and set the following variables:<br />
<br />
* CONFIG_COREBOOT 1<br />
* CONFIG_DEBUG_SERIAL 1<br />
<br />
Then:<br />
<br />
<source lang="bash"><br />
$ make<br />
</source><br />
<br />
The final SeaBIOS payload file is '''out/bios.bin.elf'''.<br />
<br />
== coreboot ==<br />
<br />
Configure coreboot with the following all disabled: '''CONFIG_VGA_ROM_RUN''', '''CONFIG_PCI_ROM_RUN''', '''CONFIG_ON_DEVICE_ROM_RUN'''<br />
<br />
Then configure the SeaBIOS '''out/bios.bin.elf''' file as the coreboot payload and build coreboot. The resulting '''coreboot.rom''' file will contain both SeaBIOS and coreboot, and it can be flashed to a ROM chip.<br />
<br />
= SeaBIOS and CBFS =<br />
<br />
SeaBIOS can read the coreboot flash filesystem and extract files. Details on the CBFS files that SeaBIOS supports are on the [http://seabios.org/Runtime_config SeaBIOS wiki].<br />
<br />
The following examples show some commonly used features.<br />
<br />
== Adding a VGA option ROM ==<br />
<br />
It is frequently necessary to add a VGA option ROM to CBFS in order to use a VGA adapter that is built-in to a motherboard. Note, VGA adapters on external cards (PCI, AGP, PCIe) do not require this step as SeaBIOS will automatically extract the VGA BIOS directly from the card. For machines without a VGA adapter, please follow the [[#Adding sgabios support|sgabios instructions]] below.<br />
<br />
=== Using your BIOS's VGA option rom ===<br />
The first step is to find the vendor and device ID of the built-in VGA adapter. This information can be found from '''lspci''':<br />
<br />
<source lang="bash"><br />
$ lspci -vnn<br />
...<br />
01:00.0 VGA compatible controller [0300]: VIA Technologies, Inc. UniChrome Pro IGP ['''1106:3344'''] (rev 01) (prog-if 00 [VGA controller])<br />
</source><br />
<br />
In the above example, the VGA vendor/device ID is '''1106:3344'''. [[VGA support#How_to_retrieve_a_good_video_bios|Obtain the VGA ROM]] (eg, '''vgabios.bin''') and add it to the ROM with:<br />
<br />
<source lang="bash"><br />
$ ./build/cbfstool build/coreboot.rom add -f /path/to/vgabios.bin -n pci1106,3344.rom -t raw<br />
$ ./build/cbfstool build/coreboot.rom print<br />
</source><br />
<br />
Alternatively, SeaBIOS supports LZMA compressed option ROMs. Use the following to add a compressed option ROM instead:<br />
<br />
<source lang="bash"><br />
$ ./build/cbfstool build/coreboot.rom add -f /path/to/vgabios.bin -c lzma -n pci1106,3344.rom.lzma -t raw<br />
$ ./build/cbfstool build/coreboot.rom print<br />
</source><br />
<br />
After the above is done, one can write the '''coreboot.rom''' file to flash. SeaBIOS will extract the VGA ROM and run it during boot.<br />
<br />
=== Adding sgabios support ===<br />
<br />
An [http://code.google.com/p/sgabios/ sgabios] option ROM can forward many VGA BIOS requests and keyboard events over a serial port. One can deploy it in addition to the primary VGA BIOS or by itself.<br />
<br />
If the target machine does not have a VGA adapter, then one should install sgabios. Most bootloaders (eg, GRUB) require a VGA BIOS in order to function properly &mdash; the sgabios ROM can fill this requirement.<br />
<br />
Place the sgabios ROM file in the '''vgaroms/''' directory of CBFS. For example:<br />
<br />
<source lang="bash"><br />
$ ./build/cbfstool build/coreboot.rom add -f /path/to/sgabios.bin -n vgaroms/sgabios.bin -t raw<br />
$ ./build/cbfstool build/coreboot.rom print<br />
</source><br />
<br />
When using sgabios, all the characters that SeaBIOS writes to the screen will be seen twice &mdash; once from SeaBIOS sending the character to the serial port and once from sgabios forwarding the character. To prevent the duplicates set the [[#Other Configuration items|config file]] '''etc/screen-and-debug''' to zero.<br />
<br />
=== Using coreboot VGA support ===<br />
Coreboot can initialize the GPU of some mainboards. After initializing the GPU, the information about it is passed to the payload.<br />
<br />
SeaBIOS can provide an option rom that implements legacy VGA BIOS compatibility for coreboot initialized GPUs. To use this feature select '''CONFIG_VGA_COREBOOT''' (in "make menuconfig" under "VGA ROM ---> VGA Hardware Type" select "coreboot linear framebuffer").<br />
<br />
The resulting option rom is in '''out/vgabios.rom'''. It can be added to '''coreboot.rom''' the same way one would add [[SeaBIOS#Adding_sgabios_support|sgabios]].<br />
<br />
=== Geode option roms ===<br />
There are two VGA option roms for geode in SeaBIOS, they can be found in "VGA ROM --->" in "make menuconfig":<br />
<br />
* The first one is for the Geode LX, its named "GeodeLX" in "make menuconfig"<br />
* The second one if for the Geode GX2, its named "Geode GX2" in "make menuconfig"<br />
<br />
== Adding a graphical "bootsplash" image ==<br />
<br />
SeaBIOS can show a custom [http://en.wikipedia.org/wiki/JPEG JPEG] image or [http://en.wikipedia.org/wiki/BMP_file_format BMP] image during bootup. To enable this, add the JPEG file to flash with the name '''bootsplash.jpg''' or BMP file as '''bootsplash.bmp'''. For example:<br />
<br />
<source lang="bash"><br />
$ ./build/cbfstool build/coreboot.rom add -f /path/to/image.jpg -n bootsplash.jpg -t raw<br />
$ ./build/cbfstool build/coreboot.rom print<br />
</source><br />
<br />
The size of the image determines the video mode to use for showing the image. Make sure the dimensions of the image exactly correspond to an available video mode (eg, 640x480, or 1024x768), otherwise it will not be displayed.<br />
<br />
SeaBIOS will show the image during the wait for the boot menu (if the boot menu has been disabled, users will not see the image). The image should probably have "Press F12 for boot menu" embedded in it so users know they can enter the normal SeaBIOS boot menu. By default, the boot menu prompt (and thus graphical image) is shown for 2.5 seconds. This can be customized via a [[#Other Configuration items|configuration parameter]].<br />
<br />
The JPEG viewer in SeaBIOS uses a simplified decoding algorithm. It supports most common JPEGs, but does not support all possible formats. Please see the [[#Trouble reporting|Trouble reporting]] section if a valid image isn't displayed properly.<br />
<br />
== Adding gpxe support ==<br />
<br />
A [[GPXE|gpxe]] option ROM can nicely complement SeaBIOS and coreboot by adding network boot support. Adding gpxe is similar to [[#Adding a VGA option ROM]]. The first step is to find the Ethernet vendor/device ID. For example:<br />
<br />
<source lang="bash"><br />
$ lspci -vnn<br />
...<br />
00:09.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet ['''10ec:8167'''] (rev 10)<br />
</source><br />
<br />
Then one can build a gpxe option ROM. For example:<br />
<br />
<source lang="bash"><br />
$ cd /path/to/gpxe/src/<br />
$ make bin/10ec8167.rom<br />
</source><br />
<br />
And add it to the coreboot image. For example:<br />
<br />
<source lang="bash"><br />
$ ./build/cbfstool build/coreboot.rom add -f /path/to/gpxe/src/bin/10ec8167.rom -n pci10ec,8167.rom -t raw<br />
$ ./build/cbfstool build/coreboot.rom print<br />
</source><br />
<br />
As with VGA option ROMs, the gpxe option ROM may be compressed with LZMA. However, compression won't significantly reduce gpxe's size as it implements its own compression.<br />
<br />
In addition to gpxe, other option ROMs can be added in the same manner.<br />
<br />
== Adding payloads ==<br />
<br />
Most [[Payloads|payloads]] can also be launched from SeaBIOS. To add a payload, build the corresponding .elf file and then add it to the '''coreboot.rom''' file in the '''img/''' directory. For example:<br />
<br />
<source lang="bash"><br />
$ ./build/cbfstool build/coreboot.rom add-payload /path/to/payload.elf img/MyPayload l<br />
$ ./build/cbfstool build/coreboot.rom print<br />
</source><br />
<br />
During boot, one can press the '''ESC''' key to get a boot menu. SeaBIOS will show all files in the '''img/''' directory, and one can instruct SeaBIOS to run them.<br />
<br />
SeaBIOS supports both uncompressed and LZMA compressed payloads.<br />
<br />
== Adding a floppy image ==<br />
<br />
It is possible to embed an image of a floppy in flash. SeaBIOS can then boot from and redirect floppy BIOS calls to the flash image. This is mainly useful for legacy software (such as DOS utilities). To use this feature, place a floppy image into the CBFS directory '''floppyimg/'''. For example:<br />
<br />
<source lang="bash"><br />
$ ./build/cbfstool build/coreboot.rom add -f /path/to/myfloppy.img -c lzma -n floppyimg/MyFloppy.lzma -t raw<br />
$ ./build/cbfstool build/coreboot.rom print<br />
</source><br />
<br />
Both uncompressed and LZMA compressed images are supported. Several floppy formats are available: 360K, 1.2MB, 720K, 1.44MB, 2.88MB, 160K, 180K, 320K.<br />
<br />
The floppy image will appear as writable to the system, however all writes are discarded on reboot.<br />
<br />
When using this system, SeaBIOS reserves high-memory to store the floppy. The reserved memory is then no longer available for OS use, so this feature should only be used when needed.<br />
<br />
== Configuring boot order ==<br />
<br />
Place a file in CBFS with the name '''bootorder''' to configure the boot up order. The file should be ASCII text and contain one line per boot method. The description of each boot method follows an [https://secure.wikimedia.org/wikipedia/en/wiki/Open_firmware Open Firmware] device path format. SeaBIOS will attempt to boot from each item in the file &mdash; first line of the file first.<br />
<br />
The easiest way to find the available boot methods is to look for "Searching bootorder for" in the SeaBIOS serial output. For example, one may see lines similar to:<br />
<br />
Searching bootorder for: /pci@i0cf8/*@f/drive@1/disk@0<br />
Searching bootorder for: /pci@i0cf8/*@f,1/drive@2/disk@1<br />
Searching bootorder for: /pci@i0cf8/usb@10,4/*@2<br />
<br />
The above represents the patterns SeaBIOS will search for in the bootorder file. However, it's safe to just copy and paste the pattern into bootorder. For example, the file:<br />
<br />
/pci@i0cf8/usb@10,4/*@2<br />
/pci@i0cf8/*@f/drive@1/disk@0<br />
<br />
will instruct SeaBIOS to attempt to boot from the given USB drive first and then attempt the given ATA harddrive second.<br />
<br />
Once a file has been created, add it to CBFS with the name '''bootorder'''. For example:<br />
<br />
<source lang="bash"><br />
$ ./build/cbfstool build/coreboot.rom add -f mybootlist.txt -n bootorder -t raw<br />
$ ./build/cbfstool build/coreboot.rom print<br />
</source><br />
<br />
== Other Configuration items ==<br />
<br />
Additional configuration options are available in the CBFS '''etc/''' directory. For example, to set the duration of the boot menu to five and a half seconds, one would do the following:<br />
<br />
<source lang="bash"><br />
$ ./build/cbfstool build/coreboot.rom add-int -i 5500 -n etc/boot-menu-wait<br />
$ ./build/cbfstool build/coreboot.rom print<br />
</source><br />
<br />
The cbfstool "add-int" command will create a litte-endian encoded binary integer and place it into the specified CBFS file.<br />
<br />
See the [http://seabios.org/Runtime_config SeaBIOS wiki] for details on available options.<br />
<br />
== File aliases ==<br />
<br />
It is possible to create the equivalent of "symbolic links" in CBFS so that one file's content appears under another name. To do this, create a links file with one line per link and each line having the format of "linkname" and "destname" separated by a space character. For example, the "links" file may look like:<br />
<br />
pci1234,1000.rom somerom.rom<br />
pci1234,1001.rom somerom.rom<br />
pci1234,1002.rom somerom.rom<br />
<br />
Then add the "links" file to CBFS:<br />
<br />
<source lang="bash"><br />
$ ./build/cbfstool build/coreboot.rom add -f links -n links -t raw<br />
$ ./build/cbfstool build/coreboot.rom print<br />
</source><br />
<br />
The above example would cause SeaBIOS to treat "pci1234,1000.rom" or "pci1234,1001.rom" as files with the same content as the file "somerom.rom".<br />
<br />
= Trouble reporting =<br />
<br />
If you are experiencing problems with SeaBIOS, please follow the directions on the [http://seabios.org/Debugging SeaBIOS wiki] to report the issue.</div>Stepanhttps://www.coreboot.org/index.php?title=Download_coreboot&diff=18248Download coreboot2016-04-29T22:54:58Z<p>Stepan: /* Repositories on coreboot.org */</p>
<hr />
<div>__NOTOC__<br />
<br />
= Releases =<br />
<br />
coreboot provides no binaries, but there exist some distributions that do so, see [[#coreboot_distributions|below]].<br />
<br />
There are source code releases on http://coreboot.org/releases/<br />
<br />
= Accessing the source code through git =<br />
<br />
coreboot uses git and gerrit for source code management. Please see the [[Git]] page on how to work with git and gerrit in coreboot.<br />
<br />
Previously the project used the subversion SCM, some links to it may still be referred to, but are definitely outdated.<br />
<br />
== Source code browsing ==<br />
<br />
You can browse the coreboot Git repository online using [https://review.coreboot.org/gitweb/cgit/coreboot.git/ cgit] including its [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree tree view] for accessing the files.<br />
<br />
= coreboot distributions =<br />
<br />
While not officially part of the coreboot project, there exist some projects that distribute pre-built (tested) ROM images along with build scripts and user-focused documentation. These "distros" of coreboot will also typically include copies of the source code (or links where to find it) for the version of coreboot used along with payloads such as SeaBIOS, GRUB and so on.<br />
<br />
'''Libreboot'''<br />
* Deblobbed coreboot, officially supporting a handful of devices.<br />
* [http://libreboot.org/ libreboot.org]<br />
<br />
'''John Lewis'''<br />
* Provides coreboot images for several Chromebooks<br />
* [https://johnlewis.ie/custom-chromebook-firmware/rom-download/ johnlewis.ie]<br />
<br />
= Repositories on coreboot.org =<br />
<br />
Find all of our git repositories in [https://review.coreboot.org/gitweb/cgit/ cgit].<br />
<br />
Here's an obsolete list that will go away soon:<br />
<br />
'''coreboot current Git tree:'''<br />
* <nowiki>http://review.coreboot.org/coreboot.git</nowiki><br />
<br />
'''coreboot v1 (obsolete):'''<br />
* svn://coreboot.org/coreboot/branches/coreboot-v1<br />
* <nowiki>https://svn.coreboot.org/coreboot/branches/coreboot-v1</nowiki><br />
<br />
'''coreboot v3 (obsolete):'''<br />
* svn://coreboot.org/repository/coreboot-v3<br />
* <nowiki>https://svn.coreboot.org/repository/coreboot-v3</nowiki><br />
<br />
'''[[FILO]]:'''<br />
* <nowiki>http://review.coreboot.org/filo.git</nowiki><br />
<br />
'''[[Buildrom]]:'''<br />
* svn://coreboot.org/buildrom/<br />
* <nowiki>https://svn.coreboot.org/buildrom/</nowiki><br />
<br />
'''[[Distributed and Automated Testsystem]]:'''<br />
* svn://coreboot.org/testsystem<br />
* <nowiki>https://svn.coreboot.org/testsystem/</nowiki></div>Stepanhttps://www.coreboot.org/index.php?title=Bios_extract&diff=18247Bios extract2016-04-29T22:51:47Z<p>Stepan: /* Installation */</p>
<hr />
<div>'''bios_extract''' is a GPL tool for extracting individual modules from proprietary BIOS/UEFI images.<br />
<br />
This utility should work on most modern UNIX-like operating systems; it has been tested on at least Linux and FreeBSD.<br />
It is very useful for extracting PCI Expansion ROMs from onboard devices, like IGP graphics, raid controllers, nic boot roms, etc, for inclusion in a coreboot image.<br />
<br />
== Installation ==<br />
<br />
'''Manual installation'''<br />
<br />
$ git clone http://review.coreboot.org/p/bios_extract<br />
$ cd bios_extract<br />
$ make<br />
$ sudo make install<br />
<br />
You can view sources via [https://review.coreboot.org/gitweb/cgit/bios_extract.git/ cgit].<br />
<br />
== Development guidelines ==<br />
<br />
We use the same [[Development Guidelines#Coding_style|coding style as coreboot]] (which is basically the Linux kernel coding style).</div>Stepanhttps://www.coreboot.org/index.php?title=Msrtool&diff=18246Msrtool2016-04-29T22:48:12Z<p>Stepan: /* Installation */ gitweb -> cgit</p>
<hr />
<div>'''msrtool''' is a small utility that dumps chipset-specific MSR registers.<br />
<br />
== Supported OSes and chipsets ==<br />
<br />
'''OSes:'''<br />
<br />
* Linux with /dev/cpu/*/msr<br />
* Darwin / OS X with DirectIO<br />
* FreeBSD with /dev/cpuctl*<br />
<br />
'''Chipsets:'''<br />
<br />
* AMD Geode GX2<br />
* AMD Geode LX<br />
* AMD Geode CS5536<br />
* AMD K8<br />
* Intel Pentium III and later<br />
<br />
== Installation ==<br />
<br />
'''Manual installation'''<br />
<br />
$ '''git clone http://review.coreboot.org/p/coreboot.git'''<br />
$ '''cd coreboot/util/msrtool'''<br />
$ '''./configure'''<br />
$ '''make'''<br />
$ '''sudo make install'''<br />
<br />
You can [https://review.coreboot.org/gitweb/cgit/coreboot.git/tree/util/msrtool browse the msrtool source code] using the gitweb interface.<br />
<br />
== Usage ==<br />
<br />
Show basic information:<br />
<br />
$ '''msrtool'''<br />
<br />
Please see '''msrtool -h''' for information on various other options.<br />
<br />
<br />
{{PD-self}}</div>Stepanhttps://www.coreboot.org/index.php?title=Download_coreboot&diff=18245Download coreboot2016-04-29T22:45:22Z<p>Stepan: /* Source code browsing */ gitweb -> cgit</p>
<hr />
<div>__NOTOC__<br />
<br />
= Releases =<br />
<br />
coreboot provides no binaries, but there exist some distributions that do so, see [[#coreboot_distributions|below]].<br />
<br />
There are source code releases on http://coreboot.org/releases/<br />
<br />
= Accessing the source code through git =<br />
<br />
coreboot uses git and gerrit for source code management. Please see the [[Git]] page on how to work with git and gerrit in coreboot.<br />
<br />
Previously the project used the subversion SCM, some links to it may still be referred to, but are definitely outdated.<br />
<br />
== Source code browsing ==<br />
<br />
You can browse the coreboot Git repository online using [https://review.coreboot.org/gitweb/cgit/coreboot.git/ cgit] including its [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree tree view] for accessing the files.<br />
<br />
= coreboot distributions =<br />
<br />
While not officially part of the coreboot project, there exist some projects that distribute pre-built (tested) ROM images along with build scripts and user-focused documentation. These "distros" of coreboot will also typically include copies of the source code (or links where to find it) for the version of coreboot used along with payloads such as SeaBIOS, GRUB and so on.<br />
<br />
'''Libreboot'''<br />
* Deblobbed coreboot, officially supporting a handful of devices.<br />
* [http://libreboot.org/ libreboot.org]<br />
<br />
'''John Lewis'''<br />
* Provides coreboot images for several Chromebooks<br />
* [https://johnlewis.ie/custom-chromebook-firmware/rom-download/ johnlewis.ie]<br />
<br />
= Repositories on coreboot.org =<br />
<br />
'''coreboot current Git tree:'''<br />
* <nowiki>http://review.coreboot.org/coreboot.git</nowiki><br />
<br />
'''coreboot v1 (obsolete):'''<br />
* svn://coreboot.org/coreboot/branches/coreboot-v1<br />
* <nowiki>https://svn.coreboot.org/coreboot/branches/coreboot-v1</nowiki><br />
<br />
'''coreboot v3 (obsolete):'''<br />
* svn://coreboot.org/repository/coreboot-v3<br />
* <nowiki>https://svn.coreboot.org/repository/coreboot-v3</nowiki><br />
<br />
'''[[FILO]]:'''<br />
* <nowiki>http://review.coreboot.org/filo.git</nowiki><br />
<br />
'''[[Buildrom]]:'''<br />
* svn://coreboot.org/buildrom/<br />
* <nowiki>https://svn.coreboot.org/buildrom/</nowiki><br />
<br />
'''[[Distributed and Automated Testsystem]]:'''<br />
* svn://coreboot.org/testsystem<br />
* <nowiki>https://svn.coreboot.org/testsystem/</nowiki></div>Stepanhttps://www.coreboot.org/index.php?title=Chrome_EC&diff=17970Chrome EC2016-01-30T01:10:22Z<p>Stepan: /* Patches required */</p>
<hr />
<div>= Chrome EC =<br />
<br />
The Chrome EC is used in almost all Chrome OS devices, and an increasing number of accessories, like Google's Type C chargers. It is based on the Chromium EC code base.<br />
<br />
= Building the Chrome EC =<br />
<br />
== Building in the ChromiumOS environment ==<br />
<br />
[http://www.chromium.org/chromium-os/ec-development/getting-started-building-ec-images-quickly Getting started building EC images quickly]<br />
<br />
== Building outside of the ChromiumOS chroot ==<br />
<br />
=== Build requirements ===<br />
<br />
You will need:<br />
* GNU Make 4.1 (older versions are having trouble with the Makefiles)<br />
* an ARM cross compiler (I used coreboot's armv7-a-eabi- toolchain)<br />
<br />
=== Patches required ===<br />
<br />
Patching up the code:<br />
<br />
* https://chromium-review.googlesource.com/#/c/322435/<br />
<br />
=== Build instructions ===<br />
<br />
Let's go:<br />
<br />
$ sudo aptitude install libftdi-dev<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/vboot_reference<br />
$ cd vboot_reference<br />
$ make<br />
[..]<br />
$ cp build/futility/futility ~/bin<br />
$ cd ..<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/ec<br />
[..]<br />
$ cd ec<br />
$ CROSS_COMPILE=armv7-a-eabi- HOST_CROSS_COMPILE= make BOARD=chell<br />
[..]<br />
$<br />
<br />
Build all boards:<br />
<br />
ls -1 board/ | grep -v OWNERS | grep -v host | \<br />
while read n; do<br />
echo "**************** $n"<br />
CROSS_COMPILE=armv7-a-eabi- HOST_CROSS_COMPILE= make BOARD=$n -j<br />
done<br />
<br />
=== Issues ===<br />
<br />
Targets not building<br />
<br />
* cr50 (make issue with -C)<br />
* glados,kunimitsu,wheatley: `memset' referenced in section `.text' of /tmp/cc3Dv6dh.ltrans2.ltrans.o: defined in discarded section `.text' of build/wheatley/RO/common/util.o (symbol from plugin)<br />
* it8380dev: armv7-a-eabi-gcc: error: unrecognized argument in option '-march=v3m'<br />
* Not real targets, but in board/: host, OWNERS</div>Stepanhttps://www.coreboot.org/index.php?title=Development_Guidelines&diff=17851Development Guidelines2016-01-21T22:03:31Z<p>Stepan: /* General Guidelines */</p>
<hr />
<div>= Development Environment =<br />
<br />
== Required Toolchain ==<br />
<br />
The easiest way to get a working toolchain is to run <code>make crossgcc</code> in the toplevel directory of a coreboot checkout. Distributions usually modify their compilers in ways incompatible with coreboot. If in doubt, use our toolchain.<br />
<br />
The toolchain consists of:<br />
* GNU development environment:<br />
** [http://gcc.gnu.org/ GCC with G++]<br />
** [http://www.kernel.org/pub/linux/devel/binutils/ binutils]<br />
* libncurses*-dev<br />
* [http://www.acpica.org/downloads/ IASL], now part of the '''ACPICA''' download (package ''pmtools'' or ''iasl'' in many distributions)<br />
<br />
= Coding Guidelines =<br />
<br />
== General Guidelines ==<br />
<br />
* Encapsulate and isolate assembly language<br />
* Code shall not be "commented out"<br />
* No use of floating-point arithmetics<br />
* No hiding of identifiers defined in outer scopes<br />
* Typedefs are unique (device_t?)<br />
* Functions shall have prototype declarations<br />
* Local functions should be declared static<br />
* No function definitions in header files<br />
* All variables are assigned before use<br />
* All objects should have fully qualified types (''unsigned int'' instead of ''unsigned'')<br />
* Types which indicate signedness and bitness should be used (''uint32_t'' or ''u32'' instead of ''unsigned int'')<br />
* We suggest trying to import more such rules, such as additional ones described in [http://www.misra.org.uk/index.htm MISRA-C 2012] (''Guidelines for the use of C in critical systems'')<br />
<br />
== Variable types ==<br />
<br />
Whenever possible, please use a variable type which is explicit about the size of data it can hold. For example, use '''uint32_t''' or '''u32''' instead of '''unsigned long''' when referencing a 32-bit wide register.<br />
<br />
=== short int names vs stdint names ===<br />
<br />
There is '''currently no hard rule''' on whether one should use short int types ('''u32'''), or stdint types ('''uint32_t'''). Whichever type you elect to use, please use common sense and stay consistent.<br />
<br />
== Assembly Language ==<br />
<br />
To keep the code consistent across the different supported platforms, AT&T syntax is to be used through-out the project. We are working actively on replacing the existing Intel syntax code with AT&T syntax. No new Intel syntax code is allowed into the project.<br />
<br />
It is highly encouraged to not use inline assembly, but instead to encapsulate and isolate the use of assembly language to pure assembly files.<br />
<br />
== Comments ==<br />
<br />
=== References ===<br />
<br />
If you are referencing a data sheet or other documentation in the code, please add the name or document number in addition to the URL. Vendors just ''love'' to rearrange their websites (and some remove documentation on their old products altogether)! If we have the name/number (or even just the filename of the PDF) at least there's a chance to google for it again (either on the vendor's site or on some archive).<br />
<br />
== Coding Style ==<br />
<br />
* We use the coreboot [[Coding Style]] throughout the project.<br />
* You can use the 'indent' tool to fix the coding style like this:<br />
indent -npro -kr -i8 -ts8 -sob -l80 -ss -ncs *.[ch]<br />
:Do not trust 'indent' blindly, though. It sometimes gets things wrong. Manual corrections may be required.<br />
<br />
== The 80 character limit ==<br />
<br />
Lines larger than 80 columns should be broken down into readable pieces. This includes not only source files, but also Makefiles, Kconfig files, and any file meant to be edited by a human. We recommend setting your editor to show the 80th character limit.<br />
This limit is not a relic from long forgotten times, but a very practical and efficient way to organize code and increase productivity. Several files can be edited on the same monitor, without the need to side-scroll. Side-scrolling source files is inefficient, time-consuming, and uncomfortable. On average, 95% of source lines are shorter than 80 characters, so limiting the line length is this manner is not only _not_ an impediment, it also gets you to think on how to best organize the code.<br />
<br />
= Documentation Guidelines =<br />
<br />
== General Guidelines and Tips ==<br />
<br />
* Documentation should be put into the wiki and/or in the code as Doxygen comments<br />
* Avoid using different styles and looks of documentation<br />
* Document ''why'' and ''what'', not ''how'' (No comments like ''/* add one to i */'')<br />
* Document assumptions, stipulations etc...<br />
* Document design and concepts!<br />
* Not lots of documentation but good documentation<br />
* Structured documentation<br />
* Focus: Whom are you addressing in your documentation? Write documentation for users, developers, vendors, ...<br />
<br />
== Automatic documentation ==<br />
<br />
* Doxygen-generated API- and code documentation is available at http://qa.coreboot.org/docs/. This documentation is updated on every 10th checkin.<br />
* To create a Doxygen comment, write<br />
/**<br />
* Sample comment.<br />
*/<br />
:or<br />
/** Sample comment. */<br />
* There are a few commands that describe what kind of comment you are adding:<br />
::@param &mdash; input parameters of a function<br />
::@return &mdash; return value of a function<br />
* A list of all commands is available at http://www.stack.nl/~dimitri/doxygen/commands.html<br />
<br />
Full example:<br />
<br />
/**<br />
* Calculate the length of a string.<br />
*<br />
* @param str The input string.<br />
* @return The length of the string, not including the final NUL character.<br />
*/<br />
static inline size_t strlen(const char *str)<br />
{<br />
/* ... */<br />
}<br />
<br />
= Testing =<br />
<br />
Every commit will be processed by the autobuild and autotest system available at http://qa.coreboot.org/. In addition please run autobuild yourself before submitting patches.<br />
<br />
== autobuild ==<br />
<br />
Autobuild can be found at [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=util/abuild;hb=HEAD coreboot/util/abuild]. <br />
<br />
Please run ''abuild'' '''before''' you commit.<br />
<br />
Autobuild is also running on every check-in to the repository. The results of this build are also available at http://qa.coreboot.org/.<br />
<br />
== autotest ==<br />
<br />
We can also run automatic tests on boards, if we find contributors willing to have a board automatically managed by our QA system. This requires a permanent connection to the net, a host system and some special circuitry. If interested, please contact us using the [[Mailinglist|mailing list]].<br />
<br />
= How to contribute =<br />
<br />
== Creating Patches ==<br />
<br />
* We use gerrit for change management, using the instance on http://review.coreboot.org/<br />
* While not necessary with gerrit, '''make sure that your change is against current master'''. Patches that fail on merge (after some developer looked at it and approved it) might linger around until '''you''' update it.<br />
* Rebase, if necessary, '''then test''' again. You might be the only contributor with that specific mainboard.<br />
* Make sure all new and modified files contain the [[Development Guidelines#Common_License_Header|proper license headers]] (see below).<br />
* Make sure all added files are actually within the commit.<br />
* Make one commit per logical change.<br />
* For more details on using gerrit, see our [[Git]] documentation. Things are somewhat different (eg. it's normal to rebase changes that were already pushed).<br />
* Double-check that your changes are correct, and that the commit only contains what you think it contains.<br />
<br />
== Sign-off Procedure ==<br />
<br />
We employ a similar sign-off procedure for coreboot <br />
[http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html as the Linux kernel developers] do.<br />
Please add a note such as<br />
Signed-off-by: Random J Developer <random@developer.example.org><br />
to your email/patch if you agree with the following Developer's Certificate of Origin 1.1.<br />
<br />
Patches without a Signed-off-by cannot be pushed to gerrit!<br />
<br />
<span style="color:red">You have to use your real name in the Signed-off-by line and in any copyright notices you add.</span> Patches without an associated real name cannot be committed!<br />
<br />
'''Developer's Certificate of Origin 1.1:'''<br />
<br />
By making a contribution to this project, I certify that:<br /><br />
(a) The contribution was created in whole or in part by me and I have<br />
the right to submit it under the open source license indicated in the file; or<br /><br />
(b) The contribution is based upon previous work that, to the best of my<br />
knowledge, is covered under an appropriate open source license and I have the<br />
right under that license to submit that work with modifications, whether created<br />
in whole or in part by me, under the same open source license (unless I am<br />
permitted to submit under a different license), as indicated in the file; or<br /><br />
(c) The contribution was provided directly to me by some other person who<br />
certified (a), (b) or (c) and I have not modified it; and<br /><br />
(d) In the case of each of (a), (b), or (c), I understand and agree that<br />
this project and the contribution are public and that a record of the contribution<br />
(including all personal information I submit with it, including my sign-off) is<br />
maintained indefinitely and may be redistributed consistent with this project or the<br />
open source license indicated in the file.<br />
<br />
<small>Note: The [http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html Developer's Certificate of Origin 1.1] is licensed under the terms of the [http://creativecommons.org/licenses/by-sa/2.5/ Creative Commons Attribution-ShareAlike 2.5 License].</small><br />
<br />
== Reviews ==<br />
<br />
* Send your patch to [[Git|gerrit]] for review.<br />
** Provide useful commit messages. Explain what the change does and why. Our short intro to [[Git|git]] explains the format in more detail.<br />
** Add a single line containing your "[[Development Guidelines#Sign-off_Procedure|sign-off]]" after the description of the patch (<code>git commit -s</code> helps, but make sure you understand and comply with the DCO).<br />
*** Example: ''Signed-off-by: John Doe <john@example.com>''<br />
* The developers will review and/or test your change and send comments or suggestions. Please push updated patches as described in "[[Git#Evolving_patches|evolving patches]]".<br />
* If the change looks ok to one or more developers, they will approve and submit it to the master branch.<br />
<br />
= Bug-Tracker =<br />
<br />
'''note: the bug tracker is dead. more or less.'''<br />
<br />
= License Issues =<br />
<br />
* Contributed code must be GPL'd (preferrably 'GPLv2', but 'GPLv2 or any later version' is fine, too). At the very minimum the code must have a GPLv2-compatible license.<br />
<br />
== Common License Header ==<br />
<br />
Please quote the shortened GPL license header text in every file, as shown below. It should contain:<br />
<br />
* The '''year(s)''' when the code was written or modified and a '''copyright note''' of you (or your company, if you are contributing as part of your employment, and thus the copyright belongs to your company). Also, please provide an '''email address''' if possible so that you can be contacted if questions arise.<br />
** Example:<br />
::''Copyright (C) 2006 John Doe <john@example.com>''<br />
::''Copyright (C) 2004-2006 Company, Inc.''<br />
* The full '''GPL header''' as shown below.<br />
<br />
'''Complete example for *.c and *.h files:'''<br />
<br />
/*<br />
* This file is part of the coreboot project.<br />
*<br />
* Copyright (C) 2003-2005 Jane Doe <jane@example.com><br />
* Copyright (C) 2006 Company, Inc.<br />
*<br />
* This program is free software; you can redistribute it and/or modify<br />
* it under the terms of the GNU General Public License as published by<br />
* the Free Software Foundation; version 2 of the License.<br />
*<br />
* This program is distributed in the hope that it will be useful,<br />
* but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
* GNU General Public License for more details.<br />
*/<br />
<br />
'''Complete example for Makefiles, config files, Python files, shell scripts etc.:'''<br />
<br />
##<br />
## This file is part of the coreboot project.<br />
##<br />
## Copyright (C) 2003-2005 Jane Doe <jane@example.com><br />
## Copyright (C) 2006 Company, Inc.<br />
##<br />
## This program is free software; you can redistribute it and/or modify<br />
## it under the terms of the GNU General Public License as published by<br />
## the Free Software Foundation; version 2 of the License.<br />
##<br />
## This program is distributed in the hope that it will be useful,<br />
## but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
## GNU General Public License for more details.<br />
##</div>Stepanhttps://www.coreboot.org/index.php?title=Development_Guidelines&diff=17850Development Guidelines2016-01-21T22:02:25Z<p>Stepan: /* Variable types */ Due to popular request to bring back sanity</p>
<hr />
<div>= Development Environment =<br />
<br />
== Required Toolchain ==<br />
<br />
The easiest way to get a working toolchain is to run <code>make crossgcc</code> in the toplevel directory of a coreboot checkout. Distributions usually modify their compilers in ways incompatible with coreboot. If in doubt, use our toolchain.<br />
<br />
The toolchain consists of:<br />
* GNU development environment:<br />
** [http://gcc.gnu.org/ GCC with G++]<br />
** [http://www.kernel.org/pub/linux/devel/binutils/ binutils]<br />
* libncurses*-dev<br />
* [http://www.acpica.org/downloads/ IASL], now part of the '''ACPICA''' download (package ''pmtools'' or ''iasl'' in many distributions)<br />
<br />
= Coding Guidelines =<br />
<br />
== General Guidelines ==<br />
<br />
* Encapsulate and isolate assembly language<br />
* Code shall not be "commented out"<br />
* No use of floating-point arithmetics<br />
* No hiding of identifiers defined in outer scopes<br />
* Typedefs are unique (device_t?)<br />
* Functions shall have prototype declarations<br />
* Local functions should be declared static<br />
* No definitions in header files<br />
* All variables are assigned before use<br />
* All objects should have fully qualified types (''unsigned int'' instead of ''unsigned'')<br />
* Types which indicate signedness and bitness should be used (''uint32_t'' or ''u32'' instead of ''unsigned int'')<br />
* We suggest trying to import more such rules, such as additional ones described in [http://www.misra.org.uk/index.htm MISRA-C 2012] (''Guidelines for the use of C in critical systems'')<br />
<br />
== Variable types ==<br />
<br />
Whenever possible, please use a variable type which is explicit about the size of data it can hold. For example, use '''uint32_t''' or '''u32''' instead of '''unsigned long''' when referencing a 32-bit wide register.<br />
<br />
=== short int names vs stdint names ===<br />
<br />
There is '''currently no hard rule''' on whether one should use short int types ('''u32'''), or stdint types ('''uint32_t'''). Whichever type you elect to use, please use common sense and stay consistent.<br />
<br />
== Assembly Language ==<br />
<br />
To keep the code consistent across the different supported platforms, AT&T syntax is to be used through-out the project. We are working actively on replacing the existing Intel syntax code with AT&T syntax. No new Intel syntax code is allowed into the project.<br />
<br />
It is highly encouraged to not use inline assembly, but instead to encapsulate and isolate the use of assembly language to pure assembly files.<br />
<br />
== Comments ==<br />
<br />
=== References ===<br />
<br />
If you are referencing a data sheet or other documentation in the code, please add the name or document number in addition to the URL. Vendors just ''love'' to rearrange their websites (and some remove documentation on their old products altogether)! If we have the name/number (or even just the filename of the PDF) at least there's a chance to google for it again (either on the vendor's site or on some archive).<br />
<br />
== Coding Style ==<br />
<br />
* We use the coreboot [[Coding Style]] throughout the project.<br />
* You can use the 'indent' tool to fix the coding style like this:<br />
indent -npro -kr -i8 -ts8 -sob -l80 -ss -ncs *.[ch]<br />
:Do not trust 'indent' blindly, though. It sometimes gets things wrong. Manual corrections may be required.<br />
<br />
== The 80 character limit ==<br />
<br />
Lines larger than 80 columns should be broken down into readable pieces. This includes not only source files, but also Makefiles, Kconfig files, and any file meant to be edited by a human. We recommend setting your editor to show the 80th character limit.<br />
This limit is not a relic from long forgotten times, but a very practical and efficient way to organize code and increase productivity. Several files can be edited on the same monitor, without the need to side-scroll. Side-scrolling source files is inefficient, time-consuming, and uncomfortable. On average, 95% of source lines are shorter than 80 characters, so limiting the line length is this manner is not only _not_ an impediment, it also gets you to think on how to best organize the code.<br />
<br />
= Documentation Guidelines =<br />
<br />
== General Guidelines and Tips ==<br />
<br />
* Documentation should be put into the wiki and/or in the code as Doxygen comments<br />
* Avoid using different styles and looks of documentation<br />
* Document ''why'' and ''what'', not ''how'' (No comments like ''/* add one to i */'')<br />
* Document assumptions, stipulations etc...<br />
* Document design and concepts!<br />
* Not lots of documentation but good documentation<br />
* Structured documentation<br />
* Focus: Whom are you addressing in your documentation? Write documentation for users, developers, vendors, ...<br />
<br />
== Automatic documentation ==<br />
<br />
* Doxygen-generated API- and code documentation is available at http://qa.coreboot.org/docs/. This documentation is updated on every 10th checkin.<br />
* To create a Doxygen comment, write<br />
/**<br />
* Sample comment.<br />
*/<br />
:or<br />
/** Sample comment. */<br />
* There are a few commands that describe what kind of comment you are adding:<br />
::@param &mdash; input parameters of a function<br />
::@return &mdash; return value of a function<br />
* A list of all commands is available at http://www.stack.nl/~dimitri/doxygen/commands.html<br />
<br />
Full example:<br />
<br />
/**<br />
* Calculate the length of a string.<br />
*<br />
* @param str The input string.<br />
* @return The length of the string, not including the final NUL character.<br />
*/<br />
static inline size_t strlen(const char *str)<br />
{<br />
/* ... */<br />
}<br />
<br />
= Testing =<br />
<br />
Every commit will be processed by the autobuild and autotest system available at http://qa.coreboot.org/. In addition please run autobuild yourself before submitting patches.<br />
<br />
== autobuild ==<br />
<br />
Autobuild can be found at [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=util/abuild;hb=HEAD coreboot/util/abuild]. <br />
<br />
Please run ''abuild'' '''before''' you commit.<br />
<br />
Autobuild is also running on every check-in to the repository. The results of this build are also available at http://qa.coreboot.org/.<br />
<br />
== autotest ==<br />
<br />
We can also run automatic tests on boards, if we find contributors willing to have a board automatically managed by our QA system. This requires a permanent connection to the net, a host system and some special circuitry. If interested, please contact us using the [[Mailinglist|mailing list]].<br />
<br />
= How to contribute =<br />
<br />
== Creating Patches ==<br />
<br />
* We use gerrit for change management, using the instance on http://review.coreboot.org/<br />
* While not necessary with gerrit, '''make sure that your change is against current master'''. Patches that fail on merge (after some developer looked at it and approved it) might linger around until '''you''' update it.<br />
* Rebase, if necessary, '''then test''' again. You might be the only contributor with that specific mainboard.<br />
* Make sure all new and modified files contain the [[Development Guidelines#Common_License_Header|proper license headers]] (see below).<br />
* Make sure all added files are actually within the commit.<br />
* Make one commit per logical change.<br />
* For more details on using gerrit, see our [[Git]] documentation. Things are somewhat different (eg. it's normal to rebase changes that were already pushed).<br />
* Double-check that your changes are correct, and that the commit only contains what you think it contains.<br />
<br />
== Sign-off Procedure ==<br />
<br />
We employ a similar sign-off procedure for coreboot <br />
[http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html as the Linux kernel developers] do.<br />
Please add a note such as<br />
Signed-off-by: Random J Developer <random@developer.example.org><br />
to your email/patch if you agree with the following Developer's Certificate of Origin 1.1.<br />
<br />
Patches without a Signed-off-by cannot be pushed to gerrit!<br />
<br />
<span style="color:red">You have to use your real name in the Signed-off-by line and in any copyright notices you add.</span> Patches without an associated real name cannot be committed!<br />
<br />
'''Developer's Certificate of Origin 1.1:'''<br />
<br />
By making a contribution to this project, I certify that:<br /><br />
(a) The contribution was created in whole or in part by me and I have<br />
the right to submit it under the open source license indicated in the file; or<br /><br />
(b) The contribution is based upon previous work that, to the best of my<br />
knowledge, is covered under an appropriate open source license and I have the<br />
right under that license to submit that work with modifications, whether created<br />
in whole or in part by me, under the same open source license (unless I am<br />
permitted to submit under a different license), as indicated in the file; or<br /><br />
(c) The contribution was provided directly to me by some other person who<br />
certified (a), (b) or (c) and I have not modified it; and<br /><br />
(d) In the case of each of (a), (b), or (c), I understand and agree that<br />
this project and the contribution are public and that a record of the contribution<br />
(including all personal information I submit with it, including my sign-off) is<br />
maintained indefinitely and may be redistributed consistent with this project or the<br />
open source license indicated in the file.<br />
<br />
<small>Note: The [http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html Developer's Certificate of Origin 1.1] is licensed under the terms of the [http://creativecommons.org/licenses/by-sa/2.5/ Creative Commons Attribution-ShareAlike 2.5 License].</small><br />
<br />
== Reviews ==<br />
<br />
* Send your patch to [[Git|gerrit]] for review.<br />
** Provide useful commit messages. Explain what the change does and why. Our short intro to [[Git|git]] explains the format in more detail.<br />
** Add a single line containing your "[[Development Guidelines#Sign-off_Procedure|sign-off]]" after the description of the patch (<code>git commit -s</code> helps, but make sure you understand and comply with the DCO).<br />
*** Example: ''Signed-off-by: John Doe <john@example.com>''<br />
* The developers will review and/or test your change and send comments or suggestions. Please push updated patches as described in "[[Git#Evolving_patches|evolving patches]]".<br />
* If the change looks ok to one or more developers, they will approve and submit it to the master branch.<br />
<br />
= Bug-Tracker =<br />
<br />
'''note: the bug tracker is dead. more or less.'''<br />
<br />
= License Issues =<br />
<br />
* Contributed code must be GPL'd (preferrably 'GPLv2', but 'GPLv2 or any later version' is fine, too). At the very minimum the code must have a GPLv2-compatible license.<br />
<br />
== Common License Header ==<br />
<br />
Please quote the shortened GPL license header text in every file, as shown below. It should contain:<br />
<br />
* The '''year(s)''' when the code was written or modified and a '''copyright note''' of you (or your company, if you are contributing as part of your employment, and thus the copyright belongs to your company). Also, please provide an '''email address''' if possible so that you can be contacted if questions arise.<br />
** Example:<br />
::''Copyright (C) 2006 John Doe <john@example.com>''<br />
::''Copyright (C) 2004-2006 Company, Inc.''<br />
* The full '''GPL header''' as shown below.<br />
<br />
'''Complete example for *.c and *.h files:'''<br />
<br />
/*<br />
* This file is part of the coreboot project.<br />
*<br />
* Copyright (C) 2003-2005 Jane Doe <jane@example.com><br />
* Copyright (C) 2006 Company, Inc.<br />
*<br />
* This program is free software; you can redistribute it and/or modify<br />
* it under the terms of the GNU General Public License as published by<br />
* the Free Software Foundation; version 2 of the License.<br />
*<br />
* This program is distributed in the hope that it will be useful,<br />
* but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
* GNU General Public License for more details.<br />
*/<br />
<br />
'''Complete example for Makefiles, config files, Python files, shell scripts etc.:'''<br />
<br />
##<br />
## This file is part of the coreboot project.<br />
##<br />
## Copyright (C) 2003-2005 Jane Doe <jane@example.com><br />
## Copyright (C) 2006 Company, Inc.<br />
##<br />
## This program is free software; you can redistribute it and/or modify<br />
## it under the terms of the GNU General Public License as published by<br />
## the Free Software Foundation; version 2 of the License.<br />
##<br />
## This program is distributed in the hope that it will be useful,<br />
## but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
## GNU General Public License for more details.<br />
##</div>Stepanhttps://www.coreboot.org/index.php?title=Laptop&diff=17775Laptop2016-01-17T17:39:15Z<p>Stepan: /* Random product links */</p>
<hr />
<div>== Laptops with coreboot Support ==<br />
<br />
See [[Supported_Motherboards#Laptops]]<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 "stock" EC firmware. This may still be a challenge because "we don't know what we don't know". 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 />
See [[Motherboard_Porting_Guide]]<br />
<br />
== Laptop survey ==<br />
<br />
This is not a list of coreboot supported laptops but rather chipsets, Super I/Os, flash chips, and especially [[embedded controller]]s used in a few laptops, just for reference purposes.<br />
<br />
{| border="0" style="font-size: smaller"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Vendor<br />
! align="left" | Model<br />
! align="left" | CPU<br />
! align="left" | Chipset NB<br />
! align="left" | Chipset SB<br />
! align="left" | Super&nbsp;I/O<br />
! align="left" | [[Embedded controller|EC]]<br />
! align="left" | Flash Chip<br />
! align="left" | Flash Size<br />
! align="left" | Flash S.<br />
! align="left" | Flash T.<br />
! align="left" | Owner<br />
<br />
|- bgcolor="#dddddd"<br />
| ASUS || S96F/Z96F || Intel&nbsp;Core&trade;2 Duo T7400 || Intel&nbsp;i945 || Intel ICH7 || ITE IT8510E || in Super I/O || ? || ? || ? || ? || [http://www.flashrom.org/pipermail/flashrom/2010-January/001986.html macavity]<br />
|- bgcolor="#eeeeee"<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="#dddddd"<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="#eeeeee"<br />
| Dell || [[Dell Latitude CPi A366XT|Latitude CPi A366XT]] || PII, 360 MHz || Intel 440BX |||| SMSC&nbsp;FDC37N958FR || in Super I/O || AMD AM29F040B || 512KB || yes || PLCC || [[User:Uwe|UH]]<br />
|- bgcolor="#dddddd"<br />
| Dell || [[Dell Latitude C610|Latitude C610]] || PIII, 1.2 GHz || Intel i830 |||| SMSC&nbsp;LPC47N252 || in Super I/O || SST SST49LF004A || 512KB || no || PLCC || [mailto:coreboot@miradou.com CybFr]<br />
|- bgcolor="#eeeeee"<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="#dddddd"<br />
| Dell || XPS M1530 || Intel&nbsp;Core&trade;2 Duo T7700 || Intel PM965 || Intel ICH8 || none || Winbond WPC8763L || Winbond 25X16VSIG || 16Mb || ?? || SPI || Corey Osgood<br />
|- bgcolor="#eeeeee"<br />
| Fujitsu-S. || Lifebook S-4572 || PIII, 750 MHz || Intel 82440MX |||| SMSC FDC37N769 || ? || Fujitsu&nbsp;MBM29F400T<sup>1</sup> || ? || no || TSOP(?) || [[User:Uwe|UH]]<br />
|- bgcolor="#dddddd"<br />
| Fujitsu-S. || Lifebook S7110 || Intel&nbsp;Core&trade;2 Duo T7200 || Intel&nbsp;i945 || Intel ICH7 || SMSC&nbsp;LPC47N217 || Fujitsu MB90378 || Spansion S25FL008A<sup>2</sup> || 1024 kB || no || SO8 / SPI || twice11<br />
|- bgcolor="#eeeeee"<br />
| Gateway || [[Gateway W730-K8X | W730-K8X]] || Socket 754 |||| ?? || ?? || ?? || SST 39VF040 || ?? || yes || PLCC || [[User:Juri|Juri]]<br />
|- bgcolor="#dddddd"<br />
| Gateway || [[Gateway 6020GZ|6020GZ]] || Celeron M 1.4Ghz || Intel 855GME |||| ?? || ?? || ?? || ?? || no || ?? || [[User:Juri|Juri]]<br />
|- bgcolor="#eeeeee"<br />
| Gericom || Webboy 340S2 || PIII || SiS630 |||| NSC PC87393VJG || NSC PC87570 || Winbond&nbsp;29C020 || 256 kB || yes || PLCC || [http://thread.gmane.org/gmane.linux.bios/13081 NS]<br />
|- bgcolor="#dddddd"<br />
| Getac || P470 || Intel&reg;&nbsp;Core 2 Duo Mobile || Intel 945 || Intel ICH7 || ? || ? || ? || 8Mb || no || SPI / SOIC8 || [[User:Stepan|Stefan Reinauer]]<br />
|- bgcolor="#eeeeee"<br />
| Highscreen || XD 14-C1700 || Intel&nbsp;Celeron&nbsp;1.7&nbsp;GHz || SiS650 |||| NSC&nbsp;PC87391(?) || ? || EON EN29F040(A) || 512 kB || yes || PLCC || [[User:Uwe|UH]]<br />
|- bgcolor="#eeeeee"<br />
| HP/Compaq || nc6320 || T7200 || 945GM || ICH7-M || SMSC LPC47N217 || SMSC KBC1021-MT || M25PE80 || 1024 kB || yes || SOIC-8 || [[User:GNUtoo|GNUtoo]]<br />
|- bgcolor="#dddddd"<br />
| HP || Omnibook XE3(L) || PIII, 750 MHz || Intel&nbsp;82371MB ||Intel PIIX4M || SMSC&nbsp;FDC37N869 || NSC&nbsp;PC87570 || SST 28SF040A || 512 kB || no || PLCC || [[User:Uwe|UH]]<br />
|- bgcolor="#eeeeee"<br />
| IBM || Thinkpad T30 || Intel P4 Mobile, 1.8 GHz || Intel&nbsp;i845 || Intel ICH3-M || NSC&nbsp;PC87392 || Renesas H8S&nbsp;64F3169ATE10 || ST&nbsp;M50FW080N5 || 1024 kB || no || TSOP40 / FWH || edgecase<br />
|- bgcolor="#dddddd"<br />
| IBM || Thinkpad X60s || Intel Core Duo CPU L2300 || Intel&nbsp;i945GM || Intel ICH7-M || NSC&nbsp;PC87392 (in Ultrabase) || Renesas H8S2161B || MX25L1605D || 2048 kB || no || SOIC-8 || [[User:SvenS|Sven Schnelle]]<br />
|- bgcolor="#dddddd"<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="#eeeeee"<br />
| One || [http://www.a110wiki.de A110] || VIA&nbsp;C7-M&nbsp;ULV&nbsp;1.0&nbsp;GHz || VIA VX800 |||| none || ENE KB3310 || ? || ? || no || ? || [[User:Uwe|UH]]<br />
|- bgcolor="#dddddd"<br />
| Panasonic || Toughbook&nbsp;CF-25 || P166MMX || FW82439TX&nbsp;(430TX) || FW82371AB || NSC PC87336VJG || Renesas&nbsp;3886 || SST SST29EE020 || 256 kB || no || ? || [[User:Miernik|Miernik]]<br />
|- bgcolor="#eeeeee"<br />
| Roda || Rocky III+ RK886EX || Intel&reg;&nbsp;Core 2 Duo Mobile T5500 || Intel 945 || Intel ICH7 || SMSC&reg;&nbsp;LPC47N227 || Renesas&nbsp;M38859 || SST SST49LF080 || 8Mb || yes || PLCC || [[User:Stepan|Stefan Reinauer]]<br />
|- bgcolor="#dddddd"<br />
| Roda || Rocky II+ RT686 || Intel&nbsp;Pentium III || Intel 430BX || Intel FW82371EB || SMSC&reg;&nbsp;FDC37N769 || Renesas&nbsp;M38867M8A || SST SST29LE020 || 256KB || yes || PLCC/parallel || [[User:Uwe|UH]]<br />
|- bgcolor="#eeeeee"<br />
| Sony || Vaio&nbsp;Picturebook&nbsp;PCG-C1XD || P2 400 || 443ZX |||| ? || ? || ST M29W004BT || 512 kB || no || || [[User:Miernik|Miernik]]<br />
|- bgcolor="#dddddd"<br />
| Sony || Vaio&nbsp;Picturebook&nbsp;PCG-C1X || P266MMX || 430TX |||| ? || ? || ? || ? || ? || ? || [[User:Miernik|Miernik]]<br />
|- bgcolor="#eeeeee"<br />
| Toshiba || Libretto&nbsp;50M PA1243CM || P133 || custom FPGA |||| ? || ? || ? || ? || ? || ? || [[User:Miernik|Miernik]]<br />
|- bgcolor="#dddddd"<br />
| Toshiba || Satellite&nbsp;A80-117 || Intel&nbsp;Celeron || Intel&nbsp;915GM || Intel ICH6 || SMSC&nbsp;LPC47N217 || ENE KB910 || ? || 1024 kB || no || TSOP (?) || [[User:Uwe|UH]]<br />
<br />
|}<br />
<br />
<small><br />
<sup>1</sup> According to the vendor BIOS update tool.<br /><br />
<sup>2</sup> Nice thing: EC/Flash is not shared, so you can erase the whole flash during system operation (this was tested).<br /><br />
</small><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]</div>Stepanhttps://www.coreboot.org/index.php?title=Chrome_EC&diff=17751Chrome EC2016-01-16T01:06:00Z<p>Stepan: /* Build instructions */</p>
<hr />
<div>= Chrome EC =<br />
<br />
The Chrome EC is used in almost all Chrome OS devices, and an increasing number of accessories, like Google's Type C chargers. It is based on the Chromium EC code base.<br />
<br />
= Building the Chrome EC =<br />
<br />
== Building in the ChromiumOS environment ==<br />
<br />
[http://www.chromium.org/chromium-os/ec-development/getting-started-building-ec-images-quickly Getting started building EC images quickly]<br />
<br />
== Building outside of the ChromiumOS chroot ==<br />
<br />
=== Build requirements ===<br />
<br />
You will need:<br />
* GNU Make 4.1 (older versions are having trouble with the Makefiles)<br />
* an ARM cross compiler (I used coreboot's armv7-a-eabi- toolchain)<br />
<br />
=== Patches required ===<br />
<br />
Patching up the code:<br />
<br />
diff --git a/Makefile.toolchain b/Makefile.toolchain<br />
index f015726..759dfb0 100644<br />
--- a/Makefile.toolchain<br />
+++ b/Makefile.toolchain<br />
@@ -48,6 +48,9 @@ CFLAGS=$(CPPFLAGS) $(CFLAGS_CPU) $(CFLAGS_DEBUG) $(CFLAGS_WARN) $(CFLAGS_y)<br />
CFLAGS+= -ffunction-sections -fshort-wchar<br />
CFLAGS+= -fno-delete-null-pointer-checks -fconserve-stack<br />
<br />
+CFLAGS+= -ffreestanding<br />
+CPPFLAGS+= -ffreestanding<br />
+<br />
FTDIVERSION=$(shell $(PKG_CONFIG) --modversion libftdi1 2>/dev/null)<br />
ifneq ($(FTDIVERSION),)<br />
LIBFTDI_NAME=ftdi1<br />
<br />
and<br />
<br />
diff --git a/include/timer.h b/include/timer.h<br />
index 5f92207..1a43604 100644<br />
--- a/include/timer.h<br />
+++ b/include/timer.h<br />
@@ -8,7 +8,7 @@<br />
#ifndef __CROS_EC_TIMER_H<br />
#define __CROS_EC_TIMER_H<br />
<br />
-#include <sys/types.h><br />
+typedef long clock_t;<br />
<br />
#include "common.h"<br />
#include "task_id.h"<br />
<br />
and<br />
<br />
diff --git a/driver/pi3usb30532.h b/driver/pi3usb30532.h<br />
index 96c9632..15a9241 100644<br />
--- a/driver/pi3usb30532.h<br />
+++ b/driver/pi3usb30532.h<br />
@@ -8,8 +8,6 @@<br />
#ifndef __CROS_EC_PI3USB30532_H<br />
#define __CROS_EC_PI3USB30532_H<br />
<br />
-#include <inttypes.h><br />
-<br />
#include "usb_pd.h"<br />
<br />
/* USB switch registers */<br />
<br />
and<br />
<br />
diff --git a/driver/als_si114x.c b/driver/als_si114x.c<br />
index bdd39fa..5a64be9 100644<br />
--- a/driver/als_si114x.c<br />
+++ b/driver/als_si114x.c<br />
@@ -219,7 +219,7 @@ static int irq_handler(struct motion_sensor_t *s, uint32_t *event)<br />
/* Just trigger a measurement */<br />
static int read(const struct motion_sensor_t *s, vector_3_t v)<br />
{<br />
- int ret;<br />
+ int ret = 0;<br />
uint8_t cmd;<br />
struct si114x_drv_data_t *data = SI114X_GET_DATA(s);<br />
<br />
=== Build instructions ===<br />
<br />
Let's go:<br />
<br />
$ sudo aptitude install libftdi-dev<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/vboot_reference<br />
$ cd vboot_reference<br />
$ make<br />
[..]<br />
$ cp build/futility/futility ~/bin<br />
$ cd ..<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/ec<br />
[..]<br />
$ cd ec<br />
$ CROSS_COMPILE=armv7-a-eabi- HOST_CROSS_COMPILE= make BOARD=chell<br />
[..]<br />
$<br />
<br />
Build all boards:<br />
<br />
ls -1 board/ | grep -v OWNERS | grep -v host | \<br />
while read n; do<br />
echo "**************** $n"<br />
CROSS_COMPILE=armv7-a-eabi- HOST_CROSS_COMPILE= make BOARD=$n -j<br />
done<br />
<br />
=== Issues ===<br />
<br />
Targets not building<br />
<br />
* cr50 (make issue with -C)<br />
* glados,kunimitsu,wheatley: `memset' referenced in section `.text' of /tmp/cc3Dv6dh.ltrans2.ltrans.o: defined in discarded section `.text' of build/wheatley/RO/common/util.o (symbol from plugin)<br />
* it8380dev: armv7-a-eabi-gcc: error: unrecognized argument in option '-march=v3m'<br />
* Not real targets, but in board/: host, OWNERS</div>Stepanhttps://www.coreboot.org/index.php?title=Chrome_EC&diff=17750Chrome EC2016-01-16T01:04:34Z<p>Stepan: /* Issues */</p>
<hr />
<div>= Chrome EC =<br />
<br />
The Chrome EC is used in almost all Chrome OS devices, and an increasing number of accessories, like Google's Type C chargers. It is based on the Chromium EC code base.<br />
<br />
= Building the Chrome EC =<br />
<br />
== Building in the ChromiumOS environment ==<br />
<br />
[http://www.chromium.org/chromium-os/ec-development/getting-started-building-ec-images-quickly Getting started building EC images quickly]<br />
<br />
== Building outside of the ChromiumOS chroot ==<br />
<br />
=== Build requirements ===<br />
<br />
You will need:<br />
* GNU Make 4.1 (older versions are having trouble with the Makefiles)<br />
* an ARM cross compiler (I used coreboot's armv7-a-eabi- toolchain)<br />
<br />
=== Patches required ===<br />
<br />
Patching up the code:<br />
<br />
diff --git a/Makefile.toolchain b/Makefile.toolchain<br />
index f015726..759dfb0 100644<br />
--- a/Makefile.toolchain<br />
+++ b/Makefile.toolchain<br />
@@ -48,6 +48,9 @@ CFLAGS=$(CPPFLAGS) $(CFLAGS_CPU) $(CFLAGS_DEBUG) $(CFLAGS_WARN) $(CFLAGS_y)<br />
CFLAGS+= -ffunction-sections -fshort-wchar<br />
CFLAGS+= -fno-delete-null-pointer-checks -fconserve-stack<br />
<br />
+CFLAGS+= -ffreestanding<br />
+CPPFLAGS+= -ffreestanding<br />
+<br />
FTDIVERSION=$(shell $(PKG_CONFIG) --modversion libftdi1 2>/dev/null)<br />
ifneq ($(FTDIVERSION),)<br />
LIBFTDI_NAME=ftdi1<br />
<br />
and<br />
<br />
diff --git a/include/timer.h b/include/timer.h<br />
index 5f92207..1a43604 100644<br />
--- a/include/timer.h<br />
+++ b/include/timer.h<br />
@@ -8,7 +8,7 @@<br />
#ifndef __CROS_EC_TIMER_H<br />
#define __CROS_EC_TIMER_H<br />
<br />
-#include <sys/types.h><br />
+typedef long clock_t;<br />
<br />
#include "common.h"<br />
#include "task_id.h"<br />
<br />
and<br />
<br />
diff --git a/driver/pi3usb30532.h b/driver/pi3usb30532.h<br />
index 96c9632..15a9241 100644<br />
--- a/driver/pi3usb30532.h<br />
+++ b/driver/pi3usb30532.h<br />
@@ -8,8 +8,6 @@<br />
#ifndef __CROS_EC_PI3USB30532_H<br />
#define __CROS_EC_PI3USB30532_H<br />
<br />
-#include <inttypes.h><br />
-<br />
#include "usb_pd.h"<br />
<br />
/* USB switch registers */<br />
<br />
and<br />
<br />
diff --git a/driver/als_si114x.c b/driver/als_si114x.c<br />
index bdd39fa..5a64be9 100644<br />
--- a/driver/als_si114x.c<br />
+++ b/driver/als_si114x.c<br />
@@ -219,7 +219,7 @@ static int irq_handler(struct motion_sensor_t *s, uint32_t *event)<br />
/* Just trigger a measurement */<br />
static int read(const struct motion_sensor_t *s, vector_3_t v)<br />
{<br />
- int ret;<br />
+ int ret = 0;<br />
uint8_t cmd;<br />
struct si114x_drv_data_t *data = SI114X_GET_DATA(s);<br />
<br />
=== Build instructions ===<br />
<br />
Let's go:<br />
<br />
$ sudo aptitude install libftdi-dev<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/vboot_reference<br />
$ cd vboot_reference<br />
$ make<br />
[..]<br />
$ cp build/futility/futility ~/bin<br />
$ cd ..<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/ec<br />
[..]<br />
$ cd ec<br />
$ CROSS_COMPILE=armv7-a-eabi- HOST_CROSS_COMPILE= make BOARD=chell<br />
[..]<br />
$<br />
<br />
=== Issues ===<br />
<br />
Targets not building<br />
<br />
* cr50 (make issue with -C)<br />
* glados,kunimitsu,wheatley: `memset' referenced in section `.text' of /tmp/cc3Dv6dh.ltrans2.ltrans.o: defined in discarded section `.text' of build/wheatley/RO/common/util.o (symbol from plugin)<br />
* it8380dev: armv7-a-eabi-gcc: error: unrecognized argument in option '-march=v3m'<br />
* Not real targets, but in board/: host, OWNERS</div>Stepanhttps://www.coreboot.org/index.php?title=Chrome_EC&diff=17749Chrome EC2016-01-16T00:57:37Z<p>Stepan: /* Patches required */</p>
<hr />
<div>= Chrome EC =<br />
<br />
The Chrome EC is used in almost all Chrome OS devices, and an increasing number of accessories, like Google's Type C chargers. It is based on the Chromium EC code base.<br />
<br />
= Building the Chrome EC =<br />
<br />
== Building in the ChromiumOS environment ==<br />
<br />
[http://www.chromium.org/chromium-os/ec-development/getting-started-building-ec-images-quickly Getting started building EC images quickly]<br />
<br />
== Building outside of the ChromiumOS chroot ==<br />
<br />
=== Build requirements ===<br />
<br />
You will need:<br />
* GNU Make 4.1 (older versions are having trouble with the Makefiles)<br />
* an ARM cross compiler (I used coreboot's armv7-a-eabi- toolchain)<br />
<br />
=== Patches required ===<br />
<br />
Patching up the code:<br />
<br />
diff --git a/Makefile.toolchain b/Makefile.toolchain<br />
index f015726..759dfb0 100644<br />
--- a/Makefile.toolchain<br />
+++ b/Makefile.toolchain<br />
@@ -48,6 +48,9 @@ CFLAGS=$(CPPFLAGS) $(CFLAGS_CPU) $(CFLAGS_DEBUG) $(CFLAGS_WARN) $(CFLAGS_y)<br />
CFLAGS+= -ffunction-sections -fshort-wchar<br />
CFLAGS+= -fno-delete-null-pointer-checks -fconserve-stack<br />
<br />
+CFLAGS+= -ffreestanding<br />
+CPPFLAGS+= -ffreestanding<br />
+<br />
FTDIVERSION=$(shell $(PKG_CONFIG) --modversion libftdi1 2>/dev/null)<br />
ifneq ($(FTDIVERSION),)<br />
LIBFTDI_NAME=ftdi1<br />
<br />
and<br />
<br />
diff --git a/include/timer.h b/include/timer.h<br />
index 5f92207..1a43604 100644<br />
--- a/include/timer.h<br />
+++ b/include/timer.h<br />
@@ -8,7 +8,7 @@<br />
#ifndef __CROS_EC_TIMER_H<br />
#define __CROS_EC_TIMER_H<br />
<br />
-#include <sys/types.h><br />
+typedef long clock_t;<br />
<br />
#include "common.h"<br />
#include "task_id.h"<br />
<br />
and<br />
<br />
diff --git a/driver/pi3usb30532.h b/driver/pi3usb30532.h<br />
index 96c9632..15a9241 100644<br />
--- a/driver/pi3usb30532.h<br />
+++ b/driver/pi3usb30532.h<br />
@@ -8,8 +8,6 @@<br />
#ifndef __CROS_EC_PI3USB30532_H<br />
#define __CROS_EC_PI3USB30532_H<br />
<br />
-#include <inttypes.h><br />
-<br />
#include "usb_pd.h"<br />
<br />
/* USB switch registers */<br />
<br />
and<br />
<br />
diff --git a/driver/als_si114x.c b/driver/als_si114x.c<br />
index bdd39fa..5a64be9 100644<br />
--- a/driver/als_si114x.c<br />
+++ b/driver/als_si114x.c<br />
@@ -219,7 +219,7 @@ static int irq_handler(struct motion_sensor_t *s, uint32_t *event)<br />
/* Just trigger a measurement */<br />
static int read(const struct motion_sensor_t *s, vector_3_t v)<br />
{<br />
- int ret;<br />
+ int ret = 0;<br />
uint8_t cmd;<br />
struct si114x_drv_data_t *data = SI114X_GET_DATA(s);<br />
<br />
=== Build instructions ===<br />
<br />
Let's go:<br />
<br />
$ sudo aptitude install libftdi-dev<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/vboot_reference<br />
$ cd vboot_reference<br />
$ make<br />
[..]<br />
$ cp build/futility/futility ~/bin<br />
$ cd ..<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/ec<br />
[..]<br />
$ cd ec<br />
$ CROSS_COMPILE=armv7-a-eabi- HOST_CROSS_COMPILE= make BOARD=chell<br />
[..]<br />
$<br />
<br />
=== Issues ===<br />
<br />
Targets not building<br />
<br />
* cr50 (make issue)<br />
* glados,kunimitsu,lars,oak: driver/pi3usb30532.h:11:22: fatal error: inttypes.h: No such file or directory<br />
* it8380dev: armv7-a-eabi-gcc: error: unrecognized argument in option '-march=v3m'<br />
* ryu: driver/als_si114x.c:269:5: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]<br />
* Not real targets, but in board/: host, OWNERS</div>Stepanhttps://www.coreboot.org/index.php?title=Chrome_EC&diff=17748Chrome EC2016-01-16T00:55:41Z<p>Stepan: /* Patches required */</p>
<hr />
<div>= Chrome EC =<br />
<br />
The Chrome EC is used in almost all Chrome OS devices, and an increasing number of accessories, like Google's Type C chargers. It is based on the Chromium EC code base.<br />
<br />
= Building the Chrome EC =<br />
<br />
== Building in the ChromiumOS environment ==<br />
<br />
[http://www.chromium.org/chromium-os/ec-development/getting-started-building-ec-images-quickly Getting started building EC images quickly]<br />
<br />
== Building outside of the ChromiumOS chroot ==<br />
<br />
=== Build requirements ===<br />
<br />
You will need:<br />
* GNU Make 4.1 (older versions are having trouble with the Makefiles)<br />
* an ARM cross compiler (I used coreboot's armv7-a-eabi- toolchain)<br />
<br />
=== Patches required ===<br />
<br />
Patching up the code:<br />
<br />
diff --git a/Makefile.toolchain b/Makefile.toolchain<br />
index f015726..759dfb0 100644<br />
--- a/Makefile.toolchain<br />
+++ b/Makefile.toolchain<br />
@@ -48,6 +48,9 @@ CFLAGS=$(CPPFLAGS) $(CFLAGS_CPU) $(CFLAGS_DEBUG) $(CFLAGS_WARN) $(CFLAGS_y)<br />
CFLAGS+= -ffunction-sections -fshort-wchar<br />
CFLAGS+= -fno-delete-null-pointer-checks -fconserve-stack<br />
<br />
+CFLAGS+= -ffreestanding<br />
+CPPFLAGS+= -ffreestanding<br />
+<br />
FTDIVERSION=$(shell $(PKG_CONFIG) --modversion libftdi1 2>/dev/null)<br />
ifneq ($(FTDIVERSION),)<br />
LIBFTDI_NAME=ftdi1<br />
<br />
and<br />
<br />
diff --git a/include/timer.h b/include/timer.h<br />
index 5f92207..1a43604 100644<br />
--- a/include/timer.h<br />
+++ b/include/timer.h<br />
@@ -8,7 +8,7 @@<br />
#ifndef __CROS_EC_TIMER_H<br />
#define __CROS_EC_TIMER_H<br />
<br />
-#include <sys/types.h><br />
+typedef long clock_t;<br />
<br />
#include "common.h"<br />
#include "task_id.h"<br />
<br />
and<br />
<br />
diff --git a/driver/pi3usb30532.h b/driver/pi3usb30532.h<br />
index 96c9632..15a9241 100644<br />
--- a/driver/pi3usb30532.h<br />
+++ b/driver/pi3usb30532.h<br />
@@ -8,8 +8,6 @@<br />
#ifndef __CROS_EC_PI3USB30532_H<br />
#define __CROS_EC_PI3USB30532_H<br />
<br />
-#include <inttypes.h><br />
-<br />
#include "usb_pd.h"<br />
<br />
/* USB switch registers */<br />
<br />
=== Build instructions ===<br />
<br />
Let's go:<br />
<br />
$ sudo aptitude install libftdi-dev<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/vboot_reference<br />
$ cd vboot_reference<br />
$ make<br />
[..]<br />
$ cp build/futility/futility ~/bin<br />
$ cd ..<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/ec<br />
[..]<br />
$ cd ec<br />
$ CROSS_COMPILE=armv7-a-eabi- HOST_CROSS_COMPILE= make BOARD=chell<br />
[..]<br />
$<br />
<br />
=== Issues ===<br />
<br />
Targets not building<br />
<br />
* cr50 (make issue)<br />
* glados,kunimitsu,lars,oak: driver/pi3usb30532.h:11:22: fatal error: inttypes.h: No such file or directory<br />
* it8380dev: armv7-a-eabi-gcc: error: unrecognized argument in option '-march=v3m'<br />
* ryu: driver/als_si114x.c:269:5: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]<br />
* Not real targets, but in board/: host, OWNERS</div>Stepanhttps://www.coreboot.org/index.php?title=Chrome_EC&diff=17747Chrome EC2016-01-16T00:54:35Z<p>Stepan: /* Building outside of the ChromiumOS chroot */</p>
<hr />
<div>= Chrome EC =<br />
<br />
The Chrome EC is used in almost all Chrome OS devices, and an increasing number of accessories, like Google's Type C chargers. It is based on the Chromium EC code base.<br />
<br />
= Building the Chrome EC =<br />
<br />
== Building in the ChromiumOS environment ==<br />
<br />
[http://www.chromium.org/chromium-os/ec-development/getting-started-building-ec-images-quickly Getting started building EC images quickly]<br />
<br />
== Building outside of the ChromiumOS chroot ==<br />
<br />
=== Build requirements ===<br />
<br />
You will need:<br />
* GNU Make 4.1 (older versions are having trouble with the Makefiles)<br />
* an ARM cross compiler (I used coreboot's armv7-a-eabi- toolchain)<br />
<br />
=== Patches required ===<br />
<br />
Patching up the code:<br />
<br />
diff --git a/Makefile.toolchain b/Makefile.toolchain<br />
index f015726..759dfb0 100644<br />
--- a/Makefile.toolchain<br />
+++ b/Makefile.toolchain<br />
@@ -48,6 +48,9 @@ CFLAGS=$(CPPFLAGS) $(CFLAGS_CPU) $(CFLAGS_DEBUG) $(CFLAGS_WARN) $(CFLAGS_y)<br />
CFLAGS+= -ffunction-sections -fshort-wchar<br />
CFLAGS+= -fno-delete-null-pointer-checks -fconserve-stack<br />
<br />
+CFLAGS+= -ffreestanding<br />
+CPPFLAGS+= -ffreestanding<br />
+<br />
FTDIVERSION=$(shell $(PKG_CONFIG) --modversion libftdi1 2>/dev/null)<br />
ifneq ($(FTDIVERSION),)<br />
LIBFTDI_NAME=ftdi1<br />
<br />
and<br />
<br />
diff --git a/include/timer.h b/include/timer.h<br />
index 5f92207..1a43604 100644<br />
--- a/include/timer.h<br />
+++ b/include/timer.h<br />
@@ -8,7 +8,7 @@<br />
#ifndef __CROS_EC_TIMER_H<br />
#define __CROS_EC_TIMER_H<br />
<br />
-#include <sys/types.h><br />
+typedef long clock_t;<br />
<br />
#include "common.h"<br />
#include "task_id.h"<br />
<br />
=== Build instructions ===<br />
<br />
Let's go:<br />
<br />
$ sudo aptitude install libftdi-dev<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/vboot_reference<br />
$ cd vboot_reference<br />
$ make<br />
[..]<br />
$ cp build/futility/futility ~/bin<br />
$ cd ..<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/ec<br />
[..]<br />
$ cd ec<br />
$ CROSS_COMPILE=armv7-a-eabi- HOST_CROSS_COMPILE= make BOARD=chell<br />
[..]<br />
$<br />
<br />
=== Issues ===<br />
<br />
Targets not building<br />
<br />
* cr50 (make issue)<br />
* glados,kunimitsu,lars,oak: driver/pi3usb30532.h:11:22: fatal error: inttypes.h: No such file or directory<br />
* it8380dev: armv7-a-eabi-gcc: error: unrecognized argument in option '-march=v3m'<br />
* ryu: driver/als_si114x.c:269:5: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]<br />
* Not real targets, but in board/: host, OWNERS</div>Stepanhttps://www.coreboot.org/index.php?title=Chrome_EC&diff=17746Chrome EC2016-01-16T00:51:09Z<p>Stepan: /* Building outside of the ChromiumOS chroot */</p>
<hr />
<div>= Chrome EC =<br />
<br />
The Chrome EC is used in almost all Chrome OS devices, and an increasing number of accessories, like Google's Type C chargers. It is based on the Chromium EC code base.<br />
<br />
= Building the Chrome EC =<br />
<br />
== Building in the ChromiumOS environment ==<br />
<br />
[http://www.chromium.org/chromium-os/ec-development/getting-started-building-ec-images-quickly Getting started building EC images quickly]<br />
<br />
== Building outside of the ChromiumOS chroot ==<br />
<br />
You will need:<br />
* GNU Make 4.1 (older versions are having trouble with the Makefiles)<br />
* an ARM cross compiler (I used coreboot's armv7-a-eabi- toolchain)<br />
<br />
Patching up the code:<br />
<br />
diff --git a/Makefile.toolchain b/Makefile.toolchain<br />
index f015726..759dfb0 100644<br />
--- a/Makefile.toolchain<br />
+++ b/Makefile.toolchain<br />
@@ -48,6 +48,9 @@ CFLAGS=$(CPPFLAGS) $(CFLAGS_CPU) $(CFLAGS_DEBUG) $(CFLAGS_WARN) $(CFLAGS_y)<br />
CFLAGS+= -ffunction-sections -fshort-wchar<br />
CFLAGS+= -fno-delete-null-pointer-checks -fconserve-stack<br />
<br />
+CFLAGS+= -ffreestanding<br />
+CPPFLAGS+= -ffreestanding<br />
+<br />
FTDIVERSION=$(shell $(PKG_CONFIG) --modversion libftdi1 2>/dev/null)<br />
ifneq ($(FTDIVERSION),)<br />
LIBFTDI_NAME=ftdi1<br />
<br />
and<br />
<br />
diff --git a/include/timer.h b/include/timer.h<br />
index 5f92207..1a43604 100644<br />
--- a/include/timer.h<br />
+++ b/include/timer.h<br />
@@ -8,7 +8,7 @@<br />
#ifndef __CROS_EC_TIMER_H<br />
#define __CROS_EC_TIMER_H<br />
<br />
-#include <sys/types.h><br />
+typedef long clock_t;<br />
<br />
#include "common.h"<br />
#include "task_id.h"<br />
<br />
Let's go:<br />
<br />
$ sudo aptitude install libftdi-dev<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/vboot_reference<br />
$ cd vboot_reference<br />
$ make<br />
[..]<br />
$ cp build/futility/futility ~/bin<br />
$ cd ..<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/ec<br />
[..]<br />
$ cd ec<br />
$ CROSS_COMPILE=armv7-a-eabi- HOST_CROSS_COMPILE= make BOARD=chell<br />
[..]<br />
$<br />
<br />
<br />
Targets not building<br />
<br />
* cr50 (make issue)<br />
* glados,kunimitsu,lars,oak: driver/pi3usb30532.h:11:22: fatal error: inttypes.h: No such file or directory<br />
* it8380dev: armv7-a-eabi-gcc: error: unrecognized argument in option '-march=v3m'<br />
* ryu: driver/als_si114x.c:269:5: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]<br />
* Not real targets, but in board/: host, OWNERS</div>Stepanhttps://www.coreboot.org/index.php?title=Chrome_EC&diff=17745Chrome EC2016-01-16T00:44:15Z<p>Stepan: /* Building outside of the ChromiumOS chroot */</p>
<hr />
<div>= Chrome EC =<br />
<br />
The Chrome EC is used in almost all Chrome OS devices, and an increasing number of accessories, like Google's Type C chargers. It is based on the Chromium EC code base.<br />
<br />
= Building the Chrome EC =<br />
<br />
== Building in the ChromiumOS environment ==<br />
<br />
[http://www.chromium.org/chromium-os/ec-development/getting-started-building-ec-images-quickly Getting started building EC images quickly]<br />
<br />
== Building outside of the ChromiumOS chroot ==<br />
<br />
You will need:<br />
* GNU Make 4.1 (older versions are having trouble with the Makefiles)<br />
* an ARM cross compiler (I used coreboot's armv7-a-eabi- toolchain)<br />
<br />
Patching up the code:<br />
<br />
diff --git a/Makefile.toolchain b/Makefile.toolchain<br />
index f015726..759dfb0 100644<br />
--- a/Makefile.toolchain<br />
+++ b/Makefile.toolchain<br />
@@ -48,6 +48,9 @@ CFLAGS=$(CPPFLAGS) $(CFLAGS_CPU) $(CFLAGS_DEBUG) $(CFLAGS_WARN) $(CFLAGS_y)<br />
CFLAGS+= -ffunction-sections -fshort-wchar<br />
CFLAGS+= -fno-delete-null-pointer-checks -fconserve-stack<br />
<br />
+CFLAGS+= -ffreestanding<br />
+CPPFLAGS+= -ffreestanding<br />
+<br />
FTDIVERSION=$(shell $(PKG_CONFIG) --modversion libftdi1 2>/dev/null)<br />
ifneq ($(FTDIVERSION),)<br />
LIBFTDI_NAME=ftdi1<br />
<br />
and<br />
<br />
diff --git a/include/timer.h b/include/timer.h<br />
index 5f92207..1a43604 100644<br />
--- a/include/timer.h<br />
+++ b/include/timer.h<br />
@@ -8,7 +8,7 @@<br />
#ifndef __CROS_EC_TIMER_H<br />
#define __CROS_EC_TIMER_H<br />
<br />
-#include <sys/types.h><br />
+typedef long clock_t;<br />
<br />
#include "common.h"<br />
#include "task_id.h"<br />
<br />
Let's go:<br />
<br />
$ sudo aptitude install libftdi-dev<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/vboot_reference<br />
$ cd vboot_reference<br />
$ make<br />
[..]<br />
$ cp build/futility/futility ~/bin<br />
$ cd ..<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/ec<br />
[..]<br />
$ cd ec<br />
$ CROSS_COMPILE=armv7-a-eabi- HOST_CROSS_COMPILE= make BOARD=chell<br />
[..]<br />
$</div>Stepanhttps://www.coreboot.org/index.php?title=Chrome_EC&diff=17744Chrome EC2016-01-16T00:28:39Z<p>Stepan: /* Building outside of the ChromiumOS chroot */</p>
<hr />
<div>= Chrome EC =<br />
<br />
The Chrome EC is used in almost all Chrome OS devices, and an increasing number of accessories, like Google's Type C chargers. It is based on the Chromium EC code base.<br />
<br />
= Building the Chrome EC =<br />
<br />
== Building in the ChromiumOS environment ==<br />
<br />
[http://www.chromium.org/chromium-os/ec-development/getting-started-building-ec-images-quickly Getting started building EC images quickly]<br />
<br />
== Building outside of the ChromiumOS chroot ==<br />
<br />
You will need:<br />
* GNU Make 4.1 (older versions are having trouble with the Makefiles)<br />
* an ARM cross compiler (I used coreboot's armv7-a-eabi- toolchain)<br />
<br />
Patching up the code:<br />
<br />
diff --git a/Makefile.toolchain b/Makefile.toolchain<br />
index f015726..759dfb0 100644<br />
--- a/Makefile.toolchain<br />
+++ b/Makefile.toolchain<br />
@@ -48,6 +48,9 @@ CFLAGS=$(CPPFLAGS) $(CFLAGS_CPU) $(CFLAGS_DEBUG) $(CFLAGS_WARN) $(CFLAGS_y)<br />
CFLAGS+= -ffunction-sections -fshort-wchar<br />
CFLAGS+= -fno-delete-null-pointer-checks -fconserve-stack<br />
<br />
+CFLAGS+= -ffreestanding<br />
+CPPFLAGS+= -ffreestanding<br />
+<br />
FTDIVERSION=$(shell $(PKG_CONFIG) --modversion libftdi1 2>/dev/null)<br />
ifneq ($(FTDIVERSION),)<br />
LIBFTDI_NAME=ftdi1<br />
<br />
and<br />
<br />
diff --git a/include/timer.h b/include/timer.h<br />
index 5f92207..1a43604 100644<br />
--- a/include/timer.h<br />
+++ b/include/timer.h<br />
@@ -8,7 +8,7 @@<br />
#ifndef __CROS_EC_TIMER_H<br />
#define __CROS_EC_TIMER_H<br />
<br />
-#include <sys/types.h><br />
+typedef long clock_t;<br />
<br />
#include "common.h"<br />
#include "task_id.h"<br />
<br />
Let's go:<br />
<br />
$ sudo aptitude install libftdi-dev<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/ec<br />
[..]<br />
$ cd ec<br />
$ CROSS_COMPILE=armv7-a-eabi- HOST_CROSS_COMPILE= make BOARD=chell<br />
[..]<br />
$</div>Stepanhttps://www.coreboot.org/index.php?title=Chrome_EC&diff=17743Chrome EC2016-01-16T00:04:54Z<p>Stepan: /* Building the Chrome EC */</p>
<hr />
<div>= Chrome EC =<br />
<br />
The Chrome EC is used in almost all Chrome OS devices, and an increasing number of accessories, like Google's Type C chargers. It is based on the Chromium EC code base.<br />
<br />
= Building the Chrome EC =<br />
<br />
== Building in the ChromiumOS environment ==<br />
<br />
[http://www.chromium.org/chromium-os/ec-development/getting-started-building-ec-images-quickly Getting started building EC images quickly]<br />
<br />
== Building outside of the ChromiumOS chroot ==<br />
<br />
You will need:<br />
* GNU Make 4.1 (older versions are having trouble with the Makefiles)<br />
* an ARM cross compiler (I used coreboot's armv7-a-eabi- toolchain)<br />
<br />
Let's go:<br />
<br />
$ sudo aptitude install libftdi-dev<br />
$ git clone https://chromium.googlesource.com/chromiumos/platform/ec<br />
[..]<br />
$ cd ec<br />
$ CROSS_COMPILE=armv7-a-eabi- HOST_CROSS_COMPILE= make BOARD=chell<br />
HOSTCC util/ectool<br />
HOSTCC util/lbplay<br />
HOSTCC util/stm32mon<br />
HOSTCC util/ec_sb_firmware_update<br />
HOSTCC util/lbcc<br />
In file included from include/common.h:11:0,<br />
from chip/mec1322/registers.h:11,<br />
from board/chell/board.h:130,<br />
from include/config.h:2063:<br />
.../4.9.2/include/stdint.h:9:26: fatal error: stdint.h: No such file or directory<br />
# include_next <stdint.h><br />
^<br />
compilation terminated.<br />
[..]</div>Stepanhttps://www.coreboot.org/index.php?title=Chrome_EC&diff=17742Chrome EC2016-01-15T23:58:30Z<p>Stepan: Created page with "= Chrome EC = The Chrome EC is used in almost all Chrome OS devices, and an increasing number of accessories, like Google's Type C chargers. It is based on the Chromium EC co..."</p>
<hr />
<div>= Chrome EC =<br />
<br />
The Chrome EC is used in almost all Chrome OS devices, and an increasing number of accessories, like Google's Type C chargers. It is based on the Chromium EC code base.<br />
<br />
= Building the Chrome EC =<br />
<br />
== Building in the ChromiumOS environment ==<br />
<br />
[http://www.chromium.org/chromium-os/ec-development/getting-started-building-ec-images-quickly Getting started building EC images quickly]</div>Stepanhttps://www.coreboot.org/index.php?title=Embedded_controller&diff=17741Embedded controller2016-01-15T23:55:12Z<p>Stepan: /* Chromebooks */</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="0" style="font-size: smaller"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Vendor<br />
! align="left" | Model<br />
! align="left" | Type<br />
! align="left" | Architecture<br />
! align="left" | Datasheet(s)<br />
! align="left" | Comments<br />
<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || KB910 || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || KB926C || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || KB926D || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || KB3310 || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<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] || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&id=2256 KB3910] || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&id=2268 KB3920] || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&id=2269 KB3925] || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&id=2270 KB3926] || EC || 8bit, 8051 core || ? || &mdash;<br />
<br />
|- bgcolor="#dddddd"<br />
| [http://www.fujitsu.com Fujitsu] || MB90378 || EC || 16bit, F<sup>2</sup>MC-16LX family || [http://edevice.fujitsu.com/fj/DATASHEET/e-ds/e713740.pdf] || &mdash;<br />
<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || IT8500 || EC & Super I/O || ? || ? || Source: [http://gmb.viatech.com.cn/resource/downloads/VGTF-Autumn/ITE/ITE.pdf]<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || IT8502E || EC & 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="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&ID=6,79 IT8510E/TE/G] || EC & Super I/O || 8bit, 8032 core (8051 compatible) || on request || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&ID=6,80 IT8511E/TE/G] || EC & Super I/O || 8bit, 8032 core (8051 compatible) || on request || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&ID=6,81 IT8512E/F/G] || EC & Super I/O || 8bit, 8032 core (8051 compatible) || on request || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&ID=6,82 IT8513E/F/G] || EC & Super I/O || 8bit, 8032 core (8051 compatible) || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || IT8516 || EC & Super I/O || ? || ? || Source: [http://gmb.viatech.com.cn/resource/downloads/VGTF-Autumn/ITE/ITE.pdf]<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&ID=6,84 IT8301E] || External GPIO chip || ? || ? || &mdash;<br />
<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || 87541V || EC || 16 bit, CR16B core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || PC97551<sup>3</sup> || EC || 16 bit, CR16B core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/ECAndNBKeyboardController/W83L951DG_W83L951FG.htm W83L951DG/FG]<sup>4</sup> || EC || 8 bit, 8051 core || on request || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/ECAndNBKeyboardController/W83L951ADG_W83L951AFG.htm W83L951ADG/AFG]<sup>4</sup> || EC || 8 bit, 8051 core || on request || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/AdvancedEmbeddedController/WPC8769L.htm WPC8765L/WPC8769L]<sup>4</sup> || EC || 16 bit, ? core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/AdvancedEmbeddedController/WPC8763L.htm WPC8763L]<sup>4</sup> || EC || 16 bit, CR16CPlus core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/AdvancedEmbeddedController/WPCE775x.htm WPCE775x]<sup>4</sup> || EC || 16 bit, CR16CPlus core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || NPCE78nx || EC || ? || ? || &mdash;<br />
<br />
|- bgcolor="#dddddd"<br />
| [http://eu.renesas.com/ Renesas] || [http://eu.renesas.com/fmwk.jsp?cnt=3885_root.jsp&fp=/products/mpumcu/740_family/38000_740_series/3885_group/ M38859]<sup>1</sup> || EC || 8bit, 740 family || [http://documentation.renesas.com/eng/products/mpumcu/e3885g.pdf] || &mdash;<br />
|- bgcolor="#dddddd"<br />
| [http://eu.renesas.com/ Renesas] || [http://eu.renesas.com/fmwk.jsp?cnt=3886_root.jsp&fp=/products/mpumcu/740_family/38000_740_series/3886_group/ M38867M8A]<sup>1</sup> || EC || 8bit, 740 family || [http://documentation.renesas.com/eng/products/mpumcu/e3886g.pdf] || &mdash;<br />
|- bgcolor="#dddddd"<br />
| [http://eu.renesas.com/ Renesas] || [http://eu.renesas.com/fmwk.jsp?cnt=h8s2117_root.jsp&fp=/products/mpumcu/h8s_family/h8s2100_series/h8s2117_group H8S/2117R]<sup>2</sup> || EC || 16 bit, H8S family || ? || Source: [http://www.intelcommsalliance.com/kshowcase/view/view_item/4ddd1dbe78eb6b235cc4f07eabb79ae562ae690e]<br />
|- bgcolor="#dddddd"<br />
| [http://eu.renesas.com/ Renesas] || H8S/2161B<sup>2</sup> || 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="#dddddd"<br />
| [http://eu.renesas.com/ Renesas] || H8S/2169AV <sup>2</sup> || 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="#dddddd"<br />
| [http://eu.renesas.com/ Renesas] || H8S/64F3169ATE10<sup>2</sup> || EC || 16 bit, H8S family || ? || &mdash;<br />
<br />
|- bgcolor="#eeeeee"<br />
| [http://www.national.com NSC] || PC87570 || EC & Super I/O || ? || ? || &mdash;<br />
<br />
|- bgcolor="#dddddd"<br />
| [http://www.smsc.com/ SMSC] || FDC37N958FR || EC & Super I/O || ? || ? || &mdash;<br />
|- bgcolor="#dddddd"<br />
| [http://www.smsc.com/ SMSC] || LPC47N252 || EC & Super I/O || ? || ? || &mdash;<br />
|- bgcolor="#dddddd"<br />
| [http://www.smsc.com/ SMSC] || [http://www.smsc.com/index.php?tid=252&pid=173 MEC1308] || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#dddddd"<br />
| [http://www.smsc.com/ SMSC] || [http://www.smsc.com/index.php?tid=252&pid=172 KBC1122/KBC1122P] || EC & Super I/O || 8bit, 8051 core || ? || &mdash;<br />
<br />
|- bgcolor="#eeeeee"<br />
| [http://www.sst.com/ SST] || [http://www.sst.com/about_sst/news/detail.dot?crumbTitle=NewsDetail&id=320 SST79LF008] || EC & Super I/O & BIOS flash || 8bit, 8051 core || ? || &mdash;<br />
<br />
|}<br />
<br />
<small><br />
<sup>1</sup> Previously Mitsubishi, now Renesas.<br /><br />
<sup>2</sup> Previously Hitachi, now Renesas.<br /><br />
<sup>3</sup> Previously National (NSC), then Winbond, now Nuvoton.<br /><br />
<sup>4</sup> Previously Winbond, now Nuvoton.<br /><br />
</small><br />
<br />
== Resources ==<br />
<br />
=== Chromebooks ===<br />
* [https://chromium.googlesource.com/chromiumos/platform/ec/ The chromebooks EC firmware project]<br />
* Building the [[Chrome EC]] outside of the Chromium chroot<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 "Index IO" 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>Stepanhttps://www.coreboot.org/index.php?title=Embedded_controller&diff=17740Embedded controller2016-01-15T23:54:52Z<p>Stepan: /* Chromebooks */</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="0" style="font-size: smaller"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Vendor<br />
! align="left" | Model<br />
! align="left" | Type<br />
! align="left" | Architecture<br />
! align="left" | Datasheet(s)<br />
! align="left" | Comments<br />
<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || KB910 || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || KB926C || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || KB926D || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || KB3310 || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<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] || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&id=2256 KB3910] || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&id=2268 KB3920] || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&id=2269 KB3925] || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ene.com.tw/en/index.asp ENE] || [http://www.ene.com.tw/en/product_detail.asp?pid=366&id=2270 KB3926] || EC || 8bit, 8051 core || ? || &mdash;<br />
<br />
|- bgcolor="#dddddd"<br />
| [http://www.fujitsu.com Fujitsu] || MB90378 || EC || 16bit, F<sup>2</sup>MC-16LX family || [http://edevice.fujitsu.com/fj/DATASHEET/e-ds/e713740.pdf] || &mdash;<br />
<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || IT8500 || EC & Super I/O || ? || ? || Source: [http://gmb.viatech.com.cn/resource/downloads/VGTF-Autumn/ITE/ITE.pdf]<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || IT8502E || EC & 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="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&ID=6,79 IT8510E/TE/G] || EC & Super I/O || 8bit, 8032 core (8051 compatible) || on request || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&ID=6,80 IT8511E/TE/G] || EC & Super I/O || 8bit, 8032 core (8051 compatible) || on request || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&ID=6,81 IT8512E/F/G] || EC & Super I/O || 8bit, 8032 core (8051 compatible) || on request || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&ID=6,82 IT8513E/F/G] || EC & Super I/O || 8bit, 8032 core (8051 compatible) || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || IT8516 || EC & Super I/O || ? || ? || Source: [http://gmb.viatech.com.cn/resource/downloads/VGTF-Autumn/ITE/ITE.pdf]<br />
|- bgcolor="#eeeeee"<br />
| [http://www.ite.com.tw/EN/index.aspx ITE] || [http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&ID=6,84 IT8301E] || External GPIO chip || ? || ? || &mdash;<br />
<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || 87541V || EC || 16 bit, CR16B core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || PC97551<sup>3</sup> || EC || 16 bit, CR16B core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/ECAndNBKeyboardController/W83L951DG_W83L951FG.htm W83L951DG/FG]<sup>4</sup> || EC || 8 bit, 8051 core || on request || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/ECAndNBKeyboardController/W83L951ADG_W83L951AFG.htm W83L951ADG/AFG]<sup>4</sup> || EC || 8 bit, 8051 core || on request || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/AdvancedEmbeddedController/WPC8769L.htm WPC8765L/WPC8769L]<sup>4</sup> || EC || 16 bit, ? core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/AdvancedEmbeddedController/WPC8763L.htm WPC8763L]<sup>4</sup> || EC || 16 bit, CR16CPlus core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || [http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ComputerIC/ECAndNBKeyboardController/AdvancedEmbeddedController/WPCE775x.htm WPCE775x]<sup>4</sup> || EC || 16 bit, CR16CPlus core || ? || &mdash;<br />
|- bgcolor="#eeeeee"<br />
| [http://www.nuvoton.com/ Nuvoton] || NPCE78nx || EC || ? || ? || &mdash;<br />
<br />
|- bgcolor="#dddddd"<br />
| [http://eu.renesas.com/ Renesas] || [http://eu.renesas.com/fmwk.jsp?cnt=3885_root.jsp&fp=/products/mpumcu/740_family/38000_740_series/3885_group/ M38859]<sup>1</sup> || EC || 8bit, 740 family || [http://documentation.renesas.com/eng/products/mpumcu/e3885g.pdf] || &mdash;<br />
|- bgcolor="#dddddd"<br />
| [http://eu.renesas.com/ Renesas] || [http://eu.renesas.com/fmwk.jsp?cnt=3886_root.jsp&fp=/products/mpumcu/740_family/38000_740_series/3886_group/ M38867M8A]<sup>1</sup> || EC || 8bit, 740 family || [http://documentation.renesas.com/eng/products/mpumcu/e3886g.pdf] || &mdash;<br />
|- bgcolor="#dddddd"<br />
| [http://eu.renesas.com/ Renesas] || [http://eu.renesas.com/fmwk.jsp?cnt=h8s2117_root.jsp&fp=/products/mpumcu/h8s_family/h8s2100_series/h8s2117_group H8S/2117R]<sup>2</sup> || EC || 16 bit, H8S family || ? || Source: [http://www.intelcommsalliance.com/kshowcase/view/view_item/4ddd1dbe78eb6b235cc4f07eabb79ae562ae690e]<br />
|- bgcolor="#dddddd"<br />
| [http://eu.renesas.com/ Renesas] || H8S/2161B<sup>2</sup> || 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="#dddddd"<br />
| [http://eu.renesas.com/ Renesas] || H8S/2169AV <sup>2</sup> || 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="#dddddd"<br />
| [http://eu.renesas.com/ Renesas] || H8S/64F3169ATE10<sup>2</sup> || EC || 16 bit, H8S family || ? || &mdash;<br />
<br />
|- bgcolor="#eeeeee"<br />
| [http://www.national.com NSC] || PC87570 || EC & Super I/O || ? || ? || &mdash;<br />
<br />
|- bgcolor="#dddddd"<br />
| [http://www.smsc.com/ SMSC] || FDC37N958FR || EC & Super I/O || ? || ? || &mdash;<br />
|- bgcolor="#dddddd"<br />
| [http://www.smsc.com/ SMSC] || LPC47N252 || EC & Super I/O || ? || ? || &mdash;<br />
|- bgcolor="#dddddd"<br />
| [http://www.smsc.com/ SMSC] || [http://www.smsc.com/index.php?tid=252&pid=173 MEC1308] || EC || 8bit, 8051 core || ? || &mdash;<br />
|- bgcolor="#dddddd"<br />
| [http://www.smsc.com/ SMSC] || [http://www.smsc.com/index.php?tid=252&pid=172 KBC1122/KBC1122P] || EC & Super I/O || 8bit, 8051 core || ? || &mdash;<br />
<br />
|- bgcolor="#eeeeee"<br />
| [http://www.sst.com/ SST] || [http://www.sst.com/about_sst/news/detail.dot?crumbTitle=NewsDetail&id=320 SST79LF008] || EC & Super I/O & BIOS flash || 8bit, 8051 core || ? || &mdash;<br />
<br />
|}<br />
<br />
<small><br />
<sup>1</sup> Previously Mitsubishi, now Renesas.<br /><br />
<sup>2</sup> Previously Hitachi, now Renesas.<br /><br />
<sup>3</sup> Previously National (NSC), then Winbond, now Nuvoton.<br /><br />
<sup>4</sup> Previously Winbond, now Nuvoton.<br /><br />
</small><br />
<br />
== Resources ==<br />
<br />
=== Chromebooks ===<br />
* [https://chromium.googlesource.com/chromiumos/platform/ec/ The chromebooks EC firmware project]<br />
* Building the [Chrome EC] outside of the Chromium chroot<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 "Index IO" 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>Stepanhttps://www.coreboot.org/index.php?title=Development_Guidelines&diff=17709Development Guidelines2016-01-12T19:19:55Z<p>Stepan: /* License Issues */</p>
<hr />
<div>= Development Environment =<br />
<br />
== Required Toolchain ==<br />
<br />
The easiest way to get a working toolchain is to run <code>make crossgcc</code> in the toplevel directory of a coreboot checkout. Distributions usually modify their compilers in ways incompatible with coreboot. If in doubt, use our toolchain.<br />
<br />
The toolchain consists of:<br />
* GNU development environment:<br />
** [http://gcc.gnu.org/ GCC with G++]<br />
** [http://www.kernel.org/pub/linux/devel/binutils/ binutils]<br />
* libncurses*-dev<br />
* [http://www.acpica.org/downloads/ IASL], now part of the '''ACPICA''' download (package ''pmtools'' or ''iasl'' in many distributions)<br />
<br />
= Coding Guidelines =<br />
<br />
== General Guidelines ==<br />
<br />
* Encapsulate and isolate assembly language<br />
* Code shall not be "commented out"<br />
* No use of floating-point arithmetics<br />
* No hiding of identifiers defined in outer scopes<br />
* Typedefs are unique (device_t?)<br />
* Functions shall have prototype declarations<br />
* Local functions should be declared static<br />
* No definitions in header files<br />
* All variables are assigned before use<br />
* All objects should have fully qualified types (''unsigned int'' instead of ''unsigned'')<br />
* Types which indicate signedness and bitness should be used (''uint32_t'' or ''u32'' instead of ''unsigned int'')<br />
* We suggest trying to import more such rules, such as additional ones described in [http://www.misra.org.uk/index.htm MISRA-C 2012] (''Guidelines for the use of C in critical systems'')<br />
<br />
== Variable types ==<br />
<br />
Whenever possible, please use a variable type which is explicit about the size of data it can hold. For example, use '''uint32_t''' or '''u32''' instead of '''unsigned long''' when referencing a 32-bit wide register.<br />
<br />
=== short int names vs stdint names ===<br />
<br />
There is '''currently no hard rule''' on whether one should use short int types ('''u32'''), or stdint types ('''uint32_t'''). Whichever type you elect to use, please use common sense and stay consistent.<br />
<br />
== Comments ==<br />
<br />
=== References ===<br />
<br />
If you are referencing a data sheet or other documentation in the code, please add the name or document number in addition to the URL. Vendors just ''love'' to rearrange their websites (and some remove documentation on their old products altogether)! If we have the name/number (or even just the filename of the PDF) at least there's a chance to google for it again (either on the vendor's site or on some archive).<br />
<br />
== Coding Style ==<br />
<br />
* We use the coreboot [[Coding Style]] throughout the project.<br />
* You can use the 'indent' tool to fix the coding style like this:<br />
indent -npro -kr -i8 -ts8 -sob -l80 -ss -ncs *.[ch]<br />
:Do not trust 'indent' blindly, though. It sometimes gets things wrong. Manual corrections may be required.<br />
<br />
== The 80 character limit ==<br />
<br />
Lines larger than 80 columns should be broken down into readable pieces. This includes not only source files, but also Makefiles, Kconfig files, and any file meant to be edited by a human. We recommend setting your editor to show the 80th character limit.<br />
This limit is not a relic from long forgotten times, but a very practical and efficient way to organize code and increase productivity. Several files can be edited on the same monitor, without the need to side-scroll. Side-scrolling source files is inefficient, time-consuming, and uncomfortable. On average, 95% of source lines are shorter than 80 characters, so limiting the line length is this manner is not only _not_ an impediment, it also gets you to think on how to best organize the code.<br />
<br />
= Documentation Guidelines =<br />
<br />
== General Guidelines and Tips ==<br />
<br />
* Documentation should be put into the wiki and/or in the code as Doxygen comments<br />
* Avoid using different styles and looks of documentation<br />
* Document ''why'' and ''what'', not ''how'' (No comments like ''/* add one to i */'')<br />
* Document assumptions, stipulations etc...<br />
* Document design and concepts!<br />
* Not lots of documentation but good documentation<br />
* Structured documentation<br />
* Focus: Whom are you addressing in your documentation? Write documentation for users, developers, vendors, ...<br />
<br />
== Automatic documentation ==<br />
<br />
* Doxygen-generated API- and code documentation is available at http://qa.coreboot.org/docs/. This documentation is updated on every 10th checkin.<br />
* To create a Doxygen comment, write<br />
/**<br />
* Sample comment.<br />
*/<br />
:or<br />
/** Sample comment. */<br />
* There are a few commands that describe what kind of comment you are adding:<br />
::@param &mdash; input parameters of a function<br />
::@return &mdash; return value of a function<br />
* A list of all commands is available at http://www.stack.nl/~dimitri/doxygen/commands.html<br />
<br />
Full example:<br />
<br />
/**<br />
* Calculate the length of a string.<br />
*<br />
* @param str The input string.<br />
* @return The length of the string, not including the final NUL character.<br />
*/<br />
static inline size_t strlen(const char *str)<br />
{<br />
/* ... */<br />
}<br />
<br />
= Testing =<br />
<br />
Every commit will be processed by the autobuild and autotest system available at http://qa.coreboot.org/. In addition please run autobuild yourself before submitting patches.<br />
<br />
== autobuild ==<br />
<br />
Autobuild can be found at [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=util/abuild;hb=HEAD coreboot/util/abuild]. <br />
<br />
Please run ''abuild'' '''before''' you commit.<br />
<br />
Autobuild is also running on every check-in to the repository. The results of this build are also available at http://qa.coreboot.org/.<br />
<br />
== autotest ==<br />
<br />
We can also run automatic tests on boards, if we find contributors willing to have a board automatically managed by our QA system. This requires a permanent connection to the net, a host system and some special circuitry. If interested, please contact us using the [[Mailinglist|mailing list]].<br />
<br />
= How to contribute =<br />
<br />
== Creating Patches ==<br />
<br />
* We use gerrit for change management, using the instance on http://review.coreboot.org/<br />
* While not necessary with gerrit, '''make sure that your change is against current master'''. Patches that fail on merge (after some developer looked at it and approved it) might linger around until '''you''' update it.<br />
* Rebase, if necessary, '''then test''' again. You might be the only contributor with that specific mainboard.<br />
* Make sure all new and modified files contain the [[Development Guidelines#Common_License_Header|proper license headers]] (see below).<br />
* Make sure all added files are actually within the commit.<br />
* Make one commit per logical change.<br />
* For more details on using gerrit, see our [[Git]] documentation. Things are somewhat different (eg. it's normal to rebase changes that were already pushed).<br />
* Double-check that your changes are correct, and that the commit only contains what you think it contains.<br />
<br />
== Sign-off Procedure ==<br />
<br />
We employ a similar sign-off procedure for coreboot <br />
[http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html as the Linux kernel developers] do.<br />
Please add a note such as<br />
Signed-off-by: Random J Developer <random@developer.example.org><br />
to your email/patch if you agree with the following Developer's Certificate of Origin 1.1.<br />
<br />
Patches without a Signed-off-by cannot be pushed to gerrit!<br />
<br />
<span style="color:red">You have to use your real name in the Signed-off-by line and in any copyright notices you add.</span> Patches without an associated real name cannot be committed!<br />
<br />
'''Developer's Certificate of Origin 1.1:'''<br />
<br />
By making a contribution to this project, I certify that:<br /><br />
(a) The contribution was created in whole or in part by me and I have<br />
the right to submit it under the open source license indicated in the file; or<br /><br />
(b) The contribution is based upon previous work that, to the best of my<br />
knowledge, is covered under an appropriate open source license and I have the<br />
right under that license to submit that work with modifications, whether created<br />
in whole or in part by me, under the same open source license (unless I am<br />
permitted to submit under a different license), as indicated in the file; or<br /><br />
(c) The contribution was provided directly to me by some other person who<br />
certified (a), (b) or (c) and I have not modified it; and<br /><br />
(d) In the case of each of (a), (b), or (c), I understand and agree that<br />
this project and the contribution are public and that a record of the contribution<br />
(including all personal information I submit with it, including my sign-off) is<br />
maintained indefinitely and may be redistributed consistent with this project or the<br />
open source license indicated in the file.<br />
<br />
<small>Note: The [http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html Developer's Certificate of Origin 1.1] is licensed under the terms of the [http://creativecommons.org/licenses/by-sa/2.5/ Creative Commons Attribution-ShareAlike 2.5 License].</small><br />
<br />
== Reviews ==<br />
<br />
* Send your patch to [[Git|gerrit]] for review.<br />
** Provide useful commit messages. Explain what the change does and why. Our short intro to [[Git|git]] explains the format in more detail.<br />
** Add a single line containing your "[[Development Guidelines#Sign-off_Procedure|sign-off]]" after the description of the patch (<code>git commit -s</code> helps, but make sure you understand and comply with the DCO).<br />
*** Example: ''Signed-off-by: John Doe <john@example.com>''<br />
* The developers will review and/or test your change and send comments or suggestions. Please push updated patches as described in "[[Git#Evolving_patches|evolving patches]]".<br />
* If the change looks ok to one or more developers, they will approve and submit it to the master branch.<br />
<br />
= Bug-Tracker =<br />
<br />
'''note: the bug tracker is dead. more or less.'''<br />
<br />
= License Issues =<br />
<br />
* Contributed code must be GPL'd (preferrably 'GPLv2', but 'GPLv2 or any later version' is fine, too). At the very minimum the code must have a GPLv2-compatible license.<br />
<br />
== Common License Header ==<br />
<br />
Please quote the shortened GPL license header text in every file, as shown below. It should contain:<br />
<br />
* The '''year(s)''' when the code was written or modified and a '''copyright note''' of you (or your company, if you are contributing as part of your employment, and thus the copyright belongs to your company). Also, please provide an '''email address''' if possible so that you can be contacted if questions arise.<br />
** Example:<br />
::''Copyright (C) 2006 John Doe <john@example.com>''<br />
::''Copyright (C) 2004-2006 Company, Inc.''<br />
* The full '''GPL header''' as shown below.<br />
<br />
'''Complete example for *.c and *.h files:'''<br />
<br />
/*<br />
* This file is part of the coreboot project.<br />
*<br />
* Copyright (C) 2003-2005 Jane Doe <jane@example.com><br />
* Copyright (C) 2006 Company, Inc.<br />
*<br />
* This program is free software; you can redistribute it and/or modify<br />
* it under the terms of the GNU General Public License as published by<br />
* the Free Software Foundation; version 2 of the License.<br />
*<br />
* This program is distributed in the hope that it will be useful,<br />
* but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
* GNU General Public License for more details.<br />
*/<br />
<br />
'''Complete example for Makefiles, config files, Python files, shell scripts etc.:'''<br />
<br />
##<br />
## This file is part of the coreboot project.<br />
##<br />
## Copyright (C) 2003-2005 Jane Doe <jane@example.com><br />
## Copyright (C) 2006 Company, Inc.<br />
##<br />
## This program is free software; you can redistribute it and/or modify<br />
## it under the terms of the GNU General Public License as published by<br />
## the Free Software Foundation; version 2 of the License.<br />
##<br />
## This program is distributed in the hope that it will be useful,<br />
## but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
## GNU General Public License for more details.<br />
##</div>Stepanhttps://www.coreboot.org/index.php?title=Development_Guidelines&diff=17708Development Guidelines2016-01-12T19:18:48Z<p>Stepan: /* Common License Header */ Fix up license header requirement to match the discussions on the mailing list from a few months ago.</p>
<hr />
<div>= Development Environment =<br />
<br />
== Required Toolchain ==<br />
<br />
The easiest way to get a working toolchain is to run <code>make crossgcc</code> in the toplevel directory of a coreboot checkout. Distributions usually modify their compilers in ways incompatible with coreboot. If in doubt, use our toolchain.<br />
<br />
The toolchain consists of:<br />
* GNU development environment:<br />
** [http://gcc.gnu.org/ GCC with G++]<br />
** [http://www.kernel.org/pub/linux/devel/binutils/ binutils]<br />
* libncurses*-dev<br />
* [http://www.acpica.org/downloads/ IASL], now part of the '''ACPICA''' download (package ''pmtools'' or ''iasl'' in many distributions)<br />
<br />
= Coding Guidelines =<br />
<br />
== General Guidelines ==<br />
<br />
* Encapsulate and isolate assembly language<br />
* Code shall not be "commented out"<br />
* No use of floating-point arithmetics<br />
* No hiding of identifiers defined in outer scopes<br />
* Typedefs are unique (device_t?)<br />
* Functions shall have prototype declarations<br />
* Local functions should be declared static<br />
* No definitions in header files<br />
* All variables are assigned before use<br />
* All objects should have fully qualified types (''unsigned int'' instead of ''unsigned'')<br />
* Types which indicate signedness and bitness should be used (''uint32_t'' or ''u32'' instead of ''unsigned int'')<br />
* We suggest trying to import more such rules, such as additional ones described in [http://www.misra.org.uk/index.htm MISRA-C 2012] (''Guidelines for the use of C in critical systems'')<br />
<br />
== Variable types ==<br />
<br />
Whenever possible, please use a variable type which is explicit about the size of data it can hold. For example, use '''uint32_t''' or '''u32''' instead of '''unsigned long''' when referencing a 32-bit wide register.<br />
<br />
=== short int names vs stdint names ===<br />
<br />
There is '''currently no hard rule''' on whether one should use short int types ('''u32'''), or stdint types ('''uint32_t'''). Whichever type you elect to use, please use common sense and stay consistent.<br />
<br />
== Comments ==<br />
<br />
=== References ===<br />
<br />
If you are referencing a data sheet or other documentation in the code, please add the name or document number in addition to the URL. Vendors just ''love'' to rearrange their websites (and some remove documentation on their old products altogether)! If we have the name/number (or even just the filename of the PDF) at least there's a chance to google for it again (either on the vendor's site or on some archive).<br />
<br />
== Coding Style ==<br />
<br />
* We use the coreboot [[Coding Style]] throughout the project.<br />
* You can use the 'indent' tool to fix the coding style like this:<br />
indent -npro -kr -i8 -ts8 -sob -l80 -ss -ncs *.[ch]<br />
:Do not trust 'indent' blindly, though. It sometimes gets things wrong. Manual corrections may be required.<br />
<br />
== The 80 character limit ==<br />
<br />
Lines larger than 80 columns should be broken down into readable pieces. This includes not only source files, but also Makefiles, Kconfig files, and any file meant to be edited by a human. We recommend setting your editor to show the 80th character limit.<br />
This limit is not a relic from long forgotten times, but a very practical and efficient way to organize code and increase productivity. Several files can be edited on the same monitor, without the need to side-scroll. Side-scrolling source files is inefficient, time-consuming, and uncomfortable. On average, 95% of source lines are shorter than 80 characters, so limiting the line length is this manner is not only _not_ an impediment, it also gets you to think on how to best organize the code.<br />
<br />
= Documentation Guidelines =<br />
<br />
== General Guidelines and Tips ==<br />
<br />
* Documentation should be put into the wiki and/or in the code as Doxygen comments<br />
* Avoid using different styles and looks of documentation<br />
* Document ''why'' and ''what'', not ''how'' (No comments like ''/* add one to i */'')<br />
* Document assumptions, stipulations etc...<br />
* Document design and concepts!<br />
* Not lots of documentation but good documentation<br />
* Structured documentation<br />
* Focus: Whom are you addressing in your documentation? Write documentation for users, developers, vendors, ...<br />
<br />
== Automatic documentation ==<br />
<br />
* Doxygen-generated API- and code documentation is available at http://qa.coreboot.org/docs/. This documentation is updated on every 10th checkin.<br />
* To create a Doxygen comment, write<br />
/**<br />
* Sample comment.<br />
*/<br />
:or<br />
/** Sample comment. */<br />
* There are a few commands that describe what kind of comment you are adding:<br />
::@param &mdash; input parameters of a function<br />
::@return &mdash; return value of a function<br />
* A list of all commands is available at http://www.stack.nl/~dimitri/doxygen/commands.html<br />
<br />
Full example:<br />
<br />
/**<br />
* Calculate the length of a string.<br />
*<br />
* @param str The input string.<br />
* @return The length of the string, not including the final NUL character.<br />
*/<br />
static inline size_t strlen(const char *str)<br />
{<br />
/* ... */<br />
}<br />
<br />
= Testing =<br />
<br />
Every commit will be processed by the autobuild and autotest system available at http://qa.coreboot.org/. In addition please run autobuild yourself before submitting patches.<br />
<br />
== autobuild ==<br />
<br />
Autobuild can be found at [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=util/abuild;hb=HEAD coreboot/util/abuild]. <br />
<br />
Please run ''abuild'' '''before''' you commit.<br />
<br />
Autobuild is also running on every check-in to the repository. The results of this build are also available at http://qa.coreboot.org/.<br />
<br />
== autotest ==<br />
<br />
We can also run automatic tests on boards, if we find contributors willing to have a board automatically managed by our QA system. This requires a permanent connection to the net, a host system and some special circuitry. If interested, please contact us using the [[Mailinglist|mailing list]].<br />
<br />
= How to contribute =<br />
<br />
== Creating Patches ==<br />
<br />
* We use gerrit for change management, using the instance on http://review.coreboot.org/<br />
* While not necessary with gerrit, '''make sure that your change is against current master'''. Patches that fail on merge (after some developer looked at it and approved it) might linger around until '''you''' update it.<br />
* Rebase, if necessary, '''then test''' again. You might be the only contributor with that specific mainboard.<br />
* Make sure all new and modified files contain the [[Development Guidelines#Common_License_Header|proper license headers]] (see below).<br />
* Make sure all added files are actually within the commit.<br />
* Make one commit per logical change.<br />
* For more details on using gerrit, see our [[Git]] documentation. Things are somewhat different (eg. it's normal to rebase changes that were already pushed).<br />
* Double-check that your changes are correct, and that the commit only contains what you think it contains.<br />
<br />
== Sign-off Procedure ==<br />
<br />
We employ a similar sign-off procedure for coreboot <br />
[http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html as the Linux kernel developers] do.<br />
Please add a note such as<br />
Signed-off-by: Random J Developer <random@developer.example.org><br />
to your email/patch if you agree with the following Developer's Certificate of Origin 1.1.<br />
<br />
Patches without a Signed-off-by cannot be pushed to gerrit!<br />
<br />
<span style="color:red">You have to use your real name in the Signed-off-by line and in any copyright notices you add.</span> Patches without an associated real name cannot be committed!<br />
<br />
'''Developer's Certificate of Origin 1.1:'''<br />
<br />
By making a contribution to this project, I certify that:<br /><br />
(a) The contribution was created in whole or in part by me and I have<br />
the right to submit it under the open source license indicated in the file; or<br /><br />
(b) The contribution is based upon previous work that, to the best of my<br />
knowledge, is covered under an appropriate open source license and I have the<br />
right under that license to submit that work with modifications, whether created<br />
in whole or in part by me, under the same open source license (unless I am<br />
permitted to submit under a different license), as indicated in the file; or<br /><br />
(c) The contribution was provided directly to me by some other person who<br />
certified (a), (b) or (c) and I have not modified it; and<br /><br />
(d) In the case of each of (a), (b), or (c), I understand and agree that<br />
this project and the contribution are public and that a record of the contribution<br />
(including all personal information I submit with it, including my sign-off) is<br />
maintained indefinitely and may be redistributed consistent with this project or the<br />
open source license indicated in the file.<br />
<br />
<small>Note: The [http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html Developer's Certificate of Origin 1.1] is licensed under the terms of the [http://creativecommons.org/licenses/by-sa/2.5/ Creative Commons Attribution-ShareAlike 2.5 License].</small><br />
<br />
== Reviews ==<br />
<br />
* Send your patch to [[Git|gerrit]] for review.<br />
** Provide useful commit messages. Explain what the change does and why. Our short intro to [[Git|git]] explains the format in more detail.<br />
** Add a single line containing your "[[Development Guidelines#Sign-off_Procedure|sign-off]]" after the description of the patch (<code>git commit -s</code> helps, but make sure you understand and comply with the DCO).<br />
*** Example: ''Signed-off-by: John Doe <john@example.com>''<br />
* The developers will review and/or test your change and send comments or suggestions. Please push updated patches as described in "[[Git#Evolving_patches|evolving patches]]".<br />
* If the change looks ok to one or more developers, they will approve and submit it to the master branch.<br />
<br />
= Bug-Tracker =<br />
<br />
'''note: the bug tracker is dead. more or less.'''<br />
<br />
= License Issues =<br />
<br />
* Contributed code must be GPL'd (preferrably 'GPLv2 or any later version', but 'GPLv2' is fine, too). At the very minimum the code must have a GPL-compatible license.<br />
<br />
== Common License Header ==<br />
<br />
Please quote the shortened GPL license header text in every file, as shown below. It should contain:<br />
<br />
* The '''year(s)''' when the code was written or modified and a '''copyright note''' of you (or your company, if you are contributing as part of your employment, and thus the copyright belongs to your company). Also, please provide an '''email address''' if possible so that you can be contacted if questions arise.<br />
** Example:<br />
::''Copyright (C) 2006 John Doe <john@example.com>''<br />
::''Copyright (C) 2004-2006 Company, Inc.''<br />
* The full '''GPL header''' as shown below.<br />
<br />
'''Complete example for *.c and *.h files:'''<br />
<br />
/*<br />
* This file is part of the coreboot project.<br />
*<br />
* Copyright (C) 2003-2005 Jane Doe <jane@example.com><br />
* Copyright (C) 2006 Company, Inc.<br />
*<br />
* This program is free software; you can redistribute it and/or modify<br />
* it under the terms of the GNU General Public License as published by<br />
* the Free Software Foundation; version 2 of the License.<br />
*<br />
* This program is distributed in the hope that it will be useful,<br />
* but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
* GNU General Public License for more details.<br />
*/<br />
<br />
'''Complete example for Makefiles, config files, Python files, shell scripts etc.:'''<br />
<br />
##<br />
## This file is part of the coreboot project.<br />
##<br />
## Copyright (C) 2003-2005 Jane Doe <jane@example.com><br />
## Copyright (C) 2006 Company, Inc.<br />
##<br />
## This program is free software; you can redistribute it and/or modify<br />
## it under the terms of the GNU General Public License as published by<br />
## the Free Software Foundation; version 2 of the License.<br />
##<br />
## This program is distributed in the hope that it will be useful,<br />
## but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
## GNU General Public License for more details.<br />
##</div>Stepanhttps://www.coreboot.org/index.php?title=Welcome_to_coreboot&diff=17425Welcome to coreboot2015-11-22T19:21:11Z<p>Stepan: </p>
<hr />
<div><table width="100%" valign="top"><tr valign="top"><td width="80%"><br />
<br />
<div style="margin-top:0.5em; margin-bottom:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;"><br />
'''coreboot''' is an Open Source project aimed at replacing the proprietary [http://wikipedia.org/wiki/BIOS BIOS] (firmware) found in most computers. coreboot performs a little bit of hardware initialization and then executes additional boot logic, called a [[Payloads|payload]].<br />
<br />
With the separation of hardware initialization and later boot logic, coreboot can scale from specialized applications that run directly from firmware, run operating systems in flash, load custom bootloaders, or implement firmware standards, like [[SeaBIOS | PC BIOS services]] or [[TianoCore | UEFI]]. This allows for systems to only include the features necessary in the target application, reducing the amount of code and flash space required.<br />
<br />
coreboot currently supports over '''[[Supported Motherboards|230]]''' different mainboards. Check the [[Support]] page to see if your system is supported.<br />
<br />
<small><br />
coreboot was formerly known as [http://www.coreboot.org/pipermail/coreboot/2008-January/029135.html LinuxBIOS]. <br />
</small><br />
</div><br />
<br />
<div style="margin-top:0.5em; margin-bottom:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;"><br />
coreboot uses [[git]] for source control and [http://review.coreboot.org gerrit] as the patch review tool.<br />
</div><br />
<br />
{| cellspacing=0 cellpadding=8 border=0 margin=0 padding=0 align="top" width=100%<br />
|-<br />
|style="vertical-align:top"|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = yellow|<br />
WIDTH = 100%|<br />
ICON = <small>[[Benefits|More...]]</small>|<br />
HEADING = <span style="font-variant:small-caps; font-size:120%">[[Benefits]]</span>|<br />
CONTENT =<br />
<small><br />
* 100% Free Software (GPL), no royalties, no license fees!<br />
* Fast boot times (500 milliseconds to verified Linux kernel)<br />
<!-- * Avoids the need for a slow/buggy/proprietary BIOS --><br />
<!-- * Runs in 32-Bit protected mode almost from the start --><br />
<!-- * Written in C, contains virtually no assembly code --><br />
* Supports many [[Supported Motherboards|mainboards]], [[Supported Chipsets and Devices|chipsets]], and [[payloads]]<br />
<!-- * Further features: netboot, serial console, remote flashing, ... --><br />
</small><br />
}}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = #d1adf6|<br />
WIDTH = 100%|<br />
ICON = <small>[[Use Cases|More...]]</small>|<br />
HEADING = <span style="font-variant:small-caps; font-size:120%">[[Use Cases]]</span>|<br />
CONTENT =<br />
<small><br />
* Desktop PCs, servers, [[Laptop|laptops]]<br />
* [[Clusters]]<br />
<!-- * Set-Top-Boxes, thin clients --><br />
* Embedded solutions<br />
<!-- * [http://en.wikipedia.org/wiki/Small_form_factor Small form factor computers], [http://en.wikipedia.org/wiki/Home_theater_PC Home-theater PCs] --><br />
<!-- * No-moving-parts solutions (ROM chip as "disk") --><br />
<!-- * Non-standard scenarios (e.g. FPGA in Opteron socket) --><br />
</small><br />
}}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = lime|<br />
WIDTH = 100%|<br />
ICON = <small>[[Payloads|More...]]</small>|<br />
HEADING = <span style="font-variant:small-caps; font-size:120%">[[Payloads]]</span>|<br />
CONTENT =<br />
<small><br />
* [[SeaBIOS]] / [[FILO]] / [[GRUB2]] / [[Payloads|...]] <!-- / [[OpenFirmware]] / [[OpenBIOS]] --><br />
* [[Linux]] / [[Windows]] / [[FreeBSD]] / [[NetBSD]] / [[Payloads|...]] <!-- / [http://openbsd.org/ OpenBSD]--><br />
* [[Etherboot]] / [[GPXE]] / [[iPXE]] / [[Payloads|...]]<br />
<!--* [[Memtest86]]<br />
* [[Bayou]] / [[Coreinfo]] / [[Tint]] / [[Libpayload]]--><br />
</small><br />
}}<br />
<br />
|}<br />
<br />
{| cellspacing=5 cellpadding=15 border=0 valign="top" width=100%<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_cb.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">About</span>'''<br /><small>Find out more about coreboot.</small><small><hr />[[Press]] | [[Logo]] | [[History]] | [[Screenshots|Screenshots/Videos]] | [[Contributors]] | [[Sponsors]] | [[Products]] | [[Vendors]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_devel.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">Developers</span>'''<br /><small>Get involved! Help us make coreboot better.</small><small><hr />[[Development Guidelines]] | [[Developer Manual]] | [http://qa.coreboot.org/docs/doxygen.php Doxygen] | [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree Browse Source] | [[GSoC]] | [[Where to start]] | [[Distributed and Automated Testsystem|Testsystem]]</small><br />
|}<br />
<br />
|-<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_status.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">Status</span>'''<br /><small>Find out whether your hardware is already supported.</small><small><hr />[[Supported Motherboards|Supported Boards]] | [[Supported Chipsets and Devices|Supported Chipsets]] | [[:Category:Tutorials|Board Status Pages]] | [[Blob Matrix|Blob Matrix]] | [http://qa.coreboot.org Build Status]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_tools.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">Related Tools</span>'''<br /><small>Tools and libraries related to coreboot.</small><small><hr />[http://www.flashrom.org flashrom] | [[Superiotool]] | [[Nvramtool]] | [[Buildrom]] | [[Mkelfimage]] | [[Inteltool]] | [[Msrtool]] | [[Ectool]] | [[Developer_Manual/Tools|Hardware tools]] | [[Abuild]] | [http://serialice.com SerialICE]</small><br />
|}<br />
<br />
|-<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_101.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">Getting Started</span>'''<br /><small>Download coreboot and get started.</small><small><hr />[[Build HOWTO]] | [[Download coreboot|Downloads]] | [[Documentation]] | [[QEMU]] | [[AMD SimNow]] | [[Build from Windows]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_support.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">Support</span>'''<br /><small>Learn how to contact us and find help and support.</small><small><hr />[[FAQ]] | [[Mailinglist]] | [[IRC]] | [[Glossary]] | [[coreboot Options|coreboot Options]]</small><br />
|}<br />
<br />
|}<br />
</td><td width="20%"><br />
<br />
[[File:Coreboot menuconfig.png|center|thumb|[[Build HOWTO|make menuconfig]] in coreboot]]<br />
<br />
<br clear=all /><br />
<br />
'''<span style="font-variant:small-caps; font-size:120%">[http://blogs.coreboot.org News (blog)]</span>'''<hr /><br />
<small><br />
<rss max=5>http://blogs.coreboot.org/feed/</rss><br />
</small><br />
<br />
<br />
'''<span style="font-variant:small-caps; font-size:120%">[[Current events|Events]]</span>'''<hr /><br />
<!-- List of upcoming events (remove events after they have taken place). --><br />
<small><br />
'''2016/??''' Hackathon Paris<br />
<br />
'''2016/01''' Fosdem<br />
<br />
'''2015/10''' [https://blogs.coreboot.org/blog/2015/08/04/coreboot-conference-in-europe-october-2015/ coreboot conference europe in Bonn]<br />
<!-- * Currently none --><br />
<!--* '''2015/mon/day:''' coreboot event at [[Link]] in somecity --><br />
</small><br />
<br />
<br />
<br clear=all /><br />
{{#widget:Ohloh Project|id=coreboot|type=partner_badge}}<br />
{{#widget:Ohloh Project|id=coreboot|type=cocomo}}<br />
<br />
<br />
</td></tr></table><br />
<br />
__NOTOC__<br />
__NOEDITSECTION__</div>Stepanhttps://www.coreboot.org/index.php?title=Welcome_to_coreboot&diff=17424Welcome to coreboot2015-11-22T19:20:31Z<p>Stepan: </p>
<hr />
<div><table width="100%" valign="top"><tr valign="top"><td width="80%"><br />
<br />
<div style="margin-top:0.5em; margin-bottom:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;"><br />
'''coreboot''' is an Open Source project aimed at replacing the proprietary [http://wikipedia.org/wiki/BIOS BIOS] (firmware) found in most computers. coreboot performs a little bit of hardware initialization and then executes additional boot logic, called a [[Payloads|payload]].<br />
<br />
With the separation of hardware initialization and later boot logic, coreboot can scale from specialized applications that run directly from firmware, run operating systems in flash, load custom bootloaders, or implement firmware standards, like [[SeaBIOS | PC BIOS services]] or [[TianoCore | UEFI]]. This allows for systems to only include the features necessary in the target application, reducing the amount of code and flash space required.<br />
<br />
coreboot currently supports over '''[[Supported Motherboards|230]]''' different mainboards. Check the [[Support]] page to see if your system is supported.<br />
<br />
<small><br />
coreboot was formerly known as [http://www.coreboot.org/pipermail/coreboot/2008-January/029135.html LinuxBIOS]. <br />
</small><br />
</div><br />
<br />
<div style="margin-top:0.5em; margin-bottom:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;"><br />
coreboot uses [[git]] for source control and [http://review.coreboot.org gerrit] as the patch review tool.<br />
</div><br />
<br />
{| cellspacing=0 cellpadding=8 border=0 margin=0 padding=0 align="top" width=100%<br />
|-<br />
|style="vertical-align:top"|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = yellow|<br />
WIDTH = 100%|<br />
ICON = <small>[[Benefits|More...]]</small>|<br />
HEADING = <span style="font-variant:small-caps; font-size:120%">[[Benefits]]</span>|<br />
CONTENT =<br />
<small><br />
* 100% Free Software (GPL), no royalties, no license fees!<br />
* Fast boot times (500 milliseconds to verified Linux kernel)<br />
<!-- * Avoids the need for a slow/buggy/proprietary BIOS --><br />
<!-- * Runs in 32-Bit protected mode almost from the start --><br />
<!-- * Written in C, contains virtually no assembly code --><br />
* Supports many [[Supported Motherboards|mainboards]], [[Supported Chipsets and Devices|chipsets]], and [[payloads]]<br />
<!-- * Further features: netboot, serial console, remote flashing, ... --><br />
</small><br />
}}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = #d1adf6|<br />
WIDTH = 100%|<br />
ICON = <small>[[Use Cases|More...]]</small>|<br />
HEADING = <span style="font-variant:small-caps; font-size:120%">[[Use Cases]]</span>|<br />
CONTENT =<br />
<small><br />
* Desktop PCs, servers, [[Laptop|laptops]]<br />
* [[Clusters]]<br />
<!-- * Set-Top-Boxes, thin clients --><br />
* Embedded solutions<br />
<!-- * [http://en.wikipedia.org/wiki/Small_form_factor Small form factor computers], [http://en.wikipedia.org/wiki/Home_theater_PC Home-theater PCs] --><br />
<!-- * No-moving-parts solutions (ROM chip as "disk") --><br />
<!-- * Non-standard scenarios (e.g. FPGA in Opteron socket) --><br />
</small><br />
}}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = lime|<br />
WIDTH = 100%|<br />
ICON = <small>[[Payloads|More...]]</small>|<br />
HEADING = <span style="font-variant:small-caps; font-size:120%">[[Payloads]]</span>|<br />
CONTENT =<br />
<small><br />
* [[SeaBIOS]] / [[FILO]] / [[GRUB2]] / [[Payloads|...]] <!-- / [[OpenFirmware]] / [[OpenBIOS]] --><br />
* [[Linux]] / [[Windows]] / [[FreeBSD]] / [[NetBSD]] / [[Payloads|...]] <!-- / [http://openbsd.org/ OpenBSD]--><br />
* [[Etherboot]] / [[GPXE]] / [[iPXE]] / [[Payloads|...]]<br />
<!--* [[Memtest86]]<br />
* [[Bayou]] / [[Coreinfo]] / [[Tint]] / [[Libpayload]]--><br />
</small><br />
}}<br />
<br />
|}<br />
<br />
{| cellspacing=5 cellpadding=15 border=0 valign="top" width=100%<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_cb.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">About</span>'''<br /><small>Find out more about coreboot.</small><small><hr />[[Press]] | [[Logo]] | [[History]] | [[Screenshots|Screenshots/Videos]] | [[Contributors]] | [[Sponsors]] | [[Products]] | [[Vendors]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_devel.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">Developers</span>'''<br /><small>Get involved! Help us make coreboot better.</small><small><hr />[[Development Guidelines]] | [[Developer Manual]] | [http://qa.coreboot.org/docs/doxygen.php Doxygen] | [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree Browse Source] | [[GSoC]] | [[Where to start]] | [[Distributed and Automated Testsystem|Testsystem]]</small><br />
|}<br />
<br />
|-<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_status.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">Status</span>'''<br /><small>Find out whether your hardware is already supported.</small><small><hr />[[Supported Motherboards|Supported Boards]] | [[Supported Chipsets and Devices|Supported Chipsets]] | [[:Category:Tutorials|Board Status Pages]] | [[Blob Matrix|Blob Matrix]] | [http://qa.coreboot.org Build Status]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_tools.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">Related Tools</span>'''<br /><small>Tools and libraries related to coreboot.</small><small><hr />[http://www.flashrom.org flashrom] | [[Superiotool]] | [[Nvramtool]] | [[Buildrom]] | [[Mkelfimage]] | [[Inteltool]] | [[Msrtool]] | [[Ectool]] | [[Developer_Manual/Tools|Hardware tools]] | [[Abuild]] | [http://serialice.com SerialICE]</small><br />
|}<br />
<br />
|-<br />
| width=50% style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_101.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">Getting Started</span>'''<br /><small>Download coreboot and get started.</small><small><hr />[[Build HOWTO]] | [[Download coreboot|Downloads]] | [[Documentation]] | [[QEMU]] | [[AMD SimNow]] | [[Build from Windows]]</small><br />
|}<br />
<br />
|style="vertical-align:top"|<br />
<br />
{|<br />
|style="vertical-align:top"|<br />
[[Image:chip_support.png]]<br />
|style="vertical-align:top"|<br />
'''<span style="font-variant:small-caps; font-size:150%">Support</span>'''<br /><small>Learn how to contact us and find help and support.</small><small><hr />[[FAQ]] | [[Mailinglist]] | [[IRC]] | [[Glossary]] | [[coreboot Options|coreboot Options]]</small><br />
|}<br />
<br />
|}<br />
</td><td width="20%"><br />
<br />
[[File:Coreboot menuconfig.png|center|thumb|[[Build HOWTO|make menuconfig]] in coreboot]]<br />
<br />
<br clear=all /><br />
<br />
'''<span style="font-variant:small-caps; font-size:120%">[http://blogs.coreboot.org News (blog)]</span>'''<hr /><br />
<small><br />
<rss max=5>http://blogs.coreboot.org/feed/</rss><br />
</small><br />
<br />
<br />
'''<span style="font-variant:small-caps; font-size:120%">[[Current events|Events]]</span>'''<hr /><br />
<!-- List of upcoming events (remove events after they have taken place). --><br />
<small><br />
'''2016/??''' Hackathon Paris<br />
'''2016/01''' Fosdem<br />
'''2015/10''' [https://blogs.coreboot.org/blog/2015/08/04/coreboot-conference-in-europe-october-2015/ coreboot conference europe in Bonn]<br />
<!-- * Currently none --><br />
<!--* '''2015/mon/day:''' coreboot event at [[Link]] in somecity --><br />
</small><br />
<br />
<br />
<br clear=all /><br />
{{#widget:Ohloh Project|id=coreboot|type=partner_badge}}<br />
{{#widget:Ohloh Project|id=coreboot|type=cocomo}}<br />
<br />
<br />
</td></tr></table><br />
<br />
__NOTOC__<br />
__NOEDITSECTION__</div>Stepanhttps://www.coreboot.org/index.php?title=EM100pro&diff=16863EM100pro2015-09-10T17:13:41Z<p>Stepan: Created page with "= Linux Utility = We are working on a Linux utility to drive the EM100Pro. Get the sources with $ git clone http://review.coreboot.org/em100 Browse the source code here: ht..."</p>
<hr />
<div>= Linux Utility =<br />
<br />
We are working on a Linux utility to drive the EM100Pro. Get the sources with<br />
$ git clone http://review.coreboot.org/em100<br />
<br />
Browse the source code here: http://review.coreboot.org/gitweb?p=em100.git;a=summary<br />
<br />
Here's how to use the utility:<br />
<br />
em100: EM100pro command line utility<br />
<br />
Example:<br />
./em100 --stop --set M25P80 -d file.bin -v --start<br />
<br />
Usage:<br />
-c|--set CHIP: select chip emulation<br />
-d|--download FILE: upload FILE into EM100pro<br />
-r|--start: em100 shall run<br />
-s|--stop: em100 shall stop<br />
-v|--verify: verify EM100 content matches the file<br />
-t|--trace: trace mode<br />
-F|--firmware-update FILE: update firmware in EM100pro (dangerous)<br />
-f|--firmware-dump FILE: export firmware in EM100pro to file<br />
-S|--set-serialno NUM: set serial number to NUM<br />
-p|--holdpin [LOW|FLOAT|INPUT]: set the hold pin state<br />
-x|--device BUS:DEV use EM100pro on USB bus/device<br />
-l|--list-devices list all connected EM100pro devices<br />
-D|--debug: print debug information.<br />
-h|--help: this help text<br />
<br />
<br />
= USB Tracing =<br />
<br />
When using VMware player to run the Windows utilities, the EM100pro will get confused by Windows trying to set the device up after Linux already did. To avoid that, add the following line to your .vmx file:<br />
<br />
usb.quirks.device0 = "0x04b4:0x1235 skip-reset, skip-refresh, skip-setconfig"</div>Stepanhttps://www.coreboot.org/index.php?title=Coreboot_Options&diff=16316Coreboot Options2015-05-05T23:24:26Z<p>Stepan: </p>
<hr />
<div>This is an automatically generated list of '''coreboot compile-time options'''.<br />
<br />
Last update: 2015/05/05 16:17:26. (r4.0-9599-g40c26df-dirty)<br />
{| border="0" style="font-size: smaller"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Option<br />
! align="left" | Source<br />
! align="left" | Format<br />
! align="left" | Short&nbsp;Description<br />
! align="left" | Description<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: General setup || || || ||<br />
|- bgcolor="#eeeeee"<br />
| EXPERT || toplevel || bool || Expert mode || <br />
This allows you to select certain advanced configuration options.<br />
<br />
Warning: Only enable this option if you really know what you are<br />
doing! You have been warned!<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| LOCALVERSION || toplevel || string || Local version string || <br />
Append an extra string to the end of the coreboot version.<br />
<br />
This can be useful if, for instance, you want to append the<br />
respective board's hostname or some other identifying string to<br />
the coreboot version number, so that you can easily distinguish<br />
boot logs of different boards from each other.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CBFS_PREFIX || toplevel || string || CBFS prefix to use || <br />
Select the prefix to all files put into the image. It's "fallback"<br />
by default, "normal" is a common alternative.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COMMON_CBFS_SPI_WRAPPER || toplevel || bool || || <br />
Use common wrapper to interface CBFS to SPI bootrom.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MULTIPLE_CBFS_INSTANCES || toplevel || bool || Multiple CBFS instances in the bootrom || <br />
Account for the firmware image containing more than one CBFS<br />
instance. Locations of instances are known at build time and are<br />
communicated between coreboot stages to make sure the next stage is<br />
loaded from the appropriate instance.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MULTIPLE_CBFS_INSTANCES || toplevel || bool || Compiler to use || <br />
This option allows you to select the compiler used for building<br />
coreboot.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COMPILER_GCC || toplevel || bool || GCC || <br />
Use the GNU Compiler Collection (GCC) to build coreboot.<br />
<br />
For details see http://gcc.gnu.org.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COMPILER_LLVM_CLANG || toplevel || bool || LLVM/clang || <br />
Use LLVM/clang to build coreboot.<br />
<br />
For details see http://clang.llvm.org.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ANY_TOOLCHAIN || toplevel || bool || Allow building with any toolchain || <br />
Many toolchains break when building coreboot since it uses quite<br />
unusual linker features. Unless developers explicitely request it,<br />
we'll have to assume that they use their distro compiler by mistake.<br />
Make sure that using patched compilers is a conscious decision.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CCACHE || toplevel || bool || Use ccache to speed up (re)compilation || <br />
Enables the use of ccache for faster builds.<br />
<br />
Requires the ccache utility in your system $PATH.<br />
<br />
For details see https://ccache.samba.org.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SCONFIG_GENPARSER || toplevel || bool || Generate SCONFIG parser using flex and bison || <br />
Enable this option if you are working on the sconfig device tree<br />
parser and made changes to sconfig.l and sconfig.y.<br />
<br />
Otherwise, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| USE_OPTION_TABLE || toplevel || bool || Use CMOS for configuration values || <br />
Enable this option if coreboot shall read options from the "CMOS"<br />
NVRAM instead of using hard-coded values.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| STATIC_OPTION_TABLE || toplevel || bool || Load default configuration values into CMOS on each boot || <br />
Enable this option to reset "CMOS" NVRAM values to default on<br />
every boot. Use this if you want the NVRAM configuration to<br />
never be modified from its default values.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COMPRESS_RAMSTAGE || toplevel || bool || Compress ramstage with LZMA || <br />
Compress ramstage to save memory in the flash image. Note<br />
that decompression might slow down booting if the boot flash<br />
is connected through a slow link (i.e. SPI).<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| INCLUDE_CONFIG_FILE || toplevel || bool || Include the coreboot .config file into the ROM image || <br />
Include the .config file that was used to compile coreboot<br />
in the (CBFS) ROM image. This is useful if you want to know which<br />
options were used to build a specific coreboot.rom image.<br />
<br />
Saying Y here will increase the image size by 2-3KB.<br />
<br />
You can use the following command to easily list the options:<br />
<br />
grep -a CONFIG_ coreboot.rom<br />
<br />
Alternatively, you can also use cbfstool to print the image<br />
contents (including the raw 'config' item we're looking for).<br />
<br />
Example:<br />
<br />
$ cbfstool coreboot.rom print<br />
coreboot.rom: 4096 kB, bootblocksize 1008, romsize 4194304,<br />
offset 0x0<br />
Alignment: 64 bytes<br />
<br />
Name Offset Type Size<br />
cmos_layout.bin 0x0 cmos layout 1159<br />
fallback/romstage 0x4c0 stage 339756<br />
fallback/ramstage 0x53440 stage 186664<br />
fallback/payload 0x80dc0 payload 51526<br />
config 0x8d740 raw 3324<br />
(empty) 0x8e480 null 3610440<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COLLECT_TIMESTAMPS || toplevel || bool || Create a table of timestamps collected during boot || <br />
Make coreboot create a table of timer-ID/timer-value pairs to<br />
allow measuring time spent at different phases of the boot process.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| USE_BLOBS || toplevel || bool || Allow use of binary-only repository || <br />
This draws in the blobs repository, which contains binary files that<br />
might be required for some chipsets or boards.<br />
This flag ensures that a "Free" option remains available for users.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COVERAGE || toplevel || bool || Code coverage support || <br />
Add code coverage support for coreboot. This will store code<br />
coverage information in CBMEM for extraction from user space.<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| RELOCATABLE_MODULES || toplevel || bool || Relocatable Modules || <br />
If RELOCATABLE_MODULES is selected then support is enabled for<br />
building relocatable modules in the RAM stage. Those modules can be<br />
loaded anywhere and all the relocations are handled automatically.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| RELOCATABLE_RAMSTAGE || toplevel || bool || Build the ramstage to be relocatable in 32-bit address space. || <br />
The reloctable ramstage support allows for the ramstage to be built<br />
as a relocatable module. The stage loader can identify a place<br />
out of the OS way so that copying memory is unnecessary during an S3<br />
wake. When selecting this option the romstage is responsible for<br />
determing a stack location to use for loading the ramstage.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM || toplevel || bool || Cache the relocated ramstage outside of cbmem. || <br />
The relocated ramstage is saved in an area specified by the<br />
by the board and/or chipset.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SKIP_MAX_REBOOT_CNT_CLEAR || toplevel || bool || Do not clear reboot count after successful boot || <br />
Do not clear the reboot count immediately after successful boot.<br />
Set to allow the payload to control normal/fallback image recovery.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| UPDATE_IMAGE || toplevel || bool || Update existing coreboot.rom image || <br />
If this option is enabled, no new coreboot.rom file<br />
is created. Instead it is expected that there already<br />
is a suitable file for further processing.<br />
The bootblock will not be modified.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| GENERIC_GPIO_LIB || toplevel || bool || || <br />
If enabled, compile the generic GPIO library. A "generic" GPIO<br />
implies configurability usually found on SoCs, particularly the<br />
ability to control internal pull resistors.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOARD_ID_AUTO || toplevel || bool || || <br />
Mainboards that can read a board ID from the hardware straps<br />
(ie. GPIO) select this configuration option.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOARD_ID_MANUAL || toplevel || bool || Add board ID file to CBFS || <br />
If you want to maintain a board ID, but the hardware does not<br />
have straps to automatically determine the ID, you can say Y<br />
here and add a file named 'board_id' to CBFS. If you don't know<br />
what this is about, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOARD_ID_STRING || toplevel || string || Board ID || <br />
This string is placed in the 'board_id' CBFS file for indicating<br />
board type.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| RAM_CODE_SUPPORT || toplevel || bool || Discover RAM configuration code and store it in coreboot table || <br />
If enabled, coreboot discovers RAM configuration (value obtained by<br />
reading board straps) and stores it in coreboot table.<br />
<br />
||<br />
<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: Mainboard || || || ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || see under vendor LiPPERT ||<br />
|- bgcolor="#eeeeee"<br />
| BOARD_ASUS_F2A85_M_DDR3_VOLT_135 || mainboard/asus/f2a85-m || bool || 1.35V || <br />
Set DRR3 memory voltage to 1.35V<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOARD_ASUS_F2A85_M_DDR3_VOLT_150 || mainboard/asus/f2a85-m || bool || 1.50V || <br />
Set DRR3 memory voltage to 1.50V<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOARD_ASUS_F2A85_M_DDR3_VOLT_165 || mainboard/asus/f2a85-m || bool || 1.65V || <br />
Set DRR3 memory voltage to 1.65V<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOARD_ASUS_F2A85_M_LE_DDR3_VOLT_135 || mainboard/asus/f2a85-m_le || bool || 1.35V || <br />
Set DRR3 memory voltage to 1.35V<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOARD_ASUS_F2A85_M_LE_DDR3_VOLT_150 || mainboard/asus/f2a85-m_le || bool || 1.50V || <br />
Set DRR3 memory voltage to 1.50V<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOARD_ASUS_F2A85_M_LE_DDR3_VOLT_165 || mainboard/asus/f2a85-m_le || bool || 1.65V || <br />
Set DRR3 memory voltage to 1.65V<br />
||<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: On-Chip Device Power Down Control || || || ||<br />
<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: Watchdog Timer setting || || || ||<br />
<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: IDE controller setting || || || ||<br />
|- bgcolor="#eeeeee"<br />
| IDE_STANDARD_COMPATIBLE || mainboard/dmp/vortex86ex || bool || Standard IDE Compatible || <br />
Built-in IDE controller PCI vendor/device ID is 17F3:1012, which<br />
is not recognized by some OSes.<br />
<br />
This option can change IDE controller PCI vendor/device ID to<br />
other value for software compatibility.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| IDE_COMPATIBLE_SELECTION || mainboard/dmp/vortex86ex || hex || IDE Compatible Selection || <br />
IDE controller PCI vendor/device ID value setting.<br />
<br />
Higher 16-bit is vendor ID, lower 16-bit is device ID.<br />
<br />
||<br />
<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: GPIO setting || || || ||<br />
<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: UART setting || || || ||<br />
<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: LPT setting || || || ||<br />
<br />
|- bgcolor="#eeeeee"<br />
| UART_FOR_CONSOLE || mainboard/intel/mohonpeak || int || || <br />
The Mohon Peak board uses COM2 (2f8) for the serial console.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SEABIOS_MALLOC_UPPERMEMORY || mainboard/intel/mohonpeak || bool || || <br />
The Avoton/Rangeley chip does not allow devices to write into the 0xe000<br />
segment. This means that USB/SATA devices will not work in SeaBIOS unless<br />
we put the SeaBIOS buffer area down in the 0x9000 segment.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MAINBOARD_PART_NUMBER || mainboard/google/nyan_blaze || string || BCT boot media || <br />
Which boot media to configure the BCT for.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| NYAN_BLAZE_BCT_CFG_SPI || mainboard/google/nyan_blaze || bool || SPI || <br />
Configure the BCT for booting from SPI.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| NYAN_BLAZE_BCT_CFG_EMMC || mainboard/google/nyan_blaze || bool || eMMC || <br />
Configure the BCT for booting from eMMC.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOOT_MEDIA_SPI_BUS || mainboard/google/nyan_blaze || int || SPI bus with boot media ROM || <br />
Which SPI bus the boot media is connected to.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOOT_MEDIA_SPI_CHIP_SELECT || mainboard/google/nyan_blaze || int || Chip select for SPI boot media || <br />
Which chip select to use for boot media.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MAINBOARD_PART_NUMBER || mainboard/google/nyan || string || BCT boot media || <br />
Which boot media to configure the BCT for.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| NYAN_BCT_CFG_SPI || mainboard/google/nyan || bool || SPI || <br />
Configure the BCT for booting from SPI.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| NYAN_BCT_CFG_EMMC || mainboard/google/nyan || bool || eMMC || <br />
Configure the BCT for booting from eMMC.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOOT_MEDIA_SPI_BUS || mainboard/google/nyan || int || SPI bus with boot media ROM || <br />
Which SPI bus the boot media is connected to.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOOT_MEDIA_SPI_CHIP_SELECT || mainboard/google/nyan || int || Chip select for SPI boot media || <br />
Which chip select to use for boot media.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MAINBOARD_PART_NUMBER || mainboard/google/rush_ryu || string || BCT boot media || <br />
Which boot media to configure the BCT for.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| RUSH_RYU_BCT_CFG_SPI || mainboard/google/rush_ryu || bool || SPI || <br />
Configure the BCT for booting from SPI.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| RUSH_RYU_BCT_CFG_EMMC || mainboard/google/rush_ryu || bool || eMMC || <br />
Configure the BCT for booting from eMMC.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOOT_MEDIA_SPI_BUS || mainboard/google/rush_ryu || int || SPI bus with boot media ROM || <br />
Which SPI bus the boot media is connected to.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOOT_MEDIA_SPI_CHIP_SELECT || mainboard/google/rush_ryu || int || Chip select for SPI boot media || <br />
Which chip select to use for boot media.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MAINBOARD_PART_NUMBER || mainboard/google/nyan_big || string || BCT boot media || <br />
Which boot media to configure the BCT for.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| NYAN_BIG_BCT_CFG_SPI || mainboard/google/nyan_big || bool || SPI || <br />
Configure the BCT for booting from SPI.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| NYAN_BIG_BCT_CFG_EMMC || mainboard/google/nyan_big || bool || eMMC || <br />
Configure the BCT for booting from eMMC.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOOT_MEDIA_SPI_BUS || mainboard/google/nyan_big || int || SPI bus with boot media ROM || <br />
Which SPI bus the boot media is connected to.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOOT_MEDIA_SPI_CHIP_SELECT || mainboard/google/nyan_big || int || Chip select for SPI boot media || <br />
Which chip select to use for boot media.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DRAM_SIZE_MB || mainboard/google/rush || int || BCT boot media || <br />
Which boot media to configure the BCT for.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| RUSH_BCT_CFG_SPI || mainboard/google/rush || bool || SPI || <br />
Configure the BCT for booting from SPI.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| RUSH_BCT_CFG_EMMC || mainboard/google/rush || bool || eMMC || <br />
Configure the BCT for booting from eMMC.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOOT_MEDIA_SPI_BUS || mainboard/google/rush || int || SPI bus with boot media ROM || <br />
Which SPI bus the boot media is connected to.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOOT_MEDIA_SPI_CHIP_SELECT || mainboard/google/rush || int || Chip select for SPI boot media || <br />
Which chip select to use for boot media.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ENABLE_DP3_DAUGHTER_CARD_IN_J120 || mainboard/amd/lamar || bool || Use J120 as an additional graphics port || <br />
The PCI Express slot at J120 can be configured as an additional<br />
DisplayPort connector using an adapter card from AMD or as a normal<br />
PCI Express (x4) slot.<br />
<br />
By default, the connector is configured as a PCI Express (x4) slot.<br />
<br />
Select this option to enable the slot for use with one of AMD's<br />
passive graphics port expander cards (only available from AMD).<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || was acquired by ADLINK ||<br />
|- bgcolor="#eeeeee"<br />
| ONBOARD_UARTS_RS485 || mainboard/lippert/literunner-lx || bool || Switch on-board serial ports 1 &amp; 2 to RS485 || <br />
If selected, the first two on-board serial ports will operate in RS485<br />
mode instead of RS232.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ONBOARD_IDE_SLAVE || mainboard/lippert/literunner-lx || bool || Make on-board CF socket act as Slave || <br />
If selected, the on-board Compact Flash card socket will act as IDE<br />
Slave instead of Master.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOARD_OLD_REVISION || mainboard/lippert/hurricane-lx || bool || Board is old pre-3.0 revision || <br />
Look on the bottom side for a number like 406-0001-30. The last 2<br />
digits state the PCB revision (3.0 in this example). For 2.0 or older<br />
boards choose Y, for 3.0 and newer say N.<br />
<br />
Old revision boards need a jumper shorting the power button to<br />
power on automatically. You may enable the button only after this<br />
jumper has been removed. New revision boards are not restricted<br />
in this way, and always have the power button enabled.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ONBOARD_UARTS_RS485 || mainboard/lippert/hurricane-lx || bool || Switch on-board serial ports to RS485 || <br />
If selected, both on-board serial ports will operate in RS485 mode<br />
instead of RS232.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ONBOARD_UARTS_RS485 || mainboard/lippert/spacerunner-lx || bool || Switch on-board serial ports to RS485 || <br />
If selected, both on-board serial ports will operate in RS485 mode<br />
instead of RS232.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ONBOARD_IDE_SLAVE || mainboard/lippert/spacerunner-lx || bool || Make on-board SSD act as Slave || <br />
If selected, the on-board SSD will act as IDE Slave instead of Master.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ONBOARD_UARTS_RS485 || mainboard/lippert/roadrunner-lx || bool || Switch on-board serial ports to RS485 || <br />
If selected, both on-board serial ports will operate in RS485 mode<br />
instead of RS232.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOARD_ROMSIZE_KB_16384 || mainboard || bool || ROM chip size || <br />
Select the size of the ROM chip you intend to flash coreboot on.<br />
<br />
The build system will take care of creating a coreboot.rom file<br />
of the matching size.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COREBOOT_ROMSIZE_KB_64 || mainboard || bool || 64 KB || <br />
Choose this option if you have a 64 KB ROM chip.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COREBOOT_ROMSIZE_KB_128 || mainboard || bool || 128 KB || <br />
Choose this option if you have a 128 KB ROM chip.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COREBOOT_ROMSIZE_KB_256 || mainboard || bool || 256 KB || <br />
Choose this option if you have a 256 KB ROM chip.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COREBOOT_ROMSIZE_KB_512 || mainboard || bool || 512 KB || <br />
Choose this option if you have a 512 KB ROM chip.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COREBOOT_ROMSIZE_KB_1024 || mainboard || bool || 1024 KB (1 MB) || <br />
Choose this option if you have a 1024 KB (1 MB) ROM chip.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COREBOOT_ROMSIZE_KB_2048 || mainboard || bool || 2048 KB (2 MB) || <br />
Choose this option if you have a 2048 KB (2 MB) ROM chip.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COREBOOT_ROMSIZE_KB_4096 || mainboard || bool || 4096 KB (4 MB) || <br />
Choose this option if you have a 4096 KB (4 MB) ROM chip.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COREBOOT_ROMSIZE_KB_8192 || mainboard || bool || 8192 KB (8 MB) || <br />
Choose this option if you have a 8192 KB (8 MB) ROM chip.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COREBOOT_ROMSIZE_KB_12288 || mainboard || bool || 12288 KB (12 MB) || <br />
Choose this option if you have a 12288 KB (12 MB) ROM chip.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COREBOOT_ROMSIZE_KB_16384 || mainboard || bool || 16384 KB (16 MB) || <br />
Choose this option if you have a 16384 KB (16 MB) ROM chip.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ENABLE_POWER_BUTTON || mainboard || bool || Enable the power button || <br />
The selected mainboard can optionally have the power button tied<br />
to ground with a jumper so that the button appears to be<br />
constantly depressed. If this option is enabled and the jumper is<br />
installed then the board will turn on, but turn off again after a<br />
short timeout, usually 4 seconds.<br />
<br />
Select Y here if you have removed the jumper and want to use an<br />
actual power button. Select N if you have the jumper installed.<br />
<br />
||<br />
<br />
|- bgcolor="#eeeeee"<br />
| LATE_CBMEM_INIT || arch/x86 || bool || || <br />
Enable this in chipset's Kconfig if northbridge does not implement<br />
early get_top_of_ram() call for romstage. CBMEM tables will be<br />
allocated late in ramstage, after PCI devices resources are known.<br />
<br />
||<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: ChromeOS || || || ||<br />
|- bgcolor="#eeeeee"<br />
| CHROMEOS || vendorcode/google/chromeos || bool || Build for ChromeOS || <br />
Enable ChromeOS specific features like the GPIO sub table in<br />
the coreboot table. NOTE: Enabling this option on an unsupported<br />
board will most likely break your build.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VBNV_OFFSET || vendorcode/google/chromeos || hex || || <br />
CMOS offset for VbNv data. This value must match cmos.layout<br />
in the mainboard directory, minus 14 bytes for the RTC.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VBNV_SIZE || vendorcode/google/chromeos || hex || || <br />
CMOS storage size for VbNv data. This value must match cmos.layout<br />
in the mainboard directory.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CHROMEOS_VBNV_CMOS || vendorcode/google/chromeos || bool || Vboot non-volatile storage in CMOS. || <br />
VBNV is stored in CMOS<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CHROMEOS_VBNV_EC || vendorcode/google/chromeos || bool || Vboot non-volatile storage in EC. || <br />
VBNV is stored in EC<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CHROMEOS_VBNV_FLASH || vendorcode/google/chromeos || bool || || <br />
VBNV is stored in flash storage<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FLASHMAP_OFFSET || vendorcode/google/chromeos || hex || Flash Map Offset || <br />
Offset of flash map in firmware image<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EC_SOFTWARE_SYNC || vendorcode/google/chromeos || bool || Enable EC software sync || <br />
EC software sync is a mechanism where the AP helps the EC verify its<br />
firmware similar to how vboot verifies the main system firmware. This<br />
option selects whether depthcharge should support EC software sync.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VBOOT_EC_SLOW_UPDATE || vendorcode/google/chromeos || bool || EC is slow to update || <br />
Whether the EC (or PD) is slow to update and needs to display a<br />
screen that informs the user the update is happening.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VBOOT_OPROM_MATTERS || vendorcode/google/chromeos || bool || Video option ROM matters || <br />
Whether the video option ROM has run matters on this platform.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VIRTUAL_DEV_SWITCH || vendorcode/google/chromeos || bool || Virtual developer switch support || <br />
Whether this platform has a virtual developer switch.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VBOOT_VERIFY_FIRMWARE || vendorcode/google/chromeos || bool || Verify firmware with vboot. || <br />
Enabling VBOOT_VERIFY_FIRMWARE will use vboot to verify the components<br />
of the firmware (stages, payload, etc).<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| NO_TPM_RESUME || vendorcode/google/chromeos || bool || || <br />
On some boards the TPM stays powered up in S3. On those<br />
boards, booting Windows will break if the TPM resume command<br />
is sent during an S3 resume.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PHYSICAL_REC_SWITCH || vendorcode/google/chromeos || bool || Physical recovery switch is present || <br />
Whether this platform has a physical recovery switch<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| WIPEOUT_SUPPORTED || vendorcode/google/chromeos || bool || User is able to request factory reset || <br />
When this option is enabled, the firmware provides the ability to<br />
signal the application the need for factory reset (a.k.a. wipe<br />
out) of the device<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VBOOT_STARTS_IN_BOOTBLOCK || vendorcode/google/chromeos/vboot2 || bool || || <br />
Firmware verification happens during or at the end of bootblock.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VBOOT_STARTS_IN_ROMSTAGE || vendorcode/google/chromeos/vboot2 || bool || || <br />
Firmware verification happens during or at the end of romstage.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VBOOT2_MOCK_SECDATA || vendorcode/google/chromeos/vboot2 || bool || Mock secdata for firmware verification || <br />
Enabling VBOOT2_MOCK_SECDATA will mock secdata for the firmware<br />
verification to avoid access to a secdata storage (typically TPM).<br />
All operations for a secdata storage will be successful. This option<br />
can be used during development when a TPM is not present or broken.<br />
THIS SHOULD NOT BE LEFT ON FOR PRODUCTION DEVICES.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VBOOT_DISABLE_DEV_ON_RECOVERY || vendorcode/google/chromeos/vboot2 || bool || Disable dev mode on recovery requests || <br />
When this option is enabled, the Chrome OS device leaves the<br />
developer mode as soon as recovery request is detected. This is<br />
handy on embedded devices with limited input capabilities.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| RETURN_FROM_VERSTAGE || vendorcode/google/chromeos/vboot2 || bool || || <br />
If this is set, the verstage returns back to the calling stage instead<br />
of exiting to the succeeding stage so that the verstage space can be<br />
reused by the succeeding stage. This is useful if a ram space is too<br />
small to fit both the verstage and the succeeding stage.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VBOOT_ROMSTAGE_INDEX || vendorcode/google/chromeos/vboot2 || hex || Romstage component index || <br />
This is the index of the romstage component in the verified<br />
firmware block.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VBOOT_RAMSTAGE_INDEX || vendorcode/google/chromeos/vboot2 || hex || Ramstage component index || <br />
This is the index of the ramstage component in the verified<br />
firmware block.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VBOOT_REFCODE_INDEX || vendorcode/google/chromeos/vboot2 || hex || Reference code firmware index || <br />
This is the index of the reference code component in the verified<br />
firmware block.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VBOOT_BOOT_LOADER_INDEX || vendorcode/google/chromeos/vboot2 || hex || Bootloader component index || <br />
This is the index of the bootloader component in the verified<br />
firmware block.<br />
<br />
||<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VIRTUAL_DEV_SWITCH || vendorcode/google/chromeos || bool || || <br />
Whether this platform has a virtual developer switch.<br />
||<br />
<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: AMD Platform Initialization || || || ||<br />
|- bgcolor="#eeeeee"<br />
| AGESA_BINARY_PI_PATH_DEFAULT || vendorcode/amd/pi/00630F01 || string || || <br />
The default binary file name to use for AMD platform initialization.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| AGESA_BINARY_PI_FILE_DEFAULT || vendorcode/amd/pi/00630F01 || string || || <br />
The default binary file name to use for AMD platform initialization.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| AGESA_BINARY_PI_LOCATION_DEFAULT || vendorcode/amd/pi/00630F01 || hex || || <br />
The default ROM address at which to store the binary Platform<br />
Initialization code.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| AGESA_BINARY_PI_PATH_DEFAULT || vendorcode/amd/pi/00730F01 || string || || <br />
The default binary file name to use for AMD platform initialization.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| AGESA_BINARY_PI_FILE_DEFAULT || vendorcode/amd/pi/00730F01 || string || || <br />
The default binary file name to use for AMD platform initialization.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| AGESA_BINARY_PI_LOCATION_DEFAULT || vendorcode/amd/pi/00730F01 || hex || || <br />
The default ROM address at which to store the binary Platform<br />
Initialization code.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| None || vendorcode/amd || None || AGESA source || <br />
Select the method for including the AMD Platform Initialization<br />
code into coreboot. Platform Initialization code is required for<br />
all AMD processors.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CPU_AMD_AGESA_BINARY_PI || vendorcode/amd || bool || binary PI || <br />
Use a binary PI package. Generally, these will be stored in the<br />
"3rdparty" directory. For some processors, these must be obtained<br />
directly from AMD Embedded Processors Group<br />
(http://www.amdcom/embedded).<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CPU_AMD_AGESA_OPENSOURCE || vendorcode/amd || bool || open-source AGESA || <br />
Build the PI package ("AGESA") from source code in the "vendorcode"<br />
directory.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| AGESA_BINARY_PI_PATH || vendorcode/amd || string || AGESA PI directory path || <br />
Specify where to find the AGESA headers and binary file<br />
for AMD platform initialization.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| AGESA_BINARY_PI_FILE || vendorcode/amd || string || AGESA PI binary file name || <br />
Specify the binary file to use for AMD platform initialization.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| AGESA_BINARY_PI_LOCATION || vendorcode/amd || string || AGESA PI binary address in ROM || <br />
Specify the ROM address at which to store the binary Platform<br />
Initialization code.<br />
<br />
||<br />
<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: Chipset || || || ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || CPU ||<br />
|- bgcolor="#eeeeee"<br />
| LAPIC_MONOTONIC_TIMER || cpu/x86 || bool || || <br />
Expose monotonic time using the local apic.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| TSC_CONSTANT_RATE || cpu/x86 || bool || || <br />
This option asserts that the TSC ticks at a known constant rate.<br />
Therefore, no TSC calibration is required.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| TSC_MONOTONIC_TIMER || cpu/x86 || bool || || <br />
Expose monotonic time using the TSC.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| TSC_SYNC_LFENCE || cpu/x86 || bool || || <br />
The CPU driver should select this if the CPU needs<br />
to execute an lfence instruction in order to synchronize<br />
rdtsc. This is true for all modern AMD CPUs.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| TSC_SYNC_MFENCE || cpu/x86 || bool || || <br />
The CPU driver should select this if the CPU needs<br />
to execute an mfence instruction in order to synchronize<br />
rdtsc. This is true for all modern Intel CPUs.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SMM_MODULES || cpu/x86 || bool || || <br />
If SMM_MODULES is selected then SMM handlers are built as modules.<br />
A SMM stub along with a SMM loader/relocator. All the handlers are<br />
written in C with stub being the only assembly.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SMM_MODULE_HEAP_SIZE || cpu/x86 || hex || || <br />
This option determines the size of the heap within the SMM handler<br />
modules.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| X86_AMD_FIXED_MTRRS || cpu/x86 || bool || || <br />
This option informs the MTRR code to use the RdMem and WrMem fields<br />
in the fixed MTRR MSRs.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PLATFORM_USES_FSP1_0 || cpu/x86 || bool || || <br />
Selected for Intel processors/platform combinations that use the<br />
Intel Firmware Support Package (FSP) 1.0 for initialization.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PARALLEL_MP || cpu/x86 || bool || || <br />
This option uses common MP infrastructure for bringing up APs<br />
in parallel. It additionally provides a more flexible mechanism<br />
for sequencing the steps of bringing up the APs.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BACKUP_DEFAULT_SMM_REGION || cpu/x86 || bool || || <br />
The CPU support will select this option if the default SMM region<br />
needs to be backed up for suspend/resume purposes.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MIRROR_PAYLOAD_TO_RAM_BEFORE_LOADING || cpu/x86 || bool || || <br />
On certain platforms a boot speed gain can be realized if mirroring<br />
the payload data stored in non-volatile storage. On x86 systems the<br />
payload would typically live in a memory-mapped SPI part. Copying<br />
the SPI contents to RAM before performing the load can speed up<br />
the boot process.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOOT_MEDIA_SPI_BUS || cpu/x86 || int || || <br />
Most x86 systems which boot from SPI flash boot using bus 0.<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| RESET_ON_INVALID_RAMSTAGE_CACHE || cpu/intel/haswell || bool || Reset the system on S3 wake when ramstage cache invalid. || <br />
The haswell romstage code caches the loaded ramstage program<br />
in SMM space. On S3 wake the romstage will copy over a fresh<br />
ramstage that was cached in the SMM space. This option determines<br />
the action to take when the ramstage cache is invalid. If selected<br />
the system will reset otherwise the ramstage will be reloaded from<br />
cbfs.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MONOTONIC_TIMER_MSR || cpu/intel/haswell || bool || || <br />
Provide a monotonic timer using the 24MHz MSR counter.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CPU_INTEL_FIRMWARE_INTERFACE_TABLE || cpu/intel/fit || None || || <br />
This option selects building a Firmware Interface Table (FIT).<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CPU_INTEL_NUM_FIT_ENTRIES || cpu/intel/fit || int || || <br />
This option selects the number of empty entries in the FIT table.<br />
<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED || cpu/intel/turbo || None || || <br />
This option indicates that the turbo mode setting is not package<br />
scoped. i.e. enable_turbo() needs to be called on not just the bsp<br />
<br />
||<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| GEODE_VSA_FILE || cpu/amd/geode_gx2 || bool || Add a VSA image || <br />
Select this option if you have an AMD Geode GX2 vsa that you would<br />
like to add to your ROM.<br />
<br />
You will be able to specify the location and file name of the<br />
image later.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VSA_FILENAME || cpu/amd/geode_gx2 || string || AMD Geode GX2 VSA path and filename || <br />
The path and filename of the file to use as VSA.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| GEODE_VSA_FILE || cpu/amd/geode_lx || bool || Add a VSA image || <br />
Select this option if you have an AMD Geode LX vsa that you would<br />
like to add to your ROM.<br />
<br />
You will be able to specify the location and file name of the<br />
image later.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VSA_FILENAME || cpu/amd/geode_lx || string || AMD Geode LX VSA path and filename || <br />
The path and filename of the file to use as VSA.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| XIP_ROM_SIZE || cpu/amd/agesa || hex || || <br />
Overwride the default write through caching size as 1M Bytes.<br />
On some AMD platforms, one socket supports 2 or more kinds of<br />
processor family, compiling several CPU families agesa code<br />
will increase the romstage size.<br />
In order to execute romstage in place on the flash ROM,<br />
more space is required to be set as write through caching.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| REDIRECT_IDS_HDT_CONSOLE_TO_SERIAL || cpu/amd/agesa/family10 || bool || Redirect AGESA IDS_HDT_CONSOLE to serial console || <br />
This Option allows you to redirect the AMD AGESA IDS_HDT_CONSOLE debug information to the serial console.<br />
<br />
Warning: Only enable this option when debuging or tracing AMD AGESA code.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CPU_AMD_SOCKET_G34 || cpu/amd/agesa/family15 || bool || || <br />
AMD G34 Socket<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CPU_AMD_SOCKET_C32 || cpu/amd/agesa/family15 || bool || || <br />
AMD C32 Socket<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CPU_AMD_SOCKET_AM3R2 || cpu/amd/agesa/family15 || bool || || <br />
AMD AM3r2 Socket<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| REDIRECT_IDS_HDT_CONSOLE_TO_SERIAL || cpu/amd/agesa/family15 || bool || Redirect AGESA IDS_HDT_CONSOLE to serial console || <br />
This Option allows you to redirect the AMD AGESA IDS_HDT_CONSOLE debug information to the serial console.<br />
<br />
Warning: Only enable this option when debuging or tracing AMD AGESA code.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FORCE_AM1_SOCKET_SUPPORT || cpu/amd/agesa/family16kb || bool || || <br />
Force AGESA to ignore package type mismatch between CPU and northbridge<br />
in memory code. This enables Socket AM1 support with current AGESA<br />
version for Kabini platform.<br />
Enable this option only if you have Socket AM1 board.<br />
Note that the AGESA release shipped with coreboot does not officially<br />
support the AM1 socket. Selecting this option might damage your hardware.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| XIP_ROM_SIZE || cpu/amd/pi || hex || || <br />
Overwride the default write through caching size as 1M Bytes.<br />
On some AMD platforms, one socket supports 2 or more kinds of<br />
processor family, compiling several CPU families agesa code<br />
will increase the romstage size.<br />
In order to execute romstage in place on the flash ROM,<br />
more space is required to be set as write through caching.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SMP || cpu || bool || || <br />
This option is used to enable certain functions to make coreboot<br />
work correctly on symmetric multi processor (SMP) systems.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| AP_SIPI_VECTOR || cpu || hex || || <br />
This must equal address of ap_sipi_vector from bootblock build.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MMX || cpu || bool || || <br />
Select MMX in your socket or model Kconfig if your CPU has MMX<br />
streaming SIMD instructions. ROMCC can build more efficient<br />
code if it can spill to MMX registers.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SSE || cpu || bool || || <br />
Select SSE in your socket or model Kconfig if your CPU has SSE<br />
streaming SIMD instructions. ROMCC can build more efficient<br />
code if it can spill to SSE (aka XMM) registers.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SSE2 || cpu || bool || || <br />
Select SSE2 in your socket or model Kconfig if your CPU has SSE2<br />
streaming SIMD instructions. Some parts of coreboot can be built<br />
with more efficient code if SSE2 instructions are available.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CPU_MICROCODE_CBFS_GENERATE || cpu || bool || Generate from tree || <br />
Select this option if you want microcode updates to be assembled when<br />
building coreboot and included in the final image as a separate CBFS<br />
file. Microcode will not be hard-coded into ramstage.<br />
<br />
The microcode file may be removed from the ROM image at a later<br />
time with cbfstool, if desired.<br />
<br />
If unsure, select this option.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CPU_MICROCODE_CBFS_EXTERNAL || cpu || bool || Include external microcode file || <br />
Select this option if you want to include an external file containing<br />
the CPU microcode. This will be included as a separate file in CBFS.<br />
A word of caution: only select this option if you are sure the<br />
microcode that you have is newer than the microcode shipping with<br />
coreboot.<br />
<br />
The microcode file may be removed from the ROM image at a later<br />
time with cbfstool, if desired.<br />
<br />
If unsure, select "Generate from tree"<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CPU_MICROCODE_CBFS_NONE || cpu || bool || Do not include microcode updates || <br />
Select this option if you do not want CPU microcode included in CBFS.<br />
Note that for some CPUs, the microcode is hard-coded into the source<br />
tree and is not loaded from CBFS. In this case, microcode will still<br />
be updated. There is a push to move all microcode to CBFS, but this<br />
change is not implemented for all CPUs.<br />
<br />
This option currently applies to:<br />
- Intel SandyBridge/IvyBridge<br />
- VIA Nano<br />
<br />
Microcode may be added to the ROM image at a later time with cbfstool,<br />
if desired.<br />
<br />
If unsure, select "Generate from tree"<br />
<br />
The GOOD:<br />
Microcode updates intend to solve issues that have been discovered<br />
after CPU production. The expected effect is that systems work as<br />
intended with the updated microcode, but we have also seen cases where<br />
issues were solved by not applying microcode updates.<br />
<br />
The BAD:<br />
Note that some operating system include these same microcode patches,<br />
so you may need to also disable microcode updates in your operating<br />
system for this option to have an effect.<br />
<br />
The UGLY:<br />
A word of CAUTION: some CPUs depend on microcode updates to function<br />
correctly. Not updating the microcode may leave the CPU operating at<br />
less than optimal performance, or may cause outright hangups.<br />
There are CPUs where coreboot cannot properly initialize the CPU<br />
without microcode updates<br />
For example, if running with the factory microcode, some Intel<br />
SandyBridge CPUs may hang when enabling CAR, or some VIA Nano CPUs<br />
will hang when changing the frequency.<br />
<br />
Make sure you have a way of flashing the ROM externally before<br />
selecting this option.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CPU_MICROCODE_FILE || cpu || string || Path and filename of CPU microcode || <br />
The path and filename of the file containing the CPU microcode.<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || Northbridge ||<br />
|- bgcolor="#eeeeee"<br />
| VGA_BIOS_ID || northbridge/intel/fsp_sandybridge || string || || <br />
This is the default PCI ID for the sandybridge/ivybridge graphics<br />
devices. This string names the vbios ROM in cbfs. The following<br />
PCI IDs will be remapped to load this ROM:<br />
0x80860102, 0x8086010a, 0x80860112, 0x80860116<br />
0x80860122, 0x80860126, 0x80860166<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CBFS_SIZE || northbridge/intel/fsp_sandybridge || hex || Size of CBFS filesystem in ROM || <br />
On Sandybridge and Ivybridge systems the firmware image may<br />
have to store a lot more than just coreboot, including:<br />
- a firmware descriptor<br />
- Intel Management Engine firmware<br />
This option specifies the maximum size of the CBFS portion in the<br />
firmware image.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FSP_FILE || northbridge/intel/fsp_sandybridge/fsp || string || || <br />
The path and filename of the Intel FSP binary for this platform.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FSP_LOC || northbridge/intel/fsp_sandybridge/fsp || hex || Intel FSP Binary location in CBFS || <br />
The location in CBFS that the FSP is located. This must match the<br />
value that is set in the FSP binary. If the FSP needs to be moved,<br />
rebase the FSP with the Intel's BCT (tool).<br />
<br />
The Ivy Bridge Processor/Panther Point FSP is built with a preferred<br />
base address of 0xFFF80000<br />
<br />
||<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CBFS_SIZE || northbridge/intel/nehalem || hex || Size of CBFS filesystem in ROM || <br />
On Nehalem systems the firmware image has to<br />
store a lot more than just coreboot, including:<br />
- a firmware descriptor<br />
- Intel Management Engine firmware<br />
This option allows to limit the size of the CBFS portion in the<br />
firmware image.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CBFS_SIZE || northbridge/intel/gm45 || hex || Size of CBFS filesystem in ROM || <br />
On GM45 systems the firmware image may<br />
store a lot more than just coreboot, including:<br />
- a firmware descriptor<br />
- Intel Management Engine firmware<br />
This option allows to limit the size of the CBFS portion in the<br />
firmware image.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SDRAMPWR_4DIMM || northbridge/intel/i440bx || bool || || <br />
This option affects how the SDRAMC register is programmed.<br />
Memory clock signals will not be routed properly if this option<br />
is set wrong.<br />
<br />
If your board has 4 DIMM slots, you must use select this option, in<br />
your Kconfig file of the board. On boards with 3 DIMM slots,<br />
do _not_ select this option.<br />
<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DCACHE_RAM_SIZE || northbridge/intel/haswell || hex || || <br />
The size of the cache-as-ram region required during bootblock<br />
and/or romstage. Note DCACHE_RAM_SIZE and DCACHE_RAM_MRC_VAR_SIZE<br />
must add up to a power of 2.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DCACHE_RAM_MRC_VAR_SIZE || northbridge/intel/haswell || hex || || <br />
The amount of cache-as-ram region required by the reference code.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DCACHE_RAM_ROMSTAGE_STACK_SIZE || northbridge/intel/haswell || hex || || <br />
The amount of anticipated stack usage from the data cache<br />
during pre-ram rom stage execution.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_MRC || northbridge/intel/haswell || bool || Add a System Agent binary || <br />
Select this option to add a System Agent binary to<br />
the resulting coreboot image.<br />
<br />
Note: Without this binary coreboot will not work<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MRC_FILE || northbridge/intel/haswell || string || Intel System Agent path and filename || <br />
The path and filename of the file to use as System Agent<br />
binary.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CBFS_SIZE || northbridge/intel/haswell || hex || Size of CBFS filesystem in ROM || <br />
On Haswell systems the firmware image has to store a lot more<br />
than just coreboot, including:<br />
- a firmware descriptor<br />
- Intel Management Engine firmware<br />
- MRC cache information<br />
This option allows to limit the size of the CBFS portion in the<br />
firmware image.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PRE_GRAPHICS_DELAY || northbridge/intel/haswell || int || Graphics initialization delay in ms || <br />
On some systems, coreboot boots so fast that connected monitors<br />
(mostly TVs) won't be able to wake up fast enough to talk to the<br />
VBIOS. On those systems we need to wait for a bit before executing<br />
the VBIOS.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_MRC || northbridge/intel/sandybridge || bool || Add a System Agent binary || <br />
Select this option to add a System Agent binary to<br />
the resulting coreboot image.<br />
<br />
Note: Without this binary coreboot will not work<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MRC_FILE || northbridge/intel/sandybridge || string || Intel System Agent path and filename || <br />
The path and filename of the file to use as System Agent<br />
binary.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CBFS_SIZE || northbridge/intel/sandybridge || hex || Size of CBFS filesystem in ROM || <br />
On Sandybridge and Ivybridge systems the firmware image has to<br />
store a lot more than just coreboot, including:<br />
- a firmware descriptor<br />
- Intel Management Engine firmware<br />
- MRC cache information<br />
This option allows to limit the size of the CBFS portion in the<br />
firmware image.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| OVERRIDE_CLOCK_DISABLE || northbridge/intel/i945 || bool || || <br />
Usually system firmware turns off system memory clock<br />
signals to unused SO-DIMM slots to reduce EMI and power<br />
consumption.<br />
However, some boards do not like unused clock signals to<br />
be disabled.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MAXIMUM_SUPPORTED_FREQUENCY || northbridge/intel/i945 || int || || <br />
If non-zero, this designates the maximum DDR frequency<br />
the board supports, despite what the chipset should be<br />
capable of.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CHECK_SLFRCS_ON_RESUME || northbridge/intel/i945 || int || || <br />
On some boards it may be neccessary to hard reset early<br />
during resume from S3 if the SLFRCS register indicates that<br />
a memory channel is not guaranteed to be in self-refresh.<br />
On other boards the check always creates a false positive,<br />
effectively making it impossible to resume.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SET_TSEG_1MB || northbridge/intel/fsp_rangeley || bool || 1 MB || <br />
Set the TSEG area to 1 MB.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SET_TSEG_2MB || northbridge/intel/fsp_rangeley || bool || 2 MB || <br />
Set the TSEG area to 2 MB.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SET_TSEG_4MB || northbridge/intel/fsp_rangeley || bool || 4 MB || <br />
Set the TSEG area to 4 MB.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SET_TSEG_8MB || northbridge/intel/fsp_rangeley || bool || 8 MB || <br />
Set the TSEG area to 8 MB.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FSP_FILE || northbridge/intel/fsp_rangeley/fsp || string || || <br />
The path and filename of the Intel FSP binary for this platform.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FSP_LOC || northbridge/intel/fsp_rangeley/fsp || hex || || <br />
The location in CBFS that the FSP is located. This must match the<br />
value that is set in the FSP binary. If the FSP needs to be moved,<br />
rebase the FSP with Intel's BCT (tool).<br />
<br />
The Rangeley FSP is built with a preferred base address of 0xFFF80000<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| REDIRECT_NBCIMX_TRACE_TO_SERIAL || northbridge/amd/cimx/rd890 || bool || Redirect AMD Northbridge CIMX Trace to serial console || <br />
This Option allows you to redirect the AMD Northbridge CIMX<br />
Trace debug information to the serial console.<br />
<br />
Warning: Only enable this option when debuging or tracing AMD CIMX code.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VGA_BIOS_ID || northbridge/amd/pi/00630F01 || string || || <br />
The default VGA BIOS PCI vendor/device ID should be set to the<br />
result of the map_oprom_vendev() function in northbridge.c.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VGA_BIOS_ID || northbridge/amd/pi/00730F01 || string || || <br />
The default VGA BIOS PCI vendor/device ID should be set to the<br />
result of the map_oprom_vendev() function in northbridge.c.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VGA_BIOS_ID || northbridge/amd/agesa/family16kb || string || || <br />
The default VGA BIOS PCI vendor/device ID should be set to the<br />
result of the map_oprom_vendev() function in northbridge.c.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SVI_HIGH_FREQ || northbridge/amd/amdfam10 || bool || || <br />
Select this for boards with a Voltage Regulator able to operate<br />
at 3.4 MHz in SVI mode. Ignored unless the AMD CPU is rev C3.<br />
<br />
||<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: HyperTransport setup || || || ||<br />
|- bgcolor="#eeeeee"<br />
| SVI_HIGH_FREQ || northbridge/amd/amdfam10 || bool || HyperTransport downlink width || <br />
This option sets the maximum permissible HyperTransport<br />
downlink width.<br />
<br />
Use of this option will only limit the autodetected HT width.<br />
It will not (and cannot) increase the width beyond the autodetected<br />
limits.<br />
<br />
This is primarily used to work around poorly designed or laid out HT<br />
traces on certain motherboards.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| LIMIT_HT_DOWN_WIDTH_16 || northbridge/amd/amdfam10 || bool || HyperTransport uplink width || <br />
This option sets the maximum permissible HyperTransport<br />
uplink width.<br />
<br />
Use of this option will only limit the autodetected HT width.<br />
It will not (and cannot) increase the width beyond the autodetected<br />
limits.<br />
<br />
This is primarily used to work around poorly designed or laid out HT<br />
traces on certain motherboards.<br />
<br />
||<br />
<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || Southbridge ||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_CMC || southbridge/intel/sch || bool || Add a CMC state machine binary || <br />
Select this option to add a CMC state machine binary to<br />
the resulting coreboot image.<br />
<br />
Note: Without this binary coreboot will not work<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CMC_FILE || southbridge/intel/sch || string || Intel CMC path and filename || <br />
The path and filename of the file to use as CMC state machine<br />
binary.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SERIRQ_CONTINUOUS_MODE || southbridge/intel/bd82x6x || bool || || <br />
If you set this option to y, the serial IRQ machine will be<br />
operated in continuous mode.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BUILD_WITH_FAKE_IFD || southbridge/intel/bd82x6x || bool || Build with a fake IFD || <br />
If you don't have an Intel Firmware Descriptor (ifd.bin) for your<br />
board, you can select this option and coreboot will build without it.<br />
Though, the resulting coreboot.rom will not contain all parts required<br />
to get coreboot running on your board. You can however write only the<br />
BIOS section to your board's flash ROM and keep the other sections<br />
untouched. Unfortunately the current version of flashrom doesn't<br />
support this yet. But there is a patch pending [1].<br />
<br />
WARNING: Never write a complete coreboot.rom to your flash ROM if it<br />
was built with a fake IFD. It just won't work.<br />
<br />
[1] http://www.flashrom.org/pipermail/flashrom/2013-June/011083.html<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_GBE_BIN || southbridge/intel/bd82x6x || bool || Add gigabit ethernet firmware || <br />
The integrated gigabit ethernet controller needs a firmware file.<br />
Select this if you are going to use the PCH integrated controller<br />
and have the firmware.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_ME_BIN || southbridge/intel/bd82x6x || bool || Add Intel Management Engine firmware || <br />
The Intel processor in the selected system requires a special firmware<br />
for an integrated controller called Management Engine (ME). The ME<br />
firmware might be provided in coreboot's 3rdparty repository. If<br />
not and if you don't have the firmware elsewhere, you can still<br />
build coreboot without it. In this case however, you'll have to make<br />
sure that you don't overwrite your ME firmware on your flash ROM.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| LOCK_MANAGEMENT_ENGINE || southbridge/intel/bd82x6x || bool || Lock Management Engine section || <br />
The Intel Management Engine supports preventing write accesses<br />
from the host to the Management Engine section in the firmware<br />
descriptor. If the ME section is locked, it can only be overwritten<br />
with an external SPI flash programmer. You will want this if you<br />
want to increase security of your ROM image once you are sure<br />
that the ME firmware is no longer going to change.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| LOCK_SPI_ON_RESUME || southbridge/intel/bd82x6x || bool || Lock all flash ROM sections on S3 resume || <br />
If the flash ROM shall be protected against write accesses from the<br />
operating system (OS), the locking procedure has to be repeated after<br />
each resume from S3. Select this if you never want to update the flash<br />
ROM from within your OS. Notice: Even with this option, the write lock<br />
has still to be enabled on the normal boot path (e.g. by the payload).<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| INTEL_LYNXPOINT_LP || southbridge/intel/lynxpoint || bool || || <br />
Set this option to y for Lynxpont LP (Haswell ULT).<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SERIRQ_CONTINUOUS_MODE || southbridge/intel/lynxpoint || bool || || <br />
If you set this option to y, the serial IRQ machine will be<br />
operated in continuous mode.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BUILD_WITH_FAKE_IFD || southbridge/intel/lynxpoint || bool || Build with a fake IFD || <br />
If you don't have an Intel Firmware Descriptor (ifd.bin) for your<br />
board, you can select this option and coreboot will build without it.<br />
Though, the resulting coreboot.rom will not contain all parts required<br />
to get coreboot running on your board. You can however write only the<br />
BIOS section to your board's flash ROM and keep the other sections<br />
untouched. Unfortunately the current version of flashrom doesn't<br />
support this yet. But there is a patch pending [1].<br />
<br />
WARNING: Never write a complete coreboot.rom to your flash ROM if it<br />
was built with a fake IFD. It just won't work.<br />
<br />
[1] http://www.flashrom.org/pipermail/flashrom/2013-June/011083.html<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_ME_BIN || southbridge/intel/lynxpoint || bool || Add Intel Management Engine firmware || <br />
The Intel processor in the selected system requires a special firmware<br />
for an integrated controller called Management Engine (ME). The ME<br />
firmware might be provided in coreboot's 3rdparty repository. If<br />
not and if you don't have the firmware elsewhere, you can still<br />
build coreboot without it. In this case however, you'll have to make<br />
sure that you don't overwrite your ME firmware on your flash ROM.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ME_MBP_CLEAR_LATE || southbridge/intel/lynxpoint || bool || Defer wait for ME MBP Cleared || <br />
If you set this option to y, the Management Engine driver<br />
will defer waiting for the MBP Cleared indicator until the<br />
finalize step. This can speed up boot time if the ME takes<br />
a long time to indicate this status.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FINALIZE_USB_ROUTE_XHCI || southbridge/intel/lynxpoint || bool || Route all ports to XHCI controller in finalize step || <br />
If you set this option to y, the USB ports will be routed<br />
to the XHCI controller during the finalize SMM callback.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| LOCK_MANAGEMENT_ENGINE || southbridge/intel/lynxpoint || bool || Lock Management Engine section || <br />
The Intel Management Engine supports preventing write accesses<br />
from the host to the Management Engine section in the firmware<br />
descriptor. If the ME section is locked, it can only be overwritten<br />
with an external SPI flash programmer. You will want this if you<br />
want to increase security of your ROM image once you are sure<br />
that the ME firmware is no longer going to change.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SERIRQ_CONTINUOUS_MODE || southbridge/intel/fsp_bd82x6x || bool || || <br />
If you set this option to y, the serial IRQ machine will be<br />
operated in continuous mode.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| INCLUDE_ME || southbridge/intel/fsp_bd82x6x || bool || || <br />
Include the me.bin and descriptor.bin for Intel PCH.<br />
This is usually required for the PCH.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ME_PATH || southbridge/intel/fsp_bd82x6x || string || || <br />
The path of the ME and Descriptor files.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| LOCK_MANAGEMENT_ENGINE || southbridge/intel/fsp_bd82x6x || bool || Lock Management Engine section || <br />
The Intel Management Engine supports preventing write accesses<br />
from the host to the Management Engine section in the firmware<br />
descriptor. If the ME section is locked, it can only be overwritten<br />
with an external SPI flash programmer. You will want this if you<br />
want to increase security of your ROM image once you are sure<br />
that the ME firmware is no longer going to change.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SERIRQ_CONTINUOUS_MODE || southbridge/intel/ibexpeak || bool || || <br />
If you set this option to y, the serial IRQ machine will be<br />
operated in continuous mode.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BUILD_WITH_FAKE_IFD || southbridge/intel/ibexpeak || bool || Build with a fake IFD || <br />
If you don't have an Intel Firmware Descriptor (ifd.bin) for your<br />
board, you can select this option and coreboot will build without it.<br />
Though, the resulting coreboot.rom will not contain all parts required<br />
to get coreboot running on your board. You can however write only the<br />
BIOS section to your board's flash ROM and keep the other sections<br />
untouched. Unfortunately the current version of flashrom doesn't<br />
support this yet. But there is a patch pending [1].<br />
<br />
WARNING: Never write a complete coreboot.rom to your flash ROM if it<br />
was built with a fake IFD. It just won't work.<br />
<br />
[1] http://www.flashrom.org/pipermail/flashrom/2013-June/011083.html<br />
<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_ME_BIN || southbridge/intel/ibexpeak || bool || Add Intel Management Engine firmware || <br />
The Intel processor in the selected system requires a special firmware<br />
for an integrated controller called Management Engine (ME). The ME<br />
firmware might be provided in coreboot's 3rdparty repository. If<br />
not and if you don't have the firmware elsewhere, you can still<br />
build coreboot without it. In this case however, you'll have to make<br />
sure that you don't overwrite your ME firmware on your flash ROM.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| LOCK_MANAGEMENT_ENGINE || southbridge/intel/ibexpeak || bool || Lock Management Engine section || <br />
The Intel Management Engine supports preventing write accesses<br />
from the host to the Management Engine section in the firmware<br />
descriptor. If the ME section is locked, it can only be overwritten<br />
with an external SPI flash programmer. You will want this if you<br />
want to increase security of your ROM image once you are sure<br />
that the ME firmware is no longer going to change.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SERIRQ_CONTINUOUS_MODE || southbridge/intel/fsp_rangeley || bool || || <br />
If you set this option to y, the serial IRQ machine will be<br />
operated in continuous mode.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| INCLUDE_ME || southbridge/intel/fsp_rangeley || bool || Add Intel descriptor.bin file || <br />
Include the descriptor.bin for rangeley.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ME_PATH || southbridge/intel/fsp_rangeley || string || Path to descriptor.bin file || <br />
The path of the descriptor.bin file.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SATA_CONTROLLER_MODE || southbridge/amd/cimx/sb700 || hex || || <br />
0x0 = Native IDE mode.<br />
0x1 = RAID mode.<br />
0x2 = AHCI mode.<br />
0x3 = Legacy IDE mode.<br />
0x4 = IDE-&gt;AHCI mode.<br />
0x5 = AHCI mode as 7804 ID (AMD driver).<br />
0x6 = IDE-&gt;AHCI mode as 7804 ID (AMD driver).<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PCIB_ENABLE || southbridge/amd/cimx/sb700 || bool || || <br />
n = Disable PCI Bridge Device 14 Function 4.<br />
y = Enable PCI Bridge Device 14 Function 4.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ACPI_SCI_IRQ || southbridge/amd/cimx/sb700 || hex || || <br />
Set SCI IRQ to 9.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| REDIRECT_SBCIMX_TRACE_TO_SERIAL || southbridge/amd/cimx/sb700 || bool || Redirect AMD Southbridge CIMX Trace to serial console || <br />
This Option allows you to redirect the AMD Southbridge CIMX Trace<br />
debug information to the serial console.<br />
<br />
Warning: Only enable this option when debuging or tracing AMD CIMX code.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ENABLE_IDE_COMBINED_MODE || southbridge/amd/cimx/sb800 || bool || Enable SATA IDE combined mode || <br />
If Combined Mode is enabled. IDE controller is exposed and<br />
SATA controller has control over Port0 through Port3,<br />
IDE controller has control over Port4 and Port5.<br />
<br />
If Combined Mode is disabled, IDE controller is hidden and<br />
SATA controller has full control of all 6 Ports when operating in non-IDE mode.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| IDE_COMBINED_MODE || southbridge/amd/cimx/sb800 || hex || SATA Mode || <br />
Select the mode in which SATA should be driven. NATIVE AHCI, or RAID.<br />
The default is AHCI.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SB800_SATA_IDE || southbridge/amd/cimx/sb800 || bool || NATIVE || <br />
NATIVE does not require a ROM.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SB800_SATA_AHCI || southbridge/amd/cimx/sb800 || bool || AHCI || <br />
AHCI is the default and may work with or without AHCI ROM. It depends on the payload support.<br />
For example, seabios does not require the AHCI ROM.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SB800_SATA_RAID || southbridge/amd/cimx/sb800 || bool || RAID || <br />
sb800 RAID mode must have the two required ROM files.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| RAID_ROM_ID || southbridge/amd/cimx/sb800 || string || RAID device PCI IDs || <br />
1002,4392 for SATA NON-RAID5 module, 1002,4393 for SATA RAID5 mode<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| RAID_MISC_ROM_POSITION || southbridge/amd/cimx/sb800 || hex || RAID Misc ROM Position || <br />
The RAID ROM requires that the MISC ROM is located between the range<br />
0xFFF0_0000 to 0xFFF0_FFFF. Also, it must 1K bytes aligned.<br />
The CONFIG_ROM_SIZE must larger than 0x100000.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SB800_IMC_FWM || southbridge/amd/cimx/sb800 || bool || Add IMC firmware || <br />
Add SB800 / Hudson 1 IMC Firmware to support the onboard fan control.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SB800_FWM_AT_FFFA0000 || southbridge/amd/cimx/sb800 || bool || 0xFFFA0000 || <br />
The IMC and GEC ROMs requires a 'signature' located at one of several<br />
fixed locations in memory. The location used shouldn't matter, just<br />
select an area that doesn't conflict with anything else.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SB800_FWM_AT_FFF20000 || southbridge/amd/cimx/sb800 || bool || 0xFFF20000 || <br />
The IMC and GEC ROMs requires a 'signature' located at one of several<br />
fixed locations in memory. The location used shouldn't matter, just<br />
select an area that doesn't conflict with anything else.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SB800_FWM_AT_FFE20000 || southbridge/amd/cimx/sb800 || bool || 0xFFE20000 || <br />
The IMC and GEC ROMs requires a 'signature' located at one of several<br />
fixed locations in memory. The location used shouldn't matter, just<br />
select an area that doesn't conflict with anything else.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SB800_FWM_AT_FFC20000 || southbridge/amd/cimx/sb800 || bool || 0xFFC20000 || <br />
The IMC and GEC ROMs requires a 'signature' located at one of several<br />
fixed locations in memory. The location used shouldn't matter, just<br />
select an area that doesn't conflict with anything else.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SB800_FWM_AT_FF820000 || southbridge/amd/cimx/sb800 || bool || 0xFF820000 || <br />
The IMC and GEC ROMs requires a 'signature' located at one of several<br />
fixed locations in memory. The location used shouldn't matter, just<br />
select an area that doesn't conflict with anything else.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EHCI_BAR || southbridge/amd/cimx/sb800 || hex || Fan Control || <br />
Select the method of SB800 fan control to be used. None would be<br />
for either fixed maximum speed fans connected to the SB800 or for<br />
an external chip controlling the fan speeds. Manual control sets<br />
up the SB800 fan control registers. IMC fan control uses the SB800<br />
IMC to actively control the fan speeds.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SB800_NO_FAN_CONTROL || southbridge/amd/cimx/sb800 || bool || None || <br />
No SB800 Fan control - Do not set up the SB800 fan control registers.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SB800_MANUAL_FAN_CONTROL || southbridge/amd/cimx/sb800 || bool || Manual || <br />
Configure the SB800 fan control registers in devicetree.cb.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SB800_IMC_FAN_CONTROL || southbridge/amd/cimx/sb800 || bool || IMC Based || <br />
Set up the SB800 to use the IMC based Fan controller. This requires<br />
the IMC rom from AMD. Configure the registers in devicetree.cb.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SATA_CONTROLLER_MODE || southbridge/amd/cimx/sb900 || hex || || <br />
0x0 = Native IDE mode.<br />
0x1 = RAID mode.<br />
0x2 = AHCI mode.<br />
0x3 = Legacy IDE mode.<br />
0x4 = IDE-&gt;AHCI mode.<br />
0x5 = AHCI mode as 7804 ID (AMD driver).<br />
0x6 = IDE-&gt;AHCI mode as 7804 ID (AMD driver).<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PCIB_ENABLE || southbridge/amd/cimx/sb900 || bool || || <br />
n = Disable PCI Bridge Device 14 Function 4.<br />
y = Enable PCI Bridge Device 14 Function 4.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ACPI_SCI_IRQ || southbridge/amd/cimx/sb900 || hex || || <br />
Set SCI IRQ to 9.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HUDSON_XHCI_ENABLE || southbridge/amd/pi/hudson || bool || Enable Hudson XHCI Controller || <br />
The XHCI controller must be enabled and the XHCI firmware<br />
must be added in order to have USB 3.0 support configured<br />
by coreboot. The OS will be responsible for enabling the XHCI<br />
controller if the the XHCI firmware is available but the<br />
XHCI controller is not enabled by coreboot.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HUDSON_XHCI_FWM || southbridge/amd/pi/hudson || bool || Add xhci firmware || <br />
Add Hudson 2/3/4 XHCI Firmware to support the onboard USB 3.0<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HUDSON_IMC_FWM || southbridge/amd/pi/hudson || bool || Add IMC firmware || <br />
Add Hudson 2/3/4 IMC Firmware to support the onboard fan control<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HUDSON_GEC_FWM || southbridge/amd/pi/hudson || bool || || <br />
Add Hudson 2/3/4 GEC Firmware to support the onboard gigabit Ethernet MAC.<br />
Must be connected to a Broadcom B50610 or B50610M PHY on the motherboard.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HUDSON_FWM_POSITION || southbridge/amd/pi/hudson || hex || Hudson Firmware ROM Position || <br />
Hudson requires the firmware MUST be located at<br />
a specific address (ROM start address + 0x20000), otherwise<br />
xhci host Controller can not find or load the xhci firmware.<br />
<br />
The firmware start address is dependent on the ROM chip size.<br />
The default offset is 0x20000 from the ROM start address, namely<br />
0xFFF20000 if flash chip size is 1M<br />
0xFFE20000 if flash chip size is 2M<br />
0xFFC20000 if flash chip size is 4M<br />
0xFF820000 if flash chip size is 8M<br />
0xFF020000 if flash chip size is 16M<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HUDSON_SATA_MODE || southbridge/amd/pi/hudson || int || SATA Mode || <br />
Select the mode in which SATA should be driven. NATIVE AHCI, or RAID.<br />
The default is NATIVE.<br />
0: NATIVE mode does not require a ROM.<br />
1: RAID mode must have the two ROM files.<br />
2: AHCI may work with or without AHCI ROM. It depends on the payload support.<br />
For example, seabios does not require the AHCI ROM.<br />
3: LEGACY IDE<br />
4: IDE to AHCI<br />
5: AHCI7804: ROM Required, and AMD driver required in the OS.<br />
6: IDE to AHCI7804: ROM Required, and AMD driver required in the OS.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || NATIVE ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || RAID ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || AHCI ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || LEGACY IDE ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || IDE to AHCI ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || AHCI7804 ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || IDE to AHCI7804 ||<br />
|- bgcolor="#eeeeee"<br />
| RAID_ROM_ID || southbridge/amd/pi/hudson || string || RAID device PCI IDs || <br />
1022,7802 for SATA NON-RAID5 module, 1022,7803 for SATA RAID5 mode<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| RAID_MISC_ROM_POSITION || southbridge/amd/pi/hudson || hex || RAID Misc ROM Position || <br />
The RAID ROM requires that the MISC ROM is located between the range<br />
0xFFF0_0000 to 0xFFF0_FFFF. Also, it must 1K bytes aligned.<br />
The CONFIG_ROM_SIZE must be larger than 0x100000.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HUDSON_LEGACY_FREE || southbridge/amd/pi/hudson || bool || System is legacy free || <br />
Select y if there is no keyboard controller in the system.<br />
This sets variables in AGESA and ACPI.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| AZ_PIN || southbridge/amd/pi/hudson || hex || || <br />
bit 1,0 - pin 0<br />
bit 3,2 - pin 1<br />
bit 5,4 - pin 2<br />
bit 7,6 - pin 3<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EXT_CONF_SUPPORT || southbridge/amd/rs690 || bool || || <br />
Select if RS690 should be setup to support MMCONF.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HUDSON_XHCI_ENABLE || southbridge/amd/agesa/hudson || bool || Enable Hudson XHCI Controller || <br />
The XHCI controller must be enabled and the XHCI firmware<br />
must be added in order to have USB 3.0 support configured<br />
by coreboot. The OS will be responsible for enabling the XHCI<br />
controller if the the XHCI firmware is available but the<br />
XHCI controller is not enabled by coreboot.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HUDSON_XHCI_FWM || southbridge/amd/agesa/hudson || bool || Add xhci firmware || <br />
Add Hudson 2/3/4 XHCI Firmware to support the onboard USB 3.0<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HUDSON_IMC_FWM || southbridge/amd/agesa/hudson || bool || Add imc firmware || <br />
Add Hudson 2/3/4 IMC Firmware to support the onboard fan control<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HUDSON_GEC_FWM || southbridge/amd/agesa/hudson || bool || || <br />
Add Hudson 2/3/4 GEC Firmware to support the onboard gigabit Ethernet MAC.<br />
Must be connected to a Broadcom B50610 or B50610M PHY on the motherboard.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HUDSON_FWM_POSITION || southbridge/amd/agesa/hudson || hex || Hudson Firmware ROM Position || <br />
Hudson requires the firmware MUST be located at<br />
a specific address (ROM start address + 0x20000), otherwise<br />
xhci host Controller can not find or load the xhci firmware.<br />
<br />
The firmware start address is dependent on the ROM chip size.<br />
The default offset is 0x20000 from the ROM start address, namely<br />
0xFFF20000 if flash chip size is 1M<br />
0xFFE20000 if flash chip size is 2M<br />
0xFFC20000 if flash chip size is 4M<br />
0xFF820000 if flash chip size is 8M<br />
0xFF020000 if flash chip size is 16M<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HUDSON_SATA_MODE || southbridge/amd/agesa/hudson || int || SATA Mode || <br />
Select the mode in which SATA should be driven. NATIVE AHCI, or RAID.<br />
The default is NATIVE.<br />
0: NATIVE mode does not require a ROM.<br />
1: RAID mode must have the two ROM files.<br />
2: AHCI may work with or without AHCI ROM. It depends on the payload support.<br />
For example, seabios does not require the AHCI ROM.<br />
3: LEGACY IDE<br />
4: IDE to AHCI<br />
5: AHCI7804: ROM Required, and AMD driver required in the OS.<br />
6: IDE to AHCI7804: ROM Required, and AMD driver required in the OS.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || NATIVE ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || RAID ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || AHCI ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || LEGACY IDE ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || IDE to AHCI ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || AHCI7804 ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || IDE to AHCI7804 ||<br />
|- bgcolor="#eeeeee"<br />
| RAID_ROM_ID || southbridge/amd/agesa/hudson || string || RAID device PCI IDs || <br />
1022,7802 for SATA NON-RAID5 module, 1022,7803 for SATA RAID5 mode<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| RAID_MISC_ROM_POSITION || southbridge/amd/agesa/hudson || hex || RAID Misc ROM Position || <br />
The RAID ROM requires that the MISC ROM is located between the range<br />
0xFFF0_0000 to 0xFFF0_FFFF. Also, it must 1K bytes aligned.<br />
The CONFIG_ROM_SIZE must be larger than 0x100000.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HUDSON_LEGACY_FREE || southbridge/amd/agesa/hudson || bool || System is legacy free || <br />
Select y if there is no keyboard controller in the system.<br />
This sets variables in AGESA and ACPI.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| AZ_PIN || southbridge/amd/agesa/hudson || hex || || <br />
bit 1,0 - pin 0<br />
bit 3,2 - pin 1<br />
bit 5,4 - pin 2<br />
bit 7,6 - pin 3<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EHCI_BAR || southbridge/amd/sb600 || hex || SATA Mode || <br />
Select the mode in which SATA should be driven. IDE or AHCI.<br />
The default is IDE.<br />
<br />
config SATA_MODE_IDE<br />
bool "IDE"<br />
<br />
config SATA_MODE_AHCI<br />
bool "AHCI"<br />
||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || Super I/O ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || Embedded Controllers ||<br />
|- bgcolor="#eeeeee"<br />
| EC_ACPI || ec/acpi || bool || || <br />
ACPI Embedded Controller interface. Mostly found in laptops.<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EC_QUANTA_IT8518 || ec/quanta/it8518 || bool || || <br />
Interface to QUANTA IT8518 Embedded Controller.<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EC_QUANTA_ENE_KB3940Q || ec/quanta/ene_kb3940q || bool || || <br />
Interface to QUANTA ENE KB3940Q Embedded Controller.<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EC_SMSC_MEC1308 || ec/smsc/mec1308 || bool || || <br />
Shared memory mailbox interface to SMSC MEC1308 Embedded Controller.<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EC_GOOGLE_CHROMEEC || ec/google/chromeec || bool || || <br />
Google's Chrome EC<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EC_GOOGLE_CHROMEEC_ACPI_MEMMAP || ec/google/chromeec || bool || || <br />
When defined, ACPI accesses EC memmap data on ports 66h/62h. When<br />
not defined, the memmap data is instead accessed on 900h-9ffh via<br />
the LPC bus.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EC_GOOGLE_CHROMEEC_I2C || ec/google/chromeec || bool || || <br />
Google's Chrome EC via I2C bus.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EC_GOOGLE_CHROMEEC_I2C_PROTO3 || ec/google/chromeec || bool || || <br />
Use only proto3 for i2c EC communication.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EC_GOOGLE_CHROMEEC_LPC || ec/google/chromeec || bool || || <br />
Google Chrome EC via LPC bus.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EC_GOOGLE_CHROMEEC_MEC || ec/google/chromeec || bool || || <br />
Microchip EC variant for LPC register access.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EC_GOOGLE_CHROMEEC_SPI || ec/google/chromeec || bool || || <br />
Google's Chrome EC via SPI bus.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EC_GOOGLE_CHROMEEC_SPI_WAKEUP_DELAY_US || ec/google/chromeec || int || || <br />
Force delay after asserting /CS to allow EC to wakeup.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EC_COMPAL_ENE932 || ec/compal/ene932 || bool || || <br />
Interface to COMPAL ENE932 Embedded Controller.<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EC_KONTRON_IT8516E || ec/kontron/it8516e || bool || || <br />
Kontron uses an ITE IT8516E on the KTQM77. Its firmware might<br />
come from Fintek (mentioned as Finte*c* somewhere in their Linux<br />
driver).<br />
The KTQM77 is an embedded board and the IT8516E seems to be<br />
only used for fan control and GPIO.<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || SoC ||<br />
|- bgcolor="#eeeeee"<br />
| BOOTBLOCK_CPU_INIT || soc/nvidia/tegra124 || string || || <br />
CPU/SoC-specific bootblock code. This is useful if the<br />
bootblock must load microcode or copy data from ROM before<br />
searching for the bootblock.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MAINBOARD_DO_DSI_INIT || soc/nvidia/tegra132 || bool || Use dsi graphics interface || <br />
Initialize dsi display<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MAINBOARD_DO_SOR_INIT || soc/nvidia/tegra132 || bool || Use dp graphics interface || <br />
Initialize dp display<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOOTBLOCK_CPU_INIT || soc/nvidia/tegra132 || string || || <br />
CPU/SoC-specific bootblock code. This is useful if the<br />
bootblock must load microcode or copy data from ROM before<br />
searching for the bootblock.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MTS_DIRECTORY || soc/nvidia/tegra132 || string || Directory where MTS microcode files are located || <br />
Path to directory where MTS microcode files are located.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| TRUSTZONE_CARVEOUT_SIZE_MB || soc/nvidia/tegra132 || hex || Size of Trust Zone region || <br />
Size of Trust Zone area in MiB to reserve in memory map.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOOTROM_SDRAM_INIT || soc/nvidia/tegra132 || bool || SoC BootROM does SDRAM init with full BCT || <br />
Use during Ryu LPDDR3 bringup<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CYGNUS_DDR_AUTO_SELF_REFRESH_ENABLE || soc/broadcom/cygnus || bool || Enable DDR auto self-refresh || <br />
Warning: M0 expects that auto self-refresh is enabled. Modify<br />
with caution.<br />
<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SOC_INTEL_BAYTRAIL || soc/intel/baytrail || bool || || <br />
Bay Trail M/D part support.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_MRC || soc/intel/baytrail || bool || Add a Memory Reference Code binary || <br />
Select this option to add a blob containing<br />
memory reference code.<br />
Note: Without this binary coreboot will not work<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MRC_FILE || soc/intel/baytrail || string || Intel memory refeference code path and filename || <br />
The path and filename of the file to use as System Agent<br />
binary. Note that this points to the sandybridge binary file<br />
which is will not work, but it serves its purpose to do builds.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DCACHE_RAM_SIZE || soc/intel/baytrail || hex || || <br />
The size of the cache-as-ram region required during bootblock<br />
and/or romstage. Note DCACHE_RAM_SIZE and DCACHE_RAM_MRC_VAR_SIZE<br />
must add up to a power of 2.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DCACHE_RAM_MRC_VAR_SIZE || soc/intel/baytrail || hex || || <br />
The amount of cache-as-ram region required by the reference code.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DCACHE_RAM_ROMSTAGE_STACK_SIZE || soc/intel/baytrail || hex || || <br />
The amount of anticipated stack usage from the data cache<br />
during pre-RAM ROM stage execution.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| RESET_ON_INVALID_RAMSTAGE_CACHE || soc/intel/baytrail || bool || Reset the system on S3 wake when ramstage cache invalid. || <br />
The baytrail romstage code caches the loaded ramstage program<br />
in SMM space. On S3 wake the romstage will copy over a fresh<br />
ramstage that was cached in the SMM space. This option determines<br />
the action to take when the ramstage cache is invalid. If selected<br />
the system will reset otherwise the ramstage will be reloaded from<br />
cbfs.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CBFS_SIZE || soc/intel/baytrail || hex || Size of CBFS filesystem in ROM || <br />
On Bay Trail systems the firmware image has to store a lot more<br />
than just coreboot, including:<br />
- a firmware descriptor<br />
- Intel Management Engine firmware<br />
- MRC cache information<br />
This option allows to limit the size of the CBFS portion in the<br />
firmware image.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ENABLE_BUILTIN_COM1 || soc/intel/baytrail || bool || Enable builtin COM1 Serial Port || <br />
The PMC has a legacy COM1 serial port. Choose this option to<br />
configure the pads and enable it. This serial port can be used for<br />
the debug console.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_ME_BIN || soc/intel/baytrail || bool || Add Intel Management Engine firmware || <br />
The Intel processor in the selected system requires a special firmware<br />
for an integrated controller called Management Engine (ME). The ME<br />
firmware might be provided in coreboot's 3rdparty repository. If<br />
not and if you don't have the firmware elsewhere, you can still<br />
build coreboot without it. In this case however, you'll have to make<br />
sure that you don't overwrite your ME firmware on your flash ROM.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BUILD_WITH_FAKE_IFD || soc/intel/baytrail || bool || Build with a fake IFD || <br />
If you don't have an Intel Firmware Descriptor (ifd.bin) for your<br />
board, you can select this option and coreboot will build without it.<br />
Though, the resulting coreboot.rom will not contain all parts required<br />
to get coreboot running on your board. You can however write only the<br />
BIOS section to your board's flash ROM and keep the other sections<br />
untouched. Unfortunately the current version of flashrom doesn't<br />
support this yet. But there is a patch pending [1].<br />
<br />
WARNING: Never write a complete coreboot.rom to your flash ROM if it<br />
was built with a fake IFD. It just won't work.<br />
<br />
[1] http://www.flashrom.org/pipermail/flashrom/2013-June/011083.html<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_REFCODE_BLOB || soc/intel/baytrail || bool || An external reference code blob should be put into cbfs. || <br />
The reference code blob will be placed into cbfs.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| REFCODE_BLOB_FILE || soc/intel/baytrail || string || Path and filename to reference code blob. || <br />
The path and filename to the file to be added to cbfs.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SOC_INTEL_COMMON || soc/intel/common || bool || || <br />
common code for Intel SOCs<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SOC_INTEL_BROADWELL || soc/intel/broadwell || bool || || <br />
Intel Broadwell and Haswell ULT support.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DCACHE_RAM_SIZE || soc/intel/broadwell || hex || || <br />
The size of the cache-as-ram region required during bootblock<br />
and/or romstage. Note DCACHE_RAM_SIZE and DCACHE_RAM_MRC_VAR_SIZE<br />
must add up to a power of 2.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DCACHE_RAM_MRC_VAR_SIZE || soc/intel/broadwell || hex || || <br />
The amount of cache-as-ram region required by the reference code.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DCACHE_RAM_ROMSTAGE_STACK_SIZE || soc/intel/broadwell || hex || || <br />
The amount of anticipated stack usage from the data cache<br />
during pre-ram rom stage execution.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_MRC || soc/intel/broadwell || bool || Add a Memory Reference Code binary || <br />
Select this option to add a Memory Reference Code binary to<br />
the resulting coreboot image.<br />
<br />
Note: Without this binary coreboot will not work<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MRC_FILE || soc/intel/broadwell || string || Intel Memory Reference Code path and filename || <br />
The filename of the file to use as Memory Reference Code binary.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CBFS_SIZE || soc/intel/broadwell || hex || Size of CBFS filesystem in ROM || <br />
The firmware image has to store more than just coreboot, including:<br />
- a firmware descriptor<br />
- Intel Management Engine firmware<br />
- MRC cache information<br />
This option allows to limit the size of the CBFS portion in the<br />
firmware image.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PRE_GRAPHICS_DELAY || soc/intel/broadwell || int || Graphics initialization delay in ms || <br />
On some systems, coreboot boots so fast that connected monitors<br />
(mostly TVs) won't be able to wake up fast enough to talk to the<br />
VBIOS. On those systems we need to wait for a bit before executing<br />
the VBIOS.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| RESET_ON_INVALID_RAMSTAGE_CACHE || soc/intel/broadwell || bool || Reset the system on S3 wake when ramstage cache invalid. || <br />
The romstage code caches the loaded ramstage program in SMM space.<br />
On S3 wake the romstage will copy over a fresh ramstage that was<br />
cached in the SMM space. This option determines the action to take<br />
when the ramstage cache is invalid. If selected the system will<br />
reset otherwise the ramstage will be reloaded from cbfs.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SERIRQ_CONTINUOUS_MODE || soc/intel/broadwell || bool || || <br />
If you set this option to y, the serial IRQ machine will be<br />
operated in continuous mode.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_ME_BIN || soc/intel/broadwell || bool || Add Intel Management Engine firmware || <br />
The Intel processor in the selected system requires a special firmware<br />
for an integrated controller called Management Engine (ME). The ME<br />
firmware might be provided in coreboot's 3rdparty repository. If<br />
not and if you don't have the firmware elsewhere, you can still<br />
build coreboot without it. In this case however, you'll have to make<br />
sure that you don't overwrite your ME firmware on your flash ROM.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BUILD_WITH_FAKE_IFD || soc/intel/broadwell || bool || Build with a fake IFD || <br />
If you don't have an Intel Firmware Descriptor (ifd.bin) for your<br />
board, you can select this option and coreboot will build without it.<br />
Though, the resulting coreboot.rom will not contain all parts required<br />
to get coreboot running on your board. You can however write only the<br />
BIOS section to your board's flash ROM and keep the other sections<br />
untouched. Unfortunately the current version of flashrom doesn't<br />
support this yet. But there is a patch pending [1].<br />
<br />
WARNING: Never write a complete coreboot.rom to your flash ROM if it<br />
was built with a fake IFD. It just won't work.<br />
<br />
[1] http://www.flashrom.org/pipermail/flashrom/2013-June/011083.html<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| LOCK_MANAGEMENT_ENGINE || soc/intel/broadwell || bool || Lock Management Engine section || <br />
The Intel Management Engine supports preventing write accesses<br />
from the host to the Management Engine section in the firmware<br />
descriptor. If the ME section is locked, it can only be overwritten<br />
with an external SPI flash programmer. You will want this if you<br />
want to increase security of your ROM image once you are sure<br />
that the ME firmware is no longer going to change.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SOC_INTEL_FSP_BAYTRAIL || soc/intel/fsp_baytrail || bool || || <br />
Bay Trail I part support using the Intel FSP.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SMM_TSEG_SIZE || soc/intel/fsp_baytrail || hex || || <br />
This is set by the FSP<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VGA_BIOS_ID || soc/intel/fsp_baytrail || string || || <br />
This is the default PCI ID for the Bay Trail graphics<br />
devices. This string names the vbios ROM in cbfs.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CBFS_SIZE || soc/intel/fsp_baytrail || hex || || <br />
On Bay Trail systems the firmware image has to store a lot more<br />
than just coreboot, including:<br />
- a firmware descriptor<br />
- Intel Trusted Execution Engine firmware<br />
This option specifies the maximum size of the CBFS portion in the<br />
firmware image.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| INCLUDE_ME || soc/intel/fsp_baytrail || bool || Include the TXE || <br />
Build the TXE and descriptor.bin into the ROM image. If you want to use a<br />
descriptor.bin and TXE file from the previous ROM image, you may not want<br />
to build it in here.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ME_PATH || soc/intel/fsp_baytrail || string || Path to ME || <br />
The path of the TXE and Descriptor files.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| LOCK_MANAGEMENT_ENGINE || soc/intel/fsp_baytrail || bool || Lock TXE section || <br />
The Intel Trusted Execution Engine supports preventing write accesses<br />
from the host to the Management Engine section in the firmware<br />
descriptor. If the ME section is locked, it can only be overwritten<br />
with an external SPI flash programmer. You will want this if you<br />
want to increase security of your ROM image once you are sure<br />
that the ME firmware is no longer going to change.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ENABLE_BUILTIN_COM1 || soc/intel/fsp_baytrail || bool || Enable built-in legacy Serial Port || <br />
The Baytrail SOC has one legacy serial port. Choose this option to<br />
configure the pads and enable it. This serial port can be used for<br />
the debug console.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FSP_FILE || soc/intel/fsp_baytrail/fsp || string || || <br />
The path and filename of the Intel FSP binary for this platform.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FSP_LOC || soc/intel/fsp_baytrail/fsp || hex || || <br />
The location in CBFS that the FSP is located. This must match the<br />
value that is set in the FSP binary. If the FSP needs to be moved,<br />
rebase the FSP with Intel's BCT (tool).<br />
<br />
The Bay Trail FSP is built with a preferred base address of<br />
0xFFFC0000.<br />
<br />
||<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CBFS_SIZE || soc/qualcomm/ipq806x || hex || Size of CBFS filesystem in ROM || <br />
CBFS size needs to match the size of memory allocated to the<br />
coreboot blob elsewhere in the system. Make sure this config option<br />
is fine tuned in the board config file.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SBL_BLOB || soc/qualcomm/ipq806x || string || file name of the Qualcomm SBL blob || <br />
The path and filename of the binary blob containing<br />
ipq806x early initialization code, as supplied by the<br />
vendor.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || Intel FSP ||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_FSP_BIN || drivers/intel/fsp1_0 || bool || Use Intel Firmware Support Package || <br />
Select this option to add an Intel FSP binary to<br />
the resulting coreboot image.<br />
<br />
Note: Without this binary, coreboot builds relying on the FSP<br />
will not boot<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FSP_FILE || drivers/intel/fsp1_0 || string || Intel FSP binary path and filename || <br />
The path and filename of the Intel FSP binary for this platform.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FSP_LOC || drivers/intel/fsp1_0 || hex || Intel FSP Binary location in CBFS || <br />
The location in CBFS that the FSP is located. This must match the<br />
value that is set in the FSP binary. If the FSP needs to be moved,<br />
rebase the FSP with Intel's BCT (tool).<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ENABLE_FSP_FAST_BOOT || drivers/intel/fsp1_0 || bool || Enable Fast Boot || <br />
Enabling this feature will force the MRC data to be cached in NV<br />
storage to be used for speeding up boot time on future reboots<br />
and/or power cycles.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ENABLE_MRC_CACHE || drivers/intel/fsp1_0 || bool || || <br />
Enabling this feature will cause MRC data to be cached in NV storage.<br />
This can either be used for fast boot, or just because the FSP wants<br />
it to be saved.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MRC_CACHE_SIZE || drivers/intel/fsp1_0 || hex || Fast Boot Data Cache Size || <br />
This is the amount of space in NV storage that is reserved for the<br />
fast boot data cache storage.<br />
<br />
WARNING: Because this area will be erased and re-written, the size<br />
should be a full sector of the flash ROM chip and nothing else should<br />
be included in CBFS in any sector that the fast boot cache data is in.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| OVERRIDE_CACHE_CACHE_LOC || drivers/intel/fsp1_0 || bool || || <br />
Selected by the platform to set a new default location for the<br />
MRC/fast boot cache.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MRC_CACHE_LOC_OVERRIDE || drivers/intel/fsp1_0 || hex || || <br />
Sets the override CBFS location of the MRC/fast boot cache.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MRC_CACHE_LOC || drivers/intel/fsp1_0 || hex || Fast Boot Data Cache location in CBFS || <br />
The location in CBFS for the MRC data to be cached.<br />
<br />
WARNING: This should be on a sector boundary of the BIOS ROM chip<br />
and nothing else should be included in that sector, or IT WILL BE<br />
ERASED.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VIRTUAL_ROM_SIZE || drivers/intel/fsp1_0 || hex || Virtual ROM Size || <br />
This is used to calculate the offset of the MRC data cache in NV<br />
Storage for fast boot. If in doubt, leave this set to the default<br />
which sets the virtual size equal to the ROM size.<br />
<br />
Example: Cougar Canyon 2 has two 8 MB SPI ROMs. When the SPI ROMs are<br />
loaded with a 4 MB coreboot image, the virtual ROM size is 8 MB. When<br />
the SPI ROMs are loaded with an 8 MB coreboot image, the virtual ROM<br />
size is 16 MB.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CACHE_ROM_SIZE_OVERRIDE || drivers/intel/fsp1_0 || hex || Cache ROM Size || <br />
This is the size of the cachable area that is passed into the FSP in<br />
the early initialization. Typically this should be the size of the CBFS<br />
area, but the size must be a power of 2 whereas the CBFS size does not<br />
have this limitation.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| USE_GENERIC_FSP_CAR_INC || drivers/intel/fsp1_0 || bool || || <br />
The chipset can select this to use a generic cache_as_ram.inc file<br />
that should be good for all FSP based platforms.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FSP_USES_UPD || drivers/intel/fsp1_0 || bool || || <br />
If this FSP uses UPD/VPD data regions, select this in the chipset Kconfig.<br />
||<br />
<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: Devices || || || ||<br />
|- bgcolor="#eeeeee"<br />
| MAINBOARD_DO_NATIVE_VGA_INIT || device || bool || Use native graphics initialization || <br />
Some mainboards, such as the Google Link, allow initializing the display<br />
without the need of a binary only VGA OPROM. Enabling this option may be<br />
faster, but also lacks flexibility in setting modes.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VGA_ROM_RUN || device || bool || Run VGA Option ROMs || <br />
Execute VGA Option ROMs in coreboot if found. This is required<br />
to enable PCI/AGP/PCI-E video cards when not using a SeaBIOS<br />
payload.<br />
<br />
When using a SeaBIOS payload it runs all option ROMs with much<br />
more complete BIOS interrupt services available than coreboot,<br />
which some option ROMs require in order to function correctly.<br />
<br />
If unsure, say N when using SeaBIOS as payload, Y otherwise.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| S3_VGA_ROM_RUN || device || bool || Re-run VGA Option ROMs on S3 resume || <br />
Execute VGA Option ROMs in coreboot when resuming from S3 suspend.<br />
<br />
When using a SeaBIOS payload it runs all option ROMs with much<br />
more complete BIOS interrupt services available than coreboot,<br />
which some option ROMs require in order to function correctly.<br />
<br />
If unsure, say N when using SeaBIOS as payload, Y otherwise.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ALWAYS_LOAD_OPROM || device || bool || || <br />
Always load option ROMs if any are found. The decision to run<br />
the ROM is still determined at runtime, but the distinction<br />
between loading and not running comes into play for CHROMEOS.<br />
<br />
An example where this is required is that VBT (Video BIOS Tables)<br />
are needed for the kernel's display driver to know how a piece of<br />
hardware is configured to be used.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ON_DEVICE_ROM_RUN || device || bool || Run Option ROMs on PCI devices || <br />
Execute Option ROMs stored on PCI/PCIe/AGP devices in coreboot.<br />
<br />
If disabled, only Option ROMs stored in CBFS will be executed by<br />
coreboot. If you are concerned about security, you might want to<br />
disable this option, but it might leave your system in a state of<br />
degraded functionality.<br />
<br />
When using a SeaBIOS payload it runs all option ROMs with much<br />
more complete BIOS interrupt services available than coreboot,<br />
which some option ROMs require in order to function correctly.<br />
<br />
If unsure, say N when using SeaBIOS as payload, Y otherwise.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PCI_OPTION_ROM_RUN_REALMODE || device || bool || Native mode || <br />
If you select this option, PCI Option ROMs will be executed<br />
natively on the CPU in real mode. No CPU emulation is involved,<br />
so this is the fastest, but also the least secure option.<br />
(only works on x86/x64 systems)<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PCI_OPTION_ROM_RUN_YABEL || device || bool || Secure mode || <br />
If you select this option, the x86emu CPU emulator will be used to<br />
execute PCI Option ROMs.<br />
<br />
This option prevents Option ROMs from doing dirty tricks with the<br />
system (such as installing SMM modules or hypervisors), but it is<br />
also significantly slower than the native Option ROM initialization<br />
method.<br />
<br />
This is the default choice for non-x86 systems.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| YABEL_PCI_ACCESS_OTHER_DEVICES || device || bool || Allow Option ROMs to access other devices || <br />
Per default, YABEL only allows Option ROMs to access the PCI device<br />
that they are associated with. However, this causes trouble for some<br />
onboard graphics chips whose Option ROM needs to reconfigure the<br />
north bridge.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| YABEL_PCI_FAKE_WRITING_OTHER_DEVICES_CONFIG || device || bool || Fake success on writing other device's config space || <br />
By default, YABEL aborts when the Option ROM tries to write to other<br />
devices' config spaces. With this option enabled, the write doesn't<br />
follow through, but the Option ROM is allowed to go on.<br />
This can create issues such as hanging Option ROMs (if it depends on<br />
that other register changing to the written value), so test for<br />
impact before using this option.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| YABEL_VIRTMEM_LOCATION || device || hex || Location of YABEL's virtual memory || <br />
YABEL requires 1MB memory for its CPU emulation. This memory is<br />
normally located at 16MB.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| YABEL_DIRECTHW || device || bool || Direct hardware access || <br />
YABEL consists of two parts: It uses x86emu for the CPU emulation and<br />
additionally provides a PC system emulation that filters bad device<br />
and memory access (such as PCI config space access to other devices<br />
than the initialized one).<br />
<br />
When choosing this option, x86emu will pass through all hardware<br />
accesses to memory and I/O devices to the underlying memory and I/O<br />
addresses. While this option prevents Option ROMs from doing dirty<br />
tricks with the CPU (such as installing SMM modules or hypervisors),<br />
they can still access all devices in the system.<br />
Enable this option for a good compromise between security and speed.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PCIEXP_COMMON_CLOCK || device || bool || Enable PCIe Common Clock || <br />
Detect and enable Common Clock on PCIe links.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PCIEXP_ASPM || device || bool || Enable PCIe ASPM || <br />
Detect and enable ASPM on PCIe links.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PCIEXP_CLK_PM || device || bool || Enable PCIe Clock Power Management || <br />
Detect and enable Clock Power Management on PCIe.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| EARLY_PCI_BRIDGE || device || bool || Early PCI bridge || <br />
While coreboot is executing code from ROM, the coreboot resource<br />
allocator has not been running yet. Hence PCI devices living behind<br />
a bridge are not yet visible to the system.<br />
<br />
This option enables static configuration for a single pre-defined<br />
PCI bridge function on bus 0.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PCIEXP_L1_SUB_STATE || device || bool || Enable PCIe ASPM L1 SubState || <br />
Detect and enable ASPM on PCIe links.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SUBSYSTEM_VENDOR_ID || device || hex || Override PCI Subsystem Vendor ID || <br />
This config option will override the devicetree settings for<br />
PCI Subsystem Vendor ID.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SUBSYSTEM_DEVICE_ID || device || hex || Override PCI Subsystem Device ID || <br />
This config option will override the devicetree settings for<br />
PCI Subsystem Device ID.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VGA_BIOS || device || bool || Add a VGA BIOS image || <br />
Select this option if you have a VGA BIOS image that you would<br />
like to add to your ROM.<br />
<br />
You will be able to specify the location and file name of the<br />
image later.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VGA_BIOS_FILE || device || string || VGA BIOS path and filename || <br />
The path and filename of the file to use as VGA BIOS.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VGA_BIOS_ID || device || string || VGA device PCI IDs || <br />
The comma-separated PCI vendor and device ID that would associate<br />
your VGA BIOS to your video card.<br />
<br />
Example: 1106,3230<br />
<br />
In the above example 1106 is the PCI vendor ID (in hex, but without<br />
the "0x" prefix) and 3230 specifies the PCI device ID of the<br />
video card (also in hex, without "0x" prefix).<br />
<br />
Under GNU/Linux you can run `lspci -nn` to list the IDs of your PCI devices.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| INTEL_MBI || device || bool || Add an MBI image || <br />
Select this option if you have an Intel MBI image that you would<br />
like to add to your ROM.<br />
<br />
You will be able to specify the location and file name of the<br />
image later.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MBI_FILE || device || string || Intel MBI path and filename || <br />
The path and filename of the file to use as VGA BIOS.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PXE_ROM || device || bool || Add a PXE ROM image || <br />
Select this option if you have a PXE ROM image that you would<br />
like to add to your ROM.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PXE_ROM_FILE || device || string || PXE ROM filename || <br />
The path and filename of the file to use as PXE ROM.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PXE_ROM_ID || device || string || network card PCI IDs || <br />
The comma-separated PCI vendor and device ID that would associate<br />
your PXE ROM to your network card.<br />
<br />
Example: 10ec,8168<br />
<br />
In the above example 10ec is the PCI vendor ID (in hex, but without<br />
the "0x" prefix) and 8168 specifies the PCI device ID of the<br />
network card (also in hex, without "0x" prefix).<br />
<br />
Under GNU/Linux you can run `lspci -nn` to list the IDs of your PCI devices.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SOFTWARE_I2C || device || bool || Enable I2C controller emulation in software || <br />
This config option will enable code to override the i2c_transfer<br />
routine with a (simple) software emulation of the protocol. This may<br />
be useful for debugging or on platforms where a driver for the real<br />
I2C controller is not (yet) available. The platform code needs to<br />
provide bindings to manually toggle I2C lines.<br />
<br />
||<br />
<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: Display || || || ||<br />
|- bgcolor="#eeeeee"<br />
| FRAMEBUFFER_SET_VESA_MODE || device || bool || Set framebuffer graphics resolution || <br />
Set VESA/native framebuffer mode (needed for bootsplash and graphical framebuffer console)<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FRAMEBUFFER_SET_VESA_MODE || device || bool || framebuffer graphics resolution || <br />
This option sets the resolution used for the coreboot framebuffer (and<br />
bootsplash screen).<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FRAMEBUFFER_KEEP_VESA_MODE || device || bool || Keep VESA framebuffer || <br />
This option keeps the framebuffer mode set after coreboot finishes<br />
execution. If this option is enabled, coreboot will pass a<br />
framebuffer entry in its coreboot table and the payload will need a<br />
framebuffer driver. If this option is disabled, coreboot will switch<br />
back to text mode before handing control to a payload.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOOTSPLASH || device || bool || Show graphical bootsplash || <br />
This option shows a graphical bootsplash screen. The graphics are<br />
loaded from the CBFS file bootsplash.jpg.<br />
<br />
You will be able to specify the location and file name of the<br />
image later.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| BOOTSPLASH_FILE || device || string || Bootsplash path and filename || <br />
The path and filename of the file to use as graphical bootsplash<br />
screen. The file format has to be jpg.<br />
<br />
||<br />
<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: Generic Drivers || || || ||<br />
|- bgcolor="#eeeeee"<br />
| SPI_FLASH || drivers/spi || bool || || <br />
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPI_ATOMIC_SEQUENCING || drivers/spi || bool || || <br />
Select this option if the SPI controller uses "atomic sequencing."<br />
Atomic sequencing is when the sequence of commands is pre-programmed<br />
in the SPI controller. Hardware manages the transaction instead of<br />
software. This is common on x86 platforms.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPI_FLASH_MEMORY_MAPPED || drivers/spi || bool || || <br />
Inform system if SPI is memory-mapped or not.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPI_FLASH_SMM || drivers/spi || bool || SPI flash driver support in SMM || <br />
Select this option if you want SPI flash support in SMM.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPI_FLASH_NO_FAST_READ || drivers/spi || bool || Disable Fast Read command || <br />
Select this option if your setup requires to avoid "fast read"s<br />
from the SPI flash parts.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPI_FLASH_ADESTO || drivers/spi || bool || || <br />
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by Adesto Technologies.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPI_FLASH_AMIC || drivers/spi || bool || || <br />
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by AMIC.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPI_FLASH_ATMEL || drivers/spi || bool || || <br />
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by Atmel.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPI_FLASH_EON || drivers/spi || bool || || <br />
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by EON.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPI_FLASH_GIGADEVICE || drivers/spi || bool || || <br />
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by Gigadevice.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPI_FLASH_MACRONIX || drivers/spi || bool || || <br />
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by Macronix.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPI_FLASH_SPANSION || drivers/spi || bool || || <br />
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by Spansion.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPI_FLASH_SST || drivers/spi || bool || || <br />
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by SST.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPI_FLASH_STMICRO || drivers/spi || bool || || <br />
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by ST MICRO.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPI_FLASH_WINBOND || drivers/spi || bool || || <br />
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by Winbond.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPI_FLASH_FAST_READ_DUAL_OUTPUT_3B || drivers/spi || bool || || <br />
Select this option if your SPI flash supports the fast read dual-<br />
output command (opcode 0x3b) where the opcode and address are sent<br />
to the chip on MOSI and data is received on both MOSI and MISO.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ELOG || drivers/elog || bool || Support for flash based event log || <br />
Enable support for flash based event logging.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ELOG_FLASH_BASE || drivers/elog || hex || Event log offset into flash || <br />
Offset into the flash chip for the ELOG block.<br />
This should be allocated in the FMAP.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ELOG_AREA_SIZE || drivers/elog || hex || Size of Event Log area in flash || <br />
This should be a multiple of flash block size.<br />
<br />
Default is 4K.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ELOG_CBMEM || drivers/elog || bool || Store a copy of ELOG in CBMEM || <br />
This option will have ELOG store a copy of the flash event log<br />
in a CBMEM region and export that address in SMBIOS to the OS.<br />
This is useful if the ELOG location is not in memory mapped flash,<br />
but it means that events added at runtime via the SMI handler<br />
will not be reflected in the CBMEM copy of the log.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ELOG_GSMI || drivers/elog || bool || SMI interface to write and clear event log || <br />
This interface is compatible with the linux kernel driver<br />
available with CONFIG_GOOGLE_GSMI and can be used to write<br />
kernel reset/shutdown messages to the event log.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ELOG_BOOT_COUNT || drivers/elog || bool || Maintain a monotonic boot number in CMOS || <br />
Store a monotonic boot number in CMOS and provide an interface<br />
to read the current value and increment the counter. This boot<br />
counter will be logged as part of the System Boot event.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ELOG_BOOT_COUNT_CMOS_OFFSET || drivers/elog || int || Offset in CMOS to store the boot count || <br />
This value must be greater than 16 bytes so as not to interfere<br />
with the standard RTC region. Requires 8 bytes.<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| USBDEBUG || drivers/usb || bool || USB 2.0 EHCI debug dongle support || <br />
This option allows you to use a so-called USB EHCI Debug device<br />
(such as the Ajays NET20DC, AMIDebug RX, or a system using the<br />
Linux "EHCI Debug Device gadget" driver found in recent kernel)<br />
to retrieve the coreboot debug messages (instead, or in addition<br />
to, a serial port).<br />
<br />
This feature is NOT supported on all chipsets in coreboot!<br />
<br />
It also requires a USB2 controller which supports the EHCI<br />
Debug Port capability.<br />
<br />
See http://www.coreboot.org/EHCI_Debug_Port for an up-to-date list<br />
of supported controllers.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| USBDEBUG_IN_ROMSTAGE || drivers/usb || bool || Enable early (pre-RAM) usbdebug || <br />
Configuring USB controllers in system-agent binary may cause<br />
problems to usbdebug. Disabling this option delays usbdebug to<br />
be setup on entry to ramstage.<br />
<br />
If unsure, say Y.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| USBDEBUG_HCD_INDEX || drivers/usb || int || Index for EHCI controller to use with usbdebug || <br />
Some boards have multiple EHCI controllers with possibly only<br />
one having the Debug Port capability on an external USB port.<br />
<br />
Mapping of this index to PCI device functions is southbridge<br />
specific and mainboard level Kconfig should already provide<br />
a working default value here.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| USBDEBUG_DEFAULT_PORT || drivers/usb || int || Default USB port to use as Debug Port || <br />
Selects which physical USB port usbdebug dongle is connected to.<br />
Setting of 0 means to scan possible ports starting from 1.<br />
<br />
Intel platforms have hardwired the debug port location and this<br />
setting makes no difference there.<br />
<br />
Hence, if you select the correct port here, you can speed up<br />
your boot time. Which USB port number refers to which actual<br />
port on your mainboard (potentially also USB pin headers on<br />
your mainboard) is highly board-specific, and you'll likely<br />
have to find out by trial-and-error.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| USBDEBUG_DONGLE_BEAGLEBONE || drivers/usb || bool || BeagleBone || <br />
Use this to configure the USB hub on BeagleBone board.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| USBDEBUG_DONGLE_BEAGLEBONE_BLACK || drivers/usb || bool || BeagleBone Black || <br />
Use this with BeagleBone Black.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| GIC || drivers/gic || None || || <br />
This option enables GIC support, the ARM generic interrupt controller.<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DRIVERS_UART_OXPCIE || drivers/uart || bool || Oxford OXPCIe952 || <br />
Support for Oxford OXPCIe952 serial port PCIe cards.<br />
Currently only devices with the vendor ID 0x1415 and device ID<br />
0xc158 or 0xc11b will work.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DRIVERS_PS2_KEYBOARD || drivers/pc80 || bool || PS/2 keyboard init || <br />
Enable this option to initialize PS/2 keyboards found connected<br />
to the PS/2 port.<br />
<br />
Some payloads (eg, filo) require this option. Other payloads<br />
(eg, GRUB 2, SeaBIOS, Linux) do not require it.<br />
Initializing a PS/2 keyboard can take several hundred milliseconds.<br />
<br />
If you know you will only use a payload which does not require<br />
this option, then you can say N here to speed up boot time.<br />
Otherwise say Y.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| LPC_TPM || drivers/pc80/tpm || bool || || <br />
Enable this option to enable LPC TPM support in coreboot.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| TPM_TIS_BASE_ADDRESS || drivers/pc80/tpm || hex || TPM Base Address || <br />
This can be used to adjust the TPM memory base address.<br />
The default is specified by the TCG PC Client Specific TPM<br />
Interface Specification 1.2 and should not be changed unless<br />
the TPM being used does not conform to TPM TIS 1.2.<br />
<br />
||<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DRIVERS_EMULATION_QEMU_BOCHS || drivers/emulation/qemu || bool || bochs dispi interface vga driver || <br />
VGA driver for qemu emulated vga cards supporting<br />
the bochs dispi interface. This includes<br />
standard vga, vmware svga and qxl. The default<br />
vga (cirrus) is *not* supported, so you have to<br />
pick another one explicitly via 'qemu -vga $card'.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DRIVER_XPOWERS_AXP209 || drivers/xpowers/axp209 || bool || || <br />
X-Powers AXP902 Power Management Unit<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DRIVER_XPOWERS_AXP209_BOOTBLOCK || drivers/xpowers/axp209 || bool || || <br />
Make AXP209 functionality available in he bootblock.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| INTEL_DP || drivers/intel/gma || bool || || <br />
helper functions for intel display port operations<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| INTEL_DDI || drivers/intel/gma || bool || || <br />
helper functions for intel DDI operations<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DRIVER_TI_TPS65090 || drivers/ti/tps65090 || bool || || <br />
TI TPS65090<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DRIVER_PARADE_PS8625 || drivers/parade/ps8625 || bool || || <br />
Parade ps8625 display port to lvds bridge<br />
<br />
||<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DRIVERS_I2C_RTD2132 || drivers/i2c/rtd2132 || bool || || <br />
Enable support for Realtek RTD2132 DisplayPort to LVDS bridge chip.<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DRIVERS_SIL_3114 || drivers/sil/3114 || bool || Silicon Image SIL3114 || <br />
It sets PCI class to IDE compatible native mode, allowing<br />
SeaBIOS, FILO etc... to boot from it.<br />
<br />
||<br />
<br />
||<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DIGITIZER_AUTODETECT || drivers/lenovo || bool || Autodetect || <br />
The presence of digitizer is inferred from model number stored in<br />
AT24RF chip.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DIGITIZER_PRESENT || drivers/lenovo || bool || Present || <br />
The digitizer is assumed to be present.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DIGITIZER_ABSENT || drivers/lenovo || bool || Absent || <br />
The digitizer is assumed to be absent.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DRIVER_MAXIM_MAX77686 || drivers/maxim/max77686 || bool || || <br />
Maxim MAX77686 power regulator<br />
<br />
||<br />
<br />
||<br />
||<br />
<br />
|- bgcolor="#eeeeee"<br />
| TPM || toplevel || bool || || <br />
Enable this option to enable TPM support in coreboot.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: Console || || || ||<br />
|- bgcolor="#eeeeee"<br />
| BOOTBLOCK_CONSOLE || console || bool || Enable early (bootblock) console output. || <br />
Use console during the bootblock if supported<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SQUELCH_EARLY_SMP || console || bool || Squelch AP CPUs from early console. || <br />
When selected only the BSP CPU will output to early console.<br />
<br />
Console drivers have unpredictable behaviour if multiple threads<br />
attempt to share the same resources without a spinlock.<br />
<br />
If unsure, say Y.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_SERIAL || console || bool || Serial port console output || <br />
Send coreboot debug output to a serial port.<br />
<br />
The type of serial port driver selected based on your configuration is<br />
shown on the following menu line. Supporting multiple different types<br />
of UARTs in one build is not supported.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || I/O mapped, 8250-compatible ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || memory mapped, 8250-compatible ||<br />
|- bgcolor="#eeeeee"<br />
| || || (comment) || || device-specific UART ||<br />
|- bgcolor="#eeeeee"<br />
| TTYS0_BASE || console || hex || || <br />
Map the COM port number to the respective I/O port.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_SERIAL_115200 || console || bool || 115200 || <br />
Set serial port Baud rate to 115200.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_SERIAL_57600 || console || bool || 57600 || <br />
Set serial port Baud rate to 57600.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_SERIAL_38400 || console || bool || 38400 || <br />
Set serial port Baud rate to 38400.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_SERIAL_19200 || console || bool || 19200 || <br />
Set serial port Baud rate to 19200.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_SERIAL_9600 || console || bool || 9600 || <br />
Set serial port Baud rate to 9600.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| TTYS0_BAUD || console || int || || <br />
Map the Baud rates to an integer.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SPKMODEM || console || bool || spkmodem (console on speaker) console output || <br />
Send coreboot debug output through speaker<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_USB || console || bool || USB dongle console output || <br />
Send coreboot debug output to USB.<br />
<br />
Configuration for USB hardware is under menu Generic Drivers.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| ONBOARD_VGA_IS_PRIMARY || console || bool || Use onboard VGA as primary video device || <br />
If not selected, the last adapter found will be used.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_NE2K || console || bool || Network console over NE2000 compatible Ethernet adapter || <br />
Send coreboot debug output to a Ethernet console, it works<br />
same way as Linux netconsole, packets are received to UDP<br />
port 6666 on IP/MAC specified with options bellow.<br />
Use following netcat command: nc -u -l -p 6666<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_NE2K_DST_MAC || console || string || Destination MAC address of remote system || <br />
Type in either MAC address of logging system or MAC address<br />
of the router.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_NE2K_DST_IP || console || string || Destination IP of logging system || <br />
This is IP address of the system running for example<br />
netcat command to dump the packets.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_NE2K_SRC_IP || console || string || IP address of coreboot system || <br />
This is the IP of the coreboot system<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_NE2K_IO_PORT || console || hex || NE2000 adapter fixed IO port address || <br />
This is the IO port address for the IO port<br />
on the card, please select some non-conflicting region,<br />
32 bytes of IO spaces will be used (and align on 32 bytes<br />
boundary, qemu needs broader align)<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_CBMEM || console || bool || Send console output to a CBMEM buffer || <br />
Enable this to save the console output in a CBMEM buffer. This would<br />
allow to see coreboot console output from Linux space.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_CBMEM_BUFFER_SIZE || console || hex || Room allocated for console output in CBMEM || <br />
Space allocated for console output storage in CBMEM. The default<br />
value (128K or 0x20000 bytes) is large enough to accommodate<br />
even the BIOS_SPEW level.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_CBMEM_DUMP_TO_UART || console || bool || Dump CBMEM console on resets || <br />
Enable this to have CBMEM console buffer contents dumped on the<br />
serial output in case serial console is disabled and the device<br />
resets itself while trying to boot the payload.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_QEMU_DEBUGCON || console || bool || QEMU debug console output || <br />
Send coreboot debug output to QEMU's isa-debugcon device:<br />
<br />
qemu-system-x86_64 \<br />
-chardev file,id=debugcon,path=/dir/file.log \<br />
-device isa-debugcon,iobase=0x402,chardev=debugcon<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEFAULT_CONSOLE_LOGLEVEL_8 || console || bool || 8: SPEW || <br />
Way too many details.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEFAULT_CONSOLE_LOGLEVEL_7 || console || bool || 7: DEBUG || <br />
Debug-level messages.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEFAULT_CONSOLE_LOGLEVEL_6 || console || bool || 6: INFO || <br />
Informational messages.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEFAULT_CONSOLE_LOGLEVEL_5 || console || bool || 5: NOTICE || <br />
Normal but significant conditions.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEFAULT_CONSOLE_LOGLEVEL_4 || console || bool || 4: WARNING || <br />
Warning conditions.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEFAULT_CONSOLE_LOGLEVEL_3 || console || bool || 3: ERR || <br />
Error conditions.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEFAULT_CONSOLE_LOGLEVEL_2 || console || bool || 2: CRIT || <br />
Critical conditions.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEFAULT_CONSOLE_LOGLEVEL_1 || console || bool || 1: ALERT || <br />
Action must be taken immediately.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEFAULT_CONSOLE_LOGLEVEL_0 || console || bool || 0: EMERG || <br />
System is unusable.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEFAULT_CONSOLE_LOGLEVEL || console || int || || <br />
Map the log level config names to an integer.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CMOS_POST || console || bool || Store post codes in CMOS for debugging || <br />
If enabled, coreboot will store post codes in CMOS and switch between<br />
two offsets on each boot so the last post code in the previous boot<br />
can be retrieved. This uses 3 bytes of CMOS.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CMOS_POST_OFFSET || console || hex || Offset into CMOS to store POST codes || <br />
If CMOS_POST is enabled then an offset into CMOS must be provided.<br />
If CONFIG_HAVE_OPTION_TABLE is enabled then it will use the value<br />
defined in the mainboard option table.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CMOS_POST_EXTRA || console || bool || Store extra logging info into CMOS || <br />
This will enable extra logging of work that happens between post<br />
codes into CMOS for debug. This uses an additional 8 bytes of CMOS.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CONSOLE_POST || console || bool || Show POST codes on the debug console || <br />
If enabled, coreboot will additionally print POST codes (which are<br />
usually displayed using a so-called "POST card" ISA/PCI/PCI-E<br />
device) on the debug console.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| POST_IO || console || bool || Send POST codes to an IO port || <br />
If enabled, POST codes will be written to an IO port.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| POST_IO_PORT || console || hex || IO port for POST codes || <br />
POST codes on x86 are typically written to the LPC bus on port<br />
0x80. However, it may be desirable to change the port number<br />
depending on the presence of coprocessors/microcontrollers or if the<br />
platform does not support IO in the conventional x86 manner.<br />
<br />
||<br />
<br />
|- bgcolor="#eeeeee"<br />
| HAVE_HARD_RESET || toplevel || bool || || <br />
This variable specifies whether a given board has a hard_reset<br />
function, no matter if it's provided by board code or chipset code.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_MONOTONIC_TIMER || toplevel || bool || || <br />
The board/chipset provides a monotonic timer.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| GENERIC_UDELAY || toplevel || bool || || <br />
The board/chipset uses a generic udelay function utilizing the<br />
monotonic timer.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| TIMER_QUEUE || toplevel || bool || || <br />
Provide a timer queue for performing time-based callbacks.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COOP_MULTITASKING || toplevel || bool || || <br />
Cooperative multitasking allows callbacks to be multiplexed on the<br />
main thread of ramstage. With this enabled it allows for multiple<br />
execution paths to take place when they have udelay() calls within<br />
their code.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| NUM_THREADS || toplevel || int || || <br />
How many execution threads to cooperatively multitask with.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_OPTION_TABLE || toplevel || bool || || <br />
This variable specifies whether a given board has a cmos.layout<br />
file containing NVRAM/CMOS bit definitions.<br />
It defaults to 'n' but can be selected in mainboard/*/Kconfig.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| CBFS_SIZE || toplevel || hex || Size of CBFS filesystem in ROM || <br />
This is the part of the ROM actually managed by CBFS, located at the<br />
end of the ROM (passed through cbfstool -o) on x86 and at at the start<br />
of the ROM (passed through cbfstool -s) everywhere else. Defaults to<br />
span the whole ROM but can be overwritten to make coreboot live<br />
alongside other components (like ChromeOS's vboot/FMAP).<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| VGA || toplevel || bool || || <br />
Build board-specific VGA code.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| GFXUMA || toplevel || bool || || <br />
Enable Unified Memory Architecture for graphics.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_ACPI_TABLES || toplevel || bool || || <br />
This variable specifies whether a given board has ACPI table support.<br />
It is usually set in mainboard/*/Kconfig.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_MP_TABLE || toplevel || bool || || <br />
This variable specifies whether a given board has MP table support.<br />
It is usually set in mainboard/*/Kconfig.<br />
Whether or not the MP table is actually generated by coreboot<br />
is configurable by the user via GENERATE_MP_TABLE.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| HAVE_PIRQ_TABLE || toplevel || bool || || <br />
This variable specifies whether a given board has PIRQ table support.<br />
It is usually set in mainboard/*/Kconfig.<br />
Whether or not the PIRQ table is actually generated by coreboot<br />
is configurable by the user via GENERATE_PIRQ_TABLE.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MAX_PIRQ_LINKS || toplevel || int || || <br />
This variable specifies the number of PIRQ interrupt links which are<br />
routable. On most chipsets, this is 4, INTA through INTD. Some<br />
chipsets offer more than four links, commonly up to INTH. They may<br />
also have a separate link for ATA or IOAPIC interrupts. When the PIRQ<br />
table specifies links greater than 4, pirq_route_irqs will not<br />
function properly, unless this variable is correctly set.<br />
<br />
||<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: System tables || || || ||<br />
|- bgcolor="#eeeeee"<br />
| GENERATE_MP_TABLE || toplevel || bool || Generate an MP table || <br />
Generate an MP table (conforming to the Intel MultiProcessor<br />
specification 1.4) for this board.<br />
<br />
If unsure, say Y.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| GENERATE_PIRQ_TABLE || toplevel || bool || Generate a PIRQ table || <br />
Generate a PIRQ table for this board.<br />
<br />
If unsure, say Y.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| GENERATE_SMBIOS_TABLES || toplevel || bool || Generate SMBIOS tables || <br />
Generate SMBIOS tables for this board.<br />
<br />
If unsure, say Y.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MAINBOARD_SERIAL_NUMBER || toplevel || string || SMBIOS Serial Number || <br />
The Serial Number to store in SMBIOS structures.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MAINBOARD_VERSION || toplevel || string || SMBIOS Version Number || <br />
The Version Number to store in SMBIOS structures.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MAINBOARD_SMBIOS_MANUFACTURER || toplevel || string || SMBIOS Manufacturer || <br />
Override the default Manufacturer stored in SMBIOS structures.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MAINBOARD_SMBIOS_PRODUCT_NAME || toplevel || string || SMBIOS Product name || <br />
Override the default Product name stored in SMBIOS structures.<br />
<br />
||<br />
<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: Payload || || || ||<br />
|- bgcolor="#eeeeee"<br />
| PAYLOAD_NONE || toplevel || bool || None || <br />
Select this option if you want to create an "empty" coreboot<br />
ROM image for a certain mainboard, i.e. a coreboot ROM image<br />
which does not yet contain a payload.<br />
<br />
For such an image to be useful, you have to use 'cbfstool'<br />
to add a payload to the ROM image later.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PAYLOAD_ELF || toplevel || bool || An ELF executable payload || <br />
Select this option if you have a payload image (an ELF file)<br />
which coreboot should run as soon as the basic hardware<br />
initialization is completed.<br />
<br />
You will be able to specify the location and file name of the<br />
payload image later.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PAYLOAD_LINUX || toplevel || bool || A Linux payload || <br />
Select this option if you have a Linux bzImage which coreboot<br />
should run as soon as the basic hardware initialization<br />
is completed.<br />
<br />
You will be able to specify the location and file name of the<br />
payload image later.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PAYLOAD_SEABIOS || toplevel || bool || SeaBIOS || <br />
Select this option if you want to build a coreboot image<br />
with a SeaBIOS payload. If you don't know what this is<br />
about, just leave it enabled.<br />
<br />
See http://coreboot.org/Payloads for more information.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PAYLOAD_FILO || toplevel || bool || FILO || <br />
Select this option if you want to build a coreboot image<br />
with a FILO payload. If you don't know what this is<br />
about, just leave it enabled.<br />
<br />
See http://coreboot.org/Payloads for more information.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PAYLOAD_GRUB2 || toplevel || bool || GRUB2 || <br />
Select this option if you want to build a coreboot image<br />
with a GRUB2 payload. If you don't know what this is<br />
about, just leave it enabled.<br />
<br />
See http://coreboot.org/Payloads for more information.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PAYLOAD_TIANOCORE || toplevel || bool || Tiano Core || <br />
Select this option if you want to build a coreboot image<br />
with a Tiano Core payload. If you don't know what this is<br />
about, just leave it enabled.<br />
<br />
See http://coreboot.org/Payloads for more information.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SEABIOS_STABLE || toplevel || bool || 1.7.5 || <br />
Stable SeaBIOS version<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SEABIOS_MASTER || toplevel || bool || master || <br />
Newest SeaBIOS version<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SEABIOS_PS2_TIMEOUT || toplevel || int || PS/2 keyboard controller initialization timeout (milliseconds) || <br />
Some PS/2 keyboard controllers don't respond to commands immediately<br />
after powering on. This specifies how long SeaBIOS will wait for the<br />
keyboard controller to become ready before giving up.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SEABIOS_THREAD_OPTIONROMS || toplevel || bool || Hardware init during option ROM execution || <br />
Allow hardware init to run in parallel with optionrom execution.<br />
<br />
This can reduce boot time, but can cause some timing<br />
variations during option ROM code execution. It is not<br />
known if all option ROMs will behave properly with this option.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SEABIOS_MALLOC_UPPERMEMORY || toplevel || bool || || <br />
Use the "Upper Memory Block" area (0xc0000-0xf0000) for internal<br />
"low memory" allocations. If this is not selected, the memory is<br />
instead allocated from the "9-segment" (0x90000-0xa0000).<br />
This is not typically needed, but may be required on some platforms<br />
to allow USB and SATA buffers to be written correctly by the<br />
hardware. In general, if this is desired, the option will be<br />
set to 'N' by the chipset Kconfig.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| SEABIOS_VGA_COREBOOT || toplevel || bool || Include generated option rom that implements legacy VGA BIOS compatibility || <br />
Coreboot can initialize the GPU of some mainboards.<br />
<br />
After initializing the GPU, the information about it can be passed to the payload.<br />
Provide an option rom that implements this legacy VGA BIOS compatibility requirement.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| GRUB2_MASTER || toplevel || bool || HEAD || <br />
Newest GRUB2 version<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FILO_STABLE || toplevel || bool || 0.6.0 || <br />
Stable FILO version<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FILO_MASTER || toplevel || bool || HEAD || <br />
Newest FILO version<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PAYLOAD_FILE || toplevel || string || Payload path and filename || <br />
The path and filename of the ELF executable file to use as payload.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PAYLOAD_FILE || toplevel || string || Linux path and filename || <br />
The path and filename of the bzImage kernel to use as payload.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| PAYLOAD_FILE || toplevel || string || Tianocore firmware volume || <br />
The result of a corebootPkg build<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| COMPRESSED_PAYLOAD_LZMA || toplevel || bool || Use LZMA compression for payloads || <br />
In order to reduce the size payloads take up in the ROM chip<br />
coreboot can compress them using the LZMA algorithm.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| LINUX_COMMAND_LINE || toplevel || string || Linux command line || <br />
A command line to add to the Linux kernel.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| LINUX_INITRD || toplevel || string || Linux initrd || <br />
An initrd image to add to the Linux kernel.<br />
<br />
||<br />
<br />
|- bgcolor="#6699dd"<br />
! align="left" | Menu: Debugging || || || ||<br />
|- bgcolor="#eeeeee"<br />
| GDB_STUB || toplevel || bool || GDB debugging support || <br />
If enabled, you will be able to set breakpoints for gdb debugging.<br />
See src/arch/x86/lib/c_start.S for details.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| GDB_WAIT || toplevel || bool || Wait for a GDB connection || <br />
If enabled, coreboot will wait for a GDB connection.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| FATAL_ASSERTS || toplevel || bool || Halt when hitting a BUG() or assertion error || <br />
If enabled, coreboot will call hlt() on a BUG() or failed ASSERT().<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEBUG_CBFS || toplevel || bool || Output verbose CBFS debug messages || <br />
This option enables additional CBFS related debug messages.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEBUG_RAM_SETUP || toplevel || bool || Output verbose RAM init debug messages || <br />
This option enables additional RAM init related debug messages.<br />
It is recommended to enable this when debugging issues on your<br />
board which might be RAM init related.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEBUG_CAR || toplevel || bool || Output verbose Cache-as-RAM debug messages || <br />
This option enables additional CAR related debug messages.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEBUG_PIRQ || toplevel || bool || Check PIRQ table consistency || <br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEBUG_SMBUS || toplevel || bool || Output verbose SMBus debug messages || <br />
This option enables additional SMBus (and SPD) debug messages.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEBUG_SMI || toplevel || bool || Output verbose SMI debug messages || <br />
This option enables additional SMI related debug messages.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEBUG_SMM_RELOCATION || toplevel || bool || Debug SMM relocation code || <br />
This option enables additional SMM handler relocation related<br />
debug messages.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEBUG_MALLOC || toplevel || bool || Output verbose malloc debug messages || <br />
This option enables additional malloc related debug messages.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEBUG_ACPI || toplevel || bool || Output verbose ACPI debug messages || <br />
This option enables additional ACPI related debug messages.<br />
<br />
Note: This option will slightly increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| REALMODE_DEBUG || toplevel || bool || Enable debug messages for option ROM execution || <br />
This option enables additional x86emu related debug messages.<br />
<br />
Note: This option will increase the time to emulate a ROM.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| X86EMU_DEBUG || toplevel || bool || Output verbose x86emu debug messages || <br />
This option enables additional x86emu related debug messages.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| X86EMU_DEBUG_JMP || toplevel || bool || Trace JMP/RETF || <br />
Print information about JMP and RETF opcodes from x86emu.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| X86EMU_DEBUG_TRACE || toplevel || bool || Trace all opcodes || <br />
Print _all_ opcodes that are executed by x86emu.<br />
<br />
WARNING: This will produce a LOT of output and take a long time.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| X86EMU_DEBUG_PNP || toplevel || bool || Log Plug&amp;Play accesses || <br />
Print Plug And Play accesses made by option ROMs.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| X86EMU_DEBUG_DISK || toplevel || bool || Log Disk I/O || <br />
Print Disk I/O related messages.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| X86EMU_DEBUG_PMM || toplevel || bool || Log PMM || <br />
Print messages related to POST Memory Manager (PMM).<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| X86EMU_DEBUG_VBE || toplevel || bool || Debug VESA BIOS Extensions || <br />
Print messages related to VESA BIOS Extension (VBE) functions.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| X86EMU_DEBUG_INT10 || toplevel || bool || Redirect INT10 output to console || <br />
Let INT10 (i.e. character output) calls print messages to debug output.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| X86EMU_DEBUG_INTERRUPTS || toplevel || bool || Log intXX calls || <br />
Print messages related to interrupt handling.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| X86EMU_DEBUG_CHECK_VMEM_ACCESS || toplevel || bool || Log special memory accesses || <br />
Print messages related to accesses to certain areas of the virtual<br />
memory (e.g. BDA (BIOS Data Area) or interrupt vectors)<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| X86EMU_DEBUG_MEM || toplevel || bool || Log all memory accesses || <br />
Print memory accesses made by option ROM.<br />
Note: This also includes accesses to fetch instructions.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| X86EMU_DEBUG_IO || toplevel || bool || Log IO accesses || <br />
Print I/O accesses made by option ROM.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| X86EMU_DEBUG_TIMINGS || toplevel || bool || Output timing information || <br />
Print timing information needed by i915tool.<br />
<br />
If unsure, say N.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEBUG_TPM || toplevel || bool || Output verbose TPM debug messages || <br />
This option enables additional TPM related debug messages.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEBUG_SPI_FLASH || toplevel || bool || Output verbose SPI flash debug messages || <br />
This option enables additional SPI flash related debug messages.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEBUG_USBDEBUG || toplevel || bool || Output verbose USB 2.0 EHCI debug dongle messages || <br />
This option enables additional USB 2.0 debug dongle related messages.<br />
<br />
Select this to debug the connection of usbdebug dongle. Note that<br />
you need some other working console to receive the messages.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEBUG_INTEL_ME || toplevel || bool || Verbose logging for Intel Management Engine || <br />
Enable verbose logging for Intel Management Engine driver that<br />
is present on Intel 6-series chipsets.<br />
||<br />
|- bgcolor="#eeeeee"<br />
| TRACE || toplevel || bool || Trace function calls || <br />
If enabled, every function will print information to console once<br />
the function is entered. The syntax is ~0xaaaabbbb(0xccccdddd)<br />
the 0xaaaabbbb is the actual function and 0xccccdddd is EIP<br />
of calling function. Please note some printk releated functions<br />
are omitted from trace to have good looking console dumps.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| DEBUG_COVERAGE || toplevel || bool || Debug code coverage || <br />
If enabled, the code coverage hooks in coreboot will output some<br />
information about the coverage data that is dumped.<br />
<br />
||<br />
<br />
|- bgcolor="#eeeeee"<br />
| POWER_BUTTON_DEFAULT_ENABLE || toplevel || bool || || <br />
Select when the board has a power button which can optionally be<br />
disabled by the user.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| POWER_BUTTON_DEFAULT_DISABLE || toplevel || bool || || <br />
Select when the board has a power button which can optionally be<br />
enabled by the user, e.g. when the board ships with a jumper over<br />
the power switch contacts.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| POWER_BUTTON_FORCE_ENABLE || toplevel || bool || || <br />
Select when the board requires that the power button is always<br />
enabled.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| POWER_BUTTON_FORCE_DISABLE || toplevel || bool || || <br />
Select when the board requires that the power button is always<br />
disabled, e.g. when it has been hardwired to ground.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| POWER_BUTTON_IS_OPTIONAL || toplevel || bool || || <br />
Internal option that controls ENABLE_POWER_BUTTON visibility.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| REG_SCRIPT || toplevel || bool || || <br />
Internal option that controls whether we compile in register scripts.<br />
<br />
||<br />
|- bgcolor="#eeeeee"<br />
| MAX_REBOOT_CNT || toplevel || int || || <br />
Internal option that sets the maximum number of bootblock executions allowed<br />
with the normal image enabled before assuming the normal image is defective<br />
and switching to the fallback image.<br />
<br />
||<br />
|}</div>Stepanhttps://www.coreboot.org/index.php?title=EHCI_Debug_Port&diff=15981EHCI Debug Port2015-04-05T23:07:45Z<p>Stepan: /* More information */</p>
<hr />
<div>[[Image:PLX_NET20DC.jpg|thumb|right|Ajays NET20DC USB Debug Device.]]<br />
<br />
Serial ports have been the primary means of early debugging of new coreboot ports. New hardware doesn't always have a serial port and another method for early debugging is needed.<br />
<br />
The '''EHCI Debug Port''' is an optional capability of EHCI controllers which can be used for that purpose.<br />
<br />
All USB2 host controllers are EHCI controllers. The debug port provides a mode of operation that requires neither RAM nor a full USB stack. A handful of registers in the EHCI controller PCI configuration and BAR address space are used for all communication. All three transfer types are supported (OUT/SETUP/IN) but transfers can only be a maximum of 8 bytes and only one specific physical USB port can be used. A Debug Class compliant device is the only supported USB function that can be communicated with.<br />
<br />
While the '''Debug Class''' functional spec describes a device communicating over USB also with the debugging host (aka remote) it would be very possible to make a Debug Class device with a regular serial port on the other end. One thing to watch out for is that such a device might not be able to handle the same throughput as the debug port itself and hence may lose data unless it can do some buffering.<br />
<br />
== Supported chipsets ==<br />
<br />
The following southbridges have USB debug support in coreboot:<br />
<br />
{| border="0" style="font-size: smaller" valign="top"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Vendor<br />
! align="left" | Southbridge<br />
! align="left" | Status<br />
! align="left" | Comments<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| SB600<br />
| style="background:lime" | OK<br />
| Tested by [[User:Uwe|Uwe Hermann]].<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| SB700<br />
| style="background:orange" | WIP<br />
| Probably won't work, a patch is being prepared.<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| SB900<br />
| style="background:lime" | OK<br />
| Tested on HP Pavilion m6 1035dx<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| A85X (Hudson D4)<br />
| style="background:lime" | OK<br />
| Tested by [[User:Ranma|Tobias Diedrich]] on ASUS F2A85M-LE.<br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel<br />
| 82801GX (ICH7)<br />
| style="background:lime" | OK<br />
| Tested by [[User:SvenS|Sven Schnelle]] on Lenovo Thinkpad X60/T60. <br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| NVIDIA<br />
| MCP55<br />
| style="background:lime" | OK<br />
| Tested by [[User:Uwe|Uwe Hermann]]. Any physical USB port will work, as the code tries all ports until the one with the attached USB Debug device is found.<br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| SiS<br />
| SiS966<br />
| style="background:yellow" | Untested<br />
| '''Note:''' It's unclear if the chipset actually has EHCI Debug Port functionality, and (if yes), whether the current coreboot code supports it properly (or whether it's just copy-pasted code from another chipset).<br />
<br />
|}<br />
<br />
== Finding the USB debug port ==<br />
<br />
Generally, each EHCI controller can offer at most one debug port. That port corresponds to a fixed physical USB port. Locating that physical port without software is rather difficult because you need to look at lots of information.<br />
<br />
* <code>sudo lshw</code> can be used to find EHCI cabpable USB ports. It may yield something like:<br />
<pre><br />
*-usb:1<br />
description: USB controller<br />
product: MCP55 USB Controller<br />
vendor: NVIDIA Corporation<br />
physical id: 2.1<br />
bus info: pci@0000:00:02.1<br />
version: a2<br />
width: 32 bits<br />
clock: 66MHz<br />
capabilities: debug pm ehci bus_master cap_list<br />
configuration: driver=ehci_hcd latency=0 maxlatency=1 mingnt=3<br />
resources: irq:22 memory:ee204000-ee2040ff<br />
</pre><br />
* As <code>dmesg</code> are part of the core system it can be used from Live distributions that often protect the filesystem from file execution which means that scripts cannot be used. The easiest way to locate the physical USB port that has EHCI debug support can be verified by doing the following:<br />
** <code>sudo dmesg -c</code><br />
** Plug a USB flash memory<br />
** <code>dmesg | tail -22 | grep ehci</code><br />
* Carl-Daniel Hailfinger [http://www.coreboot.org/pipermail/coreboot/2008-September/038618.html has written] [http://www.coreboot.org/pipermail/coreboot/attachments/20080909/ae11c291/attachment.sh a script] which can help finding that port. An [http://www.coreboot.org/pipermail/coreboot/attachments/20140530/245547f8/attachment.sh updated script] was posted [http://www.coreboot.org/pipermail/coreboot/2014-May/078022.html here] on May 30 2014.<br />
<br />
== Using the EHCI debug port ==<br />
<br />
=== usb_debug kernel module and minicom ===<br />
<br />
To get a USB debug console, enable both '''CONFIG_USBDEBUG''' and '''CONFIG_CONSOLE_USB''' (menu option '''USB 2.0 EHCI debug dongle support''') in coreboot's kconfig.<br />
<br />
In case your system has more than one debug-capable EHCI, you can select the index as CONFIG_USBDEBUG_HCD_INDEX, with a southbridge-specific value (on AMD Hudson, 0 and 1 both indicate the first port, 2 is the second port).<br />
<br />
On your "host PC" you need a Linux system which is recent enough to provide the '''usb_debug''' kernel module. When you attach the Ajays Net20DC device to your host PC, it will create a '''/dev/ttyUSB0''' device to which you can connect as usual using any serial terminal program, e.g. '''minicom''' (115200, 8n1).<br />
<br />
TODO: Is the Baud rate actually configurable somewhere?<br />
<br />
You must connect the NET20DC to a special USB port on your coreboot target board (not all of the USB ports will work!), often this is USB port 1. If in doubt, try all available ports to check which one works on your board.<br />
<br />
Then you can power up your coreboot target board and you should see the usual coreboot bootlog in minicom on your host PC.<br />
<br />
=== usb_debug_io.c ===<br />
<br />
As an alternative, you can also use [http://tracker.coreboot.org/trac/coreboot/ticket/57 this small libusb-based user-space program] on the host PC to retrieve the coreboot logs.<br />
<br />
== Hardware capability ==<br />
<br />
The Debug Port is optional, please check if EHCI controllers near you support it:<br />
<br />
$ '''for i in $(lspci|grep EHCI|cut -f1 -d' ') ; do<br />
$ ''' lspci -vs $i'''<br />
$ '''done'''<br />
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) (prog-if 20 [EHCI])<br />
Subsystem: IBM Unknown device 0566<br />
Flags: bus master, medium devsel, latency 0, IRQ 5<br />
Memory at b0000000 (32-bit, non-prefetchable) [size=1K]<br />
Capabilities: [50] Power Management version 2<br />
Capabilities: [58] '''Debug port'''<br />
<br />
Look for a line like the last one above. Please include the PCI device ID too:<br />
<br />
$ '''for i in $(lspci|grep EHCI|cut -f1 -d' ') ; do<br />
$ ''' lspci -ns $i'''<br />
$ '''done'''<br />
00:1d.7 0c03: 8086:265c (rev 03)<br />
<br />
If your controller isn't already listed below then please add it or send an email to the [[Mailinglist|mailing list]] if you don't have a wiki account yet and want one, or want us to add your controller to the page.<br />
<br />
=== Controllers verified to have the debug port capability ===<br />
<br />
* 10b9:5239 ALi Corporation USB 2.0 (USB PCI card)<br />
* 8086:24cd Intel ICH4/ICH4-M<br />
* 8086:24dd Intel ICH5<br />
* 8086:265c Intel ICH6<br />
* 8086:268c Intel 631xESB/632xESB/3100 Chipset (rev 09) (in Dell PE 1950)<br />
* 8086:27cc Intel ICH7<br />
* 8086:2836 Intel ICH8<br />
* 8086:283a Intel ICH8<br />
* 8086:293a Intel ICH9 (rev 2)<br />
* 8086:3a3a Intel ICH10<br />
* 8086:3a3c Intel ICH10<br />
* 10de:0088 NVIDIA MCP2A (rev a2)<br />
* 10de:005b NVIDIA CK804 (rev a3)<br />
* 10de:026e NVIDIA MCP51 (rev a3)<br />
* 10de:036d NVIDIA MCP55 (rev a2)<br />
* 10de:03f2 NVIDIA MCP61 (rev a3)<br />
* 1002:4386 ATI/AMD SB600<br />
* 1002:4396 ATI/AMD SB700<br />
* 1022:7808 AMD A85X<br />
* 1106:3104 VIA VX800 (rev 90)<br />
<br />
=== Controllers verified to lack the debug port capability ===<br />
<br />
* 1033:00e0 NEC Corporation EHCI (rev 02) (Compaq part)<br />
* 1106:3104 VIA Technologies EHCI (rev 82, rev 63, rev 86)<br />
* 1002:4373 ATI Technologies Inc IXP SB400 USB2 Host Controller (rev 80)<br />
* 1022:2095 Advanced Micro Devices [AMD] CS5536 [Geode companion] EHCI (rev 02)<br />
* 8086:24cd Intel Corporation 82801DB/DBM (ICH4/ICH4-M) EHCI (rev 01)<br />
* 1039:7002 SiS EHCI (rev 00)<br />
<br />
== DIY / BeagleBone Black ==<br />
<br />
=== EHCI Debug gadget driver ===<br />
If you have a device running GNU/Linux that has an usb device port, you could then try to use the [[EHCI Gadget Debug]].<br />
Note that it's not guaranteed to work on old kernels, and may be dependant on the usb device/otg controller driver.<br />
<br />
You can make your own usb debug dongle, see [[DIY EHCI debug dongle]].<br />
<br />
A BeagleBone Black with a 5v power supply can achieve this. [https://johnlewis.ie/coreboot-ehci-debug-gadget-demonstration/] (John Lewis)<br />
<br />
== Commercial Devices/Dongles ==<br />
<br />
To be able to use the debug port it needs to be connected to a compatible device.<br />
There are two commercial devices available which can use the EHCI Debug Port, the '''NET20DC''' and the '''AMIDebug RX'''.<br />
<br />
=== NET20DC ===<br />
<br />
* [http://web.archive.org/web/20080219120613/http://www.plxtech.com/products/NET2000/NET20DC/default.asp http://www.plxtech.com/products/NET2000/NET20DC/default.asp] (archive.org)<br />
* http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=12083<br />
* http://www.semiconductorstore.com/pages/asp/supplier.asp?pl=0121<br />
* http://www.ajaystech.com/net20dc.htm<br />
* http://www.ajaystech.com/resources.htm<br />
<br />
=== AMIDebug RX ===<br />
<br />
* http://www.ami.com/amidebugrx/<br />
<br />
== More information ==<br />
<br />
* [http://www.intel.com/technology/usb/download/ehci-r10.pdf EHCI 1.0 spec] (PDF) &mdash; The Debug Port is described in Appendix C.<br />
* [http://developer.intel.com/technology/usb/download/DebugDeviceSpec_R090.pdf Debug Class functional spec] (PDF) &mdash; This is what has to be connected to the EHCI controller.<br />
* [http://www.intel.com/technology/magazine/computing/it09021.pdf Intel Developer UPDATE Magazine on USB debugging] (PDF) &mdash; ''dead URL''<br />
* [http://tracker.coreboot.org/trac/coreboot/ticket/57 libusb host program for PLX NET20DC debug device]<br />
* [http://lkml.org/lkml/2006/12/4/3 Linux x86_64 early USB Debug Port support]<br />
* http://coreboot.org/pipermail/coreboot/2006-December/thread.html#17480<br />
* http://lkml.org/lkml/2006/12/1/214<br />
* http://www.usb.org/developers/presentations/pres0602/john_keys.pdf<br />
* [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5c05917e7fe313a187ad6ebb94c1c6cf42862a0b Linux early USB Debug Port support finally commited]<br />
* [http://www.kernel.org/doc/Documentation/x86/earlyprintk.txt early printk support in Linux]<br />
* http://www.spinics.net/lists/linux-usb/msg32912.html (Linux USB EHCI Debug Port device gadget)<br />
* http://cs.usfca.edu/~cruse/cs698s10/ - various EHCI debug port and Ajays resources</div>Stepanhttps://www.coreboot.org/index.php?title=Flashmap&diff=15589Flashmap2015-02-12T00:15:14Z<p>Stepan: /* How do we fix it (the solution being pursued) */</p>
<hr />
<div>''or...''<br />
=Toward a unified representation for the layout of coreboot flash images=<br />
'''N.B.''' The changes described herein are being made as part of the Chromium OS project; as such, they will initially be committed to the project's own fork of the main coreboot repository, which is available at [https://chromium.googlesource.com/chromiumos/third_party/coreboot https://chromium.googlesource.com/chromiumos/third_party/coreboot]. Unless otherwise noted, the paths and processes described throughout this page are as they exist(ed) in a checkout of the master branch of the Chromium OS sources as they appeared at the beginning of 2015. One of the guiding design principles is to keep the tools general enough that they will be helpful to others, and the resulting work will be upstreamed to the main repository once it has been regression-tested in the context of Chromium OS hardware.<br />
<br />
==How it's currently done (how the Chromium OS project presently constructs firmware images)==<br />
Most Intel-based Chromium OS devices currently use an 8 MB firmware image that includes---among other things---the Intel ME firmware, a copy of coreboot including the ramstage and depthcharge (bootloader) payload, two additional copies of the ramstage and bootloader payload, and a separate SeaBIOS payload. The primary description of this format exists in board-specific flattened device tree files, which are used by a script called [https://chromium.googlesource.com/chromiumos/platform/dev-util/+/master/host/cros_bundle_firmware cros_bundle_firmware] to modify the image produced by the coreboot build system. For instance, the layout of the Panther board's firmware exists at [https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/master/board/panther/fmap.dts https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/master/board/panther/fmap.dts], and results in a final image that looks like this:<br />
{| class="wikitable"<br />
! Section<br />
! Offset<br />
! Contents<br />
! Original source<br />
! Packaging procedure<br />
! Coreboot Kconfig entr[yi](es)<br />
|-<br />
| rowspan="8" | RO<br />
|-<br />
| 0x700000<br />
| Boot (coreboot image)<br />
| coreboot.rom (coreboot build system)<br />
| cros_bundle_firmware helper [https://chromium.googlesource.com/chromiumos/platform/dev-util/+/master/host/lib/bundle_firmware.py#967 adds] depthcharge.payload and [https://chromium.googlesource.com/chromiumos/platform/dev-util/+/master/host/lib/fdt.py#693 compiled] (then [https://chromium.googlesource.com/chromiumos/platform/dev-util/+/master/host/lib/bundle_firmware.py#1072 mod] [https://chromium.googlesource.com/chromiumos/platform/dev-util/+/master/host/cros_bundle_firmware#96 ified]) version of fmap.dts to the existing CBFS<br />
| <code>CONFIG_CMOS_POST_OFFSET</code>, <code>CONFIG_CBFS_SIZE</code><br />
|-<br />
| 0x611000<br />
| GBB (Google Binary Block)<br />
| chromeos-config section of fmap.dts<br />
| cros_bundle_firmware [https://chromium.googlesource.com/chromiumos/platform/dev-util/+/master/host/lib/bundle_firmware.py#389 generates] and inserts it<br />
|-<br />
| 0x610840<br />
| (Reserved)<br />
|-<br />
| 0x610800<br />
| FWID (Firmware ID)<br />
|-<br />
| 0x610000<br />
| FMAP (Flash MAP)<br />
|-<br />
| 0x604000<br />
| (Reserved)<br />
|-<br />
| 0x600000<br />
| RO-VPD (Vital Product Data)<br />
|-<br />
| rowspan="4" |<br />
|-<br />
| 0x400000<br />
| Legacy (SeaBIOS image)<br />
|-<br />
| 0x3fa000<br />
| (Reserved)<br />
|-<br />
| 0x3f8000<br />
| RW-VPD (Vital Product Data)<br />
|-<br />
| rowspan="3" | RW-shared<br />
|-<br />
| 0x3f6000<br />
| Vblock-dev (third-party kernel signing keys)<br />
|-<br />
| 0x3f4000<br />
| Shared-data (RW firmware calibration data)<br />
|-<br />
| rowspan="3" |<br />
|-<br />
| 0x3f0000<br />
| ELOG (Event LOG)<br />
|-<br />
| 0x3e0000<br />
| MRC-cache (Memory Reference Code training data)<br />
|-<br />
| rowspan="4" | RW-B<br />
|-<br />
| 0x3dffc0<br />
| FWID-B<br />
|-<br />
| 0x300000<br />
| Main-B (copy of coreboot ramstage and payload)<br />
|-<br />
| 0x2f0000<br />
| Vblock-B (signing keys)<br />
|-<br />
| rowspan="4" | RW-A<br />
|-<br />
| 0x2effc0<br />
| FWID-A<br />
|-<br />
| 0x210000<br />
| Main-A (copy of coreboot ramstage and payload)<br />
|-<br />
| 0x200000<br />
| Vblock-A (signing keys)<br />
|-<br />
| rowspan="3" | FW-descriptor<br />
|-<br />
| 0x001000<br />
| ME (Intel Management Engine firmware blob)<br />
|-<br />
| 0x000000<br />
| FD (Intel Firmware Descriptor header)<br />
|}<br />
<br />
==What's so bad about that (the pitfalls of this build model that we hope to solve)==<br />
<br />
==Why you should care (how this pertains to all coreboot users)==<br />
<br />
==How do we fix it (the solution being pursued)==</div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15496Code of Conduct2015-01-20T22:17:07Z<p>Stepan: /* Consequences of Unacceptable Behavior */</p>
<hr />
<div></div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15495Code of Conduct2015-01-20T22:13:24Z<p>Stepan: /* Unacceptable Behavior */</p>
<hr />
<div></div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15113Code of Conduct2015-01-09T00:39:49Z<p>Stepan: Protected "Code of Conduct" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))</p>
<hr />
<div></div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15112Code of Conduct2015-01-09T00:38:37Z<p>Stepan: </p>
<hr />
<div></div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15111Code of Conduct2015-01-09T00:37:41Z<p>Stepan: /* If You Witness or Are Subject to Unacceptable Behavior */</p>
<hr />
<div></div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15110Code of Conduct2015-01-09T00:37:25Z<p>Stepan: /* Consequences of Unacceptable Behavior */</p>
<hr />
<div></div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15109Code of Conduct2015-01-09T00:36:55Z<p>Stepan: /* Unacceptable Behavior */</p>
<hr />
<div></div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15108Code of Conduct2015-01-09T00:36:17Z<p>Stepan: /* Mailing list and chat etiquette */</p>
<hr />
<div></div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15107Code of Conduct2015-01-09T00:35:36Z<p>Stepan: /* Mailing list and chat etiquette */</p>
<hr />
<div></div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15106Code of Conduct2015-01-09T00:34:42Z<p>Stepan: /* Consequences of Unacceptable Behavior */</p>
<hr />
<div></div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15105Code of Conduct2015-01-09T00:28:17Z<p>Stepan: </p>
<hr />
<div></div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15104Code of Conduct2015-01-09T00:13:00Z<p>Stepan: </p>
<hr />
<div></div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15103Code of Conduct2015-01-09T00:12:27Z<p>Stepan: Replaced content with "This code of conduct outlines our rules and expectations for everybody participating in the coreboot community."</p>
<hr />
<div>This code of conduct outlines our rules and expectations for everybody participating in the coreboot community.</div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15102Code of Conduct2015-01-09T00:12:05Z<p>Stepan: </p>
<hr />
<div></div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15101Code of Conduct2015-01-09T00:11:37Z<p>Stepan: </p>
<hr />
<div></div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15100Code of Conduct2015-01-09T00:11:07Z<p>Stepan: </p>
<hr />
<div></div>Stepanhttps://www.coreboot.org/index.php?title=Code_of_Conduct&diff=15099Code of Conduct2015-01-09T00:08:42Z<p>Stepan: Created page with "This code of conduct outlines our rules and expectations for everybody participating in the coreboot community. = Mailing list and chat etiquette = We have a friendly and pr..."</p>
<hr />
<div></div>Stepan