.gitlab-ci.yml

@@ -90,7 +90,7 @@ check_dependencies:
 
 .run_regression: &run_regression
   image:
-    name: 3mdeb/rf-docker:0.4.2
+    name: 3mdeb/rf-docker:0.5.0
     # https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#overriding-the-entrypoint-of-an-image
     # https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2692
     # use EMPTY ENTRYPOINT for docker >17.06
@@ -99,15 +99,12 @@ check_dependencies:
     PLATFORM:
     RTE_IP:
     CONFIG:
-    AUTOFILL: 1
+    AUTOFILL:
     FIRMWARE_VERSION: $CI_COMMIT_REF_NAME
   stage: run_regression
   tags:
     - local
   timeout: 12h
-  before_script:
-    - apt-get update
-    - apt-get install binutils
   script:
     - bash -x .gitlab-ci/regression.sh
   only:
@@ -134,6 +131,14 @@ publish:apu1:
   variables:
     PLATFORM: apu1
 
+regression:apu1:
+  <<: *run_regression
+  variables:
+    PLATFORM: apu1
+    CONFIG: apu1
+    RTE_IP: $RTE_IP_APU1
+    AUTOFILL: 1
+
 
 build:apu2:
   <<: *build_rom_apu
@@ -161,6 +166,7 @@ regression:apu2:
     PLATFORM: apu2
     CONFIG: apu2
     RTE_IP: $RTE_IP_APU2
+    AUTOFILL: 1
 
 
 build:apu3:
@@ -189,6 +195,7 @@ regression:apu3:
     PLATFORM: apu3
     CONFIG: apu3
     RTE_IP: $RTE_IP_APU3
+    AUTOFILL: 1
 
 
 build:apu4:
@@ -217,6 +224,7 @@ regression:apu4:
     PLATFORM: apu4
     CONFIG: apu4
     RTE_IP: $RTE_IP_APU4
+    AUTOFILL: 1
 
 
 build:apu5:
@@ -245,3 +253,4 @@ regression:apu5:
     PLATFORM: apu5
     CONFIG: apu5
     RTE_IP: $RTE_IP_APU5
+    AUTOFILL: 1

.gitlab-ci/regression.sh

@@ -1,9 +1,8 @@
 #!/bin/bash
 
-git clone https://$GITLAB_ROBOT_USERNAME:$GITLAB_ROBOT_TOKEN@gitlab.com/3mdeb/rte/open-firmware-rte.git
-cd open-firmware-rte
+git clone https://$GITLAB_ROBOT_USERNAME:$GITLAB_ROBOT_TOKEN@$TESTS_REPO_GIT
+cd $TESTS_REPO_DIR
 
-git checkout gitlabci-regression
 sed -i 's+git@gitlab.com:3mdeb/rte/rtectrl-rest-api.git+https://'$GITLAB_ROBOT_USERNAME':'$GITLAB_ROBOT_TOKEN'@gitlab.com/3mdeb/rte/rtectrl-rest-api.git+' .gitmodules
 sed -i 's+git@gitlab.com:3mdeb/rte/snipeit-rest-api.git+https://'$GITLAB_ROBOT_USERNAME':'$GITLAB_ROBOT_TOKEN'@gitlab.com/3mdeb/rte/snipeit-rest-api.git+' .gitmodules
 git submodule update --init --checkout

.gitmodules

@@ -48,6 +48,6 @@
 	update = none
 [submodule "3rdparty/qc_blobs"]
 	path = 3rdparty/qc_blobs
-	url = ../qc_blobs.git
+	url = https://review.coreboot.org/qc_blobs.git
 	update = none
 	ignore = dirty

CHANGELOG.md

