RE: RTEMS booting problem for PICO-PI-IMX7 board.

[JunBeom Kim (EmbedCoreTech)]

Dear Sebastian,

No problem.

I found that there is difference for accessing GT between Cortex-A7(i.MX7D) and 
Cortex-A9(i.MX6Q) by ARM technical manual. Therefore, 
arm-a9mpcore-clock-config.c should be not used for Cortex-A7 based SoC.

If I have update in my side regarding RTEMS testing on PICO-PI-IMX7, I will let 
you know that.

At this time, I am focusing i.MX6Q regarding SMP and USB Host, too.

On referencing, I was successful to boot SMP kernel without u-boot on i.MX6Q. 
but, there is still problem for booting SMP kernel with u-boot.
I guess that current problem is related with u-boot.

Best Regards,
JunBeom Kim / EmbedCoreTech

-Original Message-
From: Sebastian Huber <sebastian.hu...@embedded-brains.de> 
Sent: Monday, April 16, 2018 2:46 PM
To: JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr>; users@rtems.org
Subject: Re: RTEMS booting problem for PICO-PI-IMX7 board.

Hello Kim,

On 13/04/18 10:04, JunBeom Kim (EmbedCoreTech) wrote:
> Dear Sebastian,
>
> I returned to your original code from arm-a9mpcore-clock-config.c to 
> arm-generic-timer-config.c.
> ( Reason ) Global timer register and SCU register can not be accessed by 
> direct memory access. Instead of this, CP15 control access should be used.
>
> Is it correct ?

sorry, I don't have time currently to look at the details of this chip.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.


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

Re: RTEMS booting problem for PICO-PI-IMX7 board.

[Sebastian Huber]

Hello Kim,

On 13/04/18 10:04, JunBeom Kim (EmbedCoreTech) wrote:

Dear Sebastian,

I returned to your original code from arm-a9mpcore-clock-config.c to 
arm-generic-timer-config.c.
( Reason ) Global timer register and SCU register can not be accessed by direct 
memory access. Instead of this, CP15 control access should be used.

Is it correct ?


sorry, I don't have time currently to look at the details of this chip.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: RTEMS booting problem for PICO-PI-IMX7 board.

[Russell Haley]

On Thu, Apr 12, 2018 at 11:40 PM, Sebastian Huber  wrote:

> Hello Russell,
>
> - Am 12. Apr 2018 um 23:41 schrieb Russell Haley russ.ha...@gmail.com:
>
> > Hi Sebastian,
> >
> > The Tq website doesn't  seem to provide much detail without giving them
> contact
> > information. Can I ask if you had specific criteria that made you choose
> that
> > board from Tq group?
>
> it was selected by a customer due to its requirements. TQ has usually a
> long product availability.
>

A very reasonable requirement, component end-of-life pain is real. However,
at the last company I worked used Digi ccmx53 soms because they claimed
long hardware support. After a few years it became apparent that Digi would
not support Linux kernel updates and there was no way to get at the
proprietary firmware for sub-components - notably the WiFi radio drivers. I
involuntarily spit on the floor if I hear the name RedPine.

Not that you'll have kernel problems, but I thought I'd share that. They
had settled on Phytec for their IMX SOMs but I don't know what they chose
for their Marvell solutions.

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

RE: RTEMS booting problem for PICO-PI-IMX7 board.

[JunBeom Kim (EmbedCoreTech)]

Dear Sebastian,

I returned to your original code from arm-a9mpcore-clock-config.c to 
arm-generic-timer-config.c.
( Reason ) Global timer register and SCU register can not be accessed by direct 
memory access. Instead of this, CP15 control access should be used.

Is it correct ?

When I check in my board regarding GT timer, information is below;
- arm_gt_clock_instance.interval : 8000 (decimal)
- arm_gt_clock_instance.irq : 29 (decimal)

As I knew in other processor as like i.MX6, GT timer interrupt is 27.

