Hi Vignesh,
Il 2025-07-01 09:14 Raghavendra, Vignesh ha scritto:
Hi Francesco
On 6/30/2025 7:35 PM, Francesco Valla wrote:
Hi Anshul,
On Tuesday, 3 June 2025 at 16:24:40 Anshul Dalal <[email protected]>
wrote:
This patch set adds support for falcon boot on AM62a, 62p and 62x by
bypassing A53 SPL and U-boot.
Existing Boot flow:
R5 SPL -> ATF -> A53 SPL -> U-Boot -> Linux Kernel
Updated flow:
R5 SPL -> ATF -> Linux Kernel
...
I tried this series on a custom device based on AM62P. While it's
working
mostly fine, I noticed that PWM0 is not working after a falcon boot
from
R5F, while it was working correctly after a boot through full U-Boot.
After a bit of debugging, I noticed that the epwm_tbclk0 is marked as
disabled in hardware in debugfs's clk_summary even if enabled by
software:
$ head -n 2 /sys/kernel/debug/clk/clk_summary && cat
/sys/kernel/debug/clk/clk_summary | grep pwm
enable prepare protect
duty hardware connection
clock count count count rate
accuracy phase cycle enable consumer id
clk:86:0 0 0 0
250000000 0 0 50000 Y 23000000.pwm
fck
epwm_tbclk2 0 0 0 0
0 0 50000 N deviceless
no_connection_id
epwm_tbclk1 0 0 0 0
0 0 50000 N deviceless
no_connection_id
epwm_tbclk0 1 1 0 0
0 0 50000 N 23000000.pwm
tbclk
Reading the associated register (0x00104130) returns in fact
0x00000000,
while writing to it has no effect (and after a write the register
reads
back as 0x00000000).
Do you have any idea on the reason of this behaviour? I don't think it
is
directly related to the Falcon boot implementation, but probably a
side
effect of it (maybe something that was enabled by A53 SPL?).
My guess is that CTRL_MMR region which hosts TB_CLKEN isn't unlocked.
We unlock the CTRL_MMR here:
https://elixir.bootlin.com/u-boot/v2025.04/source/arch/arm/mach-k3/am62px/am62p5_init.c#L156
But its possible that DM firmware that runs after R5 SPL re-locks these
registers and Linux is no longer able to write to those registers.
So this may need fix in the DM firmware to keep these regions unlocked.
Looking at address of tbclk (0x00104130), it should be under region 4.
Could you try after running the equivalent of
mmr_unlock(CTRL_MMR0_BASE, 4); at Linux prompt using devmem2 and then
modify the TB_CLKEN?
that was exactly the issue, after unlocking the CTRL_MMR region the
TB_CLKEN bits wrote correctly and the PWM started working again.
According to TRM, the correct region is number 1.
These were the issued commands to unlock the CTRL_MMR region 1:
$ devmem2 0x105008 w 0x68EF3490
$ devmem2 0x10500C w 0xD172BC5A
and then to write TB_CLKEN for PWM channel 0:
$ devmem2 0x00104130 w 0x1
The clock then is marked as enabled also from a hardware point of view:
$ head -n 2 /sys/kernel/debug/clk/clk_summary && cat
/sys/kernel/debug/clk/clk_summary | grep pwm
enable prepare protect
duty hardware connection
clock count count count rate
accuracy phase cycle enable consumer id
epwm_tbclk2 0 0 0 0
0 0 50000 Y deviceless
no_connection_id
epwm_tbclk1 0 0 0 0
0 0 50000 N deviceless
no_connection_id
epwm_tbclk0 1 1 0 0
0 0 50000 N 23000000.pwm tbclk
clk:86:0 0 0 0 250000000
0 0 50000 Y 23000000.pwm fck
What's the correct path to issue a bug for the DM firmware?
Thank you!
Regards,
Francesco
