aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAndrew Jeffery <andrew@aj.id.au>2019-03-25 18:15:58 +1030
committerStewart Smith <stewart@linux.ibm.com>2019-03-28 15:24:12 +1100
commitcccf5d79de07844cf095b8f45146b92944d15c2e (patch)
treed6b0f677ef416bcdf0514d410885f516a71f3da8
parentbbcbbd3e071ffe654596ce19ddf8d99b4176bbc3 (diff)
downloadskiboot-cccf5d79de07844cf095b8f45146b92944d15c2e.zip
skiboot-cccf5d79de07844cf095b8f45146b92944d15c2e.tar.gz
skiboot-cccf5d79de07844cf095b8f45146b92944d15c2e.tar.bz2
core/flash: Retry requests as necessary in flash_load_resource()
We would like to successfully boot if we have a dependency on the BMC for flash even if the BMC is not current ready to service flash requests. On the assumption that it will become ready, retry for several minutes to cover a BMC reboot cycle and *eventually* rather than *immediately* crash out with: [ 269.549748] reboot: Restarting system [ 390.297462587,5] OPAL: Reboot request... [ 390.297737995,5] RESET: Initiating fast reboot 1... [ 391.074707590,5] Clearing unused memory: [ 391.075198880,5] PCI: Clearing all devices... [ 391.075201618,7] Clearing region 201ffe000000-201fff800000 [ 391.086235699,5] PCI: Resetting PHBs and training links... [ 391.254089525,3] FFS: Error 17 reading flash header [ 391.254159668,3] FLASH: Can't open ffs handle: 17 [ 392.307245135,5] PCI: Probing slots... [ 392.363723191,5] PCI Summary: ... [ 393.423255262,5] OCC: All Chip Rdy after 0 ms [ 393.453092828,5] INIT: Starting kernel at 0x20000000, fdt at 0x30800a88 390645 bytes [ 393.453202605,0] FATAL: Kernel is zeros, can't execute! [ 393.453247064,0] Assert fail: core/init.c:593:0 [ 393.453289682,0] Aborting! CPU 0040 Backtrace: S: 0000000031e03ca0 R: 000000003001af60 ._abort+0x4c S: 0000000031e03d20 R: 000000003001afdc .assert_fail+0x34 S: 0000000031e03da0 R: 00000000300146d8 .load_and_boot_kernel+0xb30 S: 0000000031e03e70 R: 0000000030026cf0 .fast_reboot_entry+0x39c S: 0000000031e03f00 R: 0000000030002a4c fast_reset_entry+0x2c --- OPAL boot --- The OPAL flash API hooks directly into the blocklevel layer, so there's no delay for e.g. the host kernel, just for asynchronously loaded resources during boot. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
-rw-r--r--core/flash.c33
1 files changed, 31 insertions, 2 deletions
diff --git a/core/flash.c b/core/flash.c
index 90189dd..1ed4260 100644
--- a/core/flash.c
+++ b/core/flash.c
@@ -29,6 +29,7 @@
#include <libstb/trustedboot.h>
#include <libxz/xz.h>
#include <elf.h>
+#include <timebase.h>
struct flash {
struct list_node list;
@@ -765,10 +766,18 @@ int flash_resource_loaded(enum resource_id id, uint32_t subid)
return rc;
}
+/*
+ * Retry for 10 minutes in 5 second intervals: allow 5 minutes for a BMC reboot
+ * (need the BMC if we're using HIOMAP flash access), then 2x for some margin.
+ */
+#define FLASH_LOAD_WAIT_MS 5000
+#define FLASH_LOAD_RETRIES (2 * 5 * (60 / (FLASH_LOAD_WAIT_MS / 1000)))
+
static void flash_load_resources(void *data __unused)
{
struct flash_load_resource_item *r;
- int result;
+ int retries = FLASH_LOAD_RETRIES;
+ int result = OPAL_RESOURCE;
lock(&flash_load_resource_lock);
do {
@@ -783,11 +792,31 @@ static void flash_load_resources(void *data __unused)
r->result = OPAL_BUSY;
unlock(&flash_load_resource_lock);
- result = flash_load_resource(r->id, r->subid, r->buf, r->len);
+ while (retries) {
+ result = flash_load_resource(r->id, r->subid, r->buf,
+ r->len);
+ if (result == OPAL_SUCCESS) {
+ retries = FLASH_LOAD_RETRIES;
+ break;
+ }
+
+ if (result != FLASH_ERR_AGAIN &&
+ result != FLASH_ERR_DEVICE_GONE)
+ break;
+
+ time_wait_ms(FLASH_LOAD_WAIT_MS);
+
+ retries--;
+
+ prlog(PR_WARNING,
+ "FLASH: Retrying load of %d:%d, %d attempts remain\n",
+ r->id, r->subid, retries);
+ }
lock(&flash_load_resource_lock);
r = list_pop(&flash_load_resource_queue,
struct flash_load_resource_item, link);
+ /* Will reuse the result from when we hit retries == 0 */
r->result = result;
list_add_tail(&flash_loaded_resources, &r->link);
} while(true);