coreboot-gerrit January 2019

coreboot-gerrit@coreboot.org

1 participants
1296 discussions

Change in ...coreboot[master]: Documentation: Add Project Ideas document
by Patrick Georgi (Code Review) 06 Feb '19

06 Feb '19

Patrick Georgi has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/30972 Change subject: Documentation: Add Project Ideas document ...................................................................... Documentation: Add Project Ideas document This is unfinished and we should collect ideas in this commit while it's under review on Gerrit until things settled. This will provide less churn and conflicts than multiple commits trying to edit the same file. Change-Id: Idd68f845930bd37a2293969b9a153cf584d6d15f Signed-off-by: Patrick Georgi <pgeorgi(a)google.com> --- A Documentation/contributing/project_ideas.md 1 file changed, 34 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/72/30972/1 diff --git a/Documentation/contributing/project_ideas.md b/Documentation/contributing/project_ideas.md new file mode 100644 index 0000000..2e89dea --- /dev/null +++ b/Documentation/contributing/project_ideas.md @@ -0,0 +1,34 @@ +# Project Ideas + +This section collects ideas to improve coreboot and related projects and +should serve as a pool of ideas for people who want to enter the field of +firmware development but need some guidance what to work on. + +These tasks can be adopted as part of programs like Google Summer of Code or +by motivated individuals outside such programs. + +Each entry should outline what would be done, the benefit it brings to the +project, the pre-requisites, both in knowledge and parts. They should also +list people interested in supporting people who want to work on them - since +we started building this list for Google Summer of Code, we'll adopt its term +for those people and call them mentors. + +## Provide toolchain binaries +Our crossgcc subproject provides a uniform compiler environment for working on +coreboot and related projects. Sadly, building it takes hours, which is a bad +experience when trying to build coreboot the first time. + +Provide packages/installers of our compiler toolchain for Linux distros, +Windows, Mac OS. For Windows, this should also include the environment (shell, +make, ...). + +## Requirements + +* coreboot knowledge: little +* other knowledge: should know how packages or installers for their target OS + work. Knowledge of the GCC build system is a big plus +* hardware requirements: nothing special + +## Mentors +* Patrick Georgi <patrick(a)georgi.software> + -- To view, visit https://review.coreboot.org/c/coreboot/+/30972 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Idd68f845930bd37a2293969b9a153cf584d6d15f Gerrit-Change-Number: 30972 Gerrit-PatchSet: 1 Gerrit-Owner: Patrick Georgi <pgeorgi(a)google.com> Gerrit-MessageType: newchange

4 12

Change in ...coreboot[master]: Documentation: describe coreboot on the dev site's landing page
by Patrick Georgi (Code Review) 05 Feb '19

05 Feb '19

