Dear Sebastian,
I guess that GT timer interrupt 29 is correct.
timer {
compatible = "arm,armv7-timer";
interrupt-parent = <&intc>;
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_LOW)>;
clock-frequency = <8000000>;
};
Because GIC_PPI is 13, 16+13=29.
I don't know why GT timer interrupt service rountine is not entered.
I am checking this.
Best Regards,
JunBeom
-----Original Message-----
From: JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr>
Sent: Friday, April 13, 2018 5:05 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 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 : 80000000 (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
movw r0, #0x0000
movt r0, #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 = &uart5;
};
< imx7s.dtsi : added clock_frequency >
timer {
compatible = "arm,armv7-timer";
interrupt-parent = <&intc>;
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_LOW)>;
clock-frequency = <8000000>;
};
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 8000000 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) &bsp_fdt_blob[0]
- (uintptr_t) bsp_section_rodata_begin
+ (uintptr_t) bsp_section_rodata_load_begin); #else
uint32_t *d = RTEMS_DECONST(uint32_t *, &bsp_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 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 = <0x00000000>;
clock-frequency = ";]￢;
clock-latency = <0x0000ee6c>;
clocks = <0x00000001 0x000001b5>;
operating-points = <0x000f32a0 0x00106738 0x000c15c0 0x000ee098>;
phandle = <0x00000003>;
};
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
