Fwd: Build fail on debian - Toolset build error

[Andrew Butterfield]

Dear all, 
I am having a problem building RTEMs master, on OS X Mojave - see below

> Begin forwarded message:
> 
> From: Sebastian Huber 
> Subject: Re: Build fail on debian - Toolset build error
> Date: 12 October 2020 at 10:48:17 IST
> To: Andrew Butterfield 
> 
> Hello Andrew,
> 
> could you please forward this e-mail to devel@rtems.org.
> 
> On 12/10/2020 11:45, Andrew Butterfield wrote:
>> Hi Sebastian,
>> 
>>  I get a python error - despite using the virtual environment,
>> which maps `python` to the OS X \System installation of python 3.8
>> 
>> It complains about python2 being unusable - see tail of report below...
>> 
>> My command-line tools and Xcode are up-to-date. Now this is on a Mojave 
>> machine, which is
>> one that is not listed in the User Manual where OS X is discussed.
>> 
>> I'll try to do this on my laptop which is now Catalina
>> 
>> Regards, Andrew
>> 
>> tail of error report follows:
>> 
>> checking for library containing socketpair... none required
>> checking for ld used by GCC... 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
>> checking if the linker 
>> (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld)
>>  is GNU ld... no
>> checking for shared library run path origin... done
>> checking for iconv... yes
>> checking how to link with libiconv... -liconv
>> checking for iconv declaration...
>>  extern size_t iconv (iconv_t cd, char * *inbuf, size_t 
>> *inbytesleft, char * *outbuf, size_t *outbytesleft);
>> checking for library containing waddstr... -lncurses
>> checking for library containing tgetent... none required
>> checking size of unsigned long long... 8
>> checking size of unsigned long... 8
>> checking size of unsigned __int128... 16
>> checking for library containing dlopen... none required
>> checking whether to use expat... yes
>> checking for libexpat... yes
>> checking how to link with libexpat... -lexpat
>> checking for XML_StopParser... yes
>> checking whether to use MPFR... auto
>> checking for libmpfr... no
>> configure: WARNING: MPFR is missing or unusable; some features may be 
>> unavailable.
>> checking whether to use python... 
>> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
>> checking for python... no
>> configure: error: no usable python found at 
>> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
>> make[1]: *** [configure-gdb] Error 1
>> make: *** [all] Error 2
>> shell cmd failed: /bin/sh -ex  
>> /Users/butrfeld/REPOS/rtems-smp-qualification-qual/modules/rsb/rtems/build/sparc-rtems6-gdb-0295dde-x86_64-apple-darwin18.7.0-1/do-build
>> error: building sparc-rtems6-gdb-0295dde-x86_64-apple-darwin18.7.0-1
>> 
>>> On 12 Oct 2020, at 09:19, Sebastian Huber 
>>> >> > wrote:
>>> 
>>> On 12/10/2020 10:14, Andrew Butterfield wrote:
>>> 
 Is there any point me trying to build on my OS X machine, or will I just 
 get the same error?
>>> It is unlikely that you get the same error. This seems to be a Debian 
>>> specific issue.
>> 
>> 
>> Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
>> Lero@TCD, Head of Software Foundations & Verification Research Group
>> School of Computer Science and Statistics,
>> Room G.39, O'Reilly Institute, Trinity College, University of Dublin
>> http://www.scss.tcd.ie/Andrew.Butterfield/
>> 
>> 


Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
Lero@TCD, Head of Software Foundations & Verification Research Group
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
 http://www.scss.tcd.ie/Andrew.Butterfield/


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

Re: Fwd: Build fail on debian - Toolset build error

[Karel Gardas]

On 10/12/20 12:17 PM, Andrew Butterfield wrote:
> Dear all, 
> I am having a problem building RTEMs master, on OS X Mojave - see below

checking whether to use python...
/Library/Frameworks/Python.framework/Versions/2.7/bin/python2
checking for python... no
configure: error: no usable python found at
/Library/Frameworks/Python.framework/Versions/2.7/bin/python2

Something wrong with your python2 install? E.g. gdb needs python2 and if
you don't have it, it'll fail which will fail tools compile which will
fail whole rtems compile...

Cheers,
Karel

> 
>> Begin forwarded message:
>>
>> *From: *Sebastian Huber > >
>> *Subject: **Re: Build fail on debian - Toolset build error*
>> *Date: *12 October 2020 at 10:48:17 IST
>> *To: *Andrew Butterfield > >
>>
>> Hello Andrew,
>>
>> could you please forward this e-mail to devel@rtems.org
>> .
>>
>> On 12/10/2020 11:45, Andrew Butterfield wrote:
>>> Hi Sebastian,
>>>
>>>  I get a python error - despite using the virtual environment,
>>> which maps `python` to the OS X \System installation of python 3.8
>>>
>>> It complains about python2 being unusable - see tail of report below...
>>>
>>> My command-line tools and Xcode are up-to-date. Now this is on a
>>> Mojave machine, which is
>>> one that is not listed in the User Manual where OS X is discussed.
>>>
>>> I'll try to do this on my laptop which is now Catalina
>>>
>>> Regards, Andrew
>>>
>>> tail of error report follows:
>>>
>>> checking for library containing socketpair... none required
>>> checking for ld used by GCC...
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
>>> checking if the linker
>>> (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld)
>>> is GNU ld... no
>>> checking for shared library run path origin... done
>>> checking for iconv... yes
>>> checking how to link with libiconv... -liconv
>>> checking for iconv declaration...
>>>          extern size_t iconv (iconv_t cd, char * *inbuf, size_t
>>> *inbytesleft, char * *outbuf, size_t *outbytesleft);
>>> checking for library containing waddstr... -lncurses
>>> checking for library containing tgetent... none required
>>> checking size of unsigned long long... 8
>>> checking size of unsigned long... 8
>>> checking size of unsigned __int128... 16
>>> checking for library containing dlopen... none required
>>> checking whether to use expat... yes
>>> checking for libexpat... yes
>>> checking how to link with libexpat... -lexpat
>>> checking for XML_StopParser... yes
>>> checking whether to use MPFR... auto
>>> checking for libmpfr... no
>>> configure: WARNING: MPFR is missing or unusable; some features may be
>>> unavailable.
>>> checking whether to use python...
>>> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
>>> checking for python... no
>>> configure: error: no usable python found at
>>> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
>>> make[1]: *** [configure-gdb] Error 1
>>> make: *** [all] Error 2
>>> shell cmd failed: /bin/sh -ex
>>>  
>>> /Users/butrfeld/REPOS/rtems-smp-qualification-qual/modules/rsb/rtems/build/sparc-rtems6-gdb-0295dde-x86_64-apple-darwin18.7.0-1/do-build
>>> error: building sparc-rtems6-gdb-0295dde-x86_64-apple-darwin18.7.0-1
>>>
 On 12 Oct 2020, at 09:19, Sebastian Huber
 >>> 
 > wrote:

 On 12/10/2020 10:14, Andrew Butterfield wrote:

