Dear community,
This is addresed to the Lantiq/Intel developers for the SoC's VRX200 and
XWAY in general.
I'm trying to port the current sources to the common clock framework for
Openwrt.
For this purpose, I'd need to have a good knowledge of both clock
providers and consumers in order to update the device tree and also the
drivers. This means hardware (how devices are connected) and software
(what registers do what?)
There's no such low level detail after all my investigations, which are
shown here:
https://github.com/Mandrake-Lee/Lantiq_XWAY_CGU
For instance, the full structure of PLL2 register remains a mistery and
also its output; OCP selector, is a kind of divider?; PCIe generator is
located where? PMU, is just a gate controller or a provider itself?
I'd really appreciate if you could share some details in order to start
the job.
Please keep me CC'd of this thread.
Thank you very much in advance,
Jorge Amor?s-Argos
On 4/4/20 10:53 AM, Jorge Amoros-Argos wrote:
> Dear community,
>
> This is addresed to the Lantiq/Intel developers for the SoC's VRX200 and
> XWAY in general.
>
> I'm trying to port the current sources to the common clock framework for
> Openwrt.
Thanks for looking into this. this SoC should really be converted to the
common clock framework.
> For this purpose, I'd need to have a good knowledge of both clock
> providers and consumers in order to update the device tree and also the
> drivers. This means hardware (how devices are connected) and software
> (what registers do what?)
>
> There's no such low level detail after all my investigations, which are
> shown here:
>
> https://github.com/Mandrake-Lee/Lantiq_XWAY_CGU
>
> For instance, the full structure of PLL2 register remains a mistery and
> also its output; OCP selector, is a kind of divider?; PCIe generator is
> located where? PMU, is just a gate controller or a provider itself?
>
> I'd really appreciate if you could share some details in order to start
> the job.
A common clock framework driver for the Lightning Mountain(LGM) SoC is
currently being reviewed on the upstream mailling list:
https://lkml.org/lkml/2020/3/24/4
there could still be some similarities between the VRX200 and the LGM,
but there are some generations in between and with the xrx500 many
registers in the CGU block changed.
Martin started to write a driver some years ago:
https://github.com/xdarklight/linux/commits/lantiq-clk-20160620
But this does not really models the clock tree.
Be aware that the clock tree is not so simple, it has a lot of dividers.
Hauke
El Wed, 15 Apr 2020 00:00:20 +0200
Hauke Mehrtens <[email protected]> escribi?:
> On 4/4/20 10:53 AM, Jorge Amoros-Argos wrote:
> > Dear community,
> >
> > This is addresed to the Lantiq/Intel developers for the SoC's
> > VRX200 and XWAY in general.
> >
> > I'm trying to port the current sources to the common clock
> > framework for Openwrt.
>
> Thanks for looking into this. this SoC should really be converted to
> the common clock framework.
>
>
> > For this purpose, I'd need to have a good knowledge of both clock
> > providers and consumers in order to update the device tree and also
> > the drivers. This means hardware (how devices are connected) and
> > software (what registers do what?)
> >
> > There's no such low level detail after all my investigations, which
> > are shown here:
> >
> > https://github.com/Mandrake-Lee/Lantiq_XWAY_CGU
> >
> > For instance, the full structure of PLL2 register remains a mistery
> > and also its output; OCP selector, is a kind of divider?; PCIe
> > generator is located where? PMU, is just a gate controller or a
> > provider itself?
> >
> > I'd really appreciate if you could share some details in order to
> > start the job.
>
> A common clock framework driver for the Lightning Mountain(LGM) SoC is
> currently being reviewed on the upstream mailling list:
> https://lkml.org/lkml/2020/3/24/4
> there could still be some similarities between the VRX200 and the LGM,
> but there are some generations in between and with the xrx500 many
> registers in the CGU block changed.
>
> Martin started to write a driver some years ago:
> https://github.com/xdarklight/linux/commits/lantiq-clk-20160620
> But this does not really models the clock tree.
>
> Be aware that the clock tree is not so simple, it has a lot of
> dividers.
>
> Hauke
>
>
Dear Hauke and friends,
Based on some forsaken sources for linux and uboot, I have managed to
re-create most of the clock layout of the Lantiq VR9.
With this information I've been able to modify the device tree
structure and create a minor set of drivers in order migrate to CCF.
The code is now available at:
https://github.com/Mandrake-Lee/openwrt/tree/LTQ_PORTING_CLK_FRAMEWORK
Also, I've tried to gather all relevant information with references
here:
https://github.com/Mandrake-Lee/Lantiq_XWAY_CGU
There's also a fancy schematic:
https://github.com/Mandrake-Lee/Lantiq_XWAY_CGU/blob/master/VR9_CGU_v0_20200503.pdf
Unfortunately the status so far is UNSTABLE although I have the feeling
that we must be very close to the end.
The boot-up logging is mostly standard but right after kernel modules
are loaded and eth driver detects a link, the system hangs-up and
reboots after 30s roughly. There's no log message at all.
There're still some seconds where a terminal is operative though, so I
guess there's a module loading that crashes without trace.
So any help and comments are really appreciated.
In parallel, the only big "black box" that remains is the PCIe PLL
register meaning. I would appreciate if someone from Lantiq (now Intel)
could give a hand.
Best regards,
Jorge Amor?s-Argos