I am guessing that this reason is DTS description difference.

Please let me know arm_gt_clock_instance.irq number in your target.

Best Regards,
JunBeom

-Original Message-
From: JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr> 
Sent: Thursday, April 12, 2018 5:11 PM
To: 'Sebastian Huber' <sebastian.hu...@embedded-brains.de>; 'users@rtems.org' 
<users@rtems.org>
Subject: RE: RTEMS booting problem for PICO-PI-IMX7 board.

Dear Huber,

I guess that this problem is related with u-boot.

At this time, I moved call location in start.S temporarily. 
After I modified this, bsp_fdt_copy() is run.

~~
#ifdef BSP_START_COPY_FDT_FROM_U_BOOT
#ifdef RTEMS_SMP
cmp r7, #0
bne 1f
#endif
movwr0, #0x
movtr0, #0x8300
bl  bsp_fdt_copy
1:
#endif

/* Branch to boot card */
mov r0, #0
bl  boot_card
~~

Also, I modified dts file for not changing RTEMS BSP code as like below; < 
imx7d-pico.dtsi : added stdout-path >
chosen {
stdout-path = 
};


< imx7s.dtsi : added clock_frequency >
timer {
compatible = "arm,armv7-timer";
interrupt-parent = <>;
interrupts = ,
 ,
 ,
 ;
clock-frequency = <800>;
};

Even though this modified dts is used, RTEMS booting is stopped.
I found error location regarding this.
< imfs_creat.c >
#if 0 // ECT. original
memcpy( RTEMS_DECONST( char *, node->name ), name, namelen ); #else
int i;
char *dest_name = node->name;
for (i=0; i<namelen; i++)
dest_name[i] = name[i];
#endif  

I don't know why memcpy is hang up status even though ARM CP15 Alignment Fault 
is disable in RTEMS ARM code.

Anyway, when I change this, serial is out in UART5 debug port.
On referencing, because console interrupt mode is not working here, I changed 
to console polling mode.

Final problem is that arm-generic-timer-clock is not worked even though I added 
clock_frequency in DTS's timer part. I checked clock-frequency is 800 in 
arm_generic_timer_get_config().

I think that my trial on PICO-PI-IMX7 board will consume my time continuously.
I am considering to change board from PICO to i.MX7D SDB board.

Please confirm that you completed to test RTEMS on i.MX7D SDB board.
If you confirm this, I will purchase i.MX7D SDB board.

Best Regards,
JunBeomn Kim / EmbedCoreTech

-Original Message-
From: JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr>
Sent: Wednesday, April 11, 2018 2:07 PM
To: 'Sebastian Huber' <sebastian.hu...@embedded-brains.de>; 'users@rtems.org' 
<users@rtems.org>
Subject: RE: RTEMS booting problem for PICO-PI-IMX7 board.

Dear Huber,

I found problem location.

< Assembly level >
//  movw r5, #0x0040
//  movt r5, #0x30A7
//  mov r6, #0x40
//  str r6, [r5]
This code transfer '@' data using UART5 TX register(0x30A70040).

< C Level >
#define mmio32_write(addr,val) *((volatile unsigned int *)(addr)) = (val) 
mmio32_write(0x30A70040, 0x40); /* @ */

Problem location is in bsp_fdt_copy() of bsp-fdt.c.