Patrick Georgi has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/31127 Change subject: Documentation: describe coreboot on the dev site's landing page ...................................................................... Documentation: describe coreboot on the dev site's landing page Get some content on the documentation site's front page. Some links still need to be filled in with content yet to be written, but we need to start somewhere. Change-Id: I7f36234ef783e041a44590858bb75a69b96ee668 Signed-off-by: Patrick Georgi <pgeorgi(a)google.com> --- M Documentation/index.md 1 file changed, 134 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/27/31127/1 diff --git a/Documentation/index.md b/Documentation/index.md index 9fdb0dc..7498caa 100644 --- a/Documentation/index.md +++ b/Documentation/index.md @@ -5,6 +5,140 @@ [Documentation](https://review.coreboot.org/cgit/coreboot.git/tree/Documenta… directory in the source code. +## Purpose of coreboot + +coreboot is a project to develop open source firmware for various +architectures. Its design philosophy is to do the bare minimum necessary to +ensure that hardware is usable and then pass control to a different program +that called the _payload_. + +### Separation of concerns + +The payload can then provide user interfaces, file system drivers, +various policies etc. to load the OS. Through this separation of concerns +coreboot maximizes reusability of the complicated and fundamental hardware +initialization routines across many different use cases, no matter if +they provide standard interfaces or entirely custom boot flows. + +Popular [payloads]() in use with coreboot are SeaBIOS, which provides PCBIOS +services, Tianocore, which provides UEFI services, GRUB2, the bootloader +used by many Linux distributions, or depthcharge, a custom boot loader +on Chromebooks. + +### No resident services (if possible) + +Ideally coreboot completely hands over control to the payload with no +piece of coreboot remaining resident in the system, or even available +for callback. Given the reality of contemporary computer design, +there's often a small piece that survives for the whole runtime of +the computer. It runs in a highly privileged CPU mode (eg SMM on x86) +and provides some limited amount of services to the OS. But here, too, +coreboot aims to keep everything at the minimum possible, both in scope +(eg. services provided) and code size. + +### No specification of its own + +coreboot uses a very minimal interface to the payload, and otherwise +doesn't impose any standards on the ecosystem. This is made possible by +separating out concerns (interfaces and resident services are delegated +to the payload), but it's also a value that is deeply ingrained in the +project. We fearlessly rip out parts of the architecture and remodel it +when a better way of doing the same was identified. + +### One tree for everything + +Another difference to various other firmware projects is that we try +to avoid fragmentation: the traditional development model of firmware +is one of "set and forget" in which some code base is copied, adapted +for the purpose at hands, shipped and only touched again if there's an +important fix to do. + +All newer development happens on another copy of some code base without +flowing back to any older copy, and so normally there's a huge amount +of fragmentation. + +In coreboot, we try to keep everything in a single source tree, and +lift up older devices when we change something fundamentally. That way, +new and old devices benefit alike from new development in the common parts. + +There's a downside to that: Some devices might have no maintainer anymore +who could ensure that coreboot is still functional for them after a big +rework, or maybe a rework even requires knowledge that doesn't exist +anymore within the project (for example because the developer moved on +to do something else). + +In this case, we announce the deprecation of the device and defer the big +rework until the deprecation period passed, typically 6-12 months. This +gives interested developers a chance to step in and bring devices up to +latest standards. + +While without this deprecation mechanism we could inflate the number +of supported devices (probably 300+), only a tiny fraction of them +would even work, which helps nobody. + +## Scope of the coreboot project + +coreboot as a project is closer to the Linux kernel than to most +user level programs. One place where this becomes apparent is the +distribution mechanism: The project itself only provides source code +(plus redistributable binaries for parts that we haven't managed to open +up) and does not ship ready-to-install coreboot-based firmware binaries. + +There are various [distributions](), some shipping coreboot with their hardware +(eg. Purism or Chromebooks), others providing after-market images for +various devices (eg. Libreboot, MrChromebox). + +If you want to use coreboot on your system, that's great! + +Please note that the infrastructure around coreboot.org is built for +development purposes. We gladly help out users through our communication +channels, but we also expect a "firmware developer mindset": If compiling +your own firmware and, at some point, recovering from a bad flash by +hooking wires onto chips in your computer sounds scary to you, you're +right, as it is. + +If that's _way_ beyond your comfort zone, consider looking into the +various distributions, as they typically provide pre-tested binaries +which massively reduces the risk that the binary you write to flash is +one that won't boot the system (with the consequence that to get it to work +again, you'll need to attach various tools to various chips) + +## The coreboot community + +If you're interested in getting your hands dirty (incl. potentially wiring +up an external flasher to your computer), you've come to the right place! + +We have various [virtual sites]() where we discuss and coordinate +our activities, review patches, and help out each other. To +help promote a positive atmosphere, we established a [Code of +Conduct](code_of_conduct.md). We invested a lot of time to balance it out, +so please keep it in mind when engaging with the coreboot community. + +Every now and then, coreboot is present in one way or another at +[conferences](). If you're around, come and say hello! + +## Getting the source code + +coreboot is primarily developed in the +[git](https://review.coreboot.org/cgit/coreboot.git) DSCM, using +[Gerrit](https://review.coreboot.org) to manage contributions and +code review. + +In general we try to keep the `master` branch in the repository functional +for all hardware we support. So far, the only guarantee we can make is +that the master branch will (nearly) always build for all boards in a +standard configuration. + +However we're continually working on improvements to our infrastructure to +get better in that respect, eg by setting up boot testing facilities. This +is obviously more complex than regular integration testing, so progress +is slow. + +We also schedule two source code releases every year, around April and +October. These releases see some very limited testing and mostly serve +as synchronization points for deprecation notices and for other projects +such as external distributions. + Contents: * [Getting Started](getting_started/index.md) -- To view, visit https://review.coreboot.org/c/coreboot/+/31127 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I7f36234ef783e041a44590858bb75a69b96ee668 Gerrit-Change-Number: 31127 Gerrit-PatchSet: 1 Gerrit-Owner: Patrick Georgi <pgeorgi(a)google.com> Gerrit-MessageType: newchange

