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

Stefan Akatyschew stefan.aka at posteo.de
Thu Feb 18 20:03:26 UTC 2021


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
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}​​​​
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?

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
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/
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20210218/085b30cd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pasted File.png
Type: image/png
Size: 113405 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20210218/085b30cd/attachment-0001.png>


More information about the users mailing list