public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Sam Edwards <cfsworks@gmail.com>
Cc: u-boot@lists.denx.de, Jagan Teki <jagan@amarulasolutions.com>,
	Samuel Holland <samuel@sholland.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Icenowy Zheng <uwu@icenowy.me>,
	Maksim Kiselev <bigunclemax@gmail.com>
Subject: Re: [PATCH 3/3] sunxi: psci: implement PSCI on R528
Date: Tue, 15 Aug 2023 23:59:46 +0100	[thread overview]
Message-ID: <20230815235946.0c8b0dce@slackpad.lan> (raw)
In-Reply-To: <225be7f9-558e-4695-0b38-b30b0229cdcd@gmail.com>

On Tue, 15 Aug 2023 13:17:33 -0600
Sam Edwards <cfsworks@gmail.com> wrote:

Hi Sam,

> On 8/14/23 08:16, Andre Przywara wrote:
> > Hi Sam,
> >   
> >> This patch adds the necessary code to make nonsec booting and PSCI
> >> secondary core management functional on the R528/T113.  
> > 
> > Unfortunately this patch breaks the build on older 32-bit SoCs, as
> > SUNXI_CPUX_BASE is not defined there. That's a typical problem of the
> > "C-if" approach, but typically there is a clean, albeit not trivial,
> > solution:
> > 
> > It seems like SUNXI_CPUX_BASE and SUNXI_CPUCFG_BASE are mutually
> > exclusive, and I actually carry a "#define SUNXI_CPUCFG_BASE 0" hack in my
> > patches already.
> > So I wonder if we should unify those two into SUNXI_CPUCFG_BASE, with the
> > following rework:  
> 
> The SUNXI_CPUX_BASE -> SUNXI_CPUCFG_BASE rename worked excellently. 
> We're having the same problem with SUNXI_R_CPUCFG_BASE as well, though. 
> How do you want to handle that?

So that's a bit more nasty indeed. I don't even know if R_CPUCFG really
makes sense here, as the _R_ term typically refers to the management
processor, which the D1/R528 don't have. Or at least the always-on power
domain, but then again this hardly relates to the secondary entry
point. I think the name was just used because the address matches the
one used in the H6. Anyway, I got the impression that Allwinner just
uses registers wherever they find them, and that they don't care too
much about logical grouping or compatibility.

So taking a step back, I wonder if we should actually just define a
CONFIG_SUNXI_CPU_SOFT_ENTRY (or so) *Kconfig* symbol, which holds that
address, and let the per-SoC definition be solved in Kconfig instead.
Because SUNXI_R_CPUCFG_BASE and also SUNXI_RTC_BASE seem to be just
used as the base address for that purpose, with some magic offset
added, across all of U-Boot (ARMv8 FEL and v7 PSCI).

So can you try to work on that base? I will take care of
armv8/fel_utils.S, which uses some post-increment assembly trick to
keep the code small, which wouldn't work anymore. But I have an idea
how to solve this.

Cheers,
Andre

  reply	other threads:[~2023-08-15 23:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-12  0:30 [PATCH 0/3] Allwinner R528/T113s PSCI Sam Edwards
2023-08-12  0:30 ` [PATCH 1/3] sunxi: psci: clean away preprocessor macros Sam Edwards
2023-08-14 16:37   ` Andre Przywara
2023-08-14 18:10     ` Sam Edwards
2023-08-14 21:05       ` Andre Przywara
2023-08-14 21:23         ` Sam Edwards
2023-08-12  0:30 ` [PATCH 2/3] sunxi: psci: refactor register access to separate functions Sam Edwards
2023-08-12  0:30 ` [PATCH 3/3] sunxi: psci: implement PSCI on R528 Sam Edwards
2023-08-14 14:16   ` Andre Przywara
2023-08-15 19:17     ` Sam Edwards
2023-08-15 22:59       ` Andre Przywara [this message]
2023-08-16  1:48         ` Sam Edwards
2023-08-18 14:27           ` Andre Przywara
2023-08-18 22:22             ` Sam Edwards
2023-08-14 14:06 ` [PATCH 0/3] Allwinner R528/T113s PSCI Andre Przywara
2023-08-14 18:31   ` Sam Edwards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230815235946.0c8b0dce@slackpad.lan \
    --to=andre.przywara@arm.com \
    --cc=bigunclemax@gmail.com \
    --cc=cfsworks@gmail.com \
    --cc=jagan@amarulasolutions.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=samuel@sholland.org \
    --cc=u-boot@lists.denx.de \
    --cc=uwu@icenowy.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox