diff options
author | Cyril Bur <cyril.bur@au1.ibm.com> | 2017-12-01 14:53:07 +1100 |
---|---|---|
committer | Stewart Smith <stewart@linux.vnet.ibm.com> | 2017-11-30 23:45:45 -0600 |
commit | 92813a8bf9f3658dac5315c0c02025b74a8b0533 (patch) | |
tree | 3f06738611476b2cc7108ab5106a07027c3381d0 /doc | |
parent | ac685bccd8899b6021f6441551e845151a9a1b94 (diff) | |
download | skiboot-92813a8bf9f3658dac5315c0c02025b74a8b0533.zip skiboot-92813a8bf9f3658dac5315c0c02025b74a8b0533.tar.gz skiboot-92813a8bf9f3658dac5315c0c02025b74a8b0533.tar.bz2 |
nvram: Fix 'missing' nvram on FSP systems.
commit ba4d46fdd9eb ("console: Set log level from nvram") wants to read
from NVRAM rather early. This works fine on BMC based systems as
nvram_init() is actually synchronous. This is not true for FSP systems
and it turns out that the query for the console log level simply
queries blank nvram.
The simple fix is to wait for the NVRAM read to complete before
performing any query. Unfortunately it turns out that the fsp-nvram
code does not inform the generic NVRAM layer when the read is complete,
rather, it must be prompted to do so.
This patch addresses both these problems. This patch adds a check before
the first read of the NVRAM (for the console log level) that the read
has completed. The fsp-nvram code has been updated to inform the generic
layer as soon as the read completes.
The old prompt to the fsp-nvram code has been removed but a check to
ensure that the NVRAM has been loaded remains. It is conservative but
if the NVRAM is not done loading before the host is booted it will not
have an nvram device-tree node which means it won't be able to access
the NVRAM at all, ever, even after the NVRAM has loaded.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Diffstat (limited to 'doc')
0 files changed, 0 insertions, 0 deletions