date:20170210

Re: [PATCH 7/9] Patching STTY command for use in RTEMS

2017-02-10 Thread Christian Mauderer

Hello Kevin,

Am 09.02.2017 um 22:51 schrieb Kirspel, Kevin:
> Before or after the "Build the libbsd without optimization." step, I would 
> add a statement about fixing up any compilation errors.  Maybe most commands 
> will compile after making the changes listed previously but I had to fixup 
> errors related to termios differences between RTEMS and FREEBSD.  Besides 
> that, the instructions were fine and I got the suspected output. 

OK. So in general it worked. That is good to know. Do you want to add
this information to the documentation or should I create a patch?

> 
> I didn't realize the files were being changed to executables.  I edit the 
> files from a windows application running over a Samba share.  I'll check and 
> see if samba is making the change on save.

I assumed such a problem. Also it's just a detail.

> 
> I will fix the tabs.  Sometimes I forget to change my editor settings for the 
> different files I am working on.

Thanks.

> 
> There is an issue with the getopt_r() function.  Even if you initialize the 
> optind value to 1 the getopt_r() function returns '?'.  So you get past the 
> strspn() check but fail the getopt_r() call.  If you initialize the optind 
> value to 0, you get the right return value but the optind is wrong for the 
> strspn() call.  If you change the original code to the following, then it 
> will also work:
> 
> if (strspn(argv[optind == 0 ? 1 : optind], "-aefg") == strlen(argv[optind == 
> 0 ? 1 : optind])

OK. So if I understand you correctly, only the first value is really
wrong but the optind will have the correct value for the further
processing farther below. That was my main concern.

> 
> Kevin Kirspel
> Electrical Engineer - Sr. Staff
> Idexx Roswell
> 235 Hembree Park Drive
> Roswell GA 30076
> Tel: (770)-510- ext. 81642
> Direct: (770)-688-1642
> Fax: (770)-510-4445
> 
> -Original Message-
> From: Christian Mauderer [mailto:christian.maude...@embedded-brains.de] 
> Sent: Thursday, February 09, 2017 3:36 PM
> To: Kirspel, Kevin 
> Cc: RTEMS Devel 
> Subject: Re: [PATCH 7/9] Patching STTY command for use in RTEMS
> 
> Hello Kevin,
> 
> thanks for your work.
> 
> Out of curiosity: It seems that you are one of the first users of the new 
> porting process for user space applications (beneath Sebastian and me). Did 
> you encounter any problems that might be worth adding to the guide in 
> libbsd.txt?
> 
> Beneath that please see my remarks below.
> 
> Kind regards
> 
> Christian
> 
> - Ursprüngliche Mail -
>> Von: "Kevin Kirspel" 
>> An: "RTEMS Devel" 
>> Gesendet: Donnerstag, 9. Februar 2017 04:21:38
>> Betreff: [PATCH 7/9] Patching STTY command for use in RTEMS
> 
> [...]
>> diff --git a/freebsd/bin/stty/stty.c b/freebsd/bin/stty/stty.c old 
>> mode 100644 new mode 100755
> 
> You made the files executable. It would be better, if you could avoid that. 
> Please note that this is also true for a lot of other sources in your patches.
> 
>> index 54c63f6..3999a7f
>> --- a/freebsd/bin/stty/stty.c
>> +++ b/freebsd/bin/stty/stty.c
>> @@ -1,5 +1,8 @@
>> #include 
>>
>> +#ifdef __rtems__
>> +#include "rtems-bsd-stty-namespace.h"
>> +#endif /* __rtems__ */
>> /*-
>>  * Copyright (c) 1989, 1991, 1993, 1994
>>  *   The Regents of the University of California.  All rights reserved.
>> @@ -43,6 +46,12 @@ static char sccsid[] = "@(#)stty.c8.3 (Berkeley) 
>> 4/2/94";
>> #include 
>> __FBSDID("$FreeBSD$");
>>
>> +#ifdef __rtems__
>> +#define __need_getopt_newlib
>> +#include 
>> +#include  #include 
>> + #endif /* __rtems__ */
>> #include 
>>
>> #include 
>> @@ -57,20 +66,56 @@ __FBSDID("$FreeBSD$");
>>
>> #include "stty.h"
>> #include "extern.h"
>> +#ifdef __rtems__
>> +#include "rtems-bsd-stty-stty-data.h"
>> +#endif /* __rtems__ */
>> +
>> +#ifdef __rtems__
>> +static int main(int argc, char *argv[]);
>> +
>> +RTEMS_LINKER_RWSET(bsd_prog_stty, char);
>>
>> int
>> +rtems_bsd_command_stty(int argc, char *argv[]) {
>> +  int exit_code;
>> +  void *data_begin;
>> +  size_t data_size;
>> +
>> +  data_begin = RTEMS_LINKER_SET_BEGIN(bsd_prog_stty);
>> +  data_size = RTEMS_LINKER_SET_SIZE(bsd_prog_stty);
>> +
>> +  rtems_bsd_program_lock();
>> +  exit_code = rtems_bsd_program_call_main_with_data_restore("stty",
>> +  main, argc, argv, data_begin, data_size);  
>> + rtems_bsd_program_unlock();
>> +
>> +  return exit_code;
>> +}
> 
> In most (all?) places the libbsd uses BSD coding style. This is especially 
> true for code that is inserted into existing BSD code. In this case that 
> means one tab instead of two spaces. I also noted that on some of the other 
> patches in the patch set.
> 
>> +#endif /* __rtems__ */
>> +int
>> main(int argc, char *argv[])
>> {
>>  struct info i;
>>  enum FMT fmt;
>>  int ch;
>>  const char *file, *errstr = NULL;
>> +#ifdef __rtems__
>> +struct getopt_data getopt_data;
>> +memset(&getopt_data, 0, sizeof(getopt_data)); #define optind 
>> +getopt_data.optind #define optarg getopt_data

Re: x86_64 support?

2017-02-10 Thread Jan Sommer


Am 2017-02-09 22:07, schrieb Chris Johns:

On 10/02/2017 02:22, Joel Sherrill wrote:

On Feb 9, 2017 7:29 AM, "Jan Sommer" mailto:soja-li...@aries.uberspace.de>> wrote:

Hello,

As far as I see there is no support for x86_64 yet. I found that
there was a GSoC proposal to add BSP for the architecture, but I 
am

not sure if it was accepted.

Does someone know what is the current status of 64bit support and
what would be missing for a working BSP with a PCI and clock 
driver?



[...]


I recently updated the x86_64 project ticket and I suggest checking it 
...


 https://devel.rtems.org/ticket/2898



Thank you for all the information. I am not sure that we have the 
experience for such a project available atm.
I am not that familiar with the details of x86, but would it be possible 
to run a i386-BSP-application on a 64bit-CPU (e.g. something like 
http://www.systerra.de/documents/IDAN-CMA24GS_DS1.pdf)?
Given that we don't need any 64bit features, is it much work to start an 
RTEMS application in the 32bit compatibility mode?



Best regards

   Jan


The project and tasks are listed in the ticket. An important issue is
support for Intel's ACPICA code. Handling all the tables a modern BIOS
creates is lots of work without the Intel code. I think FreeBSD's
version is a good start. The same goes for UEFI run-time support.

We also need to examine the effect the change has on any hyper-visors
or partitioning wrappers that support RTEMS. I would like to see the
32bit i386 BSP removed from the source tree.

Chris

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

RE: [PATCH 7/9] Patching STTY command for use in RTEMS

2017-02-10 Thread Kirspel, Kevin

I can include the libbsd.txt updates in my updated patches.

If you want getopt_r() to match FREEBSD, it needs to be updated so that it 
works correctly when optind is initialized to 1 or 0. 

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

-Original Message-
From: Christian Mauderer [mailto:christian.maude...@embedded-brains.de] 
Sent: Friday, February 10, 2017 6:04 AM
To: Kirspel, Kevin 
Cc: RTEMS Devel 
Subject: Re: [PATCH 7/9] Patching STTY command for use in RTEMS

Hello Kevin,

Am 09.02.2017 um 22:51 schrieb Kirspel, Kevin:
> Before or after the "Build the libbsd without optimization." step, I would 
> add a statement about fixing up any compilation errors.  Maybe most commands 
> will compile after making the changes listed previously but I had to fixup 
> errors related to termios differences between RTEMS and FREEBSD.  Besides 
> that, the instructions were fine and I got the suspected output. 

OK. So in general it worked. That is good to know. Do you want to add this 
information to the documentation or should I create a patch?

> 
> I didn't realize the files were being changed to executables.  I edit the 
> files from a windows application running over a Samba share.  I'll check and 
> see if samba is making the change on save.

I assumed such a problem. Also it's just a detail.

> 
> I will fix the tabs.  Sometimes I forget to change my editor settings for the 
> different files I am working on.

Thanks.

> 
> There is an issue with the getopt_r() function.  Even if you initialize the 
> optind value to 1 the getopt_r() function returns '?'.  So you get past the 
> strspn() check but fail the getopt_r() call.  If you initialize the optind 
> value to 0, you get the right return value but the optind is wrong for the 
> strspn() call.  If you change the original code to the following, then it 
> will also work:
> 
> if (strspn(argv[optind == 0 ? 1 : optind], "-aefg") == 
> strlen(argv[optind == 0 ? 1 : optind])

OK. So if I understand you correctly, only the first value is really wrong but 
the optind will have the correct value for the further processing farther 
below. That was my main concern.

> 
> Kevin Kirspel
> Electrical Engineer - Sr. Staff
> Idexx Roswell
> 235 Hembree Park Drive
> Roswell GA 30076
> Tel: (770)-510- ext. 81642
> Direct: (770)-688-1642
> Fax: (770)-510-4445
> 
> -Original Message-
> From: Christian Mauderer 
> [mailto:christian.maude...@embedded-brains.de]
> Sent: Thursday, February 09, 2017 3:36 PM
> To: Kirspel, Kevin 
> Cc: RTEMS Devel 
> Subject: Re: [PATCH 7/9] Patching STTY command for use in RTEMS
> 
> Hello Kevin,
> 
> thanks for your work.
> 
> Out of curiosity: It seems that you are one of the first users of the new 
> porting process for user space applications (beneath Sebastian and me). Did 
> you encounter any problems that might be worth adding to the guide in 
> libbsd.txt?
> 
> Beneath that please see my remarks below.
> 
> Kind regards
> 
> Christian
> 
> - Ursprüngliche Mail -
>> Von: "Kevin Kirspel" 
>> An: "RTEMS Devel" 
>> Gesendet: Donnerstag, 9. Februar 2017 04:21:38
>> Betreff: [PATCH 7/9] Patching STTY command for use in RTEMS
> 
> [...]
>> diff --git a/freebsd/bin/stty/stty.c b/freebsd/bin/stty/stty.c old 
>> mode 100644 new mode 100755
> 
> You made the files executable. It would be better, if you could avoid that. 
> Please note that this is also true for a lot of other sources in your patches.
> 
>> index 54c63f6..3999a7f
>> --- a/freebsd/bin/stty/stty.c
>> +++ b/freebsd/bin/stty/stty.c
>> @@ -1,5 +1,8 @@
>> #include 
>>
>> +#ifdef __rtems__
>> +#include "rtems-bsd-stty-namespace.h"
>> +#endif /* __rtems__ */
>> /*-
>>  * Copyright (c) 1989, 1991, 1993, 1994
>>  *   The Regents of the University of California.  All rights reserved.
>> @@ -43,6 +46,12 @@ static char sccsid[] = "@(#)stty.c8.3 (Berkeley) 
>> 4/2/94";
>> #include 
>> __FBSDID("$FreeBSD$");
>>
>> +#ifdef __rtems__
>> +#define __need_getopt_newlib
>> +#include 
>> +#include  #include 
>> + #endif /* __rtems__ */
>> #include 
>>
>> #include 
>> @@ -57,20 +66,56 @@ __FBSDID("$FreeBSD$");
>>
>> #include "stty.h"
>> #include "extern.h"
>> +#ifdef __rtems__
>> +#include "rtems-bsd-stty-stty-data.h"
>> +#endif /* __rtems__ */
>> +
>> +#ifdef __rtems__
>> +static int main(int argc, char *argv[]);
>> +
>> +RTEMS_LINKER_RWSET(bsd_prog_stty, char);
>>
>> int
>> +rtems_bsd_command_stty(int argc, char *argv[]) {
>> +  int exit_code;
>> +  void *data_begin;
>> +  size_t data_size;
>> +
>> +  data_begin = RTEMS_LINKER_SET_BEGIN(bsd_prog_stty);
>> +  data_size = RTEMS_LINKER_SET_SIZE(bsd_prog_stty);
>> +
>> +  rtems_bsd_program_lock();
>> +  exit_code = rtems_bsd_program_call_main_with_data_restore("stty",
>> +  main, argc, argv, data_begin, data_size); 
>> + rtems_bsd_program_unlock();
>> +
>> +  return exit_code;
>> +}
> 
> In

Building toolset for Beaglebone with RSB fails (for me).

2017-02-10 Thread Tanu Hari Dixit

Hello Devs,

I wanted to build the toolset for Beaglebone following the blog (
http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
).
However, the build failed.
I got the following message.

download:
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2 ->
sources/gcc-6-20160526.tar.bz2
download:
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2:
error: 
error: downloading
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2: all
paths have failed, giving up
Build FAILED
  See error report:
rsb-report-arm-rtems4.12-gcc-6-20160526-newlib-2.4.0.20160527-x86_64-linux-gnu-1.txt
error: downloading
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2: all
paths have failed, giving up
Build Set: Time 0:01:46.366099
Build FAILED

Probably, the link is broken.

It is probably using
rtems-source-builder/rtems/config/tools/rtems-gcc-6-20160526-newlib-2.4.0.20160527-1.cfg

which sets this url which ultimately is used by
rtems-source-builder/source-builder/config/gcc-common-1.cfg . Please
correct me if I am wrong.

How do I fix this? Is there something I am missing?

Thanks,
Tanu Hari Dixit.
RTEMS Tools Project - Source Builder Error Report
 Build: error: downloading 
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2: all 
paths have failed, giving up
 Command Line: ../source-builder/sb-set-builder --log=beagle.txt 
--prefix=/home/thd/development/rtems/4.12 devel/beagle.bset
 Python: 2.7.6 (default, Jun 22 2015, 17:58:13) [GCC 4.8.2]
 
https://github.com/bengras/rtems-source-builder.git/origin/c4db36683559bdb9facf6ea918ea1ba098aa11c6
 Linux thd-Inspiron-5537 3.19.0-68-generic #76~14.04.1-Ubuntu SMP Fri Aug 12 
11:46:25 UTC 2016 x86_64
Tail of the build log:
test -z "/home/thd/development/rtems/4.12/bin" || /bin/mkdir -p 
"/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/bin"
  /bin/sh ./libtool   --mode=install /usr/bin/install -c gprof 
'/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/bin/./arm-rtems4.12-gprof'
libtool: install: /usr/bin/install -c gprof 
/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/bin/./arm-rtems4.12-gprof
test -z "/home/thd/development/rtems/4.12/share/info" || /bin/mkdir -p 
"/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/share/info"
 /usr/bin/install -c -m 644 ../../binutils-2.26/gprof/gprof.info 
'/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/share/info'
 install-info 
--info-dir='/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/share/info'
 
'/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/share/info/gprof.info'
This is not dpkg install-info anymore, but GNU install-info
See the man page for ginstall-info for command line arguments
test -z "/home/thd/development/rtems/4.12/share/man/man1" || /bin/mkdir -p 
"/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/share/man/man1"
 /usr/bin/install -c -m 644 '../../binutils-2.26/gprof/gprof.1' 
'/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/share/man/man1/arm-rtems4.12-gprof.1'
make[5]: Leaving directory 
`/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1/build/gprof'
make[4]: Leaving directory 
`/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1/build/gprof'
make[3]: Leaving directory 
`/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1/build/gprof'
make[2]: Leaving directory 
`/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1/build/gprof'
make[2]: Entering directory 
`/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1/build/intl'
make[2]: Nothing to be done for `install'.
make[2]: Leaving directory 
`/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/ar

Re: Building toolset for Beaglebone with RSB fails (for me).

2017-02-10 Thread Joel Sherrill

GCC does not keep snapshots forever. Ben's instructions and git repo must
be behind the master at git.rtems.org. clone the repos from there, use the
master, and I believe his instructions will work.

Ben.. if you see this, maybe it is time to.merge some of your instructions
into the new Sphinx documentation in a section for BB users.

--joel

On Feb 10, 2017 2:04 PM, "Tanu Hari Dixit"  wrote:

> Hello Devs,
>
> I wanted to build the toolset for Beaglebone following the blog (
> http://www.shrike-systems.com/beagleboard-xm-beaglebone-
> black-and-everything-else-rtems-on-the-beagles.html).
> However, the build failed.
> I got the following message.
>
> download: ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-
> 20160526.tar.bz2 -> sources/gcc-6-20160526.tar.bz2
> download: ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-
> 20160526.tar.bz2: error:  pub/gcc/snapshots/6-20160526: No such file or directory>
> error: downloading ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-
> 20160526.tar.bz2: all paths have failed, giving up
> Build FAILED
>   See error report: rsb-report-arm-rtems4.12-gcc-6-20160526-newlib-2.4.0.
> 20160527-x86_64-linux-gnu-1.txt
> error: downloading ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-
> 20160526.tar.bz2: all paths have failed, giving up
> Build Set: Time 0:01:46.366099
> Build FAILED
>
> Probably, the link is broken.
>
> It is probably using rtems-source-builder/rtems/config/tools/rtems-gcc-6-
> 20160526-newlib-2.4.0.20160527-1.cfg
> which sets this url which ultimately is used by
> rtems-source-builder/source-builder/config/gcc-common-1.cfg . Please
> correct me if I am wrong.
>
> How do I fix this? Is there something I am missing?
>
> Thanks,
> Tanu Hari Dixit.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Building toolset for Beaglebone with RSB fails (for me).

2017-02-10 Thread Alan Cudmore

I need to do the same for the Pi. I also noticed the Pi BSP Readme is out
of date.
Joel, where would we put instructions in the Sphinx documentation for the
Pi and BB?

Alan


On Fri, Feb 10, 2017 at 3:24 PM, Joel Sherrill  wrote:

> GCC does not keep snapshots forever. Ben's instructions and git repo must
> be behind the master at git.rtems.org. clone the repos from there, use
> the master, and I believe his instructions will work.
>
> Ben.. if you see this, maybe it is time to.merge some of your instructions
> into the new Sphinx documentation in a section for BB users.
>
> --joel
>
> On Feb 10, 2017 2:04 PM, "Tanu Hari Dixit"  wrote:
>
>> Hello Devs,
>>
>> I wanted to build the toolset for Beaglebone following the blog (
>> http://www.shrike-systems.com/beagleboard-xm-beaglebone-bla
>> ck-and-everything-else-rtems-on-the-beagles.html).
>> However, the build failed.
>> I got the following message.
>>
>> download: ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-2016052
>> 6.tar.bz2 -> sources/gcc-6-20160526.tar.bz2
>> download: ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-2016052
>> 6.tar.bz2: error: > pub/gcc/snapshots/6-20160526: No such file or directory>
>> error: downloading ftp://gcc.gnu.org/pub/gcc/snap
>> shots/6-20160526/gcc-6-20160526.tar.bz2: all paths have failed, giving up
>> Build FAILED
>>   See error report: rsb-report-arm-rtems4.12-gcc-6
>> -20160526-newlib-2.4.0.20160527-x86_64-linux-gnu-1.txt
>> error: downloading ftp://gcc.gnu.org/pub/gcc/snap
>> shots/6-20160526/gcc-6-20160526.tar.bz2: all paths have failed, giving up
>> Build Set: Time 0:01:46.366099
>> Build FAILED
>>
>> Probably, the link is broken.
>>
>> It is probably using rtems-source-builder/rtems/con
>> fig/tools/rtems-gcc-6-20160526-newlib-2.4.0.20160527-1.cfg
>> which sets this url which ultimately is used by
>> rtems-source-builder/source-builder/config/gcc-common-1.cfg . Please
>> correct me if I am wrong.
>>
>> How do I fix this? Is there something I am missing?
>>
>> Thanks,
>> Tanu Hari Dixit.
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Building toolset for Beaglebone with RSB fails (for me).

2017-02-10 Thread Gedare Bloom

On Fri, Feb 10, 2017 at 3:27 PM, Alan Cudmore  wrote:
> I need to do the same for the Pi. I also noticed the Pi BSP Readme is out of
> date.
> Joel, where would we put instructions in the Sphinx documentation for the Pi
> and BB?
>
See also https://devel.rtems.org/ticket/2854

> Alan
>
>
> On Fri, Feb 10, 2017 at 3:24 PM, Joel Sherrill  wrote:
>>
>> GCC does not keep snapshots forever. Ben's instructions and git repo must
>> be behind the master at git.rtems.org. clone the repos from there, use the
>> master, and I believe his instructions will work.
>>
>> Ben.. if you see this, maybe it is time to.merge some of your instructions
>> into the new Sphinx documentation in a section for BB users.
>>
>> --joel
>>
>> On Feb 10, 2017 2:04 PM, "Tanu Hari Dixit"  wrote:
>>>
>>> Hello Devs,
>>>
>>> I wanted to build the toolset for Beaglebone following the blog
>>> (http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html).
>>> However, the build failed.
>>> I got the following message.
>>>
>>> download:
>>> ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2 ->
>>> sources/gcc-6-20160526.tar.bz2
>>> download:
>>> ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2:
>>> error: >> file or directory>
>>> error: downloading
>>> ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2: all
>>> paths have failed, giving up
>>> Build FAILED
>>>   See error report:
>>> rsb-report-arm-rtems4.12-gcc-6-20160526-newlib-2.4.0.20160527-x86_64-linux-gnu-1.txt
>>> error: downloading
>>> ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2: all
>>> paths have failed, giving up
>>> Build Set: Time 0:01:46.366099
>>> Build FAILED
>>>
>>> Probably, the link is broken.
>>>
>>> It is probably using
>>> rtems-source-builder/rtems/config/tools/rtems-gcc-6-20160526-newlib-2.4.0.20160527-1.cfg
>>> which sets this url which ultimately is used by
>>> rtems-source-builder/source-builder/config/gcc-common-1.cfg . Please correct
>>> me if I am wrong.
>>>
>>> How do I fix this? Is there something I am missing?
>>>
>>> Thanks,
>>> Tanu Hari Dixit.
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Building toolset for Beaglebone with RSB fails (for me).

2017-02-10 Thread Chris Johns

On 11/2/17 7:27 am, Alan Cudmore wrote:
> I need to do the same for the Pi. I also noticed the Pi BSP Readme is
> out of date. 
> Joel, where would we put instructions in the Sphinx documentation for
> the Pi and BB?

Please add a page under https://devel.rtems.org/wiki/Boards. Create a
page such as https://devel.rtems.org/wiki/Boards/Raspberry Pi and
https://devel.rtems.org/wiki/Boards/Beagle Boards and the Board level
page will update. Please use spaces etc so the list in the Board page is
readable.

The Board pages focus on the Board specific parts of running and
debugging RTEMS. These pages can focus on detail such as a board
versions, boot loaders, boot modes, debugging, debugging solutions
including commercial offerings successfully being used by users. This
information is more dynamic and always being updated.

The Board pages should avoid documenting setting up the RTEMS
eco-system, building tools, RTEMS and general application building. This
detail should be in the User manual and if there is something a board
needs we should review this and update the User manual.

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

Re: Building toolset for Beaglebone with RSB fails (for me).

2017-02-10 Thread Ben Gras

All,

I see, yes. Noted. I will try to find time for this soon but it may be a
little while.

Ben


On 02/10/2017 03:24 PM, Joel Sherrill wrote:
> GCC does not keep snapshots forever. Ben's instructions and git repo
> must be behind the master at git.rtems.org .
> clone the repos from there, use the master, and I believe his
> instructions will work. 
>
> Ben.. if you see this, maybe it is time to.merge some of your
> instructions into the new Sphinx documentation in a section for BB users.
>
> --joel
>
> On Feb 10, 2017 2:04 PM, "Tanu Hari Dixit"  > wrote:
>
> Hello Devs,
>
> I wanted to build the toolset for Beaglebone following the blog
> 
> (http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
> 
> ).
> However, the build failed.
> I got the following message.
>
> download:
> ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2
> 
> -> sources/gcc-6-20160526.tar.bz2
> download:
> ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2
> :
> error:  No such file or directory>
> error: downloading
> ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2
> :
> all paths have failed, giving up
> Build FAILED
>   See error report:
> 
> rsb-report-arm-rtems4.12-gcc-6-20160526-newlib-2.4.0.20160527-x86_64-linux-gnu-1.txt
> error: downloading
> ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2
> :
> all paths have failed, giving up
> Build Set: Time 0:01:46.366099
> Build FAILED
>
> Probably, the link is broken.
>
> It is probably using
> 
> rtems-source-builder/rtems/config/tools/rtems-gcc-6-20160526-newlib-2.4.0.20160527-1.cfg
>
> which sets this url which ultimately is used by
> rtems-source-builder/source-builder/config/gcc-common-1.cfg .
> Please correct me if I am wrong.
>
> How do I fix this? Is there something I am missing?
>
> Thanks,
> Tanu Hari Dixit.
>
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel
> 
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

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

Re: [PATCH 7/9] Patching STTY command for use in RTEMS

Re: x86_64 support?

RE: [PATCH 7/9] Patching STTY command for use in RTEMS

Building toolset for Beaglebone with RSB fails (for me).

Re: Building toolset for Beaglebone with RSB fails (for me).

Re: Building toolset for Beaglebone with RSB fails (for me).

Re: Building toolset for Beaglebone with RSB fails (for me).

Re: Building toolset for Beaglebone with RSB fails (for me).

Re: Building toolset for Beaglebone with RSB fails (for me).

9 matches

Site Navigation

Mail list logo

Footer information