void bsp_fdt_copy(const void *src)
{
  const uint32_t *s = (const uint32_t *) src; #ifdef 
BSP_FDT_BLOB_COPY_TO_READ_ONLY_LOAD_AREA
  uint32_t *d = (uint32_t *) ((uintptr_t) _fdt_blob[0]
- (uintptr_t) bsp_section_rodata_begin
+ (uintptr_t) bsp_section_rodata_load_begin); #else
  uint32_t *d = RTEMS_DECONST(uint32_t *, _fdt_blob[0]); #endif

  if (s != d) {
size_t m = MIN(sizeof(bsp_fdt_blob), fdt_totalsize(src));
size_t n = (m + sizeof(*d) - 1) / sizeof(*d);
size_t i;

#if 1 // test code
uint32_t temp;

for (i = 0; i < n; ++i) {
  temp = s[i];
}
mmio32_write(0x30A70040, 0x40); /* @ */
/* REMARK : Read Operation is OK */

for (i = 0; i < n; ++i) {
   d[i] = temp;
}
/* REMARK : Write Operation is FAIL. Entering exception */

mmio32_write(0x30A70040, 0x41); /* A */ #endif

for (i = 0; i < n; ++i) {
  d[i] = s[i];
}

rtems_cache_flush_multiple_data_lines(d, m);
  }
}

I think that it is related with MMU configuration(Maybe, write protection) by 
U-Boot.

I am checking this.

Best 

Re: RTEMS booting problem for PICO-PI-IMX7 board.

[Sebastian Huber]

Hello Russell,

- Am 12. Apr 2018 um 23:41 schrieb Russell Haley russ.ha...@gmail.com:

> Hi Sebastian,
> 
> The Tq website doesn't  seem to provide much detail without giving them 
> contact
> information. Can I ask if you had specific criteria that made you choose that
> board from Tq group?

it was selected by a customer due to its requirements. TQ has usually a long 
product availability.

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

Re: RTEMS booting problem for PICO-PI-IMX7 board.

[Russell Haley]

Hi Sebastian,

The Tq website doesn't  seem to provide much detail without giving them contact 
information. Can I ask if you had specific criteria that made you choose that 
board from Tq group?

Thanks
Russ
Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Sebastian Huber
Sent: Thursday, April 12, 2018 1:13 AM
To: JunBeom Kim (EmbedCoreTech); users@rtems.org
Subject: Re: RTEMS booting problem for PICO-PI-IMX7 board.

On 12/04/18 10:11, JunBeom Kim (EmbedCoreTech) wrote:
> Please confirm that you completed to test RTEMS on i.MX7D SDB board.
> If you confirm this, I will purchase i.MX7D SDB board.

No, I used this board:

https://www.tq-group.com/en/products/product-details/prod/embedded-modul-tqma7x/extb/Main/productdetail/

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
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

Re: RTEMS booting problem for PICO-PI-IMX7 board.

[Sebastian Huber]

On 12/04/18 10:11, JunBeom Kim (EmbedCoreTech) wrote:

Please confirm that you completed to test RTEMS on i.MX7D SDB board.
If you confirm this, I will purchase i.MX7D SDB board.


No, I used this board:

https://www.tq-group.com/en/products/product-details/prod/embedded-modul-tqma7x/extb/Main/productdetail/

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

RE: RTEMS booting problem for PICO-PI-IMX7 board.

[JunBeom Kim (EmbedCoreTech)]

Dear Huber,

I guess that this problem is related with u-boot.

At this time, I moved call location in start.S temporarily. 
After I modified this, bsp_fdt_copy() is run.

~~
#ifdef BSP_START_COPY_FDT_FROM_U_BOOT
#ifdef RTEMS_SMP
cmp r7, #0
bne 1f
#endif
movwr0, #0x
movtr0, #0x8300
bl  bsp_fdt_copy
1:
#endif

/* Branch to boot card */
mov r0, #0
bl  boot_card
~~

Also, I modified dts file for not changing RTEMS BSP code as like below;
< imx7d-pico.dtsi : added stdout-path >
chosen {
stdout-path = 
};


< imx7s.dtsi : added clock_frequency >
timer {
compatible = "arm,armv7-timer";
interrupt-parent = <>;
interrupts = ,
 ,
 ,
 ;
clock-frequency = <800>;
};

Even though this modified dts is used, RTEMS booting is stopped.
I found error location regarding this.
< imfs_creat.c >
#if 0 // ECT. original
memcpy( RTEMS_DECONST( char *, node->name ), name, namelen );
#else
int i;
char *dest_name = node->name;
for (i=0; i<namelen; i++)
dest_name[i] = name[i];
#endif  

I don't know why memcpy is hang up status even though ARM CP15 Alignment Fault 
is disable in RTEMS ARM code.

Anyway, when I change this, serial is out in UART5 debug port.
On referencing, because console interrupt mode is not working here, I changed 
to console polling mode.

Final problem is that arm-generic-timer-clock is not worked even though I added 
clock_frequency in DTS's timer part. I checked clock-frequency is 800 in 
arm_generic_timer_get_config().

I think that my trial on PICO-PI-IMX7 board will consume my time continuously.
I am considering to change board from PICO to i.MX7D SDB board.

Please confirm that you completed to test RTEMS on i.MX7D SDB board.
If you confirm this, I will purchase i.MX7D SDB board.

Best Regards,
JunBeomn Kim / EmbedCoreTech

-Original Message-
From: JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr> 
Sent: Wednesday, April 11, 2018 2:07 PM
To: 'Sebastian Huber' <sebastian.hu...@embedded-brains.de>; 'users@rtems.org' 
<users@rtems.org>
Subject: RE: RTEMS booting problem for PICO-PI-IMX7 board.

Dear Huber,

I found problem location.

< Assembly level >
//  movw r5, #0x0040
//  movt r5, #0x30A7
//  mov r6, #0x40
//  str r6, [r5]
This code transfer '@' data using UART5 TX register(0x30A70040).

< C Level >
#define mmio32_write(addr,val) *((volatile unsigned int *)(addr)) = (val) 
mmio32_write(0x30A70040, 0x40); /* @ */

Problem location is in bsp_fdt_copy() of bsp-fdt.c.

void bsp_fdt_copy(const void *src)
{
  const uint32_t *s = (const uint32_t *) src; #ifdef 
BSP_FDT_BLOB_COPY_TO_READ_ONLY_LOAD_AREA
  uint32_t *d = (uint32_t *) ((uintptr_t) _fdt_blob[0]
- (uintptr_t) bsp_section_rodata_begin
+ (uintptr_t) bsp_section_rodata_load_begin); #else
  uint32_t *d = RTEMS_DECONST(uint32_t *, _fdt_blob[0]); #endif

  if (s != d) {
size_t m = MIN(sizeof(bsp_fdt_blob), fdt_totalsize(src));
size_t n = (m + sizeof(*d) - 1) / sizeof(*d);
size_t i;

#if 1 // test code
uint32_t temp;

for (i = 0; i < n; ++i) {
  temp = s[i];
}
mmio32_write(0x30A70040, 0x40); /* @ */
/* REMARK : Read Operation is OK */

for (i = 0; i < n; ++i) {
   d[i] = temp;
}
/* REMARK : Write Operation is FAIL. Entering exception */

mmio32_write(0x30A70040, 0x41); /* A */ #endif

for (i = 0; i < n; ++i) {
  d[i] = s[i];
}

rtems_cache_flush_multiple_data_lines(d, m);
  }
}

I think that it is related with MMU configuration(Maybe, write protection) by 
U-Boot.

I am checking this.

Best Regards,
JunBeom


-Original Message-
From: JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr>
Sent: Wednesday, April 11, 2018 12:34 AM
To: 'Sebastian Huber' <sebastian.hu...@embedded-brains.de>; 'users@rtems.org' 
<users@rtems.org>
Subject: RE: RTEMS booting problem for PICO-PI-IMX7 board.

Dear Huber,

Please disregard my question about BSP_ARM_A9MPCORE_GT_BASE, 
BSP_ARM_A9MPCORE_SCU_BASE.

I checked this again.

Because i.MX7 port use arm-generic-timer-clock-confg.c instead of 
arm-a9mpcore-clock-config.c, these ZERO value will not effect any problem for 
i.MX7.

Best Regards,
JunBeom

-Original Message-
From: JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr>
Sent: Wednesday, April 11, 2018 12:08 AM
To: 'Sebastian Huber' <sebastian.hu...@embedded-brains.de>; 'users@rtems.org' 
<users@rtems.org>
Subject: RE: RTEMS booting problem for PICO-PI-IMX7 board.

Dear Huber,

I think so. DTB is modified by U-Boot. I d

Re: RTEMS booting problem for PICO-PI-IMX7 board.

[Russell Haley]

On Mon, Apr 9, 2018 at 6:50 PM, JunBeom Kim (EmbedCoreTech) <
jb...@e-coretech.kr> wrote:

> Dear Sir,
>
> Is there RTEMS users for running RTEMS for PICO-PI-IMX7 board ?
>
> I purchased PICO-PI-IMX7 from Wanboard.
> https://www.wandboard.org/products/android-things/PICO-PI-IMX7/
>
> I am tring to test RTEMS on PICO-PI-IMX7 using RTEMS current version for
> i.MX7D SDB board.
>

Ooooh, this is a sexy little kit...

https://www.variscite.com/products/system-on-module-som/cortex-a7/var-som-mx7-nxp-freescale-imx-7/


>
> On referencing, when I check PICO-PI-IMX7 board, there is u-boot only.
> Also, there is eMMC memory only. (It was headache in first)
> Therefore, I needed additional work for writing your modified u-boot
> and/or for preparing RTEMS image FAT32 storage. Additional work means that
> u-boot writing by dd command and eMMC partition configuration by fdisk
> command after Linux kernel is booting.
>
> At this time, I removed Linux kernel image on eMMC storage and I am ready
> to test RTEMS image only.
> Also, If user use "ums 0 mmc 0" command in u-boot, user can replace RTEMS
> image and dtb file easily on PC(Windows or Linux Desktop).
>
> As I check difference between PICO-PI-IMX7 and i.MX7D SDB, UART debug port
> number is different.
>  - PICO-PI-IMX7 : UART5 (serial4)
>  - i.MX7D SDB : UART1 (serial0)
>
> After I check current RTEMS bsp source, I modified console-config.c due to
> UART port number change in below;
>
> < Original code : for UART1 debug port >
> static imx_uart_context imx_uart_instances[7];
> static imx_uart_context *imx_uart_console = _uart_instances[0];
>
> < Modified code : for UART5 debug port >
> static imx_uart_context imx_uart_instances[7];
> static imx_uart_context *imx_uart_console = _uart_instances[4];
>
> Even though I modified this, there is not any output after running RTEMS.
>
> I am checking UART configuration by FDT.
>
> As I check imx_uart_probe() function of console-config.c, there is
> "chosen" and "stdout-path" keyword in below;
>
> static void imx_uart_probe(void)
> {
>   const void *fdt;
>   int node;
>   int offset;
>   const char *console;
>   size_t i;
>
>   fdt = bsp_fdt_get();
>   node = fdt_path_offset(fdt, "/chosen");
>
>   console = fdt_getprop(fdt, node, "stdout-path", NULL);
>   if (console == NULL) {
> console = "";
>   }
>   ...
> }
>
> I think that there should be declaration for "stdout-path" of "chosen"
> area in dts(including dtsi) source file.
>
> As I check dts files on lastest Linux kernel for both i.MX7D SDB and
> PICO-IMX7, there is not "stdout-path" information of "chosen".
>
> I attached files related with this.
>
>  - i.MX7D SDB : imx7d-sdb.dts with imx7d.dtsi, imx7s.dtsi
>  - PICO-IMX7 : imx7d-pico-pi.dts with imx7d-pico.dtsi, imx7d.dtsi,
> imx7s.dtsi
>
> Because there is blank information for "chosen" in imx7s.dtsi, I added
> "stdout-path" in imx7d-pico-dtsi.
>
> < imx7s.dtsi >
> / {
> #address-cells = <1>;
> #size-cells = <1>;
> /*
>  * The decompressor and also some bootloaders rely on a
>  * pre-existing /chosen node to be available to insert the
>  * command line and merge other ATAGS info.
>  * Also for U-Boot there must be a pre-existing /memory node.
>  */
> chosen {}; ==> "there is not any information for stdout-path"
> memory { device_type = "memory"; };
>   ...
> }
>
> < My modified imx7d-pico.dtsi >
>
> / {
> model = "Technexion Pico i.MX7D Board";
> compatible = "technexion,imx7d-pico", "fsl,imx7d";
>
> memory@8000 {
> reg = <0x8000 0x8000>;
> };
>
> chosen {
> stdout-path = "; ==> "I added stdout-path
> information".
> };
>
>   ...
> }
>
> After I modified imx7d-pico.dtsi, I made imx7d-pico-pi.dtb.
>
> Finally, I tried to run RTEMS using the revised dtb file. But, there is
> not any serial output.
>
> On referencing, there is not JTAG debug port in PICO board, It is very
> difficult to debug current RTEMS for i.MX7D.
>
> If there is mistake in my trial step, please let me know that.
>
> Best Regards,
> JunBeom Kim
> ~~
> President / EmbedCoreTech
> Phone: +82-31-396-5584
> Fax: +82-504-065-5720
> Mobile:+82-10-6425-5720
> Email: jb...@e-coretech.kr
> Web: www.e-coretech.kr
> ~~
>
>
>
> ___
> 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