5 21

Change in ...coreboot[master]: Documentation: Describe our ecosystem
by Patrick Georgi (Code Review) 05 Feb '19

05 Feb '19

Patrick Georgi has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/31180 Change subject: Documentation: Describe our ecosystem ...................................................................... Documentation: Describe our ecosystem Neither payloads nor distributors are an integral part of the coreboot source tree, but they're very important parts of the coreboot ecosystems, so add some descriptions. Change-Id: Id64744c252b6b78c4811fbded48c441ef486ad94 Signed-off-by: Patrick Georgi <pgeorgi(a)google.com> --- A Documentation/distributions.md M Documentation/index.md A Documentation/payloads.md 3 files changed, 90 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/80/31180/1 diff --git a/Documentation/distributions.md b/Documentation/distributions.md new file mode 100644 index 0000000..788e808 --- /dev/null +++ b/Documentation/distributions.md @@ -0,0 +1,46 @@ +# Distributions + +coreboot doesn't provide binaries but provides a toolbox that others can use +to build boot firmware for all kinds of purposes. These third-parties can be +broadly separated in two groups: Those shipping coreboot on their hardware, +and those providing after-market firmware to extend the usefulness of devices. + +## Shipping coreboot on hardware + +### Purism + +[Purism](https://www.puri.sm) sells laptops with a focus on privacy and +part of that is their push to remove as much unaccounted code (that is, +binary only) from their devices as possible. + +### Chromebooks + +All Chromebooks (and related devices) that hit the market after 2013 are +using coreboot as their main firmware. And even the Embedded Controller, +a small microcontroller to support various periphery (like battery +management or the keyboard) is running open source firmware. + + +## After-market firmware + +### Libreboot + +[Libreboot](https://libreboot.org) is a project that provides ready-made +binaries for platforms where those can be built entirely from source +code. Their copy of the coreboot repository is therefore stripped of +all devices that require binary components to boot. + +### John Lewis + +[John Lewis](https://johnlewis.ie/custom-chromebook-firmware) provides +replacement firmware for some Chromebooks. Why replace coreboot with +coreboot? You might want to do different things than what the Google +engineers prepared for the mass market, that's why. This firmware is +"with training wheels off". + +### Mr. Chromebox + +[Matt Devo](https://mrchromebox.tech/) also provides replacements for +Chromebook firmware, for the same reasons as John Lewis. It's a somewhat +different set of devices, and with different configurations, so check +out both if Chromebooks are what you're dealing with. diff --git a/Documentation/index.md b/Documentation/index.md index af3886e..c5bfa9b 100644 --- a/Documentation/index.md +++ b/Documentation/index.md @@ -13,6 +13,8 @@ * [Code of Conduct](community/code_of_conduct.md) * [Community forums](community/forums.md) * [coreboot at conferences](community/conferences.md) +* [Payloads](payloads.md) +* [Distributions](distributions.md) * [Timestamps](timestamp.md) * [Intel IFD Binary Extraction](Binary_Extraction.md) * [Dealing with Untrusted Input in SMM](technotes/2017-02-dealing-with-untrusted-input-in-smm.md) diff --git a/Documentation/payloads.md b/Documentation/payloads.md new file mode 100644 index 0000000..b1eae61 --- /dev/null +++ b/Documentation/payloads.md @@ -0,0 +1,42 @@ +# Payloads + +coreboot doesn't try to mandate how the boot process should look, it merely +does hardware init and then passes on control to another piece of software +that we carry along in firmware storage, the _payload_. + +There is various software in that space that is either explicitly written as +payload or can be made to work as one. + +## SeaBIOS + +[SeaBIOS](https://www.seabios.org) is an open source implementation of +the PCBIOS API that exists since the original IBM PC and was extended +since. While originally written for emulators such as QEMU, it can be made +to work as a coreboot payload and all the necessary code is in SeaBIOS' +mainline code. + +## Tianocore + +[Tianocore](https://www.tianocore.org) is the open source reference +implementation of the UEFI Specifications that modern firmware for PCs is +based on. There were various projects in the past to make it suitable as a +coreboot payload, but these days this function is available directly in the +CorebootPayloadPkg part of its source tree. + +## GRUB2 + +GRUB2 was originally written as a bootloader and that's its most popular +purpose, but it can also be compiled as a coreboot payload. + +## Linux + +There are several projects using Linux as a payload (which was the +configuration that gave coreboot its original name, LinuxBIOS). That kernel is +often rather small and serves to load a current kernel from somewhere, e.g. +disk or network, and run that through the kexec mechanism. + +Two aspects emphasized by proponents of Linux-as-a-payload are the +availability of well-tested, battle-hardened drivers (as compared to +firmware project drivers that often reinvent the wheel) and the ability to +define boot policy with familiar tools, no matter if those are shell scripts +or compiled userland programs written in C, Go or other programming languages. -- To view, visit https://review.coreboot.org/c/coreboot/+/31180 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Id64744c252b6b78c4811fbded48c441ef486ad94 Gerrit-Change-Number: 31180 Gerrit-PatchSet: 1 Gerrit-Owner: Patrick Georgi <pgeorgi(a)google.com> Gerrit-MessageType: newchange