> Is there any point me trying to build on my OS X machine, or will I
> just get the same error?
 It is unlikely that you get the same error. This seems to be a
 Debian specific issue.
>>>
>>> 
>>> Andrew Butterfield     Tel: +353-1-896-2517     Fax: +353-1-677-2204
>>> Lero@TCD, Head of Software Foundations & Verification Research Group
>>> School of Computer Science and Statistics,
>>> Room G.39, O'Reilly Institute, Trinity College, University of Dublin
>>> http://www.scss.tcd.ie/Andrew.Butterfield/
>>> 
>>>
> 
> 
> Andrew Butterfield     Tel: +353-1-896-2517     Fax: +353-1-677-2204
> Lero@TCD, Head of Software Foundations & Verification Research Group
> School of Computer Science and Statistics,
> Room G.39, O'Reilly Institute, Trinity College, University of Dublin
>                          http://www.scss.tcd.ie/Andrew.Butterfield/
> 
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

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

Re: Build fail on debian - Toolset build error

[Andrew Butterfield]

Hi Karel,

 I have no idea what's wrong.

If I ask nicely:

:- which python2
/Library/Frameworks/Python.framework/Versions/2.7/bin/python2
:- python2 --version
Python 2.7.18

all seems well.

I have has this problem before and usually I just purge all "brew" versions of 
python,
and perhaps re-install/update the command line tools from x-code - then all 
works fine.
Right now my Mac reports my X-code and command line tools as up to date.

When it is checking for python - what is the check? How does it determine 
"usability"? It's not simple presence of the binary.

Currently I have three python2s:

:- type -a python2
python2 is /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
python2 is /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
python2 is /usr/local/bin/python2

The first one an the $PATH is the one the tool builder doesn't like.

:- type python2
python2 is hashed 
(/Library/Frameworks/Python.framework/Versions/2.7/bin/python2)

Thanks,
  Andrew



> On 12 Oct 2020, at 11:21, Karel Gardas  wrote:
> 
> On 10/12/20 12:17 PM, Andrew Butterfield wrote:
>> Dear all, 
>> I am having a problem building RTEMs master, on OS X Mojave - see below
> 
> checking whether to use python...
> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
> checking for python... no
> configure: error: no usable python found at
> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
> 
> Something wrong with your python2 install? E.g. gdb needs python2 and if
> you don't have it, it'll fail which will fail tools compile which will
> fail whole rtems compile...
> 
> Cheers,
> Karel
> 
>> 
>>> Begin forwarded message:
>>> 
>>> *From: *Sebastian Huber >> >
>>> *Subject: **Re: Build fail on debian - Toolset build error*
>>> *Date: *12 October 2020 at 10:48:17 IST
>>> *To: *Andrew Butterfield >> >
>>> 
>>> Hello Andrew,
>>> 
>>> could you please forward this e-mail to devel@rtems.org
>>> .
>>> 
>>> On 12/10/2020 11:45, Andrew Butterfield wrote:
 Hi Sebastian,
 
  I get a python error - despite using the virtual environment,
 which maps `python` to the OS X \System installation of python 3.8
 
 It complains about python2 being unusable - see tail of report below...
 
 My command-line tools and Xcode are up-to-date. Now this is on a
 Mojave machine, which is
 one that is not listed in the User Manual where OS X is discussed.
 
 I'll try to do this on my laptop which is now Catalina
 
 Regards, Andrew
 
 tail of error report follows:
 
 checking for library containing socketpair... none required
 checking for ld used by GCC...
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
 checking if the linker
 (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld)
 is GNU ld... no
 checking for shared library run path origin... done
 checking for iconv... yes
 checking how to link with libiconv... -liconv
 checking for iconv declaration...
  extern size_t iconv (iconv_t cd, char * *inbuf, size_t
 *inbytesleft, char * *outbuf, size_t *outbytesleft);
 checking for library containing waddstr... -lncurses
 checking for library containing tgetent... none required
 checking size of unsigned long long... 8
 checking size of unsigned long... 8
 checking size of unsigned __int128... 16
 checking for library containing dlopen... none required
 checking whether to use expat... yes
 checking for libexpat... yes
 checking how to link with libexpat... -lexpat
 checking for XML_StopParser... yes
 checking whether to use MPFR... auto
 checking for libmpfr... no
 configure: WARNING: MPFR is missing or unusable; some features may be
 unavailable.
 checking whether to use python...
 /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
 checking for python... no
 configure: error: no usable python found at
 /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
 make[1]: *** [configure-gdb] Error 1
 make: *** [all] Error 2
 shell cmd failed: /bin/sh -ex
  
 /Users/butrfeld/REPOS/rtems-smp-qualification-qual/modules/rsb/rtems/build/sparc-rtems6-gdb-0295dde-x86_64-apple-darwin18.7.0-1/do-build
 error: building sparc-rtems6-gdb-0295dde-x86_64-apple-darwin18.7.0-1
 
