GSoC PRU: AM35xx Clock driver
Nils Hölscher
nilhoel1 at gmail.com
Fri Aug 9 18:07:33 UTC 2019
Hi Christian,
I want to thank you again, since you actually helped me a lot with this
problem.
But I already patched this problem, didn't I.
Thanks,
Nils
Christian Mauderer <list at c-mauderer.de> schrieb am Fr., 9. Aug. 2019, 19:50:
> Hello Nils,
>
> great that you found your problem. It sounds like it is a general bug in
> libbsd. What did you change and do you have a patch that would fix this?
>
> Best regards
>
> Christian
>
> On 09/08/2019 15:42, Nils Hölscher wrote:
> > Hi,
> >
> > I was able to resolve the problem.
> > The reason that all the devices attached in the last pass and not in the
> > pass they were assigned, was the nexus bus being loaded as a standard
> > driver Module.
> > So the pass level of nexus bus was BUS_PASS_DEFAULT and all devices
> > depend on nexus bus.
> > Please see my Output attached.
> > The prints print the linkpass list and the link list and some other
> parts.
> >
> > At the bottom you can also see the pruss device in /dev.
> >
> > I will create a patch right away.
> >
> > Best,
> > Nils
> >
> > On Wed, 7 Aug 2019 at 11:35, Nils Hölscher <nilhoel1 at gmail.com
> > <mailto:nilhoel1 at gmail.com>> wrote:
> >
> > Hi,
> >
> > I was able to confirm that the current libBSD implementation scans
> > the fdt only once.
> > caller:
> https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L5100
> > callee:
> https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L969
> > The function BUS_NEW_PASS initialises a pass over fdt with all
> > drivers of the current pass level.
> >
> > However after trying to add another pass, I realized that all
> > drivers are on the DEFAULT_PASS_LEVEL (max_integer).
> >
> > Best and thanks,
> > Nils
> >
> > On Thu, 1 Aug 2019 at 11:36, Christian Mauderer
> > <christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>> wrote:
> >
> > 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>
> > > <mailto: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>>
> > > > <mailto: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>>
> > > > <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>>>
> > > > <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
> > <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>>>
> > > > > <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 <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>>>
> > <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
> > <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>>>
> > > > <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 <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>>>
> > > > <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 <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>>>
> > > <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
> > <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>>>
> > > > <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 <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>>
> > > <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>
> > > 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
> > <mailto: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.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190809/420ae211/attachment-0002.html>
More information about the devel
mailing list