From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B81AE1841 for ; Sat, 8 Apr 2023 06:27:25 +0000 (UTC) Received: by mail-ej1-f41.google.com with SMTP id ga37so1693365ejc.0 for ; Fri, 07 Apr 2023 23:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680935244; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=kJk+RIYauUS3YHbT7ZnRx1QzfuZzjpxj8La5NE9f84I=; b=qIVps3lOcC8xVOyvwfJN2Huve1EZauUHARdTFBY7TKrdF+7fpPt3Yge56cWLlj5egq 34e/oI9CRoxGZF1SORmlM8c6emydTGCfAuVQhgsYv370FR9adqzjOSC0KVaNTle2ld/1 YM/mzjRi9RNxQMFq2Y2n+LZXBIG3AMAHZnTGRGQm1VMTajThM7NQ6fclZfodmJjrxmgM 23KnnXAm6u+tRH52iw3bIhRFigifZeP4X8hAPZtFWVoLFmwNOxjnCFq6x0W4KDK+2kI0 H2dPucaIrY7GGSpbtz4HOE8WCwJ3AHmS5D/0B9buK3oeV8vFcCZLBQEn+ijsRpsk8BfL BPxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680935244; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kJk+RIYauUS3YHbT7ZnRx1QzfuZzjpxj8La5NE9f84I=; b=wELgTjHuNgboNRHM/kEPwfNhFGTUzs3ZnwilYCxcmJ4mFTEF4DfF24rtjC7xz6WjXq oYYSY2fcI0lxIhu0HKs6S+lg992RZxk8vWIjRErNOoUiqfIAnrrcX5kFUF8iBIcIYj3B j2LzAfG951XaegD4glr7/fKJrg2xa/+Aj3WNesyidLZajrxzYbzZ6ea11uI2Ecv1BqZs /dLD4bfA7ghg+4+iJb6Alra7fLFpl2WXve1pi4yyhVO+31r+SOJ60488REieaAW9e1Pq 1/nAg2ylEsSkj1f/cuSuBWSmjEsLTxQa8qoFWPynqD/nF8aubhI5ZjNyq4bHzjE0ung2 +Lzg== X-Gm-Message-State: AAQBX9fp9FJzPxvyoK6mDl/uKTzLD5VeK+46kseuKSa+PocLwO8OnDO8 /EY5+TOPaaWUJbP7Sfq8rDA= X-Google-Smtp-Source: AKy350YxkCze7UEsViEYo3+hF1Ilr8pzJdUhe1EAuf2uPGmjWx15uT+A6vU0Lo402tPoNUiLWfJBtQ== X-Received: by 2002:a17:906:1e96:b0:93b:5d19:52e1 with SMTP id e22-20020a1709061e9600b0093b5d1952e1mr1428472ejj.50.1680935243686; Fri, 07 Apr 2023 23:27:23 -0700 (PDT) Received: from jernej-laptop.localnet (89-212-118-115.static.t-2.net. [89.212.118.115]) by smtp.gmail.com with ESMTPSA id n19-20020a1709067b5300b008f89953b761sm2797163ejo.3.2023.04.07.23.27.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Apr 2023 23:27:23 -0700 (PDT) From: Jernej =?utf-8?B?xaBrcmFiZWM=?= To: Jagan Teki , Andre Przywara Cc: Samuel Holland , Piotr Oniszczuk , Mikhail Kalashnikov , u-boot@lists.denx.de, linux-sunxi@lists.linux.dev Subject: Re: [RFC PATCH] sunxi: arm64: boot0.h: runtime check for RVBAR address Date: Sat, 08 Apr 2023 08:27:22 +0200 Message-ID: <2137577.irdbgypaU6@jernej-laptop> In-Reply-To: <20230405203011.10325-1-andre.przywara@arm.com> References: <20230405203011.10325-1-andre.przywara@arm.com> Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Dne sreda, 05. april 2023 ob 22:30:11 CEST je Andre Przywara napisal(a): > Some SoCs of the H616 family use a die variant, that puts some CPU power > and reset control registers at a different address. There are examples > of two instances of the same board, using different die revisions of the > otherwise same H313 SoC. We need to write to a register in that block > *very* early in the SPL boot, to switch the core to AArch64. > > Since the devices are otherwise indistinguishable, let the SPL code read > that die variant and use the respective RVBAR address based on that. > That is a bit tricky, since we need to do that in hand-coded AArch32 > machine language, shared by all 64-bit SoCs. To avoid build dependencies > in this mess, we always provide two addresses to choose from, and just > give identical values for all other SoCs. This allows the same code to > run on all 64-bit SoCs, and controls this switch behaviour purely from > Kconfig. > > Signed-off-by: Andre Przywara > --- > Hi, > > this patch goes on top of the two patches I sent earlier, that > introduce CONFIG_SUNXI_RVBAR_ADDRESS. I don't have a device with that > die variant, so just roughly tested this by inverting the ldrne and > swapping the addresses. > Please let me know if you have such a device and can confirm that this > code works on the original and alternative die alike. > > Cheers, > Andre > > arch/arm/include/asm/arch-sunxi/boot0.h | 14 ++++++++++---- > arch/arm/mach-sunxi/Kconfig | 17 ++++++++++++++++- > 2 files changed, 26 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h > b/arch/arm/include/asm/arch-sunxi/boot0.h index 1a396f78488..b27df3b9b5e > 100644 > --- a/arch/arm/include/asm/arch-sunxi/boot0.h > +++ b/arch/arm/include/asm/arch-sunxi/boot0.h > @@ -20,8 +20,8 @@ > b reset > .space 0x7c > > - .word 0xe28f0058 // add r0, pc, #88 > - .word 0xe59f1054 // ldr r1, [pc, #84] > + .word 0xe28f0070 // add r0, pc, #112 // @(fel_stash - .) > + .word 0xe59f106c // ldr r1, [pc, #108] // fel_stash - . > .word 0xe0800001 // add r0, r0, r1 > .word 0xe580d000 // str sp, [r0] > .word 0xe580e004 // str lr, [r0, #4] > @@ -32,8 +32,12 @@ > .word 0xee1cef10 // mrc 15, 0, lr, cr12, cr0, {0} > .word 0xe580e010 // str lr, [r0, #16] > > - .word 0xe59f1024 // ldr r1, [pc, #36] ; 0x170000a0 > - .word 0xe59f0024 // ldr r0, [pc, #36] ; CONFIG_*_TEXT_BASE > + .word 0xe59f1034 // ldr r1, [pc, #52] ; RVBAR_ADDRESS > + .word 0xe59f0034 // ldr r0, [pc, #52] ; SUNXI_SRAMC_BASE > + .word 0xe5900024 // ldr r0, [r0, #36] ; SRAM_VER_REG > + .word 0xe21000ff // ands r0, r0, #255 ; 0xff > + .word 0x159f102c // ldrne r1, [pc, #44] ; RVBAR_ALTERNATIVE > + .word 0xe59f002c // ldr r0, [pc, #44] ; CONFIG_*TEXT_BASE > .word 0xe5810000 // str r0, [r1] > .word 0xf57ff04f // dsb sy > .word 0xf57ff06f // isb sy > @@ -45,6 +49,8 @@ > .word 0xeafffffd // b @wfi > > .word CONFIG_SUNXI_RVBAR_ADDRESS // writable RVBAR mapping addr > + .word SUNXI_SRAMC_BASE > + .word CONFIG_SUNXI_RVBAR_ALTERNATIVE // address for die variant > #ifdef CONFIG_SPL_BUILD > .word CONFIG_SPL_TEXT_BASE > #else > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 0527b3863a7..be0910499bb 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -111,7 +111,7 @@ config SUNXI_SRAM_ADDRESS > SRAM to a different address. > > config SUNXI_RVBAR_ADDRESS > - hex "RVBAR address" > + hex > depends on ARM64 > default 0x09010040 if SUN50I_GEN_H6 > default 0x017000a0 > @@ -122,6 +122,21 @@ config SUNXI_RVBAR_ADDRESS > entry point when switching to AArch64. This store is on different > addresses, depending on the SoC. > > +config SUNXI_RVBAR_ALTERNATIVE > + hex > + depends on ARM64 > + default 0x81000040 if MACH_SUN50I_H616 As discussed on IRC by warpme, above default has a typo. Apart from that, changes look good, so once fixed: Reviewed-by: Jernej Skrabec Best regards, Jernej > + default 0x09010040 if SUN50I_GEN_H6 > + default 0x017000a0 > + ---help--- > + The H616 die exists is at least two variants, with one having the > + RVBAR registers at a different address. If the SoC variant ID > + (stored in SRAM_VER_REG[7:0]) is not 0, we need to use the > + other address. > + Set this alternative address to the same as the normal address > + for all other SoCs, so the content of the SRAM_VER_REG becomes > + irrelevant there, and we can use the same code. > + > config SUNXI_A64_TIMER_ERRATUM > bool