From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4CF26C48BE6 for ; Wed, 16 Jun 2021 14:55:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0B0C26115C for ; Wed, 16 Jun 2021 14:55:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234142AbhFPO5X (ORCPT ); Wed, 16 Jun 2021 10:57:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:40994 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234087AbhFPO5W (ORCPT ); Wed, 16 Jun 2021 10:57:22 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id C1E176105A; Wed, 16 Jun 2021 14:55:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623855316; bh=AxlyDycZpX8N+vmFuWI19Sd23V+DuNrgeU3nJ9fSOlQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=QbxJDVCXZCiJeF3/Q66YYkQXX8XrqQWunoHlN3fz7MvO3OBOJzfBaIE1+y9uV3EAJ 7ZOnQOUax/KFmkvtfDUou8wXJ0FfPxJ4kcKXYjibBCJdFoN5AgHrlcU9CuAk4qCvlw zLTuWne2oMrfffRAnHML8LSecawZJ9nk0RmoqKCSYZh8Z9k8REa/NtJtsTmhlIcV+3 ZIDmMzY3L8+UFaPWf88q3/7ddG2zmUdCL/6pwINt3fHenvC3PuKC/nnYWq23IPE5Nm lrqlsLz6YFDCi9nBadTiG2yRnNxG98sePhSk02i2zImkAJwuFwFs6frHPbEhyjfmgV h1jU+qvK6TdTg== Received: by mail-ej1-f41.google.com with SMTP id ce15so4411016ejb.4; Wed, 16 Jun 2021 07:55:16 -0700 (PDT) X-Gm-Message-State: AOAM531x7aUGMl6u3nY7EwpG0GTrXvjqxoPRQDu48/ZpAHSqHq3k+fLK VCKUy2nhapZxTNAWvfcxbyydHuygUoP+2zjyuw== X-Google-Smtp-Source: ABdhPJwrM8JUB7d5DGbvDUmM8cwcGPrXjP07+dvcNQN2Yqm0+3CnQUECrHvdmK6ajaK5xuXmYOM66M46eB/vWGyFWYM= X-Received: by 2002:a17:906:9419:: with SMTP id q25mr163961ejx.341.1623855315390; Wed, 16 Jun 2021 07:55:15 -0700 (PDT) MIME-Version: 1.0 References: <20210419005539.22729-1-mick@ics.forth.gr> <20210419005539.22729-6-mick@ics.forth.gr> In-Reply-To: From: Rob Herring Date: Wed, 16 Jun 2021 08:55:02 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 5/5] RISC-V: Add crash kernel support To: Nick Kossifidis , Ard Biesheuvel Cc: Geert Uytterhoeven , linux-riscv , Palmer Dabbelt , Paul Walmsley , Linux Kernel Mailing List , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org +Ard On Tue, Jun 15, 2021 at 5:29 PM Nick Kossifidis wrote: > > =CE=A3=CF=84=CE=B9=CF=82 2021-06-15 22:21, Rob Herring =CE=AD=CE=B3=CF=81= =CE=B1=CF=88=CE=B5: > > On Tue, Jun 15, 2021 at 12:48 PM Geert Uytterhoeven > > wrote: > >> > >> Hi Nick, > >> > >> On Tue, Jun 15, 2021 at 8:29 PM Nick Kossifidis > >> wrote: > >> > =CE=A3=CF=84=CE=B9=CF=82 2021-06-15 16:19, Geert Uytterhoeven =CE=AD= =CE=B3=CF=81=CE=B1=CF=88=CE=B5: > >> > > This does not match > >> > > https://github.com/devicetree-org/dt-schema/blob/master/schemas/ch= osen.yaml#L77: > >> > > > >> > > $ref: types.yaml#/definitions/uint64-array > >> > > maxItems: 2 > >> > > description: > >> > > This property (currently used only on arm64) holds the memor= y > >> > > range, > >> > > the address and the size, of the elf core header which mainl= y > >> > > 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,elfcore= hdr". > >> > > > >> > > >> > That's a binding for a property on the /chosen node, that as the tex= t > >> > says it's defined for arm64 only and the code that handled it was al= so > >> > >> 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