RTEMS / RTOS / RTEMS¶
Go to Issues or Merge Requests
Issues Summary
Merge Requests Summary
Issues¶
5494 - Move README to README.md for the 5 branch¶
Id |
5494 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Closed by |
Kinsey Moore |
Created |
2026-02-20T00:13:52.412Z |
Closed |
2026-02-20T00:32:08.851Z |
Updated |
2026-02-20T00:32:09.063Z |
Milestone |
5.4 |
Labels |
release |
Link |
|
Merges |
0 |
Move README to README.md on the 5 branch so the release scripts do not need to manage both file formats.
Author: Chris Johns
2026-02-20T00:13:52.562Z
added rtems#14 as parent epic
Author: Chris Johns
2026-02-20T00:13:52.659Z
set status to To do
Author: Kinsey Moore
2026-02-20T00:30:04.896Z
mentioned in merge request !1068
Author: Kinsey Moore
2026-02-20T00:32:08.915Z
set status to Done
5219 - Backport 5.4: grlib/occan: Fix baud rate calculation¶
Id |
5219 |
State |
closed |
Type |
ISSUE |
Author |
Jan Sommer |
Assignee(s) |
Gedare Bloom |
Closed by |
Kinsey Moore |
Created |
2025-02-20T10:22:45.231Z |
Closed |
2025-02-20T22:37:30.951Z |
Updated |
2025-09-19T00:38:39.209Z |
Milestone |
5.4 |
Labels |
backport, grlib |
Link |
|
Merges |
0 |
Summary¶
Backport of https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5166.
We have a GR712RC and use the _occan_ lib for the operation of the CAN core, but had weird results regarding the measured baud rate when calling occanlib_set_speed. We used the current RCC from Gaisler and the rtems-occan example for testing.
There are 2 errors in the code:
BRP not correctly calculated¶
In the data sheet of the GR712RC it states:
!`grafik </-/project/26/uploads/d47f1150b72c68868a5c6ad9caff39e0/grafik.png>`_
/* calculate scaler */
tmp = ((br->divfactor + tseg) * baud);
sc = (core_hz * 2)/ tmp - core_hz / tmp;
Which is the same as sc = core_hz/ tmp, so the division by 2 of the core is not correctly calculated.
BTR1 register values not correct¶
From the GR712RC manual the following formulas are given for the TSEG values of the BTR1 register:
!`grafik </-/project/26/uploads/b3ac335f090f39ab51e8d4194bdfe111/grafik.png>`_
However, occanlib_set_speed eventually calls grlib_canbtrs_calc_timing which returns the full TSEG values (including the +1). The subsequent call to convert_timing_to_btrs writes these values to the registers without subtracting the +1, resulting in two time segments to many.
Steps to reproduce¶
Call
occanlib_set_speed(for example use rtems-occan of the RCC as a base).Observe the written register values in GRMON
Measure baud rate on oscilloscope and compare with desired value
Expected behaviour¶
Correct baud rate measured.
Pre-set options¶
Author: Jan Sommer
2025-02-20T10:24:29.351Z
mentioned in merge request !428
Author: Gedare Bloom
2025-02-20T21:39:52.060Z
Author: Gedare Bloom
2025-02-20T21:42:16.607Z
assigned to @gedare
Author: Kinsey Moore
2025-02-20T22:37:30.621Z
The backport MR has been merged.
5220 - Backport 5.4: Termios: cannot set all baud rates with rtems_termios_set_best_baud()¶
Id |
5220 |
State |
closed |
Type |
ISSUE |
Author |
Jan Sommer |
Assignee(s) |
Gedare Bloom |
Closed by |
Kinsey Moore |
Created |
2025-02-20T10:29:40.149Z |
Closed |
2025-02-20T22:37:38.322Z |
Updated |
2025-02-20T22:37:38.336Z |
Milestone |
5.4 |
Labels |
backport, cpukit |
Link |
|
Merges |
0 |
Summary¶
Backport of https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5162
rtems_termios_set_best_baud() cannot set all Baudrates, because rtems_termios_baud_table is unsorted.
Steps to reproduce¶
https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/cpukit/libcsupport/src/termios_baudtable.c?ref_type=heads https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/cpukit/libcsupport/src/termios_setbestbaud.c?ref_type=heads#L43
The algorithm in rtems_termios_set_best_baud() successively iterates over the elements of the rtems_termios_baud_table and searches for a fitting baud rate (checking by “is element lower than the baud parameter, then checks the next element, …).
The table of baud rates is not sorted correctly from a certain point on, therefore the algorithm for choosing the optimal baud rate does not work for every baud rate.
e.g. if the input is 7200 (which is in the table) the search terminates at 9600 as that is larger, the last entry was 4800, so in the check it sets it to either of those, but not the 7200.
We observed it when we entered 38401 (due to measurement errors on the hardware was a bit larger).
We identified the search ending at 57600 and it ended using the last = 28800.
Pre-set options¶
Author: Jan Sommer
2025-02-20T10:30:38.168Z
mentioned in merge request !429
Author: Jan Sommer
2025-02-20T12:07:11.315Z
changed title from Backport 5.4: to Backport 5.4:{+ Termios: cannot set all baud rates with ``rtems_termios_set_best_baud()``+}
Author: Gedare Bloom
2025-02-20T21:43:47.285Z
assigned to @gedare
Author: Gedare Bloom
2025-02-20T21:43:51.167Z
Author: Kinsey Moore
2025-02-20T22:37:38.045Z
The backport MR has been merged.
3791 - POSIX Message Queue thread release order is not priority based (opened)¶
Id |
3791 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2019-08-29T16:44:48.000Z |
Updated |
2026-02-20T19:10:56.555Z |
Milestone |
5.4 |
Labels |
api::posix, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: Lou.Woods
Currently the POSIX Message Queue implementation will release threads blocked on all waiting calls in FIFO order. This is counter to the Open Group specification.
mq_receive() Description Paragraph 4: If more than one thread is waiting to receive a message when a message arrives at an empty queue and the Priority Scheduling option is supported, then the thread of highest priority that has been waiting the longest shall be selected to receive the message.
Source: http://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_receive.html
Behavior tested on RTEMS 5 master xilinx_zynq_a9_qemu BSP
Tests demonstrating the behavior and a fix will be sent to the devel mailing list.
Author: Amar Takhar
2024-04-25T20:47:24.688Z
mentioned in issue #3782
Author: Chris Johns
2025-09-19T01:45:42.764Z
changed the description
Author: Gedare Bloom
2026-01-22T21:02:55.584Z
marked this issue as blocking rtems/programs/gsoc#88
Author: Xinhong Hu
2026-02-14T18:08:53.538Z
Hi @gedare @joel
I’m interested in working on this issue as a part of GSoC. I’ve been doing some debugging on RTEMS 7 (erc32-sim) and can confirm the problem still exists. Here’s what I’ve done:
Initial observation:
In _``cpukit/posix/src/mqueueopen.c``_ I change _``CORE_MESSAGE_QUEUE_DISCIPLINES_FIFO``_ to _’CORE_MESSAGE_QUEUE_DISCIPLINES_PRIORITY’_, but the behavior remained FIFO – a low-priority thread (20) blocked first, a high-priority thread (10) blocked second, and when a message was sent, the low-priority thread received it. My test code is below:
posix_mq_priority_wakeup_test.c
Verification:
I added runtime prints in ``coremsgsubmit.c`` to confirm that the message queue operations are indeed set to priority versions:
ops.enqueue = 0x2008f5c (priority_enqueue)ops.extract = 0x2008a9c (priority_extract)
Deep debugging with GDB:
I used ``sparc-rtems7-gdb`` to set breakpoints in ``_Thread_queue_Enqueue`` and ``_Thread_queue_Extract_locked``, printing thread priority via ``the_thread->Real_priority.priority``. The output was:
[Enqueue] thread addr: 0x02018408, priority: 490 (low-priority thread) [Enqueue] thread addr: 0x02018c78, priority: 200 (high-priority thread) … [Dequeue] thread addr: 0x02018408, priority: 490
This shows:
Enqueue order: low-priority first, high-priority second.
Dequeue order: the first-enqueued (low-priority) thread is extracted → FIFO behavior, despite priority operations being used.
Conclusion:
The priority enqueue function (likely ``_Thread_queue_Enqueue_priority`` or a macro expansion) is not inserting threads in priority order; it’s simply appending to the tail.
My question:
I’ve looked for the implementation of the priority enqueue function but couldn’t locate it. It might be hidden in macros or in ``threadqops.c``. Could you point me to the exact file/function that needs to be fixed? I’d like to contribute a patch and use this as part of my GSoC proposal (project #88).
Thank you for your guidance!
Author: Gedare Bloom
2026-02-14T18:08:53.498Z
Please discuss GSoC projects in the User’s Forum.
The prioritization for POSIX message queues is done when the message is sent, so trace through
mq_sendcode path. This uses the message’s priority however, and not the thread’s priority.
Author: Xinhong Hu
2026-02-17T13:22:29.581Z
Hi @gedare,
Thank you for your guidance and for pointing me to the User’s Forum for GSoC discussions. I have moved the discussion there as requested. For full details, including the corrected test code and output, I have posted a comprehensive report in the User’s Forum: GSoC 2026 : POSIX Message Queue thread release order is not priority based (#3791)
Following your suggestion, I traced the
mq_sendpath and revisited my test logic. I realized my initial misunderstanding of the POSIX-to-RTEMS priority mapping led to a flawed test setup. After correcting the test to ensure the lower RTEMS priority thread (mapped from POSIX 10) blocks first and the higher RTEMS priority thread (mapped from POSIX 20) blocks second, the message queue does wake the correct higher-priority thread. The only necessary change to guarantee POSIX compliance is setting the discipline toCORE_MESSAGE_QUEUE_DISCIPLINES_PRIORITYin_POSIX_Message_queue_Create()withinmqueueopen.c, which I confirmed in my latest tests on RTEMS 7.Thank you again for your help. Any further feedback would be greatly appreciated.
Author: Joel Sherrill
2026-02-17T21:46:57.537Z
I am glad you ran that down to the one place during initialization. The POSIX standard does not say much about thread priority and message queues. mq_receive has a little information referencing the “Priority Scheduling option.” Searching the PDF of POSIX Issue 8, that phrase only occurs in _mq_send()_ and _mq_receive()_ I think there is some terminology mixup. There is a section Priority Scheduling (2.8.4) in the background and __POSIX_PRIORITY_SCHEDULING_ is documented as an option.
Ignoring all that, I think your change is the right way to do what POSIX asks. But it locks RTEMS into having all POSIX MQs have priority blocking which is a behavior change from previous RTEMS versions. Having control over blocking discipline on a per instance basis would be better. mq_setattr() doesn’t let you change message size or maximum on the fly – it has to be set at _mq_create()_ and this would be a similar attribute.
After all this writing, the simple change would be to add a field to _mq_attr_ for FIFO or priority blocking. Something like _mq_ispriority_ and the default would be FIFO and that would be a 0 value.
static const struct mq_attr _POSIX_Message_queue_Default_attributes = { .mq_maxmsg = 10, .mq_msgsize = 16 };That structure should initialize every field. :(
A grander idea which builds on adding discipline choice is having an application configuration option as found in _<rtems/confdefs.h>_ which generates the default POSIX MQ attributes. This would replace this from from _mqopen.c_. This structure already has more fields than shown and could have another to specify if an MQ instance being created with _mq_open()_ is FIFO or priority blocking. The current default attributes structure is defined in _mqueue.h_ in the RTEMS source.
This sounds like a lot but just adding something like _mq_ispriority_ to _mq_attr_ is enough to give a lot more flexibility and make priority blocking an option to applications which want it on a per MQ instance basis.
I likely have written more English than code is required. And the grander idea may not be worth the trouble. @gedare thoughts?
Author: Gedare Bloom
2026-02-17T21:54:48.602Z
The distinction between the priority-based message delivery and priority-based thread receive is subtle. I think we just have to be a little bit careful and avoid causing confusion. We certainly don’t want to break our existing practice. This would lead me to think that we want to make an application configuration to enable
mq_receivewith thread priority. I actually am unsure what the current behavior does. My intuition would be that themq_receiveis going to unblock the highest priority thread, not the FIFO thread, because the core implementation relies on the thread queues.
Author: Xinhong Hu
2026-02-20T18:49:18.416Z
Hi @joel , @gedare
Thank you for the thoughtful discussion. I’ve been prototyping the per-instance approach Joel suggested: adding an RTEMS-specific field
mq_ispriorityto structmq_attr. This allows each queue to independently choose FIFO or priority wake-up order, with a default of FIFO to maintain backward compatibility. My tests on RTEMS 7 confirm that settingmq_ispriority = 1correctly wakes a higher-priority thread that blocks later.Regarding Gedare’s point about application configuration: I think per-instance control already gives applications the ability to configure individual queues. However, to also support system-wide defaults, we could add a configuration macro in
<rtems/confdefs.h>(e.g.,CONFIGURE_POSIX_MESSAGE_QUEUE_DEFAULT_DISCIPLINE) that sets the initial value ofmq_ispriorityfor queues created with a NULL attribute. This would allow integrators to change the global default without modifying eachmq_opencall, while still permitting per-queue overrides.For my GSoC project, I propose to implement both the per-instance field and the global configuration option. The core deliverables would be:
Extend struct
mq_attrwithmq_ispriority(guarded by#ifdef __RTEMS__).Modify
mq_open()to interpret this field and pass the discipline to the core message queue.Add a configuration macro in
<rtems/confdefs.h>to set the default discipline.Provide comprehensive tests and documentation.
I believe this scope is manageable within the GSoC timeframe and fully resolves #3791 while offering flexibility for future needs. I’d appreciate your feedback on whether this plan aligns with your expectations. If you prefer a simpler approach (only per-instance or only global), I can adjust accordingly.
Thank you for your guidance!
Author: Gedare Bloom
2026-02-18T16:53:41.242Z
What do other operating systems do?
Author: Xinhong Hu
2026-02-18T16:53:41.156Z
Hi @gedare ,
Thank you for your guidance. I’ve investigated how FreeBSD and Linux implement POSIX message queues regarding thread wake‑up order, and here’s what I found:
**FreeBSD：**
FreeBSD explicitly follows the POSIX specification. Its
mq_receiveman page states:“If more than one thread is waiting to receive a message when a message arrives at an empty queue and the Priority Scheduling option is supported, then the thread of highest priority that has been waiting the longest will be selected to receive the message.” (Source: FreeBSD 16.0-CURRENT man page)
Internally, FreeBSD does not maintain an explicit waiting thread queue; instead, it uses a simple counter (
mq_receivers) and relies on the kernel scheduler to select the appropriate thread when a message arrives. This design naturally yields the POSIX-mandated behavior.Linux:
Linux|md_0_8217|s implementation is more complex and does not fully comply with the POSIX requirement.
The waiting queue (
struct ext_wait_queue) is a linked list, but threads are inserted in priority order (higher priority first). The insertion code (wq_addinipc/mqueue.c) traverses the list and places a new thread before the first thread with lower or equal priority.As a result, the list is sorted by descending priority, so when a message arrives, the highest-priority thread (the first in the list) is woken.
However, within the same priority level, the insertion order is LIFO (later waiters are placed ahead of earlier ones), so it does not guarantee that the longest-waiting thread is chosen.
This suggests that both FreeBSD and Linux prioritize threads by priority (Linux even within same priority uses LIFO rather than FIFO), aligning with the POSIX requirement to wake the highest priority thread. Linux’s LIFO behavior for equal priorities may be a performance optimization but deviates from “longest waiting” part.
Given these examples, I think RTEMS’s current FIFO behavior for waiting threads is a deviation, and our proposal to add a priority-based discipline (either globally or per‑queue via ``mq_attr``) would bring us closer to what other systems implement and what POSIX intends.
I’d appreciate any further thoughts on this.
Author: Joel Sherrill
2026-02-20T19:10:56.521Z
Your survey looks good. I would say Linux is not compliant since it is using LIFO. And unfortunately, POSIX gives us the “if you support the __POSIX_PRIORITY_SCHEDULING_ option” then the blocking discipline for all message queues changes. This is a system implementation decision so there really is not portability. You cannot control what behavior your application is going to get.
I think as a minimum, RTEMS should support a configuration option to toggle between FIFO and priority. If we don’t do that much, then existing applications will have a change in behavior that will break backwards compatibility.
Adding a field to _mq_attr_ gives the user fine gained control on each message queue instance.
I think adding an _mq_is_priority_ to out _mq_attr_ structure is a good move. And giving the user a way to define their own default _mq_attr_ instance allows them change each entry in the default structure. It would let them also override maximum message size and maximum pending messages. It would take adding to confdefs.h a macro default for each field in the structure and another to turn on using them. The current default attributes could be a weak symbol that is overridden.
I think this solution may also be needed for POSIX semaphores. They have the same language for the __POSIX_PRIORITY_SCHEDULING_ option
3824 - SMP for Ultrascale+ in ARMv7/AArch32 mode via JTAG (opened)¶
Id |
3824 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2019-11-20T21:41:30.000Z |
Updated |
2026-02-07T16:16:44.338Z |
Milestone |
5.4 |
Labels |
arch:arm, old-indefinite, priority::normal, tickettype::defect, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: maxp60
Hi, i have successfully kicked the second APU on ultrascale+ ZCU102, but both processors are looping inside the function Per_CPU_State_wait for_non_initial_state(). I think something is missing in the configuration/initialization. has the SMP code been tested in A53 running Aarch32 state (i.e. the Zynq U+ from xilinx) ?
Author: Trac Migrate
2019-11-22T15:02:37.000Z
Original author: maxp60
In case both processors loop in this function, then this is probably a problem with the cache, MMU, or memory controller setup. Which state to the processor see and which state do they expect?
Author: Trac Migrate
2019-11-22T21:39:24.000Z
Original author: maxp60
I must include some other infos. The system is initialized through the debugger (JTAG mode) , APU0 load the fsbl@aarch32, load the programmable logic and then is breaked @ fsbl_loop(). Then the debugger stores the following instruction into OCM: (AR# 46911) 0xFFFFFF00: mvn r0, #15 0xFFFFFF04: mov r1 0xFFFFFF08: str r1, [r0] 0xFFFFFF0C: wfe 0xFFFFFF10: ldr r2, [r0] 0xFFFFFF14: cmp r2, r1 0xFFFFFF18: beq 0xc 0xFFFFFF1C: mov pc
then the debugger loads the smp examples to ram, and start both the processor. APU0 start the second processor and wait inside the function Per_CPU_State_wait for_non_initial_state(). APU1 start executing the _start normally and the stalls into the function Per_CPU_State_wait for_non_initial_state(). i can upload the lauterbach trace if necessary -M
Author: Trac Migrate
2019-11-23T09:18:52.000Z
Original author: maxp60
By the way it is not clear how the two APUs signals its ready to run…
Author: Trac Migrate
2019-11-25T06:35:22.000Z
Original author: maxp60
The higher level SMP start assumes that the mutable data is cache-coherent. For the CPU states see:
https://git.rtems.org/rtems/tree/cpukit/include/rtems/score/percpu.h#n96
Author: Trac Migrate
2019-12-12T19:23:46.000Z
Original author: maxp60
What variable/register is shared and in what source file cache snooping is enabled. any other idea?
Author: Trac Migrate
2019-12-13T06:01:52.000Z
Original author: maxp60
Sorry, I am currently busy with other things and I soon go on holidays.
Author: Trac Migrate
2019-12-13T06:02:57.000Z
Original author: maxp60
Milestone set to %”Indefinite”
Version set to ~”5”
Author: Trac Migrate
2019-12-15T17:40:17.000Z
Original author: maxp60
It appears that bsp_start_clear_bss() execution of APU1 clears the _Per_CPU_Information of both processors. disabling - but only for testing purpose - _bsp_start_clear_bss() doesn’t solve the issue. Is there something missing of SMP in general? thanks
Author: Trac Migrate
2020-04-20T16:35:33.000Z
Original author: maxp60
Nobody is working in smp?
Author: Trac Migrate
2020-04-20T18:23:00.000Z
Original author: maxp60
Sorry, I don’t have time to fix this very specific issue in my spare time.
https://docs.rtems.org/branches/master/user/support/bugs.html#nobody-fixes-my-bug
Author: Amar Takhar
2025-09-05T02:57:40.815Z
changed the description
Author: Kinsey Moore
2026-02-07T16:15:13.239Z
changed title from
SMP for Ultrascale
to
SMP for Ultrascale+
in ARMv7/AArch32 mode via JTAG
Author: Kinsey Moore
2026-02-07T16:16:44.310Z
I would recommend moving to the AArch64 BSP for this hardware. If you need to run with the existing ARMv7 ABI, the AArch64 ILP32 ABI variants are currently available in RTEMS 6 releases and will be available in RTEMS 7, although deprecated.
4003 - Zynq-7000 BSP: Support using OCM as cacheable memory (opened)¶
Id |
4003 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2020-06-11T02:21:15.000Z |
Updated |
2026-02-07T15:51:27.169Z |
Milestone |
5.4 |
Labels |
bsp, old-indefinite, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: jbrandmeyer-piq
Background: During normal startup, the ROM bootloader performs vendor-specific initialization of core 1, and then sits in a wait-for-event loop until a special value has been written to a specific address in OCM. In that state, the MMU has not yet been initialized and core 1 is treating OCM as Device memory.
By the time the RTEMS boot gets to _CPU_SMP_Start_processor, core 0’s MMU has already been initialized with the application-defined memory map. I’d like to use the on-chip memory as inner cacheable memory in my application. In order to ensure that the kick address write actually becomes visible to core 1, a cache line flush of the affected line is necessary prior to sending the event that wakes up the other core.
I also added an invalidation prior to the kick-address write out of an abundance of caution. it shouldn’t be necessary, but I had a hard time proving it definitively.
There are a plethora of cache maintenance functions available for the job in RTEMS. I picked an inline helper that operates directly on CP15. The code’s commentary suggests that the L2 hasn’t been initialized yet, and the higher-level rtems_cache_*_multiple_data_lines API affects both L1D and L2. Also, I’m using inner-cacheable/outer-shareable memory attributes for OCM specifically because of where it sits in the SOC’s busswork, so it turns out that we never need to flush L2 for that memory anyway.
This patch also works with the default memory map, which defines upper OCM as Device memory. It is harmless to perform a flush by modified virtual address to memory which is marked as Device memory.
Author: Trac Migrate
2020-06-11T02:21:47.000Z
Original author: jbrandmeyer-piq
Attachment 0001-bsp-Support-cacheable-OCM-on-the-Zynq.patch added
Patch implementing this enhancement
Author: Joel Sherrill
2021-12-17T17:03:27.000Z
Original author: jbrandmeyer-piq
Milestone changed from %”6.1” to %”Indefinite”
Author: Amar Takhar
2025-09-05T02:57:43.424Z
changed the description
Author: Kinsey Moore
2026-02-07T15:51:27.142Z
Does RTEMS on Zynq7000 rely on TF-A/ATF to provide runtime services? This type of code would likely be resident in OCM if that is the case which would make at least part of OCM unusable for this purpose.
4443 - powerpc/motorola_powerpc BSPs build bootloader with -msoft-float (opened)¶
Id |
4443 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2021-05-26T19:59:57.000Z |
Updated |
2026-01-19T20:29:55.785Z |
Milestone |
5.4 |
Labels |
priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: anj
While working on the EPICS port to RTEMS-5 and trying to link an EPICS test application into a bootable binary for the mvme2100 BSP built with RTEMS-5.1, I get this error:
/usr/local/rtems-5.1/bin/powerpc-rtems5-ld: libComTestHarness uses hard float, /usr/local/rtems-5.1/powerpc-rtems5/mvme2100/lib/bootloader.o uses soft float
/usr/local/rtems-5.1/bin/powerpc-rtems5-ld: failed to merge target specific data of file libComTestHarness
The libComTestHarness is the EPICS test application. I get the same error with the mvme2307 BSP, which is part of the same powerpc/motorola_powerpc BSP family as the mvme2100.
After investigation I found that a recent version of binutils has made linking soft-float code with hard-float an error instead of just emitting a warning, which may be why this problem hasn’t come up before. I don’t see that warning when I build for the mvme2100 with RTEMS-4.9.2 but the warning message may have been added more recently than the version of binutils used for that release.
This is coming from the AM_CFLAGS definition in c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/Makefile.am which includes the flag -msoft-float whereas all of the motorola_powerpc boards have an FPU as far as I know (none of the BSP config/*.cfg files provide that flag). Thus I first tried removing just that flag:
diff --git a/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/Makefile.am b/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/Makefile.am
index 42b70544e6..1b4b95b14c 100644
--- a/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/Makefile.am
+++ b/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/Makefile.am
@@ -21,7 +21,7 @@ bootloader_SOURCES += ../../../../../../../bsps/powerpc/motorola_powerpc/bootloa
# Remove references to EABI when compiling bootloader
BOOTLOADER_CPU_CFLAGS=$(subst -msdata=eabi,,$(subst -meabi,,$(CPU_CFLAGS)))
AM_CPPFLAGS = -D__BOOT__ @RTEMS_CPPFLAGS@ @RTEMS_BSP_CPPFLAGS@
-AM_CFLAGS = -mrelocatable -msoft-float \\
+AM_CFLAGS = -mrelocatable \\
-mstrict-align -fno-builtin -Wall -mmultiple -mstring -O2 \\
-fomit-frame-pointer -ffixed-r13 -mno-sdata $(BOOTLOADER_CPU_CFLAGS)
AM_CCASFLAGS = $(AM_CPPFLAGS) \\
However that doesn’t seem to be enough, the result gives this application build error instead:
/usr/local/rtems-5.1/bin/powerpc-rtems5-objcopy -O binary -R .comment -S libComTestHarness rtems
gzip -f9 rtems
/usr/local/rtems-5.1/bin/powerpc-rtems5-ld -o libComTestHarness.boot /usr/local/rtems-5.1/powerpc-rtems5/mvme2100/lib/bootloader.o --just-symbols=libComTestHarness -b binary rtems.gz -T /usr/local/rtems-5.1/powerpc-rtems5/mvme2100/lib/ppcboot.lds -Map libComTestHarness.map
/usr/local/rtems-5.1/bin/powerpc-rtems5-ld: libComTestHarness: compiled normally and linked with modules compiled with -mrelocatable
/usr/local/rtems-5.1/bin/powerpc-rtems5-ld: failed to merge target specific data of file libComTestHarness
I don’t have a good feel for exactly what the -mrelocatable flag is doing, but the documentation implied something like it is probably needed in this case. It also showed a similar but apparently more liberal -mrelocatable-lib flag. On applying this change and rebuilding the BSP I was able to get my EPICS build to succeed:
diff --git a/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/Makefile.am b/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/Makefile.am
index 42b70544e6..92d6e21f40 100644
--- a/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/Makefile.am
+++ b/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/Makefile.am
@@ -21,11 +21,11 @@ bootloader_SOURCES += ../../../../../../../bsps/powerpc/motorola_powerpc/bootloa
# Remove references to EABI when compiling bootloader
BOOTLOADER_CPU_CFLAGS=$(subst -msdata=eabi,,$(subst -meabi,,$(CPU_CFLAGS)))
AM_CPPFLAGS = -D__BOOT__ @RTEMS_CPPFLAGS@ @RTEMS_BSP_CPPFLAGS@
-AM_CFLAGS = -mrelocatable -msoft-float \\
+AM_CFLAGS = -mrelocatable-lib \\
-mstrict-align -fno-builtin -Wall -mmultiple -mstring -O2 \\
-fomit-frame-pointer -ffixed-r13 -mno-sdata $(BOOTLOADER_CPU_CFLAGS)
AM_CCASFLAGS = $(AM_CPPFLAGS) \\
- -mrelocatable -DASM $(BOOTLOADER_CPU_CFLAGS)
+ -mrelocatable-lib -DASM $(BOOTLOADER_CPU_CFLAGS)
#
# CAUTION :
I don’t have a VME chassis or an MVME2100 board at home with me to test with, but I hope to be able to check if the result boots and works properly once I get back into the office (which might be a few weeks though). I’m filing this ticket now to see if anyone else has come across or already solved this problem, and to see if the solution looks reasonable to those with more experience.
Any comments?
Author: Trac Migrate
2021-06-21T00:52:05.000Z
Original author: anj
Felix Kraemer from Gemini found a linker flag
--no-warn-mismatchwhich seems to permit applications to be built against an unmodified BSP without getting the error, but that probably isn’t the best solution in the long run. I have added that flag to the EPICS build system for the mvme2100 and mvme2700 (AKA mvme2307) BSPs since we have a release coming up, but I plan to work on a better fix to the RTEMS BSP bootloader files once I have access to my VME systems again.
Author: Chris Johns
2025-09-19T01:45:45.953Z
changed the description
Author: Andrew Johnson
2026-01-19T20:29:55.739Z
Original author here (anj on the old RTEMS trac), the previous comment looks like a summary (AI-written?) of the problem that I reported during the COVID-19 pandemic when we were forced to work from home.
As reported in the first comment above the EPICS build system now adds the
--no-warn-mismatchlinker flag to both mvme2100 and mvme2700 target builds, which is sufficient as a workaround for those boards. We’re not looking for a further solution for this on RTEMS-5; if a better fix is developed for a future release (6.x or 7) I’d be happy to remove that linker flag though.
3053 - Change RTEMS License to Two Paragraph BSD (opened)¶
Id |
3053 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2017-06-21T17:54:07.000Z |
Updated |
2025-10-10T20:35:37.435Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::high, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
RTEMS has long used the GPL v2 with an exception that eliminated the viral nature of the license. There has been discussion amongst the core developers and primary submitters about switching to the “Two Paragraph BSD” license. The consensus was that it was time to change. One reason was that the RTEMS license was modeled on a license no longer used by GCC language run-times. Another was that the “Two Paragraph BSD” license is easier to explain and understand. But the major reason was that the RTEMS Project has never imposed any license conformance burden on end user projects. The BSD license family is much clearer about that intent.
An announcement was made at the December 2015 Flight Software Workshop ([http://flightsoftware.jhuapl.edu/files/_site/workshops/2015/]). The slides and video are available for that presentation. No specific date was given but the core developer consensus was that we needed to focus on the 4.11 branch and, subsequently, the 4.12 release branches being made. With the 4.12 branch imminent, it is now time to ensure there is a ticket to track this effort and work through the relicensing as quickly and accurately as possible.
The relicensing effort will involve multiple activities:
update web content to include and recommend Two Paragraph BSD license
update coding conventions to recommend Two Paragraph BSD license
identify contributors for each file
some work has been done on this
obtain permission from contributors to relicense
update files with new license
generate reports on licenses associated with a particular build of RTEMS
The content on relicensing from the Flight Software Workshop presentation is captured here.
Original rationale for GPL v2 + exception * felt needed to establish a community * “stick” to encourage submissions * license was used by GCC language run-times
Rationale to switch * RTEMS has a strong community * users understand business value of submitting * we have explained the “carrot”* GPL v3 has soured some on GPL in general
Mechanics of Switching * Permission from each submitter must be obtained * permission obtained from top contributors * All contributors to a file must give permission before that file can be relicensed * Web form with confirmation email to grant permission to relicense * Effort will be made to locate the “missing”
When Permission is Not Obtained * Some files may never be relicensed * If users fund, replacement may be written * Older BSPs and ports may be obsoleted and removed on technical grounds * These are the most likely to contain files to have contributors that are hard to find
Generation of License Report * We are considering marking files with Linux Foundation sponsored [https://SPDX.org] annotation * Standard annotation for open source licenses _ Examples: NASA-1.3, GPL-2.0 * Can annotate exceptions like current RTEMS license * Example: GPL-2.0-with-linking-exception * Tools exist to generate overall license reports * RTEMS would have to integrate one with build system
Author: Chris Johns
2017-08-14T00:55:55.000Z
Milestone changed from %”5.0” to %”4.12.0”
Please review and update the milestone. Thanks.
Author: Joel Sherrill
2017-10-11T23:09:19.000Z
Milestone changed from %”4.12.0” to %”Indefinite”
Author: Joel Sherrill
2018-08-07T21:11:13.000Z
Attachment OAR-RelicenseToBSD-d2.pdf added
OAR Corporation letter granting permission to relicense
Author: Joel Sherrill
2018-08-07T21:14:51.000Z
A signed PDF from On-Line Applications Corporation (OAR) is attached to this ticket which grants the RTEMS Community permission to relicense current and future contributions. The text of the letter is as follows:
_On-Line Applications Research Corporation (OAR) grants permission to the RTEMS Foundation to relicense its current and future contributions from our current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License (https://opensource.org/licenses/BSD-2-Clause). OAR shall work with the RTEMS Foundation to facilitate this change in the license as soon as possible._
Author: Trac Migrate
2018-11-27T05:50:37.000Z
embedded brains has signed and sent a letter granting relicensing. Included are also letters from the individual developers: * Sebastian Huber * Christian Mauderer * Alexander Krutwig * Ralf Kirchner * Peter Rasmussen * Thomas Doerfler.
Author: Trac Migrate
2018-11-27T07:09:10.000Z
In [changeset:”c1864a0ad33907c5492d89ba447e227b92aad241/rtems” c1864a0a/rtems]:
Add LICENSE.BSD-2-Clause Copied from: https://spdx.org/licenses/BSD-2-Clause.html The formatting is suitable for C/C++ source comments. Update #3053.
Author: Trac Migrate
2018-12-02T16:19:29.000Z
Hesham Almatary has signed and sent the relicence letter
Author: Trac Migrate
2018-12-03T13:55:16.000Z
I grant permission to the RTEMS Foundation to relicense my current and future contributions from the current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License.
Jiri Gaisler.
Author: Trac Migrate
2018-12-11T06:00:39.000Z
In [changeset:”617976759e5fdbe37098c4fff4cf972a868ea86a/rtems” 6179767/rtems]:
Remove white space at end of line Update #3053.
Author: Gedare Bloom
2018-12-18T18:30:04.000Z
I sent in a letter to grant permission for re-licensing.
Author: Trac Migrate
2018-12-19T12:31:56.000Z
In [changeset:”cde5e8dc2bf4131d48428e1c311e038ff9923b1f/rtems” cde5e8d/rtems]:
LICENSE.BSD-2-Clause: Clarify copyright format Update #3053.
Author: Trac Migrate
2018-12-19T12:32:00.000Z
In [changeset:”6164fd82c6033a8587e28dee9c9082dd11a08cf9/rtems” 6164fd8/rtems]:
Move COPYING file to LICENSE.GPL-2.0 Use the latest plain text formatting of the GPL-2.0 as published by the FSF: https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt The current RTEMS license refers to the GPL-2.0, so the source distribution should ship a copy of the license. Update #3053.
Author: Chris Johns
2019-04-09T05:22:26.000Z
I sent in a letter to grant permission for re-licensing.
Author: Trac Migrate
2019-04-09T12:34:13.000Z
I grant permission to the RTEMS Foundation to relicense my current and future contributions to the RTEMS public source to be relicensed to the 2-Clause BSD License.
Pavel Pisa
Author: Trac Migrate
2019-04-10T07:50:45.000Z
In [changeset:”f1eedbde523e77562078aab894504300f9c259a6/rtems” f1eedbd/rtems]:
bsp/xilinx-zynq: Relicense to BSD-2-Clause Relicense contributions from Chris Johns, Christian Mauderer, embedded brains GmbH, Joel Sherrill, OAR, Pavel Pisa, Ralf Kirchner, and Sebastian Huber. Update #3053.
Author: Trac Migrate
2020-02-12T15:12:47.000Z
In [changeset:”24851567c38f573e9176529e9ca431fbf80c6cef/rtems” 2485156/rtems]:
score: Split up objects allocation Split up the different objects allocation methods into separate functions. This helps to avoid a dependency on the workspace in case no objects or a static set of objects is configured. Change license to BSD-2-Clause according to file histories. Update #3053. Update #3835.
Author: Trac Migrate
2020-02-24T07:14:08.000Z
In [changeset:”d27e6304d0968e0826243a44dda7a09e0cb75dd4/rtems-docs” d27e630/rtems-docs]:
eng: Rework file template section Update #3053.
Author: Trac Migrate
2020-02-25T11:33:45.000Z
In [changeset:”cadd8d18e316fe1fc2c91ae03e2b4ee89b07ef67/rtems” cadd8d1/rtems]:
config: Add <rtems/confdefs/obsolete.h> Unify handling of obsolete configuration options. Remove comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:33:52.000Z
In [changeset:”f45d0b2f8e8037189ee4816628e2c0e13dfb50d6/rtems” f45d0b2f/rtems]:
config: Add <rtems/confdefs/bsp.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:33:55.000Z
In [changeset:”0f8e139e14e569f7555a2a69d62bc5446b1bea30/rtems” 0f8e139e/rtems]:
config: Add <rtems/confdefs/percpu.h> Remove comments and copyrightable content from the moved content. Use BSD-2-Clause for new file according to file history of <rtems/confdefs.h>. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:33:59.000Z
In [changeset:”16082210d61d00ac83d1aa39055e8562755864ab/rtems” 1608221/rtems]:
config: Add <rtems/confdefs/libio.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:02.000Z
In [changeset:”591e973662d6abf027c054bc5ed4eb16c964c92c/rtems” 591e9736/rtems]:
config: Add <rtems/confdefs/scheduler.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:06.000Z
In [changeset:”691b61498ed32cef1e83cd9917c8567329286cfa/rtems” 691b614/rtems]:
config: Add <rtems/confdefs/bdbuf.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:09.000Z
In [changeset:”03aff2cf85b514f34cba2e798928471795fd80be/rtems” 03aff2c/rtems]:
config: Add <rtems/confdefs/malloc.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Move the default configuration to library files so that application configurations do not include the definitions for the default case. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:13.000Z
In [changeset:”1d35bf2a7fc15beb0249c011cd5ed246ce50f68d/rtems” 1d35bf2a/rtems]:
config: Add <rtems/confdefs/mcpi.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:17.000Z
In [changeset:”32561f5f5b9dc5bfc396e497da118eeaf3fb1867/rtems” 32561f5/rtems]:
config: Add <rtems/confdefs/clock.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:20.000Z
In [changeset:”fb0caca9bcd585376b31bd23f7b77275d7a134fb/rtems” fb0caca/rtems]:
config: Add <rtems/confdefs/newlib.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:23.000Z
In [changeset:”8f3419bd880f46e9c072d535d67dd98f5767ee7c/rtems” 8f3419b/rtems]:
config: Add <rtems/confdefs/extensions.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:27.000Z
In [changeset:”b15d1cba0ff0acead2650c7a3df6f75eefccafa6/rtems” b15d1cb/rtems]:
config: Add <rtems/confdefs/inittask.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:30.000Z
In [changeset:”831493390778064f0881e55bd965ac25cfc34df1/rtems” 8314933/rtems]:
config: Add <rtems/confdefs/initthread.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:34.000Z
In [changeset:”fe84ab5c6cd612538970e4ace1aad850a4b26d0c/rtems” fe84ab5/rtems]:
config: Add <rtems/confdefs/console.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:37.000Z
In [changeset:”7b6596f56fe9e453047a446ca34ec050cf23cbc6/rtems” 7b6596f5/rtems]:
config: Add <rtems/confdefs/iodrivers.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:41.000Z
In [changeset:”40db0518a9893fbeaf95a8fb1691aff94244f6bf/rtems” 40db051/rtems]:
config: Add <rtems/confdefs/unlimited.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:44.000Z
In [changeset:”f5a2fd8628f3c432ee75e8964b00eb66c6f4a1f7/rtems” f5a2fd86/rtems]:
config: Add <rtems/confdefs/threads.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:48.000Z
In [changeset:”d20209b06578c3fdfab3eee892dcfbdb6bf64620/rtems” d20209b/rtems]:
config: Add <rtems/confdefs/objectsclassic.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:51.000Z
In [changeset:”35e58c45f73239ac40abd09d6fbe40104acb89ae/rtems” 35e58c45/rtems]:
config: Add <rtems/confdefs/wkspacesupport.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:55.000Z
In [changeset:”1fb1cf1a3a61021790a9cc438a150e4141b5a386/rtems” 1fb1cf1/rtems]:
config: Add <rtems/confdefs/objectsposix.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
Author: Trac Migrate
2020-02-25T11:34:59.000Z
In [changeset:”a78495eda2d8ef6653a06222f9786b51f722efab/rtems” a78495ed/rtems]:
config: Add <rtems/confdefs/wkspace.h> Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Change licence of <rtems/confdefs.h> to BSD-2-Clause according to file history. Update #3053. Close #3875.
Author: Trac Migrate
2020-03-04T08:46:40.000Z
In [changeset:”7e3b5c0ced72ea6ffc79986d26bd9184c61888fa/rtems” 7e3b5c0/rtems]:
console: Use IMFS_add_node() for simple console Change license to BSD-2-Clause according to file history. Update #3053. Update #3894.
Author: Trac Migrate
2020-03-04T08:46:44.000Z
In [changeset:”fa3005f6c1ddb99347acb70cbaecd155ed0356ed/rtems” fa3005f/rtems]:
console: Use IMFS_add_node() for simple task cons Change license to BSD-2-Clause according to file history. Update #3053. Update #3894.
Author: Trac Migrate
2020-03-06T14:13:14.000Z
I grant permission to the RTEMS Foundation to relicense my current and future contributions from the current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License.
Kuan-Hsun Chen
Author: Trac Migrate
2020-08-31T14:21:44.000Z
In [changeset:”c7e30854f284a17200892ce8e5405744e3c46c24/rtems” c7e3085/rtems]:
rtems: Add _RTEMS_Name_to_id() Simplify object name to identifier directives. Using _RTEMS_Name_to_id() to implement the directives enables a tail call optimization. Change license to BSD-2-Clause according to file history. Update #3053.
Author: Trac Migrate
2020-09-18T16:57:09.000Z
In [changeset:”0b410b8ac75b829dca7651163da904c1a099351b/rtems” 0b410b8a/rtems]:
rtems: Generate <rtems.h> Change license to BSD-2-Clause according to file history and documentation re-licensing agreement. Update #3053. Update #3899. Update #3993.
Author: Trac Migrate
2020-09-22T07:44:34.000Z
In [changeset:”d9bdf166644f612dd628fe4951c12c6f8e94ba5f/rtems” d9bdf166/rtems]:
rtems: Install missing header file Update #3053.
Author: Trac Migrate
2020-09-28T05:18:13.000Z
In [changeset:”2c09f54fc41b86265af137716013bce2e2e92b27/rtems” 2c09f54f/rtems]:
score: Add <rtems/score/coremsgbuffer.h> Move the CORE_message_queue_Buffer definition to a separate header file to be able to use it independent of the remaining Message Queue Handler API. Change license to BSD-2-Clause according to file history. Update #3053. Update #4007.
Author: Trac Migrate
2021-02-09T06:53:35.000Z
I grant permission to the RTEMS Foundation to relicense my current and future contributions from the current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License.
Author: Trac Migrate
2021-02-09T07:19:33.000Z
In [changeset:”570992dc27543d8e1c8ed13596a4cd66439a86a1/rtems” 570992dc/rtems]:
bsp/riscv: Re-license to BSD-2-Clause Change license to BSD-2-Clause according to file history. Update #3053.
Author: Trac Migrate
2021-04-20T17:18:39.000Z
In [changeset:”d8a5e140ec44a5e45cf82d3759a339e9dedced56/rtems” d8a5e14/rtems]:
libcsupport: Move rtems_calloc() Move rtems_calloc() since it only depends on rtems_malloc(). This may make it easier to customize the heap allocator. Change licence to BSD-2-Clause according to file history. Update #3053.
Author: Trac Migrate
2021-05-15T15:06:34.000Z
In addition to my permission regarding my contributions in the name of embedded brains, I also grant permission to the RTEMS Foundation to relicense my current and future contributions done in the name of IMD from the current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License.
Thomas Doerfler.
Author: Trac Migrate
2021-05-17T15:30:54.000Z
In [changeset:”80b3c938ce9798997c59cc102fb6738475f6fe32/rtems” 80b3c938/rtems]:
score: Move _Thread_queue_Queue_get_name_and_id() Move this diagnostic function to a separate file since it does not provide a core function of the system. Change license to BSD-2-Clause according to file history and re-licensing agreement. Update #3053.
Author: Trac Migrate
2021-06-10T06:11:24.000Z
In [changeset:”93afcff7b5360fa71616d789c4d34279309a24e9/rtems” 93afcff7/rtems]:
bsps/sparc: Simplify memory initialization Directly initialize the memory in the start sequence defined by start.S instead of using a system initialization handler. This avoids using the global variable rdb_start which used a memory location which was shared with _ERC32_MEC_Timer_Control_Mirror. This change makes it possible to use _Memory_Allocate() even before the system initialization is started. Change license to BSD-2-Clause according to file history and re-licensing agreement. Update #3053.
Author: Trac Migrate
2021-06-11T05:26:55.000Z
In [changeset:”fad01e6cf95f98adaca3157faa8b96c19296a68e/rtems” fad01e6c/rtems]:
score: Add PER_CPU_DATA_NEED_INITIALIZATION() Make the initialization of the per-CPU data optional. Change license to BSD-2-Clause according to file history and re-licensing agreement. Update #3053.
Author: Trac Migrate
2021-06-16T05:35:47.000Z
Hi,
For the files cpukit/score/src/schedulerstrongapa.c, and cpukit/include/rtems/score/schedulerstrongapa.h the license has been changed to BSD-2-Clause according to file history and re-licensing agreement.
Update [https://devel.rtems.org/ticket/3053]
Author: Trac Migrate
2021-06-17T15:24:57.000Z
In [changeset:”3ee19b7ac3ff3c92dd9440eb11948c9d361ab346/rtems” 3ee19b7a/rtems]:
bsps/irq: Change license to BSD-2-Clause Change license to BSD-2-Clause according to file history and re-licensing agreement. Update #3053.
Author: Trac Migrate
2021-06-21T08:15:09.000Z
In [changeset:”8d4382ba34dfaf6a37b1f356625a29fad1a02bda/rtems” 8d4382b/rtems]:
bsps/irq: Change license to BSD-2-Clause Change license to BSD-2-Clause according to file history and re-licensing agreement. Update #3053.
Author: Trac Migrate
2021-06-24T10:30:23.000Z
In [changeset:”89c1e879c02054b8032a9a66103e20bd61156f75/rtems” 89c1e879/rtems]:
score: Move _ISR_Vector_table[] to separate file The _ISR_Handler_initialization() does not touch the _ISR_Vector_table[]. Move the definition of _ISR_Vector_table[] to a separate file. Change license to BSD-2-Clause according to file history and re-licensing agreement. Update #3053.
Author: Trac Migrate
2021-06-24T12:18:10.000Z
In [changeset:”6c23252cdd8ea63d0fe13d9f99b7befbf070fe80/rtems” 6c23252/rtems]:
Update Strong APA Scheduler This change allows for the migration of higher priority tasks on the arrival of a lower priority task limited by affinity constraints. Change license to BSD-2-Clause according to file history and re-licensing agreement. Update #3053.
Author: Trac Migrate
2021-07-28T17:06:42.000Z
In [changeset:”6e82e9e89ec2f0863013512b50f6a1cf8a0f58d3/rtems” 6e82e9e8/rtems]:
libcsupport: Consistent rtems_putc() output Use the same function to output the '\\r\\n' combination produced by rtems_putc(). Fix the format. Change licence according to file history. Update #3053.
Author: Trac Migrate
2021-09-06T10:20:59.000Z
In [changeset:”fbd0a3cec3096d8fe283c3ff05ebb5c0aafc95d9/rtems” fbd0a3ce/rtems]:
score: Move _Thread_Dispatch() The _Thread_Dispatch() function was customized over time and now the work is done by _Thread_Do_dispatch() and specialized wrappers. The plain _Thread_Dispatch() is now only used in some CPU ports. Move it to a separate file to avoid dead code in the general. Change license to BSD-2-Clause according to file history and re-licensing agreement. Update #3053.
Author: Trac Migrate
2021-09-06T10:26:01.000Z
In [changeset:”f958d58a6a98cbc111c4e3eb58a4170ce725a915/rtems” f958d58/rtems]:
score: Split up rbtreenext.c Split up rbtreenext.c since only _RBTree_Minimum() is used by the operating system core services (thread queues and the EDF scheduler). Change license to BSD-2-Clause according to file history and re-licensing agreement. Update #3053.
Author: Trac Migrate
2021-09-21T08:25:42.000Z
In [changeset:”0036ddf1f6263c3d352645f4d3a9afe4ba388bb2/rtems” 0036ddf/rtems]:
score: Provide two thread pin/unpin defaults The uniprocessor schedulers do not support systems with more than more processors. So they rivially support thread pinning and thus the SMP_FATAL_SCHEDULER_PIN_OR_UNPIN_NOT_SUPPORTED cannot happen. Add a second default implementation for SMP schedulers which do not support thread pinning. Change license to BSD-2-Clause according to file history and re-licensing agreement. Update #3053.
Author: Trac Migrate
2021-11-30T08:32:07.000Z
In [changeset:”b070e0127d0fe0b6ccf972e1605b6e43d4a4cbf5/rtems” b070e012/rtems]:
wkspace.c: Change license to BSD-2-Clause Change licence according to file history. Update #3053.
Author: Trac Migrate
2021-11-30T08:32:20.000Z
In [changeset:”d7205f0083f8fdd0408404ce99c6eab9b8d120c7/rtems” d7205f0/rtems]:
libc: Optimize malloc() initialization The BSPs provide memory for the separate C Program Heap initialization via _Memory_Get(). Most BSPs provide exactly one memory area. Only two BSPs provide more than one memory area (arm/altera-cyclone-v and bsps/powerpc/mpc55xxevb). Only if more than one memory area is provided, there is a need to use _Heap_Extend(). Provide two implementations to initialize the separate C Program Heap and let the BSP select one of the implementations based on the number of provided memory areas. This gets rid of a dependency on _Heap_Extend(). It also avoids dead code sections for most BSPs. Change licence to BSD-2-Clause according to file history. Update #3053.
Author: Trac Migrate
2022-02-24T23:06:44.000Z
In [changeset:”10114848675df9a28f6d733616bcc9fd4ee865ea/rtems” 1011484/rtems]:
score/src/schedulersimple*.c: Replace found in found in with found in Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:03.000Z
In [changeset:”ab028244174dc55ca68ad6e8be5d2490b093de5c/rtems” ab02824/rtems]:
score/src/[a-m]*.c: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:06.000Z
In [changeset:”4a0e418024c864c59894c833a9dc9ba7cd82762e/rtems” 4a0e418/rtems]:
score/src/[n-s]*.c: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:10.000Z
In [changeset:”2a1449c51751d8a642def2f7b9351b7c99e88009/rtems” 2a1449c/rtems]:
score/src/[t-z]*.c: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:14.000Z
In [changeset:”7ebce3590227e61e0cbf037b1229d164d879b132/rtems” 7ebce359/rtems]:
cpukit/include/rtems/score/[a-r]*.h: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:18.000Z
In [changeset:”7b85efb8c4543637be30e829a359d7eab44d2aaa/rtems” 7b85efb8/rtems]:
cpukit/include/rtems/score/[s-z]*.h: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:21.000Z
In [changeset:”c4fb6170305997a8baa2ddbf12b8ef28f844835b/rtems” c4fb617/rtems]:
cpukit/rtems/src/[a-r]*.c: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:25.000Z
In [changeset:”b3b6d21e6f4747a5449560cafbb0ec855c0c4d9a/rtems” b3b6d21e/rtems]:
cpukit/rtems/src/[s-z]*.c: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:29.000Z
In [changeset:”a2ed06e38f94ea8d2b575de4725eae030d7664a1/rtems” a2ed06e/rtems]:
cpukit/include/rtems/rtems/*.h: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:33.000Z
In [changeset:”0a645dadd5655d2deac4e9017051d1124848a6f9/rtems” 0a645dad/rtems]:
cpukit/posix/src/[a-o]*.c: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:36.000Z
In [changeset:”380fb9fb914fbc5043b75981834fd665af2e84fd/rtems” 380fb9f/rtems]:
cpukit/posix/src/[p-z]*.c: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:40.000Z
In [changeset:”fee27716f0dae47dabb39db7abdfab156c241499/rtems” fee2771/rtems]:
posix/src/_execve.c: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:43.000Z
In [changeset:”46a16ada0c625472978f71ef12f5f1f6a0e4b8d7/rtems” 46a16ada/rtems]:
cpukit/include/rtems/posix/*.h: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:47.000Z
In [changeset:”bd2e898c9e580c2ccaa8d4a6c74df70f03f912eb/rtems” bd2e898/rtems]:
sapi/src/*.c: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:50.000Z
In [changeset:”e47a3b758fab9cff878aecb2204b87d4209a81d9/rtems” e47a3b7/rtems]:
score/cpu/arm: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:54.000Z
In [changeset:”f42730ae7a9408032eb0083579b338367814d0ce/rtems” f42730a/rtems]:
score/cpu/i386: Change license to BSD-2 sse_test.c was deliberarely NOT changed. Updates #3053.
Author: Trac Migrate
2022-02-28T16:19:57.000Z
In [changeset:”51366002f2a200c63bf329b8da9206b810de334e/rtems” 51366002/rtems]:
score/cpu/m68k: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:20:01.000Z
In [changeset:”bf10d5b9121367d9b082f0dbe9d6cce7a746fbde/rtems” bf10d5b/rtems]:
score/cpu/mips: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:20:04.000Z
In [changeset:”4b5e64ac0494f2ed1725ffcf8f19f2729c7a2356/rtems” 4b5e64a/rtems]:
score/cpu/nios2: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:20:08.000Z
In [changeset:”3ca8895f3a7b3ca39113fb53377a6d06e1aed2a5/rtems” 3ca8895f/rtems]:
score/cpu/no_cpu: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:20:14.000Z
In [changeset:”87076c94d2cf59f46ce84fb0be156ed3bc770494/rtems” 87076c9/rtems]:
score/cpu/powerpc: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:20:18.000Z
In [changeset:”e111974ab86b6172d51928554df37d65a3150ac8/rtems” e111974/rtems]:
score/cpu/sparc: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:20:24.000Z
In [changeset:”c0ec0b29e9a2a9d9c7ab8c70449c2c598ed4994e/rtems” c0ec0b29/rtems]:
score/cpu/v850: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:20:28.000Z
In [changeset:”2fb29836b0ccf370925f5900abe8fbda1c0f503e/rtems” 2fb29836/rtems]:
cpukit/include/adainclude: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-02-28T16:20:32.000Z
In [changeset:”2dcc54f9c678a43d6f6c0a5bbdead68187411cce/rtems” 2dcc54f/rtems]:
cpukit/ftpd: Change license to BSD-2 Not all files could be changed. Updates #3053.
Author: Trac Migrate
2022-02-28T16:20:35.000Z
In [changeset:”f381e9bab29278e4434b1a93e70d17a7562dc64c/rtems” f381e9b/rtems]:
cpukit/libblock: Change license to BSD-2 Updates #3053.
Author: Joel Sherrill
2022-03-02T21:36:59.000Z
Attachment `JakeJanovetz-Permission.pdf <JakeJanovetz-Permission.pdf>`_(/assets/tracmigration/ticket_attachments/JakeJanovetz-Permission.pdf) added
Permission email from Jake Janovetz
Author: Joel Sherrill
2022-03-02T21:37:36.000Z
Referenced permission from Jacob Janovetz via email. PDF is attached.
Author: Joel Sherrill
2022-03-03T19:34:36.000Z
Attachment `JayMonkman-Permission.pdf <JayMonkman-Permission.pdf>`_(/assets/tracmigration/ticket_attachments/JayMonkman-Permission.pdf) added
Permission email from Jay Monkman
Author: Joel Sherrill
2022-03-03T19:34:54.000Z
Referenced permission from Jacob Janovetz via email. PDF is attached.
Author: Trac Migrate
2022-03-05T00:50:07.000Z
I grant permission to the RTEMS Foundation to relicense all my contributions from the current license to the 2 clause BSD license.
Author: Joel Sherrill
2022-03-08T14:35:54.000Z
Attachment Rtems_Relicensing_IPR_2018-11-18.pdf added
Permission from IPR (Peter Rasmussen) predecessor company to embedded brains GmbH
Author: Joel Sherrill
2022-03-08T14:36:19.000Z
Attachment Zustimmung Thomas D|md_0_246|rfler IMD an die RTEMS Foundation.pdf added
Permission from IMD (Thomas Doerfler) predecessor company to embedded brains GmbH
Author: Joel Sherrill
2022-03-08T14:36:39.000Z
Add permission letters (PDF) for submissions for IMD and IPR. These were the companies Thomas Doerfler and Peter Rasmussen merged to form embedded brains GmbH.
Author: Joel Sherrill
2022-03-08T18:53:41.000Z
Attachment `EricNorum-Permission.pdf <EricNorum-Permission.pdf>`_(/assets/tracmigration/ticket_attachments/EricNorum-Permission.pdf) added
Permission email from Eric Norum
Author: Joel Sherrill
2022-03-08T18:54:46.000Z
Added PDF of permission email from Eric Norum.
Author: Joel Sherrill
2022-03-20T23:33:07.000Z
Attachment `AnthonyGreen-Permission.pdf <AnthonyGreen-Permission.pdf>`_(/assets/tracmigration/ticket_attachments/AnthonyGreen-Permission.pdf) added
Permission email from Anthony Green
Author: Joel Sherrill
2022-03-21T17:08:14.000Z
Attachment `AmaanCheval-Permission.pdf <AmaanCheval-Permission.pdf>`_(/assets/tracmigration/ticket_attachments/AmaanCheval-Permission.pdf) added
Permission email from Amaan Cheval
Author: Trac Migrate
2022-03-22T16:33:27.000Z
In [changeset:”a50839ffd83f6524f337a9805c5525aead4acd15/rtems” a50839ff/rtems]:
cpukit/libdl/rtl-alloc-check.py: Change to BSD-2 by hand Updates #3053.
Author: Trac Migrate
2022-03-22T16:33:32.000Z
In [changeset:”5a65257d0ccf58efa9833dc3e2bc80d669d92f2f/rtems” 5a65257d/rtems]:
cpukit/libdl Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:33:35.000Z
In [changeset:”72d83c61d4580a3ea2d6e1f6b6e739dbfd5d4ee3/rtems” 72d83c61/rtems]:
cpukit/libdrvmsg: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:33:40.000Z
In [changeset:”60060e695a038b2f1c35d6e42d2c70f0a2c6accd/rtems” 60060e6/rtems]:
cpukit/libfs/src/defaults: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:33:43.000Z
In [changeset:”5dec08934fe44c8483795147e3e6f9480660f099/rtems” 5dec089/rtems]:
cpukit/libdl: Manual file header reordering (SPDX, Doxygen, Copyright) Updates #3053.
Author: Trac Migrate
2022-03-22T16:33:47.000Z
In [changeset:”67a5936f58f673118ba7f2b10fbae76172e6f464/rtems” 67a5936/rtems]:
cpukit/libfs/src/imfs: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:33:52.000Z
In [changeset:”4ad52d62fe1d3f8329edae4e99da5585c9f275cf/rtems” 4ad52d62/rtems]:
cpukit/libds/src/ftpfs/tftpDriver.c: Manually update license to BSD-2 Eric Norum granted permission plus git log archeology to get year for his copyright. Updates #3053.
Author: Trac Migrate
2022-03-22T16:33:56.000Z
In [changeset:”2830ee959baf461f8c30614f94e871e04b2ce131/rtems” 2830ee9/rtems]:
cpukit/libfs/src/rfs: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:34:00.000Z
In [changeset:”f083c84fe5ff60e17491bd4b99010de05b35d5d8/rtems” f083c84/rtems]:
cpukit/libgnat: Change license to BSD-2. Updates #3053.
Author: Trac Migrate
2022-03-22T16:34:04.000Z
In [changeset:”1b33b9d0e5927a4be6d95744edd9e81500ca4173/rtems” 1b33b9d/rtems]:
cpukit/libpci: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:34:08.000Z
In [changeset:”1db3d3c3ee36655f4e606582c9c78d6b06934bd3/rtems” 1db3d3c/rtems]:
cpukit/libtest: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:34:11.000Z
In [changeset:”152ab750ca736ecd7e3119aa477889120de9eadd/rtems” 152ab750/rtems]:
cpukit/libmisc/bspcmdline: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:34:15.000Z
In [changeset:”1dc5ba2a4536578864168e5ba9af61b27931df0f/rtems” 1dc5ba2a/rtems]:
cpukit/capture: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:34:19.000Z
In [changeset:”4b7fbc7c44e86e09469d836aef5c9f158763a104/rtems” 4b7fbc7/rtems]:
cpukit/libmisc/capture: Manually change license to BSD-2 These files did not follow the standard format and needed to be changed manually. Updates #3053.
Author: Trac Migrate
2022-03-22T16:34:23.000Z
In [changeset:”f1470914fb3ee3b40a1a01e8ed832c3274b4356c/rtems” f147091/rtems]:
cpukit/libmisc/cpuuse: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:34:27.000Z
In [changeset:”183209b5e73913ac0c8f3c5ba6ca3afb732e4cc5/rtems” 183209b/rtems]:
cpukit/libmisc/devnull/devzero.c: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:34:31.000Z
In [changeset:”9723662214302c715990cb5dd7d26e204ae12c17/rtems” 97236622/rtems]:
cpukit/libmisc/dummy: Change license to BSD-2. Updates #3053.
Author: Trac Migrate
2022-03-22T16:34:34.000Z
In [changeset:”3674288ad277a64854cf3159832c2824ecb8a1fe/rtems” 3674288/rtems]:
cpukit/libmisc/dumpbuf: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:34:38.000Z
In [changeset:”ccf8287197a8e1a5ea67f97a6049c52a01576b86/rtems” ccf82871/rtems]:
cpukit/libmisc/fsmount: Change license to BSD-2. Updates #3053.
Author: Trac Migrate
2022-03-22T16:34:45.000Z
In [changeset:”903bba259f8281d2291c478a7d4a386cf89eba77/rtems” 903bba25/rtems]:
cpukit/libmisc/mouse: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:34:49.000Z
In [changeset:”aa4c01027afc2ca087f6fc48217a6e45fa883a7b/rtems” aa4c0102/rtems]:
cpukit/libmisc/redirector: Manually change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:34:52.000Z
In [changeset:”c02836c485b5ad3543a7578a8d0ac64b7d05788e/rtems” c02836c/rtems]:
cpukit/libmisc/rtems-fdt: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:34:57.000Z
In [changeset:”50ec42c35339bdcfec4a925dd8a3916e3e1f0093/rtems” 50ec42c/rtems]:
cpukit/libmisc/serdbg: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:35:01.000Z
In [changeset:”ed4200e7706d7abd248e86075776ada6efa1fccb/rtems” ed4200e/rtems]:
cpukit/libmisc/check: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-22T16:35:04.000Z
In [changeset:”fab1a86221e057a93bb9c1423dac81ed2b29ecde/rtems” fab1a86/rtems]:
cpukit/libmisc/untar: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-25T16:08:19.000Z
In [changeset:”e4cc56a7921b9d13d191a2f084ee1baf7a0b308e/rtems” e4cc56a7/rtems]:
cpukit/libmisc/monitor/: Manually change to BSD-2 license This code did not have any copyrights or licenses and a bit of archeology was needed to determine authorship. This code was in the initial import into the RTEMS CVS repository when it was established in May 1995. There was very little, if any, code not written by OAR Corporation in that initial import. After discussion with Chris Johns, it was determined that this code was from OAR Corporation and that he had added a few features later. Both Chris Johns and OAR Corporation have given permission to relicense. Updates #3053.
Author: Trac Migrate
2022-03-25T21:45:57.000Z
I grant permission to the RTEMS Foundation to relicense my current and future contributions from the current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License.
Author: Trac Migrate
2022-03-26T22:54:22.000Z
In [changeset:”35d1f9a238b469f065d3fa60ace1ed1cf765d8cd/rtems” 35d1f9a/rtems]:
cpukit/include/dev: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-26T22:54:26.000Z
In [changeset:”3ec0b2676d77a7d5d7094cd1a2b6d2d765023230/rtems” 3ec0b267/rtems]:
cpukit/include/linux: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-26T22:54:30.000Z
In [changeset:”fb5f575b9f991d400d7249898f51f7bc1b354165/rtems” fb5f575/rtems]:
cpukit/include/rtems: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-03-26T22:54:34.000Z
In [changeset:”77d1ac6c22e0a7485f587f01b7a30e79a46385a2/rtems” 77d1ac6c/rtems]:
cpukit/include/sys: Change license to BSD-2. Updates #3053.
Author: Trac Migrate
2022-03-26T22:54:37.000Z
In [changeset:”3d43589812f992c4b056478607fe26565f9c9b75/rtems” 3d435898/rtems]:
cpukit/include/*.h: Change license to BSD-2 Updates #3053.
Author: Joel Sherrill
2022-03-27T15:51:21.000Z
Attachment `PetrBenes-Permission.pdf <PetrBenes-Permission.pdf>`_(/assets/tracmigration/ticket_attachments/PetrBenes-Permission.pdf) added
Permission email from Petr Benes
Author: Trac Migrate
2022-04-01T14:51:53.000Z
In [changeset:”ffaaae2cf5f028f779d62c0f7c932fbbbd8fd45d/rtems” ffaaae2/rtems]:
cpukit/score/cpu/moxie: Change license to BSD-2 Permission received from Anthony Green. Updates #3053.
Author: Trac Migrate
2022-04-01T14:51:57.000Z
In [changeset:”59fba6f520c9272c80370720978ae54bb49739e2/rtems” 59fba6f/rtems]:
cpukit/include/rtems/cbs.h: Change license to BSD-2 Permission received from Petr Benes Updates #3053.
Author: Trac Migrate
2022-04-01T14:52:01.000Z
In [changeset:”54ec02640d4ef45fb6a2660c78f2600c4009aec6/rtems” 54ec0264/rtems]:
cpukit/include/rtems/timespec.h: Change license to BSD-2 Permission received from Krzysztof Miesowicz. Updates #3053.
Author: Trac Migrate
2022-04-01T14:52:05.000Z
In [changeset:”d90e2dc1e844e051d335527098925b3f43d2624e/rtems” d90e2dc1/rtems]:
cpukit/libcsupport/src/[a-f]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-01T14:52:08.000Z
In [changeset:”df1cb9f397cf2f739be006969669137ee270a652/rtems” df1cb9f/rtems]:
cpukit/libcsupport/src/[s-z]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-01T14:52:12.000Z
In [changeset:”70432fcff208756f3df17c66c971e32d85e3be79/rtems” 70432fc/rtems]:
cpukit/libcsupport/src/[g-r]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-01T14:52:16.000Z
In [changeset:”821e89dab2e26667660af8e54cdc0b7213e1fa28/rtems” 821e89d/rtems]:
cpukit/libcsupport/src/_*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-01T19:41:53.000Z
I grant permission to the RTEMS Foundation to relicense my current and future contributions from the current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License.
Author: Joel Sherrill
2022-04-02T19:08:46.000Z
Attachment `FernandoRuizCasas-Permission.pdf <FernandoRuizCasas-Permission.pdf>`_(/assets/tracmigration/ticket_attachments/FernandoRuizCasas-Permission.pdf) added
Permission email from Fernando Ruiz Casas
Author: Trac Migrate
2022-04-05T18:03:54.000Z
In [changeset:”725101151c959f268819348f2abf2c6e7f66c0c4/rtems” 72510115/rtems]:
testsuites/sptests/sp0*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-05T18:03:56.000Z
In [changeset:”eb579662e4a0d0c7f7afeffaf81c9f0db3f178d8/rtems” eb57966/rtems]:
testsuites/sptests/sp1*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-05T18:03:59.000Z
In [changeset:”d987a57be4754e7fcc33190a460ce99684530d8f/rtems” d987a57/rtems]:
testsuites/sptests/sp[None..None](../compare/None...None)*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-05T18:04:01.000Z
In [changeset:”c50bb51b1925177f41b13151bc443a39622eeb67/rtems” c50bb51/rtems]:
testsuites/sptests/sp[None..None](../compare/None...None)*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-05T18:04:03.000Z
In [changeset:”e7d46b738cd5358bdf21ea9f8c10c6a40d0b7d4d/rtems” e7d46b73/rtems]:
testsuites/sptests/sp[a-f*]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-05T18:04:06.000Z
In [changeset:”0473b2b36a7a43058cffc9a47cc4dd07b03f82cb/rtems” 0473b2b3/rtems]:
testsuites/sptests/sp[g-r]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-05T18:04:08.000Z
In [changeset:”d865c65efe78303e488be0f2d3124336fcbb4c50/rtems” d865c65/rtems]:
testsuites/sptests/sp[s-z]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-05T18:04:11.000Z
In [changeset:”ce8d47be726e82b9f26bf163ccf70708135c5a96/rtems” ce8d47b/rtems]:
testsuites/sptests/sp[None..None](../compare/None...None)*/*.doc: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-05T18:04:13.000Z
In [changeset:”df6a7e0a1d02673502cf81e19745289a05ad97ab/rtems” df6a7e0/rtems]:
testsuites/sptests/sp[a-h]*/*.doc: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-05T18:04:16.000Z
In [changeset:”3ed59872de94d7721deca11150e944651ad61290/rtems” 3ed5987/rtems]:
testsuites/sptests/sp[i-z]*/*.doc: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-06T22:04:29.000Z
I grant permission to the RTEMS Foundation to relicense my current and future contributions from the current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License.
Author: Trac Migrate
2022-04-07T13:29:11.000Z
In [changeset:”42d4ebe1a5111d12d38d6357f37ed9a249ef0984/rtems” 42d4ebe/rtems]:
testsuites/mptests/*: Change license to BSD-2. Updates #3053.
Author: Trac Migrate
2022-04-07T13:29:14.000Z
In [changeset:”b331f409a84f1bd8b54dcaea12411949cb9bee7e/rtems” b331f40/rtems]:
testsuites/tmtests/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-07T13:29:16.000Z
In [changeset:”85cc173d6e74fe539ace5f3bfe1c7e17c9ab3bf5/rtems” 85cc173/rtems]:
testsuites/libtests/[a-c]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-07T13:29:19.000Z
In [changeset:”366711fcfaff10eea66052bad2d59909e80c7e7b/rtems” 366711f/rtems]:
testsuites/libtests/dl*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-07T13:29:22.000Z
In [changeset:”1ef07d462094e0bd3939fc3737d323c0aac28c4d/rtems” 1ef07d46/rtems]:
testsuites/libtests/[d-o]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-07T13:29:24.000Z
In [changeset:”acceb478ecafdaa45cd0281aa307af6a0dce8a56/rtems” acceb47/rtems]:
testsuites/libtests/[p-z]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-07T13:29:26.000Z
In [changeset:”e2ffe959c5fae1b45fc4ad273dd9977335f1f014/rtems” e2ffe95/rtems]:
testsuites/fstests/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-07T13:29:28.000Z
In [changeset:”74e532f1f67ed69fdb40d61159e4489fa34244ef/rtems” 74e532f/rtems]:
testsuites/smptests/*: Change license to BSD-2 Updates #3053.
Author: Joel Sherrill
2022-04-08T17:21:52.000Z
Attachment `TillStraumann-Permission.pdf <TillStraumann-Permission.pdf>`_(/assets/tracmigration/ticket_attachments/TillStraumann-Permission.pdf) added
Permission email from Till Straumann
Author: Trac Migrate
2022-04-08T21:35:17.000Z
I grant permission to the RTEMS Foundation to relicense my current and future contributions from the current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License.
Author: Trac Migrate
2022-04-09T16:52:12.000Z
I grant permission to the RTEMS Foundation to relicense my current and future contributions to the RTEMS public source to be relicensed to the 2-Clause BSD License.
Eshan Dhawan
Author: Trac Migrate
2022-04-09T22:32:22.000Z
I grant permission to the RTEMS Foundation to relicense my current and future contributions from the current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License.
Author: Trac Migrate
2022-04-12T18:32:18.000Z
In [changeset:”8d5eb7eba58f8a407e385e5d6b48dd3425f88f3d/rtems” 8d5eb7e/rtems]:
testsuites/ada/support/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:21.000Z
In [changeset:”28052b744b402a1e36e5ab3b255189b72e795f97/rtems” 28052b7/rtems]:
testsuites/ada/samples/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:24.000Z
In [changeset:”2df35d7e4dd01d5aa53e4d3cf3efe6bd23030c56/rtems” 2df35d7/rtems]:
testsuites/ada/sptests/sp0*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:26.000Z
In [changeset:”3d8f2a55a5a9a7969cf8371401823f0e8200f3ee/rtems” 3d8f2a5/rtems]:
testsuites/ada/sptests/sp1*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:28.000Z
In [changeset:”a767a2bacbf344898b82be658c387e3323e9b97d/rtems” a767a2b/rtems]:
testsuites/ada/sptests/sp2*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:31.000Z
In [changeset:”20cec598c68ea1715ca37e26ebd6ce855cbc6f96/rtems” 20cec598/rtems]:
testsuites/ada/sptests/spatcb01, spname01: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:33.000Z
In [changeset:”37426caa67362f74117a8cf7d13760d064d2d9d2/rtems” 37426ca/rtems]:
testsuites/ada/tmtests/tm1*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:35.000Z
In [changeset:”61ac3ab09cd48e75236d53a9fed18f6161ef0217/rtems” 61ac3ab/rtems]:
testsuites/ada/tmtests/tm0*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:37.000Z
In [changeset:”2bf4acfc5081dc6c48d61667a9afc0e8f68fbf24/rtems” 2bf4acfc/rtems]:
testsuites/ada/tmtests/tm2*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:40.000Z
In [changeset:”b6656a0078a78384f044aeb0321eac015f517811/rtems” b6656a00/rtems]:
testsuites/ada/tmtests/tmck: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:42.000Z
In [changeset:”2c292f3ff903ae0a632a8a5d2fa73151266c62cc/rtems” 2c292f3/rtems]:
testsuites/ada/mptests/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:45.000Z
In [changeset:”e19e650f31548971d693972b570932a37c467b76/rtems” e19e650/rtems]:
testsuites/benchmarks/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:47.000Z
In [changeset:”ef9df16afaf8e1c12afdf253c5fca735c359ce2c/rtems” ef9df16a/rtems]:
testsuites/rmtests/tm[01]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:49.000Z
In [changeset:”2c1d928fdc40d373724305c91b0d5e2927191167/rtems” 2c1d928/rtems]:
testsuites/tmtests/tm[23]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:52.000Z
In [changeset:”04b6c51e0182a4dfd0c50f7ca2309f45b6e952fe/rtems” 04b6c51/rtems]:
testsuites/tmtests/ remainder: Change license to BSD-2 + include + tmck + tmfine01 + tmonetoone + tmtimer01 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:54.000Z
In [changeset:”194d9ca5d2ef5acb5e9eb44a5fb50135c6cbd13b/rtems” 194d9ca5/rtems]:
testsuites/tmtests/*/*.py: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:56.000Z
In [changeset:”e0d673639b3bd145c35725d5b3d5510111d1af14/rtems” e0d6736/rtems]:
testsuites/support/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:32:58.000Z
In [changeset:”33078a2bfb7b58fc44e791530bb176b031b8c5b4/rtems” 33078a2/rtems]:
testsuites/libtests/[a-l]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:01.000Z
In [changeset:”52a67757ef58ec63bc2c9c78b876640fc9aa7d7d/rtems” 52a67757/rtems]:
testsuites/libtests/[m-z]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:03.000Z
In [changeset:”d1c10d6a1e6ed60c2904342b925e15761536ba8e/rtems” d1c10d6/rtems]:
testsuites/libtests/*/*.dts. stackchk02.doc: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:05.000Z
In [changeset:”6d410fe86b49802683a249f2e6e978868f84cb13/rtems” 6d410fe8/rtems]:
testsuites/fstests/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:08.000Z
In [changeset:”e8878d48154e8f87fdf7a631214529d775c8a33d/rtems” e8878d4/rtems]:
fstests/fsdosfsname01/create_image.sh: Manually change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:10.000Z
In [changeset:”a3610bb9245796fc971827564a26c74ef28338da/rtems” a3610bb/rtems]:
testsuites/psxtests/psx[01]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:12.000Z
In [changeset:”ede291588a0ca35ae1b17de21a743fc60ccc1135/rtems” ede29158/rtems]:
testsuites/psxtests/psx[a-f]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:15.000Z
In [changeset:”9e07bccac2ee694a29e9a1b81640b2785dd31a05/rtems” 9e07bcc/rtems]:
testsuites/psxtests/psx[g-m1]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:17.000Z
In [changeset:”5594854647bfe5d3c6d50c62c226abd05a58ca01/rtems” 5594854/rtems]:
testsuites/psxtests/psx[n-z]*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:19.000Z
In [changeset:”ecdac5988aefce2474f0adebabef16c24c1db23a/rtems” ecdac598/rtems]:
testsuites/psxtests/include: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:21.000Z
In [changeset:”94fa540cc2e5fb89231850bac9d49a7de38636ec/rtems” 94fa540/rtems]:
testsuites/psxtmtests: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:24.000Z
In [changeset:”ab9faf9a6fe8ae8d1978e5ad66bd73a2150a1c06/rtems” ab9faf9/rtems]:
testsuites/psxtests/psxhdrs/devctl/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:26.000Z
In [changeset:”9e6b2a9c8310c5c2843e8f11aa8658a859f0b691/rtems” 9e6b2a9/rtems]:
testsuites/psxtests/psxhdrs/pthread/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:28.000Z
In [changeset:”7f209b98413db2065bfcf77a1dc01b991dacb695/rtems” 7f209b98/rtems]:
testsuites/psxtests/psxhdrs/sched/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:30.000Z
In [changeset:”7f78f064fbd1a49c3934fb2dd4a001defb3e9616/rtems” 7f78f06/rtems]:
testsuites/psxtests/psxhdrs/signal*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:33.000Z
In [changeset:”e1448e979088cf5c4dd239f3beae19cbcc1ee357/rtems” e1448e9/rtems]:
testsuites/psxtests/psxhdrs/sys/mman/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:35.000Z
In [changeset:”15db02f6cc84dfc8436c1f3ae61382d6c1317cf8/rtems” 15db02f6/rtems]:
testsuites/psxtests/psxhdrs/sys/socket/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:37.000Z
In [changeset:”88b6293a639ff213acc79940e803508380ddd58e/rtems” 88b6293a/rtems]:
testsuites/psxtests/psxhdrs/time/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:40.000Z
In [changeset:”3f5d8c9c5656ce964847b36ff815fce75fb7f79d/rtems” 3f5d8c9c/rtems]:
testsuites/psxtests/psxhdrs/unistd/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:42.000Z
In [changeset:”e71f09094f6628a2ad2aa82f242e46cae2badde6/rtems” e71f0909/rtems]:
testsuites/samples: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-04-12T18:33:46.000Z
In [changeset:”842a7dd8133dcc37fdf3b45ac2a2df5e2268dbf6/rtems” 842a7dd8/rtems]:
psxtmtests/psxtmkey02/init.c: Manually change license to BSD-2 This has yet another typo in the license and was missed by the script. Updates #3053.
Author: Trac Migrate
2022-05-08T05:35:58.000Z
I grant permission to the RTEMS Foundation to relicense my current and future contributions from the current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License.
Author: Trac Migrate
2022-05-18T09:30:18.000Z
In [changeset:”be580201dde028a5981fe98ca9d313ade4ae22f0/rtems” be580201/rtems]:
bsps: Relicense <bsp/default-initial-extension.h> Replace Doxygen documentation. Change license to BSD-2-Clause according to file history. Update #3053.
Author: Trac Migrate
2022-05-18T09:30:20.000Z
In [changeset:”6476cdc67c3353dba717e30f78f1a4cf4f9e3805/rtems” 6476cdc/rtems]:
bsps: Relicense <bsp/fatal.h> Add Doxygen documentation. Change license to BSD-2-Clause according to file history. Update #3053.
Author: Trac Migrate
2022-05-18T09:30:23.000Z
In [changeset:”93800e09d7d88bbd5a6b878d8df9bcd1f6e2fa05/rtems” 93800e0/rtems]:
rtems: Relicense rtemsmaxprio.c Change license to BSD-2-Clause according to file history. Update #3053.
Author: Trac Migrate
2022-05-18T09:30:25.000Z
In [changeset:”89c498ccdae67ae817f8a141183b771948a817b9/rtems” 89c498c/rtems]:
score: Add SPDX License Identifier Remove URL in copyright notice. Update #3053.
Author: Trac Migrate
2022-06-14T15:25:58.000Z
In [changeset:”f98b7391192bbe0a5e26bc05f310d160d4903b44/rtems” f98b739/rtems]:
smptests/*/*.py: Change license to BSD-2 Manually adjusted location of SPDX annotation so #! remains first line. Updates #3053.
Author: Trac Migrate
2022-06-14T15:26:00.000Z
In [changeset:”731607b3b3ae58761addaaf9386bcba7d471a989/rtems” 731607b3/rtems]:
samples/*/*.doc: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-06-14T15:26:02.000Z
In [changeset:”dcbba7c0e6d9fb61ad1b5934dbba35aaf3e78d06/rtems” dcbba7c/rtems]:
psxtmtests/*/*.doc: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-06-14T15:26:05.000Z
In [changeset:”031f8fbcdcae508e2183a9eab79099dba5e1e1f2/rtems” 031f8fbc/rtems]:
smptests/*/*.doc: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-06-14T15:26:07.000Z
In [changeset:”7c6ff958e924464948e61ea31fc00f7dfc94bd8e/rtems” 7c6ff95/rtems]:
mptests/*/*.doc: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-06-14T15:26:09.000Z
In [changeset:”59a79edb9530d663f4f8baabdce055428f44cf18/rtems” 59a79ed/rtems]:
sptests/*/*.doc: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-06-14T15:26:12.000Z
In [changeset:”3a22252782bd974dc53f2fee797ac7085d5688f7/rtems” 3a222527/rtems]:
samples/iostream/init.cc: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-06-14T15:26:14.000Z
In [changeset:”1f23640a9b5c1897b221ef6ace6a58dd3a11825a/rtems” 1f23640/rtems]:
sptests/spglobalcon01/init.cc: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-06-15T17:29:25.000Z
In [changeset:”d6ebf4067e9525f6dbe18a50e537c99bdf75bbff/rtems” d6ebf40/rtems]:
bsps/shared/*: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-08T13:36:05.000Z
In [changeset:”8ca4b5c8bb24eac79fc190b71ae57979b15e2106/rtems” 8ca4b5c/rtems]:
bsps/arm/shared: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-08T13:36:07.000Z
In [changeset:”9e0244e95f4b1d890501c6de5ad87bc3c0417902/rtems” 9e0244e/rtems]:
bsps/arm/altera-cyclone-v: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-08T13:36:09.000Z
In [changeset:”6fc04f4cfd42e6960f1f763a1697aea1813cbe8c/rtems” 6fc04f4c/rtems]:
bsps/arm/atsamv: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-08T13:36:12.000Z
In [changeset:”b1cc3dd07e231ac097f50f0a94396954ca4970df/rtems” b1cc3dd0/rtems]:
bsps/arm/beagle: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-08T13:36:14.000Z
In [changeset:”65054595658b8b483411141eaecef53ce2cb0722/rtems” 65054595/rtems]:
bsps/arm/csb337: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-08T13:36:16.000Z
In [changeset:”df50266c6abcd5f77bd69244d40105df541edfe6/rtems” df50266/rtems]:
bsps/arm/imx: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-08T13:36:19.000Z
In [changeset:”03cb6e819c90852ca857269fcaf2dce2d21bfa9a/rtems” 03cb6e81/rtems]:
bsps/arm/include: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-08T13:36:21.000Z
In [changeset:”c519d4589b97062b9725bf80679d08963f84080c/rtems” c519d458/rtems]:
bsps/arm/lpc176x: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-08T13:36:23.000Z
In [changeset:”d42276615c273c53890037499242a78bf4ba4a45/rtems” d4227661/rtems]:
bsps/arm/imxrt: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-08T13:36:26.000Z
In [changeset:”445ddb31ef132dfe1f6af00e58b71a97510b9a9c/rtems” 445ddb3/rtems]:
bsps/arm/lpc24xx: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-08T13:36:29.000Z
In [changeset:”f3237b3186bdf4f2f5f7b2ff749d947e5c147207/rtems” f3237b31/rtems]:
bsps/arm/lpc32xx: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-08T13:36:31.000Z
In [changeset:”f6e9e89729a9fde615d079f77f91cd4c371347b6/rtems” f6e9e89/rtems]:
bsps/arm/raspberrypi: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-08T13:36:33.000Z
In [changeset:”00e0fb916ed5ca54c3d7ecb0de63490e61caff84/rtems” 00e0fb9/rtems]:
bsps/arm/realview-pbx-a9: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-08T16:13:30.000Z
Attachment CG-BSD2-relicensing.pdf added
Cobham Gaisler BSD-2 relicensing
Author: Trac Migrate
2022-07-08T16:17:28.000Z
Cobham Gaisler grant permission for the relicensing to BSD-2 according to the signed document attached to the thread: https://devel.rtems.org/attachment/ticket/3053/CG-BSD2-relicensing.pdf
Author: Trac Migrate
2022-07-11T22:07:34.000Z
In [changeset:”a52aa5b43feb8ebec1336025ffc59a7c8045b517/rtems” a52aa5b4/rtems]:
bsps/i386/pc386: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:07:36.000Z
In [changeset:”c1b1c0fa6c3231465a40dbaa5ca3be536974eccc/rtems” c1b1c0fa/rtems]:
bsps/i386/shared/pci/pci_io.c:Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:07:38.000Z
In [changeset:”5e8ec6356104bb0f8b506fdf58bd86ad09174c16/rtems” 5e8ec63/rtems]:
bsps/include: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:07:41.000Z
In [changeset:”2c48b89cb0c59aee7824c48809fceb647a0a3a66/rtems” 2c48b89c/rtems]:
bsps/lm32/include: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:07:43.000Z
In [changeset:”1670bb2ddd971d5d905afc64830bd369c8020a5e/rtems” 1670bb2d/rtems]:
bsps/lm32/lm32_evr: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:07:46.000Z
In [changeset:”2b87d7c5d8a444ffebc0065f632345e1e7c0d5d4/rtems” 2b87d7c5/rtems]:
bsps/lm32/shared: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:07:48.000Z
In [changeset:”cb4fdffe1643980f52577ffbaf13a1560b689c72/rtems” cb4fdff/rtems]:
m68k/bsps/av5282: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:07:50.000Z
In [changeset:”bdd4f6dcbc9fc75930863c3154afa7191e3cb860/rtems” bdd4f6dc/rtems]:
bsps/m68k/csv360: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:07:53.000Z
In [changeset:”f888837dd6826b8a40a6af04e682be67e564696e/rtems” f888837/rtems]:
bsps/m68k/gen68340: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:07:55.000Z
In [changeset:”cfadeccbfce957aa7cfd7626628abfd6cdba2955/rtems” cfadeccb/rtems]:
bsps/m68k/gen68360: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:07:57.000Z
In [changeset:”810bdeb34a3bff58a19bcc90d23afcd420f3512b/rtems” 810bdeb/rtems]:
bsps/m68k/genmcf548x: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:08:00.000Z
In [changeset:”62f31d05e5026d580d6f1fe85470d3e47620a911/rtems” 62f31d05/rtems]:
bsps/m68k/include: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:08:02.000Z
In [changeset:”5382615860fb8c5ada1dcbeb55982305328e1eed/rtems” 53826158/rtems]:
bsps/m68k/mcf5206elite: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:08:05.000Z
In [changeset:”8cc14e5a5e9db41ba800d81ce184b6cf5c872f3e/rtems” 8cc14e5/rtems]:
bsps/m68k/mcf52235: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:08:07.000Z
In [changeset:”eb7b866f51f7b49be09ffe9583db420cc1edcdd2/rtems” eb7b866/rtems]:
bsps/m68k/mcf5225x: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:08:09.000Z
In [changeset:”e50bdda22ca95126e2042f6950c1c79d499d0e07/rtems” e50bdda2/rtems]:
bsps/m68k/mvf5235: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:08:12.000Z
In [changeset:”c46ec2b497e2d2bf754eb46bd5d319f47317aa36/rtems” c46ec2b/rtems]:
bsps/m68k/mcf5329: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:08:14.000Z
In [changeset:”35cfe737408ccfdc82453aa88bb0c913ab237463/rtems” 35cfe73/rtems]:
bsps/m68k/mrm332: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:08:17.000Z
In [changeset:”b4c3de78ea5058815f2f6d0f5d98c68b3063d4b3/rtems” b4c3de7/rtems]:
bsps/m68k/mvme147: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:08:19.000Z
In [changeset:”c669338a7e806e9a6c8ce527230279bdfcea4d68/rtems” c669338a/rtems]:
bsps/m68k/mvme147s: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:08:21.000Z
In [changeset:”c1137c7f04c715e03d940a01dc80d553301fff5b/rtems” c1137c7/rtems]:
bsps/m68k/mvme162: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:08:23.000Z
In [changeset:”a9a99164719454aefd8b3c3bc7066c4d4f8186c1/rtems” a9a99164/rtems]:
bsps/m68k/shared: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-11T22:08:26.000Z
In [changeset:”1be68d80932c28c697a703f3382c949d6f0338de/rtems” 1be68d8/rtems]:
bsps/m68k/uC5282: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:05.000Z
In [changeset:”96a4b8c4942ccab1ecec8be911c7d899d84e8bdc/rtems” 96a4b8c/rtems]:
bsps/mips/shared: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:08.000Z
In [changeset:”5806ba0f5646088249048f8db67b1d0402d6e1d4/rtems” 5806ba0/rtems]:
bsps/mips/csb350: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:10.000Z
In [changeset:”334d90e324f916156e83fd19c5b1c3e0b364f1bd/rtems” 334d90e3/rtems]:
bsps/mips/hurricane: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:13.000Z
In [changeset:”654ff835bbed4b2716cdbde224136d40aec98e74/rtems” 654ff835/rtems]:
bsps/mips/include: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:15.000Z
In [changeset:”d1dcf24924706775473684ac483f7f45535cd950/rtems” d1dcf24/rtems]:
bsps/mips/jmr3904: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:17.000Z
In [changeset:”36be074d3640ba0f7d8637ceebc3d4b8e1cc1dc9/rtems” 36be074/rtems]:
bsps/mips/malta: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:19.000Z
In [changeset:”01c5b57d3905e191000fa9819a2bb37b6f769a6e/rtems” 01c5b57d/rtems]:
bsps/mips/rbtx4925: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:22.000Z
In [changeset:”fdda5dfe417f82cec7c9c4b6d1ea028b778d4e6d/rtems” fdda5dfe/rtems]:
bsps/mips/rbtx4938: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:24.000Z
In [changeset:”78a63729fadc355d8d3e7c95277f3370316aec15/rtems” 78a6372/rtems]:
bsps/moxie/moxiesim: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:27.000Z
In [changeset:”5ee313155dc47c49269c9b826d330e550b6fe3ad/rtems” 5ee3131/rtems]:
bsps/nios2/nios2_iss: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:29.000Z
In [changeset:”a3571e39fa9817822534e5c84ed90716bf07cdaa/rtems” a3571e39/rtems]:
bsps/no_cpu/no_bsp: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:31.000Z
In [changeset:”d9d2cdff213b244b315b79d953edfe690f8d1ff3/rtems” d9d2cdf/rtems]:
bsps/powerpc/beatnik: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:34.000Z
In [changeset:”a965590d648b77433de0978d1d88b80538e1e7c4/rtems” a965590d/rtems]:
bsps/powerpc/gen5200: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:36.000Z
In [changeset:”fe8b4b6c79ce47d2dc7703286dbb2689ec986c0e/rtems” fe8b4b6c/rtems]:
bsps/powerpc/83xx: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:38.000Z
In [changeset:”5ba0bb2afd25a2812a5abccc9df8ccd3aeb1f462/rtems” 5ba0bb2a/rtems]:
bsps/powerpc/include: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:41.000Z
In [changeset:”bc374cd7a5803adc1ca481dce4312b785f4c49fe/rtems” bc374cd/rtems]:
bsps/powerpc/mpc55xxevb: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:43.000Z
In [changeset:”88cf40e63c4c4cad72a27d072563a87f2ff60147/rtems” 88cf40e6/rtems]:
bsps/powerpc/mpc8260ads: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:45.000Z
In [changeset:”5aea703542a25e117776b6bf8ba36528a02b7c85/rtems” 5aea7035/rtems]:
bsps/powerpc/psim: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:47.000Z
In [changeset:”a29b9bb4dd41d0926ea294f1435d4900438bd4ad/rtems” a29b9bb4/rtems]:
bsps/powerpc/qemuppc: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:50.000Z
In [changeset:”8f4878ae1f3c47b98ade2c6b87f0f78378c7efeb/rtems” 8f4878ae/rtems]:
bsps/powerpc/qoriq: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:52.000Z
In [changeset:”9375d24dc8302f9f9458232419325426ee2fec04/rtems” 9375d24/rtems]:
bsps/powerpc/shared: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:55.000Z
In [changeset:”a1fb8b7edb86dab354a4e78917039ea924fba68d/rtems” a1fb8b7/rtems]:
bsps/powerpc/t32mppc: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:57.000Z
In [changeset:”22d861ab9a8799dc861682fb8f37555ab8a36d8c/rtems” 22d861a/rtems]:
bsps/powerpc/tqm8xx: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:40:59.000Z
In [changeset:”77f1ae05dd2f8785feac5d653a2a7353c61e9bf0/rtems” 77f1ae0/rtems]:
bsps/powerpc/virtex: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:41:02.000Z
In [changeset:”8a41efe42427c0bdb33c33dad88c8a6446eeaaf0/rtems” 8a41efe4/rtems]:
bsps/powerpc/virtex4: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:41:04.000Z
In [changeset:”a73615a948081a331aee0c89633a6cb8856fae5d/rtems” a73615a9/rtems]:
bsps/powerpc/virtex5: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:41:06.000Z
In [changeset:”0fc7a4499cce46a090d89d97f526e03cdb42d1fa/rtems” 0fc7a44/rtems]:
bsps/sh/gensh1: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:41:09.000Z
In [changeset:”aacf9e23fbd11d776a3e3a685d1642b98363dedd/rtems” aacf9e2/rtems]:
bsps/sh/gensh2: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:41:11.000Z
In [changeset:”00913bb163bff6789ba5016091c71985116822c0/rtems” 00913bb1/rtems]:
bsps/sh/shared: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:41:13.000Z
In [changeset:”f436fc7a18396fbc033ef5dabb63741aa3d0280e/rtems” f436fc7/rtems]:
bsps/sh/shsim: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:41:16.000Z
In [changeset:”749e9b63bd9b4667503a6186b93f639cbfae7749/rtems” 749e9b63/rtems]:
bsps/sparc64/include: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:41:18.000Z
In [changeset:”a49acb6bef31fcbfe8da7901949fcc16900ec64a/rtems” a49acb6b/rtems]:
bsps/sparc64/niagara: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:41:20.000Z
In [changeset:”ae71cf38ebf4dfdf1ff4b61035a3618bea881ef9/rtems” ae71cf38/rtems]:
bsps/sparc64/shared: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:41:23.000Z
In [changeset:”c1008e9da1b0da9b862d3915fe566e75fbb3fc52/rtems” c1008e9d/rtems]:
bsps/sparc64/usiii: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-07-12T16:41:25.000Z
In [changeset:”405639a67d846960bb15c04ee898554228988758/rtems” 405639a6/rtems]:
bsps/v850/gdbv850sim: Change license to BSD-2 Updates #3053.
Author: Trac Migrate
2022-11-15T16:54:31.000Z
In [changeset:”33f6e34b2d5cefff41e7dbdb98dd1d4ad40e5c74/rtems” 33f6e34/rtems]:
bsps/include/grlib: Change license to BSD-2 for files with Gaisler copyright This patch changes the license to BSD-2 for all source files where the copyright is held by Aeroflex Gaisler, Cobham Gaisler, or Gaisler Research. Some files also includes copyright right statements from OAR and/or embedded Brains in addition to Gaisler. Updates #3053.
Author: Trac Migrate
2022-11-15T16:54:33.000Z
In [changeset:”5d5b9eeb0845a9824fab55c8881ba15b43559d77/rtems” 5d5b9ee/rtems]:
bsps/shared/grlib: Change license to BSD-2 for files with Gaisler copyright This patch changes the license to BSD-2 for all source files where the copyright is held by Aeroflex Gaisler, Cobham Gaisler, or Gaisler Research. Some files also includes copyright right statements from OAR and/or embedded Brains in addition to Gaisler. Updates #3053.
Author: Trac Migrate
2022-11-15T16:54:35.000Z
In [changeset:”e01e499490fa651074f8c48114fa5b7f4eb6ff93/rtems” e01e499/rtems]:
bsps/sparc: Change license to BSD-2 for files with Gaisler copyright This patch changes the license to BSD-2 for all source files where the copyright is held by Aeroflex Gaisler, Cobham Gaisler, or Gaisler Research. Some files also includes copyright right statements from OAR and/or embedded Brains in addition to Gaisler. Updates #3053.
Author: Trac Migrate
2022-11-15T16:54:38.000Z
In [changeset:”18a181c267f0249d7310809c45559fb347cdf577/rtems” 18a181c2/rtems]:
bsps/riscv: Change license to BSD-2 for files with Gaisler copyright This patch changes the license to BSD-2 for all source files where the copyright is held by Aeroflex Gaisler, Cobham Gaisler, or Gaisler Research. Some files also includes copyright right statements from OAR and/or embedded Brains in addition to Gaisler. Updates #3053.
Author: Trac Migrate
2022-11-15T16:54:40.000Z
In [changeset:”9384ac2d65da4cab43369d0c4fd626ae67e1d833/rtems” 9384ac2/rtems]:
cpukit: Change license to BSD-2 for files with Gaisler copyright This patch changes the license to BSD-2 for all source files where the copyright is held by Aeroflex Gaisler, Cobham Gaisler, or Gaisler Research. Some files also includes copyright right statements from OAR and/or embedded Brains in addition to Gaisler. Updates #3053.
Author: Trac Migrate
2022-11-15T16:54:42.000Z
In [changeset:”3f644aa874e3a67191c9755f6251f8b6b0fa037d/rtems” 3f644aa/rtems]:
testsuites/smptests: Change license to BSD-2 for files with Gaisler copyright This patch changes the license to BSD-2 for all source files where the copyright is held by Aeroflex Gaisler, Cobham Gaisler, or Gaisler Research. Updates #3053.
Author: Trac Migrate
2023-12-12T21:42:48.000Z
I grant permission to the RTEMS Project to relicense my current and future contributions to the RTEMS public source to be relicensed to the 2-Clause BSD License.
Přemysl Houdek
Author: Trac Migrate
2024-01-15T09:36:58.000Z
In [changeset:”8e8b9bc0b727c9d35b3ac1ef27f90b2f81aefb4c/rtems” 8e8b9bc0/rtems]:
bsp/tms570: Relicense to BSD-2-Clause Change license to BSD-2-Clause according to file history and contributor agreements. Add Doxygen file comments. Update #3053. Update #3707. Update #4982.
Author: Chris Johns
2024-05-23T23:46:44.916Z
Attach a PDF print of the Trac ticket to record the names. These were lost in the move to Gitlab.
Author: Joel Sherrill
2024-05-28T20:47:42.267Z
mentioned in merge request !52
Author: Joel Sherrill
2024-06-07T14:57:06.117Z
Tony Bennett has given permission. Attached is a PDF of his email.
Author: Joel Sherrill
2025-01-22T23:26:42.210Z
mentioned in issue rtems-examples#7
Author: Gedare Bloom
2025-01-28T00:48:47.491Z
mentioned in issue rtems/websites/www.rtems.org#4
Author: Gedare Bloom
2025-02-01T06:19:37.084Z
mentioned in merge request !376
Author: Gedare Bloom
2025-02-02T01:28:43.571Z
mentioned in merge request !380
Author: Gedare Bloom
2025-02-03T22:57:30.665Z
mentioned in merge request !382
Author: Gedare Bloom
2025-02-03T23:29:10.329Z
mentioned in merge request !383
Author: Gedare Bloom
2025-02-04T00:03:43.057Z
mentioned in merge request !385
Author: Gedare Bloom
2025-02-04T00:16:16.931Z
mentioned in merge request !386
Author: Eric Valette
2025-02-04T08:57:29.388Z
“I grant permission to the RTEMS Foundation to relicense my current and future contributions from the current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License.”
I, however, kindly request to keep an email for attribution and change existing one to a correct email address like the one used in my gitlab account profile.
Author: Andrew Dachs
2025-02-09T20:21:35.600Z
I grant permission to the RTEMS Foundation to relicense my current and future contributions from the current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License.
Author: Gedare Bloom
2025-02-09T23:39:56.419Z
mentioned in merge request !408
Author: Joel Sherrill
2025-02-12T02:34:42.805Z
mentioned in issue rtems/websites/www.rtems.org#8
Author: Joel Sherrill
2025-02-28T18:31:09.167Z
mentioned in merge request !437
Author: Joel Sherrill
2025-03-11T22:50:01.226Z
mentioned in merge request !448
Author: Joel Sherrill
2025-03-12T22:25:06.768Z
mentioned in merge request !449
Author: Joel Sherrill
2025-03-12T22:32:55.861Z
mentioned in merge request !450
Author: Joel Sherrill
2025-03-13T18:46:00.581Z
mentioned in merge request !451
Author: Joel Sherrill
2025-03-18T19:47:56.868Z
mentioned in merge request !455
Author: Joel Sherrill
2025-03-18T20:20:08.453Z
mentioned in merge request !456
Author: Chirayu Desai
2025-08-21T23:01:02.285Z
I grant permission to the RTEMS Foundation to relicense my current and future contributions from the current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License.
Author: Joel Sherrill
2025-08-22T14:18:06.244Z
mentioned in merge request !685
Author: Gedare Bloom
2025-08-22T16:06:13.259Z
mentioned in merge request !686
Author: Joel Sherrill
2025-09-03T22:37:31.847Z
mentioned in merge request !702
Author: Amar Takhar
2025-09-05T02:53:07.769Z
changed the description
Author: Amar Takhar
2025-09-05T02:55:29.595Z
mentioned in issue #3899
Author: Joel Sherrill
2025-09-08T14:48:45.884Z
Ray Xu <rayx.cn@gmail.com> gave permission via email to @joel and @gedare. PDF of permission attached.
Author: Joel Sherrill
2025-09-08T17:01:11.448Z
mentioned in merge request !710
Author: John Gwynne
2025-09-08T21:16:17.388Z
I grant permission to the RTEMS Foundation to relicense my current and future contributions from the current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License.
John Gwynne
Author: Joel Sherrill
2025-09-08T21:50:19.748Z
mentioned in merge request !713
Author: Joel Sherrill
2025-09-10T18:31:22.448Z
Claas Ziemke <claas.ziemke@gmx.net> gave permission via email to @joel and @gedare. PDF of permission attached.
Author: Joel Sherrill
2025-09-10T18:47:09.138Z
Ric Claus’ permission grant did not show up when I searched earlier. Adding the email he forwarded which clearly indicates he gave permission in 2022 before the conversion to GitLab.
Re___RTEMS_Project___3053__Change_RTEMS_License_to_Two_Paragraph_BSD.eml
Author: Amar Takhar
2025-09-10T18:47:09.088Z
Look here for the PDF it’s in there: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3053#note_106221
Author: Amar Takhar
2025-09-10T18:48:33.441Z
This PDF is a snapshot of the original trac page so use that if something doesn’t show up here. It appears to be this comment: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3053#note_93669
Author: Joel Sherrill
2025-09-10T18:50:57.469Z
Thanks. Important to check both. This has been going on a LONG time. :(
Author: Joel Sherrill
2025-09-11T15:06:32.506Z
mentioned in merge request !717
Author: Joel Sherrill
2025-09-11T23:15:43.443Z
mentioned in merge request !718
Author: Joel Sherrill
2025-09-12T14:07:10.244Z
mentioned in merge request !723
Author: Joel Sherrill
2025-09-12T14:49:09.574Z
mentioned in merge request !724
Author: Joel Sherrill
2025-09-15T16:21:47.649Z
mentioned in commit 600b76286e96369d8d34bd4d091d64d322b27c76
Author: Joel Sherrill
2025-09-17T23:27:21.101Z
Wei Shen <cquark@gmail.com> has given permission to relicense their submissions.
WeiShen-PermissiontoRelicenseRTEMSSubmissions.pdf
They also would like to have their email changed in comments to <jshen.yn@gmail.com> which is associated with their github account `jianjuns <https://github.com/jianjuns>`_(Jianjun Shen).
Author: Joel Sherrill
2025-09-18T14:28:20.464Z
mentioned in merge request !729
Author: Chris Johns
2025-09-19T01:03:48.699Z
mentioned in issue #4625
Author: Alan Cudmore
2025-09-25T13:02:31.499Z
I grant permission to the RTEMS Foundation to relicense my current and future contributions from the current license GPLv2 plus exception to the RTEMS license becoming the 2-Clause BSD License.
Alan Cudmore
Author: Joel Sherrill
2025-09-27T14:56:24.275Z
mentioned in merge request !756
Author: Joel Sherrill
2025-10-06T21:57:44.797Z
mentioned in merge request !768
Author: Kinsey Moore
2025-10-08T16:39:29.848Z
mentioned in commit e91ace80f111b0a0284941deeccb133d424e74c5
Author: Joel Sherrill
2025-10-10T20:35:37.409Z
Permission receive from Matthew Riek. PDF attached.
Author: Joel Sherrill
2026-01-14T20:31:37.200Z
mentioned in merge request !909
Author: Joel Sherrill
2026-01-16T21:51:31.365Z
mentioned in merge request !919
Author: Joel Sherrill
2026-02-02T20:42:43.756Z
mentioned in merge request !984
Author: Gedare Bloom
2026-02-04T18:01:56.982Z
mentioned in merge request !1015
3034 - Convert all serial device drivers to use the new Termios device API (opened)¶
Id |
3034 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-06-08T08:30:17.000Z |
Updated |
2025-09-19T01:46:13.767Z |
Milestone |
5.4 |
Labels |
bsp, old-indefinite, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The new Termios device API is documented here:
https://docs.rtems.org/branches/master/bsp-howto/console.html
Legacy drivers can be found via the rtems_termios_open() function.
Author: Trac Migrate
2018-09-12T09:45:49.000Z
Original author: sebastian.huber
Owner set to sebastian.huber
Status changed from new to accepted
Author: Trac Migrate
2020-01-07T17:24:34.000Z
Original author: sebastian.huber
In [changeset:”362cf319d44e7e64987f12aa36ea030e6298c586/rtems” 362cf319/rtems]:
bsp/raspberrypi: Updated the console API. Replaces the legacy termios API with new termios API (#3034) Replaces the custom PL011 serial driver with RTEMS arm-pl011. Update #3034
Author: Amar Takhar
2025-09-05T03:01:05.555Z
changed the description
3026 - Driver Manager Documentation (opened)¶
Id |
3026 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2017-05-29T06:34:02.000Z |
Updated |
2025-09-19T01:46:13.583Z |
Milestone |
5.4 |
Labels |
doc, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
https://devel.rtems.org/wiki/TBR/UserManual/DriverManager should be updated, possibly expanded and added to the user’s manual.
Please delete the Wiki page after merging into the user’s manual.
Author: Joel Sherrill
2017-05-29T06:34:46.000Z
Owner set to daniel
Status changed from new to assigned
Author: Joel Sherrill
2017-05-29T06:35:41.000Z
Description changed
https://devel.rtems.org/wiki/TBR/UserManual/DriverManager should be updated, possibly expanded and added to the user's manual. + + Please delete the Wiki page after merging into the user's manual.
Author: Chris Johns
2025-09-19T01:46:13.652Z
changed the description
2979 - Load rap files failure with zeroed sections (opened)¶
Id |
2979 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-04-05T08:34:26.000Z |
Updated |
2025-09-19T01:46:13.487Z |
Milestone |
5.4 |
Labels |
cpukit::dl, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: SergKruglov
After patch “libdl: Add C++ exception support to loaded modules.” (ticket 2767 Chris Johns <chrisj@rtems.org> 2016-12-13 22:07:16 (UTC)) in function rtems_rtl_obj_add_section sections with size == 0 not added to sections list for relocate. In function rtems_rtl_rap_relocate for this sectiions generate error “no target section found”. The introduction of the condition “size > 0” in rtems_rtl_obj_add_section was a mistake. I use rap files and plain C (.ctor and .dtor have size == 0).
Author: Trac Migrate
2017-04-05T08:44:28.000Z
Original author: SergKruglov
Owner set to chrisj@rtems.org
Author: Trac Migrate
2017-05-11T07:31:02.000Z
Original author: SergKruglov
Milestone changed from %”4.12” to %”4.12.0”
Author: Trac Migrate
2017-11-09T06:27:14.000Z
Original author: SergKruglov
Milestone changed from %”4.12.0” to %”5.1”
Milestone renamed
Author: Chris Johns
2018-10-14T20:28:22.000Z
Original author: SergKruglov
Owner set to @chrisj
Status changed from new to accepted
Author: Chris Johns
2018-11-13T06:08:34.000Z
Original author: SergKruglov
The
size > 0inrtems_rtl_obj_add_sectionis correct and will not reverted. An empty section serves no purpose other than using memory.If the code is built with separate text and data section then this is a separate issue.
Author: Chris Johns
2019-12-12T23:31:32.000Z
Original author: SergKruglov
Milestone changed from %”5.1” to %”6.1”
Author: Chris Johns
2022-11-29T21:33:55.000Z
Original author: SergKruglov
Milestone changed from %”6.1” to %”Indefinite”
Owner set to Needs Funding
Status changed from accepted to assigned
Version ~”5” deleted
Author: Amar Takhar
2025-09-05T02:57:38.534Z
changed the description
2978 - Support for sigaction() sa_flags Values (opened)¶
Id |
2978 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2017-04-04T20:22:13.000Z |
Updated |
2025-09-19T01:46:13.396Z |
Milestone |
5.4 |
Labels |
old-indefinite, posix::compliance, priority::normal, rtems::score, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Per http://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html, the sa_flags field can have the following values which imply behavior in the POSIX implementation:
SA_NOCLDSTOP - requires processes, unsupportable
SA_ONSTACK - requires unsupported sigaltstack, currently unsupportable
SA_RESTART - should be supportable
SA_SIGINFO - should be supportable
SA_NOCLDWAIT - requires processes, unsupportable
SA_NODEFER - should be supportable
The purpose of this ticket is to review that the supportable sa_flags behaviors are supported or to implement the missing capabilities.
Author: Amar Takhar
2024-04-25T20:45:39.893Z
changed the description
2974 - Enable search.h functionality in newlib (opened)¶
Id |
2974 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2017-04-04T15:42:16.000Z |
Updated |
2025-09-19T01:46:13.306Z |
Milestone |
5.4 |
Labels |
old-indefinite, posix::compliance, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Ensure all search capabilities in newlib are enabled (newlib/libc/search) and review the search.h capabilities against POSIX for completeness and compliance.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/search.h.html
Author: Trac Migrate
2017-05-11T07:31:02.000Z
Milestone changed from %”4.12” to %”4.12.0”
Author: Trac Migrate
2017-06-08T07:50:49.000Z
Milestone changed from %”4.12.0” to %”Indefinite”
Author: Amar Takhar
2024-04-25T20:45:38.643Z
changed the description
2973 - Enable getdate() in newlib (opened)¶
Id |
2973 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2017-04-04T15:34:55.000Z |
Updated |
2025-09-19T01:46:13.206Z |
Milestone |
5.4 |
Labels |
old-indefinite, posix::compliance, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
getdate() (http://pubs.opengroup.org/onlinepubs/009695399/functions/getdate.html) needs to be turned on in newlib
Author: Trac Migrate
2017-05-11T07:31:02.000Z
Milestone changed from %”4.12” to %”4.12.0”
Author: Trac Migrate
2017-06-08T07:51:23.000Z
Milestone changed from %”4.12.0” to %”Indefinite”
Author: Amar Takhar
2024-04-25T20:45:38.146Z
changed the description
2926 - Coverity Reports Multiple Out of Bounds Accesses in rtd-mdreloc-sparc.c (opened)¶
Id |
2926 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2017-03-13T16:21:39.000Z |
Updated |
2025-09-19T01:46:13.111Z |
Milestone |
5.4 |
Labels |
priority::normal, scan::coverity, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Coverity spots an out of bounds read in rtl-mdreloc-sparc.c. Given the comment at the top that it was “Taken from NetBSD and stripped of the relocations not needed on RTEMS”, I am unsure how to correlate the code back to the original to see if the issue exists upstream. Also I do not know where in the NetBSD source this came from.
The first issue is: https://scan5.coverity.com/reports.htm#v29808/p10069/fileInstanceId=109360252&defectInstanceId=30967451&mergedDefectId=1255330
The long analysis ends with:
226
CID 1255330 (#1 of 1): Out-of-bounds read (OVERRUN) 14. overrun-local: Overrunning array reloc_target_bitmask of 24 4-byte elements at element index 45 (byte offset 180) using index type (which evaluates to 45). 227 mask = RELOC_VALUE_BITMASK (type); 228 value >>= RELOC_VALUE_RIGHTSHIFT (type); 229 value &= mask;
The others are:
https://scan5.coverity.com/reports.htm#v29808/p10069/fileInstanceId=109360252&defectInstanceId=30967452&mergedDefectId=1255332 https://scan5.coverity.com/reports.htm#v29808/p10069/fileInstanceId=109360252&defectInstanceId=30967450&mergedDefectId=1255342
Author: Joel Sherrill
2017-03-14T21:28:40.000Z
Description changed
Coverity spots an out of bounds read in rtl-mdreloc-sparc.c. Given the comment at the top that it was "Taken from NetBSD and stripped of the relocations not needed on RTEMS", I am unsure how to correlate the code back to the original to see if the issue exists upstream. Also I do not know where in the NetBSD source this came from. - https://scan5.coverity.com/reports.htm#v29808/p10069/fileInstanceId=109360252&defectInstanceId=30967451&mergedDefectId=1255330 + The first issue is: https://scan5.coverity.com/reports.htm#v29808/p10069/fileInstanceId=109360252&defectInstanceId=30967451&mergedDefectId=1255330 ? ++++++++++++++++++++ The long analysis ends with: 226 CID 1255330 (#1 of 1): Out-of-bounds read (OVERRUN) 14. overrun-local: Overrunning array reloc_target_bitmask of 24 4-byte elements at element index 45 (byte offset 180) using index type (which evaluates to 45). 227 mask = RELOC_VALUE_BITMASK (type); 228 value >>= RELOC_VALUE_RIGHTSHIFT (type); 229 value &= mask; + + The others are: + + https://scan5.coverity.com/reports.htm#v29808/p10069/fileInstanceId=109360252&defectInstanceId=30967452&mergedDefectId=1255332 + https://scan5.coverity.com/reports.htm#v29808/p10069/fileInstanceId=109360252&defectInstanceId=30967450&mergedDefectId=1255342
Summary changed from Out of Bounds Access in rtd-mdreloc-sparc.c to Coverity Reports Multiple Out of Bounds Accesses in rtd-mdreloc-sparc.c
Author: Chris Johns
2017-03-14T23:15:59.000Z
Replying to Joel Sherrill:
Coverity spots an out of bounds read in rtl-mdreloc-sparc.c. Given the comment at the top that it was “Taken from NetBSD and stripped of the relocations not needed on RTEMS”, I am unsure how to correlate the code back to the original to see if the issue exists upstream. Also I do not know where in the NetBSD source this came from.
The code was taken into RTEMS and working with the upstream is only as a reference. The code in NetBSD is under:
http://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/ld.elf_so/?only_with_tag=MAIN
and the SPARC code is:
http://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/ld.elf_so/arch/sparc/?only_with_tag=MAIN
The first issue is: https://scan5.coverity.com/reports.htm#v29808/p10069/fileInstanceId=109360252&defectInstanceId=30967451&mergedDefectId=1255330
This link is redirects me to a login page and my login for Coverity did not work. I had no idea it did not work and I never received anything from them it was being disabled.
Should we have links to login pages in open tickets like this?
The long analysis ends with: 226 CID 1255330 (#1 of 1): Out-of-bounds read (OVERRUN) 14. overrun-local: Overrunning array reloc_target_bitmask of 24 4-byte elements at element index 45 (byte offset 180) using index type (which evaluates to 45).
Where does the 45 come from?
227 mask = RELOC_VALUE_BITMASK (type); 228 value >>= RELOC_VALUE_RIGHTSHIFT (type); 229 value &= mask; The others are: https://scan5.coverity.com/reports.htm#v29808/p10069/fileInstanceId=109360252&defectInstanceId=30967452&mergedDefectId=1255332 https://scan5.coverity.com/reports.htm#v29808/p10069/fileInstanceId=109360252&defectInstanceId=30967450&mergedDefectId=1255342
Sorry I cannot see these.
Author: Gedare Bloom
2017-03-15T14:56:54.000Z
These links don’t work for me even if I am logged in, so they are of minimal utility. I had to use the CID number to pull up the report.
Joel did not paste enough of Coverity’s history to understand the context. You have to go back a step to see:
6. cond_between: Checking type > 45UL implies that type is between 1 and 45 (inclusive) on the false branch. 176 if (type > R_TYPE(6))
Author: Joel Sherrill
2017-03-15T17:08:19.000Z
We will have to figure out how to make the links useful.
My hunch is that since the code is modified from the original that some logic from the original is missing which leads to the three issues spotted.
Author: Chris Johns
2017-03-15T21:48:00.000Z
Thank you for looking into the coverity links, having public view-able report data would be nice.
I will add the ticket to my list of things to look into.
The upstream code can contain functionality not needed on RTEMS and this effects the ability to handle the source as is. I used the NetBSD code as a base of what we need because it had suitable code and NetBSD has a wide range of architectures. Add to this newer tool sets have presented us with newer reloc types and some differences. For example this file was recently updated to handle the unwinding support and here RTEMS and NetBSD build gcc differently which effects the type of relocation records we see. I felt it was not worth the effort attempting to keep the code in sync with the upstream.
Author: Trac Migrate
2017-05-11T07:31:02.000Z
Milestone changed from %”4.12” to %”4.12.0”
Author: Trac Migrate
2017-11-09T06:27:14.000Z
Milestone changed from %”4.12.0” to %”5.1”
Milestone renamed
Author: Joel Sherrill
2018-10-14T01:04:03.000Z
Milestone %”5.1” deleted
Version ~”5” deleted
Author: Amar Takhar
2024-04-25T20:45:28.593Z
changed the description
2892 - Use of C domain in shpinx documentation? (opened)¶
Id |
2892 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-02-01T10:24:33.000Z |
Updated |
2025-09-19T01:46:13.010Z |
Milestone |
5.4 |
Labels |
doc, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The sphinx documentation framework provides so called C/C++ domains for C/C++ API documentation:
http://www.sphinx-doc.org/en/stable/domains.html#c-roles
This feature is not used in the RTEMS documentation. Should it be used? Do we need a custom domain for the API documentation?
The PDF output of the C/C++ domain constructs is quite bad.
Author: Joel Sherrill
2017-02-01T14:26:46.000Z
Original author: sebastian.huber
I recall Chris and I tried to get this working but failed. Perhaps more is correct now and it will work. Give it a try. Using Sphinx is a learning experience for us all.
Author: Trac Migrate
2017-02-01T14:28:14.000Z
Original author: sebastian.huber
I used the C domain for the self-contained objects chapter. The HTML output looks ok, but the PDF output is not really good. I will ask on the sphinx group.
Author: Chris Johns
2017-02-01T23:48:26.000Z
Original author: sebastian.huber
I also found this and backed away from this path as I did have the time to invest becoming a sphinx master.
Author: Trac Migrate
2017-02-15T14:20:42.000Z
Original author: sebastian.huber
Milestone changed from %”4.12” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:01:04.580Z
changed the description
2887 - gcc snapshot sources missing for older RTEMS Source Builder versions (opened)¶
Id |
2887 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-01-26T09:50:10.000Z |
Updated |
2025-09-19T01:46:12.900Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::enhancement, tool::rtems-source-builder, version::5 |
Link |
|
Merges |
0 |
Original author: Christian Mauderer
I tried to build a toolchain using an older version of the RTEMS Source Builder (to be exact: cac72a2aea7 from 2016-08-01). This failed due to the fact that the gcc snapshot that should be build isn’t longer available:
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160609/gcc-6-20160609.tar.bz2
It seems that there are about 6 months of snapshots available but older ones have been deleted. That can be really annoying if you try to rebuild the tools for a specific RTEMS version.
It might would be a good idea if we would copy all sources that are used in RSB to an RTEMS ftp server and download them from there. This is also true for release versions of the sources. We have no control over the files on a foreign server. Therefore the sources could vanish at any time.
Author: Trac Migrate
2017-01-30T07:22:07.000Z
Original author: Christian Mauderer
One option would be to add all files to the RTEMS server and download them from here. Another option would be to add them to the RTEMS tools repository (this enables Github as a backup source).
Author: Chris Johns
2017-01-31T05:49:22.000Z
Original author: Christian Mauderer
The ftp server is the best available solution. Please avoid github, they have changed APIs over the years which is fair enough however this breaks the config as well.
Author: Chris Johns
2017-08-14T01:01:20.000Z
Original author: Christian Mauderer
Milestone set to %”Indefinite”
Author: Amar Takhar
2025-09-05T03:02:38.125Z
changed the description
2866 - i386 status of libbsd is unknown (opened)¶
Id |
2866 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-01-16T06:42:38.000Z |
Updated |
2025-09-19T01:46:12.790Z |
Milestone |
5.4 |
Labels |
libbsd, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
Test the latest version of libbsd on an i386 system to figure out if it sill works.
Author: Trac Migrate
2017-01-16T06:42:53.000Z
Original author: sebastian.huber
Summary changed from i386 of libbsd is unknown to i386 status of libbsd is unknown
Author: Trac Migrate
2017-02-15T14:20:42.000Z
Original author: sebastian.huber
Milestone changed from %”4.12” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T02:57:37.968Z
changed the description
2857 - Improve the I2C framework documentation (opened)¶
Id |
2857 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2016-12-23T13:44:22.000Z |
Updated |
2025-09-19T01:46:12.670Z |
Milestone |
5.4 |
Labels |
doc, old-indefinite, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The I2C framework documentation is quite rudimentary.
Author: Chris Johns
2017-08-14T00:55:55.000Z
Original author: sebastian.huber
Milestone changed from %”5.0” to %”4.12.0”
Please review and update the milestone. Thanks.
Author: Trac Migrate
2017-08-24T08:21:14.000Z
Original author: sebastian.huber
Milestone changed from %”4.12.0” to %”Indefinite”
Owner set to sebastian.huber
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:01:03.968Z
changed the description
2856 - Improve the SPI framework documentation (opened)¶
Id |
2856 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2016-12-23T13:43:01.000Z |
Updated |
2025-09-19T01:46:12.541Z |
Milestone |
5.4 |
Labels |
doc, old-indefinite, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The SPI framework documentation is quite rudimentary.
Author: Chris Johns
2017-08-14T00:55:55.000Z
Original author: sebastian.huber
Milestone changed from %”5.0” to %”4.12.0”
Please review and update the milestone. Thanks.
Author: Trac Migrate
2017-08-24T08:21:01.000Z
Original author: sebastian.huber
Milestone changed from %”4.12.0” to %”Indefinite”
Owner set to sebastian.huber
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:01:03.761Z
changed the description
2854 - What to do with the README files in the RTEMS sources? (opened)¶
Id |
2854 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2016-12-21T13:49:53.000Z |
Updated |
2025-09-19T01:46:12.413Z |
Milestone |
5.4 |
Labels |
doc, old-indefinite, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
There are several README files in the RTEMS sources:
find -iname '*readme*'
./cpukit/libcsupport/src/README
./cpukit/libi2c/README_libi2c
./cpukit/pppd/README
./cpukit/sapi/include/rtems/README
./cpukit/libfs/README
./cpukit/libfs/src/nfsclient/README
./cpukit/libpci/README
./cpukit/dtc/README.license
./cpukit/dtc/README
./cpukit/libmisc/stackchk/README
./cpukit/libmisc/xz/README
./cpukit/libmisc/monitor/README
./cpukit/libmisc/README
./cpukit/libmisc/serdbg/README
./cpukit/libmisc/utf8proc/README
./cpukit/libmisc/cpuuse/README
./cpukit/libmisc/uuid/README
./cpukit/libmisc/mouse/README
./cpukit/libmisc/untar/README
./cpukit/libmisc/fsmount/README
./cpukit/libmisc/capture/README
./cpukit/libmisc/shell/README
./cpukit/libblock/README
./cpukit/librpc/README_RTEMS
./cpukit/librpc/src/rpc/README
./cpukit/telnetd/README
./cpukit/posix/src/README.mqueue
./cpukit/libdrvmgr/README
./cpukit/libnetworking/README
./cpukit/libnetworking/lib/README
./cpukit/score/cpu/sparc/README
./cpukit/score/cpu/sparc64/README
./cpukit/zlib/README
./c/src/libchip/serial/README.xr88681
./c/src/libchip/serial/README.z85c30
./c/src/libchip/serial/README
./c/src/libchip/serial/README.ns16550
./c/src/libchip/serial/README.mc68681
./c/src/libchip/network/README.dec21140
./c/src/libchip/network/README.i82586
./c/src/libchip/network/README
./c/src/libchip/network/README.open_eth
./c/src/libchip/network/README.tulipclone
./c/src/libchip/network/README.sonic
./c/src/libchip/network/README.3com
./c/src/libchip/network/README.cs8900
./c/src/libchip/shmdr/README
./c/src/libchip/rtc/README.m48t08
./c/src/libchip/rtc/README.ds1643
./c/src/libchip/rtc/README.icm7170
./c/src/libchip/rtc/README.mc146818a
./c/src/libchip/rtc/README.m48t18
./c/src/README
./c/src/make/README
./c/src/ada-tests/tmtests/tmoverhd/README
./c/src/ada-tests/sptests/sp19/README
./c/src/ada-tests/sptests/sp04/README
./c/src/lib/libbsp/or1k/generic_or1k/README
./c/src/lib/libbsp/i386/pc386/README.dec21140
./c/src/lib/libbsp/i386/pc386/README
./c/src/lib/libbsp/i386/shared/smp/README
./c/src/lib/libbsp/sh/gensh4/README
./c/src/lib/libbsp/sh/shsim/README
./c/src/lib/libbsp/sh/gensh1/README
./c/src/lib/libbsp/sh/gensh2/README
./c/src/lib/libbsp/sh/gensh2/README.EVB7045F
./c/src/lib/libbsp/epiphany/epiphany_sim/README
./c/src/lib/libbsp/mips/hurricane/README
./c/src/lib/libbsp/mips/csb350/README
./c/src/lib/libbsp/mips/rbtx4938/README
./c/src/lib/libbsp/mips/rbtx4925/README
./c/src/lib/libbsp/mips/jmr3904/README
./c/src/lib/libbsp/mips/shared/gdbstub/README
./c/src/lib/libbsp/m68k/mcf5235/README
./c/src/lib/libbsp/m68k/gen68360/README
./c/src/lib/libbsp/m68k/mcf5329/README
./c/src/lib/libbsp/m68k/uC5282/README
./c/src/lib/libbsp/m68k/csb360/README
./c/src/lib/libbsp/m68k/mcf5206elite/README
./c/src/lib/libbsp/m68k/mvme167/README
./c/src/lib/libbsp/m68k/mvme147/README
./c/src/lib/libbsp/m68k/mrm332/README
./c/src/lib/libbsp/m68k/genmcf548x/README
./c/src/lib/libbsp/m68k/mcf5225x/README
./c/src/lib/libbsp/m68k/mvme147s/README
./c/src/lib/libbsp/m68k/mvme162/README.models
./c/src/lib/libbsp/m68k/mvme162/README
./c/src/lib/libbsp/m68k/mcf52235/README
./c/src/lib/libbsp/m68k/av5282/README
./c/src/lib/libbsp/m68k/gen68340/README
./c/src/lib/libbsp/lm32/lm32_evr/README
./c/src/lib/libbsp/lm32/milkymist/README
./c/src/lib/libbsp/lm32/shared/gdbstub/README
./c/src/lib/libbsp/m32c/m32cbsp/README
./c/src/lib/libbsp/sparc/leon2/README
./c/src/lib/libbsp/sparc/leon3/shmsupp/README
./c/src/lib/libbsp/sparc/leon3/README
./c/src/lib/libbsp/sparc/erc32/README
./c/src/lib/libbsp/sparc/shared/net/README
./c/src/lib/libbsp/nios2/README
./c/src/lib/libbsp/README
./c/src/lib/libbsp/no_cpu/no_bsp/README
./c/src/lib/libbsp/v850/gdbv850sim/README
./c/src/lib/libbsp/powerpc/virtex4/README
./c/src/lib/libbsp/powerpc/mvme5500/README.VME
./c/src/lib/libbsp/powerpc/mvme5500/README.booting
./c/src/lib/libbsp/powerpc/mvme5500/README
./c/src/lib/libbsp/powerpc/mvme5500/README.irq
./c/src/lib/libbsp/powerpc/beatnik/network/if_em/README
./c/src/lib/libbsp/powerpc/beatnik/network/porting/README
./c/src/lib/libbsp/powerpc/beatnik/README
./c/src/lib/libbsp/powerpc/mvme3100/README
./c/src/lib/libbsp/powerpc/gen83xx/README.mpc8349eamds
./c/src/lib/libbsp/powerpc/gen83xx/README.mpc8313erdb
./c/src/lib/libbsp/powerpc/gen5200/README
./c/src/lib/libbsp/powerpc/gen5200/README.IceCube
./c/src/lib/libbsp/powerpc/haleakala/README
./c/src/lib/libbsp/powerpc/qoriq/README
./c/src/lib/libbsp/powerpc/virtex5/README
./c/src/lib/libbsp/powerpc/motorola_powerpc/README.mtx603e
./c/src/lib/libbsp/powerpc/motorola_powerpc/README.dec21140
./c/src/lib/libbsp/powerpc/motorola_powerpc/README
./c/src/lib/libbsp/powerpc/motorola_powerpc/README.MVME2300
./c/src/lib/libbsp/powerpc/motorola_powerpc/README.OTHERBOARDS
./c/src/lib/libbsp/powerpc/motorola_powerpc/README.MVME2400
./c/src/lib/libbsp/powerpc/motorola_powerpc/README.qemu
./c/src/lib/libbsp/powerpc/motorola_powerpc/README.MVME2100
./c/src/lib/libbsp/powerpc/mpc55xxevb/README
./c/src/lib/libbsp/powerpc/ss555/README
./c/src/lib/libbsp/powerpc/psim/network/README
./c/src/lib/libbsp/powerpc/psim/shmsupp/README
./c/src/lib/libbsp/powerpc/psim/vectors/README
./c/src/lib/libbsp/powerpc/psim/README
./c/src/lib/libbsp/powerpc/virtex/README
./c/src/lib/libbsp/powerpc/tqm8xx/README
./c/src/lib/libbsp/powerpc/mpc8260ads/network/README
./c/src/lib/libbsp/powerpc/mpc8260ads/README
./c/src/lib/libbsp/powerpc/t32mppc/README
./c/src/lib/libbsp/powerpc/qemuppc/README
./c/src/lib/libbsp/powerpc/shared/vme/README
./c/src/lib/libbsp/powerpc/shared/bootloader/README
./c/src/lib/libbsp/bfin/bf537Stamp/README
./c/src/lib/libbsp/bfin/eZKit533/README
./c/src/lib/libbsp/bfin/TLL6527M/README
./c/src/lib/libbsp/arm/csb337/README.kit637_v6
./c/src/lib/libbsp/arm/csb337/README
./c/src/lib/libbsp/arm/rtl22xx/README
./c/src/lib/libbsp/arm/stm32f7x/hal/CMSIS/README.txt
./c/src/lib/libbsp/arm/smdk2410/README
./c/src/lib/libbsp/arm/atsam/README
./c/src/lib/libbsp/arm/csb336/README
./c/src/lib/libbsp/arm/stm32f4/README
./c/src/lib/libbsp/arm/tms570/README
./c/src/lib/libbsp/arm/realview-pbx-a9/README
./c/src/lib/libbsp/arm/gumstix/README
./c/src/lib/libbsp/arm/lpc24xx/README
./c/src/lib/libbsp/arm/beagle/pwm/README
./c/src/lib/libbsp/arm/beagle/README
./c/src/lib/libbsp/arm/beagle/README.JTAG
./c/src/lib/libbsp/arm/lpc176x/README
./c/src/lib/libbsp/arm/xilinx-zynq/README
./c/src/lib/libbsp/arm/altera-cyclone-v/README
./c/src/lib/libbsp/arm/altera-cyclone-v/hwlib/README.txt
./c/src/lib/libbsp/arm/lpc32xx/README
./c/src/lib/libbsp/arm/lm3s69xx/README
./c/src/lib/libbsp/arm/raspberrypi/README
./c/src/lib/libbsp/arm/edb7312/README
./c/src/lib/libbsp/arm/stm32f4x/hal/CMSIS/README.txt
./c/src/lib/libbsp/arm/shared/CMSIS/README
./c/src/lib/libbsp/sparc64/usiii/README
./c/src/lib/libbsp/sparc64/niagara/README
./c/src/lib/libbsp/sparc64/shared/helenos/README
./c/src/lib/libbsp/shared/umon/README
./c/src/lib/libbsp/shared/vmeUniverse/README.porting
./c/src/lib/libbsp/shared/vmeUniverse/README.universe
./c/src/lib/libcpu/mips/mongoosev/README
./c/src/lib/libcpu/m68k/m68040/fpsp/README
./c/src/lib/libcpu/README
./c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/README
./c/src/lib/libcpu/powerpc/mpc8xx/README
./c/src/lib/libcpu/powerpc/mpc8260/README
./c/src/lib/libcpu/powerpc/README
./c/src/lib/libcpu/powerpc/mpc5xx/README
./c/src/lib/libcpu/powerpc/mpc6xx/altivec/README
./c/src/lib/libcpu/powerpc/ppc403/vectors/README
./c/src/lib/libcpu/powerpc/ppc403/README
./c/src/lib/libcpu/bfin/README
./README
./testsuites/samples/pppd/README
./testsuites/samples/README
./testsuites/samples/loopback/README
./testsuites/mptests/README
./testsuites/README
./testsuites/tmtests/README
./testsuites/libtests/termios/README
./testsuites/libtests/README
./testsuites/libtests/POSIX/README
./testsuites/psxtmtests/README
./testsuites/smptests/README
./testsuites/sptests/README
./testsuites/rhealstone/README
./doc/README
./tools/cpu/nios2/README
./tools/build/README
Should there be README files at all?
What should they contain?
How should they be formatted?
What is the relationship to the Wiki BSP pages: wiki:TBR/Website/Board_Support_Packages?
Author: Chris Johns
2016-12-21T23:24:33.000Z
Original author: sebastian.huber
I think grouping all READMEs together does not work, it forces a lowest common denominator. We should consider each type separately. I see:
BSP
Testsuite
3rd Party packages
RTEMS kernel, ie the top level, c/src etc.
I think important information about a BSP needs to captured in
rtems-docs.git. The documentation on a BSP forms an interface a user of the BSP can rely on and we need to make sure it is stable across releases. We also need to make changes clear to uses with specifics on how to migrate.The wiki can contain transient and less formal documentation, for example how to use a specific debugger.
I do not know about these.
If a copy of the original package, leave.
No idea. I suspect they will not be needed in a waf build system.
TRB in the wiki means “To Be Reviewed” or “To Be Removed” depending on how you want to look at the pages. I feel the wiki needs be cleaned up, containing only relevant pages to be seriously considered a suitable place to add important documentation. Adding to the current pages means you need to know the history and importance to know how valid the pages are.
Author: Chris Johns
2017-08-14T00:55:55.000Z
Original author: sebastian.huber
Milestone changed from %”5.0” to %”4.12.0”
Please review and update the milestone. Thanks.
Author: Trac Migrate
2017-08-24T08:23:26.000Z
Original author: sebastian.huber
Milestone changed from %”4.12.0” to %”Indefinite”
Author: Trac Migrate
2017-10-25T13:03:22.000Z
Original author: sebastian.huber
Owner set to sebastian.huber
Status changed from new to assigned
Author: Trac Migrate
2018-06-26T09:21:34.000Z
Original author: sebastian.huber
In [changeset:”8e3de165c0216d031a909f3981712626cf462a23/rtems-docs” 8e3de16/rtems-docs]:
user: Add ARM BSPs chapter Add NXP i.MX section as a BSP example. Update #2854.
Author: Trac Migrate
2018-08-29T05:47:13.000Z
Original author: sebastian.huber
In [changeset:”a6fca762b69164b68c3579ad22bb5f53befdc303/rtems” a6fca76/rtems]:
bsp/qoriq: Remove README Update #2854.
Author: Trac Migrate
2018-08-29T05:47:59.000Z
Original author: sebastian.huber
In [changeset:”c476ccef39965abdf89fc660be955332e36b3d0b/rtems-docs” c476cce/rtems-docs]:
user: Add qoriq BSP section Update #2854.
Author: Amar Takhar
2025-09-05T02:57:37.816Z
mentioned in issue #2855
Author: Amar Takhar
2025-09-05T03:01:03.545Z
changed the description
2834 - Cilk Plus support (opened)¶
Id |
2834 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2016-12-07T07:48:09.000Z |
Updated |
2025-09-19T01:46:12.297Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
Cilk Plus is a C++ language extension developed by Intel. It is proposed as a C++ standard extension. It uses a work stealing scheduler. Similar to OpenMP it consists of two parts,
the code generation by the compiler, and
a run-time library.
The code generation works for the RTEMS using a recent GCC. It is feasible to port the run-time library (libcilkrt) to RTEMS. However, some issues must be dealt with.
Currently virtual memory via
mmap()is used to manage the worker stacks (cactus-stack).This could be changed to use a pool allocator.
What happens in case of stack overflows, e.g. no protection pages?
Author: Trac Migrate
2016-12-07T07:48:24.000Z
Original author: sebastian.huber
Original author: sebastian.huber
Description changed
Cilk Plus is a C++ language extension developed by Intel. It is proposed as a C++ standard extension. It uses a work stealing scheduler. Similar to OpenMP it consists of two parts, * the code generation by the compiler, and * a run-time library. The code generation works for the RTEMS using a recent GCC. It is feasible to port the run-time library (libcilkrt) to RTEMS. However, some issues must be dealt with. * Currently virtual memory via `mmap()` is used to manage the worker stacks (cactus-stack). * This could be changed to use a pool allocator. - & What happens in case of stack overflows, e.g. no protection pages? ? ^ + * What happens in case of stack overflows, e.g. no protection pages? ? ^
Author: Trac Migrate
2016-12-07T07:49:07.000Z
Original author: sebastian.huber
Original author: sebastian.huber
Description changed
+ Cilk Plus is a C++ language extension developed by Intel. It is proposed as a C++ standard extension. It uses a work stealing scheduler. Similar to OpenMP it consists of two parts, - Cilk Plus is a C++ language extension developed by Intel. It is proposed as a - C++ standard extension. - It uses a work stealing scheduler. Similar to OpenMP it - consists of two parts, * the code generation by the compiler, and * a run-time library. + The code generation works for the RTEMS using a recent GCC. It is feasible to port the run-time library (libcilkrt) to RTEMS. However, some issues must be dealt with. - The code generation works for the RTEMS using a recent GCC. It is feasible to - port the run-time library (libcilkrt) to RTEMS. However, some issues must - be dealt with. * Currently virtual memory via `mmap()` is used to manage the worker stacks (cactus-stack). * This could be changed to use a pool allocator. * What happens in case of stack overflows, e.g. no protection pages?
Author: Trac Migrate
2016-12-07T07:49:37.000Z
Original author: sebastian.huber
This ticket depends on #2833.
Author: Chris Johns
2017-08-14T00:55:55.000Z
Original author: sebastian.huber
Milestone changed from %”5.0” to %”4.12.0”
Please review and update the milestone. Thanks.
Author: Chris Johns
2017-08-23T22:53:24.000Z
Original author: sebastian.huber
Milestone changed from %”4.12.0” to %”Indefinite”
Author: Amar Takhar
2025-09-05T03:02:36.111Z
changed the description
2793 - cpuuuse shell command documentation needs an update (opened)¶
Id |
2793 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2016-09-30T05:47:08.000Z |
Updated |
2025-09-19T01:46:12.203Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
This section is outdated and incomplete.
Author: Trac Migrate
2017-02-15T14:20:42.000Z
Original author: sebastian.huber
Milestone changed from %”4.12” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:02:35.206Z
changed the description
2791 - C++11 std::exception_ptr support (opened)¶
Id |
2791 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2016-09-27T11:13:50.000Z |
Updated |
2025-09-19T01:46:12.113Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The C++11 std::exception_ptr support needs GCC changes for targets not supporting lock-free atomic operations.
http://en.cppreference.com/w/cpp/error/exception_ptr
https://gcc.gnu.org/ml/libstdc++/2016-09/msg00144.html
Author: Trac Migrate
2017-02-15T14:20:42.000Z
Original author: sebastian.huber
Milestone changed from %”4.12” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:02:35.004Z
changed the description
2787 - Add support functions for UBSAN (GCC option -fsanitize=undefined) (opened)¶
Id |
2787 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2016-09-20T08:10:30.000Z |
Updated |
2025-09-19T01:46:12.021Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, rtems::score, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
See also:
http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/
We need RTEMS support for libsanitizer (contains also ASAN, TSAN and LSAN in GCC or a free-standing implementation like on Linux:
http://lxr.free-electrons.com/source/lib/ubsan.h http://lxr.free-electrons.com/source/lib/ubsan.c
Author: Trac Migrate
2017-02-15T14:20:42.000Z
Original author: sebastian.huber
Milestone changed from %”4.12” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:02:34.787Z
changed the description
2786 - Remove the devfs in favor of a stripped down IMFS configuration (opened)¶
Id |
2786 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2016-09-19T08:05:40.000Z |
Updated |
2025-09-19T01:46:11.932Z |
Milestone |
5.4 |
Labels |
filesystem, old-indefinite, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The IMFS offers the ability to register generic nodes for device drivers. This feature is not available in the devfs. The devfs offers little benefit compared to a stripped down IMFS configuration.
Author: Joel Sherrill
2016-09-19T14:42:54.000Z
Original author: sebastian.huber
The devfs was added for at least two purposes. Just saying it doesn’t support a particular feature isn’t enough to obsolete it. You need to do a lot better job at justifying this change.
The devfs was added for at least two purposes:
to have a smaller footprint filesystem that supported only device nodes. Otherwise, no console or other device access was possible.
to have a much simpler root filesystem that was an alternative for systems which had completely disabled all filesystem support prior to this point.
If the mini-IMFS has shrunk to the point where there is little difference, then the first point is addressed. But you didn’t provide data.
The complexity of the mini-IMFS in a system that only wants devices is a topic that hasn’t even been touched on and will require some analysis.
Author: Trac Migrate
2016-09-20T05:38:07.000Z
Original author: sebastian.huber
The devfs has some design flaws.
It uses a link-time configured fixed-size table to store the devices.
It uses the standard RTEMS drivers.
The standard RTEMS drivers have some design flaws
They use a link-time configured fixed-size table. A const array of handlers is copied into one of the table entries via rtems_io_register_driver(), e.g. size is doubled.
They are not able to fully support the handlers available via the filesystem layer (rtems_filesystem_file_handlers_r), e.g. no kqueue(), fsync().
There is a considerable layering before you reach the device handler with a parameter pack/unpack, e.g.
#0 rtems_termios_write (arg=0x2046a50) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/termios.c:1100 #1 0x0201ad48 in rtems_io_write (major=major@entry=0, minor=minor@entry=0, argument=argument@entry=0x2046a50) at ../../../../../../rtems/c/src/../../cpukit/sapi/src/iowrite.c:36 #2 0x0201aa84 in rtems_deviceio_write (iop=0x2027bb0 <rtems_libio_iops+112>, buf=0x2021550 <_rodata_start+128>, nbyte=20, major=0, minor=0) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/sup_fs_deviceio.c:109 #3 0x02021310 in write (fd=<optimized out>, buffer=0x2021550 <_rodata_start+128>, count=20) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/write.c:48vs.
#0 rtems_termios_imfs_write (iop=0x20c1d0 <rtems_libio_iops+112>, buffer=0x1300a0, count=20) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/termios.c:1931 #1 0x0012fbcc in write (fd=2, buffer=0x1300a0, count=20) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/write.c:48For an example how IMFS can be configured, see fstests/fsimfsconfig0[123].
Author: Trac Migrate
2017-02-15T14:20:42.000Z
Original author: sebastian.huber
Milestone changed from %”4.12” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:02:34.581Z
changed the description
2774 - RTEMS loaded by u-boot with dcache, icache and mmu enable does not boot. (opened)¶
Id |
2774 |
State |
opened |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Trac Migrate |
Created |
2016-08-08T06:31:47.000Z |
Updated |
2025-09-19T01:46:11.840Z |
Milestone |
5.4 |
Labels |
bsp, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
The arm/xilinx_zynq_zedboard does not boot with a recent u-boot built from git (b2f1858455e99a91aeafe59ac73c6c047106d5e8). I have tracked the issue down to the MMU initialization and I am wondering if there are a few issues we need to look at closer. I think RTEMS could handle this case a little better and this would improve the ARM support making it more resilient to how it is run.
I have the code booting and running and these are the changes.
In arm_cp15_start_setup_translation_table in arm-cp15-start.h I moved the arm_cp15_set_translation_table_base to after the table is created. While this is not that important I did find when looking into this problem it improved things when I had a call to arm_cp15_data_cache_clean_all_levels() before setting the table base. I am not sure the cache clear is needed.
In the zynq_setup_mmu_and_cache I detect the MMU being enabled and if enabled I:
uint32_t ctrl = arm_cp15_get_control();
if ((ctrl & ARM_CP15_CTRL_M) != 0) {
arm_cp15_data_cache_clean_all_levels();
ctrl &= ~(ARM_CP15_CTRL_C | ARM_CP15_CTRL_I | ARM_CP15_CTRL_M);
arm_cp15_set_control(ctrl);
arm_cp15_tlb_invalidate();
}
This lets ticker run.
Author: Trac Migrate
2017-02-15T14:20:42.000Z
Milestone changed from %”4.12” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:02:34.385Z
changed the description
2763 - Incorrect exit if condition for capture_flags_global in cpukit/libmisc/capture/capture.c (opened)¶
Id |
2763 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2016-07-20T12:08:06.000Z |
Updated |
2025-09-19T01:46:11.747Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: vivekkukreja
In capture engine, capture_flags_global is set to RTEMS_CAPTURE_ON when ‘cenable’ command is run, but the ‘ctrace’ command exits incorrectly due to the following if condition: if ( (capture_flags_global & RTEMS_CAPTURE_ON) != 0 )
This should be replaced by: if ( (capture_flags_global & RTEMS_CAPTURE_ON) == 0 )
Author: Trac Migrate
2017-02-15T14:20:42.000Z
Original author: vivekkukreja
Milestone changed from %”4.12” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:02:33.730Z
changed the description
2759 - Unlinking large files in RFS never ends (opened)¶
Id |
2759 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2016-07-14T23:36:54.000Z |
Updated |
2025-09-19T01:46:11.658Z |
Milestone |
5.4 |
Labels |
filesystem, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: snob-wolpike
Steps to reproduce:
Create large file under RFS (~256Mb).
Try to delete it using ‘unlink()’.
‘unlink()’ call never finishes.
Reproduced under RTEMS 4.12 using i386 BSP under Qemu. Should also work under 4.11.
Author: Trac Migrate
2016-07-14T23:37:37.000Z
Original author: snob-wolpike
Attachment testrfs.c added
Author: Trac Migrate
2016-07-15T12:22:59.000Z
Original author: snob-wolpike
Reproduced on Kontron P2020 with QoriQ BSP with RTEMS 4.11
Author: Trac Migrate
2017-01-26T07:16:00.000Z
Original author: snob-wolpike
Milestone changed from %”4.11.1” to %”4.11.2”
Author: Trac Migrate
2017-02-15T13:44:44.000Z
Original author: snob-wolpike
Milestone changed from %”4.11.2” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:02:33.531Z
changed the description
2733 - raspberrypi: SPI driver has several flaws (opened)¶
Id |
2733 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2016-06-11T10:27:36.000Z |
Updated |
2025-09-19T01:46:11.569Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: soja
I started to work with the SPI of the raspberry pi and noticed several problems with the current driver after recording the frames with a logic analyzer:
Setting the chip select signal using the CSPOL-bits of the control register creates incorrect chip select signals
After every byte written to the TX FIFO buffer the driver waits for a signal from an interrupt. This creates very long pauses between consecutive bytes.
The lsb-first mode does not look as if it would work
3-wire/bidirectional mode might not work
Accessing the driver from a different thread than the one which called spi_init will cause a deadlock
Simultaneous read-write-operation is not supported
I will submit a patchset for this after some testing.
Author: Trac Migrate
2017-02-15T14:20:42.000Z
Original author: soja
Milestone changed from %”4.12” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:02:33.143Z
changed the description
2716 - _POSIX_signals_Check_signal() may pass random data to sigaction handler (opened)¶
Id |
2716 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2016-05-18T06:32:37.000Z |
Updated |
2025-09-19T01:46:11.470Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
_POSIX_signals_Check_signal() passes a siginfo_t structure residing on the stack to the sigaction handler which is not set up in all paths of _POSIX_signals_Clear_signals().
Author: Chris Johns
2017-08-14T00:55:55.000Z
Original author: sebastian.huber
Milestone changed from %”5.0” to %”4.12.0”
Please review and update the milestone. Thanks.
Author: Trac Migrate
2017-08-24T08:24:34.000Z
Original author: sebastian.huber
Milestone changed from %”4.12.0” to %”Indefinite”
Author: Amar Takhar
2025-09-05T03:02:32.685Z
changed the description
2699 - RSB leak to check libz1g-dev and Python-dev (opened)¶
Id |
2699 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Chris Johns |
Created |
2016-04-23T17:29:32.000Z |
Updated |
2025-09-19T01:46:11.280Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::low, tickettype::defect, tool::rtems-source-builder, version::5 |
Link |
|
Merges |
0 |
Original author: printk
This two package is needed but RSB does not check for these.
Author: Trac Migrate
2016-04-23T17:31:22.000Z
Original author: printk
Cc added @rtems@21cn.com
Author: Chris Johns
2016-04-23T23:59:01.000Z
Original author: printk
I will leave this ticket open but I have no timeline on looking at adding support to check for installed packager on a per host basis.
Author: Trac Migrate
2017-05-11T07:31:02.000Z
Original author: printk
Milestone changed from %”4.12” to %”4.12.0”
Author: Trac Migrate
2017-11-09T06:27:14.000Z
Original author: printk
Milestone changed from %”4.12.0” to %”5.1”
Milestone renamed
Author: Chris Johns
2018-04-13T01:24:47.000Z
Original author: printk
Milestone changed from %”5.1” to %”Indefinite”
This change needs funding.
Author: Amar Takhar
2025-09-05T03:01:02.042Z
changed the description
2697 - Function for getting a time_t from a struct tm in UTC (like timegm on Linux and BSD) (opened)¶
Id |
2697 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2016-04-19T09:46:52.000Z |
Updated |
2025-09-19T01:46:11.178Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::enhancement, tool::newlib, version::5 |
Link |
|
Merges |
0 |
Original author: Christian Mauderer
It seems that there is no thread save possibility to convert a struct tm that holds a UTC time into a time_t (the inverse of the POSIX gmtime() function). mktime does this for the current locale only.
Linux and BSD provide a non-POSIX-function called timegm() (see http://linux.die.net/man/3/timegm). According to the man page, the use of this functions should be avoided. The linked man page provides a solution that only uses POSIX functions. But that solution is not thread save.
We should think about adding timegm() to newlib for compatibility with applications that use it (e.g. the civetweb web server).
Author: Gedare Bloom
2016-04-19T16:06:53.000Z
Original author: Christian Mauderer
Should be sent to newlib mailing list, but I think this is probably the right thing to do.
Author: Trac Migrate
2016-04-20T14:00:11.000Z
Original author: Christian Mauderer
I currently didn’t sent it to the newlib mailinglist because my time budget doesn’t allow that I start to work on it at the moment. I hope that I’m able to implement it sometimes in the future.
Author: Joel Sherrill
2016-04-20T17:37:54.000Z
Original author: Christian Mauderer
I only found this method in the crypto library in FreeBSD:
https://github.com/freebsd/freebsd/blob/master/crypto/heimdal/lib/asn1/timegm.c
Is it anywhere else in FreeBSD?
I am not opposed to pursuing it being added to newlib.
Author: Trac Migrate
2016-04-21T05:22:53.000Z
Original author: Christian Mauderer
It seems that the solution in the crypto library is a simplified one that does not care for leap seconds or similar. To be honest, I had not found this one. But I found three others in freebsd:
A comprehensive implementation can be found in the tzcode area:
https://github.com/freebsd/freebsd/blob/master/contrib/tzcode/stdtime/localtime.c This implementation uses the same functions for mktime and timegm.
Another implementation in ldns uses the solution from the man page. But that is not thread save:
https://github.com/freebsd/freebsd/blob/master/contrib/ldns/compat/timegm.c
A third implementation is in the ntp area:
https://github.com/freebsd/freebsd/blob/master/contrib/ntp/libntp/mktime.c
As far as I can see, the one from tzcode is the one that handles the most details. It might would make sense to use this implementation for mktime as well as timegm
Author: Chris Johns
2017-08-14T01:01:53.000Z
Original author: Christian Mauderer
Milestone set to %”Indefinite”
Author: Amar Takhar
2025-09-05T03:02:31.828Z
changed the description
2666 - RSB docs yum on way out .. use dnf (opened)¶
Id |
2666 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2016-03-19T20:07:48.000Z |
Updated |
2025-09-19T01:46:11.063Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool::rtems-source-builder, version::4.10, version::4.12, version::5 |
Link |
|
Merges |
0 |
This ticket is a note that rtbf64a which is running Fedora 22 gave a warning that yum is being replaced with a tool named dnf (do not find?). The RSB doc will have to be updated to have the development environment install command once we figure out what that is.
This applies to all versions of the RSB docs.
Author: Joel Sherrill
2016-03-19T20:17:16.000Z
This article sheds more light.
From our perspective a minor documentation issue. But it does make you wonder about stable interfaces. Do we do this to our users? Wipe out over a decade of sysadmin experience with an interface?
Author: Chris Johns
2016-03-19T20:34:44.000Z
Milestone changed from %”4.11” to %”4.12”
Version changed from ~”4.10” to ~”4.12”
The RSB is python 2 and 3 clean. I am pleased I did that change.
I have moved this ticket to 4.12. Any doco changes can be back ported when ready.
Author: Joel Sherrill
2016-03-20T16:27:38.000Z
Looks like for installation purposes “dnf install” works just like “yum install”. Based on the article I linked above, there are differences but the most common use case appears to be the same.
So this should be nothing more than adding a sentence like the following to the Fedora specific section:
NOTE: In Fedora 22 and above, the yum command has been deprecated in favor of the dnf command. Use “dnf install …” rather than “yum install …”
And at some point in the future, we will have to address the CentOS/RHEL section and when they obsolete a yum wrapper, we will have to flip from yum first with a note to dnf first with a note for older Fedora systems. CentOS/RHEL will have to treat versions with yum as equals to versions with dnf due to the longevity.
Or we could just start now, and say … On Fedora 22 and above, do this… and on Fedora 21 and below do this… Later copy that pattern to CentOS/RHEL if version 8 uses dnf.
Author: Trac Migrate
2017-02-15T14:20:42.000Z
Milestone changed from %”4.12” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:02:30.416Z
changed the description
2665 - Convert _TOD_To_seconds to use mktime? (opened)¶
Id |
2665 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2016-03-18T20:34:17.000Z |
Updated |
2025-09-19T01:46:10.919Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, rtems::score, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Our implementation of _TOD_To_seconds uses our own math. Given that this should be doing the equivalent of the POSIX method mktime(), I believe we should switch to that as the implementation of this method. At a minimum, this would ensure the implementation is correct. Worst case, it deletes some code which is hard to be sure it is 100% correct from our code base.
Author: Chris Johns
2016-03-19T02:14:30.000Z
I changed
rtems_clock_get_todaway from newlib a couple of years ago because of the 2038 bug and improved the implementation to not contain loops. I think performance is important in these calls.Does the RTEMS call need to deal with timezones and the overhead it creates?
Author: Joel Sherrill
2016-03-19T15:02:52.000Z
No on timezones. This is strictly convert the time of day structure into a time_t. If you are happy with the implementation, then I am also. This was just a question from coming across this method while teaching the class and wondering.
I do think it needs to be a public method named something like rtems_clock_tod_to_seconds() or rtems_clock_tod_to_time_t(). It is used by the shared RTC driver by the private name.
Author: Chris Johns
2016-03-19T19:13:29.000Z
Replying to joel.sherrill:
No on timezones.
I think POSIX handles this so this would be a performance and size thing.
This is strictly convert the time of day structure into a time_t. If you are happy with the implementation, then I am also. This was just a question from coming across this method while teaching the class and wondering.
I would need to take a close look. I have not done this.
I do think it needs to be a public method named something like rtems_clock_tod_to_seconds() or rtems_clock_tod_to_time_t(). It is used by the shared RTC driver by the private name.
Good idea.
Author: Trac Migrate
2016-03-21T07:33:10.000Z
We should first clearly define the time of day in RTEMS, see also #2189. There are reasons, why for example this code is a bit more complicated (e.g. leap seconds):
https://svnweb.freebsd.org/base/head/contrib/tzcode/stdtime/localtime.c?revision=289027&view=markup
Author: Joel Sherrill
2016-03-21T14:40:36.000Z
The original specifications RTEMS is based upon are here:
https://ftp.rtems.org/pub/rtems/people/joel/RTEID-ORKID/
to the best of my recollection, there is no mention of epoch, timezones, leap seconds, or leap years. The epoch of 1988 was chosen since it was the leap year immediately prior to the inception of RTEMS as a project.
At one point, the computation from tod to time_t did look like the reference in #2189.
I’m not trying to be argumentative but at this point, the score time is POSIX time and the tod returned is an alternative representation of that with the limitation that you can’t set the time prior to 1988 via the Classic API.
Timezone is via the C Library and leap seconds would be the responsibility of ntp or other time syncing services.
This ticket is simply that this conversion doesn’t look like a standard algorithm. The ticket you reference is asking to document the relationships of various time representations/APIs.
Author: Trac Migrate
2017-02-15T14:20:42.000Z
Milestone changed from %”4.12” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2024-04-25T20:48:43.724Z
mentioned in issue #4338
Author: Amar Takhar
2025-09-05T02:57:02.999Z
changed the description
2552 - Add per-section compilation and rtems dynamic linking support (opened)¶
Id |
2552 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Chris Johns |
Created |
2016-01-26T11:56:11.000Z |
Updated |
2025-09-19T01:46:10.662Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5, version::7 |
Link |
|
Merges |
0 |
Original author: SergKruglov
If rtems libraries and image build with per-section compilation flags rap files (maybe and other) build with duplicate symbols(objects). Gnu ld with flag -gc-sections remove unnessary symbols(objects)? but rtems-ld this does. I wrote small sample with 3 projects: a) static lib libtst.a with one file tst.c tst.c
int abcd=5;
void funcA(void)
{
abcd=7;
}
void funcB(void)
{
}
any rtems project (minimal or any) linked with this lib and in Init call function from lib
extern void funcA(void);
extern int abcd;
rtems_task Init(rtems_task_argument argument) {
funcA();
abcd = 9;
rtems_task_delete(RTEMS_SELF);
}
c) rap file project with core image from b) and library from a) test.c
extern void funcB(void);
void rtems(void)
{
funcB();
}
After generate map files with rtems-rap -sSr
Map file without per-section compilation testrap.rap:
Strings: 0x00000074 (116) size: 14
0 (0x000000):
1 (0x000001): rtems
2 (0x000007): rtems
3 (0x00000d):
Symbols: 0x00000082 (130) size: 12
data section value name
0: 0x0012 .text 0x00000000 rtems
Relocations: 0x0000008e (142)
.text: info offset addend symbol name
0: 0x80000504 0x00000008 0x00000000 funcB
Map file with per-section compilation testrap.rap:
Strings: 0x00000090 (144) size: 31
0 (0x000000):
1 (0x000001): rtems
2 (0x000007): funcA
3 (0x00000d): abcd
4 (0x000012): funcB
5 (0x000018): rtems
6 (0x00001e):
Symbols: 0x000000af (175) size: 48
data section value name
0: 0x0012 .text 0x00000000 rtems
1: 0x0012 .text 0x00000000 funcA
2: 0x0011 .data 0x00000000 abcd
3: 0x0012 .text 0x00000000 funcB
Relocations: 0x000000df (223)
.text: info offset addend symbol name
0: 0xc0001204 0x00000008 0x00000000
1: 0xc0000d05 0x00000024 0x00000000
2: 0xc0000d06 0x0000002c 0x00000000
If use per-section compilation while insert funcB (from library libtst.a) get full tst.o from library.
Objects funcA and abcd duplicate already available in kernel.
I do not know as it to correct and remove excess symbols and objects.
Author: Trac Migrate
2016-02-05T06:27:34.000Z
Original author: SergKruglov
for build rap file use switches –rap-strip and –one-file
Author: Joel Sherrill
2016-02-05T13:42:43.000Z
Original author: SergKruglov
Owner set to @chrisj
Status changed from new to assigned
Chris… is this documented? Where can the instructions go about per function sections and these arguments?
Seems like the ticket is resolved except making sure no one treads this path again.
Author: Chris Johns
2016-02-16T23:22:37.000Z
Original author: SergKruglov
I wonder why those options are needed. We should really look into this.
There is documentation in the linkers dorectory in rtems-tools.git but this should all be moved into the docs projects.
Author: Trac Migrate
2017-05-11T07:31:02.000Z
Original author: SergKruglov
Milestone changed from %”4.12” to %”4.12.0”
Author: Trac Migrate
2017-11-09T06:27:14.000Z
Original author: SergKruglov
Milestone changed from %”4.12.0” to %”5.1”
Milestone renamed
Author: Joel Sherrill
2018-10-13T22:47:38.000Z
Original author: SergKruglov
Milestone changed from %”5.1” to %”5.2”
Author: Chris Johns
2022-11-09T23:05:20.000Z
Original author: SergKruglov
Description changed
If rtems libraries and image build with per-section compilation flags rap files (maybe and other) build with duplicate symbols(objects). Gnu ld with flag -gc-sections remove unnessary symbols(objects)? but rtems-ld this does. I wrote small sample with 3 projects: a) static lib libtst.a with one file tst.c tst.c - + {{{ int abcd=5; void funcA(void) { abcd=7; } void funcB(void) { } + }}} b) any rtems project (minimal or any) linked with this lib and in Init call function from lib - + {{{ extern void funcA(void); extern int abcd; rtems_task Init(rtems_task_argument argument) { funcA(); abcd = 9; rtems_task_delete(RTEMS_SELF); } + }}} c) rap file project with core image from b) and library from a) test.c - + {{{ extern void funcB(void); void rtems(void) { funcB(); } - + }}} After generate map files with rtems-rap -sSr Map file without per-section compilation testrap.rap: + {{{ Strings: 0x00000074 (116) size: 14 0 (0x000000): 1 (0x000001): rtems 2 (0x000007): rtems 3 (0x00000d): Symbols: 0x00000082 (130) size: 12 data section value name 0: 0x0012 .text 0x00000000 rtems Relocations: 0x0000008e (142) .text: info offset addend symbol name 0: 0x80000504 0x00000008 0x00000000 funcB - + }}} Map file with per-section compilation testrap.rap: + {{{ Strings: 0x00000090 (144) size: 31 0 (0x000000): 1 (0x000001): rtems 2 (0x000007): funcA 3 (0x00000d): abcd 4 (0x000012): funcB 5 (0x000018): rtems 6 (0x00001e): Symbols: 0x000000af (175) size: 48 data section value name 0: 0x0012 .text 0x00000000 rtems 1: 0x0012 .text 0x00000000 funcA 2: 0x0011 .data 0x00000000 abcd 3: 0x0012 .text 0x00000000 funcB Relocations: 0x000000df (223) .text: info offset addend symbol name 0: 0xc0001204 0x00000008 0x00000000 1: 0xc0000d05 0x00000024 0x00000000 2: 0xc0000d06 0x0000002c 0x00000000 - + }}} - If use per-section compilation while insert funcB (from library libtst.a) get full tst.o from library. ? - + If use per-section compilation while insert funcB (from library libtst.a) get full tst.o from library. + Objects funcA and abcd duplicate already available in kernel. I do not know as it to correct and remove excess symbols and objects.
Milestone changed from %”5.2” to %”Indefinite”
Version changed from ~”5” to ~”7”
Needs funding
Author: Amar Takhar
2025-09-05T02:57:37.104Z
changed the description
2540 - RSB has problems building into existing directory (opened)¶
Id |
2540 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2016-01-22T17:57:26.000Z |
Updated |
2025-09-19T01:46:10.542Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool::rtems-source-builder, version::5 |
Link |
|
Merges |
0 |
Original author: williamssimonp
Attempting to build the ARM/4.12 BSet using RSB on Fedora 23 X86_64. The RSB repository clone was up to date (22/01/2016). I had previously built the same BSet from the repository up to date as of 09/01/2016. When building newlib, I got the following:
Running configure in multilib subdir thumb/cortex-m7/fpv5-d16/hard
pwd: /home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/arm-rtems4.12
mkdir thumb/cortex-m7
mkdir thumb/cortex-m7/fpv5-d16
mkdir thumb/cortex-m7/fpv5-d16/hard
configure: creating cache ./config.cache
checking build system type... x86_64-pc-linux-gnu
checking host system type... arm-unknown-rtems4.12
checking for --enable-version-specific-runtime-libs... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking for arm-rtems4.12-ar... /home/simon.williams/rtems/4.12/arm-rtems4.12/bin/ar
checking for arm-rtems4.12-lipo... arm-rtems4.12-lipo
checking for arm-rtems4.12-nm... /home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/./gcc/nm
checking for arm-rtems4.12-ranlib... /home/simon.williams/rtems/4.12/arm-rtems4.12/bin/ranlib
checking for arm-rtems4.12-strip... /home/simon.williams/rtems/4.12/arm-rtems4.12/bin/strip
checking whether ln -s works... yes
checking for arm-rtems4.12-gcc... /home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/./gcc/xgcc -B/home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/./gcc/ -nostdinc -B/home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/arm-rtems4.12/thumb/cortex-m7/fpv5-d16/hard/newlib/ -isystem /home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/arm-rtems4.12/thumb/cortex-m7/fpv5-d16/hard/newlib/targ-include -isystem /home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/gcc-6-20160117/newlib/libc/include -B/home/simon.williams/rtems/4.12/arm-rtems4.12/bin/ -B/home/simon.williams/rtems/4.12/arm-rtems4.12/lib/ -isystem /home/simon.williams/rtems/4.12/arm-rtems4.12/include -isystem /home/simon.williams/rtems/4.12/arm-rtems4.12/sys-include -mthumb -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard
configure: error: in `/home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/arm-rtems4.12/thumb/cortex-m7/fpv5-d16/hard/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
Sebastian commented that the binutils being used was out of date and I noticed that it was picking up the binutils from my previous build. I removed the previous build from my PATH, but got the same issue. I examined the logs and discovered that RSB was adding the installation bin directory to the PATH while executing. I renamed the original $PREFIX so that it was no longer building into an existing directory and the build ran successfully.
It appears that RSB will not build newlib successfully if it is installing into the same location as a previous build that does not contain compatible tools.
Author: Trac Migrate
2017-01-26T07:16:00.000Z
Original author: williamssimonp
Milestone changed from %”4.11.1” to %”4.11.2”
Author: Trac Migrate
2017-02-15T13:37:51.000Z
Original author: williamssimonp
Milestone changed from %”4.11.2” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Trac Migrate
2017-10-05T07:54:29.000Z
Original author: williamssimonp
The RSB output currently looks like this
RTEMS Source Builder - Set Builder, 4.12 (1f3f21ed306b) warning: exe: absolute exe found in path: (__chown) /usr/sbin/chown Build Set: 4.12/rtems-all Build Set: 4.12/rtems-arm.bset Build Set: 4.12/rtems-autotools.bset Build Set: 4.12/rtems-autotools-internal.bset config: tools/rtems-autoconf-2.69-1.cfg package: autoconf-2.69-x86_64-linux-gnu-1 building: autoconf-2.69-x86_64-linux-gnu-1 config: tools/rtems-automake-1.12.6-1.cfg package: automake-1.12.6-x86_64-linux-gnu-1 building: automake-1.12.6-x86_64-linux-gnu-1 cleaning: autoconf-2.69-x86_64-linux-gnu-1 cleaning: automake-1.12.6-x86_64-linux-gnu-1 Build Set: Time 0:00:06.855472 Build Set: 4.12/rtems-autotools-base.bset config: tools/rtems-autoconf-2.69-1.cfg package: autoconf-2.69-x86_64-linux-gnu-1 building: autoconf-2.69-x86_64-linux-gnu-1 reporting: tools/rtems-autoconf-2.69-1.cfg -> autoconf-2.69-x86_64-linux-gnu-1.txt reporting: tools/rtems-autoconf-2.69-1.cfg -> autoconf-2.69-x86_64-linux-gnu-1.xml config: tools/rtems-automake-1.12.6-1.cfg package: automake-1.12.6-x86_64-linux-gnu-1 building: automake-1.12.6-x86_64-linux-gnu-1 reporting: tools/rtems-automake-1.12.6-1.cfg -> automake-1.12.6-x86_64-linux-gnu-1.txt reporting: tools/rtems-automake-1.12.6-1.cfg -> automake-1.12.6-x86_64-linux-gnu-1.xml installing: autoconf-2.69-x86_64-linux-gnu-1 -> /build/rtems-4.12 installing: automake-1.12.6-x86_64-linux-gnu-1 -> /build/rtems-4.12 cleaning: autoconf-2.69-x86_64-linux-gnu-1 cleaning: automake-1.12.6-x86_64-linux-gnu-1 Build Set: Time 0:00:09.739262 Build Set: Time 0:00:16.598011 config: devel/expat-2.1.0-1.cfg package: expat-2.1.0-x86_64-linux-gnu-1 building: expat-2.1.0-x86_64-linux-gnu-1 reporting: devel/expat-2.1.0-1.cfg -> expat-2.1.0-x86_64-linux-gnu-1.txt reporting: devel/expat-2.1.0-1.cfg -> expat-2.1.0-x86_64-linux-gnu-1.xml config: tools/rtems-binutils-2.29-1.cfg package: arm-rtems4.12-binutils-2.29-x86_64-linux-gnu-1 building: arm-rtems4.12-binutils-2.29-x86_64-linux-gnu-1 reporting: tools/rtems-binutils-2.29-1.cfg -> arm-rtems4.12-binutils-2.29-x86_64-linux-gnu-1.txt reporting: tools/rtems-binutils-2.29-1.cfg -> arm-rtems4.12-binutils-2.29-x86_64-linux-gnu-1.xml config: tools/rtems-gcc-7.2.0-newlib-2.5.0.20170922-1.cfg package: arm-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170922-x86_64-linux-gnu-1 building: arm-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170922-x86_64-linux-gnu-1 reporting: tools/rtems-gcc-7.2.0-newlib-2.5.0.20170922-1.cfg -> arm-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170922-x86_64-linux-gnu-1.txt reporting: tools/rtems-gcc-7.2.0-newlib-2.5.0.20170922-1.cfg -> arm-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170922-x86_64-linux-gnu-1.xml config: tools/rtems-gdb-8.0.1-1.cfg package: arm-rtems4.12-gdb-8.0.1-x86_64-linux-gnu-1 building: arm-rtems4.12-gdb-8.0.1-x86_64-linux-gnu-1 reporting: tools/rtems-gdb-8.0.1-1.cfg -> arm-rtems4.12-gdb-8.0.1-x86_64-linux-gnu-1.txt reporting: tools/rtems-gdb-8.0.1-1.cfg -> arm-rtems4.12-gdb-8.0.1-x86_64-linux-gnu-1.xml config: tools/rtems-tools-4.12-1.cfg package: rtems-tools-HEAD-1 git: reset: git://git.rtems.org/rtems-tools.git git: fetch: git://git.rtems.org/rtems-tools.git -> sources/git/rtems-tools.git git: checkout: git://git.rtems.org/rtems-tools.git => HEAD git: pull: git://git.rtems.org/rtems-tools.git building: rtems-tools-HEAD-1 reporting: tools/rtems-tools-4.12-1.cfg -> rtems-tools-HEAD-1.txt reporting: tools/rtems-tools-4.12-1.cfg -> rtems-tools-HEAD-1.xml config: tools/rtems-kernel-4.12.cfg package: arm-rtems4.12-kernel-4.12-1 building: arm-rtems4.12-kernel-4.12-1 reporting: tools/rtems-kernel-4.12.cfg -> arm-rtems4.12-kernel-4.12-1.txt reporting: tools/rtems-kernel-4.12.cfg -> arm-rtems4.12-kernel-4.12-1.xml installing: expat-2.1.0-x86_64-linux-gnu-1 -> /build/rtems-4.12 installing: arm-rtems4.12-binutils-2.29-x86_64-linux-gnu-1 -> /build/rtems-4.12 installing: arm-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170922-x86_64-linux-gnu-1 -> /build/rtems-4.12 installing: arm-rtems4.12-gdb-8.0.1-x86_64-linux-gnu-1 -> /build/rtems-4.12 installing: rtems-tools-HEAD-1 -> /build/rtems-4.12 installing: arm-rtems4.12-kernel-4.12-1 -> /build/rtems-4.12 cleaning: expat-2.1.0-x86_64-linux-gnu-1 cleaning: arm-rtems4.12-binutils-2.29-x86_64-linux-gnu-1 cleaning: arm-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170922-x86_64-linux-gnu-1 cleaning: arm-rtems4.12-gdb-8.0.1-x86_64-linux-gnu-1 cleaning: rtems-tools-HEAD-1 cleaning: arm-rtems4.12-kernel-4.12-1 Build Set: Time 0:34:45.297368The autotools are installed before the other stuff which is installed in one big chunk. Maybe this sequence should be changed to install each component as soon as possible, e.g. Binutils before GCC.
Author: Chris Johns
2017-10-05T22:13:58.000Z
Original author: williamssimonp
Replying to Sebastian Huber:
The autotools are installed before the other stuff which is installed in one big chunk.
The autotools should be installed to an internally path to be available for the build if required and installed at the end when the build finishes. It is a tricky dependence issue that has been in the RSB from its early days.
Maybe this sequence should be changed to install each component as soon as possible, e.g. Binutils before GCC.
This is dangerous and it should never happen. I will not be supporting any change to do this.
An RSB buildset build must be viewed as a single transaction that must succeed to ensure we are able to say the build installed meets the configuration management requirements. We need to know what we have described in the build is install. If the build fails in any way no part should be installed.
If you are installing over an existing installation you could end up with a hybrid of unknown versions which are not configuration controlled. They may appear to work and subtlety fail and that is dangerous or the failures maybe major such as code not building and we would need to field those report and figure out what is wrong and that is an overhead I would not like the project to have.
The RSB provides the
sb-buildcommand that lets you step down from the build sets to control specific parts. It is more complicated and may not work given some the way the build sets have developed over the last 5 or so years.In respect to this ticket I wonder if the user’s path has the install prefix’s
bindirectory in it and this is effecting the packaging being built by referencing the already installed tools.
Author: Trac Migrate
2017-10-06T05:10:30.000Z
Original author: williamssimonp
Ok, now the intention is clear to me, however, the GCC build system adds the prefix to the search paths via:
-B/${prefix}/${target}/bin/ -B/${prefix}/${target}/lib/ -isystem /${prefix}/${target}/include -isystem /${prefix}/${target}/sys-includeFrom my point of view this is a GCC build system bug. I always delete the prefix before I build anything with RSB.
Author: Chris Johns
2017-10-06T05:31:41.000Z
Original author: williamssimonp
Replying to Sebastian Huber:
Ok, now the intention is clear to me, however, the GCC build system adds the prefix to the search paths via: {{{ -B/${prefix}/${target}/bin/ -B/${prefix}/${target}/lib/ -isystem /${prefix}/${target}/include -isystem /${prefix}/${target}/sys-include }}} From my point of view this is a GCC build system bug.
Yes, gcc doing this is not helpful.
I always delete the prefix before I build anything with RSB.
I do from time to time but no always and I suppose I do not see any issues because I incrementally bump the tool versions while a jump could have real issues.
This is tricky to resolve within the RSB. For example if the RSB removed the
${PREFIX}with each build automatically you would not be able to build RTEMS 3rd party libraries with the same prefix you built the tools with because the tools would have been deleted.
Author: Trac Migrate
2018-11-13T06:12:51.000Z
Original author: williamssimonp
Maybe the RSB should warn that there are already tools installed in the prefix and offer an option to remove them.
For example building the latest or1k tool chain failed since I had the previous tools installed in $prefix. During GCC build the Binutils of $prefix are used and not the ones which are newly built.
Author: Chris Johns
2018-11-13T06:44:00.000Z
Original author: williamssimonp
Replying to Sebastian Huber:
Maybe the RSB should warn that there are already tools installed in the prefix and offer an option to remove them.
A prefix can be a shared resource used by a number of packages so what are you asking is removed?
The RSB has no concept or knowledge of what the package actually installs so how would it be able to remove these specific parts. This is what distro packaging systems do.
For example building the latest or1k tool chain failed since I had the previous tools installed in $prefix. During GCC build the Binutils of $prefix are used and not the ones which are newly built.
All I can suggest is you wrap the RSB in the distro system of your choice and deploy the tools that way if you want to track specific files in packages.
I think the real issue is not this but the build. The RSB build of the RTEMS tools should be looking to use the binutils just built however for some reason gcc must be looking in the
$prefixbefore the$PATHand when the$prefixis empty it uses the binutils in the$PATH, after all this is what happens when there are no tools installed. Does an option exist in gcc to control this order?
Author: Trac Migrate
2018-11-13T06:54:51.000Z
Original author: williamssimonp
Replying to Chris Johns:
Replying to Sebastian Huber:
Maybe the RSB should warn that there are already tools installed in the prefix and offer an option to remove them.
A prefix can be a shared resource used by a number of packages so what are you asking is removed?
What I did is this:
find /build/rtems/5/ -name ‘or1k’ | xargs rm -r
Yes, a bit dangerous. Maybe if a find $prefix -name “$target” finds something, then we can stop the build. The user has then the choice to remove it on its own or use a –force-build-with-existing-tools option.
The RSB has no concept or knowledge of what the package actually installs so how would it be able to remove these specific parts. This is what distro packaging systems do.
For example building the latest or1k tool chain failed since I had the previous tools installed in $prefix. During GCC build the Binutils of $prefix are used and not the ones which are newly built.
All I can suggest is you wrap the RSB in the distro system of your choice and deploy the tools that way if you want to track specific files in packages. I think the real issue is not this but the build. The RSB build of the RTEMS tools should be looking to use the binutils just built however for some reason gcc must be looking in the
$prefixbefore the$PATHand when the$prefixis empty it uses the binutils in the$PATH, after all this is what happens when there are no tools installed. Does an option exist in gcc to control this order?I am not sure if this can be fixed by changes in $PATH. In the GCC build tree there is for example an “as” script which is generated:
grep -r ORIGINAL_AS_FOR_TARGET gcc/Makefile.in:ORIGINAL_AS_FOR_TARGET = @ORIGINAL_AS_FOR_TARGET@ gcc/configure.ac:ORIGINAL_AS_FOR_TARGET=$gcc_cv_as gcc/configure.ac:AC_SUBST(ORIGINAL_AS_FOR_TARGET) gcc/configure.ac:case "$ORIGINAL_AS_FOR_TARGET" in gcc/exec-tool.in:ORIGINAL_AS_FOR_TARGET="@ORIGINAL_AS_FOR_TARGET@" gcc/exec-tool.in: original=$ORIGINAL_AS_FOR_TARGET gcc/ChangeLog-2005: * Makefile.in (stamp-as): Use $(ORIGINAL_AS_FOR_TARGET) gcc/ChangeLog-2005: (ORIGINAL_AS_FOR_TARGET, ORIGINAL_LD_FOR_TARGET, gcc/configure:ORIGINAL_AS_FOR_TARGET gcc/configure:ORIGINAL_AS_FOR_TARGET=$gcc_cv_as gcc/configure:case "$ORIGINAL_AS_FOR_TARGET" inIt uses absolute paths found during configure time (I guess).
Author: Chris Johns
2018-11-14T07:01:36.000Z
Original author: williamssimonp
Replying to Sebastian Huber:
Replying to Chris Johns:
Replying to Sebastian Huber:
Maybe the RSB should warn that there are already tools installed in the prefix and offer an option to remove them.
A prefix can be a shared resource used by a number of packages so what are you asking is removed?
What I did is this: find /build/rtems/5/ -name ‘or1k’ | xargs rm -r Yes, a bit dangerous. Maybe if a find $prefix -name “$target” finds something, then we can stop the build. The user has then the choice to remove it on its own or use a –force-build-with-existing-tools option.
It is dangerous. An example of the problems this exposes is the lack of an undo, a user attempts a build which fails and the previous working installed tools have been removed. I then get requests to not do this.
I think the real issue is not this but the build. The RSB build of the RTEMS tools should be looking to use the binutils just built however for some reason gcc must be looking in the
$prefixbefore the$PATHand when the$prefixis empty it uses the binutils in the$PATH, after all this is what happens when there are no tools installed. Does an option exist in gcc to control this order?I am not sure if this can be fixed by changes in $PATH. In the GCC build tree there is for example an “as” script which is generated: {{{ grep -r ORIGINAL_AS_FOR_TARGET gcc/Makefile.in:ORIGINAL_AS_FOR_TARGET = @ORIGINAL_AS_FOR_TARGET@ gcc/configure.ac:ORIGINAL_AS_FOR_TARGET=$gcc_cv_as gcc/configure.ac:AC_SUBST(ORIGINAL_AS_FOR_TARGET) gcc/configure.ac:case “$ORIGINAL_AS_FOR_TARGET” in gcc/exec-tool.in:ORIGINAL_AS_FOR_TARGET=”@ORIGINAL_AS_FOR_TARGET@” gcc/exec-tool.in: original=$ORIGINAL_AS_FOR_TARGET gcc/ChangeLog-2005: * Makefile.in (stamp-as): Use $(ORIGINAL_AS_FOR_TARGET) gcc/ChangeLog-2005: (ORIGINAL_AS_FOR_TARGET, ORIGINAL_LD_FOR_TARGET, gcc/configure:ORIGINAL_AS_FOR_TARGET gcc/configure:ORIGINAL_AS_FOR_TARGET=$gcc_cv_as gcc/configure:case “$ORIGINAL_AS_FOR_TARGET” in }}} It uses absolute paths found during configure time (I guess).
I think binutils is relocatable so I wonder if the pre-installed tools that have been built and waiting for the whole package to finish building can be used. Does
--with-astake a path to an executable?
Author: Trac Migrate
2018-11-14T07:46:18.000Z
Original author: williamssimonp
Replying to Chris Johns:
Replying to Sebastian Huber:
Replying to Chris Johns:
Replying to Sebastian Huber:
Maybe the RSB should warn that there are already tools installed in the prefix and offer an option to remove them.
A prefix can be a shared resource used by a number of packages so what are you asking is removed?
What I did is this: find /build/rtems/5/ -name ‘or1k’ | xargs rm -r Yes, a bit dangerous. Maybe if a find $prefix -name “$target” finds something, then we can stop the build. The user has then the choice to remove it on its own or use a –force-build-with-existing-tools option.
It is dangerous. An example of the problems this exposes is the lack of an undo, a user attempts a build which fails and the previous working installed tools have been removed. I then get requests to not do this.
I think the real issue is not this but the build. The RSB build of the RTEMS tools should be looking to use the binutils just built however for some reason gcc must be looking in the
$prefixbefore the$PATHand when the$prefixis empty it uses the binutils in the$PATH, after all this is what happens when there are no tools installed. Does an option exist in gcc to control this order?I am not sure if this can be fixed by changes in $PATH. In the GCC build tree there is for example an “as” script which is generated: {{{ grep -r ORIGINAL_AS_FOR_TARGET gcc/Makefile.in:ORIGINAL_AS_FOR_TARGET = @ORIGINAL_AS_FOR_TARGET@ gcc/configure.ac:ORIGINAL_AS_FOR_TARGET=$gcc_cv_as gcc/configure.ac:AC_SUBST(ORIGINAL_AS_FOR_TARGET) gcc/configure.ac:case “$ORIGINAL_AS_FOR_TARGET” in gcc/exec-tool.in:ORIGINAL_AS_FOR_TARGET=”@ORIGINAL_AS_FOR_TARGET@” gcc/exec-tool.in: original=$ORIGINAL_AS_FOR_TARGET gcc/ChangeLog-2005: * Makefile.in (stamp-as): Use $(ORIGINAL_AS_FOR_TARGET) gcc/ChangeLog-2005: (ORIGINAL_AS_FOR_TARGET, ORIGINAL_LD_FOR_TARGET, gcc/configure:ORIGINAL_AS_FOR_TARGET gcc/configure:ORIGINAL_AS_FOR_TARGET=$gcc_cv_as gcc/configure:case “$ORIGINAL_AS_FOR_TARGET” in }}} It uses absolute paths found during configure time (I guess).
I think binutils is relocatable so I wonder if the pre-installed tools that have been built and waiting for the whole package to finish building can be used. Does
--with-astake a path to an executable?I have absolutely no confidence in the GCC build system. I am not sure if this will ever work reliably. I would
try to detect that an installation exists in the prefix,
stop building if an installation exists unless a special option is given.
Author: Trac Migrate
2018-11-14T07:47:37.000Z
Original author: williamssimonp
The Ada build has also a problem if there already exists an installation. The install procedure aborts with a file permission error.
Author: Chris Johns
2018-11-15T00:45:51.000Z
Original author: williamssimonp
Replying to Sebastian Huber:
I have absolutely no confidence in the GCC build system.
I do not know gcc’s build system enough to comment. It is a bit of a beast.
I am not sure if this will ever work reliably.
I see value in what you are asking and it raises the important broader question of “What a
$prefixtree of RTEMS tools means?”. We currently assume a release$prefixis a single release however there are no checks made. You are in fact asking we create a new policy that the RSB has avoided until now. Such a policy will exist for ever so I think it would be good to flesh out what it is and what it means.I would 1. try to detect that an installation exists in the prefix,
Does this mean we can update a single variant of a package in the
$prefixand not the other variants? Do we allow a user to have an arch of one build and another arch on a different build?Is the detect test per package or common to all packages? If common to all packages, ie in the RSB’s python, how would you implement it? I think a common test is too hard.
A per-package test could be implemented with a worker script called from the config script using
$(). I did this in the gdb config to find the Python header and library before building gdb. The issue here is implementing the test in each step that matters in a package’s build, ie the binutils and gcc for tool sets.GCC has the RSB hash embedded in it and can be found with:
$prefix/arm-rtems5-gcc --version | awk ' /.*-gcc/ { print substr($8, 1, length($8) - 1); }' 30da0c720b78eba16a3f5272206c07415368617bCan an RSB hash be added to the GNU
asandldversion string? I think this would be needed to make adding any test worthwhile.
stop building if an installation exists unless a special option is given..
I am not a fan of adding extra options. I do not see a need at this point in time. I feel removing installed files or attempting to automatically clean up is a complex hole we should avoid. We could just document what users need to do if they see warnings or errors.
How would you build more than one variant of a packages, ie different arch tool sets? This feeds back to the per-package vs all packages testing of installed packages.
Do we stop for all build types or just release builds? We have two contexts, a development context where we are working with different tool sets and sometimes in different configurations and then we have the release context. Maybe in the development context a warning is printed and in the release context an error is produced.
Author: Trac Migrate
2018-11-15T10:20:51.000Z
Original author: williamssimonp
I don’t have a solution for this problem. Normally I just delete the prefix before I start the RSB. While testing the new or1k tool chain I forgot to do this and got a GCC build error. Even though I know that the RSB build is broken with an existing installation in the prefix I didn’t think about this and assumed that the new upstream or1k support in GCC is broken.
Author: Chris Johns
2018-11-17T01:20:21.000Z
Original author: williamssimonp
Replying to Sebastian Huber:
I don’t have a solution for this problem.
I did outline one :)
Normally I just delete the prefix before I start the RSB. While testing the new or1k tool chain I forgot to do this and got a GCC build error.
Even though I know that the RSB build is broken with an existing installation in the prefix
The RSB is not broken, it is doing what it is suppose to do. It is the package that is being built that is broken or it is the configuration in the RSB that could be improved. Adding shell call-outs using
$()to check the installed version to the gcc tool set scripts would work but we need an RSB signature inasandld.I didn’t think about this and assumed that the new upstream or1k support in GCC is broken.
Then please raise this with gcc or fix it’s build so we can control where it looks for
as. It is a weakness with gcc’s build we cannot control theasused.Adding an RSB signature to
asandldis something that should happen.
Author: Trac Migrate
2018-11-17T18:23:46.000Z
Original author: williamssimonp
It is not just the Binutils that make problems. There are at least five issues in case a tool chain is already present.
The build uses the existing Binutils instead of the ones built right now.
Some header and other files of the existing installation may be used instead of the one from the current sources.
The installation adds only files, it does not remove obsolete files leaving a mixture of old and new files in the prefix.
The Ada installation stops with permission errors.
In case something goes wrong it is not easy to figure out that the reason is an existing installation that interfered.
Author: Chris Johns
2018-11-18T21:34:55.000Z
Original author: williamssimonp
Replying to Sebastian Huber:
It is not just the Binutils that make problems. There are at least five issues in case a tool chain is already present. 1. The build uses the existing Binutils instead of the ones built right now.
If I used the same prefix as an bare metal ELF tool chain could gcc pick up that assembler?
Do we need more or better documentation on the
$prefixin the User manual?
Some header and other files of the existing installation may be used instead of the one from the current sources.
Why is gcc doing this? It seems wrong and dangerous.
The installation adds only files, it does not remove obsolete files leaving a mixture of old and new files in the prefix.
The binutils and gcc do just this as well. The RSB is not a packaging or deployment tool. That is a role I see existing outside of the RTEMS project where specialisation and support can happen.
The Ada installation stops with permission errors.
I thought this was in the Ada build when run from python?
In case something goes wrong it is not easy to figure out that the reason is an existing installation that interfered.
Agreed, but why is it the role of the RSB tool (not the configuration parts) to deal with this?
I have offered a solution and I am willing to review patches.
Author: Trac Migrate
2018-11-19T06:13:51.000Z
Original author: williamssimonp
Replying to Chris Johns:
Replying to Sebastian Huber:
It is not just the Binutils that make problems. There are at least five issues in case a tool chain is already present. 1. The build uses the existing Binutils instead of the ones built right now.
If I used the same prefix as an bare metal ELF tool chain could gcc pick up that assembler?
I don’t know.
Do we need more or better documentation on the
$prefixin the User manual?Yes, I didn’t find a hint that an existing installation may interfere with the current build.
Some header and other files of the existing installation may be used instead of the one from the current sources.
Why is gcc doing this? It seems wrong and dangerous.
https://devel.rtems.org/ticket/2540#comment:5
The installation adds only files, it does not remove obsolete files leaving a mixture of old and new files in the prefix.
The binutils and gcc do just this as well. The RSB is not a packaging or deployment tool. That is a role I see existing outside of the RTEMS project where specialisation and support can happen.
I think this should be clarified in the documentation.
The Ada installation stops with permission errors.
I thought this was in the Ada build when run from python?
As far as I remember it was an issue in the Python copytree area.
In case something goes wrong it is not easy to figure out that the reason is an existing installation that interfered.
Agreed, but why is it the role of the RSB tool (not the configuration parts) to deal with this? I have offered a solution and I am willing to review patches.
I think your proposal is fine. I just wanted to highlight that there are multiple problems if you have an existing installation.
Author: Amar Takhar
2025-09-05T03:00:57.890Z
changed the description
2506 - RTEMS Linker and Tester Wiki Confusion (opened)¶
Id |
2506 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Chris Johns |
Created |
2016-01-01T17:43:46.000Z |
Updated |
2025-09-19T01:46:10.423Z |
Milestone |
5.4 |
Labels |
doc, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
https://devel.rtems.org/wiki/Developer/Tools has two links in the first bullet list which do not go to pages.
RTEMS Linker
RTEMS Tester
RTEMS Trace Linker has a write up at https://devel.rtems.org/wiki/Developer/Tracing/Trace_Linker but in a couple of places uses the phrase “RTEMS Linker.”
I think the references to RTEMS Linker on the RTEMS Trace Linker page are incorrect but you need to judge.
Is there a page for the RTEMS Linker as used for dynamic loading?
Is there a page for the RTEMS Tester so the link can be fixed?
If nothing else, I think you have some notes that could be inserted into starting points on the pages.
Author: Chris Johns
2016-01-03T23:09:10.000Z
The missing links need pages added. We need to review and update the existing content if present and either move it to a suitable spot in the new wiki’s tree and update if needed or provide a new page.
I would rather need pages added or moves and updated than linking to some of the existing pages. Having out of date or invalid pages can be worse than nothing at all.
Author: Gedare Bloom
2016-01-04T02:06:02.000Z
You can make this a GCI task if you want, either to follow through on this ticket, or create a few discrete tasks related to the specific pages you want dealt with.
Author: Chris Johns
2016-01-04T02:17:14.000Z
As you point out the trace linker is referenced under tracing. I think we need a page under the tools project about the tool and development of it. I am not sure how to create a suitable GCI task for this.
I am not sure the RTEMS linker is a suitable GCI topic, it is a complex topic. It will take me a while to figure out the details.
Author: Trac Migrate
2017-05-11T07:31:02.000Z
Milestone changed from %”4.12” to %”4.12.0”
Author: Chris Johns
2017-10-11T23:31:26.000Z
Milestone changed from %”4.12.0” to %”Indefinite”
I have added pages in the wiki pointing to the RTEMS User Guide however the RTEMS Linker is not documented in the User Guide yet. I am not sure when I can get to this and it should not hold a release up.
Author: Amar Takhar
2025-09-05T03:00:57.390Z
changed the description
2492 - Delete https://devel.rtems.org/wiki/TBR/Delete/Documentation ? (opened)¶
Id |
2492 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2015-12-13T23:04:03.000Z |
Updated |
2025-09-19T01:46:10.323Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: heshamelmatary
The following is Tangem’s suggestion from GCI.
“The cpukit doxygen link and the 3 links at the top in the release manuals are broken. The other manuals state a outdated OAR copyright and I’m not sure whether those should or can be changed. Deleting the page and replacing the link on the main page with this [1] or this [2] might be a good idea.”
As Chris suggested, getting a new HTML page here [3] would be great.
[1] https://docs.rtems.org/ [2] https://www.rtems.org/onlinedocs.htm [3] https://docs.rtems.org/
Author: Trac Migrate
2017-02-15T14:20:42.000Z
Original author: heshamelmatary
Milestone changed from %”4.12” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:02:25.258Z
changed the description
2463 - rtems-syms assumes that 4.11 tools are installed (opened)¶
Id |
2463 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2015-11-10T08:23:30.000Z |
Updated |
2025-09-19T01:46:10.206Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
For example:
gmake[7]: Entering directory `/scratch/git-rtems-testing/rtems/build-arm-realview_pbx_a9_qemu-rtems/arm-rtems4.12/c/realview_pbx_a9_qemu/testsuites/libtests/dl01'
arm-rtems4.12-gcc -B../../../../../realview_pbx_a9_qemu/lib/ -specs bsp_specs -qrtems -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -o dl01.pre.exe init.o dl-load.o dl-tar.o
arm-rtems4.12-nm -g -n dl01.pre.exe > dl01.pre.num
arm-rtems4.12-size dl01.pre.exe
text data bss dec hex filename
233464 1820 267135168 267370452 fefbfd4 dl01.pre.exe
cp dl01.pre.exe dl01.pre.ralf
rm -f dl01.pre.ralf
mv dl01.pre.exe dl01.pre
rtems-syms -e -c "-march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs" -o dl-sym.o dl01.pre
: error trying to exec 'arm-rtems4.11-gcc': execvp: No such file or directory
error: compiling wrapper: Compiler error
gmake[7]: *** [dl-sym.o] Error 10
Author: Chris Johns
2015-11-11T00:15:23.000Z
Original author: sebastian.huber
If we use 4.11 tools for 4.12 then this error is expected.
We could provide the version number on the command line and it would not matter.
Author: Chris Johns
2015-11-11T00:16:19.000Z
Original author: sebastian.huber
Why do we have arm-rtems4.11-gcc rather than arm-rtems-gcc?
Author: Chris Johns
2015-11-11T07:48:23.000Z
Original author: sebastian.huber
Replying to sebastian.huber:
Replying to chrisj:
Why do we have arm-rtems4.11-gcc rather than arm-rtems-gcc?
See #2377.
Haha yes I remember now. I have been thinking about the original reason and that was RPM files built and installing in to a common prefix. With the RSB we have moved to using different prefix paths and this makes the version number in the tool name redundant.
Author: Trac Migrate
2017-02-15T14:20:42.000Z
Original author: sebastian.huber
Milestone changed from %”4.12” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:02:24.439Z
changed the description
2434 - general gpio.h is no longer installed leading to build breakage (opened)¶
Id |
2434 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2015-10-21T14:57:04.000Z |
Updated |
2025-09-19T01:46:09.956Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, resolution::fixed, tickettype::defect, version::4.10, version::4.12, version::5 |
Link |
|
Merges |
0 |
Original author: beng
The bsp-general <bsp/gpio.h> is no longer pre-installed, presumably since commit 5458bff92 regenerated preinstall.am. This causes build breakage for BSP’s implementing the gpio interface (e.g. beagle):
arm-rtems4.11-gcc –pipe -B../../../../../.././lib/ -B../../../../../.././beagleboneblack/lib/ -specs bsp_specs -qrtems -DHAVE_CONFIG_H -I../../../../../../../../rtems-src/c/src/lib/libbsp/arm/beagle/../../../libcpu/arm/shared/include -mcpu=cortex-a8 -O2 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT libbsp_a-gpio.o -MD -MP -MF .deps/libbsp_a-gpio.Tpo -c -o libbsp_a-gpio.o test -f '../../shared/gpio.c' || echo '../../../../../../../../rtems-src/c/src/lib/libbsp/arm/beagle/'../../shared/gpio.c
../../../../../../../../rtems-src/c/src/lib/libbsp/arm/beagle/../../shared/gpio.c:20:22: fatal error: bsp/gpio.h: No such file or directory
include <bsp/gpio.h>¶
Thanks for Claudio Scordino and Debajyoti Majumdar for their interest in the Beagle BSP and for reporting this problem.
Author: Trac Migrate
2015-10-21T14:58:23.000Z
Original author: beng
Attachment fix-2434.txt added
Proposed patch
Author: Joel Sherrill
2015-10-21T15:02:52.000Z
Original author: beng
Feel free to apply this to the master and 4.11 branch as appropriate.
Author: Trac Migrate
2015-10-21T15:07:17.000Z
Original author: beng
Owner set to Ben Gras <beng@rtems.org>
Resolution set to ~”fixed”
Status changed from new to closed
In changeset 6f6e5d758f6a1e7dcae74e151c3dd3d1034da232:
libbsp/Makefile.am: gpio.h as preinstalled header Also regenerate preinstall.am. Closes #2434.
Author: Trac Migrate
2015-11-10T09:17:33.000Z
Original author: beng
Milestone changed from %”4.11.1” to %”4.12”
Resolution ~”fixed” deleted
Status changed from closed to reopened
Version changed from ~”4.10” to ~”4.12”
On 06/11/15 23:57, André Marques wrote:
Hello, This issue was resolved earlier with the following patch https://git.rtems.org/rtems/commit/c/src/lib/libbsp/Makefile.am?id=a57b72ded94b4e77fd4f9bd3cc37380a02e3e35a where the inclusion of the GPIO API header file was removed from the libbsp/shared makefile and moved (in the case of the Raspberry Pi, but I forgot about the beagle BSP) to the BSP makefile which intends to use the API. This avoids these name clashes with BSPs that already have a gpio.h header file. However the following patch reintroduced the gpio API header on the libbsp/shared makefile https://git.rtems.org/rtems/commit/c/src/lib/libbsp/Makefile.am?id=6f6e5d758f6a1e7dcae74e151c3dd3d1034da232 This last patch should be reverted, and the shared/include/gpio.h should be included in the beagle BSP makefile that requires it, and motivated this reintroduction. I think it is better to have the BSPs include the gpio API header file if they actually implement the API, than forcing the header to all BSPs and creating these problems. Às 14:29 de 05-11-2015, Sebastian Huber escreveu:
On 05/11/15 15:17, Martin Galvan wrote:
The LPC1768 variants have a gpio.h file whose name clashes with the gpio.h from the new GPIO API. This results on the BSPs failing to compile. This patch renames the LPC1768 gpio.* files to lpc-gpio.*, as it’s done on other BSPs (e.g. Beaglebone). Closes #2441.
Thanks.
Author: Trac Migrate
2015-11-11T14:51:44.000Z
Original author: beng
All,
I see, sorry everyone, I wasn’t aware of this problem.
Sebastian writes:
I think it is better to have the BSPs include the gpio API header file if they actually implement the API, than forcing the header to all BSPs and creating these problems.
As I see it, gpio.h is generic to BSPs (it describes a BSP-generic API) and so ought to be safe to install unconditionally.
Installing it only whenever BSPs implement the API isn’t perfect either, as that precludes that BSP from having an installed gpio.h should they want it.
Can we install it unconditionally in a path that is safe from BSP-specific clashes?
Author: Trac Migrate
2015-11-11T14:55:37.000Z
Original author: beng
Or perhaps we can rename the generic gpio.h to a more specific name such as gpio-api.h.
Author: Chris Johns
2015-11-12T05:27:40.000Z
Original author: beng
Replying to beng:
Sebastian writes:
I think it is better to have the BSPs include the gpio API header file if they actually implement the API, than forcing the header to all BSPs and creating these problems.
As I see it, gpio.h is generic to BSPs (it describes a BSP-generic API) and so ought to be safe to install unconditionally.
I agree with Ben and once we move to waf and have a single header tree with no pre-install stage this will be the case by default. We should have it in the tree now.
Installing it only whenever BSPs implement the API isn’t perfect either, as that precludes that BSP from having an installed gpio.h should they want it.
Lets not do this.
Can we install it unconditionally in a path that is safe from BSP-specific clashes?
This will not happen in the single include tree.
The documentation for the BSP should clearly indicate the BSP supports GPIO. If I have selected a BSP without any GPIO pins and I need them I should consider a different career path. If the BSP has GPIO but no GPIO API support I should add the support.
Replying to beng:
Or perhaps we can rename the generic gpio.h to a more specific name such as gpio-api.h.
Please to not add ‘api’ to a header file name as a header by definition is an API. Should we add -c-language, -textfile etc as well? ;)
Author: Trac Migrate
2015-11-18T16:01:58.000Z
Original author: beng
I don’t think we have agreed on a way out here, or did I miss something?
Or perhaps we can rename the generic gpio.h to a more specific name such as gpio-api.h.
Please to not add ‘api’ to a header file name as a header by definition is an API. Should we add -c-language, -textfile etc as well? ;)
Point taken, though I’m not sure I agree all .h files describe such a ‘public’ API. It seems to me something like what I suggested (rename gpio.h to something that a BSP would never name it) is a simple and reasonably clean (the BSP’s won’t have to be touched) way out. Is another name an option for you Chris? E.g. gpio-shared.h?
Author: Trac Migrate
2017-05-11T07:31:02.000Z
Original author: beng
Milestone changed from %”4.12” to %”4.12.0”
Author: Trac Migrate
2017-08-24T06:27:03.000Z
Original author: beng
Milestone changed from %”4.12.0” to %”Indefinite”
Author: Amar Takhar
2025-09-05T03:02:23.325Z
changed the description
2370 - rtems/c/src/lib/libbsp/powerpc/mvme5500/network/if_1GHz/if_wm.c:1560: possible bad if ? (opened)¶
Id |
2370 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2015-07-14T20:14:21.000Z |
Updated |
2025-09-19T01:46:09.852Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: dcb
[rtems/c/src/lib/libbsp/powerpc/mvme5500/network/if_1GHz/if_wm.c:1560]: (style) Expression ‘(X & 0xe) == 0x1’ is always false.
Source code is
/* XXX Hardware bug?? */ if ((reg & 0xe) == 1) {
Author: Joel Sherrill
2015-07-14T20:19:51.000Z
Original author: dcb
I didn’t check this file but assume it is based on the one in NetBSD.
Double check me but I think the code is now this:
/* XXX Hardware bug?? */ if (sc->sc_type == WM_T_82544 && (reg & 0xe) == 1) { bit = CSR_READ(sc, mta_reg + ((reg - 1) << 2));
That looks better to me.
If that resolves the issue and the code still works, update this ticket with a patch.
Author: Gedare Bloom
2015-07-14T20:37:34.000Z
Original author: dcb
Problem is that masking off 0xe removes the 1 bit, so anything & 0xe != 1 ever.
Author: Joel Sherrill
2015-07-14T20:50:21.000Z
Original author: dcb
So the code is still broken on the NetBSD head?
Author: Gedare Bloom
2015-07-14T20:57:57.000Z
Original author: dcb
Well, the second part of the condition is a nop. I have no idea what the intent of this was.
Author: Joel Sherrill
2015-07-14T21:23:17.000Z
Original author: dcb
This driver is for an Intel NIC. The driver (by name) is not in FreeBSD. The NIC is likely in the e1000/ driver directory in the FreeBSD source. The FreeBSD driver covers a much larger set of NICs and I can’t find the corresponding source to check.
Author: Trac Migrate
2017-01-26T07:16:00.000Z
Original author: dcb
Milestone changed from %”4.11.1” to %”4.11.2”
Author: Trac Migrate
2017-02-15T13:37:51.000Z
Original author: dcb
Milestone changed from %”4.11.2” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:02:20.628Z
changed the description
2342 - Doxygen does not include mscgen figures (opened)¶
Id |
2342 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2015-05-08T15:01:37.000Z |
Updated |
2025-09-19T01:46:09.747Z |
Milestone |
5.4 |
Labels |
doc, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
I assume mscgen is not installed since the figure that should be here is not: https://docs.rtems.org/doxygen/cpukit/html/group__ClassicEventTransient.html
Also is the Doxygen and documentation being regularly regenerated?
Author: Joel Sherrill
2017-01-13T22:32:03.000Z
Owner set to @chrisj
Status changed from new to assigned
Author: Trac Migrate
2017-01-26T07:16:00.000Z
Milestone changed from %”4.11.1” to %”4.11.2”
Author: Chris Johns
2017-03-23T01:03:28.000Z
Milestone changed from %”4.11.2” to %”4.11.3”
The 4.11.2 milestone is closing.
Author: Chris Johns
2018-02-05T05:47:57.000Z
Milestone changed from %”4.11.3” to %”Indefinite”
Author: Amar Takhar
2025-09-05T03:00:56.183Z
changed the description
2177 - libtests/heapwalk fails with RTEMS_DEBUG enabled (opened)¶
Id |
2177 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Joel Sherrill |
Created |
2014-04-16T06:26:26.000Z |
Updated |
2025-09-19T01:46:09.631Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::low, priority::normal, rtems::testing, tickettype::defect, version::4.11, version::4.12, version::5, version::HEAD |
Link |
|
Merges |
0 |
Original author: sebastian.huber
There are two options to fix this:
Fix the test so that it can cope with the heap protection.
Disable or simplify the test in case RTEMS_DEBUG is enabled.
Author: Trac Migrate
2014-04-16T06:26:26.000Z
Original author: sebastian.huber
There are two options to fix this:
Fix the test so that it can cope with the heap protection.
Disable or simplify the test in case RTEMS_DEBUG is enabled.
Author: Gedare Bloom
2014-11-24T18:58:28.000Z
Original author: sebastian.huber
Version changed from ~”HEAD” to ~”4.11”
Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11
Author: Trac Migrate
2014-12-18T12:36:05.000Z
Original author: sebastian.huber
Original author: sebastian.huber
Description changed
There are two options to fix this: 1. Fix the test so that it can cope with the heap protection. 2. Disable or simplify the test in case RTEMS_DEBUG is enabled.
Milestone changed from %”4.11” to %”5.0”
Priority changed from ~”normal” to ~”low”
Author: Chris Johns
2017-08-14T00:42:45.000Z
Original author: sebastian.huber
Milestone changed from %”5.0” to %”4.12.0”
Version changed from ~”4.11” to ~”4.12”
Is this still valid?
Author: Trac Migrate
2017-08-24T07:32:25.000Z
Original author: sebastian.huber
Milestone changed from %”4.12.0” to %”Indefinite”
Yes, this is still valid.
Author: Amar Takhar
2025-09-05T03:00:55.080Z
changed the description
4984 - MCAN init fail on arm/samV71 bsp in RTEMS 5.3 (opened)¶
Id |
4984 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2024-01-16T11:32:34.000Z |
Updated |
2025-09-19T01:45:47.585Z |
Milestone |
5.4 |
Labels |
bsp, priority::high, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: darioia
Hi expert,
I have found some problems on MCAN module configuration running on SAM V71 XPLAINED ULTRA EVALUATION KIT.
It is not possible choice other input clock reference (excluded PMC_PCK_CSS_MCK), the default configuration works only on 500kb/s and MCANx_PROP_SEGy, MCANx_PROP_SEG and MCANx_SYNC_JUMP parameters not are compatibles with several MCAN bit time calculators suggested from Microchip, (is it possible have the MCAN calculator that you have used to calculate yours parameters?):
https://www.kvaser.com/support/calculators/bit-timing-calculator/ https://intrepidcs.com/products/free-tools/mb-time-calculator/
PS: I have found the following register description error (the samV71 datasheet used is DS60001527H)
define MCAN_FBTP_FSJW_Msk (0x7u << MCAN_FBTP_FSJW_Pos)¶
define MCAN_FBTP_FTSEG2_Msk (0xfu << MCAN_FBTP_FTSEG2_Pos)¶
define MCAN_FBTP_FTSEG1_Msk (0x1fu << MCAN_FBTP_FTSEG1_Pos)¶
And our collaborators has found also:
define MCAN_BTP_SJW_Pos 25¶
define MCAN_BTP_SJW_Msk (0x7fu << MCAN_BTP_SJW_Pos)¶
define MCAN_BTP_TSEG2_Pos 0¶
define MCAN_BTP_TSEG2_Msk (0x7fu << MCAN_BTP_TSEG2_Pos)¶
define MCAN_BTP_TSEG1_Pos 8¶
define MCAN_BTP_TSEG1_Msk (0xffu << MCAN_BTP_TSEG1_Pos)¶
define MCAN_BTP_BRP_Msk (0x1ffu << MCAN_BTP_BRP_Pos)¶
I hope the description is clear enought.
Best regards, Dario
Author: Joel Sherrill
2024-01-16T14:32:47.000Z
Original author: darioia
Since you have the hardware, have identified the bug, and apparently have a fix, it would be greatly appreciated if you could post a patch. The community will be happy to help you with this if you need help doing that.
Author: Trac Migrate
2024-01-19T12:13:09.000Z
Original author: darioia
Hi,
you can close the ticket. See the attach. The patches are done by hand made.
Regards, Dario
Author: Trac Migrate
2024-01-19T12:15:41.000Z
Original author: darioia
Attachment attach_ticket.txt added
Attached file patchs 1Mb/s speed configuration, register mapping wrong and problem with data cache in multiframe.
Author: Chris Johns
2025-09-19T01:45:47.663Z
changed the description
4983 - MCAN fail on arm/samV71 bsp in RTEMS 5.3 (opened)¶
Id |
4983 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2024-01-16T11:05:23.000Z |
Updated |
2025-09-19T01:45:47.375Z |
Milestone |
5.4 |
Labels |
bsp, priority::high, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: darioia
Hi expert.
I have found a big problem regarding internal SAMV71 MCAN module (the code is unchanged regards RTEMS 6 then I think it should to be present also in that version) running on SAM V71 XPLAINED ULTRA EVALUATION KIT.
The problem is present in RX direction. I use FIFO functionality, I have configured 32 buffer in FIFOs, when I receive the 33th message, the packet is invalid (I think it is repeated one), follow you can see a couple of 15 messages that should to be identically, idx is buffer position in FIFO:
idx=4 MCAN Rx Fifo 0 data: 0x00 0x64 0x53 0x00 0x01 0x02 0x03 0x04 idx=5 MCAN Rx Fifo 0 data: 0x01 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B idx=6 MCAN Rx Fifo 0 data: 0x02 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 idx=7 MCAN Rx Fifo 0 data: 0x03 0x13 0x14 0x15 0x16 0x17 0x18 0x19 idx=8 MCAN Rx Fifo 0 data: 0x04 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F 0x20 idx=9 MCAN Rx Fifo 0 data: 0x05 0x21 0x22 0x23 0x24 0x25 0x26 0x27 idx=10 MCAN Rx Fifo 0 data: 0x06 0x28 0x29 0x2A 0x2B 0x2C 0x2D 0x2E idx=11 MCAN Rx Fifo 0 data: 0x07 0x2F 0x30 0x31 0x32 0x33 0x34 0x35 idx=12 MCAN Rx Fifo 0 data: 0x08 0x36 0x37 0x38 0x39 0x3A 0x3B 0x3C idx=13 MCAN Rx Fifo 0 data: 0x09 0x3D 0x3E 0x3F 0x40 0x41 0x42 0x43 idx=14 MCAN Rx Fifo 0 data: 0x0A 0x44 0x45 0x46 0x47 0x48 0x49 0x4A idx=15 MCAN Rx Fifo 0 data: 0x0B 0x4B 0x4C 0x4D 0x4E 0x4F 0x50 0x51 idx=16 MCAN Rx Fifo 0 data: 0x0C 0x52 0x53 0x54 0x55 0x56 0x57 0x58 idx=17 MCAN Rx Fifo 0 data: 0x0D 0x59 0x5A 0x5B 0x5C 0x5D 0x5E 0x5F idx=18 MCAN Rx Fifo 0 data: 0x0E 0x60 0x61 0x62 0x63 0xA9
idx=19 MCAN Rx Fifo 0 data: 0x00 0x64 0x53 0x00 0x01 0x02 0x03 0x04 idx=20 MCAN Rx Fifo 0 data: 0x01 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B idx=21 MCAN Rx Fifo 0 data: 0x02 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 idx=22 MCAN Rx Fifo 0 data: 0x03 0x13 0x14 0x15 0x16 0x17 0x18 0x19 idx=23 MCAN Rx Fifo 0 data: 0x04 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F 0x20 idx=24 MCAN Rx Fifo 0 data: 0x05 0x21 0x22 0x23 0x24 0x25 0x26 0x27 idx=25 MCAN Rx Fifo 0 data: 0x06 0x28 0x29 0x2A 0x2B 0x2C 0x2D 0x2E idx=26 MCAN Rx Fifo 0 data: 0x07 0x2F 0x30 0x31 0x32 0x33 0x34 0x35 idx=27 MCAN Rx Fifo 0 data: 0x08 0x36 0x37 0x38 0x39 0x3A 0x3B 0x3C idx=28 MCAN Rx Fifo 0 data: 0x09 0x3D 0x3E 0x3F 0x40 0x41 0x42 0x43 idx=29 MCAN Rx Fifo 0 data: 0x0A 0x44 0x45 0x46 0x47 0x48 0x49 0x4A idx=30 MCAN Rx Fifo 0 data: 0x0B 0x4B 0x4C 0x4D 0x4E 0x4F 0x50 0x51 idx=31 MCAN Rx Fifo 0 data: 0x0C 0x52 0x53 0x54 0x55 0x56 0x57 0x58 idx=0 MCAN Rx Fifo 0 data: 0x00 0x14 0x33 0x00 0x01 0x02 0x03 0x04 idx=1 MCAN Rx Fifo 0 data: 0x0E 0x60 0x61 0x62 0x63 0xA9
The first data byte is the internal sequence number (0x00 - 0x0E) If I reduce the fifo lenght the problem is present in (MCAN1_NMBR_RX_FIFOx_ELMTS - 1) fifo element, the problem is present in polling mode and in interrupt mode.
I have seen the Microchip reference code found in https://github.com/Microchip-MPLAB-Harmony/csp_apps_sam_e70_s70_v70_v71.git
bool MCAN1_MessageReceiveFifo(MCAN_RX_FIFO_NUM rxFifoNum, uint8_t numberOfMessage, MCAN_RX_BUFFER rxBuffer) { uint8_t rxgi = 0U; …. switch (rxFifoNum) { case MCAN_RX_FIFO_0: / Read data from the Rx FIFO0 */ rxgi = (uint8_t)((MCAN1_REGS->MCAN_RXF0S & MCAN_RXF0S_F0GI_Msk) >> MCAN_RXF0S_F0GI_Pos); for (count = 0U; count < numberOfMessage; count++) { rxFifo = (uint8_t *) ((uint8_t *)mcan1Obj.msgRAMConfig.rxFIFO0Address + ((uint32_t)rxgi * MCAN1_RX_FIFO0_ELEMENT_SIZE));
(void) memcpy(rxBuf, rxFifo, MCAN1_RX_FIFO0_ELEMENT_SIZE);
if ((count + 1U) == numberOfMessage) { break; } rxBuf += MCAN1_RX_FIFO0_ELEMENT_SIZE; rxgi++; if (rxgi == 1U) ** { ** rxgi = 0U;** }** }
/* Ack the fifo position */ MCAN1_REGS->MCAN_RXF0A = MCAN_RXF0A_F0AI((uint32_t)rxgi);
status = true; break; …. } return status; }
I suppose there are a different handling on the first buffer.
I hope the description is clear enought.
Best regards, Dario
Author: Trac Migrate
2024-01-19T11:38:37.000Z
Original author: darioia
Hi,
you can close the ticket, our collabortour have found the problem regarding caching of data, is “just” necesasry to place the call rtems_cache_disable_data in the following function:
uint32_t **MCAN_GetRxFifoBuffer**(const MCan_ConfigType *mcanConfig, MCan_FifoType fifo, Mailbox64Type *pRxMailbox) { …. fill_level = 0;
**rtems_cache_disable_data**();
Regards, Dario
Author: Chris Johns
2025-09-19T01:45:47.470Z
changed the description
4972 - potential issues? Undefined behavior issues caused by the misuse of keywords were discovered in RTEMS, which will cause the program to run incorrectly. (opened)¶
Id |
4972 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2023-11-23T14:08:39.000Z |
Updated |
2025-09-19T01:45:47.200Z |
Milestone |
5.4 |
Labels |
priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: madongyu
An undefined behavior issue caused by the misuse of const keyword was discovered in RTEMS in functon rtems_bsdnet_show_mbuf_stats() of /RTEMS/4.11.3/kernel/rtems/cpukit/libnetworking/rtems/rtems_showmbuf.c file in line 41.
An undefined behavior issue caused by the misuse of const keyword was discovered in RTEMS in functon compress2() of /RTEMS/4.11.3/kernel/rtems/cpukit/zlib/compress.c file in line 30.
Author: Trac Migrate
2023-11-23T14:16:30.000Z
Original author: madongyu
Attachment Defects Description.pdf added
Undefined behavior issues caused by the misuse of keywords were discoveredin RTEMS, which will cause the program to run incorrectly.
Author: Trac Migrate
2023-11-23T14:18:40.000Z
Original author: madongyu
Real-Time Executive for Multiprocessing Systems (RTEMS) , version 5.3
Author: Chris Johns
2025-09-19T01:45:47.267Z
changed the description
4904 - Application build with vendor target toolchain fails with rtems make build support (opened)¶
Id |
4904 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2023-05-14T10:29:06.000Z |
Updated |
2025-09-19T01:45:46.997Z |
Milestone |
5.4 |
Labels |
priority::normal, rtems::build, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: arand
When building an application using the make build support (as given by the example in make/Templates/Makefile.leaf), and when the used toolchain has a vendor identifier as part of the target triplet (for example sparc-gaisler-rtems5), the build fails with the following kind of error:
<user_path>/make/custom/default.cfg:14: <user_path>/sparc-rtems5/leon3/make/bsp.cfg: No such file or directory
make: *** No rule to make target '<user_path>/sparc-rtems5/leon3/make/bsp.cfg'. Stop.
This seems to be due to make/custom/default.cfg which uses:
!#make
(...)
RTEMS_TARGET = $(RTEMS_CPU)-rtems$(RTEMS_API)
include $(RTEMS_ROOT)/$(RTEMS_TARGET)/$(RTEMS_BSP)/make/target.cfg
include $(RTEMS_SHARE)/make/host.cfg
include $(RTEMS_ROOT)/make/main.cfg
include $(RTEMS_ROOT)/$(RTEMS_TARGET)/$(RTEMS_BSP)/make/bsp.cfg
where RTEMS_CPU does not include the vendor id, and hence gives an incorrect target triplet in RTEMS_TARGET.
This seems to be a regression between rtems 4.11 and rtems 5 introduced in
Author: Chris Johns
2023-05-15T03:29:43.000Z
Original author: arand
Does your build system provide
RTEMS_TARGET?How do you specify the
sparc-gaisierlabel?
Author: Trac Migrate
2023-05-15T07:59:13.000Z
Original author: arand
My build system does not touch RTEMS_TARGET, I’m using a Makefile based on the Makefile.leaf template:
!#make # C source names, if any, go here -- minus the .c C_PIECES=foo C_FILES=$(C_PIECES:%=%.c) C_O_FILES=$(C_PIECES:%=${ARCH}/%.o) SRCS=$(C_FILES) $(CC_FILES) $(H_FILES) $(S_FILES) OBJS=$(C_O_FILES) $(CC_O_FILES) $(S_O_FILES) PGMS=${ARCH}/foo.exe include $(RTEMS_MAKEFILE_PATH)/Makefile.inc include $(RTEMS_CUSTOM) include $(RTEMS_ROOT)/make/leaf.cfg all: ${ARCH} $(SRCS) $(PGMS) # The following links using C rules. ${ARCH}/foo.exe: ${OBJS} ${LINK_FILES} $(make-exe)and pointing RTEMS_MAKEFILE_PATH to a compiled and installed version of an RTEMS BSP.
The sparc-gaisler-rtems5 triplet is given by the toolchain, in my case this is taken directly from rcc-1.3.1-gcc from https://www.gaisler.com/index.php/products/operating-systems/rtems .
However I would guess that this problem would apply to any toolchain with a vendor in its name (even “unknown”).
Author: Chris Johns
2025-09-19T01:45:47.076Z
changed the description
4898 - Checksum of libbsd5.3 is not correct (opened)¶
Id |
4898 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2023-04-17T10:54:23.000Z |
Updated |
2025-09-19T01:45:46.820Z |
Milestone |
5.4 |
Labels |
priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: marcrew
There is checksum error reported when source builder is building the libbsd 5.3.
Author: Trac Migrate
2023-04-17T10:58:36.000Z
Original author: marcrew
Owner set to Chris
Status changed from new to assigned
Author: Chris Johns
2025-09-19T01:45:46.876Z
changed the description
4764 - msdos_format throws RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE on free(fmt_params.sec) (opened)¶
Id |
4764 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2022-11-25T16:17:10.000Z |
Updated |
2025-09-19T01:45:46.731Z |
Milestone |
5.4 |
Labels |
filesystem::fat, old-indefinite, priority::high, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: Fantomas96
Hello, I’m trying to mount the FAT filesystem on the external memory of an atsamv xpalined ultra. I managed to mount the device but when calling the msdos_format function to format the memory I get a RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE fault. The fault is thrown when the function calls the free on the fmt_params.sec pointer.
Author: Trac Migrate
2022-11-25T16:18:17.000Z
Original author: Fantomas96
Attachment Immagine.png added
Error screenshot
Author: Joel Sherrill
2022-11-25T16:20:39.000Z
Original author: Fantomas96
Without looking at the code, this should indicate that the address passed to free() is not one that was malloced. Perhaps it should have been set to NULL in the structure earlier and just garbage is passed in when clean up occurs. Otherwise, there is what I would think is a bug which would have been tripped over in the most basic testing and use.
Author: Trac Migrate
2022-11-28T10:02:58.000Z
Original author: Fantomas96
Ok I found something interesting. First of all if I compile the rtems code with the flag –enable-rtems-debug the malloc of fmt_params.sec doesn’t work so the pointer it’s NULL and the function tries to free a NULL pointer. I don’t know if the malloc not allocating is an expected behaviour in this condition. But if I remove the flag and recompile the kernel the malloc is working and everything seems to work smootly until I get to the free. The pointer now it’s allocated and it contains the stuff that is being written in the external flash. Here’s what the pointer contains when the free it’s called. !`https://ibb.co/djrp9ym <https://ibb.co/djrp9ym>`_. Now the free stil doesn’t work and returns the same error as before. This obviusly causes my RTEMS app to stop working. If I reboot the app the msdos_format it’s called again but in this case the external memory is not erased since the function called in the previous execution was formatting the external memory with the FAT filesystem. So now I got a crc error. I suppose this is because the previous execution was stopped and the QSPI driver hadn’t finished writing to external memory. He’s a screen shot of the full error. !`https://ibb.co/RhXFR8j <https://ibb.co/RhXFR8j>`_ The interesting thing is that now the free works and my application keeps working as we can see from the screenshot. Obviusly the filesystem is not mounted so it’s still working in the IMFS filesystem.
Author: Chris Johns
2022-12-06T22:42:08.000Z
Original author: Fantomas96
Milestone changed from %”5.1” to %”Indefinite”
Author: Amar Takhar
2025-09-05T02:57:54.160Z
changed the description
4720 - Backport rtems-tools fixes (opened)¶
Id |
4720 |
State |
opened |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Trac Migrate |
Created |
2022-09-22T07:17:59.000Z |
Updated |
2025-09-19T01:45:46.548Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool::test, version::5 |
Link |
|
Merges |
0 |
The devel branch hashes are:
If you think more should be back ported please add.
Author: Chris Johns
2022-11-09T22:48:51.000Z
Milestone changed from %”5.2” to %”Indefinite”
Author: Amar Takhar
2025-09-05T02:57:53.575Z
changed the description
4685 - Incorrect 3C509 driver function signature in PC BSP (opened)¶
Id |
4685 |
State |
opened |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Created |
2022-07-26T07:09:55.000Z |
Updated |
2025-09-19T01:45:46.443Z |
Milestone |
5.4 |
Labels |
bsp, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
The function signature for the PC BSP 3C509 driver is wrong.
Author: Chris Johns
2022-07-26T07:13:32.000Z
There is no detach code. Might be a good idea to add some.
Author: Chris Johns
2022-11-09T23:28:07.000Z
Milestone changed from %”5.2” to %”Indefinite”
Author: Amar Takhar
2025-09-05T02:57:53.378Z
changed the description
4542 - filename length problem in JFFS2 with RTEMS4.11.3/RTEMS5.1 (opened)¶
Id |
4542 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2021-11-03T01:23:44.000Z |
Updated |
2025-09-19T01:45:46.224Z |
Milestone |
5.4 |
Labels |
filesystem::jaffs2, filesystem::jffs2, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: chenjin_zhong
Hi, the MACRO JFFS2_MAX_NAME_LEN defines the maximum length of filename is 254. The length of filename is unchecked in jffs2_create. But the length of filename is checked in rtems_jffs2_rmnod and rtems_jffs2_rename. This causes the creation of a file with a length of more than JFFS2_MAX_NAME_LEN will succeed, but rename or unlink failed. The src code is listed as follows. The bold function detects the length of filename. static int rtems_jffs2_rmnod( const rtems_filesystem_location_info_t parentloc, const rtems_filesystem_location_info_t *loc ) { struct _inode *dir_i = rtems_jffs2_get_inode_by_location(parentloc); struct _inode *entry_i = rtems_jffs2_get_inode_by_location(loc); char *name; size_t namelen; int eno = **rtems_jffs2_cache_fd_name(entry_i, &name, &namelen)*;
if (eno == 0) { switch (dir_i->i_mode & S_IFMT) { case S_IFDIR: eno = -jffs2_rmdir(dir_i, entry_i, name, namelen); break; case S_IFREG: eno = -jffs2_unlink(dir_i, entry_i, name, namelen); break; default: eno = EINVAL; break; } }
return rtems_jffs2_eno_to_rv_and_errno(eno); }
static int rtems_jffs2_rmnod( const rtems_filesystem_location_info_t parentloc, const rtems_filesystem_location_info_t *loc ) { struct _inode *dir_i = rtems_jffs2_get_inode_by_location(parentloc); struct _inode *entry_i = rtems_jffs2_get_inode_by_location(loc); char *name; size_t namelen; int eno = **rtems_jffs2_cache_fd_name(entry_i, &name, &namelen)*;
if (eno == 0) { switch (dir_i->i_mode & S_IFMT) { case S_IFDIR: eno = -jffs2_rmdir(dir_i, entry_i, name, namelen); break; case S_IFREG: eno = -jffs2_unlink(dir_i, entry_i, name, namelen); break; default: eno = EINVAL; break; } }
Author: Trac Migrate
2021-11-12T13:51:59.000Z
Original author: chenjin_zhong
This looks like a valid bug. The next step would be to add a test case to the test suite which reproduces the bug.
Author: Trac Migrate
2021-11-12T13:53:15.000Z
Original author: chenjin_zhong
Owner set to Needs Funding
Status changed from new to assigned
Author: Chris Johns
2022-11-10T02:03:01.000Z
Original author: chenjin_zhong
Milestone changed from %”5.1” to %”5.3”
Author: Chris Johns
2023-01-31T05:37:48.000Z
Original author: chenjin_zhong
Milestone changed from %”5.3” to %”Indefinite”
The ticket needs funding to be resolved.
Author: Amar Takhar
2025-09-05T02:57:51.021Z
changed the description
4464 - gpiolib: Add support for newer grgpio features (opened)¶
Id |
4464 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2021-07-01T15:42:12.000Z |
Updated |
2025-09-19T01:45:46.107Z |
Milestone |
5.4 |
Labels |
arch:sparc, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: soja
Current version of gpiolib is not aware of the input enable register of the grgpio core, when presence is indicated through capability register.
Also currently only interrupt support for “irqgen == 0” is supported. Our interface card has the mode “irqgen == 1” according to the capabilities register.
Author: Trac Migrate
2021-07-01T15:42:33.000Z
Original author: soja
Owner set to soja
Status changed from new to accepted
Author: Chris Johns
2022-11-09T23:49:37.000Z
Original author: soja
Milestone changed from %”5.2” to %”5.3”
Author: Chris Johns
2023-02-08T03:19:58.000Z
Original author: soja
Milestone changed from %”5.3” to %”Indefinite”
This requires Daniel and someone to work with him to resolve. There is no point moving each release to the next milestone.
Author: Amar Takhar
2025-09-05T02:57:50.827Z
changed the description
4344 - powerpc/beatnik: split network driver into multiple files (preparation for libbsd support) (opened)¶
Id |
4344 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2021-03-16T09:30:23.000Z |
Updated |
2025-09-19T01:45:45.738Z |
Milestone |
5.4 |
Labels |
bsp, old-indefinite, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: till.straumann@psi.ch
This pull request (on top of the 5 branch) breaks the mv643xx driver into two parts * low-level driver; independent from BSD * legacy BSD networking support layer The first is independent from RTEMS’ networking support and always part of the BSP (can e.g., be used to implement low-level ethernet access). The second builds on top of the first and is only enabled when RTEMS is configured with legacy BSDnet support.
Note: the driver design has not changed; there have always been two layers; this patch just splits the code into separate files. It is a necessary preparation for a new rtems-libbsd/nexus driver (which is submitted in a separate ticket)
Author: Trac Migrate
2021-03-16T09:38:46.000Z
Original author: till.straumann@psi.ch
Here the related rtems-libbsd ticket.
Author: Chris Johns
2022-11-10T00:10:02.000Z
Original author: till.straumann@psi.ch
Milestone changed from %”5.1” to %”5.3”
Author: Chris Johns
2023-01-30T01:00:51.000Z
Original author: till.straumann@psi.ch
Milestone changed from %”5.3” to %”Indefinite”
Please select a milestone when the work can be completed for that milestone.
Author: Amar Takhar
2025-09-05T02:57:49.420Z
changed the description
4322 - Add a workaround for the LEON3FT RETT Restart errata: TN-0018 (opened)¶
Id |
4322 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2021-03-09T13:52:28.000Z |
Updated |
2025-09-19T01:45:45.642Z |
Milestone |
5.4 |
Labels |
bsp, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: daniel
See also:
https://www.gaisler.com/doc/antn/GRLIB-TN-0018.pdf
The GCC patch has been accepted upstreams into master and GCC-10 branch:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4b690f161b82e428dbe648075da215daa52be0ea https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1aed3f059ebd08fffe1346ac7ecf8e8606359875
Author: Trac Migrate
2021-03-09T13:53:52.000Z
Original author: daniel
Attachment gcc-7.5-sparc-rtems-add-__FIX_LEON3FT_TN0018-for-affected-ta.patch added
GCC-7.5 backport from GCC-10 patch linked in ticket.
Author: Trac Migrate
2021-03-09T14:18:14.000Z
Original author: daniel
Proposed RTEMS kernel fix: https://lists.rtems.org/pipermail/devel/2020-October/062826.html
Author: Trac Migrate
2021-11-23T09:57:48.000Z
Original author: daniel
For the RTEMS pre-qualification only #4155 is relevant.
Author: Chris Johns
2022-11-09T23:23:31.000Z
Original author: daniel
Milestone changed from %”5.2” to %”5.3”
Author: Chris Johns
2023-02-08T03:20:41.000Z
Original author: daniel
Milestone changed from %”5.3” to %”Indefinite”
This requires Daniel and someone to work with him to resolve. There is no point moving each release to the next milestone.
Author: Amar Takhar
2025-09-05T02:57:48.638Z
changed the description
4318 - grlib,gr1553bc: set BC transfer descriptor timeout correctly (opened)¶
Id |
4318 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2021-03-07T15:00:47.000Z |
Updated |
2025-09-19T01:45:45.534Z |
Milestone |
5.4 |
Labels |
bsp, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: daniel
GR1553 BC driver gr1553bc_slot_transfer() bit shift logic does not match hardware, if a too large timeout value has given the wrong bus could have been selected. The timeout value was taken from a specific RT’s setting, however from the wrong RT. This may not be seen if all RT’s use the same timoute settings.
Author: Trac Migrate
2021-03-09T13:31:18.000Z
Original author: daniel
Milestone changed from %”6.1” to %”5.2”
Author: Chris Johns
2022-11-09T23:22:59.000Z
Original author: daniel
Milestone changed from %”5.2” to %”5.3”
Author: Chris Johns
2023-02-08T03:19:26.000Z
Original author: daniel
Milestone changed from %”5.3” to %”Indefinite”
This requires Daniel and someone to work with him to resolve. There is no point moving each release to the next milestone.
Author: Amar Takhar
2025-09-05T02:57:48.441Z
changed the description
4317 - grlib,gr1553bc: list creation did not set table_size field (opened)¶
Id |
4317 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2021-03-07T14:55:42.000Z |
Updated |
2025-09-19T01:45:45.410Z |
Milestone |
5.4 |
Labels |
bsp, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: daniel
By not setting the table_size field, either required the user to do that or that the memory returned by malloc() had a reasonable non-zero value, otherwise the interrupt handler could miss some of the buffer decriptor processing expected by the API. By setting the table_size according to the driver calculated list size the user will not have to do that themselves and simplifies the usage of the API and potential bugs.
Author: Trac Migrate
2021-03-09T13:30:56.000Z
Original author: daniel
Milestone changed from %”6.1” to %”5.2”
Author: Chris Johns
2022-11-09T23:22:21.000Z
Original author: daniel
Milestone changed from %”5.2” to %”5.3”
Author: Chris Johns
2023-02-08T03:16:54.000Z
Original author: daniel
Milestone changed from %”5.3” to %”Indefinite”
This requires Daniel and someone to work with him to resolve. There is no point moving each release to the next milestone.
Author: Amar Takhar
2025-09-05T02:57:48.226Z
changed the description
4179 - libbsd select timeout issue (opened)¶
Id |
4179 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Kinsey Moore |
Created |
2020-11-17T01:45:41.000Z |
Updated |
2025-09-19T01:45:45.285Z |
Milestone |
5.4 |
Labels |
libbsd, priority::normal, resolution::fixed, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: ruizx
Kernel put the select thread to sleep queue in sleepq_set_timeout_sbt, the expire value is calculated by this expire = (sbt - SBT_1S + sbt_per_tick - 1) / sbt_per_tick; sbt is the absolute time,no time drift. but the sbt_per_tick is not an accurate value, it can make the expire vaule bigger and bigger while sbt is increasing.
In rtems_bsd_initialize function, rtems_bsd_sbt_per_watchdog_tick = SBT_1S / tps;
In our system the tick rate is set to 1000Hz, the real value of rtems_bsd_sbt_per_watchdog_tick is 1<<32/1000=4294967.296 but in integer type the value is 4294967. The error is 0.296/4294967 = 0.069ppm, and it can increase the expire value 1ms every 14000 seconds.
Author: Trac Migrate
2020-11-17T01:48:10.000Z
Original author: ruizx
Attachment select.patch added
using relative time for reference
Author: Trac Migrate
2021-03-04T08:08:27.000Z
Original author: ruizx
Owner set to Sebastian Huber <sebastian.huber@embedded-brains.de>
Resolution set to ~”fixed”
Status changed from new to closed
In [changeset:”8fe59be236e7f2047adb6e393639bbf56bbd996d/rtems” 8fe59be/rtems]:
validation: Fix for 64-bit targets Closes #4179.
Author: Trac Migrate
2021-03-04T08:10:54.000Z
Original author: ruizx
Resolution ~”fixed” deleted
Status changed from closed to reopened
Sorry, wrong number in commit.
Author: Fabrizio Pirovano
2025-02-03T10:39:00.836Z
This patch, after four years, is still open and it is not been applied to rtems-6-freebsd-12 and to main branch.
Does the patch need to be applied?
Author: Amar Takhar
2025-02-03T12:39:31.001Z
Assigning this to @opticron he was looking at issues that have patches. Maybe @chris has some insight
Author: Amar Takhar
2025-02-03T12:39:36.956Z
changed the description
Author: Amar Takhar
2025-02-03T12:39:36.996Z
assigned to @opticron and unassigned @tracmigrate
4146 - rtems-tools/doc/rtems-tester.txt Needs Updating or Removed (opened)¶
Id |
4146 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2020-10-14T17:00:58.000Z |
Updated |
2025-09-19T01:45:45.160Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
This file mentions both sis and the autoconf based build system in its instructions. Hopefully, this file has no information which is not in the Sphinx based documentation and can simply be removed.
Filed against 5 and wafblocker since file is on 5 branch as well as master and contains information that is misleading and incorrect for the waf build process.
Author: Chris Johns
2022-11-09T22:34:00.000Z
Milestone changed from %”5.2” to %”Indefinite”
Please assign a milestone when a fix is scheduled or please close this ticket.
Author: Amar Takhar
2025-09-05T02:57:45.606Z
changed the description
4144 - fileio - Stack too small for login with password (cloned) (opened)¶
Id |
4144 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2020-10-12T13:21:05.000Z |
Updated |
2025-09-19T01:45:45.033Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool::test, version::5 |
Link |
|
Merges |
0 |
Original author: frank_k
Cloned from #4143:
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 (to 5 times RTEMS_MINIMUM_STACK_SIZE) solves the issue.
How to reproduce:
Start the fileio sample in QEMU with the above command.
Type a key to stop the timer.
Type “s” <return> to enter the shell.
Login as “root” with the password printed to the terminal.
In the line with the first shell prompt, the text “BLOWN STACK!!!” appears unexpectedly followed by further crash information.
[...]
/dev/foobar login: root
Password:
RTEMS Shell on /dev/foobar. Use 'help' to list commands.
SHLL [/] # BLOWN STACK!!!
task control block: 0x00205278
[...]
Author: Joel Sherrill
2020-10-12T13:27:26.000Z
Original author: frank_k
At the risk of repeating myself, why do we ever use -O0 anymore now that GCC has -Og. From https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
-Og Optimize debugging experience. -Og should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience. It is a better choice than -O0 for producing debuggable code because some compiler passes that collect debug information are disabled at -O0. Like -O0, -Og completely disables a number of optimization passes so that individual options controlling them have no effect. Otherwise -Og enables all -O1 optimization flags except for those that may interfere with debugging: -fbranch-count-reg -fdelayed-branch -fdse -fif-conversion -fif-conversion2 -finline-functions-called-once -fmove-loop-invariants -fssa-phiopt -ftree-bit-ccp -ftree-dse -ftree-pta -ftree-sraI don’t have problem with increasing the configured minimum stack size value for this sample. It would be better than tinkering with individual create invocations. But if -O0 is the culprit, let’s just switch away from it.
Author: Chris Johns
2022-11-09T22:32:58.000Z
Original author: frank_k
Milestone changed from %”5.2” to %”Indefinite”
Author: Amar Takhar
2025-09-05T02:57:45.352Z
changed the description
4136 - examples/README.waf: Out of Date URL for How to Setup a Waf based RTEMS Application (opened)¶
Id |
4136 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2020-10-08T16:27:55.000Z |
Updated |
2025-09-19T01:45:44.919Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
The README.waf has http://www.rtems.org/ftp/pub/rtems/people/chrisj/rtl/rtems-linker/waf.html
where should this point now?
Author: Chris Johns
2022-11-09T23:19:53.000Z
Milestone changed from %”5.2” to %”Indefinite”
Status changed from assigned to new
Author: Amar Takhar
2025-09-05T02:57:45.141Z
changed the description
4053 - [libbsd] e1000 driver not working for i386 based BSP in current rtems-libbsd 5 branch (opened)¶
Id |
4053 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2020-08-14T19:51:20.000Z |
Updated |
2025-09-19T01:45:44.819Z |
Milestone |
5.4 |
Labels |
libbsd, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: soja
Cloned from #4052:
Current rtems-libbsd “5” branch fails to compile the e1000 driver for i386 based BSPs.
The corresponding patches from the 5-freebsd-12 branch need to be ported to master.
Author: Chris Johns
2020-08-14T21:15:04.000Z
Original author: soja
The RTEMS 5 release is based on the
5-freebsd-12branch for LibBSD and not the5branch. Maybe the issue is the5branch for LibBSD should have been made from5-freebsd-12and notmaster.I have adjusted the release scripts to package the
5-freebsd-12branch for LibBSD as a special case however it has concerned me something is not right and this ticket is now making me wonder if the5branch referencingmasterhas confused things.
Author: Trac Migrate
2020-08-14T21:38:48.000Z
Original author: soja
I got that the 5-freebsd-12 branch will be the libbsd version for RTEMS 5.1. That’s why I put the patches there first to make it in time.
My impression was that the 5 branch was created from master with the goal that in a future 5.x release libbsd might be created from this one, once the next FreeBSD version has been officially released.
I wanted to make sure that if that happens, it has the same features as the 5-freebsd-12 branch. The discussion on the mailinglist was a bit confusing, so maybe I got it wrong.
Author: Chris Johns
2020-08-15T00:55:56.000Z
Original author: soja
I also have the same impression. We need a release and then we need to look after the branch for a while to understand how this will work. Having the patches on all branches makes it easier and simpler.
Author: Chris Johns
2020-08-25T04:01:05.000Z
Original author: soja
Milestone changed from %”5.1” to %”5.2”
This can be resolved for 5.2
Author: Chris Johns
2022-11-09T22:19:19.000Z
Original author: soja
Milestone changed from %”5.2” to %”Indefinite”
Jan please close as
won't fixif this ticket is not important. Thanks.
Author: Amar Takhar
2025-09-05T02:57:43.840Z
changed the description
4012 - Porting EEMBC Coremaster Pro benchmark to rtems (opened)¶
Id |
4012 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2020-06-22T08:47:06.000Z |
Updated |
2025-09-19T01:45:44.702Z |
Milestone |
5.4 |
Labels |
priority::normal, tickettype::task, version::5 |
Link |
|
Merges |
0 |
Original author: ashrithams
EEMBC provides coremark-pro for benchmarking SMP multi-core. I have a LEON3- Dual core processor on an FPGA. I want to benchmark it using rtems provided in gaisler website. The benchmark suite I have selected to try is Coremark-pro. AFter many trials in building for rtems, I am getting the following errors as attached in the files. I have also mentioned the Make command and options I am using. In coremaster pro folder, inside util, inside make I have created a sparc-gaisler-rtems.mak file.
Author: Trac Migrate
2020-06-22T08:49:19.000Z
Original author: ashrithams
Attachment rtems_querry_coremaster_pro.txt added
Author: Trac Migrate
2020-06-22T08:50:01.000Z
Original author: ashrithams
Attachment sparc-gaisler-rtems5.mak added
This is the makefile included in the coremaster-pro->util->make folder
Author: Trac Migrate
2020-06-22T08:53:03.000Z
Original author: ashrithams
rtems_querry_coremaster_pro.txt contains the output of make command ans its error.
Author: Gedare Bloom
2025-02-01T00:53:05.977Z
changed the description
Author: Gedare Bloom
2025-02-01T00:53:06.164Z
4009 - pc386: smpatomic01.exe fails (opened)¶
Id |
4009 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2020-06-18T07:31:21.000Z |
Updated |
2025-09-19T01:45:44.528Z |
Milestone |
5.4 |
Labels |
bsp, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: soja
It fails with this information:
] === atomic or/and test case ===
] worker 0 value: 1
] worker 1 value: 0
] atomic value: expected = 1, actual = 1
] ../../../../../../smp-refex-rtems/c/src/../../testsuites/smptests/smpatomic01/init.c: 404 n - s < LONG_MAX
]
] ** FATAL ***
According to Sebastian Huber (https://lists.rtems.org/pipermail/devel/2020-June/060102.html):
This looks like a bug in smpatomic01. We need a better test case for atomic_thread_fence().
So maybe this needs to be linked to a more general smpatomic ticket?
Author: Trac Migrate
2020-06-18T07:31:40.000Z
Original author: soja
Summary changed from pc386: smpatomic01.exe to pc386: smpatomic01.exe fails
Author: Chris Johns
2025-09-19T01:45:44.595Z
changed the description
4008 - pc386: smpclock01.exe fails (opened)¶
Id |
4008 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2020-06-18T07:19:38.000Z |
Updated |
2025-09-19T01:45:44.332Z |
Milestone |
5.4 |
Labels |
bsp, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: soja
In the current SMP implementation for i386 the smpclock01 test will run in a deadlock. This is because atm only the CPU0 will initialize a timer and handle timer interrupts. The timer events are then distributed to the other processors using IPIs.
The test now does the following: * CPU0 disables its local interrupts and then waits on barrier A for the timer_task * timer_task unblocks barrier A (timer_task runs on CPU1) * timer_task arms timer 1 clock tick in the future and goes to sleep for one tick * CPU0 waits on barrier B which is supposed to be unblocked by the timer event of CPU1 * CPU0 has local interrupts disabled which means no hw timer interrupts are handled and no tick events are forwarded to CPU1. CPU1 never fires the timer since it never ticks.
Any suggestions for solving this are welcome.
Author: Trac Migrate
2020-06-25T18:24:20.000Z
Original author: soja
The purpose of the test is to detect broken clock drivers. In a real SMP system, the clock interrupt should be serviced on each CPU.
Author: Chris Johns
2025-09-19T01:45:44.416Z
changed the description
4001 - Test program dl06 fails on arm (opened)¶
Id |
4001 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2020-06-05T04:30:09.000Z |
Updated |
2025-09-19T01:45:44.135Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
Author: Amar Takhar
2025-09-05T02:57:43.215Z
changed the description
3975 - RTEMS 5 : sem_wait + sem_destroy behavior change (opened)¶
Id |
3975 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2020-05-07T11:19:44.000Z |
Updated |
2025-09-19T01:45:43.946Z |
Milestone |
5.4 |
Labels |
api::posix, old-indefinite, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: andrei.lupas
Hello,
With previous versions of RTEMS: a blocking sem_wait() could be broken immediately via a successful sem_destroy done from another thread (sem_wait deblocks with return code -1, and errno == EINVAL).
With latest RTEMS: sem_destroy doesn’t succeed anymore, but returns EBUSY (since another thread executes a wait on it)
This behavior change breaks some of existing code.
Would it be possible to add an RTEMS config to allow user to select between OLD and NEW behavior ? (alternative is to move from POSIX sems to classic API and use rtems_semaphore_flush).
Thanks, Andrei Lupas.
Author: Joel Sherrill
2020-05-07T13:02:57.000Z
Original author: andrei.lupas
The current behavior is what is specified in the POSIX standard:
https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/sem_destroy.html
[EBUSY] There are currently processes blocked on the semaphore.It is a shame that the signature does not have an attribute structure, that would make it easy to at least add the behavior option at the API level. This signature does not give any room for change:
int sem_init(sem_t *sem, int pshared, unsigned value);Adding a flush operation to the POSIX semaphores could be an option but sem_wait() is not defined to return any errno values which make sense for a flush. But if sem_flush_np() were added, then using another errno to indicate it was flushed by a non-portable (e.g. _np) method is at least an option.
Another option is to add a sem_XXX_np method to set the “allow delete when blocked threads” internal attribute. In this case, the threads unblocked by deleting the semaphore could return EINVAL like other POSIX methods do when the object id is invalid.
I’m just offering options within the space of the POSIX standard. The second seems like a cleaner direct solution to your problem. This is a counting semaphore and there is no concept of a “holder” as with a mutex. Besides threads waiting on a resource, do not hold the resource.
Hoping others will chime in.
Author: Trac Migrate
2020-05-07T18:25:05.000Z
Original author: andrei.lupas
Indeed, behavior is according to POSIX spec, but in the “undefined” area “The effect of destroying a semaphore upon which other threads are currently blocked is undefined.” In this case, the “undefined” behavior changed from SUCCESS to error:EBUSY, and this impacts some existing apps. On short term, I suppose I need to move to classic API semaphores. Thanks a lot for the prompt feedback. Andrei.
Author: Joel Sherrill
2020-05-07T18:29:42.000Z
Original author: andrei.lupas
Replying to andrei.lupas:
Indeed, behavior is according to POSIX spec, but in the “undefined” area “The effect of destroying a semaphore upon which other threads are currently blocked is undefined.” In this case, the “undefined” behavior changed from SUCCESS to error:EBUSY, and this impacts some existing apps.
Can you cite where you found that undefined behavior citation? I looked at the Change History section for the methods I thought this would be in and don’t see it.
Knowing when the behavior changed and being able to cite something would lend strength to providing a way to get the alternative behavior. I lean to it changing on a per semaphore instance basis rather than a single flag changing it for all.
On short term, I suppose I need to move to classic API semaphores. Thanks a lot for the prompt feedback.
No problem.
Andrei.
Author: Trac Migrate
2020-05-08T04:51:39.000Z
Original author: andrei.lupas
The “The effect of destroying a semaphore upon which other threads are currently blocked is undefined.” is the current sem_destroy() description. The POSIX semaphores are now self-contained. This means the storage space is provided and maintained by the user. Destruction of a semaphore in use could indicate that someone is trying to use an object while it is destroyed (e.g. deallocated).
What we could do (since “The effect of destroying a semaphore upon which other threads are currently blocked is undefined.”) is to flush the semaphore so that callers get woken up with EINVAL, we destroy the object and return EBUSY.
Author: Trac Migrate
2020-05-08T06:09:57.000Z
Original author: andrei.lupas
Replying to Sebastian Huber: …
What we could do (since “The effect of destroying a semaphore upon which other threads are currently blocked is undefined.”) is to flush the semaphore so that callers get woken up with EINVAL, we destroy the object and return EBUSY.
Sounds good to me. Thanks.
Author: Trac Migrate
2020-05-08T06:11:51.000Z
Original author: andrei.lupas
If you would like to get this changed, then please send a patch to devel@rtems.org which includes changes in the test suite.
Author: Chris Johns
2020-05-18T06:57:01.000Z
Original author: andrei.lupas
Can someone please update the milestone for this ticket?
Author: Trac Migrate
2020-05-18T07:06:18.000Z
Original author: andrei.lupas
Milestone set to %”5.2”
Author: Chris Johns
2022-11-09T22:16:26.000Z
Original author: andrei.lupas
Milestone changed from %”5.2” to %”Indefinite”
Author: Amar Takhar
2025-09-05T02:57:42.358Z
changed the description
3858 - PC386 BSP serial console outputs garbage on real hardware (opened)¶
Id |
3858 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2020-01-29T21:56:31.000Z |
Updated |
2025-09-19T01:45:43.377Z |
Milestone |
5.4 |
Labels |
bsp, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: Lou.Woods
Problem description¶
When the RTEMS ticker test, possibly others, is started with the -–console=/dev/com1 command line argument the output to COM1 using the pc386 BSP on real hardware the console output is invalid/garbage characters instead of the expected ticker output. The serial output looks like a baud rate mismatch.
Ticker works as expected when left to output to the VGA console.
Test configuration¶
Hardware tested¶
Winsystems EBC-855 (Intel® Celeron-M ZC Dothan 1GHz) Dell Optiplex 755 (Intel Core 2 Duo)
Hardware configuration¶
*The PC386 target COM1 is connected to a Raspberry Pi 3 with a Keyspan RS232 serial to USB converter. (This hardware combination works with other boards) *The PC386 is connected via a network to the Raspberry Pi 3 running a TFTP server that provides the boot images.
Software configuration¶
RTEMS Master e22554535796fc29a7ed7c5e2338128e324a621d
RTEMS configuration
../rtems/configure --target=i386-rtems5 --enable-rtemsbsp=pc386 IDE_USE_PRIMARY_INTERFACE=0 --prefix=/home/woods/pc386/bsp-install/ --disable-networking --enable-posix --disable-smp --disable-multiprocessing --enable-tests --enable-cxx --enable-maintainer-mode
The BSP defaults COM1 to 9600bps 8-N-1 with no flow control.
The Raspberry Pi serial host is running Debian (Raspian) Stretch
The executable is booted from the Raspberry Pi TFTP host by chain loading RTEMS via IPXE
General Notes¶
The test setup’s serial connection was verified to work using the Optiplex 755 running Windows and the same hardware components with a simple Foxterm serial session.
Things attempted one at a time¶
sweeping the baud rate on the serial host while holding the board at 9600 8N1
trying different baud rates in lock-step, target and serial host.
various combination of hardware flow control, parity, word size, stop bits.
Winsystems board talking to a Windows PC running Foxterm.
Running RTEMS 4.11 branch with current i386 toolschain – exe hangs; currently haven’t tracked down the error.
COM2 port on the Winsystems board.
Changing the clock rate for the baud-rate divisor in RTEMS
3 wire serial communications with RX, TX, and GND
Author: Chris Johns
2020-01-30T00:06:34.000Z
Original author: Lou.Woods
The PC uses the shared driver. Was there a patch for this code on the devel list for the Pi. Could this be related?
Author: Trac Migrate
2020-01-30T16:59:07.000Z
Original author: Lou.Woods
Unless I’m missing it, I don’t believe it is directly related. The commit log for the raspberry pi console update didn’t modify the shared code.
Author: Joel Sherrill
2020-01-30T17:25:58.000Z
Original author: Lou.Woods
Any chance this change broke it and no one noticed?
commit 143c8d0d948b31f7c4b40e3d7eb7ebe0b80b4915 Author: Sebastian Huber <sebastian.huber@embedded-brains.de> Date: Wed Oct 17 09:43:55 2018 +0200
serial/ns16550: Fix precision clock synthesizer
The precision clock synthesizer support broke the driver on the QorIQ P1020. On this device the Alternate Function Register is accessed with DLAB == 1 instead of the FIFO Control Register (FCR). Restructure the code to account for this.
Author: Chris Johns
2025-09-19T01:45:43.469Z
changed the description
3825 - RSB prefix argument incorrectly processes tilde (opened)¶
Id |
3825 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2019-11-22T16:26:03.000Z |
Updated |
2025-09-19T01:45:43.286Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool::rtems-source-builder, version::5 |
Link |
|
Merges |
0 |
If a ~ is used in –prefix to the source builder, then it doesn’t get transformed into ${HOME}, you will end up with the tools installed into a ~ directory under rtems-source-builder/rtems if you are building the tools.
Author: Chris Johns
2019-11-22T22:40:33.000Z
Status changed from assigned to new
Author: Chris Johns
2019-12-12T17:58:32.000Z
Milestone changed from %”5.1” to %”Indefinite”
Author: Amar Takhar
2024-04-25T20:47:29.881Z
changed the description
3819 - Consider FAA AC 20-148 - Reusable Software Components in RTEMS Software Engineering manual (opened)¶
Id |
3819 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Created |
2019-11-08T07:05:34.000Z |
Updated |
2025-09-19T01:45:43.094Z |
Milestone |
5.4 |
Labels |
priority::normal, tickettype::task, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
Review of the Software Requirements Engineering chapter for the RTEMS Software Engineering manual suggested that we should take the FAA AC 20-148 - Reusable Software Components into account:
https://lists.rtems.org/pipermail/devel/2019-November/056027.html
+Resources and Performance
+-------------------------
+
+Normally, resource and performance requirements are formulated like this:
+
+* The resource U shall need less than V storage units.
+
+* The operation Y shall complete within X time units.
+
+Such statements are difficult to make for a software product like RTEMS which
+runs on many different target platforms in various configurations. So, the
+performance requirements of RTEMS shall be stated in terms of benchmarks. The
+benchmarks are run on the project-specific target platform and configuration.
+The results obtained by the benchmark runs are reported in a human readable
+presentation. The application designer can then use the benchmark results to
+determine if its system performance requirements are met. The benchmarks shall
+be executed under different environment conditions, e.g. varying cache states
+(dirty, empty, valid) and system bus load generated by other processors. The
+application designer shall have the ability to add additional environment
+conditions, e.g. system bus load by DMA engines or different system bus
+arbitration schemes.
+
+To catch resource and performance regressions via test suite runs there shall be
+a means to specify threshold values for the measured quantities. The threshold
+values should be provided for each validation platform. How this can be done
+and if the threshold values are maintained by the RTEMS Project is subject to
+discussion.
We focused on big-O and whether methods were constant time, bounded, or O(n)
when designing. Perhaps the focus could be there. But this is a design goal for all
of RTEMS and something we would document. Nothing to do except a general
design goal.
This section also sounds like part of what is required by a systems integrator
when leveraging what the FAA calls a Reusable Software Component:
https://www.faa.gov/regulations_policies/advisory_circulars/index.cfm/go/document.information/documentID/22207
You get credit for what's common and have to fill in details for your system.
Author: Trac Migrate
2019-12-19T08:07:34.000Z
Original author: sebastian.huber
Milestone changed from %”5.1” to %”6.1”
Author: Trac Migrate
2022-11-30T08:54:45.000Z
Original author: sebastian.huber
Milestone changed from %”6.1” to %”7.1”
Author: Joel Sherrill
2025-09-18T23:59:32.524Z
changed the description
Author: Joel Sherrill
2025-09-18T23:59:32.575Z
unassigned @tracmigrate
3801 - Rtems 5 BSP Test Failing (opened)¶
Id |
3801 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2019-10-15T09:47:17.000Z |
Updated |
2025-09-19T01:45:42.985Z |
Milestone |
5.4 |
Labels |
priority::normal, tickettype::defect, tool::test, version::5 |
Link |
|
Merges |
0 |
Original author: nigelwsewell
When following the instructions in:
https://docs.rtems.org/branches/master/user/start/bsp-test.html the last command fails:
$rtems-test --rtems-bsp=erc32 --rtems-tools=$HOME/quick-start/rtems/5 .
This could (should?) be replaced by:
$rtems-test --rtems-bsp=erc32-sis --rtems-tools=$HOME/quick-start/rtems/5 .
Further discussion & information found here:
https://stackoverflow.com/questions/58348878/rtems-5-bsp-test-failing
Author: Amar Takhar
2024-04-25T20:47:28.937Z
changed the description
3795 - RTEMS Source Builder | README | Broken link (opened)¶
Id |
3795 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2019-09-10T21:49:28.000Z |
Updated |
2025-09-19T01:45:42.880Z |
Milestone |
5.4 |
Labels |
priority::normal, tickettype::defect, tool::rtems-source-builder, version::5 |
Link |
|
Merges |
0 |
Original author: silvawp
The RTEMS source builder README file refers to wrong link * https://docs.rtems.org/branches/master/rsb/index.html).
It should be: * https://docs.rtems.org/branches/master/user/rsb/index.html
instead
Author: Trac Migrate
2019-09-10T21:49:52.000Z
Original author: silvawp
Attachment 0001-Fix-broken-link.patch added
Author: Amar Takhar
2024-04-25T20:47:27.539Z
changed the description
3790 - Terminal should block in default config case (opened)¶
Id |
3790 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2019-08-23T08:54:24.000Z |
Updated |
2025-09-19T01:45:42.069Z |
Milestone |
5.4 |
Labels |
api::posix, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: andy89.org
Terminal should block in default config case
expected behaviour¶
Open terminal without configure over tcsetattr. read block until new line ICANON is in termios.c_lflag set in default case.
undesired behaviour¶
Open terminal without configure over tcsetattr. read return with return value 0. After reset the default settings with tcgetattr and tcsetattr read shown expected behavior (see Example Code).
target hardware¶
TMS570 with bugfixes see Bug #3789
toolchain version¶
Modified GCC, binutils and gdb build script to build armeb compiler build with RTEMS Source Builder master(see patches for RTEMS Soucre Builder) I need a ARM Compiler with Big Endian Support as default for TMS570 see Bug #3789
configuration options for bsp¶
../rtems/configure ‘–prefix=[bsp path]/bsp/armeb-rtems5’ ‘–host=arm-rtems5’ ‘–target=arm-rtems5’ ‘–enable-posix’ ‘–enable-rtems-debug’ ‘–disable-tests’ ‘–disable-networking’ ‘–enable-rtemsbsp=tms570ls3137_hdk’ ‘CC_FOR_TARGET=armeb-rtems5-gcc’ ‘CXX_FOR_TARGET=armeb-rtem5-gcc’ ‘AR=armeb-rtems5-ar’ ‘TMS570_USE_HWINIT_STARTUP=1’
Test on master commit RTEMS (4a9a58ea8ad75248af5876c01ef654f9bc59c312) with patches for TMS570 see bug #…
Example source code¶
See test.tar.gz
Bug Fix¶
Add initialization for wait variable in tty struct in rtems_termios_open_tty function see patch
Author: Trac Migrate
2019-08-23T08:54:51.000Z
Original author: andy89.org
I can’t upload Atachments the patches and files can be found under: https://www.cs.hs-rm.de/~werner/rtems/bugreport/
Author: Trac Migrate
2019-08-26T05:39:17.000Z
Original author: andy89.org
I am not sure if default Termios settings are specified by POSIX or Linux. Do you have a reference?
Attaching patches should work. What was the error message?
Author: Trac Migrate
2019-08-26T07:49:55.000Z
Original author: andy89.org
Yes the default terminal settings are not defined but is defined the terminal must be initialized. If your Implementation set a default settings this settings should work. At section 11.1.1 of POSIX Spec[1] is defined: Opening a modem or similar piece of equipment connected by a serial line. In this case, the terminal parameters (see Section 11.2, on page 205) may be initialized to default settings by the implementation in between the last close of the device by any process and the next open of the device, or they may persist from one use to the next. The terminal parameters can be set to values that ensure the terminal behaves in a conforming manner by means of the O_TTY_INIT open flag when opening a terminal device that is not already open in any process, or by executing the stty utility with the operand sane. In the Linux kernel every read check the settings and configure the timeout[2]. The default settings in Linux kernel are defined here[3] and differiert to your settings. There was no error message the read call return with 0. For a normal file this mean End-of-file. A return value of 0 is not specified in Canonical mode by POSIX for spezial files.
[1] IEEE Std. 1003.1 Standard for Information Technology—Portable Operating System Interface (POSIX) - 2016 Edition [2] https://elixir.bootlin.com/linux/v5.2.10/source/drivers/tty/n_tty.c#L2132 [3] https://elixir.bootlin.com/linux/v5.2.10/source/drivers/tty/tty_io.c#L121
Author: Trac Migrate
2019-08-27T05:02:38.000Z
Original author: andy89.org
I am not sure if I understood the report correctly. The bug is that you open the device and ICANON is set, but it doesn’t behave like this?
Author: Trac Migrate
2019-08-27T07:42:55.000Z
Original author: andy89.org
Yes, it behave like the device is in polling mode (~ICANON, VMIN=0, VTIME=0). Start my small test Application after setting the default setting again read wait until newline or the buffer is full (Canonical mode).
Author: Trac Migrate
2019-08-27T07:48:40.000Z
Original author: andy89.org
I have little time to take care of this ticket. I think the first step would be to add a generic test case to the testsuites/libtests/termios* tests or add a new test program which reproduces the problem on a simulator BSP, e.g. sparc/erc32.
Author: Chris Johns
2025-09-19T01:45:42.166Z
changed the description
3788 - Documentation of Cygwin Packages (opened)¶
Id |
3788 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2019-08-20T22:07:53.000Z |
Updated |
2025-09-19T01:45:41.894Z |
Milestone |
5.4 |
Labels |
priority::low, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: jeff.mayes
Hi, The documentation of Cygwin, shown here https://docs.rtems.org/branches/master/user/hosts/windows.html#cygwin, needs to be updated. a) python2-devel should be added to the list. b) mingw-zlib-devel should be removed. At least, I can’t find it in the Cygwin Setup repositories.
Author: Chris Johns
2025-09-19T01:45:41.954Z
changed the description
3778 - POSIX Timers Do Not Support SIGEV_THREAD (opened)¶
Id |
3778 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2019-08-05T18:46:19.000Z |
Updated |
2025-09-19T01:45:41.800Z |
Milestone |
5.4 |
Labels |
api::posix, old-indefinite, posix::compliance, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
SIGEV_THREAD in http://pubs.opengroup.org/onlinepubs/9699919799/ is not supported by RTEMS currently.
The Linux specific SIGEV_THREAD_ID is similarly not supported.
Author: Amar Takhar
2024-04-25T20:47:24.143Z
changed the description
3759 - Add rtems-test support for atsam BSP (opened)¶
Id |
3759 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2019-06-13T14:02:12.000Z |
Updated |
2025-09-19T01:45:41.710Z |
Milestone |
5.4 |
Labels |
arch:arm, old-indefinite, priority::high, priority::normal, tickettype::project, tool, version::4.11, version::5 |
Link |
|
Merges |
0 |
Original author: xispa
Hi,
I am currently trying to install and test RTEMS on an ATMEL SAMV71Q21 chip. In order to do so, I carrefully fallowed the instructions provided in the user manual (https://docs.rtems.org/branches/master/user/start/host.html).
The doc aims at running RTEMS on a SPARC architecture, whereas in my case, I try to run it on an ARM. Considering this, all commands featuring “sparc” were replaced by “arm” while installing the tool suite.
After bootstrapping RTEMS’s sources, I configured the BSP using the command :
$HOME/quick-start/src/rtems/configure –prefix=$HOME/quick-start/rtems/5 –enable-maintainer-mode –target=arm-rtems5 –enable-rtemsbsp=atsamv –enable-tests
then built and installed the BSP. These stages seem to work properly as I do not get any errors or warnings.
I am stuck when testing the BSP using the command :
rtems-test –rtems-bsp=? –rtems-tools=$HOME/quick-start/rtems/5 .
What should I specify in –rtems-bsp option considering that I want RTEMS to run on a SAMV71Q21 ? Is there anything else that I have to do before testing the BSP ?
Kind regards,
Author: Trac Migrate
2019-06-14T09:28:04.000Z
Original author: xispa
Milestone changed from %”4.11.3” to %”Indefinite”
Owner set to Needs Funding
Priority changed from ~”high” to ~”normal”
Status changed from new to assigned
Summary changed from Running RTEMS on SAMV71Q21 to Add rtems-test support for atsam BSP
Version changed from ~”4.11” to ~”5”
There is no support for this BSP in rtems-test. You need a debugger or other tools to load the application to the target.
Author: Amar Takhar
2025-09-05T03:01:15.217Z
changed the description
3757 - Alternative memory allocators (opened)¶
Id |
3757 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2019-06-08T08:38:26.000Z |
Updated |
2025-09-19T01:45:41.619Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::low, rtems::score, tickettype::project, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The current memory allocator in RTEMS uses a first fit strategy. This is an excellent allocator if you only allocate memory and never free it. However, for real dynamic workloads which allocate and free memory throughout the application run-time this strategy is subject to
unpredictable allocation times (linear search through free blocks),
memory fragmentation.
The global lock delivers bad performance on SMP systems. RTEMS applications run on a broad range of targets, from uniprocessor 64KiB RAM to SMP systems with more than 4GiB of RAM. So, the allocator should be configurable. Link-time configuration should take into account that some applications never free memory. They should not be forced to link in the free support.
Alternative allocator implementations are:
`kernel malloc based on UMA <../wikis/FreeBSD>`_(https://github.com/freebsd/freebsd/blob/master/sys/kern/kern_malloc.c)
Author: Chris Johns
2022-06-14T06:36:23.000Z
Original author: sebastian.huber
Version ~”5” deleted
Author: Chris Johns
2022-06-14T07:11:14.000Z
Original author: sebastian.huber
The allocator has to provide an aligned allocation call. This can also be called a _boundary constrained_ call.
Author: Amar Takhar
2025-09-05T02:57:40.627Z
changed the description
3752 - Strong APA Scheduler Undocumented (opened)¶
Id |
3752 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2019-05-21T15:14:12.000Z |
Updated |
2025-09-19T01:45:41.521Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
The file confdefs.h has CONFIGURE_SCHEDULER_STRONG_APA but there is no documentation on this scheduler or this configuration parameter.
Author: Trac Migrate
2019-12-19T08:07:34.000Z
Milestone changed from %”5.1” to %”6.1”
Author: Trac Migrate
2022-09-08T07:39:22.000Z
Milestone changed from %”6.1” to %”Indefinite”
Owner set to Needs Funding
The configuration option is now documented.
Author: Amar Takhar
2025-09-05T02:57:40.430Z
changed the description
3744 - A new Constant Bandwidth Server (CBS) version with reduced limitations. (opened)¶
Id |
3744 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2019-05-11T16:56:41.000Z |
Updated |
2025-09-19T01:45:41.333Z |
Milestone |
5.4 |
Labels |
priority::normal, rtems::score, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: jollp
RTEMS provides a version of the CBS scheduler which does not include the following features:
Ability to attach more than one task to a Server;
Budget ( allowed computation time ) replenishment when a task exceeded its previous budget;
The served task is assigned with the ongoing server’s priority.
This ticket presents a new CBS version where all the rules described by Abeni and Buttazzo are correctly implemented. This new version differs from the original CBS implementation on the following aspects:
1. A server can now serve several tasks; 1. When a served task exceeds its reserved capacity, its budget is replenished and the server’s deadline updated and assigned as the new task priority; 1. The callback function is removed due to the modification performed on the CBS behavior when a served task exceeds its reserved computational time; 1. A task is killed when detached from a server since this new version only allows soft real-time tasks to run under Reservation-Based Context.
New Test Cases were developed and are directly included in the patch that will soon be attached.
Author: Trac Migrate
2019-05-11T16:59:20.000Z
Original author: jollp
Cc added @jollp@isep.ipp.pt
Author: Chris Johns
2025-09-19T01:45:41.400Z
changed the description
3740 - Libld does not load incrementially linked object file (opened)¶
Id |
3740 |
State |
opened |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Trac Migrate |
Created |
2019-04-26T05:21:48.000Z |
Updated |
2025-09-19T01:45:41.225Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5, version::7 |
Link |
|
Merges |
1 |
If separate object files have the same local symbol and are incrementally linked libdl only uses the first symbol found.
The issue has been raised by Peter in a post to devel:
https://lists.rtems.org/pipermail/devel/2019-April/025623.html
The issue can be shown with:
$ cat foo.c
#include <stdio.h>
extern void foo(void);
void foo(void)
{
printf("FOO %s\\n", "Foo 1");
}
$ cat bar.c
#include <stdio.h>
extern void bar(void);
void bar(void)
{
printf("BAR %s\\n", "Bar 1");
}
$ arm-rtems5-gcc -march=armv7-a -mthumb -c foo.c
$ arm-rtems5-gcc -march=armv7-a -mthumb -c bar.c
$ arm-rtems5-ld -r -o fubar bar.o foo.o
$ arm-rtems5-readelf -s fubar
Symbol table '.symtab' contains 20 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 SECTION LOCAL DEFAULT 1
2: 00000000 0 SECTION LOCAL DEFAULT 3
3: 00000000 0 SECTION LOCAL DEFAULT 4
4: 00000000 0 SECTION LOCAL DEFAULT 5
5: 00000000 0 SECTION LOCAL DEFAULT 6
6: 00000000 0 SECTION LOCAL DEFAULT 7
7: 00000000 0 FILE LOCAL DEFAULT ABS bar.c
8: 00000000 0 NOTYPE LOCAL DEFAULT 3 $d
9: 00000000 0 NOTYPE LOCAL DEFAULT 3 .LC0
10: 00000008 0 NOTYPE LOCAL DEFAULT 3 .LC1
11: 00000000 0 NOTYPE LOCAL DEFAULT 1 $t
12: 00000000 0 FILE LOCAL DEFAULT ABS foo.c
13: 00000010 0 NOTYPE LOCAL DEFAULT 3 $d
14: 00000010 0 NOTYPE LOCAL DEFAULT 3 .LC0
15: 00000018 0 NOTYPE LOCAL DEFAULT 3 .LC1
16: 0000001c 0 NOTYPE LOCAL DEFAULT 1 $t
17: 00000000 0 NOTYPE GLOBAL DEFAULT UND printf
18: 0000001d 28 FUNC GLOBAL DEFAULT 1 foo
19: 00000001 28 FUNC GLOBAL DEFAULT 1 bar
$ arm-rtems5-objdump --disassemble --source fubar
fubar: file format elf32-littlearm
Disassembly of section .text:
00000000 <bar>:
0: b580 push {r7, lr}
2: af00 add r7, sp, #0
4: f240 0100 movw r1, #0
8: f2c0 0100 movt r1, #0
c: f240 0000 movw r0, #0
10: f2c0 0000 movt r0, #0
14: f7ff fffe bl 0 <printf>
18: bf00 nop
1a: bd80 pop {r7, pc}
0000001c <foo>:
1c: b580 push {r7, lr}
1e: af00 add r7, sp, #0
20: f240 0100 movw r1, #0
24: f2c0 0100 movt r1, #0
28: f240 0000 movw r0, #0
2c: f2c0 0000 movt r0, #0
30: f7ff fffe bl 0 <printf>
34: bf00 nop
36: bd80 pop {r7, pc}
Author: Chris Johns
2019-04-26T21:10:02.000Z
I have updated
dl01adding the example code and build PowerPC and ARM bsps. The PowerPC BSP works while the ARM BSP does not work.The results for the
psimBSP is:$ rtems-run --rtems-bsp=psim `find . -name dl01.exe` RTEMS Testing - Run, 5.0.not_released Command Line: /opt/work/rtems/5/bin/rtems-run --rtems-bsp=psim ./powerpc-rtems5/c/psim/testsuites/libtests/dl01.exe Python: 3.6.6 (default, Oct 2 2018, 01:22:29) [GCC 4.2.1 Compatible FreeBSD Clang 6.0.0 (tags/RELEASE_600/final 326565)] Host: FreeBSD-12.0-RELEASE-p3-amd64-64bit-ELF (FreeBSD ruru 12.0-RELEASE-p3 FreeBSD 12.0-RELEASE-p3 GENERIC amd64 amd64) OpenPIC Version ? (1 CPUs and 1 IRQ sources) at 0x202571776 OpenPIC Vendor 0 (Unknown), Device 0 (Unknown), Stepping 0 Overriding NumSources (1) from configuration with 16 OpenPIC timer frequency is not set BATs must not overlap; area 0x08000000..0x09000000 hits DBAT 0 BATs must not overlap; area 0x0c000000..0x0d000000 hits DBAT 0 *** BEGIN OF TEST libdl (RTL) 1 *** *** TEST VERSION: 5.0.0.be50969881b97180bf4fc1e2975efd41169e08bb-modified *** TEST STATE: EXPECTED-PASS *** TEST BUILD: RTEMS_POSIX_API *** TEST TOOLS: 7.4.0 20181206 (RTEMS 5, RSB d9f49fc117422ea4b039cebc668191e9c07fde25, Newlib 1d35a003f) load: /dl01-o1.o handle: 0x6f668 loaded Loaded module: argc:2 [/opt/work/chris/rtems/kernel/rtems.git/c/src/../../testsuites/libtests/dl01/dl-o1.c] 0: Line 1 1: Line 2 Loaded module: argc:3 [/opt/work/chris/rtems/kernel/rtems.git/c/src/../../testsuites/libtests/dl01/dl-o1.c] 0: Call 2, line 1 1: Call 2, line 2 2: Call 2, line 3 handle: 0x6f668 closed load: /dl01-o2o3.o handle: 0x6f668 loaded FOO Foo 1 BAR Bar 1 handle: 0x6f668 closed *** END OF TEST libdl (RTL) 1 *** *** FATAL *** fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT) fatal code: 0 (0x00000000) RTEMS version: 5.0.0.be50969881b97180bf4fc1e2975efd41169e08bb-modified RTEMS tools: 7.4.0 20181206 (RTEMS 5, RSB d9f49fc117422ea4b039cebc668191e9c07fde25, Newlib 1d35a003f) executing thread ID: 0x08a010001 executing thread name: UI1 Run time : 0:00:01.032580The results for the
xilinx_zynq_a9_qemuis:$ rtems-run --rtems-bsp=xilinx_zynq_a9_qemu `find . -name dl01.exe` RTEMS Testing - Run, 5.0.not_released Command Line: /opt/work/rtems/5/bin/rtems-run --rtems-bsp=xilinx_zynq_a9_qemu ./arm-rtems5/c/xilinx_zynq_a9_qemu/testsuites/libtests/dl01.exe Python: 3.6.6 (default, Oct 2 2018, 01:22:29) [GCC 4.2.1 Compatible FreeBSD Clang 6.0.0 (tags/RELEASE_600/final 326565)] Host: FreeBSD-12.0-RELEASE-p3-amd64-64bit-ELF (FreeBSD ruru 12.0-RELEASE-p3 FreeBSD 12.0-RELEASE-p3 GENERIC amd64 amd64) (process:90678): GLib-WARNING **: 07:02:48.995: gmem.c:490: custom memory allocation vtable not supported Warning: nic cadence_gem.0 has no peer Warning: nic cadence_gem.1 has no peer *** BEGIN OF TEST libdl (RTL) 1 *** *** TEST VERSION: 5.0.0.be50969881b97180bf4fc1e2975efd41169e08bb-modified *** TEST STATE: EXPECTED-PASS *** TEST BUILD: RTEMS_POSIX_API *** TEST TOOLS: 7.4.0 20181206 (RTEMS 5, RSB d9f49fc117422ea4b039cebc668191e9c07fde25, Newlib 1d35a003f) load: /dl01-o1.o handle: 0x117c98 loaded Loaded module: argc:2 [/opt/work/chris/rtems/kernel/rtems.git/c/src/../../testsuites/libtests/dl01/dl-o1.c] 0: Line 1 1: Line 2 Loaded module: argc:3 [/opt/work/chris/rtems/kernel/rtems.git/c/src/../../testsuites/libtests/dl01/dl-o1.c] 0: Call 2, line 1 1: Call 2, line 2 2: Call 2, line 3 handle: 0x117c98 closed load: /dl01-o2o3.o handle: 0x117c98 loaded FOO Foo 1 FOO Foo 1 handle: 0x117c98 closed *** END OF TEST libdl (RTL) 1 *** *** FATAL *** fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT) fatal code: 0 (0x00000000) RTEMS version: 5.0.0.be50969881b97180bf4fc1e2975efd41169e08bb-modified RTEMS tools: 7.4.0 20181206 (RTEMS 5, RSB d9f49fc117422ea4b039cebc668191e9c07fde25, Newlib 1d35a003f) executing thread ID: 0x08a010001 executing thread name: UI1 Run time : 0:00:01.018158
Author: Joel Sherrill
2019-09-25T18:51:23.000Z
Unless someone can point to a failure I am missing, I think this should be closed. I would appreciate Chris or Peter closing this if my testing below demonstrates this is no longer an issue.
Since Chris says this test case has been added to dl01. dl01 passes on xilinx_zynq_a9_qemu with results posted at https://lists.rtems.org/pipermail/build/2019-September/003639.html
For reference, this is the Zynq output which I think is correct:
*** BEGIN OF TEST libdl (RTL) 1 *** *** TEST VERSION: 5.0.0.8798372261ed1df999bc9f4f3f0be0a230480041 *** TEST STATE: EXPECTED-PASS *** TEST BUILD: RTEMS_POSIX_API *** TEST TOOLS: 7.4.1 20190514 (RTEMS 5, RSB 83e0c3ddb8b3474806c9dad4efe4ad6afb0bb937, Newlib 6661a67) load: /dl01-o1.o handle: 0x1124b8 loaded Loaded module: argc:2 [../../../../../../rtems/c/src/../../testsuites/libtests/dl01/dl-o1.c] 0: Line 1 1: Line 2 Loaded module: argc:3 [../../../../../../rtems/c/src/../../testsuites/libtests/dl01/dl-o1.c] 0: Call 2, line 1 1: Call 2, line 2 2: Call 2, line 3 handle: 0x1124b8 closed *** END OF TEST libdl (RTL) 1 *** *** FATAL *** fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT) fatal code: 0 (0x00000000) RTEMS version: 5.0.0.8798372261ed1df999bc9f4f3f0be0a230480041 RTEMS tools: 7.4.1 20190514 (RTEMS 5, RSB 83e0c3ddb8b3474806c9dad4efe4ad6afb0bb937, Newlib 6661a67) executing thread ID: 0x08a010001 executing thread name: UI1Can this be closed?
Author: Trac Migrate
2019-09-29T02:02:40.000Z
no, it still has a failure, not libtests/dl01, but the test example in the mail https://lists.rtems.org/pipermail/devel/2019-April/025623.html
I think I have found the bug, but no one notice the mail I ever wrote. Would you please have a look at the mail https://lists.rtems.org/pipermail/devel/2019-September/055590.html
Author: Chris Johns
2019-09-29T05:13:32.000Z
Replying to jameszxj:
no, it still has a failure, not libtests/dl01, but the test example in the mail https://lists.rtems.org/pipermail/devel/2019-April/025623.html I think I have found the bug, but no one notice the mail I ever wrote. Would you please have a look at the mail https://lists.rtems.org/pipermail/devel/2019-September/055590.html
Thank you for updating the ticket. If you could create a patch for the code and the test case and attach it here it would be a great help.
Author: Trac Migrate
2019-09-29T08:13:58.000Z
Attachment dl-o1.c added
Author: Trac Migrate
2019-09-29T08:14:12.000Z
Attachment dl-o2.c added
Author: Trac Migrate
2019-09-29T08:14:30.000Z
Attachment dl-load.c added
Author: Trac Migrate
2019-09-29T08:19:52.000Z
I complite test case use the follow command
arm-rtems5-gcc -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -mlong-calls -Wall -I. -O2 -c -o wsp/build/dl-o2.o src/dl-o2.c arm-rtems5-gcc -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -mlong-calls -Wall -I. -O2 -c -o wsp/build/dl-o1.o src/dl-o1.c arm-rtems5-ld -r -o wsp/build/dl.out wsp/build/dl-o2.o wsp/build/dl-o1.ooutput message:
handle: 0x2207620 loaded dl_o1_func dl_o1_func handle: 0x2207620 closedThe right output should be:
handle: 0x2207620 loaded dl_o1_func dl_o2_func handle: 0x2207620 closed
Author: Trac Migrate
2019-09-29T08:33:08.000Z
I change the condition from STT_NOTYPE to STB_GLOBAL. It runs OK on my z7000 board, and I try it in my project(origial use RAP foramt), it works too.
Author: Trac Migrate
2019-09-29T08:35:12.000Z
Attachment 0001-fix-rtems_rtl_elf_find_symbol-bug-when-use-dynamic-l.patch added
patch
Author: Chris Johns
2019-09-29T22:16:59.000Z
Thank you for the patch. I am not sure we can remove the check for
STT_NOTYPEso should the change be …if (ELF_ST_BIND(sym->st_info) == STB_GLOBAL || ELF_ST_TYPE(sym->st_info) == STT_NOTYPE || sym->st_shndx == SHN_COMMON) { ...I am concerned removing
STT_NOTYPEmay break other architectures.
Author: Trac Migrate
2019-10-08T01:57:11.000Z
This does not work on arm. From IHI0044E_aaelf.pdf section 4.5.2 , STT_NOTYPE does not mean a global symbol.
The function if(…) is to make a distinction between GLOBAL symbols and LOCAL symbols, so use (ELF_ST_TYPE(sym->st_info) == STT_NOTYPE ) is wrong on ARM architectures. BTW: (ELF_ST_TYPE(sym->st_info) == STT_FUNC) works too on ARM.
But your concern is reasonable, I think we should test on diffrent architectures.
Author: Trac Migrate
2019-11-20T16:22:21.000Z
I’ve successfully run jameszxj’s patch and example code on these architectures/BSPs: Arm/xilinx_zynq_a9_qemu, PowerPC/psim, SPARC/erc32, and i386/pc386. I also ran tests DL01-09 on each stated BSP with and without the fix and ensured that the fix didn’t break any of these tests.
Author: Chris Johns
2019-11-20T22:46:49.000Z
Replying to Lou Woods:
I’ve successfully run jameszxj’s patch and example code on these architectures/BSPs: Arm/xilinx_zynq_a9_qemu, PowerPC/psim, SPARC/erc32, and i386/pc386. I also ran tests DL01-09 on each stated BSP with and without the fix and ensured that the fix didn’t break any of these tests.
Thank you. I assume
dl06anddl09failed as expected?
Author: Trac Migrate
2019-11-21T15:29:47.000Z
Replying to Chris Johns:
Replying to Lou Woods:
I’ve successfully run jameszxj’s patch and example code on these architectures/BSPs: Arm/xilinx_zynq_a9_qemu, PowerPC/psim, SPARC/erc32, and i386/pc386. I also ran tests DL01-09 on each stated BSP with and without the fix and ensured that the fix didn’t break any of these tests.
Thank you. I assume
dl06anddl09failed as expected?dl06failed on all.dl09only failed on erc32, alsodl05failed on pc386.
Author: Chris Johns
2019-11-21T19:31:42.000Z
Replying to Lou Woods:
dl06failed on all.dl09only failed on erc32, alsodl05failed on pc386.Thanks.
Was the result the same without the patch? I suspect it was, as we do not have a test that incrementally links object files. I think it would be good to have one.
I am fine with this patch being push on condition a test is added. If you cannot add a test, that is fine, however I would prefer the patch remains here until we have one.
A complication is this is a change to the build system and would effect Sebastian. I would like his input as well.
Author: Trac Migrate
2019-11-21T22:20:55.000Z
Replying to Chris Johns:
Replying to Lou Woods:
dl06failed on all.dl09only failed on erc32, alsodl05failed on pc386.Thanks. Was the result the same without the patch? Yes
I suspect it was, as we do not have a test that incrementally links object files. I think it would be good to have one. I am fine with this patch being push on condition a test is added. If you cannot add a test, that is fine, however I would prefer the patch remains here until we have one. I don’t think it will be too hard to convert what jameszxj provided into an automated test. I don’t think it is a problem to do that.
A complication is this is a change to the build system and would effect Sebastian. I would like his input as well. I can hold off until Sebastian has weighed in as well.
Author: Chris Johns
2019-11-21T23:15:49.000Z
Replying to Lou Woods:
Replying to Chris Johns:
Replying to Lou Woods:
dl06failed on all.dl09only failed on erc32, alsodl05failed on pc386.Thanks. Was the result the same without the patch?
Yes
OK this means we need a test.
I suspect it was, as we do not have a test that incrementally links object files. I think it would be good to have one. I am fine with this patch being push on condition a test is added. If you cannot add a test, that is fine, however I would prefer the patch remains here until we have one.
I don’t think it will be too hard to convert what jameszxj provided into an automated test. I don’t think it is a problem to do that.
Thanks. I would add it to
dl01unless you think it is best in another test. I do not see a need for a new test.A complication is this is a change to the build system and would effect Sebastian. I would like his input as well.
I can hold off until Sebastian has weighed in as well.
Great, we need to know if we can change the current build system.
Author: Trac Migrate
2019-12-06T20:01:50.000Z
Attachment 0001-dl01-Added-incrementally-linked-object-test-case.patch added
Added incrementally linked object test case to dl01 that works with rtems-tester
Author: Trac Migrate
2019-12-06T20:10:08.000Z
The above test case patch uses the current build system. Once the new build system is settled it can be converted and hopefully merged along with the fix.
Author: Chris Johns
2020-02-26T03:53:43.000Z
Milestone changed from %”5.1” to %”6.1”
Author: Chris Johns
2022-11-29T22:03:01.000Z
Milestone changed from %”6.1” to %”Indefinite”
Owner set to Needs Funding
Version changed from ~”5” to ~”7”
Author: xiaojun zheng
2024-05-03T11:06:07.904Z
mentioned in merge request !18
Author: Ranulfo Raphael
2024-05-06T11:19:47.101Z
mentioned in merge request !19
Author: Ranulfo Raphael
2024-05-07T21:33:02.640Z
mentioned in merge request !25
Author: Chris Johns
2024-06-21T06:00:01.919Z
changed the description
Author: Chris Johns
2024-06-21T06:01:54.176Z
I have reopened this issue because I have not checked the code that was merged. I do not want to revert the change because it may be OK and that only makes for churn and noise. It looks right but this area of code needs checking on a number of hosts.
Author: Sebastian Huber
2024-06-25T06:18:50.074Z
mentioned in merge request !92
3727 - RTEMS 5 raises exception on mvme2100 VME CPU board (PowerPC) (opened)¶
Id |
3727 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2019-03-28T14:54:16.000Z |
Updated |
2025-09-19T01:45:41.129Z |
Milestone |
5.4 |
Labels |
arch:powerpc, priority::high, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: goetzpf
Hello, version 5 of RTEMS crashes on a mvme2100 CPU board.
Here are details of the RTEMS version:
repository : git://git.rtems.org/rtems.git
branch : master
version : cbfc3415607a6943823e8fc47c38408dcc7dbd90
last commit : Thu Mar 14 08:20:54 2019 +0100
build commands:
./bootstrap
mkdir -p build
cd build
../configure --target=powerpc-rtems5 --enable-tests --enable-rtemsbsp="mvme2100 beatnik" --prefix /home/pfeiffer/rtems/rtems/5
make -sj
make install
Booted File:
build/powerpc-rtems5/c/mvme2100/testsuites/libtests/dl10.exe
Boot Messages:
PPC5-Bug>nab
NetBoot about to Begin... Press <ESC> to Bypass, <SPC> to Continue
Network Booting from: DEC21143, Controller 0, Device 0
Device Name: /pci@fec00000/pci1011,19@e,0:0,0
Loading: /opt/IOC/idcp/dl10.exe
Client IP Address = 193.149.12.202
Server IP Address = 193.149.12.6
Gateway IP Address = 193.149.12.1
Subnet IP Address Mask = 255.255.255.0
Boot File Name = /opt/IOC/idcp/dl10.exe
Argument File Name =
Network Boot File load in progress... To abort hit <BREAK>
Bytes Received =&8812400, Bytes Loaded =&8812400
Bytes/Second =&734366, Elapsed Time =12 Second(s)
Residual-Data Located at: $01F5511C
Exception: Program (Illegal Instruction)
SRR0 =00005000 SRR1 =00083040 Vector-Offset =00700
IP =00005000 MSR =00003040 CR =00000000 FPSCR =00000000
R0 =00000000 R1 =01F00000 R2 =00000000 R3 =01F5511C
R4 =00005000 R5 =00000000 R6 =00000000 R7 =00000000
R8 =00000000 R9 =00000000 R10 =00000000 R11 =00000000
R12 =00000000 R13 =00000000 R14 =00000000 R15 =00000000
R16 =00000000 R17 =00000000 R18 =00000000 R19 =00000000
R20 =00000000 R21 =00000000 R22 =00000000 R23 =00000000
R24 =00000000 R25 =00000000 R26 =00000000 R27 =00000000
R28 =00000000 R29 =00000000 R30 =00000000 R31 =00000000
SPR0 =9BBF322F SPR1 =00000000 SPR8 =00000000 SPR9 =00000000
00005000 7F454C46 WORD $7F454C46
PPC5-Bug>
I have seen that dl10.exe compiled for the “beatnik” board support does not crash on a mvme5500 CPU board.
Author: Trac Migrate
2019-03-28T14:58:42.000Z
Original author: goetzpf
An exception also occurs when I build the examples-v2 project and load
examples-v2/hello/both_hello/o-optimize/both_hello.ralfThe exceprion with “hello.ralf” does not occur when I use branch “examples-v2-4-10-branch” of examples-v2 and RTEMS 4.10.
Author: Trac Migrate
2019-03-29T12:32:48.000Z
Original author: goetzpf
It seems that *.exe files cannot be loaded from the mvme2100 CPU anyway, but *.ralf files do.
So, in order to reproduce the bug you have to check out examples-v2 (https://git.rtems.org/examples-v2), build it and load “both_hello.ralf”.
On the mvme2100 cpu this still gives an exception.
The command
hexdump both_hello.ralf | lessshows that the file starts with “.ELF” in ASCII representation, so it is an probably an ELF file. This is probably not the format the CPU bootloader can load.
I verified that for the “beatnik” board support, the file “both_hello.ralf” does not start with “.ELF”, and there the hello world example works.
Author: Joel Sherrill
2019-03-29T13:22:00.000Z
Original author: goetzpf
The transformation step on linked executables (.exe) to downloadable images (.ralf) was dropped from the build system between 4.11 and 5. This is now something that should be done manually.
Specifically the bsp-post-link step is no longer performed. For BSPs that had one, the bsp-post-link definition is still present but not used in the RTEMS build tree. I am unsure offhand it if is used when building applications against the installed RTEMS image like the examples-v2 do with the rtems_waf build system (assuming waf is what you used there)
https://git.rtems.org/rtems/tree/bsps/powerpc/motorola_powerpc/config/mvme2100.cfg
I think this may be what you are seeing.
Author: Chris Johns
2019-03-29T22:33:47.000Z
Original author: goetzpf
Replying to Joel Sherrill:
I am unsure offhand it if is used when building applications against the installed RTEMS image like the examples-v2 do with the rtems_waf build system (assuming waf is what you used there)
It will depend on the build system used to build examples-v2. The 4.10 would be
Makefile.incbased and if the internal change to drop the post link conversion is exposed to themakebuild of examples-v2 it would also be dropped. Thewafbuild does not support any post link conversions because there is no clean way this information could be captured. The work to add this type of support in a uniform way is complex and large given the number of BSPs we have.
Author: Trac Migrate
2019-05-27T08:25:57.000Z
Original author: goetzpf
In [changeset:”f419349a1370ffed9cb3d2322d01e801e012134e/rtems” f419349/rtems]:
bsps/powerpc: Adjust ppcboot.lds The GNU ld had a couple of changes which resulted in a broken bootloader image generation. Recent linker versions tie assignments to their nearest output section statement. Place all absolute symbols which are used with @sectoff relocations into a special section. See also: "Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA" https://www.sourceware.org/ml/binutils/2019-05/msg00183.html Update #3727
Author: Trac Migrate
2019-05-27T08:38:09.000Z
Original author: goetzpf
In [changeset:”a00052a341010ac7cf688e6366d7a3a96b48926f/rtems-docs” a00052a/rtems-docs]:
user: Document boot image generation Update #3727.
Author: Trac Migrate
2019-06-27T12:39:56.000Z
Original author: goetzpf
In [changeset:”9b858ee6ef0805fc0671ed226d66295395d26cbc/rtems” 9b858ee/rtems]:
bsp/motorola_powerpc: Fix linker command file Fix the __size symbol value to reflect the total size of the bootloader. This prevents a bootloader crash with application images above a certain threshold (e.g. fileio sample program). Update #3727.
Author: Chris Johns
2021-02-07T22:09:14.000Z
Original author: goetzpf
Is the issue in this ticket fixed? Can the ticket be closed?
Author: Joel Sherrill
2021-02-08T04:48:35.000Z
Original author: goetzpf
If this runs on the board you have access to, close it.
Author: Chris Johns
2021-02-09T22:36:53.000Z
Original author: goetzpf
Replying to Joel Sherrill:
If this runs on the board you have access to, close it.
Who is this too?
If me, I do not have a mvme2100. The defines in the code means the mvme2100 is built differently to the mvme2[67]00.
Author: Joel Sherrill
2021-02-09T23:22:49.000Z
Original author: goetzpf
It was to you Chris. Ask on the list for someone with an MVME2100 to test with. I don’t remember who Richard added mvme2100 support for. I might be able to dig it up. But we need a tester. Otherwise, we just may have to close this.
Author: Amar Takhar
2024-04-25T20:47:19.056Z
changed the description
3721 - Doxygen param “in/out” attributes not matching function behavior (opened)¶
Id |
3721 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2019-03-08T15:00:34.000Z |
Updated |
2025-09-19T01:45:40.949Z |
Milestone |
5.4 |
Labels |
priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: JSchweikhardt
It would seem that a number of doxygen comments in the source code do not match the function’s behavior.
Example: /cpukit/include/rtems/rtems/message.h
171 /**
172 * @brief RTEMS Message Queue Receive
173 *
174 * This routine implements the rtems_message_queue_receive directive.
175 * This directive is invoked when the calling task wishes to receive
176 * a message from the message queue indicated by ID. The received
177 * message is to be placed in buffer. If no messages are outstanding
178 * and the option_set indicates that the task is willing to block,
179 * then the task will be blocked until a message arrives or until,
180 * optionally, timeout clock ticks have passed.
181 *
182 * @param[in] id is the queue id
183 * @param[in] buffer is the pointer to message buffer
184 * @param[in] size is the size of message receive
185 * @param[in] option_set is the options on receive
186 * @param[in] timeout is the number of ticks to wait
187 *
188 * @retval This method returns RTEMS_SUCCESSFUL if there was not an
189 * error. Otherwise, a status code is returned indicating the
190 * source of the error.
191 */
192 rtems_status_code rtems_message_queue_receive(
193 rtems_id id,
194 void *buffer,
195 size_t *size,
196 rtems_option option_set,
197 rtems_interval timeout
198 );
Since the parameters “buffer” and “size” are output parameters, the comment should say
183 * @param[out] buffer is the pointer to message buffer
184 * @param[out] size is the size of message receive
There are other functions where this is inconsistent, so a look at all functions taking pointer parameters is likely a good idea.
Author: Joel Sherrill
2019-03-08T15:10:30.000Z
Original author: JSchweikhardt
This method was not the best example to pick to back up your case. The size parameter is used as *size for the size of the caller’s buffer and filled in on output with the size of the message actually received.
https://git.rtems.org/rtems/tree/cpukit/score/src/coremsgseize.c#n46
This particular case is indeed in/out.
Others may indicate the thinking that the pointer was an input and *pointer was the output.
Author: Trac Migrate
2019-03-08T15:36:17.000Z
Original author: JSchweikhardt
OK, from the description it was not clear that size is actually [inout]. Maybe there’s room for improvement as well.
As for “Others may indicate” I would argue that in that case “in” is redundant, or even pointless, since in C parameters are always passed by value, so can only be “in” by language definition.
Nit-pick: the coremsgseize.c you reference says “@brief Size” where it meant “Seize”. :-)
Author: Joel Sherrill
2019-03-08T19:02:36.000Z
Original author: JSchweikhardt
Replying to Jens Schweikhardt:
OK, from the description it was not clear that size is actually [inout]. Maybe there’s room for improvement as well.
I think this may be the only case in the Classic API where the value of a *argument is expected to have a value set by the caller.. So I was picking a bit at the unlucky choice for an example. :)
The fact you landed on this one as an example without realizing that may indicate the documentation could be improved. :(
This still doesn’t answer the question of how an output parameter via pointer should be annotated. The pointer has a value on input (e.g. in) but the *pointer is where the output goes.
And the Doxygen for this method doesn’t indicate that the buffer and *size will be set on success. :(
As for “Others may indicate” I would argue that in that case “in” is redundant, or even pointless, since in C parameters are always passed by value, so can only be “in” by language definition.
Yes. This is true. But the personality of the people who did this are anal about consistency. If you say out or inout for some, what is the output for those where nothing is said in the input? Does it look like a mistake not to include in annotation? It is redundant but makes things consistent.
Nit-pick: the coremsgseize.c you reference says “@brief Size” where it meant “Seize”. :-)
Got it. I fixed that locally and will push a commit when I catch my next round of patches.
Interestingly, Seize breaks the rule of “i before e except after c”
Author: Trac Migrate
2019-03-11T06:07:44.000Z
Original author: JSchweikhardt
The use of these [in], [out] and [in,out] specifiers is inconsistent and no clear guideline exits yet for the project. See also #3704 and https://lists.rtems.org/pipermail/devel/2019-February/024988.html.
Author: Trac Migrate
2019-03-11T09:05:27.000Z
Original author: JSchweikhardt
If I had to devise a (rough?) guideline:
only pointer parameters are annotated (since scalars are [in] by language definition)
[in] indicates that the pointer must point to an initialized object (it may be dereferenced by the directive)
[out] indicates that the object pointed to may be written by the directive
[inout] If both 2) and 3) apply.
This is basically how I interpret these annotations from the Interface Definition Languages from a past life where I used CORBA with a C binding. Word-smithing suggestions welcome.
Author: Chris Johns
2025-09-19T01:45:41.017Z
changed the description
3700 - Add rtems_rate_monotonic_deadline() (opened)¶
Id |
3700 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Created |
2019-02-26T09:50:42.000Z |
Updated |
2025-09-19T01:45:40.855Z |
Milestone |
5.4 |
Labels |
priority::normal, qualification, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
Depending on the scheduler selection, the rtems_rate_monotonic_period() behaves differently. In case the EDF scheduler is configured, then tasks using a rate-monotonic object have a higher priority (based on deadline) than the fixed priority background tasks. This is quite bad for applications which want to use the periods with a fixed priority just to get statistics and a deadline miss detection. The default SMP scheduler provides EDF functionality, so this is an issue while porting applications to SMP systems. To give applications more control, add a new function:
/**
* @brief Starts a deadline and period.
*
* This routine starts a deadline and period. In case Earliest Deadline First
* (EDF) scheduling is available, then the priority of the executing task is
* adjusted according to the specified deadline. The next activation of the
* executing task is specified by the period parameter.
*
* @param id The rate monotonic object identifier.
* @param deadline The deadline in ticks. Must be positive.
* @param period The period in ticks. Must be greater than or equal to the deadline.
*
* @retval RTEMS_SUCCESSFUL Successful operation.
* @retval RTEMS_INVALID_ID No period objects exists for the specified object
* identifier.
* @retval RTEMS_NOT_OWNER_OF_RESOURCE The period object belongs to another task.
* @retval RTEMS_INVALID_NUMBER The deadline is zero or the period is less than the deadline.
* @retval RTEMS_TIMEOUT The previous deadline was missed.
*/
rtems_status_code rtems_rate_monotonic_deadline(
rtems_id id,
rtems_interval deadline,
rtems_interval period
);
The new function uses two timing parameters to allow constrained deadlines and not only implicit deadlines.
The rtems_rate_monotonic_period() function should be changed to not alter the task priority depending on the implicit deadline. This avoids surprises while changing the scheduler to EDF in existing applications (especially while porting to an SMP system).
Author: Trac Migrate
2019-02-26T09:53:35.000Z
Original author: sebastian.huber
Original author: sebastian.huber
Description changed
Depending on the scheduler selection, the rtems_rate_monotonic_period() behaves differently. In case the EDF scheduler is configured, then tasks using a rate-monotonic object have a higher priority (based on deadline) than the fixed priority background tasks. This is quite bad for applications which want to use the periods with a fixed priority just to get statistics and a deadline miss detection. The default SMP scheduler provides EDF functionality, so this is an issue while porting applications to SMP systems. To give applications more control, add a new function: {{{ /** * @brief Starts a deadline and period. * * This routine starts a deadline and period. In case Earliest Deadline First * (EDF) scheduling is available, then the priority of the executing task is * adjusted according to the specified deadline. The next activation of the * executing task is specified by the period parameter. * * @param id The rate monotonic object identifier. * @param deadline The deadline in ticks. Must be positive. * @param period The period in ticks. Must be greater than or equal to the deadline. * * @retval RTEMS_SUCCESSFUL Successful operation. * @retval RTEMS_INVALID_ID No period objects exists for the specified object * identifier. * @retval RTEMS_NOT_OWNER_OF_RESOURCE The period object belongs to another task. * @retval RTEMS_INVALID_NUMBER The deadline is zero or the period is less than the deadline. * @retval RTEMS_TIMEOUT The previous deadline was missed. */ rtems_status_code rtems_rate_monotonic_deadline( rtems_id id, rtems_interval deadline, rtems_interval period ); }}} The new function uses two timing parameters to allow constrained deadlines and not only implicit deadlines. + + The rtems_rate_monotonic_period() function should be changed to not alter the task priority depending on the implicit deadline. This avoids surprises while changing the scheduler to EDF in existing applications (especially while porting to an SMP system).
Author: Trac Migrate
2019-02-26T12:40:41.000Z
Original author: sebastian.huber
What complicates the interface a bit is that rtems_rate_monotonic_deadline() is called after the current job is done (like rtems_rate_monotonic_period()) with parameters for the next job. This means that the constraint period >= deadline for the parameters makes no sense. The period should specify the time from the last activation to the next activation. The deadline should specify the time from the next activation to the deadline time point. The function checks that you have met the last deadline.
Author: Joel Sherrill
2019-12-13T14:30:05.000Z
Original author: sebastian.huber
Milestone changed from %”5.1” to %”6.1”
Pushing to 6.1. This is a recent ticket requesting an enhancement and should not block a 5 release.
Author: Trac Migrate
2020-06-29T21:18:44.000Z
Original author: sebastian.huber
We are seeing a behavior with EDF enabled in SMP mode that we see a hang under load. The test stimulus that we have isolated this to is now very simple.
for(uint32_t j = 0; j < test_iterations; j++) { sc = pthread_mutex_lock(&mx); rtems_test_assert(sc == RTEMS_SUCCESSFUL); NOP; sc = pthread_mutex_unlock(&mtx); rtems_test_assert(sc == RTEMS_SUCCESSFUL); }
When we run this pretty much basic unit test all OK. Then we run more and more threads in parallel and we see RTEMS lock up. When we go to the simple round-robin scheduler we can run these loops forever with as many threads as we want and don’t see a lock-up.
Apologies if I am posting the question in the wrong place - I want to avoid creating spam. Sebastian seems to be the expert on EDF and we are wondering if this is a known issue with a lock-up under load with EDF enabled.
Author: Trac Migrate
2020-06-30T05:09:02.000Z
Original author: sebastian.huber
Replying to Jonathan Walsh:
Apologies if I am posting the question in the wrong place - I want to avoid creating spam. Sebastian seems to be the expert on EDF and we are wondering if this is a known issue with a lock-up under load with EDF enabled. I moved this issue to a new ticket: #4019.
Author: Trac Migrate
2021-11-19T14:45:12.000Z
Original author: sebastian.huber
Milestone changed from %”6.1” to %”7.1”
Author: Amar Takhar
2024-04-25T20:47:07.202Z
changed the description
Author: Joel Sherrill
2025-09-18T23:58:07.507Z
unassigned @tracmigrate
3697 - pthread_once() lacks proper support for thread cancellation (opened)¶
Id |
3697 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2019-02-21T09:19:27.000Z |
Updated |
2025-09-19T01:45:40.764Z |
Milestone |
5.4 |
Labels |
api::posix, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_once.html
“The pthread_once() function is not a cancellation point. However, if init_routine is a cancellation point and is canceled, the effect on once_control shall be as if pthread_once() was never called.”
Author: Amar Takhar
2025-09-05T03:01:14.129Z
changed the description
3663 - Add nl_types.h support (opened)¶
Id |
3663 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-12-17T14:34:33.000Z |
Updated |
2025-09-19T01:45:40.673Z |
Milestone |
5.4 |
Labels |
old-indefinite, posix, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: Abr
POSIX Defines the functionality included in nl_types.h in http://pubs.opengroup.org/onlinepubs/7908799/xsh/nl_types.h.html
Author: Trac Migrate
2018-12-17T14:51:58.000Z
Original author: Abr
Milestone set to %”Indefinite”
Version set to ~”5”
Author: Amar Takhar
2024-04-25T20:47:00.095Z
changed the description
3656 - Function prototypes for posix_fadvise() and posix_fallocate() missing in <fcntl.h> header file (opened)¶
Id |
3656 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-12-10T07:36:02.000Z |
Updated |
2025-09-19T01:45:40.579Z |
Milestone |
5.4 |
Labels |
old-indefinite, posix::compliance, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: Zenon
Referring to the POSIX specification page, http://pubs.opengroup.org/onlinepubs/9699919799/, the page for <fcntl.h>. fcntl.h should contain the function prototype for posix_fadvise() and posix_fallocate(). However, currently, these are not implemented in <fcntl.h> header file.
Author: Amar Takhar
2024-04-25T20:46:56.833Z
changed the description
3642 - Add iswalnum(), iswalpha() … (and 18 others) to <wchar.h> header (opened)¶
Id |
3642 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-12-07T17:34:27.000Z |
Updated |
2025-09-19T01:45:40.485Z |
Milestone |
5.4 |
Labels |
api::posix, old-indefinite, posix::compliance, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: Zenon
`` #include <wchar.h> `` fails to declare function prototypes for
iswalnum()
iswalpha()
iswcntrl()
iswctype()
iswdigit()
iswgraph()
iswlower()
iswprint()
iswpunct()
iswspace()
iswupper()
iswxdigit()
as required to be POSIX-Compliant. Even though they are marked obsolescent, they should be implemented until the function prototype are removed (in a newer version).
When fixed, please remove #include <wctype.h> and the corresponding comments referring to this ticket, from the following files:
pwd: rtems/testsuites/psxtests/psxhdrs/wchar/
iswalnum.c
iswalpha.c
iswcntrl.c
iswctype.c
iswdigit.c
iswgraph.c
iswlower.c
iswprint.c
iswpunct.c
iswspace.c
iswupper.c
iswxdigit.c
Author: Trac Migrate
2018-12-07T17:51:54.000Z
Original author: Zenon
Hi! Since I don’t have edit rights to the descriptions, I would add it as a comment for a mentor to add it inside:
Please add the following functions to the list of functions:
vfwprintf() vfwscanf() vswprintf() vswscanf() vwprintf() vwscanf() towlower() towupper()
as well as the following files:
vfwprintf.c vfwscanf.c vswprintf.c vswscanf.c vwprintf.c vwscanf.c towlower.c towupper.c
Author: Trac Migrate
2018-12-07T17:52:15.000Z
Original author: Zenon
Summary changed from Add iswalnum(), iswalpha() … (and 10 others) to <wchar.h> header to Add iswalnum(), iswalpha() … (and 18 others) to <wchar.h> header
Author: Amar Takhar
2024-04-25T20:46:51.118Z
changed the description
3635 - Remove #if defined(__CYGWIN__) from complex.h header file (opened)¶
Id |
3635 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-12-05T22:50:05.000Z |
Updated |
2025-09-19T01:45:40.391Z |
Milestone |
5.4 |
Labels |
api::posix, old-indefinite, posix::compliance, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: Zenon
Re: GCI 2018 POSIX Compliance test for complex.h file Without declaring ``#define __CYGWIN__ 1 ``, including complex.h itself does not allow the execution of the functions.
The #if defined (__CYGWIN__) wrapping these lines should be removed:
#if defined(__CYGWIN__)
long double complex cacosl(long double complex);
long double complex ccosl(long double complex);
long double complex csinl(long double complex);
long double complex ctanl(long double complex);
long double complex cacoshl(long double complex);
long double complex casinhl(long double complex);
long double complex catanhl(long double complex);
long double complex ccoshl(long double complex);
long double complex csinhl(long double complex);
long double complex ctanhl(long double complex);
long double complex cexpl(long double complex);
long double complex cpowl(long double complex, long double complex);
long double complex conjl(long double complex);
long double complex cprojl(long double complex);
When the bug is fixed, the following files need to have ``#define __CYGWIN__ 1 `` removed, along with the corresponding comments referring to this ticket:
In /testsuites/psxtests/psxhdrs/complex/
cacosl.c ccosl.c csinl.c ctanl.c cacoshl.c casinhl.c catanhl.c ccoshl.c csinhl.c ctanhl.c cexpl.c cpowl.c conjl.c cprojl.c
Author: Amar Takhar
2024-04-25T20:46:48.368Z
changed the description
3628 - moxie/moxiesim rtems-syms unknown machine type (opened)¶
Id |
3628 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2018-11-29T16:52:24.000Z |
Updated |
2025-09-19T01:45:40.276Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
dl07 fails due to unknown machine type:
rtems-syms -e -c "-Os -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs" -o dl07-sym.o dl07.pre
error: machine-type: unknown machine type: 223
gmake[5]: *** [dl07-sym.o] Error 10
Author: Chris Johns
2020-02-26T03:55:18.000Z
Milestone changed from %”5.1” to %”Indefinite”
Owner set to Needs Funding
Author: Amar Takhar
2025-09-05T03:01:13.741Z
changed the description
3610 - [UPDATE WIKI PAGE] TBR/Review/Debugging/Start (opened)¶
Id |
3610 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-11-16T18:19:16.000Z |
Updated |
2025-09-19T01:45:40.163Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: Shashvat Jain
THe page https://devel.rtems.org/wiki/TBR/Review/Debugging/Start contains old and outdated information regarding debugging, update this page and add it to a suitable module in rtems-docs.
Below is the outline of the content there. Some of the content could be updated and useful. As a review guide, here is the outline. If the content of a section be deleted because that topic is covered elsewhere, we should note where the content is next to the section, and delete it from the TBR page. If it needs updating and moved, note that and where to. But let’s track this until the page can be deleted. This will take a bit of nibbling by multiple people.
Debugging
Symbolic Debug Information
Hardware Assisted Debugging
Coldfire and M683xx BDM
Debugging a BSP
GDB and RTEMS
Eclipse Plug-in
How much memory is left in the C Program Heap?
How much memory is left in the RTEMS Workspace?
BSP rtems_initialize_executive_late call dies
GDB Cannot Find My Source Files
Starting With Hello World
Standard IO and File Issues
Newlib’s Stdio Functions return -1/EOF
open, fopen, and socket creation fail
Optional Debugging Tools Provided by RTEMS
RTEMS Monitor
Capture Engine
CPU Usage Monitoring
Stack Checker
Optional Compile-time Selections
Author: Joel Sherrill
2018-11-16T18:50:00.000Z
Original author: Shashvat Jain
Description changed
- this page contains old and outdated information regarding debugging ,update this page and add it to a suitable module in rtems-docs. ? ^^^^ - + THe page https://devel.rtems.org/wiki/TBR/Review/Debugging/Start contains old and outdated information regarding debugging, update this page and add it to a suitable module in rtems-docs. ? ^^^ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + + + Below is the outline of the content there. Some of the content could be updated and useful. As a review guide, here is the outline. If the content of a section be deleted because that topic is covered elsewhere, we should note where the content is next to the section, and delete it from the TBR page. If it needs updating and moved, note that and where to. But let's track this until the page can be deleted. This will take a bit of nibbling by multiple people. + + * Debugging + * Symbolic Debug Information + * Hardware Assisted Debugging + * Coldfire and M683xx BDM + * Debugging a BSP + * GDB and RTEMS + + * Eclipse Plug-in + + * How much memory is left in the C Program Heap? + + * How much memory is left in the RTEMS Workspace? + + * BSP rtems_initialize_executive_late call dies + + * GDB Cannot Find My Source Files + + * Starting With Hello World + + * Standard IO and File Issues + * Newlib's Stdio Functions return -1/EOF + * open, fopen, and socket creation fail + + * Optional Debugging Tools Provided by RTEMS + + * RTEMS Monitor + * Capture Engine + * CPU Usage Monitoring + * Stack Checker + * Optional Compile-time Selections
Milestone changed from %”5.1” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Version ~”5” deleted
Author: Amar Takhar
2025-09-05T03:01:13.297Z
changed the description
3607 - Qemu build failure on Msys2 (opened)¶
Id |
3607 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2018-11-14T20:26:59.000Z |
Updated |
2025-09-19T01:45:40.060Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool::rtems-source-builder, version::5 |
Link |
|
Merges |
0 |
Current RSB master builds qemu a while on MSYS2 before failure as follows:
libtool: link: x86_64-w64-mingw32-gcc -O2 -pipe -I/c/msys64/home/jrs007/rtems-source-builder/bare/build/tmp/sb-jrs007/d/c/msys64/home/jrs007/tools/include -shared .libs/iconv.o .libs/localcharset.o .libs/relocatable.o .libs/iconv-exports.o .libs/libiconv.res.o -L/c/msys64/home/jrs007/rtems-source-builder/bare/build/tmp/sb-jrs007/d/c/msys64/home/jrs007/tools/lib -O2 -Wl,--export-all-symbols -O2 -o .libs/libiconv-2.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libiconv.dll.a
.libs/iconv.o: In function `libiconv_open':
C:\\msys64\\home\\jrs007\\rtems-source-builder\\bare\\build\\l1xwm1\\build\\lib/../../libiconv-1.14/lib/iconv_open1.h:176: undefined reference to `aliases2_lookup'
.libs/iconv.o: In function `libiconv_open_into':
C:\\msys64\\home\\jrs007\\rtems-source-builder\\bare\\build\\l1xwm1\\build\\lib/../../libiconv-1.14/lib/iconv_open1.h:176: undefined reference to `aliases2_lookup'
This is a known issue and the workarounds are at https://savannah.gnu.org/bugs/?47953
Which of the two alternatives is best to incorporate into the RSB?
Author: Chris Johns
2018-11-14T22:56:24.000Z
Status changed from assigned to new
Author: Chris Johns
2018-11-14T22:56:54.000Z
Milestone changed from %”5.1” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2025-09-05T03:01:12.919Z
changed the description
3582 - Remove dedicated support for boundary constraint in heap allocator (opened)¶
Id |
3582 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-11-07T11:02:37.000Z |
Updated |
2025-09-19T01:45:39.960Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, rtems::score, tickettype::task, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
Some time ago a dedicated support for a boundary constraint was added to the first fit heap allocator. The use case for this is the libbsd (new network stack) which needs this for the bus space allocator:
https://www.freebsd.org/cgi/man.cgi?query=bus_dma
It turned out that this feature is rarely used. It makes the first fit heap allocator implementation considerably more complex. It is also not a standard allocator feature which makes it more difficult to replace the first fit heap allocator with something else, e.g. TLSF.
The boundary constraint can be also satisfied by an allocator which supports only the alignment constraint via:
if (boundary > alignment) {
assert(alignment == 0 || boundary % alignment == 0);
alignment = boundary;
}
Author: Trac Migrate
2019-12-19T08:07:34.000Z
Original author: sebastian.huber
Milestone changed from %”5.1” to %”6.1”
Author: Chris Johns
2022-06-14T06:46:19.000Z
Original author: sebastian.huber
TLSF provides
tlsf_memalign(). I think this ticket can be closed and the requirement for an aligned allocation call for any new allocators be made.
Author: Chris Johns
2022-06-14T06:46:52.000Z
Original author: sebastian.huber
Milestone changed from %”6.1” to %”Indefinite”
Version ~”5” deleted
Author: Trac Migrate
2022-06-20T05:51:24.000Z
Original author: sebastian.huber
This ticket refers to the first fit allocator. Removing the boundary support would simplify the implementation a bit. We should replace the first fit allocator with TLSF, so this ticket is probably obsolete.
Author: Chris Johns
2022-06-20T07:41:33.000Z
Original author: sebastian.huber
Replying to Sebastian Huber:
This ticket refers to the first fit allocator. Removing the boundary support would simplify the implementation a bit. We should replace the first fit allocator with TLSF, so this ticket is probably obsolete.
I agree and thanks and that was my view. Please close if you think it would be covered in the other ticket.
Author: Amar Takhar
2025-09-05T02:57:39.694Z
changed the description
3544 - Coverity flags use of uninitialized variable in e500-mmu.c (opened)¶
Id |
3544 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2018-10-09T13:41:29.000Z |
Updated |
2025-09-19T01:45:39.846Z |
Milestone |
5.4 |
Labels |
arch:powerpc, old-indefinite, priority::normal, scan::coverity, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Coverity ids: 1440032 1440034 1440037 1440042
I am unsure why rtems_interrupt_disable() is confusing Coverity in this one file but it seems odd. I would expect it to be causing more issues.
519rtems_e500_tlb_idx
520rtems_e500_ftlb(uint32_t ea, int as)
521{
522uint32_t pid, mas0, mas1;
523int i, rval = -1;
1. var_decl: Declaring variable lvl without initializer.
524rtems_interrupt_level lvl;
525
CID 1440042 (#1 of 1): Uninitialized scalar variable (UNINIT)
2. uninit_use_in_call: Using uninitialized value lvl when calling rtems_interrupt_disable.
526 rtems_interrupt_disable(lvl);
Author: Joel Sherrill
2018-10-09T13:41:47.000Z
Owner set to sebastian.huber
Status changed from new to assigned
Author: Joel Sherrill
2018-10-13T22:56:00.000Z
Milestone changed from %”5.1” to %”5.2”
Author: Joel Sherrill
2018-10-14T00:21:43.000Z
Milestone changed from %”5.2” to %”4.11.1”
Author: Trac Migrate
2018-10-18T13:24:46.000Z
Milestone changed from %”4.11.1” to %”Indefinite”
Author: Amar Takhar
2024-04-25T20:46:32.288Z
changed the description
3534 - Reduce uses of rtems_event_transient_send() (opened)¶
Id |
3534 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Created |
2018-10-01T06:16:28.000Z |
Updated |
2025-09-19T01:45:39.752Z |
Milestone |
5.4 |
Labels |
device, priority::normal, tickettype::task, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The transient event predates the self-contained binary semaphores available now via <rtems/threads.h> and is used as workaround to avoid explicit synchronization objects. There are two issues with the transient event.
It is a per-thread resources and using it for different components makes debugging/development difficult. Issues noticed in one component my be caused by another component.
The diagnostic information (e.g. “task” shell command) is poor.
Replace the transient event with a binary semaphore if possible.
The performance test tmonetoone:
*** BEGIN OF TEST TMONETOONE ***
*** TEST VERSION: 6.0.0.4ac51046e0cd6d22d4c89f6d0bbea2383898d698
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_SMP
*** TEST TOOLS: 10.0.1 20200406 (RTEMS 6, RSB b69f54d51740810dc54a50662f5da4d4ba0ddd18, Newlib ece49e4)
yield
a 25425
b 25424
event
a 14082
b 14082
self-contained binary semaphore
a 12449
b 12449
Classic binary semaphore (FIFO)
a 12525
b 12524
Classic binary semaphore (priority)
a 11649
b 11649
*** END OF TEST TMONETOONE ***
shows that the events performing slightly better than the binary semaphores. However, the yield count is about two times the binary semaphore count.
This raises the question if we have to offer a better synchronization primitive for the request and wait for response type actions. This pattern is quite common in device drivers.
Author: Trac Migrate
2018-10-01T06:16:36.000Z
Original author: sebastian.huber
Owner set to sebastian.huber
Status changed from new to assigned
Author: Trac Migrate
2018-10-01T07:03:10.000Z
Original author: sebastian.huber
In [changeset:”fca9132aa5435a44a4a64adaa8438a177b33cab6/rtems” fca9132/rtems]:
bsp/atsam: Use binary semaphore for SPI Update #3534.
Author: Trac Migrate
2018-10-01T07:03:25.000Z
Original author: sebastian.huber
In [changeset:”5cb23f4b8870499b306cfb99186aa484ed0a47f1/rtems” 5cb23f4b/rtems]:
bsp/atsam: Use binary semaphore for I2C Remove superfluous sleep before each I2C transfer. Reset I2C module after transfer timeouts. Update #3534.
Author: Trac Migrate
2019-12-19T08:07:34.000Z
Original author: sebastian.huber
Milestone changed from %”5.1” to %”6.1”
Author: Trac Migrate
2020-07-24T09:38:42.000Z
Original author: sebastian.huber
Original author: sebastian.huber
Description changed
The transient event predates the self-contained binary semaphores available now via <rtems/threads.h> and is used as workaround to avoid explicit synchronization objects. There are two issues with the transient event. 1. It is a per-thread resources and using it for different components makes debugging/development difficult. Issues noticed in one component my be caused by another component. 2. The diagnostic information (e.g. "task" shell command) is poor. Replace the transient event with a binary semaphore if possible. + + The performance test tmonetoone: + {{{ + *** BEGIN OF TEST TMONETOONE *** + *** TEST VERSION: 6.0.0.4ac51046e0cd6d22d4c89f6d0bbea2383898d698 + *** TEST STATE: EXPECTED_PASS + *** TEST BUILD: RTEMS_SMP + *** TEST TOOLS: 10.0.1 20200406 (RTEMS 6, RSB b69f54d51740810dc54a50662f5da4d4ba0ddd18, Newlib ece49e4) + yield + a 25425 + b 25424 + event + a 14082 + b 14082 + self-contained binary semaphore + a 12449 + b 12449 + Classic binary semaphore (FIFO) + a 12525 + b 12524 + Classic binary semaphore (priority) + a 11649 + b 11649 + + *** END OF TEST TMONETOONE *** + }}} + shows that the events performing slightly better than the binary semaphores. However, the yield count is about two times the binary semaphore count. + + This raises the question if we have to offer a better synchronization primitive for the request and wait for response type actions. This pattern is quite common in device drivers.
Author: Trac Migrate
2022-09-08T08:08:29.000Z
Original author: sebastian.huber
Milestone changed from %”6.1” to %”7.1”
Author: Joel Sherrill
2025-09-18T23:54:16.782Z
changed the description
Author: Joel Sherrill
2025-09-18T23:54:22.116Z
unassigned @tracmigrate
3524 - Add a separate system initialization handler set for secondary processors (opened)¶
Id |
3524 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-09-20T12:36:44.000Z |
Updated |
2025-09-19T01:45:39.657Z |
Milestone |
5.4 |
Labels |
priority::normal, rtems::score, tickettype::task, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
Currently the only the boot processor calls system initialization handlers in rtems_initialize_executive(). Add a second set of handlers which are called by secondary processors in _SMP_Start_multitasking_on_secondary_processor() after the CPU state change to PER_CPU_STATE_READY_TO_START_MULTITASKING.
The use case for this are device drivers and extensions such as the stack checker.
Author: Trac Migrate
2019-12-19T08:07:34.000Z
Original author: sebastian.huber
Milestone changed from %”5.1” to %”6.1”
Author: Trac Migrate
2022-01-26T13:32:46.000Z
Original author: sebastian.huber
Milestone changed from %”6.1” to %”7.1”
Author: Joel Sherrill
2025-09-18T23:53:21.276Z
changed the description
3521 - JFFS2 has a year 2038 problem (opened)¶
Id |
3521 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-09-17T10:16:53.000Z |
Updated |
2025-09-19T01:45:39.556Z |
Milestone |
5.4 |
Labels |
filesystem::jffs2, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
We have 32-bit time values in:
/* The JFFS2 raw inode structure: Used for storage on physical media. */
/* The uid, gid, atime, mtime and ctime members could be longer, but
are left like this for space efficiency. If and when people decide
they really need them extended, it's simple enough to add support for
a new type of raw node.
*/
struct jffs2_raw_inode
{
...
jint32_t atime; /* Last access time. */
jint32_t mtime; /* Last modification time. */
jint32_t ctime; /* Change time. */
...
};
Author: Amar Takhar
2025-09-05T03:01:12.342Z
changed the description
3515 - covoar failure while running for full testsuites/ (opened)¶
Id |
3515 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-09-13T08:37:37.000Z |
Updated |
2025-09-19T01:45:39.460Z |
Milestone |
5.4 |
Labels |
priority::normal, rtems::testing, scan::coverage, tickettype::defect, tool, version::5 |
Link |
|
Merges |
0 |
Original author: thelunatic
The covoar fails to complete for some symbol-sets with specific exes. below I have noted all the sybol-sets that fail, along with the exe that causes the failure.
It is observed that when covoar is run excluding these exes, it completes successfully .
posix
sptests/spmutex01.exe
fstests/fsclose01.exe
sapi
sptests/spversion01.exe
librfs
fstests/mrfs_fserror.exe
fstests/mrfs_fsrdwr.exe
(all fstests/mrfs_*.exe fails) * fstests/fsrofs01.exe * libtests/flashdisk01.exe
libdevnull
sptests/sp21.exe
psxtests/psxmmap01.exe
tmtests/tm20.exe
libblock
fstests/fsbdpart01.exe
Command used for configuring leon3:
../rtems/configure \\
--prefix=$HOME/development/rtems/5 \\
--target=sparc-rtems5 \\
--enable-rtemsbsp=leon3 \\
--enable-posix --enable-tests
command used for running covoar:
covoar -vvvv -S /home/lunatic/development/rtems/rtems-tools/tester/rtems/testing/coverage/leon3-qemu-symbols.ini \\
-O leon3-qemu-coverage \\
-E /home/lunatic/development/rtems/rtems-tools/tester/rtems/testing/coverage/Explanations.txt \\
-p RTEMS-5 `find . -name *.exe`
Author: Joel Sherrill
2019-03-12T18:24:40.000Z
Original author: thelunatic
Is this still an issue or did it get fixed?
Author: Trac Migrate
2019-03-12T19:41:30.000Z
Original author: thelunatic
Replying to Joel Sherrill:
Is this still an issue or did it get fixed? I just tried running (leon3 with sis and qemu) and it seems like it’s still an issue.
Author: Amar Takhar
2024-04-25T20:46:29.675Z
changed the description
Author: Amar Takhar
2024-04-26T01:34:37.201Z
mentioned in issue rtems/programs/gsoc#25
3462 - Convert covoar C code to C++ (opened)¶
Id |
3462 |
State |
opened |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Created |
2018-06-21T07:45:06.000Z |
Updated |
2025-09-19T01:45:39.370Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, scan::coverage, tickettype::defect, tool, version::5 |
Link |
|
Merges |
0 |
Some of the code in covoar is C while the program is C++. Convert the C code to C++.
Author: Trac Migrate
2018-06-21T07:57:20.000Z
In [changeset:”bf8e59f83bf8d520bd550c50f566bd8cbccdd88c/rtems-tools” bf8e59f/rtems-tools]:
covoar: Covert CoverageMapBase C to C++ Updates #3462
Author: Joel Sherrill
2018-10-13T22:46:43.000Z
Milestone changed from %”5.1” to %”Indefinite”
Author: Amar Takhar
2024-04-25T20:46:22.737Z
changed the description
Author: Amar Takhar
2024-04-26T01:34:38.140Z
mentioned in issue rtems/programs/gsoc#25
3448 - Add GCC, Binutils+GDB, Newlib mirrors to RTEMS github (opened)¶
Id |
3448 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-06-07T07:30:17.000Z |
Updated |
2025-09-19T01:45:39.283Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::task, tool, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
Sometimes it is necessary to use a snapshot of GCC, Binutils+GDB or Newlib. The snapshot archives of GCC and Binutils+GDB are only available for a certain time (e.g. half a year).
https://lists.rtems.org/pipermail/devel/2018-June/021907.html
The sourceware.org Git services do not provide snapshots.
One option would be to use github since it provides snapshots. However, no official mirrors at github exist.
Add mirrors for GCC, Binutils+GDB and Newlib to https://github.com/rtems.
Author: Trac Migrate
2018-06-11T08:31:19.000Z
Original author: sebastian.huber
Owner set to sebastian.huber
My first step is to add
repositories, starting with the master branches only.
The second step is to add a cron job to dispatch.rtems.org to synchronize the repositories once per day with the upstream repositories.
Do we want to mirror all branches of the upstream repositories?
Author: Chris Johns
2018-06-11T09:29:49.000Z
Original author: sebastian.huber
What is practical?
The servers are on a fast backbone and so I do not see a big issue here.
Author: Trac Migrate
2018-06-11T09:51:22.000Z
Original author: sebastian.huber
The least maintenance overhead has probably an automated mirroring of all branches since there are standard Git commands to do this.
Author: Trac Migrate
2018-06-11T09:56:25.000Z
Original author: sebastian.huber
How are is the Git mirroring done for the RTEMS repositories? Can we use the same Git user account for this?
Author: Gedare Bloom
2018-06-11T14:17:40.000Z
Original author: sebastian.huber
This account https://github.com/rtems-updater is used from dispatch to push commits in a git hook. I don’t know who has the rtems-updater credentials, probably Amar set it up. I would guess its private key should be on dispatch though.
Author: Chris Johns
2018-06-12T01:48:22.000Z
Original author: sebastian.huber
Can the repos please be under something like ‘misc’ or ‘gnu’ or ‘fsf’ and not at the top level.
I am concerned being at the top level will imply this is what users need to use.
Thanks
Author: Trac Migrate
2018-06-12T05:35:32.000Z
Original author: sebastian.huber
I added the repositories.
I don’t know you can add subdirectories in Github. Is this possible at all?
We could use some sort of prefix, e.g. mirror-gcc, mirror-binutils-gdb, mirror-newlib-cygwin.
Author: Trac Migrate
2018-06-12T05:37:34.000Z
Original author: sebastian.huber
The git clone –mirror checkout of the three repository need 2.5G of space on my disk. On dispatch.rtems.org we have currently:
df -h Filesystem Size Used Avail Capacity Mounted on /dev/gpt/root0 88G 80G 1.4G 98% /
Author: Chris Johns
2018-06-12T07:07:06.000Z
Original author: sebastian.huber
Replying to Sebastian Huber:
I don’t know you can add subdirectories in Github. Is this possible at all?
I thought you could but I must have not understood what I was looking at. I see there are pinned repos which might help us if we pin our ones so they are at the top.
We could use some sort of prefix, e.g. mirror-gcc, mirror-binutils-gdb, mirror-newlib-cygwin.
That is a good idea. fsf-mirror-gcc?.
Author: Chris Johns
2018-06-12T07:08:08.000Z
Original author: sebastian.huber
Replying to Sebastian Huber:
The git clone –mirror checkout of the three repository need 2.5G of space on my disk. On dispatch.rtems.org we have currently: df -h Filesystem Size Used Avail Capacity Mounted on /dev/gpt/root0 88G 80G 1.4G 98% /
What if we use the NAS under /data/ftp?
Author: Trac Migrate
2018-06-12T07:57:08.000Z
Original author: sebastian.huber
Replying to Chris Johns:
Replying to Sebastian Huber:
I don’t know you can add subdirectories in Github. Is this possible at all?
I thought you could but I must have not understood what I was looking at. I see there are pinned repos which might help us if we pin our ones so they are at the top.
I added pinned repositories.
We could use some sort of prefix, e.g. mirror-gcc, mirror-binutils-gdb, mirror-newlib-cygwin.
That is a good idea. fsf-mirror-gcc?.
What about gnu-mirror-gcc, sourceware-mirror-newlib-cygwin, and sourceware-mirror-binutils-gdb? This reflects the URL of the upstream Git repositories somehow.
Author: Chris Johns
2018-06-12T22:33:51.000Z
Original author: sebastian.huber
Replying to Sebastian Huber:
Replying to Chris Johns:
Replying to Sebastian Huber:
I don’t know you can add subdirectories in Github. Is this possible at all?
I thought you could but I must have not understood what I was looking at. I see there are pinned repos which might help us if we pin our ones so they are at the top.
I added pinned repositories.
Thanks. Looks good.
I am wondering if I change the “Kernel, networking, file-systems, drivers, BSPs, samples, and testsuite.” description on rtems to “Kernel (SMP), file-systems, drivers, BSPs, samples, and testsuite.” and libbsd to “RTEMS FreeBSD, networking, USB, and media.” ?
We could use some sort of prefix, e.g. mirror-gcc, mirror-binutils-gdb, mirror-newlib-cygwin.
That is a good idea. fsf-mirror-gcc?.
What about gnu-mirror-gcc, sourceware-mirror-newlib-cygwin, and sourceware-mirror-binutils-gdb? This reflects the URL of the upstream Git repositories somehow.
Nice. That makes sense to me.
Author: Trac Migrate
2018-06-13T05:33:44.000Z
Original author: sebastian.huber
I have now the following setup on a local machine:
git clone --mirror git://sourceware.org/git/binutils-gdb.git cd binutils-gdb git remote add github git@github.com:RTEMS/sourceware-mirror-binutils-gdb.gitgit clone --mirror git://sourceware.org/git/newlib-cygwin.git cd newlib-cygwin git remote add github git@github.com:RTEMS/sourceware-mirror-newlib-cygwin.gitgit clone --mirror git://gcc.gnu.org/git/gcc.git/git/binutils-gdb.git cd gcc git remote add github git@github.com:RTEMS/gnu-mirror-gcc.gitSynchronization is quite easy:
git fetch git push --mirror githubI will set up a cron job on my local machine for now. It runs during work days. To set it up on dispatch.rtems.org we need more disk space (I suggest 4G) and someone with enough privileges on this server.
Author: Chris Johns
2018-06-13T05:58:49.000Z
Original author: sebastian.huber
Replying to Sebastian Huber:
I will set up a cron job on my local machine for now. It runs during work days. To set it up on dispatch.rtems.org we need more disk space (I suggest 4G) and someone with enough privileges on this server.
Your local
ftpdirectory under your personal area is on the NAS and should have enough space. Note, the NAS’s FTP may not appear in thedulist.You can
chmodthe work space to stop it being scanned by search bots.
Author: Trac Migrate
2018-06-18T06:38:44.000Z
Original author: sebastian.huber
I have at least two problems to set this up on dispatch.rtems.org:
I cannot add a user cron job:
dispatch:~ # crontab -u sebh -e crontab: must be privileged to use -u dispatch:~ # sudo crontab -u sebh -e -bash: sudo: command not found
The Git mirror script forwards the request to a local server on port 8003 (/data/support/git-support/hooks/github-cmd-send.py). This server probably needs to have access to the local Git clone. I cannot set this up.
Author: Trac Migrate
2019-12-19T08:15:22.000Z
Original author: sebastian.huber
Milestone changed from %”5.1” to %”Indefinite”
Author: Joel Sherrill
2021-12-17T16:16:53.000Z
Original author: sebastian.huber
Doesn’t this work now? Sebastian/Chris would you close the ticket or clarify what remains to do?
Author: Amar Takhar
2025-09-05T02:57:39.496Z
changed the description
3441 - Add support in covoar to generate separate report for each symbol-set (opened)¶
Id |
3441 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-06-06T12:04:38.000Z |
Updated |
2025-09-19T01:45:39.193Z |
Milestone |
5.4 |
Labels |
priority::normal, scan::coverage, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: thelunatic
The covoar tool is capable of processing multiple sets from a single ini file. But it creates a single report for all the symbols/subsystems, e.g, if covoar is run for score and rtems then it will generate a single symbolSymmary.txt report. It needs to be updated to generate separate report for all the symbols.
Author: Amar Takhar
2024-04-25T20:46:20.128Z
changed the description
Author: Amar Takhar
2024-04-26T01:34:38.540Z
mentioned in issue rtems/programs/gsoc#25
3440 - Add support in tester to run coverage on supported bsp without –coverage option (opened)¶
Id |
3440 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-06-06T11:43:54.000Z |
Updated |
2025-09-19T01:45:39.102Z |
Milestone |
5.4 |
Labels |
priority::normal, scan::coverage, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: thelunatic
The tester currently needs –coverage option to run coverage for a supported bsp. This needs to be updated to run coverage without the –coverage option, whenever a supported bsp (like leon3-qemu-cov ) is used.
Author: Amar Takhar
2024-04-25T20:46:19.706Z
changed the description
3422 - Move nbench from examples-v2 to main RTEMS benchmarks (opened)¶
Id |
3422 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2018-05-01T14:09:37.000Z |
Updated |
2025-09-19T01:45:38.981Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
What’s the feeling on moving nbench from examples-v2 to testsuites/benchmarks?
Author: Chris Johns
2018-10-14T01:01:04.000Z
Milestone changed from %”5.1” to %”Indefinite”
Status changed from new to assigned
Version ~”5” deleted
Author: Gedare Bloom
2025-02-01T00:52:40.631Z
changed the description
Author: Gedare Bloom
2025-02-01T00:52:40.845Z
3400 - dl06 error for powerpc/qoriq_e6500 unknown machine type (opened)¶
Id |
3400 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2018-04-16T22:02:21.000Z |
Updated |
2025-09-19T01:45:38.881Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool, version::5 |
Link |
|
Merges |
0 |
rtems-ld -r /home/joel/rtems-work/rtems-testing/rtems/build-powerpc-qoriq_e6500_64-rtems/powerpc-rtems5/c/qoriq_e6500_64 -O rap -b dl06.pre -e rtems_main -s -o dl06.rap dl06-o1.o dl06-o2.o -lm error: machine-type: unknown machine type: 21 gmake[5]: *** [dl06.rap] Error 10
Author: Joel Sherrill
2018-04-17T13:55:09.000Z
Owner set to chrisj@rtems.org
Status changed from new to assigned
Author: Trac Migrate
2019-12-19T11:12:29.000Z
Milestone changed from %”5.1” to %”Indefinite”
Owner set to Needs Funding
Test is disabled for this BSP. It is unlikely that someone adds 64-bit PowerPC ELFv2 support to libdl.
Author: Amar Takhar
2025-09-05T03:01:11.055Z
changed the description
3399 - dl06 error for moxie unknown machine type (opened)¶
Id |
3399 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2018-04-16T22:02:18.000Z |
Updated |
2025-09-19T01:45:38.778Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool, version::5 |
Link |
|
Merges |
0 |
gmake[5]: Entering directory `/data/home/joel/rtems-work/rtems-testing/rtems/build-moxie-moxiesim-rtems/moxie-rtems5/c/moxiesim/testsuites/libtests’ rtems-ld -r /home/joel/rtems-work/rtems-testing/rtems/build-moxie-moxiesim-rtems/moxie-rtems5/c/moxiesim -O rap -b dl06.pre -e rtems_main -s -o dl06.rap dl06-o1.o dl06-o2.o -lm error: machine-type: unknown machine type: 223 gmake[5]: *** [dl06.rap] Error 10
Author: Joel Sherrill
2018-04-17T13:54:46.000Z
Owner set to chrisj@rtems.org
Status changed from new to assigned
Author: Chris Johns
2018-10-19T00:20:08.000Z
Milestone changed from %”5.1” to %”Indefinite”
Author: Amar Takhar
2025-09-05T03:01:10.839Z
changed the description
3372 - add tests for inttypes.h methods to RTEMS (opened)¶
Id |
3372 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-03-26T20:26:27.000Z |
Updated |
2025-09-19T01:45:38.665Z |
Milestone |
5.4 |
Labels |
api::posix, old-indefinite, posix::compliance, priority::low, priority::normal, rtems::score, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: salsalil
These methods are defined in the POSIX standard here: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/inttypes.h.html
This entails the following methods:
intmax_t imaxabs(intmax_t); imaxdiv_t imaxdiv(intmax_t, intmax_t); intmax_t strtoimax(const char *restrict, char **restrict, int); uintmax_t strtoumax(const char *restrict, char **restrict, int); intmax_t wcstoimax(const wchar_t *restrict, wchar_t **restrict, int); uintmax_t wcstoumax(const wchar_t *restrict, wchar_t **restrict, int);
Author: Trac Migrate
2018-03-26T22:50:21.000Z
Original author: salsalil
Version ~”5” deleted
See: http://pubs.opengroup.org/onlinepubs/007904975/basedefs/inttypes.h.html
Author: Joel Sherrill
2018-03-27T14:52:06.000Z
Original author: salsalil
Description changed
<details> <summary>Summary</summary> <pre> These methods are defined in the POSIX standard here: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/inttypes.h.html
This entails the following methods:
intmax_t imaxabs(intmax_t); imaxdiv_t imaxdiv(intmax_t, intmax_t); intmax_t strtoimax(const char restrict, char **restrict, int); uintmax_t strtoumax(const char *restrict, char **restrict, int); intmax_t wcstoimax(const wchar_t *restrict, wchar_t **restrict, int); uintmax_t wcstoumax(const wchar_t *restrict, wchar_t **restrict, int); </pre> </details> * **Priority* changed from ~”low” to ~”normal” * Summary changed from add testsuites for inttypes.h methods to RTEMS5 to add tests for inttypes.h methods to RTEMS
Author: Amar Takhar
2024-04-25T20:46:13.805Z
changed the description
3371 - Add dirfd() and fdopendir() methods in dirent.h (opened)¶
Id |
3371 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-03-26T18:49:46.000Z |
Updated |
2025-09-19T01:45:38.525Z |
Milestone |
5.4 |
Labels |
old-indefinite, posix::compliance, priority::low, rtems::score, tickettype::defect, version::5 |
Link |
|
Merges |
1 |
Original author: salsalil
When added update psxhdr section of psxtests/Makefile.am to enable the existing API Compliance tests.
Author: Trac Migrate
2018-04-14T18:52:20.000Z
Original author: salsalil
These methods are defined in the POSIX standard here: http://pubs.opengroup.org/onlinepubs/9699919799/functions/dirfd.html
Author: Joel Sherrill
2018-12-05T17:49:10.000Z
Original author: salsalil
Description changed
<details> <summary>Summary</summary> <pre> When added update psxhdr section of psxtests/Makefile.am to enable the existing API Compliance tests. </pre> </details> * Summary changed from Add dirfd() method in dirent.h to Add dirfd() and fdopendir() methods in dirent.h
Author: Trac Migrate
2018-12-05T18:01:10.000Z
Original author: salsalil
In [changeset:”9abe98b389bb29307d40697ca7a7aca15e99f328/rtems” 9abe98b3/rtems]:
testsuites/psxtests/Makefile.am: Disable psxhdrs for dirfd.c and fdopendir.c updates #3371.
Author: Amar Takhar
2024-04-25T20:46:13.303Z
changed the description
Author: Bhuvan B
2026-02-01T16:09:55.973Z
mentioned in merge request !978
3356 - Add support for CLOCK_THREAD_CPUTIME_ID (opened)¶
Id |
3356 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2018-03-19T19:23:29.000Z |
Updated |
2025-09-19T01:45:38.410Z |
Milestone |
5.4 |
Labels |
api::posix, old-indefinite, posix::compliance, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Add support for CLOCK_THREAD_CPUTIME_ID. This would impact at least clock_gettime() and clock_settime().
Author: Amar Takhar
2024-04-25T20:46:12.871Z
changed the description
3355 - RSB build error: downloading expat-2.1.0.tar.gz (opened)¶
Id |
3355 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-03-18T05:05:29.000Z |
Updated |
2025-09-19T01:45:38.317Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool::rtems-source-builder, version::5 |
Link |
|
Merges |
0 |
Original author: VidushiVashishth
On attempting to build the tool chain for the SPARC architecture the following build error is encountered: ‘’Build: error: downloading https://github.com/libexpat/libexpat/releases/download/R_2_1_0/expat-2.1.0.tar.gz: all paths have failed, giving up ‘’
Manually downloading the expat tar file to the sources folder of the rsb/rtems directory circumvents the build error.
Author: Trac Migrate
2018-03-18T05:06:54.000Z
Original author: VidushiVashishth
Attachment rsb-report-expat-2.1.0-x86_64-apple-darwin16.7.0-1.txt added
RSB error report
Author: Amar Takhar
2025-09-05T03:01:10.426Z
changed the description
3310 - zynq_uart_write_polled could produce a blocking scenario (opened)¶
Id |
3310 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-02-21T10:10:54.000Z |
Updated |
2025-09-19T01:45:38.224Z |
Milestone |
5.4 |
Labels |
arch:arm, bsp, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: fdpousa
The actual code for the zynq_uart_write_polled has a while loop inside. What could happen if a hw fault occurs? If TX buffer is always full, lower priority tasks may remain in a blocked state. The objective is to use the UART communication directly by RS232/RS422 protocol without any console.
Why is this function codified different than zynq_uart_read_polled()? With the zynq_uart_read_polled codification the blocking risks disappear if hw fails and a byte is never put in RX Buffer. I suggest to apply the same if struct to zynq_uart_write_polled.
Author: Amar Takhar
2024-04-25T20:46:01.435Z
changed the description
3282 - or1k GCC 4.9.3 and 5.3.0 do not build on FreeBSD 11 (opened)¶
Id |
3282 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-01-26T14:39:55.000Z |
Updated |
2025-09-19T01:45:38.123Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool::gcc, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
/usr/include/c++/v1/exception:167:5: error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'?
_VSTD::abort();
^~~~~~~
/usr/include/c++/v1/__config:390:15: note: expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
^
11 warning../../gcc-4.9.3/gcc/system.h:685s generated.
:13: note: 'fancy_abort' declared here
extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN;
Author: Amar Takhar
2025-09-05T03:01:09.719Z
changed the description
3276 - rtems-test: Add option to consume a log file and generate a report for it (opened)¶
Id |
3276 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Chris Johns |
Created |
2018-01-22T06:39:52.000Z |
Updated |
2025-09-19T01:45:37.999Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::enhancement, tool, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The RTEMS Tester works quite well if it can run the tests step by step. I have a board were I can run reliably all tests at once with a custom script. I cannot run tests individually due to an instability in the debug support. This produces a large text file with the test output of all tests.
It would be nice to have an option to simply feed this file to the rtems-test program and generate the report (optionally send it via e-mail).
Author: Trac Migrate
2018-01-22T06:42:21.000Z
Original author: sebastian.huber
Example log file.
Author: Chris Johns
2018-10-19T00:26:55.000Z
Original author: sebastian.huber
Milestone changed from %”5.1” to %”Indefinite”
Version ~”5” deleted
Author: Chris Johns
2020-09-08T07:19:24.000Z
Original author: sebastian.huber
I am wondering if the lines in the log should have a timestamp prefixed to them.
Are there any requirements for the test harness obtaining the log? For example timeouts, crash recovery and tests running too long?
Author: Amar Takhar
2025-09-05T02:57:38.924Z
changed the description
3252 - Add PowerPC support for libdebugger (opened)¶
Id |
3252 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-11-22T08:43:04.000Z |
Updated |
2025-09-19T01:45:37.886Z |
Milestone |
5.4 |
Labels |
library, old-indefinite, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
Author: Amar Takhar
2025-09-05T03:01:09.278Z
changed the description
3241 - RSB sporadically fails when fetching rtems-tools (opened)¶
Id |
3241 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-11-20T11:03:40.000Z |
Updated |
2025-09-19T01:45:37.767Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::low, priority::normal, tickettype::enhancement, tool::rtems-source-builder, version::5 |
Link |
|
Merges |
0 |
Original author: Christian Mauderer
Sporadically the rtems source builder fails with a error message like the following:
...
package: rtems-tools-HEAD-1
git: reset: git://git.rtems.org/rtems-tools.git
git: fetch: git://git.rtems.org/rtems-tools.git -> sources/git/rtems-tools.git
error: git command failed (/usr/bin/git): 128
Build FAILED
See error report: rsb-report-rtems-tools-HEAD-1.txt
error: git command failed (/usr/bin/git): 128
Build Set: Time 0:28:42.787936
Build FAILED
The error report in rsb-report-rtems-tools-HEAD-1.txt isn’t really useful in that case:
...
script: 81: build_top=$(pwd)
script: 82: rtems_tools_source="rtems-tools.git"
script: 83: source_dir_rtems_tools=${rtems_tools_source}
source setup: rtems-tools-HEAD-1: source rtems-tools -q -n ${rtems_tools_source}
making dir: /home/EB/christian_m/Projekte/grisp-software/rtems-source-builder/rtems/sources/git
git: reset: git://git.rtems.org/rtems-tools.git
git: fetch: git://git.rtems.org/rtems-tools.git -> sources/git/rtems-tools.git
error: git command failed (/usr/bin/git): 128
I assume that the git fetch went wrong for some reason. That’s really annoying because it happens after the quite time consuming build of gcc.
Please correct me if I’m wrong but as far as I know, a download in advance wouldn’t do this git command. Therefore this bug can’t be triggered before the build.
I’m not that familiar with that step of the RSB but would it be possible to to download a tar.bz2-snapshot of the correct commit from our git server instead of doing a git clone? The git web interface shows a URL like the following for every commit: https://git.rtems.org/rtems-tools/snapshot/rtems-tools-9f34b38edf2a235e8d41c3265b146b0b1a4da252.tar.bz2
With that it would be possible to do all downloads in advance and then do the build without the risk that some download goes wrong during the build.
Author: Trac Migrate
2018-04-17T07:59:22.000Z
Original author: Christian Mauderer
Milestone changed from %”Indefinite” to %”5.1”
Owner set to sebastian.huber
Priority changed from ~”low” to ~”normal”
Status changed from new to assigned
An additional problem is that the unspecified RTEMS tools version makes the RSB tool set not reproducable (RTEMS tools version is build time dependent).
Author: Chris Johns
2018-04-17T10:24:46.000Z
Original author: Christian Mauderer
Replying to Sebastian Huber:
An additional problem is that the unspecified RTEMS tools version makes the RSB tool set not reproducable (RTEMS tools version is build time dependent).
Is this to support a bisect?
I always intended to have the RSB be part of the RTEMS Tools repo however it is a lot of work for me to merge the changes in the RSB config and some other parts into the rtemstoolkit version of the modules. Another issue is all the related documentation and work flows that now exist. It is just something that got away on me and I am sorry for that.
Author: Trac Migrate
2018-04-17T11:29:08.000Z
Original author: Christian Mauderer
Replying to Chris Johns:
Replying to Sebastian Huber:
An additional problem is that the unspecified RTEMS tools version makes the RSB tool set not reproducable (RTEMS tools version is build time dependent).
Is this to support a bisect?
Yes, this is one use case.
I always intended to have the RSB be part of the RTEMS Tools repo however it is a lot of work for me to merge the changes in the RSB config and some other parts into the rtemstoolkit version of the modules. Another issue is all the related documentation and work flows that now exist. It is just something that got away on me and I am sorry for that.
I think we just have to treat the RTEMS tools like Newlib and GCC. We should specify the version explicitly.
Author: Chris Johns
2018-04-18T01:43:38.000Z
Original author: Christian Mauderer
Replying to Sebastian Huber:
Replying to Chris Johns:
Replying to Sebastian Huber:
An additional problem is that the unspecified RTEMS tools version makes the RSB tool set not reproducable (RTEMS tools version is build time dependent).
Is this to support a bisect?
Yes, this is one use case.
As pointed out on the devel list newlib breaks bisecting now.
The ticket is about a git issue which is valid and stopping
rtems-toolsbeing fetched by git does not fix that issue, it just hides it. I welcome any patches related to fixing this git issue.
Author: Trac Migrate
2018-04-18T05:12:08.000Z
Original author: Christian Mauderer
Replying to Chris Johns:
Replying to Sebastian Huber:
Replying to Chris Johns:
Replying to Sebastian Huber:
An additional problem is that the unspecified RTEMS tools version makes the RSB tool set not reproducable (RTEMS tools version is build time dependent).
Is this to support a bisect?
Yes, this is one use case.
As pointed out on the devel list newlib breaks bisecting now.
A Newlib version update doesn’t break the bisecting.
The ticket is about a git issue which is valid and stopping
rtems-toolsbeing fetched by git does not fix that issue, it just hides it. I welcome any patches related to fixing this git issue.Yes, sorry. I should have opened a new bug.
Author: Trac Migrate
2018-04-18T05:12:44.000Z
Original author: Christian Mauderer
Milestone changed from %”5.1” to %”Indefinite”
Status changed from assigned to new
Version ~”5” deleted
Author: Amar Takhar
2025-09-05T03:01:08.852Z
changed the description
3233 - Documentation has a number of warning that need fixing. (opened)¶
Id |
3233 |
State |
opened |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Trac Migrate |
Created |
2017-11-13T00:47:58.000Z |
Updated |
2025-09-19T01:45:37.642Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Adding --sphinx-verbose="-v" to the configure command line will produce a range of warnings. These should be reviewed and is possible and easy they should be fixed.
Author: Chris Johns
2018-10-14T01:03:55.000Z
Milestone changed from %”5.1” to %”Indefinite”
Version ~”5” deleted
Author: Amar Takhar
2025-09-05T03:01:08.622Z
changed the description
3214 - non-blocking termios interface (opened)¶
Id |
3214 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-10-31T22:09:23.000Z |
Updated |
2025-09-19T01:45:37.416Z |
Milestone |
5.4 |
Labels |
priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: stavros.passas
We face some issues with TERMIOS, when used on slow UART devices when running on RTEMS master. This was not happening before the last big refactoring of TERMIOS.
Even when the tty is blocking, rtems_termios_write_tty function is calling doTransmit with
wait = true
nextWait = false.
However in doTransmit, wait is over-written with nextWait at the end of each loop, so after one loop wait becomes false regardless if a write is blocking or non-blocking, and the function may return before writing all the characters.
I think what it is intended to be done there is to do wait |= nextWait, so if wait is already true, it remains true for the entire function.
Author: Trac Migrate
2017-10-31T22:19:54.000Z
Original author: stavros.passas
Attachment 3214-Fix-termios-blocking-interface.patch added
proposed fix
Author: Trac Migrate
2017-10-31T22:20:19.000Z
Original author: stavros.passas
proposed fix attached.
Author: Trac Migrate
2017-11-02T10:16:19.000Z
Original author: stavros.passas
Cc added @sebastian.huber, @peerst
We implemented this behaviour for the select() support. In case select() indicates a ready write to a Termios file descriptor, then it is guaranteed that we can transmit at least one character. You can use a loop around write() to transfer everything in on rush.
Author: Trac Migrate
2017-11-02T11:37:30.000Z
Original author: stavros.passas
You are right. I was hoping there is a way to differentiate between select(), and blocking and non-blocking write() calls. This way we break existing applications, even thought I guess we can easily port them.
Author: Trac Migrate
2017-11-02T11:47:37.000Z
Original author: stavros.passas
Do these applications run on FreeBSD or Linux?
Author: Trac Migrate
2017-11-02T20:11:44.000Z
Original author: stavros.passas
RTEMS applications.
Author: Chris Johns
2025-09-19T01:45:37.508Z
changed the description
3208 - Update the RTEMS Porting Guide (opened)¶
Id |
3208 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-10-25T12:58:50.000Z |
Updated |
2025-09-19T01:45:37.315Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The _RTEMS Porting Guide_ is out of date and in its current state not helpful to ease the porting of RTEMS to a new architecture. Perform the following steps:
Enable build of the _RTEMS Porting Guide_.
Disable existing content and start with a nearly empty document.
One step of the porting is the update of the _RTEMS CPU Architecture Supplement_. Mentions this in the guild and move the _PORT SPECIFIC INFORMATION_ chapter to the guide.
Remove the _no_cpu_ directories form the RTEMS sources and transfer the content to the guide. Mention useful example implementations.
Author: Amar Takhar
2025-09-05T03:01:08.392Z
changed the description
3206 - BSPs Wiki Page is Out of Date (opened)¶
Id |
3206 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2017-10-25T12:47:22.000Z |
Updated |
2025-09-19T01:45:37.209Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
https://devel.rtems.org/wiki/TBR/Website/Board_Support_Packages is linked to from the top of the Wiki and horribly out of date.
I am not sure what to do about this page. We need a master list of BSPs somewhere. It could be updated or we have to find a way to generate an equivalent page. Given this has some historical information, automatically generating it seems hard.
Author: Chris Johns
2017-10-25T22:21:24.000Z
Release README.txt files contain a list of BSPs in that release (scroll down). It is generated automatically using the
rtems-bspscript when the release is created.The current definitive BSP definition is the
rtems-bspwhich learns from the source tree and:https://git.rtems.org/rtems-tools/tree/tester/rtems/rtems-bsps.ini
For me a BSP only formally exists if it is in the INI files under the
rtems-tester.A list of BSPs is nice, a list based on the Tier structure would be nicer and a list based on the Tier structure with valid test results even better.
My hope is users of RTEMS will put pressure on those providing services to them to get their architecture and BSP moved up the tier ranks by publishing test results on
build@rtems.org.There is also Amar’s django website that has support for managing BSPs however that effort needs work to straighten out some schema issues on the relationship of arch, processors and BSP that resulted from Amar and I talking at cross purposes. I am not sure what is involved and how much work is required to make this production quality. I am also not sure how we maintain this data long term if this database become active.
Author: Joel Sherrill
2017-10-25T22:25:13.000Z
I would be happy to see that page link to a list of BSPs generated for each branch. Not have the table itself.
But every time we branch, we have to add a link. I was hoping to find something that would stay accurate on its own. Generated from code. Perhaps part of the release process to have a file in the release directory? We could back populate that file and link to those.
We don’t have tiers for anything beyond the next release. Could we run the script for 4.10 and 4.11 and link to that? From where to where?
Author: Chris Johns
2017-10-25T22:32:42.000Z
Replying to Joel Sherrill:
We don’t have tiers for anything beyond the next release. Could we run the script for 4.10 and 4.11 and link to that? From where to where?
You could
./rtems-bsp > rtems-4.11.2.txtfor the4.11releases and I can update the release procedure to do this automatically and have theREADME.txtlink to it.For
4.10I suggest you copy thertems-bspto the source tree and run it. In theory you should be able to do this on a number of the older releases.Your
sh_foo_ is better than mine so a compact list of archs before the BSP list might be a nice addition :)
Author: Trac Migrate
2017-10-26T05:40:39.000Z
I would move this information together with the BSP READMEs to the RTEMS CPU Architecture Supplement. Then I would delete this wiki page.
Author: Trac Migrate
2017-11-09T06:27:14.000Z
Milestone changed from %”4.12.0” to %”5.1”
Milestone renamed
Author: Chris Johns
2018-10-14T00:59:03.000Z
Milestone changed from %”5.1” to %”Indefinite”
Status changed from new to assigned
Version ~”5” deleted
This would make a good set of GCI tasks.
What happens to BSPs in old releases?
Author: Amar Takhar
2025-09-05T03:01:08.179Z
changed the description
3186 - rtems_print_buffer() should follow rtems_printer pattern (opened)¶
Id |
3186 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2017-10-12T16:58:19.000Z |
Updated |
2025-09-19T01:45:37.109Z |
Milestone |
5.4 |
Labels |
library, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
The rtems_print_buffer() method always uses printk(). It should be changed to use the rtems_printer pattern like cpuuse reports.
Documentation will need to be updated as this changes the API and adds at least one method.
Author: Joel Sherrill
2017-10-12T16:59:11.000Z
Description changed
- The rtems_print_buffer() method always uses printk(). It should be changed to use the rtems_printer pattern like cpuuse reports. + The `rtems_print_buffer()` method always uses `printk()`. It should be changed to use the rtems_printer pattern like cpuuse reports. ? + + + + Documentation will need to be updated as this changes the API and adds at least one method.
Author: Amar Takhar
2025-09-05T03:01:06.566Z
changed the description
3156 - rtems-fdt probably not supported on 64-bit PowerPC (opened)¶
Id |
3156 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Chris Johns |
Created |
2017-09-29T05:06:58.000Z |
Updated |
2025-09-19T01:45:37.002Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, rtems::score, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The following warnings indicate that there are some problems on 64-bit PowerPC:
cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:488:11: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'long int' [-Wformat=]
cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:536:13: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'long int' [-Wformat=]
cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:57:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:64:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Author: Trac Migrate
2017-10-06T11:39:31.000Z
Original author: sebastian.huber
Owner set to @chrisj
Status changed from new to assigned
I don’t know the code good enough to fix the warning/bug.
Author: Amar Takhar
2024-04-25T20:48:22.020Z
mentioned in issue #4150
Author: Amar Takhar
2025-09-05T02:57:04.794Z
changed the description
3155 - libdl not supported on 64-bit PowerPC (opened)¶
Id |
3155 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-09-29T05:05:21.000Z |
Updated |
2025-09-19T01:45:36.896Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, rtems::score, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
There are several warnings:
cpukit/libdl/rtl-elf.c:253:46: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'Elf32_Word {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-elf.c:253:64: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type 'Elf32_Word {aka const unsigned int}' [-Wformat=]
cpukit/libdl/rtl-elf.c:263:45: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'Elf32_Word {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-elf.c:263:63: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type 'Elf32_Word {aka const unsigned int}' [-Wformat=]
cpukit/libdl/rtl-elf.c:307:54: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'Elf32_Word {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-elf.c:320:49: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'Elf32_Word {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-elf.c:87:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cpukit/libdl/rtl-elf.c:98:28: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cpukit/libdl/rtl-mdreloc-powerpc.c:104:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
cpukit/libdl/rtl-mdreloc-powerpc.c:114:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
cpukit/libdl/rtl-mdreloc-powerpc.c:123:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
cpukit/libdl/rtl-mdreloc-powerpc.c:143:48: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cpukit/libdl/rtl-mdreloc-powerpc.c:152:43: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cpukit/libdl/rtl-mdreloc-powerpc.c:156:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
cpukit/libdl/rtl-mdreloc-powerpc.c:163:44: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cpukit/libdl/rtl-mdreloc-powerpc.c:166:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
cpukit/libdl/rtl-mdreloc-powerpc.c:177:43: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cpukit/libdl/rtl-mdreloc-powerpc.c:186:44: warning: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'Elf32_Word {aka const unsigned int}' [-Wformat=]
cpukit/libdl/rtl-mdreloc-powerpc.c:186:56: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'unsigned int' [-Wformat=]
cpukit/libdl/rtl-mdreloc-powerpc.c:189:15: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
cpukit/libdl/rtl-mdreloc-powerpc.c:189:39: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
cpukit/libdl/rtl-mdreloc-powerpc.c:191:63: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'unsigned int' [-Wformat=]
cpukit/libdl/rtl-mdreloc-powerpc.c:63:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
cpukit/libdl/rtl-mdreloc-powerpc.c:92:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
cpukit/libdl/rtl-obj.c:782:61: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-obj.c:782:67: warning: format '%lu' expects argument of type 'long unsigned int', but argument 7 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:214:35: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:269:49: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:318:33: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:318:44: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:318:55: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:334:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cpukit/libdl/rtl-rap.c:374:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cpukit/libdl/rtl-rap.c:389:19: warning: format '%lu' expects argument of type 'long unsigned int', but argument 7 has type 'Elf32_Word {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:389:19: warning: format '%lx' expects argument of type 'long unsigned int', but argument 8 has type 'Elf32_Word {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:389:48: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:409:19: warning: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'Elf32_Word {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:409:19: warning: format '%lx' expects argument of type 'long unsigned int', but argument 7 has type 'Elf32_Word {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:409:47: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:614:42: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:614:55: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:614:69: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:643:64: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:819:40: warning: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:826:38: warning: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:838:35: warning: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:850:32: warning: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:867:39: warning: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:888:39: warning: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:888:44: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:888:56: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:888:67: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:916:45: warning: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:946:37: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:946:47: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:968:40: warning: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-rap.c:975:39: warning: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'uint32_t {aka unsigned int}' [-Wformat=]
cpukit/libdl/rtl-shell.c:217:34: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'uint32_t {aka unsigned int}' [-Wformat=]
Due to vast ABI differences between 32-bit and 64-bit PowerPC it is unlikely that libdl is supported on PowerPC.
Author: Chris Johns
2017-10-03T04:57:06.000Z
Original author: sebastian.huber
Replying to Sebastian Huber:
Due to vast ABI differences between 32-bit and 64-bit PowerPC it is unlikely that libdl is supported on PowerPC.
Do you mean PowerPC 64bit or any PowerPC?
What do you propose?
Author: Trac Migrate
2017-10-03T06:13:50.000Z
Original author: sebastian.huber
Replying to Chris Johns:
Replying to Sebastian Huber:
Due to vast ABI differences between 32-bit and 64-bit PowerPC it is unlikely that libdl is supported on PowerPC.
Do you mean PowerPC 64bit or any PowerPC?
64-bit PowerPC.
What do you propose?
We can probably fix the warnings with a small amount of work, however, a real 64-bit support is probably some more work.
Author: Chris Johns
2017-10-03T23:10:57.000Z
Original author: sebastian.huber
Replying to Sebastian Huber:
Replying to Chris Johns:
What do you propose?
We can probably fix the warnings with a small amount of work, however, a real 64-bit support is probably some more work.
Fixing the warning is a good idea. Yes there are some spots that need to be fixed. The host side for 64bit and 32bit support needs some changes and the RAP format would need some work.
Author: Trac Migrate
2017-10-06T07:14:43.000Z
Original author: sebastian.huber
I guess this prototype is wrong
bool rtems_rtl_elf_find_symbol (rtems_rtl_obj_t* obj, const Elf_Sym* sym, const char* symname, Elf_Word* value)It should probably be Elf_Addr *value.
Author: Trac Migrate
2017-10-06T10:47:07.000Z
Original author: sebastian.huber
In [changeset:”4e38aed00588b77fd326854d78889447e7120e86/rtems” 4e38aed/rtems]:
libdl: Use 64-bit ELF on 64-bit targets Update #3155.
Author: Trac Migrate
2017-10-06T10:47:19.000Z
Original author: sebastian.huber
In [changeset:”8bdbefedd526763cdf0d8a6f30d22919a4096258/rtems” 8bdbefe/rtems]:
libdl: Fix warnings Update #3155.
Author: Chris Johns
2017-10-07T00:07:22.000Z
Original author: sebastian.huber
Replying to Sebastian Huber:
I guess this prototype is wrong {{{ bool rtems_rtl_elf_find_symbol (rtems_rtl_obj_t* obj, const Elf_Sym* sym, const char* symname, Elf_Word* value) }}} It should probably be Elf_Addr *value.
Yes I agree. Once you highlight this is makes perfect sense. Thank you for taking the time to fix these issues.
Author: Amar Takhar
2025-09-05T03:02:40.099Z
changed the description
3154 - Add recovery support for I2C bus (opened)¶
Id |
3154 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-09-28T09:02:44.000Z |
Updated |
2025-09-19T01:45:36.780Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, rtems::score, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
FreeBSD has a recovery support for the I2C bus. Port this to RTEMS and use it in the I2C bus drivers.
https://svnweb.freebsd.org/base/head/sys/dev/iicbus/iic_recover_bus.c?view=markup
Author: Chris Johns
2017-10-03T05:26:12.000Z
Original author: sebastian.huber
Looks good. I am not sure how this could be down with the Xilinx I2C controller.
How or when is this invoked?
Author: Trac Migrate
2017-10-03T06:18:48.000Z
Original author: sebastian.huber
Its invoked by the bus driver in case of timeouts or after arbitration problems. You need control over the lines via GPIO.
I have no plans to implement this now, but it might be useful for some applications.
Author: Amar Takhar
2025-09-05T03:02:39.833Z
changed the description
3151 - Should Tests Be Added to .tcfg file Which Only Fail to Link with RTEMS Debug is Enabled? (opened)¶
Id |
3151 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2017-09-21T23:34:50.000Z |
Updated |
2025-09-19T01:45:36.573Z |
Milestone |
5.4 |
Labels |
priority::normal, rtems::testing, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
A recent build sweep with RTEMS debug enabled shows a number of BSPs which fail to build all tests which do when RTEMS debug is disabled. The stance by the RTEMS Project to these failures needs to be formally decided. I see a few options:
Do nothing
Add them to .tcfg
Add a special mode for “fails in debug mode” to .tcfg
I hate to see us with BSPs not building. This is just a bad thing to do.
I hate to add them to .tcfg when they do link in normal build mode since this would reduce testing.
The third option is the best but it would require adding another keyword to the .tcfg syntax and require modifying the processing of those files. But it seems like the best option.
Comments welcomed.
Author: Joel Sherrill
2017-09-21T23:35:56.000Z
Summary changed from Shuold Tests Be Added to .tcfg file Which Only Fail to Link with RTEMS Debug is Enabled? to Should Tests Be Added to .tcfg file Which Only Fail to Link with RTEMS Debug is Enabled?
Author: Chris Johns
2017-09-22T00:15:53.000Z
It would mean some attribute, tag or grouping would need to be added to the
.tcfgfiles. The.tcfgprocessing is now in Python so this makes that side of things easier to implement. I suggest we add groupings. For example:[default] exclude: fileio exclude: cdtest exclude: iostream exclude: flashdisk01 [debug] exclude: jffs2_fspermission exclude: jffs2_fsrdwr [smp] exclude: pppd [smp-debug] exclude: utf8proc01There are some issues we need to decide on or solve:
Which build options do we create variants for? We should formalize these.
2. How would combinations of variant options be handled? For example is a test in the
debuggroup not built for any //debug// variant such assmp-debug? 2. How do we perform themakelevel processing in testsuites/automake/subdirs.am to create a suitable list of variants?
Author: Chris Johns
2017-09-22T00:18:26.000Z
I should also point out the
rtems-bsp-builderhas a concept of //variants// here https://git.rtems.org/rtems-tools/tree/tester/rtems/rtems-bsps.ini#n138.
Author: Chris Johns
2025-09-19T01:45:36.649Z
changed the description
3150 - SP 51 Test failure on Beaglebone Black (opened)¶
Id |
3150 |
State |
opened |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Trac Migrate |
Created |
2017-09-21T07:30:17.000Z |
Updated |
2025-09-19T01:45:36.430Z |
Milestone |
5.4 |
Labels |
bsp:beaglebone, old-indefinite, priority::normal, rtems::score, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Running rtems-test with a recent u-boot and a current master this failure is reported:
] RTEMS Beagleboard: am335x-based
]
]
] *** BEGIN OF TEST SP 51 ***
] Create semaphore - priority ceiling unlocked - invalid ceiling
] Create semaphore - priority ceiling locked - violate ceiling
] Create semaphore - priority ceiling unlocked
] Obtain semaphore -- violate ceiling
] Release semaphore we did not obtain
] /opt/work/chris/rtems/kernel/rtems.git/c/src/../../testsuites/sptests/sp51/init.c: 41 sc == RTEMS_SUCCESSFUL
Author: Amar Takhar
2024-04-25T20:45:51.497Z
changed the description
3149 - SP 37 Test failure on Beaglebone Black (opened)¶
Id |
3149 |
State |
opened |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Trac Migrate |
Created |
2017-09-21T07:26:18.000Z |
Updated |
2025-09-19T01:45:36.299Z |
Milestone |
5.4 |
Labels |
bsp:beaglebone, old-indefinite, priority::normal, rtems::score, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Running rtems-test with a recent u-boot and a current master this failure is reported:
] RTEMS Beagleboard: am335x-based
]
]
] *** BEGIN OF TEST SP 37 ***
] clock_tick from task level
] Blocking task... suspending self
] clock_tick from task level with preempt -- OK
] interrupt is in progress (use body)
] interrupt disable (use inline)
] interrupt flash (use inline)
] interrupt enable (use inline)
] interrupt level mode (use inline)
] test case working..
] interrupt disable (use body)
then a reset.
Author: Joel Sherrill
2017-09-21T15:35:44.000Z
Works on erc32 and psim Fails on jmr3904 and xilinx_zynq_a9_qemu
The two failures are difference. On the MIPS, the issue is that _ISR_Get_level() is not returning the value that was set immediately above. I am guessing that the _ISR_Set_level() for the mips and arm ports translates the requested level into a register setting and then doesn’t reverse the translation on the _ISR_Get_level().
The code in question is around line 130 with a printf() added to show the value:
ISR_Level current = 0; ISR_Level last_proper_level;
_ISR_Set_level( current ); printf( “_ISR_Get_Level()=0x%08x current=0x%08xn”, _ISR_Get_level(), current ); rtems_test_assert( _ISR_Get_level() == current );
jmr3904 output
** BEGIN OF TEST SP 37 *** _ISR_Get_Level()=0x0000007f current=0x00000000 ../../../../../../../rtems/c/src/../../testsuites/sptests/sp37/init.c: 133 _ISR_Get_level() == current
On the ARM, it is failing calling the body version of rtems_interrupt_disable() in rtems/src/intr.c. No obvious failure looking at the code.
Author: Amar Takhar
2024-04-25T20:45:51.058Z
changed the description
3147 - DEBUGGER01 Test failure on Beaglebone Black (opened)¶
Id |
3147 |
State |
opened |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Created |
2017-09-21T06:23:31.000Z |
Updated |
2025-09-19T01:45:36.148Z |
Milestone |
5.4 |
Labels |
bsp:beaglebone, old-indefinite, priority::normal, rtems::score, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Running rtems-test with a recent u-boot and a current master this failure is reported:
] RTEMS Beagleboard: am335x-based
]
]
] *** BEGIN OF TEST DEBUGGER01 ***
] error: rtems-db: remote not found: test
] [CPU:0] error: rtems-db: test remote: begin
] [CPU:0] rtems-db: remote-debug is on
] [CPU:0] rtems-db: remote running
] [CPU:0] rtems-db: test remote: isconnected: not-connected
] [CPU:0] error: rtems-db: test remote: connect
] [CPU:0] rtems-db: remote running
] [CPU:0] rtems-db: arm debug: (v4.2) ARMv7 [v7, baseline CP14 registers] breakpoints:5 watchpoints:1
]
] R0 = 0x0000005C R8 = 0x00000000
] R1 = 0x00000000 R9 = 0x00000000
] R2 = 0x00000003 R10 = 0x00000000
] R3 = 0x03078002 R11 = 0x80103778
] R4 = 0x801029A8 R12 = 0x801029AC
] R5 = 0x00000002 SP = 0x8010CC90
] R6 = 0x80114950 LR = 0x80015388
] R7 = 0x00000000 PC = 0x800153CC
] CPSR = 0x20000113 VEC = 0x00000001
Author: Joel Sherrill
2017-09-21T15:38:13.000Z
This is not reported as a failure on erc32, jmr3904, psim, and xilinx_zynq_a9_qemu.
Author: Chris Johns
2017-09-21T23:32:50.000Z
Replying to Joel Sherrill:
This is not reported as a failure on erc32, jmr3904, psim, and xilinx_zynq_a9_qemu.
I suspect it is specific to the ARM on the BBB. I will take care of this one.
Author: Amar Takhar
2024-04-25T20:45:50.169Z
changed the description
3146 - FSJFFS2GC Test failure on Beaglebone Black (opened)¶
Id |
3146 |
State |
opened |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Trac Migrate |
Created |
2017-09-21T06:19:05.000Z |
Updated |
2025-09-19T01:45:35.990Z |
Milestone |
5.4 |
Labels |
bsp:beaglebone, filesystem, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Running rtems-test with a recent u-boot and a current master this failure is reported:
] RTEMS Beagleboard: am335x-based
]
]
] *** BEGIN OF TEST FSJFFS2GC 1 ***
] Initializing filesystem JFFS2
] /opt/work/chris/rtems/kernel/rtems.git/c/src/../../testsuites/fstests/fsjffs2gc01/init.c: 284 memcmp(&info, &info_after_first_gc, sizeof(*&info)) == 0
Author: Joel Sherrill
2017-09-21T15:36:57.000Z
This works on erc32, jmr3904, psim, and xilinx_zynq_a9_qemu.
Author: Amar Takhar
2024-04-25T20:45:49.662Z
changed the description
3131 - Move more implementation details of mmap() to the file handlers (opened)¶
Id |
3131 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-09-12T06:20:24.000Z |
Updated |
2025-09-19T01:45:35.833Z |
Milestone |
5.4 |
Labels |
filesystem, old-indefinite, priority::normal, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The mmap() implementation contains too many conditionals. It doesn’t follow the object oriented design of the file system layer. The mmap() is basically a factory. The mmap_h handler should construct a mapping object. A destructor is currently missing. Maybe the mmap_h handler should use a flag to deal with construction and destruction.
As a first step, pass the flags to the mmap_h handler and add a special flag to indicate an unmap. Use it in unmap() to destroy the mapping.
#define RTEMS_FILESYSTEM_MAP_UNMAP 0x8000
Add a static assert to ensure that RTEMS_FILESYSTEM_MAP_UNMAP is distinct to all other MAP flags used by RTEMS.
Author: Amar Takhar
2025-09-05T03:02:39.631Z
changed the description
3118 - fdt-shell uses char as index, gets warnings (opened)¶
Id |
3118 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Chris Johns |
Created |
2017-08-27T16:07:24.000Z |
Updated |
2025-09-19T01:45:35.554Z |
Milestone |
5.4 |
Labels |
priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
The comments in ctype.h indicate that the argument to methods like isdigit(0 should be an integer containing a char. These warnings indicate that a char is directly being passed. This warning is only showing up on the or1k and epiphany but both have the current newlib.
warnings/warnings-4.12-master-20170827a/warnings-all-4.12-master-20170827a.txt:log/or1k-generic_or1k.log:../../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:341:3: warning: array subscript has type ‘char’ [-Wchar-subscripts] warnings/warnings-4.12-master-20170827a/warnings-all-4.12-master-20170827a.txt:log/or1k-generic_or1k.log:../../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:383:3: warning: array subscript has type ‘char’ [-Wchar-subscripts] warnings/warnings-4.12-master-20170827a/warnings-all-4.12-master-20170827a.txt:log/or1k-generic_or1k.log:../../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:429:3: warning: array subscript has type ‘char’ [-Wchar-subscripts] warnings/warnings-4.12-master-20170827a/warnings-all-4.12-master-20170827a.txt:log/or1k-generic_or1k.log:../../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:476:3: warning: array subscript has type ‘char’ [-Wchar-subscripts]
Author: Joel Sherrill
2017-08-27T16:07:38.000Z
Owner set to @chrisj
Status changed from new to assigned
Author: Chris Johns
2025-09-19T01:45:35.680Z
changed the description
3110 - libbsd: openssl contains architecture-specific files (opened)¶
Id |
3110 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-08-23T08:52:22.000Z |
Updated |
2025-09-19T01:45:35.444Z |
Milestone |
5.4 |
Labels |
libbsd, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The following files are ARM-specific:
freebsd/crypto/openssl/crypto/arm_arch.h
freebsd/crypto/openssl/crypto/armcap.c
Are this the only architecture-specific files? Do they work on RTEMS? How to test this?
Author: Trac Migrate
2017-08-23T08:55:20.000Z
Original author: sebastian.huber
In [changeset:”885ac75710f810ea766491304b2c511816c26479/rtems-libbsd” 885ac75/rtems-libbsd]:
openssl: Workaround for ARM-specific files Update #3110.
Author: Amar Takhar
2025-09-05T03:02:39.429Z
changed the description
3106 - Rate monotonic and timer delete broken in SMP configurations (opened)¶
Id |
3106 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-08-22T15:28:06.000Z |
Updated |
2025-09-19T01:45:35.339Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, smp, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
In case a rate monotonic or timer object is deleted and the corresponding timer handler executes currently on another processor, then this may lead to a use after free condition. This could lead to a corrupt watchdog handler state with unpredictable effects.
Author: Amar Takhar
2025-09-05T03:01:05.956Z
changed the description
3081 - gcc 7.1 fails to build in TrueOS (aka FreeBSD 12-CURRENT #66 git ac2f0aa3b) (opened)¶
Id |
3081 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-07-21T15:34:17.000Z |
Updated |
2025-09-19T01:45:35.234Z |
Milestone |
5.4 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool::gcc, version::5 |
Link |
|
Merges |
0 |
Original author: dinsdale
The RTEMS source build fails when run on FBSD 12-CURRENT as of July 17. I cannot seem to provide more resolution in the build number as this is rolling release TrueOS (I’ll work on that).
gcc 7.1 fails to build when running 12-CURRENT kernel and userland. The issue is in the file options.h (I THINK the file is ./rsb/rtems/build/sparc-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170623-x86_64-freebsd12.0-1/build/gcc/options.h). An example of the issue is (full report attached):
./options.h:5541:3: error: redefinition of enumerator ‘OPT_d’ OPT_d = 123, /* -d / ^ ./options.h:5539:3: note: previous definition is here OPT_d = 121, / -d */ ^
When run in a jail of 11.0-RELEASE on 12-CURRENT host, the build still thinks it’s in 12 (pulls info from kernel) but builds SUCCESSFULLY.
Author: Trac Migrate
2017-07-21T15:35:33.000Z
Original author: dinsdale
Attachment options.h added
options.h file from FAILED build
Author: Trac Migrate
2017-07-21T15:37:11.000Z
Original author: dinsdale
Attachment rsb-report-sparc-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170623-x86_64-freebsd12.0-1.txt added
rsb report from failed build of gcc 7.1 on FreeBSD 12-CURRENT
Author: Trac Migrate
2017-07-23T21:24:58.000Z
Original author: dinsdale
I thought I had added this comment already, but I don’t see it. There was some resolution to this issue on the FreeBSD forum:
https://forums.freebsd.org/threads/54172/
I tried setenv LC_COLLATE C …
and tried sudo env LC_COLLATE=”C” …
both with the same failed result as building without attempting to set this.
Not sure where to go with this issue. It seems to have “suddenly appeared” in my 11-release jail that I had thought previously worked.
Author: Amar Takhar
2024-04-25T20:45:46.555Z
changed the description
3078 - Section 5.1. Prefixes is difficult to interpret (opened)¶
Id |
3078 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-07-19T05:54:00.000Z |
Updated |
2025-09-19T01:45:35.131Z |
Milestone |
5.4 |
Labels |
doc, old-indefinite, priority::low, tickettype::enhancement, version::5 |
Link |
|
Merges |
0 |
Original author: dinsdale
Hi, I’m going through the documentation and trying to build rtems. I’m having difficulty understanding the section on Prefixes. Chris Johns created a follow up email to my questions on the mailing list which clarifies why that section is difficult to document. Upon retrospect with his explanation in mind, the section makes sense???
I’m going to read it again tomorrow morning. However, my feeling tonight is that perhaps it should say “tldr; setting the –prefix sets the output directory for the RSB” and then have a link to something more elaborate like what CJ said.
Thanks for listening! Russell
Author: Amar Takhar
2025-09-05T03:01:05.769Z
changed the description
3050 - Buffer Overflow in pc386 Video Driver (opened)¶
Id |
3050 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2017-06-14T14:32:10.000Z |
Updated |
2025-09-19T01:45:34.862Z |
Milestone |
5.4 |
Labels |
bsp, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
./../../../../../../../rtems/c/src/lib/libbsp/i386/pc386/console/fb_vesa_rm.c:117:9: warning: ‘strncpy’ writing 16 bytes into a region of size 4 overflows the destination [-Wstringop-overflow=]
Looking at the code, it looks suspicious. Passing to Pavel for some insight.
Author: Joel Sherrill
2017-06-14T14:32:27.000Z
Owner set to ppisa
Status changed from new to assigned
Author: Trac Migrate
2017-06-15T18:24:51.000Z
Attachment 0001-i386-pc386-VESA-fb-copy-the-length-of-VBE-signature-.patch added
Patch prepared by Jan Dolezal to solve the warning/problem.
Author: Trac Migrate
2017-06-15T18:26:18.000Z
I have send question to Jan Dolezal and he prepared patch. I can commit it but not test till month end.
Author: Chris Johns
2025-09-19T01:45:34.922Z
changed the description
3039 - ppc/qemuprep: Qemu fails to boot, no boot partition found (opened)¶
Id |
3039 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2017-06-12T11:05:38.000Z |
Updated |
2025-09-19T01:45:34.760Z |
Milestone |
5.4 |
Labels |
bsp, old-indefinite, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: cpod
PowerPC/qemuprep bsp fails to boot as no boot partition can be found tried with:
qemu-system-ppc -no-reboot -monitor null -serial stdio -nographic -net none -M prep -kernel $HOME/development/rtems/qemuprep/powerpc-rtems4.12/c/qemuprep/testsuites/samples/hello/hello.exe
and also tried to boot from floppy:
qemu-system-ppc -boot a -fda ./rtems-boot.img -m 20MB -append “console=/dev/com1” -serial stdio -no-reboot -kernel $HOME/development/rtems/qemuprep/powerpc-rtems4.12/c/qemuprep/testsuites/samples/hello/hello.exe
seems to ignore this boot option, also hangs at the end and does not exit
qemu-system-ppc -no-reboot -monitor null -serial stdio -nographic -net none -M prep -kernel $HOME/development/rtems/qemuprep/powerpc-rtems4.12/c/qemuprep/testsuites/samples/hello/hello.exe register PCI host ‘pci-bridge’ ‘pci’ ‘<null>’ ‘PREP Host PCI Bridge - Motorola Raven’ register ‘pci-bridge’ ‘pci’ ‘<null>’ ‘PREP Host PCI Bridge - Motorola Raven’ 0x80000000 in ‘device-tree’ 0xffffffff Done 582b000 582b880 PCI device ‘<null>’ 0 11 0 has no reg properties: PCI device ‘<null>’ 0 11 0 has no assigned addresses properties: register pci device ‘Qemu VGA’ 0000000d ‘display’ ‘VGA’ ‘Qemu VGA’ register ‘Qemu VGA’ ‘display’ ‘VGA’ ‘Qemu VGA’ 0x0000000d in ‘pci-bridge’ 0x80000000 Done 582b880 582b980 PCI device ‘Qemu VGA’ 0 13 0 reg properties: addr: 82006810 00000000 f0000000 size: 00000000 01000000 addr: 82006818 00000000 f1000000 size: 00000000 00010000 PCI device ‘Qemu VGA’ 0 13 0 assigned addresses properties: addr: 82006810 00000000 f0000000 size: 00000000 01000000 addr: 82006818 00000000 f1000000 size: 00000000 00010000 PPC Open Hack’Ware BIOS for qemu version 0.4.1 Build 2014-07-04 15:23:25 Copyright 2003-2005 Jocelyn Mayer
Memory size: 128 MB. Booting from device m ide0: drive 0: none ide0: drive 1: none ide1: drive 0: CD-ROM ERROR: OF_property_copy cannot get property ‘cd’ for aliases ERROR: ATAPI TEST_UNIT_READY : status 58 != 0x08 ERROR: ATAPI TEST_UNIT_READY : status 41 != 0x40 ide1: drive 1: none Probe partitions for device m ERROR: No MSDOS signature (38 0 0 0) Use bloc device as raw partition Boot partition: 0 9401fff8 9401fff8 0 ERROR: OF_property_copy cannot get property ‘alias’ for <null> boot device: 5832000 image 1000000 size 4599176 ERROR: No MSDOS signature (7f 45 0 0) Use bloc device as raw partition Boot partition: 0 9401fff8 9401fff8 0 boot device: 5832000 ERROR: Found no boot partition! ERROR: BUG caught… BIOS execution exception nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000 Stopping execution qemu: terminating on signal 2
Author: Trac Migrate
2017-06-15T09:27:51.000Z
Original author: cpod
Milestone set to %”Indefinite”
Author: Amar Takhar
2025-09-05T03:02:38.768Z
changed the description
4985 - Build error: building srg9xwm1 (opened)¶
Id |
4985 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2024-01-30T21:51:25.000Z |
Updated |
2024-10-06T21:57:58.281Z |
Milestone |
5.4 |
Labels |
priority::normal, rtems::build, tickettype::defect, tool::gdb, version::5 |
Link |
|
Merges |
0 |
Original author: qwertyspark
I am attempting to build the RTEMS 5.3 toolset on Windows using MSYS2 with mingw64. I have been following the quick-start guide in the 5.3 user guide.
I have included a source builder error report for reference.
I entered the following command to initiate the build:
{{{#!python
../source-builder/sb-set-builder --prefix=C:/msys64/home/<REDACT>/quick-start/rtems/5 5/rtems-sparc
}}}
The build progressed as expected until building gdb-9.1.
The error report indicated the following error:
{{{#!python
../../gdb-9.1/gdb/completer.c: In function 'char* gdb_completion_word_break_characters_throw()':
../../gdb-9.1/gdb/completer.c:1933:10: error: invalid conversion from 'const char*' to 'char*' [-fpermissive]
1933 | return rl_completer_word_break_characters;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| const char*
}}}
Here is the referenced section of code from completer.c. Specifically “return rl_completer_word_break_characters;”
const char *
gdb_completion_word_break_characters_throw ()
{
/* New completion starting. Get rid of the previous tracker and
start afresh. */
delete current_completion.tracker;
current_completion.tracker = new completion_tracker ();
completion_tracker &tracker = *current_completion.tracker;
complete_line_internal (tracker, NULL, rl_line_buffer,
rl_point, handle_brkchars);
if (tracker.use_custom_word_point ())
{
gdb_assert (tracker.custom_word_point () > 0);
rl_point = tracker.custom_word_point () - 1;
gdb_assert (rl_point >= 0 && rl_point < strlen (rl_line_buffer));
gdb_custom_word_point_brkchars[0] = rl_line_buffer[rl_point];
rl_completer_word_break_characters = gdb_custom_word_point_brkchars;
rl_completer_quote_characters = NULL;
/* Clear this too, so that if we're completing a quoted string,
readline doesn't consider the quote character a delimiter.
If we didn't do this, readline would auto-complete {b
'fun<tab>} to {'b 'function()'}, i.e., add the terminating
\\', but, it wouldn't append the separator space either, which
is not desirable. So instead we take care of appending the
quote character to the LCD ourselves, in
gdb_rl_attempted_completion_function. Since this global is
not just completer-specific, we'll restore it back to the
default in gdb_rl_attempted_completion_function. */
rl_basic_quote_characters = NULL;
}
return rl_completer_word_break_characters;
}
char *
gdb_completion_word_break_characters ()
{
/* New completion starting. */
current_completion.aborted = false;
try
{
return gdb_completion_word_break_characters_throw ();
}
catch (const gdb_exception &ex)
{
/* Set this to that gdb_rl_attempted_completion_function knows
to abort early. */
current_completion.aborted = true;
}
return NULL;
}
Author: Trac Migrate
2024-01-30T21:52:35.000Z
Original author: qwertyspark
Attachment rsb-report-sparc-rtems5-gdb-9.1-x86_64-w64-mingw32-1.txt added
RTEMS Tools Project - Source Builder Error Report
Author: Joel Sherrill
2024-01-30T23:40:08.000Z
Original author: qwertyspark
Is gdb configured with –disable-werror (or similar)? This might be in the –log file if you configured with that.
This type of thing is generally an issue as the host OSes get newer and newer tools and releases of RTEMS and other distributions tend to be tested with older packages.
Author: Amar Takhar
2024-04-25T20:50:57.700Z
changed the description
4897 - Wrong result comparing Python versions in gdb-common-1.cfg (opened)¶
Id |
4897 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2023-04-13T11:25:56.000Z |
Updated |
2023-04-13T11:25:56.000Z |
Milestone |
5.4 |
Labels |
priority::normal, tickettype::defect, tool::rtems-source-builder, version::5 |
Link |
|
Merges |
0 |
Original author: okleinke
On branch: 5, tag: 5.3, commit: 9144a4a
Tried to build using the following command line on a fresh Debian testing:
../source-builder/sb-set-builder --prefix=[...]/rtems/bin 5/rtems-sparc
Fails with:
error: shell macro failed: [...]/rtems/rsb/source-builder/sb/rtems-build-dep -c gcc -l : 2: error: no library (-l) provided
The trace log reveals that a check in gdb-common-1.cfg has the wrong outcome, thus not using the --embed argument when calling python3-config:
config: source-builder/config/gdb-common-1.cfg: 112:>%if %{gdb-python-ver-mm} < 3.8 [True]
config: source-builder/config/gdb-common-1.cfg: 112: _if[1]: ['3.11', '<', '3.8']
config: source-builder/config/gdb-common-1.cfg: 112: _if: numeric value check
config: source-builder/config/gdb-common-1.cfg: 112: _if[2]: ('3.11', '<', '3.8') True none True
config: source-builder/config/gdb-common-1.cfg: 112: _ifs[2]: dir=None 3 ['3.11', '<', '3.8']
config: source-builder/config/gdb-common-1.cfg: 113:>%define gdb-python-config-lib-check-flags --ldflags [True]
config: source-builder/config/gdb-common-1.cfg: 114:>%else [True]
config: source-builder/config/gdb-common-1.cfg: 115: %define gdb-python-config-lib-check-flags --ldflags --embed [False]
config: source-builder/config/gdb-common-1.cfg: 116: %endif [False]
4886 - Build of gdb-9.1 fails on mingw64 (opened)¶
Id |
4886 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2023-03-22T11:08:05.000Z |
Updated |
2023-03-22T11:08:05.000Z |
Milestone |
5.4 |
Labels |
priority::high, tickettype::defect, tool::gdb, version::5 |
Link |
|
Merges |
0 |
Original author: Fantomas96
The building of the rtems-gdb-9.1 fails due to a feature which is considered deprecated by the late model gcc in mingw. The solution is to update the gdb to version 12.1 by putting the gdb-12.1.cfg file inside the rtems-source-builder/rtems/config/tools directory and update the rtems-default.bset file in rtems-source-builder/rtems/config/5 by changing the gdb version to 12.1
4877 - sptests/spsysinit01 sem_open call only has 3 parameters with O_CREAT flag (opened)¶
Id |
4877 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2023-03-13T09:26:17.000Z |
Updated |
2023-03-13T14:29:09.000Z |
Milestone |
5.4 |
Labels |
priority::normal, resolution::invalid, tickettype::defect, tool::test, version::5 |
Link |
|
Merges |
0 |
Original author: lsilistr
When calling sem_open with the O_CREAT flag the sem_open function requires 4 parameters. It will: value = va_arg(args, unsigned int); so the “value” argument will be randomly chosen.
sem_open can fail if the random value is not a valid semaphore value, failing the test.
Author: Joel Sherrill
2023-03-13T13:31:05.000Z
Original author: lsilistr
Resolution set to ~”invalid”
Status changed from new to closed
This is an error on the caller’s part. Per https://pubs.opengroup.org/onlinepubs/9699919799/functions/sem_open.html, the fourth argument is required if you include O_CREAT. Since you did not explicitly pass a value, the result is undefined.
O_CREAT This flag is used to create a semaphore if it does not already exist. If O_CREAT is set and the semaphore already exists, then O_CREAT has no effect, except as noted under O_EXCL. Otherwise, sem_open() creates a named semaphore. The O_CREAT flag requires a third and a fourth argument: mode, which is of type mode_t, and value, which is of type unsigned. The semaphore is created with an initial value of value. Valid initial values for semaphores are less than or equal to {SEM_VALUE_MAX}.
Author: Trac Migrate
2023-03-13T13:35:06.000Z
Original author: lsilistr
It’s the RTEMS test spstests/spsysinit01 that calls sem_open with only 3 arguments (line 911 in init.c - master branch on github right now).
Author: Trac Migrate
2023-03-13T14:28:50.000Z
Original author: lsilistr
Milestone set to %”5.4”
Resolution ~”invalid” deleted
Status changed from closed to reopened
Thanks, you found the reason for a sporadic test failure which is on my TODO list for a long time.
Author: Trac Migrate
2023-03-13T14:29:09.000Z
Original author: lsilistr
Owner set to sebastian.huber
Status changed from reopened to assigned
4742 - Deadlock risk of Immediate Ceiling Priority Protocol (ICPP) with nested resource sharing (opened)¶
Id |
4742 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2022-10-19T09:54:00.000Z |
Updated |
2023-01-31T22:44:38.000Z |
Milestone |
5.4 |
Labels |
priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: JJShi
In the current implementation of Immediate Ceiling Priority Protocol (ICPP), the task’s base priority is assumed to be lower or equal to the requested resource’s ceiling after a successful ceiling check.
However, we notice that the resource’s ceiling is not checked against the thread’s (task’s) base priority but against its current dunamic priority derived from the task’s priority aggregation. According to the definition of priority ceiling, a resource’s ceiling is required to be set as the highest base priority of all tasks that are requesting it.
This mismatch may lead to a deadlock by erroneously denying legitimate nested resource access if resources are requested with descending order of priority ceilings. We give an example to elaborate such a case: Consider two tasks t_1 and t_2, t_1 has higher priority than t_2 and two resources R_1 (used by both tasks) and R_2 (used by t_2 only) with Ceiling(R_1) = Priority(t_1) and Ceiling(R_2) = Priority(t_2). If t_2 acquires R_1, it inherits its priority ceiling and executes with the promoted dynamic priority Priority(t_1). If it requests the second resource R_2 , its dynamic priority is higher than Ceiling(R_2), which leads to a denial of the resource access by the implemented ceiling check. The consequence of this is a deadlock, i.e., t_2 holds R_1 but cannot successfully lock semaphore R_2 due to the implemented ceiling check, whilst t_1 cannot enter the critical section guarded by R_1.
Such execution behavior with a deadlock can also be demonstrated by a running example in RTEMS, which has been attached.
To correct the mismatch, an adaption to the priority ceiling check is proposed in the attached patch for coremuteximpl.h. Instead of checking the potentially already increased dynamic priority, it uses the thread’s base priority for the comparison to the newly requested resource’s priority ceiling.
After applying the correction, the aforementioned counterexample can be successfully executed.
Author: Trac Migrate
2022-10-19T09:55:11.000Z
Original author: JJShi
Attachment ICPP_Test.c added
ICPP test with deadlock
Author: Chris Johns
2022-11-10T01:06:35.000Z
Original author: JJShi
Milestone changed from %”5.1” to %”5.3”
Author: Gedare Bloom
2023-01-31T22:43:44.000Z
Original author: JJShi
I would like to move this to 5.4 at least. I believe this bug is avoidable by common practice, and deterministically triggered if it will occur. I would isolate the fix to a later dot release to avoid unexpected impacts on other applications.
Author: Gedare Bloom
2023-01-31T22:44:38.000Z
Original author: JJShi
Milestone changed from %”5.3” to %”5.4”
4721 - Support tar along with pax (opened)¶
Id |
4721 |
State |
opened |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Created |
2022-09-22T07:42:24.000Z |
Updated |
2023-01-30T00:46:32.000Z |
Milestone |
5.4 |
Labels |
priority::normal, rtems::build, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Rocky 9 does not provide pax. Searching PowerTools and CRB repos does not report pax or spax as available. RPM websites do not report the RPM available.
Change libdl tests to use tar if pax is not available. Update the options to map pax functionality to GNU tar. BSD tar is not supported but this should not be an issue because BSD systems should maintain pax.
Note, RTEMS 6 uses waf and Python’s tarfile support.
Author: Chris Johns
2022-09-22T22:18:39.000Z
It is simpler to support BSD tar so it will also be supported.
Author: Chris Johns
2022-11-09T23:46:22.000Z
Milestone changed from %”5.2” to %”5.3”
Author: Chris Johns
2023-01-30T00:46:32.000Z
Milestone changed from %”5.3” to %”5.4”
Merge Requests¶
1068 - README: Rename and convert to markdown¶
Id |
1068 |
State |
merged |
Merged by |
Chris Johns |
Merged at |
2026-02-20T00:31:43.838Z |
Assignee(s) |
Kinsey Moore |
Created |
2026-02-20T00:29:58.656Z |
Updated |
2026-02-20T00:31:43.827Z |
Milestone |
5.4 |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1068 |
Commit |
Summary¶
README: Rename and convert to markdown
This updates README to README.md for homogeniety purposes to allow releases to be more consistent.
Closes #5494
Generative AI¶
Author: Kinsey Moore
2026-02-20T00:29:59.118Z
assigned to @opticron
Author: Chris Johns
2026-02-20T00:30:55.151Z
approved this merge request
Author: Chris Johns
2026-02-20T00:30:59.162Z
enabled an automatic merge when all merge checks for 0b77054106928f29ab8068541cfe966036edfef9 pass
Author: Joel Sherrill
2026-02-20T00:31:41.316Z
approved this merge request
429 - cpukit/termios: Fix ordering of baud rate table¶
Id |
429 |
State |
merged |
Merged by |
Kinsey Moore |
Merged at |
2025-02-20T22:09:14.743Z |
Assignee(s) |
Gedare Bloom |
Created |
2025-02-20T10:30:32.295Z |
Updated |
2025-02-20T22:09:17.378Z |
Milestone |
5.4 |
Labels |
backport, cpukit |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/429 |
Commit |
Summary¶
cpukit/termios: Fix ordering of baud rate table
rtems_termios_set_best_baud expects a sorted baud rate table.
Fixes #5220
Author: Gedare Bloom
2025-02-20T21:42:56.677Z
assigned to @gedare
Author: Gedare Bloom
2025-02-20T21:51:49.326Z
approved this merge request
Author: Kinsey Moore
2025-02-20T22:08:29.946Z
approved this merge request
Author: Kinsey Moore
2025-02-20T22:08:56.351Z
added 2 commits
13cbd834 - 1 commit from branch
rtems/rtos:561654535 - cpukit/termios: Fix ordering of baud rate table
428 - Backport 5.4: grlib/occan: Fix baud rate calculation¶
Id |
428 |
State |
merged |
Merged by |
Kinsey Moore |
Merged at |
2025-02-20T22:08:35.119Z |
Assignee(s) |
Gedare Bloom |
Created |
2025-02-20T10:24:22.519Z |
Updated |
2025-02-20T22:08:37.091Z |
Milestone |
5.4 |
Labels |
backport |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/428 |
Commit |
Summary¶
grlib/occan: Fix baud rate calculation
Fixes #5219
Author: Jan Sommer
2025-02-20T10:24:50.901Z
added 1 commit
13cbd834 - grlib/occan: Fix baud rate calculation
Author: Amar Takhar
2025-02-20T11:04:50.651Z
I merged the CI into the wrong branch should have 5 not 5.3. @chris is this true?
Author: Amar Takhar
2025-02-20T11:05:23.285Z
Actually nevermind it IS to 5 hmm.
Author: Amar Takhar
2025-02-20T11:09:19.557Z
Strange no ideas why the pipeline took so long I had to go to ‘Pipelines’ and run it but not sure if that made a difference.
Author: Amar Takhar
2025-02-20T11:10:22.805Z
Nevermind I think I know why it’s a permission thing will need to look into it. It’s being blocked somewhere.
Author: Gedare Bloom
2025-02-20T21:40:36.707Z
approved this merge request
Author: Gedare Bloom
2025-02-20T21:42:19.815Z
assigned to @gedare
Author: Kinsey Moore
2025-02-20T22:08:24.966Z
approved this merge request
419 - gitlab: Add link to CI¶
Id |
419 |
State |
merged |
Merged by |
Chris Johns |
Merged at |
2025-02-13T03:23:53.001Z |
Assignee(s) |
Amar Takhar |
Created |
2025-02-12T13:55:17.479Z |
Updated |
2025-02-13T03:23:54.762Z |
Milestone |
5.4 |
Labels |
ci |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/419 |
Commit |
Summary¶
gitlab: Add link to CI
This runs only the commit message and merge request checker.
Required so we can have ‘all pipelines must pass’ enabled due to a bug in Gitlab
Author: Amar Takhar
2025-02-12T13:55:17.940Z
assigned to @amar
Author: Amar Takhar
2025-02-12T14:04:29.501Z
Once this is merged I can enable enforcing pipelines must pass.
Author: Kinsey Moore
2025-02-12T14:46:34.046Z
approved this merge request
Author: Chris Johns
2025-02-13T03:19:50.942Z
changed the description
Author: Chris Johns
2025-02-13T03:23:43.649Z
Commit message has “ue” instead of “due”.
Author: Amar Takhar
2025-02-13T03:22:46.883Z
added 1 commit
ef6e6e30 - gitlab: Add link to CI
Author: Chris Johns
2025-02-13T03:23:43.665Z
resolved all threads
Author: Chris Johns
2025-02-13T03:23:46.727Z
approved this merge request