GSoC PRU: AM35xx Clock driver
Christian Mauderer
christian.mauderer at embedded-brains.de
Thu Aug 1 09:36:51 UTC 2019
Hello Nils,
On 31/07/2019 14:54, Nils Hölscher wrote:
> 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.
I would always suggest a JTAG or some other kind of debugger for
embedded work. In a professional work environment you should try to
convince your boss that it is a big time saver (which is definitively
true) so that even an expensive debugger is a good investment
By the way: For understanding the initialization sequence you might can
use a simulator too. For the basic sequence you can simulate any BSP and
are not bound to BBB.
> With BUS_DEBUG enabled I saw that the problem is indeed that the pruss
> unit is discovered too early.
> Is this device tree related?
It's possible that this is a difference in how modules are handled. I'm
not sure whether FreeBSD loads EARLY_MODULES dynamically at another time
during boot while we link everything in from the start. If that is true,
the mechanism might not work the same like in FreeBSD. You might want to
have a look at that.
>
> 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.
Don't have a test environment ready so this is just from a quick glance
at the code. I might have missed something:
simplebus_attach adds all child nodes from the tree to the bus:
https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/dev/fdt/simplebus.c#n157
The bus_generic_attach then loops over all children and calls their
probe and attach functions:
https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/kern/subr_bus.c#n3768
Best regards
Christian
> 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
> <mailto: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>
> > <mailto: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>
> > <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>>
> > <mailto: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>>
> > > <mailto: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>> <mailto: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>>
> > <mailto: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>>
> > <mailto: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>>
> <mailto: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>>
> > <mailto: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>
> <mailto:devel at rtems.org <mailto:devel at rtems.org>>
> > > http://lists.rtems.org/mailman/listinfo/devel
> > >
> >
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
--
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
PGP: Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel
mailing list