<div dir="ltr">Hi,<br><div><br></div><div>I was able to confirm that the current libBSD implementation scans the fdt only once.</div><div>caller: <a href="https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L5100">https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L5100</a></div><div>callee: <a href="https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L969">https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L969</a></div><div>The function BUS_NEW_PASS initialises a pass over fdt with all drivers of the current pass level.</div><div><br></div><div>However after trying to add another pass, I realized that all drivers are on the DEFAULT_PASS_LEVEL (max_integer).</div><div><br></div><div>Best and thanks,</div><div>Nils</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 1 Aug 2019 at 11:36, Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.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">Hello Nils,<br>
<br>
On 31/07/2019 14:54, Nils Hölscher wrote:<br>
> Hi,<br>
> <br>
> I have been reading into the FreeBSD init code the past few days,<br>
> especially for Driver_MODULE.<br>
> Expect an Blog entry today or tomorrow.<br>
> <br>
> Because I don't have JTAG, it took me quite some time.<br>
<br>
I would always suggest a JTAG or some other kind of debugger for<br>
embedded work. In a professional work environment you should try to<br>
convince your boss that it is a big time saver (which is definitively<br>
true) so that even an expensive debugger is a good investment<br>
<br>
By the way: For understanding the initialization sequence you might can<br>
use a simulator too. For the basic sequence you can simulate any BSP and<br>
are not bound to BBB.<br>
<br>
> With BUS_DEBUG enabled I saw that the problem is indeed that the pruss<br>
> unit is discovered too early.<br>
> Is this device tree related?<br>
<br>
It's possible that this is a difference in how modules are handled. I'm<br>
not sure whether FreeBSD loads EARLY_MODULES dynamically at another time<br>
during boot while we link everything in from the start. If that is true,<br>
the mechanism might not work the same like in FreeBSD. You might want to<br>
have a look at that.<br>
<br>
> <br>
> I am not sure, cause the overlay I am using is from the BSD community.<br>
> <br>
> I added my output to a gist and link to the interesting parts.<br>
> The EARLY_DRIVER_MODULE's are indeed loaded first.<br>
> <a href="https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L125" rel="noreferrer" target="_blank">https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L125</a><br>
> Nexus bus attaches and the driver goes over every discovered device and<br>
> tries to attach the drivers in order:<br>
> <a href="https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L326" rel="noreferrer" target="_blank">https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L326</a><br>
> ofwbus gets discovered:<br>
> <a href="https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L747" rel="noreferrer" target="_blank">https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L747</a><br>
> Here the ti_pruss device gets discovered too early in the fdt and fails:<br>
> <a href="https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L904" rel="noreferrer" target="_blank">https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L904</a><br>
> <br>
> I still haven't found the loop running over fdt.<br>
<br>
Don't have a test environment ready so this is just from a quick glance<br>
at the code. I might have missed something:<br>
<br>
simplebus_attach adds all child nodes from the tree to the bus:<br>
<br>
<a href="https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/dev/fdt/simplebus.c#n157" rel="noreferrer" target="_blank">https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/dev/fdt/simplebus.c#n157</a><br>
<br>
The bus_generic_attach then loops over all children and calls their<br>
probe and attach functions:<br>
<br>
<a href="https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/kern/subr_bus.c#n3768" rel="noreferrer" target="_blank">https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/kern/subr_bus.c#n3768</a><br>
<br>
Best regards<br>
<br>
Christian<br>
<br>
> And it seems that the device tree only gets one iteration.<br>
> But the BSD man page for EARLY_DRIVER_MODULE states that every<br>
> PASS_LEVEL has an iteration.<br>
> " <br>
> <br>
> The *EARLY*_*DRIVER*_*MODULE*() macro allows a driver to be registered for a<br>
> specific pass level. The boot time probe and attach process makes *_multi- _ _ple passes over the device tree_*. Certain critical drivers that provide<br>
> basic services needed by other devices are attach during earlier passes.<br>
> Most drivers are attached in a final general pass. A driver that<br>
> attaches during an early pass must register for a specific pass level<br>
> (BUS_PASS_*) via the /pass/ argument. Once a driver is registered it is<br>
> available to attach to devices for all subsequent passes."<br>
> <br>
> <a href="https://www.freebsd.org/cgi/man.cgi?query=DRIVER_MODULE&sektion=9&apropos=0&manpath=FreeBSD+12.0-RELEASE+and+Ports" rel="noreferrer" target="_blank">https://www.freebsd.org/cgi/man.cgi?query=DRIVER_MODULE&sektion=9&apropos=0&manpath=FreeBSD+12.0-RELEASE+and+Ports</a><br>
> <br>
> Best,<br>
> Nils<br>
> <br>
> <br>
> On Sun, 28 Jul 2019 at 11: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 28/07/2019 11:22, Nils Hölscher wrote:<br>
> ><br>
> ><br>
> > On Sat, 27 Jul 2019 at 14:34, Christian Mauderer<br>
> <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<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> <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>><br>
> > <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<br>
> 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<br>
> 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<br>
> (non-libbsd)<br>
> > drivers enable their power and clocks themself. Please make<br>
> sure that<br>
> > the FreeBSD prcm doesn't interfere with that. Otherwise you<br>
> 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>
> > <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>
> <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>>><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> <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>><br>
> > <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>
> <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><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>>><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> <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<br>
> success one. <br>
> > ><br>
> > > if (ofw_bus_is_compatible(dev,<br>
> "ti,am3-prcm")) {<br>
> > > device_set_desc(dev, "AM335x Power<br>
> 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<br>
> 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<br>
> 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<br>
> the same<br>
> > > sources.<br>
> > ><br>
> > > Have you checked that your source is from the tree<br>
> matching the<br>
> > > libBSD HEAD<br>
> > > commit? <br>
> > ><br>
> > > reg = <0x00 0x2000>;<br>
> > > #address-cells = <0x01>;<br>
> > > #size-cells = <0x01>;<br>
> > > ranges = <0x00 0x00<br>
> 0x2000>;<br>
> > > phandle = <0x5a>;<br>
> > > [...]<br>
> > > "<br>
> > > Any ideas would help, cause I am currently<br>
> not able to<br>
> > > understand this behaviour.<br>
> > > Also without this driver even the<br>
> dev_usb_bbb driver<br>
> > > shouldn't work.<br>
> > > However it attaches because it doesn't check<br>
> 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<br>
> doesn't work<br>
> > > for you, I won't mind checking<br>
> > > again, this will give me a hint for the display<br>
> issue<br>
> > as well. <br>
> > ><br>
> > > I will keep you updated on this.<br>
> > > Would you be so kind and send me your compiled<br>
> device tree? <br>
> > ><br>
> > > Please find it attached in this mail. <br>
> > ><br>
> > > Note: I have removed the devel from the cc because the<br>
> 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><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>>><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> <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<br>
> 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>><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> <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>
> > > After debugging with printk, didn't<br>
> get the<br>
> > > module loading working as suggested by<br>
> > Sebastian.<br>
> > > I just found out that my PRU driver<br>
> can't be<br>
> > > attached, cause the AM35xx clock<br>
> driver isn't<br>
> > > loaded.<br>
> > > The driver can be found her:<br>
> > > <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<br>
> driver and<br>
> > > obisouly before I initialize my BSD<br>
> modules?<br>
> > ><br>
> > > FYI: The code line that fails is<br>
> this one,<br>
> > cause<br>
> > > the driver hasn't been initialized.<br>
> > > <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>
> > <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>
> <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>
> <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>
> <br>
> _______________________________________________<br>
> devel mailing list<br>
> <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>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
Phone: +49-89-18 94 741 - 18<br>
Fax: +49-89-18 94 741 - 08<br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</blockquote></div>