From patchwork Mon Feb 24 22:19:48 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Atish Patra X-Patchwork-Id: 1243597 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=wdc.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=wdc.com header.i=@wdc.com header.a=rsa-sha256 header.s=dkim.wdc.com header.b=Cf3IFkFQ; dkim-atps=neutral Received: from phobos.denx.de (phobos.denx.de [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 48RGjp6VV6z9sP7 for ; Tue, 25 Feb 2020 09:20:55 +1100 (AEDT) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id AB3F481260; Mon, 24 Feb 2020 23:20:40 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=wdc.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=wdc.com header.i=@wdc.com header.b="Cf3IFkFQ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 34D928126C; Mon, 24 Feb 2020 23:20:38 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_HELO_NONE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from esa5.hgst.iphmx.com (esa5.hgst.iphmx.com [216.71.153.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 9F12D8120B for ; Mon, 24 Feb 2020 23:20:32 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=wdc.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=prvs=31631e744=atish.patra@wdc.com DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1582582833; x=1614118833; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=reifdDj0l7gZECzsvENwJRYYLj8Ah7bjPz4gLNm96y0=; b=Cf3IFkFQ8TH+jGvIiSXuksYhdwCe3o3yWZz/6NgMl7MmmWiAPbdXhXWs LN1eD+nnaxWGRCy5MXN+dyfmKQYXOqU7ze9AERJ1bWMAkTts1oymXlxwS iUYRdb4KDXazxHPwjibN/gqAILAkDZQj9TI9blF5RSMsTxye0KYA3u0To yEStbm/n5LM5IAuYdPfB9+9GX0VERb233w0ab07/6Av0RcmnkWuwfDe0B yD6Lh08OhHt1o8F8KxDjP9dwwPBDCCmXMobanWsa7a5gXhr++VeeBQfN6 PK7+nd9FFkAiDfIfnb1naqwf1v1T3BepCfFwZ4fae1sR0f8ArI1h2EBGf w==; IronPort-SDR: XVS/Jxbc0U62rdUqGi7tw1zaeU7Z1XdeEwqvRJ2XA7/QLWh7KbKghW2nMOZSnHV8zcKd3+5mD0 oaMixnHeGYkTIpJkvyKAX2KauqJJri/xMRpncS9o1QfSTdAqnmnxuNwqWJU3urdEaIkHZ1PE0N ryabgrRfCh9hUUs+x1nbXkTaGCcruor+Y6v+DfniOn1s/z+B/2ZtX90OUlSyv5Uwr8i05Jf748 0UVHoaOaVBdgXGQOINjMEenR/eZ6I7t9gAd6uqg3wbMY8TfGzxzHqD78kMz12csBkxGN3NBvPL m/o= X-IronPort-AV: E=Sophos;i="5.70,481,1574092800"; d="scan'208";a="131143521" Received: from uls-op-cesaip01.wdc.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 25 Feb 2020 06:20:30 +0800 IronPort-SDR: tFHbnE8HAivVHsIeSIFwdSKbY8ISGHjPP+iubzBVHKQzK6J9KU7I7CEHEVUVyf3bGIryUy6v0y 3eGR8Qb85SO6fkMLlL7dt+ShtktJhdAzVUlo/6VaA+svUNIAZjGYz1jU3htiEruZGvPBRoFVUO CoLz/nKBl7yorCQA1wzNOe02qi8xQ/ig7bUHuW0Z0AjA0tZAzpJJMvmbVZG/e2wZc0IZ12Ru5Q fK+1yZqoWK5eoD7SAsSfU06U9t+Ijg3KqiL0qx1xGR/aWX0THtw+qH4L6EnBjM3Sr/0KDssi4a LX6TuGZQwHzwc49KaRH/c9yr Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Feb 2020 14:12:57 -0800 IronPort-SDR: OVLM8+QyIjwyK2LKk2yu514nueZRL4VYVMfEJTjYeuZRnV23ZcNcDRbPU3xpSl6HL8yRcV4GBX oHrJguRRqGLLPqqY3F3qoc5AlVNb7IBxxfXb98i7iR2y9xNGrHVj3D2dLQ6D0K8Kx+/0xNvK32 F8uGbZsv9klqd0eNahsj5g5ve1tsOwaed0f2ltMdO4+aNjjs+wgMLTw2PIZyE3M0o7wzO7sa+G 6ZFHjxoctjdGcZNjbFonlCoJhu2wD/TVmk3MqOKWQBUx6/2RWy1/SExHLq74T7nQhjfjdHq+tO Y6g= WDCIronportException: Internal Received: from jedi-01.sdcorp.global.sandisk.com (HELO jedi-01.int.fusionio.com) ([10.11.143.218]) by uls-op-cesaip02.wdc.com with ESMTP; 24 Feb 2020 14:20:28 -0800 From: Atish Patra To: u-boot@lists.denx.de Cc: Atish Patra , Alexander Graf , Anup Patel , Bin Meng , Joe Hershberger , Loic Pallardy , Lukas Auer , =?utf-8?q?Marek_Beh?= =?utf-8?b?w7pu?= , Marek Vasut , Patrick Delaunay , Peng Fan , Philippe Reynes , Simon Glass , Simon Goldschmidt , Stefano Babic , Thierry Reding , trini@konsulko.com, Heinrich Schuchardt , Ard Biesheuvel , "leif@nuviainc.com" , abner.chang@hpe.com, daniel.schaefer@hpe.com Subject: [RFC PATCH 0/1] Add boot hartid to a Device tree Date: Mon, 24 Feb 2020 14:19:48 -0800 Message-Id: <20200224221949.28826-1-atish.patra@wdc.com> X-Mailer: git-send-email 2.24.0 MIME-Version: 1.0 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.30rc1 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.102.2 at phobos.denx.de X-Virus-Status: Clean The RISC-V booting protocol requires the hart id to be present in "a0" register. This is not a problem for bootm/booti commands as they directly jump to Linux kernel. However, bootefi jumps to a EFI boot stub code in Linux kernel which acts a loader and jumps to real Linux after terminating the boot services. This boot stub code has to be aware of the boot hart id so that it can set it in "a0" before jumping to Linux kernel. Currently, UEFI protocol doesn't have any mechanism to pass the boot hart id to an EFI executable. We should keep it this way as this is a RISC-V specific requirement rather than a UEFI requirement. Out of the all possible options, device tree seemed to be the best choice to do this job. The detailed discussion can be found in the following thread. https://patchwork.ozlabs.org/patch/1233664/ This patch updates the device tree in arch_fixup_fdt() which is common for all booting commands. As a result, the DT modification doesn't require any efi related arch specific functions and all DT related modifications are contained at one place. However, the hart id node will be available for Linux even if the kernel is booted using bootm command. If that is not acceptable, we can always move the code to an efi specific function. Atish Patra (1): riscv: Add boot hartid to Device tree arch/riscv/lib/bootm.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) --- 2.24.0