> On 12 Oct 2020, at 09:19, Sebastian Huber
>  
> > wrote:
> 
> On 12/10/2020 10:14, Andrew Butterfield wrote:
> 
>> Is there any point me trying to build on my OS X machine, or will I
>> just get the same error?
> It is unlikely that you get the same error. This seems to be a
> Debian specific issue.
 
 

Re: Build fail on debian - Toolset build error

[Karel Gardas]

Sure, but you have to install header files whatever this means on
macosx. On Ubuntu this means 'apt install python2.7-dev'

On 10/12/20 2:27 PM, Andrew Butterfield wrote:
> Hi Karel,
> 
>  I have no idea what's wrong.
> 
> If I ask nicely:
> 
> :- which python2
> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
> :- python2 --version
> Python 2.7.18
> 
> all seems well.
> 
> I have has this problem before and usually I just purge all "brew"
> versions of python,
> and perhaps re-install/update the command line tools from x-code - then
> all works fine.
> Right now my Mac reports my X-code and command line tools as up to date.
> 
> When it is checking for python - what is the check? How does it
> determine "usability"? It's not simple presence of the binary.
> 
> Currently I have three python2s:
> 
> :- type -a python2
> python2 is /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
> python2 is /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
> python2 is /usr/local/bin/python2
> 
> The first one an the $PATH is the one the tool builder doesn't like.
> 
> :- type python2
> python2 is hashed
> (/Library/Frameworks/Python.framework/Versions/2.7/bin/python2)
> 
> Thanks,
>   Andrew
> 
> 
> 
>> On 12 Oct 2020, at 11:21, Karel Gardas > > wrote:
>>
>> On 10/12/20 12:17 PM, Andrew Butterfield wrote:
>>> Dear all, 
>>> I am having a problem building RTEMs master, on OS X Mojave - see below
>>
>> checking whether to use python...
>> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
>> checking for python... no
>> configure: error: no usable python found at
>> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
>>
>> Something wrong with your python2 install? E.g. gdb needs python2 and if
>> you don't have it, it'll fail which will fail tools compile which will
>> fail whole rtems compile...
>>
>> Cheers,
>> Karel
>>
>>>
 Begin forwarded message:

 *From: *Sebastian Huber >>> 
 >
 *Subject: **Re: Build fail on debian - Toolset build error*
 *Date: *12 October 2020 at 10:48:17 IST
 *To: *Andrew Butterfield >>> 
 >

 Hello Andrew,

 could you please forward this e-mail to devel@rtems.org
 
 .

 On 12/10/2020 11:45, Andrew Butterfield wrote:
> Hi Sebastian,
>
>  I get a python error - despite using the virtual environment,
> which maps `python` to the OS X \System installation of python 3.8
>
> It complains about python2 being unusable - see tail of report below...
>
> My command-line tools and Xcode are up-to-date. Now this is on a
> Mojave machine, which is
> one that is not listed in the User Manual where OS X is discussed.
>
> I'll try to do this on my laptop which is now Catalina
>
> Regards, Andrew
>
> tail of error report follows:
>
> checking for library containing socketpair... none required
> checking for ld used by GCC...
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
> checking if the linker
> (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld)
> is GNU ld... no
> checking for shared library run path origin... done
> checking for iconv... yes
> checking how to link with libiconv... -liconv
> checking for iconv declaration...
>          extern size_t iconv (iconv_t cd, char * *inbuf, size_t
> *inbytesleft, char * *outbuf, size_t *outbytesleft);
> checking for library containing waddstr... -lncurses
> checking for library containing tgetent... none required
> checking size of unsigned long long... 8
> checking size of unsigned long... 8
> checking size of unsigned __int128... 16
> checking for library containing dlopen... none required
> checking whether to use expat... yes
> checking for libexpat... yes
> checking how to link with libexpat... -lexpat
> checking for XML_StopParser... yes
> checking whether to use MPFR... auto
> checking for libmpfr... no
> configure: WARNING: MPFR is missing or unusable; some features may be
> unavailable.
> checking whether to use python...
> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
> checking for python... no
> configure: error: no usable python found at
> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
> make[1]: *** [configure-gdb] Error 1
> make: *** [all] Error 2
> shell cmd failed: /bin/sh -ex
>  
> /Users/butrfeld/REPOS/rtems-smp-qualification-qual/modules/rsb/rtems/build/sparc-rtems6-gdb-0295dde-x86_64-apple-darwin18.7.0-1/do-build
> error: building sparc-rtems6-gdb-0295dde-x8

[PATCH v2] testsuites/samples/fileio - Increase of stack size

[Frank Kuehndel]

From: Frank Kühndel 

When I use the 'shell' from the fileio sample with the command below:

   env QEMU_AUDIO_DRV="none" \
   qemu-system-arm -no-reboot -net none -nographic -M realview-pbx-a9 \
   -m 256M \
   -kernel build/arm/realview_pbx_a9_qemu/testsuites/samples/fileio.exe

The executable crashes with an "BLOWN STACK!!!" as soon as I try to login
as 'root' with password. (The logins without password work fine.)
Increasing the stack size of the affected thread a bit solves the issue.
Hence, I suggest this patch.

 My config.ini was

[arm/realview_pbx_a9_qemu]
RTEMS_DEBUG = True
RTEMS_NETWORKING = True
RTEMS_POSIX_API = True
RTEMS_SMP = True
BUILD_TESTS = True

RTEMS origin.master at a479686c112144119866391ceb21c48be6a3eca9

Close #4143
---
 testsuites/samples/fileio/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testsuites/samples/fileio/init.c b/testsuites/samples/fileio/init.c