RE: RTEMS booting problem for PICO-PI-IMX7 board.

[JunBeom Kim (EmbedCoreTech)]

Dear Huber,

Please disregard my question about BSP_ARM_A9MPCORE_GT_BASE, 
BSP_ARM_A9MPCORE_SCU_BASE.

I checked this again.

Because i.MX7 port use arm-generic-timer-clock-confg.c instead of 
arm-a9mpcore-clock-config.c, these ZERO value will not effect any problem for 
i.MX7.

Best Regards,
JunBeom

-Original Message-
From: JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr> 
Sent: Wednesday, April 11, 2018 12:08 AM
To: 'Sebastian Huber' <sebastian.hu...@embedded-brains.de>; 'users@rtems.org' 
<users@rtems.org>
Subject: RE: RTEMS booting problem for PICO-PI-IMX7 board.

Dear Huber,

I think so. DTB is modified by U-Boot. I don't know the reason right now. I am 
checking u-boot source.

But, Because clock-frequency variable of timer is disappeared in lastest Linux 
kernel, you need to review arm_generic_timer_get_config() in bspstart.c

I checked "dtc command on Linux" and "fdt command on u-boot"

< dtc command on Linux >
cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0x0>;
clock-frequency = <0x3b5dc100>;
clock-latency = <0xee6c>;
clocks = <0x1 0x1b5>;
operating-points = <0xf32a0 0x106738 0xc15c0 0xee098>;
phandle = <0x3>;
};

< fdt command on u-boot >
cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0x>;
clock-frequency = ";]￢;
clock-latency = <0xee6c>;
clocks = <0x0001 0x01b5>;
operating-points = <0x000f32a0 0x00106738 0x000c15c0 0x000ee098>;
phandle = <0x0003>;
};

Also, I am checking bsp/arm/imx/include/bsp.h At this time, below definition is 
zero.

#define BSP_ARM_A9MPCORE_GT_BASE 0
#define BSP_ARM_A9MPCORE_SCU_BASE 0

Is there any reason which this definition is zero ?

Best Regards,
JunBeom

-Original Message-
From: Sebastian Huber <sebastian.hu...@embedded-brains.de>
Sent: Tuesday, April 10, 2018 10:51 PM
To: JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr>; users@rtems.org
Subject: Re: RTEMS booting problem for PICO-PI-IMX7 board.

On 10/04/18 15:44, JunBeom Kim (EmbedCoreTech) wrote:
> At this time, I am checking Linux kernel's DTS building again.

