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