Re: Standalone repository for libnetworking stack

2021-02-25 Thread Gedare Bloom 
On Thu, Feb 25, 2021 at 6:06 PM Chris Johns  wrote:
>
> On 26/2/21 4:49 am, Vijay Kumar Banerjee wrote:
> > The stand-alone repository is very close to completion now and I could
> > use the networking01 test with the standalone repo and it successfully
> > runs on pc-qemu.
>
> Fantastic news.
>
> > The following are the links to the branches with the
> > final version of the commits and I would really appreciate a review
> > and suggestions on what else needs to be done (I'm not sending patches
> > as they're big and would hit the devel limit):
>
> I am fine reviewing the changes in the repos.
>
> > RTEMS: https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet
>
> Looks good. The only observation is a bisect will probability break as the
> nfsclient depends on rpc but I am OK with now things are.
>
> I checked rtems_waf and I think it is OK dealing with no networking defined in
> the RTEMS opts header.
>
> > rtems-net-legacy: 
> > https://git.rtems.org/vijay/rtems-net-legacy.git/log/?h=main
>
> Would calling lnetwork.py netlegacy.py be a better match for that name? Closer
> to the repo naming.
>
> Do the new python files need to pep8 formatted? :)
> [ https://gitlab.com/ita1024/waf/-/tree/master/playground/pep8 ]
>
> In bsp_drivers.py is there a waf node way to find the sources rather than a
> python os walk?
> [ https://waf.io/apidocs/Node.html#waflib.Node.Node.ant_glob ]
>
> Should the README reference rtems_waf and all the configure options it 
> supports?
>
> Do we need a LICENSE file?
>
> >
> > There are at least two things that need to be done:
> > 1. Shift the tests like mghttpd01 that use the libnetworking stack, to
> > the standalone repo like networking01
>
> OK
>
> > 2. There are still codes that use the #ifdef RTEMS_NETWORKING. What do
> > we want to do about those?
>
> How many BSPs/places/areas are we talking about?
>
> Would it be practical to add a cgit link to a ticket and then post an email to
> user and devel stating those interested in BSPs x,y,z to review the ticket? We
> then wait a week and after that the remaining defines are removed.
>
> Do we have a ticket for this task?
>
https://devel.rtems.org/ticket/3850

I'll let Vijay answer the rest.

> > Apart from these two points above, do the commits and the standalone
> > repo look OK (close to mergeable)?
>
> For me this is very close and a welcomed change for RTEMS 6. Really nice work.
>
> Thanks
> 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: About Chains in RTEMS

2021-02-25 Thread Richi Dubey 
Thanks a lot! Your suggestion helps. I'll look if there is any place where
double insertion/extraction is taking place.

On Thu, Feb 25, 2021 at 8:57 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 25/02/2021 10:47, Richi Dubey wrote:
>
> > Hi,
> >
> > When I am debugging the call to _Chain_Append_unprotected (from line
> > 92
> >  of
>
> > sp02, rtems_task_delete -> _Thread_Close ->...->_Thread_Cancel -> ...
> > ->_Scheduler_Unblock -> ... _Scheduler_strong_APA_Insert_ready
> > -> _Chain_Append_unprotected), I see a weird chain behavior where
> > there's some kind of cycle:
> >
> > (gdb) p _Chain_Tail(the_chain)
> > $20 = (Chain_Node *) 0x200768
> > <_Configuration_Scheduler_strong_APA_dflt+40>
> > (gdb) p _Chain_Tail(the_chain)->previous
> > $21 = (Chain_Node *) 0x2014e8 <_RTEMS_tasks_Objects+2024>
> > (gdb) p (_Chain_Tail(the_chain)->previous)->previous
> > $22 = (Chain_Node *) 0x200fe0 <_RTEMS_tasks_Objects+736>
> > (gdb) p ((_Chain_Tail(the_chain)->previous)->previous)->previous
> > $23 = (Chain_Node *) 0x2014e8 <_RTEMS_tasks_Objects+2024>
> > (gdb) p
> > (((_Chain_Tail(the_chain)->previous)->previous)->previous)->previous
> > $24 = (Chain_Node *) 0x200fe0 <_RTEMS_tasks_Objects+736>
> >
> >
> > sp02 is a single processor test and I am trying to run it on the
> > Strong APA SMP scheduler. Can someone please give an insight into what
> > might be causing this? The Strong APA scheduler does not affect the
> > functioning of the chain, it only uses the chain using standard
> > function headers defined in chain.h
> Cycles in a chain may be caused by double insertions or extractions. I
> would enable RTEMS_DEBUG since it adds assertions for these cases.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Standalone repository for libnetworking stack

2021-02-25 Thread Chris Johns 
On 26/2/21 4:49 am, Vijay Kumar Banerjee wrote:
> The stand-alone repository is very close to completion now and I could
> use the networking01 test with the standalone repo and it successfully
> runs on pc-qemu. 

Fantastic news.

> The following are the links to the branches with the
> final version of the commits and I would really appreciate a review
> and suggestions on what else needs to be done (I'm not sending patches
> as they're big and would hit the devel limit):

I am fine reviewing the changes in the repos.

> RTEMS: https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet

Looks good. The only observation is a bisect will probability break as the
nfsclient depends on rpc but I am OK with now things are.

I checked rtems_waf and I think it is OK dealing with no networking defined in
the RTEMS opts header.

> rtems-net-legacy: https://git.rtems.org/vijay/rtems-net-legacy.git/log/?h=main

Would calling lnetwork.py netlegacy.py be a better match for that name? Closer
to the repo naming.

Do the new python files need to pep8 formatted? :)
[ https://gitlab.com/ita1024/waf/-/tree/master/playground/pep8 ]

In bsp_drivers.py is there a waf node way to find the sources rather than a
python os walk?
[ https://waf.io/apidocs/Node.html#waflib.Node.Node.ant_glob ]

Should the README reference rtems_waf and all the configure options it supports?

Do we need a LICENSE file?

> 
> There are at least two things that need to be done:
> 1. Shift the tests like mghttpd01 that use the libnetworking stack, to
> the standalone repo like networking01

OK

> 2. There are still codes that use the #ifdef RTEMS_NETWORKING. What do
> we want to do about those?

How many BSPs/places/areas are we talking about?

Would it be practical to add a cgit link to a ticket and then post an email to
user and devel stating those interested in BSPs x,y,z to review the ticket? We
then wait a week and after that the remaining defines are removed.

Do we have a ticket for this task?

> Apart from these two points above, do the commits and the standalone
> repo look OK (close to mergeable)?

For me this is very close and a welcomed change for RTEMS 6. Really nice work.

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

Re: [PATCH 01/10] build: Generate build hash

2021-02-25 Thread Chris Johns 
On 26/2/21 2:18 am, Sebastian Huber wrote:
> On 25/02/2021 09:42, Sebastian Huber wrote:
>>> Should we look to use a list that is contained? A list that effects the 
>>> code on
>>> the target? In a purest sense a hash created from the CU pieces in all 
>>> target
>>> libraries would be ideal however this is recursive.
>> This is a good idea. Maybe we should iterate over all start files and
>> libraries generated by the build and then create a hash of all executable
>> sections. Then we recompile one object with a command line define with the
>> build hash and replace this object in librtemscpu.a.
> I will drop for now the introduction of a rtems_get_build_hash() in favour of 
> a
> rtems_get_build_label() since my waf skills are not good enough to do the 
> above
> task.

Lets chip away at this. I think it is important.

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

Re: [PATCH 01/10] build: Generate build hash

2021-02-25 Thread Chris Johns 
On 25/2/21 7:42 pm, Sebastian Huber wrote:
> On 25/02/2021 05:13, Chris Johns wrote:
> 
>> On 25/2/21 12:57 am, Sebastian Huber wrote:
>>> Update #4265.
>>> ---
>>>   wscript | 27 ++-
>>>   1 file changed, 26 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/wscript b/wscript
>>> index 6626fafb74..83c7c446bb 100755
>>> --- a/wscript
>>> +++ b/wscript
>>> @@ -1359,6 +1359,30 @@ def get_compiler(conf, cp, variant):
>>>   return value
>>>     +def _generate_build_hash(conf):
>>> +    import hashlib
>>> +    import base64
>>> +
>>> +    build_hash = ""
>>> +    for key in sorted(conf.env):
>>> +    build_hash = build_hash + key + str(conf.env[key])
>> I am pleased to see the environment is being addressed but on some modern
>> operating systems the environment has become a bit of a beast. This means
>> comparable values will be near impossible if the whole environment is 
>> included
>> in the build hash.
>>
>> Should we look to use a list that is contained? A list that effects the code 
>> on
>> the target? In a purest sense a hash created from the CU pieces in all target
>> libraries would be ideal however this is recursive.
> This is a good idea. Maybe we should iterate over all start files and 
> libraries
> generated by the build and then create a hash of all executable sections. Then
> we recompile one object with a command line define with the build hash and
> replace this object in librtemscpu.a.

Nice. I wonder if this could then include the gcc/newlib library mix for that 
BSP?

The hash generator could be added to `rtems-exe-info` without too much effort.
The toolkit can handle ELF object and archives out of the box and the code to
read a section into memory is somewhere in the `ra` tools so at hand.

Which ELF sections flags should be matched? Just executable, const, string etc?

>> Any chance of a build label set in the config.ini? :)
> You want something like a rtems_get_build_label() which returns the value of
> RTEMS_BUILD_LABEL set in a config.ini (or a default, e.g. "arch/bsp")?

Yes I would. Felix (gemini) and I are working at the moment to find why his
RTEMS 5 build is not working and this sort of enumeration would help. The
ability to label an RTEMS build in a simple non-invasive manner would help all
RTEMS deployments.

>>
>>> +    for discard in [
>>> +    conf.env.PREFIX,
>>> +    conf.bldnode.make_node(conf.env.VARIANT).abspath(),
>>> +    conf.path.abspath(),
>>> +    ]:
>>> +    build_hash = build_hash.replace(discard, "")
>> I do not follow this piece of logic.
> It removes prefix, source and build paths.

OK.

>>> +    state = hashlib.sha256()
>>> +    state.update(build_hash.encode("utf-8"))
>> Why the `utf-8` encode and then decode later?
> The hash update needs a byte stream not a string. The define needs a string 
> and
> not a byte stream.

Thanks

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

Re: BSP Builder Results :(

2021-02-25 Thread Chris Johns 
On 26/2/21 8:33 am, junkes wrote:
> With RTEMS6, frozen CPU even with the ubuntu mkimage:

Thanks Heinz.

We need to isolate and resolve this issue before removing autoconf. I do not
think the powerpc bsps build with autotools at the moment so it is hard to say
if there is an issue in the BSP or in the waf build.

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

Re: BSP Builder Results :(

2021-02-25 Thread junkes 

With RTEMS6, frozen CPU even with the ubuntu mkimage:

MVME2500=> setenv tfile hello
MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 13 ms (928.7 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'hello.img'.
Load address: 0x1000
Loading: ##
6.2 MiB/s
done
Bytes transferred = 77800 (12fe8 hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 1000 ...
Image Name: RTEMS
Created: 2021-02-25 20:30:19 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 77736 Bytes = 75.9 KiB
Load Address: 4000
Entry Point: 4000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2000
Booting using the fdt blob at 0x2000
Uncompressing Kernel Image ... OK
Loading Device Tree to 03ff9000, end 03fff04a ... OK

> no more output ...

On 2021-02-25 20:52, junkes wrote:


I have now done the whole thing again the "old way"

(master, checkout 5
./bootstrap -c && ./rtems-bootstrap
cd ..
mkdir -p build/b-qoriq_e500
cd build/b-qoriq_e500
../../kernel/configure --prefix=/home/junkes/MVME2500_testing/rtems/5 
--target=powerpc-rtems5 --enable-rtemsbsp=qoriq_e500 --enable-posix 
--enable-c++ --disable-networking --enable-tests

make -j17 all
make install
)

with RTEMS 5 and have come to the same result (frozen CPU).

Then instead of using mkimage.pl I used my standard way:

powerpc-rtems5-objcopy -O binary 
b-qoriq_e500/powerpc-rtems5/c/qoriq_e500/testsuites/samples/hello.exe 
hello.bin

mv hello.img hello_mkimage.img
gzip -9 -f -c hello.bin > hello.bin.gz
mkimage -A ppc -O linux -T kernel -a 0x4000 -e 0x4000 -n RTEMS -d 
hello.bin.tgz hello.img


(mkimage from the ubuntu distro:
junkes@Krikkit:~/MVME2500_testing$ mkimage -V
mkimage version 2020.10+dfsg-1ubuntu0~20.04.2
)
Et voila:

MVME2500=> setenv tfile hello
MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 13 ms (928.7 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'hello.img'.
Load address: 0x1000
Loading: #
5.7 MiB/s
done
Bytes transferred = 59818 (e9aa hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 1000 ...
Image Name: RTEMS
Created: 2021-02-25 19:38:30 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 59754 Bytes = 58.4 KiB
Load Address: 4000
Entry Point: 4000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2000
Booting using the fdt blob at 0x2000
Uncompressing Kernel Image ... OK
Loading Device Tree to 03ff9000, end 03fff04a ... OK

*** BEGIN OF TEST HELLO WORLD ***
*** TEST VERSION: 5.0.0.3824960f24304eec051fdc59121ba9ba8a8346da
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5 (803d42cda7b3), Newlib 
7947581)

Hello World

*** END OF TEST HELLO WORLD ***

*** FATAL ***
fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
fatal code: 0 (0x)
RTEMS version: 5.0.0.3824960f24304eec051fdc59121ba9ba8a8346da
RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (803d42cda7b3), Newlib 
7947581)

executing thread ID: 0x08a010001
executing thread name: UI1

U-Boot 2013.01 (Aug 23 2016 - 12:17:55)

CPU0: P2020E, Version: 2.1, (0x80ea0021)
Core: E500, Version: 5.1, (0x80211051)
Clock Configuration:
CPU0:1200 MHz, CPU1:1200 MHz,
CCB:400 MHz,
DDR:400 MHz (800 MT/s data rate) (Asynchronous), LBC:25 MHz
L1: D-cache 32 kB enabled

Now, I will repeat the Installation of RTEMS6 again and try the ubuntu 
mkimage


Heinz

On 2021-02-25 18:23, Joel Sherrill wrote:

On Thu, Feb 25, 2021 at 11:15 AM junkes  
wrote:


Hallo Joel,
unfortunately, even with waf, it still does not work as it should.

Building and not working is slightly better but still bad. :(

The bsp-builder doesn't run any tests. I do run automated test runs on 
a
number  of BSPs and have had to login to the server and kill qemu's 
that

get stuck and run forever. I haven't tracked down which BSP is hanging
yet though.

Example MVME2500 (qoriq_e500)

#install rsb and rtems powerpc tools
git clone https://github.com/RTEMS/rtems-source-builder.git rsb
cd rsb/rtems
../source-builder/sb-set-builder 
--prefix=/home/junkes/MVME2500_testing/rtems/6 6/rtems-powerpc

cd ../..

#RTEMS development
export RTEMS_VERSION=6
export RTEMS_ARCH=powerpc-rtems${RTEMS_VERSION}
export RTEMS_ROOT=/home/junkes/MVME2500_testing/rtems/${RTEMS_VERSION}
export PATH=${RTEMS_ROOT}/bin:${PATH}

# building kernel
git clone git://git.rtems.org/rtems.git [1] kernel
cd kernel
# build and install bsp
./waf bsp_defaults --rtems-bsps=powerpc/qoriq_e500 > config.ini
sed -i \
-e "s|RTEMS_POSIX_API = False|RTEMS_POSIX_API = True|" \
-e "s|CLOCK_DRIVER_USE_FAST_IDLE = True|CLOCK_DRIVER_USE_FAST_IDLE = 
False|" \

-e "s|BUILD_TESTS = False|BUILD_TESTS = True|" \
config.ini
./waf configure --prefix=/home/junkes/MVME2500_testing/rtems/6

Re: BSP Builder Results :(

2021-02-25 Thread junkes 

I have now done the whole thing again the "old way"

(master, checkout 5
./bootstrap -c && ./rtems-bootstrap
cd ..
mkdir -p build/b-qoriq_e500
cd build/b-qoriq_e500
../../kernel/configure --prefix=/home/junkes/MVME2500_testing/rtems/5 
--target=powerpc-rtems5 --enable-rtemsbsp=qoriq_e500 --enable-posix 
--enable-c++ --disable-networking --enable-tests

make -j17 all
make install
)

with RTEMS 5 and have come to the same result (frozen CPU).

Then instead of using mkimage.pl I used my standard way:

powerpc-rtems5-objcopy -O binary 
b-qoriq_e500/powerpc-rtems5/c/qoriq_e500/testsuites/samples/hello.exe 
hello.bin

mv hello.img hello_mkimage.img
gzip -9 -f -c hello.bin > hello.bin.gz
mkimage -A ppc -O linux -T kernel -a 0x4000 -e 0x4000 -n RTEMS -d 
hello.bin.tgz hello.img


(mkimage from the ubuntu distro:
junkes@Krikkit:~/MVME2500_testing$ mkimage -V
mkimage version 2020.10+dfsg-1ubuntu0~20.04.2
)
Et voila:

MVME2500=> setenv tfile hello
MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 13 ms (928.7 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'hello.img'.
Load address: 0x1000
Loading: #
5.7 MiB/s
done
Bytes transferred = 59818 (e9aa hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 1000 ...
Image Name: RTEMS
Created: 2021-02-25 19:38:30 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 59754 Bytes = 58.4 KiB
Load Address: 4000
Entry Point: 4000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2000
Booting using the fdt blob at 0x2000
Uncompressing Kernel Image ... OK
Loading Device Tree to 03ff9000, end 03fff04a ... OK

*** BEGIN OF TEST HELLO WORLD ***
*** TEST VERSION: 5.0.0.3824960f24304eec051fdc59121ba9ba8a8346da
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5 (803d42cda7b3), Newlib 
7947581)

Hello World

*** END OF TEST HELLO WORLD ***

*** FATAL ***
fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
fatal code: 0 (0x)
RTEMS version: 5.0.0.3824960f24304eec051fdc59121ba9ba8a8346da
RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (803d42cda7b3), Newlib 
7947581)

executing thread ID: 0x08a010001
executing thread name: UI1

U-Boot 2013.01 (Aug 23 2016 - 12:17:55)

CPU0: P2020E, Version: 2.1, (0x80ea0021)
Core: E500, Version: 5.1, (0x80211051)
Clock Configuration:
CPU0:1200 MHz, CPU1:1200 MHz,
CCB:400 MHz,
DDR:400 MHz (800 MT/s data rate) (Asynchronous), LBC:25 MHz
L1: D-cache 32 kB enabled

Now, I will repeat the Installation of RTEMS6 again and try the ubuntu 
mkimage


Heinz

On 2021-02-25 18:23, Joel Sherrill wrote:

On Thu, Feb 25, 2021 at 11:15 AM junkes  
wrote:



Hallo Joel,
unfortunately, even with waf, it still does not work as it should.


Building and not working is slightly better but still bad. :(

The bsp-builder doesn't run any tests. I do run automated test runs on 
a
number  of BSPs and have had to login to the server and kill qemu's 
that

get stuck and run forever. I haven't tracked down which BSP is hanging
yet though.

Example MVME2500 (qoriq_e500)

#install rsb and rtems powerpc tools
git clone https://github.com/RTEMS/rtems-source-builder.git rsb
cd rsb/rtems
../source-builder/sb-set-builder 
--prefix=/home/junkes/MVME2500_testing/rtems/6 6/rtems-powerpc

cd ../..

#RTEMS development
export RTEMS_VERSION=6
export RTEMS_ARCH=powerpc-rtems${RTEMS_VERSION}
export RTEMS_ROOT=/home/junkes/MVME2500_testing/rtems/${RTEMS_VERSION}
export PATH=${RTEMS_ROOT}/bin:${PATH}

# building kernel
git clone git://git.rtems.org/rtems.git [1] kernel
cd kernel
# build and install bsp
./waf bsp_defaults --rtems-bsps=powerpc/qoriq_e500 > config.ini
sed -i \
-e "s|RTEMS_POSIX_API = False|RTEMS_POSIX_API = True|" \
-e "s|CLOCK_DRIVER_USE_FAST_IDLE = True|CLOCK_DRIVER_USE_FAST_IDLE = 
False|" \

-e "s|BUILD_TESTS = False|BUILD_TESTS = True|" \
config.ini
./waf configure --prefix=/home/junkes/MVME2500_testing/rtems/6
./waf
./waf install

#create bootable image file
cd ..
mkimage.py -A ppc -O linux -T kernel -a 0x4000 -e 0x4000 -n RTEMS -d 
kernel/build/powerpc/qoriq_e500/testsuites/samples/hello.exe hello.img


junkes@Krikkit:~/MVME2500_testing$ ls -l hello.img
-rw-rw-r-- 1 junkes junkes 2990848 Feb 25 17:50 hello.img

#boot file on HW (MVME2500)

MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 12 ms (1005.9 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'hello.img'.
Load address: 0x1000
Loading: 
#

#
#
#
10.6 MiB/s
done
Bytes transferred = 2990848 (2da300 hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 1000

[PATCH] score: Fix thread initialization

2021-02-25 Thread Sebastian Huber 
Close the thread object if a thread create extension fails.  Also call
the delete extension to avoid resource leaks in early extensions if a
late extension fails.

Close #4270.
---
 cpukit/include/rtems/posix/pthreadimpl.h  |7 -
 cpukit/include/rtems/score/threadimpl.h   |   22 +-
 cpukit/posix/src/pthreadcreate.c  |   39 +-
 cpukit/rtems/src/taskconstruct.c  |   23 +-
 cpukit/score/src/mpci.c   |7 +-
 cpukit/score/src/threadcreateidle.c   |7 +-
 cpukit/score/src/threadinitialize.c   |  142 +-
 cpukit/score/src/threadrestart.c  |   51 +-
 .../validation/tc-task-construct-errors.c | 1753 -
 9 files changed, 1434 insertions(+), 617 deletions(-)

diff --git a/cpukit/include/rtems/posix/pthreadimpl.h 
b/cpukit/include/rtems/posix/pthreadimpl.h
index 74e46e4d92..52d462ab6f 100644
--- a/cpukit/include/rtems/posix/pthreadimpl.h
+++ b/cpukit/include/rtems/posix/pthreadimpl.h
@@ -107,13 +107,6 @@ RTEMS_INLINE_ROUTINE Thread_Control 
*_POSIX_Threads_Allocate(void)
 _Objects_Allocate_unprotected( &_POSIX_Threads_Information.Objects );
 }
 
-RTEMS_INLINE_ROUTINE void _POSIX_Threads_Free (
-  Thread_Control *the_pthread
-)
-{
-  _Objects_Free( &_POSIX_Threads_Information.Objects, _pthread->Object );
-}
-
 /** @} */
 
 #ifdef __cplusplus
diff --git a/cpukit/include/rtems/score/threadimpl.h 
b/cpukit/include/rtems/score/threadimpl.h
index 0c7df47f36..1e7d58609f 100644
--- a/cpukit/include/rtems/score/threadimpl.h
+++ b/cpukit/include/rtems/score/threadimpl.h
@@ -201,15 +201,31 @@ typedef struct {
  * @param the_thread The thread to initialize.
  * @param config The configuration of the thread to initialize.
  *
- * @retval true The thread initialization was successful.
- * @retval false The thread initialization failed.
+ * @retval STATUS_SUCCESSFUL The thread initialization was successful.
+ *
+ * @retval STATUS_UNSATISFIED The thread initialization failed.
  */
-bool _Thread_Initialize(
+Status_Control _Thread_Initialize(
   Thread_Information *information,
   Thread_Control *the_thread,
   const Thread_Configuration *config
 );
 
+/**
+ * @brief Frees the thread.
+ *
+ * This routine invokes the thread delete extensions and frees all resources
+ * associated with the thread.  Afterwards the thread object is closed.
+ *
+ * @param[in, out] information is the thread information.
+ *
+ * @param[in, out] the_thread is the thread to free.
+ */
+void _Thread_Free(
+  Thread_Information *information,
+  Thread_Control *the_thread
+);
+
 /**
  * @brief Starts the specified thread.
  *
diff --git a/cpukit/posix/src/pthreadcreate.c b/cpukit/posix/src/pthreadcreate.c
index 33c5f8d03a..55ba73c8b4 100644
--- a/cpukit/posix/src/pthreadcreate.c
+++ b/cpukit/posix/src/pthreadcreate.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #if defined(RTEMS_POSIX_API)
 #include 
@@ -72,7 +73,8 @@ int pthread_create(
   int normal_prio;
   boolvalid;
   Thread_Configurationconfig;
-  boolstatus;
+  Status_Control  status;
+  boolok;
   Thread_Control *the_thread;
   Thread_Control *executing;
   int schedpolicy = SCHED_RR;
@@ -224,22 +226,23 @@ int pthread_create(
 config.stack_free = _Stack_Free_nothing;
   }
 
-  status = ( config.stack_area != NULL );
+  if ( config.stack_area == NULL ) {
+_Objects_Free( &_POSIX_Threads_Information.Objects, _thread->Object );
+_Objects_Allocator_unlock();
+return EAGAIN;
+  }
 
   /*
*  Initialize the core thread for this task.
*/
-  if ( status ) {
-status = _Thread_Initialize(
-  &_POSIX_Threads_Information,
-  the_thread,
-  
-);
-  }
-  if ( !status ) {
-_POSIX_Threads_Free( the_thread );
+  status = _Thread_Initialize(
+&_POSIX_Threads_Information,
+the_thread,
+
+  );
+  if ( status != STATUS_SUCCESSFUL ) {
 _Objects_Allocator_unlock();
-return EAGAIN;
+return _POSIX_Get_error( status );
   }
 
   if ( the_attr->detachstate == PTHREAD_CREATE_DETACHED ) {
@@ -249,14 +252,14 @@ int pthread_create(
   the_thread->Life.state |= THREAD_LIFE_CHANGE_DEFERRED;
 
   _ISR_lock_ISR_disable( _context );
-   status = _Scheduler_Set_affinity(
+   ok = _Scheduler_Set_affinity(
  the_thread,
  the_attr->affinitysetsize,
  the_attr->affinityset
);
   _ISR_lock_ISR_enable( _context );
-   if ( !status ) {
- _POSIX_Threads_Free( the_thread );
+   if ( !ok ) {
+  _Thread_Free( &_POSIX_Threads_Information, the_thread );
  _RTEMS_Unlock_allocator();
  return EINVAL;
}
@@ -287,7 +290,7 @@ int pthread_create(
*  POSIX threads are allocated and started in one operation.
*/
   _ISR_lock_ISR_disable( _context );
-  status =

Re: Standalone repository for libnetworking stack

2021-02-25 Thread Vijay Kumar Banerjee 
Hi,

The stand-alone repository is very close to completion now and I could
use the networking01 test with the standalone repo and it successfully
runs on pc-qemu. The following are the links to the branches with the
final version of the commits and I would really appreciate a review
and suggestions on what else needs to be done (I'm not sending patches
as they're big and would hit the devel limit):

RTEMS: https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet
rtems-net-legacy: https://git.rtems.org/vijay/rtems-net-legacy.git/log/?h=main

There are at least two things that need to be done:
1. Shift the tests like mghttpd01 that use the libnetworking stack, to
the standalone repo like networking01
2. There are still codes that use the #ifdef RTEMS_NETWORKING. What do
we want to do about those?

Apart from these two points above, do the commits and the standalone
repo look OK (close to mergeable)?

Best regards,
Vijay


On Tue, Feb 9, 2021 at 5:47 PM Vijay Kumar Banerjee  wrote:
>
> On Tue, Feb 9, 2021 at 3:31 PM Chris Johns  wrote:
> >
> > On 6/2/21 10:17 am, Vijay Kumar Banerjee wrote:
> > > Hello Christian, Joel, Chris,
> > >
> > > On Fri, Feb 5, 2021 at 3:41 PM Chris Johns  wrote:
> > >>
> > >> On 6/2/21 8:28 am, Joel Sherrill wrote:
> > >>> On Fri, Feb 5, 2021 at 2:54 PM Christian Mauderer  > >>> > wrote:
> > >>>
> > >>> Hello Vijay,
> > >>>
> > >>> On 05/02/2021 19:41, Vijay Kumar Banerjee wrote:
> > >>> > Hello,
> > >>> >
> > >>> > I'm currently working on separating the libnetworking stack into 
> > >>> its
> > >>> > standalone repository that can be built separately with waf. The 
> > >>> current
> > >>> > status of the project is that I have a working rtems-libnetworking
> > >>> > repository [1] that builds with waf (hasn't been tested with any 
> > >>> test
> > >>> > cases yet). And In my fork of RTEMS I have separated the 
> > >>> libnetworking
> > >>> > stack [2].
> > >>
> > >> If you have not already done so I suggest you create repos in your 
> > >> personal area
> > >> on dispatch.rtems.org and these will appear on the cgit page. It is a 
> > >> simple way
> > >> to get exposure to the work.
> > >>
> > > I do have some repos in my area in dispatch.rtems.org but for some
> > > reason they don't appear in git.rtems.org page that's why I pushed it
> > > in github. Am I possibly missing some step?
> >
> > I have fixed the cgit viewing. I am sorry for the delay.
> >
> > Your repos are there, valid and available. On dispatch.rtems.org in
> > /data/git/users a symlink needs to be set to your physical repo path under
> > /data/git. I have done this. The cgit server is configured to scan
> > /data/git/user so it does not pick some dormant but present repos.
> >
>
> Thanks! It's now working and here's the rtems-net-legacy repo:
> https://git.rtems.org/vijay/rtems-net-legacy.git/
>
> Best regards,
> Vijay
> > Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP Builder Results :(

2021-02-25 Thread Joel Sherrill 
On Thu, Feb 25, 2021 at 11:15 AM junkes  wrote:

> Hallo Joel,
> unfortunately, even with waf, it still does not work as it should.
>

Building and not working is slightly better but still bad. :(

The bsp-builder doesn't run any tests. I do run automated test runs on a
number  of BSPs and have had to login to the server and kill qemu's that
get stuck and run forever. I haven't tracked down which BSP is hanging
yet though.

> Example MVME2500 (qoriq_e500)
>
> #install rsb and rtems powerpc tools
> git clone https://github.com/RTEMS/rtems-source-builder.git rsb
> cd rsb/rtems
> ../source-builder/sb-set-builder
> --prefix=/home/junkes/MVME2500_testing/rtems/6 6/rtems-powerpc
> cd ../..
>
> #RTEMS development
> export RTEMS_VERSION=6
> export RTEMS_ARCH=powerpc-rtems${RTEMS_VERSION}
> export RTEMS_ROOT=/home/junkes/MVME2500_testing/rtems/${RTEMS_VERSION}
> export PATH=${RTEMS_ROOT}/bin:${PATH}
>
> # building kernel
> git clone git://git.rtems.org/rtems.git kernel
> cd kernel
> # build and install bsp
> ./waf bsp_defaults --rtems-bsps=powerpc/qoriq_e500 > config.ini
> sed -i \
> -e "s|RTEMS_POSIX_API = False|RTEMS_POSIX_API = True|" \
> -e "s|CLOCK_DRIVER_USE_FAST_IDLE = True|CLOCK_DRIVER_USE_FAST_IDLE =
> False|" \
> -e "s|BUILD_TESTS = False|BUILD_TESTS = True|" \
> config.ini
> ./waf configure --prefix=/home/junkes/MVME2500_testing/rtems/6
> ./waf
> ./waf install
>
> #create bootable image file
> cd ..
> mkimage.py -A ppc -O linux -T kernel -a 0x4000 -e 0x4000 -n RTEMS -d
> kernel/build/powerpc/qoriq_e500/testsuites/samples/hello.exe hello.img
>
> junkes@Krikkit:~/MVME2500_testing$ ls -l hello.img
> -rw-rw-r-- 1 junkes junkes 2990848 Feb 25 17:50 hello.img
>
> #boot file on HW (MVME2500)
>
> MVME2500=> run rtems_myTests
> reading mvme2500.dtb
> 12363 bytes read in 12 ms (1005.9 KiB/s)
> Speed: 1000, full duplex
> Using eTSEC1 device
> TFTP from server 141.14.128.9; our IP address is 141.14.128.89
> Filename 'hello.img'.
> Load address: 0x1000
> Loading: #
> #
> #
> #
> 10.6 MiB/s
> done
> Bytes transferred = 2990848 (2da300 hex)
> WARNING: adjusting available memory to 3000
> ## Booting kernel from Legacy Image at 1000 ...
> Image Name: RTEMS
> Created: 2021-02-25 16:50:29 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 2990784 Bytes = 2.9 MiB
> Load Address: 4000
> Entry Point: 4000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 2000
> Booting using the fdt blob at 0x2000
> Uncompressing Kernel Image ... Error: Bad gzipped data
> GUNZIP: uncompress, out-of-mem or overwrite error - must RESET board to
> recover
>
>
> U-Boot 2013.01 (Aug 23 2016 - 12:17:55)
>
> CPU0: P2020E, Version: 2.1, (0x80ea0021)
> Core: E500, Version: 5.1, (0x80211051)
> Clock Configuration:
> CPU0:1200 MHz, CPU1:1200 MHz,
> CCB:400 MHz,
> DDR:400 MHz (800 MT/s data rate) (Asynchronous), LBC:25 MHz
> L1: D-cache 32 kB enabled
> ...
>
> With mkimage no compression:
>
> mkimage.py -A ppc -O linux -T kernel -C none -a 0x4000 -e 0x4000 -n RTEMS
> -d kernel/build/powerpc/qoriq_e500/testsuites/samples/hello.exe hello.img
> Image Name: RTEMS
> Created: Thu Feb 25 18:10:00 2021
> Image Type: none
> Data Size: 2990784
> Load Address: 0x4000
> Entry Point: 0x4000
>
> Now the well known behavior -> hangs, must be HW-reset
>
> MVME2500=> setenv tfile hello
> MVME2500=> run rtems_myTests
> reading mvme2500.dtb
> 12363 bytes read in 13 ms (928.7 KiB/s)
> Speed: 1000, full duplex
> Using eTSEC1 device
> TFTP from server 141.14.128.9; our IP address is 141.14.128.89
> Filename 'hello.img'.
> Load address: 0x1000
> Loading: #
> #
> #
> #
> 10.3 MiB/s
> done
> Bytes transferred = 2990848 (2da300 hex)
> WARNING: adjusting available memory to 3000
> ## Booting kernel from Legacy Image at 1000 ...
> Image Name: RTEMS
> Created: 2021-02-25 17:10:00 UTC
> Image Type: PowerPC Linux Kernel Image (uncompressed)
> Data Size: 2990784 Bytes = 2.9 MiB
> Load Address: 4000
> Entry Point: 4000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 2000
> Booting using the fdt blob at 0x2000
> Loading Kernel Image ... OK
> OK
> Loading Device Tree to 03ff9000, end 03fff04a ... OK
>
> -> no more output ... frozen target 
>
> On 2021-02-25 14:45, Joel Sherrill wrote:
>
> Hi
>
> Just passing along that the need to switch the BSP builder to waf is
> becoming more obvious in the BSP Builder results
>
> https://lists.rtems.org/pipermail/build/2021-February/026054.html
>
> 467 of 1615 configurations now fail to build.
>
> -joel
>
>

Re: BSP Builder Results :(

2021-02-25 Thread junkes 

Hallo Joel,
unfortunately, even with waf, it still does not work as it should.

Example MVME2500 (qoriq_e500)

#install rsb and rtems powerpc tools
git clone https://github.com/RTEMS/rtems-source-builder.git rsb
cd rsb/rtems
../source-builder/sb-set-builder 
--prefix=/home/junkes/MVME2500_testing/rtems/6 6/rtems-powerpc

cd ../..

#RTEMS development
export RTEMS_VERSION=6
export RTEMS_ARCH=powerpc-rtems${RTEMS_VERSION}
export RTEMS_ROOT=/home/junkes/MVME2500_testing/rtems/${RTEMS_VERSION}
export PATH=${RTEMS_ROOT}/bin:${PATH}

# building kernel
git clone git://git.rtems.org/rtems.git kernel
cd kernel
# build and install bsp
./waf bsp_defaults --rtems-bsps=powerpc/qoriq_e500 > config.ini
sed -i \
-e "s|RTEMS_POSIX_API = False|RTEMS_POSIX_API = True|" \
-e "s|CLOCK_DRIVER_USE_FAST_IDLE = True|CLOCK_DRIVER_USE_FAST_IDLE = 
False|" \

-e "s|BUILD_TESTS = False|BUILD_TESTS = True|" \
config.ini
./waf configure --prefix=/home/junkes/MVME2500_testing/rtems/6
./waf
./waf install

#create bootable image file
cd ..
mkimage.py -A ppc -O linux -T kernel -a 0x4000 -e 0x4000 -n RTEMS -d 
kernel/build/powerpc/qoriq_e500/testsuites/samples/hello.exe hello.img


junkes@Krikkit:~/MVME2500_testing$ ls -l hello.img
-rw-rw-r-- 1 junkes junkes 2990848 Feb 25 17:50 hello.img

#boot file on HW (MVME2500)

MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 12 ms (1005.9 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'hello.img'.
Load address: 0x1000
Loading: 
#

#
#
#
10.6 MiB/s
done
Bytes transferred = 2990848 (2da300 hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 1000 ...
Image Name: RTEMS
Created: 2021-02-25 16:50:29 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 2990784 Bytes = 2.9 MiB
Load Address: 4000
Entry Point: 4000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2000
Booting using the fdt blob at 0x2000
Uncompressing Kernel Image ... Error: Bad gzipped data
GUNZIP: uncompress, out-of-mem or overwrite error - must RESET board to 
recover


U-Boot 2013.01 (Aug 23 2016 - 12:17:55)

CPU0: P2020E, Version: 2.1, (0x80ea0021)
Core: E500, Version: 5.1, (0x80211051)
Clock Configuration:
CPU0:1200 MHz, CPU1:1200 MHz,
CCB:400 MHz,
DDR:400 MHz (800 MT/s data rate) (Asynchronous), LBC:25 MHz
L1: D-cache 32 kB enabled
...

With mkimage no compression:

mkimage.py -A ppc -O linux -T kernel -C none -a 0x4000 -e 0x4000 -n 
RTEMS -d kernel/build/powerpc/qoriq_e500/testsuites/samples/hello.exe 
hello.img

Image Name: RTEMS
Created: Thu Feb 25 18:10:00 2021
Image Type: none
Data Size: 2990784
Load Address: 0x4000
Entry Point: 0x4000

Now the well known behavior -> hangs, must be HW-reset

MVME2500=> setenv tfile hello
MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 13 ms (928.7 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'hello.img'.
Load address: 0x1000
Loading: 
#

#
#
#
10.3 MiB/s
done
Bytes transferred = 2990848 (2da300 hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 1000 ...
Image Name: RTEMS
Created: 2021-02-25 17:10:00 UTC
Image Type: PowerPC Linux Kernel Image (uncompressed)
Data Size: 2990784 Bytes = 2.9 MiB
Load Address: 4000
Entry Point: 4000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2000
Booting using the fdt blob at 0x2000
Loading Kernel Image ... OK
OK
Loading Device Tree to 03ff9000, end 03fff04a ... OK

-> no more output ... frozen target 

On 2021-02-25 14:45, Joel Sherrill wrote:


Hi

Just passing along that the need to switch the BSP builder to waf is 
becoming more obvious in the BSP Builder results


https://lists.rtems.org/pipermail/build/2021-February/026054.html

467 of 1615 configurations now fail to build.

-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: About Chains in RTEMS

2021-02-25 Thread Sebastian Huber 

On 25/02/2021 10:47, Richi Dubey wrote:


Hi,

When I am debugging the call to _Chain_Append_unprotected (from line 
92 
 of 
sp02, rtems_task_delete -> _Thread_Close ->...->_Thread_Cancel -> ... 
->_Scheduler_Unblock -> ... _Scheduler_strong_APA_Insert_ready 
-> _Chain_Append_unprotected), I see a weird chain behavior where 
there's some kind of cycle:


(gdb) p _Chain_Tail(the_chain)
$20 = (Chain_Node *) 0x200768 
<_Configuration_Scheduler_strong_APA_dflt+40>

(gdb) p _Chain_Tail(the_chain)->previous
$21 = (Chain_Node *) 0x2014e8 <_RTEMS_tasks_Objects+2024>
(gdb) p (_Chain_Tail(the_chain)->previous)->previous
$22 = (Chain_Node *) 0x200fe0 <_RTEMS_tasks_Objects+736>
(gdb) p ((_Chain_Tail(the_chain)->previous)->previous)->previous
$23 = (Chain_Node *) 0x2014e8 <_RTEMS_tasks_Objects+2024>
(gdb) p 
(((_Chain_Tail(the_chain)->previous)->previous)->previous)->previous

$24 = (Chain_Node *) 0x200fe0 <_RTEMS_tasks_Objects+736>


sp02 is a single processor test and I am trying to run it on the 
Strong APA SMP scheduler. Can someone please give an insight into what 
might be causing this? The Strong APA scheduler does not affect the 
functioning of the chain, it only uses the chain using standard 
function headers defined in chain.h
Cycles in a chain may be caused by double insertions or extractions. I 
would enable RTEMS_DEBUG since it adds assertions for these cases.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: [PATCH 01/10] build: Generate build hash

2021-02-25 Thread Sebastian Huber 

On 25/02/2021 09:42, Sebastian Huber wrote:

Should we look to use a list that is contained? A list that effects 
the code on
the target? In a purest sense a hash created from the CU pieces in 
all target

libraries would be ideal however this is recursive.
This is a good idea. Maybe we should iterate over all start files and 
libraries generated by the build and then create a hash of all 
executable sections. Then we recompile one object with a command line 
define with the build hash and replace this object in librtemscpu.a.
I will drop for now the introduction of a rtems_get_build_hash() in 
favour of a rtems_get_build_label() since my waf skills are not good 
enough to do the above task.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

[PATCH 2/2] libtest: Report build label

2021-02-25 Thread Sebastian Huber 
Update #4269.
---
 cpukit/libtest/t-test.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cpukit/libtest/t-test.c b/cpukit/libtest/t-test.c
index 02f59033d4..fa7c1985ba 100644
--- a/cpukit/libtest/t-test.c
+++ b/cpukit/libtest/t-test.c
@@ -840,6 +840,7 @@ T_system(T_context *ctx)
T_do_log(ctx, T_QUIET, "S:Compiler:" __VERSION__ "\n");
T_do_log(ctx, T_QUIET, "S:Version:%s\n", rtems_version());
T_do_log(ctx, T_QUIET, "S:BSP:%s\n", rtems_board_support_package());
+   T_do_log(ctx, T_QUIET, "S:BuildLabel:%s\n", rtems_get_build_label());
 #if RTEMS_DEBUG
T_do_log(ctx, T_QUIET, "S:RTEMS_DEBUG:1\n");
 #else
-- 
2.26.2

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

[PATCH 1/2] rtems: Add rtems_get_build_label()

2021-02-25 Thread Sebastian Huber 
Update #4269.
---
 cpukit/Makefile.am  |  1 +
 cpukit/include/rtems/config.h   | 33 ++-
 cpukit/sapi/src/getbuildlabel.c | 50 +
 spec/build/cpukit/cpuopts.yml   |  2 ++
 spec/build/cpukit/librtemscpu.yml   |  1 +
 spec/build/cpukit/optbuildlabel.yml | 16 +
 6 files changed, 102 insertions(+), 1 deletion(-)
 create mode 100644 cpukit/sapi/src/getbuildlabel.c
 create mode 100644 spec/build/cpukit/optbuildlabel.yml

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index a31cd31596..143a0ee4f5 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -1062,6 +1062,7 @@ librtemscpu_a_SOURCES += sapi/src/extensiondelete.c
 librtemscpu_a_SOURCES += sapi/src/extensionident.c
 librtemscpu_a_SOURCES += sapi/src/fatal.c
 librtemscpu_a_SOURCES += sapi/src/fatalsrctext.c
+librtemscpu_a_SOURCES += sapi/src/getbuildlabel.c
 librtemscpu_a_SOURCES += sapi/src/getconfigmax.c
 librtemscpu_a_SOURCES += sapi/src/getcopyrightnotice.c
 librtemscpu_a_SOURCES += sapi/src/getversionstring.c
diff --git a/cpukit/include/rtems/config.h b/cpukit/include/rtems/config.h
index a3eec39584..2f1a7ecfa4 100644
--- a/cpukit/include/rtems/config.h
+++ b/cpukit/include/rtems/config.h
@@ -10,7 +10,7 @@
  */
 
 /*
- * Copyright (C) 2009, 2020 embedded brains GmbH 
(http://www.embedded-brains.de)
+ * Copyright (C) 2009, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -93,6 +93,37 @@ extern "C" {
  * configuration option values, for example rtems_resource_unlimited().
  */
 
+/* Generated from spec:/rtems/config/if/get-build-label */
+
+/**
+ * @ingroup RTEMSAPIConfig
+ *
+ * @brief Gets the RTEMS build label.
+ *
+ * The build label is a user-provided string defined by the build
+ * configuration.
+ *
+ * @return Returns the pointer to the RTEMS build label.
+ *
+ * @par Notes
+ * The build label can be used to distinguish test suite results obtained from
+ * different build configurations.  A use case is to record test results with
+ * performance data to track performance regressions.  For this a database of
+ * performance limits is required.  The build label and the target hash
+ * obtained from rtems_get_target_hash() can be used as a key to obtain
+ * performance limits.
+ *
+ * @par Constraints
+ * @parblock
+ * The following constraints apply to this directive:
+ *
+ * * The directive may be called from within any runtime context.
+ *
+ * * The directive will not cause the calling task to be preempted.
+ * @endparblock
+ */
+const char *rtems_get_build_label( void );
+
 /* Generated from spec:/rtems/config/if/get-copyright-notice */
 
 /**
diff --git a/cpukit/sapi/src/getbuildlabel.c b/cpukit/sapi/src/getbuildlabel.c
new file mode 100644
index 00..3e8d2a4e3b
--- /dev/null
+++ b/cpukit/sapi/src/getbuildlabel.c
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSImplClassic
+ *
+ * @brief This source file contains the implementation of
+ *   rtems_get_build_label().
+ */
+
+/*
+ * Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+const char *rtems_get_build_label( void )
+{
+#ifdef RTEMS_BUILD_LABEL
+  return RTEMS_BUILD_LABEL;
+#else
+  return "DEFAULT";
+#endif
+}
diff --git a/spec/build/cpukit/cpuopts.yml b/spec/build/cpukit/cpuopts.yml
index 4b2a818b64..e0da529c50 100644
--- a/spec/build/cpukit/cpuopts.yml
+++ b/spec/build/cpukit/cpuopts.yml
@@

[PATCH rtems-libbsd 2/2] ping6: Honor file descriptor maximum

2021-02-25 Thread Christian Mauderer 
This is basically the same as the patch for ping.
---
 freebsd/sbin/ping6/ping6.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/freebsd/sbin/ping6/ping6.c b/freebsd/sbin/ping6/ping6.c
index a56aae1dc..2d6e5adef 100644
--- a/freebsd/sbin/ping6/ping6.c
+++ b/freebsd/sbin/ping6/ping6.c
@@ -115,6 +115,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #endif /* __rtems__ */
 #include 
 #include 
@@ -1198,7 +1199,13 @@ main(int argc, char *argv[])
struct timespec now, timeout;
struct msghdr m;
struct iovec iov[2];
+#ifndef __rtems__
fd_set rfds;
+#else /* __rtems__ */
+   fd_set big_enough_rfds[howmany(rtems_libio_number_iops,
+   sizeof(fd_set) * 8)];
+#definerfds (*(fd_set *)(_enough_rfds[0]))
+#endif /* __rtems__ */
int n;
 
/* signal handling */
@@ -1211,7 +1218,11 @@ main(int argc, char *argv[])
continue;
}
 #endif
+#ifndef __rtems__
FD_ZERO();
+#else /* __rtems__ */
+   memset(big_enough_rfds, 0, sizeof(big_enough_rfds));
+#endif /* __rtems__ */
FD_SET(srecv, );
clock_gettime(CLOCK_MONOTONIC, );
timespecadd(, , );
-- 
2.26.2

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

[PATCH rtems-libbsd 1/2] racoon/session: Honor file descriptor maximum

2021-02-25 Thread Christian Mauderer 
Dynamically allocate a big enough file descriptor set for select(). A
better solution would be to use kqueue() instead of select().
---
 .../racoon/rtems-bsd-racoon-session-data.h|  6 +--
 ipsec-tools/src/racoon/session.c  | 40 +++
 2 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/ipsec-tools/src/racoon/rtems-bsd-racoon-session-data.h 
b/ipsec-tools/src/racoon/rtems-bsd-racoon-session-data.h
index b869a1518..196107a35 100644
--- a/ipsec-tools/src/racoon/rtems-bsd-racoon-session-data.h
+++ b/ipsec-tools/src/racoon/rtems-bsd-racoon-session-data.h
@@ -2,11 +2,11 @@
 #include 
 #include "rtems-bsd-racoon-data.h"
 /* session.c */
-RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static fd_set active_mask);
-RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static fd_set preset_mask);
+RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static _types_fd_set 
*allocated_active_mask);
+RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static _types_fd_set 
*allocated_preset_mask);
 RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static int nfds);
 RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static int signals[]);
 RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static sig_atomic_t volatile 
volatile sigreq[]);
-RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static struct fd_monitor 
fd_monitors[]);
+RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static struct fd_monitor 
*allocated_fd_monitors);
 RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static struct fd_monitor_list 
fd_monitor_tree[]);
 RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static struct sched scflushsa);
diff --git a/ipsec-tools/src/racoon/session.c b/ipsec-tools/src/racoon/session.c
index 65124c15e..90120c761 100644
--- a/ipsec-tools/src/racoon/session.c
+++ b/ipsec-tools/src/racoon/session.c
@@ -65,6 +65,10 @@
 #include 
 #include 
 #include 
+#ifdef __rtems__
+#include 
+#include 
+#endif /* __rtems__ */
 
 #include 
 #include 
@@ -123,8 +127,16 @@ static void check_sigreq __P((void));
 static void check_flushsa __P((void));
 static int close_sockets __P((void));
 
+#ifndef __rtems__
 static fd_set preset_mask, active_mask;
 static struct fd_monitor fd_monitors[FD_SETSIZE];
+#else /* __rtems__ */
+static fd_set *allocated_preset_mask, *allocated_active_mask;
+static struct fd_monitor *allocated_fd_monitors;
+#define preset_mask (*allocated_preset_mask)
+#define active_mask (*allocated_active_mask)
+#define fd_monitors (allocated_fd_monitors)
+#endif /* __rtems__ */
 static TAILQ_HEAD(fd_monitor_list, fd_monitor) fd_monitor_tree[NUM_PRIORITIES];
 static int nfds = 0;
 
@@ -134,7 +146,11 @@ static struct sched scflushsa = SCHED_INITIALIZER();
 void
 monitor_fd(int fd, int (*callback)(void *, int), void *ctx, int priority)
 {
+#ifndef __rtems__
if (fd < 0 || fd >= FD_SETSIZE) {
+#else /* __rtems__ */
+   if (fd < 0 || fd >= rtems_libio_number_iops) {
+#endif /* __rtems__ */
plog(LLV_ERROR, LOCATION, NULL, "fd_set overrun");
exit(1);
}
@@ -158,7 +174,11 @@ monitor_fd(int fd, int (*callback)(void *, int), void 
*ctx, int priority)
 void
 unmonitor_fd(int fd)
 {
+#ifndef __rtems__
if (fd < 0 || fd >= FD_SETSIZE) {
+#else /* __rtems__ */
+   if (fd < 0 || fd >= rtems_libio_number_iops) {
+#endif /* __rtems__ */
plog(LLV_ERROR, LOCATION, NULL, "fd_set overrun");
exit(1);
}
@@ -186,7 +206,22 @@ session(void)
struct fd_monitor *fdm;
 
nfds = 0;
+#ifndef __rtems__
FD_ZERO(_mask);
+#else /* __rtems__ */
+   allocated_preset_mask = calloc(sizeof(fd_set),
+   howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
+   if (allocated_preset_mask == NULL)
+   errx(1, "failed to allocate preset_mask");
+   allocated_active_mask = calloc(sizeof(fd_set),
+   howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
+   if (allocated_active_mask == NULL)
+   errx(1, "failed to allocate active_mask");
+   allocated_fd_monitors = calloc(
+   rtems_libio_number_iops, sizeof(struct fd_monitor));
+   if (allocated_fd_monitors == NULL)
+   errx(1, "failed to allocate fd_monitors");
+#endif /* __rtems__ */
 
for (i = 0; i < NUM_PRIORITIES; i++)
TAILQ_INIT(_monitor_tree[i]);
@@ -356,6 +391,11 @@ close_session()
flushsainfo();
close_sockets();
backupsa_clean();
+#ifdef __rtems__
+   free(allocated_preset_mask); allocated_preset_mask = NULL;
+   free(allocated_active_mask); allocated_active_mask = NULL;
+   free(allocated_fd_monitors); allocated_fd_monitors = NULL;
+#endif /* __rtems__ */
 
plog(LLV_INFO, LOCATION, NULL, "racoon process %d shutdown\n", 
getpid());
 
-- 
2.26.2

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

BSP Builder Results :(

2021-02-25 Thread Joel Sherrill 
Hi

Just passing along that the need to switch the BSP builder to waf is
becoming more obvious in the BSP Builder results

https://lists.rtems.org/pipermail/build/2021-February/026054.html

467 of 1615 configurations now fail to build.

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

[PATCH] MAINTAINERS: Add myself to write after approval

2021-02-25 Thread Jan Sommer 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 29e22357a5..6c9b70bc40 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -53,6 +53,7 @@ Christian Mauderer 
christian.maude...@embedded-brains.de
 Hesham Almataryheshamelmat...@gmail.com
 Amaan Cheval   am...@rtems.org
 Vijay Kumar Banerjee   vi...@rtems.org
+Jan Sommer j...@rtems.org
 
 Localized Write Permission
 ==
-- 
2.17.1

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

Re: [PATCH 2/2] This adds a way to print the host triplet

2021-02-25 Thread Robin Müller 
I still think it would be nice if very common tool suites like ARM could be
installed /downloaded in a pre-compiled way at least for Windows because
the  tool building process is the only thing preventing
development on Windows some(or most?) times.
xPacks is doing that (and they use CXC for the Windows toolchain too,
building it automatically for Windows on a Debian machine, see here
https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases) and
Arduino ships pre-compiled  toolchains with their software (but it's
possible to download separately as well).

Once the tool suite was available, I did not have any OS specific issues
any more.

Kind Regards
Robin

On Thu, 25 Feb 2021 at 10:44, Robin Müller 
wrote:

> I only used it to CXC the ARM toolchain (Linux -> Windows) mainly because
> I have only needed the ARM tool suite up until now (and there were issues
> building it  on Windows, but maybe that has been solved since).
> That was a few weeks ago and I have not rebuilt it since.
>
> Kind Regards
> Robin
>
> On Thu, 25 Feb 2021 at 01:30, Chris Johns  wrote:
>
>> On 25/2/21 9:21 am, Robin Müller wrote:
>> > There is no first patch (the first patch file was a SIS update, but
>> that's
>> > already inside master I think).
>> > I think I used this when I canadian cross-compiled the RTEMS ARM
>> toolchain for
>> > Windows on Linux and I was not sure what the triplet was.
>>
>> Great and thanks. Have you been using the Cxc mode recently? I have
>> stopped
>> testing it.
>>
>> Chris
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

About Chains in RTEMS

2021-02-25 Thread Richi Dubey 
Hi,

When I am debugging the call to _Chain_Append_unprotected (from line 92
 of
sp02, rtems_task_delete -> _Thread_Close ->...->_Thread_Cancel -> ...
->_Scheduler_Unblock -> ... _Scheduler_strong_APA_Insert_ready
-> _Chain_Append_unprotected), I see a weird chain behavior where there's
some kind of cycle:

(gdb) p _Chain_Tail(the_chain)
$20 = (Chain_Node *) 0x200768 <_Configuration_Scheduler_strong_APA_dflt+40>
(gdb) p _Chain_Tail(the_chain)->previous
$21 = (Chain_Node *) 0x2014e8 <_RTEMS_tasks_Objects+2024>
(gdb) p (_Chain_Tail(the_chain)->previous)->previous
$22 = (Chain_Node *) 0x200fe0 <_RTEMS_tasks_Objects+736>
(gdb) p ((_Chain_Tail(the_chain)->previous)->previous)->previous
$23 = (Chain_Node *) 0x2014e8 <_RTEMS_tasks_Objects+2024>
(gdb) p
(((_Chain_Tail(the_chain)->previous)->previous)->previous)->previous
$24 = (Chain_Node *) 0x200fe0 <_RTEMS_tasks_Objects+736>


sp02 is a single processor test and I am trying to run it on the Strong APA
SMP scheduler. Can someone please give an insight into what might be
causing this? The Strong APA scheduler does not affect the functioning of
the chain, it only uses the chain using standard function headers defined
in chain.h

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

Re: [PATCH 2/2] This adds a way to print the host triplet

2021-02-25 Thread Robin Müller 
I only used it to CXC the ARM toolchain (Linux -> Windows) mainly because I
have only needed the ARM tool suite up until now (and there were issues
building it  on Windows, but maybe that has been solved since).
That was a few weeks ago and I have not rebuilt it since.

Kind Regards
Robin

On Thu, 25 Feb 2021 at 01:30, Chris Johns  wrote:

> On 25/2/21 9:21 am, Robin Müller wrote:
> > There is no first patch (the first patch file was a SIS update, but
> that's
> > already inside master I think).
> > I think I used this when I canadian cross-compiled the RTEMS ARM
> toolchain for
> > Windows on Linux and I was not sure what the triplet was.
>
> Great and thanks. Have you been using the Cxc mode recently? I have stopped
> testing it.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 01/10] build: Generate build hash

2021-02-25 Thread Sebastian Huber 

On 25/02/2021 05:13, Chris Johns wrote:


On 25/2/21 12:57 am, Sebastian Huber wrote:

Update #4265.
---
  wscript | 27 ++-
  1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/wscript b/wscript
index 6626fafb74..83c7c446bb 100755
--- a/wscript
+++ b/wscript
@@ -1359,6 +1359,30 @@ def get_compiler(conf, cp, variant):
  return value
  
  
+def _generate_build_hash(conf):

+import hashlib
+import base64
+
+build_hash = ""
+for key in sorted(conf.env):
+build_hash = build_hash + key + str(conf.env[key])

I am pleased to see the environment is being addressed but on some modern
operating systems the environment has become a bit of a beast. This means
comparable values will be near impossible if the whole environment is included
in the build hash.

Should we look to use a list that is contained? A list that effects the code on
the target? In a purest sense a hash created from the CU pieces in all target
libraries would be ideal however this is recursive.
This is a good idea. Maybe we should iterate over all start files and 
libraries generated by the build and then create a hash of all 
executable sections. Then we recompile one object with a command line 
define with the build hash and replace this object in librtemscpu.a.


Any chance of a build label set in the config.ini? :)
You want something like a rtems_get_build_label() which returns the 
value of RTEMS_BUILD_LABEL set in a config.ini (or a default, e.g. 
"arch/bsp")?



+for discard in [
+conf.env.PREFIX,
+conf.bldnode.make_node(conf.env.VARIANT).abspath(),
+conf.path.abspath(),
+]:
+build_hash = build_hash.replace(discard, "")

I do not follow this piece of logic.

It removes prefix, source and build paths.



+state = hashlib.sha256()
+state.update(build_hash.encode("utf-8"))

Why the `utf-8` encode and then decode later?
The hash update needs a byte stream not a string. The define needs a 
string and not a byte stream.



+conf.define(
+"RTEMS_BUILD_HASH",
+base64.urlsafe_b64encode(state.digest()).decode("utf-8"),

Thank you for base64 encoding the result.

Chris


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: About Thread_Cancel

2021-02-25 Thread Richi Dubey 
Hi,

Thanks for the help.

What is the contradiction? You shouldn't have a blocked thread in a
> queue when you want to delete it. The thread needs to be in some kind
> of "quiescent" state.

Okay, I'll look further into this.

On Wed, Feb 24, 2021 at 10:19 PM Gedare Bloom  wrote:

> On Wed, Feb 24, 2021 at 12:54 AM Richi Dubey  wrote:
> >
> > Hi,
> >
> > Can someone please give a brief overview of what these three lines aim
> to achieve:
> >
> >   } else if ( _Thread_Is_life_change_allowed( previous ) ) {
> > _Thread_Add_life_change_request( the_thread );
> > _Thread_State_release( the_thread, _context );
> >
> > _Thread_Finalize_life_change( the_thread, priority );
> >
> > 492 threadrestart.c
> >
> > I am asking because in line 92 of sp02, this _Thread_Cancel function is
> called, and because of _Thread_Add_life_change_request( the_thread )
> ->_Thread_Set_state_locked -> _Scheduler_Block is called and because of
> _Thread_Finalize_life_change->_Thread_Remove_life_change_request->_Thread_Clear_state_locked->_Scheduler_Unblock
> is called, which is contradictory.
> >
> What is the contradiction? You shouldn't have a blocked thread in a
> queue when you want to delete it. The thread needs to be in some kind
> of "quiescent" state.
>
> Thread cancellation and end-of-life considerations are tricky. Maybe
> your scheduler has some invalid assumptions about how threads
> terminate?
>
> The API-level requirements derive from two directions:
>
> https://docs.rtems.org/branches/master/c-user/scheduling-concepts/background.html#task-state-transitions
>
> https://docs.rtems.org/branches/master/posix-users/thread_cancellation.html
>
> The low-level detailed implementation is probably not so
> well-documented. You might be able to find some clues in the doxygen.
> Otherwise you probably have to keep working your way through the code
> like you have been.
>
> > Thanks,
> > Richi.
> > ___
> > 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: About Thread_Cancel

2021-02-25 Thread Richi Dubey 
Hi Sebastian,

Thank you for the help. I will look further into this.

Best Regards,
Richi.

On Wed, Feb 24, 2021 at 10:37 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Richi,
>
> the reason for the reference counted life change request and this
> sequence of block/unblock is that you have to be careful with the lock
> ordering in SMP configurations. _Thread_Add_life_change_request() is
> called under protection of the thread state lock. The
> _Thread_Finalize_life_change() is called without owning this lock.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel