RE: RTEMS Fatal Error on IMX7D SABRE Board.

2021-01-06 Thread JunBeom Kim (EmbedCoreTech)
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  
Sent: Wednesday, January 6, 2021 10:17 PM
To: jameszxj ; JunBeom Kim (EmbedCoreTech) 
; 'users' 
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)" ;  > > *Date:* Wed, 
> Jan 6, 2021 04:46 PM  > > *To:* 
> "'jameszxj'";"'users'";
>  > > *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)   > > 
> *Sent:* Wednesday, January 6, 2021 5:39 PM  > > *To:* 'jameszxj' 
> ; 'users'   > > *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  <mailto:users-boun...@rtems.org>>  > > *On Behalf Of *jameszxj  > > 
> *Sent:* Wednesday, January 6, 2021 4:13 PM  > > *To:* users 
> 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 
>

Re: RTEMS Fatal Error on IMX7D SABRE Board.

2021-01-06 Thread jameszxj
Hi Christian


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



Thanks for the details. I forget to remove some power test code, it makes the 
system enter low power mode. ;)
Now rtems is running successfully.


Thanks again.___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

RE: RTEMS Fatal Error on IMX7D SABRE Board.

2021-01-06 Thread JunBeom Kim (EmbedCoreTech)
Hello,

I checked this again. Thank you very much.

Because I used imx7d-sdb.dtb file from u-boot\arch\arm\dts, there was a problem 
for initializing general timer.

As soon as I have update for testing MX7D SABRE board, I will let you know that.

Best Regards,
JunBeom

-Original Message-
From: Christian Mauderer  
Sent: Wednesday, January 6, 2021 6:24 PM
To: jameszxj ; JunBeom Kim (EmbedCoreTech) 
; 'users' 
Subject: Re: RTEMS Fatal Error on IMX7D SABRE Board.

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/02270d5ec82684007ae9973070a6f29428be1543

It's on my TODO-list to avoid that patch, but I haven't done that yet.

> 
> -- Original --
> *From:* "JunBeom Kim (EmbedCoreTech)" ;
> *Date:* Wed, Jan 6, 2021 04:46 PM
> *To:* "'jameszxj'";"'users'";
> *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.


> 
> Best Regards,
> 
> JunBeom
> 
> *From:*JunBeom Kim (EmbedCoreTech) 
> *Sent:* Wednesday, January 6, 2021 5:39 PM
> *To:* 'jameszxj' ; 'users' 
> *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  <mailto:users-boun...@rtems.org>> *On Behalf Of *jameszxj
> *Sent:* Wednesday, January 6, 2021 4:13 PM
> *To:* users 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.

> 
> 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)"  <mailto:jb...@e-coretech.kr>>;
> 
> *Date:*Wed, Jan 6, 2021 01:05 PM
> 
> *To:*"users"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;  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
>

Re: RTEMS Fatal Error on IMX7D SABRE Board.

2021-01-06 Thread Christian Mauderer

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/02270d5ec82684007ae9973070a6f29428be1543

 >
 > 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)" ;
 > > *Date:* Wed, Jan 6, 2021 04:46 PM
 > > *To:* "'jameszxj'";"'users'";
 > > *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) 
 > > *Sent:* Wednesday, January 6, 2021 5:39 PM
 > > *To:* 'jameszxj' ; 'users' 
 > > *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 <mailto:users-boun...@rtems.org>>

 > > *On Behalf Of *jameszxj
 > > *Sent:* Wednesday, January 6, 2021 4:13 PM
 > > *To:* users 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:
 >
 >?0?2 ?0?2 ?0?2 https://github.com/grisp/grisp2-rtems-toolchain
 >
 > >
 > > -- Original --
 > >
 > > *From:*"JunBeom Kim (EmbedCoreTech)"  > <mailto:jb...@e-coretech.kr>>;
 > >
 > > *Date:*Wed, Jan 6, 2021 01:05 PM
 > >
 > > *To:*"users"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;
 > >  rtems.img is made by calling mkimage.
 > >
 > > At this time, I am trying to debug RTEMS BSP usi

Re: RTEMS Fatal Error on IMX7D SABRE Board.

2021-01-06 Thread jameszxj
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/02270d5ec82684007ae9973070a6f29428be1543

 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.


 
  -- Original --
  *From:* "JunBeom Kim (EmbedCoreTech)" mailto:users-boun...@rtems.org;
  *On Behalf Of *jameszxj
  *Sent:* Wednesday, January 6, 2021 4:13 PM
  *To:* users 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.


 
  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)" mailto:jb...@e-coretech.kr;;
 
  *Date:*Wed, Jan 6, 2021 01:05 PM
 
  *To:*"users"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;
  mailto:users@rtems.org;
  http://lists.rtems.org/mailman/listinfo/users;
  

Re: RTEMS Fatal Error on IMX7D SABRE Board.

2021-01-06 Thread Christian Mauderer

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/02270d5ec82684007ae9973070a6f29428be1543

It's on my TODO-list to avoid that patch, but I haven't done that yet.



-- Original --
*From:* "JunBeom Kim (EmbedCoreTech)" ;
*Date:* Wed, Jan 6, 2021 04:46 PM
*To:* "'jameszxj'";"'users'";
*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.





Best Regards,

