From patchwork Fri Apr 5 08:30:05 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Heiko_St=C3=BCbner?= X-Patchwork-Id: 1078170 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.denx.de (client-ip=81.169.180.215; helo=lists.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=sntech.de Received: from lists.denx.de (dione.denx.de [81.169.180.215]) by ozlabs.org (Postfix) with ESMTP id 44bCjG2Bmtz9sPS for ; Fri, 5 Apr 2019 19:32:02 +1100 (AEDT) Received: by lists.denx.de (Postfix, from userid 105) id DD5C8C21DFA; Fri, 5 Apr 2019 08:31:40 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable autolearn_force=no version=3.4.0 Received: from lists.denx.de (localhost [IPv6:::1]) by lists.denx.de (Postfix) with ESMTP id 53155C21E44; Fri, 5 Apr 2019 08:31:19 +0000 (UTC) Received: by lists.denx.de (Postfix, from userid 105) id 3E778C21DF9; Fri, 5 Apr 2019 08:31:14 +0000 (UTC) Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by lists.denx.de (Postfix) with ESMTPS id DD524C21E30 for ; Fri, 5 Apr 2019 08:31:10 +0000 (UTC) Received: from ip5f5a6320.dynamic.kabel-deutschland.de ([95.90.99.32] helo=phil.fritz.box) by gloria.sntech.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1hCKFT-0001vf-UR; Fri, 05 Apr 2019 10:30:55 +0200 From: Heiko Stuebner To: sjg@chromium.org, philipp.tomsich@theobroma-systems.com Date: Fri, 5 Apr 2019 10:30:05 +0200 Message-Id: <20190405083013.5473-1-heiko@sntech.de> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Cc: u-boot@lists.denx.de, hl@rock-chips.com Subject: [U-Boot] [PATCH 0/8] arm-trusted-firmware support for rk3288 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.18 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" This adds support for jumping into aarch32 ATF from u-boot spl similar to how it works on aarch64. I guess the biggest question might be "why" ;-) Right now the status quo on Rockchip arm32 socs is, that the linux kernel itself does smp and suspend handling. This precludes us from doing fance things like virtualization but also deep suspend with the DDR in self refresh, due to at least 2 approaches for putting generalized code into sram from the kernel side failed so far. For Virtualization we need the kernel to start in hyp mode and hence needing to use psci for smp handling as well. So there are multiple ways for achieving that, we could do - psci in uboot itself is bad for coreboot and barebox who would need to reimplement the same - psci in optee is the solution Rockchip themself choose but only provides precompiled binaries for their arm32 socs and also reimplmenting this in an open way is somewhat of a dead-end because while aarch64 can use op-tee, psci itself is always done in the atf - atf using the somewhat new aarch32 port has the advantage of being able to share a lot of platform code making maintenance together with the aarch64 parts a lot easier Not having to rely on binary components as part of the boot process is way nicer not only for reproducible builds but also for future proofing projects as binary blobs may not receive updates after some time. Also it is still possible to use this together with an optee implementation for specific security foobar. The only difference is that while aarch64 can has separate states for secure monitor and secure-os, in aarch32 both need to share the bl32 space, so optee needs to be a payload during the atf build. If no secure-os is needed, atf can use the sp_min payload, which is part of atf. This works nicely on my rk3288 evb and even virtualization worked already. Full support will still need a modified devicetree to actually make use of the new psci capabilites. Heiko Stuebner (8): arm: v7: add read_mpidr function for arm32 spl: atf: add arm32 variant rockchip: rk3288: move TPL options to generic position rockchip: rk3288: adjust load addresses rockchip: rk3288: reserve first 2MB when build with ATF support rockchip: rk3288: split evb into its two entities rockchip: rk3288: convert rk3288-evb to use tpl rockchip: rk3288: make both evb variants use atf arch/arm/dts/Makefile | 3 +- ...evb.dts => rk3288-evb-act8846-u-boot.dtsi} | 33 +- arch/arm/dts/rk3288-evb-act8846.dts | 188 +++++++ arch/arm/dts/rk3288-evb-rk808-u-boot.dtsi | 40 ++ arch/arm/dts/rk3288-evb-rk808.dts | 202 +++++++ arch/arm/dts/rk3288-evb.dtsi | 493 ++++++++---------- arch/arm/include/asm/system.h | 9 + arch/arm/mach-rockchip/Kconfig | 16 + arch/arm/mach-rockchip/rk3288/Kconfig | 16 +- arch/arm/mach-rockchip/rk3288/rk3288.c | 16 + board/rockchip/evb_rk3288/evb-rk3288.c | 14 + board/rockchip/evb_rk3288/fit_spl_atf.its | 52 ++ common/spl/Kconfig | 2 +- common/spl/spl_atf.c | 86 ++- ...defconfig => evb-rk3288-act8846_defconfig} | 14 +- configs/evb-rk3288-rk808_defconfig | 91 ++++ include/atf_common.h | 52 ++ include/configs/rk3288_common.h | 8 +- 18 files changed, 998 insertions(+), 337 deletions(-) rename arch/arm/dts/{rk3288-evb.dts => rk3288-evb-act8846-u-boot.dtsi} (64%) create mode 100644 arch/arm/dts/rk3288-evb-act8846.dts create mode 100644 arch/arm/dts/rk3288-evb-rk808-u-boot.dtsi create mode 100644 arch/arm/dts/rk3288-evb-rk808.dts create mode 100644 board/rockchip/evb_rk3288/fit_spl_atf.its rename configs/{evb-rk3288_defconfig => evb-rk3288-act8846_defconfig} (87%) create mode 100644 configs/evb-rk3288-rk808_defconfig