[PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
Tom Rini
trini at konsulko.com
Wed Dec 4 00:18:29 CET 2019
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@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: <https://lists.denx.de/pipermail/u-boot/attachments/20191203/efcce78d/attachment.sig>
More information about the U-Boot
mailing list