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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 77F63C4332F for ; Tue, 13 Dec 2022 00:31:49 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id F1C5885437; Tue, 13 Dec 2022 01:31:46 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="VEg+MwJ4"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 1F27F84FD4; Tue, 13 Dec 2022 01:31:45 +0100 (CET) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 4EF2582A0A for ; Tue, 13 Dec 2022 01:31:42 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=seanga2@gmail.com Received: by mail-qt1-x836.google.com with SMTP id g7so10593136qts.1 for ; Mon, 12 Dec 2022 16:31:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=lYb9rqbZRxNSGingOmeWDDSjlUZclsrhrkfL6nJLkDc=; b=VEg+MwJ49JEDeUwn6J9JxT/hJDW2ceuLQrEFDYJFThq60cvSSmCC5aIqR2QFWtarm0 G/bX+BHhbMj4FJrW3X4sNFrurzki78UdQ8ZyWjIvV9DmYBsaP7Yvh9AvBqqu6Q3I51DW ckSf2wQ6hR2gZNss0LOOCg/65ga/FPKayhMyRiHBtllfJOTTpts8PFxLOVurg9ZI0D78 Q5PHWd+FIf9t5de0mMZbO1c4tevNxANHrsXuPqpe30w+znyCnp9e+g2J96WVlXDaHMQS KdZWuv8GgwH/F0GJPTrJut0M20Rs7DaHWJdE7Rn1TaeDK1jRRoAy2apgRwHVSY/XncVZ GRYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lYb9rqbZRxNSGingOmeWDDSjlUZclsrhrkfL6nJLkDc=; b=WSuB+6sHEjhKhIatCz25gm8U3sq3Plh0ZE0n3xeX6R2sDSyDoYsJVjMfNikHt9Ilhs +D1qhlZ+YPnPOlKn04ZzezXhI96y7GOCm0deE/lncFJvHrw+jW8+28Yem1qN7HTdCKF5 mEOTMc3pvCYZhQXQbf7N9sKMg69cAroDd8PvNvrBowaEoSTsHFkMDhsgoQb19dN+YbdW lb0DM2iUIHYNmAux22KXryEK8BqIIfsuchdzZ/zh8oyI/Qf4XBKymGxCb2U+IzDvgfgk CJPFVp7qxqh0ej4CNo7A7pa57PmLRIL2HDQk+nV1T9P+duUHYDcFZkbeQMGVTe/jpJw3 zdRw== X-Gm-Message-State: ANoB5pn3e8Khf/svkXJR72uWw7Bgcu8LEG0b/WZs244GoFSXXgFJjI/R fDlwyTFJlCc2ecDMsslkqOA= X-Google-Smtp-Source: AA0mqf7XyWJxDdiBjrm7yYJT1/DsPbEj475+sPs7MdPT0Q0HSgFI8pnJmHdUCTeN+EMen3bs5AHp/Q== X-Received: by 2002:ac8:1e8c:0:b0:3a7:ad38:f3dc with SMTP id c12-20020ac81e8c000000b003a7ad38f3dcmr26321635qtm.15.1670891500945; Mon, 12 Dec 2022 16:31:40 -0800 (PST) Received: from [192.168.1.201] (pool-173-73-95-180.washdc.fios.verizon.net. [173.73.95.180]) by smtp.gmail.com with ESMTPSA id g21-20020ac87755000000b0039cc944ebdasm6601622qtu.54.2022.12.12.16.31.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Dec 2022 16:31:40 -0800 (PST) Message-ID: Date: Mon, 12 Dec 2022 19:31:39 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT Content-Language: en-US To: Tom Rini , Rick Chen Cc: Rick Chen , ycliang@andestech.com, u-boot@lists.denx.de, sjg@chromium.org, xypron.glpk@gmx.de References: <20221207062334.21292-1-rick@andestech.com> <1162c5df-dcfc-0908-1d07-32145e3a6aaa@gmail.com> <20221209220723.GS3787616@bill-the-cat> <20221212150315.GS3787616@bill-the-cat> From: Sean Anderson In-Reply-To: <20221212150315.GS3787616@bill-the-cat> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.6 at phobos.denx.de X-Virus-Status: Clean On 12/12/22 10:03, Tom Rini wrote: > On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote: >> Hi Tom >> >>> On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote: >>>> On 12/7/22 01:23, Rick Chen wrote: >>>>> In RISC-V, it only provide normal mode booting currently. >>>>> To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT >>>>> to achieve this feature which will be call Fast-Boot mode. By >>>> >>>> Can you name this something different. We already have something called >>>> fastboot in-tree (the Android-derived protocol) and there's a Microsoft >>>> technology called fastboot (some kind of hibernation). "OS Boot" isn't >>>> very specific either, since we (almost always) boot an OS. Maybe "Eagle >>>> mode" by analogy to Falcon mode, which lets SPL directly boot an OS. >>>> >>>> (Is this substantially different from falcon mode anyway?) >>> >>> I was kind of wondering if this is different, really, from Falcon Mode. >>> Falcon Mode didn't initially have to factor in other-firmware as that's >>> not a hard requirement on arm32 like it is on arm64 or risc-v. But my >>> first read of this was that it seems like the RISC-V specific side of >>> doing Falcon Mode and dealing with the prior stage needs correctly. >>> >> >> Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y). >> When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR and >> jump_to_image_linux() shall be defined but they are un-necessary for RISC-V. >> Because the flow of OpenSBI and SPL_OS_BOOT are totally different code >> flow in board_init_r() of common/spl/spl.c. >> That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this >> RISC-V fast boot implementation. > > Those sound like fairly minor challenges for the same fundamental > concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to > pass along". We might need to do a little code re-factoring here. But > maybe also a little bit of explaining why we wouldn't be booting to the > OS directly but instead passing back to openSBI to do this? That's not > normally how RISC-V boots the OS, right? Or am I miss-understanding > something here? > The usual process is ROM -> SPL -> SBI -> U-Boot -> Linux Where SPL loads SBI and U-Boot and tells SBI "please run U-Boot after you are done booting". But the idea here is to load Linux instead of U-Boot. I think this is pretty similar to Falcon mode. Actually, when CONFIG_SPL_OPENSBI is enabled, I think it's reasonable for falcon mode to do exactly that. People who want the SPL -> Linux path can disable SPL_OPENSBI. --Sean