Re: About Thread_Cancel

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

Re: About Thread_Cancel

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

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

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

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

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,

About Chains in RTEMS

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

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

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 Wi

[PATCH] MAINTAINERS: Add myself to write after approval

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

BSP Builder Results :(

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 ma

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

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

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

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(+),

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

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

[PATCH 2/2] libtest: Report build label

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_

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

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 ite

Re: About Chains in RTEMS

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

Re: BSP Builder Results :(

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/

Re: BSP Builder Results :(

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

Re: Standalone repository for libnetworking stack

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 suggestion

[PATCH] score: Fix thread initialization

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 +- cpuk

Re: BSP Builder Results :(

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-

Re: BSP Builder Results :(

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

Re: BSP Builder Results :(

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

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

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

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

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 howev

Re: Standalone repository for libnetworking stack

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 vers

Re: About Chains in RTEMS

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

Re: Standalone repository for libnetworking stack

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