[PATCH 5/5] arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK

[Michael Walle]

Am 2022-08-16 20:17, schrieb Pali Rohár:
>> > > If I understand correctly
>> > > the defines in kw88f6281.h/kw88f6192.h were sensible defaults but
>> > > boards were able to override it to reflect the hardware configuration.
>> >
>> > Anyway, I think that this patch should not cause issue as it is changing
>> > only two board config files and removing redefinition of CONFIG_SYS_TCLK
>> > macro which is set to the same value as in kw88f61**.h files.
>> 
>> At least for the lsxl and the NET2BIG_V2 this is not correct. Both 
>> have
>> the 88F6281 and both use have a 166MHz TCLK clock.
> 
> Interesting... because this contradicts publicly available
> documentation. Maybe in NDA doc is some more details?

No, the board support was entirely done by reverse engineering the
original bootloader, back in 2012..

>> Anyway, I'm reverting this patch. The only open question is, should I
>> convert the TCLK to a Kconfig option?
> 
> In this case it would be better to detect TCLK from some SAR register,
> like it is already implemented for other Armada SoCs.

Maybe a bit of a background: The LS-XHL and the LS-CHLv2 share the same
PCB, labeled LSXL (thus the board name). the LS-CHLv2 being the 
low-budget
version, i.e. only 64MiB of memory and a slower CPU clock. The LS-XHL
has 256MiB memory.

I have both boards and I've dumped the SAR:

On the LS-XHL (TCLK 200MHz):
# busybox devmem 0xf1010030 32
0x0093CE96

On the LS-CHLv2 (TCLK 166MHz):
# busybox devmem 0xf1010030 32
0x00B2CA4C

> md f1040000 1
f1040000: 628111ab

> Just by a chance, do you have some "better" 88F6281 documentation? If
> there is some TCLK information or SAR register description. In publicly
> available FS_88F6180_9x_6281_OpenSource.pdf there is 0x10030 Sample at
> Reset Register, but nothing TCLK related.

This made me look closer, and linux is reporting:
[    0.000017] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps 
every 21474836475ns
and on the other board:
[    0.000015] sched_clock: 32 bits at 166MHz, resolution 6ns, wraps 
every 12884901885ns

I've digged into it and the kirkwood-core-clock has more information:
https://elixir.bootlin.com/linux/v5.19.1/source/drivers/clk/mvebu/kirkwood.c#L59

I'll take a look at how this could then be determined at runtime.

> At least BootROM has to detect TCLK because UART clock is derived from
> TCLK and BootROM supports UART booting via 115200 baudrate. In case you
> can provide me 88F6281 BootROM dump from your board, I can try to find
> code which configures UART and detect TCLK. I have already did it for
> 88F6820 (A385) to verify that U-Boot code detects TCLK in the same way
> as BootROM.

If you still need the bootrom and it is readable in u-boot, I can 
provide
you the dump.

-michael