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

Mon Feb 22 06:28:41 UTC 2021

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20210222/67839853/attachment-0001.html>