RTEMS / RTOS / RTEMS

Go to Issues or Merge Requests

Issues Summary

Merge Requests Summary


Issues

5281 - RTEMS 6.1 GR740 Multiprocessing build fails

Id

5281

State

closed

Type

ISSUE

Author

Gedare Bloom

Assignee(s)

Matteo Concas

Closed by

Matteo Concas

Created

2025-06-24T20:26:51.026Z

Closed

2025-07-04T06:49:45.863Z

Updated

2025-07-04T06:49:45.876Z

Milestone

6.2

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5281

Merges

0

Summary

When building the GR740 BSP with RTEMS_MULTIPROCESSING set to true , the build will fail.

Steps to reproduce

The INI file contents are:

[DEFAULT]
RTEMS_POSIX_API = True

[sparc/gr740_mp]
INHERIT=gr740
RTEMS_MULTIPROCESSING=True

I configure the Waf system with:

./waf configure --prefix=$RTEMS_PREFIX --rtems-config=gr740.ini

And then ./waf to build the BSP. I get the following output:

Waf: Entering directory `/scratch/matteo/rtems-build/src/rtems-6.1/build'
Waf: Leaving directory `/scratch/matteo/rtems-build/src/rtems-6.1/build'
'build' finished successfully (0.081s)
Waf: Entering directory `/scratch/matteo/rtems-build/src/rtems-6.1/build/sparc/gr740_mp'
[ 167/1641] Compiling bsps/sparc/leon3/clock/ckinit.c
In file included from ../../../bsps/sparc/leon3/clock/ckinit.c:46:
../../../bsps/sparc/leon3/clock/ckinit.c: In function 'leon3_clock_initialize':
../../../bsps/sparc/leon3/include/bsp/leon3.h:221:5: error: 'leon3_timer_core_index' undeclared (first use in this function); did you mean 'leon3_timecounter'?
221 |   ( leon3_timer_core_index != 0 ? 0 : 2 * LEON3_Cpu_Index )
|     ^~~~~~~~~~~~~~~~~~~~~~
../../../bsps/sparc/leon3/clock/ckinit.c:181:36: note: in expansion of macro 'LEON3_CLOCK_INDEX'
181 |   timer = &LEON3_Timer_Regs->timer[LEON3_CLOCK_INDEX];
|                                    ^~~~~~~~~~~~~~~~~
../../../bsps/sparc/leon3/include/bsp/leon3.h:221:5: note: each undeclared identifier is reported only once for each function it appears in
221 |   ( leon3_timer_core_index != 0 ? 0 : 2 * LEON3_Cpu_Index )
|     ^~~~~~~~~~~~~~~~~~~~~~
../../../bsps/sparc/leon3/clock/ckinit.c:181:36: note: in expansion of macro 'LEON3_CLOCK_INDEX'
181 |   timer = &LEON3_Timer_Regs->timer[LEON3_CLOCK_INDEX];
|                                    ^~~~~~~~~~~~~~~~~
../../../bsps/sparc/leon3/clock/../../../shared/dev/clock/clockimpl.h: In function '_Clock_Initialize':
../../../bsps/sparc/leon3/include/bsp/leon3.h:221:5: error: 'leon3_timer_core_index' undeclared (first use in this function); did you mean 'leon3_timecounter'?
221 |   ( leon3_timer_core_index != 0 ? 0 : 2 * LEON3_Cpu_Index )
|     ^~~~~~~~~~~~~~~~~~~~~~
../../../bsps/sparc/leon3/clock/ckinit.c:137:49: note: in expansion of macro 'LEON3_CLOCK_INDEX'
137 | #define Adjust_clkirq_for_node() do { clkirq += LEON3_CLOCK_INDEX; } while(0)
|                                                 ^~~~~~~~~~~~~~~~~
../../../bsps/sparc/leon3/clock/ckinit.c:145:7: note: in expansion of macro 'Adjust_clkirq_for_node'
145 |       Adjust_clkirq_for_node(); \\
|       ^~~~~~~~~~~~~~~~~~~~~~
../../../bsps/sparc/leon3/clock/../../../shared/dev/clock/clockimpl.h:249:3: note: in expansion of macro 'Clock_driver_support_find_timer'
249 |   Clock_driver_support_find_timer();
|   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Waf: Leaving directory `/scratch/matteo/rtems-build/src/rtems-6.1/build/sparc/gr740_mp'
Build failed
-> task in '/bsps/sparc/leon3/obj' failed with exit status 1 (run with -v to display more information)

Expected behaviour

Build should complete successfully.

Possible fix

From my own investigation this comes from bsps/sparc/leon3/include/bsp/leon3.h . leon3_timer_core_index is only declared if LEON3_GPTIMER_BASE is not defined but later in the file the LEON3_CLOCK_INDEX macro is defined in the following way:

/**
* @brief This constant defines the index of the GPTIMER timer used by the
*   clock driver.
*/
#if defined(RTEMS_MULTIPROCESSING)
#define LEON3_CLOCK_INDEX \\
( leon3_timer_core_index != 0 ? 0 : 2 * LEON3_Cpu_Index )
#else
#define LEON3_CLOCK_INDEX 0
#endif

So when RTEMS_MULTIPROCESSING is used the LEON3_CLOCK_INDEX will expand to use the leon3_timer_core_index variable which won’t be declared as the GPTIMER base is defined for the GR740 BSP.

I don’t fully understand why the LEON3_CLOCK_INDEX macro is defined this way but changing it’s define conditional to:

#if defined(RTEMS_MULTIPROCESSING) && !defined(LEON3_GPTIMER_BASE)

Will make the BSP build successfully, I haven’t had the time to test this fix, it might break something else at runtime.

Author: Gedare Bloom

2025-06-24T20:26:51.204Z

cloned from #5258

Author: Gedare Bloom

2025-06-24T20:28:54.720Z

Author: Gedare Bloom

2025-06-24T20:30:26.097Z

@matteo.concas

Author: Gedare Bloom

2025-06-24T20:30:46.754Z

assigned to @matteo.concas

Author: Gedare Bloom

2025-06-24T20:31:37.061Z

mentioned in merge request !532

5288 - Backport RISC-V Double Trap extension fix to 6

Id

5288

State

closed

Type

ISSUE

Author

Matteo Concas

Closed by

Matteo Concas

Created

2025-07-03T08:07:26.897Z

Closed

2025-07-04T06:48:43.417Z

Updated

2025-07-04T06:48:43.431Z

Milestone

6.2

Labels

arch:riscv

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5288

Merges

0

If the Double Trap Extension is implemented, the MDT bit of the mstatus (or mstatush in RV32) register will be set when a trap is to be taken.

The MIE (Machine Interrupt Enable) bit can only be set to 1 if the MDT bit is zero.

Thus, we need to clear MDT first if we want to enable interrupts when dispatching a thread.

MDT is also cleared in register a1 before restoring the interrupt frame as writing 1 to MDT will cause MIE to be set to 0. In RV64 this happens regardless of the value written to MIE in the same write.

In RV32, MDT is in mstatush so we do not need to clear during restore as this register is not restored.

With this change all 60 SMP tests pass (compared to 20/60 before the fix). The tests have been run on hardware using two RV64 CPUs that implement the double trap extension.

Author: Matteo Concas

2025-07-03T08:10:45.328Z

mentioned in merge request !548

Author: Kinsey Moore

2025-07-03T13:10:32.134Z

added rtems#10 as parent epic

5283 - Backport 6.2: bsps/noelv: Fix using console in polled mode

Id

5283

State

closed

Type

ISSUE

Author

Matteo Concas

Closed by

Gedare Bloom

Created

2025-06-27T07:40:58.098Z

Closed

2025-06-28T15:36:17.903Z

Updated

2025-06-28T15:36:17.916Z

Milestone

6.2

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5283

Merges

0

Summary

bsps/noelv: Fix using console in polled mode

The console driver needs BSP_CONSOLE_USE_INTERRUPTS to be defined or it does not build. The intent was to use polled mode if the macro was equal to zero but not using interrupt means the macro won’t be defined instead.

This is the faulty code:

if (BSP_CONSOLE_USE_INTERRUPTS) {
handler = &apbuart_handler_interrupt;
}

In bsps/riscv/noel/console/console-config.c .

Steps to reproduce

Create a INI with the following contents:

[riscv/noel64imafd_polling]
INHERIT = noel64imafd
RTEMS_SMP = True
BSP_CONSOLE_USE_INTERRUPTS = 0

Build the RTEMS kernel, it will fail to build due to BSP_CONSOLE_USE_INTERRUPTS being undefined.

Expected behaviour

BSP should build successfully.

Author: Matteo Concas

2025-06-27T07:43:21.023Z

mentioned in merge request !537

Author: Kinsey Moore

2025-06-27T12:59:09.680Z

Author: Matteo Concas

2025-06-28T15:35:42.404Z

mentioned in commit dd490c5c2d02e472c83b7052612b554e8b74358f

5254 - i386/pc BSP ATA driver asserts with node errors on FAT disk mount

Id

5254

State

closed

Type

ISSUE

Author

Chris Johns

Assignee(s)

Chris Johns

Closed by

Kinsey Moore

Created

2025-05-28T02:54:29.731Z

Closed

2025-05-30T13:34:36.579Z

Updated

2025-05-30T13:34:36.593Z

Milestone

6.2

Labels

arch:i386

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5254

Merges

0

Summary

With RTEMS_DEBUG enabled the PC ATA driver asserts with a failure because a node’s link pointer is not set to NULL. The assert is:

assertion "_Chain_Is_node_off_chain( the_node )" failed: file "../../../cpukit/include/rtems/score/chainimpl.h", line 691, function: _Chain_Append_unprotected

A back trace is:

