Re: RSB build failure

[Vidushi Vashishth]

So it was a problem with the path variable.

Fixed it. The setup worked. Thanks!

On Sat, Mar 17, 2018 at 3:33 PM, Aditya Upadhyay <aadit0...@gmail.com>
wrote:

> install python-dev... Will solve the issue. If you are using ubuntu..
> sudo apt-get install python-dev.
>
> On Sat, Mar 17, 2018, 3:30 PM Amaan Cheval <amaan.che...@gmail.com> wrote:
>
>> Hi!
>>
>> > checking for python...
>> /Library/Frameworks/Python.framework/Versions/2.7/bin/python
>> > checking for python2.7... no
>> > configure: error: python is missing or unusable
>>
>> That looks like the problem (at least on the surface). macOS does come
>> with
>> Python built-in, but I don't believe that's good enough for development
>> (vague memories only of issues) - have you installed Python separately
>> too?
>>
>> If so, could you confirm that you have the python2.7 binary in your PATH
>> variable too?
>>
>> On Sat, Mar 17, 2018 at 3:24 PM Vidushi Vashishth <reachv...@gmail.com>
>> wrote:
>>
>> > Hello!
>>
>> > I was trying to set up the sparc/erc32 bsp on a new system and was
>> following the quickstart on the user manual. Though I have successfully
>> done this before, this time its throwing an error. PFA the rsb log file
>> with the error report. I was doing this to run the trace buffering
>> examples.
>>
>> > Why is the shell command /bin/sh -ex failing?
>>
>> > Regards,
>> > Vidushi
>> > ___
>> > 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: RSB build failure

[Aditya Upadhyay]

install python-dev... Will solve the issue. If you are using ubuntu..
sudo apt-get install python-dev.

On Sat, Mar 17, 2018, 3:30 PM Amaan Cheval <amaan.che...@gmail.com> wrote:

> Hi!
>
> > checking for python...
> /Library/Frameworks/Python.framework/Versions/2.7/bin/python
> > checking for python2.7... no
> > configure: error: python is missing or unusable
>
> That looks like the problem (at least on the surface). macOS does come with
> Python built-in, but I don't believe that's good enough for development
> (vague memories only of issues) - have you installed Python separately too?
>
> If so, could you confirm that you have the python2.7 binary in your PATH
> variable too?
>
> On Sat, Mar 17, 2018 at 3:24 PM Vidushi Vashishth <reachv...@gmail.com>
> wrote:
>
> > Hello!
>
> > I was trying to set up the sparc/erc32 bsp on a new system and was
> following the quickstart on the user manual. Though I have successfully
> done this before, this time its throwing an error. PFA the rsb log file
> with the error report. I was doing this to run the trace buffering
> examples.
>
> > Why is the shell command /bin/sh -ex failing?
>
> > Regards,
> > Vidushi
> > ___
> > 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: RSB build failure

[Amaan Cheval]

> Why is the shell command /bin/sh -ex failing?

That's likely because the "doit" script calls the configure script, which
errors out because it can't find python2.7, by the way.

On Sat, Mar 17, 2018 at 3:30 PM Amaan Cheval <amaan.che...@gmail.com> wrote:

> Hi!

> > checking for python...
> /Library/Frameworks/Python.framework/Versions/2.7/bin/python
> > checking for python2.7... no
> > configure: error: python is missing or unusable

> That looks like the problem (at least on the surface). macOS does come
with
> Python built-in, but I don't believe that's good enough for development
> (vague memories only of issues) - have you installed Python separately
too?

> If so, could you confirm that you have the python2.7 binary in your PATH
> variable too?

> On Sat, Mar 17, 2018 at 3:24 PM Vidushi Vashishth <reachv...@gmail.com>
> wrote:

> > Hello!

> > I was trying to set up the sparc/erc32 bsp on a new system and was
> following the quickstart on the user manual. Though I have successfully
> done this before, this time its throwing an error. PFA the rsb log file
> with the error report. I was doing this to run the trace buffering
> examples.

> > Why is the shell command /bin/sh -ex failing?

> > Regards,
> > Vidushi
> > ___
> > 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: RSB build failure

[Amaan Cheval]

Hi!

> checking for python...
/Library/Frameworks/Python.framework/Versions/2.7/bin/python
> checking for python2.7... no
> configure: error: python is missing or unusable

That looks like the problem (at least on the surface). macOS does come with
Python built-in, but I don't believe that's good enough for development
(vague memories only of issues) - have you installed Python separately too?

If so, could you confirm that you have the python2.7 binary in your PATH
variable too?

On Sat, Mar 17, 2018 at 3:24 PM Vidushi Vashishth <reachv...@gmail.com>
wrote:

> Hello!

> I was trying to set up the sparc/erc32 bsp on a new system and was
following the quickstart on the user manual. Though I have successfully
done this before, this time its throwing an error. PFA the rsb log file
with the error report. I was doing this to run the trace buffering
examples.

> Why is the shell command /bin/sh -ex failing?

> Regards,
> Vidushi
> ___
> 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

RSB build failure

[Vidushi Vashishth]

Hello!

I was trying to set up the sparc/erc32 bsp on a new system and was
following the quickstart on the user manual. Though I have successfully
done this before, this time its throwing an error. PFA the rsb log file
with the error report. I was doing this to run the trace buffering
examples.

Why is the shell command /bin/sh -ex failing?

Regards,
Vidushi
RTEMS Tools Project - Source Builder Error Report
 Build: error: building sparc-rtems5-gdb-8.0.1-x86_64-apple-darwin16.7.0-1
 Command Line: ../source-builder/sb-set-builder 
--prefix=/Users/vidushi/development/rtems/5 5/rtems-sparc
 Python: 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 12:01:12) [GCC 4.2.1 (Apple 
Inc. build 5666) (dot 3)]
 
git://git.rtems.org/rtems-source-builder.git/origin/4b3e0f8e3d6998b84a2503dd2e11578989b1672b
 Darwin Vidushis-MacBook-Air.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jan 
11 22:59:40 PST 2018; root:xnu-3789.73.8~1/RELEASE_X86_64 x86_64
Tail of the build log:
checking whether rawmemchr is declared without a macro... no
checking whether stpcpy is declared without a macro... yes
checking whether stpncpy is declared without a macro... yes
checking whether strchrnul is declared without a macro... no
checking whether strdup is declared without a macro... yes
checking whether strncat is declared without a macro... yes
checking whether strndup is declared without a macro... yes
checking whether strnlen is declared without a macro... yes
checking whether strpbrk is declared without a macro... yes
checking whether strsep is declared without a macro... yes
checking whether strcasestr is declared without a macro... yes
checking whether strtok_r is declared without a macro... yes
checking whether strerror_r is declared without a macro... yes
checking whether strsignal is declared without a macro... yes
checking whether strverscmp is declared without a macro... no
checking whether strstr works... yes
checking whether strtok_r is declared... (cached) yes
checking whether stat file-mode macros are broken... no
checking for mode_t... yes
checking for a thread-safe mkdir -p... 
../../../gdb-8.0.1/gdb/gnulib/../../install-sh -c -d
checking for struct timespec in ... yes
checking whether  uses 'inline' correctly... yes
checking for wint_t... yes
checking for alloca as a compiler built-in... yes
checking whether alphasort is declared without a macro... yes
checking whether closedir is declared without a macro... yes
checking whether dirfd is declared without a macro... yes
checking whether fdopendir is declared without a macro... yes
checking whether opendir is declared without a macro... yes
checking whether readdir is declared without a macro... yes
checking whether rewinddir is declared without a macro... yes
checking whether scandir is declared without a macro... yes
checking for dirfd... yes
checking whether dirfd is declared... (cached) yes
checking whether dirfd is a macro... no
checking whether // is distinct from /... (cached) no
checking for flexible array member... yes
checking whether conversion from 'int' to 'long double' works... yes
checking for working GNU fnmatch... no
checking whether isblank is declared... yes
checking whether isblank is declared... (cached) yes
checking whether frexp works... yes
checking whether frexpl is declared... yes
checking whether frexpl() can be used without linking with libm... yes
checking whether frexpl works... yes
checking whether gettimeofday clobbers localtime buffer... no
checking for gettimeofday with POSIX signature... yes
checking whether INT32_MAX < INTMAX_MAX... yes
checking whether INT64_MAX == LONG_MAX... yes
checking whether UINT32_MAX < UINTMAX_MAX... yes
checking whether UINT64_MAX == ULONG_MAX... yes
checking whether isnan(double) can be used without linking with libm... yes
checking whether isnan(long double) can be used without linking with libm... no
checking where to find the exponent in a 'long double'... word 2 bit 0
checking whether NAN macro works... yes
checking whether HUGE_VAL works... yes
checking whether acosf is declared without a macro... yes
checking whether acosl is declared without a macro... yes
checking whether asinf is declared without a macro... yes
checking whether asinl is declared without a macro... yes
checking whether atanf is declared without a macro... yes
checking whether atanl is declared without a macro... yes
checking whether cbrt is declared without a macro... yes
checking whether cbrtf is declared without a macro... yes
checking whether cbrtl is declared without a macro... yes
checking whether ceilf is declared without a macro... yes
checking whether ceill is declared without a macro... yes
checking whether copysign is declared without a macro... yes
checking whether copysignf is declared without a macro... yes
checking whether copysignl is declared without a macro... yes
checking whether cosf is declared without a macro... yes
checking whether cosl is declared without a macro... yes
checking whether coshf is declared without a

Re: RSB valid status check (was: Contribute to project)

[Abhinav Jain]

Sir,

I request you to please guide me whether I have done the task correctly or
not and if something more is to be modified in this.
If this is done correctly, please tell me how should I proceed further for
the memory management project, which I was discussing earlier.

Thanks and Regards
Abhinav Jain

On Feb 20, 2018 10:17 PM, "Abhinav Jain"  wrote:

> Sir,
>
> I have tried to incorporate the changes suggested by you.
> I request you to please check the new patch file and guide me if some more
> improvement is needed to be done.
>
> Thanks and Regards
> Abhinav Jain
>
>
>
> On Tue, Feb 20, 2018 at 8:27 PM, Abhinav Jain 
> wrote:
>
>> Sir,
>>
>> I will edit the current patch accordingly and will take care of this in
>> the future.
>>
>> Thanks and Regards
>> Abhinav Jain
>>
>> On Tue, Feb 20, 2018 at 7:31 PM, Gedare Bloom  wrote:
>>
>>> Oops, I should read my mail better. Thanks for breaking this out Chris.
>>> Abhinav,
>>>
>>> On Tue, Feb 20, 2018 at 1:12 AM, Abhinav Jain 
>>> wrote:
>>> > Sir,
>>> >
>>> > I have attached the patch file with this mail. I have tried to follow
>>> all
>>> > the conventions that were listed in the User Git page. I request you to
>>> > please check and guide me whether I have done it correctly or not or
>>> whether
>>> > something more is to be done.
>>> >
>>> I won't comment on the code, I'll let Chris do that. However, this
>>> patch has a few issues that should be addressed.
>>> 1. Use line breaks in your commit message. About 70-80 characters per
>>> line max, please.
>>> 2. The "short message" can omit "function added to", basically all
>>> patches add some code, so this is a bit redundant. You can just say
>>> "Check the validity ..."
>>> 3. The commit message should use "Closes #." somewhere, usually in
>>> the end of the commit, if it is fixing/closing a ticket.
>>> 4. The commit message may be less verbose, if the extra details about
>>> the change are already in the ticket.
>>> 5. Avoid adding extra white spaces randomly, e.g. hunk #2 of the
>>> patch, and avoid introducing white space new lines where one exists,
>>> creating 2 blank lines in a row.
>>> 6. You may like to try to get git-send-email to work for you. It is a
>>> little nicer for submitting patches to mailing list.
>>> https://devel.rtems.org/wiki/Developer/Git/Users#Configuring
>>> git-send-emailtouseGMail
>>>
>>> -Gedare
>>>
>>> > Thanks and Regards
>>> > Abhinav Jain
>>> >
>>> > On Tue, Feb 20, 2018 at 4:13 AM, Chris Johns  wrote:
>>> >>
>>> >> On 19/02/2018 21:19, Abhinav Jain wrote:
>>> >> > I have made the changes suggested by you in the code and hopefully,
>>> the
>>> >> > issue
>>> >> > will be resolved as if the .git file is not found in the directory,
>>> the
>>> >> > process
>>> >> > will not go ahead and hence the wrong git repository will not be
>>> >> > changed.
>>> >>
>>> >> Excellent. Please post for review.
>>> >>
>>> >> > I request to please guide me whether anything more is to be done in
>>> the
>>> >> > code or
>>> >> > should I proceed with a pull request.
>>> >>
>>> >> I assume you mean a github pull request. RTEMS uses patches sent to
>>> this
>>> >> list
>>> >> for review. The top page of the Wiki has a section called RTEMS
>>> Developer
>>> >> Information and in that section are links to User Git access and
>>> >> submitting
>>> >> patches. You can also attach the patch to the ticket.
>>> >>
>>> >> Chris
>>> >
>>> >
>>>
>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB valid status check (was: Contribute to project)

[Abhinav Jain]

Sir,

I have tried to incorporate the changes suggested by you.
I request you to please check the new patch file and guide me if some more
improvement is needed to be done.

Thanks and Regards
Abhinav Jain



On Tue, Feb 20, 2018 at 8:27 PM, Abhinav Jain  wrote:

> Sir,
>
> I will edit the current patch accordingly and will take care of this in
> the future.
>
> Thanks and Regards
> Abhinav Jain
>
> On Tue, Feb 20, 2018 at 7:31 PM, Gedare Bloom  wrote:
>
>> Oops, I should read my mail better. Thanks for breaking this out Chris.
>> Abhinav,
>>
>> On Tue, Feb 20, 2018 at 1:12 AM, Abhinav Jain 
>> wrote:
>> > Sir,
>> >
>> > I have attached the patch file with this mail. I have tried to follow
>> all
>> > the conventions that were listed in the User Git page. I request you to
>> > please check and guide me whether I have done it correctly or not or
>> whether
>> > something more is to be done.
>> >
>> I won't comment on the code, I'll let Chris do that. However, this
>> patch has a few issues that should be addressed.
>> 1. Use line breaks in your commit message. About 70-80 characters per
>> line max, please.
>> 2. The "short message" can omit "function added to", basically all
>> patches add some code, so this is a bit redundant. You can just say
>> "Check the validity ..."
>> 3. The commit message should use "Closes #." somewhere, usually in
>> the end of the commit, if it is fixing/closing a ticket.
>> 4. The commit message may be less verbose, if the extra details about
>> the change are already in the ticket.
>> 5. Avoid adding extra white spaces randomly, e.g. hunk #2 of the
>> patch, and avoid introducing white space new lines where one exists,
>> creating 2 blank lines in a row.
>> 6. You may like to try to get git-send-email to work for you. It is a
>> little nicer for submitting patches to mailing list.
>> https://devel.rtems.org/wiki/Developer/Git/Users#Configuring
>> git-send-emailtouseGMail
>>
>> -Gedare
>>
>> > Thanks and Regards
>> > Abhinav Jain
>> >
>> > On Tue, Feb 20, 2018 at 4:13 AM, Chris Johns  wrote:
>> >>
>> >> On 19/02/2018 21:19, Abhinav Jain wrote:
>> >> > I have made the changes suggested by you in the code and hopefully,
>> the
>> >> > issue
>> >> > will be resolved as if the .git file is not found in the directory,
>> the
>> >> > process
>> >> > will not go ahead and hence the wrong git repository will not be
>> >> > changed.
>> >>
>> >> Excellent. Please post for review.
>> >>
>> >> > I request to please guide me whether anything more is to be done in
>> the
>> >> > code or
>> >> > should I proceed with a pull request.
>> >>
>> >> I assume you mean a github pull request. RTEMS uses patches sent to
>> this
>> >> list
>> >> for review. The top page of the Wiki has a section called RTEMS
>> Developer
>> >> Information and in that section are links to User Git access and
>> >> submitting
>> >> patches. You can also attach the patch to the ticket.
>> >>
>> >> Chris
>> >
>> >
>>
>
>
From d2e4586b2b6886004287bd24e7cf7faf48926799 Mon Sep 17 00:00:00 2001
From: Abhinav Jain 
Date: Tue, 20 Feb 2018 21:54:44 +0530
Subject: [PATCH] Check the validity of git repository.

Earlier the function valid was checking the validity of the git repository,
the program was working in. For doing this the function was first checking
whether path exists or not and after that it was checking whether the
directory is a git repository or not and to do so, it
was relying on git status. Since the git status looks for the .git file in
the current directory and if not found it will look up in the tree and if finds
a .git file there it will return valid, which voids the purpose of use.
Now to solve this problem, a function _valid_repo_path is created to check
for the .git file and every function which looks for the validity of
git repository will call this function to check. Closes #2522
---
 source-builder/sb/git.py | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/source-builder/sb/git.py b/source-builder/sb/git.py
index be23396..0d139f9 100644
--- a/source-builder/sb/git.py
+++ b/source-builder/sb/git.py
@@ -38,9 +38,12 @@ class repo:
 if ec:
 raise error.general('git command failed (%s): %d' % (self.git, ec))
 
+def _valid_repo_path(self):
+	return path.exists(path.join(self.path, '.git'))
+
 def _run(self, args, check = False):
 e = execute.capture_execution()
-if path.exists(self.path):
+if _valid_repo_path():
 cwd = self.path
 else:
 cwd = None
@@ -122,7 +125,7 @@ class repo:
 
 def status(self, submodules_always_clean = False):
 _status = {}
-if path.exists(self.path):
+if _valid_repo_path():
 if submodules_always_clean:
 submodules = self.submodules()
 else:
@@ -166,7 +169,7 @@ class repo:
 return not 

Re: RSB valid status check (was: Contribute to project)

[Abhinav Jain]

Sir,

I will edit the current patch accordingly and will take care of this in the
future.

Thanks and Regards
Abhinav Jain

On Tue, Feb 20, 2018 at 7:31 PM, Gedare Bloom  wrote:

> Oops, I should read my mail better. Thanks for breaking this out Chris.
> Abhinav,
>
> On Tue, Feb 20, 2018 at 1:12 AM, Abhinav Jain 
> wrote:
> > Sir,
> >
> > I have attached the patch file with this mail. I have tried to follow all
> > the conventions that were listed in the User Git page. I request you to
> > please check and guide me whether I have done it correctly or not or
> whether
> > something more is to be done.
> >
> I won't comment on the code, I'll let Chris do that. However, this
> patch has a few issues that should be addressed.
> 1. Use line breaks in your commit message. About 70-80 characters per
> line max, please.
> 2. The "short message" can omit "function added to", basically all
> patches add some code, so this is a bit redundant. You can just say
> "Check the validity ..."
> 3. The commit message should use "Closes #." somewhere, usually in
> the end of the commit, if it is fixing/closing a ticket.
> 4. The commit message may be less verbose, if the extra details about
> the change are already in the ticket.
> 5. Avoid adding extra white spaces randomly, e.g. hunk #2 of the
> patch, and avoid introducing white space new lines where one exists,
> creating 2 blank lines in a row.
> 6. You may like to try to get git-send-email to work for you. It is a
> little nicer for submitting patches to mailing list.
> https://devel.rtems.org/wiki/Developer/Git/Users#Configuringgit-send-
> emailtouseGMail
>
> -Gedare
>
> > Thanks and Regards
> > Abhinav Jain
> >
> > On Tue, Feb 20, 2018 at 4:13 AM, Chris Johns  wrote:
> >>
> >> On 19/02/2018 21:19, Abhinav Jain wrote:
> >> > I have made the changes suggested by you in the code and hopefully,
> the
> >> > issue
> >> > will be resolved as if the .git file is not found in the directory,
> the
> >> > process
> >> > will not go ahead and hence the wrong git repository will not be
> >> > changed.
> >>
> >> Excellent. Please post for review.
> >>
> >> > I request to please guide me whether anything more is to be done in
> the
> >> > code or
> >> > should I proceed with a pull request.
> >>
> >> I assume you mean a github pull request. RTEMS uses patches sent to this
> >> list
> >> for review. The top page of the Wiki has a section called RTEMS
> Developer
> >> Information and in that section are links to User Git access and
> >> submitting
> >> patches. You can also attach the patch to the ticket.
> >>
> >> Chris
> >
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] rsb: Add '--patchdir' option description

[Maksim E. Kozlov]

According to commit d30be3129e9681a74efc80ce241aaf3c3a5b0efe in
rtems-source-builder repo.

Signed-off-by: Maksim E. Kozlov <maksim.e.koz...@gmail.com>
---
 rsb/commands.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/rsb/commands.rst b/rsb/commands.rst
