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 <l...@c-mauderer.de> wrote: > On 28/07/2019 11:22, Nils Hölscher wrote: > > > > > > On Sat, 27 Jul 2019 at 14:34, Christian Mauderer <l...@c-mauderer.de > > <mailto:l...@c-mauderer.de>> wrote: > > > > On 24/07/2019 16:53, Nils Hölscher wrote: > > > Hi, > > > > > > @Vijay Kumar Banerjee <mailto:vijaykumar9...@gmail.com > > <mailto:vijaykumar9...@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 > > > <vijaykumar9...@gmail.com <mailto:vijaykumar9...@gmail.com> > > <mailto:vijaykumar9...@gmail.com <mailto:vijaykumar9...@gmail.com>>> > > wrote: > > > > > > > > > > > > On Wed, Jul 24, 2019 at 7:03 PM Nils Hölscher > > <nilho...@gmail.com <mailto:nilho...@gmail.com> > > > <mailto:nilho...@gmail.com <mailto:nilho...@gmail.com>>> > wrote: > > > > > > > > > > > > On Wed, 24 Jul 2019 at 15:14, Vijay Kumar Banerjee > > > <vijaykumar9...@gmail.com > > <mailto:vijaykumar9...@gmail.com> <mailto:vijaykumar9...@gmail.com > > <mailto:vijaykumar9...@gmail.com>>> wrote: > > > > > > > > > > > > > > > On Wed, Jul 24, 2019 at 6:36 PM Nils Hölscher > > > <nilho...@gmail.com <mailto:nilho...@gmail.com> > > <mailto:nilho...@gmail.com <mailto:nilho...@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@0 { > > > compatible = > > > "ti,am3-prcm\0simple-bus"; > > > > > > In my device tree, it runs successfully and the > decompiled > > > compatible looks like : > > > ``` > > > prcm@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 > > > <nilho...@gmail.com <mailto:nilho...@gmail.com> > > <mailto:nilho...@gmail.com <mailto:nilho...@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 > > > <nilho...@gmail.com > > <mailto:nilho...@gmail.com> <mailto:nilho...@gmail.com > > <mailto:nilho...@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@rtems.org <mailto:devel@rtems.org> > > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > > http://lists.rtems.org/mailman/listinfo/devel > > > > > > > > > _______________________________________________ > > > devel mailing list > > > devel@rtems.org <mailto:devel@rtems.org> > > > http://lists.rtems.org/mailman/listinfo/devel > > > > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
