<div>Yeah, there was no timer entry in the FDT, hence I created it (only filled with clock-frequency) manually. I forgot to attach the fdt list output before my changes in my last mail:</div><div><img alt="" src="cid:mcid-a61be025-dcb8"></div><br><div>Regarding WAF and SMP: I can't follow unfortunately, I only ran "./waf configure --rtems=..." and saw the missing SMP output there.</div><br><div>Kind regards,</div><div>Stefan</div><div class="gmail_quote_attribution">On Feb 18 2021, at 9:52 pm, Christian Mauderer <oss@c-mauderer.de> wrote:</div><blockquote><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 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 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><br><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><br><div>https://gitlab.denx.de/u-boot/u-boot/-/blob/2dddc1bb296308/arch/arm/mach-imx/syscounter.c#L63</div><br><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><br><div>Maybe you want to try the patch that I added for initializing the system</div><div>counter on i.MX6ULL:</div><br><div>https://git.rtems.org/rtems/commit/bsps/arm/imx/start/bspstart.c?id=7b99d7619ec3ff1143db003a541505367f8004d5</div><br><div>It should work on an i.MX7 too if the counter hasn't been initialized.</div><br><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 follow</div><div>> with Step 2. Do I have to just get the current u-boot sources, make the</div><div>> change and normally build it? I used the imx7 u-boot image 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 that</div><div>> process. Can someone please give me pointers on how to proceed from here?</div><br><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><br><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><br><div>How does the timer entry of your FDT look like? Is there even an timer</div><div>entry?</div><br><div>></div><div>> Regarding the SMP flag, I found it here on the quick-start guide:</div><div>> https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/user/start/bsp-build.html</div><div>> <https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/user/start/bsp-build.html></div><br><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><br><div>Best regards</div><br><div>Christian</div><br><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 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 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</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 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 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 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 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</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 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 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</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 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>> >></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 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, 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, 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 Dörfler</div><div>> Unsere Datenschutzerklärung finden Sie hier:</div><div>> https://embedded-brains.de/datenschutzerklaerung/</div><div>></div></div></blockquote>