<div>Hi Christian,</div><div>thanks a lot, changing the timer node path to /soc/timer in the bspstart.c did the trick! Finally I have a (basic) working build setup.</div><div>Yes, I am running the RTEMS 5.1 release. And that's odd, because I definitely always built it like you described (--with-rtems-smp), but the ./waf configure output always showed me, that SMP was not enabled. But now I rebuilt my complete toolchain and it works.</div><div>Now I can finally go on and actually work on a SMP application.</div><br><div>Kind regards,</div><div>Stefan</div><div> </div><br><div class="gmail_quote_attribution">On Feb 19 2021, at 9:53 pm, Christian Mauderer <oss@c-mauderer.de> wrote:</div><blockquote><div><div>Hello Stefan,</div><br><div>On 19/02/2021 21:29, Stefan Akatyschew wrote:</div><div>> Yeah, there was no timer entry in the FDT, hence I created it (only</div><div>> filled with clock-frequency) manually. I forgot to attach the fdt list</div><div>> output before my changes in my last mail:</div><br><div>No timer entry doesn't sound right. Normally the timer entry should</div><div>exist like here:</div><br><div>https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx7s.dtsi#n152</div><br><div>It seems that phytec decided to move it to soc/timer at least in some FDTs:</div><br><div>https://stash.phytec.com/projects/PUB/repos/linux-phytec-fsl/browse/arch/arm/boot/dts/imx7s.dtsi?at=BSP-Yocto-FSL-iMX7-PD18.2.0#366</div><br><div>If that is the case for you, you might have to create a patch for</div><div>bsps/arm/imx/start/bspstart.c. Basically you would have to change the</div><div>search for the timer node from:</div><br><div>````</div><div>node = fdt_path_offset(fdt, "/timer");</div><div>````</div><br><div>to</div><br><div>````</div><div>node = fdt_path_offset(fdt, "/timer");</div><div>if (node < 0) {</div><div>node = fdt_path_offset(fdt, "/soc/timer");</div><div>}</div><div>````</div><br><div>or alternatively search for a "compatible" node.</div><br><div>></div><div>> Regarding WAF and SMP: I can't follow unfortunately, I only ran "./waf</div><div>> configure --rtems=..." and saw the missing SMP output there.</div><br><div>Sorry, I might have asked that already: Which version of RTEMS do you use?</div><br><div>If it is the 5 release, you should have a something like like</div><br><div>./configure --target=arm-rtems5 \</div><div>--prefix=${PREFIX} \</div><div>--enable-posix \</div><div>--enable-rtemsbsp=imx \</div><div>--disable-networking \</div><div>--with-rtems-smp</div><div>make</div><br><div>or similar to build your BSP. For the current master with the waf based</div><div>build system, you will have calls like</div><br><div>./waf bsp_defaults --rtems-bsps=arm/imx > config.ini</div><div># edit config.ini to fit your needs - for example ENABLE_RTEMS_SMP</div><div>./waf configure --prefix=${PREFIX}</div><div>./waf</div><br><div>Best regards</div><br><div>Christian</div><br><div>></div><div>> Kind regards,</div><div>> Stefan</div><div>> On Feb 18 2021, at 9:52 pm, Christian Mauderer <oss@c-mauderer.de> wrote:</div><div>></div><div>> On 18/02/2021 21:03, Stefan Akatyschew wrote:</div><div>> > Hello Christian,</div><div>> > I'm very grateful for the script, it seems to work with the load</div><div>> adress</div><div>> > 0x80800000 and I don't get the previously described error. Thank you!</div><div>> > Unfortunately though I got the Fatal error 3072, as described here:</div><div>> > https://www.mail-archive.com/users@rtems.org/msg02837.html</div><div>> > <https://www.mail-archive.com/users@rtems.org/msg02837.html></div><div>> > But could "resolve" that, by setting up /timer/clock-frequency in</div><div>> the ftd:</div><div>> >   run loadfdt</div><div>> >   run loadimage</div><div>> >   fdt addr 0x83000000</div><div>> >   fdt resize</div><div>> >   fdt mknode / timer</div><div>> >   fdt set /time clock-frequency <0x007a1200></div><div>> >   bootz ${​​​​loadaddr}​​​​ - ${​​​​fdt_addr}​​​​</div><div>></div><div>> That's odd. Normally U-Boot should already add that. Only barebox didn't</div><div>> seem to add it on the i.MX6UL/ULL. But barebox also didn't initialize</div><div>> the timer. So if the clock-frequency is missing, you might need a bit</div><div>> more than just adding the field. It is possible that U-Boot then also</div><div>> doesn't call the timer_init:</div><div>></div><div>> https://gitlab.denx.de/u-boot/u-boot/-/blob/2dddc1bb296308/arch/arm/mach-imx/syscounter.c#L63</div><div>></div><div>> Maybe only certain U-Boots did call that and add the clock-frequency? I</div><div>> can't say fur sure which version has been used on the i.mx7 boards that</div><div>> have been used for the original BSP development.</div><div>></div><div>> Maybe you want to try the patch that I added for initializing the system</div><div>> counter on i.MX6ULL:</div><div>></div><div>> https://git.rtems.org/rtems/commit/bsps/arm/imx/start/bspstart.c?id=7b99d7619ec3ff1143db003a541505367f8004d5</div><div>></div><div>> It should work on an i.MX7 too if the counter hasn't been initialized.</div><div>></div><div>> > I just chose the value for the clock-frequency out of the fdt</div><div>> > /clock-osc/clock-frequency. Not sure if that is the correct value, I</div><div>> > also tried some others, but I always get the error code 263</div><div>> > (BSP_ARM_FATAL_GENERIC_TIMER_CLOCK_IRQ_INSTALL) . (I fiddled it</div><div>> > together, so please correct if I did any mistakes)</div><div>> > That also seems to fit the description of JunBeom, but I couldn't</div><div>> follow</div><div>> > with Step 2. Do I have to just get the current u-boot sources,</div><div>> make the</div><div>> > change and normally build it? I used the imx7 u-boot image</div><div>> provided by</div><div>> > PHYTEC and am not sure if there are necessary custom changes for the</div><div>> > imx7 Board or the fdt information is needed to be provided. I looked</div><div>> > quiet a while on the internet, but couldn't find much guidance on</div><div>> that</div><div>> > process. Can someone please give me pointers on how to proceed</div><div>> from here?</div><div>></div><div>> I think the problem in that thread has been that U-Boot for some reason</div><div>> started in a different mode. But note that JunBeom didn't get an</div><div>> interrupt. He didn't have a problem installing the interrupt handler.</div><div>></div><div>> Installing the interrupt handler can fail for different reasons. The</div><div>> most likely one in this case is that the entry for the interrupt is also</div><div>> missing in the FDT.</div><div>></div><div>> How does the timer entry of your FDT look like? Is there even an timer</div><div>> entry?</div><div>></div><div>> ></div><div>> > Regarding the SMP flag, I found it here on the quick-start guide:</div><div>> ></div><div>> https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/user/start/bsp-build.html</div><div>> ></div><div>> <https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/user/start/bsp-build.html></div><div>></div><div>> Ah, sorry. I missed that you are using the 5 release and not the latest</div><div>> master. In that case I assume the waf call has been for libbsd, right?</div><div>></div><div>> Best regards</div><div>></div><div>> Christian</div><div>></div><div>> ></div><div>> > Thanks again for the great help so far!</div><div>> > Kind regards,</div><div>> > Stefan</div><div>> > On Feb 8 2021, at 8:41 am, Christian MAUDERER</div><div>> > <christian.mauderer@embedded-brains.de> wrote:</div><div>> ></div><div>> > Hello Stefan,</div><div>> ></div><div>> > Am 07.02.21 um 20:35 schrieb Christian Mauderer:</div><div>> > > Hello Stefan,</div><div>> > ></div><div>> > > On 07/02/2021 19:31, Stefan Akatyschew wrote:</div><div>> > >> Hey Christian,</div><div>> > >> no problem, thanks a lot for your reply!</div><div>> > >> Here it starts, right after loading the elf file:</div><div>> > >> Just to be sure there is no mistake in my setup, I attached the</div><div>> > >> complete listing shown (start.S), as well as my .cmm script to</div><div>> load</div><div>> > >> the binary.</div><div>> > ></div><div>> > > That looks like there is a bug in the setup of your debugger.</div><div>> > ></div><div>> > > The i.MX7 BSP normally runs out of SDRAM. It expects to be</div><div>> > started by a</div><div>> > > U-Boot on the i.MX7. If I understand your trace script</div><div>> correctly, it</div><div>> > > resets the board, then it loads the application. This will try</div><div>> to put</div><div>> > > the application into a SDRAM that is not yet initialized. It's a</div><div>> > bit odd</div><div>> > > that Trace32 doesn't throw an error when you try to access the</div><div>> > code there.</div><div>> > ></div><div>> > > For boards with a boot loader (like U-Boot) I most of the time</div><div>> > use the</div><div>> > > following approach:</div><div>> > ></div><div>> > > - Make sure that there is an application that can be loaded by</div><div>> > the boot</div><div>> > > loader (Linux Kernel, RTEMS application, ...)</div><div>> > > - If the BSP needs an FDT (i.MX does need one): Make sure that</div><div>> one is</div><div>> > > loaded too.</div><div>> > ></div><div>> > > In the debug script:</div><div>> > ></div><div>> > > - Reset and halt the board</div><div>> > > - Set a breakpoint at the location where the Kernel would start</div><div>> > (in that</div><div>> > > case 0x80200000; for Linux maybe 0x80000000 - check the U-Boot</div><div>> output</div><div>> > > for that)</div><div>> > > - Start the board and let it run till the breakpoint. This will</div><div>> > execute</div><div>> > > the boot loader and let it do all the basic setup.</div><div>> > > - Load the application for debugging.</div><div>> > > - Let the CPU run.</div><div>> > ></div><div>> > > I can take a look whether I have some debug script for an i.MX7</div><div>> on my</div><div>> > > work PC tomorrow.</div><div>> ></div><div>> > A simplified version of the script that I would try:</div><div>> ></div><div>> > ~~~~~~~~</div><div>> > &APPLICATION_FILE="path/to/app.exe"</div><div>> ></div><div>> > global &initialized</div><div>> ></div><div>> > if "&initialized"==""</div><div>> > (</div><div>> > &initialized="1"</div><div>> ></div><div>> > RESet</div><div>> > SYStem.RESet</div><div>> > SYStem.CPU IMX7DUAL-CA7</div><div>> > SYStem.Option ResBreak OFF</div><div>> > SYStem.Option WaitReset 30.0ms</div><div>> > SYStem.JtagClock CTCK 10MHz</div><div>> > CORE.ASSIGN 1.</div><div>> > )</div><div>> ></div><div>> > break.IMPLEMENTATION PROGRAM ONCHIP</div><div>> > sys.mode down</div><div>> > sys.mode up</div><div>> > go.direct</div><div>> > wait 1s</div><div>> > Break.direct</div><div>> > go 0x80004000 ; You most likely have to adapt that based on what</div><div>> > ; your U-Boot currently loads.</div><div>> > wait !run()</div><div>> ></div><div>> > data.load "&APPLICATION_FILE"</div><div>> > break.set _Terminate</div><div>> ></div><div>> > enddo</div><div>> > ~~~~~~~~</div><div>> ></div><div>> > Best regards</div><div>> ></div><div>> > Christian</div><div>> ></div><div>> > ></div><div>> > >></div><div>> > >> Another question, I wonder why when I run waf configure, it</div><div>> tells me</div><div>> > >> "Checking for RTEMS_SMP                      : no", when I</div><div>> built my</div><div>> > >> BSP with the option "--with-rtems-smp"?</div><div>> > ></div><div>> > > --with-rtems-smp was for the old make based build system. For</div><div>> the waf</div><div>> > > based one I think you have to set RTEMS_SMP = True in the</div><div>> config.ini.</div><div>> > ></div><div>> > > Where did you find the --with-rtems-smp switch? It's quite</div><div>> > possible that</div><div>> > > there is a  there a bug in the documentation?</div><div>> > ></div><div>> > >> On this occasion also, in case you missed it, the ssl</div><div>> > certificate for</div><div>> > >> ftp.rtems.org expired a few days ago.</div><div>> > ></div><div>> > > I forwarded the information to our internal list. There has</div><div>> been just</div><div>> > > recently a certificate update for devel.rtems.org. Most likely the</div><div>> > > ftp.rtems.org has been missed.</div><div>> > ></div><div>> > > Best regards</div><div>> > ></div><div>> > > Christian</div><div>> > ></div><div>> > >></div><div>> > >> Kind regards,</div><div>> > >> Stefan</div><div>> > >></div><div>> > >> On Feb 6 2021, at 12:38 pm, Christian Mauderer</div><div>> > <oss@c-mauderer.de> wrote:</div><div>> > >></div><div>> > >>     Hello Stefan,</div><div>> > >></div><div>> > >>     sorry for not answering earlier. I somehow missed the mail.</div><div>> > >></div><div>> > >>     On 02/02/2021 18:02, Stefan Akatyschew wrote:</div><div>> > >>      > Hey together!</div><div>> > >>      ></div><div>> > >>      > I'm new to RTEMS and just hit some errors, I just can't</div><div>> > figure</div><div>> > >> out.</div><div>> > >>      > Since I will probably lure around a bit longer, I wanted</div><div>> > to give</div><div>> > >>     short</div><div>> > >>      > introduction, so you can estimate what to expect from me:</div><div>> > I'm a</div><div>> > >>      > nearly-finished(tm) EE undergrad from Germany, not</div><div>> having any</div><div>> > >>     hands-on</div><div>> > >>      > experience on RTOS, my embedded knowledge is confined</div><div>> to some</div><div>> > >> hobby</div><div>> > >>      > STM32/PIC projects and the usual microcontroller stuff they</div><div>> > >> teach at</div><div>> > >>      > uni. Not a great starting point for something as</div><div>> advanced as</div><div>> > >>     RTEMS, I'm</div><div>> > >>      > aware, but I'm eager to learn it. Besides embedded stuff</div><div>> > I'm also</div><div>> > >>     into</div><div>> > >>      > the RF electronics :)</div><div>> > >></div><div>> > >>     It's not a too bad starting point either. It's quite</div><div>> similar to</div><div>> > >> the one</div><div>> > >>     I had when I had my first contact with RTEMS.</div><div>> > >></div><div>> > >>      > Goal of my engagement with RTEMS: Setting up a small</div><div>> SMP Demo</div><div>> > >>      > Application on the Phytec Zeta i.MX7d Board</div><div>> > >>      ></div><div>> > >></div><div>> > https://www.phytec.eu/product-eu/single-board-computer/phyboard-zeta/</div><div>> > >>      > for a university project, though after getting to know</div><div>> > RTEMS, I</div><div>> > >>     hope to</div><div>> > >>      > be able to stick around after that, the applications in</div><div>> > >>     (aero)space, are</div><div>> > >>      > exactly what I'm passionate about! Also I hope after I</div><div>> > get to run</div><div>> > >>      > everything, I can compile and publish my</div><div>> > >> documentation/experience to</div><div>> > >>      > help others with the i.MX 7, since the road has been</div><div>> > rather rocky</div><div>> > >>     for me</div><div>> > >>      > now.</div><div>> > >>      ></div><div>> > >></div><div>> > >>     I hope I didn't add too much stones to the road. I worked</div><div>> > quite a</div><div>> > >> bit on</div><div>> > >>     the imx BSP when I added i.MX 6 and some of the changes</div><div>> > haven't been</div><div>> > >>     extensively tested on i.MX 7.</div><div>> > >></div><div>> > >>      ></div><div>> > >>      > So to my actual problem: I have the before mentioned</div><div>> i.MX 7d</div><div>> > >>     Board and a</div><div>> > >>      > Lauterbach Power Debug Interface with trace32, to directly</div><div>> > >> flash my</div><div>> > >>      > binaries onto the SRAM. I'm using their i.MX7d SABRE</div><div>> > >>     configuration file,</div><div>> > >>      > which successfully worked with their sample binary and</div><div>> > slightly</div><div>> > >>     modified</div><div>> > >>      > it (mainly deactivating ETF on-chip tracing).</div><div>> > >>      ></div><div>> > >>      > I've built the RTEMS 5 toolchain according to your</div><div>> > quick-start</div><div>> > >>     guide (</div><div>> > >>      ></div><div>> > https://docs.rtems.org/branches/master/user/start/index.html),</div><div>> > >>     with some</div><div>> > >>      > slight modifications arm/imx7 on my Ubuntu 18.04 VM</div><div>> > (kernel built</div><div>> > >>     from</div><div>> > >>      > sources, somehow didn't work otherwise). I also built the</div><div>> > >>     simplest demo</div><div>> > >>      > application from 2.7, which went without problems (well,</div><div>> > after</div><div>> > >> many</div><div>> > >>      > hours of troubleshooting stupid mistakes). Now after</div><div>> > flashing the</div><div>> > >>     binary</div><div>> > >>      > directly to the SRAM with my Lauterbach Debugger (without</div><div>> > RTEMS OS</div><div>> > >>      > Awareness yet), I end up in the exception routine</div><div>> > >>      > "_ARMV4_Exception_data_abort_default", with the following</div><div>> > >>      > call-tree-hierarchy:</div><div>> > >>      ></div><div>> > >></div><div>> > >>     Can you hit "Up" once and take a look at the code location</div><div>> > and send a</div><div>> > >>     screen shot. Best thing would be the mode that shows assembler</div><div>> > >>     istructions too. And maybe the window with the CPU registers.</div><div>> > >></div><div>> > >>     Best regards</div><div>> > >></div><div>> > >>     Christian</div><div>> > >></div><div>> > >>      > I also tried removing the printf (just letting it count an</div><div>> > >> integer up</div><div>> > >>      > and overflow), since I was confused why RTEMS would call a</div><div>> > >> uart_write</div><div>> > >>      > function otherwise, but that didn't change anything and</div><div>> > actually</div><div>> > >>     doesn't</div><div>> > >>      > even get to the Init rtems_task.</div><div>> > >>      ></div><div>> > >>      > I already looked on the internet, the documentation and the</div><div>> > >>     mailing-list</div><div>> > >>      > archive for help (not nearly finished reading through the</div><div>> > complete</div><div>> > >>      > Classic API Guide and User Manual, that'll take some time).</div><div>> > >>      > Unfortunately I'm also new to the Lauterbach Debugger,</div><div>> which</div><div>> > >>     seems to be</div><div>> > >>      > a beast of its own, so I unfortunately can't provide any</div><div>> > useful</div><div>> > >>     on-chip</div><div>> > >>      > trace data yet. I hope anyone can point me to the,</div><div>> > probably rather</div><div>> > >>      > obvious, mistake I'm making, any help is appreciated!</div><div>> > >>      ></div><div>> > >>      ></div><div>> > >>      > Last but not least, thanks for your awesome work on RTEMS!</div><div>> > >>      ></div><div>> > >>      > Kind regards,</div><div>> > >>      > Stefan</div><div>> > >>      ></div><div>> > >>      ></div><div>> > >>      > Attached some maybe useful outputs:</div><div>> > >>      ></div><div>> > >>      > stefan@rtems-vm:~$ arm-rtems5-gcc --version</div><div>> > >>      > arm-rtems5-gcc (GCC) 7.5.0 20191114 (RTEMS 5, RSB 5.1,</div><div>> Newlib</div><div>> > >>     7947581)</div><div>> > >>      ></div><div>> > >>      > ./waf configure --rtems=$HOME/rtems/5 --rtems-bsp=arm/imx7</div><div>> > >>      > Setting top to                           :</div><div>> > >>      > /home/stefan/VCS/rtems-bp/first-test</div><div>> > >>      > Setting out to                           :</div><div>> > >>      > /home/stefan/VCS/rtems-bp/first-test/build</div><div>> > >>      > RTEMS Version                            : 5</div><div>> > >>      > Architectures                            : arm-rtems5</div><div>> > >>      > Board Support Package (BSP)              : arm-rtems5-imx7</div><div>> > >>      > Show commands                            : no</div><div>> > >>      > Long commands                            : no</div><div>> > >>      > Checking for program 'arm-rtems5-gcc'    :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-gcc</div><div>> > >>      > Checking for program 'arm-rtems5-g++'    :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-g++</div><div>> > >>      > Checking for program 'arm-rtems5-gcc'    :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-gcc</div><div>> > >>      > Checking for program 'arm-rtems5-ld'     :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-ld</div><div>> > >>      > Checking for program 'arm-rtems5-ar'     :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-ar</div><div>> > >>      > Checking for program 'arm-rtems5-nm'     :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-nm</div><div>> > >>      > Checking for program 'arm-rtems5-objdump' :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-objdump</div><div>> > >>      > Checking for program 'arm-rtems5-objcopy' :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-objcopy</div><div>> > >>      > Checking for program 'arm-rtems5-readelf' :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-readelf</div><div>> > >>      > Checking for program 'arm-rtems5-strip'   :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-strip</div><div>> > >>      > Checking for program 'arm-rtems5-ranlib'  :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-ranlib</div><div>> > >>      > Checking for program 'rtems-ld'           :</div><div>> > >>      > /home/stefan/rtems/5/bin/rtems-ld</div><div>> > >>      > Checking for program 'rtems-tld'          :</div><div>> > >>      > /home/stefan/rtems/5/bin/rtems-tld</div><div>> > >>      > Checking for program 'rtems-syms'         :</div><div>> > >>      > /home/stefan/rtems/5/bin/rtems-syms</div><div>> > >>      > Checking for program 'rtems-bin2c'        :</div><div>> > >>      > /home/stefan/rtems/5/bin/rtems-bin2c</div><div>> > >>      > Checking for program 'tar'                : /bin/tar</div><div>> > >>      > Checking for program 'gcc, cc'            :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-gcc</div><div>> > >>      > Checking for program 'ar'                 :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-ar</div><div>> > >>      > Checking for program 'g++, c++'           :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-g++</div><div>> > >>      > Checking for program 'ar'                 :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-ar</div><div>> > >>      > Checking for program 'gas, gcc'           :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-gcc</div><div>> > >>      > Checking for program 'ar'                 :</div><div>> > >>      > /home/stefan/rtems/5/bin/arm-rtems5-ar</div><div>> > >>      > Checking for c flags '-MMD'               : yes</div><div>> > >>      > Checking for cxx flags '-MMD'             : yes</div><div>> > >>      > Compiler version (arm-rtems5-gcc)         : 7.5.0</div><div>> > 20191114 (RTEMS</div><div>> > >>     5, RSB</div><div>> > >>      > 5.1, Newlib 7947581)</div><div>> > >>      > Checking for a valid RTEMS BSP installation : yes</div><div>> > >>      > Checking for RTEMS_DEBUG                    : no</div><div>> > >>      > Checking for RTEMS_MULTIPROCESSING          : no</div><div>> > >>      > Checking for RTEMS_NEWLIB                   : yes</div><div>> > >>      > Checking for RTEMS_POSIX_API                : yes</div><div>> > >>      > Checking for RTEMS_SMP                      : no</div><div>> > >>      > Checking for RTEMS_NETWORKING               : yes</div><div>> > >>      > 'configure' finished successfully (1.056s)</div><div>> > >>      ></div><div>> > >>      ></div><div>> > >>      > _______________________________________________</div><div>> > >>      > users mailing list</div><div>> > >>      > users@rtems.org</div><div>> > >>      > http://lists.rtems.org/mailman/listinfo/users</div><div>> > >>      ></div><div>> > >></div><div>> ></div><div>> > --</div><div>> > --------------------------------------------</div><div>> > embedded brains GmbH</div><div>> > Herr Christian MAUDERER</div><div>> > Dornierstr. 4</div><div>> > 82178 Puchheim</div><div>> > Germany</div><div>> > email: christian.mauderer@embedded-brains.de</div><div>> > phone: +49-89-18 94 741 - 18</div><div>> > fax: +49-89-18 94 741 - 08</div><div>> ></div><div>> > Registergericht: Amtsgericht München</div><div>> > Registernummer: HRB 157899</div><div>> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas</div><div>> Dörfler</div><div>> > Unsere Datenschutzerklärung finden Sie hier:</div><div>> > https://embedded-brains.de/datenschutzerklaerung/</div><div>> ></div><div>></div></div></blockquote>