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