(gdb) bt
#0  0x00162c55 in bsp_reset (source=source@entry=RTEMS_FATAL_SOURCE_ASSERT, code=code@entry=1872624) at ../../../bsps/i386/pc386/start/bspreset.c:39
#1  0x00161b15 in bsp_fatal_extension (source=RTEMS_FATAL_SOURCE_ASSERT, always_set_to_false=false, code=1872624) at ../../../bsps/shared/start/bspfatal-default.c:213
#2  0x001189b3 in _User_extensions_Iterate (arg=arg@entry=0x1c92b8, visitor=0x118900 <_User_extensions_Fatal_visitor>, direction=CHAIN_ITERATOR_FORWARD) at ../../../cpukit/score/src/userextiterate.c:194
#3  0x0011321f in _User_extensions_Fatal (error=1872624, source=RTEMS_FATAL_SOURCE_ASSERT) at ../../../cpukit/include/rtems/score/userextimpl.h:467
#4  _Terminate (the_source=the_source@entry=RTEMS_FATAL_SOURCE_ASSERT, the_error=the_error@entry=1872624) at ../../../cpukit/score/src/interr.c:66
#5  0x001077ec in rtems_fatal (fatal_code=1872624, fatal_source=RTEMS_FATAL_SOURCE_ASSERT) at ../../../cpukit/include/rtems/fatal.h:160
#6  __assert_func (file=file@entry=0x189a64 "../../../cpukit/include/rtems/score/chainimpl.h", line=691, func=0x1a0378 <__func__.0> "_Chain_Append_unprotected", failedexpr=0x189a3c "_Chain_Is_node_off_chain( the_node )") at ../../../cpukit/libcsupport/src/__assert.c:71
#7  0x0016c03d in _Chain_Append_unprotected (the_node=0x1cbbc0, the_chain=0x1aae4c <ata_ide_ctrls+44>) at ../../../cpukit/include/rtems/score/chainimpl.h:691
#8  0x0016c0dc in _Chain_Append_unprotected (the_node=0x1cbbc0, the_chain=0x1aae4c <ata_ide_ctrls+44>) at ../../../cpukit/sapi/src/chainprotected.c:99
#9  rtems_chain_append (chain=chain@entry=0x1aae4c <ata_ide_ctrls+44>, node=0x1cbbc0) at ../../../cpukit/sapi/src/chainprotected.c:97
#10 0x00160cb9 in ata_add_to_controller_queue (ctrl_minor=0, areq=0x1cbbc0) at ../../../bsps/shared/dev/ide/ata.c:540
#11 0x00160ea1 in ata_io_data_request (ata_dev=<optimized out>, req=0x1c9450) at ../../../bsps/shared/dev/ide/ata.c:228
#12 ata_ioctl (dd=0x1bee44, cmd=3222815233, argp=0x1c9450) at ../../../bsps/shared/dev/ide/ata.c:949
#13 0x00102f5e in rtems_bdbuf_execute_transfer_request (dd=dd@entry=0x1bee44, req=req@entry=0x1c9450, cache_locked=cache_locked@entry=true) at ../../../cpukit/libblock/src/bdbuf.c:1878
#14 0x001032c9 in rtems_bdbuf_execute_read_request (dd=dd@entry=0x1bee44, bd=<optimized out>, bd@entry=0x1bbe2c, transfer_count=transfer_count@entry=1) at ../../../cpukit/libblock/src/bdbuf.c:1994
#15 0x001044df in rtems_bdbuf_read (dd=dd@entry=0x1bee44, block=block@entry=0, bd_ptr=bd_ptr@entry=0x1c9558) at ../../../cpukit/libblock/src/bdbuf.c:2094
#16 0x00131f67 in rtems_bdpart_read_record (dd=0x1bee44, index=0, block=0x1c9558) at ../../../cpukit/libblock/src/bdpart-read.c:220
#17 0x00132190 in rtems_bdpart_read (disk_name=disk_name@entry=0x1ca62e "/dev/hda", format=format@entry=0x1c95dc, pt=pt@entry=0x1c9630, count=count@entry=0x1c95d4) at ../../../cpukit/libblock/src/bdpart-read.c:273
#18 0x00119a5e in rtems_bdpart_shell_main (argc=2, argv=0x1c9b30) at ../../../cpukit/libmisc/shell/fdisk.c:236
#19 0x0012dacd in shell_main_loop (shell_env=shell_env@entry=0x1c9ec8, interactive=interactive@entry=true, line_editor_output=<optimized out>) at ../../../cpukit/libmisc/shell/shell.c:1215
#20 0x0012ed18 in rtems_shell_main_loop (shell_env=shell_env@entry=0x1c9ec8) at ../../../cpukit/libmisc/shell/shell.c:1383
#21 0x0012ed38 in rtems_shell_task (task_argument=1875656) at ../../../cpukit/libmisc/shell/shell.c:1038
#22 0x00115adb in _Thread_Handler () at ../../../cpukit/score/src/threadhandler.c:164
#23 0xa5a5a5a5 in ?? ()

Steps to reproduce

INI file:

[DEFAULT]
RTEMS_DEBUG = True
RTEMS_POSIX_API = True

[i386/pc686]
BUILD_TESTS = True

Run the fileio.exe test, enter the shell and then enter the following command:

fdisk /dev/hda

The shell session is:

*** BEGIN OF TEST FILE I/O ***
*** TEST VERSION: 7.0.0.34c362fee100659e36a6945204f77e71cb1c2f7e
*** TEST STATE: USER_INPUT
*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API
*** TEST TOOLS: 13.3.0 20240521 (RTEMS 7, RSB 170160cb918e7c68b4b35d8f0a42db6df81168e7, Newlib 1b3dcfd)
Press any key to start file I/O sample (20s remaining)
=========================
RTEMS FILE I/O Test Menu
=========================
p -> part_table_initialize
f -> mount all disks in fs_table
l -> list  file
r -> read  file
w -> write file
s -> start shell
Enter your selection ==>s
Creating /etc/passwd and group with four useable accounts:
root/pwd
test/pwd
rtems/NO PASSWORD
chroot/NO PASSWORD
Only the root user has access to all available commands.
=========================
starting shell
=========================

Welcome to rtems-7.0.0 (Intel i386/Pentium/pc686)
Copyright (C) 1989, 2021 RTEMS Project and contributors
Login into RTEMS
/dev/foobar login: root
Password:

RTEMS Shell on /dev/foobar. Use 'help' to list commands.
SHLL [/] # fdisk /dev/hda
assertion "_Chain_Is_node_off_chain( the_node )" failed: file "../../../cpukit/include/rtems/score/chainimpl.h", line 691, function: _Chain_Append_unprotected
Pre-set options

Author: Chris Johns

2025-05-28T02:54:30.004Z

cloned from #5253

Author: Chris Johns

2025-05-28T02:54:43.589Z

assigned to @chris

Author: Chris Johns

2025-05-28T02:54:53.933Z

Author: Chris Johns

2025-05-28T02:56:00.050Z

changed title from i38{-p-}/pc BSP ATA driver asserts with node errors on FAT disk mount to i38{+6+}/pc BSP ATA driver asserts with node errors on FAT disk mount

Author: Chris Johns

2025-05-28T03:02:54.791Z

mentioned in merge request !492

Author: Chris Johns

2025-05-30T13:34:27.984Z

mentioned in commit cb3fba044770f0bb6a96bd2b93e09df90d1e2e34

5232 - Backport “spec: Install missing header files for GRLIB and SPARC” to 6 branch

Id

5232

State

closed

Type

ISSUE

Author

Kinsey Moore

Assignee(s)

Kinsey Moore

Closed by

Kinsey Moore

Created

2025-03-26T15:53:40.588Z

Closed

2025-03-26T16:50:40.530Z

Updated

2025-03-26T16:50:40.542Z

Milestone

6.2

Labels

grlib

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5232

Merges

1

The following discussion from !458 should be addressed:

  • [] @joel started a discussion

    1. Is this also being applied to the 6 branch?

Author: Kinsey Moore

2025-03-26T15:53:40.797Z

assigned to @opticron

Author: Kinsey Moore

2025-03-26T15:53:41.118Z

Author: Kinsey Moore

2025-03-26T15:54:02.665Z

Author: Kinsey Moore

2025-03-26T16:00:38.727Z

changed the description

Author: Matteo Concas

2025-03-26T16:48:52.616Z

mentioned in merge request !459

5173 - powerpc/qoriq: Avoid spurious interrupt fatal errors

Id

5173

State

closed

Type

ISSUE

Author

Sebastian Huber

Assignee(s)

Sebastian Huber

Closed by

Gedare Bloom

Created

2024-12-05T23:47:28.576Z

Closed

2025-02-07T23:22:10.064Z

Updated

2025-02-11T05:38:23.897Z

Milestone

6.2

Labels

arch:powerpc

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5173

Merges

2

Summary

The interrupt dispatching routine erroneously invokes the fatal error handler if a spurious interrupt is acknowledged.

Pre-set options

Author: Sebastian Huber

2024-12-05T23:47:28.686Z

assigned to @sebhub

Author: Sebastian Huber

2024-12-05T23:47:36.803Z

cloned to #5174

Author: Sebastian Huber

2024-12-05T23:47:47.386Z

Author: Sebastian Huber

2024-12-06T10:22:32.171Z

mentioned in merge request !345

Author: Chris Johns

2024-12-22T03:38:40.991Z

Author: Gedare Bloom

2025-02-07T23:22:09.483Z

Fixed in e421c922a87842f0613a269054acd041e46c91cd

Author: Sebastian Huber

2025-02-11T05:38:23.477Z

mentioned in commit e421c922a87842f0613a269054acd041e46c91cd

5205 - Back port “grlib/occan: Fix baud rate calculation” to 6

Id

5205

State

closed

Type

ISSUE

Author

Joel Sherrill

Closed by

Gedare Bloom

Created

2025-02-07T15:07:07.522Z

Closed

2025-02-07T20:37:37.624Z

Updated

2025-02-11T05:38:23.820Z

Milestone

6.2

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5205

Merges

2

The following discussion from !340 should be addressed:

  • [] @gedare started a discussion

    @thesummer Should this be back-ported to 6?

    Yes. @thesummer please use this issue to back port the fix to 6.

Author: Joel Sherrill

2025-02-07T15:07:26.994Z

Author: Gedare Bloom

2025-02-07T15:51:54.551Z

mentioned in merge request !404

Author: Jan Sommer

2025-02-11T05:38:23.247Z

mentioned in commit a0e4be53f4e30ee02d6d0c9221d613d18c72f426

5189 - Backport libdl ARM trampoline crash fix

Id

5189

State

closed

Type

ISSUE

Author

Kinsey Moore

Assignee(s)

Kinsey Moore

Closed by

Chris Johns

Created

2025-01-23T22:24:29.147Z

Closed

2025-01-24T00:10:34.134Z

Updated

2025-02-11T05:38:23.668Z

Milestone

6.2

Labels

arch:arm, cpukit::dl

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5189

Merges

2

Summary

When a trampoline is not aligned on a word boundary and a ldr.w pc,[pc] instruction is generated, the address loaded is not pc+4, but instead pc+2.

Author: Kinsey Moore

2025-01-23T22:24:29.300Z

assigned to @opticron

Author: Kinsey Moore

2025-01-23T22:24:29.649Z

Author: Kinsey Moore

2025-01-23T22:26:00.055Z

mentioned in merge request !367

Author: Chris Johns

2025-01-24T00:10:28.724Z

changed title from Backpor{-r-}t libdl ARM trampoline crash fix to Backport libdl ARM trampoline crash fix

Author: Ranulfo Raphael

2025-02-11T05:38:23.161Z

mentioned in commit 84c2cf3da9983ef7eadb11d4a676449d6b3ef875

4958 - NTP broadcast client fails to open sockets on lwIP

Id

4958

State

closed

Type

ISSUE

Author

Kinsey Moore

Assignee(s)

Trac Migrate

Closed by

Kinsey Moore

Created

2023-10-04T19:42:57.000Z

Closed

2025-01-31T18:30:49.585Z

Updated

2025-01-31T18:30:49.660Z

Milestone

6.2

Labels

network::lwip, priority::normal, tickettype::defect, version::6

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4958

Merges

0

Reproduction: * Install lwIP on top of a compatible BSP * Modify the existing ntp01 test to use the broadcast client * Set NTP_DEBUG to 1 * Replace the first two lines of etc_ntp_conf with: * broadcastclient * disable auth * Build rtems-net-services against the installed BSP with lwIP network stack * Run the modified ntp01 test

Expected result: NTP opens broadcast listener successfully.

Actual result: NTP fails to open broadcast listener with error message: bind(37) AF_INET 0.0.0.0#123 flags 0x409 failed: Address already in use

Workaround: In open_socket() in bsd/freebsd/contrib/ntp/ntpd/ntp_io.c, there is a test for wildcard addresses inside a OS_NEEDS_REUSEADDR_FOR_IFADDRBIND conditional. If the set_wildcard_reuse() call is made unconditional, the socket creation succeeds.

The root cause is that behavior differs between LibBSD and lwIP. On lwIP, early-bound wildcard and non-wildcard address bindings succeed, but late-bound wildcard address bindings fail. Once any any address is bound, lwIP will fail to bind any further wildcard sockets. Either we can change lwIP’s behavior to be closer to LibBSD or we can alter the NTP client to check for lwIP or blindly apply the address reuse flags.

Author: Kinsey Moore

2023-10-04T19:44:27.000Z

  • Description changed

Reproduction:
* Install lwIP on top of a compatible BSP
* Modify the existing ntp01 test to use the broadcast client
- ** Set NTP_DEBUG to 1
?  -

+  * Set NTP_DEBUG to 1
? +

- ** Replace the first two lines of etc_ntp_conf with:
?  -

+  * Replace the first two lines of etc_ntp_conf with:
? +

- *** broadcastclient
?  --

