RTEMS Fatal Error on IMX7D SABRE Board.
JunBeom Kim (EmbedCoreTech)
jbkim at e-coretech.kr
Thu Jan 7 05:44:55 UTC 2021
Hello,
I resolved my problem according to two steps.
< Step 1. FATAL code (0x0200)>
As I checked from fata.h, this problem is from IMX_FATAL_GENERIC_TIMER_FREQUENCY.
Therefore, I added clock_frequency parameter in timer section of imx7s.dtsi.
< Step 2. Why clock interrupt is not occurred >
As I checked u-boot source code, timer_init() of arch/arm/mach-imx/syscounter.c is called.
When I checked counter value as calling arm_gt_clock_get_count(), timer is increased. But, timer interrupt is not occurred.
I found important information in below link.
https://developer.arm.com/documentation/ddi0464/d/Generic-Interrupt-Controller/GIC-functional-description/Interrupt-sources
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Secure Physical Timer event (PPI1)
This is the event generated from the Secure Physical Timer and uses ID29. The interrupt is level-sensitive.
Non-secure Physical Timer event (PPI2)
This is the event generated from the Non-secure Physical Timer and uses ID30. The interrupt is level-sensitive.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At this time, when I check u-boot booting message, current u-boot is booted as non-secure mode.
Therefore, I changed arm_gt_clock_early_init.irq value from 29 to 30 as temporary way.
Best Regards,
JunBeom
-----Original Message-----
From: Christian Mauderer <oss at c-mauderer.de>
Sent: Wednesday, January 6, 2021 10:17 PM
To: jameszxj <jameszxj at gmail.com>; JunBeom Kim (EmbedCoreTech) <jbkim at e-coretech.kr>; 'users' <users at rtems.org>
Subject: Re: RTEMS Fatal Error on IMX7D SABRE Board.
Hello,
On 06/01/2021 13:25, jameszxj wrote:
> Hi,
>
> > Hello,
> >
> > On 06/01/2021 10:04, jameszxj wrote:
> > > Hi,
> > >
> > > I can't find "timer" node in your devicetree.
> > > Function arm_generic_timer_get_config() in file bspstart.c will
> find > > node "/timer"
> > > and get "clock-frequency" value for system tick.
> >
> > note that at least the clock-frequency is added by U-Boot on the
> i.MX7 > during boot and is not in the typical device tree sources.
> >
> > On i.MX6UL/ULL there is still an ugly hack necessary:
> >
> >
> https://github.com/grisp/rtems/commit/02270d5ec82684007ae9973070a6f294
> 28be1543
> >
> > It's on my TODO-list to avoid that patch, but I haven't done that yet.
> >
>
> I add the timer_init in bsp, but the tick interrupt still seems pending.
> When I type something in shell, ticks will come.
Sounds like some low power mode. I would suggest to check the settings in the CCM. Check whether the system enters low power mode on a WFI instruction and disable that feature. Especially interesting would be the CCM_CLPCR.MASK_CORE0_WFI and similar bits. If these seem to be correct, I would check the CCGR* registers.
>
> > >
> > > ------------------ Original ------------------ > > *From:*
> "JunBeom Kim (EmbedCoreTech)" <jbkim at e-coretech.kr>; > > *Date:* Wed,
> Jan 6, 2021 04:46 PM > > *To:*
> "'jameszxj'"<jameszxj at gmail.com>;"'users'"<users at rtems.org>;
> > > *Subject:* RE: RTEMS Fatal Error on IMX7D SABRE Board.
> > >
> > > Dear James,
> > >
> > > As I know before, because this BSP is tested on Phytec’s
> PhyBOARD-i.MX7
> > > board, I am considering to purchase this board, too.
> >
> >
> > The last test on that board is some time back because I currently
> don't > have access to it (working from home). So also I would hope
> it, I > wouldn't guarantee that it runs out of the box.
> >
>
> thanks.
>
> >
> > >
> > > Best Regards,
> > >
> > > JunBeom
> > >
> > > *From:*JunBeom Kim (EmbedCoreTech) <jbkim at e-coretech.kr> > >
> *Sent:* Wednesday, January 6, 2021 5:39 PM > > *To:* 'jameszxj'
> <jameszxj at gmail.com>; 'users' <users at rtems.org> > > *Subject:* RE:
> RTEMS Fatal Error on IMX7D SABRE Board.
> > >
> > > Dear James,
> > >
> > > I used two files(imx7d-sdb.dts and imx7d.dtsi) for making
> imx7d-sdb.dtb.
> > >
> > > There is clock-frequency configuration in imx7d.dtsi.
> > >
> >
> >
> > Again: Normally U-Boot should add that clock-frequency.
> >
> >
> > > Best Regards,
> > >
> > > JunBeom
> > >
> > > *From:*users <users-bounces at rtems.org
> <mailto:users-bounces at rtems.org>> > > *On Behalf Of *jameszxj > >
> *Sent:* Wednesday, January 6, 2021 4:13 PM > > *To:* users
> <users at rtems.org <mailto:users at rtems.org>> > > *Subject:* Re:RTEMS
> Fatal Error on IMX7D SABRE Board.
> > >
> > > Hi,
> > > I use IMX7 bsp on my imx6ull board. I have encountered maybe the
> same > > problem. Please check your device-tree, BSP needs
> "clock-frequency" at > > node "timer".
> >
> > Do you use an i.MX6ULL with U-Boot or Barebox? They might have
> slightly > different behavior regarding the timer.
> >
>
> I use barebox.
OK. Barebox definitively doesn't initialize the timer. Odd thing is that I don't remember that it switches on a power save mode. But maybe something changed in a more recent version ...
Best regards
Christian
>
> > >
> > > But I encountered another problems, theARMv7-AR Generic Timercan
> not > > generate interrupt.
> > > imx7d has the same core with imx6ull，if your board run RTEMS > >
> successfully, please let me know, thanks.
> >
> > As you might have seen above, I'm using the BSP on i.MX6ULL based
> > boards. The board uses Phytec Phycore i.MX6UL/ULL modules (different
> > variants in different projects). One of the projects is an open
> source > one and you can find all sources at:
> >
> > https://github.com/grisp/grisp2-rtems-toolchain
> >
> > >
> > > ------------------ Original ------------------ > > > >
> *From:*"JunBeom Kim (EmbedCoreTech)" <jbkim at e-coretech.kr > >
> <mailto:jbkim at e-coretech.kr>>; > > > > *Date:*Wed, Jan 6, 2021 01:05
> PM > > > > *To:*"users"<users at rtems.org <mailto:users at rtems.org>>;
> > > > > *Subject:*RTEMS Fatal Error on IMX7D SABRE Board.
> > >
> > > Hello,
> > >
> > > After I purchased i.MX7D SABRE board, I am trying to test RTEMS
> kernel using > > lastest RTEMS kernel and source builder for RTEMS
> 6.0 > > > > As I knew before, RTEMS BSP for i.MX7D was not tested
> for i.MX7D SABRE > > board.
> > >
> > > When I tested this, my testing result is in below; > > <REMARK>
> rtems.img is made by calling mkimage.
> > >
> > > At this time, I am trying to debug RTEMS BSP using GDB with
> J-Link probe.
> > > There is problem for executing start.S assembly code as source
> code level.
> >
> > Can you try to set a breakpoint on at least _Terminate and do a >
> backtrace (bt in gdb)? I think the _ARM_Exception_default could be a
> > useful one too.
> >
> > Best regards
> >
> > Christian
> >
> >
> > >
> > > Please advise me.
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > U-Boot 2020.10 (Jan 05 2021 - 09:44:38 +0900) > > > >
> CPU:Freescale i.MX7D rev1.3 1000 MHz (running at 792 MHz) > >
> CPU:Commercial temperature grade (0C to 95C) at 38C > > Reset cause:
> POR > > Model: Freescale i.MX7 SabreSD Board > > Board: i.MX7D
> SABRESD in non-secure mode > > DRAM:1 GiB > > PMIC: PFUZE3000
> DEV_ID=0x30 REV_ID=0x11 > > MMC:FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> > > Loading Environment from MMC... *** Warning - bad CRC, using
> default > > environment > > > > Video: 480x272x24 > > In:serial >
> > Out:serial > > Err:serial > > Hit any key to stop autoboot:0 > >
> > > => fatload mmc 0 0x80800000 rtems.img > > 36463 bytes read in 23
> ms (1.5 MiB/s) > > > > => fatload mmc 0 0x83000000 imx7d-sdb.dtb >
> > 33369 bytes read in 22 ms (1.4 MiB/s) > > > > => bootm 0x80800000
> - 0x83000000 > > ## Booting kernel from Legacy Image at 80800000 ...
> > > Image Name:RTEMS
> > > Image Type:ARM Linux Kernel Image (gzip compressed) > > Data
> Size:36399 Bytes = 35.5 KiB > > Load Address: 80200000 > > Entry
> Point:80200000 > > Verifying Checksum ... OK > > ## Flattened Device
> Tree blob at 83000000 > > Booting using the fdt blob at 0x83000000 >
> > Uncompressing Kernel Image > > Using Device Tree in place at
> 83000000, end 8300b258 > > > > Starting kernel ...
> > >
> > >
> > > *** FATAL ***
> > > fatal source: 6 (RTEMS_FATAL_SOURCE_BSP) > > fatal code: 3072
> (0x00000c00) > > RTEMS version: 6.0.0 > > RTEMS tools: 10.2.1
> 20201222 (RTEMS 6, RSB > > d3dc0bc3861362978cdf65725e4ba2b64e283d32,
> Newlib 415fdd4) > > Executing thread is NULL > >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > Best Regards,
> > > JunBeom Kim
> > >
> > > _______________________________________________
> > > users mailing list
> > > users at rtems.org <mailto:users at rtems.org> > >
> http://lists.rtems.org/mailman/listinfo/users
> > > <http://lists.rtems.org/mailman/listinfo/users>
> > >
> > >
> > > _______________________________________________
> > > users mailing list
> > > users at rtems.org
> > > http://lists.rtems.org/mailman/listinfo/users
> > >
More information about the users
mailing list