[coreboot] Further coreboot releases, setting new standards

[Patrick Rudolph]

On 2018-11-23 04:32 PM, Arthur Heymans wrote:
> Patrick Georgi via coreboot <coreboot at coreboot.org> writes:
> 
>> Am Fr., 23. Nov. 2018 um 14:43 Uhr schrieb Arthur Heymans <arthur at aheymans.xyz>:
>>
>>  I'd argue for requiring the following:
>>
>> In which time frame? The next release, ie May 2019? In two releases,
>> November 2019?
>>
> That is indeed worthy item of discussion.
> 
> NO_RELOCATABLE_RAMSTAGE on x86 is only selected by:
> NORTHBRIDGE_AMD_AMDFAM10,
> NORTHBRIDGE_AMD_LX,
> NORTHBRIDGE_VIA_VX900,
> SOC_INTEL_FSP_BAYTRAIL,
> SOC_INTEL_FSP_BROADWELL_DE
> 
> POSTCAR_STAGE is selected by:
> cpu/amd/agesa
> cpu/amd/pi
> mainboard/intel/galileo
> northbridge/intel/i440bx
> northbridge/intel/i945
> northbridge/intel/e7505
> northbridge/intel/gm45
> northbridge/intel/haswell
> northbridge/intel/nehalem
> northbridge/intel/pineview
> northbridge/intel/sandybridge
> northbridge/intel/sandybridge
> northbridge/intel/x4x
> soc/amd/stoneyridge
> soc/intel/apollolake
> soc/intel/cannonlake
> soc/intel/denverton_ns
> soc/intel/skylake
> soc/intel/icelake
> so all other x86 targets don't implement it and therefore lack
> NO_CAR_GLOBAL_MIGRATION.
> 
Not sure what to do here. I haven't looked at it and there's no
documentation.
> 
> C_ENVIRONMENT_BOOTBLOCK is even less used since it is a relatively new
> feature (was introduced with INTEL_APOLLOLAKE and INTEL_SKYLAKE) so most
> x86 targets don't implement it but there are already many patches for it lying
> around for review (like most targets in northbridge/intel/*). It is
> however a very useful feature to have.
> 
> So it would seem reasonable to drop NO_RELOCATABLE_RAMSTAGE in may 2019
> and mandate NO_CAR_GLOBAL_MIGRATION and C_ENVIRONMENT_BOOTBLOCK in
> november 2019? Any thoughts on this?
> 
Sound like a good plan.
All maintainers (via git log/gerrit/MAINTAINERS) should be notified now,
if this is going to happen, to make sure that they are aware of the
(bad) code quality. I don't think that it'll be a problem of time or
money if everybody has been properly warned.

> Nico also suggested to set the timeframe 2 weeks before the release, to
> avoid last minute WIP patches attempting to tackle the issue right
> before the release.
> 
> -- 
> ==============
> Arthur Heymans