[Skiboot] [PATCH v4 10/18] hdata: Create ibm,dump DT node

[Stewart Smith]

Vasant Hegde <hegdevasant at linux.vnet.ibm.com> writes:
> We use MPIPL system parameter to detect whether MPIPL is supported or not.
> If its supported create new device tree node (/ibm,dump) to pass all dump
> related information to kernel. This patch creates new node and populates
> below properties:
>   - compatible   - ibm,dump version
>   - fw-load-area - Memory used by OPAL to load kernel/initrd from PNOR
>                    (KERNEL_LOAD_BASE & INITRAMFS_LOAD_BASE)
>                    This is the temporary memory used by OPAL during boot.
> 		   Later Linux kernel is free to use this memory. We will
> 		   pass this information to Linux. If Linux kernel is using
> 		   these memory it will take necessary steps to make sure
> 		   OPAL stomping these memory doesn't impact kernel
> 		   dump.

Thinking through this a bit, I don't think we can completely accurately
tell the kernel this, as if we've done something like a firmware update
followed by a dump we *could* (depending on BMC implementation) end up
getting a different PAYLOAD than we originally booted with, using a
different amount of memory.

If the aim is to have the kernel not have any memory in this range
needing to be dumped, wouldn't we have that knowledge in firmware and be
able to work around it for the kernel?

>
> Signed-off-by: Vasant Hegde <hegdevasant at linux.vnet.ibm.com>
> ---
>  hdata/spira.c | 23 +++++++++++++++++++++++
>  hdata/spira.h |  1 +
>  2 files changed, 24 insertions(+)
>
> diff --git a/hdata/spira.c b/hdata/spira.c
> index 9d968fbcb..82928af53 100644
> --- a/hdata/spira.c
> +++ b/hdata/spira.c
> @@ -1030,6 +1030,25 @@ static void dt_init_secureboot_node(const struct iplparams_sysparams *sysparams)
>  	dt_add_property_cells(node, "hw-key-hash-size", hw_key_hash_size);
>  }
>
> +static void fadump_add_node(void)
> +{
> +	u64 fw_load_area[4];
> +	struct dt_node *node;
> +
> +	if (proc_gen < proc_gen_p9)
> +		return;
> +
> +	node = dt_new(dt_root, "ibm,dump");

This should probably come under /ibm,opal/ rather than root.

> +	assert(node);
> +	dt_add_property_string(node, "compatible", "ibm,opal-dump-v1");

We can probably leave off the 'v1' as it's going to be implied.

-- 
Stewart Smith
OPAL Architect, IBM.