GSoC PRU: AM35xx Clock driver
Christian Mauderer
list at c-mauderer.de
Sun Jul 28 09:34:17 UTC 2019
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
> >
>
More information about the devel
mailing list