1coreboot 4.12 2============= 3 4coreboot 4.12 was released on May 12th, 2020. 5 6Since 4.11 there were 2692 new commits by over 190 developers and of 7these, 59 contributed for the first time, which is quite an amazing 8increase. 9 10Thank you to all developers who again helped made coreboot better 11than ever, and a big welcome to our new contributors! 12 13Maintainers 14----------- 15 16This release saw some activity on the MAINTAINERS file, showing more 17persons, teams and companies declare publicly that they intend to 18take care of mainboards and subsystems. 19 20To all new maintainers, thanks a lot! 21 22Documentation 23------------- 24 25Our documentation efforts in the code tree are picking up steam, with 26some 70 commits in that general area. Everything from typo fixes to 27documenting mainboard support or coreboot APIs. 28 29There's still room to improve, but the contributions are getting more 30and better. 31 32Hardware support 33---------------- 34 35The removals due to the announced deprecations as well as the 36deduplication of boards into variants skew the stats a bit, so at 37a top level view this is a rare coreboot release in that it removes 38more boards (51) than it adds (49). 39 40After accounting for the variant moves the numbers in favor of more 41hardware supported than the previous version. Besides a whole lot 42of Chrome OS devices (again), this release features a whole bunch 43of retrofits for devices originally shipping with non-coreboot OEM 44firmware, but also support for devices that come with coreboot right 45out of the box. 46 47For that, a shout out to System76, Protectli, Libretrend and the 48Open Compute Project! 49 50Cleanup 51-------- 52 53We simplified the header that comes at the top of every file: 54Instead of a lengthy reference to the license any given file 55is under, or even the license text itself, we opted for simple 56[SPDX](https://www.spdx.org) identifiers. 57 58Since people also handled copyright lines differently, we now opt for 59collecting authors in AUTHORS and let git history tell the whole story. 60 61While at it, the content-free "This file is part of this-and-that 62project" header was also dropped. 63 64Besides that, there has also been more work to sort out the headers 65we include across the tree to minimize the code impacting every 66compilation unit. 67 68Now that our board-variant mechanism matured, many boards that were 69individual models so far were converted into variants, making it 70easier to maintain families of devices. 71 72Deprecations 73------------ 74 75For the 4.12 release a few features on x86 became mandatory. These are 76relocatable ramstage, postcar stage and C\_ENVIRONMENT\_BOOTBLOCK. 77 78### Relocatable ramstage 79 80Relocatable stages are a feature implemented only on x86, where stages 81can be relocated at runtime. This is used to place ramstage in a better 82location that does not collide with memory the OS or the payload tends 83to use. The rationale behind making this mandatory is that you always 84want cbmem to be cached so it's a good location to run ramstage from. 85It avoids using lower memory altogether so the OS can make use of it 86and no backing up needs to happen on S3 resume. 87 88### Postcar stage 89 90With Postcar stage tearing down Cache-as-Ram is done in a separate 91stage. This means that romstage has a clean program boundary and 92that all variables in romstage can be accessed via their linked 93addresses without runtime resolution. There is no need to link 94global and static variables via the CAR\_GLOBAL macro and no need 95to access them with car\_set/get\_var/ptr functions. 96 97### C\_ENVIRONMENT\_BOOTBLOCK 98 99Historically the bootblock on x86 platforms has been compiled with 100romcc. This means that the generated code only uses CPU registers 101and therefore no stack. This 20K+ LOC compiler is limited and hard 102to maintain and so is the code that one has to write in that 103environment. A different solution is to set up Cache-as-Ram in the 104bootblock and run GCC compiled code in the bootblock. The advantages 105are increased flexibility and consistency with other architectures as 106well as other stages: e.g. printing to console is possible and 107VBOOT can run before romstage, making romstage updatable via RW FMAP 108regions. 109 110### Platforms dropped from master 111 112The following platforms did not implement those feature are dropped 113from master to allow the master branch to move on: 114- AMDFAM10 115- all FSP1.0 platforms: BROADWELL\_DE, FSP\_BAYTRAIL, RANGELEY 116- VIA VX900 117 118In particular on FSP1.0 it is impossible to implement POSTCAR stage. 119The reason is that FSP1.0 relocates the CAR region to the HOB before 120returning to coreboot. This means that after FSP returns to coreboot 121accessing variables via their original address is not possible. One 122way of obtaining that behavior would be to set up Cache-as-Ram again 123(but with open source code) and copy the relocated data from the HOB 124there. This solution is deemed too hacky. Maybe a lesson can be 125learned from this: blobs should not interfere with the execution 126environment, as this makes proper integration much harder. 127 128### 4.11\_branch 129 130Given that some platforms supported by FSP1.0 are being produced and 131popular, the 4.11 release was made into a branch in which further 132development can happen. 133 134Significant changes 135------------------- 136 137### SMMSTORE is now production ready 138 139See [smmstore](../drivers/smmstore.md) for the documentation on 140the API, but note that there will be an update to it featuring a 141much-improved but incompatible API. 142 143### Unit testing infrastructure 144 145Unit testing of coreboot is now possible in a more structured way, with new 146build subsystem and adoption of [Cmocka](https://cmocka.org/) framework. Tree 147has new directory `tests/`, which comprises infrastructure and examples of unit 148tests. See 149[Unit testing coreboot](../technotes/2020-03-unit-testing-coreboot.md) for the 150design document. 151 152Final Notes 153----------- 154 155Your favorite new feature or supported board didn't make it to the 156release notes? They're maintained collaboratively in the coreboot 157tree, so when you land something noteworthy don't be shy, contribute 158to the upcoming release's document in Documentation/releases! 159