date:20180413

Re: Trouble with Quick Start build on CentOS 7 and Ubuntu

2018-04-13 Thread Chris Johns


On 14/4/18 11:19 am, Christopher Etzkorn wrote:
I have attempted multiple times to build the SPARC toolchain on both 
CentOS 7 and Ubuntu 16.04.4 in VirtualBox, and I keep hitting a snag at 
this point:


# ../source-builder/sb-set-builder --prefix=$HOME/development/rtems/5 
5/rtems-sparc


The build always fails at

config: tools/rtems-gcc-7.3.0-newlib.3.0.0.cfg
package: sparc-rtems5-gcc-7.3.0-newlib-3.0.0-x86_64-linux-gnu-1
building: sparc-rtems5-gcc-7.3.0-newlib-3.0.0-x86_64-linux-gnu-1
_


And I'm ultimately forced to kill the process.



What does the log say?

Did the RSB create an RSB error report?

You can open another terminal and follow the log to see if it is still 
running (see 'tail -f').




In CentOS, I have successfully installed the 4.13 version of texinfo.  
(Ignoring Ubuntu for now)


I also installed ncurses-devel, and I successfully followed this 
instruction:


# yum install autoconf automake binutils gcc gcc-c++ gdb make patch 
\bison flex xz unzip ncurses-devel texinfo zlib-devel python-devel git


which is listed under 3.1.2. CentOS on the RSB page.

(Most of which I covered earlier on by running #yum group install 
"Development Tools" and by installing texinfo separately).


Nada.

I have also looked into making this change, MAKEINFO=true, inside the 
.cfg files based on the information contained in the following link, but 
I have not yet done so.  (Found in a recent post in the user mailing list):


https://github.com/mdavidsaver/rsb/commit/f0bf5876ad96417db07a876845fbf833b10ced65



This should be resolved. The change may be different as another more 
supported method was used.




To cover my bases and do this as neatly as possible, I have deleted 
CentOS 7, recreated it, and run the following commands in this order:


$ su
# dhclient
# yum install git
# yum install wget
# yum group install "Development Tools"
# yum install autoconf automake binutils gcc gcc-c++ gdb make patch \ 
bison flex xz unzip ncurses-devel zlib-devel python-devel git


