aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>2015-03-30 23:50:18 +0530
committerStewart Smith <stewart@linux.vnet.ibm.com>2015-03-31 15:42:37 +1100
commit16f965ed2ce85eed76592a82f89964fb20bbe5c9 (patch)
treec1e5876971f65091dbde5f6c4cfb37aa2d13a5cd
parent4175cff8a558e6769006b2638ed9198f088c714a (diff)
downloadskiboot-16f965ed2ce85eed76592a82f89964fb20bbe5c9.zip
skiboot-16f965ed2ce85eed76592a82f89964fb20bbe5c9.tar.gz
skiboot-16f965ed2ce85eed76592a82f89964fb20bbe5c9.tar.bz2
opal: Fix an issue where partial LID load causes opal to hang.skiboot-5.0-rc2
commit c789772 introduced an asynchronous mechanism to load LID resource for FSP systems. But after this change some of the FSP based system failed to load/boot petitboot kernel. While fetching LID resource in multiple chunks, we depend on return status from FSP whether there is more data available to fetch or not. As per FSP mailbox documentation, fetch cmd returns status=2 which means, there is more data pending, and status=0 means we have reached end-of-file. But in reality FSP don't behave as per the document. It looks like we always get status=0 irrespective of whether end of file is reached or not. The old implementation (fsp_sync_msg) used to rely on (wlen < chunk) check to decide whether we reached end of file or not. Ideally, FSP folks should be fix their code as per documentation. But until they do, adding the old check back here again. Without this patch some system won't be able to boot into petitboot kernel. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
-rw-r--r--hw/fsp/fsp.c17
1 files changed, 16 insertions, 1 deletions
diff --git a/hw/fsp/fsp.c b/hw/fsp/fsp.c
index e5a3c1d..c57052f 100644
--- a/hw/fsp/fsp.c
+++ b/hw/fsp/fsp.c
@@ -2156,6 +2156,7 @@ struct fsp_fetch_lid_item {
void *buffer;
size_t *length;
size_t remaining;
+ size_t chunk_requested;
struct list_node link;
int result;
};
@@ -2269,7 +2270,20 @@ static void fsp_fetch_lid_complete(struct fsp_msg *msg)
return;
}
- if (rc == 0)
+ /*
+ * As per documentation, rc=2 means end of file not reached and
+ * rc=1 means we reached end of file. But it looks like we always
+ * get rc=0 irrespective of whether end of file is reached or not.
+ * The old implementation (fsp_sync_msg) used to rely on
+ * (wlen < chunk) to decide whether we reached end of file.
+ *
+ * Ideally FSP folks should be fix their code as per documentation.
+ * but until they do, adding the old check (hack) here again.
+ *
+ * Without this hack some systems would load partial lid and won't
+ * be able to boot into petitboot kernel.
+ */
+ if (rc == 0 && (wlen < last->chunk_requested))
last->result = OPAL_SUCCESS;
fsp_freemsg(msg);
@@ -2317,6 +2331,7 @@ static void fsp_fetch_lid_next_chunk(struct fsp_fetch_lid_item *last)
if (chunk > (PSI_DMA_FETCH_SIZE - boff))
chunk = PSI_DMA_FETCH_SIZE - boff;
last->bsize = ((boff + chunk) + TCE_MASK) & ~TCE_MASK;
+ last->chunk_requested = chunk;
prlog(PR_DEBUG, "FSP: Loading Chunk 0x%08x bytes balign=%llx"
" boff=%llx bsize=%llx\n",