GSoC PRU: AM35xx Clock driver

Christian Mauderer list at c-mauderer.de
Fri Aug 9 17:50:22 UTC 2019


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.
> 



More information about the devel mailing list