[RTEMS Project] Trac email verification for user: samtv

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: samtv
Verification Token: tErCFNRu

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: samtv

[RTEMS trac]

New user registration for user samtv

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #3716: Unit, integration and validation tests for space profile

[RTEMS trac]

#3716: Unit, integration and validation tests for space profile
-+---
 Reporter:  Sebastian Huber  |   Owner:  Sebastian Huber
 Type:  task |  Status:  assigned
 Priority:  normal   |   Milestone:  7.1
Component:  doc  | Version:  6
 Severity:  normal   |  Resolution:
 Keywords:  qualification|  Blocked By:  3199, 3717, 3718
 Blocking:  3701 |
-+---

Comment (by Sebastian Huber ):

 In [changeset:"aaa2491a617132dd193247e3a83a8978fe702f83/rtems-central"
 aaa2491/rtems-central]:
 {{{
 #!CommitTicketReference repository="rtems-central"
 revision="aaa2491a617132dd193247e3a83a8978fe702f83"
 spec: Add tests for compiler builtins

 On the arm target, __udivmoddi4() cannot be fully tested through normal
 integer divisions.

 Update #3716.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4986: Improve CONFIGURE_TICKS_PER_TIMESLICE configuration and documentation

[RTEMS trac]

#4986: Improve CONFIGURE_TICKS_PER_TIMESLICE configuration and documentation
-+--
 Reporter:  Sebastian Huber  |   Owner:  Sebastian Huber
 Type:  enhancement  |  Status:  closed
 Priority:  normal   |   Milestone:  6.1
Component:  config   | Version:  6
 Severity:  normal   |  Resolution:  fixed
 Keywords:   |  Blocked By:
 Blocking:   |
-+--

Comment (by Sebastian Huber ):

 In [changeset:"b83eb5dec947e01efb67a28242b0ce8cfee811f3/rtems"
 b83eb5d/rtems]:
 {{{
 #!CommitTicketReference repository="rtems"
 revision="b83eb5dec947e01efb67a28242b0ce8cfee811f3"
 doxygen: Fix constraints

 Somehow the constraints for CONFIGURE_TICKS_PER_TIMESLICE and
 CONFIGURE_EXTRA_MPCI_RECEIVE_SERVER_STACK got mixed up.

 Update #4986.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: 13935289

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: 13935289
Verification Token: hC4RYkWq

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: 13935289

[RTEMS trac]

New user registration for user 13935289

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #3716: Unit, integration and validation tests for space profile

[RTEMS trac]

#3716: Unit, integration and validation tests for space profile
-+---
 Reporter:  Sebastian Huber  |   Owner:  Sebastian Huber
 Type:  task |  Status:  assigned
 Priority:  normal   |   Milestone:  7.1
Component:  doc  | Version:  6
 Severity:  normal   |  Resolution:
 Keywords:  qualification|  Blocked By:  3199, 3717, 3718
 Blocking:  3701 |
-+---

Comment (by Sebastian Huber ):

 In [changeset:"43143040f00af26fcf6a8f9a7f9dbce3ff823b41/rtems"
 43143040/rtems]:
 {{{
 #!CommitTicketReference repository="rtems"
 revision="43143040f00af26fcf6a8f9a7f9dbce3ff823b41"
 validation: Test global construction on aarch64

 Update #3716.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #3716: Unit, integration and validation tests for space profile

[RTEMS trac]

#3716: Unit, integration and validation tests for space profile
-+---
 Reporter:  Sebastian Huber  |   Owner:  Sebastian Huber
 Type:  task |  Status:  assigned
 Priority:  normal   |   Milestone:  7.1
Component:  doc  | Version:  6
 Severity:  normal   |  Resolution:
 Keywords:  qualification|  Blocked By:  3199, 3717, 3718
 Blocking:  3701 |
-+---

Comment (by Sebastian Huber ):

 In [changeset:"b771385452535e6a1ab97d1fdbdd8e6aa7cc2de7/rtems"
 b7713854/rtems]:
 {{{
 #!CommitTicketReference repository="rtems"
 revision="b771385452535e6a1ab97d1fdbdd8e6aa7cc2de7"
 testsuites/unit: Add tests for compiler builtins

 On the arm target, __udivmoddi4() cannot be fully tested through normal
 integer divisions.

 Update #3716.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4991: RSB source and patch checksum updates

[RTEMS trac]

#4991: RSB source and patch checksum updates
-+--
 Reporter:  Chris Johns  |   Owner:  Chris Johns
 Type:  defect   |  Status:  assigned
 Priority:  normal   |   Milestone:  6.1
Component:  tool/rsb | Version:  6
 Severity:  normal   |  Resolution:
 Keywords:   |  Blocked By:
 Blocking:   |
-+--

Comment (by Chris Johns ):

 In [changeset:"aa19d914d3edf86c954bd0f4145cf2dc7790785c/rtems-source-
 builder" aa19d91/rtems-source-builder]:
 {{{
 #!CommitTicketReference repository="rtems-source-builder"
 revision="aa19d914d3edf86c954bd0f4145cf2dc7790785c"
 rtems: Checksum fixes

 Updates #4991
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4955: sparc: Potential stack corruption in uniprocessor configurations during start multitasking

[RTEMS trac]

#4955: sparc: Potential stack corruption in uniprocessor configurations during
start multitasking
-+--
 Reporter:  Sebastian Huber  |   Owner:  Sebastian Huber
 Type:  defect   |  Status:  closed
 Priority:  normal   |   Milestone:  6.1
Component:  arch/sparc   | Version:  6
 Severity:  critical |  Resolution:  fixed
 Keywords:  qualification|  Blocked By:
 Blocking:   |
-+--

Comment (by Sebastian Huber ):

 In [changeset:"e8132daf75bf208d0ab63c864f32250348fa4a6c/rtems"
 e8132da/rtems]:
 {{{
 #!CommitTicketReference repository="rtems"
 revision="e8132daf75bf208d0ab63c864f32250348fa4a6c"
 validation: Fix powerpc in test case

 The powerpc context switch restores the interrupt state.

 Update #4955.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: NigelW

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: NigelW
Verification Token: kfY9WX6f

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: NigelW

[RTEMS trac]

New user registration for user NigelW

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: seantang001

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: seantang001
Verification Token: WMPB2v_N

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: seantang001

[RTEMS trac]

New user registration for user seantang001

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: Chee-Tzu

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: Chee-Tzu
Verification Token: wIfGn0tZ

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: Chee-Tzu

[RTEMS trac]

New user registration for user Chee-Tzu

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] #5004: amd64 BSP general protection fault

[RTEMS trac]

#5004: amd64 BSP general protection fault
---+
  Reporter:  Matheus Pecoraro  |  Owner:  (none)
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:
 Component:  arch/x86_64   |Version:
  Severity:  normal|   Keywords:  x86_64
Blocked By:|   Blocking:
---+
 I kept getting a general protection fault whenever attempting to execute
 the amd64 BSP while preparing for my GSOC proposal.

 The GPF was being caused by an instruction attempting to move an SSE
 register to an address on the stack not aligned to 16 bytes. After some
 debugging I noticed that the code for setting up the stack frame for a
 context would result in it being misaligned by 8 bytes as to what is
 expected by the x86-64 SysV ABI, thus leading the compiler to unknowingly
 cause the exception (when control is transferred to the function entry
 point RSP+8 is supposed to be a multiple of 16, without this patch RSP
 itself was a multiple of 16).

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Password reset: abhinavmir

[RTEMS trac]

Password reset for user abhinavmir

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Password reset: abhinavmir

[RTEMS trac]

Password reset for user abhinavmir

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac password reset for user: abhinavmir

[RTEMS trac]

Your Trac password has been reset.

Here is your account information:

Login URL: 
Username: abhinavmir
Password: J9unGm2f

-- 
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: Suraj02

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: Suraj02
Verification Token: MM0RMz6B

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: Suraj02

[RTEMS trac]

New user registration for user Suraj02

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: the.m3chanic

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: the.m3chanic
Verification Token: 93DbyQ9t

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: the.m3chanic

[RTEMS trac]

New user registration for user the.m3chanic

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Password reset: Purva26

[RTEMS trac]

Password reset for user Purva26

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: Purva26

[RTEMS trac]

New user registration for user Purva26

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Password reset: Purva26

[RTEMS trac]

Password reset for user Purva26

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4623: Add RSB for LLVM targeting RTEMS

[RTEMS trac]

#4623: Add RSB for LLVM targeting RTEMS
-+-
 Reporter:  Joel Sherrill|   Owner:  Gedare
 |  Bloom
 Type:  enhancement  |  Status:  assigned
 Priority:  normal   |   Milestone:  Indefinite
Component:  tool | Version:
 Severity:  normal   |  Resolution:
 Keywords:  llvm, tools, gcc, llvm, ecosystem,   |  Blocked By:
  SoC, medium|
 Blocking:   |
-+-

Comment (by Hesham Almatary):

 To completely remove the reliance on GCC, this should also include
 building:
 * newlib
 * compiler-rt
 * libc++

 Clang might still need a driver for linking RTEMS targets

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: Purva26

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: Purva26
Verification Token: nd3KMu2D

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #3930: RISC-V Clang/LLVM support

[RTEMS trac]

#3930: RISC-V Clang/LLVM support
-+-
 Reporter:  Hesham Almatary  |   Owner:  Hesham Almatary
 Type:  task |  Status:  accepted
 Priority:  normal   |   Milestone:  Indefinite
Component:  rtems| Version:
 Severity:  normal   |  Resolution:
 Keywords:   |  Blocked By:  3931, 3932, 3933, 3934
 Blocking:   |
-+-

Comment (by Hesham Almatary):

 This is still needed I believe. The toolchain needs to build all deps
 first, which isn't supported by RSB yet.

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: qianli08002...@163.com

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: qianli08002...@163.com
Verification Token: 4QacqInf

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: qianli08002...@163.com

[RTEMS trac]

New user registration for user qianli08002...@163.com

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: MuhammadAtta158

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: MuhammadAtta158
Verification Token: 9kJosDAy

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: MuhammadAtta158

[RTEMS trac]

New user registration for user MuhammadAtta158

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] #5003: Make GCC ARM Cortex-A53 errata workarounds available

[RTEMS trac]

#5003: Make GCC ARM Cortex-A53 errata workarounds available
--+-
  Reporter:  Sebastian Huber  |  Owner:  Sebastian Huber
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  6.1
 Component:  arch/aarch64 |Version:  6
  Severity:  normal   |   Keywords:
Blocked By:   |   Blocking:
--+-
 The ARM Cortex-A53 processor has several chip errata. For two of them
 compiler workarounds are available. Make these errata workarounds
 available for RTEMS through a specialized A53 multilib:

 -mcpu=cortex-a53 -mfix-cortex-a53-835769 -mfix-cortex-a53-843419

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4862: score/ & bsps/: Unused input parameters

[RTEMS trac]

#4862: score/ & bsps/: Unused input parameters
---+--
 Reporter:  Daniel Páscoa  |   Owner:  Sebastian Huber
 Type:  enhancement|  Status:  closed
 Priority:  normal |   Milestone:  6.1
Component:  unspecified| Version:  6
 Severity:  normal |  Resolution:  fixed
 Keywords:  qualification  |  Blocked By:
 Blocking: |
---+--
Changes (by Sebastian Huber ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"7fafbede33ebea18c4e3fa9886905f436a5bc455/rtems-docs"
 7fafbed/rtems-docs]:
 {{{
 #!CommitTicketReference repository="rtems-docs"
 revision="7fafbede33ebea18c4e3fa9886905f436a5bc455"
 bsp-howto: Document clock driver arg parameter

 Close #4862.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #1977: mq_open lacks support of "mode" argument

[RTEMS trac]

#1977: mq_open lacks support of "mode" argument
--+
 Reporter:  Ralf Corsepius|   Owner:  Joel Sherrill
 Type:  defect|  Status:  new
 Priority:  low   |   Milestone:  Indefinite
Component:  score | Version:
 Severity:  normal|  Resolution:
 Keywords:  POSIX-Compliance  |  Blocked By:
 Blocking:|
--+

Comment (by Joel Sherrill):

 The parameter should not be removed. It needs to be fetched into a
 variable like attr around line 186 of mqueueopen.c. Currently it is
 "skipped" in the variable argument and not saved into a variable. It needs
 to be fetched and honored somehow when oflag includes O_CREAT. See
 https://pubs.opengroup.org/onlinepubs/009696699/functions/mq_open.html

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #1977: mq_open lacks support of "mode" argument

[RTEMS trac]

#1977: mq_open lacks support of "mode" argument
--+
 Reporter:  Ralf Corsepius|   Owner:  Joel Sherrill
 Type:  defect|  Status:  new
 Priority:  low   |   Milestone:  Indefinite
Component:  score | Version:
 Severity:  normal|  Resolution:
 Keywords:  POSIX-Compliance  |  Blocked By:
 Blocking:|
--+

Comment (by Abhinav (August) Radjoe):

 Would we want to implement other methods in such a way that `mod` is used
 or do we remove `mode`for now?

 Thx

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: abhinavmir

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: abhinavmir
Verification Token: ATS2y72n

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: abhinavmir

[RTEMS trac]

New user registration for user abhinavmir

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4862: score/ & bsps/: Unused input parameters

[RTEMS trac]

#4862: score/ & bsps/: Unused input parameters
---+--
 Reporter:  Daniel Páscoa  |   Owner:  Sebastian Huber
 Type:  enhancement|  Status:  assigned
 Priority:  normal |   Milestone:  6.1
Component:  unspecified| Version:  6
 Severity:  normal |  Resolution:
 Keywords:  qualification  |  Blocked By:
 Blocking: |
---+--

Comment (by Sebastian Huber ):

 In [changeset:"1df822a922dce3fd42399692a50c626609cbf2dd/rtems"
 1df822a/rtems]:
 {{{
 #!CommitTicketReference repository="rtems"
 revision="1df822a922dce3fd42399692a50c626609cbf2dd"
 Mark parameters as intentionally unused

 The parameters are unused due to API constraints.  The functions are
 used through function pointers.  Alternative implementations may use the
 parameters.

 Update #4862.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4862: score/ & bsps/: Unused input parameters

[RTEMS trac]

#4862: score/ & bsps/: Unused input parameters
---+--
 Reporter:  Daniel Páscoa  |   Owner:  Sebastian Huber
 Type:  enhancement|  Status:  assigned
 Priority:  normal |   Milestone:  6.1
Component:  unspecified| Version:  6
 Severity:  normal |  Resolution:
 Keywords:  qualification  |  Blocked By:
 Blocking: |
---+--

Comment (by Sebastian Huber ):

 In [changeset:"1eed6f8bfca86b77174412292ff7807708f4ab3a/rtems"
 1eed6f8/rtems]:
 {{{
 #!CommitTicketReference repository="rtems"
 revision="1eed6f8bfca86b77174412292ff7807708f4ab3a"
 bsps: Avoid unused argument in clock interrupt

 Pass the parameter of the clock interrupt handler to
 Clock_driver_support_at_tick() and Clock_driver_timecounter_tick().  This
 makes
 it possible to use the interrupt handler argument in clock drivers.

 Use the interrupt handler provided by Clock_driver_support_install_isr()
 to
 avoid local delarations of Clock_isr().

 Update #4862.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #5002: Add API to get and set interrupt priorities for interrupt vectors

[RTEMS trac]

#5002: Add API to get and set interrupt priorities for interrupt vectors
-+--
 Reporter:  Sebastian Huber  |   Owner:  Sebastian Huber
 Type:  enhancement  |  Status:  assigned
 Priority:  normal   |   Milestone:  6.1
Component:  rtems| Version:  6
 Severity:  normal   |  Resolution:
 Keywords:   |  Blocked By:
 Blocking:   |
-+--

Comment (by Gedare Bloom):

 Two basic questions:
 1. Does the priority field `type` need to be Architecture- or BSP-defined
 or is `uint32_t` always going to be fine.

 2. Does changing (increasing) the priority of a vector from within
 interrupt context possibly cause a pending interrupt to post that was
 previously at a lower priority than the currently masked priority level?
 In that case, it would cause a preemption to occur. I'm guessing this
 behavior could be architecture-specific.

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4986: Improve CONFIGURE_TICKS_PER_TIMESLICE configuration and documentation

[RTEMS trac]

#4986: Improve CONFIGURE_TICKS_PER_TIMESLICE configuration and documentation
-+--
 Reporter:  Sebastian Huber  |   Owner:  Sebastian Huber
 Type:  enhancement  |  Status:  closed
 Priority:  normal   |   Milestone:  6.1
Component:  config   | Version:  6
 Severity:  normal   |  Resolution:  fixed
 Keywords:   |  Blocked By:
 Blocking:   |
-+--

Comment (by Sebastian Huber ):

 In [changeset:"f5e42e5d9fae95e50f41a2ed71ee94e9908612c0/rtems-central"
 f5e42e5/rtems-central]:
 {{{
 #!CommitTicketReference repository="rtems-central"
 revision="f5e42e5d9fae95e50f41a2ed71ee94e9908612c0"
 spec: Fix CONFIGURE_TICKS_PER_TIMESLICE constraint

 Update #4986.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4986: Improve CONFIGURE_TICKS_PER_TIMESLICE configuration and documentation

[RTEMS trac]

#4986: Improve CONFIGURE_TICKS_PER_TIMESLICE configuration and documentation
-+--
 Reporter:  Sebastian Huber  |   Owner:  Sebastian Huber
 Type:  enhancement  |  Status:  closed
 Priority:  normal   |   Milestone:  6.1
Component:  config   | Version:  6
 Severity:  normal   |  Resolution:  fixed
 Keywords:   |  Blocked By:
 Blocking:   |
-+--
Changes (by Sebastian Huber ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"150c2e8b551e1cff3bcc914c02c6faea4cfbf395/rtems-docs"
 150c2e8/rtems-docs]:
 {{{
 #!CommitTicketReference repository="rtems-docs"
 revision="150c2e8b551e1cff3bcc914c02c6faea4cfbf395"
 c-user: Clarify CONFIGURE_TICKS_PER_TIMESLICE

 Close #4986.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4986: Improve CONFIGURE_TICKS_PER_TIMESLICE configuration and documentation

[RTEMS trac]

#4986: Improve CONFIGURE_TICKS_PER_TIMESLICE configuration and documentation
-+--
 Reporter:  Sebastian Huber  |   Owner:  Sebastian Huber
 Type:  enhancement  |  Status:  assigned
 Priority:  normal   |   Milestone:  6.1
Component:  config   | Version:  6
 Severity:  normal   |  Resolution:
 Keywords:   |  Blocked By:
 Blocking:   |
-+--

Comment (by Sebastian Huber ):

 In [changeset:"d62f299b3452329efc121bd546e1bc9cf2bf8af9/rtems"
 d62f299/rtems]:
 {{{
 #!CommitTicketReference repository="rtems"
 revision="d62f299b3452329efc121bd546e1bc9cf2bf8af9"
 Do not define CONFIGURE_TICKS_PER_TIMESLICE to 0

 Unconditionally make a CONFIGURE_TICKS_PER_TIMESLICE value less than or
 equal
 to zero an error.

 Update #4986.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4862: score/ & bsps/: Unused input parameters

[RTEMS trac]

#4862: score/ & bsps/: Unused input parameters
---+--
 Reporter:  Daniel Páscoa  |   Owner:  Sebastian Huber
 Type:  enhancement|  Status:  assigned
 Priority:  normal |   Milestone:  6.1
Component:  unspecified| Version:  6
 Severity:  normal |  Resolution:
 Keywords:  qualification  |  Blocked By:
 Blocking: |
---+--
Description changed by Sebastian Huber:

Old description:

> The following functions list input parameters on their signature that
> seem not to be used:
>
> ||=**File** =||= **Function** =||= **Line** =||
> ||bsps\shared\cache\cacheimpl.h||smp_cache_inst_inv_all ||293||
> ||bsps\shared\dev\clock\clockimpl.h||void Clock_isr||130||
> ||bsps\shared\dev\clock\clockimpl.h||rtems_isr Clock_isr||134||
> ||bsps\shared\irq\irq-
> generic.c||bsp_interrupt_allocate_handler_index||62||
> ||bsps\sparc\leon3\start\bspclean.c||bsp_fatal_extension||70||
> ||cpukit\score\src\threadchangepriority.c||static void
> _Thread_Priority_action_change( ); ||92||
> ||cpukit\score\src\threadq.c||_Thread_queue_MP_callout_do_nothing||157||
> ||cpukit\score\src\threadqenqueue.c||_Thread_queue_Deadlock_fatal||382||
> ||cpukit\score\src\threadqops.c||_Thread_queue_FIFO_do_initialize||137||
> ||cpukit\score\src\threadqtimeout.c||_Thread_queue_Add_timeout_ticks||28||
> ||cpukit\score\src\threadrestart.c||_Thread_Join_flush_filter||84||
> ||cpukit\score\src\userextiterate.c||_User_extensions_Thread_begin_visitor||102||
>

> Could one please double-check if in each case the unused parameters can
> be safely removed from the function’s signature? PS: The first functions
> are also implemented within .h files and perhaps could be moved to .c
> files.
>
> **Additional Notes:**
> This ticket was raised as an outcome of the Independent SW Verification
> and Validation (ISVV) for ESA-promoted RTEMS SMP Qualification Data Packs
> (https://rtems-qual.io.esa.int). The original ISVV reference for this
> issue is RTEMS-SMP-CODE-VER-028.

New description:

 The following functions list input parameters on their signature that seem
 not to be used:

 ||=**File** =||= **Function** =||= **Line** =||= **Resolution** ||
 ||bsps\shared\cache\cacheimpl.h||smp_cache_inst_inv_all ||293||Unused due
 to API constraints||
 ||bsps\shared\dev\clock\clockimpl.h||void Clock_isr||130||Fixed: parameter
 can be used||
 ||bsps\shared\dev\clock\clockimpl.h||rtems_isr Clock_isr||134||Fixed:
 parameter can be used||
 ||bsps\shared\irq\irq-
 generic.c||bsp_interrupt_allocate_handler_index||62||Fixed: parameter
 removed||
 ||bsps\sparc\leon3\start\bspclean.c||bsp_fatal_extension||70||API backward
 compatibility||
 ||cpukit\score\src\threadchangepriority.c||static void
 _Thread_Priority_action_change( ); ||92||Unused due to API constraints||
 ||cpukit\score\src\threadq.c||_Thread_queue_MP_callout_do_nothing||157||Unused
 due to API constraints||
 ||cpukit\score\src\threadqenqueue.c||_Thread_queue_Deadlock_fatal||382||Unused
 due to API constraints||
 ||cpukit\score\src\threadqops.c||_Thread_queue_FIFO_do_initialize||137||Unused
 due to API constraints||
 
||cpukit\score\src\threadqtimeout.c||_Thread_queue_Add_timeout_ticks||28||Unused
 due to API constraints||
 ||cpukit\score\src\threadrestart.c||_Thread_Join_flush_filter||84||Unused
 due to API constraints||
 
||cpukit\score\src\userextiterate.c||_User_extensions_Thread_begin_visitor||102||Unused
 due to API constraints||


 Could one please double-check if in each case the unused parameters can be
 safely removed from the function’s signature? PS: The first functions are
 also implemented within .h files and perhaps could be moved to .c files.

 **Additional Notes:**
 This ticket was raised as an outcome of the Independent SW Verification
 and Validation (ISVV) for ESA-promoted RTEMS SMP Qualification Data Packs
 (https://rtems-qual.io.esa.int). The original ISVV reference for this
 issue is RTEMS-SMP-CODE-VER-028.

--

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: disnoca

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: disnoca
Verification Token: EJrDNzDg

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: disnoca

[RTEMS trac]

New user registration for user disnoca

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] #5002: Add API to get and set interrupt priorities for interrupt vectors

[RTEMS trac]

#5002: Add API to get and set interrupt priorities for interrupt vectors
--+-
  Reporter:  Sebastian Huber  |  Owner:  Sebastian Huber
  Type:  enhancement  | Status:  assigned
  Priority:  normal   |  Milestone:  6.1
 Component:  rtems|Version:  6
  Severity:  normal   |   Keywords:
Blocked By:   |   Blocking:
--+-
 Modern interrupt controllers support interrupt priorities. There is
 currently no API in RTEMS to get or set interrupt priorities. Here is a
 proposal:
 {{{#!patch
 diff --git a/cpukit/include/rtems/rtems/intr.h
 b/cpukit/include/rtems/rtems/intr.h
 index f8809015e4..425e53797a 100644
 --- a/cpukit/include/rtems/rtems/intr.h
 +++ b/cpukit/include/rtems/rtems/intr.h
 @@ -9,7 +9,7 @@
   */

  /*
 - * Copyright (C) 2008, 2022 embedded brains GmbH & Co. KG
 + * Copyright (C) 2008, 2024 embedded brains GmbH & Co. KG
   * Copyright (C) 1988, 2008 On-Line Applications Research Corporation
 (OAR)
   *
   * Redistribution and use in source and binary forms, with or without
 @@ -1743,6 +1743,97 @@ rtems_status_code rtems_interrupt_raise_on(
   */
  rtems_status_code rtems_interrupt_clear( rtems_vector_number vector );

 +/* Generated from spec:/rtems/intr/if/get-priority */
 +
 +/**
 + * @ingroup RTEMSAPIClassicIntr
 + *
 + * @brief Gets the priority set of the interrupt vector.
 + *
 + * @param vector is the interrupt vector number.
 + *
 + * @param[out] priority is the pointer to an uint32_t object.  When the
 + *   directive call is successful, the priority of the interrupt vector
 will be
 + *   stored in this object.
 + *
 + * @retval ::RTEMS_SUCCESSFUL The requested operation was successful.
 + *
 + * @retval ::RTEMS_INVALID_ADDRESS The ``priority`` parameter was NULL.
 + *
 + * @retval ::RTEMS_INVALID_ID There was no interrupt vector associated
 with the
 + *   number specified by ``vector``.
 + *
 + * @retval ::RTEMS_UNSATISFIED There is no priority associated with the
 + *   interrupt vector.
 + *
 + * @par Notes
 + * The rtems_interrupt_set_priority() directive may be used to set the
 priority
 + * associated with an interrupt vector.
 + *
 + * @par Constraints
 + * @parblock
 + * The following constraints apply to this directive:
 + *
 + * * The directive may be called from within interrupt context.
 + *
 + * * The directive may be called from within device driver initialization
 + *   context.
 + *
 + * * The directive may be called from within task context.
 + *
 + * * The directive will not cause the calling task to be preempted.
 + * @endparblock
 + */
 +rtems_status_code rtems_interrupt_get_priority(
 +  rtems_vector_number vector,
 +  uint32_t   *priority
 +);
 +
 +/* Generated from spec:/rtems/intr/if/set-priority */
 +
 +/**
 + * @ingroup RTEMSAPIClassicIntr
 + *
 + * @brief Sets the priority of the interrupt vector.
 + *
 + * @param vector is the interrupt vector number.
 + *
 + * @param priority is the new priority for the interrupt vector.
 + *
 + * @retval ::RTEMS_SUCCESSFUL The requested operation was successful.
 + *
 + * @retval ::RTEMS_INVALID_ID There was no interrupt vector associated
 with the
 + *   number specified by ``vector``.
 + *
 + * @retval ::RTEMS_INVALID_PRIORITY The priority specified by
 ``priority`` was
 + *   not a valid new priority for the interrupt vector.
 + *
 + * @retval ::RTEMS_UNSATISFIED The request to set the priority of the
 interrupt
 + *   vector has not been satisfied.
 + *
 + * @par Notes
 + * The rtems_interrupt_get_priority() directive may be used to get the
 priority
 + * associated with an interrupt vector.
 + *
 + * @par Constraints
 + * @parblock
 + * The following constraints apply to this directive:
 + *
 + * * The directive may be called from within interrupt context.
 + *
 + * * The directive may be called from within device driver initialization
 + *   context.
 + *
 + * * The directive may be called from within task context.
 + *
 + * * The directive will not cause the calling task to be preempted.
 + * @endparblock
 + */
 +rtems_status_code rtems_interrupt_set_priority(
 +  rtems_vector_number vector,
 +  uint32_tpriority
 +);
 +
  /* Generated from spec:/rtems/intr/if/get-affinity */

  /**
 @@ -2020,6 +2111,28 @@ typedef struct {
 * rtems_interrupt_raise(), or rtems_interrupt_raise_on().
 */
rtems_interrupt_signal_variant trigger_signal;
 +
 +  /**
 +   * @brief This member is true, if the priority of the interrupt vector
 can be
 +   *   obtained by rtems_interrupt_get_priority(), otherwise it is false.
 +   */
 +  bool can_get_priority;
 +
 +  /**
 +   * @brief This member is true, if the priority of the interrupt vector
 can be
 +   *   set by rtems_interrupt_set_priority(), otherwise it is false.
 +   */
 +  bool can_set_priority;
 +
 +  /**
 +   * @brief This member represents the maximum priority value of the
 

Re: [RTEMS Project] #5001: LittleVGL URL Broken

[RTEMS trac]

#5001: LittleVGL URL Broken
---+-
 Reporter:  Joel Sherrill  |   Owner:  Christian Mauderer
 Type:  defect |  Status:  assigned
 Priority:  normal |   Milestone:
Component:  unspecified| Version:
 Severity:  normal |  Resolution:
 Keywords:  littlevgl  |  Blocked By:
 Blocking: |
---+-
Changes (by Joel Sherrill):

 * owner:  (none) => Christian Mauderer
 * status:  new => assigned


--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] #5001: LittleVGL URL Broken

[RTEMS trac]

#5001: LittleVGL URL Broken
+---
  Reporter:  Joel Sherrill  |  Owner:  (none)
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  unspecified|Version:
  Severity:  normal |   Keywords:  littlevgl
Blocked By: |   Blocking:
+---
 The URL https://docs.littlevgl.com/en/html/index.html used in the
 README.md appears to be broken.

 If LittleVGL changed their domain or organization, rtems-littlevgl needs a
 review and update.

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #5000: Implement POSIX Asynchronous IO

[RTEMS trac]

#5000: Implement POSIX Asynchronous IO
---+-
 Reporter:  Joel Sherrill  |   Owner:  (none)
 Type:  enhancement|  Status:  new
 Priority:  normal |   Milestone:
Component:  posix  | Version:
 Severity:  normal |  Resolution:
 Keywords:  SoC, POSIX |  Blocked By:
 Blocking: |
---+-

Old description:

> RTEMS does not currently support POSIX Asynchronous IO as defined by The
> Open Group. These methods and associated constants are prototyped by the
> [​http://www.opengroup.org/onlinepubs/009695399/basedefs/aio.h.html
> ] header file which is cpukit/posix/include/aio.h in the RTEMS
> source tree. The following methods have already been implemented but
> should be reviewed against the POSIX specification to ensure they are as
> complete as possible:
>
> - ​aio_read()
> ​- aio_write()
> ​- aio_cancel()
> ​- aio_error()
> ​- aio_return()
>
> The implementation of the above AIO methods includes a server thread
> which performs the user's AIO requests. These AIO methods request a
> SINGLE operation.
>
> The method ​lio_listio() is not implemented currently in RTEMS. The
> current implementation between the aio_ methods and the server thread
> will need to grow to support a list. The straightforward way to
> accomplish this is to modify the current aio_ infrastructure to treat a
> single aio_ request as a list of one. Then the lio_listio() should be a
> simple modification.
>
> The current implementation leans to a long-ish function to process AIO
> requests. This processing should be refactored so while iterating the
> list, the server thread calls a helper method for each request type.
>
> The implementation has a single server thread. The server thread
> characteristics such as stack size and priority should be application
> configurable.
>
> There will need to be tests added for the new functionality. Coverage
> will need to be reviewed for the AIO functionality.
>
> Possible Mentors: Joel Sherrill, Gedare Bloom, Chris Johns, Kinsey Moore

New description:

 RTEMS does not currently support POSIX Asynchronous IO as defined by The
 Open Group. These methods and associated constants are prototyped by the
 [​http://www.opengroup.org/onlinepubs/009695399/basedefs/aio.h.html
 ] header file which is cpukit/posix/include/aio.h in the RTEMS
 source tree. The following methods have already been implemented but
 should be reviewed against the POSIX specification to ensure they are as
 complete as possible:

 - ​aio_read()
 ​- aio_write()
 ​- aio_cancel()
 ​- aio_error()
 ​- aio_return()

 The implementation of the above AIO methods includes a server thread which
 performs the user's AIO requests. These AIO methods request a SINGLE
 operation.

 The method ​lio_listio() is not implemented currently in RTEMS. The
 current implementation between the aio_ methods and the server thread will
 need to grow to support a list. The straightforward way to accomplish this
 is to modify the current aio_ infrastructure to treat a single aio_
 request as a list of one. Then the lio_listio() should be a simple
 modification.

 The current implementation leans to a long-ish function to process AIO
 requests. This processing should be refactored so while iterating the
 list, the server thread calls a helper method for each request type.

 The implementation has a single server thread. The server thread
 characteristics such as stack size and priority should be application
 configurable.

 There will need to be tests added for the new functionality. Coverage will
 need to be reviewed for the AIO functionality.

 Possible Mentors: Joel Sherrill, Gedare Bloom, Chris Johns, Kinsey Moore

--

Comment (by Joel Sherrill):

 My thoughts on an implementation plan. The functionality of lio_listio()
 can be implemented by a series of incremental changes. Much of the
 functionality is already present in the existing aio_* methods. Some of
 these can happen in parallel. Ensure all AIO tests pass as modifications
 are made and new tests are added as needed.

 * Review existing AIO functions to gain understanding of the
 implementation and to check each POSIX function against the specification.
 If there is any missing functionality, this plan will have to be adjusted
 to account for that.

 * Refactor AIO processing so a helper method exists for processing
 existing AIO operations. Eventually these will be called for each
 requested operation in a list. Refactoring helper methods will make the
 server thread easier to read. Change no functionality in this step.
   - This is likely a good spot to submit a patch.

 * Modify the message structure between the aio_ functions and the server
 to include a number of messages. It is one for all aio_ operations and a
 user provided count for lio_listio. Included in this is modifying the
 server to process a list of requests.
   - This is likely a good spot to 

Re: [RTEMS Project] #4328: New APIs Added to POSIX Standard (202x) (was: New APIs Added to POSIX Standard (2021))

[RTEMS trac]

#4328: New APIs Added to POSIX Standard (202x)
-+-
 Reporter:  Joel Sherrill|   Owner:  Joel
 |  Sherrill
 Type:  enhancement  |  Status:  assigned
 Priority:  normal   |   Milestone:
Component:  posix| Version:
 Severity:  normal   |  Resolution:
 Keywords:  SoC, POSIX, compliance, API, |  Blocked By:
  kernel, small  |
 Blocking:   |
-+-
Description changed by Joel Sherrill:

Old description:

> The following is a draft of the edits a set of new APIs are coming to
> POSIX.
>
> https://www.opengroup.org/austin/docs/austin_1110.pdf
>
> Search for "+" for added lines. Some are text changes and others are API
> additions. Some like strlcat() have been around for ages. Others are new
> like pthread_cond_clockwait() and similar "clockwait" methods for many
> (all?) concurrency primitives.
>
> This ticket is to perform the analysis to identify the list of methods
> and constants that are added, determine if RTEMS/newlib/libbsd currently
> supports that, and file tickets as appropriate to add them to the RTEMS
> environment.
>
> The analysis can be done as part of a GSoC project proposal effort. The
> GSoC project itself would consist of adding missing methods. There appear
> to be groups of related methods and the resulting tickets should reflect
> what would be added as a set.
>
> I have not and likely will not soon make it through this document to make
> a list of the new APIs. This list would then need to be checked against
> RTEMS and newlib. It is clear we are missing an entire class of new
> concurrency methods.
>
> Possible Mentors: Joel Sherrill
> Skills: C
> Difficulty: Medium

New description:

 The following is a draft of the edits a set of new APIs are coming to
 POSIX.

 https://www.opengroup.org/austin/docs/austin_1110.pdf

 Search for "+" for added lines. Some are text changes and others are API
 additions. Some like strlcat() have been around for ages. Others are new
 like pthread_cond_clockwait() and similar "clockwait" methods for many
 (all?) concurrency primitives. Most of these additions will likely be
 implemented in Linux and/or FreeBSD and the POSIX specification usually
 aligns with those implementations.

 Note that the final version of POSIX 202x has not been published and
 access to the full draft standard is restricted. Access to an HTML version
 has historically been available through The Open Group once approved and
 published.

 This ticket is to perform the analysis to identify the list of methods and
 constants that are added per the document above or a newer version if
 available. Then determine if RTEMS/newlib/libbsd currently supports that,
 and file tickets as appropriate to add them to the RTEMS environment.

 The analysis can be done as part of a GSoC project proposal effort. The
 GSoC project itself would consist of adding missing methods. There appear
 to be groups of related methods and the resulting tickets should reflect
 what would be added as a set. Identifying potential permissive open source
 implementations that might be appropriate to incorporate should be done.

 I have not and likely will not soon make it through this document to make
 a list of the new APIs. This list would then need to be checked against
 RTEMS and newlib. It is clear we are missing an entire class of new
 concurrency methods.

 Possible Mentors: Joel Sherrill
 Skills: C
 Difficulty: Medium

--

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] #5000: Implement POSIX Asynchronous IO

[RTEMS trac]

#5000: Implement POSIX Asynchronous IO
+
  Reporter:  Joel Sherrill  |  Owner:  (none)
  Type:  enhancement| Status:  new
  Priority:  normal |  Milestone:
 Component:  posix  |Version:
  Severity:  normal |   Keywords:  SoC, POSIX
Blocked By: |   Blocking:
+
 RTEMS does not currently support POSIX Asynchronous IO as defined by The
 Open Group. These methods and associated constants are prototyped by the
 [​http://www.opengroup.org/onlinepubs/009695399/basedefs/aio.h.html
 ] header file which is cpukit/posix/include/aio.h in the RTEMS
 source tree. The following methods have already been implemented but
 should be reviewed against the POSIX specification to ensure they are as
 complete as possible:

 - ​aio_read()
 ​- aio_write()
 ​- aio_cancel()
 ​- aio_error()
 ​- aio_return()

 The implementation of the above AIO methods includes a server thread which
 performs the user's AIO requests. These AIO methods request a SINGLE
 operation.

 The method ​lio_listio() is not implemented currently in RTEMS. The
 current implementation between the aio_ methods and the server thread will
 need to grow to support a list. The straightforward way to accomplish this
 is to modify the current aio_ infrastructure to treat a single aio_
 request as a list of one. Then the lio_listio() should be a simple
 modification.

 The current implementation leans to a long-ish function to process AIO
 requests. This processing should be refactored so while iterating the
 list, the server thread calls a helper method for each request type.

 The implementation has a single server thread. The server thread
 characteristics such as stack size and priority should be application
 configurable.

 There will need to be tests added for the new functionality. Coverage will
 need to be reviewed for the AIO functionality.

 Possible Mentors: Joel Sherrill, Gedare Bloom, Chris Johns, Kinsey Moore

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: Hassan

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: Hassan
Verification Token: dz6xzYyw

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: Hassan

[RTEMS trac]

New user registration for user Hassan

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4999: missing bsp's in rtems 6.1 rc2

[RTEMS trac]

#4999: missing bsp's in rtems 6.1 rc2
--+-
 Reporter:  Heinz Junkes  |   Owner:  (none)
 Type:  defect|  Status:  closed
 Priority:  high  |   Milestone:  6.1
Component:  arch/powerpc  | Version:  6
 Severity:  blocker   |  Resolution:  fixed
 Keywords:  bsps  |  Blocked By:
 Blocking:|
--+-

Comment (by Chris Johns):

 The RTEMS deployment repo has more examples and possible ways to build BSP
 packages:

  https://git.rtems.org/chrisj/rtems-deployment.git/tree/config/epics

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4999: missing bsp's in rtems 6.1 rc2

[RTEMS trac]

#4999: missing bsp's in rtems 6.1 rc2
--+-
 Reporter:  Heinz Junkes  |   Owner:  (none)
 Type:  defect|  Status:  closed
 Priority:  high  |   Milestone:  6.1
Component:  arch/powerpc  | Version:  6
 Severity:  blocker   |  Resolution:  fixed
 Keywords:  bsps  |  Blocked By:
 Blocking:|
--+-

Comment (by Joel Sherrill):

 Is that kernel building command line equivalent? The BSP stack bsets
 include more than RTEMS -- they usually build the tools, rtems, network
 stack, and likely some support libraries. This is from BBB:


 {{{
 6/rtems-arm
 6/rtems-kernel
 6/rtems-libbsd
 6/rtems-packages
 }}}

 If you want that set easily buildable and not just RTEMS, some more BSPs
 need to get added.

 It would be a question for Chris, but I wonder if the RSB supports a way
 to have a template bset that the arch and bsp come from the command line.
 This could reduce it to 3 bsets (libbsd, lwip, and no networking). Just a
 thought.

 And FWIW every BSP bset gets built as part of the OAR build sweeper. Just
 as needed when there are changes requiring it.

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4999: missing bsp's in rtems 6.1 rc2

[RTEMS trac]

#4999: missing bsp's in rtems 6.1 rc2
--+-
 Reporter:  Heinz Junkes  |   Owner:  (none)
 Type:  defect|  Status:  closed
 Priority:  high  |   Milestone:  6.1
Component:  arch/powerpc  | Version:  6
 Severity:  blocker   |  Resolution:  fixed
 Keywords:  bsps  |  Blocked By:
 Blocking:|
--+-
Changes (by Heinz Junkes):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 but this works?
 ../source-builder/sb-set-builder --prefix=$HOME/development/rtems/6.1-rc2
 --target=powerpc-rtems6 --with-rtems-bsp=powerpc/beatnik --with-rtems-
 tests=yes 6/rtems-kernel

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] #4999: missing bsp's in rtems 6.1 rc2

[RTEMS trac]

#4999: missing bsp's in rtems 6.1 rc2
---+
  Reporter:  Heinz Junkes  |  Owner:  (none)
  Type:  defect| Status:  new
  Priority:  high  |  Milestone:  6.1
 Component:  arch/powerpc  |Version:  6
  Severity:  blocker   |   Keywords:  bsps
Blocked By:|   Blocking:
---+
 Only a few bsps are available as configurations (bsets). Not all that are
 listed in the documentation. E.g. 'beatnik' is missing.

 this is the output of
 ../source-builder/sb-set-builder --list-bsets
 ...
 bsps/atsamv.bset
 bsps/beagleboneblack.bset
 bsps/erc32.bset
 bsps/gr712rc.bset
 bsps/gr740.bset
 bsps/imx7.bset
 bsps/pc.bset
 bsps/qoriq_e500.bset
 bsps/qoriq_e6500_32.bset
 bsps/qoriq_e6500_64.bset
 bsps/raspberrypi2.bset
 bsps/xilinx_zynq_zc702.bset
 bsps/xilinx_zynq_zc706.bset
 bsps/xilinx_zynq_zedboard.bset
 ...

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Password reset: jun...@fhi-berlin.mpg.de

[RTEMS trac]

Password reset for user jun...@fhi-berlin.mpg.de

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Password reset: jun...@fhi-berlin.mpg.de

[RTEMS trac]

Password reset for user jun...@fhi-berlin.mpg.de

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac password reset for user: jun...@fhi-berlin.mpg.de

[RTEMS trac]

Your Trac password has been reset.

Here is your account information:

Login URL: 
Username: jun...@fhi-berlin.mpg.de
Password: 0QeYYzJh

-- 
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: mpec

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: mpec
Verification Token: wl5OMA-d

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: mpec

[RTEMS trac]

New user registration for user mpec

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: Ashish Baghel

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: Ashish Baghel
Verification Token: L85RfNyz

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: Ashish Baghel

[RTEMS trac]

New user registration for user Ashish Baghel

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: Ranulfo

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: Ranulfo
Verification Token: pOxyyaLq

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: Ranulfo

[RTEMS trac]

New user registration for user Ranulfo

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: AlessandroNardin

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: AlessandroNardin
Verification Token: eP5M7QtB

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: AlessandroNardin

[RTEMS trac]

New user registration for user AlessandroNardin

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #3716: Unit, integration and validation tests for space profile

[RTEMS trac]

#3716: Unit, integration and validation tests for space profile
-+---
 Reporter:  Sebastian Huber  |   Owner:  Sebastian Huber
 Type:  task |  Status:  assigned
 Priority:  normal   |   Milestone:  7.1
Component:  doc  | Version:  6
 Severity:  normal   |  Resolution:
 Keywords:  qualification|  Blocked By:  3199, 3717, 3718
 Blocking:  3701 |
-+---

Comment (by Matt Joyce ):

 In [changeset:"461f118ad005a27c648b437a9869d11fd3b087bd/rtems"
 461f118a/rtems]:
 {{{
 #!CommitTicketReference repository="rtems"
 revision="461f118ad005a27c648b437a9869d11fd3b087bd"
 validation/tc-sched-smp: Fix synchronization issue

 Update #3716.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: atharvd440

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: atharvd440
Verification Token: joS8UiiR

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: atharvd440

[RTEMS trac]

New user registration for user atharvd440

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: sverreexspandsome

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: sverreexspandsome
Verification Token: nOrzEqw0

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: sverreexspandsome

[RTEMS trac]

New user registration for user sverreexspandsome

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: Devolution

[RTEMS trac]

New user registration for user Devolution

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: Guleon

[RTEMS trac]

New user registration for user Guleon

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: Himanshu

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: Himanshu
Verification Token: N0jyoTmN

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: Himanshu

[RTEMS trac]

New user registration for user Himanshu

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4349: Package Micro Python

[RTEMS trac]

#4349: Package Micro Python
--+--
 Reporter:  eshan dhawan  |   Owner:  Chris Johns
 Type:  enhancement   |  Status:  assigned
 Priority:  normal|   Milestone:  Indefinite
Component:  tool/rsb  | Version:
 Severity:  normal|  Resolution:
 Keywords:  SoC, API, medium  |  Blocked By:
 Blocking:|
--+--
Description changed by Gedare Bloom:

Old description:

> MicroPython (https://micropython.org/) is supported in RTEMS for a long
> time but isn't packaged well. Packaging it would mainly involve the
> following:
>
> * ensure MicroPython builds and works
> * construct an RSB Recipe
> * implement example(s)
> * provide documentation.
>
> The RSB Recipe will default to a generally useful configuration. If there
> are tuning options to MicroPython, these will have to be available to
> tweaked by the user.  If MicroPython requires specific features enabled
> in RTEMS, these will have to be checked for. If there are add-on
> libraries that are needed, the RSB Recipe will have to address these. All
> of these configuring and dependencies are a critical part of the user
> facing RTEMS documentation on this package.
>
> The examples should include a basic minimal example of embedded
> MicroPython in an application and using it. There should be another
> example which shows to integrate an application specific feature into the
> MicroPython environment. There should be an example of integrating an
> RTEMS shell command and invoking it from MicroPython. If there are other
> application uses cases identified for MicroPython, there may be other
> requirements for the examples.
>
> The user facing documentation should make it easy for a user to build
> MicroPython and use it in their examples.
>
> Having MicroPython packaged is important but an important side product of
> this effort is defining the pattern for the kit for supporting an
> embedded language with RTEMS.
>
> == Skills ==
> Python
>
> == Difficulty ==
>
> This is a small (175-hour) project of easy difficulty.

New description:

 MicroPython (https://micropython.org/) is supported in RTEMS for a long
 time but isn't packaged well. Packaging it would mainly involve the
 following:

 * ensure MicroPython builds and works
 * construct an RSB Recipe
 * implement example(s)
 * provide documentation.

 The RSB Recipe will default to a generally useful configuration. If there
 are tuning options to MicroPython, these will have to be available to
 tweaked by the user.  If MicroPython requires specific features enabled in
 RTEMS, these will have to be checked for. If there are add-on libraries
 that are needed, the RSB Recipe will have to address these. All of these
 configuring and dependencies are a critical part of the user facing RTEMS
 documentation on this package.

 The examples should include a basic minimal example of embedded
 MicroPython in an application and using it. There should be another
 example which shows to integrate an application specific feature into the
 MicroPython environment. There should be an example of integrating an
 RTEMS shell command and invoking it from MicroPython. If there are other
 application uses cases identified for MicroPython, there may be other
 requirements for the examples.

 The user facing documentation should make it easy for a user to build
 MicroPython and use it in their examples.

 Having MicroPython packaged is important but an important side product of
 this effort is defining the pattern for the kit for supporting an embedded
 language with RTEMS.

 == Skills ==
 Python

 == Difficulty ==

 This is a medium (175-hour) project of easy difficulty.

--

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: seifalrahman

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: seifalrahman
Verification Token: 5SlUZrK4

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Trac email verification for user: seifalrahman

[RTEMS trac]

Please visit the following URL to confirm your email address.

Verification URL: 
Username: seifalrahman
Verification Token: hKKbu4Cn

-- 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] New user registration: seifalrahman

[RTEMS trac]

New user registration for user seifalrahman

--
RTEMS Project 
RTEMS Project

___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4997: GMP not building when not installed

[RTEMS trac]

#4997: GMP not building when not installed
-+---
 Reporter:  Chris Johns  |   Owner:  joel
 Type:  defect   |  Status:  assigned
 Priority:  normal   |   Milestone:  6.1
Component:  tool/rsb | Version:  6
 Severity:  normal   |  Resolution:
 Keywords:   |  Blocked By:
 Blocking:   |
-+---

Comment (by Chris Johns):

 Replying to [comment:2 Joel Sherrill]:
 > The build of gdb now depends on gmp-devel.

 Yes, it has for a while and we have building gmp for a while as a result.

 > I don't know if we want to include gmp in the rsb bset or not. But once
 I loaded that package, it built.

 Please remove the package and retest. It is included in the build setsfor
 the RTEMS tools. Please have a look in the defaults build sets for the 6
 release.

 > This is on CentOS 7 with the software collection to have gcc 8 and
 Python 3.

 Python 3 is now required because GDB requires it. The RTEMS tools commands
 are still python 2 compatible however pushing to a more recent GDB means
 we all need python 3.

 > CentOS 7 default is a gcc 4.8 and Python 2 which is insufficient.

 I do not use Linux and I do not know what this means?

 > Should we update the CentOS 7 recommendations in the Users Guide?

 To say what? The issue is not needing the package but why it was not built
 when it should be. Can you please debug this?

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4998: Add support for C11 Annex K Bounds Checking Functions

[RTEMS trac]

#4998: Add support for C11 Annex K Bounds Checking Functions
---+-
 Reporter:  Joel Sherrill  |   Owner:  (none)
 Type:  enhancement|  Status:  new
 Priority:  normal |   Milestone:
Component:  tool/newlib| Version:
 Severity:  normal |  Resolution:
 Keywords:  C11, SoC, newlib, medium, API  |  Blocked By:
 Blocking: |
---+-
Changes (by Gedare Bloom):

 * keywords:  C11, SoC, newlib, medium => C11, SoC, newlib, medium, API


Old description:

> C11 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf) Annex K
> defines a set of alternatives to many Standard C Library functions that
> perform bounds checking. It is desirable to support these in RTEMS.
>
> Since these functions are prototyped in standard C header files, it would
> be nice to have these merged into newlib and prototyped in the header
> files included there. Prototypes of Annex K functions need to be guarded
> by the _STDC_LIB_EXT1_ cpp define. That would be defined by OS in
> sys/features.h
>
> There is at least one implementation or possibly forks of one
> implementation based on there being multiple "safelibc" projects on
> github.com with permissive licenses. One of the first steps in this
> project is to determine which upstream project is the official version
> and should be the one used for the source. The following repositories as
> a minimum have been identified:
>
> * https://github.com/sbaresearch/slibc
> * https://github.com/rurban/safeclib
> * https://github.com/coruus/safeclib
>

> Since the goal is to have the code merged into newlib, there will need to
> be a list of files and git hash from the source repository so it is
> possible to easily track updates.
>
> Mentors: Joel Sherrill, Gedare Bloom, and possibly others

New description:

 == Description ==
 C11 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf) Annex K
 defines a set of alternatives to many Standard C Library functions that
 perform bounds checking. It is desirable to support these in RTEMS.

 Since these functions are prototyped in standard C header files, it would
 be nice to have these merged into newlib and prototyped in the header
 files included there. Prototypes of Annex K functions need to be guarded
 by the _STDC_LIB_EXT1_ cpp define. That would be defined by OS in
 sys/features.h

 There is at least one implementation or possibly forks of one
 implementation based on there being multiple "safelibc" projects on
 github.com with permissive licenses. One of the first steps in this
 project is to determine which upstream project is the official version and
 should be the one used for the source. The following repositories as a
 minimum have been identified:

 * https://github.com/sbaresearch/slibc
 * https://github.com/rurban/safeclib
 * https://github.com/coruus/safeclib

 Since the goal is to have the code merged into newlib, there will need to
 be a list of files and git hash from the source repository so it is
 possible to easily track updates.

 == Mentors ==
 Mentors: Joel Sherrill, Gedare Bloom, and possibly others

 == Skills ==
 C, autoconf

 == Difficulty ==
 Moderate

--

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] #4998: Add support for C11 Annex K Bounds Checking Functions

[RTEMS trac]

#4998: Add support for C11 Annex K Bounds Checking Functions
+--
  Reporter:  Joel Sherrill  |  Owner:  (none)
  Type:  enhancement| Status:  new
  Priority:  normal |  Milestone:
 Component:  tool/newlib|Version:
  Severity:  normal |   Keywords:  C11, SoC, newlib, medium
Blocked By: |   Blocking:
+--
 C11 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf) Annex K
 defines a set of alternatives to many Standard C Library functions that
 perform bounds checking. It is desirable to support these in RTEMS.

 Since these functions are prototyped in standard C header files, it would
 be nice to have these merged into newlib and prototyped in the header
 files included there. Prototypes of Annex K functions need to be guarded
 by the _STDC_LIB_EXT1_ cpp define. That would be defined by OS in
 sys/features.h

 There is at least one implementation or possibly forks of one
 implementation based on there being multiple "safelibc" projects on
 github.com with permissive licenses. One of the first steps in this
 project is to determine which upstream project is the official version and
 should be the one used for the source. The following repositories as a
 minimum have been identified:

 * https://github.com/sbaresearch/slibc
 * https://github.com/rurban/safeclib
 * https://github.com/coruus/safeclib


 Since the goal is to have the code merged into newlib, there will need to
 be a list of files and git hash from the source repository so it is
 possible to easily track updates.

 Mentors: Joel Sherrill, Gedare Bloom, and possibly others

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4995: powerpc/qoriq_e6500_64 rtems-syms unknown machine type (cloned)

[RTEMS trac]

#4995: powerpc/qoriq_e6500_64 rtems-syms unknown machine type (cloned)
---+--
 Reporter:  Joel Sherrill  |   Owner:  Sebastian Huber
 Type:  defect |  Status:  closed
 Priority:  normal |   Milestone:  6.1
Component:  lib/dl | Version:  6
 Severity:  normal |  Resolution:  fixed
 Keywords: |  Blocked By:
 Blocking:  4996   |
---+--
Changes (by Sebastian Huber ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"e7d5f9c0091b3491d662591e4c5c7ee3ae81aa70/rtems-tools"
 e7d5f9c/rtems-tools]:
 {{{
 #!CommitTicketReference repository="rtems-tools"
 revision="e7d5f9c0091b3491d662591e4c5c7ee3ae81aa70"
 rld: Recognize 64-bit PowerPC

 Close #4995.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4974: rtems-tools buid failed with '--host=x86_64-w64-mingw32'

[RTEMS trac]

#4974: rtems-tools buid failed with '--host=x86_64-w64-mingw32'
--+
 Reporter:  zhengxiaojun  |   Owner:  zhengxiaojun 
 Type:  defect|  Status:  closed
 Priority:  normal|   Milestone:  6.1
Component:  tool  | Version:  6
 Severity:  normal|  Resolution:  fixed
 Keywords:|  Blocked By:
 Blocking:|
--+
Changes (by zhengxiaojun ):

 * owner:  (none) => zhengxiaojun 
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"ce16c8084093f8a54afdd2d22954e41588a2bc81/rtems-tools"
 ce16c808/rtems-tools]:
 {{{
 #!CommitTicketReference repository="rtems-tools"
 revision="ce16c8084093f8a54afdd2d22954e41588a2bc81"
 add libiberty/argv.c for mingw32 build

 Signed-off-by: zhengxiaojun 

 Close #4974.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4997: GMP not building when not installed

[RTEMS trac]

#4997: GMP not building when not installed
-+---
 Reporter:  Chris Johns  |   Owner:  joel
 Type:  defect   |  Status:  assigned
 Priority:  normal   |   Milestone:  6.1
Component:  tool/rsb | Version:  6
 Severity:  normal   |  Resolution:
 Keywords:   |  Blocked By:
 Blocking:   |
-+---

Comment (by Joel Sherrill):

 The build of gdb now depends on gmp-devel. I don't know if we want to
 include gmp in the rsb bset or not. But once I loaded that package, it
 built.

 This is on CentOS 7 with the software collection to have gcc 8 and Python
 3. CentOS 7 default is a gcc 4.8 and Python 2 which is insufficient.
 Should we update the CentOS 7 recommendations in the Users Guide?

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4993: Increase FD_SETSIZE to 256

[RTEMS trac]

#4993: Increase FD_SETSIZE to 256
-+
 Reporter:  Chris Johns  |   Owner:  Joel Sherrill
 Type:  defect   |  Status:  assigned
 Priority:  highest  |   Milestone:  6.1
Component:  tool/newlib  | Version:  6
 Severity:  blocker  |  Resolution:
 Keywords:   |  Blocked By:
 Blocking:   |
-+

Comment (by Joel Sherrill):

 Patch submitted to newlib. When I get acked to push it, I will let you
 know so you can bump the newlib hash to pick the change to 256 up.

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4993: Increase FD_SETSIZE to 256

[RTEMS trac]

#4993: Increase FD_SETSIZE to 256
-+
 Reporter:  Chris Johns  |   Owner:  Joel Sherrill
 Type:  defect   |  Status:  assigned
 Priority:  highest  |   Milestone:  6.1
Component:  tool/newlib  | Version:  6
 Severity:  blocker  |  Resolution:
 Keywords:   |  Blocked By:
 Blocking:   |
-+
Changes (by Chris Johns):

 * owner:  Chris Johns => Joel Sherrill


--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4969: Update libibery sources in rtems-tools

[RTEMS trac]

#4969: Update libibery sources in rtems-tools
-+--
 Reporter:  Chris Johns  |   Owner:  Chris Johns
 Type:  defect   |  Status:  closed
 Priority:  normal   |   Milestone:  6.1
Component:  tool | Version:  6
 Severity:  normal   |  Resolution:  fixed
 Keywords:   |  Blocked By:
 Blocking:   |
-+--

Comment (by Sebastian Huber ):

 In [changeset:"489565f330da91bbcf35b4a51504c6cf5d32c6fb/rtems-tools"
 489565f/rtems-tools]:
 {{{
 #!CommitTicketReference repository="rtems-tools"
 revision="489565f330da91bbcf35b4a51504c6cf5d32c6fb"
 rtemstoolkit/libiberty: Add missing file

 This fixes the following build error for --host=x86_64-w64-mingw32:

 rtemstoolkit/libiberty.a(pex-win32.c.18.o): in function `win32_spawn':
 rtemstoolkit/libiberty/pex-win32.c:643: undefined reference to `writeargv'

 Update #4969.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #4997: GMP not building when not installed

[RTEMS trac]

#4997: GMP not building when not installed
-+---
 Reporter:  Chris Johns  |   Owner:  joel
 Type:  defect   |  Status:  assigned
 Priority:  normal   |   Milestone:  6.1
Component:  tool/rsb | Version:  6
 Severity:  normal   |  Resolution:
 Keywords:   |  Blocked By:
 Blocking:   |
-+---

Comment (by Chris Johns):

 Joel,

 Can you please detail the operating system?

 Can you please remove the installed `gmp-devel` package and then check if
 the GMP is built? Please add `--trace` to the RSB command line.

 Thanks
 Chris

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] #4997: GMP not building when not installed

[RTEMS trac]

#4997: GMP not building when not installed
--+--
  Reporter:  Chris Johns  |  Owner:  joel
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  6.1
 Component:  tool/rsb |Version:  6
  Severity:  normal   |   Keywords:
Blocked By:   |   Blocking:
--+--
 Email from Joel to `devel`:

 rtems 6.1rc2 has a lot of tool build failures because I didn't have gmp-
 devel installed.
 {{{
 Checking for gmp.h... no
 configure: error: gmp.h header not found
 }}}
 This is reported as part of building `gcc-newlib`. Should the RSB account
 for this by building gmp at the same time?

 For now, I installed a host `gmp-devel` and restarted the build sweep.

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] #4996: libdl: Add 64-bit PowerPC ELFv2 support

[RTEMS trac]

#4996: libdl: Add 64-bit PowerPC ELFv2 support
--+-
  Reporter:  Sebastian Huber  |  Owner:  Sebastian Huber
  Type:  enhancement  | Status:  assigned
  Priority:  normal   |  Milestone:  6.1
 Component:  lib/dl   |Version:  6
  Severity:  normal   |   Keywords:
Blocked By:  4995 |   Blocking:
--+-
 Support libdl on 64-bit PowerPC ELFv2 targets.

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Re: [RTEMS Project] #3627: powerpc/qoriq_e6500_64 rtems-syms unknown machine type

[RTEMS trac]

#3627: powerpc/qoriq_e6500_64 rtems-syms unknown machine type
---+-
 Reporter:  Joel Sherrill  |   Owner:  (none)
 Type:  defect |  Status:  closed
 Priority:  normal |   Milestone:  Indefinite
Component:  lib/dl | Version:  5
 Severity:  normal |  Resolution:  wontfix
 Keywords: |  Blocked By:
 Blocking: |
---+-
Changes (by Sebastian Huber):

 * status:  new => closed
 * resolution:   => wontfix


--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] #4995: powerpc/qoriq_e6500_64 rtems-syms unknown machine type (cloned)

[RTEMS trac]

#4995: powerpc/qoriq_e6500_64 rtems-syms unknown machine type (cloned)
+-
  Reporter:  Joel Sherrill  |  Owner:  Sebastian Huber
  Type:  defect | Status:  assigned
  Priority:  normal |  Milestone:  6.1
 Component:  lib/dl |Version:  6
  Severity:  normal |   Keywords:
Blocked By: |   Blocking:
+-
 Cloned from #3627:
 
 rtems-syms does not know 64-bit powerpc.

 {{{
 gmake[5]: Entering directory `/data/home/joel/rtems-work/rtems-
 testing/rtems/build-powerpc-qoriq_e6500_64-rtems/powerpc-
 rtems5/c/qoriq_e6500_64/testsuites/libtests'
 rtems-syms -e -c "-mcpu=e6500 -m64 -fno-common -O2 -g -ffunction-sections
 -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration
 -Wstrict-prototypes -Wnested-externs" -o dl07-sym.o dl07.pre
 error: machine-type: unknown machine type: 21

 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

[RTEMS Project] Batch modify: #1825, #1830, #1831, #1835, #1836, ...

[RTEMS trac]

Batch modification to #1825, #1830, #1831, #1835, #1836, #1840, #1843, #1846, 
#1847, #1849, #1850, #1852, #1859, #1860, #1863, #1866, #1874, #1875, #1878, 
#1880, #1881, #1887, #1888, #1903 by chrisj:
component to test

--
Tickets URL: 

RTEMS Project 
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs