[PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
Simon Goldschmidt
simon.k.r.goldschmidt at gmail.com
Tue Dec 3 21:09:48 CET 2019
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?
Distributions like Fedora would use things like Grub, right? I thought
that should work with U-Boot, too (once it's done)?
Regards,
Simon
>
> --dalon
>
>>>> 1) U-Boot -> ATF-BL31 -> U-Boot Proper -> Linux
>>>>
>>>> 2) ATF-BL2 -> ATF-BL31 -> UEFI -> Other OSes or Linux
>>>>
>>>> These two boot flows now share the same code base (ATF-BL31).
>>>>> Indeed, having the same code in both seems like double effort for
>>>
>>> maintenance.
>>>>>>> In my opinion, you're reducing functionality in U-Boot by making
>>>>>>> ATF a requirement.
>>>>>>>
>>>>>>> And by saying "I can't review this", I mean this looks like a
>>>>>>> questionable way to me and I'm not the one to say if a U-Boot
>>>>>>> board should
>>>>>
>>>>> go this way or not.
>>>>>> I understand. Btw, who should I include to review this ?
>>>>>>>> Yes. PSCI is a generic software interface which encapsulate the
>>>>>>>> platform
>>>>>>>
>>>>>>> specific code.
>>>>>>>> Let me give you a good example in one of your sysreset driver
>>>>>>>> you have
>>>>>>>
>>>>>>> implemented for S10.
>>>>>>>> #include <dm.h>
>>>>>>>> #include <errno.h>
>>>>>>>> #include <sysreset.h>
>>>>>>>> -#include <asm/arch/mailbox_s10.h>
>>>>>>>>
>>>>>>>> static int socfpga_sysreset_request(struct udevice *dev,
>>>>>>>> enum sysreset_t type) {
>>>>>>>> - puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
>>>>>>>> - mbox_reset_cold();
>>>>>>>> + psci_system_reset();
>>>>>
>>>>> And coming back on this, the sysreset driver won't work in SPL any more,
>>>
>>> right?
>>>> You brought a very good point. See my comment at the bottom.
>>>>>>> So this is not an socfgpa_s10 specific driver any more, right?
>>>>
>>>> This driver code can be renamed to more generic name such as
>>>
>>> socfpga_soc64.c.
>>>> So that it can be shared by both Stratix10 and Agilex.
>>>>>>>> return -EINPROGRESS;
>>>>>>>> }
>>>>>>>>
>>>>>>>> Above is the changes in one of my patchsets, the sysreset driver
>>>>>>>> for
>>>>>>>> S10 used to call mbox_reset_cold() to send mailbox message to
>>>>>>>> Secure Device Manager
>>>>>>>> (SDM) to trigger COLD reset.
>>>>>>>> Calling 'mbox_reset_cold()' means you are calling platform
>>>>>>>> specific code in the sysreset driver to perform COLD reset. What
>>>>>>>> if method to trigger
>>>>>>>
>>>>>>> COLD reset is changed in new platform ?
>>>>>>>> We have to change the sysreset driver code to support another
>>>>>>>> new
>>>>>
>>>>> platform.
>>>>>>>> If this function call is replaced with "psci_system_reset()", we
>>>>>>>> don't have to change the code at all because all the platform
>>>>>>>> specific code for COLD reset is now reside in ATF because this
>>>>>>>> function just invoke the PSCI function provided by ATF. You just
>>>>>>>> have to replace the ATF binary with the new implementation for
>>>>>>>> the new platform. We can re-use this sysreset driver for any
>>>>>>>> platform that support ATF. In fact, it makes our U-Boot driver
>>>>>>>> code more 'generic' because PSCI interface stay the same. BTW,
>>>>>>>> Linux also call PSCI functions to perform COLD reset. By
>>>>>>>
>>>>>>> using ATF, U-Boot and Linux share the same COLD reset service
>>>>>>> provided by
>>>>>
>>>>> ATF.
>>>>>>> It actually reduce code duplication.
>>>>>>>
>>>>>>> What I meant was code duplication inside the U-Boot tree (having
>>>>>>> one driver for each arch but in effect all those drivers will
>>>>>>> call into the same psci
>>>>>
>>>>> function).
>>>>>> Can different archs share the same driver if the driver code is
>>>>>> common to
>>>>>
>>>>> those platforms ?
>>>>>
>>>>> I don't know why not. However, you then need a different way to
>>>>> select this
>>>>> driver: you clearly cannot use DT compatibles as this DT entry does
>>>>> not in any way stand for what you make the driver binding to it execute.
>>>>>
>>>>> Instead, I would think of a way to make your PSCI-aware U-Boot
>>>>> proper use a generic PSCI-reset driver instead of the one matching
>>>>> the devicetree. And then keep in mind you still need the DT-matching
>>>>> driver in SPL. Thinking about it, having a driver in SPL you don't
>>>>> use in U-Boot proper is probably not done, yet, as well.
>>>>
>>>> I don't have any problem with this approach (PSCI-reset driver) but it
>>>> is very easy to support SPL and U-Boot proper in the same driver by just
>>>
>>> checking the current exception level. Please take a look at the code below.
>>>> #include <dm.h>
>>>> #include <errno.h>
>>>> #include <sysreset.h>
>>>> #include <asm/arch/mailbox_s10.h>
>>>>
>>>> static int socfpga_sysreset_request(struct udevice *dev,
>>>> enum sysreset_t type) {
>>>> - puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
>>>> + If (current_el() == 3)
>>>
>>> Hard-coding the EL here seems quite a hack?
>>>
>>>> + mbox_reset_cold();
>>>> + else
>>>> + psci_system_reset();
>>>> return -EINPROGRESS;
>>>> }
>>>>
>>>> We can make the sysreset driver compatible in SPL and U-Boot proper by
>>>> just
>>>
>>> checking the current exception level.
>>>> If it's EL3 (secure), we knew SPL is running and otherwise U-Boot proper
>>>> (EL2,
>>>
>>> non-secure) is running.
>>>
>>> So you compile all the PSCI stuff into SPL although never using it?
>>
>> The PSCI stuff is just a very thin layer (interface to PSCI/SMC call) since
>> real work is done in ATF.
>> Or we can do it in compile time:
>> #ifdef CONFIG_SPL_BUILD
>> // do it in normal way
>> #else
>> // invoke PSCI call
>> #endif
>>> I'd still prefer to have DT-compat matched drivers implementing the hardware
>>> access.
>>> Then you can instantiate different drivers in U-Boot proper if you want to
>>> use
>>> PSCI, not the hardware. Having DT-compat matched drivers do something
>>> completely different (issuing PSCI calls instead of accessing the hardware
>>> they
>>> matched on) seems wrong.
>>
>> OK.
>>> Regards,
>>> Simon
>>>
>>>> Or we can make a small generic function like below and call it from
>>>> sysreset
>>>
>>> driver code:
>>>> void soc64_cold_reset(void)
>>>> {
>>>> If (current_el() == 3)
>>>> mbox_reset_cold();
>>>> else
>>>> psci_system_reset();
>>>> }
>>>>
>>>>>>> What you're doing is to move this code from U-Boot open U-Boot
>>>>>>> sources to possibly closed source ATF sources. But we've already
>>>>>>> had that discussion, I think...
>>>>>>
>>>>>> Our PSCI implementation in ATF is open source:
>>>>>> https://github.com/ARM-software/arm-trusted-firmware/tree/master/p
>>>>>>
>>>>>> lat/
>>>>>> intel/soc
>>>>>
>>>>> Well, open source... Without implying anything: it's BSD, so it's
>>>>> open source as long as Intel wants it to be open source and nothing
>>>>> prevents the next manager from keeping additions or even bugfixes closed
>>>
>>> source.
>>>>> For whatever reasons might come.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Simon
>>>>>
>>>>>>> Regards,
>>>>>>> Simon
>>>>>>>
>>>>>>>> I think you are aware of we are working to move the mailbox
>>>>>>>> driver code away
>>>>>>>
>>>>>>> from arch to drivers.
>>>>>>>> You will see that a lot of those mailbox functions will be
>>>>>>>> removed from the
>>>>>>>
>>>>>>> mailbox driver.
>>>>>>>> One of them is 'mbox_reset_cold()' which you called in sysreset
>>>>>>>> driver for
>>>>>
>>>>> S10.
>>>>>>>>> Regards,
>>>>>>>>> Simon
>>>>>>>>>
>>>>>>>>>>> Regard,
>>>>>>>>>>> Simon
>>>>>>>>>>>
>>>>>>>>>>>>>> SPL loads the u-boot.itb which consist of:
>>>>>>>>>>>>>> 1) u-boot-nodtb.bin (U-Boot Proper image)
>>>>>>>>>>>>>> 2) u-boot.dtb (U-Boot Proper DTB)
>>>>>>>>>>>>>> 3) bl31.bin (ATF-BL31 image)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Supported Platform: Intel SoCFPGA 64bits (Stratix10 &
>>>>>>>>>>>>>> Agilex)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now, U-Boot Proper is running in non-secure mode
>>>>>>>>>>>>>> (EL2), it
>>>>>>>>>>>>>> invokes SMC/PSCI calls provided by ATF to perform COLD
>>>>>>>>>>>>>> reset, System Manager register accesses and mailbox
>>>>>>>>>>>>>> communications with Secure Device Manager (SDM).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Steps to build the U-Boot with ATF support:
>>>>>>>>>>>>>> 1) Build U-Boot
>>>>>>>>>>>>>> 2) Build ATF BL31
>>>>>>>>>>>>>> 3) Copy ATF BL31 binary image into U-Boot's root
>>>>>>>>>>>>>> folder
>>>>>>>>>>>>>> 4) "make u-boot.itb" to generate u-boot.itb
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> These patchsets have dependency on:
>>>>>>>>>>>>>> [U-Boot,v8,00/19] Add Intel Agilex SoC support:
>>>>>>>>>>>>>> https://patchwork.ozlabs.org/cover/1201373/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Chee Hong Ang (19):
>>>>>>>>>>>>>> arm: socfpga: add fit source file for pack itb with
>>>>>>>>>>>>>> ATF
>>>>>>>>>>>>>> arm: socfpga: Add function for checking description
>>>>>>>>>>>>>> from FIT
>>>>>>>
>>>>>>> image
>>>>>>>>>>>>>> arm: socfpga: Load FIT image with ATF support
>>>>>>>>>>>>>> arm: socfpga: Override 'lowlevel_init' to support
>>>>>>>>>>>>>> ATF
>>>>>>>>>>>>>> configs: socfpga: Enable FIT image loading with ATF
>>>>>>>>>>>>>> support
>>>>>>>>>>>>>> arm: socfpga: Disable "spin-table" method for
>>>>>>>>>>>>>> booting Linux
>>>>>>>>>>>>>> arm: socfpga: Add SMC helper function for Intel
>>>>>>>>>>>>>> SOCFPGA
>>>
>>> (64bits)
>>>>>>>>>>>>>> arm: socfpga: Define SMC function identifiers for
>>>>>>>>>>>>>> PSCI SiP
>>>
>>> services
>>>>>>>>>>>>>> arm: socfpga: Add secure register access helper
>>>>>>>>>>>>>> functions for
>>>
>>> SoC
>>>>>>>>>>>>>> 64bits
>>>>>>>>>>>>>> arm: socfpga: Secure register access for clock
>>>>>>>>>>>>>> manager (SoC
>>>
>>> 64bits)
>>>>>>>>>>>>>> arm: socfpga: Secure register access in PHY mode
>>>>>>>>>>>>>> setup
>>>>>>>>>>>>>> arm: socfpga: Secure register access for reading
>>>>>>>>>>>>>> PLL frequency
>>>>>>>>>>>>>> mmc: dwmmc: socfpga: Secure register access in MMC
>>>>>>>>>>>>>> driver
>>>>>>>>>>>>>> net: designware: socfpga: Secure register access in
>>>>>>>>>>>>>> MAC driver
>>>>>>>>>>>>>> arm: socfpga: Secure register access in Reset
>>>>>>>>>>>>>> Manager driver
>>>>>>>>>>>>>> arm: socfpga: stratix10: Initialize timer in SPL
>>>>>>>>>>>>>> arm: socfpga: stratix10: Refactor FPGA reconfig
>>>>>>>>>>>>>> driver
>>>>>>>>>>>>>> to support
>>>>>>>
>>>>>>> ATF
>>>>>>>>>>>>>> arm: socfpga: Bridge reset now invokes SMC calls to
>>>>>>>>>>>>>> query FPGA
>>>>>>>>>
>>>>>>>>> config
>>>>>>>>>>>>>> status
>>>>>>>>>>>>>> sysreset: socfpga: Invoke PSCI call for COLD reset
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Dalon Westergreen (1):
>>>>>>>>>>>>>> configs: stratix10: Remove CONFIG_OF_EMBED
>>>>>>>>>>>>>
>>>>>>>>>>>>> This one is included in another series already:
>>>>>>>>>>>>> https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Does this mean that one will be abandonen?
>>>>>>>>>>>>> So the combined hex output part of that series is not
>>>>>>>>>>>>> required any
>>>>>>>
>>>>>>> more?
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Simon
>>>>>>>>>>>>>
>>>>>>>>>>>>>> arch/arm/mach-
>>>>>>>>>>>>>> socfpga/Kconfig | 2 -
>>>>>>>>>>>>>> arch/arm/mach-
>>>>>>>>>>>>>> socfpga/Makefile | 4 +
>>>>>>>>>>>>>> arch/arm/mach-
>>>>>>>>>>>>>> socfpga/board.c | 10 +
>>>>>>>>>>>>>> arch/arm/mach-
>>>>>>>>>>>>>> socfpga/clock_manager_agilex.c | 5 +-
>>>>>>>>>>>>>> arch/arm/mach-
>>>>>>>>>>>>>> socfpga/clock_manager_s10.c | 5 +-
>>>>>>>>>>>>>> arch/arm/mach-
>>>>>>>>>>>>>> socfpga/include/mach/misc.h | 3 +
>>>>>>>>>>>>>> .../mach-
>>>>>>>>>>>>>> socfpga/include/mach/secure_reg_helper.h | 20 ++
>>>>>>>>>>>>>> arch/arm/mach-
>>>>>>>>>>>>>> socfpga/lowlevel_init.S | 48 +++
>>>>>>>>>>>>>> arch/arm/mach-
>>>>>>>>>>>>>> socfpga/misc_s10.c | 47 ++-
>>>>>>>>>>>>>> arch/arm/mach-
>>>>>>>>>>>>>> socfpga/reset_manager_s10.c | 31 +-
>>>>>>>>>>>>>> arch/arm/mach-
>>>>>>>>>>>>>> socfpga/secure_reg_helper.c | 67 ++++
>>>>>>>>>>>>>> arch/arm/mach-
>>>>>>>>>>>>>> socfpga/timer_s10.c | 3 +-
>>>>>>>>>>>>>> arch/arm/mach-
>>>>>>>>>>>>>> socfpga/wrap_pll_config_s10.c | 9 +-
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> board/altera/soc64/its/fit_spl_atf.its |
>>>>>>>>>>>>>> 51 +++
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> configs/socfpga_agilex_defconfig |
>>>>>>>>>>>>>> 8 +-
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> configs/socfpga_stratix10_defconfig |
>>>>>>>>>>>>>> 9 +-
>>>>>>>>>>>>>> drivers/fpga/stratix10.c |
>>>>>>>>>>>>>> 261 ++++----------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> drivers/mmc/socfpga_dw_mmc.c |
>>>>>>>>>>>>>> 7 +-
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> drivers/net/dwmac_socfpga.c |
>>>>>>>>>>>>>> 5 +-
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> drivers/sysreset/sysreset_socfpga_s10.c |
>>>>>>>>>>>>>> 4 +-
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> include/configs/socfpga_soc64_common.h |
>>>>>>>>>>>>>> 2 +-
>>>>>>>>>>>>>> include/linux/intel-smc.h |
>>>>>>>>>>>>>> 374
>>>>>>>
>>>>>>> +++++++++++++++++++++
>>>>>>>>>>>>>> 22 files changed, 732 insertions(+), 243 deletions(-
>>>>>>>>>>>>>> )
>>>>>>>>>>>>>> create mode
>>>>>>>>>>>>>> 100644
>>>>>>>>>>>>>> arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
>>>>>>>>>>>>>> create mode 100644 arch/arm/mach-
>>>>>>>>>>>>>> socfpga/lowlevel_init.S
>>>>>>>>>>>>>> create mode 100644
>>>>>>>>>>>>>> arch/arm/mach-socfpga/secure_reg_helper.c
>>>>>>>>>>>>>> create mode 100644
>>>>>>>>>>>>>> board/altera/soc64/its/fit_spl_atf.its
>>>>>>>>>>>>>> create mode 100644 include/linux/intel-smc.h
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> 2.7.4
>>>>>>>>>>>>>>
>
More information about the U-Boot
mailing list