Patrick Rudolph has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/33664
Change subject: Documentation: Update CBFS
......................................................................
Documentation: Update CBFS
Update some parts to match current implementation.
Change-Id: I84d07ae1c5c1ded2b9ab5934e2babbbabb749440
---
M Documentation/lib/cbfs.md
M Documentation/lib/payloads/selfboot.md
2 files changed, 46 insertions(+), 34 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/64/33664/1
diff --git a/Documentation/lib/cbfs.md b/Documentation/lib/cbfs.md
index 83d8b44..ce87b78 100644
--- a/Documentation/lib/cbfs.md
+++ b/Documentation/lib/cbfs.md
@@ -7,7 +7,7 @@
## Introduction
-This document describes the coreboot CBFS specification (from here
+This document describes the coreboot filesystem specification (from here
referred to as CBFS). CBFS is a scheme for managing independent chunks
of data in a system ROM. Though not a true filesystem, the style and
concepts are similar.
@@ -15,7 +15,7 @@
## Architecture
-The CBFS architecture looks like the following:
+The CBFS on x86 architecture looks like the following:
```
/---------------\ <-- Start of ROM
@@ -49,11 +49,11 @@
The CBFS architecture consists of a binary associated with a physical
ROM disk referred hereafter as the ROM. A number of independent of
-components, each with a header prepended on to data are located within
-the ROM. The components are nominally arranged sequentially, though they
+components, each with a header prepended on to data are located within
+the ROM. The components are nominally arranged sequentially, though they
are aligned along a pre-defined boundary.
-The bootblock occupies the last 20k of the ROM. Within
+On x86 legacy the bootblock occupies the last 20k of the ROM. Within
the bootblock is a master header containing information about the ROM
including the size, alignment of the components, and the offset of the
start of the first CBFS component within the ROM.
@@ -62,14 +62,13 @@
The master header contains essential information about the ROM that is
used by both the CBFS implementation within coreboot at runtime as well
-as host based utilities to create and manage the ROM. The master header
-will be located somewhere within the bootblock (last 20k of the ROM). A
-pointer to the location of the header will be located at offset
--4 from the end of the ROM. This translates to address 0xFFFFFFFC on a
-normal x86 system. The pointer will be to physical memory somewhere
-between - 0xFFFFB000 and 0xFFFFFFF0. This makes it easier for coreboot
-to locate the header at run time. Build time utilities will
-need to read the pointer and do the appropriate math to locate the header.
+as host based utilities to create and manage the ROM. The master header
+will be located at the start of CBFS. A pointer to the location of the
+header will be located at offset -4 from the end of the ROM.
+This translates to address 0xFFFFFFFC on a normal x86 system.
+This makes it easier for coreboot to locate the header at run time.
+Build time utilities will need to read the pointer and do the appropriate
+math to locate the header.
The following is the structure of the master header:
@@ -114,16 +113,16 @@
for.
## Bootblock
-The bootblock is a mandatory component in the ROM. It is located in the
-last 20k of the ROM space, and contains, among other things, the location of the
-master header and the entry point for the loader firmware. The bootblock
-does not have a component header attached to it.
+The bootblock is a mandatory component in the ROM. On x86 legacy it is located
+at the end of the CBFS, and contains, among other things, the location of the
+master header and the entry point for the loader firmware. On other
+architectures the bootblock might not be part of the CBFS.
## Components
CBFS components are placed in the ROM starting at 'offset' specified in
-the master header and ending at the bootblock. Thus the total size
-available for components in the ROM is (ROM size - 20k - 'offset').
+the master header and ending at the end of the CBFS. Thus the total size
+available for components in the ROM is (ROM size - 'offset').
Each CBFS component is to be aligned according to the 'align' value in the
header.
Thus, if a component of size 1052 is located at offset 0 with an 'align'
@@ -208,10 +207,10 @@
#### Stages
-Stages are code loaded by coreboot during the boot process. They are
-essential to a successful boot. Stages are comprised of a single blob
+Stages are code loaded by coreboot during the boot process. They are
+essential to a successful boot. Stages are comprised of a single blob
of binary data that is to be loaded into a particular location in memory
-and executed. The uncompressed header contains information about how
+and executed. The uncompressed header contains information about how
large the data is, and where it should be placed, and what additional memory
needs to be cleared.
@@ -244,8 +243,8 @@
`compression` is an integer defining how the data is compressed. There
are three compression types defined by this version of the standard:
-none (0x0), lzma (0x1), and nrv2b (0x02, deprecated), though additional
-types may be added assuming that coreboot understands how to handle the scheme.
+none (0x0), lzma (0x1), and lz4 (0x02), though additional types may be
+added assuming that coreboot understands how to handle the scheme.
`entry` is a 64 bit value indicating the location where the program
counter should jump following the loading of the stage. This should be
@@ -271,13 +270,13 @@
#### Payloads
Payloads are loaded by coreboot following the boot process.
+The default payloads supported by coreboot are [SELF] payloads.
-Stages are assigned a component value of 0x20. When coreboot sees this
+[SELF] stages are assigned a component value of 0x20. When coreboot sees this
component type, it knows that it should pass the data to a sub-function
-that will process the payload. Furthermore, other run time applications such
-as 'bayou' may easily index all available payloads
-on the system by searching for the payload type.
-
+that will process the payload. Furthermore, other run time applications such
+as 'bayou' may easily index all available payloads on the system by searching
+for the payload type.
The following is the format of a stage component:
@@ -338,9 +337,9 @@
`compression` is the compression scheme for the segment. Each segment can
be independently compressed. There are three compression types defined by
-this version of the standard: none (0x0), lzma (0x1), and nrv2b
-(0x02, deprecated), though additional types may be added assuming that
-coreboot understands how to handle the scheme.
+this version of the standard: none (0x0), lzma (0x1), and lz4 (0x02), though
+additional types may be added assuming that coreboot understands how to handle
+the scheme.
`offset` is the address of the data within the component, starting from
the component header.
@@ -355,6 +354,13 @@
The data will located immediately following the last segment.
+#### FIT payload
+
+A payload of type [FIT] is supported on some architectures.
+
+[FIT] stages are assigned a component value of 0x21 and do not support
+compressions at all.
+
#### Option ROMS
The third specified component type will be Option ROMs. Option ROMS will
@@ -364,8 +370,11 @@
#### NULL
-There is a 4th component type ,defined as NULL (0xFFFFFFFF). This is
-the "don't care" component type. This can be used when the component
+There is a 4th component type, defined as NULL (0xFFFFFFFF, 0x00000000).
+This is the "don't care" component type. This can be used when the component
type is not necessary (such as when the name of the component is unique.
i.e. option_table). It is recommended that all components be assigned a
unique type, but NULL can be used when the type does not matter.
+
+[FIT]: payloads/fit.md
+[SELF]: payloads/selfboot.md
diff --git a/Documentation/lib/payloads/selfboot.md b/Documentation/lib/payloads/selfboot.md
index 62a4393..791d6c0 100644
--- a/Documentation/lib/payloads/selfboot.md
+++ b/Documentation/lib/payloads/selfboot.md
@@ -18,6 +18,8 @@
address they specify. If it's not possible to load the payload at the specified
address, the system won't boot.
+Implementations details can be found in the [CBFS] documentation.
+
### Calling conventions
The SELF payload is called with a pointer to the coreboot tables as first
argument.
@@ -26,3 +28,4 @@
and a pointer to the *FDT* as arguments.
[RISC-V]: ../../arch/riscv/index.md
+[CBFS]: ../cbfs.md
--
To view, visit https://review.coreboot.org/c/coreboot/+/33664
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I84d07ae1c5c1ded2b9ab5934e2babbbabb749440
Gerrit-Change-Number: 33664
Gerrit-PatchSet: 1
Gerrit-Owner: Patrick Rudolph <patrick.rudolph(a)9elements.com>
Gerrit-MessageType: newchange
Matt Delco has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/33303
Change subject: libpayload/drivers/i8042: ignore special keys on keyboard
......................................................................
libpayload/drivers/i8042: ignore special keys on keyboard
Some keyboards have a fn-key (and/or fn-mode lock) that can generate
0xe0-prefixed scan codes for certain keys. Previously the 0xe0 prefix
state wasn't tracked (it was ignored), so these scan codes could be
misinterpreted as non-0xe0 presses (e.g., 'mute' generates 0xe0 0x20
but this would get interpreted as 0x20 and be treated as a 'D' press).
Most 0xe0-prefixed codes (besides those for the 10-key) are irrelevant
for firmware so we'll ignore them.
BUG=none
BRANCH=none
TEST=local build and flash. Verified that special keys are no longer
interpreted as other keystrokes.
Change-Id: Ie6a828b6a0a3ab47456d6db2db504aa0d7aefc28
Signed-off-by: Matt Delco <delco(a)chromium.org>
---
M payloads/libpayload/drivers/i8042/keyboard.c
1 file changed, 23 insertions(+), 5 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/03/33303/1
diff --git a/payloads/libpayload/drivers/i8042/keyboard.c b/payloads/libpayload/drivers/i8042/keyboard.c
index 3e5f988..bca916f 100644
--- a/payloads/libpayload/drivers/i8042/keyboard.c
+++ b/payloads/libpayload/drivers/i8042/keyboard.c
@@ -235,12 +235,30 @@
unsigned char ch;
int shift;
int ret = 0;
-
- while (!keyboard_havechar()) ;
+ static int prior_special = 0;
ch = keyboard_get_scancode();
- if (!(ch & 0x80) && ch < 0x59) {
+ if (prior_special) {
+ if (ch == 0x5e)
+ ret = POWER_BUTTON;
+ /*
+ * For now 0xe0 with 0x1c, 0x35, or 0x47 - 0x53 is the same as
+ * non-0xe0. For 10-key scan codes 0x47-0x53 it's probably more
+ * accurate for the non-0xe0 presses to use the numeric
+ * interpretation of the key (i.e., when num lock is on) and
+ * the 0xe0 prefixed versions should use the non-numeric
+ * interpretation (i.e., num lock off). However, the existing
+ * tables are using the non-numeric interpretation so for now
+ * the 0xe0 presses can use what's in the table for non-0xe0
+ * presses. The main exception is that shift+'/' on the keypad
+ * (0xe0 0x35) should still produce a '/' (vs. a '?' like on
+ * the key that's to the left of the right-shift on English
+ * keyboards) so we'll ignore the shift status.
+ */
+ else if (ch == 0x1c || ch == 0x35 || (ch >= 0x47 && ch <= 0x53))
+ ret = map->map[0][ch];
+ } else if (ch < 0x59) { /* implies !(ch & 0x80), i.e., key press */
shift =
(modifier & KB_MOD_SHIFT) ^ (modifier & KB_MOD_CAPSLOCK) ? 1 : 0;
@@ -265,8 +283,8 @@
}
}
- if (ch == 0x5e)
- ret = POWER_BUTTON;
+ /* sequence 0xe0 0xe0 should not leave prior_special set. */
+ prior_special = !prior_special && ch == 0xe0;
return ret;
}
--
To view, visit https://review.coreboot.org/c/coreboot/+/33303
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ie6a828b6a0a3ab47456d6db2db504aa0d7aefc28
Gerrit-Change-Number: 33303
Gerrit-PatchSet: 1
Gerrit-Owner: Matt Delco <delco(a)chromium.org>
Gerrit-MessageType: newchange
Michał Żygowski has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/30757
Change subject: [RFC] src/device/smbus: add extended addressing functions
......................................................................
[RFC] src/device/smbus: add extended addressing functions
Found this on one of private repositories I have access to.
Do not have any use case for it yet.
Signed-off-by: Michał Żygowski <michal.zygowski(a)3mdeb.com>
Change-Id: I5dcfc6bf33ef7baaa619f84b2ce0ab8e179a44b3
---
M src/device/smbus_ops.c
M src/include/device/smbus.h
M src/include/device/smbus_def.h
3 files changed, 64 insertions(+), 1 deletion(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/57/30757/1
diff --git a/src/device/smbus_ops.c b/src/device/smbus_ops.c
index c91f415..26cd956 100644
--- a/src/device/smbus_ops.c
+++ b/src/device/smbus_ops.c
@@ -90,3 +90,20 @@
return ops_smbus_bus(get_pbus_smbus(dev))->block_write(dev, cmd,
bytes, buffer);
}
+
+int smbus_extended_read_byte(struct device *dev, u16 addr)
+{
+ CHECK_PRESENCE(extended_read_byte);
+
+ return ops_smbus_bus(get_pbus_smbus(dev))->extended_read_byte(dev,
+ addr);
+}
+
+int smbus_extended_write_byte(struct device *dev, u16 addr, u8 val)
+{
+ CHECK_PRESENCE(extended_write_byte);
+
+ return ops_smbus_bus(get_pbus_smbus(dev))->extended_write_byte(dev,
+ addr,
+ val);
+}
\ No newline at end of file
diff --git a/src/include/device/smbus.h b/src/include/device/smbus.h
index de6cf40..cb3f826 100644
--- a/src/include/device/smbus.h
+++ b/src/include/device/smbus.h
@@ -1,3 +1,22 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2014 Sage Electronic Engineering, LLC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.
+ */
+
#ifndef DEVICE_SMBUS_H
#define DEVICE_SMBUS_H
@@ -15,6 +34,8 @@
int (*block_read)(struct device *dev, u8 cmd, u8 bytes, u8 *buffer);
int (*block_write)(struct device *dev, u8 cmd, u8 bytes,
const u8 *buffer);
+ int (*extended_read_byte)(struct device *dev, u16 addr);
+ int (*extended_write_byte)(struct device *dev, u16 addr, u8 value);
};
static inline const struct smbus_bus_operations *ops_smbus_bus(struct bus *bus)
@@ -54,6 +75,10 @@
int smbus_block_read(struct device *dev, u8 cmd, u8 bytes, u8 *buffer);
int smbus_block_write(struct device *dev, u8 cmd, u8 bytes, const u8 *buffer);
+int smbus_extended_read_byte(struct device *dev, u16 addr);
+int smbus_extended_write_byte(struct device *dev, u16 addr, u8 val);
+
+
#if IS_ENABLED(CONFIG_SMBUS_HAS_AUX_CHANNELS)
void smbus_switch_to_channel(uint8_t channel_number);
uint8_t smbus_get_current_channel(void);
diff --git a/src/include/device/smbus_def.h b/src/include/device/smbus_def.h
index 61d7861..cac08cc 100644
--- a/src/include/device/smbus_def.h
+++ b/src/include/device/smbus_def.h
@@ -1,10 +1,31 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2014 Sage Electronic Engineering, LLC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.
+ */
+
+
#ifndef DEVICE_SMBUS_DEF_H
#define DEVICE_SMBUS_DEF_H
#include <types.h>
/* Error results are negative success is >= 0 */
-#define SMBUS_ERROR CB_ERR
+#define SMBUS_SUCCESS CB_SUCCESS
+#define SMBUS_ERROR CB_ERR
#define SMBUS_WAIT_UNTIL_READY_TIMEOUT CB_I2C_BUSY
#define SMBUS_WAIT_UNTIL_DONE_TIMEOUT CB_I2C_TIMEOUT
#define SMBUS_WAIT_UNTIL_ACTIVE_TIMEOUT CB_I2C_NO_DEVICE
--
To view, visit https://review.coreboot.org/c/coreboot/+/30757
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I5dcfc6bf33ef7baaa619f84b2ce0ab8e179a44b3
Gerrit-Change-Number: 30757
Gerrit-PatchSet: 1
Gerrit-Owner: Michał Żygowski <michal.zygowski(a)3mdeb.com>
Gerrit-MessageType: newchange
Vassil Kakaradov has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/30708
Change subject: `sudo apt-get install -y qemu; qemu-system-x86_64 -bios build/coreboot.rom -serial stdio` -> "qemu-system-x86_64: command not found" `sudo apt-get install -y qemu qemu-kvm; qemu-system-x86_64 -bios build/coreboot.rom -serial stdio` -> "SUCCESS" replaced `sudo apt-get install -y qemu` with `sudo apt-get install -y qemu qemu-kvm` in lesson1.md Change-Id: Ia171562493eede9ddecd5a9389cf721462652596 Signed-off-by: vassil <vassil88(a)gmail.com>
......................................................................
`sudo apt-get install -y qemu; qemu-system-x86_64 -bios build/coreboot.rom -serial stdio` -> "qemu-system-x86_64: command not found"
`sudo apt-get install -y qemu qemu-kvm; qemu-system-x86_64 -bios build/coreboot.rom -serial stdio` -> "SUCCESS"
replaced `sudo apt-get install -y qemu` with `sudo apt-get install -y qemu qemu-kvm` in lesson1.md
Change-Id: Ia171562493eede9ddecd5a9389cf721462652596
Signed-off-by: vassil <vassil88(a)gmail.com>
---
A Documentation/lessons/lesson1_2019-01-07_13.31.35_UTC.md
1 file changed, 168 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/08/30708/1
diff --git a/Documentation/lessons/lesson1_2019-01-07_13.31.35_UTC.md b/Documentation/lessons/lesson1_2019-01-07_13.31.35_UTC.md
new file mode 100644
index 0000000..729e6ae
--- /dev/null
+++ b/Documentation/lessons/lesson1_2019-01-07_13.31.35_UTC.md
@@ -0,0 +1,168 @@
+coreboot lesson 1 - Starting from scratch
+=========================================
+
+From a fresh Ubuntu 16.04 or 18.04 install, here are all the steps required for
+a very basic build:
+
+Download, configure, and build coreboot
+---------------------------------------
+
+### Step 1 - Install tools and libraries needed for coreboot
+ $ sudo apt-get install -y bison build-essential curl flex git gnat-5 libncurses5-dev m4 zlib1g-dev
+
+### Step 2 - Download coreboot source tree
+ $ git clone https://review.coreboot.org/coreboot
+ $ cd coreboot
+
+### Step 3 - Build the coreboot toolchain
+Please note that this can take a significant amount of time
+
+ $ make crossgcc-i386 CPUS=$(nproc)
+
+Also note that you can possibly use your system toolchain, but the results are
+not reproducible, and may have issues, so this is not recommended. See step 5
+to use your system toolchain.
+
+### Step 4 - Build the payload - coreinfo
+ $ make -C payloads/coreinfo olddefconfig
+ $ make -C payloads/coreinfo
+
+### Step 5 - Configure the build
+
+##### Configure your mainboard
+ $ make menuconfig
+ select 'Mainboard' menu
+ Beside 'Mainboard vendor' should be '(Emulation)'
+ Beside 'Mainboard model' should be 'QEMU x86 i440fx/piix4'
+ select < Exit >
+These should be the default selections, so if anything else was set, run
+`make distclean` to remove your old config file and start over.
+
+##### Optionally use your system toolchain (Again, not recommended)
+ select 'General Setup' menu
+ select 'Allow building with any toolchain'
+ select < Exit >
+
+##### Select the payload
+ select 'Payload' menu
+ select 'Add a Payload'
+ choose 'An Elf executable payload'
+ select 'Payload path and filename'
+ enter 'payloads/coreinfo/build/coreinfo.elf'
+ select < Exit >
+ select < Exit >
+ select < Yes >
+
+##### check your configuration (optional step):
+
+ $ make savedefconfig
+ $ cat defconfig
+
+There should only be two lines (or 3 if you're using the system toolchain):
+
+ CONFIG_PAYLOAD_ELF=y
+ CONFIG_PAYLOAD_FILE="payloads/coreinfo/build/coreinfo.elf"
+
+### Step 6 - build coreboot
+ $ make
+
+At the end of the build, you should see:
+
+ Build emulation/qemu-i440fx (QEMU x86 i440fx/piix4)
+
+This means your build was successful. The output from the build is in the build
+directory. build/coreboot.rom is the full rom file.
+
+Test the image using QEMU
+-------------------------
+
+### Step 7 - Install QEMU
+ $ sudo apt-get install -y qemu qemu-kvm
+
+### Step 8 - Run QEMU
+Start QEMU, and point it to the ROM you just built:
+
+ $ qemu-system-x86_64 -bios build/coreboot.rom -serial stdio
+
+You should see the serial output of coreboot in the original console window, and
+a new window will appear running the coreinfo payload.
+
+Summary
+-------
+
+### Step 1 summary - Install tools and libraries needed for coreboot
+You installed the minimum additional requirements for ubuntu to download and
+build coreboot. Ubuntu already has most of the other tools that would be
+required installed by default.
+
+* `build-essential` is the basic tools for doing builds. It comes pre-installed
+on some Ubuntu flavors, and not on others.
+* `git` is needed to download coreboot from the coreboot git repository.
+* `libncurses5-dev` is needed to build the menu for 'make menuconfig'
+* `m4, bison, curl, flex, gnat-5, zlib1g-dev` are needed to build the coreboot
+toolchain.
+
+If you started with a different distribution, you might need to install many
+other items which vary by distribution.
+
+### Step 2 summary - Download coreboot source tree
+This will download a 'read-only' copy of the coreboot tree. This just means
+that if you made changes to the coreboot tree, you couldn't immediately
+contribute them back to the community. To pull a copy of coreboot that would
+allow you to contribute back, you would first need to sign up for an account on
+gerrit.
+
+### Step 3 summary - Build the coreboot toolchain.
+This builds one of the coreboot cross-compiler toolchains for X86 platforms.
+Because of the variability of compilers and the other required tools between
+the various operating systems that coreboot can be built on, coreboot supplies
+and uses its own cross-compiler toolchain to build the binaries that end up as
+part of the coreboot ROM. The toolchain provided by the operating system (the
+'host toolchain') is used to build various tools that will run on the local
+system during the build process.
+
+### Step 4 summary - Build the payload
+To actually do anything useful with coreboot, you need to build a payload to
+include in the rom. The idea behind coreboot is that it does the minimum amount
+possible before passing control of the machine to a payload. There are various
+payloads such as grub or SeaBIOS that are typically used to boot the operating
+system. Instead, we used coreinfo, a small demonstration payload that allows the
+user to look at various things such as memory and the contents of coreboot's
+cbfs - the pieces that make up the coreboot rom.
+
+### Step 5 summary - Configure the build
+This step configures coreboot's build options using the menuconfig interface to
+Kconfig. Kconfig is the same configuration program used by the linux kernel. It
+allows you to enable, disable, and change various values to control the coreboot
+build process, including which mainboard(motherboard) to use, which toolchain to
+use, and how the runtime debug console should be presented and saved.
+Anytime you change mainboards in Kconfig, you should always run `make distclean`
+before running `make menuconfig`. Due to the way that Kconfig works, values will
+be kept from the previous mainboard if you skip the clean step. This leads to a
+hybrid configuration which may or may not work as expected.
+
+### Step 6 summary - Build coreboot
+You may notice that a number of other pieces are downloaded at the beginning of
+the build process. These are the git submodules used in various coreboot builds.
+By default, the _blobs_ submodule is not downloaded. This git submodule may be
+required for other builds for microcode or other binaries. To enable downloading
+this submodule, select the option "Allow use of binary-only repository" in the
+"General Setup" menu of Kconfig
+This attempts to build the coreboot rom. The rom file itself ends up in the
+build directory as 'coreboot.rom'. At the end of the build process, the build
+displayed the contents of the rom file.
+
+### Step 7 summary - Install QEMU
+QEMU is a processor emulator which we can use to show coreboot
+
+### Step 8 summary - Run QEMU
+Here's the command line broken down:
+* `qemu-system-x86_64`
+This starts the QEMU emulator with the i440FX host PCI bridge and PIIX3 PCI to
+ISA bridge.
+* `-bios build/coreboot.rom`
+Use the bios rom image that we just built. If this is left off, the standard
+SeaBIOS image that comes with QEMU is used.
+* `-serial stdio`
+Send the serial output to the console. This allows you to view the coreboot
+debug output.
--
To view, visit https://review.coreboot.org/c/coreboot/+/30708
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ia171562493eede9ddecd5a9389cf721462652596
Gerrit-Change-Number: 30708
Gerrit-PatchSet: 1
Gerrit-Owner: Vassil Kakaradov <vassil88(a)gmail.com>
Gerrit-MessageType: newchange