+Ard

On Tue, Jun 15, 2021 at 5:29 PM Nick Kossifidis [off-list ref] wrote:

Στις 2021-06-15 22:21, Rob Herring έγραψε:

quoted

On Tue, Jun 15, 2021 at 12:48 PM Geert Uytterhoeven
[off-list ref] wrote:

quoted

Hi Nick,

On Tue, Jun 15, 2021 at 8:29 PM Nick Kossifidis [off-list ref]
wrote:

quoted

Στις 2021-06-15 16:19, Geert Uytterhoeven έγραψε:

quoted

This does not match
https://github.com/devicetree-org/dt-schema/blob/master/schemas/chosen.yaml#L77:

    $ref: types.yaml#/definitions/uint64-array
    maxItems: 2
    description:
      This property (currently used only on arm64) holds the memory
range,
      the address and the size, of the elf core header which mainly
describes
      the panicked kernel\'s memory layout as PT_LOAD segments of elf
format.

Hence "linux,elfcorehdr" should be a property of the /chosen node,
instead of a memory node with a compatible value of "linux,elfcorehdr".

That's a binding for a property on the /chosen node, that as the text
says it's defined for arm64 only and the code that handled it was also

That doesn't mean it must not be used on other architectures ;-)
Arm64 was just the first one to use it...

It is used on arm64 because memory is often passed by UEFI tables and
not with /memory node. As riscv is also supporting EFI, I'd think they
would do the same.

We've had this discussion before, riscv uses /memory for now and even if
we switched to getting memory from ACPI/UEFI tables, the elf core header
is passed from the crashed kernel to the kdump kernel, it has nothing to
do with UEFI since the bootloader is the kernel itself. Am I missing
something ?

I believe if we originally booted using UEFI tables, then those are
passed the kdump kernel as well. The original DT may have had a
/memory node, but it's possible it didn't match what was in the UEFI
tables. So using the DT /memory nodes for kdump could give surprising
results. I think reserved regions also come from UEFI. Ard can
probably comment better.

Rob