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...
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