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 <o...@c-mauderer.de> Sent: Wednesday, January 6, 2021 10:17 PM To: jameszxj <james...@gmail.com>; JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr>; 'users' <users@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)" <jb...@e-coretech.kr>; > > *Date:* Wed, > Jan 6, 2021 04:46 PM > > *To:* > "'jameszxj'"<james...@gmail.com>;"'users'"<users@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) <jb...@e-coretech.kr> > > > *Sent:* Wednesday, January 6, 2021 5:39 PM > > *To:* 'jameszxj' > <james...@gmail.com>; 'users' <users@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-boun...@rtems.org > <mailto:users-boun...@rtems.org>> > > *On Behalf Of *jameszxj > > > *Sent:* Wednesday, January 6, 2021 4:13 PM > > *To:* users > <users@rtems.org <mailto:users@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)" <jb...@e-coretech.kr > > > <mailto:jb...@e-coretech.kr>>; > > > > *Date:*Wed, Jan 6, 2021 01:05 > PM > > > > *To:*"users"<users@rtems.org <mailto:users@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@rtems.org <mailto:users@rtems.org> > > > http://lists.rtems.org/mailman/listinfo/users > > > <http://lists.rtems.org/mailman/listinfo/users> > > > > > > > > > _______________________________________________ > > > users mailing list > > > users@rtems.org > > > http://lists.rtems.org/mailman/listinfo/users > > > _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users