summaryrefslogtreecommitdiff
path: root/src/mainboard/foxconn
diff options
context:
space:
mode:
authorJulius Werner <jwerner@chromium.org>2021-05-20 17:00:46 -0700
committerJulius Werner <jwerner@chromium.org>2021-05-27 23:30:42 +0000
commit913a47a32236cac6eae8c707f643616686dc8598 (patch)
tree5493a5fd594d438d6a90120c073eed5ab1905b40 /src/mainboard/foxconn
parent8ad93797d6e1eb2d4be4010e29152636551567fa (diff)
cbmem: Introduce "early" init hooks for console
Over the last couple of years we have continuously added more and more CBMEM init hooks related to different independent components. One disadvantage of the API is that it can not model any dependencies between the different hooks, and their order is essentially undefined (based on link order). For most hooks this is not a problem, and in fact it's probably not a bad thing to discourage implicit dependencies between unrelated components like this... but one resource the components obviously all share is CBMEM, and since many CBMEM init hooks are used to create new CBMEM areas, the arbitrary order means that the order of these areas becomes unpredictable. Generally code using CBMEM should not care where exactly an area is allocated, but one exception is the persistent CBMEM console which relies (on a best effort basis) on always getting allocated at the same address on every boot. This is, technically, a hack, but it's a pretty harmless hack that has served us reasonably well so far and would be difficult to realize in a more robust way (without adding a lot of new infrastructure). Most of the time, coreboot will allocate the same CBMEM areas in the same order with the same sizes on every boot, and this all kinda works out (and since it's only a debug console, we don't need to be afraid of the odd one-in-a-million edge case breaking it). But one reproducible difference we can have between boots is the vboot boot mode (e.g. normal vs. recovery boot), and we had just kinda gotten lucky in the past that we didn't have differences in CBMEM allocations in different boot modes. With the recent addition of the RW_MCACHE (which does not get allocated in recovery mode), this is no longer true, and as a result CBMEM consoles can no longer persist between normal and recovery modes. The somewhat kludgy but simple solution is to just create a new class of specifically "early" CBMEM init hooks that will always run before all the others. While arbitrarily partitioning hooks into "early" and "not early" without any precise definition of what these things mean may seem a bit haphazard, I think it will be good enough in practice for the very few cases where this matters and beats building anything much more complicated (FWIW Linux has been doing something similar for years with device suspend/resume ordering). Since the current use case only relates to CBMEM allocation ordering and you can only really be "first" if you allocate in romstage, the "early" hook is only available in romstage for now (could be expanded later if we find a use case for it). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: If2c849a89f07a87d448ec1edbad4ce404afb0746 Reviewed-on: https://review.coreboot.org/c/coreboot/+/54737 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
Diffstat (limited to 'src/mainboard/foxconn')
0 files changed, 0 insertions, 0 deletions