GSoC PRU: AM35xx Clock driver
Nils Hölscher
nilhoel1 at gmail.com
Wed Jul 31 12:54:59 UTC 2019
Hi,
I have been reading into the FreeBSD init code the past few days,
especially for Driver_MODULE.
Expect an Blog entry today or tomorrow.
Because I don't have JTAG, it took me quite some time.
With BUS_DEBUG enabled I saw that the problem is indeed that the pruss unit
is discovered too early.
Is this device tree related?
I am not sure, cause the overlay I am using is from the BSD community.
I added my output to a gist and link to the interesting parts.
The EARLY_DRIVER_MODULE's are indeed loaded first.
https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L125
Nexus bus attaches and the driver goes over every discovered device and
tries to attach the drivers in order:
https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L326
ofwbus gets discovered:
https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L747
Here the ti_pruss device gets discovered too early in the fdt and fails:
https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L904
I still haven't found the loop running over fdt.
And it seems that the device tree only gets one iteration.
But the BSD man page for EARLY_DRIVER_MODULE states that every PASS_LEVEL
has an iteration.
"
The *EARLY*_*DRIVER*_*MODULE*() macro allows a driver to be
registered for a
specific pass level. The boot time probe and attach process makes *multi-
ple passes over the device tree*. Certain critical drivers that provide
basic services needed by other devices are attach during earlier passes.
Most drivers are attached in a final general pass. A driver that
attaches during an early pass must register for a specific pass level
(BUS_PASS_*) via the *pass* argument. Once a driver is registered it is
available to attach to devices for all subsequent passes."
https://www.freebsd.org/cgi/man.cgi?query=DRIVER_MODULE&sektion=9&apropos=0&manpath=FreeBSD+12.0-RELEASE+and+Ports
Best,
Nils
On Sun, 28 Jul 2019 at 11:34, Christian Mauderer <list at c-mauderer.de> wrote:
> On 28/07/2019 11:22, Nils Hölscher wrote:
> >
> >
> > On Sat, 27 Jul 2019 at 14:34, Christian Mauderer <list at c-mauderer.de
> > <mailto:list at c-mauderer.de>> wrote:
> >
> > On 24/07/2019 16:53, Nils Hölscher wrote:
> > > Hi,
> > >
> > > @Vijay Kumar Banerjee <mailto:vijaykumar9597 at gmail.com
> > <mailto:vijaykumar9597 at gmail.com>> thanks for the
> > > dtb file.
> > > I build my file from FreeBSD master.
> > >
> > > Prcm attaches now but still after the pruss driver...:
> > > "
> > > nexus0: <RTEMS Nexus device>
> > > ofwbus0: <Open Firmware Device Tree> on nexus0
> > > simplebus0: <Flattened device tree simple bus> on ofwbus0
> > > *ti_pruss0: <TI Programmable Realtime Unit Subsystem> mem
> > > 0x4a300000-0x4a37ffff irq 20,21,22,23,24,25,26,27 on simplebus0
> > > ti_pruss0: could not enable PRUSS clock
> > > device_attach: ti_pruss0 attach returned 6*
> > > simplebus1: <Flattened device tree simple bus> on simplebus0*
> > > am335x_prcm0: <AM335x Power and Clock Management> mem
> > 0x200000-0x203fff
> > > on simplebus1*
> >
> > Hello Nils,
> >
> > I'm not sure about the order. But what seems a little bit odd is that
> > the prcm0 is found in simplebus0 while am335x_prcm0 is found on
> > simplebus1. Maybe it's worth investigating how that order is created
> and
> > how it is handled in RTEMS.
> >
> >
> > Thanks for the information.
> > I think the way rtems initializes the bsd modules differs from the way
> > described in the libbsd manuel.
> > But I will have to investigate that further.
> >
> >
>
> I'm not 100% sure but as far as I know the _modules_ should be
> initialized in the given order (early module prior to normal module).
> But the device detection is something different. I think there is some
> loop in simplebus that loops over the devices and asks every driver
> whether it wants to handle that device. If yes the driver can have it.
> If no the device is unhandled.
>
> For a module that is mentioned in the device tree I would expect that
> the order in the device tree binary is the one used. For devices outside
> of the device tree most likely some link order is used.
>
> If you have a debugger you might want to search for the loops and take a
> look at when they are called and how they add devices. I don't think
> that there are that many early modules yet that would use the device
> tree. So it's possible that there is some call missing that would parse
> the device tree for early modules.
>
> >
> >
> > A general note regarding the prcm module: In RTEMS most (non-libbsd)
> > drivers enable their power and clocks themself. Please make sure that
> > the FreeBSD prcm doesn't interfere with that. Otherwise you might get
> > odd effects.
> >
> > Thanks I will keep that in mind.
> >
> > Best,
> > Nils
> >
> >
> > Best regards
> >
> > Christian
> >
> > > *====am335x_prcm_attach====*
> > > "
> > >
> > > Is there anything else I can do besides using MODULE_DEPENDENCY,
> > which I
> > > already use.
> > > The prcm module is also a EARLY_DRIVER_MODULE.
> > >
> > > Best,
> > > Nils
> > >
> > > On Wed, 24 Jul 2019 at 16:04, Vijay Kumar Banerjee
> > > <vijaykumar9597 at gmail.com <mailto:vijaykumar9597 at gmail.com>
> > <mailto:vijaykumar9597 at gmail.com <mailto:vijaykumar9597 at gmail.com>>>
> > wrote:
> > >
> > >
> > >
> > > On Wed, Jul 24, 2019 at 7:03 PM Nils Hölscher
> > <nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>
> > > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>>>
> wrote:
> > >
> > >
> > >
> > > On Wed, 24 Jul 2019 at 15:14, Vijay Kumar Banerjee
> > > <vijaykumar9597 at gmail.com
> > <mailto:vijaykumar9597 at gmail.com> <mailto:vijaykumar9597 at gmail.com
> > <mailto:vijaykumar9597 at gmail.com>>> wrote:
> > >
> > >
> > >
> > >
> > > On Wed, Jul 24, 2019 at 6:36 PM Nils Hölscher
> > > <nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>
> > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>>> wrote:
> > >
> > > Hi again,
> > >
> > > Hi Nils
> > >
> > > I just decompiled my device tree and checked.
> > > The probe code of the prcm driver is as follows:
> > > "
> > > static int
> > > am335x_prcm_probe(device_t dev)
> > > {
> > > printk("am335x_prcm_probe\n");
> > >
> > > if (!ofw_bus_status_okay(dev)){
> > > printk("ofw_bus_status_not_okay\n");
> > > return (ENXIO);
> > > }
> > >
> > > Do you get the "ofw_bus_status_not_okay" print ?
> > >
> > > Yes. But I also see the other print. except the success
> one.
> > >
> > > if (ofw_bus_is_compatible(dev, "ti,am3-prcm"))
> {
> > > device_set_desc(dev, "AM335x Power and
> Clock
> > > Management");
> > > printk("PROBE SUCESSFULL\n");
> > > return(BUS_PROBE_DEFAULT);
> > > }
> > > printk("ofw_bus incompatible\n");
> > > return (ENXIO);
> > > }
> > > "
> > > So it seems the prcm part in the device tree has
> to be
> > > compatible to "ti,am3-prcm".
> > > The thing is the decompiled device tree states
> > just that:
> > > "
> > > prcm at 0 {
> > > compatible =
> > > "ti,am3-prcm\0simple-bus";
> > >
> > > In my device tree, it runs successfully and the
> decompiled
> > > compatible looks like :
> > > ```
> > > prcm at 200000 {
> > > compatible = "ti,am3-prcm";
> > > reg = < 0x200000 0x4000 >;
> > > linux,phandle = < 0x4a >;
> > > phandle = < 0x4a >;
> > > ```
> > >
> > > OK, this is awkward, cause we both should have used the
> same
> > > sources.
> > >
> > > Have you checked that your source is from the tree matching the
> > > libBSD HEAD
> > > commit?
> > >
> > > reg = <0x00 0x2000>;
> > > #address-cells = <0x01>;
> > > #size-cells = <0x01>;
> > > ranges = <0x00 0x00
> 0x2000>;
> > > phandle = <0x5a>;
> > > [...]
> > > "
> > > Any ideas would help, cause I am currently not
> able to
> > > understand this behaviour.
> > > Also without this driver even the dev_usb_bbb
> driver
> > > shouldn't work.
> > > However it attaches because it doesn't check for
> the
> > > clocks error code.
> > >
> > > I remember testing this a few days ago for my fb
> > drivers and
> > > it was attaching alright,
> > > if I remember correctly. If changing the dtb doesn't
> work
> > > for you, I won't mind checking
> > > again, this will give me a hint for the display issue
> > as well.
> > >
> > > I will keep you updated on this.
> > > Would you be so kind and send me your compiled device
> tree?
> > >
> > > Please find it attached in this mail.
> > >
> > > Note: I have removed the devel from the cc because the
> attachment
> > > might be
> > > big for the list. Please continue the discussion in the
> > mailing list
> > > and maybe note
> > > it somewhere that you already received the dtb from me in
> > private mail.
> > >
> > > Regards,
> > > Vijay
> > >
> > >
> > >
> > > Best,
> > > Nils
> > >
> > >
> > >
> > > On Wed, 24 Jul 2019 at 14:43, Nils Hölscher
> > > <nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>
> > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>>> wrote:
> > >
> > > Hi,
> > >
> > > I just found out that the prcm driver fails to
> > probe
> > > on the simplebus and therefore cannot apply
> > itself.
> > > Seems like I am back to checking dtb.
> > >
> > > Best,
> > > Nils
> > >
> > > On Tue, 23 Jul 2019 at 14:26, Nils Hölscher
> > > <nilhoel1 at gmail.com
> > <mailto:nilhoel1 at gmail.com> <mailto:nilhoel1 at gmail.com
> > <mailto:nilhoel1 at gmail.com>>> wrote:
> > >
> > > Hi,
> > >
> > > After debugging with printk, didn't get the
> > > module loading working as suggested by
> > Sebastian.
> > > I just found out that my PRU driver can't
> be
> > > attached, cause the AM35xx clock driver
> isn't
> > > loaded.
> > > The driver can be found her:
> > >
> >
> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c
> > >
> > > Can anyone tell me how to load this driver
> and
> > > obisouly before I initialize my BSD
> modules?
> > >
> > > FYI: The code line that fails is this one,
> > cause
> > > the driver hasn't been initialized.
> > >
> >
> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c#L854
> > >
> > > Thanks,
> > > Nils
> > >
> > > _______________________________________________
> > > devel mailing list
> > > devel at rtems.org <mailto:devel at rtems.org>
> > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
> > > http://lists.rtems.org/mailman/listinfo/devel
> > >
> > >
> > > _______________________________________________
> > > devel mailing list
> > > devel at rtems.org <mailto:devel at rtems.org>
> > > http://lists.rtems.org/mailman/listinfo/devel
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190731/03e4d701/attachment-0002.html>
More information about the devel
mailing list