<div>Hello Christian,</div><div>I'm very grateful for the script, it seems to work with the load adress 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: <a href="https://www.mail-archive.com/users@rtems.org/msg02837.html" title="https://www.mail-archive.com/users@rtems.org/msg02837.html">https://www.mail-archive.com/users@rtems.org/msg02837.html</a><br>But could "resolve" that, by setting up /timer/clock-frequency in the ftd<span data-emoji-typing="true">:</span></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>I just chose the value for the clock-frequency out of the fdt /clock-osc/clock-frequency. Not sure if that is the correct value, I also tried some others, but I always get the error code 263 (BSP_ARM_FATAL_GENERIC_TIMER_CLOCK_IRQ_INSTALL) . (I fiddled it together, so please correct if I did any mistakes)</div><div><img alt="" src="cid:mcid-3ab9ae9d-6d84"></div><div>That also seems to fit the description of JunBeom, but I couldn't follow with Step 2. Do I have to just get the current u-boot sources, make the change and normally build it? I used the imx7 u-boot image provided by PHYTEC and am not sure if there are necessary custom changes for the imx7 Board or the fdt information is needed to be provided. I looked quiet a while on the internet, but couldn't find much guidance on that process. Can someone please give me pointers on how to proceed from here?</div><br><div>Regarding the SMP flag, I found it here on the quick-start guide: <a href="https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/user/start/bsp-build.html" title="https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/user/start/bsp-build.html">https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/user/start/bsp-build.html</a></div><br><div>Thanks again for the great help so far!</div><div>Kind regards,</div><div>Stefan</div><div class="gmail_quote_attribution">On Feb 8 2021, at 8:41 am, Christian MAUDERER <christian.mauderer@embedded-brains.de> wrote:</div><blockquote><div><div>Hello Stefan,</div><br><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 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 started by a</div><div>> U-Boot on the i.MX7. If I understand your trace script correctly, it</div><div>> resets the board, then it loads the application. This will try to put</div><div>> the application into a SDRAM that is not yet initialized. It's a bit odd</div><div>> that Trace32 doesn't throw an error when you try to access the code there.</div><div>></div><div>> For boards with a boot loader (like U-Boot) I most of the time use the</div><div>> following approach:</div><div>></div><div>> - Make sure that there is an application that can be loaded by 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 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 (in that</div><div>> case 0x80200000; for Linux maybe 0x80000000 - check the U-Boot output</div><div>> for that)</div><div>> - Start the board and let it run till the breakpoint. This will 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 on my</div><div>> work PC tomorrow.</div><br><div>A simplified version of the script that I would try:</div><br><div>~~~~~~~~</div><div>&APPLICATION_FILE="path/to/app.exe"</div><br><div>global &initialized</div><br><div>if "&initialized"==""</div><div>(</div><div>&initialized="1"</div><br><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><br><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><br><div>data.load "&APPLICATION_FILE"</div><div>break.set _Terminate</div><br><div>enddo</div><div>~~~~~~~~</div><br><div>Best regards</div><br><div>Christian</div><br><div>></div><div>>></div><div>>> Another question, I wonder why when I run waf configure, it tells me</div><div>>> "Checking for RTEMS_SMP                      : no", when I 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 the waf</div><div>> based one I think you have to set RTEMS_SMP = True in the config.ini.</div><div>></div><div>> Where did you find the --with-rtems-smp switch? It's quite 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 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 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 <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 figure</div><div>>> out.</div><div>>>      > Since I will probably lure around a bit longer, I wanted to give</div><div>>>     short</div><div>>>      > introduction, so you can estimate what to expect from me: I'm a</div><div>>>      > nearly-finished(tm) EE undergrad from Germany, not having any</div><div>>>     hands-on</div><div>>>      > experience on RTOS, my embedded knowledge is confined 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 advanced as</div><div>>>     RTEMS, I'm</div><div>>>      > aware, but I'm eager to learn it. Besides embedded stuff 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 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 SMP Demo</div><div>>>      > Application on the Phytec Zeta i.MX7d Board</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 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 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 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 quite a</div><div>>> bit on</div><div>>>     the imx BSP when I added i.MX 6 and some of the changes 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 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 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 quick-start</div><div>>>     guide (</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 (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, after</div><div>>> many</div><div>>>      > hours of troubleshooting stupid mistakes). Now after flashing the</div><div>>>     binary</div><div>>>      > directly to the SRAM with my Lauterbach Debugger (without 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 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 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 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, which</div><div>>>     seems to be</div><div>>>      > a beast of its own, so I unfortunately can't provide any useful</div><div>>>     on-chip</div><div>>>      > trace data yet. I hope anyone can point me to the, 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, 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 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><br><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><br><div>Registergericht: Amtsgericht München</div><div>Registernummer: HRB 157899</div><div>Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler</div><div>Unsere Datenschutzerklärung finden Sie hier:</div><div>https://embedded-brains.de/datenschutzerklaerung/</div></div></blockquote>