| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Initialising raw flash lead to a dead assignment to rc. Check the return
code and take the failure path as necessary. Both before and after the
fix we see output along the lines of the following when flash_init()
fails:
[ 53.283182881,7] IRQ: Registering 0800..0ff7 ops @0x300d4b98 (data 0x3052b9d8)
[ 53.283184335,7] IRQ: Registering 0ff8..0fff ops @0x300d4bc8 (data 0x3052b9d8)
[ 53.283185513,7] PHB#0000: Initializing PHB...
[ 53.288260827,4] FLASH: Can't load resource id:0. No system flash found
[ 53.288354442,4] FLASH: Can't load resource id:1. No system flash found
[ 53.342933439,3] CAPP: Error loading ucode lid. index=200ea
[ 53.462749486,2] NVRAM: Failed to load
[ 53.462819095,2] NVRAM: Failed to load
[ 53.462894236,2] NVRAM: Failed to load
[ 53.462967071,2] NVRAM: Failed to load
[ 53.463033077,2] NVRAM: Failed to load
[ 53.463144847,2] NVRAM: Failed to load
Eventually followed by:
[ 57.216942479,5] INIT: platform wait for kernel load failed
[ 57.217051132,5] INIT: Assuming kernel at 0x20000000
[ 57.217127508,3] INIT: ELF header not found. Assuming raw binary.
[ 57.217249886,2] NVRAM: Failed to load
[ 57.221294487,0] FATAL: Kernel is zeros, can't execute!
[ 57.221397429,0] Assert fail: core/init.c:615:0
[ 57.221471414,0] Aborting!
CPU 0028 Backtrace:
S: 0000000031d43c60 R: 000000003001b274 ._abort+0x4c
S: 0000000031d43ce0 R: 000000003001b2f0 .assert_fail+0x34
S: 0000000031d43d60 R: 0000000030014814 .load_and_boot_kernel+0xae4
S: 0000000031d43e30 R: 0000000030015164 .main_cpu_entry+0x680
S: 0000000031d43f00 R: 0000000030002718 boot_entry+0x1c0
--- OPAL boot ---
Analysis of the execution paths suggests we'll always "safely" end this
way due the setup sequence for the blocklevel callbacks in flash_init()
and error handling in blocklevel_get_info(), and there's no current risk
of executing from unexpected memory locations. As such the issue is
reduced to down to a fix for poor error hygene in the original change
and a resolution for a Coverity warning (famous last words etc).
Fixes: c826e1ca9e5b ("astbmc: Try IPMI HIOMAP for P8 (again)")
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The HIOMAP protocol was developed after the release of P8 in preparation
for P9. As a consequence P9 always uses it, but it has rarely been
enabled for P8. P8DTU has recently added IPMI HIOMAP support to its BMC
firmware, so enable its use in skiboot with P8 machines. Doing so
requires some rework to ensure fallback works correctly as in the past
the fallback was to mbox, which will only work for P9.
Tested on Garrison, Palmetto without HIOMAP, Palmetto with HIOMAP, and
Witherspoon.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit bd9839684d482417e8c60449592f4308e9a91dac as it broke
booting on P8 systems, including Garrison (AMI BMC), Firestone (AMI BMC)
and QEMU (BMC simulator).
Issue https://github.com/open-power/skiboot/issues/217 tracks the
failure. The P8 IPMI HIOMAP feature can be re-enabled once this issue is
resolved.
Reported-by: Sam Mendoza-Jonas <sam@mendozajonas.com>
Reported-by: Sam Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Acked-by: Sam Mendoza-Jonas <sam@mendozajonas.com>
Acked-by: Sam Mendoza-Jonas <sam@mendozajonas.com>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Acked-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The HIOMAP protocol was developed after the release of P8 in preparation
for P9. As a consequence P9 always uses it, but it has rarely been
enabled for P8. P8DTU has recently added IPMI HIOMAP support to its BMC
firmware, so enable its use in skiboot with P8 machines. Doing so
requires some rework to ensure fallback works correctly as in the past
the fallback was to mbox, which will only work for P9.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
| |
|
|
|
|
|
|
|
| |
If the IPMI command is not available, fall back to the mailbox
interface.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
[stewart: fix up mbox test]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
| |
|
|
|
|
|
|
| |
Introduce some consistency for readability and make the names better
reflect the nature of the tests.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
| |
|
|
|
|
|
|
|
| |
If the BMC is MBOX protocol aware, request flash reads/writes over the
MBOX regs. This inits the blocklevel for pnor access with mbox-flash.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current flash code was written with only one flash chip, which is
a system_flash (ie. the PNOR image), in mind.
Now that we have mambo bogusdisk flash, we can have many flash chips.
This is resulting in some confusing output messages.
This reworks some of the error paths and warnings to make this more
coherent when we have multiple flash chips.
We assume everything can be a system flash, so I've removed the
is_system_flash parameter from flash_register(). We'll use the first
system flash we find and warn if we find another since discovery order
is not a guaranteed API.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are some functions (notably: erase_chip and set_4b_mode) which cannot
be abstracted away by the blocklevel interface, this means that if they are
really needed (by pflash for example) then at the moment a program like
pflash would need to pass a blocklevel_device struct to libflash.
This forces libflash to trust that it was given a blocklevel that it did
init. If it didn't init it the container_of call will return junk and
libflash has no way to protect its self. This method (while very useful)
has destroyed type safety. As such, this commit reintroduces some
typesafety back into this stack.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
In pnor_init(), there are chances of pointer bl being read before
assignment. Fix it by initializing it to NULL.
Fixes Coverity defect#97868.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Cc: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
| |
Converted all the libflash calls to use the blocklevel interface, modified all
callers to libflash to use the blocklevel interface.
This patch should introduce next to no functional change.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
platforms/astbmc/pnor.c:43:6: error: variable 'pnor_chip' is used uninitialized whenever 'if' condition is true
[-Werror,-Wsometimes-uninitialized]
if (rc) {
^~
platforms/astbmc/pnor.c:58:6: note: uninitialized use occurs here
if (pnor_chip)
^~~~~~~~~
platforms/astbmc/pnor.c:43:2: note: remove the 'if' if its condition is always false
if (rc) {
^~~~~~~~~
platforms/astbmc/pnor.c:30:30: note: initialize the variable 'pnor_chip' to silence this warning
struct flash_chip *pnor_chip;
^
= NULL
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
| |
memboot uses bmc system memory instead of a real flash chip. This
patch adds a flash backend for bmc system memory to allow use of the
memboot tool (in external/memboot) to boot the system.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we want to prevent conflicts between PNOR and NVRAM, this change
moves the flash-nvram handling out of flash-nvram.c and into the generic
flash module. This way, the OPAL_FLASH_{READ,WRITE,ERASE} API won't
conflict with the OPAL_*_NVRAM api.
To do this, we use the flash_register function to look for an "NVRAM"
partition. If one is found, it is automatically registered as the system
NVRAM backend.
We also change the rhesus and astmbc platforms to use the common flash
code.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
| |
Since we have a flash device registered as the system flash, use this as
a generic load_resource backend.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a subid to load_resource() so that sub-partitions can be accessed
inside a PNOR partition. These sub-partitions follow the format used by the
hostboot SBE image.
The subid will match on the EC field of the SBE table of contents. If it's
found, only that sub-partition is returned to the caller.
Current partitions (kernel and ramfs) don't support sub-partitions. If caller
tries to access a sub-partition within these, we fail the call.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
| |
Commit 16c80346 change included some reverts of previous commits, which
we need. This change reverts those reverts, leaving the original intent
of that change.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
| |
Was mentioned in linux as possibly being used by some external test
modules. It's harmless to make this official behaviour.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To date BMC platforms have had their payload built in to the skiboot
binary. This patch adds the option of loading from a flash partition
instead.
This has been tested on palmetto with a separate skiboot and
kernel+rootfs partition. In the future we may have separate kernel and
rootfs, which should just work. For now this is what we see when booting:
[10648940943,5] INIT: Kernel loaded, size: 15728640 bytes (0 = unknown
preload)
[10649094578,5] INIT: 32-bit kernel entry at 0x2001015c
[10649170607,3] PLAT: No ROOTFS partition in PNOR
If the partition named cannot be found, the core loading logic will fall
back to using the built-in payload. In this case, the user gets the
following messages:
[2214557191,3] PLAT: No KERNEL partition in PNOR.
[2220486159,5] INIT: platform kernel load failed.
[2221293286,5] Using built-in kernel.
[2265861935,5] INIT: Kernel loaded, size: 14706638 bytes (0 = unknown
preload).
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
We might have a different BMC in the future..
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