index 86b34b99dd..c552d33613 100644
--- a/testsuites/samples/fileio/init.c
+++ b/testsuites/samples/fileio/init.c
@@ -630,7 +630,7 @@ static void fileio_start_shell(void)
   printf(" =\n");
   rtems_shell_init(
 "SHLL",  /* task_name */
-RTEMS_MINIMUM_STACK_SIZE * 4,/* task_stacksize */
+RTEMS_MINIMUM_STACK_SIZE * 5,/* task_stacksize */
 100, /* task_priority */
 "/dev/foobar",   /* devname */
 /* device is currently ignored by the shell if it is not a pty */
-- 
2.26.2

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

Re: [PATCH v2] testsuites/samples/fileio - Increase of stack size

[Sebastian Huber]

On 12/10/2020 15:49, Frank Kuehndel wrote:


Close #4143

Thanks, I checked it in.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Build fail on debian - Toolset build error

[Anders Montonen]

Hi,

> On 12 Oct 2020, at 15:30, Karel Gardas  wrote:
> 
> 
> Sure, but you have to install header files whatever this means on
> macosx. On Ubuntu this means 'apt install python2.7-dev’

System frameworks on macOs usually include the development libraries and 
headers. Running “python-config —cflags”, and “python-config 
—ldflags” returns the compiler and linker flags needed.

Regards,
Anders Montonen___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] c-user: Add "Generated from ..." comments

[Sebastian Huber]

---
 c-user/config/bdbuf.rst | 28 +++
 c-user/config/bsp-related.rst   | 16 +
 c-user/config/classic-api.rst   | 26 ++
 c-user/config/classic-init-task.rst | 18 ++
 c-user/config/device-driver.rst | 38 
 c-user/config/event-record.rst  | 10 ++
 c-user/config/filesystem.rst| 56 +
 c-user/config/general.rst   | 44 +++
 c-user/config/idle-task.rst |  8 +
 c-user/config/mpci.rst  | 16 +
 c-user/config/posix-api.rst | 20 +++
 c-user/config/posix-init-thread.rst |  8 +
 c-user/config/scheduler-general.rst | 30 
 c-user/config/task-stack-alloc.rst  | 12 +++
 14 files changed, 330 insertions(+)

diff --git a/c-user/config/bdbuf.rst b/c-user/config/bdbuf.rst
index 1a0d393..e981f54 100644
--- a/c-user/config/bdbuf.rst
+++ b/c-user/config/bdbuf.rst
@@ -15,12 +15,16 @@
 ..
 .. https://docs.rtems.org/branches/master/eng/req/howto.html
 
+.. Generated from spec:/acfg/if/group-bdbuf
+
 Block Device Cache Configuration
 
 
 This section describes configuration options related to the Block Device Cache
 (bdbuf).
 
+.. Generated from spec:/acfg/if/appl-needs-libblock
+
 .. index:: CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
 
 .. _CONFIGURE_APPLICATION_NEEDS_LIBBLOCK:
@@ -47,6 +51,8 @@ NOTES:
 set by the user with the configuration options below.  The Block Device 
Cache
 is used for example by the RFS and DOSFS filesystems.
 
+.. Generated from spec:/acfg/if/bdbuf-buffer-max-size
+
 .. index:: CONFIGURE_BDBUF_BUFFER_MAX_SIZE
 
 .. _CONFIGURE_BDBUF_BUFFER_MAX_SIZE:
@@ -78,6 +84,8 @@ DESCRIPTION:
 NOTES:
 None.
 
+.. Generated from spec:/acfg/if/bdbuf-buffer-min-size
+
 .. index:: CONFIGURE_BDBUF_BUFFER_MIN_SIZE
 
 .. _CONFIGURE_BDBUF_BUFFER_MIN_SIZE:
@@ -105,6 +113,8 @@ DESCRIPTION:
 NOTES:
 None.
 
+.. Generated from spec:/acfg/if/bdbuf-cache-memory-size
+
 .. index:: CONFIGURE_BDBUF_CACHE_MEMORY_SIZE
 
 .. _CONFIGURE_BDBUF_CACHE_MEMORY_SIZE:
@@ -132,6 +142,8 @@ DESCRIPTION:
 NOTES:
 None.
 
+.. Generated from spec:/acfg/if/bdbuf-max-read-ahead-blocks
+
 .. index:: CONFIGURE_BDBUF_MAX_READ_AHEAD_BLOCKS
 
 .. _CONFIGURE_BDBUF_MAX_READ_AHEAD_BLOCKS:
@@ -161,6 +173,8 @@ NOTES:
 will issue speculative read transfers if a sequential access pattern is
 detected.  This can improve the performance on some systems.
 
+.. Generated from spec:/acfg/if/bdbuf-max-write-blocks
+
 .. index:: CONFIGURE_BDBUF_MAX_WRITE_BLOCKS
 
 .. _CONFIGURE_BDBUF_MAX_WRITE_BLOCKS:
@@ -188,6 +202,8 @@ DESCRIPTION:
 NOTES:
 None.
 
+.. Generated from spec:/acfg/if/bdbuf-read-ahead-task-priority
+
 .. index:: CONFIGURE_BDBUF_READ_AHEAD_TASK_PRIORITY
 
 .. _CONFIGURE_BDBUF_READ_AHEAD_TASK_PRIORITY:
@@ -214,6 +230,8 @@ DESCRIPTION:
 NOTES:
 None.
 
+.. Generated from spec:/acfg/if/bdbuf-task-stack-size
+
 .. index:: CONFIGURE_BDBUF_TASK_STACK_SIZE
 
 .. _CONFIGURE_BDBUF_TASK_STACK_SIZE:
@@ -251,6 +269,8 @@ DESCRIPTION:
 NOTES:
 None.
 
+.. Generated from spec:/acfg/if/bdbuf-swapout-block-hold
+
 .. index:: CONFIGURE_SWAPOUT_BLOCK_HOLD
 
 .. _CONFIGURE_SWAPOUT_BLOCK_HOLD:
@@ -278,6 +298,8 @@ DESCRIPTION:
 NOTES:
 None.
 
+.. Generated from spec:/acfg/if/bdbuf-swapout-swap-period
+
 .. index:: CONFIGURE_SWAPOUT_SWAP_PERIOD
 
 .. _CONFIGURE_SWAPOUT_SWAP_PERIOD:
@@ -305,6 +327,8 @@ DESCRIPTION:
 NOTES:
 None.
 