+   * broadcastclient
? ++

- *** disable auth
?  --

+   * disable auth
? ++

* Build rtems-net-services against the installed BSP with lwIP network stack
* Run the modified ntp01 test

Expected result:
NTP opens broadcast listener successfully.

Actual result:
NTP fails to open broadcast listener with error message:
bind(37) AF_INET 0.0.0.0#123 flags 0x409 failed: Address already in use

Workaround:
In open_socket() in bsd/freebsd/contrib/ntp/ntpd/ntp_io.c, there is a test for wildcard addresses inside a OS_NEEDS_REUSEADDR_FOR_IFADDRBIND conditional. If the set_wildcard_reuse() call is made unconditional, the socket creation succeeds.

The root cause is that behavior differs between LibBSD and lwIP. On lwIP, early-bound wildcard and non-wildcard address bindings succeed, but late-bound wildcard address bindings fail. Once any any address is bound, lwIP will fail to bind any further wildcard sockets. Either we can change lwIP's behavior to be closer to LibBSD or we can alter the NTP client to check for lwIP or blindly apply the address reuse flags.

Author: Chris Johns

2023-10-04T21:30:43.000Z

I think NTP is using _normal_ behavior so lwIP is not compliant in this case. Adding a work around to NTP solves this problem but leaves the issue present other packages may trip over.

Have you asked lwIP about this?

Author: Kinsey Moore

2023-10-05T17:08:40.000Z

I haven’t. This was an issue I noticed and wanted to document that it existed with current thoughts, but I hadn’t moved beyond that yet since the broadcast client isn’t on my priority list at the moment. I’ll agree with you that fixing lwIP to be more “normal” is probably the right solution. I’ll get more context from lwIP.

Author: Gedare Bloom

2024-12-04T21:40:36.490Z

changed the description

Author: Gedare Bloom

2024-12-04T21:40:37.588Z

Author: Kinsey Moore

2025-01-31T18:30:49.722Z

moved to rtems/pkg/rtems-net-services#10

5146 - Follow-up from “Draft: timespec.h, etc.: Eliminate use of 32-bit for time_t”

Id

5146

State

closed

Type

ISSUE

Author

Chris Johns

Assignee(s)

Joel Sherrill

Closed by

Kinsey Moore

Created

2024-11-08T00:37:24.402Z

Closed

2025-01-24T01:08:51.602Z

Updated

2025-01-24T01:08:52.058Z

Milestone

6.2

Labels

rtems::score

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5146

Merges

1

The following discussion from !175 should be addressed:

  • [] @sebhub started a discussion

    Add test case to sptchimespec01 which uses a > 32-bit time?

Author: Chris Johns

2024-11-08T00:37:24.525Z

assigned to @joel

Author: zack liang

2024-11-09T22:19:35.699Z

hey @joel would like to work on this just tell me where the tests file is

Author: zack liang

2024-11-15T01:43:13.170Z

mentioned in merge request !314

Author: Joel Sherrill

2024-12-04T00:56:31.646Z

Author: Gedare Bloom

2024-12-04T21:40:37.917Z

5107 - timespecaddto.c: Use of 32-bit time_t

Id

5107

State

closed

Type

ISSUE

Author

Joel Sherrill

Assignee(s)

Joel Sherrill

Closed by

Chris Johns

Created

2024-08-07T21:57:13.967Z

Closed

2024-11-08T00:40:35.581Z

Updated

2024-11-08T00:40:35.686Z

Milestone

6.2

Labels

rtems::score, scan::coverity

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5107

Merges

1

Summary

Coverity CID 1512527

Coverity spotted this where time_t variables/structure elements are assigned to uint32_t. Notice that the return type is uint32_t which propagates to callers of this such as rtems_timespec_add_to().

46 uint32_t _Timespec_Add_to(
47  struct timespec       *time,
48  const struct timespec *add
49)
50{

CID 1512527: (#1 of 1): Use of 32-bit time_t (Y2K38_SAFETY)
1. store_truncates_time_t: A time_t value is stored in an integer with too few bits to accommodate it. The expression add->tv_sec is cast to uint32_t.
51  uint32_t seconds = add->tv_sec;

Steps to reproduce

Author: Joel Sherrill

2024-08-07T21:57:14.149Z

assigned to @joel

Author: Joel Sherrill

2024-08-07T22:01:06.155Z

mentioned in merge request !175

4964 - rtems-test can hang indefinitely

Id

4964

State

closed

Type

ISSUE

Author

Kinsey Moore

Assignee(s)

Trac Migrate

Created

2023-11-07T15:20:21.000Z

Updated

2023-11-07T21:06:51.000Z

Milestone

6.2

Labels

priority::low, resolution::duplicate, tickettype::defect, tool::test, version::6

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4964

Merges

0

When using the RTEMS automated tester configured with TFTP, there is a state that can occur in which the tester never times out a test. This was discovered when testing with the AArch64 Xilinx ZynqMP BSP where the board did not actually power on even though it was instructed to do so. This left the tester running the TFTP server waiting more than 4 full days (left to run over a long weekend) for the target to start without progressing to the next test.

The failure to start on the target side was due to a missing minimum settling time between off and on states that is apparently influenced by the environment.

Author: Chris Johns

2023-11-07T20:52:08.000Z

Can you please try https://lists.rtems.org/pipermail/devel/2023-October/076519.html ?

Looks like I forgot to push it.

Author: Chris Johns

2023-11-07T21:06:51.000Z

  • Resolution set to ~”duplicate”

  • Status changed from new to closed

This is a duplicate of #4959

5284 - Backport mvme3100 fixes to 6 (!541) (opened)

Id

5284

State

opened

Type

ISSUE

Author

Jeremy Lorelli

Created

2025-06-30T01:03:53.061Z

Updated

2025-06-30T14:56:00.427Z

Milestone

6.2

Labels

arch:powerpc, backport

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5284

Merges

0

Summary

Backport !541 to RTEMS 6, once it’s merged.

Pre-set options

Author: Jeremy Lorelli

2025-06-30T01:04:28.988Z

mentioned in merge request !541

Author: Gedare Bloom

2025-06-30T14:54:49.549Z

changed type from task to issue

Author: Gedare Bloom

2025-06-30T14:56:00.396Z

added rtems#10 as parent epic

5273 - Backport libdebugger setjmp fix to 6 branch (opened)

Id

5273

State

opened

Type

ISSUE

Author

Kinsey Moore

Assignee(s)

Kinsey Moore

Created

2025-06-18T18:52:51.524Z

Updated

2025-06-19T22:52:53.491Z

Milestone

6.2

Labels

arch:aarch64, cpukit::debugger

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5273

Merges

0

The following discussion from !523 should be addressed:

  • [] @opticron started a discussion:

    This needs to be backported to 6.

Author: Kinsey Moore

2025-06-18T18:52:52.066Z

assigned to @opticron

Author: Kinsey Moore

2025-06-18T18:52:53.254Z

Author: Kinsey Moore

2025-06-18T18:55:47.388Z

mentioned in merge request !524

Author: Kinsey Moore

2025-06-19T22:52:52.933Z

mentioned in commit 3d8b56f10c9cabe8cc731ada636af59f71e8e10b

5271 - Backport libdebugger TLS support to the RTEMS 6 branch (opened)

Id

5271

State

opened

Type

ISSUE

Author

Kinsey Moore

Assignee(s)

Kinsey Moore

Created

2025-06-17T19:15:41.599Z

Updated

2025-06-17T19:19:46.332Z

Milestone

6.2

Labels

arch:aarch64, cpukit::debugger

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5271

Merges

0

The following discussion from !517 should be addressed:

  • [] @opticron started a discussion:

    This needs to be backported to the 6 branch.

Author: Kinsey Moore

2025-06-17T19:15:42.193Z

assigned to @opticron

Author: Kinsey Moore

2025-06-17T19:15:42.692Z

Author: Kinsey Moore

2025-06-17T19:19:46.270Z

mentioned in merge request !518

5216 - Deprecate powerpc/mvme5500 in favor of powerpc/beatnik (opened)

Id

5216

State

opened

Type

ISSUE

Author

Gedare Bloom

Assignee(s)

Gedare Bloom

Created

2025-02-14T22:36:47.150Z

Updated

2025-05-08T23:19:02.124Z

Milestone

6.2

Labels

arch:powerpc, bsp

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5216

Merges

0

The beatnik primarily targets the mvme6100 but it also supports the mvme5500. This issue notices that the powerpc/mvme5500 is deprecated in the 6 release series and will be removed in 7.

Author: Gedare Bloom

2025-02-14T22:36:47.351Z

cloned from #4160

Author: Gedare Bloom

2025-02-14T22:36:47.239Z

assigned to @gedare

Author: Gedare Bloom

2025-02-14T22:38:04.310Z

changed title from {-Obsolete -}mvme5500 in favor of {-B-}eatnik to {+Deprecate powerpc/+}mvme5500 in favor of {+powerpc/b+}eatnik

Author: Gedare Bloom

2025-02-14T22:38:04.339Z

changed the description

Author: Gedare Bloom

2025-02-14T22:38:13.212Z

Author: Gedare Bloom

2025-02-14T22:57:48.491Z

  • [x] add this to the release notes

  • [x] add a note in Beatnik documentation

Author: Gedare Bloom

2025-02-14T22:57:48.491Z

https://gitlab.rtems.org/rtems/rtos/rtems-release/-/merge_requests/25

Author: Gedare Bloom

2025-02-14T22:57:48.491Z

https://gitlab.rtems.org/rtems/docs/rtems-docs/-/merge_requests/153

Author: Gedare Bloom

2025-02-14T22:53:43.694Z

mentioned in commit gedare/rtems-docs@72286dba503c0879486b8877c2e88522b146bad0

Author: Gedare Bloom

2025-02-14T22:54:05.231Z

mentioned in merge request rtems/docs/rtems-docs!153

Author: Gedare Bloom

2025-02-20T23:18:23.121Z

mentioned in commit gedare/rtems-docs@3ec35416774b6a7baf9106ebc0ac4a935e84cb48

Author: Amar Takhar

2025-05-08T23:16:06.202Z

mentioned in commit amar/rtems-docs@38a25aad78332ef1f507620040c3e8541a1ab048

Author: Amar Takhar

2025-05-08T23:19:01.833Z

mentioned in commit gedare/rtems-docs@701f0230e962b7d559dd7bb55b4443c37b82d67f

5236 - Runtime symbols loading is broken (opened)

Id

5236

State

opened

Type

ISSUE

Author

Chris Johns

Assignee(s)

Chris Johns

Created

2025-04-01T00:58:33.568Z

Updated

2025-04-01T13:51:00.306Z

Milestone

6.2

Labels

cpukit::dl, tool::rtems-tools

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5236

Merges

0

Summary

Run time symbol loading from an object file is broken. The change to track dependencies added support to check the origin of a symbol to track dependencies. Runtime loading of symbols requires the symbol rtems_rtl_base_sym_global_add be in the symbol table. Loading an symbol object file causes a constrictor attribute function to be run and that calls rtems_rtl_base_sym_global_add adding the base image global symbols. Currently attempting to load a symbol object file results in an unresolved external to rtems_rtl_base_sym_global_add because the symbols is inserted into the global symbol table and not added to the base image’s global symbols.

Also rtems-syms does not correctly export the needed TLS data.

Author: Chris Johns

2025-04-01T00:58:33.714Z

cloned from #5234

Author: Chris Johns

2025-04-01T00:58:33.637Z

assigned to @chris

Author: Chris Johns

2025-04-01T01:34:24.159Z

mentioned in merge request !461

Author: Kinsey Moore

2025-04-01T13:51:00.525Z

5222 - RTEMS Priority range API change (regression) (opened)

Id

5222

State

opened

Type

ISSUE

Author

Chris Johns

Assignee(s)

Chris Johns

Created

2025-02-27T21:44:09.559Z

Updated

2025-03-05T13:15:56.986Z

Milestone

6.2

Labels

api

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5222

Merges

0

The following discussion from !436 should be addressed:

  • [] @chris started a discussion

    Yes I could add CONFIGURE_MAXIMUM_PRIORITY with 255 to resolve the problem in my application. Why should I? The code base that brought this problem to my attention was originally developed on RTEMS 4 on a Zynq and the user wants to use SMP?

    My investigation to understand the problem has raised a number of concerns and I do not think this MR is the place to discuss them. The MR may in the end be a suitable resolution however we need to first have a wider discussion.

    I believe the changing of the priority range is a _regression_ with respect to the historical user interfaces until we decide otherwise. I do not remember a specific discussion about the range changing in regards to this context, the effects, other possible options or how we convey this to users? I believe a number of separate changes over a period of time have come together to bring about my concerns. Each piece on its own makes sense and seems reasonable however together there are issues. We need to respect our users, existing code and the need to make things as simple as possible simple configurations.

    I am also using this specific example to bring about a policy change. API changes needs to be announced and a specific discussion happen for the change to accepted. Approval and merging of changes in isolation does not mean an acceptable of change. If this happens we need to discuss the impact, look at solutions I have labelled this MR API however I wonder if we need an api-change label as well?

    A discourse topic discussing this issue can be found at https://users.rtems.org/t/scheduler-maximum-regression-in-rtems-6/78

Author: Chris Johns

2025-02-27T21:44:09.713Z

assigned to @chris

Author: Chris Johns

2025-02-27T21:45:07.643Z

changed the description

Author: Chris Johns

2025-02-28T02:19:24.550Z

changed the description

Author: Sebastian Huber

2025-03-05T13:15:56.927Z

The default SMP scheduler is an EDF scheduler. This has other implications. For example, the use of rate-monotonic objects changes drastically. If you want maximum backward compatibility, the default SMP scheduler could be changed back to deterministic priority.

5212 - machine/_timecounter.h is missing _Timecounter_Getboottime(_tvp) (opened)

Id

5212

State

opened

Type

ISSUE

Author

Chris Johns

Assignee(s)

Chris Johns

Created

2025-02-11T22:24:18.786Z

Updated

2025-02-11T22:27:23.625Z

Milestone

6.2

Labels

rtems::kernel

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5212

Merges

0

The machine/_kernel_time.h header has:

#define        getboottime(_tvp) _Timecounter_Getboottime(_tvp)
#define        getboottimebin(_bt) _Timecounter_Getboottimebin(_bt)

however machine/_timecounter.h does not have a prototype for _Timecounter_Getboottime and GCC 14 now generates an error.

Author: Chris Johns

2025-02-11T22:24:18.920Z

cloned from #5211

Author: Chris Johns

2025-02-11T22:24:18.850Z

assigned to @chris

Author: Chris Johns

2025-02-11T22:24:31.498Z

Author: Chris Johns

2025-02-11T22:25:03.138Z

GCC 13 does not complain but the issue is still present.

Author: Chris Johns

2025-02-11T22:27:23.402Z

mentioned in merge request !416

5165 - Use of pkg-config –libs is unreliable (opened)

Id

5165

State

opened

Type

ISSUE

Author

Sebastian Huber

Assignee(s)

Sebastian Huber

Created

2024-11-28T12:58:42.398Z

Updated

2025-02-11T06:26:21.717Z

Milestone

6.2

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5165

Merges

0

Summary

I noticed a strange issue with pkg-config for a BSP with special linker flags:

https://github.com/pkgconf/pkgconf/issues/371

I think we should provide the linker flags also through an LDFLAGS variable.

Author: Sebastian Huber

2024-11-28T12:58:42.511Z

assigned to @sebhub

Author: Sebastian Huber

2024-11-28T14:26:59.811Z

mentioned in merge request !335

Author: Sebastian Huber

2024-11-28T14:28:04.148Z

mentioned in merge request !336

Author: Gedare Bloom

2024-12-04T21:39:42.250Z

Author: Sebastian Huber

2024-12-05T03:02:18.776Z

cloned to #5169

Author: Chris Johns

2024-12-22T03:37:31.386Z

Author: Chris Johns

2025-02-11T05:34:34.959Z

This change breaks libbsd and I suspect more. See https://gitlab.rtems.org/rtems/pkg/rtems-libbsd/-/issues/38 for details.

Author: Chris Johns

2025-02-11T05:36:33.803Z

The MR needs to be revert it.

Author: Sebastian Huber

2025-02-11T05:38:22.683Z

mentioned in commit e36ba91110724b5cc8a9e07659d98d0bcb96e4d4

Author: Sebastian Huber

2025-02-11T05:38:56.744Z

I would first like to investigate why this change causes something to break. The LDFLAGS were previously not visible by pkg-config.

Author: Sebastian Huber

2025-02-11T06:26:22.134Z

It seems the removal of the Ldflags: is the issue here. This part of the patch needs to be reverted. The rtems_waf package uses the option --ldflags which is not documented by pkg-config --help.

Author: Chris Johns

2025-02-11T06:26:22.134Z

I suggest this change is reverted and then a new change can created, review and merged. Any change has to build rtems_waf base packages such as libbsd to be approved.

Author: Sebastian Huber

2025-02-11T06:26:22.134Z

Why don’t you give people a business day to fix this?

Author: Chris Johns

2025-02-11T06:26:22.134Z

That depends on the fix and how long it takes to be reviewed and merged. A revert works, I have tested it so it lets LibBSD build which is important. I am a little unsure what the problem is with a revert?

Author: Sebastian Huber

2025-02-11T06:26:22.134Z

I am already working on a patch.

Author: Chris Johns

2025-02-11T06:26:22.134Z

Sure and thanks. I am only providing a way to solve this breakage. It would helpful if you could please explain your position of no reverts? Gitlab has a Revert button because it is useful and used so if a change breaks something it is helpful.

Author: Sebastian Huber

2025-02-11T06:26:22.134Z

In the past, patches were not reverted this quickly.

Author: Amar Takhar

2025-02-11T06:27:01.628Z

These should be reverted because it caused the breakage it’s a good way to record the issue in GitLab. New MRs should come with the alternate change.

The reason we moved to GitLab is to make these processes easy we’re not in a race I appreciate you wanting more time but the policy should always be to revert ASAP when we see breakage and have a new change in come via a new MR this is an easier way to track changes. This also means that any future changes can be properly considered without being under pressure due to current breakage.

Author: Sebastian Huber

2025-02-11T06:26:22.134Z

Please go ahead, I will have a look at it in a couple of days.

Author: Chris Johns

2025-02-11T05:50:43.935Z

mentioned in merge request !413

Author: Amar Takhar

2025-02-11T05:58:44.327Z

mentioned in merge request !414

5184 - cpukit/libmisc/capture: rtems_capture_flush incorrectly clears the RTEMS_CAPTURE_INIT flag (opened)

Id

5184

State

opened

Type

ISSUE

Author

Gedare Bloom

Assignee(s)

Gedare Bloom

Created

2025-01-20T23:56:21.515Z

Updated

2025-02-11T05:38:23.408Z

Milestone

6.2

Labels

cpukit::misc

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5184

Merges

2

The following discussion from !337 should be addressed:

  • [] @gedare started a discussion:

    The RTEMS_CAPTURE_OVERFLOW is an overflow flag for each CPU, and its value is the same as RTEMS_CAPTURE_INIT. Executing rtems_capture_flush will set the RTEMS_CAPTURE_INIT flag to 0 in the global flags.

Author: Gedare Bloom

2025-01-20T23:56:21.693Z

assigned to @gedare

Author: Gedare Bloom

2025-01-20T23:56:22.093Z

Author: Gedare Bloom

2025-01-21T00:00:30.526Z

mentioned in merge request !361

Author: Gedare Bloom

2025-01-21T02:25:29.025Z

Author: Zhaoyue Wang

2025-02-11T05:38:22.745Z

mentioned in commit 603c168a0ba828efc949b398d3623ebc9a0aafa3

5206 - Back-port “wscript: Make builds with tar archives reproducible” (opened)

Id

5206

State

opened

Type

ISSUE

Author

Gedare Bloom

Assignee(s)

Gedare Bloom

Created

2025-02-07T20:41:02.457Z

Updated

2025-02-07T20:41:02.457Z

Milestone

6.2

Labels

backport

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5206

Merges

0

The following discussion from !405 should be addressed:

  • [] @frank_k started a discussion

    What do I need to do to get this patch also into RTEMS 6?

Author: Gedare Bloom

2025-02-07T20:41:02.632Z

assigned to @gedare

Author: Gedare Bloom

2025-02-07T20:41:03.799Z

5202 - Termios: cannot set all baud rates with rtems_termios_set_best_baud() (opened)

Id

5202

State

opened

Type

ISSUE

Author

Gedare Bloom

Assignee(s)

Jan Sommer

Created

2025-02-03T19:00:52.672Z

Updated

2025-02-06T03:35:43.265Z

Milestone

6.2

Labels

cpukit

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5202

Merges

2

Summary

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: Gedare Bloom

2025-02-03T19:00:52.815Z

cloned from #5162

Author: Gedare Bloom

2025-02-03T19:00:52.746Z

assigned to @thesummer

Author: Gedare Bloom

2025-02-03T19:01:07.472Z

Author: Gedare Bloom

2025-02-03T19:05:34.225Z

mentioned in merge request !381

Author: Jan Sommer

2025-02-06T03:35:43.024Z

mentioned in commit 9641e1e97d8195d567a6218228ef0f0f2d7fdc25

5008 - Create an ALUMNI file for MAINTAINERS in lieu of CODEOWNERS (opened)

Id

5008

State

opened

Type

ISSUE

Author

Amar Takhar

Assignee(s)

Chris Johns, Gedare Bloom, Joel Sherrill

Created

2024-05-02T07:17:35.160Z

Updated

2025-01-31T18:56:38.667Z

Milestone

6.2

Labels

doc

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5008

Merges

0

Summary

We have some alumni in the MAINTAINERS file we want to put somewhere in the docs? But it’s confusing to have both let’s make sure that the CODEOWNERS is the canonical version and anything that needs to be carried in docs gets done so.

We can have an ALUMNI file plenty of projects have that and I support this method since it’s carried in the source I don’t think they should need to go seek somewhere else.

Steps to reproduce

Author: Amar Takhar

2024-05-02T07:17:35.264Z

assigned to @chris, @gedare, and @joel

Author: Gedare Bloom

2024-12-04T21:40:37.675Z

Author: Gedare Bloom

2025-01-31T18:56:38.719Z

changed title from {-Remove-} MAINTAINERS in lieu of CODEOWNERS to {+Create an ALUMNI file for+} MAINTAINERS in lieu of CODEOWNERS

5187 - Backport 6.2: bsps/shared: NS16550 driver updates the line control register during operation (opened)

Id

5187

State

opened

Type

ISSUE

Author

Jan Sommer

Assignee(s)

Jan Sommer

Created

2025-01-23T14:04:11.055Z

Updated

2025-01-23T14:26:27.714Z

Milestone

6.2

Labels

device::serial, version::6

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5187

Merges

0

Backport of https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5179

Summary

Calling tcsetattr even with only changes to the timeout conditions will reset the line control register temporary which can corrupt ongoing data transfers.

Steps to reproduce

  • Continuously write data to the serial port (ideally with high baud rates like 921600 bps).

  • Change the timing settings like VMIN or VTIME

  • Receive corrupted data

Expected behaviour

  • Data transfer is not corrupted.

Pre-set options

Author: Jan Sommer

2025-01-23T14:04:37.307Z

Author: Jan Sommer

2025-01-23T14:12:26.017Z

@opticron I could assign the epic via the quick action, but not the milestone or labels. Could please do it and also assign the issue to me?

Author: Kinsey Moore

2025-01-23T14:12:26.017Z

Done!

Author: Kinsey Moore

2025-01-23T14:11:07.723Z

assigned to @thesummer

Author: Jan Sommer

2025-01-23T14:26:27.685Z

mentioned in merge request !365

4956 - Deadlock caused by locking inversion in JFFS2 (opened)

Id

4956

State

opened

Type

ISSUE

Author

Kinsey Moore

Assignee(s)

Kinsey Moore

Created

2023-09-20T16:58:43.000Z

Updated

2024-12-04T21:40:36.315Z

Milestone

6.2

Labels

priority::normal, tickettype::defect

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4956

Merges

0

When the code for delayed writes was added to support JFFS2 on NAND, it introduced a possible locking inversion when managing the delayed write work queue.

This has been partially addressed by fa85760c99a72b8186c70c896b98efe0d7cde2b6, but there are other issues with this code that need to be addressed as well.

First is that when not compiling with RTEMS_DEBUG, nodes are not automatically set as off the chain upon extraction and this behavior is depended upon.

Second is that protected (ISR-locked) chain calls are used when they are not necessary due to already being locked.

Third is that the bug fixed by the referenced commit needs a test that verifies the fix.

Author: Trac Migrate

2023-09-26T00:41:07.000Z

Hey i’m interested working on this ticket would the nodes be set off only if

Author: Kinsey Moore

2023-09-26T13:16:46.000Z

Hey, thanks for the interest. I actually have a patch on the mailing list that just got approved for fixing this, so it should be going into the codebase shortly. I still need to write a test that produces the original issue, though.

Author: Trac Migrate

2023-09-26T13:38:00.000Z

In [changeset:”99c637fbd973a3d2f6e5adf38aac8f3f588cbb7e/rtems” 99c637f/rtems]:

cpukit/jffs2: Avoid use of off-chain semantics

This reworks the JFFS2 delayed work queue to avoid use of
on-chain/off-chain semantics since they vary in behavior under
RTEMS_DEBUG and are not guaranteed to be safe to use in SMP systems.
This adds all delayed work structs to the chain on FS init and does not
remove them until umount.

Updates #4956

Author: Kinsey Moore

2024-02-16T00:35:11.000Z

  • Owner set to @kinsey

  • Status changed from new to assigned

Author: Kinsey Moore

2024-05-02T23:19:35.303Z

A baseline set of tests has been added to the RTEMS testsuite to test JFFS2 on a simulated NAND device. This baseline set of tests does not trigger the original condition that necessitated this ticket and I have thus far been unable to trigger the deadlock from a test with rolled-back code.

Author: Kinsey Moore

2024-05-17T02:59:17.993Z

changed the description

Author: Gedare Bloom

2024-12-04T21:40:37.334Z

4895 - Add support for RTEMS cache API to MicroBlaze (opened)

Id

4895

State

opened

Type

ISSUE

Author

Trac Migrate

Assignee(s)

Trac Migrate

Created

2023-04-12T03:23:57.000Z

Updated

2024-12-04T21:40:36.095Z

Milestone

6.2

Labels

bsp, priority::normal, tickettype::enhancement, version::6

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4895

Merges

0

Original author: Alex

Some cache management functions have already been added to MicroBlaze. The functions are declared in bsps/microblaze/microblaze_fpga/include/bsp.h. These should instead be called by the wrapper functions of the RTEMS cache management API from bsps/shared/cache/cacheimpl.h to match the API used in other BSPs. The cache management functions should be defined in bsps/microblaze/shared/cache/cache.c.

Author: Joel Sherrill

2023-06-22T20:54:27.000Z

Original author: Alex

Alex .. Is this required for 6.1 or can the milestone be moved to 6.2, 7.1, or indefinite? Is it in your work queue?

Author: Trac Migrate

2023-09-20T15:08:40.000Z

Original author: Alex

Replying to Joel Sherrill:

Alex .. Is this required for 6.1 or can the milestone be moved to 6.2, 7.1, or indefinite? Is it in your work queue?

This can be moved to 6.2. It’s still on the backlog.

Author: Kinsey Moore

2023-09-21T13:20:48.000Z

Original author: Alex

  • Milestone changed from %”6.1” to %”6.2”

Author: Chris Johns

2023-09-21T23:45:16.000Z

Original author: Alex

Replying to Alex White:

Replying to Joel Sherrill:

Alex .. Is this required for 6.1 or can the milestone be moved to 6.2, 7.1, or indefinite? Is it in your work queue?

This can be moved to 6.2. It’s still on the backlog.

Does this change mean an cache API change for the Microblaze?

Author: Gedare Bloom

2024-12-04T21:40:36.178Z

changed the description

Author: Gedare Bloom

2024-12-04T21:40:37.155Z

4675 - sleep should be a thread cancellation point (opened)

Id

4675

State

opened

Type

ISSUE

Author

Trac Migrate

Assignee(s)

Kinsey Moore

Created

2022-07-07T10:17:28.000Z

Updated

2024-12-04T21:40:35.983Z

Milestone

6.2

Labels

api::posix, priority::normal, tickettype::defect, version::6

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4675

Merges

0

Original author: aoliva

GCC has worked around, in the libstdc++ testsuite, the fact that nanosleep (as well as sleep and clock_nanosleep) should be thread cancellation points, per POSIX, but RTEMS may want to make them so. https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597003.html

(I haven’t checked that other functions that should be thread cancellation points are, I only noticed that this one wasn’t, and decided to file this ticket because for other issues in which I explicitly identified RTEMS I got a request to do so)

Author: Trac Migrate

2022-07-07T12:40:48.000Z

Original author: aoliva

Thanks for reporting the issue. I think we have currently no cancellation points in RTEMS at all. I think this is intentional, so I would mark this bug as WONTFIX.

Author: Joel Sherrill

2023-03-18T17:43:07.000Z

Original author: aoliva

Do you have a test to show something isn’t right? sleep() and nanonsleep() ultimately call clock_nanosleep() and the requested blocking state is “STATES_WAITING_FOR_TIME | STATES_INTERRUPTIBLE_BY_SIGNAL”

https://git.rtems.org/rtems/tree/cpukit/posix/src/clocknanosleep.c#n77

RTEMS state bits consist of the type of object is being blocked on and attributes such as interruptible. It has been this way for a LONG time.

As a random thought, if you don’t build RTEMS with POSIX enabled, then POSIX signals are disabled and then this likely wouldn’t work.

Author: Joel Sherrill

2023-03-18T17:43:24.000Z

Original author: aoliva

  • Milestone set to %”6.1”

Author: Trac Migrate

2023-04-22T05:32:10.000Z

Original author: aoliva

The unpatched libstdc++ testcase is a test that shows the problem. An explicit pthread_testcancel shouldn’t be needed. Functions that are cancellation points should (as-if) call it implicitly.

Author: Joel Sherrill

2023-06-22T20:52:53.000Z

Original author: aoliva

  • Owner set to @kinsey

  • Status changed from new to assigned

Author: Amar Takhar

2024-05-17T00:42:51.649Z

Hi there Kinsey can this be moved to %6.2?

Author: Amar Takhar

2024-05-17T01:08:02.038Z

changed the description

Author: Kinsey Moore

2024-05-17T02:53:23.124Z

@joel Do you have opinions on this? It’s in my backlog of things to get to, but I have many things that come before it.

Author: Amar Takhar

2024-05-17T03:23:52.870Z

@opticron this was already moved to %6.2 :) .. Joel asked to move it.

Author: Kinsey Moore

2024-05-17T03:23:52.870Z

I saw that it got moved, but not the rationale. I was driving at the time.

Author: Amar Takhar

2024-05-17T03:23:52.870Z

Ah, makes sense I should have noted that it was Joel that asked, too.

Author: Gedare Bloom

2024-12-04T21:40:37.120Z

4364 - rtems-test Fails to list failed tests to user (opened)

Id

4364

State

opened

Type

ISSUE

Author

Joel Sherrill

Assignee(s)

Chris Johns

Created

2021-03-28T15:51:47.000Z

Updated

2024-12-04T21:40:35.871Z

Milestone

6.2

Labels

priority::normal, tickettype::defect, tool::rtems-source-builder, version::6

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4364

Merges

0

rtems-test does not report the set of failed tests to the user at the conclusion of its run. It only gives a summary by category. They ARE in the log file. I assume this is a minor issue now that I have spotted the pattern.

I assume this also applies to 5 but I spotted it on 6 during the recent heavy round of manual testing.

Author: Amar Takhar

2024-05-17T02:02:50.798Z

Joel are you OK with this being moved to %6.2 Since there is already a solution this is more of an ease-of-use feature.

Author: Joel Sherrill

2024-05-17T13:46:01.611Z

It is not an ease of use feature. If interactive, you do not get the list of failures unless you enable logging.

I don’t mind moving the milestone though. This has been sitting here for 3 years already.

Author: Amar Takhar

2024-05-17T15:09:16.482Z

changed the description

Author: Gedare Bloom

2024-12-04T21:40:36.939Z

4292 - rtems-rfs-bitmaps.c: Useless call (CID 1399749) (opened)

Id

4292

State

opened

Type

ISSUE

Author

Joel Sherrill

Assignee(s)

Chris Johns

Created

2021-03-03T21:04:09.000Z

Updated

2024-12-04T21:40:35.770Z

Milestone

6.2

Labels

filesystem::rfs, priority::normal, tickettype::defect, version::6

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4292

Merges

0

Coverity Scan spotted this in rtems-rfs-bitmaps.c as CID 1399749). On the face of it, Scan appears to be correct but this issue should be reviewed by the original author of this code.

}
623    else
624    {
625      bits      = *map;
626      available = rtems_rfs_bitmap_element_bits ();
627    }
628
629    if (rtems_rfs_bitmap_match (bits, RTEMS_RFS_BITMAP_ELEMENT_SET))

