From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B9076C433F5 for ; Tue, 15 Feb 2022 13:15:28 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 30625836BE; Tue, 15 Feb 2022 14:15:26 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=nic.cz Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=nic.cz header.i=@nic.cz header.b="hmWG87z4"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 69C0981FC6; Tue, 15 Feb 2022 14:15:24 +0100 (CET) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 80FA2836BE for ; Tue, 15 Feb 2022 14:15:18 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=nic.cz Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=marek.behun@nic.cz Received: from dellmb (unknown [IPv6:2001:1488:fffe:6:8747:7254:5571:3010]) by mail.nic.cz (Postfix) with ESMTPSA id 1889E14089D; Tue, 15 Feb 2022 14:15:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1644930918; bh=mPJXTde0yte7BUp/vbj2zxyY4SH3jooCwJUYoZ+res0=; h=Date:From:To; b=hmWG87z4PbwofFNryfq3zPEMBHIC0J+3HJY8yFK2DfQRn+rmXqnTab0omVPwsla5R vjEvfxW1k9C1XEL+XQL6hJgZtP1Xejuy2P9NUCe/yGSxoIby7n0G9hghdmqEPubu5F kR8vtYvc50ucV/8RIK/IzfKu4NgOzXHMP9yTwsOs= Date: Tue, 15 Feb 2022 14:15:17 +0100 From: Marek =?UTF-8?B?QmVow7pu?= To: Pali =?UTF-8?B?Um9ow6Fy?= Cc: Stefan Roese , u-boot@lists.denx.de Subject: Re: [PATCH u-boot-mvebu 2/3] arm: mvebu: a37xx: Map CCI-400 and AP BootROM address space Message-ID: <20220215141517.0ffed9d6@dellmb> In-Reply-To: <20220215130447.vxokuwtaiwqumgfw@pali> References: <20220214232835.12924-1-pali@kernel.org> <20220214232835.12924-3-pali@kernel.org> <20220215131125.27598730@dellmb> <20220215130447.vxokuwtaiwqumgfw@pali> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean On Tue, 15 Feb 2022 14:04:47 +0100 Pali Roh=C3=A1r wrote: > On Tuesday 15 February 2022 13:11:25 Marek Beh=C3=BAn wrote: > > On Tue, 15 Feb 2022 00:28:34 +0100 > > Pali Roh=C3=A1r wrote: > > =20 > > > In function build_mem_map() prepares also mapping for CCI-400 and =20 > > * prepare =20 > > > AP BootROM address space. > > >=20 > > > A53 AP BootROM by default starts at address 0xfff00000 and is 16 kB l= ong. =20 > >=20 > > RVBAR_EL3 register has value 0xffff0000. The BootROM is 16 KiB long but > > the window is 1 MiB long, so the content repeats every 4 KiB. > > =20 > > > CCI-400 in new TF-A version starts at address 0xfe000000 and is 64 kB= long. > > >=20 > > > Physical addresses are read directly from mvebu registers, so if TF-A > > > remaps it in future then it would not cause any issue. =20 > >=20 > > As we talked about in private conversation, I still don't think we > > should do this unless it is needed. > >=20 > > CCI may be needed to be mapped if ever there is some driver that needs > > to interact with it. > >=20 > > BootROM is never needed by the U-Boot code. > >=20 > > I really don't think that we should map these in production U-Boot > > binaries for everyone, when the intention is "for debugging > > purposes only". In the last 4 years there were 2 people (me, and you > > :)) who were interested in BootROM. In the next 10 years there will be > > maybe 2 more. So I really don't think the windows should be mapped for > > everyone. =20 >=20 > I looked at this stuff because other people asked me about possibility > to dump BootROM. So it is not "only me". Even then, they can just enable the mapping once, dump the code and publish it somewhere. No need to keep it enabled for everyone. > Anyway, the main issue with all this stuff is that there is no public > documentation for it and things which are missing in U-Boot would be > missing forever (because there are only few people with access to > documentation; which is even more incomplete, inconsistent and > incorrect). So adding this stuff may help other people from community > who would like to study this platform or code. As I am saying above, the BootROM code needs to be dumped only once, if someone wants it. No need to always keep the mapping. The code does not change. > Note that, by default U-Boot has already enabled 'md', 'mw', 'pci' and > so other commands which are intended for debug purposes only, so I do > not see reason why _in this version_ cannot be mapped also BootROM code. mw/cmp is not for debugging only. md may be, but mw can reasonably be used from boot scripts. > In _production version_ where is no debug capability and no access to > any memory (just ability to boot) is is probably not needed, but none of > A3720 board is building this kind of version (by default). And in case > BootROM is mapped also in these versions, is there any issue with it? My issue is that it isn't needed. You can just dump it once, publish it somewhere, and you are done. No need to keep that window mapped for everyone else. > BootROM is read-only, same in all A3720 SoCs, so by this definition it > is public and everybody can inspect it... Yes, I also consider the BootROM blob public, since everyone can access it if they know how to, and the necessary information for that is available in TF-A. > Stefan, what do you think about it? >=20 > > Maybe you can map them if some debug option is enabled in menuconfig? > >=20 > > Marek =20