Hi Kever, Am Montag, 1. April 2019, 11:49:35 CEST schrieb Kever Yang: > On 04/01/2019 01:42 PM, Heiko Stübner wrote: > > Am Montag, 1. April 2019, 04:32:28 CEST schrieb Kever Yang: > >> On 04/01/2019 05:02 AM, Heiko Stübner wrote: > >>> Am Freitag, 29. März 2019, 13:16:26 CET schrieb Kever Yang: > >>>> On 03/29/2019 07:25 PM, Philipp Tomsich wrote: > >>>>>> On 29.03.2019, at 12:21, Kever Yang <[email protected]> wrote: > >>>>>> > >>>>>> Rockchip provide tee binary release in 'rkbin' repository: > >>>>>> https://github.com/rockchip-linux/rkbin > >>>>>> For some historical reason, rockchip optee binary is using > >>>>>> 'r1' instead of 'lr' as U-Boot entry. > >>>>>> > >>>>>> Signed-off-by: Kever Yang <[email protected]> > >>>>>> --- > >>>>>> > >>>>>> common/spl/spl_optee.S | 3 +++ > >>>>>> 1 file changed, 3 insertions(+) > >>>>>> > >>>>>> diff --git a/common/spl/spl_optee.S b/common/spl/spl_optee.S > >>>>>> index 8bd1949ddf..092307b3cc 100644 > >>>>>> --- a/common/spl/spl_optee.S > >>>>>> +++ b/common/spl/spl_optee.S > >>>>>> @@ -8,5 +8,8 @@ > >>>>>> > >>>>>> ENTRY(spl_optee_entry) > >>>>>> ldr lr, =CONFIG_SYS_TEXT_BASE > >>>>>> +#ifdef CONFIG_ARCH_ROCKCHIP > >>>>> Can we make this selectable based on a dedicated config-option? We > >>>>> provide our > >>>>> own OPTEE port for some of our modules and I would like to have this as > >>>>> an opt-in > >>>>> or opt-out option in Kconfig. > >>>> I think you are using OPTEE for RK3368/RK3399, right? Then the use case > >>>> is different, you are using OPTEE as bl32 for armv8, and this spl_optee > >>>> is > >>>> for armv7 only. > >>>> I'm OK to add a Kconfig option if you really have different usage, > >>>> and I think this patch does not break things because the no one use 'r1' > >>>> now. > >>> rk3229 has support in upstream op-tee, so possibly the calling convention > >>> is different with that? And of course there may come a time when people > >>> may want to use upstream-op-tee instead of a binary-blob. > >> Upstream op-tee is using 'lr' and rockchip binary is now using 'r1' for > >> u-boot entry. > >> So upstream op-tee can be boot if my patch series for rk3229 is merged, > >> and with this patch, people can chose to use rockchip binary for rk3229 > >> or other > >> armv7 SoCs. > > Yes, an that is the reason there should be a Kconfig symbol for that :-) > > I don't think we need the Kconfig symbol now because I think user don't have > to make this choice in SPL, user only need to use the firmware they need. > With this patch, both upstream and Rockchip OP-TEE can be supported, > it does not break support for upstream op-tee. > The Kconfig symbol is needed if only one choice is available, isn't it?
In a related spl-atf change from last week, I saw today, I also saw the comment to not mix architecture hacks with common code, so I guess having a "ifdef ROCKCHIP" in common applies here. From what I understood right now, all Rockchip vendor OP-Tees use r1, so at least on rk3229 there is already a choice to use either upstream op-tee build from source or the binary rockchip one. > >> eg. I'll add op-tee support for rk3288 later because of the psci needed > >> by mainline kernel. > > please keep in mind that old device-trees in mainline need to stay working > > aka you cannot expect people to update their firmware just to keep using > > mainline kernels. So u-boot should modify the kernel-devicetree accordingly > > to enable psci, before starting the kernel. > > Well, I think the U-Boot should support op-tee first, and then kernel can > decide to use PSCI or not, user can still use old style if they don't > want a psci. > But if U-Boot don't support op-tee, then kernel is not able to use PSCI. of course ... this was not meant to be criticism of any sort ;-) Just a reminder, before somebody starts posting kernel patches converting the in-kernel devicetree to only psci. Heiko _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
