<apritzel>
ah, I know the patch author (from the list)
<loki666>
want me to contact him ?
<apritzel>
well, we want to have a discussion about the patches on the list. From a 30 second glance this seems to go in the right direction, touching the right code places, I'd say
<apritzel>
loki666: you can ask him whether he wants to bring this upstream, alternatively offer to do this for him, if you like
gsz has quit [Quit: leaving]
<apritzel>
jernej: so hacking plat_my_core_pos and plat_core_pos_by_mpidr() at least fixes the EINVAL return, but there is surely more:
<apritzel>
[ 0.149157] smp: Bringing up secondary CPUs ...
<apritzel>
[ 5.426292] CPU1: failed to come online
<apritzel>
[ 5.430515] CPU1: failed in unknown state : 0x0
<loki666>
ok I'll try with a comment on his commit
<apritzel>
jernej: and reset doesn't work, I guess the watchdog code needs some adjustments
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
junari has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<swiftgeek>
nice, sun4i fixes are still happening :D
<swiftgeek>
oh got confused, I actually have sun5i
<jernej>
apritzel: thanks for testing. sounds promising
<jernej>
apritzel: any thoughts on last patch? do you think it's needed?
<apritzel>
loki666: did this patch change anything for you? Originally we thought this might fix your DVFS issues, but that turned out to be not the case.
<loki666>
Indeed the culprit was the ramp delay
<loki666>
But I've been using it since you posted... I'm a bit afraid to drop it now
<loki666>
Another guy on the ML said it was needed for another board
<apritzel>
would you have to chance to run some DVFS stress test without the patch, maybe?
<loki666>
I guess yes
<apritzel>
jernej: btw: I think PSCI kicks in rather early in the kernel boot process, so you might get away with some normal non-A523 aware kernel for testing, when using "earlycon" on the command line
<apritzel>
jernej: and I don't know about those extra secure registers, does the BSP code provide any clue about what they control? I guess we wouldn't see a difference on a non "secure boot" system anyway?
<apritzel>
loki666: ah, I remember now. It seems like wens agreed, but indeed it's not queued anywhere?
<loki666>
I think wens was waiting for your go
<wens>
you'll have to remind me. looking at too many kernel and dts patches at work :|
<apritzel>
wens: I understand that problem ;-) Will send a reply ...
gsz has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
gsz has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<jernej>
apritzel: stupid question, do you have all relevant regulators enabled for second cluster?
<jernej>
apritzel: no clue, I found it in BSP, but I think it's pretty self explanatory - it disables R_SPC, TZMA (some memory protection from arm) and enables non-secure access to DSP PRCM.
apritzel has joined #linux-sunxi
<apritzel>
jernej: regulators: I was already thinking about that, depends on *when* you need it? U-Boot proper would turn it on, but it's probably off when TF-A boots
<apritzel>
in general I suspect some more hurdles for the second cluster, but at least the first four cores should work more easily. Do you see them coming online now?
<jernej>
apritzel: today I don't have time to play on HW, I'm just making general comments
Schimsalabim has quit [Read error: Connection reset by peer]
<apritzel>
fair enough, just wanted to say that I totally expected the second cluster to initially fail, since there might be more power or clock gates or so
gsz has joined #linux-sunxi
colinsane has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
<apritzel>
that breaks the older SoCs, of course, leave this as an exercise to the reader to make this build time switchable ;-)
<jernej>
apritzel: I'm looking at BSP core management code and of course it doesn't match to currently implemented methods
<jernej>
so again, new method needs to be implemented
<apritzel>
I wouldn't be too sure that they got it right. Maybe check the Cortex-A55 TRM instead. This will not talk about MMIO registers (that's the integrator's task), but the general algorithm should be there
<apritzel>
"they got it right" as in: they might be doing too much, or make it too complicated, or copied legacy parts
<apritzel>
I found traces of A53 code still in the BROM (for instance setting bit 6 in ACTLR)
<jernej>
apritzel: could it be that architecturally there is only one cluster with 8 cores?
<apritzel>
lol, just wanted to tell you that ;-)
<jernej>
all code is set in this way
<apritzel>
so yes, on the silicon side they have two power domains, but in the MPIDR it's modelled as one 8-core cluster
<apritzel>
actually the name cluster is old there, Aff0, Aff1, Aff2 is more meaningful in terms of MPIDR handling
<apritzel>
so there are two clusters in terms of power topology: because they have separate regulators and clocks
<apritzel>
that's why I thought the 2nd cluster will be "fun": maybe you focus on the first four cores first, to get the core bringup right, and have more than one core at all?
<jernej>
at least code for powering on and off cores is the same
<jernej>
clocks and regulators are separate
<jernej>
issue
<apritzel>
yes, in our model clocks and regulators are Linux' responsibilities. But that means that they must be at least running, before the PSCI code is called
<apritzel>
AFAIR SMP bringup comes before drivers are initialised, so we can't rely on the kernel to enable the clock and the regulator
<apritzel>
I think your SPL code enables and programs the secondary cluster clock, so that's covered, at least
gsz has joined #linux-sunxi
jason123onirc has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
jason123onirc has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
gsz has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
<apritzel>
MasterR3C0RD: parthiban: do you have any expectations about running your A133 devices on "older" kernels? Say 6.12 (LTS)?
<apritzel>
I am asking because I stumbled over the iosc clock, and indeed MasterR3C0RD has patches for the RTC
<apritzel>
but they would break forward compatibility: you cannot run newer DTs (from U-Boot) with older kernels anymore, you would require a kernel knowing about the A100-RTC
<apritzel>
though maybe it would still work in practice, since both pinctrl and the CCU driver are somewhat forgiving about the IOSC and 32K clock failing to probe ...