From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kever Yang <kever.yang@rock-chips.com>
Date: Thu, 14 Jul 2016 20:14:28 +0800
Subject: [U-Boot] How to support ATF on u-boot
In-Reply-To: <4596ab1a-c9d9-75c9-ddbd-1c0d969a16aa@arm.com>
References: <57675BF7.707@rock-chips.com>
 <36bb7650-5ea3-3d12-6134-4ef32b517cc7@suse.de>
 <4596ab1a-c9d9-75c9-ddbd-1c0d969a16aa@arm.com>
Message-ID: <57878224.6050300@rock-chips.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Andre,

On 07/13/2016 08:45 PM, Andre Przywara wrote:
> Hi,
>
> On 13/07/16 13:27, Andreas F?rber wrote:
>> Hi Kever,
>>
>> Am 20.06.2016 um 04:59 schrieb Kever Yang:
>>>      I want to upstream a new SoC named RK3399 from Rockchip which is
>>> AARCH64/ARMv8, we need to support Arm Trust Firmware base on U-boot.
>>>
>>>      Right now we are using a miniloader(just like SPL in U-boot) to load
>>> ATF/U-boot,
>>> and PC jump from miniloader to ATF and then to U-boot(with CPU change to
>>> EL2 mode or nsEL1),
>>> then U-boot load kernel/rootfs as usual.
>>>
>>>      The ATF support for RK3399 has already upstream
>>>      Could you give your opinion on how to support ATF on U-boot upstream?
>>> When I asked Simon Glass offline, he suggest if we can build ATF as part
>>> of the
>>> U-boot build process, perhaps with a script in U-boot tree,
>>>
>>> Perhaps something like:
>>>
>>> make rk3399_board_defconfig
>>> make
>>> ./scripts/build-atf-image rk3399_board
>>> ^^ new script
> I am not sure we should trigger an ATF build on building U-Boot. In my
> build process for the Pine64 I just point to the compiled binary and
> leave it up to the user to take care of compiling that. ATF builds are
> really easy and fast, for the Pine64 it's just: "make PLAT=sun50iw1p1
> bl31" for instance and takes only a few seconds.
I have send my patch set today, get bl31 from ATF is easy, still need some
rockchip tools to do the package and load the image.
>
>>> In any case, a good README would help.
>> I've started looking into RK3368 for my GeekBox, which raises a similar
>> issue. Are you working on that as well or just RK3399?
>>
>> Personally I think that the approach the HiKey has taken is the best,
>> i.e. decouple U-Boot from ATF and just supply a README for how to make
>> it work with U-Boot as ATF payload.
> Interestingly ATF itself considers U-Boot a payload, as it provides its
> own bootstrapping parts which take a similar role as U-Boot's SPL.
> So the official ATF build process (at least for Juno) lets you specify
> the location of the U-Boot binary to be included in their FIP image.
>
> OTOH, some boards (like the Pine64) only use the runtime component of
> ATF, so including it in U-Boot makes more sense (see below). I guess
> this is similar for Rockchip?
Yes for now, but I think there might be a secure OS in the future.
>
>> Obviously it would help to integrate your loaderimage tool into mkimage.
> FWIW, I extended SPL's FIT loading to support loading multiple images.
> With this I was able to combine (non-SPL) U-Boot, ATF and multiple DTs
> into one FIT image and attach that to the SPL.
> I even managed to include a kernel and initrd in there, fwiw.
> I will post those patches soonish.
Great, good news! Simon also want to enable the SPL support for ATF when we
discuss this issue offline, so I think we can see this feature enabled 
very soon.

Thanks,
- Kever
>
> Cheers,
> Andre.
>
>> Also, what is the difference between your trust_merger tool and ATF's
>> fip_create / fiptool?
>>
>> Regards,
>> Andreas
>>
>
>