*/ I removed texinfo from the previous command and installed it 
separately following the instructions for 4.13 /*


# cd ~
# mkdir -p Downloads
# cd Downloads
# wget http://ftp.gnu.org/gnu/texinfo/texinfo-4.13.tar.gz
# tar -xzf texinfo-4.13.tar.gz
# cd texinfo-4.13
# ./configure --prefix=$HOME/development/texinfo-4.13
# make
# make install
# export PATH=$HOME/development/texinfo-4.13/bin:$PATH

# cd
# mkdir -p development/rtems/rsb
# cd development/rtems/rsb
# git clone git://git.rtems.org/rtems-source-builder.git 


# cd rtems-source-builder
# cd rtems
#../source-builder/sb-set-builder --prefix=$HOME/development/rtems/5 
5/rtems-sparc



Annnd, fail



A fail will have an error. Please inspect the log and see what the build 
was doing and why it failed.




The output is in a slightly different order this time, but it's still 
crashing at


building: sparc-rtems5-gcc-7.3.0-newlib-3.0.0-x86_64-linux-gnu-1


At this point, I'm assuming I'm missing something completely asinine



Building in a VM can be slow.

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

Trouble with Quick Start build on CentOS 7 and Ubuntu

2018-04-13 Thread Christopher Etzkorn

I have attempted multiple times to build the SPARC toolchain on both CentOS
7 and Ubuntu 16.04.4 in VirtualBox, and I keep hitting a snag at this point:

# ../source-builder/sb-set-builder --prefix=$HOME/development/rtems/5
5/rtems-sparc

The build always fails at

config: tools/rtems-gcc-7.3.0-newlib.3.0.0.cfg
package: sparc-rtems5-gcc-7.3.0-newlib-3.0.0-x86_64-linux-gnu-1
building: sparc-rtems5-gcc-7.3.0-newlib-3.0.0-x86_64-linux-gnu-1
_


And I'm ultimately forced to kill the process.


In CentOS, I have successfully installed the 4.13 version of texinfo.
(Ignoring Ubuntu for now)

I also installed ncurses-devel, and I successfully followed this
instruction:

# yum install autoconf automake binutils gcc gcc-c++ gdb make patch \bison
flex xz unzip ncurses-devel texinfo zlib-devel python-devel git

which is listed under 3.1.2. CentOS on the RSB page.

(Most of which I covered earlier on by running #yum group install
"Development Tools" and by installing texinfo separately).

Nada.

I have also looked into making this change, MAKEINFO=true, inside the .cfg
files based on the information contained in the following link, but I have
not yet done so.  (Found in a recent post in the user mailing list):

https://github.com/mdavidsaver/rsb/commit/f0bf5876ad96417db07a876845fbf833b10ced65



To cover my bases and do this as neatly as possible, I have deleted CentOS
7, recreated it, and run the following commands in this order:

$ su
# dhclient
# yum install git
# yum install wget
# yum group install "Development Tools"
# yum install autoconf automake binutils gcc gcc-c++ gdb make patch \ bison
flex xz unzip ncurses-devel zlib-devel python-devel git

*/ I removed texinfo from the previous command and installed it separately
following the instructions for 4.13 /*

# cd ~
# mkdir -p Downloads
# cd Downloads
# wget http://ftp.gnu.org/gnu/texinfo/texinfo-4.13.tar.gz
# tar -xzf texinfo-4.13.tar.gz
# cd texinfo-4.13
# ./configure --prefix=$HOME/development/texinfo-4.13
# make
# make install
# export PATH=$HOME/development/texinfo-4.13/bin:$PATH

# cd
# mkdir -p development/rtems/rsb
# cd development/rtems/rsb
# git clone git://git.rtems.org/rtems-source-builder.git
# cd rtems-source-builder
# cd rtems
#../source-builder/sb-set-builder --prefix=$HOME/development/rtems/5
5/rtems-sparc


Annnd, fail


The output is in a slightly different order this time, but it's still
crashing at

building: sparc-rtems5-gcc-7.3.0-newlib-3.0.0-x86_64-linux-gnu-1


At this point, I'm assuming I'm missing something completely asinine


Thanks for the help!
-Chris
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

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

2018-04-13 Thread JunBeom Kim (EmbedCoreTech)

Dear Sebastian,

I guess that GT timer interrupt 29 is correct.

timer {
compatible = "arm,armv7-timer";
interrupt-parent = <&intc>;
interrupts = ,
 ,
 ,
 ;
clock-frequency = <800>;
};

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)  
Sent: Friday, April 13, 2018 5:05 PM
To: 'Sebastian Huber' ; '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 : 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)  
Sent: Thursday, April 12, 2018 5:11 PM
To: 'Sebastian Huber' ; '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 = &uart5;
};


< imx7s.dtsi : added clock_frequency >
timer {
compatible = "arm,armv7-timer";
interrupt-parent = <&intc>;
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
Sent: Wednesday, April 11, 2018 2:07 PM
To: 'Sebastian Huber' ; '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) 
Sent: Wednesday, April 11, 2018 12:34 AM
To: 'Sebastian Huber' ; '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,

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

2018-04-13 Thread 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)  
Sent: Thursday, April 12, 2018 5:11 PM
To: 'Sebastian Huber' ; '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 = &uart5;
};


< imx7s.dtsi : added clock_frequency >
timer {
compatible = "arm,armv7-timer";
interrupt-parent = <&intc>;
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
Sent: Wednesday, April 11, 2018 2:07 PM
To: 'Sebastian Huber' ; '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) 
Sent: Wednesday, April 11, 2018 12:34 AM
To: 'Sebastian Huber' ; '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) 
Sent: Wednesday, April 11, 2018 12:08 AM
To: 'Sebastian Huber' ; '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";
devic

Re: Trouble with Quick Start build on CentOS 7 and Ubuntu

Trouble with Quick Start build on CentOS 7 and Ubuntu

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

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

4 matches

Site Navigation

Mail list logo

Footer information