All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: "Pali Rohár" <pali@kernel.org>
Cc: baruch@tkos.co.il, dgilmore@redhat.com, dirk.eibach@gdsys.cc,
	jon@solid-run.com, judge.packham@gmail.com, marek.behun@nic.cz,
	mario.six@gdsys.cc, sr@denx.de, u-boot@lists.denx.de
Subject: Re: [PATCH 5/5] arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK
Date: Tue, 16 Aug 2022 22:05:13 +0200	[thread overview]
Message-ID: <f72dc20c0592c7d076f5c01b0756b7f6@walle.cc> (raw)
In-Reply-To: <20220816181708.5t3rl5zxo5oqjder@pali>

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

  parent reply	other threads:[~2022-08-16 20:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-31 12:22 [PATCH 0/5] arm: mvebu: Automatically detect CONFIG_SYS_TCLK Pali Rohár
2021-07-31 12:22 ` [PATCH 1/5] arm: mvebu: a38x: Detect CONFIG_SYS_TCLK from SAR register Pali Rohár
2021-08-02  6:33   ` Stefan Roese
2021-07-31 12:22 ` [PATCH 2/5] arm: mvebu: a37x: " Pali Rohár
2021-08-02  6:33   ` Stefan Roese
2021-07-31 12:22 ` [PATCH 3/5] arm: mvebu: msys: Set CONFIG_SYS_TCLK globally Pali Rohár
2021-08-02  6:34   ` Stefan Roese
2021-07-31 12:22 ` [PATCH 4/5] arm: mvebu: axp: " Pali Rohár
2021-08-02  6:35   ` Stefan Roese
2021-07-31 12:22 ` [PATCH 5/5] arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK Pali Rohár
2021-08-01  8:07   ` Chris Packham
2021-08-01 10:25     ` Pali Rohár
2022-08-16  9:37       ` Michael Walle
2022-08-16 18:17         ` Pali Rohár
2022-08-16 19:38           ` Pali Rohár
2022-08-16 20:02             ` Pali Rohár
2022-08-16 20:06             ` Michael Walle
2022-08-16 20:05           ` Michael Walle [this message]
2021-08-02  6:35   ` Stefan Roese
2021-08-11  8:27 ` [PATCH 0/5] arm: mvebu: Automatically detect CONFIG_SYS_TCLK Stefan Roese

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=f72dc20c0592c7d076f5c01b0756b7f6@walle.cc \
    --to=michael@walle.cc \
    --cc=baruch@tkos.co.il \
    --cc=dgilmore@redhat.com \
    --cc=dirk.eibach@gdsys.cc \
    --cc=jon@solid-run.com \
    --cc=judge.packham@gmail.com \
    --cc=marek.behun@nic.cz \
    --cc=mario.six@gdsys.cc \
    --cc=pali@kernel.org \
    --cc=sr@denx.de \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.