JunBeom

*From:*JunBeom Kim (EmbedCoreTech) 
*Sent:* Wednesday, January 6, 2021 5:39 PM
*To:* 'jameszxj' ; 'users' 
*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 mailto:users-boun...@rtems.org>> 
*On Behalf Of *jameszxj

*Sent:* Wednesday, January 6, 2021 4:13 PM
*To:* users 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.




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)" <mailto:jb...@e-coretech.kr>>;


*Date:*Wed, Jan 6, 2021 01:05 PM

*To:*"users"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;
 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 0x8080 rtems.img
36463 bytes read in 23 ms (1.5 MiB/s)

=> fatload mmc 0 0x8300 imx7d-sdb.dtb
33369 bytes read in 22 ms (1.4 MiB/s)

=> bootm 0x8080 - 0x8300
## Booting kernel from Legacy Image at 8080 ...
Image Name:RTEMS
Image Type:ARM Linux Kernel Image (gzip compressed)
Data Size:36399 Bytes = 35.5 KiB
Load Address: 8020
Entry Point:8020
Verifying Checksum ... OK
## Flattened Device Tree blob at 8300
Booting using the fdt blob at 0x8300
Uncompressing Kernel Image
Using Device Tree in place at 8300, end 8300b258

Starting kernel ...


*** FATAL ***
fatal source: 6 (RTEMS_FATAL_SOURCE_BSP)
fatal code: 3072 (0x0c00)
RTEMS version: 6.0.0
RTEMS tools: 10.2.1 20201222 (RTEMS 6, RSB
d3dc0bc3861362978cdf65725e4ba2b64e283d32, Newlib 415fdd4)
Executing thread is NULL
~~

RE: RTEMS Fatal Error on IMX7D SABRE Board.

2021-01-06 Thread JunBeom Kim (EmbedCoreTech)
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.

 

Best Regards,

JunBeom

 

From: JunBeom Kim (EmbedCoreTech)  
Sent: Wednesday, January 6, 2021 5:39 PM
To: 'jameszxj' ; 'users' 
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.

 

Best Regards,

JunBeom

 

From: users mailto:users-boun...@rtems.org> > On
Behalf Of jameszxj
Sent: Wednesday, January 6, 2021 4:13 PM
To: users 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".

But I encountered another problems, the  ARMv7-AR Generic Timer  can not
generate interrupt.
imx7d has the same core with imx6ull,if your board run RTEMS successfully,
please let me know, thanks.

 

 

-- Original --

From: "JunBeom Kim (EmbedCoreTech)" mailto:jbkim@e-
coretech.kr> >;

Date: Wed, Jan 6, 2021 01:05 PM

To: "users"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;
 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.

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 0x8080 rtems.img
36463 bytes read in 23 ms (1.5 MiB/s)

=> fatload mmc 0 0x8300 imx7d-sdb.dtb
33369 bytes read in 22 ms (1.4 MiB/s)

=> bootm 0x8080 - 0x8300
## Booting kernel from Legacy Image at 8080 ...
   Image Name:   RTEMS
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:36399 Bytes = 35.5 KiB
   Load Address: 8020
   Entry Point:  8020
   Verifying Checksum ... OK
## Flattened Device Tree blob at 8300
   Booting using the fdt blob at 0x8300
   Uncompressing Kernel Image
   Using Device Tree in place at 8300, end 8300b258

Starting kernel ...


*** FATAL ***
fatal source: 6 (RTEMS_FATAL_SOURCE_BSP)
fatal code: 3072 (0x0c00)
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

___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

RE: RTEMS Fatal Error on IMX7D SABRE Board.

2021-01-06 Thread JunBeom Kim (EmbedCoreTech)
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.

 

Best Regards,

JunBeom

 

From: users  On Behalf Of jameszxj
Sent: Wednesday, January 6, 2021 4:13 PM
To: users 
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".

But I encountered another problems, the  ARMv7-AR Generic Timer  can not
generate interrupt.
imx7d has the same core with imx6ull,if your board run RTEMS successfully,
please let me know, thanks.

 

 

-- Original --

From: "JunBeom Kim (EmbedCoreTech)" mailto:jbkim@e-
coretech.kr> >;

Date: Wed, Jan 6, 2021 01:05 PM

To: "users"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;
 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.

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 0x8080 rtems.img
36463 bytes read in 23 ms (1.5 MiB/s)

=> fatload mmc 0 0x8300 imx7d-sdb.dtb
33369 bytes read in 22 ms (1.4 MiB/s)

=> bootm 0x8080 - 0x8300
## Booting kernel from Legacy Image at 8080 ...
   Image Name:   RTEMS
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:36399 Bytes = 35.5 KiB
   Load Address: 8020
   Entry Point:  8020
   Verifying Checksum ... OK
## Flattened Device Tree blob at 8300
   Booting using the fdt blob at 0x8300
   Uncompressing Kernel Image
   Using Device Tree in place at 8300, end 8300b258

Starting kernel ...


*** FATAL ***
fatal source: 6 (RTEMS_FATAL_SOURCE_BSP)
fatal code: 3072 (0x0c00)
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  
http://lists.rtems.org/mailman/listinfo/users



imx7d-sdb.dts
Description: Binary data


imx7d.dtsi
Description: Binary data
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users