+.. Generated from spec:/acfg/if/bdbuf-swapout-task-priority
+
 .. index:: CONFIGURE_SWAPOUT_TASK_PRIORITY
 
 .. _CONFIGURE_SWAPOUT_TASK_PRIORITY:
@@ -331,6 +355,8 @@ DESCRIPTION:
 NOTES:
 None.
 
+.. Generated from spec:/acfg/if/bdbuf-swapout-worker-tasks
+
 .. index:: CONFIGURE_SWAPOUT_WORKER_TASKS
 
 .. _CONFIGURE_SWAPOUT_WORKER_TASKS:
@@ -357,6 +383,8 @@ DESCRIPTION:
 NOTES:
 None.
 
+.. Generated from spec:/acfg/if/bdbuf-swapout-worker-taskp-riority
+
 .. index:: CONFIGURE_SWAPOUT_WORKER_TASK_PRIORITY
 
 .. _CONFIGURE_SWAPOUT_WORKER_TASK_PRIORITY:
diff --git a/c-user/config/bsp-related.rst b/c-user/config/bsp-related.rst
index 8ed34cf..71bcd58 100644
--- a/c-user/config/bsp-related.rst
+++ b/c-user/config/bsp-related.rst
@@ -15,6 +15,8 @@
 ..
 .. https://docs.rtems.org/branches/master/eng/req/howto.html
 
+.. Generated from spec:/acfg/if/group-bsp
+
 BSP Related Configuration Options
 =
 
@@ -23,6 +25,8 @@ configuration options may have a BSP-specific setting which 
is defined by
 .  The BSP-specific settings can be disabled by the
 :ref:`CONFIGURE_DISABLE_BSP_SETTINGS` configuration option.
 
+.. Generated from spec:/acfg/if/bsp-idle-task-body
+
 .. index:: BSP_IDLE_TASK_BODY
 
 .. _BSP_IDLE_TASK_BODY:
@@ -58,6 +62,8 @@ NOTES:
 peripheral buses, a BSP-specific IDLE task may be capable of turning
 components off to save power during extended periods of no task activity.
 
+.. Generated from spec:/acfg/if/

Re: [PATCH v2] testsuites/samples/fileio - Increase of stack size

[Frank Kühndel]

I also created a ticket for RTEMS version 5 as requested by Joel and
Chris. It is #4144.

Yet, note that I have not tested whether the problem appears there, too.
The efforts to install and compile 5.1 just for this simple test are
prohibitive. Sorry for this. Maybe someone else who is working with 5.1
can check it.

Moreover, I cannot contribute to the discussion -Og versus -O0.

Greetings
Frank

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

Re: Build fail on debian - Toolset build error

[Karel Gardas]

On 10/12/20 3:50 PM, Anders Montonen wrote:
> Hi,
> 
>> On 12 Oct 2020, at 15:30, Karel Gardas > > wrote:
>>
>>
>> Sure, but you have to install header files whatever this means on
>> macosx. On Ubuntu this means 'apt install python2.7-dev’
> 
> System frameworks on macOs usually include the development libraries and
> headers. Running “python-config —cflags”, and “python-config
> —ldflags” returns the compiler and linker flags needed.

Check where is Python.h -- if it's available, then probably gdb's
configure is not able to pick it up -- probably due to missing
parameters -- which should be supplied by rsb. Anyway, you (or OP) are
on macosx which is not that usual so you will probably need to do some
tweaks. If it's not available, you need to convince your python install
to install all headers and libs.

Also, have a look into rtems-source-builder/source-builder/sb -- not
sure, but there is no macosx.py there but perhaps it should be... (like
linux, openbsd, netbsd etc. are there too...)

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

BSP Build Sweep (12 Oct)

[Joel Sherrill]

Hi

I just pushed a few tcfg additions and now all the configurations my script
is doing should match waf and autoconf next time. This is just building. I
will do another sweep to confirm that they all match and then we can review
the configurations to see if I missed anything.

I haven't done the regular sweep in a couple of weeks where I build new
tools and actually run tests on simulators. I am going to run this and then
do another BSP sweep.

At this point, my outstanding BSP build comparison is whether we know the
clang sparc and riscv BSPs are all building. That's one area I have not
touched.

And should you be able to enable clang for an architecture that isn't
supported yet?

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

Re: Need help debugging sp16.exe

[Richi Dubey]

>
> There are existing checks scattered throughout the source. Do any need to
> be in your scheduler?

I don't understand. If there are already checks scattered through, why do I
need more checks in my scheduler? Are these checks independent from the
checks I might need in the scheduler? Please explain.

+ Looks like the bsp has fast idle on but that should not impact anything.

What's fast idle? I found this
.
:p How can time run as fast as possible?

+ Run this with the another scheduler and see if you can identify when that
> scheduler makes the decision you are missing. There has to be one of the
> scheduler hooks that is making a different decision. Run the test side by
> side with two different schedulers. Alternate forward motion in the two and
> compare the behaviour.

This is genius. Thanks a lot. I'm gonna work on this.

+ Adding trading might help but is probably more trouble to set up than
> just comparing good and bad schedulers in parallel.

What's trading?

+ Look at what every failing test is doing. May be a common issue and one
> is easier to debug

Thanks. I'll check this.


On Sun, Oct 11, 2020 at 5:08 AM Joel Sherrill  wrote:

>
>
> On Sat, Oct 10, 2020, 10:47 AM Richi Dubey  wrote:
>
>> Hi Mr. Huber,
>>
>> Thanks for checking in.
>>
>> I suggested to enable your new scheduler implementation as the default
>>> to check if it is in line with the standard schedulers. I would first
>>> get some high level data. Select a BSP with good test results on a
>>> simulator (for example sparc/leon3 or arm/realview_pbx_a9_qemu). Run the
>>> tests and record the test data. Then enable the SMP EDF scheduler as the
>>> default, run the tests, record the data. Then enable your scheduler as
>>> the default, run the tests, record the data. Then get all tests which
>>> fail only with your scheduler.
>>
>> Yes, this is something I've already done based on your previous
>> suggestion. I set SCHEDULER_STRONG_APA(the current RTEMS master's version)
>> as the default scheduler for both sp and SMP and ran the test (on both
>> sparc/leon3 and arm/realview_pbx_a9_qemu). Then I set
>> SCHEDULER_STRONG_APA(my version) as the default scheduler for both sp and
>> SMP and ran the test and compared it with the master's strong apa result.
>> The following (extra) tests failed:
>>
>>  sp02.exe
>>  sp16.exe
>>  sp30.exe
>>  sp31.exe
>>  sp37.exe
>>  sp42.exe
>>  spfatal29.exe
>>  tm24.exe
>>
>> Do a high level analysis of all failing
>>
>> tests. Try to figure out a new scenario for the test smpstrongapa01.
>>
>> Okay, I would look into this. This is a great suggestion, thanks!
>>
>>
>> Do all the development with RTEMS_DEBUG enabled!
>>> Add _Assert() stuff to your scheduler. Check pre- and post-conditions of
>>> all operations. Check invariants.
>>
>> How do I check postconditions? Using _Assert() or by manually debugging
>> each function call?
>>
>
> There are existing checks scattered throughout the source. Do any need to
> be in your scheduler?
>
> Random thoughts:
>
> + Looks like the bsp has fast idle on but that should not impact anything.
>
> + Run this with the another scheduler and see if you can identify when
> that scheduler makes the decision you are missing. There has to be one of
> the scheduler hooks that is making a different decision. Run the test side
> by side with two different schedulers. Alternate forward motion in the two
> and compare the behaviour.
>
> + Adding trading might help but is probably more trouble to set up than
> just comparing good and bad schedulers in parallel.
>
> + Look at what every failing test is doing. May be a common issue and one
> is easier to debug
>
> --joel
>
>>
>>
>>
>> On Sat, Oct 10, 2020 at 6:09 PM Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> Hello Richi,
>>>
>>> I suggested to enable your new scheduler implementation as the default
>>> to check if it is in line with the standard schedulers. I would first
>>> get some high level data. Select a BSP with good test results on a
>>> simulator (for example sparc/leon3 or arm/realview_pbx_a9_qemu). Run the
>>> tests and record the test data. Then enable the SMP EDF scheduler as the
>>> default, run the tests, record the data. Then enable your scheduler as
>>> the default, run the tests, record the data. Then get all tests which
>>> fail only with your scheduler. Do a high level analysis of all failing
>>> tests. Try to figure out a new scenario for the test smpstrongapa01.
>>>
>>> Do all the development with RTEMS_DEBUG enabled!
>>>
>>> Add _Assert() stuff to your scheduler. Check pre- and post-conditions of
>>> all  operations. Check invariants.
>>>
>>> ___
>> 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

Re: RTEMS 5.1 pc686 BSP malloc_info problem?

[Alan Cudmore]

Hi Chris,
I'm not sure that I can easily create a test to show that this
condition exists. I think the rtems_rfs_bitmap_create_search function
works as it is intended to, but during the last iteration of the for
loop, if 'size' is zero and 'bit' is 31, the 'search_map' variable is
incremented once more, and the value of RTEMS_RFS_BITMAP_ELEMENT_CLEAR
(0x) is written to that location. This location is one address
beyond the memory that was allocated for the search_map in
rtems_rfs_bitmap_open.
I guess that most of the time this is a silent side effect, but my
application just happened to have memory lined up such that the extra
write causes the malloc Allocator mutex to fail, causing the
malloc_info call to block indefinitely. I would consider this a lucky
break!
The exact same example application does not fail on RTEMS 4.11. I
think the problem still exists, but in that case, the word that gets
written is different.

Here are some debug printfs from rtems_rfs_bitmap_open and
rtems_rfs_bitmap_create_search:

>From rtems_rfs_bitmap_open:
RFS - rtems_rfs_bitmap_open - search_bits malloced size = 16 bytes
RFS - rtems_rfs_bitmap_open - addr of search_bits = 0x00C03814
RFS -> size of search_map = 4
RFS -> control->size = 4095

>From the subsequent call to rtems_rfs_bitmap_create_search:
These printfs are in the if clause where bit == 31 (line 633)
RFS --> search_map before increment addr 00C03814, size = 3071
RFS --> search_map after increment -> writing
RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03818
RFS --> search_map before increment addr 00C03818, size = 2047
RFS --> search_map after increment -> writing
RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C0381C
RFS --> search_map before increment addr 00C0381C, size = 1023
RFS --> search_map after increment -> writing
RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03820
RFS --> search_map before increment addr 00C03820, size = 0
RFS --> search_map after increment -> writing
RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03824

It's this last write to 00C03824 that causes the problem. I think the
fix just involves checking to see if size == 0 before executing the if
clause. I wanted to be sure that this extra write was not needed.

If you have an idea for a test case, I can work on it, but if you
think that this is good enough, I can propose a patch.

Also, thanks for the idea of using RTEMS_DEBUG Sebastian, I need to
upgrade my RTEMS toolbox with the latest techniques.

Alan


On Sun, Oct 11, 2020 at 6:20 PM Chris Johns  wrote:
>
> On 10/10/20 7:35 am, Alan Cudmore wrote:
> > After doing a lot of tracing through my application, it looks like
> > malloc_info works fine before we start our cFS application, but it
> > blocks after the cFS is initialized. This suggests some sort of memory
> > corruption.
> > I started by instrumenting our code to call malloc info during various
> > stages of application initialization, and finally narrowed it down to
> > the code where we create a RAM Disk and format it with RFS.
> > (skipping a bunch of other malloc based troubleshooting.. )
> > After I followed the issue into the RFS init, I was able to narrow
> > down the place where malloc_info stopped working to here:
> > https://git.rtems.org/rtems/tree/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c?h=5#n637
> > During the RFS format process.
> > In this section of the code, the size variable is 0, meaning it will
> > exit the for loop and then return from the function, but it increments
> > the "search_map" variable and writes to memory through the pointer one
> > more time before exiting the loop and function. It's at this point
> > where malloc_info starts blocking.
> >
> > It seems to me that this if block should be skipped when size == 0. I
> > tried that and the malloc_info issue seems to be fixed.
>
> Would you be able to create a test case for this? The test is ..
>
> https://git.rtems.org/rtems/tree/testsuites/fstests/fsrfsbitmap01/test.c
>
> Or if you could please provide the values in `control` I can add the test.
>
> > Is this an RFS bug writing into other memory, or is this last write
> > needed before the function updates?
>
> It would seem so.
>
> > If this looks like a bug, should I write a ticket and provide a patch?
>
> Yes please. It would be nice to have a test case that fails so we can isolate
> the cause.
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 5.1 pc686 BSP malloc_info problem?

[Joel Sherrill]

On Mon, Oct 12, 2020 at 11:15 AM Alan Cudmore 
wrote:

> Hi Chris,
> I'm not sure that I can easily create a test to show that this
> condition exists. I think the rtems_rfs_bitmap_create_search function
> works as it is intended to, but during the last iteration of the for
> loop, if 'size' is zero and 'bit' is 31, the 'search_map' variable is
> incremented once more, and the value of RTEMS_RFS_BITMAP_ELEMENT_CLEAR
> (0x) is written to that location. This location is one address
> beyond the memory that was allocated for the search_map in
> rtems_rfs_bitmap_open.
> I guess that most of the time this is a silent side effect, but my
> application just happened to have memory lined up such that the extra
> write causes the malloc Allocator mutex to fail, causing the
> malloc_info call to block indefinitely. I would consider this a lucky
> break!
> The exact same example application does not fail on RTEMS 4.11. I
> think the problem still exists, but in that case, the word that gets
> written is different.
>
> Here are some debug printfs from rtems_rfs_bitmap_open and
> rtems_rfs_bitmap_create_search:
>
> From rtems_rfs_bitmap_open:
> RFS - rtems_rfs_bitmap_open - search_bits malloced size = 16 bytes
> RFS - rtems_rfs_bitmap_open - addr of search_bits = 0x00C03814
> RFS -> size of search_map = 4
> RFS -> control->size = 4095
>
> From the subsequent call to rtems_rfs_bitmap_create_search:
> These printfs are in the if clause where bit == 31 (line 633)
> RFS --> search_map before increment addr 00C03814, size = 3071
> RFS --> search_map after increment -> writing
> RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03818
> RFS --> search_map before increment addr 00C03818, size = 2047
> RFS --> search_map after increment -> writing
> RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C0381C
> RFS --> search_map before increment addr 00C0381C, size = 1023
> RFS --> search_map after increment -> writing
> RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03820
> RFS --> search_map before increment addr 00C03820, size = 0
> RFS --> search_map after increment -> writing
> RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03824
>
> It's this last write to 00C03824 that causes the problem. I think the
> fix just involves checking to see if size == 0 before executing the if
> clause. I wanted to be sure that this extra write was not needed.
>
> If you have an idea for a test case, I can work on it, but if you
> think that this is good enough, I can propose a patch.
>
> Also, thanks for the idea of using RTEMS_DEBUG Sebastian, I need to
> upgrade my RTEMS toolbox with the latest techniques.
>

If, while analysing this issues, you came up with any consistency checks
or assertions that can be added to the code when debug is enabled,
those would be welcomed. It is hard to go back and add them without
the analysis like you did hunting this bug.

--joel


>
> Alan
>
>
> On Sun, Oct 11, 2020 at 6:20 PM Chris Johns  wrote:
> >
> > On 10/10/20 7:35 am, Alan Cudmore wrote:
> > > After doing a lot of tracing through my application, it looks like
> > > malloc_info works fine before we start our cFS application, but it
> > > blocks after the cFS is initialized. This suggests some sort of memory
> > > corruption.
> > > I started by instrumenting our code to call malloc info during various
> > > stages of application initialization, and finally narrowed it down to
> > > the code where we create a RAM Disk and format it with RFS.
> > > (skipping a bunch of other malloc based troubleshooting.. )
> > > After I followed the issue into the RFS init, I was able to narrow
> > > down the place where malloc_info stopped working to here:
> > >
> https://git.rtems.org/rtems/tree/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c?h=5#n637
> > > During the RFS format process.
> > > In this section of the code, the size variable is 0, meaning it will
> > > exit the for loop and then return from the function, but it increments
> > > the "search_map" variable and writes to memory through the pointer one
> > > more time before exiting the loop and function. It's at this point
> > > where malloc_info starts blocking.
> > >
> > > It seems to me that this if block should be skipped when size == 0. I
> > > tried that and the malloc_info issue seems to be fixed.
> >
> > Would you be able to create a test case for this? The test is ..
> >
> > https://git.rtems.org/rtems/tree/testsuites/fstests/fsrfsbitmap01/test.c
> >
> > Or if you could please provide the values in `control` I can add the
> test.
> >
> > > Is this an RFS bug writing into other memory, or is this last write
> > > needed before the function updates?
> >
> > It would seem so.
> >
> > > If this looks like a bug, should I write a ticket and provide a patch?
> >
> > Yes please. It would be nice to have a test case that fails so we can
> isolate
> > the cause.
> >
> > Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Need help debugging sp16.exe

[Joel Sherrill]

On Mon, Oct 12, 2020 at 10:47 AM Richi Dubey  wrote:

> There are existing checks scattered throughout the source. Do any need to
>> be in your scheduler?
>
> I don't understand. If there are already checks scattered through, why do
> I need more checks in my scheduler? Are these checks independent from the
> checks I might need in the scheduler? Please explain.
>

Your scheduler is a unique piece of software. It may be making assumptions
that are not checked in the generic scheduler code. And checks in other
schedulers are of no use to you.

There may not be any but this is something to consider.


>
> + Looks like the bsp has fast idle on but that should not impact anything.
>
> What's fast idle? I found this
> .
> :p How can time run as fast as possible?
>

Simulators tend to run slowly. They also may spend a long time when testing
RTEMS executing the idle thread waiting for time to pass. Fast idle just
says if a clock tick occurs while the idle thread is running, call clock
tick over and over until another thread is unblocked and preempts idle.

>
> + Run this with the another scheduler and see if you can identify when
>> that scheduler makes the decision you are missing. There has to be one of
>> the scheduler hooks that is making a different decision. Run the test side
>> by side with two different schedulers. Alternate forward motion in the two
>> and compare the behaviour.
>
> This is genius. Thanks a lot. I'm gonna work on this.
>
> + Adding trading might help but is probably more trouble to set up than
>> just comparing good and bad schedulers in parallel.
>
> What's trading?
>

That's a bad typo or auto-correct. Probably should have been tactic.

>
> + Look at what every failing test is doing. May be a common issue and one
>> is easier to debug
>
> Thanks. I'll check this.
>

Looking across all failing tests usually helps. For some reason, one tends
to be easier to debug than the others.

Also some of the tests have a lot of code up front that doesn't impact what
you are testing. It may be possible to disable early parts of sp16 to
reduce what you have to step through and compare schedulers.

--joel

>
>
> On Sun, Oct 11, 2020 at 5:08 AM Joel Sherrill  wrote:
>
>>
>>
>> On Sat, Oct 10, 2020, 10:47 AM Richi Dubey  wrote:
>>
>>> Hi Mr. Huber,
>>>
>>> Thanks for checking in.
>>>
>>> I suggested to enable your new scheduler implementation as the default
 to check if it is in line with the standard schedulers. I would first
 get some high level data. Select a BSP with good test results on a
 simulator (for example sparc/leon3 or arm/realview_pbx_a9_qemu). Run the
 tests and record the test data. Then enable the SMP EDF scheduler as the
 default, run the tests, record the data. Then enable your scheduler as
 the default, run the tests, record the data. Then get all tests which
 fail only with your scheduler.
>>>
>>> Yes, this is something I've already done based on your previous
>>> suggestion. I set SCHEDULER_STRONG_APA(the current RTEMS master's version)
>>> as the default scheduler for both sp and SMP and ran the test (on both
>>> sparc/leon3 and arm/realview_pbx_a9_qemu). Then I set
>>> SCHEDULER_STRONG_APA(my version) as the default scheduler for both sp and
>>> SMP and ran the test and compared it with the master's strong apa result.
>>> The following (extra) tests failed:
>>>
>>>  sp02.exe
>>>  sp16.exe
>>>  sp30.exe
>>>  sp31.exe
>>>  sp37.exe
>>>  sp42.exe
>>>  spfatal29.exe
>>>  tm24.exe
>>>
>>> Do a high level analysis of all failing
>>>
>>> tests. Try to figure out a new scenario for the test smpstrongapa01.
>>>
>>> Okay, I would look into this. This is a great suggestion, thanks!
>>>
>>>
>>> Do all the development with RTEMS_DEBUG enabled!
 Add _Assert() stuff to your scheduler. Check pre- and post-conditions of
 all operations. Check invariants.
>>>
>>> How do I check postconditions? Using _Assert() or by manually debugging
>>> each function call?
>>>
>>
>> There are existing checks scattered throughout the source. Do any need to
>> be in your scheduler?
>>
>> Random thoughts:
>>
>> + Looks like the bsp has fast idle on but that should not impact
>> anything.
>>
>> + Run this with the another scheduler and see if you can identify when
>> that scheduler makes the decision you are missing. There has to be one of
>> the scheduler hooks that is making a different decision. Run the test side
>> by side with two different schedulers. Alternate forward motion in the two
>> and compare the behaviour.
>>
>> + Adding trading might help but is probably more trouble to set up than
>> just comparing good and bad schedulers in parallel.
>>
>> + Look at what every failing test is doing. May be a common issue and one
>> is easier to debug
>>
>> --joel
>>
>>>
>>>
>>>
>>> On Sat, Oct 10, 2020 at 6:09 PM Sebastian Huber <
>>> sebastian.hu...@embedded-brains.de> wrote:
>>>
 Hello Richi

mvme3100 (mpc8540) and qemu mpc8544ds

[Joel Sherrill]

Hi

Looking at the PowerPC models supported by Qemu, I noticed this one and
looking at the mpc8544, it is so integrated that I wonder if these are
quite similar.

It would be nice to have a qemu platform with networking if these are close
enough to be an easy shot.

Any ideas?

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

Re: Build fail on debian - Toolset build error

[Chris Johns]

On 13/10/20 1:06 am, Karel Gardas wrote:
> On 10/12/20 3:50 PM, Anders Montonen wrote:
>> Hi,
>>
>>> On 12 Oct 2020, at 15:30, Karel Gardas >> > wrote:
>>>
>>>
>>> Sure, but you have to install header files whatever this means on
>>> macosx. On Ubuntu this means 'apt install python2.7-dev’
>>
>> System frameworks on macOs usually include the development libraries and
>> headers. Running “python-config —cflags”, and “python-config
>> —ldflags” returns the compiler and linker flags needed.
> 
> Check where is Python.h -- if it's available, then probably gdb's
> configure is not able to pick it up -- probably due to missing
> parameters -- which should be supplied by rsb. Anyway, you (or OP) are
> on macosx which is not that usual so you will probably need to do some
> tweaks. If it's not available, you need to convince your python install
> to install all headers and libs.
> 
> Also, have a look into rtems-source-builder/source-builder/sb -- not
> sure, but there is no macosx.py there but perhaps it should be... (like
> linux, openbsd, netbsd etc. are there too...)

The detection is here:

https://git.rtems.org/rtems-source-builder/tree/source-builder/config/gdb-common-1.cfg#n7

Updates welcome. The detection support is a continuous work in progress so if
something is needed to help a specific case please add it. The config looks for
a suitable python to use, then for the config command and then the settings it 
has.

Andrew, I do not test building with macports or homebrew. The amount of work
that would generate for me would be enough to consume all my time.

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