Trouble with addr_abort exception on arm/imx7 BSP with simple RTEMS code

Christian MAUDERER christian.mauderer at embedded-brains.de
Mon Feb 22 07:37:48 UTC 2021


Hello Stefan,

Am 22.02.21 um 07:28 schrieb Stefan Akatyschew:
> Hi Christian,
> 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.

good to hear. Maybe you want to think about creating a patch if that 
worked for you?

Best regards

Christian

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

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/


More information about the users mailing list