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, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY 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 6B190C432BE for ; Wed, 25 Aug 2021 21:34:54 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8C90F610C7 for ; Wed, 25 Aug 2021 21:34:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8C90F610C7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xs4all.nl Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 03A8081EBD; Wed, 25 Aug 2021 23:34:51 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id C6BA080ECC; Wed, 25 Aug 2021 23:34:48 +0200 (CEST) Received: from sibelius.xs4all.nl (sibelius.xs4all.nl [83.163.83.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id E733C80ECC for ; Wed, 25 Aug 2021 23:34:45 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=mark.kettenis@xs4all.nl Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id de52f687; Wed, 25 Aug 2021 23:34:45 +0200 (CEST) Date: Wed, 25 Aug 2021 23:34:45 +0200 (CEST) From: Mark Kettenis To: Peter Robinson Cc: sjg@chromium.org, ilias.apalodimas@linaro.org, trini@konsulko.com, u-boot@lists.denx.de, jaeckel-floss@eyet-services.de, michal.simek@xilinx.com, dennis@ausil.us, daniel.schwierzeck@gmail.com, lukas.auer@aisec.fraunhofer.de, jh80.chung@samsung.com, mbrugger@suse.com, peng.fan@nxp.com, swarren@nvidia.com, swarren@wwwdotorg.org In-Reply-To: (message from Peter Robinson on Wed, 25 Aug 2021 14:29:45 +0100) Subject: Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow References: <20210819034601.1618773-1-sjg@chromium.org> <20210819135944.GX858@bill-the-cat> <20210819172750.GB858@bill-the-cat> <20210823200854.GH858@bill-the-cat> Message-ID: <561419e9d8b31466@bloch.sibelius.xs4all.nl> X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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.103.2 at phobos.denx.de X-Virus-Status: Clean > From: Peter Robinson > Date: Wed, 25 Aug 2021 14:29:45 +0100 > > > > Exactly. Keep in mind that RISC-V is looking into EBBR as well, > > > so this is far from an 'Arm thing'. Moreover, the efi stub side > > > of the kernel for risc-v, will only load an initrd using the > > > EFI_LOAD_FILE2 protocol we added support for. So right now the > > > only way to properly boot a RISC-V with EFI is through the > > > manager. > > > > I had heard that RISC-V was just going to use UEFI (and not U-Boot), > > but perhaps that is not correct. So far I have not really done > > anything with RISC-V so am not familiar with it. > > My understanding is the intention is to just use UEFI of which U-Boot > has a UEFI implementation. The HiFive Unmatched ships with U-Boot. I'm booting OpenBSD via UEFI on that board by using the uSD card that came with the board. The folks pushing the spec for RISC-V server hardware are probably considering a more traditional UEFI implementation for those systems since they also seem to be pushing for ACPI. But they explicitly mention EBBR for "embedded" systems, and EBBR was deliberately designed to allow the implementation of compliant systems using U-Boot's UEFI implementation.