index 3ef7772..ab338c1 100644
--- a/rsb/commands.rst
+++ b/rsb/commands.rst
@@ -31,6 +31,7 @@ This commands checks your system is set up correctly. Most 
options are ignored::
 --configdir path   : Path to the configuration directory, default: 
./config
 --builddir path: Path to the build directory, default: ./build
 --sourcedir path   : Path to the source directory, default: ./source
+--patchdir path: Path to the patches directory, default: ./patches
 --tmppath path : Path to the temp directory, default: ./tmp
 --macros file[,[file]  : Macro format files to load after the defaults
 --log file : Log file where all build out is written too
@@ -72,6 +73,7 @@ arguments. Most options are ignored::
 --configdir path   : Path to the configuration directory, default: 
./config
 --builddir path: Path to the build directory, default: ./build
 --sourcedir path   : Path to the source directory, default: ./source
+--patchdir path: Path to the patches directory, default: ./patches
 --tmppath path : Path to the temp directory, default: ./tmp
 --macros file[,[file]  : Macro format files to load after the defaults
 --log file : Log file where all build out is written too
@@ -109,6 +111,7 @@ This command builds a set::
 --configdir path   : Path to the configuration directory, default: 
./config
 --builddir path: Path to the build directory, default: ./build
 --sourcedir path   : Path to the source directory, default: ./source
+--patchdir path: Path to the patches directory, default: ./patches
 --tmppath path : Path to the temp directory, default: ./tmp
 --macros file[,[file]  : Macro format files to load after the defaults
 --log file : Log file where all build out is written too
@@ -196,6 +199,9 @@ The ``arguments`` are a list of build sets to build.
 ``--sourcedir path``:
   Path to the source directory. This overrides the default of +source+.
 
+``--patchdir path``:
+  Path to the patches directory. This overrides the default of +patches+.
+
 ``--tmppath path``:
   Path to the temporary directory. This overrides the default of +tmp+.
 
@@ -311,6 +317,7 @@ file. Configuration files have the extension of ``.cfg``::
 --configdir path   : Path to the configuration directory, default: 
./config
 --builddir path: Path to the build directory, default: ./build
 --sourcedir path   : Path to the source directory, default: ./source
+--patchdir path: Path to the patches directory, default: ./patches
 --tmppath path : Path to the temp directory, default: ./tmp
 --macros file[,[file]  : Macro format files to load after the defaults
 --log file : Log file where all build out is written too
-- 
1.9.1

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

Re: RSB valid status check (was: Contribute to project)

[Gedare Bloom]

Oops, I should read my mail better. Thanks for breaking this out Chris. Abhinav,

On Tue, Feb 20, 2018 at 1:12 AM, Abhinav Jain  wrote:
> Sir,
>
> I have attached the patch file with this mail. I have tried to follow all
> the conventions that were listed in the User Git page. I request you to
> please check and guide me whether I have done it correctly or not or whether
> something more is to be done.
>
I won't comment on the code, I'll let Chris do that. However, this
patch has a few issues that should be addressed.
1. Use line breaks in your commit message. About 70-80 characters per
line max, please.
2. The "short message" can omit "function added to", basically all
patches add some code, so this is a bit redundant. You can just say
"Check the validity ..."
3. The commit message should use "Closes #." somewhere, usually in
the end of the commit, if it is fixing/closing a ticket.
4. The commit message may be less verbose, if the extra details about
the change are already in the ticket.
5. Avoid adding extra white spaces randomly, e.g. hunk #2 of the
patch, and avoid introducing white space new lines where one exists,
creating 2 blank lines in a row.
6. You may like to try to get git-send-email to work for you. It is a
little nicer for submitting patches to mailing list.
https://devel.rtems.org/wiki/Developer/Git/Users#Configuringgit-send-emailtouseGMail

-Gedare

> Thanks and Regards
> Abhinav Jain
>
> On Tue, Feb 20, 2018 at 4:13 AM, Chris Johns  wrote:
>>
>> On 19/02/2018 21:19, Abhinav Jain wrote:
>> > I have made the changes suggested by you in the code and hopefully, the
>> > issue
>> > will be resolved as if the .git file is not found in the directory, the
>> > process
>> > will not go ahead and hence the wrong git repository will not be
>> > changed.
>>
>> Excellent. Please post for review.
>>
>> > I request to please guide me whether anything more is to be done in the
>> > code or
>> > should I proceed with a pull request.
>>
>> I assume you mean a github pull request. RTEMS uses patches sent to this
>> list
>> for review. The top page of the Wiki has a section called RTEMS Developer
>> Information and in that section are links to User Git access and
>> submitting
>> patches. You can also attach the patch to the ticket.
>>
>> Chris
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB valid status check (was: Contribute to project)

[Abhinav Jain]

Sir,

I have attached the patch file with this mail. I have tried to follow all
the conventions that were listed in the User Git page. I request you to
please check and guide me whether I have done it correctly or not or
whether something more is to be done.

Thanks and Regards
Abhinav Jain

On Tue, Feb 20, 2018 at 4:13 AM, Chris Johns  wrote:

> On 19/02/2018 21:19, Abhinav Jain wrote:
> > I have made the changes suggested by you in the code and hopefully, the
> issue
> > will be resolved as if the .git file is not found in the directory, the
> process
> > will not go ahead and hence the wrong git repository will not be changed.
>
> Excellent. Please post for review.
>
> > I request to please guide me whether anything more is to be done in the
> code or
> > should I proceed with a pull request.
>
> I assume you mean a github pull request. RTEMS uses patches sent to this
> list
> for review. The top page of the Wiki has a section called RTEMS Developer
> Information and in that section are links to User Git access and submitting
> patches. You can also attach the patch to the ticket.
>
> Chris
>
From 273baf1527f50ae6dd4832ddf9434a9f4630375a Mon Sep 17 00:00:00 2001
From: Abhinav Jain 
Date: Mon, 19 Feb 2018 15:35:59 +0530
Subject: [PATCH] Function added to check the validity of git repository.

Earlier the function valid was checking the validity of the git repository, the program was working in. For doing this the function was first checking whether path exists or not and after that it was checking whether the directory is a git repository or not and to do so, it
was relying on git status. The git status looks for the .git file in the current directory and if not found it will look up in the tree and if finds a .git file there it will return valid, which voids the purpose of use. 
Now to solve this problem, a function _valid_repo_path is created to check for the .git file and every function which looks for the validity of git repository will call this function to check. 

---
 source-builder/sb/git.py | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/source-builder/sb/git.py b/source-builder/sb/git.py
index be23396..82b23fb 100644
--- a/source-builder/sb/git.py
+++ b/source-builder/sb/git.py
@@ -38,9 +38,13 @@ class repo:
 if ec:
 raise error.general('git command failed (%s): %d' % (self.git, ec))
 
+   
+def _valid_repo_path(self):
+	return path.exists(path.join(self.path, '.git'))
+
 def _run(self, args, check = False):
 e = execute.capture_execution()
-if path.exists(self.path):
+if _valid_repo_path():
 cwd = self.path
 else:
 cwd = None
@@ -52,6 +56,7 @@ class repo:
 self._git_exit_code(exit_code)
 return exit_code, output
 
+
 def __init__(self, _path, opts = None, macros = None):
 self.path = _path
 self.opts = opts
@@ -122,7 +127,7 @@ class repo:
 
 def status(self, submodules_always_clean = False):
 _status = {}
-if path.exists(self.path):
+if _valid_repo_path():
 if submodules_always_clean:
 submodules = self.submodules()
 else:
@@ -166,7 +171,7 @@ class repo:
 return not (len(_status) == 1 and 'branch' in _status)
 
 def valid(self):
-if path.exists(self.path):
+if _valid_repo_path():
 ec, output = self._run(['status'])
 return ec == 0
 return False
-- 
1.9.1

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

Re: RSB valid status check (was: Contribute to project)

[Chris Johns]

On 19/02/2018 21:19, Abhinav Jain wrote:
> I have made the changes suggested by you in the code and hopefully, the issue
> will be resolved as if the .git file is not found in the directory, the 
> process
> will not go ahead and hence the wrong git repository will not be changed.

Excellent. Please post for review.

> I request to please guide me whether anything more is to be done in the code 
> or
> should I proceed with a pull request.

I assume you mean a github pull request. RTEMS uses patches sent to this list
for review. The top page of the Wiki has a section called RTEMS Developer
Information and in that section are links to User Git access and submitting
patches. You can also attach the patch to the ticket.

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

Re: RSB valid status check (was: Contribute to project)

[Abhinav Jain]

Sir,

I have made the changes suggested by you in the code and hopefully, the
issue will be resolved as if the .git file is not found in the directory,
the process will not go ahead and hence the wrong git repository will not
be changed.
I request to please guide me whether anything more is to be done in the
code or should I proceed with a pull request.

Thanks and Regards
Abhinav Jain

On Mon, Feb 19, 2018 at 3:10 AM, Chris Johns <chr...@rtems.org> wrote:

> Hi Abhinav
>
> I have broken the mail thread as we have switched from contributing to the
> project to a specific fix.
>
> > I have gone through the code concerning the issue raised. I also read
> about the
> > working of git status command and the problem that I am able to figure
> out is
> > that although the existing code is able to check whether the current
> path exists
> > or not but since it is relying on git status to check whether the .git
> file is
> > available or not, a problem is there. The git status checks the current
> > directory for the .git file but in case the current directory doesn't
> have the
> > .git file, it will look for it in the parent directory and if found
> there it
> > will return True, which voids the purpose.
> > So, I think, if a second check is given to validate whether the current
> > directory contains .git file or not will solve the issue.
> > So the code may be:
> > def valid(self):
> > if path.exists(self.path):
> > if path.exists(path.join(self.path, ".git")):
> >ec, output = self._run(['status'])
> >return ec == 0
> > return False
> > I request you to please guide me whether I proceeded in a right way or
> not.
>
> I am a little confused by the situation that leads to this happening. If
> the RSB
> is being run from a git repo and the build references a git repo the RSB
> will
> clone and update the repo so a 'valid' check to repo within the RSB's clone
> should not fail. This is happening because it has been working for a long
> time.
> I can see this happening if someone plays the source/git tree of files or
> maybe
> a clone failed for some reason and a directory is left. Maybe git does
> that.
>
> To make things more robust a check for the .git directory makes sense.
> There is
> no need to check the path twice, a single check is all that is needed. I
> suggest
> a new function be added to the class call '_valid_repo_path' which is:
>
> def _valid_repo_path(self):
> return path.exists(path.join(self.path, '.git')
>
> and all 'path.exists(self.path)' in the class be replaced by this call.
>
> Thanks
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RSB valid status check (was: Contribute to project)

[Chris Johns]

Hi Abhinav

I have broken the mail thread as we have switched from contributing to the
project to a specific fix.

> I have gone through the code concerning the issue raised. I also read about 
> the
> working of git status command and the problem that I am able to figure out is
> that although the existing code is able to check whether the current path 
> exists
> or not but since it is relying on git status to check whether the .git file is
> available or not, a problem is there. The git status checks the current
> directory for the .git file but in case the current directory doesn't have the
> .git file, it will look for it in the parent directory and if found there it
> will return True, which voids the purpose.
> So, I think, if a second check is given to validate whether the current
> directory contains .git file or not will solve the issue.
> So the code may be:
> def valid(self):
> if path.exists(self.path):
> if path.exists(path.join(self.path, ".git")):
>ec, output = self._run(['status'])
>return ec == 0
> return False
> I request you to please guide me whether I proceeded in a right way or not.

I am a little confused by the situation that leads to this happening. If the RSB
is being run from a git repo and the build references a git repo the RSB will
clone and update the repo so a 'valid' check to repo within the RSB's clone
should not fail. This is happening because it has been working for a long time.
I can see this happening if someone plays the source/git tree of files or maybe
a clone failed for some reason and a directory is left. Maybe git does that.

To make things more robust a check for the .git directory makes sense. There is
no need to check the path twice, a single check is all that is needed. I suggest
a new function be added to the class call '_valid_repo_path' which is:

def _valid_repo_path(self):
return path.exists(path.join(self.path, '.git')

and all 'path.exists(self.path)' in the class be replaced by this call.

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

[PATCH] gcc: Use the RSB release for released tools.

[Chris Johns]

Using the RSB release version for the gcc version string means the
tools have a version string that matches the release.

Close #3294
---
 rtems/config/rtems-base.bset   | 3 ++-
 source-builder/config/gcc-common-1.cfg | 9 +
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/rtems/config/rtems-base.bset b/rtems/config/rtems-base.bset
index 04c9679..5a7cc98 100644
--- a/rtems/config/rtems-base.bset
+++ b/rtems/config/rtems-base.bset
@@ -20,7 +20,8 @@ package: rtems-%{rtems_version}-%{_target}-%{_host}-%{release}
 #
 # Project custom message
 #
-%define gcc_version_message RTEMS %{rtems_version}, RSB %{_sbgit_id}, Newlib 
%{newlib_version}
+%define rtems_gcc_version %{rtems_version}
+%define gcc_version_message RTEMS %{rtems_gcc_version}, RSB %{_sbgit_id}, 
Newlib %{newlib_version}
 
 #
 # Pick up the RTEMS URLs.
diff --git a/source-builder/config/gcc-common-1.cfg 
b/source-builder/config/gcc-common-1.cfg
index c04c243..03d84bc 100644
--- a/source-builder/config/gcc-common-1.cfg
+++ b/source-builder/config/gcc-common-1.cfg
@@ -38,6 +38,15 @@ BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
  %define with_lto 0
 %endif
 
+#
+# The GCC version depends on the type of build we are doing.
+#
+%if %{rsb_released}
+ %define rtems_gcc_version %{rsb_version}
+%else
+ %define rtems_gcc_version %{rtems_version}
+%endif
+
 #
 # Prepare the source code.
 #
-- 
2.14.1

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

[PATCH] gcc: Use the RSB release for released tools.

[Chris Johns]

Using the RSB release version for the gcc version string means the
tools have a version string that matches the release.

Close #3293
---
 rtems/config/rtems-base.bset   | 3 ++-
 source-builder/config/gcc-common-1.cfg | 9 +
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/rtems/config/rtems-base.bset b/rtems/config/rtems-base.bset
index 04c9679..5a7cc98 100644
--- a/rtems/config/rtems-base.bset
+++ b/rtems/config/rtems-base.bset
@@ -20,7 +20,8 @@ package: rtems-%{rtems_version}-%{_target}-%{_host}-%{release}
 #
 # Project custom message
 #
-%define gcc_version_message RTEMS %{rtems_version}, RSB %{_sbgit_id}, Newlib 
%{newlib_version}
+%define rtems_gcc_version %{rtems_version}
+%define gcc_version_message RTEMS %{rtems_gcc_version}, RSB %{_sbgit_id}, 
Newlib %{newlib_version}
 
 #
 # Pick up the RTEMS URLs.
diff --git a/source-builder/config/gcc-common-1.cfg 
b/source-builder/config/gcc-common-1.cfg
index 0bf59b6..eafd958 100644
--- a/source-builder/config/gcc-common-1.cfg
+++ b/source-builder/config/gcc-common-1.cfg
@@ -41,6 +41,15 @@ BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
 #
 %define disable_MAKEINFO 1
 
+#
+# The GCC version depends on the type of build we are doing.
+#
+%if %{rsb_released}
+ %define rtems_gcc_version %{rsb_version}
+%else
+ %define rtems_gcc_version %{rtems_version}
+%endif
+
 #
 # Prepare the source code.
 #
-- 
2.14.1

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

[PATCH] gcc: Use the RSB release for released tools.

[Chris Johns]

Using the RSB release version for the gcc version string means the
tools have a version string that matches the release.

Close #3074
---
 rtems/config/rtems-base.bset   | 3 ++-
 source-builder/config/gcc-common-1.cfg | 9 +
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/rtems/config/rtems-base.bset b/rtems/config/rtems-base.bset
index 0e61423..48f4218 100644
--- a/rtems/config/rtems-base.bset
+++ b/rtems/config/rtems-base.bset
@@ -15,7 +15,8 @@ package: rtems-%{rtems_version}-%{_target}-%{_host}-%{release}
 #
 # Project custom message
 #
-%define gcc_version_message RTEMS %{rtems_version}, RSB %{_sbgit_id}, Newlib 
%{newlib_version}
+%define rtems_gcc_version %{rtems_version}
+%define gcc_version_message RTEMS %{rtems_gcc_version}, RSB %{_sbgit_id}, 
Newlib %{newlib_version}
 
 #
 # Pick up the RTEMS URLs.
diff --git a/source-builder/config/gcc-common-1.cfg 
b/source-builder/config/gcc-common-1.cfg
index ec81d9b..9154026 100644
--- a/source-builder/config/gcc-common-1.cfg
+++ b/source-builder/config/gcc-common-1.cfg
@@ -31,6 +31,15 @@ BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
 #
 %global _gcclibdir %{_prefix}/lib
 
+#
+# The GCC version depends on the type of build we are doing.
+#
+%if %{rsb_released}
+ %define rtems_gcc_version %{rsb_version}
+%else
+ %define rtems_gcc_version %{rtems_version}
+%endif
+
 #
 # Prepare the source code.
 #
-- 
2.14.1

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

[PATCH] rsb: Minor fixes.

[Chris Johns]

Close #2910
---
 rsb/hosts.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/rsb/hosts.rst b/rsb/hosts.rst
index ba565d5..a4226f3 100644
--- a/rsb/hosts.rst
+++ b/rsb/hosts.rst
@@ -156,7 +156,7 @@ Mavericks
 
 The RSB works on Mavericks and the GNU tools can be built for RTEMS using the
 Mavericks clang LLVM tool chain. You will need to build and install a couple of
-packages to make the RSB pass the +sb-check+. These are CVS and XZ. You can get
+packages to make the RSB pass the ``sb-check``. These are CVS and XZ. You can 
get
 these tools from a packaging tool for MacOS such as *MacPorts* or *HomeBrew*.
 
 I do not use 3rd party packaging on MacOS and prefer to build the packages from
@@ -165,8 +165,8 @@ however they sometimes bring in extra dependence and that 
complicates my build
 environment and I want to know the minimal requirements when building
 tools. The following are required:
 
-. The XZ package's home page is http://tukaani.org/xz/ and I use version
-  5.0.5. XZ builds and installs cleanly.
+#. The XZ package's home page is http://tukaani.org/xz/ and I use version
+   5.0.5. XZ builds and installs cleanly.
 
 Serria
 ~~
-- 
2.14.1

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

[PATCH] sb: Backport from 4.11 the --rsb-file with releases fixes.

[Chris Johns]

Close #3286
---
 source-builder/sb/download.py | 16 ++--
 source-builder/sb/options.py  | 89 ++-
 source-builder/sb/version.py  | 24 +---
 3 files changed, 86 insertions(+), 43 deletions(-)

diff --git a/source-builder/sb/download.py b/source-builder/sb/download.py
index 32d801b..6c2593f 100644
--- a/source-builder/sb/download.py
+++ b/source-builder/sb/download.py
@@ -26,6 +26,7 @@ from __future__ import print_function
 
 import hashlib
 import os
+import re
 import stat
 import sys
 try:
@@ -301,6 +302,11 @@ parsers = { 'http': _http_parser,
 'cvs':  _cvs_parser,
 'file': _file_parser }
 
+def set_release_path(release_path, macros):
+if release_path is None:
+release_path = '%{rtems_release_url}/%{rsb_version}/sources'
+macros.define('release_path', release_path)
+
 def parse_url(url, pathkey, config, opts, file_override = None):
 #
 # Split the source up into the parts we need.
@@ -318,7 +324,6 @@ def parse_url(url, pathkey, config, opts, file_override = 
None):
 bad_chars = [c for c in ['/', '\\', '?', '*'] if c in file_override]
 if len(bad_chars) > 0:
 raise error.general('bad characters in file name: %s' % 
(file_override))
-
 log.output('download: file-override: %s' % (file_override))
 source['file'] = file_override
 source['options'] += ['file-override']
@@ -591,10 +596,9 @@ def get_file(url, local, opts, config):
 #
 url_bases = opts.urls()
 try:
-rtems_release_url_value = 
config.macros.expand('%{rtems_release_url}/%{rsb_version}/sources')
+rtems_release_url_value = config.macros.expand('%{release_path}')
 except:
 rtems_release_url_value = None
-log.output('RTEMS release URL could not be expanded')
 rtems_release_url = None
 if version.released() and rtems_release_url_value:
 rtems_release_url = rtems_release_url_value
@@ -637,6 +641,12 @@ def get_file(url, local, opts, config):
 url_file = url_path[slash + 1:]
 log.trace('url_file: %s' %(url_file))
 for base in url_bases:
+#
+# Hack to fix #3064 where --rsb-file is being used. This code is a
+# mess and should be refactored.
+#
+if version.released() and base == rtems_release_url:
+url_file = path.basename(local)
 if base[-1:] != '/':
 base += '/'
 next_url = urllib_parse.urljoin(base, url_file)
diff --git a/source-builder/sb/options.py b/source-builder/sb/options.py
index 7791329..7bbdd8c 100644
--- a/source-builder/sb/options.py
+++ b/source-builder/sb/options.py
@@ -54,34 +54,35 @@ class command_line:
 def __init__(self, argv, optargs, _defaults, command_path):
 self._long_opts = {
 # key macrohandler
param  defs   init
-'--prefix' : ('_prefix',   self._lo_path, 
True,  None,  False),
-'--topdir' : ('_topdir',   self._lo_path, 
True,  None,  False),
-'--configdir'  : ('_configdir',self._lo_path, 
True,  None,  False),
-'--builddir'   : ('_builddir', self._lo_path, 
True,  None,  False),
-'--sourcedir'  : ('_sourcedir',self._lo_path, 
True,  None,  False),
-'--tmppath': ('_tmppath',  self._lo_path, 
True,  None,  False),
-'--jobs'   : ('_jobs', self._lo_jobs, 
True,  'max', True),
-'--log': ('_logfile',  self._lo_string,   
True,  None,  False),
-'--url': ('_url_base', self._lo_string,   
True,  None,  False),
-'--no-download': ('_disable_download', self._lo_bool, 
False, '0',   True),
-'--macros' : ('_macros',   self._lo_string,   
True,  None,  False),
-'--targetcflags'   : ('_targetcflags', self._lo_string,   
True,  None,  False),
-'--targetcxxflags' : ('_targetcxxflags',   self._lo_string,   
True,  None,  False),
-'--libstdcxxflags' : ('_libstdcxxflags',   self._lo_string,   
True,  None,  False),
-'--force'  : ('_force',self._lo_bool, 
False, '0',   True),
-'--quiet'  : ('_quiet',self._lo_bool, 
False, '0',   True),
-'--trace'  : ('_trace',self._lo_bool, 
False, '0',   True),
-'--dry-run': ('_dry_run',  self._lo_bool, 
False, '0',   True),
-'--warn-all'   : ('_warn_all', self._lo_bool, 
False, '0',   True),
-'--no-clean'   : ('_no_clean', self._lo_bool, 
False, '0',   True),
-'--keep-going' : ('_keep_going',   self._lo_bool, 
False,

[PATCH 4.10] Backport --rsb-file support for releases.

[Chris Johns]

Add for long term support.

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

[4.11] RSB Fixes to fetch GCC parts from GNU's FTP server

[Chris Johns]

Hi,

These patches fix the initial patch to move to GNU's FTP site for 
the GGC parts used to build GCC. 

The patches back port from master the orphans check plus some
SB modules needed to support the checker. It also includes the
removal of unused RTEMS tools configurations and finally all
references to MPC are set to 1.0.3.

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

Re: RSB release's default mode for building kernels

[Sebastian Huber]

On 16/01/18 23:35, Joel Sherrill wrote:



On Tue, Jan 16, 2018 at 4:27 PM, Chris Johns > wrote:


Hi,

The current mode on all release branches is to build the RTEMS
kernel. The
purpose was to have a single command that builds the tools and
RTEMS. However
this means all BSPs for an architecture are built and this is not
practical
because it slows a build and uses a larger amount of disk space
when an
architecture has a larger number of BSPs so I am wondering if the
default is
reversed.


I think RTEMS itself should not be built as part of the tools.


Yes, only the tools should be built by default.

--
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.

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

Re: RSB release's default mode for building kernels

[Joel Sherrill]

On Tue, Jan 16, 2018 at 4:27 PM, Chris Johns  wrote:

> Hi,
>
> The current mode on all release branches is to build the RTEMS kernel. The
> purpose was to have a single command that builds the tools and RTEMS.
> However
> this means all BSPs for an architecture are built and this is not practical
> because it slows a build and uses a larger amount of disk space when an
> architecture has a larger number of BSPs so I am wondering if the default
> is
> reversed.
>

I think RTEMS itself should not be built as part of the tools.

You can't win. You are building BSPs that are not wanted, likely in a
configuration that isn't the users, and not being able to test on end user
hardware while doing it.  Best not to build them. Users expect to build
their own RTEMS and we need to encourage them to test and report.

--joel

>
> Comments?
>
> Chris
> ___
> 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

RSB release's default mode for building kernels

[Chris Johns]

Hi,

The current mode on all release branches is to build the RTEMS kernel. The
purpose was to have a single command that builds the tools and RTEMS. However
this means all BSPs for an architecture are built and this is not practical
because it slows a build and uses a larger amount of disk space when an
architecture has a larger number of BSPs so I am wondering if the default is
reversed.

Comments?

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

[PATCH] Change RSB version from 4.12 to 5

[Sebastian Huber]

---
 source-builder/sb/version.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source-builder/sb/version.py b/source-builder/sb/version.py
index da6aa02..0148614 100644
--- a/source-builder/sb/version.py
+++ b/source-builder/sb/version.py
@@ -35,7 +35,7 @@ import sources
 #
 # Default to an internal string.
 #
-_version = '4.12'
+_version = '5'
 _revision = 'not_released'
 _version_str = '%s.%s' % (_version, _revision)
 _released = False
-- 
2.12.3

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

[PATCH] RSB - RISC-V: Add scripts to build RISC-V's simulator

[Hesham Almatary]

Update #3109
---
 bare/config/devel/spike-1.1.0.cfg   | 21 
 bare/config/devel/spike.bset|  7 
 source-builder/config/spike-1-1.cfg | 64 +
 3 files changed, 92 insertions(+)
 create mode 100644 bare/config/devel/spike-1.1.0.cfg
 create mode 100644 bare/config/devel/spike.bset
 create mode 100644 source-builder/config/spike-1-1.cfg

diff --git a/bare/config/devel/spike-1.1.0.cfg 
b/bare/config/devel/spike-1.1.0.cfg
new file mode 100644
index 000..5b633fc
--- /dev/null
+++ b/bare/config/devel/spike-1.1.0.cfg
@@ -0,0 +1,21 @@
+#
+# RISC-V's simulator (spike) 1.1.0
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+%include %{_configdir}/base.cfg
+
+%define spike_version 1.1.0
+
+%hash sha512 priv-1.10.zip 
46ff0a07135bdc8c442ade3727f080d09ec8e7136e42f082d135b256c06088dc0b9f34028f0a20bcb19bb6de5a144ea02a53c587fac4204f0f7d05a11ae23ed3
+
+# RISC-V's front-end server (fesvr)
+%hash sha512 f683e01542acf60e50774d061bcb396b628e3e67.zip 
54900159e4a4f6ec28a43702e651354932e22e1e1995fa82aeb182225fe32be085e850e6060b8feadf6ffdd6cbe19873a379af687e36d04a1a3ea337cef93b06
+
+#
+# The spike build instructions. We use 1.x.x Release 1.
+#
+%include %{_configdir}/spike-1-1.cfg
diff --git a/bare/config/devel/spike.bset b/bare/config/devel/spike.bset
new file mode 100644
index 000..c7a6340
--- /dev/null
+++ b/bare/config/devel/spike.bset
@@ -0,0 +1,7 @@
+#
+# Build set for RISC-V's simulator
+#
+
+%define release 1
+
+devel/spike-1.1.0
diff --git a/source-builder/config/spike-1-1.cfg 
b/source-builder/config/spike-1-1.cfg
new file mode 100644
index 000..54e4915
--- /dev/null
+++ b/source-builder/config/spike-1-1.cfg
@@ -0,0 +1,64 @@
+#
+# RISC-V's spike (priv-1.10) 1.x.x Version 1.
+#
+# This configuration file configure's, make's and install's RISC-V's spike 
simulator.
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+Name:  spike-%{spike_version}-%{_host}-%{release}
+Summary:   spike-github
+Version:   %{spike_version}
+Release:   %{release}
+URL:  https://github.com/riscv/riscv-isa-sim/
+BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
+
+#
+# Source
+#
+%source set spike https://github.com/riscv/riscv-isa-sim/archive/priv-1.10.zip
+%source set fesvr 
https://github.com/riscv/riscv-fesvr/archive/f683e01542acf60e50774d061bcb396b628e3e67.zip
+
+#
+# Prepare the source code.
+#
+%prep
+  build_top=$(pwd)
+
+  %source setup fesvr -q -n 
riscv-fesvr-f683e01542acf60e50774d061bcb396b628e3e67
+  %source setup spike -q -n riscv-isa-sim-priv-1.10
+
+  cd ${build_top}
+
+%build
+  build_top=$(pwd)
+
+  cd riscv-fesvr-f683e01542acf60e50774d061bcb396b628e3e67
+
+  ../riscv-fesvr-f683e01542acf60e50774d061bcb396b628e3e67/configure \
+  --prefix=%{_prefix}
+  %{__make} %{?_smp_mflags} all$
+  %{__make} install
+
+
+  cd ../riscv-isa-sim-priv-1.10
+
+  ../riscv-isa-sim-priv-1.10/configure \
+  --prefix=%{_prefix} \
+  --with-fesvr=%{_prefix}
+
+  %{__make} %{?_smp_mflags} all$
+
+  cd ${build_top}
+
+%install
+  build_top=$(pwd)
+
+  rm -rf $SB_BUILD_ROOT
+
+  cd riscv-isa-sim-priv-1.10
+  %{__make} DESTDIR=$SB_BUILD_ROOT PREFIX=%{_prefix} install
+
+  cd ${build_top}
-- 
2.7.4

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

Re: [PATCH] RSB - Add support for RISC-V RV64 (64-bit) toolchain v2

[Hesham Almatary]

On Fri, Oct 27, 2017 at 5:55 PM, Chris Johns <chr...@rtems.org> wrote:
> On 27/10/2017 16:45, Sebastian Huber wrote:
>> Thanks, committed. Even the Ada support works:
>>
>> riscv64-rtems4.12-gnat --version
>> GNAT 7.2.0 20170814 (RTEMS 4.12, RSB 
>> 5bd4aa6bb33872b0f0fb243e7fc2f0784e69ab81,
>> Newlib 2.5.0.20170922)
>> Copyright (C) 1996-2017, Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.
>> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A 
>> PARTICULAR
>> PURPOSE.
>>
>
> This this arch get put in tier-4?
>
> Tools for archs with no BSP sit is tier-4 until a BSP is merged.
>
Well, I submitted a set of patches for RISC-V 64-bit, with a new
riscv64_generic (just a symlink to riscv_generic), which works.
Waiting for review.


> Chris



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

Re: [PATCH] RSB - Add support for RISC-V RV64 (64-bit) toolchain v2

[Chris Johns]

On 27/10/2017 16:45, Sebastian Huber wrote:
> Thanks, committed. Even the Ada support works:
> 
> riscv64-rtems4.12-gnat --version
> GNAT 7.2.0 20170814 (RTEMS 4.12, RSB 5bd4aa6bb33872b0f0fb243e7fc2f0784e69ab81,
> Newlib 2.5.0.20170922)
> Copyright (C) 1996-2017, Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> 

This this arch get put in tier-4?

Tools for archs with no BSP sit is tier-4 until a BSP is merged.

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

Re: [PATCH] RSB - Add support for RISC-V RV64 (64-bit) toolchain v2

[Sebastian Huber]

Thanks, committed. Even the Ada support works:

riscv64-rtems4.12-gnat --version
GNAT 7.2.0 20170814 (RTEMS 4.12, RSB 
5bd4aa6bb33872b0f0fb243e7fc2f0784e69ab81, Newlib 2.5.0.20170922)

Copyright (C) 1996-2017, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE.


--
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.

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

[PATCH] RSB - Add support for RISC-V RV64 (64-bit) toolchain v2

[Hesham Almatary]

Update #3109
---
 rtems/config/4.12/rtems-riscv64.bset | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 rtems/config/4.12/rtems-riscv64.bset

diff --git a/rtems/config/4.12/rtems-riscv64.bset 
b/rtems/config/4.12/rtems-riscv64.bset
new file mode 100644
index 000..406c0c9
--- /dev/null
+++ b/rtems/config/4.12/rtems-riscv64.bset
@@ -0,0 +1,16 @@
+#
+# RISC-V 64-bit architecture
+#
+%define release 1
+%define rtems_arch riscv64
+%define with_libgomp
+
+%include rtems-base.bset
+
+4.12/rtems-autotools
+
+devel/expat-2.1.0-1
+tools/rtems-binutils-2.29-1
+tools/rtems-gcc-7.2.0-newlib-2.5.0.20170922-1
+tools/rtems-tools-4.12-1
+tools/rtems-kernel-4.12
--
2.7.4

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

[PATCH] RSB - Add support for RISC-V RV64 (64-bit) toolchain

[Hesham Almatary]

From: Hesham Almatary 

Update #3109
---
 rtems/config/4.12/rtems-riscv64.bset | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 rtems/config/4.12/rtems-riscv64.bset

diff --git a/rtems/config/4.12/rtems-riscv64.bset 
b/rtems/config/4.12/rtems-riscv64.bset
new file mode 100644
index 000..406c0c9
--- /dev/null
+++ b/rtems/config/4.12/rtems-riscv64.bset
@@ -0,0 +1,16 @@
+#
+# RISC-V 64-bit architecture
+#
+%define release 1
+%define rtems_arch riscv64
+%define with_libgomp
+
+%include rtems-base.bset
+
+4.12/rtems-autotools
+
+devel/expat-2.1.0-1
+tools/rtems-binutils-2.29-1
+tools/rtems-gcc-7.2.0-newlib-2.5.0.20170922-1
+tools/rtems-tools-4.12-1
+tools/rtems-kernel-4.12
-- 
2.7.4

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

Re: [PATCH] RSB: Update gdb-7.12 config to pull in latest sis patches

[Jiri Gaisler]

On 07/31/2017 02:21 PM, Sebastian Huber wrote:
> On 31/07/17 14:18, Jiri Gaisler wrote:
>
>> Sorry - previous post had the wrong patch. Here is the correct one.
>
> Ok, could you please check that it is now all right.
>

It's perfect - thanks!

Jiri.

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

Re: [PATCH] RSB: Update gdb-7.12 config to pull in latest sis patches

[Sebastian Huber]

On 31/07/17 14:18, Jiri Gaisler wrote:


Sorry - previous post had the wrong patch. Here is the correct one.


Ok, could you please check that it is now all right.

--
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.

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

Re: [PATCH] RSB: Update gdb-7.12 config to pull in latest sis patches

[Jiri Gaisler]

Sorry - previous post had the wrong patch. Here is the correct one.

Jiri.


>From a5462f874eef326d47753abeffd2043034bccecf Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Sun, 30 Jul 2017 21:27:38 +0200
Subject: [PATCH] Update gdb-7.12 config to pull in latest sis patches.

	* Will make sure sis uses LMA rather than VMA when loading elf files.
---
 rtems/config/tools/rtems-gdb-7.12-1.cfg | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rtems/config/tools/rtems-gdb-7.12-1.cfg b/rtems/config/tools/rtems-gdb-7.12-1.cfg
index 38eedc3..f049dca 100644
--- a/rtems/config/tools/rtems-gdb-7.12-1.cfg
+++ b/rtems/config/tools/rtems-gdb-7.12-1.cfg
@@ -12,8 +12,8 @@
 #
 # ERC32 simulator fixes.
 #
-%patch add gdb https://gaisler.org/gdb/gdb-7.12-sis-leon2-leon3.diff
-%hash md5 gdb-7.12-sis-leon2-leon3.diff fe29e7daaab3bf70c99cda6925d8c0c5
+%patch add gdb https://gaisler.org/gdb/gdb-7.12.1-sis-leon2-leon3.diff
+%hash md5 gdb-7.12.1-sis-leon2-leon3.diff 40670e05b7fc3868a405fb43138f3262
 
 %patch add gdb https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blobdiff_plain;f=gdb/location.c;h=8dce21ada12b3f8cb4145d1af96e29efe378bda2;hp=65116c732f7071444986c4b582580b7cc4622f0b;hb=909de2c5cc91b815d671f7018da2a925fbd19aaf;hpb=a945860b6cb4f8a26343ac5dcb0b42fe5fb2f68a
 %hash sha512 binutils-gdb-git-8dce21ada12b3f8cb4145d1af96e29efe378bda2.patch c5acc276312067cdb9bbda1678f066b3d2b2c1e11275574aa2e3b5c4541c51e670da00e057a184211b282df254e9e1afa14ae7563f2a0588cf11a4dcbd2e5f7a
-- 
2.7.4

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

[PATCH] RSB: Update gdb-7.12 config to pull in latest sis patches

[Jiri Gaisler]

Please merge.


>From b14821b4ac72913139cc1758e9757443f697a642 Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Sun, 30 Jul 2017 21:27:38 +0200
Subject: [PATCH] Update gdb-7.12 config to pull in latest sis patches.

	* Will make sure sis uses LMA rather than VMA when loading elf files.
---
 rtems/config/tools/rtems-gdb-7.12-1.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtems/config/tools/rtems-gdb-7.12-1.cfg b/rtems/config/tools/rtems-gdb-7.12-1.cfg
index 38eedc3..90e809e 100644
--- a/rtems/config/tools/rtems-gdb-7.12-1.cfg
+++ b/rtems/config/tools/rtems-gdb-7.12-1.cfg
@@ -13,7 +13,7 @@
 # ERC32 simulator fixes.
 #
 %patch add gdb https://gaisler.org/gdb/gdb-7.12-sis-leon2-leon3.diff
-%hash md5 gdb-7.12-sis-leon2-leon3.diff fe29e7daaab3bf70c99cda6925d8c0c5
+%hash md5 gdb-7.12.1-sis-leon2-leon3.diff 40670e05b7fc3868a405fb43138f3262
 
 %patch add gdb https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blobdiff_plain;f=gdb/location.c;h=8dce21ada12b3f8cb4145d1af96e29efe378bda2;hp=65116c732f7071444986c4b582580b7cc4622f0b;hb=909de2c5cc91b815d671f7018da2a925fbd19aaf;hpb=a945860b6cb4f8a26343ac5dcb0b42fe5fb2f68a
 %hash sha512 binutils-gdb-git-8dce21ada12b3f8cb4145d1af96e29efe378bda2.patch c5acc276312067cdb9bbda1678f066b3d2b2c1e11275574aa2e3b5c4541c51e670da00e057a184211b282df254e9e1afa14ae7563f2a0588cf11a4dcbd2e5f7a
-- 
2.7.4

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

rtems microblaze rsb build failure in 4.12

[yao0718]

I try to build tools of microblaze by rsb, but I get failure when build newlib 
libm,
the log is:
/opt/rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.3.0-newlib-2.5.0.20170323-i686-linux-gnu-1/build/./gcc/xgcc
 
-B/opt/rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.3.0-newlib-2.5.0.20170323-i686-linux-gnu-1/build/./gcc/
 -nostdinc 
-B/opt/rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.3.0-newlib-2.5.0.20170323-i686-linux-gnu-1/build/microblaze-rtems4.12/bs/newlib/
 -isystem 
/opt/rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.3.0-newlib-2.5.0.20170323-i686-linux-gnu-1/build/microblaze-rtems4.12/bs/newlib/targ-include
 -isystem 
/opt/rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.3.0-newlib-2.5.0.20170323-i686-linux-gnu-1/gcc-6.3.0/newlib/libc/include
 -B/opt/rtems/4.12/microblaze-rtems4.12/bin/ 
-B/opt/rtems/4.12/microblaze-rtems4.12/lib/ -isystem 
/opt/rtems/4.12/microblaze-rtems4.12/include -isystem 
/opt/rtems/4.12/microblaze-rtems4.12/sys-include  -mxl-barrel-shift 
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" 
-DPACKAGE_VERSION=\"2.5.0\" -DPACKAGE_STRING=\"newlib\ 2.5.0\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I. 
-I../../../../../../gcc-6.3.0/newlib/libm/math 
-I../../../../../../gcc-6.3.0/newlib/libm/math/../common -D_COMPILING_NEWLIB 
-DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED 
-DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL 
-DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS 
-D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -D_NO_POSIX_SPAWN 
-D_I386MACH_ALLOW_HW_INTERRUPTS -fno-builtin  -g -O2  -mxl-barrel-shift -c 
-o lib_a-kf_tan.o `test -f 'kf_tan.c' || echo 
'../../../../../../gcc-6.3.0/newlib/libm/math/'`kf_tan.c
/opt/rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.3.0-newlib-2.5.0.20170323-i686-linux-gnu-1/build/./gcc/xgcc
 
-B/opt/rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.3.0-newlib-2.5.0.20170323-i686-linux-gnu-1/build/./gcc/
 -nostdinc 
-B/opt/rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.3.0-newlib-2.5.0.20170323-i686-linux-gnu-1/build/microblaze-rtems4.12/bs/newlib/
 -isystem 
/opt/rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.3.0-newlib-2.5.0.20170323-i686-linux-gnu-1/build/microblaze-rtems4.12/bs/newlib/targ-include
 -isystem 
/opt/rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.3.0-newlib-2.5.0.20170323-i686-linux-gnu-1/gcc-6.3.0/newlib/libc/include
 -B/opt/rtems/4.12/microblaze-rtems4.12/bin/ 
-B/opt/rtems/4.12/microblaze-rtems4.12/lib/ -isystem 
/opt/rtems/4.12/microblaze-rtems4.12/include -isystem 
/opt/rtems/4.12/microblaze-rtems4.12/sys-include  -mxl-barrel-shift 
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" 
-DPACKAGE_VERSION=\"2.5.0\" -DPACKAGE_STRING=\"newlib\ 2.5.0\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I. 
-I../../../../../../gcc-6.3.0/newlib/libm/math 
-I../../../../../../gcc-6.3.0/newlib/libm/math/../common -D_COMPILING_NEWLIB 
-DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED 
-DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL 
-DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS 
-D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -D_NO_POSIX_SPAWN 
-D_I386MACH_ALLOW_HW_INTERRUPTS -fno-builtin  -g -O2  -mxl-barrel-shift -c 
-o lib_a-ef_acos.o `test -f 'ef_acos.c' || echo 
'../../../../../../gcc-6.3.0/newlib/libm/math/'`ef_acos.c
/tmp/cczMOr4b.s: Assembler messages:
/tmp/cczMOr4b.s:291: Fatal error: operand must be a constant or a label
make[8]: *** [lib_a-ef_acos.o] Error 1
make[8]: Leaving directory 
`/opt/rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.3.0-newlib-2.5.0.20170323-i686-linux-gnu-1/build/microblaze-rtems4.12/bs/newlib/libm/math'





I think perhaps the new fast sqrt function cause failure,can someone give me 
some advice?


alwasy failure when compile ef_acos.c___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/1] RSB: Update gdb-7.12 config to pull in latest sis patches.

[Jiri Gaisler]

Sorry, forgot to add the patch. Should not be doing this on a Friday
night ... :-)


On 07/21/2017 10:24 PM, Jiri Gaisler wrote:
> Can somebody review and merge this to RSB?
>
> Thanks, Jiri.
>

>From ae34bb8a2dedcff60ca25a83786c09d7bac3b794 Mon Sep 17 00:00:00 2001
From: Jiri Gaisler <j...@gaisler.se>
Date: Fri, 21 Jul 2017 18:08:07 +0200
Subject: [PATCH] Update gdb-7.12 config to pull in latest sis patches.

	This will add support for FSMULD on leon3 targets.
---
 rtems/config/tools/rtems-gdb-7.12-1.cfg | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/rtems/config/tools/rtems-gdb-7.12-1.cfg b/rtems/config/tools/rtems-gdb-7.12-1.cfg
index ab557aa..38eedc3 100644
--- a/rtems/config/tools/rtems-gdb-7.12-1.cfg
+++ b/rtems/config/tools/rtems-gdb-7.12-1.cfg
@@ -10,10 +10,10 @@
 %hash md5 gdb-%{gdb_version}.tar.xz a0a3a00f7499b0c5278ba8676745d180
 
 #
-# ERC32 simulator fixes. (still OK from 7.11)
+# ERC32 simulator fixes.
 #
-%patch add gdb %{rtems_gdb_patches}/gdb-7.11-sis-leon2-leon3.diff
-%hash md5 gdb-7.11-sis-leon2-leon3.diff 88eac302290ea2a58bd7e08aaca94efd
+%patch add gdb https://gaisler.org/gdb/gdb-7.12-sis-leon2-leon3.diff
+%hash md5 gdb-7.12-sis-leon2-leon3.diff fe29e7daaab3bf70c99cda6925d8c0c5
 
 %patch add gdb https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blobdiff_plain;f=gdb/location.c;h=8dce21ada12b3f8cb4145d1af96e29efe378bda2;hp=65116c732f7071444986c4b582580b7cc4622f0b;hb=909de2c5cc91b815d671f7018da2a925fbd19aaf;hpb=a945860b6cb4f8a26343ac5dcb0b42fe5fb2f68a
 %hash sha512 binutils-gdb-git-8dce21ada12b3f8cb4145d1af96e29efe378bda2.patch c5acc276312067cdb9bbda1678f066b3d2b2c1e11275574aa2e3b5c4541c51e670da00e057a184211b282df254e9e1afa14ae7563f2a0588cf11a4dcbd2e5f7a
-- 
2.7.4

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

[PATCH 1/1] RSB: Update gdb-7.12 config to pull in latest sis patches.

[Jiri Gaisler]

Can somebody review and merge this to RSB?

Thanks, Jiri.

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

Re: RSB Architecture request: aarch64, x86_64, risc-v

[Joel Sherrill]

On Mon, Jun 26, 2017 at 8:39 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 26/06/17 02:28, Hesham Almatary wrote:
>
> On Mon, Jun 26, 2017 at 10:11 AM, Chris Johns  wrote:
>>
>>> On 26/06/2017 10:03, Hesham Almatary wrote:
>>>
 I've already submitted a patch for riscv32 here [1].

 Thanks. My reading of the thread there are some unresolved questions.
>>>
>>> What is the status?
>>>
>>> Regarding FSF paperwork, I asked my employer about that. Shouldn't be
>> an issue for this patch as I fetch the patch from my personal GitHub
>> repo.
>>
>> Sebastian, is any more work needed for this patch to be merged?
>>
>>
> Sorry, I simply forgot to commit your patch.
>
> Could you please merge the RTEMS GCC support with the ELF support and send
> a patch to the GCC patches list? It would be nice to have it in GCC 7.2
> which should be available in the next weeks.


cc Sebastian and I since either of us can commit it.

It is just better if the full gcc community sees it. And +1 on getting it
into gcc 7.2

--joel


>
>
> --
> 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.
>
>
> ___
> 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: RSB Architecture request: aarch64, x86_64, risc-v

[Sebastian Huber]

On 26/06/17 02:28, Hesham Almatary wrote:


On Mon, Jun 26, 2017 at 10:11 AM, Chris Johns  wrote:

On 26/06/2017 10:03, Hesham Almatary wrote:

I've already submitted a patch for riscv32 here [1].


Thanks. My reading of the thread there are some unresolved questions.

What is the status?


Regarding FSF paperwork, I asked my employer about that. Shouldn't be
an issue for this patch as I fetch the patch from my personal GitHub
repo.

Sebastian, is any more work needed for this patch to be merged?



Sorry, I simply forgot to commit your patch.

Could you please merge the RTEMS GCC support with the ELF support and 
send a patch to the GCC patches list? It would be nice to have it in GCC 
7.2 which should be available in the next weeks.


--
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.

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

Re: RSB Architecture request: aarch64, x86_64, risc-v

[Hesham Almatary]

Hi Chris,



On Mon, Jun 26, 2017 at 10:11 AM, Chris Johns  wrote:
> On 26/06/2017 10:03, Hesham Almatary wrote:
>>
>> I've already submitted a patch for riscv32 here [1].
>>
>
> Thanks. My reading of the thread there are some unresolved questions.
>
> What is the status?
>
Regarding FSF paperwork, I asked my employer about that. Shouldn't be
an issue for this patch as I fetch the patch from my personal GitHub
repo.

Sebastian, is any more work needed for this patch to be merged?

> Thanks
> Chris
>
>> [1] https://lists.rtems.org/pipermail/devel/2017-May/017951.html.
>
>
>



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

Re: RSB Architecture request: aarch64, x86_64, risc-v

[Chris Johns]

On 26/06/2017 10:03, Hesham Almatary wrote:
> 
> I've already submitted a patch for riscv32 here [1].
> 

Thanks. My reading of the thread there are some unresolved questions.

What is the status?

Thanks
Chris

> [1] https://lists.rtems.org/pipermail/devel/2017-May/017951.html.



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

Re: RSB Architecture request: aarch64, x86_64, risc-v

[Hesham Almatary]

Hi Chris,

I've already submitted a patch for riscv32 here [1].

[1] https://lists.rtems.org/pipermail/devel/2017-May/017951.html.

Cheers,
Hesham

On Mon, Jun 26, 2017 at 9:57 AM, Chris Johns <chr...@rtems.org> wrote:
> Hello,
>
> I would like to add aarch64, x86_64, and risc-v to 4.12/rtems-all so these 
> tools
> are always built when regression testing tool set changes. This change makes
> sure the tools are in a suitable state for those looking to add support for
> these architectures.
>
> To add RISC-V I need the architecture added to the RSB. Could those working 
> with
> this architecture to please considering post patches to this list list for
> review that adds this architecture.
>
> Thanks
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



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

RSB Architecture request: aarch64, x86_64, risc-v

[Chris Johns]

Hello,

I would like to add aarch64, x86_64, and risc-v to 4.12/rtems-all so these tools
are always built when regression testing tool set changes. This change makes
sure the tools are in a suitable state for those looking to add support for
these architectures.

To add RISC-V I need the architecture added to the RSB. Could those working with
this architecture to please considering post patches to this list list for
review that adds this architecture.

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

Re: RSB Couverture-Qemu build queries

[Cillian O'Donnell]

> Please try and let me know if it is ok so I can push to master:

It worked! Everything's perfect now. Thanks Chris.

On 19 June 2017 at 23:19, Jiri Gaisler <j...@gaisler.se> wrote:
>
>
> On 06/17/2017 10:28 AM, Cillian O'Donnell wrote:
>> On 16 June 2017 at 22:00, Jiri Gaisler <j...@gaisler.se> wrote:
>>> Hi Cillian,
>>>
>>> the gaisler.org server is currently down due to a power problem last
>>> week. I am in the Caribbean at the moment so I can't fix it until
>>> Tuesday next week. I suggest you skip the LEON3 patches until I fix the
>>> server next week. Let me know if you get problems merging the patches,
>>> and I will try to sort it out.
>>>
>>> Jiri.
>>>
>> Ok, thanks for letting me know Jiri. I'll leave the patches till
>> Tuesday and see If I can put them back together and get them merged
>> then. Thanks Joel, I've been talking with Fabien Chouteau from the
>> Couverture project, I'll reach out to him with the patches and cc you
>> and Chris and thanks Gedare for the info.
>
> gaisler.org is up again, so you can download the patches. Let me know if
> you need help merging them.
>
> Jiri.

Great! I'll get to work on the patches today. Thanks Jiri.
>
>>
>>> On 06/16/2017 03:13 PM, Cillian O'Donnell wrote:
>>>> Hi,
>>>>
>>>> I am getting the RSB to build Couverture-Qemu and I just want to check
>>>> a few things I have done so far.
>>>>
>>>> 1. There are about 5 patches applied to the current qemu build. Only
>>>> one of which applies cleanly to the Couverture build. Do you want me
>>>> to try and fix these up, comment them out and leave a note for
>>>> whoever wants to fix them or remove them completely? The patches that
>>>> don't work are:
>>>>
>>>> %patch add qemu
>>>> pw://patchwork.ozlabs.org/patch/406903/raw/Provide-the-missing-LIBUSB_LOG_LEVEL_-for-older-libusb-or-FreeBSD.-Providing-just-the-needed-value-as-a-defined..patch
>>>>
>>>> %patch add qemu
>>>> https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-
>>>> play.patch
>>>>
>>>> %patch add qemu
>>>> https://gaisler.org/qemu/0002-LEON3-Build-AMBA-plug-and-play-records-from-high-lev.patch
>>>>
>>>> %patch add qemu
>>>> https://gaisler.org/qemu/0003-LEON3-Init-UART-timers-and-CPU-if-we-run-a-RAM-image.patch
>>>>
>>>>
>>>> 2. For this source setting section, is the first part just dealing
>>>> with the case were this a packaged release so a tar of the download is
>>>> already included with it?
>>>>
>>>> %if %{rsb_released} && %{!defined without_release_url}
>>>> %source set qemu
>>>> %{rtems_release_url}/%{rtems_version}/sources/qemu-git-42d58e7.tar.xz
>>>> %else
>>>> %source set qemu
>>>> https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
>>>> %endif
>>>>
>>>> 3. What does the -q option do in the %prep section of the build, this
>>>> option shows up in examples in the docs but there is no description of
>>>> what it does?
>>>>
>>>> %source setup qemu -q -n qemu-%{qemu_version}
>>>>
>>>> 4. The current qemu build is configured with the default setting to
>>>> build for all architectures but most of the arch's aren't used by
>>>> RTEMS and/or don't have machine support for same bsps, so I've added a
>>>> --target-list to only build the targets that have a corresponding bsp
>>>> (sparc64-softmmu is missing as it runs into build issues, I forgot to
>>>> mention in the initial results). However the list spills over 80 lines
>>>> so should I make a %{qemu_targets} macro and if so where should I put
>>>> it?
>>>>
>>>>  --make=%{__make} \
>>>>  72 
>>>> --target-list=arm-softmmu,i386-softmmu,lm32-softmmu,mips-softmmu,ppc-softmmu,sparc-softmmu
>>>> \
>>>>  73 ${VDE_CONFIG} \
>>>>  74 --disable-smartcard-nss \
>>>>
>>>> Thanks,
>>>>
>>>> Cillian.
>>>> ___
>>>> 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: RSB Couverture-Qemu build queries

[Jiri Gaisler]

On 06/17/2017 10:28 AM, Cillian O'Donnell wrote:
> On 16 June 2017 at 22:00, Jiri Gaisler <j...@gaisler.se> wrote:
>> Hi Cillian,
>>
>> the gaisler.org server is currently down due to a power problem last
>> week. I am in the Caribbean at the moment so I can't fix it until
>> Tuesday next week. I suggest you skip the LEON3 patches until I fix the
>> server next week. Let me know if you get problems merging the patches,
>> and I will try to sort it out.
>>
>> Jiri.
>>
> Ok, thanks for letting me know Jiri. I'll leave the patches till
> Tuesday and see If I can put them back together and get them merged
> then. Thanks Joel, I've been talking with Fabien Chouteau from the
> Couverture project, I'll reach out to him with the patches and cc you
> and Chris and thanks Gedare for the info.

gaisler.org is up again, so you can download the patches. Let me know if
you need help merging them.

Jiri.

>
>> On 06/16/2017 03:13 PM, Cillian O'Donnell wrote:
>>> Hi,
>>>
>>> I am getting the RSB to build Couverture-Qemu and I just want to check
>>> a few things I have done so far.
>>>
>>> 1. There are about 5 patches applied to the current qemu build. Only
>>> one of which applies cleanly to the Couverture build. Do you want me
>>> to try and fix these up, comment them out and leave a note for
>>> whoever wants to fix them or remove them completely? The patches that
>>> don't work are:
>>>
>>> %patch add qemu
>>> pw://patchwork.ozlabs.org/patch/406903/raw/Provide-the-missing-LIBUSB_LOG_LEVEL_-for-older-libusb-or-FreeBSD.-Providing-just-the-needed-value-as-a-defined..patch
>>>
>>> %patch add qemu
>>> https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-
>>> play.patch
>>>
>>> %patch add qemu
>>> https://gaisler.org/qemu/0002-LEON3-Build-AMBA-plug-and-play-records-from-high-lev.patch
>>>
>>> %patch add qemu
>>> https://gaisler.org/qemu/0003-LEON3-Init-UART-timers-and-CPU-if-we-run-a-RAM-image.patch
>>>
>>>
>>> 2. For this source setting section, is the first part just dealing
>>> with the case were this a packaged release so a tar of the download is
>>> already included with it?
>>>
>>> %if %{rsb_released} && %{!defined without_release_url}
>>> %source set qemu
>>> %{rtems_release_url}/%{rtems_version}/sources/qemu-git-42d58e7.tar.xz
>>> %else
>>> %source set qemu
>>> https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
>>> %endif
>>>
>>> 3. What does the -q option do in the %prep section of the build, this
>>> option shows up in examples in the docs but there is no description of
>>> what it does?
>>>
>>> %source setup qemu -q -n qemu-%{qemu_version}
>>>
>>> 4. The current qemu build is configured with the default setting to
>>> build for all architectures but most of the arch's aren't used by
>>> RTEMS and/or don't have machine support for same bsps, so I've added a
>>> --target-list to only build the targets that have a corresponding bsp
>>> (sparc64-softmmu is missing as it runs into build issues, I forgot to
>>> mention in the initial results). However the list spills over 80 lines
>>> so should I make a %{qemu_targets} macro and if so where should I put
>>> it?
>>>
>>>  --make=%{__make} \
>>>  72 
>>> --target-list=arm-softmmu,i386-softmmu,lm32-softmmu,mips-softmmu,ppc-softmmu,sparc-softmmu
>>> \
>>>  73 ${VDE_CONFIG} \
>>>  74 --disable-smartcard-nss \
>>>
>>> Thanks,
>>>
>>> Cillian.
>>> ___
>>> 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: RSB Couverture-Qemu build queries

[Chris Johns]

On 19/06/2017 20:33, Cillian O'Donnell wrote:
> On 18 June 2017 at 03:23, Chris Johns <chr...@rtems.org> wrote:
>> On 17/6/17 6:38 am, Joel Sherrill wrote:
>>> On Fri, Jun 16, 2017 at 2:13 PM, Cillian O'Donnell <cpodonne...@gmail.com
>>> <mailto:cpodonne...@gmail.com>> wrote:
>> Use '--trace --dry-run' to debug until you get the command line you want.
> 
> The --dry-run option has been running into trouble for me. I had a
> look around the build config files and config.py but I haven't figured
> out how to fix it. The traceback starts at gettext, if I remove
> gettext it stops at libffi and if thats removed it stops at the next
> dependency and so on. It's the same for the current qemu too.
> 
> ../source-builder/sb-set-builder
> --prefix=$HOME/development/rtems/qemu_tools --dry-run --trace
> devel/couverture-qemu
> RTEMS Source Builder - Set Builder, 4.12 (14a801b3ceaa modified)
> Build Set: devel/couverture-qemu
> Build Set: devel/autotools-internal.bset
> config: devel/autoconf-2.69-1.cfg
> package: autoconf-2.69-x86_64-linux-gnu-1
>   See error report: rsb-report-autoconf-2.69-x86_64-linux-gnu-1.txt
> config: devel/automake-1.12.6-1.cfg
> package: automake-1.12.6-x86_64-linux-gnu-1
>   See error report: rsb-report-automake-1.12.6-x86_64-linux-gnu-1.txt
> config: devel/libtool-2.4.2-1.cfg
> package: libtool-2.4.2-x86_64-linux-gnu-1
>   See error report: rsb-report-libtool-2.4.2-x86_64-linux-gnu-1.txt
> cleaning: autoconf-2.69-x86_64-linux-gnu-1
> cleaning: automake-1.12.6-x86_64-linux-gnu-1
> cleaning: libtool-2.4.2-x86_64-linux-gnu-1
> Build Set: Time 0:00:00.312635
> config: devel/libiconv-1.14-1.cfg
> config: devel/gettext-0.18.3.1-1.cfg
> Build Set: Time 0:00:00.330358
> Traceback (most recent call last):
>   File "../source-builder/sb-set-builder", line 29, in 
> setbuilder.run()
>   File "../source-builder/sb/setbuilder.py", line 502, in run
> b.build(deps)
>   File "../source-builder/sb/setbuilder.py", line 347, in build
> opts, macros)
>   File "../source-builder/sb/build.py", line 129, in __init__
> self.config = config.file(name, opts, self.macros)
>   File "../source-builder/sb/config.py", line 249, in __init__
> self.load(name)
>   File "../source-builder/sb/config.py", line 1258, in load
> r = self._parse(config, dir, info)
>   File "../source-builder/sb/config.py", line 991, in _parse
> l = self._expand(l)
>   File "../source-builder/sb/config.py", line 623, in _expand
> ps = self._pkgconfig(epcl)
>   File "../source-builder/sb/config.py", line 481, in _pkgconfig
> ps = self._pkgconfig_check(pcl[1:])
>   File "../source-builder/sb/config.py", line 425, in _pkgconfig_check
> if self.macros['_dry_run'] == '1' and self.macros['with_download'] == '1':
>   File "../source-builder/sb/macros.py", line 147, in __getitem__
> raise IndexError('key: %s' % (key))
> IndexError: key: with_download
> 

Please try and let me know if it is ok so I can push to master:

diff --git a/source-builder/sb/config.py b/source-builder/sb/config.py
index da54ba3..a4f739b 100644
--- a/source-builder/sb/config.py
+++ b/source-builder/sb/config.py
@@ -422,7 +422,8 @@ class file: def _pkgconfig_check(self, test):
 # Hack to by pass pkgconfig checks when just wanting to download the
 # source.
-if self.macros['_dry_run'] == '1' and self.macros['with_download'] == 
'1':
+if self.macros['_dry_run'] == '1' and \
+   ('with_download' in self.macros and self.macros['with_download'] == 
'1'):
 return '0'
 ok = False
 if type(test) == str:
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB Couverture-Qemu build queries

[Cillian O'Donnell]

On 18 June 2017 at 03:23, Chris Johns <chr...@rtems.org> wrote:
> On 17/6/17 6:38 am, Joel Sherrill wrote:
>>
>>
>> On Fri, Jun 16, 2017 at 2:13 PM, Cillian O'Donnell <cpodonne...@gmail.com
>> <mailto:cpodonne...@gmail.com>> wrote:
>>
>> Hi,
>>
>> I am getting the RSB to build Couverture-Qemu and I just want to check
>> a few things I have done so far.
>>
>> 1. There are about 5 patches applied to the current qemu build. Only
>> one of which applies cleanly to the Couverture build. Do you want me
>> to try and fix these up, comment them out and leave a note for
>> whoever wants to fix them or remove them completely? The patches that
>> don't work are:
>>
>> %patch add qemu
>> 
>> pw://patchwork.ozlabs.org/patch/406903/raw/Provide-the-missing-LIBUSB_LOG_LEVEL_-for-older-libusb-or-FreeBSD.-Providing-just-the-needed-value-as-a-defined..patch
>> 
>> <http://patchwork.ozlabs.org/patch/406903/raw/Provide-the-missing-LIBUSB_LOG_LEVEL_-for-older-libusb-or-FreeBSD.-Providing-just-the-needed-value-as-a-defined..patch>
>>
>> %patch add qemu
>> https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-
>> <https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug->
>> play.patch
>>
>> %patch add qemu
>> 
>> https://gaisler.org/qemu/0002-LEON3-Build-AMBA-plug-and-play-records-from-high-lev.patch
>> 
>> <https://gaisler.org/qemu/0002-LEON3-Build-AMBA-plug-and-play-records-from-high-lev.patch>
>>
>> %patch add qemu
>> 
>> https://gaisler.org/qemu/0003-LEON3-Init-UART-timers-and-CPU-if-we-run-a-RAM-image.patch
>> 
>> <https://gaisler.org/qemu/0003-LEON3-Init-UART-timers-and-CPU-if-we-run-a-RAM-image.patch>
>>
>>
>>
>> I think they need to be proposed to the Couverture project to be evaluated. 
>> They
>> should
>> be OK with the Gaisler ones without too much trouble. We can bring in 
>> Gaisler folks.
>> The other is a portability one.
>>
>> So at least make the project aware of them.
>>
>> https://forge.open-do.org/projects/couverture-qemu/
>>
>> Make sure myself and chrisj@ are on any issue/email you file.
>>
>>
>> 2. For this source setting section, is the first part just dealing
>> with the case were this a packaged release so a tar of the download is
>> already included with it?
>>
>> %if %{rsb_released} && %{!defined without_release_url}
>> %source set qemu
>> %{rtems_release_url}/%{rtems_version}/sources/qemu-git-42d58e7.tar.xz
>> %else
>> %source set qemu
>> https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
>> <https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz>
>> %endif
>>
>>
>> I think so but Chris should confirm that.
>
> I think the release process should handle this. I suggest you make this as
> simple as possible and remove the release check. I can look at this if this
> breaks the release scripts when we start the 4.12 release process.
>
>>
>> 3. What does the -q option do in the %prep section of the build, this
>> option shows up in examples in the docs but there is no description of
>> what it does?
>>
>> %source setup qemu -q -n qemu-%{qemu_version}
>>
>>
>> Chris will have to answer this.
>>
>
> It is a spec file compatible option that is not used. You can remove the -q.
>
> https://docs.fedoraproject.org/ro/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch09s04.html
>
>> 4. The current qemu build is configured with the default setting to
>> build for all architectures but most of the arch's aren't used by
>> RTEMS and/or don't have machine support for same bsps, so I've added a
>> --target-list to only build the targets that have a corresponding bsp
>> (sparc64-softmmu is missing as it runs into build issues, I forgot to
>> mention in the initial results). However the list spills over 80 lines
>> so should I make a %{qemu_targets} macro and if so where should I put
>> it?
>>
>> I like the idea of limiting the targets built. You are right that we don't
>> care about the others.
>
> Makes sense. We should only provide what we know works.
>
>> The style and variable name are Chris questions.
>>
>>  --make=%{__make} \
>>  72
>>  
>> --target-list=arm-softmmu,i386-softmmu,lm32-softmmu,mips-softmmu,ppc-softmmu,spa

Re: RSB Couverture-Qemu build queries

[Cillian O'Donnell]

On 16 June 2017 at 22:00, Jiri Gaisler <j...@gaisler.se> wrote:
> Hi Cillian,
>
> the gaisler.org server is currently down due to a power problem last
> week. I am in the Caribbean at the moment so I can't fix it until
> Tuesday next week. I suggest you skip the LEON3 patches until I fix the
> server next week. Let me know if you get problems merging the patches,
> and I will try to sort it out.
>
> Jiri.
>

Ok, thanks for letting me know Jiri. I'll leave the patches till
Tuesday and see If I can put them back together and get them merged
then. Thanks Joel, I've been talking with Fabien Chouteau from the
Couverture project, I'll reach out to him with the patches and cc you
and Chris and thanks Gedare for the info.

>
> On 06/16/2017 03:13 PM, Cillian O'Donnell wrote:
>> Hi,
>>
>> I am getting the RSB to build Couverture-Qemu and I just want to check
>> a few things I have done so far.
>>
>> 1. There are about 5 patches applied to the current qemu build. Only
>> one of which applies cleanly to the Couverture build. Do you want me
>> to try and fix these up, comment them out and leave a note for
>> whoever wants to fix them or remove them completely? The patches that
>> don't work are:
>>
>> %patch add qemu
>> pw://patchwork.ozlabs.org/patch/406903/raw/Provide-the-missing-LIBUSB_LOG_LEVEL_-for-older-libusb-or-FreeBSD.-Providing-just-the-needed-value-as-a-defined..patch
>>
>> %patch add qemu
>> https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-
>> play.patch
>>
>> %patch add qemu
>> https://gaisler.org/qemu/0002-LEON3-Build-AMBA-plug-and-play-records-from-high-lev.patch
>>
>> %patch add qemu
>> https://gaisler.org/qemu/0003-LEON3-Init-UART-timers-and-CPU-if-we-run-a-RAM-image.patch
>>
>>
>> 2. For this source setting section, is the first part just dealing
>> with the case were this a packaged release so a tar of the download is
>> already included with it?
>>
>> %if %{rsb_released} && %{!defined without_release_url}
>> %source set qemu
>> %{rtems_release_url}/%{rtems_version}/sources/qemu-git-42d58e7.tar.xz
>> %else
>> %source set qemu
>> https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
>> %endif
>>
>> 3. What does the -q option do in the %prep section of the build, this
>> option shows up in examples in the docs but there is no description of
>> what it does?
>>
>> %source setup qemu -q -n qemu-%{qemu_version}
>>
>> 4. The current qemu build is configured with the default setting to
>> build for all architectures but most of the arch's aren't used by
>> RTEMS and/or don't have machine support for same bsps, so I've added a
>> --target-list to only build the targets that have a corresponding bsp
>> (sparc64-softmmu is missing as it runs into build issues, I forgot to
>> mention in the initial results). However the list spills over 80 lines
>> so should I make a %{qemu_targets} macro and if so where should I put
>> it?
>>
>>  --make=%{__make} \
>>  72 
>> --target-list=arm-softmmu,i386-softmmu,lm32-softmmu,mips-softmmu,ppc-softmmu,sparc-softmmu
>> \
>>  73 ${VDE_CONFIG} \
>>  74 --disable-smartcard-nss \
>>
>> Thanks,
>>
>> Cillian.
>> ___
>> 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: RSB Couverture-Qemu build queries

[Jiri Gaisler]

Hi Cillian,

the gaisler.org server is currently down due to a power problem last
week. I am in the Caribbean at the moment so I can't fix it until
Tuesday next week. I suggest you skip the LEON3 patches until I fix the
server next week. Let me know if you get problems merging the patches,
and I will try to sort it out.

Jiri.


On 06/16/2017 03:13 PM, Cillian O'Donnell wrote:
> Hi,
>
> I am getting the RSB to build Couverture-Qemu and I just want to check
> a few things I have done so far.
>
> 1. There are about 5 patches applied to the current qemu build. Only
> one of which applies cleanly to the Couverture build. Do you want me
> to try and fix these up, comment them out and leave a note for
> whoever wants to fix them or remove them completely? The patches that
> don't work are:
>
> %patch add qemu
> pw://patchwork.ozlabs.org/patch/406903/raw/Provide-the-missing-LIBUSB_LOG_LEVEL_-for-older-libusb-or-FreeBSD.-Providing-just-the-needed-value-as-a-defined..patch
>
> %patch add qemu
> https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-
> play.patch
>
> %patch add qemu
> https://gaisler.org/qemu/0002-LEON3-Build-AMBA-plug-and-play-records-from-high-lev.patch
>
> %patch add qemu
> https://gaisler.org/qemu/0003-LEON3-Init-UART-timers-and-CPU-if-we-run-a-RAM-image.patch
>
>
> 2. For this source setting section, is the first part just dealing
> with the case were this a packaged release so a tar of the download is
> already included with it?
>
> %if %{rsb_released} && %{!defined without_release_url}
> %source set qemu
> %{rtems_release_url}/%{rtems_version}/sources/qemu-git-42d58e7.tar.xz
> %else
> %source set qemu
> https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
> %endif
>
> 3. What does the -q option do in the %prep section of the build, this
> option shows up in examples in the docs but there is no description of
> what it does?
>
> %source setup qemu -q -n qemu-%{qemu_version}
>
> 4. The current qemu build is configured with the default setting to
> build for all architectures but most of the arch's aren't used by
> RTEMS and/or don't have machine support for same bsps, so I've added a
> --target-list to only build the targets that have a corresponding bsp
> (sparc64-softmmu is missing as it runs into build issues, I forgot to
> mention in the initial results). However the list spills over 80 lines
> so should I make a %{qemu_targets} macro and if so where should I put
> it?
>
>  --make=%{__make} \
>  72 
> --target-list=arm-softmmu,i386-softmmu,lm32-softmmu,mips-softmmu,ppc-softmmu,sparc-softmmu
> \
>  73 ${VDE_CONFIG} \
>  74 --disable-smartcard-nss \
>
> Thanks,
>
> Cillian.
> ___
> 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: RSB Couverture-Qemu build queries

[Gedare Bloom]

On Fri, Jun 16, 2017 at 4:38 PM, Joel Sherrill <j...@rtems.org> wrote:
>
>
> On Fri, Jun 16, 2017 at 2:13 PM, Cillian O'Donnell <cpodonne...@gmail.com>
> wrote:
>>
>> Hi,
>>
>> I am getting the RSB to build Couverture-Qemu and I just want to check
>> a few things I have done so far.
>>
>> 1. There are about 5 patches applied to the current qemu build. Only
>> one of which applies cleanly to the Couverture build. Do you want me
>> to try and fix these up, comment them out and leave a note for
>> whoever wants to fix them or remove them completely? The patches that
>> don't work are:
>>
>> %patch add qemu
>>
>> pw://patchwork.ozlabs.org/patch/406903/raw/Provide-the-missing-LIBUSB_LOG_LEVEL_-for-older-libusb-or-FreeBSD.-Providing-just-the-needed-value-as-a-defined..patch
>>
>> %patch add qemu
>> https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-
>> play.patch
>>
>> %patch add qemu
>>
>> https://gaisler.org/qemu/0002-LEON3-Build-AMBA-plug-and-play-records-from-high-lev.patch
>>
>> %patch add qemu
>>
>> https://gaisler.org/qemu/0003-LEON3-Init-UART-timers-and-CPU-if-we-run-a-RAM-image.patch
>>
>>
>
> I think they need to be proposed to the Couverture project to be evaluated.
> They should
> be OK with the Gaisler ones without too much trouble. We can bring in
> Gaisler folks.
> The other is a portability one.
>
> So at least make the project aware of them.
>
> https://forge.open-do.org/projects/couverture-qemu/
>
> Make sure myself and chrisj@ are on any issue/email you file.
>
>>
>> 2. For this source setting section, is the first part just dealing
>> with the case were this a packaged release so a tar of the download is
>> already included with it?
>>
>> %if %{rsb_released} && %{!defined without_release_url}
>> %source set qemu
>> %{rtems_release_url}/%{rtems_version}/sources/qemu-git-42d58e7.tar.xz
>> %else
>> %source set qemu
>> https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
>> %endif
>
>
> I think so but Chris should confirm that.
>>
>>
>> 3. What does the -q option do in the %prep section of the build, this
>> option shows up in examples in the docs but there is no description of
>> what it does?
>>
>> %source setup qemu -q -n qemu-%{qemu_version}
>
>
> Chris will have to answer this.
>
>>
>>
>> 4. The current qemu build is configured with the default setting to
>> build for all architectures but most of the arch's aren't used by
>> RTEMS and/or don't have machine support for same bsps, so I've added a
>> --target-list to only build the targets that have a corresponding bsp
>> (sparc64-softmmu is missing as it runs into build issues, I forgot to
>> mention in the initial results). However the list spills over 80 lines
>> so should I make a %{qemu_targets} macro and if so where should I put
>> it?
>
>
> I like the idea of limiting the targets built. You are right that we don't
> care about the others.
>

sparc64-softmmu did not work for rtems the last time that I checked,
but that was a few years ago.

> The style and variable name are Chris questions.
>
>>
>>
>>  --make=%{__make} \
>>  72
>> --target-list=arm-softmmu,i386-softmmu,lm32-softmmu,mips-softmmu,ppc-softmmu,sparc-softmmu
>> \
>>  73 ${VDE_CONFIG} \
>>  74 --disable-smartcard-nss \
>>
>> Thanks,
>>
>> Cillian.
>
>
>
> ___
> 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: RSB Couverture-Qemu build queries

[Joel Sherrill]

On Fri, Jun 16, 2017 at 2:13 PM, Cillian O'Donnell <cpodonne...@gmail.com>
wrote:

> Hi,
>
> I am getting the RSB to build Couverture-Qemu and I just want to check
> a few things I have done so far.
>
> 1. There are about 5 patches applied to the current qemu build. Only
> one of which applies cleanly to the Couverture build. Do you want me
> to try and fix these up, comment them out and leave a note for
> whoever wants to fix them or remove them completely? The patches that
> don't work are:
>
> %patch add qemu
> pw://patchwork.ozlabs.org/patch/406903/raw/Provide-the-
> missing-LIBUSB_LOG_LEVEL_-for-older-libusb-or-FreeBSD.-
> Providing-just-the-needed-value-as-a-defined..patch
>
> %patch add qemu
> https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-
> play.patch
>
> %patch add qemu
> https://gaisler.org/qemu/0002-LEON3-Build-AMBA-plug-and-
> play-records-from-high-lev.patch
>
> %patch add qemu
> https://gaisler.org/qemu/0003-LEON3-Init-UART-timers-and-
> CPU-if-we-run-a-RAM-image.patch
>
>
>
I think they need to be proposed to the Couverture project to be evaluated.
They should
be OK with the Gaisler ones without too much trouble. We can bring in
Gaisler folks.
The other is a portability one.

So at least make the project aware of them.

https://forge.open-do.org/projects/couverture-qemu/

Make sure myself and chrisj@ are on any issue/email you file.


> 2. For this source setting section, is the first part just dealing
> with the case were this a packaged release so a tar of the download is
> already included with it?
>
> %if %{rsb_released} && %{!defined without_release_url}
> %source set qemu
> %{rtems_release_url}/%{rtems_version}/sources/qemu-git-42d58e7.tar.xz
> %else
> %source set qemu
> https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
> %endif
>

I think so but Chris should confirm that.

>
> 3. What does the -q option do in the %prep section of the build, this
> option shows up in examples in the docs but there is no description of
> what it does?
>
> %source setup qemu -q -n qemu-%{qemu_version}
>

Chris will have to answer this.


>
> 4. The current qemu build is configured with the default setting to
> build for all architectures but most of the arch's aren't used by
> RTEMS and/or don't have machine support for same bsps, so I've added a
> --target-list to only build the targets that have a corresponding bsp
> (sparc64-softmmu is missing as it runs into build issues, I forgot to
> mention in the initial results). However the list spills over 80 lines
> so should I make a %{qemu_targets} macro and if so where should I put
> it?
>

I like the idea of limiting the targets built. You are right that we don't
care about the others.

The style and variable name are Chris questions.


>
>  --make=%{__make} \
>  72 --target-list=arm-softmmu,i386-softmmu,lm32-softmmu,
> mips-softmmu,ppc-softmmu,sparc-softmmu
> \
>  73 ${VDE_CONFIG} \
>  74 --disable-smartcard-nss \
>
> Thanks,
>
> Cillian.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RSB Couverture-Qemu build queries

[Cillian O'Donnell]

Hi,

I am getting the RSB to build Couverture-Qemu and I just want to check
a few things I have done so far.

1. There are about 5 patches applied to the current qemu build. Only
one of which applies cleanly to the Couverture build. Do you want me
to try and fix these up, comment them out and leave a note for
whoever wants to fix them or remove them completely? The patches that
don't work are:

%patch add qemu
pw://patchwork.ozlabs.org/patch/406903/raw/Provide-the-missing-LIBUSB_LOG_LEVEL_-for-older-libusb-or-FreeBSD.-Providing-just-the-needed-value-as-a-defined..patch

%patch add qemu
https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-
play.patch

%patch add qemu
https://gaisler.org/qemu/0002-LEON3-Build-AMBA-plug-and-play-records-from-high-lev.patch

%patch add qemu
https://gaisler.org/qemu/0003-LEON3-Init-UART-timers-and-CPU-if-we-run-a-RAM-image.patch


2. For this source setting section, is the first part just dealing
with the case were this a packaged release so a tar of the download is
already included with it?

%if %{rsb_released} && %{!defined without_release_url}
%source set qemu
%{rtems_release_url}/%{rtems_version}/sources/qemu-git-42d58e7.tar.xz
%else
%source set qemu
https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
%endif

3. What does the -q option do in the %prep section of the build, this
option shows up in examples in the docs but there is no description of
what it does?

%source setup qemu -q -n qemu-%{qemu_version}

4. The current qemu build is configured with the default setting to
build for all architectures but most of the arch's aren't used by
RTEMS and/or don't have machine support for same bsps, so I've added a
--target-list to only build the targets that have a corresponding bsp
(sparc64-softmmu is missing as it runs into build issues, I forgot to
mention in the initial results). However the list spills over 80 lines
so should I make a %{qemu_targets} macro and if so where should I put
it?

 --make=%{__make} \
 72 
--target-list=arm-softmmu,i386-softmmu,lm32-softmmu,mips-softmmu,ppc-softmmu,sparc-softmmu
\
 73 ${VDE_CONFIG} \
 74 --disable-smartcard-nss \

Thanks,

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

[PATCH 4/7] sb: Backport from master the '--rsb-file=' option.

[Chris Johns]

Upates #3033.
---
 source-builder/sb/build.py|  51 ++---
 source-builder/sb/download.py | 101 --
 2 files changed, 104 insertions(+), 48 deletions(-)

diff --git a/source-builder/sb/build.py b/source-builder/sb/build.py
index 15d569d..b995e6b 100644
--- a/source-builder/sb/build.py
+++ b/source-builder/sb/build.py
@@ -209,8 +209,33 @@ class build:
 if sm is None:
 raise error.internal('source macro not found: %s in %s (%s)' % 
\
  (s, name, _map))
-url = self.config.expand(sm[2])
-src = download.parse_url(url, '_sourcedir', self.config, self.opts)
+opts = []
+url = []
+for sp in sm[2].split():
+if len(url) == 0 and sp[0] == '-':
+opts += [sp]
+else:
+url += [sp]
+if len(url) == 0:
+raise error.general('source URL not found: %s' % (' 
'.join(args)))
+#
+# Look for --rsb-file as an option we use as a local file name.
+# This can be used if a URL has no reasonable file name the
+# download URL parser can figure out.
+#
+file_override = None
+if len(opts) > 0:
+for o in opts:
+if o.startswith('--rsb-file'):
+   os_ = o.split('=')
+   if len(os_) != 2:
+   raise error.general('invalid --rsb-file option: %s' 
% (' '.join(args)))
+   if os_[0] != '--rsb-file':
+   raise error.general('invalid --rsb-file option: %s' 
% (' '.join(args)))
+   file_override = os_[1]
+opts = [o for o in opts if not o.startswith('--rsb-')]
+url = self.config.expand(' '.join(url))
+src = download.parse_url(url, '_sourcedir', self.config, 
self.opts, file_override)
 download.get_file(src['url'], src['local'], self.opts, self.config)
 if 'symlink' in src:
 sname = name.replace('-', '_')
@@ -303,6 +328,22 @@ class build:
 url += [pp]
 if len(url) == 0:
 raise error.general('patch URL not found: %s' % (' 
'.join(args)))
+#
+# Look for --rsb-file as an option we use as a local file name.
+# This can be used if a URL has no reasonable file name the
+# download URL parser can figure out.
+#
+file_override = None
+if len(opts) > 0:
+for o in opts:
+if o.startswith('--rsb-file'):
+   os_ = o.split('=')
+   if len(os_) != 2:
+   raise error.general('invalid --rsb-file option: %s' 
% (' '.join(args)))
+   if os_[0] != '--rsb-file':
+   raise error.general('invalid --rsb-file option: %s' 
% (' '.join(args)))
+   file_override = os_[1]
+opts = [o for o in opts if not o.startswith('--rsb-')]
 if len(opts) == 0:
 opts = default_opts
 else:
@@ -312,12 +353,10 @@ class build:
 #
 # Parse the URL first in the source builder's patch directory.
 #
-patch = download.parse_url(url, '_patchdir', self.config, 
self.opts)
+patch = download.parse_url(url, '_patchdir', self.config, 
self.opts, file_override)
 #
-# If not in the source builder package check the source directory.
+# Download the patch
 #
-if not path.exists(patch['local']):
-patch = download.parse_url(url, '_patchdir', self.config, 
self.opts)
 download.get_file(patch['url'], patch['local'], self.opts, 
self.config)
 if 'compressed' in patch:
 patch['script'] = patch['compressed'] + ' ' +  patch['local']
diff --git a/source-builder/sb/download.py b/source-builder/sb/download.py
index c9cb792..5744844 100644
--- a/source-builder/sb/download.py
+++ b/source-builder/sb/download.py
@@ -26,6 +26,7 @@ from __future__ import print_function
 
 import hashlib
 import os
+import re
 import stat
 import sys
 try:
@@ -130,57 +131,62 @@ def _hash_check(file_, absfile, macros, remove = True):
 
 def _local_path(source, pathkey, config):
 for p in config.define(pathkey).split(':'):
-local = path.join(path.abspath(p), source['file'])
+local_prefix = path.abspath(p)
+local = path.join(local_prefix, source['file'])
 if source['local'] is None:
-source['local_prefix'] = path.abspath(p)
+source['local_prefix'] = local_prefix
 source['local'] = local
 if path.exists(local):
-source['local_

Re: rsb only download option

[Chris Johns]

On 14/06/2017 01:18, punit vara wrote:
> 
> Is there any way to download packages for rsb and then build locally
> rather than downloading while installing rsb ?
> 
> If there is no option for only download , I would suggest to provide
> something like download all the packages required for rsb and then
> developer can install it locally.

To download just the source and not build anything you can use:

 $ ../source-builder/sb-set-builder --dry-run --with-download \
--without-error-report \
--without-release-url 4.12/rtems-all

The 'sources' and 'patches' directories will contain the source. Copy the
contents of both directories to a single directory, CD, DVD, server, where ever.
If done on the 4.11 branch the result should look something like:

https://ftp.rtems.org/pub/rtems/releases/4.11/rc/4.11.2-rc4/sources/

You should then be able to use the option:

 --url=file://something/local/where/the/source/is

Releasing and deploying can use a VERSION file.

If you are deploying the RSB in an environment such as a project or company and
you wish to create a special version that is not a formal RTEMS release create a
'VERSION' file in the root directory of the RSB.

NOTES:
1. Please avoid using a release string that matches the RTEMS ones we use,
please use something that identifies the deployed release as something you own
and support. For example 4.12-pv1.
2. Only do this if you need to support a team on a common release point and you
are prepared to support the release yourself. Otherwise use git.

The format of the file can be seen by looking the RTEMS 4.11.2-rc4 RSB release.:

[version]
release = 4.11.2-rc4
release_path = 
https://ftp.rtems.org/pub/rtems/releases/4.11/rc/4.11.2-rc4/sources

[hashes]
rtems-tools-4.11.2-rc4.tar.xz = sha512
023e8874f6ee3ef8493caf7e60dc4b6b4b95bd16c0d34080f5a316c03e0f08ee6fe6b7b2f0c8cbd025e3dbbe44e40ebb2f3f46613694d85c34c4b9795195dfc4
rtems-4.11.2-rc4.tar.xz = sha512
c7ec3d1e0f6e4c75caec6db8b53e2ef68754225d82b99fba2c2e9cc6ce6e36c4e8348f289a4ba4b3b2554953e402277ff2c9991c8d33de89546b719c0a2ee7d2

It is an INI format file. The 'hashes' section is used to manage the dependence
issues requiring a hash for the released version when the RSB has source links
that are git repos.

> Last time when I was gsoc student it
> used to take around 10-12 hours for building RSB. This idea could be
> helpful to students/developers lives in cities where internet
> connections are pretty low and still want to contribute to RTEMS
> organization.
> 
> What do you guys think about this ?
> 

This is something we need to support. Some companies have no or limited internet
support.

If you could test this and contribute with fixes and/or documentation that would
be awesome. I would welcome documentation for the RSB that details standalone
set ups and deployment.

Thank you for asking.

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

Re: [PATCH] docs/rsb/configuration.rst: Fix typos, grammar.

[Chris Johns]

On 14/06/2017 04:17, Cillian O'Donnell wrote:
> ---
>  rsb/configuration.rst | 56 
> +--
>  1 file changed, 28 insertions(+), 28 deletions(-)

Pushed. Thank you.

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

[PATCH] docs/rsb/configuration.rst: Fix typos, grammar.

[Cillian O'Donnell]

---
 rsb/configuration.rst | 56 +--
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/rsb/configuration.rst b/rsb/configuration.rst
index 62fc073..b2745a5 100644
--- a/rsb/configuration.rst
+++ b/rsb/configuration.rst
@@ -115,18 +115,18 @@ supported compression formats are:
 ``xy``:
   XY
 
-The output of the decompression tool is feed to the standard ``tar`` utility if
+The output of the decompression tool is fed to the standard ``tar`` utility if
 not a ZIP file and unpacked into the build directory. ZIP files are unpacked by
 the decompression tool and all other files must be in the tar file format.
 
 The ``%source`` directive typically supports a single source file tar or zip
 file. The ``set`` command is used to set the URL for a specific source
-group. The first set command encoutner is registered and any further set
+group. The first set command encountered is registered and any further set
 commands are ignored. This allows you to define a base standard source location
 and override it in build and architecture specific files. You can also add
 extra source files to a group. This is typically done when a collection of
 source is broken down in a number of smaller files and you require the full
-package. The source's ``setup`` command must reide in the ``%prep:`` section
+package. The source's ``setup`` command must reside in the ``%prep:`` section
 and it unpacks the source code ready to be built.
 
 If the source URL references the GitHub API server https://api.github.com/ a
@@ -584,7 +584,7 @@ information is kept updated and accurate::
 
 The next section defines the source and any patches. In this case there is a
 single source package and it can be downloaded using the HTTP protocol. The RSB
-knows this is GZip'ped tar file. If more than one package package is needed add
+knows this is GZip'ped tar file. If more than one package is needed, add
 them increasing the index. The ``gcc-4.8-1.cfg`` configuration contains
 examples of more than one source package as well as conditionally including
 source packages based on the outer configuration options::
@@ -642,7 +642,7 @@ control. Newlib is taken directly from its CVS repository.
 Next is the building phase and for the DTC example this is simply a matter of
 running ``make``. Note the use of the RSB macros for commands. In the case of
 ``%{__make}`` it maps to the correct make for your host. In the case of BSD
-systems we need to use the GNU make and not the GNU make.
+systems we need to use the BSD make and not the GNU make.
 
 If your package requires a configuration stage you need to run this before the
 make stage. Again the GCC common configuration file provides a detailed 
example::
@@ -749,10 +749,10 @@ To build this you can use something similar to::
 The build is for a FreeBSD host and the prefix is for user installed
 packages. In this example I cannot let the source builder perform the install
 because I never run the RSB with root priviledges so a build set or bset tar
-file is created. This can then be installed using root privildges.
+file is created. This can then be installed using root priviledges.
 
 The command also supplies the ``--trace`` option. The output in the log file
-will contian all the macros.
+will contain all the macros.
 
 Debugging
 ~
@@ -768,7 +768,7 @@ phases. These are usually a mix of shell script bugs or 
package set up or
 configuration bugs. Here you can use any normal shell script type debug
 technique such as ``set +x`` to output the commands or ``echo``
 statements. Debugging package related issues may require you start a build with
-teh RSB and supply ``--no-clean`` option and then locate the build directories
+the RSB and supply ``--no-clean`` option and then locate the build directories
 and change directory into them and manually run commands until to figure what
 the package requires.
 
@@ -823,7 +823,7 @@ The script language is implemented in terms of macros. The 
built-in list is:
   Define a source code package. This macro has a number appended.
 
 ``%patch``:
-  Define a patch. This macro has a is number appended.
+  Define a patch. This macro has a number appended.
 
 ``%hash``:
   Define a checksum for a source or patch file.
@@ -1018,7 +1018,7 @@ macro. The build block is a series of shell commands that 
execute to build the
 package. It assumes all source code has been unpacked, patch and adjusted so
 the build will succeed.
 
-The following is an example take from the GutHub STLink project. The STLink is
+The following is an example take from the GitHub STLink project. The STLink is
 a JTAG debugging device for the ST ARM family of processors::
 
 %build
@@ -1078,7 +1078,7 @@ a JTAG debugging device for the ST ARM family of 
processors::
 
 The ``%install`` macro starts a block that continues until the next block
 macro. The install block is a series of shell commands that execute to install
-the package. You can

rsb only download option

[punit vara]

Hi

Is there any way to download packages for rsb and then build locally
rather than downloading while installing rsb ?

If there is no option for only download , I would suggest to provide
something like download all the packages required for rsb and then
developer can install it locally. Last time when I was gsoc student it
used to take around 10-12 hours for building RSB. This idea could be
helpful to students/developers lives in cities where internet
connections are pretty low and still want to contribute to RTEMS
organization.

What do you guys think about this ?

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

[PATCH 2/2] docs/rsb/quick-start.rst: Fix typos, hard coded paths, version

[Cillian O'Donnell]

---
 rsb/quick-start.rst | 242 ++--
 1 file changed, 121 insertions(+), 121 deletions(-)

diff --git a/rsb/quick-start.rst b/rsb/quick-start.rst
index f39c0a6..387ab61 100644
--- a/rsb/quick-start.rst
+++ b/rsb/quick-start.rst
@@ -42,13 +42,13 @@ difficult to manage in production systems.
 The RSB by default will install (copy) the executables to a directory tree
 under the *prefix* you supply. To use the tools once finished just set your
 path to the ``bin`` directory under the *prefix* you use. In the examples
-that follow the *prefix* is ``$HOME/development/rtems/4.11`` and is set
+that follow the *prefix* is ``$HOME/development/rtems/4.12`` and is set
 using the ``--prefix`` option so the path you need to configure to build
 applications can be set with the following in a BASH shell:
 
 .. code-block:: shell
 
-  $ export PATH=$HOME/development/rtems/4.11/bin:$PATH
+  $ export PATH=$HOME/development/rtems/4.12/bin:$PATH
 
 Make sure you place the RTEMS tool path at the front of your path so they
 are searched first. RTEMS can provide newer versions of some tools your
@@ -74,15 +74,15 @@ Setup
 Setup a development work space::
 
 $ cd
-$ mkdir -p development/rtems/src
-$ cd development/rtems/src
+$ mkdir -p development/rtems
+$ cd development/rtems
 
 The RTEMS Source Builder is distributed as source. It is Python code so all you
 need to do is download the release's RSB tarball or clone the code directly
 from the RTEMS GIT repository::
 
-$ git clone git://git.rtems.org/rtems-source-builder.git
-$ cd rtems-source-builder
+$ git clone git://git.rtems.org/rtems-source-builder.git rsb
+$ cd rsb
 
 .. topic:: Workspaces
 
@@ -118,7 +118,7 @@ given a list of warnings about executable files not in the 
expected location
 however the executable was located somewhere in your environment's path. You
 will need to check each tool to determine if this is an issue. An executable
 not in the standard location may indicate it is not the host operating system's
-standard tool. It maybe ok or it could be buggy, only you can determine this.
+standard tool. It may be ok or it could be buggy, only you can determine this.
 
 The :ref:`Hosts` section lists packages you should install for common host
 operating systems. It maybe worth checking if you have those installed.
@@ -208,30 +208,30 @@ Building
 The quick start builds a SPARC tool set::
 
 $ ../source-builder/sb-set-builder --log=l-sparc.txt \   <1>
-  --prefix=$HOME/development/rtems/4.11 \   <2>
-  4.11/rtems-sparc   <3>
-Source Builder - Set Builder, v0.2.0
-Build Set: 4.11/rtems-sparc
+  --prefix=$HOME/development/rtems/4.12 \   <2>
+  4.12/rtems-sparc   <3>
+RTEMS Source Builder - Set Builder, 4.12
+Build Set: 4.12/rtems-sparc
 config: expat-2.1.0-1.cfg<4>
 package: expat-2.1.0-x86_64-freebsd9.1-1
 building: expat-2.1.0-x86_64-freebsd9.1-1
-config: tools/rtems-binutils-2.22-1.cfg<5>
-package: sparc-rtems4.11-binutils-2.22-1
-building: sparc-rtems4.11-binutils-2.22-1
-config: tools/rtems-gcc-4.7.2-newlib-1.20.0-1.cfg   <6>
-package: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
-building: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
-config: tools/rtems-gdb-7.5.1-1.cfg  <7>
-package: sparc-rtems4.11-gdb-7.5.1-1
-building: sparc-rtems4.11-gdb-7.5.1-1
-installing: rtems-4.11-sparc-rtems4.11-1 -> 
/home/chris/development/rtems/4.11 <8>
-installing: rtems-4.11-sparc-rtems4.11-1 -> 
/home/chris/development/rtems/4.11
-installing: rtems-4.11-sparc-rtems4.11-1 -> 
/home/chris/development/rtems/4.11
-installing: rtems-4.11-sparc-rtems4.11-1 -> 
/home/chris/development/rtems/4.11
+config: tools/rtems-binutils-2.28-1.cfg<5>
+package: sparc-rtems4.12-binutils-2.28-1
+building: sparc-rtems4.12-binutils-2.28-1
+config: tools/rtems-gcc-7.1.0-newlib-2.5.0-1.cfg   <6>
+package: sparc-rtems4.12-gcc-7.1.0-newlib-2.5.0-1
+building: sparc-rtems4.12-gcc-7.1.0-newlib-2.5.0-1
+config: tools/rtems-gdb-7.12.1-1.cfg  <7>
+package: sparc-rtems4.12-gdb-7.12.1-1
+building: sparc-rtems4.12-gdb-7.12.1-1
+installing: rtems-4.12-sparc-rtems4.12-1 -> $HOME/development/rtems/4.12 
<8>
+installing: rtems-4.12-sparc-rtems4.12-1 -> $HOME/development/rtems/4.12
+installing: rtems-4.12-sparc-rtems4.12-1 -> $HOME/development/rtems/4.12
+installing: rtems-4.12-sparc-rtems4.12-1 -> $HOME/development/rtems/4.12
 cleaning: expat-2.1.0-x86_64-freebsd9.1-1 <9>
-cleaning: sparc-rtems4.11-binutils-2.22-1
-cleaning: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
-cleaning: sparc-rtems4.11-gdb-7.5.1-1
+cleaning: sparc-rtems4.12-b

Re: GSOC: building RSB

[Gedare Bloom]

Yes, it is not mandatory to use the RSB. However, the RSB helps ensure
consistency across the community, and is easier to maintain and
support than the variety of roll-your-own build scripts that each
developer used to keep independently.

On Sun, Apr 2, 2017 at 10:57 AM, faizan khan <faizan10...@gmail.com> wrote:
> I am using ubuntu and I have almost all the tools necessary. Can't I just
> build the RTEMS and run it via gdb on a target or QEMU...
>
> cheers,
> Faizan
>
> ___
> 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

GSOC: building RSB

[faizan khan]

I am using ubuntu and I have almost all the tools necessary. Can't I just
build the RTEMS and run it via gdb on a target or QEMU...

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

Re: qemu RSB bset with gcc 6.3.0

[Chris Johns]

On 16/2/17 2:19 am, Joel Sherrill wrote:
> Hi again,
> 
> I am taking a shot at fixing this and fetching the patches from the
> Freedesktop
> ticket.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=95326
> 

Is this fixed in a later glib?

> When I use wget to fetch the patch link, the file names are of the form:
> 
> gdate.c?id=0817af40e8c74c721c30f6ef482b1f53d12044c7
> 52ecda6335add96494a178186bf7d490
> 
> And the RSB is fetching both as "gdate.c" 
> 
> How do I fetch these patches and specify the md5 sum?
> 
> %patch add glib
> https://git.gnome.org/browse/glib/patch/glib/gdate.c?id=0817af40e8c74c721c30f6ef482b1f53d12044c7
> %hash md5 gdate.c?id=0817af40e8c74c721c30f6ef482b1f53d12044c7
> 52ecda6335add96494a178186bf7d490
> 
> %patch add glib
> https://git.gnome.org/browse/glib/patch/glib/gdate.c?id=8cdbc7fb2c8c876902e457abe46ee18a0b134486
> %hash md5 gdate.c?id=8cdbc7fb2c8c876902e457abe46ee18a0b134486
> 16bc0b96bbfa7c2b350df6f4aff2db29

The hash should be against the actual file name. There is a setting that
allows you to override the auto-detection of the file. Add --rsb-file to
the patch command, see
rtems/config/tools/rtems-gcc-6-20160327-newlib-2.4.0-1.cfg for an example.

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

Re: qemu RSB bset with gcc 6.3.0

[Joel Sherrill]

Hi again,

I am taking a shot at fixing this and fetching the patches from the
Freedesktop
ticket.

https://bugs.freedesktop.org/show_bug.cgi?id=95326

When I use wget to fetch the patch link, the file names are of the form:

gdate.c?id=0817af40e8c74c721c30f6ef482b1f53d12044c7
52ecda6335add96494a178186bf7d490

And the RSB is fetching both as "gdate.c"

How do I fetch these patches and specify the md5 sum?

%patch add glib
https://git.gnome.org/browse/glib/patch/glib/gdate.c?id=0817af40e8c74c721c30f6ef482b1f53d12044c7
%hash md5 gdate.c?id=0817af40e8c74c721c30f6ef482b1f53d12044c7
52ecda6335add96494a178186bf7d490

%patch add glib
https://git.gnome.org/browse/glib/patch/glib/gdate.c?id=8cdbc7fb2c8c876902e457abe46ee18a0b134486
%hash md5 gdate.c?id=8cdbc7fb2c8c876902e457abe46ee18a0b134486
16bc0b96bbfa7c2b350df6f4aff2db29

Thanks.

--joel


On Wed, Feb 15, 2017 at 7:10 AM, Joel Sherrill <j...@rtems.org> wrote:

>
>
> On Feb 14, 2017 8:47 PM, "Chris Johns" <chr...@rtems.org> wrote:
>
> On 15/02/2017 04:00, Joel Sherrill wrote:
>
>> Hi
>>
>> Helping someone using Debian unstable which uses gcc 6.3.0. glib has
>> code using strftime() which is now flagged and glib is compiled with
>> -Werror.
>>
>> gdate.c:2497 in glib 2.39. On the glib master at github, it is line 2500
>> and
>> the code is fixed with a blame/comment in 2002.
>>
>> My first thought was to bump the glib version but glib is at 2.50 and
>> I am concerned about interface changes. Besides, this isn't fixed
>> on their master from what we saw.
>>
>> Someone reported this to Freedesktop with this issue:
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=95326
>>
>> Any thoughts?
>>
>>
> I have some patches sitting around somewhere to bump a few bits and pieces
> used to build qemu when I tried to build qemu on OSX. I could not get it to
> build and I did not have the time to complete the work.
>
>
> I filed a ticket and think I have the solution based on that ticket. Just
> need to spend the time updating the package.
>
> I don't see any reason to investigate rebaselining qemu yet.
>
>
> Chris
> ___
> 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: qemu RSB bset with gcc 6.3.0

[Chris Johns]

On 15/02/2017 04:00, Joel Sherrill wrote:

Hi

Helping someone using Debian unstable which uses gcc 6.3.0. glib has
code using strftime() which is now flagged and glib is compiled with
-Werror.

gdate.c:2497 in glib 2.39. On the glib master at github, it is line 2500 and
the code is fixed with a blame/comment in 2002.

My first thought was to bump the glib version but glib is at 2.50 and
I am concerned about interface changes. Besides, this isn't fixed
on their master from what we saw.

Someone reported this to Freedesktop with this issue:

https://bugs.freedesktop.org/show_bug.cgi?id=95326

Any thoughts?



I have some patches sitting around somewhere to bump a few bits and 
pieces used to build qemu when I tried to build qemu on OSX. I could not 
get it to build and I did not have the time to complete the work.


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

qemu RSB bset with gcc 6.3.0

[Joel Sherrill]

Hi

Helping someone using Debian unstable which uses gcc 6.3.0. glib has
code using strftime() which is now flagged and glib is compiled with
-Werror.

gdate.c:2497 in glib 2.39. On the glib master at github, it is line 2500 and
the code is fixed with a blame/comment in 2002.

My first thought was to bump the glib version but glib is at 2.50 and
I am concerned about interface changes. Besides, this isn't fixed
on their master from what we saw.

Someone reported this to Freedesktop with this issue:

https://bugs.freedesktop.org/show_bug.cgi?id=95326

Any thoughts?

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

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

[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 <http://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" <tokencol...@gmail.com
> <mailto:tokencol...@gmail.com>> 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
> 
> <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
> <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
> <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
> <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
> <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 <mailto:devel@rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel
> <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).

[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).

[Gedare Bloom]

On Fri, Feb 10, 2017 at 3:27 PM, Alan Cudmore <alan.cudm...@gmail.com> 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 <j...@rtems.org> 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" <tokencol...@gmail.com> 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).

[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 <j...@rtems.org> 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" <tokencol...@gmail.com> 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).

[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" <tokencol...@gmail.com> 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

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

[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/

Re: PATCH for RSB/gdb

[Joel Sherrill]

I just posted a patch series which should include all of my
updates and Jiri's patches. Please review.

Thanks Jiri.

--joel

On Mon, Nov 14, 2016 at 7:25 AM, Jiri Gaisler <j...@gaisler.se> wrote:

> The previous patch also contained a non-related fix to binutils, sorry
> for that. I have attached the correct patch.
>
> Jiri.
>
>
> On 14/11/16 13:58, Jiri Gaisler wrote:
> > I have attached a patch for RSB/gdb-7.11 that brings the sis simulator
> > up to date and adds support for leon2/3 emulation. Some seg-faults have
> > also been fixed, and breakpoints and watchpoints work correctly with gdb
> > and DDD now. The patch is pulled in from gaisler.org, and consists of
> > the following 9 parts:
> >
>
>
> ___
> 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 for RSB/gdb

[Jiri Gaisler]

The previous patch also contained a non-related fix to binutils, sorry
for that. I have attached the correct patch.

Jiri.


On 14/11/16 13:58, Jiri Gaisler wrote:
> I have attached a patch for RSB/gdb-7.11 that brings the sis simulator
> up to date and adds support for leon2/3 emulation. Some seg-faults have
> also been fixed, and breakpoints and watchpoints work correctly with gdb
> and DDD now. The patch is pulled in from gaisler.org, and consists of
> the following 9 parts:
>

diff --git a/rtems/config/tools/rtems-gdb-7.11-1.cfg b/rtems/config/tools/rtems-gdb-7.11-1.cfg
index 5f7cf78..308427c 100644
--- a/rtems/config/tools/rtems-gdb-7.11-1.cfg
+++ b/rtems/config/tools/rtems-gdb-7.11-1.cfg
@@ -18,12 +18,8 @@
 #
 # ERC32 simulator fixes.
 #
-%patch add gdb %{rtems_gdb_patches}/gdb-7.11-erc32-endian-fix.diff
-%hash md5 gdb-7.11-erc32-endian-fix.diff d0cd4207f0c7d04cb9bc9b918eebfdc6
-%patch add gdb %{rtems_gdb_patches}/gdb-7.11-erc32-printf_filtered.diff
-%hash md5 gdb-7.11-erc32-printf_filtered.diff 1e03d4c90c0cb4ded7c08963210f7127
-%patch add gdb %{rtems_gdb_patches}/gdb-7.11-erc32-common-run.diff
-%hash md5 gdb-7.11-erc32-common-run.diff e986ce115b81f7dd45f36d6f257af541
+%patch add gdb https://gaisler.org/rsb/gdb-7.11-sis-leon2-leon3.diff
+%hash md5 gdb-7.11-sis-leon2-leon3.diff 88eac302290ea2a58bd7e08aaca94efd
 
 %if %{_build_os} == freebsd
  %patch add gdb -p0 %{rtems_gdb_patches}/patch-gdb-python-python-config.py
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

PATCH for RSB/gdb

[Jiri Gaisler]

I have attached a patch for RSB/gdb-7.11 that brings the sis simulator
up to date and adds support for leon2/3 emulation. Some seg-faults have
also been fixed, and breakpoints and watchpoints work correctly with gdb
and DDD now. The patch is pulled in from gaisler.org, and consists of
the following 9 parts:

0001-sim-erc32-Use-gdb-callback-for-UART-I-O-when-linked-.patch
0002-sim-erc32-Access-memory-subsystem-through-struct-mem.patch
0003-sim-erc32-Move-local-extern-declarations-into-sis.h.patch
0004-Add-support-for-LEON3-processor-emulation.patch
0005-sim-erc32-Add-support-for-LEON2-processor-emulation.patch
0006-sim-erc32-Updated-documentation.patch
0007-sim-erc32-Add-data-watchpoint-support.patch
0008-Add-watchpoint-support-to-gdb-simulator-interface.patch
0009-sim-erc32-Added-back-original-run.c.patch

The 'run' command now also supports leon2/3 emulation, by adding '-a
-leon2' or '-a leon3' at startup. This can be used to automate testing
of the erc32, leon2 and leon3 bsp's. I would suggest that the 'sis' bsp
is dropped for 4.12 as it is no longer needed ...

Jiri.

diff --git a/rtems/config/tools/rtems-binutils-2.26-1.cfg b/rtems/config/tools/rtems-binutils-2.26-1.cfg
index 37ec3d5..d51496c 100644
--- a/rtems/config/tools/rtems-binutils-2.26-1.cfg
+++ b/rtems/config/tools/rtems-binutils-2.26-1.cfg
@@ -16,6 +16,11 @@
 %hash sha512 binutils-2.26-rtems-aarch64-x86_64.patch 2236cc22dda60d5c18a2ab5abc0f44bf487794f7c0899382bf49233e789e1fb34ce28b0f7a85069642f7cc06bd34d7634a441a8d92bf890de57bb89cc398349f
 
 #
+# SPARC GAS fixes.
+#
+%patch add binutils https://gaisler.org/rsb/binutils-2.26-gas-reloc.patch
+%hash md5 binutils-2.26-gas-reloc.patch 1b88374118c2da61eeaca9c4ba1ce42c
+
 # Enable deterministic archives by default. This will be the default
 # there all tools using this binutils will create deterministic
 # archives.
diff --git a/rtems/config/tools/rtems-gdb-7.11-1.cfg b/rtems/config/tools/rtems-gdb-7.11-1.cfg
index 5f7cf78..308427c 100644
--- a/rtems/config/tools/rtems-gdb-7.11-1.cfg
+++ b/rtems/config/tools/rtems-gdb-7.11-1.cfg
@@ -18,12 +18,8 @@
 #
 # ERC32 simulator fixes.
 #
-%patch add gdb %{rtems_gdb_patches}/gdb-7.11-erc32-endian-fix.diff
-%hash md5 gdb-7.11-erc32-endian-fix.diff d0cd4207f0c7d04cb9bc9b918eebfdc6
-%patch add gdb %{rtems_gdb_patches}/gdb-7.11-erc32-printf_filtered.diff
-%hash md5 gdb-7.11-erc32-printf_filtered.diff 1e03d4c90c0cb4ded7c08963210f7127
-%patch add gdb %{rtems_gdb_patches}/gdb-7.11-erc32-common-run.diff
-%hash md5 gdb-7.11-erc32-common-run.diff e986ce115b81f7dd45f36d6f257af541
+%patch add gdb https://gaisler.org/rsb/gdb-7.11-sis-leon2-leon3.diff
+%hash md5 gdb-7.11-sis-leon2-leon3.diff 88eac302290ea2a58bd7e08aaca94efd
 
 %if %{_build_os} == freebsd
  %patch add gdb -p0 %{rtems_gdb_patches}/patch-gdb-python-python-config.py
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: 4.10 RSB h8300 tools on CentOS 7

[Joel Sherrill]

I should have mentioned. This is using the 4.10 branch of the
RSB and not the rc1 candidate. I started doing this before you
cut that.

On Sun, Sep 4, 2016 at 7:02 PM, Chris Johns <chr...@rtems.org> wrote:

> On 05/09/2016 04:46, Joel Sherrill wrote:
>
>> Hi
>>
>>
> Thank you for testing 4.10 RC1 and reporting the issues.
>
> The h8300 tools fail to build on CentOS 7:
>>
>> /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/
>> build/h8300-rtems4.10-gcc-4.4.7-newlib-1.18.0-x86_64-linux-
>> gnu-1/build/./gcc/xgcc
>> -B/data/home/joel/rtems-4.11-work/rtems-source-builder/rtems
>> /build/h8300-rtems4.10-gcc-4.4.7-newlib-1.18.0-x86_64-
>> linux-gnu-1/build/./gcc/
>> -nostdinc
>> -B/data/home/joel/rtems-4.11-work/rtems-source-builder/rtems
>> /build/h8300-rtems4.10-gcc-4.4.7-newlib-1.18.0-x86_64-
>> linux-gnu-1/build/h8300-rtems4.10/newlib/
>> -isystem
>> /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/
>> build/h8300-rtems4.10-gcc-4.4.7-newlib-1.18.0-x86_64-linux-
>> gnu-1/build/h8300-rtems4.10/newlib/targ-include
>> -isystem
>> /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/
>> build/h8300-rtems4.10-gcc-4.4.7-newlib-1.18.0-x86_64-linux-
>> gnu-1/gcc-4.4.7/newlib/libc/include
>> -B/home/joel/rtems-4.11-work/tools/4.10/h8300-rtems4.10/bin/
>> -B/home/joel/rtems-4.11-work/tools/4.10/h8300-rtems4.10/lib/ -isystem
>> /home/joel/rtems-4.11-work/tools/4.10/h8300-rtems4.10/include -isystem
>> /home/joel/rtems-4.11-work/tools/4.10/h8300-rtems4.10/sys-include
>> -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
>> -DPACKAGE_VERSION=\"1.18.0\" -DPACKAGE_STRING=\"newlib\ 1.18.0\"
>> -DPACKAGE_BUGREPORT=\"\" -I.
>> -I../../../../../../gcc-4.4.7/newlib/libc/iconv/lib -D_COMPILING_NEWLIB
>> -DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED
>> -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE
>> -DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT
>> -D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN
>> -fno-builtin  -g -O2   -c -o lib_a-iconvnls.o `test -f 'iconvnls.c'
>> || echo '../../../../../../gcc-4.4.7/newlib/libc/iconv/lib/'`iconvnls.c
>> /tmp/ccweOScM.s: Assembler messages:
>> /tmp/ccweOScM.s:123: Warning: operand #0x out of range.
>> /tmp/ccj0h68L.s: Assembler messages:
>> /tmp/ccj0h68L.s:26: Warning: operand #0xfff4 out of range.
>> /tmp/cckRh3aM.s: Assembler messages:
>> /tmp/cckRh3aM.s:26: Warning: operand #0xfffd out of range.
>> /tmp/cckRh3aM.s:50: Warning: operand #0x out of range.
>> /tmp/cckRh3aM.s:110: Warning: operand #0xfff4 out of range.
>> /tmp/cckRh3aM.s:118: Warning: operand #0xfffd out of range.
>> /tmp/cckRh3aM.s:142: Warning: operand #0x out of range.
>>
>>
> I have pushed a change to the RSB to fix this so h8300 builds on FreeBSD.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

4.10 RSB h8300 tools on CentOS 7

[Joel Sherrill]

Hi

The h8300 tools fail to build on CentOS 7:

/data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/h8300-rtems4.10-gcc-4.4.7-newlib-1.18.0-x86_64-linux-gnu-1/build/./gcc/xgcc
-B/data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/h8300-rtems4.10-gcc-4.4.7-newlib-1.18.0-x86_64-linux-gnu-1/build/./gcc/
-nostdinc
-B/data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/h8300-rtems4.10-gcc-4.4.7-newlib-1.18.0-x86_64-linux-gnu-1/build/h8300-rtems4.10/newlib/
-isystem
/data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/h8300-rtems4.10-gcc-4.4.7-newlib-1.18.0-x86_64-linux-gnu-1/build/h8300-rtems4.10/newlib/targ-include
-isystem
/data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/h8300-rtems4.10-gcc-4.4.7-newlib-1.18.0-x86_64-linux-gnu-1/gcc-4.4.7/newlib/libc/include
-B/home/joel/rtems-4.11-work/tools/4.10/h8300-rtems4.10/bin/
-B/home/joel/rtems-4.11-work/tools/4.10/h8300-rtems4.10/lib/ -isystem
/home/joel/rtems-4.11-work/tools/4.10/h8300-rtems4.10/include -isystem
/home/joel/rtems-4.11-work/tools/4.10/h8300-rtems4.10/sys-include
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.18.0\" -DPACKAGE_STRING=\"newlib\ 1.18.0\"
-DPACKAGE_BUGREPORT=\"\" -I.
-I../../../../../../gcc-4.4.7/newlib/libc/iconv/lib -D_COMPILING_NEWLIB
-DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED
-DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL
-DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS
-D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -fno-builtin  -g -O2   -c -o
lib_a-iconvnls.o `test -f 'iconvnls.c' || echo
'../../../../../../gcc-4.4.7/newlib/libc/iconv/lib/'`iconvnls.c
/tmp/ccweOScM.s: Assembler messages:
/tmp/ccweOScM.s:123: Warning: operand #0x out of range.
/tmp/ccj0h68L.s: Assembler messages:
/tmp/ccj0h68L.s:26: Warning: operand #0xfff4 out of range.
/tmp/cckRh3aM.s: Assembler messages:
/tmp/cckRh3aM.s:26: Warning: operand #0xfffd out of range.
/tmp/cckRh3aM.s:50: Warning: operand #0x out of range.
/tmp/cckRh3aM.s:110: Warning: operand #0xfff4 out of range.
/tmp/cckRh3aM.s:118: Warning: operand #0xfffd out of range.
/tmp/cckRh3aM.s:142: Warning: operand #0x out of range.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: FYI - RSB tools and binutils 2.27

[Gedare Bloom]

P.S. you may like to see if there is a recent newlib snapshot
available or request one.

On Thu, Aug 25, 2016 at 3:29 PM, Gedare Bloom  wrote:
> Sebastian has more than once suggested we bump to gcc6 snapshot
>
> On Thu, Aug 25, 2016 at 3:27 PM, Joel Sherrill  wrote:
>> Hi
>>
>> Just a note that I am testing updating the binutils version to this now.
>>
>> Is there a gcc bump needed also?
>>
>> --joel
>>
>> ___
>> 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: FYI - RSB tools and binutils 2.27

[Gedare Bloom]

Sebastian has more than once suggested we bump to gcc6 snapshot

On Thu, Aug 25, 2016 at 3:27 PM, Joel Sherrill  wrote:
> Hi
>
> Just a note that I am testing updating the binutils version to this now.
>
> Is there a gcc bump needed also?
>
> --joel
>
> ___
> 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

FYI - RSB tools and binutils 2.27

[Joel Sherrill]

Hi

Just a note that I am testing updating the binutils version to this now.

Is there a gcc bump needed also?

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

[PATCH] Add Windows Subsystem for Linux to RSB Doc

[Alan Cudmore]

 doc/source-builder.txt | 56
+++---
 1 file changed, 44 insertions(+), 12 deletions(-)

diff --git a/doc/source-builder.txt b/doc/source-builder.txt
index 3bcc397..d676e63 100644
--- a/doc/source-builder.txt
+++ b/doc/source-builder.txt
@@ -39,7 +39,7 @@ from source and taught this tool. The RTEMS Source
Builder has been tested on:
 * <<_freebsd,FreeBSD>>
 * <<_netbsd,NetBSD>>
 * <<_macos,MacOS>>
-* <<_mint,Linux Mint>>
+* <<_linuxmint,LinuxMint>>
 * <<_opensuse,openSUSE>>
 * <<_raspbian,Raspbian>>
 * <<_ubuntu,Ubuntu>>
@@ -3112,6 +3112,15 @@ $ sudo apt-get build-dep binutils gcc g++ gdb unzip
git
 $ sudo apt-get install python2.7-dev
 -

+LinuxMint
+^
+zlib package is required on Linux Mint. It has a different name (other
+than the usual zlib-dev):
+
+-
+# sudo apt-get install zlib1g-dev
+-
+
 FreeBSD
 ~~~

@@ -3157,16 +3166,6 @@ The RTEMS Source Builder has been tested on Mountain
Lion. You will need to
 install the Xcode app using the _App Store_ tool, run Xcode and install the
 Developers Tools package within Xcode.

-Linux Mint
-^^
-
-zlib package is required on Linux Mint. It has a different name (other
-than the usual zlib-dev):
-
--
-# sudo apt-get install zlib1g-dev
--
-
 Mavericks
 ^

@@ -3204,13 +3203,15 @@ debugging experiences may vary and if this is an
issue please raised the topic
 on the RTEMS Users mailing list.

 Building the tools or some other packages may require a Unix or POSIX type
-shell. There are a few options, Cygwin and MSYS2. I recommend MSYS2.
+shell. There are a few options, Cygwin, MSYS2, and Windows Subsystem for
Linux
+(WSL) on Windows 10 with the 2016 Windows Anniversary Update. I recommend
MSYS2.

 .Ready To Go Windows Tools
 NOTE: From time to time I provide tools for Windows at
 http://ftp.rtems.org/pub/rtems/people/chrisj/source-builder/4.11/mingw32/

 MSYS2
+^

 This is a new version of the old MinGW project's original MSYS based
around the
 Arch Linux pacman packager. MSYS and MSYS2 are a specific fork of the
Cygwin
@@ -3237,6 +3238,7 @@ Install a suitable version of Python from
http://www.python.org/ and add it to
 the start of your path. The MSYS2 python does not work with waf.

 Cygwin
+^^

 Building on Windows is a little more complicated because the Cygwin shell
is
 used rather than the MSYS2 shell. The MSYS2 shell is simpler because the
@@ -3352,6 +3354,36 @@ reasons they cannot be avoided in all cases. Cygwin
and it's fork MSYS are
 fantastic pieces of software in a difficult environment. I have found
building
 a single tool tends to work, building all at once is harder.

+Windows Subsystem for Linux (WSL)
+^
+
+The Windows Subsystem for Linux is a port of the user mode binaries from
+Ubuntu 14.04 LTS to Windows 10. It was first made available in the August
2016
+Windows 10 Anniversary Update.
+
+WSL installs a Bash shell and many of the Ubuntu command line linux
utilities
+including a fully working apt-get command. Graphical or X-Windows
applciations
+are not supported.
+
+.Installing WSL
+NOTE: There are many articles on the internet describing how to install
WSL.
+Here is an example:
+https://msdn.microsoft.com/en-us/commandline/wsl/install_guide
+
+Once WSL is installed, using the RTEMS Source Builder is nearly the same as
+as using it on Ubuntu Linux 14.04. I had to install the following packages
+to allow RSB to work on WSL
+
+-
+$ sudo apt-get install autoconf automake bison flex binutils gcc \
+g++ gdb texinfo unzip ncurses-dev python-dev git zlib1g-dev make
+-
+
+Once the RSB toolchain is compiled, I was able to add the toolchain to my
path
+by editing .bashrc in my WSL home directory. For some reason, .profile was
not
+run when starting a bash shell like it does when logging into a real Ubuntu
+system.
+

 Build Status By Host
 
-- 
2.7.4 (Apple Git-66)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB toolchain builds on Windows 10/Windows Subsystem for Linux

[Alan Cudmore]

Sure. I did not take any notes when I did the first install and build, I'm
going to reinstall the linux environment and document what I had to do.

Alan


On Tue, Aug 9, 2016 at 8:06 PM, Chris Johns <chr...@rtems.org> wrote:

> On 09/08/2016 23:51, Alan Cudmore wrote:
>
>> I thought I would try the new Windows Subsystem for Linux to see how the
>> RSB toolchain build would go.
>> WSL is a port of the Ubuntu 14.04 user space binaries to the windows 10
>> kernel:
>> https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux
>>
>> The RSB toolchain builds the same here as it does on a native ubuntu
>> 14.04 machine. No problems or differences that I can tell.
>>
>> Note that I'm not advocating this, just reporting another option for
>> RTEMS developers :)
>>
>>
> Could you please update the doc in the RSB to mention this?
>
> Thanks
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Corrected a typo in RSB docs

[Sambeet Panigrahi]

From 1ddfd35822be6c99cee644ed62a716f3cb371ddb Mon Sep 17 00:00:00 2001
From: Sambeet Panigrahi <b313...@iiit-bh.ac.in>
Date: Mon, 1 Aug 2016 16:43:26 +0530
Subject: [PATCH] Corrected another typo in RSB Documentation

---
 doc/source-builder.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/source-builder.txt b/doc/source-builder.txt
index 967ca1c..b07b129 100644
--- a/doc/source-builder.txt
+++ b/doc/source-builder.txt
@@ -1078,7 +1078,7 @@ A package requires 3 files to be created:
 
 . The second file is an RTEMS version specific configuration file and it
   includes the RSB RTEMS BSP support. These configuration files reside in the
-  +rtems/config+ tree again under the FreeBSP port's path name. For example the
+  +rtems/config+ tree again under the FreeBSD port's path name. For example the
   NTP package is found in the +net+ directory of the FreeBSD ports tree so the
   NTP configuration path is +$$rtems/config/net/ntp-4.2.6p5-1.cfg$$+ for that
   specific version. The configuration file name typically provides version
-- 
1.9.1

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

Re: [PATCH] RSB: update newlib version built with gcc-4.9.3

[Chris Johns]

On 08/06/2016 23:51, Sebastian Huber wrote:

Given the file name rtems-gcc-4.9.3-newlib-2.4.0-1.cf, how does this fit
to the new file content? We have this *-N.cfg pattern throughout. What
is the rule for the N? Is it useful at all?


This was present when we had no branching in the repo to help manage 
incompatible differences. We tend to manage variations conditionally 
these days and this is a better approach so the need for the number is 
questionable. It you think there is value in removing the number please 
do so. I am not sure about partial removal, it may just make things 
confusing.


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

Re: [PATCH] RSB: update newlib version built with gcc-4.9.3

[Sebastian Huber]

On 08/06/16 00:49, Hesham Almatary wrote:

---
  rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg 
b/rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg
index 596a4a7..42f6cfa 100644
--- a/rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg
+++ b/rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg
@@ -3,10 +3,10 @@
  #
  
  %define gcc_version4.9.3

-%define newlib_version 2.4.0
+%define newlib_version 2.4.0.20160527
  
  %hash md5 gcc-%{gcc_version}.tar.bz2 6f831b4d251872736e8e9cc09746f327

-%hash sha512 newlib-2.4.0.tar.gz 
c60665e793dce2368a5baf23560beb50f641e1831854d702d1d7629fb6e9200cf814527f29796792a3d2dff81afee4255723df99ceb0732f99dd9580a17d2ac0
+%hash sha512 newlib-2.4.0.20160527.tar.gz 
09d0c8ac2a657e910eebfeeb7e5fcc6956591223fe499ed4717b5e719287148fc35e80835821fb5b6b586e371100737a7765a03c43f0c194cf67892484132d3f
  
  #

  # The gcc/newlib build instructions.


Given the file name rtems-gcc-4.9.3-newlib-2.4.0-1.cf, how does this fit 
to the new file content? We have this *-N.cfg pattern throughout. What 
is the rule for the N? Is it useful at all?


--
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.

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

[PATCH] RSB: update newlib version built with gcc-4.9.3

[Hesham Almatary]

---
 rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg 
b/rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg
index 596a4a7..42f6cfa 100644
--- a/rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg
+++ b/rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg
@@ -3,10 +3,10 @@
 #
 
 %define gcc_version4.9.3
-%define newlib_version 2.4.0
+%define newlib_version 2.4.0.20160527
 
 %hash md5 gcc-%{gcc_version}.tar.bz2 6f831b4d251872736e8e9cc09746f327
-%hash sha512 newlib-2.4.0.tar.gz 
c60665e793dce2368a5baf23560beb50f641e1831854d702d1d7629fb6e9200cf814527f29796792a3d2dff81afee4255723df99ceb0732f99dd9580a17d2ac0
+%hash sha512 newlib-2.4.0.20160527.tar.gz 
09d0c8ac2a657e910eebfeeb7e5fcc6956591223fe499ed4717b5e719287148fc35e80835821fb5b6b586e371100737a7765a03c43f0c194cf67892484132d3f
 
 #
 # The gcc/newlib build instructions.
-- 
2.8.0.rc3

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

Re: rsb to build 4.10 tools with modern compilers (ie under MSYS2)

[Chris Johns]

On 28/05/2016 1:04 AM, Worth Burruss wrote:


Chris, If you would prefer this as a ticket let me know.


Yes a ticket would be good.

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

rsb to build 4.10 tools with modern compilers (ie under MSYS2)

[Worth Burruss]

Attached are 3 patches I needed to build 4.10 tools for coldfire processors 
(m68k) under 
windows (7 and 10) using MSYS2.  I have been meaning to send them for awhile. 

The primary patch is for GCC and is needed to build older GCC with newer GCC.  
I found 
this patch on the GCC mailing list and ajusted it for 4.4.7 as attached.  The 
second for GDB 
is a windows only patch where a function is defined twice under windows.
The last patch adjusts the rsb to apply the patches and fix a missing checksum.

I am sorry if these have been put up here before, but I could find no 
references through 
google other than the similar case on the GCC list.  

Chris, If you would prefer this as a ticket let me know.  Also, autotools are 
not being built in 
the 4.10 m68k recipe.  I would not have known this but for finding 4.12 tools 
mistakenly in the 
path of the machine I normally use and not in the machine that was being setup. 
 I suspect 
this is part of the branching of 4.11 and will be fixed when 4.10 is properly 
branched.  This 
may have also been some of what you were discussing with others a few weeks 
ago.  If not, 
and there is any way I can help, I will do my best with the limited time I have 
over the next few 
weeks.


The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

    File information ---
 File:  gcc-g++-4.4.7-rtems4.10-20160413.diff
 Date:  13 Apr 2016, 14:39
 Size:  19215 bytes.
 Type:  Unknown


gcc-g++-4.4.7-rtems4.10-20160413.diff
Description: Binary data
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

    File information ---
 File:  gdb-7.3.1-rtems4.10-20160414.diff
 Date:  14 Apr 2016, 9:45
 Size:  465 bytes.
 Type:  Unknown


gdb-7.3.1-rtems4.10-20160414.diff
Description: Binary data
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

    File information ---
 File:  rsb-15april2016.diff
 Date:  15 Apr 2016, 12:58
 Size:  2519 bytes.
 Type:  Unknown


rsb-15april2016.diff
Description: Binary data
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Skip Building a few packages by RSB

[Joel Sherrill]

If you are build RTEMS multiple times, then you should just build it by
hand. The tools themselves news to get built much less frequently.

Why do you need to build RTEMS so much is my question.  I think you should
not and install RTEMS and then focus on Rock. You should only need to
rebuild RTEMS if adding or changing something for Rock to work. Say if
RTEMS is missing something.

--joel
On May 27, 2016 5:43 AM, "Sambeet Panigrahi" <sambeet161...@gmail.com>
wrote:

Hi,
I am working on porting Rock to RTEMS as a Summer of code project.I have to
modify the code and build RTEMS using RSB a lot many times. RSB is designed
to clean install every time but building newlib and gcc each time is a very
time consuming task. Is there a way I can select what packages to build and
what not to using RSB so that I can apply changes and build whatever is
required and build whatever is required?
Regards
Sambeet



___
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

Skip Building a few packages by RSB

[Sambeet Panigrahi]

Hi,
I am working on porting Rock to RTEMS as a Summer of code project.I have to
modify the code and build RTEMS using RSB a lot many times. RSB is designed
to clean install every time but building newlib and gcc each time is a very
time consuming task. Is there a way I can select what packages to build and
what not to using RSB so that I can apply changes and build whatever is
required and build whatever is required?
Regards
Sambeet
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB Git modified status

[Gedare Bloom]

On Mon, Apr 18, 2016 at 5:31 PM, Chris Johns <chr...@rtems.org> wrote:
> On 19/04/2016 02:34, Gedare Bloom wrote:
>>
>> I didn't quite follow. Is this to determine whether RSB should do
>> something?
>
>
> I am sorry, I should have provided more of a context.
>
>> I guess this is caused by some bootstrap or configure that
>> creates untracked files in a repo?
>
>
> Yes.
>
>>
>> What does it matter?
>>
>
> It is used to create the version message, for example gcc ...
>
> $ i386-rtems4.12-gcc --version
> i386-rtems4.12-gcc (GCC) 6.0.0 20160327 (RTEMS 4.12, RSB
> 6843e47ce33961e5a705285f3af7a78cae0c2891-modified, Newlib 2.4.0)
>
> This lets us know if the repo is clean or dirty and if changes have been
> made. It helps us support users and it can be part of the evidence in an
> audit.
>
For this specific use, I would not call it modified, because it is
useful to differentiate between a tree that has actually been modified
by a user, and a build that is "vanilla" with only modifications
introduced by auto-gen files. Any untracked files present should only
affect the build if the user also modifies tracked files (short of a
user hacking Makefile.in and configure files, too).
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB Git modified status

[Chris Johns]

On 19/04/2016 08:11, Gedare Bloom wrote:

On Mon, Apr 18, 2016 at 5:31 PM, Chris Johns <chr...@rtems.org> wrote:

This lets us know if the repo is clean or dirty and if changes have been
made. It helps us support users and it can be part of the evidence in an
audit.


For this specific use, I would not call it modified, because it is
useful to differentiate between a tree that has actually been modified
by a user, and a build that is "vanilla" with only modifications
introduced by auto-gen files. Any untracked files present should only
affect the build if the user also modifies tracked files (short of a
user hacking Makefile.in and configure files, too).


This is what I also think. The RSB is unique because you can add a new 
file or a few files and use those but they would tend to result in 
different version numbers showing up in other parts.


I will push a patch.

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

Re: RSB Git modified status

[Chris Johns]

On 19/04/2016 02:34, Gedare Bloom wrote:

I didn't quite follow. Is this to determine whether RSB should do
something?


I am sorry, I should have provided more of a context.


I guess this is caused by some bootstrap or configure that
creates untracked files in a repo?


Yes.



What does it matter?



It is used to create the version message, for example gcc ...

$ i386-rtems4.12-gcc --version
i386-rtems4.12-gcc (GCC) 6.0.0 20160327 (RTEMS 4.12, RSB 
6843e47ce33961e5a705285f3af7a78cae0c2891-modified, Newlib 2.4.0)


This lets us know if the repo is clean or dirty and if changes have been 
made. It helps us support users and it can be part of the evidence in an 
audit.


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

Re: RSB Git modified status

[Gedare Bloom]

I didn't quite follow. Is this to determine whether RSB should do
something? I guess this is caused by some bootstrap or configure that
creates untracked files in a repo?

What does it matter?

On Sun, Apr 17, 2016 at 7:55 PM, Chris Johns <chr...@rtems.org> wrote:
> Hi,
>
> At the moment the RSB says untracked files in a git repo is modified.
>
> Is this valid or this is a distraction? For example if I have 'x' as a file
> in the repo it is seen as untracked and so modified and nothing in the RSB
> has been changed.
>
> I am currently leaning to not modified.
>
> Chris
> ___
> 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

RSB Git modified status

[Chris Johns]

Hi,

At the moment the RSB says untracked files in a git repo is modified.

Is this valid or this is a distraction? For example if I have 'x' as a 
file in the repo it is seen as untracked and so modified and nothing in 
the RSB has been changed.


I am currently leaning to not modified.

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

Re: [PATCH] [RSB] use updated newlib revision for or1k

[Joel Sherrill]

Done.

If there is anything else that needs merging, just ping me.

On Mon, Apr 11, 2016 at 6:02 PM, Hesham Almatary <heshamelmat...@gmail.com>
wrote:

> That's Ok, so please merge your patch and discard this one.
>
> On Mon, Apr 11, 2016 at 10:40 AM Joel Sherrill <j...@rtems.org> wrote:
>
>>
>> On Apr 10, 2016 7:11 PM, "Hesham Almatary" <heshamelmat...@gmail.com>
>> wrote:
>> >
>> > This is the patch. It would conflict with Joel's [PATCH 3/5]
>> 4.12/rtems-or1k.bset: Update newlib to 2.4.0, so we can choose either
>> according to the current RSB convention (releases or git revisions).
>>
>> The ports need to get to newlib 2.4.0. If I don't merge my patch, can you
>> bump the newlib version in yours?
>>
>> I am holding a few pthread patches that need the updated newlib.
>>
>> > On Wed, Mar 30, 2016 at 4:48 PM Stefan Wallentowitz <
>> ste...@wallentowitz.de> wrote:
>> >>
>> >> -BEGIN PGP SIGNED MESSAGE-
>> >> Hash: SHA1
>> >>
>> >> On 30.03.2016 07:29, Sebastian Huber wrote:
>> >> >
>> >> >
>> >> > On 30/03/16 07:26, Stefan Wallentowitz wrote:
>> >> >> there is also a GCC-6 snapshot available:
>> >> >> https://github.com/openrisc/newlib/releases/tag/gcc6-preview
>> >> >>
>> >> >> This was the GCC version used in the other architectures last
>> >> >> week, so maybe it makes sense to bump to this GCC version, too.
>> >> >
>> >> > Are there any plans to integrate the or1k stuff into the FSF GCC?
>> >> >
>> >>
>> >> Hi Sebastian,
>> >>
>> >> this is unfortunately not possible due to one missing FSF copyright
>> >> assignment of the original author. We have repeatedly tried to
>> >> convince him or find a proper workaround, but do not have a solution.
>> >> But we are keeping up with upstream GCC pretty fast currently.
>> >>
>> >> If you accidentally know somehow who would be interested to rewrite
>> >> the GCC port from scratch..
>> >>
>> >> Cheers,
>> >> Stefan
>> >> -BEGIN PGP SIGNATURE-
>> >> Version: GnuPG v2
>> >>
>> >> iEYEARECAAYFAlb7aKkACgkQuMYtsrn2U9wbjgCffW0gkH6MDa2T/SnwGGFkXLWe
>> >> s9oAnAyqPfD8jNiXSdDsfOZW3QIn2anE
>> >> =BBl7
>> >> -END PGP SIGNATURE-
>> >> ___
>> >> 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] [RSB] use updated newlib revision for or1k

[Hesham Almatary]

That's Ok, so please merge your patch and discard this one.

On Mon, Apr 11, 2016 at 10:40 AM Joel Sherrill <j...@rtems.org> wrote:

>
> On Apr 10, 2016 7:11 PM, "Hesham Almatary" <heshamelmat...@gmail.com>
> wrote:
> >
> > This is the patch. It would conflict with Joel's [PATCH 3/5]
> 4.12/rtems-or1k.bset: Update newlib to 2.4.0, so we can choose either
> according to the current RSB convention (releases or git revisions).
>
> The ports need to get to newlib 2.4.0. If I don't merge my patch, can you
> bump the newlib version in yours?
>
> I am holding a few pthread patches that need the updated newlib.
>
> > On Wed, Mar 30, 2016 at 4:48 PM Stefan Wallentowitz <
> ste...@wallentowitz.de> wrote:
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> On 30.03.2016 07:29, Sebastian Huber wrote:
> >> >
> >> >
> >> > On 30/03/16 07:26, Stefan Wallentowitz wrote:
> >> >> there is also a GCC-6 snapshot available:
> >> >> https://github.com/openrisc/newlib/releases/tag/gcc6-preview
> >> >>
> >> >> This was the GCC version used in the other architectures last
> >> >> week, so maybe it makes sense to bump to this GCC version, too.
> >> >
> >> > Are there any plans to integrate the or1k stuff into the FSF GCC?
> >> >
> >>
> >> Hi Sebastian,
> >>
> >> this is unfortunately not possible due to one missing FSF copyright
> >> assignment of the original author. We have repeatedly tried to
> >> convince him or find a proper workaround, but do not have a solution.
> >> But we are keeping up with upstream GCC pretty fast currently.
> >>
> >> If you accidentally know somehow who would be interested to rewrite
> >> the GCC port from scratch..
> >>
> >> Cheers,
> >> Stefan
> >> -BEGIN PGP SIGNATURE-
> >> Version: GnuPG v2
> >>
> >> iEYEARECAAYFAlb7aKkACgkQuMYtsrn2U9wbjgCffW0gkH6MDa2T/SnwGGFkXLWe
> >> s9oAnAyqPfD8jNiXSdDsfOZW3QIn2anE
> >> =BBl7
> >> -END PGP SIGNATURE-
> >> ___
> >> 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] [RSB] use updated newlib revision for or1k

[Hesham Almatary]

This is the patch. It would conflict with Joel's [PATCH 3/5]
4.12/rtems-or1k.bset: Update newlib to 2.4.0, so we can choose either
according to the current RSB convention (releases or git revisions).

On Wed, Mar 30, 2016 at 4:48 PM Stefan Wallentowitz <ste...@wallentowitz.de>
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 30.03.2016 07:29, Sebastian Huber wrote:
> >
> >
> > On 30/03/16 07:26, Stefan Wallentowitz wrote:
> >> there is also a GCC-6 snapshot available:
> >> https://github.com/openrisc/newlib/releases/tag/gcc6-preview
> >>
> >> This was the GCC version used in the other architectures last
> >> week, so maybe it makes sense to bump to this GCC version, too.
> >
> > Are there any plans to integrate the or1k stuff into the FSF GCC?
> >
>
> Hi Sebastian,
>
> this is unfortunately not possible due to one missing FSF copyright
> assignment of the original author. We have repeatedly tried to
> convince him or find a proper workaround, but do not have a solution.
> But we are keeping up with upstream GCC pretty fast currently.
>
> If you accidentally know somehow who would be interested to rewrite
> the GCC port from scratch..
>
> Cheers,
> Stefan
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iEYEARECAAYFAlb7aKkACgkQuMYtsrn2U9wbjgCffW0gkH6MDa2T/SnwGGFkXLWe
> s9oAnAyqPfD8jNiXSdDsfOZW3QIn2anE
> =BBl7
> -END PGP SIGNATURE-
> ___
> 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] [RSB] use updated newlib revision for or1k

[Stefan Wallentowitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30.03.2016 07:29, Sebastian Huber wrote:
> 
> 
> On 30/03/16 07:26, Stefan Wallentowitz wrote:
>> there is also a GCC-6 snapshot available: 
>> https://github.com/openrisc/newlib/releases/tag/gcc6-preview
>> 
>> This was the GCC version used in the other architectures last
>> week, so maybe it makes sense to bump to this GCC version, too.
> 
> Are there any plans to integrate the or1k stuff into the FSF GCC?
> 

Hi Sebastian,

this is unfortunately not possible due to one missing FSF copyright
assignment of the original author. We have repeatedly tried to
convince him or find a proper workaround, but do not have a solution.
But we are keeping up with upstream GCC pretty fast currently.

If you accidentally know somehow who would be interested to rewrite
the GCC port from scratch..

Cheers,
Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlb7aKkACgkQuMYtsrn2U9wbjgCffW0gkH6MDa2T/SnwGGFkXLWe
s9oAnAyqPfD8jNiXSdDsfOZW3QIn2anE
=BBl7
-END PGP SIGNATURE-
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RSB] use updated newlib revision for or1k

[Sebastian Huber]

On 30/03/16 07:26, Stefan Wallentowitz wrote:

there is also a GCC-6 snapshot available:
https://github.com/openrisc/newlib/releases/tag/gcc6-preview

This was the GCC version used in the other architectures last week, so
maybe it makes sense to bump to this GCC version, too.


Are there any plans to integrate the or1k stuff into the FSF GCC?

--
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.

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

Re: [PATCH] [RSB] use updated newlib revision for or1k

[Stefan Wallentowitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Hesham,

there is also a GCC-6 snapshot available:
https://github.com/openrisc/newlib/releases/tag/gcc6-preview

This was the GCC version used in the other architectures last week, so
maybe it makes sense to bump to this GCC version, too.

Best,
Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlb7Y20ACgkQuMYtsrn2U9xDqACgosg/yDD8YBaJaPFqdiBH+CBQ
ZZUAoIWMCHPtP0N3TgO3zTT4bSxrC3n7
=knxA
-END PGP SIGNATURE-
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel