On Mon, Jan 15, 2018 at 11:25:00AM +0800, Kever Yang wrote: >Bryan, > > >On 01/12/2018 11:10 PM, Bryan O'Donoghue wrote: >> >> >>On 12/01/18 11:27, Philipp Tomsich wrote: >>>>OP-TEE is an open source trusted OS, in armv7, its loading and >>>>running are like this: >>>>loading: >>>>- SPL load both OP-TEE and U-Boot >>>>running: >>>>- SPL run into OP-TEE in secure mode; >>>>- OP-TEE run into U-Boot in non-secure mode; >>>> >>>>More detail: >>>>https://github.com/OP-TEE/optee_os >>>>and search for 'boot arguments' for detail entry parameter in: >>>>core/arch/arm/kernel/generic_entry_a32.S >>>> >>>>Signed-off-by: Kever Yang <kever.y...@rock-chips.com> >>>>--- >>>> >>>>Changes in v4: >>>>- use NULL instead of '0' >>>>- add fdt_addr as arg2 of entry >>>> >>>>Changes in v3: None >>>>Changes in v2: >>>>- Using new image type for op-tee >>>> >>>> common/spl/Kconfig | 7 +++++++ >>>> common/spl/Makefile | 1 + >>>> common/spl/spl.c | 9 +++++++++ >>>> common/spl/spl_optee.S | 13 +++++++++++++ >>>> include/spl.h | 13 +++++++++++++ >>>> 5 files changed, 43 insertions(+) >>>> create mode 100644 common/spl/spl_optee.S >>>> >>> >>>Acked-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com> >>>_______________________________________________ >>>U-Boot mailing list >>>U-Boot@lists.denx.de >>>https://lists.denx.de/listinfo/u-boot >>> >> >>Kever, Philipp >> >>I have patches that define a IH_TYPE_OPTEE as a bootable OPTEE >>image (one that never returns to u-boot). > >I don't understand how you use OP-TEE in your project. >You are using U-Boot 'bootm' cmd to run into OP-TEE and 'PC' never >get out of the OP-TEE os? >The upstream OP-TEE will always be back to the pointer in 'lr'. > >We are using boot flow like ARMv8 for OP-TEE in armv7, could you >introduce your flow?
The flow is ROM->U-Boot->OP-TEE->Linux. Regards, Peng. >bootrom(BL1, secure word)->SPL(BL2, secure word)->OP-TEE(BL31/32, >secure word) >->U-Boot(BL33, non-secure word)->Linux kernel(non secure word). >By the OP-TEE design we need jump to U-Boot with using 'lr' as >pointer to next stage, that's why I add >new type for SPL image: >https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/kernel/generic_entry_a32.S#L186 > >Thanks, >- Kever >> >>The image type allows bootm to identify the type of binary it is >>booting and perform image-specific checks. >> >>On this patch though, do you guys really need a new image type for >>SPL ? Couldn't you use IH_TYPE_TEE in the same way ? >> >>+#if CONFIG_IS_ENABLED(OPTEE) >>+ case IH_TYPE_TEE: >>+ debug("Jumping to U-Boot via OP-TEE\n"); >>+ spl_optee_entry(NULL, NULL, spl_image->fdt_addr, >>+ (void *)spl_image.entry_point); >>+ break; >>+#endif >> >>i.e. it appears to me as if you don't actually do anything >>image-specific with IH_OS_OP_TEE that couldn't be done with the >>existing IH_TYPE_TEE... as above you use spl_image->fdt_addr and >>spl_image.entry_point - as opposed to any header specific data from >>the binary you are booting.. >> >>_______________________________________________ >>U-Boot mailing list >>U-Boot@lists.denx.de >>https://lists.denx.de/listinfo/u-boot > > >_______________________________________________ >U-Boot mailing list >U-Boot@lists.denx.de >https://lists.denx.de/listinfo/u-boot -- _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
