[PATCH] build: Fix dependencies for start and asm files

Add explicit asm target feature. Add a build start file node list and use it as a test program dependency. Close #3846. Close #4080. --- wscript | 41 - 1 file changed, 36 insertions(+), 5 deletions(-) diff --git a/wscript b/wscript index

Re: [PATCH v1 2/6] waf: Add path-mappings feature

On 16/9/20 8:06 pm, jan.som...@dlr.de wrote: > Hi Chris, > >> -Original Message- >> From: Chris Johns >> Sent: Thursday, September 10, 2020 6:44 AM >> To: Sommer, Jan ; devel@rtems.org >> Subject: Re: [PATCH v1 2/6] waf: Add path-mappings feature >> >> On 15/8/20 5:57 am, Jan Sommer

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

On 17/9/20 9:50 am, Joel Sherrill wrote: > On Wed, Sep 16, 2020, 6:43 PM Chris Johns > wrote: > > On 16/9/20 11:42 pm, Joel Sherrill wrote: > > snprintf() is a safe method and I strongly disagree with the blanket > replacement > > of many safe methods

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

On Wed, Sep 16, 2020, 6:43 PM Chris Johns wrote: > On 16/9/20 11:42 pm, Joel Sherrill wrote: > > snprintf() is a safe method and I strongly disagree with the blanket > replacement > > of many safe methods with memcpy(). > > > > Based on what POSIX profiles snprintf() is included in and the

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

On 16/9/20 11:42 pm, Joel Sherrill wrote: > snprintf() is a safe method and I strongly disagree with the blanket > replacement > of many safe methods with memcpy(). > > Based on what POSIX profiles snprintf() is included in and the safety and > security requirements those profiles are designed

Re: [PATCH v5 0/7] Add rtems_task_construct()

Looks good. Thanks for your patience as we worked through this change. I think the outcome is solid and reflects the efforts made. Chris On 17/9/20 12:49 am, Sebastian Huber wrote: > v2: > > Rename function from rtems_task_build() to > rtems_task_create_from_config(). Add

Re: RTEMS BSP Builder and New/Old Build System

On 17/9/20 8:12 am, Joel Sherrill wrote: > Just noting that it would be nice to have a transition period where RTEMS BSP > Builder supported both build systems for comparison purposes. I prefer this be as short as possible. What about 1st Nov 2020? It is not clear what the criteria is to trigger

RTEMS BSP Builder and New/Old Build System

Hi Just noting that it would be nice to have a transition period where RTEMS BSP Builder supported both build systems for comparison purposes. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

[RTEMS-libBSD OFW v1] dev/ofw: Use RTEMS OFW FDT implementation

This commit modifies the OFW interface to the RTEMS FDT implementation instead of the default FreeBSD. --- freebsd/sys/dev/ofw/openfirm.c| 2 ++ freebsd/sys/dev/ofw/openfirm.h| 9 .../machine/rtems-bsd-kernel-namespace.h | 22 --- 3

Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

Hello, Sorry for the delay, I was a bit occupied with my university work. Now since the new build system is merged I would like to get my GSoC work merged too. The goal of this series patches is to implement the OFW API into RTEMS and modify libBSD to use this RTEMS API instead of its own.

[PATCH v1 2/2] libtests/ofw01: Added a test for RTEMS OFW

This commit adds a basic test that tests all the implemented RTEMS OFW functions. --- spec/build/testsuites/libtests/grp.yml | 2 + spec/build/testsuites/libtests/ofw01.yml | 21 +++ testsuites/libtests/ofw01/init.c | 187 +++ testsuites/libtests/ofw01/ofw01.doc

[PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

RTEMS OFW is a FDT only implementation of the OpenFirmWare interface. This API is created to be compatible with FreeBSD OpenFirmWare interface. The main intention is to make porting of FreeBSD drivers to RTEMS easier. Most functions implemented have an direct one-one mapping with the original OFW

Re: Strong APA scheduler testing

Hi, Sorry for the delay. My university tests were going on. So, I reran the test only for smptestsuites, and I have attached the log. The test says that smpfatal09 gives timeout, where when I ran the test with qemu, I get the following output:

Re: devel Digest, Vol 106, Issue 81

On Mon, Sep 14, 2020 at 5:30 PM wrote: > Send devel mailing list submissions to > devel@rtems.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.rtems.org/mailman/listinfo/devel > or, via email, send a message with subject or body 'help' to >

[PATCH v5 0/7] Add rtems_task_construct()

v2: Rename function from rtems_task_build() to rtems_task_create_from_config(). Add RTEMS_TASK_STORAGE_ALIGNMENT and RTEMS_TASK_STORAGE_SIZE(). Improve documentation. v3: Add CONFIGURE_TASKS_CREATED_FROM_CONFIG. Fix RTEMS_TASK_STORAGE_SIZE() if CPU_ALL_TASKS_ARE_FP == TRUE. v4: Add

[PATCH v5 3/7] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

Add this application configuration option. This configuration option can be used to reserve space for the dynamic linking of modules with thread-local storage objects. Add RTEMS_TASK_STORAGE_ALIGNMENT to define the minium alignment of a thread-local storage size. Update #4074. ---

[PATCH v5 2/7] rtems: Add RTEMS_ALIGN_UP()

Update #3959. Update #4074. --- cpukit/include/rtems/score/basedefs.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/cpukit/include/rtems/score/basedefs.h b/cpukit/include/rtems/score/basedefs.h index 4d16c88b49..c31b4ebef7 100644 --- a/cpukit/include/rtems/score/basedefs.h

[PATCH v5 4/7] rtems: Add rtems_task_construct()

In contrast to rtems_task_create() this function constructs a task with a user-provided task storage area. The new directive uses a configuration structure instead of individual parameters. Add RTEMS_TASK_STORAGE_SIZE() to calculate the recommended size of a task storage area based on the task

[PATCH v5 1/7] rtems: Add RTEMS_ALIGN_DOWN()

Update #3959. Update #4074. --- cpukit/include/rtems/score/basedefs.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/cpukit/include/rtems/score/basedefs.h b/cpukit/include/rtems/score/basedefs.h index 5a7e4e4f31..4d16c88b49 100644 --- a/cpukit/include/rtems/score/basedefs.h

[PATCH v5 7/7] validation: rtems_task_construct() errors

This is the first test case generated from a specification item in the rtems-central repository. Update #3959. --- .../testsuites/validation/validation-0.yml|1 + .../validation/tc-task-construct-errors.c | 2367 + 2 files changed, 2368 insertions(+) create mode

[PATCH v5 5/7] doxygen: Move top-level group definitions

Update #3959. --- cpukit/doxygen.h | 18 - cpukit/doxygen/top-level-groups.h | 44 +++ 2 files changed, 44 insertions(+), 18 deletions(-) create mode 100644 cpukit/doxygen/top-level-groups.h diff --git a/cpukit/doxygen.h

[PATCH v5 6/7] validation: Add general purpose test suite

Add a general purpose test suite for validation tests. This is the first test suite generated from a specification item in the rtems-central repository. Update #3959. --- Doxyfile | 2 +- cpukit/doxygen/top-level-groups.h | 6 +

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

snprintf() is a safe method and I strongly disagree with the blanket replacement of many safe methods with memcpy(). Based on what POSIX profiles snprintf() is included in and the safety and security requirements those profiles are designed to meet, snprintf() is supported by RTOSes that can meet

RE: legacy stack or libbsd

>On 5/8/20 2:13 pm, Gedare Bloom wrote: >> On Tue, Aug 4, 2020 at 6:41 PM Chris Johns wrote: > >>> On 5/8/20 10:23 am, Chris Johns wrote: On 5/8/20 2:04 am, Heinz Junkes wrote: > Because the libbsd stack does not support some things yet (e.g. ntp) > I have PTP running on libbsd. I

RE: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes smpfatal08 link

> -Original Message- > From: Sebastian Huber > Sent: Wednesday, September 16, 2020 12:30 PM > To: Sommer, Jan ; devel@rtems.org > Subject: Re: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes > smpfatal08 link > > On 16/09/2020 12:06, jan.som...@dlr.de wrote: > > > Is

Re: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes smpfatal08 link

On 16/09/2020 12:06, jan.som...@dlr.de wrote: Is there an easy way to only send the updated patch to the mailinglist or should I send in the full patch set with v2? It seems the patch set is already included in the RTEMS master. ___ devel mailing

RE: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes smpfatal08 link

Hi Sebastian, Sure. Is there an easy way to only send the updated patch to the mailinglist or should I send in the full patch set with v2? Cheers, Jan > -Original Message- > From: Sebastian Huber > Sent: Tuesday, September 15, 2020 6:38 AM > To: Sommer, Jan ; devel@rtems.org >

RE: [PATCH v1 2/6] waf: Add path-mappings feature

Hi Chris, > -Original Message- > From: Chris Johns > Sent: Thursday, September 10, 2020 6:44 AM > To: Sommer, Jan ; devel@rtems.org > Subject: Re: [PATCH v1 2/6] waf: Add path-mappings feature > > On 15/8/20 5:57 am, Jan Sommer wrote: > > - path-mappings allow to fix autogenerated

Re: New build system ready for testing

On 16/9/20 4:45 pm, Karel Gardas wrote: > Looks great, but on submit attempt I've been welcome by "Akismet says > content is spam" and I guess I solved math exercise well... I am sorry, I have no idea why that would happen. Chris ___ devel mailing list

Re: New build system ready for testing

On 9/16/20 3:16 AM, Chris Johns wrote: > On 15/9/20 5:36 pm, Sebastian Huber wrote: >> On 15/09/2020 09:32, Karel Gardas wrote: >> >>> On 9/15/20 9:28 AM, Sebastian Huber wrote: Maybe it is more practical if we add a table to a wiki page in which everyone can add the BSPs which were

Re: [rtems commit] build: Add RELOCADDR to i386/pc386 options

On 16/09/2020 01:26, Chris Johns wrote: +default: 1048576 Is hex supported? 0x10 is much friendlier and simpler to grep for. It would be difficult to add support for this. The YAML parser can read hex number, however, the default YAML formatter writes all integers as decimals. If you