RTEMS / Programs / Google Summer of Code¶
Go to Issues or rtems/programs/gsoc-merges
Merge Requests Summary
Issues¶
35 - RTEMS Release Notes Generator¶
Id |
35 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Created |
2018-03-01T01:06:45.000Z |
Updated |
2025-09-19T01:08:36.169Z |
Milestone |
6.1 |
Labels |
gsoc, gsoc::large, priority::normal, resolution::fixed, tickettype::project |
Link |
|
Merges |
0 |
RTEMS Release Notes Generator¶
Mentors¶
Chris Johns
Students¶
Past, Present, and Potential Students
Status¶
This is an existing project. The history is:
Introduction¶
The RTEMS release process generate the release notes from Trac. All changes on a release branch must have a ticket and the ticket is assigned the Version and Milestone. During the release process a Trac TicketQuery is run on release milestone and the resulting pages are converted to a PDF as the release notes. The Trac ticket pages are downloaded in a format suitable for parsing such as XML.
The RTEMS 4.11.3 release notes are:
https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.3/rtems-4.11.3-release-notes.pdf
and all the tickets and so all the changes have been captured however the release notes have some issues.
The tickets only have the descriptions and no comments. This means any discussion on the resolution of the ticket is missing.
The date is relative so 4 days ago is relative to the date of the release.
There are some formatting issue. See page 3/8 of the 4.11.3 notes on the link above.
Comments cannot be easily added. Trac’s TicketQuery does not support adding the Comments. There has been many requests for this over the years and it has not been added.
The date is a local setting which means logging in to get a setting and the release process is anonymous and gets the default.
The formatting could be the current release process’s CSS file used to generate the PDF.
Goal¶
Automatically create the release notes for a release from the Trac data.
Include all of the ticket’s data in the release notes.
Use the full date.
Provide better formatting of the ticket such as each ticket starting on a new page.
Be able to provide HTML and PDF version of the output.
Prerequisite ==¶
Knowledge of Python
Knowledge of HTML and CSS
Knowledge of XML
Knowledge of ReST (Sphinx)
Tasks¶
Develop a Python class to read an RSS page from Trac. An RSS page is basically HTML in XML.
Develop a Python class to get a list of tickets for a milestone from Trac using the RSS format.
Develop a Python class to get all the ticket data for a milestone.
Generate ReST output that can be wrapped in coverpages to create a document.
Have Sphnix generate create HTML and PDF output.
Package the tool in the
rtems-toolsrepo.Update the RTEMS release process to create the new format release notes.
Author: Amar Takhar
2024-04-26T01:34:36.327Z
assigned to @chris
Author: Chris Johns
2018-03-01T01:07:22.000Z
Owner set to @chrisj
Status changed from new to assigned
Author: Chris Johns
2018-03-01T01:14:58.000Z
Description changed
- = RTEMS Release Note Generator = + = RTEMS Release Notes Generator = ? + [[Contents, inline)](../wikis/PageOutline(1-5,)] == Mentors == Chris Johns == Students == Past, Present, and Potential Students == Status == This is a new project == Introduction == The RTEMS release process generate the release notes from Trac. All changes on a release branch must have a ticket and the ticket is assigned the Version and Milestone. During the release process a Trac TicketQuery is run on release milestone and the resulting web pages are converted to a PDF as the release notes. The RTEMS 4.11.3 release notes are: https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.3/rtems-4.11.3-release-notes.pdf and all the tickets and so all the changes have been captured however the release notes have some issues. 1. The tickets only have the descriptions and no comments. This means any discussion on the resolution of the ticket is missing. 2. The date is relative so **4 days ago** is relative to the date of the release. 3. There are some formatting issue. See page 3/8 of the 4.11.3 notes on the link above. Comments cannot be easily added. Trac's TicketQuery does not support adding the Comments. There has been many requests for this over the years and it has not been added. The date is a local setting which means logging in to get a setting and the release process is anonymous and gets the default. The formatting could be the current release process's CSS file used to generate the PDF. == Goal == * Automatically create the release notes for a release from the Trac data. * Include all of the ticket's data in the release notes. * Use the full date. * Provide better formatting of the ticket such as each ticket starting on a new page. * Be able to provide HTML and PDF version of the output. == Prerequisite == * Knowledge of Python * Knowledge of HTML and CSS * Knowledge of XML * Optional knowledge of ReST (Sphinx) == Tasks == 1. Develop a Python class to read an RSS page from Trac. An RSS page is basically HTML in XML. 2. Develop a Python class to get a list of tickets for a milestone from Trac using the RSS format. 3. Develop a Python class to get all the ticket data for a milestone. 4. Investigate output formats. See if the data can be used in a ReST (Restructured Text) document so Sphnix can be used to create HTML and PDF output. 5. Generate the output format. Add the RTEMS icon, a coverpage, copyright and another data we need in the release notes. 6. Convert the output to HTML and PDF. 7. Package the tool in the `rtems-tools` repo. 8. Update the RTEMS release process to create the new format release notes.
Summary changed from RTEMS Releases Note Generator to RTEMS Release Notes Generator
Author: Chris Johns
2020-03-04T02:20:04.000Z
Description changed
= RTEMS Release Notes Generator = [[Contents, inline)](../wikis/PageOutline(1-5,)] == Mentors == Chris Johns == Students == Past, Present, and Potential Students == Status == - This is a new project + This is an existing project. The history is: + + [GSoC/2018](GSoC/2018) == Introduction == The RTEMS release process generate the release notes from Trac. All changes on a release branch must have a ticket and the ticket is assigned the Version and Milestone. During the release process a Trac TicketQuery is run on release milestone and the resulting web pages are converted to a PDF as the release notes. The RTEMS 4.11.3 release notes are: https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.3/rtems-4.11.3-release-notes.pdf and all the tickets and so all the changes have been captured however the release notes have some issues. 1. The tickets only have the descriptions and no comments. This means any discussion on the resolution of the ticket is missing. 2. The date is relative so **4 days ago** is relative to the date of the release. 3. There are some formatting issue. See page 3/8 of the 4.11.3 notes on the link above. Comments cannot be easily added. Trac's TicketQuery does not support adding the Comments. There has been many requests for this over the years and it has not been added. The date is a local setting which means logging in to get a setting and the release process is anonymous and gets the default. The formatting could be the current release process's CSS file used to generate the PDF. == Goal == * Automatically create the release notes for a release from the Trac data. * Include all of the ticket's data in the release notes. * Use the full date. * Provide better formatting of the ticket such as each ticket starting on a new page. * Be able to provide HTML and PDF version of the output. == Prerequisite == * Knowledge of Python * Knowledge of HTML and CSS * Knowledge of XML - * Optional knowledge of ReST (Sphinx) ? ^^^^^^^^^^ + * Knowledge of ReST (Sphinx) ? ^ == Tasks == 1. Develop a Python class to read an RSS page from Trac. An RSS page is basically HTML in XML. 2. Develop a Python class to get a list of tickets for a milestone from Trac using the RSS format. 3. Develop a Python class to get all the ticket data for a milestone. - 4. Investigate output formats. See if the data can be used in a ReST (Restructured Text) document so Sphnix can be used to create HTML and PDF output. + 4. Generate ReST output that can be wrapped in coverpages to create a document. + 5. Have Sphnix generate create HTML and PDF output. - 5. Generate the output format. Add the RTEMS icon, a coverpage, copyright and another data we need in the release notes. - - 6. Convert the output to HTML and PDF. 7. Package the tool in the `rtems-tools` repo. 8. Update the RTEMS release process to create the new format release notes.
Author: Chris Johns
2020-03-04T20:55:04.000Z
Description changed
= RTEMS Release Notes Generator = [[Contents, inline)](../wikis/PageOutline(1-5,)] == Mentors == Chris Johns == Students == Past, Present, and Potential Students == Status == This is an existing project. The history is: [GSoC/2018](GSoC/2018) == Introduction == - The RTEMS release process generate the release notes from Trac. All changes on a release branch must have a ticket and the ticket is assigned the Version and Milestone. During the release process a Trac TicketQuery is run on release milestone and the resulting web pages are converted to a PDF as the release notes. ? ^^^^^^^^^^^^^ + The RTEMS release process generate the release notes from Trac. All changes on a release branch must have a ticket and the ticket is assigned the Version and Milestone. During the release process a Trac TicketQuery is run on release milestone and the resulting pages are converted to a PDF as the release notes. The Trac ticket pages are downloaded in a format suitable for parsing such as XML. ? ^^^^^^^^^ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The RTEMS 4.11.3 release notes are: https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.3/rtems-4.11.3-release-notes.pdf and all the tickets and so all the changes have been captured however the release notes have some issues. 1. The tickets only have the descriptions and no comments. This means any discussion on the resolution of the ticket is missing. 2. The date is relative so **4 days ago** is relative to the date of the release. 3. There are some formatting issue. See page 3/8 of the 4.11.3 notes on the link above. Comments cannot be easily added. Trac's TicketQuery does not support adding the Comments. There has been many requests for this over the years and it has not been added. The date is a local setting which means logging in to get a setting and the release process is anonymous and gets the default. The formatting could be the current release process's CSS file used to generate the PDF. == Goal == * Automatically create the release notes for a release from the Trac data. * Include all of the ticket's data in the release notes. * Use the full date. * Provide better formatting of the ticket such as each ticket starting on a new page. * Be able to provide HTML and PDF version of the output. == Prerequisite == * Knowledge of Python * Knowledge of HTML and CSS * Knowledge of XML * Knowledge of ReST (Sphinx) == Tasks == 1. Develop a Python class to read an RSS page from Trac. An RSS page is basically HTML in XML. 2. Develop a Python class to get a list of tickets for a milestone from Trac using the RSS format. 3. Develop a Python class to get all the ticket data for a milestone. 4. Generate ReST output that can be wrapped in coverpages to create a document. 5. Have Sphnix generate create HTML and PDF output. 7. Package the tool in the `rtems-tools` repo. 8. Update the RTEMS release process to create the new format release notes.
Author: Chris Johns
2023-03-24T23:20:30.000Z
Resolution set to ~”fixed”
Status changed from assigned to closed
This task has been completed.
Author: Amar Takhar
2024-04-25T20:46:02.240Z
changed the description
66 - Replace Mongoose with Civetweb¶
Id |
66 |
State |
closed |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2021-03-10T22:48:28.000Z |
Closed |
2024-11-22T00:53:06.534Z |
Updated |
2025-09-19T01:06:40.473Z |
Milestone |
6.1 |
Labels |
gsoc, gsoc::large, library, priority::normal, project::large, tickettype::enhancement |
Link |
|
Merges |
0 |
RTEMS has an old version of Mongoose using a permissive license before it was relicensed to GPL. There was a fork at the point of it being relicensed and it is now called Civetweb (https://github.com/civetweb/civetweb).
This project would remove mongoose from RTEMS and ideally replace it with an RSB built version of Civetweb. This would enable it to be used on top of any TCP/IP stack RTEMS supports.
One challenge will be figuring out how to deal with all the options Civetweb has, making these accessible to the user building Civetweb via RSB, and documenting them.
Author: Amar Takhar
2024-04-26T01:34:49.459Z
assigned to @tracmigrate
Author: Gedare Bloom
2021-03-18T16:16:25.000Z
Description changed
- RTEMS has an old version of Mongoose using a permissive license before it was relicensed to GPL. There was a fork at the point of it being relicensed and it is now called Civitweb (https://github.com/civetweb/civetweb). ? ^^^^^ + RTEMS has an old version of Mongoose using a permissive license before it was relicensed to GPL. There was a fork at the point of it being relicensed and it is now called Civetweb (https://github.com/civetweb/civetweb). ? ^^^^^ - This project would remove mongoose from RTEMS and ideally replace it with an RSB built version of Civitweb. This would enable it to be used on top of any TCP/IP stack RTEMS supports. ? ^ + This project would remove mongoose from RTEMS and ideally replace it with an RSB built version of Civetweb. This would enable it to be used on top of any TCP/IP stack RTEMS supports. ? ^ - One challenge will be figuring out how to deal with all the options Civitweb has, making these accessible to the user building Civitweb via RSB, and documenting them. ? ^ ^ + One challenge will be figuring out how to deal with all the options Civetweb has, making these accessible to the user building Civetweb via RSB, and documenting them. ? ^ ^
Summary changed from Replace Mongoose with Civitweb to Replace Mongoose with Civetweb
Author: Chris Johns
2024-02-18T23:41:27.000Z
Should Civetweb be added to net-services or an RSB package?
Author: Amar Takhar
2024-04-25T20:48:42.733Z
changed the description
61 - Improve Exception Output¶
Id |
61 |
State |
closed |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Created |
2020-12-09T23:52:21.000Z |
Updated |
2025-09-19T01:06:40.377Z |
Milestone |
6.1 |
Labels |
bsp, gsoc, gsoc::small, old-indefinite, priority::normal, resolution::fixed, tickettype::enhancement, version::6 |
Link |
|
Merges |
0 |
When debugging a divide by zero error on the x86, an exception was printed which was marginally useful. However, it printed the task id in decimal and did not print the exception type as a string. This task is to review the exception handler for each architecture and attempt to make it more user friendly.
Print values in the most appropriate numeric base
Print exceptions as strings and with any accompanying details
This can be done an architecture at a time as a small task or as a set for a Summer of Code style project.
Author: Amar Takhar
2024-04-26T01:34:47.498Z
assigned to @tracmigrate
Author: Joel Sherrill
2021-12-16T15:38:01.000Z
Milestone changed from rtems%”6.1” to rtems%”Indefinite”
Author: Joel Sherrill
2021-12-16T15:41:34.000Z
Resolution set to ~”fixed”
Status changed from new to closed
Implemented by Chris Johns.
Author: Amar Takhar
2024-04-25T20:48:31.572Z
changed the description
67 - Port Rust to RTEMS¶
Id |
67 |
State |
closed |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Closed by |
Gedare Bloom |
Created |
2020-11-20T16:19:43.000Z |
Closed |
2025-01-20T15:27:21.314Z |
Updated |
2025-09-19T01:06:40.275Z |
Milestone |
6.1 |
Labels |
gsoc, gsoc::large, lang::rust, old-indefinite, project::large |
Link |
|
Merges |
0 |
With at least two architectures (SPARC and RISC-V) buildable with LLVM/clang, it is now time to consider porting Rust to RTEMS.
This project will be to target the Rust compiler to RTEMS, port the Rust run-time to RTEMS, and run the test suite for Rust.
All LLVM modifications should be submitted to LLVM which means a contributors agreement to them will have to be executed.
Note: RISC-V RTEMS support for LLVM may still be a work in progress.
rtems/rtos/rtems#4623 may be a prerequisite for this. Being able to build LLVM with RTEMS support for any architecture and test it with normal C support is critical.
Potential mentors: Joel Sherrill, Sebastian Huber, Chris Johns, Gedare Bloom Skills: C, some Rust Difficulty: Hard
Author: Amar Takhar
2024-04-26T01:34:49.849Z
assigned to @tracmigrate
Author: Trac Migrate
2022-02-08T00:46:55.000Z
Cc added @karel@functional.vision
Not sure if this project is not going against the wind here. If nobody steps in, then RTEMS project may get Rust language support for “free” by just waiting and seeing how https://rust-gcc.github.io/ completes. And then by enabling it in RSB I would guess. And well, porting its runtime to newlib. But hopefully effort will be lower than porting whole LLVM framework “just” to bring Rust in.
Author: Joel Sherrill
2022-02-25T21:09:57.000Z
Description changed
With at least two architectures (SPARC and RISC-V) buildable with LLVM/clang, it is now time to consider porting Rust to RTEMS. This project will be to target the Rust compiler to RTEMS, port the Rust run-time to RTEMS, and run the test suite for Rust. All LLVM modifications should be submitted to LLVM which means a contributors agreement to them will have to be executed. + Note: RISC-V RTEMS support for LLVM may still be a work in progress. + + #4623 may be a prerequisite for this. Being able to build LLVM with RTEMS support for any architecture and test it with normal C support is critical. + Potential mentors: Joel Sherrill, Sebastian Huber, Chris Johns, Gedare Bloom + Skills: C, some Rust + Difficulty: Hard +
Author: Trac Migrate
2022-03-31T10:42:56.000Z
For porting LLVM-based rust toolchain, e.g. the one commonly known as ‘rust’, this page should be related: https://github.com/rust-embedded/wg
Author: Trac Migrate
2022-04-04T08:16:27.000Z
And to complete a picture, here is another project marring rust and gcc. This time rust as it is is used and the backend is changed from llvm to gcc’s own gccjit library. https://github.com/rust-lang/rustc_codegen_gcc
Author: Amar Takhar
2024-04-25T20:48:28.454Z
changed the description
Author: Gedare Bloom
2025-01-20T15:28:08.908Z
cloned to #80
9 - Add Classic API Barrier “get number waiting” Service¶
Id |
9 |
State |
closed |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Joel Sherrill |
Closed by |
Gedare Bloom |
Created |
2019-05-20T22:22:33.000Z |
Closed |
2025-05-12T17:03:03.102Z |
Updated |
2025-09-19T01:06:40.153Z |
Milestone |
6.1 |
Labels |
gsoc, gsoc::small, lang::c, old-indefinite, project::small, rtems::kernel |
Link |
|
Merges |
2 |
Background¶
Given that a barrier can be set to manually release, it would be useful to know how many threads are waiting at it. An extension to the barrier API could be useful.
Approach¶
Talk to the mentors. Tests and documentation are required.
Knowledge/Skills¶
C
Synchronization primitives
Possible Mentors¶
@joel @gedare
Author: Amar Takhar
2024-04-26T01:25:48.444Z
assigned to @joel
Author: Joel Sherrill
2022-02-25T21:25:44.000Z
Description changed
- Given that a barrier can be set to manually release, it would be useful to know how many threads are waiting at it. This is a low priority request to consider adding that. ? ^^ ^^ ^^ ^^^^ ^^^^ ----------- -------------- + Given that a barrier can be set to manually release, it would be useful to know how many threads are waiting at it. Tests and documentation required. ? ^ ^ ^^^^ ^^^^^^^^ ^ ++ + + Possible Mentors: Joel Sherrill + Skills: C + Difficulty: Medium
Author: Gedare Bloom
2024-02-17T05:09:21.000Z
Priority changed from ~”lowest” to ~”normal”
Author: Gedare Bloom
2024-02-17T05:13:37.000Z
Owner set to @joel
Status changed from new to assigned
Author: Amar Takhar
2024-04-25T20:47:22.889Z
changed the description
Author: Gedare Bloom
2025-01-18T02:15:21.106Z
changed the description
Author: Gedare Bloom
2025-01-24T23:17:06.150Z
changed the description
Author: mazen Adel
2025-03-02T14:30:08.647Z
mentioned in merge request rtems/rtos/rtems!439
Author: mazen Adel
2025-03-02T14:49:45.677Z
mentioned in merge request rtems/rtos/rtems!440
Author: mazen Adel
2025-03-02T21:24:08.383Z
mentioned in merge request rtems/rtos/rtems!441
Author: mazen Adel
2025-03-02T21:38:54.300Z
mentioned in commit mez3n/rtems@27258c00758dde6dbbdd2585fce0c1036b275bb2
Author: mazen Adel
2025-03-02T21:39:31.801Z
mentioned in merge request rtems/rtos/rtems!442
Author: mazen Adel
2025-03-04T22:51:16.973Z
mentioned in commit mez3n/rtems@f05430b3797505d56e71fc558ac31d59afb22253
Author: mazen Adel
2025-03-04T22:58:26.206Z
mentioned in merge request rtems/rtos/rtems!443
Author: mazen Adel
2025-03-04T23:08:19.371Z
mentioned in commit mez3n/rtems@cedac6705c606466e1373d66ac3b301555040c70
Author: mazen Adel
2025-03-04T23:10:09.290Z
mentioned in commit mez3n/rtems@1804468edb99ec38950eaf9552061807c7047f74
Author: mazen Adel
2025-03-08T11:14:43.889Z
mentioned in commit mez3n/rtems@f7f9bc49d95c3303ddb264a48d61c6add54fc37f
Author: mazen Adel
2025-03-08T15:27:11.919Z
mentioned in commit mez3n/rtems@bd62cffa1459c203c7dba33102031ed1c3de717c
Author: mazen Adel
2025-03-08T15:44:12.862Z
mentioned in commit mez3n/rtems@29c7a0d2be845ceb1c585ffa9a4bd74d8eb8857c
Author: mazen Adel
2025-03-20T22:09:32.856Z
mentioned in commit mez3n/rtems@3ddb5c4813ff8e8960a9372d8ef1332275e65fd8
Author: mazen Adel
2025-03-27T19:52:41.005Z
mentioned in commit mez3n/rtems-docs@1a8110bb7ad623d7d051932dd110c3d2c08a6bc5
Author: mazen Adel
2025-03-27T19:54:35.945Z
mentioned in merge request rtems/docs/rtems-docs!167
Author: mazen Adel
2025-03-27T19:58:20.733Z
mentioned in commit mez3n/rtems-docs@4777a0dad822cbf535068e32782e65f651dd7865
Author: mazen Adel
2025-04-23T22:05:10.088Z
mentioned in commit mez3n/rtems-docs@ca5c113de0607f6eccf9c95d095315ebd6008456
Author: mazen Adel
2025-04-23T22:39:26.485Z
mentioned in commit mez3n/rtems-docs@d09d56093fc7e9d94347e34fb1e149b56b89c321
Author: mazen Adel
2025-04-23T22:45:36.651Z
mentioned in commit mez3n/rtems-docs@5db696844dd0448612dd34aeee93810bf8072581
Author: mazen Adel
2025-05-09T23:22:23.658Z
mentioned in commit mez3n/rtems@5fb2acfe9e191f4de742c507306d50a0e66074dc
Author: mazen Adel
2025-05-09T23:30:13.142Z
mentioned in commit mez3n/rtems@1ff8baaef6cf9525838536fe5ddef58889d89f87
Author: mazen Adel
2025-05-12T17:00:17.621Z
mentioned in commit mez3n/rtems@528095cd24afeef648ea0e70694aa3755a7c0edf
Author: mazen Adel
2025-05-12T17:25:01.785Z
mentioned in commit sunil-hegde/rtems@2cc39d9a707c889157af33872412c0756cf8660c
Author: mazen Adel
2025-08-29T13:15:18.599Z
mentioned in commit mez3n/rtems-docs@238db0f7fa0896e5cb79e64aa53f186bd0c94818
Author: mazen Adel
2025-08-31T12:46:44.225Z
mentioned in commit mez3n/rtems-docs@348fb0331720acee2e62cef1d6257c3cc4b65ecc
Author: mazen Adel
2025-08-31T12:47:42.039Z
mentioned in commit mez3n/rtems-docs@418dd3359e0e134504ddf6f8a32569592c17bc8b
Author: mazen Adel
2025-08-31T12:52:04.735Z
mentioned in commit mez3n/rtems-docs@9dec1de81c033e38184fa39000e212674ece0116
Author: mazen Adel
2025-08-31T12:53:50.575Z
mentioned in commit mez3n/rtems-docs@4d1429e284b2a67cd70ed89761566fa2e9c7362b
47 - TLS support for libdl¶
Id |
47 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Created |
2019-03-04T03:54:41.000Z |
Updated |
2025-09-19T01:06:40.028Z |
Milestone |
6.1 |
Labels |
cpukit::dl, gsoc, gsoc::large, old-indefinite, priority::normal, resolution::duplicate, rtems::kernel, tickettype::project |
Link |
|
Merges |
0 |
TLS support for libdl¶
Mentors¶
Chris Johns
Status ==¶
Introduction =¶
The goal of this project is to support TLS variables in code loaded using libdl.
RTEMS supports the run-time loading of the executable code using the dlopen family of calls. The implementation is in libdl. Thread Local Storage (TLS) is not support. Code containing TLS will not load and so cannot be run.
TLS Varables¶
TLS data is private to each thread. A thread is allocated a block of data when it is create to hold the system wide TLS variables. When code references a TLS variable it uses an offset from a system defined and reserved register to access the memory. With a statically linked executable all the TLS variables are known so the space allocated is known. Initialized TLS variables need to initialized when a thread is created.
TLS has an overhead. The thread specific storage adds to the allocation overhead when a thread is created, as well as thread create time as the memory needs to be initialized or cleared. It is useful to hold pointer to large object and use by RTEMS system level software should be avoided.
TLS needs compiler support to work and this means the ABI the compiler implements defines how TLS variables are defined and operate.
Run-time Loaded TLS Variables¶
Run-time loading TLS variables complicates the how TLS variables are implemented in RTEMS and how TLS variables are used. Space needs to be reserved in all threads to cater for variables that are loaded at run-time.
Space is allocated to TLS variables from the special memory attached to each thread as they are loaded until the reserved space is consumed. TLS variable symbols are treated differently to other variables loaded at run-time. Space allocated to a TLS cannot be used again until the TLS symbol that references it is removed from the system by the unloading of the executable object file that contains it.
Initialization of new variables in existing threads can happen without suspending a thread. A new TLS variable is only available to a running thread once the executable object has finished being loaded so the memory can be touched while the thread is running. The thread cannot be deleted while the initialisation is happening. Threads that start after TLS variables have been loaded need to have their TLS memory initialized.
RTEMS cannot afford to suspend threads to dynamically allocate more space to TLS variables.
Project¶
The project is to add support to the RTEMS score and libdl to support the loading of executable object files with TLS variables.
Goal¶
Update the
scoreto allow reserve extra TLS memoryProvide an allocator to the memory.
Add a TLS symbol table to
libdl.Add TSL variable tests to the testsuite.
Prerequisite¶
This is an advanced project with a lot of detail. Parts of the code need to be in the score and deep in the TCB for threads. Code accuracy and clarity is important.
Advanced knowledge of C.
An understanding of ELF and TLS.
Ability to read detail documents on file formats and operating characteristics such as ABI details for an architecture.
Experience with a few RTEMS tier 1 architectures.
Difficulty¶
This is a large (350-hour) project of hard difficulty.
Resources¶
Current RTEMS developers.
Tasks¶
The following are the tasks:
TDB
Acknowledgements¶
None.
Miscellaneous Sections¶
As the project progresses, you will need to add to the RTEMS Testing section of the User manual. This section does not currently exist but it should be present even in a skeleton form.
References¶
None.
Author: Amar Takhar
2024-04-26T01:34:41.568Z
assigned to @chris
Author: Gedare Bloom
2020-01-14T21:05:53.000Z
Owner set to @chrisj
Status changed from new to assigned
Author: Gedare Bloom
2022-02-25T18:19:03.000Z
Description changed
= TLS support for libdl = [[Contents, inline)](../wikis/PageOutline(1-5,)] == Mentors == Chris Johns == Status == = Introduction = The goal of this project is to support TLS variables in code loaded using `libdl`. RTEMS supports the run-time loading of the executable code using the `dlopen` family of calls. The implementation is in `libdl`. Thread Local Storage (TLS) is not support. Code containing TLS will not load and so cannot be run. == TLS Varables == TLS data is private to each thread. A thread is allocated a block of data when it is create to hold the system wide TLS variables. When code references a TLS variable it uses an offset from a system defined and reserved register to access the memory. With a statically linked executable all the TLS variables are known so the space allocated is known. Initialized TLS variables need to initialized when a thread is created. TLS has an overhead. The thread specific storage adds to the allocation overhead when a thread is created, as well as thread create time as the memory needs to be initialized or cleared. It is useful to hold pointer to large object and use by RTEMS system level software should be avoided. TLS needs compiler support to work and this means the ABI the compiler implements defines how TLS variables are defined and operate. == Run-time Loaded TLS Variables == Run-time loading TLS variables complicates the how TLS variables are implemented in RTEMS and how TLS variables are used. Space needs to be reserved in all threads to cater for variables that are loaded at run-time. Space is allocated to TLS variables from the special memory attached to each thread as they are loaded until the reserved space is consumed. TLS variable symbols are treated differently to other variables loaded at run-time. Space allocated to a TLS cannot be used again until the TLS symbol that references it is removed from the system by the unloading of the executable object file that contains it. Initialization of new variables in existing threads can happen without suspending a thread. A new TLS variable is only available to a running thread once the executable object has finished being loaded so the memory can be touched while the thread is running. The thread cannot be deleted while the initialisation is happening. Threads that start after TLS variables have been loaded need to have their TLS memory initialized. RTEMS cannot afford to suspend threads to dynamically allocate more space to TLS variables. = Project = The project is to add support to the RTEMS `score` and `libdl` to support the loading of executable object files with TLS variables. == Goal == * Update the `score` to allow reserve extra TLS memory * Provide an allocator to the memory. * Add a TLS symbol table to `libdl`. * Add TSL variable tests to the testsuite. == Prerequisite == This is an advanced project with a lot of detail. Parts of the code need to be in the `score` and deep in the TCB for threads. Code accuracy and clarity is important. * Advanced knowledge of C. * An understanding of ELF and TLS. * Ability to read detail documents on file formats and operating characteristics such as ABI details for an architecture. * Experience with a few RTEMS tier 1 architectures. + == Difficulty == + This is a large (350-hour) project of hard difficulty. + == Resources == * Current RTEMS developers. = Tasks = The following are the tasks: TDB = Acknowledgements = None. = Miscellaneous Sections = As the project progresses, you will need to add to the RTEMS Testing section of the User manual. This section does not currently exist but it should be present even in a skeleton form. = References = * None
Author: Gedare Bloom
2024-02-17T17:35:27.000Z
Description changed
= TLS support for libdl = [[Contents, inline)](../wikis/PageOutline(1-5,)] == Mentors == Chris Johns == Status == = Introduction = The goal of this project is to support TLS variables in code loaded using `libdl`. RTEMS supports the run-time loading of the executable code using the `dlopen` family of calls. The implementation is in `libdl`. Thread Local Storage (TLS) is not support. Code containing TLS will not load and so cannot be run. == TLS Varables == TLS data is private to each thread. A thread is allocated a block of data when it is create to hold the system wide TLS variables. When code references a TLS variable it uses an offset from a system defined and reserved register to access the memory. With a statically linked executable all the TLS variables are known so the space allocated is known. Initialized TLS variables need to initialized when a thread is created. TLS has an overhead. The thread specific storage adds to the allocation overhead when a thread is created, as well as thread create time as the memory needs to be initialized or cleared. It is useful to hold pointer to large object and use by RTEMS system level software should be avoided. TLS needs compiler support to work and this means the ABI the compiler implements defines how TLS variables are defined and operate. == Run-time Loaded TLS Variables == Run-time loading TLS variables complicates the how TLS variables are implemented in RTEMS and how TLS variables are used. Space needs to be reserved in all threads to cater for variables that are loaded at run-time. Space is allocated to TLS variables from the special memory attached to each thread as they are loaded until the reserved space is consumed. TLS variable symbols are treated differently to other variables loaded at run-time. Space allocated to a TLS cannot be used again until the TLS symbol that references it is removed from the system by the unloading of the executable object file that contains it. Initialization of new variables in existing threads can happen without suspending a thread. A new TLS variable is only available to a running thread once the executable object has finished being loaded so the memory can be touched while the thread is running. The thread cannot be deleted while the initialisation is happening. Threads that start after TLS variables have been loaded need to have their TLS memory initialized. RTEMS cannot afford to suspend threads to dynamically allocate more space to TLS variables. = Project = The project is to add support to the RTEMS `score` and `libdl` to support the loading of executable object files with TLS variables. == Goal == * Update the `score` to allow reserve extra TLS memory * Provide an allocator to the memory. * Add a TLS symbol table to `libdl`. * Add TSL variable tests to the testsuite. == Prerequisite == This is an advanced project with a lot of detail. Parts of the code need to be in the `score` and deep in the TCB for threads. Code accuracy and clarity is important. * Advanced knowledge of C. * An understanding of ELF and TLS. * Ability to read detail documents on file formats and operating characteristics such as ABI details for an architecture. * Experience with a few RTEMS tier 1 architectures. == Difficulty == This is a large (350-hour) project of hard difficulty. == Resources == * Current RTEMS developers. = Tasks = The following are the tasks: TDB = Acknowledgements = None. = Miscellaneous Sections = As the project progresses, you will need to add to the RTEMS Testing section of the User manual. This section does not currently exist but it should be present even in a skeleton form. = References = - * None + * None. ? +
Resolution set to ~”duplicate”
Status changed from assigned to closed
This is now a tracked blocker defect rtems/rtos/rtems#4920.
Author: Amar Takhar
2024-04-25T20:47:14.152Z
changed the description
21 - Improve Coverity Scan Integration¶
Id |
21 |
State |
closed |
Type |
ISSUE |
Author |
Gedare Bloom |
Assignee(s) |
Gedare Bloom |
Closed by |
Gedare Bloom |
Created |
2019-02-28T21:06:28.000Z |
Closed |
2025-01-31T17:30:52.096Z |
Updated |
2025-09-19T01:06:39.904Z |
Milestone |
6.1 |
Labels |
gsoc, gsoc::retired, old-indefinite, priority::normal, rtems::testing, tickettype::project |
Link |
|
Merges |
0 |
The goal of this project is to create better workflows to incorporate static analysis into the RTEMS development and release cycle. This project can be done with other static analyzers such as Codiga
Mentors¶
Gedare Bloom, Joel Sherrill
Skills¶
Python, Data manipulation
Difficulty¶
This is a small (175-hour) project of medium difficulty.
More Information¶
Coverity Scan is a static analyzer that can identify various types of potential software defects. Coverity offers free use of this analyzer for free software projects. Issues identified for RTEMS are at https://scan.coverity.com/projects/rtems.
Coverity Scan identifies POTENTIAL issues. Some may be real bugs. Others may indicate that Coverity Scan does not have full awareness of the program life. For example, memory allocated during RTEMS initialization may appear to be leaked because it is never freed, but this is deliberate and the issue marked as such in Coverity Scan.
You can get an account on Coverity Scan and request access to the [RTEMS Project](https://scan.coverity.com/projects/rtems) to contribute.
The current process for dealing with Coverity Scan is entirely manual. See, for example, Google Code-In task instructions for Coverity. This manual process has several drawbacks. The purpose of this GSoC Project would be to simplify the process of working with Coverity, and to automate it where possible. We have identified two starting directions, and encourage interested students to brainstorm on other ways to improve the Coverity Scan integration.
Reducing False Positives Static analysis suffers from a high number of false positives. Coverity Scan provides two methods for removing false positives. First is by creating an optional _modeling file_ to accommodate for special cases where the data flow analysis breaks, for example due to missing functions that are linked outside the analyzed source code. A modeling file usually is used to identify functions that terminate execution, allocate memory, or free memory. Second, source code annotations in specially formatted comments can also be used to suppress warnings. This project should determine which approach to take, and design/implement a path forward.
Testing Fixes Since security tools tend to be costly in terms of time or compute resources, they are normally run on nightly or even weekly builds rather than on every commit as done for typical continuous integration (CI). It can be tedious to merge commits to the development master and trigger a scan to determine if the issue has been fixed. Instead, we would like to develop fixes and trigger Coverity Scan as needed (subject to staying within the allowed scan rates). Coverity Scan integrates with Github and can be triggered to scan by merging new code to a specific git repository branch. As a first step, a special ‘coverity’ branch could be created for scanning commits that are pushed there, so that developers who are testing changes can work through the coverity branch before merging fixes into the master. Alternate solutions should be discussed with any mentors.
Coding Rule Scans Investigation on this direction is needed. Coverity supports for example a couple of MISRA rules: https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/coverity-misra-standards-ds-ul.pdf
These rules are not enabled currently. Would it be possible to enable a subset of these rules in our current setup?
Author: Amar Takhar
2024-04-26T01:25:54.359Z
assigned to @gedare
Author: Gedare Bloom
2019-02-28T21:16:19.000Z
Description changed
The goal of this project is to create better workflows to incorporate static analysis using Coverity Scan into the RTEMS development and release cycle. Coverity Scan is a static analyzer that can identify various types of potential software defects. Coverity offers free use of this analyzer for free software projects. Issues identified for RTEMS are at https://scan.coverity.com/projects/rtems. Coverity Scan identifies POTENTIAL issues. Some may be real bugs. Others may indicate that Coverity Scan does not have full awareness of the program life. For example, memory allocated during RTEMS initialization may appear to be leaked because it is never freed, but this is deliberate and the issue marked as such in Coverity Scan. You can get an account on [Coverity Scan](https://scan.coverity.com) and request access to the [RTEMS Project](https://scan.coverity.com/projects/rtems) to contribute. The current process for dealing with Coverity Scan is entirely manual. See, for example, [Google Code-In task instructions for Coverity](../wikis/GCI/Coding/CoverityIssues). This manual process has several drawbacks. The purpose of this GSoC Project would be to simplify the process of working with Coverity, and to automate it where possible. We have identified two starting directions, and encourage interested students to brainstorm on other ways to improve the Coverity Scan integration. **Reducing False Positives** + Static analysis suffers from a high number of false positives. Coverity Scan provides two methods for removing false positives. First is by creating an optional _modeling file_ to accommodate for special cases where the data flow analysis breaks, for example due to missing functions that are linked outside the analyzed source code. A modeling file usually is used to identify functions that terminate execution, allocate memory, or free memory. Second, source code annotations in specially formatted comments can also be used to suppress warnings. This project should determine which approach to take, and design/implement a path forward. - Static analysis suffers from a high number of false positives. Coverity Scan provides two methods for removing false - positives. First is by creating an optional _modeling file_ to accommodate - for special cases where the data flow analysis breaks, for example due to - missing functions that are linked outside the analyzed source code. A modeling - file usually is used to identify functions that terminate execution, allocate - memory, or free memory. Second, source code annotations in specially formatted - comments can also be used to suppress warnings. This project should determine which approach to take, and design/implement a path forward. **Testing Fixes** + Since security tools tend to be costly in terms of time or compute resources, they are normally run on nightly or even weekly builds rather than on every commit as done for typical continuous integration (CI). It can be tedious to merge commits to the development master and trigger a scan to determine if the issue has been fixed. Instead, we would like to develop fixes and trigger Coverity Scan as needed (subject to staying within the allowed scan rates). Coverity Scan integrates with Github and can be triggered to scan by merging new code to a specific git repository branch. As a first step, a special 'coverity' branch could be created for scanning commits that are pushed there, so that developers who are testing changes can work through the coverity branch before merging fixes into the master. Alternate solutions should be discussed with any mentors. - Since security tools tend to be costly in terms of time or compute resources, - they are normally run on nightly or even weekly builds rather than on every - commit as done for typical continuous integration (CI). It can be tedious to merge commits to the development master and trigger a scan to determine if the issue has been fixed. Instead, we would like to develop fixes and trigger Coverity Scan as needed (subject to staying within the allowed scan rates). - Coverity Scan - integrates with Github and can be triggered to scan by merging new code to a - specific git repository branch. - As a first step, a special 'coverity' branch could be created for scanning commits that are pushed there, so that developers who are testing changes can work through the coverity branch before merging fixes into the master. Alternate solutions should be discussed with any mentors.
Author: Gedare Bloom
2019-06-27T21:30:46.000Z
Description changed
The goal of this project is to create better workflows to incorporate static analysis using Coverity Scan into the RTEMS development and release cycle. Coverity Scan is a static analyzer that can identify various types of potential software defects. Coverity offers free use of this analyzer for free software projects. Issues identified for RTEMS are at https://scan.coverity.com/projects/rtems. Coverity Scan identifies POTENTIAL issues. Some may be real bugs. Others may indicate that Coverity Scan does not have full awareness of the program life. For example, memory allocated during RTEMS initialization may appear to be leaked because it is never freed, but this is deliberate and the issue marked as such in Coverity Scan. You can get an account on [Coverity Scan](https://scan.coverity.com) and request access to the [RTEMS Project](https://scan.coverity.com/projects/rtems) to contribute. The current process for dealing with Coverity Scan is entirely manual. See, for example, [Google Code-In task instructions for Coverity](../wikis/GCI/Coding/CoverityIssues). This manual process has several drawbacks. The purpose of this GSoC Project would be to simplify the process of working with Coverity, and to automate it where possible. We have identified two starting directions, and encourage interested students to brainstorm on other ways to improve the Coverity Scan integration. **Reducing False Positives** Static analysis suffers from a high number of false positives. Coverity Scan provides two methods for removing false positives. First is by creating an optional _modeling file_ to accommodate for special cases where the data flow analysis breaks, for example due to missing functions that are linked outside the analyzed source code. A modeling file usually is used to identify functions that terminate execution, allocate memory, or free memory. Second, source code annotations in specially formatted comments can also be used to suppress warnings. This project should determine which approach to take, and design/implement a path forward. **Testing Fixes** Since security tools tend to be costly in terms of time or compute resources, they are normally run on nightly or even weekly builds rather than on every commit as done for typical continuous integration (CI). It can be tedious to merge commits to the development master and trigger a scan to determine if the issue has been fixed. Instead, we would like to develop fixes and trigger Coverity Scan as needed (subject to staying within the allowed scan rates). Coverity Scan integrates with Github and can be triggered to scan by merging new code to a specific git repository branch. As a first step, a special 'coverity' branch could be created for scanning commits that are pushed there, so that developers who are testing changes can work through the coverity branch before merging fixes into the master. Alternate solutions should be discussed with any mentors. + **Coding Rule Scans** + Investigation on this direction is needed. Coverity supports for example a couple of MISRA rules: + https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/coverity-misra-standards-ds-ul.pdf + + These rules are not enabled currently. Would it be possible to enable a subset of these rules in our current setup?
Author: Gedare Bloom
2022-02-25T18:59:03.000Z
Description changed
- The goal of this project is to create better workflows to incorporate static analysis using Coverity Scan into the RTEMS development and release cycle. + The goal of this project is to create better workflows to incorporate static analysis into the RTEMS development and release cycle. This project can be done with other static analyzers such as Codiga + + == Mentors == + + Gedare Bloom, Joel Sherrill + + == Skills == + + Python, Data manipulation + + == Difficulty == + + This is a small (175-hour) project of medium difficulty. + + + == More Information == Coverity Scan is a static analyzer that can identify various types of potential software defects. Coverity offers free use of this analyzer for free software projects. Issues identified for RTEMS are at https://scan.coverity.com/projects/rtems. Coverity Scan identifies POTENTIAL issues. Some may be real bugs. Others may indicate that Coverity Scan does not have full awareness of the program life. For example, memory allocated during RTEMS initialization may appear to be leaked because it is never freed, but this is deliberate and the issue marked as such in Coverity Scan. You can get an account on [Coverity Scan](https://scan.coverity.com) and request access to the [RTEMS Project](https://scan.coverity.com/projects/rtems) to contribute. The current process for dealing with Coverity Scan is entirely manual. See, for example, [Google Code-In task instructions for Coverity](../wikis/GCI/Coding/CoverityIssues). This manual process has several drawbacks. The purpose of this GSoC Project would be to simplify the process of working with Coverity, and to automate it where possible. We have identified two starting directions, and encourage interested students to brainstorm on other ways to improve the Coverity Scan integration. **Reducing False Positives** Static analysis suffers from a high number of false positives. Coverity Scan provides two methods for removing false positives. First is by creating an optional _modeling file_ to accommodate for special cases where the data flow analysis breaks, for example due to missing functions that are linked outside the analyzed source code. A modeling file usually is used to identify functions that terminate execution, allocate memory, or free memory. Second, source code annotations in specially formatted comments can also be used to suppress warnings. This project should determine which approach to take, and design/implement a path forward. **Testing Fixes** Since security tools tend to be costly in terms of time or compute resources, they are normally run on nightly or even weekly builds rather than on every commit as done for typical continuous integration (CI). It can be tedious to merge commits to the development master and trigger a scan to determine if the issue has been fixed. Instead, we would like to develop fixes and trigger Coverity Scan as needed (subject to staying within the allowed scan rates). Coverity Scan integrates with Github and can be triggered to scan by merging new code to a specific git repository branch. As a first step, a special 'coverity' branch could be created for scanning commits that are pushed there, so that developers who are testing changes can work through the coverity branch before merging fixes into the master. Alternate solutions should be discussed with any mentors. **Coding Rule Scans** Investigation on this direction is needed. Coverity supports for example a couple of MISRA rules: https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/coverity-misra-standards-ds-ul.pdf These rules are not enabled currently. Would it be possible to enable a subset of these rules in our current setup?
Author: Amar Takhar
2024-04-25T20:47:12.079Z
changed the description
51 - Basic Support for Trace Compass¶
Id |
51 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2019-02-20T12:02:45.000Z |
Updated |
2025-09-19T01:06:39.771Z |
Milestone |
6.1 |
Labels |
gsoc, priority::normal, resolution::fixed, tickettype::project, tool, version::5 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The Trace Compass is a tool to analyse and display trace data. Trace data can be gathered from RTEMS applications via various means, for example: * RTEMS Trace Linker * Event Recording * Capture Engine
The goal of this project is to enable the Trace Compass to analyse and display some basic information using the Event Recording infrastructure. Basic information is defined by the Linux kernel trace support (lttng) and includes (see Trace Compass project explorer Tracing -> Traces -> Something):
kernel
Views
CPU usage
CPU usage
IRQ Analysis
IRQ Statistics
IRQ Table
IRQ vs Count
IRQ vs Time
Linux Kernel
Control Flow
Resources
Example data can be obtained from the Trace Visualization Labs.
Advanced support for Trace Compass could include dynamic memory traces, stack usage, network packet flow, etc.
There are four main problems.
Generation of sufficient trace events, currently the interrupt entry/exit events are not available for example.
The trace data must be transferred from the target system running the RTEMS application to a host computer running the Trace Compass (transfer via TCP is available, for UDP based transfer see rtems/rtos/rtems#3695).
The Trace Compass must be able to analyse and display the information obtained from the Event Recording.
The RTEMS user must be able to use this infrastructure. This requires that it is easy to use, availability of tutorials and documentation.
To tackle problem 3. there are two approaches possible. You can extend the Trace Compass to work with the trace data provided by RTEMS as is. Alternatively, the RTEMS trace data could be converted to Linux kernel trace data (lttng) which Trace Compass already understands.
Related topics are Common Trace Format, [Babeltrace](https://diamon.org/babeltrace/), [barectf](https://github.com/efficios/barectf), rtems/rtos/rtems#2961 and rtems/rtos/rtems#3028.
Skills Needed
You need good C and C++ skills with a proven record. You need to show socket level and networking programming skills. In case Trace Compass needs to be extended this requires Java skills and familiarity with the Eclipse framework. Knowledge of YAML and XML is helpful. High end RTEMS targets can generate a huge number of events per second (10MiB/s trace data is 1310720 events per second; on a 4GHz host processor this is 3051 instructions per event under real-time processing conditions) which imposes a considerable work load to modern host computers, so the host programs must work efficiently.
Difficulty
We consider this an advanced project.
Author: Amar Takhar
2024-04-26T01:34:43.182Z
assigned to @tracmigrate
Author: Trac Migrate
2019-05-31T10:01:13.000Z
Original author: sebastian.huber
The current stable version 1.5.6 of babeltrace does not have feature to convert live trace stream into CTF. This feature is currently in development and will be released in babeltrace 2.0
Author: Trac Migrate
2020-02-10T20:30:04.000Z
Original author: sebastian.huber
This project has been at least partially done during GSoC 2019 and further developed since then. For everyone picking up this project: Check carefully what can be extended.
Author: Trac Migrate
2020-04-02T08:58:00.000Z
Original author: sebastian.huber
Milestone set to rtems%”5.1”
Resolution set to ~”fixed”
Status changed from assigned to closed
Version set to ~”5”
Author: Amar Takhar
2024-04-25T20:47:06.238Z
changed the description
37 - RTEMS Testing TFTP Proxy Project¶
Id |
37 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Created |
2019-02-14T01:43:26.000Z |
Updated |
2025-09-19T01:06:39.663Z |
Milestone |
6.1 |
Labels |
gsoc, gsoc::ecosystem, old-indefinite, priority::normal, resolution::fixed, rtems::testing, tickettype::project, version::5 |
Link |
|
Merges |
0 |
RTEMS Testing TFTP Proxy Project¶
Mentors¶
Chris Johns
Status ==¶
Introduction =¶
This project involves working with the RTEMS Testing Tool that resides in the RTEMS Tools package and is part of the RTEMS Tools Project. The RTEMS Testing Tool provides a consistent way to test BSPs on different hardware. The tool aims to integrate with a wide range of testing tools and methods generating a consistent report for the RTEMS test suite.
An important part of test is testing on real hardware and this may use the TFTP protocol. The RTEMS Testing Tool contains a TFTP server so a single run of the tool results in a sequential run of the tests for the hardware. It also means there can only be a single test run on the host. These are both seen as limitation as the time to run all the tests on real hardware is long.
Project¶
The project is to develop a TFTP proxy in C++ that is built for a host when the RTEMS Tools project is build on a host. The TFTP is to take a configuration that maps the TFTP client IP address to a proxy port. The rtems-test tool can be configure to connect to the proxy port and so to a TFTP client which is the board running the tests.
The RTEMS Tool’s rtems-test command can test on hardware using the TFTP protocol and U-boot however the rtems-test command needs to be run as root because the standard TFTP port can only be used when root. A proxy can be run as root while the RTEMS Testing tool can be run as a user.
The U-Boot has support in the code to set a server IP address however there was no configuration option and the support is not built in by default. Using the server IP would mean standard U-Boot loaders shipped with boards could not be used.
Goal¶
Create a service or daemon that can run as
rootto proxy TFTP requests.Read an INI configuration file of TFTP Client IP address mapped to remote IP and port.
Send a request from a client to the configured remote IP and port and so
rtems-testfor that board.Provide optional logging via
syslog.Provide command line options to trace the proxy tool when integrating.
Prerequisite¶
Knowledge of C, C++ and Python programming languages.
Knowledge of Unix software and Unix networking protocols.
Knowledge of the RTEMS Tool’s Toolkit.
Requires Unix (Linux or FreeBSD) host.
Requires modern PC hardware. Building all tests and running takes.
A Zedboard, MicroZed or BeagleBone Black.
Optionally a Windows 10 machine to test and check.
Resources¶
Current RTEMS developers.
The existing RTEMS Testing Tool.
Tasks¶
The following are the tasks:
Proxy Tool ==¶
Build a program to:
1. Listen on the detault TFTP port for UDP requests 1. Extract the source IP address and locate the IP address and port. 1. Send the request to the remote IP address and port. 1. Determine if the TFTP protocol will continue between the client and the remote server or the proxy tool need to listen for the remote’s response to send to the client.
Configuration Files¶
Develop a simple configuration for management of boards and testers.
Acknowledgements¶
None.
Miscellaneous Sections¶
As the project progresses, you will need to add to the RTEMS Testing section of the User manual. This section does not currently exist but it should be present even in a skeleton form.
References¶
None
Author: Amar Takhar
2024-04-26T01:34:37.126Z
assigned to @chris
Author: Gedare Bloom
2020-01-14T20:58:57.000Z
Owner set to @chrisj
Status changed from new to assigned
Author: Chris Johns
2020-01-20T04:12:26.000Z
Resolution set to ~”fixed”
Status changed from assigned to closed
A Python command has been added to RTEMS Tools …
https://git.rtems.org/rtems-tools/tree/misc/rtems-tftp-proxy
Author: Amar Takhar
2024-04-25T20:47:03.929Z
changed the description
31 - Add Benchmarking statistics for block device drivers¶
Id |
31 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-05-09T12:56:49.000Z |
Updated |
2025-09-19T01:06:39.533Z |
Milestone |
6.1 |
Labels |
gsoc, gsoc::small, old-indefinite, priority::normal, resolution::wontfix, tickettype::task |
Link |
|
Merges |
0 |
Original author: madaari
Carry out benchmarking of different block device drivers(SDIO,SDHCI, UMS) and document the results
Author: Amar Takhar
2024-04-26T01:34:34.135Z
assigned to @tracmigrate
Author: Gedare Bloom
2022-02-25T18:16:59.000Z
Original author: madaari
Resolution set to ~”wontfix”
Status changed from assigned to closed
Author: Amar Takhar
2024-04-25T20:46:17.674Z
changed the description
26 - Add SDIO driver support to rtems-libbsd¶
Id |
26 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2018-05-09T12:10:45.000Z |
Updated |
2025-09-19T01:06:39.386Z |
Milestone |
6.1 |
Labels |
gsoc, gsoc::large, libbsd, old-indefinite, priority::normal, resolution::wontfix, tickettype::task |
Link |
|
Merges |
0 |
Original author: madaari
SDIO interface nowadays, is widely used for connecting WiFi/Bluetooth chips on ARM boards, like Wandboard, Raspberry Pi 3 or Banana Pi. Adding SDIO support to RTEMS will thus, allow us to exploit these features.
Author: Amar Takhar
2024-04-26T01:34:32.306Z
assigned to @tracmigrate
Author: Joel Sherrill
2022-02-04T18:48:52.000Z
Original author: madaari
I thought SDIO support was available in libbsd now with support for multiple BSPs. Is there something to this project I am missing or is it done?
Author: Gedare Bloom
2022-02-25T18:15:14.000Z
Original author: madaari
Resolution set to ~”wontfix”
Status changed from assigned to closed
Author: Amar Takhar
2024-04-25T20:46:15.191Z
changed the description
79 - GDB script entries in EXE¶
Id |
79 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Closed by |
Chris Johns |
Created |
2024-06-05T05:05:09.230Z |
Closed |
2025-02-01T21:48:36.687Z |
Updated |
2025-09-19T01:03:39.357Z |
Milestone |
6.1 |
Labels |
tool::gdb |
Link |
|
Merges |
0 |
Summary¶
This issue tracks patches we use to test how auto-loading works in GDB.
We know from Tom static support is not well done. It could be something we could work on and improve. A response in GDB IRC:
!`image.png <https://gitlab.rtems.org/-/project/uploads/b0dd26748d6a2f778be55dca4d55a8e6/image.png>`_
The GDB documentation is https://sourceware.org/gdb/current/onlinedocs/gdb.html/dotdebug_005fgdb_005fscripts-section.html#dotdebug_005fgdb_005fscripts-section
Author: Chris Johns
2024-06-05T05:05:12.870Z
Author: Chris Johns
2024-06-05T05:07:43.328Z
changed the description
Author: Chris Johns
2024-06-05T05:08:49.086Z
changed the description
Author: Suraj Kumar
2024-06-05T13:47:33.275Z
`cxx_vector_dbgtext.exe <https://gitlab.rtems.org/-/project/uploads/aa66d5366b31223ce16b61e1f84ccb3f/cxx_vector_dbgtext.exe>`_[create_dbgscript_path.py](/uploads/768d2401a834188069bc18eda5cc3125/create_dbgscript_path.py)
Author: Chris Johns
2024-06-11T06:06:20.853Z
I have review the coded. What I was after was:
diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c index 83f6342ab3..56d1e2eed0 100644 --- a/testsuites/samples/hello/init.c +++ b/testsuites/samples/hello/init.c @@ -35,10 +35,20 @@ const char rtems_test_name[] = "HELLO WORLD"; +/* Note: The "MS" section flags are to remove duplicates. */ +#define DEFINE_GDB_PY_SCRIPT(script_name) \\ + asm("\\ + .pushsection \\".debug_gdb_scripts\\", \\"MS\\",@progbits,1\\n\\ + .byte 1 /* Python */\\n\\ + .asciz \\"" script_name "\\"\\n\\ + .popsection \\n\\ + "); + static rtems_task Init( rtems_task_argument ignored ) { + DEFINE_GDB_PY_SCRIPT("rtems-gdb-init.py"); rtems_print_printer_fprintf_putc(&rtems_test_printer); TEST_BEGIN(); printf( "Hello World\\n" );Building the samples, which RTEMS does by default, generates this in the sections:
$ readelf -e build/arm/xilinx_zynq_a9_qemu/testsuites/samples/hello/init.c.579.o | grep gdb [ 7] .debug_gdb_script PROGBITS 00000000 000078 000013 00 MS 0 0 1however the section does not end up in the executable:
$ readelf -e build/arm/xilinx_zynq_a9_qemu/testsuites/samples/hello.exe | grep gdb $The
linkercmdneeds updating to place the.debug_gdb_scriptin the output.This approach will let us test what works with GDB and how to make it work.
Author: Chris Johns
2024-06-11T06:06:20.853Z
Updating the
linkcmds.basefile for ARM places it into the exe:diff --git a/bsps/arm/shared/start/linkcmds.base b/bsps/arm/shared/start/linkcmds.base index aeca87005b..f7596bc6df 100644 --- a/bsps/arm/shared/start/linkcmds.base +++ b/bsps/arm/shared/start/linkcmds.base @@ -437,6 +437,8 @@ SECTIONS { .ARM.attributes 0 : { KEEP (*(.ARM.attributes)) KEEP (*(.gnu.attributes)) } .note.gnu.arm.ident 0 : { KEEP (*(.note.gnu.arm.ident)) } /DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) } + /* GDB */ + .debug_gdb_scripts 0: { *(.debug_gdb_scripts) } /* * This is a RTEMS specific section to catch all unexpected input
Author: Chris Johns
2024-06-11T06:06:20.853Z
Running qemu and connecting with GDB shows this:
(gdb) info auto-load gdb-scripts: No auto-load scripts. local-gdbinit: Local .gdbinit file was not found. python-scripts: Loaded Script No rtems-gdb-init.pyI am not sure what it means yet and where GDB searched. GDB reported:
Reading symbols from /opt/work/chris/rtems/kernel/rtems.git/build/arm/xilinx_zynq_a9_qemu/testsuites/samples/hello.exe... warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts of file /opt/work/chris/rtems/kernel/rtems.git/build/arm/xilinx_zynq_a9_qemu/testsuites/samples/hello.exe. Use `info auto-load python-scripts [REGEXP]' to list them.
Author: Chris Johns
2024-06-11T06:06:20.853Z
GDB does not search the
auto-loadpaths with a script in.debug_gdb_scripts. Adding python text does execute then the executable is loaded. This is the path to follow.
Author: Suraj Kumar
2024-06-11T06:06:20.853Z
@chris GDB searches by default for scripts loaded in
.debug_gdb_scriptsin thesourcedirectory specified (which, by default iscwd). However, even for scripts loaded as text inside the section, a file name needs to be specified, and that filename needs to be in an auto-load safe path (as Christian noted, not doing so would be a security issue).May I please know what name you specified for the script when loading Python as text?
Author: Chris Johns
2024-06-11T06:06:20.853Z
I am working through this and I have provided the detail in a new thread closing this one.
Author: Chris Johns
2024-06-11T06:05:25.345Z
I have pushed some code to my personal repo that runs. The branch is https://gitlab.rtems.org/chris/rtems/-/commits/79-gdb-script-entries-in-exe. It modifies the
iostreamsample to add
The special section GDB searches
The linker command file change for the object file section to be written into the executable
And a vector in C++ to test pretty printing with
The GDB support is:
#define DEFINE_GDB_PY() \\ asm( \\ ".pushsection \\".debug_gdb_scripts\\", \\"MS\\",@progbits,1\\n" \\ ".byte 4\\n" \\ ".ascii \\"gdb.inlined-script\\\\n\\"\\n" \\ ".ascii \\"import sys\\\\n\\"\\n" \\ ".ascii \\"import os.path\\\\n\\"\\n" \\ ".ascii \\"sys.path.append(os.path.join(gdb.PYTHONDIR, 'rtems'))\\\\n\\"\\n" \\ ".ascii \\"print(sys.path)\\\\n\\"\\n" \\ ".ascii \\"print(gdb.PYTHONDIR)\\\\n\\"\\n" \\ ".ascii \\"import rtems.stdcxx as stdcxx\\\\n\\"\\n" \\ ".byte 0\\n" \\ ".popsection\\n" \\ )
This test code appends to Python’s system search path the RTEMS Python support. The
gdb.PYTHONDIRis the install prefix path as we assume GDB andrtems-toolsare installed under the same$prefix.Loads an RTEMS python script called
stdcxxfrom the RTEMS Python. This does not exist yet. This file will need to figure out the location of the GCC installlibstdcxxpython code and integrate it.The C++ test code is:
auto v = std::vector<int>({1, 2, 3, 5, 7, 8}); for (auto i: v) { std::cout << i << ' '; }The expected output is:
(gdb) p v $1 = std::vector of length 6, capacity 6 = {1, 2, 3, 5, 7, 8}
40 - Add RSB Support for CivetWeb¶
Id |
40 |
State |
closed |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Chris Johns |
Closed by |
Gedare Bloom |
Created |
2022-04-06T14:57:16.000Z |
Closed |
2025-01-28T05:54:22.740Z |
Updated |
2025-09-19T01:03:39.258Z |
Milestone |
6.1 |
Labels |
gsoc, gsoc::large, lang::python, network, project::large, tool::rtems-source-builder |
Link |
|
Merges |
0 |
Background¶
`CivetWeb <CivetWeb>`_(https://github.com/civetweb/civetweb) is a permissive licensed fork of the last permissively licensed Mongoose version. We would like to support CivetWeb on RTEMS as a third-party package.
Approach¶
There needs to be instructions to configure and building CivetWeb by hand and an RSB recipe for this. It needs to build against libbsd as a minimum and lwip is desirable.
Knowledge/Skills¶
C/C++, Python
Possible Mentors¶
@joel @chris @gedare @c-mauderer @opticron @vijay
Author: Amar Takhar
2024-04-26T01:34:38.134Z
assigned to @chris
Author: Gedare Bloom
2024-02-17T05:13:08.000Z
Description changed
[CivetWeb](CivetWeb)(https://github.com/civetweb/civetweb) is a permissive licensed fork of the last permissively licensed Mongoose version. There needs to be instructions for configure and building this by hand and an RSB recipe for this. It needs to build against libbsd as minimum and lwip is desirable. + + See also #4334 Possible Mentors: Joel Sherrill, Gedare Bloom, Chris Johns, etc Skills: C/C++ Difficulty: Easy
Owner set to @chrisj
Status changed from new to assigned
Author: Amar Takhar
2024-04-25T20:49:52.064Z
changed the description
Author: Gedare Bloom
2025-01-18T00:20:01.654Z
changed title from Add RSB Support for Civ{-i-}tWeb to Add RSB Support for Civ{+e+}tWeb
Author: Gedare Bloom
2025-01-18T00:20:01.680Z
changed the description
Author: Kinsey Moore
2025-01-28T05:52:29.041Z
This may be complete as of RSB commit d2f00ca6.
Author: Gedare Bloom
2025-01-28T05:52:28.795Z
59 - Add BSP for Polarfire based Beagle¶
Id |
59 |
State |
closed |
Type |
ISSUE |
Author |
Kinsey Moore |
Assignee(s) |
Kinsey Moore |
Closed by |
Kinsey Moore |
Created |
2022-03-02T14:01:52.000Z |
Closed |
2024-11-04T17:49:00.359Z |
Updated |
2025-09-19T01:03:39.126Z |
Milestone |
6.1 |
Labels |
bsp, gsoc, gsoc::large, priority::normal, tickettype::enhancement |
Link |
|
Merges |
0 |
There is a new RISC-V based Beagle based on the Polarfire SOC. This project is to create a BSP for that.
The following is a list of peripherals that have been identified based on information from https://www.microchip.com/en-us/products/fpgas-and-plds/system-on-chip-fpgas/polarfire-soc-fpgas
Another dev kit could be https://www.microchip.com/en-us/development-tool/mpfs-disco-kit
This ticket is related to the BeagleBoard 2022 GSoC effort: https://elinux.org/BeagleBoard/GSoC/Ideas-2022#RTEMS_on_RISC-V
As of 2022/3/1, at least these BSP components are supported:
CPU Cores (both E51 and U54)
Interrupt controller (PLIC)
Timer (CLINT)
UART (mmuart, 16550-compatible or close enough)
Unsupported:
Ethernet (mss-gem, not in libbsd or upstream FreeBSD, lwIP support unknown)
U54 MMU (bare and Sv39 modes)
There is Linux support under development for this. We need to pursue asking for dual-licensing at least the network driver as NXP did for qoriq.
All other peripherals have not been checked for existing support.
Mentors: Hesham, Kinsey, Joel, Chris, someone from Beagle community Skills: C
Author: Amar Takhar
2024-04-26T01:34:46.862Z
assigned to @opticron
Author: Kinsey Moore
2022-03-04T13:52:28.000Z
This ticket is related to the BeagleBoard 2022 GSoC effort: https://elinux.org/BeagleBoard/GSoC/Ideas-2022#RTEMS_on_RISC-V
Author: Joel Sherrill
2022-03-04T16:59:18.000Z
Description changed
+ + There is a new RISC-V based Beagle based on the Polarfire SOC. This project is to create a BSP for that. + The following is a list of peripherals that have been identified based on information from https://www.microchip.com/en-us/products/fpgas-and-plds/system-on-chip-fpgas/polarfire-soc-fpgas + This ticket is related to the BeagleBoard 2022 GSoC effort: https://elinux.org/BeagleBoard/GSoC/Ideas-2022#RTEMS_on_RISC-V + As of 2022/3/1, at least these BSP components are supported: + - CPU Cores (both E51 and U54) + * CPU Cores (both E51 and U54) ? ++ - Interrupt controller (PLIC) + * Interrupt controller (PLIC) ? ++ - Timer (CLINT) + * Timer (CLINT) ? ++ - UART (mmuart, 16550-compatible or close enough) + * UART (mmuart, 16550-compatible or close enough) ? ++ + Unsupported: + - Ethernet (mss-gem, not in libbsd or upstream FreeBSD, lwIP support unknown) + * Ethernet (mss-gem, not in libbsd or upstream FreeBSD, lwIP support unknown) ? ++ - U54 MMU (bare and Sv39 modes) + * U54 MMU (bare and Sv39 modes) ? ++ + + There is Linux support under development for this. We need to pursue asking for dual-licensing at least the network driver as NXP did for qoriq. All other peripherals have not been checked for existing support. + + Mentors: Hesham, Kinsey, Joel, Chris, someone from Beagle community + Skills: C
Summary changed from Add BSP for Polarfire to Add BSP for Polarfire based Beagle
Author: Gedare Bloom
2024-02-16T15:22:51.000Z
Description changed
There is a new RISC-V based Beagle based on the Polarfire SOC. This project is to create a BSP for that. The following is a list of peripherals that have been identified based on information from https://www.microchip.com/en-us/products/fpgas-and-plds/system-on-chip-fpgas/polarfire-soc-fpgas + + Another dev kit could be https://www.microchip.com/en-us/development-tool/mpfs-disco-kit This ticket is related to the BeagleBoard 2022 GSoC effort: https://elinux.org/BeagleBoard/GSoC/Ideas-2022#RTEMS_on_RISC-V As of 2022/3/1, at least these BSP components are supported: * CPU Cores (both E51 and U54) * Interrupt controller (PLIC) * Timer (CLINT) * UART (mmuart, 16550-compatible or close enough) Unsupported: * Ethernet (mss-gem, not in libbsd or upstream FreeBSD, lwIP support unknown) * U54 MMU (bare and Sv39 modes) There is Linux support under development for this. We need to pursue asking for dual-licensing at least the network driver as NXP did for qoriq. All other peripherals have not been checked for existing support. Mentors: Hesham, Kinsey, Joel, Chris, someone from Beagle community Skills: C
Author: Gedare Bloom
2024-02-17T05:20:14.000Z
Owner set to @kinsey
Status changed from new to assigned
Author: Amar Takhar
2024-04-25T20:49:45.844Z
changed the description
Author: Gedare Bloom
2024-10-26T19:14:13.865Z
Author: Kinsey Moore
2024-11-04T17:49:00.023Z
A bsp has been added to RTEMS for the BeagleV-Fire in rtems/rtos/rtems!194.
57 - Add Python initializer for gdb RTEMS specific support¶
Id |
57 |
State |
closed |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Chris Johns |
Closed by |
Gedare Bloom |
Created |
2022-02-25T17:03:13.000Z |
Closed |
2025-01-22T22:23:46.173Z |
Updated |
2025-09-19T01:03:38.992Z |
Milestone |
6.1 |
Labels |
gsoc, gsoc::small, old-indefinite, project::small, tool, tool::gdb |
Link |
|
Merges |
0 |
GDB needs an initialization hook in Python like the ones installed into ${prefix}/share/gdb for RTEMS installations.
Please see Chris Johns for further details.
Possible Mentors: Chris Johns Skills: Python, C Difficulty: Medium
Author: Amar Takhar
2024-04-26T01:34:46.040Z
assigned to @chris
Author: Joel Sherrill
2022-02-25T21:22:24.000Z
Description changed
GDB needs an initialization hook in Python like the ones installed into ${prefix}/share/gdb for RTEMS installations. Please see Chris Johns for further details. + + + Possible Mentors: Chris Johns + Skills: Python, C + Difficulty: Medium
Author: Chris Johns
2023-03-13T03:55:49.000Z
These links may be useful:
https://gcc.gnu.org/legacy-ml/libstdc++/2009-02/msg00056.html https://sourceware.org/gdb/onlinedocs/gdb/Python-Auto_002dloading.html
Author: Gedare Bloom
2024-02-17T05:16:10.000Z
Owner set to @chrisj
Status changed from new to assigned
Author: Amar Takhar
2024-04-25T20:49:40.726Z
changed the description
Author: Gedare Bloom
2025-01-22T22:23:12.085Z
Author: Gedare Bloom
2025-01-22T22:23:45.898Z
Substantial progress was made in last year’s GSoC.
73 - Make Stack Checker Error Handler Configurable¶
Id |
73 |
State |
closed |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Joel Sherrill |
Closed by |
Gedare Bloom |
Created |
2022-02-04T19:14:53.000Z |
Closed |
2025-01-18T01:33:30.786Z |
Updated |
2025-09-19T01:03:38.820Z |
Milestone |
6.1 |
Labels |
gsoc, gsoc::small, library, old-indefinite, priority::normal, project::small, rtems::kernel, tickettype::enhancement |
Link |
|
Merges |
0 |
Currently, the stack checker has a built in error reporting method that is invoked when it determines that a stack overflow has occurred. This should turned into a configuration point. The user should be able to provide their own handler for this.
As a check, when this is done, it should be possible for the stack checker to be enabled and printk() not pulled into an application.
Possible Mentors: Joel Sherrill, Gedare Bloom, Chris Johns Skills: C Difficulty: Easy
Author: Amar Takhar
2024-04-26T01:34:52.659Z
assigned to @joel
Author: Gedare Bloom
2022-02-07T14:50:50.000Z
Owner set to @joel
Status changed from new to assigned
Author: Joel Sherrill
2022-02-25T21:17:29.000Z
Description changed
Currently, the stack checker has a built in error reporting method that is invoked when it determines that a stack overflow has occurred. This should turned into a configuration point. The user should be able to provide their own handler for this. As a check, when this is done, it should be possible for the stack checker to be enabled and printk() not pulled into an application. + + Possible Mentors: Joel Sherrill, Gedare Bloom, Chris Johns + Skills: C + Difficulty: Easy
Author: Amar Takhar
2024-04-25T20:49:28.992Z
changed the description
Author: Gedare Bloom
2024-06-12T15:23:38.075Z
Author: Gedare Bloom
2024-06-22T22:31:31.889Z
mentioned in issue rtems/rtos/rtems#5047
Author: Gedare Bloom
2025-01-18T01:33:30.524Z
This has been mostly completed by a GSoC 2024 effort.
76 - dtc build failure on msys2 - all rtems6 target tools fail to build on Windows 10¶
Id |
76 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Closed by |
Amar Takhar |
Created |
2021-11-11T21:08:30.000Z |
Closed |
2024-10-03T02:38:53.002Z |
Updated |
2024-10-03T02:38:53.175Z |
Milestone |
6.1 |
Labels |
gsoc, gsoc::small, priority::normal, tickettype::defect, tool::rtems-source-builder |
Link |
|
Merges |
0 |
Original author: kgardas
I’m testing RSB git source updated 2021-11-10 and it fails on freshly installed msys2/windows 10 platform with:
karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems
$ ../source-builder/sb-check
RTEMS Source Builder - Check, 6 (efa44e47a7d2 modified)
Environment is ok
karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems
$ ../source-builder/sb-set-builder --prefix=/c/r/rr 6/rtems-sparc
RTEMS Source Builder - Set Builder, 6 (efa44e47a7d2 modified)
Build Set: 6/rtems-sparc
config: devel/dtc-1.6.0-1.cfg
package: dtc-1.6.0-x86_64-w64-mingw32-1
building: dtc-1.6.0-x86_64-w64-mingw32-1
error: building d1xwm1
Build FAILED
See error report: rsb-report-dtc-1.6.0-x86_64-w64-mingw32-1.txt
error: building d1xwm1
Build Set: Time 0:00:28.232196
Build FAILED
karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems
$
the problem report is attached.
Joel adds: dtc does not build on msys2. It requires fnmatch.h which is not present. Alternative fixes include finding an alternative for fnmatch on msys2, providing an implementation to be used on msys2, or adding gnulib which is a portability package to our RSB packages on msys2.
Also there may be other tickets for the same issue.
Possible Mentors: Karel Gardas Skills: C Difficulty: Medium
Author: Amar Takhar
2024-04-26T01:34:53.550Z
assigned to @tracmigrate
Author: Trac Migrate
2021-11-11T21:09:20.000Z
Original author: kgardas
Attachment rsb-report-dtc-1.6.0-x86_64-w64-mingw32-1.txt added
dtc compilation failure problem report.
Author: Joel Sherrill
2022-02-02T14:23:22.000Z
Original author: kgardas
Milestone set to rtems%”6.1”
Adding SoC as a ticket because I think this is a possible small SoC project. Possible solutions include adding gnulib to the RSB bset for msys2 or modifying dtc to use other APIs for this functionality.
Author: Joel Sherrill
2022-02-04T20:05:29.000Z
Original author: kgardas
Description changed
I'm testing RSB git source updated 2021-11-10 and it fails on freshly installed msys2/windows 10 platform with:karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems $ ../source-builder/sb-check RTEMS Source Builder - Check, 6 (efa44e47a7d2 modified) Environment is ok
karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems $ ../source-builder/sb-set-builder –prefix=/c/r/rr 6/rtems-sparc RTEMS Source Builder - Set Builder, 6 (efa44e47a7d2 modified) Build Set: 6/rtems-sparc config: devel/dtc-1.6.0-1.cfg package: dtc-1.6.0-x86_64-w64-mingw32-1 building: dtc-1.6.0-x86_64-w64-mingw32-1 error: building d1xwm1 Build FAILED See error report: rsb-report-dtc-1.6.0-x86_64-w64-mingw32-1.txt error: building d1xwm1 Build Set: Time 0:00:28.232196 Build FAILED
karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems $
the problem report is attached. + + Joel adds: dtc does not build on msys2. It requires fnmatch.h which is not present. Alternative fixes include finding an alternative for fnmatch on msys2, providing an implementation to be used on msys2, or adding gnulib which is a portability package to our RSB packages on msys2. + + Also there may be other tickets for the same issue.
Summary changed from RSB can’t build rtems-sparc target tools on Windows 10. to dtc build failure on msys2 - all rtems6 target tools fail to build on Windows 10
Author: Joel Sherrill
2022-02-25T21:15:50.000Z
Original author: kgardas
Description changed
I'm testing RSB git source updated 2021-11-10 and it fails on freshly installed msys2/windows 10 platform with:karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems $ ../source-builder/sb-check RTEMS Source Builder - Check, 6 (efa44e47a7d2 modified) Environment is ok
karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems $ ../source-builder/sb-set-builder –prefix=/c/r/rr 6/rtems-sparc RTEMS Source Builder - Set Builder, 6 (efa44e47a7d2 modified) Build Set: 6/rtems-sparc config: devel/dtc-1.6.0-1.cfg package: dtc-1.6.0-x86_64-w64-mingw32-1 building: dtc-1.6.0-x86_64-w64-mingw32-1 error: building d1xwm1 Build FAILED See error report: rsb-report-dtc-1.6.0-x86_64-w64-mingw32-1.txt error: building d1xwm1 Build Set: Time 0:00:28.232196 Build FAILED
karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems $
the problem report is attached. Joel adds: dtc does not build on msys2. It requires fnmatch.h which is not present. Alternative fixes include finding an alternative for fnmatch on msys2, providing an implementation to be used on msys2, or adding gnulib which is a portability package to our RSB packages on msys2. Also there may be other tickets for the same issue. + + Possible Mentors: Karel Gardas + Skills: C + Difficulty: Medium
Author: Chris Johns
2022-11-29T23:48:28.000Z
Original author: kgardas
status update?
Author: Gedare Bloom
2024-02-17T05:15:05.000Z
Original author: kgardas
Owner set to kgardas
Status changed from new to assigned
Author: Amar Takhar
2024-04-25T20:49:19.387Z
changed the description
Author: Amar Takhar
2024-10-03T02:38:53.241Z
moved to rtems/tools/rtems-source-builder#36
72 - Use thread-local storage for Newlib reentrancy objects¶
Id |
72 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2021-12-03T09:04:00.000Z |
Updated |
2024-04-26T01:34:51.859Z |
Milestone |
6.1 |
Labels |
gsoc, gsoc::large, priority::normal, qualification, resolution::fixed, tickettype::project, tool::newlib, version::7 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
Problem¶
The state of the art architectures supported by RTEMS have all efficient support for thread-local storage (MIPS has issues with thread-local storage, however, is MIPS state of the art?).
Newlib currently uses a huge object of type struct _reent to store thread-specific data. This object is returned by __getreent(). It is related to the __DYNAMIC_REENT__ Newlib configuration option which is always defined for RTEMS.
The reentrancy structure contains errno and also the standard input, output, and error file streams. This means that if an application only uses errno it has a dependency on the file stream support event if it does not use it. This is an issue for lower end targets and the pre-qualification of RTEMS.
Solution¶
One approach to disentangle the dependencies introduced by struct _reent is to get rid of this structure and replace the individual members of the structure with thread-local objects. For example, instead of
struct _reent {
int _errno;
__FILE *_stdin;
__FILE *_stdout;
__FILE *_stderr;
};
use
_Thread_local int _errno;
_Thread_local __FILE *_stdin;
_Thread_local __FILE *_stdout;
_Thread_local __FILE *_stderr;
Newlib already has access macros for the struct _reent members, for example:
#define _REENT_SIGNGAM(ptr) ((ptr)->_new._reent._gamma_signgam)
#define _REENT_RAND_NEXT(ptr) ((ptr)->_new._reent._rand_next)
#define _REENT_RAND48_SEED(ptr) ((ptr)->_new._reent._r48._seed)
#define _REENT_RAND48_MULT(ptr) ((ptr)->_new._reent._r48._mult)
#define _REENT_RAND48_ADD(ptr) ((ptr)->_new._reent._r48._add)
How-to Implement¶
The member access macros are incomplete. The first step is to use the Newlib configuration for RTEMS as is and rename all struct _reent members, for example add an TEMPORARY prefix to all member names, _errno to TEMPORARY_errno. Then add member access macros until Newlib builds again. Install this Newlib and check that RTEMS and libbsd compiles. Run the RTEMS and libbsd test suites to check for regressions.
In a second step to this for the _REENT_SMALL configuration of Newlib.
The third step is to add a new Newlib configuration option, for example _REENT_THREAD_LOCAL which turns the struct _reent members into thread-local objects with corresponding “member” access macros. Define _REENT to NULL.
Skills¶
C and assembly
Difficulty¶
This is a large (350-hour) project of hard difficulty.
Author: Amar Takhar
2024-04-26T01:34:51.829Z
assigned to @tracmigrate
Author: Joel Sherrill
2021-12-03T17:29:59.000Z
Original author: sebastian.huber
One issue with this is that TLS is not supported on all architectures. We would either have to have two methods (current and TLS) to do this or fix TLS everywhere.
Author: Trac Migrate
2021-12-03T19:20:33.000Z
Original author: sebastian.huber
I am not sure what the Newlib maintainer say if we try to add a third reentrancy approach. I guess for backward compatibility they want to keep the existing methods anyway.
Author: Chris Johns
2021-12-06T08:19:37.000Z
Original author: sebastian.huber
I would like to see
libdlsupport for TLS added to RTEMS.
Author: Trac Migrate
2022-01-28T07:35:58.000Z
Original author: sebastian.huber
In [changeset:”b519e509a953c25894700531c321f7213fa11e70/rtems” b519e50/rtems]:
sptests: Avoid a dependency on errno Avoid a dependency on errno which might be a thread-local object. The tests sp01, spstkalloc02, and sptls03 assume that no thread-local storage object is present. Update #4560.
Author: Trac Migrate
2022-01-28T07:38:25.000Z
Original author: sebastian.huber
Related discussion on libc-coord:
Author: Gedare Bloom
2022-02-25T18:27:59.000Z
Original author: sebastian.huber
Description changed
= Problem The state of the art architectures supported by RTEMS have all efficient support for thread-local storage (MIPS has issues with thread-local storage, however, is MIPS state of the art?). Newlib currently uses a huge object of type `struct _reent` to store thread-specific data. This object is returned by `__getreent()`. It is related to the `__DYNAMIC_REENT__` Newlib configuration option which is always defined for RTEMS. The reentrancy structure contains `errno` and also the standard input, output, and error file streams. This means that if an application only uses `errno` it has a dependency on the file stream support event if it does not use it. This is an issue for lower end targets and the pre-qualification of RTEMS. = Solution One approach to disentangle the dependencies introduced by `struct _reent` is to get rid of this structure and replace the individual members of the structure with thread-local objects. For example, instead of {{{#!c struct _reent { int _errno; __FILE *_stdin; __FILE *_stdout; __FILE *_stderr; }; }}} use {{{#!c _Thread_local int _errno; _Thread_local __FILE *_stdin; _Thread_local __FILE *_stdout; _Thread_local __FILE *_stderr; }}} Newlib already has access macros for the `struct _reent` members, for example: {{{#!c #define _REENT_SIGNGAM(ptr) ((ptr)->_new._reent._gamma_signgam) #define _REENT_RAND_NEXT(ptr) ((ptr)->_new._reent._rand_next) #define _REENT_RAND48_SEED(ptr) ((ptr)->_new._reent._r48._seed) #define _REENT_RAND48_MULT(ptr) ((ptr)->_new._reent._r48._mult) #define _REENT_RAND48_ADD(ptr) ((ptr)->_new._reent._r48._add) }}} = How-to Implement The member access macros are incomplete. The first step is to use the Newlib configuration for RTEMS as is and rename all `struct _reent` members, for example add an `TEMPORARY` prefix to all member names, `_errno` to `TEMPORARY_errno`. Then add member access macros until Newlib builds again. Install this Newlib and check that RTEMS and libbsd compiles. Run the RTEMS and libbsd test suites to check for regressions. In a second step to this for the `_REENT_SMALL` configuration of Newlib. The third step is to add a new Newlib configuration option, for example `_REENT_THREAD_LOCAL` which turns the `struct _reent` members into thread-local objects with corresponding "member" access macros. Define `_REENT` to `NULL`. + + = Skills = + C and assembly + + = Difficulty = + This is a large (350-hour) project of hard difficulty.
Author: Trac Migrate
2022-06-29T09:04:57.000Z
Original author: sebastian.huber
Milestone changed from rtems%”7.1” to rtems%”6.1”
Version changed from ~”7” to ~”6”
Author: Trac Migrate
2022-07-21T05:15:04.000Z
Original author: sebastian.huber
In [changeset:”57a569efe16c2b8e9579147fdd78ee909c7558d3/rtems” 57a569e/rtems]:
sptests: Disable Newlib reentrancy Update #4560.
Author: Trac Migrate
2022-07-21T05:15:06.000Z
Original author: sebastian.huber
In [changeset:”6d4b390f99af0e9d5873a3cb8ebaccfa05cbe37b/rtems” 6d4b390/rtems]:
Support _REENT_THREAD_LOCAL Newlib configuration In case the Newlib _REENT_THREAD_LOCAL configuration option is enabled, the struct _reent is not defined (there is only a forward declaration in <sys/reent.h>). Instead, the usual members of struct _reent are available as dedicatd thread-local storage objects. Update #4560.
Author: Trac Migrate
2022-07-21T08:25:04.000Z
Original author: sebastian.huber
In [changeset:”ae6e5983d801cc8c44bc9aa0c6ab85b7d23ac1e8/rtems-source-builder” ae6e598/rtems-source-builder]:
6/7: Update Newlib This makes the --enable-newlib-reent-thread-local (_REENT_THREAD_LOCAL_STORAGE) Newlib configuration option available. Update #4560.
Author: Trac Migrate
2022-07-21T08:25:05.000Z
Original author: sebastian.huber
In [changeset:”958de508aa141deb4c8a115560aeec80dbdad3e8/rtems-source-builder” 958de50/rtems-source-builder]:
newlib: Support --with/without-newlib-tls This RSB option defines if the --enable-newlib-reent-thread-local (_REENT_THREAD_LOCAL_STORAGE) Newlib configuration option is used or not. Update #4560.
Author: Trac Migrate
2022-07-21T08:25:06.000Z
Original author: sebastian.huber
In [changeset:”f4f5d43a98051f7562103aaa2ec7723c628c6947/rtems-source-builder” f4f5d43/rtems-source-builder]:
6/7: Use TLS in Newlib for some targets by default Use the --enable-newlib-reent-thread-local (_REENT_THREAD_LOCAL_STORAGE) Newlib configuration option on the aarch64, arm, nios2, powerpc, riscv, and sparc targets by default. Update #4560.
Author: Trac Migrate
2022-08-08T11:00:15.000Z
Original author: sebastian.huber
Attachment gcc-10-RTEMS-Use-local-exec-TLS-model-by-default.patch added
Author: Trac Migrate
2022-08-08T11:00:32.000Z
Original author: sebastian.huber
Attachment gcc-12-RTEMS-Use-local-exec-TLS-model-by-default.patch added
Author: Trac Migrate
2022-08-08T18:23:20.000Z
Original author: sebastian.huber
In [changeset:”eea379370116628dbe91f19e61ad6129aa1951ac/rtems-source-builder” eea3793/rtems-source-builder]:
6: Use local-exec TLS model by default Update #4560.
Author: Trac Migrate
2022-09-09T05:32:55.000Z
Original author: sebastian.huber
In [changeset:”91e8654b1151db78b19ddcfe0ad10e386a8f2fe3/rtems-docs” 91e8654/rtems-docs]:
user: Document RSB --with/without-newlib-tls Update #4560.
Author: Trac Migrate
2022-10-14T09:41:39.000Z
Original author: sebastian.huber
In [changeset:”b9212e242fd2cb4b7821eea942d414cc84c27006/rtems” b9212e2/rtems]:
sptls01: Disable file system and Newlib reentrancy Update #4560.
Author: Chris Johns
2022-11-29T22:38:23.000Z
Original author: sebastian.huber
Are we able to close this ticket?
Author: Trac Migrate
2022-11-30T08:59:07.000Z
Original author: sebastian.huber
Resolution set to ~”fixed”
Status changed from assigned to closed
Yes, I recently were able to integrate the final patch for GCC 13. A follow up activity is rtems/rtos/rtems#4765.
Author: Trac Migrate
2023-04-26T05:14:33.000Z
Original author: sebastian.huber
In [changeset:”908efe4393f158e6e83a1a9ecc84b469f43201fa/rtems-source-builder” 908efe4/rtems-source-builder]:
7: Use TLS in Newlib for m68k by default Update #4560.
Author: Amar Takhar
2024-04-25T20:49:22.256Z
changed the description
23 - Port RTEMS to Microblaze¶
Id |
23 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Joel Sherrill |
Created |
2017-02-06T02:59:16.000Z |
Updated |
2024-04-26T01:34:29.883Z |
Milestone |
6.1 |
Labels |
bsp, gsoc, priority::normal, resolution::fixed, tickettype::project, version::4.11 |
Link |
|
Merges |
0 |
Original author: tokencolour
Port RTEMS to Microblaze¶
Students: Past, Present, and Potential Students
Status: The tools build from RSB properly, but GDB is not compatible with current XDM (Xilinx Debugging Module), Xilinx GDB version is working fine.
Introduction: A new architecture port, not just BSP. Include a BSP for GDB simulator. Also needs BSP for more complete HW on simulator.
Goal: Update the preliminary Microblaze port, complete clock timer support, merge into RTEMS, and continue to improve the BSP/port.
Some work has been initiated here [1] (By Joel Sherrill and Hesham ALMatary) to get hello world working. It has been tested on Atlys FPGA board [2]. The BSP can run virtually on every FPGA board the Xilinx tools support building MicroBlaze on.
The work will need to be updated against the current RTEMS version and tools and then completed. There are multiple boards supported by qemu-system-microblaze. One of these should be suitable for completing the port including interrupts. It will require investigation to know if qemu includes networking support for the Microblaze but this is likely.
References¶
[2] www.digilentinc.com/atlys/
Author: Amar Takhar
2024-04-26T01:34:29.856Z
assigned to @joel
Author: Chris Johns
2017-08-14T00:04:23.000Z
Original author: tokencolour
Version ~”4.11” deleted
Author: Gedare Bloom
2020-01-14T20:53:20.000Z
Original author: tokencolour
Description changed
= Port RTEMS to Microblaze = **Students:** Past, Present, and Potential Students **Status:** The tools build from RSB properly, but GDB is not compatible with current XDM (Xilinx Debugging Module), Xilinx GDB version is working fine. **Introduction:** A new architecture port, not just BSP. Include a BSP for GDB simulator. Also needs BSP for more complete HW on simulator. - **Goal:** Concise statement of the overall goal of the project. Refine this initial statement to include: project deliverables (code, docs, testing), required/suggested methodology, standards of quality, possible goal extensions beyond the main objective. + **Goal:** Update the preliminary Microblaze port, complete clock timer support, merge into RTEMS, and continue to improve the BSP/port. - **Requirements:** List the requirements and level of expertise you estimate are required by the developer tackling this project will have to have: Required level of programming language(s), specific areas of RTEMS or tools, level of familiarity with RTEMS, cross-development, GNU/Linux, etx., development/documentation/testing tools, mathematical/algorithmic background, other desirable skills. - - **Resources:** Current RTEMS developers, papers, etc that may help you in this project. - - **Acknowledgements** - * who helped and did work * Some work has been initiated here [1] (By Joel Sherrill and Hesham ALMatary) to get hello world working. It has been tested on Atlys FPGA board [2]. The BSP can run virtually on every FPGA board the Xilinx tools support building MicroBlaze on. - - = Miscellaneous Sections = - - As the project progresses, you will need to add build instructions, etc and this page will evolve from a project description into a HOWTO. = References = * [1] https://github.com/heshamelmatary/rtems-microblaze * [2] www.digilentinc.com/atlys/ - **Other sections:** If you have more to say about the project that doesn't fit in the proposed sections of this template, feel free to add other sections at will.
Author: Joel Sherrill
2020-05-29T12:58:33.000Z
Original author: tokencolour
Description changed
= Port RTEMS to Microblaze = **Students:** Past, Present, and Potential Students **Status:** The tools build from RSB properly, but GDB is not compatible with current XDM (Xilinx Debugging Module), Xilinx GDB version is working fine. **Introduction:** A new architecture port, not just BSP. Include a BSP for GDB simulator. Also needs BSP for more complete HW on simulator. **Goal:** Update the preliminary Microblaze port, complete clock timer support, merge into RTEMS, and continue to improve the BSP/port. - * Some work has been initiated here [1] (By Joel Sherrill and Hesham ALMatary) to get hello world working. It has been tested on Atlys FPGA board [2]. The BSP can run virtually on every FPGA board the Xilinx tools support building MicroBlaze on. ? ---- - + Some work has been initiated here [1] (By Joel Sherrill and Hesham ALMatary) to get hello world working. It has been tested on Atlys FPGA board [2]. The BSP can run virtually on every FPGA board the Xilinx tools support building MicroBlaze on. + + The work will need to be updated against the current RTEMS version and tools and then completed. There are multiple boards supported by qemu-system-microblaze. One of these should be suitable for completing the port including interrupts. It will require investigation to know if qemu includes networking support for the Microblaze but this is likely. = References = * [1] https://github.com/heshamelmatary/rtems-microblaze * [2] www.digilentinc.com/atlys/
Author: Joel Sherrill
2021-11-11T17:54:41.000Z
Original author: tokencolour
Milestone changed from rtems%”Indefinite” to rtems%”6.1”
Resolution set to ~”fixed”
Status changed from new to closed
A Microblaze port and BSP for the KCU105 (HW and Qemu) have been merged. LWIP and libbsd should be supported soon. Closing.
Author: Amar Takhar
2024-04-25T20:45:21.645Z
changed the description