CID 1399749 (#1 of 1): Useless call (USELESS_CALL)
side_effect_free: Calling rtems_rfs_bitmap_set(*search_map, bit) is only useful for its return value, which is ignored. [show details]
630      rtems_rfs_bitmap_set (*search_map, bit);
631    else
632    {

Author: Joel Sherrill

2021-03-03T21:04:21.000Z

  • Owner set to @chrisj

  • Status changed from new to assigned

Author: Chris Johns

2024-05-16T23:08:01.788Z

changed the description

Author: Chris Johns

2024-05-16T23:08:05.781Z

Please create merge request.

Author: Gedare Bloom

2024-12-04T21:40:37.082Z

4125 - Update wiki pages to reference waf not autoconf based build (opened)

Id

4125

State

opened

Type

ISSUE

Author

Joel Sherrill

Assignee(s)

Joel Sherrill

Created

2020-10-06T18:27:32.000Z

Updated

2024-12-04T21:40:35.664Z

Milestone

6.2

Labels

priority::normal, tickettype::defect, version::6

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4125

Merges

0

Since configure is a horrible thing to search for, I searched for “enable-rtems” in the wiki. The results are https://devel.rtems.org/search?q=enable-rtems&noquickjump=1&wiki=on and show about 20 pages that need review.

Some may be ok since they are historical on GSoC projects but others will need updating. Some are BSP pages which really should be converted to the Users Guide and updated.

We have an ongoing effort to reduce the wiki and some of these pages may be good candidates. Let’s use this as an excuse to do some clean up.

Author: Joel Sherrill

2020-10-06T18:27:51.000Z

  • Summary changed from Update wiki to reference waf to Update wiki pages to reference waf not autoconf based build

Author: Trac Migrate

2020-11-02T18:48:43.000Z

I don’t think this is a blocker to remove the old build system. The user manual is the source of reference.

Author: Chris Johns

2022-11-29T23:23:25.000Z

  • Owner set to @joel

  • Status changed from new to assigned

Author: Amar Takhar

2024-05-17T00:47:34.904Z

changed the description

Author: Amar Takhar

2024-05-17T00:47:37.779Z

Hi Joel since we have no more wiki what’s the alternate solution for this? Moving it to %6.2 since it’s not really related to %6.1 anymore.

Author: Gedare Bloom

2024-12-04T21:40:36.815Z

4095 - Remove doc from rtems-tools (opened)

Id

4095

State

opened

Type

ISSUE

Author

Chris Johns

Assignee(s)

Kinsey Moore

Created

2020-09-24T23:53:13.000Z

Updated

2024-12-04T21:40:35.559Z

Milestone

6.2

Labels

priority::normal, tickettype::task, tool, version::6

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4095

Merges

0

This directory is not used and needs to go. I will push the change directly to the repo to avoid the clutter a review would generate as most of the files and imported.

Author: Joel Sherrill

2022-03-03T22:54:55.000Z

Is this done? Easy to close?

Author: Joel Sherrill

2022-12-28T19:51:02.000Z

Please check if this can be closed.

Author: Gedare Bloom

2023-01-23T20:41:52.000Z

https://git.rtems.org/rtems-tools/tree/doc

Still exists.

Author: Joel Sherrill

2023-02-09T16:04:32.000Z

I think that much of the content in rtems-tools/doc is NOT in the Users Guide. The discussion of the RTEMS Tester in the Users Guide takes a different view and appears to never show how to use it which is the focus of much of this documentation. I don’t think this is a simple remove some files.

Author: Joel Sherrill

2023-06-22T21:21:57.000Z

  • Owner set to @kinsey

Author: Amar Takhar

2024-05-17T02:01:29.459Z

Can this be moved to %6.2?

Author: Kinsey Moore

2024-05-17T02:54:17.851Z

This is fine to move to %”6.2”.

Author: Kinsey Moore

2024-05-17T02:54:22.287Z

changed the description

Author: Gedare Bloom

2024-12-04T21:40:36.469Z

3230 - RSB does not report –rsb-file for patches correctly. (opened)

Id

3230

State

opened

Type

ISSUE

Author

Chris Johns

Assignee(s)

Chris Johns

Created

2017-11-12T04:45:41.000Z

Updated

2024-12-04T21:40:35.420Z

Milestone

6.2

Labels

priority::normal, tickettype::defect, tool::rtems-source-builder, version::5

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3230

Merges

0

The reports from the RSB do not report the --rsb-file option correctly.

Author: Chris Johns

2017-11-12T04:46:01.000Z

  • Status changed from assigned to accepted

Author: Chris Johns

2019-12-12T23:32:22.000Z

  • Milestone changed from %”5.1” to %”6.1”

Author: Amar Takhar

2024-05-17T01:59:37.817Z

changed the description

Author: Amar Takhar

2024-05-17T02:00:00.357Z

Moving to %6.2 since it’s been bumped once already.

Author: Gedare Bloom

2024-12-04T21:40:35.716Z

Merge Requests

548 - cpu/riscv: Add Smdbltrp extension compatibility to 6 branch

Id

548

State

merged

Merged by

Kinsey Moore

Merged at

2025-07-03T13:20:06.894Z

Created

2025-07-03T08:10:40.579Z

Updated

2025-07-03T13:20:06.437Z

Milestone

6.2

Labels

arch:riscv

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/548

Commit

e7fa90ab0ccd0566dd0b136c62aa729515c3b011

Summary

cpu/riscv: Add Smdbltrp extension compatibility

If the Double Trap Extension is implemented, the MDT bit of the mstatus (or mstatush in RV32) register will be set when a trap is to be taken.

The MIE (Machine Interrupt Enable) bit can only be set to 1 if the MDT bit is zero.

Thus, we need to clear MDT first if we want to enable interrupts when dispatching a thread.

MDT is also cleared in register a1 before restoring the interrupt frame as writing 1 to MDT will cause MIE to be set to 0. In RV64 this happens regardless of the value written to MIE in the same write.

In RV32, MDT is in the mstatush so we do not need to clear during restore as this register is not restored.

With this change all 60 SMP tests pass (compared to 20/60 before the fix). The tests have been run on hardware using two RV64 CPUs that implement the double trap extension.

Close #5288

(cherry picked from commit 19f12d2dca02da3072c0c31e2da281f6a447699e)

Author: Kinsey Moore

2025-07-03T13:11:23.395Z

approved this merge request

Author: Kinsey Moore

2025-07-03T13:11:30.083Z

enabled an automatic merge when all merge checks for e7fa90ab0ccd0566dd0b136c62aa729515c3b011 pass

Author: Joel Sherrill

2025-07-03T13:20:01.821Z

approved this merge request

537 - bsps/noelv: Backport polled mode console to 6

Id

537

State

merged

Merged by

Gedare Bloom

Merged at

2025-06-28T15:35:41.336Z

Created

2025-06-26T07:02:00.422Z

Updated

2025-06-28T15:36:37.701Z

Milestone

6.2

Labels

arch:riscv, backport

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/537

Commit

dd490c5c2d02e472c83b7052612b554e8b74358f

Summary

bsps/noelv: Fix using console in polled mode

Before, the console driver needed BSP_CONSOLE_USE_INTERRUPTS to be defined or it would not build. The intent was to use polled mode if the macro was equal to zero.

This change makes it so interrupt mode is used if the macro is defined and polled mode is used if the macro is not defined.

(cherry picked from commit 5e0a68d3ab6bedb16e465267310c59c25803b783)

Close #5283

Author: Joel Sherrill

2025-06-27T13:32:10.089Z

This needs an issue for the backport and the issue needs to be associated with the 6.2 release epic.

If that needs clarification, this is documented somewhere. Ask on Discord and hopefully someone can give you a pointer.

If you need help, ask on Discord.

Author: Matteo Concas

2025-06-27T13:32:10.089Z

I created issue #5283, but I can’t seem to add it to the 6.2 release epic or add labels to it. I guess only maintainers have these rights.

Author: Matteo Concas

2025-06-27T07:42:39.176Z

added 1 commit

  • dd490c5c - bsps/noelv: Fix using console in polled mode

Compare with previous version

Author: Matteo Concas

2025-06-27T07:43:20.752Z

changed the description

Author: Kinsey Moore

2025-06-27T13:32:10.120Z

resolved all threads

Author: Kinsey Moore

2025-06-27T13:32:14.452Z

approved this merge request

Author: Gedare Bloom

2025-06-28T14:53:54.575Z

approved this merge request

532 - bsps/sparc/leon3: Backport GPTIMER timer index logic fix to 6

Id

532

State

merged

Merged by

Kinsey Moore

Merged at

2025-06-26T02:36:21.764Z

Assignee(s)

Matteo Concas

Created

2025-06-23T07:28:42.604Z

Updated

2025-06-26T02:36:21.748Z

Milestone

6.2

Labels

backport

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/532

Commit

d010f6ae8bc4e2ccfcc162b256e18ed61b71820d

Summary

bsps/sparc/leon3: Fix GPTIMER timer index logic

The old logic would lead to an error when multiprocessing was enabled and LEON3_GPTIMER_BASE was defined due to leon3_timer_core_index being undefined.

The new logic fixes this and keeps the same intent:

  • If multiprocessing is not enabled, the timer index is 0

  • If multiprocessing is enabled and LEON3_GPTIMER_BASE is defined, the timer index is twice the CPU boot index

  • If multiprocessing is enabled and LEON3_GPTIMER_BASE is not defined, we fallback to the old logic using the GPTIMER core index.

Author: Matteo Concas

2025-06-23T07:29:20.225Z

changed title from bsps/sparc/leon3: {-Fix-} GPTIMER timer index logic to bsps/sparc/leon3: {+Backport+} GPTIMER timer index logic{+ fix to 6+}

Author: Matteo Concas

2025-06-23T07:30:22.977Z

mentioned in merge request !514

Author: Gedare Bloom

2025-06-25T16:24:56.538Z

@matteo.concas please add closes #5281 to the commit message someone will have to manually close it also, after the backport

Author: Matteo Concas

2025-06-25T16:24:56.538Z

I have added “Close #5281” to the commit message.

Author: Gedare Bloom

2025-06-24T20:31:45.106Z

assigned to @matteo.concas

Author: Matteo Concas

2025-06-25T06:23:00.842Z

added 1 commit

  • d010f6ae - bsps/sparc/leon3: Fix GPTIMER timer index logic

Compare with previous version

Author: Gedare Bloom

2025-06-25T16:24:56.595Z

resolved all threads

Author: Gedare Bloom

2025-06-25T16:26:16.722Z

approved this merge request

Author: Joel Sherrill

2025-06-25T22:20:48.635Z

approved this merge request

Author: Kinsey Moore

2025-06-26T02:36:07.135Z

enabled an automatic merge when the pipeline for d010f6ae8bc4e2ccfcc162b256e18ed61b71820d succeeds

524 - cpukit/libdebugger: Prevent hang on memory access

Id

524

State

merged

Merged by

Kinsey Moore

Merged at

2025-06-19T22:52:50.613Z

Assignee(s)

Kinsey Moore

Reviewer(s)

Chris Johns

Created

2025-06-18T18:55:15.610Z

Updated

2025-06-19T22:52:53.452Z

Milestone

6.2

Labels

arch:aarch64, cpukit::debugger

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/524

Commit

3d8b56f10c9cabe8cc731ada636af59f71e8e10b

Summary

cpukit/libdebugger: Prevent hang on memory access

When memory is accessed by the remote debugging client, the access is sandboxed with setjmp/longjmp and appropriate exception handlers to prevent the attempted access from causing a failure of the debugger or otherwise altering execution. The existing implementation works as expected when the context executing the memory access and the exception context resulting from a failed access do not share a stack.

In the case of AArch64, a failed access when the debugger is already in exception context causes a re-entry into exception context where the machine state is pushed onto the same stack that was in use where the exception occurred. When setjmp is called inside a stack frame and the exception occurs outside that stack frame, the stack frame is unwound before the exception occurs and the exception entry overwrites the area previously occupied by the stack frame housing the setjmp and corrupting the link register that is stored there. After restoration of state using longjmp(), this corrupted link register information is loaded from the stack frame and undesired behavior occurs.

In the instance of this bug that was encountered, the corrupted link register contained an unaligned pointer which caused an unending cascade of prefetch abort exceptions presenting as a hard hang.

Closes #5273

Author: Kinsey Moore

2025-06-18T18:55:16.294Z

requested review from @chris

Author: Kinsey Moore

2025-06-18T18:55:16.326Z

assigned to @opticron

Author: Chris Johns

2025-06-19T22:36:09.770Z

approved this merge request

Author: Joel Sherrill

2025-06-19T22:48:37.839Z

approved this merge request

354 - score: Fix RTEMS_DEBUG build

Id

354

State

merged

Merged by

Kinsey Moore

Merged at

2025-01-08T13:31:58.965Z

Assignee(s)

Sebastian Huber

Created

2025-01-08T05:42:37.595Z

Updated

2025-05-09T00:10:25.214Z

Milestone

6.2

Labels

rtems::score

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/354

Commit

34ba74f4f492030ea33fc23adfd21e20959ba9f8

Summary

score: Fix RTEMS_DEBUG build

Close #5159.

Author: Sebastian Huber

2025-01-08T05:42:37.873Z

assigned to @sebhub

Author: Chris Johns

2025-01-08T05:43:50.581Z

approved this merge request

Author: Kinsey Moore

2025-01-08T13:31:38.056Z

approved this merge request

416 - machine/timecounters: Add _Timecounter_Getboottime, _Timecounter_Getboottimebin decls

Id

416

State

merged

Merged by

Kinsey Moore

Merged at

2025-05-08T22:38:11.262Z

Assignee(s)

Chris Johns

Created

2025-02-11T22:27:17.904Z

Updated

2025-05-08T22:38:15.309Z

Milestone

6.2

Labels

rtems::kernel

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/416

Commit

6335d7e48a692e4c4fe0577b6bba44ff0f64aefc

Summary

Add _Timecounter_Getboottime, _Timecounter_Getboottimebin decls

Closes #5212

Author: Chris Johns

2025-02-11T22:27:18.157Z

assigned to @chris

Author: Kinsey Moore

2025-05-08T22:36:28.879Z

This fails the commit message line length checks.

Author: Chris Johns

2025-05-08T22:36:01.285Z

added 1 commit

  • 993962be - machine/timecounters: Add missing _Timecounter_ decls

Compare with previous version

Author: Joel Sherrill

2025-05-08T22:36:28.914Z

resolved all threads

Author: Joel Sherrill

2025-05-08T22:36:37.023Z

approved this merge request

Author: Kinsey Moore

2025-05-08T22:36:54.367Z

approved this merge request

Author: Kinsey Moore

2025-05-08T22:37:04.928Z

added 4 commits

  • 993962be…f769b20c - 3 commits from branch rtems/rtos:6

  • 328e83ec - machine/timecounters: Add missing _Timecounter_ decls

Compare with previous version

Author: Chris Johns

2025-05-08T22:37:32.553Z

added 1 commit

  • 6335d7e4 - machine/timecounters: Add missing _Timecounter_ decls

Compare with previous version

461 - cpukit/libdl: Fix loading symbols from an object file at runtime

Id

461

State

merged

Merged by

Amar Takhar

Merged at

2025-04-04T00:06:34.500Z

Assignee(s)

Chris Johns

Created

2025-04-01T01:34:14.150Z

Updated

2025-04-04T00:06:36.822Z

Milestone

6.2

Labels

cpukit::dl, tool::rtems-tools

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/461

Commit

f769b20c98e48c4351c540ac53c443acf64cd6b1

Summary

cpukit/libdl: Fix loading symbols from an object file at runtime

  • Assume a relocation record with a symbol name with a length of 0 is resolved. ARM seems to create a symbol with no name for R_ARM_V4BX relocation records.

  • Move the addition of the rtems_rtl_base_sym_global_add symbol to the global symbol table to the weak rtems_rtl_base_global_syms_init call. If symbols are embedded the support for runtime loading symbols is over loaded. This change is required so the base object has a valid global symbol table attached to track dependencies.

Fixes #5236

Author: Chris Johns

2025-04-01T01:34:14.397Z

assigned to @chris

Author: Kinsey Moore

2025-04-03T23:01:59.004Z

approved this merge request

Author: Amar Takhar

2025-04-04T00:06:28.081Z

approved this merge request

459 - Backport “spec: Install missing header files for GRLIB and SPARC” to 6 branch

Id

459

State

merged

Merged by

Joel Sherrill

Merged at

2025-03-26T16:50:31.035Z

Created

2025-03-26T16:48:45.767Z

Updated

2025-03-26T16:50:33.271Z

Milestone

6.2

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/459

Commit

9dae9f5fe858dbd556ebd2f529035f8c63824dca

Backport commit spec: Install missing header files for GRLIB and SPARC on main to 6 branch.

Closes issue #5232

Author: Kinsey Moore

2025-03-26T16:49:31.177Z

approved this merge request

Author: Joel Sherrill

2025-03-26T16:50:20.843Z

approved this merge request

413 - Revert “build: Provide LDFLAGS for pkg-config”

Id

413

State

merged

Merged by

Kinsey Moore

Merged at

2025-02-11T13:51:35.086Z

Assignee(s)

Chris Johns

Created

2025-02-11T05:43:37.231Z

Updated

2025-02-11T13:51:37.304Z

Milestone

6.2

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/413

Commit

87bf49b7156b9ddf45c218e5d4fa01f27b283db7

Summary

Revert “build: Provide LDFLAGS for pkg-config”

This reverts commit e36ba91110724b5cc8a9e07659d98d0bcb96e4d4

Updates #5165

See https://gitlab.rtems.org/rtems/pkg/rtems-libbsd/-/issues/38

Author: Chris Johns

2025-02-11T05:50:43.847Z

changed the description

Author: Chris Johns

2025-02-11T05:50:43.893Z

assigned to @chris

Author: Chris Johns

2025-02-11T05:52:05.406Z

changed the description

Author: Amar Takhar

2025-02-11T05:55:01.814Z

approved this merge request

Author: Kinsey Moore

2025-02-11T13:51:20.391Z

approved this merge request

345 - bsp/qoriq: Ignore spurious interrupts

Id

345

State

merged

Merged by

Kinsey Moore

Merged at

2025-02-07T23:20:29.334Z

Assignee(s)

Sebastian Huber

Created

2024-12-06T10:22:28.402Z

Updated

2025-02-07T23:20:33.215Z

Milestone

6.2

Labels

arch:powerpc, backport

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/345

Commit

e421c922a87842f0613a269054acd041e46c91cd

Summary

bsp/qoriq: Ignore spurious interrupts

For example, with edge triggered external interrupts we may see spurious interrupts. Ignore them instead of issuing a fatal error.

Use eieio to synchronize access to the IACK and EOI registers.

Use a loop to immediately services the next pending interrupt without having to go through the exception epiloge and prologue.

Close #5173.

Author: Sebastian Huber

2024-12-06T10:22:28.560Z

assigned to @sebhub

Author: Gedare Bloom

2024-12-06T16:10:09.706Z

approved this merge request

Author: Kinsey Moore

2024-12-06T16:19:36.472Z

added 2 commits

  • a357119b - 1 commit from branch rtems/rtos:6

  • 81ed4b2d - bsp/qoriq: Ignore spurious interrupts

Compare with previous version

Author: Kinsey Moore

2025-02-07T22:57:58.139Z

This needs the same fix as the other MR.

Author: Gedare Bloom

2025-02-07T23:17:29.509Z

changed this line in version 6 of the diff

Author: Kinsey Moore

2024-12-06T16:20:26.526Z

requested changes

Author: Gedare Bloom

2025-02-03T18:59:36.917Z

unapproved this merge request

Author: Kinsey Moore

2025-02-06T23:49:46.426Z

added 9 commits

  • 81ed4b2d…9641e1e9 - 8 commits from branch rtems/rtos:6

  • 70cb4a1c - bsp/qoriq: Ignore spurious interrupts

Compare with previous version

Author: Kinsey Moore

2025-02-07T22:56:47.362Z

added 3 commits

  • 70cb4a1c…e36ba911 - 2 commits from branch rtems/rtos:6

  • f1e807b2 - bsp/qoriq: Ignore spurious interrupts

Compare with previous version

Author: Kinsey Moore

2025-02-07T22:57:45.129Z

added 1 commit

  • 18c59283 - bsp/qoriq: Ignore spurious interrupts

Compare with previous version

Author: Kinsey Moore

2025-02-07T22:57:58.154Z

resolved all threads

Author: Kinsey Moore

2025-02-07T22:58:41.186Z

approved this merge request

Author: Gedare Bloom

2025-02-07T23:17:29.818Z

added 1 commit

  • be39d7cc - bsp/qoriq: Ignore spurious interrupts

Compare with previous version

Author: Gedare Bloom

2025-02-07T23:17:45.099Z

reset approvals from @opticron by pushing to the branch

Author: Gedare Bloom

2025-02-07T23:18:36.678Z

added 1 commit

  • e421c922 - bsp/qoriq: Ignore spurious interrupts

Compare with previous version

Author: Gedare Bloom

2025-02-07T23:19:38.690Z

approved this merge request

Author: Kinsey Moore

2025-02-07T23:20:19.442Z

approved this merge request

335 - build: Provide LDFLAGS for pkg-config (6.1)

Id

335

State

merged

Merged by

Joel Sherrill

Merged at

2025-02-07T18:29:24.490Z

Assignee(s)

Sebastian Huber

Created

2024-11-28T14:26:56.054Z

Updated

2025-02-07T18:29:26.896Z

Milestone

6.2

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/335

Commit

e36ba91110724b5cc8a9e07659d98d0bcb96e4d4

Summary

build: Provide LDFLAGS for pkg-config

Some pkg-config variants perform transformations on the –libs options. This may lead to completely broken linker options. Provide the LDFLAGS as a variable. Remove “Ldflags:” since this is an unsupported field.

Update #5165.

Author: Sebastian Huber

2024-11-28T14:26:56.172Z

assigned to @sebhub

Author: Sebastian Huber

2024-11-28T14:28:45.629Z

changed title from build: Provide LDFLAGS for pkg-config to build: Provide LDFLAGS for pkg-config{+ (6.1)+}

Author: Chris Johns

2024-11-28T18:55:33.768Z

approved this merge request

Author: Chris Johns

2024-11-28T18:56:10.244Z

unapproved this merge request

Author: Kinsey Moore

2025-01-17T01:21:22.921Z

approved this merge request

Author: Kinsey Moore

2025-01-17T01:21:50.110Z

added 4 commits

  • 0de8e928…34ba74f4 - 3 commits from branch rtems/rtos:6

  • b337ac32 - build: Provide LDFLAGS for pkg-config

Compare with previous version

Author: Kinsey Moore

2025-01-17T03:12:28.532Z

unapproved this merge request

Author: Kinsey Moore

2025-01-17T03:12:38.050Z

approved this merge request

Author: Sebastian Huber

2025-01-20T23:32:47.963Z

added 2 commits

  • f7de6d54 - 1 commit from branch rtems/rtos:6

  • c6242efc - build: Provide LDFLAGS for pkg-config

Compare with previous version

Author: Sebastian Huber

2025-01-20T23:33:00.694Z

reset approvals from @opticron by pushing to the branch

Author: Kinsey Moore

2025-01-24T01:06:37.734Z

added 5 commits

  • c6242efc…f1c201c5 - 4 commits from branch rtems/rtos:6

  • 6c845593 - build: Provide LDFLAGS for pkg-config

Compare with previous version

Author: Kinsey Moore

2025-01-24T01:06:45.116Z

approved this merge request

Author: Kinsey Moore

2025-02-06T23:48:13.858Z

added 2 commits

  • 9641e1e9 - 1 commit from branch rtems/rtos:6

  • 7654de7c - build: Provide LDFLAGS for pkg-config

Compare with previous version

Author: Kinsey Moore

2025-02-07T18:28:08.013Z

added 2 commits

  • a0e4be53 - 1 commit from branch rtems/rtos:6

  • e36ba911 - build: Provide LDFLAGS for pkg-config

Compare with previous version

Author: Joel Sherrill

2025-02-07T18:29:12.972Z

approved this merge request

404 - grlib/occan: Fix baud rate calculation

Id

404

State

merged

Merged by

Joel Sherrill

Merged at

2025-02-07T18:03:48.749Z

Assignee(s)

Gedare Bloom

Created

2025-02-07T15:51:47.539Z

Updated

2025-02-07T18:03:50.977Z

Milestone

6.2

Labels

backport, grlib

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/404

Commit

a0e4be53f4e30ee02d6d0c9221d613d18c72f426

Summary

grlib/occan: Fix baud rate calculation

Fixes #5205

Closes #5205

Author: Gedare Bloom

2025-02-07T15:51:47.744Z

assigned to @gedare

Author: Kinsey Moore

2025-02-07T18:01:17.302Z

approved this merge request

Author: Joel Sherrill

2025-02-07T18:03:40.618Z

approved this merge request

381 - cpukit/termios: Fix ordering of baud rate table

Id

381

State

merged

Merged by

Sebastian Huber

Merged at

2025-02-06T03:35:42.316Z

Assignee(s)

Gedare Bloom

Created

2025-02-03T19:05:27.637Z

Updated

2025-02-06T03:35:45.233Z

Milestone

6.2

Labels

cpukit

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/381

Commit

9641e1e97d8195d567a6218228ef0f0f2d7fdc25

Summary

cpukit/termios: Fix ordering of baud rate table

rtems_termios_set_best_baud expects a sorted baud rate table.

Fixes #5202

Closes #5202

Author: Gedare Bloom

2025-02-03T19:05:27.858Z

assigned to @gedare

Author: Kinsey Moore

2025-02-03T19:10:11.840Z

approved this merge request

Author: Sebastian Huber

2025-02-06T03:35:22.184Z

approved this merge request

365 - Backport 6.2: bsps/shared: NS16550 driver updates the line control register during operation

Id

365

State

merged

Merged by

Chris Johns

Merged at

2025-01-24T00:09:30.843Z

Created

2025-01-23T14:26:20.807Z

Updated

2025-01-24T00:09:32.535Z

Milestone

6.2

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/365

Commit

f1c201c508ff65e1ed9d0ec8149f39be52ac39a9

Summary

bsps/shared: NS16550 driver updates the line control register during operation

Fixes: #5187

Author: Kinsey Moore

2025-01-23T14:27:47.909Z

approved this merge request

Author: Jan Sommer

2025-01-23T14:33:23.574Z

changed title from bsps/shared: NS16550 driver updates the line control register during operation to {+Backport 6.2: +}bsps/shared: NS16550 driver updates the line control register during operation

Author: Chris Johns

2025-01-24T00:08:35.222Z

added 3 commits

  • 545f8f0f…603c168a - 2 commits from branch rtems/rtos:6

  • f1c201c5 - bsps/shared: NS16550 driver updates the line control register during operation

Compare with previous version

Author: Chris Johns

2025-01-24T00:09:26.181Z

approved this merge request

361 - cpukit/libmisc: fix flag in capture.c

Id

361

State

merged

Merged by

Kinsey Moore

Merged at

2025-01-23T23:49:48.189Z

Assignee(s)

Gedare Bloom

Created

2025-01-21T00:00:22.382Z

Updated

2025-01-23T23:49:50.563Z

Milestone

6.2

Labels

cpukit::misc

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/361

Commit

603c168a0ba828efc949b398d3623ebc9a0aafa3

Summary

cpukit/libmisc: fix flag in capture.c

The RTEMS_CAPTURE_OVERFLOW is an overflow flag for each CPU, and its value is the same as RTEMS_CAPTURE_INIT. Executing rtems_capture_flush will set the RTEMS_CAPTURE_INIT flag to 0 in the global flags.

Fixes #5184.

Closes #5184

Author: Gedare Bloom

2025-01-21T00:00:24.030Z

assigned to @gedare

Author: Chris Johns

2025-01-23T23:45:11.771Z

added 3 commits

  • 151074b3…84c2cf3d - 2 commits from branch rtems/rtos:6

  • 603c168a - cpukit/libmisc: fix flag in capture.c

Compare with previous version

Author: Chris Johns

2025-01-23T23:45:36.805Z

approved this merge request

Author: Kinsey Moore

2025-01-23T23:49:43.026Z

approved this merge request

367 - cpukit/libdl/arm: Fix trampoline alignment

Id

367

State

merged

Merged by

Chris Johns

Merged at

2025-01-23T23:37:30.167Z

Created

2025-01-23T22:05:59.402Z

Updated

2025-01-23T23:37:32.473Z

Milestone

6.2

Labels

arch:arm, cpukit::dl

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/367

Commit

84c2cf3da9983ef7eadb11d4a676449d6b3ef875

Summary

cpukit/libdl/arm: Fix trampoline alignment

This commit aligns trampolines for THUMB and ARM instructions (CALL/JUMP24 and THM_JUMP24/THM_PC22).

According to the ARM technical reference in section “Register-relative and PC-relative expressions”:

In Thumb code: * For B, BL, CBNZ, and CBZ instructions, the value of the PC is the address of the current instruction plus 4 bytes. * For all other instructions that use labels, the value of the PC is the address of the current instruction plus 4 bytes, with bit[1] of the result cleared to 0 to make it word-aligned.

Closes #5189

https://developer.arm.com/documentation/dui0473/m/symbols–literals–expressions–and-operators/register-relative-and-pc-relative-expressions

Author: Kinsey Moore

2025-01-23T22:49:30.326Z

I have created #5189 for this MR to reference with appropriate epic and milestone. Could you please reference it with “Closes #5189” on a new line at the end of the commit message?

Author: Ranulfo Raphael

2025-01-23T22:49:30.326Z

Done. Thanks.

Author: Ranulfo Raphael

2025-01-23T22:41:09.917Z

added 1 commit

  • 84c2cf3d - cpukit/libdl/arm: Fix trampoline alignment

Compare with previous version

Author: Ranulfo Raphael

2025-01-23T22:47:35.033Z

changed the description

Author: Ranulfo Raphael

2025-01-23T22:49:30.342Z

resolved all threads

Author: Kinsey Moore

2025-01-23T23:03:23.524Z

approved this merge request

Author: Chris Johns

2025-01-23T23:37:24.885Z

approved this merge request

348 - libmisc/stackchk: Add stack smashing protection (opened)

Id

348

State

opened

Assignee(s)

Joel Sherrill

Reviewer(s)

Gedare Bloom

Created

2024-12-19T06:34:14.290Z

Updated

2025-07-03T01:13:57.653Z

Milestone

6.2

Labels

backport

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/348

Commit

6a6881cb661f460ee9e064107dcf8590ae6e552a

Summary

libmisc/stackchk: Add stack smashing protection

This is a backport for merge request 277! to 6 branch.

Note

Closes #5180

Author: Mohamed Hassan

2024-12-19T06:41:59.787Z

mentioned in issue #5180

Author: Gedare Bloom

2024-12-19T16:33:40.221Z

assigned to @joel

Author: Gedare Bloom

2024-12-19T16:35:21.370Z

requested review from @gedare

Author: Gedare Bloom

2024-12-19T16:35:37.534Z

Needs the same fixes as !277

Author: Mohamed Hassan

2024-12-20T15:04:15.023Z

Done.

Author: Gedare Bloom

2025-02-07T18:30:50.708Z

Please add Closes #5180

Author: Mohamed Hassan

2025-02-07T18:30:50.708Z

Understood & done.

Author: Mohamed Hassan

2024-12-20T14:49:15.952Z

added 1 commit

  • 066b355c - libmisc/stackchk: Add stack smashing protection

Compare with previous version

Author: Mohamed Hassan

2024-12-20T15:02:21.630Z

added 1 commit

  • 30d7008a - libmisc/stackchk: Add stack smashing protection

Compare with previous version

Author: Mohamed Hassan

2024-12-20T15:03:35.573Z

changed the description

Author: Mohamed Hassan

2024-12-23T20:25:19.593Z

added 2 commits

  • d61a739e - 1 commit from branch rtems/rtos:6

  • b50f74c9 - libmisc/stackchk: Add stack smashing protection

Compare with previous version

Author: Kinsey Moore

2025-02-06T23:51:32.758Z

added 8 commits

  • b50f74c9…9641e1e9 - 7 commits from branch rtems/rtos:6

  • 9c5f1ae7 - libmisc/stackchk: Add stack smashing protection

Compare with previous version

Author: Amar Takhar

2025-07-03T01:14:00.936Z

added 13 commits

  • 9c5f1ae7…dd490c5c - 12 commits from branch rtems/rtos:6

  • 6a6881cb - libmisc/stackchk: Add stack smashing protection

Compare with previous version

424 - build: Provide LDFLAGS for pkg-config (opened)

Id

424

State

opened

Assignee(s)

Sebastian Huber

Created

2025-02-15T05:42:39.462Z

Updated

2025-07-02T18:25:40.016Z

Milestone

6.2

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/424

Commit

3e90c37861ad2f26e235ffa1b10f50a9841bf27b

Summary

Some pkg-config variants perform transformations on the –libs options. This may lead to completely broken linker options:

https://github.com/pkgconf/pkgconf/issues/371

Provide the LDFLAGS as a variable. Do not add the ABI_FLAGS to LDFLAGS since they are already contained in the CFLAGS. The linker command line should include the compiler flags so that link-time optimization works properly.

Update #5165.

Author: Sebastian Huber

2025-02-15T05:42:39.627Z

assigned to @sebhub

Author: Sebastian Huber

2025-02-15T05:44:12.602Z

changed title from {-cpukit/jffs2/rtime: Fix off-by-one error in decompression check-} to {+build: Provide LDFLAGS for pkg-config+}

Author: Sebastian Huber

2025-02-15T05:44:12.631Z

changed the description

Author: Sebastian Huber

2025-02-15T05:44:12.670Z

changed target branch from main to 6

Author: Sebastian Huber

2025-02-15T05:48:57.400Z

I created the MR with the wrong target branch. Now the pipeline is confused.

Author: Amar Takhar

2025-02-15T05:59:03.534Z

Yes, we actually enacted a new policy and adding to gitlab that branches targeted towards branches need to start with 5-* or 6-* gitlab will then automatically set the branch.

This just happened no doc updating the old way is still fine but this way this CI issue won’t happen. Let me try and see if restarting the pipeline manually fixes it.

Author: Amar Takhar

2025-02-15T06:00:16.820Z

Nope that didn’t fix it let me see how to properly handle this situation it may be how I have the CI setup

Author: Amar Takhar

2025-02-16T09:50:17.653Z

I think we’re stuck unless you do an update the source or we have to rebase on it. GitLab will snapshot the state when an MR comes in and use that. I have seen complaints about this exact issue but no solutions anywhere so we’ll wait until there is a chance to rebase.

Author: Kinsey Moore

2025-03-04T15:20:39.238Z

approved this merge request

Author: Amar Takhar

2025-07-02T18:25:44.075Z

added 8 commits

  • a5e5c058…dd490c5c - 7 commits from branch rtems/rtos:6

  • 3e90c378 - build: Provide LDFLAGS for pkg-config

Compare with previous version

Author: Amar Takhar

2025-07-02T18:25:58.823Z

reset approvals from @opticron by pushing to the branch

518 - cpukit/libdebugger: Add support for TLS variables (opened)

Id

518

State

opened

Assignee(s)

Kinsey Moore

Reviewer(s)

Chris Johns

Created

2025-06-17T19:19:24.345Z

Updated

2025-06-26T00:48:21.103Z

Milestone

6.2

Labels

backport

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/518

Commit

4f819d026e5afba800f96dced054cc6a6067ca07

Summary

cpukit/libdebugger: Add support for TLS variables

This adds support for the “vGetTLSAddr” GDB query which retrieves the address of a TLS variable by offset from the beginning of the TLS memory space for the given thread. This offset does not include the size of the thread control block which is at the beginning of every TLS area as used by RTEMS. Notably, the returned address is big-endian rather than the little-endian typical with other responses.

This functionality does not include retrieval of addresses for TLS variables hosted in loadable modules, only TLS variables in the host binary.

Closes #5271 Updates #4883

Author: Kinsey Moore

2025-06-17T19:19:24.986Z

requested review from @chris

Author: Kinsey Moore

2025-06-17T19:19:25.012Z

assigned to @opticron

Author: Kinsey Moore

2025-06-18T18:59:43.036Z

changed the description

Author: Kinsey Moore

2025-06-18T19:01:15.967Z

mentioned in issue #4883

Author: Kinsey Moore

2025-06-25T11:42:20.014Z

added 1 commit

  • 14329bc2 - cpukit/libdebugger: Add support for TLS variables

Compare with previous version

Author: Gedare Bloom

2025-06-25T16:35:42.812Z

approved this merge request

Author: Kinsey Moore

2025-06-26T00:48:21.060Z

added 1 commit

  • 4f819d02 - cpukit/libdebugger: Add support for TLS variables

Compare with previous version