Trouble with addr_abort exception on arm/imx7 BSP with simple RTEMS code
Christian MAUDERER
christian.mauderer at embedded-brains.de
Mon Feb 8 07:41:28 UTC 2021
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