Trouble with addr_abort exception on arm/imx7 BSP with simple RTEMS code
Christian Mauderer
oss at c-mauderer.de
Thu Feb 18 20:52:34 UTC 2021
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/
>
More information about the users
mailing list