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=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 E4D1CC48BE5 for ; Wed, 16 Jun 2021 15:12:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C431F61166 for ; Wed, 16 Jun 2021 15:12:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234501AbhFPPOx (ORCPT ); Wed, 16 Jun 2021 11:14:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:44886 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234537AbhFPPOk (ORCPT ); Wed, 16 Jun 2021 11:14:40 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5478361166; Wed, 16 Jun 2021 15:12:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623856354; bh=79yfQdKxv3qf+Uv+p6L1hNCWKPz5Fwg5T6U9zNgNXKw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=BqW78zvfiJFX1WM3aDIknqlHXv25abiaKRQGWflPbVe5mHb8O9l3o/637flx39WEV cxE5w+ImnzJWcupRqiIlSCdWw3mWk3Cx9zyVndQ6dkPj5t43AKjeBGVfcpsgenW4vb OtKupuD0Ntu2vsfS9jGRg8LEs4BP2xDparQODe4NbrpL5Ifi5OWG2B4/P9HW70cQ+p X/YEaHt+LUkVEt4USF3AMG74opsi25veGHPjoUFr0Y86T4K0ypaX1XE8w1CW0XHn0r M7bIYHn+eSLwn7g9EpX8Xjv0jQ72wzH8eddElWFaUDVLoyT0S+osdrecHy6yxIijoO vHMYPlo4SyQqg== Received: by mail-ed1-f53.google.com with SMTP id s15so3141786edt.13; Wed, 16 Jun 2021 08:12:34 -0700 (PDT) X-Gm-Message-State: AOAM532lCtCMzVKAZETEBvNqLjW+kwqaIONtY78GGoD/rm4MyUFmoZhU cQUSrR8lEzHQcUxRceMGzKqrL9sRZpb2GOWMHw== X-Google-Smtp-Source: ABdhPJxABYnhsAzimi3nTGL6QdJk0DeFkDzt1g0oue+DKcU8vorHRba5UMSdbzxFOM1x2Zy6FOyPf8RPn7FkPhkqUPU= X-Received: by 2002:a05:6402:cb0:: with SMTP id cn16mr69518edb.165.1623856342407; Wed, 16 Jun 2021 08:12:22 -0700 (PDT) MIME-Version: 1.0 References: <20210221174930.27324-1-nramas@linux.microsoft.com> <20210221174930.27324-6-nramas@linux.microsoft.com> <54efb4fce5aac7efbd0b1b3885e9098b1d4ea745.camel@linux.microsoft.com> <87y2basg27.fsf@mpe.ellerman.id.au> In-Reply-To: <87y2basg27.fsf@mpe.ellerman.id.au> From: Rob Herring Date: Wed, 16 Jun 2021 09:12:10 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v19 05/13] of: Add a common kexec FDT setup function To: Michael Ellerman Cc: nramas , Geert Uytterhoeven , Mimi Zohar , Thiago Jung Bauermann , AKASHI Takahiro , Greg KH , Will Deacon , Joe Perches , Catalin Marinas , Stephen Rothwell , James Morse , Sasha Levin , Benjamin Herrenschmidt , Paul Mackerras , Frank Rowand , Vincenzo Frascino , Mark Rutland , dmitry.kasatkin@gmail.com, James Morris , "Serge E. Hallyn" , Pavel Tatashin , Allison Randal , Masahiro Yamada , Matthias Brugger , Hsin-Yi Wang , tao.li@vivo.com, Christophe Leroy , Prakhar Srivastava , balajib@linux.microsoft.com, linux-integrity , Linux Kernel Mailing List , Linux ARM , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linuxppc-dev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 15, 2021 at 8:23 PM Michael Ellerman wrote: > > Rob Herring writes: > > On Tue, Jun 15, 2021 at 10:13 AM nramas wrote: > >> > >> On Tue, 2021-06-15 at 08:01 -0600, Rob Herring wrote: > >> > On Tue, Jun 15, 2021 at 6:18 AM Geert Uytterhoeven < > >> > geert@linux-m68k.org> wrote: > >> > > > >> > > > +void *of_kexec_alloc_and_setup_fdt(const struct kimage *image, > >> > > > + unsigned long > >> > > > initrd_load_addr, > >> > > > + unsigned long initrd_len, > >> > > > + const char *cmdline, size_t > >> > > > extra_fdt_size) > >> > > > +{ > >> > > > + /* Did we boot using an initrd? */ > >> > > > + prop = fdt_getprop(fdt, chosen_node, "linux,initrd- > >> > > > start", NULL); > >> > > > + if (prop) { > >> > > > + u64 tmp_start, tmp_end, tmp_size; > >> > > > + > >> > > > + tmp_start = fdt64_to_cpu(*((const fdt64_t *) > >> > > > prop)); > >> > > > + > >> > > > + prop = fdt_getprop(fdt, chosen_node, > >> > > > "linux,initrd-end", NULL); > >> > > > + if (!prop) { > >> > > > + ret = -EINVAL; > >> > > > + goto out; > >> > > > + } > >> > > > + > >> > > > + tmp_end = fdt64_to_cpu(*((const fdt64_t *) > >> > > > prop)); > >> > > > >> > > Some kernel code assumes "linux,initrd-{start,end}" are 64-bit, > >> > > other code assumes 32-bit. > >> > > >> > It can be either. The above code was a merge of arm64 and powerpc >> > both > >> > of which use 64-bit and still only runs on those arches. It looks >> > like > >> > some powerpc platforms may use 32-bit, but this would have been >> > broken > >> > before. > > >> of_kexec_alloc_and_setup_fdt() is called from elf_64.c (in > >> arch/powerpc/kexec) which is for 64-bit powerpc platform only. > > > > 64-bit PPC could be writing 32-bit property values. The architecture > > size doesn't necessarily matter. And if the values came from the > > bootloader, who knows what size it used. > > > > This code is 32-bit powerpc only?: > > > > arch/powerpc/boot/main.c- /* Tell the kernel initrd address via device tree */ > > arch/powerpc/boot/main.c: setprop_val(chosen, "linux,initrd-start", (u32)(initrd_addr)); > > arch/powerpc/boot/main.c- setprop_val(chosen, "linux,initrd-end", (u32)(initrd_addr+initrd_size)); > > Historically that code was always built 32-bit, even when used with a > 64-bit kernel. > > These days it is also built 64-bit (for ppc64le). How it is built is immaterial. It's always writing a 32-bit value due to the u32 cast. > It looks like the drivers/of/fdt.c code can handle either 64 or 32-bit, > so I guess that's why it seems to be working. Yes, that works, but that's not the issue. The question is does the main.c code run in combination with kexec. The kexec code above (copied straight from PPC code) would not work if linux,initrd-* are written by the main.c code. Rob 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=-4.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 A6FB6C48BE5 for ; Wed, 16 Jun 2021 15:14:02 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5FEAE61166 for ; Wed, 16 Jun 2021 15:14:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5FEAE61166 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=G1uvsbVMUQGJX13/AYByV7/UoFjl62sSDC5MYUGx67Y=; b=eFtKcLcfnRLhE/ jISDC610XnPy1SK9BfGkmS8bBuF7rWvJ84NIeZdKT/8PbflW77opZcmMdKG/UKgc9EshyVGxzuihP W0X1Pw2999zclTPAh/YndP1K0kJLzg1fLNgzo6LfldV2JGg58G2pjkGu7YeMbgV1mVV8Wz2p34FB8 aKvBWYaj2QIR+3NGGjfM82HMMA5qdbd29leJAh0gellXoO2JbJpWY03nDc1kgeZ6UILfK8B7r5XDB ijQ+u/luoWSsGdM3VaZA/05GDtAMPXBtGQVL3YljjYzS2UjC73xkngCsGovUIbICreNqFkQ8W5Gf0 3RCF1eKCLnJrhLfEDVxA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltXDa-006qMI-Kk; Wed, 16 Jun 2021 15:12:38 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltXDX-006qLq-Dy for linux-arm-kernel@lists.infradead.org; Wed, 16 Jun 2021 15:12:36 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 197EF611CE for ; Wed, 16 Jun 2021 15:12:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623856355; bh=79yfQdKxv3qf+Uv+p6L1hNCWKPz5Fwg5T6U9zNgNXKw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=cql5GZtsqAlbBvn/G1wOb8+9xZ4PTtvaPV1TqiBZl3uU6JrChuxc1ZYMZZdShqJif 8gTeOL14pIsJ/k0rmWC3G95FH3kPhRSvJpwAtPv8Q0D+3MBm01NkLxf8xrQ61hqfzr YScfDxEw8MG09Q/oqXiaOAR9t60KbsBrgGxBqjCkxR4ODVGLoPH98cEfoMgvBedj1C 8xhMK0xytV35wwzl1eBGDlsudUnN6QppOYMkRuv/dOMV/J7YRh/LAAHpkllGWemk88 hnxzXQseFmdJhXxpe7cWoOcgJJxEr7HJxV9L8ymkahCez/ye17yEbwbtdP7KCCcSAS 0x5CxH4WFREgA== Received: by mail-lj1-f170.google.com with SMTP id l15so98235lje.10 for ; Wed, 16 Jun 2021 08:12:35 -0700 (PDT) X-Gm-Message-State: AOAM533A34m2fS/m3IWw2aezYHdrOhJM1XnSfqjPm5yUp6zbbY63kmP/ R5LP8dErtRQRp1r9UmTfWWFx9hAqqidxT6eUjw== X-Google-Smtp-Source: ABdhPJxABYnhsAzimi3nTGL6QdJk0DeFkDzt1g0oue+DKcU8vorHRba5UMSdbzxFOM1x2Zy6FOyPf8RPn7FkPhkqUPU= X-Received: by 2002:a05:6402:cb0:: with SMTP id cn16mr69518edb.165.1623856342407; Wed, 16 Jun 2021 08:12:22 -0700 (PDT) MIME-Version: 1.0 References: <20210221174930.27324-1-nramas@linux.microsoft.com> <20210221174930.27324-6-nramas@linux.microsoft.com> <54efb4fce5aac7efbd0b1b3885e9098b1d4ea745.camel@linux.microsoft.com> <87y2basg27.fsf@mpe.ellerman.id.au> In-Reply-To: <87y2basg27.fsf@mpe.ellerman.id.au> From: Rob Herring Date: Wed, 16 Jun 2021 09:12:10 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v19 05/13] of: Add a common kexec FDT setup function To: Michael Ellerman Cc: nramas , Geert Uytterhoeven , Mimi Zohar , Thiago Jung Bauermann , AKASHI Takahiro , Greg KH , Will Deacon , Joe Perches , Catalin Marinas , Stephen Rothwell , James Morse , Sasha Levin , Benjamin Herrenschmidt , Paul Mackerras , Frank Rowand , Vincenzo Frascino , Mark Rutland , dmitry.kasatkin@gmail.com, James Morris , "Serge E. Hallyn" , Pavel Tatashin , Allison Randal , Masahiro Yamada , Matthias Brugger , Hsin-Yi Wang , tao.li@vivo.com, Christophe Leroy , Prakhar Srivastava , balajib@linux.microsoft.com, linux-integrity , Linux Kernel Mailing List , Linux ARM , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linuxppc-dev X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210616_081235_543182_62A2C3BE X-CRM114-Status: GOOD ( 30.39 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jun 15, 2021 at 8:23 PM Michael Ellerman wrote: > > Rob Herring writes: > > On Tue, Jun 15, 2021 at 10:13 AM nramas wrote: > >> > >> On Tue, 2021-06-15 at 08:01 -0600, Rob Herring wrote: > >> > On Tue, Jun 15, 2021 at 6:18 AM Geert Uytterhoeven < > >> > geert@linux-m68k.org> wrote: > >> > > > >> > > > +void *of_kexec_alloc_and_setup_fdt(const struct kimage *image, > >> > > > + unsigned long > >> > > > initrd_load_addr, > >> > > > + unsigned long initrd_len, > >> > > > + const char *cmdline, size_t > >> > > > extra_fdt_size) > >> > > > +{ > >> > > > + /* Did we boot using an initrd? */ > >> > > > + prop = fdt_getprop(fdt, chosen_node, "linux,initrd- > >> > > > start", NULL); > >> > > > + if (prop) { > >> > > > + u64 tmp_start, tmp_end, tmp_size; > >> > > > + > >> > > > + tmp_start = fdt64_to_cpu(*((const fdt64_t *) > >> > > > prop)); > >> > > > + > >> > > > + prop = fdt_getprop(fdt, chosen_node, > >> > > > "linux,initrd-end", NULL); > >> > > > + if (!prop) { > >> > > > + ret = -EINVAL; > >> > > > + goto out; > >> > > > + } > >> > > > + > >> > > > + tmp_end = fdt64_to_cpu(*((const fdt64_t *) > >> > > > prop)); > >> > > > >> > > Some kernel code assumes "linux,initrd-{start,end}" are 64-bit, > >> > > other code assumes 32-bit. > >> > > >> > It can be either. The above code was a merge of arm64 and powerpc >> > both > >> > of which use 64-bit and still only runs on those arches. It looks >> > like > >> > some powerpc platforms may use 32-bit, but this would have been >> > broken > >> > before. > > >> of_kexec_alloc_and_setup_fdt() is called from elf_64.c (in > >> arch/powerpc/kexec) which is for 64-bit powerpc platform only. > > > > 64-bit PPC could be writing 32-bit property values. The architecture > > size doesn't necessarily matter. And if the values came from the > > bootloader, who knows what size it used. > > > > This code is 32-bit powerpc only?: > > > > arch/powerpc/boot/main.c- /* Tell the kernel initrd address via device tree */ > > arch/powerpc/boot/main.c: setprop_val(chosen, "linux,initrd-start", (u32)(initrd_addr)); > > arch/powerpc/boot/main.c- setprop_val(chosen, "linux,initrd-end", (u32)(initrd_addr+initrd_size)); > > Historically that code was always built 32-bit, even when used with a > 64-bit kernel. > > These days it is also built 64-bit (for ppc64le). How it is built is immaterial. It's always writing a 32-bit value due to the u32 cast. > It looks like the drivers/of/fdt.c code can handle either 64 or 32-bit, > so I guess that's why it seems to be working. Yes, that works, but that's not the issue. The question is does the main.c code run in combination with kexec. The kexec code above (copied straight from PPC code) would not work if linux,initrd-* are written by the main.c code. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 0E097C48BE8 for ; Wed, 16 Jun 2021 15:13:06 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8324260FDB for ; Wed, 16 Jun 2021 15:13:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8324260FDB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4G4pbN3C3nz3c1D for ; Thu, 17 Jun 2021 01:13:04 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=BqW78zvf; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=robh@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=BqW78zvf; dkim-atps=neutral Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4G4pZt2PXBz306n for ; Thu, 17 Jun 2021 01:12:38 +1000 (AEST) Received: by mail.kernel.org (Postfix) with ESMTPSA id 2A96360FDB for ; Wed, 16 Jun 2021 15:12:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623856354; bh=79yfQdKxv3qf+Uv+p6L1hNCWKPz5Fwg5T6U9zNgNXKw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=BqW78zvfiJFX1WM3aDIknqlHXv25abiaKRQGWflPbVe5mHb8O9l3o/637flx39WEV cxE5w+ImnzJWcupRqiIlSCdWw3mWk3Cx9zyVndQ6dkPj5t43AKjeBGVfcpsgenW4vb OtKupuD0Ntu2vsfS9jGRg8LEs4BP2xDparQODe4NbrpL5Ifi5OWG2B4/P9HW70cQ+p X/YEaHt+LUkVEt4USF3AMG74opsi25veGHPjoUFr0Y86T4K0ypaX1XE8w1CW0XHn0r M7bIYHn+eSLwn7g9EpX8Xjv0jQ72wzH8eddElWFaUDVLoyT0S+osdrecHy6yxIijoO vHMYPlo4SyQqg== Received: by mail-lf1-f41.google.com with SMTP id p17so4913762lfc.6 for ; Wed, 16 Jun 2021 08:12:34 -0700 (PDT) X-Gm-Message-State: AOAM530m/TRt5FOCbyLvgU2jIAA3ojKzfG9u+gA35B0xDpRQBjdmxaMn d8V/6sx1goJptKcFkTbxmmQ57r9f4faZRC63Mg== X-Google-Smtp-Source: ABdhPJxABYnhsAzimi3nTGL6QdJk0DeFkDzt1g0oue+DKcU8vorHRba5UMSdbzxFOM1x2Zy6FOyPf8RPn7FkPhkqUPU= X-Received: by 2002:a05:6402:cb0:: with SMTP id cn16mr69518edb.165.1623856342407; Wed, 16 Jun 2021 08:12:22 -0700 (PDT) MIME-Version: 1.0 References: <20210221174930.27324-1-nramas@linux.microsoft.com> <20210221174930.27324-6-nramas@linux.microsoft.com> <54efb4fce5aac7efbd0b1b3885e9098b1d4ea745.camel@linux.microsoft.com> <87y2basg27.fsf@mpe.ellerman.id.au> In-Reply-To: <87y2basg27.fsf@mpe.ellerman.id.au> From: Rob Herring Date: Wed, 16 Jun 2021 09:12:10 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v19 05/13] of: Add a common kexec FDT setup function To: Michael Ellerman Content-Type: text/plain; charset="UTF-8" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , tao.li@vivo.com, Mimi Zohar , Paul Mackerras , Vincenzo Frascino , Frank Rowand , Sasha Levin , Stephen Rothwell , nramas , Will Deacon , Masahiro Yamada , James Morris , AKASHI Takahiro , Geert Uytterhoeven , Linux ARM , Catalin Marinas , "Serge E. Hallyn" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Pavel Tatashin , Prakhar Srivastava , Hsin-Yi Wang , Allison Randal , Christophe Leroy , Matthias Brugger , balajib@linux.microsoft.com, dmitry.kasatkin@gmail.com, Linux Kernel Mailing List , James Morse , Greg KH , Joe Perches , linux-integrity , linuxppc-dev , Thiago Jung Bauermann Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, Jun 15, 2021 at 8:23 PM Michael Ellerman wrote: > > Rob Herring writes: > > On Tue, Jun 15, 2021 at 10:13 AM nramas wrote: > >> > >> On Tue, 2021-06-15 at 08:01 -0600, Rob Herring wrote: > >> > On Tue, Jun 15, 2021 at 6:18 AM Geert Uytterhoeven < > >> > geert@linux-m68k.org> wrote: > >> > > > >> > > > +void *of_kexec_alloc_and_setup_fdt(const struct kimage *image, > >> > > > + unsigned long > >> > > > initrd_load_addr, > >> > > > + unsigned long initrd_len, > >> > > > + const char *cmdline, size_t > >> > > > extra_fdt_size) > >> > > > +{ > >> > > > + /* Did we boot using an initrd? */ > >> > > > + prop = fdt_getprop(fdt, chosen_node, "linux,initrd- > >> > > > start", NULL); > >> > > > + if (prop) { > >> > > > + u64 tmp_start, tmp_end, tmp_size; > >> > > > + > >> > > > + tmp_start = fdt64_to_cpu(*((const fdt64_t *) > >> > > > prop)); > >> > > > + > >> > > > + prop = fdt_getprop(fdt, chosen_node, > >> > > > "linux,initrd-end", NULL); > >> > > > + if (!prop) { > >> > > > + ret = -EINVAL; > >> > > > + goto out; > >> > > > + } > >> > > > + > >> > > > + tmp_end = fdt64_to_cpu(*((const fdt64_t *) > >> > > > prop)); > >> > > > >> > > Some kernel code assumes "linux,initrd-{start,end}" are 64-bit, > >> > > other code assumes 32-bit. > >> > > >> > It can be either. The above code was a merge of arm64 and powerpc >> > both > >> > of which use 64-bit and still only runs on those arches. It looks >> > like > >> > some powerpc platforms may use 32-bit, but this would have been >> > broken > >> > before. > > >> of_kexec_alloc_and_setup_fdt() is called from elf_64.c (in > >> arch/powerpc/kexec) which is for 64-bit powerpc platform only. > > > > 64-bit PPC could be writing 32-bit property values. The architecture > > size doesn't necessarily matter. And if the values came from the > > bootloader, who knows what size it used. > > > > This code is 32-bit powerpc only?: > > > > arch/powerpc/boot/main.c- /* Tell the kernel initrd address via device tree */ > > arch/powerpc/boot/main.c: setprop_val(chosen, "linux,initrd-start", (u32)(initrd_addr)); > > arch/powerpc/boot/main.c- setprop_val(chosen, "linux,initrd-end", (u32)(initrd_addr+initrd_size)); > > Historically that code was always built 32-bit, even when used with a > 64-bit kernel. > > These days it is also built 64-bit (for ppc64le). How it is built is immaterial. It's always writing a 32-bit value due to the u32 cast. > It looks like the drivers/of/fdt.c code can handle either 64 or 32-bit, > so I guess that's why it seems to be working. Yes, that works, but that's not the issue. The question is does the main.c code run in combination with kexec. The kexec code above (copied straight from PPC code) would not work if linux,initrd-* are written by the main.c code. Rob