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