3 8

Change in ...coreboot[master]: Documentation: Allow passing arguments into make livesphinx
by Patrick Georgi (Code Review) 05 Feb '19

05 Feb '19

Patrick Georgi has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/31128 Change subject: Documentation: Allow passing arguments into make livesphinx ...................................................................... Documentation: Allow passing arguments into make livesphinx It's what the doc.coreboot.org docker container is running and when using its livehtml feature, it listens at localhost, which isn't always desirable. With `docker run -e SPHINXOPTS="-H $localip" ...` it now listens at localip, which is more flexible. Change-Id: Ia0614e57458c32169f6d614783366025e9c814b3 Signed-off-by: Patrick Georgi <pgeorgi(a)google.com> --- M Documentation/Makefile 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/28/31128/1 diff --git a/Documentation/Makefile b/Documentation/Makefile index ed08936..b4fe8df 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -52,4 +52,4 @@ rm -f corebootPortingGuide.pdf livesphinx: - $(MAKE) -f Makefile.sphinx livehtml + $(MAKE) -f Makefile.sphinx livehtml SPHINXOPTS="$(SPHINXOPTS)" -- To view, visit https://review.coreboot.org/c/coreboot/+/31128 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Ia0614e57458c32169f6d614783366025e9c814b3 Gerrit-Change-Number: 31128 Gerrit-PatchSet: 1 Gerrit-Owner: Patrick Georgi <pgeorgi(a)google.com> Gerrit-MessageType: newchange

3 3

Change in ...coreboot[master]: bootmem: add new memory type for BL31
by Ting Shen (Code Review) 05 Feb '19

