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 <l...@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 <nilho...@gmail.com > > <mailto:nilho...@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.maude...@embedded-brains.de > > <mailto:christian.maude...@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 > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > > <mailto:l...@c-mauderer.de <mailto: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> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto: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> > > > <mailto:vijaykumar9...@gmail.com > > <mailto:vijaykumar9...@gmail.com>> > > > > <mailto:vijaykumar9...@gmail.com > > <mailto:vijaykumar9...@gmail.com> > > > <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>> > > > <mailto:vijaykumar9...@gmail.com > > <mailto:vijaykumar9...@gmail.com> > > <mailto:vijaykumar9...@gmail.com <mailto: > vijaykumar9...@gmail.com>>> > > > > <mailto:vijaykumar9...@gmail.com > > <mailto:vijaykumar9...@gmail.com> > > > <mailto:vijaykumar9...@gmail.com > > <mailto:vijaykumar9...@gmail.com>> > > <mailto: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>> > > > <mailto:nilho...@gmail.com <mailto:nilho...@gmail.com> > > <mailto:nilho...@gmail.com <mailto:nilho...@gmail.com>>> > > > > > <mailto:nilho...@gmail.com > > <mailto:nilho...@gmail.com> <mailto:nilho...@gmail.com > > <mailto:nilho...@gmail.com>> > > > <mailto: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>> > > > > <mailto:vijaykumar9...@gmail.com > > <mailto:vijaykumar9...@gmail.com> > > > <mailto:vijaykumar9...@gmail.com > > <mailto:vijaykumar9...@gmail.com>>> > > <mailto:vijaykumar9...@gmail.com <mailto: > vijaykumar9...@gmail.com> > > > <mailto:vijaykumar9...@gmail.com > > <mailto:vijaykumar9...@gmail.com>> > > > > <mailto: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>> > > > <mailto:nilho...@gmail.com <mailto:nilho...@gmail.com> > > <mailto:nilho...@gmail.com <mailto:nilho...@gmail.com>>> > > > > <mailto:nilho...@gmail.com > > <mailto:nilho...@gmail.com> <mailto:nilho...@gmail.com > > <mailto:nilho...@gmail.com>> > > > <mailto: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>> > > <mailto:nilho...@gmail.com <mailto:nilho...@gmail.com> > > > <mailto:nilho...@gmail.com <mailto:nilho...@gmail.com>>> > > > > <mailto:nilho...@gmail.com > > <mailto:nilho...@gmail.com> <mailto:nilho...@gmail.com > > <mailto:nilho...@gmail.com>> > > > <mailto: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>> > > > > <mailto:nilho...@gmail.com > > <mailto:nilho...@gmail.com> <mailto:nilho...@gmail.com > > <mailto:nilho...@gmail.com>>> > > > <mailto:nilho...@gmail.com <mailto:nilho...@gmail.com> > > <mailto:nilho...@gmail.com <mailto:nilho...@gmail.com>> > > > > <mailto: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>> > > > <mailto:devel@rtems.org <mailto:devel@rtems.org> > > <mailto:devel@rtems.org <mailto:devel@rtems.org>>> > > > > <mailto:devel@rtems.org <mailto:devel@rtems.org> > > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > > <mailto: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> > > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > > <mailto: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 > > > > > > > -- > > -------------------------------------------- > > embedded brains GmbH > > Herr Christian Mauderer > > Dornierstr. 4 > > D-82178 Puchheim > > Germany > > email: christian.maude...@embedded-brains.de > > <mailto:christian.maude...@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. > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