@@ -12,6 +12,15 @@ official [coreboot repository](https://review.coreboot.org/cgit/coreboot.git)
 Please use [pce-fw-builder](https://github.com/pcengines/pce-fw-builder)
 
 ## [Unreleased]
+## [v4.12.0.4] - 2020-08-28
+### Changed
+- rebased with official coreboot repository commit 81a2f45
+- updates sortbootorder to v4.6.20 for minor build fix
+
+### Fixed
+- TPM2 visibility in OS for apu3d and apu4d
+- issues with IRQ vectors reported in Xen and Linux dmesg
+
 ## [v4.12.0.3] - 2020-07-29
 ### Fixed
 - [memory speed values in the DMI table](https://github.com/pcengines/apu2-documentation/issues/176)
@@ -445,7 +454,8 @@ redundant code which was similar for APU2/3/5 boards.
 - turn off D4 and D5 leds on boot
 - enable power on after power failure
 
-[Unreleased]: https://github.com/pcengines/coreboot/compare/v4.12.0.3...develop
+[Unreleased]: https://github.com/pcengines/coreboot/compare/v4.12.0.4...develop
+[v4.12.0.4]: https://github.com/pcengines/coreboot/compare/v4.12.0.3...v4.12.0.4
 [v4.12.0.3]: https://github.com/pcengines/coreboot/compare/v4.12.0.2...v4.12.0.3
 [v4.12.0.2]: https://github.com/pcengines/coreboot/compare/v4.12.0.1...v4.12.0.2
 [v4.12.0.1]: https://github.com/pcengines/coreboot/compare/v4.11.0.6...v4.12.0.1

Documentation/arch/x86/index.md

@@ -5,16 +5,19 @@ This section contains documentation about coreboot on x86 architecture.
 * [x86 PAE support](pae.md)
 
 ## State of x86_64 support
-At the moment there's no single board that supports x86_64 or to be exact
-`ARCH_RAMSTAGE_X86_64` and `ARCH_ROMSTAGE_X86_64`.
+At the moment there's only experimental x86_64 support.
+The `emulation/qemu-i440fx` and `emulation/qemu-q35` boards do support
+*ARCH_RAMSTAGE_X86_64* , *ARCH_POSTCAR_X86_64* and *ARCH_ROMSTAGE_X86_64*.
 
-In order to add support for x86_64 the following assumptions are made:
+In order to add support for x86_64 the following assumptions were made:
 * The CPU supports long mode
 * All memory returned by malloc must be below 4GiB in physical memory
 * All code that is to be run must be below 4GiB in physical memory
 * The high dword of pointers is always zero
 * The reference implementation is qemu
 * The CPU supports 1GiB hugepages
+* x86 payloads are loaded below 4GiB in physical memory and are jumped
+  to in *protected mode*
 
 ## Assuptions for all stages using the reference implementation
 * 0-4GiB are identity mapped using 2MiB-pages as WB
@@ -37,18 +40,16 @@ The page tables contains the following structure:
 
 At the moment *$n* is 4, which results in identity mapping the lower 4 GiB.
 
-## Steps to add basic support for x86_64
-* Add x86_64 toolchain support - *DONE*
-* Fix compilation errors - *DONE*
-* Fix linker errors - *TODO*
-* Add x86_64 rmodule support - *DONE*
-* Add x86_64 exception handlers - *DONE*
-* Setup page tables for long mode - *DONE*
-* Add assembly code for long mode - *DONE*
-* Add assembly code for SMM - *DONE*
-* Add assembly code for postcar stage - *TODO*
-* Add assembly code to return to protected mode - *TODO*
-* Implement reference code for mainboard `emulation/qemu-q35` - *TODO*
+## Basic x86_64 support
+Basic support for x86_64 has been implemented for QEMU mainboard target.
+
+## Reference implementation
+The reference implementation is
+* [QEMU i440fx](../../mainboard/emulation/qemu-i440fx.md)
+* [QEMU Q35](../../mainboard/emulation/qemu-q35.md)
+
+## TODO
+* Identity map memory above 4GiB in ramstage
 
 ## Future work
 

Documentation/conf.py

@@ -48,7 +48,7 @@
 except ImportError:
     print("Error: Please install sphinxcontrib.ditaa for ASCII art conversion\n")
 else:
-    extensions += 'sphinxcontrib.ditaa'
+    extensions += ['sphinxcontrib.ditaa']
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

Documentation/getting_started/gerrit_guidelines.md

@@ -43,15 +43,42 @@ employer is aware and you are authorized to submit the code. For
 clarification, see the Developer's Certificate of Origin in the coreboot
 [Signed-off-by policy](https://www.coreboot.org/Development_Guidelines#Sign-off_Procedure).
 
-* Let non-trivial patches sit in a review state for at least 24 hours
-before submission. Remember that there are coreboot developers in timezones
-all over the world, and everyone should have a chance to contribute.
-Trivial patches would be things like whitespace changes or spelling fixes,
-in general those that don’t impact the final binary output. The
-24-hour period would start at submission, and would be restarted at any
-update which significantly changes any part of the patch. Patches can be
-'Fast-tracked' and submitted in under 24 hours with the agreement of at
-least 3 +2 votes.
+* In general, patches should remain open for review for at least 24 hours
+since the last significant modification to the change. The purpose is to
+let coreboot developers around the world have a chance to review. Complex
+reworks, even if they don't change the purpose of the patch but the way
+it's implemented, should restart the wait period.
+
+* A change can go in without the wait period if its purpose is to fix
+a recently-introduced issue (build, boot or OS-level compatibility, not
+necessarily identified by coreboot.org facilities). Its commit message
+has to explain what change introduced the problem and the nature of
+the problem so that the emergency need becomes apparent. The change
+itself should be as limited in scope and impact as possible to make it
+simple to assess the impact. Such a change can be merged early with 3
+Code-Review+2. For emergency fixes that affect a single project (SoC,
+mainboard, ...) it's _strongly_ recommended to get a review by somebody
+not involved with that project to ensure that the documentation of the
+issue is clear enough.
+
+* Trivial changes that deal with minor issues like inconsistencies in
+whitespace or spelling fixes that don't impact the final binary output
+also don't need to wait. Such changes should point out in their commit
+messages how the the author verified that the binary output is identical
+(e.g. a TIMELESS build for a given configuration). When submitting
+such changes early, the submitter must be different from the author
+and must document the intent in the Gerrit discussion, e.g. "landed the
+change early because it's trivial". Note that trivial fixes shouldn't
+necessarily be expedited: Just like they're not critical enough for
+things to go wrong because of them, they're not critical enough to
+require quick handling. This exception merely serves to acknowledge that
+a round-the-world review just isn't necessary for some types of changes.
+
+* As explained in our Code of Conduct, we try to assume the best of each
+other in this community. It's okay to discuss mistakes (e.g. isolated
+instances of non-trivial and non-critical changes submitted early) but
+try to keep such inquiries blameless. If a change leads to problems with
+our code, the focus should be on fixing the issue, not on assigning blame.
 
 * Do not +2 patches that you authored or own, even for something as trivial
 as whitespace fixes. When working on your own patches, it’s easy to

Documentation/getting_started/gpio.md

@@ -88,11 +88,6 @@ configurations together into a set of macros, e.g.,
 ```C
     /* Native function configuration */
     #define PAD_CFG_NF(pad, pull, rst, func)
-    /*
-     * Set native function with RX Level/Edge configuration and disable
-     * input/output buffer if necessary
-     */
-    #define PAD_CFG_NF_BUF_TRIG(pad, pull, rst, func, bufdis, trig)
     /* General purpose output, no pullup/down. */
     #define PAD_CFG_GPO(pad, val, rst)
     /* General purpose output, with termination specified */

Documentation/getting_started/kconfig.md

@@ -52,7 +52,7 @@ command line.
   not have an answer yet, it stops and queries the user for the desired value.
 - olddefconfig - Generates a config, using the default value for any symbols not
   listed in the .config file.
-- savedefconfig - Creates a ‘mini-config’ file, stripping out all of the symbols
+- savedefconfig - Creates a ‘defconfig’ file, stripping out all of the symbols
   that were left as default values.  This is very useful for debugging, and is
   how config files should be saved.
 - silentoldconfig - This evaluates the .config file the same way that the

Documentation/lib/payloads/fit.md

@@ -5,6 +5,7 @@
 
 ## Supported architectures
 
+* aarch32
 * aarch64
 * riscv
 
@@ -26,6 +27,13 @@ The section must be named in order to be found by the FIT parser:
 
 The FIT parser needs architecure support.
 
+### aarch32
+The source code can be found in `src/arch/arm/fit_payload.c`.
+
+On aarch32 the kernel (a section named 'kernel') must be in **Image**
+format and it needs a devicetree (a section named 'fdt') to boot.
+The kernel will be placed close to "*DRAMSTART*".
+
 ### aarch64
 The source code can be found in `src/arch/arm64/fit_payload.c`.