05 Feb '19

Ting Shen has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/31123 Change subject: bootmem: add new memory type for BL31 ...................................................................... bootmem: add new memory type for BL31 Change-Id: Idbd9a7fe4b12af23de1519892936d8d88a000e2c Signed-off-by: Ting Shen <phoenixshen(a)google.com> --- M src/arch/arm64/arm_tf.c M src/include/bootmem.h M src/lib/bootmem.c 3 files changed, 5 insertions(+), 1 deletion(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/23/31123/1 diff --git a/src/arch/arm64/arm_tf.c b/src/arch/arm64/arm_tf.c index b74f7be..3f1aa2a 100644 --- a/src/arch/arm64/arm_tf.c +++ b/src/arch/arm64/arm_tf.c @@ -50,7 +50,7 @@ if (prog_locate(&bl31)) die("BL31 not found"); - if (!selfload_check(&bl31, BM_MEM_RESERVED)) + if (!selfload_check(&bl31, BM_MEM_BL31)) die("BL31 load failed"); bl31_entry = prog_entry(&bl31); diff --git a/src/include/bootmem.h b/src/include/bootmem.h index fb67b13..0e6ba50 100644 --- a/src/include/bootmem.h +++ b/src/include/bootmem.h @@ -37,6 +37,7 @@ BM_MEM_NVS, /* ACPI NVS Memory */ BM_MEM_UNUSABLE, /* Unusable address space */ BM_MEM_VENDOR_RSVD, /* Vendor Reserved */ + BM_MEM_BL31, /* BL31 exectuable */ BM_MEM_TABLE, /* Ram configuration tables are kept in */ /* Tags below this point are ignored for the OS table. */ BM_MEM_OS_CUTOFF = BM_MEM_TABLE, @@ -53,6 +54,7 @@ * Bootmem types match to LB_MEM tags, except for the following: * BM_MEM_RAMSTAGE : Translates to LB_MEM_RAM. * BM_MEM_PAYLOAD : Translates to LB_MEM_RAM. + * BM_MEM_BL31 : Translates to LB_MEM_RESERVED. */ void bootmem_write_memory_table(struct lb_memory *mem); diff --git a/src/lib/bootmem.c b/src/lib/bootmem.c index a7b7dd9..7fa6855 100644 --- a/src/lib/bootmem.c +++ b/src/lib/bootmem.c @@ -59,6 +59,8 @@ return LB_MEM_UNUSABLE; case BM_MEM_VENDOR_RSVD: return LB_MEM_VENDOR_RSVD; + case BM_MEM_BL31: + return LB_MEM_RESERVED; case BM_MEM_TABLE: return LB_MEM_TABLE; default: -- To view, visit https://review.coreboot.org/c/coreboot/+/31123 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Idbd9a7fe4b12af23de1519892936d8d88a000e2c Gerrit-Change-Number: 31123 Gerrit-PatchSet: 1 Gerrit-Owner: Ting Shen <phoenixshen(a)google.com> Gerrit-MessageType: newchange

7 28

Change in ...coreboot[master]: arch/x86/acpigen: wrap _PLD in a package
by Matt Delco (Code Review) 05 Feb '19

05 Feb '19

Matt Delco has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/31162 Change subject: arch/x86/acpigen: wrap _PLD in a package ...................................................................... arch/x86/acpigen: wrap _PLD in a package The ACPI spec has an asl example for _PLD in the form: Name (_PLD, Package (0x01) { ToPLD (PLD_Revision = 0x2) }) When I ported this to acpigen and diffed the results I noticed that the binary blob was no longer provided within a package. The ACPI spec (section 6.1.8 in version 6.2) defines _PLD as "a variable-length Package containing a list of Buffers". This commit changes acpigen_write_pld to use a package (the one existing caller I found isn't wrapping the result in a package so it doesn't look like it was intended for the callers of acpigen_write_pld to be responsible for using a package. BUG=none BRANCH=none TEST=Verified that after this change a package is use and the result of acpigen matches what was used in the original asl. Change-Id: Ie2db63c976100109bfe976553e52565fb2d2d9df Signed-off-by: Matt Delco <delco(a)chromium.org> --- M src/arch/x86/acpigen.c 1 file changed, 2 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/62/31162/1 diff --git a/src/arch/x86/acpigen.c b/src/arch/x86/acpigen.c index 290893d..0eacf05 100644 --- a/src/arch/x86/acpigen.c +++ b/src/arch/x86/acpigen.c @@ -1261,7 +1261,9 @@ return; acpigen_write_name("_PLD"); + acpigen_write_package(1); acpigen_write_byte_buffer(buf, ARRAY_SIZE(buf)); + acpigen_pop_len(); } void acpigen_write_dsm(const char *uuid, void (**callbacks)(void *), -- To view, visit https://review.coreboot.org/c/coreboot/+/31162 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Ie2db63c976100109bfe976553e52565fb2d2d9df Gerrit-Change-Number: 31162 Gerrit-PatchSet: 1 Gerrit-Owner: Matt Delco <delco(a)chromium.org> Gerrit-MessageType: newchange

4 3

Change in ...coreboot[master]: acpi: device: avoid empty property list in acpi_dp_write
by Matt Delco (Code Review) 05 Feb '19

05 Feb '19

Matt Delco has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/31161 Change subject: acpi: device: avoid empty property list in acpi_dp_write ...................................................................... acpi: device: avoid empty property list in acpi_dp_write If an acpi_dp table has children but no properties then acpi_dp_write() will write out a properties UUID and package that contains no properties. The existing function will avoid writing out a UUID and empty package when no children exist, but it seems to assume that properties will always be used. With this change properties are handled in a manner akin to children so that a UUID and package are only written if properties exist. BUG=none BRANCH=none TEST=Confirmed that prior to this change a UUID and empty package was present for a device that had children but no properties. Verified that after this change the UUID and empty package are no longer present but the child UUID and package are still present. Change-Id: I6f5597713a1e91ca26b409f36b3ff9eb90a010af Signed-off-by: Matt Delco <delco(a)chromium.org> --- M src/arch/x86/acpi_device.c 1 file changed, 26 insertions(+), 16 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/61/31161/1 diff --git a/src/arch/x86/acpi_device.c b/src/arch/x86/acpi_device.c index 48b7fee..c62d6f3 100644 --- a/src/arch/x86/acpi_device.c +++ b/src/arch/x86/acpi_device.c @@ -632,7 +632,7 @@ void acpi_dp_write(struct acpi_dp *table) { struct acpi_dp *dp, *prop; - char *dp_count, *prop_count; + char *dp_count, *prop_count = NULL; int child_count = 0; if (!table || table->type != ACPI_DP_TYPE_TABLE) @@ -644,32 +644,42 @@ /* Device Property list starts with the next entry */ prop = table->next; - /* Package (DP), default to 2 elements (assuming no children) */ - dp_count = acpigen_write_package(2); - - /* ToUUID (ACPI_DP_UUID) */ - acpigen_write_uuid(ACPI_DP_UUID); - - /* Package (PROP), element count determined as it is populated */ - prop_count = acpigen_write_package(0); + /* Package (DP), default to assuming no properties or children */ + dp_count = acpigen_write_package(0); /* Print base properties */ for (dp = prop; dp; dp = dp->next) { if (dp->type == ACPI_DP_TYPE_CHILD) { child_count++; } else { + /* + * The UUID and package is only added when + * we come across the first property. This + * is to avoid creating a zero-length package + * in situations where there are only children. + */ + if (!prop_count) { + *dp_count += 2; + /* ToUUID (ACPI_DP_UUID) */ + acpigen_write_uuid(ACPI_DP_UUID); + /* + * Package (PROP), element count determined as + * it is populated + */ + prop_count = acpigen_write_package(0); + } (*prop_count)++; acpi_dp_write_property(dp); } } - - /* Package (PROP) length */ - acpigen_pop_len(); + if (prop_count) { + /* Package (PROP) length, if a package was written */ + acpigen_pop_len(); + } if (child_count) { - /* Update DP package count to 4 */ - *dp_count = 4; - + /* Update DP package count to 2 or 4 */ + *dp_count += 2; /* ToUUID (ACPI_DP_CHILD_UUID) */ acpigen_write_uuid(ACPI_DP_CHILD_UUID); @@ -679,7 +689,7 @@ for (dp = prop; dp; dp = dp->next) if (dp->type == ACPI_DP_TYPE_CHILD) acpi_dp_write_property(dp); - + /* Package (CHILD) length */ acpigen_pop_len(); } -- To view, visit https://review.coreboot.org/c/coreboot/+/31161 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I6f5597713a1e91ca26b409f36b3ff9eb90a010af Gerrit-Change-Number: 31161 Gerrit-PatchSet: 1 Gerrit-Owner: Matt Delco <delco(a)chromium.org> Gerrit-MessageType: newchange

5 6

Change in ...coreboot[master]: mb/google/hatch: Add keyboard backlight support
by Ivy Jian (Code Review) 05 Feb '19

05 Feb '19

Ivy Jian has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/31175 Change subject: mb/google/hatch: Add keyboard backlight support ...................................................................... mb/google/hatch: Add keyboard backlight support This change adds keyboard backlight feature for Hatch platform BUG=b:122799544 BRANCH=none TEST=keyboard backlight works when EC reports correct info. Change-Id: I29273122f061e0e442f6629351ef3670535c0507 Signed-off-by: Ivy Jian <ivy_jian(a)compal.corp-partner.google.com> --- M src/mainboard/google/hatch/variants/baseboard/include/baseboard/ec.h 1 file changed, 3 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/75/31175/1 diff --git a/src/mainboard/google/hatch/variants/baseboard/include/baseboard/ec.h b/src/mainboard/google/hatch/variants/baseboard/include/baseboard/ec.h index f9cebd7..75d583e 100644 --- a/src/mainboard/google/hatch/variants/baseboard/include/baseboard/ec.h +++ b/src/mainboard/google/hatch/variants/baseboard/include/baseboard/ec.h @@ -78,4 +78,7 @@ #define SIO_EC_HOST_ENABLE /* EC Host Interface Resources */ #define SIO_EC_ENABLE_PS2K /* Enable PS/2 Keyboard */ +/* Enable EC backed Keyboard Backlight in ACPI */ +#define EC_ENABLE_KEYBOARD_BACKLIGHT + #endif /* __BASEBOARD_EC_H__ */ -- To view, visit https://review.coreboot.org/c/coreboot/+/31175 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I29273122f061e0e442f6629351ef3670535c0507 Gerrit-Change-Number: 31175 Gerrit-PatchSet: 1 Gerrit-Owner: Ivy Jian <ivy_jian(a)compal.corp-partner.google.com> Gerrit-MessageType: newchange

4 5

Change in ...coreboot[master]: mb/google/kukui: Add default HWID for Chrome OS
by Hung-Te Lin (Code Review) 05 Feb '19

05 Feb '19

Hung-Te Lin has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/31088 Change subject: mb/google/kukui: Add default HWID for Chrome OS ...................................................................... mb/google/kukui: Add default HWID for Chrome OS The default value for Chrome OS HWID should be different. Calculated as HWID v1. BUG=None BRANCH=kukui TEST=build and boots properly. Change-Id: I39c640562c1c3b117292b8abacd36a4a9c2fa6c6 Signed-off-by: Hung-Te Lin <hungte(a)chromium.org> --- M src/mainboard/google/kukui/Kconfig 1 file changed, 5 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/88/31088/1 diff --git a/src/mainboard/google/kukui/Kconfig b/src/mainboard/google/kukui/Kconfig index 7635e5f..1a594a3 100644 --- a/src/mainboard/google/kukui/Kconfig +++ b/src/mainboard/google/kukui/Kconfig @@ -59,4 +59,9 @@ hex default 0x2 +config GBB_HWID + string + depends on CHROMEOS + default "KUKUI TEST 9847" + endif -- To view, visit https://review.coreboot.org/c/coreboot/+/31088 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I39c640562c1c3b117292b8abacd36a4a9c2fa6c6 Gerrit-Change-Number: 31088 Gerrit-PatchSet: 1 Gerrit-Owner: Hung-Te Lin <hungte(a)chromium.org> Gerrit-MessageType: newchange

5 9

Change in ...coreboot[master]: mb/emulation/qemu-i440fx: use e820 in romstage
by Thomas Heijligen (Code Review) 05 Feb '19

05 Feb '19

Thomas Heijligen has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/30850 Change subject: mb/emulation/qemu-i440fx: use e820 in romstage ...................................................................... mb/emulation/qemu-i440fx: use e820 in romstage Use memory map from fw_cfg e820 map to find cbmem_top in romstage to avoid conflicts with CMOS option table. Keep qemu_gwt_memory_size() as fallback. Change-Id: I6465085020125fc790257f09eb157030c6ceabcb Signed-off-by: Thomas Heijligen <thomas.heijligen(a)secunet.com> --- M src/mainboard/emulation/qemu-i440fx/Makefile.inc M src/mainboard/emulation/qemu-i440fx/memory.c 2 files changed, 18 insertions(+), 1 deletion(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/50/30850/1 diff --git a/src/mainboard/emulation/qemu-i440fx/Makefile.inc b/src/mainboard/emulation/qemu-i440fx/Makefile.inc index 9e2880a..8c19afc 100644 --- a/src/mainboard/emulation/qemu-i440fx/Makefile.inc +++ b/src/mainboard/emulation/qemu-i440fx/Makefile.inc @@ -1,4 +1,5 @@ ramstage-y += northbridge.c ramstage-y += fw_cfg.c +romstage-y += fw_cfg.c romstage-y += memory.c ramstage-y += memory.c diff --git a/src/mainboard/emulation/qemu-i440fx/memory.c b/src/mainboard/emulation/qemu-i440fx/memory.c index dea96f2..863d923 100644 --- a/src/mainboard/emulation/qemu-i440fx/memory.c +++ b/src/mainboard/emulation/qemu-i440fx/memory.c @@ -16,6 +16,8 @@ #include <cbmem.h> #include <arch/io.h> #include "memory.h" +#include "fw_cfg.h" +#include "fw_cfg_if.h" #define CMOS_ADDR_PORT 0x70 #define CMOS_DATA_PORT 0x71 @@ -52,5 +54,19 @@ void *cbmem_top(void) { - return (void *) (qemu_get_memory_size() * 1024); + FwCfgE820Entry e; + uint64_t tom = 0; + + if (fw_cfg_e820_select()) { + while (!fw_cfg_e820_read(&e)) { + uint64_t limit = (uint64_t)e.address + e.length; + if (e.type == 1 && limit < 4ULL * GiB && limit > tom) + tom = limit; + } + } + + if (!tom) + tom = qemu_get_memory_size() * 1024; + + return (void *)((uint32_t)tom); } -- To view, visit https://review.coreboot.org/c/coreboot/+/30850 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I6465085020125fc790257f09eb157030c6ceabcb Gerrit-Change-Number: 30850 Gerrit-PatchSet: 1 Gerrit-Owner: Thomas Heijligen <src(a)posteo.de> Gerrit-Reviewer: Martin Roth <martinroth(a)google.com> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-Reviewer: Thomas Heijligen <src(a)posteo.de> Gerrit-MessageType: newchange

3 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit January 2019