The DTB is modified by U-Boot before it is handed over to the system to start. 
See the U-Boot sources for the details.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.


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

RE: RTEMS booting problem for PICO-PI-IMX7 board.

[JunBeom Kim (EmbedCoreTech)]

Dear Huber,

I think so. DTB is modified by U-Boot. I don't know the reason right now. I am 
checking u-boot source.

But, Because clock-frequency variable of timer is disappeared in lastest Linux 
kernel, you need to review arm_generic_timer_get_config() in bspstart.c

I checked "dtc command on Linux" and "fdt command on u-boot"

< dtc command on Linux >
cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0x0>;
clock-frequency = <0x3b5dc100>;
clock-latency = <0xee6c>;
clocks = <0x1 0x1b5>;
operating-points = <0xf32a0 0x106738 0xc15c0 0xee098>;
phandle = <0x3>;
};

< fdt command on u-boot >
cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0x>;
clock-frequency = ";]￢;
clock-latency = <0xee6c>;
clocks = <0x0001 0x01b5>;
operating-points = <0x000f32a0 0x00106738 0x000c15c0 0x000ee098>;
phandle = <0x0003>;
};

Also, I am checking bsp/arm/imx/include/bsp.h
At this time, below definition is zero.

#define BSP_ARM_A9MPCORE_GT_BASE 0
#define BSP_ARM_A9MPCORE_SCU_BASE 0

Is there any reason which this definition is zero ?

Best Regards,
JunBeom

-Original Message-
From: Sebastian Huber <sebastian.hu...@embedded-brains.de> 
Sent: Tuesday, April 10, 2018 10:51 PM
To: JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr>; users@rtems.org
Subject: Re: RTEMS booting problem for PICO-PI-IMX7 board.

On 10/04/18 15:44, JunBeom Kim (EmbedCoreTech) wrote:
> At this time, I am checking Linux kernel's DTS building again.

The DTB is modified by U-Boot before it is handed over to the system to start. 
See the U-Boot sources for the details.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.


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

RE: RTEMS booting problem for PICO-PI-IMX7 board.

[JunBeom Kim (EmbedCoreTech)]

Dear Huber,

I checked DTS file which you sent me shortly.

There are different points;

1) chosen : MBa7x is configured for serial5(uart6).
  - I will add this in pico dts again as serial4(uart5)
  - This feature should be added not for modifying console-config.c.

2) timer : it is real problem. There is not "clock-frequency" in pico DTS.
  - I will check this.

I think that other tag will not effect RTEMS booting.

As soon as I have update, I will let you know.

Best Regards,
JunBeom

-Original Message-
From: Sebastian Huber <sebastian.hu...@embedded-brains.de> 
Sent: Tuesday, April 10, 2018 6:23 PM
To: JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr>; users@rtems.org
Subject: Re: RTEMS booting problem for PICO-PI-IMX7 board.

Attached is a DTS file reconstructed from the DTB presented by U-Boot. 
Please note that U-Boot modifies the DTB. It is the default DTB of this 
board:

https://www.tq-group.com/en/products/product-details/prod/embedded-modul-tqma7x/extb/Main/productdetail/

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.


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

RE: RTEMS booting problem for PICO-PI-IMX7 board.

[JunBeom Kim (EmbedCoreTech)]

Dear Huber,

I think that it is another option.

But, I think that device tree based probing for ARMv7A GIC, timer, serial is 
best approach.

I want to use device tree based probing method continuously.

If possible, please could you send me imx7d-sdb.dtb file which you are using ?

Best Regards,
JunBeom Kim

-Original Message-
From: Sebastian Huber <sebastian.hu...@embedded-brains.de> 
Sent: Tuesday, April 10, 2018 2:28 PM
To: JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr>; users@rtems.org
Subject: Re: RTEMS booting problem for PICO-PI-IMX7 board.

Hello Kim,

maybe you can temporarily disable the device tree based probing and use a hard 
coded console device.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.


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