Documentation/releases/coreboot-4.12-relnotes.md

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