From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 3 Dec 2019 18:18:29 -0500 Subject: [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot In-Reply-To: References: Message-ID: <20191203231829.GB15966@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Dec 03, 2019 at 09:09:48PM +0100, Simon Goldschmidt wrote: > Am 03.12.2019 um 15:59 schrieb Dalon L Westergreen: > > > > > > On Tue, 2019-12-03 at 14:45 +0000, Ang, Chee Hong wrote: > > > > On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong < > > > > chee.hong.ang at intel.com > > > > > > > > > wrote: > > > > > > Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong: > > > > > > > > On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong > > > > > > > > < > > > > > > > > chee.hong.ang at intel.com > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong > > > > > > > > > > < > > > > > > > > > > chee.hong.ang at intel.com > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > > > > > > > > > > > > < > > > > > > > > > > > > chee.hong.ang at intel.com > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > On Mon, Dec 2, 2019 at 11:25 AM < > > > > > > > > > > > > > > chee.hong.ang at intel.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > From: "Ang, Chee Hong" < > > > > > > > > > > > > > > > chee.hong.ang at intel.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > New U-boot flow with ARM Trusted Firmware (ATF) > > > > > > > > > > > > > > > support: > > > > > > > > > > > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> > > > > > > > > > > > > > > > Linux > > > > > > > > > > > > > > > (EL1) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Adding support for ATF means that using U-Boot on > > > > > > > > > > > > > > Stratix10 > > > > > > > > > > > > > > and Agilex without ATF keeps working, right? > > > > > > > > > > > > > > > > > > > > > > > > > > ATF is needed in order for Stratix10 and Agilex's U-Boot > > > > > > > > > > > > > to work. > > > > > > > > > > > > > > > > > > > > > > > > Is there a technical requirement for that? > > > > > > > > > > > > > > > > > > > > > > Yes. We are using ATF to provide PSCI services such as system > > > > > > > > > > > reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and > > > > > > > > > > > other secure services such as mailbox communications with > > > > > > > > > > > Secure Device Manager and accessing the System Manager > > > > > > > > > > > registers which are > > > > > > > > > > > > > > > > secure. > > > > > > > > > > > Without PSCI services, we are able to boot until U-Boot proper > > > > > > > > > > > only. > > > > > > > > > > > Currently, our U-Boot in mainline doesn't boot to Linux due to > > > > > > > > > > > these missing > > > > > > > > > > > > > > > > > > > > PSCI services. > > > > > > > > > > > Another reason is we have another boot flow which is using ATF > > > > > > > > > > > + > > > > > > > > UEFI. > > > > > > > > > > > So now we are re-using the PSCI services from ATF so that now > > > > > > > > > > > U-Boot and UEFI share the same ATF-BL31 image so that we don't > > > > > > > > > > > have to > > > > > > > > > > > > > > > > > > > > reimplement another sets of PSCI services for U-Boot again. > > > > > > > > > > > This will greatly reduce our engineering efforts. > > > > > > > > > > > > > > > > > > > > Hmm, thanks for the explanation. > > > > > > > > > > > > > > > > > > > > I don't really think I can review this, given the lack of > > > > > > > > > > knowledge about that PSCI stuff. > > > > > > > > > > > > > > > > > > I believe you can review it. > > > > > > > > > Have you briefly gone through the patches ? It has nothing to do > > > > > > > > > with the PSCI > > > > > > > > > > > > > > > > stuff. > > > > > > > > > It just call the invoke_smc() function to call the ATF's PSCI > > > > > > > > > functions. Those PSCI functions in ATF will do the rest. > > > > > > > > > > > > > > > > No, not yet. But see below. > > > > > > > > > > > > > > > > > > I must say it seems strange to me that U-Boot would have to > > > > > > > > > > rely on ATF > > > > > > > > > > > > > > > > though. > > > > > > > > > > How do other platforms implement this? Shouldn't PSCI be > > > > > > > > > > generic or is it really platform specific? If it's generic, > > > > > > > > > > isn't that a dupliation of code if you implement e.g. a reset > > > > > > > > > > driver for > > > > > > > > > > Stratix10 but call > > > > > > > > > > > > > > > > into PSCI? > > > > > > > > > It's not strange at all. A lot of U-Boot users already using > > > > > > > > > this boot flow (ATF + > > > > > > > > > > > > > > > > U-Boot). > > > > > > > > > > > > > > > > Just because other boards do this doesn't mean it's not strange. > > > > > > > > Wasn't there some kind of discussion around that PSCI stuff to > > > > > > > > make it > > > > > > > > > > > > available from U-Boot? > > > > > > > > What's wrong with that way? > > > > > > > > > > > > > > Our downstream U-Boot branch is already implemented the PSCI > > > > > > > stuffs in U- > > > > > > > > > > > > Boot. > > > > > > > I tried to upstream my PSCI code: > > > > > > > https://lists.denx.de/pipermail/u-boot/2019-May/368822.html > > > > > > > > > > > > > > > > > > > > > Marek pointed me to this thread: > > > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg319458.html > > > > > > > > > > > > > > > > > > > > > He had a point. He suggested maybe we can implement the PSCI > > > > > > > stuffs in SPL/TPL. I took a look at the U-Boot code and found out > > > > > > > ATF is already well > > > > > > > > > > > > supported. Why don't we just use the PSCI code from ATF rather than > > > > > > re- implementing the PSCI code again in SPL/TPL. > > > > > > > It will save our effort to maintain two PSCI code in U-Boot and > > > > > > > ATF while we > > > > > > > > > > > > already have the ATF PSCI implementation to support UEFI. > > > > > > > > > > > > It seems to me we do have working code in U-Boot, what's missing is > > > > > > "only" to turn it ino PSCI? > > > > > > > > > > Existing PSCI framework in U-Boot provide a way for us to turn the > > > > > code into a PSCI handler by just adding a '__secure' keyword before the > > > > > > > > function name. See: > > > > > https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-socfpga > > > > > > > > > > /mailbox_s10.c > > > > > > > > > > Below is one of the functions that has 2 versions. One 'live' in a > > > > > normal code section and another one will be relocated to "__secure" > > > > > section (for PSCI). You can see that 2 same functions are duplicated for > > > > > normal > > > > > > > > code section and PSCI section. > > > > > int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg, > > > > > u8 urgent, u32 *resp_buf_len, u32 *resp_buf) { > > > > > return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, > > > > > urgent, > > > > > resp_buf_len, resp_buf); } > > > > > > > > > > int __secure mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len, > > > > > u32 *arg, u8 urgent, u32 *resp_buf_len, > > > > > u32 *resp_buf) { > > > > > return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, > > > > > urgent, > > > > > resp_buf_len, resp_buf); } > > > > > > > > > > Those functions that are needed by PSCI runtime need to be duplicated for > > > > > > > > "__secure" section. > > > > > U-Boot Proper will copy and relocate the PSCI code in "__secure" > > > > > section to a location before booting Linux whereby they can be called > > > > > by Linux. Using the PSCI framework, U-Boot proper is not able to call any > > > > > PSCI > > > > > > > > functions because PSCI code is not available until U-Boot proper ready to > > > > boot > > > > Linux. > > > > > So that's the reason we need to have 2 sets of code in U-Boot. One for > > > > > SPL/U-Boot and another one for PSCI section which is used by Linux. > > > > > Currently we have 2 implementations for FPGA reconfiguration driver in our > > > > > > > > downstream branch. > > > > > One for SPL/U-Boot and another one for Linux (PSCI). FPGA > > > > > reconfiguration driver for U-Boot is already upstreamed but I don't think > > > > > I can > > > > > > > > get the FPGA reconfiguration for the PSCI part upstreamed. > > > > > They are 2 sets of different code for the same purpose. But that is > > > > > what we have done in downstream to make sure we can support Linux. > > > > > > > > > > BTW, we are going to get rid of those duplicated code for PSCI after we > > > > > switch > > > > > > > > to ATF boot flow. > > > > > > > > I think we have already discussed why that style is bad and unstable. > > > > > > > > The correct thing to do would be to compile an SPL style binary from the U- > > > > Boot > > > > sources that can replace ATF-BL31, not this messy __secure thing. > > > > > > > > I can see others (rockchip, TI, NXP?) might in part rely on ATF as well, but > > > > speaking for socfpga, if you must insist on using ATF, I would be happy if > > > > you > > > > could do it in a way that does not reduce existing functionality in U-Boot. > > > > > > Please do 'git grep CONFIG_SPL_ATF' and you will have some idea who are using > > > the ATF > > > with U-Boot. You can know which platforms are using the ATF by looking at the > > > name > > > of the defconfig files. > > > > > > BTW, what makes you think this ATF method reduce the existing functionality in > > > U-Boot ? > > > I don't really get that. I would like to know more to see what I can do to > > > ease your concern. > > > > > > And given U-Boot aims to support UEFI (kind of?), I'd rather argue: > > > > > > why do you need ATF at all? > > > > > > > > > > No, U-Boot does not aim to support UEFI. We have 2 boot flows that don't > > > > > > > > mix: > > > > > > > > Really? Or do you mean you don't aim to support EFI boot using U-Boot? > > > > I don't know that (U)EFI stuff too well, yet, but I was under the impression > > > > that > > > > Heinrich et. al. do want U-Boot to support UEFI? > > > > > > Yes. Currently, we have no plan to support (U)EFI boot with U-Boot. > > > Anyway, I am not working on UEFI boot flow. That's the work from another team. > > > > I need to point out a miscommunication on going in this thread. Ang is > > referring to the UEFI bootloader that currently supports socfpga devices, > > Simon is referring to EFI support in uboot which we should move to support > > and test in uboot as it is commonly used for arm64 boot, by fedora for example. > > > > https://github.com/altera-opensource/uefi-socfpga > > I'm not sure I get the difference. What's this uefi-socfpga, what does it > and where in the below 1) and 2) would it be located? It's the altera tree of EDK II / Tianocore. That is to say, a full UEFI implementation as the firmware. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: