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=-2.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 DD6F2C433EF for ; Thu, 9 Sep 2021 11:17:09 +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 0DBF461100 for ; Thu, 9 Sep 2021 11:17:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0DBF461100 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmx.de 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 4289382C7F; Thu, 9 Sep 2021 13:17:05 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=gmx.net header.i=@gmx.net header.b="b70UCr5I"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7B82B82E48; Thu, 9 Sep 2021 13:17:02 +0200 (CEST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 76A6482C2C for ; Thu, 9 Sep 2021 13:16:58 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xypron.glpk@gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1631186217; bh=71dkOGJzX+6D2Vu6ii8893jaGS7LQMLT1x7Fl7dxMi8=; h=X-UI-Sender-Class:To:Cc:From:Subject:Date; b=b70UCr5IJvNHLeH8KJeJQ5vmtGO///U1NBEbzsxbQDyyz85BffNuJYAfpqAfczsEC fxUPABRd/I2Scoqoa5gNokysJncw3xu+WVhtPmogIGvq7ovzn4kSxfCtYSitel7Uoo VmN1cVgZyqmqLlNMQVqhZdC1QSc4ws0Rn5fJy7CY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.123.55] ([88.152.144.157]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MrQEx-1mlVRm0WLX-00oX88; Thu, 09 Sep 2021 13:16:57 +0200 To: Simon Glass Cc: Bin Meng , Ilias Apalodimas , U-Boot Mailing List From: Heinrich Schuchardt Subject: Driver model at UEFI runtime Message-ID: <2461183e-ae0a-d8b3-3822-6a06ee90950d@gmx.de> Date: Thu, 9 Sep 2021 13:16:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:UjQVIMVMIfsSObhYu2KXnUecB/+7RBAclZsI5CAAeESHzv1sBJI FqSnZQn5+BFyJ8OESEtK49HXyFK60v7QJwghoKKasQIj5AW70GprnnZPVwP+vi6EAUZWJof uHylwgjy4S863GlAZi0d6XLHJ8gwnsqaPbaYOJ0Jv7UUAMBtY316zV6JdaxX1QuHsNQU/NY TC272+bgu5dBoGJaPwWHw== X-UI-Out-Filterresults: notjunk:1;V03:K0:ecxkCDRQfI8=:8YH9GYSNtSB0nrHuTen5Bq UXyrghoGwmE78Q1s8hFz+1DuiiZZroJHezN5+94/rrYjG9fia7KU3Mut5WJrcDDNTUom0qkna NrISv0py7gjZ0D7sjbyjQEZy4f8ZRd8++o2nAe2+/ZoA9i9wcdHiW8SJ251XfonnpYUcdfHPf r0AAbtxam53msEvxH9zsmHmA3I9YW+eE+V/mQ0f4dfzDOheTd8PTV759XIWBCBPockYt0wdMJ Z3rWraTfuwaU9vr3c2XYUnTykxwXIYdan6TokRd7r0ZT2KR6z2jRcIjP1FpQrzBJD0SjdZ68e 2z4LFC/+bqi4E9nVgKzaRDGTPyR+iSftymJWi8S3WEyhXNUNPN0fgJQFMxnEB4FH8BMS2gRCG tcNhD9l2qfSYazLP0WeCutFbB7E+MnnnfEZ5fPzo7pcwoNo8fxcxoaDjFDvm5scdamuR+H0WO S4WhoXqBJK5AY9J7WCmJWU/mwAlScEWXNLzuYAEc3Jjfz6r0zUWGutK24Z/79L3IShKfPEOuQ 6QhMc95HxYDhuwZtp66ghCnX3+b/Yw8lY0+MypMUA4LIZKx3nLx0olu5tSRnYkr9Niwky85+I n/hG7QKAXhjiyC3a59fHVRKyX5MaT5m9Hl+KxDAkH936uQfMIjget3W8Rlf3DyZ4oCP/f5Lcv tfkw6OKa9GvzwGclJNAz5JRiRpT5yBSwxrOKoRTf82rtLHRoaoHUugh+6XeV4IfpJYh4U/85k T7kmv9I9poDErrFtutIPAVORx6pJ/TxrIameAA4JC1WC2pQyjerzAacTuZyGcAi49Uhk9bzjj j1YsVVSQNd4ONuoKTKT7jxKw2zYGvUdAsTYS6UTDalHem60BwBJibfbgs4AUamitrFWkJnjLt og9AiCzz1aF3h2CC18XdtREJ4lIDAEXSdN6X8bN5qBd38xcXFIP1RZ2megiVBS0/MlJPTXV8F cV725P5ZDKAdO7yNl7DA5BTtv8LagQnNtH4owIlZZSnDeyvyigIn+A2pNlzlxkEXvUeSs/y0m WOdUTouh5oC39XwuPKE5HUJU/XwOezms4P320g3v7+PHSjwkDDunfNFTyHRfIaUG43wIoB/U8 U5pE1uK1kakgMI= 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 Hello Simon, The EBBR specification requires that the UEFI SystemReset() runtime service is available to the operating system. Up to now this has been implemented by overriding function efi_reset_system() which is marked as __efi_runtime. Both ARM and RISC-V support generic interfaces for reset. PSCI for ARM and the System Reset Extension for SBI on RISC-V. This has kept the number of implementations low. The only exceptions are: * arch/arm/cpu/armv8/fsl-layerscape/cpu.c * arch/arm/mach-bcm283x/reset.c for the Raspberry PIs * arch/sandbox/cpu/start.c Bin has suggested in https://lists.denx.de/pipermail/u-boot/2021-September/459865.html to use reset drivers based on the driver model. Currently after ExitBootServices() the driver model does not exist anymore= . When evaluating Bin's suggestion one has to keep in mind that after invoking ExitBootServices() most operating systems call SetVirtualAddressMap(). Due to the change of the address map all pointers used by U-Boot afterwards must be updated to match the new memory map. The impression that Ilias and I have is that keeping the driver model alive after SetVirtualAddressMap() would incur: * a high development effort * a significant code size increase * an enlarged attack surface For RISC-V it has been clarified in the platform specification that the SBI must implement the system reset extension. For ARMv8 using TF-A and PSCI is what ARM suggests. So for these architectures we do not expect a growth in the number of drivers needed. Ilias and my favorite would be keeping the design as is. What is your view on this? Best regards Heinrich