RTEMS 5.2 Embedded Realtime Operating System

Table of Content


RTEMS Release 5.2

RTEMS 5.2 Release Notes

API Changes

  • Termios
    • txTaskCharsDequeued has been added to struct rtems_termios_tty. With that the size of the structure changed. Libraries and applications that use the structure should be recompiled.
    • The l_start line discipline function now receives the number of characters that have been sent. It is save to ignore the extra parameter for applications that don't need it.

API Additions

  • NTP support
    • Addition of NTP update second handler via _Timecounter_Set_NTP_update_second() from <rtems/score/timecounter.h>

RTEMS 5.2 Ticket Overview

Total Closed In_progress New Assigned Percentage
105 105 0 0 0 100%


RTEMS 5.2 Ticket Summary

ID Status Summary
2746 closed RTEMS gdb python script do not load.
2830 closed throwing std::runtime on PC BSP fails.
3347 closed tms570: Register Macro Redefinition
3540 closed How To Use SPARC memscrub
3571 closed Stream of Unicode Warnings from git hook on Commit
3601 closed Block device disk management implementation can underflow rtems_disk_device.uses
3619 closed Docs location for docs.rtems.org
3641 closed Gitlab mirror
4011 closed Test compilation error in riscv bsps
4024 closed NFS Client is broken on 64-bit targets
4058 closed RSB 5/rtems-riscv fails to build on Windows
4059 closed RSB: UnicodeDecodeError
4060 closed The reworked <rtems/confdefs.h> has a cyclic dependency with RTEMS_MULTIPROCESSING enabled
4064 closed RSB needs to support waf with no python command
4068 closed arm: arm_cp15_set_translation_table_entries() should affect Inner Shareable domain
4071 closed RSB does not pass BSP options correctly.
4073 closed libbsd: Back port ifmcstat command
4075 closed POSIX Compliance Guide Missing Some math.h Methods
4082 closed License files missing on 5-freebsd-12 branch
4092 closed bsps/pc386: Add missing license header
4094 closed RSB: pkgconfig.py uses python2 specific "unicode" keyword
4096 closed shell: CRTL-U sets the cursor to the wrong position
4099 closed Enhance rtems-bsps to print canonical names of bsps
4102 closed rtems-pairs includes invalid BSP
4106 closed RSB Missing BSP bset for xilinx_zynq_a9_qemu
4114 closed Cortex-A9 MPCore based BSPs should include the workaround for Errata 794072 and 845369
4119 closed rtems-bsp-tester: Off By One for Completed Jobs
4149 closed RFS bit map search buffer overflow
4154 closed Improve the workaround for the LEON3FT store-store errata: TN-0009
4165 closed Fix NVMe disk synchronization and media block handling (cloned)
4169 closed Link problem of C++ tests when using libpci in BSP
4174 closed devctl.h does not compile from C++
4185 closed arm/bsps: Small MMU pages are rounded to 1 MiB (cloned)
4189 closed rtems_interrupt_server_delete() does not destroy the ISR lock of the server control (cloned)
4190 closed Back port rtems_interrupt_server_create() improvements
4224 closed Missing "extern" in RTEMS_LINKER_ROSET_ITEM_ORDERED_DECLARE() (cloned)
4232 closed Timeout for automatic barriers is broken (cloned)
4233 closed MVME 2600/2700 has no console output (cloned)
4234 closed powerpc/motorola_shared display current RTEMS on boot
4236 closed bsps/zynq: termios not working correctly for stdin
4247 closed Change motorola_powerpc bsp to support irq-generic (cloned)
4248 closed PowerPC shared ISA IRQ support is broken (cloned)
4249 closed fix mkimage.py script type processing
4263 closed Activate ehci_pci in rtems-libbsd
4266 closed motorola_powerpc bootloader images not linking correctly
4274 closed GR1553RT driver: fixes to memory allocation and locking on descriptor updates
4275 closed GR1553B: use new codec available in GR740 revision 1
4303 closed grlib,gr1553bc: better check of the DMA area address alignment
4304 closed grlib,grspw: SET_PACKET_SIZE could use old DMA address
4305 closed grlib,ambapp: update GRLIB IP core ID list
4306 closed grlib,can: introduce a new common CAN baud-rate timing calculating functions
4307 closed grlib,grcanfd: extend the GRCAN driver with GRCANFD support
4308 closed grlib,greth: added support for variable sized descriptor table sizes
4309 closed bsps,leon3: avoid BSP dependency on apbuart/timer driver
4310 closed bsps,leon3: BSP assumes that timer pre-scaler runs at 1MHz
4311 closed bsps,leon3: _st64() did not follow the SPARC ABI
4312 closed bsps,leon3: need to make cpucounter restart after underflow
4313 closed grlib,grspw_router: add function to control SpaceWire run clock divisor
4314 closed grlib,ahbstat: add new register definitions for AHBSTAT version 1
4315 closed grlib,l2cache: prevent unused diagnostic access
4316 closed grlib,grspw_pkt: SpaceWire link-state defines corrected
4347 closed Allow RTEMS_PRIORITY for MrsP semaphores
4357 closed rtems_semaphore_set_priority() uses an invalid SMP lock (cloned)
4359 closed Priority discipline is broken for semaphores and message queues in SMP configurations (cloned)
4369 closed RTEMS5: Add driver for cadence-spi device for xilinx based BSPs (cloned)
4370 closed RTEMS5: Add spi driver for AXI SPI ip core from Xilinx (cloned)
4371 closed RTEMS5: Shell: Backport commands for spi and i2c
4394 closed Workspace initialization is broken for arm/imx7 and arm/raspberrypi
4409 closed rtems_task_start() does not check that the entry point is not equal to NULL
4429 closed clock_nanosleep() may use wrong clock for relative times (cloned)
4452 closed libbsd/i386: Include header error through bus.h
4456 closed bsps/i386: TSC calibration inaccurate (cloned)
4505 closed posix_devctl() should return the errno directly not -1 and set errno
4512 closed Count of postponed jobs is not set to zero for a newly created rate-monotonic period object (cloned)
4514 closed Support MVME2307 DEC Tulip driver
4515 closed Make [out/in] le and be calls conditional
4516 closed Map LibBSD bus space to the PCI base address for motorola_powerpc BSP
4520 closed Re-add lost capability for custom stack allocator to allocate IDLE thread stacks
4523 closed gdb 9.1 no longer builds on Cygwin (thread local error)
4549 closed Timecounter: Add NTP support (cloned)
4567 closed Atomic store does not use the order parameter for C++ (cloned)
4649 closed tcpdump: Fix dumping to file and reading from file
4651 closed if_atsam: Fix checksum offload, add multicast and VLAN support
4653 closed pfctl: Fix global state initialization
4655 closed sync() whould synchronize all file descriptors
4676 closed incorrect handling of "inactive_per_block" from "Objects_Information" structure
4683 closed Leaked BSP section flags in Makefile.inc breaks EPICS
4687 closed Documentation List for Releases Completely Missing 5.x
4704 closed Fix invalid RSB source URLs
4709 closed Installed header break C++
4711 closed RSB does not expand dir type macros correctly (cloned)
4715 closed RSB get sources misses a number of files
4716 closed Backport RSB fixes from Development
4717 closed Add RSB Deployment support
4725 closed Git commit message format instrunctions (cloned)
4727 closed RSB decode exception stops build
4731 closed rtems-source-builder doesn't generate tar archives for all packages any more
4733 closed Set top in RSB version.py
4734 closed RSB decode exception stops build
4752 closed RTEMS docs do not build with a recent sphinx
4754 closed Set RSB GDB source path to https
4755 closed Docs build system does not build singlehtml
4757 closed RSB freetype 2.4.10 source not hosted any longer
4758 closed Net-Snmp referenced patch missing
4761 closed RSB fatal error on missing hash checksums (cloned)


RTEMS 5.2 Tickets By Category

Owner

Owner Closed Total Progress
  11 11 11/11
Chris Johns 29 29 29/29
Pavel Pisa 1 1 1/1
Amar Takhar 3 3 3/3
Daniel Hellstrom 18 18 18/18
Needs Funding 2 2 2/2
Sebastian Huber 24 24 24/24
Joel Sherrill <joel@…> 2 2 2/2
Ryan Long <ryan.long@…> 2 2 2/2
Stephen Clark <stephen.clark@…> 1 1 1/1
Joel Sherrill 3 3 3/3
Jan Sommer <jan.sommer@…> 3 3 3/3
Jan Sommer 5 5 5/5
Christian Mauderer 1 1 1/1

Type

Type Closed Total Progress
defect 86 86 86/86
infra 1 1 1/1
enhancement 15 15 15/15
task 3 3 3/3

Priority

Priority Closed Total Progress
high 2 2 2/2
normal 102 102 102/102
low 1 1 1/1

Component

Component Closed Total Progress
tool/gdb 2 2 2/2
tool/rsb 13 13 13/13
arch/arm 4 4 4/4
admin 12 12 12/12
doc 5 5 5/5
lib/block 1 1 1/1
network/libbsd 10 10 10/10
config 1 1 1/1
bsps 27 27 27/27
tool/gcc 1 1 1/1
tool 4 4 4/4
shell 2 2 2/2
arch/sparc 2 2 2/2
fs/rfs 1 1 1/1
tool/newlib 1 1 1/1
lib 1 1 1/1
rtems 6 6 6/6
score 4 4 4/4
posix 2 2 2/2
arch/powerpc 2 2 2/2
fs 1 1 1/1
build 1 1 1/1
tool/website 1 1 1/1
release 1 1 1/1

Severity

Severity Closed Total Progress
major 1 1 1/1
normal 101 101 101/101
critical 1 1 1/1
minor 1 1 1/1
trivial 1 1 1/1

Reporter

Reporter Closed Total Progress
Chris Johns 31 31 31/31
Joel Sherrill 13 13 13/13
Kevin Gordon 1 1 1/1
Amar Takhar 2 2 2/2
Sebastian Huber 24 24 24/24
kgardas 1 1 1/1
Jan Sommer 9 9 9/9
Ryan Long 1 1 1/1
Stephen Clark 1 1 1/1
Frank Kuehndel 1 1 1/1
GabrielMoyano 2 2 2/2
Daniel Hellstrom 16 16 16/16
Adrian Varlan 1 1 1/1
Christian Mauderer 2 2 2/2

Version

Version Closed Total Progress
5 99 99 99/99
  3 3 3/3
4.11 2 2 2/2
4.5 1 1 1/1


RTEMS 5.2 Tickets


2746 - RTEMS gdb python script do not load.

Link https://devel.rtems.org/ticket/2746
Id 2746
Reporter Chris Johns
Created 24 June 2016 23:49:05
Modified 9 November 2022 22:14:21
Owner  
Type defect
Component tool/gdb
Status closed
Resolution wontfix
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Loading the scripts does not work ...

(gdb) python import rtems
Traceback (most recent call last):
File "", line 1, in
File "/opt/work/rtems/4.12/share/gdb/python/rtems/__init__.py", line 31, in
import rtems
File "/opt/work/rtems/4.12/share/gdb/python/rtems/rtems.py", line 38, in
import threads
File "/opt/work/rtems/4.12/share/gdb/python/rtems/threads.py", line 39, in
import rbtrees
ImportError: No module named rbtrees
Error while executing Python code.
(gdb)
Comment 1
  1. Chris Johns, Fri, 24 Jun 2016 23:49:53 GMT
  2. description: modified (diff)
Comment 2
  1. Chris Johns, Mon, 27 Mar 2017 06:48:47 GMT
  2. milestone: changed from 4.12.1 to 4.12.0

Move to the first 4.12 milestone.

Comment 3
  1. Joel Sherrill, Thu, 12 Oct 2017 02:47:58 GMT
  2. component: changed from unspecified to tool/gdb
Comment 4
  1. Joel Sherrill, Thu, 12 Oct 2017 02:48:37 GMT
  2. milestone: changed from 4.12.0 to 4.12.1
Comment 5
  1. Sebastian Huber, Thu, 09 Nov 2017 06:27:05 GMT
  2. milestone: changed from 4.12.1 to 5.2

Milestone renamed

Comment 6
  1. Chris Johns, Wed, 09 Nov 2022 22:14:21 GMT
  2. status: changed from new to closed
  3. resolution: set to wontfix

The scripts are too hard to maintain on the 5 branch because a lot of detail in the score has changed. On 6 and later libdebugger provides a highlevel access to a number of pieces or data.


2830 - throwing std::runtime on PC BSP fails.

Link https://devel.rtems.org/ticket/2830
Id 2830
Reporter Chris Johns
Created 2 December 2016 05:10:06
Modified 21 September 2020 21:14:32
Owner Needs Funding
Type defect
Component tool/gcc
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Throwing a std::runtime() exception locks up.

The lock up is in the exception clean up handler where the exception object is destructed. The destructor loops distructing the std::string object. The path ends up in libstdc++-v3/include/ext/atomicity.h line 48 or exchange_and_add.

At a guess it would seem like the C++ atomics on i386 is broken or fragile.

UPDATE: This was broken when gcc i386 eliminated -mcpu in favor of -march/-mtune. The multilibs were built with -mtune and not -march.

Attachments:

1 Chris Johns, Fri, 02 Dec 2016 05:10:43 GMT
  attach: set to cdtest-throw-std_runtime.diff
 
2 Michael Davidsaver, Sat, 19 Sep 2020 14:46:42 GMT
  attach: set to gcc-7.5.0-i386march-1.diff
 
3 Michael Davidsaver, Sat, 19 Sep 2020 14:53:28 GMT
  attach: set to 0001-patch-gcc-i386-multiarch.patch
 
Comment 1
  1. Chris Johns, Fri, 02 Dec 2016 05:12:22 GMT
  2. description: modified (diff)
Comment 2
  1. Sebastian Huber, Fri, 09 Dec 2016 07:02:30 GMT

Works at least on SPARC and ARM. On which BSP fails this?

Comment 3
  1. Chris Johns, Fri, 09 Dec 2016 11:24:02 GMT

Replying to sebastian.huber:

Works at least on SPARC and ARM. On which BSP fails this?

i386/pc686 tested on qemu with a core2duo cpu.

Comment 4
  1. Sebastian Huber, Wed, 15 Feb 2017 14:20:42 GMT
  2. owner: set to Needs Funding
  3. status: changed from new to assigned
  4. milestone: changed from 4.12 to Indefinite
Comment 5
  1. Michael Davidsaver, Thu, 10 Sep 2020 20:24:40 GMT

I'm observing a hang with RTEMS 5.1 with i386/pc686 which may be this issue, though it does not looks to me to be in an exception class dtor. This is a test case I'm running in QEMU w/ 1 virtual CPU.

It's on exit from an catch(...){ block. The actual hang appears to be a tight loop in the __atomic_fetch_add_4 builtin. Specifically, these three instructions.

=> 0x3f1780 :        mov    $0x5,%eax
   0x3f1785 :      mov    %eax,0xc(%esp)
   0x3f1789 :      jmp    0x3f1780  

The stack trace is:

(gdb) bt
#0  libat_fetch_add_4 (mptr=0x75d7bc, opval=4294967295, smodel=5) at ../../../../gcc-7.5.0/libatomic/fop_n.c:44
#1  0x003b07fc in __gnu_cxx::__exchange_and_add (__val=-1, __mem=0x75d7bc)
    at /home/mdavidsaver/source/rtems/rtems-source-builder-5.1/rtems/build/i386-rtems5-gcc-7.5.0-newlib-7947581-x86_64-linux-gnu-1/build/i386-rtems5/mpentiumpro/libstdc++-v3/include/ext/atomicity.h:49
#2  __gnu_cxx::__exchange_and_add_dispatch (__val=-1, __mem=0x75d7bc)
    at /home/mdavidsaver/source/rtems/rtems-source-builder-5.1/rtems/build/i386-rtems5-gcc-7.5.0-newlib-7947581-x86_64-linux-gnu-1/build/i386-rtems5/mpentiumpro/libstdc++-v3/include/ext/atomicity.h:82
#3  __gnu_cxx::__eh_atomic_dec (__count=0x75d7bc) at ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_atomics.h:72
#4  __gxx_exception_cleanup (code=_URC_FOREIGN_EXCEPTION_CAUGHT, exc=0x75d7fc)
    at ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_throw.cc:46
#5  0x003ad9cb in _Unwind_DeleteException (exc=0x75d7fc) at ../../../../gcc-7.5.0/libgcc/unwind.inc:271
#6  0x003af8d0 in __cxxabiv1::__cxa_end_catch () at ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_catch.cc:125
#7  0x001012fd in epicsTimeTest () at ../epicsTimeTest.cpp:116 
Comment 6
  1. Sebastian Huber, Fri, 11 Sep 2020 04:51:16 GMT

If this BSP uses libatomic to load a 32-bit value, then it uses an obsolete instruction set.

Comment 7
  1. Michael Davidsaver, Fri, 11 Sep 2020 16:56:14 GMT

I've not come across 'libatomic' before. I guess this is some compatibility glue for older x86?

From some playing around, it looks like the toolchain gcc is defaulting to '-march=i386' if no other option is provided. Maybe not surprising given that the toolchain name is 'i386-rtems5'. '/make/custom/pc686.cfg' has '-mtune=pentiumpro -march=pentium'. Passing this to a short test seems to result in the intrinsic actually being used. So I guess the RTEMS kernel config/build is ok?

Starting from the linker map of epicsTimeTest, I see that the symbol __atomic_fetch_add_4 (aka. 'libat_fetch_add_4') is undefined in /lib/gcc/i386-rtems5/7.5.0/mpentiumpro/libstdc++.a. So I guess this means that the (multilib?) build of libstdc++ is not being done correctly?

My knowledge of GCC internals doesn't extend beyond ./configure arguments. So I don't know where to look next.

Comment 8
  1. Joel Sherrill, Fri, 11 Sep 2020 22:07:20 GMT

Could someone please try this test case with -march=i486 as the compiler selection?

I think we need to move the base uniprocessor x86 CPU model up from vanilla i386 w/FPU but what the new floor needs to be is TBD. If I understand things correctly, i486 is the minimum with any atomic instructions but you have to get into the pentium II era to get the earliest SMP support.

I'm not sure if going beyond i486 is needed for uniprocessor but that may be sufficient. For SMP, you probably need to go to at least pentium II. On Qemu, I used core2duo long ago to test SMP.

If we move the floor to greater than or equal to Pentium, there is more opportunity to remove a small bit of code. But I'd like to know the bare technical minimums first.

So what is the lowest architecture (-march=XXX) that appears to solve this for you?

Comment 9
  1. Michael Davidsaver, Fri, 11 Sep 2020 22:58:24 GMT

Could someone please try this test case with -march=i486 as the compiler selection?

This seems to have the desired effect (emits a 'lock' instruction instead of calling __atomic_fetch_add_4).

I'm still perplexed that the 'pentiumpro' version of libstdc++.a appears to be built with '-march=i386'. All 6 versions seem to be. Is this how gcc's multilib is meant to work?

Comment 10
  1. Michael Davidsaver, Fri, 11 Sep 2020 23:18:34 GMT

I may have answered part of my question with a lucky grep of the gcc source. I found 'gcc/config/i386/t-rtems' which seems to show that the different multilib versions are built with '-mtune=...', and presumably defaulting to '-march=i386'. RTEMS itself in '/make/custom/pc686.cfg' has '-march=pentium'. What is the logic here?

MULTILIB_OPTIONS = mtune=i486/mtune=pentium/mtune=pentiumpro msoft-float
MULTILIB_DIRNAMES= m486 mpentium mpentiumpro soft-float
MULTILIB_MATCHES = msoft-float=mno-80387
MULTILIB_MATCHES += mtune?pentium=mtune?k6 mtune?pentiumpro=mtune?athlon
MULTILIB_EXCEPTIONS = \
mtune=pentium/*msoft-float* \
mtune=pentiumpro/*msoft-float* 
Comment 11
  1. Sebastian Huber, Sat, 12 Sep 2020 07:47:29 GMT

We have two different issues:

The i386 BSPs use probably obsolete instruction sets which lead to the use of libatomic. If libatomic is used, then there is some broken behaviour.

The libatomic seems to work fine on other architectures, e.g. it is also used by the sparc/erc32 BSP. Here the cdtest.exe test program runs successfully and executes a similar context:

Breakpoint 2, libat_fetch_add_4 (mptr=0x203d798, opval=4294967295, smodel=4) at ../../../gnu-mirror-gcc-c72a1b6/libatomic/fop_n.c:164
164     ../../../gnu-mirror-gcc-c72a1b6/libatomic/fop_n.c: No such file or directory.
(gdb) bt
#0  libat_fetch_add_4 (mptr=0x203d798, opval=4294967295, smodel=4) at ../../../gnu-mirror-gcc-c72a1b6/libatomic/fop_n.c:164
#1  0x0200eda0 in __gnu_cxx::__exchange_and_add (__val=-1, __mem=0x203d798) at /home/EB/sebastian_h/src/rtems-source-builder/rtems/build/sparc-rtems6-gcc-c72a1b6-newlib-ece49e4-x86_64-linux-gnu-1/build/sparc-rtems6/libstdc++-v3/include/ext/atomicity.h:84
#2  __gnu_cxx::__exchange_and_add_dispatch (__val=-1, __mem=0x203d798) at /home/EB/sebastian_h/src/rtems-source-builder/rtems/build/sparc-rtems6-gcc-c72a1b6-newlib-ece49e4-x86_64-linux-gnu-1/build/sparc-rtems6/libstdc++-v3/include/ext/atomicity.h:84
#3  __gnu_cxx::__eh_atomic_dec (__count=0x203d798) at ../../../../gnu-mirror-gcc-c72a1b6/libstdc++-v3/libsupc++/eh_atomics.h:72
#4  __gxx_exception_cleanup (code=_URC_FOREIGN_EXCEPTION_CAUGHT, exc=0x203d7d0) at ../../../../gnu-mirror-gcc-c72a1b6/libstdc++-v3/libsupc++/eh_throw.cc:46
#5  0x0201e584 in _Unwind_DeleteException (exc=0x203d7d0) at ../../../gnu-mirror-gcc-c72a1b6/libgcc/unwind.inc:283
#6  0x02001a44 in foo_function () at ../../../testsuites/samples/cdtest/main.cc:198
#7  main_task () at ../../../testsuites/samples/cdtest/main.cc:212
#8  0x02006b8c in _Thread_Entry_adaptor_numeric (executing=0x2032ae8 <_RTEMS_tasks_Objects>) at ../../../cpukit/score/src/threadentryadaptornumeric.c:25
#9  0x02006c64 in _Thread_Handler () at ../../../cpukit/score/src/threadhandler.c:143
#10 0x02006c04 in _Thread_Handler () at ../../../cpukit/score/src/threadhandler.c:87 
Comment 12
  1. Sebastian Huber, Sat, 12 Sep 2020 10:29:03 GMT

Replying to Michael Davidsaver:

It's on exit from an catch(...){ block. The actual hang appears to be a tight loop in the __atomic_fetch_add_4 builtin. Specifically, these three instructions.

=> 0x3f1780 :        mov    $0x5,%eax
   0x3f1785 :      mov    %eax,0xc(%esp)
   0x3f1789 :      jmp    0x3f1780  

From this code it is clear, that this is a libatomic configuration issue on i386. We have a recursive call here. We probably use instruction sets which are not really tested these days by someone else.

Comment 13
  1. Joel Sherrill, Sat, 12 Sep 2020 14:54:58 GMT

The bug goes back to when gcc replaced -mcpu= with -march= and -mtune=. We used to generated code specifically compatible with and optimized for a CPU model. -march is now the compatibility level flag and -mtune is an optimization indication. We are generating i386 compatible code which is tuned based on say an i686 instruction weighting.

The multilib -mtune needs to change to -march.

Since -march is the first x86 option described, it is at the top of this page in the GCC manual:

​https://gcc.gnu.org/onlinedocs/gcc-7.5.0/gcc/x86-Options.html#x86-Options

A quick search browsing gcc/config/i386/t-* shows RTEMS seems to be the only i386 target building multilibs which are cpu model based. Others use m32/m64 or other things.

Comment 14
  1. Michael Davidsaver, Fri, 18 Sep 2020 21:36:49 GMT

Is there agreement on a path forward for this issue? Is it as simple as replacing 'mtune' with 'march' in gcc/config/i386/t-rtems ? If so, who will do/test this? This change seems simple enough that I would just try it myself, but I'm not sure where/how to add a patch in the RSB recipies.

Comment 15
  1. Joel Sherrill, Fri, 18 Sep 2020 21:53:00 GMT

I think that's the extent of the source changes which we think will resolve the issue. Someone may point to documentation but it is Friday and I am going to point to an example of adding a patch and talk you through it. This assumes the 5 branch because we won't get a patch merged into gcc 7. We can address RTEMS master after 5 is fixed. The patch for gcc should be the same. We just have more latitude to merge it to gcc master and newer release branches.

How to generate a patch: ​https://devel.rtems.org/wiki/Developer/Coding/GenerateAPatch which should also be in the Software Engineering Guide.

The easiest example I saw was in rtems/config/5/rtems-lm32.bset which adds a gdb patch only for lm32 builds. You would be adding a gcc patch to rtems/config/5/rtems-i386.bset.

For merging, a patch needs an Internet home (attaching to a ticket gives you a URL) but for testing, you can just drop the diff into the patches subdirectory config/rtems/patches. The RSB will see it there and not try to fetch it. But you need an sha checksum.

After that, it is build as normal for testing purpose. If this gives you a toolset that works, we can address changing the URL. But attaching it to this ticket and getting the URL for the "raw" attachment should work just fine.

Comment 16
  1. Michael Davidsaver, Sat, 19 Sep 2020 16:47:42 GMT

I've attached patches for GCC and RSB.

A successful test build: ​https://github.com/mdavidsaver/rsb/runs/1138090148?check_suite_focus=true#step:5:563

Comment 17
  1. Joel Sherrill, Sat, 19 Sep 2020 17:49:16 GMT

Congratulations! Can you confirm you tested code compiled with the resulting toolchain and it solved the problem?

Comment 18
  1. Michael Davidsaver, Sat, 19 Sep 2020 19:44:55 GMT

Ha. That would be a good thing to mention would it not? Yes, the epicsTimeTest now passes, and the cdtest completes as well (with qemu*). I am having a problem with another test, but this is almost certainly a separate issue.

​https://github.com/mdavidsaver/rsb/runs/1138090148?check_suite_focus=true#step:8:71
Comment 19
  1. Joel Sherrill, Mon, 21 Sep 2020 19:43:58 GMT
  2. component: changed from unspecified to tool/gcc
  3. description: modified (diff)
  4. milestone: changed from Indefinite to 5.2
Comment 20
  1. Michael Davidsaver, Mon, 21 Sep 2020 20:37:37 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In ebc3abe/rtems-source-builder:

patch gcc i386 multiarch
Add patch to change from mtune to march when building multilibs. The mtune argument tunes or optimizes for a specific CPU model but does not ensure the generated code is appropriate for the CPU model. Prior to this patch, i386 compatible code was always generated but tuned for later models.
Closes #2830.
Comment 21
  1. Michael Davidsaver, Mon, 21 Sep 2020 21:14:32 GMT

In 1ea1c9c/rtems-source-builder:

patch gcc i386 multiarch
Add patch to change from mtune to march when building multilibs. The mtune argument tunes or optimizes for a specific CPU model but does not ensure the generated code is appropriate for the CPU model. Prior to this patch, i386 compatible code was always generated but tuned for later models.
This is the same fix as #2830 but applying to gcc 10.
Updates #4084.

3347 - tms570: Register Macro Redefinition

Link https://devel.rtems.org/ticket/3347
Id 3347
Reporter Joel Sherrill
Created 15 March 2018 14:56:57
Modified 15 October 2018 06:45:51
Owner Pavel Pisa
Type defect
Component arch/arm
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

This looks like the same name was accidentally used. Without knowing the architecture, you can't know what was intended:

/home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h:164:0: warning: "TMS570_SYS1_CDDIS_VCLKAOFF_SET" redefined
/home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h:163:0: warning: "TMS570_SYS1_CDDIS_VCLKAOFF_GET" redefined
/home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h:162:0: warning: "TMS570_SYS1_CDDIS_VCLKAOFF" redefined
/home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h:146:0: warning: "TMS570_SYS1_CSDISCLR_CLRCLKSR_OFF_SET" redefined
/home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h:145:0: warning: "TMS570_SYS1_CSDISCLR_CLRCLKSR_OFF_GET" redefined
/home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h:144:0: warning: "TMS570_SYS1_CSDISCLR_CLRCLKSR_OFF" redefined
/home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h:134:0: warning: "TMS570_SYS1_CSDISSET_SETCLKSR_OFF_SET" redefined
/home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h:133:0: warning: "TMS570_SYS1_CSDISSET_SETCLKSR_OFF_GET" redefined
/home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h:132:0: warning: "TMS570_SYS1_CSDISSET_SETCLKSR_OFF" redefined
/home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h:122:0: warning: "TMS570_SYS1_CSDIS_CLKSROFF_SET" redefined
/home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h:121:0: warning: "TMS570_SYS1_CSDIS_CLKSROFF_GET" redefined
/home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h:120:0: warning: "TMS570_SYS1_CSDIS_CLKSROFF" redefined

Comment 1
  1. Joel Sherrill, Thu, 15 Mar 2018 14:57:13 GMT
  2. owner: set to Pavel Pisa
  3. status: changed from new to assigned
Comment 2
  1. Joel Sherrill, Sat, 13 Oct 2018 22:51:07 GMT
  2. milestone: changed from 5.1 to 5.2
Comment 3
  1. Pavel Pisa, Mon, 15 Oct 2018 06:45:51 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 1822649/rtems:

bsp/tms570: Simple fix to resolve macro redefinitions. closes #3347

3540 - How To Use SPARC memscrub

Link https://devel.rtems.org/ticket/3540
Id 3540
Reporter Joel Sherrill
Created 5 October 2018 16:32:08
Modified 9 November 2022 23:06:34
Owner Daniel Hellstrom
Type defect
Component doc
Status closed
Resolution wontfix
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords qualification
Cc  
Blocking  
Blocked by  

Description

The SPARC memory scrubber code on the RTEMS master is undocumented from a using standpoint. Google shows the RCC has documentation (chapter 49) using it. Can this information be made available in the RTEMS Ecosystem somehow?

Comment 1
  1. Joel Sherrill, Fri, 05 Oct 2018 16:32:26 GMT
  2. owner: set to Daniel Hellstrom
  3. status: changed from new to assigned
Comment 2
  1. Joel Sherrill, Sat, 13 Oct 2018 22:54:56 GMT
  2. milestone: changed from 5.1 to 5.2
Comment 3
  1. Sebastian Huber, Fri, 18 Jun 2021 09:24:45 GMT
  2. keywords: qualification added
Comment 4
  1. Chris Johns, Wed, 09 Nov 2022 23:06:34 GMT
  2. status: changed from assigned to closed
  3. resolution: set to wontfix

Please reopen if this is going to be worked on.


3571 - Stream of Unicode Warnings from git hook on Commit

Link https://devel.rtems.org/ticket/3571
Id 3571
Reporter Joel Sherrill
Created 26 October 2018 21:19:20
Modified 17 August 2022 06:08:55
Owner Amar Takhar
Type defect
Component admin
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity critical
Keywords  
Cc  
Blocking  
Blocked by  

Description

When I pushed a commit this afternoon, I got so many of these that I can't scroll back to the git commit command:

remote: Code point 0x0000 is not Unicode, may not be portable at /data/support/git-support/hooks/hook_email.pl line 183.
remote: Malformed UTF-8 character (unexpected non-continuation byte 0x03, immediately after start byte 0xfd) in print at /data/support/git-support/hooks/hook_email.pl line 183.
remote: Code point 0x0000 is not Unicode, may not be portable at /data/support/git-support/hooks/hook_email.pl line 183.
remote: Malformed UTF-8 character (unexpected non-continuation byte 0xfe, immediately after start byte 0xf6) in print at /data/support/git-support/hooks/hook_email.pl line 183.
remote: Code point 0x0000 is not Unicode, may not be portable at /data/support/git-support/hooks/hook_email.pl line 183.
remote: Malformed UTF-8 character (unexpected non-continuation byte 0x04, immediately after start byte 0xfd) in print at /data/support/git-support/hooks/hook_email.pl line 183.
remote: Code point 0x0000 is not Unicode, may not be portable at /data/support/git-support/hooks/hook_email.pl linCKilled by signal 2.

Comment 1
  1. Amar Takhar, Wed, 21 Nov 2018 23:15:42 GMT

Can you provide the rev hash that triggered this? Sorry I missed this ticket.

Comment 2
  1. Amar Takhar, Wed, 05 Dec 2018 03:35:26 GMT

Any update on giving the hash that triggered this? Thanks.

Comment 3
  1. Amar Takhar, Wed, 13 Feb 2019 20:03:19 GMT
  2. milestone: changed from 5.1 to 5.2

I haven't heard back on which hash triggered this. Moving to milestone:5.2

Comment 4
  1. Chris Johns, Wed, 17 Aug 2022 06:08:55 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

There has been no feedback so lets consider it closed.


3601 - Block device disk management implementation can underflow rtems_disk_device.uses

Link https://devel.rtems.org/ticket/3601
Id 3601
Reporter Kevin Gordon
Created 12 November 2018 01:35:03
Modified 9 November 2022 23:08:11
Owner Needs Funding
Type defect
Component lib/block
Status closed
Resolution wontfix
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The source file discdevs.c contains logic error with regard to a rtems_disk_device.uses member, in that the .uses value can underflow and wrap-around because this member is unsigned and the implementation does not check for a current value of 0.

Case in point, see diskdevs.c line 373:

physical_disk->uses -= deleted_count;

If deleted_count is greater than physical_disk->uses, e.g. physical_disk->uses is 0 and deleted_count is 1, physical_disk->uses will underflow. There are other references to the uses member that can result in errors, e.g., line 448:

uses = --dd->uses;

We discovered this bug via a unit-test that creates multiple RAM disks and then attempts to delete them, without any uses, resulting in RTEMS errors because the __uses__ member had wrapped around. To circumvent this bug, we had to force the __uses__ member to a value of 1 prior to calling rtems_disk_release(), which then successfully deleted the RAM disks via rtems_disk_delete(), otherwise the results cascaded into error situations that were undesirable.

Comment 1
  1. Sebastian Huber, Mon, 12 Nov 2018 06:21:35 GMT
  2. component: changed from admin to lib/block

This API is deprecated in RTEMS 5.1 and will be removed in RTEMS 6.1.

Comment 2
  1. Sebastian Huber, Tue, 29 Jan 2019 08:06:16 GMT
  2. milestone: changed from 5.1 to 5.2

If you want to get this fixed, then please send a patch to devel@…. I would avoid this API and use rtems_blkdev_create() and rtems_blkdev_create_partition() instead.

Comment 3
  1. Sebastian Huber, Mon, 13 Jul 2020 15:22:47 GMT
  2. owner: set to Needs Funding
  3. status: changed from new to assigned
Comment 4
  1. Chris Johns, Wed, 09 Nov 2022 23:07:23 GMT
  2. milestone: changed from 5.2 to Indefinite
Comment 5
  1. Chris Johns, Wed, 09 Nov 2022 23:08:11 GMT
  2. status: changed from assigned to closed
  3. resolution: set to wontfix
  4. milestone: changed from Indefinite to 5.2

Sebastian has recommended avoiding this API.


3619 - Docs location for docs.rtems.org

Link https://devel.rtems.org/ticket/3619
Id 3619
Reporter Amar Takhar
Created 26 November 2018 01:09:58
Modified 9 November 2022 23:11:16
Owner Amar Takhar
Type defect
Component admin
Status closed
Resolution wontfix
Version  
Milestone 5.2
Priority normal
Severity normal
Keywords buildbot
Cc Chris Johns
Blocking  
Blocked by  

Description

Where do the built docs from Buildbot need to go for docs.rtems.org?

Right now I see the top is 'master' so just replace those?

Comment 1
  1. Chris Johns, Wed, 28 Nov 2018 06:48:19 GMT

The docs.rtems.org website is constructed using the files in this repo ​https://git.rtems.org/chrisj/rtems-admin.git/. This includes all the previous releases.

I do not understand how buildbot built docs plug into this set up so I it would be good ot get some understanding of how this will work.

How are the docs being built by buildbot? Is there a public repo for the buildbot config files? How do the docs move from buildbot jail to the docs jail? Is there somewhere Joel and I can review the buildbot built docs?
Comment 2
  1. Chris Johns, Wed, 09 Nov 2022 23:11:16 GMT
  2. status: changed from assigned to closed
  3. resolution: set to wontfix

Please reopen if this is to be worked on.


3641 - Gitlab mirror

Link https://devel.rtems.org/ticket/3641
Id 3641
Reporter Amar Takhar
Created 7 December 2018 17:27:33
Modified 9 November 2022 23:12:01
Owner Amar Takhar
Type infra
Component admin
Status closed
Resolution wontfix
Version  
Milestone 5.2
Priority normal
Severity normal
Keywords mirrors
Cc  
Blocking  
Blocked by  

Description

I just registered the 'rtems' group over at gitlab.com.

It doesn't cost us anything to run mirrors at both Github and Gitlab when I have a chance I will setup a Gitlab mirror though it's not a priority.

I'll work out getting access to everyone through their Gitlab accounts at a later date.

Comment 1
  1. Chris Johns, Sun, 09 Dec 2018 23:37:32 GMT

Do you have a link?

Comment 2
  1. Chris Johns, Wed, 09 Nov 2022 23:12:01 GMT
  2. status: changed from assigned to closed
  3. resolution: set to wontfix

Please repopen if this is to be worked on.


4011 - Test compilation error in riscv bsps

Link https://devel.rtems.org/ticket/4011
Id 4011
Reporter Jan Sommer
Created 22 June 2020 07:06:41
Modified 9 November 2022 22:17:48
Owner  
Type defect
Component admin
Status closed
Resolution wontfix
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Configuring the riscv bsps with --enable-tests fails to build at least the dl06 test.

../rtems-5.0.0-m2006-2/configure --target=riscv-rtems5 --prefix../install/bsps --disable-networking --enable-tests --enable-rtemsbsp=griscv

Error during the compilation step:

rtems-ld -r /localdata2/somm_ja/rtems/5-0-rc/build-riscv/riscv-rtems5/c/griscv \

-C riscv-rtems5-gcc -c "-march=rv32imafd -mabi=ilp32d" \
-O rap -b dl06.pre -e rtems_main -s \
-o dl06.rap dl06-o1.o dl06-o2.o -lm

error: rap::object: Section index '0' not found: dl06-o1.o
Makefile:8479: recipe for target 'dl06.rap' failed
make[5]: __* [dl06.rap] Error 10
make[5]: Leaving directory '/localdata2/somm_ja/rtems/5-0-rc/build-riscv/riscv-rtems5/c/griscv/testsuites/libtests'
Makefile:663: recipe for target 'libtests' failed
make[4]: __* [libtests] Error 2
make[4]: Leaving directory '/localdata2/somm_ja/rtems/5-0-rc/build-riscv/riscv-rtems5/c/griscv/testsuites'
Makefile:1222: recipe for target 'testsuites' failed
make[3]: __* [testsuites] Error 2
make[3]: Leaving directory '/localdata2/somm_ja/rtems/5-0-rc/build-riscv/riscv-rtems5/c/griscv'
Makefile:716: recipe for target 'all-recursive' failed
make[2]: __* [all-recursive] Error 1
make[2]: Leaving directory '/localdata2/somm_ja/rtems/5-0-rc/build-riscv/riscv-rtems5/c/griscv'
Makefile:289: recipe for target 'all-recursive' failed
make[1]: __* [all-recursive] Error 1
make[1]: Leaving directory '/localdata2/somm_ja/rtems/5-0-rc/build-riscv/riscv-rtems5/c'
Makefile:410: recipe for target 'all-recursive' failed
make: __* [all-recursive] Error 1
make all 112,71s user 27,01s system 102% cpu 2:16,13 total

Comment 1
  1. Chris Johns, Wed, 09 Nov 2022 22:17:48 GMT
  2. status: changed from new to closed
  3. resolution: set to wontfix

Please use the RISCV support in RTEMS 6.


4024 - NFS Client is broken on 64-bit targets

Link https://devel.rtems.org/ticket/4024
Id 4024
Reporter Sebastian Huber
Created 8 July 2020 11:33:11
Modified 17 August 2022 06:09:40
Owner Sebastian Huber
Type defect
Component network/libbsd
Status closed
Resolution wontfix
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Packed and unpacked structures are mixed leading to invalid XDR encode/decode operations if addresses > 4GiB are used.

Comment 1
  1. Chris Johns, Mon, 10 Aug 2020 05:44:39 GMT
  2. milestone: changed from 5.1 to 5.2
Comment 2
  1. Chris Johns, Wed, 17 Aug 2022 06:09:40 GMT
  2. status: changed from assigned to closed
  3. resolution: set to wontfix

Use master or RTEMS 6.


4058 - RSB 5/rtems-riscv fails to build on Windows

Link https://devel.rtems.org/ticket/4058
Id 4058
Reporter Chris Johns
Created 20 August 2020 22:33:34
Modified 8 September 2022 03:36:29
Owner  
Type defect
Component tool/gdb
Status closed
Resolution wontfix
Version 5
Milestone 5.2
Priority high
Severity major
Keywords  
Cc  
Blocking  
Blocked by  

Description

To repeat run rtems-release-test 5 1-rc2 on Windows.

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ada-tasks.o: in function `memcpy':
C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined reference to `__memcpy_chk'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: breakpoint.o: in function `strcpy':
C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:228: undefined reference to `__strcpy_chk'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:228: undefined reference to `__s
trcpy_chk'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: breakpoint.o: in function `memset':
C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:208: undefined reference to `__memset_chk'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: breakpoint.o: in function `sprintf(char*, char const*, ...)':
C:/msys64/mingw64/x86_64-w64-mingw32/include/stdio.h:366: undefined reference to `__chk_fail'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cli/cli-decode.o: in function `strcat':
C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:234: undefined reference to `__strcat_chk'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:234: undefined reference to `__m
emcpy_chk'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:234: undefined reference to `__m
emcpy_chk'

I think this has been resolved in a later GDB version.

Comment 1
  1. Chris Johns, Thu, 08 Sep 2022 03:36:29 GMT
  2. status: changed from new to closed
  3. resolution: set to wontfix

Please use RTEMS 6. The RISCV is in the tier-4 list for this release.


4059 - RSB: UnicodeDecodeError

Link https://devel.rtems.org/ticket/4059
Id 4059
Reporter Sebastian Huber
Created 21 August 2020 06:12:00
Modified 9 November 2022 22:21:25
Owner  
Type defect
Component tool/rsb
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The RSB some times cannot create a report due to an Unicode decode error:

error: building powerpc-rtems5-gdb-9.1-x86_64-linux-gnu-1
Build FAILED
error: failure to create error report
Build Set: Time 0:01:29.712543
Traceback (most recent call last):
File "../source-builder/sb/cmd-set-builder.py", line 26, in
setbuilder.run()
File "/scratch/git-rtems-release/5.1-rc2/rtems-source-builder-5.1-rc2/source-builder/sb/setbuilder.py", line 736, in run
b.build(deps, mail = mail)
File "/scratch/git-rtems-release/5.1-rc2/rtems-source-builder-5.1-rc2/source-builder/sb/setbuilder.py", line 473, in build
self.build_package(configs[s], b)
File "/scratch/git-rtems-release/5.1-rc2/rtems-source-builder-5.1-rc2/source-builder/sb/setbuilder.py", line 258, in build_package
_build.make()
File "/scratch/git-rtems-release/5.1-rc2/rtems-source-builder-5.1-rc2/source-builder/sb/build.py", line 603, in make
self._generate_report_('Build: %s' % (gerr))
File "/scratch/git-rtems-release/5.1-rc2/rtems-source-builder-5.1-rc2/source-builder/sb/build.py", line 126, in _generate_report_
self.opts, header, footer)
File "/scratch/git-rtems-release/5.1-rc2/rtems-source-builder-5.1-rc2/source-builder/sb/ereport.py", line 56, in generate
l.write(os.linesep.join(r))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 50: ordinal not in range(128)
RSB Error Report:
Comment 1
  1. Hilgad Montelo, Fri, 17 Sep 2021 06:25:25 GMT

This error also happens when the RSB tool is trying to build RTEMS for others architectures and packages (found on release 5.1): building: rtems-tools-29ad0ec7a8ec8aae5afeb32ef8be03707f626843-1 error: building rtems-tools-29ad0ec7a8ec8aae5afeb32ef8be03707f626843-1 Build FAILED error: failure to create error report Build Set: Time 3:07:57.408978 Traceback (most recent call last):

File "../source-builder/sb/cmd-set-builder.py", line 26, in

setbuilder.run()

File "$Dev/RTEMS/rtems-bbb/tools/rtems-source-builder/source-builder/sb/setbuilder.py", line 736, in run

b.build(deps, mail = mail)

File "$Dev/RTEMS/rtems-bbb/tools/rtems-source-builder/source-builder/sb/setbuilder.py", line 473, in build

self.build_package(configs[s], b)

File "$Dev/RTEMS/rtems-bbb/tools/rtems-source-builder/source-builder/sb/setbuilder.py", line 258, in build_package

_build.make()

File "$Dev/RTEMS/rtems-bbb/tools/rtems-source-builder/source-builder/sb/build.py", line 603, in make

self._generate_report_('Build: %s' % (gerr))

File "$Dev/RTEMS/rtems-bbb/tools/rtems-source-builder/source-builder/sb/build.py", line 126, in _generate_report_

self.opts, header, footer)

File "$Dev/RTEMS/rtems-bbb/tools/rtems-source-builder/source-builder/sb/ereport.py", line 56, in generate

l.write(os.linesep.join(r))

UnicodeDecodeError?: 'ascii' codec can't decode byte 0xe2 in position 70: ordinal not in range(128)

Comment 2
  1. Arne Ehrlich, Wed, 22 Dec 2021 11:37:04 GMT

This error occurs when the python locale environment is not set correctly. I got this for an compile error message when rtems-source-builder failing to building expat on MacOS.

ensuring LANG and LC_ALL are set fixed the problem writing the error log

export LANG='en_US.UTF-8' LC_ALL='en_US.UTF-8'

LANG is generally set correctly on macos.

if one is setting one of the LC_* variables to a different locale (I use LC_TIME="de_DE.UTF-8")

then python assumes the encoding is ascii only.

setting LC_ALL overrides this and python happily uses utf-8 again.

Comment 3
  1. Chris Johns, Wed, 09 Nov 2022 22:21:25 GMT
  2. status: changed from new to closed
  3. resolution: set to fixed

Fixed here ​https://git.rtems.org/rtems-source-builder/commit/?h=5&id=ddfcc320ab740cd6ac30d70aaff7987dda25ee7f


4060 - The reworked <rtems/confdefs.h> has a cyclic dependency with RTEMS_MULTIPROCESSING enabled

Link https://devel.rtems.org/ticket/4060
Id 4060
Reporter Sebastian Huber
Created 21 August 2020 06:47:02
Modified 23 June 2021 07:07:55
Owner Sebastian Huber
Type defect
Component config
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords qualification
Cc  
Blocking  
Blocked by  

Description

The changes for #3875 introduced a cyclic dependency between and .

Comment 1
  1. Sebastian Huber, Fri, 21 Aug 2020 18:03:24 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 7661402/rtems:

confdefs: Fix cyclic dependency Close #4060.
Comment 2
  1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
  2. keywords: qualification added

4064 - RSB needs to support waf with no python command

Link https://devel.rtems.org/ticket/4064
Id 4064
Reporter Chris Johns
Created 28 August 2020 00:25:08
Modified 9 November 2022 23:14:51
Owner Chris Johns
Type defect
Component tool/rsb
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Recent Linux distros may not provide a python command by default. This breaks building any waf based tools such as the rtems-tools and rtems-libbsd.

Provide support for waf builds by check for a suitable Python executable and using it to directly invoke waf. For example:

/usr/local/bin/python3.7 ./waf configure --prefix=/blah/blah 
Comment 1
  1. Chris Johns, Wed, 09 Nov 2022 23:14:51 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

RTEMS 5 has a hack'ish detect that has been removed in RTEMS 6.


4068 - arm: arm_cp15_set_translation_table_entries() should affect Inner Shareable domain

Link https://devel.rtems.org/ticket/4068
Id 4068
Reporter Sebastian Huber
Created 4 September 2020 13:43:16
Modified 17 September 2020 06:38:20
Owner Sebastian Huber
Type defect
Component arch/arm
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The arm_cp15_set_translation_table_entries() uses the wrong TLB maintenance operation in multi-processor systems.

Comment 1
  1. Sebastian Huber, Thu, 17 Sep 2020 06:38:20 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 20d8237/rtems:

arm: Fix arm_cp15_set_translation_table_entries() In a multi-processor system we must broadcast the TLB maintenance operation to the Inner Shareable domain to ensure that the other processors update their TLB caches accordingly. Close #4068.

4071 - RSB does not pass BSP options correctly.

Link https://devel.rtems.org/ticket/4071
Id 4071
Reporter kgardas
Created 6 September 2020 22:19:37
Modified 9 November 2022 22:31:38
Owner  
Type defect
Component admin
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Using 5.1 RTEMS release and RSB to build the beast I've found out it's not able to pass BSP options correctly using --with-rtems-bspopts option:

../source-builder/sb-set-builder
--prefix=$HOME/sfw/rtems/5.1-smp2-vga80x50-key-to-reset 5/bsps/pc
--with-rtems-tests --with-rtems-smp
--with-rtems-bspopts="BSP_VIDEO_80x50=1 BSP_PRESS_KEY_FOR_RESET=1"

command fails with:

Build Set: Time 0:00:28.975685
Build Set: Time 0:03:36.556012
installing: 5/bsps/pc ->
/export/home/karel/sfw/rtems/5.1-smp2-vga80x50-key-to-reset
clean staging: 5/bsps/pc
Staging Size: 4.271GB
Build Set: Time 0:24:53.756984
Build Set: BSP_PRESS_KEY_FOR_RESET=1
error: no build set file found: BSP_PRESS_KEY_FOR_RESET=1.bset
Build Set: Time 0:00:00.000420
Build FAILED

It looks like even if I use just one BSP options, it's still not passed to the BSP, but build is built fine at least.

Comment 1
  1. Chris Johns, Wed, 09 Nov 2022 22:31:38 GMT
  2. status: changed from new to closed
  3. resolution: set to fixed

The RTEMS 5 RSB has been updated to support deployment and I think this will now be fixed. Please refer to the ​RTEMS Deployment repo for example configurations known to work.


4073 - libbsd: Back port ifmcstat command

Link https://devel.rtems.org/ticket/4073
Id 4073
Reporter Sebastian Huber
Created 10 September 2020 11:27:43
Modified 10 September 2020 11:31:20
Owner Sebastian Huber
Type enhancement
Component network/libbsd
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The ifmcstat command is a useful diagnostics command to track down issues with multicasts.

Comment 1
  1. Sebastian Huber, Thu, 10 Sep 2020 11:31:09 GMT

Integrated in 7f47f2784138109b8363804c2aecd3d83231ab0f.

Comment 2
  1. Sebastian Huber, Thu, 10 Sep 2020 11:31:20 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

4075 - POSIX Compliance Guide Missing Some math.h Methods

Link https://devel.rtems.org/ticket/4075
Id 4075
Reporter Joel Sherrill
Created 11 September 2020 21:30:39
Modified 14 September 2020 18:30:42
Owner Joel Sherrill <joel@…>
Type defect
Component doc
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The following methods are provided as macros on top of compiler built-ins. They have been missed by previous reviews but have long been supported. The POSIX Compliance Guide for the 5 branch and master needs to be updated.

  • fpclassify()
  • isfinite()
  • isgreater()
  • isgreaterequal()
  • isless()
  • islessequal()
  • islessgreater()
  • isnormal()
  • isunordered()
  • nexttowardf()
  • signbit()
Comment 1
  1. Joel Sherrill, Mon, 14 Sep 2020 18:29:42 GMT
  2. owner: set to Joel Sherrill <joel@…>
  3. status: changed from new to closed
  4. resolution: set to fixed

In 6559511/rtems-docs:

Add missing methods implemented as macros on compiler builtins. These methods have long been provided and this change is needed on the 5.x branch and master. Closes #4075.
Comment 2
  1. Joel Sherrill, Mon, 14 Sep 2020 18:30:42 GMT

In 5642fe5/rtems-docs:

Add missing methods implemented as macros on compiler builtins. These methods have long been provided and this change is needed on the 5.x branch and master. Closes #4075.

4082 - License files missing on 5-freebsd-12 branch

Link https://devel.rtems.org/ticket/4082
Id 4082
Reporter Christian Mauderer
Created 17 September 2020 09:23:31
Modified 28 September 2020 11:51:48
Owner Christian Mauderer
Type enhancement
Component admin
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority low
Severity normal
Keywords  
Cc Chris Johns
Blocking  
Blocked by  

Description

The commits

​https://git.rtems.org/rtems-libbsd/commit/libbsd.py?id=c64a1ebaf9c8871f3f72b8754097e272043012d6 ​https://git.rtems.org/rtems-libbsd/commit/libbsd.py?id=e2fc9082816452844a53dc97f862375b74d9523b ​https://git.rtems.org/rtems-libbsd/commit/libbsd.py?id=589f43d6af2302623229760fb0f37378241b8bfe

haven't been added to the 5-freebsd-12 branch. Therefore the License files are missing.

Comment 1
  1. Christian Mauderer, Mon, 28 Sep 2020 11:51:26 GMT

Fixed with patches 640b2a03b87481bd1a3c80d6e33a2a8a13868734, 5b3ee7027991fbf290e982a4eaffe7ea7ad21ae6, 9dd0bc27e3338bad08eaaf52d03265d2e7b9b4f7 in libbsd.

Comment 2
  1. Christian Mauderer, Mon, 28 Sep 2020 11:51:48 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

4092 - bsps/pc386: Add missing license header

Link https://devel.rtems.org/ticket/4092
Id 4092
Reporter Joel Sherrill
Created 23 September 2020 13:19:03
Modified 23 September 2020 13:30:01
Owner  
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

bspsmp.c is missing a licence header.

Comment 1
  1. Joel Sherrill, Wed, 23 Sep 2020 13:30:01 GMT
  2. status: changed from new to closed
  3. resolution: set to fixed

In 1f77518/rtems:

(The changeset message doesn't reference this ticket)


4094 - RSB: pkgconfig.py uses python2 specific "unicode" keyword

Link https://devel.rtems.org/ticket/4094
Id 4094
Reporter Stephen Clark
Created 24 September 2020 23:16:45
Modified 26 September 2020 01:01:38
Owner Stephen Clark <stephen.clark@…>
Type defect
Component tool/rsb
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

​https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/pkgconfig.py#n218 uses the unicode keyword which is python2 specific. This problem exists on both the 5 branch and the master.

Attachments:

1 Stephen Clark, Fri, 25 Sep 2020 21:47:24 GMT
  attach: set to 0001-pkgconfig.py-Removed-use-of-unicode-keyword-for-pyth.patch
 
Comment 1
  1. Stephen Clark, Sat, 26 Sep 2020 01:00:05 GMT
  2. owner: set to Stephen Clark <stephen.clark@…>
  3. status: changed from new to closed
  4. resolution: set to fixed

In e32e184/rtems-source-builder:

pkgconfig.py: Removed use of "unicode" keyword for python3 compatibility Closes #4094.
Comment 2
  1. Stephen Clark, Sat, 26 Sep 2020 01:01:38 GMT

In ed5030b/rtems-source-builder:

pkgconfig.py: Removed use of "unicode" keyword for python3 compatibility Closes #4094.

4096 - shell: CRTL-U sets the cursor to the wrong position

Link https://devel.rtems.org/ticket/4096
Id 4096
Reporter Frank Kuehndel
Created 28 September 2020 12:12:11
Modified 28 September 2020 12:21:17
Owner Sebastian Huber
Type defect
Component shell
Status closed
Resolution fixed
Version  
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

This patch fixes a tiny bug in the command line editing of the RTEMS shell.
Typing CTRL-U in the shell should remove all characters left of the cursor.
After pressing CTRL-U, the current implementation does wrongly place the cursor
at the end of the line instead at its beginning.
To reproduce the bug, start the shell and type 'abc123' (no ):

~/src/rtems $ qemu-system-arm -net none -nographic -M realview-pbx-a9 -m 256M -kernel build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl10.exe
*** BEGIN OF TEST libdl (RTL) 10 ***
*** TEST VERSION: 6.0.0.d9bdf166644f612dd628fe4951c12c6f8e94ba5f
*** TEST STATE: USER_INPUT
*** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
*** TEST TOOLS: 10.2.1 20200904 \
(RTEMS 6, RSB 31f936a7b74d60bda609a9960c6e1a705ba54974, Newlib a0d7982)
RTL (libdl) commands: dl, rtl
RTEMS Shell on /dev/foobar. Use 'help' to list commands.
SHLL [/] # abc123

Then move the cursor onto the '1' by hitting three times the key.
Next type -U:

SHLL [/] # 123 

Note that the cursor is at the end of the line (after '3') instead of correctly
at the beginning (on the '1'), now.
Continuing typing 'echo ' incorrectly results in the output:

SHLL [/] # 123echo 123 

The patch changes this behavior so that the cursor in the second last step will
be on the '1' and typing 'echo ' will then correctly reflected as:

SHLL [/] # echo 123 
Comment 1
  1. Frank Kühndel, Mon, 28 Sep 2020 12:21:17 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 18549295/rtems:

Fixing bug in line editing of the shell with CTRL-U. This patch fixes a tiny bug in the command line editing of the RTEMS shell. Typing CTRL-U in the shell should remove all characters left of the cursor. After pressing CTRL-U, the current implementation does wrongly place the cursor at the end of the line instead at its beginning. To reproduce the bug, start the shell and type 'abc123' (no ):
~/src/rtems $ qemu-system-arm -net none -nographic -M realview-pbx-a9 \
-m 256M -kernel build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl10.exe
__* BEGIN OF TEST libdl (RTL) 10 __* __* TEST VERSION: 6.0.0.d9bdf166644f612dd628fe4951c12c6f8e94ba5f __* TEST STATE: USER_INPUT __* TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP __* TEST TOOLS: 10.2.1 20200904 \
(RTEMS 6, RSB 31f936a7b74d60bda609a9960c6e1a705ba54974, Newlib a0d7982)
RTL (libdl) commands: dl, rtl RTEMS Shell on /dev/foobar. Use 'help' to list commands. SHLL / # abc123
Then move the cursor onto the '1' by hitting three times the key. Next type -U:
SHLL / # 123
Note that the cursor is at the end of the line (after '3') instead of correctly at the beginning (on the '1'), now. Continuing typing 'echo ' incorrectly results in the output:
SHLL / # 123echo 123
The patch changes this behavior so that the cursor in the second last step will be on the '1' and typing 'echo ' will then correctly reflected as:
SHLL / # echo 123
Close #4096.

4099 - Enhance rtems-bsps to print canonical names of bsps

Link https://devel.rtems.org/ticket/4099
Id 4099
Reporter Ryan Long
Created 28 September 2020 22:43:16
Modified 29 September 2020 12:59:41
Owner Ryan Long <ryan.long@…>
Type defect
Component tool
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

For some purposes it is nice to have a list of the BSPs in the form ARCHITECTURE/BSP, which can be fed into other scripts.

Attachments:

1 Ryan Long, Mon, 28 Sep 2020 22:52:00 GMT
  attach: set to 0001-rtems-bsps-add-ability-to-print-architecture-bsp-lis.patch
 
Comment 1
  1. Ryan Long, Tue, 29 Sep 2020 05:11:25 GMT
  2. owner: set to Ryan Long <ryan.long@…>
  3. status: changed from new to closed
  4. resolution: set to fixed

In 0805930/rtems:

rtems-bsps: add ability to print architecture/bsp list Closes #4099.
Comment 2
  1. Ryan Long, Tue, 29 Sep 2020 12:59:41 GMT

In fdbe9b7/rtems:

rtems-bsps: add ability to print architecture/bsp list Closes #4099.

4102 - rtems-pairs includes invalid BSP

Link https://devel.rtems.org/ticket/4102
Id 4102
Reporter Joel Sherrill
Created 29 September 2020 22:00:07
Modified 9 November 2022 23:16:11
Owner Chris Johns
Type defect
Component tool
Status closed
Resolution wontfix
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

On both 5 and master, the list of BSP pairs includes bbxm which appears to come from the file bsps/arm/beagle/simscripts/bbxm.cfg which is obviously not a build configuration file.

arm: (families:21 bsps:57)
altcycv_devkit altera-cyclone-v
atsamv atsam
bbxm beagle
beagleboardorig beagle
beagleboardxm beagle
beagleboneblack beagle
beaglebonewhite beagle
Comment 1
  1. Joel Sherrill, Tue, 29 Sep 2020 22:00:18 GMT
  2. owner: set to Chris Johns
  3. status: changed from new to assigned
Comment 2
  1. Chris Johns, Wed, 09 Nov 2022 23:16:11 GMT
  2. status: changed from assigned to closed
  3. resolution: set to wontfix

4106 - RSB Missing BSP bset for xilinx_zynq_a9_qemu

Link https://devel.rtems.org/ticket/4106
Id 4106
Reporter Joel Sherrill
Created 30 September 2020 15:52:28
Modified 9 November 2022 22:32:24
Owner  
Type defect
Component tool/rsb
Status closed
Resolution wontfix
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

This needs to be added to the RSB for 5 and master.

Comment 1
  1. Chris Johns, Wed, 09 Nov 2022 22:32:24 GMT
  2. status: changed from new to closed
  3. resolution: set to wontfix

Please reopen when the bset is added.


4114 - Cortex-A9 MPCore based BSPs should include the workaround for Errata 794072 and 845369

Link https://devel.rtems.org/ticket/4114
Id 4114
Reporter Sebastian Huber
Created 2 October 2020 09:34:40
Modified 16 October 2020 04:48:30
Owner Sebastian Huber
Type defect
Component arch/arm
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The workaround may be already set up by the bootloader. Not having the workaround applied may lead to system crashes, so make sure the BSP does it during system startup.

Comment 1
  1. Sebastian Huber, Mon, 05 Oct 2020 06:46:34 GMT
  2. description: modified (diff)
  3. summary: changed from Cortex-A9 MPCore based BSPs should include the workaround for Errata 845369 to Cortex-A9 MPCore based BSPs should include the workaround for Errata 794072 and 845369
Comment 2
  1. Sebastian Huber, Fri, 16 Oct 2020 04:48:26 GMT

In 3d7da435/rtems:

bsps/arm: Workaround for Errata 845369 Add a workaround for Cortex-A9 Errata 845369: Under Very Rare Timing Circumstances Transition into Streaming Mode Might Create Data Corruption. Update #4114.
Comment 3
  1. Sebastian Huber, Fri, 16 Oct 2020 04:48:30 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In e71e271/rtems:

bsps/arm: Add workaround for Errata 794072 Add a workaround for Cortex-A9 Errata 845369: A short loop including a DMB instruction might cause a denial of service on another which executes a CP15 broadcast operation. Close #4114.

4119 - rtems-bsp-tester: Off By One for Completed Jobs

Link https://devel.rtems.org/ticket/4119
Id 4119
Reporter Joel Sherrill
Created 2 October 2020 17:36:58
Modified 9 November 2022 23:17:29
Owner Chris Johns
Type defect
Component tool
Status closed
Resolution wontfix
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Looking at ​https://lists.rtems.org/pipermail/build/2020-September/019154.html, you can see that the completed number of jobs doesn't match up with the number for the last build:

Total Time            : 2:05:13.725904 for 1696 completed job(s)
Average BSP Build Time: 0:00:04.430262
.....
1695 profiling v850/v850sim build:
configure: /home/joel/rtems-cron-6/rtems/configure\
--target=v850-rtems6 --enable-rtemsbsp=v850sim --prefix=/home/joel\
/rtems-cron-6/tools/6/bsps --enable-profiling --disable-smp

I think there are 1695 jobs completed not 1696. :)

Comment 1
  1. Chris Johns, Wed, 09 Nov 2022 23:17:29 GMT
  2. status: changed from assigned to closed
  3. resolution: set to wontfix

Please reopen if this is still valid and important for the 5 branch.


4149 - RFS bit map search buffer overflow

Link https://devel.rtems.org/ticket/4149
Id 4149
Reporter Chris Johns
Created 15 October 2020 06:13:07
Modified 16 October 2020 23:55:53
Owner Chris Johns
Type defect
Component fs/rfs
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Cloned from #4148:

The bit search create writes past the end of its buffer. See:

​https://lists.rtems.org/pipermail/devel/2020-October/062701.html

Comment 1
  1. Chris Johns, Fri, 16 Oct 2020 23:55:53 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 7021c014/rtems:

libfs/rfs: Check search bit map end on last bit Do not write past the last location of the search bit map whe nit is being created. Closes #4149

4154 - Improve the workaround for the LEON3FT store-store errata: TN-0009

Link https://devel.rtems.org/ticket/4154
Id 4154
Reporter Sebastian Huber
Created 16 October 2020 05:45:40
Modified 23 June 2021 07:07:55
Owner Daniel Hellstrom
Type defect
Component arch/sparc
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords qualification
Cc  
Blocking  
Blocked by  

Description

See also:

​https://www.gaisler.com/doc/antn/GRLIB-TN-0009.pdf

Some areas were already fixed by #3057.

Comment 1
  1. Daniel Cederman, Sun, 07 Mar 2021 15:56:20 GMT

In 980cdb8/rtems:

sparc: Remove sequences that the B2BST scan script warns about Update #4154.
Comment 2
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:57:36 GMT

In 3074eb0/rtems:

sparc,leon: avoid triggering TN-0009 bad sequence Update #4154.
Comment 3
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:57:40 GMT

In 2497a46a/rtems:

sparc,leon: avoid triggering LEON3FT errata TN-0009 Update #4154.
Comment 4
  1. Daniel Hellstrom, Thu, 11 Mar 2021 15:17:11 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2
Comment 5
  1. Daniel Hellstrom, Thu, 11 Mar 2021 17:01:09 GMT
  2. summary: changed from Add a workaround for the LEON3FT store-store errata: TN-0009 to Improve the workaround for the LEON3FT store-store errata: TN-0009
Comment 6
  1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
  2. keywords: qualification added

4165 - Fix NVMe disk synchronization and media block handling (cloned)

Link https://devel.rtems.org/ticket/4165
Id 4165
Reporter Sebastian Huber
Created 27 October 2020 05:24:30
Modified 27 October 2020 05:27:52
Owner Sebastian Huber
Type defect
Component network/libbsd
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Cloned from #4164.

Comment 1
  1. Sebastian Huber, Tue, 27 Oct 2020 05:27:52 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

4169 - Link problem of C++ tests when using libpci in BSP

Link https://devel.rtems.org/ticket/4169
Id 4169
Reporter Jan Sommer
Created 29 October 2020 13:19:02
Modified 30 October 2020 02:22:13
Owner Jan Sommer <jan.sommer@…>
Type defect
Component lib
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

When using libpci in a custom BSP we experienced linking problems for C++ test (e.g. spcxx01).

The reason is the missing extern C include guards for confdefs/libpci.h.
Therefore, the reference to pci_config_lib_init is mangled.

A patch fixing this problem is provided here: ​https://lists.rtems.org/pipermail/devel/2020-October/062981.html

Comment 1
  1. Jan Sommer, Fri, 30 Oct 2020 02:22:13 GMT
  2. owner: set to Jan Sommer <jan.sommer@…>
  3. status: changed from new to closed
  4. resolution: set to fixed

In f84c4a5/rtems:

confdefs: Add extern C guards to libpci.h Closes #4169

4174 - devctl.h does not compile from C++

Link https://devel.rtems.org/ticket/4174
Id 4174
Reporter Joel Sherrill
Created 9 November 2020 21:34:40
Modified 10 December 2020 21:08:18
Owner Joel Sherrill
Type defect
Component tool/newlib
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The closing boilerplate of the C++ extern C wrapper is out of order with another #endif and the resulting code does not compile.

The attached patch addresses this but it needs to be merged to newlib and the RSB updated before this ticket closed.

Patch to newlib is on #4193.

Attachments:

1 Joel Sherrill, Mon, 09 Nov 2020 21:35:20 GMT
  attach: set to 0001-libc-include-newlib.h-Fix-C-compilation-issue.patch
 
Comment 1
  1. Joel Sherrill, Mon, 16 Nov 2020 14:19:02 GMT

Fixed pushed to newlib.

​https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=302b82afee423fcb5a447a222e2b771ef9c06ee0

Comment 2
  1. Joel Sherrill, Tue, 17 Nov 2020 15:44:02 GMT
  2. owner: changed from Joel Sherrill to Sebastian Huber

Assigning to Sebastian since he is bumping the RSB recipes and can close when that is done.

Comment 3
  1. Joel Sherrill, Tue, 08 Dec 2020 17:47:04 GMT
  2. owner: changed from Sebastian Huber to Joel Sherrill
  3. description: modified (diff)
Comment 4
  1. Joel Sherrill, Thu, 10 Dec 2020 21:08:18 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 803d42c/rtems-source-builder:

Add patch to newlib for devctl.h to compile with C++ Closes #4174.

4185 - arm/bsps: Small MMU pages are rounded to 1 MiB (cloned)

Link https://devel.rtems.org/ticket/4185
Id 4185
Reporter Jan Sommer
Created 24 November 2020 08:34:18
Modified 15 December 2020 10:27:33
Owner Jan Sommer <jan.sommer@…>
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Cloned from #4184:

The function arm_cp15_start_set_translation_table_entries rounds the end address of a section up to 1 MiB even if small 4kiB pages are used (i.e. ARM_MMU_USE_SMALL_PAGES enabled).

Will submit a patch which only rounds the end address to 4kiB boundary.

Comment 1
  1. Jan Sommer, Wed, 02 Dec 2020 12:39:29 GMT

To keep track of it during the Christmas break: The patch is here:

​https://lists.rtems.org/pipermail/devel/2020-November/063461.html

Comment 2
  1. Jan Sommer, Fri, 11 Dec 2020 05:55:49 GMT
  2. owner: set to Jan Sommer <jan.sommer@…>
  3. status: changed from new to closed
  4. resolution: set to fixed

In 21ed8d11/rtems:

bsps/arm: Fix MMU small pages support For small tables only round to the next 4kiB instead of 1MiB Close #4185.
Comment 3
  1. Sebastian Huber, Tue, 15 Dec 2020 10:27:33 GMT

In 2a8f755/rtems:

bsps/arm: Fix MMU configuration Update #4185.

4189 - rtems_interrupt_server_delete() does not destroy the ISR lock of the server control (cloned)

Link https://devel.rtems.org/ticket/4189
Id 4189
Reporter Sebastian Huber
Created 25 November 2020 07:24:37
Modified 25 November 2020 07:33:25
Owner Sebastian Huber
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Cloned from #4158:

This leads to memory corruption if RTEMS_PROFILING and RTEMS_SMP is enabled.

Comment 1
  1. Sebastian Huber, Wed, 25 Nov 2020 07:33:25 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 1dbdf94e/rtems:

bsps: Fix rtems_interrupt_server_delete() The ISR lock must be destroyed to prevent memory corruption if RTEMS_PROFILING and RTEMS_SMP is enabled. Close #4189.

4190 - Back port rtems_interrupt_server_create() improvements

Link https://devel.rtems.org/ticket/4190
Id 4190
Reporter Sebastian Huber
Created 25 November 2020 07:31:46
Modified 25 November 2020 07:33:28
Owner Sebastian Huber
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Back port 99c73303deb09ad66d4cc1c89961f62e4e618938 to RTEMS 5 to fix "fman" network interface driver issues in libbsd.

Comment 1
  1. Sebastian Huber, Wed, 25 Nov 2020 07:33:28 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In dedc3e1d/rtems:

rtems: Improve rtems_interrupt_server_create() Also start interrupt server tasks on processors which do not have a scheduler. Applications may dynamically manage processors using rtems_scheduler_remove_processor() and rtems_scheduler_add_processor(). Close #4190.

4224 - Missing "extern" in RTEMS_LINKER_ROSET_ITEM_ORDERED_DECLARE() (cloned)

Link https://devel.rtems.org/ticket/4224
Id 4224
Reporter Sebastian Huber
Created 25 January 2021 05:43:27
Modified 25 January 2021 05:48:17
Owner Sebastian Huber
Type defect
Component rtems
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Cloned from #4223:

The fix for #3865 contains a typo. In RTEMS_LINKER_ROSET_ITEM_ORDERED_DECLARE() there is a missing "extern".

Comment 1
  1. Sebastian Huber, Mon, 25 Jan 2021 05:48:17 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 5ae7ec9/rtems:

Fix RTEMS_LINKER_ROSET_ITEM_ORDERED_DECLARE() Add "extern" similar to RTEMS_LINKER_RWSET_ITEM_ORDERED_DECLARE(). Close #4224.

4232 - Timeout for automatic barriers is broken (cloned)

Link https://devel.rtems.org/ticket/4232
Id 4232
Reporter Sebastian Huber
Created 6 February 2021 20:03:57
Modified 6 February 2021 20:35:12
Owner Sebastian Huber
Type defect
Component score
Status closed
Resolution fixed
Version 4.11
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Cloned from #4230:

A barrier wait timeout at an automatic barrier doesn't decrement the count of waiting threads.

Comment 1
  1. Sebastian Huber, Sat, 06 Feb 2021 20:35:05 GMT

In 5861e42/rtems:

score: Constify Thread_queue_First_operation Update #4232.
Comment 2
  1. Sebastian Huber, Sat, 06 Feb 2021 20:35:09 GMT

In cc2a237/rtems:

score: Make FIFO thread queue ops public Update #4232.
Comment 3
  1. Sebastian Huber, Sat, 06 Feb 2021 20:35:12 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In ef1ac8af/rtems:

score: Add barrier thread queue operations This fixes a missing decrement of the number of waiting threads during a barrier wait timeout. Close #4232.

4233 - MVME 2600/2700 has no console output (cloned)

Link https://devel.rtems.org/ticket/4233
Id 4233
Reporter Chris Johns
Created 7 February 2021 02:58:12
Modified 10 February 2021 06:36:01
Owner Chris Johns
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Cloned from #4231:

A single character is output then nothing further. Tests output using the printk but spconsole01 fails.

It seems there is a problem with the UART driver interrupts.

Comment 1
  1. Chris Johns, Wed, 10 Feb 2021 06:36:01 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 6d9843e/rtems:

powerpc/shared: ISA bus bridge fails to enable the openpic irq The call to enable the openpic irq for the ISA bridge fails because the IRQ used is offset by the ISA bus signals and the openpic call expects an IRQ relative to its signals. Add the MVME 2600/2700 to the list of boards with an ISA bridge. Closes #4233

4234 - powerpc/motorola_shared display current RTEMS on boot

Link https://devel.rtems.org/ticket/4234
Id 4234
Reporter Chris Johns
Created 7 February 2021 03:00:53
Modified 10 February 2021 06:36:05
Owner Chris Johns
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The boot messages display the RTEMS version. Display the current version and not a hard coded version:

-----------------------------------------
Welcome to rtems-5.0.0 (PowerPC/Generic (classic FPU)/mvme2307) on MVME 2600/2700 with MVME761
-----------------------------------------
Comment 1
  1. Chris Johns, Wed, 10 Feb 2021 06:36:05 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 388bd805/rtems:

bsp/motorola_powerp: Print RTEMS_VERSION from the bootloader Close #4234

4236 - bsps/zynq: termios not working correctly for stdin

Link https://devel.rtems.org/ticket/4236
Id 4236
Reporter Jan Sommer
Created 9 February 2021 12:22:15
Modified 9 March 2021 08:30:38
Owner Jan Sommer <jan.sommer@…>
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The termios test application does not work correctly for Zynq based BSPs.
Also scanf and similar functions reading from stdin do return immediately and do not block as expected.

The console driver has been fixed in master. This should be backported to 5.x.

Comment 1
  1. Kinsey Moore, Tue, 09 Mar 2021 08:30:07 GMT

In 2f32370/rtems:

zynq-uart: Fix set_attributes implementation The zynq-uart set_attributes implementation was configured to always return false which causes spconsole01 to fail. This restores the disabled implementation which sets the baud rate registers appropriately and allows spconsole01 to pass. This also expands the set_attributes functionality to allow setting of the stop bits, character width, and parity. Updates #4236
Comment 2
  1. Jan Sommer, Tue, 09 Mar 2021 08:30:38 GMT
  2. owner: set to Jan Sommer <jan.sommer@…>
  3. status: changed from new to closed
  4. resolution: set to fixed

In 645dbc5/rtems:

bsps/shared: Allow setting baud rate for zynq uart Closes #4236

4247 - Change motorola_powerpc bsp to support irq-generic (cloned)

Link https://devel.rtems.org/ticket/4247
Id 4247
Reporter Chris Johns
Created 16 February 2021 04:18:24
Modified 16 February 2021 20:30:07
Owner Chris Johns
Type enhancement
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Cloned from #4238:

Update the motorola_powerpc to support irq-generic moving the IRQ management to the IRQ server. This enables libbsd support for interrupts.

Comment 1
  1. Chris Johns, Tue, 16 Feb 2021 20:30:07 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 2f56b737/rtems:

Update motorola_power to irq-generic interrupt management Add support to the BSP to enable irq-generic management Update the powerpc shared irq code to support irq-generic. This is an opt in option for existing powerpc bsps. This change should be simpler now Fix a number of issues in ISA IRQ controller handling by porting fixes from the i386 (PC) BSP Closes #4247 Closes #4248

4248 - PowerPC shared ISA IRQ support is broken (cloned)

Link https://devel.rtems.org/ticket/4248
Id 4248
Reporter Chris Johns
Created 16 February 2021 04:19:03
Modified 16 February 2021 20:30:07
Owner Chris Johns
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords i8258 irq interrupt
Cc  
Blocking  
Blocked by  

Description

Cloned from #4239:

The PowerPC shared ISA IRQ management in i8259s.c is broken. It fails to handle:

  • Interrupt acknowledgements for the slave controller when the master has a lower priority pending interrupt acknowledge the slave and the master controllers
  • The nesting support to suspend and resume an interrupt does not correctly handle the enable/disable
  • The initialise of an interrupt does not handle any pending request
  • Locks up when using with the IRQ server which is executing the handler in a task context

All these issues have been fixed in the i386 BSP however the code between is not shared as the i386 BSP has BSP specific IRQ management code as well.

Comment 1
  1. Chris Johns, Tue, 16 Feb 2021 20:30:07 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 2f56b737/rtems:

Update motorola_power to irq-generic interrupt management Add support to the BSP to enable irq-generic management Update the powerpc shared irq code to support irq-generic. This is an opt in option for existing powerpc bsps. This change should be simpler now Fix a number of issues in ISA IRQ controller handling by porting fixes from the i386 (PC) BSP Closes #4247 Closes #4248

4249 - fix mkimage.py script type processing

Link https://devel.rtems.org/ticket/4249
Id 4249
Reporter Chris Johns
Created 16 February 2021 05:21:34
Modified 16 February 2021 05:24:00
Owner Chris Johns
Type defect
Component tool
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The explaination is taken from André on the user list:

Hello,

after some digging I think I found the problem and at least a workaround.

As a disclaimer, I do not know if this really counts as a general fix.
I have not invested enough time to dig through the original mkimage U-Boot source to figure this out.
But I have attached my workaround patch if anyone might face the same problems.

The source of the problem are eight bytes between the header and the actual input file which are missing when using mkimage.py.
Also the input size and input crc are wrong which is a result of the missing bytes.

These eight bytes always reflect the actual size of the input file (first four bytes) with four bytes zeros following.
Within the original mkimage tool these eight bytes are considered part of the input file section in the output file.
Therefore the calculated input size is eight bytes higher and the input crc differs.

As a workaround the mkimage.py script will add these eight bytes to the output file and the input crc calculation and adjusts the input size.
This only happens when the type script was selected.

Best regards
André

​https://lists.rtems.org/pipermail/users/2021-January/068060.html ​https://lists.rtems.org/pipermail/users/2021-February/068140.html ​https://lists.rtems.org/pipermail/devel/2021-February/064491.html

Comment 1
  1. Andre Nahrwold, Tue, 16 Feb 2021 05:24:00 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In e621fd9/rtems-tools:

misc: tools: fix mkimage.py script type processing Closes #4249

4263 - Activate ehci_pci in rtems-libbsd

Link https://devel.rtems.org/ticket/4263
Id 4263
Reporter GabrielMoyano
Created 22 February 2021 10:29:08
Modified 9 March 2021 10:38:24
Owner Jan Sommer
Type enhancement
Component network/libbsd
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Import ehci_pci from freebsd-org using freebsd-to-rtems.py

Comment 1
  1. Jan Sommer, Mon, 08 Mar 2021 17:18:19 GMT
  2. component: changed from admin to network/libbsd
Comment 2
  1. Jan Sommer, Tue, 09 Mar 2021 10:37:15 GMT
  2. owner: set to Jan Sommer
  3. status: changed from new to accepted
Comment 3
  1. Jan Sommer, Tue, 09 Mar 2021 10:38:24 GMT
  2. status: changed from accepted to closed
  3. resolution: set to fixed

Fixed with ​https://git.rtems.org/rtems-libbsd/commit/?h=5-freebsd-12&id=ea5d0c78038d92597983c0922a011a62f5dc2dea


4266 - motorola_powerpc bootloader images not linking correctly

Link https://devel.rtems.org/ticket/4266
Id 4266
Reporter Chris Johns
Created 24 February 2021 05:52:30
Modified 3 March 2021 19:58:04
Owner Chris Johns
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The change to support code and data sections has broken creating net boot images for the MVME 2700 (mvme2307) BSP. The linker command file ppcboot.lds does not handle the per function text sections.

Comment 1
  1. Chris Johns, Wed, 24 Feb 2021 21:50:13 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 3824960/rtems:

powerpc/motorola_power: Link all text sections into the executable image The change to building all code with code and data sections means we have a section per function. Make sure all functions are placed in the text section. Closes #4266
Comment 2
  1. Chris Johns, Fri, 26 Feb 2021 04:19:33 GMT
  2. status: changed from closed to reopened
  3. resolution: fixed deleted

The change does not resolve the issue. I am not sure what happened in my testing.

The bootloader linked executable has the .text.* sections present. I am wondering if the Motorola debug monitor is not capable of loaded this type of ELF file. As a result the card information is not found and boot process fails. You can observe this by running readelf -a on the rtems.img.elf file created when making the image file. This is the RTEMS 5 executable linked with the RTEMS 6 bootloader:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 010000 00f145 00  AX  0   0 32
  [ 2] .eh_frame         PROGBITS        0000f148 01f148 0017e0 00   A  0   0  4
  [ 3] .image            PROGBITS        00010928 020928 017778 00  WA  0   0  1
  [ 4] .reloc            PROGBITS        000280a0 0380a0 0002bc 00  WA  0   0  4
  [ 5] .handlers         PROGBITS        0002835c 03835c 0003ac 00  WA  0   0  1
  [ 6] .data             PROGBITS        00028720 038720 003c80 00  WA  0   0 32
  [ 7] .bss              NOBITS          0002c3a0 03c3a0 001158 00  WA  0   0 32
  [ 8] .gnu.attributes   GNU_ATTRIBUTES  00000000 03c3a0 000010 00      0   0  1
  [ 9] .symtab           SYMTAB          00000000 03c3b0 0066c0 10     10 698  4
  [10] .strtab           STRTAB          00000000 042a70 00616c 00      0   0  1
  [11] .shstrtab         STRTAB          00000000 048bdc 00005e 00      0   0  1 

The RTEMS 6 executable has more code than the RTEMS 5. I tried a number of combinations in the linker command script but could not find a suitable result.

I have now looked into fixing the building of the bootloader in the RTEMS 5 automake build system and there are some fundamental issues present and I am yet to decide how this is to be resolved.

The bootloader Makefile has a variable BOOTLOADER_CPU_FLAGS: ​https://git.rtems.org/rtems/tree/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/Makefile.am?h=5#n22 This is empty because CPU_FLAGS is not exported into this file:

$ grep CPU_FLAGS powerpc-rtems5/c/mvme2307/lib/libbsp/powerpc/motorola_powerpc/bootloader/Makefile
$ 

The CPU flags are being provided the globally set CFLAGS and this includes the text and data segment flags which is causing the problem. Adding:

CFLAGS =
CPPFLAGS =
CCASFLAGS = 

Results in no valid CPU flags being set.

I am reluctant to add exporting the CPU flags to a high level in the build process because it will be seen by all BSPs and it is very difficult to know if there are possible side effects in another BSP.

I cannot only see a couple of solutions:

Remove the problem flags from the build Find a way to include the config with the flags
Comment 3
  1. Chris Johns, Fri, 26 Feb 2021 07:14:46 GMT

I have isolated the issue to the building of zlib.c by the RTEMS 5 gcc. If I build just this file with the RTEMS 6 gcc the board boots.

Comment 4
  1. Chris Johns, Fri, 26 Feb 2021 19:04:37 GMT

Comparing the zlib.o ELF sections for RTEMS 5 and 6 the .bss size is almost 0:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 000034 003cb8 00  AX  0   0  4
  [ 2] .rela.text        RELA            00000000 004890 000444 0c   I 16   1  4
  [ 3] .data             PROGBITS        00000000 003cec 00027c 00  WA  0   0  4
  [ 4] .bss              NOBITS          00000000 003f68 000008 00  WA  0   0  4 

and zlib has a set of tables it generates. The RTEMS 6 or gcc-10 ELF sections are:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 000034 003c7c 00  AX  0   0  4
  [ 2] .rela.text        RELA            00000000 005014 000444 0c   I 18   1  4
  [ 3] .data             PROGBITS        00000000 003cb0 00027c 00  WA  0   0  4
  [ 4] .bss              NOBITS          00000000 003f2c 0010a8 00  WA  0   0  4 

An inspection of the generated assember shows the data being allocated using the .comm directory placing the data in the common section. Adding -f-no-common to the building of the bootloader has it working.

Comment 5
  1. Chris Johns, Fri, 26 Feb 2021 19:06:17 GMT

GCC 10 defaults to -fno-common ...

​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

Comment 6
  1. Chris Johns, Fri, 26 Feb 2021 19:21:14 GMT

The preferred solution is to add *(COMMON) to the .bss section in the linker command file used to link the boot loader. This will work with any gcc version and default they decide on.

Comment 7
  1. Chris Johns, Sun, 28 Feb 2021 01:28:36 GMT
  2. status: changed from reopened to closed
  3. resolution: set to fixed

In d1bab98/rtems:

powerpc/motorola_power: Place any common data in the .bss section It seems the compiler how defaults to -fcommon and this means some uninitialised data is ignored. Closes #4266
Comment 8
  1. Chris Johns, Sun, 28 Feb 2021 03:37:18 GMT

In 75fb7a0e/rtems:

powerpc/motorola_power: Link all text sections into the executable image The change to building all code with code and data sections means we have a section per function. Make sure all functions are placed in the text section. Closes #4266
Comment 9
  1. Chris Johns, Sun, 28 Feb 2021 03:37:22 GMT

In 96918af/rtems:

powerpc/motorola_power: Place any common data in the .bss section It seems the compiler how defaults to -fcommon and this means some uninitialised data is ignored. Closes #4266
Comment 10
  1. Michael Davidsaver, Wed, 03 Mar 2021 19:58:04 GMT

Maybe worthwhile looking into the --orphan-handling=MODE argument for ld in newer binutils? At least "warn" if not "error" seems like it would have made this situation more obvious.

​https://sourceware.org/binutils/docs/ld/Orphan-Sections.html


4274 - GR1553RT driver: fixes to memory allocation and locking on descriptor updates

Link https://devel.rtems.org/ticket/4274
Id 4274
Reporter Daniel Hellstrom
Created 26 February 2021 15:23:59
Modified 14 December 2022 23:27:11
Owner Daniel Hellstrom
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Issues in GRLIB GR1553B RT mode device driver (used by GR740 BSP):

gr1553rt_list_init() - fixed memory leak when dynamic allocation failed
gr1553rt_bd_update() - release interrupt/spin-lock correctly

Comment 1
  1. Arvid Bjorkengren, Sun, 07 Mar 2021 15:56:23 GMT

In a97a473/rtems:

leon,gr1553rt: Fixed memory leak Update #4274.
Comment 2
  1. Arvid Bjorkengren, Sun, 07 Mar 2021 15:56:26 GMT

In 1223f5e/rtems:

leon,gr1553rt: Fixed spinlock unlock Update #4274.
Comment 3
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:20:48 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2

4275 - GR1553B: use new codec available in GR740 revision 1

Link https://devel.rtems.org/ticket/4275
Id 4275
Reporter Daniel Hellstrom
Created 26 February 2021 15:46:50
Modified 14 December 2022 23:26:11
Owner Daniel Hellstrom
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Select the new 1553 codec available specifically in GR740.

Comment 1
  1. Arvid Bjorkengren, Sun, 07 Mar 2021 15:56:30 GMT

In 14fcf388/rtems:

leon,gr1553b: set codec version This is enables the updated codec for GR740 and is backwards compatible with all other versions of the IP. Updates #4275.
Comment 2
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:21:45 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2

4303 - grlib,gr1553bc: better check of the DMA area address alignment

Link https://devel.rtems.org/ticket/4303
Id 4303
Reporter Daniel Hellstrom
Created 7 March 2021 13:26:40
Modified 9 March 2021 13:22:56
Owner Daniel Hellstrom
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

GR1553 BC hardware truncates unaligned DMA memory addresses. Need to check input and the final DMA address and fail if unaligned address.

Comment 1
  1. Daniel Hellstrom, Sun, 07 Mar 2021 13:46:56 GMT
  2. component: changed from admin to bsps
Comment 2
  1. Arvid Bjorkengren, Sun, 07 Mar 2021 15:56:33 GMT

In 8004ffb/rtems:

leon,gr1553b: Only align allocated memory. Verify alignment of memory. Update #4303.
Comment 3
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:22:56 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2

Minor fix, no need to add to 5.2 Changelog.


4304 - grlib,grspw: SET_PACKET_SIZE could use old DMA address

Link https://devel.rtems.org/ticket/4304
Id 4304
Reporter Daniel Hellstrom
Created 7 March 2021 13:37:08
Modified 9 March 2021 13:23:36
Owner Daniel Hellstrom
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

When the DMA table has been allocated dynamically, the IOCTL_SET_PACKETSIZE will trigger an issue where pDev->rx and pDev->tx are not updated with the new DMA tables base address. Instead the old pointers are used.

There is no point in reallocting the DMA tables because there is no configuration option to it.

Comment 1
  1. Daniel Hellstrom, Sun, 07 Mar 2021 13:37:33 GMT
  2. summary: changed from leon,grspw: SET_PACKET_SIZE could use old DMA address to grlib,grspw: SET_PACKET_SIZE could use old DMA address
Comment 2
  1. Daniel Hellstrom, Sun, 07 Mar 2021 13:47:21 GMT
  2. component: changed from admin to bsps
Comment 3
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:56:36 GMT

In 84fb340/rtems:

leon,grspw: fix for SET_PACKET_SIZE When the DMA table has been allocated dynamically, the IOCTL_SET_PACKETSIZE will trigger an issue where pDev->rx and pDev->tx are not updated with the new DMA tables base address. Instead the old pointers are used. There is no point in reallocting the DMA tables because there is no configuration option to it. Therefore the DMA tables allocation is moved to a separate function never called from SET_PACKETSIZE. Update #4304.
Comment 4
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:23:36 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2

4305 - grlib,ambapp: update GRLIB IP core ID list

Link https://devel.rtems.org/ticket/4305
Id 4305
Reporter Daniel Hellstrom
Created 7 March 2021 13:41:16
Modified 9 March 2021 13:24:23
Owner Daniel Hellstrom
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity trivial
Keywords  
Cc  
Blocking  
Blocked by  

Description

Add the new AMBA PnP IDs of the new cores.

Comment 1
  1. Daniel Hellstrom, Sun, 07 Mar 2021 13:47:46 GMT
  2. component: changed from admin to bsps
Comment 2
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:56:39 GMT

In 0ab993b/rtems:

grlib,ambapp: added new IP core IDs Update #4305.
Comment 3
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:24:23 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2

Minor improvement, no need to add to 5.2 changelog.


4306 - grlib,can: introduce a new common CAN baud-rate timing calculating functions

Link https://devel.rtems.org/ticket/4306
Id 4306
Reporter Daniel Hellstrom
Created 7 March 2021 13:46:26
Modified 9 March 2021 13:25:01
Owner Daniel Hellstrom
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

There is no point in having two different implementations specific per GRLIB CAN device driver (OCCAN and GRCAN). Instead we can use the common CAN timing definitions and translate that into the device specific parameters using a new common calculation function.

Comment 1
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:56:43 GMT

In da7cb87/rtems:

leon,can: introduce common CAN baud-rate calculation function Reimplemented the baud-rate algorithm from scratch to cope with GRCAN, GRCANFD and OC_CAN devices. Update #4306.
Comment 2
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:56:46 GMT

In 78b45cc5/rtems:

leon,grcan: use common CAN baud-rate calculation routine Update #4306.
Comment 3
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:56:49 GMT

In 7db032cf/rtems:

leon,occan: use common CAN baud-rate calculation routine Update #4306.
Comment 4
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:25:01 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2

4307 - grlib,grcanfd: extend the GRCAN driver with GRCANFD support

Link https://devel.rtems.org/ticket/4307
Id 4307
Reporter Daniel Hellstrom
Created 7 March 2021 14:00:03
Modified 9 March 2021 13:25:50
Owner Daniel Hellstrom
Type enhancement
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The new GRCAN_FD IP supports CAN FD standard and is mostly backwards compatible with GRCAN SW interface. It introduces support for CAN-FD frames and a new bit-rate timing registers for new baud-rate.

The GRCAN driver have been extended to support the GRCANFD IP using the same API. Device IP-core specific functions are split into different files (grcanstd.c and grcanfd.c).

Comment 1
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:56:53 GMT

In e1062fae/rtems:

grlib: added 64-bit read no-cache function Update #4307.
Comment 2
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:56:56 GMT

In c41e7ba/rtems:

leon,grcan: added support for GRCANFD The new GRCAN_FD IP supports CAN FD standard and is mostly backwards compatible with GRCAN SW interface. The GRCAN driver have been extended to support the GRCANFD IP using the same driver. Additional functions have been added that uses a new CAN FD frame format and read/write/baud-rate functions that supports both GRCANFD and GRCAN. To keep the SW API fully backwards compatible with GRCAN, the old functions remain. Update #4307.
Comment 3
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:56:59 GMT

In e180f281/rtems:

leon,grcanfd: split out GRCANFD specific support in separate file Update #4307.
Comment 4
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:57:03 GMT

In 23cc5a6/rtems:

leon,grcan: split out GRCAN non-FD specific support in separate file Update #4307.
Comment 5
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:25:50 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2

4308 - grlib,greth: added support for variable sized descriptor table sizes

Link https://devel.rtems.org/ticket/4308
Id 4308
Reporter Daniel Hellstrom
Created 7 March 2021 14:06:05
Modified 9 March 2021 13:26:25
Owner Daniel Hellstrom
Type enhancement
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Comment 1
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:57:06 GMT

In c13205f/rtems:

leon,greth: added support for variable sized descriptor table sizes The descriptor table size is equal to its alignment and set when configuring the HW IP through VHDL generics. This SW patch simply probes the HW how large the RX/TX descriptor tables are and adjusts accordingly. The number of descriptors actual used are controlled by other settings (rxDescs and txDescs) controlled by the user. Update #4308.
Comment 2
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:26:25 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2

Minor improvement, no need to add to 5.2 changelog.


4309 - bsps,leon3: avoid BSP dependency on apbuart/timer driver

Link https://devel.rtems.org/ticket/4309
Id 4309
Reporter Daniel Hellstrom
Created 7 March 2021 14:13:17
Modified 9 March 2021 13:26:49
Owner Daniel Hellstrom
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The BSP amba.c references the GPTIMER and APBUART drivers causing them to be dragged in when the driver manager is used. By moving the dependencies to a separate file the user can override the default without dragging in unused drivers.

Comment 1
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:57:09 GMT

In 0ed294b6/rtems:

leon3: avoid dependency on apbuart/timer driver Moves drvmgr_drivers[] from amba.c to a separate file in order to avoid the dependecy on APBUART/GPTIMER drivers. This has an effect when user configured not to use timer or uart in their project. Update #4309.
Comment 2
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:26:49 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2

4310 - bsps,leon3: BSP assumes that timer pre-scaler runs at 1MHz

Link https://devel.rtems.org/ticket/4310
Id 4310
Reporter Daniel Hellstrom
Created 7 March 2021 14:19:31
Modified 20 October 2021 08:16:23
Owner Daniel Hellstrom
Type enhancement
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

When driver manager GPTIMER driver is used a different pre-scaler can be supported by a driver setting. This is used to increase the resolution of the timer.

Comment 1
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:57:12 GMT

In 81e4a15/rtems:

leon,ckinit: avoid assuming 1MHz timer pre-scaler clock Update #4310.
Comment 2
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:27:14 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2
Comment 3
  1. Andrea, Wed, 20 Oct 2021 08:16:23 GMT

Is there the same assumption in RTEMS 4.8 too?


4311 - bsps,leon3: _st64() did not follow the SPARC ABI

Link https://devel.rtems.org/ticket/4311
Id 4311
Reporter Daniel Hellstrom
Created 7 March 2021 14:29:23
Modified 9 March 2021 13:27:56
Owner Daniel Hellstrom
Type defect
Component arch/sparc
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

STD instruction requires even register alignment for 64-bit data.

Comment 1
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:57:19 GMT

In d9d96f0/rtems:

sparc: fix bad register alignment for 64 bit store Update #4311.
Comment 2
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:27:56 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2

4312 - bsps,leon3: need to make cpucounter restart after underflow

Link https://devel.rtems.org/ticket/4312
Id 4312
Reporter Daniel Hellstrom
Created 7 March 2021 14:34:33
Modified 9 March 2021 13:28:21
Owner Daniel Hellstrom
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Fix for the BSP timer initialization when GPTIMER is used as the cpucounter. Without restarting in HW the cpucounter would stop after some time.

Comment 1
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:57:16 GMT

In cb8379d/rtems:

leon: restart and load timer counter at initialization Without this smp05 and smpthreadlife01 tests may fail depending on how the boot loader initialized the GPTIMER. Before the time counter stopped counting when reaching zero, but tests could work since it could take 232 us before stopping. The timer driver will potentially overwrite this, but it happens later due to the initialization order having RTEMS_SYSINIT_CPU_COUNTER very early. Update #4312.
Comment 2
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:28:21 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2

4313 - grlib,grspw_router: add function to control SpaceWire run clock divisor

Link https://devel.rtems.org/ticket/4313
Id 4313
Reporter Daniel Hellstrom
Created 7 March 2021 14:37:36
Modified 9 March 2021 13:28:44
Owner Daniel Hellstrom
Type enhancement
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The driver needs to allow the user to set SpaceWire? run clock divisor for an individual port.

Comment 1
  1. Martin Aberg, Sun, 07 Mar 2021 15:57:22 GMT

In 1161e1f/rtems:

leon, grspw_router: added router_port_link_div() Allows user to set SpaceWire? run clock divisor for an individual port. Update #4313.
Comment 2
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:28:44 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2

4314 - grlib,ahbstat: add new register definitions for AHBSTAT version 1

Link https://devel.rtems.org/ticket/4314
Id 4314
Reporter Daniel Hellstrom
Created 7 March 2021 14:40:01
Modified 9 March 2021 13:29:07
Owner Daniel Hellstrom
Type enhancement
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

This is needed for GR740 users.

Comment 1
  1. Martin Aberg, Sun, 07 Mar 2021 15:57:26 GMT

In b0eb9524/rtems:

leon, ahbstat: register definitions for AHBSTAT version 1 Update #4314.
Comment 2
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:29:07 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2

4315 - grlib,l2cache: prevent unused diagnostic access

Link https://devel.rtems.org/ticket/4315
Id 4315
Reporter Daniel Hellstrom
Created 7 March 2021 14:42:54
Modified 9 March 2021 13:29:33
Owner Daniel Hellstrom
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity minor
Keywords  
Cc  
Blocking  
Blocked by  

Description

GR740 L2-cache driver improvement.

Comment 1
  1. Martin Aberg, Sun, 07 Mar 2021 15:57:30 GMT

In 8cfaa0eb/rtems:

leon, l2cache: prevent unused diagnostic access Update #4315.
Comment 2
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:29:33 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2

Minor improvement, no need to add to 5.2 changelog.


4316 - grlib,grspw_pkt: SpaceWire link-state defines corrected

Link https://devel.rtems.org/ticket/4316
Id 4316
Reporter Daniel Hellstrom
Created 7 March 2021 14:45:22
Modified 9 March 2021 13:30:05
Owner Daniel Hellstrom
Type defect
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Numbering of SPW_LS_CONNECTING and SPW_LS_STARTED was swapped.

Comment 1
  1. Daniel Hellstrom, Sun, 07 Mar 2021 15:57:33 GMT

In 29126711/rtems:

grlib,grspw_pkt: correct link state enum numbering Not used by the driver itself, but shuold be correct if used by application. Update #4316.
Comment 2
  1. Daniel Hellstrom, Tue, 09 Mar 2021 13:30:05 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed
  4. milestone: changed from 6.1 to 5.2

4347 - Allow RTEMS_PRIORITY for MrsP semaphores

Link https://devel.rtems.org/ticket/4347
Id 4347
Reporter Sebastian Huber
Created 16 March 2021 13:27:05
Modified 23 June 2021 07:07:55
Owner Sebastian Huber
Type enhancement
Component rtems
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords qualification
Cc  
Blocking  
Blocked by  

Description

In order to improve the compatibility of RTEMS 5.2 with future version of RTEMS which fixed #4346 allow MrsP semaphores to be created with RTEMS_PRIORITY.

Comment 1
  1. Sebastian Huber, Wed, 17 Mar 2021 09:47:01 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 0965b7c8/rtems:

rtems: Require RTEMS_PRIORITY for MrsP semaphores MrsP semaphores are a generalization of the priority ceiling semaphores for SMP configurations. Priority ceiling semaphores are required to use the priority task wait queue discipline. Require this discipline also for MrsP semaphores. Close #4347.
Comment 2
  1. Sebastian Huber, Wed, 17 Mar 2021 09:48:57 GMT

In 3a66586/rtems:

rtems: Allow RTEMS_PRIORITY for MrsP semaphores In order to improve the compatibility of RTEMS 5.2 with future version of RTEMS which fixed #4346 allow MrsP semaphores to be created with RTEMS_PRIORITY. Close #4347.
Comment 3
  1. Sebastian Huber, Wed, 17 Mar 2021 13:05:34 GMT

In 7c43a4b/rtems-docs:

c-user: Update MrsP semaphore documentation Update #4347.
Comment 4
  1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
  2. keywords: qualification added

4357 - rtems_semaphore_set_priority() uses an invalid SMP lock (cloned)

Link https://devel.rtems.org/ticket/4357
Id 4357
Reporter Sebastian Huber
Created 23 March 2021 17:14:20
Modified 9 November 2022 23:24:24
Owner Sebastian Huber
Type defect
Component rtems
Status closed
Resolution wontfix
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Cloned from #4356:

If the priority of a locked priority ceiling mutex is set, the used SMP lock sequence is invalid.

Comment 1
  1. Chris Johns, Wed, 09 Nov 2022 23:24:24 GMT
  2. status: changed from assigned to closed
  3. resolution: set to wontfix

Please use RTEMS 6 for SMP


4359 - Priority discipline is broken for semaphores and message queues in SMP configurations (cloned)

Link https://devel.rtems.org/ticket/4359
Id 4359
Reporter Sebastian Huber
Created 25 March 2021 08:09:28
Modified 9 November 2022 23:25:23
Owner Sebastian Huber
Type defect
Component admin
Status closed
Resolution wontfix
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Cloned from #4358:

The priority queues in clustered scheduling configurations use a per scheduler priority queue rotation to ensure FIFO fairness across schedulers. This mechanism is implemented in the thread queue surrender operation. Unfortunately some semaphore and message queue directives use wrongly the thread queue extract operation.

Comment 1
  1. Chris Johns, Wed, 09 Nov 2022 23:25:23 GMT
  2. status: changed from assigned to closed
  3. resolution: set to wontfix

Please use RTEMS 6 for SMP. Please reopen if this is to be fixed on the RTEMS 5 branch.


4369 - RTEMS5: Add driver for cadence-spi device for xilinx based BSPs (cloned)

Link https://devel.rtems.org/ticket/4369
Id 4369
Reporter Jan Sommer
Created 31 March 2021 07:15:07
Modified 6 April 2021 13:16:22
Owner Jan Sommer
Type enhancement
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Cloned from #4320: Backport to RTEMS5

Implement a spidev compatible driver for using the cadence-spi device of the Zynq devices in standard SPI mode.

Comment 1
  1. Jan Sommer, Wed, 31 Mar 2021 07:15:33 GMT
  2. owner: set to Jan Sommer
  3. status: changed from new to accepted
Comment 2
  1. Jan Sommer, Tue, 06 Apr 2021 13:16:11 GMT

In c86d5136/rtems:

bsps/xilinx_zynq: Add SPI driver for cadence-spi Updates #4369
Comment 3
  1. Jan Sommer, Tue, 06 Apr 2021 13:16:22 GMT
  2. status: changed from accepted to closed
  3. resolution: set to fixed

In 14e74e4/rtems:

bsps/xilinx_zynq: Add cadence SPI driver to build system Closes #4369

4370 - RTEMS5: Add spi driver for AXI SPI ip core from Xilinx (cloned)

Link https://devel.rtems.org/ticket/4370
Id 4370
Reporter Jan Sommer
Created 31 March 2021 08:06:09
Modified 6 April 2021 13:16:42
Owner Jan Sommer
Type enhancement
Component bsps
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Cloned from #4321: --> Backport to RTEMS5

Add a spidev compatible driver for the xilinx axi quad spi ip core for standard SPI mode

Comment 1
  1. Jan Sommer, Wed, 31 Mar 2021 08:06:22 GMT
  2. owner: set to Jan Sommer
  3. status: changed from new to accepted
Comment 2
  1. Jan Sommer, Tue, 06 Apr 2021 13:16:32 GMT

In ce2b276/rtems:

bsps/xilinx_zynq: Add SPI driver for xilinx-axi-spi Updates #4370
Comment 3
  1. Jan Sommer, Tue, 06 Apr 2021 13:16:42 GMT
  2. status: changed from accepted to closed
  3. resolution: set to fixed

In ec26605/rtems:

bsps/xilinx_zynq: Add Xilinx AXI SPI driver to build Closes #4370

4371 - RTEMS5: Shell: Backport commands for spi and i2c

Link https://devel.rtems.org/ticket/4371
Id 4371
Reporter Jan Sommer
Created 31 March 2021 08:27:57
Modified 6 April 2021 13:16:51
Owner Jan Sommer
Type enhancement
Component shell
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Backport the i2c and spi shell commands of Christian Mauderer.

Comment 1
  1. Jan Sommer, Wed, 31 Mar 2021 08:28:09 GMT
  2. owner: set to Jan Sommer
  3. status: changed from new to accepted
Comment 2
  1. Christian Mauderer, Tue, 06 Apr 2021 13:16:51 GMT
  2. status: changed from accepted to closed
  3. resolution: set to fixed

In a274b6f/rtems:

shell: Add i2c and spi commands This adds some commands that are usefull for debugging simple serial interfaces. Even if they are a complete re-implementation, the i2c* commands use a simmilar call like the Linux i2c tools. Closes #4371

4394 - Workspace initialization is broken for arm/imx7 and arm/raspberrypi

Link https://devel.rtems.org/ticket/4394
Id 4394
Reporter Sebastian Huber
Created 29 April 2021 11:38:16
Modified 29 April 2021 11:41:45
Owner Sebastian Huber
Type defect
Component arch/arm
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The ARMV7_CP15_START_WORKSPACE_ENTRY_INDEX has a wrong value. The bug was introduced by the fix for #4185.

Comment 1
  1. Sebastian Huber, Thu, 29 Apr 2021 11:41:45 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In d697769/rtems:

bsps/arm: ARMV7_CP15_START_WORKSPACE_ENTRY_INDEX Change the ARMV7_CP15_START_WORKSPACE_ENTRY_INDEX value to be in line with the workspace entry in ARMV7_CP15_START_DEFAULT_SECTIONS. Close #4394.

4409 - rtems_task_start() does not check that the entry point is not equal to NULL

Link https://devel.rtems.org/ticket/4409
Id 4409
Reporter Sebastian Huber
Created 14 May 2021 07:12:33
Modified 23 June 2021 07:07:55
Owner Sebastian Huber
Type defect
Component admin
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords qualification
Cc  
Blocking  
Blocked by  

Description

Bug was introduced by commit 33829ce155069462ba410d396da431386369ed08 related to #2555.

Comment 1
  1. Sebastian Huber, Fri, 14 May 2021 07:23:24 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 06427c8d/rtems:

rtems: Check entry point in rtems_task_start() Close #4409.
Comment 2
  1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
  2. keywords: qualification added

4429 - clock_nanosleep() may use wrong clock for relative times (cloned)

Link https://devel.rtems.org/ticket/4429
Id 4429
Reporter Sebastian Huber
Created 18 May 2021 18:45:29
Modified 4 May 2022 13:55:19
Owner Sebastian Huber
Type defect
Component posix
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Cloned from #4426:

For relative times, the clock identifier is not used to select the clock and instead always the CLOCK_MONOTONIC is used. A side-effect is that sleep() and nanosleep() use the wrong clock (CLOCK_MONOTONIC instead of CLOCK_REALTIME).

Comment 1
  1. Sebastian Huber, Wed, 04 May 2022 13:55:19 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 5d73509/rtems:

posix: Fix use of clock for relative times Close #4429.

4452 - libbsd/i386: Include header error through bus.h

Link https://devel.rtems.org/ticket/4452
Id 4452
Reporter Jan Sommer
Created 8 June 2021 13:51:48
Modified 9 June 2021 19:02:41
Owner  
Type defect
Component network/libbsd
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Currently compilations of applications fails at rtemsbsd/include/bus.h:

 #ifdef __i386__
#error "your include paths are wrong"
#endif

Proposed solution:
Install the header files for i386, so that the original ones from FreeBSD will be used.

Comment 1
  1. Jan Sommer, Wed, 09 Jun 2021 19:02:17 GMT

Closed with commits:

​https://git.rtems.org/rtems-libbsd/commit/?h=5-freebsd-12&id=9edb1201f67c3c9c77531bae52ab75bfea0e5aad

​https://git.rtems.org/rtems-libbsd/commit/?h=5-freebsd-12&id=5c1b99e4d24530492dcd436ca9718676883ab7f3

Comment 2
  1. Jan Sommer, Wed, 09 Jun 2021 19:02:41 GMT
  2. status: changed from new to closed
  3. resolution: set to fixed

4456 - bsps/i386: TSC calibration inaccurate (cloned)

Link https://devel.rtems.org/ticket/4456
Id 4456
Reporter Jan Sommer
Created 11 June 2021 06:32:36
Modified 21 June 2021 08:15:12
Owner Jan Sommer
Type defect
Component admin
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords i386 clock
Cc  
Blocking  
Blocked by  

Description

Cloned from #4455:

The current implementation of the TSC calibration during startup yields inaccurate results.

There are 2 issues:

1. Rounding error:

The calibrate_tsc function calibrates for 1s by waiting for rtems_clock_get_ticks_per_second() ticks via the PIT.

The PIT has a frequency of 1193182 Hz. For a rtems tick of 1ms this yields 1193. Waiting for 1s means then waiting for 1193000 PIT ticks (instead of the full 1193182).
For a 1 GHz TSC clock this would yield already ~150 kHz less then the correct TSC frequency.

2. Waiting for the first loop at begin of timer period
for (i = rtems_clock_get_ticks_per_second() * pc386_isrs_per_tick;
i != 0; --i ) {
/* We know we've just completed a tick when timer goes from low to high */
then_lsb = then_msb = 0xff;
do { <== First loop does not start at begin of clock period
READ_8254(now_lsb, now_msb);
if ((then_msb < now_msb) ||
((then_msb == now_msb) && (then_lsb < now_lsb)))
break;
then_lsb = now_lsb;
then_msb = now_msb;
} while (1);
}

This can yield deviations of several MHz for the TSC frequency.
For example, for a tested CPU with a TSC frequency of 19167.1 MHz yields a calibration result of 1912.3 MHz.

Proposed solution
  • Just wait 1193182 PIT ticks for 1 s instead of a number of rtems ticks
  • Use the raw timer value instead of waiting for clock ticks.
Comment 1
  1. Jan Sommer, Fri, 11 Jun 2021 06:32:53 GMT
  2. owner: set to Jan Sommer
  3. status: changed from new to accepted
Comment 2
  1. Jan Sommer, Mon, 21 Jun 2021 08:15:12 GMT
  2. status: changed from accepted to closed
  3. resolution: set to fixed

In 4925ab4/rtems:

bsps/i386: Update calibration of TSC to be more accurate Closes #4456

4505 - posix_devctl() should return the errno directly not -1 and set errno

Link https://devel.rtems.org/ticket/4505
Id 4505
Reporter Joel Sherrill
Created 20 August 2021 19:23:54
Modified 20 September 2021 19:08:11
Owner Ryan Long <ryan.long@…>
Type defect
Component posix
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The RTEMS implementation of posix_devctl() from POSIX 1003.26 does not return error codes as required by the standard.

"Upon successful completion, posix_devctl() shall return zero; otherwise an error number shall be returned to indicate the error. The value returned via the dev_info_ptr argument is driver dependent."

It should return the errno value and not -1 and set the errno variable. The current behavior is wrong but understandable because the implementation is a wrapper for close() and ioctl() which do set errno and return -1.

Comment 1
  1. Joel Sherrill, Tue, 24 Aug 2021 18:35:37 GMT
  2. description: modified (diff)
Comment 2
  1. Ryan Long, Mon, 20 Sep 2021 19:08:11 GMT
  2. owner: set to Ryan Long <ryan.long@…>
  3. status: changed from new to closed
  4. resolution: set to fixed

In e9712e78/rtems:

pxcdevctl: Adjust for standard (5 branch) psxdevctl is supposed to return the value in errno. Before, it was returning -1 and setting errno. Changed the tests to reflect these changes. Added code from RRADE's posix_devctl.c. Closes #4505

4512 - Count of postponed jobs is not set to zero for a newly created rate-monotonic period object (cloned)

Link https://devel.rtems.org/ticket/4512
Id 4512
Reporter Sebastian Huber
Created 9 September 2021 13:15:54
Modified 9 September 2021 13:16:23
Owner Sebastian Huber
Type defect
Component rtems
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Cloned from #4511:

rtems_rate_monotonic_get_status() returns an arbitrary number for the count of postponed jobs if it is called for a newly created period object. The count of postponed jobs should be cleared to zero at object creation.

Comment 1
  1. Sebastian Huber, Thu, 09 Sep 2021 13:16:23 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In ff94ddc/rtems:

rtems: Initialize count of postponed jobs The rtems_rate_monotonic_get_status() directive returns an arbitrary number for the count of postponed jobs if it is called for a newly created period object. Set the count of postponed jobs to zero during object creation. Close #4512.

4514 - Support MVME2307 DEC Tulip driver

Link https://devel.rtems.org/ticket/4514
Id 4514
Reporter Chris Johns
Created 18 September 2021 07:46:06
Modified 22 September 2021 04:43:39
Owner Chris Johns
Type task
Component network/libbsd
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Back port the MVME2307 patches from 6-freebsd-12 to support the MVME2307 (motorola_powerpc) NIC. The patches:

  • Add nexus bus support for the ifdc NIC and UKPHY
  • Update the bus space support to support BSP define split PCI address spaces
  • Support PCI legacy support for the PowerPC
Comment 1
  1. Chris Johns, Wed, 22 Sep 2021 04:43:37 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In afb3616/rtems-libbsd:

rtemsbsd/bus: Add PCI support to the nexus bus Add PCI IO region support Add support map buffers to PCI address space Add BSP conditional IO space support. Some PC implementations have PCI IO space mapped differently to memory space and this needs to be reflected in the busspace. Include bsp.h to pick per BSP configuration. Closes #4514
Comment 2
  1. Chris Johns, Wed, 22 Sep 2021 04:43:39 GMT

In 332cc9f/rtems-libbsd:

bsp/motorola_powerpc: Add dc, ukphy and legacy PCI support Add the dc net dev to the BSP Add the ukphy support Add PCI Legacy bus support to the PowerPC Closes #4514

4515 - Make [out/in] le and be calls conditional

Link https://devel.rtems.org/ticket/4515
Id 4515
Reporter Chris Johns
Created 18 September 2021 08:07:01
Modified 9 November 2022 23:26:38
Owner Chris Johns
Type defect
Component arch/powerpc
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

These calls clash with the Linux IO header in LibBSD. Making these conditional here means BSPs build and the imported Linux header is untouched.

Comment 1
  1. Chris Johns, Wed, 09 Nov 2022 23:26:38 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

Fixed ​https://git.rtems.org/rtems/commit/?h=5&id=cfef84a007bac32b6f3852ab3d9367f7cdcf2c6b


4516 - Map LibBSD bus space to the PCI base address for motorola_powerpc BSP

Link https://devel.rtems.org/ticket/4516
Id 4516
Reporter Chris Johns
Created 18 September 2021 08:08:55
Modified 22 September 2021 01:05:17
Owner Chris Johns
Type task
Component arch/powerpc
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

This provides the per BSP support for a split PCI address space in LibBSD for this the MVME2307 BSP

Comment 1
  1. Chris Johns, Wed, 22 Sep 2021 01:05:17 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 99698fb/rtems:

powerpc/motorola_powerpc: Map LibBSD bus space to the PCI base address Closes #4516

4520 - Re-add lost capability for custom stack allocator to allocate IDLE thread stacks

Link https://devel.rtems.org/ticket/4520
Id 4520
Reporter Joel Sherrill
Created 4 October 2021 14:15:46
Modified 12 October 2021 17:48:47
Owner Joel Sherrill
Type defect
Component rtems
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The move to statically allocate the stacks for the IDLE threads resulted in the loss of the capability for a custom stack allocator to be able to allocate the idle threads' stacks.

Comment 1
  1. Joel Sherrill, Mon, 11 Oct 2021 13:41:14 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In c8a10609/rtems:

Add support for IDLE Thread stack allocator Add a stack allocator hook specifically for allocation of IDLE thread stacks. This allows the user to decide if IDLE thread stacks are statically allocated or handled by the same custom allocator mechanism as other thread stacks. Closes #4520.
Comment 2
  1. Joel Sherrill, Tue, 12 Oct 2021 17:48:47 GMT

In 30e5832/rtems-docs:

task-stack-alloc.rst: Add CONFIGURE_TASK_STACK_FROM_ALLOCATOR Updates #4520.

4523 - gdb 9.1 no longer builds on Cygwin (thread local error)

Link https://devel.rtems.org/ticket/4523
Id 4523
Reporter Joel Sherrill
Created 6 October 2021 14:22:54
Modified 13 October 2021 16:36:57
Owner Joel Sherrill <joel@…>
Type defect
Component admin
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The Cygwin link error is:

cp-support.o: in function `gdb_demangle(char const*, int)':
/home/Christian/binutils-gdb/obj/gdb/../../gdb/cp-support.c:1619:(.text+0x6472): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for thread_local_segv_handler'
/home/Christian/binutils-gdb/obj/gdb/../../gdb/cp-support.c:1619:(.text+0x648b): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for thread_local_segv_handler'
collect2: error: ld returned 1 exit status

The issue appears to be that Cygwin changed their base address for executables and there are multiple approaches to fixing this on the Internet. None of these applied cleanly to a vanilla gdb 9.1. I adapted the patch presented at ​https://stackoverflow.com/questions/61984974/failed-to-build-avr-and-arm-gdb-9-1-under-cygwin-relocation-truncated-to-fit

This patch avoids using a thread-local extern variable, which causes link errors on some platforms, notably Cygwin. The poster through this was a better pattern even outside of working around linker bugs because it encapsulates direct access to the variable inside the class, instead of having a global extern variable.

It should be noted that gdb 10.1 builds cleanly on Cygwin but discussions leaned against bumping the gdb on the 5 branch. Hence we end up with a Cygwin specific patch for gdb 9.1 on Cygwin.

Attachments:

1 Joel Sherrill, Wed, 06 Oct 2021 15:53:24 GMT
  attach: set to gdb-9-1-thread-local.diff
 
Comment 1
  1. Joel Sherrill, Wed, 13 Oct 2021 16:36:57 GMT
  2. owner: set to Joel Sherrill <joel@…>
  3. status: changed from new to closed
  4. resolution: set to fixed

In 9be3668/rtems-source-builder:

rtems-gdb-9.1-1.cfg: Add patch for Cygwin The patch is needed to address link failures introduced when Cygwin apparently changed their base address for executables. This is not an issue with gdb 10 and this is a minimalistic approach to addressing this failure on the 5 branch. Closes #4523.

4549 - Timecounter: Add NTP support (cloned)

Link https://devel.rtems.org/ticket/4549
Id 4549
Reporter GabrielMoyano
Created 15 November 2021 11:37:22
Modified 9 November 2022 22:34:48
Owner  
Type enhancement
Component score
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

Cloned from #2348:

The FreeBSD timecounter implementation supports the NTP. This support is currently disabled in RTEMS.

Comment 1
  1. Sebastian Huber, Tue, 30 Nov 2021 14:41:11 GMT

In 5382f61/rtems:

score: Add _Timecounter_Set_NTP_update_second() Allow the installation of an NTP update second handler which may be used by an NTP service. Update #4549.
Comment 2
  1. Joel Sherrill, Fri, 17 Dec 2021 17:02:39 GMT

Is all the work done on this? Can it be closed? What's left?

Comment 3
  1. GabrielMoyano, Mon, 10 Jan 2022 07:47:56 GMT

Replying to Joel Sherrill:

Is all the work done on this? Can it be closed? What's left?

Yes, it can be closed. Sorry for the delay

Comment 4
  1. Chris Johns, Wed, 09 Nov 2022 22:34:48 GMT
  2. status: changed from new to closed
  3. resolution: set to fixed

Closing as instructed.


4567 - Atomic store does not use the order parameter for C++ (cloned)

Link https://devel.rtems.org/ticket/4567
Id 4567
Reporter Sebastian Huber
Created 7 December 2021 11:07:44
Modified 7 December 2021 11:25:53
Owner Sebastian Huber
Type defect
Component score
Status closed
Resolution fixed
Version 4.11
Milestone 5.2
Priority normal
Severity normal
Keywords SMP
Cc  
Blocking  
Blocked by  

Description

Cloned from #4566:

This could result in invalid inline code for the SMP ticket locks if used from C++.

Comment 1
  1. Sebastian Huber, Tue, 07 Dec 2021 11:25:53 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 18bbfc7/rtems:

score: Fix atomic stores for C++ Close #4567.

4649 - tcpdump: Fix dumping to file and reading from file

Link https://devel.rtems.org/ticket/4649
Id 4649
Reporter Sebastian Huber
Created 11 May 2022 06:44:07
Modified 12 May 2022 05:49:57
Owner Sebastian Huber
Type defect
Component network/libbsd
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

When dumping to file, the file needs to be closed at program exit. When reading from file, we do not need the loop monitor. Do not use signals, since they are not cleaned up at program exit.

Comment 1
  1. Sebastian Huber, Wed, 11 May 2022 06:44:56 GMT
  2. version: set to 5
Comment 2
  1. Sebastian Huber, Thu, 12 May 2022 05:49:33 GMT

In 6364f45/rtems-libbsd:

tcpdump01: New test Update #4649.
Comment 3
  1. Sebastian Huber, Thu, 12 May 2022 05:49:36 GMT

In 5c88a52/rtems-libbsd:

Add program destructor support Update #4649.
Comment 4
  1. Sebastian Huber, Thu, 12 May 2022 05:49:40 GMT

In a5bdd7a/rtems-libbsd:

tcpdump: Make loop monitor cooperative This helps a bit if the fgetc() is non-blocking. Update #4649.
Comment 5
  1. Sebastian Huber, Thu, 12 May 2022 05:49:43 GMT

In d5fdfbb/rtems-libbsd:

tcpdump: Use rtems_task_exit() Update #4649.
Comment 6
  1. Sebastian Huber, Thu, 12 May 2022 05:49:47 GMT

In cb01e5b/rtems-libbsd:

tcpdump: Close pcap dumper at program exit Update #4649.
Comment 7
  1. Sebastian Huber, Thu, 12 May 2022 05:49:50 GMT

In 47ec4b8/rtems-libbsd:

tcpdump: No loop monitor if reading from file Update #4649.
Comment 8
  1. Sebastian Huber, Thu, 12 May 2022 05:49:54 GMT

In 45c9bd2/rtems-libbsd:

tcpdump: Ensure loop monitor termination Update #4649.
Comment 9
  1. Sebastian Huber, Thu, 12 May 2022 05:49:57 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In ea80d58/rtems-libbsd:

tcpdump: Do not use signals and chroot Close #4649.

4651 - if_atsam: Fix checksum offload, add multicast and VLAN support

Link https://devel.rtems.org/ticket/4651
Id 4651
Reporter Sebastian Huber
Created 11 May 2022 06:48:30
Modified 1 June 2022 07:51:10
Owner Sebastian Huber
Type defect
Component network/libbsd
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The if_atsam network interface driver has several issues. Do not disable the FCS if the checksum offload is disabled. Make sure the interface capabilities are enabled. Add multicast and VLAN support. Use the interface transmit method instead of the interface start approach. Correct a potential receive starvation error. Fix the interface up/down.

Comment 1
  1. Sebastian Huber, Thu, 12 May 2022 05:39:56 GMT

In a4b878c/rtems-libbsd:

if_atsam: Fix warnings Update #4651.
Comment 2
  1. Sebastian Huber, Thu, 12 May 2022 05:39:58 GMT

In 79e7421/rtems-libbsd:

if_atsam: Enable all capabilities Update #4651.
Comment 3
  1. Sebastian Huber, Thu, 12 May 2022 05:39:59 GMT

In 4780eff/rtems-libbsd:

if_atsam: Do not disable the Ethernet CRC The Ethernet CRC and padding must be always generated by the MAC. Update #4651.
Comment 4
  1. Sebastian Huber, Thu, 12 May 2022 05:40:00 GMT

In 46ec9d7/rtems-libbsd:

if_atsam: Fix interrupt setup The interrupt is enabled by rtems_interrupt_handler_install(). Update #4651.
Comment 5
  1. Sebastian Huber, Thu, 12 May 2022 05:40:02 GMT

In 1fe1bc6/rtems-libbsd:

if_atsam: Fix start/stop of interface Update #4651.
Comment 6
  1. Sebastian Huber, Thu, 12 May 2022 05:40:03 GMT

In 58162da/rtems-libbsd:

if_atsam: Add multicast support Update #4651.
Comment 7
  1. Sebastian Huber, Thu, 12 May 2022 05:40:05 GMT

In 1fee8dd/rtems-libbsd:

if_atsam: Optimize transmit Use the transmit interface handler to avoid a transmit task/interrupt. Use a compile-time constant for the transmit DMA descriptor count to simplify calculations. Update #4651.
Comment 8
  1. Sebastian Huber, Thu, 12 May 2022 05:40:06 GMT

In 204a487/rtems-libbsd:

if_atsam: Optimize receive Do not use the interface mutex in the receive loop. Avoid multiple reads of DMA descriptor words. Use a compile-time constant for the receive DMA descriptor count to simplify calculations. Update #4651.
Comment 9
  1. Sebastian Huber, Thu, 12 May 2022 05:40:07 GMT

In 245ca94/rtems-libbsd:

if_atsam: Support IFCAP_VLAN_HWTAGGING This is required to enable checksum offload for vlan interfaces. Update #4651.
Comment 10
  1. Sebastian Huber, Thu, 12 May 2022 05:40:09 GMT

In 2a174be/rtems-libbsd:

if_atsam: Do not use rtems_bsdnet_newproc() Update #4651.
Comment 11
  1. Sebastian Huber, Thu, 12 May 2022 05:40:10 GMT

In c1b15c7/rtems-libbsd:

if_atsam: Support transmit bpf Update #4651.
Comment 12
  1. Sebastian Huber, Thu, 12 May 2022 05:40:12 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In a661df0/rtems-libbsd:

if_atsam: Fix interface stop Close #4651.
Comment 13
  1. Sebastian Huber, Wed, 01 Jun 2022 07:51:05 GMT

In f05e625/rtems-libbsd:

if_atsam: Allow stats reset via sysctl Update #4651.
Comment 14
  1. Sebastian Huber, Wed, 01 Jun 2022 07:51:06 GMT

In 8e5a933/rtems-libbsd:

if_atsam: Add register sysctls Update #4651.
Comment 15
  1. Sebastian Huber, Wed, 01 Jun 2022 07:51:08 GMT

In c78ec59/rtems-libbsd:

if_atsam: Add tx/rx desc sysctls Update #4651.
Comment 16
  1. Sebastian Huber, Wed, 01 Jun 2022 07:51:09 GMT

In 62d320d/rtems-libbsd:

if_atsam: Shorten sysctl names Update #4651.
Comment 17
  1. Sebastian Huber, Wed, 01 Jun 2022 07:51:10 GMT

In 29f9822/rtems-libbsd:

if_atsam: Recover from receive freezes Under unknown conditions the receive path ended up in a frozen state. In this state, the DMA and driver descriptor head were equal and all receive descriptors had the used bit set. So, the DMA was unable to store received frames. However, the receive daemon was never woken up to refill the receive buffers. It seems that the RXUBR interrupt can be used to recover from this state. Update #4651.

4653 - pfctl: Fix global state initialization

Link https://devel.rtems.org/ticket/4653
Id 4653
Reporter Sebastian Huber
Created 11 May 2022 11:37:02
Modified 11 May 2022 13:21:04
Owner Sebastian Huber
Type defect
Component network/libbsd
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

The last update introduced a static variable in get_query_socket() which was not initialized.

Comment 1
  1. Sebastian Huber, Wed, 11 May 2022 13:21:02 GMT

In d1b5468/rtems-libbsd:

pf02: Fix shell envirionment initialization Update #4653.
Comment 2
  1. Sebastian Huber, Wed, 11 May 2022 13:21:04 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In e00ca96/rtems-libbsd:

pfctl: Fix global state initialization Close #4653.

4655 - sync() whould synchronize all file descriptors

Link https://devel.rtems.org/ticket/4655
Id 4655
Reporter Sebastian Huber
Created 13 May 2022 10:58:34
Modified 17 May 2022 13:24:35
Owner Sebastian Huber
Type defect
Component fs
Status closed
Resolution fixed
Version 4.5
Milestone 5.2
Priority normal
Severity normal
Keywords  
Cc  
Blocking  
Blocked by  

Description

According to POSIX

​https://pubs.opengroup.org/onlinepubs/9699919799/functions/sync.html

we have

The sync() function shall cause all information in memory that updates file systems to be scheduled for writing out to all file systems. 

Currently, the RTEMS sync() implementation synchronizes only the file descriptors associated with a FILE object. This should be changed to call fsync() and fdatasync() for all file descriptors.

Comment 1
  1. Sebastian Huber, Tue, 17 May 2022 13:24:35 GMT
  2. status: changed from assigned to closed
  3. resolution: set to fixed

In 8d54187/rtems:

Synchronize all file descriptors in sync() Synchronize all file descriptors and not just the ones associated with a FILE object. Close #4655.

4676 - incorrect handling of "inactive_per_block" from "Objects_Information" structure

Link https://devel.rtems.org/ticket/4676
Id 4676
Reporter Adrian Varlan
Created 12 July 2022 06:45:56
Modified 21 July 2022 07:17:33
Owner Sebastian Huber
Type defect
Component score
Status closed
Resolution fixed
Version 5
Milestone 5.2
Priority normal
Severity normal
Keywords CONFIGURE_UNLIMITED_OBJECTS inactive_per_block
Cc  
Blocking  
Blocked by  

Description

The inactive_per_block for block 1 is not handled correctly.
For the first object in the second block, the inactive_per_block value is not decremented. As a consequence, the block might be deleted when the second to last object from block 1 is deleted.
This is only valid when the application is configured with "CONFIGURE_UNLIMITED_OBJECTS".

The reason is the following:

in function "_Objects_Activate_unlimited" from "objectimpl.h"

block = _Objects_Get_index( the_object->id ) - OBJECTS_INDEX_MINIMUM;

if ( block > objects_per_block ) {

block /= objects_per_block;

information->inactive_per_block[ block ]--;
information->inactive--;

}

in a block with 8 objects per block, when creating the 9th object, _Objects_Get_index( the_object->id ) returns 9. Therefore, "block" will be 8 (9 - 1).
The next "if" will not be taken (8 > 8 ? No) and the inactive_per_block will not be decremented to 7 and remains at 8.
This means that block 1 is a candidate for "_Objects_Shrink_information" function although object id 9 is still valid.

Steps to reproduce:
-assuming 8 objects per allocation block
-using semaphores as objects

  • create 17 "RTEMS_SIMPLE_BINARY_SEMAPHORE" semaphore objects id's 1 -> 17.
  • delete semaphores 11, 12, 13, 14, 15, 16, 17 (order is important)
  • lock semaphore 9
  • delete semaphore 10 -> at this point, block 1 is freed although semaphore 9 is still active
  • unlock semaphore 9 -> this can lead to errors. In my case due to the free the semaphore object was altered and changed from a "SEMAPHORE_VARIANT_SIMPLE_BINARY" to "SEMAPHORE_VARIANT_MUTEX_INHERIT_PRIORITY" resulting in a return value of "RTEMS_NOT_OWNER_OF_RESOURCE".
  • Simple fix:
    the condition for the "if" should be ">=" instead of ">".

    Comment 1
    1. Sebastian Huber, Tue, 12 Jul 2022 07:33:52 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to accepted

    Thanks for the detailed bug report. Do you would like to add a test case for this? If not, then I can do it.

    I think the bug was introduced by:

    commit 21275b58a5a69c3c838082ffc8a7a3641f32ea9a
    Author: Sebastian Huber 
    Date:   Thu Nov 22 19:14:51 2018 +0100
        score: Static Objects_Information initialization
        Statically allocate the objects information together with the initial
        set of objects either via .  Provide default object
        informations with zero objects via librtemscpu.a.  This greatly
        simplifies the workspace size estimate.  RTEMS applications which do not
        use the unlimited objects option are easier to debug since all objects
        reside now in statically allocated objects of the right types.
        Close #3621.
    diff --git a/cpukit/score/src/objectallocate.c b/cpukit/score/src/objectallocate.c
    index 9213cf8eb7..ad73884a07 100644
    --- a/cpukit/score/src/objectallocate.c
    +++ b/cpukit/score/src/objectallocate.c
    @@ -68,13 +68,18 @@ Objects_Control *_Objects_Allocate_unprotected(
         }
         if ( the_object != NULL ) {
    +      Objects_Maximum objects_per_block;
           Objects_Maximum block;
    +      objects_per_block = information->objects_per_block;
           block = _Objects_Get_index( the_object->id ) - OBJECTS_INDEX_MINIMUM;
    -      block /= information->objects_per_block;
    -      information->inactive_per_block[ block ]--;
    -      information->inactive--;
    +      if ( block > objects_per_block ) {
    +        block /= objects_per_block;
    +
    +        information->inactive_per_block[ block ]--;
    +        information->inactive--;
    +      }
         }
       } 
    Comment 2
    1. Adrian Varlan, Tue, 12 Jul 2022 15:27:33 GMT

    Hello,

    if not too much trouble then I think it's best you add a test case.

    Comment 3
    1. Sebastian Huber, Thu, 21 Jul 2022 07:17:31 GMT

    In fc7584d7/rtems:

    score: Fix _Objects_Active_count() With unlimited objects the object maximum may be larger than the sum of active and inactive objects. Update #4676.
    Comment 4
    1. Sebastian Huber, Thu, 21 Jul 2022 07:17:33 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In b9de5b3b/rtems:

    score: Fix unlimited objects support Commit 21275b58a5a69c3c838082ffc8a7a3641f32ea9a ("score: Static Objects_Information initialization") introduced an off-by-one error in the maintenance of inactive objects. Close #4676.

    4683 - Leaked BSP section flags in Makefile.inc breaks EPICS

    Link https://devel.rtems.org/ticket/4683
    Id 4683
    Reporter Chris Johns
    Created 21 July 2022 05:47:07
    Modified 9 November 2022 22:39:30
    Owner  
    Type defect
    Component build
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    RTEMS 5 added -ffunction-sections -fdata-sections to the target flags for BSPs in an architecture that supports code and data sections.

    Some EPICS code such as the ​NTP have code the linker does not link into the final executable. The data sections means the done variable is not linked into the executable when a function in the module is referenced.

    RTEMS 6 only exports the ABI flags and any internal build flags are not exported.

    EPICS should also review this type of code because it excludes potential optimizations.

    Comment 1
    1. Chris Johns, Thu, 21 Jul 2022 05:52:08 GMT
    2. description: modified (diff)
    Comment 2
    1. Joel Sherrill, Thu, 21 Jul 2022 14:26:42 GMT

    This is not a good code pattern to use if per item sectioning is used. There is no reference to the variable done at all and no reason for it to be included. Why not just call an explicit initialization method?

    Comment 3
    1. Chris Johns, Wed, 09 Nov 2022 22:39:30 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    This topic has been discussed in an EPICS github issue ​#288 and Michael thinks the flags are fine. Further testing has shown no real issue. I will set this ticket to invalid and close it. It can be reopened if it is a problem.


    4687 - Documentation List for Releases Completely Missing 5.x

    Link https://devel.rtems.org/ticket/4687
    Id 4687
    Reporter Joel Sherrill
    Created 27 July 2022 18:27:48
    Modified 9 November 2022 23:29:04
    Owner Chris Johns
    Type defect
    Component tool/website
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    See ​https://docs.rtems.org/releases.html and fix it. :)

    Comment 1
    1. Chris Johns, Wed, 09 Nov 2022 23:29:04 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    The website now handles the 5.1 release correctly.


    4704 - Fix invalid RSB source URLs

    Link https://devel.rtems.org/ticket/4704
    Id 4704
    Reporter Chris Johns
    Created 17 August 2022 06:12:26
    Modified 6 December 2022 22:45:21
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Some packages now have invalid source URLs

    Comment 1
    1. Chris Johns, Tue, 06 Dec 2022 22:45:21 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    The release fetching of sources is now clean.


    4709 - Installed header break C++

    Link https://devel.rtems.org/ticket/4709
    Id 4709
    Reporter Chris Johns
    Created 26 August 2022 01:38:01
    Modified 29 August 2022 03:23:10
    Owner Chris Johns
    Type defect
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Some headers generate C++ errors and so cannot be included.

    Comment 1
    1. Chris Johns, Mon, 29 Aug 2022 03:23:10 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In c5b7942/rtems:

    cpukit/include: Fix including in C++ Closes #4709

    4711 - RSB does not expand dir type macros correctly (cloned)

    Link https://devel.rtems.org/ticket/4711
    Id 4711
    Reporter Chris Johns
    Created 28 August 2022 22:34:28
    Modified 9 November 2022 23:32:16
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Cloned from #4710:

    The expansion of the dir type macros is not done correctly. Macro replacement only appends the file part to the last element of a path list. For example:

     %{mydir}/abc.cfg 

    with a path of:

     %define mydir x:y:z 

    results in:

     x:y:z/abc.cfg 

    The config load code handles this but it is wrong. The expansion of dir type macro variables should handle path separators (:) so you get:

     x/abc.cfg:y/abc.cfg:z.abc.cfg 

    This has not been a problem in the RSB because the _configdir has only had two elements and the last one only ever had subdirectories.

    Comment 1
    1. Chris Johns, Wed, 09 Nov 2022 23:32:16 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Fixed with backports from main for deployment.


    4715 - RSB get sources misses a number of files

    Link https://devel.rtems.org/ticket/4715
    Id 4715
    Reporter Chris Johns
    Created 8 September 2022 03:40:07
    Modified 6 December 2022 22:46:37
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Back port the changes from the development branch. The get sources tool is used during the release to collect the sources so they are hosted on ​https://ftp.rtems.org

    The changes exposes a number of configuration file issues on the 5 branch.

    Comment 1
    1. Chris Johns, Mon, 19 Sep 2022 21:24:53 GMT

    In 3138ff5/rtems-source-builder:

    sb/getsources: Fix getting sources Back ported from the development branch Updates #4715
    Comment 2
    1. Chris Johns, Mon, 19 Sep 2022 21:24:56 GMT

    In db3d470/rtems-source-builder:

    sb/getsources: Fixes to configurations Updates #4715
    Comment 3
    1. Chris Johns, Wed, 09 Nov 2022 23:32:33 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    Comment 4
    1. Chris Johns, Fri, 11 Nov 2022 02:57:37 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    More missed files.

    Comment 5
    1. Chris Johns, Mon, 14 Nov 2022 20:58:24 GMT

    In 5992bc9/rtems-source-builder:

    bare/gcc: Remove gcc-4.8.2 because newlib references the unsupported CVS Updates #4715
    Comment 6
    1. Chris Johns, Mon, 14 Nov 2022 22:36:16 GMT

    In b57948f/rtems-source-builder:

    rtems: Update source and patch URLs to valid locations Updates #4715
    Comment 7
    1. Chris Johns, Tue, 15 Nov 2022 21:42:36 GMT

    In 3ec6441/rtems-source-builder:

    rtems: Update source and patch URLs to valid locations Updates #4715
    Comment 8
    1. Chris Johns, Tue, 15 Nov 2022 23:10:26 GMT

    In 1116c5f/rtems-source-builder:

    rtems: Add back gcc-4.6 build configuration Updates #4715
    Comment 9
    1. Chris Johns, Tue, 06 Dec 2022 22:46:37 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    The release now fetches all sources.


    4716 - Backport RSB fixes from Development

    Link https://devel.rtems.org/ticket/4716
    Id 4716
    Reporter Chris Johns
    Created 8 September 2022 05:31:58
    Modified 9 November 2022 23:32:51
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Backport RSB fixes from the development branch.

    Comment 1
    1. Chris Johns, Mon, 19 Sep 2022 21:24:54 GMT

    In 6116d9c/rtems-source-builder:

    sb: Back port fixes from the development branch Updates #4716
    Comment 2
    1. Chris Johns, Mon, 19 Sep 2022 21:24:58 GMT

    In e85e2a7/rtems-source-builder:

    sb/setbuilder: Support line continuation Updates #4716
    Comment 3
    1. Chris Johns, Mon, 19 Sep 2022 21:24:59 GMT

    In 0253d81/rtems-source-builder:

    sb/config: Correctly handle multiple config paths Add rtems/config to the config directories searched to better support deployment Correctly expand the configdir and path searchs Updates #4716
    Comment 4
    1. Chris Johns, Mon, 19 Sep 2022 21:25:01 GMT

    In 828feec/rtems-source-builder:

    sb/setbuilder: Correctly create build set tar files Make a single tarfile for all buildsets built Use the staging tree as the tarfile source Use python's tarfile module Create a config.file object without loading a .cfg file Updates #4716
    Comment 5
    1. Chris Johns, Mon, 19 Sep 2022 21:25:02 GMT

    In 25972d9/rtems-source-builder:

    sb/setbuilder: Do not install if --no-install option is used This is a bug introduced in the recent bset tar file changes Updates #4716
    Comment 6
    1. Chris Johns, Mon, 19 Sep 2022 21:25:05 GMT

    In 6afc04b/rtems-source-builder:

    sb/setbuilder: Install the build when stagging or configured to install Updates #4716
    Comment 7
    1. Chris Johns, Wed, 09 Nov 2022 23:32:51 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    4717 - Add RSB Deployment support

    Link https://devel.rtems.org/ticket/4717
    Id 4717
    Reporter Chris Johns
    Created 14 September 2022 07:09:32
    Modified 9 November 2022 23:33:09
    Owner Chris Johns
    Type enhancement
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Provide deployment support for RTEMS 5.

    The support will be a single architecture with multiple BSPs for that architecture.

    This change does not effect any existing functionality.

    Comment 1
    1. Chris Johns, Mon, 19 Sep 2022 21:25:04 GMT

    In 16d4f2c/rtems-source-builder:

    rtems/kernel: Support deployment standard buildset configs Check and optionally support arch/bsp format 'with_rtems_bsp' defines Updates #4717
    Comment 2
    1. Chris Johns, Fri, 30 Sep 2022 20:19:04 GMT

    In 369b60a/rtems-source-builder:

    rtems/bsps: Optionally support arch/bsp if used Updates #4717
    Comment 3
    1. Chris Johns, Wed, 09 Nov 2022 23:33:09 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    4725 - Git commit message format instrunctions (cloned)

    Link https://devel.rtems.org/ticket/4725
    Id 4725
    Reporter Chris Johns
    Created 26 September 2022 01:50:47
    Modified 14 December 2022 23:25:58
    Owner Joel Sherrill
    Type task
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The Eng docs ​Creating A Patch references the Wiki. The content should be in the manual.

    Note lots of git related bits are in the Eng manual and still on the Wiki so which is correct?

    Comment 1
    1. Chris Johns, Tue, 15 Nov 2022 10:29:58 GMT

    Why is this on the 5 branch?

    Comment 2
    1. Joel Sherrill, Wed, 14 Dec 2022 23:25:58 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d144cf0/rtems-docs:

    (The changeset message doesn't reference this ticket)


    4727 - RSB decode exception stops build

    Link https://devel.rtems.org/ticket/4727
    Id 4727
    Reporter Chris Johns
    Created 26 September 2022 05:39:18
    Modified 9 November 2022 23:48:42
    Owner Chris Johns
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Building in a Rocky VM on FB 12 with 5 I got:

    Traceback (most recent call last):
    File "/usr/lib64/python3.9/threading.py", line 973, in _bootstrap_inner
    self.run()
    File "/usr/lib64/python3.9/threading.py", line 910, in run
    self._target(*self._args, **self._kwargs)
    File "/opt/work/chris/rtems/rsb/rtems-source-builder.git/source-builder/sb/execute.py", line 204, in _readthread
    data = data.decode(sys.stdout.encoding)
    UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe2 in position 4095: unexpected end of data

    If the data is corrupted or broken things stop. Fix to attempt to keep going.

    Comment 1
    1. Chris Johns, Mon, 26 Sep 2022 05:39:53 GMT
    2. summary: changed from RSB decode exception stops build (cloned) to RSB decode exception stops build
    Comment 2
    1. Chris Johns, Wed, 09 Nov 2022 23:48:42 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Fixed ​https://git.rtems.org/rtems-source-builder/commit/?h=5&id=ddfcc320ab740cd6ac30d70aaff7987dda25ee7f


    4731 - rtems-source-builder doesn't generate tar archives for all packages any more

    Link https://devel.rtems.org/ticket/4731
    Id 4731
    Reporter Christian Mauderer
    Created 29 September 2022 08:12:46
    Modified 30 September 2022 20:19:03
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Cloned from #4730:

    Like discussed in the following mailing list thread, the rtems-source-builder doesn't generate tar archives for all packages anymore:

    ​https://lists.rtems.org/pipermail/devel/2022-September/073369.html

    All RTEMS tools build sets 6/rtems-* work fine except for 6/rtems-microblaze. devel/qemu and devel/dtc do not generate a tar archive. If the patch

    ​https://git.rtems.org/rtems-source-builder/commit/?id=6205068c5a429e9ee1b471f4c8a3a119bb6757b2

    is reverted, the tar files are generated just like before.

    Comment 1
    1. Chris Johns, Thu, 29 Sep 2022 23:13:11 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 6f1e914/rtems-source-builder:

    sb/set-builder: Fix staging and tar file generation with a single config build Closes #4731
    Comment 2
    1. Chris Johns, Fri, 30 Sep 2022 02:24:57 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    This has broken staging for multiple packages in a top level buildset.

    Comment 3
    1. Chris Johns, Fri, 30 Sep 2022 20:19:03 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    In d592ee8/rtems-source-builder:

    sb/set-bulder: Fix installing builds when a single buildset Always stage a build Install if installable and outter most buildset instance Closes #4731

    4733 - Set top in RSB version.py

    Link https://devel.rtems.org/ticket/4733
    Id 4733
    Reporter Chris Johns
    Created 29 September 2022 08:15:41
    Modified 29 September 2022 23:13:12
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Cloned from #4732:

    Setting the top lets the code be used in deployment to get the version of the RSB being used. An RSB version lets a user track the exact tools being built and version numbers reported by the tools can match the packaged build, eg an rpm name and version info.

    Comment 1
    1. Chris Johns, Thu, 29 Sep 2022 23:13:12 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 08ca387/rtems-source-builder:

    sb/version: Set top from external package Closes #4733

    4734 - RSB decode exception stops build

    Link https://devel.rtems.org/ticket/4734
    Id 4734
    Reporter Chris Johns
    Created 29 September 2022 23:11:12
    Modified 30 September 2022 20:19:01
    Owner Chris Johns
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Cloned from #4726:

    Building in a Rocky VM on FB 12 with 5 I got:

    Traceback (most recent call last):
    File "/usr/lib64/python3.9/threading.py", line 973, in _bootstrap_inner
    self.run()
    File "/usr/lib64/python3.9/threading.py", line 910, in run
    self._target(*self._args, **self._kwargs)
    File "/opt/work/chris/rtems/rsb/rtems-source-builder.git/source-builder/sb/execute.py", line 204, in _readthread
    data = data.decode(sys.stdout.encoding)
    UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe2 in position 4095: unexpected end of data

    If the data is corrupted or broken things stop. Fix to attempt to keep going.

    This issue also effect rtems-tools.

    Comment 1
    1. Chris Johns, Thu, 29 Sep 2022 23:13:14 GMT

    In ddfcc32/rtems-source-builder:

    sb/execute: Use a decoder that maintains state aross blocks Update #4734
    Comment 2
    1. Chris Johns, Fri, 30 Sep 2022 20:19:01 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In af0f612/rtems-source-builder:

    sb/execute: Fix incremental decoder with --dry-run Closes #4734

    4752 - RTEMS docs do not build with a recent sphinx

    Link https://devel.rtems.org/ticket/4752
    Id 4752
    Reporter Chris Johns
    Created 10 November 2022 04:00:02
    Modified 10 November 2022 04:28:51
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The build does not configure:

    $ ./waf distclean configure --prefix=/opt/src/rtems/test --pdf --singlehtml
    'distclean' finished successfully (0.000s)
    Setting top to : /opt/work/chris/rtems/docs/rtems-docs.git
    Setting out to : /opt/work/chris/rtems/docs/rtems-docs.git/build
    Checking for program 'git' : /usr/local/bin/git
    Checking for program 'sphinx-build' : /opt/work/chris/rtems/releasing/rng/bin/sphinx-build
    Checking for program 'aspell' : /usr/local/bin/aspell
    Checking if Sphinx is at least 1.3 : yes (5.3)
    Checking Sphinx Options : none
    Checking Sphinx Nit-Pick mode : no
    Checking for 'sphinx.ext.autodoc' : found
    Checking for 'sphinx.ext.coverage' : found
    Checking for 'sphinx.ext.doctest' : found
    Checking for 'sphinx.ext.graphviz' : found
    Checking for 'sphinx.ext.intersphinx' : found
    Checking for 'sphinx.ext.mathjax' : found
    Checking for 'sphinxcontrib.bibtex' : not found (see README.txt)
    The configuration failed
    (complete log in /opt/work/chris/rtems/docs/rtems-docs.git/build/config.log)
    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 04:28:51 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 07f151f/rtems-docs:

    waf: Backport from main build fixes Closes #4752

    4754 - Set RSB GDB source path to https

    Link https://devel.rtems.org/ticket/4754
    Id 4754
    Reporter Chris Johns
    Created 10 November 2022 20:43:01
    Modified 14 November 2022 20:58:22
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Backport ​https://git.rtems.org/rtems-source-builder/commit/?id=949cf500b4f4ab560a77c2ac60cd9ac0f47aa852

    Comment 1
    1. Sebastian Huber, Mon, 14 Nov 2022 20:58:22 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 2eda12e/rtems-source-builder:

    gdb: Use https for downloads Close #4754

    4755 - Docs build system does not build singlehtml

    Link https://devel.rtems.org/ticket/4755
    Id 4755
    Reporter Chris Johns
    Created 10 November 2022 22:04:50
    Modified 10 November 2022 22:14:54
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The configure logic does not handle the inliner detection correctly.

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 22:14:54 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 031cb12/rtems-docs:

    waf: Handle the enable options for singlehtml and ditaa/puml Close #4755

    4757 - RSB freetype 2.4.10 source not hosted any longer

    Link https://devel.rtems.org/ticket/4757
    Id 4757
    Reporter Chris Johns
    Created 11 November 2022 02:34:00
    Modified 15 November 2022 10:31:23
    Owner  
    Type defect
    Component release
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The source is not present any longer. I think the simplest solution maybe using the source in the 5.1 release and pointing the RSB 5 freetype URL to that file.

    Any updates would be a change in the code and functionality.

    Comment 1
    1. Chris Johns, Tue, 15 Nov 2022 10:31:23 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    4758 - Net-Snmp referenced patch missing

    Link https://devel.rtems.org/ticket/4758
    Id 4758
    Reporter Chris Johns
    Created 13 November 2022 20:59:29
    Modified 14 November 2022 20:58:25
    Owner Chris Johns
    Type defect
    Component network/libbsd
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The Net-SNMP configuration references a patch that is missing. I cannot find it.

    Update to 5.9.3 and for the libbsd stack.

    Attachments:

    1 Chris Johns, Sun, 13 Nov 2022 22:49:57 GMT
      attach: set to rtems-net-snmp-5.9.3-20221113.patch
     
    Comment 1
    1. Chris Johns, Mon, 14 Nov 2022 20:58:25 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In c7e85e3/rtems-source-builder:

    rtems/net-snmp: Update to 5.9.3 with the RTEMS patch The 5.7.2.1 patch referenced in the configuration cannot be located so update the version to the latest. Checked with Zynq A9 qemu and libbsd. Closes #4758

    4761 - RSB fatal error on missing hash checksums (cloned)

    Link https://devel.rtems.org/ticket/4761
    Id 4761
    Reporter Chris Johns
    Created 15 November 2022 02:25:36
    Modified 15 November 2022 21:42:34
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.2
    Priority high
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Cloned from #4760:

    The time has come to raise a fatal error if a hash is missing rather than a warning. This will stop missing checksums being present when releasing.

    It also makes it simpler to test releases for no missing checksums.

    Comment 1
    1. Chris Johns, Tue, 15 Nov 2022 10:33:25 GMT
    2. milestone: changed from 5.3 to 5.2
    Comment 2
    1. Chris Johns, Tue, 15 Nov 2022 21:42:34 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 0a7ecef/rtems-source-builder:

    sb/downloads: Raise errors on no hash present Close #4761


    RTEMS Release 5.1

    RTEMS 5.1 Release Notes

    RTEMS Improvements

    In this section, we discuss public API level changes as well as improvements to the implementation of those API routines.

    Public API changes usually fall into one of the following categories:

    • Addition of new methods

    • Modifications to prototypes

    • Deletion of obsoleted methods

    Implementation improvements usually fall into one of the following categories:

    • Algorithm improvements in execution time or memory usage

    • Critical section reduction

    API Changes

    • The header file <rtems.h> no longer includes <limits.h> and <string.h>.

    • Most services use now statically allocated resources and no longer need accounting in the application configuration.

    • The work area initialization (RTEMS Work Space and C Program Heap) changed. BSPs must provide now a _Memory_Get() function.

    • POSIX timers and signals are now the only POSIX resources which are enabled by the POSIX API.

    API Additions

    • Support for recording of high-frequency events in particular on SMP systems

    • Termios supports now generation of signals.

    • New fatal sources:

      • RTEMS_FATAL_SOURCE_EXCEPTION

      • RTEMS_FATAL_SOURCE_PANIC

      • RTEMS_FATAL_SOURCE_SMP

      • RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE

      • RTEMS_FATAL_SOURCE_HEAP

    • New chain API function: rtems_chain_get_first_unprotected()

    • Add user defined thread names: pthread_setname_np() and pthread_getname_np()

    • Support for xz compression/decompression

    • Added rtems_scheduler_ident_by_processor()

    • Added rtems_scheduler_ident_by_processor_set()

    • Added RTEMS_PREDICT_TRUE() and RTEMS_PREDICT_FALSE() for static branch prediction hints

    • Added rtems_malloc() and rtems_calloc()

    • Added rtems_scheduler_get_maximum_priority()

    • Added rtems_scheduler_get_processor()

    • Added rtems_scheduler_get_processor_maximum()

    API Implementation Improvements

    • Priority inheritance is now transitive.

    • POSIX key destructors are now called during thread restart.

    • More robust thread dispatching on SMP and ARM Cortex-M

    API Deprecations

    • rtems_iterate_over_all_threads(). Use rtems_task_iterate() instead.

    • rtems_get_current_processor(). Use rtems_scheduler_get_processor() instead.

    • rtems_get_processor_count(). Use rtems_scheduler_get_processor_maximum() instead.

    • boolean is deprecated. Use bool instead.

    • single_precision is deprecated. Use float instead.

    • double_precision is deprecated. Use double instead.

    • proc_ptr is deprecated. Use a proper function pointer type.

    • rtems_context

    • rtems_context_fp

    • rtems_extension

    • rtems_io_lookup_name() is deprecated. Use stat() instead.

    • region_information_block

    • rtems_thread_cpu_usage_t is deprecated. Use struct timespec instead.

    • rtems_rate_monotonic_period_time_t is deprecated. Use struct timespec instead.

    • _Copyright_Notice is deprecated. Use rtems_get_copyright_notice() instead.

    • _RTEMS_version is deprecated. Use rtems_get_version_string() instead.

    • RTEMS_MAXIMUM_NAME_LENGTH is deprecated. Use sizeof(rtems_name) instead.

    • RTEMS_COMPILER_NO_RETURN_ATTRIBUTE is deprecated. Use RTEMS_NO_RETURN instead.

    • RTEMS_COMPILER_PURE_ATTRIBUTE is deprecated. Use RTEMS_PURE instead.

    • RTEMS_COMPILER_DEPRECATED_ATTRIBUTE is deprecated. Use RTEMS_DEPRECATED instead.

    • RTEMS_COMPILER_UNUSED_ATTRIBUTE is deprecated. Use RTEMS_UNUSED instead.

    • RTEMS_COMPILER_PACKED_ATTRIBUTE is deprecated. Use RTEMS_PACKED instead.

    • Including <rtems/system.h> is deprecated. This header file will be removed in RTEMS 6.

    API Removals

    • rtems_clock_get()

    • API defined by <rtems/debug.h>

    • Task notepads

    • Task variables

    SMP Support Improvements

    • Reimplemenation of the Multiprocessor Resource Sharing Protocol (MrsP) to address performance issues.

    • Implementation of the O(m) Independence-Preserving Protocol (OMIP).

    • Support for thread pinning (enables support for Epoch Based Reclamation; used by libbsd)

    • The default SMP scheduler supports now EDF scheduling, one-to-one and one-to-all thread to processor affinities, and thread pinning.

    • Timers (watchdogs) use now per-processor data structures.

    • Improved POSIX key to value look up.

    • The Ada runtime supports now SMP configurations.

    Configuration Changes

    • All configuration options are now documented.

    • Most resources are now statically allocated and no longer use the workspace.

    • New configuration options:

      • CONFIGURE_MAXIMUM_THREAD_NAME_SIZE

      • CONFIGURE_MINIMUM_POSIX_THREAD_STACK_SIZE

      • CONFIGURE_DIRTY_MEMORY

      • CONFIGURE_RECORD_EXTENSIONS_ENABLED

      • CONFIGURE_RECORD_FATAL_DUMP_BASE64

      • CONFIGURE_RECORD_FATAL_DUMP_BASE64_ZLIB

      • CONFIGURE_RECORD_PER_PROCESSOR_ITEMS

      • CONFIGURE_VERBOSE_SYSTEM_INITIALIZATION

      • CONFIGURE_IMFS_ENABLE_MKFIFO

      • CONFIGURE_IMFS_DISABLE_MKNOD_FILE

    • Renamed configuration options:

      • CONFIGURE_SMP_MAXIMUM_PROCESSORS to CONFIGURE_MAXIMUM_PROCESSORS

      • CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS to CONFIGURE_MAXIMUM_FILE_DESCRIPTORS

    • Removed configuration options:

      • CONFIGURE_SMP_APPLICATION

      • CONFIGURE_HAS_OWN_CONFIGURATION_TABLE

      • CONFIGURE_HAS_OWN_BDBUF_TABLE

      • CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE

      • CONFIGURE_HAS_OWN_FILESYSTEM_TABLE

      • CONFIGURE_HAS_OWN_INIT_TABLE

      • CONFIGURE_HAS_OWN_MOUNT_TABLE

      • CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE

      • CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE

      • CONFIGURE_DISABLE_SMP_CONFIGURATION

      • CONFIGURE_MAXIMUM_DEVICES

    • The helper macro for the clustered scheduler configuration RTEMS_SCHEDULER_EDF_SMP() has now only one parameter.

    RTEMS Shell Improvements

    The following improvements were made to the RTEMS Shell:

    General

    Architectures

    Removed obsolete architectures:

    Obsoleted architectures:

    BSPs and Device Drivers

    Newlib Changes

    Ecosystem

    RTEMS 5.1 Ticket Overview

    Total Closed In_progress New Assigned Percentage
    844 844 0 0 0 100%


    RTEMS 5.1 Ticket Summary

    ID Status Summary
    1247 closed RTEMS does not implement locks needed by multithreaded newlib
    1394 closed scandir() fails due to MAXNAMELEN is incorrect
    1662 closed termios.c: semaphore not deleted, consequently resulting in failure of rtems_termios_open
    1747 closed Heap extend allows discontinuous memory regions.
    1971 closed Memory leak in tmpfile()
    2132 closed <rtems/score/basedefs.h> superfluously includes <limits.h>
    2133 closed <rtems/score/basedefs.h> superfluously includes <string.h>
    2135 closed times() and _times() are subject to integer overflows
    2173 closed Potential integer overflow problem in EDF scheduler
    2176 closed fishy behavior in termios tx task mode
    2198 closed Automate doxygen build
    2207 closed RTEMS tar does not overwrite.
    2213 closed Decreased performance for whetstone benchmark using GCC >=4.5
    2261 closed Add coverage report generation support to rtems-tools
    2266 closed Move bsp_pretasking_hook() into files named bsppretaskinghook.c
    2284 closed h8300 gets error linking dl0* tests
    2289 closed rtems_ada_self is broken on SMP
    2305 closed sp07 needs to be split into an user extensions and a notepad test
    2306 closed powerpc/mvme5500/vectors/exceptionhandler.c uses task variables
    2308 closed Change uniprocessor INIT task mode to preempt.
    2325 closed Broken console driver infrastructure for SPARC
    2344 closed Second argument of ualarm() is ignored
    2350 closed One watchdog ticks header per scheduler instance
    2354 closed Replace red-black tree implementation, change API
    2355 closed SPARC: Several shared drivers are not SMP ready
    2363 closed SPARC: Silent FP context corruption possible
    2366 closed Create a Public API for the Atomic Operations
    2367 closed Documentation of User Extensions needs more information
    2377 closed rtems_waf: Tools without a version are not supported
    2385 closed Warning from commit "bsps/arm: Do not use ARM_ARCH_7A"
    2407 closed Enable function and data sections
    2408 closed Linker set based initialization
    2412 closed Improved priority inheritance implementation
    2420 closed RSB %source file fails
    2423 closed rtems_iterate_over_all_threads lacks user callback private pointer pass through
    2428 closed Add 4.12 Tool Target Configurations to RSB
    2441 closed lpc1768 variants fail to build with error in gpio.c
    2442 closed Remove avrtest BSP
    2443 closed Remove AVR Architectural Port
    2444 closed Remove m68k/mvme136 BSP
    2445 closed Remove m68k/sim68000 BSP
    2446 closed Remove M32R Architectural Port
    2447 closed Remove m32r/m32rsim
    2448 closed Remove mips/mongoose BSP
    2449 closed Remove arm/gba BSP
    2450 closed Remove arm/nds
    2451 closed Remove arm/gp32 BSP
    2452 closed Remove H8300 Architectual Port
    2453 closed Remove h8300/h8sim BSP
    2454 closed Warning in threadqops.c
    2455 closed Warning in spsimplesched02
    2457 closed Remove powerpc/ep1a BSP
    2458 closed Remove powerpc/score603e BSP
    2459 closed Add rtems_chain_get_first_unprotected() to chain API
    2464 closed RSB: Tool patches use the RTEMS version
    2468 closed Add Thread Local Storage (TLS) support on x86
    2477 closed Remove <rtems/debug.h>
    2487 closed Should https://devel.rtems.org/wiki/TBR/Delete/SpecBuilder be Deleted?
    2488 closed Vagrant Scripts
    2490 closed RSB: Use SHA512 instead of MD5
    2493 closed Remove notepads
    2494 closed Remove task variables
    2503 closed mvme5500 BSP: Exception Handler uses deprecated Notepads.
    2509 closed Should "https://devel.rtems.org/wiki/TBR/Delete/BSP_Template" be replaced?
    2513 closed Remove m68k/idp BSP
    2514 closed Make POSIX API mandatory (except signals and the sporadic server)
    2515 closed i386 score/libcpu API Layering Violation
    2527 closed Move pc386/tools/bin2boot to rtems-tools
    2529 closed BSP for the Atmel SAM V71/V70/E70/S70 chip platform
    2536 closed RSB allows use of insecure hash algorithms like MD5 and SHA1
    2537 closed Use Newlib exec*() variants and remove RTEMS versions
    2542 closed Review cxx_iostream size change per function-section changes
    2543 closed Obsolete gen68302 BSP
    2544 closed Osolete m68k/ods68302
    2545 closed Obsolete mbx8xx BSP
    2546 closed Obsolete idp BSP
    2553 closed [mvme3100] boot_card() broken by 37030e38
    2554 closed New watchdog handler implementation
    2555 closed Eliminate the Giant lock
    2556 closed Implement the O(m) Independence-Preserving Protocol (OMIP)
    2557 closed Add word splitting to print output
    2559 closed Delete the EXTERN pattern
    2560 closed smdk2410 is broken due to gp32 removal
    2562 closed RSB Docs Quick Start version number
    2576 closed arm/lpc176x: linker script update (add KEEP() sections)
    2606 closed alarm() uses seconds watchdog and thus is affected by clock changes
    2608 closed POSIX Condition Variables Clock Attribute Support
    2617 closed rtems_heap_allocate_aligned_with_boundary() body and prototype inconsistent
    2624 closed Fix the year 2038 problem
    2625 closed Use one lookup tree per-thread for the POSIX keys
    2626 closed Unify thread cancel/join and delete
    2627 closed Fix CPU time used for threads on SMP
    2628 closed Avoid home-grown condition variable implementation in the Classic Regions
    2631 closed Use an ISR lock to protect the state of Classic Rate Monotonic objects
    2632 closed rtems-tester failure
    2633 closed waf build failed for rtems-libbsd
    2634 closed New warning in pc386 VESA driver
    2638 closed pc386: ld -r issue with per function sections
    2641 closed configure: enable-rtemsbsp doesn't warn if bsp does not exist
    2644 closed sis does not run on gdb 7.11 but does on gdb 7.9
    2649 closed RSB remove 4.11, 4.10 and 4.9 from the master branch.
    2663 closed pc386 BSP has complex dependencies
    2664 closed spclock_err02
    2669 closed Update OpenRISC toolchain in 4.12
    2672 closed After latest patches with Objects_Get_by_name rtems-master not compiling without --enable-posix
    2674 closed CORE spinlock implementation is next to be useless
    2676 closed Obsolete clock_get() directive
    2680 closed Add pthread_setconcurrency() and pthread_getconcurrency()
    2683 closed Configuration table's smp_enabled conditional on RTEMS_SMP
    2684 closed rtems/c/src/lib/libbsp/sparc/leon3/clock/ckinit.c:122: duplicate if
    2685 closed c/src/lib/libbsp/arm/atsam/network/if_atsam.c:409: possible bad if statement
    2689 closed POSIX key destructors must be called during thread restart
    2692 closed User extensions execution order must be clarified
    2693 closed Update doc to reflect obsoleting rtems_clock_get()
    2694 closed linking issue for htonl, etc when using -std=c99
    2695 closed Add libatomic for RTEMS
    2696 closed Unpredictable errno value returned by sem_wait() in case of semaphore deletion
    2698 closed GCC 6.1 is broken for microblaze
    2700 closed cpukit/libfs/src/nfsclient/src/rpcio.c:524]: (style) Suspicious condition
    2701 closed Rename asm file with .S(upper case) ext. name
    2702 closed Remove descriptor objects for POSIX message queues
    2706 closed Buffer allocation of capture engine is broken on SMP configurations
    2707 closed Unsafe use of current processor index in capture engine
    2714 closed A pthread_detach() does not lead to a resource reclamation
    2718 closed Blocking _CORE_message_queue_Submit() may lead to unpredictable results
    2722 closed SEM_VALUE_MAX is unusually small on RTEMS
    2723 closed CPUINFO command to report per-processor information
    2725 closed Classic binary semaphores without a locking protocol can be released by everyone
    2726 closed grascs.c: Questionable use of binary semaphore
    2727 closed FAT file systems use wrong semaphore for mutual exclusion
    2728 closed Pipes use wrong semaphore for mutual exclusion
    2729 closed TFTP client uses wrong semaphore for mutual exclusion
    2732 closed Add clock_nanosleep()
    2734 closed pthread_setschedprio() is missing
    2735 closed pthread_setschedparam() sets the priority not according to POSIX
    2736 closed pthread_getschedparam() returns wrong priority values
    2737 closed Add CLOCK_DRIVER_USE_ONLY_BOOT_PROCESSOR
    2740 closed Suboptimal type for Timestamp_Control
    2741 closed New warning from printf plugin changes
    2742 closed New warning in SHM driver
    2745 closed Use clock from pthread_condattr in pthread_cond_timedwait
    2748 closed Move RTEMS-specific socket wake-up to RTEMS-specific <rtems/rtems_bsdnet.h>
    2749 closed rtems_task_set_scheduler() has insufficient parameters
    2750 closed Compile Error When Multiprocessing Enabled
    2751 closed Thread dispatch via interrupt is broken at least on ARM and PowerPC
    2752 closed Relax execution enviroment for thread begin extensions
    2754 closed no .strtab section
    2765 closed Application level deadlocks may lead to SMP lock level deadlocks
    2768 closed untar does not keep permissions correctly.
    2769 closed rtems-syms does not clean up temp files.
    2770 closed Missing documentation for RTEMS_LINKER_ROSET_CONTENT and RTEMS_LINKER_RWSET_CONTENT
    2771 closed Empty C++ file with just <rtems.h> does not compile with HEAD.
    2775 closed ARM CP15 arm_cp15_set_translation_table_entries fails if TTB in read-only memory
    2776 closed SPI Framework
    2777 closed Remove librtems++
    2784 closed Add function to get the current priority of a task by scheduler instance
    2788 closed RTEMS I2C API only defines Standard-mode (Sm) speed as a default.
    2790 closed Linker sets broken with GCC 7
    2795 closed Overrun Handling for general real-time models
    2797 closed Add ability to add/remove processors to/from a scheduler instance
    2798 closed Fix POSIX timer interval
    2800 closed qoriq variants failing to build
    2802 closed Test "libdl (RTL) 5" fails on SPARC targets
    2803 closed Get rid of CPU_BIG_ENDIAN and CPU_LITTLE_ENDIAN
    2805 closed Use SPRG0 on PowerPC for current per-CPU control (SMP only)
    2806 closed Undocumented confdefs.h Configure Options
    2807 closed rtems-docs repository is not known to trac
    2808 closed Conditionally provide rtems_interrupt_frame
    2809 closed Reduce interrupt latency on SMP configurations during thread dispatch
    2810 closed Remove sparc/sis BSP variant
    2811 closed More robust thread dispatching on SMP and ARM Cortex-M
    2816 closed Many ARM BSPs have Static Assert
    2817 closed All Blackfin BSPs do not Compile on Master
    2818 closed NIOS2 Does Not Compile on Master
    2819 closed powerpc-ss555 does not compile on master
    2820 closed All SPARC64 BSPs do not Build on master
    2821 closed No BSPs Build on Master
    2822 closed m32csim does not build on master
    2823 closed Nearly all m68k BSPs do not Build on Master
    2824 closed arm/lpc23xx_tli800 no longer links tar01
    2825 closed Improve the fatal error handling chapter of the user manual
    2826 closed arm_cp15_get_translation_table_base_control_register warning.
    2829 closed xz git URL in README is broken
    2835 closed Ada support is broken on SMP configurations
    2836 closed Add posix_devctl()
    2838 closed Termios task driven mode should use mutex for device operations
    2839 closed Add new interrupt server driven Termios mode
    2840 closed Use self-contained mutexes for Termios framework
    2841 closed Add NXP SC16IS752 serial device driver
    2842 closed Change C11 threads support to use Classic tasks instead of POSIX threads
    2843 closed Use self-contained objects instead of Classic API for drivers and support libraries
    2844 closed JFFS2: Add IO controls to get filesystem instance information and force a garbage collection
    2845 closed Add I2C framework documentation
    2849 closed ATA/IDE support in RTEMS is out-dated
    2850 closed Driver manual covers non-existent Analog Driver
    2851 closed Driver manual covers non-existent Discrete Driver
    2853 closed Driver manual covers non-existent Non-Volatile Memory Driver
    2858 closed Add user defined thread names
    2859 closed Implement POSIX Shared Memory Objects
    2862 closed docs.rtems.org Add support to ReST format releases.
    2863 closed Update POSIX 1003.1 Compliance Guide for ReST
    2864 closed docs.rtems.org Automatic update of branches content when a rtems-doc.git change is made.
    2865 closed Coverpage installed when building the docs repeats catalogue.xml entries
    2867 closed Fix exclude rule in rtems-test-check
    2868 closed src/c/src/lib/libbsp/arm/smdk2410/smc/smc.c: 3 * pointless local variables ?
    2873 closed src/c/src/lib/libbsp/arm/raspberrypi/i2c/i2c.c:320: defective error checking ?
    2874 closed src/c/src/lib/libbsp/powerpc/beatnik/marvell/gt_timer.c: 4 * pointless check ?
    2877 closed DHCP client fails on complex networks
    2878 closed src/c/src/lib/libbsp/sparc/shared/can/occan.c:1573: broken error checking ?
    2879 closed src/cpukit/libdebugger/rtems-debugger-server.c: four problems
    2880 closed src/cpukit/libfs/src/jffs2/src/readinode.c:189: faulty logic
    2883 closed src/c/src/lib/libbsp/arm/tms570/console/tms570-sci.c:248: strange expression ?
    2885 closed Fix rtems_rate_monotonic_postponed_job_count() prototype
    2889 closed RTEMS_STACK_CHECKER_EXTENSION has incomplete definition
    2890 closed _RBTree_Initialize_node generates warnings
    2893 closed Remove CONFIGURE_SMP_APPLICATION
    2894 closed Rename CONFIGURE_SMP_MAXIMUM_PROCESSORS to CONFIGURE_MAXIMUM_PROCESSORS
    2895 closed Prefix the confdefs.h internal defines with an underscore
    2896 closed RSB requirements are missing pax
    2897 closed Update termios.h to match the latest FREEBSD definitions
    2905 closed Merge LEON
    2906 closed rtems-doc waf configure does not detect sphinxcontrib.bibtex status
    2909 closed xz: Support for 64-bit CRC is build although XZ_USE_CRC64 is not defined
    2912 closed libdebugger: control reaches end of non-void function
    2916 closed termios: Change receive callback invocation to enable select() and poll() support
    2917 closed termios: Make write POSIX compatible
    2922 closed libdl unresolved externals that use more than one block or multiple entries corrupts.
    2923 closed Questionable Code in resource_snapshot.c
    2924 closed Warnings in SPARC BSPs
    2925 closed Warnings in rtl-obj-cache.c on some targets
    2930 closed Coverity Reports Out of Bounds Read in drvmgr_print.c
    2933 closed Flexibleassignto is broken on new ticket page.
    2935 closed Termios task driven mode not compatible with SMP
    2941 closed building rsb freezes
    2942 closed rtems building error
    2943 closed rtems building error
    2945 closed Many failures on LEON3 with SMP disabled
    2946 closed Add a top level global testsuite configuration file (.tcfg) and a 'user-input' test state.
    2949 closed Questionable patch organization in RTEMS tools and RSB
    2951 closed Error path in rtems-gcc-6.3.0-newlib-2.5.0.20170228-1.cfg
    2954 closed ARM: Optimize context switch
    2957 closed Shared memory support internal locking is broken
    2958 closed Add some popular benchmark programs to the testsuite
    2959 closed arm/libdl: C++ exception index tables may not be ordered correctly
    2962 closed Set test configurations to reflect test results.
    2963 closed Add a testsuite top level confguration file that is common to all tests.
    2965 closed bootstrap sort inconsistent with sb-bootstrap for acinclude
    2967 closed ARM: Change ABI to not use short enums
    2968 closed newlib inttypes.h is missing some methods
    2969 closed qoriq BSPs depend on mkimage which is not always available
    2976 closed warnings in rtems-debugger-server.c
    2977 closed warnings in Dhrystone Benchmark
    2980 closed pc586-sse does not compile fsjffs2gc01
    2981 closed testdata excludes on included tcfg files does not work
    2982 closed LibBSD broken with GCC+RTEMS changes
    2983 closed Create <rtems/inttypes.h> to consolidate extensions to <inttypes.h>
    2984 closed Changing Trac milestone page fails.
    2990 closed RTEMS Source Builder Fails on Windows Builds
    2992 closed Long path crashes the RSB when listing a directory.
    2993 closed SMP assert in _Thread_Executing in libdebugger
    2994 closed tar01 XZ error
    2995 closed Missing bsets
    2997 closed Monitor config command does not handle unlimited objects.
    2998 closed RTEMS User Manual Quick Start does not cover releases.
    2999 closed sb-check on Cygwin
    3000 closed Setting interrupt level in the mode arg on SMP returns RTEMS_UNSATISFIED
    3001 closed SMP build of RTEMS Testsuite does not set CONFIGURE_MAXIMUM_PROCESSORS
    3003 closed FAT does not support clusters bigger than 32K
    3006 closed SPARC LEON3 BSP SMP build is broken.
    3007 closed ARM caching issues
    3008 closed missing pax causes install failures
    3009 closed Provide invalid link handler for docs.rtems.org so old docs can be removed.
    3010 closed src/cpukit/posix/src/mmap.c:189]: (style) Suspicious condition
    3011 closed Error compiling xilinx_zynq_zedboard.
    3012 closed Global C++ IO streams are broken (cout, cin, cerr)
    3013 closed ProgrammingError: (1064, "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'sid='nikolaykomashinskiy' AND authenticated=1 AND name='force_change_passwd'' at line 1")
    3014 closed interrupt vector indexing is assuming BSP_INTERRUPT_VECTOR_MIN = 0 for this code.
    3015 closed Add support for IBM PPC 750 chip
    3016 closed missing a couple register names + a #ifndef ASM around serial.h inclusion
    3017 closed improvement in pci.h
    3018 closed RSB cannot compile tool chain in CentOS 7.
    3020 closed Review tests using CONFIGURE_DISABLE_SMP_CONFIGURATION
    3023 closed Parameter of CPU_COPY() are in wrong order
    3025 closed m32c/m32csim does not build linpack-pc.c
    3027 closed RTEMS source builder fails when building gcc documentation with newer versions of gcc
    3032 closed CPU_NAND_S() implementation is not in line with FreeBSD
    3036 closed CPU_CMP() implementation is not in line with FreeBSD
    3040 closed Cannot use RTEMS mailing list archive for patches
    3043 closed 4.11/rtems-nios2 does not build on Windows.
    3046 closed 4.12/rtems-moxie missing release number.
    3047 closed Remove docs directory from the RSB
    3049 closed Warnings in libdebugger
    3052 closed RSB: powerpc GDB build broken on Apple Darwin
    3054 closed gdb 7.12.1 on RSB 4.12 branch fail to build on Archlinux
    3056 closed Add EDF SMP scheduler
    3057 closed Add a workaround for the LEON3FT store-store errata
    3059 closed Add a simple processor affinity support to the EDF SMP scheduler
    3061 closed including 'unistd.h' in C++ does not build.
    3063 closed Make the EDF scheduler the default SMP scheduler
    3069 closed Add rtems_scheduler_ident_by_processor()
    3070 closed Add rtems_scheduler_ident_by_processor_set()
    3071 closed Create an interrupt server for every processor in the system
    3072 closed Declaration of global functions in driver source files
    3076 closed Test suite failures due to floating point usage
    3077 closed SPARC: Add lazy floating point context switching
    3079 closed Ada tests do not build
    3080 closed Infinite loop in SPARC rtems_invalidate_multiple_instruction_lines()
    3082 closed Add 64-bit support for PowerPC
    3083 closed parallel make not working
    3084 closed Makefile recipe override warning has returned
    3085 closed Add hypervisor support for QorIQ BSPs
    3087 closed RSB rtems-gdb-7.12-1.cfg MD5 value is ERROR
    3088 closed shell test in testsuites\samples\fileio many COMMANDs is Lost
    3089 closed Inconsistent blocking addressing in RFS
    3090 closed Add BSP for i.MX 7
    3091 closed Core Dump in powerpc-rtems4.12-ld
    3096 closed Shell internal commands should be public.
    3098 closed Add new RTEMS repos to github.
    3099 closed Add RTEMS FDT wrapper and shell command to libmisc
    3100 closed Add Xilinx AXI I2C driver
    3101 closed Add I2C Drivers for LM25066A, TMP112, ADS1113 and ADS1115
    3102 closed rtems-exeinfo does not decode ARM static constructors.
    3103 closed rtems-tools on CentOS 7 Build Failure
    3109 closed Add RISC-V support
    3111 closed Newlib: Change time_t and clock_t integer types to 64-bit
    3112 closed POSIX: Make pthread_mutex_t self-contained
    3113 closed POSIX: Make pthread_cond_t self-contained
    3114 closed POSIX: Make pthread_barrier_t self-contained
    3115 closed POSIX: Make pthread_rwlock_t self-contained
    3116 closed POSIX: Make sem_t self-contained
    3117 closed score: Optimize _Thread_queue_Enqueue() timeout handling
    3121 closed clock() implementation in Newlib is broken
    3122 closed Simplify and unify BSP_output_char
    3123 closed GDB 8.0.1 is broken on FreeBSD 11
    3124 closed Ignore pshared attribute for POSIX semaphores
    3125 closed Accept PTHREAD_PROCESS_SHARED for POSIX mutexes
    3126 closed Accept PTHREAD_PROCESS_SHARED for POSIX barriers
    3127 closed MIPS tool build on Darwin (MacOS) fails.
    3128 closed RTEMS Tools corvar does not build on Windows.
    3129 closed RTEMS Tools covoar build fails on Windows
    3130 closed RTEMS Doxygen.in latex output does not build
    3132 closed Add reference counting to file descriptors
    3133 closed Remove rtems_libio_t::driver
    3134 closed Remove LIBIO_FLAGS_CREATE
    3135 closed Devel mailing list doesn't work and Git push impossible due to disk full
    3136 closed Use FIFO for file descriptor free list
    3137 closed Accept PTHREAD_PROCESS_SHARED for POSIX condition variables
    3139 closed Remove old ISR parameter from Clock_driver_support_install_isr() and make it optional
    3140 closed CPU Kit broken with --enable-rtems-debug
    3141 closed Change the BSP Howto's name to something smaller.
    3142 closed POSIX: Reduce size of pthread_once_t and make it zero-initialized
    3148 closed PSXRDWRV Test failure on Beaglebone Black
    3152 closed Beaglebone Black crashes on u-boot master build.
    3153 closed Accept PTHREAD_PROCESS_SHARED for POSIX rwlocks
    3157 closed PowerPC tools don't build on 32-bit hosts
    3158 closed Examples v2 does not build
    3159 closed Examples v2 trace linker ini files reference non-existing dump-on-error
    3160 closed Trace linker score support is broken
    3163 closed Add I2C device driver for temperature sensor LM75A
    3166 closed New default ticket assignee: NeedsReview
    3167 closed Internal status codes must not depend on RTEMS_POSIX_API
    3168 closed Simplify POSIX_API_Control
    3170 closed Use BSP_output_char via RTEMS printer or simple console driver for test output by default
    3171 closed RSB GCC does not build on High Sierra and APFS
    3172 closed i386 PC BSP does not reset when bsp_reset is called.
    3173 closed XIlinx AXI I2C driver IP race condition causes clock glitch.
    3174 closed Remove rtems_pthread_attribute_compare()
    3175 closed Merge FreeBSD timecounter changes from 2015-01-20 to now
    3176 closed __getreent in libc.a and generated by confdefs.h
    3177 closed Replace/update POSIX Compliance Guide
    3178 closed Update sh-rtems4.12 bset to use rtems-default (using old gcc)
    3179 closed New warnings from Time Changes
    3180 closed ar warning: u' modifier ignored sinceD' is the default (see `U')
    3181 closed Various cc1plus warnings for "valid for C/ObjC but not for C++"
    3182 closed CLOCK_REALTIME timeout implementation is not POSIX compliant
    3185 closed Change uptime seconds to int32_t
    3187 closed smptests/Makefile.am Issues
    3188 closed Add C11 Threading Examples
    3189 closed MUTEX_INITIALIZER missing braces warning
    3190 closed RTEMS Tester covoar does not link on MacOS
    3191 closed RTEMS Tester covoar dies with no arguments.
    3198 closed Add lazy update of line control and baud divisor to NS16550 serial driver
    3200 closed m32c tests don't build -- test_context too large
    3201 closed epiphany tools checksum error
    3202 closed or1k tools build error
    3203 closed Upgrade trac to fix numerous problems.
    3204 closed Exception in rtems-test
    3205 closed Relative timespec timeouts are subject to integer overflows
    3207 closed Supported Architectures Page is out of date
    3209 closed RSB should fail on this error
    3210 closed Improve the RSB build email message
    3211 closed Fix pthread_create() with user provided stack
    3212 closed Qemu Fails to Build, RSB Gives Odd Traceback
    3213 closed Move erc32, leon2, leon3, psim and jmr3904 to Tier 2
    3215 closed Configuring a System Still Includes Notepads and Has Wrong Heading
    3216 closed Replace vprintk() implementation
    3217 closed Add RTEMS version, build and tools details to tests
    3218 closed Termios canonical mode (ICANON) does not return input line by line
    3219 closed Zynq BSP missing linker option --gc-sections
    3220 closed Change RTEMS release number scheme from 4.12 to 5
    3221 closed RSB wiki page duplicates documentation
    3224 closed Upgrade or1k and m32c to Binutils 2.29
    3225 closed Upgrade m32c to GDB 8.0.1
    3226 closed gdb: pr 16827, fix sim on Mavrick
    3227 closed sb-check fails on Msys2 64-bit
    3228 closed aarch64 missing from 5/rtems-all build set
    3229 closed Add index to all documents.
    3231 closed RTEMS Top level README needs updating.
    3232 closed Use of .. include:: in the User Manual should be changed.
    3234 closed Quick Start Instructions Inconsistent
    3235 closed Fix rtems_semaphore_flush() for priority inheritance semaphores
    3236 closed Fix thread queue owner priority update in _Thread_queue_Flush_critical()
    3237 closed Fix priority ceiling updates
    3238 closed Git push to Trac with more than one commit does not update tickets.
    3239 closed Add getentropy() implementation provided by each BSP
    3240 closed cpukit/libmisc/stackchk/check.c stack addresses formatted incorrectly.
    3242 closed Workarounds for UT699, UT700, and GR712RC errata
    3243 closed Simplify global construction
    3244 closed Change rtems_panic() implementation and document this function
    3245 closed Replace BSP_panic() with rtems_panic()
    3246 closed Remove _BSP_Fatal_error()
    3247 closed Remove BSP-specific defaults for RTEMS_BSP_CLEANUP_OPTIONS()
    3248 closed Add BSP_VERBOSE_FATAL_EXTENSION to RTEMS_BSP_CLEANUP_OPTIONS
    3249 closed imx7 does not link getentropy01 test on master
    3254 closed Reorganize header files to avoid "make preinstall"
    3255 closed Warnings on 64-bit targets
    3256 closed Ada run-time needs support for self-contained POSIX synchronization objects
    3260 closed libpci depends on BSP-specific header files
    3261 closed A couple of documentation typos
    3264 closed Add monotonic watchdog based on uptime
    3265 closed Use second one based uptime for CLOCK_MONOTONIC for FreeBSD compatibility
    3266 closed cpukit/libpci references BSP headers.
    3267 closed rtems/status-checks.h calls printk without including the needed header.
    3268 closed PowerPC BSP include naming mess.
    3270 closed Remove unused support for MPC505
    3277 closed QorIQ: Add MAC-less DPAA driver to libbsd
    3278 closed bsp-builder has incorrect print (%s in output)
    3281 closed Add epiphany support to GDB 8.0.0
    3283 closed Bad URL in OpenOCD/Xilinx_Zynq Wiki Page
    3284 closed RSB uses hard coded GCC binary paths
    3285 closed Reorganize BSP source directory
    3290 closed Add device tree support to Altera/Intel Cyclone V BSP
    3294 closed gcc version report for released tools is wrong.
    3298 closed dlerror non-conformance
    3305 closed Add paravirtualization support to ARM
    3306 closed Add paravirtualization support to PowerPC
    3307 closed PowerPC linkcmds.base missing wildcards on some sections
    3309 closed rtems_task_create's initial_mode SMP update
    3312 closed RSB macro calls such as define fail on unicode keys.
    3315 closed Move expat's home site to github from SF.
    3318 closed Improve INTERNAL_ERROR_THREAD_EXITTED to show the id and thread name
    3320 closed Add a simple task console driver
    3323 closed mhttpd's http etag can result in invalid caching in a browser.
    3325 closed Simplify clustered scheduler configuration
    3327 closed Eliminate score/cpu/*/.../types.h
    3328 closed bootstrap uses non-POSIX compliant echo -e
    3329 closed Trac Login Failure (bad password) Causes Internal Error
    3334 closed deadlock in _once()
    3339 closed Several PowerPC linker commands do not support constructors/destructors with priority
    3340 closed gen83xx warning for macros redefined
    3341 closed sparc64: Macro Redefined
    3342 closed pthread_setschedparam() has incorrect prototype
    3343 closed pthread_mutex_getprioceiling() has incorrect prototype
    3344 closed mcf5272/mcf5272.h Timer3 Duplicate Definition
    3345 closed mvme3100 spaces needed around quote in macro definitions in bsp.h
    3346 closed bf533.h
    3348 closed beatnick:spaces needed around quote in macro definitions in bsp.h
    3349 closed pc386 edid.h invalid macro names
    3350 closed sptimecounter02 warning due to defining _KERNEL and disabling part of <sys/time.h>
    3352 closed Warning in all lpc176x variants
    3354 closed PowerPC BSPs duplicate PAGE_MASK, etc redefinition
    3358 closed Deprecate rtems_disk_create_phys(), etc.
    3374 closed rtems-test does not honor --mail-from argument
    3375 closed Remove command line pre-processor defines
    3376 closed Remove cklength program
    3377 closed Remove eolstrip program
    3378 closed Remove unhex program
    3379 closed Remove packhex program
    3380 closed Move rtems-bin2c program to rtems-tools
    3381 closed rtems-test command line documentation appears to be out of date
    3382 closed Testsuite Makefile merge to one per group of tests
    3383 closed Require --enable-rtemsbsp with --enable-smp or --enable-multiprocessor
    3384 closed Prefer int for int32_t
    3385 closed Generate an error if RTEMS's gcc is not found when the user runs configure
    3386 closed Trac's git changeset browsing is suspect.
    3387 closed Add subdir-objects to automake flags
    3388 closed rtems-tester: possible parsing error for qemuprep-altivec on exclude SMP configuration
    3389 closed Warning flags have disappeared with recent autoconf changes
    3390 closed NFS: Remove support for cexp
    3392 closed infinite loop in RSB's path when a prefix path is not writable
    3395 closed rtems-ld does not remove executable when there is an output error
    3396 closed rtems-ld does not handle R_ARM_V4BX relocation records
    3397 closed The register keyword is deprecated in C++11
    3401 closed dl06: tms570* Mixed LSB/MSB Error
    3402 closed dl06: mips hurricane Mixed Endian Error
    3403 closed RSB RTEMS tool set build is irreproducible
    3407 closed Move Gaisler.org and Gaisler.se hosted RSB patches to rtems.org
    3409 closed Strip down configure checks to the bare minimum
    3410 closed Remove bin2boot program used by i386 BSPs
    3411 closed qemuppc does not install linkcmds.base
    3413 closed examples-v2 both_hello and triple_period fail to build
    3415 closed Add examples and tests as components
    3416 closed Update Ubuntu RSB Instructions for 17.10
    3417 closed Add libdwarf to elftoolchain and provide a C++ wrapper
    3418 closed Remove difftest and sorttimes test tools
    3419 closed Always build network services (tftpfs, ftpfs, ftpd, telnetd, libdebugger)
    3421 closed New Trac components for Coverage and Trace
    3423 closed examples-v2: m68k/powerpc BSPs undefined reference to _Thread_Life_action_handler
    3424 closed examples-v2: no MIPS BSPs pass configuration step
    3425 closed examples-v2: PowerPC fails to build fat_ramdisk
    3432 closed Remove Simple SMP Priority Scheduler
    3433 closed Add SMP support for RISC-V
    3434 closed Add CONFIGURE_MINIMUM_POSIX_THREAD_STACK_SIZE configuration option
    3435 closed Add test case for CONFIGURE_BSP_PREREQUISITE_DRIVERS configuration option
    3436 closed Remove clock driver Clock_driver_support_shutdown_hardware() hook
    3437 closed Replace use of printk() in free() with a fatal error
    3443 closed Remove shgen program
    3444 closed Remove nios2gen program
    3445 closed Remove multigen script
    3446 closed Remove cvsignore-add.sh script
    3447 closed Remove rtems-testsuite-autostuff script
    3451 closed Remove size_rtems script
    3452 closed Update RISC-V tool chain to support standard 64-bit chips
    3453 closed Add RISC-V GDB
    3454 closed Tracing Framework Documentation in User Manual
    3455 closed Remove install-if-change script
    3458 closed rtems-test should not use the env PATH to find covoar
    3459 closed Rework initialization and interrupt stack support
    3460 closed GDB 8 SIS LEON2 LEON3 Patches
    3461 closed Canadian cross compilation of RTEMS tools not supported for x86_64-w64-mingw32
    3463 closed Convert covoar to use DWARF function data
    3465 closed Integrate all changes from Linux v3.11 to v4.17 made in the JFFS2 sources
    3471 closed Update libfdt as of date 2018-07-09
    3472 closed Update of libbsd to a version close to the FreeBSD 12 release
    3475 closed Add RTEMS_PREDICT_TRUE() and RTEMS_PREDICT_FALSE() for static branch prediction hints
    3478 closed RISCV BSP Tester Cleanup Needed
    3480 closed CONFIGURE_MINIMUM_TASK_STACK_SIZE may affect CONFIGURE_INTERRUPT_STACK_SIZE
    3482 closed Relax the buffer alignment required by rtems_partition_create()
    3484 closed RFS: Remove stray call of rtems_disk_release() in rtems_rfs_buffer_sync()
    3486 closed Use uintptr_t and size_t instead of uint32_t in rtems_partition_create()
    3488 closed Remove CONFIGURE_HAS_OWN_MOUNT_TABLE
    3489 closed Obsolete CONFIGURE_HAS_OWN_CONFIGURATION_TABLE
    3490 closed Remove CONFIGURE_HAS_OWN_CONFIGURATION_TABLE
    3491 closed Align mprotect() prototype with POSIX
    3496 closed Remove superfluous interrupt enable in _Thread_Dispatch_enable()
    3498 closed Command and Variable Index is empty
    3499 closed The "Index" chapter is empty
    3500 closed Change rtems_waf's RTEMS path check from bin to share/rtems`
    3501 closed MSR_RI defined multiple places
    3502 closed PL111_LCD_CONTROL_LCD_BPP_16 Redefined
    3503 closed PDF Documentation is missing an index
    3504 closed Warning and formatting in bsps/powerpc/mpc55xxevb/dev/dspi.c
    3505 closed powerpc/virtex redefined warning
    3506 closed waf for building RTEMS applications needs updating
    3507 closed Add flexible per-CPU data
    3508 closed Add support for thread to processor pinning
    3510 closed ATA driver uses deprecated rtems_blkdev services
    3511 closed int/pointer size warnings in powerpc-qoriq_e6500_64
    3512 closed sb-check:No python command with Python 2 and Python 3 installed
    3513 closed Convert tqm8xx console driver to new Termios API
    3516 closed sb-set-builder should report disk usage of build
    3517 closed RSB Ubuntu Host Requirements Missing Some
    3518 closed RSB MacOS Nits
    3519 closed RSB does not strictly check args
    3520 closed Remove CONFIGURE_HAS_OWN_FILESYSTEM_TABLE
    3522 closed Update mDNSResponder to Apple version v878.30.4
    3523 closed Add FEC network interface driver for TQM8XX
    3525 closed Add MMC/SDCard support for i.MX 7Dual BSP
    3526 closed Convert PTY driver to new Termios API
    3528 closed Remove undocumented and untested CONFIGURE_MAXIMUM_PTYS
    3529 closed Fix issues raised by Coverity Scan for Telnet server
    3530 closed Fix issues raised by Coverity Scan for FTP server
    3531 closed Add POSIX Attribute Reports for More Than Scheduler (examples-v2)
    3532 closed RSB source only download is host specific
    3533 closed Add rtems_task_exit()
    3535 closed Remove stdin, stdout, stderr convenience routines for CEXP
    3536 closed Move RTEMS configuration data to a common config directory
    3537 closed RSB and RTEMS Tools Support for python2 and python3
    3538 closed Classic API Barrier Wait Section Title Has Wrong Name
    3539 closed Remove CPU_PROVIDES_IDLE_THREAD_BODY
    3542 closed Remove keep_stdio feature from Telnet service
    3543 closed Change Telnet server to allocate most resources during initialization
    3545 closed Support O_DIRECTORY open() flag
    3546 closed Support O_NOFOLLOW open() flag
    3547 closed Support O_CLOEXEC open() flag
    3549 closed Obsolete powerpc/virtex BSP
    3551 closed Move default configuration to separate library
    3552 closed cpu usage error in SMP mode
    3553 closed rtems-libbsd Missing waf in Top Directory
    3554 closed rtems-libbsd README.waf Needs an Update Sweep
    3555 closed IRC bots need to be registered to join #rtems
    3557 closed Test ticket
    3558 closed Update TracSpamFilter
    3559 closed Fix NavAdd plugin.
    3560 closed Fix FlexibleAssignTo
    3561 closed Migrate to CommitTicketUpdater
    3562 closed Use a short paths for the RSB temporary build path on Windows
    3568 closed RSB: UnboundLocalError: local variable 'build_max_size_human' referenced before assignment
    3569 closed waf version in various rtems-repositories incompatible with python 3.7
    3576 closed gdb 8.0.1 sis does not build on Cygwin
    3577 closed Avoid CLooG and ISL host depencencies for target GCC
    3579 closed testsuite's rtems-test-check.py python version support
    3583 closed Add rtems_malloc() and rtems_calloc()
    3585 closed Deprecate proc_ptr
    3587 closed Deprecate rtems_context
    3589 closed Deprecate rtems_context_fp
    3591 closed Deprecate region_information_block
    3593 closed Deprecate rtems_thread_cpu_usage_t
    3595 closed Deprecate rtems_rate_monotonic_period_time_t
    3598 closed Move internal types of API objects to separate header file
    3599 closed Remove m32c architecture port
    3600 closed Update or1k tools to use GCC master
    3602 closed Update or1k tool chain to use the upstream GCC
    3603 closed Remove support for 16-bit object identifiers
    3604 closed RTL Unresolved Symbols from common section on i386/pc686 (cloned)
    3605 closed RTL Allows Unloading a Module other Modules Depend Upon (cloned)
    3609 closed Update Spike Version in RSB (RISC-V simulator)
    3612 closed RTL unresolved compaction does not update string indexes after removing a string
    3620 closed CommitTicketUpdater does not process commits in order
    3621 closed Statically initialize object information structures
    3622 closed Remove cache routines working with a processor set
    3624 closed MSYS2 builds appear to ignore tcfg file
    3625 closed RTL Allows Unloading a Module other Modules Depend Upon (cloned)
    3626 closed sigtimedwait() needed when POSIX is disabled
    3629 closed Add RSB reporting section to the documentation.
    3630 closed Build of rtems-tools fails with i686-w64-mingw32
    3636 closed Add rtems_scheduler_get_maximum_priority()
    3637 closed Fix rtems_task_restart() argument type
    3649 closed Error with IRC anouncing in examples-v2 commits.
    3651 closed Sphinx 1.8 PDF (latex) on FreeBSD does not build
    3664 closed RSB config parsing slow on python3
    3665 closed Add low level event recording infrastructure
    3666 closed Add support for C++17 std::aligned_alloc
    3667 closed Support data cache disable on ARMv7-AR
    3668 closed Commit message in examples-v2 and libbsd didn't trigger a ticket update.
    3669 closed rtems-docs.git does not build with Sphinx 1.8.2 and 1.8.3
    3670 closed examples-v2 uses deprecated or obsolete RTEMS interfaces
    3672 closed No i386 BSP can link all tests after cache manager changes
    3673 closed xilinx_zynq_a9_qemu - fails to link psxconfig01
    3674 closed Raspberry Pi Fails to Build
    3675 closed RSB: Change default prefix to OS prefix + "rtems" + $rtems_version
    3677 closed ARM BSP contains ARM code in THUMB only build
    3678 closed Add RISC-V BSP with support for the grlib
    3682 closed Add BSP for Xilinx Zynq UltraScale+ MPSoC platform
    3683 closed Git clone via HTTPS does not give much interactive feedback
    3684 closed rtems_print_buffer is broken
    3685 closed Add large memory support to libdl
    3686 closed Add library searching and loading to libdl
    3687 closed Add architecture section support to libdl and support PowerPC's small data.
    3688 closed rtems-docs fails to build with python3
    3692 closed libdl does not honour write unlock/lock for sections
    3693 closed libdl incorrectly handles MIPS16hi/lo relocs
    3694 closed shm_open has logically unreachable code (Coverity ID: 1399706, 1399714)
    3696 closed Basic Support for Trace Compass
    3699 closed Wrong system register specified for ARM virtual timer value retrieval
    3708 closed Remove Doxygen comments from confdefs.h
    3720 closed mfill shell command uses the wrong arguments for the memset()
    3724 closed bsp/lpc24xx: Convert SSP driver to Linux API
    3725 closed bsp/lpc24xx: Convert I2C driver to Linux API
    3728 closed Set small data seciton to max size for mvme5500 and motorola_powerpc BSPs
    3731 closed Add rtems_scheduler_get_processor()
    3732 closed Add rtems_scheduler_get_processor_maximum()
    3733 closed Add general reg support to libdebugger
    3734 closed Add RTEMS_CONST attribute
    3735 closed Remove CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE
    3736 closed PowerPC Beatnik BSP C++ exceptions broken
    3741 closed libdl loading ELF objects from libbsd NFS file system ends in a deadlock
    3742 closed T_config conflicting type qualifiers for 'config'
    3743 closed RSB os and arch config logic is broken
    3746 closed libdl test dl05.exe failing
    3747 closed Address Cortex-M3 Errata 602117
    3748 closed libdl uses a linear symbol search on object file symbols
    3751 closed No documentation on Region Get Information Directives
    3753 closed Rename CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS
    3754 closed Users Guide Ubuntu Instructions Have Typo
    3756 closed Condition codes in PSR are destroyed by lazy FP context switch
    3760 closed BBB MMU update crashes
    3762 closed Return the current handler from ARM cp15 set exception call
    3763 closed RSB SIS build fails on FreeBSD
    3768 closed Add staging support to Makefile.inc
    3769 closed RSB BSP Buildsets
    3770 closed RSB 3rd party packages failing to build
    3773 closed RPi fails to boot
    3774 closed RPi2 SMP does not build
    3775 closed libdl does not handle ARM mode reloc tramp parsing
    3776 closed libdl ARM does not support ARM mode trampolines.
    3777 closed libdl object unload debugger delete support is broken
    3781 closed RSB crashes in case the host as an unreadable directory in "/"
    3783 closed MSYS2 RSB build error
    3785 closed Add RISC-V BSP with support for the Freedom E310 Arty A7 FPGA
    3789 closed TMS570 applciation build error
    3792 closed RSB fails to build on MSYS2
    3793 closed trace record tool does not build on Windows
    3794 closed Initial POSIX Signals Mask Incorrect
    3796 closed docs/develenv directory structure bitrot
    3797 closed Add LLVM as a package
    3798 closed Add sockatmark to libbsd
    3800 closed termios - Add Capability to Generate SIGINTR and SIGQUIT
    3802 closed RSB Build of Spike Fails on Second TIme (bug in upstream spike)
    3803 closed RSB ssl context error fetching qemu patches
    3804 closed sb-get-sources: Error repo_mail referenced before assignment
    3805 closed libdebugger build error on atsamv
    3806 closed Add fatal error for heap errors
    3808 closed Fix qemu-couverture-git RSB download file name
    3809 closed Fix epiphany-rtems5-gdb-7.8 RSB download file name
    3810 closed Use the release details in the release build docs
    3811 closed Release source path on ftp.rtems.org is wrong
    3812 closed Released RSB has no source set for rtems-tools
    3813 closed RSB does not handle --rsb-file in releases
    3814 closed Releasing creates 2 copies or the kernel and tools.
    3815 closed Improve SMP EDF scheduler configuration
    3817 closed RSB fails on FreeBSD 12.0 (32bit and 64bit)
    3821 closed Port NVMe support from FreeBSD to libbsd
    3822 closed Release created VERSION file in rtems-tools-.*.tar.xz is wrong
    3823 closed Untar_ family doesn't handle nested directories
    3826 closed top on SMP shows invalid priorities
    3830 closed Build problems with user names which contain space characters
    3831 closed Duplicate description of Tiers and Rules
    3833 closed Simplify RTEMS semaphore configuration
    3834 closed Simplify clock driver
    3835 closed Support statically allocated threads
    3836 closed Specify the application configuration options
    3837 closed Rename CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS
    3838 closed Rework work area initialization
    3839 closed RTEMS revision does not handle -
    3840 closed Add CONFIGURE_IMFS_ENABLE_MKFIFO
    3841 closed Add rtems_object_get_local_node()
    3842 closed RSB RTEMS version message string is fixed to the git hash
    3843 closed Add CONFIGURE_DIRTY_MEMORY
    3844 closed Remove CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE
    3845 closed Remove Ada-specific configuration options
    3848 closed Libdebugger test in libbsd should depend on libdebugger.a
    3849 closed Fix PSIM memory map
    3856 closed posix_devctl - Add support for SOCKCLOSE
    3857 closed Use EAGAIN for POSIX mq wait in ISR error
    3859 closed No output from joel scripts in telnet
    3861 closed Add CONFIGURE_VERBOSE_SYSTEM_INITIALIZATION
    3862 closed Canonicalize CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY
    3863 closed Remove support for the BSP_ZERO_WORKSPACE_AUTOMATICALLY BSP option
    3864 closed rtems-tester does not work with gdb simulators
    3865 closed Fix linker set item declarations for small data area targets
    3868 closed newlib links breaks mingw build
    3871 closed Remove rtems_configuration_get_posix_api_configuration()
    3873 closed Remove CONFIGURE_HAS_OWN_INIT_TASK_TABLE
    3874 closed Remove CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE
    3875 closed Split up confdefs.h in component based header files
    3876 closed Remove CONFIGURE_DISABLE_SMP_CONFIGURATION
    3881 closed Add API functions to map a task priority to/from a POSIX thread priority
    3882 closed Add POSIX user environment pointer to TCB
    3885 closed Context switch extension is broken in SMP configurations
    3887 closed Do not report remotes in RSB build log if --mail is used
    3888 closed Update rtems_waf in libbsd
    3893 closed RSB staging changes have broken building a 3rd party package
    3894 closed Replace the device filesystem with a specialization of the IMFS
    3895 closed Add a migration to RTEMS 5 chapter to User Manual
    3896 closed RSB option --source-only-download does not work with releases
    3898 closed Remove CONFIGURE_MAXIMUM_DEVICES
    3900 closed New template for boolean feature defines
    3901 closed New template for configuration options with a value
    3903 closed raspberrypi2 libbsd 5-freebsd-12 does not build
    3904 closed Add methods to dump the event records in base64 encoding (optionally zlib compressed)
    3907 closed Update Getting Started Instructions
    3909 closed rtems_waf with python2 needs to handle unicode strings with waf
    3911 closed Remove gdbarmsim
    3914 closed Spike has hard-coded path to DTC
    3919 closed RSB may not download source of pkconfig checked packages
    3921 closed QorIQ clock tick interval is off by one hardware clock tick
    3927 closed tclsh required to build sqlite -- makes all BSP bsets fail
    3936 closed C++ thread-local storage broken on sparc64
    3938 closed Many (~40) BSPs Fail to Link all Tests
    3944 closed qoriq_e500 BSP bset fails
    3945 closed Update DTC example on rtems-docs/user/rsb/configuration.rst
    3949 closed clock_settime() can lead to a failed _Assert()
    3953 closed rtems_extensions_create() accepts a NULL pointer table
    3956 closed RSB BSP build with tests does not keep a copy
    3960 closed Add to FreeBSD host setup information
    3961 closed bsps/arm: CPU counter based on arm generic timer doesn't work correctly
    3966 closed RSB bare version number if wrong.
    3967 closed Release source package list is out of date
    3968 closed symlinks in RTEMS source tree
    3969 closed dl06 fails on all libdl supported architectures
    3970 closed Deprecate use _RTEMS_version at API level
    3971 closed Deprecate use of RTEMS_MAXIMUM_NAME_LENGTH
    3972 closed Deprecate <rtems/system.h>
    3973 closed Add rtems_get_copyright_notice() and deprecate _Copyright_Notice
    3974 closed Deprecate ephipany port in rtems5 and remove in rtems6
    3976 closed Released RSB qemu4 source download fails.
    3987 closed ARMv7-M Exception handler does not store the SP
    3992 closed Release URL path with sources is wrong
    3995 closed Release doxygen support is broken
    4002 closed Beaglebone and PC BSP stacks do not build
    4005 closed Remove RTEMS_MP_NOT_CONFIGURED error condition
    4006 closed rtems-test target_exe_filter fails when there is no filter
    4010 closed Update mDNSResponder to Apple version v878.30.4
    4014 closed RSB RTEMS 5 Post Branch Clean
    4015 closed Sqlite has stopped http access
    4016 closed shm_unlink uses uninitialized obj_err on successful return from _POSIX_Shm_Get_by_name
    4017 closed RSB --host and --target option trigger the bset tarball
    4021 closed PowerPC for libbsd does not build
    4028 closed i386: SMP-System hangs with non-consecutive APIC IDs
    4030 closed i386: ISR can overwrite its own stack during system initialization
    4033 closed Add rtems_interrupt_server_create() and rtems_interrupt_server_destroy()
    4038 closed arm/atsam/SC16IS752: Make interrupt server configurable
    4049 closed RTEMS version number 5.1 breaks RTEMS version code
    4051 closed libbsd test fails to build
    4056 closed bsps/xilinx-zynq: Flush TX-Buffer before initializing the zynq-uart (cloned)
    4057 closed RSB 5/rtems-arm fails to build on Windows
    4083 closed i386: bad asm in smp mode (rtems.git/5)
    4137 closed The select mechanism does not support asynchronous device communication
    4138 closed the atomicity of some operations cannot be guaranteed.
    4139 closed low efficiency of sending inter-core interrupts
    4170 closed Raspberry Pi booting files from master branch not working
    4210 closed rtems-record-lttng '-e' option does not verify existance
    4325 closed Ubuntu's gcc preventing QEMU from being built
    4352 closed about get cpu number
    4353 closed the pci initialization part cannot pass the initialization
    4362 closed about error number
    4385 closed grlib/genirq: Bad returned value when enabling/disabling interrupt
    4457 closed shell command problem
    4465 closed m68k/uC5282: _fini epilog is missing
    4495 closed rtems-tools does not build with up-to-date llvm
    4535 closed acess JFFS2 sb->s_root question
    4536 closed acess JFFS2 sb->s_root
    4537 closed mutex is not initilaized in jffs2_new_inode
    4538 closed mutex is not initilaized in jffs2_read_inode
    4539 closed rtems_filesystem_table compile
    4541 closed rtems_jffs2_rmnod function problem
    4553 closed Adapt improved mailer.py for rtems-tools 5 branch
    4554 closed Adapt improved mailer.py for RSB 5 branch
    4561 closed Fix build issue with qemu4 on Ubuntu
    4562 closed Bump dtc on rtems5 to match rtems6
    4598 closed about MIPS architecture support
    4599 closed support pmu under MIPS platform
    4600 closed non-alignment exception
    4601 closed support for 64KB clusters DOSFS
    4602 closed support commands such as rename
    4603 closed Added support for Intel I210
    4604 closed Telnet client protocols
    4605 closed TFTP client protocols
    4606 closed TFTP server protocols
    4608 closed Added support for Intel 82580
    4609 closed support for DMA access
    4660 closed Spike failing to build with RSB 5 on Ubuntu 21.04
    4692 closed Python 3.8 introduces new warning about using operator "is" with a literal


    RTEMS 5.1 Tickets By Category

    Owner

    Owner Closed Total Progress
    Chris Johns 173 173 173/173
    Sebastian Huber 353 353 353/353
    Daniel Hellstrom 12 12 12/12
      100 100 100/100
    chrisj@… 12 12 12/12
    joel.sherrill@… 18 18 18/18
    Amar Takhar 22 22 22/22
    joel@… 3 3 3/3
    Gedare Bloom <gedare@…> 5 5 5/5
    joel 1 1 1/1
    Sebastian Huber <sebastian.huber@…> 18 18 18/18
    Chris Johns <chrisj@…> 14 14 14/14
    Christian Mauderer <christian.mauderer@…> 1 1 1/1
    Needs Funding 4 4 4/4
    Joel Sherrill 43 43 43/43
    Joel Sherrill <joel@…> 16 16 16/16
    Aun-Ali Zaidi <admin@…> 8 8 8/8
    Ralph Holmes <ralph@…> 1 1 1/1
    Ben Gras 1 1 1/1
    Joel Sherrill <joel.sherrill@…> 1 1 1/1
    Gedare Bloom 13 13 13/13
    Pavel Pisa <ppisa@…> 1 1 1/1
    Pavel Pisa 1 1 1/1
    Andreas Kölbl <andreas.koelbl@…> 1 1 1/1
    Fan Deng 1 1 1/1
    Hesham Almatary 3 3 3/3
    amar@… 1 1 1/1
    Frédéric Jouault <f.jouault@…> 1 1 1/1
    Vidushi Vashishth 1 1 1/1
    Christian Mauderer 3 3 3/3
    Jiri Gaisler 1 1 1/1
    Jan Sommer <jan.sommer@…> 3 3 3/3
    Kinsey Moore <kinsey.moore@…> 1 1 1/1
    Moyano Gabriel <gabriel.moyano@…> 1 1 1/1
    Alex White <alex.white@…> 2 2 2/2
    Ryan Long <ryan.long@…> 3 3 3/3
    Stavros Passas <stavros.passas@…> 1 1 1/1

    Type

    Type Closed Total Progress
    defect 524 524 524/524
    infra 16 16 16/16
    enhancement 213 213 213/213
    project 9 9 9/9
    task 82 82 82/82

    Priority

    Priority Closed Total Progress
    highest 30 30 30/30
    high 51 51 51/51
    normal 746 746 746/746
    low 14 14 14/14
    lowest 3 3 3/3

    Component

    Component Closed Total Progress
    fs 11 11 11/11
    arch/sparc 16 16 16/16
    unspecified 87 87 87/87
    doc 56 56 56/56
    tool/rsb 74 74 74/74
    arch/arm 45 45 45/45
    score 94 94 94/94
    arch/powerpc 34 34 34/34
    build 29 29 29/29
    tool/gcc 17 17 17/17
    tool 50 50 50/50
    admin 33 33 33/33
    posix 46 46 46/46
    test 5 5 5/5
    release 4 4 4/4
    tool/newlib 12 12 12/12
    bsps 22 22 22/22
    tool/website 6 6 6/6
    arch/i386 10 10 10/10
    config 31 31 31/31
    examples 2 2 2/2
    lib/dl 21 21 21/21
    network/libbsd 12 12 12/12
    arch/m68k 6 6 6/6
    arch/mips 3 3 3/3
    rtems 34 34 34/34
    network/legacy 11 11 11/11
    fs/fat 3 3 3/3
    dev/serial 5 5 5/5
    shell 7 7 7/7
    arch/riscv 7 7 7/7
    tool/gdb 6 6 6/6
    arch/or1k 3 3 3/3
    arch/epiphany 2 2 2/2
    lib 20 20 20/20
    tool/binutils 1 1 1/1
    dev 3 3 3/3
    arch/sparc64 2 2 2/2
    arch/bfin 1 1 1/1
    lib/block 3 3 3/3
    fs/jffs2 6 6 6/6
    fs/rfs 1 1 1/1
    arch/m32c 1 1 1/1
    lib/debugger 2 2 2/2

    Severity

    Severity Closed Total Progress
    critical 35 35 35/35
    blocker 47 47 47/47
    normal 740 740 740/740
    major 18 18 18/18
    minor 1 1 1/1
    trivial 3 3 3/3

    Reporter

    Reporter Closed Total Progress
    strauman 1 1 1/1
    Joel Sherrill 191 191 191/191
    Gedare Bloom 10 10 10/10
    Sebastian Huber 339 339 339/339
    Chris Johns 169 169 169/169
    Amar Takhar 9 9 9/9
    Kuan 1 1 1/1
    Bharath Suri 1 1 1/1
    Andrey Mozzhuhin 1 1 1/1
    daniel.cederman 1 1 1/1
    Daniel Hellstrom 1 1 1/1
    Jeffrey Hill 2 2 2/2
    Jakob Viketoft 1 1 1/1
    Aun-Ali Zaidi 1 1 1/1
    Santosh Vattam 1 1 1/1
    Nick Withers 1 1 1/1
    joguin 1 1 1/1
    Stefan Wallentowitz 1 1 1/1
    Serg Kruglov 1 1 1/1
    David Binderman 11 11 11/11
    printk 1 1 1/1
    aurelio 1 1 1/1
    Christian Mauderer 4 4 4/4
    Patrick Gauvin 1 1 1/1
    Alexander Krutwig 1 1 1/1
    Stavros Passas 5 5 5/5
    Kevin Kirspel 1 1 1/1
    Tanu Hari Dixit 1 1 1/1
    Martin Aberg 1 1 1/1
    DHANPAL SINGH 3 3 3/3
    alexgerbor 1 1 1/1
    Worth Burruss 2 2 2/2
    Hassan Karim 2 2 2/2
    munster 2 2 2/2
    Arturo Pérez 1 1 1/1
    Nikolay Komashinskiy 1 1 1/1
    phongvanpham 5 5 5/5
    AndiK 1 1 1/1
    likangbei 2 2 2/2
    Fan Deng 1 1 1/1
    Jeff Mayes 3 3 3/3
    Andrei Chichak 1 1 1/1
    Frédéric Jouault 1 1 1/1
    Amaan Cheval 1 1 1/1
    Vidushi Vashishth 1 1 1/1
    Jens Schweikhardt 2 2 2/2
    Justin 1 1 1/1
    Malte Münch 1 1 1/1
    jameszxj 2 2 2/2
    Joseph Hickey 1 1 1/1
    Kevin Gordon 2 2 2/2
    Markus Bernd Moessner 1 1 1/1
    Kinsey Moore 2 2 2/2
    dufault 1 1 1/1
    Andreas Werner 1 1 1/1
    pragnesh 1 1 1/1
    Jan Sommer 3 3 3/3
    only_yipie 6 6 6/6
    Miguel Garcia-Gordillo 1 1 1/1
    Ryan Long 7 7 7/7
    GabrielMoyano 1 1 1/1
    tianye 1 1 1/1
    chenjin_zhong 6 6 6/6
    ostyche 11 11 11/11
    Konrad Schwarz 1 1 1/1
    mw 1 1 1/1
    Jonathan Brandmeyer 1 1 1/1
    Cláudio Maia 1 1 1/1
    Matthew J Fletcher 1 1 1/1

    Version

    Version Closed Total Progress
    4.5 2 2 2/2
    5 674 674 674/674
    4.11 81 81 81/81
      60 60 60/60
    4.10 26 26 26/26
    4.9 1 1 1/1


    RTEMS 5.1 Tickets


    1247 - RTEMS does not implement locks needed by multithreaded newlib

    Link https://devel.rtems.org/ticket/1247
    Id 1247
    Reporter strauman
    Created 17 June 2007 03:43:24
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component fs
    Status closed
    Resolution fixed
    Version 4.5
    Milestone 5.1
    Priority highest
    Severity critical
    Keywords  
    Cc chrisj@…
    Blocking  
    Blocked by  

    Description

    multi-threaded newlib protects a number of internal data structures
    (as of newlib-1.15 these comprise:

    • global list of FILE objects
    • stdio FILE object initializer
    • individual FILEs [since FILEs with the exception of
      stdin/stdout/stderr are per-process entities]
    • global hash table used by telldir/seekdir
    • individual DIR structures (opendir/readdir)
    • atexit list
    • list of environment variables
    • global timezone variable

    )
    using mutexes. It expects the OS to implement these locks but defaults
    to not using locking if the OS does not provide an implementation.
    Currently, RTEMS does *not* provide its own implementation of 'sys/lock.h'
    and therefore vital data structures in newlib are currently *unprotected*
    (with the exception of environment variables -- 'envlock.c' had been
    added to RTEMS a while ago but since then, newlib has introduced more
    locks and a general OS interface which - once implemented - will obsolete
    'envlock.c').

    Note that while semantics of having no protection for individual FILE
    objects may be tolerable, having no protection for global newlib data
    structures such as lists of FILEs is not acceptable.

    I am currently working on an implementation which should be available shortly.

    Attachments:

    1 strauman, Thu, 23 Aug 2007 23:53:38 GMT
      attach: set to PR#1247-rtems-newlibc-locking.diff
     
    2 strauman, Thu, 23 Aug 2007 23:55:18 GMT
      attach: set to PR#1247-newlib-1.15.0-locking.diff
     
    3 strauman, Thu, 06 Mar 2008 21:47:00 GMT
      attach: set to PR#1247-rtems-newlibc-locking-1.diff
     
    4 strauman, Sat, 07 Mar 2009 00:18:24 GMT
      attach: set to PR#1247-newlib-1.16.0-locking-crt0add.diff
     
    Comment 1
    1. strauman, Thu, 23 Aug 2007 23:56:34 GMT
    2. attachments.mimetype: changed from text/x-patch to text/plain
    3. attachments.ispatch: changed from 0 to 1
    Comment 2
    1. strauman, Thu, 06 Mar 2008 21:47:00 GMT
    2. attachments.isobsolete: changed from 0 to 1
    Comment 3
    1. strauman, Sat, 07 Mar 2009 00:18:24 GMT

    This patch (to *newlib*) is required (in addition to the previously posted newlib patch) to help RTEMS autoconf tests. These tests try to link specific functions from newlib in order to determine if newlib provides them. Some functions require the newlib locks, however, and linkage would fail unless stubs for the locking routines are present in crt0. Such stubs are what this patch provides.

    Comment 4
    1. Chris Johns, Fri, 04 Jun 2010 20:54:02 GMT
    2. owner: changed from Joel Sherrill to Chris Johns
    3. status: changed from new to assigned, chrisj@rtems.org
    4. version: changed from 4.7 to HEAD
    5. component: changed from cpukit to filesystem
    6. milestone: changed from 4.7 to 4.11
    Comment 5
    1. Gedare Bloom, Mon, 24 Nov 2014 18:58:28 GMT
    2. version: changed from HEAD to 4.11

    Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11

    Comment 6
    1. Gedare Bloom, Tue, 10 Feb 2015 15:16:33 GMT
    2. description: modified (diff)

    Sebastian/Chris: Is this still a valid problem?

    Comment 7
    1. Gedare Bloom, Mon, 02 Mar 2015 20:42:45 GMT
    2. milestone: changed from 4.11 to 4.11.1

    bump milestone

    Comment 8
    1. Sebastian Huber, Fri, 31 Jul 2015 05:32:11 GMT
    2. status: changed from assigned to closed
    3. version: changed from 4.11 to 4.5
    4. resolution: set to fixed
    5. milestone: changed from 4.11.1 to 4.12

    It is fixed with this commit in Newlib:

    ​https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f39988a

    It requires an RTEMS version [9e9e61d27d146e2ca83d5b0f590683a3f605c3f1/rtems] or later.

    Comment 9
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 10
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    1394 - scandir() fails due to MAXNAMELEN is incorrect

    Link https://devel.rtems.org/ticket/1394
    Id 1394
    Reporter Daniel Hellstrom
    Created 20 March 2009 07:55:57
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component tool/newlib
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc joel.sherrill@… sebastian.huber@…
    Blocking  
    Blocked by  

    Description

    I have been trying to use scandir() however the newlib one does not work due to MAXNAMLEN and NAMLEN differ. scandir in libcsupport seems to have a fix for this, however my libcsupport_a-scandir.o is empty, I'm guessing because HAVE_SCANDIR is defined.

    It is used in scandir() (newlib-1.17.0/newlib/libc/posix/scandir.c:117) by the macro DIRSIZ. Where DIRSIZ uses the MAXNAMELEN define which is set incorrectly. It does not match the sizeof(struct dirent) which makes the DIRSIZ return a negative number, then malloc(DIRSIZ(d)) will try to allocate 4GB which fail.

    My guess is that MAXNAMELEN should be defined in newlib-1.17.0/newlib/libc/sys/rtems/sys/dirent.h or newlib-1.17.0/newlib/libc/sys/rtems/include/limits.h or in a new file.

    I tried to run the code below on my FAT filesystem, taken directly from the scandir(3) man page.

    /* print files in current directory in reverse order */
    #include
    main(){

    struct dirent __namelist;
    int n; __

    n = scandir(".", &namelist, 0, NULL);
    if (n < 0)

    perror("scandir");

    else {

    while(n--) {

    printf("%s\n", namelist[n]->d_name);
    free(namelist[n]);

    }
    free(namelist);

    }

    }

    Attachments:

    1 Gedare Bloom, Wed, 25 Feb 2015 19:06:54 GMT
      attach: set to 0001-rtems-make-MAXNAMLEN-match-with-NAME_MAX.patch
     
    2 Joel Sherrill, Tue, 03 Mar 2015 21:17:09 GMT
      attach: set to 0001-Add-simple-test-for-scandir-on-all-file-systems-test.patch
     
    Comment 1
    1. Sebastian Huber, Thu, 28 Mar 2013 08:31:24 GMT
    2. cc: Sebastian Huber added
    3. milestone: 2 deleted
    Comment 2
    1. Sebastian Huber, Thu, 28 Mar 2013 09:30:17 GMT
    2. milestone: set to 4.11

    I just looked in the latest Newlib sources. The MAXNAMELEN vs. NAME_MAX problem still exists:

    ./newlib/libc/sys/rtems/sys/syslimits.h:#define NAME_MAX 255 /* max bytes in a file name */ ./newlib/libc/sys/rtems/sys/dirent.h: char d_name[NAME_MAX + 1];

    ./newlib/libc/include/dirent.h:#if !defined(MAXNAMLEN) && !defined(_POSIX_SOURCE) ./newlib/libc/include/dirent.h:#define MAXNAMLEN 1024

    0x0202acd0 in scandir (dirname=, namelist=0x203feb0, select=0x200149c , dcomp=0x0) at /home/sh/archive/gcc-4.6.3/newlib/libc/posix/scandir.c:117 117 p = (struct dirent *)malloc(DIRSIZ(d)); Value returned is $1 = 1 (gdb) s malloc (size=4294966555) at /home/sh/git-rtems/c/src/../../cpukit/libcsupport/src/malloc.c:33 33 MSBUMP(malloc_calls, 1);

    The psxtests/psxreaddir is quite sloppy since the scandir() return status is only printed:

    scandir status: -1

    Comment 3
    1. Gedare Bloom, Sun, 23 Nov 2014 16:06:57 GMT
    2. version: changed from unknown to 4.11
    3. description: modified (diff)
    Comment 4
    1. Joel Sherrill, Sun, 23 Nov 2014 16:11:19 GMT
    2. version: changed from 4.11 to 4.10

    This was reported in the 4.10 development cycle. 4.9 used newlib 1.16.0 and 4.10 used 1.18.0.

    Comment 5
    1. Gedare Bloom, Wed, 25 Feb 2015 19:07:53 GMT
    2. description: modified (diff)

    Attached patch should work but I haven't tested it yet.

    Comment 6
    1. Gedare Bloom, Tue, 03 Mar 2015 16:35:58 GMT

    I don't have a test case for this.

    Comment 7
    1. Gedare Bloom, Tue, 03 Mar 2015 21:45:18 GMT

    Further examination in newlib shows that this bug should no longer manifest itself. However, we might want to consider adding the tests and even upstreaming the patch for making the two defines match to avoid any future problems. I don't have a fix for 4.10.

    Comment 8
    1. Joel Sherrill, Wed, 04 Mar 2015 20:47:47 GMT

    Added new set of tests fsscandir01 in fstests for code shown in this PR.

    Comment 9
    1. Gedare Bloom, Wed, 04 Mar 2015 21:18:58 GMT
    2. milestone: changed from 4.11 to 4.10.3

    Move to 4.10.3 in case we want to provide a fix there. This problem is resolved in newlib already.

    Comment 10
    1. Sebastian Huber, Tue, 24 Jan 2017 09:08:54 GMT

    In 6af2221aac489acac54c2daaf9702a926ec1e263/rtems:

    fsscandir01: Check MAXNAMLEN and NAME_MAX Update #1394.
    Comment 11
    1. Sebastian Huber, Tue, 24 Jan 2017 09:09:31 GMT
    2. milestone: changed from 4.10.3 to 4.12

    ​https://sourceware.org/ml/newlib/2017/msg00077.html

    Comment 12
    1. Sebastian Huber, Wed, 25 Jan 2017 12:24:00 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Fix with next Newlib snapshot.

    Comment 13
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 14
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    1662 - termios.c: semaphore not deleted, consequently resulting in failure of rtems_termios_open

    Link https://devel.rtems.org/ticket/1662
    Id 1662
    Reporter Bharath Suri
    Created 9 August 2010 17:52:00
    Modified 5 February 2018 07:53:24
    Owner Chris Johns
    Type defect
    Component fs
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc joel.sherrill@… sebastian.huber@…
    Blocking  
    Blocked by  

    Description

    The semaphore osem is still in use in rtems_termios_close while an attempt to delete it is made and hence is not deleted.
    Consequently, it results in a RTEMS_TOO_MANY on rtems_semaphore_create, which further results in failure of rtems_termios_open.

    Attachments:

    1 Bharath Suri, Mon, 09 Aug 2010 18:00:52 GMT
      attach: set to libcsupport-changes.diff
     
    2 Bharath Suri, Mon, 09 Aug 2010 18:01:32 GMT
      attach: set to cpukit-ChangeLog-changes.txt
     
    3 Bharath Suri, Tue, 10 Aug 2010 18:09:00 GMT
      attach: set to termios01-init-changes.diff
     
    Comment 1
    1. Joel Sherrill, Mon, 09 Aug 2010 18:19:10 GMT
    2. cc: Joel Sherrill added
    Comment 2
    1. Joel Sherrill, Tue, 10 Aug 2010 16:57:32 GMT
    2. cc: Sebastian Huber added
    Comment 3
    1. Bharath Suri, Tue, 10 Aug 2010 18:17:07 GMT
    2. blocked: set to 1661
    Comment 4
    1. Bharath Suri, Wed, 11 Aug 2010 01:25:13 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 5
    1. Sebastian Huber, Wed, 11 Aug 2010 14:47:07 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted
    Comment 6
    1. Sebastian Huber, Thu, 12 Aug 2010 06:36:21 GMT

    Let me explain the problem with the clean up during the last close. The Termios driver is an example for a driver that will be opened by one thread, but the read and write access may be issued by different threads concurrently. The close may happen also concurrently (exit() may be called concurrently?). I think a concurrent call to close() will lead to more problems, so I omit this here. I think currently that the only way to avoid accesses to deleted resources is to not delete anything during the last close. Instead we should simply flush the output buffer.

    Comment 7
    1. Gedare Bloom, Mon, 24 Nov 2014 18:58:28 GMT
    2. version: changed from HEAD to 4.11

    Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11

    Comment 8
    1. Gedare Bloom, Fri, 19 Dec 2014 03:53:23 GMT
    2. description: modified (diff)
    3. milestone: changed from 4.11 to 4.11.1
    Comment 9
    1. Sebastian Huber, Thu, 26 Jan 2017 07:16:00 GMT
    2. milestone: changed from 4.11.1 to 4.11.2
    Comment 10
    1. Chris Johns, Thu, 23 Mar 2017 01:03:28 GMT
    2. milestone: changed from 4.11.2 to 4.11.3

    The 4.11.2 milestone is closing.

    Comment 11
    1. Chris Johns, Mon, 05 Feb 2018 05:55:12 GMT

    What should happen with this ticket?

    Comment 12
    1. Sebastian Huber, Mon, 05 Feb 2018 07:53:24 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed
    4. milestone: changed from 4.11.3 to 5.1

    Due to the reference counting of file descriptors (#3132) this problem no longer exists in RTEMS 5.1. If you close() a file descriptor which is still in use, you get an error (EBUSY).


    1747 - Heap extend allows discontinuous memory regions.

    Link https://devel.rtems.org/ticket/1747
    Id 1747
    Reporter Chris Johns
    Created 1 March 2011 01:16:43
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority low
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The check in (cpukit/ChangeLog) states:

    2010-06-07 Sebastian Huber

    • score/src/heapextend.c: Implemented support for scattered heap areas.

    The heap cannot support scattered blocks because the _Heap_Is_block_in_heap assumes the region is continuous between the first and last blocks of the heap. Making the gaps in the regions passed to the heap extend call used is questionable and makes the _Heap_Is_block_in_heap test not really perform the task it's name states. This is an issue because it is this check that determines if a heap free of NULL should proceed. This issue is covered in another PR.

    I also wonder about a heap free call to an address that maps to one of the "in-use" gap regions. The previous heap code knew if an address was in the heap and therefore it was kind of safe to probe for a valid block. This assumption is now not valid.

    The former heap extend code:

    http://www.rtems.org/viewvc/rtems/cpukit/score/src/heapextend.c?revision=1.7&view=markup

    clearly states the type of memory that can be added to an existing heap. The current code has no restrictions. The user manual is not great in this area. It would also be useful if comments are added to the heap extend code.

    The heap extend code is used by the rtems_region_extend call and this call clearly states in the manual that the memory region must be continuous. If this has changed we should discuss the API change and make better note of it. I also suspect the testsuite will need additions to test any API changes.

    Comment 1
    1. Sebastian Huber, Tue, 01 Mar 2011 07:46:28 GMT

    The support for scattered heap area does no harm for users of the continuous case. Only if you use the flexibility of a scattered heap area you have to life with a less effective _Heap_Is_block_in_heap() check.

    Comment 2
    1. Gedare Bloom, Mon, 24 Nov 2014 18:58:28 GMT
    2. version: changed from HEAD to 4.11

    Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11

    Comment 3
    1. Sebastian Huber, Thu, 27 Nov 2014 12:59:46 GMT
    2. description: modified (diff)

    Where in the documentation should this heap extension stuff be mentioned?

    Comment 4
    1. Sebastian Huber, Wed, 18 Feb 2015 14:37:17 GMT
    2. status: changed from new to accepted
    3. description: modified (diff)
    Comment 5
    1. Gedare Bloom, Mon, 02 Mar 2015 20:42:45 GMT
    2. milestone: changed from 4.11 to 4.11.1

    bump milestone

    Comment 6
    1. Sebastian Huber, Fri, 23 Dec 2016 14:10:53 GMT
    2. priority: changed from normal to low
    Comment 7
    1. Sebastian Huber, Thu, 26 Jan 2017 07:16:00 GMT
    2. milestone: changed from 4.11.1 to 4.11.2
    Comment 8
    1. Sebastian Huber, Fri, 27 Jan 2017 07:06:50 GMT

    In 4ea92d1ed11f0fc93d6b40729ebe7ec5c03d448e/rtems:

    score: Clarify _Heap_Extend() Update #1747.
    Comment 9
    1. Sebastian Huber, Fri, 27 Jan 2017 07:08:24 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed
    4. milestone: changed from 4.11.2 to 4.12

    [9889463c236f3445ef00a48d2e848e742860a130/rtems-docs]

    Comment 10
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 11
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    1971 - Memory leak in tmpfile()

    Link https://devel.rtems.org/ticket/1971
    Id 1971
    Reporter Andrey Mozzhuhin
    Created 24 November 2011 13:50:41
    Modified 12 February 2018 00:07:17
    Owner Chris Johns
    Type defect
    Component fs
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc joel.sherrill@… sebastian.huber@… gedare@…
    Blocking  
    Blocked by  

    Description

    Hello,

    I use tmpfile() in my RTEMS application, and found that it has memory leak.
    I wrote small test application (see attachment), that output memory usage:

    Memory usage before:
    Number of used blocks: 12
    Largest used block: 1288
    Total bytes used: 3628

    Memory used after:
    Number of used blocks: 1013
    Largest used block: 1288
    Total bytes used: 112064

    By 1000 iteration, each call tmpfile() cause memory leak about 108 bytes.

    Attachments:

    1 Andrey Mozzhuhin, Thu, 24 Nov 2011 13:50:41 GMT
      attach: set to init.c
     
    Comment 1
    1. Gedare Bloom, Fri, 11 Apr 2014 19:33:28 GMT
    2. status: changed from new to closed, gedare@rtems.org
    3. resolution: set to fixed
    Comment 2
    1. Sebastian Huber, Mon, 14 Apr 2014 06:02:01 GMT
    2. status: changed from closed to reopened, sebastian.huber@embedded-brains.de
    3. resolution: fixed deleted
    4. milestone: changed from 4.11 to 4.12
    Comment 3
    1. Joel Sherrill, Mon, 14 Apr 2014 15:37:59 GMT
    2. cc: Joel Sherrill added
    Comment 4
    1. Andrey Mozzhuhin, Wed, 16 Apr 2014 05:21:26 GMT

    I think real memory leak was fixed. How we can see in first memory trace after 1000 tmpfile() was allocated 1000+1 block. In Gedare memory trace after test was allocated 1 block. This block probably allocated at first tmpfile() for some initialization.

    I can try to find out this 1 block allocation and write test but it can take a long time.

    Not for license wars, this attached application is too simple to licensing and can be written by any RTEMS developer. Nonetheless, formalities for I give all rights on attached test application to Joel Sherrill.

    Comment 5
    1. Chris Johns, Thu, 20 Nov 2014 03:27:43 GMT
    2. description: modified (diff)
    3. milestone: changed from 4.12 to 4.11
    Comment 6
    1. Gedare Bloom, Fri, 19 Dec 2014 04:38:14 GMT
    2. milestone: changed from 4.11 to 4.11.1

    Bump milestone to 4.11.1 in case no patch exists and PR seems delayable.

    Comment 7
    1. Sebastian Huber, Thu, 26 Jan 2017 07:16:00 GMT
    2. milestone: changed from 4.11.1 to 4.11.2
    Comment 8
    1. Chris Johns, Thu, 23 Mar 2017 01:03:28 GMT
    2. milestone: changed from 4.11.2 to 4.11.3

    The 4.11.2 milestone is closing.

    Comment 9
    1. Chris Johns, Thu, 23 Mar 2017 01:05:42 GMT
    2. version: changed from 4.10 to 4.11

    Move to the 4.11 branch.

    Comment 10
    1. Chris Johns, Mon, 05 Feb 2018 05:56:05 GMT
    2. description: modified (diff)

    What should happen with this ticket?

    Comment 11
    1. Sebastian Huber, Mon, 05 Feb 2018 08:32:00 GMT
    2. milestone: changed from 4.11.3 to 5.1
    Comment 12
    1. Sebastian Huber, Mon, 05 Feb 2018 08:32:32 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    In 4ac5ffbb/rtems:

    fsclose01: Add tmpfile() test case Close #1971.
    Comment 13
    1. Sebastian Huber, Fri, 09 Feb 2018 12:15:21 GMT

    In 48aa4b5d/rtems:

    fsclose01: Use floating-point task The tmpfile() uses sprintf(). Update #1971.
    Comment 14
    1. Sebastian Huber, Fri, 09 Feb 2018 12:18:32 GMT

    In a3eec5c/rtems:

    fsclose01: Fix task mode, use attribute Update #1971.
    Comment 15
    1. Chris Johns, Mon, 12 Feb 2018 00:07:17 GMT

    The version and milestone for this ticket do not match.


    2132 - <rtems/score/basedefs.h> superfluously includes <limits.h>

    Link https://devel.rtems.org/ticket/2132
    Id 2132
    Reporter Sebastian Huber
    Created 22 July 2013 14:36:54
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority low
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In older RTEMS versions provided indirectly. The include of was added to not break application source files that relied on this accidentally.

    We may remove this include in the future.

    Comment 1
    1. Sebastian Huber, Mon, 22 Jul 2013 14:36:54 GMT

    In older RTEMS versions provided indirectly. The include of was added to not break application source files that relied on this accidentally.

    We may remove this include in the future.

    Comment 2
    1. Joel Sherrill, Sat, 22 Nov 2014 16:10:47 GMT
    2. owner: changed from Joel Sherrill to Sebastian Huber
    3. status: changed from new to assigned
    4. description: modified (diff)

    Sebastian .. is this still valid? What do you want to do?

    Comment 3
    1. Sebastian Huber, Mon, 24 Nov 2014 07:52:18 GMT
    2. milestone: changed from 4.11 to 5.0
    Comment 4
    1. Gedare Bloom, Mon, 24 Nov 2014 18:58:28 GMT
    2. version: changed from HEAD to 4.11

    Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11

    Comment 5
    1. Sebastian Huber, Wed, 18 Feb 2015 14:39:52 GMT
    2. status: changed from assigned to accepted
    3. description: modified (diff)
    Comment 6
    1. Sebastian Huber, Fri, 23 Dec 2016 14:10:53 GMT
    2. priority: changed from normal to low
    Comment 7
    1. Sebastian Huber, Fri, 25 Aug 2017 10:54:09 GMT
    2. version: 4.11 deleted
    3. milestone: changed from 5.0 to 4.12.0
    Comment 8
    1. Sebastian Huber, Fri, 25 Aug 2017 10:54:09 GMT

    In 1f22b26/rtems:

    Include missing Update #2132.
    Comment 9
    1. Sebastian Huber, Fri, 25 Aug 2017 10:54:59 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In cfa7afd/rtems:

    score: Remove include from basedefs.h Close #2132.
    Comment 10
    1. Sebastian Huber, Fri, 25 Aug 2017 12:24:08 GMT

    In 666a568/rtems-libbsd:

    Include missing and Fix warnings. Update #2132. Update #2133.
    Comment 11
    1. Sebastian Huber, Fri, 25 Aug 2017 12:40:14 GMT

    In 02b007e/rtems:

    Include missing Update #2132.
    Comment 12
    1. Sebastian Huber, Tue, 19 Sep 2017 08:57:49 GMT

    In 9a50e32/rtems:

    score: Include missing Update #2132. Close #3140.
    Comment 13
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2133 - <rtems/score/basedefs.h> superfluously includes <string.h>

    Link https://devel.rtems.org/ticket/2133
    Id 2133
    Reporter Sebastian Huber
    Created 23 July 2013 10:28:30
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In older RTEMS versions provided indirectly. The include
    of was added to not break application source files that relied on
    this accidentally.

    We may remove this include in the future.

    Comment 1
    1. Sebastian Huber, Tue, 23 Jul 2013 10:28:30 GMT

    In older RTEMS versions provided indirectly. The include of was added to not break application source files that relied on this accidentally.

    We may remove this include in the future.

    Comment 2
    1. Joel Sherrill, Sun, 23 Nov 2014 16:45:56 GMT
    2. description: modified (diff)

    Can this be closed? The ticket is a warning about a change to basedefs.h and the comment makes no sense.

    Comment 3
    1. Gedare Bloom, Mon, 24 Nov 2014 18:58:28 GMT
    2. version: changed from HEAD to 4.11

    Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11

    Comment 4
    1. Sebastian Huber, Thu, 27 Nov 2014 13:50:45 GMT
    2. milestone: changed from 4.11 to 5.0
    Comment 5
    1. Joel Sherrill, Thu, 27 Nov 2014 14:47:36 GMT

    Out of curiosity, why shouldn't we just remove these includes now? There is no way to warn a user at compile time that they will be impacted. All we are doing is delaying the inevitable random number of users who are impacted. Hopefully that number is higher in the future than now.

    My proposal is:

    + make a announcement to users@ and devel@ that these includes were removed and any

    code that unintentionally depended on them will have compile errors or warnings. This will serve as a hit in Google.

    + Remove it and see what tests break. Make sure the commits for those issues include

    enough information in the log so Google will see those as related.

    Break and move forward.

    Comment 6
    1. Amar Takhar, Thu, 27 Nov 2014 14:49:14 GMT

    Replying to joel.sherrill:

    Out of curiosity, why shouldn't we just remove these includes now? There is no way to warn a user at compile time that they will be impacted. All we are doing is delaying the inevitable random number of users who are impacted. Hopefully that number is higher in the future than now.

    All of these are moving in 5.0 anyway why bother moving it now when it works? I don't disagree with your reasoning but closing milestone:4.11 would be nice!

    Comment 7
    1. Sebastian Huber, Thu, 27 Nov 2014 15:02:35 GMT

    At the time I created the *impl.h header files, a lot of stuff broke due to the now missing indirect include. I guess this is also true for application code. Especially . Maybe this include is a feature not a bug.

    Comment 8
    1. Joel Sherrill, Thu, 27 Nov 2014 15:32:18 GMT

    I agree on closing milestone 4.11 but this isn't the long pole in the tent. If we want to just get this behind us, let's do it. No point putting it off.

    Comment 9
    1. Sebastian Huber, Thu, 27 Nov 2014 15:45:08 GMT

    We still have the option to set this to WONTFIX and close it forever.

    Comment 10
    1. Chris Johns, Sun, 13 Aug 2017 23:55:42 GMT
    2. description: modified (diff)
    3. milestone: changed from 5.0 to 4.11.3

    Please fix or close this ticket? Thanks.

    Comment 11
    1. Sebastian Huber, Thu, 24 Aug 2017 10:47:31 GMT
    2. owner: changed from Joel Sherrill to Sebastian Huber
    3. status: changed from new to accepted
    Comment 12
    1. Joel Sherrill, Thu, 24 Aug 2017 16:15:12 GMT

    I don't think the milestone should be 4.11.3. At this point, this would break the contract for users on a release branch. I think the milestone should be 4.12 and this fixed.

    Comment 13
    1. Sebastian Huber, Fri, 25 Aug 2017 06:32:41 GMT
    2. version: 4.11 deleted
    3. milestone: changed from 4.11.3 to 4.12.0
    Comment 14
    1. Sebastian Huber, Fri, 25 Aug 2017 10:53:56 GMT

    In b2ed712/rtems:

    Include missing Update #2133.
    Comment 15
    1. Sebastian Huber, Fri, 25 Aug 2017 10:54:35 GMT

    In 76b9c31/rtems:

    libpci: Use calloc() Update #2133.
    Comment 16
    1. Sebastian Huber, Fri, 25 Aug 2017 10:55:11 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 163ff8e/rtems:

    score: Remove include from basedefs.h Close #2133.
    Comment 17
    1. Sebastian Huber, Fri, 25 Aug 2017 12:24:08 GMT

    In 666a568/rtems-libbsd:

    Include missing and Fix warnings. Update #2132. Update #2133.
    Comment 18
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2135 - times() and _times() are subject to integer overflows

    Link https://devel.rtems.org/ticket/2135
    Id 2135
    Reporter Sebastian Huber
    Created 30 July 2013 07:06:13
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority low
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The clock_t type is defined as unsigned long for RTEMS in Newlib. With a 1ms clock tick an overflow happens after 7 days on 32-bit long targets.

    Comment 1
    1. Joel Sherrill, Tue, 30 Jul 2013 13:19:19 GMT

    Replying to comment:1:

    Replying to comment:0:

    The clock_t type is defined as unsigned long for RTEMS in Newlib. With a 1ms clock tick an overflow happens after 7 days on 32-bit long targets.

    I mean 7 weeks.

    CentOS 6.4 has this has clock_t as clock_t which appears to be a long int. So no better.

    Comment 2
    1. Gedare Bloom, Mon, 24 Nov 2014 18:58:28 GMT
    2. version: changed from HEAD to 4.11

    Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11

    Comment 3
    1. Sebastian Huber, Thu, 18 Dec 2014 12:29:27 GMT
    2. priority: changed from normal to low
    3. milestone: changed from 4.11 to 5.0
    Comment 4
    1. Chris Johns, Mon, 14 Aug 2017 00:41:59 GMT
    2. version: changed from 4.11 to 4.12
    3. milestone: changed from 5.0 to 4.12.0

    Moving to 4.12.0. Please update and move if this is not valid.

    Comment 5
    1. Sebastian Huber, Thu, 24 Aug 2017 06:55:23 GMT

    This should change to at least 64-bit just like time_t.

    Comment 6
    1. Sebastian Huber, Fri, 25 Aug 2017 12:37:43 GMT

    In 4f364ef/rtems-source-builder:

    4.12: Change clock_t to 64-bit Update #2135. Update #3111.
    Comment 7
    1. Sebastian Huber, Fri, 25 Aug 2017 13:37:31 GMT
    2. owner: changed from Joel Sherrill to Sebastian Huber
    3. status: changed from new to accepted
    Comment 8
    1. Sebastian Huber, Wed, 06 Sep 2017 05:43:52 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 731e68a3/rtems:

    Fix integer overflow problems in times() An integer overflow may still happen, however, only after 68 years of system uptime. Close #2135.
    Comment 9
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 10
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2173 - Potential integer overflow problem in EDF scheduler

    Link https://devel.rtems.org/ticket/2173
    Id 2173
    Reporter Sebastian Huber
    Created 24 March 2014 06:06:34
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    On 2014-03-21 14:46, Gedare Bloom wrote:> On Fri, Mar 21, 2014 at 9:43 AM, Sebastian Huber

    wrote:

    [...]

    I have another question regarding the EDF scheduler. Does this work in case
    _Watchdog_Ticks_since_boot overflows?

    No. For this, I think we need to use "deadline folding" which is just
    modulo arithmetic.

    void _Scheduler_EDF_Release_job(

    Thread_Control *the_thread,
    uint32_t deadline

    )
    {

    Priority_Control new_priority;

    if (deadline) {

    /* Initializing or shifting deadline. */
    new_priority = (_Watchdog_Ticks_since_boot + deadline)

    & ~SCHEDULER_EDF_PRIO_MSB;

    }
    else {

    /* Switch back to background priority. */
    new_priority = the_thread->Start.initial_priority;

    }

    the_thread->real_priority = new_priority;
    _Thread_Change_priority(the_thread, new_priority, true);

    }

    _Watchdog_Ticks_since_boot us uint32_t and overflows after 49 days with a one millisecond clock tick.

    Comment 1
    1. Sebastian Huber, Mon, 24 Mar 2014 06:06:34 GMT

    On 2014-03-21 14:46, Gedare Bloom wrote:> On Fri, Mar 21, 2014 at 9:43 AM, Sebastian Huber

    wrote:

    [...]

    I have another question regarding the EDF scheduler. Does this work in case _Watchdog_Ticks_since_boot overflows?

    No. For this, I think we need to use "deadline folding" which is just modulo arithmetic.

    void _Scheduler_EDF_Release_job(

    Thread_Control *the_thread, uint32_t deadline

    ) {

    Priority_Control new_priority;

    if (deadline) {

    /* Initializing or shifting deadline. */ new_priority = (_Watchdog_Ticks_since_boot + deadline)

    & ~SCHEDULER_EDF_PRIO_MSB;

    } else {

    /* Switch back to background priority. */ new_priority = the_thread->Start.initial_priority;

    }

    the_thread->real_priority = new_priority; _Thread_Change_priority(the_thread, new_priority, true);

    }

    _Watchdog_Ticks_since_boot us uint32_t and overflows after 49 days with a one millisecond clock tick.

    Comment 2
    1. Joel Sherrill, Sun, 23 Nov 2014 16:26:56 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix
    4. description: modified (diff)

    Sebastian noted this was a hardware problem. Seems to indicate problem is NA now.

    Comment 3
    1. Sebastian Huber, Mon, 24 Nov 2014 07:28:07 GMT
    2. status: changed from closed to reopened
    3. resolution: wontfix deleted

    Actually the Bugzilla to trac conversion seems to have a lot of errors.

    This was not a hardware problem. This is still an open issue.

    Without much consideration I would fix it like this:

    Make the tick since boot uint64_t. Make the Thread_Control::current_priority and Thread_Control::real_priority int64_t (to support easy comparison operations for RB tree insert and search). Remove the Scheduler_Operations::priority_compare operation.

    With a system tick of 1ns the system can run 146years before something overflows.

    Comment 4
    1. Gedare Bloom, Mon, 24 Nov 2014 18:58:28 GMT
    2. version: changed from HEAD to 4.11

    Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11

    Comment 5
    1. Joel Sherrill, Mon, 24 Nov 2014 19:35:19 GMT

    The EDF scheduler should NOT use priority to store the deadline. That is one issue and it shows itself by bogus values being returned when you obtain the current priority. So #2 is __NOT__ acceptable to me. The EDF scheduler should use its own internal stored value to sort the threads.

    Why can't the scheduler use uptime and not ticks since boot?

    The EDF scheduler is broken in assuming it can rewrite a thread priority with a deadline.

    Comment 6
    1. Gedare Bloom, Mon, 24 Nov 2014 19:44:23 GMT

    Why not rewrite thread (current) priority?

    Priority should be an opaque notion of a scheduler in general, which should export information needed for synchronization modules (locks) to implement PI/PC protocols. The priority of a thread being scheduled according to EDF increases (toward 0) as its deadline draws closer.

    That said, I'm not opposed to putting the absolute deadline into the scheduler-specific portion of the TCB. I just don't understand the strong negative reaction to letting the scheduler determine what priority means.

    Comment 7
    1. Gedare Bloom, Mon, 02 Mar 2015 20:42:45 GMT
    2. milestone: changed from 4.11 to 4.11.1

    bump milestone

    Comment 8
    1. Sebastian Huber, Wed, 22 Jun 2016 12:47:47 GMT

    In 77ff5599e0d8e6d91190a379be21a332f83252b0/rtems:

    score: Introduce map priority scheduler operation Introduce map/unmap priority scheduler operations to map thread priority values from/to the user domain to/from the scheduler domain. Use the map priority operation to validate the thread priority. The EDF schedulers use this new operation to distinguish between normal priorities and priorities obtain through a job release. Update #2173. Update #2556.
    Comment 9
    1. Sebastian Huber, Wed, 22 Jun 2016 12:47:57 GMT

    In 7ec66e0890c65f3fdfed9db91a4ae59de6a8ff18/rtems:

    score: Remove hidden deadline overrule for CBS Do what the user commands. Maybe we should add a rtems_cbs_period() that calls rtems_rate_monotonic_period() with the right parameter. Update #2173.
    Comment 10
    1. Sebastian Huber, Wed, 22 Jun 2016 12:48:06 GMT

    In 9a78f8a5076687a8744991998ee6119f87db12a8/rtems:

    score: Modify release job scheduler operation Pass the deadline in watchdog ticks to the scheduler. Update #2173.
    Comment 11
    1. Sebastian Huber, Wed, 22 Jun 2016 12:48:16 GMT

    In 99fc1d1d1b44e70a0bed4c94a514bd3f3b5df64f/rtems:

    score: Rework EDF scheduler Use inline red-black tree insert. Do not use shifting priorities since this is not supported by the thread queues. Due to the 32-bit Priority_Control this currently limits the uptime to 49days with a 1ms clock tick. Update #2173.
    Comment 12
    1. Sebastian Huber, Thu, 26 Jan 2017 07:16:00 GMT
    2. milestone: changed from 4.11.1 to 4.11.2
    Comment 13
    1. Sebastian Huber, Tue, 31 Jan 2017 09:18:55 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed
    4. description: modified (diff)
    5. milestone: changed from 4.11.2 to 4.12
    Comment 14
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 15
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2176 - fishy behavior in termios tx task mode

    Link https://devel.rtems.org/ticket/2176
    Id 2176
    Reporter Jeffrey Hill
    Created 15 April 2014 16:38:51
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type defect
    Component score
    Status closed
    Resolution wontfix
    Version  
    Milestone 5.1
    Priority low
    Severity normal
    Keywords  
    Cc sebastian.huber@…
    Blocking  
    Blocked by  

    Description

    I have a look around in the drivers in the various BSPs and I notice that none of the termios drivers appear to transmit characters at task level even if they are running in termios task mode. Maybe all (most) of them send characters in the ISR. If there was a large frame of characters to send then this could lock out task activity for too long.

    FWIW, I had a closer look at this today, and maybe something is fishy in the termios code when the TX part of termios runs in task driven mode. It seems that in task mode if the UART can accept characters immediately in the write routine then we wouldn’t need to turn on any interrupts at all. The write routine would need to somehow tell termios how many characters it sent; presumably this would occur by calling rtems_termios_dequeue_characters in the driver's write function. I see in the code that this tries to work, rtems_termios_dequeue_characters posts the semaphore of termios tx and increases the characters sent count of termios. However after the write routine returns it goes badly.

    If the transmitter runs in termios TASK mode and the driver's write routine does not immediately enable an interrupt, then it returns to the code below in rtems_termios_puts and it sets the transmitter to rob_busy. After that the termios tx daemon proceeds to step through all of the characters remaining (I think that I see this in the debugger) and discards them because the transmitter stays in rob_busy state.

    It's also probably odd that termios calls the write function with interrupts disabled when it is in task driven mode; we could loop outputting a large frame of characters in the write routine at task level with interrupts globally disabled.

    if (tty->rawOutBufState == rob_idle) {

    /* check, whether XOFF has been received */
    if (!(tty->flow_ctrl & FL_ORCVXOF)) {

    (*tty->device.write)(tty->minor,

    (char *)&tty->rawOutBuf.theBuf[tty->rawOutBuf.Tail],1);

    }
    else {

    /* remember that output has been stopped due to flow ctrl*/
    tty->flow_ctrl |= FL_OSTOP;

    }
    tty->rawOutBufState = rob_busy;

    }

    [debug]#0 rtems_termios_puts (_buf=0x9ca60, len=1, tty=0x11509c) at /home/hill/nios2-rtems/rtems/rtems-git/rtems-4.10/c/src/../../cpukit/libcsupport/src/termios.c:677
    [debug]#1 0x00015c68 in oproc (c=99 'c', tty=0x11509c) at /home/hill/nios2-rtems/rtems/rtems-git/rtems-4.10/c/src/../../cpukit/libcsupport/src/termios.c:748
    [debug]#2 0x00015d9c in rtems_termios_write (arg=0x9cad8) at /home/hill/nios2-rtems/rtems/rtems-git/rtems-4.10/c/src/../../cpukit/libcsupport/src/termios.c:770
    [debug]#3 0x00002ef0 in console_write (major=0, minor=0, arg=0x9cad8) at /home/hill/nios2-rtems/rtems/rtems-git/rtems-4.10/c/src/lib/libbsp/nios2/altera-sys-config/./console/console.c:171
    [debug]#4 0x0006c328 in rtems_io_write (major=0, minor=0, argument=0x9cad8) at /home/hill/nios2-rtems/rtems/rtems-git/rtems-4.10/c/src/../../cpukit/sapi/src/iowrite.c:47
    [debug]#5 0x00068044 in device_write (iop=0x114988, buffer=0x3366d4, count=44) at /home/hill/nios2-rtems/rtems/rtems-git/rtems-4.10/c/src/../../cpukit/libfs/src/imfs/deviceio.c:160
    [debug]#6 0x00017ef4 in write (fd=1, buffer=0x3366d4, count=44) at /home/hill/nios2-rtems/rtems/rtems-git/rtems-4.10/c/src/../../cpukit/libcsupport/src/write.c:51
    [debug]#7 0x0007f078 in _write_r (ptr=0x9d638, fd=1, buf=0x3366d4, nbytes=44) at /home/hill/nios2-rtems/rtems/rtems-git/rtems-4.10/c/src/../../cpukit/libcsupport/src/write_r.c:38
    [debug]#8 0x0006d488 in _fflush_r (ptr=0x9d638, fp=0x9d98c) at ../../../../../../nios2-rtems/altera/altera11.0/gnu-tools/rtems-patched/gcc-4.1/newlib/libc/stdio/fflush.c:214
    [debug]#9 0x000754e8 in sfvwrite_r (ptr=0x9d638, fp=0x9d98c, uio=0x9cbe0) at ../../../../../../nios2-rtems/altera/altera11.0/gnu-tools/rtems-patched/gcc-4.1/newlib/libc/stdio/fvwrite.c:257
    [debug]#10 0x0007830c in sprint_r (ptr=0x9d638, fp=0x20, uio=0x9cbe0) at ../../../../../../nios2-rtems/altera/altera11.0/gnu-tools/rtems-patched/gcc-4.1/newlib/libc/stdio/vfprintf.c:322
    [debug]#11 0x00072fc8 in _vfprintf_r (data=0x9d638, fp=0x9d98c, fmt0=, ap=0x0) at ../../../../../../nios2-rtems/altera/altera11.0/gnu-tools/rtems-patched/gcc-4.1/newlib/libc/stdio/vfprintf.c:1501
    [debug]#12 0x0006dce8 in printf (fmt=0x1 "") at ../../../../../../nios2-rtems/altera/altera11.0/gnu-tools/rtems-patched/gcc-4.1/newlib/libc/stdio/printf.c:52
    [debug]#13 0x00057de0 in bootpc_init (update_files=false, forever=true) at /home/hill/nios2-rtems/rtems/rtems-git/rtems-4.10/c/src/../../cpukit/libnetworking/nfs/bootp_subr.c:997
    [debug]#14 0x0002960c in rtems_bsdnet_do_bootp () at /home/hill/nios2-rtems/rtems/rtems-git/rtems-4.10/c/src/../../cpukit/libnetworking/rtems/rtems_bootp.c:23
    [debug]#15 0x0002b218 in rtems_bsdnet_initialize_network () at /home/hill/nios2-rtems/rtems/rtems-git/rtems-4.10/c/src/../../cpukit/libnetworking/rtems/rtems_glue.c:980
    [debug]#16 0x00001528 in Init (ignored=565432) at init.c:47
    [debug]#17 0x0006ccb0 in _Thread_Handler () at /home/hill/nios2-rtems/rtems/rtems-git/rtems-4.10/c/src/../../cpukit/score/src/threadhandler.c:145
    [debug]#18 0x0006cc28 in _Thread_Is_heir (the_thread=0x6cc28) at ../../cpukit/../../../altera-sys-config/lib/include/rtems/score/thread.inl:82
    [debug]Backtrace stopped: frame did not save the PC

    Comment 1
    1. Sebastian Huber, Thu, 17 Apr 2014 05:22:35 GMT
    2. cc: Sebastian Huber added

    Yes, the interrupt support for Termios is broken if you ask me. It is very unlikely that we will see an improvement here unless someone gets a budget for this.

    Comment 2
    1. Sebastian Huber, Thu, 18 Dec 2014 12:35:42 GMT
    2. priority: changed from normal to low
    3. description: modified (diff)
    4. milestone: changed from 4.11 to 5.0
    Comment 3
    1. Sebastian Huber, Wed, 01 Feb 2017 06:16:37 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    Termios supports now a TERMIOS_IRQ_SERVER_DRIVEN mode, see #2839.

    Comment 4
    1. Sebastian Huber, Wed, 01 Feb 2017 06:16:50 GMT
    2. version: 4.10 deleted
    3. milestone: changed from 5.0 to 4.12
    Comment 5
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2198 - Automate doxygen build

    Link https://devel.rtems.org/ticket/2198
    Id 2198
    Reporter Gedare Bloom
    Created 21 November 2014 19:20:28
    Modified 15 June 2018 00:22:17
    Owner Chris Johns
    Type infra
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity blocker
    Keywords migration
    Cc Sebastian Huber
    Blocking  
    Blocked by  

    Description

    The doxygen builds are no longer being generated nightly.

    Comment 1
    1. Amar Takhar, Sun, 07 Dec 2014 22:31:33 GMT
    2. keywords: migration added
    Comment 2
    1. Amar Takhar, Fri, 06 Mar 2015 16:15:58 GMT
    2. milestone: changed from 4.11 to 4.11.1

    Docs have been built but are not updating automatically. I will re-generate this once we cut milestone:4.11 as part of the Release checklist.

    Comment 3
    1. Joel Sherrill, Tue, 09 Jun 2015 19:05:03 GMT
    2. cc: Sebastian Huber added

    Ping

    Comment 4
    1. Amar Takhar, Tue, 09 Jun 2015 19:46:10 GMT

    The milestone is set for 4.11.1. I'll try to get it done sooner I just don't know. I can re-run it again today if that is good enough.

    Comment 5
    1. Joel Sherrill, Fri, 13 Jan 2017 22:30:44 GMT
    2. owner: changed from Amar Takhar to Chris Johns
    3. status: changed from new to assigned
    Comment 6
    1. Joel Sherrill, Fri, 13 Jan 2017 22:34:55 GMT
    2. component: changed from admin to Documentation
    Comment 7
    1. Sebastian Huber, Thu, 26 Jan 2017 07:16:00 GMT
    2. milestone: changed from 4.11.1 to 4.11.2
    Comment 8
    1. Chris Johns, Thu, 23 Mar 2017 01:01:56 GMT
    2. version: changed from 4.11 to 4.12
    3. milestone: changed from 4.11.2 to 4.12

    This ticket should be on master.

    Comment 9
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 10
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 11
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 12
    1. Chris Johns, Fri, 15 Jun 2018 00:22:17 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Online here ​https://docs.rtems.org/doxygen/branches/master/


    2207 - RTEMS tar does not overwrite.

    Link https://devel.rtems.org/ticket/2207
    Id 2207
    Reporter Chris Johns
    Created 3 December 2014 00:31:37
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority low
    Severity normal
    Keywords tar
    Cc  
    Blocking  
    Blocked by  

    Description

    A host tar by default will overwrite the contents of a directory. A sort of refresh. The RTEMS tar requires you remove the existing files rather than overwrite. This is dangerous because you have to remove files yet you do not know if the tar will be successful and moving and saving files assumes you know the contents of the tar file before hand.

    Tar should be changed to overwrite and so allow files to be refreshed.

    Consistence of files should be managed outside of tar via hashes or checksums.

    Comment 1
    1. Chris Johns, Wed, 03 Dec 2014 10:15:43 GMT

    Running some tests wth tar on MacOS I see tar updates by removing files before outputting the new file. The example shown chowns x1/d1 to root while x1/d1/f1 is still owned by me:

    $ tar xf z1.tar x1/d1/: Can't update time for x1/d1 x1/d1/f2: Can't unlink already-existing object tar: Error exit delayed from previous errors.

    Looks like a delete tree needs to be added.

    Comment 2
    1. Sebastian Huber, Thu, 18 Dec 2014 09:12:11 GMT
    2. priority: changed from highest to low
    3. milestone: changed from 4.11 to 5.0
    Comment 3
    1. Chris Johns, Sat, 04 Jun 2016 00:11:31 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In d84e346b26017f021c1a7d5c8ad078c7264240ab/rtems:

    libmisc/untar: Support directory create and overwrites. Share the common code. Support creating directories for files with a path depth greater than 1. Some tar files can have files with a path depth greater than 1 and no directory entry in the tar file to create a directory. Support overwriting existing files and directories failing in a similar way to tar on common hosts. If a file is replaced with a file delete the file and create a new file. If a directory replaces a file remove the file and create the directory. If a file replaces a directory remove the directory, and if the directory is not empty and cannot be removed report an error. If a directory alreday exists do nothing leaving the contents untouched. The untar code now shares the common header parsing and initial processing with the actual writes still separate. No changes to the IMFS have been made. Updates #2415. Closes #2207.
    Comment 4
    1. Sebastian Huber, Thu, 05 Oct 2017 08:33:00 GMT
    2. milestone: changed from 5.0 to 4.12.0
    Comment 5
    1. Sebastian Huber, Tue, 10 Oct 2017 06:35:44 GMT
    2. component: changed from misc to unspecified
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2213 - Decreased performance for whetstone benchmark using GCC >=4.5

    Link https://devel.rtems.org/ticket/2213
    Id 2213
    Reporter daniel.cederman
    Created 9 December 2014 10:07:33
    Modified 9 November 2017 06:27:14
    Owner Daniel Hellstrom
    Type defect
    Component tool/gcc
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Moving from GCC 4.4.2 to 4.9.2 increases the execution time of the whetstone benchmark on both SPARC and x86. The cause seems to be a single commit. I have submitted a bug report to the GCC bugzilla:

    ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64193

    Comment 1
    1. Joel Sherrill, Thu, 22 Jan 2015 15:15:04 GMT

    Daniel.. did this get resolved? I recall discussions.

    Comment 2
    1. daniel.cederman, Fri, 23 Jan 2015 09:43:41 GMT

    Richard Biener provided a patch that fixed it on trunk. It looks like it could be easy to backport, but I have not had time to test it yet.

    Comment 3
    1. Gedare Bloom, Mon, 02 Mar 2015 20:48:06 GMT
    2. milestone: changed from 4.11 to 4.11.1
    Comment 4
    1. Sebastian Huber, Mon, 23 Jan 2017 13:47:53 GMT
    2. owner: set to Needs Funding
    3. status: changed from new to assigned

    How is the performance on GCC 6 or 7?

    Comment 5
    1. Sebastian Huber, Mon, 23 Jan 2017 13:48:08 GMT
    2. owner: changed from Needs Funding to Daniel Hellstrom
    Comment 6
    1. daniel.cederman, Mon, 23 Jan 2017 14:53:23 GMT

    A quick test shows that the performance for GCC 7 is about the same as for GCC 4.4.6.

    GCC 4.4.6 => ~52 seconds GCC 4.9.4 => ~55 seconds GCC 7.0.0 (master at 20170116) => ~52 seconds Compiled with -O3 and -mcpu=leon3.

    Comment 7
    1. Sebastian Huber, Mon, 23 Jan 2017 14:55:31 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    4. milestone: changed from 4.11.1 to 4.12

    Fixed in RTEMS 4.12, no plans to fix this in RTEMS 4.11.

    Comment 8
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 9
    1. Sebastian Huber, Tue, 10 Oct 2017 05:58:26 GMT
    2. component: changed from GCC to tool/gcc
    Comment 10
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2261 - Add coverage report generation support to rtems-tools

    Link https://devel.rtems.org/ticket/2261
    Id 2261
    Reporter Joel Sherrill
    Created 11 February 2015 15:42:52
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This ticket is to capture the current state of the project started by
    Krzysztof Mięsowicz . The goals of the project were to:

    • replace the existing shell scripts in rtems-testing with Python code integrated into rtems-tools
    • add the capability to generate a report per directory. This is important because a large body of code with low coverage negatively impacts the overall coverage area and makes reports harder to read. Breaking the reports down by functional area lets us do coverage reporting on more code even when some of the areas are in need of testing improvement.

    The remaining effort in conjunction with other activity related to coverage such as inclusion of gcov generated reports is a good "summer of code" type project. This is an important capability to add to the rtems-tools.

    The attached tar file krzy-patches.tar.bz2 contains the current code. There may be other issues to resolve but writing from memory, the following are the highest priority ones:

    • no default setting for coverage enable/disable
    • configuration file has hard coded paths. This should be able to be a template which is adjusted by the tools at run-time.
    • variable naming and coding style does not match that used in other Python code in rtems-tools

    Krzysztof wrote some in his blog about this (​http://kmiesowicz.blogspot.com/p/esa-socis-2014.html). Ensure that your base RTEMS tools are built with the RTEMS Source Builder and check on the development list if it builds a qemu with coverage support. This may have changed since he blogged.

    Attachments:

    1 Joel Sherrill, Wed, 11 Feb 2015 15:43:33 GMT
      attach: set to krzy-patches.tar.bz2
     
    Comment 1
    1. Joel Sherrill, Wed, 11 Feb 2015 15:46:37 GMT
    2. description: modified (diff)
    Comment 2
    1. Joel Sherrill, Wed, 11 Feb 2015 17:55:01 GMT
    2. milestone: set to 5.0
    Comment 3
    1. Amar Takhar, Wed, 11 Feb 2015 18:06:46 GMT

    I think this should be added into the waf build rather than kept separately. The test suite is inside RTEMS it seems natural everything needed for coverage reporting is there too.

    I know this requires modified tools -- RSB can build the tools the rest should go into waf.

    Comment 4
    1. Chris Johns, Sun, 13 Aug 2017 23:52:30 GMT
    2. version: changed from 4.11 to 4.12
    3. milestone: changed from 5.0 to 4.12.0

    Moving to 4.12.0 as a milestone. The ticket can be updated once this years GSoC project wraps up.

    Comment 5
    1. Joel Sherrill, Thu, 12 Oct 2017 02:51:36 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    All code is now merged after GSoC.

    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2266 - Move bsp_pretasking_hook() into files named bsppretaskinghook.c

    Link https://devel.rtems.org/ticket/2266
    Id 2266
    Reporter Joel Sherrill
    Created 13 February 2015 20:27:26
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component unspecified
    Status closed
    Resolution invalid
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Over the past few years, we have split out the BSP required methods into their own files with consistent names. bsp_pretasking_hook() is next on the list.

    $ grep -rl bsp_pretasking_hook .
    ./sparc/shared/bsppretaskinghook.c
    ./powerpc/score603e/startup/bspstart.c
    ./powerpc/beatnik/startup/bspstart.c
    ./powerpc/virtex5/startup/bspstart.c
    ./powerpc/virtex5/start/start.S
    ./powerpc/shared/startup/pretaskinghook.c
    ./powerpc/virtex4/startup/bspstart.c
    ./powerpc/virtex4/start/start.S
    ./powerpc/ep1a/startup/bspstart.c
    ./arm/lpc176x/startup/bspstart.c
    ./arm/lpc24xx/startup/bspstart.c
    ./bfin/bf537Stamp/startup/bspstart.c
    ./bfin/TLL6527M/startup/bspstart.c
    ./bfin/eZKit533/startup/bspstart.c
    ./shared/include/bootcard.h
    ./shared/bsppretaskinghook.c
    ./shared/bootcard.c

    Comment 1
    1. Amar Takhar, Fri, 13 Feb 2015 20:29:36 GMT

    You really want to do this in milestone:4.11 and not milestone:5.0?

    Comment 2
    1. Joel Sherrill, Fri, 13 Feb 2015 20:31:02 GMT
    2. milestone: changed from 4.11 to 5.0
    Comment 3
    1. Sebastian Huber, Tue, 24 Jan 2017 07:37:25 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    The bsp_pretasking_hook() exists no longer, see #2408.

    Comment 4
    1. Sebastian Huber, Tue, 24 Jan 2017 07:37:43 GMT
    2. milestone: changed from 5.0 to 4.12
    Comment 5
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2284 - h8300 gets error linking dl0&#42 tests

    Link https://devel.rtems.org/ticket/2284
    Id 2284
    Reporter Joel Sherrill
    Created 6 March 2015 14:30:50
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component unspecified
    Status closed
    Resolution wontfix
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    rtems-syms -e -c "-mh -mint32 -O2 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs" -o dl-sym.o dl01.pre
    h8300-rtems4.11-gcc -B../../../../../h8sim/lib/ -specs bsp_specs -qrtems -mh -mint32 -O2 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -mh -mint32 \

    -o dl01.exe init.o dl-load.o dl-tar.o dl-sym.o

    dl-sym.o: In function `rtems_rtl_base_global_syms_init':
    rld--gTgaaa.c:(.text+0xa): undefined reference to `rtemsrtl_base_globals_size'
    rld--gTgaaa.c:(.text+0x10): undefined reference to `rtemsrtl_base_globals'
    collect2: error: ld returned 1 exit status

    Comment 1
    1. Sebastian Huber, Tue, 05 Jan 2016 10:43:31 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix
    4. milestone: changed from 4.11.1 to 4.12

    h8300 support was removed in 4.12.

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2289 - rtems_ada_self is broken on SMP

    Link https://devel.rtems.org/ticket/2289
    Id 2289
    Reporter Sebastian Huber
    Created 9 March 2015 09:47:22
    Modified 9 November 2017 06:27:14
    Owner Needs Funding
    Type defect
    Component tool/gcc
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The global variable rtems_ada_self is broken on SMP (similar to the task variables) and should be replaced with a function call or thread specific data.

    Comment 1
    1. Sebastian Huber, Thu, 26 Jan 2017 07:16:00 GMT
    2. milestone: changed from 4.11.1 to 4.11.2
    Comment 2
    1. Sebastian Huber, Wed, 15 Feb 2017 13:37:51 GMT
    2. owner: set to Needs Funding
    3. status: changed from new to assigned
    4. milestone: changed from 4.11.2 to Indefinite
    Comment 3
    1. Sebastian Huber, Tue, 07 Mar 2017 10:07:12 GMT
    2. status: changed from assigned to closed
    3. resolution: set to duplicate

    Duplicate of #2835.

    Comment 4
    1. Sebastian Huber, Tue, 23 May 2017 08:01:52 GMT
    2. status: changed from closed to reopened
    3. version: 4.11 deleted
    4. resolution: duplicate deleted

    One option is to use TLS, e.g.

    diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in
    index 598b262d914..5e1c5286d63 100644
    --- a/gcc/ada/gcc-interface/Makefile.in
    +++ b/gcc/ada/gcc-interface/Makefile.in
    @@ -1743,7 +1743,7 @@ ifeq ($(strip $(filter-out rtems%,$(target_os))),)
       s-parame.adb

    Another option is to use POSIX keys:

    diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in
    index 598b262d914..5e1c5286d63 100644
    --- a/gcc/ada/gcc-interface/Makefile.in
    +++ b/gcc/ada/gcc-interface/Makefile.in
    @@ -1743,7 +1743,7 @@ ifeq ($(strip $(filter-out rtems%,$(target_os))),)
       s-parame.adb

    I tend to use TLS since it has less overhead.

    Comment 5
    1. Sebastian Huber, Fri, 02 Jun 2017 08:32:56 GMT

    In 3623c40/rtems:

    ada-tests/spatcb01: New test Update #2289.
    Comment 6
    1. Sebastian Huber, Wed, 07 Jun 2017 09:50:37 GMT

    ​https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=248952

    Comment 7
    1. Joel Sherrill, Wed, 07 Jun 2017 13:12:16 GMT

    Just to be clear. We are using keys now for Ada. Does confdefs.h reflect this?

    Comment 8
    1. Sebastian Huber, Wed, 07 Jun 2017 13:19:36 GMT

    No, we used a hand crafted task variable for this. I will update RTEMS once the RSB is updated. Need to backport the GCC change to GCC 7 branch before.

    Comment 9
    1. Sebastian Huber, Wed, 07 Jun 2017 13:52:17 GMT

    This change breaks the x86 Ada support as long as x86 has no TLS support.

    Comment 10
    1. Joel Sherrill, Wed, 07 Jun 2017 17:49:23 GMT

    So we are now using TLS for Ada.Self. I was thinking the POSIX default code used keys. That was the original implementation in GNAT. Is it TLS or POSIX keys?

    Comment 11
    1. Sebastian Huber, Thu, 08 Jun 2017 05:29:44 GMT

    On Linux and vxWorks TLS is used.

    Comment 12
    1. Sebastian Huber, Mon, 12 Jun 2017 11:53:01 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    In c336dc9/rtems-source-builder:

    4.12: Add SMP support for Ada of GCC 7.1 Close #2289.
    Comment 13
    1. Sebastian Huber, Mon, 12 Jun 2017 11:54:23 GMT
    2. milestone: changed from Indefinite to 4.12.0
    Comment 14
    1. Sebastian Huber, Wed, 14 Jun 2017 05:31:18 GMT

    In 3dd67dd1/rtems:

    score: Remove rtems_ada_self This task variable is superfluous since we use thread-local storage now. Update #2289.
    Comment 15
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2305 - sp07 needs to be split into an user extensions and a notepad test

    Link https://devel.rtems.org/ticket/2305
    Id 2305
    Reporter Joel Sherrill
    Created 14 March 2015 15:25:12
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component unspecified
    Status closed
    Resolution wontfix
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I was reviewing all code in the tree which uses deprecated methods. I will fix most of the cases. This is going to take a little more time. This test needs to be split apart. I think the notepad usage can go into a new test spnotepad02. It is primarily ensuring that two threads can exchange values through notepads.

    The remaining use of notepads in sp07 can probably just be a count down on the priority.

    I am starting to move code to spnotepad02 from sp07 that is not related to the tasks counting down.

    Hopefully I can resolve this without much feedback.

    Comment 1
    1. Sebastian Huber, Wed, 25 Jan 2017 12:22:55 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix
    4. milestone: changed from 4.11.1 to 4.12

    Notepads no longer exist in RTEMS 4.12.

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2306 - powerpc/mvme5500/vectors/exceptionhandler.c uses task variables

    Link https://devel.rtems.org/ticket/2306
    Id 2306
    Reporter Joel Sherrill
    Created 15 March 2015 02:14:17
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I am addressing almost all uses of deprecated methods. They are mostly calls to rtems_clock_get() which can be easily corrected or test code which will be removed when the deprecated feature is removed.

    This BSP however has what appears to be a unique feature -- the ability for a thread to add a unique exception fault handler. My inclination is to rip this out but I am not doing it now. I am just turning off deprecated warnings for the file.

    Comment 1
    1. Sebastian Huber, Tue, 15 Dec 2015 10:51:25 GMT

    I suggest to remove the functionality of task specific exception handlers. In a multi-threaded environment exceptions affect the overall program, e.g. memory corruption.

    Comment 2
    1. Joel Sherrill, Tue, 29 Dec 2015 17:30:08 GMT

    This code is disabled. It can't use notepads because they are obsoleted in 4.11 and removed after.

    Comment 3
    1. Sebastian Huber, Wed, 04 May 2016 05:27:15 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    4. milestone: changed from 4.11.1 to 4.12

    [159b63701539f3e584668a4ace13c6109d3b364b/rtems]

    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Mon, 16 Oct 2017 06:25:10 GMT
    2. component: changed from unspecified to arch/powerpc
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2308 - Change uniprocessor INIT task mode to preempt.

    Link https://devel.rtems.org/ticket/2308
    Id 2308
    Reporter Chris Johns
    Created 17 March 2015 03:00:10
    Modified 9 November 2017 06:27:14
    Owner  
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The current INIT task mode for a uni-processor build is NO_PREEMPT. This is not possible on an SMP system and so the default mode is PREEMPT. Both system should be the same and so the uniprocessor mode should be changed.

    Comment 1
    1. Chris Johns, Mon, 14 Aug 2017 00:01:57 GMT
    2. status: changed from new to closed
    3. version: changed from 4.11 to 4.12
    4. resolution: set to fixed
    5. milestone: changed from 5.0 to 4.12.0

    This is fixed on the master branch (4.12). The mode is NO_PREEMPT for non-SMP builds only.

    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2325 - Broken console driver infrastructure for SPARC

    Link https://devel.rtems.org/ticket/2325
    Id 2325
    Reporter Sebastian Huber
    Created 17 April 2015 06:59:46
    Modified 9 November 2017 06:27:14
    Owner Daniel Hellstrom
    Type defect
    Component arch/sparc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The stuff in "c/src/lib/libbsp/sparc/shared/uart/cons.c" should get removed and the new Termios device API should be used instead (see also rtems_termios_device_install()).

    Comment 1
    1. Sebastian Huber, Thu, 28 May 2015 08:02:11 GMT
    2. severity: changed from normal to blocker
    3. summary: changed from Superfluous console driver infrastructure for SPARC to Broken console driver infrastructure for SPARC

    The console devices installed with this driver are broken on SMP (attribute changes are not properly synchronized). In case RTEMS_DRVMGR_STARTUP is defined, then the SMP capable console driver "c/src/lib/libbsp/sparc/leon3/console/console.c" is disabled.

    Comment 2
    1. Ralph Holmes, Wed, 30 Dec 2015 18:46:26 GMT

    Upon further inspection, c/src/lib/libbsp/sparc/shared/uart/cons.c and c/src/lib/libbsp/sparc/shared/include/cons.h do not appear to be referenced from anywhere, and contain dead code. These can be removed safely.

    Comment 3
    1. Joel Sherrill, Wed, 30 Dec 2015 19:12:51 GMT

    I don't think the files are referenced either.

    Comment 4
    1. Sebastian Huber, Mon, 04 Jan 2016 09:06:51 GMT

    The file cons.c defines console_initialize() etc., so it is referenced in case you add a console driver to your application configuration.

    Comment 5
    1. Sebastian Huber, Wed, 25 Jan 2017 13:42:57 GMT
    2. milestone: changed from 4.11 to 4.12
    Comment 6
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 7
    1. Chris Johns, Mon, 14 Aug 2017 00:03:18 GMT
    2. version: changed from 4.11 to 4.12

    Any updates for this ticket? The severity is blocker

    Comment 8
    1. Daniel Hellstrom, Tue, 22 Aug 2017 08:24:51 GMT

    The cons.c is used by the apbuart_cons.c driver used with the driver manager. cons.c and apbuart_cons.c were updated for SMP and to use the new termios device registration in H1 2017 (see patches from --author="maberg@…"). Therefore I think we can close this ticket now.

    Comment 9
    1. Daniel Hellstrom, Tue, 22 Aug 2017 08:25:20 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 10
    1. Sebastian Huber, Mon, 16 Oct 2017 06:23:46 GMT
    2. component: changed from unspecified to arch/sparc
    Comment 11
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2344 - Second argument of ualarm() is ignored

    Link https://devel.rtems.org/ticket/2344
    Id 2344
    Reporter Sebastian Huber
    Created 11 May 2015 12:47:28
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I don't think this is in line with POSIX.

    Comment 1
    1. Joel Sherrill, Tue, 12 May 2015 22:32:45 GMT

    Would converting the second argument (interval) to ticks, saving it in a static variable, and using _Watchdog_Insert_ticks() in the TSR instead of _Watchdog_Reset_ticks() be enough to solve this?

    Also this method was deprecated/obsoleted in one edition of POSIX but the current edition doesn't appear to mention that if I read the pages correctly.

    Comment 2
    1. Sebastian Huber, Wed, 13 May 2015 06:36:28 GMT

    Something like this should do it. I added this report as a note since I don't have time for this currently.

    Comment 3
    1. Sebastian Huber, Mon, 22 Feb 2016 13:08:29 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to accepted
    4. milestone: changed from 4.11.1 to 4.12
    Comment 4
    1. Sebastian Huber, Mon, 22 Feb 2016 14:33:39 GMT

    In 5d478af46b2bd928f32cb8977164fe03d161c77f/rtems:

    psxtests/psxualarm: Add test cases Update #2344.
    Comment 5
    1. Sebastian Huber, Fri, 04 Mar 2016 14:00:20 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    [03b900d3ed120ea919ea3eded7edbece3488cff3/rtems]

    Comment 6
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2350 - One watchdog ticks header per scheduler instance

    Link https://devel.rtems.org/ticket/2350
    Id 2350
    Reporter Sebastian Huber
    Created 20 May 2015 07:25:28
    Modified 9 November 2017 06:27:14
    Owner  
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Currently there is one watchdog header for all ticks based watchdogs. This is not scalable. For example on the Freescale T4240 platform with 24-processors we observe in the smptests/smpwakeafter01 test a maximum thread dispatch disabled time of 3.8ms on processor 0 and 1.7ms on the other processors.


    3807457
    124091
    1706880473
    13755
    0
    24661
    10148
    127682501
    12582


    1715826
    102805
    1884937615
    18335
    0
    47
    12
    8299
    664


    47020
    2709
    31
    52
    990203330
    1674926849
    31604848
    10574
    8168
    8578
    31577528

    The watchdog lock is highly contended and since the watchdog insert procedure acquires and releases the lock during the iteration of the watchdog chain several times, this yields the high thread dispatch disabled times.

    To get rid of this bottleneck we should move the watchdog context into the scheduler context to use one watchdog context per scheduler instance. Take care that active watchdogs move in case of a scheduler change of a thread.

    Comment 1
    1. Chris Johns, Mon, 14 Aug 2017 00:08:57 GMT
    2. version: 4.11 deleted
    3. milestone: changed from 5.0 to Indefinite
    Comment 2
    1. Sebastian Huber, Mon, 21 Aug 2017 05:26:59 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    4. milestone: changed from Indefinite to 4.12.0

    There is now one watchdog header per processor.

    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:27:10 GMT
    2. component: changed from SMP to score
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:29:01 GMT
    2. component: changed from score to cpukit
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2354 - Replace red-black tree implementation, change API

    Link https://devel.rtems.org/ticket/2354
    Id 2354
    Reporter Sebastian Huber
    Created 28 May 2015 09:39:15
    Modified 9 November 2017 06:27:14
    Owner  
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The RTEMS red-black tree implementation is not as good as the BSD implementation which performs quite well in a benchmark:

    ​https://github.com/sebhub/rb-bench

    Proposal:

    ​https://github.com/sebhub/rb-bench/blob/master/test-rbtree-bsd-for-rtems.c

    One benefit is that the search/insert is done inline and the red-black tree fixup is done in a general purpose _BSD_RBTree_Insert_color() function (similar to the Linux red-black tree API).

    This makes it possible to get rid of the red-black tree implementation used by the JFFS2 support.

    Comment 1
    1. Chris Johns, Mon, 14 Aug 2017 00:05:18 GMT
    2. version: 4.11 deleted
    3. milestone: changed from 5.0 to Indefinite
    Comment 2
    1. Sebastian Huber, Mon, 21 Aug 2017 05:21:29 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    4. milestone: changed from Indefinite to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2355 - SPARC: Several shared drivers are not SMP ready

    Link https://devel.rtems.org/ticket/2355
    Id 2355
    Reporter Sebastian Huber
    Created 28 May 2015 12:18:40
    Modified 21 November 2017 09:29:21
    Owner Daniel Hellstrom
    Type defect
    Component arch/sparc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Several drivers in c/src/lib/libbsp/sparc/shared/ use interrupt disable/enable for low-level mutual exclusion. This is not enough on SMP configurations.

    Comment 1
    1. Sebastian Huber, Wed, 25 Jan 2017 13:42:57 GMT
    2. milestone: changed from 4.11 to 4.12
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Daniel Hellstrom, Fri, 12 May 2017 09:57:36 GMT

    With the most recent patches send to the devel-list most drivers have been fixed and now supports SMP.

    Still there are a couple which has not been addressed, the focus has been on the device drivers that are present/used on multi-core LEON devices such as dual-core GR712RC and quad-core GR740.

    The remaining drivers that generate warnings about this are:

    shared/spw/grspw.c - old driver, better functionality and SMP support in shared/spw/grspw_pkt.c. I'm thinking we should disable this driver for SMP builds. shared/1553/gr1553rt.c - Used by GR740. Was considered of lower priority but will be fixed in June.

    Related to this topic also important:

    sparc/shared/spw/grspw_router.c - Central for GR740. Build does not produce warnings since HW does not generate interrupts. A patch is pending on this one including SMP support and more importantly API updates for the GR740.

    Personally I think the current LEON3 BSP state regarding topic this should not be a blocker for a 4.12 branch?

    Comment 4
    1. Sebastian Huber, Fri, 12 May 2017 10:11:02 GMT

    Do you want to release RTEMS 4.12 with the message that most drivers work on your SMP chips or all?

    Comment 5
    1. Daniel Hellstrom, Fri, 12 May 2017 10:22:16 GMT

    I assumed that there will be some time after the branching until 4.12 is released? Maybe this is wrong? The two first should be quick to fix. The SpW router turned out to be more work than we initially expected.

    Comment 6
    1. Chris Johns, Mon, 15 May 2017 22:35:19 GMT

    Replying to Daniel Hellstrom:

    I assumed that there will be some time after the branching until 4.12 is released? Maybe this is wrong? The two first should be quick to fix. The SpW router turned out to be more work than we initially expected.

    I would prefer we get things sorted and stable on master, make the branch and then release. The overheads for making a release are coming down each time it happens so a dot point release to add a fix for a driver is fine with me.

    Comment 7
    1. Chris Johns, Mon, 14 Aug 2017 00:07:22 GMT
    2. priority: changed from normal to highest
    3. version: changed from 4.11 to 4.12
    4. severity: changed from normal to blocker

    What is the status of these drivers?

    Comment 8
    1. Chris Johns, Wed, 11 Oct 2017 22:41:03 GMT

    This ticket is mark as a blocker. Please update with an estimate of when this will be completed.

    Comment 9
    1. Sebastian Huber, Mon, 16 Oct 2017 06:23:46 GMT
    2. component: changed from unspecified to arch/sparc
    Comment 10
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 11
    1. Daniel Hellstrom, Tue, 14 Nov 2017 09:58:39 GMT

    Sorry for my late reply.

    It seems that "Update #2355" in the commit message does not work when I push. But the text says "remote: 3: update trac" as if it working when pushing.

    The following patches affect the status of this ticket since August:

    1ccce05337be6e81f823039932a8a10d2b07c2d8 6b339b5af65b243ea32edce29dc5642440ba68d5 59af2cc58e37481f176cbea96e6a59e70a9f5598 (pushed today)

    Status (libbsp/sparc/shared/):

    [FIXED] spw/grspw.c - disabled on SMP builds via Makefiles. Only safe in UP configuration. [FIXED] spw/grspw_router.c - SMP protection via spin-locks & semaphore. [TODO] 1533/gr1553rt.c - work not started yet. Is not SMP safe currently.

    With the router patch it is only the GR1553B in RT mode that is not SMP safe on the GR740. We could disable the RT driver on SMP for now to avoid the warnings until SMP is fixed? My initial plan was to have this driver SMP safe a long time ago. I don't think the remaining is a blocking issue and I suggest to change this ticket from being a blocker into major?

    Comment 12
    1. Sebastian Huber, Tue, 14 Nov 2017 10:08:52 GMT

    The Trac update via commits doesn't work if you push more than one commit at once.

    How much work is it to fix the GR1553B driver?

    Comment 13
    1. Daniel Hellstrom, Mon, 20 Nov 2017 14:18:52 GMT

    Thanks for information, I will test it with this RT patch.

    Thats right, its not much work but its the testing that concerns me. I have posted a patch which fixes the RT driver with SMP support and closes this ticket:

    ​https://lists.rtems.org/pipermail/devel/2017-November/019556.html

    Comment 14
    1. Daniel Hellstrom, Tue, 21 Nov 2017 09:29:21 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 4d7e4bb/rtems:

    leon, gr1553rt: adding SMP protection Add device spin-lock around internal data structures. Since the driver provides a low-level C API accessing the descriptors the application still needs to implement part of the SMP synchonization needed between Interrupt handler and tasks. Close #2355.

    2363 - SPARC: Silent FP context corruption possible

    Link https://devel.rtems.org/ticket/2363
    Id 2363
    Reporter Sebastian Huber
    Created 9 June 2015 07:40:10
    Modified 5 February 2018 07:49:50
    Owner  
    Type defect
    Component arch/sparc
    Status closed
    Resolution duplicate
    Version 4.11
    Milestone 5.1
    Priority lowest
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    On uni-processor configurations the post-switch actions (e.g. signal handlers) and context switch extensions may silently corrupt the floating point context. Set test sptests/spcontext01.

    This problem exists for many years and might be working as intended. It is possible to fix this issue using the SPARC_USE_SAFE_FP_SUPPORT option. This is already used for the SMP configurations. The disadavantage is that this disables the deferred floating point support.

    Comment 1
    1. Sebastian Huber, Thu, 26 Jan 2017 07:16:00 GMT
    2. milestone: changed from 4.11.1 to 4.11.2
    Comment 2
    1. Chris Johns, Thu, 23 Mar 2017 01:04:45 GMT
    2. milestone: changed from 4.11.2 to 4.11.3

    The 4.11.2 milestone is closing.

    Comment 3
    1. Chris Johns, Mon, 05 Feb 2018 04:39:20 GMT
    2. milestone: changed from 4.11.3 to Indefinite

    Requires funding.

    Comment 4
    1. Sebastian Huber, Mon, 05 Feb 2018 07:49:50 GMT
    2. status: changed from new to closed
    3. resolution: set to duplicate
    4. component: changed from score to arch/sparc
    5. milestone: changed from Indefinite to 5.1

    Fixed by #3077.


    2366 - Create a Public API for the Atomic Operations

    Link https://devel.rtems.org/ticket/2366
    Id 2366
    Reporter Joel Sherrill
    Created 11 June 2015 15:16:31
    Modified 9 November 2017 06:27:14
    Owner  
    Type enhancement
    Component score
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Ticket #2364 regarded use of a pthread mutex in three graphics driver as basically an atomic flag to ensure only one open() was active at a time. This created an unnecessary dependency on the POSIX API being enabled. I changed the code to use score Atomic flags.

    This highlighted the need for a public Atomic API.

    The existing tests could be converted to the public API, a macro wrapper written for Classic API Atomics, and documentation added. This may be enough to be a small GSOC project.

    Comment 1
    1. Sebastian Huber, Mon, 23 Jan 2017 06:46:39 GMT

    Why not simply use C11/C++11 atomic operations?

    Comment 2
    1. Chris Johns, Mon, 14 Aug 2017 00:06:50 GMT
    2. version: changed from 4.11 to 4.12
    3. milestone: changed from 5.0 to 4.12.0

    Should the API in 'sys/locks.h' be used?

    Comment 3
    1. Sebastian Huber, Thu, 24 Aug 2017 07:23:30 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    Since C11 or C++11 is now the default in GCC users can simply use the standard atomic operations.

    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2367 - Documentation of User Extensions needs more information

    Link https://devel.rtems.org/ticket/2367
    Id 2367
    Reporter mw
    Created 15 June 2015 17:30:11
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber <sebastian.huber@…>
    Type enhancement
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority low
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The documentation for User Extension sets in the C User's Guide could use some clarification. It discusses the multiple sets of extensions, but it is unclear as to whether or not the extensions are added or replaced when rtems_extension_create() is called. There is a section - 22.2.4 (Order of Invocation) that does discuss the operation of the sets, but it only makes sense once the reader understands that the sets are, in fact, additive.

    Comment 1
    1. Joel Sherrill, Tue, 16 Jun 2015 00:00:18 GMT

    Any other questions you would like to see answered? The points you mention are relatively straightforward to address but the email thread had a lot going on and I wanted to make sure all your questions got reflected in the changes.

    Comment 2
    1. mw, Wed, 17 Jun 2015 16:53:23 GMT

    No, I think all of my questions were stemming from that initial confusion. I thought I had to somehow extract the extensions that were previously installed in order to call them back myself; once I realized that they were layered (and the OS was doing the sequential calling), it all fell into place and I understood what was going on.

    Replying to joel.sherrill:

    Any other questions you would like to see answered? The points you mention are relatively straightforward to address but the email thread had a lot going on and I wanted to make sure all your questions got reflected in the changes.

    Comment 3
    1. Chris Johns, Mon, 14 Aug 2017 00:43:58 GMT
    2. version: changed from 4.11 to 4.12
    3. milestone: set to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 24 Aug 2017 07:57:40 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 6eef7a4/rtems-docs:

    c-user: Clarify user extensions Close #2367.
    Comment 5
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2377 - rtems_waf: Tools without a version are not supported

    Link https://devel.rtems.org/ticket/2377
    Id 2377
    Reporter Sebastian Huber
    Created 31 July 2015 08:30:35
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component tool
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc Daniel Hellstrom
    Blocking  
    Blocked by  

    Description

    waf configure --prefix=/opt/rtems --rtems=/opt/rtems --rtems-tools=/opt/rtems --rtems-bsps=i386/pc686
    Setting top to : /scratch/git-rtems-libbsd
    Setting out to : /scratch/git-rtems-libbsd/build
    Could not find any architectures
    (complete log in /scratch/git-rtems-libbsd-upstream/build/config.log)

    Comment 1
    1. Chris Johns, Fri, 31 Jul 2015 22:17:34 GMT

    I do not understand the issue. What does tools without a version mean ?

    Comment 2
    1. Sebastian Huber, Fri, 11 Sep 2015 09:03:45 GMT

    For example sparc-rtems-gcc, etc.

    This is used by some third-party tools, like the Gaisler RCC.

    Comment 3
    1. Chris Johns, Sun, 13 Sep 2015 22:49:42 GMT

    The rtems_waf module is designed to look at a standard versioned RTEMS tree that is built and installed. We have had versioning since 4.7. The module checks for the architectures requested are installed versioned. Changes to stop this adds complexity and increase testing in an area I would prefer not to do.

    I understood Gaisler is supporting versioned tools. What other 3rd party tool set are you referring to ?

    Comment 4
    1. Sebastian Huber, Mon, 14 Sep 2015 06:18:41 GMT

    The RCC archives use a version:

    ​http://gaisler.com/anonftp/rcc/bin/linux/

    However, the tools use all a sparc-rtems- prefix without a version.

    I found it convenient to use this scheme for the RTEMS master as well. You can build the tools with an arbitrary string after the target-rtems, e.g. sparc-rtemsfoobarblug99.abc is also allowed.

    Comment 5
    1. Chris Johns, Mon, 14 Sep 2015 06:35:54 GMT

    Replying to sebastian.huber:

    The RCC archives use a version:

    ​http://gaisler.com/anonftp/rcc/bin/linux/

    These look like old tools. My understanding is un-versioned tools would not be be part of any 4.11 version and the last un-versioned tools by Gaisler was 4.10.

    However, the tools use all a sparc-rtems- prefix without a version.

    We should not and really cannot support un-versioned tools in the project. I will discourage any efforts to make it supported.

    I found it convenient to use this scheme for the RTEMS master as well. You can build the tools with an arbitrary string after the target-rtems, e.g. sparc-rtemsfoobarblug99.abc is also allowed.

    Did you try the --rtems-version option, ie --rtems-version=foobarblug99.abc ?

    I support any version label and encourage custom ones for a specific user build. It is just no versioning I wish to discourage.

    Note, the waf based rtems-config support has a bug with a hardcoded version.

    Comment 6
    1. Sebastian Huber, Mon, 14 Sep 2015 06:49:48 GMT
    2. cc: Daniel Hellstrom added

    Replying to chrisj:

    Replying to sebastian.huber:

    The RCC archives use a version:

    ​http://gaisler.com/anonftp/rcc/bin/linux/

    These look like old tools. My understanding is un-versioned tools would not be be part of any 4.11 version and the last un-versioned tools by Gaisler was 4.10.

    The preliminary RCC for 4.11 has still un-versioned tools:

    ​http://www.gaisler.com/anonftp/rcc/smp/nov2014/sparc-rtems-4.11-gcc-4.9.2-1.2.99.1-linux.tar.bz2

    However, the tools use all a sparc-rtems- prefix without a version.

    We should not and really cannot support un-versioned tools in the project. I will discourage any efforts to make it supported.

    Ok, then Gaisler should adjust their RCC structure.

    I found it convenient to use this scheme for the RTEMS master as well. You can build the tools with an arbitrary string after the target-rtems, e.g. sparc-rtemsfoobarblug99.abc is also allowed.

    Did you try the --rtems-version option, ie --rtems-version=foobarblug99.abc ?

    I support any version label and encourage custom ones for a specific user build. It is just no versioning I wish to discourage.

    Note, the waf based rtems-config support has a bug with a hardcoded version.

    No, I didn't build the tools with such a version label.

    Comment 7
    1. Chris Johns, Mon, 14 Sep 2015 07:30:46 GMT

    Replying to sebastian.huber:

    Replying to chrisj:

    Replying to sebastian.huber:

    The RCC archives use a version:

    ​http://gaisler.com/anonftp/rcc/bin/linux/

    These look like old tools. My understanding is un-versioned tools would not be be part of any 4.11 version and the last un-versioned tools by Gaisler was 4.10.

    The preliminary RCC for 4.11 has still un-versioned tools:

    ​http://www.gaisler.com/anonftp/rcc/smp/nov2014/sparc-rtems-4.11-gcc-4.9.2-1.2.99.1-linux.tar.bz2

    Sigh. These being in the wild un-versioned is unfortunate.

    However, the tools use all a sparc-rtems- prefix without a version.

    We should not and really cannot support un-versioned tools in the project. I will discourage any efforts to make it supported.

    Ok, then Gaisler should adjust their RCC structure.

    Yes. We have to put an end to users appearing on the mailing list with questions and we are guessing the origin of the tools. This is the reason we have asked for the change. Joel and I are clear in our understanding of what was to happen. I checked with him last night his time.

    Comment 8
    1. Daniel Hellstrom, Thu, 17 Sep 2015 14:27:56 GMT

    Hi,

    Joel has discussed this with us some time ago and we agreed that we need to change the RCC naming. The temporary toolchain you can find via the gaisler.com homepage used still the old prefix and built by the old build scripts we have had. We were planning on using RSB initially but has not converted to it yet, however the old build script was updated recently which generates a toolchain with the prefix "sparc-rcc-rtems4.11-" as previously discussed. So next RCC release on rtems-4.11 will have that prefix. Please let me know if you see any trouble with us using that prefix.

    Regards, Daniel

    Comment 9
    1. Joel Sherrill, Fri, 18 Sep 2015 21:07:42 GMT

    The unversioned tools should still work with 4.11. There is no issue there because it is still only autoconf.

    This is an issue with the waf build. That will be 4.12 or 5.x but not 4.11. We need to make sure the target used for the Gaisler tools (sparc-rcc-rtems4.11-) is accepted OK. That should only be a matter of the wildcard pattern recognizing the CPU-rtemsVERSION or CPU-vendor-rtemsVERSION form of the target. The is actually GNUitically correct since the target technically has three parts. When the vendor isn't provided, it is assumed to be unknown.

    Comment 10
    1. Sebastian Huber, Thu, 26 Jan 2017 07:05:37 GMT
    2. milestone: changed from 4.11 to 4.11.2
    Comment 11
    1. Chris Johns, Tue, 21 Mar 2017 03:40:59 GMT
    2. version: changed from 4.11 to 4.12
    3. milestone: changed from 4.11.2 to 4.12

    Moved to master.

    Comment 12
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 13
    1. Sebastian Huber, Thu, 08 Jun 2017 08:35:44 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix
    Comment 14
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2385 - Warning from commit "bsps/arm: Do not use __ARM_ARCH_7A__"

    Link https://devel.rtems.org/ticket/2385
    Id 2385
    Reporter Chris Johns
    Created 6 August 2015 02:15:14
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This change ​https://git.rtems.org/rtems/commit/?h=4.11&id=d0733bb8 generate a warning in user code. The warning is:

    .../arm-errata.h:45:1: warning: 'in line' is not at beginning of declaration [-Wold-style-declaration]
    static bool inline arm_errata_is_applicable_processor_errata_764369(void)
    ^
    Comment 1
    1. Sebastian Huber, Fri, 04 Sep 2015 11:51:14 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In fc5e52b93837da575a73d5f1d783732587f8ec4e/rtems:

    bsps/arm: Fix function definition Close #2385.
    Comment 2
    1. Sebastian Huber, Fri, 04 Sep 2015 11:52:58 GMT
    2. version: changed from 4.11 to 4.12
    3. milestone: changed from 4.11.1 to 4.12
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:54:12 GMT
    2. component: changed from bsps to arch/arm
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2407 - Enable function and data sections

    Link https://devel.rtems.org/ticket/2407
    Id 2407
    Reporter Sebastian Huber
    Created 2 September 2015 12:29:49
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type enhancement
    Component build
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In order to reduce the size of executables it is beneficial to put all global functions and data into separate sections. This enables the linker to perform a garbage collection which removes all items not directly referenced. The following steps are necessary:

  • Modify the build system to use the following compiler and linker flags:
  • CFLAGS += -ffunction-sections -fdata-sections
    LDFLAGS += -Wl,--gc-sections

  • Review all linker command files and ensure that linker sets and global constructor sections are not affected by the garbage collection (e.g. use the KEEP() directive of GNU ld).
  • Comment 1
    1. Joel Sherrill, Fri, 11 Mar 2016 00:12:28 GMT

    Closing. This has been done and distributed to other tickets when specific issues were encountered.

    Comment 2
    1. Joel Sherrill, Fri, 11 Mar 2016 00:12:40 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    Comment 3
    1. Joel Sherrill, Fri, 11 Mar 2016 00:12:47 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2408 - Linker set based initialization

    Link https://devel.rtems.org/ticket/2408
    Id 2408
    Reporter Sebastian Huber
    Created 2 September 2015 12:52:05
    Modified 6 February 2020 14:24:21
    Owner Sebastian Huber
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Linker sets are used for example in Linux, FreeBSD (they are used in the RTEMS port of the FreeBSD network stack, e.g. libbsd), eCos and for global C++ constructors. They provide a space efficient and flexible means to initialize modules. A linker set consists of

    • dedicated input sections for the linker (e.g. .ctors and .ctors.* in the case of global constructors),
    • a begin marker (e.g. provided by crtbegin.o, and
    • an end marker (e.g. provided by ctrend.o).

    A module may place a certain data item into the dedicated input section. The linker will collect all such data items in this section and creates a begin and end marker. The initialization code can then use the begin and end markers to find all the collected data items (e.g. function pointers).

    Lets look how this works using a simple example. For this we need three files myset.h,

    #ifndef MYSET_H
    #define MYSET_H
    /* The linker set items */
    typedef struct {
    void (*func)(void);
    } item;
    /*
    * Macro to create a linker set item. The first parameter is
    * the designator of the item. It must be unique within the
    * module scope. The second parameter is the desired function.
    */
    #define MYSET_ITEM(i, f) \
    __attribute__((used)) \
    __attribute__((section(".rtemsroset.myset.content"))) \
    static item i = { f }
    #endif /* MYSET_H */

    module.c

    #include "myset.h"
    #include
    /*
    * Some global function that needs a module specific
    * intialization done by f().
    */
    void
    g(void)
    {
    printf("g()\n");
    }
    /* The module constructor */
    static void
    f(void)
    {
    printf("f()\n");
    }
    /*
    * This registers the module constructor f()
    * in the linker set "myset".
    */
    MYSET_ITEM(i, &f);

    and init.c.

    #include "myset.h"
    #include
    /* Should be in a proper header file */
    void g(void);
    /* Define the start marker */
    __attribute__((used))
    __attribute__((section(".rtemsroset.myset.begin")))
    static volatile const item begin[0];
    /* Define the end marker */
    __attribute__((used))
    __attribute__((section(".rtemsroset.myset.end")))
    static volatile const item end[0];
    int main(void)
    {
    size_t n = &end[0] - &begin[0];
    size_t i;
    /* Call all functions of the linker set */
    for (i = 0; i < n; ++i) {
    (*begin[i].func)();
    }
    /*
    * This will pull in the module.c and register its item in the
    * linker set "myset". So g() can rely on f() being called first.
    */
    g();
    return (0);
    }

    In the linker command file of the GNU linker we need the following statement.

    .rtemsroset : {
    KEEP (*(SORT(.rtemsroset.*)))

    The KEEP() ensures that a garbage collection by the linker will not discard the content of this section. This would be normally the case since the linker set items are not referenced directly. The SORT() directive sorts the input sections lexicographically. Please note the lexicographical order of the .begin, .content and .end section name parts in the previous example which ensures that the position of the begin and end markers are right. The interesting part of linker map file of the previous example may look like this.

    .rtemsroset     0x0000000001001990        0x4 load address 0x000000000002268c
    *(SORT(.rtemsroset.*))
    .rtemsroset.myset.begin
    0x0000000001001990 0x0 init.o
    .rtemsroset.myset.content
    0x0000000001001990 0x4 module.o
    .rtemsroset.myset.end
    0x0000000001001994 0x0 init.o

    So what is the benefit of using linker sets to initialize modules? Currently in RTEMS all available managers (semaphore, message queue, barrier, etc.) are initialized since the initialization code doesn't know what is actually used by the application. With the linker set approach we need to initialize only those managers that are used by the application. In case an application uses message queues, then it must call rtems_message_queue_create(). In the module implementing this function we can place a linker set item and register the message queue handler constructor. Otherwise, in case the application doesn't use message queues, then there will be no reference to the rtems_message_queue_create() function and the constructor is not registered, thus nothing of the message queue handler will be in the final executable.

    Comment 1
    1. Sebastian Huber, Thu, 03 Sep 2015 13:39:08 GMT

    See also [Developer/Projects/Open/SequencedInitialization].

    Comment 2
    1. Sebastian Huber, Wed, 28 Oct 2015 13:08:32 GMT

    See also ​https://lists.rtems.org/pipermail/devel/2015-October/012701.html.

    Comment 3
    1. Sebastian Huber, Tue, 08 Dec 2015 12:53:24 GMT

    In b618d8cfc54f84d4ed03dc7b7fa510c872e6128a/rtems:

    Add RTEMS linker sets Update #2408.
    Comment 4
    1. Sebastian Huber, Wed, 09 Dec 2015 07:00:51 GMT

    The POSIX API is disabled in 4.9 and 4.10. In 4.11 and 4.12 sizes are presented with POSIX enabled/disabled. The 4.12 without prefix is with the linker set based initialization. In 4.12 the Newlib internal locks are enabled.12. The PNOLS version is with POSIX enabled and the old initialization infrastructure.

    Executable sizes for the SPARC/SIS ticker.exe.

    Text Data BSS Workspace Non-Text 4.9 80384 2532 2996 51432 56960 4.10 124384 1828 2384 51056 55268 4.11 100592 1616 7008 44120 52744 4.11/POSIX 104608 1760 8528 45200 55488 4.12/PNOLS 105296 1872 8512 45376 55760 4.12/POSIX 101680 1808 6592 45336 53736 4.12 101472 1808 6528 44336 52672

    The huge increase in the test size from 4.9 to 4.10 is mostly due to the introduction of the pipe() support which pulls in sprintf().

    The increase of the BSS section from 4.10 to 4.11 is due to the static initialization of the scheduler data structures (move from workspace to BSS).

    Executable sizes for the SPARC/SIS minimum.exe.

    Text Data BSS Workspace Non-Text 4.9 45808 2324 2708 3288 8320 4.10 30032 1300 1296 3240 5836 4.11 34032 320 2976 2000 5296 4.11/POSIX 41664 1168 4480 2216 7864 4.12/PNOLS 39904 1232 4480 2136 7848 4.12/POSIX 29104 272 2304 2128 4704 4.12 28976 272 2240 1928 4440
    Comment 5
    1. Sebastian Huber, Thu, 10 Dec 2015 07:33:58 GMT

    In 2858939a2ccb3cf1918dadd9cda1fd1d8ab5a9ef/rtems:

    bsps: Delete superfluous bsp_pretasking_hook() Use the bsp_predriver_hook() instead. Update #2408.
    Comment 6
    1. Sebastian Huber, Fri, 11 Dec 2015 07:57:40 GMT

    [d0c39838146c6a186ddda3d95dac71c3fa90f11e/rtems]

    Comment 7
    1. Sebastian Huber, Tue, 26 Jan 2016 17:04:55 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 8
    1. Sebastian Huber, Wed, 03 Feb 2016 09:29:51 GMT

    In 36b86d7eb5e51a62c0cee1906210b389c2ab96eb/rtems:

    score: Create idle threads via linker set This allows a more fine grained rtems_initialize_data_structures(). Update #2408.
    Comment 9
    1. Sebastian Huber, Wed, 03 Feb 2016 09:30:01 GMT

    In a853c8518d7b8ccf54491018857ed86548f3ea24/rtems:

    Optional Initial Extensions initialization Update #2408.
    Comment 10
    1. Sebastian Huber, Wed, 03 Feb 2016 09:30:14 GMT

    In 92bb345374ea3982b40b10e7d50ecfc1cb4d2ed3/rtems:

    Optional Extensions initialization Update #2408.
    Comment 11
    1. Sebastian Huber, Wed, 03 Feb 2016 09:30:24 GMT

    In 565672a257156f78295608afb05157d1c7da7000/rtems:

    Optional Classic Tasks initialization Update #2408.
    Comment 12
    1. Sebastian Huber, Wed, 03 Feb 2016 09:30:35 GMT

    In 26335844f484c8cd061444cebba9480b62d165cb/rtems:

    Optional Classic Timer initialization Update #2408.
    Comment 13
    1. Sebastian Huber, Wed, 03 Feb 2016 09:30:46 GMT

    In a7f36829c08d86f6a53b5aad83a21e38aa1454b5/rtems:

    Optional Classic Signal initialization Update #2408.
    Comment 14
    1. Sebastian Huber, Wed, 03 Feb 2016 09:30:57 GMT

    In ae85b0663eb19db435476d268a10187633f2ba56/rtems:

    Optional Classic Event initialization Update #2408.
    Comment 15
    1. Sebastian Huber, Wed, 03 Feb 2016 09:31:07 GMT

    In ed8b00e667fe179730beb8947b5afb6bcc234d7a/rtems:

    Optional Classic Message Queue initialization Update #2408.
    Comment 16
    1. Sebastian Huber, Wed, 03 Feb 2016 09:31:18 GMT

    In cbaac1f7f4b3d78673abfde9bd6ed7e43dddf12c/rtems:

    Optional Classic Semaphore initialization Update #2408.
    Comment 17
    1. Sebastian Huber, Wed, 03 Feb 2016 09:31:28 GMT

    In fd3cc36f61e5b92b2234ff5eff5250f0ce6447bb/rtems:

    Optional Classic Partition initialization Update #2408.
    Comment 18
    1. Sebastian Huber, Wed, 03 Feb 2016 09:31:39 GMT

    In 365456cce3f3cf6da8a1bab9199e4bbd5f240dde/rtems:

    Optional Classic Region initialization Update #2408.
    Comment 19
    1. Sebastian Huber, Wed, 03 Feb 2016 09:31:50 GMT

    In af12278f9b33d7d8dca96d3873472ef2382f3c8e/rtems:

    Optional Classic Dual-Ported Memory initialization Update #2408.
    Comment 20
    1. Sebastian Huber, Wed, 03 Feb 2016 09:32:00 GMT

    In b377e3f6b70b5a5a09ac1dd77a450e4e5812cc42/rtems:

    Optional Classic Rate Monotonic initialization Update #2408.
    Comment 21
    1. Sebastian Huber, Wed, 03 Feb 2016 09:32:11 GMT

    In 97d94ff3e96c86d2a23b26efe48a9386c16a915a/rtems:

    Optional Classic Barrier initialization Update #2408.
    Comment 22
    1. Sebastian Huber, Wed, 03 Feb 2016 09:32:32 GMT

    In 04436ae7d83825300df85cabc3953f9c0314fe72/rtems:

    Optional POSIX Signals initialization Update #2408.
    Comment 23
    1. Sebastian Huber, Wed, 03 Feb 2016 09:32:42 GMT

    In ef1a985fc7591988ef956dd7b35f9533bace68a6/rtems:

    Optional POSIX Threads initialization Update #2408.
    Comment 24
    1. Sebastian Huber, Wed, 03 Feb 2016 09:32:53 GMT

    In cef56750eb5ce8a2aa31ff4e3bc038bc656a0d96/rtems:

    Optional POSIX Cleanup initialization Update #2408.
    Comment 25
    1. Sebastian Huber, Wed, 03 Feb 2016 09:33:04 GMT

    In f4fee4778e9ab8a61c00fdb34a6d2e49f2e0b2ce/rtems:

    Optional POSIX Condition Variable initialization Update #2408.
    Comment 26
    1. Sebastian Huber, Wed, 03 Feb 2016 09:33:14 GMT

    In 9871f5dc60c622b58710f624f2ddb9328de16eb8/rtems:

    Optional POSIX Mutex initialization Update #2408.
    Comment 27
    1. Sebastian Huber, Wed, 03 Feb 2016 09:33:25 GMT

    In 3015ed641a41059dec9abad1eb3872a006ee6324/rtems:

    Optional POSIX Message Queue initialization Update #2408.
    Comment 28
    1. Sebastian Huber, Wed, 03 Feb 2016 09:33:36 GMT

    In 2189b3e963f7e43e9fc577ab4f24c952cef5b08e/rtems:

    Optional POSIX Semaphore initialization Update #2408.
    Comment 29
    1. Sebastian Huber, Wed, 03 Feb 2016 09:33:46 GMT

    In 6c678557906cbbe73af1691e90e52911b2d00223/rtems:

    Optional POSIX Timer initialization Update #2408.
    Comment 30
    1. Sebastian Huber, Wed, 03 Feb 2016 09:33:57 GMT

    In e4e7f149c0f4d167a40862fee90707d38ee1aaf6/rtems:

    Optional POSIX Barrier initialization Update #2408.
    Comment 31
    1. Sebastian Huber, Wed, 03 Feb 2016 09:34:07 GMT

    In 76a8328945bdefafc255d9589d4dcc371e1a73ef/rtems:

    Optional POSIX RWLock initialization Update #2408.
    Comment 32
    1. Sebastian Huber, Wed, 03 Feb 2016 09:34:18 GMT

    In 4eee8781458f271be78e6f92cf344f9dbd2b4c8e/rtems:

    Optional POSIX Spinlock initialization Update #2408.
    Comment 33
    1. Sebastian Huber, Wed, 03 Feb 2016 09:34:29 GMT

    In 190169fee2f267f5e32813eb6fd3e9b51430effc/rtems:

    Optional CPU Set Handler initialization Update #2408.
    Comment 34
    1. Sebastian Huber, Wed, 03 Feb 2016 09:34:39 GMT

    In 2605a48938b9b3466add326d8e94b9622ffad7ba/rtems:

    Optional POSIX Keys initialization Update #2408.
    Comment 35
    1. Sebastian Huber, Wed, 03 Feb 2016 09:35:01 GMT

    In 3d36164fe5a366cf206ed3d2e8dc5b4d9e366c14/rtems:

    Use linker set for root file system initialization Update #2408.
    Comment 36
    1. Sebastian Huber, Wed, 03 Feb 2016 09:35:22 GMT

    In ca4602e914d4ec00bf5db51e0830d702d5bc3f4e/rtems:

    Use linker set for libio initialization Update #2408.
    Comment 37
    1. Sebastian Huber, Wed, 03 Feb 2016 09:35:33 GMT

    In 6bf44a581b35aba967034bc3e0348a4d1f36a048/rtems:

    Use linker set for driver manager initialization Update #2408.
    Comment 38
    1. Sebastian Huber, Wed, 03 Feb 2016 09:35:44 GMT

    In 8ca372e9b47319a034a32250e037247e5b3c4c9e/rtems:

    Use linker set for MPCI initialization Update #2408.
    Comment 39
    1. Sebastian Huber, Wed, 03 Feb 2016 09:35:55 GMT

    In 1ff8eca17a9f09bad3ab50c640547916808bf085/rtems:

    Use linker set for Classic User Tasks init Update #2408.
    Comment 40
    1. Sebastian Huber, Wed, 03 Feb 2016 09:36:06 GMT

    In 4210114032d8d079bddaa2333875c38e30c93490/rtems:

    Use linker set for POSIX User Threads init Update #2408.
    Comment 41
    1. Sebastian Huber, Wed, 03 Feb 2016 09:38:47 GMT

    Implementation is complete. Documentation is missing.

    Comment 42
    1. Sebastian Huber, Thu, 04 Feb 2016 11:59:09 GMT
    2. status: changed from assigned to accepted
    Comment 43
    1. Sebastian Huber, Tue, 01 Mar 2016 14:01:44 GMT

    In 1db95677debcd5497006d04b70634464a332a95b/rtems:

    sptests/spsysinit01: Fix for RTEMS_DEBUG Update #2408.
    Comment 44
    1. Joel Sherrill, Fri, 11 Mar 2016 00:13:28 GMT

    Just checking. Is this ready to close or do you have additional plans?

    Comment 45
    1. Sebastian Huber, Mon, 14 Mar 2016 07:16:20 GMT

    Documentation is incomplete.

    Comment 46
    1. Sebastian Huber, Wed, 12 Oct 2016 09:13:53 GMT

    In be573185e6d6ddafdd3612c7c2db04aa0f65a330/rtems:

    score: More robust linker sets Update #2408. Update #2790.
    Comment 47
    1. Joel Sherrill, Mon, 14 Nov 2016 16:38:08 GMT

    Should this ticket be closed now?

    Comment 48
    1. Sebastian Huber, Tue, 15 Nov 2016 06:05:10 GMT

    No, documentation is still incomplete. I am not satisfied with the GCC 7 support.

    Comment 49
    1. Sebastian Huber, Tue, 06 Dec 2016 11:03:23 GMT

    In 4b579c5f5170e1fb6a0573729444c289643b7d84/rtems:

    score: Simplify linker set API Resurrect RTEMS_LINKER_SET_BEGIN() and RTEMS_LINKER_SET_END(). Add new macros RTEMS_LINKER_SET_ITEM_COUNT(), RTEMS_LINKER_SET_IS_EMPTY(), and RTEMS_LINKER_SET_FOREACH(). Remove confusing RTEMS_LINKER_SET_ASSIGN_BEGIN() and RTEMS_LINKER_SET_ASSIGN_END(). Fix RTEMS_LINKER_SET_SIZE() to return the size in characters as specified by the documentation. Update #2408. Update #2790.
    Comment 50
    1. Chris Johns, Wed, 07 Dec 2016 04:10:42 GMT

    Jeff has reported to me libbsd is broken.

    Comment 51
    1. Sebastian Huber, Mon, 12 Dec 2016 07:09:08 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    Documentation complete.

    Comment 52
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 53
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 54
    1. Sebastian Huber, Fri, 20 Apr 2018 13:25:21 GMT

    In 6d21a3f2/rtems:

    drvmgr: Remove bsp_driver_level_hook() Use RTEMS_SYSINIT_ITEM() instead. Update #2408.
    Comment 55
    1. Sebastian Huber, Fri, 20 Apr 2018 13:25:54 GMT

    In c4ccf26c/rtems:

    bsps: Convert all bsp_predriver_hook() Use RTEMS_SYSINIT_ITEM() instead. Update #2408.
    Comment 56
    1. Sebastian Huber, Thu, 02 Jan 2020 08:49:16 GMT

    In 453bb4b/rtems:

    rtems: Fix MPCI initialization Update #2408.
    Comment 57
    1. Sebastian Huber, Tue, 04 Feb 2020 06:22:23 GMT

    In 813ada5/rtems-docs:

    c-user: Update system initialization chapter Update #2408. Update #3838.
    Comment 58
    1. Sebastian Huber, Thu, 06 Feb 2020 14:24:21 GMT

    In a4b23d9/rtems-docs:

    c-user: Document new linker set macros Adjust copyright. Linker sets were introduced in 2015. Update #2408. Close #3865.

    2412 - Improved priority inheritance implementation

    Link https://devel.rtems.org/ticket/2412
    Id 2412
    Reporter Sebastian Huber
    Created 4 September 2015 13:36:28
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority high
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Problem

    The RTEMS mutexes implement only a very simple approximation of the priority inheritance protocol. The real priority of a thread is only restored once it releases its last mutex. Lets consider this scenario. We have a file system instance protected by one mutex (e.g. JFFS2) and a dynamic memory allocator protected by another mutex. A low priority thread performs writes some log data into a file, thus it acquires the file system instance mutex. The file system allocates dynamic memory. Now a high priority thread interrupts and tries to allocate dynamic memory. The allocator mutex is already owned, so the priority of the low priority thread is raised to the priority of the high priority thread. The memory allocation completes and the allocator mutex is released, since the low priority thread still owns the file system instance mutex it continues to execute with the high priority (the high priority thread is not scheduled). It may now perform complex and long file system operations (e.g. garbage collection, polled flash erase and write functions) with a high priority.

    Functional requirements
    • The mutex shall use the priority inheritance protocol to prevent priority inversion. On SMP configurations OMIP shall be used.
    • The mutex shall allow vertical nesting (a thread owns multiple mutexes).
    • The mutex shall allow horizontal nesting (a thread waits for ownership of a mutex those owner waits for ownership of a mutex, and so on).
    • Threads from one scheduler instance shall wait in priority order. The highest priority thread shall be dequeued first.
    • The highest priority waiting thread of each scheduler instance shall wait in FIFO order.
    • The mutex shall provide an acquire operation with timeout.
    • In case a mutex is released, then the previous owner shall no longer use the priorities inherited by this mutex.
    • In case a mutex acquire operation timeout occurs, then the current owner of the mutex shall no longer use the priorities inherited by the acquiring thread.
    • The order of the mutex release operations may differ from the order of the mutex acquire operations.
    • Priority changes not originating due to the priority inheritance protocol shall take place immediately.
    • Deadlock shall be detected. In case a deadlock would occur an error status shall be returned or a fatal error shall be generated.
    • Deadlocks at application level shall not lead to a deadlock at operating system level.
    Performance requirements
    • The mutex acquire operation shall use only object-specific locks in case the mutex is not owned currently.
    • The mutex release operation shall use only object-specific locks in case no threads wait for ownership of this mutex.
    Invariants
    • A mutex shall be owned by at most one thread.
    • A thread shall wait for ownership of at most one mutex.
    Possible implementation

    Use a recursive data structure to determine the highest priority available to a thread for each scheduler instance, e.g.

    typedef struct Thread_Priority_node {
    Priority_Control current_priority;
    Priority_Control real_priority;
    struct Thread_Priority_node *owner;
    RBTree_Node Node;
    RBTree_Control Inherited_priorities;
    } Thread_Priority_node;
    typedef struct {
    ...
    Thread_Priority_node *priority_nodes; /* One per scheduler instances */
    ...
    } Thread_Control;

    Initially a thread has a priority node reflecting its real priority. The Thread_Priority_node::owner is NULL. The Thread_Priority_node::current_priority is set to the real priority. The Thread_Priority_node::Inherited_priorities is empty.

    In case the thread must wait for ownership of a mutex, then it enqueues its priority node in Thread_Priority_node::Inherited_priorities of the mutex owner.

    In case the thread is dequeued from the wait queue of a mutex, then it dequeues its priority node in Thread_Priority_node::Inherited_priorities of the previous mutex owner (ownership transfer) or the current mutex owner (acquire timeout).

    In case the minimum of Thread_Priority_node::real_priority and Thread_Priority_node::Inherited_priorities changes, then Thread_Priority_node::current_priority is updated. In case the Thread_Priority_node::owner its not NULL, the priority change propagates to the owner, and so on. In case Thread_Priority_node::current_priority changes, the corresponding scheduler is notified.

    The biggest issue is the locking on SMP configurations in case of recursive minimum updates.

    Somehow we must connect this to the scheduler helping protocol for OMIP. We may have to replace the return value based scheduler operations with a pre-context-switch action. Due to some recent implementation changes the run-time of the _Thread_Dispatch() function is no longer average-case performance critical.

    Comment 1
    1. Sebastian Huber, Mon, 07 Sep 2015 06:01:03 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Tue, 05 Jul 2016 07:53:12 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 3
    1. Sebastian Huber, Tue, 05 Jul 2016 07:53:28 GMT
    2. component: changed from General to cpukit
    Comment 4
    1. Sebastian Huber, Tue, 05 Jul 2016 07:53:37 GMT
    2. type: changed from defect to enhancement
    Comment 5
    1. Sebastian Huber, Wed, 27 Jul 2016 08:56:15 GMT

    In f4d1f307926b6319e5d3b325dbe424901285dec1/rtems:

    score: Split _Thread_Change_priority() Update #2412. Update #2556. Update #2765.
    Comment 6
    1. Sebastian Huber, Wed, 27 Jul 2016 08:56:26 GMT

    In ac8402ddd6e4a8eb6defb98220d39d4c20a6f025/rtems:

    score: Simplify _Thread_queue_Boost_priority() Raise the priority under thread queue lock protection and omit the superfluous thread queue priority change, since the thread is extracted anyway. The unblock operation will pick up the new priority. Update #2412. Update #2556. Update #2765.
    Comment 7
    1. Sebastian Huber, Wed, 27 Jul 2016 08:56:36 GMT

    In 3a58dc863157bb21054a144c1a21b690544c0d23/rtems:

    score: Priority inherit thread queue operations Move the priority change due to priority interitance to the thread queue enqueue operation to simplify the locking on SMP configurations. Update #2412. Update #2556. Update #2765.
    Comment 8
    1. Sebastian Huber, Wed, 27 Jul 2016 08:56:46 GMT

    In 1fcac5adc5ed38fb88ce4c6d24b2ca2e27e3cd10/rtems:

    score: Turn thread lock into thread wait lock The _Thread_Lock_acquire() function had a potentially infinite run-time due to the lack of fairness at atomic operations level. Update #2412. Update #2556. Update #2765.
    Comment 9
    1. Sebastian Huber, Wed, 27 Jul 2016 08:56:57 GMT

    In d79df38c2bea50112214ade95776cb90d693e390/rtems:

    score: Add deadlock detection The mutex objects use the owner field of the thread queues for the mutex owner. Use this and add a deadlock detection to _Thread_queue_Enqueue_critical() for thread queues with an owner. Update #2412. Update #2556. Close #2765.
    Comment 10
    1. Sebastian Huber, Wed, 21 Sep 2016 07:05:43 GMT

    In 300f6a481aaf9e6d29811faca71bf7104a01492c/rtems:

    score: Rework thread priority management Add priority nodes which contribute to the overall thread priority. The actual priority of a thread is now an aggregation of priority nodes. The thread priority aggregation for the home scheduler instance of a thread consists of at least one priority node, which is normally the real priority of the thread. The locking protocols (e.g. priority ceiling and priority inheritance), rate-monotonic period objects and the POSIX sporadic server add, change and remove priority nodes. A thread changes its priority now immediately, e.g. priority changes are not deferred until the thread releases its last resource. Replace the _Thread_Change_priority() function with _Thread_Priority_perform_actions(), _Thread_Priority_add(), _Thread_Priority_remove(), _Thread_Priority_change(), and _Thread_Priority_update(). Update #2412. Update #2556.
    Comment 11
    1. Sebastian Huber, Fri, 23 Dec 2016 14:11:26 GMT
    2. priority: changed from normal to high
    Comment 12
    1. Sebastian Huber, Wed, 01 Feb 2017 06:59:27 GMT
    2. status: changed from assigned to closed
    3. version: 4.5 deleted
    4. resolution: set to fixed

    [8add1793d25b2f76d564028f991cac31e0f871b4/rtems-docs]

    Comment 13
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 14
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2420 - RSB %source file fails

    Link https://devel.rtems.org/ticket/2420
    Id 2420
    Reporter Jakob Viketoft
    Created 14 September 2015 12:45:40
    Modified 13 December 2019 15:24:21
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    It seems that the method for accessing an existing file repository both isn't covered much in the "manual", but it also fails to find it. Looking at the python code in download.py, it requires the format ​file:// to identify the local file protocol, but then tries to access the actual file/directory using that the entire url (including ​file://).

    This unfortunately fails and I'm not familiar enough with Python to correct this, although it appears that the "​file://" part should be cut from the URL before calling the "return path.isdir(url)" in the _file_downloader function.

    Comment 1
    1. Gedare Bloom, Mon, 14 Sep 2015 14:03:57 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    4. version: changed from 4.10 to 4.11
    Comment 2
    1. Gedare Bloom, Mon, 14 Sep 2015 14:05:11 GMT

    Can you provide some more information about the failure? What are you trying to build, what is the config/bset being used, what %source directive fails? It may help to attach the log

    Comment 3
    1. Jakob Viketoft, Tue, 15 Sep 2015 08:45:29 GMT

    Well, at the moment I'm chasing a build bug in newlib and have modified a bset to allow me to change the source code locally. This was a perfect match for the "file" type available for %source, but as I stated it doesn't seem to work completely. (I would also like to use it later to have git sources as submodules instead of cloned-on-demand.)

    E.g., if I use a bset and modify the %source path for newlib from e.g. ​git:// to ​file:///full_path_to_this_dir/sources/git/newlib it doesn't find the directory. I added a printout of the url variable in _file_downloader in download.py, and the url contains the full given address as ​file:///full_path_to_this_dir/sources/git/newlib. This is then given to path.isdir and predictably fails.

    Or am I missing something fundamental here?

    Comment 4
    1. Chris Johns, Tue, 15 Sep 2015 23:54:47 GMT

    There maybe a bug in the 'file' implementation, but I think what you are asking for is something new. I think you are asking to use the source tree as is in the location it is and to build using it where the 'file' expects a tar type file. Using the source in the specified location is currently not implemented. It is an interesting feature to add and I like it. It however would require I take a look to see what it effects and currently time is limited.

    Comment 5
    1. Sebastian Huber, Thu, 26 Jan 2017 07:16:00 GMT
    2. milestone: changed from 4.11.1 to 4.11.2
    Comment 6
    1. Chris Johns, Wed, 22 Mar 2017 23:58:33 GMT
    2. version: changed from 4.11 to 4.12
    3. milestone: changed from 4.11.2 to 4.12

    This is a new feature and not suitable on a release branch.

    Comment 7
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 8
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 9
    1. Chris Johns, Fri, 13 Dec 2019 15:24:21 GMT
    2. status: changed from assigned to closed
    3. resolution: set to wontfix

    I have no time to work on this.


    2423 - rtems_iterate_over_all_threads lacks user callback private pointer pass through

    Link https://devel.rtems.org/ticket/2423
    Id 2423
    Reporter Jeffrey Hill
    Created 22 September 2015 00:12:13
    Modified 9 November 2017 06:27:14
    Owner  
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords rtems_iterate_over_all_threads callback private
    Cc  
    Blocking  
    Blocked by  

    Description

    Typically when designing an API that calls a user callback there is a user private "void *" pointer transparently passed through to the user callback so that the user can access his private state inside of his callback without being forced to employ a global variable. A global variable doesnt work very well if there are multiple objects instances created each of them using the same method with rtems_iterate_over_all_threads. This type of "void *" private pointer is of course a standard approach allowing the users callback to behave much the same way as a virtual method in C++, but nevertheless retaining a compatible C based API.

    An enhanced version of the API might look like this.

    void rtems_iterate_over_all_threads_xxx(
    rtems_per_thread_routine routine, void * const pUserPrivatePassThrogh
    );

    typedef void (*rtems_per_thread_routine_xxx)(
    Thread_Control *the_thread, void * const pUserPrivatePassThrogh
    );

    The pUserPrivatePassThrogh is not used by the library; it is retained for the duration of the rtems_iterate_over_all_threads_xxx function only so that it can be passed through to the user's callback.

    thanks for your consideration of this matter

    Comment 1
    1. Jeffrey Hill, Tue, 22 Sep 2015 15:35:30 GMT

    PS: I am using rtems_iterate_over_all_threads to implement a task mode, thread aware, Ethernet connected GDB stub. When GDB attaches it stops certain threads and sends their status depending on its operating modes, but this of course should not apply to the GDB communication threads. Therefore there needs to be a way to iterate through all of the threads checking each of them to determine if they are tagged as being GDB stop-mode immune.

    Comment 2
    1. Jeffrey Hill, Tue, 22 Sep 2015 20:02:27 GMT

    PPS: In thread.h and iterateoverthreads.c one could create some code like this. A possible implementation.

    /__ This defines the type for a method which operates on a single thread. __

    */

    typedef void (*rtems_per_thread_routine)( Thread_Control * ); typedef void (*rtems_per_task_function)( Thread_Control *,

    void * const pUserPrivate );

    /__ __

    This routine iterates over all threads regardless of API and invokes the specified routine. */

    void rtems_iterate_over_all_threads(

    rtems_per_thread_routine routine

    );

    void rtems_thread_per_each_callback(rtems_per_task_function pFunction,

    void * const pUserPrivate );

    void rtems_thread_per_each_callback(rtems_per_task_function pFunction,

    void * const pUserPrivate )

    {

    uint32_t i; uint32_t api_index; Thread_Control *the_thread; Objects_Information *information;

    if ( !pFunction )

    return;

    for ( api_index = 1 ; api_index <= OBJECTS_APIS_LAST ; api_index++ ) {

    if ( !_Objects_Information_table[ api_index ] )

    continue;

    information = _Objects_Information_table[ api_index ][ 1 ]; if ( !information )

    continue;

    for ( i=1 ; i <= information->maximum ; i++ ) {

    the_thread = (Thread_Control *)information->local_table[ i ];

    if ( !the_thread )

    continue;

    (*pFunction)(the_thread,pUserPrivate);

    }

    }

    }

    Comment 3
    1. Jeffrey Hill, Tue, 22 Sep 2015 20:07:16 GMT

    Ok, yes, the names I choose are pretty lame.

    Comment 4
    1. Sebastian Huber, Mon, 31 Oct 2016 12:38:33 GMT
    2. milestone: changed from 4.11.1 to 4.12
    Comment 5
    1. Sebastian Huber, Wed, 02 Nov 2016 08:13:53 GMT

    In d271c3bb78f86dd9417a964b019b8e38911064fa/rtems:

    rtems: Add rtems_task_iterate() Update #2423.
    Comment 6
    1. Sebastian Huber, Wed, 02 Nov 2016 08:14:03 GMT

    In 4cf58905b825ea8d2b9d677dc32d529390052d3a/rtems:

    cpuuse: Use rtems_task_iterate() Update #2423.
    Comment 7
    1. Sebastian Huber, Wed, 14 Dec 2016 14:25:44 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Documentation update done.

    Comment 8
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2428 - Add 4.12 Tool Target Configurations to RSB

    Link https://devel.rtems.org/ticket/2428
    Id 2428
    Reporter Joel Sherrill
    Created 16 October 2015 19:26:40
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type enhancement
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Even though so far the 4.11 and master tools don't need to be different, 4.12 configurations need to be added. This gives us space to:

    + (DONE) remove obsolete targets (avr, h8300, m32r)
    + (DONE) update versions
    + complete submission of patches and bump gdb
    + ...

    Comment 1
    1. Joel Sherrill, Wed, 20 Jan 2016 01:32:54 GMT
    2. version: changed from 4.10 to 4.12
    3. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Chris Johns, Wed, 11 Oct 2017 23:14:27 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    This was done a long time ago.

    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2441 - lpc1768 variants fail to build with error in gpio.c

    Link https://devel.rtems.org/ticket/2441
    Id 2441
    Reporter Joel Sherrill
    Created 2 November 2015 17:12:09
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    arm-lpc1768_mbed_ahb_ram_eth
    arm-lpc1768_mbed_ahb_ram
    arm-lpc1768_mbed

    In file included from ../../../../../../../../rtems/c/src/lib/libbsp/arm/lpc176x/gpio/gpio.c:25:0:
    ../../../../../.././lpc1768_mbed_ahb_ram_eth/lib/include/bsp/gpio.h:28:4: error: #error "BSP_GPIO_PIN_COUNT or BSP_GPIO_PINS_PER_BANK is not defined."

    #error "BSP_GPIO_PIN_COUNT or BSP_GPIO_PINS_PER_BANK is not defined."

    ../../../../../.././lpc1768_mbed_ahb_ram_eth/lib/include/bsp/gpio.h:32:4: error: #error "Invalid BSP_GPIO_PIN_COUNT or BSP_GPIO_PINS_PER_BANK."

    #error "Invalid BSP_GPIO_PIN_COUNT or BSP_GPIO_PINS_PER_BANK."

    ../../../../../.././lpc1768_mbed_ahb_ram_eth/lib/include/bsp/gpio.h:41:5: error: division by zero in #if

    #if GPIO_LAST_BANK_PINS > 0

    ../../../../../../../../rtems/c/src/lib/libbsp/arm/lpc176x/gpio/gpio.c:29:8: error: unknown type name 'lpc176x_registered_interrupt_function'

    static lpc176x_registered_interrupt_function function_vector[

    ../../../../../../../../rtems/c/src/lib/libbsp/arm/lpc176x/gpio/gpio.c:30:3: error: 'LPC176X_RESERVED_ISR_FUNCT_SIZE' undeclared here (not in a function)

    LPC176X_RESERVED_ISR_FUNCT_SIZE ];

    ../../../../../../../../rtems/c/src/lib/libbsp/arm/lpc176x/gpio/gpio.c:35:9: error: unknown type name 'lpc176x_gpio_direction'

    const lpc176x_gpio_direction dir

    Comment 1
    1. Sebastian Huber, Wed, 04 Nov 2015 06:44:51 GMT

    This BSP is not maintained by us.

    Comment 2
    1. Martin Galvan, Thu, 05 Nov 2015 14:28:51 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 1d55e157ca9f4a9ff806f8fa5fcc79b03a7b8178/rtems:

    LPC1768: Fix compilation error The LPC1768 variants have a gpio.h file whose name clashes with the gpio.h from the new GPIO API. This results on the BSPs failing to compile. This patch renames the LPC1768 gpio.* files to lpc-gpio.*, as it's done on other BSPs (e.g. Beaglebone). Closes #2441.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2442 - Remove avrtest BSP

    Link https://devel.rtems.org/ticket/2442
    Id 2442
    Reporter Joel Sherrill
    Created 2 November 2015 18:00:20
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type enhancement
    Component bsps
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords obsolete, BSP
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the avr/avrtest BSP per the instructions at ​https://devel.rtems.org/wiki/Developer/Removing_a_BSP

    Attachments:

    1 Ralph Holmes, Sat, 19 Dec 2015 16:12:20 GMT
      attach: set to 0001-avr-avrtest-Remove-obselete.patch
    2 Ralph Holmes, Sat, 19 Dec 2015 16:12:44 GMT
      attach: set to 0001-avr-avrtest-Remove-avrtest-references.patch
    Comment 1
    1. Joel Sherrill, Tue, 03 Nov 2015 19:27:04 GMT
    2. keywords: obsolete BSP added
    3. owner: set to joel.sherrill@…
    4. component: changed from General to bsps
    Comment 2
    1. Ralph Holmes, Sat, 19 Dec 2015 19:58:56 GMT

    In 34a2ec924d4300ff22504d1740d2bcd3c7acdb18/rtems:

    avr/avrtest: Remove (obselete). Updates #2442.
    Comment 3
    1. Ralph Holmes, Sat, 19 Dec 2015 19:59:18 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In a452c5727244c608379b08b1f6d720858cb41a78/rtems-testing:

    avr/avrtest: Remove avrtest references. Closes #2442.
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2443 - Remove AVR Architectural Port

    Link https://devel.rtems.org/ticket/2443
    Id 2443
    Reporter Joel Sherrill
    Created 2 November 2015 18:04:16
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill <joel@…>
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords obsolete, target
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the AVR port per the instructions at ​https://devel.rtems.org/wiki/Developer/Removing_a_Port.

    All BSPa must be removed before the architectural port can be removed. These are tracked by the following tickets:

    • #2442 - avrtest

    Rationale: The AVR port is incomplete and the largest AVR CPU models are just barely large enough to run RTEMS. This by itself is not enough to drop the port. However, the state of GCC for this target is poor. It is marginally maintained. Atmel maintains their own patch set independent of GCC. Plus they use their own small (and unique) C Library. This makes avr-rtems the only user of AVR+newlib. The target size is a challenge but that was why the port was initially interesting. It provided a real goal. But the tool state is painful for a port which is incomplete and has neither users nor anyone interested in actively maintaining it for GCC or RTEMS.

    Comment 1
    1. Joel Sherrill, Tue, 03 Nov 2015 14:38:42 GMT
    2. description: modified (diff)
    Comment 2
    1. Joel Sherrill, Tue, 03 Nov 2015 19:27:20 GMT
    2. keywords: obsolete target added
    Comment 3
    1. Joel Sherrill, Wed, 20 Jan 2016 01:40:58 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 15068f4c9afd2d5ca6a77d510059d6306c9a3be6/rtems:

    Remove AVR port closes #2443.
    Comment 4
    1. Sebastian Huber, Wed, 20 Jan 2016 07:31:40 GMT

    In 1d308a13210edd54133235e0bc015080f9191bd5/rtems:

    bsps: Resurrect ARM port Remove AVR port instead. Bug introduced by 15068f4c9afd2d5ca6a77d510059d6306c9a3be6. Update #2443.
    Comment 5
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2444 - Remove m68k/mvme136 BSP

    Link https://devel.rtems.org/ticket/2444
    Id 2444
    Reporter Joel Sherrill
    Created 3 November 2015 00:25:00
    Modified 9 November 2017 06:27:14
    Owner Aun-Ali Zaidi <admin@…>
    Type enhancement
    Component arch/m68k
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords obsolete, BSP
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the m68k/mvme136 BSP per the instructions at ​https://devel.rtems.org/wiki/Developer/Removing_a_BSP

    Rationale: Although it is sad to see the BSP for the board that RTEMS was developed for be removed, this board was current in 1988-9. It has only 1MB RAM, 2 UARTS, and no NIC. It is unlikely to be available and without a NIC, isn't that useful.

    Attachments:

    1 Aun-Ali Zaidi, Tue, 08 Dec 2015 02:49:23 GMT
      attach: set to 0001-m68k-mvme136-Remove.patch
    2 Aun-Ali Zaidi, Tue, 08 Dec 2015 02:49:41 GMT
      attach: set to 0002-m68k-acinclude.m4-Regenerate-to-remove-mvme136.patch
    3 Aun-Ali Zaidi, Tue, 08 Dec 2015 02:56:11 GMT
      attach: set to 0001-rtems-bit_rtems-Remove-mvme136-reference.patch
    4 Aun-Ali Zaidi, Tue, 08 Dec 2015 02:56:23 GMT
      attach: set to 0002-rtems-bit_all_bsps-Remove-mvme136-reference.patch
    5 Aun-Ali Zaidi, Tue, 08 Dec 2015 20:00:23 GMT
      attach: set to 0001-m68k-mvme136-Remove.2.patch
    Comment 1
    1. Joel Sherrill, Tue, 03 Nov 2015 00:25:50 GMT
    2. type: changed from defect to enhancement
    Comment 2
    1. Joel Sherrill, Tue, 03 Nov 2015 15:47:14 GMT
    2. description: modified (diff)
    Comment 3
    1. Joel Sherrill, Tue, 03 Nov 2015 19:26:52 GMT
    2. keywords: obsolete BSP added
    Comment 4
    1. Joel Sherrill, Tue, 08 Dec 2015 17:07:22 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 5
    1. Aun-Ali Zaidi, Tue, 08 Dec 2015 20:03:33 GMT
    2. owner: set to Aun-Ali Zaidi <admin@…>

    In 9ae2d98866cace349fc40feac8cf0e8895d9c699/rtems:

    m68k/mvme136: Remove closes #2444.
    Comment 6
    1. Aun-Ali Zaidi, Tue, 08 Dec 2015 20:11:50 GMT

    In 37efe15157d2479d600647080583cf37b23db4ff/rtems-testing:

    rtems/bit_rtems and bit_all_bsps: Remove mvme136 reference updates #2444.
    Comment 7
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 8
    1. Sebastian Huber, Tue, 10 Oct 2017 06:54:47 GMT
    2. component: changed from bsps to arch/m68k
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2445 - Remove m68k/sim68000 BSP

    Link https://devel.rtems.org/ticket/2445
    Id 2445
    Reporter Joel Sherrill
    Created 3 November 2015 00:25:43
    Modified 9 November 2017 06:27:14
    Owner Aun-Ali Zaidi <admin@…>
    Type enhancement
    Component arch/m68k
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords obsolete, BSP
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the m68k/sim68000 BSP per the instructions at ​​https://devel.rtems.org/wiki/Developer/Removing_a_BSP

    Rationale: This is a BSP for a simulator named BSVC (​http://www4.ncsu.edu/~bwmott/bsvc/) that was never under a truly free license and has not been updated in a decade. Although a decent tool, it was extremely slow.

    Attachments:

    1 Aun-Ali Zaidi, Tue, 08 Dec 2015 01:46:55 GMT
      attach: set to 0001-m68k-sim68000-Remove.patch
    2 Aun-Ali Zaidi, Tue, 08 Dec 2015 01:47:11 GMT
      attach: set to 0001-m68k-acinclude.m4-Regenerate-to-remove-sim68000.patch
    3 Aun-Ali Zaidi, Tue, 08 Dec 2015 01:58:35 GMT
      attach: set to 0001-rtems-bit_all_bsps-Remove-sim68000-reference.patch
     
    Comment 1
    1. Joel Sherrill, Tue, 03 Nov 2015 15:48:41 GMT
    2. description: modified (diff)
    Comment 2
    1. Joel Sherrill, Tue, 03 Nov 2015 19:26:59 GMT
    2. keywords: obsolete BSP added
    Comment 3
    1. Aun-Ali Zaidi, Tue, 08 Dec 2015 02:16:14 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 4
    1. Aun-Ali Zaidi, Tue, 08 Dec 2015 06:32:35 GMT
    2. owner: set to Aun-Ali Zaidi <admin@…>

    In a4e172aca7e0dd43a4c9822fe7c6afde2f22f49b/rtems:

    m68k/sim68000: Remove closes #2445.
    Comment 5
    1. Aun-Ali Zaidi, Tue, 08 Dec 2015 06:33:17 GMT

    In 008f779de1c423c3094b76b40d46ee29f784b619/rtems-testing:

    rtems/bit_all_bsps; Remove sim68000 reference closes #2445.
    Comment 6
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 7
    1. Sebastian Huber, Tue, 10 Oct 2017 06:54:47 GMT
    2. component: changed from bsps to arch/m68k
    Comment 8
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2446 - Remove M32R Architectural Port

    Link https://devel.rtems.org/ticket/2446
    Id 2446
    Reporter Joel Sherrill
    Created 3 November 2015 14:41:42
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords obsolete, target
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the M32R port per the instructions at ​​https://devel.rtems.org/wiki/Developer/Removing_a_Port.

    All BSPa must be removed before the architectural port can be removed.
    These are tracked by the following tickets:

    #2447 - m32rsim

    Rationale: The M32R port is incomplete, appears to have no users, and the CPU architecture is end-of-lifed.

    Comment 1
    1. Joel Sherrill, Tue, 03 Nov 2015 14:42:47 GMT
    2. description: modified (diff)
    Comment 2
    1. Joel Sherrill, Tue, 03 Nov 2015 19:27:49 GMT
    2. keywords: obsolete target added
    Comment 3
    1. Sebastian Huber, Wed, 15 Feb 2017 13:50:44 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 08 Jun 2017 07:26:03 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Port has been removed by [f5201df0dc70e4510c7a6862a96d66175fbbf514/rtems].

    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2447 - Remove m32r/m32rsim

    Link https://devel.rtems.org/ticket/2447
    Id 2447
    Reporter Joel Sherrill
    Created 3 November 2015 14:42:31
    Modified 9 November 2017 06:27:14
    Owner Aun-Ali Zaidi <admin@…>
    Type enhancement
    Component bsps
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords obsolete, BSP
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the m32r/m32rsim BSP per the instructions at ​https://devel.rtems.org/wiki/Developer/Removing_a_BSP

    Attachments:

    1 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:31:18 GMT
      attach: set to 0001-dejagnu-boards-rtems-m32r-m32rsim.exp-Remove.patch
    2 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:31:33 GMT
      attach: set to 0001-m32r-m32rsim-Remove.patch
    3 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:31:42 GMT
      attach: set to 0002-sim-scripts-Makefile-Remove-m32r-reference.patch
    4 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:31:51 GMT
      attach: set to 0003-sim-scripts-.gitignore-Remove-m32r-references.patch
    5 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:32:01 GMT
      attach: set to 0004-sim-scripts-m32rsim.in-Remove.patch
    6 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:32:12 GMT
      attach: set to 0005-gcc-rundeja-Remove-m32r-reference.patch
    7 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:32:34 GMT
      attach: set to 0006-gcc-test_driver-Remove-m32r-reference.patch
    8 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:32:43 GMT
      attach: set to 0007-gcc-RTEMS_GCC_Testing.txt-Remove-m32r-references.patch
    9 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:32:52 GMT
      attach: set to 0008-gcc-do_one-Remove-m32r-reference.patch
    10 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:33:01 GMT
      attach: set to 0009-gcc-parallelize_build-Remove-m32r-reference.patch
    11 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:33:10 GMT
      attach: set to 0010-gcc-testsuite-ada-acats-Makefile.rtems-Remove-m32r-r.patch
    12 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:33:20 GMT
      attach: set to 0011-simple-build-script-build_tools-Remove-m32r-referenc.patch
    13 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:33:29 GMT
      attach: set to 0012-rtems-bit_rtems-Remove-m32r-reference.patch
    14 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:33:38 GMT
      attach: set to 0013-rtems-bit_all_bsps-Remove-m32r-references.patch
    15 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:33:47 GMT
      attach: set to 0014-rtems-bit_all_multilib-Remove-m32r-reference.patch
    16 Aun-Ali Zaidi, Wed, 09 Dec 2015 19:33:56 GMT
      attach: set to 0015-rtems-common.sh-Remove-m32r-references.patch
    Comment 1
    1. Joel Sherrill, Tue, 03 Nov 2015 19:27:56 GMT
    2. keywords: obsolete BSP added
    Comment 2
    1. Joel Sherrill, Wed, 09 Dec 2015 23:11:30 GMT

    Grrr... you need to rebase your RTEMS tree. The rtems patch to remove the BSP does not apply.

    git checkout master git pull git checkout am # assuming that's the name of the branch git rebase -i master # things may break or conflict, fix them. make a new patch

    Please also delete all obsolete patches on this PR.

    Comment 3
    1. Joel Sherrill, Wed, 09 Dec 2015 23:13:47 GMT

    Please combine all patches for rtems-testing into a single patch.

    Also do not remove support for the m32r architecture in general. This means rtems-testing should not be modified.

    Please resubmit

    Comment 4
    1. Aun-Ali Zaidi, Thu, 10 Dec 2015 00:19:50 GMT

    I am not aware of a method of deleting the obsolete patches. As far as I know, that requires admin privileges.

    Replying to joel.sherrill:

    Grrr... you need to rebase your RTEMS tree. The rtems patch to remove the BSP does not apply.

    git checkout master git pull git checkout am # assuming that's the name of the branch git rebase -i master # things may break or conflict, fix them. make a new patch

    Please also delete all obsolete patches on this PR.

    Comment 5
    1. Aun-Ali Zaidi, Thu, 10 Dec 2015 00:21:30 GMT

    Replying to joel.sherrill:

    Please also delete all obsolete patches on this PR.

    I am not aware of a method of deleting the obsolete patches. As far as I know, that requires admin privileges.

    Comment 6
    1. Joel Sherrill, Thu, 10 Dec 2015 01:00:32 GMT

    I take back something I said. There maybe m32rsim references in the rtems-testing/gcc subdirectory. If so, kill them. But don't drop the entire m32r.

    Sorry. This gets complicated.

    Comment 7
    1. Aun-Ali Zaidi, Thu, 10 Dec 2015 08:29:28 GMT

    In f7c47a6880aea022b12f7f553df070d6f7ec0702/rtems:

    m32r/m32rsim: Remove updates #2447.
    Comment 8
    1. Joel Sherrill, Thu, 10 Dec 2015 13:57:44 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 9
    1. Aun-Ali Zaidi, Mon, 14 Dec 2015 03:10:36 GMT
    2. owner: set to Aun-Ali Zaidi <admin@…>

    In 2df531a2b7cdae890618c515c41a664b82ac2e9d/rtems-tools:

    bsps/m32rsim*: Remove closes #2447.
    Comment 10
    1. Gedare Bloom, Mon, 14 Dec 2015 03:13:42 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    Still hasn't been removed from rtems-testing.git.

    Comment 11
    1. Joel Sherrill, Sun, 03 Jan 2016 21:06:57 GMT

    Do we remove the tests from sim-scripts even when supported by older ports? I am reasonably happy to do this because the three ports being removed this time are all but useless. But in general, we need to be more deliberate.

    I suppose it is OK if there are release branches for this repo.

    Comment 12
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 13
    1. Sebastian Huber, Thu, 24 Aug 2017 06:19:41 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    In 9da6e08/rtems-testing:

    sim-scripts: Remove obsolete ignores Close #2447.
    Comment 14
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2448 - Remove mips/mongoose BSP

    Link https://devel.rtems.org/ticket/2448
    Id 2448
    Reporter Joel Sherrill
    Created 3 November 2015 14:54:17
    Modified 9 November 2017 06:27:14
    Owner  
    Type enhancement
    Component arch/mips
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords obsolete, BSP
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the m32r/m32rsim BSP per the instructions at ​​https://devel.rtems.org/wiki/Developer/Removing_a_BSP

    Rationale: This is a radiation hardened MIPS R3000 CPU that has only been used by a few missions. After discussions with various NASA and commercial engineers, we have learned that it is no longer considered an option for new missions and has not an option for a considerable length of time. The missions still underway (including New Horizons) are locked down on very old versions of their development infrastructure including hosts.

    Comment 1
    1. Joel Sherrill, Tue, 03 Nov 2015 19:28:02 GMT
    2. keywords: obsolete BSP added
    Comment 2
    1. Aun-Ali Zaidi, Mon, 14 Dec 2015 16:31:23 GMT

    In f39e173c47200d5638b7fd38b1548e30282d1484/rtems:

    mips/genmongoosev: Remove updates #2448.
    Comment 3
    1. Aun-Ali Zaidi, Fri, 26 Feb 2016 15:43:03 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Closing...

    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Tue, 10 Oct 2017 06:57:52 GMT
    2. component: changed from bsps to arch/mips
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2449 - Remove arm/gba BSP

    Link https://devel.rtems.org/ticket/2449
    Id 2449
    Reporter Joel Sherrill
    Created 3 November 2015 15:21:15
    Modified 9 November 2017 06:27:14
    Owner Aun-Ali Zaidi <admin@…>
    Type enhancement
    Component arch/arm
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords obsolete, BSP
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the arm/gba BSP per the instructions at ​​​https://devel.rtems.org/wiki/Developer/Removing_a_BSP

    Rationale: This BSP is for very old Nintendo hardware and required the use of either a simulator or hard to obtain programmable game cartridge. Nintendo was aggressive in shutting down resellers of those cartridges. There is no real console input and it is hard to automate testing. This was a useful BSP when there were few ARM BSPs but with the Pi, Beagle, etc. these days are long past.

    Comment 1
    1. Joel Sherrill, Tue, 03 Nov 2015 19:28:09 GMT
    2. keywords: obsolete BSP added
    Comment 2
    1. Aun-Ali Zaidi, Sun, 13 Dec 2015 01:20:56 GMT
    2. owner: set to Aun-Ali Zaidi <admin@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 0b52107768d392f65e41c075e16c563c6f87ebb6/rtems-testing:

    rtems/bit_all_bsps: Remove gba reference closes #2449.
    Comment 3
    1. Aun-Ali Zaidi, Sun, 13 Dec 2015 01:21:54 GMT

    In c8a8a6013fc3c02ae58eb343afec00a5954952e5/rtems:

    arm/gba: Remove updates #2449.
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Tue, 10 Oct 2017 06:55:49 GMT
    2. component: changed from bsps to arch/arm
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2450 - Remove arm/nds

    Link https://devel.rtems.org/ticket/2450
    Id 2450
    Reporter Joel Sherrill
    Created 3 November 2015 15:22:02
    Modified 9 November 2017 06:27:14
    Owner Aun-Ali Zaidi <admin@…>
    Type enhancement
    Component arch/arm
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords obsolete, BSP
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the arm/nds BSP per the instructions at ​​​​https://devel.rtems.org/wiki/Developer/Removing_a_BSP

    Rationale: This BSP is for very old Nintendo hardware and required the use of either a simulator or hard to obtain programmable game cartridge. Nintendo was aggressive in shutting down resellers of those cartridges. There is no real console input and it is hard to automate testing. This was a useful BSP when there were few ARM BSPs but with the Pi, Beagle, etc. these days are long past.

    Comment 1
    1. Joel Sherrill, Tue, 03 Nov 2015 19:28:15 GMT
    2. keywords: obsolete BSP added
    Comment 2
    1. Aun-Ali Zaidi, Fri, 11 Dec 2015 14:20:52 GMT

    In 32c2cd2be1067ebe32cdabccbc8aa16126ae3a32/rtems:

    arm/nds: Remove updates #2450.
    Comment 3
    1. Aun-Ali Zaidi, Fri, 11 Dec 2015 14:21:55 GMT
    2. owner: set to Aun-Ali Zaidi <admin@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 7cbd67b90b5aa4e4967b1a59f3ecd9f6e13e657f/rtems-testing:

    rtems/bit_all_bsps: Remove nds reference closes #2450.
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Tue, 10 Oct 2017 06:55:49 GMT
    2. component: changed from bsps to arch/arm
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2451 - Remove arm/gp32 BSP

    Link https://devel.rtems.org/ticket/2451
    Id 2451
    Reporter Joel Sherrill
    Created 3 November 2015 15:25:42
    Modified 9 November 2017 06:27:14
    Owner Aun-Ali Zaidi <admin@…>
    Type enhancement
    Component arch/arm
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords obsolete, BSP
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the arm/gp32 BSP per the instructions at ​​​​​https://devel.rtems.org/wiki/Developer/Removing_a_BSP

    Rationale: This BSP is for an open source alternative to the Gameboy Advance introduced in 2001. Wikipedia notes that 30K units were sold but it has been unavailable since 2007. This was a useful BSP when there were few ARM BSPs and the openness was interesting but with the Pi, Beagle, etc. these days are long past.

    Comment 1
    1. Joel Sherrill, Tue, 03 Nov 2015 19:28:21 GMT
    2. keywords: obsolete BSP added
    Comment 2
    1. Aun-Ali Zaidi, Sun, 13 Dec 2015 13:39:53 GMT
    2. owner: set to Aun-Ali Zaidi <admin@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 22e1982b7fbe57fdcb0c3b1a3cbf13d5f8d2d8e5/rtems-testing:

    rtems/bit_all_bsps: Remove gp32 reference closes #2451.
    Comment 3
    1. Aun-Ali Zaidi, Sun, 13 Dec 2015 13:40:07 GMT

    In f2a228b2cb5ce376c56ae8d767084b92f2822af0/rtems:

    arm/gp32: Remove updates #2451.
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Tue, 10 Oct 2017 06:55:49 GMT
    2. component: changed from bsps to arch/arm
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2452 - Remove H8300 Architectual Port

    Link https://devel.rtems.org/ticket/2452
    Id 2452
    Reporter Joel Sherrill
    Created 3 November 2015 15:30:21
    Modified 8 October 2021 15:42:04
    Owner Joel Sherrill
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords obsolete, target
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the H8300 port per the instructions at ​​https://devel.rtems.org/wiki/Developer/Removing_a_Port.

    All BSPa must be removed before the architectural port can be removed. These are tracked by the following tickets:

    #2453 - h8sim

    Rationale: The h8 has been end of lifed. There do not appear to be any users based up questions and tickets filed. The architecture itself has issues which lead to breakages in gcc (which do get fixed though often slowly) and those same issues force us to disable some features like iconv in newlib. With no users, end of life, and tool issues, it is time to remove it.

    Comment 1
    1. Joel Sherrill, Tue, 03 Nov 2015 15:31:19 GMT
    2. description: modified (diff)
    Comment 2
    1. Joel Sherrill, Tue, 03 Nov 2015 19:27:31 GMT
    2. keywords: obsolete target added
    Comment 3
    1. Sebastian Huber, Wed, 15 Feb 2017 13:50:44 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 08 Jun 2017 07:24:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Port has been removed by [f6a8663ec590a07d0a65c7305bacec0f9534775e/rtems].

    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 7
    1. Sebastian Huber, Thu, 08 Nov 2018 15:48:38 GMT

    In 947b679/rtems:

    h8300: Remove left over files Update #2452.
    Comment 8
    1. Joel Sherrill, Fri, 08 Oct 2021 15:42:04 GMT

    In f6385b4e/rtems:

    libdl/rtl-mdreloc-h8300.c: Remove remnant of h8300 port Updates #2452.

    2453 - Remove h8300/h8sim BSP

    Link https://devel.rtems.org/ticket/2453
    Id 2453
    Reporter Joel Sherrill
    Created 3 November 2015 15:31:06
    Modified 9 November 2017 06:27:14
    Owner Aun-Ali Zaidi <admin@…>
    Type enhancement
    Component bsps
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords obsolete, BSP
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the h8300/h8sim BSP per the instructions at ​​https://devel.rtems.org/wiki/Developer/Removing_a_BSP

    Comment 1
    1. Joel Sherrill, Tue, 03 Nov 2015 19:27:40 GMT
    2. keywords: obsolete BSP added
    Comment 2
    1. Aun-Ali Zaidi, Mon, 14 Dec 2015 03:03:14 GMT

    In 357fdfc2466f53a35d9821776d56fa236349a489/rtems:

    h8300/h8sim: Remove updates #2453.
    Comment 3
    1. Aun-Ali Zaidi, Mon, 14 Dec 2015 03:07:53 GMT

    In fcd7e2207454036956ac46c59cd4509da949ab43/rtems-testing:

    h8300: Remove h8sim references updates #2453.
    Comment 4
    1. Aun-Ali Zaidi, Mon, 14 Dec 2015 03:08:07 GMT
    2. owner: set to Aun-Ali Zaidi <admin@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In ea51d2ac224dd8a1a88e05d16287d6fa1ac6c555/rtems-tools:

    bsps/h8sim*: Remove closes #2453.
    Comment 5
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2454 - Warning in threadqops.c

    Link https://devel.rtems.org/ticket/2454
    Id 2454
    Reporter Joel Sherrill
    Created 3 November 2015 15:52:20
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This may apply to the 4.11 branch as well. I am not sure.

    ../../../../../../rtems/c/src/../../cpukit/score/src/threadqops.c:202:29: warning: passing argument 1 of '_RBTree_Initialize_empty' from incompatible pointer type

    This happens building many/all BSPs.

    Comment 1
    1. Sebastian Huber, Wed, 04 Nov 2015 06:41:32 GMT
    2. version: changed from 4.11 to 4.12
    Comment 2
    1. Sebastian Huber, Wed, 04 Nov 2015 06:53:44 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In eab538cf9e6c16f3ff902bf340ed0111d58fc35b/rtems:

    score: Fix warning Close #2454.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2455 - Warning in spsimplesched02

    Link https://devel.rtems.org/ticket/2455
    Id 2455
    Reporter Joel Sherrill
    Created 3 November 2015 15:53:29
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This may apply to the 4.11 branch as well. I am not sure.

    ../../../../../../../rtems/c/src/../../testsuites/sptests/spsimplesched02/init.c:84:5: warning: passing argument 1 of '_Objects_Name_to_id_u32' from incompatible pointer type

    This happens building many/all BSPs.

    Comment 1
    1. Sebastian Huber, Wed, 04 Nov 2015 06:41:48 GMT
    2. version: changed from 4.11 to 4.12
    Comment 2
    1. Sebastian Huber, Tue, 05 Jan 2016 12:02:40 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [893f9efe10142279fa2d445b1305e5359f1d5188/rtems]

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2457 - Remove powerpc/ep1a BSP

    Link https://devel.rtems.org/ticket/2457
    Id 2457
    Reporter Joel Sherrill
    Created 3 November 2015 20:06:04
    Modified 9 November 2017 06:27:14
    Owner Aun-Ali Zaidi <admin@…>
    Type enhancement
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords obsolete, BSP
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the powerpc/ep1a BSP per the instructions at ​​https://devel.rtems.org/wiki/Developer/Removing_a_BSP

    Rationale: AFAIK this BSP was only used on a program supported by OAR. That program is no longer in active development and is completely frozen. If that situation changes, the BSP can be resurrected. It was introduced 10 years ago and has not has a modification other than general maintenance in the last four years.

    Attachments:

    1 Aun-Ali Zaidi, Wed, 09 Dec 2015 03:58:00 GMT
      attach: set to 0001-powerpc-ep1a-Remove.patch
    2 Aun-Ali Zaidi, Wed, 09 Dec 2015 03:58:12 GMT
      attach: set to 0001-rtems-bit_all_bsps-Remove-ep1a-reference.patch
    Comment 1
    1. Aun-Ali Zaidi, Wed, 09 Dec 2015 06:29:05 GMT

    In 05d09f44fc298db02043cb6e21783cfb129b1c85/rtems:

    powerpc/ep1a: Remove updates #2457.
    Comment 2
    1. Aun-Ali Zaidi, Wed, 09 Dec 2015 06:29:57 GMT
    2. owner: set to Aun-Ali Zaidi <admin@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 6d384ec087724b65a1efb7930d35e87d4669f3bb/rtems-testing:

    rtems/bit_all_bsps: Remove ep1a reference closes #2457.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:56:19 GMT
    2. component: changed from bsps to arch/powerpc
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2458 - Remove powerpc/score603e BSP

    Link https://devel.rtems.org/ticket/2458
    Id 2458
    Reporter Joel Sherrill
    Created 3 November 2015 20:06:06
    Modified 9 November 2017 06:27:14
    Owner Ralph Holmes <ralph@…>
    Type enhancement
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords obsolete, BSP
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the powerpc/score603e BSP per the instructions at ​​https://devel.rtems.org/wiki/Developer/Removing_a_BSP

    Rationale: AFAIK this BSP was only used on a program supported by OAR. That program is no longer in active development and is completely frozen. If that situation changes, the BSP can be resurrected. It was introduced in 1999 and has not has a modification other than general maintenance in the last six years.

    Attachments:

    1 Ralph Holmes, Tue, 08 Dec 2015 22:56:27 GMT
      attach: set to 0001-powerpc-score603e-Remove-obselete.patch
    2 Ralph Holmes, Tue, 08 Dec 2015 23:06:36 GMT
      attach: set to 0001-rtems-bit_rtems-Remove-reference-to-score603e.patch
    Comment 1
    1. Joel Sherrill, Tue, 01 Dec 2015 13:51:27 GMT
    2. keywords: obsolete BSP added
    Comment 2
    1. Ralph Holmes, Wed, 09 Dec 2015 02:17:15 GMT

    In 999529516a32ae73f62c887370540d9574cdcecd/rtems:

    powerpc/score603e: Remove (obselete). Updates #2458.
    Comment 3
    1. Ralph Holmes, Wed, 09 Dec 2015 02:17:51 GMT
    2. owner: set to Ralph Holmes <ralph@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 94e40137bed8b40459d3eb26043e87bc5b12ec03/rtems-testing:

    rtems/bit_rtems: Remove reference to score603e. Closes #2458.
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Tue, 10 Oct 2017 06:56:19 GMT
    2. component: changed from bsps to arch/powerpc
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2459 - Add rtems_chain_get_first_unprotected() to chain API

    Link https://devel.rtems.org/ticket/2459
    Id 2459
    Reporter Sebastian Huber
    Created 5 November 2015 10:28:59
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Thu, 05 Nov 2015 10:33:12 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [aa473025f70d144ef9b50e833e7d9b91aad134f9/rtems]

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Mon, 16 Oct 2017 06:20:51 GMT
    2. component: changed from score to rtems
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2464 - RSB: Tool patches use the RTEMS version

    Link https://devel.rtems.org/ticket/2464
    Id 2464
    Reporter Sebastian Huber
    Created 10 November 2015 14:16:03
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component tool
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In rtems/conifg/rtems-urls.bset the tool patches are set to an RTEMS version dependent directory. This makes re-use of the general purpose files quite difficult.

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Chris Johns, Wed, 11 Oct 2017 23:17:34 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    We should use patches from tickets rather that using the rtems-tools.git repo. This means this any changed in the RSB can be avoided.

    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2468 - Add Thread Local Storage (TLS) support on x86

    Link https://devel.rtems.org/ticket/2468
    Id 2468
    Reporter Joel Sherrill
    Created 13 November 2015 15:16:53
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component arch/i386
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The x86 is one of the architectures which does not support Thread Local Storage. Each architecture requires target architecture specific support to provide this standard language feature.

    Details on the implementation by the compiler may be found at ​http://wiki.osdev.org/Thread_Local_Storage.

    Based on this information, I think a segment register needs to be added to the thread context and some hooks to the TLS implemented.

    Architecture information on TLS implementation should be added to the CPU Supplement document as this is part of the ABI and context switch.

    As part of effort, the documentation for the general procedure of adding target specific TLS support should be added to the porting guide or reviewed.

    Comment 1
    1. Sebastian Huber, Mon, 16 Nov 2015 06:36:48 GMT

    For documentation see for example:

    ​https://docs.rtems.org/doc-current/share/rtems/html/cpu_supplement/Port-Specific-Information-Thread_002dLocal-Storage.html#Port-Specific-Information-Thread_002dLocal-Storage

    Comment 2
    1. Sebastian Huber, Wed, 15 Feb 2017 14:20:42 GMT
    2. owner: set to Needs Funding
    3. status: changed from new to assigned
    4. milestone: changed from 4.12 to Indefinite
    Comment 3
    1. Sebastian Huber, Mon, 12 Jun 2017 09:07:42 GMT

    In cb0d9a0/rtems:

    i386: Move _CPU_Context_Initialize() Update #2468.
    Comment 4
    1. Sebastian Huber, Mon, 12 Jun 2017 09:08:08 GMT

    In 7b0c74ff/rtems:

    i386: Support thread-local storage (TLS) Update #2468.
    Comment 5
    1. Sebastian Huber, Mon, 12 Jun 2017 09:10:26 GMT
    2. owner: changed from Needs Funding to Sebastian Huber
    3. status: changed from assigned to accepted
    4. version: 4.12 deleted
    5. component: changed from General to cpukit
    6. milestone: changed from Indefinite to 4.12.0
    Comment 6
    1. Sebastian Huber, Mon, 12 Jun 2017 09:10:43 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 44c9e33/rtems-docs:

    cpu-supplement: Update TLS support status Close #2468.
    Comment 7
    1. Sebastian Huber, Mon, 16 Oct 2017 06:19:06 GMT
    2. component: changed from score to arch/i386
    Comment 8
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2477 - Remove <rtems/debug.h>

    Link https://devel.rtems.org/ticket/2477
    Id 2477
    Reporter Sebastian Huber
    Created 25 November 2015 08:30:22
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber <sebastian.huber@…>
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    RTEMS has an API for dynamic debug support in . This feature is sparely used:

    cpukit/sapi/src/debug.c:  rtems_debug_disable( RTEMS_DEBUG_ALL_MASK );
    cpukit/sapi/src/debug.c:void rtems_debug_enable (
    cpukit/sapi/src/debug.c: rtems_debug_control to_be_enabled
    cpukit/sapi/src/debug.c:void rtems_debug_disable (
    cpukit/sapi/src/debug.c: rtems_debug_control to_be_disabled
    cpukit/sapi/src/debug.c:bool rtems_debug_is_enabled(
    cpukit/sapi/src/debug.c: rtems_debug_control level
    cpukit/rtems/include/rtems/rtems/regionimpl.h: if ( rtems_debug_is_enabled( RTEMS_DEBUG_REGION ) ) \
    cpukit/score/include/rtems/debug.h:typedef uint32_t rtems_debug_control;
    cpukit/score/include/rtems/debug.h:SCORE_EXTERN rtems_debug_control _Debug_Level;
    cpukit/score/include/rtems/debug.h:void rtems_debug_enable(
    cpukit/score/include/rtems/debug.h: rtems_debug_control to_be_enabled
    cpukit/score/include/rtems/debug.h:void rtems_debug_disable(
    cpukit/score/include/rtems/debug.h: rtems_debug_control to_be_disabled
    cpukit/score/include/rtems/debug.h:bool rtems_debug_is_enabled(
    cpukit/score/include/rtems/debug.h: rtems_debug_control level
    c/src/lib/libbsp/shared/bootcard.c: * - rtems_debug_enable( RTEMS_DEBUG_ALL_MASK );
    c/src/lib/libbsp/shared/bootcard.c: rtems_debug_enable( RTEMS_DEBUG_ALL_MASK );
    c/src/lib/libbsp/shared/include/bootcard.h: * - rtems_debug_enable( RTEMS_DEBUG_ALL_MASK )
    testsuites/sptests/spregion_err01/init.c: puts( "TA1 - rtems_debug_disable - RTEMS_DEBUG_REGION" );
    testsuites/sptests/spregion_err01/init.c: rtems_debug_disable( RTEMS_DEBUG_REGION );
    testsuites/sptests/spregion_err01/init.c: puts( "TA1 - rtems_debug_enable - RTEMS_DEBUG_REGION" );
    testsuites/sptests/spregion_err01/init.c: rtems_debug_enable( RTEMS_DEBUG_REGION );
    testsuites/sptests/sp10/init.c: puts( "Init - rtems_debug_is_enabled - is 0x1 set? No" );
    testsuites/sptests/sp10/init.c: is_set = rtems_debug_is_enabled( 0x1 );
    testsuites/sptests/sp10/init.c: puts( "Init - rtems_debug_enable - set 0x1" );
    testsuites/sptests/sp10/init.c: rtems_debug_enable(0x1);
    testsuites/sptests/sp10/init.c: puts( "Init - rtems_debug_is_enabled - is 0x1 set? Yes" );
    testsuites/sptests/sp10/init.c: is_set = rtems_debug_is_enabled( 0x1 );
    testsuites/sptests/sp10/init.c: puts( "Init - rtems_debug_disable - clear 0x1" );
    testsuites/sptests/sp10/init.c: rtems_debug_disable(0x1);
    testsuites/sptests/sp10/init.c: puts( "Init - rtems_debug_is_enabled - is 0x1 set? No" );
    testsuites/sptests/sp10/init.c: is_set = rtems_debug_is_enabled( 0x1 );

    The only user is the Classic Region and it is only active in case RTEMS_DEBUG is defined. Due to the heap protection support which is also available in case RTEMS_DEBUG is defined, the expensive heap walks are superfluous.

    We should remove this API entirely to simplify the code base.

    Comment 1
    1. Sebastian Huber, Mon, 07 Dec 2015 12:13:47 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 8054b1c7181b7c36e413ce15b686f99d06f4a7d2/rtems:

    Remove Close #2477.
    Comment 2
    1. Sebastian Huber, Mon, 07 Dec 2015 13:43:47 GMT

    In 452eec433b3aa2fba464cee54f7d3c92726e4e0e/rtems:

    doc: Remove reference to debug mask Update #2477.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2487 - Should https://devel.rtems.org/wiki/TBR/Delete/SpecBuilder be Deleted?

    Link https://devel.rtems.org/ticket/2487
    Id 2487
    Reporter Joel Sherrill
    Created 8 December 2015 17:20:39
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component tool/website
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Chris.. you are the only one who knows if this tool is obsolete or not. Please do what you think is right with this page.

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Chris Johns, Wed, 11 Oct 2017 23:19:36 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    I cannot find the page in the wiki.

    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2488 - Vagrant Scripts

    Link https://devel.rtems.org/ticket/2488
    Id 2488
    Reporter Joel Sherrill
    Created 10 December 2015 18:58:54
    Modified 9 November 2017 06:27:14
    Owner Ben Gras
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Ben.. someone posted on IRC that they used your scripts but the clones point to your personal repos which are out of date I am guessing.

    Also is this discussed anywhere on the RTEMS wiki?

    Comment 1
    1. Ben Gras, Fri, 11 Dec 2015 11:43:05 GMT

    Drat. OK I am going to look into this.

    Comment 2
    1. Ben Gras, Sat, 12 Dec 2015 20:47:43 GMT

    I have

    . reproduced the problem

    To fix some encountered problems, I

    . rebased my RSB repo . changed to the 4.12 ARM bset . updated the qemu linaro commit id to accept newly passed configure options . rebased my rtems-tools repo . hard-coded an RTEMS module location in rtems-test so it could find rtemstoolkit - not sure what a clean fix is there

    As a result, tests are passing using the bbxm linaro qemu, making it Very Likely that everything is fixed.

    I have to go now but as far as I'm concerned this ticket can be closed once I (or anyone) verified with their own eyes that this newly built BSP boots on real hardware. All changes are pushed so anyone can try.

    Comment 3
    1. Chris Johns, Sun, 13 Dec 2015 01:46:38 GMT

    . hard-coded an RTEMS module location in rtems-test so it could find rtemstoolkit - not sure what a clean fix is there

    This has been fixed in a recent patch in the rtems-tools. Can you please test it?

    Comment 4
    1. Ben Gras, Sun, 13 Dec 2015 04:35:16 GMT

    Replying to chrisj:

    . hard-coded an RTEMS module location in rtems-test so it could find rtemstoolkit - not sure what a clean fix is there

    This has been fixed in a recent path in the rtems-tools. Can you please test it?

    Got it. It seemed to me I had fully rebased but I will re-investigate when I have some more time.

    Comment 5
    1. Chris Johns, Sun, 13 Dec 2015 04:38:56 GMT

    These are the patches on master and 4.11:

    ​https://git.rtems.org/rtems-tools/commit/?id=a6f5f188ce61d586136c643125dfb857da64169f ​https://git.rtems.org/rtems-tools/commit/?h=4.11&id=3b9bfa4dfe6fe10fbaf1ebbf1ddca660c2f33167

    Comment 6
    1. Ben Gras, Sun, 13 Dec 2015 04:53:13 GMT

    Acknowledged. I have to get to bed, please let me update later..

    Comment 7
    1. Ben Gras, Sun, 27 Dec 2015 02:33:17 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    All build problems are fixed in my RSB repo. I have verified it works from scratch on real hw. I had to fix an additional build problem in uboot now that gcc has major version 6.

    I am going to resolve this ticket and retry the tools test.

    Comment 8
    1. Ben Gras, Sun, 27 Dec 2015 03:18:58 GMT

    @chris, it seems your later commit of running the tester from a git clone did the trick - i rebased and the tester works now too.

    Unfortunately there is now yet another problem with a new uboot for the bbxm so the actual tests have started failing :(.

    Comment 9
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 10
    1. Sebastian Huber, Tue, 10 Oct 2017 06:12:28 GMT
    2. component: changed from Other to unspecified
    Comment 11
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2490 - RSB: Use SHA512 instead of MD5

    Link https://devel.rtems.org/ticket/2490
    Id 2490
    Reporter Sebastian Huber
    Created 11 December 2015 07:15:22
    Modified 10 April 2018 08:08:31
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Since MD5 is not a secure hash algorithm, we should change all hashes used by the RSB configuration files to use SHA512.

    Comment 1
    1. Chris Johns, Fri, 11 Dec 2015 10:42:07 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to accepted
    Comment 2
    1. Sebastian Huber, Thu, 26 Jan 2017 07:05:05 GMT
    2. milestone: changed from 4.11 to 4.11.2
    Comment 3
    1. Chris Johns, Tue, 21 Mar 2017 03:24:28 GMT
    2. version: changed from 4.11 to 4.12
    3. milestone: changed from 4.11.2 to 4.12

    Moving this to master.

    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 6
    1. Chris Johns, Tue, 10 Apr 2018 08:08:31 GMT
    2. status: changed from accepted to closed
    3. resolution: set to wontfix

    There is 98 md5 labels in the config files. I will not fix this so I am closing it with won't fix. Please open again if this is important and then assign to someone who agrees to update the hashes to sha512.


    2493 - Remove notepads

    Link https://devel.rtems.org/ticket/2493
    Id 2493
    Reporter Sebastian Huber
    Created 14 December 2015 12:42:30
    Modified 1 December 2017 14:23:45
    Owner Joel Sherrill <joel.sherrill@…>
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Notepads were marked as obsolete in #2265. Next step is to remove them. Documentation should mention that notepads are removed an list the alternatives, e.g. POSIX keys or thread local storage.

    Attachments:

    1 Aun-Ali Zaidi, Wed, 23 Dec 2015 21:06:32 GMT
      attach: set to 0001-api-Remove-deprecated-Notepads.patch
    Comment 1
    1. Sebastian Huber, Tue, 15 Dec 2015 10:54:46 GMT
    Remove RTEMS_API_Control::Notepads Remove all rtems_task_*note*() functions and now unused dependencies. Build with all tests enabled and fix all compile and link time errors. Run tests without regressions. Remove RTEMS_tasks_MP_Packet::note*. Build with --enable-multiprocessing. Build with all tests enabled and fix all compile and link time errors. Run tests without regressions. Update documentation, to be defined.
    Comment 2
    1. Aun-Ali Zaidi, Wed, 23 Dec 2015 21:10:03 GMT

    Notepads where a feature of RTEMS' tasks that simply functioned in the same way as POSIX keys or threaded local storage (TLS). They were introduced well before per task variables, which are also deprecated, and were barely used in favor of their POSIX alternatives.

    In addition to their scarce usage, Notepads took up unnecessary memory. For each task:

    16 32-bit integers were allocated. A total of 64 bytes per task per thread.

    This is especially critical in low memory and safety-critical applications.

    They are also defined as uint32_t, and therefore are not guaranteed to hold a pointer.

    Lastly, they are not portable solutions for SMP and uniprocessor systems, like POSIX keys and TLS.

    I am closing this ticket once the patch is committed.

    Comment 3
    1. Joel Sherrill, Thu, 24 Dec 2015 23:05:02 GMT
    2. owner: set to Joel Sherrill <joel.sherrill@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In c924e8502f6ad340acfae0e55443d0acde45fdf1/rtems:

    user/task.t: Add advice on transitioning use of notepads closes #2493.
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Mon, 29 May 2017 06:02:19 GMT

    In afa5b89/rtems:

    ada: Remove task notepad support Update #2493.
    Comment 6
    1. Sebastian Huber, Mon, 09 Oct 2017 06:05:48 GMT

    In d8f7bdc/rtems-docs:

    c-user: Add obsolete configuration options section Update #2493. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 8
    1. Sebastian Huber, Fri, 01 Dec 2017 14:23:45 GMT

    In dda8142f/rtems:

    ada/sp07: Fix uninitialized variable Bug was introduced by d5154d0f6a04f3b7ed59d9a09038576fe2640756. Updates #2493.

    2494 - Remove task variables

    Link https://devel.rtems.org/ticket/2494
    Id 2494
    Reporter Sebastian Huber
    Created 14 December 2015 12:45:02
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc admin@…
    Blocking  
    Blocked by  

    Description

    Notepads were marked as obsolete in 4.11. Next step is to remove them. Documentation should mention that notepads are removed and list the alternatives, e.g. POSIX keys or thread local storage.

    Attachments:

    1 Aun-Ali Zaidi, Tue, 01 Mar 2016 03:38:09 GMT
      attach: set to 0001-api-Remove-deprecated-task-variables.patch
    Comment 1
    1. Sebastian Huber, Tue, 15 Dec 2015 10:50:17 GMT

    This ticket depends on #2306.

    Comment 2
    1. Sebastian Huber, Tue, 15 Dec 2015 10:56:21 GMT
    Remove _Thread_Control::task_variables. Remove all rtems_task_*variable*() functions and now unused dependencies. Build with all tests enabled and fix all compile and link time errors. Run tests without regressions. Update documentation, to be defined.
    Comment 3
    1. Aun-Ali Zaidi, Tue, 01 Mar 2016 03:38:31 GMT
    2. cc: admin@… added
    Comment 4
    1. Sebastian Huber, Wed, 04 May 2016 05:28:19 GMT

    [1d40d81b4b8dd50e4162b0b79b60d3312d2744e5/rtems]

    Documentation update is missing.

    Comment 5
    1. Sebastian Huber, Wed, 15 Feb 2017 13:21:27 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 6
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2503 - mvme5500 BSP: Exception Handler uses deprecated Notepads.

    Link https://devel.rtems.org/ticket/2503
    Id 2503
    Reporter Aun-Ali Zaidi
    Created 23 December 2015 19:20:15
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity blocker
    Keywords  
    Cc admin@…
    Blocking  
    Blocked by  

    Description

    The MVME5500 BSP uses Notepads in its exception handler and #2493 removes them. This is obviously not portable and requires a rewrite.

    Comment 1
    1. Aun-Ali Zaidi, Wed, 23 Dec 2015 19:22:59 GMT
    2. owner: set to joel.sherrill@…
    3. component: changed from General to bsps
    Comment 2
    1. Aun-Ali Zaidi, Wed, 23 Dec 2015 19:23:35 GMT
    2. cc: admin@… added
    Comment 3
    1. Aun-Ali Zaidi, Tue, 29 Dec 2015 00:17:47 GMT

    This is related to #2306.

    Comment 4
    1. Joel Sherrill, Tue, 29 Dec 2015 17:28:56 GMT

    #2306 covers this issue. Closing.

    Comment 5
    1. Joel Sherrill, Tue, 29 Dec 2015 17:29:13 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 6
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 7
    1. Sebastian Huber, Tue, 10 Oct 2017 06:56:19 GMT
    2. component: changed from bsps to arch/powerpc
    Comment 8
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2509 - Should "https://devel.rtems.org/wiki/TBR/Delete/BSP_Template" be replaced?

    Link https://devel.rtems.org/ticket/2509
    Id 2509
    Reporter Santosh Vattam
    Created 4 January 2016 20:49:39
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type defect
    Component tool/website
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc Gedare Bloom
    Blocking  
    Blocked by  

    Description

    As part of the GCI Task ​https://codein.withgoogle.com/dashboard/task-instances/5106463810781184/?sp-page=1, the student has created a new page with a corrected template and placed it under "UserManual?" at: ​https://devel.rtems.org/wiki/TBR/UserManual/Submitting_a_BSP/BSP_Template Is it a good idea to replace the older page with the newly created page?

    Comment 1
    1. Gedare Bloom, Tue, 05 Jan 2016 17:33:46 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Yeah this is an improvement even if we ultimately change how BSPs are documented. Deleting the old one and closing this ticket.

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2513 - Remove m68k/idp BSP

    Link https://devel.rtems.org/ticket/2513
    Id 2513
    Reporter Joel Sherrill
    Created 6 January 2016 20:09:16
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component arch/m68k
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords obsolete, BSP
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the m68k/idp BSP per the instructions at ​​https://devel.rtems.org/wiki/Developer/Removing_a_BSP

    Comment 1
    1. Aun-Ali Zaidi, Fri, 26 Feb 2016 15:56:52 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Closing since it is already removed by f2ab5bc5943e1817540804117c4626151759681c.

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:54:47 GMT
    2. component: changed from bsps to arch/m68k
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2514 - Make POSIX API mandatory (except signals and the sporadic server)

    Link https://devel.rtems.org/ticket/2514
    Id 2514
    Reporter Sebastian Huber
    Created 7 January 2016 09:06:43
    Modified 18 May 2020 07:05:33
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by 3551

    Description

    The POSIX API is currently a build-time configuration option. In general it is beneficial to avoid build-time configuration options since this reduces the testing scope.

    Applications not using the POSIX API should observe only a minimal overhead due to this change.

    This enhancement depends on #2408.

    Attachments:

    1 Sebastian Huber, Thu, 05 Oct 2017 05:20:56 GMT
      attach: set to 0001-RTEMS-Self-contained-POSIX-objects.patch
    Comment 1
    1. Sebastian Huber, Thu, 07 Jan 2016 09:10:38 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Fri, 08 Jan 2016 08:02:42 GMT

    In fe100e16117c36c40e99a853d09cd8dcf98dbff0/rtems:

    score: Add fatal errors for NULL entry init tasks This simplifies the global construction. Update #2514.
    Comment 3
    1. Sebastian Huber, Fri, 08 Jan 2016 08:37:30 GMT

    In [44e987192e47910b8551a8f9409e9cd6133695d1/rtems]:

    score: Avoid dead code in global construction

    Update #2514.

    Comment 4
    1. Sebastian Huber, Mon, 11 Jan 2016 07:47:12 GMT

    In ccd54344d904b657123e4e4ba795a32212382be2/rtems:

    score: Introduce Thread_Entry_information This avoids potential dead code in _Thread_Handler(). It gets rid of the dangerous function pointer casts. Update #2514.
    Comment 5
    1. Sebastian Huber, Tue, 26 Jan 2016 09:26:22 GMT

    In 885c342e043f2281a0bc707cd0bc59726d1c4b79/rtems:

    mpci: Update due to API changes Update due to API changes introduced by ccd54344d904b657123e4e4ba795a32212382be2. Update #2514.
    Comment 6
    1. Sebastian Huber, Tue, 31 Jan 2017 09:13:49 GMT
    2. version: 4.12 deleted
    3. milestone: changed from 4.12 to 5.0
    Comment 7
    1. Sebastian Huber, Thu, 11 May 2017 10:05:24 GMT

    The signals implementation has some (severe) defects:

    #2100 #2263 #2607 #2716 #2690

    Fixing them is a major work package. I suggest to enable the non-signal related stuff of the POSIX API by default.

    Comment 8
    1. Sebastian Huber, Thu, 05 Oct 2017 12:34:58 GMT

    In 76d9db3/rtems-source-builder:

    4.12: Update to Newlib 2.5.0.20170922 The time_t is now a 64-bit signed integer. This update includes a patch to introduce the self-contained POSIX synchronization objects. Update #2514. Update #3111. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 9
    1. Sebastian Huber, Thu, 05 Oct 2017 12:35:53 GMT

    In e46a075/rtems:

    Enforce compatible Newlib version This Newlib check ensures that we have a 64-bit time_t and self-contained POSIX synchronization objects. Update #2514. Update #3111. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 10
    1. Sebastian Huber, Thu, 05 Oct 2017 12:36:18 GMT

    In c090db7/rtems:

    posix: Implement self-contained POSIX semaphores For semaphore object pointer and object validation see POSIX_SEMAPHORE_VALIDATE_OBJECT(). Destruction or close of a busy semaphore returns an error status. The object is not flushed. POSIX semaphores are now available in all configurations and no longer depend on --enable-posix. Update #2514. Update #3116.
    Comment 11
    1. Sebastian Huber, Thu, 05 Oct 2017 12:36:31 GMT

    In e67929c/rtems:

    posix: Implement self-contained POSIX barriers POSIX barriers are now available in all configurations and no longer depend on --enable-posix. Update #2514. Update #3114.
    Comment 12
    1. Sebastian Huber, Thu, 05 Oct 2017 12:36:43 GMT

    In 89fc9345/rtems:

    posix: Implement self-contained POSIX rwlocks POSIX rwlocks are now available in all configurations and no longer depend on --enable-posix. Update #2514. Update #3115.
    Comment 13
    1. Sebastian Huber, Thu, 05 Oct 2017 12:36:56 GMT

    In 5222488/rtems:

    posix: Implement self-contained POSIX condvar POSIX condition variables are now available in all configurations and no longer depend on --enable-posix. Update #2514. Update #3113.
    Comment 14
    1. Sebastian Huber, Thu, 05 Oct 2017 12:37:09 GMT

    In de59c065/rtems:

    posix: Implement self-contained POSIX mutex POSIX mutexes are now available in all configurations and no longer depend on --enable-posix. Update #2514. Update #3112.
    Comment 15
    1. Sebastian Huber, Tue, 10 Oct 2017 05:43:49 GMT

    In af9115f3/rtems:

    posix: Simplify POSIX_API_Control Return stack area via pthread_getattr_np(). Simplify pthread_attr_setaffinity_np(), and pthread_attr_getaffinity_np() and let the scheduler do the more sophisticated error checks. Make pthread_setaffinity_np(), pthread_getaffinity_np(), pthread_attr_setaffinity_np(), and pthread_attr_getaffinity_np() available in all configurations. Update #2514. Close #3145. Close #3168.
    Comment 16
    1. Sebastian Huber, Tue, 10 Oct 2017 05:44:03 GMT

    In da9f5f1/rtems:

    posix: Remove rtems_pthread_attribute_compare() Update #2514. Close #3174.
    Comment 17
    1. Sebastian Huber, Tue, 10 Oct 2017 05:44:17 GMT

    In 8c5267a/rtems:

    posix: Simplify pthread_attr_setstack() Simplify pthread_attr_setstack(), and pthread_attr_setstacksize(). Update #2514.
    Comment 18
    1. Sebastian Huber, Tue, 10 Oct 2017 05:44:29 GMT

    In 4f9ed26/rtems:

    posix: Constify default thread processor affinity Set default thread processor affinity to all processors of the pre-allocated set. This allows to constify the _POSIX_Threads_Default_attributes. Update #2514.
    Comment 19
    1. Sebastian Huber, Tue, 10 Oct 2017 05:44:43 GMT

    In bd5be58f/rtems:

    posix: Unconditional thread attribute support Update #2514.
    Comment 20
    1. Sebastian Huber, Wed, 11 Oct 2017 05:39:29 GMT

    In a3ad4af/rtems:

    posix: Validate affinity sets by the scheduler Update #2514.
    Comment 21
    1. Sebastian Huber, Wed, 11 Oct 2017 05:39:43 GMT

    In b2dbb634/rtems:

    score: Remove CPU_set_Control Use Processor_mask instead. Update #2514.
    Comment 22
    1. Sebastian Huber, Wed, 11 Oct 2017 06:34:14 GMT

    In 16aaf73b/rtems:

    smpaffinity01: Fix test case Update #2514.
    Comment 23
    1. Sebastian Huber, Wed, 11 Oct 2017 12:09:24 GMT
    2. status: changed from new to accepted
    3. summary: changed from Make POSIX API mandatory to Make POSIX API mandatory (except signals and the sporadic server)
    4. component: changed from unspecified to posix
    5. milestone: changed from 5.0 to 4.12.0
    Comment 24
    1. Sebastian Huber, Thu, 12 Oct 2017 05:20:28 GMT

    In 58500540/rtems:

    posix: Fix const qualifier warning Update #2514. Update #3179.
    Comment 25
    1. Sebastian Huber, Wed, 18 Oct 2017 06:52:20 GMT

    In 2be22d4/rtems:

    posix: Move POSIX_API_Control::thread This member is only used by the sporadic server support. Update #2514.
    Comment 26
    1. Sebastian Huber, Wed, 18 Oct 2017 06:52:32 GMT

    In 3f3f424/rtems:

    posix: Remove POSIX_API_Control::schedparam Move sporadic server scheduler parameters to POSIX_API_Control::Sporadic. Remove redundant scheduler priority parameter. Update #2514.
    Comment 27
    1. Sebastian Huber, Wed, 18 Oct 2017 06:52:44 GMT

    In 37eb717/rtems:

    posix: Simplify _POSIX_Threads_Create_extension() Move unblocked signals initialization to pthread_create(). Update #2514.
    Comment 28
    1. Sebastian Huber, Wed, 18 Oct 2017 07:34:22 GMT

    In dbb30e26/rtems:

    posix: Fix POSIX disabled build Update #2514.
    Comment 29
    1. Sebastian Huber, Mon, 23 Oct 2017 05:13:34 GMT

    In eeb8d83/rtems:

    posix: Fix POSIX disabled build Update #2514.
    Comment 30
    1. Sebastian Huber, Thu, 02 Nov 2017 10:25:59 GMT

    In 81fd79d/rtems:

    smppsxaffinity02: Fix thread attribute usage The pthread_getattr_np() returns now the stack address and size. Do not use this stack for the new threads. Update #2514. Update #3145. Update #3168.
    Comment 31
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 32
    1. Sebastian Huber, Thu, 09 Nov 2017 07:13:44 GMT

    In 7147dc4/rtems:

    posix: Remove POSIX_API_Control::schedpolicy Use the thread CPU budget algorithm to determine the scheduler policy. This fixes also pthread_getschedparam() for Classic tasks. Update #2514.
    Comment 33
    1. Sebastian Huber, Thu, 09 Nov 2017 07:13:56 GMT

    In 64ba1a96/rtems:

    posix: Change created_with_explicit_scheduler Remove POSIX_API_Control::created_with_explicit_scheduler. Add Thread_Control::was_created_with_inherited_scheduler. This fixes also pthread_getattr_np() for Classic tasks. Update #2514.
    Comment 34
    1. Sebastian Huber, Tue, 21 Nov 2017 07:09:15 GMT

    In c0d602e/rtems:

    posix: _POSIX_Threads_Get_sched_param_sporadic() Remove api parameter to simplify the calling functions. Update #2514.
    Comment 35
    1. Sebastian Huber, Mon, 18 Jun 2018 07:54:07 GMT

    In 49fd910/rtems-docs:

    c-user: Remove obsolete RTEMS_SYSINIT_CPU_SET Update #2514.
    Comment 36
    1. Joel Sherrill, Sat, 13 Oct 2018 22:41:39 GMT

    Sebastian.. since this hasn't been touched in a few months, is this complete?

    Comment 37
    1. Sebastian Huber, Mon, 15 Oct 2018 05:31:34 GMT

    Progress on this ticket was blocked by several things. I hope to close it soon.

    Comment 38
    1. Sebastian Huber, Mon, 15 Oct 2018 06:21:45 GMT
    2. blockedby: set to 3551
    Comment 39
    1. Sebastian Huber, Tue, 23 Oct 2018 14:03:05 GMT

    In dd804bb/rtems:

    posix: Provide cancel state/type by default Sort POSIX sources lexicographically in Makefile.am Update #2514.
    Comment 40
    1. Sebastian Huber, Tue, 23 Oct 2018 14:03:09 GMT

    In 0b2808ce/rtems:

    posix: Provide scheduler support by default Update #2514.
    Comment 41
    1. Sebastian Huber, Tue, 23 Oct 2018 14:03:12 GMT

    In 8d81622/rtems:

    posix: Provide non-thread functions by default Update #2514.
    Comment 42
    1. Sebastian Huber, Thu, 25 Oct 2018 08:06:11 GMT

    In 4a7be22/rtems:

    posix: Fix build with POSIX API disabled Update #2514.
    Comment 43
    1. Sebastian Huber, Thu, 25 Oct 2018 08:06:22 GMT

    In 135cb10/rtems:

    posix: Provide more functions by default Update #2514.
    Comment 44
    1. Sebastian Huber, Tue, 30 Oct 2018 06:11:25 GMT

    In 0dbf67b/rtems:

    posix: Provide aio_suspend() by default Update #2514.
    Comment 45
    1. Sebastian Huber, Tue, 30 Oct 2018 06:11:34 GMT

    In 5090a71b/rtems:

    score: Remove bogus thread object name support Update #2514.
    Comment 46
    1. Sebastian Huber, Tue, 30 Oct 2018 06:11:42 GMT

    In 7038271/rtems:

    Remove RTEMS_SCORE_OBJECT_ENABLE_STRING_NAMES Enable support for string objects names unconditionally. Add const qualifier throughout. Split _Objects_Namespace_remove() into _Objects_Namespace_remove_u32() and _Objects_Namespace_remove_string() to avoid an unnecessary dependency on _Workspace_Free(). Update #2514.
    Comment 47
    1. Sebastian Huber, Tue, 30 Oct 2018 06:11:58 GMT

    In e97806a/rtems:

    posix: Split posix_api_configuration_table Use separate configuration variables to avoid false dependencies. Update #2514.
    Comment 48
    1. Sebastian Huber, Tue, 30 Oct 2018 06:12:06 GMT

    In 9318cfb0/rtems:

    posix: Provide named semaphores by default Update #2514.
    Comment 49
    1. Sebastian Huber, Tue, 30 Oct 2018 06:12:14 GMT

    In 701057e0/rtems:

    posix: Provide shared memory objects by default Update #2514.
    Comment 50
    1. Sebastian Huber, Tue, 30 Oct 2018 06:12:21 GMT

    In fe7aefd5/rtems:

    posix: Provide message queues by default Update #2514.
    Comment 51
    1. Sebastian Huber, Tue, 30 Oct 2018 06:12:29 GMT

    In 033f31c8/rtems:

    posix: Hide POSIX_API_Control by default Update #2514.
    Comment 52
    1. Sebastian Huber, Tue, 30 Oct 2018 06:12:37 GMT

    In 54f35888/rtems:

    posix: Provide threads by default Update #2514.
    Comment 53
    1. Sebastian Huber, Tue, 30 Oct 2018 06:12:45 GMT

    In ef16a11/rtems:

    posix: Enable psxtmtests tests by default Update #2514.
    Comment 54
    1. Sebastian Huber, Tue, 30 Oct 2018 06:12:54 GMT

    In 24f3e8f/rtems:

    posix: Enable more smptests tests by default Update #2514.
    Comment 55
    1. Sebastian Huber, Tue, 30 Oct 2018 06:13:02 GMT

    In 8dc1ed1/rtems:

    posix: Enable more psxtests by default Update #2514.
    Comment 56
    1. Sebastian Huber, Tue, 30 Oct 2018 06:13:10 GMT

    In bb3484c9/rtems:

    posix: Enable more sptests test cases by default Update #2514.
    Comment 57
    1. Sebastian Huber, Mon, 05 Nov 2018 06:19:24 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In dd1c262/rtems-docs:

    c-user: Update POSIX API configuration Close ##2514.
    Comment 58
    1. Sebastian Huber, Mon, 18 May 2020 07:05:33 GMT

    In 934cbe7/rtems:

    posix: Get real priority in pthread_getattr_np() This is in line with pthread_setschedparam() and pthread_getschedparam(). Update #2514.

    2515 - i386 score/libcpu API Layering Violation

    Link https://devel.rtems.org/ticket/2515
    Id 2515
    Reporter Gedare Bloom
    Created 8 January 2016 18:06:20
    Modified 9 November 2017 06:27:14
    Owner Gedare Bloom
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords i386
    Cc Joel Sherrill
    Blocking  
    Blocked by  

    Description

    The file libcpu/i386/cpu.h provides functions referenced in rtems/score/i386.h Relatedly, libcpu/i386/cpu.h is the only other consumer than score/cpu.h of the score/interrupts.h. The libcpu/i386/cpu.h should be refactored into rtems/score/i386.h, which could also then subsume rtems/score/interrupts.h.

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Gedare Bloom, Fri, 30 Jun 2017 13:26:04 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Fixed by 328bd350aa40bd6aff923cd2efd3c14d0c8e0ec4

    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2527 - Move pc386/tools/bin2boot to rtems-tools

    Link https://devel.rtems.org/ticket/2527
    Id 2527
    Reporter Joel Sherrill
    Created 15 January 2016 00:36:55
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type enhancement
    Component tool
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Per discussion with Chris. Begin to eliminate BSP specific tools.

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Joel Sherrill, Thu, 12 Oct 2017 00:02:55 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    This appears to be an obsolete boot format. This utility isn't causing issues in its current location. Unless someone complains, it should remain here and be removed as part of moving to the new build system.

    Comment 3
    1. Sebastian Huber, Thu, 12 Oct 2017 05:31:00 GMT

    This is one item that forces you to install a native compiler to build RTEMS.

    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2529 - BSP for the Atmel SAM V71/V70/E70/S70 chip platform

    Link https://devel.rtems.org/ticket/2529
    Id 2529
    Reporter Sebastian Huber
    Created 15 January 2016 14:17:22
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    ​http://www.atmel.com/products/microcontrollers/arm/sam-v-mcus.aspx

    Comment 1
    1. Sebastian Huber, Tue, 19 Jan 2016 07:38:47 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In f2e0f8e1a769231257f38a6bb6ab9ea9bbad452f/rtems:

    bsp/atsam: New Close #2529.
    Comment 2
    1. Sebastian Huber, Tue, 19 Jan 2016 07:48:01 GMT

    All tests except sp71 passed at version [f2e0f8e1a769231257f38a6bb6ab9ea9bbad452f/rtems] on a Atmel SAM V71 Xplained Ultra evaluation board running form 2MiB external SDRAM. sp71 uses more than 2MiB of memory. paranoia reported several flaws and errors which is expected due to the lacking support for subnormal numbers in the FPU.

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:54:12 GMT
    2. component: changed from bsps to arch/arm
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2536 - RSB allows use of insecure hash algorithms like MD5 and SHA1

    Link https://devel.rtems.org/ticket/2536
    Id 2536
    Reporter Sebastian Huber
    Created 19 January 2016 07:01:10
    Modified 9 November 2017 06:27:14
    Owner Chris Johns <chrisj@…>
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Support for these hashes should be removed. Hashes should be mandatory.

    Comment 1
    1. Chris Johns, Tue, 19 Jan 2016 23:04:04 GMT

    Replying to sebastian.huber:

    Support for these hashes should be removed.

    Ok.

    Hashes should be mandatory.

    I had left it optional as we move to adding them. They can be mandatory now.

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Chris Johns, Thu, 12 Oct 2017 02:52:09 GMT
    2. owner: set to Chris Johns <chrisj@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In d94bd01/rtems-source-builder:

    4.12: Update all MD5 hashes to SHA256. Closes #2536.
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2537 - Use Newlib exec&#42() variants and remove RTEMS versions

    Link https://devel.rtems.org/ticket/2537
    Id 2537
    Reporter Joel Sherrill
    Created 19 January 2016 18:32:05
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In reviewing RTEMS+newlib POSIX conformance, I noticed that our newlib configuration does include the exec*() variants. All of these call _execve() which we already provided.

    This ticket is just to explain the removal of the RTEMS copies. The functional behavior to the user is still to return ENOSYS.

    Comment 1
    1. Joel Sherrill, Tue, 19 Jan 2016 18:33:27 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 22bb1b61cb4efe0c0dbe41057aac83bb5cffb5d3/rtems:

    posix/src/exec*: Remove all variants already in Newlib The RTEMS build of Newlib includes implementations of all exec*() variants. They rely on the _execve() support method. RTEMS already had this and it returned ENOSYS. There is no functional change. closes #2537.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2542 - Review cxx_iostream size change per function-section changes

    Link https://devel.rtems.org/ticket/2542
    Id 2542
    Reporter Joel Sherrill
    Created 23 January 2016 22:22:10
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type defect
    Component bsps
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc Ralph Holmes
    Blocking  
    Blocked by  

    Description

    It looks like some BSPs with their own linkcmds may have shrunk too much. Norm appears to be 50% while some went to 75-80%. A second look after catching the pattern indicates that the KEEP() section requirements in the linker scripts were not correct and it was missed.

    Rather than reverting a bunch of patches, this ticket is to review all function-section patches from this one back in time for cxx_iostream shrinking too much.

    commit 6d21c13e5094d490280a941cf0e8333f91f85715 Author: Ralph Holmes
    Date: Sat Jan 23 21:15:40 2016 +0000

    powerpc/gen5200: Add per-section compilation and linking support.

    For the brs5l BSP variant:

    Comment 1
    1. Joel Sherrill, Sat, 23 Jan 2016 22:25:02 GMT

    The following commits were made before this was noticed. Only those with a large cxx_iostream shrinkage or no cxx_iostream size need review.

    arm/beagle: Add per-section compilation and linking support arm/csb336: Add per-section compilation and linking support arm/csb337: Add per-section compilation and linking support arm/edb7312: Add per-section compilation and linking support arm/gdbarmsim: Add per-section compilation and linking support arm/gumstix: Add per-section compilation and linking support arm/lm3s69xx: Add per-section compilation and linking support arm/lpc176x: Add per-section compilation and linking support m68k/av5282: Add per-section compilation and linking support. m68k/csb360: Add per-section compilation and linking support. m68k/gen68302: Add per-section compilation and linking support. m68k/gen68340: Add per-section compilation and linking support. m68k/gen68360: Add per-section compilation and linking support. m68k/genmcf548x: Add per-section compilation and linking support. m68k/mcf5206elite: Add per-section compilation and linking support. m68k/mcf52235: Add per-section compilation and linking support. m68k/mcf5225x: Add per-section compilation and linking support. m68k/mcf5235: Add per-section compilation and linking support. m68k/mcf5329: Add per-section compilation and linking support. m68k/mrm332: Add per-section compilation and linking support. m68k/mvme147: Add per-section compilation and linking support. m68k/mvme147s: Add per-section compilation and linking support. m68k/mvme162: Add per-section compilation and linking support. m68k/mvme167: Add per-section compilation and linking support. m68k/ods68302: Add per-section compilation and linking support. m68k/uC5282: Add per-section compilation and linking support. mips/csb350: Add per-section compilation and linking support. mips/hurricane: Add per-section compilation and linking support. mips/malta: Add per-section compilation and linking support. mips/rbtx4925: Add per-section compilation and linking support. mips/rbtx4938: Add per-section compilation and linking support. powerpc/beatnik: Add per-section compilation and linking support. powerpc/gen5200: Add per-section compilation and linking support. powerpc/haleakala: Add per-section compilation and linking support. powerpc/mbx8xx: Add per-section compilation and linking support. powerpc/mpc8260ads: Add per-section compilation and linking support. powerpc/mvme3100: Add per-section compilation and linking support. powerpc/mvme5500: Add per-section compilation and linking support. powerpc/qemuppc: Add per-section compilation and linking support. powerpc/ss555: Add per-section compilation and linking support. powerpc/t32mppc: Add per-section compilation and linking support. powerpc/tqm8xx: Add per-section compilation and linking support. powerpc/virtex4: Add per-section compilation and linking support. powerpc/virtex5: Add per-section compilation and linking support. powerpc/virtex: Add per-section compilation and linking support.

    Comment 2
    1. Joel Sherrill, Sat, 23 Jan 2016 22:27:17 GMT
    2. owner: set to joel.sherrill@…
    3. version: changed from 4.10 to 4.12
    4. component: changed from General to bsps
    5. milestone: changed from 4.11.1 to 4.12
    Comment 3
    1. Joel Sherrill, Sat, 23 Jan 2016 22:36:47 GMT

    After a review of all potential BSPs, I have determined that these are the ones which are almost certainly missing KEEP() sections. This drops the set considerably.

    As a practical matter, the BSPs will be converted to use a shared linkcmds.base or have the use of function-sections disabled by commenting out the added lines. We need to work out the details but the same comment should be added above those lines like this (review and approve):

    # This BSP does not either (a) use a shared linkcmds base file or (b) include # proper KEEP() directives in its linkcmds* files. Because of these arguments # can not currently be enabled.

    powerpc/mbx8xx: Add per-section compilation and linking support. - removed per #2545. powerpc/haleakala: Add per-section compilation and linking support. - #2561. powerpc/ss555: Add per-section compilation and linking support. - #2563. powerpc/qemuppc: Add per-section compilation and linking support. - #2564. powerpc/mpc8260ads: Add per-section compilation and linking support. #2565. m68k/mvme162: Add per-section compilation and linking support. - now uses shared m68k/gen68360: Add per-section compilation and linking support. - #2566. m68k/mvme147s: Add per-section compilation and linking support. - now uses shared m68k/mvme147: Add per-section compilation and linking support. - now uses shared m68k/mrm332: Add per-section compilation and linking support. - #2657. m68k/mcf5225x: Add per-section compilation and linking support. - #2568. m68k/mcf5329: Add per-section compilation and linking support. - #2569. m68k/mcf52235: Add per-section compilation and linking support. - #2570. m68k/mcf5235: Add per-section compilation and linking support. - #2571. m68k/mcf5206elite: Add per-section compilation and linking support. - #2572. m68k/gen68340: Add per-section compilation and linking support. - #2573. m68k/av5282: Add per-section compilation and linking support. - #2574. m68k/mvme167: Add per-section compilation and linking support. - now uses shared m68k/gen68302: Add per-section compilation and linking support. - removed per #2543. m68k/uC5282: Add per-section compilation and linking support. - #2575. m68k/ods68302: Add per-section compilation and linking support. - removed per #2544. arm/lpc176x: Add per-section compilation and linking support. - #2576.

    Comment 4
    1. Joel Sherrill, Mon, 25 Jan 2016 20:14:25 GMT

    In 449905a8acaa5eac214c51ef2547b0321e86d6b2/rtems:

    m68k/mvme*: switch to shared linkcmds.base updates #2542.
    Comment 5
    1. Joel Sherrill, Sat, 06 Feb 2016 16:26:17 GMT

    All BSPs which had function sections enabled and clearly broke cxx_iostream should now have per function section linking disabled and a separate ticket filed.

    Comment 6
    1. Joel Sherrill, Sat, 06 Feb 2016 16:26:33 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 7
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 8
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2543 - Obsolete gen68302 BSP

    Link https://devel.rtems.org/ticket/2543
    Id 2543
    Reporter Joel Sherrill
    Created 23 January 2016 22:41:25
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc admin@…
    Blocking  
    Blocked by  

    Description

    Delete the gen68302 BSP after 4.11 and before 4.12.

    Attachments:

    1 Aun-Ali Zaidi, Mon, 03 Oct 2016 00:23:25 GMT
      attach: set to 0001-cpukit-m68k-Remove-leftover-bits-of-gen68302-BSP.patch
    Comment 1
    1. Aun-Ali Zaidi, Mon, 03 Oct 2016 00:43:25 GMT
    2. cc: admin@… added
    Comment 2
    1. Aun-Ali Zaidi, Mon, 03 Oct 2016 00:43:27 GMT
    2. cc: admin@… added
    Comment 3
    1. Sebastian Huber, Wed, 15 Feb 2017 13:49:47 GMT
    2. status: changed from new to assigned
    Comment 4
    1. Joel Sherrill, Mon, 03 Apr 2017 23:17:45 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    This was removed.

    Comment 5
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2544 - Osolete m68k/ods68302

    Link https://devel.rtems.org/ticket/2544
    Id 2544
    Reporter Joel Sherrill
    Created 23 January 2016 22:46:09
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type defect
    Component unspecified
    Status closed
    Resolution duplicate
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Obsolete and remove the ods68302 BSP before 4.12.

    Comment 1
    1. Joel Sherrill, Sat, 23 Jan 2016 22:47:08 GMT
    2. description: modified (diff)
    3. summary: changed from Osolete m68k/ods302 to Osolete m68k/ods68302
    Comment 2
    1. Aun-Ali Zaidi, Mon, 03 Oct 2016 00:48:55 GMT

    Duplicate of #2543.

    Comment 3
    1. Aun-Ali Zaidi, Mon, 03 Oct 2016 00:49:13 GMT
    2. status: changed from new to closed
    3. resolution: set to duplicate
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2545 - Obsolete mbx8xx BSP

    Link https://devel.rtems.org/ticket/2545
    Id 2545
    Reporter Joel Sherrill
    Created 23 January 2016 22:48:39
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Obsolete and remove.

    Comment 1
    1. Sebastian Huber, Wed, 15 Feb 2017 13:49:47 GMT
    2. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Mon, 03 Apr 2017 23:18:15 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    This is done.

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2546 - Obsolete idp BSP

    Link https://devel.rtems.org/ticket/2546
    Id 2546
    Reporter Joel Sherrill
    Created 23 January 2016 23:52:33
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type enhancement
    Component arch/m68k
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Obsolete and remove the m68k/idp BSP before the 4.12 release.

    Comment 1
    1. Joel Sherrill, Sat, 23 Jan 2016 23:57:02 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In f2ab5bc5943e1817540804117c4626151759681c/rtems:

    Remove m68k/idp BSP closes #2546.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:57:31 GMT
    2. component: changed from bsps to arch/m68k
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2553 - [mvme3100] boot_card() broken by 37030e38

    Link https://devel.rtems.org/ticket/2553
    Id 2553
    Reporter Nick Withers
    Created 27 January 2016 04:40:40
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Backtrace with ​37030e38__*__ (with a fatal exception handler installed):

    #0  fatal_extension (the_source=INTERNAL_ERROR_CORE, is_internal=true, the_error=23) at init.c:425
    #1 0x000a6d18 in _User_extensions_Iterate (arg=arg@entry=0x1ab6348, visitor=0xa6c70 <_User_extensions_Fatal_visitor>) at ../../../../../../../rtems/c/src/../../cpukit/score/src/userextiterate.c:155
    #2 0x000a1c90 in _User_extensions_Fatal (error=23, is_internal=true, source=INTERNAL_ERROR_CORE) at ../../cpukit/../../../mvme3100/lib/include/rtems/score/userextimpl.h:254
    #3 _Terminate (the_source=the_source@entry=INTERNAL_ERROR_CORE, is_internal=is_internal@entry=true, the_error=the_error@entry=23) at ../../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:44
    #4 0x0007ad40 in RTEMS_Malloc_Initialize (areas=areas@entry=0x1ab6398, area_count=area_count@entry=1, extend=extend@entry=0x0 )
    at ../../../../../../../rtems/c/src/../../cpukit/libcsupport/src/malloc_initialize.c:53
    #5 0x0005cf84 in bsp_work_area_initialize_default (area_size=, area_begin=) at ../../../../../.././mvme3100/lib/include/bsp/bootcard.h:183
    #6 bsp_work_area_initialize () at ../../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mvme3100/../../powerpc/shared/startup/bspgetworkarea.c:23
    #7 0x0005cec4 in boot_card (cmdline=) at ../../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mvme3100/../../shared/bootcard.c:80
    #8 0x00003294 in __rtems_entry_point () at ../../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mvme3100/start/start.S:89

    If I reverse the changes to ​c/src/lib/libbsp/shared/bootcard.c it works again.

    __*__ With RSB e3b9fb68 and the following RTEMS patches:

    • ​https://git.rtems.org/rtems/patch/?id=af418e8f6b76a14a1d543d79fc79aa469f06b47d
    • ​https://git.rtems.org/rtems/patch/?id=7a0c4854c6abe8665b7e50a3bafebce84e7872a4
    • ​https://git.rtems.org/rtems/patch/?id=4202a31f91ca3d19ca18f08730a4be52fb71cc04

    Attachments:

    1 Sebastian Huber, Wed, 27 Jan 2016 06:36:27 GMT
      attach: set to 0001-bsps-powerpc-Fix-startup.patch
    Comment 1
    1. Sebastian Huber, Wed, 27 Jan 2016 06:36:44 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Nick Withers, Wed, 27 Jan 2016 10:23:29 GMT

    Thank you again Sebastian, that's worked a treat!

    Comment 3
    1. Sebastian Huber, Wed, 27 Jan 2016 10:32:49 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In ab8e821c9ee36dc5c3b429c2ca28e90b2c30432f/rtems:

    bsps/powerpc: Fix startup Do work area initialization after bsp_start() for BSPs using the shared PowerPC work area initialization. Close #2553.
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Tue, 10 Oct 2017 06:56:19 GMT
    2. component: changed from bsps to arch/powerpc
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2554 - New watchdog handler implementation

    Link https://devel.rtems.org/ticket/2554
    Id 2554
    Reporter Sebastian Huber
    Created 27 January 2016 08:28:00
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Background

    The watchdog handler uses delta chains. The insert operation has a O(n) worst-case time complexity with n being the count of watchdogs in the delta chain. In each step of the insert operation, the SMP lock of the corresponding watchdog header is acquired and released. The profiling data obtain by test program smptests/smpwakeafter01 showed that the current implementation leads to unacceptable latencies, thus it should be replaced by something else.

    The use cases for the watchdog handler fall roughly into two categories.

    • Timeouts - used to detect if some operations needs more time than expected. Since the unexpected happens hopefully rarely, timeout timers are usually removed before they expire. The critical operations are insert and removal. They are important for the performance of a network stack.
    • Timers - used to carry out some work in the future. They usually expire and need a high resolution. An example user is a time driven scheduler, e.g. rate-monotonic or EDF.

    One approach is to use a red-black tree with the expiration time as the key. This leads to O(log(n)) worst-case insert and removal operations. For each operation it is sufficient to acquire and release the lock only once. The drawback is that a 64-bit integer type must be used for the intervals to avoid a potential overflow of the key values. With a system tick interval of 1ns the system could run more than 500 years before an overflow happens. The EDF scheduler would also profit from a 64-bit interval representation, see #2173.

    An alternative is the use of a ​timer wheel based algorithm which is used in Linux and ​FreeBSD for example. A timer wheel based algorithm offers O(1) worst-case time complexity for insert and removal operations. The drawback is that the run-time of the watchdog tick procedure is somewhat unpredictable due to the use of a hash table or cascading.

    Which approach should we choose? Since the watchdog serves the timeout and timer services in RTEMS we have to make some trade-offs. We recommend to use the red-black tree approach which offers a more predictable run-time behaviour and sacrifice the constant insert and removal operations offered by the timer wheel algorithms, see also ​https://www.kernel.org/doc/ols/2006/ols2006v1-pages-333-346.pdf. We can reuse the red-black tree support already used for the thread priority queues.

    The new watchdog handler implementation is a prerequisite to eliminate the Giant lock in the Classic Timer manager.

    Implementation

    Change the _Watchdog_Ticks_since_boot to a 64-bit integer type. Keep the Watchdog_Interval at 32-bit for backward compatibility. Replace the delta chains with a red-black tree. Use the ticks for timers with a relative expiration time. Use struct timespec or struct bintime for timers with an absolute expiration time. This has the benefit that we do not have to adjust the data structures in case the absolute time changes, e.g. due to NTP. It simplifies the POSIX timer services, since no conversion to ticks is necessary.

    Attachments:

    1 Sebastian Huber, Wed, 02 Mar 2016 08:02:23 GMT
      attach: set to tmtimer01-T4240-f831eff7387d9a4ae8460d639da660d5ae2ce4fa.png
    2 Sebastian Huber, Wed, 02 Mar 2016 08:02:37 GMT
      attach: set to tmtimer01-T4240-next.png
    Comment 1
    1. Sebastian Huber, Wed, 27 Jan 2016 09:39:52 GMT

    Profiling data (reduced to show only relevant information) obtained on the 24-processor T4240 system using the smptests/smpwakeafter01 test.

    
      
        3128351
        97821
        1435132321
        14671
        0
        21766
        10040
        124466623
        12396
      
      
        1548547
        79339
        1621381982
        20436
        0
        37
        11
        32946
        2791
      
      
        14893
        2978
        32
        55
        1158320573
        2009011082
        35986044
        6874
        6187
        8266
        35964717
      
      
        1803
        29041
        105
        5514
        87844
        4582492
        831
        831
        0
        0
        0
      
     

    The clock tick interval is 1ms (1000 ticks per second). We observe a maximum thread dispatch disabled time of 3.1ms on the first processor which serves the clock interrupt and 1.5ms on the other processors. There is no contention on the Giant lock. However, the watchdog lock is highly contended. The maximum acquire and section times are small compared to the maximum thread dispatch disabled time. The maximum interrupt time on the first processor is 0.012ms, so serving the clock interrupt is no a big deal This clearly indicates that the loop based updates of the delta chains are the main issue.

    Comment 2
    1. Sebastian Huber, Thu, 04 Feb 2016 11:59:40 GMT
    2. status: changed from new to accepted
    Comment 3
    1. Sebastian Huber, Wed, 17 Feb 2016 10:54:37 GMT

    In 10f28914f8bac5b8676ce1b9cc7efeccb2b33bb3/rtems:

    smptests/smpwakeafter01: Add scheduler config Update #2554.
    Comment 4
    1. Joel Sherrill, Thu, 18 Feb 2016 19:58:15 GMT

    I am not opposed to the use of RB Trees or the use of 64 bit time for absolute/calendar time.

    I would like to see us move away from ticks on the relative timer and move to something more like CLOCK_MONOTONIC based on uptime.

    I assume the new ticks key value will be the "watchdog ticks since boot" value to trigger the watchdogs on. I think this is really still OK based on the math but limits the durations one can delay and the granularity.

    The extra granularity may allow us to move to a tickless or variable clock tick in the future. Although I am still concerned that reprogramming the timer on the fly is potentially more dangerous and error prone than a fixed tick.

    Comment 5
    1. Sebastian Huber, Wed, 02 Mar 2016 08:01:39 GMT

    In f831eff7387d9a4ae8460d639da660d5ae2ce4fa/rtems:

    tmtests/tmtimer01: New test Test run performed on T4240 running at 1667MHz in uni-processor configuration. Update #2554.
    Comment 6
    1. Sebastian Huber, Wed, 02 Mar 2016 08:19:43 GMT

    Test results (some data omitted the middle) for new test tmtimer01 executed on a T4240 running at 1667MHz in uni-processor configuration using [f831eff7387d9a4ae8460d639da660d5ae2ce4fa/rtems]:

    
      
        0639732901527
      
      
        2198615501314
      
      
        4155121343072
      
      
        7254535113404
      
      
        10159523634287
      
      
        14147327406069
      
      
        5577219791181555721907509
      
      
        6550324041369459126215885
      
    Last> 

    Comment 7
    1. Sebastian Huber, Wed, 02 Mar 2016 08:22:54 GMT

    Test results (some data omitted the middle) for new test tmtimer01 executed on a T4240 running at 1667MHz in uni-processor configuration using the new red-black tree based implementation:

    
      
        088121412917
      
      
        2160210101367
      
      
        4152410891086
      
      
        7179111211838
      
      
        10148810162134
      
      
        14152716983186
      
      
        5577289491003116262
      
      
        6550391991030919090
      
     

    Comment 8
    1. Sebastian Huber, Wed, 02 Mar 2016 09:26:19 GMT

    Profiling data (reduced to show only relevant information) of smpwakeafter01 executed on a T4240 using 24 processors and the new red-black tree based implementation.

    
      
        85615
        15508
        563813241
        36355
        0
        4771
        482
        11144389
        23082
      
      
        53595
        14437
        493386525
        34175
        0
        3094
        844
        8783271
        10398
      
      
        87633
        15055
        561768649
        37314
        0
        4884
        447
        10309678
        23056
      
      
        1924
        89496
        116
        4644
        119374
        4751695
        1023
        1023
        0
        0
        0
      
      
        54115
        9609
        1154
        881
        1357899955
        1035917001
        1175742
        16188
        14403
        14350
        1130801
      
      
        686
        2220
        61
        78
        4271819
        5394270
        68964
        68964
        0
        0
        0
      
     

    The maximum thread dispatch disabled time drops from 3ms to about 100us. There is now one watchdog header per-CPU. Profiling data is only shown for one of the watchdog locks. No contention is visible here. The new bottle neck is the scheduler lock, but this is a different issue. In addition the interrupt count on scheduler A is about two times the clock tick interrupt count. This means that each clock tick service results in an inter-processor interrupt. This highlights one of the known problems of a global priority based scheduler: massive thread migrations.

    Comment 9
    1. Sebastian Huber, Fri, 04 Mar 2016 13:59:46 GMT

    [5b0d2c1965e1dab2915231866aaa5623ced66330/rtems] [90d8567d34a6d80da04b1cb37b667a3173f584c4/rtems] [03b900d3ed120ea919ea3eded7edbece3488cff3/rtems]

    Comment 10
    1. Sebastian Huber, Fri, 18 Mar 2016 06:47:28 GMT

    In 90de3001089a8de300d9339b2d8d49a51ebd9674/rtems:

    score: Destroy thread timer lock Update #2554.
    Comment 11
    1. Sebastian Huber, Thu, 12 May 2016 11:35:43 GMT

    In 1379d840a483ccdce109fa8e45ef63d51a6e8e00/rtems:

    smptests/smpcapture02: Adjust for clock changes Fix overall clock tick count. Change introduced by 90d8567d34a6d80da04b1cb37b667a3173f584c4. Update #2554.
    Comment 12
    1. Sebastian Huber, Fri, 23 Dec 2016 14:10:09 GMT
    2. priority: changed from normal to high
    Comment 13
    1. Sebastian Huber, Mon, 30 Jan 2017 12:53:21 GMT

    [a17535d222a1268542e97c7e6c1b2fdf045e46d8/rtems-docs]

    Comment 14
    1. Sebastian Huber, Mon, 30 Jan 2017 13:22:58 GMT

    [1161ed179c0be212b7909d6a761bfc31cacf4ca3/rtems-docs]

    Comment 15
    1. Sebastian Huber, Mon, 30 Jan 2017 13:23:07 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed
    Comment 16
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 17
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2555 - Eliminate the Giant lock

    Link https://devel.rtems.org/ticket/2555
    Id 2555
    Reporter Sebastian Huber
    Created 27 January 2016 08:35:06
    Modified 15 December 2017 06:24:12
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Background

    The standard approach to turn a uni-processor operating system into an SMP-capable operating system is to encapsulate virtually the complete operating system state and protect it by one global recursive lock - the Giant lock. Thus, at most one processor can modify the operating system state at a time. Under Giant lock protection interrupt disable/enable critical sections still work. This approach is easy to realize and leads to something that runs on SMP with a minimal effort. Unfortunately, such an operating system does not scale with the processor count and offers very poor performance. It is quite useless for real applications.

    The first steps to get rid of the Giant lock are tackled with the introduction of fine grained locking for the scheduler, watchdog handler, timestamps, thread queues, events, semaphores and message queues. The Giant lock is still used in a couple of places, e.g. all other objects using thread queues, thread life cycle changes (termination, restart) and scheduler changes. It is a straight forward task to eliminate it entirely, but it is also somewhat labour intensive since a lot of code must be changed.

    Implementation

    Eliminate all remaining code areas that use

    • _ISR_Disable(),
    • _ISR_Enable(), and
    • _ISR_Flash().

    Direct users of these macros are

    • _Chain_Append(),
    • _Chain_Extract(),
    • _Chain_Get(),
    • _Chain_Insert(), and
    • _Chain_Prepend().

    Each spot must be dealt with individually. Once this is done, delete these macros since they are now superfluous. Rename _ISR_Disable_without_giant() into _ISR_Locale_disable(). Rename _ISR_Enable_without_giant() into _ISR_Locale_enable().

    Eliminate all remaining code areas that use

    • _Thread_Disable_dispatch() and
    • _Thread_Enable_dispatch().

    A prominent user of this functions is _Objects_Get(). The following components are affected by these functions

    • Classic barrier handler,
    • Classic dual-ported memory handler,
    • Classic message queue handler,
    • Classic partition handler,
    • Classic rate-monotonic handler,
    • Classic region handler,
    • Classic semaphore handler,
    • Classic timer handler,
    • extension handler,
    • IO manager,
    • multi-processing management,
    • objects management,
    • POSIX barrier handler,
    • POSIX condition handler,
    • POSIX key handler,
    • POSIX message queue handler,
    • POSIX mutex handler,
    • POSIX rwlock handler,
    • POSIX semaphore handler,
    • POSIX spinlock handler,
    • POSIX timer handler,
    • signals,
    • thread cancellation,
    • thread life-cycle changes, and
    • thread scheduler changes.

    Once this is done, delete _Thread_Disable_dispatch() and _Thread_Enable_dispatch(). As a side-effect the Giant lock will be removed.

    Comment 1
    1. Sebastian Huber, Thu, 04 Feb 2016 11:59:58 GMT
    2. status: changed from new to accepted
    Comment 2
    1. Sebastian Huber, Fri, 04 Mar 2016 14:01:28 GMT

    [03b900d3ed120ea919ea3eded7edbece3488cff3/rtems]

    Comment 3
    1. Sebastian Huber, Fri, 04 Mar 2016 14:16:29 GMT

    In 9f5754b5c226202d0a35eb729e68cdd3a26c65fc/rtems:

    bsps: Avoid Giant lock in simulator clock driver Update #2555.
    Comment 4
    1. Sebastian Huber, Mon, 07 Mar 2016 07:38:38 GMT

    Depends on #2625, #2626, #2627, #2628. #2630 and #2631.

    Comment 5
    1. Sebastian Huber, Mon, 14 Mar 2016 08:31:00 GMT

    In 77e6eba7146ba2e2074b719eec01cc7c40bbe98b/rtems:

    score: Add and use _Objects_Get_local() This simplifies the handling with local-only objects. Update #2555.
    Comment 6
    1. Sebastian Huber, Tue, 15 Mar 2016 07:13:12 GMT

    In 18ff88962458f9b0aa1150a4cfc89ac5bdd622e7/rtems:

    score: Use ISR lock for IO driver registration Create implementation header file. Update #2555.
    Comment 7
    1. Sebastian Huber, Tue, 15 Mar 2016 07:13:27 GMT

    In df91dd9f34686567042b055a623ee2db9dbe7ae6/rtems:

    monitor: Use object allocator lock Use object allocator lock instead of disabled thread dispatching. Update #2555.
    Comment 8
    1. Sebastian Huber, Wed, 16 Mar 2016 06:17:33 GMT

    In 05ef28754ea2920133f24ce0d3c6e274408c3b75/rtems:

    sapi: Do not disable thread dispatching Do not disable thread dispatching to add a user extension. After startup, the object allocator lock is enough. Update #2555.
    Comment 9
    1. Sebastian Huber, Wed, 16 Mar 2016 06:20:19 GMT

    In 474b9beeaa5fd6153ffa8ffe10d09acdaa8609da/rtems:

    score: Use allocator lock in _Objects_Get_next() Use the object allocator lock in _Objects_Get_next() instead of disabled thread dispatching since object creation and deletion is covered by this lock. Update #2555.
    Comment 10
    1. Sebastian Huber, Thu, 17 Mar 2016 08:03:25 GMT

    In 75aef54d16baab507134a5011e955151b990dcf6/rtems:

    posix: Avoid Giant lock in sched_yield() Update #2555.
    Comment 11
    1. Sebastian Huber, Thu, 17 Mar 2016 08:03:38 GMT

    In f5bb299190750189e89849a178173a21d1afd104/rtems:

    rtems: Avoid Giant lock in rtems_task_mode() Update #2555.
    Comment 12
    1. Sebastian Huber, Thu, 17 Mar 2016 08:03:50 GMT

    In 92dee4ab9cf806553d0cdaeb4968d25ced4a8b3a/rtems:

    rtems: Avoid Giant lock in rtems_signal_catch() Update #2555.
    Comment 13
    1. Sebastian Huber, Mon, 21 Mar 2016 06:45:36 GMT

    In be8897644043e4378db7add02c3c9e1ac7fde563/rtems:

    mpci: Avoid Giant lock The object creation/deletion is protected by the object allocator lock. Update #2555.
    Comment 14
    1. Sebastian Huber, Tue, 22 Mar 2016 06:44:37 GMT

    In 30cac38f157f0b4bd10a9b310e3dd6fdfc1d242e/rtems:

    rtems: Use object allocator lock Object creation and destruction is protected by the object allocator lock and not disabled thread dispatching. Update #2555.
    Comment 15
    1. Sebastian Huber, Tue, 22 Mar 2016 07:05:48 GMT

    In 865f110b58d944db72a71296fe3f15a4b8de097a/rtems:

    score: Fix for RTEMS_DEBUG The rtems_extension_create() no longer uses the Giant lock. Ensure that we call _User_extensions_Add_set() only in the right context. Update #2555.
    Comment 16
    1. Sebastian Huber, Tue, 29 Mar 2016 11:43:38 GMT

    In 3feca902a2e2dac8e07637be6f5a68524a76f85a/rtems:

    score: Fix _Objects_MP_Is_remote() Bug introduced by be8897644043e4378db7add02c3c9e1ac7fde563. Update #2555.
    Comment 17
    1. Sebastian Huber, Thu, 31 Mar 2016 11:57:24 GMT

    In c01401c48128218189c0d50743c47679bcad7e0c/rtems:

    score: _User_extensions_Remove_set() Use unprotected chain operation in _User_extensions_Remove_set() since the caller must own the object allocator lock. Update #2555.
    Comment 18
    1. Sebastian Huber, Wed, 06 Apr 2016 08:32:19 GMT

    In d995a263b5de31583cd269c71a5ef760e98e8f26/rtems:

    score: Delete _Chain_Append() This function is not used in the score. Update #2555.
    Comment 19
    1. Sebastian Huber, Tue, 19 Apr 2016 05:23:00 GMT

    In 362722795abb917fb53d8903eae450c78ba43be4/rtems:

    sapi: Avoid Giant lock for extensions Extension create and delete is protected by the object allocator lock. Update #2555.
    Comment 20
    1. Sebastian Huber, Tue, 19 Apr 2016 05:23:26 GMT

    In 709f38a97287ff1aa8e8c0668c2d066e711db87c/rtems:

    score: Use chain iterator for user extensions Add a lock and use a chain iterator for safe iteration during concurrent user extension addition and removal. Ensure that dynamically added thread delete and fatal extensions are called in reverse order. Update #2555. Update #2692.
    Comment 21
    1. Sebastian Huber, Thu, 21 Apr 2016 05:34:38 GMT

    In 48b04fc388a60fc6621233ddbb7cd65d89bb63d8/rtems:

    posix: Avoid Giant lock for mutexes Delete _POSIX_Mutex_Get(). Use _POSIX_Mutex_Get_interrupt_disable() instead. Update #2555.
    Comment 22
    1. Sebastian Huber, Thu, 21 Apr 2016 05:34:49 GMT

    In adbedd10cfe5259018b1682d903ab40f6005b3f0/rtems:

    score: Introduce _Thread_queue_Flush_critical() Replace _Thread_queue_Flush() with _Thread_queue_Flush_critical() and add a filter function for customization of the thread queue flush operation. Update #2555.
    Comment 23
    1. Sebastian Huber, Wed, 27 Apr 2016 06:51:34 GMT

    In 7f4ee2b4ae39928ab5f449048e562ef6b2c5d17d/rtems:

    posix: Avoid Giant lock for condition variables Update #2555.
    Comment 24
    1. Sebastian Huber, Mon, 02 May 2016 10:07:32 GMT

    In 7e66865e17d7a82add541056de13717793da002a/rtems:

    score: Move message notification Move message notification to end of critical section and delegate the message queue release to the notification handler. It may do more complex notification actions out of the critical section. Update #2555.
    Comment 25
    1. Sebastian Huber, Mon, 02 May 2016 10:07:42 GMT

    In 6741d30a310695f4fe4c8acccb86ccf7389567bd/rtems:

    rtems: Avoid Giant lock for message queues Update #2555.
    Comment 26
    1. Sebastian Huber, Mon, 02 May 2016 10:07:53 GMT

    In c8982e5f6a4857444676165deab1e08dc91a6847/rtems:

    posix: Simplify message queues The mq_open() function returns a descriptor to a POSIX message queue object identified by a name. This is similar to sem_open(). In contrast to the POSIX semaphore the POSIX message queues use a separate object for the descriptor. This extra object is superfluous, since the object identifier can be used directly for this purpose, just like for the semaphores. Update #2702. Update #2555.
    Comment 27
    1. Sebastian Huber, Mon, 02 May 2016 10:08:03 GMT

    In f009ed086d3da813a2c92b9834c3b2d618894883/rtems:

    rtems: Avoid Giant lock for semaphores Update #2555.
    Comment 28
    1. Sebastian Huber, Mon, 02 May 2016 10:08:13 GMT

    In f4d541ccfe6a6e64a06cbf89bc7b03e045f62281/rtems:

    rtems: Avoid Giant lock in rtems_object_set_name() Update #2555.
    Comment 29
    1. Sebastian Huber, Mon, 02 May 2016 10:08:22 GMT

    In 77726405fab31a04834e95968d1942fc81d0644d/rtems:

    score: _Objects_Get_name_as_string() Avoid Giant lock in _Objects_Get_name_as_string(). Update #2555.
    Comment 30
    1. Sebastian Huber, Mon, 02 May 2016 10:08:41 GMT

    In 1ef8e4a8e93a848e2a68f37e029039300f1c936b/rtems:

    score: Avoid Giant lock for set time of day Update #2555. Update #2630.
    Comment 31
    1. Sebastian Huber, Mon, 02 May 2016 10:09:10 GMT

    In 259d885168b548b5ebea5067f112a0d8b94d167f/rtems:

    posix: Remove superfluous thread dispatch disable The _Thread_queue_Enqueue_critical() already deals with thread dispatching. Update #2555.
    Comment 32
    1. Sebastian Huber, Mon, 02 May 2016 10:09:20 GMT

    In 66374dfc0c42066fac5f9a62475029711baac735/rtems:

    posix: Avoid Giant lock in _POSIX_signals_Send() Update #2555. Update #2690.
    Comment 33
    1. Sebastian Huber, Wed, 04 May 2016 05:29:06 GMT

    [1d40d81b4b8dd50e4162b0b79b60d3312d2744e5/rtems]

    Comment 34
    1. Sebastian Huber, Wed, 04 May 2016 05:55:38 GMT

    In b30ab250f0967920d6c08eae776fb82e717da182/rtems:

    mpci: Avoid Giant lock in _MPCI_Process_response() Update #2555. Update #2703.
    Comment 35
    1. Sebastian Huber, Fri, 06 May 2016 06:18:14 GMT

    In bb2ad039a7246eecde65592a5116c86d3dede34b/rtems:

    rtems: Avoid Giant lock for signals Update #2555.
    Comment 36
    1. Sebastian Huber, Fri, 06 May 2016 06:18:27 GMT

    In 64051ec80b55c3945ace509fa275c21ab8c89ab1/rtems:

    posix: Avoid Giant lock in pthread_equal() Update #2555.
    Comment 37
    1. Sebastian Huber, Fri, 06 May 2016 06:18:40 GMT

    In f65f803a269784f6f05658054dd1709497ca5049/rtems:

    score: Avoid Giant lock for CBS scheduler Update #2555.
    Comment 38
    1. Sebastian Huber, Thu, 12 May 2016 11:34:25 GMT

    In 4d76300ae524f798bf665f6c28dca420fd23a59c/rtems:

    rtems: Avoid Giant lock for some task operations Avoid Giant lock for rtems_task_set_priority(), rtems_task_suspend() and rtems_task_resume(). Update #2555.
    Comment 39
    1. Sebastian Huber, Thu, 12 May 2016 11:34:34 GMT

    In 11c66437e750e6f8c464a96476c5f5221c1808a6/rtems:

    rtems: Avoid Giant lock rtems_task_is_suspended() Update #2555.
    Comment 40
    1. Sebastian Huber, Thu, 12 May 2016 11:34:44 GMT

    In bd12dda405e1bab16c522f7ef0dd2b455230d269/rtems:

    score: Use thread state lock for current state In addition protect scheduler of thread by thread state lock. Enables use of scheduler per-instance locks. Update #2555.
    Comment 41
    1. Sebastian Huber, Thu, 12 May 2016 11:34:54 GMT

    In e135271b933c896068a343b161773ce3b685be43/rtems:

    score: Avoid Giant lock _Scheduler_Set_affinity() Update #2555.
    Comment 42
    1. Sebastian Huber, Thu, 12 May 2016 11:35:04 GMT

    In d99529999451043166c6dbf3ef22be42463e16f3/rtems:

    score: Avoid Giant lock _Scheduler_Get_affinity() Update #2555.
    Comment 43
    1. Sebastian Huber, Thu, 12 May 2016 11:35:13 GMT

    In 8bc6bf28aa098a03c25763e3c59274874bfbe3da/rtems:

    posix: Avoid Giant lock for some pthread functions Avoid Giant lock for pthread_getattr_np(), pthread_setschedparam() and pthread_getschedparam(). Replace POSIX threads scheduler lock with thread state lock. Update #2555.
    Comment 44
    1. Sebastian Huber, Thu, 12 May 2016 11:35:23 GMT

    In ef6f8a8377964a2d94eb7215724d11b499ec078b/rtems:

    score: Avoid Giant lock for scheduler set/get Update #2555.
    Comment 45
    1. Sebastian Huber, Fri, 20 May 2016 05:56:47 GMT

    In e75374870375099eb097f189905be709008fb3c0/rtems:

    score: Delete redundant thread life enums This makes it easier to add more states in the future. Update #2555. Update #2626.
    Comment 46
    1. Sebastian Huber, Fri, 20 May 2016 05:56:57 GMT

    In b7f5e391c0c0e94e5958a294e5d38b1dda7332cc/rtems:

    score: Add _Thread_Exit() The goal is to make _Thread_Exit() a no-return function in follow up patches. Update #2555. Update #2626.
    Comment 47
    1. Sebastian Huber, Fri, 20 May 2016 05:57:07 GMT

    In 270394eef82ae584477cb9c443d4a5c8e67978eb/rtems:

    score: Avoid superfluous life protection Disable thread dispatching is enough to prevent deletion of the executing thread. There is no need for an additional life protection. Update #2555. Update #2626.
    Comment 48
    1. Sebastian Huber, Fri, 20 May 2016 05:57:17 GMT

    In 69c722f3f6ac84eca42e68eda0e1ed63fd3702e7/rtems:

    score: Delete unused variable Update #2555. Update #2626.
    Comment 49
    1. Sebastian Huber, Fri, 20 May 2016 05:57:27 GMT

    In 9949d8a7d042da7ba53516300db5c34c8b9c8a31/rtems:

    score: Add Thread_Change_life() Add _Thread_Change_life_locked() as a general function to alter the thread life state. Use it to implement _Thread_Set_life_protection() as a first step. Update #2555. Update #2626.
    Comment 50
    1. Sebastian Huber, Fri, 20 May 2016 05:57:37 GMT

    In 7023d82ca6bdfe7e0fa1d1c10481671dd744d894/rtems:

    score: Add _Thread_Raise_real_priority() Update #2555. Update #2626.
    Comment 51
    1. Sebastian Huber, Fri, 20 May 2016 05:57:47 GMT

    In c99eb50b9f66e76cdd6aa0833321550c9b9e655c/rtems:

    score: Rework _Thread_Exit() Rework _Thread_Exit() to use _Thread_Change_life_locked(). Update #2555. Update #2626.
    Comment 52
    1. Sebastian Huber, Fri, 20 May 2016 05:57:57 GMT

    In 232147ddc12d45ff7872f72a790077c26fe5ca0a/rtems:

    score: Add _Thread_Join() and _Thread_Cancel() Split _Thread_Close() into _Thread_Join() and _Thread_Cancel() to prepare for a re-use in pthread_join() and pthread_cancel(). Update #2555. Update #2626.
    Comment 53
    1. Sebastian Huber, Fri, 20 May 2016 05:58:07 GMT

    In 9a99ce15d0878d847b4c7e054eb2996a9f5fbc34/rtems:

    score: Add _Thread_Set_state_locked() This makes it possible to do thread state and thread life changes together under protection of the thread state lock. Update #2555. Update #2626.
    Comment 54
    1. Sebastian Huber, Fri, 20 May 2016 05:58:17 GMT

    In f410ea82a4b9d5609ce170d2aa09027b5a7c4c50/rtems:

    score: Add _Thread_Clear_state_locked() This makes it possible to do thread state and thread life changes together under protection of the thread state lock. Update #2555. Update #2626.
    Comment 55
    1. Sebastian Huber, Fri, 20 May 2016 05:58:27 GMT

    In 0475cca9a015a7b43209270ca6e40aebf177639a/rtems:

    score: Add _Thread_Dispatch_disable_with_CPU() Update #2555. Update #2626.
    Comment 56
    1. Sebastian Huber, Fri, 20 May 2016 05:58:37 GMT

    In 938839077741d2eac82d9d86705c16e0b9de8379/rtems:

    score: Split _Thread_Restart() Split _Thread_Restart() into _Thread_Restart_self() and _Thread_Restart_other(). Move content of existing _Thread_Restart_self() into new _Thread_Restart_self(). Avoid Giant lock for thread restart. _Thread_Restart_self() is a no-return function and used by _Thread_Global_construction(). Update #2555. Update #2626.
    Comment 57
    1. Sebastian Huber, Fri, 20 May 2016 05:58:47 GMT

    In 862a0eeb1197539c0e69381cb5aaccb9e1c64c0f/rtems:

    score: Rework _Thread_Restart_other() Rework _Thread_Restart_other() to use _Thread_Change_life_locked(). Cope with concurrent change requests by means of a pending request counter. Update #2555. Update #2626.
    Comment 58
    1. Sebastian Huber, Fri, 20 May 2016 05:58:58 GMT

    In ef09017ebb6ac9c1309df4e827b240c14e6dbaa9/rtems:

    score: Rework _Thread_Cancel() Rework _Thread_Cancel() to use _Thread_Change_life_locked(). Update #2555. Update #2626.
    Comment 59
    1. Sebastian Huber, Fri, 20 May 2016 05:59:08 GMT

    In 29e1ecab875c3121357f27e0676913d9ca96183f/rtems:

    score: Simplify _Thread_Life_action_handler() Use _Thread_Change_life_locked() to avoid duplicated code. Avoid Giant lock in _Thread_Life_action_handler(). Update #2555. Update #2626.
    Comment 60
    1. Sebastian Huber, Fri, 20 May 2016 05:59:18 GMT

    In 54550e048d3a49435912797d2024f80671e93267/rtems:

    posix: Rework pthread_join() Rework pthread_join() to use _Thread_Join(). Close #2402. Update #2555. Update #2626. Close #2714.
    Comment 61
    1. Sebastian Huber, Fri, 20 May 2016 05:59:29 GMT

    In 33829ce155069462ba410d396da431386369ed08/rtems:

    score: Avoid Giant lock for _Thread_Start() Update #2555.
    Comment 62
    1. Sebastian Huber, Fri, 20 May 2016 05:59:39 GMT

    In da82656065d09f7b6aa411ba361287afdd787204/rtems:

    posix: Rework thread cancellation Add Thread_Life_state::THREAD_LIFE_CHANGE_DEFERRED and rework the POSIX thread cancellation to use the thread life states. Update #2555. Update #2626.
    Comment 63
    1. Sebastian Huber, Fri, 20 May 2016 05:59:49 GMT

    In 64fe16636b45d7a3d64654707234b885f7ccbaf6/rtems:

    posix: Avoid Giant lock for pthread_kill() Update #2555.
    Comment 64
    1. Sebastian Huber, Fri, 20 May 2016 06:00:00 GMT

    In f36ada320dc075503a2c878bc4f9f7ff9d761d41/rtems:

    rtems: Avoid Giant lock for rtems_task_delete() Update #2555.
    Comment 65
    1. Sebastian Huber, Fri, 20 May 2016 06:00:09 GMT

    In 92f6883073126f96973252cd57a5c7e24d88d412/rtems:

    sptests/spintrcritical22: Avoid _Objects_Get() Use _Semaphore_Get_interrupt_disable() instead. Update #2555.
    Comment 66
    1. Sebastian Huber, Fri, 20 May 2016 06:00:19 GMT

    In 5eac967651866b0501593dcfea458452ef9e9128/rtems:

    testsuites: Replace _Thread_Get() Replace _Thread_Get() with _Thread_Get_interrupt_disable() to avoid the Giant lock. Update #2555.
    Comment 67
    1. Sebastian Huber, Fri, 20 May 2016 06:00:29 GMT

    In 23294fd2255031eefe708075064f58bf54d43279/rtems:

    score: Delete unused _Thread_Get() Update #2555.
    Comment 68
    1. Sebastian Huber, Fri, 20 May 2016 06:00:39 GMT

    In ee710ef483b76ebbd54cdc8fac05a228d9ef30ff/rtems:

    score: Delete unused _Objects_Get() Update #2555.
    Comment 69
    1. Sebastian Huber, Fri, 20 May 2016 06:00:48 GMT

    In b80156cf15a9e080e8608a30e3e2795211c03f3e/rtems:

    score: Avoid Giant _Objects_Extend_information() Avoid Giant lock for _Objects_Extend_information(). Update #2280. Update #2555.
    Comment 70
    1. Sebastian Huber, Fri, 20 May 2016 06:00:59 GMT

    In dab902d5b2688fe958118299f7d44d1adbf13878/rtems:

    testsuites: Avoid Giant lock Replace _Thread_Disable_dispatch() with _Thread_Dispatch_disable(). Replace _Thread_Enable_dispatch() with _Thread_Dispatch_enable(). This is a preparation to remove the Giant lock. Update #2555.
    Comment 71
    1. Sebastian Huber, Fri, 20 May 2016 06:01:09 GMT

    In d2bacb6c38c2bc0e47524b943200e16ad3c26bd8/rtems:

    score: _Thread_Dispatch_increment_disable_level() Avoid _Thread_Dispatch_increment_disable_level() and _Thread_Dispatch_decrement_disable_level() and thus the Giant lock. This is a preparation to remove the Giant lock. Update #2555.
    Comment 72
    1. Sebastian Huber, Fri, 20 May 2016 06:01:19 GMT

    In 4b04cb61552dbaa1a42a64e2f7b823708127e488/rtems:

    score: Rename _ISR_Disable_without_giant() Rename _ISR_Disable_without_giant() into _ISR_Local_disable(). Rename _ISR_Enable_without_giant() into _ISR_Local_enable(). This is a preparation to remove the Giant lock. Update #2555.
    Comment 73
    1. Sebastian Huber, Fri, 20 May 2016 06:01:29 GMT

    In 247131632173158cb2668d4e5c7464951b668067/rtems:

    score: Rename _ISR_Disable() and _ISR_Enable() Rename _ISR_Disable() into _ISR_Local_disable(). Rename _ISR_Enable() into _ISR_Local_enable(). Remove _Debug_Is_owner_of_giant(). This is a preparation to remove the Giant lock. Update #2555.
    Comment 74
    1. Sebastian Huber, Fri, 20 May 2016 06:01:39 GMT

    In c2f301b580ebb4a46d657651a814bc9348103546/rtems:

    score: Rename _ISR_Flash() into _ISR_Local_flash() This is a preparation to remove the Giant lock. Update #2555.
    Comment 75
    1. Sebastian Huber, Fri, 20 May 2016 06:01:48 GMT

    In ceb0f6597c36fabbfcbdf0807fd87dd03a45cc5e/rtems:

    score: Remove the Giant lock Update #2555.
    Comment 76
    1. Sebastian Huber, Mon, 19 Dec 2016 13:47:29 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    [09078e0e51531f3b8e166506bdf4719f5ff78717/rtems-docs]

    Comment 77
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 78
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 79
    1. Sebastian Huber, Fri, 15 Dec 2017 06:24:12 GMT

    In e1563f37/rtems:

    posix: Remove unused global variable Update #2702. Update #2555.

    2556 - Implement the O(m) Independence-Preserving Protocol (OMIP)

    Link https://devel.rtems.org/ticket/2556
    Id 2556
    Reporter Sebastian Huber
    Created 27 January 2016 08:45:27
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority high
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Background

    The O(m) Independence-Preserving Protocol (​OMIP) is a generalization of the priority inheritance protocol to clustered scheduling which avoids the non-preemptive sections present with priority boosting. The m denotes the number of processors in the system. Its implementation requires an extension of the scheduler helping protocol already used for the ​MrsP semaphores. However, the current implementation of the scheduler helping protocol has two major issues, see Catellani, Sebastiano, Luca Bonato, Sebastian Huber, and Enrico Mezzetti: Challenges in the Imple- mentation of MrsP. In Reliable Software Technologies - Ada-Europe 2015, pages 179–195, 2015. Firstly, the run-time of some scheduler operations depend on the size of the resource dependency tree. Secondly, the scheduler operations of threads which don't use shared resources must deal with the scheduler helping protocol in case an owner of a shared resource is somehow involved.

    To illustrate the second issue, let us look at the following example. We have a system with eight processors and two L2 caches. We assign processor 0 to a partition P for latency sensitive real-time tasks (e.g. sensor and actuator handling), processors 1, 2 and 3 are assigned to a cluster CA and the remaining processors are assigned to a cluster CB for soft real-time worker tasks. The worker tasks use a shared resource, e.g. a file system for data storage. Let us suppose a task R of partition P sends a message to the workers. This may make a waiting worker ready, which in turn pre-empts the owner of a shared resource. In this case the scheduler helping protocol takes action and is carried out by the task R. This contradicts the intended isolation of scheduler instances.

    The reason for this unfortunate coupling is a design issue of the scheduler helping protocol implementation. Some scheduler operations may return a thread in need of help. For example, if a thread is unblocked which pre-empts an owner of a shared resource, then the pre-empted thread is returned. Once a thread in need of help is returned, the ask for help operation of the scheduler is executed. An alternative to this return value based approach is the introduction of a pre-emption intervention during thread dispatching. Threads taking part in the scheduler helping protocol indicate this with a positive resource count value. In case a thread dispatch occurs and pre-empts an owner of a shared resource, the scheduler ask for help operation is invoked. So, the work is carried out on behalf of the thread which takes part in the scheduler helping protocol.

    To overcome the first issue, an improved resource dependency tracking is required. One approach is to use a recursive red-black tree based data structure, see #2412.

    Implementation

    There are several steps necessary to implement OMIP.

    • Introduce per-scheduler locks.
    • Enable context switches with interrupts enabled.
    • Add a pre-emption intervention to the thread dispatch.
    • Add a table for priority nodes to the thread control block. For each scheduler instance there is one priority node.
    • Update the table in case the thread blocks on a resource, a timeout while waiting for a resource occurs, or ownership of a resource is transferred to the thread.
    • Use this table in the pre-emption intervention.
    • Update the MrsP implementation to the new infrastructure.

    Currently, only one scheduler lock for all scheduler instances is used. This simplified the MrsP implementation and due to the presence of a Giant lock, this was not an issue. With the elimination of the Giant lock, however, we need one scheduler lock per scheduler instance to really profit from a decoupled system due to clustered scheduling.

    The current implementation of thread dispatching has some implications with respect to the interrupt latency. It is crucial to preserve the system invariant that a thread can execute on at most one processor in the system at a time. This is accomplished with a boolean indicator in the thread context. The processor architecture specific context switch code will mark that a thread context is no longer executing and waits that the heir context stopped execution before it restores the heir context and resumes execution of the heir thread (the boolean indicator is basically a TTAS lock). So, there is one point in time in which a processor is without a thread. This is essential to avoid cyclic dependencies in case multiple threads migrate at once. Otherwise some supervising entity is necessary to prevent deadlocks. Such a global supervisor would lead to scalability problems so this approach is not used. Currently the context switch is performed with interrupts disabled. Thus in case the heir thread is currently executing on another processor, the time of disabled interrupts is prolonged since one processor has to wait for another processor to make progress.

    If we add pre-emption intervention to the thread dispatch sequence, then there is an even greater need to avoid this issue with the interrupt latency. Interrupts normally store the context of the interrupted thread on its stack. In case a thread is marked as not executing, we must not use its thread stack to store such an interrupt context. We cannot use the heir stack before it stopped execution on another processor. If we enable interrupts during this transition, then we have to provide an alternative thread independent stack for interrupts in this time frame.

    The pre-emption intervention should be added to _Thread_Do_dispatch() before the heir is read and perform the following pseudo-code actions.

    pre_emption_intervention(executing):
    if executing.resource_count > 0:
    executing.lock()
    if executing.is_ready():
    for scheduler in executing.schedulers:
    scheduler.lock()
    if !executing.is_scheduled():
    for scheduler in executing.schedulers:
    scheduler.ask_for_help(executing)
    for scheduler in executing.schedulers:
    scheduler.unlock()
    else if executing.active_help_level > 0:
    idle.use(executing.scheduler_node)
    executing.unlock()

    The scheduler help operation affects multiple scheduler instances. In terms of locking we have only two options,

    • use a global scheduler lock, or
    • obtain multiple per-scheduler locks at once.

    A global scheduler lock is not an option. To avoid deadlocks obtain the per-scheduler locks in a fixed order. However, in this case the per-scheduler locks will observe different worst-case and average-case acquire times (depending on the order).

    Use a recursive data structure to determine the highest priority available to a thread for each scheduler instance, e.g.

    typedef struct Thread_Priority_node {
    Priority_Control current_priority;
    Priority_Control real_priority;
    struct Thread_Priority_node *owner;
    RBTree_Node Node;
    RBTree_Control Inherited_priorities;
    } Thread_Priority_node;
    typedef struct {
    ...
    Thread_Priority_node *priority_nodes; /* One per scheduler instances */
    ...
    } Thread_Control;

    Initially a thread has a priority node reflecting its real priority. The Thread_Priority_node::owner is NULL. The Thread_Priority_node::current_priority is set to the real priority. The Thread_Priority_node::Inherited_priorities is empty.

    In case the thread must wait for ownership of a mutex, then it enqueues its priority node in Thread_Priority_node::Inherited_priorities of the mutex owner.

    In case the thread is dequeued from the wait queue of a mutex, then it dequeues its priority node in Thread_Priority_node::Inherited_priorities of the previous mutex owner (ownership transfer) or the current mutex owner (acquire timeout).

    In case the minimum of the Thread_Priority_node::real_priority and the Thread_Priority_node::Inherited_priorities changes, then Thread_Priority_node::current_priority is updated. In case the Thread_Priority_node::owner its not NULL, the priority change propagates to the owner, and so on. In case Thread_Priority_node::current_priority changes, the corresponding scheduler is notified.

    Use the thread lock to protect the priority nodes.

    Attachments:

    1 Sebastian Huber, Wed, 27 Jan 2016 08:49:03 GMT
      attach: set to resource.png
    2 Sebastian Huber, Wed, 27 Jan 2016 08:49:16 GMT
      attach: set to help.png
    Comment 1
    1. Sebastian Huber, Wed, 27 Jan 2016 08:46:27 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Wed, 27 Jan 2016 08:52:02 GMT

    This is an example resource dependency tree with sixteen threads t0 up to t15 and sixteen resources r0 up to r15. The root of this tree is t0. The thread t0 owns the resources r0, r1, r2, r3, r6, r11 and r12 and is in the ready state. The threads t1 up to t15 wait directly or indirectly via resources owned by t0 and are in a blocked state. The colour of the thread nodes indicate the scheduler instance.

    Comment 3
    1. Sebastian Huber, Wed, 27 Jan 2016 08:54:45 GMT

    This is an example of a table of priority nodes with sixteen threads t0 up to t15 and three scheduler instances s0 up to s2 corresponding to the previous example. The overall resource owner is t0. The colour of the nodes indicate the scheduler instance. Several threads of different scheduler instances depend on thread t10. So, the thread t10 contributes for example the highest priority node of scheduler instance s2 to thread t0 even though it uses scheduler instance s0.

    Comment 4
    1. Sebastian Huber, Thu, 04 Feb 2016 12:00:29 GMT
    2. status: changed from new to accepted
    Comment 5
    1. Sebastian Huber, Thu, 12 May 2016 11:34:06 GMT

    In 6e4f929296b1cfd50fc8f41f117459e65214b816/rtems:

    score: Introduce thread state lock Update #2556.
    Comment 6
    1. Sebastian Huber, Fri, 20 May 2016 14:13:25 GMT

    In 7dfb4b970cbd22cef170b2f45a41f445406a2ce5/rtems:

    score: Add per scheduler instance maximum priority The priority values are only valid within a scheduler instance. Thus, the maximum priority value must be defined per scheduler instance. The first scheduler instance defines PRIORITY_MAXIMUM. This implies that RTEMS_MAXIMUM_PRIORITY and POSIX_SCHEDULER_MAXIMUM_PRIORITY are only valid for threads of the first scheduler instance. Further API/implementation changes are necessary to fix this. Update #2556.
    Comment 7
    1. Sebastian Huber, Fri, 20 May 2016 14:13:35 GMT

    In 8a040fe4eeb9f7ba5c9f95f8abd45b9b6d5f7c4b/rtems:

    score: Use _RBTree_Insert_inline() Use _RBTree_Insert_inline() for priority thread queues. Update #2556.
    Comment 8
    1. Sebastian Huber, Wed, 22 Jun 2016 12:47:47 GMT

    In 77ff5599e0d8e6d91190a379be21a332f83252b0/rtems:

    score: Introduce map priority scheduler operation Introduce map/unmap priority scheduler operations to map thread priority values from/to the user domain to/from the scheduler domain. Use the map priority operation to validate the thread priority. The EDF schedulers use this new operation to distinguish between normal priorities and priorities obtain through a job release. Update #2173. Update #2556.
    Comment 9
    1. Sebastian Huber, Wed, 22 Jun 2016 12:48:45 GMT

    In 9bfad8cd519f17cbb26a672868169fcd304d5bd5/rtems:

    score: Add thread priority to scheduler nodes The thread priority is manifest in two independent areas. One area is the user visible thread priority along with a potential thread queue. The other is the scheduler. Currently, a thread priority update via _Thread_Change_priority() first updates the user visble thread priority and the thread queue, then the scheduler is notified if necessary. The priority is passed to the scheduler via a local variable. A generation counter ensures that the scheduler discards out-of-date priorities. This use of a local variable ties the update in these two areas close together. For later enhancements and the OMIP locking protocol implementation we need more flexibility. Add a thread priority information block to Scheduler_Node and synchronize priority value updates via a sequence lock on SMP configurations. Update #2556.
    Comment 10
    1. Sebastian Huber, Wed, 27 Jul 2016 08:56:15 GMT

    In f4d1f307926b6319e5d3b325dbe424901285dec1/rtems:

    score: Split _Thread_Change_priority() Update #2412. Update #2556. Update #2765.
    Comment 11
    1. Sebastian Huber, Wed, 27 Jul 2016 08:56:26 GMT

    In ac8402ddd6e4a8eb6defb98220d39d4c20a6f025/rtems:

    score: Simplify _Thread_queue_Boost_priority() Raise the priority under thread queue lock protection and omit the superfluous thread queue priority change, since the thread is extracted anyway. The unblock operation will pick up the new priority. Update #2412. Update #2556. Update #2765.
    Comment 12
    1. Sebastian Huber, Wed, 27 Jul 2016 08:56:36 GMT

    In 3a58dc863157bb21054a144c1a21b690544c0d23/rtems:

    score: Priority inherit thread queue operations Move the priority change due to priority interitance to the thread queue enqueue operation to simplify the locking on SMP configurations. Update #2412. Update #2556. Update #2765.
    Comment 13
    1. Sebastian Huber, Wed, 27 Jul 2016 08:56:46 GMT

    In 1fcac5adc5ed38fb88ce4c6d24b2ca2e27e3cd10/rtems:

    score: Turn thread lock into thread wait lock The _Thread_Lock_acquire() function had a potentially infinite run-time due to the lack of fairness at atomic operations level. Update #2412. Update #2556. Update #2765.
    Comment 14
    1. Sebastian Huber, Wed, 27 Jul 2016 08:56:57 GMT

    In d79df38c2bea50112214ade95776cb90d693e390/rtems:

    score: Add deadlock detection The mutex objects use the owner field of the thread queues for the mutex owner. Use this and add a deadlock detection to _Thread_queue_Enqueue_critical() for thread queues with an owner. Update #2412. Update #2556. Close #2765.
    Comment 15
    1. Sebastian Huber, Wed, 03 Aug 2016 11:58:00 GMT

    In ff2e6c647d166fa54769f3c300855ef7f8020668/rtems:

    score: Fix and simplify thread wait locks There was a subtile race condition in _Thread_queue_Do_extract_locked(). It must first update the thread wait flags and then restore the default thread wait state. In the previous implementation this could lead under rare timing conditions to an ineffective _Thread_Wait_tranquilize() resulting to a corrupt system state. Update #2556.
    Comment 16
    1. Sebastian Huber, Thu, 04 Aug 2016 06:29:02 GMT

    In 1c1e31f788b85bf3bcadea675110eec35a612eb4/rtems:

    score: Optimize _Thread_queue_Path_release() Update #2556.
    Comment 17
    1. Sebastian Huber, Thu, 08 Sep 2016 07:57:08 GMT

    In e27421f38661ea18b2a663776ad524afadeba607/rtems:

    score: Move scheduler node to own header file This makes it possible to add scheduler nodes to structures defined in . Update #2556.
    Comment 18
    1. Sebastian Huber, Thu, 08 Sep 2016 07:57:18 GMT

    In 15b5678dcd72a11909a54b63ddc8e57869d63244/rtems:

    score: Move thread wait node to scheduler node Update #2556.
    Comment 19
    1. Sebastian Huber, Thu, 08 Sep 2016 07:57:27 GMT

    In 52a661e8f8124b77b29a2ed44c7814fd0a7cf358/rtems:

    score: Add scheduler node implementation header Update #2556.
    Comment 20
    1. Sebastian Huber, Wed, 21 Sep 2016 07:05:43 GMT

    In 300f6a481aaf9e6d29811faca71bf7104a01492c/rtems:

    score: Rework thread priority management Add priority nodes which contribute to the overall thread priority. The actual priority of a thread is now an aggregation of priority nodes. The thread priority aggregation for the home scheduler instance of a thread consists of at least one priority node, which is normally the real priority of the thread. The locking protocols (e.g. priority ceiling and priority inheritance), rate-monotonic period objects and the POSIX sporadic server add, change and remove priority nodes. A thread changes its priority now immediately, e.g. priority changes are not deferred until the thread releases its last resource. Replace the _Thread_Change_priority() function with _Thread_Priority_perform_actions(), _Thread_Priority_add(), _Thread_Priority_remove(), _Thread_Priority_change(), and _Thread_Priority_update(). Update #2412. Update #2556.
    Comment 21
    1. Sebastian Huber, Wed, 21 Sep 2016 07:05:58 GMT

    In 5d6b21198140f406a71599a2d388b6ec47ee3337/rtems:

    score: Add scheduler node table for each thread Update #2556.
    Comment 22
    1. Sebastian Huber, Wed, 21 Sep 2016 07:06:10 GMT

    In 266d3835d883f908c0e4cbf547359d683f72dcc4/rtems:

    score: Manage scheduler nodes via thread queues Update #2556.
    Comment 23
    1. Sebastian Huber, Wed, 21 Sep 2016 07:06:34 GMT

    In 8123cae864579219e5003a67b451ca4cc07d998b/rtems:

    rtems: Add rtems_task_get_priority() Update #2556. Update #2784.
    Comment 24
    1. Sebastian Huber, Wed, 21 Sep 2016 07:06:48 GMT

    In f6142c19f192e40ee1aa9ff67eb1c711343c157d/rtems:

    score: Scheduler node awareness for thread queues Maintain the priority of a thread for each scheduler instance via the thread queue enqueue, extract, priority actions and surrender operations. This replaces the primitive priority boosting. Update #2556.
    Comment 25
    1. Sebastian Huber, Wed, 02 Nov 2016 09:06:30 GMT

    In d097b54633fe98d4370154de5bdea44c32e81648/rtems:

    score: Rename scheduler ask for help stuff Rename the scheduler ask for help stuff since this will be replaced step by step with a second generation of the scheduler helping protocol. Keep the old one for now in parallel to reduce the patch set sizes. Update #2556.
    Comment 26
    1. Sebastian Huber, Wed, 02 Nov 2016 09:06:40 GMT

    In 501043a18bae037ca7195ce6989d3ffa8cc72660/rtems:

    score: Pass scheduler node to update priority op This enables to call this scheduler operation for all scheduler nodes available to a thread. Update #2556.
    Comment 27
    1. Sebastian Huber, Wed, 02 Nov 2016 09:06:50 GMT

    In 2df4abcee2fd762a9688bef13e152d5b81cc763e/rtems:

    score: Pass scheduler node to yield operation Changed for consistency with other scheduler operations. Update #2556.
    Comment 28
    1. Sebastian Huber, Wed, 02 Nov 2016 09:07:00 GMT

    In e382a1bfccdecf1dcf01c452ee0edb5afa0660b3/rtems:

    score: Pass scheduler node to block operation Changed for consistency with other scheduler operations. Update #2556.
    Comment 29
    1. Sebastian Huber, Wed, 02 Nov 2016 09:07:10 GMT

    In 72e0bdba4580072c33da09fcacbd3063dbc4f2c1/rtems:

    score: Pass scheduler node to unblock operation Changed for consistency with other scheduler operations. Update #2556.
    Comment 30
    1. Sebastian Huber, Wed, 02 Nov 2016 09:07:20 GMT

    In 3a724113f953490e05704582fb1effbf6c8e9601/rtems:

    score: Simplify _Scheduler_SMP_Node_change_state() Update #2556.
    Comment 31
    1. Sebastian Huber, Wed, 02 Nov 2016 09:07:30 GMT

    In 1c9688a9a11c08eabd6443d8bb9ccd439dce82e5/rtems:

    score: Add _Scheduler_Node_get_scheduler() Update #2556.
    Comment 32
    1. Sebastian Huber, Wed, 02 Nov 2016 09:07:40 GMT

    In 36d7abad13474c6c7211dc07643287747d4594bb/rtems:

    score: Add _Thread_Scheduler_add_wait_node() Update #2556.
    Comment 33
    1. Sebastian Huber, Wed, 02 Nov 2016 09:07:50 GMT

    In 70c22d939513dd05171d99cb053dc8f71135ee25/rtems:

    score: Add _Thread_Scheduler_remove_wait_node() Update #2556.
    Comment 34
    1. Sebastian Huber, Wed, 02 Nov 2016 09:08:00 GMT

    In 07a32d193257f150e5237970a7fa864ab71817b3/rtems:

    score: Add thread scheduler lock Update #2556.
    Comment 35
    1. Sebastian Huber, Wed, 02 Nov 2016 09:08:10 GMT

    In a7a8ec03258a7e59a300919485cbbd5f37782416/rtems:

    score: Protect thread scheduler state changes Update #2556.
    Comment 36
    1. Sebastian Huber, Wed, 02 Nov 2016 09:08:20 GMT

    In edb020ca678c78e4a1a7ba4becbc46a2d6bf24c7/rtems:

    score: Protect thread CPU by thread scheduler lock Update #2556.
    Comment 37
    1. Sebastian Huber, Wed, 02 Nov 2016 09:08:30 GMT

    In ebdd2a343181ef5f3fc2f1330930b0ea5c0ed8a4/rtems:

    score: Add scheduler node requests Add the ability to add/remove scheduler nodes to/from the set of scheduler nodes available to the schedulers for a particular thread. Update #2556.
    Comment 38
    1. Sebastian Huber, Wed, 02 Nov 2016 09:08:39 GMT

    In 240347331d45b0d424077a8b74ee02efc651e003/rtems:

    score: Add _Thread_Scheduler_process_requests() Update #2556.
    Comment 39
    1. Sebastian Huber, Wed, 02 Nov 2016 09:08:50 GMT

    In 351c14dfd00e1bdaced2823242532cab4bccb58c/rtems:

    score: Add new SMP scheduler helping protocol Update #2556.
    Comment 40
    1. Sebastian Huber, Wed, 02 Nov 2016 09:08:59 GMT

    In 6a82f1ae8c1cd3d24b4ad6dc78431ffffb214151/rtems:

    score: Yield support for new SMP helping protocol Update #2556.
    Comment 41
    1. Sebastian Huber, Wed, 02 Nov 2016 09:09:09 GMT

    In 913864c0b85c9e94140515a44e79d13e999ff9a2/rtems:

    score: Use scheduler instance specific locks Update #2556.
    Comment 42
    1. Sebastian Huber, Wed, 02 Nov 2016 09:09:19 GMT

    In 3a2724805421098df505c0acea106fb294bc2f6a/rtems:

    score: First part of new MrsP implementation Update #2556.
    Comment 43
    1. Sebastian Huber, Wed, 02 Nov 2016 09:09:30 GMT

    In 73a193fdd672486f57ec6db5f9beb50e5264ffac/rtems:

    score: Delete unused functions Delete _Scheduler_Thread_change_resource_root() and _Scheduler_Thread_change_help_state(). Update #2556.
    Comment 44
    1. Sebastian Huber, Wed, 02 Nov 2016 09:09:40 GMT

    In 97f7dac6604b448f0c4ee10f02d192ea42bc6aaa/rtems:

    score: Delete _Scheduler_Ask_for_help_if_necessary Delete Thread_Control::Resource_node. Update #2556.
    Comment 45
    1. Sebastian Huber, Wed, 02 Nov 2016 09:10:09 GMT

    In 6771359fa1488598ccba3fd3c440b95f64965340/rtems:

    score: Second part of new MrsP implementation Update #2556.
    Comment 46
    1. Sebastian Huber, Wed, 02 Nov 2016 09:10:19 GMT

    In 1cafc4664689040d67033d81c9d2e25929d44477/rtems:

    score: Delete Resource Handler Update #2556.
    Comment 47
    1. Sebastian Huber, Wed, 02 Nov 2016 09:10:29 GMT

    In b5f1b249028ea2be69a4ad06aa822c16cb4ac57e/rtems:

    score: Delete Scheduler_Node::accepts_help Update #2556.
    Comment 48
    1. Sebastian Huber, Wed, 02 Nov 2016 09:10:39 GMT

    In c0f1f52763b3a231a329da0162979207519a6db6/rtems:

    score: Delete Thread_Scheduler_control::node Update #2556.
    Comment 49
    1. Sebastian Huber, Wed, 02 Nov 2016 09:10:48 GMT

    In 7f7424329eafab755381bc638c2cdddc152a909b/rtems:

    score: Delete Thread_Scheduler_control::own_node Update #2556.
    Comment 50
    1. Sebastian Huber, Wed, 02 Nov 2016 09:10:59 GMT

    In 2dd098a6359d9df132da09201ea0506c5389dc80/rtems:

    score: Introduce Thread_Scheduler_control::home Replace Thread_Scheduler_control::control and Thread_Scheduler_control::own_control with new Thread_Scheduler_control::home. Update #2556.
    Comment 51
    1. Sebastian Huber, Wed, 02 Nov 2016 09:11:08 GMT

    In 63e2ca1b8b0a651a733d4ac3e0517397d0681214/rtems:

    score: Simplify yield and unblock scheduler ops Update #2556.
    Comment 52
    1. Sebastian Huber, Fri, 23 Dec 2016 14:10:09 GMT
    2. priority: changed from normal to high
    Comment 53
    1. Sebastian Huber, Wed, 01 Feb 2017 06:59:55 GMT
    2. status: changed from accepted to closed
    3. version: 4.12 deleted
    4. resolution: set to fixed

    [8add1793d25b2f76d564028f991cac31e0f871b4/rtems-docs]

    Comment 54
    1. Sebastian Huber, Fri, 03 Feb 2017 09:58:05 GMT

    In ca1e546e7772838b20d0792155e2c71514d6b5d3/rtems:

    score: Improve scheduler helping protocol Only register ask for help requests in the scheduler unblock and yield operations. The actual ask for help operation is carried out during _Thread_Do_dispatch() on a processor related to the thread. This yields a better separation of scheduler instances. A thread of one scheduler instance should not be forced to carry out too much work for threads on other scheduler instances. Update #2556.
    Comment 55
    1. Sebastian Huber, Tue, 07 Mar 2017 12:21:24 GMT

    In 088acbb0/rtems:

    score: Fix scheduler yield in SMP configurations Check that no ask help request is registered during unblock and yield scheduler operations. There is no need to ask for help if a scheduled thread yields, since this is already covered by the pre-emption detection. Update #2556.
    Comment 56
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 57
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2557 - Add word splitting to print output

    Link https://devel.rtems.org/ticket/2557
    Id 2557
    Reporter Amar Takhar
    Created 30 January 2016 21:03:09
    Modified 9 November 2017 06:27:14
    Owner Amar Takhar
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Chris Johns, Sun, 31 Jan 2016 20:27:25 GMT

    The word splitting needs to be in the index. At the moment the Sphinx generated PDF output's indexes overflow with the longer entries. We need to have these entries word split. The Texinfo indexes do this.

    Comment 2
    1. Chris Johns, Sat, 14 Jan 2017 20:42:30 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    The latext style has been updated to fix this.

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2559 - Delete the EXTERN pattern

    Link https://devel.rtems.org/ticket/2559
    Id 2559
    Reporter Sebastian Huber
    Created 3 February 2016 11:51:17
    Modified 30 April 2020 22:06:27
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Change the following pattern:
    some.h:

    #ifndef SOME_XYZ_EXTERN
    #define SOME_XYZ_EXTERN extern
    #endif
    SOME_XYZ_EXTERN type xyz;

    some_xyz.c:

    #define SOME_XYZ_EXTERN
    #include

    into:
    some.h:

    extern type xyz; 

    some_xyz.c:

    #include 
    type xyz;

    See discussion:

    ​https://lists.rtems.org/pipermail/devel/2016-January/013506.html

    Update Developer Coding Conventions accordingly.

    Comment 1
    1. Sebastian Huber, Thu, 04 Feb 2016 12:00:29 GMT
    2. status: changed from new to accepted
    Comment 2
    1. Sebastian Huber, Wed, 17 Feb 2016 08:41:58 GMT

    In d4e81e3c80259467adbd2472fce94aebec3935b5/rtems:

    or1k: Delete superfluous _CPU_Null_fp_context Update #2559.
    Comment 3
    1. Sebastian Huber, Wed, 17 Feb 2016 08:42:10 GMT

    In deaf71637ad7ecb3f3d233039bfefc33b1416957/rtems:

    i386: Avoid SCORE_EXTERN Update #2559.
    Comment 4
    1. Sebastian Huber, Wed, 17 Feb 2016 08:42:21 GMT

    In 59e6e76190383d396582263800e915d54fb0206f/rtems:

    sh: Avoid SCORE_EXTERN Update #2559.
    Comment 5
    1. Sebastian Huber, Wed, 17 Feb 2016 08:42:33 GMT

    In af3847a82af1a1eecce5a0b464d4685444040add/rtems:

    epiphany: Delete superfluous _CPU_Null_fp_context Update #2559.
    Comment 6
    1. Sebastian Huber, Wed, 17 Feb 2016 08:42:44 GMT

    In d638aca61b6d87a7912f634b3820b0e64efb0767/rtems:

    mips: Avoid SCORE_EXTERN Update #2559.
    Comment 7
    1. Sebastian Huber, Wed, 17 Feb 2016 08:42:56 GMT

    In 18a5db205c296b9e3d83a1c7d107e29a996fb12f/rtems:

    m68k: Avoid SCORE_EXTERN Update #2559.
    Comment 8
    1. Sebastian Huber, Wed, 17 Feb 2016 08:43:08 GMT

    In c60093406706cdfe000c093f23e0fd0972a28881/rtems:

    lm32: Avoid SCORE_EXTERN Update #2559.
    Comment 9
    1. Sebastian Huber, Wed, 17 Feb 2016 08:43:20 GMT

    In dab78624ebbdc97341497f9d0fe92ed7fe1c8167/rtems:

    sparc: Avoid SCORE_EXTERN Update #2559.
    Comment 10
    1. Sebastian Huber, Wed, 17 Feb 2016 08:43:32 GMT

    In 9f016ec97e9e514fc9bed345005b66d88bbec5d3/rtems:

    no_cpu: Avoid SCORE_EXTERN Update #2559.
    Comment 11
    1. Sebastian Huber, Wed, 17 Feb 2016 08:43:44 GMT

    In 142868b235a5e2a550080ad1d4698f057716cd25/rtems:

    bfin: Delete superfluous _CPU_Null_fp_context Update #2559.
    Comment 12
    1. Sebastian Huber, Wed, 17 Feb 2016 08:43:56 GMT

    In 6df892688513d2559d493c394f762e38b8267f2c/rtems:

    moxie: Delete superfluous _CPU_Null_fp_context Update #2559.
    Comment 13
    1. Sebastian Huber, Wed, 17 Feb 2016 08:44:07 GMT

    In 51dc9a6121f8d4716b8ee5849feb16f880ecb20c/rtems:

    sparc64: Avoid SCORE_EXTERN Update #2559.
    Comment 14
    1. Sebastian Huber, Wed, 17 Feb 2016 08:44:18 GMT

    In 358bd740593132ddb00d6e33b4f512b5f9615597/rtems:

    score: Avoid SCORE_EXTERN Delete SCORE_INIT. This finally removes the some.h:
    `#ifndef SOME_XYZ_EXTERN #define SOME_XYZ_EXTERN extern #endif SOME_XYZ_EXTERN type xyz; `
    some_xyz.c:
    `#define SOME_XYZ_EXTERN #include `
    pattern in favour of some.h:
    extern type xyz;
    some_xyz.c
    `#include type xyz; `
    Update #2559.
    Comment 15
    1. Sebastian Huber, Wed, 17 Feb 2016 08:44:52 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed
    Comment 16
    1. Sebastian Huber, Mon, 14 Mar 2016 09:25:13 GMT

    In 62d2540daeb8dac70daa94ab490b626930f92009/rtems:

    score: Delete unused SAPI_IO_EXTERN Update #2559.
    Comment 17
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 18
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 19
    1. Joel Sherrill, Thu, 30 Apr 2020 22:06:27 GMT
    2. description: modified (diff)

    2560 - smdk2410 is broken due to gp32 removal

    Link https://devel.rtems.org/ticket/2560
    Id 2560
    Reporter Sebastian Huber
    Created 4 February 2016 06:25:44
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity blocker
    Keywords  
    Cc Aun-Ali Zaidi <admin@…>
    Blocking  
    Blocked by  

    Description

    The smdk2410 BSPs use files of the removed gp32 BSP.

    [f2a228b2cb5ce376c56ae8d767084b92f2822af0/rtems]

    Comment 1
    1. Aun-Ali Zaidi, Mon, 03 Oct 2016 01:31:26 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Just ran a fresh compile of smdk2410 and everything looks fine. All tests compile fine. I'm closing this for now.

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:54:12 GMT
    2. component: changed from bsps to arch/arm
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2562 - RSB Docs Quick Start version number

    Link https://devel.rtems.org/ticket/2562
    Id 2562
    Reporter Gedare Bloom
    Created 6 February 2016 12:17:37
    Modified 2 April 2020 15:36:38
    Owner Gedare Bloom
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords documentation
    Cc  
    Blocking  
    Blocked by  

    Description

    The quick start in the RSB docs only refers to version 4.11 in the examples. It may be worth a brief paragraph about RTEMS version numbers here to help orient new users since, if they follow these directions, they will not be able to build the master.

    Attachments:

    1 shashvat jain, Sun, 18 Nov 2018 14:21:31 GMT
      attach: set to 0001-version-number-notation-Ticket-2562-GCI-2018.patch
    2 shashvat jain, Wed, 21 Nov 2018 17:00:26 GMT
      attach: set to 0001-Added-version-nembers-guidelines-and-output-to-comma.patch
     
    3 shashvat jain, Wed, 21 Nov 2018 17:43:30 GMT
      attach: set to 0001-Closes-Ticket-2562.patch
     
    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 3
    1. Chris Johns, Sun, 14 Oct 2018 00:50:11 GMT
    2. owner: changed from Chris Johns to Gedare Bloom
    3. status: changed from new to assigned

    That would be nice to have. Please update once Joel pushes his changes to the Quick Start. Thanks.

    Comment 4
    1. shashvat jain, Sun, 18 Nov 2018 14:04:04 GMT

    I generalized the release version of RTEMS with "urversion" in rtems-docs/rsb and rtems-docs/user ,and specified a paragraph regarding the same below the commands. I also made a table in the Quick Start and rsb/project-sets page which displays the released versions and their status. here is the details of the table

    __release notes__ __status__ 5 development 4.11 current release 4.10 previous release

    here is what the note says

    "In the above commands and all commands on this page, __urversion__ gives the version of RTEMS you are building or want to build. Replace it with reference to release version table on *projects sets* page ."

    The patch with all changes made has been added to the attachments

    Comment 5
    1. Chris Johns, Sun, 18 Nov 2018 21:36:07 GMT

    The user manual is for a single release. I think it would be confusing to mention others releases or to make the manual appear suitable for other releases. For example the manual has command lines for tools which vary between releases and so it will not be correct for at least one release.

    May I suggest you run the commands listed and update the output for RTEMS 5.

    Comment 6
    1. shashvat jain, Wed, 21 Nov 2018 08:59:13 GMT

    I have added a paragraph about version numbers in the quick start and updated the outputs of the commands at quick start I am unable to give the patch file because of spam message,please help me with this.

    Comment 7
    1. Chris Johns, Fri, 13 Dec 2019 15:36:10 GMT

    Is this in the documentation? I cannot see it in the user of eng manuals.

    Comment 8
    1. Gedare Bloom, Thu, 02 Apr 2020 15:36:38 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 7a0834d/rtems-docs:

    start/user: describe version numbers and releases Closes #2562.

    2576 - arm/lpc176x: linker script update (add KEEP() sections)

    Link https://devel.rtems.org/ticket/2576
    Id 2576
    Reporter Joel Sherrill
    Created 6 February 2016 16:24:07
    Modified 14 September 2018 19:03:46
    Owner Joel Sherrill <joel@…>
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords function sections, KEEP
    Cc  
    Blocking  
    Blocked by  

    Description

    This BSP's linker script does not include KEEP() directives and thus cannot have per-function and per-data element section support enabled.

    The preferred solution is to convert the BSP to use a shared base linker script. The acceptable solution is to add the proper KEEP directives to the existing linker script(s).

    Shared linker scripts for the arm, m68k, and sparc have the proper KEEP sections and can serve as examples.

    Comment 1
    1. Joel Sherrill, Sat, 06 Feb 2016 16:26:47 GMT

    In e41d8ce5a764d57952102009ff1c5e5ace69a1c8/rtems:

    arm/.../lpc1768_embed.cfg: Disable per function sections updates #2576.
    Comment 2
    1. Marcos Diaz, Thu, 17 Mar 2016 20:12:25 GMT

    I looked into the linkerscript and it uses the shared for all arm's, which uses KEEP directives. Then I tested this BSP enabling the flags, and samples work ok:

    hello.exe : section size addr .start 772 0 .text 79136 776 .rodata 4152 79936 .vector 1256 268435456 .data 1656 268436712 .bss 5656 268438368

    With flags: hello.exe : section size addr .start 772 0 .text 61424 776 .rodata 3512 62224 .vector 1256 268435456 .data 1604 268436712 .bss 5592 268438336

    And the same for the other samples.

    Comment 3
    1. Marcos Diaz, Tue, 22 Mar 2016 14:51:04 GMT

    I suggest to apply the linker flags and deprecate this bug

    Comment 4
    1. Joel Sherrill, Tue, 22 Mar 2016 15:10:51 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 1a738edb39d462b9d99be4537782934f5ec56ca5/rtems:

    lpc1768_mbed.cfg: Turn on per function sections Closes #2576.
    Comment 5
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 6
    1. Sebastian Huber, Tue, 10 Oct 2017 06:54:12 GMT
    2. component: changed from bsps to arch/arm
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 8
    1. Joel Sherrill, Fri, 14 Sep 2018 19:03:46 GMT
    2. keywords: function sections KEEP added

    2606 - alarm() uses seconds watchdog and thus is affected by clock changes

    Link https://devel.rtems.org/ticket/2606
    Id 2606
    Reporter Sebastian Huber
    Created 22 February 2016 07:49:18
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    alarm() uses _Watchdog_Insert_seconds() and thus is affected by clock changes, e.g. via _TOD_Set(). This is wrong. The POSIX documentation is not that clear since it talks only about "realtime seconds". However, the FreeBSD implementation uses the uptime. This is also in line with the RTEMS ualarm() and nanosleep().

    Comment 1
    1. Sebastian Huber, Mon, 22 Feb 2016 08:17:07 GMT

    In 452f6ba9d193e0937f94432459c74122ea345e74/rtems:

    psxtests/psxalarm01: Add adjtime() test case Update #2606.
    Comment 2
    1. Sebastian Huber, Mon, 22 Feb 2016 13:08:54 GMT
    2. status: changed from new to accepted
    Comment 3
    1. Sebastian Huber, Fri, 04 Mar 2016 14:01:04 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    [03b900d3ed120ea919ea3eded7edbece3488cff3/rtems]

    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Mon, 16 Oct 2017 06:23:11 GMT
    2. component: changed from unspecified to posix
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2608 - POSIX Condition Variables Clock Attribute Support

    Link https://devel.rtems.org/ticket/2608
    Id 2608
    Reporter Joel Sherrill
    Created 22 February 2016 14:20:08
    Modified 5 December 2017 17:04:20
    Owner Gedare Bloom
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords POSIX-Compliance
    Cc Sebastian Huber
    Blocking  
    Blocked by  

    Description

    I am beginning to add support for the clock attribute to POSIX condition variables.

    ​http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_condattr_getclock.html

    Since the clock can't be a CPU time clock, that leaves CLOCK_MONOTONIC and CLOCK_REALTIME. The thread queue is based on CLOCK_MONOTONIC and does not have an option to use CLOCK_REALTIME. Threads and timers waiting on CLOCK_REALTIME should be impacted by time of day changes.

    ​https://docs.google.com/document/d/1GsGer0t84p-nUfZFim4Ty0LTDYNhgKBvlwip_gLQjTY/edit?usp=sharing is a Google doc with my notes so far in it on POSIX clocks. I will move it to the Wiki as it turns into something more concrete than notes and reflects plans/code.

    So the first issue is how best to alter the thread queue to support using either clock source? And what does that do to the current ticks based API since you proposed different time representations for the ticks (relative/monotonic) and seconds (absolute/realtime) structures?

    Comment 1
    1. Joel Sherrill, Thu, 16 Jun 2016 14:04:39 GMT

    In 6131b849081335e101f92b4a99e01572153d44f5/rtems:

    Add pthread_condattr_getclock() and pthread_condattr_setclock() updates #2608.
    Comment 2
    1. Joel Sherrill, Mon, 03 Apr 2017 23:18:33 GMT
    2. keywords: POSIX-Compliance added
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Joel Sherrill, Wed, 11 Oct 2017 23:18:54 GMT
    2. owner: changed from Joel Sherrill to Gedare Bloom
    3. status: changed from new to assigned

    Gedare.. I checked and think this is implemented and I thought you did the final part of the work. If you concur it is implemented, please close.

    Comment 5
    1. Sebastian Huber, Thu, 12 Oct 2017 05:35:35 GMT

    See also #3182.

    Comment 6
    1. Sebastian Huber, Mon, 16 Oct 2017 06:23:11 GMT
    2. component: changed from unspecified to posix
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 8
    1. Gedare Bloom, Tue, 05 Dec 2017 17:04:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    2617 - rtems_heap_allocate_aligned_with_boundary() body and prototype inconsistent

    Link https://devel.rtems.org/ticket/2617
    Id 2617
    Reporter Joel Sherrill
    Created 1 March 2016 00:24:40
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The first parameter is size_t in the .h and uintptr_t in the body. This resulted in a compiler error on the m32c. But it is an inconsistency which should be fixed even if no architecture complained.

    The malloc.h header file has this:

    void *rtems_heap_allocate_aligned_with_boundary(

    size_t size,
    uintptr_t alignment,
    uintptr_t boundary

    );

    malloc_deferred.c has this:

    void *rtems_heap_allocate_aligned_with_boundary(

    uintptr_t size,
    uintptr_t alignment,
    uintptr_t boundary

    )

    Comment 1
    1. Sebastian Huber, Tue, 01 Mar 2016 06:36:06 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 75518fb78240dbab92fc9d959765639afb32a457/rtems:

    malloc: Fix function definition Close #2617.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2624 - Fix the year 2038 problem

    Link https://devel.rtems.org/ticket/2624
    Id 2624
    Reporter Sebastian Huber
    Created 7 March 2016 06:39:24
    Modified 17 September 2018 10:15:05
    Owner Needs Funding
    Type defect
    Component tool/newlib
    Status closed
    Resolution fixed
    Version 4.5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    RTEMS uses currently a signed 32-bit integer for time_t on Newlib. Thus, it is affected by the year 2038 problem. There are only 22 years left and this time span is within the realistic time frame of some RTEMS applications that are developed now.

    The time_t should be changed to int64_t in Newlib. To make sure that all integer operations are carried out properly I suggest to temporarily do this

    `#include

    typedef struct {

    int64_t _val;

    } time_t;

    static inline time_t _time_add(time_t a, time_t b)
    {

    time_t r = { a._val + b._val };
    return r;

    }

    static inline time_t _time_sub(time_t a, time_t b)
    {

    time_t r = { a._val - b._val };
    return r;

    }

    static inline time_t _time_mul(time_t a, time_t b)
    {

    time_t r = { a._val * b._val };
    return r;

    }

    static inline time_t _time_div(time_t a, time_t b)
    {

    time_t r = { a._val / b._val };
    return r;

    }
    `

    Make sure that RTEMS and Newlib build with this. Add test cases to highlight the time_t integer limits.

    Comment 1
    1. Nick Withers, Mon, 07 Mar 2016 06:59:51 GMT

    __time_t__ 's required to be an integer or floating-point type by POSIX: ​http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/types.h.html

    Comment 2
    1. Sebastian Huber, Mon, 07 Mar 2016 07:02:49 GMT

    Yes, this is why I wrote temporarily. Once we are reasonably sure that all the integer operations are all right, we use

    typedef __int64_t time_t 

    I am not sure if we should keep the inline functions for clarity.

    Comment 3
    1. Chris Johns, Mon, 07 Mar 2016 23:01:46 GMT

    What do you mean by "all integer operations are carried out properly"? How do you decide everything is done properly?

    Is this specific to RTEMS and 3rd party code such as gcc and newlib RTEMS depends on? What happens to code such as cpukit/ftpd/ftpd.c:1193 or cpukit/libfs/src/jffs2/src/fs-rtems.c:1053? The JFFS has time_t in it's struct iattr and I am not sure if this is embedded in the file system in the flash. The RFS has a special type for time in the inode on disk.

    Comment 4
    1. Joel Sherrill, Mon, 07 Mar 2016 23:11:34 GMT

    I don't see the value of adding helper methods. Much of the code impacted would have to be altered to use them. Internal code using 64-bit time_t should just work. The issue is where there are interfaces to other representations or storage systems.

    Analyse the cases Chris mentions, ask on newlib if there are any known places to be concerned about, and just try it.

    Adding use of non-standard helper functions on a standard type is just extra work.

    Comment 5
    1. Sebastian Huber, Tue, 08 Mar 2016 16:58:06 GMT

    I didn't assign the ticket to me because I don't work actively on this topic. Its a ticket to collect some ideas.

    I just want to point out that its not as simple as "typedef uint64_t time_t".

    Joel, how would you ensure that you don't accidentally use maybe a long for time_t arithmetic in Newlib and RTEMS?

    Comment 6
    1. Sebastian Huber, Wed, 15 Feb 2017 14:20:42 GMT
    2. owner: set to Needs Funding
    3. status: changed from new to assigned
    4. milestone: changed from 4.12 to Indefinite
    Comment 7
    1. Sebastian Huber, Mon, 17 Sep 2018 10:15:05 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    4. version: changed from 4.10 to 4.5
    5. component: changed from unspecified to tool/newlib
    6. milestone: changed from Indefinite to 5.1

    Fixed by #3111.


    2625 - Use one lookup tree per-thread for the POSIX keys

    Link https://devel.rtems.org/ticket/2625
    Id 2625
    Reporter Sebastian Huber
    Created 7 March 2016 07:06:25
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Currently a global lookup tree is used for all the POSIX key/value pairs. On SMP configurations this is a bottleneck. Use one lookup tree per thread instead.

    Comment 1
    1. Sebastian Huber, Fri, 18 Mar 2016 06:47:40 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 5eaf0e7458bac80ba669f03c4feaae5bad55c6c9/rtems:

    posix: Use per-thread lookup tree for POSIX Keys Yields higher performance on SMP systems. Close #2625.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2626 - Unify thread cancel/join and delete

    Link https://devel.rtems.org/ticket/2626
    Id 2626
    Reporter Sebastian Huber
    Created 7 March 2016 07:11:26
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The rtems_task_delete() is basically a pthread_cancel() plus pthread_join(). Unify the implementation and introduce a _Thread_Cancel() and _Thread_Join() to be used by both APIs. Get rid of the Giant lock for thread delete.

    Comment 1
    1. Sebastian Huber, Fri, 20 May 2016 05:56:47 GMT

    In e75374870375099eb097f189905be709008fb3c0/rtems:

    score: Delete redundant thread life enums This makes it easier to add more states in the future. Update #2555. Update #2626.
    Comment 2
    1. Sebastian Huber, Fri, 20 May 2016 05:56:57 GMT

    In b7f5e391c0c0e94e5958a294e5d38b1dda7332cc/rtems:

    score: Add _Thread_Exit() The goal is to make _Thread_Exit() a no-return function in follow up patches. Update #2555. Update #2626.
    Comment 3
    1. Sebastian Huber, Fri, 20 May 2016 05:57:07 GMT

    In 270394eef82ae584477cb9c443d4a5c8e67978eb/rtems:

    score: Avoid superfluous life protection Disable thread dispatching is enough to prevent deletion of the executing thread. There is no need for an additional life protection. Update #2555. Update #2626.
    Comment 4
    1. Sebastian Huber, Fri, 20 May 2016 05:57:17 GMT

    In 69c722f3f6ac84eca42e68eda0e1ed63fd3702e7/rtems:

    score: Delete unused variable Update #2555. Update #2626.
    Comment 5
    1. Sebastian Huber, Fri, 20 May 2016 05:57:27 GMT

    In 9949d8a7d042da7ba53516300db5c34c8b9c8a31/rtems:

    score: Add Thread_Change_life() Add _Thread_Change_life_locked() as a general function to alter the thread life state. Use it to implement _Thread_Set_life_protection() as a first step. Update #2555. Update #2626.
    Comment 6
    1. Sebastian Huber, Fri, 20 May 2016 05:57:37 GMT

    In 7023d82ca6bdfe7e0fa1d1c10481671dd744d894/rtems:

    score: Add _Thread_Raise_real_priority() Update #2555. Update #2626.
    Comment 7
    1. Sebastian Huber, Fri, 20 May 2016 05:57:47 GMT

    In c99eb50b9f66e76cdd6aa0833321550c9b9e655c/rtems:

    score: Rework _Thread_Exit() Rework _Thread_Exit() to use _Thread_Change_life_locked(). Update #2555. Update #2626.
    Comment 8
    1. Sebastian Huber, Fri, 20 May 2016 05:57:57 GMT

    In 232147ddc12d45ff7872f72a790077c26fe5ca0a/rtems:

    score: Add _Thread_Join() and _Thread_Cancel() Split _Thread_Close() into _Thread_Join() and _Thread_Cancel() to prepare for a re-use in pthread_join() and pthread_cancel(). Update #2555. Update #2626.
    Comment 9
    1. Sebastian Huber, Fri, 20 May 2016 05:58:07 GMT

    In 9a99ce15d0878d847b4c7e054eb2996a9f5fbc34/rtems:

    score: Add _Thread_Set_state_locked() This makes it possible to do thread state and thread life changes together under protection of the thread state lock. Update #2555. Update #2626.
    Comment 10
    1. Sebastian Huber, Fri, 20 May 2016 05:58:17 GMT

    In f410ea82a4b9d5609ce170d2aa09027b5a7c4c50/rtems:

    score: Add _Thread_Clear_state_locked() This makes it possible to do thread state and thread life changes together under protection of the thread state lock. Update #2555. Update #2626.
    Comment 11
    1. Sebastian Huber, Fri, 20 May 2016 05:58:27 GMT

    In 0475cca9a015a7b43209270ca6e40aebf177639a/rtems:

    score: Add _Thread_Dispatch_disable_with_CPU() Update #2555. Update #2626.
    Comment 12
    1. Sebastian Huber, Fri, 20 May 2016 05:58:37 GMT

    In 938839077741d2eac82d9d86705c16e0b9de8379/rtems:

    score: Split _Thread_Restart() Split _Thread_Restart() into _Thread_Restart_self() and _Thread_Restart_other(). Move content of existing _Thread_Restart_self() into new _Thread_Restart_self(). Avoid Giant lock for thread restart. _Thread_Restart_self() is a no-return function and used by _Thread_Global_construction(). Update #2555. Update #2626.
    Comment 13
    1. Sebastian Huber, Fri, 20 May 2016 05:58:47 GMT

    In 862a0eeb1197539c0e69381cb5aaccb9e1c64c0f/rtems:

    score: Rework _Thread_Restart_other() Rework _Thread_Restart_other() to use _Thread_Change_life_locked(). Cope with concurrent change requests by means of a pending request counter. Update #2555. Update #2626.
    Comment 14
    1. Sebastian Huber, Fri, 20 May 2016 05:58:58 GMT

    In ef09017ebb6ac9c1309df4e827b240c14e6dbaa9/rtems:

    score: Rework _Thread_Cancel() Rework _Thread_Cancel() to use _Thread_Change_life_locked(). Update #2555. Update #2626.
    Comment 15
    1. Sebastian Huber, Fri, 20 May 2016 05:59:08 GMT

    In 29e1ecab875c3121357f27e0676913d9ca96183f/rtems:

    score: Simplify _Thread_Life_action_handler() Use _Thread_Change_life_locked() to avoid duplicated code. Avoid Giant lock in _Thread_Life_action_handler(). Update #2555. Update #2626.
    Comment 16
    1. Sebastian Huber, Fri, 20 May 2016 05:59:18 GMT

    In 54550e048d3a49435912797d2024f80671e93267/rtems:

    posix: Rework pthread_join() Rework pthread_join() to use _Thread_Join(). Close #2402. Update #2555. Update #2626. Close #2714.
    Comment 17
    1. Sebastian Huber, Fri, 20 May 2016 05:59:39 GMT

    In da82656065d09f7b6aa411ba361287afdd787204/rtems:

    posix: Rework thread cancellation Add Thread_Life_state::THREAD_LIFE_CHANGE_DEFERRED and rework the POSIX thread cancellation to use the thread life states. Update #2555. Update #2626.
    Comment 18
    1. Sebastian Huber, Fri, 20 May 2016 06:18:58 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 19
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 20
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2627 - Fix CPU time used for threads on SMP

    Link https://devel.rtems.org/ticket/2627
    Id 2627
    Reporter Sebastian Huber
    Created 7 March 2016 07:16:14
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The CPU time used of a thread is currently maintained per-processor mostly during _Thread_Dispatch(). However, on SMP configurations the actual processor of a thread is difficult to figure out since thread dispatching is a highly asynchronous process (e.g. via inter-processor interrupts). Only the intended processor of a thread is known to the scheduler easily. Do the CPU usage accounting during thread heir updates in the context of the scheduler operations. Provide a function to get the CPU usage of a thread using proper locks to get a consistent value.

    Comment 1
    1. Chris Johns, Tue, 08 Mar 2016 00:03:16 GMT

    SMP introduces new challenges for users building applications.

    I am struggling to understand what __standard__ support RTEMS has for threads and processor performance accounting. When I last looked a while ago I found I needed to turn on profiling to get anything and I feel creating a special build is not a great option for some basic or __standard__ performance accounting.

    What do we consider as important?

    Do we have things like context switches per core? Core idle time?

    Comment 2
    1. Sebastian Huber, Wed, 09 Mar 2016 06:50:03 GMT

    The profiling is optional since it may severely impact the performance of the operating system. Some SMP chips are not really well designed and offer no processor private access to timer and counter modules. Instead you must use on-chip peripheral over the system bus.

    Adding some counters shouldn't be a big deal, but please create a new ticket for this. This ticket is about fixing an existing statistic so that it works on SMP.

    Determining the per-processor idle time is difficult with the global fixed priority schedulers if they manage more than one processor and I don't think this value is interesting.

    Comment 3
    1. Chris Johns, Wed, 09 Mar 2016 21:26:43 GMT

    Replying to sebastian.huber:

    The profiling is optional since it may severely impact the performance of the operating system. Some SMP chips are not really well designed and offer no processor private access to timer and counter modules. Instead you must use on-chip peripheral over the system bus.

    Yes I agree profiling is not a normal user activity and may place extra demands on the system. We need to track this variant with buildbot.

    Adding some counters shouldn't be a big deal, but please create a new ticket for this. This ticket is about fixing an existing statistic so that it works on SMP.

    Good idea, I will do this.

    Determining the per-processor idle time is difficult with the global fixed priority schedulers if they manage more than one processor and I don't think this value is interesting.

    Maybe the stats collected are per scheduler and reflect what is important.

    Comment 4
    1. Sebastian Huber, Thu, 17 Mar 2016 08:03:12 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In d37adfe5dd82cc3c933eb521b8f800c342af0e52/rtems:

    score: Fix CPU time used by executing threads The CPU time used of a thread was previously maintained per-processor mostly during _Thread_Dispatch(). However, on SMP configurations the actual processor of a thread is difficult to figure out since thread dispatching is a highly asynchronous process (e.g. via inter-processor interrupts). Only the intended processor of a thread is known to the scheduler easily. Do the CPU usage accounting during thread heir updates in the context of the scheduler operations. Provide the function _Thread_Get_CPU_time_used() to get the CPU usage of a thread using proper locks to get a consistent value. Close #2627.
    Comment 5
    1. Sebastian Huber, Tue, 22 Mar 2016 06:28:38 GMT

    In baa1362643f20781db1d50a5a4d23e7069d0972a/rtems:

    score: Fix for RTEMS_DEBUG Update #2627.
    Comment 6
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2628 - Avoid home-grown condition variable implementation in the Classic Regions

    Link https://devel.rtems.org/ticket/2628
    Id 2628
    Reporter Sebastian Huber
    Created 7 March 2016 07:22:11
    Modified 29 November 2017 07:16:52
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution wontfix
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The Classic Region manager enables users to wait until memory is available to satisfy an allocation request. This is done through special purpose code that basically implements a condition variable.

    Comment 1
    1. Sebastian Huber, Mon, 07 Mar 2016 07:29:10 GMT

    Depends on #2629.

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:42:40 GMT
    2. milestone: changed from 4.12.0 to 5.0
    Comment 4
    1. Chris Johns, Mon, 14 Aug 2017 00:47:54 GMT
    2. version: 4.10 deleted
    3. milestone: changed from 5.0 to Indefinite
    Comment 5
    1. Sebastian Huber, Wed, 29 Nov 2017 07:16:52 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix
    4. milestone: changed from Indefinite to 5.1

    The region can be configured to let threads wait in FIFO or priority order. The self-contained condition variables do not support this. Keep this special case implementation as is.


    2631 - Use an ISR lock to protect the state of Classic Rate Monotonic objects

    Link https://devel.rtems.org/ticket/2631
    Id 2631
    Reporter Sebastian Huber
    Created 7 March 2016 07:38:12
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The state of Classic Rate Monotonic is currently protected by the Giant lock and ISR disable sections. Use a per-object ISR lock to protect state changes instead.

    Comment 1
    1. Sebastian Huber, Tue, 22 Mar 2016 06:28:14 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 90960bd11a91259d9aace3870692dbe2e227de0f/rtems:

    rtems: Rework rate-monotonic scheduler Use the default thread lock to protect rate-monotonic state changes. This avoids use of the Giant lock. Split rtems_rate_monotonic_period() body into several static functions. Introduce a new thread wait class THREAD_WAIT_CLASS_PERIOD for period objects to synchronize the blocking operation. Close #2631.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2632 - rtems-tester failure

    Link https://devel.rtems.org/ticket/2632
    Id 2632
    Reporter Joel Sherrill
    Created 7 March 2016 22:54:28
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority highest
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    CentOS 7 on master

    $ ../rtems-tools/tester/rtems-test --rtems-tools=/home/joel/rtems-4.11-work/tools/4.12 --rtems-bsp=sis find . -name "*hello.exe" RTEMS Testing - Tester, 4.12 (a5d243d3f8e2)

    Command Line: ../rtems-tools/tester/rtems-test --rtems-tools=/home/joel/rtems-4.11-work/tools/4.12 --rtems-bsp=sis ./sparc-rtems4.12/c/sis/testsuites/samples/hello/hello.exe
    Python: 2.7.5 (default, Nov 20 2015, 02:00:19) [GCC 4.8.5 20150623 (Red Hat 4.8.5-4)]

    [1/1] p:0 f:0 t:0 i:0 | sparc/sis: hello.exe
    Traceback (most recent call last):

    File "../rtems-tools/tester/rtems-test", line 40, in

    rt.test.run()

    File "/data/home/joel/rtems-4.11-work/rtems-tools/tester/rt/test.py", line 287, in run

    tst.reraise()

    File "/data/home/joel/rtems-4.11-work/rtems-tools/tester/rt/test.py", line 123, in reraise

    raise (self.result[0], self.result[1], self.result[2])

    TypeError?: init() takes exactly 2 arguments (1 given)

    Comment 1
    1. Chris Johns, Wed, 16 Mar 2016 06:30:12 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2633 - waf build failed for rtems-libbsd

    Link https://devel.rtems.org/ticket/2633
    Id 2633
    Reporter joguin
    Created 8 March 2016 21:03:57
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component network/legacy
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc Chris Johns
    Blocking  
    Blocked by  

    Description

    The rtems-libbsd failed when building with waf. Here is the output:

    [488/845] Compiling freebsd/sys/kern/subr_taskqueue.c
    In file included from /home/josh/development/rtems/bsps/4.12/i386-rtems4.12/pc386/lib/include/rtems/score/threadimpl.h:36:0,

    from ../../freebsd/sys/kern/subr_sleepqueue.c:91:

    /home/josh/development/rtems/bsps/4.12/i386-rtems4.12/pc386/lib/include/rtems/score/watchdogimpl.h: In function '_Watchdog_Per_CPU_insert_relative':
    /home/josh/development/rtems/bsps/4.12/i386-rtems4.12/pc386/lib/include/rtems/score/watchdogimpl.h:356:18: error: 'struct ' has no member named '_bsd_ticks'; did you mean 'ticks'?

    cpu->Watchdog.ticks + ticks

    In file included from ../../freebsd/sys/kern/subr_sleepqueue.c:62:0:
    ../../freebsd/sys/kern/subr_sleepqueue.c: In function 'sleepq_set_timeout':
    ../../freebsd/sys/kern/subr_sleepqueue.c:424:29: error: 'Thread_Timer_information {aka struct }' has no member named 'state'

    BSD_ASSERT(executing->Timer.state == WATCHDOG_INACTIVE);

    ../../freebsd/sys/kern/subr_sleepqueue.c:424:2: note: in expansion of macro 'BSD_ASSERT'

    BSD_ASSERT(executing->Timer.state == WATCHDOG_INACTIVE); ~

    ../../freebsd/sys/kern/subr_sleepqueue.c:425:2: error: too many arguments to function '_Watchdog_Initialize'

    _Watchdog_Initialize(&executing->Timer, sleepq_timeout, ~

    In file included from /home/josh/development/rtems/bsps/4.12/i386-rtems4.12/pc386/lib/include/rtems/score/threadimpl.h:36:0,

    from ../../freebsd/sys/kern/subr_sleepqueue.c:91:

    /home/josh/development/rtems/bsps/4.12/i386-rtems4.12/pc386/lib/include/rtems/score/watchdogimpl.h:178:27: note: declared here

    RTEMS_INLINE_ROUTINE void _Watchdog_Initialize(

    ~

    Waf: Leaving directory `/home/josh/development/rtems/rtems-libbsd/build/i386-rtems4.12-pc386'
    Build failed

    Comment 1
    1. Joel Sherrill, Tue, 08 Mar 2016 21:33:30 GMT
    2. version: changed from 4.11 to 4.12
    3. component: changed from General to networking
    4. milestone: changed from 4.11.1 to 4.12
    Comment 2
    1. Joel Sherrill, Tue, 08 Mar 2016 21:34:16 GMT

    Most likely a side-effect of the recent watchdog change to RBTree.

    Comment 3
    1. Sebastian Huber, Tue, 08 Mar 2016 23:21:52 GMT

    Yes, I had no time to update this since I am on a business trip this week.

    Comment 4
    1. Sebastian Huber, Tue, 08 Mar 2016 23:22:04 GMT
    2. status: changed from new to accepted
    Comment 5
    1. Joel Sherrill, Tue, 08 Mar 2016 23:32:32 GMT
    2. cc: Chris Johns added
    Comment 6
    1. Joel Sherrill, Tue, 08 Mar 2016 23:33:25 GMT

    Chris pointed out that this means that unless the code as written in specific to 4.11. Thus it may be necessary to create a 4.11 branch at this point.

    Hmm.. It has a 4.11 branch. Is it in sync as much as possible with the master?

    Comment 7
    1. Sebastian Huber, Mon, 14 Mar 2016 08:32:12 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    [a336c4630161a6e5a3742c1430564d5566cafa58/rtems-libbsd]

    Comment 8
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2634 - New warning in pc386 VESA driver

    Link https://devel.rtems.org/ticket/2634
    Id 2634
    Reporter Joel Sherrill
    Created 9 March 2016 16:22:14
    Modified 9 November 2017 06:27:14
    Owner Pavel Pisa <ppisa@…>
    Type defect
    Component arch/i386
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc Pavel Pisa Chris Johns
    Blocking  
    Blocked by  

    Description

    Pavel.. can you look into this?

    ./../../../../../../../rtems/c/src/lib/libbsp/i386/pc386/console/fb_vesa_rm.c: In function 'find_mode_using_EDID':
    ../../../../../../../../rtems/c/src/lib/libbsp/i386/pc386/console/fb_vesa_rm.c:502:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]

    if (*(uint16_t*)&edid.STI[index] == EDID_STI_DescriptorUnused) ~

    Attachments:

    1 Pavel Pisa, Wed, 09 Mar 2016 19:51:08 GMT
      attach: set to correct-fb_vesa_rm-warning.diff
     
    Comment 1
    1. Pavel Pisa, Wed, 09 Mar 2016 19:53:24 GMT

    Hello all, I have attached proposal for fixup. I have checked that it compiles against 4.11 without warning but I have not test that it by run of compiled code under QEMU. I need to find more time for that in some of next days.

    Comment 2
    1. Joel Sherrill, Wed, 09 Mar 2016 20:59:53 GMT
    2. cc: Chris Johns added
    Comment 3
    1. Joel Sherrill, Wed, 09 Mar 2016 21:03:07 GMT

    Thanks. I don't know if I can test this or not.

    The RSB build of qemu doesn't turn on the graphics module so I don't know if it hits this code or not. And from what my five minute at trying to turn it on made me think you needed Xen development files to use it and they were only available for 64-bit CentOS 6. If that's the case, the code isn't portable at all off of Linux so we should disable video, unfortunately.

    The real PC I have been using to test on prints a message (from memory) that indicates it didn't initialize it or find it. Not sure which.

    What setup is required to test this?

    Comment 4
    1. Pavel Pisa, Wed, 09 Mar 2016 21:44:22 GMT

    Hello Chris, I have minimal experience with RSB based RTEMS OS builds, but regular configure make builds of RTEMS is by default with VESA graphic support which can be then initialized at runtime by RTEMS kernel option --video=auto. This result in switch to graphic mode early in RTEMS boot. But you need some graphic application to open frame-buffer a draw to it. Regular standard output to video console does not emulate characters drawing/text mode yet. Initial version of such text mode emulation on graphic frame-buffer is implemented in experimental branch of RPi support only till now and is in shape that it could be adapted to be generic for more architectures.

    I use Microwindows/Nano?-X builds for testing (manual by RTEMS graphic toolkit do_it -A) or by RSB. Required packages recipes have been integrated to mainline RSB as a result of Qiao Yang GSoC project during 2015 autumn and previous work is already integrated to Micowindows mainline as well, so we can even switch scrips to use that directly instead of the Alex GSoC Microwindows fork. Microwindows demos can be run then on QEMU (VirtualBox? not tested but should work too) a we have run some tests on real PC hardware during driver development as well.

    Documentation for (now default) VESA configuration is there

    ​https://devel.rtems.org/wiki/Projects/GraphicsToolkit#RTEMS4.11andVESABIOSExtensionVBE

    RSB build of graphic libraries against regular configure make installed RTEMS in /opt

    ../source-builder/sb-set-builder \
        --log=graphic-build-log.txt \
        --prefix=/opt/rtems4.11 \
        --rtems-bsp=i386/pc686 \
        --with-rtems-bsp=pc686 \
        --pkg-tar-files \
        4.11/graphics/graphics-all.bset 

    My QEMU command line

    qemu-system-x86_64 -gdb tcp::1234 -enable-kvm -kernel $APP_BINARY \
          -vga cirrus \
          -net nic,vlan=0,model=e1000 -net user,vlan=0 \
          -serial stdio \
          -append "--console=com1 --video=auto" 

    where $APP_BINARY is RTEMS+application image.

    I use serial output for messages and RTEMS standard output then and graphic frame-buffer for tested application.

    Suitable QEMU (qemu-system-x86_64 or qemu-system-i386) should be available in all GNU/Linux distributions.

    Comment 5
    1. Pavel Pisa, Wed, 09 Mar 2016 22:04:38 GMT

    I have tested patched 4.11 build with some of my experimental applications and video setup seems OK. I need build tool-chains and switch to 4.12, I have it on my TODO, but ... .

    Comment 6
    1. Joel Sherrill, Wed, 09 Mar 2016 22:26:07 GMT

    If you have tested this patch on 4.11, we should just apply it to both branches. You just seemed concern it would break something.

    Comment 7
    1. Pavel Pisa, Sat, 16 Apr 2016 22:25:36 GMT
    2. owner: set to Pavel Pisa <ppisa@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In b752f9454fd412b0c4e3b15ee853afd4870ccc54/rtems:

    i386/pc386: reimplemented check for unused EDID entry in fb_vesa.c to suppress GCC 6 warning. closes #2634
    Comment 8
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 9
    1. Sebastian Huber, Tue, 10 Oct 2017 06:55:23 GMT
    2. component: changed from bsps to arch/i386
    Comment 10
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2638 - pc386: ld -r issue with per function sections

    Link https://devel.rtems.org/ticket/2638
    Id 2638
    Reporter Joel Sherrill
    Created 10 March 2016 21:47:37
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill <joel@…>
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The pc386 BSP has an issue with "ld -r" when function-sections is enabled which does not seem to occur on any other BSP. The same lines were added to the custom .cfg file as on other BSPs. It is unknown at this point whether this is an x86 specific "ld -r" issue or a pc386 build configuration issue.

    Per-function-section linking is disabled until this is addressed.

    i386-rtems4.12-gcc --pipe -B../../../../../.././lib/ -B../../../../../.././pc386/lib/ -specs bsp_specs -qrtems -mtune=i386 -O2 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -qnolinkcmds -nostdlib -r -Wl,--gc-sections -Wl,-Ttext,0x00100000 -o ne2000.rel ne2000_rel-ne2000.o
    /data/home/joel/rtems-4.11-work/tools/4.12/bin/../lib/gcc/i386-rtems4.12/6.0.0/../../../../i386-rtems4.12/bin/ld: gc-sections requires either an entry or an undefined symbol
    collect2: error: ld returned 1 exit status

    Comment 1
    1. Chris Johns, Thu, 10 Mar 2016 23:08:44 GMT

    I have seen patches from H,J Lu from Intel recently on binutils about -r. Maybe ask him.

    Comment 2
    1. Joel Sherrill, Thu, 10 Mar 2016 23:14:21 GMT

    Good idea. I emailed binutils@ and hopefully we will get a hint.

    Comment 3
    1. Joel Sherrill, Fri, 11 Mar 2016 22:08:25 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 5e368e8441e21e484a09e0d743a5b6b934e45047/rtems:

    pc386: Fix linker usage issues with -r and function sections closes #2638.
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2641 - configure: enable-rtemsbsp doesn't warn if bsp does not exist

    Link https://devel.rtems.org/ticket/2641
    Id 2641
    Reporter aurelio
    Created 11 March 2016 17:03:32
    Modified 11 April 2018 01:57:55
    Owner Chris Johns
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc Chris Johns joel
    Blocking  
    Blocked by  

    Description

    When running configure with an incorrect bsp name the script does not cause an error. You can ever run make without getting any warning message.

    The script should check the name of the bsp and continue only if it is a valid bsp. On the other hand if the bsp name given by the user is invalid the script should prompt a message.

    Attachments:

    1 Chris Johns, Mon, 14 Mar 2016 02:04:57 GMT
      attach: set to 0001-configure-Check-the-enable-rtemsbsp-list-of-BSPs-ear.patch
     
    Comment 1
    1. Chris Johns, Mon, 14 Mar 2016 02:06:23 GMT
    2. cc: joel added

    Try this patch.

    Joel, is this ok to push to master and 4.11?

    Comment 2
    1. Chris Johns, Mon, 14 Mar 2016 23:12:56 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to accepted

    The patch is broken, --enable-rtemsbsp accepts space delimited bsps and not comma delimited bsps.

    I will update the patch and attach again when I can.

    Comment 3
    1. Sebastian Huber, Thu, 26 Jan 2017 07:16:00 GMT
    2. milestone: changed from 4.11.1 to 4.11.2
    Comment 4
    1. Chris Johns, Tue, 21 Mar 2017 03:25:40 GMT
    2. version: changed from 4.11 to 4.12
    3. milestone: changed from 4.11.2 to 4.12.1

    This is not suitable for a branch. Moving it to master.

    Comment 5
    1. Chris Johns, Mon, 27 Mar 2017 06:48:47 GMT
    2. milestone: changed from 4.12.1 to 4.12.0

    Move to the first 4.12 milestone.

    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 7
    1. Chris Johns, Wed, 11 Apr 2018 01:57:55 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 7ff743d/rtems:

    Generate an error if a BSP in the --enable-rtemsbsp list is not valid Also generate an error if the architecure does not match the --target architecture given to configure's command line. Close #2641.

    2644 - sis does not run on gdb 7.11 but does on gdb 7.9

    Link https://devel.rtems.org/ticket/2644
    Id 2644
    Reporter Joel Sherrill
    Created 14 March 2016 18:01:19
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc Chris Johns
    Blocking  
    Blocked by  

    Description

    I know we reported this on the gdb list but we should have a ticket.

    Neither gdb nor run works for sis on gdb 4.11. Checked against RTEMS 4.11 tools (gdb 4.9) and it will run sis.

    Not sure about other simulators.

    Comment 1
    1. Chris Johns, Tue, 15 Mar 2016 22:24:32 GMT
    2. summary: changed from sis does not run on gdb 4.11 but does on gdb 4.9 to sis does not run on gdb 7.11 but does on gdb 7.9

    There is 2 separate problems:

    the run command does not work any more on Linux and OS X the simulator does not work

    This patch ​https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=465fb143 changed the sim/erc32 from the sim/common/run.c to sis.o for the run command so in effect made the run command the same as the sis command.

    Our rtems-4.11 release uses gdb-7.9 with 23 patches (​https://git.rtems.org/rtems-tools/tree/tools/4.11/gdb/sparc/7.9?h=4.11) so upgrading to gdb-7.11 was considered a better move than moving the rtems-4.11 patches to rtems-4.12. Of the 23 patches gdb-7.11 has patches 0001-0013 merged along with 0016 and the remaining patches are not merged. The 0014 patch is a gdb-7.9 version of my patch to clean up the output paths. Without that patch the erc32 does not support MI mode and can block on input locking up when run in the test framework. The remaining patches are LEON2 and LEON3 support which I am not sure about and watchpoints.

    Running on FreeBSD works with the sparc/sis BSP. Running on Linux gives:

    chris@titi:~/development/rtems/test/gdb/sparc-rtems4.12$ /opt/rtems/4.12/bin/sparc-rtems4.12-gdb /home/chris/development/rtems/kernel/erc32-sis/sparc-rtems4.12/c/sis/testsuites/samples/hello/hello.exe
    GNU gdb (GDB) 7.11
    Copyright (C) 2016 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later 
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "--host=x86_64-linux-gnu --target=sparc-rtems4.12".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    .
    Find the GDB manual and other documentation resources online at:
    .
    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from /home/chris/development/rtems/kernel/erc32-sis/sparc-rtems4.12/c/sis/testsuites/samples/hello/hello.exe...done.
    (gdb) tar sim -v
     SIS - SPARC instruction simulator 2.7.5
     Bug-reports to Jiri Gaisler ESA/ESTEC (jgais@wd.estec.esa.nl)
    RAM start: 0x2000000, RAM size: 256 K, ROM size: 128 K
    Waitstates = RAM read: 3, RAM write: 3, ROM read: 15, ROM write: 15
    Watchdog started, scaler = 255, counter = 65535
    serial port A on stdin/stdout
    Connected to the simulator.
    (gdb) load
    loading /home/chris/development/rtems/kernel/erc32-sis/sparc-rtems4.12/c/sis/testsuites/samples/hello/hello.exe:
    section .text at 0x02000000 (0x19980 bytes)
    section .rtemsroset at 0x02019980 (0x40 bytes)
    section .data at 0x020199c0 (0x670 bytes)
    section .bss at 0x0201a040 (0x1920 bytes)(not loaded)
    (gdb) run
    Starting program: /home/chris/development/rtems/kernel/erc32-sis/sparc-rtems4.12/c/sis/testsuites/samples/hello/hello.exe
    RAM start: 0x2000000, RAM size: 256 K, ROM size: 128 K
    Waitstates = RAM read: 3, RAM write: 3, ROM read: 15, ROM write: 15
    Watchdog started, scaler = 255, counter = 65535
    resuming at 2000000
    Waitstates = RAM read: 0, RAM write: 0, ROM read: 0, ROM write: 0
    Watchdog disabled
    Error manager halt - MEC hardware error
    RAM start: 0x2000000, RAM size: 4096 K, ROM size: 1024 K
    Error manager halt - IU in error mode
    Error manager halt - MEC hardware error
    [Inferior 1 (process 42000) exited normally]
    (gdb) 

    I am not sure what broken this.

    Back to the run command. The run command should be using sim/common/nrun.c and this moves the simulator to the common structure and that conflicts with the sim/erc32/inferf.c code. The erc32 sim_open is broken and needs to be fixed to return a real SIM_DESC and that needs to be filled in correct. An issue I am not sure about is now the inferior's memory access routines link up with the SIS view of memory. I suspect they would be separate pieces of memory.

    Also the sim/erc32 makes lots of printf calls and these needs to via GDB's filtered print calls. The direct printf calls break MI support.

    Comment 2
    1. Chris Johns, Wed, 16 Mar 2016 04:51:02 GMT

    In 0bbd2de7f5306ad15ce544f9c3e9a5d9bb00dc85/rtems-tools:

    4.12: Patches for ERC simualtor for gdb-7.11. The patches fix the endian checks in the simulator, print filtering, and the run command. Updates #2644.
    Comment 3
    1. Chris Johns, Wed, 16 Mar 2016 04:55:11 GMT

    In 08aa888205798b3416d24544fd06613fd683bb1e/rtems-source-builder:

    4.12/gdb-7.11: Add ERC32 patches to fix the simulator. Updates #2644.
    Comment 4
    1. Joel Sherrill, Wed, 16 Mar 2016 14:48:04 GMT

    sis command still does not work. Or I don't remember how to use it. :)

    Comment 5
    1. Chris Johns, Wed, 16 Mar 2016 19:55:36 GMT

    What is the sis command?

    Comment 6
    1. Chris Johns, Wed, 16 Mar 2016 19:56:48 GMT

    FYI I ran all the SIS and ERC32 tests in a single run. The results are:

    Passed:   1062
    Failed:      3
    Timeouts:    3
    Invalid:     0
    --------------
    Total:    1068
    Failures:
     psxcancel.exe
     psxcancel.exe
     spcontext01.exe
    Timeouts:
     crypt01.exe
     spcontext01.exe
     crypt01.exe
    Average test time: 0:00:00.667911
    Testing time     : 0:11:53.329500 
    Comment 7
    1. Joel Sherrill, Mon, 14 Nov 2016 16:34:00 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 8
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2649 - RSB remove 4.11, 4.10 and 4.9 from the master branch.

    Link https://devel.rtems.org/ticket/2649
    Id 2649
    Reporter Chris Johns
    Created 14 March 2016 23:05:31
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords RSB
    Cc  
    Blocking  
    Blocked by  

    Description

    Having 4.11 on master is confusing users as they build 4.11 tool on master and there may be issues in 4.11 configurations fixed on the 4.11 branch.

    Leave 4.9 and 4.10 until they are branched off master. We will make these branches once 4.12 is stable again.

    Comment 1
    1. Chris Johns, Wed, 16 Mar 2016 05:00:10 GMT

    In e7649747c8385a554a49624542f50c6b2f0e42f5/rtems-source-builder:

    4.11: Remove from master. Updates #2649.
    Comment 2
    1. Chris Johns, Mon, 14 Aug 2017 00:56:50 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    4. milestone: set to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2663 - pc386 BSP has complex dependencies

    Link https://devel.rtems.org/ticket/2663
    Id 2663
    Reporter Joel Sherrill
    Created 18 March 2016 15:22:52
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component arch/i386
    Status closed
    Resolution wontfix
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc Chris Johns
    Blocking  
    Blocked by  

    Description

    In 4.11, the minimum executable did not include open() and close() because the methods rtems_libio_post_driver() and rtems_libio_exit() were not included in the executable. On the master, these two methods are showing up in minimum and pulling in these methods.

    The dependency chain used to be if the console driver was installed, we needed to open and close stdin, stdout, and stderr. Now even without the console configured these are included.

    FWIW the minimum size looks pretty good on the master for sis. Fixing this would likely drop it at least another 5%.

    Comment 1
    1. Sebastian Huber, Mon, 21 Mar 2016 06:47:24 GMT

    This looks like a BSP-specific issue. On which BSP do you see this?

    Comment 2
    1. Chris Johns, Mon, 21 Mar 2016 06:50:32 GMT

    SIS by the looks of "FWIW the minimum size looks pretty good on the master for sis. ...".

    Comment 3
    1. Sebastian Huber, Mon, 21 Mar 2016 06:52:49 GMT

    Yes, but I don't see this problem on the sis BSP.

    Comment 4
    1. Sebastian Huber, Mon, 21 Mar 2016 07:41:18 GMT

    It seems to be the pc386 BSP. It pulls in a lot of stuff via printk() (e.g. console_select.c).

    Comment 5
    1. Sebastian Huber, Mon, 21 Mar 2016 07:57:49 GMT
    2. type: changed from defect to enhancement
    3. version: changed from 4.12 to 4.11
    4. component: changed from RTEMS Configuration to bsps

    The pc386 BSP has this problem also in 4.11.

    Comment 6
    1. Sebastian Huber, Mon, 21 Mar 2016 07:59:24 GMT
    2. summary: changed from Dependency on open() and close() reintroduced to pc386 BSP has complex dependencies
    Comment 7
    1. Joel Sherrill, Mon, 21 Mar 2016 12:35:15 GMT

    I saw this on sis. I was teaching a class and wouldn't use pc386 (or any BSP simulated on qemu) as my first choice since you want a simpler BSP and simpler way to execute it.

    But I don't see it in sis minimum.exe now. I am going to close this.

    Comment 8
    1. Joel Sherrill, Mon, 21 Mar 2016 12:36:24 GMT

    The pc386 and motorola_powerpc probe for a lot of features and don't have them as optional. They aren't focused on low size but flexibility. The pc386 can have the console changed by boot arguments and this is the intention. Most BSPs don't have that kind of flexibility.

    Comment 9
    1. Joel Sherrill, Mon, 21 Mar 2016 12:36:39 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix
    Comment 10
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 11
    1. Sebastian Huber, Tue, 10 Oct 2017 06:55:23 GMT
    2. component: changed from bsps to arch/i386
    Comment 12
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2664 - spclock_err02

    Link https://devel.rtems.org/ticket/2664
    Id 2664
    Reporter Joel Sherrill
    Created 18 March 2016 18:51:10
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution duplicate
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    New test failure on sis but likely all targets.

    __* BEGIN OF TEST SPCLOCK_ERR 2 __*
    TA1 - rtems_io_close - RTEMS_INVALID_NUMBER
    TA1 - rtems_io_control - RTEMS_INVALID_NUMBER
    TA1 - rtems_io_initialize - RTEMS_INVALID_NUMBER
    TA1 - rtems_io_open - RTEMS_INVALID_NUMBER
    TA1 - rtems_io_read - RTEMS_INVALID_NUMBER
    TA1 - rtems_io_write - RTEMS_INVALID_NUMBER
    TA1 - rtems_clock_set - 23:59:59 12/31/2000 - RTEMS_SUCCESSFUL
    TA1 - rtems_clock_get_tod - 00:00:00 01/01/2001 - RTEMS_SUCCESSFUL
    TA1 - rtems_clock_set - 23:59:59 12/31/1999 - RTEMS_SUCCESSFUL
    TA1 - rtems_clock_get_tod - 00:00:00 01/01/2000 - RTEMS_SUCCESSFUL
    assertion "ticks < 0x400000000" failed: file "../../cpukit/../../../sis/lib/include/rtems/score/watchdogimpl.h", line 316, function: _Watchdog_Ticks_from_timespec

    Breakpoint 1, _Terminate (the_source=the_source@entry=RTEMS_FATAL_SOURCE_ASSERT,

    is_internal=is_internal@entry=false, the_error=the_error@entry=33694096)
    at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36

    36 {
    (gdb) bt #0 _Terminate (the_source=the_source@entry=RTEMS_FATAL_SOURCE_ASSERT,

    is_internal=is_internal@entry=false, the_error=the_error@entry=33694096)
    at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36

    #1 0x0200aed4 in rtems_fatal (source=source@entry=RTEMS_FATAL_SOURCE_ASSERT,

    error=error@entry=33694096)
    at ../../../../../../rtems/c/src/../../cpukit/sapi/src/fatal2.c:34

    #2 0x02004a9c in assert_func (

    file=file@entry=0x201a650 "../../cpukit/../../../sis/lib/include/rtems/score/watchdogimpl.h", line=line@entry=316,
    func=func@entry=0x201a6d0 "_Watchdog_Ticks_from_timespec",
    failedexpr=failedexpr@entry=0x201a638 "ticks < 0x400000000")
    at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/assert.c:52

    #3 0x0200bbf8 in _Watchdog_Ticks_from_timespec (ts=0x2022210)

    at ../../cpukit/../../../sis/lib/include/rtems/score/watchdogimpl.h:316

    #4 _TOD_Set_with_timestamp (tod_as_timestamp=tod_as_timestamp@entry=0x2022280)

    at ../../../../../../rtems/c/src/../../cpukit/score/src/coretodset.c:40

    #5 0x02009880 in rtems_clock_set (tod=tod@entry=0x2022304)

    at ../../../../../../rtems/c/src/../../cpukit/rtems/src/clockset.c:42

    #6 0x02001818 in Init (argument=)

    at ../../../../../../../rtems/c/src/../../testsuites/sptests/spclock_err02/init.c:93

    #7 0x0200fcbc in _Thread_Entry_adaptor_numeric (executing=0x201fb90)

    at ../../../../../../rtems/c/src/../../cpukit/score/src/threadentryadaptornumeric---Type to continue, or q to quit---

    .c:25 #8 0x02012e0c in _Thread_Handler ()

    at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:93

    #9 0x02012d60 in _Thread_Handler ()

    at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:29

    (gdb) l init.c:93
    88 status = rtems_clock_get_tod( &time );
    89 directive_failed( status, "rtems_clock_get_tod" );
    90 print_time( "TA1 - rtems_clock_get_tod - ", &time, " - RTEMS_SUCCESSFUL\n" );
    91
    92 build_time( &time, 12, 31, 2100, 23, 59, 59, 0 );
    93 status = rtems_clock_set( &time );
    94 directive_failed( status, "rtems_clock_set" );
    95 print_time( "TA1 - rtems_clock_set - ", &time, " - RTEMS_SUCCESSFUL\n" );
    96 status = rtems_task_wake_after( rtems_clock_get_ticks_per_second() );
    97 status = rtems_clock_get_tod( &time );
    (gdb)

    Comment 1
    1. Sebastian Huber, Mon, 21 Mar 2016 06:37:48 GMT
    2. status: changed from new to closed
    3. resolution: set to duplicate

    This is with RTEMS_DEBUG enabled and is a duplicate of #2624. See also comment in _Watchdog_Ticks_from_timespec().

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2669 - Update OpenRISC toolchain in 4.12

    Link https://devel.rtems.org/ticket/2669
    Id 2669
    Reporter Stefan Wallentowitz
    Created 20 March 2016 15:53:21
    Modified 9 November 2017 06:27:14
    Owner  
    Type enhancement
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Bump the OpenRISC toolchain to newer versions:

    • Binutils to 2.26
    • GCC to 4.9.3
    • GDB to 7.11

    Attachments:

    1 Stefan Wallentowitz, Sun, 20 Mar 2016 15:53:44 GMT
      attach: set to 0001-Bump-OpenRISC-versions.patch
    Comment 1
    1. Stefan Wallentowitz, Thu, 24 Mar 2016 20:19:18 GMT

    In eac749bb80b184c1f5e34e40d745e0c428cb9f73/rtems-source-builder:

    Bump OpenRISC versions Bump the OpenRISC toolchain to newer versions. Binutils to 2.26 GCC to 4.9.3 GDB to 7.11 updates #2669
    Comment 2
    1. Gedare Bloom, Fri, 25 Mar 2016 12:27:54 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2672 - After latest patches with Objects_Get_by_name rtems-master not compiling without --enable-posix

    Link https://devel.rtems.org/ticket/2672
    Id 2672
    Reporter Serg Kruglov
    Created 21 March 2016 15:02:41
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber <sebastian.huber@…>
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    After latest patches with Objects_Get_by_name rtems-master not compiling if i use --disable-posix. Type "Objects_Get_by_name_error" not resolved in posixapi.h in sapi folder.
    If --enable-posix - all OK.

    Comment 1
    1. Sebastian Huber, Tue, 22 Mar 2016 06:44:56 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In c61431f9349869e94f12787abea796861039054e/rtems:

    score: Always declare _Objects_Get_by_name() Still define it only if RTEMS_SCORE_OBJECT_ENABLE_STRING_NAMES is defined. Close #2672.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2674 - CORE spinlock implementation is next to be useless

    Link https://devel.rtems.org/ticket/2674
    Id 2674
    Reporter Sebastian Huber
    Created 22 March 2016 13:27:50
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Lets assume we have two tasks A and B. Task A acquires a CORE spinlock. Now B somehow executes and tries to acquire the same CORE spinlock, then no progress can be made.

    Alternative implementation:

    Disable thread dispatching and interrupts while owning the spinlock. Forbid blocking calls while owning the spinlock.

    Drawback: The test cases of the Linux Test Project would fail:

    ​https://github.com/linux-test-project/ltp/blob/master/testcases/open_posix_testsuite/conformance/interfaces/pthread_spin_lock/1-2.c

    Optimization: User provided storage space for pthread_spin_t. In line with POSIX:

    "Only the object referenced by lock may be used for performing synchronization."

    ​http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_spin_destroy.html

    Comment 1
    1. Sebastian Huber, Wed, 23 Nov 2016 11:55:03 GMT

    In c42be504c92d76d2e06d0fc8ebd05fc913376d2d/rtems:

    posix: Add self-contained pthread spinlock Turn pthread_spinlock_t into a self-contained object. On uni-processor configurations, interrupts are disabled in the lock/trylock operations and the previous interrupt status is restored in the corresponding unlock operations. On SMP configurations, a ticket lock is a acquired and released in addition. The self-contained pthread_spinlock_t object is defined by Newlib in . typedef struct {
    struct _Ticket_lock_Control _lock; uint32_t _interrupt_state;
    } pthread_spinlock_t; This implementation is simple and efficient. However, this test case of the Linux Test Project would fail due to call of printf() and sleep() during spin lock ownership: ​https://github.com/linux-test-project/ltp/blob/master/testcases/open_posix_testsuite/conformance/interfaces/pthread_spin_lock/1-2.c There is only limited support for profiling on SMP configurations. Delete CORE spinlock implementation. Update #2674.
    Comment 2
    1. Sebastian Huber, Wed, 23 Nov 2016 14:12:55 GMT

    In d42cf3388e6fdc2a82a4fcbeb704c8277cd611a5/rtems:

    posix: Fix typo Update #2674.
    Comment 3
    1. Sebastian Huber, Fri, 02 Dec 2016 08:57:24 GMT

    In aadd318cd92e42839cf86260e1085f2953113180/rtems:

    posix: Fix fall back spinlock implementation Update #2674.
    Comment 4
    1. Sebastian Huber, Wed, 15 Feb 2017 13:30:19 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 5
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 6
    1. Sebastian Huber, Thu, 11 May 2017 07:41:37 GMT
    2. status: changed from assigned to closed
    3. version: 4.10 deleted
    4. resolution: set to fixed

    Added to documentation:

    ​file:///home/EB/sebastian_h/git-rtems-docs/build/c-user/html/symmetric_multiprocessing_services.html#disabling-of-interrupts

    Comment 7
    1. Sebastian Huber, Thu, 12 Oct 2017 05:16:16 GMT

    In 9c0cefb/rtems:

    confdefs: Add warnings for obsolete options Update #2674. Close #3112. Close #3113. Close #3114. Close #3115. Close #3116.
    Comment 8
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 9
    1. Sebastian Huber, Wed, 18 Oct 2017 06:53:08 GMT

    In 6087f33e/rtems:

    tmtests/tmfine01: Add test cases Update #2674. Update #3112. Update #3113. Update #3114. Update #3115.
    Comment 10
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2676 - Obsolete clock_get() directive

    Link https://devel.rtems.org/ticket/2676
    Id 2676
    Reporter Joel Sherrill
    Created 22 March 2016 18:32:30
    Modified 24 November 2017 12:52:03
    Owner Joel Sherrill <joel@…>
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This is deprecated on the 4.11 branch and its use has been isolated in the source tree.

    • Remove clock_get()
    • Should allow deletion of rtems_clock_get_options

    $ grep -rl "clock_get(" .
    ./doc/user/clock.t
    ./testsuites/tmtests/tmoverhd/testtask.c
    ./testsuites/tmtests/tmoverhd/dumrtems.h
    ./testsuites/sptests/spclockget/init.c
    ./testsuites/sptests/spclockget/spclockget.doc
    ./cpukit/rtems/include/rtems/rtems/clock.h
    ./cpukit/rtems/src/clockget.c

    Comment 1
    1. Joel Sherrill, Thu, 14 Apr 2016 21:53:42 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In e65c45c4b6cf6dfb485bef48385e39969de8b361/rtems:

    Obsolete rtems_clock_get() directive. This service was marked as deprecated long prior to the 4.11 release series and is now being removed. closes #2676.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 4
    1. Sebastian Huber, Fri, 24 Nov 2017 12:52:03 GMT

    In 83ad1c5/rtems:

    ada/sp04: Fix clock get Update #2676.

    2680 - Add pthread_setconcurrency() and pthread_getconcurrency()

    Link https://devel.rtems.org/ticket/2680
    Id 2680
    Reporter Joel Sherrill
    Created 29 March 2016 21:14:23
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type enhancement
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    __* Code merged. Ticket changed to documentation to remind us to add documentation when master documentation reopens in new format. __

    We only require the simple implementation documented here:

    ​http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_getconcurrency.html

    This is required for FACE Conformance.

    Comment 1
    1. Joel Sherrill, Fri, 15 Apr 2016 14:41:46 GMT
    2. owner: changed from Joel Sherrill to Chris Johns
    3. status: changed from new to assigned
    4. component: changed from cpukit to Documentation
    5. description: modified (diff)

    ​https://git.rtems.org/rtems/commit/?id=8228548d127dd73439615f45f38f92b8a42bcfed added the calls.

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 4
    1. Joel Sherrill, Thu, 12 Oct 2017 00:58:27 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d36d685/rtems-docs:

    posix-users/thread.rst: Add pthread_getconcurrency and pthread_setconcurrency Closes #2680.
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2683 - Configuration table's smp_enabled conditional on RTEMS_SMP

    Link https://devel.rtems.org/ticket/2683
    Id 2683
    Reporter Chris Johns
    Created 4 April 2016 01:48:22
    Modified 31 March 2020 10:59:35
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The rtems_configuration_table has:

     #ifdef RTEMS_SMP
    bool smp_enabled;
    #endif

    I would like the smp_enabled variable to always be defined for 4.12 and always set to false when RTEMS_SMP is not defined. It is impossible to parse the configuration table with external auditing tools with out this field always being present unless you examine the DWARF debug info.

    I wonder if User_multiprocessing_table is the same so this means the members of the configuration table must always be defined.

    Chris

    Comment 1
    1. Chris Johns, Mon, 04 Apr 2016 01:48:55 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Mon, 04 Apr 2016 05:27:59 GMT

    Yes, the top-level configuration tables should contain no pre-processor stuff.

    Comment 3
    1. Joel Sherrill, Mon, 04 Apr 2016 09:05:18 GMT

    With per function/data element linking, will the smp enabled variable even make it to a linked uniprocessor exe if SMP is disabled and the variable is always false? There will be no code to reference it.

    Comment 4
    1. Chris Johns, Mon, 04 Apr 2016 21:23:58 GMT

    Replying to joel.sherrill:

    With per function/data element linking, will the smp enabled variable even make it to a linked uniprocessor exe if SMP is disabled and the variable is always false? There will be no code to reference it.

    It is in the configuration table. All that is being suggested to always have the elements in the table. There is no code.

    Comment 5
    1. Sebastian Huber, Wed, 15 Feb 2017 14:25:52 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    4. milestone: changed from 4.12 to Indefinite
    Comment 6
    1. Sebastian Huber, Tue, 31 Mar 2020 10:59:06 GMT
    2. status: changed from assigned to closed
    3. resolution: set to invalid
    4. milestone: changed from Indefinite to 5.1

    The configuration table not longer exists. In particular, the SMP enabled indicator is no longer used. The User_multiprocessing_table no longer exists. In MPCI configurations, there is now an _MPCI_Configuration.


    2684 - rtems/c/src/lib/libbsp/sparc/leon3/clock/ckinit.c:122: duplicate if

    Link https://devel.rtems.org/ticket/2684
    Id 2684
    Reporter David Binderman
    Created 7 April 2016 21:05:07
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component arch/sparc
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    rtems/c/src/lib/libbsp/sparc/leon3/clock/ckinit.c:122]: (style) Expression is always false because 'else if' condition matches previous condition at line 116.

    Source code is

    } else if (state == 1) {

    unsigned int ks = 1U << 5;

    state = 0;

    irqmp_ts->control = ks | s1_s2 | (unsigned int) clkirq;

    } else if (state == 1) {

    Comment 1
    1. Sebastian Huber, Thu, 14 Apr 2016 05:52:58 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    4. version: changed from 4.10 to 4.11
    5. milestone: changed from 4.11.1 to 4.12
    Comment 2
    1. Sebastian Huber, Tue, 05 Jul 2016 07:59:52 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    4. component: changed from General to bsps

    [291945f137d411834c0eaf3b0bb819263efb845b/rtems]

    No plans to fix this for RTEMS 4.11.

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:53:06 GMT
    2. component: changed from bsps to arch/sparc
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2685 - c/src/lib/libbsp/arm/atsam/network/if_atsam.c:409: possible bad if statement

    Link https://devel.rtems.org/ticket/2685
    Id 2685
    Reporter David Binderman
    Created 7 April 2016 21:07:24
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    rtems/c/src/lib/libbsp/arm/atsam/network/if_atsam.c:409]: (style) Redundant condition: If 'phy <= 0', the comparison 'phy <= 31' is always true.

    Source code is

    if ((phy <= 0) && (phy <= 31)) {

    /*

    • invalid phy number
      */

    Maybe better code

    if ((phy <= 0) (phy >= 31)) {

    /*

    • invalid phy number
      */
    Comment 1
    1. Sebastian Huber, Thu, 14 Apr 2016 05:52:12 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    4. version: changed from 4.10 to 4.12
    5. milestone: changed from 4.11.1 to 4.12
    Comment 2
    1. Alexander Krutwig, Mon, 06 Jun 2016 11:17:28 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 15f0f9b448150f1ac828a9d3e498a7249dbdc362/rtems:

    atsam: Fix network interface PHY handling Close #2685.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Mon, 16 Oct 2017 06:24:30 GMT
    2. component: changed from unspecified to arch/arm
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2689 - POSIX key destructors must be called during thread restart

    Link https://devel.rtems.org/ticket/2689
    Id 2689
    Reporter Sebastian Huber
    Created 14 April 2016 06:06:04
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    POSIX key destructors must be called during thread restart. Just like the POSIX cleanup handlers. This ensures that the TLS object destructors are called during thread restart for example. It is important for the global construction, which uses a thread restart to run the Init task in a clean environment.

    Comment 1
    1. Sebastian Huber, Thu, 14 Apr 2016 06:06:19 GMT
    2. component: changed from General to cpukit
    Comment 2
    1. Sebastian Huber, Thu, 14 Apr 2016 07:01:14 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 6efa3498504bffde166b4663319bd7d94ea42a08/rtems:

    posix: Run key destructors during thread restart POSIX key destructors must be called during thread restart. Just like the POSIX cleanup handlers. This ensures that the TLS object destructors are called during thread restart for example. It is important for the global construction, which uses a thread restart to run the Init task in a clean environment. Close #2689.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2692 - User extensions execution order must be clarified

    Link https://devel.rtems.org/ticket/2692
    Id 2692
    Reporter Sebastian Huber
    Created 14 April 2016 07:00:24
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority high
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The implemented and documented execution order of some user extensions disagree. Intended behaviour must be tested. Documentation must be updated accordingly.

    Comment 1
    1. Sebastian Huber, Tue, 19 Apr 2016 05:23:26 GMT

    In 709f38a97287ff1aa8e8c0668c2d066e711db87c/rtems:

    score: Use chain iterator for user extensions Add a lock and use a chain iterator for safe iteration during concurrent user extension addition and removal. Ensure that dynamically added thread delete and fatal extensions are called in reverse order. Update #2555. Update #2692.
    Comment 2
    1. Sebastian Huber, Fri, 23 Dec 2016 14:10:09 GMT
    2. priority: changed from normal to high
    Comment 3
    1. Sebastian Huber, Thu, 26 Jan 2017 12:55:05 GMT

    In 6f6da82ca0b57ed1c42050f8103c2ea2adb3d3e2/rtems:

    score: Fix user extensions order Use forward and reverse order for initial and dynamic extensions. This is the behaviour documented in the C Users Guide. Change thread terminate order to backward to be in line with the thread delete order. Change fatal error order to forward to ensure that initial extensions are called first due the peculiar execution context of fatal error extensions, see _Terminate() documentation. Update #2692.
    Comment 4
    1. Sebastian Huber, Fri, 27 Jan 2017 06:24:44 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [b1e3b75e907db0f448610f18c5e11dd1ee9448b2/rtems-docs]

    Comment 5
    1. Sebastian Huber, Tue, 21 Feb 2017 11:12:45 GMT

    In c54769e71e1c87c55e482a3d05322e728fb2aac1/rtems:

    spextensions01: Fix extension create order Update #2692.
    Comment 6
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2693 - Update doc to reflect obsoleting rtems_clock_get()

    Link https://devel.rtems.org/ticket/2693
    Id 2693
    Reporter Joel Sherrill
    Created 14 April 2016 21:52:32
    Modified 15 April 2020 14:57:16
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Ticket to reflect documentation change needed on the master but not on 4.11. When new documentation format is available for master, this needs to be accounted for.

    Attachments:

    1 Joel Sherrill, Thu, 14 Apr 2016 21:53:01 GMT
      attach: set to 0002-doc-user-clock.t-Remove-obsolete-rtems_clock_get.patch
    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Sebastian Huber, Wed, 14 Jun 2017 13:50:19 GMT

    Does it make sense to remove this function? It is just an API glue layer and adds no overhead to an application if not used.

    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 4
    1. Joel Sherrill, Wed, 11 Oct 2017 23:42:57 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 21e0fcd/rtems-docs:

    c-user: Update to reflect rtems_clock_get() being obsoleted. Closes #2693.
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 6
    1. Sebastian Huber, Wed, 15 Apr 2020 14:57:16 GMT

    In e150e16/rtems-docs:

    c-user: Add removed directive rtems_clock_get() Be in line with Task Manager chapter. Update #2693.

    2694 - linking issue for htonl, etc when using -std=c99

    Link https://devel.rtems.org/ticket/2694
    Id 2694
    Reporter Joel Sherrill
    Created 15 April 2016 15:17:18
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component network/legacy
    Status closed
    Resolution worksforme
    Version 5
    Milestone 5.1
    Priority low
    Severity normal
    Keywords  
    Cc Chris Johns Gedare Bloom
    Blocking  
    Blocked by  

    Description

    When -std=c99 is on the compile line, there is a linking error for undefined references to htonl, htons, ntohl, and ntohs. This test case is just for htonl but others should be similar.

    This likely impacts the 4.11 branch of rtems-libbsd as well but I was testing on master.

    Test case
    ======================
    #include

    int main(

    int argc,
    char __argv __

    )
    {

    uint32_t v = (uint32_t) argc;
    uint32_t rc = htonl(v);
    return v;

    }
    ======================

    This script was what I used to find what caused the linking error to go away.

    ======================
    RTEMS_MAKEFILE_PATH=/home/joel/rtems-4.11-work/tools/4.12/i386-rtems4.12/pc586/

    i386-rtems4.12-gcc -std=c99 \

    -B${RTEMS_MAKEFILE_PATH}/lib -specs bsp_specs -qrtems \
    -D_XOPEN_SOURCE=600 -DUSE_SVID main.c -lbsd -lm -lbsd

    i386-rtems4.12-gcc -std=c99 \

    -B${RTEMS_MAKEFILE_PATH}/lib -specs bsp_specs -qrtems \
    -DUSE_SVID main.c -lbsd -lm -lbsd

    i386-rtems4.12-gcc -std=c99 \

    -B${RTEMS_MAKEFILE_PATH}/lib -specs bsp_specs -qrtems \
    main.c -lbsd -lm -lbsd

    i386-rtems4.12-gcc \

    -B${RTEMS_MAKEFILE_PATH}/lib -specs bsp_specs -qrtems \
    main.c -lbsd -lm -lbsd

    ======================

    Comment 1
    1. Sebastian Huber, Fri, 23 Dec 2016 14:10:53 GMT
    2. priority: changed from normal to low
    Comment 2
    1. Sebastian Huber, Mon, 23 Jan 2017 07:34:47 GMT

    I cannot reproduce this problem on the master.

    Comment 3
    1. Joel Sherrill, Mon, 23 Jan 2017 15:42:57 GMT
    2. status: changed from new to closed
    3. resolution: set to worksforme
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2695 - Add libatomic for RTEMS

    Link https://devel.rtems.org/ticket/2695
    Id 2695
    Reporter Sebastian Huber
    Created 19 April 2016 06:00:26
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component tool/gcc
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Tue, 19 Apr 2016 06:00:38 GMT
    2. version: changed from 4.10 to 4.11
    Comment 2
    1. Sebastian Huber, Tue, 19 Apr 2016 07:27:46 GMT

    ​https://lists.rtems.org/pipermail/devel/2016-April/014554.html ​https://lists.rtems.org/pipermail/devel/2016-April/014555.html ​https://lists.rtems.org/pipermail/devel/2016-April/014556.html

    Comment 3
    1. Chris Johns, Tue, 19 Apr 2016 07:33:48 GMT

    Replying to sebastian.huber:

    ​https://lists.rtems.org/pipermail/devel/2016-April/014555.html

    Does this patch require crt0.c being updated?

    Re ​https://lists.rtems.org/pipermail/users/2016-April/030145.html

    Comment 4
    1. Sebastian Huber, Tue, 19 Apr 2016 08:16:28 GMT

    Replying to chrisj:

    Replying to sebastian.huber:

    ​https://lists.rtems.org/pipermail/devel/2016-April/014555.html

    Does this patch require crt0.c being updated?

    Re ​https://lists.rtems.org/pipermail/users/2016-April/030145.html

    Yes:

    ​​https://lists.rtems.org/pipermail/devel/2016-April/014558.html

    Comment 5
    1. Chris Johns, Tue, 19 Apr 2016 08:19:46 GMT

    Replying to sebastian.huber:

    ​​https://lists.rtems.org/pipermail/devel/2016-April/014558.html

    Is that on top of Joel's patch?

    Comment 6
    1. Sebastian Huber, Wed, 27 Apr 2016 07:15:27 GMT

    ​https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=235466

    Comment 7
    1. Sebastian Huber, Fri, 01 Jul 2016 10:01:24 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Fixed in this RSB version:

    ​https://git.rtems.org/rtems-source-builder/commit/?id=3da4d0e5ce50909d4fe45168d6d6a82ebc119f92

    Comment 8
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 9
    1. Sebastian Huber, Tue, 10 Oct 2017 05:58:26 GMT
    2. component: changed from GCC to tool/gcc
    Comment 10
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2696 - Unpredictable errno value returned by sem_wait() in case of semaphore deletion

    Link https://devel.rtems.org/ticket/2696
    Id 2696
    Reporter Sebastian Huber
    Created 19 April 2016 09:14:18
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    _POSIX_Semaphore_Delete() used -1 for the thread queue flush status which in turn resulted in an invalid memory access in _POSIX_Semaphore_Translate_core_semaphore_return_code().

    Comment 1
    1. Joel Sherrill, Tue, 19 Apr 2016 13:10:50 GMT

    I went back to the 4.8 branch and the translation was a switch in semaphorewaitsupp.c which covered all cases. Also the error returned was not -1 but CORE_SEMAPHORE_WAS_DELETED.

    Somewhere along the line, the code was changed to a table lookup and range checking was moved to an ifdef DEBUG.

    I have no idea why the status returned is no longer CORE_SEMAPHORE_WAS_DELETED which would likely not result in an out of range access.

    Did the debug check catch this error? If not, then the debug check is insufficient.

    Comment 2
    1. Sebastian Huber, Tue, 19 Apr 2016 13:14:45 GMT

    There was no test case, so the debug check was simply not triggered.

    Comment 3
    1. Sebastian Huber, Thu, 21 Apr 2016 05:33:39 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 90f1265e5dffe0f834ee9c55640a34fd90be8f12/rtems:

    score: Fix _CORE_semaphore_Flush() Use proper CORE_semaphore_Status for _CORE_semaphore_Flush() and _CORE_semaphore_Destroy() operations. Close #2696.
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2698 - GCC 6.1 is broken for microblaze

    Link https://devel.rtems.org/ticket/2698
    Id 2698
    Reporter Sebastian Huber
    Created 21 April 2016 06:17:33
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component tool/gcc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The enabled libatomic reveals a bug in the microblaze RTEMS configuration:

    configure:3566: checking for C compiler default output file name
    configure:3588: /scratch/git-rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.0.1-RC-20160415-newlib-6ee81f44e04848901c7b05c968564d34a7ceed06-x86_64-linux-gnu-1/build/./gcc/xgcc -B/scratch/git-rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.0.1-RC-20160415-newlib-6ee81f44e04848901c7b05c968564d34a7ceed06-x86_64-linux-gnu-1/build/./gcc/ -nostdinc -B/scratch/git-rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.0.1-RC-20160415-newlib-6ee81f44e04848901c7b05c968564d34a7ceed06-x86_64-linux-gnu-1/build/microblaze-rtems4.12/newlib/ -isystem /scratch/git-rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.0.1-RC-20160415-newlib-6ee81f44e04848901c7b05c968564d34a7ceed06-x86_64-linux-gnu-1/build/microblaze-rtems4.12/newlib/targ-include -isystem /scratch/git-rtems-source-builder/rtems/build/microblaze-rtems4.12-gcc-6.0.1-RC-20160415-newlib-6ee81f44e04848901c7b05c968564d34a7ceed06-x86_64-linux-gnu-1/gcc-6.0.1-RC-20160415/newlib/libc/include -B/build/rtems-4.12/microblaze-rtems4.12/bin/ -B/build/rtems-4.12/microblaze-rtems4.12/lib/ -isystem /build/rtems-4.12/microblaze-rtems4.12/include -isystem /build/rtems-4.12/microblaze-rtems4.12/sys-include -g -O2 conftest.c >&5
    /build/rtems-4.12/microblaze-rtems4.12/bin/ld: cannot open linker script file xilinx.ld: No such file or directory
    collect2: error: ld returned 1 exit status

    Reason:

    gcc/config/microblaze/microblaze.h: %{!T*: -dT xilinx.ld%s}"

    This should be somehow fixed in the RTEMS GCC configuration for microblaze.

    Comment 1
    1. Joel Sherrill, Thu, 21 Apr 2016 14:54:47 GMT

    This is in gcc/config/microblaze/microblaze.h:

    ============================================================= /* Extra switches sometimes passed to the linker. */ /* -xl-mode-xmdstub translated to -Zxl-mode-xmdstub -- deprecated. */

    #define LINK_SPEC "%{shared:-shared} -N -relax \

    %{mbig-endian:-EB --oformat=elf32-microblaze} \ %{mlittle-endian:-EL --oformat=elf32-microblazeel} \ %{Zxl-mode-xmdstub:-defsym _TEXT_START_ADDR=0x800} \ %{mxl-mode-xmdstub:-defsym _TEXT_START_ADDR=0x800} \ %{mxl-gp-opt:%{G*}} %{!mxl-gp-opt: -G 0} \ %{!T*: -dT xilinx.ld%s}"

    =============================================================

    We can add an undef of LINK_SPEC to gcc/config/microblaze/rtems.h as a minimum. Or we can redefine it to a subset of what it is by default.

    Based on the set of libc.a's installed, I think we need at least the endian flags. I would tend to keep the mxl-gp-opt since it looks harmless enough. But I would redefine and drop the xmdstub and xilinx.ld ones (drop 3, keep rest). That results in:

    #undef LINK_SPEC `#define LINK_SPEC "%{shared:-shared} -N -relax \

    %{mbig-endian:-EB --oformat=elf32-microblaze} \` %{mlittle-endian:-EL --oformat=elf32-microblazeel} \ %{mxl-gp-opt:%{G*}} %{!mxl-gp-opt: -G 0}

    How does that look?

    Comment 2
    1. Joel Sherrill, Thu, 21 Apr 2016 15:41:04 GMT

    I posted a patch which builds but I haven't tested it with RTEMS. Give this a try:

    ​https://lists.rtems.org/pipermail/devel/2016-April/014651.html

    Comment 3
    1. Sebastian Huber, Wed, 27 Apr 2016 07:08:00 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    ​https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=235465

    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Tue, 10 Oct 2017 05:58:26 GMT
    2. component: changed from GCC to tool/gcc
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2700 - cpukit/libfs/src/nfsclient/src/rpcio.c:524]: (style) Suspicious condition

    Link https://devel.rtems.org/ticket/2700
    Id 2700
    Reporter David Binderman
    Created 26 April 2016 09:38:33
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber <sebastian.huber@…>
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    cpukit/libfs/src/nfsclient/src/rpcio.c:524]: (style) Suspicious condition (assignment + comparison); Clarify expression with parentheses.

    Source code is

    if ( (len = getgroups(NGROUPS, gids) < 0 ) ) {

    maybe better code

    if ( (len = getgroups(NGROUPS, gids)) < 0 ) {

    Comment 1
    1. David Binderman, Fri, 20 Jan 2017 15:17:24 GMT

    Still broken nine months later.

    Comment 2
    1. Sebastian Huber, Mon, 23 Jan 2017 13:39:44 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In c0151e6c6486ce3ae3623e616326fae626f32eb2/rtems:

    nfsclient: Fix suspicious condition Close #2700.
    Comment 3
    1. Sebastian Huber, Mon, 23 Jan 2017 13:40:22 GMT
    2. milestone: changed from 4.11.1 to 4.12
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2701 - Rename asm file with .S(upper case) ext. name

    Link https://devel.rtems.org/ticket/2701
    Id 2701
    Reporter printk
    Created 27 April 2016 16:48:33
    Modified 9 November 2017 06:27:14
    Owner Amar Takhar
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity major
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The are some asm file with .s ext. name, .s and .S is different for gnu as, the pre processed produce .s file from
    .S. In a word, .S can use
    #define
    .s can not.
    KBuild clean .s files when make clean.
    I have submit a patch to devel, but blocked. Too big patch.

    Comment 1
    1. printk, Wed, 27 Apr 2016 16:50:00 GMT

    find *.s grep -R xxx.s There is one .am file contains the xxx.s Only one.

    Comment 2
    1. Sebastian Huber, Tue, 20 Dec 2016 09:31:52 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 81af80e586475843624c6e8dc3aa77f97b37b5a9/rtems:

    Rename *.s to *.S Consistently use *.S for assembler files. Close #2701.
    Comment 3
    1. Chris Johns, Mon, 27 Mar 2017 06:48:47 GMT
    2. milestone: changed from 4.12.1 to 4.12.0

    Move to the first 4.12 milestone.

    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:03:57 GMT
    2. component: changed from Code to build
    Comment 5
    1. Sebastian Huber, Tue, 10 Oct 2017 06:04:12 GMT
    2. component: changed from build to RSB
    Comment 6
    1. Sebastian Huber, Tue, 10 Oct 2017 06:04:32 GMT
    2. component: changed from RSB to build
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2702 - Remove descriptor objects for POSIX message queues

    Link https://devel.rtems.org/ticket/2702
    Id 2702
    Reporter Sebastian Huber
    Created 29 April 2016 07:11:23
    Modified 15 December 2017 06:24:12
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The mq_open() function returns a descriptor to a POSIX message queue object identified by a name. This is similar to sem_open(). In contrast to the POSIX semaphore the POSIX message queues use a separate object for the descriptor. This extra object is superfluous, since the object identifier can be used directly for this purpose, just like for the semaphores.

    Comment 1
    1. Sebastian Huber, Mon, 02 May 2016 10:07:53 GMT

    In c8982e5f6a4857444676165deab1e08dc91a6847/rtems:

    posix: Simplify message queues The mq_open() function returns a descriptor to a POSIX message queue object identified by a name. This is similar to sem_open(). In contrast to the POSIX semaphore the POSIX message queues use a separate object for the descriptor. This extra object is superfluous, since the object identifier can be used directly for this purpose, just like for the semaphores. Update #2702. Update #2555.
    Comment 2
    1. Sebastian Huber, Mon, 19 Dec 2016 13:52:36 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [7b0db6a9d58140150134718c34a1b552d4e0d4ae/rtems-docs]

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 6
    1. Sebastian Huber, Fri, 15 Dec 2017 06:24:12 GMT

    In e1563f37/rtems:

    posix: Remove unused global variable Update #2702. Update #2555.

    2706 - Buffer allocation of capture engine is broken on SMP configurations

    Link https://devel.rtems.org/ticket/2706
    Id 2706
    Reporter Sebastian Huber
    Created 12 May 2016 09:03:22
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber <sebastian.huber@…>
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The capture engine uses function static variables.

    Comment 1
    1. Sebastian Huber, Thu, 12 May 2016 11:35:52 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 2f11d4a0144207321838f746471b56c4cfa40a0d/rtems:

    capture: Fix buffer allocation and free Do not use function static variables. Remove superfluous volatile qualifiers. Use proper integer types. Close #2706.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2707 - Unsafe use of current processor index in capture engine

    Link https://devel.rtems.org/ticket/2707
    Id 2707
    Reporter Sebastian Huber
    Created 12 May 2016 09:05:36
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber <sebastian.huber@…>
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The current processor index is used outside a thread dispatch disabled section.

    Comment 1
    1. Sebastian Huber, Thu, 12 May 2016 11:35:33 GMT

    In 0727760336bfcb4f66771f1a86ee3bb923d2cfc4/rtems:

    rtems: Add rtems_interrupt_lock_interrupt_disable Update #2707.
    Comment 2
    1. Sebastian Huber, Thu, 12 May 2016 11:36:20 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In df23f464be5733b489eae03428d5449a37b310b9/rtems:

    capture: Fix use of per-processor data Get the current processor index only once and with interrupts disabled. Close #2707.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2714 - A pthread_detach() does not lead to a resource reclamation

    Link https://devel.rtems.org/ticket/2714
    Id 2714
    Reporter Sebastian Huber
    Created 17 May 2016 08:59:44
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    According to POSIX a pthread_detach() should lead to a resource reclamation if the thread is already cancelled.

    Comment 1
    1. Sebastian Huber, Tue, 17 May 2016 09:00:36 GMT

    In 9d8ee11e55a0c9e515409f40900917a58d3bf6cc/rtems:

    psxtests/psxcancel: Add pthread_detach() tests Update #2714.
    Comment 2
    1. Sebastian Huber, Fri, 20 May 2016 05:56:37 GMT

    In 12a1228c593166069ac316f91865bdd9bb812ba1/rtems:

    psxclassic01: Assume correct pthread_detach() Update #2714.
    Comment 3
    1. Sebastian Huber, Fri, 20 May 2016 05:59:18 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 54550e048d3a49435912797d2024f80671e93267/rtems:

    posix: Rework pthread_join() Rework pthread_join() to use _Thread_Join(). Close #2402. Update #2555. Update #2626. Close #2714.
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Mon, 16 Oct 2017 06:23:11 GMT
    2. component: changed from unspecified to posix
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2718 - Blocking _CORE_message_queue_Submit() may lead to unpredictable results

    Link https://devel.rtems.org/ticket/2718
    Id 2718
    Reporter Sebastian Huber
    Created 24 May 2016 13:30:17
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The thread wait return code is not properly initialized before the thread queue enqueue.

    Comment 1
    1. Sebastian Huber, Tue, 24 May 2016 13:37:51 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 4b623d655bb4f4853a6ce385ae17e505dddbe7ce/rtems:

    score: Fix blocking _CORE_message_queue_Submit() Close #2718.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2722 - SEM_VALUE_MAX is unusually small on RTEMS

    Link https://devel.rtems.org/ticket/2722
    Id 2722
    Reporter Sebastian Huber
    Created 25 May 2016 12:13:57
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component tool/newlib
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    RTEMS defines SEM_VALUE_MAX to 32767 in Newlib

    newlib/libc/sys/rtems/include/limits.h

    Other systems use INT_MAX or 2147483647.

    Comment 1
    1. Sebastian Huber, Wed, 21 Dec 2016 06:44:33 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    4. component: changed from General to tools
    5. type: changed from defect to enhancement

    ​https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=483e696049e6c254d30663b15c7a5df1b75ca735

    Comment 2
    1. Sebastian Huber, Wed, 21 Dec 2016 06:45:03 GMT
    2. component: changed from tools to Newlib
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2723 - CPUINFO command to report per-processor information

    Link https://devel.rtems.org/ticket/2723
    Id 2723
    Reporter Sebastian Huber
    Created 31 May 2016 08:09:28
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add a CPUINFO command to report per-processor information, e.g. processor index, online state and scheduler assignment.

    [/] # cpuinfo
    -------------------------------------------------------------------------------
    PER PROCESSOR INFORMATION
    -------+--------+--------------+-----------------------------------------------
    INDEX | ONLINE | SCHEDULER ID | SCHEDULER NAME
    -------+--------+--------------+-----------------------------------------------
    0 | 1 | 0x0f010001 | MPS
    1 | 1 | 0x0f010001 | MPS
    2 | 1 | 0x0f010001 | MPS
    3 | 1 | 0x0f010001 | MPS
    4 | 1 | 0x0f010001 | MPS
    5 | 1 | 0x0f010001 | MPS
    6 | 1 | 0x0f010001 | MPS
    7 | 1 | 0x0f010001 | MPS
    8 | 1 | 0x0f010001 | MPS
    9 | 1 | 0x0f010001 | MPS
    10 | 1 | 0x0f010001 | MPS
    11 | 1 | 0x0f010001 | MPS
    12 | 1 | 0x0f010001 | MPS
    13 | 1 | 0x0f010001 | MPS
    14 | 1 | 0x0f010001 | MPS
    15 | 1 | 0x0f010001 | MPS
    16 | 1 | 0x0f010001 | MPS
    17 | 1 | 0x0f010001 | MPS
    18 | 1 | 0x0f010001 | MPS
    19 | 1 | 0x0f010001 | MPS
    20 | 1 | 0x0f010001 | MPS
    21 | 1 | 0x0f010001 | MPS
    22 | 1 | 0x0f010001 | MPS
    23 | 1 | 0x0f010001 | MPS
    Comment 1
    1. Sebastian Huber, Tue, 31 May 2016 08:12:02 GMT

    In 01cb5540bd7b391f9a19c79b284fdfc4385afc06/rtems:

    shell: Add CPUINFO command Update #2723.
    Comment 2
    1. Sebastian Huber, Mon, 19 Dec 2016 14:07:20 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [f5170100f1a2fe449c327cb6786c4f3202cf07e8/rtems-docs]

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:35:44 GMT
    2. component: changed from misc to unspecified
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2725 - Classic binary semaphores without a locking protocol can be released by everyone

    Link https://devel.rtems.org/ticket/2725
    Id 2725
    Reporter Sebastian Huber
    Created 3 June 2016 06:16:16
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority high
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The Classic binary semaphores without a locking protocol can be released by everyone, e.g. in contrast to the POSIX mutexes (all variants) or the Classic binary semphores with priority inheritance or ceiling, there is no owner check in the release path.

    This behaviour is a bit unexpected and not documented.

    The following test case fails in case an owner check is added:

    *** BEGIN OF TEST SP 42 ***
    Exercising blocking discipline w/extract in FIFO order
    Exercising blocking discipline w/unblock in FIFO order
    TA00 - unblocked - OK
    rtems_semaphore_delete FAILED -- expected (RTEMS_SUCCESSFUL) got (RTEMS_RESOURCE_IN_USE)

    This is actually a bug in the test, since an available mutex is released again.

    Comment 1
    1. Sebastian Huber, Fri, 03 Jun 2016 06:24:47 GMT
    2. component: changed from General to cpukit
    3. summary: changed from Classic binary semaphores without a locking protocol can be release by everyone to Classic binary semaphores without a locking protocol can be released by everyone
    Comment 2
    1. Chris Johns, Fri, 03 Jun 2016 06:25:16 GMT
    2. description: modified (diff)
    Comment 3
    1. Sebastian Huber, Mon, 06 Jun 2016 11:17:00 GMT

    In 3ad5f86cf6803204b98760cdce0c56ef6d79bccd/rtems:

    rtems: Fix no protocol mutex release The Classic binary semaphores without a locking protocol (RTEMS_BINARY_SEMAPHORE) could be released by everyone, e.g. in contrast to the POSIX mutexes (all variants) or the Classic binary semphores with priority inheritance or ceiling, there was no owner check in the release path. This behaviour was a bit unexpected and not documented. Add an owner check to the release path. Update sptests/sp42 accordingly. This change has nothing to do with the simple binary semaphores (RTEMS_SIMPLE_BINARY_SEMAPHORE) which have no owner at all. Update #2725
    Comment 4
    1. Sebastian Huber, Fri, 23 Dec 2016 14:10:09 GMT
    2. priority: changed from normal to high
    Comment 5
    1. Sebastian Huber, Mon, 23 Jan 2017 12:46:12 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [31157bcd477336016a76ae75c8c51aca42c608fb/rtems-docs]

    Comment 6
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2726 - grascs.c: Questionable use of binary semaphore

    Link https://devel.rtems.org/ticket/2726
    Id 2726
    Reporter Sebastian Huber
    Created 6 June 2016 09:02:14
    Modified 9 November 2017 06:27:14
    Owner Daniel Hellstrom
    Type defect
    Component arch/sparc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Use a simple binary semaphore or binary semaphore with inherit priority instead.

    c/src/lib/libbsp/sparc/shared/ascs/grascs.c-
    c/src/lib/libbsp/sparc/shared/ascs/grascs.c- /* Create semaphores for blocking ASCS_TC/TM functions */
    c/src/lib/libbsp/sparc/shared/ascs/grascs.c- if(rtems_semaphore_create(rtems_build_name('A','S','C','0'),1,
    c/src/lib/libbsp/sparc/shared/ascs/grascs.c: (RTEMS_FIFO|RTEMS_BINARY_SEMAPHORE|
    c/src/lib/libbsp/sparc/shared/ascs/grascs.c- RTEMS_NO_INHERIT_PRIORITY|RTEMS_LOCAL|
    c/src/lib/libbsp/sparc/shared/ascs/grascs.c- RTEMS_NO_PRIORITY_CEILING), 0,
    c/src/lib/libbsp/sparc/shared/ascs/grascs.c- &cfg->tcsem1) != RTEMS_SUCCESSFUL) {
    c/src/lib/libbsp/sparc/shared/ascs/grascs.c-    goto init_error2;
    c/src/lib/libbsp/sparc/shared/ascs/grascs.c- }
    c/src/lib/libbsp/sparc/shared/ascs/grascs.c- if(rtems_semaphore_create(rtems_build_name('A','S','C','2'),0,
    c/src/lib/libbsp/sparc/shared/ascs/grascs.c: (RTEMS_FIFO|RTEMS_BINARY_SEMAPHORE|
    c/src/lib/libbsp/sparc/shared/ascs/grascs.c- RTEMS_NO_INHERIT_PRIORITY|RTEMS_LOCAL|
    c/src/lib/libbsp/sparc/shared/ascs/grascs.c- RTEMS_NO_PRIORITY_CEILING), 0,
    c/src/lib/libbsp/sparc/shared/ascs/grascs.c- &cfg->tcsem2) != RTEMS_SUCCESSFUL) {
    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Chris Johns, Mon, 14 Aug 2017 00:49:08 GMT
    2. version: changed from 4.10 to 4.12
    Comment 3
    1. Daniel Hellstrom, Wed, 30 Aug 2017 10:41:43 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Fixed by efcac228f4888c2cccfea0caf584705f0fddfc14

    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:53:06 GMT
    2. component: changed from bsps to arch/sparc
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2727 - FAT file systems use wrong semaphore for mutual exclusion

    Link https://devel.rtems.org/ticket/2727
    Id 2727
    Reporter Sebastian Huber
    Created 6 June 2016 09:06:04
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component fs/fat
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    cpukit/libfs/src/dosfs/msdos_initsupp.c-
    cpukit/libfs/src/dosfs/msdos_initsupp.c- sc = rtems_semaphore_create(3,
    cpukit/libfs/src/dosfs/msdos_initsupp.c- 1,
    cpukit/libfs/src/dosfs/msdos_initsupp.c: RTEMS_BINARY_SEMAPHORE | RTEMS_FIFO,
    cpukit/libfs/src/dosfs/msdos_initsupp.c- 0,
    cpukit/libfs/src/dosfs/msdos_initsupp.c- &fs_info->vol_sema);
    cpukit/libfs/src/dosfs/msdos_initsupp.c

    Should use a binary semaphore with inherit priority.

    Comment 1
    1. Sebastian Huber, Mon, 06 Jun 2016 11:16:31 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In a7f0096b730ebebb0b22b5eacb2ea20cd130344d/rtems:

    dosfs: Use proper semaphore attr for mutex Close #2727.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:50:58 GMT
    2. component: changed from fs to fs/fat
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2728 - Pipes use wrong semaphore for mutual exclusion

    Link https://devel.rtems.org/ticket/2728
    Id 2728
    Reporter Sebastian Huber
    Created 6 June 2016 09:07:13
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    cpukit/libfs/src/pipe/fifo.c-      sc = rtems_semaphore_create(
    cpukit/libfs/src/pipe/fifo.c- rtems_build_name('P', 'I', 'P', 'E'),
    cpukit/libfs/src/pipe/fifo.c- 1,
    cpukit/libfs/src/pipe/fifo.c: RTEMS_BINARY_SEMAPHORE | RTEMS_INHERIT_PRIORITY | RTEMS_PRIORITY,
    cpukit/libfs/src/pipe/fifo.c- RTEMS_NO_PRIORITY,
    cpukit/libfs/src/pipe/fifo.c- &pipe_semaphore
    cpukit/libfs/src/pipe/fifo.c- );

    Should use a binary semaphore with inherit priority instead.

    Comment 1
    1. Sebastian Huber, Mon, 06 Jun 2016 11:16:40 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In c75aa864cf614ec2cc82598eadef6067a7dbe3db/rtems:

    pipe: Use proper semaphore attr for mutex Close #2728.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2729 - TFTP client uses wrong semaphore for mutual exclusion

    Link https://devel.rtems.org/ticket/2729
    Id 2729
    Reporter Sebastian Huber
    Created 6 June 2016 09:55:17
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    cpukit/libnetworking/lib/tftpDriver.c-    rtems_build_name('T', 'F', 'T', 'P'),
    cpukit/libnetworking/lib/tftpDriver.c- 1,
    cpukit/libnetworking/lib/tftpDriver.c- RTEMS_FIFO |
    cpukit/libnetworking/lib/tftpDriver.c: RTEMS_BINARY_SEMAPHORE |
    cpukit/libnetworking/lib/tftpDriver.c- RTEMS_NO_INHERIT_PRIORITY |
    cpukit/libnetworking/lib/tftpDriver.c- RTEMS_NO_PRIORITY_CEILING |
    cpukit/libnetworking/lib/tftpDriver.c- RTEMS_LOCAL,

    Should use a binary semaphore with inherit priority.

    Comment 1
    1. Sebastian Huber, Mon, 06 Jun 2016 09:55:31 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Mon, 06 Jun 2016 11:16:50 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a2f91f6cb87a5c53d1bb6f3dcb4ad9153078918f/rtems:

    tftp: Use proper semaphore attr for mutex Close #2729.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2732 - Add clock_nanosleep()

    Link https://devel.rtems.org/ticket/2732
    Id 2732
    Reporter Gedare Bloom
    Created 9 June 2016 15:36:47
    Modified 9 November 2017 06:27:14
    Owner Gedare Bloom
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords posix
    Cc  
    Blocking  
    Blocked by  

    Description

    The clock_nanosleep function is provided to enable specifying the clock source (CLOCK_REALTIME or CLOCK_MONOTONIC) and to control whether or not to use an absolute or relative reference point via TIMER_ABSTIME flag.

    See also: ​http://pubs.opengroup.org/onlinepubs/009695399/functions/clock_nanosleep.html

    Comment 1
    1. Gedare Bloom, Mon, 25 Jul 2016 16:45:22 GMT

    In e0f17fcf6f06d3383cd389d809ee4e3d6e0fb14d/rtems:

    posix: fix clock_nanosleep and nanosleep clock use Sleeping with CLOCK_REALTIME should use the WATCHDOG_ABSOLUTE clock discipline for the threadq so that the timeout interval may change in case the clock source changes. Similarly, CLOCK_MONOTONIC uses the WATCHDOG_RELATIVE threadq that will only wakeup the thread after the requested count of ticks elapse. updates #2732
    Comment 2
    1. Gedare Bloom, Tue, 26 Jul 2016 18:17:57 GMT

    In 39d97ab78cfcc37eb8b1e7d9f9717f51b249155b/rtems:

    cpukit: refactor nanosleep and use 64-bit timeout for threadq Fixes a bug with elapsed time calculations misusing absolute time arguments in nanosleep_helper by passing the requested relative interval. Fixes a bug with truncation of absolute timeouts by passing the full 64-bit value to Thread_queue_Enqueue. Share yield logic between nanosleep and clock_nanosleep. updates #2732
    Comment 3
    1. Gedare Bloom, Fri, 29 Jul 2016 17:14:45 GMT

    In 842005e432136953d670e39cedc2d665ea949e7b/rtems:

    posix: nanosleep: optimize away a time conversion updates #2732
    Comment 4
    1. Gedare Bloom, Wed, 10 Aug 2016 16:10:21 GMT

    In 709594f0fb29d4f860b99cda264ea3e74c635a72/rtems:

    posix: nanosleep: adjust elapsed time calculation Use clock_gettime before and after sleep to calculate the time spent asleep, and the amount of time remaining. updates #2732
    Comment 5
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 6
    1. Gedare Bloom, Fri, 30 Jun 2017 13:27:37 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 7
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 8
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2734 - pthread_setschedprio() is missing

    Link https://devel.rtems.org/ticket/2734
    Id 2734
    Reporter Sebastian Huber
    Created 13 June 2016 06:01:06
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber <sebastian.huber@…>
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords POSIX-Compliance
    Cc  
    Blocking  
    Blocked by  

    Description

    See also

    ​http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_setschedprio.html

    and

    ​http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_08_04_01

    In particular the distinction to pthread_setschedparam() (SCHED_FIFO, item 7.).

    Prototype is defined in Newlib provide .

    Comment 1
    1. Sebastian Huber, Mon, 13 Jun 2016 13:38:29 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 0c34dbf341095f93a712bbe6d024c8c1d975b6f5/rtems:

    posix: Add pthread_setschedprio() Close #2734.
    Comment 2
    1. Joel Sherrill, Mon, 03 Apr 2017 23:28:20 GMT
    2. keywords: POSIX-Compliance added
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2735 - pthread_setschedparam() sets the priority not according to POSIX

    Link https://devel.rtems.org/ticket/2735
    Id 2735
    Reporter Sebastian Huber
    Created 13 June 2016 06:02:09
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    See also

    ​http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_08_04_01

    In particular the distinction to pthread_setschedprio() (SCHED_FIFO, item 7.).

    Comment 1
    1. Sebastian Huber, Mon, 13 Jun 2016 13:10:14 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    4. summary: changed from pthread_setschedparam() set the priority not according to POSIX to pthread_setschedparam() sets the priority not according to POSIX
    Comment 2
    1. Sebastian Huber, Mon, 13 Jun 2016 13:20:19 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In fc30ac5973aae2393fb318b56346368f5e9b4493/rtems:

    posix: Fix pthread_setschedparam() Close #2735.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2736 - pthread_getschedparam() returns wrong priority values

    Link https://devel.rtems.org/ticket/2736
    Id 2736
    Reporter Sebastian Huber
    Created 13 June 2016 06:03:46
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    See also

    ​http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_getschedparam.html

    "The priority value returned from pthread_getschedparam() shall be the value specified by the most recent pthread_setschedparam(), pthread_setschedprio(), or pthread_create() call affecting the target thread. It shall not reflect any temporary adjustments to its priority as a result of any priority inheritance or ceiling functions."

    Comment 1
    1. Sebastian Huber, Mon, 13 Jun 2016 12:59:41 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 23b1bb38b208a6638747bb49b8184a5571e8f5e7/rtems:

    posix: Fix pthread_getschedparam() Return the unmodified thread priority value according to POSIX. Close #2736.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2737 - Add CLOCK_DRIVER_USE_ONLY_BOOT_PROCESSOR

    Link https://devel.rtems.org/ticket/2737
    Id 2737
    Reporter Sebastian Huber
    Created 14 June 2016 09:19:33
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component bsps
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add CLOCK_DRIVER_USE_ONLY_BOOT_PROCESSOR clock driver option. If defined, then do the clock tick processing on the boot processor on behalf of all other processors. Currently, this is intended as a workaround for a Qemu shortcoming on ARM.

    Comment 1
    1. Sebastian Huber, Fri, 01 Jul 2016 10:02:34 GMT

    [b61d5cac7c5f1ba801a8d0f896313b2e5cd01111/rtems]

    Comment 2
    1. Sebastian Huber, Wed, 21 Dec 2016 10:09:53 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [e7f40f04d39d3d87d30b50a02bab90a72a9dae61/rtems-docs]

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2740 - Suboptimal type for Timestamp_Control

    Link https://devel.rtems.org/ticket/2740
    Id 2740
    Reporter Sebastian Huber
    Created 15 June 2016 08:53:55
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Currently we have

    typedef struct bintime Timestamp_Control; 

    this type offers more precision than needed. Maybe use sbintime_t (also known as int64_t) instead to simplify computations.

    Comment 1
    1. Sebastian Huber, Wed, 15 Feb 2017 14:25:52 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    4. milestone: changed from 4.12 to Indefinite
    Comment 2
    1. Sebastian Huber, Fri, 06 Oct 2017 12:59:46 GMT
    2. status: changed from assigned to accepted
    3. milestone: changed from Indefinite to 4.12.0
    Comment 3
    1. Sebastian Huber, Mon, 09 Oct 2017 12:15:53 GMT

    In c0623a99/rtems:

    score: Simplify _Timestamp_Add_to() Update #2740.
    Comment 4
    1. Sebastian Huber, Mon, 09 Oct 2017 12:16:07 GMT

    In 2256946/rtems:

    score: Use struct timespec for TOD Use the timestamps only for uptime based values. Use struct timespec for the absolute time values (TOD). Update #2740.
    Comment 5
    1. Sebastian Huber, Mon, 09 Oct 2017 12:16:23 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 65012bf/rtems:

    score: Change Timestamp_Control to sbintime_t The timestamp are based on the uptime. There is no need for a 64-bit seconds part. The signed 32-bit seconds part of the sbintime_t limits the uptime to roughly 68 years. Close #2740.
    Comment 6
    1. Sebastian Huber, Thu, 12 Oct 2017 05:05:47 GMT

    In ed9a6fd/rtems:

    posix: Use right time format in adjtime() Update #2740.
    Comment 7
    1. Sebastian Huber, Thu, 12 Oct 2017 05:27:11 GMT

    In 16db540a/rtems:

    Use right time format in _times() Update #2740. Close #3179.
    Comment 8
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2741 - New warning from printf plugin changes

    Link https://devel.rtems.org/ticket/2741
    Id 2741
    Reporter Joel Sherrill
    Created 16 June 2016 15:38:33
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component bsps
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    ../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc6xx/mmu/pte121.c: In function 'whatPrintf':
    ../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc6xx/mmu/pte121.c:189:46: warning: pointer type mismatch in conditional expression

    return _Thread_Executing ? (PrintF) printf : printk;

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Sebastian Huber, Thu, 08 Jun 2017 08:38:22 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [73f8d938474d04013d785f5918d75b9d82c80ca3/rtems]

    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:33:12 GMT
    2. component: changed from libcpu to bsps
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2742 - New warning in SHM driver

    Link https://devel.rtems.org/ticket/2742
    Id 2742
    Reporter Joel Sherrill
    Created 16 June 2016 16:31:15
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Not sure how to fix this one

    ../../../../../rtems/c/src/libchip/shmdr/init.c:241:29: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]

    MPCI_Shm_extensions.fatal = MPCI_Fatal;

    PowerPC/psim with multiprocessing enabled.

    Comment 1
    1. Joel Sherrill, Thu, 16 Jun 2016 17:09:52 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Fri, 17 Jun 2016 06:05:11 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 305231bd3c2cb78421cedb9d7093773359612445/rtems:

    bsps: Fix MPCI_Fatal() prototype Close #2742.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2745 - Use clock from pthread_condattr in pthread_cond_timedwait

    Link https://devel.rtems.org/ticket/2745
    Id 2745
    Reporter Gedare Bloom
    Created 23 June 2016 20:10:07
    Modified 9 November 2017 06:27:14
    Owner Gedare Bloom
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    For pthread_cond_timedwait, the condition variable shall have a clock attribute which specifies the clock that shall be used to measure the time specified by the abstime argument. RTEMS currently does not honor the clock attribute.

    See ​http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_cond_timedwait.html

    Comment 1
    1. Gedare Bloom, Thu, 23 Jun 2016 20:10:22 GMT
    2. owner: set to Gedare Bloom
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Gedare Bloom, Fri, 30 Jun 2017 13:24:31 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    fixed in b5bfaaf9c27996d672f7aad67fee24581ab2f218

    Comment 4
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2748 - Move RTEMS-specific socket wake-up to RTEMS-specific <rtems/rtems_bsdnet.h>

    Link https://devel.rtems.org/ticket/2748
    Id 2748
    Reporter Sebastian Huber
    Created 28 June 2016 05:56:41
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber <sebastian.huber@…>
    Type enhancement
    Component network/legacy
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The contains definitions for the RTEMS-specific socket wake-up support. Move this stuff to since this feature is not present in standard network stacks. Portable applications should not use it.

    Comment 1
    1. Chris Johns, Tue, 28 Jun 2016 05:57:45 GMT

    Will this break existing applications?

    Comment 2
    1. Sebastian Huber, Tue, 28 Jun 2016 06:07:06 GMT

    Yes, if they use the old network stack and include only .

    Comment 3
    1. Sebastian Huber, Tue, 28 Jun 2016 13:20:39 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In e79a0ca75fbc87c17e220f6a80a64bff3d10c9dd/rtems:

    libnetworking: Move RTEMS-specific socket wake-up Close #2748.
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2749 - rtems_task_set_scheduler() has insufficient parameters

    Link https://devel.rtems.org/ticket/2749
    Id 2749
    Reporter Sebastian Huber
    Created 30 June 2016 11:12:19
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component rtems
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Task priorities are only valid within a scheduler instance. The rtems_task_set_scheduler() directive moves a task from one scheduler instance to another using the current priority of the thread. However, the current task priority of the source scheduler instance is undefined in the target scheduler instance. Add a third parameter to specify the priority.

    /**
    * @brief Sets the scheduler instance of a task.
    *
    * Initially, the scheduler instance of a task is set to the scheduler instance
    * of the task that created it. This directive allows to move a task from its
    * current scheduler instance to another specified by the scheduler identifier.
    *
    * @param[in] task_id Identifier of the task. Use @ref RTEMS_SELF to select
    * the executing task.
    * @param[in] scheduler_id Identifier of the scheduler instance.
    * @param[in] priority The task priority with respect to the new scheduler
    * instance. The real and initial priority of the task is set to this value.
    * The initial priority is used by rtems_task_restart() for example.
    *
    * @retval RTEMS_SUCCESSFUL Successful operation.
    * @retval RTEMS_ILLEGAL_ON_REMOTE_OBJECT Directive is illegal on remote tasks.
    * @retval RTEMS_INVALID_ID Invalid task or scheduler identifier.
    * @retval RTEMS_INVALID_PRIORITY Invalid priority.
    * @retval RTEMS_RESOURCE_IN_USE The task owns resources which deny a scheduler
    * change.
    *
    * @see rtems_scheduler_ident().
    */
    rtems_status_code rtems_task_set_scheduler(
    rtems_id task_id,
    rtems_id scheduler_id,
    rtems_task_priority priority
    );
    Comment 1
    1. Sebastian Huber, Thu, 30 Jun 2016 11:35:31 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Fri, 01 Jul 2016 09:57:39 GMT
    2. description: modified (diff)
    Comment 3
    1. Sebastian Huber, Fri, 01 Jul 2016 09:58:55 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In c0bd0064ac41f0602c0abfe494dbe140d7c5282f/rtems:

    rtems: Fix rtems_task_set_scheduler() API Task priorities are only valid within a scheduler instance. The rtems_task_set_scheduler() directive moves a task from one scheduler instance to another using the current priority of the thread. However, the current task priority of the source scheduler instance is undefined in the target scheduler instance. Add a third parameter to specify the priority. Close #2749.
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Tue, 10 Oct 2017 06:24:23 GMT
    2. component: changed from SMP to rtems
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2750 - Compile Error When Multiprocessing Enabled

    Link https://devel.rtems.org/ticket/2750
    Id 2750
    Reporter Joel Sherrill
    Created 30 June 2016 14:00:49
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This should impact every BSP with multiprocessing enabled but I saw it on the sparc/leon3 and powerpc/psim

    ../../cpukit/../../../psim/lib/include/rtems/score/basedefs.h:229:5: error: static assertion failed: "Message_queue_MP_Packet"

    _Static_assert(cond, # msg)

    ../../../../../../rtems/c/src/../../cpukit/rtems/src/msgmp.c:28:1: note: in expansion of macro 'RTEMS_STATIC_ASSERT'

    RTEMS_STATIC_ASSERT(

    Comment 1
    1. Sebastian Huber, Fri, 01 Jul 2016 09:59:05 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 4cb13c399827a39a9108a631e6afddf6d96de60c/rtems:

    score: Fix MPCI message layout Restore the 32-bit priority field in MP_packet_Prefix. Bug introduced by 254dc82daf8cbd6922376fcbb81c31e21cbf4d16. Close #2750.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2751 - Thread dispatch via interrupt is broken at least on ARM and PowerPC

    Link https://devel.rtems.org/ticket/2751
    Id 2751
    Reporter Sebastian Huber
    Created 1 July 2016 07:42:38
    Modified 29 June 2018 09:58:41
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority high
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The ARM and PowerPC interrupt epilogues call _Thread_Dispatch() with interrupts disabled (counter example: SPARC).

    On SMP configurations, since inter-processor interrupts set the thread dispatch necessary indicator this prevents a thread dispatch notification in post-switch handlers (which all run with interrupts disabled).

    On all configurations, this is a serious issue for the interrupt latency.

    Comment 1
    1. Sebastian Huber, Fri, 01 Jul 2016 09:58:45 GMT

    In 8d5b03802e99e581c360e9a2cf67856596ec824c/rtems:

    score: Workaround for #2751 The ARM and PowerPC interrupt epilogues call _Thread_Dispatch() with interrupts disabled (counter example: SPARC). On SMP configurations, since inter-processor interrupts set the thread dispatch necessary indicator this prevents a thread dispatch notification in post-switch handlers (which all run with interrupts disabled). On all configurations, this is a serious issue for the interrupt latency. Update #2751
    Comment 2
    1. Sebastian Huber, Fri, 18 Nov 2016 06:59:42 GMT

    In d78d5294cd076b48160e12c2f52a940d783b4dac/rtems:

    score: Add and use _Thread_Dispatch_direct() This function is useful for operations which synchronously block, e.g. self restart, self deletion, yield, sleep. It helps to detect if these operations are called in the wrong context. Since the thread dispatch necessary indicator is not used, this is more robust in some SMP situations. Update #2751.
    Comment 3
    1. Sebastian Huber, Fri, 18 Nov 2016 07:02:28 GMT

    In 2072dd242f269ca7d3d14b8f4e2830f15e85e555/rtems:

    score: Add Per_CPU_Control::isr_dispatch_disable Update #2751.
    Comment 4
    1. Sebastian Huber, Fri, 18 Nov 2016 07:03:06 GMT

    In c11ac2d59dce04b189948dd851b1f1eb6f9a4a52/rtems:

    sparc: Use Per_CPU_Control::isr_dispatch_disable Update #2751.
    Comment 5
    1. Sebastian Huber, Fri, 18 Nov 2016 07:03:44 GMT

    In d59585db26ea30d23a0d112212cf4b42d01e73fc/rtems:

    arm: Use Per_CPU_Control::isr_dispatch_disable Update #2751.
    Comment 6
    1. Sebastian Huber, Fri, 18 Nov 2016 07:03:56 GMT

    In 7ce60b378dcf732e1467dcb7664a94824ac608c7/rtems:

    powerpc: Use Per_CPU_Control::isr_dispatch_disable Update #2751.
    Comment 7
    1. Sebastian Huber, Mon, 21 Nov 2016 12:16:16 GMT

    In 4e2bc0a308104d96b60d8af1a0c5bcff99fe1564/rtems:

    arm: Fix Thumb-1 targets We cannot use the MRS or MSR instructions in Thumb-1 mode. Stay in ARM mode for the Thumb-1 targets during interrupt low-level processing. Update #2751.
    Comment 8
    1. Sebastian Huber, Wed, 23 Nov 2016 11:53:10 GMT

    In 1d18a9027d04625306d08c4971a7735ce4b7e9f7/rtems:

    arm: Fix _ARMV4_Exception_interrupt Use the right register to determine if a thread dispatch is allowed and necessary. Update #2751.
    Comment 9
    1. Sebastian Huber, Thu, 24 Nov 2016 08:13:18 GMT

    In 4b5ff47d159872ef9e1096713fd68367f4640576/rtems:

    score: Fix interrupt profiling Callers of _Thread_Do_dispatch() must have a valid Per_CPU_Control::Stats::thread_dispatch_disabled_instant. Call _Profiling_Outer_most_interrupt_entry_and_exit() with the interrupt stack to not exceed Per_CPU_Control::Interrupt_frame. Update #2751.
    Comment 10
    1. Sebastian Huber, Fri, 02 Dec 2016 12:56:59 GMT

    In f65dcc712ab7ff1fb36da4254b4383f4fc5eb459/rtems:

    score: Fix ARM and PowerPC context initialization Update #2751.
    Comment 11
    1. Sebastian Huber, Fri, 23 Dec 2016 14:10:09 GMT
    2. priority: changed from normal to high
    Comment 12
    1. Sebastian Huber, Tue, 24 Jan 2017 08:45:03 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 436a4b384b70b4b050d5c5967c169a2b79f90042/rtems:

    smptests/smpsignal01: Check signal ISR level Close #2751.
    Comment 13
    1. Sebastian Huber, Tue, 28 Mar 2017 08:34:46 GMT

    In cd3d747/rtems:

    arm: Optimize context switch Set CPU_ENABLE_ROBUST_THREAD_DISPATCH to TRUE. In this case the interrupts are always enabled during a context switch even after interrupt processing (see #2751). Remove the CPSR from the context control since it contains only volatile bits. Close #2954.
    Comment 14
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 15
    1. Sebastian Huber, Tue, 23 May 2017 08:05:22 GMT

    In d5c8756/rtems:

    arm: Fix profiling support of Thumb-1 targets Update #2751.
    Comment 16
    1. Sebastian Huber, Tue, 10 Oct 2017 06:27:10 GMT
    2. component: changed from SMP to score
    Comment 17
    1. Sebastian Huber, Tue, 10 Oct 2017 06:29:01 GMT
    2. component: changed from score to cpukit
    Comment 18
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 19
    1. Sebastian Huber, Fri, 29 Jun 2018 09:58:41 GMT

    In 9704d86f/rtems:

    riscv: Enable interrupts during dispatch after ISR The code sequence is derived from the ARM code (see _ARMV4_Exception_interrupt). Update #2751. Update #3433.

    2752 - Relax execution enviroment for thread begin extensions

    Link https://devel.rtems.org/ticket/2752
    Id 2752
    Reporter Sebastian Huber
    Created 4 July 2016 11:58:12
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 4.10
    Milestone 5.1
    Priority high
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Currently, the thread begin extensions are invoked with thread dispatching disabled. There is an explanation for this in the code

     /*
    * Take care that 'begin' extensions get to complete before
    * 'switch' extensions can run. This means must keep dispatch
    * disabled until all 'begin' extensions complete.
    */
    _User_extensions_Thread_begin( executing );

    However, the switch extension is always invoked before the thread begin extension for all threads except the initialization thread. A thread dispatch disabled contexts drastically limits the work which can be carried out in the thread begin extensions. It is for example not possible to call malloc(), create POSIX keys or access C++ thread local storage.

    The thread begin extension should execute in a normal thread context. Thread begin extensions that are disturbed by a thread dispatch should deal with this locally.

    With the availability of C++ thread local storage in RTEMS being able to pre-initialize such objects in the thread begin extension would be quite handy.

    Comment 1
    1. Sebastian Huber, Mon, 25 Jul 2016 06:40:43 GMT

    In 0fd6f25507fbea5f4892b71b58837cdda17856b4/rtems:

    score: Relax thread begin extension environment Update #2752.
    Comment 2
    1. Sebastian Huber, Fri, 23 Dec 2016 14:10:09 GMT
    2. priority: changed from normal to high
    Comment 3
    1. Sebastian Huber, Fri, 27 Jan 2017 06:25:20 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [b1e3b75e907db0f448610f18c5e11dd1ee9448b2/rtems-docs]

    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2754 - no .strtab section

    Link https://devel.rtems.org/ticket/2754
    Id 2754
    Reporter Patrick Gauvin
    Created 11 July 2016 00:11:57
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity major
    Keywords  
    Cc Ryan Slabaugh
    Blocking  
    Blocked by  

    Description

    dlopen on the object generated by libfoo.cpp in the attached test case fails and results in the error no .strtab section. readelf shows that the section is present, though:

    readelf -S libfoo.o | grep strtab
    (standard input):97: [92] .shstrtab STRTAB 00000000 001fb0 00040c 00 0 0 1
    (standard input):99: [94] .strtab STRTAB 00000000 0018b0 00019e 00 0 0 1

    Steps to Reproduce (you may have to edit BSP_DIR in the Makefile):

    make clean all
    qemu-system-arm -m 256M -M xilinx-zynq-a9 -serial null -serial mon:stdio \
    -nographic -no-reboot -kernel libdl-strtab-test.exe

    Expected Output:

    TEST BEGIN
    dlopen: no .strtab section
    assertion "handle != NULL" failed: file "libdl-strtab-test.c", line 46, function: POSIX_Init

    Development Environment:

    • __RTEMS Version__: 4.11 (Branch "4.11", commit 3f72dda6ee518d3ea04341ad4df079ecb1895ef7) with the dlerror patches from #2747, and the attached ARM PREL31 support patch (I will be making a separate ticket for this with test code soon).
    • __System Type__: ARM Cortex-A9, xilinx_zynq_a9_qemu BSP
    • __GCC Version__:

    arm-rtems4.11-gcc (GCC) 4.9.3 20150626 (RTEMS 4.11, RSB 1675a733536d1aec2020011e5e522497a442561a (HEAD, origin/4.11, 4.11), Newlib 2.2.0.20150423)

    • __RTEMS Configure Options__:

    --target=arm-rtems4.11 --enable-rtemsbsp="xilinx_zynq_a9_qemu xilinx_zynq_zedboard xilinx_zynq_csp_cots xilinx_zynq_csp_hybrid" --enable-tests=samples --enable-posix --prefix=$HOME/development/rtems/4.11 --disable-networking

    Attachments:

    1 Patrick Gauvin, Mon, 11 Jul 2016 00:12:28 GMT
      attach: set to libdl-prel31-arm.patch
    2 Patrick Gauvin, Wed, 20 Jul 2016 20:17:07 GMT
      attach: set to libdl-strtab-test.tar.gz
     
    3 Patrick Gauvin, Wed, 20 Jul 2016 20:17:38 GMT
      attach: set to rtems-libdl-obj-cache-disable.patch
     
    Comment 1
    1. Patrick Gauvin, Wed, 20 Jul 2016 20:26:35 GMT

    I've narrowed down the problem to a corrupted section name for .strtab being retrieved by rtems_rtl_obj_cache_read in rtems_rtl_elf_parse_sections. The offset to the name in the file was correct, but garbage was returned. The attached patch effectively disables the caching functionality of rtems_rtl_obj_cache_read, allowing the test to load the object successfully and generate this output:

    TEST BEGIN
    dlopen:
    TEST END 
    Comment 2
    1. Chris Johns, Fri, 12 Aug 2016 09:31:12 GMT

    Is this to be fixed on the 4.11 branch as well?

    Comment 3
    1. Joel Sherrill, Fri, 12 Aug 2016 15:58:59 GMT

    Patrick should answer from their perspective. But I think it should.

    But from what I know of Patrick's application, we would strongly encourage them to move to the master to get greater stability on the SMP and maturity on rtems-libbsd.

    Comment 4
    1. Patrick Gauvin, Sat, 13 Aug 2016 18:07:54 GMT

    chrisj:

    Is this to be fixed on the 4.11 branch as well?

    It is desirable, especially if the patches for master don't apply cleanly to 4.11.

    joel.sherrill:

    Patrick should answer from their perspective. But I think it should.

    But from what I know of Patrick's application, we would strongly encourage them to move to the master to get greater stability on the SMP and maturity on rtems-libbsd.

    This project is likely locked to 4.11, but I will recommend it.

    Comment 5
    1. Chris Johns, Mon, 15 Aug 2016 08:09:16 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 35edf82463f33d30e6bbbbbbafe3aadd80acffbb/rtems:

    libdl: Fix cache corruption bugs. This patch fixes a number of bugs in the cache when requests are made to read close to the end of the file and the data is copied from the top of the cache buffer to the bottom of the buffer. This was compounded by attempting to read past the end of the file. Closes #2754.
    Comment 6
    1. Chris Johns, Mon, 27 Mar 2017 06:50:20 GMT
    2. milestone: set to 4.12.0
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2765 - Application level deadlocks may lead to SMP lock level deadlocks

    Link https://devel.rtems.org/ticket/2765
    Id 2765
    Reporter Sebastian Huber
    Created 25 July 2016 12:17:27
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Due to a missing deadlock detection application level deadlocks may lead to SMP lock level deadlocks.

    Comment 1
    1. Sebastian Huber, Mon, 25 Jul 2016 12:18:48 GMT

    In 57a00bc6afd25f5c41006b386627d087ff9d4c66/rtems:

    smptests/smpmutex02: New test Update #2765.
    Comment 2
    1. Sebastian Huber, Mon, 25 Jul 2016 12:20:41 GMT
    2. version: changed from 4.10 to 4.11
    Comment 3
    1. Sebastian Huber, Wed, 27 Jul 2016 08:56:15 GMT

    In f4d1f307926b6319e5d3b325dbe424901285dec1/rtems:

    score: Split _Thread_Change_priority() Update #2412. Update #2556. Update #2765.
    Comment 4
    1. Sebastian Huber, Wed, 27 Jul 2016 08:56:26 GMT

    In ac8402ddd6e4a8eb6defb98220d39d4c20a6f025/rtems:

    score: Simplify _Thread_queue_Boost_priority() Raise the priority under thread queue lock protection and omit the superfluous thread queue priority change, since the thread is extracted anyway. The unblock operation will pick up the new priority. Update #2412. Update #2556. Update #2765.
    Comment 5
    1. Sebastian Huber, Wed, 27 Jul 2016 08:56:36 GMT

    In 3a58dc863157bb21054a144c1a21b690544c0d23/rtems:

    score: Priority inherit thread queue operations Move the priority change due to priority interitance to the thread queue enqueue operation to simplify the locking on SMP configurations. Update #2412. Update #2556. Update #2765.
    Comment 6
    1. Sebastian Huber, Wed, 27 Jul 2016 08:56:46 GMT

    In 1fcac5adc5ed38fb88ce4c6d24b2ca2e27e3cd10/rtems:

    score: Turn thread lock into thread wait lock The _Thread_Lock_acquire() function had a potentially infinite run-time due to the lack of fairness at atomic operations level. Update #2412. Update #2556. Update #2765.
    Comment 7
    1. Sebastian Huber, Wed, 27 Jul 2016 08:56:57 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In d79df38c2bea50112214ade95776cb90d693e390/rtems:

    score: Add deadlock detection The mutex objects use the owner field of the thread queues for the mutex owner. Use this and add a deadlock detection to _Thread_queue_Enqueue_critical() for thread queues with an owner. Update #2412. Update #2556. Close #2765.
    Comment 8
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 9
    1. Sebastian Huber, Tue, 10 Oct 2017 06:27:10 GMT
    2. component: changed from SMP to score
    Comment 10
    1. Sebastian Huber, Tue, 10 Oct 2017 06:29:01 GMT
    2. component: changed from score to cpukit
    Comment 11
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2768 - untar does not keep permissions correctly.

    Link https://devel.rtems.org/ticket/2768
    Id 2768
    Reporter Chris Johns
    Created 1 August 2016 00:13:50
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    On disk I have 'x' with:

    $ ls -las x
    4 -rwxr-xr-x 1 chris caeng 48 Jul 14 11:46 x

    the tar file shows:

    $ tar tvf rootfs.tar
    -rwxr-xr-x 0 chris caeng 48 Jul 14 11:46 x

    and in the IMFS it shows:

    [/] # ls -las x
    0 -rw-r--r-- 1 root root 48 Jan 1 00:00 x

    The makes adding 'joel' scripts difficult.

    Comment 1
    1. Chris Johns, Tue, 09 Aug 2016 07:24:19 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In b0f08c83e23e69c7b19b04d38910f90b5f7af51b/rtems:

    libmisc/untar: Set the perms to the value in the tar file. This patch parses the mode field in the tar header and sets the directory or file to the mode value in the header. Closes #2768.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2769 - rtems-syms does not clean up temp files.

    Link https://devel.rtems.org/ticket/2769
    Id 2769
    Reporter Chris Johns
    Created 2 August 2016 00:36:47
    Modified 13 April 2018 00:30:33
    Owner Chris Johns
    Type defect
    Component unspecified
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I am seeing temps files such as:

    $ ls -las /tmp/rld-*
    0 -rw------- 1 chris wheel 0 Jul 27 18:16 /tmp/rld--04lbaa.rldxx
    0 -rw------- 1 chris wheel 0 Jul 27 18:42 /tmp/rld--0niaaa.rldxx
    0 -rw------- 1 chris wheel 0 Jul 27 18:39 /tmp/rld--0viaaa.rldxx
    0 -rw------- 1 chris wheel 0 Jul 27 18:38 /tmp/rld--1Hhaaa.rldxx
    88 -rw------- 1 chris wheel 87426 Jul 27 18:30 /tmp/rld--1ibaaa.c
    0 -rw------- 1 chris wheel 0 Jul 27 18:24 /tmp/rld--2EZaaa.rldxx
    0 -rw------- 1 chris wheel 0 Jul 29 17:11 /tmp/rld--2rwaaa.rldxx
    0 -rw------- 1 chris wheel 0 Jul 29 18:14 /tmp/rld--2sBaaa.rldxx
    88 -rw------- 1 chris wheel 88148 Jul 29 17:40 /tmp/rld--2umaaa.c
    88 -rw------- 1 chris wheel 87426 Jul 27 18:25 /tmp/rld--3baaaa.c
    88 -rw------- 1 chris wheel 87426 Jul 27 18:27 /tmp/rld--4Jaaaa.c
    0 -rw------- 1 chris wheel 0 Jul 27 18:52 /tmp/rld--4Wiaaa.rldxx
    0 -rw------- 1 chris wheel 0 Jul 27 18:38 /tmp/rld--4bfaaa.rldxx

    left in /tmp. They look like symbols and so I suspect rtems-syms when building the testsuite with 4.12 (master). This is on FreeBSD.

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 3
    1. Chris Johns, Thu, 12 Apr 2018 23:30:08 GMT

    In 2a61542/rtems:

    libdl: RAP format fixes. Do not error if a RAP section is not found. Free a symbol table via the RTL allocator interface. Add the symbols to the global symbol table. Update #2769
    Comment 4
    1. Chris Johns, Thu, 12 Apr 2018 23:30:27 GMT

    In 31cd205d/rtems:

    tools: Add a -N option to force a name on the array. This can be used to have a different file name for the same data name. Update #2769
    Comment 5
    1. Chris Johns, Thu, 12 Apr 2018 23:30:41 GMT

    In 86e79d7/rtems:

    testsuites/dl06: Add a test for RAP format. This test loads a RAP format file that contains calls that are not in the kernel and linked from libm. It uses and test rtems-ld. Update #2769
    Comment 6
    1. Chris Johns, Fri, 13 Apr 2018 00:30:33 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    I have add rtems-ld to the testsuite so it and rtems-syms are both run and I cannot see any temp files being left. I wonder if this happens when there is an error?

    I am going to close the ticket with invalid and it can be opened again if this appears again.


    2770 - Missing documentation for RTEMS_LINKER_ROSET_CONTENT and RTEMS_LINKER_RWSET_CONTENT

    Link https://devel.rtems.org/ticket/2770
    Id 2770
    Reporter Christian Mauderer
    Created 2 August 2016 06:33:35
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Currently the two macros

    RTEMS_LINKER_ROSET_CONTENT
    RTEMS_LINKER_RWSET_CONTENT

    are not documented. This should be added as soon as the doc repo is ready for it.

    The macros have been introduced in this commit:

    ​https://git.rtems.org/rtems/commit/?id=5fe6d07ad5690e3d9c6445ca3a465a700a5a5015

    Comment 1
    1. Sebastian Huber, Wed, 15 Feb 2017 14:08:13 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned

    [3b9b8a004c5e92f95007036cc7475125450014bb/rtems-docs]

    Comment 2
    1. Sebastian Huber, Wed, 15 Feb 2017 14:33:26 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2771 - Empty C++ file with just <rtems.h> does not compile with HEAD.

    Link https://devel.rtems.org/ticket/2771
    Id 2771
    Reporter Chris Johns
    Created 4 August 2016 00:20:12
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component score
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority highest
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I have an application that does not build.

    The following C++ file:

    $ cat t1.cpp
    #include

    does not compile with git head 5fe6d07ad5690e3d9c6445ca3a465a700a5a5015 on Zynq ARM. Build with:

    $ /opt/work/rtems/4.12/bin/arm-rtems4.12-g++ \
    -B/opt/work/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib \
    -B/opt/work/bsps/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib \
    -specs bsp_specs -qrtems \
    -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 \
    -g -O2 -DNDEBUG -std=c++11 \
    -Werror -Wall -Wextra \
    -o t1.o \
    -c t1.cpp

    Some (too much to post) of the output is:

    In file included from /opt/work/bsps/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/thread.h:36:0,
    from /opt/work/bsps/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/heap.h:22,
    from /opt/work/bsps/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/rtems/types.h:26,
    from /opt/work/bsps/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems.h:31,
    from t1.cpp:1:
    /opt/work/bsps/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/timestamp.h: In function 'void _Timestamp_Set(Timestamp_Control*, time_t, long int)':
    /opt/work/bsps/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/timestamp.h:78:33: error: 'timespec2bintime' was not declared in this scope
    timespec2bintime( &_ts, _time );
    ^
    /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/timestamp.h: In function 'void _Timestamp_Set_to_zero(Timestamp_Control*)':
    /opt/work/bsps/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/timestamp.h:94:8: error: invalid use of incomplete type 'Timestamp_Control {aka struct bintime}'
    _time->sec = 0;
    ^~
    In file included from /opt/work/rtems/4.12/arm-rtems4.12/include/sys/time.h:299:0,
    from /opt/work/bsps/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/timestamp.h:43,
    from /opt/work/bsps/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/thread.h:36,
    from /opt/work/bsps/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/heap.h:22,
    from /opt/work/bsps/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/rtems/types.h:26,
    from /opt/work/bsps/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems.h:31,
    from t1.cpp:1:
    /opt/work/rtems/4.12/arm-rtems4.12/include/machine/_time.h:40:15: note: forward declaration of 'Timestamp_Control {aka struct bintime}'
    extern struct bintime _Timecounter_Boottimebin;
    ^~~~~~~

    If '-std=c++11' is removed or replaced with '-std=gnu++11' the error becomes:

    arm-rtems4.12-g++: fatal error: /opt/work/bsps/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/bsp_specs: attempt to rename spec 'endfile' to already defined spec 'old_endfile' 
    Comment 1
    1. Chris Johns, Thu, 04 Aug 2016 00:22:19 GMT
    2. description: modified (diff)
    Comment 2
    1. Chris Johns, Thu, 04 Aug 2016 00:23:37 GMT
    2. summary: changed from Empty C++ file does not compile with HEAD. to Empty C++ file with just does not compile with HEAD.
    Comment 3
    1. Sebastian Huber, Thu, 04 Aug 2016 05:19:19 GMT

    I cannot reproduce this problem. The C++ tests build fine.

    Comment 4
    1. Chris Johns, Thu, 04 Aug 2016 05:33:46 GMT

    Replying to sebastian.huber:

    I cannot reproduce this problem.

    Is this your build or the RSB?

    The C++ tests build fine.

    Which tests?

    Comment 5
    1. Sebastian Huber, Thu, 04 Aug 2016 05:40:29 GMT

    Replying to chrisj:

    Replying to sebastian.huber:

    I cannot reproduce this problem.

    Is this your build or the RSB?

    arm-rtems4.12-g++ --version arm-rtems4.12-g++ (GCC) 6.1.1 20160609 (RTEMS 4.12, RSB c476de6150f39afdf142c6f4420c59ba2f1aa2fe, Newlib 2.4.0.20160527)

    The C++ tests build fine.

    Which tests?

    For example the iostream test (--enable-tests --enable-cxx).

    Comment 6
    1. Chris Johns, Thu, 04 Aug 2016 05:50:55 GMT

    I have:

    arm-rtems4.12-g++ (GCC) 6.1.1 20160609 (RTEMS 4.12, RSB cac72a2aea711f671816d7c41bb1cfe66d54ee37, Newlib 2.4.0.20160527)

    and the tests build OK as well. The problem still exists.

    Comment 7
    1. Sebastian Huber, Thu, 04 Aug 2016 05:54:46 GMT

    I guess it is a problem with your local BSP/RTEMS installation or command line. Do you have a double "-specs bsp_specs" for example? You must specify the specs exactly once on the command line.

    Comment 8
    1. Chris Johns, Thu, 04 Aug 2016 05:56:02 GMT

    The second issue with the bsp_specs was a command issue where is was not being show correctly on the terminal. The first issue exists. I will update a .i file.

    Comment 9
    1. Sebastian Huber, Thu, 04 Aug 2016 05:59:24 GMT

    The uses BSD extensions, e.g. struct bintime, thus it doesn't work with -std=c++11.

    The main problem is that includes way too many implementation details.

    Comment 10
    1. Chris Johns, Thu, 04 Aug 2016 06:00:11 GMT

    Ah ok this is the problem. Is this something that needs to be fixed?

    Comment 11
    1. Sebastian Huber, Thu, 04 Aug 2016 06:03:08 GMT

    Yes, but it has very low priority for me. Its probably something for the new-build-system era.

    Comment 12
    1. Chris Johns, Thu, 04 Aug 2016 06:04:59 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix
    Comment 13
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 14
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2775 - ARM CP15 arm_cp15_set_translation_table_entries fails if TTB in read-only memory

    Link https://devel.rtems.org/ticket/2775
    Id 2775
    Reporter Chris Johns
    Created 9 August 2016 03:32:58
    Modified 9 November 2017 06:27:14
    Owner Chris Johns <chrisj@…>
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords ARM
    Cc  
    Blocking  
    Blocked by  

    Description

    If the TTB is held in the text section and the section is set to read-only, and cached when booting no section change happen at run time because the table cannot be written too to change. The table cannot be changed unless the MMU is disabled.

    I suggest the MMU be disabled, the table updated and then the MMU enabled.

    Note, the issue only shows up on real hardware, qemu does not complain.

    Comment 1
    1. Pavel Pisa, Sun, 14 Aug 2016 21:51:15 GMT

    I think that disabling of MMU at runtime is highly problematic. You need to stop all parallel processes to ensure that all modifications held in cache are propagated to memory and then switch MMU off. If multiple CPUs are running (SMP) then there is almost no way hot to ensure fully synchronized case for at least some ARM architecture members. Coherency is maintained through MMU and guaranteed only for cache clean through VMA. The cache clean by level+set+way does not need to generate required snoop operations.

    On the other hand, ARM architecture is prepared and operations are optimized for runtime page tables updates and switching and there are defined operations sequences to ensure correct page tables changes propagations in ARM architecture manuals. So I vote for this direction.

    Comment 2
    1. Chris Johns, Sun, 14 Aug 2016 22:38:09 GMT

    I agree it is problematic for a running system. I had not seen the note in your git commit about adding the MMU tables section. I have a patch which add this to the default set. It removes the current issue we are facing.

    Comment 3
    1. Chris Johns, Sun, 14 Aug 2016 23:23:05 GMT
    2. owner: set to Chris Johns <chrisj@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 01aa1ba34a1696736ed5200ffa1d4be9963d99b3/rtems:

    libbsp/arm: Add the TTB table to the default MMU set up as read/write. This lets the table be changed at runtime for dynamic loading and debugger support. Closes #2775.
    Comment 4
    1. Sebastian Huber, Wed, 17 Aug 2016 07:34:22 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    This change breaks a lot of ARM BSPs since bsp_translation_table_end is not defined.

    Comment 5
    1. Chris Johns, Wed, 17 Aug 2016 07:41:49 GMT

    If you have a list I can add them to ​https://git.rtems.org/rtems-tools/tree/tester/rtems/rtems-bsps.ini and then they can be built.

    Thanks.

    Comment 6
    1. Sebastian Huber, Wed, 17 Aug 2016 08:18:38 GMT

    You can use "/path/to/rtems/configure --target=arm-rtems4.12 --enable-maintainer-mode --enable-tests=samples" to build all ARM BSPs.

    Comment 7
    1. Chris Johns, Tue, 23 Aug 2016 01:14:16 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    In 89a319a0f8bb9374e5a23358b266db3745268a3a/rtems:

    libbsp/arm: Fix ARM BSPs missing the bsp_translation_table_end symbol. Closes #2775.
    Comment 8
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 9
    1. Sebastian Huber, Tue, 10 Oct 2017 06:32:23 GMT
    2. component: changed from libcpu to arch/arm
    Comment 10
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2776 - SPI Framework

    Link https://devel.rtems.org/ticket/2776
    Id 2776
    Reporter Alexander Krutwig
    Created 9 August 2016 07:42:09
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords SPI, Framework
    Cc  
    Blocking  
    Blocked by  

    Description

    Development of a SPI framework which shall be used for further SPI bus and device drivers. The framework shall be developed using the i2c framework as a template. It shall export the Linux Userspace SPI API.

    Comment 1
    1. Alexander Krutwig, Fri, 16 Sep 2016 12:01:46 GMT

    In a42be52bbf2b3a549d4b9635a5a93215dacd0657/rtems:

    Add SPI bus framework User API is compatible to Linux userspace API. New test libtests/spi01. Update #2776.
    Comment 2
    1. Sebastian Huber, Fri, 16 Sep 2016 12:02:20 GMT

    Update of BSP manual is missing.

    Comment 3
    1. Sebastian Huber, Fri, 23 Dec 2016 13:41:47 GMT

    [0cb2748a11ecdbeb96a40a60a3039dad99da2937/rtems-docs]

    Comment 4
    1. Sebastian Huber, Fri, 23 Dec 2016 13:42:00 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 5
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2777 - Remove librtems++

    Link https://devel.rtems.org/ticket/2777
    Id 2777
    Reporter Chris Johns
    Created 10 August 2016 02:17:40
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This is old and there are better design patterns for threading and C++. We recommend you use the new C++ standards based support.

    Comment 1
    1. Chris Johns, Thu, 11 Aug 2016 07:26:43 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 03c1038edbe9b01a72d4775dcb6ffc1a03193a0c/rtems:

    librtems++: Remove from RTEMS. This is old and there are better design patterns for threading and C++. We recommend you use the new C++ standards based support. Closes #2777.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:35:44 GMT
    2. component: changed from misc to unspecified
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2784 - Add function to get the current priority of a task by scheduler instance

    Link https://devel.rtems.org/ticket/2784
    Id 2784
    Reporter Sebastian Huber
    Created 8 September 2016 12:44:55
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    /**
    * @brief Gets the current priority of the specified task with respect to the
    * specified scheduler instance.
    *
    * The current priority reflects temporary priority adjustments due to locking
    * protocols, the rate-monotonic objects on some schedulers and other
    * mechnisms.
    *
    * @param[in] task_id Identifier of the task. Use @ref RTEMS_SELF to select
    * the executing task.
    * @param[in] scheduler_id Identifier of the scheduler instance.
    * @param[out] priority Returns the current priority of the specified task with
    * respect to the specified scheduler instance.
    *
    * @retval RTEMS_SUCCESSFUL Successful operation.
    * @retval RTEMS_ILLEGAL_ON_REMOTE_OBJECT Directive is illegal on remote tasks.
    * @retval RTEMS_INVALID_ADDRESS The priority parameter is @c NULL.
    * @retval RTEMS_INVALID_ID Invalid task or scheduler identifier.
    * @retval RTEMS_NOT_DEFINED The task has no priority within the specified
    * scheduler instance.
    *
    * @see rtems_scheduler_ident().
    */
    rtems_status_code rtems_task_get_priority(
    rtems_id task_id,
    rtems_id scheduler_id,
    rtems_task_priority *priority
    );
    Comment 1
    1. Sebastian Huber, Wed, 21 Sep 2016 07:06:34 GMT

    In 8123cae864579219e5003a67b451ca4cc07d998b/rtems:

    rtems: Add rtems_task_get_priority() Update #2556. Update #2784.
    Comment 2
    1. Sebastian Huber, Mon, 19 Dec 2016 13:34:32 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [3be5dd685cd8baa634b9de068b778d5ecd89ae0e/rtems-docs]

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:24:23 GMT
    2. component: changed from SMP to rtems
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2788 - RTEMS I2C API only defines Standard-mode (Sm) speed as a default.

    Link https://devel.rtems.org/ticket/2788
    Id 2788
    Reporter Chris Johns
    Created 21 September 2016 00:54:54
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type enhancement
    Component score
    Status closed
    Resolution wontfix
    Version 4.10
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The RTEMS I2C API as defined in cpukit/dev/include/dev/i2c/i2c.h only defines the bus speed as Standard-mode (Sm) as defined by the I2C standard. This is set as I2C_BUS_CLOCK_DEFAULT. The default speed is defined by the hardware, ie the devices connected, and not this API.

    The API should define the speeds as defined in the I2C standard and there should be no default. Drivers like the Cadence driver for the Zynq should be modified to require the bus speed be provided and all future drivers need to provide the speed.

    Comment 1
    1. Sebastian Huber, Wed, 21 Sep 2016 08:19:21 GMT

    The cpukit/dev/include/dev/i2c/i2c.h is an I2C bus implementation header file not a part of the user API ( and . A driver must have an initial speed. The I2C_BUS_CLOCK_DEFAULT is the recommended initial speed.

    Comment 2
    1. Chris Johns, Wed, 21 Sep 2016 08:21:58 GMT

    A driver's initial speed needs to match the hardware. There is nothing that can be recommended. It requires analysis and a real value.

    Comment 3
    1. Sebastian Huber, Wed, 21 Sep 2016 08:28:57 GMT

    Ok, the set clock IO control is not part of the Linux user-space API. You can set it via the RTEMS specific I2C_BUS_SET_CLOCK IO control.

    It is up to the application/board initialization code to set the right speed for a particular I2C bus. The generic I2C bus driver cannot and should not know this. They have to choose an arbitrary initial value.

    Comment 4
    1. Chris Johns, Wed, 21 Sep 2016 22:38:07 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    Replying to sebastian.huber:

    Ok, the set clock IO control is not part of the Linux user-space API. You can set it via the RTEMS specific I2C_BUS_SET_CLOCK IO control.

    I did not pick up this interface to control the clock speed.

    This approach fits with the Xilinx AXI I2C controller where the bus speed is best handled by the IP integrator placing the IP into the FPGA. There is no point having software control the clock speed, the FPGA needs to do this. In this case setting the clock speed will fail, which is the default.

    Thanks.

    Comment 5
    1. Sebastian Huber, Tue, 27 Sep 2016 05:36:27 GMT

    There is an I2C bus driver handler for the clock setting. You can return an error code, if the user wants an unavailable clock frequency:

     /**
       * @brief Sets the bus clock.
       *
       * @param[in] bus The bus control.
       * @param[in] clock The desired bus clock in Hz.
       *
       * @retval 0 Successful operation.
       * @retval negative Negative error number in case of an error.
       */
      int (*set_clock)(i2c_bus *bus, unsigned long clock); 
    Comment 6
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2790 - Linker sets broken with GCC 7

    Link https://devel.rtems.org/ticket/2790
    Id 2790
    Reporter Sebastian Huber
    Created 23 September 2016 05:41:32
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    See also:

    ​https://gcc.gnu.org/ml/gcc/2016-09/msg00114.html

    The

    #define MAKEGCCNOTKNOWTHEADDRESS(ptr) asm("":"+r"(ptr))

    is probably the best option. It works probably also with link-time optimization.

    Comment 1
    1. Sebastian Huber, Wed, 12 Oct 2016 09:13:53 GMT

    In be573185e6d6ddafdd3612c7c2db04aa0f65a330/rtems:

    score: More robust linker sets Update #2408. Update #2790.
    Comment 2
    1. Sebastian Huber, Thu, 13 Oct 2016 05:15:45 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In f5eff007a44ad20c2a420b66903508e9d6c3b066/rtems:

    score: Rename RTEMS_OBFUSCATE_POINTER() The inline asm construct works for everything which fits into a register. Close #2790.
    Comment 3
    1. Sebastian Huber, Tue, 06 Dec 2016 11:03:23 GMT

    In 4b579c5f5170e1fb6a0573729444c289643b7d84/rtems:

    score: Simplify linker set API Resurrect RTEMS_LINKER_SET_BEGIN() and RTEMS_LINKER_SET_END(). Add new macros RTEMS_LINKER_SET_ITEM_COUNT(), RTEMS_LINKER_SET_IS_EMPTY(), and RTEMS_LINKER_SET_FOREACH(). Remove confusing RTEMS_LINKER_SET_ASSIGN_BEGIN() and RTEMS_LINKER_SET_ASSIGN_END(). Fix RTEMS_LINKER_SET_SIZE() to return the size in characters as specified by the documentation. Update #2408. Update #2790.
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2795 - Overrun Handling for general real-time models

    Link https://devel.rtems.org/ticket/2795
    Id 2795
    Reporter Kuan
    Created 8 October 2016 11:49:04
    Modified 9 November 2017 06:27:14
    Owner Gedare Bloom <gedare@…>
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords Overrun, RMS, SP, Scheduler, Periodicity
    Cc Gedare Bloom Joel Sherrill Sebastian Huber
    Blocking  
    Blocked by  

    Description

    In the current implementation, if a task period is time out, the next call of rtems_rate_monotonic_period() will only release one following job and manipulate the task period with the calling moment + the next length of period. With the assumption that implicit/constraint deadline and hard real-time model, the above mechanism is okay.

    However, it may not be applicable for general task models, e.g., soft real-time task, arbitrary deadline, mixed-criticality system [1-4]. It is usually assumed that multiple task jobs of a task are executed in a first-come-first-serve manner. Thus, it is sufficient to release the second task job at the moment the first task job finishes according to a strictly periodic release pattern. The current design in fact shifts the release pattern of periodic/sporadic tasks. Since there maybe more than one postponed jobs due to the preemption, these postponed jobs that should be released are never released to the system.

    Although there is no standard requirement in reality for deadline misses, with this enhancement, the postponed jobs will be released with the correct number without periodic release shifting. This way of handling is already widely considered in academia from 90s [2] until now [3] or even on multicores as well [4].

    I refine the following four files and handle this requirement individually. The overhead seems to me negligible.
    cpukit/rtems/include/rtems/rtems/ratemon.h
    cpukit/rtems/include/rtems/rtems/ratemonimpl.h
    cpukit/rtems/src/ratemontimeout.c
    cpukit/rtems/src/ratemonperiod.c
    I have tested the enhancement on Qemu and Raspberry Pi Model B+ with corresponding BSPs.

    I believe this patch as a basis is required for further use for more general real-time task models.
    This enhancement only affect those timeout cases without changing any behaviour in normal cases.
    This enhancement is accepted in workshop mixed-criticality (WMC 2016) along with RTSS'16 this year [5].

    To demonstrate the differences, a heuristic example is prepared in testsuites/sptests/sprmsched01 to show the benefit of the enhancement:
    Given two tasks with implicit deadline that task deadline is equal to its period.
    Task 1 period is 10000 ticks, whereas task 2 is 2000 ticks.
    Task 1 has the execution time 6000 ticks, and task 2 has 1000 ticks.
    Assume Task 1 has a higher priority than task 2. Task 1 only executes 2 times.
    In the expected result, we can observe that the postponed jobs are continuously released till there is no postponed job left, and the task period will still keep as it is.
    (Job 3-7 in task 2 are postponed jobs)

    [1] Buttazzo et al., Soft Real-Time Systems: Predictability vs. Efficiency, Springer 2005, ​​http://www.springer.com/gp/book/9780387237015 [2] Lehoczky et al., Fixed priority scheduling of periodic task sets with arbitrary deadlines, RTSS 1990, ​​http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=128748 [3] Georg von der Brüggen et al., Systems with Dynamic Real-Time Guarantees in Uncertain and Faulty Execution Environments, RTSS'16, accepted. [4] Huang et al., Response time bounds for sporadic arbitrary-deadline tasks under global fixed-priority scheduling on multiprocessors, RTNS 2015, ​​http://dl.acm.org/citation.cfm?doid=2597457.2597459 [5] Chen et al., Overrun Handling for Mixed-Criticality Support in RTEMS, WMC 2016, accepted.

    Attachments:

    1 Kuan, Sat, 08 Oct 2016 11:56:50 GMT
      attach: set to patch.diff
     
    2 Kuan-Hsun Chen, Tue, 18 Oct 2016 12:27:56 GMT
      attach: set to patch.2.diff
     
    Comment 1
    1. Kuan, Sat, 08 Oct 2016 12:03:59 GMT
    2. keywords: Overrun RMS SP Scheduler Periodicity added; overrun removed
    Comment 2
    1. Sebastian Huber, Wed, 12 Oct 2016 06:01:30 GMT

    In RTEMS the behaviour of the rate-monotonic periods depends on the scheduler. We have a fix-priority scheduler (default scheduler) and a job-level fixed-priority scheduler (EDF).

    In your test case you have 6000/10000 + 1000/2000 = 110% processor utilization, so your task set is not schedulable.

    In case of the default scheduler, the priority assignment is not according to the rules:

    ​https://docs.rtems.org/doc-current/share/rtems/html/c_user/Rate-Monotonic-Manager-Rate-Monotonic-Scheduling-Algorithm.html#Rate-Monotonic-Manager-Rate-Monotonic-Scheduling-Algorithm

    Task 2 has a shorter period compared to task 1, so it must have a higher priority.

    What changes your patch? You automatically restart the watchdog in case of a timeout and count the number of timeouts?

    Comment 3
    1. Kuan-Hsun Chen, Wed, 12 Oct 2016 08:04:20 GMT

    Yes, as the utilization is over 100%, my test case has deadline misses definitely. However, the test case is designed on purpose to present what is the proper overrun handling within 30000 ticks. (Otherwise, domino effect will hide the enhancement in the worst case.) Please note that, __Task 1 only executes 2 times__ in my test case. Let's only focus on the periodic behavior of task 2.

    Please refer to my paper [5]: ​http://ls12-www.cs.tu-dortmund.de/daes/media/documents/publications/downloads/2016-wmc.pdf In the following examples, the time unit is 1000 ticks. (1 = 1000 ticks)

    With the original design of overrun handing, there is only one postponed job and the release pattern is not periodic. As shown in Fig.2 (a) of [5], the arrival pattern from 16 is changed due to the lateness of the red job, by which the orange job and the following jobs are all released earlier.

    With this enhancement, the behaviour of task 2 with the enhancement is shown in Fig. 2 (b) of [5]. The postponed jobs due to the execution of task 1 are marked red. The jobs postponed due to the execution of previous jobs of task 2 are marked orange. The yellow job is postponed due to the orange job in the same period but can still finish its execution on time.

    In fact the example can be __schedule__ if the system has dynamic real-time guarantees [3] for mixed-criticality system. Suppose that task 1 requires a full timing guarantee with the abnormal execution time C_{1,A} = 6, and the normal execution time C_{1,N} = 1. Task 2 is a timing tolerable task with C_{2,A} = C_{2,N} = 1 as shown in Fig. 2 (c) of [5]. The second job of task 1 needs 6 time units for its execution time due to fault detection and recovery. We can see that after all the postponed jobs of task 2 are finished at 24, the release of task 2 turns back according to the original periodic pattern again. Since this example is a bit complicated for normal users, I didn't implement it in the example case.

    In my patch. I automatically __restart the watchdog__ in case of a timeout and __keep updating the number of postponed jobs__ (increase). If the number of postponed jobs is not 0, the default scheduler will decrease the number of postponed jobs and release the postponed jobs accordingly. Please note that, __the deadline of watchdog is not updated by the job releasing unless the targeted task has no more postponed jobs.__

    We all know that the schedulbility researches always talking about WCET and the worst case rarely happens in reality. However the overrun handling is still useful to isolate the effect of the abrupt overrun without disturbing the other normal tasks.

    Comment 4
    1. Sebastian Huber, Wed, 12 Oct 2016 08:12:43 GMT

    Ok, I will have a closer look at your paper and the patch. However, I am on a business trip next week, so this will take at least two weeks.

    Your patch changes the existing behaviour. We must decide if this is acceptable or if we need a new option, e.g. explicitly enable the watchdog restart plus counter.

    Comment 5
    1. Kuan-Hsun Chen, Wed, 12 Oct 2016 08:25:49 GMT

    Replying to sebastian.huber:

    Ok, I will have a closer look at your paper and the patch. However, I am on a business trip next week, so this will take at least two weeks.

    Thanks a lot.

    Your patch changes the existing behaviour. We must decide if this is acceptable or if we need a new option, e.g. explicitly enable the watchdog restart plus counter.

    Yes, I know. We have discussed this in user mailing list before. Please let me know if there is anything I can do.

    Comment 6
    1. Gedare Bloom, Fri, 13 Jan 2017 21:09:49 GMT
    2. owner: set to Gedare Bloom <gedare@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In cb2cbecefdc124b010aa9d8714856332e3e3a759/rtems:

    classic: adjust names of RM postponed job functions closes #2795
    Comment 7
    1. Sebastian Huber, Mon, 23 Jan 2017 09:11:05 GMT

    Several tests fail now:

    WARNING - log/sp20 did not appear to complete execution WARNING - log/sp60 did not appear to complete execution WARNING - log/sp69 did not appear to complete execution WARNING - log/spcbssched03 did not appear to complete execution WARNING - log/spedfsched02 did not appear to complete execution WARNING - log/spedfsched04 did not appear to complete execution WARNING - log/spintrcritical08 did not appear to complete execution WARNING - log/spratemon_err01 did not appear to complete execution WARNING - log/sprmsched01 did not appear to complete execution

    Comment 8
    1. Sebastian Huber, Tue, 24 Jan 2017 12:42:27 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted
    4. severity: changed from critical to blocker
    5. milestone: changed from 4.11.1 to 4.12
    Comment 9
    1. Sebastian Huber, Tue, 24 Jan 2017 12:43:11 GMT

    There is a possible deadlock at SMP lock level:

    ​https://lists.rtems.org/pipermail/devel/2017-January/016754.html

    Comment 10
    1. Sebastian Huber, Tue, 24 Jan 2017 13:45:15 GMT

    In 1240aade5a35c4e8c43d5409e2329eeb6a173299/rtems:

    rtems: Fix _Rate_monotonic_Renew_deadline() Make _Rate_monotonic_Renew_deadline() static and use proper locking in SMP configurations. Update #2795.
    Comment 11
    1. Sebastian Huber, Tue, 24 Jan 2017 14:04:57 GMT

    In 625bd6aca47268bc21cfa38662ebc17413475e82/rtems:

    rtems: Fix _Rate_monotonic_Release_postponed_job() Use proper locking in SMP configurations. Update #2795.
    Comment 12
    1. Sebastian Huber, Tue, 24 Jan 2017 14:05:50 GMT

    In b8d6eb719ad016b8e0a7752619a5004960b9711d/rtems:

    rtems: rtems_rate_monotonic_postponed_job_count() Use proper locking in SMP configurations. Update #2795.
    Comment 13
    1. Sebastian Huber, Tue, 24 Jan 2017 14:37:26 GMT

    In 29e08d41f42d68fdafba982061ea7a3d57f75731/rtems:

    sptests/sprmsched01: Merge and fix Merge into one file and fix obvious problems (e.g. out of bounds array access). Update #2795.
    Comment 14
    1. Sebastian Huber, Tue, 24 Jan 2017 14:40:46 GMT

    The output of sprmsched01 depends on the target timing:

    *** BEGIN OF TEST SPRMSCHED 1 ***
    Ticks per second in your system: 1000
    Task 0 starts at tick 10.
                                            Job 1 Task 0 ends at tick 6141.
    Job 1 Task 1 starts at tick 6144.
                                            Job 1 Task 1 ends at tick 7169.
    Job 2 Task 1 starts at tick 8144.
                                            Job 2 Task 1 ends at tick 9168.
    Task 0 starts at tick 10009.
                                            Job 2 Task 0 ends at tick 16140.
    Job 3 Task 1 starts at tick 16145.
                                            Job 3 Task 1 ends at tick 17169.
    RTEMS_TIMEOUT
    Job 4 Task 1 starts at tick 17172.
                                            Job 4 Task 1 ends at tick 18196.
    Job 5 Task 1 starts at tick 18199.
                                            Job 5 Task 1 ends at tick 19223.
    Job 6 Task 1 starts at tick 19226.
                                            Job 6 Task 1 ends at tick 20250.
    Job 7 Task 1 starts at tick 20253.
                                            Job 7 Task 1 ends at tick 21277.
    Job 8 Task 1 starts at tick 21280.
                                            Job 8 Task 1 ends at tick 22304.
    Job 9 Task 1 starts at tick 22307.
                                            Job 9 Task 1 ends at tick 23331.
    RTEMS_SUCCESSFUL
    Job 10 Task 1 starts at tick 24145.
                                            Job 10 Task 1 ends at tick 25169.
    Job 11 Task 1 starts at tick 26144.
                                            Job 11 Task 1 ends at tick 27168.
    Job 12 Task 1 starts at tick 28144.
                                            Job 12 Task 1 ends at tick 29168.
    *** END OF TEST SPRMSCHED 1 *** 

    Its not clear if the test objectives are checked. Why is rtems_rate_monotonic_postponed_jobs_count() not used at all?

    Comment 15
    1. Kuan-Hsun Chen, Tue, 24 Jan 2017 14:46:59 GMT

    Replying to sebastian.huber:

    The output of sprmsched01 depends on the target timing:

    *** BEGIN OF TEST SPRMSCHED 1 ***
    Ticks per second in your system: 1000
    Task 0 starts at tick 10.
                                            Job 1 Task 0 ends at tick 6141.
    Job 1 Task 1 starts at tick 6144.
                                            Job 1 Task 1 ends at tick 7169.
    Job 2 Task 1 starts at tick 8144.
                                            Job 2 Task 1 ends at tick 9168.
    Task 0 starts at tick 10009.
                                            Job 2 Task 0 ends at tick 16140.
    Job 3 Task 1 starts at tick 16145.
                                            Job 3 Task 1 ends at tick 17169.
    RTEMS_TIMEOUT
    Job 4 Task 1 starts at tick 17172.
                                            Job 4 Task 1 ends at tick 18196.
    Job 5 Task 1 starts at tick 18199.
                                            Job 5 Task 1 ends at tick 19223.
    Job 6 Task 1 starts at tick 19226.
                                            Job 6 Task 1 ends at tick 20250.
    Job 7 Task 1 starts at tick 20253.
                                            Job 7 Task 1 ends at tick 21277.
    Job 8 Task 1 starts at tick 21280.
                                            Job 8 Task 1 ends at tick 22304.
    Job 9 Task 1 starts at tick 22307.
                                            Job 9 Task 1 ends at tick 23331.
    RTEMS_SUCCESSFUL
    Job 10 Task 1 starts at tick 24145.
                                            Job 10 Task 1 ends at tick 25169.
    Job 11 Task 1 starts at tick 26144.
                                            Job 11 Task 1 ends at tick 27168.
    Job 12 Task 1 starts at tick 28144.
                                            Job 12 Task 1 ends at tick 29168.
    *** END OF TEST SPRMSCHED 1 *** 

    Its not clear if the test objectives are checked. Why is rtems_rate_monotonic_postponed_jobs_count() not used at all?

    That function I prepared is for the requirement from the application layer. It will not be used directly within the overrun handling. Since I only focused on the timing behaviors before, so I prepared this test without testing that.

    Now I can add in the test and print out the number of postponed jobs.

    Comment 16
    1. Sebastian Huber, Tue, 24 Jan 2017 14:53:07 GMT

    The rtems_rate_monotonic_postponed_jobs_count() is not tested at all, see #2885.

    There is a potential integer overflow in _Rate_monotonic_Renew_deadline(). It should be documented what happens in this case.

    Comment 17
    1. Kuan-Hsun Chen, Tue, 24 Jan 2017 15:07:46 GMT

    How about the potential overflow for uint32_t variables "missed_count" and "count" in rtems_rate_monotonic_period_statistics? I didn't find related means in the current version. stats->missed_count++ in cpukit/rtems/src/ratemonperiod.c could also incur this problem right?

    The trivial solution is to add assertion to avoid this situation or shut down the system...

    Comment 18
    1. Sebastian Huber, Wed, 25 Jan 2017 06:33:58 GMT

    The missed count is just a statistic.

    For the integer overflow in

    static void _Rate_monotonic_Renew_deadline(
      Rate_monotonic_Control *the_period,
      Thread_Control         *owner,
      ISR_lock_Context       *lock_context
    )
    {
      uint64_t deadline;
      ++the_period->postponed_jobs;
      the_period->state = RATE_MONOTONIC_EXPIRED;
      deadline = _Watchdog_Per_CPU_insert_relative(
        &the_period->Timer,
        _Per_CPU_Get(),
        the_period->next_length
      );
      the_period->latest_deadline = deadline;
      _Rate_monotonic_Release( the_period, lock_context );
    } 

    we have some options.

    Ignore it, then postponed jobs count will be zero again. Issue a new fatal error. Saturate, e.g. stay at 0xffffffff.

    I am in favour of 3. It should be documented in any way.

    Comment 19
    1. Sebastian Huber, Wed, 25 Jan 2017 07:33:32 GMT

    The references mentioned in the ticket should be added to the documentation:

    ​https://git.rtems.org/rtems-docs/tree/common/refs.bib

    They should show up in the documentation somewhere:

    ​https://git.rtems.org/rtems-docs/tree/c-user/rate_monotonic_manager.rst

    The "Further Reading" should be changed to references.

    Comment 20
    1. Kuan-Hsun Chen, Wed, 25 Jan 2017 08:30:40 GMT

    I will set a precondition for saturating before ++the_period->postponed_jobs, and update the documentation.

    Comment 21
    1. Sebastian Huber, Wed, 25 Jan 2017 10:17:14 GMT

    In 23a11b68cdba71ae34fe1b2271606b167eb6a5b4/rtems:

    sptests/spedfsched04: Merge and fix Merge into one file and fix obvious problems (e.g. out of bounds array access). Update #2795.
    Comment 22
    1. Kuan-Hsun Chen, Thu, 26 Jan 2017 09:01:03 GMT

    In d7feb8677d48162bf8db34406c232e0179d43dc6/rtems:

    Remove rtems_rate_monotonic_postponed_job_count() Add a variable named "count" in rtems_rate_monotonic_period_status structure. Revise rtems_rate_monotonic_get_status() for the postponed job count. sptests/sp69: Add in the verification of the postponed job count for rtems_rate_monotonic_get_status(). Update #2795.
    Comment 23
    1. Sebastian Huber, Mon, 30 Jan 2017 07:12:14 GMT

    [c660173fa4aed11c12403e359248eee59c5b5a01/rtems-docs]

    Comment 24
    1. Sebastian Huber, Mon, 30 Jan 2017 07:15:11 GMT

    The tests sprmsched01 and spedfsched01 should use rtems_rate_monotonic_get_status() to check that the postponed_jobs_count has the expected value.

    Ideally, the test output should be independent of the target timing and console driver.

    Comment 25
    1. Kuan-Hsun Chen, Mon, 30 Jan 2017 10:03:29 GMT

    Replying to sebastian.huber:

    The tests sprmsched01 and spedfsched01 should use rtems_rate_monotonic_get_status() to check that the postponed_jobs_count has the expected value.

    Ideally, the test output should be independent of the target timing and console driver.

    Okay, I will fix them. Before the examples were prepared for showing the diagrams on the paper. I will use only assertions and rtems_rate_monotonic_get_status() to check the expected value of postponed jobs instead of showing the whole simulated executions.

    Comment 26
    1. Kuan-Hsun Chen, Tue, 31 Jan 2017 06:20:41 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    In 166a9f67cde9085a74d6d5d962160b3c92b3e3d7/rtems:

    sprmsched01/spedfsched04: Revise Instead of using the target time and console driver, both tests now use assertions and rtems_rate_monotonic_get_status() to verify the count of postponed jobs. The setting of spedfsched04 is slightly changed. Close #2795.
    Comment 27
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 28
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2797 - Add ability to add/remove processors to/from a scheduler instance

    Link https://devel.rtems.org/ticket/2797
    Id 2797
    Reporter Sebastian Huber
    Created 31 October 2016 11:32:29
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The scheduler configuration is done at link-time. In order to support run-time re-configuration add functions to dd/remove processors to/from a scheduler instance.

    /**
    * @brief Adds a processor the set of processors owned by the scheduler.
    *
    * Must be called from task context. This operation obtains and releases the
    * objects allocator lock.
    *
    * @param[in] scheduler_id Identifier of the scheduler.
    * @param[in] cpu_index Index of the processor to add.
    *
    * @retval RTEMS_SUCCESSFUL Successful operation.
    * @retval RTEMS_INVALID_ID Invalid scheduler identifier.
    * @retval RTEMS_NOT_CONFIGURED The processor is not configured to be used by
    * the application.
    * @retval RTEMS_INCORRECT_STATE The processor is configured to be used by
    * the application, however, it is not available.
    */
    rtems_status_code rtems_scheduler_add_processor(
    rtems_id scheduler_id,
    uint32_t cpu_index
    );
    /**
    * @brief Removes a processor from set of processors owned by the scheduler.
    *
    * Must be called from task context. This operation obtains and releases the
    * objects allocator lock. Removing a processor from a scheduler is a complex
    * operation that involves all tasks in the system.
    *
    * @param[in] scheduler_id Identifier of the scheduler.
    * @param[in] cpu_index Index of the processor to add.
    *
    * @retval RTEMS_SUCCESSFUL Successful operation.
    * @retval RTEMS_INVALID_ID Invalid scheduler identifier.
    * @retval RTEMS_INVALID_NUMBER The processor is not owned by the scheduler.
    * @retval RTEMS_RESOURCE_IN_USE The set of processors owned by the scheduler
    * would be empty after the processor removal and there exists a non-idle
    * task that uses this scheduler as its home scheduler.
    */
    rtems_status_code rtems_scheduler_remove_processor(
    rtems_id scheduler_id,
    uint32_t cpu_index
    );
    Comment 1
    1. Sebastian Huber, Thu, 10 Nov 2016 08:59:39 GMT

    In 2612a0bf5b9f0105315d62cbacfa9d29a5caa4b5/rtems:

    score: Simplify _Scheduler_Get_by_id() Avoid dead code in non-SMP configurations. Return scheduler identifier independent of the current processor count of the scheduler via rtems_scheduler_ident(), since this value may change during run-time. Check the processor count in _Scheduler_Set() under scheduler lock protection. Update #2797.
    Comment 2
    1. Sebastian Huber, Thu, 10 Nov 2016 08:59:58 GMT

    In 1c46b80329d5d099022d8c7e0a8c593845120729/rtems:

    score: Add scheduler to per-CPU information This makes it possible to adjust the scheduler of a processor at run-time. Update #2797.
    Comment 3
    1. Sebastian Huber, Thu, 10 Nov 2016 09:00:18 GMT

    In e6107854b2511decef8c209cde14c4826a33ff01/rtems:

    score: Rename _Scheduler_Assignments Rename _Scheduler_Assignments into _Scheduler_Initial_assignments to make it clear that they may not reflect the run-time scheduler assignment. Update #2797.
    Comment 4
    1. Sebastian Huber, Thu, 10 Nov 2016 09:00:27 GMT

    In 1f5bee3d85405d42a7f35caf3ff0c190789afd60/rtems:

    score: Add and use Thread_Control::is_idle Update #2797.
    Comment 5
    1. Sebastian Huber, Thu, 10 Nov 2016 09:00:37 GMT

    In 05ca53ddf6bc8333c2f3ad861c5415467c3262d2/rtems:

    rtems: Add scheduler processor add/remove Update #2797.
    Comment 6
    1. Sebastian Huber, Thu, 10 Nov 2016 10:35:44 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [bcdca5db9d35138c9c97055b6e71621c451d9542/rtems-docs]

    Comment 7
    1. Sebastian Huber, Fri, 02 Dec 2016 10:19:31 GMT

    In d10716f98f950348cf25df9097402987b6e219fc/rtems:

    rtems: Fix rtems_scheduler_add_processor() Fix thread dispatch profiling of rtems_scheduler_add_processor(). Update #2797.
    Comment 8
    1. Sebastian Huber, Fri, 02 Dec 2016 10:52:04 GMT

    In 7da78cf637e5d039fd1e0aafd99b282626f9e266/rtems:

    rtems: Use _Thread_Dispatch_direct() Update #2797.
    Comment 9
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 10
    1. Sebastian Huber, Tue, 10 Oct 2017 06:24:23 GMT
    2. component: changed from SMP to rtems
    Comment 11
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2798 - Fix POSIX timer interval

    Link https://devel.rtems.org/ticket/2798
    Id 2798
    Reporter Sebastian Huber
    Created 31 October 2016 12:05:47
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    See also:

    ​https://lists.rtems.org/pipermail/users/2016-October/030714.html

    Just back to RTEMS after a long time. I've build the last version (Git)
    with last compiler (4.12) and looks like a simple POSIX timer doen't
    work anymore... It should display "Signal 14" every second but period is
    veryyyy short...and display very fast :(
    Any idea? any change in the way to use POSIX with RTEMS?
    See my program attached (it works fine with Linux).
    I have tested with Raspberry Pi and QEMU/i386.
    thx by advance
    Comment 1
    1. Sebastian Huber, Mon, 31 Oct 2016 12:37:33 GMT

    In 3e9f4c9232277079d11814e55af9bed11106bd04/rtems:

    posix: Fix timeout handling in sigtimedwait() Update #2798.
    Comment 2
    1. Sebastian Huber, Mon, 31 Oct 2016 12:37:43 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In bb9f09f34c9bdcf4d2631a1fd317bcefd8426efb/rtems:

    posix: Fix timer interval Do not overwrite timer interval with initial interval in _POSIX_Timer_Insert(). Close #2798.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2800 - qoriq variants failing to build

    Link https://devel.rtems.org/ticket/2800
    Id 2800
    Reporter Joel Sherrill
    Created 2 November 2016 16:19:23
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The following qoriq variants fail to build:

    powerpc-qoriq_core_0
    powerpc-qoriq_core_1
    powerpc-qoriq_p1020rdb

    All fail with this error:

    ../../../../../.././qoriq_core_0/lib/include/bsp/qoriq.h:407:3: error: conflicting types for 'qoriq_gpio'
    } qoriq_gpio;
    ^~~~~~~~~~
    ../../../../../.././qoriq_core_0/lib/include/bsp/qoriq.h:184:3: note: previous declaration of 'qoriq_gpio' was here
    } qoriq_gpio;
    ^~~~~~~~~~

    Found during full build sweep based on this commit:

    commit bb9f09f34c9bdcf4d2631a1fd317bcefd8426efb
    Author: Sebastian Huber
    Date: Mon Oct 31 13:07:34 2016 +0100
    posix: Fix timer interval
    Do not overwrite timer interval with initial interval in
    _POSIX_Timer_Insert().
    Close #2798.
    Comment 1
    1. Joel Sherrill, Wed, 02 Nov 2016 22:13:42 GMT

    Confirmed to still be broken on this commit:

    commit 63e2ca1b8b0a651a733d4ac3e0517397d0681214
    Author: Sebastian Huber 
    Date:   Mon Oct 31 09:13:35 2016 +0100
        score: Simplify yield and unblock scheduler ops
        Update #2556. 
    Comment 2
    1. Sebastian Huber, Mon, 07 Nov 2016 08:32:09 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 6cb234f079527dfd52da7d5a12340408777e48ee/rtems:

    bsp/qoriq: Remove duplicate qoriq_gpio definition Close #2800.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:56:19 GMT
    2. component: changed from bsps to arch/powerpc
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2802 - Test "libdl (RTL) 5" fails on SPARC targets

    Link https://devel.rtems.org/ticket/2802
    Id 2802
    Reporter Sebastian Huber
    Created 4 November 2016 13:55:35
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    On GR740 I get:

    rtl: RELOC_32 0x60ae8 @ 0x86edc in /dl-o5.o
    rtl: relocation: .rela.eh_frame, syms:.symtab
    rtl: rela: sym:__gxx_personality_v0(20)=00001dec type:3 off:00000013 addend:0
    CPU 0: IU in error mode (tt = 0x07, mem address not aligned)
    0x0001fa9c: c4040000 ld [%l0], %g2
    CPU 1: Power down mode
    CPU 2: Power down mode
    CPU 3: Power down mode

    On GR712RC I get:

    rtl: WDISP_30 0x7ffe2ccd @ 0x40087108 in /dl-o5.o
    rtl: relocation: .rela.gcc_except_table.exception_dl, syms:.symtab
    rtl: rela: sym:_ZTISt9exception(32)=40060ae8 type:3 off:00000034 addend:0
    rtl: RELOC_32 0x40060ae8 @ 0x400871b4 in /dl-o5.o
    rtl: relocation: .rela.eh_frame, syms:.symtab
    rtl: rela: sym:__gxx_personality_v0(20)=40001dec type:3 off:00000013 addend:0

    Target resets now.

    Attachments:

    1 Chris Johns, Fri, 11 Nov 2016 06:09:35 GMT
      attach: set to libdl-sparc-R_SPARC_32-missaligned.patch
     
    Comment 1
    1. Chris Johns, Thu, 10 Nov 2016 05:39:59 GMT

    This is due to the following relocation record:

    Relocation section '.rela.eh_frame' at offset 0x5fe8 contains 3 entries:
     Offset     Info    Type            Sym.Value  Sym. Name + Addend
    00000013  00001403 R_SPARC_32        00000000   __gxx_personality_v0 + 0 

    The type is R_SPARC_32 is declared as being aligned however the offset is 0x13 and this causes a misaligned access.

    Comment 2
    1. Sebastian Huber, Thu, 10 Nov 2016 07:32:09 GMT

    Is this a bug in the tool chain or the libdl?

    Comment 3
    1. Chris Johns, Thu, 10 Nov 2016 07:46:01 GMT

    I am investigating. At this stage it looks like a bug in gas. Binutils contain code that checks the lower bits of the address and selects either R_SPARC_32 or UA32. I am looking to make a suitable test case so I can see what is happening.

    Comment 4
    1. Chris Johns, Fri, 11 Nov 2016 05:50:10 GMT

    ​https://sourceware.org/bugzilla/show_bug.cgi?id=20803

    Comment 5
    1. Chris Johns, Fri, 11 Nov 2016 06:10:48 GMT

    I have attached a work-around which allows dl05 to run and fail in the expected manner.

    We can review the status of this patch once we get some feedback from the binutil's community.

    Comment 6
    1. Jiri Gaisler, Mon, 14 Nov 2016 14:24:08 GMT

    In 316da9356ad7b612f6df6ed1e47b62268450438e/rtems:

    rtl-mdreloc-sparc.c: Do not print unaligned pointer and cause unaligned access. updates #2802.
    Comment 7
    1. Sebastian Huber, Tue, 22 Nov 2016 06:41:39 GMT

    Now the test terminates with

    rtl: UA_32 0x8c6d8 @ 0x8c755 in /dl-o5.o
    rtl: alloc: del: SYMBOL addr=0x8c780
    rtl: alloc: new: OBJECT addr=0x8c7e8 size=132
    rtl: linkmap_add
    rtl: unresolv: global resolve
    dlopen:
    dlsym:
    exception_base called
    exception_dl: throwing
    terminate called after throwing an instance of 'std::runtime_error'
      what():  exception_dl throw 
    Comment 8
    1. Chris Johns, Tue, 22 Nov 2016 21:26:11 GMT

    This error is the expected result of the test. It does not pass. See #2767 for the original issue that raised the problem.

    Comment 9
    1. Sebastian Huber, Wed, 23 Nov 2016 06:04:02 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 10
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 11
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2803 - Get rid of CPU_BIG_ENDIAN and CPU_LITTLE_ENDIAN

    Link https://devel.rtems.org/ticket/2803
    Id 2803
    Reporter Sebastian Huber
    Created 7 November 2016 06:33:17
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The remaining uses of the CPU port defines CPU_BIG_ENDIAN and CPU_LITTLE_ENDIAN should be replaced by the BSD (also available in glibc) BYTE_ORDER.

    Comment 1
    1. Sebastian Huber, Mon, 07 Nov 2016 06:48:53 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Tue, 24 Jan 2017 07:40:44 GMT

    In dc9b70445015402d4d043830ecf4dd84b9400d49/rtems:

    Provide for glibc compatibility Update #2803.
    Comment 3
    1. Sebastian Huber, Tue, 24 Jan 2017 07:40:56 GMT

    In 2711914f828d19d726d3b2d9cda401352b626fc2/rtems:

    Use Update #2803.
    Comment 4
    1. Sebastian Huber, Tue, 24 Jan 2017 07:41:07 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 4aa23c9641225476bd61b1f64e324bbd0f76eab5/rtems:

    Remove CPU_BIG_ENDIAN and CPU_LITTLE_ENDIAN Use de-facto standard BYTE_ORDER instead. Close #2803.
    Comment 5
    1. Joel Sherrill, Tue, 24 Jan 2017 14:26:47 GMT

    Is this mentioned in the porting guide? If so, that needs touching as well.

    If this topic isn't mentioned (which would surprise me), then we need a ticket to discuss endian issues in porting.

    Comment 6
    1. Sebastian Huber, Tue, 24 Jan 2017 14:31:59 GMT

    Where can I find the porting guide?

    Comment 7
    1. Joel Sherrill, Tue, 24 Jan 2017 16:58:36 GMT

    ​https://git.rtems.org/rtems-docs/tree/porting

    Comment 8
    1. Sebastian Huber, Wed, 25 Jan 2017 10:23:37 GMT

    I never used this guide before. My main reference for CPU ports is ​https://git.rtems.org/rtems/tree/cpukit/score/cpu/no_cpu/rtems/score/cpu.h. It seems that it is not even built in the rtems-docs. Without looking at it, I guess it is out of date and I would need several days to fix this.

    Comment 9
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 10
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2805 - Use SPRG0 on PowerPC for current per-CPU control (SMP only)

    Link https://devel.rtems.org/ticket/2805
    Id 2805
    Reporter Sebastian Huber
    Created 9 November 2016 14:18:46
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add _CPU_Get_current_per_CPU_control() on SMP configurations as an optimization for PowerPC. Use SPRG0 for the current per-CPU control. This reduces the code size a bit and is slightly faster in some benchmarks.

    Comment 1
    1. Sebastian Huber, Thu, 10 Nov 2016 09:00:57 GMT

    In 38a1449fd47be848cc40593abd40262e9ad2030d/rtems:

    powerpc: Add _CPU_Get_current_per_CPU_control() Add _CPU_Get_current_per_CPU_control() on SMP configurations. Use SPRG0 for the current per-CPU control. This reduces the code size by three instructions and is slightly faster. Update #2805.
    Comment 2
    1. Sebastian Huber, Thu, 10 Nov 2016 09:19:10 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [6297ad31d09bb5c0bddda418881296b7cbd20152/rtems-docs]

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:23:41 GMT
    2. component: changed from SMP to arch/powerpc
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2806 - Undocumented confdefs.h Configure Options

    Link https://devel.rtems.org/ticket/2806
    Id 2806
    Reporter Joel Sherrill
    Created 9 November 2016 23:18:48
    Modified 2 April 2020 08:27:13
    Owner Sebastian Huber
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3836
    Blocked by  

    Description

    The following constants in confdefs.h that are available for users to use are not defined in the Sphinx documentation.

    • CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER - internal and CONFIGURE_APPLICATION_NEEDS_IDE_DRIVER turns into this. Should we recognize both?
    • CONFIGURE_ATA_DRIVER_TASK_PRIORITY - Document this. Looks like CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER should replace CONFIGURE_APPLICATION_NEEDS_IDE_DRIVER based on this name. There is no "IDE task priority" configure option.
    • CONFIGURE_CBS_MAXIMUM_SERVERS - document this.
    • CONFIGURE_EXECUTIVE_RAM_SIZE - do we want users to define this anymore?
    • CONFIGURE_EXTRA_MPCI_RECEIVE_SERVER_STACK
    • CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS - document this.
    • CONFIGURE_MAXIMUM_PTYS - document this. Used by telnetd. Is this the same on old and new TCP/IP stacks?
    • CONFIGURE_MAXIMUM_TASK_VARIABLES - document for 4.11, not master
    • CONFIGURE_TIMER_FOR_SHARED_MEMORY_DRIVER - internal only, do not document
    Comment 1
    1. Sebastian Huber, Thu, 19 Jan 2017 12:08:02 GMT

    For CONFIGURE_MAXIMUM_PTYS see #2872.

    Comment 2
    1. Sebastian Huber, Thu, 26 Jan 2017 07:16:00 GMT
    2. milestone: changed from 4.11.1 to 4.11.2
    Comment 3
    1. Sebastian Huber, Wed, 15 Feb 2017 13:44:44 GMT
    2. owner: set to Needs Funding
    3. status: changed from new to assigned
    4. milestone: changed from 4.11.2 to Indefinite
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 5
    1. Sebastian Huber, Tue, 31 Mar 2020 10:53:12 GMT
    2. owner: changed from Needs Funding to Sebastian Huber
    3. milestone: changed from Indefinite to 5.1
    Comment 6
    1. Sebastian Huber, Wed, 01 Apr 2020 07:03:30 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 4032c96/rtems-docs:

    c-user: Document all configuration options Close #2806.
    Comment 7
    1. Sebastian Huber, Thu, 02 Apr 2020 08:27:13 GMT
    2. blocking: set to 3836

    2807 - rtems-docs repository is not known to trac

    Link https://devel.rtems.org/ticket/2807
    Id 2807
    Reporter Sebastian Huber
    Created 10 November 2016 09:19:00
    Modified 9 November 2017 06:27:14
    Owner Amar Takhar
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Sebastian Huber, Thu, 08 Jun 2017 08:32:18 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    This works now.

    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2808 - Conditionally provide rtems_interrupt_frame

    Link https://devel.rtems.org/ticket/2808
    Id 2808
    Reporter Sebastian Huber
    Created 11 November 2016 09:40:56
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Provide rtems_interrupt_frame only if CPU_ISR_PASSES_FRAME_POINTER is defined to TRUE.

    Comment 1
    1. Sebastian Huber, Fri, 11 Nov 2016 10:08:04 GMT
    2. description: modified (diff)
    3. summary: changed from Deprecate rtems_interrupt_frame to Conditionally provide rtems_interrupt_frame

    Some CPU ports require CPU_Interrupt_frame due to CPU_ISR_PASSES_FRAME_POINTER defined to TRUE.

    Comment 2
    1. Sebastian Huber, Fri, 18 Nov 2016 07:00:30 GMT

    In 141e16d22538bc9f3f79466a774fdad3a9128533/rtems:

    rtems: Conditionally define rtems_interrupt_frame Update #2808.
    Comment 3
    1. Sebastian Huber, Mon, 19 Dec 2016 13:38:59 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [117f98c9cb990f358eb199ffedba34649a50134d/rtems-docs]

    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2809 - Reduce interrupt latency on SMP configurations during thread dispatch

    Link https://devel.rtems.org/ticket/2809
    Id 2809
    Reporter Sebastian Huber
    Created 14 November 2016 11:16:00
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Currently we have this situation:

    ​https://docs.rtems.org/doc-current/share/rtems/html/c_user/Symmetric-Multiprocessing-Services-Thread-Dispatch-Details.html#Symmetric-Multiprocessing-Services-Thread-Dispatch-Details

    "On SMP systems, scheduling decisions on one processor must be propagated to other processors through inter-processor interrupts. So, a thread dispatch which must be carried out on another processor happens not instantaneous. Thus several thread dispatch requests might be in the air and it is possible that some of them may be out of date before the corresponding processor has time to deal with them. The thread dispatch mechanism uses three per-processor variables,

    • the executing thread,
    • the heir thread, and
    • an boolean flag indicating if a thread dispatch is necessary or not.

    Updates of the heir thread and the thread dispatch necessary indicator are synchronized via explicit memory barriers without the use of locks. A thread can be an heir thread on at most one processor in the system. The thread context is protected by a TTAS lock embedded in the context to ensure that it is used on at most one processor at a time. The thread post-switch actions use a per-processor lock. This implementation turned out to be quite efficient and no lock contention was observed in the test suite.

    The current implementation of thread dispatching has some implications with respect to the interrupt latency. It is crucial to preserve the system invariant that a thread can execute on at most one processor in the system at a time. This is accomplished with a boolean indicator in the thread context. The processor architecture specific context switch code will mark that a thread context is no longer executing and waits that the heir context stopped execution before it restores the heir context and resumes execution of the heir thread (the boolean indicator is basically a TTAS lock). So, there is one point in time in which a processor is without a thread. This is essential to avoid cyclic dependencies in case multiple threads migrate at once. Otherwise some supervising entity is necessary to prevent deadlocks. Such a global supervisor would lead to scalability problems so this approach is not used. Currently the context switch is performed with interrupts disabled. Thus in case the heir thread is currently executing on another processor, the time of disabled interrupts is prolonged since one processor has to wait for another processor to make progress.

    It is difficult to avoid this issue with the interrupt latency since interrupts normally store the context of the interrupted thread on its stack. In case a thread is marked as not executing, we must not use its thread stack to store such an interrupt context. We cannot use the heir stack before it stopped execution on another processor. If we enable interrupts during this transition, then we have to provide an alternative thread independent stack for interrupts in this time frame. This issue needs further investigation.

    The problematic situation occurs in case we have a thread which executes with thread dispatching disabled and should execute on another processor (e.g. it is an heir thread on another processor). In this case the interrupts on this other processor are disabled until the thread enables thread dispatching and starts the thread dispatch sequence. The scheduler (an exception is the scheduler with thread processor affinity support) tries to avoid such a situation and checks if a new scheduled thread already executes on a processor. In case the assigned processor differs from the processor on which the thread already executes and this processor is a member of the processor set managed by this scheduler instance, it will reassign the processors to keep the already executing thread in place. Therefore normal scheduler requests will not lead to such a situation. Explicit thread migration requests, however, can lead to this situation. Explicit thread migrations may occur due to the scheduler helping protocol or explicit scheduler instance changes. The situation can also be provoked by interrupts which suspend and resume threads multiple times and produce stale asynchronous thread dispatch requests in the system."

    Add an interrupt frame to the per-CPU control which can be used during context switches on SMP configurations.

    Comment 1
    1. Sebastian Huber, Fri, 18 Nov 2016 07:00:46 GMT

    In d18560ae053857484cdb87defde44322ba67bacf/rtems:

    sparc64: Rename CPU_Minimum_stack_frame Rename SPARC64-specific CPU_Minimum_stack_frame to SPARC64_Minimum_stack_frame. Rename SPARC64-specific CPU_MINIMUM_STACK_FRAME_SIZE to SPARC64_MINIMUM_STACK_FRAME_SIZE. Update #2809.
    Comment 2
    1. Sebastian Huber, Fri, 18 Nov 2016 07:01:04 GMT

    In 427dcee8372097b0acb695d3e4645d11fccdbb6d/rtems:

    sparc: Rename CPU_Minimum_stack_frame Rename SPARC-specific CPU_Minimum_stack_frame to SPARC_Minimum_stack_frame. Rename SPARC-specific CPU_MINIMUM_STACK_FRAME_SIZE to SPARC_MINIMUM_STACK_FRAME_SIZE. Update #2809.
    Comment 3
    1. Sebastian Huber, Fri, 18 Nov 2016 07:01:20 GMT

    In c539a865f4ffc36dcc8395a4c9b9c798e45f3eb2/rtems:

    sparc: Move CPU_Interrupt_frame related defines Move CPU_Interrupt_frame related defines to . Update #2809.
    Comment 4
    1. Sebastian Huber, Fri, 18 Nov 2016 07:01:33 GMT

    In 40d592eb3e6461605838d9427dcb9f5eadc85862/rtems:

    bsps/powerpc: Avoid use of CPU_Interrupt_frame This type is not relevant for the code since only a pointer is passed around. Update #2809.
    Comment 5
    1. Sebastian Huber, Fri, 18 Nov 2016 07:01:49 GMT

    In bf4fdb1f1dcc39635f23fbc9585140be5eedb3d4/rtems:

    powerpc: Move legacy CPU_Interrupt_frame The only remaining user of CPU_Interrupt_frame on PowerPC is the mpc5xx support. Move it to here. Update #2809.
    Comment 6
    1. Sebastian Huber, Fri, 18 Nov 2016 07:02:02 GMT

    In 2599c8e63e575ee2a6f40ca995e12d4579b8ba85/rtems:

    powerpc: Add up to date CPU_Interrupt_frame Rename ppc_exc_min_frame to CPU_Interrupt_frame. Move it and the corresponding defines to . Update #2809.
    Comment 7
    1. Sebastian Huber, Fri, 18 Nov 2016 07:02:16 GMT

    In dbeccf0ec0d34fa169a0ccaf04505f9ce4e9323b/rtems:

    arm: Provide CPU_Interrupt_frame for ARMv4 Update #2809.
    Comment 8
    1. Sebastian Huber, Fri, 18 Nov 2016 07:02:42 GMT

    In f9aa34ddd9afa2953cf690eadb6119b1d24f4fc6/rtems:

    score: Add Per_CPU_Control::Interrupt_frame Update #2809.
    Comment 9
    1. Sebastian Huber, Fri, 18 Nov 2016 07:02:54 GMT

    In d5e073cde70211b2471e4366be397370e9f6ce48/rtems:

    score: Allow interrupts during thread dispatch Use a processor-specific interrupt frame during context switches in case the executing thread is longer executes on the processor and the heir thread is about to start execution. During this period we must not use a thread stack for interrupt processing. Update #2809.
    Comment 10
    1. Sebastian Huber, Fri, 23 Dec 2016 14:10:09 GMT
    2. priority: changed from normal to high
    Comment 11
    1. Sebastian Huber, Tue, 24 Jan 2017 08:00:57 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [ffe8197ac3ef6c504d6d6a233092f2bbc5f82f5c/rtems-docs]

    Comment 12
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 13
    1. Sebastian Huber, Tue, 10 Oct 2017 06:27:10 GMT
    2. component: changed from SMP to score
    Comment 14
    1. Sebastian Huber, Tue, 10 Oct 2017 06:29:01 GMT
    2. component: changed from score to cpukit
    Comment 15
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2810 - Remove sparc/sis BSP variant

    Link https://devel.rtems.org/ticket/2810
    Id 2810
    Reporter Joel Sherrill
    Created 14 November 2016 16:47:36
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type enhancement
    Component arch/sparc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc Jiri Gaisler
    Blocking  
    Blocked by  

    Description

    As discussed in the following thread, the sparc/sis BSP variant is no longer necessary and can be removed.

    ​https://lists.rtems.org/pipermail/devel/2016-November/016383.html

    This ticket is to track that removal.

    Attachments:

    1 Joel Sherrill, Tue, 15 Nov 2016 18:21:26 GMT
      attach: set to 0001-Remove-sparc-sis-BSP.patch
    Comment 1
    1. Joel Sherrill, Tue, 15 Nov 2016 18:22:19 GMT
    2. cc: Jiri Gaisler added
    Comment 2
    1. Joel Sherrill, Tue, 29 Nov 2016 15:29:21 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In de7b174e381ee60686487c03c6db8d0ed7596da1/rtems:

    Remove sparc/sis BSP. closes #2810.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:56:37 GMT
    2. component: changed from bsps to arch/sparc
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2811 - More robust thread dispatching on SMP and ARM Cortex-M

    Link https://devel.rtems.org/ticket/2811
    Id 2811
    Reporter Sebastian Huber
    Created 15 November 2016 06:45:22
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    On SMP configurations, it is a fatal error to call blocking operating system with interrupts disabled, since this prevents delivery of inter-processor interrupts. This could lead to executing threads which are not allowed to execute resulting in undefined behaviour.

    The ARM Cortex-M port has a similar problem, since the interrupt state is not a part of the thread context.

    Add a new CPU port function:

    /**
    * @brief Returns true if interrupts are enabled in the specified ISR level,
    * otherwise returns false.
    *
    * @param[in] level The ISR level.
    *
    * @retval true Interrupts are enabled in the ISR level.
    * @retval false Otherwise.
    */
    RTEMS_INLINE_ROUTINE bool _CPU_ISR_Is_enabled( uint32_t level )
    {
    return false;
    }

    Use this function to ensure that _Thread_Do_dispatch() is called with an interrupt level with enabled interrupts, otherwise call _Terminate().

    Comment 1
    1. Chris Johns, Tue, 15 Nov 2016 06:47:40 GMT

    Is this specific to an SMP build?

    Comment 2
    1. Sebastian Huber, Tue, 15 Nov 2016 06:50:03 GMT

    I will add _CPU_ISR_Is_enabled() unconditionally. The fatal error will be limited to SMP and ARM Cortex-M. However, its an application bug in general to call blocking operations with interrupts disabled.

    Comment 3
    1. Chris Johns, Tue, 15 Nov 2016 20:54:24 GMT

    Replying to sebastian.huber:

    I will add _CPU_ISR_Is_enabled() unconditionally. The fatal error will be limited to SMP and ARM Cortex-M.

    I would prefer to see an error code returned. Fatal errors should be limited to internal issues like inconsistencies where the kernel cannot reasonable continue and not user errors with an API. Fatal errors can also be difficult to track down with threading unless you have a thread aware debugger. Not all users or BSPs have this support.

    However, its an application bug in general to call blocking operations with interrupts disabled.

    Yes I would agree and if a user makes a call to RTEMS that is not valid we should return a suitable error or status code. For a single core system we have allowed this in past release so as a general change this is something that changes our current behavior.

    Comment 4
    1. Sebastian Huber, Wed, 16 Nov 2016 06:17:31 GMT

    I think a fatal error is more appropriate here.

    Applications which have this usage error needs to be fixed at compile-time. It makes no sense to ship an SMP application with this bug. Return codes can be ignored. I definitely have seen code like this before:
    /* This cannot fail, we know the identifier is valid */
    (void) pthread_mutex_lock(&mtx); 
    This ticket is a result of porting a real world application from uni-processor to SMP. If you are not an expert of the operating system internals and your application has this bug, then you need easily a couple of days to figure out the problem. So, it is important to make sure it gets detected. To figure out what caused a fatal error is easy. The (source, error) pair uniquely identifies the source code location of the error. With a stack trace and the executing thread you get enough information to locate the problem in the code. There is no need for a thread aware debugger. This is a new constraint specific to SMP. Existing software may be simply unaware of this issue. However, its important to detect this constraint violation. _Thread_Do_dispatch() has no return value. Adding this check to other places would be much more difficult, error prone. with more space and time overhead, and labour intensive to test.
    Comment 5
    1. Chris Johns, Wed, 16 Nov 2016 07:43:30 GMT

    Replying to sebastian.huber:

    I think a fatal error is more appropriate here.

    Applications which have this usage error needs to be fixed at compile-time. It makes no sense to ship an SMP application with this bug.

    A fatal error is still run-time and not a compile time error so you have lost me here.

    Return codes can be ignored. I definitely have seen code like this before:
    /* This cannot fail, we know the identifier is valid */
    (void) pthread_mutex_lock(&mtx); 

    This is a different issue and a change of topic. We provide the means for errors to be analyzed and that is our boundary.

    This ticket is a result of porting a real world application from uni-processor to SMP. If you are not an expert of the operating system internals and your application has this bug, then you need easily a couple of days to figure out the problem. So, it is important to make sure it gets detected.

    I agree with detecting the issue and there being an error. It is the delivery we are discussing.

    The error code should provide some help just like the fatal error code. If one can the other can.

    How many fatal errors instance are there in RTEMS in the kernel? Not the number of error code, but the specific locations a fatal error can appear, ie code/line pairs? I have never audited this.

    To figure out what caused a fatal error is easy. The (source, error) pair uniquely identifies the source code location of the error.

    The source location is a line the kernel's core code which means users need to step into this code and figure out the answer. I have been hit by this with SMP and it is hard.

    With a stack trace and the executing thread you get enough information to locate the problem in the code. There is no need for a thread aware debugger.

    This implies testing will highlight the issue because you have a debugger to give you this data. Currently RTEMS standard or default stack traces that get called on a fatal error provide little if any information that could be used to resolve the exact source, eg the thread id executing or even better an unwinder (dreaming here). Better support for tier 1 archs would help.

    This is a new constraint specific to SMP. Existing software may be simply unaware of this issue. However, its important to detect this constraint violation.

    I agree it is important.

    _Thread_Do_dispatch() has no return value. Adding this check to other places would be much more difficult, error prone. with more space and time overhead, and labour intensive to test.

    There are no other similar tests happening now on the blocking paths?

    Comment 6
    1. Sebastian Huber, Wed, 16 Nov 2016 08:07:30 GMT

    Replying to chrisj:

    Replying to sebastian.huber:

    I think a fatal error is more appropriate here.

    Applications which have this usage error needs to be fixed at compile-time. It makes no sense to ship an SMP application with this bug.

    A fatal error is still run-time and not a compile time error so you have lost me here.

    It is an error that must be fixed during development. Otherwise you have a broken product.

    Return codes can be ignored. I definitely have seen code like this before:
    /* This cannot fail, we know the identifier is valid */
    (void) pthread_mutex_lock(&mtx); 

    This is a different issue and a change of topic. We provide the means for errors to be analyzed and that is our boundary.

    This ticket is a result of porting a real world application from uni-processor to SMP. If you are not an expert of the operating system internals and your application has this bug, then you need easily a couple of days to figure out the problem. So, it is important to make sure it gets detected.

    I agree with detecting the issue and there being an error. It is the delivery we are discussing.

    The error code should provide some help just like the fatal error code. If one can the other can.

    How many fatal errors instance are there in RTEMS in the kernel? Not the number of error code, but the specific locations a fatal error can appear, ie code/line pairs? I have never audited this.

    See Internal_errors_Core_list, we have a test for every fatal internal error.

    To figure out what caused a fatal error is easy. The (source, error) pair uniquely identifies the source code location of the error.

    The source location is a line the kernel's core code which means users need to step into this code and figure out the answer. I have been hit by this with SMP and it is hard.

    With a stack trace and the executing thread you get enough information to locate the problem in the code. There is no need for a thread aware debugger.

    This implies testing will highlight the issue because you have a debugger to give you this data. Currently RTEMS standard or default stack traces that get called on a fatal error provide little if any information that could be used to resolve the exact source, eg the thread id executing or even better an unwinder (dreaming here). Better support for tier 1 archs would help.

    Improved fatal error diagnostics is a different topic. With a debugger is a matter of seconds to figure out the problem spot of a fatal error.

    This is a new constraint specific to SMP. Existing software may be simply unaware of this issue. However, its important to detect this constraint violation.

    I agree it is important.

    _Thread_Do_dispatch() has no return value. Adding this check to other places would be much more difficult, error prone. with more space and time overhead, and labour intensive to test.

    There are no other similar tests happening now on the blocking paths?

    No, this is a weak area in RTEMS. For example call rtems_task_wake_after() in an interrupt service routine. You don't get any status information that this is stupid.

    For now, I think a fatal error is sufficient. In case there is really a problem with this in the field, we can still improve things. What matters is that this constraint violation gets detected, otherwise you can spend hours on debugging.

    Comment 7
    1. Chris Johns, Thu, 17 Nov 2016 01:29:24 GMT

    Replying to sebastian.huber:

    Replying to chrisj:

    Replying to sebastian.huber:

    I think a fatal error is more appropriate here.

    Applications which have this usage error needs to be fixed at compile-time. It makes no sense to ship an SMP application with this bug.

    A fatal error is still run-time and not a compile time error so you have lost me here.

    It is an error that must be fixed during development. Otherwise you have a broken product.

    This goes for checking returned error codes as well.

    The logical end to this path of discussion is to remove all fatal error checks from the kernel in production because they should never appear. I am sure you would agree this is not practical therefore there is always a finite chance of a fatal error happening and robust systems need to take this issue seriously.

    In the case of this specific check or test we need to find what is practical. The issues are how it effects a user who encounters it, what it does to the kernel in terms of overhead and complexity, and what can be implemented now and and what could be implemented given the time and resources.

    How many fatal errors instance are there in RTEMS in the kernel? Not the number of error code, but the specific locations a fatal error can appear, ie code/line pairs? I have never audited this.

    See Internal_errors_Core_list, we have a test for every fatal internal error.

    Where is the user documentation? The C User guide is lacking detail for this and the other generic errors cases.

    Looking further into this we have around 300 calls to rtems_fatal_error_occurred less some for noise due to an approximate count. Of this around 200 are in the c/src tree with about 50 under the cpukit. For example we have rtems_fatal_error_occurred(0xdeadbeef); in cpukit/libfs/src/nfsclient/src/nfs.c.

    The we have the family of *_Fatal* calls. Getting decent counts is not easy so I will not put them there. We have _CPU_Fatal_halt, _BSP_Fatal_error, _POSIX_Fatal_error, MPCI_Fatal, and _SMP_Fatal. Without decent control we end up with _CPU_Fatal_halt(RTEMS_FATAL_SOURCE_EXCEPTION, 0xECC0); which is in the NIOS2 interrupt handler.

    I am concerned about adding to this without a suitable means to provide accessible user documentation on what we do.

    This implies testing will highlight the issue because you have a debugger to give you this data. Currently RTEMS standard or default stack traces that get called on a fatal error provide little if any information that could be used to resolve the exact source, eg the thread id executing or even better an unwinder (dreaming here). Better support for tier 1 archs would help.

    Improved fatal error diagnostics is a different topic.

    I do not agree. If you argue a case for using fatal errors then I see it as reasonable we discuss how this impacts users.

    With a debugger is a matter of seconds to figure out the problem spot of a fatal error.

    Yes, however the time needed to understand the issue depends on the person looking and you and I are not suitable to judge this.

    A fatal error could occur in production simply due to the fact there is code in the build that can generate them, and they do happen when performing system integration when there are no debuggers connected. How the error gets translated by a user with no knowledge of the RTEMS internals is the question being proposed. The more fatal errors we add the more of a problem this becomes and this ticket wants to add another.

    This is a new constraint specific to SMP. Existing software may be simply unaware of this issue. However, its important to detect this constraint violation.

    I agree it is important.

    _Thread_Do_dispatch() has no return value. Adding this check to other places would be much more difficult, error prone. with more space and time overhead, and labour intensive to test.

    There are no other similar tests happening now on the blocking paths?

    No, this is a weak area in RTEMS. For example call rtems_task_wake_after() in an interrupt service routine. You don't get any status information that this is stupid.

    Yes we have a few cases like this.

    For now, I think a fatal error is sufficient.

    Ok, however there is a need for documentation on the error aimed at the user being added to our user manuals.

    I would like to see better default exception output and after this discussion I can see a real need for the debug server needing to catch any fatal errors and break the system leaving the user in the thread stack frame with the error.

    In case there is really a problem with this in the field, we can still improve things.

    In terms of the implementation, sure, in terms of supporting users with suitable documentation I believe we have a problem now.

    What matters is that this constraint violation gets detected, otherwise you can spend hours on debugging.

    Yes this is the most important item to get resolved.

    Comment 8
    1. Sebastian Huber, Thu, 17 Nov 2016 14:51:24 GMT

    I will focus on fatal error documentation improvements. At least for this particular new one.

    Comment 9
    1. Sebastian Huber, Fri, 18 Nov 2016 07:04:08 GMT

    In 537f00ebe83370b8336361b8ae34d4a71e7023bb/rtems:

    score: Restrict task interrupt level to 0 on SMP Update #2811.
    Comment 10
    1. Sebastian Huber, Fri, 18 Nov 2016 07:04:23 GMT

    In 408609f6b9cd8e03d3886b7c150efbf7e59b5fb0/rtems:

    score: Add _ISR_Is_enabled() In contrast to _ISR_Get_level() the _ISR_Is_enabled() function evaluates a level parameter and returns a boolean value. Update #2811.
    Comment 11
    1. Sebastian Huber, Wed, 23 Nov 2016 11:54:10 GMT

    In 84e6f15c828869eb7d293096cfcfa0563b5752b3/rtems:

    score: Robust thread dispatch On SMP configurations, it is a fatal error to call blocking operating system with interrupts disabled, since this prevents delivery of inter-processor interrupts. This could lead to executing threads which are not allowed to execute resulting in undefined behaviour. The ARM Cortex-M port has a similar problem, since the interrupt state is not a part of the thread context. Update #2811.
    Comment 12
    1. Sebastian Huber, Fri, 02 Dec 2016 12:57:09 GMT

    In b07e642a2b1249cd64048c5e9f5e45254df7ae65/rtems:

    smpthreadlife01: Fix due to robust thread dispatch Update #2811.
    Comment 13
    1. Sebastian Huber, Fri, 09 Dec 2016 12:04:53 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Documentation update is done.

    Comment 14
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 15
    1. Sebastian Huber, Thu, 21 Sep 2017 11:33:40 GMT

    In a4bca685/rtems:

    bsps/powerpc: Fix robust thread dispatch Implement thread dispatch code in ppc_exc_wrapup() similar to ppc_exc_interrupt(). Update #2811.
    Comment 16
    1. Sebastian Huber, Mon, 09 Oct 2017 06:10:35 GMT

    In 80933ab3/rtems:

    bsps/powerpc: Fix robust thread dispatch again Use the saved MSR to account for FPU and AltiVec? settings. Update #2811.
    Comment 17
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2816 - Many ARM BSPs have Static Assert

    Link https://devel.rtems.org/ticket/2816
    Id 2816
    Reporter Joel Sherrill
    Created 18 November 2016 17:39:18
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Hi

    With the recent commits, many BSPs on the master do not build.
    They error out with this static assert:

    In file included from ../../../../cpukit/../../../gumstix/lib/include/rtems/score/types.h:23:0,

    from ../../../../cpukit/../../../gumstix/lib/include/rtems/score/cpu.h:32,
    from ../../../../cpukit/../../../gumstix/lib/include/rtems/system.h:23,
    from ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/arm/cpu.c:29:

    ../../../../cpukit/../../../gumstix/lib/include/rtems/score/basedefs.h:241:5: error: static assertion failed: "ARM_CONTEXT_CONTROL_ISR_DISPATCH_DISABLE"

    _Static_assert(cond, # msg)

    ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/arm/cpu.c:54:3: note: in expansion of macro 'RTEMS_STATIC_ASSERT'

    RTEMS_STATIC_ASSERT(

    The list of BSPs is:

    arm1136jfs arm1136js arm7tdmi arm920 csb336 csb337 csb637 edb7312
    gumstix kit637_v6 lpc2362 lpc23xx_tli800 lpc24xx_ea
    lpc24xx_ncs_ram lpc24xx_ncs_rom_ext lpc24xx_ncs_rom_int
    lpc24xx_plx800_ram lpc24xx_plx800_rom_int lpc32xx_mzx
    lpc32xx_mzx_stage_1 lpc32xx_mzx_stage_2 lpc32xx_phycore
    raspberrypi rtl22xx rtl22xx_t smdk2410

    Comment 1
    1. Sebastian Huber, Mon, 21 Nov 2016 09:15:09 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 9f225dea192e7b17ba465a6b78029532cdf97933/rtems:

    arm: Fix ARM_CONTEXT_CONTROL_ISR_DISPATCH_DISABLE Close #2816.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Mon, 16 Oct 2017 06:24:30 GMT
    2. component: changed from unspecified to arch/arm
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2817 - All Blackfin BSPs do not Compile on Master

    Link https://devel.rtems.org/ticket/2817
    Id 2817
    Reporter Joel Sherrill
    Created 18 November 2016 19:51:22
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Recent changes to master resulted in this:

    bfin-rtems4.12-gcc --pipe -DHAVE_CONFIG_H -I../../.. -I../../../../cpukit/../../../bf537Stamp/lib/include -O2 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT libscorecpu_a-cpu.o -MD -MP -MF .deps/libscorecpu_a-cpu.Tpo -c -o libscorecpu_a-cpu.o test -f 'cpu.c' || echo '../../../../../../../../rtems/c/src/../../cpukit/score/cpu/bfin/'cpu.c
    bfin-rtems4.12-gcc --pipe -DHAVE_CONFIG_H -I../../.. -I../../../../cpukit/../../../bf537Stamp/lib/include -DASM -O2 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -O2 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT libscorecpu_a-cpu_asm.o -MD -MP -MF .deps/libscorecpu_a-cpu_asm.Tpo -c -o libscorecpu_a-cpu_asm.o test -f 'cpu_asm.S' || echo '../../../../../../../../rtems/c/src/../../cpukit/score/cpu/bfin/'cpu_asm.S
    ../../../../cpukit/../../../bf537Stamp/lib/include/rtems/score/cpu.h: Assembler messages:
    ../../../../cpukit/../../../bf537Stamp/lib/include/rtems/score/cpu.h:670: Error: syntax error. Input text was static.
    ../../../../cpukit/../../../bf537Stamp/lib/include/rtems/score/cpu.h:670: Error:
    ../../../../cpukit/../../../bf537Stamp/lib/include/rtems/score/cpu.h:671: Error: syntax error. Input text was {.
    ../../../../cpukit/../../../bf537Stamp/lib/include/rtems/score/cpu.h:671: Error:
    ../../../../cpukit/../../../bf537Stamp/lib/include/rtems/score/cpu.h:672: Error: syntax error. Input text was return.
    ../../../../cpukit/../../../bf537Stamp/lib/include/rtems/score/cpu.h:672: Error:
    ../../../../cpukit/../../../bf537Stamp/lib/include/rtems/score/cpu.h:673: Error: syntax error. Input text was }.
    ../../../../cpukit/../../../bf537Stamp/lib/include/rtems/score/cpu.h:673: Error:
    gmake[7]: __* [libscorecpu_a-cpu_asm.o] Error 1 __

    Comment 1
    1. Sebastian Huber, Mon, 21 Nov 2016 09:07:41 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In c6f446bd702f6bdc469c7ed3a0e2b86cb9810032/rtems:

    bfin: ASM compatibility for Close #2817.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2818 - NIOS2 Does Not Compile on Master

    Link https://devel.rtems.org/ticket/2818
    Id 2818
    Reporter Joel Sherrill
    Created 18 November 2016 19:52:18
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/nios2/nios2-isr-get-level.c: In function '_CPU_ISR_Is_enabled':
    ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/nios2/nios2-isr-get-level.c:26:16: error: 'status' undeclared (first use in this function)

    return ((status & NIOS2_STATUS_IL_MASK) >> NIOS2_STATUS_IL_OFFSET) == 0;

    ~

    ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/nios2/nios2-isr-get-level.c:26:16: note: each undeclared identifier is reported only once for each function it appears in
    ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/nios2/nios2-isr-get-level.c:32:1: warning: control reaches end of non-void function [-Wreturn-type]

    }

    Comment 1
    1. Sebastian Huber, Mon, 21 Nov 2016 09:15:19 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In fd6d3f1f0361b2fe875b08a3c11f078fe933ff24/rtems:

    nios2: Fix _CPU_ISR_Is_enabled() Close #2818.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2819 - powerpc-ss555 does not compile on master

    Link https://devel.rtems.org/ticket/2819
    Id 2819
    Reporter Joel Sherrill
    Created 18 November 2016 19:53:13
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Recent changes broke this configuration:

    gmake[6]: Entering directory `/data/home/joel/rtems-4.11-work/rtems-testing/rtems/build-powerpc-ss555-rtems/powerpc-rtems4.12/c/ss555/testsuites/samples/hello'
    powerpc-rtems4.12-gcc -B../../../../../ss555/lib/ -specs bsp_specs -qrtems -DHAVE_CONFIG_H -I. -I../../../../../../../rtems/c/src/../../testsuites/samples/hello -I.. -mcpu=505 -Dmpc555 -O2 -g -fno-keep-inline-functions -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT init.o -MD -MP -MF .deps/init.Tpo -c -o init.o ../../../../../../../rtems/c/src/../../testsuites/samples/hello/init.c
    In file included from ../../../../../ss555/lib/include/rtems/score/percpu.h:22:0,

    from ../../../../../ss555/lib/include/rtems/confdefs.h:32,
    from ../../../../../../../rtems/c/src/../../testsuites/samples/hello/init.c:51:

    ../../../../../ss555/lib/include/rtems/score/cpuimpl.h:196:3: error: conflicting types for 'CPU_Interrupt_frame'

    } CPU_Interrupt_frame;

    In file included from ../../../../../ss555/lib/include/bsp/irq.h:28:0,

    from ../../../../../ss555/lib/include/bsp.h:31,
    from ../../../../../../../rtems/c/src/../../testsuites/samples/hello/init.c:17:

    ../../../../../ss555/lib/include/libcpu/irq.h:193:3: note: previous declaration of 'CPU_Interrupt_frame' was here

    } CPU_Interrupt_frame;

    __

    gmake[6]: __* [init.o] Error 1
    gmake[6]: Target `all' not remade because of errors.

    Comment 1
    1. Sebastian Huber, Mon, 21 Nov 2016 10:20:30 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In f730c25b707c7d6836d0a9bc2453dd0ca3cfa4e0/rtems:

    powerpc/mpc5xx: Rename CPU_Interrupt_frame The MPC5XX support uses a legacy interrupt/exception infrastructure. Close #2819.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Mon, 16 Oct 2017 06:25:10 GMT
    2. component: changed from unspecified to arch/powerpc
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2820 - All SPARC64 BSPs do not Build on master

    Link https://devel.rtems.org/ticket/2820
    Id 2820
    Reporter Joel Sherrill
    Created 18 November 2016 19:54:09
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component arch/sparc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Recent changes broke all builds:

    sparc64-rtems4.12-gcc --pipe -DHAVE_CONFIG_H -I../../.. -I../../../../cpukit/../../../usiii/lib/include -mcpu=ultrasparc3 -DUS3 -DSUN4U -g -O2 -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT libscorecpu_a-sparc64-exception-frame-print.o -MD -MP -MF .deps/libscorecpu_a-sparc64-exception-frame-print.Tpo -c -o libscorecpu_a-sparc64-exception-frame-print.o test -f 'sparc64-exception-frame-print.c' || echo '../../../../../../../../rtems/c/src/../../cpukit/score/cpu/sparc64/'sparc64-exception-frame-print.c
    sparc64-rtems4.12-gcc --pipe -DHAVE_CONFIG_H -I../../.. -I../../../../cpukit/../../../usiii/lib/include -mcpu=ultrasparc3 -DUS3 -DSUN4U -g -O2 -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT ../no_cpu/libscorecpu_a-cpucounterread.o -MD -MP -MF ../no_cpu/.deps/libscorecpu_a-cpucounterread.Tpo -c -o ../no_cpu/libscorecpu_a-cpucounterread.o test -f '../no_cpu/cpucounterread.c' || echo '../../../../../../../../rtems/c/src/../../cpukit/score/cpu/sparc64/'../no_cpu/cpucounterread.c
    In file included from ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/sparc64/../no_cpu/cpucounterread.c:15:0:
    ../../../../cpukit/../../../usiii/lib/include/rtems/score/cpu.h: In function '_CPU_ISR_Is_enabled':
    ../../../../cpukit/../../../usiii/lib/include/rtems/score/cpu.h:759:12: error: 'psr' undeclared (first use in this function)

    return ( psr & SPARC_PSTATE_IE_MASK ) != 0;

    ../../../../cpukit/../../../usiii/lib/include/rtems/score/cpu.h:759:12: note: each undeclared identifier is reported only once for each function it appears in
    gmake[7]: __* no_cpu/libscorecpu_a-cpucounterread.o Error 1
    mv -f .deps/libscorecpu_a-context.Tpo .deps/libscorecpu_a-context.Po
    In file included from ../../../../cpukit/../../../usiii/lib/include/rtems/system.h:23:0, __

    Comment 1
    1. Sebastian Huber, Mon, 21 Nov 2016 09:29:31 GMT

    In 27eccdad87a5abaa44edf756254db687a3a05be1/rtems:

    sparc64: Fix _CPU_ISR_Is_enabled() Update #2820.
    Comment 2
    1. Sebastian Huber, Mon, 21 Nov 2016 09:29:41 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In ccc92b81c9fa4a969bdcc92cf19667be105740c3/rtems:

    score: Group Per_CPU_Control members by alignment Close #2820.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Mon, 16 Oct 2017 06:23:46 GMT
    2. component: changed from unspecified to arch/sparc
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2821 - No BSPs Build on Master

    Link https://devel.rtems.org/ticket/2821
    Id 2821
    Reporter Joel Sherrill
    Created 21 November 2016 22:58:01
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority highest
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I have the latest tools.

    All BSPs appear to fail like this:

    powerpc-rtems4.11-gcc --pipe -DHAVE_CONFIG_H -I.. -I../../cpukit/../../../psim/lib/include -meabi -mcpu=603e -msdata=sysv -fno-common -Dppc603e -O2 -g -fno-keep-inline-functions -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT src/libscore_a-smpbarrierwait.o -MD -MP -MF src/.deps/libscore_a-smpbarrierwait.Tpo -c -o src/libscore_a-smpbarrierwait.o test -f 'src/smpbarrierwait.c' || echo '../../../../../../rtems/c/src/../../cpukit/score/'src/smpbarrierwait.c
    powerpc-rtems4.11-gcc --pipe -DHAVE_CONFIG_H -I.. -I../../cpukit/../../../psim/lib/include -meabi -mcpu=603e -msdata=sysv -fno-common -Dppc603e -O2 -g -fno-keep-inline-functions -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT src/libscore_a-kern_tc.o -MD -MP -MF src/.deps/libscore_a-kern_tc.Tpo -c -o src/libscore_a-kern_tc.o test -f 'src/kern_tc.c' || echo '../../../../../../rtems/c/src/../../cpukit/score/'src/kern_tc.c
    powerpc-rtems4.11-gcc --pipe -DHAVE_CONFIG_H -I.. -I../../cpukit/../../../psim/lib/include -meabi -mcpu=603e -msdata=sysv -fno-common -Dppc603e -O2 -g -fno-keep-inline-functions -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT src/libscore_a-libatomic.o -MD -MP -MF src/.deps/libscore_a-libatomic.Tpo -c -o src/libscore_a-libatomic.o test -f 'src/libatomic.c' || echo '../../../../../../rtems/c/src/../../cpukit/score/'src/libatomic.c
    mv -f src/.deps/libscore_a-semaphore.Tpo src/.deps/libscore_a-semaphore.Po
    mv -f src/.deps/libscore_a-once.Tpo src/.deps/libscore_a-once.Po
    ../../../../../../rtems/c/src/../../cpukit/score/src/libatomic.c:19:32: fatal error: machine/_libatomic.h: No such file or directory

    #include

    compilation terminated.
    gmake[6]: __* [src/libscore_a-libatomic.o] Error 1
    In file included from /data/home/joel/rtems-4.11-work/tools/4.11/powerpc-rtems4.11/include/sys/param.h:89:0, __

    from ../../../../../../rtems/c/src/../../cpukit/score/src/kern_tc.c:48:

    ../../cpukit/../../../psim/lib/include/sys/uio.h:41:9: error: unknown type name 'ssize_t'

    typedef ssize_t ssize_t;

    ../../cpukit/../../../psim/lib/include/sys/uio.h:46:9: error: unknown type name 'off_t'

    typedef off_t off_t;

    ../../cpukit/../../../psim/lib/include/sys/uio.h:46:17: error: conflicting types for 'off_t'

    typedef off_t off_t;

    Comment 1
    1. Sebastian Huber, Tue, 22 Nov 2016 06:06:50 GMT

    Replying to joel.sherrill:

    I have the latest tools.

    All BSPs appear to fail like this:

    powerpc-rtems4.11-gcc --pipe -DHAVE_CONFIG_H -I.. -I../../cpukit/../../../psim/lib/include

    [...]

    Maybe you tried to build the master with the 4.11 tool chain?

    Comment 2
    1. Joel Sherrill, Tue, 22 Nov 2016 16:58:06 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    Slaps head.. Doh! I switched the testing scripts over to 4.11 to get a warnings report and forgot to switch them back.

    Thanks.

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2822 - m32csim does not build on master

    Link https://devel.rtems.org/ticket/2822
    Id 2822
    Reporter Joel Sherrill
    Created 22 November 2016 18:30:51
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In file included from ../../cpukit/../../../m32csim/lib/include/rtems/score/types.h:22:0,

    from ../../cpukit/../../../m32csim/lib/include/rtems/score/cpu.h:40,
    from ../../../../../../rtems/c/src/../../cpukit/score/src/percpuasm.c:19:

    ../../cpukit/../../../m32csim/lib/include/rtems/score/basedefs.h:244:17: error: size of array 'rtems_static_assert_PER_CPU_OFFSET_EXECUTING' is negative

    typedef int rtems_static_assert_ ## msg [(cond) ? 1 : -1]

    ../../../../../../rtems/c/src/../../cpukit/score/src/percpuasm.c:98:1: note: in expansion of macro 'RTEMS_STATIC_ASSERT'

    RTEMS_STATIC_ASSERT(

    ../../cpukit/../../../m32csim/lib/include/rtems/score/basedefs.h:244:17: error: size of array 'rtems_static_assert_PER_CPU_OFFSET_HEIR' is negative

    typedef int rtems_static_assert_ ## msg [(cond) ? 1 : -1]

    ../../../../../../rtems/c/src/../../cpukit/score/src/percpuasm.c:103:1: note: in expansion of macro 'RTEMS_STATIC_ASSERT'

    RTEMS_STATIC_ASSERT(

    Comment 1
    1. Sebastian Huber, Wed, 23 Nov 2016 06:56:05 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In a550b3f35a32e6c74c78aeda1154b1d901574168/rtems:

    score: Force Per_CPU_Control::executing alignment This fixes the CPU ports with relaxed alignment restrictions, e.g. type alignment is less than the type size. Close #2822. Close #2823.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2823 - Nearly all m68k BSPs do not Build on Master

    Link https://devel.rtems.org/ticket/2823
    Id 2823
    Reporter Joel Sherrill
    Created 22 November 2016 18:32:44
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    av5282 is the first

    In file included from ../../cpukit/../../../av5282/lib/include/rtems/score/types.h:22:0,

    from ../../cpukit/../../../av5282/lib/include/rtems/score/cpu.h:26,
    from ../../../../../../rtems/c/src/../../cpukit/score/src/percpuasm.c:19:

    ../../cpukit/../../../av5282/lib/include/rtems/score/basedefs.h:241:5: error: static assertion failed: "PER_CPU_OFFSET_EXECUTING"

    _Static_assert(cond, # msg)

    ../../../../../../rtems/c/src/../../cpukit/score/src/percpuasm.c:98:1: note: in expansion of macro 'RTEMS_STATIC_ASSERT'

    RTEMS_STATIC_ASSERT(

    ../../cpukit/../../../av5282/lib/include/rtems/score/basedefs.h:241:5: error: static assertion failed: "PER_CPU_OFFSET_HEIR"

    _Static_assert(cond, # msg)

    ../../../../../../rtems/c/src/../../cpukit/score/src/percpuasm.c:103:1: note: in expansion of macro 'RTEMS_STATIC_ASSERT'

    RTEMS_STATIC_ASSERT(

    Comment 1
    1. Sebastian Huber, Wed, 23 Nov 2016 06:56:05 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In a550b3f35a32e6c74c78aeda1154b1d901574168/rtems:

    score: Force Per_CPU_Control::executing alignment This fixes the CPU ports with relaxed alignment restrictions, e.g. type alignment is less than the type size. Close #2822. Close #2823.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2824 - arm/lpc23xx_tli800 no longer links tar01

    Link https://devel.rtems.org/ticket/2824
    Id 2824
    Reporter Joel Sherrill
    Created 22 November 2016 18:34:37
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Normally I would add the test to those skipped but I thought this deserved a second look. Should this BSP be able to run this test? I thought it was a fairly beefy board.

    arm-rtems4.12-gcc -B../../../../../lpc23xx_tli800/lib/ -specs bsp_specs -qrtems -mcpu=arm7tdmi-s -mthumb -Os -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -Wl,--gc-sections -mcpu=arm7tdmi-s -mthumb -DHAVE_XZ=1 -o tar01.exe init.o test_cat.o initial_filesystem_tar.o initial_filesystem_tar_gz.o initial_filesystem_tar_xz.o -lrtemscpu -lz
    /data/home/joel/rtems-4.11-work/tools/4.12/bin/../lib/gcc/arm-rtems4.12/6.2.1/../../../../arm-rtems4.12/bin/ld: tar01.exe section .data' will not fit in region ROM_INT'
    /data/home/joel/rtems-4.11-work/tools/4.12/bin/../lib/gcc/arm-rtems4.12/6.2.1/../../../../arm-rtems4.12/bin/ld: region `ROM_INT' overflowed by 36 bytes
    collect2: error: ld returned 1 exit status
    gmake[7]: __* [tar01.exe] Error 1 __

    Comment 1
    1. Sebastian Huber, Wed, 23 Nov 2016 06:12:02 GMT

    No, this is a low-end target in terms of memory.

    Comment 2
    1. Sebastian Huber, Wed, 23 Nov 2016 06:47:46 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 3142727602622f7e8f0a58fe3f71648292c3733a/rtems:

    bsp/lpc23xx_tli800: Disable tar01 test Close #2824.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Mon, 16 Oct 2017 06:24:30 GMT
    2. component: changed from unspecified to arch/arm
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2825 - Improve the fatal error handling chapter of the user manual

    Link https://devel.rtems.org/ticket/2825
    Id 2825
    Reporter Sebastian Huber
    Created 23 November 2016 06:08:10
    Modified 9 November 2017 06:27:14
    Owner  
    Type enhancement
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    At least replace the "Document me" markers with something useful.

    Comment 1
    1. Sebastian Huber, Wed, 23 Nov 2016 11:55:15 GMT

    In bee032327997cb9f00d75e816ea93c7e1942a510/rtems:

    score: Uncomment unused internal error codes Update #2825.
    Comment 2
    1. Sebastian Huber, Wed, 23 Nov 2016 12:44:34 GMT

    In 73f9c2c27ba6a22f8bc3ccef9298c951c3728741/rtems:

    smptests/smpfatal03: Use timer to provoke error Avoid use of internal _Thread_Dispatch_disable() function. Update #2825.
    Comment 3
    1. Sebastian Huber, Wed, 23 Nov 2016 12:44:56 GMT

    In f6edd8807991f1da8e538c6fbadf1d0c99e76326/rtems:

    score: Explicitly define the fatal source numbers Update #2825.
    Comment 4
    1. Sebastian Huber, Mon, 12 Dec 2016 07:04:49 GMT

    In b6606e8d9911d1487dbf8338447e7560d09ff48c/rtems:

    score: Remove fatal is internal indicator The fatal is internal indicator is redundant since the fatal source and error code uniquely identify a fatal error. Keep the fatal user extension is internal parameter for backward compatibility and set it to false always. Update #2825.
    Comment 5
    1. Sebastian Huber, Mon, 12 Dec 2016 07:04:59 GMT

    In 6a9282d9bb7dd6d7665adb858161edf4e1d0778a/rtems:

    Rename is_internal to always_set_to_false Update #2825.
    Comment 6
    1. Sebastian Huber, Mon, 12 Dec 2016 07:05:09 GMT

    In 279d5260c3660e230189ea7d6b45ddf60523b2fe/rtems:

    Add INTERNAL_ERROR_RTEMS_INIT_TASK_CREATE_FAILED Update #2825.
    Comment 7
    1. Sebastian Huber, Mon, 12 Dec 2016 07:05:19 GMT

    In 0a81a58254f993652822dddba7b73cc7ac439dad/rtems:

    Add INTERNAL_ERROR_POSIX_INIT_THREAD_CREATE_FAILED Update #2825.
    Comment 8
    1. Sebastian Huber, Mon, 12 Dec 2016 07:05:38 GMT

    In 825296881297025df2f22e2e4e6f2be1d4f0ea61/rtems:

    INTERNAL_ERROR_LIBIO_USER_ENV_KEY_CREATE_FAILED Update #2825.
    Comment 9
    1. Sebastian Huber, Mon, 12 Dec 2016 07:05:48 GMT

    In 9622f7796f782a03d0c18261e21d0353880960cf/rtems:

    Add INTERNAL_ERROR_LIBIO_SEM_CREATE_FAILED Update #2825.
    Comment 10
    1. Sebastian Huber, Mon, 12 Dec 2016 07:06:07 GMT

    In a5ba08eb4f20591e8c36a12ae4a30c13f8be5c56/rtems:

    Add INTERNAL_ERROR_LIBIO_STDOUT_FD_OPEN_FAILED Update #2825.
    Comment 11
    1. Sebastian Huber, Mon, 12 Dec 2016 07:06:16 GMT

    In e203b65e516c8201360f018a3f029185cd10cba6/rtems:

    Add INTERNAL_ERROR_LIBIO_STDERR_FD_OPEN_FAILED Update #2825.
    Comment 12
    1. Sebastian Huber, Mon, 12 Dec 2016 07:08:35 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Should be sufficiently good for now.

    Comment 13
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 14
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 15
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2826 - arm_cp15_get_translation_table_base_control_register warning.

    Link https://devel.rtems.org/ticket/2826
    Id 2826
    Reporter Chris Johns
    Created 24 November 2016 02:08:26
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    arm_cp15_get_translation_table_base_control_register in c/src/lib/libcpu/arm/shared/include/arm-cp15.h returns a pointer however ttb_cr is not a pointer"

    ../../cpukit/../../../xilinx_zynq_zedboard/lib/include/libcpu/arm-cp15.h: In function 'arm_cp15_get_translation_table_base_control_register':
    ../../cpukit/../../../xilinx_zynq_zedboard/lib/include/libcpu/arm-cp15.h:401:10: warning: return makes pointer from integer without a cast [-Wint-conversion]
    return ttb_cr;
    ^~~~~~
    Comment 1
    1. Sebastian Huber, Wed, 15 Feb 2017 14:10:48 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [444cb5cd23872182f4a2fac3ca25cdbf79a49bff/rtems]

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Mon, 16 Oct 2017 06:24:30 GMT
    2. component: changed from unspecified to arch/arm
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2829 - xz git URL in README is broken

    Link https://devel.rtems.org/ticket/2829
    Id 2829
    Reporter Joel Sherrill
    Created 30 November 2016 22:22:19
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Use ​http://git.tukaani.org/?

    Comment 1
    1. Sebastian Huber, Thu, 16 Feb 2017 10:19:49 GMT

    It should be:

    ​http://git.tukaani.org/?p=xz-embedded.git;a=summary

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:35:44 GMT
    2. component: changed from misc to unspecified
    Comment 4
    1. Joel Sherrill, Thu, 12 Oct 2017 02:37:55 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In dfa9a2e7/rtems:

    xz/README: Correct URL Closes #2829.
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2835 - Ada support is broken on SMP configurations

    Link https://devel.rtems.org/ticket/2835
    Id 2835
    Reporter Sebastian Huber
    Created 7 December 2016 07:58:07
    Modified 9 November 2017 06:27:14
    Owner Needs Funding
    Type defect
    Component tool/gcc
    Status closed
    Resolution duplicate
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The Ada support is the last user of a task variable: rtems_ada_self. This doesn't work on SMP configurations. The Ada support in GCC should be changed to use a function call or C11 thread-local storage.

    Comment 1
    1. Sebastian Huber, Tue, 07 Mar 2017 10:07:33 GMT
    2. owner: set to Needs Funding
    3. status: changed from new to assigned
    4. milestone: changed from 5.0 to Indefinite
    Comment 2
    1. Sebastian Huber, Tue, 23 May 2017 07:58:43 GMT
    2. status: changed from assigned to closed
    3. resolution: set to duplicate

    This is a duplicate of #2289.

    Comment 3
    1. Sebastian Huber, Thu, 05 Oct 2017 08:31:08 GMT
    2. milestone: changed from Indefinite to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2836 - Add posix_devctl()

    Link https://devel.rtems.org/ticket/2836
    Id 2836
    Reporter Joel Sherrill
    Created 9 December 2016 16:37:30
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords POSIX-Compliance
    Cc  
    Blocking  
    Blocked by  

    Description

    The posix_devctl() method is defined in POSIX 1003.26 and required by the FACE POSIX profiles. The only use case that needs to be supported is FIONBIO on sockets per the FACE Technical Standard.

    ioctl() is not a standardized method per POSIX and is not included in the FACE Profiles.

    Making operations non-blocking can also be done with fcntl() but due to RTOS qualification concerns, fcntl() is not included in the more stringent FACE profiles. Specifically, it is not in the Safety Base profile which matches the RTEMS POSIX capabilities.

    This requires adding the file to newlib. That has been done. I am testing my implementation but a tool update will be needed before this can be pushed to the community. This is OK because we have other reasons to move to a new gcc and newlib version soon.

    Comment 1
    1. Joel Sherrill, Fri, 09 Dec 2016 16:39:09 GMT
    2. description: modified (diff)
    Comment 2
    1. Joel Sherrill, Mon, 03 Apr 2017 14:08:38 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    The code, tests, and documentation are merged.

    Comment 3
    1. Joel Sherrill, Mon, 03 Apr 2017 23:15:32 GMT
    2. keywords: POSIX-Compliance added
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2838 - Termios task driven mode should use mutex for device operations

    Link https://devel.rtems.org/ticket/2838
    Id 2838
    Reporter Sebastian Huber
    Created 14 December 2016 12:27:32
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Termios has a task driven mode (TERMIOS_TASK_DRIVEN). This mode aims to avoid long sections with disabled interrupts. This is only partly implemented since the device level state is still protected by disabled interrupts. Use a mutex to protect the device level state in task driven mode to fix this issue.

    Comment 1
    1. Sebastian Huber, Fri, 16 Dec 2016 10:29:41 GMT

    In c3764ce80588461d086e844e68002142dbd1ead9/rtems:

    termios: Use mutex for task driven mode Termios has a task driven mode (TERMIOS_TASK_DRIVEN). This mode aims to avoid long sections with disabled interrupts. This is only partly implemented since the device level state is still protected by disabled interrupts. Use a mutex to protect the device level state in task driven mode to fix this issue. Update #2838.
    Comment 2
    1. Sebastian Huber, Fri, 23 Dec 2016 13:48:25 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [5bb51a43d1c770dfaddd484f0e5f6d104b8df92e/rtems-docs]

    Comment 3
    1. Sebastian Huber, Fri, 03 Feb 2017 09:58:24 GMT

    In 85ed95ec4808d021be50a1ab1f476476a09c5a22/rtems:

    termios: Fix static device initalization This enables early printk() support. Update #2838.
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2839 - Add new interrupt server driven Termios mode

    Link https://devel.rtems.org/ticket/2839
    Id 2839
    Reporter Sebastian Huber
    Created 14 December 2016 12:36:47
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add a new new interrupt server driven Termios mode (TERMIOS_IRQ_DRIVEN). This mode is identical to the interrupt driven mode except that a mutex is used for device level locking. The intended use case for this mode are device drivers that use the interrupt server, e.g. SPI or I2C connected devices.

    Comment 1
    1. Alexander Krutwig, Fri, 16 Dec 2016 10:29:55 GMT

    In e34fe384cb7ecdd2643e8bf528e08e1c988abc8a/rtems:

    termios: Add TERMIOS_IRQ_SERVER_DRIVEN Add a new interrupt server driven Termios mode (TERMIOS_IRQ_DRIVEN). This mode is identical to the interrupt driven mode except that a mutex is used for device level locking. The intended use case for this mode are device drivers that use the interrupt server, e.g. SPI or I2C connected devices. Update #2839.
    Comment 2
    1. Sebastian Huber, Fri, 23 Dec 2016 14:12:15 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [5bb51a43d1c770dfaddd484f0e5f6d104b8df92e/rtems-docs]

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2840 - Use self-contained mutexes for Termios framework

    Link https://devel.rtems.org/ticket/2840
    Id 2840
    Reporter Sebastian Huber
    Created 14 December 2016 12:53:36
    Modified 22 February 2018 15:42:52
    Owner Sebastian Huber
    Type enhancement
    Component dev/serial
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Use C11 mutexes instead of Classic semaphores as a performance optimization and to simplify the application configuration.

    A performance of Classic semaphores vs. C11 mutexes was measured on the arm/atsam BSP. A NXP SC16IS752 was connected via SPI. The RTEMS application used one task to read from the device and write it immediately back (look back via task). A development system constantly transmitted data at 115200 bits per second.

    CPU usage by function with Classic semaphores:

    name______________________________________|ratio___|1%_____2%________5%_____10%_____20%_______50%___100|
    CPU_Thread_Idle_body | 22.454%|================================= |
    atsam_spi_setup_transfer | 6.767%|==================== |
    Objects_Get | 5.859%|=================== |
    atsam_spi_interrupt | 4.483%|================ |
    Event_Seize | 3.867%|============== |
    rtems_termios_enqueue_raw_characters | 3.804%|============== |
    Timecounter_Binuptime | 3.715%|============== |
    Scheduler_priority_Block | 3.104%|============ |
    rtems_semaphore_release | 3.018%|============ |
    Scheduler_priority_Unblock | 2.901%|=========== |
    rtems_termios_read_tty | 2.777%|=========== |
    ARMV7M_NVIC_Interrupt_dispatch | 2.750%|=========== |
    rtems_semaphore_obtain | 2.627%|========== |
    Thread_Do_dispatch | 2.351%|========= |
    ARMV7M_Interrupt_service_leave | 2.086%|======== |
    iproc | 1.919%|======= |
    CPU_Context_switch |

    CPU usage by function with C11 mutexes:

    name______________________________________|ratio___|1%_____2%________5%_____10%_____20%_______50%___100|
    CPU_Thread_Idle_body | 33.395%|====================================== |
    atsam_spi_setup_transfer | 6.061%|=================== |
    atsam_spi_interrupt | 4.690%|================ |
    Mutex_recursive_Release | 3.011%|============ |
    Event_Seize | 2.955%|=========== |
    ARMV7M_NVIC_Interrupt_dispatch | 2.885%|=========== |
    rtems_termios_enqueue_raw_characters | 2.771%|=========== |
    rtems_termios_read_tty | 2.722%|=========== |
    Timecounter_Binuptime | 2.653%|========== |
    Thread_Do_dispatch | 2.240%|======== |
    Scheduler_priority_Block | 2.112%|======== |
    ARMV7M_Interrupt_service_leave | 2.100%|======== |
    Scheduler_priority_Unblock | 1.919%|======= |
    Mutex_recursive_Acquire | 1.876%|====== |
    iproc | 1.773%|====== |
    CPU_Context_switch |

    The change resulted in 10% more total idle time on the system.

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:42:40 GMT
    2. milestone: changed from 4.12.0 to 5.0
    Comment 3
    1. Chris Johns, Mon, 14 Aug 2017 00:12:55 GMT
    2. version: 4.11 deleted
    3. milestone: changed from 5.0 to Indefinite
    Comment 4
    1. Sebastian Huber, Fri, 02 Feb 2018 14:22:00 GMT

    In 2c12262/rtems:

    termios: Use self-contained objects Update #2840.
    Comment 5
    1. Sebastian Huber, Mon, 05 Feb 2018 10:50:41 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    4. summary: changed from Use C11 mutexes for Termios framework to Use self-contained mutexes for Termios framework
    5. component: changed from score to dev/serial
    6. milestone: changed from Indefinite to 5.1

    Fixed by #2843.

    Comment 6
    1. Sebastian Huber, Thu, 22 Feb 2018 15:42:52 GMT

    In 5618997d/rtems:

    termios: Fix use of uninitialized variable Update #2840.

    2841 - Add NXP SC16IS752 serial device driver

    Link https://devel.rtems.org/ticket/2841
    Id 2841
    Reporter Sebastian Huber
    Created 14 December 2016 14:19:23
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add Termios device driver for NXP SC16IS752 (RS232/RS485 over SPI or I2C).

    Comment 1
    1. Alexander Krutwig, Fri, 16 Dec 2016 10:30:07 GMT

    In 9edc73013bbf20d5ca7df67df46699ca32c3e371/rtems:

    dev: Add NXP SC16IS752 serial device driver Update #2841.
    Comment 2
    1. Sebastian Huber, Mon, 30 Jan 2017 14:07:40 GMT
    2. status: changed from new to closed
    3. version: changed from 4.11 to 4.12
    4. resolution: set to fixed
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2842 - Change C11 threads support to use Classic tasks instead of POSIX threads

    Link https://devel.rtems.org/ticket/2842
    Id 2842
    Reporter Sebastian Huber
    Created 16 December 2016 16:22:43
    Modified 13 August 2020 04:48:22
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The C11 support should be available in all RTEMS configurations. Since the POSIX API is still optional the C11 threads implementation should be changed to use Classic tasks.

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:42:40 GMT
    2. milestone: changed from 4.12.0 to 5.0
    Comment 3
    1. Chris Johns, Mon, 14 Aug 2017 00:13:17 GMT
    2. version: 4.11 deleted
    3. milestone: changed from 5.0 to Indefinite
    Comment 4
    1. Joel Sherrill, Wed, 12 Aug 2020 21:11:51 GMT

    Can this be closed? I think we have our implementation from FreeBSD and are happy with it.

    Comment 5
    1. Chris Johns, Thu, 13 Aug 2020 01:42:07 GMT

    Is the configure option for POSIX going to be removed in the waf build system?

    Comment 6
    1. Sebastian Huber, Thu, 13 Aug 2020 04:46:37 GMT

    Replying to Chris Johns:

    Is the configure option for POSIX going to be removed in the waf build system?

    No, this CPU option exists also in the new build system.

    Comment 7
    1. Sebastian Huber, Thu, 13 Aug 2020 04:48:22 GMT
    2. status: changed from new to closed
    3. version: set to 4.11
    4. resolution: set to fixed
    5. milestone: changed from Indefinite to 5.1

    The POSIX thread support is always enabled in RTEMS 5.1. There is no need to change the implementation of C11 threads.


    2843 - Use self-contained objects instead of Classic API for drivers and support libraries

    Link https://devel.rtems.org/ticket/2843
    Id 2843
    Reporter Sebastian Huber
    Created 16 December 2016 16:25:04
    Modified 8 February 2018 08:59:06
    Owner Sebastian Huber
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The Classic API has some weaknesses:

    • Dynamic memory (the workspace) is used to allocate object pools. This requires a complex configuration with heavy use of the C pre-processor.
    • Objects are created via function calls which return an object identifier. The object operations use this identifier and map it internally to an object representation.
    • The objects reside in a table, e.g. they are suspect to false sharing of cache lines.
    • The object operations use a rich set of options and attributes. For each object operation these parameters must be evaluated and validated at run-time to figure out what to do exactly for this operation.

    The overhead for Classic API mutexes used for example in Termios and the SPI framework is significant, see discussion:

    ​https://lists.rtems.org/pipermail/devel/2016-December/016543.html

    There are some API options available:

  • Use C11 mutexes and condition variables.
  • Turn the POSIX synchronization objects into self-contained objects and use them.
  • Use FreeBSD synchronization objects like ​MUTEX(9) or ​CONDVAR(9).
  • Add RTEMS-specific self-contained synchronization objects and use them.
  • Option 1. and 2. lack support for binary semaphores which are used for task/interrupt synchronization, e.g. Termios.

    Option 2. needs run-time evaluation to figure out the actual object variant, e.g. non-recursive, recursive, ceiling, error-checking, robust POSIX mutex.

    Option 3. uses hash tables, thus it is not suitable for real-time systems.

    Option 1. and 2. lack support for user-defined object names that may help for system diagnostic, tracing and debugging.

    Option 4. could be used to avoid all shortcomings of options 1-3. It would be trivial to implement, test and document.

    In order to enable user-defined object names one option is to add a const char *name member to Thread_queue_Queue.

    Comment 1
    1. Sebastian Huber, Tue, 20 Dec 2016 08:15:06 GMT
    2. description: modified (diff)
    3. summary: changed from Use C11 mutexes instead of Classic API priority inheritance semaphores to Use self-contained objects instead of Classic API for drivers and support libraries
    Comment 2
    1. Chris Johns, Tue, 20 Dec 2016 10:23:41 GMT

    Can Option 4 be NP extensions to POSIX after Option 2 is done?

    Comment 3
    1. Sebastian Huber, Tue, 20 Dec 2016 10:28:54 GMT

    Replying to chrisj:

    Can Option 4 be NP extensions to POSIX after Option 2 is done?

    Binary semaphores are not available out of the box with POSIX. You need a mutex and a condition variable for this, e.g. ​http://stackoverflow.com/questions/7478684/how-to-initialise-a-binary-semaphore-in-c.

    Option 4. should be implementable via POSIX to allow to run the software without RTEMS, however, it should use a specialized implementation on RTEMS to minimize run-time and space overheads.

    Comment 4
    1. Gedare Bloom, Tue, 20 Dec 2016 19:34:28 GMT

    What are the downsides for self-contained objects? (Is there a clear definition of what self-contained objects are?)

    Comment 5
    1. Sebastian Huber, Wed, 21 Dec 2016 06:43:21 GMT

    Self-contained means the user must provide the storage for the object.

    ​https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/sys/rtems/include/sys/lock.h;h=c0549db67cbb559edacbef49584156fb8ac346fd;hb=HEAD

    What you cannot do with self-contained objects is using them in a distributed system with distinct address spaces, e.g. a usage case RTEMS was initially designed for. Here you need one level of indirection to identify objects globally.

    With object identifiers you can detect a use of deleted objects under certain conditions. You cannot detect use of a deleted and re-used object. To detect/prevent the use of deleted objects in SMP configurations is quite difficult (e.g. hazard pointers) and not implemented in RTEMS.

    From my point of view the advantages of self-contained objects are apparent.

    Comment 6
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 7
    1. Sebastian Huber, Thu, 11 May 2017 07:42:40 GMT
    2. milestone: changed from 4.12.0 to 5.0
    Comment 8
    1. Chris Johns, Mon, 14 Aug 2017 00:55:55 GMT
    2. milestone: changed from 5.0 to 4.12.0

    Please review and update the milestone. Thanks.

    Comment 9
    1. Joel Sherrill, Thu, 12 Oct 2017 02:23:15 GMT
    2. component: changed from score to bsps
    3. milestone: changed from 4.12.0 to 4.13.0
    Comment 10
    1. Sebastian Huber, Thu, 09 Nov 2017 06:26:20 GMT
    2. milestone: changed from 4.13.0 to 5.0
    Comment 11
    1. Sebastian Huber, Thu, 09 Nov 2017 06:26:42 GMT
    2. milestone: changed from 5.0 to 6.1

    Milestone renamed

    Comment 12
    1. Sebastian Huber, Mon, 22 Jan 2018 09:40:28 GMT

    In 6bc5e47/rtems:

    smptests: Fix configuration Update #2843.
    Comment 13
    1. Sebastian Huber, Fri, 02 Feb 2018 14:21:23 GMT

    In f14a04c6/rtems:

    Add RTEMS thread API Update #2843.
    Comment 14
    1. Sebastian Huber, Fri, 02 Feb 2018 14:21:36 GMT

    In 1b2da177/rtems:

    libblock: Use self-contained mutex for disk lock Update #2843.
    Comment 15
    1. Sebastian Huber, Fri, 02 Feb 2018 14:21:48 GMT

    In 8d7f3680/rtems:

    libblock: Use self-contained mutex and cond var Update #2843.
    Comment 16
    1. Sebastian Huber, Fri, 02 Feb 2018 14:22:11 GMT

    In dc158ad/rtems:

    i2c: Use self-contained mutex Update #2843.
    Comment 17
    1. Sebastian Huber, Fri, 02 Feb 2018 14:22:23 GMT

    In 36304f3/rtems:

    spi: Use self-contained mutex Update #2843.
    Comment 18
    1. Sebastian Huber, Fri, 02 Feb 2018 14:22:35 GMT

    In 16fc3f9a/rtems:

    network: Use self-contained recursive mutex Update #2843.
    Comment 19
    1. Sebastian Huber, Fri, 02 Feb 2018 14:22:47 GMT

    In b17bcb3/rtems:

    JFFS2: Use self-contained recursive mutex Update #2843.
    Comment 20
    1. Sebastian Huber, Fri, 02 Feb 2018 14:22:59 GMT

    In 3b77417/rtems:

    dosfs: Use self-contained recursive mutex Update #2843.
    Comment 21
    1. Sebastian Huber, Fri, 02 Feb 2018 14:23:11 GMT

    In 0940648f/rtems:

    RFS: Use self-contained recursive mutex Update #2843.
    Comment 22
    1. Sebastian Huber, Fri, 02 Feb 2018 14:23:22 GMT

    In 8ddd92d/rtems:

    pipe: Use self-contained mutex Update #2843.
    Comment 23
    1. Sebastian Huber, Fri, 02 Feb 2018 14:23:34 GMT

    In 03e5a780/rtems:

    NFS: Use self-contained recursive mutex Update #2843.
    Comment 24
    1. Chris Johns, Sun, 04 Feb 2018 22:31:46 GMT

    These changes are fantastic. It is so nice after all this time to see the internal allocation issue being solved in this way. Thank you.

    Comment 25
    1. Sebastian Huber, Mon, 05 Feb 2018 08:47:18 GMT

    In 1472f84/rtems-docs:

    c-user: Add self-contained objects chapter Update #2843.
    Comment 26
    1. Sebastian Huber, Mon, 05 Feb 2018 08:58:31 GMT

    In 53b6484/rtems:

    termios: Remove obsolete configuration options Update #2843.
    Comment 27
    1. Sebastian Huber, Mon, 05 Feb 2018 09:01:16 GMT

    In 0851404/rtems-docs:

    c-user: Document obsolete termios config options Update #2843.
    Comment 28
    1. Sebastian Huber, Mon, 05 Feb 2018 10:39:43 GMT

    In 8b3da13/rtems-libbsd:

    termios: Update due to API changes Update #2843.
    Comment 29
    1. Sebastian Huber, Mon, 05 Feb 2018 11:14:17 GMT
    2. component: changed from bsps to unspecified
    3. milestone: changed from 6.1 to 5.1
    Comment 30
    1. Sebastian Huber, Wed, 07 Feb 2018 13:14:31 GMT

    In e16111b/rtems:

    NFS: Fix use of self-contained objects Update #2843.
    Comment 31
    1. Sebastian Huber, Thu, 08 Feb 2018 08:16:35 GMT

    In c8d5bed/rtems:

    libblock: Use self-contained mutex for nvdisk Update #2843.
    Comment 32
    1. Sebastian Huber, Thu, 08 Feb 2018 08:16:50 GMT

    In f9027ccf/rtems:

    libblock: Use self-contained mutex for flashdisk Update #2843.
    Comment 33
    1. Sebastian Huber, Thu, 08 Feb 2018 08:17:02 GMT

    In 868ca746/rtems:

    libblock: Use self-contained mutex for sparse disk Update #2843.
    Comment 34
    1. Sebastian Huber, Thu, 08 Feb 2018 08:17:17 GMT

    In a59a6182/rtems:

    libblock: Use self-contained mutex for media Update #2843.
    Comment 35
    1. Sebastian Huber, Thu, 08 Feb 2018 08:17:32 GMT

    In 0a593c2d/rtems:

    ftpd: Use self-contained synchronization objects Update #2843.
    Comment 36
    1. Sebastian Huber, Thu, 08 Feb 2018 08:17:45 GMT

    In d9800ac/rtems:

    libdl: Use self-contained recursive mutex Update #2843.
    Comment 37
    1. Sebastian Huber, Thu, 08 Feb 2018 08:17:59 GMT

    In 87b7117f/rtems:

    libdl: Use self-contained mutex for RAP Update #2843.
    Comment 38
    1. Sebastian Huber, Thu, 08 Feb 2018 08:18:12 GMT

    In 71a8446/rtems:

    libdl: Fix potential overwrite of dest buffer Update #2843.
    Comment 39
    1. Sebastian Huber, Thu, 08 Feb 2018 08:18:26 GMT

    In 3535439f/rtems:

    tftpfs: Use self-contained mutex Update #2843.
    Comment 40
    1. Sebastian Huber, Thu, 08 Feb 2018 08:18:38 GMT

    In 2aa5b98/rtems:

    syslog: Use self-contained recursive mutex Update #2843.
    Comment 41
    1. Sebastian Huber, Thu, 08 Feb 2018 08:18:51 GMT

    In 2fd31117/rtems:

    stdio-redirector: Use self-contained mutex Update #2843.
    Comment 42
    1. Sebastian Huber, Thu, 08 Feb 2018 08:38:11 GMT

    In 9ace2648/rtems:

    fdt: Use self-contained mutex Update #2843.
    Comment 43
    1. Sebastian Huber, Thu, 08 Feb 2018 08:59:06 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    All cpukit services use now self-contained objects, except:

    gxx_wrappers.c (legacy, would need GCC patch) ada_intrsupp.c (would need GCC patch) libi2c.c (legacy, I2C drivers should use new framework) sse_test.c (seems to be dead code)

    2844 - JFFS2: Add IO controls to get filesystem instance information and force a garbage collection

    Link https://devel.rtems.org/ticket/2844
    Id 2844
    Reporter Sebastian Huber
    Created 19 December 2016 11:35:54
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component fs
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Some applications need to control the garbage collection of the JFFS2 filesystem. For example during bootloader to application transitions with execute in place flashes (XIP).

    Comment 1
    1. Chris Johns, Mon, 19 Dec 2016 21:28:42 GMT

    When does JFFS2 garbage collect at the moment?

    Does this mean we can mount a JFFS2 disk and not start the garbage collection and defer it to later?

    If so does this mean a user needs to enable garage collection at some later time or will the JFFS be configured to start garbage collection automatically?

    Comment 2
    1. Sebastian Huber, Tue, 20 Dec 2016 06:29:55 GMT

    Garbage collection is done on demand automatically as late as possible. Every operation can result in a garbage collection. We don't have a garbage collection thread like on Linux.

    This operation gives you a bit more control when the garbage collection takes place.

    Comment 3
    1. Sebastian Huber, Tue, 20 Dec 2016 07:32:35 GMT

    In 07c833f8f98c665e2f7d7e9adfa5f5503177dbff/rtems:

    JFFS2: Add RTEMS_JFFS2_GET_INFO Add IO control RTEMS_JFFS2_GET_INFO to get some JFFS2 filesystem instance information. Update #2844.
    Comment 4
    1. Sebastian Huber, Tue, 20 Dec 2016 07:32:47 GMT

    In ade135d45577263fe2c7b4d885e81c1798a1a79a/rtems:

    JFFS2: Add RTEMS_JFFS2_FORCE_GARBAGE_COLLECTION Add IO control to force a garbage collection. Update #2844.
    Comment 5
    1. Sebastian Huber, Tue, 20 Dec 2016 07:32:59 GMT

    In ab834d65e4a96bb59901f4349857ffe3e57a3f54/rtems:

    JFFS2: RTEMS_JFFS2_ON_DEMAND_GARBAGE_COLLECTION Update #2844.
    Comment 6
    1. Sebastian Huber, Tue, 20 Dec 2016 07:33:21 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 7
    1. Chris Johns, Tue, 20 Dec 2016 07:49:54 GMT

    Replying to sebastian.huber:

    Garbage collection is done on demand automatically as late as possible. Every operation can result in a garbage collection. We don't have a garbage collection thread like on Linux.

    Is there a special reason we do not have a thread?

    This operation gives you a bit more control when the garbage collection takes place.

    I see it forces a garbage collection so how do you suspend it?

    Your original post suggested it could be suspended and this would be good. After a large delete and reboot the start up can hang on the mount. It would be nice to hold this until we have initialised and then let the clean up happen.

    Comment 8
    1. Sebastian Huber, Tue, 20 Dec 2016 07:54:55 GMT

    Replying to chrisj:

    Replying to sebastian.huber:

    Garbage collection is done on demand automatically as late as possible. Every operation can result in a garbage collection. We don't have a garbage collection thread like on Linux.

    Is there a special reason we do not have a thread?

    Nobody needed it up to now.

    This operation gives you a bit more control when the garbage collection takes place.

    I see it forces a garbage collection so how do you suspend it?

    Your original post suggested it could be suspended and this would be good. After a large delete and reboot the start up can hang on the mount. It would be nice to hold this until we have initialised and then let the clean up happen.

    With the RTEMS_JFFS2_ON_DEMAND_GARBAGE_COLLECTION and the rtems_jffs2_control::trigger_garbage_collection you have now the ability to use a garbage collection thread in your application.

    Comment 9
    1. Chris Johns, Tue, 20 Dec 2016 10:20:07 GMT

    Replying to sebastian.huber:

    Replying to chrisj:

    Replying to sebastian.huber:

    Garbage collection is done on demand automatically as late as possible. Every operation can result in a garbage collection. We don't have a garbage collection thread like on Linux.

    Is there a special reason we do not have a thread?

    Nobody needed it up to now.

    Great, that is fine.

    This operation gives you a bit more control when the garbage collection takes place.

    I see it forces a garbage collection so how do you suspend it?

    Your original post suggested it could be suspended and this would be good. After a large delete and reboot the start up can hang on the mount. It would be nice to hold this until we have initialised and then let the clean up happen.

    With the RTEMS_JFFS2_ON_DEMAND_GARBAGE_COLLECTION and the rtems_jffs2_control::trigger_garbage_collection you have now the ability to use a garbage collection thread in your application.

    OK. I will take a look. It would be good to have an example of doing this or even something a user can pull in.

    Comment 10
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 11
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2845 - Add I2C framework documentation

    Link https://devel.rtems.org/ticket/2845
    Id 2845
    Reporter Sebastian Huber
    Created 20 December 2016 08:47:57
    Modified 9 November 2017 06:27:14
    Owner  
    Type enhancement
    Component doc
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The new I2C framework lacks documentation.

    Comment 1
    1. Sebastian Huber, Fri, 23 Dec 2016 13:43:39 GMT

    [7351405fe6841705d8fab2abbd080552e5290ff8/rtems-docs]

    Comment 2
    1. Sebastian Huber, Fri, 23 Dec 2016 13:43:55 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2849 - ATA/IDE support in RTEMS is out-dated

    Link https://devel.rtems.org/ticket/2849
    Id 2849
    Reporter Sebastian Huber
    Created 20 December 2016 08:52:50
    Modified 9 November 2017 06:27:14
    Owner  
    Type enhancement
    Component doc
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The ATA/IDE support in RTEMS is out-dated. New platforms should consider to use the SATA support provided by FreeBSD via libbsd.

    Update the documentation accordingly.

    Comment 1
    1. Sebastian Huber, Fri, 23 Dec 2016 13:46:19 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [4af69ea42a3167f39d9132a1f723810981086645/rtems-docs]

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2850 - Driver manual covers non-existent Analog Driver

    Link https://devel.rtems.org/ticket/2850
    Id 2850
    Reporter Sebastian Huber
    Created 20 December 2016 08:54:52
    Modified 9 November 2017 06:27:14
    Owner  
    Type enhancement
    Component doc
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove this chapter from the documentation.

    Comment 1
    1. Sebastian Huber, Tue, 20 Dec 2016 10:35:53 GMT
    2. summary: changed from Driver manual covers non-existant Analog Driver to Driver manual covers non-existent Analog Driver
    Comment 2
    1. Sebastian Huber, Fri, 23 Dec 2016 13:44:46 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [4b5b49988d8eaf78ea58e1b290159632ab547c3a/rtems-docs]

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2851 - Driver manual covers non-existent Discrete Driver

    Link https://devel.rtems.org/ticket/2851
    Id 2851
    Reporter Sebastian Huber
    Created 20 December 2016 08:55:36
    Modified 9 November 2017 06:27:14
    Owner  
    Type enhancement
    Component doc
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove this chapter from the documentation.

    Comment 1
    1. Sebastian Huber, Tue, 20 Dec 2016 10:36:03 GMT
    2. summary: changed from Driver manual covers non-existant Discrete Driver to Driver manual covers non-existent Discrete Driver
    Comment 2
    1. Sebastian Huber, Fri, 23 Dec 2016 13:45:07 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [5b8d5d06c199ac2651103ed11b6f7caea44d1f68/rtems-docs]

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2853 - Driver manual covers non-existent Non-Volatile Memory Driver

    Link https://devel.rtems.org/ticket/2853
    Id 2853
    Reporter Sebastian Huber
    Created 20 December 2016 10:37:09
    Modified 9 November 2017 06:27:14
    Owner  
    Type enhancement
    Component doc
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove this chapter from the documentation.

    Comment 1
    1. Sebastian Huber, Fri, 23 Dec 2016 13:45:41 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [003ee4d27dac8c3e6b7d6f8808f0a54dbb3289b8/rtems-docs]

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2858 - Add user defined thread names

    Link https://devel.rtems.org/ticket/2858
    Id 2858
    Reporter Sebastian Huber
    Created 12 January 2017 12:41:16
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add user defined thread names to ease debugging, enhance the system diagnostics and improve compatibility to other systems, e.g. Linux and FreeBSD.

    Implement pthread_setname_np() and pthread_getname_np(). Add CONFIGURE_MAXIMUM_THREAD_NAME_SIZE to the application configuration options. Add a application configuration dependent storage area for thread names to the thread control block.

    Comment 1
    1. Joel Sherrill, Thu, 12 Jan 2017 13:41:01 GMT

    This shouldn't be hard to add since rtems_object_[gs]et_name() were added to do the same thing. These have been in since before 4.10. See psx14 for an example usage of rtems_object_set_name() on a pthread.

    Comment 2
    1. Sebastian Huber, Thu, 12 Jan 2017 14:50:47 GMT

    The problem with the object set/get name is that the interpretation of the Objects_Name depends on Objects_Information::is_string which is false for Classic and true for POSIX.

    Comment 3
    1. Sebastian Huber, Thu, 12 Jan 2017 14:53:20 GMT

    With the new thread name support I get now

    [/] # cpuuse
    -------------------------------------------------------------------------------
                                  CPU USAGE BY THREAD
    ------------+----------------------------------------+---------------+---------
     ID         | NAME                                   | SECONDS       | PERCENT
    ------------+----------------------------------------+---------------+---------
     0x09010001 | IDLE                                   |      2.389090 |  71.877
     0x0a010001 | UI1                                    |      0.214980 |   6.464
     0x0a010002 | BSWP                                   |      0.005139 |   0.154
     0x0a010003 | BRDA                                   |      0.001066 |   0.032
     0x0a010004 | MDIA                                   |      0.000583 |   0.017
     0x0a010005 | TIME                                   |      0.180753 |   5.430
     0x0a010006 | IRQS                                   |      0.004529 |   0.136
     0x0a010007 | swi1: netisr 0                         |      0.002570 |   0.077
     0x0a010008 | kqueue_ctx task                        |      0.000676 |   0.020
     0x0a010009 | swi5: fast task                        |      0.000059 |   0.001
     0x0a01000a | thread taskq                           |      0.000058 |   0.001
     0x0a01000b | swi6: task queu                        |      0.003285 |   0.098
     0x0a01000c | DHCP                                   |      0.274554 |   8.237
     0x0a01000d | FTPa                                   |      0.002210 |   0.066
     0x0a01000e | FTPb                                   |      0.000352 |   0.010
     0x0a01000f | FTPc                                   |      0.000240 |   0.007
     0x0a010010 | FTPd                                   |      0.000347 |   0.010
     0x0a010011 | FTPD                                   |      0.002903 |   0.087
     0x0a010012 | TNTD                                   |      0.001117 |   0.033
     0x0a010013 | SHLL                                   |      0.253692 |   7.599
    ------------+----------------------------------------+---------------+---------
     TIME SINCE LAST CPU USAGE RESET IN SECONDS:                          3.338494
    ------------------------------------------------------------------------------- 

    Before all the libbsd threads had the name "_BSD".

    Comment 4
    1. Joel Sherrill, Thu, 12 Jan 2017 16:18:27 GMT

    I am missing something in the code about how a Classic API task can have a string name.

    What about names for threads created using the new lightweight API? And do they show up in these lists.

    Comment 5
    1. Sebastian Huber, Thu, 12 Jan 2017 16:33:21 GMT

    See patch:

    ​https://lists.rtems.org/pipermail/devel/2017-January/016680.html

    The optional string name is accessible via Thread_Control::Join_queue::Queue::name.

    Comment 6
    1. Sebastian Huber, Fri, 13 Jan 2017 07:34:32 GMT

    In b8bcebea186e2d02334a014d5e792a0dde8007fc/rtems:

    score: Add and use _Objects_Name_to_string() Update #2858.
    Comment 7
    1. Sebastian Huber, Fri, 13 Jan 2017 07:34:42 GMT

    In 2b72162b81b33a9f5983feccadd8426a1ab6f950/rtems:

    score: Add Thread_queue_Queue::name Update #2858.
    Comment 8
    1. Sebastian Huber, Fri, 13 Jan 2017 07:34:52 GMT

    In 7ced9d9bb2fd51cfef2ce33d22e779adfed604c2/rtems:

    score: Add and use _Thread_Get_name() Update #2858.
    Comment 9
    1. Sebastian Huber, Fri, 13 Jan 2017 07:35:01 GMT

    In da6ad56a68676d68782ddcbd443a57337c84ee06/rtems:

    score: Add _Thread_Set_name() Add configuration option CONFIGURE_MAXIMUM_THREAD_NAME_SIZE. Update #2858.
    Comment 10
    1. Sebastian Huber, Fri, 13 Jan 2017 07:35:11 GMT

    In 7c49927911badda7907703568cadbcb2f1b7ef9d/rtems:

    posix: Add pthread_getname_np(), ... Add pthread_getname_np() and pthread_setname_np(). Update #2858.
    Comment 11
    1. Sebastian Huber, Fri, 13 Jan 2017 08:21:31 GMT

    In 172f2acb2b0ad183cb2360843e67aa86ca26a210/rtems-libbsd:

    Use thread name support Update #2858.
    Comment 12
    1. Sebastian Huber, Tue, 31 Jan 2017 09:11:16 GMT

    In e366f774a76d3607ad41dc0992e787ce38df980d/rtems:

    score: Add _Thread_queue_Object_name Add the special thread queue name _Thread_queue_Object_name to mark thread queues embedded in an object with identifier. Using the special thread state STATES_THREAD_QUEUE_WITH_IDENTIFIER is not reliable for this purpose since the thread wait information and thread state are protected by different SMP locks in separate critical sections. Remove STATES_THREAD_QUEUE_WITH_IDENTIFIER. Add and use _Thread_queue_Object_initialize(). Update #2858.
    Comment 13
    1. Sebastian Huber, Tue, 31 Jan 2017 09:11:57 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [40a1e80e6391418450157eb9e69aa8b796123aaa/rtems-docs]

    Comment 14
    1. Sebastian Huber, Tue, 14 Feb 2017 10:13:42 GMT

    In 468e9a4d99418a95657ab411d6557916d9f68bae/rtems:

    monitor: Print short and long task names Print wait object identifier only if it exists. Update #2858.
    Comment 15
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 16
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2859 - Implement POSIX Shared Memory Objects

    Link https://devel.rtems.org/ticket/2859
    Id 2859
    Reporter Gedare Bloom
    Created 13 January 2017 16:47:41
    Modified 9 November 2017 06:27:14
    Owner Gedare Bloom
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords POSIX-Compliance
    Cc  
    Blocking  
    Blocked by  

    Description

    POSIX Shared Memory is a widely used API for inter-process communication. The functions in the API include:

    • ​shm_open
    • ​ftruncate
    • ​mmap
    • ​munmap
    • ​shm_unlink
    • ​close
    • ​fstat
    • ​fchown
    • ​fchmod
    Comment 1
    1. Gedare Bloom, Fri, 13 Jan 2017 17:41:37 GMT

    ba77628250ae7158db363fc0d7886ebd43e9cb69

    Comment 2
    1. Sebastian Huber, Wed, 25 Jan 2017 12:33:07 GMT

    In 7cb7454f9321f9d68ad79c7bc21458755a4a6b46/rtems:

    psxtests: Relax shared memory tests There is currently no proper mmap() implementation. Update #2859.
    Comment 3
    1. Joel Sherrill, Tue, 04 Apr 2017 00:03:21 GMT
    2. keywords: POSIX-Compliance added; posix removed
    Comment 4
    1. Gedare Bloom, Fri, 05 May 2017 15:26:56 GMT

    In 87de70a2/rtems:

    posix/mman: add mmap support for shm objects Update #2859.
    Comment 5
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 6
    1. Kevin Kirspel, Fri, 14 Jul 2017 20:04:27 GMT

    In 1549beb/rtems:

    psxtests: Add a mmap dedicated test case Updates #2859
    Comment 7
    1. Sebastian Huber, Tue, 18 Jul 2017 12:22:46 GMT

    Test psxmmap01 fails with RTEMS_DEBUG:

    *** BEGIN OF TEST PSX MMAP01 ***
    Init: mmap - map at zero
    Breakpoint 1, __assert_func (file=file@entry=0x2027fc8 "../../cpukit/../../../erc32/lib/include/rtems/score/chainimpl.h", line=line@entry=686, func=func@entry=0x2029198 <__func__.2359> "_Chain_Append_unprotected", failedexpr=failedexpr@entry=0x20286e0 "_Chain_Is_node_off_chain( the_node )") at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/__assert.c:37
    37      {
    (gdb) bt
    #0  __assert_func (file=file@entry=0x2027fc8 "../../cpukit/../../../erc32/lib/include/rtems/score/chainimpl.h", line=line@entry=686, func=func@entry=0x2029198 <__func__.2359> "_Chain_Append_unprotected", failedexpr=failedexpr@entry=0x20286e0 "_Chain_Is_node_off_chain( the_node )") at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/__assert.c:37
    #1  0x0200d688 in _Chain_Append_unprotected (the_node=0x2039450, the_chain=0x202f650 ) at ../../cpukit/../../../erc32/lib/include/rtems/score/chainimpl.h:686
    #2  0x0200d720 in _Chain_Append_unprotected (the_node=0x2039450, the_chain=0x202f650 ) at ../../../../../../rtems/c/src/../../cpukit/sapi/src/chainprotected.c:74
    #3  rtems_chain_append (chain=chain@entry=0x202f650 , node=node@entry=0x2039450) at ../../../../../../rtems/c/src/../../cpukit/sapi/src/chainprotected.c:72
    #4  0x0200a634 in mmap (addr=addr@entry=0xfffff000, len=len@entry=4096, prot=prot@entry=7, flags=, flags@entry=4114, fildes=fildes@entry=-1, off=) at ../../../../../../rtems/c/src/../../cpukit/posix/src/mmap.c:373
    #5  0x020014cc in mmap_map_at_zero () at ../../../../../../../rtems/c/src/../../testsuites/psxtests/psxmmap01/init.c:100
    #6  POSIX_Init (argument=) at ../../../../../../../rtems/c/src/../../testsuites/psxtests/psxmmap01/init.c:324
    #7  0x0201be58 in _Thread_Entry_adaptor_pointer (executing=0x20318d8) at ../../../../../../rtems/c/src/../../cpukit/score/src/threadentryadaptorpointer.c:25
    #8  0x0201bed4 in _Thread_Handler () at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:88
    #9  0x0201be6c in _Thread_Handler () at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:38
    (gdb) frame 3
    #3  rtems_chain_append (chain=chain@entry=0x202f650 , node=node@entry=0x2039450) at ../../../../../../rtems/c/src/../../cpukit/sapi/src/chainprotected.c:72
    72        _Chain_Append_unprotected( chain, node );
    (gdb) p *node
    $1 = {
      next = 0x202f654 ,
      previous = 0x202f650 
    } 
    Comment 8
    1. Kevin Kirspel, Thu, 20 Jul 2017 05:30:57 GMT

    In bb01a36/rtems:

    Fixed issue with searching mapped addresses The loop that checks if the current address is already mapped uses the same local variable for the chanin node as the newly allocated chain node so the allocated chain node gets over written. Added a new local variable for the loop that checks the address Updates #2859.
    Comment 9
    1. Sebastian Huber, Thu, 20 Jul 2017 05:31:10 GMT

    In b965f461/rtems:

    posix: Use unprotected chain operations Operarations are already protected by mmap_mappings_lock. Updates #2859.
    Comment 10
    1. Sebastian Huber, Thu, 20 Jul 2017 05:33:50 GMT

    The mmap_mappings_lock attributes don't create a mutex:

    #define RTEMS_MUTEX_ATTRIBS \

    (RTEMS_PRIORITY | RTEMS_SIMPLE_BINARY_SEMAPHORE | \

    RTEMS_NO_INHERIT_PRIORITY | RTEMS_NO_PRIORITY_CEILING | RTEMS_LOCAL)

    I suggest to use the libio mutex and keep the specialized lock/unlock functions. Mutex lock/unlock should not return a status code to simplify the error handling.

    Comment 11
    1. Gedare Bloom, Mon, 24 Jul 2017 19:01:33 GMT

    In b264998/rtems:

    posix: replace mmap mappings lock with libio lock Use the libio mutex lock instead of the mmap mappings lock. Updates #2859.
    Comment 12
    1. Gedare Bloom, Mon, 24 Jul 2017 19:14:54 GMT

    In c6d897e5/rtems:

    posix: fix warnings with mmap from heap/wkspace Avoid void pointer arithmetic. Updates #2859.
    Comment 13
    1. Sebastian Huber, Fri, 28 Jul 2017 11:54:11 GMT

    In 77cbb2a/rtems:

    psxtests/psxmmap01: Fix warning Update #2859.
    Comment 14
    1. Gedare Bloom, Fri, 28 Jul 2017 19:16:13 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 1ab6d59/rtems-docs:

    memory_management: update mmap, munmap, shm_open, shm_unlink Close #2859.
    Comment 15
    1. Gedare Bloom, Fri, 28 Jul 2017 19:19:00 GMT

    I consider this basically complete. Open new tickets against any bugs or added features.

    Comment 16
    1. Sebastian Huber, Thu, 14 Sep 2017 05:03:21 GMT

    In 694e946/rtems:

    libio: Remove special-case reference count The top-level IO library structures should contain no special-case data. Update #2859.
    Comment 17
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 18
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2862 - docs.rtems.org Add support to ReST format releases.

    Link https://devel.rtems.org/ticket/2862
    Id 2862
    Reporter Chris Johns
    Created 14 January 2017 21:06:00
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add support to the releases section of the web site to handle ReST packages. The catalogues have a legacy field for texinfo docs.

    The 4.11.0 and 4.11.1 releases need to have a catalogue added because this did not exist when those releases were created.

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Chris Johns, Sun, 13 Aug 2017 23:39:26 GMT
    2. version: changed from 4.11 to 4.12
    Comment 3
    1. Chris Johns, Mon, 04 Sep 2017 03:29:05 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Fixed.

    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2863 - Update POSIX 1003.1 Compliance Guide for ReST

    Link https://devel.rtems.org/ticket/2863
    Id 2863
    Reporter Joel Sherrill
    Created 14 January 2017 23:24:09
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type enhancement
    Component doc
    Status closed
    Resolution duplicate
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The POSIX 1003.1 Compliance Guide should be auto-generated from a spreadsheet into the ReST format. My vague recollection is that we used shell scripts to do this for texinfo output.

    I will have to decipher what we used to do and define a new procedure.

    This impacts 4.11 and newer. One issue is having correct information for what methods are present on a branch. The FACE Conformance Test Suite can be used for ~800 of the methods.

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Chris Johns, Mon, 14 Aug 2017 00:14:07 GMT
    2. version: changed from 4.11 to 4.12

    What is the priority on this work and will be it available for the 4.12.0 milestone?

    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 4
    1. Joel Sherrill, Wed, 11 Oct 2017 23:45:37 GMT
    2. status: changed from new to closed
    3. resolution: set to duplicate

    This is a duplicate of #3177

    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2864 - docs.rtems.org Automatic update of branches content when a rtems-doc.git change is made.

    Link https://devel.rtems.org/ticket/2864
    Id 2864
    Reporter Chris Johns
    Created 15 January 2017 23:39:48
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity major
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add support to automatically update the branches when a git commit happens.

    Comment 1
    1. Amar Takhar, Mon, 16 Jan 2017 06:00:41 GMT

    You mean automatically build the docs when someone makes a commit to them?

    A little confused by the description. :)

    Comment 2
    1. Chris Johns, Mon, 16 Jan 2017 06:23:20 GMT
    2. summary: changed from docs.rtems.org Automatic update of branches. to docs.rtems.org Automatic update of branches content when a rtems-doc.git change is made.

    Replying to amar:

    You mean automatically build the docs when someone makes a commit to them?

    Yes and publish the build on the docs.rtems.org website. The website is driven off an XML catalogue created when building the docs so document changes, additions, renames and removals are handled within the built package.

    A little confused by the description. :)

    Sorry, I have amended the Summary. I hope this is better.

    I intend to build on sync.rtems.org when a hash on a branch changes, tar the content then transfer to docs.rtems.org. I have a script to manage the git hash checking and to build the content. A job on docs will pick up the new package and install it. All I need a way to move the package from sync to docs.

    Comment 3
    1. Amar Takhar, Mon, 16 Jan 2017 14:09:42 GMT

    I have already written something like this for the new docs.rtems.org. Incremental builds (by commit) and release builds.

    It needs to be managed properly, most projects overwrite their 'devel' documentation with new versions. I want to keep around every single built version for comparison this is more useful for contributors.

    Comment 4
    1. Chris Johns, Mon, 16 Jan 2017 22:42:15 GMT

    Replying to amar:

    I have already written something like this for the new docs.rtems.org. Incremental builds (by commit) and release builds.

    Release builds are part of the release process which is a separate from this web site. The released documents are loaded on the the web site and the website's configuration updated to include the release details and the site is regenerated.

    For building from git I was told to sort out building by cron so this is what I have done.

    Is it possible to set up a share on the TrueNAS to be a clearing house between sync and docs?

    It needs to be managed properly, most projects overwrite their 'devel' documentation with new versions.

    I am concerned it places extra stress on the limit resources we have so do not see holding builds as a priority. We have the source in git so someone can get that release and build it.

    I want to keep around every single built version for comparison this is more useful for contributors.

    How is this more useful for contributors?

    Comment 5
    1. Amar Takhar, Tue, 17 Jan 2017 00:15:53 GMT

    Replying to chrisj:

    Release builds are part of the release process which is a separate from this web site. The released documents are loaded on the the web site and the website's configuration updated to include the release details and the site is regenerated.

    They'll all be built from the same location using the same tools and same process the only difference is one will be a tag and the other a branch. If you are talking about what 'triggers' a build then yes they are different.

    For building from git I was told to sort out building by cron so this is what I have done.

    Is it possible to set up a share on the TrueNAS to be a clearing house between sync and docs?

    How long is this going to be setup for? I suggested this before you mentioned building after every commit...

    It needs to be managed properly, most projects overwrite their 'devel' documentation with new versions.

    I am concerned it places extra stress on the limit resources we have so do not see holding builds as a priority. We have the source in git so someone can get that release and build it.

    Space isn't an issue it will be a decade worth of builds before it will be a problem.

    The other nice feature is if someone builds from a commit in source they'll have the corresponding documentation available that is as close to that version as possible -- I have a way to track this it's a tool I wrote some time ago.

    I want to keep around every single built version for comparison this is more useful for contributors.

    How is this more useful for contributors?

    Not all errors are build errors some are formatting/syntax. Lots of contributors don't have the ability to build docs from source -- I don't think that is a pre requisit to make changes since they need to be tested before commit anyway.

    Docs are unique in that regard.

    Comment 6
    1. Joel Sherrill, Tue, 17 Jan 2017 01:40:43 GMT

    What is the problem with providing a way to get content from a "build jail" to a "offer to the world jail"? AFAIK all solutions include either making a directory on the TrueNAS available to the "offer to the world jail" or push via ssh. Please help Chris.

    Providing this path from "build to "offer to the world" is not an unusual requirement. It is needed for multiple offerings.

    There is negative value in keeping builds of documentation on every commit.

    Comment 7
    1. Chris Johns, Tue, 17 Jan 2017 05:14:41 GMT

    Replying to amar:

    Replying to chrisj:

    Release builds are part of the release process which is a separate from this web site. The released documents are loaded on the the web site and the website's configuration updated to include the release details and the site is regenerated.

    They'll all be built from the same location using the same tools and same process the only difference is one will be a tag and the other a branch. If you are talking about what 'triggers' a build then yes they are different.

    I am not sure if we are saying the same thing or not.

    A release of RTEMS contains released documentation and the formally released procedure creates that tar file of documentation. The rtems-release.git repo contains the format release scripts. Released documentation must be created as part of that formal release procedure.

    For building from git I was told to sort out building by cron so this is what I have done.

    Is it possible to set up a share on the TrueNAS to be a clearing house between sync and docs?

    How long is this going to be setup for?

    I am sorry I have no idea how long. I am just wanting to fill a gap that currently exists as best I can. I am after a simple, secure method to complete this task. As Joel says, if a simple solution can be found and this can be done that would be excellent. We would also be free to move on and sort other issues out, eg buildbot of the RTEMS code, new website, etc and we can come back to this when we have time, funding etc. We are working hard and openly to try to get this to happen but is hard.

    I suggested this before you mentioned building after every commit...

    I did not know sphinx could not be installed on docs.rtems.org and the docs built in that jail. I just assumed the docs could be built on each commit on docs.rtems.org. When I looked at the jail I saw you had installed tex alive and other packages and you had been building documentation there.

    It needs to be managed properly, most projects overwrite their 'devel' documentation with new versions.

    I am concerned it places extra stress on the limit resources we have so do not see holding builds as a priority. We have the source in git so someone can get that release and build it.

    Space isn't an issue it will be a decade worth of builds before it will be a problem.

    The other nice feature is if someone builds from a commit in source they'll have the corresponding documentation available that is as close to that version as possible -- I have a way to track this it's a tool I wrote some time ago.

    Sorry, I do not follow. How would someone with a local build compare and what would the value be in doing this?

    I want to keep around every single built version for comparison this is more useful for contributors.

    How is this more useful for contributors?

    Not all errors are build errors some are formatting/syntax. Lots of contributors don't have the ability to build docs from source -- I don't think that is a pre requisit to make changes since they need to be tested before commit anyway.

    Docs are unique in that regard.

    We have been testing on a number of hosts and it builds ok. I have not built PDF on OS X as tex alive is too hard without something like brew or macports, HTML works.

    Comment 8
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 9
    1. Chris Johns, Sun, 13 Aug 2017 23:40:11 GMT
    2. version: changed from 4.11 to 4.12
    Comment 10
    1. Chris Johns, Mon, 04 Sep 2017 01:06:13 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Commits update master and the release branch.

    Comment 11
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 12
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2865 - Coverpage installed when building the docs repeats catalogue.xml entries

    Link https://devel.rtems.org/ticket/2865
    Id 2865
    Reporter Chris Johns
    Created 16 January 2017 00:07:24
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The catalogue repeats entries.

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Chris Johns, Fri, 11 Aug 2017 03:46:53 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In feb6832/rtems-docs:

    coverpage: Fix repeated entries. Closes #2865.
    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2867 - Fix exclude rule in rtems-test-check

    Link https://devel.rtems.org/ticket/2867
    Id 2867
    Reporter Stavros Passas
    Created 16 January 2017 15:37:30
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority low
    Severity minor
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    rtems-test-check is responsible of checking the testsuite configuration of a given BSP and adapt it based on a given "command". Currently for the "exclude" command, we never exclude anything, the output of the script is always the whole list of the input tests.

    This happens because the script always starts with output = $tests and appends on the list the tests that are not excluded, so the output is always all the tests.

    Attachments:

    1 Stavros Passas, Mon, 16 Jan 2017 15:44:43 GMT
      attach: set to fix-2867.patch
     
    Comment 1
    1. Stavros Passas, Mon, 16 Jan 2017 15:48:37 GMT

    I attached a simple fix that would solve the described issue. The issue is created because we want to provide a full list of tests in case the exclude file from the BSP is non-existing, thus a simple fix would be to start with an empty list if the BSP file exists, or with a full list there is nothing to exclude.

    Comment 2
    1. Joel Sherrill, Mon, 16 Jan 2017 17:08:47 GMT

    Thanks. I had reported that a LOT of BSPs failed to complete building all tests but hadn't tracked it down completely. I am testing this patch. Does it look OK?

    index e02f8e9..218d1f0 100755 --- a/tools/build/rtems-test-check +++ b/tools/build/rtems-test-check [joel@rtbf64c rtems]$ git diff tools/ diff --git a/tools/build/rtems-test-check b/tools/build/rtems-test-check index e02f8e9..218d1f0 100755 --- a/tools/build/rtems-test-check +++ b/tools/build/rtems-test-check @@ -32,7 +32,7 @@ done

    case ${mode} in

    exclude)

    output=${tests}

    + output=

    ;;

    flags)

    if [ $test_count != 1 ]; then

    Comment 3
    1. Stavros Passas, Mon, 16 Jan 2017 17:21:06 GMT

    Hi Joel, no this will not work, because for the BSPs that do not have an exclude testsuite list, the output will be returned immediately as ${output} (that will be ""), and the BSP will not compile any test!

    Comment 4
    1. Joel Sherrill, Mon, 16 Jan 2017 18:23:31 GMT

    Unfortunately, it looks like this script has grown complicated enough where some test cases are needed that are independent of the BSPs and testsuite.

    I will try to look at it some more but am assigning this to Chris since he wrote the script.

    Comment 5
    1. Joel Sherrill, Mon, 16 Jan 2017 18:23:55 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 6
    1. Joel Sherrill, Mon, 16 Jan 2017 19:25:48 GMT

    I posted a patch to devel which works for gensh1 (has .tcfg file with excludes) and pc686 which doesn't have a .tcfg file. I will build all BSPs before I consider pushing this.

    Feedback appreciated.

    Comment 7
    1. Joel Sherrill, Wed, 18 Jan 2017 00:06:34 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    I have built all BSPs with your patch and my additions to some .tcfg files.

    The only BSPs with build issues are those which are gcc < 5.0 due to using restrict and not restrict in devctl.h. This is fixed in newlib and the next newlib snapshot and tool bump will fix those.

    Reopen if you think this isn't OK.

    Comment 8
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2868 - src/c/src/lib/libbsp/arm/smdk2410/smc/smc.c: 3 &#42 pointless local variables ?

    Link https://devel.rtems.org/ticket/2868
    Id 2868
    Reporter David Binderman
    Created 16 January 2017 17:01:57
    Modified 9 November 2017 06:27:14
    Owner Gedare Bloom <gedare@…>
    Type enhancement
    Component arch/arm
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority lowest
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    [src/c/src/lib/libbsp/arm/smdk2410/smc/smc.c:235]: (style) Variable 'cnt1' is modified but its new value is never used.
    [src/c/src/lib/libbsp/arm/smdk2410/smc/smc.c:243]: (style) Variable 'cnt2' is modified but its new value is never used.
    [src/c/src/lib/libbsp/arm/smdk2410/smc/smc.c:246]: (style) Variable 'cnt3' is modified but its new value is never used.

    $ egrep "cnt1|cnt2|cnt3" src/c/src/lib/libbsp/arm/smdk2410/smc/smc.c

    uint32_t pblock, i, j, lblock, zone, count, cnt1, cnt2, cnt3;
    cnt1 = 0;
    cnt2 = 0;
    cnt3 = 0;

    cnt1++;

    cnt2++;
    cnt3++;

    $

    Maybe someone left some debug code in ?

    Comment 1
    1. Gedare Bloom, Thu, 19 Jan 2017 18:00:50 GMT
    2. owner: set to Gedare Bloom <gedare@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 3f09d6354899f032958cbc44e49c7ee99175df27/rtems:

    smdk2410: delete unused variables Closes #2868.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Mon, 16 Oct 2017 06:24:30 GMT
    2. component: changed from unspecified to arch/arm
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2873 - src/c/src/lib/libbsp/arm/raspberrypi/i2c/i2c.c:320: defective error checking ?

    Link https://devel.rtems.org/ticket/2873
    Id 2873
    Reporter David Binderman
    Created 19 January 2017 19:59:10
    Modified 9 November 2017 06:27:14
    Owner Gedare Bloom <gedare@…>
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    src/c/src/lib/libbsp/arm/raspberrypi/i2c/i2c.c:320]: (style) Checking if unsigned variable 'rv' is less than zero.

    Source code is

    rv = rpi_i2c_setup_transfer(bus);

    if ( rv < 0 ) {

    but

    uint32_t rv = 0;

    and

    static int rpi_i2c_setup_transfer(rpi_i2c_bus *bus)

    Suggest put return value into an int local variable, then
    sanity check it, then assign it to rv.

    Comment 1
    1. Gedare Bloom, Thu, 19 Jan 2017 20:35:03 GMT
    2. owner: set to Gedare Bloom <gedare@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 70e8abf3917c93ab085ca77fee379df9fa000183/rtems:

    raspberrypi: use signed int for return variable Closes #2873.
    Comment 2
    1. Joel Sherrill, Sun, 05 Feb 2017 02:07:37 GMT

    This ticket is closed but I would like to know what you are running to spot these issues and what settings.

    I would like to make sure that eventually we are running the same thing as a project. I would have emailed directly but couldn't find your email.

    Thanks.

    --joel

    Comment 3
    1. David Binderman, Sun, 05 Feb 2017 09:06:38 GMT

    I would like to know what you are running to spot these issues and what settings.

    I run a static C / C++ analyser called cppcheck, available from sourceforge.

    ​http://cppcheck.sourceforge.net/

    The latest released version would probably work ok, but I use the current development version. I use flag --enable=all and I've tweeked the source of cppcheck as well.

    BTW, if I could figure out how to build rtems on Linux, then I could run the latest development versions of clang and gcc over rtems and possibly get some interesting warnings.

    I would like to make sure that eventually we are running the same thing as a project.

    I have been doing this myself for about a year or so. I'd be more than happy to help and share my results.

    I would have emailed directly but couldn't find your email.

    dcb 314 at hotmail dot com. Feel free to chat offline.

    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Mon, 16 Oct 2017 06:24:30 GMT
    2. component: changed from unspecified to arch/arm
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2874 - src/c/src/lib/libbsp/powerpc/beatnik/marvell/gt_timer.c: 4 &#42 pointless check ?

    Link https://devel.rtems.org/ticket/2874
    Id 2874
    Reporter David Binderman
    Created 19 January 2017 20:52:11
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber <sebastian.huber@…>
    Type enhancement
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority lowest
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    [src/c/src/lib/libbsp/powerpc/beatnik/marvell/gt_timer.c:102]: (style) Checking if unsigned variable 'timer' is less than zero.
    [src/c/src/lib/libbsp/powerpc/beatnik/marvell/gt_timer.c:109]: (style) Checking if unsigned variable 'timer' is less than zero.
    [src/c/src/lib/libbsp/powerpc/beatnik/marvell/gt_timer.c:117]: (style) Checking if unsigned variable 'timer' is less than zero.
    [src/c/src/lib/libbsp/powerpc/beatnik/marvell/gt_timer.c:128]: (style) Checking if unsigned variable 'timer' is less than zero.

    Parameter "timer" is only ever type uint32_t, so any check < 0 seem pointless.

    Comment 1
    1. Sebastian Huber, Fri, 20 Jan 2017 13:23:31 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In e8606d5b90048b9a5feba09430ac356c422eee7d/rtems:

    bsp/beatnik: Remove superfluous check Close #2874.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Mon, 16 Oct 2017 06:25:10 GMT
    2. component: changed from unspecified to arch/powerpc
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2877 - DHCP client fails on complex networks

    Link https://devel.rtems.org/ticket/2877
    Id 2877
    Reporter Stavros Passas
    Created 20 January 2017 09:21:28
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords dhcp
    Cc  
    Blocking  
    Blocked by  

    Description

    What happens is that on networks with more than one DHCP servers, or on networks that use multiple vlans it can happen that After a DHCP discover our client broadcasts, it receives multiple offers, which is perfectly fine based on the DHCP RFC.

    However our implementation of a DHCP client, expects a linear execution flow:

  • Broadcast a DHCP discover;
  • Wait for a DHCP offer;
  • Transmit a DHCP request;
  • Wait for a DHCP ack;
  • However the network stack is not cleaned between the reception of a DHCP offer and a DHCP ack, so if multiple offers are received, just the first one will be processed during the "Receive DHCP offer" phase, and the next one will be received when we expect a "DHCP ack", which makes our implementation assume the DHCP handshake is invalid and fail. Thus we restart the network and retry the whole process from the beginning which will cause the same issue again.

    This issue that is present from when I remember in RTEMS, definitely from 4.10 up to now.

    Attachments:

    1 Stavros Passas, Fri, 20 Jan 2017 09:33:28 GMT
      attach: set to fix-2877.patch
    Comment 1
    1. Sebastian Huber, Fri, 20 Jan 2017 09:25:37 GMT

    The DHCP client used by libbsd is probably not affected by this problem.

    Comment 2
    1. Stavros Passas, Fri, 20 Jan 2017 09:27:16 GMT

    Correct, this affects just cpukit/libnetworking/rtems/rtems_dhcp.c

    Comment 3
    1. Stavros Passas, Fri, 20 Jan 2017 09:33:55 GMT

    I attach a file with a proposed fix for this DHCP client. mainly what the fix does is extend bootp_call to be able to expect a specific message as response. If it receives any other message, it will just ignore it, and it will timeout as it is expected to do in the first place.

    Then with the extended bootp_call, I extended the dhcp client implementation to strictly expect a dhcp offer after a discover message and a DHCP ack after a request message. This way, the DHCP protocol does not fail if there are multiple DHCP messages on the network and it will finish successfully a DHCP handshake even when multiple messages are received from our client.

    Comment 4
    1. Stavros Passas, Fri, 20 Jan 2017 14:07:39 GMT
    2. owner: set to joel.sherrill@…
    3. component: changed from General to cpukit
    Comment 5
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 6
    1. Stavros Passas, Thu, 08 Jun 2017 08:07:18 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 2585347/rtems:

    network: Fix DHCP client protocol Close #2877.
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2878 - src/c/src/lib/libbsp/sparc/shared/can/occan.c:1573: broken error checking ?

    Link https://devel.rtems.org/ticket/2878
    Id 2878
    Reporter David Binderman
    Created 20 January 2017 14:14:06
    Modified 9 November 2017 06:27:14
    Owner Daniel Hellstrom
    Type defect
    Component arch/sparc
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    src/c/src/lib/libbsp/sparc/shared/can/occan.c:1573]: (style) Checking if unsigned variable 'speed=pelican_speed_auto(can)' is less than zero.

    Source code is

    if ( (speed=pelican_speed_auto(can)) < 0 ){

    /* failed */
    return RTEMS_IO_ERROR;

    }

    but

    unsigned int speed;

    and

    static int pelican_speed_auto(occan_priv *priv);

    I am not sure which C compiler gets using in rtems, but I do
    know that gcc compiler flag -Wtype-limits will flag this
    kind of problem.

    Comment 1
    1. Sebastian Huber, Fri, 20 Jan 2017 14:14:52 GMT
    2. owner: set to Daniel Hellstrom
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Daniel Hellstrom, Tue, 22 Aug 2017 08:35:33 GMT

    Hi, This might not generated a warning because it is part of dead code that will never be reached due to the return statement just above. I have made a patch to remove this dead code, it will close this ticket.

    Comment 4
    1. Daniel Hellstrom, Wed, 30 Aug 2017 10:40:05 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Fixed by 3471d3da25de4e706f4cdb09d93a4de4e54455df

    Comment 5
    1. Sebastian Huber, Mon, 16 Oct 2017 06:23:46 GMT
    2. component: changed from unspecified to arch/sparc
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2879 - src/cpukit/libdebugger/rtems-debugger-server.c: four problems

    Link https://devel.rtems.org/ticket/2879
    Id 2879
    Reporter David Binderman
    Created 23 January 2017 17:41:53
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    1.

    src/cpukit/libdebugger/rtems-debugger-server.c:1306]: (style) Redundant condition: extended. '!extended || (extended && check_pid(pid))' is equivalent to '!extended || check_pid(pid)' 

    Suggest simplify.

    2.

    src/cpukit/libdebugger/rtems-debugger-server.c:1858]: (warning) Possible null pointer dereference: rtems_debugger 

    Source code is

     if (r < 0) {
    rtems_printf(printer, "error: rtems-db: remote begin: %s: %s\n",
    rtems_debugger->remote->name, strerror(errno));
    free(rtems_debugger);
    rtems_debugger = NULL;
    }
    /*
    * Reset at the end of the session.
    */
    rtems_debugger->flags = 0;

    Suggest adding return -1 inside the if.

    3.

    src/cpukit/libdebugger/rtems-debugger-server.c:906]: (style) Redundant condition: extended. '!extended || (extended && check_pid(pid))' is equivalent to '!extended || check_pid(pid)' 

    Duplicate.

    4.

    src/cpukit/libdebugger/rtems-debugger-server.c:956]: (warning) Char literal compared with pointer 'p'. Did you intend to dereference it? 

    Source code is

     while (p != NULL && p != '\0') { 

    Maybe better code

     while (p != NULL && *p != '\0') { 
    Comment 1
    1. Chris Johns, Mon, 23 Jan 2017 23:05:49 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to accepted
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Chris Johns, Sun, 16 Jul 2017 23:41:37 GMT
    2. description: modified (diff)

    Update formatting to show the code fragments.

    Comment 4
    1. Chris Johns, Mon, 07 Aug 2017 23:34:21 GMT
    2. version: changed from 4.11 to 4.12
    3. component: changed from General to cpukit
    Comment 5
    1. Chris Johns, Tue, 15 Aug 2017 01:40:37 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In b2353ed9/rtems:

    libdebugger: Fixes to debugging, ARM support, locking, and gcc-7.1 warnings. Add printk support to aid multi-core debugging. Add lock trace to aid lock debugging. Fixes to gcc-7.1 warnings. Fixes from ticket #2879. Add verbose command controls. Change using the RTEMS sys/lock.h API to manage exception threads. ARM hardware breakpoint fixes. Support for SMP stepping is not implemented, this requires use of the context id register. Closes #2879.
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2880 - src/cpukit/libfs/src/jffs2/src/readinode.c:189: faulty logic

    Link https://devel.rtems.org/ticket/2880
    Id 2880
    Reporter David Binderman
    Created 23 January 2017 17:46:08
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component unspecified
    Status closed
    Resolution wontfix
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    src/cpukit/libfs/src/jffs2/src/readinode.c:189]: (style) Condition 'tn.fn.ofs>=offset' is always true

    Source code is

    if (tn->fn->ofs < offset)

    next = tn->rb.rb_right;

    else if (tn->fn->ofs >= offset)

    next = tn->rb.rb_left;

    else

    break;

    Maybe better code

    if (tn->fn->ofs < offset)

    next = tn->rb.rb_right;

    else if (tn->fn->ofs > offset)

    next = tn->rb.rb_left;

    else

    break;

    Comment 1
    1. Sebastian Huber, Tue, 24 Jan 2017 06:32:03 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    This code block is identical to the Linux upstream.

    Comment 2
    1. David Binderman, Tue, 24 Jan 2017 08:18:51 GMT

    I've reported this strange code to the linux developers.

    Comment 3
    1. Sebastian Huber, Tue, 24 Jan 2017 08:20:57 GMT

    The JFFS2 code should be updated to a specific Linux version in one rush.

    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2883 - src/c/src/lib/libbsp/arm/tms570/console/tms570-sci.c:248: strange expression ?

    Link https://devel.rtems.org/ticket/2883
    Id 2883
    Reporter David Binderman
    Created 23 January 2017 19:08:50
    Modified 9 November 2017 06:27:14
    Owner Pavel Pisa
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    src/c/src/lib/libbsp/arm/tms570/console/tms570-sci.c:248]: (style) Same expression on both sides of '|'.

    Source code is

    uint32_t flr_tx_ready = TMS570_SCI_FLR_TX_EMPTY | TMS570_SCI_FLR_TX_EMPTY;

    Comment 1
    1. Sebastian Huber, Tue, 24 Jan 2017 06:41:28 GMT
    2. owner: set to Pavel Pisa
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Joel Sherrill, Thu, 12 Oct 2017 17:38:41 GMT

    Ping Paval. Any idea what this line of code should be?

    Comment 4
    1. Pavel Pisa, Thu, 12 Oct 2017 23:03:14 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In f4009d8/rtems:

    bsp/tms570: remove duplicate of TMS570_SCI_FLR_TX_EMPTY in console driver. Initial idea has been that check for both, TMS570_SCI_FLR_TX_EMPTY and TMS570_SCI_FLR_TXRDY is required before console driver parameters update. closes #2883.
    Comment 5
    1. Sebastian Huber, Mon, 16 Oct 2017 06:24:30 GMT
    2. component: changed from unspecified to arch/arm
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2885 - Fix rtems_rate_monotonic_postponed_job_count() prototype

    Link https://devel.rtems.org/ticket/2885
    Id 2885
    Reporter Sebastian Huber
    Created 24 January 2017 14:01:10
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    rtems_rate_monotonic_postponed_job_count() should return an RTEMS status code. It should be renamed to rtems_rate_monotonic_get_postponed_job_count() or rtems_rate_monotonic_get_postponed_jobs() (similar to rtems_rate_monotonic_get_statistics()).

    Comment 1
    1. Sebastian Huber, Tue, 24 Jan 2017 14:13:27 GMT

    There is no test case for this function.

    Comment 2
    1. Kuan-Hsun Chen, Tue, 24 Jan 2017 15:44:34 GMT

    I think we should rename it as rtems_rate_monotonic_get_postponed_job_count(uint32_t *count), though the name is really long. The RTEMS status codes could be: RTEMS_SUCCESSFUL - count returned successfully RTEMS_INVALID_ID - invalid rate monotonic period id RTEMS_INVALID_ADDRESS - invalid address of count

    Comment 3
    1. Sebastian Huber, Wed, 25 Jan 2017 06:28:28 GMT

    My preferred option: just add this to rtems_rate_monotonic_period_status and return it via rtems_rate_monotonic_get_status().

    Comment 4
    1. Kuan-Hsun Chen, Wed, 25 Jan 2017 08:28:16 GMT

    I can do this. I will add the count into the structure of rtems_rate_monotonic_period_status, remove rtems_rate_monotonic_get_postponed_job_count(), and extend rtems_rate_monotonic_get_status().

    Comment 5
    1. Kuan-Hsun Chen, Wed, 25 Jan 2017 13:19:19 GMT

    Sp69 is also planned to be updated, which is the test for rtems_rate_monotonic_get_status()

    Comment 6
    1. Kuan-Hsun Chen, Mon, 30 Jan 2017 06:53:30 GMT

    In 0794197f729f5ee9551dc7b2e14867f394cbc327/rtems:

    rtems: Fix _Rate_monotonic_Renew_deadline() Prepare a precondition to prevent the potential integer overflow. Remove one redundant parameter in _Rate_monotonic_Renew_deadline(). sptests/sprmsched02: Create A test case for checking the overflow condition of postponed_jobs in rtems_rate_monotonic_period_status. Update #2885.
    Comment 7
    1. Sebastian Huber, Mon, 30 Jan 2017 07:06:48 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 8
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2889 - RTEMS_STACK_CHECKER_EXTENSION has incomplete definition

    Link https://devel.rtems.org/ticket/2889
    Id 2889
    Reporter Stavros Passas
    Created 30 January 2017 10:40:08
    Modified 9 November 2017 06:27:14
    Owner Stavros Passas <stavros.passas@…>
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority low
    Severity trivial
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The extension for the stack checker defines 8 entries, while the structure for RTEMS extensions gets 9 arguments. This causes warnings to appear on applications compiled with -Werror, or similar flags.

    The handler that is missing is for the terminate callback, so a 0 entry would be enough to fix this error.

    Attachments:

    1 Stavros Passas, Mon, 30 Jan 2017 10:41:26 GMT
      attach: set to 2889-Complete-STACK_CHECKER_EXTENSION.patch
     
    Comment 1
    1. Stavros Passas, Mon, 30 Jan 2017 10:41:53 GMT

    Fix attached.

    Comment 2
    1. Stavros Passas, Mon, 30 Jan 2017 10:51:12 GMT
    2. owner: set to Stavros Passas <stavros.passas@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 575c2e21e25db83a5a8d83d2f4062e0f39f18c46/rtems:

    Complete STACK_CHECKER_EXTENSION. Fixes #2889
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2890 - _RBTree_Initialize_node generates warnings

    Link https://devel.rtems.org/ticket/2890
    Id 2890
    Reporter Stavros Passas
    Created 30 January 2017 11:06:39
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber <sebastian.huber@…>
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority low
    Severity trivial
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Currently, when _RBTree_Initialize_node is used, it generates warnings of unused variables. I traced the issue down to the variable being used only if RTEMS_DEBUG is set.

    Thus, the argument should be marked as RTEMS_UNUSED, if RTENS_DEBUG is not set.

    Attachments:

    1 Stavros Passas, Mon, 30 Jan 2017 11:07:39 GMT
      attach: set to 2890-Avoid-warnings-on-_RBTree_Initialize_node.patch
     
    Comment 1
    1. Stavros Passas, Mon, 30 Jan 2017 11:08:39 GMT

    Suggested fix attached.

    Comment 2
    1. Sebastian Huber, Mon, 30 Jan 2017 11:30:42 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In c5430e0618fbe1517417a0b353c12924a8934554/rtems:

    score: Fix unused parameter warning Close #2890.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2893 - Remove CONFIGURE_SMP_APPLICATION

    Link https://devel.rtems.org/ticket/2893
    Id 2893
    Reporter Sebastian Huber
    Created 1 February 2017 10:42:14
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component config
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    SMP support must be enabled with the CONFIGURE_SMP_APPLICATION configuration option. Remove this option and enable the SMP support if CONFIGURE_SMP_MAXIMUM_PROCESSORS > 1.

    Comment 1
    1. Sebastian Huber, Wed, 01 Feb 2017 10:45:53 GMT
    2. version: changed from 4.12 to 4.11
    Comment 2
    1. Sebastian Huber, Thu, 02 Feb 2017 08:10:05 GMT

    In f95fa38764c007459cb0bd62a67e83a442f55433/rtems:

    Remove CONFIGURE_SMP_APPLICATION Enable the SMP support if CONFIGURE_SMP_MAXIMUM_PROCESSORS > 1. Update #2893.
    Comment 3
    1. Sebastian Huber, Fri, 03 Feb 2017 12:30:33 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [1f3c22e7868b14482df287656e602e17ccac4adc/rtems-docs]

    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Tue, 10 Oct 2017 06:13:34 GMT
    2. component: changed from SMP to config
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2894 - Rename CONFIGURE_SMP_MAXIMUM_PROCESSORS to CONFIGURE_MAXIMUM_PROCESSORS

    Link https://devel.rtems.org/ticket/2894
    Id 2894
    Reporter Sebastian Huber
    Created 1 February 2017 10:43:36
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component config
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Rename CONFIGURE_SMP_MAXIMUM_PROCESSORS to CONFIGURE_MAXIMUM_PROCESSORS since the SMP part is superfluous.

    Comment 1
    1. Sebastian Huber, Tue, 14 Feb 2017 09:21:26 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    4. component: changed from Documentation to SMP

    [1d073c538527a196cc35dab9d4ff6892e70d770d/rtems-docs]

    Comment 2
    1. Sebastian Huber, Tue, 14 Feb 2017 10:13:04 GMT

    In 54835ae9b35a595099c22e764bce86dc74d57317/rtems:

    Rename CONFIGURE_SMP_MAXIMUM_PROCESSORS Rename CONFIGURE_SMP_MAXIMUM_PROCESSORS to CONFIGURE_MAXIMUM_PROCESSORS since the SMP part is superfluous. Update #2894.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:13:34 GMT
    2. component: changed from SMP to config
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2895 - Prefix the confdefs.h internal defines with an underscore

    Link https://devel.rtems.org/ticket/2895
    Id 2895
    Reporter Sebastian Huber
    Created 1 February 2017 10:45:13
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component config
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Prefix the confdefs.h internal defines with an underscore to simplify the review of this extremely complex header file.

    Comment 1
    1. Chris Johns, Wed, 01 Feb 2017 23:51:32 GMT

    Could you please provide more detail about this change, why it helps and the user impact?

    Thanks

    Comment 2
    1. Sebastian Huber, Thu, 02 Feb 2017 05:45:24 GMT

    It is common practice in RTEMS to prefix internal things with an underscore. The confdefs.h header file became quite complex over time. It uses a lot of internal defines and up to now everything starts with CONFIGURE_*. It has no user impact. It helps to identify undocumented configuration options.

    Comment 3
    1. Sebastian Huber, Tue, 14 Feb 2017 08:45:07 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [07d71279b46142147f73b00ea8b1731e868e484a/rtems]

    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2896 - RSB requirements are missing pax

    Link https://devel.rtems.org/ticket/2896
    Id 2896
    Reporter Joel Sherrill
    Created 1 February 2017 16:46:49
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution wontfix
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Loading a new VM, I noticed that pax is needed. It isn't mentioned in the RSB manual at all.

    I can only accurately fix this for Centos 7 but we can safely assume that advice applies to Centos 6, Fedora, and RHEL.

    Can users of other distributions check about pax. Please

    Comment 1
    1. Joel Sherrill, Wed, 01 Feb 2017 16:47:05 GMT
    2. owner: set to Chris Johns
    3. component: changed from General to RSB
    Comment 2
    1. Chris Johns, Wed, 01 Feb 2017 23:43:03 GMT

    The RSB needs a better way to manage this type of problem as well as packages.

    It a reasonably sized change which will have to happen. I do not think it can be avoided anymore.

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Chris Johns, Mon, 14 Aug 2017 00:16:05 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    I need patches to the documentation to fix this.

    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2897 - Update termios.h to match the latest FREEBSD definitions

    Link https://devel.rtems.org/ticket/2897
    Id 2897
    Reporter Kevin Kirspel
    Created 1 February 2017 21:27:35
    Modified 9 November 2017 06:27:14
    Owner Needs Funding
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The FREEBSD struct termios separates out the input and output baud rates into individual speed_t variables. It also supports more flag options. The big benefit is that the rtems-libbsd tty code can be ported cleanly without the need to fixup the input and output baud rates. This should be a transparent change unless someone was manipulating the baud rates directly through the c_cflags (not using the cfgetispeed, cfgetospeed, cfsetispeed, cfsetospeed functions).

    Attachments:

    1 Kevin Kirspel, Wed, 01 Feb 2017 21:28:10 GMT
      attach: set to 0001-remove-files-that-are-no-longer-needed-in-libnetwork.patch
    2 Kevin Kirspel, Wed, 01 Feb 2017 21:28:27 GMT
      attach: set to 0002-Updating-termios-headers-to-latest-FREEBSD-verion.patch
    3 Kevin Kirspel, Wed, 01 Feb 2017 21:29:10 GMT
      attach: set to log_xilinx_zynq_a9_qemu_net.log
     
    4 Kevin Kirspel, Thu, 02 Feb 2017 23:00:55 GMT
      attach: set to 0001-Adding-new-files-for-inclusion-of-FREEBSD-termios-fe.patch
     
    5 Kevin Kirspel, Thu, 02 Feb 2017 23:01:34 GMT
      attach: set to 0002-Updating-termios-to-support-FREEBSD-struct-termios.-.patch
     
    6 Kevin Kirspel, Thu, 02 Feb 2017 23:01:55 GMT
      attach: set to 0003-test-suites-are-updated-to-reflect-the-changes-made-.patch
     
    7 Kevin Kirspel, Thu, 02 Feb 2017 23:02:12 GMT
      attach: set to 0004-tools-was-updated-to-reflect-the-changes-made-to-ter.patch
     
    8 Kevin Kirspel, Thu, 02 Feb 2017 23:03:23 GMT
      attach: set to log_xilinx_zynq_a9_qemu.log
     
    Comment 1
    1. Kevin Kirspel, Wed, 01 Feb 2017 21:52:39 GMT

    Ignore the patches and test log. I accidently configured on the wrong tree. I'll post new patches soon.

    Comment 2
    1. Kevin Kirspel, Thu, 02 Feb 2017 23:00:00 GMT

    I have made the modifications to termios. There were a bunch of files to change in the BSPs to use the new baud rate fields. I think I updated all the necessary BSPs. I only tested the xilinx_zynq_a9_qemu BSP. I am attaching the patch file and testsuite log.

    Comment 3
    1. Sebastian Huber, Wed, 15 Feb 2017 14:20:42 GMT
    2. owner: set to Needs Funding
    3. status: changed from new to assigned
    4. milestone: changed from 4.12 to Indefinite
    Comment 4
    1. Kevin Kirspel, Wed, 22 Mar 2017 10:57:26 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 1c6926c1/rtems:

    termios: Synchronize with latest FreeBSD headers Adding modified FreeBSD headers to synchronize RTEMS termios with FreeBSD. Modify termios to support dedicated input and output baud for termios structure. Updated BSPs to use dedicated input and output baud in termios structure. Updated tools to use dedicated input and output baud in termios structure. Updated termios testsuites to use dedicated input and output baud in termios structure. Close #2897.
    Comment 5
    1. Sebastian Huber, Wed, 22 Mar 2017 10:59:48 GMT
    2. milestone: changed from Indefinite to 4.12
    Comment 6
    1. Sebastian Huber, Mon, 27 Mar 2017 08:31:35 GMT

    In 94a4865/rtems:

    termios: Avoid invalid memory access Update #2897.
    Comment 7
    1. Sebastian Huber, Mon, 27 Mar 2017 13:39:05 GMT

    In 5f382713/rtems:

    cpukit: Fix Makefile.am and update preinstall.am Update #2897.
    Comment 8
    1. Sebastian Huber, Mon, 03 Apr 2017 12:08:49 GMT

    In 1301468/rtems:

    bsps: Fix baud settings Update #2897.
    Comment 9
    1. Kevin Kirspel, Mon, 10 Apr 2017 14:40:08 GMT

    In d2390ce4/rtems:

    Updating default termios initialization for dedicated input/output baud rates updates #2897.
    Comment 10
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 11
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2905 - Merge LEON

    Link https://devel.rtems.org/ticket/2905
    Id 2905
    Reporter Tanu Hari Dixit
    Created 6 February 2017 03:06:42
    Modified 9 November 2017 06:27:14
    Owner Daniel Hellstrom
    Type project
    Component arch/sparc
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords SoC, BSP
    Cc  
    Blocking  
    Blocked by  

    Description

    Merge LEON

    __Students:__ Past, Present, and Potential Students

    __Status:__ Some work may be done.

    __Introduction:__ Merge Leon RTEMS and mainstream RTEMS merge the Leon DriverManager, ​samples, and ​LEON-RTEMS into mainstream RTEMS.

    __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.

    __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
    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
    • TBD

    __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.

    Comment 1
    1. Chris Johns, Mon, 06 Feb 2017 04:02:32 GMT
    2. type: changed from enhancement to project
    Comment 2
    1. Gedare Bloom, Thu, 02 Mar 2017 20:23:10 GMT
    2. keywords: BSP added
    Comment 3
    1. Gedare Bloom, Thu, 02 Mar 2017 20:26:08 GMT

    I'm fairly certain this is "done".

    Comment 4
    1. Sebastian Huber, Mon, 06 Mar 2017 06:13:55 GMT
    2. status: changed from new to closed
    3. version: 4.11 deleted
    4. resolution: set to fixed
    5. milestone: changed from Indefinite to 4.12

    This is mostly done and certainly not a GSoC project.

    Comment 5
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 6
    1. Sebastian Huber, Tue, 10 Oct 2017 06:53:06 GMT
    2. component: changed from bsps to arch/sparc
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2906 - rtems-doc waf configure does not detect sphinxcontrib.bibtex status

    Link https://devel.rtems.org/ticket/2906
    Id 2906
    Reporter Chris Johns
    Created 9 February 2017 21:16:53
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity blocker
    Keywords  
    Cc Sebastian Huber Joel Sherrill
    Blocking  
    Blocked by  

    Description

    The rtems-docs requires the Sphinx contribution extension for bibtex to build.

    A configure check should be added to see if the extension is installed and an error raised or the documentation conditionally built.

    It is not clear to me if bibtex needs Tex Alive. Requiring Tex on all hosts to build the documentation is a regression so the extension will need to be removed or a fall back position taken where degraded quality documentation in HTML is created.

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Chris Johns, Mon, 04 Sep 2017 01:30:49 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    ​https://git.rtems.org/rtems-docs/commit/?id=ff9d55501f5a150d52b43513357becc04171fd61

    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2909 - xz: Support for 64-bit CRC is build although XZ_USE_CRC64 is not defined

    Link https://devel.rtems.org/ticket/2909
    Id 2909
    Reporter Sebastian Huber
    Created 14 February 2017 07:52:24
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This leads to:

    ../../../../../../rtems/c/src/../../cpukit/libmisc/xz/xz_crc64.c:21:16: warning: no previous prototype for 'xz_crc64_init' [-Wmissing-prototypes]
    ../../../../../../rtems/c/src/../../cpukit/libmisc/xz/xz_crc64.c:40:20: warning: no previous prototype for 'xz_crc64' [-Wmissing-prototypes]

    We should enable the 64-bit CRC or remove this file from the build.

    Comment 1
    1. Joel Sherrill, Fri, 07 Apr 2017 20:24:01 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In c475924d/rtems:

    xz_config.h: Define XZ_USE_CRC64 close #2909.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Tue, 13 Jun 2017 09:45:57 GMT

    In c7377381/rtems:

    xz: Use CRC32 This reverts c475924d6d2ea7d5cba160a8a28e88642d6b46d8. Update #2909. Close #2994.
    Comment 4
    1. Sebastian Huber, Thu, 06 Jul 2017 13:12:06 GMT

    In 71943dd/rtems:

    xz: Suppress attribute warnings Update #2909.
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2912 - libdebugger: control reaches end of non-void function

    Link https://devel.rtems.org/ticket/2912
    Id 2912
    Reporter Sebastian Huber
    Created 15 February 2017 10:15:53
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    ../../../../../../rtems/c/src/../../cpukit/libdebugger/rtems-debugger-server.c:393:1: warning: control reaches end of non-void function [-Wreturn-type]
    ../../../../../../rtems/c/src/../../cpukit/libdebugger/rtems-debugger-server.c:405:1: warning: control reaches end of non-void function [-Wreturn-type]

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Chris Johns, Sun, 16 Jul 2017 23:31:04 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    This looks fixed to me on master.

    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2916 - termios: Change receive callback invocation to enable select() and poll() support

    Link https://devel.rtems.org/ticket/2916
    Id 2916
    Reporter Sebastian Huber
    Created 28 February 2017 07:55:02
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Call the receive callback in case a read will succeed without to block. This enables the use of the receive callback for a poll() and select() support. Increase raw input buffer size to allow buffering of one line.

    Comment 1
    1. Sebastian Huber, Tue, 28 Feb 2017 07:55:08 GMT
    2. owner: changed from joel.sherrill@… to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Tue, 28 Feb 2017 09:03:08 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    [9fa0f543ecfcf6cdf79d60a3a9f5a0ed845c7046/rtems]

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2917 - termios: Make write POSIX compatible

    Link https://devel.rtems.org/ticket/2917
    Id 2917
    Reporter Sebastian Huber
    Created 28 February 2017 07:57:14
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Currently only blocking read/write operations are implemented. A blocking write must transfer at least one character. It should not wait for the device for the second character and so on.

    Comment 1
    1. Sebastian Huber, Tue, 28 Feb 2017 07:57:19 GMT
    2. owner: changed from joel.sherrill@… to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Tue, 28 Feb 2017 09:03:33 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    [a165a9607abd4263fa1a572bb227bd9fb537053b/rtems]

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2922 - libdl unresolved externals that use more than one block or multiple entries corrupts.

    Link https://devel.rtems.org/ticket/2922
    Id 2922
    Reporter Chris Johns
    Created 9 March 2017 03:00:21
    Modified 27 November 2018 06:12:50
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    If there are lots of unresolved externals the unresolved block structure get confused and the can lock up looking for a new slot to add an unresolved external.

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 3
    1. Chris Johns, Sun, 14 Oct 2018 00:52:20 GMT
    2. owner: changed from chrisj@… to Chris Johns
    3. status: changed from new to accepted
    Comment 4
    1. Chris Johns, Tue, 27 Nov 2018 06:12:50 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    2923 - Questionable Code in resource_snapshot.c

    Link https://devel.rtems.org/ticket/2923
    Id 2923
    Reporter Joel Sherrill
    Created 10 March 2017 18:13:20
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Coverity URL:

    ​https://scan5.coverity.com/reports.htm#v29808/p10069/fileInstanceId=108958257&defectInstanceId=30877219&mergedDefectId=1399703

    Coverity Scan doesn't like taking the address of a single uint32_t and then treating it as an array pointer. I think the code is likely doing what is intended but there is an implicit linkable between the order of the fields in the structure here and the class numbers used in the object IDs. Is there a way to improve this code and reduce the linkage?

    141

  • address_of: Taking address with &snapshot->active_posix_keys yields a singleton pointer.
  • assign: Assigning: active = &snapshot->active_posix_keys.
  • 142 active = &snapshot->active_posix_keys;
    143

  • Condition i < 19U /* sizeof (objects_info_table) / sizeof (objects_info_table[0]) */, taking true branch.
  • 144 for (i = 0; i < RTEMS_ARRAY_SIZE(objects_info_table); ++i) {
    145 const Objects_Information *information;
    146
    147 information = _Objects_Get_information(
    148 objects_info_table[i].api,
    149 objects_info_table[i].cls
    150 );
    151

  • Condition information != NULL, taking true branch.
  • 152 if (information != NULL) {
    CID 1399703 (#1 of 1): Out-of-bounds access (ARRAY_VS_SINGLETON)

  • ptr_arith: Using active as an array. This might corrupt or misinterpret adjacent memory locations.
  • 153 active[i] = _Objects_Active_count(information);

    Comment 1
    1. Joel Sherrill, Fri, 10 Mar 2017 18:13:45 GMT
    2. owner: changed from joel.sherrill@… to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Mon, 13 Mar 2017 06:00:40 GMT

    Yes, the code is ugly, but it works quite well.

    Comment 3
    1. Gedare Bloom, Mon, 13 Mar 2017 15:08:59 GMT

    Very ugly. The hack might be a bit more clear if we use

     typedef struct {
      Heap_Information_block workspace_info;
      Heap_Information_block heap_info;
      uint32_t active_posix_key_value_pairs;
      union {
        uint32_t anonymous[ 1 + ( sizeof(rtems_resource_rtems_api) + sizeof(rtems_resource_posix_api) ) / sizeof(uint32_t) ];
        struct {
          uint32_t active_posix_keys;
          rtems_resource_rtems_api rtems_api;
          rtems_resource_posix_api posix_api;
        }
      }
      int open_files;
    } rtems_resource_snapshot; 
    Comment 4
    1. Sebastian Huber, Tue, 14 Mar 2017 06:28:40 GMT

    Replying to Gedare:

    Very ugly. The hack might be a bit more clear if we use

     typedef struct {
      Heap_Information_block workspace_info;
      Heap_Information_block heap_info;
      uint32_t active_posix_key_value_pairs;
      union {
        uint32_t anonymous[ 1 + ( sizeof(rtems_resource_rtems_api) + sizeof(rtems_resource_posix_api) ) / sizeof(uint32_t) ];
        struct {
          uint32_t active_posix_keys;
          rtems_resource_rtems_api rtems_api;
          rtems_resource_posix_api posix_api;
        }
      }
      int open_files;
    } rtems_resource_snapshot; 

    The rtems_resource_snapshot structure is supposed to be easy to understand for the user and should not make implementation details visible. With the union you still assume a certain mapping of array elements and normal structure members. It is an out-of-bounds access, so Coverity is right, but it is intentional. I don't think this should be changed.

    Comment 5
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 6
    1. Sebastian Huber, Thu, 11 May 2017 07:43:47 GMT
    2. status: changed from assigned to closed
    3. resolution: set to wontfix
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2924 - Warnings in SPARC BSPs

    Link https://devel.rtems.org/ticket/2924
    Id 2924
    Reporter Joel Sherrill
    Created 10 March 2017 19:31:17
    Modified 9 November 2017 06:27:14
    Owner Daniel Hellstrom
    Type defect
    Component arch/sparc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    As of today, the following warnings exist for SPARC BSPs.

    log/sparc-leon2.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon2/console/debugputs.c:43:5: warning: this 'while' clause does not guard... [-Wmisleading-indentation]
    log/sparc-leon2.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon2/../../sparc/shared/amba/ahbstat.c:156:3: warning: implicit declaration of function 'printk' [-Wimplicit-function-declaration]
    log/sparc-leon2.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon2/../../sparc/shared/amba/ahbstat.c:156:3: warning: nested extern declaration of 'printk' [-Wnested-externs]
    log/sparc-leon2.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon2/../../sparc/shared/drvmgr/ambapp_bus.c:647:4: warning: implicit declaration of function 'printk' [-Wimplicit-function-declaration]
    log/sparc-leon2.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon2/../../sparc/shared/drvmgr/ambapp_bus.c:647:4: warning: nested extern declaration of 'printk' [-Wnested-externs]
    log/sparc-leon2.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon2/../../sparc/shared/drvmgr/leon2_amba_bus.c:168:3: warning: implicit declaration of function 'printk' [-Wimplicit-function-declaration]
    log/sparc-leon2.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon2/../../sparc/shared/drvmgr/leon2_amba_bus.c:168:3: warning: nested extern declaration of 'printk' [-Wnested-externs]
    log/sparc-leon2.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon2/../../sparc/shared/irq/genirq.c:244:3: warning: implicit declaration of function 'printk' [-Wimplicit-function-declaration]
    log/sparc-leon2.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon2/../../sparc/shared/irq/genirq.c:244:3: warning: nested extern declaration of 'printk' [-Wnested-externs]
    log/sparc-leon2.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon2/../../sparc/shared/spw/grspw_router.c:213:4: warning: implicit declaration of function 'printk' [-Wimplicit-function-declaration]
    log/sparc-leon2.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon2/../../sparc/shared/spw/grspw_router.c:213:4: warning: nested extern declaration of 'printk' [-Wnested-externs]
    log/sparc-leon2.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon2/../../sparc/shared/uart/apbuart.c:574:21: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'apbuart_priv * {aka struct *}' [-Wformat=]
    log/sparc-leon3.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/amba/ahbstat.c:156:3: warning: implicit declaration of function 'printk' [-Wimplicit-function-declaration]
    log/sparc-leon3.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/amba/ahbstat.c:156:3: warning: nested extern declaration of 'printk' [-Wnested-externs]
    log/sparc-ngmp.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/amba/ahbstat.c:156:3: warning: implicit declaration of function 'printk' [-Wimplicit-function-declaration]
    log/sparc-ngmp.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/amba/ahbstat.c:156:3: warning: nested extern declaration of 'printk' [-Wnested-externs]
    log/sparc-leon3.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/drvmgr/ambapp_bus.c:647:4: warning: implicit declaration of function 'printk' [-Wimplicit-function-declaration]
    log/sparc-leon3.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/drvmgr/ambapp_bus.c:647:4: warning: nested extern declaration of 'printk' [-Wnested-externs]
    log/sparc-ngmp.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/drvmgr/ambapp_bus.c:647:4: warning: implicit declaration of function 'printk' [-Wimplicit-function-declaration]
    log/sparc-ngmp.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/drvmgr/ambapp_bus.c:647:4: warning: nested extern declaration of 'printk' [-Wnested-externs]
    log/sparc-leon3.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/irq/genirq.c:244:3: warning: implicit declaration of function 'printk' [-Wimplicit-function-declaration]
    log/sparc-leon3.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/irq/genirq.c:244:3: warning: nested extern declaration of 'printk' [-Wnested-externs]
    log/sparc-ngmp.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/irq/genirq.c:244:3: warning: implicit declaration of function 'printk' [-Wimplicit-function-declaration]
    log/sparc-ngmp.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/irq/genirq.c:244:3: warning: nested extern declaration of 'printk' [-Wnested-externs]
    log/sparc-leon3.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/spw/grspw_router.c:213:4: warning: implicit declaration of function 'printk' [-Wimplicit-function-declaration]
    log/sparc-leon3.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/spw/grspw_router.c:213:4: warning: nested extern declaration of 'printk' [-Wnested-externs]
    log/sparc-ngmp.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/spw/grspw_router.c:213:4: warning: implicit declaration of function 'printk' [-Wimplicit-function-declaration]
    log/sparc-ngmp.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/spw/grspw_router.c:213:4: warning: nested extern declaration of 'printk' [-Wnested-externs]
    log/sparc-leon3.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/uart/apbuart.c:574:21: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'apbuart_priv * {aka struct *}' [-Wformat=]
    log/sparc-ngmp.log:../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/uart/apbuart.c:574:21: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'apbuart_priv * {aka struct *}' [-Wformat=]

    Comment 1
    1. Joel Sherrill, Fri, 10 Mar 2017 19:31:29 GMT
    2. owner: changed from joel.sherrill@… to Daniel Hellstrom
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:53:06 GMT
    2. component: changed from bsps to arch/sparc
    Comment 4
    1. Joel Sherrill, Thu, 12 Oct 2017 17:29:59 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    These no longer occur. Closing.

    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2925 - Warnings in rtl-obj-cache.c on some targets

    Link https://devel.rtems.org/ticket/2925
    Id 2925
    Reporter Joel Sherrill
    Created 13 March 2017 16:18:23
    Modified 14 October 2018 00:47:25
    Owner Chris Johns
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    These warnings are on m68k but not sparc, mips powerpc, or arm. Looks like inttypes.h should be used.

    ../../../../../../rtems/c/src/../../cpukit/libdl/rtl-obj-cache.c:175:47: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Wformat=]
    ../../../../../../rtems/c/src/../../cpukit/libdl/rtl-obj-cache.c:175:85: warning: format '%d' expects argument of type 'int', but argument 7 has type 'long unsigned int' [-Wformat=]
    ../../../../../../rtems/c/src/../../cpukit/libdl/rtl-obj-cache.c:81:67: warning: format '%d' expects argument of type 'int', but argument 7 has type 'long unsigned int' [-Wformat=]
    ../../../../../../rtems/c/src/../../cpukit/libdl/rtl-obj-cache.c:81:81: warning: format '%d' expects argument of type 'int', but argument 9 has type 'long unsigned int' [-Wformat=]
    ~

    Comment 1
    1. Joel Sherrill, Mon, 13 Mar 2017 16:18:35 GMT
    2. owner: changed from joel.sherrill@… to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 4
    1. Joel Sherrill, Sun, 14 Oct 2018 00:47:25 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    2930 - Coverity Reports Out of Bounds Read in drvmgr_print.c

    Link https://devel.rtems.org/ticket/2930
    Id 2930
    Reporter Joel Sherrill
    Created 14 March 2017 21:31:10
    Modified 9 November 2017 06:27:14
    Owner Daniel Hellstrom
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    ​https://scan5.coverity.com/reports.htm#v29808/p10069/fileInstanceId=109359850&defectInstanceId=30967449&mergedDefectId=1399730

    354 printf(" DRIVER ID: 0x%llx\n", drv->drv_id);

  • Condition drv->name, taking true branch.
  • 355 printf(" NAME: %s\n", drv->name ? drv->name : "NO_NAME");
    356 printf(" BUS TYPE: %d\n", drv->bus_type);
    357 printf(" OPERATIONS:\n");

  • alias: Assigning: ppfunc = &drv->ops->init[0]. ppfunc now points to element 0 of drv->ops->init (which consists of 4 4-byte elements).
  • Condition i < 6U /* sizeof (struct drvmgr_drv_ops) / sizeof (void (*)(void)) */, taking true branch.
  • Condition i < 6U /* sizeof (struct drvmgr_drv_ops) / sizeof (void (*)(void)) */, taking true branch.
  • cond_at_most: Checking i < 6U implies that i may be up to 5 on the true branch.
  • 358 for (i = 0, ppfunc = (fun_ptr *)&drv->ops->init[0];
    359 i < DRVMGR_OPS_NUM(struct drvmgr_drv_ops); i++)

  • Jumping back to the beginning of the loop.
  • CID 1399730 (#1 of 1): Out-of-bounds read (OVERRUN)

  • overrun-local: Overrunning array of 4 4-byte elements at element index 5 (byte offset 20) by dereferencing pointer ppfunc + i.
  • 360 printf(" %s %p\n", drv_ops_names[i], ppfunc[i]);
    361 printf(" NO. DEVICES: %d\n", drv->dev_cnt);
    362

    Comment 1
    1. Joel Sherrill, Wed, 15 Mar 2017 16:03:24 GMT
    2. owner: changed from joel.sherrill@… to Daniel Hellstrom
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Daniel Hellstrom, Tue, 29 Aug 2017 07:09:36 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 3663be53/rtems:

    drvmgr: clean up info_drv print Fixes #2930
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2933 - Flexibleassignto is broken on new ticket page.

    Link https://devel.rtems.org/ticket/2933
    Id 2933
    Reporter Amar Takhar
    Created 15 March 2017 16:13:06
    Modified 20 October 2018 22:58:08
    Owner Amar Takhar
    Type infra
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3560
    Blocked by  

    Description

    The plugin needs to be fixed for new trac template changes. I usually don't have to modify this often but we made a huge version jump.

    Right now all we see is

    assign to

    There should be a list of developers.

    Comment 1
    1. Amar Takhar, Sat, 20 Oct 2018 22:58:08 GMT
    2. status: changed from assigned to closed
    3. version: set to 5
    4. resolution: set to fixed
    5. blocking: set to 3560
    6. milestone: set to 5.1

    See #3560 for updates.


    2935 - Termios task driven mode not compatible with SMP

    Link https://devel.rtems.org/ticket/2935
    Id 2935
    Reporter Martin Aberg
    Created 16 March 2017 10:14:36
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type defect
    Component score
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords termios smp
    Cc  
    Blocking  
    Blocked by  

    Description

    When the Termios task driven functioning mode is used, rtems_termios_open_tty() calls rtems_task_create() with RTEMS_NO_PREEMPT in the initial task mode parameter. RTEMS_NO_PREEMPT is not supported on SMP.

    rtems_task_create() returns RTEMS_UNSATISFIED in this SMP scenario and Termios ends up in rtems_fatal_error_occurred().

    Termios starts the RX and TX tasks successfully on SMP if RTEMS_NO_PREEMPT is removed from the initial task modes of these tasks. However, I suspect there may be assumptions on the NO_PREEMPT mode for the RX and TX tasks in other parts of Termios.

    Comment 1
    1. Sebastian Huber, Thu, 16 Mar 2017 14:39:51 GMT

    The task driven mode in general needs a review and possibly a re-implementation. A good alternative is the TERMIOS_IRQ_SERVER_DRIVEN mode in case the interrupt server is available.

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 08 Jun 2017 07:42:07 GMT

    In f7a2dcf/rtems-docs:

    bsp-howto: Warn about TERMIOS_TASK_DRIVEN Update #2935.
    Comment 4
    1. Sebastian Huber, Thu, 08 Jun 2017 07:43:12 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    We should keep the task driven mode as is. Maybe remove it in the future.

    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2941 - building rsb freezes

    Link https://devel.rtems.org/ticket/2941
    Id 2941
    Reporter DHANPAL SINGH
    Created 17 March 2017 11:05:30
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component tool/rsb
    Status closed
    Resolution invalid
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~$ cd
    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~$ mkdir -p development/rtems/rsb
    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~$ cd development/rtems/rsb
    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~/development/rtems/rsb$ git clone ​git://git.rtems.org/rtems-source-builder.git fatal: destination path 'rtems-source-builder' already exists and is not an empty directory.
    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~/development/rtems/rsb$ cd rtems-source-builder
    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~/development/rtems/rsb/rtems-source-builder$ cd rtems
    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~/development/rtems/rsb/rtems-source-builder/rtems$ ../source-builder/sb-set-builder --prefix=$HOME/development/rtems/4.12 4.12/rtems-sparc
    RTEMS Source Builder - Set Builder, 4.12 (10d9e2dfacf7)
    Build Set: 4.12/rtems-sparc
    Build Set: 4.12/rtems-autotools.bset
    Build Set: 4.12/rtems-autotools-internal.bset
    config: tools/rtems-autoconf-2.69-1.cfg
    package: autoconf-2.69-x86_64-linux-gnu-1
    Creating source directory: sources
    download: ​ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz -> sources/autoconf-2.69.tar.gz
    downloading: sources/autoconf-2.69.tar.gz - 1.8MB of 1.8MB (100%)
    building: autoconf-2.69-x86_64-linux-gnu-1
    config: tools/rtems-automake-1.12.6-1.cfg
    package: automake-1.12.6-x86_64-linux-gnu-1
    download: ​ftp://ftp.gnu.org/gnu/automake/automake-1.12.6.tar.gz -> sources/automake-1.12.6.tar.gz
    downloading: sources/automake-1.12.6.tar.gz - 2.0MB of 2.0MB (100%)
    Creating source directory: patches
    download: ​https://git.rtems.org/rtems-tools/plain/tools/4.12/automake/automake-1.12.6-bugzilla.redhat.com-1239379.diff -> patches/automake-1.12.6-bugzilla.redhat.com-1239379.diff
    downloading: patches/automake-1.12.6-bugzilla.redhat.com-1239379.diff - 0.0 bytedownloading: patches/automake-1.12.6-bugzilla.redhat.com-1239379.diff - 408.0 bytes of 408.0 bytes (100%)
    building: automake-1.12.6-x86_64-linux-gnu-1
    cleaning: autoconf-2.69-x86_64-linux-gnu-1
    cleaning: automake-1.12.6-x86_64-linux-gnu-1
    Build Set: Time 0:00:44.961728
    Build Set: 4.12/rtems-autotools-base.bset
    config: tools/rtems-autoconf-2.69-1.cfg
    package: autoconf-2.69-x86_64-linux-gnu-1
    building: autoconf-2.69-x86_64-linux-gnu-1
    reporting: tools/rtems-autoconf-2.69-1.cfg -> autoconf-2.69-x86_64-linux-gnu-1.txt
    reporting: tools/rtems-autoconf-2.69-1.cfg -> autoconf-2.69-x86_64-linux-gnu-1.xml
    config: tools/rtems-automake-1.12.6-1.cfg
    package: automake-1.12.6-x86_64-linux-gnu-1
    building: automake-1.12.6-x86_64-linux-gnu-1
    reporting: tools/rtems-automake-1.12.6-1.cfg -> automake-1.12.6-x86_64-linux-gnu-1.txt
    reporting: tools/rtems-automake-1.12.6-1.cfg -> automake-1.12.6-x86_64-linux-gnu-1.xml
    installing: autoconf-2.69-x86_64-linux-gnu-1 -> /home/dhanpal/development/rtems/4.12
    installing: automake-1.12.6-x86_64-linux-gnu-1 -> /home/dhanpal/development/rtems/4.12
    cleaning: autoconf-2.69-x86_64-linux-gnu-1
    cleaning: automake-1.12.6-x86_64-linux-gnu-1
    Build Set: Time 0:00:15.092702
    Build Set: Time 0:01:00.058748
    config: devel/expat-2.1.0-1.cfg
    package: expat-2.1.0-x86_64-linux-gnu-1
    download: ​http://downloads.sourceforge.net/project/expat/expat/2.1.0/expat-2.1.0.tar.gz -> sources/expat-2.1.0.tar.gz

    redirect: ​https://nchc.dl.sourceforge.net/project/expat/expat/2.1.0/expat-2.1.0.tar.gz

    downloading: sources/expat-2.1.0.tar.gz - 549.4kB of 549.4kB (100%)
    building: expat-2.1.0-x86_64-linux-gnu-1
    reporting: devel/expat-2.1.0-1.cfg -> expat-2.1.0-x86_64-linux-gnu-1.txt
    reporting: devel/expat-2.1.0-1.cfg -> expat-2.1.0-x86_64-linux-gnu-1.xml
    config: tools/rtems-binutils-2.27-1.cfg
    package: sparc-rtems4.12-binutils-2.27-x86_64-linux-gnu-1
    download: ​ftp://ftp.gnu.org/gnu/binutils/binutils-2.27.tar.bz2 -> sources/binutils-2.27.tar.bz2
    downloading: sources/binutils-2.27.tar.bz2 - 24.9MB of 24.9MB (100%)
    download: ​https://git.rtems.org/rtems-tools/plain/tools/4.12/binutils/binutils-2.26-gas-reloc.patch -> patches/binutils-2.26-gas-reloc.patch
    downloading: patches/binutils-2.26-gas-reloc.patch - 0.0 bytes of 510.0 bytes (0downloading: patches/binutils-2.26-gas-reloc.patch - 510.0 bytes of 510.0 bytes (100%)
    building: sparc-rtems4.12-binutils-2.27-x86_64-linux-gnu-1
    reporting: tools/rtems-binutils-2.27-1.cfg -> sparc-rtems4.12-binutils-2.27-x86_64-linux-gnu-1.txt
    reporting: tools/rtems-binutils-2.27-1.cfg -> sparc-rtems4.12-binutils-2.27-x86_64-linux-gnu-1.xml
    config: tools/rtems-gcc-6.3.0-newlib-2.5.0.20170228-1.cfg
    package: sparc-rtems4.12-gcc-6.3.0-newlib-2.5.0.20170228-x86_64-linux-gnu-1
    download: ​ftp://ftp.gnu.org/gnu/gcc/gcc-6.3.0/gcc-6.3.0.tar.bz2 -> sources/gcc-6.3.0.tar.bz2
    downloading: sources/gcc-6.3.0.tar.bz2 - 95.3MB of 95.3MB (100%)
    download: ​ftp://sourceware.org/pub/newlib/newlib-2.5.0.20170228.tar.gz -> sources/newlib-2.5.0.20170228.tar.gz
    downloading: sources/newlib-2.5.0.20170228.tar.gz - 17.1MB of 17.1MB (100%)
    download: ​http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2.tar.bz2 -> sources/mpfr-2.4.2.tar.bz2
    downloading: sources/mpfr-2.4.2.tar.bz2 - 1.0MB of 1.0MB (100%)
    download: ​http://www.multiprecision.org/mpc/download/mpc-0.8.1.tar.gz -> sources/mpc-0.8.1.tar.gz
    downloading: sources/mpc-0.8.1.tar.gz - 532.2kB of 532.2kB (100%)
    download: ​ftp://ftp.gnu.org/gnu/gmp/gmp-4.3.2.tar.bz2 -> sources/gmp-4.3.2.tar.bz2
    downloading: sources/gmp-4.3.2.tar.bz2 - 1.8MB of 1.8MB (100%)
    building: sparc-rtems4.12-gcc-6.3.0-newlib-2.5.0.20170228-x86_64-linux-gnu-1

    Comment 1
    1. Joel Sherrill, Fri, 17 Mar 2017 13:03:41 GMT

    Depending on the speed of the computer, building tools for an architecture can easily take an hour. You should run top in another windows land see how active your computer is. There is also a detailed log file you can tail. But I don't remember the details of that offhand.

    Comment 2
    1. Gedare Bloom, Fri, 17 Mar 2017 19:33:57 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    Yeah this looks perfectly normal so far. Let it continue going.

    I'm closing this. OP can re-open and post an rsb-error / log file if there is a problem.

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Mon, 16 Oct 2017 06:26:07 GMT
    2. component: changed from unspecified to tool/rsb
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2942 - rtems building error

    Link https://devel.rtems.org/ticket/2942
    Id 2942
    Reporter DHANPAL SINGH
    Created 17 March 2017 14:28:11
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component unspecified
    Status closed
    Resolution invalid
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~$ export PATH=$HOME/development/rtems/4.12/bin:$PATH
    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~$ cd
    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~$ cd development/rtems
    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~/development/rtems$ mkdir kernel
    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~/development/rtems$ cd kernel
    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~/development/rtems/kernel$ git clone ​git://git.rtems.org/rtems.git rtems
    Cloning into 'rtems'...
    remote: Counting objects: 504955, done.
    remote: Compressing objects: 100% (90780/90780), done.
    remote: Total 504955 (delta 407126), reused 499936 (delta 403143)
    Receiving objects: 100% (504955/504955), 73.12 MiB | 113 KiB/s, done.
    Resolving deltas: 100% (407126/407126), done.
    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~/development/rtems/kernel$ cd rtems
    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~/development/rtems/kernel/rtems$ ./bootstrap -c && ./bootstrap -p && \

    $HOME/development/rtems/rsb/source-builder/sb-bootstrap

    removing automake generated Makefile.in files
    removing configure files
    removing aclocal.m4 files
    Generating ./cpukit/libmisc/preinstall.am
    Generating ./cpukit/preinstall.am
    Generating ./cpukit/ftpd/preinstall.am
    Generating ./cpukit/mghttpd/preinstall.am
    Generating ./cpukit/score/preinstall.am
    Generating ./cpukit/score/cpu/no_cpu/preinstall.am
    Generating ./cpukit/score/cpu/arm/preinstall.am
    Generating ./cpukit/score/cpu/lm32/preinstall.am
    Generating ./cpukit/score/cpu/nios2/preinstall.am
    Generating ./cpukit/score/cpu/epiphany/preinstall.am
    Generating ./cpukit/score/cpu/sparc64/preinstall.am
    Generating ./cpukit/score/cpu/m32c/preinstall.am
    Generating ./cpukit/score/cpu/i386/preinstall.am
    Generating ./cpukit/score/cpu/mips/preinstall.am
    Generating ./cpukit/score/cpu/v850/preinstall.am
    Generating ./cpukit/score/cpu/or1k/preinstall.am
    Generating ./cpukit/score/cpu/bfin/preinstall.am
    Generating ./cpukit/score/cpu/sh/preinstall.am
    Generating ./cpukit/score/cpu/m68k/preinstall.am
    Generating ./cpukit/score/cpu/powerpc/preinstall.am
    Generating ./cpukit/score/cpu/moxie/preinstall.am
    Generating ./cpukit/score/cpu/sparc/preinstall.am
    Generating ./cpukit/libcrypt/preinstall.am
    Generating ./cpukit/dev/preinstall.am
    Generating ./cpukit/libpci/preinstall.am
    Generating ./cpukit/wrapup/preinstall.am
    Generating ./cpukit/sapi/preinstall.am
    Generating ./cpukit/libdl/preinstall.am
    Generating ./cpukit/libcsupport/preinstall.am
    Generating ./cpukit/pppd/preinstall.am
    Generating ./cpukit/dtc/libfdt/preinstall.am
    Generating ./cpukit/libnetworking/preinstall.am
    Generating ./cpukit/libfs/preinstall.am
    Generating ./cpukit/libfs/src/nfsclient/preinstall.am
    Generating ./cpukit/zlib/preinstall.am
    Generating ./cpukit/posix/preinstall.am
    Generating ./cpukit/librpc/preinstall.am
    Generating ./cpukit/telnetd/preinstall.am
    Generating ./cpukit/libdebugger/preinstall.am
    Generating ./cpukit/rtems/preinstall.am
    Generating ./cpukit/libmd/preinstall.am
    Generating ./c/src/wrapup/preinstall.am
    Generating ./c/src/libchip/preinstall.am
    Generating ./c/src/lib/libbsp/no_cpu/no_bsp/preinstall.am
    Generating ./c/src/lib/libbsp/preinstall.am
    Generating ./c/src/lib/libbsp/arm/csb336/preinstall.am
    Generating ./c/src/lib/libbsp/arm/smdk2410/preinstall.am
    Generating ./c/src/lib/libbsp/arm/realview-pbx-a9/preinstall.am
    Generating ./c/src/lib/libbsp/arm/preinstall.am
    Generating ./c/src/lib/libbsp/arm/stm32f4/preinstall.am
    Generating ./c/src/lib/libbsp/arm/atsam/preinstall.am
    Generating ./c/src/lib/libbsp/arm/rtl22xx/preinstall.am
    Generating ./c/src/lib/libbsp/arm/csb337/preinstall.am
    Generating ./c/src/lib/libbsp/arm/beagle/preinstall.am
    Generating ./c/src/lib/libbsp/arm/edb7312/preinstall.am
    Generating ./c/src/lib/libbsp/arm/lm3s69xx/preinstall.am
    Generating ./c/src/lib/libbsp/arm/lpc176x/preinstall.am
    Generating ./c/src/lib/libbsp/arm/lpc24xx/preinstall.am
    Generating ./c/src/lib/libbsp/arm/gumstix/preinstall.am
    Generating ./c/src/lib/libbsp/arm/xilinx-zynq/preinstall.am
    Generating ./c/src/lib/libbsp/arm/gdbarmsim/preinstall.am
    Generating ./c/src/lib/libbsp/arm/lpc32xx/preinstall.am
    Generating ./c/src/lib/libbsp/arm/tms570/preinstall.am
    Generating ./c/src/lib/libbsp/arm/raspberrypi/preinstall.am
    Generating ./c/src/lib/libbsp/arm/altera-cyclone-v/preinstall.am
    Generating ./c/src/lib/libbsp/lm32/milkymist/preinstall.am
    Generating ./c/src/lib/libbsp/lm32/lm32_evr/preinstall.am
    Generating ./c/src/lib/libbsp/nios2/nios2_iss/preinstall.am
    Generating ./c/src/lib/libbsp/epiphany/preinstall.am
    Generating ./c/src/lib/libbsp/epiphany/epiphany_sim/preinstall.am
    Generating ./c/src/lib/libbsp/sparc64/niagara/preinstall.am
    Generating ./c/src/lib/libbsp/sparc64/usiii/preinstall.am
    Generating ./c/src/lib/libbsp/m32c/m32cbsp/preinstall.am
    Generating ./c/src/lib/libbsp/i386/pc386/preinstall.am
    Generating ./c/src/lib/libbsp/mips/rbtx4938/preinstall.am
    Generating ./c/src/lib/libbsp/mips/rbtx4925/preinstall.am
    Generating ./c/src/lib/libbsp/mips/hurricane/preinstall.am
    Generating ./c/src/lib/libbsp/mips/jmr3904/preinstall.am
    Generating ./c/src/lib/libbsp/mips/malta/preinstall.am
    Generating ./c/src/lib/libbsp/mips/csb350/preinstall.am
    Generating ./c/src/lib/libbsp/v850/preinstall.am
    Generating ./c/src/lib/libbsp/v850/gdbv850sim/preinstall.am
    Generating ./c/src/lib/libbsp/or1k/preinstall.am
    Generating ./c/src/lib/libbsp/or1k/generic_or1k/preinstall.am
    Generating ./c/src/lib/libbsp/bfin/TLL6527M/preinstall.am
    Generating ./c/src/lib/libbsp/bfin/bf537Stamp/preinstall.am
    Generating ./c/src/lib/libbsp/bfin/eZKit533/preinstall.am
    Generating ./c/src/lib/libbsp/sh/gensh2/preinstall.am
    Generating ./c/src/lib/libbsp/sh/gensh1/preinstall.am
    Generating ./c/src/lib/libbsp/sh/gensh4/preinstall.am
    Generating ./c/src/lib/libbsp/sh/shsim/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mcf5235/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/genmcf548x/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mcf5329/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/csb360/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/av5282/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mcf5225x/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mvme147s/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mvme162/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/gen68360/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mrm332/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/gen68340/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mcf52235/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mvme167/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/uC5282/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mvme147/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mcf5206elite/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/motorola_powerpc/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/virtex5/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/haleakala/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/ss555/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/qemuppc/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/gen83xx/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/gen5200/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/virtex/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/mpc55xxevb/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/t32mppc/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/virtex4/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/mvme3100/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/beatnik/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/qoriq/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/tqm8xx/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/mvme5500/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/mpc8260ads/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/psim/preinstall.am
    Generating ./c/src/lib/libbsp/moxie/moxiesim/preinstall.am
    Generating ./c/src/lib/libbsp/sparc/erc32/preinstall.am
    Generating ./c/src/lib/libbsp/sparc/leon3/preinstall.am
    Generating ./c/src/lib/libbsp/sparc/leon2/preinstall.am
    Generating ./c/src/lib/libcpu/arm/preinstall.am
    Generating ./c/src/lib/libcpu/lm32/preinstall.am
    Generating ./c/src/lib/libcpu/nios2/preinstall.am
    Generating ./c/src/lib/libcpu/sparc64/preinstall.am
    Generating ./c/src/lib/libcpu/i386/preinstall.am
    Generating ./c/src/lib/libcpu/mips/preinstall.am
    Generating ./c/src/lib/libcpu/or1k/preinstall.am
    Generating ./c/src/lib/libcpu/bfin/preinstall.am
    Generating ./c/src/lib/libcpu/sh/preinstall.am
    Generating ./c/src/lib/libcpu/m68k/preinstall.am
    Generating ./c/src/lib/libcpu/powerpc/preinstall.am
    Generating ./c/src/lib/libcpu/sparc/preinstall.am
    Generating ./c/src/ada/preinstall.am
    bash: /home/dhanpal/development/rtems/rsb/source-builder/sb-bootstrap: No such file or directory
    dhanpal@dhanpal-HP-Pavilion-15-Notebook-PC:~/development/rtems/kernel/rtems$ sudo -s
    [sudo] password for dhanpal:
    root@dhanpal-HP-Pavilion-15-Notebook-PC:~/development/rtems/kernel/rtems# ./bootstrap -c && ./bootstrap -p && \

    $HOME/development/rtems/rsb/source-builder/sb-bootstrap

    removing automake generated Makefile.in files
    removing configure files
    removing aclocal.m4 files
    Generating ./cpukit/libmisc/preinstall.am
    Generating ./cpukit/preinstall.am
    Generating ./cpukit/ftpd/preinstall.am
    Generating ./cpukit/mghttpd/preinstall.am
    Generating ./cpukit/score/preinstall.am
    Generating ./cpukit/score/cpu/no_cpu/preinstall.am
    Generating ./cpukit/score/cpu/arm/preinstall.am
    Generating ./cpukit/score/cpu/lm32/preinstall.am
    Generating ./cpukit/score/cpu/nios2/preinstall.am
    Generating ./cpukit/score/cpu/epiphany/preinstall.am
    Generating ./cpukit/score/cpu/sparc64/preinstall.am
    Generating ./cpukit/score/cpu/m32c/preinstall.am
    Generating ./cpukit/score/cpu/i386/preinstall.am
    Generating ./cpukit/score/cpu/mips/preinstall.am
    Generating ./cpukit/score/cpu/v850/preinstall.am
    Generating ./cpukit/score/cpu/or1k/preinstall.am
    Generating ./cpukit/score/cpu/bfin/preinstall.am
    Generating ./cpukit/score/cpu/sh/preinstall.am
    Generating ./cpukit/score/cpu/m68k/preinstall.am
    Generating ./cpukit/score/cpu/powerpc/preinstall.am
    Generating ./cpukit/score/cpu/moxie/preinstall.am
    Generating ./cpukit/score/cpu/sparc/preinstall.am
    Generating ./cpukit/libcrypt/preinstall.am
    Generating ./cpukit/dev/preinstall.am
    Generating ./cpukit/libpci/preinstall.am
    Generating ./cpukit/wrapup/preinstall.am
    Generating ./cpukit/sapi/preinstall.am
    Generating ./cpukit/libdl/preinstall.am
    Generating ./cpukit/libcsupport/preinstall.am
    Generating ./cpukit/pppd/preinstall.am
    Generating ./cpukit/dtc/libfdt/preinstall.am
    Generating ./cpukit/libnetworking/preinstall.am
    Generating ./cpukit/libfs/preinstall.am
    Generating ./cpukit/libfs/src/nfsclient/preinstall.am
    Generating ./cpukit/zlib/preinstall.am
    Generating ./cpukit/posix/preinstall.am
    Generating ./cpukit/librpc/preinstall.am
    Generating ./cpukit/telnetd/preinstall.am
    Generating ./cpukit/libdebugger/preinstall.am
    Generating ./cpukit/rtems/preinstall.am
    Generating ./cpukit/libmd/preinstall.am
    Generating ./c/src/wrapup/preinstall.am
    Generating ./c/src/libchip/preinstall.am
    Generating ./c/src/lib/libbsp/no_cpu/no_bsp/preinstall.am
    Generating ./c/src/lib/libbsp/preinstall.am
    Generating ./c/src/lib/libbsp/arm/csb336/preinstall.am
    Generating ./c/src/lib/libbsp/arm/smdk2410/preinstall.am
    Generating ./c/src/lib/libbsp/arm/realview-pbx-a9/preinstall.am
    Generating ./c/src/lib/libbsp/arm/preinstall.am
    Generating ./c/src/lib/libbsp/arm/stm32f4/preinstall.am
    Generating ./c/src/lib/libbsp/arm/atsam/preinstall.am
    Generating ./c/src/lib/libbsp/arm/rtl22xx/preinstall.am
    Generating ./c/src/lib/libbsp/arm/csb337/preinstall.am
    Generating ./c/src/lib/libbsp/arm/beagle/preinstall.am
    Generating ./c/src/lib/libbsp/arm/edb7312/preinstall.am
    Generating ./c/src/lib/libbsp/arm/lm3s69xx/preinstall.am
    Generating ./c/src/lib/libbsp/arm/lpc176x/preinstall.am
    Generating ./c/src/lib/libbsp/arm/lpc24xx/preinstall.am
    Generating ./c/src/lib/libbsp/arm/gumstix/preinstall.am
    Generating ./c/src/lib/libbsp/arm/xilinx-zynq/preinstall.am
    Generating ./c/src/lib/libbsp/arm/gdbarmsim/preinstall.am
    Generating ./c/src/lib/libbsp/arm/lpc32xx/preinstall.am
    Generating ./c/src/lib/libbsp/arm/tms570/preinstall.am
    Generating ./c/src/lib/libbsp/arm/raspberrypi/preinstall.am
    Generating ./c/src/lib/libbsp/arm/altera-cyclone-v/preinstall.am
    Generating ./c/src/lib/libbsp/lm32/milkymist/preinstall.am
    Generating ./c/src/lib/libbsp/lm32/lm32_evr/preinstall.am
    Generating ./c/src/lib/libbsp/nios2/nios2_iss/preinstall.am
    Generating ./c/src/lib/libbsp/epiphany/preinstall.am
    Generating ./c/src/lib/libbsp/epiphany/epiphany_sim/preinstall.am
    Generating ./c/src/lib/libbsp/sparc64/niagara/preinstall.am
    Generating ./c/src/lib/libbsp/sparc64/usiii/preinstall.am
    Generating ./c/src/lib/libbsp/m32c/m32cbsp/preinstall.am
    Generating ./c/src/lib/libbsp/i386/pc386/preinstall.am
    Generating ./c/src/lib/libbsp/mips/rbtx4938/preinstall.am
    Generating ./c/src/lib/libbsp/mips/rbtx4925/preinstall.am
    Generating ./c/src/lib/libbsp/mips/hurricane/preinstall.am
    Generating ./c/src/lib/libbsp/mips/jmr3904/preinstall.am
    Generating ./c/src/lib/libbsp/mips/malta/preinstall.am
    Generating ./c/src/lib/libbsp/mips/csb350/preinstall.am
    Generating ./c/src/lib/libbsp/v850/preinstall.am
    Generating ./c/src/lib/libbsp/v850/gdbv850sim/preinstall.am
    Generating ./c/src/lib/libbsp/or1k/preinstall.am
    Generating ./c/src/lib/libbsp/or1k/generic_or1k/preinstall.am
    Generating ./c/src/lib/libbsp/bfin/TLL6527M/preinstall.am
    Generating ./c/src/lib/libbsp/bfin/bf537Stamp/preinstall.am
    Generating ./c/src/lib/libbsp/bfin/eZKit533/preinstall.am
    Generating ./c/src/lib/libbsp/sh/gensh2/preinstall.am
    Generating ./c/src/lib/libbsp/sh/gensh1/preinstall.am
    Generating ./c/src/lib/libbsp/sh/gensh4/preinstall.am
    Generating ./c/src/lib/libbsp/sh/shsim/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mcf5235/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/genmcf548x/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mcf5329/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/csb360/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/av5282/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mcf5225x/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mvme147s/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mvme162/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/gen68360/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mrm332/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/gen68340/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mcf52235/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mvme167/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/uC5282/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mvme147/preinstall.am
    Generating ./c/src/lib/libbsp/m68k/mcf5206elite/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/motorola_powerpc/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/virtex5/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/haleakala/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/ss555/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/qemuppc/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/gen83xx/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/gen5200/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/virtex/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/mpc55xxevb/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/t32mppc/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/virtex4/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/mvme3100/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/beatnik/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/qoriq/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/tqm8xx/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/mvme5500/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/mpc8260ads/preinstall.am
    Generating ./c/src/lib/libbsp/powerpc/psim/preinstall.am
    Generating ./c/src/lib/libbsp/moxie/moxiesim/preinstall.am
    Generating ./c/src/lib/libbsp/sparc/erc32/preinstall.am
    Generating ./c/src/lib/libbsp/sparc/leon3/preinstall.am
    Generating ./c/src/lib/libbsp/sparc/leon2/preinstall.am
    Generating ./c/src/lib/libcpu/arm/preinstall.am
    Generating ./c/src/lib/libcpu/lm32/preinstall.am
    Generating ./c/src/lib/libcpu/nios2/preinstall.am
    Generating ./c/src/lib/libcpu/sparc64/preinstall.am
    Generating ./c/src/lib/libcpu/i386/preinstall.am
    Generating ./c/src/lib/libcpu/mips/preinstall.am
    Generating ./c/src/lib/libcpu/or1k/preinstall.am
    Generating ./c/src/lib/libcpu/bfin/preinstall.am
    Generating ./c/src/lib/libcpu/sh/preinstall.am
    Generating ./c/src/lib/libcpu/m68k/preinstall.am
    Generating ./c/src/lib/libcpu/powerpc/preinstall.am
    Generating ./c/src/lib/libcpu/sparc/preinstall.am
    Generating ./c/src/ada/preinstall.am
    bash: /home/dhanpal/development/rtems/rsb/source-builder/sb-bootstrap: No such file or directory
    root@dhanpal-HP-Pavilion-15-Notebook-PC:~/development/rtems/kernel/rtems#

    Comment 1
    1. Gedare Bloom, Fri, 17 Mar 2017 19:37:30 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    This says there is no file found at the location of $HOME/development/rtems/rsb/source-builder/sb-bootstrap

    Please check your file system to see where you have checked out RSB. (I see from your other ticket you filed that it is in fact $HOME/development/rtems/rsb/rtems-source-builder/source-builder/sb-bootstrap that you need.

    Also, it is not recommended to run the source builder as the root user, or even as sudo.

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2943 - rtems building error

    Link https://devel.rtems.org/ticket/2943
    Id 2943
    Reporter DHANPAL SINGH
    Created 18 March 2017 07:07:28
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component unspecified
    Status closed
    Resolution wontfix
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    i am attaching the screenshot of file system

    Attachments:

    1 DHANPAL SINGH, Sat, 18 Mar 2017 07:07:57 GMT
      attach: set to Screenshot from 2017-03-18 09:51:42.png
    Comment 1
    1. Chris Johns, Mon, 20 Mar 2017 04:06:56 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    I am sorry, I do not understand the purpose of the ticket.

    Tickets are for bugs or issues in RTEMS or one of its packages. If you need support please ask on the RTEMS User's mailing list.

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2945 - Many failures on LEON3 with SMP disabled

    Link https://devel.rtems.org/ticket/2945
    Id 2945
    Reporter Joel Sherrill
    Created 20 March 2017 22:54:12
    Modified 9 November 2017 06:27:14
    Owner Daniel Hellstrom
    Type defect
    Component unspecified
    Status closed
    Resolution worksforme
    Version 5
    Milestone 5.1
    Priority highest
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    There are approximately ~100 failures, timeouts, etc on the LEON3 BSP. See this thread for some discussion where Jiri notes it is broken on his checkout from December:

    ​https://lists.rtems.org/pipermail/devel/2017-March/017277.html

    Passed: 458
    Failed: 20
    Timeouts: 73
    Invalid: 3

    Total: 554

    Failures:

    cdtest.exe
    spintrcritical20.exe
    dl05.exe
    spintrcritical01.exe
    spintrcritical04.exe
    spintrcritical10.exe
    spintrcritical22.exe
    sp69.exe
    spintrcritical21.exe
    sp11.exe
    spintrcritical16.exe
    spintrcritical23.exe
    psxfile01.exe
    spintrcritical05.exe
    spintrcritical02.exe
    spintrcritical08.exe
    psxgetrusage01.exe
    spcpucounter01.exe
    spintrcritical03.exe
    psxtimes01.exe

    Timeouts:

    nsecs.exe
    sptask_err02.exe
    spprivenv01.exe
    psxkey03.exe
    psxsignal01.exe
    psx06.exe
    psx10.exe
    sp04.exe
    mrfs_fstime.exe
    ticker.exe
    psxmsgq03.exe
    psxkey09.exe
    psx07.exe
    sptimerserver01.exe
    psxusleep.exe
    psxstack02.exe
    psxkey07.exe
    psxkey10.exe
    stackchk.exe
    sp01.exe
    fileio.exe
    spsimplesched01.exe
    sp03.exe
    psxcond01.exe
    sp65.exe
    sp62.exe
    psx11.exe
    psx12.exe
    psx02.exe
    imfs_fstime.exe
    crypt01.exe
    psxstack01.exe
    spcbssched01.exe
    termios.exe
    mimfs_fstime.exe
    psxsignal02.exe
    psx08.exe
    top.exe
    psxrwlock01.exe
    sp22.exe
    psxsignal04.exe
    psxkey04.exe
    mouse01.exe
    sp24.exe
    psx04.exe
    spedfsched01.exe
    uid01.exe
    mdosfs_fstime.exe
    psx16.exe
    psxaio03.exe
    sp19.exe
    psxtime.exe
    psx09.exe
    psxkey06.exe
    psxclock.exe
    cpuuse.exe
    psx05.exe
    sp66.exe
    psxsignal03.exe
    capture.exe
    sp30.exe
    psxcleanup.exe
    psxcancel.exe
    jffs2_fstime.exe
    psxsignal06.exe
    spstdthreads01.exe
    psxbarrier01.exe
    sp31.exe
    sp73.exe
    psxualarm.exe
    spfifo03.exe
    psxtimer01.exe
    monitor.exe

    Invalid:

    cxx_iostream.exe
    spinternalerror01.exe
    sptimecounter01.exe

    Comment 1
    1. Joel Sherrill, Mon, 20 Mar 2017 22:54:56 GMT
    2. owner: changed from daniel h to Daniel Hellstrom
    Comment 2
    1. Chris Johns, Tue, 21 Mar 2017 00:07:52 GMT

    Replying to Joel Sherrill:

    There are approximately ~100 failures, timeouts, etc on the LEON3 BSP. See this thread for some discussion where Jiri notes it is broken on his checkout from December:

    ​https://lists.rtems.org/pipermail/devel/2017-March/017277.html

    Passed: 458 Failed: 20 Timeouts: 73 Invalid: 3

    Total: 554

    What are the results with SMP enabled?

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Daniel Hellstrom, Fri, 12 May 2017 09:42:39 GMT

    I have not managed to reproduce so many failures on GR712RC, GR740 or TSIM. Below are the failures I get from the run yesterday on non-SMP RTEMS configuration at GR712RC LEON3. The five fstests below have been discussed before and I believe they are related to the same faulty newlib configure used when the toolchain was built. Left is 4 tests which we will have to analyse.

    I'm would argue that this should not block the 4.12 branching?

    [usr1] ####################################################### [usr1] # RTEMS TESTSUITE FAILURE SUMMARY [usr1] # [usr1] # Result Test ExecRes? ConsoleRes? ExitCode1 ExitCode2 [usr1] # FAIL: ./fstests/imfs_fsscandir01 OK FAIL 5 0 [usr1] # FAIL: ./fstests/jffs2_fsscandir01 OK FAIL 5 0 [usr1] # FAIL: ./fstests/mdosfs_fsscandir01 OK FAIL 5 0 [usr1] # FAIL: ./fstests/mimfs_fsscandir01 OK FAIL 5 0 [usr1] # FAIL: ./fstests/mrfs_fsscandir01 OK FAIL 5 0 [usr1] # FAIL: ./libtests/tar01 OK FAIL 5 0 [usr1] # FAIL: ./psxtests/psxsem01 OK FAIL 5 11 [usr1] # FAIL: ./sptests/spinternalerror01 OK N/A -559038737 1611526157 [usr1] # FAIL: ./sptests/sptimecounter01 OK N/A 5 0 [usr1] # [usr1] # SUMMARY [usr1] # Tests failing: 9 [usr1] # Tests successful: 534 [usr1] # [usr1] #######################################################

    Comment 5
    1. Daniel Hellstrom, Fri, 12 May 2017 09:46:03 GMT
    2. status: changed from assigned to closed
    3. resolution: set to worksforme
    Comment 6
    1. Sebastian Huber, Fri, 12 May 2017 09:53:58 GMT

    Which tool chain did you use?

    Why are there fsscandir01 failures?

    Comment 7
    1. Daniel Hellstrom, Fri, 12 May 2017 10:03:05 GMT

    It happens on both GCC-6 and GCC-7 series. It is our own build, I think it is the configuration of it that is an issue.

    [usr1] # FAIL: ./fstests/imfs_fsscandir01 OK FAIL 5 0 [usr1] # FAIL: ./fstests/jffs2_fsscandir01 OK FAIL 5 0 [usr1] # FAIL: ./fstests/mdosfs_fsscandir01 OK FAIL 5 0 [usr1] # FAIL: ./fstests/mimfs_fsscandir01 OK FAIL 5 0 [usr1] # FAIL: ./fstests/mrfs_fsscandir01 OK FAIL 5 0

    all fail with similar error message:

    [term1] __* BEGIN OF TEST FSSCANDIR ROOT IMFS __* [term1] Initializing filesystem ROOT IMFS [term1] scandir: Success [term1] /opt/rtems-4.12/src/rtems-4.12/c/src/../../testsuites/fstests/imfs_fsscandir01/../fsscandir01/init.c: 47 MAXNAMLEN == NAME_MAX

    Comment 8
    1. Sebastian Huber, Fri, 12 May 2017 10:08:13 GMT

    It would be quite nice if your RCC is next to identical to the tool chain produced by the RSB. This issue was fixed in January 2017 in the RTEMS master.

    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2946 - Add a top level global testsuite configuration file (.tcfg) and a 'user-input' test state.

    Link https://devel.rtems.org/ticket/2946
    Id 2946
    Reporter Chris Johns
    Created 21 March 2017 00:24:03
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Adding a top level testsuite configuration file lets us specify tests that have a common test state across all BSPs.

    Adding the test state 'user-input' clearly tags the test as needing user input and test result tools can correctly determine the test result. The current practice of passing a test needing user input is actually hiding the real result of the test.

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Sebastian Huber, Tue, 10 Oct 2017 06:46:55 GMT
    2. component: changed from testing to unspecified
    Comment 3
    1. Joel Sherrill, Wed, 11 Oct 2017 23:47:54 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Chris says he fixed this.

    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2949 - Questionable patch organization in RTEMS tools and RSB

    Link https://devel.rtems.org/ticket/2949
    Id 2949
    Reporter Sebastian Huber
    Created 21 March 2017 14:19:11
    Modified 13 November 2017 07:39:52
    Owner  
    Type defect
    Component tool/rsb
    Status closed
    Resolution wontfix
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Patches for RTEMS tools are available via the RTEMS tools repository:

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

    They are organized using subdirectories.

    The RSB uses these patches. It removes the subdirectories and collects everything in a "patches" directory, e.g.

    download: ​https://git.rtems.org/rtems-tools/plain/tools/4.11/newlib/arm/newlib-ARM-Optimize-IEEE-754-sqrt-implementation.diff -> patches/newlib-ARM-Optimize-IEEE-754-sqrt-implementation.diff

    This works only in case the patch file names are unique. So, the use of subdirectories in the RTEMS tools is questionable.

    Comment 1
    1. Amar Takhar, Wed, 22 Mar 2017 12:25:02 GMT

    This should be easily solved by preserving the subdirectories when downloading Keeping the subdirectories is good for orginisation and still handy when they've been downloaded.

    Comment 2
    1. Chris Johns, Wed, 22 Mar 2017 23:42:36 GMT

    Is the issue switching between branches when testing?

    There is the patch option of --rsb-file= that overrides the RSB's detection of a file name from the URL. This option assumes a file name and not a file path.

    I question the need for patches being in rtems-tools, the less we have the better off we are. I cannot see how we can remove the ones we have without needing to update the 4.11 and master branches.

    The RSB has evolved to being able to download patches from a range of sources. I prefer to see patches referenced from upstream sources where ever possible. Mailing list archives are a good source of patches and I wonder if this is a better place for us to hold any patches we need?

    The ability to support a download directory structure would mean the RSB would need to more complex code to handle some of sites we currently download from. I am not sure how to do this.

    Comment 3
    1. Gedare Bloom, Thu, 23 Mar 2017 15:53:24 GMT

    The problem of multiple patches with the same name would be a problem regardless of the source of the patches. This namespace problem could be solved by renaming all patches to something that should be unique, e.g. the hash value of the file.

    Comment 4
    1. Chris Johns, Fri, 24 Mar 2017 01:28:52 GMT

    Replying to Gedare:

    The problem of multiple patches with the same name would be a problem regardless of the source of the patches. This namespace problem could be solved by renaming all patches to something that should be unique, e.g. the hash value of the file.

    The hash value of the file would work and a good idea. I was concerned about making it difficult to find the patch or file from the error or log but a hash is something you can grep the config tree for.

    If no hash is provided the file name can be used. This keeps the bootstrap of adding new files like it currently is, ie a warning.

    This would be common to the source and patch directories. Is that OK?

    Comment 5
    1. Chris Johns, Fri, 24 Mar 2017 04:29:59 GMT

    A problem with using the hashes is releases, that is:

    ​https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.1/sources/

    The release procedure uses the RSB in a download only mode to collect all the source needed in a release.

    I am not sure how to handle this.

    Comment 6
    1. Sebastian Huber, Fri, 24 Mar 2017 10:27:31 GMT

    I think we should stop to use subdirectories in the RTEMS tools for the patches.

    Comment 7
    1. Chris Johns, Fri, 24 Mar 2017 22:27:34 GMT

    Sebastian, I did not understand your last comment.

    Comment 8
    1. Chris Johns, Mon, 27 Mar 2017 04:37:32 GMT

    I fixed #2951 using the patch from the newlib mailing list:

    ​https://git.rtems.org/rtems-source-builder/commit/?id=b47a811955e427f945f8958de87158e9990dc7da

    I like this approach. The --rsb-file option can be used to make a patch name unique such as pre-pending rtems-4.11- to the start.

    Comment 9
    1. Sebastian Huber, Mon, 27 Mar 2017 05:18:29 GMT

    I think we should copy everything we need to a place we can control. URLs may get out of date and web servers may disappear. GCC snapshots seem to be only available for six months or so.

    Comment 10
    1. Sebastian Huber, Mon, 27 Mar 2017 05:20:21 GMT

    Replying to Sebastian Huber:

    I think we should stop to use subdirectories in the RTEMS tools for the patches.

    In case we copy everything into one directory on the patch consumer side, e.g. RSB, release directory, then we should not use subdirectories to make a patch unique on the patch provider side, e.g. RTEMS tools.

    Comment 11
    1. Chris Johns, Mon, 27 Mar 2017 05:42:35 GMT

    Replying to Sebastian Huber:

    I think we should copy everything we need to a place we can control. URLs may get out of date and web servers may disappear.

    For a release this is what happens. The directory for 4.11.1 is:

    ​https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.1/sources/

    and this is all the source for that release.

    I am not sure I follow the context of "copy everything". In terms of a time line the only points that matter are the release branch heads for the active and previous branch and master. I do not see any value in a single collection point for any and every patch the RSB references over time.

    Attempting to make sure all commits in the RSB are functional does not make sense. Hosts change and this effects the RSB so there are 2 dependent variables in play.

    GCC snapshots seem to be only available for six months or so.

    Yes as we have discovered. I am fine with an FTP area on the ftp.rtems.org being set up for special cases if we have a need and gcc fills this role. If a release references a GCC snapshot when the release will contain a copy. The downside of this is a clutter of files that are of no value sitting around.

    In case we copy everything into one directory on the patch consumer side, e.g. RSB, release directory, then we should not use subdirectories to make a patch unique on the patch provider side, e.g. RTEMS tools.

    Yes, and I am for us not using rtems-tools for patches any more.

    Comment 12
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 13
    1. Sebastian Huber, Thu, 08 Jun 2017 07:54:08 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    The consensus seems to be that rtems-tools should no longer be used for patches.

    Comment 14
    1. Sebastian Huber, Mon, 16 Oct 2017 06:26:07 GMT
    2. component: changed from unspecified to tool/rsb
    Comment 15
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 16
    1. Sebastian Huber, Mon, 13 Nov 2017 07:39:52 GMT

    In 3a32d15/rtems-tools:

    Add tool patches warning Update #2949.

    2951 - Error path in rtems-gcc-6.3.0-newlib-2.5.0.20170228-1.cfg

    Link https://devel.rtems.org/ticket/2951
    Id 2951
    Reporter alexgerbor
    Created 24 March 2017 14:54:37
    Modified 9 November 2017 06:27:14
    Owner chrisj@…
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords newlib, 4.12, build, path
    Cc  
    Blocking  
    Blocked by  

    Description

    newlib-ARM-Optimize-IEEE-754-sqrt-implementation.diff in path ​https://git.rtems.org/rtems-tools/plain/tools/4.12/newlib/arm/ not found

    In rtems-gcc-6.3.0-newlib-2.5.0.20170228-1.cfg there error:
    %patch add newlib %{rtems_newlib_patches}/arm/newlib-ARM-Optimize-IEEE-754-sqrt-implementation.diff

    Log from execute /source-builder/sb-set-builder:

    download: (full) ​https://git.rtems.org/rtems-tools/plain/tools/4.12/newlib/arm/newlib-ARM-Optimize-IEEE-754-sqrt-implementation.diff -> patches/newlib-ARM-Optimize-IEEE-754-sqrt-implementation.diff
    download: ​https://git.rtems.org/rtems-tools/plain/tools/4.12/newlib/arm/newlib-ARM-Optimize-IEEE-754-sqrt-implementation.diff -> patches/newlib-ARM-Optimize-IEEE-754-sqrt-implementation.diff
    download: no ssl context
    download: ​https://git.rtems.org/rtems-tools/plain/tools/4.12/newlib/arm/newlib-ARM-Optimize-IEEE-754-sqrt-implementation.diff: error: HTTP Error 404: Not found
    error: downloading ​https://git.rtems.org/rtems-tools/plain/tools/4.12/newlib/arm/newlib-ARM-Optimize-IEEE-754-sqrt-implementation.diff: all paths have failed, giving up

    Comment 1
    1. Chris Johns, Sun, 26 Mar 2017 03:49:43 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In b47a811/rtems-source-builder:

    4.11/arm: Fix the path to the sqrt patch. Use the upstream patch sent to the newlib mailing list. Closes #2951.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2954 - ARM: Optimize context switch

    Link https://devel.rtems.org/ticket/2954
    Id 2954
    Reporter Sebastian Huber
    Created 27 March 2017 07:36:00
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Set CPU_ENABLE_ROBUST_THREAD_DISPATCH to TRUE. In this case the interrupts are always enabled during a context switch even after interrupt processing (see #2751). Remove the CPSR from the context control since it contains only volatile bits.

    Comment 1
    1. Sebastian Huber, Tue, 28 Mar 2017 08:34:46 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In cd3d747/rtems:

    arm: Optimize context switch Set CPU_ENABLE_ROBUST_THREAD_DISPATCH to TRUE. In this case the interrupts are always enabled during a context switch even after interrupt processing (see #2751). Remove the CPSR from the context control since it contains only volatile bits. Close #2954.
    Comment 2
    1. Sebastian Huber, Mon, 16 Oct 2017 06:21:19 GMT
    2. component: changed from score to arch/arm
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2957 - Shared memory support internal locking is broken

    Link https://devel.rtems.org/ticket/2957
    Id 2957
    Reporter Sebastian Huber
    Created 28 March 2017 05:50:01
    Modified 9 November 2017 06:27:14
    Owner Gedare Bloom
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The top level lock is an ISR lock (interrupt disable/enable or SMP lock) and the low level lock is potentially a mutex. The problem is exposed by test psxshm02:

    #0  _Terminate (the_source=INTERNAL_ERROR_CORE, the_error=31) at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:35
    #1 0x00111654 in _Internal_error (core_error=INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT) at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:52
    #2 0x00117010 in _Thread_Do_dispatch (cpu_self=0x2035c0 <_Per_CPU_Information>, level=1611071955) at ../../../../../../rtems/c/src/../../cpukit/score/src/threaddispatch.c:190
    #3 0x0011a568 in _Thread_Dispatch_enable (cpu_self=0x2035c0 <_Per_CPU_Information>) at ../../cpukit/../../../realview_pbx_a9_qemu/lib/include/rtems/score/threaddispatch.h:227
    #4 0x0011b6c4 in _Thread_Change_life (clear=THREAD_LIFE_PROTECTED, set=THREAD_LIFE_PROTECTED, ignore=(unknown: 0)) at ../../../../../../rtems/c/src/../../cpukit/score/src/threadrestart.c:684
    #5 0x0011b6ea in _Thread_Set_life_protection (state=THREAD_LIFE_PROTECTED) at ../../../../../../rtems/c/src/../../cpukit/score/src/threadrestart.c:691
    #6 0x0010f3dc in _API_Mutex_Lock (the_mutex=0x2037d8) at ../../../../../../rtems/c/src/../../cpukit/score/src/apimutexlock.c:31
    #7 0x001050a0 in _RTEMS_Lock_allocator () at ../../cpukit/../../../realview_pbx_a9_qemu/lib/include/rtems/score/apimutex.h:120
    #8 0x00105442 in rtems_heap_allocate_aligned_with_boundary (size=10004, alignment=0, boundary=0) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/malloc_deferred.c:89
    #9 0x001055a6 in malloc (size=10004) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/malloc.c:39
    #10 0x0011e820 in realloc (ptr=0x0, size=10004) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/realloc.c:62
    #11 0x0010b1a2 in _POSIX_Shm_Object_resize_from_heap (shm_obj=0x204870, size=10004) at ../../../../../../rtems/c/src/../../cpukit/posix/src/shmheap.c:59
    #12 0x0010b6ac in shm_ftruncate (iop=0x202cf8 , length=10004) at ../../../../../../rtems/c/src/../../cpukit/posix/src/shmopen.c:83
    #13 0x00104cfc in ftruncate (fd=3, length=10004) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/ftruncate.c:37
    #14 0x001008e0 in POSIX_Init (argument=0x0) at ../../../../../../../rtems/c/src/../../testsuites/psxtests/psxshm02/init.c:54
    #15 0x001201ee in _Thread_Entry_adaptor_pointer (executing=0x2041a8) at ../../../../../../rtems/c/src/../../cpukit/score/src/threadentryadaptorpointer.c:25
    #16 0x00120302 in _Thread_Handler () at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:88
    Comment 1
    1. Gedare Bloom, Tue, 28 Mar 2017 19:39:49 GMT

    Yes: the shm code has some rather questionable design choices in its locking patterns. Here it acquires a thread_queue and then calls a user plugin function, in this case malloc is called which eventually leads to the error shown.

    Is there somewhere with guidance written for how to use the various lock constructs available in RTEMS? Or what are their constraints on use. Because I didn't even know this was a problem, and apparently did not spend much time thinking about this while writing the code.

    The shm code uses 2 locking patterns. The one causing a problem here is the use of a thread_queue to protect the invocations to operations on the shared-memory object. This should be some fine-grained mutex lock that allows the operation invoked to also acquire/release internal locks such as is needed by malloc.

    The other lock used is the _Objects_Allocator_lock to protect the integrity of the POSIX_Shm_Control Object. I think this one is fine.

    Comment 2
    1. Sebastian Huber, Wed, 29 Mar 2017 05:34:52 GMT

    Replying to Gedare:

    Yes: the shm code has some rather questionable design choices in its locking patterns. Here it acquires a thread_queue and then calls a user plugin function, in this case malloc is called which eventually leads to the error shown.

    Is there somewhere with guidance written for how to use the various lock constructs available in RTEMS? Or what are their constraints on use. Because I didn't even know this was a problem, and apparently did not spend much time thinking about this while writing the code.

    Good question, maybe we should something add to the manual, e.g. in Key Concepts, 3.3 Communication and Synchronization.

    The shm code uses 2 locking patterns. The one causing a problem here is the use of a thread_queue to protect the invocations to operations on the shared-memory object. This should be some fine-grained mutex lock that allows the operation invoked to also acquire/release internal locks such as is needed by malloc.

    The thread queue should be replaced with a mutex. For simplicity, maybe just the allocator mutex. We really need the self-contained mutexes for internal use.

    The other lock used is the _Objects_Allocator_lock to protect the integrity of the POSIX_Shm_Control Object. I think this one is fine.

    Yes.

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Gedare Bloom, Fri, 30 Jun 2017 13:21:04 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    fixed in bd9d5ebc33c35d91b5ca0746b6b78a365eeb726d

    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2958 - Add some popular benchmark programs to the testsuite

    Link https://devel.rtems.org/ticket/2958
    Id 2958
    Reporter Sebastian Huber
    Created 28 March 2017 13:10:52
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add dhrystone, whetstone and linpack benchmark programs to the testsuite. This may help to evaluate compiler settings, compiler versions and processors.

    Comment 1
    1. Sebastian Huber, Wed, 29 Mar 2017 06:12:40 GMT

    In 0027682/rtems:

    benchmarks: Add benchmark templates Update #2958.
    Comment 2
    1. Sebastian Huber, Wed, 29 Mar 2017 06:12:53 GMT

    In 317c1f4/rtems:

    benchmarks/dhrystone: Import Import dhrystone sources from: ​http://www.netlib.org/benchmark/dhry-c Update #2958.
    Comment 3
    1. Sebastian Huber, Wed, 29 Mar 2017 06:13:05 GMT

    In 954ca41/rtems:

    benchmarks/dhrystone: Port to RTEMS Update #2958.
    Comment 4
    1. Sebastian Huber, Wed, 29 Mar 2017 06:13:17 GMT

    In 8783660/rtems:

    benchmarks/linpack: Import Import linpack sources from: ​http://www.netlib.org/benchmark/linpack-pc.c Update #2958.
    Comment 5
    1. Sebastian Huber, Wed, 29 Mar 2017 06:13:28 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 0a16d5f/rtems:

    benchmarks/linpack: Port to RTEMS Close #2958.
    Comment 6
    1. Sebastian Huber, Wed, 29 Mar 2017 06:13:40 GMT

    In 3785f937/rtems:

    benchmarks/whetstone: Import Import whetstone sources from: ​http://www.netlib.org/benchmark/whetstone.c Update #2958.
    Comment 7
    1. Sebastian Huber, Wed, 29 Mar 2017 06:13:52 GMT

    In a1c60b56/rtems:

    benchmarks/whetstone: Port to RTEMS Update #2958.
    Comment 8
    1. Sebastian Huber, Tue, 10 Oct 2017 06:46:55 GMT
    2. component: changed from testing to unspecified
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2959 - arm/libdl: C++ exception index tables may not be ordered correctly

    Link https://devel.rtems.org/ticket/2959
    Id 2959
    Reporter Chris Johns
    Created 29 March 2017 06:32:17
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity major
    Keywords libdl
    Cc  
    Blocking  
    Blocked by  

    Description

    The ARM EXIDX sections have the SHF_LINK_ORDER flag set and this is not honored by libdl which means the section order in the ELF file needs to be the correct order of the functions in the address map.

    Add support to libdl to follow the link-to order.

    Comment 1
    1. Chris Johns, Fri, 31 Mar 2017 02:57:18 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In bba48d9/rtems:

    libdl: Support link ordered loading of ELF sections. The ARM C++ exception ABI uses an address ordered index table to locate the correct frame data and this requires the EXIDX sections are loaded in the order the order the matching text is loaded. The EXIDX sections set the SHF_LINK_ORDER flag and link field. This patch adds support to load those flagged sections in the linked-to section order. Updates #2955. Closes #2959
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2962 - Set test configurations to reflect test results.

    Link https://devel.rtems.org/ticket/2962
    Id 2962
    Reporter Chris Johns
    Created 31 March 2017 04:43:37
    Modified 5 June 2020 04:32:03
    Owner  
    Type defect
    Component test
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity blocker
    Keywords testsuite testing GCI
    Cc  
    Blocking  
    Blocked by  

    Description

    Tests can be set to the result we expect such as expected-fail, user-input and indeterminate as well as excluded so we can maintain accurate results for the testsuite.

    This ticket covers setting of the correct state for all tests for tier 1 BSPs. Please add an "Updates #" for this ticket to any related commits and once done we can close this ticket.

    Note: I have add a top level test configuration file called testsuites/rtems.tcfg that lets us specify a test configuration for all BSPs.

    Comment 1
    1. Sebastian Huber, Tue, 10 Oct 2017 06:46:55 GMT
    2. component: changed from testing to unspecified
    Comment 2
    1. Joel Sherrill, Thu, 12 Oct 2017 02:47:16 GMT
    2. owner: changed from joel.sherrill@… to Chris Johns
    3. status: changed from new to assigned
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 4
    1. Joel Sherrill, Sun, 14 Oct 2018 01:10:08 GMT
    2. keywords: GCI added

    Get Chris to write GCI instructions.

    Comment 5
    1. Chris Johns, Sun, 14 Oct 2018 22:11:26 GMT
    Run the test suite for a bsp. Get the list of failures. Update or create a bsps///config/-testsuite.tcfg adding a line for each failure we __expect__ to get with:
    expected:  
    Comment 6
    1. Chris Johns, Fri, 19 Oct 2018 00:26:06 GMT
    2. owner: Chris Johns deleted
    Comment 7
    1. Chris Johns, Thu, 15 Nov 2018 22:58:12 GMT
    2. severity: changed from normal to blocker

    We need to document in the tests which tests are known to fail for specific archs or BSPs. It is important for us to be able to tell a user this is what we have baselined in a release.

    Comment 8
    1. Chris Johns, Thu, 22 Nov 2018 02:09:42 GMT

    The loopback test needs to be set to USER-INPUT to avoid a timeout when testing the samples with a network build.

    Comment 9
    1. Chris Johns, Tue, 28 Apr 2020 05:33:14 GMT

    Looking at the build reports I see a differences with the erc32 BSP between no debug and RTEMS_DEBUG. Should the headwalk test like it does?

    ​https://lists.rtems.org/pipermail/build/2020-April/014203.html

    Comment 10
    1. Sebastian Huber, Wed, 29 Apr 2020 04:58:33 GMT

    In a8f0d94/rtems:

    libtests/heapwalk: Fix for RTEMS_DEBUG Update #2962.
    Comment 11
    1. Chris Johns, Tue, 05 May 2020 23:56:58 GMT
    2. component: changed from unspecified to test
    Comment 12
    1. Chris Johns, Wed, 06 May 2020 21:00:33 GMT

    In 89f57a66/rtems:

    testsuite: Add the BSP architecture to the include path Updates #2962
    Comment 13
    1. Chris Johns, Wed, 06 May 2020 21:00:37 GMT

    In 7d00247/rtems:

    testsuite: Add expected-fail to erc32, leon2, and leon3 BSPs Updates #2962
    Comment 14
    1. Chris Johns, Wed, 06 May 2020 21:00:44 GMT

    In 1b1755d9/rtems:

    testsuite: Add expected-fail to psim Updates #2962
    Comment 15
    1. Chris Johns, Wed, 06 May 2020 21:00:48 GMT

    In 7e3af67/rtems:

    testsuite: Add expected-fail to xilinx's zedboard, a9_qemu, zc702 and zc706 Updates #2962
    Comment 16
    1. Chris Johns, Wed, 06 May 2020 21:00:51 GMT

    In 084ea83/rtems:

    testsuite: Add expected-fail to beagleboneblack Updates #2962
    Comment 17
    1. Sebastian Huber, Fri, 05 Jun 2020 04:32:03 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    The failures on powerpc/psim are due to #3982. For the psxfenv01 failures see #3996, #3997, and #3998. For arm/beagleboneblack see #3999. For the arm/xilinx-zynq see #4000. For dl06 on arm see #4001.

    All test failures which need to be looked at have now tickets.


    2963 - Add a testsuite top level confguration file that is common to all tests.

    Link https://devel.rtems.org/ticket/2963
    Id 2963
    Reporter Chris Johns
    Created 31 March 2017 04:49:26
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords testing
    Cc  
    Blocking  
    Blocked by  

    Description

    Add the file testsuites/rtems.tcfg to hold test states common to all BSPs. This lets us globally set a test state.

    For example fileio is user-input.

    Note, user-input will be added a test state to test this file.

    Comment 1
    1. Sebastian Huber, Fri, 31 Mar 2017 04:59:42 GMT

    I am not very fond of global files. The tests should be self contained. Maybe add some special comments to the test sources like in the GCC test suite?

    /* { dg-options "-mthumb -Os" } */
    /* { dg-require-effective-target arm_thumb2_ok } */
    /* { dg-final { scan-assembler "ands" } } */ 
    Comment 2
    1. Chris Johns, Fri, 31 Mar 2017 06:26:42 GMT

    I have never looked at the gcc testsuite and from what I have read about it was not flattering.

    I do not think adding 500+ files to state fileio is a user-input test and will never complete is not good. Maybe global is not a great word, maybe common is better. We need accurate data to determine the results of tests.

    It is similar to the work you have been doing to have a common linkercmd file where ever possible. It is the same thing or are you saying we should create a separate linker command file for every bsp as well? ;)

    Look at the results with a work in progress rtems-test for erc32-run:

    Passed:        546
    Failed:          1
    User Input:      4
    Expected Fail:   0
    Indeterminate:   0
    Timeout:         6
    Invalid:         1
    ------------------
    Total:         558
    Failures:
     spcontext01.exe
    User Input:
     fileio.exe
     top.exe
     termios.exe
     monitor.exe
    Timeouts:
     jffs2_fssymlink.exe
     mrfs_fserror.exe
     dhrystone.exe
     fsdosfsformat01.exe
     imfs_fsrdwr.exe
     whetstone.exe
    Invalid:
     minimum.exe
    Average test time: 0:00:00.481800
    Testing time     : 0:04:28.844749 

    Note, the benchmark tests have broken parallel testing because of the time they now take.

    Comment 3
    1. Sebastian Huber, Fri, 31 Mar 2017 06:32:12 GMT

    Replying to Chris Johns:

    I have never looked at the gcc testsuite and from what I have read about it was not flattering.

    My comment was not about the GCC testsuite in general.

    I do not think adding 500+ files to state fileio is a user-input test and will never complete is not good. Maybe global is not a great word, maybe common is better. We need accurate data to determine the results of tests.

    Why 500+ files, its just one:

    diff --git a/testsuites/samples/fileio/init.c b/testsuites/samples/fileio/init.c
    index 07ec2c6..68942e8 100644
    --- a/testsuites/samples/fileio/init.c
    +++ b/testsuites/samples/fileio/init.c
    @@ -34,6 +34,7 @@
    `#include `
    `#include `
    +/* FANCY TEST COMMENT: user-input */
     const char rtems_test_name[] = "FILE I/O";
    `#if FILEIO_BUILD 

    It is similar to the work you have been doing to have a common linkercmd file where ever possible. It is the same thing or are you saying we should create a separate linker command file for every bsp as well? ;)

    Look at the results with a work in progress rtems-test for erc32-run:

    Passed:        546`
    Failed:          1
    User Input:      4
    Expected Fail:   0
    Indeterminate:   0
    Timeout:         6
    Invalid:         1
    ------------------
    Total:         558
    Failures:
     spcontext01.exe
    User Input:
     fileio.exe
     top.exe
     termios.exe
     monitor.exe
    Timeouts:
     jffs2_fssymlink.exe
     mrfs_fserror.exe
     dhrystone.exe
     fsdosfsformat01.exe
     imfs_fsrdwr.exe
     whetstone.exe
    Invalid:
     minimum.exe
    Average test time: 0:00:00.481800
    Testing time     : 0:04:28.844749 

    Note, the benchmark tests have broken parallel testing because of the time they now take.

    On my host these benchmark tests did run less than 3 minutes.

    Comment 4
    1. Chris Johns, Fri, 31 Mar 2017 07:05:39 GMT

    Replying to Sebastian Huber:

    Replying to Chris Johns:

    I do not think adding 500+ files to state fileio is a user-input test and will never complete is not good. Maybe global is not a great word, maybe common is better. We need accurate data to determine the results of tests.

    Why 500+ files, its just one:

    diff --git a/testsuites/samples/fileio/init.c b/testsuites/samples/fileio/init.c
    index 07ec2c6..68942e8 100644
    --- a/testsuites/samples/fileio/init.c
    +++ b/testsuites/samples/fileio/init.c
    @@ -34,6 +34,7 @@
    `#include `
    `#include `
    +/* FANCY TEST COMMENT: user-input */
     const char rtems_test_name[] = "FILE I/O";
    `#if FILEIO_BUILD 

    Sure I thought you were talking about tcfg files. There is no standard for this plus and how does the comment get to rtems-test.

    I am leveraging the expected-fail mechanism to handle this. That needs to be external to test.

    All I am doing is collecting these things into a common place and a common framework.

    It is similar to the work you have been doing to have a common linkercmd file where ever possible. It is the same thing or are you saying we should create a separate linker command file for every bsp as well? ;)

    Look at the results with a work in progress rtems-test for erc32-run:

    Passed:        546`
    Failed:          1
    User Input:      4
    Expected Fail:   0
    Indeterminate:   0
    Timeout:         6
    Invalid:         1
    ------------------
    Total:         558
    Failures:
     spcontext01.exe
    User Input:
     fileio.exe
     top.exe
     termios.exe
     monitor.exe
    Timeouts:
     jffs2_fssymlink.exe
     mrfs_fserror.exe
     dhrystone.exe
     fsdosfsformat01.exe
     imfs_fsrdwr.exe
     whetstone.exe
    Invalid:
     minimum.exe
    Average test time: 0:00:00.481800
    Testing time     : 0:04:28.844749 

    Note, the benchmark tests have broken parallel testing because of the time they now take.

    On my host these benchmark tests did run less than 3 minutes.

    All cores fully loaded?

    Comment 5
    1. Chris Johns, Mon, 03 Apr 2017 22:11:13 GMT
    2. owner: changed from joel.sherrill@… to Chris Johns
    Comment 6
    1. Chris Johns, Mon, 03 Apr 2017 23:52:54 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 258bda3/rtems:

    testsuite: Add a common test configuration. Fix configure.ac and Makefile.am errors. Add a top level test configuration file for test states that are common to all BSPs. This saves adding a test configuration (tcfg) file for every BSP. Add the test states 'user-input' and 'benchmark'. This lets 'rtems-test' stop the test rather than waiting for a timeout or letting a benchmark run without the user asking for it to run. Implement rtems-test-check in Python to make it faster. The shell script had grown to a point it was noticably slowing the build down. Fix the configure.ac and Makefile.am files for a number of the test directories. The files are difficiult to keep in sync with the number of tests and mistakes can happen such as tests being left out of the build. The test fsrofs01 is an example. Also a there was a mix of SUBDIRS and _SUBDIRS being used and only _SUBDIRS should be used. Fix the test fsrofs01 so it compiles. Closes #2963.
    Comment 7
    1. Sebastian Huber, Tue, 10 Oct 2017 06:46:55 GMT
    2. component: changed from testing to unspecified
    Comment 8
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2965 - bootstrap sort inconsistent with sb-bootstrap for acinclude

    Link https://devel.rtems.org/ticket/2965
    Id 2965
    Reporter Gedare Bloom
    Created 31 March 2017 19:48:58
    Modified 9 November 2017 06:27:14
    Owner Gedare Bloom <gedare@…>
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The output of bootstrap does not use a consistent sort order with sb-bootstrap. The difference appears to be in the default behavior of the sort command versus Python's sorted. By forcing the locale to C, sort should have a consistent behavior.

    Comment 1
    1. Gedare Bloom, Thu, 13 Apr 2017 17:01:12 GMT
    2. owner: set to Gedare Bloom <gedare@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 3be28ee6/rtems:

    bootstrap: make sort use C locale consistently Closes #2965.
    Comment 2
    1. Gedare Bloom, Thu, 13 Apr 2017 17:19:04 GMT

    In 1731757c/rtems:

    bootstrap: regenerate files after sort order fix Updates #2965.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2967 - ARM: Change ABI to not use short enums

    Link https://devel.rtems.org/ticket/2967
    Id 2967
    Reporter Sebastian Huber
    Created 3 April 2017 06:07:23
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component tool/gcc
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Whether enums are short or not is left open in the ARM EABI. On Linux and FreeBSD no short enums are used. Otherwise short enums are enabled by default.

    Short enums may cause hard to find issues with 3rd party software, since the are quite unusual in general, e.g.

    ​https://git.rtems.org/rtems-libbsd/commit/freebsd/include/rpc?id=9880635f2e642380b69b85e00271649b3a2fc2de

    The data and structure layout may suddenly change in case enumeration values are added/removed. The benefit of short enums is probably not worth the trouble, since the packed compiler attribute can be used to individually make an enum short.

    The reason for not choosing no short enums during the ARM EABI introduction was an issue with Newlib. This is addressed with the following patch:

    ​https://sourceware.org/ml/newlib/2017/msg00238.html

    Comment 1
    1. Sebastian Huber, Mon, 03 Apr 2017 06:07:37 GMT
    2. owner: changed from joel.sherrill@… to Sebastian Huber
    3. status: changed from new to accepted
    Comment 2
    1. Sebastian Huber, Fri, 07 Apr 2017 07:07:15 GMT

    GCC changes are in place:

    ​https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=246753 ​https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=246754

    Comment 3
    1. Sebastian Huber, Fri, 07 Apr 2017 07:19:04 GMT

    GCC website update done (GCC 6.4 changes show up once released):

    ​https://gcc.gnu.org/gcc-6/changes.html ​https://gcc.gnu.org/gcc-7/changes.html

    Comment 4
    1. Sebastian Huber, Thu, 08 Jun 2017 07:30:12 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    Fixed due to change to GCC 7.1.

    Comment 5
    1. Sebastian Huber, Tue, 10 Oct 2017 05:58:26 GMT
    2. component: changed from GCC to tool/gcc
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2968 - newlib inttypes.h is missing some methods

    Link https://devel.rtems.org/ticket/2968
    Id 2968
    Reporter Joel Sherrill
    Created 3 April 2017 14:06:21
    Modified 26 March 2018 17:18:20
    Owner  
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords POSIX-Compliance
    Cc  
    Blocking  
    Blocked by  

    Description

    inttypes.h defines some methods which are not present but required for POSIX compliance. They are also included in the FACE General Purpose Profile.

    intmax_t imaxabs(intmax_t);
    imaxdiv_t imaxdiv(intmax_t, intmax_t);
    intmax_t strtoimax(const char *restrict, char __restrict, int);
    uintmax_t strtoumax(const char *restrict, char __restrict, int);
    intmax_t wcstoimax(const wchar_t *restrict, wchar_t __restrict, int);
    uintmax_t wcstoumax(const wchar_t *restrict, wchar_t __restrict, int);

    This was originally discussed here (​https://sourceware.org/ml/newlib/2013/msg00626.html) with follow up discussion here (​https://sourceware.org/ml/newlib/2017/msg00240.html).

    The consensus seems to be that the methods as currently implemented in FreeBSD address the concerns raised in that email thread.

    This ticket is complete when:

    • source for these methods is merged into newlib
    • methods are documented in newlib
    • RSB is updated appropriately
    • tests are added to RTEMS
    • RTEMS POSIX Compliance spreadsheet (​https://goo.gl/AXrnxO) is updated
    Comment 1
    1. Joel Sherrill, Mon, 03 Apr 2017 23:20:55 GMT
    2. keywords: POSIX-Compliance added
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 08 Jun 2017 07:51:50 GMT
    2. milestone: changed from 4.12.0 to Indefinite
    Comment 4
    1. Joel Sherrill, Mon, 26 Mar 2018 17:18:01 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    All of these methods are now present.

    Comment 5
    1. Joel Sherrill, Mon, 26 Mar 2018 17:18:20 GMT
    2. milestone: changed from Indefinite to 5.1

    2969 - qoriq BSPs depend on mkimage which is not always available

    Link https://devel.rtems.org/ticket/2969
    Id 2969
    Reporter Joel Sherrill
    Created 3 April 2017 19:15:56
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The following BSPs do not successfully build on the master because they use UBoot's mkimage which is not part of the standard RTEMS tools.

    qoriq_core_0
    qoriq_core_1
    qoriq_p1020rdb

    Comment 1
    1. Joel Sherrill, Mon, 03 Apr 2017 19:16:05 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Tue, 04 Apr 2017 05:09:35 GMT

    Ok, now I know why I didn't commit this patch years ago.

    Should we add the U-Boot mkimage to the RTEMS tools? It is GPL software.

    Comment 3
    1. Chris Johns, Tue, 04 Apr 2017 06:04:04 GMT

    Replying to Sebastian Huber:

    Should we add the U-Boot mkimage to the RTEMS tools? It is GPL software.

    No. The RSB is fine, maybe a rtems/config/bsps/qoriq build set could be added which builds everything for the user of the BSP including uboot.

    You could see if you can craft a configure test to detect the tool then update the build rule. This would allow those who do not have the tool to build and regression test building.

    I also suggest you provide instructions in the Wiki under ​https://devel.rtems.org/wiki/Boards on how to get and build uboot, create images etc.

    I see any post rules or stages as a wasted effort, even the size command. This should be handled outside of RTEMS. It is difficult to handle generically.

    Comment 4
    1. Sebastian Huber, Tue, 04 Apr 2017 06:08:25 GMT

    I am not sure if its easily possible to adjust anything in make/custom/* via the configure script.

    Comment 5
    1. Chris Johns, Tue, 04 Apr 2017 06:12:15 GMT

    Replying to Sebastian Huber:

    I am not sure if its easily possible to adjust anything in make/custom/* via the configure script.

    I am sure a bit of m4 and whole lot of ../ is all you need ;)

    Comment 6
    1. Sebastian Huber, Wed, 05 Apr 2017 05:10:15 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a7dc1550/rtems:

    bsp/qoriq: Comment out post-link hook The U-Boot mkimage is not available in general. Close #2969.
    Comment 7
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 8
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2976 - warnings in rtems-debugger-server.c

    Link https://devel.rtems.org/ticket/2976
    Id 2976
    Reporter Joel Sherrill
    Created 4 April 2017 19:58:37
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This should be present on any ARM or x86 build.

    cpukit/libdebugger/rtems-debugger-server.c:393:1: warning: control reaches end of non-void function [-Wreturn-type]
    cpukit/libdebugger/rtems-debugger-server.c:405:1: warning: control reaches end of non-void function [-Wreturn-type]

    Comment 1
    1. Joel Sherrill, Tue, 04 Apr 2017 19:58:47 GMT
    2. owner: changed from joel.sherrill@… to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Chris Johns, Wed, 19 Apr 2017 04:34:11 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 7f95cc0/rtems:

    libdebugger: Fix the mode on task create. Clean up warnings. Closes #2976.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:35:44 GMT
    2. component: changed from misc to unspecified
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2977 - warnings in Dhrystone Benchmark

    Link https://devel.rtems.org/ticket/2977
    Id 2977
    Reporter Joel Sherrill
    Created 4 April 2017 20:00:54
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The following warnings show up across the various BSPs for the dhrystone benchmark:

    grep "dhrystone.*warning" log/*

    log/epiphany-epiphany_sim.log:../../../../../../../rtems/c/src/../../testsuites/benchmarks/dhrystone/dhry_1.c:286:1: warning: control reaches end of non-void function [-Wreturn-type]
    log/powerpc-haleakala.log:../../../../../../../rtems/c/src/../../testsuites/benchmarks/dhrystone/dhry_1.c:244:3: warning: 'Int_2_Loc' may be used uninitialized in this function [-Wmaybe-uninitialized]
    log/powerpc-t32mppc.log:../../../../../../../rtems/c/src/../../testsuites/benchmarks/dhrystone/dhry_1.c:244:3: warning: 'Int_2_Loc' may be used uninitialized in this function [-Wmaybe-uninitialized]
    log/sparc64-niagara.log:../../../../../../../rtems/c/src/../../testsuites/benchmarks/dhrystone/dhry_1.c:220:40: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
    log/sparc64-niagara.log:../../../../../../../rtems/c/src/../../testsuites/benchmarks/dhrystone/dhry_1.c:231:40: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
    log/sparc64-usiii.log:../../../../../../../rtems/c/src/../../testsuites/benchmarks/dhrystone/dhry_1.c:220:40: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
    log/sparc64-usiii.log:../../../../../../../rtems/c/src/../../testsuites/benchmarks/dhrystone/dhry_1.c:231:40: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]

    Comment 1
    1. Joel Sherrill, Tue, 04 Apr 2017 20:01:22 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Wed, 05 Apr 2017 05:23:53 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 662b301/rtems:

    dhrystone: Fix warnings Close #2977.
    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2980 - pc586-sse does not compile fsjffs2gc01

    Link https://devel.rtems.org/ticket/2980
    Id 2980
    Reporter Joel Sherrill
    Created 5 April 2017 22:09:12
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution worksforme
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    After the tool upgrade, the pc586-sse BSP does not compile the test fsjffs2gc01:

    i386-rtems4.12-gcc -B../../../../../pc586-sse/lib/ -specs bsp_specs -qrtems -DHAVE_CONFIG_H -I. -I../../../../../../../rtems/c/src/../../testsuites/fstests/fsjffs2gc01 -I.. -I../../../../../../../rtems/c/src/../../testsuites/fstests/support -I../../../../../../../rtems/c/src/../../testsuites/fstests/jffs2_support -I../../../../../../../rtems/c/src/../../testsuites/fstests/../support/include -I../../../../../../../rtems/c/src/../../testsuites/fstests/../psxtests/include -mtune=pentium -march=pentium -msse2 -O2 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT fstest_support.o -MD -MP -MF .deps/fstest_support.Tpo -c -o fstest_support.o test -f '../support/fstest_support.c' || echo '../../../../../../../rtems/c/src/../../testsuites/fstests/fsjffs2gc01/'../support/fstest_support.c
    In file included from ../../../../../../../rtems/c/src/../../testsuites/fstests/fsjffs2gc01/../support/fstest_support.c:30:0:
    ../../../../../../../rtems/c/src/../../testsuites/fstests/../psxtests/include/pmacros.h:99:2: error: #error "unsupported size of off_t"

    #error "unsupported size of off_t"

    __

    gmake[6]: __* [fstest_support.o] Error 1
    gmake[6]: Leaving directory `/data/home/joel/rtems-work/rtems-testing/rtems/build-i386-pc586-sse-rtems/i386-rtems4.12/c/pc586-sse/testsuites/fstests/fsjffs2gc01

    Comment 1
    1. Joel Sherrill, Wed, 05 Apr 2017 22:09:23 GMT
    2. owner: changed from joel.sherrill@… to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 06 Apr 2017 08:07:25 GMT

    Works for me. Maybe a configure problem?

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 11 May 2017 07:45:09 GMT

    What is the status here?

    Comment 5
    1. Sebastian Huber, Thu, 08 Jun 2017 08:13:46 GMT
    2. status: changed from assigned to closed
    3. resolution: set to worksforme
    Comment 6
    1. Sebastian Huber, Tue, 10 Oct 2017 06:46:55 GMT
    2. component: changed from testing to unspecified
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2981 - testdata excludes on included tcfg files does not work

    Link https://devel.rtems.org/ticket/2981
    Id 2981
    Reporter Joel Sherrill
    Created 5 April 2017 22:28:03
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    It looks like the includes do not always work for .tcfg files. So far these BSPs do not appear to honor the excludes in an included file:

    log/m32c-m32csim.log
    log/mips-hurricane.log
    log/mips-rbtx4925.log
    log/mips-rbtx4938.log
    log/moxie-moxiesim.log

    mips and moxie are dl tests.

    Comment 1
    1. Joel Sherrill, Wed, 05 Apr 2017 22:28:14 GMT
    2. owner: changed from joel.sherrill@… to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Fri, 07 Apr 2017 17:02:42 GMT

    Still happens on my overnight build from master.

    Comment 3
    1. Chris Johns, Sat, 15 Apr 2017 02:00:30 GMT

    On OSX MIPS still have a sed issue:

    Mode = sf\|df
    xgcc: error: addsf3: No such file or directory
    make[4]: *** [addsf3.o] Error 1
    make[4]: *** Waiting for unfinished jobs....
    Suffix = si\|2\|3 
    Comment 4
    1. Chris Johns, Tue, 18 Apr 2017 02:28:52 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 18f63c0/rtems:

    testsuite: Fix rtems-test-check not excluding tests. The include file handling was broken. Add a test configuration data README. Closes #2981.
    Comment 5
    1. Chris Johns, Wed, 19 Apr 2017 03:02:29 GMT

    In 3d803af/rtems:

    testsuite: Fix rtems-test-check-py when a BSP has no tcfg file. Updates #2981.
    Comment 6
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 7
    1. Sebastian Huber, Tue, 10 Oct 2017 06:46:55 GMT
    2. component: changed from testing to unspecified
    Comment 8
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2982 - LibBSD broken with GCC+RTEMS changes

    Link https://devel.rtems.org/ticket/2982
    Id 2982
    Reporter Chris Johns
    Created 6 April 2017 00:21:53
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component tool/gcc
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority highest
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The RTEMS Header test is libbsd is broken. I assume including and no other is still a requirement. Maybe we need a test for this.

    The example code is:

    $ cat t.c
    /*
    /opt/work/rtems/4.12/bin/arm-rtems4.12-gcc -qrtems -B/opt/work/si/rtems/4.12/arm-rtems4.12/lib -B/opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/ --specs bsp_specs -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -ffunction-sections -fdata-sections -DHAVE_RTEMS_SCORE_CPUOPTS_H=1 t.c -c -o t.o
    */
    #include
    int main(int argc, char **argv) {
    (void)argc; (void)argv;
    return 0;
    }
    $ /opt/work/rtems/4.12/bin/arm-rtems4.12-gcc -qrtems -B/opt/work/si/rtems/4.12/arm-rtems4.12/lib -B/opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/ --specs bsp_specs -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -ffunction-sections -fdata-sections -DHAVE_RTEMS_SCORE_CPUOPTS_H=1 t.c -c -o t.o
    In file included from /opt/work/rtems/4.12/arm-rtems4.12/include/signal.h:6:0,
    from /opt/work/rtems/4.12/arm-rtems4.12/include/time.h:178,
    from /opt/work/rtems/4.12/arm-rtems4.12/include/sys/time.h:268,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/timestamp.h:43,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/thread.h:36,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/heap.h:22,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/rtems/types.h:26,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems.h:31,
    from t.c:7:
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/signal.h:53:3: error: unknown type name 'pthread_attr_t'
    pthread_attr_t *sigev_notify_attributes; /* Notification Attributes */
    ^~~~~~~~~~~~~~
    In file included from /opt/work/rtems/4.12/arm-rtems4.12/include/string.h:10:0,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/basedefs.h:49,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/types.h:23,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/cpu.h:32,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/system.h:23,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems.h:29,
    from t.c:7:
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/signal.h:202:5: error: unknown type name 'pthread_t'
    int _EXFUN(pthread_kill, (pthread_t thread, int sig));
    ^
    In file included from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/rtems/config.h:25:0,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/config.h:57,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems.h:33,
    from t.c:7:
    /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/rtems/tasks.h:425:3: error: unknown type name 'cpu_set_t'
    cpu_set_t *cpuset
    ^~~~~~~~~
    /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/rtems/tasks.h:458:9: error: unknown type name 'cpu_set_t'
    const cpu_set_t *cpuset
    ^~~~~~~~~
    /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/rtems/tasks.h:581:3: error: unknown type name 'cpu_set_t'
    cpu_set_t *cpuset
    ^~~~~~~~~
    $ cat t.cpp
    /*
    /opt/work/rtems/4.12/bin/arm-rtems4.12-g++ -qrtems -B/opt/work/si/rtems/4.12/arm-rtems4.12/lib -B/opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/ --specs bsp_specs -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -ffunction-sections -fdata-sections -DHAVE_RTEMS_SCORE_CPUOPTS_H=1 t.cpp -c -o t.o
    */
    #include
    int main(int argc, char **argv) {
    (void)argc; (void)argv;
    return 0;
    }
    $ /opt/work/rtems/4.12/bin/arm-rtems4.12-g++ -qrtems -B/opt/work/si/rtems/4.12/arm-rtems4.12/lib -B/opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/ --specs bsp_specs -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -ffunction-sections -fdata-sections -DHAVE_RTEMS_SCORE_CPUOPTS_H=1 t.cpp -c -o t.o
    In file included from /opt/work/rtems/4.12/arm-rtems4.12/include/signal.h:6:0,
    from /opt/work/rtems/4.12/arm-rtems4.12/include/time.h:178,
    from /opt/work/rtems/4.12/arm-rtems4.12/include/sys/time.h:268,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/timestamp.h:43,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/thread.h:36,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/heap.h:22,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/rtems/types.h:26,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems.h:31,
    from t.cpp:7:
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/signal.h:53:3: error: 'pthread_attr_t' does not name a type
    pthread_attr_t *sigev_notify_attributes; /* Notification Attributes */
    ^~~~~~~~~~~~~~
    In file included from /opt/work/rtems/4.12/arm-rtems4.12/include/string.h:10:0,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/basedefs.h:49,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/types.h:23,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/score/cpu.h:32,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/system.h:23,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems.h:29,
    from t.cpp:7:
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/signal.h:202:5: error: 'pthread_t' was not declared in this scope
    int _EXFUN(pthread_kill, (pthread_t thread, int sig));
    ^
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/signal.h:202:5: error: expected primary-expression before 'int'
    int _EXFUN(pthread_kill, (pthread_t thread, int sig));
    ^
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/signal.h:202:5: error: expression list treated as compound expression in initializer [-fpermissive]
    int _EXFUN(pthread_kill, (pthread_t thread, int sig));
    ^
    In file included from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/rtems/config.h:25:0,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/config.h:57,
    from /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems.h:33,
    from t.cpp:7:
    /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/rtems/tasks.h:425:3: error: 'cpu_set_t' has not been declared
    cpu_set_t *cpuset
    ^~~~~~~~~
    /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/rtems/tasks.h:458:9: error: 'cpu_set_t' does not name a type
    const cpu_set_t *cpuset
    ^~~~~~~~~
    /opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/include/rtems/rtems/tasks.h:581:3: error: 'cpu_set_t' has not been declared
    cpu_set_t *cpuset
    ^~~~~~~~~

    Note: The header test in libbsd is currently using C++ and I am not sure why.

    Comment 1
    1. Chris Johns, Thu, 06 Apr 2017 00:29:07 GMT
    2. owner: changed from joel.sherrill@… to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Chris Johns, Thu, 06 Apr 2017 02:17:54 GMT
    2. status: changed from assigned to closed
    3. resolution: set to invalid

    I cleaned the install paths and rebuilt and I see no error.

    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 05:58:26 GMT
    2. component: changed from GCC to tool/gcc
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2983 - Create <rtems/inttypes.h> to consolidate extensions to <inttypes.h>

    Link https://devel.rtems.org/ticket/2983
    Id 2983
    Reporter Joel Sherrill
    Created 6 April 2017 22:45:08
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill <joel@…>
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords printf, inttypes.h
    Cc  
    Blocking  
    Blocked by  

    Description

    Per discussion at ​https://lists.rtems.org/pipermail/devel/2017-April/017483.html, create to consolidate extensions to the C99 file. A quick search shows that there are the following set of defines which could be consolidated as a starting point. Then these are available to address other printf() format warnings.

    $ grep -r "#define PRI" . | grep -v PRIORITY | grep -v PRINT
    ./cpukit/libmisc/shell/main_time.c:#define PRIdtime_t PRId64
    ./cpukit/libmisc/shell/main_time.c:#define PRIdtime_t PRId32
    ./cpukit/libmisc/uuid/gen_uuid.c:#define PRIutime_t PRIu64
    ./cpukit/libmisc/uuid/gen_uuid.c:#define PRIutime_t PRIu32
    ./cpukit/libdl/rtl-shell.c:#define PRIdoff_t PRIo32
    ./cpukit/libdl/rtl-shell.c:#define PRIdoff_t PRIo64
    ./cpukit/libfs/src/nfsclient/src/dirutils.c:#define PRIomode_t PRIo64
    ./cpukit/libfs/src/nfsclient/src/dirutils.c:#define PRIomode_t PRIo32
    ./cpukit/libfs/src/nfsclient/src/dirutils.c:#define PRIdoff_t PRIo64
    ./cpukit/libfs/src/nfsclient/src/dirutils.c:#define PRIdoff_t PRIo32
    ./cpukit/libfs/src/rfs/rtems-rfs-dir.c:#define PRIooff_t PRIo64
    ./cpukit/libfs/src/rfs/rtems-rfs-dir.c:#define PRIooff_t PRIo32
    ./cpukit/libfs/src/rfs/rtems-rfs-rtems-file.c:#define PRIdoff_t PRId64
    ./cpukit/libfs/src/rfs/rtems-rfs-rtems-file.c:#define PRIdoff_t PRId32
    ./cpukit/libfs/src/rfs/rtems-rfs-rtems.c:#define PRIomode_t PRIo64
    ./cpukit/libfs/src/rfs/rtems-rfs-rtems.c:#define PRIomode_t PRIo32
    ./testsuites/psxtests/include/pmacros.h:#define PRIdoff_t PRIo64
    ./testsuites/psxtests/include/pmacros.h:#define PRIdoff_t PRIo32
    ./testsuites/psxtests/include/pmacros.h:#define PRIxblksize_t PRIx64
    ./testsuites/psxtests/include/pmacros.h:#define PRIxblksize_t PRIx32
    ./testsuites/psxtests/include/pmacros.h:#define PRIxblksize_t "lx"
    ./testsuites/psxtests/include/pmacros.h:#define PRIxblkcnt_t PRIx64
    ./testsuites/psxtests/include/pmacros.h:#define PRIxblkcnt_t PRIx32
    ./testsuites/psxtests/include/pmacros.h:#define PRIxblkcnt_t "lx"
    ./testsuites/libtests/termios01/init.c:#define PRIdrtems_termios_baud_t PRId32
    ./testsuites/support/include/pritime.h:#define PRIdtime_t PRId64
    ./testsuites/support/include/pritime.h:#define PRIdtime_t PRId32
    ./testsuites/support/include/tmacros.h:#define PRIxrtems_id PRIx16
    ./testsuites/support/include/tmacros.h:#define PRIxrtems_id PRIx32
    ./testsuites/support/include/tmacros.h:#define PRIdPriority_Control PRIu64
    ./testsuites/support/include/tmacros.h:#define PRIxPriority_Control PRIx64
    ./testsuites/support/include/tmacros.h:#define PRIdrtems_task_priority PRIu32
    ./testsuites/support/include/tmacros.h:#define PRIxrtems_task_priority PRIx32
    ./testsuites/support/include/tmacros.h:#define PRIdWatchdog_Interval PRIu32
    ./testsuites/support/include/tmacros.h:#define PRIdrtems_interval PRIdWatchdog_Interval
    ./testsuites/support/include/tmacros.h:#define PRIdThread_Entry_numeric_type PRIuPTR
    ./testsuites/support/include/tmacros.h:#define PRIdrtems_task_argument PRIdThread_Entry_numeric_type
    ./testsuites/support/include/tmacros.h:#define PRIxrtems_event_set PRIx32
    ./testsuites/support/include/tmacros.h:#define PRIxpthread_t PRIx32
    ./testsuites/support/include/tmacros.h:#define PRIxrtems_signal_set PRIx32
    ./testsuites/support/include/tmacros.h:#define PRIxino_t "lx"
    ./testsuites/support/include/primode.h:#define PRIomode_t PRIo64
    ./testsuites/support/include/primode.h:#define PRIomode_t PRIo32
    ./testsuites/sptests/sp21/init.c:#define PRIurtems_device_major_number PRIu32
    ./testsuites/sptests/sp08/init.c:#define PRIxModes_Control PRIx32
    ./testsuites/sptests/sp08/init.c:#define PRIxrtems_mode PRIxModes_Control
    ./testsuites/sptests/sp47/init.c:#define PRIXModes_Control PRIX32
    ./testsuites/sptests/sp47/init.c:#define PRIXrtems_mode PRIXModes_Control

    Comment 1
    1. Joel Sherrill, Tue, 18 Apr 2017 16:25:09 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In d420b67/rtems:

    Merge tmacros.h PRIxxx constants from testsuites/ into This completes the initial creation of rtems/inttypes.h based on all existing PRIxxx definitions contained in RTEMS Project owned code. closes #2983.
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2984 - Changing Trac milestone page fails.

    Link https://devel.rtems.org/ticket/2984
    Id 2984
    Reporter Chris Johns
    Created 6 April 2017 23:23:04
    Modified 9 November 2017 06:27:14
    Owner Amar Takhar
    Type infra
    Component unspecified
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority high
    Severity major
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Changing the default milestone is timing out. It has worked before. The error is:

    Gateway Timeout

    The gateway did not receive a timely response from the upstream server or application.

    Comment 1
    1. Amar Takhar, Fri, 07 Apr 2017 00:06:17 GMT
    2. owner: set to Amar Takhar
    3. status: changed from new to accepted

    Er, that is very weird I will look into this tonight.

    Comment 2
    1. Amar Takhar, Fri, 07 Apr 2017 00:16:23 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    Actually this was set in trac.ini I don't think you were able to change it before. I updated trac_version as per our chat.

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2990 - RTEMS Source Builder Fails on Windows Builds

    Link https://devel.rtems.org/ticket/2990
    Id 2990
    Reporter Worth Burruss
    Created 11 April 2017 13:45:49
    Modified 14 October 2018 00:25:12
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords windows, MSYS2, gcc
    Cc chrisj@…
    Blocking  
    Blocked by  

    Description

    The source Builder Fails to build 4.11 tools under MSYS2 and windows. Newer versions of MSYS use a version of gcc greater than 6.0 which can no longer be used to build older version of gcc.

    The attached patch is from the gcc mailing list and originally was for gcc version 5.3. It has been adjusted so that it applies to 4.9.3.

    This problem should also apply to linux and other systems that use newer gcc 6.0 and above.

    Attachments:

    1 Worth Burruss, Tue, 11 Apr 2017 13:46:55 GMT
      attach: set to gcc-4.9.3-20170404-1.patch
    Comment 1
    1. Chris Johns, Wed, 12 Apr 2017 01:09:21 GMT
    2. status: changed from new to assigned
    Comment 2
    1. Chris Johns, Wed, 12 Apr 2017 10:27:08 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In e85c673/rtems-source-builder:

    MSYS2: Patch to support newer packages. The patch is contributed by Worth Burruss. Closes #2990.
    Comment 3
    1. Chris Johns, Thu, 13 Apr 2017 07:48:24 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    Building 4.11.2-rc4 on Windows with a new MSYS2 install has an error on rtems-arm:

    In file included from ../../gcc-4.9.3/gcc/cp/except.c:1013:0:
    cfns.gperf: In function 'const char* libc_name_p(const char*, unsigned int)':
    cfns.gperf:101:1: error: 'const char* libc_name_p(const char*, unsigned int)' redeclared inline with 'gnu_inline' attribute
    cfns.gperf:26:14: note: 'const char* libc_name_p(const char*, unsigned int)' previously declared here
    cfns.gperf: At global scope:
    cfns.gperf:26:14: warning: inline function 'const char* libc_name_p(const char*, unsigned int)' used but never defined
    make[2]: *** [Makefile:1059: cp/except.o] Error 1 

    I am not sure the patch is ok so I am reopening this ticket.

    Comment 4
    1. Chris Johns, Fri, 26 May 2017 03:07:34 GMT

    The problem with ARM is the bset file includes an arch specific cfg file. This patch needs to be added to that file.

    I suggest you create a new cfg file with just this patch, remove it from config/tools/rtems-gcc-4.9-newlib-2.2.0-1.cfg, then include the file. Also add the include to config/tools/rtems-arm-gcc-4.9.3-newlib-2.2.0-20150423-1.cfg.

    Comment 5
    1. Chris Johns, Thu, 15 Jun 2017 02:50:23 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    Fixed with patch 2433c4b/rtems-source-builder.

    Comment 6
    1. Chris Johns, Mon, 07 Aug 2017 01:33:45 GMT
    2. status: changed from closed to reopened
    3. version: changed from 4.11 to 4.12
    4. resolution: fixed deleted
    5. milestone: changed from 4.11.2 to 4.12.0

    This bug effects m32c on the 4.12 (master) branch.

    Comment 7
    1. Chris Johns, Mon, 07 Aug 2017 23:41:35 GMT

    Windows (10 64bit) failures:

    dtc-1.4.1 epiphany gdb-7.8.1 lm32 gdb-7.12 microblaze gdb-7.12 nios2 gcc-7.1.0, newlib-2.5.0.20170623 powerpc gdb-7.12 sparc gdb-7.12

    We need all these issues resolved to branch 4.12.

    Comment 8
    1. Chris Johns, Mon, 07 Aug 2017 23:42:56 GMT

    dtc-1.4.1:

    convert-dtsv0-lexer.lex.c:398:0: error: "yywrap" redefined [-Werror]
    convert-dtsv0-lexer.lex.c:74:0: note: this is the location of the previous definition
    convert-dtsv0-lexer.l:41:21: fatal error: fnmatch.h: No such file or directory
    `#include `
                         ^ 
    Comment 9
    1. Joel Sherrill, Mon, 07 Aug 2017 23:51:44 GMT

    What's the gdb problem? Is it the same on all the targets failing?

    What about the nios2? That would seem to be a different issue.

    Comment 10
    1. Chris Johns, Mon, 07 Aug 2017 23:54:56 GMT

    lm32 gdb-7.12:

    ../../../gdb-7.12/sim/lm32/dv-lm32uart.c: In function 'lm32uart_io_read_buffer':
    ../../../gdb-7.12/sim/lm32/dv-lm32uart.c:207:3: error: unknown type name 'fd_set'
       fd_set fd;
       ^~~~~~ 
    Comment 11
    1. Chris Johns, Mon, 07 Aug 2017 23:55:49 GMT

    microblaze gdb-7.12:

    ../../../gdb-7.12/sim/microblaze/interp.c: In function 'microblaze_extract_unsigned_integer':
    ../../../gdb-7.12/sim/microblaze/interp.c:34:57: error: 'BIG_ENDIAN' undeclared (first use in this function)
    `#define target_big_endian (CURRENT_TARGET_BYTE_ORDER == BIG_ENDIAN)`
                                                             ^
    ../../../gdb-7.12/sim/microblaze/interp.c:52:8: note: in expansion of macro 'target_big_endian'
       if (!target_big_endian)
            ^~~~~~~~~~~~~~~~~
    ../../../gdb-7.12/sim/microblaze/interp.c:34:57: note: each undeclared identifier is reported only once for each function it appears in
    `#define target_big_endian (CURRENT_TARGET_BYTE_ORDER == BIG_ENDIAN)`
                                                             ^
    ../../../gdb-7.12/sim/microblaze/interp.c:52:8: note: in expansion of macro 'target_big_endian'
       if (!target_big_endian)
            ^~~~~~~~~~~~~~~~~
    ../../../gdb-7.12/sim/microblaze/interp.c: In function 'microblaze_store_unsigned_integer':
    ../../../gdb-7.12/sim/microblaze/interp.c:34:57: error: 'BIG_ENDIAN' undeclared (first use in this function)
    `#define target_big_endian (CURRENT_TARGET_BYTE_ORDER == BIG_ENDIAN)`
                                                             ^
    ../../../gdb-7.12/sim/microblaze/interp.c:74:8: note: in expansion of macro 'target_big_endian'
       if (!target_big_endian)
            ^~~~~~~~~~~~~~~~~ 
    Comment 12
    1. Chris Johns, Mon, 07 Aug 2017 23:59:07 GMT

    nios2 gcc-7.1.0, newlib-2.5.0.20170623:

    ../../../../../../../../../../gcc-7.1.0/libgcc/unwind-dw2-fde.c: At top level:
    ../../../../../../../../../../gcc-7.1.0/libgcc/unwind-dw2-fde.c:56:1: error: variable 'object_mutex' has initializer but incomplete type
     static __gthread_mutex_t object_mutex = __GTHREAD_MUTEX_INIT;
     ^~~~~~
    make[4]: *** [../../../../../../../../../../gcc-7.1.0/libgcc/static-object.mk:17: unwind-sjlj.o] Error 1
    In file included from ../../../../../../../../../../gcc-7.1.0/libgcc/gthr.h:148:0,
                     from ../../../../../../../../../../gcc-7.1.0/libgcc/emutls.c:31:
    ./gthr-default.h:51:30: error: '_MUTEX_INITIALIZER' undeclared here (not in a function); did you mean 'PTHREAD_MUTEX_INITIALIZER'?
    `#define __GTHREAD_MUTEX_INIT _MUTEX_INITIALIZER`
                                  ^
    ../../../../../../../../../../gcc-7.1.0/libgcc/emutls.c:58:41: note: in expansion of macro '__GTHREAD_MUTEX_INIT'
     static __gthread_mutex_t emutls_mutex = __GTHREAD_MUTEX_INIT;
                                             ^~~~~~~~~~~~~~~~~~~~
    ../../../../../../../../../../gcc-7.1.0/libgcc/emutls.c: In function '__emutls_get_address':
    ../../../../../../../../../../gcc-7.1.0/libgcc/emutls.c:159:13: warning: implicit declaration of function 'calloc' [-Wimplicit-function-declaration]
           arr = calloc (size + 1, sizeof (void *));
                 ^~~~~~
    ../../../../../../../../../../gcc-7.1.0/libgcc/emutls.c:159:13: warning: incompatible implicit declaration of built-in function 'calloc'
    ../../../../../../../../../../gcc-7.1.0/libgcc/emutls.c:159:13: note: include '' or provide a declaration of 'calloc'
    ../../../../../../../../../../gcc-7.1.0/libgcc/emutls.c:171:13: warning: implicit declaration of function 'realloc' [-Wimplicit-function-declaration]
           arr = realloc (arr, (size + 1) * sizeof (void *));
                 ^~~~~~~
    ../../../../../../../../../../gcc-7.1.0/libgcc/emutls.c:171:13: warning: incompatible implicit declaration of built-in function 'realloc'
    ../../../../../../../../../../gcc-7.1.0/libgcc/emutls.c:171:13: note: include '' or provide a declaration of 'realloc'
    ../../../../../../../../../../gcc-7.1.0/libgcc/emutls.c: At top level:
    ../../../../../../../../../../gcc-7.1.0/libgcc/emutls.c:58:26: error: storage size of 'emutls_mutex' isn't known
     static __gthread_mutex_t emutls_mutex = __GTHREAD_MUTEX_INIT;
                              ^~~~~~~~~~~~
    In file included from ../../../../../../../../../../gcc-7.1.0/libgcc/gthr.h:148:0,
                     from ../../../../../../../../../../gcc-7.1.0/libgcc/unwind-dw2-fde.c:37:
    ./gthr-default.h:51:30: error: '_MUTEX_INITIALIZER' undeclared here (not in a function); did you mean 'PTHREAD_MUTEX_INITIALIZER'?
    `#define __GTHREAD_MUTEX_INIT _MUTEX_INITIALIZER`
                                  ^
    ../../../../../../../../../../gcc-7.1.0/libgcc/unwind-dw2-fde.c:56:41: note: in expansion of macro '__GTHREAD_MUTEX_INIT'
     static __gthread_mutex_t object_mutex = __GTHREAD_MUTEX_INIT;
                                             ^~~~~~~~~~~~~~~~~~~~
    make[4]: *** [../../../../../../../../../../gcc-7.1.0/libgcc/static-object.mk:17: emutls.o] Error 1
    ../../../../../../../../../../gcc-7.1.0/libgcc/unwind-dw2-fde.c:56:26: error: storage size of 'object_mutex' isn't known
     static __gthread_mutex_t object_mutex = __GTHREAD_MUTEX_INIT;
                              ^~~~~~~~~~~~ 
    Comment 13
    1. Chris Johns, Tue, 08 Aug 2017 00:01:55 GMT

    powerpc gdb-7.12:

    ../sim/ppc/libsim.a(sim_calls.o): In function `sim_io_read_stdin':
    D:\opt\rtems\rsb.git\rtems\build\prg7xwm1\build\sim\ppc/../../../gdb-7.12/sim/ppc/sim_calls.c:302: undefined reference to `error'
    ../sim/ppc/libsim.a(sim_calls.o): In function `sim_io_write_stdout':
    D:\opt\rtems\rsb.git\rtems\build\prg7xwm1\build\sim\ppc/../../../gdb-7.12/sim/ppc/sim_calls.c:320: undefined reference to `error'
    ../sim/ppc/libsim.a(sim_calls.o): In function `sim_io_write_stderr':
    D:\opt\rtems\rsb.git\rtems\build\prg7xwm1\build\sim\ppc/../../../gdb-7.12/sim/ppc/sim_calls.c:339: undefined reference to `error'
    ../sim/ppc/libsim.a(sim_calls.o): In function `sim_io_printf_filtered':
    D:\opt\rtems\rsb.git\rtems\build\prg7xwm1\build\sim\ppc/../../../gdb-7.12/sim/ppc/sim_calls.c:358: undefined reference to `error'
    ../sim/ppc/libsim.a(sim_calls.o): In function `sim_load':
    D:\opt\rtems\rsb.git\rtems\build\prg7xwm1\build\sim\ppc/../../../gdb-7.12/sim/ppc/sim_calls.c:105: undefined reference to `error'
    ../sim/ppc/libsim.a(sim_calls.o):D:\opt\rtems\rsb.git\rtems\build\prg7xwm1\build\sim\ppc/../../../gdb-7.12/sim/ppc/sim_calls.c:125: more undefined references to `error' follow 

    Tracked in GDB here ​https://sourceware.org/bugzilla/show_bug.cgi?id=20863

    Comment 14
    1. Chris Johns, Tue, 08 Aug 2017 00:02:59 GMT

    sparc gdb-7.12:

    ../../../gdb-7.12/sim/erc32/sis.c: In function 'main':
    ../../../gdb-7.12/sim/erc32/sis.c:245:16: warning: implicit declaration of function 'fcntl' [-Wimplicit-function-declaration]
         termsave = fcntl(0, F_GETFL, 0);
                    ^~~~~
    ../../../gdb-7.12/sim/erc32/sis.c:245:25: error: 'F_GETFL' undeclared (first use in this function)
         termsave = fcntl(0, F_GETFL, 0);
                             ^~~~~~~
    ../../../gdb-7.12/sim/erc32/sis.c:245:25: note: each undeclared identifier is reported only once for each function it appears in 
    Comment 15
    1. Chris Johns, Wed, 09 Aug 2017 23:36:23 GMT

    epiphany gdb or binutils:

    syslex_wrap.o: In function `yylex':
    D:\opt\rtems\rsb.git\rtems\build\erg7xwm1\build\binutils/syslex.c:1097: undefined reference to `yywrap'
    collect2.exe: error: ld returned 1 exit status 
    Comment 16
    1. Chris Johns, Fri, 25 Aug 2017 01:25:41 GMT

    Windows (10 64bit) failures with the gcc-7.2.0 changes to the RSB:

    dtc-1.4.1 epiphany gdb-7.8.1 microblaze gdb-7.12 nios2 gcc-7.1.0, newlib-2.5.0.20170623 powerpc gdb-7.12 sparc gdb-7.12
    Comment 17
    1. Chris Johns, Fri, 25 Aug 2017 03:04:42 GMT

    DTC uses fnmatch and this function is not available on Windows in the MinGW environment. The use of this function makes it difficult to get this tool to work on native Windows.

    A couple of solutions come to mind:

    Fix the DTC tool. Commit a DTB to the moxie project for the DTS and remove the dependency.
    Comment 18
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 19
    1. Chris Johns, Sun, 14 Oct 2018 00:25:12 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    Replying to Chris Johns:

    DTC uses fnmatch and this function is not available on Windows in the MinGW environment. The use of this function makes it difficult to get this tool to work on native Windows.

    A couple of solutions come to mind:

    Fix the DTC tool. Commit a DTB to the moxie project for the DTS and remove the dependency.

    I will not fixing DTC on Windows. A new ticket can be opened if this is needed.


    2992 - Long path crashes the RSB when listing a directory.

    Link https://devel.rtems.org/ticket/2992
    Id 2992
    Reporter Chris Johns
    Created 14 April 2017 01:15:44
    Modified 14 October 2018 20:45:22
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity major
    Keywords RSB
    Cc  
    Blocking  
    Blocked by  

    Description

    Building LM32 on Windows crashes the RSB with a long path. The os.listdir call in Python on Windows is limited to 254 characters even if the path is Uncode.

    building: lm32-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-w64-mingw32-1
    Build Set: Time 0:29:19.809228
    Build Set: Time 3:47:43.385503
    Traceback (most recent call last):
    File "../source-builder/sb-set-builder", line 29, in
    setbuilder.run()
    File "../source-builder/sb/setbuilder.py", line 502, in run
    b.build(deps)
    File "../source-builder/sb/setbuilder.py", line 340, in build
    bs.build(deps, nesting_count)
    File "../source-builder/sb/setbuilder.py", line 354, in build
    self.build_package(configs[s], b)
    File "../source-builder/sb/setbuilder.py", line 194, in build_package
    _build.config.expand('%{_tmproot}'))
    File "../source-builder/sb/setbuilder.py", line 155, in root_copy
    self.copy(src, dst)
    File "../source-builder/sb/setbuilder.py", line 95, in copy
    path.copy_tree(src, dst)
    File "../source-builder/sb/path.py", line 232, in copy_tree
    copy_tree(srcname, dstname)
    File "../source-builder/sb/path.py", line 232, in copy_tree
    copy_tree(srcname, dstname)
    File "../source-builder/sb/path.py", line 232, in copy_tree
    copy_tree(srcname, dstname)
    File "../source-builder/sb/path.py", line 232, in copy_tree
    copy_tree(srcname, dstname)
    File "../source-builder/sb/path.py", line 232, in copy_tree
    copy_tree(srcname, dstname)
    File "../source-builder/sb/path.py", line 232, in copy_tree
    copy_tree(srcname, dstname)
    File "../source-builder/sb/path.py", line 232, in copy_tree
    copy_tree(srcname, dstname)
    File "../source-builder/sb/path.py", line 232, in copy_tree
    copy_tree(srcname, dstname)
    File "../source-builder/sb/path.py", line 232, in copy_tree
    copy_tree(srcname, dstname)
    File "../source-builder/sb/path.py", line 232, in copy_tree
    copy_tree(srcname, dstname)
    File "../source-builder/sb/path.py", line 232, in copy_tree
    copy_tree(srcname, dstname)
    File "../source-builder/sb/path.py", line 232, in copy_tree
    copy_tree(srcname, dstname)
    File "../source-builder/sb/path.py", line 232, in copy_tree
    copy_tree(srcname, dstname)
    File "../source-builder/sb/path.py", line 232, in copy_tree
    copy_tree(srcname, dstname)
    File "../source-builder/sb/path.py", line 232, in copy_tree
    copy_tree(srcname, dstname)
    File "../source-builder/sb/path.py", line 191, in copy_tree
    names = os.listdir(hsrc)
    TypeError: encoded string too long (269, maximum length 259)
    Comment 1
    1. Chris Johns, Tue, 18 Apr 2017 00:34:38 GMT

    I have looked into this issue in detail and it is complicated. At the heart of the problem is the inherent path limit in the WIN32 API which is documented in ​Naming Files, Paths, and Namespaces. There is also ​Python Issue 27731 which details how Python will respond.

    I see a couple of solution, one complicated and full of potential issues which others have solved, for example the MSYS2 shell, and the second is a simple hack. The complex solution is to step down to the Win32 API and selectively use Win32 API calls that support the Unicode extension to let the RSB work. I feel this is a lot of work and difficult to get to work. The second solution is to generate a script and to run it and let the shell on the host manage the issue. The RSB needs a shell to build most packages so it has to be present.

    We see the long file name issue when coping a tree and removing a tree.

    Comment 2
    1. Chris Johns, Thu, 15 Jun 2017 02:46:32 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Fixed with the patch 78c1524/rtems-source-builder.

    Comment 3
    1. Chris Johns, Mon, 07 Aug 2017 02:16:18 GMT
    2. status: changed from closed to reopened
    3. version: changed from 4.11 to 4.12
    4. resolution: fixed deleted
    5. milestone: changed from 4.11.2 to 4.12.0

    This 4.11 fix needs to be ported to 4.12.

    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 5
    1. Chris Johns, Sun, 14 Oct 2018 20:45:22 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    The patch in this ticket is applied to master.


    2993 - SMP assert in _Thread_Executing in libdebugger

    Link https://devel.rtems.org/ticket/2993
    Id 2993
    Reporter Chris Johns
    Created 14 April 2017 06:02:14
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The target code in libdebugger has support to recover from exceptions related to invalid memory accesses. GDB may request the server access memory on the target that results in an exception. The exception occurs on the server's remote connection thread and the server needs to recover and return and error to GDB.

    Running the debugger01 test with an SMP build of RTEMS and libbsd for xilinx_zedboard and issuing bt in GDB results in:

    *** LIBBSD DEBUGGER 1 TEST ***                                                                                                                                                                                                                                                                            [144/1950]
    shell:cannot set terminal attributes(/dev/console)
    RTEMS Shell on /devn/ecxounss0o:l e<.R TUEsMeS 'Nheexlups' dteov ilcies>t
    ccogmemma0n:d s<.C
    adence CGEM Gigabit Ethernet Interface> on nexus0
    miibus0: on cgem0
    [/] # e1000phy0: PHY 0 on miibus0
    e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
    cgem0: Ethernet address: fa:69:35:9e:04:2f
    zy7_slcr0: on nexus0
    [zone: udpcb] kern.ipc.maxsockets limit reached
    notice: cgem0: link state changed to DOWN
    add host 10.10.5.1: gateway cgem0
    add net default: gateway 10.10.5.1
    rtems-db: remote running
    rtems-db: tcp remote: listing on port: 1122
    notice: cgem0: link state changed to UP
    rtems-db: tcp remote: connect host: 10.10.5.2
    rtems-db: arm debug: (v3.0) ARMv7 [v7, all CP14 registers] breakpoints:5 watchpoints:3
    assertion "cpu_self->thread_dispatch_disable_level != 0 || _ISR_Get_level() != 0" failed: file "../../cpukit/../../../xilinx_zynq_zedboard/lib/include/rtems/score/percpu.h", line 630, function: _Per_CPU_Get

    If I enable TARGET_DEBUG in libdebugger and apply the attached patch I can create the assert with DIE_ON_ASSERT set to 1. The output is:

     rtems-db: tcp remote: connect host: 10.10.5.2
    rtems-db: arm debug: (v3.0) ARMv7 [v7, all CP14 registers] breakpoints:5 watchpoints:3
    [} frame = 005664EC sig=1 vector=4 ifsr=00000000 pra=0024173A
    [} R0 = 00000158 R1 = 00000004 R2 = 00000001 R3 = 0041AB64
    [} R4 = 00000158 R5 = 00000004 R6 = 00000000 R7 = 005606A4
    [} R8 = 00000016 R9 = 00000001 R10 = 00000006 R11 = 0041AB64
    [} R12 = 00560658 SP = 00566540 LR = 00000FFD PC = 00241736
    [} CPSR = 08010173 ----Q--A-FT GE:0 IT:01 M:13 SVC
    [} target exception: 0 0 0
    assertion "cpu_self->thread_dispatch_disable_level != 0 || _ISR_Get_level() != 0" failed: file "../../cpukit/../../../xilinx_zynq_zedboard/lib/include/rtems/score/percpu.h", line 630, function: _Per_CPU_Get

    and set to `0```

    rtems-db: tcp remote: connect host: 10.10.5.2
    rtems-db: arm debug: (v3.0) ARMv7 [v7, all CP14 registers] breakpoints:5 watchpoints:3
    [} frame = 005664EC sig=1 vector=4 ifsr=00000000 pra=0024173A
    [} R0 = 00000158 R1 = 00000004 R2 = 00000001 R3 = 0041AB64
    [} R4 = 00000158 R5 = 00000004 R6 = 00000000 R7 = 005606A4
    [} R8 = 00000016 R9 = 00000001 R10 = 00000006 R11 = 0041AB64
    [} R12 = 00560658 SP = 00566540 LR = 00000FFD PC = 00241736
    [} CPSR = 08010173 ----Q--A-FT GE:0 IT:01 M:13 SVC
    [} target exception: 0 0 0
    [} tid:0A01000A: thread:0041F5B0 frame:005664EC
    [} server access fault
    [} frame = 005664EC sig=1 vector=4 ifsr=00000000 pra=0024173A
    [} R0 = 00000158 R1 = 00000004 R2 = 00000001 R3 = 0041AB64
    [} R4 = 00000158 R5 = 00000004 R6 = 00000000 R7 = 005606A4
    [} R8 = 00000016 R9 = 00000001 R10 = 00000006 R11 = 0041AB64
    [} R12 = 00560658 SP = 00566540 LR = 00000FFD PC = 00241736
    [} CPSR = 08010173 ----Q--A-FT GE:0 IT:01 M:13 SVC
    [} target exception: 0 0 0
    [} tid:0A01000A: thread:0041F5B0 frame:005664EC
    [} server access fault

    The following lines first two values are cpu_self->thread_dispatch_disable_level and _ISR_Get_level() which are both 0 so I cannot see a reason the assert is happening:

    [} target exception: 0 0 0 

    Attachments:

    1 Chris Johns, Fri, 14 Apr 2017 06:02:48 GMT
      attach: set to die-on-assert.patch
     
    Comment 1
    1. Chris Johns, Sat, 15 Apr 2017 00:44:35 GMT

    In b53ad46/rtems:

    libdebugger: Work around assert when using _Thread_Executing. Using _Thread_Executing with RTEMS_DEBUG results in an assert if the server accesses invalid memory. Updates #2993.
    Comment 2
    1. Sebastian Huber, Tue, 02 May 2017 05:27:20 GMT

    What prevents a thread dispatch in this context?

    Comment 3
    1. Chris Johns, Tue, 02 May 2017 06:27:02 GMT

    I think it was the mode and attributes being the wrong way around in the create call.

    Maybe the create call should detect this and return an error rather than the internal error.

    Comment 4
    1. Joel Sherrill, Tue, 02 May 2017 14:17:14 GMT

    It would take making the attribute and mode bits mutually exclusive so overlap can be detected. I considered this also. We would have to be careful to document/check that they stay overlapping.

    Comment 5
    1. Sebastian Huber, Thu, 24 Aug 2017 07:30:17 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    [b2353ed92435c3f9301b795bf20bce14f0ddb01b/rtems]

    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2994 - tar01 XZ error

    Link https://devel.rtems.org/ticket/2994
    Id 2994
    Reporter Joel Sherrill
    Created 15 April 2017 13:06:30
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This shows up on erc32 and psim.

    /dest3/home/test_script: mode: 0755 want: 0755

    ========= /dest3/symlink =========
    (0)This is a test of loading an RTEMS filesystem from an
    initial tar image.

    Untaring chunks from txz - XZ file is corrupt (data)
    ../../../../../../../rtems/c/src/../../testsuites/libtests/tar01/init.c: 272 status == UNTAR_SUCCESSFUL

    Comment 1
    1. Joel Sherrill, Sat, 15 Apr 2017 13:06:43 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Sebastian Huber, Tue, 13 Jun 2017 09:45:57 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In c7377381/rtems:

    xz: Use CRC32 This reverts c475924d6d2ea7d5cba160a8a28e88642d6b46d8. Update #2909. Close #2994.
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2995 - Missing bsets

    Link https://devel.rtems.org/ticket/2995
    Id 2995
    Reporter Hassan Karim
    Created 16 April 2017 23:04:21
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    When I went to rebuild based on 4.12, I cloned from github.
    I am no longer getting all of the b-sets that I was expecting. Specifically, 4.12/rtems-sparc

    Chris Johns said to submit it as a bug. It must have happened within the last couple of weeks. As my scripts that automated these tasks were working as of around 3/1/2017

    git clone ​git://git.rtems.org/rtems-source-builder.git $SETBLDRSCRIPTDIR/sb-set-builder --list-bsets

    RTEMS Source Builder - Set Builder, 4.12 (2074bd1168ee)
    Examining: config
    Examining: ../rtems/src/rtems-source-builder/source-builder/config
    Examining: ../rtems/src/rtems-source-builder/bare/config
    devel/autotools-base.bset
    devel/autotools-internal.bset
    devel/autotools.bset
    devel/dtc.bset
    devel/libtool.bset
    devel/libusb.bset
    devel/or1ksim.bset
    devel/qemu.bset
    gnu-tools-4.6.bset
    gnu-tools-4.8.2.bset
    lang/gcc491.bset

    Comment 1
    1. Joel Sherrill, Mon, 17 Apr 2017 03:29:20 GMT

    When you mentioned GitHub?, I wondered if the mirroring was broken. It is not. And it looks like rtems/config/4.12 has the right content.

    I will try the script in the morning to see what it lists on my computer.

    Comment 2
    1. Hassan Karim, Mon, 17 Apr 2017 03:44:58 GMT

    What could I look for specifically by hand in the git repository?

    Comment 3
    1. Joel Sherrill, Mon, 17 Apr 2017 14:32:04 GMT

    I don't think you need to look at anything. I can confirm the script doesn't find the RTEMS 4.12 bsets. It isn't seeing anything in the rtems/ directory.

    $ ./source-builder/sb-set-builder --list-bsets RTEMS Source Builder - Set Builder, 4.12 (2074bd1168ee) Examining: config Examining: source-builder/config Examining: bare/config

    devel/autotools-base.bset devel/autotools-internal.bset devel/autotools.bset devel/dtc.bset devel/libtool.bset devel/libusb.bset devel/or1ksim.bset devel/qemu.bset gnu-tools-4.6.bset gnu-tools-4.8.2.bset lang/gcc491.bset

    The rtems 4.12 bset's are:

    $ ls rtems/config/4.12 rtems-aarch64.bset rtems-i386.bset rtems-powerpc.bset rtems-all.bset rtems-lm32.bset rtems-sh.bset rtems-arm.bset rtems-m32c.bset rtems-sparc64.bset rtems-autotools-base.bset rtems-m68k.bset rtems-sparc.bset rtems-autotools.bset rtems-microblaze.bset rtems-tools.bset rtems-autotools-internal.bset rtems-mips.bset rtems-v850.bset rtems-bfin.bset rtems-moxie.bset rtems-x86_64.bset rtems-default.bset rtems-nios2.bset rtems-epiphany.bset rtems-or1k.bset

    cd into rtems/ and then run set-builder using any of those. This is just a problem with the --list-bsets.

    Comment 4
    1. Hassan Karim, Sat, 29 Apr 2017 11:57:37 GMT

    Thanks. It worked.

    Comment 5
    1. Joel Sherrill, Sat, 29 Apr 2017 17:24:34 GMT

    Good news. Please close if it is resolved n

    Comment 6
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 7
    1. Sebastian Huber, Tue, 10 Oct 2017 06:57:05 GMT
    2. component: changed from bsps to tool/rsb
    Comment 8
    1. Joel Sherrill, Thu, 12 Oct 2017 01:07:54 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2997 - Monitor config command does not handle unlimited objects.

    Link https://devel.rtems.org/ticket/2997
    Id 2997
    Reporter Chris Johns
    Created 18 April 2017 02:43:56
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Running the console's config command with unlimited objects gives:

    [/] # config
    INITIAL (startup) Configuration Info
    ------------------------------------------------------------------------------
    WORKSPACE start: 0x800f0173; size: 0x374c8
    TIME usec/tick: 10000; tick/timeslice: 50; tick/sec: 100
    MAXIMUMS tasks: -2147483614; timers: -2147483616; sems: -2147483609; que's: -2147483616; ext's: 1
    partitions: -2147483616; regions: -2147483616; ports: -2147483616; periods: -2147483616
    Comment 1
    1. Joel Sherrill, Tue, 18 Apr 2017 14:34:46 GMT

    Why do I own this? I added neither the monitor nor unlimited objects? I think you wrote both of them. :)

    Comment 2
    1. Chris Johns, Tue, 18 Apr 2017 23:44:32 GMT
    2. owner: changed from joel.sherrill@… to Chris Johns

    Sorry, I just missed you are the default. I have posted a patch to the list.

    Comment 3
    1. Sebastian Huber, Thu, 24 Aug 2017 06:05:36 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    [4fd25c4340f30f61360d4ab2eb126b095eab82e7/rtems]

    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    2998 - RTEMS User Manual Quick Start does not cover releases.

    Link https://devel.rtems.org/ticket/2998
    Id 2998
    Reporter Chris Johns
    Created 18 April 2017 04:27:24
    Modified 12 March 2020 21:23:43
    Owner chrisj@…
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The quick start documents using git and does not cover a release. This is confusing because the releases tools and the git master may not work.

    Comment 1
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 3
    1. Chris Johns, Thu, 12 Mar 2020 21:23:40 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In f672026/rtems-docs:

    user: Update Quick Start Guide Add support for release source archives Add building the BSP using the RSB Add building packages using the RSB Add an application Closes #2998
    Comment 4
    1. Chris Johns, Thu, 12 Mar 2020 21:23:43 GMT

    In 5bd9f4d/rtems-docs:

    sphinx: Add a custom highlight colour Update #2998

    2999 - sb-check on Cygwin

    Link https://devel.rtems.org/ticket/2999
    Id 2999
    Reporter Joel Sherrill
    Created 18 April 2017 14:41:54
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    It looks like there are two issues in windows.py

    • Probes for programs like bison and flex as required.
    • tar - bsdtar must be on mingw. It doesn't appear to exist on cygwin.

    I think the fix is pretty simple code-wise but I wanted to get some feedback on why there were a lot more required programs in this file than on other OS.py files.

    Comment 1
    1. Chris Johns, Tue, 18 Apr 2017 23:43:22 GMT

    Replying to Joel Sherrill:

    It looks like there are two issues in windows.py

    Probes for programs like bison and flex as required. tar - bsdtar must be on mingw. It doesn't appear to exist on cygwin.

    Correct. Getting a suitable bug free tar on Windows is not as easy as it looks.

    I have no interest in supporting Cygwin. In the past it has never been able to complete a build of the tools in a reliable way while MSYS2 does. Cygwin complicates the Windows environment, machine set up, documentation and what user's should use.

    I do not want to run parallel MSYS2 and Cygiwn environments to check both are working. I have supported Cygwin the past and found it a major effort and distraction.

    I think the new Microsoft Unix layer, what ever that is called, is a better path for us to follow.

    I think the fix is pretty simple code-wise

    If you wish to support Cygwin then I ask you test all changes to this file on MSYS2 as this is the primary set up for Windows.

    but I wanted to get some feedback on why there were a lot more required programs in this file than on other OS.py files.

    Typically a default entry is overridden by creating an entry in the host's OS file. Entries are overridden if the paths do not match.

    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 3
    1. Joel Sherrill, Thu, 12 Oct 2017 00:16:16 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    Some patches for Cygwin support were merged. Other issues were solved by installing more tools.

    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3000 - Setting interrupt level in the mode arg on SMP returns RTEMS_UNSATISFIED

    Link https://devel.rtems.org/ticket/3000
    Id 3000
    Reporter Chris Johns
    Created 19 April 2017 02:11:59
    Modified 9 January 2019 09:37:17
    Owner Joel Sherrill
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    If for any reason a user sets the interrupt level in the mode on an SMP build the error RTEMS_UNSATISFIED is returned. The documentation indicates this is a lack of stack and this confusing.

    The reason this happens is the SMP check for an interrupt level being set is in the score's _Thread_Initialize. I propose that and is_preemptible check be converted to an assert and checks be added to the Classic API to catch these errors and report suitable error codes.

    There is no meaningful error code available without abusing an existing one so I propose adding RTEMS_INVALID_MODE.

    Comment 1
    1. Joel Sherrill, Wed, 19 Apr 2017 03:28:50 GMT

    I think this is a generally a good idea but there are a number of pieces to do this completely:

    the status has to also be returned by rtems_task_mode() add status to list in rtems status to string add status to list in Ada binding. Should be mechanical. add status to status table in Classic API manual add new status to rtems_task_create() documentation add new status to rtems_task_mode() documentation add test for rtems_task_create() new error add test for rtems_task_mode() new error

    I am unsure if the assert() is debug mode only. That needs to be clarified.

    Sorry to be pedantic with the list but this looks like the type of change that is small but has tentacles that would be easy to miss pieces. I suspect my list isn't complete yet.

    Comment 2
    1. Chris Johns, Wed, 19 Apr 2017 04:42:23 GMT

    Replying to Joel Sherrill:

    I think this is a generally a good idea but there are a number of pieces to do this completely:

    Great and yes.

    the status has to also be returned by rtems_task_mode()

    OK.

    add status to list in rtems status to string

    Done in the posted patch.

    add status to list in Ada binding. Should be mechanical.

    Is there any documentation on how to do this?

    Answer: Edit rtems.ads and add it. It is just an enumerated list. You won't have trouble. c/src/ada/rtems.ads around line 353.

    add status to status table in Classic API manual add new status to rtems_task_create() documentation add new status to rtems_task_mode() documentation

    I will create a docs patch once I have a suitable patch for master.

    add test for rtems_task_create() new error add test for rtems_task_mode() new error

    Yes however the tests are only running in the single core mode even when built with SMP so the error is not able to be tripped.

    ANSWER: Sounds like a new SMP test is needed.

    I am unsure if the assert() is debug mode only. That needs to be clarified.

    That is correct. The assert's catch a bug in a user of the score API when built with RTEMS_DEBUG. The users of the call need to protect the score thread initialise call.

    Sorry to be pedantic with the list but this looks like the type of change that is small but has tentacles that would be easy to miss pieces. I suspect my list isn't complete yet.

    This looks the list to me.

    Comment 3
    1. Sebastian Huber, Tue, 02 May 2017 05:34:57 GMT

    See smpunsupported01 test.

    Comment 4
    1. Chris Johns, Tue, 02 May 2017 06:28:22 GMT

    Replying to Sebastian Huber:

    See smpunsupported01 test.

    What what? Could you please elaborate a little more?

    Thanks

    Comment 5
    1. Sebastian Huber, Tue, 02 May 2017 06:54:04 GMT

    Replying to Chris Johns:

    Replying to Sebastian Huber:

    See smpunsupported01 test.

    What what? Could you please elaborate a little more?

    This is the test program the new error cases should be added.

    Comment 6
    1. Chris Johns, Thu, 12 Oct 2017 17:46:04 GMT
    2. description: modified (diff)
    Comment 7
    1. Joel Sherrill, Thu, 12 Oct 2017 18:46:16 GMT

    Updated work list:

    Whine that this was easier to report than to fix. CPUKit Changes (PREVIOUSLY COMMITTED) Add status to enumeration (PREVIOUSLY COMMITTED) Add status to list in rtems status to string (PREVIOUSLY COMMITTED) Add status to list in Ada binding. Should be mechanical (PREVIOUSLY COMMITTED) Add both error checks to rtems_task_create() (CLEAN UP PASS) Add both error checks to rtems_task_mode() Documentation (ADDED) Add status to status table in Classic API manual (ADDED) Add new status to rtems_task_create() documentation (ADDED) Add new status to rtems_task_mode() documentation Testing (PREVIOUSLY COMMITTED) Add rtems_task_create() test case(s) to smpunsupported01 (ONE PREVIOUSLY COMMITTED, ONE ADDED) Add rtems_task_mode() test case(s) to smpunsupported01

    Patches for "CLEAN UP PASS" and "ADDED" submitted to devel@ mailing list. Pending review to be committed and close this.

    Comment 8
    1. Joel Sherrill, Thu, 12 Oct 2017 18:51:18 GMT
    2. owner: changed from Chris Johns to Joel Sherrill
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 10
    1. Joel Sherrill, Wed, 06 Dec 2017 18:49:12 GMT

    In e9e0f1d4/rtems:

    smpunsupported01: Add missing error check for rtems_task_mode Update test documentation to include more cases. Updates #3000.
    Comment 11
    1. Joel Sherrill, Wed, 06 Dec 2017 18:49:57 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 3079455/rtems-docs:

    Account for non-preemption and interrupt level not supported on SMP Closes #3000.
    Comment 12
    1. Sebastian Huber, Thu, 07 Dec 2017 08:22:31 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    Tests tm04 and tm20 fail now with --enable-smp.

    Comment 13
    1. Joel Sherrill, Fri, 08 Dec 2017 18:16:34 GMT

    In 1307e75/rtems:

    tm08: Do not use RTEMS_INTERRUPT_MASK for no reschedule case Updates #3000.
    Comment 14
    1. Sebastian Huber, Fri, 19 Jan 2018 06:46:33 GMT

    In a5b4db4b/rtems:

    rtems: Fix rtems_task_mode() A rtems_configuration_is_smp_enabled() inside a !defined( RTEMS_SMP) block makes no sense. Remove !defined( RTEMS_SMP ) conditions. Test tm04 works now again. Update #3000.
    Comment 15
    1. Chris Johns, Fri, 13 Apr 2018 01:46:14 GMT

    Can this ticket be closed? If it cannot be closed what is outstanding to be done?

    Comment 16
    1. Joel Sherrill, Sun, 14 Oct 2018 00:29:16 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed
    Comment 17
    1. Sebastian Huber, Wed, 09 Jan 2019 09:37:11 GMT

    In 38cb59e/rtems:

    Separate task mode checks Update #3000.
    Comment 18
    1. Sebastian Huber, Wed, 09 Jan 2019 09:37:14 GMT

    In 1f285186/rtems:

    rtems: Allow to set ISR level 0 in SMP config Update #3000.
    Comment 19
    1. Sebastian Huber, Wed, 09 Jan 2019 09:37:17 GMT

    In 3bd39999/rtems:

    Adjust interrupt mode tests for some CPU ports In case the robust thread dispatch is enabled by the CPU port, then the interrupt level must not be changed through the task mode. Update #3000.

    3001 - SMP build of RTEMS Testsuite does not set CONFIGURE_MAXIMUM_PROCESSORS

    Link https://devel.rtems.org/ticket/3001
    Id 3001
    Reporter Chris Johns
    Created 20 April 2017 07:48:13
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The default setting for CONFIGURE_MAXIMUM_PROCESSORS is 1 and this means rtems_configuration_is_smp_enabled() returns false. Only the smptests set the maximum processor count to CPU_COUNT and therefore run in SMP mode.

    If SMP is not running in an SMP build when running the tests are the tests really reporting a true indication of the of the system?

    I would expect we have the API tests, libtests and fstests running with SMP enabled in an SMP build.

    Comment 1
    1. Chris Johns, Thu, 20 Apr 2017 07:48:52 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Thu, 11 May 2017 09:59:06 GMT
    2. owner: changed from joel.sherrill@… to Sebastian Huber
    3. status: changed from new to accepted
    Comment 3
    1. Sebastian Huber, Fri, 12 May 2017 06:01:25 GMT

    In 1309718/rtems:

    confdefs.h: CONFIGURE_DISABLE_SMP_CONFIGURATION Enable the SMP configuration by default in case SMP is enabled. Add configuration option CONFIGURE_DISABLE_SMP_CONFIGURATION to disable it explicitly. Add CONFIGURE_DISABLE_SMP_CONFIGURATION to all test which would fail otherwise. Update #3001.
    Comment 4
    1. Sebastian Huber, Fri, 12 May 2017 06:36:26 GMT

    In f778b7f3/rtems:

    confdefs.h: Use SMP scheduler only if necessary Update #3001.
    Comment 5
    1. Sebastian Huber, Tue, 16 May 2017 07:48:56 GMT

    In 6bc63df1/rtems:

    confdefs.h: Add SMP enabled field to configuration Do not use the processor count to determine if SMP is enabled. Instead use a dedicated configuration option. Enable SMP by default in SMP configurations. Add CONFIGURE_DISABLE_SMP_CONFIGURATION to all test which would fail otherwise. Update #3001.
    Comment 6
    1. Sebastian Huber, Thu, 08 Jun 2017 08:11:59 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    By default, in case SMP in enabled the SMP mode will be used.

    Comment 7
    1. Sebastian Huber, Tue, 10 Oct 2017 06:27:10 GMT
    2. component: changed from SMP to score
    Comment 8
    1. Sebastian Huber, Tue, 10 Oct 2017 06:29:01 GMT
    2. component: changed from score to cpukit
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3003 - FAT does not support clusters bigger than 32K

    Link https://devel.rtems.org/ticket/3003
    Id 3003
    Reporter munster
    Created 20 April 2017 12:23:11
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component fs/fat
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords FAT, cluster
    Cc  
    Blocking  
    Blocked by  

    Description

    When used with 64KiB clusters, the FAT driver will loop forever in cpukit/libfs/src/dosfs/fat.c, line 580.
    This happens because struct fat_vol_s declares bytes per cluster variable as __uint16_t bpc__, whereas it can be as big as 256KiB.

    Here is a link for Linux FAT driver which doesn't make any assumption about cluster size: ​http://lxr.free-electrons.com/source/fs/fat/inode.c?v=2.6.24#L1262

    Attachments:

    1 munster, Fri, 21 Apr 2017 09:41:56 GMT
      attach: set to fat.diff
    Comment 1
    1. Gedare Bloom, Thu, 20 Apr 2017 15:15:38 GMT

    Do you have a test case?

    Do you have a proposed solution? is it just to increase bpc type size?

    Comment 2
    1. munster, Fri, 21 Apr 2017 09:43:32 GMT

    I have attached a solution which increases bpc size and removes the limit.

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Sebastian Huber, Thu, 24 Aug 2017 09:56:36 GMT
    2. owner: changed from chrisj@… to Sebastian Huber
    3. status: changed from new to assigned
    Comment 5
    1. Sebastian Huber, Wed, 06 Sep 2017 08:21:32 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In fae59c9/rtems:

    dosfs: Support a cluster size of 64KiB Close #3003.
    Comment 6
    1. Sebastian Huber, Tue, 10 Oct 2017 06:50:58 GMT
    2. component: changed from fs to fs/fat
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3006 - SPARC LEON3 BSP SMP build is broken.

    Link https://devel.rtems.org/ticket/3006
    Id 3006
    Reporter Chris Johns
    Created 27 April 2017 05:57:22
    Modified 9 November 2017 06:27:14
    Owner Daniel Hellstrom
    Type defect
    Component arch/sparc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords tier-1
    Cc  
    Blocking  
    Blocked by  

    Description

    The rtems-bsp-builder failure output is:

     2 smp-debug sparc/leon3 build:
    configure: /opt/work/chris/rtems/kernel/rtems.git/configure --target\
    =sparc-rtems4.12 --enable-rtemsbsp=leon3 --prefix=/opt/rtems/4.12\
    --enable-debug --enable-smp --enable-tests
    error: c/src/lib/libbsp/sparc/shared/spw/grspw_pkt.c:61:2 error:
    #error SMP mode not compatible with these interrupt lock primitives

    The BSP builder command line is:

    RTEMS Tools Project - RTEMS Kernel BSP Builder, 4.12.not_released
    command: /opt/work/rtems/4.12/bin/rtems-bsp-builder --rtems-\
    tools=/build/rtems/tools/4.12\
    --rtems=/opt/work/chris/rtems/kernel/rtems.git --build=smp-debug\
    --log=x
    Comment 1
    1. Chris Johns, Thu, 27 Apr 2017 07:20:30 GMT
    2. owner: changed from joel.sherrill@… to Daniel Hellstrom
    3. status: changed from new to assigned
    Comment 2
    1. Daniel Hellstrom, Fri, 12 May 2017 09:32:46 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    I never had this problem until I rebased recently. It triggered on LEON3 since some drivers are looking at the RTEMS version information from headers.

    This was fixed by Sebastian in commit:

    e0627c69b5bc2b669105525b1ce35f84abc3edf0 "cpukit: Fix RTEMS_REVISION define"

    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:53:06 GMT
    2. component: changed from bsps to arch/sparc
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3007 - ARM caching issues

    Link https://devel.rtems.org/ticket/3007
    Id 3007
    Reporter munster
    Created 27 April 2017 14:23:57
    Modified 16 April 2020 23:48:10
    Owner joel.sherrill@…
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords ARM,cache,L2C 310
    Cc  
    Blocking  
    Blocked by  

    Description

    There are two problems with the caching on ARM:

    • In cases where the buffer is not aligned to line boundary at the beginning or the end, the invalidate operation would lose modifications done on the adjacent data. This applies to both L1 and L2 caches.
    • The L2C-310 cache management operations use excessive locking. According to ​manual, the used operations (Clean Line by PA, Clean and Invalidate Line by PA, Cache Sync) are atomic and do not require locking.

    I have attached the proposed patch.

    Attachments:

    1 munster, Thu, 27 Apr 2017 14:24:20 GMT
      attach: set to cache.diff
    2 munster, Mon, 08 May 2017 09:58:29 GMT
      attach: set to cache_invalidate.diff
    3 munster, Mon, 08 May 2017 09:58:44 GMT
      attach: set to cache_locking.diff
    4 munster, Thu, 11 May 2017 14:25:40 GMT
      attach: set to 0001-Remove-excessive-locking-from-cache-operations.patch
    5 munster, Thu, 11 May 2017 14:25:54 GMT
      attach: set to 0002-Fix-cache-invalidate-behavior.patch
    6 munster, Wed, 14 Jun 2017 11:43:59 GMT
      attach: set to v2-0001-Remove-excessive-locking-from-cache-operations.patch
    7 munster, Wed, 14 Jun 2017 11:44:10 GMT
      attach: set to v2-0002-Fix-cache-invalidate-behavior.patch
    Comment 1
    1. Chris Johns, Thu, 27 Apr 2017 23:44:36 GMT

    Why have you changed the signature of some of the functions to be uint32_t, uint32_t from const void* , const size_t ?

    Comment 2
    1. munster, Fri, 28 Apr 2017 15:13:35 GMT

    Well, I was just following the Linux driver ​example. If you don't like it, I can use the previous function signature.

    Comment 3
    1. Chris Johns, Sun, 30 Apr 2017 22:09:35 GMT

    Replying to munster:

    Well, I was just following the Linux driver ​example. If you don't like it, I can use the previous function signature.

    I think it is best a change like this is as small as can be and keeping the existing function signatures helps do this so please revert that part of the change and post a new patch. Thanks.

    Comment 4
    1. Sebastian Huber, Tue, 02 May 2017 05:30:52 GMT

    Please don't change the function signatures. Please generate one patch for each issue.

    Its up to the user to ensure that a cache line invalidation is safe. The cache manager should not take care of this.

    Comment 5
    1. munster, Mon, 08 May 2017 10:02:40 GMT

    Replying to Sebastian Huber:

    Please don't change the function signatures. Please generate one patch for each issue.

    I have attached separate patches for these two issues.

    Its up to the user to ensure that a cache line invalidation is safe. The cache manager should not take care of this.

    Generally you are right. However, the user may not be aware of this particular problem.

    Comment 6
    1. Sebastian Huber, Tue, 09 May 2017 07:58:16 GMT

    Replying to munster:

    Replying to Sebastian Huber:

    Please don't change the function signatures. Please generate one patch for each issue.

    I have attached separate patches for these two issues.

    Could you please format the patches via "git format-patch":

    ​https://docs.rtems.org/branches/master/user/support/contrib.html

    Please help to improve the wiki and website if something is unclear or hard to find.

    Its up to the user to ensure that a cache line invalidation is safe. The cache manager should not take care of this.

    Generally you are right. However, the user may not be aware of this particular problem.

    The we should fix this issue with better documentation. In

    ​https://git.rtems.org/rtems/tree/cpukit/rtems/include/rtems/rtems/cache.h#n111

    we have

    /**
     * @brief Invalidates multiple data cache lines.
     *
     * The cache lines covering the area are marked as invalid.  A later read
     * access in the area will load the data from memory.
     *
     * In case the area is not aligned on cache line boundaries, then this
     * operation may destroy unrelated data.
     *
     * @param[in] addr The start address of the area to invalidate.
     * @param[in] size The size in bytes of the area to invalidate.
     */
    void rtems_cache_invalidate_multiple_data_lines(
      const void *addr,
      size_t size
    ); 

    The cache manager documentation probably needs to move into the user manual. Maybe some examples help to show what can go wrong.

    Comment 7
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 8
    1. munster, Thu, 11 May 2017 14:27:34 GMT

    Replying to Sebastian Huber:

    Could you please format the patches via "git format-patch":

    I have attached the patches.

    Comment 9
    1. Sebastian Huber, Fri, 12 May 2017 05:23:15 GMT

    See

    ​https://devel.rtems.org/wiki/Developer/Git/Users#CreatingaPatch

    Please use your real name for the patch with a valid e-mail address.

    Comment 10
    1. Sebastian Huber, Thu, 08 Jun 2017 07:46:40 GMT
    2. milestone: changed from 4.12.0 to 4.12.1
    Comment 11
    1. Sebastian Huber, Mon, 12 Jun 2017 07:34:17 GMT

    Without a real name I cannot apply this patch.

    Comment 12
    1. munster, Wed, 14 Jun 2017 11:45:18 GMT

    Replying to Sebastian Huber:

    Without a real name I cannot apply this patch.

    Re-attached with real name.

    Comment 13
    1. Alexei Pososin, Wed, 14 Jun 2017 13:41:30 GMT

    In fd10817/rtems:

    Remove excessive locking from cache operations. According to manual, the used operations (Clean Line by PA, Clean and Invalidate Line by PA, Cache Sync) are atomic and do not require locking. Update #3007.
    Comment 14
    1. Sebastian Huber, Wed, 14 Jun 2017 13:46:21 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    It is up to the user to ensure that its safe to invalidate a certain data area.

    Comment 15
    1. Sebastian Huber, Wed, 14 Jun 2017 13:46:35 GMT
    2. version: changed from 4.12 to 4.11
    Comment 16
    1. Chris Johns, Wed, 12 Jul 2017 22:32:43 GMT
    2. milestone: changed from 4.12.1 to 4.12.0
    Comment 17
    1. Sebastian Huber, Tue, 10 Oct 2017 06:54:12 GMT
    2. component: changed from bsps to arch/arm
    Comment 18
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3008 - missing pax causes install failures

    Link https://devel.rtems.org/ticket/3008
    Id 3008
    Reporter Hassan Karim
    Created 6 May 2017 19:47:36
    Modified 9 November 2017 06:27:14
    Owner chrisj@…
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords pax; testsuites
    Cc  
    Blocking  
    Blocked by  

    Description

    I have tried to install sparc bsp=erc32 on 4 different builds. 3 failed, and 1 flawlessly installed. The others all seem to fail somewhere during make install of test suites. Each reports one missing config problem or another.

    I believe the problem resulted in a missing package, pax & libbsd-dev on Ubuntu 12.04.5 LTS (GNU/Linux 3.2.0-126-virtual x86_64)

    I hadn't seen this exact problem because I normally update & upgrade as soon as I get a new image. Pressed for time, I skipped it. So, I am not sure if we need to update the documentation to directly include pax, since it is directly called in configure and breaks if not present.

    ​https://docs.rtems.org/rsb/#_host_setups Under this section,
    11.1.5. Ubuntu

    Add pax to this line
    $ sudo apt-get build-dep binutils gcc g++ gdb unzip git python2.7-dev pax

    Comment 1
    1. Chris Johns, Sun, 07 May 2017 22:54:11 GMT

    This looks like a duplicate of #2437.

    Solving this issue cleanly at the RSB level requires teaching the RSB about packages and then providing per host integration to the local packaging system if one is present. The RSB can build anything and so it is difficult to create a per host install list for everything that it could build. As a result there is currently a middle ground that is not cleanly covered leaving holes such as this one.

    For pax please provide a documentation patch.

    Comment 2
    1. Chris Johns, Sun, 07 May 2017 22:58:24 GMT

    Also the latest RSB documentation is ​https://docs.rtems.org/branches/master/rsb/index.html

    Comment 3
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 4
    1. Chris Johns, Mon, 04 Sep 2017 03:33:35 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 2cc9e2a/rtems-docs:

    Add PAX to the Ubuntu packages to install. Closes #3008.
    Comment 5
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3009 - Provide invalid link handler for docs.rtems.org so old docs can be removed.

    Link https://devel.rtems.org/ticket/3009
    Id 3009
    Reporter Chris Johns
    Created 7 May 2017 22:57:36
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type infra
    Component tool/website
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority high
    Severity major
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The docs.rtems.org website has lots of old docs which need to be removed.

    See #3008 for a reference to old documentation.

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Chris Johns, Wed, 11 Oct 2017 23:08:49 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    The old paths have been remove for a while and it looks like Google has indexed the site. The www.rtems.org pages have been updated.

    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3010 - src/cpukit/posix/src/mmap.c:189]: (style) Suspicious condition

    Link https://devel.rtems.org/ticket/3010
    Id 3010
    Reporter David Binderman
    Created 8 May 2017 19:33:43
    Modified 9 November 2017 06:27:14
    Owner Gedare Bloom <gedare@…>
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    src/cpukit/posix/src/mmap.c:189]: (style) Suspicious condition (bitwise operator + comparison); Clarify expression with parentheses.

    Source code is

    } else if ( (flags & MAP_PRIVATE != MAP_PRIVATE) ) {

    Maybe better code

    } else if ( (flags & MAP_PRIVATE) != MAP_PRIVATE ) {

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Gedare Bloom, Tue, 16 May 2017 15:38:07 GMT
    2. owner: set to Gedare Bloom <gedare@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In a330c5d/rtems:

    posix: clarify expression with parentheses Close #3010.
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3011 - Error compiling xilinx_zynq_zedboard.

    Link https://devel.rtems.org/ticket/3011
    Id 3011
    Reporter Arturo Pérez
    Created 9 May 2017 08:28:39
    Modified 9 November 2017 06:27:14
    Owner Gedare Bloom
    Type defect
    Component arch/arm
    Status closed
    Resolution worksforme
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords zedboard RSB buid
    Cc  
    Blocking  
    Blocked by  

    Description

    I encountered an error compiling the xilinx_zynq_zedboard BSP. I am using a built of the RSB that I compiled in December. With that built of the RSB I could built this BSP several times until I did a git pull of the RTEMS repo two weeks ago. Today I updated my repos of the RTEMS and RSB sources, I rebuilt the RSB and I tried to built again the xilinx_zynq_zedboard BSP, encountering the same error:

    gmake[6]: __* No rule to make target posix/include/sys/mman.h', needed by ../cpukit/../../../xilinx_zynq_zedboard/lib/include/sys/mman.h'. Stop. __

    Comment 1
    1. Gedare Bloom, Tue, 09 May 2017 14:24:45 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    You need to re-build your toolchain with a new git-pull of the RSB.

    Comment 2
    1. Arturo Pérez, Wed, 10 May 2017 08:50:57 GMT

    As I wrote, I updated the RSB sources by doing a git-pull. Then, I built it again, but using this new version I found the same error. I did it yesterday and today.

    Comment 3
    1. Gedare Bloom, Wed, 10 May 2017 12:46:23 GMT
    2. status: changed from closed to reopened
    3. resolution: invalid deleted

    The sys/mman.h was moved from RTEMS into newlib awhile ago, but maybe there is a problem with the integration. I recently added the mmap/munmap support. I'll try to look at this, can anyone else replicate it?

    Comment 4
    1. Gedare Bloom, Wed, 10 May 2017 12:46:43 GMT
    2. owner: changed from joel.sherrill@… to Gedare Bloom
    3. status: changed from reopened to assigned
    Comment 5
    1. Joel Sherrill, Wed, 10 May 2017 13:07:47 GMT

    I built all BSPs overnight and didn't have any failures due to this. I always bootstrap -c and rebootstrap before a build sweep. It is quite possible that the Makefile.in didn't get regenerated in the reporter's source tree.

    Comment 6
    1. Gedare Bloom, Wed, 10 May 2017 16:40:46 GMT

    Yes, that makes sense. Arturo, please do bootstrap -c and then bootstrap, configure and make.

    Comment 7
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 8
    1. Arturo Pérez, Thu, 11 May 2017 08:25:39 GMT

    Yes, that was the solution. I was not doing bootstrap -c.

    From now I will do the built always following the steps as Joel said.

    Thanks, so much. Sorry, if I made you losing a bit of time.

    Comment 9
    1. Sebastian Huber, Thu, 11 May 2017 11:08:58 GMT
    2. status: changed from assigned to closed
    3. resolution: set to worksforme
    Comment 10
    1. Sebastian Huber, Tue, 10 Oct 2017 06:54:12 GMT
    2. component: changed from bsps to arch/arm
    Comment 11
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3012 - Global C++ IO streams are broken (cout, cin, cerr)

    Link https://devel.rtems.org/ticket/3012
    Id 3012
    Reporter Sebastian Huber
    Created 9 May 2017 08:57:53
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component tool/newlib
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The global C++ IO stream objects are initialized here

    ​https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/src/c%2B%2B98/ios_init.cc?view=markup#l85

    via a placement new. The "stdout" etc. is thread-local in Newlib

    #define    stdout  (_REENT->_stdout) 

    Using this for a global object like std::cout is quite broken. Which FILE object should be used instead? Potential fix:

    diff --git a/libstdc++-v3/src/c++98/ios_init.cc b/libstdc++-v3/src/c++98/ios_init.cc
    index c5bcc83..7470c44 100644
    --- a/libstdc++-v3/src/c++98/ios_init.cc
    +++ b/libstdc++-v3/src/c++98/ios_init.cc
    @@ -33,6 +33,15 @@
    #include
    #include
    +#ifdef __rtems__
    +#undef stdout
    +#undef stdin
    +#undef stderr
    +#define stdout (_GLOBAL_REENT->_stdout)
    +#define stdin (_GLOBAL_REENT->_stdout)
    +#define stderr (_GLOBAL_REENT->_stdout)
    +#endif
    +
    namespace __gnu_internal _GLIBCXX_VISIBILITY(hidden)
    {
    using namespace __gnu_cxx;
    diff --git a/newlib/libc/stdio/findfp.c b/newlib/libc/stdio/findfp.c
    index 83d3dc5..7d50951 100644
    --- a/newlib/libc/stdio/findfp.c
    +++ b/newlib/libc/stdio/findfp.c
    @@ -259,6 +259,12 @@ _DEFUN(__sinit, (s),
    __sinit_lock_release ();
    }
    +static void __attribute__((__constructor__(0)))
    +_global_reent_init(void)
    +{
    + __sinit (_GLOBAL_REENT);
    +}
    +
    #ifndef __SINGLE_THREAD__
    __LOCK_INIT_RECURSIVE(static, __sfp_recursive_mutex);
    Comment 1
    1. Chris Johns, Wed, 10 May 2017 00:21:49 GMT

    This approach concerns me because it breaks std::cout in the other direction. If this is fine for C++'s stdout it should be ok for a thread's C stdout and given newlib has:

    #define      stdout  (_REENT->_stdout) 

    we are not consistent.

    Is moving at run-time the address of stdout, which newlib does, conflicting with another standard like C++? I assume the stdc++ code is capturing a reference to stdout so closing and then opening a file and assigning it to stdio works.

    This is a difficult issue.

    Comment 2
    1. Sebastian Huber, Wed, 10 May 2017 05:08:39 GMT

    Another option would be to use thread-local cout, etc. This would require that all RTEMS targets support thread-local storage.

    Comment 3
    1. Chris Johns, Wed, 10 May 2017 05:59:36 GMT

    I have considered this and it is attractive. Is this something libstdc++ supports out of the box or do we need to make changes?

    I would like to understand the issue a little more and how cygwin solves the problem. Joel has been testing some code on cygwin and it would be nice to get it to run on RTEMS and see how it breaks.

    I am concerned the current implementation's behavior is undefined if a thread calls std::cout and then is deleted leaving libstdc++ with a reference to invalid memory.

    Comment 4
    1. Sebastian Huber, Wed, 10 May 2017 06:05:58 GMT

    Replying to Chris Johns:

    I have considered this and it is attractive. Is this something libstdc++ supports out of the box or do we need to make changes?

    No, I guess it needs a some work and it is not clear if this is acceptable for libstdc++. The maintainer have a strong view if it comes to standard compliance.

    I would like to understand the issue a little more and how cygwin solves the problem.

    I guess the main thread is never deleted, so cout can use its stdout safely.

    Joel has been testing some code on cygwin and it would be nice to get it to run on RTEMS and see how it breaks.

    I am concerned the current implementation's behavior is undefined if a thread calls std::cout and then is deleted leaving libstdc++ with a reference to invalid memory.

    This is why one option is to use the _GLOBAL_REENT.

    Comment 5
    1. Sebastian Huber, Tue, 23 May 2017 09:45:20 GMT

    The Ada run-time support has the same problem (thread-local IO streams used like a global object).

    Comment 6
    1. Sebastian Huber, Thu, 22 Jun 2017 06:36:49 GMT

    Maybe we could add an RTEMS-specific change to Newlib so that we still have the thread-local stdio streams, but we initialize them to global FILE objects by default, e.g. remove struct _reent::sf for RTEMS. This would also reduce the amount of per-thread storage.

    If we do this, then we have to be careful with fclose(), since this would close the FILE for all threads. There is no reference counting in the FILE objects.

    Comment 7
    1. Sebastian Huber, Fri, 30 Jun 2017 12:57:05 GMT

    In 5ede1c7/rtems-source-builder:

    4.12: Enable global stdio streams Update #3012.
    Comment 8
    1. Sebastian Huber, Fri, 30 Jun 2017 12:57:49 GMT

    In 9b07f5e/rtems:

    newlib01: Use fopen() instead of freopen() With global stdio streams, a freopen() would close the global stream object. Update #3012.
    Comment 9
    1. Chris Johns, Thu, 06 Jul 2017 01:08:35 GMT

    Has the recent change in newlib to have a single stdout, stderr, etc object and per thread references in the TLS fixed this problem?

    If the first use of the C++ standard streams is before any code redirects and overwrites a thread TLS pointer the standard streams should be the global instance.

    Comment 10
    1. Sebastian Huber, Thu, 06 Jul 2017 05:08:03 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    4. component: changed from GCC to Newlib
    5. milestone: changed from Indefinite to 4.12.0

    From my point of view this problem is fixed.

    The application could alter the stdio stream references in a attribute((constructor(123))) function if it knows what to do.

    Comment 11
    1. Sebastian Huber, Thu, 06 Jul 2017 05:08:25 GMT
    2. version: 4.12 deleted
    Comment 12
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3013 - ProgrammingError: (1064, "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'sid='nikolaykomashinskiy' AND authenticated=1 AND name='force_change_passwd'' at line 1")

    Link https://devel.rtems.org/ticket/3013
    Id 3013
    Reporter Nikolay Komashinskiy
    Created 9 May 2017 14:25:42
    Modified 20 October 2018 20:02:25
    Owner Amar Takhar
    Type defect
    Component tool/website
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Hello, during reset password I had an internal error. This card was automatically generated.

    How to Reproduce

    While doing a POST operation on /reset_password, Trac issued an internal error.

    __(please provide additional details here)__

    Request parameters:

    {u'__FORM_TOKEN': u'56888d70c5e5799302935f97',
    u'email': u'nikolay.komashinskiy@yandex.ru',
    u'register_phone': u'',
    u'rtems_user_phone': u'',
    u'username': u'nikolaykomashinskiy'}

    User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36

    System Information

    __System information not available__

    Enabled Plugins

    __Plugin information not available__

    Interface Customization

    __Interface customization information not available__

    Python Traceback
    Traceback (most recent call last):
    File "/data/src/trac/trac/web/main.py", line 620, in _dispatch_request
    dispatcher.dispatch(req)
    File "/data/src/trac/trac/web/main.py", line 253, in dispatch
    resp = chosen_handler.process_request(req)
    File "/data/trac/plugins/TracAccountManager-0.5.dev0-py2.7.egg/acct_mgr/web_ui.py", line 168, in process_request
    self._do_reset_password(req)
    File "/data/trac/plugins/TracAccountManager-0.5.dev0-py2.7.egg/acct_mgr/web_ui.py", line 256, in _do_reset_password
    self._reset_password(req, username, email)
    File "/data/trac/plugins/TracAccountManager-0.5.dev0-py2.7.egg/acct_mgr/web_ui.py", line 301, in _reset_password
    set_user_attribute(self.env, username, 'force_change_passwd', 1)
    File "/data/trac/plugins/TracAccountManager-0.5.dev0-py2.7.egg/acct_mgr/model.py", line 509, in set_user_attribute
    (value, username, attribute))
    File "/data/src/trac/trac/db/util.py", line 128, in execute
    cursor.execute(query, params if params is not None else [])
    File "/data/src/trac/trac/db/util.py", line 72, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
    File "/usr/local/lib/python2.7/site-packages/MySQLdb/cursors.py", line 205, in execute
    self.errorhandler(self, exc, value)
    File "/usr/local/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
    raise errorclass, errorvalue
    ProgrammingError: (1064, "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'sid='nikolaykomashinskiy' AND authenticated=1 AND name='force_change_passwd'' at line 1")
    Comment 1
    1. Gedare Bloom, Tue, 09 May 2017 20:13:00 GMT
    2. owner: changed from joel.sherrill@… to Amar Takhar
    3. status: changed from new to assigned
    Comment 2
    1. Amar Takhar, Tue, 09 May 2017 20:37:15 GMT

    Whoa very strange. I will look at this when I get home. Thank you for the report.

    Comment 3
    1. Amar Takhar, Sat, 20 Oct 2018 20:02:25 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    4. milestone: changed from Indefinite to 5.1

    This should have been fixed long ago if anyone runs into this issue again please open a new ticket.


    3014 - interrupt vector indexing is assuming BSP_INTERRUPT_VECTOR_MIN = 0 for this code.

    Link https://devel.rtems.org/ticket/3014
    Id 3014
    Reporter phongvanpham
    Created 9 May 2017 21:36:24
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type defect
    Component bsps
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Someone implement bsp_interrupt_handler_index() forgot to update this delta in rtems\c\src\lib\libbsp\shared\src\irq-generic.c:bsp_interrupt_allocate_handler_index(). See attachment.

    Attachments:

    1 phongvanpham, Tue, 09 May 2017 21:37:53 GMT
      attach: set to irq-generic.c
     
    2 phongvanpham, Tue, 09 May 2017 21:38:50 GMT
      attach: set to irq-generic.c.orig
     
    3 phongvanpham, Fri, 12 May 2017 18:40:56 GMT
      attach: set to 0001-interrupt-vector-indexing-is-assuming-BSP_INTERRUPT_.patch
     
    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Sebastian Huber, Fri, 12 May 2017 05:19:45 GMT

    The change looks good, please use your real name and a valid e-mail address for the patch.

    Comment 3
    1. Phong Pham, Sun, 14 May 2017 04:11:01 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In a9859d1/rtems:

    interrupt vector indexing is assuming BSP_INTERRUPT_VECTOR_MIN = 0 Closes #3014.
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3015 - Add support for IBM PPC 750 chip

    Link https://devel.rtems.org/ticket/3015
    Id 3015
    Reporter phongvanpham
    Created 9 May 2017 23:25:44
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type task
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Currently MPC750 chip is supported. However, PPC750 (from IBM) is very close to MPC750 except minor differences. Enclosed is the delta to support PPC750.

    Attachments:

    1 phongvanpham, Tue, 09 May 2017 23:29:10 GMT
      attach: set to cpuIdent.c
     
    2 phongvanpham, Tue, 09 May 2017 23:29:39 GMT
      attach: set to cpuIdent.c.orig
     
    3 phongvanpham, Tue, 09 May 2017 23:29:58 GMT
      attach: set to cpuIdent.h
     
    4 phongvanpham, Tue, 09 May 2017 23:30:18 GMT
      attach: set to cpuIdent.h.orig
     
    5 phongvanpham, Tue, 09 May 2017 23:30:38 GMT
      attach: set to ppc_exc_categories.c
     
    6 phongvanpham, Tue, 09 May 2017 23:31:01 GMT
      attach: set to ppc_exc_categories.c.orig
     
    7 phongvanpham, Fri, 12 May 2017 18:39:29 GMT
      attach: set to 0001-Add-support-for-IBM-PowerPC-750-chip.patch
     
    8 phongvanpham, Fri, 26 May 2017 00:05:14 GMT
      attach: set to 0001-Reuse-mpc750-category-instead-of-creating-new-one-an.patch
     
    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Sebastian Huber, Fri, 12 May 2017 05:16:56 GMT

    Has the existing PPC 740 a performance monitor exception? Maybe use one category for both variants.

    Comment 3
    1. phongvanpham, Wed, 17 May 2017 16:12:53 GMT

    Replying to Sebastian Huber:

    Has the existing PPC 740 a performance monitor exception? Maybe use one category for both variants.

    Current ppc_booke_category_table (exception category for PPC 740) code does not have exception vector 0x1700 supported. Whether or not PPC 740 does have exception vector 0x1700 is unknown since I am not working on that chip nor do I have the datasheet for it. For IBM PowerPC750, exception 0x1700 is Thermal Management. ASM_60X_ITM_VECTOR is defined to be 0x17

    Comment 4
    1. Joel Sherrill, Wed, 17 May 2017 16:25:08 GMT

    I did a quick google and turned up this:

    ​https://people.cs.clemson.edu/~mark/ppc750.pdf

    Which has 740 and 750 in the title. It lists 0x1700 as Thermal Management and doesn't appear to distinguish 740 from 750.

    One odd thought is whether there is an MPC740 which is different from the PPC740. Clearly from the "About This Book" section, they are nearly identical:

    The primary objective of this user’s manual is to define the functionality of the PowerPC
    750™ and PowerPC 740™ microprocessors for use by software and hardware developers.
    Although the emphasis of this manual is upon the 750, unless otherwise noted, all
    information here applies to 740. 

    Maybe that reference helps.

    Comment 5
    1. phongvanpham, Wed, 17 May 2017 16:33:34 GMT

    Replying to Joel Sherrill:

    I did a quick google and turned up this:

    ​https://people.cs.clemson.edu/~mark/ppc750.pdf

    Which has 740 and 750 in the title. It lists 0x1700 as Thermal Management and doesn't appear to distinguish 740 from 750.

    One odd thought is whether there is an MPC740 which is different from the PPC740. Clearly from the "About This Book" section, they are nearly identical:

    The primary objective of this user’s manual is to define the functionality of the PowerPC
    750™ and PowerPC 740™ microprocessors for use by software and hardware developers.
    Although the emphasis of this manual is upon the 750, unless otherwise noted, all
    information here applies to 740. 

    Maybe that reference helps.

    Yes, that reference does help. Page 182 (where thermal exception management is described) states it is "750-specific".

    Comment 6
    1. phongvanpham, Mon, 22 May 2017 17:16:07 GMT

    Hi Developers,

    What is your status on this ticket? Are you accepting the change and I am just waiting for the code to be merged to main line or you are rejecting the change or postponing it to another release at a TBD date?

    If the variable names, etc. does not meet your standard, pls. change them to your liking.

    Comment 7
    1. Sebastian Huber, Tue, 23 May 2017 10:09:30 GMT

    Its still not clear to me why you cannot use the mpc_750_category_table for the IBM PPC750.

    Comment 8
    1. phongvanpham, Tue, 23 May 2017 16:02:58 GMT

    I copy & paste the two data structures for you convenience.

    static const ppc_exc_categories mpc_750_category_table = {

    PPC_BASIC_VECS,

    [ASM_60X_SYSMGMT_VECTOR] = PPC_EXC_CLASSIC | PPC_EXC_ASYNC, [ASM_60X_ADDR_VECTOR] = PPC_EXC_CLASSIC, [ASM_60X_ITM_VECTOR] = PPC_EXC_CLASSIC,

    };

    static const ppc_exc_categories ppc_750_category_table = {

    PPC_BASIC_VECS,

    [ASM_60X_PERFMON_VECTOR] = PPC_EXC_CLASSIC, [ASM_60X_SYSMGMT_VECTOR] = PPC_EXC_CLASSIC | PPC_EXC_ASYNC, [ASM_60X_ADDR_VECTOR] = PPC_EXC_CLASSIC, [ASM_60X_ITM_VECTOR] = PPC_EXC_CLASSIC,

    };

    There is 1 additional line in ppc_750 that is not in mpc750.

    Comment 9
    1. phongvanpham, Tue, 23 May 2017 16:20:45 GMT

    Replying to Sebastian Huber:

    Its still not clear to me why you cannot use the mpc_750_category_table for the IBM PPC750.

    Are you comfortable/Do you prefer that I add [ASM_60X_PERFMON_VECTOR] = PPC_EXC_CLASSIC,

    to mpc_750_category_table data structure? From the datasheet, it looks like this exception is missing but I only have access to PowerPC 750 chip so I can't verify anything for folks using MPC750.

    Comment 10
    1. Sebastian Huber, Wed, 24 May 2017 05:19:38 GMT

    Replying to phongvanpham:

    Replying to Sebastian Huber:

    Its still not clear to me why you cannot use the mpc_750_category_table for the IBM PPC750.

    Are you comfortable/Do you prefer that I add [ASM_60X_PERFMON_VECTOR] = PPC_EXC_CLASSIC,

    to mpc_750_category_table data structure? From the datasheet, it looks like this exception is missing but I only have access to PowerPC 750 chip so I can't verify anything for folks using MPC750.

    Yes, please add this to the mpc_750_category_table.

    Comment 11
    1. phongvanpham, Fri, 26 May 2017 00:06:48 GMT

    Replying to Sebastian Huber:

    Replying to phongvanpham:

    Replying to Sebastian Huber:

    Its still not clear to me why you cannot use the mpc_750_category_table for the IBM PPC750.

    Are you comfortable/Do you prefer that I add [ASM_60X_PERFMON_VECTOR] = PPC_EXC_CLASSIC,

    to mpc_750_category_table data structure? From the datasheet, it looks like this exception is missing but I only have access to PowerPC 750 chip so I can't verify anything for folks using MPC750.

    Yes, please add this to the mpc_750_category_table.

    Just completed. See the additional patch attachment.

    Comment 12
    1. Phong Pham, Mon, 29 May 2017 06:07:13 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 848007c/rtems:

    Add support for IBM PowerPC 750 chip. Closes #3015.
    Comment 13
    1. Sebastian Huber, Tue, 10 Oct 2017 06:32:53 GMT
    2. component: changed from libcpu to arch/powerpc
    Comment 14
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3016 - missing a couple register names + a #ifndef __ASM__ around serial.h inclusion

    Link https://devel.rtems.org/ticket/3016
    Id 3016
    Reporter phongvanpham
    Created 9 May 2017 23:38:34
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type defect
    Component bsps
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In rtems\c\src\libchip\serial\ns16550_p.h, need to add a couple register and #ifndef around serial.h

    Attachments:

    1 phongvanpham, Tue, 09 May 2017 23:46:27 GMT
      attach: set to ns16550_p.h
     
    2 phongvanpham, Tue, 09 May 2017 23:46:47 GMT
      attach: set to ns16550_p.h.orig
     
    3 phongvanpham, Fri, 12 May 2017 18:43:53 GMT
      attach: set to 0001-missing-a-couple-register-names-a-ifndef_ASM__-aroun.patch
     
    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Sebastian Huber, Fri, 12 May 2017 05:14:21 GMT

    Please generate the Git patch with your real name and a valid e-mail address.

    This ns16550_p.h is a private header file, why do you have to change it?

    Comment 3
    1. Phong Pham, Sun, 14 May 2017 03:50:58 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In f219adc/rtems:

    missing a couple register names + a #ifndef_ASM around serial.h inclusion Closes #3016.
    Comment 4
    1. phongvanpham, Wed, 17 May 2017 16:15:26 GMT

    Replying to Sebastian Huber:

    Please generate the Git patch with your real name and a valid e-mail address.

    This ns16550_p.h is a private header file, why do you have to change it?

    The changes are b/c a couple of register names are missing. Yes one can use another name with the intended value; however, this is unmaintainable code. As you can see, there are different names of the same value (register number) in the file.

    The reason to use #ifndef here is b/c I intend to use the file elsewhere in my BSP. Basically, I cherry pick code to maximize reuse in order to meet my needs. If you object to this particular change, (thus my needs are not met,) I will copy the file to my BSP to resolve my problem; thus a lack of sharing/reusing.

    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3017 - improvement in pci.h

    Link https://devel.rtems.org/ticket/3017
    Id 3017
    Reporter phongvanpham
    Created 9 May 2017 23:52:49
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type task
    Component score
    Status closed
    Resolution worksforme
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In pci.h, there are references to BSP_pci_configuration data structure which is in pci.c. However, in this file, there are also references to detect_host_bridge () in detect_raven_bridge.c. For folks that are just interested in pci_read_config_dword() + its brothers, all they need is to include pci.h and content for where BSP_pci_configuration is defined. The rest of the stuff in pci.c should be separate. Or in another word, data structures and #defines involving with BSP_pci_configuration needs to be in separate files rather all stuffed in pci.c

    I currently do not need this functionality for my BSP (nor do I able to test it), so I cannot modify code and submit. It is best someone who can test the code to make the code change. Or else, just shelf it under the table and/or close this ticket.

    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Joel Sherrill, Thu, 13 Jul 2017 13:46:29 GMT
    2. status: changed from new to closed
    3. resolution: set to worksforme

    This shouldn't be an issue since we compile and link with per-function-sections. With this set of options, a function is only included in an executable if it is actually referenced -- not just if it is in a file with a referenced symbol.

    FWIW Users using this option with large C++ applications have reported seeing their executables drop in size by half. C applications did get smaller but the RTEMS tests didn't show a huge improvement. Still it did drop some code out.

    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3018 - RSB cannot compile tool chain in CentOS 7.

    Link https://devel.rtems.org/ticket/3018
    Id 3018
    Reporter phongvanpham
    Created 10 May 2017 00:39:30
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type task
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In CentOS 6.8, everything works fine. But in CentOS 7, it does not. Initial investigation (I did a while back around New Year time) looks like later version of texinfo has an issue with autoconf. Enclosed is the email Chris Johns replied but I didn't follow through since I switched to CentOS 6.8 for my work.

    "Looks to me like the RSB is trying to download autoconf 2.69-1 and from ​https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711297

    Looks like this autoconf version has a bug. I also noticed my autoconf version is 2.69-11; however, from what I am reading, RSB will download its own version independent of what user has."

    Chris John replies:

    "I guess a recent texinfo version has exposed the issue. I suggest you get the patch from the link in the bug report, create a patch for rtems-tools.git to add the autoconf patch, then create a patch to the RSB adding the patch to the autoconf build, finally 'git send-email' the patches to devel@… for review."

    Attachments:

    1 phongvanpham, Wed, 10 May 2017 00:40:43 GMT
      attach: set to rsb-report-autoconf-2.69-x86_64-linux-gnu-1.txt
    Comment 1
    1. Sebastian Huber, Thu, 11 May 2017 07:31:02 GMT
    2. milestone: changed from 4.12 to 4.12.0
    Comment 2
    1. Chris Johns, Wed, 23 Aug 2017 22:55:10 GMT

    Joel, is this still valid?

    Comment 3
    1. Sebastian Huber, Thu, 24 Aug 2017 08:18:25 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    I built all tools today on a CentOS 7 machine without errors.

    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3020 - Review tests using CONFIGURE_DISABLE_SMP_CONFIGURATION

    Link https://devel.rtems.org/ticket/3020
    Id 3020
    Reporter Sebastian Huber
    Created 12 May 2017 08:43:27
    Modified 17 July 2020 09:22:42
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Some tests need CONFIGURE_DISABLE_SMP_CONFIGURATION to work correctly on SMP configurations. These tests must be reviewed. There should be a comment why this option is necessary or they should be changed to not use features unavailable on SMP, e.g. disabled preemption or an interrupt level mode > 0.

    Comment 1
    1. Chris Johns, Mon, 14 Aug 2017 00:55:55 GMT
    2. milestone: changed from 5.0 to 4.12.0

    Please review and update the milestone. Thanks.

    Comment 2
    1. Sebastian Huber, Tue, 10 Oct 2017 06:46:55 GMT
    2. component: changed from testing to unspecified
    Comment 3
    1. Joel Sherrill, Thu, 12 Oct 2017 00:28:30 GMT
    2. owner: changed from joel.sherrill@… to Sebastian Huber
    3. status: changed from new to assigned

    Refer to ​https://lists.rtems.org/pipermail/devel/2017-May/017784.html

    testsuites/testdata can be enhanced to know that these tests fail on SMP. This would make a master list of the tests. Longer term, the tests need to be reviewed for underlying cause. If it is a specific SMP unsafe operation, then split that into a different test.

    Comment 4
    1. Sebastian Huber, Thu, 12 Oct 2017 11:15:27 GMT
    2. milestone: changed from 4.12.0 to Indefinite
    Comment 5
    1. Sebastian Huber, Thu, 16 Nov 2017 14:29:34 GMT

    In e24d64b/rtems:

    psx05: Remove CONFIGURE_DISABLE_SMP_CONFIGURATION Update #3020.
    Comment 6
    1. Sebastian Huber, Fri, 01 Dec 2017 13:23:07 GMT

    In c589775a/rtems:

    ada: Use CONFIGURE_DISABLE_SMP_CONFIGURATION Most Ada tests fail otherwise. Update #3020.
    Comment 7
    1. Sebastian Huber, Fri, 17 Jul 2020 09:22:42 GMT
    2. status: changed from assigned to closed
    3. resolution: set to invalid
    4. milestone: changed from Indefinite to 5.1

    This configuration options was removed in RTEMS 5.1.


    3023 - Parameter of CPU_COPY() are in wrong order

    Link https://devel.rtems.org/ticket/3023
    Id 3023
    Reporter Sebastian Huber
    Created 19 May 2017 12:02:29
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component tool/newlib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    According to the FreeBSD man page we have:

    ​https://www.freebsd.org/cgi/man.cgi?query=cpuset&sektion=9&apropos=0&manpath=FreeBSD+11.0-RELEASE+and+Ports

    CPU_COPY(cpuset_t *from, cpuset_t *to); 

    However, in Newlib we have:

    static __inline void CPU_COPY( cpu_set_t *dest, const cpu_set_t *src )
    {
    *dest = *src;
    }
    Comment 1
    1. Sebastian Huber, Fri, 19 May 2017 12:02:39 GMT
    2. owner: changed from joel.sherrill@… to Sebastian Huber
    3. status: changed from new to accepted
    Comment 2
    1. Sebastian Huber, Wed, 07 Jun 2017 13:29:45 GMT

    In 836f454/rtems:

    Fix CPU_COPY() usage The original CPU_COPY() support of Newlib had the parameters in the wrong order. This is fixed in Newlib since 2017-05-22. Update #3023.
    Comment 3
    1. Sebastian Huber, Wed, 07 Jun 2017 13:39:58 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:25:41 GMT
    2. component: changed from SMP to tool/newlib
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3025 - m32c/m32csim does not build linpack-pc.c

    Link https://devel.rtems.org/ticket/3025
    Id 3025
    Reporter Chris Johns
    Created 24 May 2017 00:04:57
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    1 tests m32c/m32csim build:

    configure: /opt/work/chris/rtems/kernel/rtems.git/configure --target\
    =m32c-rtems4.12 --enable-rtemsbsp=m32csim --prefix=/opt/rtems/4.12\
    --enable-tests

    error: testsuites/benchmarks/linpack/linpack-pc.c:253:33: error:

    storage size of 'a' isn't constant

    error: testsuites/benchmarks/linpack/linpack-pc.c:253:21: error:

    storage size of 'aa' isn't constant

    Comment 1
    1. Joel Sherrill, Wed, 24 May 2017 14:29:26 GMT

    Disable it for this BSP. This test is almost certainly too large in some way for the m32c. I already disabled it for a number of other BSPs for similar reasons.

    Comment 2
    1. Chris Johns, Sun, 28 May 2017 21:58:39 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    The test has been disabled.

    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:46:55 GMT
    2. component: changed from testing to unspecified
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3027 - RTEMS source builder fails when building gcc documentation with newer versions of gcc

    Link https://devel.rtems.org/ticket/3027
    Id 3027
    Reporter Worth Burruss
    Created 30 May 2017 17:25:21
    Modified 10 April 2018 07:37:33
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords msys2, gcc
    Cc  
    Blocking  
    Blocked by  

    Description

    Originally discovered with MSYS2 on windows. Building the gcc compiler fails for older versions of gcc (ie 4.8.3) when building bfin and m32c architectures. The gcc maintainers recommend the use of MISSING=texinfo switch during configuration. A possible solution is attached.

    Attachments:

    1 Worth Burruss, Tue, 30 May 2017 17:26:17 GMT
      attach: set to gcc-MakeInfoFix-20170529-1.patch
    Comment 1
    1. Worth Burruss, Wed, 31 May 2017 00:52:01 GMT

    Originally discovered with MSYS2 on windows while building rtems 4.11. Building the gcc compiler fails when trying to build the documentation. This applies when a new version of gcc is used to build older versions of gcc (ie 4.8.3 such as when building bfin and m32c architectures for 4.11). The gcc maintainers recommend the use of MISSING=texinfo switch during configuration. A possible solution is attached.

    NOTE: this problem should also exist when trying to build rtems 4.10 compilers and earlier.

    Comment 2
    1. Chris Johns, Tue, 13 Jun 2017 00:32:49 GMT

    Is it MISSING=texinfo per the comments or MAKEINFO=missing as in the patch?

    Also I am thinking of adding this before the configure command set the environment variable:

    %if %{_host_os} == win32
      export MAKEINFO=missing
    %endif 
    Comment 3
    1. Chris Johns, Tue, 13 Jun 2017 05:45:21 GMT
    2. milestone: set to 4.11.2
    Comment 4
    1. Worth Burruss, Tue, 13 Jun 2017 13:27:39 GMT
    2. milestone: 4.11.2 deleted

    Sorry for the Confusion. I have been using: MAKEINFO=missing. I can not fathom where I got the other the switch from or if it is even valid.

    Limiting the solution to just windows fixes the problem for now, but will become a problem down the road as more OS's move to newer versions of GCC. From my point of view having a test to see if the Host GCC version is > 6.x is the way to do it. but I do not see a way to execute that logic. So for the short term that solution looks good.

    Comment 5
    1. Chris Johns, Wed, 14 Jun 2017 00:06:10 GMT

    Thanks for clearing up which to use.

    There is a reference on line to where the GCC developers discuss this issue and the solution?

    I am sorry but I am not following the relationship with makeinfo and the host's gcc version.

    Comment 6
    1. Worth Burruss, Wed, 14 Jun 2017 18:25:56 GMT

    Chris, you are correct it is not GCC version, I should have looked a little further it is makeinfo version. I got my original patch idea from here: ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60961 with better descriptions here: ​https://dev.openwrt.org/ticket/13039 and here: ​https://osmocom.org/issues/1916

    My MSYS2 is using makeinfo version 6.3 My CentOS was building fine and currently has makeinfo version 5.1

    Comment 7
    1. Chris Johns, Thu, 15 Jun 2017 03:13:29 GMT

    Replying to Worth Burruss:

    Chris, you are correct it is not GCC version, I should have looked a little further it is makeinfo version. I got my original patch idea from here: ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60961

    Thanks. Yes we need to disabled it for all gcc-4 builds.

    This says MISSING=texinfo.

    with better descriptions here: ​https://dev.openwrt.org/ticket/13039

    Here says MAKEINFO=missing.

    and here: ​https://osmocom.org/issues/1916

    and this has no solution.

    My MSYS2 is using makeinfo version 6.3 My CentOS was building fine and currently has makeinfo version 5.1

    Looks like we need this handled on the master branch as well.

    Comment 8
    1. Chris Johns, Thu, 29 Jun 2017 04:52:36 GMT

    I have a tried a both options and makeinfo is being run. I cannot make this work.

    Comment 9
    1. Chris Johns, Thu, 29 Jun 2017 05:43:27 GMT

    I was wrong MAKEINFO=missing is the solution. It seems like it is a configure thing.

    Comment 10
    1. Chris Johns, Mon, 03 Jul 2017 03:38:22 GMT

    In 0a916c3/rtems-source-builder:

    gcc: Disable makenfo cause newer verisons do not build gcc-4.8 docs. Newer makeinfo tools cannot build the existing texinfo in gcc so disable building it. This will not be fixed on the gcc branches. Updates #3027.
    Comment 11
    1. Chris Johns, Mon, 07 Aug 2017 01:51:09 GMT
    2. status: changed from new to assigned
    3. version: changed from 4.11 to 4.12
    4. milestone: set to 4.12.0

    Moving this to 4.12 as it has been fixed on 4.11.

    Comment 12
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 13
    1. Chris Johns, Tue, 10 Apr 2018 07:37:33 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3032 - CPU_NAND_S() implementation is not in line with FreeBSD

    Link https://devel.rtems.org/ticket/3032
    Id 3032
    Reporter Sebastian Huber
    Created 7 June 2017 06:47:21
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component tool/newlib
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    According to the FreeBSD man page we have:

    ​https://www.freebsd.org/cgi/man.cgi?query=cpuset&sektion=9&apropos=0&manpath=FreeBSD+11.0-RELEASE+and+Ports

    The CPU_NAND() macro removes CPUs in src from dst. (It is the cpuset(9) equivalent of the scalar: dst &= ~ src.)

    However, in Newlib we had:

    static __inline void CPU_NAND_S(size_t setsize, cpu_set_t *destset,
    const cpu_set_t *srcset1, const cpu_set_t *srcset2)
    {
    cpu_set_word_t *wdest = &destset->__bits[0];
    const cpu_set_word_t *wsrc1 = &srcset1->__bits[0];
    const cpu_set_word_t *wsrc2 = &srcset2->__bits[0];
    size_t n = setsize / sizeof(*wdest);
    size_t i;
    for (i = 0; i < n; ++i)
    wdest[i] = ~(wsrc1[i] & wsrc2[i]);
    }
    Comment 1
    1. Sebastian Huber, Wed, 07 Jun 2017 13:30:00 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In b06dbb26/rtems:

    spcpuset01: Update due to CPU_NAND_S() changes Close #3032.
    Comment 2
    1. Sebastian Huber, Tue, 10 Oct 2017 06:25:41 GMT
    2. component: changed from SMP to tool/newlib
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3036 - CPU_CMP() implementation is not in line with FreeBSD

    Link https://devel.rtems.org/ticket/3036
    Id 3036
    Reporter Sebastian Huber
    Created 9 June 2017 05:50:04
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type defect
    Component tool/newlib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    According to the FreeBSD man page we have:

    ​https://www.freebsd.org/cgi/man.cgi?query=cpuset&sektion=9&apropos=0&manpath=FreeBSD+11.0-RELEASE+and+Ports

    The CPU_CMP() macro returns true if cpuset1 is NOT equal to cpuset2.

    However, in Newlib we had:

    /* return 1 if the sets set1 and set2 are equal, otherwise return 0 */
    static __inline int CPU_CMP( const cpu_set_t *set1, const cpu_set_t *set2 )
    {
    return CPU_EQUAL(set1, set2);
    }
    Comment 1
    1. Sebastian Huber, Fri, 09 Jun 2017 05:51:35 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In f7d0f5e/rtems:

    spcpuset01: Update due to CPU_CMP() changes Close #3036.
    Comment 2
    1. Sebastian Huber, Tue, 10 Oct 2017 06:25:41 GMT
    2. component: changed from SMP to tool/newlib
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3040 - Cannot use RTEMS mailing list archive for patches

    Link https://devel.rtems.org/ticket/3040
    Id 3040
    Reporter Sebastian Huber
    Created 12 June 2017 11:34:41
    Modified 20 October 2018 22:44:28
    Owner Amar Takhar
    Type infra
    Component tool/website
    Status closed
    Resolution invalid
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The RTEMS mailing list archive has no option to get the raw e-mail via the web interface, e.g.

    ​https://lists.rtems.org/pipermail/devel/2017-June/018101.html

    For example the Newlib mailing list archive:

    ​https://sourceware.org/cgi-bin/get-raw-msg?listname=newlib&date=2017&msgid=20170612064218.11969-1-sebastian.huber%40embedded-brains.de

    Comment 1
    1. Amar Takhar, Mon, 12 Jun 2017 11:51:56 GMT
    2. owner: changed from joel.sherrill@… to Amar Takhar
    3. status: changed from new to accepted

    That's strange I will look into this shortly.

    Comment 2
    1. Amar Takhar, Mon, 12 Jun 2017 11:57:56 GMT

    I don't know how easy this is going to be. I've always grabbed the entire raw mbox file and pulled it out that way. You can find them on the list archive pages in gzipped form.

    I'll look into setting this up but I need to figure out the best and safest way to do it.

    Comment 3
    1. Amar Takhar, Sat, 20 Oct 2018 20:43:19 GMT
    2. status: changed from accepted to closed
    3. type: changed from defect to infra
    4. resolution: set to invalid
    5. milestone: changed from Indefinite to 5.1

    This isn't something we can support. It's a custom feature that I cannot find the source to.

    If you can get a copy of 'get-raw-msg' from Sourceware I can look into installing it..

    Comment 4
    1. Joel Sherrill, Sat, 20 Oct 2018 21:55:12 GMT

    What software package is get-raw-msg associated with? Is it part of Sourceware itself or something hosted on sourceware?

    Comment 5
    1. Amar Takhar, Sat, 20 Oct 2018 22:29:51 GMT

    I think it's something they created custom. I can't find any information on it at all. A few other projects seem to use it but they're hosted by sourceware..

    Comment 6
    1. Joel Sherrill, Sat, 20 Oct 2018 22:34:12 GMT

    This would be a mailman plugin?

    Comment 7
    1. Amar Takhar, Sat, 20 Oct 2018 22:44:28 GMT

    It's probably a custom CGI they created.

    The real fix for this is to move to Mailman v3. Here is an example setup:

    ​https://mail.python.org/mm3/

    The new frontend HyperKitty has a lot of functionality and also static email URLs. Which unlike v2 don't randomly change.


    3043 - 4.11/rtems-nios2 does not build on Windows.

    Link https://devel.rtems.org/ticket/3043
    Id 3043
    Reporter Chris Johns
    Created 12 June 2017 23:33:05
    Modified 9 November 2017 06:27:14
    Owner  
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The attached RSB report details the failure.

    The path to ranlib is the cwd (see make[5] path) plus the relative path (see the report) which is 308 characters in length and this exceeds the max path length for the Win32 API and binutils reports this as a No such file.

    Attachments:

    1 Chris Johns, Mon, 12 Jun 2017 23:33:31 GMT
      attach: set to rsb-report-nios2-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-w64-mingw32-1.txt
     
    Comment 1
    1. Chris Johns, Mon, 14 Aug 2017 01:00:40 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    4. milestone: set to 4.12.0

    Patch fixes for Windows have been merged.

    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3046 - 4.12/rtems-moxie missing release number.

    Link https://devel.rtems.org/ticket/3046
    Id 3046
    Reporter Chris Johns
    Created 13 June 2017 05:51:04
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    4.12/rtems-moxie is reporting

    cleaning: dtc-1.4.1-x86_64-freebsd11.0-1
    cleaning: expat-2.1.0-x86_64-freebsd11.0-1
    cleaning: moxie-rtems4.12-binutils-2.28-x86_64-freebsd11.0-
    cleaning: moxie-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170519-x86_64-freebsd11.0-
    cleaning: moxie-rtems4.12-gdb-7.12-x86_64-freebsd11.0-
    cleaning: rtems-tools-HEAD-

    There is no -1 or whatever at the end of the lines.

    Comment 1
    1. Joel Sherrill, Thu, 12 Oct 2017 02:27:31 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Fixed but didn't automatically update.

    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3047 - Remove docs directory from the RSB

    Link https://devel.rtems.org/ticket/3047
    Id 3047
    Reporter Chris Johns
    Created 14 June 2017 00:10:47
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The documentation has been moved to rtems-docs.git repo. Remove the docs directory and asciidocs from RTEMS.

    Comment 1
    1. Chris Johns, Thu, 03 Aug 2017 06:08:57 GMT

    Removing the doc directory means I can remove asciidoc from the source-builder/sb directory and make the RSB smaller. This means I need to remove the asciidoc report type.

    Any issues with this?

    Comment 2
    1. Gedare Bloom, Thu, 03 Aug 2017 11:58:28 GMT

    No issues from me. I think it is time.

    Comment 3
    1. Chris Johns, Mon, 07 Aug 2017 00:05:39 GMT
    2. component: changed from General to RSB
    Comment 4
    1. Chris Johns, Mon, 07 Aug 2017 00:08:40 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 8b96e17/rtems-source-builder:

    doc: Remove in source documentation and the asciidoc package The RSB documentation is now in ReST format and part of the RTEMS Documentation project. See ​https://docs.rtems.org/. Remove support for the GPL based asciidoc tool and remove the asciidoc package from the RSB. Add the Python Markdown package and update the reporter to use Markdown for HTML generation. The resuling HTML report is a single self contained file. Closes #3047.
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3049 - Warnings in libdebugger

    Link https://devel.rtems.org/ticket/3049
    Id 3049
    Reporter Joel Sherrill
    Created 14 June 2017 14:30:09
    Modified 14 October 2018 00:48:28
    Owner Chris Johns
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I started fixing the warnings in libdebugger with the latest tools but apparently some of the variables can't be changed to const char *const. So filing as a ticket so Chris can fix them more accurately.

    67 ../../../../../../rtems/c/src/../../cpukit/libdebugger/rtems-debugger-server.c:957:25: warning: comparison between pointer and zero character constant [-Wpointer-compare]

    67 ../../../../../../rtems/c/src/../../cpukit/libdebugger/rtems-debugger-server.c:61:19: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
    67 ../../../../../../rtems/c/src/../../cpukit/libdebugger/rtems-debugger-server.c:60:19: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
    67 ../../../../../../rtems/c/src/../../cpukit/libdebugger/rtems-debugger-server.c:53:14: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
    67 ../../../../../../rtems/c/src/../../cpukit/libdebugger/rtems-debugger-server.c:1490:14: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
    67 ../../../../../../rtems/c/src/../../cpukit/libdebugger/rtems-debugger-server.c:1426:14: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
    67 ../../../../../../rtems/c/src/../../cpukit/libdebugger/rtems-debugger-server.c:1302:14: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
    67 ../../../../../../rtems/c/src/../../cpukit/libdebugger/rtems-debugger-server.c:1260:14: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
    67 ../../../../../../rtems/c/src/../../cpukit/libdebugger/rtems-debugger-server.c:1064:14: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
    67 ../../../../../../rtems/c/src/../../cpukit/libdebugger/rtems-debugger-server.c:1025:14: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
    60 ../../../../../../rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:302:14: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
    60 ../../../../../../rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:301:14: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]

    Comment 1
    1. Joel Sherrill, Wed, 14 Jun 2017 14:30:24 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 3
    1. Joel Sherrill, Sun, 14 Oct 2018 00:48:28 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3052 - RSB: powerpc GDB build broken on Apple Darwin

    Link https://devel.rtems.org/ticket/3052
    Id 3052
    Reporter Sebastian Huber
    Created 20 June 2017 12:37:18
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    RTEMS Tools Project - Source Builder Error Report
    Build: error: building powerpc-rtems4.12-gdb-7.12-x86_64-apple-darwin14.5.0-1
    Command Line: ../source-builder/sb-set-builder --prefix=~/rtems/4.12 4.12/rtems-powerpc
    Python: 2.7.10 (default, Jul 14 2015, 19:46:27) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.39)]
    git://git.rtems.org/rtems-source-builder.git/origin/cb3fac1ea71f50b1bf7dcfe032c639392915d32a-modified
    Darwin yrael.lan 14.5.0 Darwin Kernel Version 14.5.0: Sun Sep 25 22:07:15 PDT 2016; root:xnu-2782.50.9~1/RELEASE_X86_64 x86_64
    Tail of the build log:
    ^
    ../../gdb-7.12/gdb/common/vec.h:711:18: note: expanded from macro '\
    DEF_VEC_FUNC_P'
    static inline T *VEC_OP (T,address) \
    ^
    ../../gdb-7.12/gdb/common/vec.h:399:22: note: expanded from macro 'VEC_OP'
    #define VEC_OP(T,OP) VEC_##T##_##OP
    ^
    :151:1: note: expanded from here
    VEC_tp_t_address
    ^
    ../../gdb-7.12/gdb/record-btrace.c:2445:1: warning: unused function 'VEC_tp_t_lower_bound' [-Wunused-function]
    ../../gdb-7.12/gdb/common/vec.h:428:20: note: expanded from macro 'DEF_VEC_P'
    VEC_T(T); \
    ^
    ../../gdb-7.12/gdb/common/vec.h:717:24: note: expanded from macro '\
    DEF_VEC_FUNC_P'
    static inline unsigned VEC_OP (T,lower_bound) \
    ^
    ../../gdb-7.12/gdb/common/vec.h:399:22: note: expanded from macro 'VEC_OP'
    #define VEC_OP(T,OP) VEC_##T##_##OP
    ^
    :155:1: note: expanded from here
    VEC_tp_t_lower_bound
    ^
    ../../gdb-7.12/gdb/record-btrace.c:2445:1: warning: unused function 'VEC_tp_t_alloc' [-Wunused-function]
    ../../gdb-7.12/gdb/common/vec.h:429:27: note: expanded from macro 'DEF_VEC_P'
    DEF_VEC_FUNC_P(T) \
    ^
    ../../gdb-7.12/gdb/common/vec.h:744:23: note: expanded from macro '\
    DEF_VEC_ALLOC_FUNC_P'
    static inline VEC(T) *VEC_OP (T,alloc) \
    ^
    ../../gdb-7.12/gdb/common/vec.h:399:22: note: expanded from macro 'VEC_OP'
    #define VEC_OP(T,OP) VEC_##T##_##OP
    ^
    :166:1: note: expanded from here
    VEC_tp_t_alloc
    ^
    ../../gdb-7.12/gdb/record-btrace.c:2445:1: warning: unused function 'VEC_tp_t_free' [-Wunused-function]
    ../../gdb-7.12/gdb/common/vec.h:429:27: note: expanded from macro 'DEF_VEC_P'
    DEF_VEC_FUNC_P(T) \
    ^
    ../../gdb-7.12/gdb/common/vec.h:751:20: note: expanded from macro '\
    DEF_VEC_ALLOC_FUNC_P'
    static inline void VEC_OP (T,free) \
    ^
    ../../gdb-7.12/gdb/common/vec.h:399:22: note: expanded from macro 'VEC_OP'
    #define VEC_OP(T,OP) VEC_##T##_##OP
    ^
    :170:1: note: expanded from here
    VEC_tp_t_free
    ^
    ../../gdb-7.12/gdb/record-btrace.c:2445:1: warning: unused function 'VEC_tp_t_merge' [-Wunused-function]
    ../../gdb-7.12/gdb/common/vec.h:429:27: note: expanded from macro 'DEF_VEC_P'
    DEF_VEC_FUNC_P(T) \
    ^
    ../../gdb-7.12/gdb/common/vec.h:784:23: note: expanded from macro '\
    DEF_VEC_ALLOC_FUNC_P'
    static inline VEC(T) *VEC_OP (T,merge) (VEC(T) *vec1_, VEC(T) *vec2_) \
    ^
    ../../gdb-7.12/gdb/common/vec.h:399:22: note: expanded from macro 'VEC_OP'
    #define VEC_OP(T,OP) VEC_##T##_##OP
    ^
    :187:1: note: expanded from here
    VEC_tp_t_merge
    ^
    ../../gdb-7.12/gdb/record-btrace.c:2445:1: warning: unused function 'VEC_tp_t_safe_grow' [-Wunused-function]
    ../../gdb-7.12/gdb/common/vec.h:429:27: note: expanded from macro 'DEF_VEC_P'
    DEF_VEC_FUNC_P(T) \
    ^
    ../../gdb-7.12/gdb/common/vec.h:817:20: note: expanded from macro '\
    DEF_VEC_ALLOC_FUNC_P'
    static inline void VEC_OP (T,safe_grow) \
    ^
    ../../gdb-7.12/gdb/common/vec.h:399:22: note: expanded from macro 'VEC_OP'
    #define VEC_OP(T,OP) VEC_##T##_##OP
    ^
    :205:1: note: expanded from here
    VEC_tp_t_safe_grow
    ^
    ../../gdb-7.12/gdb/record-btrace.c:2445:1: warning: unused function 'VEC_tp_t_safe_insert' [-Wunused-function]
    ../../gdb-7.12/gdb/common/vec.h:429:27: note: expanded from macro 'DEF_VEC_P'
    DEF_VEC_FUNC_P(T) \
    ^
    ../../gdb-7.12/gdb/common/vec.h:835:18: note: expanded from macro '\
    DEF_VEC_ALLOC_FUNC_P'
    static inline T *VEC_OP (T,safe_insert) \
    ^
    ../../gdb-7.12/gdb/common/vec.h:399:22: note: expanded from macro 'VEC_OP'
    #define VEC_OP(T,OP) VEC_##T##_##OP
    ^
    :225:1: note: expanded from here
    VEC_tp_t_safe_insert
    ^
    2 warnings generated.
    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -g -O2 -I. -I../../gdb-7.12/gdb -I../../gdb-7.12/gdb/common -I../../gdb-7.12/gdb/config -DLOCALEDIR="\"/rtems-source-builder/rtems/~/rtems/4.12/share/locale\"" -DHAVE_CONFIG_H -I../../gdb-7.12/gdb/../include/opcode -I../../gdb-7.12/gdb/../opcodes/.. -I../../gdb-7.12/gdb/../readline/.. -I../../gdb-7.12/gdb/../zlib -I../bfd -I../../gdb-7.12/gdb/../bfd -I../../gdb-7.12/gdb/../include -I../libdecnumber -I../../gdb-7.12/gdb/../libdecnumber -I../../gdb-7.12/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wformat-nonliteral -c -o debug.o -MT debug.o -MMD -MP -MF .deps/debug.Tpo ../../gdb-7.12/gdb/debug.c
    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -g -O2 -I. -I../../gdb-7.12/gdb -I../../gdb-7.12/gdb/common -I../../gdb-7.12/gdb/config -DLOCALEDIR="\"/rtems-source-builder/rtems/~/rtems/4.12/share/locale\"" -DHAVE_CONFIG_H -I../../gdb-7.12/gdb/../include/opcode -I../../gdb-7.12/gdb/../opcodes/.. -I../../gdb-7.12/gdb/../readline/.. -I../../gdb-7.12/gdb/../zlib -I../bfd -I../../gdb-7.12/gdb/../bfd -I../../gdb-7.12/gdb/../include -I../libdecnumber -I../../gdb-7.12/gdb/../libdecnumber -I../../gdb-7.12/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wformat-nonliteral -c -o common-exceptions.o -MT common-exceptions.o -MMD -MP -MF .deps/common-exceptions.Tpo ../../gdb-7.12/gdb/common/common-exceptions.c
    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -g -O2 -I. -I../../gdb-7.12/gdb -I../../gdb-7.12/gdb/common -I../../gdb-7.12/gdb/config -DLOCALEDIR="\"/rtems-source-builder/rtems/~/rtems/4.12/share/locale\"" -DHAVE_CONFIG_H -I../../gdb-7.12/gdb/../include/opcode -I../../gdb-7.12/gdb/../opcodes/.. -I../../gdb-7.12/gdb/../readline/.. -I../../gdb-7.12/gdb/../zlib -I../bfd -I../../gdb-7.12/gdb/../bfd -I../../gdb-7.12/gdb/../include -I../libdecnumber -I../../gdb-7.12/gdb/../libdecnumber -I../../gdb-7.12/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wformat-nonliteral -c -o btrace-common.o -MT btrace-common.o -MMD -MP -MF .deps/btrace-common.Tpo ../../gdb-7.12/gdb/common/btrace-common.c
    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -g -O2 -I. -I../../gdb-7.12/gdb -I../../gdb-7.12/gdb/common -I../../gdb-7.12/gdb/config -DLOCALEDIR="\"/rtems-source-builder/rtems/~/rtems/4.12/share/locale\"" -DHAVE_CONFIG_H -I../../gdb-7.12/gdb/../include/opcode -I../../gdb-7.12/gdb/../opcodes/.. -I../../gdb-7.12/gdb/../readline/.. -I../../gdb-7.12/gdb/../zlib -I../bfd -I../../gdb-7.12/gdb/../bfd -I../../gdb-7.12/gdb/../include -I../libdecnumber -I../../gdb-7.12/gdb/../libdecnumber -I../../gdb-7.12/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wformat-nonliteral -c -o fileio.o -MT fileio.o -MMD -MP -MF .deps/fileio.Tpo ../../gdb-7.12/gdb/common/fileio.c
    clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    2 warnings generated.
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -g -O2 -I. -I../../gdb-7.12/gdb -I../../gdb-7.12/gdb/common -I../../gdb-7.12/gdb/config -DLOCALEDIR="\"/rtems-source-builder/rtems/~/rtems/4.12/share/locale\"" -DHAVE_CONFIG_H -I../../gdb-7.12/gdb/../include/opcode -I../../gdb-7.12/gdb/../opcodes/.. -I../../gdb-7.12/gdb/../readline/.. -I../../gdb-7.12/gdb/../zlib -I../bfd -I../../gdb-7.12/gdb/../bfd -I../../gdb-7.12/gdb/../include -I../libdecnumber -I../../gdb-7.12/gdb/../libdecnumber -I../../gdb-7.12/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wformat-nonliteral -c -o common-regcache.o -MT common-regcache.o -MMD -MP -MF .deps/common-regcache.Tpo ../../gdb-7.12/gdb/common/common-regcache.c
    clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    2 warnings generated.
    2 warnings generated.
    2 warnings generated.
    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -g -O2 -I. -I../../gdb-7.12/gdb -I../../gdb-7.12/gdb/common -I../../gdb-7.12/gdb/config -DLOCALEDIR="\"/rtems-source-builder/rtems/~/rtems/4.12/share/locale\"" -DHAVE_CONFIG_H -I../../gdb-7.12/gdb/../include/opcode -I../../gdb-7.12/gdb/../opcodes/.. -I../../gdb-7.12/gdb/../readline/.. -I../../gdb-7.12/gdb/../zlib -I../bfd -I../../gdb-7.12/gdb/../bfd -I../../gdb-7.12/gdb/../include -I../libdecnumber -I../../gdb-7.12/gdb/../libdecnumber -I../../gdb-7.12/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wformat-nonliteral -c -o compile.o -MT compile.o -MMD -MP -MF .deps/compile.Tpo ../../gdb-7.12/gdb/compile/compile.c
    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -g -O2 -I. -I../../gdb-7.12/gdb -I../../gdb-7.12/gdb/common -I../../gdb-7.12/gdb/config -DLOCALEDIR="\"/rtems-source-builder/rtems/~/rtems/4.12/share/locale\"" -DHAVE_CONFIG_H -I../../gdb-7.12/gdb/../include/opcode -I../../gdb-7.12/gdb/../opcodes/.. -I../../gdb-7.12/gdb/../readline/.. -I../../gdb-7.12/gdb/../zlib -I../bfd -I../../gdb-7.12/gdb/../bfd -I../../gdb-7.12/gdb/../include -I../libdecnumber -I../../gdb-7.12/gdb/../libdecnumber -I../../gdb-7.12/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wformat-nonliteral -c -o compile-c-symbols.o -MT compile-c-symbols.o -MMD -MP -MF .deps/compile-c-symbols.Tpo ../../gdb-7.12/gdb/compile/compile-c-symbols.c
    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -g -O2 -I. -I../../gdb-7.12/gdb -I../../gdb-7.12/gdb/common -I../../gdb-7.12/gdb/config -DLOCALEDIR="\"/rtems-source-builder/rtems/~/rtems/4.12/share/locale\"" -DHAVE_CONFIG_H -I../../gdb-7.12/gdb/../include/opcode -I../../gdb-7.12/gdb/../opcodes/.. -I../../gdb-7.12/gdb/../readline/.. -I../../gdb-7.12/gdb/../zlib -I../bfd -I../../gdb-7.12/gdb/../bfd -I../../gdb-7.12/gdb/../include -I../libdecnumber -I../../gdb-7.12/gdb/../libdecnumber -I../../gdb-7.12/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wformat-nonliteral -c -o compile-c-types.o -MT compile-c-types.o -MMD -MP -MF .deps/compile-c-types.Tpo ../../gdb-7.12/gdb/compile/compile-c-types.c
    2 warnings generated.
    2 warnings generated.
    clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -g -O2 -I. -I../../gdb-7.12/gdb -I../../gdb-7.12/gdb/common -I../../gdb-7.12/gdb/config -DLOCALEDIR="\"/rtems-source-builder/rtems/~/rtems/4.12/share/locale\"" -DHAVE_CONFIG_H -I../../gdb-7.12/gdb/../include/opcode -I../../gdb-7.12/gdb/../opcodes/.. -I../../gdb-7.12/gdb/../readline/.. -I../../gdb-7.12/gdb/../zlib -I../bfd -I../../gdb-7.12/gdb/../bfd -I../../gdb-7.12/gdb/../include -I../libdecnumber -I../../gdb-7.12/gdb/../libdecnumber -I../../gdb-7.12/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wformat-nonliteral -c -o compile-object-load.o -MT compile-object-load.o -MMD -MP -MF .deps/compile-object-load.Tpo ../../gdb-7.12/gdb/compile/compile-object-load.c
    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -g -O2 -I. -I../../gdb-7.12/gdb -I../../gdb-7.12/gdb/common -I../../gdb-7.12/gdb/config -DLOCALEDIR="\"/rtems-source-builder/rtems/~/rtems/4.12/share/locale\"" -DHAVE_CONFIG_H -I../../gdb-7.12/gdb/../include/opcode -I../../gdb-7.12/gdb/../opcodes/.. -I../../gdb-7.12/gdb/../readline/.. -I../../gdb-7.12/gdb/../zlib -I../bfd -I../../gdb-7.12/gdb/../bfd -I../../gdb-7.12/gdb/../include -I../libdecnumber -I../../gdb-7.12/gdb/../libdecnumber -I../../gdb-7.12/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wformat-nonliteral -c -o compile-object-run.o -MT compile-object-run.o -MMD -MP -MF .deps/compile-object-run.Tpo ../../gdb-7.12/gdb/compile/compile-object-run.c
    clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    2 warnings generated.
    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -g -O2 -I. -I../../gdb-7.12/gdb -I../../gdb-7.12/gdb/common -I../../gdb-7.12/gdb/config -DLOCALEDIR="\"/rtems-source-builder/rtems/~/rtems/4.12/share/locale\"" -DHAVE_CONFIG_H -I../../gdb-7.12/gdb/../include/opcode -I../../gdb-7.12/gdb/../opcodes/.. -I../../gdb-7.12/gdb/../readline/.. -I../../gdb-7.12/gdb/../zlib -I../bfd -I../../gdb-7.12/gdb/../bfd -I../../gdb-7.12/gdb/../include -I../libdecnumber -I../../gdb-7.12/gdb/../libdecnumber -I../../gdb-7.12/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wformat-nonliteral -c -o compile-loc2c.o -MT compile-loc2c.o -MMD -MP -MF .deps/compile-loc2c.Tpo ../../gdb-7.12/gdb/compile/compile-loc2c.c
    clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    2 warnings generated.
    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -g -O2 -I. -I../../gdb-7.12/gdb -I../../gdb-7.12/gdb/common -I../../gdb-7.12/gdb/config -DLOCALEDIR="\"/rtems-source-builder/rtems/~/rtems/4.12/share/locale\"" -DHAVE_CONFIG_H -I../../gdb-7.12/gdb/../include/opcode -I../../gdb-7.12/gdb/../opcodes/.. -I../../gdb-7.12/gdb/../readline/.. -I../../gdb-7.12/gdb/../zlib -I../bfd -I../../gdb-7.12/gdb/../bfd -I../../gdb-7.12/gdb/../include -I../libdecnumber -I../../gdb-7.12/gdb/../libdecnumber -I../../gdb-7.12/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wformat-nonliteral -c -o compile-c-support.o -MT compile-c-support.o -MMD -MP -MF .deps/compile-c-support.Tpo ../../gdb-7.12/gdb/compile/compile-c-support.c
    clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    2 warnings generated.
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -g -O2 -I. -I../../gdb-7.12/gdb -I../../gdb-7.12/gdb/common -I../../gdb-7.12/gdb/config -DLOCALEDIR="\"/rtems-source-builder/rtems/~/rtems/4.12/share/locale\"" -DHAVE_CONFIG_H -I../../gdb-7.12/gdb/../include/opcode -I../../gdb-7.12/gdb/../opcodes/.. -I../../gdb-7.12/gdb/../readline/.. -I../../gdb-7.12/gdb/../zlib -I../bfd -I../../gdb-7.12/gdb/../bfd -I../../gdb-7.12/gdb/../include -I../libdecnumber -I../../gdb-7.12/gdb/../libdecnumber -I../../gdb-7.12/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wformat-nonliteral -c -o inflow.o -MT inflow.o -MMD -MP -MF .deps/inflow.Tpo ../../gdb-7.12/gdb/inflow.c
    clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    2 warnings generated.
    ../../gdb-7.12/gdb/compile/compile-loc2c.c:733:6: warning: variable 'uoffset' is uninitialized when used here [-Wuninitialized]
    uoffset += dwarf2_per_cu_text_offset (per_cu);
    ^~~~~~~
    ../../gdb-7.12/gdb/compile/compile-loc2c.c:671:23: note: initialize the variable 'uoffset' to silence this warning
    uint64_t uoffset, reg;
    ^
    = 0
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    2 warnings generated.
    2 warnings generated.
    17 warnings generated.
    2 warnings generated.
    3 warnings generated.
    2 warnings generated.
    99 warnings generated.
    Making init.c
    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -g -O2 -I. -I../../gdb-7.12/gdb -I../../gdb-7.12/gdb/common -I../../gdb-7.12/gdb/config -DLOCALEDIR="\"/rtems-source-builder/rtems/~/rtems/4.12/share/locale\"" -DHAVE_CONFIG_H -I../../gdb-7.12/gdb/../include/opcode -I../../gdb-7.12/gdb/../opcodes/.. -I../../gdb-7.12/gdb/../readline/.. -I../../gdb-7.12/gdb/../zlib -I../bfd -I../../gdb-7.12/gdb/../bfd -I../../gdb-7.12/gdb/../include -I../libdecnumber -I../../gdb-7.12/gdb/../libdecnumber -I../../gdb-7.12/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wformat-nonliteral -c -o init.o -MT init.o -MMD -MP -MF .deps/init.Tpo init.c
    clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    2 warnings generated.
    rm -f gdb
    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/include -g -O2 -Wl,-no_pie -L/rtems-source-builder/rtems/build/tmp/sb-peer/4.12/rtems-powerpc/rtems-source-builder/rtems/~/rtems/4.12/lib \
    -o gdb gdb.o rs6000-tdep.o ppc-sysv-tdep.o solib-svr4.o ravenscar-thread.o ppc-ravenscar-thread.o ser-base.o ser-unix.o ser-pipe.o ser-tcp.o remote.o dcache.o tracepoint.o ax-general.o ax-gdb.o remote-fileio.o remote-notif.o ctf.o tracefile.o tracefile-tfile.o remote-sim.o cli-dump.o cli-decode.o cli-script.o cli-cmds.o cli-setshow.o cli-logging.o cli-interp.o cli-utils.o mi-out.o mi-console.o mi-cmds.o mi-cmd-catch.o mi-cmd-env.o mi-cmd-var.o mi-cmd-break.o mi-cmd-stack.o mi-cmd-file.o mi-cmd-disas.o mi-symbol-cmds.o mi-cmd-target.o mi-cmd-info.o mi-interp.o mi-main.o mi-parse.o mi-getopt.o tui-command.o tui-data.o tui-disasm.o tui-file.o tui-hooks.o tui-interp.o tui-io.o tui-layout.o tui-out.o tui-regs.o tui-source.o tui-stack.o tui-win.o tui-windata.o tui-wingeneral.o tui-winsource.o tui.o python.o py-arch.o py-auto-load.o py-block.o py-bpevent.o py-breakpoint.o py-cmd.o py-continueevent.o py-xmethods.o py-event.o py-evtregistry.o py-evts.o py-exitedevent.o py-finishbreakpoint.o py-frame.o py-framefilter.o py-function.o py-gdb-readline.o py-inferior.o py-infevents.o py-infthread.o py-lazy-string.o py-linetable.o py-newobjfileevent.o py-objfile.o py-param.o py-prettyprint.o py-progspace.o py-signalevent.o py-stopevent.o py-symbol.o py-symtab.o py-threadevent.o py-type.o py-unwind.o py-utils.o py-value.o py-varobj.o guile.o elfread.o stap-probe.o dtrace-probe.o posix-hdep.o posix-strerror.o c-exp.o cp-name-parser.o ada-exp.o jv-exp.o d-exp.o f-exp.o go-exp.o m2-exp.o p-exp.o rust-exp.o version.o annotate.o addrmap.o auto-load.o auxv.o agent.o bfd-target.o blockframe.o breakpoint.o break-catch-sig.o break-catch-throw.o break-catch-syscall.o findvar.o regcache.o cleanups.o charset.o continuations.o corelow.o disasm.o dummy-frame.o dfp.o source.o value.o eval.o valops.o valarith.o valprint.o printcmd.o block.o symtab.o psymtab.o symfile.o symfile-debug.o symmisc.o linespec.o dictionary.o namespace.o location.o infcall.o infcmd.o infrun.o expprint.o environ.o stack.o tid-parse.o thread.o thread-fsm.o exceptions.o extension.o filesystem.o filestuff.o inf-child.o interps.o minidebug.o main.o macrotab.o macrocmd.o macroexp.o macroscope.o mi-common.o event-loop.o event-top.o inf-loop.o completer.o gdbarch.o arch-utils.o gdbtypes.o gdb_bfd.o gdb_obstack.o osabi.o copying.o memattr.o mem-break.o target.o target-dcache.o parse.o language.o build-id.o buildsym.o findcmd.o std-regs.o signals-state-save-restore.o signals.o exec.o reverse.o bcache.o objfiles.o observer.o minsyms.o maint.o demangle.o dbxread.o coffread.o coff-pe-read.o dwarf2read.o mipsread.o stabsread.o corefile.o dwarf2expr.o dwarf2loc.o dwarf2-frame.o dwarf2-frame-tailcall.o ada-lang.o c-lang.o d-lang.o f-lang.o objc-lang.o ada-tasks.o ada-varobj.o c-varobj.o ui-out.o cli-out.o varobj.o vec.o go-lang.o go-valprint.o go-typeprint.o jv-lang.o jv-valprint.o jv-typeprint.o jv-varobj.o m2-lang.o opencl-lang.o p-lang.o p-typeprint.o p-valprint.o selftest.o sentinel-frame.o complaints.o typeprint.o ada-typeprint.o c-typeprint.o f-typeprint.o m2-typeprint.o ada-valprint.o c-valprint.o cp-valprint.o d-valprint.o f-valprint.o m2-valprint.o ser-event.o serial.o mdebugread.o top.o utils.o ui-file.o user-regs.o frame.o frame-unwind.o doublest.o frame-base.o inline-frame.o gnu-v2-abi.o gnu-v3-abi.o cp-abi.o cp-support.o cp-namespace.o d-namespace.o reggroups.o rust-lang.o trad-frame.o tramp-frame.o solib.o solib-target.o prologue-value.o memory-map.o memrange.o xml-support.o xml-syscall.o xml-utils.o target-descriptions.o target-memory.o xml-tdesc.o xml-builtin.o inferior.o osdata.o gdb_usleep.o record.o record-full.o gcore.o gdb_vecs.o jit.o progspace.o skip.o probe.o common-utils.o buffer.o ptid.o gdb-dlfcn.o common-agent.o format.o registry.o btrace.o record-btrace.o waitstatus.o print-utils.o rsp-low.o errors.o common-debug.o debug.o common-exceptions.o btrace-common.o fileio.o common-regcache.o compile.o compile-c-symbols.o compile-c-types.o compile-object-load.o compile-object-run.o compile-loc2c.o compile-c-support.o inflow.o init.o \
    ../sim/ppc/libsim.a ../readline/libreadline.a ../opcodes/libopcodes.a ../bfd/libbfd.a -L./../zlib -lz ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lncurses -lm -L/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config -ldl -framework CoreFoundation -lpython2.7 -u _PyMac_Error /System/Library/Frameworks/Python.framework/Versions/2.7/Python -lexpat ../libiberty/libiberty.a build-gnulib/import/libgnu.a -liconv
    Undefined symbols for architecture x86_64:
    "_error", referenced from:
    _sim_io_printf_filtered in libsim.a(sim_calls.o)
    _sim_load in libsim.a(sim_calls.o)
    _sim_create_inferior in libsim.a(sim_calls.o)
    _sim_io_read_stdin in libsim.a(sim_calls.o)
    _sim_io_write_stdout in libsim.a(sim_calls.o)
    _sim_io_write_stderr in libsim.a(sim_calls.o)
    _sim_io_flush_stdoutput in libsim.a(sim_calls.o)
    ...
    (maybe you meant: _device_error, __Z20host_to_fileio_errori , _bfd_get_error_handler , __bfd_default_error_handler , _bfd_set_error_handler , _bfd_set_error_program_name , __Z28dwarf_reg_to_regnum_or_errorP7gdbarchm , __Z29observer_detach_command_errorP8observer , _sim_io_error , _deprecated_error_begin_hook , __Z35throw_max_completions_reached_errorv , __Z25type_name_no_tag_or_errorP4type , __Z12memory_error18target_xfer_statusm , __bfd_error_handler , __Z20annotate_error_beginv , __Z19compile_rx_or_errorP17re_pattern_bufferPKcS2_ , __Z12catch_errorsPFiPvES_Pc11return_mask , __Z20memory_error_message18target_xfer_statusP7gdbarchm , __Z11range_errorPKcz , __Z13gdb_xml_errorP14gdb_xml_parserPKcz , __Z29observer_notify_command_errorv , _gdbpy_gdb_memory_error , _bfd_set_error , __Z23invalid_thread_id_errorPKc , __Z11throw_error6errorsPKcz , _gdbpy_gdb_error , __Z14gdb_bfd_errmsg9bfd_errorPPc , __Z29observer_attach_command_errorPFvvE , __Z27gdbpy_print_python_errors_pv , _bfd_get_error , __Z14internal_errorPKciS0_z , __Z17get_regcomp_erroriP17re_pattern_buffer , __Z14annotate_errorv )
    ld: symbol(s) not found for architecture x86_64
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    make[2]: *** [gdb] Error 1
    make[1]: *** [all-gdb] Error 2
    make: *** [all] Error 2
    shell cmd failed: /bin/sh -ex /rtems-source-builder/rtems/build/powerpc-rtems4.12-gdb-7.12-x86_64-apple-darwin14.5.0-1/doit
    error: building powerpc-rtems4.12-gdb-7.12-x86_64-apple-darwin14.5.0-1
    Comment 1
    1. Sebastian Huber, Fri, 23 Jun 2017 05:33:59 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 21a9010/rtems-source-builder:

    Fix GDB 7.12 build on Darwin Close #3052.
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3054 - gdb 7.12.1 on RSB 4.12 branch fail to build on Archlinux

    Link https://devel.rtems.org/ticket/3054
    Id 3054
    Reporter AndiK
    Created 28 June 2017 07:44:58
    Modified 9 November 2017 06:27:14
    Owner Andreas Kölbl <andreas.koelbl@…>
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    7.12.1 does not compile with latest guile
    As already stated here: ​https://sourceware.org/bugzilla/show_bug.cgi?id=21104 GDB in version 7.12.1 fails when trying to compile on Archlinux. GDB uses deprecated functions of libguile which were gone in version 2.2 of libguile. As GDB states in its configure script to support version 2.2 of libguile it fails compiling.

    Tested with the latest rtems source builder on master.

    Attachments:

    1 AndiK, Wed, 28 Jun 2017 08:13:10 GMT
      attach: set to rsb-report-arm-rtems4.12-gdb-7.12-x86_64-linux-gnu-1.txt
     
    Comment 1
    1. Joel Sherrill, Wed, 28 Jun 2017 16:09:15 GMT

    I have no idea what guile is being used for but based on the comments in the gdb PR, it looks like it isn't getting fixed on the 7.12 branch. Looks like Freddie's suggestion is the most practical one.

    Freddie Chopin 2017-05-02 21:23:58 UTC For me a "workaround" is to explicitly disable guile by passing --with-guile=no to GDB's configure script

    A semi-proper solution for 7.12 would be to detect the newer guile version and disable guile.

    The PR thread doesn't mention if this is fixed in a newer gdb which leads me to believe that it hasn't been.

    Comment 2
    1. Joel Sherrill, Wed, 28 Jun 2017 16:26:58 GMT

    Follow up based on discussions on the gdb PR. This is also broken with gdb 8.0. ArchLinux? uses gdb 8.0 with guile 2.0.

    We have two options:

    build a known guile version as a dependency for gdb disable guile

    guile (Scheme) is used as an alternative to Python to program gdb from a user perspective.

    My personal recommendation to you would be to disable guile in the RSB configuration files and submit a patch.

    Whether or not this is the best permanent solution is up for discussion from an RTEMS community discussion. I suspect it is the best solution though.

    Comment 3
    1. Andreas Kölbl, Mon, 03 Jul 2017 21:59:59 GMT
    2. owner: set to Andreas Kölbl <andreas.koelbl@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In d413d7e/rtems-source-builder:

    Fix GDB build on ArchLinux? Archlinux provides both, libguile v2.0 and v2.2. GDB states in configuration its compatibility with both versions of libguile which is false. The SCM_port interface of libguile was removed in v2.2 and therefore breaks GDB as a user. RTEMS does not use libguile and therefore it can be compiled without support. ​https://sourceware.org/bugzilla/show_bug.cgi?id=21104 Close #3054.
    Comment 4
    1. Chris Johns, Wed, 12 Jul 2017 22:33:32 GMT
    2. milestone: changed from 4.12.1 to 4.12.0
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3056 - Add EDF SMP scheduler

    Link https://devel.rtems.org/ticket/3056
    Id 3056
    Reporter Sebastian Huber
    Created 29 June 2017 09:10:33
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The current SMP schedulers are all fixed-priority schedulers. Add a job-level fixed priority scheduler (EDF).

    Comment 1
    1. Sebastian Huber, Fri, 30 Jun 2017 06:00:40 GMT

    In 1dbce41/rtems:

    smptests: Split smpscheduler03 Split smpscheduler03 to run the tests with only one processor. Update #3056.
    Comment 2
    1. Sebastian Huber, Fri, 30 Jun 2017 06:00:53 GMT

    In 15dbc71/rtems:

    score: Add red-black tree node to Scheduler_Node In SMP configurations, add a red-black tree node to Scheduler_Node to enable an EDF scheduler implementation. Update #3056.
    Comment 3
    1. Sebastian Huber, Fri, 30 Jun 2017 06:01:05 GMT

    In f3d9f228/rtems:

    score: Add SMP EDF scheduler Update #3056.
    Comment 4
    1. Sebastian Huber, Fri, 30 Jun 2017 06:01:16 GMT

    In 74f9db8/rtems:

    score: Add RTEMS_NO_INLINE Update #3056.
    Comment 5
    1. Sebastian Huber, Fri, 30 Jun 2017 06:01:28 GMT

    In 7f7a3e8f/rtems:

    tests: Move busy loop to test support Update #3056.
    Comment 6
    1. Sebastian Huber, Fri, 30 Jun 2017 06:01:41 GMT

    In 7adf4941/rtems:

    smptests/smpschededf01: New test Update #3056.
    Comment 7
    1. Sebastian Huber, Mon, 03 Jul 2017 07:43:13 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 8cf3d75/rtems-docs:

    c-user: Document EDF SMP Close #3056.
    Comment 8
    1. Sebastian Huber, Tue, 10 Oct 2017 06:27:10 GMT
    2. component: changed from SMP to score
    Comment 9
    1. Sebastian Huber, Tue, 10 Oct 2017 06:29:01 GMT
    2. component: changed from score to cpukit
    Comment 10
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3057 - Add a workaround for the LEON3FT store-store errata

    Link https://devel.rtems.org/ticket/3057
    Id 3057
    Reporter Sebastian Huber
    Created 3 July 2017 05:25:06
    Modified 9 November 2017 06:27:14
    Owner Daniel Hellstrom
    Type defect
    Component tool/gcc
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    GCC needs support to provide a workaround for the LEON3FT store-store errata, e.g.

    ​https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01577.html

    and follow up versions.

    Attachments:

    1 Sebastian Huber, Mon, 17 Jul 2017 05:51:39 GMT
      attach: set to 0001-config-sparc-sparc.opt-mfix-ut700-New-option.patch
    Comment 1
    1. Sebastian Huber, Wed, 12 Jul 2017 09:19:20 GMT

    Something was added to GCC 7 branch:

    ​https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=250121

    Fix is incomplete.

    Comment 2
    1. Daniel Cederman, Mon, 17 Jul 2017 05:42:46 GMT

    In 2f8704b6/rtems:

    sparc: Add assembly workaround for LEON3FT B2BST errata This patch adds NOP instructions to prevent instruction sequences that are sensitive to the LEON3FT B2BST errata. See GRLIB-TN-0009: "LEON3FT Stale Cache Entry After Store with Data Tag Parity Error" for more information. The sequences are only modified if FIX_LEON3FT_B2BST is defined. The patch works in conjunction with the -mfix-ut700, -mfix-gr712rc, and -mfix-ut699 GCC flags that prevents the sensitive sequences from being generated. Update #3057.
    Comment 3
    1. Daniel Cederman, Mon, 17 Jul 2017 05:45:23 GMT

    In 4debaca6/rtems:

    bsps/sparc: Add leon3 BSP variants Rename NGMP to GR740 and add configs for UT699, UT700, and GR712RC The UT699 requires -mcpu=leon as it does not support the CAS instruction provided by -mcpu=leon3. It also requires -mfix-ut699 for errata fixes. UT700 and GR712RC requires the -mfix-ut700 and -mfix-gr712rc flags that have been recently added to GCC's master and 7-branch. Remove -msoft-float from the leon3 config to make the more common case of using the FPU the default. Update #3057.
    Comment 4
    1. Sebastian Huber, Mon, 17 Jul 2017 06:31:35 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In e2952bb/rtems-source-builder:

    4.12: Add LEON3FT store-store errata workaround Close #3057.
    Comment 5
    1. Sebastian Huber, Tue, 10 Oct 2017 05:58:26 GMT
    2. component: changed from GCC to tool/gcc
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3059 - Add a simple processor affinity support to the EDF SMP scheduler

    Link https://devel.rtems.org/ticket/3059
    Id 3059
    Reporter Sebastian Huber
    Created 4 July 2017 07:31:27
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add support to the EDF SMP scheduler to honour one-to-one and one-to-all thread processor affinities. Use one ready queue for threads with a one-to-all affinity. Use one ready queue for each of the one-to-one threads for each processor. Since a red-black tree is used for the ready queues, the space overhead of one pointer per ready queue is small.

    Comment 1
    1. Sebastian Huber, Mon, 10 Jul 2017 07:33:00 GMT

    In fd03ba4/rtems-source-builder:

    4.12: Fix and update bitset(9) Update #3059.
    Comment 2
    1. Sebastian Huber, Mon, 10 Jul 2017 07:37:14 GMT

    In 3dfe55ee/rtems:

    score: Use for Processor_mask Implement the Processor_mask via . Provide _Processor_mask_To_uint32_t() to enable its use in device specific routines, e.g. interrupt affinity register in an interrupt controller. Update #3059.
    Comment 3
    1. Sebastian Huber, Mon, 10 Jul 2017 07:37:27 GMT

    In 7a5e4d94/rtems:

    score: Add processor mask to/from cpu_set_t Update #3059.
    Comment 4
    1. Sebastian Huber, Mon, 10 Jul 2017 07:37:38 GMT

    In 6223097a/rtems:

    score: Add some processor mask functions Update #3059.
    Comment 5
    1. Sebastian Huber, Mon, 10 Jul 2017 07:37:51 GMT

    In 7851555/rtems:

    score: Move processor affinity to Thread_Control Update #3059.
    Comment 6
    1. Sebastian Huber, Mon, 10 Jul 2017 07:38:03 GMT

    In 6b1d8c7/rtems:

    score: Add processor set to scheduler context Replace the simple processor count with the processor set owned by the scheduler instance. Update #3059.
    Comment 7
    1. Sebastian Huber, Mon, 10 Jul 2017 07:38:15 GMT

    In 1ec9c86/rtems:

    rtems: Fix rtems_scheduler_remove_processor() Account for the thread processor affinity and make sure that it is possible to allocate a processor to each thread dedicated to a scheduler instance. Update #3059.
    Comment 8
    1. Sebastian Huber, Mon, 10 Jul 2017 07:38:28 GMT

    In 0232b28/rtems:

    score: Use processor mask for set affinity Update #3059.
    Comment 9
    1. Sebastian Huber, Mon, 10 Jul 2017 07:38:41 GMT

    In 76d1198/rtems:

    score: Introduce _SMP_Get_online_processors() Update #3059.
    Comment 10
    1. Sebastian Huber, Mon, 10 Jul 2017 07:38:53 GMT

    In 16347a6/rtems:

    score: Fix default set affinity The set of online processors must be a subset of the thread processor affinity for the schedulers without arbitrary processor affinity support to avoid problems in case of processor addition and removal. Update #3059.
    Comment 11
    1. Sebastian Huber, Mon, 10 Jul 2017 07:39:05 GMT

    In 197a614/rtems:

    score: Add scheduler node to set affinity op Update #3059.
    Comment 12
    1. Sebastian Huber, Mon, 10 Jul 2017 07:39:17 GMT

    In e745ec5/rtems:

    smptests/smpstrongapa01: Simplify Update #3059.
    Comment 13
    1. Sebastian Huber, Mon, 10 Jul 2017 07:39:29 GMT

    In d19dc071/rtems:

    score: Pass scheduler nodes to processor allocator This allows scheduler implementations to easily access scheduler-specific data. Update #3059.
    Comment 14
    1. Sebastian Huber, Mon, 10 Jul 2017 07:39:41 GMT

    In 34487537/rtems:

    score: Add simple affinity support to EDF SMP Update #3059.
    Comment 15
    1. Sebastian Huber, Mon, 10 Jul 2017 07:39:54 GMT

    In 4a1bdd30/rtems:

    score: Fix set scheduler Ensure that the thread processor affinity fits the new scheduler instance. Update #3059.
    Comment 16
    1. Sebastian Huber, Mon, 10 Jul 2017 07:40:06 GMT

    In 21389c06/rtems:

    score: Make EDF the default SMP scheduler The EDF SMP scheduler supports simple thread processor affinities (see #3059) with a small run-time overhead. The current default SMP scheduler lacks support for thread processor affinities at all. The EDF SMP scheduler offers a good feature set for most applications. So, use it by default. Run-time libraries like libgomp, MTAPI, work stealing schedulers, language interpreters (e.g. Erlang virtual machine), maintainence of per-processor data (e.g. Universal Memory Allocator (UMA)), etc. use a one-to-one thread processor affinity for example. Update #3063.
    Comment 17
    1. Sebastian Huber, Mon, 10 Jul 2017 07:49:06 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 9037998/rtems-docs:

    c-user: Update scheduler/task chapter Reflect EDF SMP scheduler changes. Close #3059. Close #3063.
    Comment 18
    1. Sebastian Huber, Tue, 11 Jul 2017 11:51:47 GMT

    In 3b14e7aa/rtems:

    rtems: Fix warning Update #3059.
    Comment 19
    1. Sebastian Huber, Tue, 11 Jul 2017 12:16:24 GMT

    In c29eb085/rtems:

    bsps/sparc: Fix ambapp_int_set_affinity() Update #3059.
    Comment 20
    1. Sebastian Huber, Wed, 12 Jul 2017 06:15:29 GMT

    In 8397320/rtems-source-builder:

    4.12: Fix bitset(9) Update #3059.
    Comment 21
    1. Sebastian Huber, Wed, 12 Jul 2017 08:57:27 GMT

    In e2623038/rtems:

    score: Fix typo Update #3059.
    Comment 22
    1. Sebastian Huber, Tue, 18 Jul 2017 12:38:53 GMT

    In 852d7059/rtems:

    score: Fix warning Update #3059.
    Comment 23
    1. Sebastian Huber, Wed, 19 Jul 2017 11:04:31 GMT

    In 96ce1ec/rtems:

    smptests/smpscheduler02: Remove invalid assert Update #3059.
    Comment 24
    1. Sebastian Huber, Fri, 22 Sep 2017 12:24:57 GMT

    In 560acb62/rtems:

    score: Include missing header file Update #3059.
    Comment 25
    1. Sebastian Huber, Tue, 10 Oct 2017 06:27:10 GMT
    2. component: changed from SMP to score
    Comment 26
    1. Sebastian Huber, Tue, 10 Oct 2017 06:29:01 GMT
    2. component: changed from score to cpukit
    Comment 27
    1. Sebastian Huber, Tue, 07 Nov 2017 06:09:28 GMT

    In bceb9db6/rtems:

    score: Remove superfluous include Update #3059.
    Comment 28
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3061 - including 'unistd.h' in C++ does not build.

    Link https://devel.rtems.org/ticket/3061
    Id 3061
    Reporter Chris Johns
    Created 5 July 2017 03:23:03
    Modified 9 November 2017 06:27:14
    Owner chrisj@…
    Type defect
    Component tool
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority highest
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Including unistd.h in a C++ program does not compile with the RSB for today:

    $ /opt/work/rtems/4.12/bin/arm-rtems4.12-g++ -B/opt/work/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib -B/opt/work/si/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib -specs bsp_specs -qrtems -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -g -O2 u.cpp
    In file included from /opt/work/rtems/4.12/arm-rtems4.12/include/sys/_pthreadtypes.h:24:0,
    from /opt/work/rtems/4.12/arm-rtems4.12/include/sys/types.h:239,
    from /opt/work/rtems/4.12/arm-rtems4.12/include/sys/unistd.h:12,
    from /opt/work/rtems/4.12/arm-rtems4.12/include/unistd.h:4,
    from u.cpp:6:
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h: In function 'void CPU_AND_S(size_t, cpu_set_t*, const cpu_set_t*, const cpu_set_t*)':
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h:147:3: error: 'BIT_AND2' was not declared in this scope
    BIT_AND2(_cpu_set_bits(setsize), destset, srcset1, srcset2);
    ^~~~~~~~
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h:147:3: note: suggested alternative: 'BIT_AND'
    BIT_AND2(_cpu_set_bits(setsize), destset, srcset1, srcset2);
    ^~~~~~~~
    BIT_AND
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h: In function 'void CPU_OR_S(size_t, cpu_set_t*, const cpu_set_t*, const cpu_set_t*)':
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h:159:3: error: 'BIT_OR2' was not declared in this scope
    BIT_OR2(_cpu_set_bits(setsize), destset, srcset1, srcset2);
    ^~~~~~~
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h:159:3: note: suggested alternative: 'BIT_OR'
    BIT_OR2(_cpu_set_bits(setsize), destset, srcset1, srcset2);
    ^~~~~~~
    BIT_OR
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h: In function 'void CPU_XOR_S(size_t, cpu_set_t*, const cpu_set_t*, const cpu_set_t*)':
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h:171:3: error: 'BIT_XOR2' was not declared in this scope
    BIT_XOR2(_cpu_set_bits(setsize), destset, srcset1, srcset2);
    ^~~~~~~~
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h:171:3: note: suggested alternative: 'BIT_OR'
    BIT_XOR2(_cpu_set_bits(setsize), destset, srcset1, srcset2);
    ^~~~~~~~
    BIT_OR
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h: In function 'void CPU_NAND_S(size_t, cpu_set_t*, const cpu_set_t*, const cpu_set_t*)':
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h:183:3: error: 'BIT_NAND2' was not declared in this scope
    BIT_NAND2(_cpu_set_bits(setsize), destset, srcset1, srcset2);
    ^~~~~~~~~
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h:183:3: note: suggested alternative: 'BIT_NAND'
    BIT_NAND2(_cpu_set_bits(setsize), destset, srcset1, srcset2);
    ^~~~~~~~~
    BIT_NAND
    In file included from /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h:46:0,
    from /opt/work/rtems/4.12/arm-rtems4.12/include/sys/_pthreadtypes.h:24,
    from /opt/work/rtems/4.12/arm-rtems4.12/include/sys/types.h:239,
    from /opt/work/rtems/4.12/arm-rtems4.12/include/sys/unistd.h:12,
    from /opt/work/rtems/4.12/arm-rtems4.12/include/unistd.h:4,
    from u.cpp:6:
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h: In function 'int CPU_COUNT_S(size_t, const cpu_set_t*)':
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h:194:10: error: '__bitcountl' was not declared in this scope
    return BIT_COUNT(_cpu_set_bits(setsize), set);
    ^
    /opt/work/rtems/4.12/arm-rtems4.12/include/sys/cpuset.h:194:10: note: suggested alternative: '__count'

    Attachments:

    1 Chris Johns, Wed, 05 Jul 2017 03:23:40 GMT
      attach: set to u.cpp
     
    Comment 1
    1. Chris Johns, Wed, 05 Jul 2017 03:24:41 GMT
    2. description: modified (diff)
    Comment 2
    1. Chris Johns, Wed, 05 Jul 2017 03:42:13 GMT

    Maybe we need a test for C++ that just includes a number of standard headers.

    Comment 3
    1. Sebastian Huber, Wed, 05 Jul 2017 11:46:37 GMT

    I guess this xilinx_zynq_zc706 installation has an installed libbsd? I removed some header files from libbsd which may in in your installation tree (e.g. you have now two bitset.h).

    Comment 4
    1. Joel Sherrill, Wed, 05 Jul 2017 11:56:05 GMT

    It may be worth it to duplicate psxhdr for C++

    Comment 5
    1. Chris Johns, Thu, 06 Jul 2017 00:08:21 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    Replying to Sebastian Huber:

    I guess this xilinx_zynq_zc706 installation has an installed libbsd? I removed some header files from libbsd which may in in your installation tree (e.g. you have now two bitset.h).

    Doh! Yes it does. Removing the installed BSP and then installing again allowed libbsd to build.

    Thanks.

    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3063 - Make the EDF scheduler the default SMP scheduler

    Link https://devel.rtems.org/ticket/3063
    Id 3063
    Reporter Sebastian Huber
    Created 6 July 2017 13:50:55
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component config
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The EDF SMP scheduler supports simple thread processor affinities (see #3059) with a small run-time overhead. The current default SMP scheduler lacks support for thread processor affinities at all. The EDF SMP scheduler offers a good feature set for most applications. So, use it by default. Run-time libraries like libgomp, MTAPI, work stealing schedulers, language interpreters (e.g. Erlang virtual machine), etc. use a one-to-one thread processor affinity for example.

    Comment 1
    1. Sebastian Huber, Mon, 10 Jul 2017 07:40:06 GMT

    In 21389c06/rtems:

    score: Make EDF the default SMP scheduler The EDF SMP scheduler supports simple thread processor affinities (see #3059) with a small run-time overhead. The current default SMP scheduler lacks support for thread processor affinities at all. The EDF SMP scheduler offers a good feature set for most applications. So, use it by default. Run-time libraries like libgomp, MTAPI, work stealing schedulers, language interpreters (e.g. Erlang virtual machine), maintainence of per-processor data (e.g. Universal Memory Allocator (UMA)), etc. use a one-to-one thread processor affinity for example. Update #3063.
    Comment 2
    1. Sebastian Huber, Mon, 10 Jul 2017 07:49:06 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 9037998/rtems-docs:

    c-user: Update scheduler/task chapter Reflect EDF SMP scheduler changes. Close #3059. Close #3063.
    Comment 3
    1. Sebastian Huber, Wed, 19 Jul 2017 10:59:42 GMT

    In 7ad8239/rtems:

    smptests/smpscheduler01: Use right scheduler Update #3063.
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:25:58 GMT
    2. component: changed from SMP to config
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3069 - Add rtems_scheduler_ident_by_processor()

    Link https://devel.rtems.org/ticket/3069
    Id 3069
    Reporter Sebastian Huber
    Created 11 July 2017 05:25:52
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    /**
    * @brief Identifies a scheduler by a processor index.
    *
    * @param[in] cpu_index The processor index.
    * @param[out] id The scheduler identifier associated with the processor index.
    *
    * @retval RTEMS_SUCCESSFUL Successful operation.
    * @retval RTEMS_INVALID_ADDRESS The @a id parameter is @c NULL.
    * @retval RTEMS_INVALID_NAME Invalid processor index.
    * @retval RTEMS_INCORRECT_STATE The processor index is valid, however, this
    * processor is not owned by a scheduler.
    */
    Comment 1
    1. Sebastian Huber, Wed, 12 Jul 2017 06:01:44 GMT

    In 548d65a/rtems:

    rtems: Add rtems_scheduler_ident_by_processor() Update #3069.
    Comment 2
    1. Sebastian Huber, Wed, 12 Jul 2017 06:29:10 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a31dbcb/rtems-docs:

    c-user: Document new scheduler ident routines Close #3069. Close #3070.
    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:24:23 GMT
    2. component: changed from SMP to rtems
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3070 - Add rtems_scheduler_ident_by_processor_set()

    Link https://devel.rtems.org/ticket/3070
    Id 3070
    Reporter Sebastian Huber
    Created 11 July 2017 08:12:52
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    /**
    * @brief Identifies a scheduler by a processor set.
    *
    * The scheduler is selected according to the highest numbered online processor
    * in the specified processor set.
    *
    * @param[in] cpusetsize Size of the specified processor set buffer in
    * bytes. This value must be positive.
    * @param[out] cpuset The processor set to identify the scheduler.
    * @param[out] id The scheduler identifier associated with the processor set.
    *
    * @retval RTEMS_SUCCESSFUL Successful operation.
    * @retval RTEMS_INVALID_ADDRESS The @a id parameter is @c NULL.
    * @retval RTEMS_INVALID_SIZE Invalid processor set size.
    * @retval RTEMS_INVALID_NAME The processor set contains no online processor.
    * @retval RTEMS_INCORRECT_STATE The processor set is valid, however, the
    * highest numbered online processor in the specified processor set is not
    * owned by a scheduler.
    */
    rtems_status_code rtems_scheduler_ident_by_processor_set(
    size_t cpusetsize,
    cpu_set_t *cpuset,
    rtems_id *id
    );
    Comment 1
    1. Sebastian Huber, Tue, 11 Jul 2017 08:21:56 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Wed, 12 Jul 2017 06:01:56 GMT

    In ecabd384/rtems:

    rtems: Add rtems_scheduler_ident_by_processor_set Update #3070.
    Comment 3
    1. Sebastian Huber, Wed, 12 Jul 2017 06:29:10 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a31dbcb/rtems-docs:

    c-user: Document new scheduler ident routines Close #3069. Close #3070.
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:24:23 GMT
    2. component: changed from SMP to rtems
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3071 - Create an interrupt server for every processor in the system

    Link https://devel.rtems.org/ticket/3071
    Id 3071
    Reporter Sebastian Huber
    Created 12 July 2017 05:46:02
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component bsps
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Create an interrupt server for every processor in the system with a one-to-one thread processor affinity. This allows load balancing for interrupt processing. Add support routines to customize the setup after initialization.

    Comment 1
    1. Sebastian Huber, Wed, 12 Jul 2017 06:02:08 GMT

    In e7ee719f/rtems:

    Create one interrupt server per processor This allows load balancing of interrupt processing in SMP configurations. Update #3071.
    Comment 2
    1. Sebastian Huber, Wed, 12 Jul 2017 06:02:20 GMT

    In a961e198/rtems:

    Add interrupt server suspend/resume This mechanism can be used to safely move the interrupt server from one scheduler instance to another for example. Update #3071.
    Comment 3
    1. Sebastian Huber, Wed, 12 Jul 2017 06:02:31 GMT

    In d184140/rtems:

    Add interrupt server set affinity Update #3071.
    Comment 4
    1. Sebastian Huber, Wed, 12 Jul 2017 06:02:43 GMT

    In ccc87c8b/rtems:

    Add interrupt server move Update #3071.
    Comment 5
    1. Sebastian Huber, Wed, 12 Jul 2017 06:02:56 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In af207fa9/rtems:

    Add interrupt vector set/get affinity Close #3071.
    Comment 6
    1. Sebastian Huber, Wed, 12 Jul 2017 08:57:38 GMT

    In e19da87/rtems:

    bsps: Include missing header file Update #3071.
    Comment 7
    1. Sebastian Huber, Wed, 19 Jul 2017 12:38:26 GMT

    In dcc3ccc/rtems:

    bsps: Fix warning Update #3071.
    Comment 8
    1. Sebastian Huber, Tue, 10 Oct 2017 06:25:19 GMT
    2. component: changed from SMP to bsps
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3072 - Declaration of global functions in driver source files

    Link https://devel.rtems.org/ticket/3072
    Id 3072
    Reporter Sebastian Huber
    Created 12 July 2017 05:54:31
    Modified 9 November 2017 06:27:14
    Owner Daniel Hellstrom
    Type defect
    Component arch/sparc
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    There are declarations of global functions in various driver source files, e.g.

    c/src/lib/libbsp/sparc/shared/drvmgr/ambapp_bus_grlib.c
    c/src/lib/libbsp/sparc/shared/drvmgr/ambapp_bus.c

    The declaration should move to a header file or a static function should be used.

    Comment 1
    1. Daniel Hellstrom, Wed, 30 Aug 2017 10:35:52 GMT

    Fixed by 8570ad2216fe796390dbe0b0e5bbdf92f02bfad2

    Comment 2
    1. Daniel Hellstrom, Wed, 30 Aug 2017 10:36:03 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:53:06 GMT
    2. component: changed from bsps to arch/sparc
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3076 - Test suite failures due to floating point usage

    Link https://devel.rtems.org/ticket/3076
    Id 3076
    Reporter Sebastian Huber
    Created 18 July 2017 11:24:53
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Several tests fail due to an unaccounted use of the floating point unit:

    BLOCK 6
    BLOCK 14
    CONSTRUCTOR/DESTRUCTOR
    CRYPT 1
    DUMPBUF 1
    FLASHDISK 1
    FSBDPART 1
    FSDOSFSFORMAT 1
    FSDOSFSNAME 1
    FSERROR DOSFS
    FSERROR JFFS2
    FSERROR MOUNTED IMFS
    FSERROR RFS
    FSERROR ROOT IMFS
    FSPERMISSION JFFS2
    FSPERMISSION MOUNTED IMFS
    FSPERMISSION RFS
    FSPERMISSION ROOT IMFS
    FSRENAME MOUNTED IMFS
    FTP 1
    libdl (RTL) 1
    libdl (RTL) 4
    libdl (RTL) 5
    MGHTTPD 1
    MONITOR 2
    MOUSE 1
    NETWORKING 1
    PSXFILE 1
    PSXIMFS 1
    PSXIMFS 2
    PSXPASSWD 2
    PSXPIPE 1
    PSXSTAT
    SMP 1
    SMP 2
    SMP 3
    SMP 8
    SMP 9
    SMPAFFINITY 1
    SMPSCHEDULER 1
    SPERROR 1
    SPERROR 2
    SPERROR 3
    SYSCALL 1
    TAR 1
    TERMIOS 3
    TERMIOS 4
    TERMIOS 5
    TERMIOS 6
    TERMIOS 7

    Comment 1
    1. Sebastian Huber, Tue, 18 Jul 2017 12:25:15 GMT

    In 08586e5/rtems:

    ftpd: Use floating point tasks Update #3076.
    Comment 2
    1. Sebastian Huber, Tue, 18 Jul 2017 12:25:28 GMT

    In 533ac112/rtems:

    tests: Use more integer print functions This avoids an unnecessary use of the floating point unit. Update #3076.
    Comment 3
    1. Sebastian Huber, Tue, 18 Jul 2017 12:25:42 GMT

    In b682f4cb/rtems:

    dumpbuf: Simplify rtems_print_buffer() This avoids an unnecessary use of the floating point unit. Update #3076.
    Comment 4
    1. Sebastian Huber, Tue, 18 Jul 2017 12:25:56 GMT

    In 07e1780/rtems:

    tests: Use floating point task These tests directly or indirectly use fprintf(), etc. which may use the floating point unit. Update #3076.
    Comment 5
    1. Sebastian Huber, Wed, 19 Jul 2017 09:57:31 GMT

    In 6f46848/rtems:

    tests: Use floating point task These tests directly or indirectly use fprintf(), etc. which may use the floating point unit. Update #3076.
    Comment 6
    1. Joel Sherrill, Wed, 19 Jul 2017 10:15:26 GMT

    Newlib has integer only versions of the printf() family. Why aren't we using these in the test to avoid this problem?

    Comment 7
    1. Sebastian Huber, Wed, 19 Jul 2017 10:55:10 GMT

    We use them in the tests, however, we don't use them in the rest of RTEMS.

    Comment 8
    1. Sebastian Huber, Wed, 19 Jul 2017 13:56:09 GMT

    In a0271a7/rtems:

    tests: Use floating point task These tests directly or indirectly use fprintf(), etc. which may use the floating point unit. Update #3076.
    Comment 9
    1. Sebastian Huber, Wed, 19 Jul 2017 13:56:21 GMT

    In 0ea7ca9/rtems:

    sptests/spcache01: Use standard test IO Update #3076.
    Comment 10
    1. Sebastian Huber, Wed, 19 Jul 2017 14:01:33 GMT

    In 5f1ae90e/rtems:

    sptests/sptls02: Use standard test IO Update #3076.
    Comment 11
    1. Sebastian Huber, Thu, 20 Jul 2017 06:28:07 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Test runs on GR740 and AT697F have no more failures due to non floating point tasks.

    Comment 12
    1. Sebastian Huber, Tue, 10 Oct 2017 06:46:55 GMT
    2. component: changed from testing to unspecified
    Comment 13
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3077 - SPARC: Add lazy floating point context switching

    Link https://devel.rtems.org/ticket/3077
    Id 3077
    Reporter Sebastian Huber
    Created 18 July 2017 12:52:02
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component arch/sparc
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The uniprocessor floating point context switching is unsafe, e.g. it is possible to silently corrupt the floating point context. The SMP floating point switching is safe, however, it doesn't use a deferred switch. Implement lazy floating point switching in uniprocessor configurations. This fixes test case spcontext01.

    Comment 1
    1. Sebastian Huber, Tue, 25 Jul 2017 09:44:32 GMT

    In b2e1bded/rtems:

    score: Add optional _CPU_Context_Destroy() Update #3077.
    Comment 2
    1. Sebastian Huber, Tue, 25 Jul 2017 09:44:44 GMT

    In a400d06f/rtems:

    sparc: Rename SPARC_USE_SAFE_FP_SUPPORT Rename SPARC_USE_SAFE_FP_SUPPORT in SPARC_USE_SYNCHRONOUS_FP_SWITCH. Update comment. Update #3077.
    Comment 3
    1. Sebastian Huber, Tue, 25 Jul 2017 09:44:55 GMT

    In 600d88d/rtems:

    INTERNAL_ERROR_ILLEGAL_USE_OF_FLOATING_POINT_UNIT Add new fatal error INTERNAL_ERROR_ILLEGAL_USE_OF_FLOATING_POINT_UNIT. Update #3077.
    Comment 4
    1. Sebastian Huber, Tue, 25 Jul 2017 09:45:08 GMT

    In 146adb1/rtems:

    sparc: Add lazy floating point switch The SPARC ABI is a bit special with respect to the floating point context. The complete floating point context is volatile. Thus, from an ABI point of view nothing needs to be saved and restored during a context switch. Instead the floating point context must be saved and restored during interrupt processing. Historically, the deferred floating point switch was used for SPARC and the complete floating point context is saved and restored during a context switch to the new floating point unit owner. This is a bit dangerous since post-switch actions (e.g. signal handlers) and context switch extensions may silently corrupt the floating point context. The floating point unit is disabled for interrupt handlers. Thus, in case an interrupt handler uses the floating point unit then this will result in a trap (INTERNAL_ERROR_ILLEGAL_USE_OF_FLOATING_POINT_UNIT). In uniprocessor configurations, a lazy floating point context switch is used. In case an active floating point thread is interrupted (PSR[EF] == 1) and a thread dispatch is carried out, then this thread is registered as the floating point owner. When a floating point owner is present during a context switch, the floating point unit is disabled for the heir thread (PSR[EF] == 0). The floating point disabled trap checks that the use of the floating point unit is allowed and saves/restores the floating point context on demand. Update #3077.
    Comment 5
    1. Sebastian Huber, Thu, 24 Aug 2017 06:31:01 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Tested using the SIS.

    Comment 6
    1. Sebastian Huber, Mon, 16 Oct 2017 06:20:09 GMT
    2. component: changed from score to arch/sparc
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3079 - Ada tests do not build

    Link https://devel.rtems.org/ticket/3079
    Id 3079
    Reporter Sebastian Huber
    Created 19 July 2017 11:32:52
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber <sebastian.huber@…>
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    A "make" in the top level build directory does not build the Ada tests (used to work some weeks ago). A "make" in ./sparc-rtems4.12/c/erc32/ada-tests for example works.

    The configuration step seems to work:

    configure: configuring in ada-tests
    configure: running /bin/sh '../../../../../rtems/c/src/ada-tests/configure' '--prefix=/home/joel/rtems-4.11-work/bsp-install' '--host=sparc-rtems4.12' '--build=x86_64-pc-linux-gnu' '--target=sparc-rtems4.12' '--enable-smp' '--disable-profiling' '--disable-multiprocessing' '--enable-rtems-debug' '--enable-cxx' '--disable-rdbg' '--enable-maintainer-mode' '--enable-tests' '--enable-networking' '--enable-posix' '--disable-itron' '--disable-deprecated' '--enable-ada' '--enable-expada' 'SIMSPARC_FAST_IDLE=1' '--with-target-subdir=sparc-rtems4.12' '--exec-prefix=/home/joel/rtems-4.11-work/bsp-install/sparc-rtems4.12' '--includedir=/home/joel/rtems-4.11-work/bsp-install/sparc-rtems4.12/include' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=sparc-rtems4.12' 'target_alias=sparc-rtems4.12' '--with-project-root=../../' '--with-project-top=../../' 'RTEMS_BSP=erc32' 'RTEMS_CPU_MODEL=erc32' 'RTEMS_BSP_FAMILY=erc32' 'CFLAGS=-mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs' '--enable-rtems-root=../' '--enable-project-root=../../../erc32' '--with-project-top=../../../' '--enable-rtemsbsp=erc32' --cache-file=/dev/null --srcdir=../../../../../rtems/c/src/ada-tests
    configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
    checking for gmake... gmake

    However:

    gmake[4]: Entering directory '/scratch/git-rtems-testing/rtems/build-sparc-erc32-rtems/sparc-rtems4.12/c/erc32/ada-tests'
    gmake[4]: Nothing to be done for 'all-am'.
    Comment 1
    1. Joel Sherrill, Thu, 12 Oct 2017 00:18:40 GMT
    2. owner: changed from chrisj@… to Sebastian Huber
    3. status: changed from new to assigned
    4. milestone: changed from 4.12.0 to 4.10.3

    Is this fixed now?

    Comment 2
    1. Sebastian Huber, Thu, 12 Oct 2017 05:29:11 GMT
    2. owner: changed from Sebastian Huber to Chris Johns
    3. milestone: changed from 4.10.3 to 4.12.0

    This is a 4.12 problem and related to recent changes in the build system.

    Comment 3
    1. Chris Johns, Thu, 12 Oct 2017 05:39:24 GMT
    2. owner: Chris Johns deleted
    3. status: changed from assigned to new

    No point assigning this to me, I do not have an Ada compiler and when I last looked it did not build easily on my hosts. I have no ability to test any of this.

    I suggest you change SUBDIRS to _SUBDIRS and see what happens. SUBDIRS is owned by automake and our build system circumvented automake long ago.

    Comment 4
    1. Sebastian Huber, Thu, 12 Oct 2017 08:52:56 GMT

    Thanks, this _SUBDIR hint was what I needed.

    Comment 5
    1. Sebastian Huber, Thu, 12 Oct 2017 08:55:52 GMT

    In b3874e1/rtems:

    ada-tests: Use _SUBDIRS instead of SUBDIRS Update #3079.
    Comment 6
    1. Sebastian Huber, Thu, 12 Oct 2017 08:56:07 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In ee537ea/rtems:

    ada-tests: Move to testsuites/ada This solves a build dependency issue, e.g. building tests before librtemsbsp.a exists. Close #3079.
    Comment 7
    1. Chris Johns, Thu, 12 Oct 2017 15:53:17 GMT

    Replying to Sebastian Huber:

    Thanks, this _SUBDIR hint was what I needed.

    Awesome change. Thank you.

    Comment 8
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3080 - Infinite loop in SPARC rtems_invalidate_multiple_instruction_lines()

    Link https://devel.rtems.org/ticket/3080
    Id 3080
    Reporter Sebastian Huber
    Created 19 July 2017 13:54:07
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component arch/sparc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    A

    #define CPU_INSTRUCTION_CACHE_ALIGNMENT 0

    is not a good idea in case the default range functions are used.

    Comment 1
    1. Sebastian Huber, Wed, 19 Jul 2017 13:56:33 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 7ed8ad0/rtems:

    bsps/sparc: Fix cache support Fix infinite loop in rtems_invalidate_multiple_instruction_lines(). Implement this function. Close #3080.
    Comment 2
    1. Sebastian Huber, Tue, 10 Oct 2017 06:53:06 GMT
    2. component: changed from bsps to arch/sparc
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3082 - Add 64-bit support for PowerPC

    Link https://devel.rtems.org/ticket/3082
    Id 3082
    Reporter Sebastian Huber
    Created 24 July 2017 07:15:45
    Modified 25 January 2019 14:40:29
    Owner Sebastian Huber
    Type enhancement
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The QorIQ chips have more than 4GiB of memory available.

    Comment 1
    1. Sebastian Huber, Fri, 28 Jul 2017 08:25:37 GMT

    GCC support will be available with GCC 7.2:

    ​https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=250654

    Comment 2
    1. Sebastian Huber, Fri, 28 Jul 2017 08:49:28 GMT

    In b615e9b/rtems:

    bsp/qoriq: Simplify initialization Do not flush/invalidate the caches. Instead enable the cache during the low-level initialization and perform an explicit cache flush for the read-only and fast-text sections. Update #3082. Update #3085.
    Comment 3
    1. Sebastian Huber, Fri, 28 Jul 2017 08:49:42 GMT

    In 0db7c55/rtems:

    bsp/qoriq: New BSP names Due to the FDT support we can now reduce the BSP variants. Use the processor core to define the BSP variants. Update #3082. Update #3085.
    Comment 4
    1. Sebastian Huber, Fri, 28 Jul 2017 11:45:15 GMT

    In 1ceafe5/rtems-source-builder:

    4.12: Update to Binutils 2.29 Update #3082.
    Comment 5
    1. Sebastian Huber, Fri, 28 Jul 2017 13:40:58 GMT

    In 8966e8a/rtems:

    bsp/qoriq: Fix pre-processor expansion Update #3082. Update #3085.
    Comment 6
    1. Sebastian Huber, Mon, 31 Jul 2017 12:46:02 GMT

    In a597984/rtems:

    powerpc: Add register defines Update #3082. Update #3085.
    Comment 7
    1. Sebastian Huber, Mon, 31 Jul 2017 12:46:18 GMT

    In 65ee42c/rtems:

    bsp/qoriq: Simplify fatal exceptions Avoid use of small-data area, since it is not supported in the ELFv2 ABI by GCC. Update #3082.
    Comment 8
    1. Sebastian Huber, Mon, 31 Jul 2017 12:46:33 GMT

    In b7be9439/rtems:

    bsps/powerpc: Do not set ouput format and arch There is no need to explicitly set the output format and architecture in the linker script. This enables the usage of this linker script with the ELFv2 ABI (64-bit). Update #3082.
    Comment 9
    1. Sebastian Huber, Tue, 01 Aug 2017 09:45:58 GMT

    In 23cb9af/rtems:

    bsps/powerpc: Rename ppc_exc_wrap_async_normal Rename ppc_exc_wrap_async_normal to ppc_exc_interrupt to avoid a bit of obfuscation. Update #3082.
    Comment 10
    1. Sebastian Huber, Tue, 01 Aug 2017 09:46:11 GMT

    In a8694035/rtems:

    bsps/powerpc: Add PPC_EXC_INTERRUPT_FRAME_SIZE Use a specific define for the interrupt exception frame size. Update #3082.
    Comment 11
    1. Sebastian Huber, Tue, 22 Aug 2017 14:49:44 GMT

    In 7e3ff84/rtems-source-builder:

    4.12: Fix 64-bit PowerPC support of GCC 7.2 Update #3082.
    Comment 12
    1. Sebastian Huber, Tue, 22 Aug 2017 14:51:08 GMT

    In 279c540/rtems:

    score: Fix format specifier Update #3082.
    Comment 13
    1. Sebastian Huber, Tue, 22 Aug 2017 14:51:20 GMT

    In e062741d/rtems:

    dev/i2c: Fix integer type Update #3082.
    Comment 14
    1. Sebastian Huber, Tue, 22 Aug 2017 14:51:32 GMT

    In 93934f88/rtems:

    heap: Fix integer types Update #3082.
    Comment 15
    1. Sebastian Huber, Tue, 22 Aug 2017 14:51:44 GMT

    In a8f4fd2/rtems:

    smptests: Fix format specifier Update #3082.
    Comment 16
    1. Sebastian Huber, Tue, 22 Aug 2017 14:51:57 GMT

    In b98e407/rtems:

    libchip/ata: Fix integer to/from pointer Update #3082.
    Comment 17
    1. Sebastian Huber, Tue, 22 Aug 2017 14:52:10 GMT

    In 5e1a831/rtems:

    libchip/serial: Fix integer types Update #3082.
    Comment 18
    1. Sebastian Huber, Tue, 22 Aug 2017 14:52:22 GMT

    In caa12270/rtems:

    powerpc: Add register defines Update #3082.
    Comment 19
    1. Sebastian Huber, Tue, 22 Aug 2017 14:52:35 GMT

    In ea9084de/rtems:

    powerpc: ppc_interrupt_get_disable_mask() Fix warning on 64-bit PowerPC. Update #3082.
    Comment 20
    1. Sebastian Huber, Tue, 22 Aug 2017 14:52:47 GMT

    In 5a9372f/rtems:

    powerpc: 64-bit support for CPU_SIZEOF_POINTER Update #3082.
    Comment 21
    1. Sebastian Huber, Tue, 22 Aug 2017 14:52:59 GMT

    In 7837728b/rtems:

    powerpc: 64-bit _CPU_Context_Initialize() support Update #3082.
    Comment 22
    1. Sebastian Huber, Tue, 22 Aug 2017 14:53:11 GMT

    In a6f84b27/rtems:

    powerpc: Add 64-bit context/interrupt support Update #3082.
    Comment 23
    1. Sebastian Huber, Tue, 22 Aug 2017 14:53:24 GMT

    In ec25c6ef/rtems:

    bsps: Fix integer to/from pointer Update #3082.
    Comment 24
    1. Sebastian Huber, Tue, 22 Aug 2017 14:53:48 GMT

    In 241d2f2/rtems:

    bsps: Fix integer types in bsp_fdt_copy() Update #3082.
    Comment 25
    1. Sebastian Huber, Tue, 22 Aug 2017 14:54:00 GMT

    In 60d077f/rtems:

    bsps/powerpc: Add 64-bit linker sections Update #3082.
    Comment 26
    1. Sebastian Huber, Tue, 22 Aug 2017 14:54:12 GMT

    In 50382788/rtems:

    bsps/powerpc: Add 64-bit SET_SELF_CPU_CONTROL Update #3082.
    Comment 27
    1. Sebastian Huber, Tue, 22 Aug 2017 14:54:25 GMT

    In d50124d/rtems:

    bsps/powerpc: Rename ppc_exc_wrap_async_normal_end Rename ppc_exc_wrap_async_normal_end to ppc_exc_interrupt_end to avoid a bit of obfuscation. Update #3082.
    Comment 28
    1. Sebastian Huber, Tue, 22 Aug 2017 14:54:37 GMT

    In 0e26c19a/rtems:

    bsps/powerpc: Add 64-bit CRT init/fini support Update #3082.
    Comment 29
    1. Sebastian Huber, Tue, 22 Aug 2017 14:54:50 GMT

    In c6994af/rtems:

    bsp/qoriq: Use LA to load an address Add 64-bit support for LA. Update #3082.
    Comment 30
    1. Sebastian Huber, Tue, 22 Aug 2017 14:55:03 GMT

    In 43cc2b4/rtems:

    bsp/qoriq: Add basic 64-bit support Update #3082.
    Comment 31
    1. Sebastian Huber, Tue, 22 Aug 2017 14:55:15 GMT

    In 0ae1916b/rtems:

    bsp/qoriq: Copy FDT later We need a ready to use TOC section before we can call bsp_fdt_copy(). Update #3082.
    Comment 32
    1. Sebastian Huber, Tue, 22 Aug 2017 14:55:27 GMT

    In f14da45/rtems:

    bsp/qoriq: 64-bit support for spin table Update #3082.
    Comment 33
    1. Sebastian Huber, Tue, 22 Aug 2017 14:55:40 GMT

    In 5f42a0e/rtems:

    bsp/qoriq: Enable 64-bit mode for exceptions Update #3082.
    Comment 34
    1. Sebastian Huber, Tue, 22 Aug 2017 14:55:52 GMT

    In 77c81016/rtems:

    bsp/qoriq: 64-bit support for interrupt controller Update #3082.
    Comment 35
    1. Sebastian Huber, Tue, 22 Aug 2017 14:56:04 GMT

    In c8aeb76/rtems:

    bsp/qoriq: 64-bit MMU support Update #3082.
    Comment 36
    1. Sebastian Huber, Tue, 22 Aug 2017 14:56:16 GMT

    In c693a3a/rtems:

    powerpc: PPC64_NOP_FOR_LINKER_TOC_POINTER_RESTORE In 64-bit mode, the linker must have the ability to restore the TOC pointer after an external function call. Update #3082.
    Comment 37
    1. Sebastian Huber, Tue, 22 Aug 2017 14:56:29 GMT

    In 95a4b1f/rtems:

    bsp/qoriq: Enable > 2GiB memory Update #3082.
    Comment 38
    1. Sebastian Huber, Tue, 22 Aug 2017 14:56:41 GMT

    In 695c9c50/rtems:

    bsp/qoriq: Add qoriq_e6500_64 variant Update #3082.
    Comment 39
    1. Sebastian Huber, Tue, 22 Aug 2017 14:59:45 GMT

    In fd0bcc5/rtems-tools:

    tester: Add qoriq_e6500_64 Update #3082.
    Comment 40
    1. Sebastian Huber, Tue, 22 Aug 2017 15:02:20 GMT
    2. status: changed from assigned to accepted
    3. milestone: changed from Indefinite to 4.12.0
    Comment 41
    1. Sebastian Huber, Wed, 23 Aug 2017 07:26:19 GMT

    In b6977f7/rtems-docs:

    cpu-supplement/powerpc: Rewrite Remove obsolete and duplicated information. Reference the ABI specifications. Add 64-bit caveats. Update #3082.
    Comment 42
    1. Sebastian Huber, Wed, 23 Aug 2017 09:04:37 GMT

    In 34ff390/rtems-libbsd:

    BUS_SPACE(9): 64-bit support Update #3082.
    Comment 43
    1. Sebastian Huber, Thu, 24 Aug 2017 06:11:40 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    Works on a T4240 with network stack.

    Comment 44
    1. Sebastian Huber, Thu, 24 Aug 2017 13:55:28 GMT

    In 873ba80/rtems-docs:

    cpu-supplement: Fix PowerPC TOC limitation Update #3082.
    Comment 45
    1. Sebastian Huber, Fri, 25 Aug 2017 08:36:10 GMT

    In 3fdea2d/rtems-docs:

    cpu-supplement: Use literal instead of emphasis Update #3082.
    Comment 46
    1. Sebastian Huber, Thu, 28 Sep 2017 11:22:22 GMT

    In 910adc3/rtems:

    bsps: Fix integer to/from pointer warnings Update #3082.
    Comment 47
    1. Sebastian Huber, Mon, 16 Oct 2017 06:19:48 GMT
    2. component: changed from score to arch/powerpc
    Comment 48
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 49
    1. Sebastian Huber, Fri, 24 Nov 2017 14:13:31 GMT

    In 2e7c3f6/rtems:

    sptests/splinkersets01: Fix 64-bit targets Update #3082.
    Comment 50
    1. Sebastian Huber, Fri, 24 Nov 2017 14:19:07 GMT

    In 54e7b81/rtems:

    libtests/stringto01: Fix 64-bit targets Update #3082.
    Comment 51
    1. Sebastian Huber, Fri, 24 Nov 2017 14:27:25 GMT

    In 57f96b9/rtems:

    libtests/malloctest: Fix 64-bit targets Update #3082.
    Comment 52
    1. Sebastian Huber, Mon, 22 Jan 2018 14:24:50 GMT

    In 5fb838d/rtems:

    rfs: Fix for 64-bit targets The RTEMS_BLKIO_SETBLKSIZE IO control expects an uint32_t parameter and not a size_t which is 64-bits on 64-bit targets. Update #3082.
    Comment 53
    1. Sebastian Huber, Tue, 23 Jan 2018 07:00:46 GMT

    In 6bb9b3df/rtems:

    rfs: Fix format warning Update #3082.
    Comment 54
    1. Sebastian Huber, Mon, 29 Jan 2018 05:59:40 GMT

    In bc96f3b4/rtems:

    ada: Introduce RTEMS.Size type Some time ago the Classic API object size related parameters were changed to use size_t. Reflect this in the Ada bindings. Update #3082.
    Comment 55
    1. Sebastian Huber, Fri, 02 Feb 2018 14:20:01 GMT

    In c1c71cd/rtems:

    sp20: Fix print buffer size There were two issues: The buffer size must be divisible by 8 on 64-bit targets It must be large enough to service the begin of start message. Update #3082.
    Comment 56
    1. Sebastian Huber, Fri, 02 Feb 2018 14:20:13 GMT

    In d71d1da/rtems:

    spsyslock01: Fix object compare Due to structure internal padding the use of memcmp() may lead to sporadic test failures. Update #3082.
    Comment 57
    1. Sebastian Huber, Fri, 25 Jan 2019 14:40:29 GMT

    In 81aec18/rtems:

    bsps/powerpc: Fix 64-bit issues in assembler files We have to be careful with instructions which operate explicitly on words or doublewords. Update #3082.

    3083 - parallel make not working

    Link https://devel.rtems.org/ticket/3083
    Id 3083
    Reporter Joel Sherrill
    Created 27 July 2017 23:08:33
    Modified 9 April 2018 23:11:56
    Owner Chris Johns
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    As reported on the mailing list, parallel make on the master is broken.

    Attachments:

    1 Chris Johns, Thu, 16 Nov 2017 22:02:27 GMT
      attach: set to 0001-build-Provide-system-level-locking-so-only-one-insta.patch
     
    Comment 1
    1. Joel Sherrill, Thu, 27 Jul 2017 23:08:43 GMT
    2. owner: changed from chrisj@… to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Chris Johns, Mon, 07 Aug 2017 23:35:51 GMT
    2. priority: changed from normal to highest
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 4
    1. Chris Johns, Mon, 13 Nov 2017 23:40:38 GMT

    The list email referenced is ​https://lists.rtems.org/pipermail/devel/2017-July/018513.html

    Comment 5
    1. Chris Johns, Tue, 14 Nov 2017 01:56:02 GMT

    I wonder if this is due to different directories installing the same files at different levels in the build system and this has exposed something present in the build systems. We could see calls for install happening at the same time on the same file and I wonder if the Linux install executable is doing some checking that exposes this issue.

    Comment 6
    1. Chris Johns, Thu, 16 Nov 2017 22:09:52 GMT

    Note, make install is broken. I will look at that if this fixes the build issue.

    Comment 7
    1. Chris Johns, Mon, 09 Apr 2018 22:52:54 GMT
    Comment 8
    1. Chris Johns, Mon, 09 Apr 2018 23:11:56 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    This has been fixed with the switch to real parallel building of sub-directories, the removal of pre-installed header files, and now the testsuite has been refactored to use one nested make call per test group.

    See:

    2afb22b7/rtems 900c4073/rtems

    3084 - Makefile recipe override warning has returned

    Link https://devel.rtems.org/ticket/3084
    Id 3084
    Reporter Joel Sherrill
    Created 27 July 2017 23:14:42
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The makefile overrides recipe warnings had disappeared with Chris' rework to improve parallelism. Unfortunately, one Makefile has had the warning return. To reproduce, complete a build with all tests enabled, then just type make >/dev/null at the top of the build tree

    [joel@rtbf64c rtems-work]$ ./build_bsp sparc erc32
    Using rtems for RTEMS source

    real 5m4.247s
    user 5m58.188s
    sys 1m34.959s
    0
    [joel@rtbf64c rtems-work]$ cd b-erc32/
    [joel@rtbf64c b-erc32]$ make >/dev/null
    Makefile:653: warning: overriding recipe for target `spprofiling01'
    Makefile:653: warning: ignoring old recipe for target `spprofiling01'

    Comment 1
    1. Joel Sherrill, Thu, 27 Jul 2017 23:14:53 GMT
    2. owner: changed from chrisj@… to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Thu, 12 Oct 2017 01:19:16 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 871c23c/rtems:

    Fix spprofiling01 overriding recipe warning Closes #3084.
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3085 - Add hypervisor support for QorIQ BSPs

    Link https://devel.rtems.org/ticket/3085
    Id 3085
    Reporter Sebastian Huber
    Created 28 July 2017 08:08:56
    Modified 20 March 2018 06:42:19
    Owner Sebastian Huber
    Type enhancement
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    NXP provides a hypervisor (Topaz) for the QorIQ platform.

    ​https://www.xes-inc.com/wp-content/uploads/2016/03/NXP-Embedded-Hypervisor-for-QorIQ-Overview.pdf

    Comment 1
    1. Sebastian Huber, Fri, 28 Jul 2017 08:49:28 GMT

    In b615e9b/rtems:

    bsp/qoriq: Simplify initialization Do not flush/invalidate the caches. Instead enable the cache during the low-level initialization and perform an explicit cache flush for the read-only and fast-text sections. Update #3082. Update #3085.
    Comment 2
    1. Sebastian Huber, Fri, 28 Jul 2017 08:49:42 GMT

    In 0db7c55/rtems:

    bsp/qoriq: New BSP names Due to the FDT support we can now reduce the BSP variants. Use the processor core to define the BSP variants. Update #3082. Update #3085.
    Comment 3
    1. Sebastian Huber, Fri, 28 Jul 2017 13:40:58 GMT

    In 8966e8a/rtems:

    bsp/qoriq: Fix pre-processor expansion Update #3082. Update #3085.
    Comment 4
    1. Sebastian Huber, Mon, 31 Jul 2017 12:46:02 GMT

    In a597984/rtems:

    powerpc: Add register defines Update #3082. Update #3085.
    Comment 5
    1. Sebastian Huber, Tue, 12 Sep 2017 08:01:28 GMT

    In 458179f1/rtems:

    bsp/qoriq: Remove console stuff from bsp_start() Update #3085.
    Comment 6
    1. Sebastian Huber, Tue, 12 Sep 2017 08:01:41 GMT

    In 20fc4f9/rtems:

    bsp/qoriq: Add QORIQ_IS_HYPERVISOR_GUEST Update #3085.
    Comment 7
    1. Sebastian Huber, Tue, 12 Sep 2017 08:01:53 GMT

    In 0ce5bfb/rtems:

    bsp/qoriq: Do not touch MMU as hypervisor guest Update #3085.
    Comment 8
    1. Sebastian Huber, Tue, 12 Sep 2017 08:02:05 GMT

    In b742de2/rtems:

    bsp/qoriq: Boot page translation Do not mingle with the boot page translation as hypervisor guest. Update #3085.
    Comment 9
    1. Sebastian Huber, Tue, 12 Sep 2017 08:02:17 GMT

    In 0d51c05/rtems:

    bsp/qoriq: Import ePAPR hcalls from Linux 4.12 Update #3085.
    Comment 10
    1. Sebastian Huber, Tue, 12 Sep 2017 08:02:30 GMT

    In 356b1b85/rtems:

    bsp/qoriq: Port ePAPR hcall interface to RTEMS Update #3085.
    Comment 11
    1. Sebastian Huber, Tue, 12 Sep 2017 08:02:42 GMT

    In 134fe56/rtems:

    bsp/qoriq: Add byte channel console driver Update #3085.
    Comment 12
    1. Sebastian Huber, Tue, 12 Sep 2017 08:02:54 GMT

    In df62e51/rtems:

    bsp/qoriq: Virtual interrupt controller support Update #3085.
    Comment 13
    1. Sebastian Huber, Tue, 19 Sep 2017 12:36:04 GMT

    In 599e6fbd/rtems:

    bsps/powerpc: PPC_EXC_CONFIG_USE_FIXED_HANDLER Make PPC_EXC_CONFIG_USE_FIXED_HANDLER mandatory for BSPs using ppc_exc_interrupt(). Pass exception number to bsp_interrupt_dispatch() to allow processing of decrementer and doorbell exceptions as hypervisor guest. Update #3085.
    Comment 14
    1. Sebastian Huber, Tue, 19 Sep 2017 12:36:17 GMT

    In fd70e206/rtems:

    bsp/qoriq: Add early debug output initialization Update #3085.
    Comment 15
    1. Sebastian Huber, Tue, 19 Sep 2017 12:36:29 GMT

    In ec28f31/rtems:

    bsp/qoriq: Add decrementer clock driver Update #3085.
    Comment 16
    1. Sebastian Huber, Tue, 19 Sep 2017 12:36:41 GMT

    In 44c0114/rtems:

    bsp/qoriq: Reduce static memory demands Update #3085.
    Comment 17
    1. Sebastian Huber, Tue, 19 Sep 2017 12:36:52 GMT

    In 6600882b/rtems:

    bsp/qoriq: Avoid MAS8 access as hypervisor guest Update #3085.
    Comment 18
    1. Sebastian Huber, Tue, 19 Sep 2017 12:37:04 GMT

    In 2720fbf0/rtems:

    bsp/qoriq: Avoid IVOR38..42 access as hv guest Update #3085.
    Comment 19
    1. Sebastian Huber, Tue, 19 Sep 2017 12:37:15 GMT

    In 31540bf/rtems:

    bsp/qoriq: MMU configuration as hypervisor guest Re-enable MMU configuration as hypervisor guest. Make sure the QORIQ_TLB1_ENTRY_COUNT is set according to the hypervisor configuration. Update #3085.
    Comment 20
    1. Sebastian Huber, Tue, 19 Sep 2017 12:37:27 GMT

    In f100a58/rtems:

    bsp/qoriq: Add hypervisor guest SMP support Update #3085.
    Comment 21
    1. Sebastian Huber, Tue, 19 Sep 2017 12:42:12 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 4c1f442/rtems:

    bsp/qoriq: Update README Close #3085.
    Comment 22
    1. Sebastian Huber, Tue, 19 Sep 2017 12:42:33 GMT
    2. version: set to 4.12
    3. milestone: changed from Indefinite to 4.12.0
    Comment 23
    1. Sebastian Huber, Wed, 20 Sep 2017 07:35:46 GMT

    In d7ed684/rtems:

    bsps/powerpc: Fix PPC_EXC_CONFIG_USE_FIXED_HANDLER Fix link-time error on BSPs not using PPC_EXC_CONFIG_USE_FIXED_HANDLER. Update #3085.
    Comment 24
    1. Sebastian Huber, Thu, 21 Sep 2017 11:33:28 GMT

    In b800f88/rtems:

    bsp/t32mppc: PPC_EXC_CONFIG_USE_FIXED_HANDLER Fix link-time error. Update #3085.
    Comment 25
    1. Sebastian Huber, Tue, 10 Oct 2017 06:56:19 GMT
    2. component: changed from bsps to arch/powerpc
    Comment 26
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 27
    1. Sebastian Huber, Mon, 20 Nov 2017 07:51:01 GMT

    In 5018894e/rtems:

    bsps/powerpc: Fix PPC_EXC_CONFIG_USE_FIXED_HANDLER For the SPE support we must store the upper half of r3 as well. Update #3085.
    Comment 28
    1. Sebastian Huber, Mon, 22 Jan 2018 09:38:44 GMT

    In 5ce2dfa/rtems:

    powerpc: Add FSL_EIS_EPR Update #3085.
    Comment 29
    1. Sebastian Huber, Mon, 22 Jan 2018 09:38:55 GMT

    In 9ec5ff4e/rtems:

    bsp/qoriq: Fix hypervisor guest MMU config Account for DPAA resources defined in the device tree. Prevent merging of areas with incompatible MAS2. Update #3085.
    Comment 30
    1. Sebastian Huber, Mon, 22 Jan 2018 09:39:07 GMT

    In 81eced53/rtems:

    bsp/qoriq: Fix bsp_fdt_map_intr() Update #3085.
    Comment 31
    1. Sebastian Huber, Mon, 22 Jan 2018 09:39:18 GMT

    In 2f54488f/rtems:

    bsp/qoriq: Fix hypervisor guest IRQ support Update #3085.
    Comment 32
    1. Sebastian Huber, Mon, 22 Jan 2018 09:39:30 GMT

    In 44ba969/rtems:

    bsp/qoriq: Fix hypervisor guest polled console Update #3085.
    Comment 33
    1. Sebastian Huber, Mon, 22 Jan 2018 09:39:42 GMT

    In 0df59b7c/rtems:

    bsp/qoriq: Optional multiprocessing support Update #3085.
    Comment 34
    1. Sebastian Huber, Mon, 22 Jan 2018 09:39:53 GMT

    In 2fd684e/rtems:

    bsp/qoriq: Fix hypervisor guest irq vector max Update #3085.
    Comment 35
    1. Sebastian Huber, Mon, 22 Jan 2018 09:40:05 GMT

    In b391fbc6/rtems:

    bsp/qoriq: Fix hypervisor guest interrupt init Update #3085.
    Comment 36
    1. Sebastian Huber, Tue, 23 Jan 2018 06:30:46 GMT

    In 469fdeb/rtems:

    bsp/qoriq: Fix define for optional intercom Update #3085.
    Comment 37
    1. Sebastian Huber, Tue, 20 Mar 2018 06:42:19 GMT

    In 5d44981c/rtems:

    bsp/qoriq: Fix bsp_restart() Update #3085.

    3087 - RSB rtems-gdb-7.12-1.cfg MD5 value is ERROR

    Link https://devel.rtems.org/ticket/3087
    Id 3087
    Reporter likangbei
    Created 2 August 2017 01:41:36
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords rsb MD5
    Cc  
    Blocking  
    Blocked by  

    Description

    rtems-source-builder\rtems\config\tools\rtems-gdb-7.12-1.cfg
    line 16:%hash md5 gdb-7.12-sis-leon2-leon3.diff "fe29e7daaab3bf70c99cda6925d8c0c5" is error
    "40670e05b7fc3868a405fb43138f3262" is right

    TEST on WIN7+MSYS2

    My English is bad! Sorry

    Comment 1
    1. Chris Johns, Mon, 14 Aug 2017 00:59:54 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    4. milestone: set to 4.12.0
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3088 - shell test in testsuites\samples\fileio many COMMANDs is Lost

    Link https://devel.rtems.org/ticket/3088
    Id 3088
    Reporter likangbei
    Created 2 August 2017 02:01:06
    Modified 9 November 2017 06:27:14
    Owner chrisj@…
    Type defect
    Component shell
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords shell COMMAND Lost
    Cc  
    Blocking  
    Blocked by  

    Description

    testsuites\samples\fileio test on atsam BSP,
    init.c:
    #define CONFIGURE_SHELL_COMMANDS_INIT
    #define CONFIGURE_SHELL_COMMANDS_ALL

    but when press s -> start shell,I only find three COMMANDs(help,alias,time),Other COMMANDs is Lost。
    I remember that the previous version was normal。

    Sorry! My English is bad!

    Comment 1
    1. Joel Sherrill, Thu, 03 Aug 2017 03:19:22 GMT

    The set of available commands depends on what user you login as. Try root for more commands.

    Comment 2
    1. Chris Johns, Mon, 14 Aug 2017 00:58:35 GMT
    2. milestone: set to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 24 Aug 2017 06:44:47 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 80a13ec4/rtems:

    samples/fileio: Give command availability hint Close #3088.
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3089 - Inconsistent blocking addressing in RFS

    Link https://devel.rtems.org/ticket/3089
    Id 3089
    Reporter Fan Deng
    Created 3 August 2017 04:22:04
    Modified 11 April 2018 01:57:45
    Owner Fan Deng
    Type defect
    Component fs
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc Chris Johns
    Blocking  
    Blocked by  

    Description

    __Background__ There are two ways to address a block in RFS:

  • Via a single 32bit block number (bno)
  • Via a group number(gno) and a bit offset (bit)
  • They should be fully convertible (1-1 mapping). In other words, the equation to convert 1 to 2 should be unique within the RFS implementation.

    __The bug__ The RFS implementation contains two different conversions between 1 and 2.

    __Details__

  • In rtems_rfs_group_bitmap_alloc (rtems-rfs-group.c, line 172)
    bno = gno * group_blocks + bit 
  • In rtems_rfs_group_bitmap_alloc (rtems-rfs-group.c, line 228)
    bno = gno * group_blocks + bit + 1 (via rtems_rfs_group_block() function) 
  • In rtems_rfs_group_bitmap_free (rtems-rfs-group.c, line 283)
    bno = gno * group_blocks + bit + 1 (RTEMS_RFS_SUPERBLOCK_SIZE) 
  • In rtems_rfs_group_bitmap_test (rtems-rfs-group.c, line 332)
    bno = gno * group_blocks + bit 
  • To summarize, the implementation contains two ways of converting a bno to a (gno, bit) pair:

    Either:

    bno = gno * group_blocks + bit 

    Or:

    bno = gno * group_blocks + bit + 1 

    __The Fix__ The RFS implementation should consistently convert a bno to a (gno, bit) pair with:

    bno = gno * group_blocks + bit + RTEMS_RFS_SUPERBLOCK_SIZE 

    This is because the superblock is not accounted for in the block bitmaps. So places to change:

  • rtems-rfs-group.c: all references to the conversion must be updated to use RTEMS_RFS_SUPERBLOCK_SIZE explicitly.
  • rtems_rfs_group_block converts the pair to bno via:
    #define rtems_rfs_group_block(_g, _b) (((_g)->base) + (_b)) 
  • (_g)->base is calculated via rtems-rfs-format.c from:

    #define rtems_rfs_fs_block(_fs, _grp, _blk) \
    ((((_fs)->group_blocks) * (_grp)) + (_blk) + 1)

    The "+ 1" part should really be "+ RTEMS_RFS_SUPERBLOCK_SIZE" to be logically correct. As RTEMS_RFS_SUPERBLOCK_SIZE itself has a comment saying:

    /**
    * Number of blocks in the superblock. Yes I know it is a superblock and not
    * superblocks but if for any reason this needs to change it is handled.
    */
    #define RTEMS_RFS_SUPERBLOCK_SIZE (1)
    Comment 1
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 2
    1. Chris Johns, Wed, 11 Apr 2018 01:57:45 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 9e8df1fe/rtems:

    fstest/fsrfsbitmap01: Update RFS bitmap tests to test fixes. Add tests to check the patches for this ticket exist and are fixed. Close #3089

    3090 - Add BSP for i.MX 7

    Link https://devel.rtems.org/ticket/3090
    Id 3090
    Reporter Sebastian Huber
    Created 4 August 2017 11:49:50
    Modified 8 February 2018 09:01:00
    Owner Sebastian Huber
    Type enhancement
    Component bsps
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Fri, 04 Aug 2017 12:25:39 GMT

    In ef04443/rtems:

    bsps/arm: Add ARMv7-AR Generic Timer support Update #3090.
    Comment 2
    1. Sebastian Huber, Fri, 04 Aug 2017 12:25:51 GMT

    In ffe7c0e/rtems:

    bsps/arm: Add ARMv7-AR Generic Timer clock driver Update #3090.
    Comment 3
    1. Sebastian Huber, Fri, 04 Aug 2017 12:26:04 GMT

    In 694c31f9/rtems:

    bsp/imx: New BSP Update #3090.
    Comment 4
    1. Sebastian Huber, Fri, 04 Aug 2017 12:47:03 GMT

    In ca9490c/rtems:

    bsp/imx: Fix UART interrupt Update #3090.
    Comment 5
    1. Chris Johns, Sat, 05 Aug 2017 23:55:35 GMT

    Can the rtems-tool's bsp-builder configuration files please be updated to include this BSP:

    ​https://git.rtems.org/rtems-tools/tree/tester/rtems/rtems-bsps-arm.ini

    Thanks

    Comment 6
    1. Sebastian Huber, Fri, 22 Sep 2017 12:25:09 GMT

    In 8e6a407a/rtems:

    bsps/arm: Copy FDT only on boot processor Update #3090.
    Comment 7
    1. Sebastian Huber, Fri, 22 Sep 2017 12:25:20 GMT

    In 3ad3849a/rtems:

    bsp/imx: Add register headers Update #3090.
    Comment 8
    1. Sebastian Huber, Fri, 22 Sep 2017 12:25:32 GMT

    In 29919242/rtems:

    bsp/imx: Add SMP support Update #3090.
    Comment 9
    1. Sebastian Huber, Fri, 22 Sep 2017 12:40:45 GMT

    In 05f9858f/rtems:

    bsps: Generalize bsp_fdt_map_intr() Pass all interrupt cells to bsp_fdt_map_intr() since some platforms use an array to describe an interrupt. Update #3090.
    Comment 10
    1. Sebastian Huber, Fri, 22 Sep 2017 12:43:09 GMT

    In b469163/rtems-libbsd:

    Generalize bsp_fdt_map_intr() Update #3090.
    Comment 11
    1. Sebastian Huber, Tue, 26 Sep 2017 05:32:21 GMT

    In 4bf2ce31/rtems:

    bsp/imx: Add register headers Update #3090.
    Comment 12
    1. Sebastian Huber, Tue, 26 Sep 2017 12:02:03 GMT

    In 362e96ab/rtems:

    bsp/imx: Provide a default console Update #3090.
    Comment 13
    1. Sebastian Huber, Wed, 27 Sep 2017 08:59:47 GMT

    In 5616983/rtems:

    bsp/imx: Add nocache section Update #3090.
    Comment 14
    1. Sebastian Huber, Wed, 27 Sep 2017 12:56:17 GMT

    In 87e1929/rtems-docs:

    Mention i.MX 7 SMP support Update #3090.
    Comment 15
    1. Sebastian Huber, Mon, 02 Oct 2017 11:41:52 GMT

    In 7e195e66/rtems:

    bsp/imx: Add imx_get_irq_of_node() Update #3090.
    Comment 16
    1. Sebastian Huber, Mon, 02 Oct 2017 11:42:04 GMT

    In ce28d601/rtems:

    bsp/imx: Add imx_get_reg_of_node() Update #3090.
    Comment 17
    1. Sebastian Huber, Mon, 02 Oct 2017 11:42:16 GMT

    In 9db9024/rtems:

    bsp/imx: Fix I2C register header Update #3090.
    Comment 18
    1. Sebastian Huber, Mon, 02 Oct 2017 11:42:27 GMT

    In f043b9b/rtems:

    bsp/imx: Add I2C bus driver Update #3090.
    Comment 19
    1. Sebastian Huber, Fri, 06 Oct 2017 11:02:46 GMT

    In b39cda6/rtems:

    bsp/imx: Fix I2C registration with path Update #3090.
    Comment 20
    1. Sebastian Huber, Fri, 06 Oct 2017 11:02:57 GMT

    In e316be7/rtems:

    bsp/imx: Import iomux from FreeBSD Update #3090.
    Comment 21
    1. Sebastian Huber, Fri, 06 Oct 2017 11:03:09 GMT

    In 54380f42/rtems:

    bsp/imx: Add imx_iomux_configure_pins() Update #3090.
    Comment 22
    1. Sebastian Huber, Fri, 06 Oct 2017 11:03:20 GMT

    In 170df3d/rtems:

    bsp/imx: Add SPI bus driver Update #3090.
    Comment 23
    1. Sebastian Huber, Wed, 25 Oct 2017 12:31:19 GMT

    In a8a9cf1/rtems-libbsd:

    ffec: Add checksum offload Update #3090.
    Comment 24
    1. Sebastian Huber, Thu, 26 Oct 2017 06:44:46 GMT

    In 936b597/rtems-libbsd:

    ffec: Fix comment Update #3090.
    Comment 25
    1. Sebastian Huber, Thu, 02 Nov 2017 10:26:12 GMT

    In c52a968/rtems:

    bsp/imx: Implement bsp_reset() Update #3090.
    Comment 26
    1. Sebastian Huber, Thu, 02 Nov 2017 10:26:23 GMT

    In 4b055e23/rtems:

    bsp/imx: Drain console before reset Update #3090.
    Comment 27
    1. Sebastian Huber, Thu, 02 Nov 2017 12:44:27 GMT

    In 4438c4d8/rtems:

    bsp/imx: More robust and faster bsp_reset() Update #3090.
    Comment 28
    1. Sebastian Huber, Wed, 08 Nov 2017 07:44:56 GMT

    In 336fe3b/rtems:

    bsp/imx: Better utilize UART transmit FIFO Update #3090.
    Comment 29
    1. Sebastian Huber, Wed, 08 Nov 2017 07:45:08 GMT

    In fdf0e55/rtems:

    bsp/imx: Add UART baud change Update #3090.
    Comment 30
    1. Sebastian Huber, Thu, 09 Nov 2017 08:54:54 GMT

    In 6f5cfad/rtems-tools:

    Add tester imx7.ini Update #3090.
    Comment 31
    1. Sebastian Huber, Thu, 08 Feb 2018 09:01:00 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    4. milestone: changed from Indefinite to 5.1

    3091 - Core Dump in powerpc-rtems4.12-ld

    Link https://devel.rtems.org/ticket/3091
    Id 3091
    Reporter Joel Sherrill
    Created 7 August 2017 23:55:46
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This appears to have been introduced by the new binutils. Impacts qemuprep and qemuprep-altivec BSPs.

    gmake[8]: Entering directory `/data/home/joel/rtems-work/rtems-testing/rtems/build-powerpc-qemuprep-rtems/powerpc-rtems4.12/c/qemuprep/lib/libbsp/powerpc/motorola_powerpc/qemu_fakerom'
    powerpc-rtems4.12-ld -o qemu_fakerom.bin qemu_fakerom.o qemu_fakeres.o --oformat binary -nostdlib -Ttext 0xfff00000 --section-start=.romentry=0xfffffffc
    gmake[8]: __* [qemu_fakerom.bin] Segmentation fault __

    Attachments:

    1 Sebastian Huber, Thu, 10 Aug 2017 08:12:52 GMT
      attach: set to 0001-Fix-Binutils-2.29-PR21884.patch
    Comment 1
    1. Joel Sherrill, Mon, 07 Aug 2017 23:55:58 GMT
    2. owner: changed from chrisj@… to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Tue, 08 Aug 2017 11:44:01 GMT

    Yes, I will have a look at this once GCC 7.2 is out.

    Comment 3
    1. Sebastian Huber, Thu, 10 Aug 2017 08:18:26 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 7208ab6/rtems-source-builder:

    4.12: Fix for Binutils PR21884 See ​https://sourceware.org/bugzilla/show_bug.cgi?id=21884. Close #3091.
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3096 - Shell internal commands should be public.

    Link https://devel.rtems.org/ticket/3096
    Id 3096
    Reporter Chris Johns
    Created 13 August 2017 06:00:41
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type enhancement
    Component shell
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords shell
    Cc  
    Blocking  
    Blocked by  

    Description

    A few of the functions held in cpukit/libmisc/shell/internal.h are useful in building system. For example rtems_shell_register_monitor_commands() and rtems_shell_execute_cmd().

    The shell commands are important and systems may provide other scripting mechanisms, for example sequences in YAML files. Providing public access lets users know the functions are supported.

    Comment 1
    1. Joel Sherrill, Sun, 13 Aug 2017 15:45:14 GMT

    Hard to argue against. The shell evolved and this is just an artifact. We now have a different opinion. Change it.

    Comment 2
    1. Chris Johns, Sun, 13 Aug 2017 23:23:14 GMT

    I have found there is currently no way to have the commands registered unless you start a shell. The POSIX once call used to add the shell's configured commands is buried inside the main loop of the shell task.

    I would like this change to be back ported to 4.11 to make applications compatible between 4.11 and 4.12 and beyond.

    Comment 3
    1. Chris Johns, Tue, 15 Aug 2017 01:38:26 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 2465c01/rtems:

    libmisc/shell: Make some internal shell functions public. Add 'rtems_shell_init_environment()' so a user can create the shell environment without needing to run a shell. Move 'rtems_shell_lookup_topic', 'rtems_shell_can_see_cmd', and 'rtems_shell_execute_cmd' from the internal interface to the public interface. Closes #3096.
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3098 - Add new RTEMS repos to github.

    Link https://devel.rtems.org/ticket/3098
    Id 3098
    Reporter Chris Johns
    Created 16 August 2017 00:03:01
    Modified 19 October 2018 16:31:13
    Owner Amar Takhar
    Type infra
    Component admin
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity blocker
    Keywords github
    Cc  
    Blocking  
    Blocked by  

    Description

    Please add:

  • rtems-docs.git
  • rtems-release.git
  • to our github repos.

    Comment 1
    1. Chris Johns, Wed, 23 Aug 2017 22:56:04 GMT
    2. priority: changed from normal to highest
    3. severity: changed from normal to blocker

    This is important for a release.

    Comment 2
    1. Joel Sherrill, Wed, 11 Oct 2017 22:41:04 GMT

    This ticket is marked as a blocker for 4.12. Please update with a estimate of when this will be completed.

    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 4
    1. Chris Johns, Tue, 06 Feb 2018 00:42:07 GMT

    Ping?

    Comment 5
    1. Joel Sherrill, Sat, 13 Oct 2018 22:33:40 GMT
    2. owner: changed from amar@… to Amar Takhar
    3. status: changed from new to assigned
    Comment 6
    1. Joel Sherrill, Sun, 14 Oct 2018 00:39:58 GMT

    If someone knows how to do this (Gedare, Amar, etc), please address this. It is a blocker.

    Comment 7
    1. Amar Takhar, Sun, 14 Oct 2018 20:52:56 GMT

    Okay I can do this.

    Comment 8
    1. Amar Takhar, Fri, 19 Oct 2018 16:31:13 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    ​https://github.com/RTEMS/rtems-docs ​https://github.com/RTEMS/rtems-release

    3099 - Add RTEMS FDT wrapper and shell command to libmisc

    Link https://devel.rtems.org/ticket/3099
    Id 3099
    Reporter Chris Johns
    Created 16 August 2017 03:49:39
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type task
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords FDT FPGA zynq
    Cc  
    Blocking  
    Blocked by  

    Description

    Provide a wrapper to the FDT library for use on RTEMS. The wrapper provides a simplified interface suitable for applications. The shell command provides access to registered FDT blobs so a user can search the tree like a file system and optionally read and write from device addresses.

    Comment 1
    1. Chris Johns, Wed, 16 Aug 2017 03:54:57 GMT
    2. status: changed from assigned to accepted
    Comment 2
    1. Chris Johns, Sun, 20 Aug 2017 01:12:55 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 6b7efdb2/rtems:

    libmisc/rtems-fdt: Add RTEMS FDT wrapper and shell command to libmisc. Provide application support for handling FDT blobs in RTEMS. This is useful when interfacing FPGA fabrics. Provide a shell command to list a blob as well as provide read and write access to addresses in the FTB. Closes #3099.
    Comment 3
    1. Chris Johns, Wed, 23 Aug 2017 23:40:39 GMT

    In 602b184f/rtems:

    libmisc/rtems-fdt: Add libmisc/rtems-fdt to the cpukit wrapup. Updates #3099.
    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:35:44 GMT
    2. component: changed from misc to unspecified
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3100 - Add Xilinx AXI I2C driver

    Link https://devel.rtems.org/ticket/3100
    Id 3100
    Reporter Chris Johns
    Created 16 August 2017 03:50:39
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type task
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords Xilinx zynq FPGA
    Cc  
    Blocking  
    Blocked by  

    Description

    Add a Xilinx AXI I2C driver.

    Comment 1
    1. Chris Johns, Wed, 16 Aug 2017 03:55:09 GMT
    2. status: changed from assigned to accepted
    Comment 2
    1. Chris Johns, Mon, 21 Aug 2017 23:22:15 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed
    Comment 3
    1. Sebastian Huber, Mon, 16 Oct 2017 06:19:24 GMT
    2. component: changed from score to arch/arm
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3101 - Add I2C Drivers for LM25066A, TMP112, ADS1113 and ADS1115

    Link https://devel.rtems.org/ticket/3101
    Id 3101
    Reporter Chris Johns
    Created 16 August 2017 03:53:18
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type task
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords I2C
    Cc  
    Blocking  
    Blocked by  

    Description

    Add drivers for:

  • LM25066A
  • TMP112
  • ADS1113
  • ADS1115
  • Comment 1
    1. Chris Johns, Wed, 16 Aug 2017 03:53:32 GMT
    2. owner: set to joel.sherrill@…
    3. component: changed from General to cpukit
    Comment 2
    1. Chris Johns, Wed, 16 Aug 2017 03:53:44 GMT
    2. owner: changed from joel.sherrill@… to Chris Johns
    3. status: changed from new to assigned
    Comment 3
    1. Chris Johns, Wed, 16 Aug 2017 03:55:21 GMT
    2. status: changed from assigned to accepted
    Comment 4
    1. Chris Johns, Mon, 21 Aug 2017 23:21:46 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3102 - rtems-exeinfo does not decode ARM static constructors.

    Link https://devel.rtems.org/ticket/3102
    Id 3102
    Reporter Chris Johns
    Created 16 August 2017 08:09:40
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The sections for ARM are not the same as other architectures.

    Comment 1
    1. Chris Johns, Wed, 16 Aug 2017 08:09:52 GMT
    2. status: changed from assigned to accepted
    Comment 2
    1. Chris Johns, Wed, 16 Aug 2017 08:18:49 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 78bbe4c/rtems-tools:

    linkers/exe-info Support ARM static constructors. Note, ARM destructors are registered at runtime and currently not easly found. Update libiberty to get a newer demangler. Closes #3102.
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3103 - rtems-tools on CentOS 7 Build Failure

    Link https://devel.rtems.org/ticket/3103
    Id 3103
    Reporter Joel Sherrill
    Created 19 August 2017 17:07:50
    Modified 9 November 2017 06:27:14
    Owner chrisj@…
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    A build failure for rtems-tools on the master has been reported on CentOS 7. This is my notes as I try to reproduce it.

    [joel@localhost rtems-tools]$ ./waf configure
    Setting top to : /home/joel/rtems-work/rtems-tools
    Setting out to : /home/joel/rtems-work/rtems-tools/build
    Version : 4.12.78bbe4c1a31d (4.12)
    Checking for program 'python' : /usr/bin/python
    Checking for python version >= 2.6.6 : 2.7.5
    Checking for 'gcc' (C compiler) : /usr/bin/gcc
    Checking for 'g++' (C++ compiler) : /usr/bin/g++
    Checking for header alloca.h : yes
    Checking for header fcntl.h : yes
    Checking for header process.h : not found
    Checking for header stdlib.h : yes
    Checking for header string.h : yes
    Checking for header strings.h : yes
    Checking for header sys/file.h : yes
    Checking for header sys/stat.h : yes
    Checking for header sys/time.h : yes
    Checking for header sys/types.h : yes
    Checking for header sys/wait.h : yes
    Checking for header unistd.h : yes
    Checking for header vfork.h : not found
    Checking for function getrusage : yes
    Checking for program 'm4' : /usr/bin/m4
    Checking for header sys/wait.h : yes
    Checking for function kill : yes
    Checking for 'gcc' (C compiler) : /usr/bin/gcc
    Checking for 'g++' (C++ compiler) : /usr/bin/g++
    Checking for 'g++' (C++ compiler) : /usr/bin/g++
    Checking for function open64 : not found
    Checking for function stat64 : not found
    'configure' finished successfully (0.786s)
    =========================================================
    [joel@localhost rtems-tools]$ ./waf -j 1 --verbose
    Waf: Entering directory `/home/joel/rtems-work/rtems-tools/build'
    [ 88/151] Compiling rtemstoolkit/rld-process.cpp
    11:58:16 runner ['/usr/bin/g++', '-pipe', '-g', '-O2', '-Wall', '-Wextra', '-pedantic', '-Irtemstoolkit', '-I../rtemstoolkit', '-Irtemstoolkit/elftoolchain/libelf', '-I../rtemstoolkit/elftoolchain/libelf', '-Irtemstoolkit/elftoolchain/common', '-I../rtemstoolkit/elftoolchain/common', '-Irtemstoolkit/libiberty', '-I../rtemstoolkit/libiberty', '-DHAVE_CONFIG_H=1', '-DRTEMS_VERSION="4.12"', '-DRTEMS_RELEASE="4.12.78bbe4c1a31d"', '-DFASTLZ_LEVEL=1', '../rtemstoolkit/rld-process.cpp', '-c', '-o/home/joel/rtems-work/rtems-tools/build/rtemstoolkit/rld-process.cpp.7.o']
    In file included from ../rtemstoolkit/libiberty/libiberty.h:42:0,

    from ../rtemstoolkit/rld-process.cpp:64:

    ../rtemstoolkit/libiberty/ansidecl.h:169:64: error: new declaration ‘char* basename(const char*)’

    # define ATTRIBUTE_NONNULL(m) attribute ((nonnull (m)))

    ../rtemstoolkit/libiberty/libiberty.h:112:64: note: in expansion of macro ‘ATTRIBUTE_NONNULL’

    extern char *basename (const char *) ATTRIBUTE_RETURNS_NONNULL ATTRIBUTE_NONNULL(1);

    In file included from ../rtemstoolkit/rld-process.cpp:24:0:
    /usr/include/string.h:599:26: error: ambiguates old declaration ‘const char* basename(const char*)’

    extern "C++" const char *basename (const char *filename)

    In file included from ../rtemstoolkit/libiberty/libiberty.h:42:0,

    from ../rtemstoolkit/rld-process.cpp:64: __

    ../rtemstoolkit/libiberty/ansidecl.h:169:64: error: declaration of ‘int vasprintf(char__, const char*, va_list_tag*)’ has a different exception specifier

    # define ATTRIBUTE_NONNULL(m) attribute ((nonnull (m)))

    ../rtemstoolkit/libiberty/ansidecl.h:198:80: note: in expansion of macro ‘ATTRIBUTE_NONNULL’

    #define ATTRIBUTE_PRINTF(m, n) attribute ((format (printf, m, n))) ATTRIBUTE_NONNULL(m)

    ../rtemstoolkit/libiberty/libiberty.h:651:55: note: in expansion of macro ‘ATTRIBUTE_PRINTF’

    extern int vasprintf (char __, const char *, va_list) ATTRIBUTE_PRINTF(2,0); __

    In file included from ../rtemstoolkit/rld-process.cpp:23:0:
    /usr/include/stdio.h:399:12: error: from previous declaration ‘int vasprintf(char__, const char*, va_list_tag*) throw ()’ __

    extern int vasprintf (char __restrict ptr, const char *restrict f, __

    Waf: Leaving directory `/home/joel/rtems-work/rtems-tools/build'
    Build failed

    -> task in 'rld' failed with exit status 1:

    {task 23048432: cxx rld-process.cpp -> rld-process.cpp.7.o}

    ['/usr/bin/g++', '-pipe', '-g', '-O2', '-Wall', '-Wextra', '-pedantic', '-Irtemstoolkit', '-I../rtemstoolkit', '-Irtemstoolkit/elftoolchain/libelf', '-I../rtemstoolkit/elftoolchain/libelf', '-Irtemstoolkit/elftoolchain/common', '-I../rtemstoolkit/elftoolchain/common', '-Irtemstoolkit/libiberty', '-I../rtemstoolkit/libiberty', '-DHAVE_CONFIG_H=1', '-DRTEMS_VERSION="4.12"', '-DRTEMS_RELEASE="4.12.78bbe4c1a31d"', '-DFASTLZ_LEVEL=1', '../rtemstoolkit/rld-process.cpp', '-c', '-o/home/joel/rtems-work/rtems-tools/build/rtemstoolkit/rld-process.cpp.7.o']
    ==================================================================
    Looking down into libiberty.h, I picked on basename()

    /* HAVE_DECL_* is a three-state macro: undefined, 0 or 1. If it is

    undefined, we haven't run the autoconf check so provide the
    declaration without arguments. If it is 0, we checked and failed
    to find the declaration so provide a fully prototyped one. If it
    is 1, we found it so don't provide any declaration at all. */

    #if !HAVE_DECL_BASENAME

    #if defined (GNU_LIBRARY ) defined (linux) \
    defined (FreeBSD) defined (OpenBSD) defined (NetBSD) \ defined (CYGWIN) defined (CYGWIN32) defined (MINGW32) \ defined (DragonFly) defined (HAVE_DECL_BASENAME)

    extern char *basename (const char *) ATTRIBUTE_RETURNS_NONNULL ATTRIBUTE_NONNULL(1);
    #else
    /* Do not allow basename to be used if there is no prototype seen. We

    either need to use the above prototype or have one from
    autoconf which would result in HAVE_DECL_BASENAME being set. */

    #define basename basename_cannot_be_used_without_a_prototype
    #endif
    #endif
    ============================================
    The native CentOS 7 has this definition of basename:

    # ifndef basename
    /* Return the file name within directory of FILENAME. We don't

    declare the function if the `basename' macro is available (defined
    in ) which makes the XPG version of this function
    available. */

    # ifdef CORRECT_ISO_CPP_STRING_H_PROTO
    extern "C++" char *basename (char *filename)

    THROW asm ("basename") nonnull ((1));

    extern "C++" const char *basename (const char *filename)

    THROW asm ("basename") nonnull ((1));

    # else
    extern char *basename (const char *filename) THROW nonnull ((1));
    # endif
    # endif
    #endif

    ==============================
    I think we are getting the C++ prototype from string.h and a conflicting C prototype from libiberty.h

    Comment 1
    1. Chris Johns, Sun, 20 Aug 2017 07:22:34 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In f2bb439/rtems-tools:

    rtemstoolkit/libiberty: Fix broken configure detection. The file libiberty.h requires some configure macros to control some parts and these are not provided so the file did not match what was needed. Hard code the result and remove the need for the macros. The related calls are not provided in our libiberty usage and not needed. Closes #3103.
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3109 - Add RISC-V support

    Link https://devel.rtems.org/ticket/3109
    Id 3109
    Reporter Sebastian Huber
    Created 23 August 2017 05:20:45
    Modified 24 August 2018 05:13:10
    Owner Hesham Almatary
    Type enhancement
    Component arch/riscv
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add RISC-V 32-bit tool chain to RSB consisting of Binutils, GCC, Newlib and GDB. Add CPU port and a basic simulator BSP.

    Comment 1
    1. Sebastian Huber, Wed, 23 Aug 2017 05:21:49 GMT

    In e960835/rtems-source-builder:

    4.12: Add riscv32 to all Update #3109.
    Comment 2
    1. Hesham Almatary, Wed, 25 Oct 2017 23:20:39 GMT
    2. owner: set to Hesham Almatary
    3. status: changed from new to accepted
    Comment 3
    1. Hesham Almatary, Thu, 26 Oct 2017 05:21:42 GMT
    2. summary: changed from Add RISC-V 32-bit support to Add RISC-V support

    Account for 64-bit RISC-V

    Comment 4
    1. Hesham Almatary, Fri, 27 Oct 2017 05:45:00 GMT

    In 5bd4aa6/rtems-source-builder:

    RSB - Add support for RISC-V RV64 (64-bit) toolchain v2 Update #3109
    Comment 5
    1. Hesham Almatary, Sat, 28 Oct 2017 07:01:25 GMT

    In e274bdf/rtems-source-builder:

    RSB - RISC-V: Add scripts to build RISC-V's simulator Update #3109
    Comment 6
    1. Hesham Almatary, Sat, 28 Oct 2017 07:11:34 GMT

    In 35b9c0c/rtems-tools:

    Tester - RISC-V: Add spike simulator and scripts/bsp for riscv ports Update #3109
    Comment 7
    1. Hesham Almatary, Sat, 28 Oct 2017 07:42:52 GMT

    In 6d85e05/rtems:

    bsp: Add new riscv_generic bsp v3 Only runs/tested on simulator/spike. Ticker, hello, capture work proprely Tested via RTEMS Tester, Passed: 525/565 (92%) Update #3109
    Comment 8
    1. Sebastian Huber, Sat, 28 Oct 2017 12:07:52 GMT

    In cf614ec/rtems:

    riscv32: Add missing preinstall.am Update #3109.
    Comment 9
    1. Hesham Almatary, Tue, 31 Oct 2017 23:22:09 GMT

    In 8fa827c/rtems:

    bsp: Make riscv_generic work for both riscv32 and riscv64 - v2 Update #3109
    Comment 10
    1. Sebastian Huber, Thu, 04 Jan 2018 06:19:47 GMT

    In 030ce68/rtems:

    tests: Fix canonical-target-name.m4 Update #3109.
    Comment 11
    1. Sebastian Huber, Fri, 24 Aug 2018 05:13:10 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed
    4. version: set to 5
    5. component: changed from unspecified to arch/riscv
    6. milestone: changed from Indefinite to 5.1

    Superseded by #3433, #3452, and #3453.


    3111 - Newlib: Change time_t and clock_t integer types to 64-bit

    Link https://devel.rtems.org/ticket/3111
    Id 3111
    Reporter Sebastian Huber
    Created 24 August 2017 06:57:06
    Modified 29 January 2018 05:59:28
    Owner Sebastian Huber
    Type enhancement
    Component tool/newlib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Thu, 24 Aug 2017 07:26:05 GMT
    2. summary: changed from Newlib: Change time_t and clock_t integer types to at 64-bit to Newlib: Change time_t and clock_t integer types to 64-bit
    Comment 2
    1. Sebastian Huber, Fri, 25 Aug 2017 12:37:43 GMT

    In 4f364ef/rtems-source-builder:

    4.12: Change clock_t to 64-bit Update #2135. Update #3111.
    Comment 3
    1. Sebastian Huber, Thu, 05 Oct 2017 12:34:58 GMT

    In 76d9db3/rtems-source-builder:

    4.12: Update to Newlib 2.5.0.20170922 The time_t is now a 64-bit signed integer. This update includes a patch to introduce the self-contained POSIX synchronization objects. Update #2514. Update #3111. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 4
    1. Sebastian Huber, Thu, 05 Oct 2017 12:35:53 GMT

    In e46a075/rtems:

    Enforce compatible Newlib version This Newlib check ensures that we have a 64-bit time_t and self-contained POSIX synchronization objects. Update #2514. Update #3111. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 5
    1. Sebastian Huber, Fri, 06 Oct 2017 07:43:41 GMT

    In 900fda45/rtems:

    rtems: Fix format warnings Update #3111.
    Comment 6
    1. Sebastian Huber, Mon, 09 Oct 2017 05:24:27 GMT

    In 6489bcb/rtems:

    psxtests/psx05: Fix timeout calculation Update #3111.
    Comment 7
    1. Joel Sherrill, Thu, 12 Oct 2017 00:17:33 GMT
    2. owner: changed from chrisj@… to Sebastian Huber
    3. status: changed from new to assigned

    Sebastian .. is this ready to close or is there something left to do?

    Comment 8
    1. Sebastian Huber, Thu, 12 Oct 2017 11:19:49 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    4. version: set to 4.12
    5. component: changed from tool to tool/newlib
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 10
    1. Sebastian Huber, Mon, 29 Jan 2018 05:59:28 GMT

    In d8de6b9/rtems:

    ada: Fix RTEMS.Time_t Update #3111.

    3112 - POSIX: Make pthread_mutex_t self-contained

    Link https://devel.rtems.org/ticket/3112
    Id 3112
    Reporter Sebastian Huber
    Created 24 August 2017 09:33:35
    Modified 22 November 2017 12:51:51
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Change the POSIX mutex into a self-contained object using , e.g.

    typedef struct {
    struct _Mutex_recursive_Control _mutex;
    unsigned int _flags;
    struct _Scheduler_Control *_scheduler;
    __uint64_t _priority_ceiling;
    } pthread_mutex_t;
    Comment 1
    1. Sebastian Huber, Mon, 18 Sep 2017 05:07:02 GMT
    2. status: changed from assigned to accepted
    3. milestone: changed from Indefinite to 4.12.0
    Comment 2
    1. Sebastian Huber, Wed, 27 Sep 2017 10:11:48 GMT

    In e460cd00/rtems:

    score: Rename to _Scheduler_Control Rename struct Scheduler_Control to _Scheduler_Control to allow its use in standard header files, e.g. . Update #3112.
    Comment 3
    1. Sebastian Huber, Wed, 27 Sep 2017 12:57:42 GMT

    In e2fe881a/rtems:

    score: Simplify red-black tree debug support Make the RBTree_Node layout independent of RTEMS_DEBUG (and all other build configuration options). This allows the use of this structure in Newlib. Update #3112.
    Comment 4
    1. Sebastian Huber, Thu, 05 Oct 2017 12:34:58 GMT

    In 76d9db3/rtems-source-builder:

    4.12: Update to Newlib 2.5.0.20170922 The time_t is now a 64-bit signed integer. This update includes a patch to introduce the self-contained POSIX synchronization objects. Update #2514. Update #3111. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 5
    1. Sebastian Huber, Thu, 05 Oct 2017 12:35:53 GMT

    In e46a075/rtems:

    Enforce compatible Newlib version This Newlib check ensures that we have a 64-bit time_t and self-contained POSIX synchronization objects. Update #2514. Update #3111. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 6
    1. Sebastian Huber, Thu, 05 Oct 2017 12:37:09 GMT

    In de59c065/rtems:

    posix: Implement self-contained POSIX mutex POSIX mutexes are now available in all configurations and no longer depend on --enable-posix. Update #2514. Update #3112.
    Comment 7
    1. Sebastian Huber, Mon, 09 Oct 2017 06:05:48 GMT

    In d8f7bdc/rtems-docs:

    c-user: Add obsolete configuration options section Update #2493. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 8
    1. Sebastian Huber, Wed, 11 Oct 2017 12:34:32 GMT
    2. component: changed from score to posix
    Comment 9
    1. Sebastian Huber, Thu, 12 Oct 2017 05:16:16 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 9c0cefb/rtems:

    confdefs: Add warnings for obsolete options Update #2674. Close #3112. Close #3113. Close #3114. Close #3115. Close #3116.
    Comment 10
    1. Sebastian Huber, Wed, 18 Oct 2017 06:53:08 GMT

    In 6087f33e/rtems:

    tmtests/tmfine01: Add test cases Update #2674. Update #3112. Update #3113. Update #3114. Update #3115.
    Comment 11
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 12
    1. Sebastian Huber, Wed, 22 Nov 2017 12:51:51 GMT

    In 7188bd5/rtems-docs:

    c-user: Remove RTEMS_SYSINIT_POSIX_MUTEX Update #3112.

    3113 - POSIX: Make pthread_cond_t self-contained

    Link https://devel.rtems.org/ticket/3113
    Id 3113
    Reporter Sebastian Huber
    Created 24 August 2017 09:38:11
    Modified 22 November 2017 12:51:42
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Change the POSIX condition variable into a self-contained object using , e.g.

    typedef struct {
    struct _Condition_Control _condition;
    pthread_mutex_t *_mutex;
    clockid_t _clock;
    } pthread_cond_t;
    Comment 1
    1. Sebastian Huber, Tue, 12 Sep 2017 06:12:16 GMT

    In 62c912e/rtems:

    posix: Use mutex object itself for condvar We should only use the address used to initialize the mutex object according to POSIX, "2.9.9 Synchronization Object Copies and Alternative Mappings". ​http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_09 Update #3113.
    Comment 2
    1. Sebastian Huber, Mon, 18 Sep 2017 05:07:02 GMT
    2. status: changed from assigned to accepted
    3. milestone: changed from Indefinite to 4.12.0
    Comment 3
    1. Sebastian Huber, Thu, 05 Oct 2017 12:34:58 GMT

    In 76d9db3/rtems-source-builder:

    4.12: Update to Newlib 2.5.0.20170922 The time_t is now a 64-bit signed integer. This update includes a patch to introduce the self-contained POSIX synchronization objects. Update #2514. Update #3111. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 4
    1. Sebastian Huber, Thu, 05 Oct 2017 12:35:53 GMT

    In e46a075/rtems:

    Enforce compatible Newlib version This Newlib check ensures that we have a 64-bit time_t and self-contained POSIX synchronization objects. Update #2514. Update #3111. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 5
    1. Sebastian Huber, Thu, 05 Oct 2017 12:36:56 GMT

    In 5222488/rtems:

    posix: Implement self-contained POSIX condvar POSIX condition variables are now available in all configurations and no longer depend on --enable-posix. Update #2514. Update #3113.
    Comment 6
    1. Sebastian Huber, Mon, 09 Oct 2017 06:05:48 GMT

    In d8f7bdc/rtems-docs:

    c-user: Add obsolete configuration options section Update #2493. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 7
    1. Sebastian Huber, Wed, 11 Oct 2017 12:34:32 GMT
    2. component: changed from score to posix
    Comment 8
    1. Sebastian Huber, Thu, 12 Oct 2017 05:16:16 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 9c0cefb/rtems:

    confdefs: Add warnings for obsolete options Update #2674. Close #3112. Close #3113. Close #3114. Close #3115. Close #3116.
    Comment 9
    1. Sebastian Huber, Wed, 18 Oct 2017 06:53:08 GMT

    In 6087f33e/rtems:

    tmtests/tmfine01: Add test cases Update #2674. Update #3112. Update #3113. Update #3114. Update #3115.
    Comment 10
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 11
    1. Sebastian Huber, Wed, 22 Nov 2017 12:51:42 GMT

    In 5680ec5/rtems-docs:

    c-user: RTEMS_SYSINIT_POSIX_CONDITION_VARIABLE Update #3113.

    3114 - POSIX: Make pthread_barrier_t self-contained

    Link https://devel.rtems.org/ticket/3114
    Id 3114
    Reporter Sebastian Huber
    Created 24 August 2017 09:41:44
    Modified 22 November 2017 12:51:59
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Change the POSIX barrier into a self-contained object using , e.g.

    typedef struct {
    struct _Thread_queue_Queue _queue;
    unsigned int _flags;
    unsigned int _count;
    } pthread_barrier_t;
    Comment 1
    1. Sebastian Huber, Mon, 18 Sep 2017 05:07:02 GMT
    2. status: changed from assigned to accepted
    3. milestone: changed from Indefinite to 4.12.0
    Comment 2
    1. Sebastian Huber, Thu, 05 Oct 2017 12:34:58 GMT

    In 76d9db3/rtems-source-builder:

    4.12: Update to Newlib 2.5.0.20170922 The time_t is now a 64-bit signed integer. This update includes a patch to introduce the self-contained POSIX synchronization objects. Update #2514. Update #3111. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 3
    1. Sebastian Huber, Thu, 05 Oct 2017 12:35:53 GMT

    In e46a075/rtems:

    Enforce compatible Newlib version This Newlib check ensures that we have a 64-bit time_t and self-contained POSIX synchronization objects. Update #2514. Update #3111. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 4
    1. Sebastian Huber, Thu, 05 Oct 2017 12:36:31 GMT

    In e67929c/rtems:

    posix: Implement self-contained POSIX barriers POSIX barriers are now available in all configurations and no longer depend on --enable-posix. Update #2514. Update #3114.
    Comment 5
    1. Sebastian Huber, Mon, 09 Oct 2017 06:05:48 GMT

    In d8f7bdc/rtems-docs:

    c-user: Add obsolete configuration options section Update #2493. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 6
    1. Sebastian Huber, Wed, 11 Oct 2017 12:34:32 GMT
    2. component: changed from score to posix
    Comment 7
    1. Sebastian Huber, Thu, 12 Oct 2017 05:16:16 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 9c0cefb/rtems:

    confdefs: Add warnings for obsolete options Update #2674. Close #3112. Close #3113. Close #3114. Close #3115. Close #3116.
    Comment 8
    1. Sebastian Huber, Wed, 18 Oct 2017 06:53:08 GMT

    In 6087f33e/rtems:

    tmtests/tmfine01: Add test cases Update #2674. Update #3112. Update #3113. Update #3114. Update #3115.
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 10
    1. Sebastian Huber, Wed, 22 Nov 2017 12:51:59 GMT

    In 6c1bf7e/rtems-docs:

    c-user: Remove RTEMS_SYSINIT_POSIX_BARRIER Update #3114.

    3115 - POSIX: Make pthread_rwlock_t self-contained

    Link https://devel.rtems.org/ticket/3115
    Id 3115
    Reporter Sebastian Huber
    Created 24 August 2017 09:44:35
    Modified 22 November 2017 12:52:07
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Change the POSIX read-write lock into a self-contained object using , e.g.

    typedef struct {
    struct _Thread_queue_Queue _queue;
    unsigned int _flags;
    unsigned int _readers;
    } pthread_rwlock_t;
    Comment 1
    1. Sebastian Huber, Mon, 18 Sep 2017 05:07:02 GMT
    2. status: changed from assigned to accepted
    3. milestone: changed from Indefinite to 4.12.0
    Comment 2
    1. Sebastian Huber, Thu, 05 Oct 2017 12:34:58 GMT

    In 76d9db3/rtems-source-builder:

    4.12: Update to Newlib 2.5.0.20170922 The time_t is now a 64-bit signed integer. This update includes a patch to introduce the self-contained POSIX synchronization objects. Update #2514. Update #3111. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 3
    1. Sebastian Huber, Thu, 05 Oct 2017 12:35:53 GMT

    In e46a075/rtems:

    Enforce compatible Newlib version This Newlib check ensures that we have a 64-bit time_t and self-contained POSIX synchronization objects. Update #2514. Update #3111. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 4
    1. Sebastian Huber, Thu, 05 Oct 2017 12:36:43 GMT

    In 89fc9345/rtems:

    posix: Implement self-contained POSIX rwlocks POSIX rwlocks are now available in all configurations and no longer depend on --enable-posix. Update #2514. Update #3115.
    Comment 5
    1. Sebastian Huber, Mon, 09 Oct 2017 06:05:48 GMT

    In d8f7bdc/rtems-docs:

    c-user: Add obsolete configuration options section Update #2493. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 6
    1. Sebastian Huber, Wed, 11 Oct 2017 12:34:32 GMT
    2. component: changed from score to posix
    Comment 7
    1. Sebastian Huber, Thu, 12 Oct 2017 05:16:16 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 9c0cefb/rtems:

    confdefs: Add warnings for obsolete options Update #2674. Close #3112. Close #3113. Close #3114. Close #3115. Close #3116.
    Comment 8
    1. Sebastian Huber, Wed, 18 Oct 2017 06:53:08 GMT

    In 6087f33e/rtems:

    tmtests/tmfine01: Add test cases Update #2674. Update #3112. Update #3113. Update #3114. Update #3115.
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 10
    1. Sebastian Huber, Wed, 22 Nov 2017 12:52:07 GMT

    In d1a824f/rtems-docs:

    c-user: Remove RTEMS_SYSINIT_POSIX_RWLOCK Update #3115.

    3116 - POSIX: Make sem_t self-contained

    Link https://devel.rtems.org/ticket/3116
    Id 3116
    Reporter Sebastian Huber
    Created 24 August 2017 09:46:54
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Change the POSIX semaphore into a self-contained object using , e.g.

    typedef struct {
    struct _Semaphore_Control _sem;
    } sem_t;
    Comment 1
    1. Sebastian Huber, Mon, 18 Sep 2017 05:07:02 GMT
    2. status: changed from assigned to accepted
    3. milestone: changed from Indefinite to 4.12.0
    Comment 2
    1. Sebastian Huber, Thu, 05 Oct 2017 12:34:58 GMT

    In 76d9db3/rtems-source-builder:

    4.12: Update to Newlib 2.5.0.20170922 The time_t is now a 64-bit signed integer. This update includes a patch to introduce the self-contained POSIX synchronization objects. Update #2514. Update #3111. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 3
    1. Sebastian Huber, Thu, 05 Oct 2017 12:35:53 GMT

    In e46a075/rtems:

    Enforce compatible Newlib version This Newlib check ensures that we have a 64-bit time_t and self-contained POSIX synchronization objects. Update #2514. Update #3111. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 4
    1. Sebastian Huber, Thu, 05 Oct 2017 12:36:18 GMT

    In c090db7/rtems:

    posix: Implement self-contained POSIX semaphores For semaphore object pointer and object validation see POSIX_SEMAPHORE_VALIDATE_OBJECT(). Destruction or close of a busy semaphore returns an error status. The object is not flushed. POSIX semaphores are now available in all configurations and no longer depend on --enable-posix. Update #2514. Update #3116.
    Comment 5
    1. Sebastian Huber, Mon, 09 Oct 2017 06:05:48 GMT

    In d8f7bdc/rtems-docs:

    c-user: Add obsolete configuration options section Update #2493. Update #3112. Update #3113. Update #3114. Update #3115. Update #3116.
    Comment 6
    1. Sebastian Huber, Wed, 11 Oct 2017 12:34:32 GMT
    2. component: changed from score to posix
    Comment 7
    1. Sebastian Huber, Thu, 12 Oct 2017 05:15:28 GMT

    In 64564df/rtems-docs:

    c-user: CONFIGURE_MAXIMUM_POSIX_SEMAPHORES This configuration is not obsolete since it is still used for named semaphores. Update #3116.
    Comment 8
    1. Sebastian Huber, Thu, 12 Oct 2017 05:16:16 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 9c0cefb/rtems:

    confdefs: Add warnings for obsolete options Update #2674. Close #3112. Close #3113. Close #3114. Close #3115. Close #3116.
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3117 - score: Optimize _Thread_queue_Enqueue() timeout handling

    Link https://devel.rtems.org/ticket/3117
    Id 3117
    Reporter Sebastian Huber
    Created 24 August 2017 09:51:38
    Modified 22 March 2018 08:06:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Use the Thread_queue_Context::enqueue_callout to do the timeout handling. This avoids the switch statement in _Thread_queue_Timeout(). It removes the thread queue dependency to _Thread_Timeout().

    Comment 1
    1. Sebastian Huber, Thu, 24 Aug 2017 09:52:09 GMT
    2. summary: changed from __score: Optimize _Thread_queue_Enqueue()__ to __score: Optimize _Thread_queue_Enqueue() timeout handling__
    Comment 2
    1. Sebastian Huber, Mon, 09 Oct 2017 12:18:01 GMT
    2. status: changed from assigned to accepted
    3. milestone: changed from Indefinite to 4.12.0
    Comment 3
    1. Sebastian Huber, Tue, 17 Oct 2017 06:31:01 GMT

    In bf2a53d2/rtems:

    score: Rename watchdog variants Rename PER_CPU_WATCHDOG_RELATIVE in PER_CPU_WATCHDOG_MONOTONIC to highlight the corresponding POSIX CLOCK_MONOTONIC. Rename PER_CPU_WATCHDOG_ABSOLUTE in PER_CPU_WATCHDOG_REALTIME to highlight the corresponding POSIX CLOCK_REALTIME. Update #3117. Update #3182.
    Comment 4
    1. Sebastian Huber, Tue, 17 Oct 2017 06:31:14 GMT

    In 91ce012c/rtems:

    score: Rename _Watchdog_Per_CPU_insert_monotonic() Rename _Watchdog_Per_CPU_insert_monotonic() in _Watchdog_Per_CPU_insert_ticks(). Update #3117. Update #3182.
    Comment 5
    1. Sebastian Huber, Tue, 17 Oct 2017 11:57:07 GMT

    In 9a583a9/rtems-libbsd:

    SLEEPQUEUE(9): Update due to API changes Update #3117. Update #3182.
    Comment 6
    1. Sebastian Huber, Tue, 24 Oct 2017 08:20:25 GMT

    In 02878626/rtems:

    score: Add _Thread_Add_timeout_ticks() Replace _Thread_Timer_insert_monotonic() with _Thread_Add_timeout_ticks(). Update #3117. Update #3182.
    Comment 7
    1. Sebastian Huber, Tue, 24 Oct 2017 08:20:37 GMT

    In 27cfe7c/rtems:

    score: Add _Watchdog_Ticks_per_second This value is frequently used. Avoid the function call overhead and the integer division at run-time. Update #3117. Update #3182.
    Comment 8
    1. Sebastian Huber, Tue, 24 Oct 2017 08:20:49 GMT

    In e0dc6ef/rtems:

    rtems: Simplify RTEMS_MILLISECONDS_TO_MICROSECONDS Remove the cast so that it can be used in C pre-processor directives. Update #3117. Update #3182.
    Comment 9
    1. Sebastian Huber, Tue, 24 Oct 2017 08:21:01 GMT

    In 381ef5c/rtems:

    confdefs: Warn about problematic ticks per second A non-integer clock ticks per second value may lead to inaccurate time format conversions. Update #3117. Update #3182.
    Comment 10
    1. Sebastian Huber, Tue, 24 Oct 2017 08:21:13 GMT

    In ecef3698/rtems:

    score: Rename _Watchdog_Ticks_from_*() Rename _Watchdog_Ticks_from_*() to _Watchdog_Realtime_from_*(). This highlights that these routines are used for the CLOCK_REALTIME watchdogs (in contrast to CLOCK_MONOTONIC). Update #3117. Update #3182.
    Comment 11
    1. Sebastian Huber, Tue, 24 Oct 2017 08:21:25 GMT

    In adaf5c23/rtems:

    score: _Watchdog_Is_far_future_realtime_timespec() Update #3117. Update #3182.
    Comment 12
    1. Sebastian Huber, Tue, 24 Oct 2017 08:21:36 GMT

    In d16d07f/rtems:

    score: Add _Watchdog_Is_valid_interval_timespec() Update #3117. Update #3182.
    Comment 13
    1. Sebastian Huber, Tue, 24 Oct 2017 08:21:48 GMT

    In 7ed377b/rtems:

    score: _Watchdog_Is_far_future_monotonic_timespec Update #3117. Update #3182.
    Comment 14
    1. Sebastian Huber, Tue, 24 Oct 2017 08:22:00 GMT

    In cea5ff7/rtems:

    score: Add _Watchdog_Nanoseconds_per_tick Move it from the configuration to a separate variable. Update #3117. Update #3182.
    Comment 15
    1. Sebastian Huber, Tue, 24 Oct 2017 08:22:12 GMT

    In b13ec80/rtems:

    score: Add _Watchdog_Monotonic_from_timespec() Update #3117. Update #3182.
    Comment 16
    1. Sebastian Huber, Tue, 24 Oct 2017 08:22:24 GMT

    In 5747962/rtems:

    score: _Watchdog_Per_CPU_lazy_insert_monotonic() Update #3117. Update #3182.
    Comment 17
    1. Sebastian Huber, Tue, 24 Oct 2017 08:22:36 GMT

    In 6de1f92/rtems:

    score: Add _Thread_Continue() Update #3117. Update #3182.
    Comment 18
    1. Sebastian Huber, Tue, 24 Oct 2017 08:22:48 GMT

    In 1666ffe5/rtems:

    score: Rename function threadq support function Rename _Thread_queue_Context_set_do_nothing_enqueue_callout() into _Thread_queue_Context_set_enqueue_do_nothing_extra(). More _Thread_queue_Context_set_enqueue_*() functions will follow. Update #3117. Update #3182.
    Comment 19
    1. Sebastian Huber, Tue, 24 Oct 2017 08:23:00 GMT

    In c3105894/rtems:

    score: Move thread queue timeout handling Update #3117. Update #3182.
    Comment 20
    1. Sebastian Huber, Tue, 24 Oct 2017 08:52:31 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed
    Comment 21
    1. Sebastian Huber, Tue, 24 Oct 2017 10:20:24 GMT

    In 2fcf5aa/rtems-libbsd:

    rtems-bsd-mutex: Update due to API changes Update #3117.
    Comment 22
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 23
    1. Sebastian Huber, Thu, 22 Mar 2018 07:43:06 GMT

    In 3da2f471/rtems:

    mpci: Update due to thread queue API changes Update #3117. Update #3182.
    Comment 24
    1. Sebastian Huber, Thu, 22 Mar 2018 08:06:14 GMT

    In 7353422f/rtems:

    mpci: Fix _MPCI_Enqueue_callout() Update #3117. Update #3182.

    3121 - clock() implementation in Newlib is broken

    Link https://devel.rtems.org/ticket/3121
    Id 3121
    Reporter Sebastian Huber
    Created 6 September 2017 06:15:48
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component tool/newlib
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Newlib uses _times_r() in clock(). The problem is that the _times_r() clock frequency is defined by sysconf(_SC_CLK_TCK). The clock frequency of clock() is the constant CLOCKS_PER_SEC.

    FreeBSD uses getrusage() for clock().

    Comment 1
    1. Sebastian Huber, Thu, 07 Sep 2017 05:40:56 GMT

    In bdbf1ffa/rtems:

    Implement clock() Newlib uses _times_r() in clock(). The problem is that the _times_r() clock frequency is defined by sysconf(_SC_CLK_TCK). The clock frequency of clock() is the constant CLOCKS_PER_SEC. FreeBSD uses getrusage() for clock(). Since RTEMS has only one process, the implementation can be simplified. Update #3121.
    Comment 2
    1. Sebastian Huber, Thu, 07 Sep 2017 05:43:57 GMT
    2. owner: changed from joel.sherrill@… to Sebastian Huber
    3. status: changed from new to accepted
    4. milestone: changed from Indefinite to 4.12.0
    Comment 3
    1. Sebastian Huber, Fri, 15 Sep 2017 11:06:07 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3122 - Simplify and unify BSP_output_char

    Link https://devel.rtems.org/ticket/3122
    Id 3122
    Reporter Sebastian Huber
    Created 8 September 2017 08:37:58
    Modified 12 April 2019 12:38:25
    Owner Sebastian Huber
    Type enhancement
    Component bsps
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The BSP_output_char should output a char and not mingle with high level processing, e.g. '\n' to '\r\n' translation. Move this translation to rtems_putc(). Remove it from all the BSP_output_char implementations.

    Comment 1
    1. Sebastian Huber, Fri, 08 Sep 2017 08:38:09 GMT
    2. status: changed from assigned to accepted
    Comment 2
    1. Chris Johns, Sun, 10 Sep 2017 20:36:44 GMT

    Is this an internal RTEMS function?

    Could this change any external code that may be using it?

    What do users call to get the same thing as we currently have?

    It is a good change, I am just considering the timing late in a release development cycle.

    Comment 3
    1. Sebastian Huber, Mon, 11 Sep 2017 08:44:16 GMT

    Replying to Chris Johns:

    Is this an internal RTEMS function?

    This is the function pointer used by rtems_putc() and printk().

    Could this change any external code that may be using it?

    What do users call to get the same thing as we currently have?

    It is a good change, I am just considering the timing late in a release development cycle.

    This is not an API change. Only the "\n" to "\r\n" moves from the lowest level one step up to rtems_putc().

    Comment 4
    1. Sebastian Huber, Mon, 11 Sep 2017 08:45:15 GMT

    See also:

    ​https://lists.rtems.org/pipermail/devel/2017-September/018948.html

    Comment 5
    1. Sebastian Huber, Tue, 12 Sep 2017 08:01:16 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 1bc0ad2/rtems:

    Simplify and unify BSP_output_char The BSP_output_char should output a char and not mingle with high level processing, e.g. '\n' to '\r\n' translation. Move this translation to rtems_putc(). Remove it from all the BSP_output_char implementations. Close #3122.
    Comment 6
    1. Sebastian Huber, Tue, 12 Sep 2017 09:50:58 GMT

    In 2fc32460/rtems:

    serdbg: Fix warning Update #3122.
    Comment 7
    1. Sebastian Huber, Tue, 19 Sep 2017 05:22:01 GMT

    In a029230a/rtems:

    Add "\n" to "\r\n" translation to rtems_putc() Update #3122.
    Comment 8
    1. Sebastian Huber, Thu, 28 Sep 2017 11:22:08 GMT

    In 610ffd7/rtems:

    bsp/gen5200: Fix warning Update #3122.
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 10
    1. Sebastian Huber, Fri, 12 Apr 2019 12:38:25 GMT

    In be50969/rtems:

    bsp/motorola_powerpc: Fix debug output Update #3122.

    3123 - GDB 8.0.1 is broken on FreeBSD 11

    Link https://devel.rtems.org/ticket/3123
    Id 3123
    Reporter Sebastian Huber
    Created 8 September 2017 12:12:22
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component tool/gdb
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I tried to add the patches for 7.11, but this results in:

    --------------------------
    |--- gdb/gnulib/import/stddef.in.h.orig 2016-10-07 23:33:10.529558000 -0700
    |+++ gdb/gnulib/import/stddef.in.h 2016-10-07 23:33:23.824676000 -0700
    --------------------------
    Patching file gdb/gnulib/import/stddef.in.h using Plan A...
    Hunk #1 failed at 82.
    1 out of 1 hunks failed--saving rejects to gdb/gnulib/import/stddef.in.h.rej
    Comment 1
    1. Sebastian Huber, Fri, 08 Sep 2017 12:15:33 GMT

    The problem seems to be still in stddef.h:

    /usr/bin/c++ -O2 -pipe -fbracket-depth=1024 -I/usr/home/user/git-rtems-source-builder/rtems/build/tmp/sb-user/4.12/rtems-powerpc/opt/rtems-4.12/include
     -std=gnu++11    -I. -I../../gdb-8.0.1/gdb -I../../gdb-8.0.1/gdb/common -I../../gdb-8.0.1/gdb/config -DLOCALEDIR="\"/opt/rtems-4.12/share/locale\"" -DH
    AVE_CONFIG_H -I../../gdb-8.0.1/gdb/../include/opcode -I../../gdb-8.0.1/gdb/../opcodes/.. -I../../gdb-8.0.1/gdb/../readline/.. -I../../gdb-8.0.1/gdb/../
    zlib -I../bfd -I../../gdb-8.0.1/gdb/../bfd -I../../gdb-8.0.1/gdb/../include -I../libdecnumber -I../../gdb-8.0.1/gdb/../libdecnumber  -I../../gdb-8.0.1/
    gdb/gnulib/import -Ibuild-gnulib/import   -DTUI=1  -I/usr/home/user/git-rtems-source-builder/rtems/build/tmp/sb-user/4.12/rtems-powerpc/opt/rtems-4.12/
    include  -I/usr/local/include/python2.7 -I/usr/local/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -
    Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wformat-nonliteral  -c -o ser-u
    nix.o -MT ser-unix.o -MMD -MP -MF .deps/ser-unix.Tpo ../../gdb-8.0.1/gdb/ser-unix.c
    c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    c++: warningc++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    : treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecatedc++: warning: treating 'c' input as 'c++' when in C++ mode, this
     behavior is deprecated
    c++
    : warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]warning: unknown warning opt
    ion '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    warningwarning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    : unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-parameter'; did you mean '-Wunused-parameter'? [-Wunknown-warning-option]
    warning: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]warning: unknown warning
     option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    warning
    : unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Wunknown-warning-option]
    In file included from ../../gdb-8.0.1/gdb/rs6000-tdep.c:20:
    In file included from ../../gdb-8.0.1/gdb/defs.h:28:
    In file included from ../../gdb-8.0.1/gdb/common/common-defs.h:52:
    In file included from build-gnulib/import/stdio.h:53:
    build-gnulib/import/stddef.h:106:3: error: typedef redefinition with different types ('union max_align_t' vs 'long double')
    } max_align_t;
      ^
    /usr/include/c++/v1/stddef.h:57:21: note: previous definition is here
    typedef long double max_align_t; 
    Comment 2
    1. Joel Sherrill, Thu, 12 Oct 2017 02:49:38 GMT
    2. owner: changed from joel.sherrill@… to Sebastian Huber
    3. status: changed from new to assigned
    Comment 3
    1. Sebastian Huber, Thu, 12 Oct 2017 05:00:35 GMT
    2. status: changed from assigned to closed
    3. resolution: set to wontfix

    It works with FreeBSD 11.1. This is good enough for me.

    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3124 - Ignore pshared attribute for POSIX semaphores

    Link https://devel.rtems.org/ticket/3124
    Id 3124
    Reporter Sebastian Huber
    Created 8 September 2017 13:17:57
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Since we have only one process, sharing between processes is trivial.

    Comment 1
    1. Sebastian Huber, Thu, 14 Sep 2017 05:01:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 18b32d76/rtems:

    posix: Ignore pshared for semaphores Since we have only one process, sharing between processes is trivial. Close #3124.
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3125 - Accept PTHREAD_PROCESS_SHARED for POSIX mutexes

    Link https://devel.rtems.org/ticket/3125
    Id 3125
    Reporter Sebastian Huber
    Created 8 September 2017 13:38:57
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Since we have only one process, sharing between processes is trivial.

    Comment 1
    1. Sebastian Huber, Fri, 08 Sep 2017 13:42:33 GMT
    2. type: changed from defect to enhancement
    Comment 2
    1. Sebastian Huber, Mon, 18 Sep 2017 05:00:15 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 3b47ce7/rtems:

    posix: Allow PTHREAD_PROCESS_SHARED for mutexes Close #3125.
    Comment 3
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3126 - Accept PTHREAD_PROCESS_SHARED for POSIX barriers

    Link https://devel.rtems.org/ticket/3126
    Id 3126
    Reporter Sebastian Huber
    Created 8 September 2017 13:42:18
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Since we have only one process, sharing between processes is trivial.

    Comment 1
    1. Sebastian Huber, Mon, 18 Sep 2017 05:00:27 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 8230a329/rtems:

    posix: Allow PTHREAD_PROCESS_SHARED for barriers Close #3126.
    Comment 2
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3127 - MIPS tool build on Darwin (MacOS) fails.

    Link https://devel.rtems.org/ticket/3127
    Id 3127
    Reporter Chris Johns
    Created 9 September 2017 22:58:02
    Modified 14 October 2018 00:38:59
    Owner Chris Johns
    Type defect
    Component tool/gcc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity major
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This is the same bug that effects FreeBSD. For details see:

    ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66032 ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62097

    Comment 1
    1. Sebastian Huber, Tue, 10 Oct 2017 05:58:26 GMT
    2. component: changed from GCC to tool/gcc
    Comment 2
    1. Joel Sherrill, Thu, 12 Oct 2017 18:52:53 GMT
    2. summary: changed from MIP tool build on Darwin (MacOS) fails. to MIPS tool build on Darwin (MacOS) fails.
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 4
    1. Chris Johns, Sun, 14 Oct 2018 00:38:59 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Fixed:

    ​https://lists.rtems.org/pipermail/build/2018-October/001117.html


    3128 - RTEMS Tools corvar does not build on Windows.

    Link https://devel.rtems.org/ticket/3128
    Id 3128
    Reporter Chris Johns
    Created 10 September 2017 20:29:29
    Modified 9 November 2017 06:27:14
    Owner chrisj@…
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords RTP
    Cc  
    Blocking  
    Blocked by  

    Description

    The following error has appeared on Windows:

    In file included from ../rtemstoolkit/elftoolchain/libelf/gelf.h:34:0,
    from ../rtemstoolkit/rld-elf-types.h:29,
    from ../rtemstoolkit/rld.h:72,
    from ../rtemstoolkit/rld-process.h:31,
    from ../tester/covoar/ObjdumpProcessor.h:16,
    from ../tester/covoar/DesiredSymbols.h:18,
    from ../tester/covoar/app_common.h:6,
    from ../tester/covoar/app_common.cc:40:
    ../rtemstoolkit/elftoolchain/libelf/libelf.h:33:23: fatal error: sys/queue.h: No such file or directory
    #include
    ^
    compilation terminated.
    Waf: Leaving directory `D:/opt/rtems/rsb.git/rtems/build/rtH/rtems-tools.git/build'
    Comment 1
    1. Chris Johns, Sun, 10 Sep 2017 21:15:44 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In cb0677b/rtems-tools:

    Add Windows includes so the rtemstoolkit builds. Closes #3128.
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3129 - RTEMS Tools covoar build fails on Windows

    Link https://devel.rtems.org/ticket/3129
    Id 3129
    Reporter Chris Johns
    Created 10 September 2017 21:21:50
    Modified 5 December 2017 14:21:44
    Owner joel
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords RTP
    Cc  
    Blocking  
    Blocked by  

    Description

    The following warnings and errors are present so the RSB tools do not finish and install:

    [ 97/150] Compiling linkers/rtems-syms.cpp
    [ 98/150] Compiling linkers/rtems-rapper.cpp
    [ 99/150] Compiling linkers/rtems-exeinfo.cpp
    In file included from ../rtemstoolkit/rld-files.cpp:30:0:
    ../rtemstoolkit/rld-files.cpp: In destructor 'virtual rld::files::image::~image()':
    ../rtemstoolkit/rld.h:111:75: warning: throw will always call terminate() [-Wterminate]
    rld::error (_what, std::string (__FILE__) + ":" + to_string (__LINE__))
    ^
    ../rtemstoolkit/rld-files.cpp:256:15: note: in expansion of macro 'rld_error_at'
    throw rld_error_at ("references when destructing image");
    ^~~~~~~~~~~~
    ../rtemstoolkit/rld.h:111:75: note: in C++11 destructors default to noexcept
    rld::error (_what, std::string (__FILE__) + ":" + to_string (__LINE__))
    ^
    ../rtemstoolkit/rld-files.cpp:256:15: note: in expansion of macro 'rld_error_at'
    throw rld_error_at ("references when destructing image");
    ^~~~~~~~~~~~
    [100/150] Compiling tester/covoar/app_common.cc
    [101/150] Compiling tester/covoar/CoverageFactory.cc
    [102/150] Compiling tester/covoar/CoverageMap.cc
    [103/150] Compiling tester/covoar/CoverageMapBase.cc
    [104/150] Compiling tester/covoar/CoverageRanges.cc
    [105/150] Compiling tester/covoar/CoverageReaderBase.cc
    [106/150] Compiling tester/covoar/CoverageReaderQEMU.cc
    [107/150] Compiling tester/covoar/CoverageReaderRTEMS.cc
    [108/150] Compiling tester/covoar/CoverageReaderSkyeye.cc
    [109/150] Compiling tester/covoar/CoverageReaderTSIM.cc
    [110/150] Compiling tester/covoar/CoverageWriterBase.cc
    [111/150] Compiling tester/covoar/CoverageWriterRTEMS.cc
    [112/150] Compiling tester/covoar/CoverageWriterSkyeye.cc
    [113/150] Compiling tester/covoar/CoverageWriterTSIM.cc
    [114/150] Compiling tester/covoar/DesiredSymbols.cc
    [115/150] Compiling tester/covoar/ExecutableInfo.cc
    [116/150] Compiling tester/covoar/Explanations.cc
    [117/150] Compiling tester/covoar/GcovData.cc
    [118/150] Compiling tester/covoar/GcovFunctionData.cc
    [119/150] Compiling tester/covoar/ObjdumpProcessor.cc
    ../tester/covoar/DesiredSymbols.cc: In member function 'void Coverage::DesiredSymbols::determineSourceLines(Coverage::CoverageRanges*, Coverage::ExecutableInfo*)':
    ../tester/covoar/DesiredSymbols.cc:517:36: error: 'realpath' was not declared in this scope
    realpath( inputBuffer, rpath );
    ^
    Waf: Leaving directory `D:/opt/rtems/rtems-tools.git/build'
    Build failed
    -> task in 'ccovoar' failed with exit status 1 (run with -v to display more information)
    Comment 1
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 2
    1. Joel Sherrill, Tue, 05 Dec 2017 14:21:44 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    This must have been fixed since the ticket was filed. It builds now. There are warnings but that's a different issue.


    3130 - RTEMS Doxygen.in latex output does not build

    Link https://devel.rtems.org/ticket/3130
    Id 3130
    Reporter Chris Johns
    Created 10 September 2017 22:01:32
    Modified 9 November 2017 06:27:14
    Owner chrisj@…
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity critical
    Keywords doxygen
    Cc  
    Blocking  
    Blocked by  

    Description

    Doxygen latex output on sync.rtems.org does not build.

    Does latex output build on any host? If so which hosts and what tool combination.

    If it does not build we should consider defaulting the setting for latex output to "no".

    Comment 1
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 2
    1. Chris Johns, Thu, 12 Oct 2017 15:49:54 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In addeb53a/rtems:

    doxygen: Set the Latex generation default to NO. Closes #3130.
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3132 - Add reference counting to file descriptors

    Link https://devel.rtems.org/ticket/3132
    Id 3132
    Reporter Sebastian Huber
    Created 13 September 2017 05:56:39
    Modified 15 November 2017 12:25:56
    Owner Sebastian Huber
    Type enhancement
    Component fs
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The use of a file descriptor after or during a close() operation may result in a ​use after free. Finding such errors in applications is difficult. Especially in SMP systems using the highly dynamic libbsd network stack.

    The file descriptor objects reside in a table with a application configuration defined size. So, the storage of a file descriptor object is always present, only the referenced file system node may change over time. The file system nodes may use an internal reference counting, which is independent of the file descriptors.

    To implement reference counting for the file descriptors add a bit field for the reference count to the rtems_libio_t::flags and use atomic operations to maintain the flags.

    Each operation using a file descriptor should perform a sequence like this:

    int op( int fd, ... )
    {
    rtems_libio_t *iop;
    unsigned int flags;
    if ( (uint32_t) fd >= rtems_libio_number_iops ) {
    rtems_set_errno_and_return_minus_one( EBADF );
    }
    iop = rtems_libio_iop( fd );
    flags = rtems_libio_iop_hold( iop );
    if ( ( flags & LIBIO_FLAGS_OPEN ) == 0 ) {
    rtems_libio_iop_drop( _iop );
    rtems_set_errno_and_return_minus_one( EBADF );
    }
    do_op( iop, ... );
    rtems_libio_iop_drop( iop );
    return 0;
    }

    A close() should return -1 with EBUSY in case the file descriptor is referenced. In this case, no close operation will be performed.

    Comment 1
    1. Sebastian Huber, Wed, 13 Sep 2017 05:56:49 GMT
    2. status: changed from assigned to accepted
    Comment 2
    1. Sebastian Huber, Thu, 14 Sep 2017 05:03:35 GMT

    In ead1281f/rtems:

    bsp/mrm332: Remove dead code Update #3132.
    Comment 3
    1. Sebastian Huber, Thu, 14 Sep 2017 06:36:11 GMT
    2. description: modified (diff)
    Comment 4
    1. Sebastian Huber, Fri, 15 Sep 2017 08:58:46 GMT

    In 7b45202/rtems:

    libio: Simplify rtems_libio_iop() Remove the file descriptor validation. This is the job of rtems_libio_check_fd(). Use an inline function instread of a macro. Update #3132.
    Comment 5
    1. Sebastian Huber, Fri, 15 Sep 2017 08:58:57 GMT

    In 4b759b1/rtems:

    libio: Avoid direct use of rtems_libio_iops Update #3132.
    Comment 6
    1. Sebastian Huber, Fri, 15 Sep 2017 08:59:09 GMT

    In 0169e90/rtems:

    libio: Do simple parameter checks early This simplifies error handling later. Update #3132.
    Comment 7
    1. Sebastian Huber, Fri, 15 Sep 2017 08:59:20 GMT

    In 48dbb6cf/rtems:

    libio: Remove rtems_libio_check_permissions() Remove rtems_libio_check_permissions() and convert single user to rtems_libio_check_permissions_with_error(). Update #3132.
    Comment 8
    1. Sebastian Huber, Fri, 15 Sep 2017 08:59:32 GMT

    In ec10d26/rtems:

    libio: rtems_libio_check_permissions_with_error() Rename rtems_libio_check_permissions_with_error() in rtems_libio_check_permissions(). Update #3132.
    Comment 9
    1. Sebastian Huber, Fri, 15 Sep 2017 08:59:43 GMT

    In 856ede4f/rtems:

    libio: Add iop set/clear flags Update #3132.
    Comment 10
    1. Sebastian Huber, Fri, 15 Sep 2017 08:59:56 GMT

    In ca90c6c/rtems:

    libio: Add rtems_libio_iop_flags_initialize() Update #3132.
    Comment 11
    1. Sebastian Huber, Fri, 15 Sep 2017 09:00:08 GMT

    In e2b1db23/rtems:

    libio: Add rtems_libio_iop_flags() Update #3132.
    Comment 12
    1. Sebastian Huber, Fri, 15 Sep 2017 09:00:20 GMT

    In bbcdc302/rtems:

    libio: Add rtems_libio_iop_is_no_delay() Update #3132.
    Comment 13
    1. Sebastian Huber, Fri, 15 Sep 2017 09:00:32 GMT

    In a937a5a/rtems:

    libio: Add rtems_libio_iop_is_readable() Update #3132.
    Comment 14
    1. Sebastian Huber, Fri, 15 Sep 2017 09:00:45 GMT

    In 3cffd66d/rtems:

    libio: Add rtems_libio_iop_is_writeable() Update #3132.
    Comment 15
    1. Sebastian Huber, Fri, 15 Sep 2017 09:00:57 GMT

    In d4c5441/rtems:

    libio: Add rtems_libio_iop_is_append() Update #3132.
    Comment 16
    1. Sebastian Huber, Fri, 15 Sep 2017 09:01:09 GMT

    In 9012db8/rtems:

    libio: LIBIO_GET_IOP() LIBIO_GET_IOP_WITH_ACCESS() Replace rtems_libio_check_fd(), rtems_libio_iop(), rtems_libio_check_open() and rtems_libio_check_permissions() combinations with new LIBIO_GET_IOP() and LIBIO_GET_IOP_WITH_ACCESS() macros. Update #3132.
    Comment 17
    1. Sebastian Huber, Fri, 15 Sep 2017 09:01:20 GMT

    In 98041b68/rtems:

    libio: Unify readv() and writev() Update #3132.
    Comment 18
    1. Sebastian Huber, Fri, 15 Sep 2017 09:01:32 GMT

    In baef823c/rtems:

    libio: Add hold/drop iop reference Check iop reference count in close() and return -1 with errno set to EBUSY in case the file descriptor is still in use. Update #3132.
    Comment 19
    1. Sebastian Huber, Fri, 15 Sep 2017 10:49:57 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 894c965/rtems-libbsd:

    Support reference counting for file descriptors Close #3132.
    Comment 20
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 21
    1. Sebastian Huber, Wed, 15 Nov 2017 12:23:13 GMT

    In d4b99ae/rtems:

    libio: Add assert to rtems_libio_iop_drop() This assert helps to detect an invalid reference counting in RTEMS_DEBUG configurations. Update #3132.
    Comment 22
    1. Sebastian Huber, Wed, 15 Nov 2017 12:25:56 GMT

    In b03a1c0/rtems-libbsd:

    Fix file descriptor reference counting in accept() Update #3132.

    3133 - Remove rtems_libio_t::driver

    Link https://devel.rtems.org/ticket/3133
    Id 3133
    Reporter Sebastian Huber
    Created 13 September 2017 07:16:36
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component fs
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove unused rtems_libio_t::driver member.

    Comment 1
    1. Sebastian Huber, Mon, 18 Sep 2017 05:00:02 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 8fa75d3/rtems:

    libio: Remove rtems_libio_t::driver This member was apparently unused. Close #3133.
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3134 - Remove LIBIO_FLAGS_CREATE

    Link https://devel.rtems.org/ticket/3134
    Id 3134
    Reporter Sebastian Huber
    Created 13 September 2017 08:49:10
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component fs
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove unused LIBIO_FLAGS_CREATE flag.

    Comment 1
    1. Sebastian Huber, Thu, 14 Sep 2017 05:10:53 GMT

    The LIBIO_FLAGS_CREATE is actually used in one place via rtems_libio_to_fcntl_flags() for fcntl(fd, F_GETFL). However, POSIX mandates that only access and status flags are returned.

    ​http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html

    Status flags are defined here:

    ​http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fcntl.h.html

    Comment 2
    1. Sebastian Huber, Fri, 15 Sep 2017 08:58:34 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 5eb67f3/rtems:

    libio: Remove LIBIO_FLAGS_CREATE Close #3134.
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3135 - Devel mailing list doesn't work and Git push impossible due to disk full

    Link https://devel.rtems.org/ticket/3135
    Id 3135
    Reporter Sebastian Huber
    Created 13 September 2017 13:42:24
    Modified 9 November 2017 06:27:14
    Owner amar@…
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I got this:

    git push
    Counting objects: 18, done.
    Delta compression using up to 12 threads.
    Compressing objects: 100% (17/17), done.
    Writing objects: 100% (18/18), 1.68 KiB | 0 bytes/s, done.
    Total 18 (delta 16), reused 0 (delta 0)
    remote: error: file write error (No space left on device)
    remote: fatal: unable to write sha1 file
    error: remote unpack failed: unpack-objects abnormal exit
    To ssh://dispatch.rtems.org/data/git/rtems.git
    ! [remote rejected] upstream -> master (unpacker error)
    error: failed to push some refs to 'ssh://sebh@dispatch.rtems.org/data/git/rtems.git'

    We have on dispatch.rtems.org:

    Filesystem        Size    Used   Avail Capacity  Mounted on
    /dev/gpt/root0 88G 82G -600M 101% /
    Comment 1
    1. Amar Takhar, Wed, 13 Sep 2017 23:14:10 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    This was fixed some time ago sorry about that. I am working on setting up realtime monitoring and Ansible it's a lot of work.

    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3136 - Use FIFO for file descriptor free list

    Link https://devel.rtems.org/ticket/3136
    Id 3136
    Reporter Sebastian Huber
    Created 15 September 2017 05:39:25
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component fs
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Currently, the free list of file descriptors is organized as a LIFO. In erroneous systems which use a file descriptor after a call to close(), this increases the likelihood that this error is undetected due to the prompt re-use of the file descriptor. The use of a FIFO has the benefit that free file descriptors remain on the free list as long as possible. This increases the time frame in which an invalid use of a closed file descriptor returns an error status.

    Comment 1
    1. Sebastian Huber, Fri, 15 Sep 2017 09:01:44 GMT

    In ac74162/rtems:

    libio: Use FIFO for iop free list Update #3136.
    Comment 2
    1. Sebastian Huber, Fri, 15 Sep 2017 10:50:09 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3137 - Accept PTHREAD_PROCESS_SHARED for POSIX condition variables

    Link https://devel.rtems.org/ticket/3137
    Id 3137
    Reporter Sebastian Huber
    Created 15 September 2017 11:30:59
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Since we have only one process, sharing between processes is trivial.

    Comment 1
    1. Sebastian Huber, Mon, 18 Sep 2017 05:00:39 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In c030edd/rtems:

    posix: Allow PTHREAD_PROCESS_SHARED for condvar Close #3137.
    Comment 2
    1. Joel Sherrill, Mon, 18 Sep 2017 05:02:17 GMT

    Please check the docs for any impact.

    Comment 3
    1. Sebastian Huber, Mon, 18 Sep 2017 05:06:08 GMT

    I didn't find anything in the documentation.

    Comment 4
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3139 - Remove old ISR parameter from Clock_driver_support_install_isr() and make it optional

    Link https://devel.rtems.org/ticket/3139
    Id 3139
    Reporter Sebastian Huber
    Created 18 September 2017 06:02:15
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component bsps
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The old ISR is not used by the clock driver shell.

    Comment 1
    1. Sebastian Huber, Mon, 18 Sep 2017 06:30:51 GMT

    In f3b29236/rtems:

    bsps: Clock_driver_support_install_isr() Remove old ISR parameter since is not used by the clock driver shell. Make an implementation optional. Update #3139.
    Comment 2
    1. Sebastian Huber, Mon, 18 Sep 2017 06:31:19 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 27515ec/rtems-docs:

    bsp-howto: Clock_driver_support_install_isr() Close #3139.
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3140 - CPU Kit broken with --enable-rtems-debug

    Link https://devel.rtems.org/ticket/3140
    Id 3140
    Reporter Chris Johns
    Created 18 September 2017 22:53:25
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Building with:

    ..../rtems.git/configure --target=arm-rtems4.12 --prefix=/opt/work/chris/rtems/kernel/4.12 --disable-networking --enable-rtemsbsp=beagleboneblack --enable-maintainer-mode --enable-rtems-debug 

    results in an error:

    gmake[5]: Entering directory '/opt/work/chris/rtems/kernel/bsps/beagleboneblack/arm-rtems4.12/c/beagleboneblack/cpukit/score'
    arm-rtems4.12-gcc --pipe -DHAVE_CONFIG_H -I.. -I../../cpukit/../../../beagleboneblack/lib/include -mcpu=cortex-a8 -O2 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT src/libscore_a-semaphore.o -MD -MP -MF src/.deps/libscore_a-semaphore.Tpo -c -o src/libscore_a-semaphore.o `test -f 'src/semaphore.c' || echo '/opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/score/'`src/semaphore.c
    In file included from /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/score/src/semaphore.c:21:0:
    /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/score/src/semaphore.c: In function '_Semaphore_Post':
    /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/score/src/semaphore.c:134:27: error: 'UINT_MAX' undeclared (first use in this function); did you mean 'UINT8_MAX'?
    _Assert( sem->count < UINT_MAX );
    ^
    ../../cpukit/../../../beagleboneblack/lib/include/rtems/score/assert.h:67:12: note: in definition of macro '_Assert'
    ( ( _e ) ? \
    ^~
    /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/score/src/semaphore.c:134:27: note: each undeclared identifier is reported only once for each function it appears in
    _Assert( sem->count < UINT_MAX );
    ^
    ../../cpukit/../../../beagleboneblack/lib/include/rtems/score/assert.h:67:12: note: in definition of macro '_Assert'
    ( ( _e ) ? \
    ^~
    gmake[5]: *** [Makefile:4571: src/libscore_a-semaphore.o] Error 1

    We need the rtems-bsp-builder to be run on a regular basis to catch these errors.

    Tools are:

    $ /opt/work/rtems/4.12/bin/arm-rtems4.12-gcc --version
    arm-rtems4.12-gcc (GCC) 7.2.0 20170814 (RTEMS 4.12, RSB e6d0a8bae6d16eba605370ca11a5928b797820bb-modified, Newlib 2.5.0.20170818)
    Comment 1
    1. Chris Johns, Mon, 18 Sep 2017 22:55:24 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Tue, 19 Sep 2017 08:57:49 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 9a50e32/rtems:

    score: Include missing Update #2132. Close #3140.
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3141 - Change the BSP Howto's name to something smaller.

    Link https://devel.rtems.org/ticket/3141
    Id 3141
    Reporter Chris Johns
    Created 18 September 2017 23:05:20
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type task
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The BSP Howto's current name is:

    __RTEMS BSP and Device Driver Development Guide__

    This is long and causes problems in the PDF output. Change the name to:

    __RTEMS BSP and Driver Guide__

    Comment 1
    1. Sebastian Huber, Tue, 10 Oct 2017 06:06:29 GMT
    2. component: changed from Documentation to doc
    Comment 2
    1. Joel Sherrill, Thu, 12 Oct 2017 23:53:55 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In c6f8e51/rtems-docs:

    Shorten the name of the BSP and Device Driver Development Guide Old name:
    RTEMS BSP and Device Driver Development Guide
    This is long and causes problems in the PDF output. This patch changes the name to:
    RTEMS BSP and Driver Guide
    Closes #3141.
    Comment 3
    1. Joel Sherrill, Fri, 13 Oct 2017 00:04:38 GMT

    In 13a15f9/rtems-docs:

    Shorten BSP and Driver Guide name (missed commit) Updates #3141.
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3142 - POSIX: Reduce size of pthread_once_t and make it zero-initialized

    Link https://devel.rtems.org/ticket/3142
    Id 3142
    Reporter Sebastian Huber
    Created 19 September 2017 11:17:59
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    A zero-initialized pthread_once_t reduces the ROM usage of RTEMS applications, since the global pthread_once_t objects may reside in the BSS section.

    Comment 1
    1. Sebastian Huber, Tue, 19 Sep 2017 11:18:05 GMT
    2. status: changed from assigned to accepted
    Comment 2
    1. Sebastian Huber, Tue, 19 Sep 2017 11:18:34 GMT
    2. summary: changed from POSIX: Reduce size of pthread_once_t and make it llow zero-initialized to POSIX: Reduce size of pthread_once_t and make it zero-initialized
    Comment 3
    1. Sebastian Huber, Thu, 05 Oct 2017 12:36:06 GMT

    In 47b1e31/rtems:

    posix: Optimize pthread_once_t Reduce size of pthread_once_t and make it zero-initialized. Update #3142.
    Comment 4
    1. Sebastian Huber, Fri, 06 Oct 2017 12:48:57 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    Fixed with latest RSB.

    Comment 5
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3148 - PSXRDWRV Test failure on Beaglebone Black

    Link https://devel.rtems.org/ticket/3148
    Id 3148
    Reporter Chris Johns
    Created 21 September 2017 06:44:13
    Modified 9 November 2017 06:27:14
    Owner joel.sherrill@…
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords Beaglebone
    Cc  
    Blocking  
    Blocked by  

    Description

    Running rtems-test with a recent u-boot and a current master this failure is reported:

    ] RTEMS Beagleboard: am335x-based
    ]
    ]
    ] *** BEGIN OF TEST PSXRDWRV ***
    ] writev bad file descriptor -- EBADF
    ] writev error 1: 22=Invalid argument
    ] Error during error test!!!!
    Comment 1
    1. Joel Sherrill, Thu, 21 Sep 2017 15:15:38 GMT

    Works on erc32 Fails on jmr3904, psim, and xilinx_zynq_a9_qemu

    Tracked down to needing a memset on a stack variable "vec" which was an IO vector. Apparently depending on the BSP, the variable was zero or not. Patch to follow

    Comment 2
    1. Joel Sherrill, Thu, 21 Sep 2017 15:17:28 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 714cb06/rtems:

    psxrdwrv/test.c: Clear iovec to ensure consistent results closes #3148.
    Comment 3
    1. Sebastian Huber, Thu, 05 Oct 2017 08:30:10 GMT
    2. milestone: changed from Indefinite to 4.12.0
    Comment 4
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3152 - Beaglebone Black crashes on u-boot master build.

    Link https://devel.rtems.org/ticket/3152
    Id 3152
    Reporter Chris Johns
    Created 22 September 2017 05:27:55
    Modified 14 October 2018 00:42:04
    Owner Chris Johns
    Type defect
    Component arch/arm
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords Beaglebone u-boot
    Cc  
    Blocking  
    Blocked by  

    Description

    The crash with a Linux type image and no FDT is:

    ] ## Booting kernel from Legacy Image at 82000000 ...
    ] Image Name: RTEMS
    ] Image Type: ARM Linux Kernel Image (gzip compressed)
    ] Data Size: 60886 Bytes = 59.5 KiB
    ] Load Address: 80000000
    ] Entry Point: 80000000
    ] Verifying Checksum ... OK
    ] Uncompressing Kernel Image ... OK
    ]
    ] Starting kernel ...
    ]
    ] data abort
    ]
    ] MAYBE you should read doc/README.arm-unaligned-accesses
    ]
    ] pc : [<8000010c>] lr : [<800000ac>]
    ] sp : 80101000 ip : 0000000c fp : 9f35ac28
    ] r10: 9f3ad0f4 r9 : 00000000 r8 : 9f238f40
    ] r7 : 00000000 r6 : 80000100 r5 : 00000e05 r4 : 60000193
    ] r3 : 9f238fe0 r2 : 80000100 r1 : 00000e05 r0 : 60000193
    ] Flags: nzcv IRQs off FIQs on Mode SVC_32
    ] Resetting CPU ...

    and the code is:

    BSP_START_TEXT_SECTION void bsp_start_hook_0(void)
    {
    }
    80000104: e12fff1e bx lr
    80000108 :
    BSP_START_TEXT_SECTION static inline arm_a8core_start_set_vector_base(void)
    {
    /*
    * Do not use bsp_vector_table_begin == 0, since this will get optimized away.
    */
    if (bsp_vector_table_end != bsp_vector_table_size) {
    80000108: e3002040 movw r2, #64 ; 0x40
    8000010c: e3003040 movw r3, #64 ; 0x40
    80000110: e3482000 movt r2, #32768 ; 0x8000
    80000114: e3403000 movt r3, #0
    80000118: e1520003 cmp r2, r3
    Comment 1
    1. Chris Johns, Fri, 22 Sep 2017 08:12:37 GMT

    My u-boot is the original one that comes with the board. I am working out how to get a new one to boot from an SD Card

    Comment 2
    1. Chris Johns, Mon, 25 Sep 2017 03:45:39 GMT

    The SD card requires you position the SPL (MLO) and u-boot image in specific locations to boot:

    dd if=MLO        of=sdcard.img count=1 seek=1 conv=notrunc bs=128k
    dd if=u-boot.img of=sdcard.img count=2 seek=1 conv=notrunc bs=384k 

    The SD card can be formatted with anything.

    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:54:12 GMT
    2. component: changed from bsps to arch/arm
    Comment 4
    1. Joel Sherrill, Wed, 11 Oct 2017 23:11:19 GMT
    2. owner: changed from joel.sherrill@… to Chris Johns
    3. status: changed from new to assigned
    4. summary: changed from Beaglbone Black crashes on u-boot master build. to Beaglebone Black crashes on u-boot master build.
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 6
    1. Joel Sherrill, Sun, 14 Oct 2018 00:42:04 GMT
    2. status: changed from assigned to closed
    3. resolution: set to wontfix

    There is a work around. If broken again, someone can reopen or file a new ticket.


    3153 - Accept PTHREAD_PROCESS_SHARED for POSIX rwlocks

    Link https://devel.rtems.org/ticket/3153
    Id 3153
    Reporter Sebastian Huber
    Created 22 September 2017 06:13:58
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Since we have only one process, sharing between processes is trivial.

    Comment 1
    1. Sebastian Huber, Fri, 22 Sep 2017 06:46:59 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In bdc468a/rtems:

    posix: Allow PTHREAD_PROCESS_SHARED for rwlocks Close #3153.
    Comment 2
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3157 - PowerPC tools don't build on 32-bit hosts

    Link https://devel.rtems.org/ticket/3157
    Id 3157
    Reporter Jeff Mayes
    Created 29 September 2017 20:31:32
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Using RSB and trying to build PowerPC.
    Updated RSB just a few days ago.
    i386 and arm build successfully, but PowerPC fails.

    configure:3662: checking for suffix of object files
    configure:3684: /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/./gcc/xgcc -B/opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/./gcc/ -nostdinc -B/opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/powerpc-rtems4.12/me6500/m64/newlib/ -isystem /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/powerpc-rtems4.12/me6500/m64/newlib/targ-include -isystem /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/gcc-7.2.0/newlib/libc/include -B/desk/rtems/powerpc-rtems4.12/bin/ -B/desk/rtems/powerpc-rtems4.12/lib/ -isystem /desk/rtems/powerpc-rtems4.12/include -isystem /desk/rtems/powerpc-rtems4.12/sys-include -mcpu=e6500 -m64 -c -g -O2 conftest.c >&5
    Assembler messages:
    Fatal error: -a64 unsupported
    configure:3688: $? = 1
    configure: failed program was:
    | /* confdefs.h */
    | #define PACKAGE_NAME "GNU C Runtime Library"
    | #define PACKAGE_TARNAME "libgcc"
    | #define PACKAGE_VERSION "1.0"
    | #define PACKAGE_STRING "GNU C Runtime Library 1.0"
    | #define PACKAGE_BUGREPORT ""
    | #define PACKAGE_URL "​http://www.gnu.org/software/libgcc/"
    | /* end confdefs.h. */
    |
    | int
    | main ()
    | {
    |
    | ;
    | return 0;
    | }
    configure:3702: error: in `/opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/powerpc-rtems4.12/me6500/m64/libgcc':
    configure:3705: error: cannot compute suffix of object files: cannot compile

    Comment 1
    1. Jeff Mayes, Fri, 29 Sep 2017 20:32:06 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Fri, 29 Sep 2017 20:55:48 GMT
    2. summary: changed from PowerPC tools doesn't build to PowerPC tools don't build

    I have built the tools on two CentOS 7 computers. Jeff was on Cygwin and has successfully built both arm and x86.

    Comment 3
    1. Sebastian Huber, Sat, 30 Sep 2017 07:20:20 GMT

    Please make sure that no previous RTEMS tools are in your $PATH before the build, e.g. delete the previous installation and try it again.

    Comment 4
    1. Sebastian Huber, Sat, 30 Sep 2017 07:25:02 GMT
    2. status: changed from assigned to closed
    3. resolution: set to duplicate

    Duplicate of #2540.

    Comment 5
    1. Jeff Mayes, Wed, 04 Oct 2017 19:48:34 GMT
    2. status: changed from closed to reopened
    3. resolution: duplicate deleted

    OK. There are no RTEMS tools in my path. I deleted the build folder in my working dir and tried again. I also changed the #PREFIX to use a different directory. It still fails with the same error as reported.

    Any other ideas? Thanks

    Comment 6
    1. Jeff Mayes, Wed, 04 Oct 2017 19:55:52 GMT

    Joel had the idea to see what verbose gcc output showed. This shows the as version used (2.29).

    We have checked and my RSB is up to date. Is there any chance 64-bit PowerPC support is disabled in binutils on Cygwin?

    + /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/./gcc/xgcc -B/opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/./gcc/ -nostdinc -B/opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/powerpc-rtems4.12/me6500/m64/newlib/ -isystem /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/powerpc-rtems4.12/me6500/m64/newlib/targ-include -isystem /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/gcc-7.2.0/newlib/libc/include -B/desk/rtems/powerpc/powerpc-rtems4.12/bin/ -B/desk/rtems/powerpc/powerpc-rtems4.12/lib/ -isystem /desk/rtems/powerpc/powerpc-rtems4.12/include -isystem /desk/rtems/powerpc/powerpc-rtems4.12/sys-include -mcpu=e6500 -m64 -c -g -v -O2 conftest.c
    Reading specs from /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/./gcc/specs
    COLLECT_GCC=/opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/./gcc/xgcc
    Target: powerpc-rtems4.12
    Configured with: ../gcc-7.2.0/configure --prefix=/desk/rtems/powerpc --bindir=/desk/rtems/powerpc/bin --exec_prefix=/desk/rtems/powerpc --includedir=/desk/rtems/powerpc/include --libdir=/desk/rtems/powerpc/lib --libexecdir=/desk/rtems/powerpc/libexec --mandir=/desk/rtems/powerpc/share/man --infodir=/desk/rtems/powerpc/share/info --datadir=/desk/rtems/powerpc/share --build=i686-pc-cygwin --host=i686-pc-cygwin --target=powerpc-rtems4.12 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --disable-lto --enable-newlib-io-c99-formats --enable-newlib-iconv --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258 --enable-threads --disable-plugin --enable-libgomp --enable-languages=c,c++
    Thread model: rtems
    gcc version 7.2.0 20170814 (RTEMS 4.12, RSB 55f2d69e9b67cde23d61375fa34ef5b0f04a985d, Newlib 2.5.0.20170818) (GCC)
    COLLECT_GCC_OPTIONS='-B' '/opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/./gcc/' '-nostdinc' '-B' '/opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/powerpc-rtems4.12/me6500/m64/newlib/' '-isystem' '/opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/powerpc-rtems4.12/me6500/m64/newlib/targ-include' '-isystem' '/opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/gcc-7.2.0/newlib/libc/include' '-B' '/desk/rtems/powerpc/powerpc-rtems4.12/bin/' '-B' '/desk/rtems/powerpc/powerpc-rtems4.12/lib/' '-isystem' '/desk/rtems/powerpc/powerpc-rtems4.12/include' '-isystem' '/desk/rtems/powerpc/powerpc-rtems4.12/sys-include' '-mcpu=e6500' '-m64' '-c' '-g' '-v' '-O2'
     /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/./gcc/cc1.exe -quiet -nostdinc -v -imultilib me6500/m64 -iprefix /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/gcc/../lib/gcc/powerpc-rtems4.12/7.2.0/ -isystem /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/./gcc/include -isystem /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/./gcc/include-fixed -D__PPC_CPU_E6500__ -isystem /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/powerpc-rtems4.12/me6500/m64/newlib/targ-include -isystem /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/gcc-7.2.0/newlib/libc/include -isystem /desk/rtems/powerpc/powerpc-rtems4.12/include -isystem /desk/rtems/powerpc/powerpc-rtems4.12/sys-include conftest.c -quiet -dumpbase conftest.c -mcpu=e6500 -m64 -auxbase conftest -g -O2 -version -o /tmp/ccRXH4mo.s
    GNU C11 (GCC) version 7.2.0 20170814 (RTEMS 4.12, RSB 55f2d69e9b67cde23d61375fa34ef5b0f04a985d, Newlib 2.5.0.20170818) (powerpc-rtems4.12)
        compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version none
    GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
    ignoring nonexistent directory "/opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/powerpc-rtems4.12/me6500/m64/newlib/targ-include"
    ignoring nonexistent directory "/desk/rtems/powerpc/powerpc-rtems4.12/include"
    ignoring nonexistent directory "/desk/rtems/powerpc/powerpc-rtems4.12/sys-include"
    `#include "..." search starts here:`
    `#include <...> search starts here:`
     /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/./gcc/include
     /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/./gcc/include-fixed
     /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/gcc-7.2.0/newlib/libc/include
    End of search list.
    GNU C11 (GCC) version 7.2.0 20170814 (RTEMS 4.12, RSB 55f2d69e9b67cde23d61375fa34ef5b0f04a985d, Newlib 2.5.0.20170818) (powerpc-rtems4.12)
        compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version none
    GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
    Compiler executable checksum: c400f821a881560be7012bb91d375b83
    COLLECT_GCC_OPTIONS='-B' '/opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/./gcc/' '-nostdinc' '-B' '/opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/powerpc-rtems4.12/me6500/m64/newlib/' '-isystem' '/opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/powerpc-rtems4.12/me6500/m64/newlib/targ-include' '-isystem' '/opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/gcc-7.2.0/newlib/libc/include' '-B' '/desk/rtems/powerpc/powerpc-rtems4.12/bin/' '-B' '/desk/rtems/powerpc/powerpc-rtems4.12/lib/' '-isystem' '/desk/rtems/powerpc/powerpc-rtems4.12/include' '-isystem' '/desk/rtems/powerpc/powerpc-rtems4.12/sys-include' '-mcpu=e6500' '-m64' '-c' '-g' '-v' '-O2'
     /opt/rtems-tools/rsb/rtems/build/powerpc-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170818-i686-pc-cygwin-1/build/./gcc/as -v -a64 -me6500 -many -mbig -o conftest.o /tmp/ccRXH4mo.s
    GNU assembler version 2.29 (powerpc-rtems4.12) using BFD version (GNU Binutils) 2.29
    Assembler messages:
    Fatal error: -a64 unsupported 
    Comment 7
    1. Chris Johns, Wed, 04 Oct 2017 23:45:27 GMT

    The error is happening in as and it would appear the PPC as does not support 64bit options. Does an as Linux build of the PPC support the -a64 option? Hint, use -save-temp to get a .s file and shift it to Linux and try.

    I would compare the full build logs for a Linux build and a Cygwin build paying extra attention to the assembler configure and build. I would try and locate a PowerPC 64bit assembler file in the as source and see if it is build on Linux and Cygwin.

    Comment 8
    1. Sebastian Huber, Thu, 05 Oct 2017 06:53:10 GMT

    The BFD configuration is in Binutils bfd/config.bfd:

     powerpc-*-*bsd* | powerpc-*-elf* | powerpc-*-sysv4* | powerpc-*-eabi* | \
      powerpc-*-solaris2* | powerpc-*-linux-* | powerpc-*-rtems* | \
      powerpc-*-chorus*)
        targ_defvec=powerpc_elf32_vec
        targ_selvecs="rs6000_xcoff_vec powerpc_elf32_le_vec powerpc_boot_vec"
        targ64_selvecs="powerpc_elf64_vec powerpc_elf64_le_vec"
        ;; 

    Looks like some Cygwin-specific build problem to me.

    Comment 9
    1. Jeff Mayes, Tue, 10 Oct 2017 22:53:01 GMT

    With Joel's help, I got it to build today. Here are the changes we made:

    jeff@Win7-VM /opt/rtems-tools/rsb/rtems
    $ git diff config/tools/rtems-binutils-2.29-1.cfg
    diff --git a/rtems/config/tools/rtems-binutils-2.29-1.cfg b/rtems/config/tools/rtems-binutils-2.29-1.cfg
    index 6941ebb..87580f8 100644
    --- a/rtems/config/tools/rtems-binutils-2.29-1.cfg
    +++ b/rtems/config/tools/rtems-binutils-2.29-1.cfg
    @@ -20,6 +20,11 @@
     %define with_deterministic_archives 1
     #
    +# Enable 64-bit BFD support
    +#
    +%define with_64_bit_bfd 1
    +
    +#
     # The binutils build instructions. We use 2.xx Release 1.
     #
     %include %{_configdir}/binutils-2-1.cfg
    jeff@Win7-VM /opt/rtems-tools/rsb/rtems
    $ git diff ../source-builder/config/binutils-2-1.cfg
    diff --git a/source-builder/config/binutils-2-1.cfg b/source-builder/config/binutils-2-1.cfg
    index 539f076..0b4101d 100644
    --- a/source-builder/config/binutils-2-1.cfg
    +++ b/source-builder/config/binutils-2-1.cfg
    @@ -70,6 +70,7 @@ BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
         --target=%{_target} \
         --verbose --disable-nls \
         %{?with_deterministic_archives:--enable-deterministic-archives} \
    +    %{?with_64_bit_bfd:--enable-64-bit-bfd} \
         %{?with_gold:--enable-gold=yes} \
         %{?with_lto:--enable-lto --enable-plugins}%{!?with_lto:--disable-lto} \
         --without-included-gettext \ 
    Comment 10
    1. Chris Johns, Wed, 11 Oct 2017 10:21:20 GMT

    Please correct the ticket and:

    Assign ownership to Joel. Set a milestone Add binutils PowerPC 64bit to the tags

    Thanks

    What hosts have you tested?

    Comment 11
    1. Joel Sherrill, Wed, 11 Oct 2017 10:33:42 GMT
    2. owner: changed from Sebastian Huber to Joel Sherrill
    3. status: changed from reopened to assigned
    4. milestone: set to 4.12.0

    No other hosts have been tested. We were happy it worked on Cygwin. If you are ok with the patch, we can test it elsewhere.

    Comment 12
    1. Chris Johns, Wed, 11 Oct 2017 11:32:44 GMT

    Replying to Joel Sherrill:

    No other hosts have been tested. We were happy it worked on Cygwin. If you are ok with the patch, we can test it elsewhere.

    Patch looks fine with a minor change in the commit to say Enable 64-bit BFD support. Needed on 32bit hosts.. We just need to make sure other hosts are not broken.

    Comment 13
    1. Joel Sherrill, Wed, 11 Oct 2017 12:13:05 GMT

    Testing now on CentOS 7 and Fedora 26 which are 64-bit hosts.

    Following up on a comment from Sebastian that I missed. This is not Cygwin specific. It is an issue on all 32-bit hosts. The bfd magic silently disables 64-bit BFD on 32-bit hosts unless you specify --enable-64-bit-bfd. I have not checked yet if sparc64 or aarch64 will build on 32-bit Cygwin. They may need this option also. I will ask Jeff to check if they build. They may need this option also.

    Comment 14
    1. Jeff Mayes, Wed, 11 Oct 2017 20:24:31 GMT

    Just tested aarch64 and sparc64 with the fixed files, and they both build just fine.

    Comment 15
    1. Joel Sherrill, Wed, 11 Oct 2017 23:57:25 GMT
    2. summary: changed from PowerPC tools don't build to PowerPC tools don't build on 32-bit hosts
    Comment 16
    1. Joel Sherrill, Thu, 12 Oct 2017 02:18:45 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In c4b6bf0/rtems-source-builder:

    Enable 64-bit BFD support. Needed on 32bit hosts Closes #3157.
    Comment 17
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3158 - Examples v2 does not build

    Link https://devel.rtems.org/ticket/3158
    Id 3158
    Reporter Chris Johns
    Created 1 October 2017 00:20:09
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity major
    Keywords examples
    Cc  
    Blocking  
    Blocked by  

    Description

    Updating waf breaks the rootfs. Add rootfs support to rtems-waf.git.

    Comment 1
    1. Chris Johns, Mon, 02 Oct 2017 00:13:35 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    Comment 2
    1. Joel Sherrill, Fri, 06 Oct 2017 19:41:46 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    I think this is still broken for me. I did a "git module update" and it didn't seem to pull anything. The configure was this:

    ./waf configure --rtems=$HOME/rtems-work/tools/4.12/bsps \

    --rtems-tools=$HOME/rtems-work/tools/4.12 \ --rtems-bsps=sparc/erc32

    I did "./wak -k" and multiple tests do not build currently. I cd'ed to file_io/crc and then did this:

    $ ../../waf clean 'clean-sparc-rtems4.12-erc32' finished successfully (0.065s) [joel@localhost crc]$ ../../waf Waf: Entering directory `/home/joel/rtems-work/examples-v2/build/sparc-rtems4.12-erc32' [0/2] Compiling rootfs/image.img [1/2] Compiling ../../build/sparc-rtems4.12-erc32/file_io/crc/fs-root.tar [2/6] Compiling crc_32.c [3/6] Compiling ../../build/sparc-rtems4.12-erc32/file_io/crc/fs-root-tar.c [4/6] Compiling init.c ../../file_io/crc/init.c:18:10: fatal error: FilesystemImage?.h: No such file or directory

    #include "FilesystemImage?.h"

    compilation terminated.

    Waf: Leaving directory `/home/joel/rtems-work/examples-v2/build/sparc-rtems4.12-erc32' Build failed

    -> task in 'crc.exe' failed with exit status 1 (run with -v to display more information)

    I did a "git submodule deinit ." and reinitialized the modules but that didn't help either.

    Comment 3
    1. Chris Johns, Fri, 06 Oct 2017 21:57:35 GMT

    Replying to Joel Sherrill:

    I think this is still broken for me. I did a "git module update" and it didn't seem to pull anything.

    I have not worked on this since my last changes you have.

    I did "./waf -k" and multiple tests do not build currently. I cd'ed to file_io/crc and then did this:

    Using -k is a good idea. I should have done that.

    ../../file_io/crc/init.c:18:10: fatal error: FilesystemImage?.h: No such file or directory

    #include "FilesystemImage?.h"

    I have changed the bin2tar file name to clean up the code. The code now uses the rtems_waf __rootfs__ to create the C filesystem file.

    I did a "git submodule deinit ." and reinitialized the modules but that didn't help either.

    This a bug I did not see because the build I did stopped at the trace linker errors.

    Comment 4
    1. Joel Sherrill, Fri, 06 Oct 2017 22:04:09 GMT

    Awesome! Any other tests which look easy to fix?

    Comment 5
    1. Sebastian Huber, Thu, 12 Oct 2017 11:03:38 GMT

    In 4b907ce/examples-v2:

    Fix configuration warnings Update #3158.
    Comment 6
    1. Sebastian Huber, Thu, 12 Oct 2017 11:07:34 GMT

    In 7a8df0d/examples-v2:

    Fix warnings Update #3158.
    Comment 7
    1. Sebastian Huber, Thu, 12 Oct 2017 11:12:24 GMT

    The following errors are left:

    Waf: Entering directory `build/arm-rtems4.12-xilinx_zynq_a9_qemu'
    [ 29/115] Compiling file_io/crc/init.c
    [ 34/115] Compiling build/arm-rtems4.12-xilinx_zynq_a9_qemu/file_io/fdopen/test.c.2.o
    error: config section: dump-on-error: not found
    [108/115] Linking build/arm-rtems4.12-xilinx_zynq_a9_qemu/posix_api/psx_sched_report/psx_sched_report.exe
    ../../file_io/crc/init.c:18:10: fatal error: FilesystemImage.h: No such file or directory
    `#include "FilesystemImage.h"`
              ^~~~~~~~~~~~~~~~~~~
    compilation terminated.
    librtemscpu.a(default-configuration.o): In function `__getreent':
    confdefs.h:2342: multiple definition of `__getreent'
    Waf: Leaving directory `build/arm-rtems4.12-xilinx_zynq_a9_qemu'
    Build failed
     -> task in 'fdopen.texe' failed with exit status 10 (run with -v to display more information)
     -> task in 'crc.exe' failed with exit status 1 (run with -v to display more information)
     -> task in 'psx_sched_report.exe' failed with exit status 1 (run with -v to display more information) 
    Comment 8
    1. Chris Johns, Thu, 12 Oct 2017 15:59:18 GMT

    Replying to Sebastian Huber:

    The following errors are left:

    Waf: Entering directory `build/arm-rtems4.12-xilinx_zynq_a9_qemu'
    [ 29/115] Compiling file_io/crc/init.c
    [ 34/115] Compiling build/arm-rtems4.12-xilinx_zynq_a9_qemu/file_io/fdopen/test.c.2.o
    error: config section: dump-on-error: not found 

    The fix is to remove the line from the INI file.

    [108/115] Linking build/arm-rtems4.12-xilinx_zynq_a9_qemu/posix_api/psx_sched_report/psx_sched_report.exe
    ../../file_io/crc/init.c:18:10: fatal error: FilesystemImage.h: No such file or directory
    `#include "FilesystemImage.h"`
              ^~~~~~~~~~~~~~~~~~~
    compilation terminated. 

    I change the name of the file system image. I have refactored the support so rtems_waf can build a tar file and create the C/H files with a single build instance. I forgot to update the init.c files.

    librtemscpu.a(default-configuration.o): In function `__getreent':
    confdefs.h:2342: multiple definition of `__getreent' 

    This is one Joel has been looking at and has posted on the newlib list about.

    Comment 9
    1. Joel Sherrill, Thu, 12 Oct 2017 19:11:24 GMT

    In f15676f/examples-v2:

    Make crc and fdopen build Updates #3158.
    Comment 10
    1. Joel Sherrill, Thu, 12 Oct 2017 19:16:23 GMT

    psx_sched_report fails due to #3176 and using a default configuration. Changing that test to have an explicit RTEMS configuration.

    Comment 11
    1. Joel Sherrill, Thu, 12 Oct 2017 19:17:28 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    In b6c5dbb/examples-v2:

    psx_sched_report: Add RTEMS configuration to address build issue. Closes #3158.
    Comment 12
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3159 - Examples v2 trace linker ini files reference non-existing dump-on-error

    Link https://devel.rtems.org/ticket/3159
    Id 3159
    Reporter Chris Johns
    Created 1 October 2017 00:21:06
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity major
    Keywords examples
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the dump-on-error option.

    Comment 1
    1. Chris Johns, Mon, 02 Oct 2017 00:14:07 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    Comment 2
    1. Joel Sherrill, Thu, 05 Oct 2017 14:07:05 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    This still fails for me. Did you actually push the fix? I fixed a few other examples-v2 failures. But these remain:

    -> task in 'hello-deep.texe' failed with exit status 10 (run with -v to display more information)

    Looks like missing update from recent changes.

    -> task in 'fat_ramdisk.texe' failed with exit status 10 (run with -v to display more information)

    Looks like missing update from recent changes.

    -> task in 'fdopen.texe' failed with exit status 10 (run with -v to display more information)

    Not building filesystem image

    -> task in 'crc.exe' failed with exit status 1 (run with -v to display more information)

    Not building filesystem image

    -> task in 'psx_sched_report.exe' failed with exit status 1 (run with -v to display more information)

    RTEMS confdefs.h and newlib libc.a both define getreent.

    Comment 3
    1. Chris Johns, Thu, 05 Oct 2017 21:34:05 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    Replying to Joel Sherrill:

    This still fails for me. Did you actually push the fix?

    ​https://git.rtems.org/examples-v2/commit/?id=c7dfbaf83c5b119106f9ee38c902988cc463b0aa

    It removes the dump-on-error issue which is the subject of this ticket.

    Are you seeing #3160?

    Comment 4
    1. Joel Sherrill, Thu, 05 Oct 2017 22:26:58 GMT

    Yes. It appears to impact both_hello and fat_ramdisk.

    Did you look at the two tests which aren't building a filesystem image in waf?

    Comment 5
    1. Chris Johns, Thu, 05 Oct 2017 23:12:15 GMT

    Replying to Joel Sherrill:

    Yes. It appears to impact both_hello and fat_ramdisk.

    It is the trace linker definitions. They need updating.

    Did you look at the two tests which aren't building a filesystem image in waf?

    No. Is that issue #3158? If so please update that ticket with the command you used to configure and build plus the output.

    Comment 6
    1. Joel Sherrill, Thu, 05 Oct 2017 23:40:26 GMT

    OK. Looks like 3158 but I don't have a toolset now. Rebuilding with the latest changes. Will do that in the morning.

    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3160 - Trace linker score support is broken

    Link https://devel.rtems.org/ticket/3160
    Id 3160
    Reporter Chris Johns
    Created 1 October 2017 00:23:33
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The trace linker needs to be updated to build. I am not sure which bit is broken. Building the tools gives:

    [ 7/15] Compiling build/arm-rtems4.12-beagleboneblack/hello/both_hello/test.c.2.o
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:134:13: error: 'Thread_queue_Flush_callout' undeclared here (not in a function); did you mean 'Thread_queue_Flush_filter'?
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: { sizeof (Thread_queue_Flush_callout), "Thread_queue_Flush_callout" },
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^~~~~~~~~~~~~~~~~~~~~~~~~~
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: Thread_queue_Flush_filter
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:140:13: error: 'CORE_mutex_Status' undeclared here (not in a function); did you mean 'CORE_mutex_Control'?
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: { sizeof (CORE_mutex_Status), "CORE_mutex_Status" },
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^~~~~~~~~~~~~~~~~
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: CORE_mutex_Control
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:143:19: error: unknown type name 'CORE_mutex_Attributes'
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: { sizeof (const CORE_mutex_Attributes*), "const CORE_mutex_Attributes*" },
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^~~~~~~~~~~~~~~~~~~~~
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:160:13: error: 'CORE_mutex_API_mp_support_callout' undeclared here (not in a function)
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: { sizeof (CORE_mutex_API_mp_support_callout), "CORE_mutex_API_mp_support_callout" },
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:321:13: error: 'Objects_Locations' undeclared here (not in a function); did you mean 'Objects_Information'?
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: { sizeof (Objects_Locations*), "Objects_Locations*" },
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^~~~~~~~~~~~~~~~~
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: Objects_Information
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:321:31: error: expected expression before ')' token
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: { sizeof (Objects_Locations*), "Objects_Locations*" },
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:342:31: error: expected expression before ')' token
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: { sizeof (Objects_Locations*), "Objects_Locations*" },
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:359:31: error: expected expression before ')' token
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: { sizeof (Objects_Locations*), "Objects_Locations*" },
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:368:31: error: expected expression before ')' token
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: { sizeof (Objects_Locations*), "Objects_Locations*" },
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:443:31: error: expected expression before ')' token
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: { sizeof (Objects_Locations*), "Objects_Locations*" },
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:548:13: error: 'Thread_Start_types' undeclared here (not in a function); did you mean '_Thread_Start'?
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: { sizeof (Thread_Start_types), "Thread_Start_types" },
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^~~~~~~~~~~~~~~~~~
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: _Thread_Start
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:570:13: error: 'Thread_blocking_operation_States' undeclared here (not in a function); did you mean 'Thread_queue_Operations'?
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: { sizeof (Thread_blocking_operation_States), "Thread_blocking_operation_States" },
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: Thread_queue_Operations
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c: In function 'rtld_pg_printk_entry':
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:678:3: warning: implicit declaration of function 'printk'; did you mean 'printf'? [-Wimplicit-function-declaration]
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: printk (">>> %s (0x%08x)\n", func_name, func_addr);
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^~~~~~
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: printf
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c: At top level:
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:742:48: error: expected declaration specifiers or '...' before 'Thread_queue_Flush_callout'
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: void _CORE_mutex_Flush(CORE_mutex_Control* a1, Thread_queue_Flush_callout a2, uint32_t a3);
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^~~~~~~~~~~~~~~~~~~~~~~~~~
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:743:55: error: expected declaration specifiers or '...' before 'Thread_queue_Flush_callout'
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: void __real__CORE_mutex_Flush(CORE_mutex_Control* a1, Thread_queue_Flush_callout a2, uint32_t a3);
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^~~~~~~~~~~~~~~~~~~~~~~~~~
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:744:55: error: expected declaration specifiers or '...' before 'Thread_queue_Flush_callout'
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: void __wrap__CORE_mutex_Flush(CORE_mutex_Control* a1, Thread_queue_Flush_callout a2, uint32_t a3)
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^~~~~~~~~~~~~~~~~~~~~~~~~~
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: hello-deep.c:757:1: error: unknown type name 'CORE_mutex_Status'; did you mean 'CORE_mutex_Control'?
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: CORE_mutex_Status _CORE_mutex_Initialize(CORE_mutex_Control* a1, Thread_Control* a2, const CORE_mutex_Attributes* a3, bool a4);
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: ^~~~~~~~~~~~~~~~~
    /Users/chris/development/rtems/4.12/bin/arm-rtems4.12-gcc: CORE_mutex_Control

    This is a snip of the errors.

    Comment 1
    1. Sebastian Huber, Mon, 02 Oct 2017 11:50:12 GMT

    I removed these types some months ago. Are you on the right branch? How can I build this stuff?

    Comment 2
    1. Chris Johns, Mon, 02 Oct 2017 22:23:58 GMT

    Replying to Sebastian Huber:

    I removed these types some months ago. Are you on the right branch?

    Yes. There are types in the trace definitions ...

    ​https://git.rtems.org/rtems-tools/tree/linkers/rtems-score-coremutex.ini

    These definitions are a quick and dirty hack I would prefer to avoid however the long term solution is getting function signatures and types from the DWARF data but that work is more than the time I have available. I need someone to support the effort.

    How can I build this stuff?

    Clone examples-v2 and then build using the ./waf I have just added to the repo. The examples uses rtems_waf so configured in a similar way to libbsd.

    Comment 3
    1. Sebastian Huber, Fri, 06 Oct 2017 07:34:14 GMT

    The CORE mutex implementation changed considerably. Most of it moved to inline functions. I am not sure what you want to trace here?

    Comment 4
    1. Sebastian Huber, Fri, 06 Oct 2017 07:36:18 GMT

    Maybe this should be replaced by the thread queue enqueue and extract functions.

    Comment 5
    1. Chris Johns, Sat, 07 Oct 2017 00:16:31 GMT

    Replying to Sebastian Huber:

    Maybe this should be replaced by the thread queue enqueue and extract functions.

    I think anything that makes sense will do. It is more of an example of what we can trace and the fact you can trace into the kernel some distance.

    Comment 6
    1. Sebastian Huber, Thu, 12 Oct 2017 10:53:52 GMT

    In b76fa74/rtems-tools:

    linkers: Update due to API changes Update #3160.
    Comment 7
    1. Sebastian Huber, Thu, 12 Oct 2017 10:56:24 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 3742597/examples-v2:

    Update due to trace linker changes Close #3160.
    Comment 8
    1. Chris Johns, Thu, 12 Oct 2017 15:54:19 GMT

    Thank you for fixing this for me.

    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3163 - Add I2C device driver for temperature sensor LM75A

    Link https://devel.rtems.org/ticket/3163
    Id 3163
    Reporter Sebastian Huber
    Created 2 October 2017 11:40:34
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Mon, 02 Oct 2017 11:41:40 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 4cfce5c/rtems:

    i2c: Add temperature sensor LM75A driver Close #3163.
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3166 - New default ticket assignee: NeedsReview

    Link https://devel.rtems.org/ticket/3166
    Id 3166
    Reporter Sebastian Huber
    Created 4 October 2017 16:25:57
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    We have to many tickets with an unclear state if someone is working on them. One problem is that the tickets are assigned to a real person by default. Assign the tickets to a virtual person NeedsReview? to make it clear that this ticket has nobody assigned which can resolve it.

    Comment 1
    1. Chris Johns, Wed, 04 Oct 2017 23:53:48 GMT

    I would prefer we remove the default owner from the components and have Trac leave the ticket unassigned.

    Comment 2
    1. Sebastian Huber, Thu, 05 Oct 2017 04:56:39 GMT

    Ok, I will remove the default owners tomorrow if nobody objects.

    Comment 3
    1. Sebastian Huber, Fri, 06 Oct 2017 11:47:08 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    I removed the default owner for all components.

    Comment 4
    1. Sebastian Huber, Tue, 10 Oct 2017 06:12:28 GMT
    2. component: changed from Other to unspecified
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3167 - Internal status codes must not depend on RTEMS_POSIX_API

    Link https://devel.rtems.org/ticket/3167
    Id 3167
    Reporter Sebastian Huber
    Created 5 October 2017 07:24:55
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The internal status codes encode a Classic rtems_status_code and error codes used by the POSIX and C11/C++11 APIs. In case the POSIX API is disabled, the C11/C++11 support must still work.

    Comment 1
    1. Sebastian Huber, Thu, 05 Oct 2017 07:46:12 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 5cf5d46e/rtems:

    score: Make status codes unconditional The internal status codes encode a Classic rtems_status_code and error codes used by the POSIX and C11/C++11 APIs. In case the POSIX API is disabled, the C11/C++11 support must still work. Close #3167.
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3168 - Simplify POSIX_API_Control

    Link https://devel.rtems.org/ticket/3168
    Id 3168
    Reporter Sebastian Huber
    Created 5 October 2017 13:28:04
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    There is no need to have a copy of the thread attributes used for the pthread_create() in POSIX_API_Control::Attributes. This is at least in line with Linux.

    Attachments:

    1 Sebastian Huber, Thu, 05 Oct 2017 13:28:41 GMT
      attach: set to test.c
     
    Comment 1
    1. Sebastian Huber, Tue, 10 Oct 2017 05:43:49 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In af9115f3/rtems:

    posix: Simplify POSIX_API_Control Return stack area via pthread_getattr_np(). Simplify pthread_attr_setaffinity_np(), and pthread_attr_getaffinity_np() and let the scheduler do the more sophisticated error checks. Make pthread_setaffinity_np(), pthread_getaffinity_np(), pthread_attr_setaffinity_np(), and pthread_attr_getaffinity_np() available in all configurations. Update #2514. Close #3145. Close #3168.
    Comment 2
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 3
    1. Sebastian Huber, Thu, 02 Nov 2017 10:25:59 GMT

    In 81fd79d/rtems:

    smppsxaffinity02: Fix thread attribute usage The pthread_getattr_np() returns now the stack address and size. Do not use this stack for the new threads. Update #2514. Update #3145. Update #3168.
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3170 - Use BSP_output_char via RTEMS printer or simple console driver for test output by default

    Link https://devel.rtems.org/ticket/3170
    Id 3170
    Reporter Chris Johns
    Created 6 October 2017 04:02:37
    Modified 5 February 2018 09:48:37
    Owner Chris Johns
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity critical
    Keywords zedboard testing
    Cc  
    Blocking  
    Blocked by  

    Description

    Test runs with a interrupt driven console driver result in unreliable test outcomes.

    Problem was noticed with test runs on Microzed, for example libtest/block08:

    The test prints:

    ** END OF TEST BLOCK 8 *** 

    The rtems-test command marks the result as a failure. There is a single * missing from the start of the line. I attach the full test trace.

    Attachments:

    1 Chris Johns, Fri, 06 Oct 2017 04:03:09 GMT
      attach: set to microzed-block8.txt
     
    Comment 1
    1. Chris Johns, Fri, 06 Oct 2017 21:48:30 GMT
    2. severity: changed from major to critical
    3. summary: changed from Microzed libtest/block8 fails to print end of test correctly. to Microzed libtest/block08 fails to print end of test correctly.

    I changed all printk calls in the block08 test to printf and the output from the test is now correct and rtems-test passes the test.

    There must be something wrong with the Zync UART drivers. I have escalated this to critical because I would like the Zynq to be a tier 1 device with the Beaglebone Black so we have Cortex-A9 and Cortex-A8 devices in tier 1.

    There are 233 printk references in the testsuite. I am sure some are needed however block08's printk calls were not needed so I am now wondering how many are?

    Comment 2
    1. Sebastian Huber, Mon, 09 Oct 2017 07:19:29 GMT

    Does the following patch alter the output:

    diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/console/zynq-uart.c b/c/src/lib/libbsp/arm/xilinx-zynq/console/zynq-uart.c
    index fa91f3f46e..3c42be428f 100644
    --- a/c/src/lib/libbsp/arm/xilinx-zynq/console/zynq-uart.c
    +++ b/c/src/lib/libbsp/arm/xilinx-zynq/console/zynq-uart.c
    @@ -226,12 +226,18 @@ void zynq_uart_write_polled(
     {
       zynq_uart_context *ctx = (zynq_uart_context *) base;
       volatile zynq_uart *regs = ctx->regs;
    +  rtems_interrupt_level level;
    +
    +  rtems_interrupt_local_disable(level);
       while ((regs->channel_sts & ZYNQ_UART_CHANNEL_STS_TFUL) != 0) {
         /* Wait */
    +    rtems_interrupt_local_enable(level);
    +    rtems_interrupt_local_disable(level);
       }
       regs->tx_rx_fifo = ZYNQ_UART_TX_RX_FIFO_FIFO(c);
    +  rtems_interrupt_local_enable(level);
     }
     static void zynq_uart_write_support( 
    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:46:55 GMT
    2. component: changed from testing to unspecified
    Comment 4
    1. Chris Johns, Wed, 11 Oct 2017 23:11:59 GMT
    2. owner: changed from joel.sherrill@… to Chris Johns
    3. status: changed from new to assigned
    Comment 5
    1. Chris Johns, Thu, 12 Oct 2017 17:19:10 GMT

    Replying to Sebastian Huber:

    Does the following patch alter the output:

    No it did not make a difference.

    See ​https://lists.rtems.org/pipermail/build/2017-October/000007.html. Search for Result: invalid Time: 0:00:23.859291 dumpbuf01.exe.img. The rtems_print_buffer() call uses rtems_putc and that uses printk or the putc equivalent.

    Reviewing the failures there looks to be something wrong in the BSP. There are failures which should not or do not fail on other BSP. I cannot debug this remotely so it may have to wait. Are you able to run the tests on a Zynq?

    Comment 6
    1. Sebastian Huber, Fri, 13 Oct 2017 06:48:49 GMT

    Do you use a polled or interrupt driven console driver? The tests need a polled console driver.

    Comment 7
    1. Chris Johns, Fri, 13 Oct 2017 12:51:02 GMT

    Replying to Sebastian Huber:

    Do you use a polled or interrupt driven console driver?

    I use the default configuration:

    configure --target=arm-rtems4.12 --prefix=/opt/work/chris/rtems/kernel/4.12 --disable-networking --enable-rtemsbsp=xilinx_zynq_zedboard --enable-maintainer-mode --enable-tests 

    I have always assumed the default configuration for __any__ BSP lets the tests run. Is this not the case?

    The tests need a polled console driver.

    What do I do to make this happen?

    Comment 8
    1. Sebastian Huber, Fri, 13 Oct 2017 12:54:16 GMT

    Replying to Chris Johns:

    Replying to Sebastian Huber:

    Do you use a polled or interrupt driven console driver?

    I use the default configuration:

    configure --target=arm-rtems4.12 --prefix=/opt/work/chris/rtems/kernel/4.12 --disable-networking --enable-rtemsbsp=xilinx_zynq_zedboard --enable-maintainer-mode --enable-tests 

    I have always assumed the default configuration for __any__ BSP lets the tests run. Is this not the case?

    No, this is not the case for the real hardware BSPs which usually use an interrupt driven console driver.

    The tests need a polled console driver.

    What do I do to make this happen?

    This is BSP-specific. Try, to add "ZYNQ_CONSOLE_USE_INTERRUPTS=" to the configure command line.

    Comment 9
    1. Chris Johns, Fri, 13 Oct 2017 13:21:40 GMT

    Replying to Sebastian Huber:

    Replying to Chris Johns:

    I have always assumed the default configuration for __any__ BSP lets the tests run. Is this not the case?

    No, this is not the case for the real hardware BSPs which usually use an interrupt driven console driver.

    This seems like a new requirement. Has something changed in RTEMS to cause this? I do not remember having this problem with previous versions.

    This is confusing because each BSP is different and has different options. The tests should manage this internally at runtime and not be dependent on low level BSP specific driver implementations. We have polled console driver support in BSPs, why not get the tests to use it?

    Is this documented anywhere? FWIW I see adding some now as hiding the real issue.

    What do I do to make this happen?

    This is BSP-specific. Try, to add "ZYNQ_CONSOLE_USE_INTERRUPTS=" to the configure command line.

    I will consider the blocker status for this issue and discuss it with Joel today. He told me yesterday no tests should be using printk unless configured to do so, ie small memory targets. There seems to be some confusion.

    Comment 10
    1. Sebastian Huber, Fri, 13 Oct 2017 13:28:24 GMT

    Replying to Chris Johns:

    Replying to Sebastian Huber:

    Replying to Chris Johns:

    I have always assumed the default configuration for __any__ BSP lets the tests run. Is this not the case?

    No, this is not the case for the real hardware BSPs which usually use an interrupt driven console driver.

    This seems like a new requirement. Has something changed in RTEMS to cause this? I do not remember having this problem with previous versions.

    At least since I use RTEMS, this was the case. I asked questions about this on the mailing list.

    This is confusing because each BSP is different and has different options. The tests should manage this internally at runtime and not be dependent on low level BSP specific driver implementations. We have polled console driver support in BSPs, why not get the tests to use it?

    Is this documented anywhere? FWIW I see adding some now as hiding the real issue.

    The console drivers are a real mess. We have no link-time configuration options/mechanism for drivers. Its not so easy.

    Changing the tests so that they work with an interrupt driven console driver is hard. I don't think it makes sense. What we need is a non-blocking test output support.

    What do I do to make this happen?

    This is BSP-specific. Try, to add "ZYNQ_CONSOLE_USE_INTERRUPTS=" to the configure command line.

    I will consider the blocker status for this issue and discuss it with Joel today. He told me yesterday no tests should be using printk unless configured to do so, ie small memory targets. There seems to be some confusion.

    Some tests must not use printf, due to execution environment constraints, e.g. interrupt context, no drivers, early system state, fatal error, etc.

    If you consider this as a blocker, then you possibly delay the release for several months.

    Comment 11
    1. Sebastian Huber, Fri, 13 Oct 2017 13:38:59 GMT

    An short term option would be a unification of the BSP option to select a polled console driver.

    Comment 12
    1. Joel Sherrill, Fri, 13 Oct 2017 13:41:11 GMT

    There is a buffered test up option for the tests which will help those that use the infrastructure. Should be in testsuites/configure.ac

    Comment 13
    1. Chris Johns, Fri, 13 Oct 2017 13:42:07 GMT

    Replying to Sebastian Huber:

    Replying to Chris Johns:

    Replying to Sebastian Huber:

    Replying to Chris Johns:

    I have always assumed the default configuration for __any__ BSP lets the tests run. Is this not the case?

    No, this is not the case for the real hardware BSPs which usually use an interrupt driven console driver.

    This seems like a new requirement. Has something changed in RTEMS to cause this? I do not remember having this problem with previous versions.

    At least since I use RTEMS, this was the case. I asked questions about this on the mailing list.

    The beaglebone black does not have the same problems as the Zynq. I checked the drivers for the BBB and there is an interrupt version so I wonder if the polled driver is used by default. I did not check this.

    The console drivers are a real mess. We have no link-time configuration options/mechanism for drivers. Its not so easy.

    If consoles provide interrupt and poll devs, why have the test close the console and reopen it with the polled driver? Yeah ok It is easy to say this and no I have not looked into the detail and what complexity there is. :)

    Changing the tests so that they work with an interrupt driven console driver is hard. I don't think it makes sense. What we need is a non-blocking test output support.

    Agreed, I was not considering changing the tests to do this rather how output is handled. There is the TESTS_BUFFER_OUTPUT and TESTS_USE_PRINTK can they be forced on and all stdout and stderr paths switched to what is used?

    If you consider this as a blocker, then you possibly delay the release for several months.

    This is being a little dramatic. I am not after a rewrite, I am looking for a simple pragmatic solution. We need the ability to test on hardware in a repeatable manner for the life of the release branch.

    Comment 14
    1. Sebastian Huber, Fri, 13 Oct 2017 13:44:54 GMT

    Replying to Chris Johns:

    Replying to Sebastian Huber:

    Replying to Chris Johns:

    Replying to Sebastian Huber:

    Replying to Chris Johns:

    I have always assumed the default configuration for __any__ BSP lets the tests run. Is this not the case?

    No, this is not the case for the real hardware BSPs which usually use an interrupt driven console driver.

    This seems like a new requirement. Has something changed in RTEMS to cause this? I do not remember having this problem with previous versions.

    At least since I use RTEMS, this was the case. I asked questions about this on the mailing list.

    The beaglebone black does not have the same problems as the Zynq. I checked the drivers for the BBB and there is an interrupt version so I wonder if the polled driver is used by default. I did not check this.

    It depends also on the hardware, FIFO depth, DMA support, etc.

    Comment 15
    1. Chris Johns, Fri, 13 Oct 2017 13:47:42 GMT

    Replying to Sebastian Huber:

    An short term option would be a unification of the BSP option to select a polled console driver.

    We have an option --enable-tests=all? Should this force polled drivers?

    Comment 16
    1. Sebastian Huber, Mon, 16 Oct 2017 05:22:23 GMT

    Its not really transparent to the user that --enable-tests=all tinkers with the console driver.

    Comment 17
    1. Sebastian Huber, Mon, 23 Oct 2017 11:49:42 GMT

    In 88e84c22/rtems:

    testsuite: Fix build Updates #3170.
    Comment 18
    1. Chris Johns, Tue, 24 Oct 2017 21:33:16 GMT

    In 4c70110/rtems:

    testsuite: Fix build Updates #3170.
    Comment 19
    1. Sebastian Huber, Thu, 26 Oct 2017 12:06:21 GMT

    Tests must be audited to ensure that they don't call the standard output functions, e.g.

    nm find -name '*.exe' | grep 'exe:\|\\|\'

    Comment 20
    1. Sebastian Huber, Fri, 27 Oct 2017 05:01:07 GMT
    2. description: modified (diff)
    3. summary: changed from Microzed libtest/block08 fails to print end of test correctly. to Use BSP_output_char via RTEMS printer for test output by default

    If we use BSP_output_char for all tests, then the console driver is not tested. We probably need a special test for it.

    We should also remove CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER from all other tests.

    Comment 21
    1. Sebastian Huber, Sat, 28 Oct 2017 12:08:04 GMT

    In f703e7f/rtems:

    tests: Move rtems_test_printer definition Statically initialize it to use printk(). Update #3170. Update #3199.
    Comment 22
    1. Sebastian Huber, Sat, 28 Oct 2017 12:08:16 GMT

    In 7bec7f27/rtems:

    rtems: Add rtems_print_printer_fprintf_putc() Update #3170. Update #3199.
    Comment 23
    1. Sebastian Huber, Sat, 28 Oct 2017 12:08:27 GMT

    In 73d892d8/rtems:

    tests: Use rtems_test_printer Update #3170. Update #3199.
    Comment 24
    1. Sebastian Huber, Sat, 28 Oct 2017 12:08:39 GMT

    In 46ddc3c5/rtems:

    tests: Use rtems_print_printer_fprintf_putc() Use rtems_print_printer_fprintf_putc() instead of rtems_print_printer_printf() to output via rtems_putc(). Update #3170. Update #3199.
    Comment 25
    1. Sebastian Huber, Sat, 28 Oct 2017 12:08:51 GMT

    In 7e10291/rtems:

    tests: Use rtems_test_printer in general Update #3170. Update #3199.
    Comment 26
    1. Sebastian Huber, Sat, 28 Oct 2017 12:09:02 GMT

    In acc9d064/rtems:

    tests: Remove obsolete TESTS_USE_PRINTK Update #3170. Update #3199.
    Comment 27
    1. Sebastian Huber, Sat, 28 Oct 2017 12:09:15 GMT

    In af43554/rtems:

    tests: Remove TEST_INIT The TEST_EXTERN is a used only by the system.h style tests and they use CONFIGURE_INIT appropriately. Update #3170. Update #3199.
    Comment 28
    1. Chris Johns, Mon, 30 Oct 2017 05:31:17 GMT

    In 2126438a/rtems:

    testsuite: Add bspIo for a local printk. Update #3170. Update #3199.
    Comment 29
    1. Sebastian Huber, Thu, 02 Nov 2017 13:25:12 GMT

    In 0d796d6/rtems:

    tests: Delete obsolete TESTS_USE_PRINTF Update #3170. Update #3199.
    Comment 30
    1. Sebastian Huber, Thu, 02 Nov 2017 13:26:51 GMT

    In 8c1f4064/rtems:

    tests: Use printf() instead of fprintf() Update #3170. Update #3199.
    Comment 31
    1. Sebastian Huber, Mon, 06 Nov 2017 06:29:25 GMT

    In ac28f15/rtems:

    Add simple console driver Update #3170. Update #3199.
    Comment 32
    1. Sebastian Huber, Mon, 06 Nov 2017 06:29:41 GMT

    In c4b8b147/rtems:

    tests: Use simple console driver Update #3170. Update #3199.
    Comment 33
    1. Sebastian Huber, Tue, 07 Nov 2017 06:09:15 GMT

    In 7b00c2fa/rtems:

    tests: Use in all tests Update #3170. Update #3199.
    Comment 34
    1. Sebastian Huber, Tue, 07 Nov 2017 07:32:57 GMT

    In 32ceb38/rtems:

    tests: Use Update #3170. Update #3199.
    Comment 35
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 36
    1. Sebastian Huber, Mon, 13 Nov 2017 09:01:06 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    Comment 37
    1. Sebastian Huber, Mon, 13 Nov 2017 09:02:07 GMT
    2. summary: changed from Use BSP_output_char via RTEMS printer for test output by default to Use BSP_output_char via RTEMS printer or simple console driver for test output by default
    Comment 38
    1. Sebastian Huber, Mon, 05 Feb 2018 09:48:37 GMT

    In d078405/rtems-docs:

    CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER Close #3170. Update #3199.

    3171 - RSB GCC does not build on High Sierra and APFS

    Link https://devel.rtems.org/ticket/3171
    Id 3171
    Reporter Chris Johns
    Created 7 October 2017 20:34:21
    Modified 14 October 2018 00:37:39
    Owner Chris Johns
    Type defect
    Component tool/gcc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity critical
    Keywords RSB APFS MacOS
    Cc  
    Blocking  
    Blocked by  

    Description

    The issue has been reported upstream as ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

    Attachments:

    1 Chris Johns, Wed, 11 Oct 2017 12:31:33 GMT
      attach: set to darwin-apfs-gcc-libstdc++-bug-81797.diff
     
    2 Chris Johns, Fri, 27 Oct 2017 03:04:12 GMT
      attach: set to darwin-apfs-gcc-libstdc++-bug-81797-redi-2.diff
     
    3 Chris Johns, Sun, 07 Oct 2018 03:16:48 GMT
      attach: set to darwin-libstdcpp-noparallel-fix.patch
     
    Comment 1
    1. Sebastian Huber, Tue, 10 Oct 2017 05:58:26 GMT
    2. component: changed from GCC to tool/gcc
    Comment 2
    1. Chris Johns, Wed, 11 Oct 2017 23:13:11 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to accepted
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 4
    1. Chris Johns, Fri, 12 Oct 2018 17:00:55 GMT

    In 7bb268b/rtems-source-builder:

    darwin: Work around symlink issues on Darwin with APFS building libstd++. See ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 Updates #3171
    Comment 5
    1. Chris Johns, Sun, 14 Oct 2018 00:37:39 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    Tested on Mojave.


    3172 - i386 PC BSP does not reset when bsp_reset is called.

    Link https://devel.rtems.org/ticket/3172
    Id 3172
    Reporter Chris Johns
    Created 9 October 2017 02:56:01
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component arch/i386
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords PC i386 reset
    Cc  
    Blocking  
    Blocked by  

    Description

    Removal of the Edison support removed the standard PC reset using the keyboard controller rather then the specific Edison support.

    Comment 1
    1. Joel Sherrill, Mon, 09 Oct 2017 03:14:53 GMT

    I noticed the wrong code was removed Thursday and have a patch ready to push.

    Comment 2
    1. Joel Sherrill, Mon, 09 Oct 2017 03:26:42 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 19cbd194/rtems:

    pc386/.../bspreset.c: Readd proper reset code. The removal of the Edison code removed the wrong part of the conditional. Closes #3172.
    Comment 3
    1. Sebastian Huber, Tue, 10 Oct 2017 06:55:23 GMT
    2. component: changed from bsps to arch/i386
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3173 - XIlinx AXI I2C driver IP race condition causes clock glitch.

    Link https://devel.rtems.org/ticket/3173
    Id 3173
    Reporter Chris Johns
    Created 9 October 2017 10:50:41
    Modified 1 February 2018 04:00:19
    Owner Chris Johns
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords I2C XIlinx AXI
    Cc  
    Blocking  
    Blocked by  

    Description

    The Xilinx AXI I2C IP has a race condition when the PIRQ read FIFO level is reached and the clock is throttling.

    Comment 1
    1. Sebastian Huber, Mon, 16 Oct 2017 06:18:44 GMT
    2. component: changed from score to arch/arm
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 3
    1. Chris Johns, Thu, 01 Feb 2018 04:00:19 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 05015dc1/rtems:

    Xilinx AXI I2C driver IP race condition causes clock glitch. Setting the PIRQ to 0 before reading the data produces a short clock pulse. Moving the write to after reading the data fixes the issue. Close #3173

    3174 - Remove rtems_pthread_attribute_compare()

    Link https://devel.rtems.org/ticket/3174
    Id 3174
    Reporter Sebastian Huber
    Created 9 October 2017 13:24:14
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The rtems_pthread_attribute_compare() function is undocumented and used only in one test. Move it to the test.

    Comment 1
    1. Sebastian Huber, Tue, 10 Oct 2017 05:44:03 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In da9f5f1/rtems:

    posix: Remove rtems_pthread_attribute_compare() Update #2514. Close #3174.
    Comment 2
    1. Sebastian Huber, Mon, 16 Oct 2017 06:17:09 GMT
    2. component: changed from score to posix
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3175 - Merge FreeBSD timecounter changes from 2015-01-20 to now

    Link https://devel.rtems.org/ticket/3175
    Id 3175
    Reporter Sebastian Huber
    Created 10 October 2017 05:50:32
    Modified 20 October 2018 15:21:27
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by 3557

    Description

    Comment 1
    1. Hans Petter Selasky, Thu, 12 Oct 2017 05:05:59 GMT

    In ea0b339/rtems:

    timecounter: Merge FreeBSD change r279728 Add mutex support to the pps_ioctl() API in the kernel. Bump kernel version to reflect structure change. PR: 196897 MFC after: 1 week Update #3175.
    Comment 2
    1. Ian Lepore, Thu, 12 Oct 2017 05:06:10 GMT

    In 0aef6fb/rtems:

    timecounter: Merge FreeBSD change r280012 Use sbuf_printf() for sysctl strings instead of stack buffers and snprintf(). Update #3175.
    Comment 3
    1. Ian Lepore, Thu, 12 Oct 2017 05:06:22 GMT

    In 51304dde/rtems:

    timecounter: Merge FreeBSD change r282424 Implement a mechanism for making changes in the kernel<->driver PPS interface without breaking ABI or API compatibility with existing drivers. The existing data structures used to communicate between the kernel and driver portions of PPS processing contain no spare/padding fields and no flags field or other straightforward mechanism for communicating changes in the structures or behaviors of the code. This makes it difficult to MFC new features added to the PPS facility. ABI compatibility is important; out-of-tree drivers in module form are known to exist. (Note that the existing api_version field in the pps_params structure must contain the value mandated by RFC 2783 and any RFCs that come along after.) These changes introduce a pair of abi-version fields which are filled in by the driver and the kernel respectively to indicate the interface version. The driver sets its version field before calling the new pps_init_abi() function. That lets the kernel know how much of the pps_state structure is understood by the driver and it can avoid using newer fields at the end of the structure that it knows about if the driver is a lower version. The kernel fills in its version field during the init call, letting the driver know what features and data the kernel supports. To implement the new version information in a way that is backwards compatible with code from before these changes, the high bit of the lightly-used 'kcmode' field is repurposed as a flag bit that indicates the driver is aware of the abi versioning scheme. Basically if this bit is clear that indicates a "version 0" driver and if it is set the driver_abi field indicates the version. These changes also move the recently-added 'mtx' field of pps_state from the middle to the end of the structure, and make the kernel code that uses this field conditional on the driver being abi version 1 or higher. It changes the only driver currently supplying the mtx field, usb_serial, to use pps_init_abi(). Reviewed by: hselasky@ Update #3175.
    Comment 4
    1. Konstantin Belousov, Thu, 12 Oct 2017 05:06:34 GMT

    In 4d0ade9/rtems:

    timecounter: Merge FreeBSD change r284256 Tweaks for r284178: Do not include machine/atomic.h explicitely, the header is already included by sys/systm.h. Force inlining of tc_getgen() and tc_setgen(). The functions are used more than once, which causes compilers with non-aggressive inlining policies to generate calls. Suggested by: bde Sponsored by: The FreeBSD Foundation MFC after: 1 week Update #3175.
    Comment 5
    1. Konstantin Belousov, Thu, 12 Oct 2017 05:06:46 GMT

    In 0163063/rtems:

    timecounter: Merge FreeBSD change r285286 Reimplement the ordering requirements for the timehands updates, and for timehands consumers, by using fences. Ensure that the timehands->th_generation reset to zero is visible before the data update is visible [*]. tc_setget() allowed data update writes to become visible before generation (but not on TSO architectures). Remove tc_setgen(), tc_getgen() helpers, use atomics inline [__]. __ Noted by: alc [*] Requested by: bde [__] Reviewed by: alc, bde Sponsored by: The FreeBSD Foundation MFC after: 3 weeks __ Update #3175.
    Comment 6
    1. Ian Lepore, Thu, 12 Oct 2017 05:06:58 GMT

    In ec349b58/rtems:

    timecounter: Merge FreeBSD change r286423 RFC 2783 requires a status of ETIMEDOUT, not EWOULDBLOCK, on a timeout. Update #3175.
    Comment 7
    1. Ian Lepore, Thu, 12 Oct 2017 05:07:09 GMT

    In 7494681/rtems:

    timecounter: Merge FreeBSD change r286429 Only process the PPS event types currently enabled in pps_params.mode. This makes the PPS API behave correctly, but isn't ideal -- we still end up capturing PPS data for non-enabled edges, we just don't process the data into an event that becomes visible outside of kern_tc. That's because the event type isn't passed to pps_capture(), so it can't do the filtering. Any solution for capture filtering is going to require touching every driver. Update #3175.
    Comment 8
    1. Ian Lepore, Thu, 12 Oct 2017 05:07:21 GMT

    In f1463c8/rtems:

    timecounter: Merge FreeBSD change r286701 If a specific timecounter has been chosen via sysctl, and a new timecounter with higher quality registers (presumably in a module that has just been loaded), do not undo the user's choice by switching to the new timecounter. Document that behavior, and also the fact that there is no way to unregister a timecounter (and thus no way to unload a module containing one). Update #3175.
    Comment 9
    1. Ian Lepore, Thu, 12 Oct 2017 05:07:33 GMT

    In 2b6d00f/rtems:

    timecounter: Merge FreeBSD change r304285 Constify the pointers to eventtimer and timecounter name strings. The need for this appears as soon as you try to set the names to something that isn't a "quoted literal". (I'm actually confused why quoted strings aren't a problem as well, we must have some warning disabled.) Update #3175.
    Comment 10
    1. Konstantin Belousov, Thu, 12 Oct 2017 05:07:44 GMT

    In f013c14/rtems:

    timecounter: Merge FreeBSD change r288216 Use per-cpu values for base and last in tc_cpu_ticks(). The values are updated lockess, different CPUs write its own view of timecounter state. The critical section is done for safety, callers of tc_cpu_ticks() are supposed to already enter critical section, or to own a spinlock. The change fixes sporadical reports of too high values reported for the (W)CPU on platforms that do not provide cpu ticker and use tc_cpu_ticks(), in particular, arm*. Diagnosed and reviewed by: jhb Sponsored by: The FreeBSD Foundation MFC after: 1 week Update #3175.
    Comment 11
    1. Ngie Cooper, Thu, 12 Oct 2017 05:07:56 GMT

    In 4cd742e/rtems:

    timecounter: Merge FreeBSD change r290257 Define fhard in pps_event(..) only when PPS_SYNC is defined to mute an -Wunused-but-set-variable warning Reported by: FreeBSD_HEAD_amd64_gcc4.9 jenkins job Sponsored by: EMC / Isilon Storage Division Update #3175.
    Comment 12
    1. Pedro Giffuni, Thu, 12 Oct 2017 05:08:08 GMT

    In 65f2cd7a/rtems:

    timecounter: Merge FreeBSD change r298819 sys/kern: spelling fixes in comments. No functional change. Update #3175.
    Comment 13
    1. Pedro Giffuni, Thu, 12 Oct 2017 05:08:20 GMT

    In f6c94601/rtems:

    timecounter: Merge FreeBSD change r298981 sys/sys: minor spelling fixes. While the changes are minor, these headers are very visible. MFC after: 2 weeks Update #3175.
    Comment 14
    1. Konstantin Belousov, Thu, 12 Oct 2017 05:08:32 GMT

    In d310aa7/rtems:

    timecounter: Merge FreeBSD change r303382 Hide the boottime and bootimebin globals, provide the getboottime(9) and getboottimebin(9) KPI. Change consumers of boottime to use the KPI. The variables were renamed to avoid shadowing issues with local variables of the same name. Issue is that boottime* should be adjusted from tc_windup(), which requires them to be members of the timehands structure. As a preparation, this commit only introduces the interface. Some uses of boottime were found doubtful, e.g. NLM uses boottime to identify the system boot instance. Arguably the identity should not change on the leap second adjustment, but the commit is about the timekeeping code and the consumers were kept bug-to-bug compatible. Tested by: pho (as part of the bigger patch) Reviewed by: jhb (same) Discussed with: bde Sponsored by: The FreeBSD Foundation MFC after: 1 month X-Differential revision: ​https://reviews.freebsd.org/D7302 Update #3175.
    Comment 15
    1. Konstantin Belousov, Thu, 12 Oct 2017 05:08:44 GMT

    In 6d3c125/rtems:

    timecounter: Merge FreeBSD change r303383 Reduce number of timehands to just two. This is useful because consumers can now be only one tc_windup() call late. Use C99 initialization. Tested by: pho (as part of the whole patch) Reviewed by: jhb (same) Discussed with: bde Sponsored by: The FreeBSD Foundation MFC after: 1 month X-Differential revision: ​https://reviews.freebsd.org/D7302 Update #3175.
    Comment 16
    1. Konstantin Belousov, Thu, 12 Oct 2017 05:08:56 GMT

    In 464fd5d/rtems:

    timecounter: Merge FreeBSD change r303384 Style. Sponsored by: The FreeBSD Foundation MFC after: 1 month X-Differential revision: ​https://reviews.freebsd.org/D7302 Update #3175.
    Comment 17
    1. Konstantin Belousov, Thu, 12 Oct 2017 05:09:08 GMT

    In b48aeaf/rtems:

    timecounter: Merge FreeBSD change r303387 Prevent parallel tc_windup() calls, both parallel top-level calls from setclock() and from simultaneous top-level and interrupt. For this, tc_windup() is protected with a tc_setclock_mtx spinlock, in the try mode when called from hardclock interrupt. If spinlock cannot be obtained without spinning from the interrupt context, this means that top-level executes tc_windup() on other core and our try may be avoided. The boottimebin and boottime variables should be adjusted from tc_windup(). To be correct, they must be part of the timehands and read using lockless protocol. Remove the globals and reimplement the getboottime(9)/getboottimebin(9) KPI using the timehands read protocol. Tested by: pho (as part of the whole patch) Reviewed by: jhb (same) Discussed wit: bde Sponsored by: The FreeBSD Foundation MFC after: 1 month X-Differential revision: ​https://reviews.freebsd.org/D7302 Update #3175.
    Comment 18
    1. Konstantin Belousov, Thu, 12 Oct 2017 05:09:20 GMT

    In c382cc83/rtems:

    timecounter: Merge FreeBSD change r303548 Cache getbintime(9) answer in timehands, similarly to getnanotime(9) and getmicrotime(9). Suggested and reviewed by: bde (previous version) Sponsored by: The FreeBSD Foundation MFC after: 1 month Update #3175.
    Comment 19
    1. Konstantin Belousov, Thu, 12 Oct 2017 05:09:33 GMT

    In 7488715/rtems:

    timecounter: Merge FreeBSD change r304285 Implement userspace gettimeofday(2) with HPET timecounter. Right now, userspace (fast) gettimeofday(2) on x86 only works for RDTSC. For older machines, like Core2, where RDTSC is not C2/C3 invariant, and which fall to HPET hardware, this means that the call has both the penalty of the syscall and of the uncached hw behind the QPI or PCIe connection to the sought bridge. Nothing can me done against the access latency, but the syscall overhead can be removed. System already provides mappable /dev/hpetX devices, which gives straight access to the HPET registers page. Add yet another algorithm to the x86 'vdso' timehands. Libc is updated to handle both RDTSC and HPET. For HPET, the index of the hpet device to mmap is passed from kernel to userspace, index might be changed and libc invalidates its mapping as needed. Remove cpu_fill_vdso_timehands() KPI, instead require that timecounters which can be used from userspace, to provide tc_fill_vdso_timehands{,32}() methods. Merge i386 and amd64 libc//sys/vdso_gettc.c into one source file in the new libc/x86/sys location. vdso_gettc() internal interface is changed to move timecounter algorithm detection into the MD code. Measurements show that RDTSC even with the syscall overhead is faster than userspace HPET access. But still, userspace HPET is three-four times faster than syscall HPET on several Core2 and SandyBridge? machines. Tested by: Howard Su Sponsored by: The FreeBSD Foundation MFC after: 1 month Differential revision: ​https://reviews.freebsd.org/D7473 Update #3175.
    Comment 20
    1. Ed Schouten, Thu, 12 Oct 2017 05:09:45 GMT

    In a9219e7/rtems:

    timecounter: Merge FreeBSD change r310053 Add labels to sysctls related to clocks. Sysctls like kern.eventtimer.et.*.quality currently embed the name of the clock device. This is problematic for the Prometheus metrics exporter for two reasons: Some of those clocks have dashes in their names, which Prometheus doesn't allow to be used in metric names. It doesn't allow for extracting the same property of all clocks on the system from within a single query. Attach these nodes to have a label, so that the Prometheus metrics exporter gives these metric a uniform name with the name of the clock attached as a label. Reviewed by: cem Differential Revision: ​https://reviews.freebsd.org/D8775 Update #3175.
    Comment 21
    1. Eric van Gyzen, Thu, 12 Oct 2017 05:09:57 GMT

    In 952b42b6/rtems:

    timecounter: Merge FreeBSD change r315280 When the RTC is adjusted, reevaluate absolute sleep times based on the RTC POSIX 2008 says this about clock_settime(2):
    If the value of the CLOCK_REALTIME clock is set via clock_settime(), the new value of the clock shall be used to determine the time of expiration for absolute time services based upon the CLOCK_REALTIME clock. This applies to the time at which armed absolute timers expire. If the absolute time requested at the invocation of such a time service is before the new value of the clock, the time service shall expire immediately as if the clock had reached the requested time normally.
    Setting the value of the CLOCK_REALTIME clock via clock_settime() shall have no effect on threads that are blocked waiting for a relative time service based upon this clock, including the nanosleep() function; nor on the expiration of relative timers based upon this clock. Consequently, these time services shall expire when the requested relative interval elapses, independently of the new or old value of the clock.
    When the real-time clock is adjusted, such as by clock_settime(3), wake any threads sleeping until an absolute real-clock time. Such a sleep is indicated by a non-zero td_rtcgen. The sleep functions will set that field to zero and return zero to tell the caller to reevaluate its sleep duration based on the new value of the clock. At present, this affects the following functions:
    pthread_cond_timedwait(3) pthread_mutex_timedlock(3) pthread_rwlock_timedrdlock(3) pthread_rwlock_timedwrlock(3) sem_timedwait(3) sem_clockwait_np(3)
    I'm working on adding clock_nanosleep(2), which will also be affected. Reported by: Sebastian Huber Reviewed by: jhb, kib MFC after: 2 weeks Relnotes: yes Sponsored by: Dell EMC Differential Revision: ​https://reviews.freebsd.org/D9791 Update #3175.
    Comment 22
    1. Eric van Gyzen, Thu, 12 Oct 2017 05:10:09 GMT

    In 5167d0e/rtems:

    timecounter: Merge FreeBSD change r315287 Add missing pieces of r315280 I moved this branch from github to a private server, and pulled from the wrong one when committing r315280, so I failed to include two recent commits. Thankfully, they were only cosmetic and were included in the review. Specifically: Add documentation, polish comments, and improve style(9). Tested by: pho (r315280) MFC after: 2 weeks Sponsored by: Dell EMC Differential Revision: ​https://reviews.freebsd.org/D9791 Update #3175.
    Comment 23
    1. Konstantin Belousov, Thu, 12 Oct 2017 05:10:22 GMT

    In bcbbe76/rtems:

    timecounter: Merge FreeBSD change r324528 The th_bintime, th_microtime and th_nanotime members of the timehand all cache the last system time (uptime + boottime). Only the format differs. Do not re-calculate the bintime and simply use the value used to calculate the microtime and nanotime. Group all the updates under the relevant comment. Remove obsoleted XXX part. Submitted by: Sebastian Huber MFC after: 1 week Update #3175.
    Comment 24
    1. Sebastian Huber, Thu, 12 Oct 2017 05:10:35 GMT

    In d8b6f1c/rtems:

    timecounter: Update FreeBSD identifiers Update #3175.
    Comment 25
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 26
    1. Joel Sherrill, Tue, 05 Dec 2017 14:28:46 GMT

    Is this done and can be closed? With an appropriate comment.

    Comment 27
    1. Joel Sherrill, Sat, 13 Oct 2018 22:46:08 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Closing since no feedback since Dec 2017

    Comment 28
    1. Amar Takhar, Sat, 20 Oct 2018 15:15:06 GMT

    Whoops, Joel closed this. I need to test the fix implemented in #3557 to make sure no developers that do not have an account on trac receive an email.

    Comment 29
    1. Amar Takhar, Sat, 20 Oct 2018 15:21:27 GMT
    2. blockedby: set to 3557

    3176 - __getreent in libc.a and generated by confdefs.h

    Link https://devel.rtems.org/ticket/3176
    Id 3176
    Reporter Joel Sherrill
    Created 10 October 2017 14:40:33
    Modified 17 September 2018 11:10:42
    Owner Joel Sherrill
    Type defect
    Component tool/newlib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Some applications are getting duplicate symbol definitions for getreent(). One of the examples-v2 programs is doing this. It is because there are two bodies for this method -- one from confdefs.h and another from newlib.

    ​https://sourceware.org/ml/newlib/2017/msg01020.html addresses the issues and needs to be incorporated by the RSB.

    ​https://sourceware.org/ml/newlib/2017/msg01019.html is a cleanup that was spotted at the same time. It can be picked up by a newlib snapshot.

    Comment 1
    1. Joel Sherrill, Wed, 11 Oct 2017 10:31:43 GMT
    2. milestone: set to 4.12.0

    This needs to be fixed for 4.12. I haven't checked if this is also needed for 4.11. If 4.11 confdefs.h defines getreent(), then it has the bug also.

    Comment 2
    1. Joel Sherrill, Thu, 12 Oct 2017 00:29:05 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 4
    1. Sebastian Huber, Mon, 17 Sep 2018 11:10:42 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    This is fixed at least since [d7fd32078a45c1fc7ceed58528e0c6a193383104/rtems-source-builder].


    3177 - Replace/update POSIX Compliance Guide

    Link https://devel.rtems.org/ticket/3177
    Id 3177
    Reporter Joel Sherrill
    Created 11 October 2017 22:36:34
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The POSIX Compliance Guide was never converted from texinfo. Beyond that, it is out of date and follows the outline of the printed version of the POSIX standard which no one sees anymore. This ticket proposes:

  • new Sphinx document
  • contents generated from POSIX API tracking spreadsheet (CSV)
  • outline per .h file, not functional area
  • use bullets, not tables so easier to format
  • Comment 1
    1. Joel Sherrill, Wed, 11 Oct 2017 22:37:09 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    4. component: changed from admin to doc
    5. milestone: set to 4.12.0
    Comment 2
    1. Chris Johns, Thu, 12 Oct 2017 19:29:47 GMT
    2. owner: changed from Joel Sherrill to Chris Johns

    Add waf support to convert the CSV file to ReST.

    Comment 3
    1. Chris Johns, Fri, 13 Oct 2017 01:26:12 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 2804294/rtems-docs:

    posix-compliance: Add automatic generation of the ReST file from CSV data. Closes #3177.
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3178 - Update sh-rtems4.12 bset to use rtems-default (using old gcc)

    Link https://devel.rtems.org/ticket/3178
    Id 3178
    Reporter Joel Sherrill
    Created 12 October 2017 01:11:16
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill <joel@…>
    Type defect
    Component tool/gcc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I built a toolset and all BSPs on Centos 7 after switching this to rtems-default.bset again. There was no comment indicating why it was using an older gcc so I assume something has been fixed.

    Comment 1
    1. Joel Sherrill, Thu, 12 Oct 2017 02:15:31 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In c7f286e/rtems-source-builder:

    rtems-sh.bset: Use default toolset specifically GCC 7 Closes #3178.
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3179 - New warnings from Time Changes

    Link https://devel.rtems.org/ticket/3179
    Id 3179
    Reporter Joel Sherrill
    Created 12 October 2017 01:23:54
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    New warnings after picking up your recent commits. How are you checking for warnings?

    ../../../../../../rtems/c/src/../../cpukit/posix/src/pthreadattrdefault.c:58:5: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
    &_POSIX_Threads_Default_attributes.affinitysetpreallocated,
    ^
    ../../../../../../rtems/c/src/../../cpukit/posix/src/adjtime.c: In function 'adjtime':
    ../../../../../../rtems/c/src/../../cpukit/posix/src/adjtime.c:85:16: warning: passing argument 1 of '_TOD_Adjust' from incompatible pointer type [-Wincompatible-pointer-types]
    _TOD_Adjust( &delta_as_timestamp );
    ^
    In file included from ../../../../../../rtems/c/src/../../cpukit/posix/src/adjtime.c:28:0:
    ../../cpukit/../../../erc32/lib/include/rtems/score/todimpl.h:287:6: note: expected 'const struct timespec *' but argument is of type 'Timestamp_Control * {aka long long int *}'
    void _TOD_Adjust(
    ^~~~~~~~~~~
    sparc-rtems4.12-ar: `u' modifier ignored since `D' is the default (see `U')
    sparc-rtems4.12-ar: `u' modifier ignored since `D' is the default (see `U')
    sparc-rtems4.12-ar: `u' modifier ignored since `D' is the default (see `U')
    sparc-rtems4.12-ar: `u' modifier ignored since `D' is the default (see `U')
    ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/__times.c: In function '_times':
    ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/__times.c:60:31: warning: passing argument 1 of '_TOD_Get_zero_based_uptime' from incompatible pointer type [-Wincompatible-pointer-types]
    _TOD_Get_zero_based_uptime( &binuptime );
    ^
    In file included from ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/__times.c:35:0:
    ../../cpukit/../../../erc32/lib/include/rtems/score/todimpl.h:215:20: note: expected 'Timestamp_Control * {aka long long int *}' but argument is of type 'struct bintime *'
    static inline void _TOD_Get_zero_based_uptime(
    ^~~~~~~~~~~~~~~~~~~~~~~~~~
    ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/__times.c:71:55: warning: passing argument 2 of '_Thread_Get_CPU_time_used' from incompatible pointer type [-Wincompatible-pointer-types]
    _Thread_Get_CPU_time_used( _Thread_Get_executing(), &bin_cpu_time_used );
    ^
    In file included from ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/__times.c:37:0:
    ../../cpukit/../../../erc32/lib/include/rtems/score/threadimpl.h:906:6: note: expected 'Timestamp_Control * {aka long long int *}' but argument is of type 'struct bintime *'
    void _Thread_Get_CPU_time_used(
    ^~~~~~~~~~~~~~~~~~~~~~~~~
    Comment 1
    1. Joel Sherrill, Thu, 12 Oct 2017 01:24:09 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 12 Oct 2017 05:20:28 GMT

    In 58500540/rtems:

    posix: Fix const qualifier warning Update #2514. Update #3179.
    Comment 3
    1. Sebastian Huber, Thu, 12 Oct 2017 05:27:11 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 16db540a/rtems:

    Use right time format in _times() Update #2740. Close #3179.
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3180 - ar warning: u' modifier ignored sinceD' is the default (see `U')

    Link https://devel.rtems.org/ticket/3180
    Id 3180
    Reporter Joel Sherrill
    Created 12 October 2017 01:25:21
    Modified 22 October 2018 05:52:46
    Owner Sebastian Huber
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove this warning

    sparc-rtems4.12-ar: `u' modifier ignored since `D' is the default (see `U') 
    Comment 1
    1. Joel Sherrill, Thu, 12 Oct 2017 01:41:30 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    4. severity: changed from blocker to normal
    5. milestone: changed from 4.12.0 to Indefinite

    This appears to be related to deterministic archives per this discussion.

    I tried to find the magic combination of options but have had no luck.

    Comment 2
    1. Sebastian Huber, Mon, 22 Oct 2018 05:52:46 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    4. milestone: changed from Indefinite to 5.1

    Fixed by [637546a659cd71fba108bbdce4478e466d3b65bb/rtems].


    3181 - Various cc1plus warnings for "valid for C/ObjC but not for C++"

    Link https://devel.rtems.org/ticket/3181
    Id 3181
    Reporter Joel Sherrill
    Created 12 October 2017 02:30:54
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill <joel@…>
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Fix these

    cc1plus: warning: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++
    cc1plus: warning: command line option '-Wimplicit-function-declaration' is valid for C/ObjC but not for C++
    cc1plus: warning: command line option '-Wstrict-prototypes' is valid for C/ObjC but not for C++
    cc1plus: warning: command line option '-Wnested-externs' is valid for C/ObjC but not for C++
    Comment 1
    1. Joel Sherrill, Thu, 12 Oct 2017 02:35:11 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 14e5a08/rtems:

    Fix warnings for using C/ObjC specific GCC flags with C++ Closes #3181.
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3182 - CLOCK_REALTIME timeout implementation is not POSIX compliant

    Link https://devel.rtems.org/ticket/3182
    Id 3182
    Reporter Sebastian Huber
    Created 12 October 2017 05:35:17
    Modified 22 March 2018 08:06:14
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Changes of the CLOCK_REALTIME must trigger absolute timeouts. This is not the case. There is no test for this in RTEMS.

    Comment 1
    1. Joel Sherrill, Thu, 12 Oct 2017 17:34:48 GMT

    I think this only can be used via clock_nanosleep() or a timeout on a condition variable. Do both not wakeup after a time change on CLOCK_REALTIME?

    Are there tests for this?

    Comment 2
    1. Sebastian Huber, Fri, 13 Oct 2017 08:07:57 GMT

    See also:

    ​http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_settime.html

    Test case (runs on Linux as root):

    ​https://lists.rtems.org/pipermail/devel/2017-October/019186.html

    Comment 3
    1. Sebastian Huber, Fri, 13 Oct 2017 08:08:28 GMT
    2. description: modified (diff)
    Comment 4
    1. Sebastian Huber, Tue, 17 Oct 2017 06:31:01 GMT

    In bf2a53d2/rtems:

    score: Rename watchdog variants Rename PER_CPU_WATCHDOG_RELATIVE in PER_CPU_WATCHDOG_MONOTONIC to highlight the corresponding POSIX CLOCK_MONOTONIC. Rename PER_CPU_WATCHDOG_ABSOLUTE in PER_CPU_WATCHDOG_REALTIME to highlight the corresponding POSIX CLOCK_REALTIME. Update #3117. Update #3182.
    Comment 5
    1. Sebastian Huber, Tue, 17 Oct 2017 06:31:14 GMT

    In 91ce012c/rtems:

    score: Rename _Watchdog_Per_CPU_insert_monotonic() Rename _Watchdog_Per_CPU_insert_monotonic() in _Watchdog_Per_CPU_insert_ticks(). Update #3117. Update #3182.
    Comment 6
    1. Sebastian Huber, Tue, 17 Oct 2017 11:57:07 GMT

    In 9a583a9/rtems-libbsd:

    SLEEPQUEUE(9): Update due to API changes Update #3117. Update #3182.
    Comment 7
    1. Sebastian Huber, Thu, 19 Oct 2017 12:47:54 GMT

    According to POSIX we have for clock_nanosleep():

    ​http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html

    "If, at the time of the call, the time value specified by rqtp is less than or equal to the time value of the specified clock, then clock_nanosleep() shall return immediately and the calling process shall not be suspended."

    Would it be all right to perform a sched_yield() in this case? This would make the implementation of the thread queue enqueue a bit easier.

    Comment 8
    1. Joel Sherrill, Thu, 19 Oct 2017 13:03:51 GMT

    I think having a time in the past yield is a good solution. Just add it to the documentation in the right spots.

    Comment 9
    1. Sebastian Huber, Thu, 19 Oct 2017 13:06:45 GMT

    A yield may lead to a pre-emption. I am not sure if this is all right with respect to the "return immediately and the calling process shall not be suspended".

    Comment 10
    1. Sebastian Huber, Thu, 19 Oct 2017 13:40:08 GMT

    Why is nanosleep() not implemented as clock_nanosleep(CLOCK_REALTIME, 0, rqtp, rmtp)?

    Comment 11
    1. Joel Sherrill, Thu, 19 Oct 2017 13:44:02 GMT

    History. nanosleep has been there much longer.

    Comment 12
    1. Sebastian Huber, Tue, 24 Oct 2017 08:20:14 GMT

    In d85c94c0/rtems:

    psxclockrealtime01: New test Update #3182.
    Comment 13
    1. Sebastian Huber, Tue, 24 Oct 2017 08:20:25 GMT

    In 02878626/rtems:

    score: Add _Thread_Add_timeout_ticks() Replace _Thread_Timer_insert_monotonic() with _Thread_Add_timeout_ticks(). Update #3117. Update #3182.
    Comment 14
    1. Sebastian Huber, Tue, 24 Oct 2017 08:20:37 GMT

    In 27cfe7c/rtems:

    score: Add _Watchdog_Ticks_per_second This value is frequently used. Avoid the function call overhead and the integer division at run-time. Update #3117. Update #3182.
    Comment 15
    1. Sebastian Huber, Tue, 24 Oct 2017 08:20:49 GMT

    In e0dc6ef/rtems:

    rtems: Simplify RTEMS_MILLISECONDS_TO_MICROSECONDS Remove the cast so that it can be used in C pre-processor directives. Update #3117. Update #3182.
    Comment 16
    1. Sebastian Huber, Tue, 24 Oct 2017 08:21:01 GMT

    In 381ef5c/rtems:

    confdefs: Warn about problematic ticks per second A non-integer clock ticks per second value may lead to inaccurate time format conversions. Update #3117. Update #3182.
    Comment 17
    1. Sebastian Huber, Tue, 24 Oct 2017 08:21:13 GMT

    In ecef3698/rtems:

    score: Rename _Watchdog_Ticks_from_*() Rename _Watchdog_Ticks_from_*() to _Watchdog_Realtime_from_*(). This highlights that these routines are used for the CLOCK_REALTIME watchdogs (in contrast to CLOCK_MONOTONIC). Update #3117. Update #3182.
    Comment 18
    1. Sebastian Huber, Tue, 24 Oct 2017 08:21:25 GMT

    In adaf5c23/rtems:

    score: _Watchdog_Is_far_future_realtime_timespec() Update #3117. Update #3182.
    Comment 19
    1. Sebastian Huber, Tue, 24 Oct 2017 08:21:36 GMT

    In d16d07f/rtems:

    score: Add _Watchdog_Is_valid_interval_timespec() Update #3117. Update #3182.
    Comment 20
    1. Sebastian Huber, Tue, 24 Oct 2017 08:21:48 GMT

    In 7ed377b/rtems:

    score: _Watchdog_Is_far_future_monotonic_timespec Update #3117. Update #3182.
    Comment 21
    1. Sebastian Huber, Tue, 24 Oct 2017 08:22:00 GMT

    In cea5ff7/rtems:

    score: Add _Watchdog_Nanoseconds_per_tick Move it from the configuration to a separate variable. Update #3117. Update #3182.
    Comment 22
    1. Sebastian Huber, Tue, 24 Oct 2017 08:22:12 GMT

    In b13ec80/rtems:

    score: Add _Watchdog_Monotonic_from_timespec() Update #3117. Update #3182.
    Comment 23
    1. Sebastian Huber, Tue, 24 Oct 2017 08:22:24 GMT

    In 5747962/rtems:

    score: _Watchdog_Per_CPU_lazy_insert_monotonic() Update #3117. Update #3182.
    Comment 24
    1. Sebastian Huber, Tue, 24 Oct 2017 08:22:36 GMT

    In 6de1f92/rtems:

    score: Add _Thread_Continue() Update #3117. Update #3182.
    Comment 25
    1. Sebastian Huber, Tue, 24 Oct 2017 08:22:48 GMT

    In 1666ffe5/rtems:

    score: Rename function threadq support function Rename _Thread_queue_Context_set_do_nothing_enqueue_callout() into _Thread_queue_Context_set_enqueue_do_nothing_extra(). More _Thread_queue_Context_set_enqueue_*() functions will follow. Update #3117. Update #3182.
    Comment 26
    1. Sebastian Huber, Tue, 24 Oct 2017 08:23:00 GMT

    In c3105894/rtems:

    score: Move thread queue timeout handling Update #3117. Update #3182.
    Comment 27
    1. Sebastian Huber, Wed, 25 Oct 2017 05:54:30 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In c5161ee/rtems-docs:

    posix-users: Clarify timed operation errors Close #3182.
    Comment 28
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 29
    1. Sebastian Huber, Thu, 22 Mar 2018 07:43:06 GMT

    In 3da2f471/rtems:

    mpci: Update due to thread queue API changes Update #3117. Update #3182.
    Comment 30
    1. Sebastian Huber, Thu, 22 Mar 2018 08:06:14 GMT

    In 7353422f/rtems:

    mpci: Fix _MPCI_Enqueue_callout() Update #3117. Update #3182.

    3185 - Change uptime seconds to int32_t

    Link https://devel.rtems.org/ticket/3185
    Id 3185
    Reporter Sebastian Huber
    Created 12 October 2017 11:27:33
    Modified 9 November 2017 12:40:44
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The use of a 64-bit integer for the uptime seconds is overkill. Use int32_t instead for _Timecounter_Time_uptime. Change derived APIs, e.g. rtems_clock_get_uptime_seconds().

    Comment 1
    1. Sebastian Huber, Thu, 12 Oct 2017 11:27:47 GMT
    2. summary: changed from Change uptime to int32_t to Change uptime seconds to int32_t
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 07:09:37 GMT

    In c6b890c/rtems-source-builder:

    5: Add Newlib patches Update #3185. Close #3189.
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 07:14:19 GMT

    In 5f02a57/rtems:

    score: Change _Timecounter_Time_uptime to int32_t Move basic timecounter API shared with BSD network stack to . Update #3185.
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 12:39:54 GMT

    In b225aa1/rtems:

    Reject incompatible tool chains Update #3185.
    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 12:40:44 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3187 - smptests/Makefile.am Issues

    Link https://devel.rtems.org/ticket/3187
    Id 3187
    Reporter Joel Sherrill
    Created 12 October 2017 18:32:24
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    There appear to be two issues in smptests/Makefile.am:

  • smppsxaffinity0[12] are listed twice. This causes a warning.
    I am unsure if they should always be built or only when POSIX
    is enabled.
  • smppsxmutex01 is listed in the "HAS_POSIX" section. Aren't
    POSIX mutexes always on now so this test should not be
    inside the conditional?
  • Comment 1
    1. Joel Sherrill, Thu, 12 Oct 2017 18:32:53 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    4. component: changed from admin to build
    Comment 2
    1. Sebastian Huber, Fri, 13 Oct 2017 04:55:00 GMT

    It is a bit work left to enable the POSIX tests by default, e.g. a lot of them use pthread_create().

    Comment 3
    1. Sebastian Huber, Wed, 25 Oct 2017 05:59:02 GMT

    The 2. is a duplicate of #2514.

    Comment 4
    1. Sebastian Huber, Wed, 25 Oct 2017 05:59:40 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In e3ef14b/rtems:

    smptests: Remove duplicate Makefile targets Close #3187.
    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3188 - Add C11 Threading Examples

    Link https://devel.rtems.org/ticket/3188
    Id 3188
    Reporter Joel Sherrill
    Created 12 October 2017 19:21:24
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    C11 is new and we need to provide examples.

    Comment 1
    1. Joel Sherrill, Thu, 12 Oct 2017 19:21:40 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Thu, 12 Oct 2017 19:22:36 GMT

    Add c11 directory to examples-v2 which contains a set of examples for using the entire C11 API.

    c11_thread01 - multiple threads, arguments, yield, sleep c11_mutex01 - mutual exclusion, blocking, timeout c11_cndvar01 - use condition variable to signal data arrival c11_key01 - per thread storage

    Comment 3
    1. Joel Sherrill, Thu, 12 Oct 2017 19:23:27 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 1963961/examples-v2:

    Add examples for using the entire C11 API. c11_thread01 - multiple threads, arguments, yield, sleep c11_mutex01 - mutual exclusion, blocking, timeout c11_cndvar01 - use condition variable to signal data arrival c11_key01 - per thread storage Closes #3188.
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3189 - MUTEX_INITIALIZER missing braces warning

    Link https://devel.rtems.org/ticket/3189
    Id 3189
    Reporter Joel Sherrill
    Created 13 October 2017 01:50:07
    Modified 9 November 2017 07:09:37
    Owner Sebastian Huber
    Type defect
    Component tool/newlib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Hi

    Multiple tests have this warning. Appears to be something not quite right in the newlib .h files.

     21 ../../../../../../../rtems/c/src/../../testsuites/psxtests/psxhdrs/pthread/pthread_mutex_unlock.c:27:27: warning: missing braces around initializer [-Wmissing-braces]
    21 ../../../../../../../rtems/c/src/../../testsuites/psxtests/psxhdrs/pthread/pthread_mutex_trylock.c:27:27: warning: missing braces around initializer [-Wmissing-braces]
    21 ../../../../../../../rtems/c/src/../../testsuites/psxtests/psxhdrs/pthread/pthread_mutex_timedlock.c:30:27: warning: missing braces around initializer [-Wmissing-braces]
    21 ../../../../../../../rtems/c/src/../../testsuites/psxtests/psxhdrs/pthread/pthread_mutex_lock.c:27:27: warning: missing braces around initializer [-Wmissing-braces]
    21 ../../../../../../../rtems/c/src/../../testsuites/psxtests/psxhdrs/pthread/pthread_mutex_init.c:27:31: warning: missing braces around initializer [-Wmissing-braces]
    21 ../../../../../../../rtems/c/src/../../testsuites/psxtests/psxhdrs/pthread/pthread_mutex_destroy.c:27:28: warning: missing braces around initializer [-Wmissing-braces]
    21 ../../../../../../../rtems/c/src/../../testsuites/psxtests/psxhdrs/pthread/pthread_cond_wait.c:28:27: warning: missing braces around initializer [-Wmissing-braces]
    21 ../../../../../../../rtems/c/src/../../testsuites/psxtests/psxhdrs/pthread/pthread_cond_timedwait.c:28:27: warning: missing braces around initializer [-Wmissing-braces]
    21 ../../../../../../../rtems/c/src/../../testsuites/psxtests/psxautoinit02/init.c:33:25: warning: missing braces around initializer [-Wmissing-braces]
    21 ../../../../../../../rtems/c/src/../../testsuites/psxtests/psxautoinit01/init.c:29:28: warning: missing braces around initializer [-Wmissing-braces]
    21 ../../../../../../../rtems/c/src/../../testsuites/psxtests/psxautoinit01/init.c:28:28: warning: missing braces around initializer [-Wmissing-braces]
    21 ../../../../../../../rtems/c/src/../../testsuites/psxtests/psx0
    Comment 1
    1. Joel Sherrill, Fri, 13 Oct 2017 01:50:22 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Fri, 13 Oct 2017 06:04:01 GMT

    How did you get these warnings? I get them when I turn on -Wsystem-headers by hand.

    Comment 3
    1. Sebastian Huber, Fri, 13 Oct 2017 06:09:49 GMT

    Fixed in Newlib. I will integrate this with the October Newlib snapshot.

    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 07:09:37 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In c6b890c/rtems-source-builder:

    5: Add Newlib patches Update #3185. Close #3189.

    3190 - RTEMS Tester covoar does not link on MacOS

    Link https://devel.rtems.org/ticket/3190
    Id 3190
    Reporter Chris Johns
    Created 13 October 2017 16:29:18
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords covoar
    Cc  
    Blocking  
    Blocked by  

    Description

    The executables do not link on MacOS.

    Comment 1
    1. Chris Johns, Fri, 13 Oct 2017 16:31:25 GMT
    2. component: changed from admin to tool
    Comment 2
    1. Chris Johns, Fri, 13 Oct 2017 16:34:25 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 0054585/rtems-tools:

    tester/covoar: Use standard waf modules for linking. Use the standard modules use option for building executables and let waf figure out the platform specifics. Closes #3190.
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3191 - RTEMS Tester covoar dies with no arguments.

    Link https://devel.rtems.org/ticket/3191
    Id 3191
    Reporter Chris Johns
    Created 13 October 2017 16:30:48
    Modified 2 January 2018 23:00:41
    Owner Joel Sherrill
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Running covoar terminate with an unhandled exception with no arguments on the command line:

    $ ./build/tester/covoar/covoar
    error missing option: target -T
    Usage: ./build/tester/covoar/covoar [-v] -T TARGET -f FORMAT [-E EXPLANATIONS] -1 EXECUTABLE coverage1 ... coverageN
    --OR--
    Usage: ./build/tester/covoar/covoar [-v] -T TARGET -f FORMAT [-E EXPLANATIONS] -e EXE_EXTENSION -c COVERAGEFILE_EXTENSION EXECUTABLE1 ... EXECUTABLE2
    -v - verbose at initialization
    -T TARGET - target name
    -f FORMAT - coverage file format (RTEMS, QEMU, TSIM or Skyeye)
    -E EXPLANATIONS - name of file with explanations
    -s SYMBOLS_FILE - name of file with symbols of interest
    -1 EXECUTABLE - name of executable to get symbols from
    -e EXE_EXTENSION - extension of the executables to analyze
    -c COVERAGEFILE_EXTENSION - extension of the coverage files to analyze
    -g GCNOS_LIST - name of file with list of *.gcno files
    -p PROJECT_NAME - name of the project
    -C ConfigurationFileName - name of configuration file
    -O Output_Directory - name of output directory (default=.
    libc++abi.dylib: terminating with uncaught exception of type std::__1::basic_string, std::__1::allocator >
    Abort trap: 6
    Comment 1
    1. Joel Sherrill, Wed, 01 Nov 2017 20:43:46 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 3
    1. Joel Sherrill, Tue, 05 Dec 2017 14:05:02 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In b516a58/rtems-tools:

    tester/covoar/covoar.cc: Exit using exit() rather than just throwing. Closes #3191.
    Comment 4
    1. Joel Sherrill, Tue, 02 Jan 2018 23:00:41 GMT

    In 0333442/rtems-tools:

    tester/covoar/covoar.cc: Add missing throw keyword Why clang caught this and gcc didn't is a mystery. Updates #3191.

    3198 - Add lazy update of line control and baud divisor to NS16550 serial driver

    Link https://devel.rtems.org/ticket/3198
    Id 3198
    Reporter Sebastian Huber
    Created 18 October 2017 05:18:39
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component dev/serial
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Updates of the line control and baud divisor while transfers are in progress may lead to unpredictable behaviour on some chips. Perform the updates only if necessary.

    Comment 1
    1. Sebastian Huber, Wed, 18 Oct 2017 06:52:56 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 67015b6/rtems:

    dev/serial: Lazy update of NS16550 settings Updates of the line control and baud divisor while transfers are in progress may lead to unpredictable behaviour on some chips. Perform the updates only if necessary. Close #3198.
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3200 - m32c tests don't build -- test_context too large

    Link https://devel.rtems.org/ticket/3200
    Id 3200
    Reporter Joel Sherrill
    Created 23 October 2017 14:22:22
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    ../../../../../../../rtems/c/src/../../testsuites/tmtests/tmfine01/init.c:58:21: error: size of variable 'test_instance' is too large

    static test_context test_instance;

    FWIW I marked this as unspecified because this is just a generic small target issue.

    Comment 1
    1. Joel Sherrill, Mon, 23 Oct 2017 14:22:32 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Mon, 23 Oct 2017 18:12:30 GMT
    2. owner: changed from Chris Johns to Sebastian Huber

    The number of resources needs to be lowered on m32c. It has limited indexing and offset ability in its instructions. This patch lets it compile. Is this OK to commit?

    git diff

    diff --git a/testsuites/tmtests/tmfine01/init.c b/testsuites/tmtests/tmfine01/i index 31843ce..4d9e6ec 100644 --- a/testsuites/tmtests/tmfine01/init.c +++ b/testsuites/tmtests/tmfine01/init.c @@ -28,7 +28,11 @@

    const char rtems_test_name[] = "TMFINE 1";

    +#if defined(m32c) +#define CPU_COUNT 3 +#else

    #define CPU_COUNT 32

    +#endif

    #define MSG_COUNT 3

    Comment 3
    1. Sebastian Huber, Tue, 24 Oct 2017 07:28:08 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 0e1ad7fa/rtems:

    tmtests/tmfine01: Reduce test context size Reduce test context size in non-SMP configurations. Close #3200.
    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3201 - epiphany tools checksum error

    Link https://devel.rtems.org/ticket/3201
    Id 3201
    Reporter Joel Sherrill
    Created 23 October 2017 14:24:00
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill <joel@…>
    Type defect
    Component arch/epiphany
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I assume this is a side-effect of the recent checksum changes. If that's the case, it just needs to be updated. Otherwise, it is a more serious error.

    download: (full) ​https://github.com/adapteva/epiphany-gcc/archive/f7051762470c42ce7f01baa7edeb113d51c7dd72.zip -> sources/f7051762470c42ce7f01baa7edeb113d51c7dd72.zip
    download: ​https://github.com/adapteva/epiphany-gcc/archive/f7051762470c42ce7f01baa7edeb113d51c7dd72.zip -> sources/f7051762470c42ce7f01baa7edeb113d51c7dd72.zip

    redirect: ​https://codeload.github.com/adapteva/epiphany-gcc/zip/f7051762470c42ce7f01baa7edeb113d51c7dd72 redirect: ​https://codeload.github.com/adapteva/epiphany-gcc/zip/f7051762470c42ce7f01baa7edeb113d51c7dd72

    checksums: f7051762470c42ce7f01baa7edeb113d51c7dd72.zip: 4d911e7bff4f1827dd7712669d20e4a1bf02806df0fae113ff0e7d13466bef2e => 2b2034fd12f2fd5108205ade66400c175ede8cef8141a38ae03fc78bf2d65325
    warning: checksum error: f7051762470c42ce7f01baa7edeb113d51c7dd72.zip
    error: checksum failure file: sources/f7051762470c42ce7f01baa7edeb113d51c7dd72.zip

    Comment 1
    1. Joel Sherrill, Mon, 23 Oct 2017 17:20:00 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 6c60a4b/rtems-source-builder:

    rtems-epiphany.bset: Add sha512sum for GCC git repository Closes #3201.
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3202 - or1k tools build error

    Link https://devel.rtems.org/ticket/3202
    Id 3202
    Reporter Joel Sherrill
    Created 23 October 2017 14:24:53
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill <joel@…>
    Type defect
    Component arch/or1k
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I assume this is a side-effect of recent checksum changes. Otherwise, there is a serious problem.

    ownload: (full) ​https://git.rtems.org/rtems-tools/plain/tools/4.12/gdb/gdb-7.11-sis-leon2-leon3.diff -> patches/gdb-7.11-sis-leon2-leon3.diff
    download: ​https://git.rtems.org/rtems-tools/plain/tools/4.12/gdb/gdb-7.11-sis-leon2-leon3.diff -> patches/gdb-7.11-sis-leon2-leon3.diff
    checksums: gdb-7.11-sis-leon2-leon3.diff: 0b8b2a23c7d1592315fe0130188f457c80f8b1e26645535bed091a5e0671682dc44a1987d00e6939a1b1c562c7579404db43183e666c29c2b479446aa61ca4f6 => 4c44afec9c00a45b9322d787da3796f3294f207ddae9fe9faab3327b6991ac75
    warning: checksum error: gdb-7.11-sis-leon2-leon3.diff
    error: checksum failure file: patches/gdb-7.11-sis-leon2-leon3.diff

    Comment 1
    1. Joel Sherrill, Mon, 23 Oct 2017 14:25:04 GMT
    2. description: modified (diff)
    Comment 2
    1. Joel Sherrill, Mon, 23 Oct 2017 16:18:07 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 5295cb8/rtems-source-builder:

    rtems-gdb-7.11-1.cfg: Correct sha512sum on gdb-7.11-sis-leon2-leon3.diff Closes #3202.
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3203 - Upgrade trac to fix numerous problems.

    Link https://devel.rtems.org/ticket/3203
    Id 3203
    Reporter Amar Takhar
    Created 23 October 2017 20:01:53
    Modified 20 October 2018 23:01:00
    Owner Amar Takhar
    Type infra
    Component admin
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity major
    Keywords  
    Cc Sebastian Huber Chris Johns thomas.doerfler Joel Sherrill
    Blocking  
    Blocked by  

    Description

    There are a ton of issues going on with trac that need to be resolved. The two major ones are:

    • The ticket commenter emails people who aren't a trac user. This may require a custom modification.
    • The always_email setting is taking things too literally and always sending emails even if it shouldn't.
    • The Git plug-in consistently spins, floods the jail with processes then the site dies.
    • Frequent, strange and random crashes.
      • This one is not a huge deal since it's just that request process users won't even notice when this happens.

    Upgrading trac is a weeklong project usually I will start preparing for it and update here.

    If anyone has any feature requests now is the time to do it!

    Comment 1
    1. Amar Takhar, Sat, 20 Oct 2018 23:01:00 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    4. milestone: set to 5.1

    The first 2 items are fixed which were the most important.

    The last two will only be fixed by a major upgrade which is a lot of work. There's a lot of custom glue we work and it will be a rewrite for most of it for 1.3. Not a bad thing since 1.3 is far superior to 1.2

    I'll call this fixed and open a new ticket for the upgrade when the time comes I've made so many changes this ticket is no longer relevant.


    3204 - Exception in rtems-test

    Link https://devel.rtems.org/ticket/3204
    Id 3204
    Reporter Joel Sherrill
    Created 23 October 2017 20:34:03
    Modified 13 December 2019 14:27:38
    Owner Chris Johns
    Type defect
    Component tool
    Status closed
    Resolution worksforme
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Note: No category for rtems-tools.

    My first attempt to send run logs didn't go so well. This was a weird failure mode. It didn't exit but had to be killed by hand. I dropped off the options related to mailing the log and it still failed. This is on an up to date CentOS 7 (rtbf64c 7.4) as well as my 7.3 VM.

    + /home/joel/rtems-work/rtems-tools//tester/rtems-test --rtems-tools=/home/joel/rtems-work/tools/4.12 --rtems-bsp=erc32 --log=run.log --mail --mail-from=joel@rtems.org --mail-to=build@lists.rtems.org ./sparc-rtems4.12/c/erc32/testsuites/samples/ticker/ticker.exe ./sparc-rtems4.12/c/erc32/testsuites/samples/minimum/minimum.exe ./sparc-rtems4.12/c/erc32/testsuites/samples/iostream/cxx_iostream.exe ./sparc-rtems4.12/c/erc32/testsuites/samples/fileio/fileio.exe ./sparc-rtems4.12/c/erc32/testsuites/samples/capture/capture.exe ./sparc-rtems4.12/c/erc32/testsuites/samples/nsecs/nsecs.exe ./sparc-rtems4.12/c/erc32/testsuites/samples/paranoia/paranoia.exe ./sparc-rtems4.12/c/erc32/testsuites/samples/cdtest/cdtest.exe ./sparc-rtems4.12/c/erc32/testsuites/samples/base_sp/base_sp.exe ./sparc-rtems4.12/c/erc32/testsuites/samples/unlimited/unlimited.exe ./sparc-rtems4.12/c/erc32/testsuites/samples/hello/hello.exe
    RTEMS Testing - Tester, 4.12 (52513610668b)
    [ 5/11] p:0 f:0 u:0 e:0 I:0 B:0 t:0 i:0 | sparc/erc32: hello.exe
    [ 6/11] p:0 f:0 u:0 e:0 I:0 B:0 t:0 i:0 | sparc/erc32: cxx_iostream.exe
    [ 3/11] p:0 f:0 u:0 e:0 I:0 B:0 t:0 i:0 | sparc/erc32: cdtest.exe
    [ 9/11] p:0 f:0 u:0 e:0 I:0 B:0 t:0 i:0 | sparc/erc32: paranoia.exe
    [ 7/11] p:0 f:0 u:0 e:0 I:0 B:0 t:0 i:0 | sparc/erc32: minimum.exe
    [ 1/11] p:0 f:0 u:0 e:0 I:0 B:0 t:0 i:0 | sparc/erc32: base_sp.exe
    [11/11] p:0 f:0 u:0 e:0 I:0 B:0 t:0 i:0 | sparc/erc32: unlimited.exe
    [ 4/11] p:0 f:0 u:0 e:0 I:0 B:0 t:0 i:0 | sparc/erc32: fileio.exe
    [10/11] p:0 f:0 u:0 e:0 I:0 B:0 t:0 i:0 | sparc/erc32: ticker.exe
    [ 2/11] p:0 f:0 u:0 e:0 I:0 B:0 t:0 i:0 | sparc/erc32: capture.exe
    [ 8/11] p:0 f:0 u:0 e:0 I:0 B:0 t:0 i:0 | sparc/erc32: nsecs.exe
    Traceback (most recent call last):
    File "/home/joel/rtems-work/rtems-tools//tester/rtems-test", line 40, in
    rt.test.run()
    File "/data/home/joel/rtems-work/rtems-tools/tester/rt/test.py", line 336, in run
    job_trace)
    File "/data/home/joel/rtems-work/rtems-tools/tester/rt/test.py", line 189, in report_finished
    reports.log(tst.executable, report_mode)
    File "/data/home/joel/rtems-work/rtems-tools/tester/rt/report.py", line 193, in log
    exe = path.basename(self.results[name]['exe'])
    File "/home/joel/rtems-work/rtems-tools/rtemstoolkit/path.py", line 77, in basename
    return shell(os.path.basename(path))
    File "/usr/lib64/python2.7/posixpath.py", line 121, in basename
    i = p.rfind('/') + 1
    AttributeError: 'NoneType' object has no attribute 'rfind'
    Comment 1
    1. Joel Sherrill, Mon, 23 Oct 2017 20:34:13 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Chris Johns, Tue, 24 Oct 2017 11:23:33 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In bf58911/rtems-tools:

    tester: Refactor to use INI format files for BSP configurations. Add support for user condfigurations files with the --user-config. Add support for a $HOME/.rtemstesterrc for a user configuration. Closes #3204.
    Comment 3
    1. Joel Sherrill, Tue, 24 Oct 2017 14:13:19 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    Seems to be worse now but at least the output isn't an exception trace. Updated, cleaned, and reinstalled. Both installed and from the source tree fail with this:

    [joel@rtbf64c b-erc32]$ /home/joel/rtems-work/tools/4.12/bin/rtems-test Incorrect RTEMS Tools installation [joel@rtbf64c b-erc32]$ ../rtems-tools/tester/rtems-test Incorrect RTEMS Tools installation

    Looking at the code, this is just a generic exception handler message.

    Comment 4
    1. Chris Johns, Tue, 24 Oct 2017 21:03:20 GMT

    Replying to Joel Sherrill:

    Seems to be worse now but at least the output isn't an exception trace. Updated, cleaned, and reinstalled.

    Thank you for the report. I am wondering is something is happening with the installed version I have broken. It looks like there is also some issues with the naming of the INI files and the BSP name I need to resolve.

    Both installed and from the source tree fail with this:

    [joel@rtbf64c b-erc32]$ /home/joel/rtems-work/tools/4.12/bin/rtems-test Incorrect RTEMS Tools installation [joel@rtbf64c b-erc32]$ ../rtems-tools/tester/rtems-test Incorrect RTEMS Tools installation

    Looking at the code, this is just a generic exception handler message.

    Yes, an import is broken. I need to do an install and test. I did not do this.

    Chris

    Comment 5
    1. Chris Johns, Tue, 24 Oct 2017 21:48:01 GMT

    Replying to Joel Sherrill:

    [joel@rtbf64c b-erc32]$ /home/joel/rtems-work/tools/4.12/bin/rtems-test Incorrect RTEMS Tools installation [joel@rtbf64c b-erc32]$ ../rtems-tools/tester/rtems-test Incorrect RTEMS Tools installation

    Sorry my mistake and a silly one. I was playing about seeing it YAML was installed and was checking a number of hosts and all my hosts seem to have support for Python while the 2.7 docs for Python have no such module. I left the line in by mistake. Your error supports the reason I have not added YAML support, we would need a module in our code.

    Comment 6
    1. Chris Johns, Tue, 24 Oct 2017 22:06:08 GMT

    In 41d0c34/rtems-tools:

    tester: Add a BSP field to each BSP INI configuration section. The INI section in a BSP configuration is the name of the INI file so each BSP configuration section needs a BSP. Updates #3204.
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 8
    1. Chris Johns, Fri, 19 Oct 2018 00:32:43 GMT

    Joel, is this ticket valid? Please close if fixed.

    Comment 9
    1. Chris Johns, Fri, 23 Nov 2018 03:54:05 GMT
    2. description: modified (diff)
    3. summary: changed from Exception in rtems-tester to Exception in rtems-test
    Comment 10
    1. Chris Johns, Fri, 23 Nov 2018 03:54:55 GMT

    Ping.

    Comment 11
    1. Joel Sherrill, Fri, 13 Dec 2019 14:27:38 GMT
    2. status: changed from reopened to closed
    3. resolution: set to worksforme

    This is old and I haven't seen this issue recently.


    3205 - Relative timespec timeouts are subject to integer overflows

    Link https://devel.rtems.org/ticket/3205
    Id 3205
    Reporter Sebastian Huber
    Created 24 October 2017 09:07:21
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    As a best-effort approach, a very large relative timeout should result in the maximum monotonic watchdog value and not in an undefined integer overflow.

    Comment 1
    1. Sebastian Huber, Fri, 03 Nov 2017 06:08:04 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 3e81d52/rtems:

    posix: Use far future for very long timeouts Close #3205.
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3207 - Supported Architectures Page is out of date

    Link https://devel.rtems.org/ticket/3207
    Id 3207
    Reporter Joel Sherrill
    Created 25 October 2017 12:49:10
    Modified 5 December 2017 16:51:05
    Owner  
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    ​https://devel.rtems.org/wiki/TBR/UserManual/SupportedCPUs is out of date. I have the information to update it if that's what we want to do.

    I don't know the best way to provide this broad view from 4.6 up on what architectures are supported. The wiki seems OK.

    Comment 1
    1. Chris Johns, Wed, 25 Oct 2017 22:23:34 GMT

    Is this a duplicate of #3206?

    The architecture and BSP is closely linked.

    Comment 2
    1. Joel Sherrill, Wed, 25 Oct 2017 22:26:58 GMT

    They are related but I tend to think the architecture page is OK to do by hand and the BSP page needs something where you can look at a file per release.

    Not 100% sure what the right answer is but the set of BSPs is more fluid than the set of architectures.

    And the porting guide could include adding an entry and the release procedure could include adding a column.

    Comment 3
    1. Chris Johns, Wed, 25 Oct 2017 22:36:30 GMT

    Replying to Joel Sherrill:

    Not 100% sure what the right answer is but the set of BSPs is more fluid than the set of architectures.

    Amar's database highlights a complexity hidden in just top level __architectures__, take ARM, we support a subset of the available variants and having this listed would be awesome.

    And the porting guide could include adding an entry and the release procedure could include adding a column.

    Column of?

    Comment 4
    1. Sebastian Huber, Thu, 26 Oct 2017 05:39:15 GMT

    I would move this information to the RTEMS CPU Architecture Supplement and delete the wiki page. We can add a chapter with obsoleted architectures and just mention the version which removed them.

    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 6
    1. Joel Sherrill, Tue, 05 Dec 2017 16:51:05 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    3209 - RSB should fail on this error

    Link https://devel.rtems.org/ticket/3209
    Id 3209
    Reporter Joel Sherrill
    Created 26 October 2017 19:01:06
    Modified 11 April 2018 02:01:37
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I was updating the md5's to sha512's on qemu and made a typo which resulted in this message:

    reporting: devel/qemu-git-1.cfg -> qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1.xml
    error: qemu-git-1.cfg:57: invalid number of hash args
    loading: vdeplug
    get: requires ()

    The error message did not result in the build aborting. Perhaps this should be a fatal error.

    The broken RSB fragment was in qemu-git-1.cfg:

     %patch add qemu %{rtems_http_git}/rtems-tools/plain/tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
    -%hash md5 0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch 6aa9dfc4522466ab4a463129b3b9cb1d
    +%hash md5 376ea9e07c4c8077b345af02856549843dff2ad73b5da5886c71e859c4a0849522c59dcd05724270756763438aecdb70211ea2ae8cac28056cb17da53c3981e1

    Attachments:

    1 Chris Johns, Tue, 10 Apr 2018 08:03:19 GMT
      attach: set to 0001-sb-config-Terminate-building-on-an-error.patch
     
    Comment 1
    1. Joel Sherrill, Thu, 26 Oct 2017 19:01:16 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Thu, 26 Oct 2017 19:03:21 GMT
    2. description: modified (diff)
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 4
    1. Chris Johns, Tue, 10 Apr 2018 07:55:58 GMT

    Are you sure the did continue? If you get an error the RSB switches to --dry-run mode.

    Maybe an option should be added to stop the build and if the option --keep-going the mode is switched to dry run?

    Comment 5
    1. Chris Johns, Wed, 11 Apr 2018 02:01:37 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 162cbda/rtems-source-builder:

    sb/config: Terminate building on an error. This changes the previous functionality where the RSB switch to dry run mode. This functionality can be enabled by adding --keep-going. Close #3209.

    3210 - Improve the RSB build email message

    Link https://devel.rtems.org/ticket/3210
    Id 3210
    Reporter Chris Johns
    Created 27 October 2017 06:20:10
    Modified 9 November 2017 06:27:14
    Owner Chris Johns
    Type enhancement
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords RSB
    Cc  
    Blocking  
    Blocked by  

    Description

    The message needs more detail to provide a suitable archive.

    Comment 1
    1. Chris Johns, Fri, 27 Oct 2017 06:27:12 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 0f97375/rtems-source-builder:

    sb: Provide a more detail email message. Close #3210.
    Comment 2
    1. Chris Johns, Fri, 27 Oct 2017 06:34:55 GMT

    In 70e3e5e/rtems-source-builder:

    sb: Set the to email address to build@…. Fix a minor bug in the to addr processing. Update #3210
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3211 - Fix pthread_create() with user provided stack

    Link https://devel.rtems.org/ticket/3211
    Id 3211
    Reporter Sebastian Huber
    Created 27 October 2017 06:58:22
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In case the user provides a stack with address and size, then do not alter the stack size.

    Comment 1
    1. Sebastian Huber, Sat, 28 Oct 2017 11:14:18 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 1d572eba/rtems:

    posix: Fix pthread_create() with user stack In case the user provides a stack with address and size, then do not alter the stack size. Close #3211.
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3212 - Qemu Fails to Build, RSB Gives Odd Traceback

    Link https://devel.rtems.org/ticket/3212
    Id 3212
    Reporter Joel Sherrill
    Created 27 October 2017 18:17:05
    Modified 12 December 2019 23:24:47
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution worksforme
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    After applying the attached patch to update the md5's to sha512's, something goes wrong in the RSB build of Qemu. There is nothing obvious from the qemu build directory. But it appears that the cd into the qemu git directory didn't work and it is acting on my RSB git clone. The RSB trace is:

    script: 78: cd "/data/home/joel/rtems-work/rtems-source-builder/bare/build/qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1"
    script: 79: echo "=> qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1:"
    script: 80: echo "==> %prep:"
    script: 81: build_top=$(pwd)
    script: 82: source_dir_qemu="qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144"
    source setup: qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144-x86_64-linux-gnu-1: source qemu -q -n qemu-42d58e7c6760cb9c55627c28ae538e27dcf2f144
    making dir: /data/home/joel/rtems-work/rtems-source-builder/bare/sources/git
    _url: git://git.qemu-project.org/qemu.git?pull?checkout=42d58e7c6760cb9c55627c28ae538e27dcf2f144?submodule=dtc -> /data/home/joel/rtems-work/rtems-source-builder/bare/sources/git/qemu.git
    cmd: (/data/home/joel/rtems-work/rtems-source-builder/bare/sources/git/qemu.git) /usr/bin/git status
    exe: ['/usr/bin/git', 'status']
    # On branch am
    # Untracked files:
    # (use "git add ..." to include in what will be committed)
    #
    # ../../../../am/
    # ../../../j_qemu
    # ../../../nohup.out
    # ../../../../gcc7/
    # ../../../../rtems/4.10-targets
    # ../../../../rtems/all
    # ../../../../rtems/chris
    # ../../../../rtems/do_a
    # ../../../../rtems/do_all
    # ../../../../rtems/nohup.out
    # ../../../../rtems/p_rm
    # ../../../../rtems/sh-gdb.diff
    nothing added to commit but untracked files present (use "git add" to track)
    cmd: (/data/home/joel/rtems-work/rtems-source-builder/bare/sources/git/qemu.git) /usr/bin/git clean -f -d
    exe: ['/usr/bin/git', 'clean', '-f', '-d']
    cmd: (/data/home/joel/rtems-work/rtems-source-builder/bare/sources/git/qemu.git) /usr/bin/git reset --hard
    exe: ['/usr/bin/git', 'reset', '--hard']
    HEAD is now at 96485e3 Add SHA512 checksums for qemu sources
    cmd: (/data/home/joel/rtems-work/rtems-source-builder/bare/sources/git/qemu.git) /usr/bin/git checkout master
    exe: ['/usr/bin/git', 'checkout', 'master']
    Switched to branch 'master'
    git: pull: git://git.qemu-project.org/qemu.git
    cmd: (/data/home/joel/rtems-work/rtems-source-builder/bare/sources/git/qemu.git) /usr/bin/git pull
    exe: ['/usr/bin/git', 'pull']
    Build Set: Time 0:05:24.810871
    abort: user terminated

    Attachments:

    1 Joel Sherrill, Fri, 27 Oct 2017 18:17:23 GMT
      attach: set to 0001-Add-SHA512-checksums-for-qemu-sources.patch
    Comment 1
    1. Joel Sherrill, Fri, 27 Oct 2017 18:18:09 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 3
    1. Chris Johns, Wed, 11 Apr 2018 02:09:16 GMT

    I see a patch for the checksums has already gone into the repo. See 18e1ba6a/rtems-source-builder. The attachment will not be merged.

    Comment 4
    1. Chris Johns, Wed, 11 Apr 2018 02:14:22 GMT

    This looks like git is walking up above the qemu.git top. I am not sure how to recreate the problem.

    Can this please be moved to another milestone and if it comes up in GSoC 2018 we can look into it and get a fix?

    Comment 5
    1. Chris Johns, Wed, 21 Nov 2018 02:14:45 GMT

    Replying to Chris Johns:

    Can this please be moved to another milestone and if it comes up in GSoC 2018 we can look into it and get a fix?

    Ping?

    Comment 6
    1. Joel Sherrill, Thu, 12 Dec 2019 23:24:47 GMT
    2. status: changed from assigned to closed
    3. resolution: set to worksforme

    This has aged out. Closing as "works for me" since qemu has been built many times since this ticket was filed. Open new ticket for new problems.


    3213 - Move erc32, leon2, leon3, psim and jmr3904 to Tier 2

    Link https://devel.rtems.org/ticket/3213
    Id 3213
    Reporter Joel Sherrill
    Created 27 October 2017 19:08:31
    Modified 13 December 2019 15:46:49
    Owner Chris Johns
    Type enhancement
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Based on these results on gdb simulators, please bump these to Tier 2.

    • erc32 - ​https://lists.rtems.org/pipermail/build/2017-October/000018.html
    • leon2 - ​https://lists.rtems.org/pipermail/build/2017-October/000021.html
    • leon3 - ​https://lists.rtems.org/pipermail/build/2017-October/000022.html
    • psim - ​https://lists.rtems.org/pipermail/build/2017-October/000020.html
    • jmr3904 - ​https://lists.rtems.org/pipermail/build/2017-October/000019.html

    As an aside, how will we distinguish the SPARC BSPs on sis, tsim or real hardware in the results?

    Comment 1
    1. Joel Sherrill, Fri, 27 Oct 2017 19:08:39 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Chris Johns, Sat, 28 Oct 2017 07:03:51 GMT

    Replying to Joel Sherrill:

    Based on these results on gdb simulators, please bump these to Tier 2.

    Fantastic. Please do not find on the command line so the email results are more compact. :)

    erc32 - ​https://lists.rtems.org/pipermail/build/2017-October/000018.html leon2 - ​https://lists.rtems.org/pipermail/build/2017-October/000021.html

    These do not look great. Looks like the script conversion to INI is broken. Are you able to please take a look?

    leon3 - ​https://lists.rtems.org/pipermail/build/2017-October/000022.html psim - ​https://lists.rtems.org/pipermail/build/2017-October/000020.html jmr3904 - ​https://lists.rtems.org/pipermail/build/2017-October/000019.html

    As an aside, how will we distinguish the SPARC BSPs on sis, tsim or real hardware in the results?

    The subject has the BSP name being tested. Would you like something in the body of the message?

    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 4
    1. Joel Sherrill, Wed, 29 Nov 2017 20:06:39 GMT

    Where are the BSPs in each tier listed? If these are on the list, can this be closed?

    Comment 5
    1. Chris Johns, Fri, 13 Dec 2019 15:37:29 GMT

    Here ​https://git.rtems.org/rtems-tools/tree/config/rtems-bsps-tiers.ini#n19

    Comment 6
    1. Chris Johns, Fri, 13 Dec 2019 15:46:49 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 429b747/rtems-tools:

    tiers: Move bsps from tier-3 to tier-2 Closes #3213

    3215 - Configuring a System Still Includes Notepads and Has Wrong Heading

    Link https://devel.rtems.org/ticket/3215
    Id 3215
    Reporter Joel Sherrill
    Created 2 November 2017 15:08:04
    Modified 9 November 2017 06:27:14
    Owner Joel Sherrill
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This section has the wrong heading and needs to be deleted anyway.

    24.8.2. Specify Maximum Classic API Timers
    CONSTANT:
    CONFIGURE_ENABLE_CLASSIC_API_NOTEPADS
    Comment 1
    1. Joel Sherrill, Thu, 02 Nov 2017 15:08:15 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Thu, 02 Nov 2017 15:13:51 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 120c8a0/rtems-docs:

    c-user/configuring_a_system.rst: Delete notepads section closes #3215.
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3216 - Replace vprintk() implementation

    Link https://devel.rtems.org/ticket/3216
    Id 3216
    Reporter Sebastian Huber
    Created 2 November 2017 15:25:09
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The current vprintk() implementation has a questionable licence header, lacks support for the 'z' and 'j' format specifiers, is not robust against invalid format specifiers, uses a global variable for output. Replace it with a stripped down version of the FreeBSD kernel kvprintf() function.

    Comment 1
    1. Chris Johns, Thu, 02 Nov 2017 20:48:50 GMT

    Good idea.

    Comment 2
    1. Sebastian Huber, Mon, 06 Nov 2017 06:29:13 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 1082798/rtems:

    score: Add _IO_Printf() and _IO_Vprintf() The previous vprintk() implementation had a questionable licence header, lacks support for the 'z' and 'j' format specifiers, is not robust against invalid format specifiers, uses a global variable for output. Replace it with a stripped down version of the FreeBSD kernel kvprintf() function. The new implementation allows a low overhead rtems_snprintf() if necessary. Update #3199. Close #3216.
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3217 - Add RTEMS version, build and tools details to tests

    Link https://devel.rtems.org/ticket/3217
    Id 3217
    Reporter Chris Johns
    Created 5 November 2017 07:38:56
    Modified 10 April 2018 05:14:43
    Owner Chris Johns
    Type enhancement
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Published test results need the RTEMS version, how it is built and the tools used to build the kernel and tests.

    Attachments:

    1 Chris Johns, Tue, 14 Nov 2017 01:00:54 GMT
      attach: set to 0001-build-Fix-the-dependence-for-the-generating-the-key-.patch
     
    Comment 1
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 2
    1. Chris Johns, Sat, 11 Nov 2017 05:23:26 GMT

    In 30218f5/rtems-tools:

    tester: Add reporting the RTEMS version, build and tools. Update #3217.
    Comment 3
    1. Sebastian Huber, Mon, 13 Nov 2017 13:16:44 GMT

    I get build failures on CentOS Linux release 7.4.1708 with a "make -j 1":

    + version=5
    + bsp=t32mppc
    + target=powerpc
    + build_dir=b-t32mppc
    + source_dir=/home/rtems/rtems
    + rm -rf b-t32mppc
    + mkdir b-t32mppc
    + cd b-t32mppc
    + /home/rtems/rtems/configure --target=powerpc-rtems5 --prefix=/opt/rtems/5 --enable-maintainer-mode --enable-rtemsbsp=t32mppc --enable-posix --disable-tests --enable-networking --enable-smp
    checking for gmake... gmake
    checking for RTEMS Version... 5.0.0
    checking build system type... x86_64-pc-linux-gnu
    checking host system type... x86_64-pc-linux-gnu
    ...
    Making all-am in sapi
    gmake[5]: Entering directory `/home/rtems/build/b-t32mppc/powerpc-rtems5/c/t32mppc/cpukit/sapi'
    powerpc-rtems5-gcc --pipe -DHAVE_CONFIG_H   -I.. -I../../cpukit/../../../t32mppc/lib/include -I.   -mcpu=8540 -meabi -msdata=sysv -fno-common -msoft-float -mno-spe -D__ppc_generic -Og -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT src/libsapi_a-version.o -MD -MP -MF src/.deps/libsapi_a-version.Tpo -c -o src/libsapi_a-version.o `test -f 'src/version.c' || echo '/home/rtems/rtems/c/src/../../cpukit/sapi/'`src/version.c
    /home/rtems/rtems/c/src/../../cpukit/sapi/src/version.c:30:10: fatal error: version-vc-key.h: No such file or directory
    `#include "version-vc-key.h"`
              ^~~~~~~~~~~~~~~~~~
    compilation terminated.
    gmake[5]: *** [src/libsapi_a-version.o] Error 1
    gmake[5]: Leaving directory `/home/rtems/build/b-t32mppc/powerpc-rtems5/c/t32mppc/cpukit/sapi'
    gmake[4]: *** [sapi] Error 2
    gmake[4]: Leaving directory `/home/rtems/build/b-t32mppc/powerpc-rtems5/c/t32mppc/cpukit'
    gmake[3]: *** [cpukit] Error 2
    gmake[3]: Leaving directory `/home/rtems/build/b-t32mppc/powerpc-rtems5/c/t32mppc'
    gmake[2]: *** [all-recursive] Error 1
    gmake[2]: Leaving directory `/home/rtems/build/b-t32mppc/powerpc-rtems5/c/t32mppc'
    gmake[1]: *** [all-recursive] Error 1
    gmake[1]: Leaving directory `/home/rtems/build/b-t32mppc/powerpc-rtems5/c'
    make: *** [all-recursive] Error 1 

    It works only if I change into the sapi build directory and run "make" here:

    cd /home/rtems/build/b-t32mppc/powerpc-rtems5/c/t32mppc/cpukit/sapi
    ~/build/b-t32mppc/powerpc-rtems5/c/t32mppc/cpukit/sapi > make
    Generating version-vc-key.h
    gmake  all-am
    gmake[1]: Entering directory `/home/rtems/build/b-t32mppc/powerpc-rtems5/c/t32mppc/cpukit/sapi'
    powerpc-rtems5-gcc --pipe -DHAVE_CONFIG_H   -I.. -I../../cpukit/../../../t32mppc/lib/include -I.   -mcpu=8540 -meabi -msdata=sysv -fno-common -msoft-float -mno-spe -D__ppc_generic -Og -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT src/libsapi_a-version.o -MD -MP -MF src/.deps/libsapi_a-version.Tpo -c -o src/libsapi_a-version.o `test -f 'src/version.c' || echo '/home/rtems/rtems/c/src/../../cpukit/sapi/'`src/version.c 
    Comment 4
    1. Chris Johns, Mon, 13 Nov 2017 21:53:06 GMT

    Replying to Sebastian Huber:

    I get build failures on CentOS Linux release 7.4.1708 with a "make -j 1":

    #include "version-vc-key.h"

    ~

    I can repeat this. And ..

    $ find . -name version-vc-key.h
    $ 

    .. for some reason the key is not being generated with a single job.

    Comment 5
    1. Chris Johns, Tue, 14 Nov 2017 06:07:03 GMT

    In 631f711/rtems:

    build: Fix the dependence for the generating the key file. Update #3217.
    Comment 6
    1. Sebastian Huber, Tue, 14 Nov 2017 06:07:47 GMT

    Thanks, this patch worked.

    Comment 7
    1. Joel Sherrill, Tue, 05 Dec 2017 14:27:35 GMT

    Is this resolved? The tests are reporting version information. I can't tell what else is required before this ticket is complete.

    Comment 8
    1. Chris Johns, Tue, 10 Apr 2018 05:14:43 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3218 - Termios canonical mode (ICANON) does not return input line by line

    Link https://devel.rtems.org/ticket/3218
    Id 3218
    Reporter Sebastian Huber
    Created 7 November 2017 06:50:14
    Modified 9 November 2017 06:27:14
    Owner Sebastian Huber
    Type defect
    Component dev/serial
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In canonical mode, input is made available line by line. We must stop the canonical buffer filling upon reception of an end-of-line character.

    Comment 1
    1. Sebastian Huber, Wed, 08 Nov 2017 07:44:45 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 791469bd/rtems:

    termios: Fix canonical mode In canonical mode, input is made available line by line. We must stop the canonical buffer filling upon reception of an end-of-line character. Close #3218.
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed


    3219 - Zynq BSP missing linker option --gc-sections

    Link https://devel.rtems.org/ticket/3219
    Id 3219
    Reporter Chris Johns
    Created 7 November 2017 16:45:20
    Modified 17 September 2018 11:46:13
    Owner Chris Johns
    Type defect
    Component bsps
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This Zynq BSP is missing this option.

    Comment 1
    1. Chris Johns, Tue, 07 Nov 2017 16:45:32 GMT
    2. status: changed from assigned to accepted
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 3
    1. Sebastian Huber, Mon, 17 Sep 2018 11:46:13 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    This BSP has this option since [5460722d8d17fb6dc34bfca217b88369a8094260/rtems]. This happened before the ticket was opened.


    3220 - Change RTEMS release number scheme from 4.12 to 5

    Link https://devel.rtems.org/ticket/3220
    Id 3220
    Reporter Sebastian Huber
    Created 9 November 2017 06:11:33
    Modified 21 March 2018 06:55:18
    Owner Sebastian Huber
    Type project
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    As discussed here

    ​https://lists.rtems.org/pipermail/devel/2017-October/019169.html

    it was agreed to use version 5.1 with the new number scheme for the next RTEMS release.

    Most important items of this release:

    • SMP support
    • 64-bit time_t (year 2038 problem)
    • the network stack header consolidation and the move to Newlib
    • self-contained POSIX synchronization objects (impacting the configuration)
    • improved Ada support (however, not all Ada tests pass currently)

    The following steps are necessary to carry out the number change:

  • Change version of RTEMS tools
  • Change version of RSB
  • Change version of RTEMS
  • Documentation repo. Easy.
  • Documentation website repo. Easy.
  • Release procedure repo. Easy.
  • Trac tickets. Not sure.
  • Trac wiki. Medium(?). A wiki search of 4.12 gives 21 hits.
  • rtems.org website. That needs Joel.
  • Make announcement on the devel and user mailing list
  • Comment 1
    1. Sebastian Huber, Thu, 09 Nov 2017 06:11:43 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 09 Nov 2017 06:11:51 GMT
    2. status: changed from assigned to accepted
    Comment 3
    1. Sebastian Huber, Thu, 09 Nov 2017 06:27:14 GMT
    2. milestone: changed from 4.12.0 to 5.1

    Milestone renamed

    Comment 4
    1. Sebastian Huber, Thu, 09 Nov 2017 06:29:50 GMT
    2. description: modified (diff)

    Trac update done.

    Comment 5
    1. Sebastian Huber, Thu, 09 Nov 2017 07:03:21 GMT
    2. description: modified (diff)

    Wiki update done:

    ​https://devel.rtems.org/search?q=4.12&noquickjump=1&wiki=on

    Comment 6
    1. Sebastian Huber, Thu, 09 Nov 2017 07:06:37 GMT

    In e5dad3c/rtems-tools:

    Change RTEMS version from 4.12 to 5 Update #3220.
    Comment 7
    1. Sebastian Huber, Thu, 09 Nov 2017 07:09:27 GMT

    In 637061c/rtems-source-builder:

    Change RTEMS version from 4.12 to 5 Update #3220.
    Comment 8
    1. Sebastian Huber, Thu, 09 Nov 2017 07:09:48 GMT

    In 089327b/rtems-source-builder:

    Change RSB version from 4.12 to 5 Update #3220.
    Comment 9
    1. Sebastian Huber, Thu, 09 Nov 2017 07:15:40 GMT
    2. description: modified (diff)

    [4a14751879f61ba7a045a1fcc7ff485a88dcb51d/rtems]

    Comment 10
    1. Sebastian Huber, Thu, 09 Nov 2017 07:44:54 GMT

    In aff8c47/rtems-tools:

    Add tools/5 patch Update #3220.
    Comment 11
    1. Sebastian Huber, Thu, 09 Nov 2017 08:05:35 GMT

    In b5a4b15/rtems-tools:

    Add tools/5 patch Update #3220.
    Comment 12
    1. Sebastian Huber, Thu, 09 Nov 2017 08:17:04 GMT

    In 2da1356/rtems-tools:

    Add tools/5 patches Update #3220.
    Comment 13
    1. Sebastian Huber, Thu, 09 Nov 2017 08:26:23 GMT

    In 52f3790/rtems-tools:

    Add tools/5 patch Update #3220.
    Comment 14
    1. Sebastian Huber, Thu, 09 Nov 2017 08:35:50 GMT

    In a70b8e6/rtems-tools:

    Add tools/5 patch Update #3220.
    Comment 15
    1. Sebastian Huber, Thu, 09 Nov 2017 08:41:55 GMT

    In 469e362/rtems-tools:

    Add tools/5 patches Update #3220.
    Comment 16
    1. Sebastian Huber, Thu, 09 Nov 2017 09:24:34 GMT

    In 60a6d6e/rtems-docs:

    Change RTEMS version to 5 Update #3220.
    Comment 17
    1. Sebastian Huber, Thu, 09 Nov 2017 09:25:36 GMT
    2. description: modified (diff)
    Comment 18
    1. Sebastian Huber, Thu, 09 Nov 2017 09:26:10 GMT
    2. description: modified (diff)
    Comment 19
    1. Sebastian Huber, Thu, 09 Nov 2017 13:29:24 GMT

    In b15a719/rtems-libbsd:

    Change RTEMS version to 5 Update #3220.
    Comment 20
    1. Sebastian Huber, Fri, 10 Nov 2017 08:39:09 GMT

    In 9f34b38/rtems-tools:

    Remove tools/5 patches Update #3220.
    Comment 21
    1. Sebastian Huber, Mon, 13 Nov 2017 08:01:56 GMT

    In cb40687/rtems:

    Change RTEMS_API from 5.0 to 5 This fixes the legacy Makefile based build system which expects RTEMS_API to be identical to the tool chain version. Update #3220.
    Comment 22
    1. Sebastian Huber, Thu, 23 Nov 2017 07:53:51 GMT
    2. description: modified (diff)
    Comment 23
    1. Sebastian Huber, Wed, 06 Dec 2017 18:21:41 GMT

    In 9526b034/rtems:

    confdefs: Replace RTEMS 4.12 with 5.1 Update #3220.
    Comment 24
    1. Sebastian Huber, Wed, 21 Mar 2018 06:55:18 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    I think the version change is complete.


    3221 - RSB wiki page duplicates documentation

    Link https://devel.rtems.org/ticket/3221
    Id 3221
    Reporter Sebastian Huber
    Created 9 November 2017 06:49:14
    Modified 4 April 2020 18:18:05
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The wiki page

    ​https://devel.rtems.org/wiki/Developer/Tools/RSB

    duplicates content with

    ​https://docs.rtems.org/branches/master/rsb/index.html

    Comment 1
    1. Gedare Bloom, Sat, 04 Apr 2020 18:18:05 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    I replaced the wiki content with a link to the docs.


    3224 - Upgrade or1k and m32c to Binutils 2.29

    Link https://devel.rtems.org/ticket/3224
    Id 3224
    Reporter Sebastian Huber
    Created 10 November 2017 08:13:50
    Modified 10 November 2017 08:17:09
    Owner Sebastian Huber
    Type enhancement
    Component tool/binutils
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Fri, 10 Nov 2017 08:14:00 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to accepted
    Comment 2
    1. Sebastian Huber, Fri, 10 Nov 2017 08:17:09 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In dbe55c3/rtems-source-builder:

    5: Use Binutils 2.29 for or1k and m32c This avoids Binutils patches from rtems-tools. Close #3224.

    3225 - Upgrade m32c to GDB 8.0.1

    Link https://devel.rtems.org/ticket/3225
    Id 3225
    Reporter Sebastian Huber
    Created 10 November 2017 08:33:13
    Modified 10 November 2017 08:36:40
    Owner Sebastian Huber
    Type enhancement
    Component tool/gdb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Fri, 10 Nov 2017 08:36:40 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d20f4df/rtems-source-builder:

    5: Upgrade m32c to GDB 8.0.1 Close #3225.

    3226 - gdb: pr 16827, fix sim on Mavrick

    Link https://devel.rtems.org/ticket/3226
    Id 3226
    Reporter Sebastian Huber
    Created 10 November 2017 08:48:52
    Modified 10 November 2017 09:07:22
    Owner Sebastian Huber
    Type defect
    Component tool/gdb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Attachments:

    1 Sebastian Huber, Fri, 10 Nov 2017 08:50:03 GMT
      attach: set to gdb-sim-arange-inline.diff
    2 Sebastian Huber, Fri, 10 Nov 2017 08:50:14 GMT
      attach: set to gdb-sim-cgen-inline.diff
    Comment 1
    1. Sebastian Huber, Fri, 10 Nov 2017 09:07:22 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 831bc7e/rtems-source-builder:

    5: Avoid rtems-tools for epiphany GDB Close #3226.

    3227 - sb-check fails on Msys2 64-bit

    Link https://devel.rtems.org/ticket/3227
    Id 3227
    Reporter Joel Sherrill
    Created 10 November 2017 16:13:10
    Modified 5 December 2017 14:31:08
    Owner Chris Johns
    Type defect
    Component admin
    Status closed
    Resolution worksforme
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    There must be a recent change to msys2 which is breaking things. I installed the 64-bit version from ​https://msys2.github.io/ per the instructions at ​https://docs.rtems.org/branches/master/user/hosts/index.html#microsoft-windows

    $ ./source-builder/sb-check
    error: no hosts defaults found; please add

    After adding some prints, I learned this:

    $ ./source-builder/sb-check
    posix
    made it
    MSYS_NT-10.0
    error: no hosts defaults found; please add

    I filled in options.py and windows.py to recognize this as MSYS2. I was then able to run sb-check. But it wasn't happy. Apparently the pacman command in the User's Guide is missing some packages based on newer versions:

    $ ./source-builder/sb-check
    posix
    MSYS_NT-10.0
    RTEMS Source Builder - Check, 5 (8b30eb3f440a modified)
    error: exe: not found: (__ar) ar
    error: exe: not found: (__as) as
    error: exe: not found: (__cc) x86_64-w64-mingw32-gcc
    error: exe: not found: (__cxx) x86_64-w64-mingw32-g++
    error: exe: not found: (__ld) ld
    error: exe: not found: (__nm) nm
    error: exe: not found: (__objcopy) objcopy
    error: exe: not found: (__objdump) objdump
    error: exe: not found: (__ranlib) ranlib
    Environment is not correctly set up

    I installed binutils explcitly with pacman and then sb-check is complaining about gcc. I did a find to locate the gcc's installed:

    $ find / -name "*gcc.*"
    /home/jrs007/.ssh/id_rsa_gcc.pub
    /mingw64/bin/gcc.exe
    /mingw64/bin/x86_64-w64-mingw32-gcc.exe
    /mingw64/lib/gcc/x86_64-w64-mingw32/6.2.0/include/stdint-gcc.h
    /mingw64/lib/gcc/x86_64-w64-mingw32/6.2.0/libgcc.a
    /mingw64/share/info/gcc.info.gz
    /mingw64/share/man/man1/gcc.1.gz
    /usr/share/vim/vim80/compiler/gcc.vim
    find: failed to read file names from file system at or below ‘/’: No such file or directory
    jrs007@JRS-OAR-Laptop MINGW64 /c/opt/rtems/rsb/source-builder
    $ /mingw64/bin/x86_64-w64-mingw32-gcc.exe --version
    x86_64-w64-mingw32-gcc.exe (Rev2, Built by MSYS2 project) 6.2.0
    Copyright (C) 2016 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions. There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    Attachments:

    1 Joel Sherrill, Fri, 10 Nov 2017 16:13:54 GMT
      attach: set to rsb.diff
     
    Comment 1
    1. Joel Sherrill, Fri, 10 Nov 2017 16:14:37 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Sun, 12 Nov 2017 15:53:38 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d1e6dfc/rtems-source-builder:

    5/rtems-all.bset: Add missing aarch64 closes #3227.
    Comment 3
    1. Joel Sherrill, Sun, 12 Nov 2017 15:54:36 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    Wrong ticket closed

    Comment 4
    1. Chris Johns, Sun, 12 Nov 2017 21:38:18 GMT

    I have just updated my MSYS2 and I am not seeing an issue. Also:

    chris@weng MINGW64 /d/opt/rtems/rsb.git/rtems
    $ ../source-builder/sb-check
    RTEMS Source Builder - Check, 5 (089327b5dcf9)
    Environment is ok
    chris@weng MINGW64 /d/opt/rtems/rsb.git/rtems
    $ /mingw64/bin/x86_64-w64-mingw32-gcc.exe --version
    x86_64-w64-mingw32-gcc.exe (Rev1, Built by MSYS2 project) 7.2.0
    Copyright (C) 2017 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 

    My installed gcc is much newer than yours?

    Did you follow this procedure ​https://github.com/msys2/msys2/wiki/MSYS2-installation#iii-updating-packages ?

    Comment 5
    1. Joel Sherrill, Tue, 05 Dec 2017 14:31:08 GMT
    2. status: changed from reopened to closed
    3. resolution: set to worksforme

    This should have been closed. The issue was that my install needed to be updated after the initial install. Apparently, they don't give you the latest version of anything on an initial install.

    Closing.


    3228 - aarch64 missing from 5/rtems-all build set

    Link https://devel.rtems.org/ticket/3228
    Id 3228
    Reporter Chris Johns
    Created 11 November 2017 01:51:48
    Modified 12 November 2017 16:04:37
    Owner  
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords RSB aarch64
    Cc  
    Blocking  
    Blocked by  

    Description

    This arch needs to be added to the all build set.

    Comment 1
    1. Joel Sherrill, Sun, 12 Nov 2017 16:04:24 GMT

    Fixed by commit ​https://git.rtems.org/rtems-source-builder/commit/?id=d1e6dfcb1e14d2f9d42c79e1137ddca6d8fc67d5

    Comment 2
    1. Joel Sherrill, Sun, 12 Nov 2017 16:04:37 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    3229 - Add index to all documents.

    Link https://devel.rtems.org/ticket/3229
    Id 3229
    Reporter Chris Johns
    Created 11 November 2017 23:08:36
    Modified 14 October 2018 00:36:36
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Indexes currently do not work. Fix this adding them to all documents.

    Add index entries where possible.

    Comment 1
    1. Chris Johns, Sat, 11 Nov 2017 23:08:46 GMT
    2. status: changed from assigned to accepted
    Comment 2
    1. Chris Johns, Sat, 11 Nov 2017 23:43:38 GMT

    In 42d50d7/rtems-docs:

    Add indexes to all documents. Update #3229.
    Comment 3
    1. Chris Johns, Sun, 12 Nov 2017 02:57:42 GMT

    I have noticed all the c-user guide has .. index:: labels after headings and they should be before the headings. They need to be moved to before to make clicking on an index work better. This needs to happen on all documents.

    Comment 4
    1. Chris Johns, Sun, 12 Nov 2017 03:35:39 GMT

    In 6c56401/rtems-docs:

    c-user: Fix index locations. Update #3229.
    Comment 5
    1. Chris Johns, Mon, 13 Nov 2017 02:27:40 GMT

    In 3384994/rtems-docs:

    Clean up sphinx warnings. Fix minor formatting issues. Fix reference the gloassary TLS using ':term:'. Make sure nothing is between an anchor and the heading where ':ref:' references the anchor. This meant moving all the recently added '.. index::' entries. Update #3232. Update #3229.
    Comment 6
    1. Chris Johns, Tue, 14 Nov 2017 22:04:30 GMT

    The documentation README needs updating to explain the formatting I fixed in the last change in this ticket.

    Comment 7
    1. Sebastian Huber, Mon, 05 Feb 2018 09:04:34 GMT

    The index directives are still in the wrong place, e.g.

    ​https://docs.rtems.org/branches/master/c-user/configuring_a_system.html#configure-bdbuf-buffer-count

    Comment 8
    1. Sebastian Huber, Mon, 05 Feb 2018 09:48:28 GMT

    In 13debfb/rtems-docs:

    c-user: Fix index directives Update #3229.
    Comment 9
    1. Joel Sherrill, Sun, 14 Oct 2018 00:36:36 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    Fixed on review doc master.


    3231 - RTEMS Top level README needs updating.

    Link https://devel.rtems.org/ticket/3231
    Id 3231
    Reporter Chris Johns
    Created 12 November 2017 05:05:32
    Modified 27 April 2020 07:09:25
    Owner Chris Johns
    Type defect
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    • Add markdown header.
    • Does the release process add a VERSION file to releases?
    • Docs link is wrong.
    • Anything else we need to add?
    Comment 1
    1. Chris Johns, Sun, 14 Oct 2018 20:26:01 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to accepted
    Comment 2
    1. Chris Johns, Mon, 27 Apr 2020 01:36:16 GMT

    In 396e9830/rtems:

    README: Fix the rtems.git line Updates #3231
    Comment 3
    1. Chris Johns, Mon, 27 Apr 2020 07:09:25 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    3232 - Use of .. include:: in the User Manual should be changed.

    Link https://devel.rtems.org/ticket/3232
    Id 3232
    Reporter Chris Johns
    Created 12 November 2017 23:04:38
    Modified 13 November 2017 02:27:40
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This tricket for Sphinx highlights an issue when using .. include::, we should be using .. toctree:::

    ​https://github.com/sphinx-doc/sphinx/issues/3432

    Comment 1
    1. Chris Johns, Mon, 13 Nov 2017 00:54:00 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In ac0eaff/rtems-docs:

    Use '.. toctree::' and not '.. include::' in the User Manual. Change all suitable '.. include::' to TOC tree. Remove unused and not needed sections. Fix the conf.py to not exclude some files. Close #3232.
    Comment 2
    1. Chris Johns, Mon, 13 Nov 2017 02:27:40 GMT

    In 3384994/rtems-docs:

    Clean up sphinx warnings. Fix minor formatting issues. Fix reference the gloassary TLS using ':term:'. Make sure nothing is between an anchor and the heading where ':ref:' references the anchor. This meant moving all the recently added '.. index::' entries. Update #3232. Update #3229.

    3234 - Quick Start Instructions Inconsistent

    Link https://devel.rtems.org/ticket/3234
    Id 3234
    Reporter Joel Sherrill
    Created 14 November 2017 18:28:45
    Modified 14 November 2017 18:35:48
    Owner Joel Sherrill
    Type defect
    Component doc
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In section 5 of the User's Manual, the clone of rtems-source-builder has you clone it into rsb but the sb-bootstrap command is based on cloning it into the rsb subdirectory.

    Comment 1
    1. Joel Sherrill, Tue, 14 Nov 2017 18:29:00 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Tue, 14 Nov 2017 18:35:48 GMT
    2. status: changed from assigned to closed
    3. resolution: set to invalid

    Must have misread the documentation.


    3235 - Fix rtems_semaphore_flush() for priority inheritance semaphores

    Link https://devel.rtems.org/ticket/3235
    Id 3235
    Reporter Sebastian Huber
    Created 16 November 2017 13:08:04
    Modified 16 November 2017 13:40:44
    Owner Sebastian Huber
    Type defect
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The _Semaphore_Get_operations() must return the proper operations for priority inheritance semaphores.

    Add a test case for rtems_semaphore_flush() with priority inheritance.

    Comment 1
    1. Sebastian Huber, Thu, 16 Nov 2017 13:40:44 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 79a998d/rtems:

    rtems: rtems_semaphore_flush() with prio inherit The _Semaphore_Get_operations() must return the proper operations for priority inheritance semaphores. Add a test case for rtems_semaphore_flush() with priority inheritance. Close #3235.

    3236 - Fix thread queue owner priority update in _Thread_queue_Flush_critical()

    Link https://devel.rtems.org/ticket/3236
    Id 3236
    Reporter Sebastian Huber
    Created 16 November 2017 13:37:57
    Modified 16 November 2017 13:41:00
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The thread queue extract operations performed by the _Thread_queue_Flush_critical() may result in a priority change of the thread queue owner. Carry out the scheduler priority update operation. This is especially important in SMP configurations.

    Comment 1
    1. Sebastian Huber, Thu, 16 Nov 2017 13:41:00 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 9c30c31e/rtems:

    score: Fix _Thread_queue_Flush_critical() The thread queue extract operations performed by the _Thread_queue_Flush_critical() may result in a priority change of the thread queue owner. Carry out the scheduler priority update operation. This is especially important in SMP configurations. Close #3236.

    3237 - Fix priority ceiling updates

    Link https://devel.rtems.org/ticket/3237
    Id 3237
    Reporter Sebastian Huber
    Created 16 November 2017 14:25:37
    Modified 16 November 2017 14:29:23
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    We must not clear the priority updates in _Thread_queue_Extract_locked() since this function is used by the priority ceiling surrender operations after the ceiling priority handover from the previous owner to the new owner. This is especially important in SMP configurations.

    Move the _Thread_queue_Context_clear_priority_updates() invocation to the callers.

    Comment 1
    1. Sebastian Huber, Thu, 16 Nov 2017 14:29:23 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In ec771f2/rtems:

    score: Fix priority ceiling updates We must not clear the priority updates in _Thread_queue_Extract_locked() since this function is used by the priority ceiling surrender operations after the ceiling priority handover from the previous owner to the new owner. This is especially important in SMP configurations. Move the _Thread_queue_Context_clear_priority_updates() invocation to the callers. Close #3237.

    3238 - Git push to Trac with more than one commit does not update tickets.

    Link https://devel.rtems.org/ticket/3238
    Id 3238
    Reporter Chris Johns
    Created 16 November 2017 20:42:19
    Modified 21 October 2018 00:13:37
    Owner Amar Takhar
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority highest
    Severity blocker
    Keywords  
    Cc  
    Blocking 3561
    Blocked by  

    Description

    The git push to trac hook does not queue or handle a number of commits in a push. As a result updates to tickets can be missed.

    Comment 1
    1. Chris Johns, Thu, 16 Nov 2017 20:42:34 GMT
    2. summary: changed from Git push to trace with more than one commit does not update tickets. to Git push to Trac with more than one commit does not update tickets.
    Comment 2
    1. Chris Johns, Mon, 05 Feb 2018 23:42:25 GMT
    2. priority: changed from normal to highest
    3. severity: changed from normal to blocker

    I consider this ticket is important and we need to find a solution. I am finding tickets are not being closed on branches if there is a push with more than one change. This creates 2 issues, the first the ticket is not closed effecting the milestone report __and__ manually closing the ticket requires finding and pasting in the URL for the changeset and so we can have a possible mix of Trac changesets and cgit changesets. Given we have moved to Trac generated Release Notes (which are fantastic) having this data correct for releases is important.

    Comment 3
    1. Sebastian Huber, Thu, 03 May 2018 05:19:40 GMT

    I use the following workaround:

    git log --format='%h' origin/master..HEAD | tac | sed 's%\(.*\)%git push origin \1:master%' > tmp.sh

    It creates a script to push each commit separately.

    Comment 4
    1. Joel Sherrill, Sat, 13 Oct 2018 22:35:56 GMT
    2. owner: set to Amar Takhar
    3. status: changed from new to assigned
    Comment 5
    1. Chris Johns, Sun, 14 Oct 2018 00:46:19 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Work around the problem with this script: ​https://devel.rtems.org/wiki/Developer/Git/Committers#PushingMultipleCommits

    Comment 6
    1. Amar Takhar, Sun, 21 Oct 2018 00:13:37 GMT
    2. blocking: set to 3561

    3239 - Add getentropy() implementation provided by each BSP

    Link https://devel.rtems.org/ticket/3239
    Id 3239
    Reporter Sebastian Huber
    Created 17 November 2017 06:26:22
    Modified 22 November 2017 12:01:45
    Owner Sebastian Huber
    Type enhancement
    Component dev
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The getentropy() system call was introduced by OpenBSD and is now also available on glibc 2.25 and later. It is used for example by arc4random_buf(). Which in turn is used by various cryptographic functions.

    Comment 1
    1. Christian Mauderer, Fri, 17 Nov 2017 06:28:22 GMT

    In ddc339c/rtems:

    cpukit: Add _arc4random_getentropy_fail. Add a default implementation of _arc4random_getentropy_fail with an internal error. Update #3239.
    Comment 2
    1. Christian Mauderer, Fri, 17 Nov 2017 06:28:34 GMT

    In ca4895c/rtems:

    getentropy: Add cpu counter based implementation. Update #3239.
    Comment 3
    1. Christian Mauderer, Fri, 17 Nov 2017 06:28:47 GMT

    In 1358d4c/rtems:

    getentropy: Add test. Update #3239.
    Comment 4
    1. Christian Mauderer, Fri, 17 Nov 2017 06:29:01 GMT

    In a9de9a7/rtems:

    bsp/atsam: Add getentropy(). Update #3239.
    Comment 5
    1. Christian Mauderer, Fri, 17 Nov 2017 06:48:05 GMT

    In d0b961a/rtems-docs:

    bsp-howto: Add getentropy. Update #3239.
    Comment 6
    1. Sebastian Huber, Fri, 17 Nov 2017 06:58:41 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In baf9824/rtems-docs:

    Document INTERNAL_ERROR_ARC4RANDOM_GETENTROPY_FAIL Close #3239.
    Comment 7
    1. Sebastian Huber, Mon, 20 Nov 2017 07:09:41 GMT

    In 70f23e4/rtems-docs:

    Clarify INTERNAL_ERROR_ARC4RANDOM_GETENTROPY_FAIL Update #3239.
    Comment 8
    1. Sebastian Huber, Mon, 20 Nov 2017 07:50:50 GMT

    In 3d374d9/rtems:

    bsps: Use a state in default getentropy() Use the boot time to initialize the state. Use the state, the current CPU counter and a very simple pseudo random number generator for getentropy(). At least, this enables to pass the test "GETENTROPY 1" on ERC32. Update #3239.
    Comment 9
    1. Sebastian Huber, Wed, 22 Nov 2017 12:01:45 GMT

    In a8bf9a3/rtems:

    bsps: Add default getentropy() implementation Update #3239. Close #3249.

    3240 - cpukit/libmisc/stackchk/check.c stack addresses formatted incorrectly.

    Link https://devel.rtems.org/ticket/3240
    Id 3240
    Reporter Andrei Chichak
    Created 18 November 2017 05:32:17
    Modified 6 December 2017 22:51:35
    Owner Chris Johns
    Type defect
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords rtems_stack_checker_report_usage
    Cc  
    Blocking  
    Blocked by  

    Description

    The function Stack_check_Dump_threads_usage displays the stack high, low, and current pointers incorrectly.

    Instead of displaying these pointers in conventional hex format, the values have a proper prefix of 0x, but the pointer value is displayed in decimal.

    The incorrect inttypes.h formatting define was used.

    Attachments:

    1 Andrei Chichak, Sat, 18 Nov 2017 06:14:29 GMT
      attach: set to 0001-libmisc-stackchk-check.c-correct-formatting-of-stack.patch
    Comment 1
    1. Andrei Chichak, Sat, 18 Nov 2017 06:05:38 GMT
    Comment 2
    1. Joel Sherrill, Tue, 05 Dec 2017 21:17:08 GMT

    Wasn't a fix for this committed? Is there work left to do? Either close or state actions left. Please

    Comment 3
    1. Chris Johns, Wed, 06 Dec 2017 06:05:34 GMT

    No, the format of the prints is wrong and this patch fixes it. It needs to be applied and that should close the ticket.

    Comment 4
    1. Chris Johns, Wed, 06 Dec 2017 22:48:31 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to accepted
    Comment 5
    1. Andrei Chichak, Wed, 06 Dec 2017 22:51:35 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 1737e8f/rtems:

    libmisc/stackchk/check.c: correct formatting of stack pointers in Stack_check_Dump_threads_usage Pointers were being printed as 0x rather than 0x. I altered the formatting define used to give the correct formatting. Close #3240

    3242 - Workarounds for UT699, UT700, and GR712RC errata

    Link https://devel.rtems.org/ticket/3242
    Id 3242
    Reporter Sebastian Huber
    Created 20 November 2017 12:57:44
    Modified 19 December 2017 09:40:32
    Owner Sebastian Huber
    Type defect
    Component tool/gcc
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    ​https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01751.html

    This patch series adds workarounds for the newly discovered errata for UT699, UT700, and GR712RC. The errata and possible workarounds are described in the following documents available at ​http://www.gaisler.com/index.php/information/app-tech-notes:

    GRLIB-TN-0010 - LEON3/FT AHB Deadlock After Sequence of Load and Atomic Instructions
    GRLIB-TN-0011 - LEON3/FT AHB Lock Release during Atomic Operation
    GRLIB-TN-0012 - GR712RC Incorrect Annulation of Floating-point Operation on Instruction Cache Parity Error
    GRLIB-TN-0013 - GRFPU Floating-point controller: Missing FDIV/FSQRT Result

    Daniel Cederman (4):

    [SPARC] Errata workaround for GRLIB-TN-0012
    [SPARC] Errata workaround for GRLIB-TN-0011
    [SPARC] Errata workaround for GRLIB-TN-0010
    [SPARC] Errata workaround for GRLIB-TN-0013

    Attachments:

    1 Sebastian Huber, Thu, 30 Nov 2017 08:32:21 GMT
      attach: set to gcc-sparc-ticket-3242.patch
    2 Sebastian Huber, Tue, 19 Dec 2017 08:36:20 GMT
      attach: set to gcc-sparc-ticket-3242-v2.patch
    Comment 1
    1. Sebastian Huber, Thu, 30 Nov 2017 08:26:56 GMT

    Include also:

    [SPARC] Recognize the load when accessing the GOT [SPARC] Prevent -mfix-ut699 from generating b2bst errata sequences

    Comment 2
    1. Sebastian Huber, Thu, 30 Nov 2017 08:31:12 GMT
    2017-11-29  Daniel Cederman  
        Backport from mainline
        * config/sparc/sparc.c (sparc_do_work_around_errata): Treat the
            movsi_pic_gotdata_op instruction as a load for the UT699 errata
            workaround.
    2017-11-29  Martin Aberg  
        Backport from mainline
        * config/sparc/sparc.md (divdf3_fix): Add NOP and adjust length
            to prevent b2bst errata sequence.
            (sqrtdf2_fix): Likewise.
    2017-11-29  Daniel Cederman  
        Backport from mainline
        * config/sparc/sparc.c (fpop_reg_depend_p): New function.
        (div_sqrt_insn_p): New function.
        (sparc_do_work_around_errata): Insert NOP instructions to
        prevent sequences that could trigger the TN-0013 errata for
        certain LEON3 processors.
        (pass_work_around_errata::gate): Also test sparc_fix_lost_divsqrt.
        (sparc_option_override): Set sparc_fix_lost_divsqrt appropriately.
        * config/sparc/sparc.md (fix_lost_divsqrt): New attribute.
        (in_branch_delay): Prevent div and sqrt in delay slot if
        fix_lost_divsqrt.
        * config/sparc/sparc.opt (sparc_fix_lost_divsqrt): New variable.
    2017-11-29  Daniel Cederman  
        Backport from mainline
        * config/sparc/sparc.c (atomic_insn_p): New function.
        (sparc_do_work_around_errata): Insert NOP instructions to
        prevent sequences that could trigger the TN-0010 errata for
        UT700.
        * config/sparc/sync.md (atomic_compare_and_swap_leon3_1): Make
        instruction referable in atomic_insns_p.
    2017-11-29  Daniel Cederman  
        Backport from mainline
        * config/sparc/sync.md (swapsi): 16-byte align if sparc_fix_gr712rc.
        (atomic_compare_and_swap_leon3_1): Likewise.
        (ldstub): Likewise.
    2017-11-29  Daniel Cederman  
        Backport from mainline
        * config/sparc/sparc.c (fpop_insn_p): New function.
        (sparc_do_work_around_errata): Insert NOP instructions to
        prevent sequences that could trigger the TN-0012 errata for
        GR712RC.
        (pass_work_around_errata::gate): Also test sparc_fix_gr712rc.
        * config/sparc/sparc.md (fix_gr712rc): New attribute.
        (in_branch_annul_delay): Prevent floating-point instructions
        in delay slot of annulled integer branch. 
    Comment 3
    1. Sebastian Huber, Fri, 01 Dec 2017 06:02:08 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In ffbd5e9/rtems-source-builder:

    5: Add SPARC chip errata workarounds Close #3242.
    Comment 4
    1. Sebastian Huber, Tue, 19 Dec 2017 08:30:47 GMT

    Update the patch series to integrate some cleanup and fix an ICE.

    2017-12-19  Daniel Cederman  
        Backport from mainline
        2017-12-19  Daniel Cederman  
        * config/sparc/sparc.c (sparc_do_work_around_errata): Make sure
        the jump is to a label.
    2017-12-06  Eric Botcazou  
        Revert
        2017-11-29  Martin Aberg  
        * config/sparc/sparc.md (divdf3_fix): Add NOP and adjust length
        to prevent b2bst errata sequence.
        (sqrtdf2_fix): Likewise.
    2017-12-04  Eric Botcazou  
        * config/sparc/sparc.c (sparc_do_work_around_errata): Use mem_ref
        instead of MEM_P in a couple more places.  Fix formatting issues. 
    Comment 5
    1. Sebastian Huber, Tue, 19 Dec 2017 09:40:32 GMT

    In f3b1700/rtems-source-builder:

    5: Update SPARC chip errata workarounds Update #3242.

    3243 - Simplify global construction

    Link https://devel.rtems.org/ticket/3243
    Id 3243
    Reporter Sebastian Huber
    Created 21 November 2017 06:53:42
    Modified 1 October 2018 10:28:33
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    For the SMP support the global construction was changed to use an approach with a thread restart after global construction. With this implementation thread-local objects and POSIX keys initialized during global construction are not present in the initialization thread (main thread). This is not in line with what users familiar with GNU/Linux or FreeBSD would expect. See for example:

    ​https://lists.rtems.org/pipermail/users/2017-July/031525.html

    Comment 1
    1. Sebastian Huber, Wed, 22 Nov 2017 12:01:56 GMT

    In a7dcef97/rtems:

    score: Simplify global construction Update #3243.
    Comment 2
    1. Sebastian Huber, Wed, 22 Nov 2017 12:02:08 GMT

    In cd3e220/rtems:

    INTERNAL_ERROR_POSIX_INIT_THREAD_ENTRY_IS_NULL Delete superfluous INTERNAL_ERROR_POSIX_INIT_THREAD_ENTRY_IS_NULL. Update #3243.
    Comment 3
    1. Sebastian Huber, Fri, 24 Nov 2017 05:57:02 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 674b714/rtems-docs:

    c-user: Document global construction Close #3243.
    Comment 4
    1. Sebastian Huber, Mon, 01 Oct 2018 10:28:33 GMT

    In 0614743/rtems:

    spthreadlife01: Remove superfluous restart case Update #3243.

    3244 - Change rtems_panic() implementation and document this function

    Link https://devel.rtems.org/ticket/3244
    Id 3244
    Reporter Sebastian Huber
    Created 21 November 2017 10:16:54
    Modified 5 June 2018 07:13:17
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The current rtems_panic() implementation is quite heavy weight. It depends on _exit() which calls the global destructors. It uses fprintf(stderr, ...) for output which depends on an initialized console device and the complex fprintf().

    Introduce a new fatal source RTEMS_FATAL_SOURCE_PANIC for rtems_panic() and output via printk().

    Document this function in Fatal Manager chapter.

    Replace all BSP_panic() with rtems_panic().

    Comment 1
    1. Sebastian Huber, Wed, 22 Nov 2017 12:02:20 GMT

    In 15e19273/rtems:

    sapi: New implementation of rtems_panic() The previous rtems_panic() implementation was quite heavy weight. It depended on _exit() which calls the global destructors. It used fprintf(stderr, ...) for output which depends on an initialized console device and the complex fprintf(). Introduce a new fatal source RTEMS_FATAL_SOURCE_PANIC for rtems_panic() and output via vprintk(). Update #3244.
    Comment 2
    1. Sebastian Huber, Thu, 23 Nov 2017 06:28:11 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 97c51c8/rtems-docs:

    c-user: Document rtems_panic() Close #3244.
    Comment 3
    1. Sebastian Huber, Tue, 05 Jun 2018 07:13:17 GMT

    In c934365f/rtems:

    Update rtems_fatal_source_text() Add RTEMS_FATAL_SOURCE_PANIC to rtems_fatal_source_text(). Update #3244.

    3245 - Replace BSP_panic() with rtems_panic()

    Link https://devel.rtems.org/ticket/3245
    Id 3245
    Reporter Sebastian Huber
    Created 21 November 2017 10:36:31
    Modified 22 November 2017 12:02:32
    Owner Sebastian Huber
    Type enhancement
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Due to a new rtems_panic() implementation, it is possible to replace the PowerPC-specific BSP_panic() with rtems_panic(). Remove BSP_panic() implementations.

    Comment 1
    1. Sebastian Huber, Wed, 22 Nov 2017 12:02:32 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 1c193a2/rtems:

    powerpc: Replace BSP_panic() with rtems_panic() Due to a new rtems_panic() implementation, it is possible to replace the PowerPC-specific BSP_panic() with rtems_panic(). Remove BSP_panic() implementations. Close #3245.

    3246 - Remove _BSP_Fatal_error()

    Link https://devel.rtems.org/ticket/3246
    Id 3246
    Reporter Sebastian Huber
    Created 21 November 2017 10:49:07
    Modified 22 November 2017 12:02:46
    Owner Sebastian Huber
    Type enhancement
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    BSPs can use the bsp_fatal_extension() to provide BSP-specific fatal error handling. There is no need for a _BSP_Fatal_error().

    Comment 1
    1. Sebastian Huber, Wed, 22 Nov 2017 12:02:46 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 07d96453/rtems:

    powerpc: Remove _BSP_Fatal_error() BSPs can use the bsp_fatal_extension() to provide BSP-specific fatal error handling. There is no need for a _BSP_Fatal_error(). Close #3246.

    3247 - Remove BSP-specific defaults for RTEMS_BSP_CLEANUP_OPTIONS()

    Link https://devel.rtems.org/ticket/3247
    Id 3247
    Reporter Sebastian Huber
    Created 21 November 2017 11:44:27
    Modified 22 November 2017 12:44:40
    Owner Sebastian Huber
    Type enhancement
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove BSP-specific defaults for RTEMS_BSP_CLEANUP_OPTIONS() to simplify the BSP configuration and documentation. Change default to:

    BSP_PRESS_KEY_FOR_RESET=0
    BSP_RESET_BOARD_AT_EXIT=1
    BSP_PRINT_EXCEPTION_CONTEXT=1

    Comment 1
    1. Sebastian Huber, Wed, 22 Nov 2017 12:44:40 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    [3dd381f0431b761965f573381ff90a8d42a8bd79/rtems]


    3248 - Add BSP_VERBOSE_FATAL_EXTENSION to RTEMS_BSP_CLEANUP_OPTIONS

    Link https://devel.rtems.org/ticket/3248
    Id 3248
    Reporter Sebastian Huber
    Created 21 November 2017 11:50:43
    Modified 2 December 2017 19:33:54
    Owner Sebastian Huber
    Type enhancement
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add BSP_VERBOSE_FATAL_EXTENSION to RTEMS_BSP_CLEANUP_OPTIONS to optionally print the RTEMS version, the fatal source and the fatal code in the shared bsp_fatal_extension().

    Comment 1
    1. Sebastian Huber, Wed, 22 Nov 2017 12:03:12 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 86a80ee1/rtems:

    bsps: Add BSP_VERBOSE_FATAL_EXTENSION Add BSP_VERBOSE_FATAL_EXTENSION to RTEMS_BSP_CLEANUP_OPTIONS to optionally print the RTEMS version, the fatal source and the fatal code in the shared bsp_fatal_extension(). Close #3248.
    Comment 2
    1. Sebastian Huber, Sat, 02 Dec 2017 19:33:54 GMT

    In 57f3969a/rtems:

    bsps: Print internal error text Update #3248.

    3249 - imx7 does not link getentropy01 test on master

    Link https://devel.rtems.org/ticket/3249
    Id 3249
    Reporter Joel Sherrill
    Created 21 November 2017 18:38:50
    Modified 22 November 2017 12:01:45
    Owner Sebastian Huber
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    arm-rtems5-gcc -B../../../../../imx7/lib/ -specs bsp_specs -qrtems -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a7 -O2 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -Wl,--gc-sections -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a7 -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -o getentropy01.exe init.o
    init.o: In function `test_getentropy':
    /home/joel/rtems-work/rtems-testing/rtems/build-arm-imx7-rtems/arm-rtems5/c/imx7/testsuites/libtests/getentropy01/../../../../../../../rtems/c/src/../../testsuites/libtests/getentropy01/init.c:57: undefined reference to `getentropy'
    /home/joel/rtems-work/rtems-testing/rtems/build-arm-imx7-rtems/arm-rtems5/c/imx7/testsuites/libtests/getentropy01/../../../../../../../rtems/c/src/../../testsuites/libtests/getentropy01/init.c:59: undefined reference to `getentropy'

    Comment 1
    1. Joel Sherrill, Tue, 21 Nov 2017 18:39:24 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Wed, 22 Nov 2017 12:01:45 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a8bf9a3/rtems:

    bsps: Add default getentropy() implementation Update #3239. Close #3249.

    3254 - Reorganize header files to avoid "make preinstall"

    Link https://devel.rtems.org/ticket/3254
    Id 3254
    Reporter Sebastian Huber
    Created 23 November 2017 12:20:43
    Modified 14 December 2018 06:04:11
    Owner  
    Type enhancement
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Chris Johns, Fri, 24 Nov 2017 05:25:37 GMT

    Solving this problem requires:

    Capturing the installed headers files with an MD5 checksum so each can be clearly identified in the source tree. Capturing the preinstall view of the process with the install path and a source tree path. Defining the include paths in RTEMS and any macros required to reference the header within that tree.

    For each preinstall header we need to collate the source headers and determine what overlaps. With the define directories we want to have we can determine the moves we need. I am getting close to having this data.

    Comment 2
    1. Sebastian Huber, Mon, 27 Nov 2017 06:34:35 GMT

    In e58e29f/rtems:

    Remove coverhd.h This header file contained timing overhead values which are hard to maintain. Update #3254.
    Comment 3
    1. Sebastian Huber, Mon, 27 Nov 2017 06:34:46 GMT

    In affb282/rtems:

    bsps: Remove empty tm27.h variants Update #3254.
    Comment 4
    1. Sebastian Huber, Mon, 27 Nov 2017 06:34:58 GMT

    In 0d5c795/rtems:

    Move Ada includes Update #3254.
    Comment 5
    1. Sebastian Huber, Mon, 27 Nov 2017 08:37:18 GMT

    In 642ef00/rtems:

    bsps: Provide in each BSP Since the is highly BSP-dependent and used only by the tm27 test program we must provide this header file for each BSP. Without the preinstall build target each header file must have a unique source header file. Update #3254.
    Comment 6
    1. Sebastian Huber, Tue, 05 Dec 2017 13:31:43 GMT

    In 61bd8cd6/rtems:

    bsp/gen5200: Avoid duplicate header installation Update #3254.
    Comment 7
    1. Sebastian Huber, Thu, 07 Dec 2017 06:17:09 GMT

    In 28fb905/rtems:

    bsps/powerpc: Fix mpc83xx_i2cdrv.h location Update #3254.
    Comment 8
    1. Sebastian Huber, Thu, 07 Dec 2017 06:24:20 GMT

    In 3f575da/rtems:

    Remove obsolete network header files Update #3254.
    Comment 9
    1. Sebastian Huber, Thu, 07 Dec 2017 10:50:19 GMT

    In 7704f1a/rtems:

    bsps/or1k: Avoid Update #3254.
    Comment 10
    1. Sebastian Huber, Fri, 08 Dec 2017 12:06:17 GMT

    In 102fd7c9/rtems:

    bsps: Do not install This is a cache manager implementation header file. Update #3254.
    Comment 11
    1. Sebastian Huber, Fri, 08 Dec 2017 12:06:32 GMT

    In e9d6114/rtems:

    bsp/gumstix: Move libcpu files to BSP Update #3254.
    Comment 12
    1. Sebastian Huber, Fri, 08 Dec 2017 12:06:46 GMT

    In 586c70ad/rtems:

    bsps/arm: Remove obsolete s3c2400 Update #3254.
    Comment 13
    1. Sebastian Huber, Fri, 08 Dec 2017 12:06:58 GMT

    In 26ff9fd6/rtems:

    bsp/csb336: Move libcpu files to BSP Update #3254.
    Comment 14
    1. Sebastian Huber, Fri, 08 Dec 2017 12:07:10 GMT

    In 7829710/rtems:

    bsp/rtl22xx: Move libcpu files to BSP Update #3254.
    Comment 15
    1. Sebastian Huber, Fri, 08 Dec 2017 12:07:23 GMT

    In a1460043/rtems:

    bsp/smdk2410: Move libcpu files to BSP Update #3254.
    Comment 16
    1. Sebastian Huber, Fri, 08 Dec 2017 12:07:35 GMT

    In b748dffe/rtems:

    bsp/csb337: Move libcpu files to BSP Update #3254.
    Comment 17
    1. Sebastian Huber, Fri, 08 Dec 2017 13:14:12 GMT

    In 604f080c/rtems:

    bsp/shsim: Move libcpu files to BSP Update #3254.
    Comment 18
    1. Sebastian Huber, Fri, 08 Dec 2017 13:14:25 GMT

    In b850e7f/rtems:

    bsp/gensh1: Move libcpu files to BSP Update #3254.
    Comment 19
    1. Sebastian Huber, Fri, 08 Dec 2017 13:14:39 GMT

    In 533e2c0/rtems:

    bsp/gensh2: Move libcpu files to BSP Update #3254.
    Comment 20
    1. Sebastian Huber, Fri, 08 Dec 2017 13:14:51 GMT

    In f2969b5/rtems:

    bsp/gensh4: Move libcpu files to BSP Update #3254.
    Comment 21
    1. Sebastian Huber, Wed, 13 Dec 2017 08:07:50 GMT

    In 8e8cf72/rtems:

    arm: Move to cpukit Update #3254.
    Comment 22
    1. Sebastian Huber, Wed, 13 Dec 2017 08:08:02 GMT

    In 6ad3f471/rtems:

    libdebugger: Avoid use of Update #3254.
    Comment 23
    1. Sebastian Huber, Wed, 13 Dec 2017 08:08:14 GMT

    In a397c7d8/rtems:

    IMFS: Include Prepare for header file move to common include directory. Update #3254.
    Comment 24
    1. Sebastian Huber, Wed, 13 Dec 2017 08:08:27 GMT

    In 339069fc/rtems:

    devfs: Include Prepare for header file move to common include directory. Update #3254.
    Comment 25
    1. Sebastian Huber, Wed, 13 Dec 2017 08:08:39 GMT

    In 51a30a4/rtems:

    ftpd: Include Prepare for header file move to common include directory. Update #3254.
    Comment 26
    1. Sebastian Huber, Wed, 13 Dec 2017 08:08:50 GMT

    In 7683da8/rtems:

    dosfs: Include Prepare for header file move to common include directory. Update #3254.
    Comment 27
    1. Sebastian Huber, Wed, 13 Dec 2017 08:09:02 GMT

    In 7d9455e/rtems:

    pipe: Include Prepare for header file move to common include directory. Update #3254.
    Comment 28
    1. Sebastian Huber, Wed, 13 Dec 2017 08:09:14 GMT

    In 990adc5/rtems:

    libdl: Include Prepare for header file move to common include directory. Update #3254.
    Comment 29
    1. Sebastian Huber, Wed, 13 Dec 2017 08:09:26 GMT

    In 295ca7d/rtems:

    RFS: Include Prepare for header file move to common include directory. Update #3254.
    Comment 30
    1. Sebastian Huber, Wed, 13 Dec 2017 08:09:39 GMT

    In 249730de/rtems:

    capture: Include Prepare for header file move to common include directory. Update #3254.
    Comment 31
    1. Sebastian Huber, Wed, 13 Dec 2017 08:09:50 GMT

    In 47f236c6/rtems:

    monitor: Include Prepare for header file move to common include directory. Update #3254.
    Comment 32
    1. Sebastian Huber, Wed, 13 Dec 2017 08:10:02 GMT

    In 4a23aa45/rtems:

    shell: Include Prepare for header file move to common include directory. Update #3254.
    Comment 33
    1. Sebastian Huber, Wed, 13 Dec 2017 08:10:14 GMT

    In a1626726/rtems:

    redirector: Include Prepare for header file move to common include directory. Update #3254.
    Comment 34
    1. Sebastian Huber, Wed, 13 Dec 2017 08:10:26 GMT

    In f666fc59/rtems:

    utf8proc: Include Prepare for header file move to common include directory. Update #3254.
    Comment 35
    1. Sebastian Huber, Wed, 13 Dec 2017 08:10:38 GMT

    In edfdc42/rtems:

    uuid: Include Prepare for header file move to common include directory. Update #3254.
    Comment 36
    1. Sebastian Huber, Wed, 13 Dec 2017 08:10:50 GMT

    In 9589755f/rtems:

    mghttpd: Include Prepare for header file move to common include directory. Update #3254.
    Comment 37
    1. Sebastian Huber, Wed, 13 Dec 2017 08:11:03 GMT

    In 5346fa87/rtems:

    pppd: Include Prepare for header file move to common include directory. Update #3254.
    Comment 38
    1. Sebastian Huber, Wed, 13 Dec 2017 08:11:15 GMT

    In 94e04b5/rtems:

    telnetd: Include Prepare for header file move to common include directory. Update #3254.
    Comment 39
    1. Sebastian Huber, Wed, 13 Dec 2017 08:26:41 GMT

    In 241fc046/rtems:

    zlib: Do not generate zconf.h Update #3254.
    Comment 40
    1. Sebastian Huber, Wed, 13 Dec 2017 08:33:00 GMT

    In d19e7aab/rtems:

    zlib: Fix build Update #3254.
    Comment 41
    1. Sebastian Huber, Thu, 14 Dec 2017 07:13:31 GMT

    In 12641f7b/rtems:

    epiphany: Remove superfluous includes Update #3254.
    Comment 42
    1. Sebastian Huber, Fri, 15 Dec 2017 06:23:48 GMT

    In 2717032d/rtems:

    bsps/arm: Fix move to cpukit Update #3254.
    Comment 43
    1. Sebastian Huber, Thu, 04 Jan 2018 06:19:08 GMT

    In f3ce8f41/rtems:

    bsps: Include bsp.am in all BSP Makefile.am Update #3254.
    Comment 44
    1. Sebastian Huber, Thu, 04 Jan 2018 06:19:21 GMT

    In 33a2faa/rtems:

    bsps: Add EXTRA_DIST to all BSP Makefile.am This makes it possible to easily use EXTRA_DIST += foobar in fragments. Update #3254.
    Comment 45
    1. Sebastian Huber, Thu, 04 Jan 2018 06:19:35 GMT

    In ec32100/rtems:

    bsps: Use CPPASCOMPILE for startfile Update #3254.
    Comment 46
    1. Sebastian Huber, Thu, 04 Jan 2018 06:19:59 GMT

    In e1c0d67/rtems:

    bsp/mpc55xxevb: Move Update #3254. Update #3268.
    Comment 47
    1. Sebastian Huber, Thu, 04 Jan 2018 06:20:11 GMT

    In 7190005/rtems:

    sparc: Move Update #3254. Update #3260.
    Comment 48
    1. Sebastian Huber, Thu, 04 Jan 2018 06:20:23 GMT

    In 3b392b6/rtems:

    sparc: Remove BSP specifics from Update #3254. Update #3260.
    Comment 49
    1. Sebastian Huber, Thu, 04 Jan 2018 06:20:36 GMT

    In 569fd50/rtems:

    sparc: Remove BSP specifics from Update #3254. Update #3260. Update #3269.
    Comment 50
    1. Sebastian Huber, Thu, 04 Jan 2018 06:20:49 GMT

    In 4e100058/rtems:

    sparc: Remove from PCI shell command Update #3254. Update #3260.
    Comment 51
    1. Sebastian Huber, Thu, 04 Jan 2018 06:21:02 GMT

    In fb01816b/rtems:

    bsps/powerpc: Move shared irq.h This header file is only used by motorola_powerpc, so not shared. Update #3254. Update #3268.
    Comment 52
    1. Sebastian Huber, Thu, 04 Jan 2018 06:21:14 GMT

    In 375e923d/rtems:

    bsps/powerpc: Rename BSP specific linkcmds.base Avoid name conflicts with shared linkcmds.base. Update #3254.
    Comment 53
    1. Sebastian Huber, Fri, 05 Jan 2018 10:58:11 GMT

    In f636e91a/rtems:

    bsp/pc386: Do not install console_private.h The name suggests that this is a private implementation header file. Update #3254.
    Comment 54
    1. Chris Johns, Fri, 05 Jan 2018 10:58:22 GMT

    In 6897cb1/rtems:

    bsps: Add AM_CPPFLAGS to special case CPPFLAGS This is necessary to pick up mandatory flags provided by the build system. Update #3254.
    Comment 55
    1. Chris Johns, Fri, 05 Jan 2018 10:58:46 GMT

    In 3eed4f3/rtems:

    bsp/altera-cyclone-v: Use public include path Update #3254.
    Comment 56
    1. Chris Johns, Fri, 05 Jan 2018 10:58:57 GMT

    In 1efd148b/rtems:

    bsp/pc386: Use public include path Update #3254.
    Comment 57
    1. Chris Johns, Fri, 05 Jan 2018 10:59:09 GMT

    In 9c91520/rtems:

    bsps/lm32: Use public include path Update #3254.
    Comment 58
    1. Chris Johns, Fri, 05 Jan 2018 10:59:22 GMT

    In caeaae26/rtems:

    bsp/gen5200: Use public include path Update #3254.
    Comment 59
    1. Chris Johns, Fri, 05 Jan 2018 10:59:34 GMT

    In 230acc55/rtems:

    libchip: Use public include path Update #3254.
    Comment 60
    1. Chris Johns, Fri, 05 Jan 2018 10:59:46 GMT

    In e2cf289/rtems:

    bsp/mcf548x: Use public include path Update #3254.
    Comment 61
    1. Chris Johns, Fri, 05 Jan 2018 10:59:58 GMT

    In 010bf86/rtems:

    bsps/powerpc: Use public include path Update #3254.
    Comment 62
    1. Chris Johns, Fri, 05 Jan 2018 11:00:11 GMT

    In 9dd2fdb9/rtems:

    bsps/bfin: Use public include path Update #3254.
    Comment 63
    1. Chris Johns, Fri, 05 Jan 2018 11:00:23 GMT

    In 3964329/rtems:

    bsp/beatnik: Use public include path Update #3254.
    Comment 64
    1. Chris Johns, Fri, 05 Jan 2018 11:00:35 GMT

    In 731abf4/rtems:

    bsp/mvme3100: Use public include path Update #3254.
    Comment 65
    1. Chris Johns, Fri, 05 Jan 2018 11:00:47 GMT

    In 26ac19c/rtems:

    bsps/powerpc: Use public include path Update #3254.
    Comment 66
    1. Chris Johns, Fri, 05 Jan 2018 11:00:59 GMT

    In f4dc9737/rtems:

    bsps: Use public include path Update #3254.
    Comment 67
    1. Chris Johns, Fri, 05 Jan 2018 11:01:11 GMT

    In 8428b40/rtems:

    bsp/edb7312: Use public include path Update #3254.
    Comment 68
    1. Chris Johns, Fri, 05 Jan 2018 11:01:23 GMT

    In 816f999f/rtems:

    bsps/i386: Fix AC_CONFIG_SRCDIR() Update #3254.
    Comment 69
    1. Chris Johns, Fri, 05 Jan 2018 11:01:35 GMT

    In a7b0da2/rtems:

    bsps/mips: Fix AC_CONFIG_SRCDIR() Update #3254.
    Comment 70
    1. Sebastian Huber, Fri, 05 Jan 2018 11:01:47 GMT

    In 7cd389e/rtems:

    bsps/m68k: Install shared Update #3254.
    Comment 71
    1. Sebastian Huber, Mon, 15 Jan 2018 06:26:20 GMT

    In a67f44c/rtems:

    bsps/lm32: Do not include network headers in bsp.h Update #3254.
    Comment 72
    1. Sebastian Huber, Mon, 15 Jan 2018 06:26:32 GMT

    In 4b12436/rtems:

    libchip: Use public include path Update #3254.
    Comment 73
    1. Sebastian Huber, Mon, 15 Jan 2018 06:26:44 GMT

    In 0d08844/rtems:

    bsps: Add AM_CPPFLAGS to special case CPPFLAGS This is necessary to pick up mandatory flags provided by the build system. Update #3254.
    Comment 74
    1. Sebastian Huber, Tue, 16 Jan 2018 09:44:27 GMT

    In 47cc206/rtems:

    bsps/powerpc: Move BSP specific file to BSP Update #3254.
    Comment 75
    1. Sebastian Huber, Mon, 22 Jan 2018 06:06:19 GMT

    In d898f6e/rtems:

    bsp/gen5200: Fix i2c.h and i2cdrv.h installation Install these files only as and . Update #3254.
    Comment 76
    1. Sebastian Huber, Mon, 22 Jan 2018 09:38:31 GMT

    In 17fd0ff/rtems:

    bsps: Move wd80x3.h to libchip/wd80x3.h This header is used also by the motorola_powerpc BSP. Update #3254.
    Comment 77
    1. Sebastian Huber, Mon, 22 Jan 2018 12:17:07 GMT

    In e79bb0c3/rtems:

    bsp/gen5200: Use public include path Update #3254.
    Comment 78
    1. Chris Johns, Thu, 25 Jan 2018 09:17:03 GMT

    In 2afb22b/rtems:

    Remove make preinstall A speciality of the RTEMS build system was the make preinstall step. It copied header files from arbitrary locations into the build tree. The header files were included via the -Bsome/build/tree/path GCC command line option. This has at least seven problems: The make preinstall step itself needs time and disk space. Errors in header files show up in the build tree copy. This makes it hard for editors to open the right file to fix the error. There is no clear relationship between source and build tree header files. This makes an audit of the build process difficult. The visibility of all header files in the build tree makes it difficult to enforce API barriers. For example it is discouraged to use BSP-specifics in the cpukit. An introduction of a new build system is difficult. Include paths specified by the -B option are system headers. This may suppress warnings. The parallel build had sporadic failures on some hosts. This patch removes the make preinstall step. All installed header files are moved to dedicated include directories in the source tree. Let @RTEMS_CPU@ be the target architecture, e.g. arm, powerpc, sparc, etc. Let @RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g. erc32, imx, qoriq, etc. The new cpukit include directories are: cpukit/include cpukit/score/cpu/@RTEMS_CPU@/include cpukit/libnetworking The new BSP include directories are: bsps/include bsps/@RTEMS_CPU@/include bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include There are build tree include directories for generated files. The include directory order favours the most general header file, e.g. it is not possible to override general header files via the include path order. The "bootstrap -p" option was removed. The new "bootstrap -H" option should be used to regenerate the "headers.am" files. Update #3254.
    Comment 79
    1. Sebastian Huber, Fri, 09 Mar 2018 07:44:27 GMT

    In 16f4661f/rtems:

    network: Optionally install network headers Install the network headers only if --enable-networking is specified. Update #3254.
    Comment 80
    1. Sebastian Huber, Wed, 21 Mar 2018 06:59:00 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    The header reorganization is complete.

    Comment 81
    1. Sebastian Huber, Wed, 28 Mar 2018 05:21:29 GMT

    In fc9db4c/rtems-docs:

    user: Do not mention "bootstrap -p" It is now obsolete and was never necessary for an RTEMS users. Update #3254.
    Comment 82
    1. Chris Johns, Wed, 11 Apr 2018 03:28:15 GMT

    In b8c59353/rtems:

    build: Fix make clean. Update #3254.
    Comment 83
    1. Sebastian Huber, Thu, 08 Nov 2018 15:26:52 GMT

    In edc4ff6/rtems-docs:

    user: Remove obsolete boostrap -p step Update #3254.
    Comment 84
    1. Sebastian Huber, Fri, 14 Dec 2018 06:04:11 GMT

    In 6b0a729b/rtems:

    build: Remove ampolish3 Update #3254.

    3255 - Warnings on 64-bit targets

    Link https://devel.rtems.org/ticket/3255
    Id 3255
    Reporter Joel Sherrill
    Created 29 November 2017 19:02:22
    Modified 30 November 2017 06:12:12
    Owner Sebastian Huber
    Type defect
    Component arch/powerpc
    Status closed
    Resolution duplicate
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This occurred on the 64 bit PowerPC and SPARC64 targets.

    log/powerpc-qoriq_e6500_64.log:../../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:57:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
    log/powerpc-qoriq_e6500_64.log:../../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:64:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
    log/powerpc-qoriq_e6500_64.log:../../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:488:11: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'long int' [-Wformat=]
    log/powerpc-qoriq_e6500_64.log:../../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:536:13: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'long int' [-Wformat=]

    Comment 1
    1. Joel Sherrill, Wed, 29 Nov 2017 19:02:35 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 30 Nov 2017 06:12:12 GMT
    2. status: changed from assigned to closed
    3. resolution: set to duplicate

    This is a duplicate of #3156.


    3256 - Ada run-time needs support for self-contained POSIX synchronization objects

    Link https://devel.rtems.org/ticket/3256
    Id 3256
    Reporter Sebastian Huber
    Created 1 December 2017 10:29:59
    Modified 5 December 2017 06:18:26
    Owner Sebastian Huber
    Type defect
    Component tool/gcc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Object types are hard coded in gcc/ada/s-osinte-rtems.ads.

    Attachments:

    1 Sebastian Huber, Fri, 01 Dec 2017 11:04:53 GMT
      attach: set to 0001-RTEMS-Ada-Fix-some-POSIX-types.patch
    2 Sebastian Huber, Mon, 04 Dec 2017 08:41:47 GMT
      attach: set to v2-0001-RTEMS-Ada-Fix-some-POSIX-types.patch
    Comment 1
    1. Sebastian Huber, Fri, 01 Dec 2017 13:09:37 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d60799b/rtems-source-builder:

    5: Ada: Fix some POSIX types Close #3256.
    Comment 2
    1. Sebastian Huber, Mon, 04 Dec 2017 14:18:33 GMT

    In 7034d65/rtems-source-builder:

    5: Ada: Fix more POSIX types Update #3256.
    Comment 3
    1. Sebastian Huber, Tue, 05 Dec 2017 06:18:26 GMT

    In fd5471b/rtems:

    ada: Check C and POSIX types Update #3256.

    3260 - libpci depends on BSP-specific header files

    Link https://devel.rtems.org/ticket/3260
    Id 3260
    Reporter Sebastian Huber
    Created 12 December 2017 07:46:12
    Modified 4 January 2018 06:21:50
    Owner Sebastian Huber
    Type defect
    Component arch/sparc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The libpci is currently only used on SPARC. It is in cpukit, so BSP-specific header files are not allowed. Unfortunately this is not the case for libpci. However, it seems the the routines depending on BSP_PCI_BIG_ENDIAN are not used:

    grep -r 'pci_[ldst]\{2\}_' .
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE uint16_t pci_ld_le16(volatile uint16_t *addr)
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE void pci_st_le16(volatile uint16_t *addr, uint16_t val)
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE uint32_t pci_ld_le32(volatile uint32_t *addr)
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE void pci_st_le32(volatile uint32_t *addr, uint32_t val)
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE uint16_t pci_ld_be16(volatile uint16_t *addr)
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE void pci_st_be16(volatile uint16_t *addr, uint16_t val)
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE uint32_t pci_ld_be32(volatile uint32_t *addr)
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE void pci_st_be32(volatile uint32_t *addr, uint32_t val)
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE uint16_t pci_ld_le16(volatile uint16_t *addr)
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE void pci_st_le16(volatile uint16_t *addr, uint16_t val)
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE uint32_t pci_ld_le32(volatile uint32_t *addr)
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE void pci_st_le32(volatile uint32_t *addr, uint32_t val)
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE uint16_t pci_ld_be16(volatile uint16_t *addr)
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE void pci_st_be16(volatile uint16_t *addr, uint16_t val)
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE uint32_t pci_ld_be32(volatile uint32_t *addr)
    ./cpukit/libpci/pci/access.h:RTEMS_INLINE_ROUTINE void pci_st_be32(volatile uint32_t *addr, uint32_t val)

    Is this dead code and can I remove BSP_PCI_BIG_ENDIAN?

    Another issue is the use of a BSP-specific interrupt API in cpukit/libpci/pci/irq.h.

    The missing functions should be added to .

    Comment 1
    1. Sebastian Huber, Thu, 04 Jan 2018 06:20:11 GMT

    In 7190005/rtems:

    sparc: Move Update #3254. Update #3260.
    Comment 2
    1. Sebastian Huber, Thu, 04 Jan 2018 06:20:23 GMT

    In 3b392b6/rtems:

    sparc: Remove BSP specifics from Update #3254. Update #3260.
    Comment 3
    1. Sebastian Huber, Thu, 04 Jan 2018 06:20:36 GMT

    In 569fd50/rtems:

    sparc: Remove BSP specifics from Update #3254. Update #3260. Update #3269.
    Comment 4
    1. Sebastian Huber, Thu, 04 Jan 2018 06:20:49 GMT

    In 4e100058/rtems:

    sparc: Remove from PCI shell command Update #3254. Update #3260.
    Comment 5
    1. Sebastian Huber, Thu, 04 Jan 2018 06:21:50 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    See also #3269.


    3261 - A couple of documentation typos

    Link https://devel.rtems.org/ticket/3261
    Id 3261
    Reporter Frédéric Jouault
    Created 13 December 2017 10:24:32
    Modified 4 January 2019 10:11:28
    Owner Frédéric Jouault <f.jouault@…>
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This patch includes a couple of typo corrections in the C User Manual.

    Attachments:

    1 Frédéric Jouault, Wed, 13 Dec 2017 10:25:27 GMT
      attach: set to 0001-fixed-couple-of-typos.patch
    Comment 1
    1. Sebastian Huber, Fri, 04 Jan 2019 10:00:38 GMT
    2. version: set to 5
    3. milestone: set to 5.1
    Comment 2
    1. Frédéric Jouault, Fri, 04 Jan 2019 10:11:28 GMT
    2. owner: set to Frédéric Jouault <f.jouault@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 4de0da1/rtems-docs:

    c-user: Fix typos Close #3261.

    3264 - Add monotonic watchdog based on uptime

    Link https://devel.rtems.org/ticket/3264
    Id 3264
    Reporter Sebastian Huber
    Created 21 December 2017 12:41:55
    Modified 5 February 2018 10:39:52
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The CLOCK_MONOTONIC time services use currently the clock tick based watchdog. This is a problem in case the uptime (measured via the timercounter) and the ticks since boot drift away (measured via the clock ticks). Introduce a new watchdog which uses the uptime. The memory overhead is quite small (two pointers per processor).

    Comment 1
    1. Sebastian Huber, Fri, 02 Feb 2018 14:20:36 GMT

    In 89c0313/rtems:

    score: Optimize watchdog tickle Avoid unnecessary lock acquire/release operations. Get realtime via timecounter only if necessary. Update #3264.
    Comment 2
    1. Sebastian Huber, Fri, 02 Feb 2018 14:20:48 GMT

    In 3a4e044/rtems:

    score: Rename _Watchdog_Realtime_from_*() Rename _Watchdog_Realtime_from_*() to _Watchdog_Ticks_from_*(). Update #3264.
    Comment 3
    1. Sebastian Huber, Fri, 02 Feb 2018 14:21:00 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 9480815a/rtems:

    score: Introduce new monotonic clock Rename PER_CPU_WATCHDOG_MONOTONIC to PER_CPU_WATCHDOG_TICKS. Add new PER_CPU_WATCHDOG_MONOTONIC which is based on the system uptime (measured by timecounter). Close #3264.
    Comment 4
    1. Sebastian Huber, Mon, 05 Feb 2018 10:39:52 GMT

    In a0633c5/rtems-libbsd:

    SLEEPQUEUE(9): Update due to API changes Update #3264.

    3265 - Use second one based uptime for CLOCK_MONOTONIC for FreeBSD compatibility

    Link https://devel.rtems.org/ticket/3265
    Id 3265
    Reporter Sebastian Huber
    Created 22 December 2017 12:39:56
    Modified 2 February 2018 14:21:12
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This simplifies the CLOCK_MONOTONIC based time services. It is potentially important for libbsd.

    Comment 1
    1. Sebastian Huber, Fri, 02 Feb 2018 14:21:12 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 8fa4549/rtems:

    posix: Use one second based CLOCK_MONOTONIC This simplifies the CLOCK_MONOTONIC based time services. It is potentially important for libbsd. Close #3265.

    3266 - cpukit/libpci references BSP headers.

    Link https://devel.rtems.org/ticket/3266
    Id 3266
    Reporter Chris Johns
    Created 24 December 2017 04:03:35
    Modified 2 January 2018 06:23:05
    Owner  
    Type defect
    Component lib
    Status closed
    Resolution duplicate
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    On the no-preinstall branch of ​https://git.rtems.org/chrisj/rtems.git/ the build fails with:

    sparc-rtems5-gcc --pipe -DHAVE_CONFIG_H   -I.. -I/opt/work/chris/rtems/kernel/bsps/beagleboneblack/sparc-rtems5/c/erc32/include -I/opt/work/chris/rtems/kernel/rtems.git/cpukit/include -I/opt/work/chris/rtems/kernel/rtems.git/cpukit/score/cpu/sparc/include   -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -MT pci_access.o -MD -MP -MF $depbase.Tpo -c -o pci_access.o /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/libpci/pci_access.c &&\
    mv -f $depbase.Tpo $depbase.Po
    In file included from /opt/work/chris/rtems/kernel/rtems.git/cpukit/include/pci.h:23:0,
    from /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/libpci/pci_access.c:10:
    /opt/work/chris/rtems/kernel/rtems.git/cpukit/include/pci/access.h:16:10: fatal error: libcpu/byteorder.h: No such file or directory
    #include
    ^~~~~~~~~~~~~~~~~~~~

    This header is found under:

    $ find . -name byteorder.h
    ./bsps/powerpc/include/libcpu/byteorder.h
    ./bsps/sparc/include/libcpu/byteorder.h
    ./bsps/i386/include/libcpu/byteorder.h
    Comment 1
    1. Joel Sherrill, Sun, 24 Dec 2017 20:09:09 GMT

    Is there anything in the implementations that is BSP, not architecture, specific? They could be moved to cpukit if we have confidence they can be implemented always that way.

    Or they can be real methods provided by the bsl

    Comment 2
    1. Chris Johns, Tue, 26 Dec 2017 21:59:42 GMT

    Replying to Joel Sherrill:

    Is there anything in the implementations that is BSP, not architecture, specific? They could be moved to cpukit if we have confidence they can be implemented always that way.

    Or they can be real methods provided by the bsl

    Sorry I do not know.

    Comment 3
    1. Sebastian Huber, Tue, 02 Jan 2018 06:22:44 GMT

    This is a duplicate of #3260.

    Comment 4
    1. Sebastian Huber, Tue, 02 Jan 2018 06:23:05 GMT
    2. status: changed from new to closed
    3. resolution: set to duplicate

    3267 - rtems/status-checks.h calls printk without including the needed header.

    Link https://devel.rtems.org/ticket/3267
    Id 3267
    Reporter Chris Johns
    Created 27 December 2017 02:22:40
    Modified 21 March 2018 06:49:56
    Owner  
    Type defect
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    /opt/work/chris/rtems/kernel/rtems.git/cpukit/include/rtems/status-checks.h:74:7: warning: implicit declaration of function 'printk'; did you mean 'printf'? [-Wimplicit-function-declaration]
    printk( fmt, ##__VA_ARGS__)
    ^
    /opt/work/chris/rtems/kernel/rtems.git/cpukit/include/rtems/status-checks.h:86:3: note: in expansion of macro 'RTEMS_SYSLOG_PRINT'
    RTEMS_SYSLOG_PRINT( "%s: " fmt, __func__, ##__VA_ARGS__)
    ^~~~~~~~~~~~~~~~~~
    /opt/work/chris/rtems/kernel/rtems.git/cpukit/include/rtems/status-checks.h:107:3: note: in expansion of macro 'RTEMS_SYSLOG'
    RTEMS_SYSLOG( "Error: " fmt, ##__VA_ARGS__)
    ^~~~~~~~~~~~
    /opt/work/chris/rtems/kernel/rtems.git/cpukit/include/rtems/status-checks.h:113:3: note: in expansion of macro 'RTEMS_SYSLOG_ERROR'
    RTEMS_SYSLOG_ERROR( "SC = %i: %s\n", (int) sc, msg);
    ^~~~~~~~~~~~~~~~~~
    /opt/work/chris/rtems/kernel/rtems.git/cpukit/include/rtems/status-checks.h:152:5: note: in expansion of macro 'RTEMS_SYSLOG_ERROR_WITH_SC'
    RTEMS_SYSLOG_ERROR_WITH_SC( sc, msg); \
    ^~~~~~~~~~~~~~~~~~~~~~~~~~
    /opt/work/chris/rtems/kernel/rtems.git/c/src/lib/libbsp/lm32/milkymist/../../lm32/shared/milkymist_gpio/gpio.c:57:5: note: in expansion of macro 'RTEMS_CHECK_SC'
    RTEMS_CHECK_SC(sc, "create GPIO device");
    ^~~~~~~~~~~~~~
    Comment 1
    1. Chris Johns, Wed, 27 Dec 2017 02:55:00 GMT

    ​https://git.rtems.org/chrisj/rtems.git/commit/?h=no-preinstall&id=8d355aaf02669edec4e4d2f5d1100b4253637af5

    Comment 2
    1. Sebastian Huber, Wed, 21 Mar 2018 06:49:56 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    3268 - PowerPC BSP include naming mess.

    Link https://devel.rtems.org/ticket/3268
    Id 3268
    Reporter Chris Johns
    Created 1 January 2018 00:01:11
    Modified 22 January 2018 11:32:08
    Owner  
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The PowerPC BSP family headers need some refactoring for the RTEMS 5 release. The BSP family relies on the preinstall process to get suitable headers installed to work and removing preinstall exposes this. The specific issue appears with irq.h when building the no-preinstall branch. There is a PowerPC BSP family header and a number of BSPs also have an irq.h which overrides families header. The code has #include and the header used depends on the include order on the GCC command line. This is fragile for any user. These headers needs to be moved to BSP specific paths, for example #include .

    Comment 1
    1. Chris Johns, Mon, 01 Jan 2018 00:01:31 GMT
    2. component: changed from admin to arch/powerpc
    Comment 2
    1. Chris Johns, Mon, 01 Jan 2018 01:16:31 GMT

    Add on to the list i2c.h in the mpc5200.

    Comment 3
    1. Sebastian Huber, Thu, 04 Jan 2018 06:19:59 GMT

    In e1c0d67/rtems:

    bsp/mpc55xxevb: Move Update #3254. Update #3268.
    Comment 4
    1. Sebastian Huber, Thu, 04 Jan 2018 06:21:02 GMT

    In fb01816b/rtems:

    bsps/powerpc: Move shared irq.h This header file is only used by motorola_powerpc, so not shared. Update #3254. Update #3268.
    Comment 5
    1. Sebastian Huber, Mon, 22 Jan 2018 11:32:08 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    This problem was fixed by [d898f6e18ec2e84977edb5024052ecca64cf39f3/rtems].


    3270 - Remove unused support for MPC505

    Link https://devel.rtems.org/ticket/3270
    Id 3270
    Reporter Sebastian Huber
    Created 4 January 2018 14:37:28
    Modified 5 February 2018 11:13:20
    Owner Sebastian Huber
    Type task
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    There is some support for MPC505 in libcpu, however, I cannot find a BSP
    for this code. Remove this apparently dead code.

    Comment 1
    1. Sebastian Huber, Mon, 05 Feb 2018 11:13:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 0f4a7391/rtems:

    bsps/powerpc: Remove support for mpc505 Close #3270.

    3277 - QorIQ: Add MAC-less DPAA driver to libbsd

    Link https://devel.rtems.org/ticket/3277
    Id 3277
    Reporter Sebastian Huber
    Created 23 January 2018 13:54:06
    Modified 5 February 2018 10:41:20
    Owner Sebastian Huber
    Type enhancement
    Component network/libbsd
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The SDK Linux DPAA driver supports a so called MAC-less interface driver. This driver allows Ethernet communication between guest systems of a hypervisor.

    Comment 1
    1. Sebastian Huber, Tue, 23 Jan 2018 13:57:00 GMT

    In fe05886/rtems-libbsd:

    linux/compiler.h: Define cold Update #3277.
    Comment 2
    1. Sebastian Huber, Tue, 23 Jan 2018 13:57:09 GMT

    In 583216a/rtems-libbsd:

    linux/smp.h: Avoid function call overhead Update #3277.
    Comment 3
    1. Sebastian Huber, Tue, 23 Jan 2018 13:57:19 GMT

    In 066b536/rtems-libbsd:

    linux/sort.h: New file Update #3277.
    Comment 4
    1. Sebastian Huber, Tue, 23 Jan 2018 13:57:28 GMT

    In 0d421d8/rtems-libbsd:

    linux/of.h: Add of_n_addr_cells() Update #3277.
    Comment 5
    1. Sebastian Huber, Tue, 23 Jan 2018 13:57:38 GMT

    In 26ce2ac/rtems-libbsd:

    linux/of.h: Add of_n_size_cells() Update #3277.
    Comment 6
    1. Sebastian Huber, Tue, 23 Jan 2018 13:57:47 GMT

    In 44fca38/rtems-libbsd:

    linux/of.h: Add of_read_number() Update #3277.
    Comment 7
    1. Sebastian Huber, Tue, 23 Jan 2018 13:57:57 GMT

    In 81fc57d/rtems-libbsd:

    linux/of.h: Add of_find_node_by_path() Update #3277.
    Comment 8
    1. Sebastian Huber, Tue, 23 Jan 2018 13:58:06 GMT

    In 0f1d2f6/rtems-libbsd:

    linux/of_address.h: Add of_translate_address() Update #3277.
    Comment 9
    1. Sebastian Huber, Tue, 23 Jan 2018 13:58:16 GMT

    In e4923c8/rtems-libbsd:

    linux/of_address.h: of_address_to_resource() Translate address in of_address_to_resource(). Update #3277.
    Comment 10
    1. Sebastian Huber, Tue, 23 Jan 2018 13:58:25 GMT

    In cfc149b/rtems-libbsd:

    linux/of_irq.h: Generalize of_irq_to_resource() Determine interrupt cells via device tree. Update #3277.
    Comment 11
    1. Sebastian Huber, Tue, 23 Jan 2018 13:58:35 GMT

    In 2fba1e4/rtems-libbsd:

    dpaa: Remove unused configuration defines Update #3277.
    Comment 12
    1. Sebastian Huber, Tue, 23 Jan 2018 13:58:44 GMT

    In bdf99316/rtems-libbsd:

    dpaa: Disable unused bman_pool members Update #3277.
    Comment 13
    1. Sebastian Huber, Tue, 23 Jan 2018 13:58:54 GMT

    In 34b7ccc/rtems-libbsd:

    dpaa: Support FQ_TYPE_RX_PCD Update #3277.
    Comment 14
    1. Sebastian Huber, Tue, 23 Jan 2018 13:59:03 GMT

    In 1342fad/rtems-libbsd:

    dpaa: Add and use SDK_DPAA_COMPAT_STATIC Update #3277.
    Comment 15
    1. Sebastian Huber, Tue, 23 Jan 2018 13:59:12 GMT

    In 95fe5b1/rtems-libbsd:

    dpaa: Use device tree throughout in BMan init Update #3277.
    Comment 16
    1. Sebastian Huber, Tue, 23 Jan 2018 13:59:22 GMT

    In a7d252c/rtems-libbsd:

    dpaa: Add and use bman_new_pool_for_bpid() Update #3277.
    Comment 17
    1. Sebastian Huber, Tue, 23 Jan 2018 13:59:32 GMT

    In 0f6ff4a/rtems-libbsd:

    dpaa: QMan portal only initialization Update #3277.
    Comment 18
    1. Sebastian Huber, Tue, 23 Jan 2018 13:59:41 GMT

    In f5ed3aa/rtems-libbsd:

    sdk_dpaa: Import from QorIQ SDK Linux ​http://git.freescale.com/git/cgit.cgi/ppc/sdk/linux.git Commit 1ae843c08261402b2c35d83422e4fa1e313611f4 (fsl-sdk-v2.0-1703). Update #3277.
    Comment 19
    1. Sebastian Huber, Tue, 23 Jan 2018 13:59:51 GMT

    In d62a3df/rtems-libbsd:

    sdk_dpaa: Port to RTEMS Update #3277.
    Comment 20
    1. Sebastian Huber, Tue, 23 Jan 2018 14:00:00 GMT

    In 327f4e1/rtems-libbsd:

    sdk_dpaa: What to do with tail queue drop? The issue is this: static int dpaa_eth_macless_probe(struct platform_device *_of_dev) { [...]
    INIT_LIST_HEAD(&priv->dpa_fq_list);
    err = dpa_fq_probe_macless(dev, &priv->dpa_fq_list, RX); if (!err)
    err = dpa_fq_probe_macless(dev, &priv->dpa_fq_list,
    TX);
    if (err < 0)
    goto fq_probe_failed;
    [...]
    /* Add the FQs to the interface, and make them active */ /* For MAC-less devices we only get here for RX frame queues
    initialization, which are the TX queues of the other partition. It is safe to rely on one partition to set the FQ taildrop threshold for the TX queues of the other partition because the ERN notifications will be received by the partition doing qman_enqueue. */
    err = dpa_fqs_init(dev, &priv->dpa_fq_list, true); if (err < 0)
    goto fq_alloc_failed;
    [...] The priv->dpa_fq_list contains a list of FQ_TYPE_RX_PCD and FQ_TYPE_TX items. I don't understand what the "For MAC-less devices we only get here for RX frame queues initialization" means in this context. The td_enable == true in dpa_fqs_init(). So, we have: int dpa_fq_init(struct dpa_fq *dpa_fq, bool td_enable) { [...]
    if (dpa_fq->fq_type == FQ_TYPE_TX
    dpa_fq->fq_type == FQ_TYPE_TX_CONFIRM dpa_fq->fq_type == FQ_TYPE_TX_CONF_MQ) {
    [...]
    initfq.we_mask |= QM_INITFQ_WE_OAC;
    [...]
    }
    if (td_enable) {
    initfq.we_mask |= QM_INITFQ_WE_TDTHRESH; qm_fqd_taildrop_set(&initfq.fqd.td,
    DPA_FQ_TD, 1);
    initfq.fqd.fq_ctrl = QM_FQCTRL_TDE;
    }
    The td_enable == true && dpa_fq->fq_type == FQ_TYPE_TX causes later: int qman_init_fq(struct qman_fq *fq, u32 flags, struct qm_mcc_initfq *opts) { [...]
    if (opts && (opts->we_mask & QM_INITFQ_WE_OAC)) {
    /* And can't be set at the same time as TDTHRESH */ if (opts->we_mask & QM_INITFQ_WE_TDTHRESH)
    return -EINVAL;
    }
    This aborts the initialization of the MAC-less driver. I don't understand why this path doesn't happen on the SDK Linux system. Update #3277.
    Comment 21
    1. Sebastian Huber, Mon, 05 Feb 2018 10:41:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3278 - bsp-builder has incorrect print (%s in output)

    Link https://devel.rtems.org/ticket/3278
    Id 3278
    Reporter Joel Sherrill
    Created 23 January 2018 21:18:19
    Modified 31 January 2018 23:52:37
    Owner Chris Johns
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I don't think the tools have branches so only impacts master.

    Notice the "run: %s:"

    [1114/1565] powerpc/mpc5674fevb (profiling) Configuring
    run: %s: powerpc/mpc5674fevb.profiling\

    /home/joel/rtems-work/rtems/configure --target=powerpc-rtems5\
    --enable-rtemsbsp=mpc5674fevb --prefix=/home/joel/rtems-work/bsps\
    --enable-profiling

    Comment 1
    1. Joel Sherrill, Tue, 23 Jan 2018 21:18:35 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Chris Johns, Wed, 31 Jan 2018 23:52:37 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 005f995/rtems-tools:

    rtems-bsp-builder: Remove stray %s from the run log message. Close #3278

    3281 - Add epiphany support to GDB 8.0.0

    Link https://devel.rtems.org/ticket/3281
    Id 3281
    Reporter Sebastian Huber
    Created 26 January 2018 08:06:09
    Modified 5 February 2018 10:43:30
    Owner Sebastian Huber
    Type enhancement
    Component tool/gdb
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Attachments:

    1 Sebastian Huber, Fri, 26 Jan 2018 08:06:50 GMT
      attach: set to gdb-8.0.0-epiphany.patch
    Comment 1
    1. Sebastian Huber, Mon, 05 Feb 2018 10:43:30 GMT
    2. status: changed from assigned to closed
    3. resolution: set to wontfix

    GDB is support for ephiphany is not integrated in the FSF GDB. Adapteva didn't respond to e-mails.


    3283 - Bad URL in OpenOCD/Xilinx_Zynq Wiki Page

    Link https://devel.rtems.org/ticket/3283
    Id 3283
    Reporter Joel Sherrill
    Created 26 January 2018 15:10:31
    Modified 31 January 2018 00:11:55
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    ​https://devel.rtems.org/wiki/Debugging/OpenOCD/Xilinx_Zynq has a link to the Zedboard Processor Debug Adapter. I think the URL has changed to this but would like someone more knowledgeable to confirm that before it is changed.

    ​http://zedboard.org/accessories/zedboard-processor-debug-adapter

    Comment 1
    1. Joel Sherrill, Fri, 26 Jan 2018 15:10:44 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Chris Johns, Wed, 31 Jan 2018 00:11:55 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Wiki page links have been updated.


    3284 - RSB uses hard coded GCC binary paths

    Link https://devel.rtems.org/ticket/3284
    Id 3284
    Reporter Sebastian Huber
    Created 30 January 2018 09:36:36
    Modified 1 February 2018 06:14:47
    Owner Sebastian Huber <sebastian.huber@…>
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In order to build a tool chain with Ada support you need a native GCC with Ada support of the same version as the cross compiler. The RSB uses hard coded paths for the gcc and g++ programs:

    source-builder/defaults.mc:__cc:                exe,     required, '/usr/bin/gcc'
    source-builder/defaults.mc:__cxx: exe, required, '/usr/bin/g++'

    So, the RSB user must change the main GCC installation of the machine to build a particular RTEMS tool chain. This is undesired/infeasible in most situations.

    Comment 1
    1. Chris Johns, Wed, 31 Jan 2018 00:03:21 GMT

    I am OK with changing this to 'gcc' and 'g++'. There are a few other paths that could be relaxed, ie I remembering seeing something in your build logs.

    This is something that has appeared as the RSB ages.

    Comment 2
    1. Sebastian Huber, Thu, 01 Feb 2018 06:14:47 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 2a5c9da/rtems-source-builder:

    Avoid hard coded GCC binary paths In order to build a tool chain with Ada support a native GCC with Ada support of the same version as the cross compiler is required. The RSB used hard coded paths for the gcc and g++ programs. This forced the RSB user to change the main GCC installation of the machine to build a particular RTEMS tool chain. This is undesired/infeasible in most situations. Close #3284.

    3285 - Reorganize BSP source directory

    Link https://devel.rtems.org/ticket/3285
    Id 3285
    Reporter Sebastian Huber
    Created 30 January 2018 09:48:03
    Modified 3 August 2018 12:15:34
    Owner Sebastian Huber
    Type task
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Now, that all BSP header files are in

    • bsps/include
    • bsps/@RTEMS_CPU@/include
    • bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@/include

    we should also move the BSP sources to this new directory tree. How do we want to organize the BSP sources in bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@?

    • include (this is already there, see #3254)
    • config
      • somebsp.cfg
    • start (everything required to run a minimal application without devices)
      • start.S
      • bspstart.c
      • bspsmp.c
      • linkcmds
    • cache (everything for the cache controller support)
    • irq (everything for the interrupt controller support)
    • console (everything for the console driver)
    • clock (everything for the clock driver
    • i2c (everything for the I2C driver)
    • spi (everything for the SPI driver)
    • net (legacy network stack drivers)
    • mpci (RTEMS_MULTIPROCESSING support)
    • rtc (everything for the RTC driver)
    • ata (everything for the ATA driver)
    • contrib (import of external sources)
      • The layout of external sources should be used as is if possible.
    Comment 1
    1. Sebastian Huber, Wed, 31 Jan 2018 11:51:51 GMT

    In 4cf93658/rtems:

    bsps: Rework cache manager implementation The previous cache manager support used a single souce file (cache_manager.c) which included an implementation header (cache_.h). This required the use of specialized include paths to find the right header file. Change this to include a generic implementation header (cacheimpl.h) in specialized source files. Use the following directories and files: bsps/shared/cache bsps/@RTEMS_CPU@/shared/cache bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILY/start/cache.c Update #3285.
    Comment 2
    1. Sebastian Huber, Wed, 31 Jan 2018 11:53:45 GMT
    2. description: modified (diff)
    Comment 3
    1. Sebastian Huber, Fri, 02 Feb 2018 06:09:05 GMT

    In 5f0a6376/rtems:

    bsp/leon3: Do not use internal cache API Update #3285.
    Comment 4
    1. Sebastian Huber, Mon, 05 Feb 2018 10:42:12 GMT
    2. milestone: changed from 5.1 to 6.1
    Comment 5
    1. Sebastian Huber, Tue, 13 Mar 2018 07:06:40 GMT

    In a4570829/rtems:

    bsps: Remove unused memcpy() implementations This patch is a part of the BSP source reorganization. Update #3285.
    Comment 6
    1. Sebastian Huber, Tue, 13 Mar 2018 07:06:50 GMT

    In 4c83f292/rtems:

    bsps: Remove unused RTEMS_CPU_MODEL This patch is a part of the BSP source reorganization. Update #3285.
    Comment 7
    1. Sebastian Huber, Tue, 13 Mar 2018 07:07:00 GMT

    In 961e2ef/rtems:

    bsps/mips: Remove Mongoose-V README This patch is a part of the BSP source reorganization. Update #3285.
    Comment 8
    1. Sebastian Huber, Tue, 13 Mar 2018 07:07:11 GMT

    In b6755af/rtems:

    bsps/mips: Move libcpu content to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 9
    1. Sebastian Huber, Tue, 13 Mar 2018 07:07:22 GMT

    In c4905d8d/rtems:

    bsps/arm: Move libcpu content to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 10
    1. Sebastian Huber, Tue, 13 Mar 2018 07:07:32 GMT

    In 8b5778e/rtems:

    sparc: Move libcpu content to cpukit This patch is a part of the BSP source reorganization. Update #3285.
    Comment 11
    1. Sebastian Huber, Tue, 13 Mar 2018 07:07:42 GMT

    In 7633f5b/rtems:

    sparc64: Move libcpu content to cpukit This patch is a part of the BSP source reorganization. Update #3285.
    Comment 12
    1. Sebastian Huber, Mon, 19 Mar 2018 12:12:49 GMT

    In ac04bb85/rtems:

    bsps/powerpc: Move legacy IRQ support This patch is a part of the BSP source reorganization. Update #3285.
    Comment 13
    1. Sebastian Huber, Mon, 19 Mar 2018 12:13:00 GMT

    In 7dbc43d/rtems:

    bsps/powerpc: Move basic support to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 14
    1. Sebastian Huber, Mon, 19 Mar 2018 12:13:10 GMT

    In ff3b9aa/rtems:

    bsps/powerpc: Remove unused files This patch is a part of the BSP source reorganization. Update #3285.
    Comment 15
    1. Sebastian Huber, Mon, 19 Mar 2018 12:13:21 GMT

    In bd150801/rtems:

    bsps/powerpc: Move exceptions support to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 16
    1. Sebastian Huber, Mon, 19 Mar 2018 12:13:32 GMT

    In 09dd82a/rtems:

    bsp/ss555: Move libcpu content to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 17
    1. Sebastian Huber, Thu, 22 Mar 2018 06:02:34 GMT

    In a7fa9e91/rtems:

    bsp/pc386: Move libcpu content to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 18
    1. Sebastian Huber, Thu, 22 Mar 2018 06:02:44 GMT

    In f3a51d62/rtems:

    bsps/powerpc: Remove bsp_timer_internal_clock The only consumer of this variable was the ppc403 clock driver used by the haleakala, virtex, and virtex4 BSPs which set bsp_timer_internal_clock unconditionally to true. Update #3285.
    Comment 19
    1. Sebastian Huber, Thu, 22 Mar 2018 06:02:55 GMT

    In bb22a3f3/rtems:

    bsp/powerpc: Move libcpu timer to bsps Use only one timer driver variant based on the standard PowerPC time base. This patch is a part of the BSP source reorganization. Update #3285.
    Comment 20
    1. Sebastian Huber, Thu, 22 Mar 2018 07:42:45 GMT

    In 3f3f246a/rtems:

    bsps/mpc55xx: Remove unused files This patch is a part of the BSP source reorganization. Update #3285.
    Comment 21
    1. Sebastian Huber, Thu, 22 Mar 2018 07:42:55 GMT

    In dc1ea01/rtems:

    bsps/mpc55xx: Move libcpu content to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 22
    1. Sebastian Huber, Mon, 26 Mar 2018 09:09:58 GMT

    In b1b7390/rtems:

    bsp/pc386: Fix build This patch is a part of the BSP source reorganization. Update #3285.
    Comment 23
    1. Sebastian Huber, Mon, 26 Mar 2018 09:10:08 GMT

    In 96400050/rtems:

    bsp/pc386: Remove unused RTEMS_CPU_MODEL This patch is a part of the BSP source reorganization. Update #3285.
    Comment 24
    1. Sebastian Huber, Mon, 26 Mar 2018 09:10:19 GMT

    In e2bd1f6/rtems:

    bsp/bfin: Move libcpu content to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 25
    1. Sebastian Huber, Mon, 26 Mar 2018 09:10:29 GMT

    In 0cab067/rtems:

    bsps/powerpc: Move libcpu content to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 26
    1. Sebastian Huber, Mon, 26 Mar 2018 09:10:40 GMT

    In a12dcff8/rtems:

    bsp/mpc8260: Move libcpu content to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 27
    1. Sebastian Huber, Mon, 26 Mar 2018 09:10:51 GMT

    In b8c468b/rtems:

    bsp/tqm8xx: Move libcpu content to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 28
    1. Sebastian Huber, Mon, 26 Mar 2018 09:11:01 GMT

    In 11fe8c59/rtems:

    bsps/powerpc: Move MMU support to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 29
    1. Sebastian Huber, Mon, 26 Mar 2018 09:11:12 GMT

    In d813d9aa/rtems:

    bsps/powerpc: Move dec clock driver to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 30
    1. Sebastian Huber, Mon, 26 Mar 2018 09:11:22 GMT

    In 4fd1ff0f/rtems:

    bsps/powerpc: Move AltiVec? support to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 31
    1. Sebastian Huber, Mon, 26 Mar 2018 09:11:32 GMT

    In d7c232f/rtems:

    bsps/powerpc: Remove unused files This patch is a part of the BSP source reorganization. Update #3285.
    Comment 32
    1. Sebastian Huber, Mon, 26 Mar 2018 09:11:43 GMT

    In 2d33672a/rtems:

    bsps/powerpc: Move ppc403 clock driver to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 33
    1. Sebastian Huber, Mon, 26 Mar 2018 09:11:53 GMT

    In 6882be7/rtems:

    bsps/powerpc: Remove libcpu/powerpc This patch is a part of the BSP source reorganization. Update #3285.
    Comment 34
    1. Sebastian Huber, Mon, 26 Mar 2018 09:12:04 GMT

    In 5f59e2a/rtems:

    bsps/powerpc: Move dec timer driver This patch is a part of the BSP source reorganization. Update #3285.
    Comment 35
    1. Sebastian Huber, Mon, 26 Mar 2018 13:33:24 GMT

    In f8e4755f/rtems:

    bsps/m68k: Use namespace header This patch is a part of the BSP source reorganization. Update #3285.
    Comment 36
    1. Sebastian Huber, Mon, 26 Mar 2018 13:33:35 GMT

    In 1e23c47/rtems:

    bsps/m68k: Remove unused define This patch is a part of the BSP source reorganization. Update #3285.
    Comment 37
    1. Sebastian Huber, Mon, 26 Mar 2018 13:33:46 GMT

    In fc2ec62/rtems:

    bsps/m68k: Move libcpu content to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 38
    1. Sebastian Huber, Mon, 26 Mar 2018 13:33:57 GMT

    In 3cf2bf63/rtems:

    bsps/m68k: Move fpsp support to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 39
    1. Sebastian Huber, Mon, 26 Mar 2018 13:34:08 GMT

    In 2190bc6/rtems:

    bsps/mcf5206elite: Move libcpu content to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 40
    1. Sebastian Huber, Mon, 26 Mar 2018 13:34:19 GMT

    In ddf3ea2/rtems:

    bsps/csb360: Move libcpu content to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 41
    1. Sebastian Huber, Mon, 26 Mar 2018 13:34:30 GMT

    In 945095d/rtems:

    bsps/genmcf548x: Move libcpu content to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 42
    1. Sebastian Huber, Mon, 26 Mar 2018 13:34:53 GMT

    In b54558ac/rtems:

    bsps/mcf5225x: Move libcpu content to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 43
    1. Sebastian Huber, Mon, 26 Mar 2018 13:35:04 GMT

    In 5d39512/rtems:

    bsps/m68k: Remove libcpu/m68k This patch is a part of the BSP source reorganization. Update #3285.
    Comment 44
    1. Sebastian Huber, Mon, 26 Mar 2018 13:35:15 GMT

    In 699fee43/rtems:

    bsps: Remove libcpu This patch is a part of the BSP source reorganization. Update #3285.
    Comment 45
    1. Sebastian Huber, Wed, 04 Apr 2018 11:51:10 GMT

    In 66b99a1/rtems:

    bsps: Add RTEMS_BSP to bspopts.h This patch is a part of the BSP source reorganization. Update #3285.
    Comment 46
    1. Sebastian Huber, Wed, 04 Apr 2018 11:51:21 GMT

    In ce0ea6f/rtems:

    bsps: Add shared-sources.am This patch is a part of the BSP source reorganization. Update #3285.
    Comment 47
    1. Sebastian Huber, Wed, 04 Apr 2018 11:51:33 GMT

    In 4f0dca3a/rtems:

    bsps: Move version.c and use bspopts.h This patch is a part of the BSP source reorganization. Update #3285. Update #3375.
    Comment 48
    1. Sebastian Huber, Wed, 04 Apr 2018 11:51:45 GMT

    In 8621ed38/rtems:

    bsps: Move config macros to RTEMS_BSP_CONFIGURE Provide HAS_NETWORKING and HAS_SMP Automake conditionals for all BSPs. This patch is a part of the BSP source reorganization. Update #3285.
    Comment 49
    1. Sebastian Huber, Wed, 04 Apr 2018 11:51:56 GMT

    In 27de4e1f/rtems:

    bsps: Move libchip to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 50
    1. Sebastian Huber, Thu, 05 Apr 2018 05:27:30 GMT

    In 82bc976/rtems:

    bsps/bfin: Rename shared.am to shared-sources.am This patch is a part of the BSP source reorganization. Update #3285.
    Comment 51
    1. Sebastian Huber, Thu, 05 Apr 2018 05:27:40 GMT

    In 0f0f249c/rtems:

    bsps/m68k: Rename fpsp.am to fpsp-sources.am This patch is a part of the BSP source reorganization. Update #3285.
    Comment 52
    1. Sebastian Huber, Thu, 05 Apr 2018 05:27:51 GMT

    In 6799a78/rtems:

    bsps/powerpc: Rename to exceptions-sources.am This patch is a part of the BSP source reorganization. Update #3285.
    Comment 53
    1. Sebastian Huber, Thu, 05 Apr 2018 05:28:01 GMT

    In d03ec77d/rtems:

    bsps/powerpc: Rename to shared-sources.am This patch is a part of the BSP source reorganization. Update #3285.
    Comment 54
    1. Sebastian Huber, Mon, 09 Apr 2018 05:12:18 GMT

    In 671c31fc/rtems:

    bsp: Move umon support to bsps The umon support is only used by the csb337 BSP. This patch is a part of the BSP source reorganization. Update #3285.
    Comment 55
    1. Sebastian Huber, Mon, 09 Apr 2018 05:12:38 GMT

    In 814eccb4/rtems:

    bsps: Move VME support to bsps The VME support is only used by powerpc BSPs. This patch is a part of the BSP source reorganization. Update #3285.
    Comment 56
    1. Sebastian Huber, Mon, 09 Apr 2018 05:12:54 GMT

    In 4b28d3c/rtems:

    bsps: Move shmdr to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 57
    1. Sebastian Huber, Mon, 09 Apr 2018 05:13:09 GMT

    In d584269/rtems:

    bsps: Remove librtemsbsp.a wrapup This patch is a part of the BSP source reorganization. Update #3285.
    Comment 58
    1. Sebastian Huber, Mon, 09 Apr 2018 05:13:25 GMT

    In 9b7c456/rtems:

    bsps: Move generic IRQ support to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 59
    1. Sebastian Huber, Mon, 09 Apr 2018 09:38:23 GMT

    In 01d34a3/rtems:

    bsp/csb337: Fix umon support This patch is a part of the BSP source reorganization. Update #3285.
    Comment 60
    1. Sebastian Huber, Mon, 09 Apr 2018 09:41:33 GMT

    In b606998/rtems:

    bsp/genmcf548x: Fix IRQ support This patch is a part of the BSP source reorganization. Update #3285.
    Comment 61
    1. Sebastian Huber, Tue, 10 Apr 2018 05:19:34 GMT

    In 1ce4a9e/rtems:

    bsps: Fix typo in MPCI support This patch is a part of the BSP source reorganization. Update #3285.
    Comment 62
    1. Sebastian Huber, Thu, 12 Apr 2018 05:17:10 GMT

    In f0bcae38/rtems:

    bsps: Remove unused console_select_simple.c This patch is a part of the BSP source reorganization. Update #3285.
    Comment 63
    1. Sebastian Huber, Thu, 12 Apr 2018 05:17:20 GMT

    In b43ea9f/rtems:

    bsps: Move legacy console driver to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 64
    1. Sebastian Huber, Thu, 12 Apr 2018 05:17:41 GMT

    In b46f943c/rtems:

    bsp/motorola_powerpc: Move polled_io.c This file was used by this BSP only. Avoid RTEMS_RELLDFLAGS. This patch is a part of the BSP source reorganization. Update #3285.
    Comment 65
    1. Sebastian Huber, Thu, 12 Apr 2018 05:18:02 GMT

    In 6c4140c/rtems:

    bsps: Avoid line continuation in Makefile.am This patch is a part of the BSP source reorganization. Update #3285.
    Comment 66
    1. Sebastian Huber, Thu, 12 Apr 2018 05:18:12 GMT

    In b78b814/rtems:

    bsps: Avoid source variables in Makefile.am This patch is a part of the BSP source reorganization. Update #3285.
    Comment 67
    1. Sebastian Huber, Thu, 12 Apr 2018 05:18:25 GMT

    In b10caf8/rtems:

    bsps: Remove headers from librtemsbsp_a_SOURCES This was used by the not supported "make dist". This patch is a part of the BSP source reorganization. Update #3285.
    Comment 68
    1. Sebastian Huber, Thu, 12 Apr 2018 05:18:36 GMT

    In 4359c43/rtems:

    bsps: Simplify source file path in Makefile.am This patch is a part of the BSP source reorganization. Update #3285.
    Comment 69
    1. Sebastian Huber, Thu, 12 Apr 2018 05:18:47 GMT

    In c5fe4431/rtems:

    bsps: Move bootcard.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 70
    1. Sebastian Huber, Thu, 12 Apr 2018 05:18:58 GMT

    In ff24c90d/rtems:

    bsps: Remove empty gnatinstallhandler.c This patch is a part of the BSP source reorganization. Update #3285.
    Comment 71
    1. Sebastian Huber, Fri, 13 Apr 2018 07:45:53 GMT

    I move slowly to the real BSP sources. After some review and effort calculation I propose a new structure for the BSPs in bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@:

    include (this is already there, see #3254) make somebsp.cfg start (everything required to run a minimal application without devices) start.S bspstart.c bspsmp.c linkcmds cache (everything for the cache controller support) irq (everything for the interrupt controller support) console (everything for the console driver) clock (everything for the clock driver i2c (everything for the I2C driver) spi (everything for the SPI driver) net (legacy network stack drivers) mpci (RTEMS_MULTIPROCESSING support) contrib (import of external sources) The layout of external sources should be used as is if possible.

    This essentially removes the new dev directory of the original proposal and is closer to the existing BSP layout. The existing layout has standard directory names, but the file names vary greatly. This new proposal helps to move the files with less human intervention.

    Comment 72
    1. Joel Sherrill, Fri, 13 Apr 2018 12:36:21 GMT

    I see you are back to moving the contents of make/custom to make/. I still have my local branch where I was well along the path of doing that. I can resurrect it if desired.

    Comment 73
    1. Chris Johns, Sat, 14 Apr 2018 04:30:25 GMT

    I suggest we move away from make to config. Make is an implementation.

    Can we please create a doc type file in the bsps to list the directories we allow?

    Comment 74
    1. Sebastian Huber, Tue, 17 Apr 2018 05:06:11 GMT

    In 90013f59/rtems:

    bsps: Move tod.c to bsps and rename This patch is a part of the BSP source reorganization. Update #3285.
    Comment 75
    1. Sebastian Huber, Tue, 17 Apr 2018 05:06:23 GMT

    In 1cba1de/rtems:

    bsps: Move bsp-fdt.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 76
    1. Sebastian Huber, Tue, 17 Apr 2018 05:06:33 GMT

    In 9d44ae7/rtems:

    bsps: Move bsp-uboot-board-info.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 77
    1. Sebastian Huber, Tue, 17 Apr 2018 05:06:44 GMT

    In 0a09ac58/rtems:

    bsps: Move stackalloc.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 78
    1. Sebastian Huber, Tue, 17 Apr 2018 05:06:54 GMT

    In 223e22f/rtems:

    bsps: Move uart-output-char.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 79
    1. Sebastian Huber, Tue, 17 Apr 2018 09:02:22 GMT
    2. description: modified (diff)
    Comment 80
    1. Sebastian Huber, Fri, 20 Apr 2018 13:04:46 GMT

    In 300cc68/rtems-docs:

    bsp-howto: Update BSP source code structure This patch is a part of the BSP source reorganization. Update #3285.
    Comment 81
    1. Sebastian Huber, Fri, 20 Apr 2018 13:24:24 GMT

    In 4826858/rtems:

    motorola_powerpc: Remove headers from *_SOURCES This was used by the not supported "make dist". This patch is a part of the BSP source reorganization. Update #3285.
    Comment 82
    1. Sebastian Huber, Fri, 20 Apr 2018 13:24:35 GMT

    In 43bda786/rtems:

    bsps: Move bspclean.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 83
    1. Sebastian Huber, Fri, 20 Apr 2018 13:24:46 GMT

    In 554e39c/rtems:

    bsps: Move bspreset.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 84
    1. Sebastian Huber, Fri, 20 Apr 2018 13:24:58 GMT

    In 0736410/rtems:

    bsps: Move bspreset_loop.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 85
    1. Sebastian Huber, Fri, 20 Apr 2018 13:25:09 GMT

    In 0b93d4f8/rtems:

    bsps: Move bspstart.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 86
    1. Sebastian Huber, Fri, 20 Apr 2018 13:25:32 GMT

    In 5a06b187/rtems:

    bsps: Move bspgetworkarea.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 87
    1. Sebastian Huber, Fri, 20 Apr 2018 13:25:43 GMT

    In a884df3/rtems:

    bsp/motorola_powerpc: Move bspstart.c to bsps This shared powerpc file was only used by this BSP. This patch is a part of the BSP source reorganization. Update #3285.
    Comment 88
    1. Sebastian Huber, Fri, 20 Apr 2018 13:26:04 GMT

    In 0510cd50/rtems:

    bsps: Move doxygen.h files to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 89
    1. Sebastian Huber, Fri, 20 Apr 2018 13:26:15 GMT

    In f923901/rtems:

    bsps: Move pci_bus_count.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 90
    1. Sebastian Huber, Fri, 20 Apr 2018 13:26:25 GMT

    In 9ec8cfc5/rtems:

    bsps: Move pci_find_device.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 91
    1. Sebastian Huber, Fri, 20 Apr 2018 13:26:36 GMT

    In 8d04f18/rtems:

    bsps: Remove unused rtems-stub-glue.c This patch is a part of the BSP source reorganization. Update #3285.
    Comment 92
    1. Sebastian Huber, Fri, 20 Apr 2018 13:26:47 GMT

    In 4b9015c/rtems:

    bsps: Remove unused irq.h template file This patch is a part of the BSP source reorganization. Update #3285.
    Comment 93
    1. Sebastian Huber, Fri, 20 Apr 2018 13:26:57 GMT

    In d6fb37a/rtems:

    bsps: Move shared btimer support to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 94
    1. Sebastian Huber, Fri, 20 Apr 2018 13:27:09 GMT

    In ef78454/rtems:

    bsps: Move gpio.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 95
    1. Sebastian Huber, Fri, 20 Apr 2018 13:27:20 GMT

    In 79b9fe6/rtems:

    bsps: Move getentropy-cpucounter.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 96
    1. Sebastian Huber, Fri, 20 Apr 2018 13:27:30 GMT

    In 7806d9c0/rtems:

    bsps: Move shared CPU counter support to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 97
    1. Sebastian Huber, Fri, 20 Apr 2018 13:27:42 GMT

    In a442939/rtems:

    bsps: Move sbrk.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 98
    1. Sebastian Huber, Fri, 20 Apr 2018 13:27:53 GMT

    In bc010a8d/rtems:

    bsps: Move setvec.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 99
    1. Sebastian Huber, Fri, 20 Apr 2018 13:28:04 GMT

    In 2584f5b/rtems:

    bsps: Move bspsmp.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 100
    1. Sebastian Huber, Fri, 20 Apr 2018 13:28:16 GMT

    In 5c5b021/rtems:

    bsps: Move bspsmpgetcurrentprocessor.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 101
    1. Sebastian Huber, Fri, 20 Apr 2018 13:28:28 GMT

    In 7632906/rtems:

    bsps: Move clock drivers to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 102
    1. Sebastian Huber, Fri, 20 Apr 2018 13:28:40 GMT

    In 58adad4/rtems:

    bsps/powerpc: Move shared btimer support This patch is a part of the BSP source reorganization. Update #3285.
    Comment 103
    1. Sebastian Huber, Fri, 20 Apr 2018 13:28:54 GMT

    In d7d66d7/rtems:

    bsps: Move console drivers to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 104
    1. Sebastian Huber, Fri, 20 Apr 2018 13:29:08 GMT

    In fbcd7c8f/rtems:

    bsps: Move start files to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 105
    1. Sebastian Huber, Fri, 20 Apr 2018 13:29:22 GMT

    In 9964895/rtems:

    bsps: Move startup files to bsps Adjust build support files to new directory layout. This patch is a part of the BSP source reorganization. Update #3285.
    Comment 106
    1. Sebastian Huber, Fri, 20 Apr 2018 13:29:35 GMT

    In e0dd8a5a/rtems:

    bsps: Move benchmark timer to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 107
    1. Sebastian Huber, Fri, 20 Apr 2018 13:29:47 GMT

    In 28b4c7ac/rtems:

    sparc: Move _CPU_Trap_slot_template The definition of _CPU_Trap_slot_template is BSP-independent. A potential para-virtualization support may use . This patch is a part of the BSP source reorganization. Update #3285.
    Comment 108
    1. Sebastian Huber, Fri, 20 Apr 2018 13:29:57 GMT

    In c49896f/rtems:

    sparc: Move irq_asm.S This file is BSP-independent. This patch is a part of the BSP source reorganization. Update #3285.
    Comment 109
    1. Sebastian Huber, Fri, 20 Apr 2018 13:30:09 GMT

    In d60d303c/rtems:

    bsps/sparc: Move shared files to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 110
    1. Sebastian Huber, Fri, 20 Apr 2018 13:30:20 GMT

    In b15cb636/rtems:

    bsps/sparc: Move network drivers to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 111
    1. Sebastian Huber, Fri, 20 Apr 2018 13:30:30 GMT

    In 1efa1c8/rtems:

    bsps: Move MPCI support to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 112
    1. Sebastian Huber, Fri, 20 Apr 2018 13:30:40 GMT

    In 96faf12/rtems:

    bsps/sparc: Move gnatsupp to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 113
    1. Sebastian Huber, Fri, 20 Apr 2018 13:30:51 GMT

    In 67e472c/rtems:

    bsps/leon2: Move PCI driver to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 114
    1. Sebastian Huber, Fri, 20 Apr 2018 13:31:01 GMT

    In 13091dc4/rtems:

    bsps/leon3: Move AMBA support to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 115
    1. Sebastian Huber, Fri, 20 Apr 2018 13:35:45 GMT

    In 4b70ed9/rtems:

    bsps/mvme147s: Fix Makefile.am This patch is a part of the BSP source reorganization. Update #3285.
    Comment 116
    1. Sebastian Huber, Mon, 23 Apr 2018 05:54:44 GMT

    In 676d3d5/rtems-docs:

    bsp-howto: Avoid :file: role with ${...} The curly braces have a special meaning in the :file: role. This patch is a part of the BSP source reorganization. Update #3285.
    Comment 117
    1. Sebastian Huber, Mon, 23 Apr 2018 13:16:02 GMT

    In 1645deb/rtems-source-builder:

    bootstrap: Do not generate acinlude.m4 files Do not generate files which are part of the Git repository. These files should be maintained manually in the future. This patch is a part of the BSP source reorganization. Update #3285.
    Comment 118
    1. Sebastian Huber, Mon, 23 Apr 2018 13:19:00 GMT

    In 37dc047/rtems:

    bsps: Remove AC_CONFIG_SRCDIR() This AC_CONFIG_SRCDIR() is just a sanity check in this insane build system. Since all content of c/src/lib/libbsp/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@ is bound to be moved it makes no sense to keep it. This patch is a part of the BSP source reorganization. Update #3285.
    Comment 119
    1. Sebastian Huber, Mon, 23 Apr 2018 13:19:11 GMT

    In adb85dd/rtems:

    bsps: Move make/custom/* files to bsps Adjust various build files. Remove automatic generation of the c/src/lib/libbsp/*/acinclude.m4 files from bootstrap script. This patch is a part of the BSP source reorganization. Update #3285.
    Comment 120
    1. Sebastian Huber, Mon, 23 Apr 2018 13:19:21 GMT

    In f004ace/rtems:

    bsp/altera-cyclone-v: Move hwlib to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 121
    1. Sebastian Huber, Mon, 23 Apr 2018 13:19:32 GMT

    In 54aabb7/rtems:

    bsp/atsam: Move libraries to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 122
    1. Sebastian Huber, Mon, 23 Apr 2018 13:19:43 GMT

    In a0f04d6/rtems:

    bsp/gen5200: Move bestcomm to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 123
    1. Sebastian Huber, Mon, 23 Apr 2018 13:19:53 GMT

    In a62c75c1/rtems:

    bsp/tms570: Move more start to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 124
    1. Sebastian Huber, Mon, 23 Apr 2018 13:20:05 GMT

    In 3bd30f4/rtems:

    bsps/arm: Remove unused stm32f* files This patch is a part of the BSP source reorganization. Update #3285.
    Comment 125
    1. Sebastian Huber, Mon, 23 Apr 2018 13:20:16 GMT

    In a2dad96/rtems:

    bsps: Move I2C drivers to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 126
    1. Sebastian Huber, Mon, 23 Apr 2018 13:20:26 GMT

    In 276afd2b/rtems:

    bsps: Move SPI drivers to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 127
    1. Sebastian Huber, Mon, 23 Apr 2018 13:20:37 GMT

    In 8f8ccee/rtems:

    bsps: Move interrupt controller support to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 128
    1. Sebastian Huber, Mon, 23 Apr 2018 13:20:48 GMT

    In 031df391/rtems:

    bsps: Move legacy network drivers to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 129
    1. Sebastian Huber, Mon, 23 Apr 2018 13:20:59 GMT

    In 4fb1b79/rtems:

    bsps: Move RTC drivers to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 130
    1. Sebastian Huber, Mon, 23 Apr 2018 13:21:13 GMT

    In 142175ef/rtems:

    bsps/sparc64: Move helenos to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 131
    1. Sebastian Huber, Mon, 23 Apr 2018 13:21:27 GMT

    In 4ccbac63/rtems:

    bsps/v850: Move crt1.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 132
    1. Sebastian Huber, Mon, 23 Apr 2018 13:21:40 GMT

    In fd67814/rtems:

    bsps: Move GDB stubs to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 133
    1. Sebastian Huber, Mon, 23 Apr 2018 13:21:52 GMT

    In b4de37fd/rtems:

    bsps/sh: Move bsphwinit.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 134
    1. Sebastian Huber, Mon, 23 Apr 2018 13:22:03 GMT

    In e617455/rtems:

    bsps/sh: Move setvec.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 135
    1. Sebastian Huber, Mon, 23 Apr 2018 13:22:14 GMT

    In 6e1cf37/rtems:

    bsps/sh: Move console.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 136
    1. Sebastian Huber, Mon, 23 Apr 2018 13:22:24 GMT

    In 5a4e3dc0/rtems:

    bsps: Move PCI drivers to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 137
    1. Sebastian Huber, Mon, 23 Apr 2018 13:22:35 GMT

    In fc79b26/rtems:

    bsps: Move ATA drivers to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 138
    1. Sebastian Huber, Mon, 23 Apr 2018 13:22:45 GMT

    In 21978523/rtems:

    bsps/lm32: Move shared drivers to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 139
    1. Sebastian Huber, Tue, 24 Apr 2018 08:25:02 GMT

    In 56bd37bf/rtems:

    bsps: Remove unmaintained times files This patch is a part of the BSP source reorganization. Update #3285.
    Comment 140
    1. Sebastian Huber, Tue, 24 Apr 2018 08:25:12 GMT

    In c99e4f4e/rtems:

    bsps: Remove obsolete documentation This patch is a part of the BSP source reorganization. Update #3285.
    Comment 141
    1. Sebastian Huber, Tue, 24 Apr 2018 08:25:22 GMT

    In 65e59cc/rtems:

    bsps/arm: Move bsp_memory_management_initialize() This function is only used by the raspberrypi BSP. This patch is a part of the BSP source reorganization. Update #3285.
    Comment 142
    1. Sebastian Huber, Tue, 24 Apr 2018 08:25:33 GMT

    In 0180acf2/rtems:

    bsps/arm: Remove unused shared/comm/uart.c This patch is a part of the BSP source reorganization. Update #3285.
    Comment 143
    1. Sebastian Huber, Tue, 24 Apr 2018 08:25:43 GMT

    In 03e1d837/rtems:

    bsps/powerpc: Move bootloader to bsps This bootloader is only used by the motorola_powerpc BSP. This patch is a part of the BSP source reorganization. Update #3285.
    Comment 144
    1. Sebastian Huber, Tue, 24 Apr 2018 08:25:54 GMT

    In 2101f54/rtems:

    bsps: Move uboot_getenv.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 145
    1. Sebastian Huber, Tue, 24 Apr 2018 08:26:04 GMT

    In 670f104/rtems:

    bsps: Move uboot_dump_bdinfo.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 146
    1. Sebastian Huber, Tue, 24 Apr 2018 08:26:15 GMT

    In 1163f502/rtems:

    bsps: Move tictac.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 147
    1. Sebastian Huber, Tue, 24 Apr 2018 08:26:26 GMT

    In b8777d9/rtems:

    bsps: Move memcpy.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 148
    1. Sebastian Huber, Tue, 24 Apr 2018 08:26:36 GMT

    In 7091461/rtems:

    bsps: Move ppc-exc-handler-table.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 149
    1. Sebastian Huber, Tue, 24 Apr 2018 08:26:47 GMT

    In 1cc69e1/rtems:

    bsps: Move showbats.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 150
    1. Sebastian Huber, Tue, 24 Apr 2018 08:26:57 GMT

    In 173e157/rtems:

    bsps: Move residual.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 151
    1. Sebastian Huber, Tue, 24 Apr 2018 08:27:08 GMT

    In 499385e/rtems:

    bsps: Move motorola.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 152
    1. Sebastian Huber, Tue, 24 Apr 2018 08:27:18 GMT

    In afa90ee5/rtems:

    bsps: Move vpd.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 153
    1. Sebastian Huber, Tue, 24 Apr 2018 08:27:29 GMT

    In b5d4c80/rtems:

    bsps: Move flash.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 154
    1. Sebastian Huber, Tue, 24 Apr 2018 08:27:41 GMT

    In ff04935/rtems:

    bsps: Move intelFlash.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 155
    1. Sebastian Huber, Tue, 24 Apr 2018 08:27:53 GMT

    In fe077b3/rtems:

    bsps: Move spansionFlash.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 156
    1. Sebastian Huber, Tue, 24 Apr 2018 08:28:04 GMT

    In c7410f17/rtems:

    bsps/m68k: Remove unused files This patch is a part of the BSP source reorganization. Update #3285.
    Comment 157
    1. Sebastian Huber, Tue, 24 Apr 2018 08:28:16 GMT

    In 7a8e71b/rtems:

    bsps/i386: Move shared files to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 158
    1. Sebastian Huber, Tue, 24 Apr 2018 08:28:27 GMT

    In c3a44343/rtems:

    bsps: Move bspreset.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 159
    1. Sebastian Huber, Tue, 24 Apr 2018 08:28:38 GMT

    In d7a9eb90/rtems:

    bsps: Move armv7m-cpucounter.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 160
    1. Sebastian Huber, Tue, 24 Apr 2018 08:28:49 GMT

    In e2f63219/rtems:

    bsps: Move arm-a9mpcore-clock-config.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 161
    1. Sebastian Huber, Tue, 24 Apr 2018 08:28:59 GMT

    In 1ded97b9/rtems:

    bsps: Move arm-generic-timer-clock-config.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 162
    1. Sebastian Huber, Tue, 24 Apr 2018 08:29:10 GMT

    In bbedc47b/rtems:

    bsps: Move arm-pl111-fb.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 163
    1. Sebastian Huber, Tue, 24 Apr 2018 08:29:20 GMT

    In 3ad74cba/rtems:

    bsps: Move arm-pl011.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 164
    1. Sebastian Huber, Tue, 24 Apr 2018 08:29:31 GMT

    In fc6d8c2/rtems:

    bsps: Move arm-pl050.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 165
    1. Sebastian Huber, Tue, 24 Apr 2018 08:29:41 GMT

    In 864e72e/rtems:

    bsps: Move arm-a9mpcore-smp.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 166
    1. Sebastian Huber, Tue, 24 Apr 2018 08:29:52 GMT

    In aa705fe/rtems:

    bsps: Move arm-cp15-set-exception-handler.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 167
    1. Sebastian Huber, Tue, 24 Apr 2018 08:30:02 GMT

    In 891754f7/rtems:

    bsps: Move arm-cp15-set-ttb-entries.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 168
    1. Sebastian Huber, Wed, 25 Apr 2018 12:32:10 GMT

    In b07da56e/rtems:

    bsp/gensh4: Move hw_init.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 169
    1. Sebastian Huber, Wed, 25 Apr 2018 12:32:21 GMT

    In 8bf101c/rtems:

    bsp/virtex4: Move mmu.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 170
    1. Sebastian Huber, Wed, 25 Apr 2018 12:32:32 GMT

    In 25787041/rtems:

    bsp/virtex5: Move mmu.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 171
    1. Sebastian Huber, Wed, 25 Apr 2018 12:32:43 GMT

    In 8f12ee32/rtems:

    bsp/mvme5500: Move source files to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 172
    1. Sebastian Huber, Wed, 25 Apr 2018 12:32:54 GMT

    In bf16ee5/rtems:

    bsp/mvme3100: Move flashcfg.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 173
    1. Sebastian Huber, Wed, 25 Apr 2018 12:33:05 GMT

    In 8266fb5/rtems:

    bsp/beatnik: Move source files to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 174
    1. Sebastian Huber, Wed, 25 Apr 2018 12:33:16 GMT

    In 95d5426c/rtems:

    bsp/haleakala: Move mmu_405.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 175
    1. Sebastian Huber, Wed, 25 Apr 2018 12:33:27 GMT

    In 64d4fc7/rtems:

    bsp/gen5200: Move source files to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 176
    1. Sebastian Huber, Wed, 25 Apr 2018 12:33:38 GMT

    In 100c972/rtems:

    bsp/mrm332: Move spinit.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 177
    1. Sebastian Huber, Wed, 25 Apr 2018 12:33:50 GMT

    In 0e15ba3/rtems:

    bsp/mrm332: Move interr.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 178
    1. Sebastian Huber, Wed, 25 Apr 2018 12:34:03 GMT

    In a79d650/rtems:

    bsp/mcf5206elite: Move nvram.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 179
    1. Sebastian Huber, Wed, 25 Apr 2018 12:34:16 GMT

    In 4183b711/rtems:

    bsp/tms570: Move cpucounterread.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 180
    1. Sebastian Huber, Wed, 25 Apr 2018 12:34:29 GMT

    In ede0eb3/rtems:

    bsp/smdk2410: Move smc.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 181
    1. Sebastian Huber, Wed, 25 Apr 2018 12:34:43 GMT

    In fc1bdb83/rtems:

    bsp/raspberrypi: Move source files to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 182
    1. Sebastian Huber, Wed, 25 Apr 2018 12:34:54 GMT

    In 43250167/rtems:

    bsp/lpc32xx: Move source files to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 183
    1. Sebastian Huber, Wed, 25 Apr 2018 12:35:06 GMT

    In 74df15c/rtems:

    bsp/lpc24xx: Move source files to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 184
    1. Sebastian Huber, Wed, 25 Apr 2018 12:35:18 GMT

    In e945b049/rtems:

    bsp/lpc176x: Move source files to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 185
    1. Sebastian Huber, Wed, 25 Apr 2018 12:35:29 GMT

    In 82bfda92/rtems:

    bsp/lm3s69xx: Move ssi.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 186
    1. Sebastian Huber, Wed, 25 Apr 2018 12:35:40 GMT

    In 720ebc0/rtems:

    bsp/gumstix: Move fb.c to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 187
    1. Sebastian Huber, Wed, 25 Apr 2018 12:35:51 GMT

    In 531d160/rtems:

    bsp/beagle: Move source files to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 188
    1. Sebastian Huber, Wed, 25 Apr 2018 12:36:02 GMT

    In f7eaf316/rtems:

    bsps: Remove unused u-boot-generic-board-info.h This patch is a part of the BSP source reorganization. Update #3285.
    Comment 189
    1. Sebastian Huber, Wed, 25 Apr 2018 12:36:13 GMT

    In 1913eb16/rtems:

    bsps/arm: Remove unused files This patch is a part of the BSP source reorganization. Update #3285.
    Comment 190
    1. Sebastian Huber, Wed, 25 Apr 2018 13:28:56 GMT
    2. milestone: changed from 6.1 to 5.1
    Comment 191
    1. Sebastian Huber, Thu, 26 Apr 2018 05:18:30 GMT

    In 0b60c54/rtems:

    bsp/haleakala: Move assembler files to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 192
    1. Sebastian Huber, Thu, 26 Apr 2018 05:18:40 GMT

    In b80be135/rtems:

    bsp/psim: Move align_h.S to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 193
    1. Sebastian Huber, Thu, 26 Apr 2018 05:18:51 GMT

    In 3460c522/rtems:

    bsps/powerpc: Move bsp-start-zero.S to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 194
    1. Sebastian Huber, Thu, 26 Apr 2018 05:19:02 GMT

    In a5bf9b6/rtems:

    bsps/mips: Move liblnk to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 195
    1. Sebastian Huber, Thu, 26 Apr 2018 05:19:12 GMT

    In 1554415/rtems:

    bsp/sparc64: Move asm.S to bsps and rename This patch is a part of the BSP source reorganization. Update #3285.
    Comment 196
    1. Sebastian Huber, Thu, 26 Apr 2018 05:19:23 GMT

    In 8eb264d3/rtems:

    bsps: Remove unmaintained times files This patch is a part of the BSP source reorganization. Update #3285.
    Comment 197
    1. Sebastian Huber, Thu, 26 Apr 2018 05:19:35 GMT

    In eb36d11/rtems:

    bsps: Move documentation, etc. files to bsps This patch is a part of the BSP source reorganization. Update #3285.
    Comment 198
    1. Sebastian Huber, Fri, 27 Apr 2018 10:50:26 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In cb0f55a/rtems-docs:

    Update due to BSP source reorganization This patch is a part of the BSP source reorganization. Close #3285.
    Comment 199
    1. Sebastian Huber, Fri, 03 Aug 2018 12:15:34 GMT

    In 32ccc01/rtems:

    bsps: Fix the generic IRQ support The genmcf548x partly uses is own implementation of the interrupt extension API for libbsd support. This patch is a part of the BSP source reorganization. Update #3285.

    3290 - Add device tree support to Altera/Intel Cyclone V BSP

    Link https://devel.rtems.org/ticket/3290
    Id 3290
    Reporter Sebastian Huber
    Created 5 February 2018 12:54:38
    Modified 6 February 2018 09:03:13
    Owner Sebastian Huber
    Type enhancement
    Component arch/arm
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Mon, 05 Feb 2018 12:55:45 GMT

    In 3454179/rtems:

    bsp/altera-cyclone-v: Add device tree support Update #3290.
    Comment 2
    1. Sebastian Huber, Tue, 06 Feb 2018 09:03:13 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In c30fa94/rtems-libbsd:

    Add device tree support for Altera/Intel? Cyclone V Close #3290.

    3294 - gcc version report for released tools is wrong.

    Link https://devel.rtems.org/ticket/3294
    Id 3294
    Reporter Chris Johns
    Created 7 February 2018 04:25:48
    Modified 7 February 2018 21:48:28
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The release gcc version string has the RTEMS release and not the actual release.

    Comment 1
    1. Chris Johns, Wed, 07 Feb 2018 21:48:28 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 858b648/rtems-source-builder:

    gcc: Use the RSB release for released tools. Using the RSB release version for the gcc version string means the tools have a version string that matches the release. Close #3294

    3298 - dlerror non-conformance

    Link https://devel.rtems.org/ticket/3298
    Id 3298
    Reporter Chris Johns
    Created 8 February 2018 03:37:08
    Modified 8 February 2019 23:08:07
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by 2747

    Description

    This is a port of the 4.11 patches from #2747 to master. Please refer to that ticket for details.

    Comment 1
    1. Chris Johns, Fri, 08 Feb 2019 23:08:07 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In e2f13430/rtems:

    libdl: Fix dlerror non-conformance Closes #3298

    3305 - Add paravirtualization support to ARM

    Link https://devel.rtems.org/ticket/3305
    Id 3305
    Reporter Joel Sherrill
    Created 16 February 2018 17:15:35
    Modified 13 March 2018 15:15:20
    Owner Joel Sherrill
    Type enhancement
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The Arm port does not currently have paravirtualization support.

    Comment 1
    1. Joel Sherrill, Fri, 16 Feb 2018 17:15:56 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Tue, 13 Mar 2018 15:15:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    ​https://git.rtems.org/rtems/commit/?id=c0443b4ce943fa891839c7b7be21d8ebd4370de1


    3306 - Add paravirtualization support to PowerPC

    Link https://devel.rtems.org/ticket/3306
    Id 3306
    Reporter Joel Sherrill
    Created 16 February 2018 17:17:37
    Modified 13 March 2018 15:01:44
    Owner Joel Sherrill <joel@…>
    Type enhancement
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The PowerPC port does not currently have paravirtualization support.

    Comment 1
    1. Joel Sherrill, Tue, 13 Mar 2018 15:01:44 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 0a7a30d/rtems:

    Add PowerPC paravirtualization support Cannot read or write MSR when executing in user mode. This is used when RTEMS_PARAVIRT is defined. Provide alternate methods to disable/enable interrupts Closes #3306.

    3307 - PowerPC linkcmds.base missing wildcards on some sections

    Link https://devel.rtems.org/ticket/3307
    Id 3307
    Reporter Joel Sherrill
    Created 16 February 2018 17:21:14
    Modified 17 September 2018 11:47:40
    Owner Joel Sherrill
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Some sections were missing sections. Wildcards needed to be added.

    Comment 1
    1. Joel Sherrill, Fri, 16 Feb 2018 17:21:29 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Mon, 19 Feb 2018 19:12:21 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 40c623a8/rtems:

    powerpc/shared/startup/linkcmds.base: Add wildcards on some sections Closes #3307.
    Comment 3
    1. Sebastian Huber, Wed, 07 Mar 2018 09:48:06 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    I reverted [40c623a8/rtems] and built the qoriq_e6500_32 with the -fPIC option. I got no linker failures in the test suite.

    We should investigate what sections are not recognized before we add dangerous *.x wildcards.

    See also [1fcdd639ee38a990e629fdaa670eeda9faae9beb/rtems].

    Comment 4
    1. Sebastian Huber, Fri, 18 May 2018 08:45:56 GMT

    In 7bf072b/rtems:

    bsp/powerpc: Remove wildcards in linkcmds.base This reverts commit 40c623a883da5dd80e4599cf4cd14097834706bd. The use of postfix wildcards, e.g. of the form "*.x" is dangerous since it circumvents the standard matching rules for sections. Unknown input sections should be added explicitly to the desired output section via "x.*" wildcards. Update #3307.
    Comment 5
    1. Sebastian Huber, Mon, 17 Sep 2018 11:47:24 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    Is probably fixed.


    3309 - rtems_task_create's initial_mode SMP update

    Link https://devel.rtems.org/ticket/3309
    Id 3309
    Reporter Chris Johns
    Created 21 February 2018 02:26:07
    Modified 14 October 2018 01:11:23
    Owner  
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The initial_mode cannot have the non-preempt flag or an interrupt level set or an RTEMS_UNSATISFIED error is returned. This is not documented in the directive.

    Comment 1
    1. Chris Johns, Sun, 14 Oct 2018 01:11:23 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    3312 - RSB macro calls such as define fail on unicode keys.

    Link https://devel.rtems.org/ticket/3312
    Id 3312
    Reporter Chris Johns
    Created 23 February 2018 00:34:09
    Modified 25 February 2018 21:33:37
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3313
    Blocked by  

    Description

    The define call in macros.py checks for a str while the __setitem__ call can convert a unicode string to str. Remove the check.

    Remove the other places in macros.py a key str check is made and see if they can be improved.

    The following has been reported to me:

    cd rtems-source-builder-4.11.3/rtems
    ../source-builder/sb-set-builder --prefix=/home/user/rtems/4.11 --log=arm.txt --without-rtems 4.11/rtems-arm
    Traceback (most recent call last):
    File "../source-builder/sb-set-builder", line 29, in
    setbuilder.run()
    File "../source-builder/sb/setbuilder.py", line 526, in run
    opts = options.load(sys.argv, optargs)
    File "../source-builder/sb/options.py", line 668, in load
    version.load_release_settings(o.defaults)
    File "../source-builder/sb/version.py", line 123, in load_release_settings
    sources.hash((hs[0], hash[0], hs[1]), macros, setting_error)
    File "../source-builder/sb/sources.py", line 105, in hash
    macros.define(_file, '%s %s' % (args[0], args[2]))
    File "../source-builder/sb/macros.py", line 439, in define
    raise TypeError('bad key type: %s' % (type(key)))
    TypeError: bad key type:
    Comment 1
    1. Chris Johns, Fri, 23 Feb 2018 01:27:27 GMT
    2. blocking: set to 3313
    Comment 2
    1. Chris Johns, Sun, 25 Feb 2018 21:33:37 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d255e81/rtems-source-builder:

    sb: Convert any unicode keys to strings Closes #3312

    3315 - Move expat's home site to github from SF.

    Link https://devel.rtems.org/ticket/3315
    Id 3315
    Reporter Chris Johns
    Created 2 March 2018 00:21:26
    Modified 4 March 2018 21:31:03
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity critical
    Keywords  
    Cc  
    Blocking 3316, 3317
    Blocked by  

    Description

    Move expat's home site from SF to github:

    ​https://libexpat.github.io/

    Comment 1
    1. Chris Johns, Fri, 02 Mar 2018 00:23:24 GMT
    2. blocking: set to 3316
    Comment 2
    1. Chris Johns, Fri, 02 Mar 2018 00:24:24 GMT
    2. blocking: changed from 3316 to 3316, 3317
    Comment 3
    1. Chris Johns, Sun, 04 Mar 2018 21:31:03 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 4b3e0f8/rtems-source-builder:

    The libexpat project has moved to github. Fetch expat from github. Close #3315

    3318 - Improve INTERNAL_ERROR_THREAD_EXITTED to show the id and thread name

    Link https://devel.rtems.org/ticket/3318
    Id 3318
    Reporter Matthew J Fletcher
    Created 2 March 2018 10:12:31
    Modified 8 March 2018 05:56:53
    Owner Sebastian Huber
    Type enhancement
    Component bsps
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority low
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    It might be more helpful i the case of a thread exit to output some information about that thread to make tracking it down simpler.

    This example works ok.

    static void thread_exitted_print_info(rtems_tcb *tcb)
    {

    printf("Thread exited: %s (id %d)\n", tcb->Object.name, tcb->Object.id)

    }

    /* In your configuration: */
    #define CONFIGURE_INITIAL_EXTENSIONS \

    { .thread_exitted = thread_exitted_print_info }

    Comment 1
    1. Sebastian Huber, Wed, 07 Mar 2018 06:50:44 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to accepted
    4. version: set to 5
    5. component: changed from rtems to bsps
    6. milestone: set to 5.1
    Comment 2
    1. Sebastian Huber, Thu, 08 Mar 2018 05:56:53 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In d39cc068/rtems:

    bsps: More verbose bsp_fatal_extension() Close #3318.

    3320 - Add a simple task console driver

    Link https://devel.rtems.org/ticket/3320
    Id 3320
    Reporter Sebastian Huber
    Created 6 March 2018 07:07:36
    Modified 29 June 2018 09:53:37
    Owner Sebastian Huber <sebastian.huber@…>
    Type enhancement
    Component dev/serial
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The default console driver for tests is the simple console driver. It uses a polled output via rtems_putc() done directly in the context of the executing thread. This is a problem for timing sensitive tests. Add a simple task console driver.

    .. index:: CONFIGURE_APPLICATION_NEEDS_SIMPLE_TASK_CONSOLE_DRIVER
    .. _CONFIGURE_APPLICATION_NEEDS_SIMPLE_TASK_CONSOLE_DRIVER:
    CONFIGURE_APPLICATION_NEEDS_SIMPLE_TASK_CONSOLE_DRIVER
    ------------------------------------------------------
    CONSTANT:
    ``CONFIGURE_APPLICATION_NEEDS_SIMPLE_TASK_CONSOLE_DRIVER``
    DATA TYPE:
    Boolean feature macro.
    RANGE:
    Defined or undefined.
    DEFAULT VALUE:
    This is not defined by default.
    DESCRIPTION:
    ``CONFIGURE_APPLICATION_NEEDS_SIMPLE_TASK_CONSOLE_DRIVER`` is defined if
    the application wishes to include the Simple Task Console Device Driver.
    NOTES:
    This device driver is responsible for providing the :file:`/dev/console`
    device file. This device is used to initialize the standard input, output,
    and error file descriptors.
    This device driver reads via ``getchark()``.
    This device driver writes into a write buffer. The count of characters
    written into the write buffer is returned. It might be less than the
    requested count, in case the write buffer is full. The write is
    non-blocking and may be called from interrupt context. A dedicated task
    reads from the write buffer and outputs the characters via
    ``rtems_putc()``. This task runs with the least important priority. The
    write buffer size is 2047 characters and it is not configurable.
    Use ``fsync(STDOUT_FILENO)`` or ``fdatasync(STDOUT_FILENO)`` to drain the
    write buffer.
    The Termios framework is not used. There is no support to change device
    settings, e.g. baud, stop bits, parity, etc.
    The
    * ``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER``,
    * ``CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER``, and
    * ``CONFIGURE_APPLICATION_NEEDS_SIMPLE_TASK_CONSOLE_DRIVER``
    configuration options are mutually exclusive.
    Comment 1
    1. Sebastian Huber, Tue, 06 Mar 2018 10:46:54 GMT

    In f6c6c8b/rtems-docs:

    CONFIGURE_*_SIMPLE_TASK_CONSOLE_DRIVER Update #3320.
    Comment 2
    1. Sebastian Huber, Tue, 06 Mar 2018 11:32:27 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 337a186/rtems:

    Add a simple task console driver Close #3320.
    Comment 3
    1. Sebastian Huber, Fri, 29 Jun 2018 09:53:37 GMT

    In 196ce18/rtems:

    console: Add missing return status Update #3320.

    3323 - mhttpd's http etag can result in invalid caching in a browser.

    Link https://devel.rtems.org/ticket/3323
    Id 3323
    Reporter Chris Johns
    Created 8 March 2018 04:11:03
    Modified 11 April 2018 02:47:25
    Owner Chris Johns
    Type defect
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3324
    Blocked by  

    Description

    The mhttp's http etag uses the mtime and file length and this can cause subtle issues if a target has no RTC or it is incorrect and files are being copied without preserving the mtime or changes happen that do not change the length.

    The cp and untar code do not update a file's time.

    Add support for an etag callback so a user can manage the tag, ie MD5 or something similar.

    Comment 1
    1. Chris Johns, Thu, 08 Mar 2018 04:12:12 GMT
    2. blocking: set to 3324
    Comment 2
    1. Chris Johns, Wed, 11 Apr 2018 02:47:25 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d13a624/rtems:

    cpukit/mttpd: Add a callback to generate a per file HTTP etag Close #3323.

    3325 - Simplify clustered scheduler configuration

    Link https://devel.rtems.org/ticket/3325
    Id 3325
    Reporter Sebastian Huber
    Created 8 March 2018 06:02:28
    Modified 12 March 2018 06:14:56
    Owner Sebastian Huber
    Type enhancement
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Improve the scheduler configuration documentation according to user review.

    Do not use names derived from scheduler implementation details. Instead
    use names derived from the scheduler configuration or documentation.
    Provide defines for backward compatibility.

    Comment 1
    1. Sebastian Huber, Thu, 08 Mar 2018 06:47:33 GMT

    In bf78123/rtems-docs:

    c-user: Rework scheduler alogrithm config defs Update #3325.
    Comment 2
    1. Sebastian Huber, Thu, 08 Mar 2018 07:05:33 GMT

    In 0231ebc/rtems:

    config: Remove RTEMS prefix from internal defines Update #3325.
    Comment 3
    1. Sebastian Huber, Mon, 12 Mar 2018 06:02:46 GMT

    In 2ef85b1/rtems:

    config: Simplify clustered scheduler configuration Do not use names derived from scheduler implementation details. Instead use names derived from the scheduler configuration or documentation. Provide defines for backward compatibility. Update #3325.
    Comment 4
    1. Sebastian Huber, Mon, 12 Mar 2018 06:02:56 GMT

    In 6fadb7a/rtems:

    config: Use new scheduler configuration defines Update #3325.
    Comment 5
    1. Sebastian Huber, Mon, 12 Mar 2018 06:14:56 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 154fb0f9/rtems-docs:

    c-user: Simplify clustered scheduler configuration Close #3325.

    3327 - Eliminate score/cpu/&#42/.../types.h

    Link https://devel.rtems.org/ticket/3327
    Id 3327
    Reporter Joel Sherrill
    Created 8 March 2018 17:22:23
    Modified 21 March 2018 06:51:40
    Owner  
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Each port contains a types.h file. It universally defines one type (CPU_Uint32ptr) that is required. Some of the types.h files define a CPU specific simple vectored ISR handler prototype.

    • Move the CPU_Uint32ptr typedef to cpu.h
    • If unused, delete the ISR handler prototype. If used, move to cpu.h
    Comment 1
    1. Joel Sherrill, Mon, 12 Mar 2018 19:30:07 GMT

    In c2282d6d/rtems:

    sparc/include/rtems/score/types.h: Eliminate this file Updates #3327.
    Comment 2
    1. Sebastian Huber, Wed, 21 Mar 2018 06:51:40 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    3328 - bootstrap uses non-POSIX compliant echo -e

    Link https://devel.rtems.org/ticket/3328
    Id 3328
    Reporter Amaan Cheval
    Created 9 March 2018 16:59:21
    Modified 9 March 2018 19:26:18
    Owner  
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc Joel Sherrill
    Blocking  
    Blocked by  

    Description

    On certain shells, the "-e" option is not supported, and causes echo to output the flag along with the quoted text.

     -> % sh
    $ echo -e "foo bar"
    -e foo bar
    $

    This varies by shell, and is not even consistent between sh or bash.

    It was introduced ​while removing the make preinstall stage here, and may still work on most shells, though it didn't for me on sh on Ubuntu 16.04 LTS (4.4.0-78-generic x86_64 GNU/Linux) - as far as I can tell, this bug hasn't made it to any releases yet, so just fixing it on master should be enough.

    A patch is attached.

    Reference to the POSIX standard which confirms that -n is the only argument supported.

    ​http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html

    Link to POSIX for printf(1):

    ​http://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html

    Attachments:

    1 Amaan Cheval, Fri, 09 Mar 2018 17:00:08 GMT
      attach: set to 0001-bootstrap-Use-printf-instead-of-echo-e-for-POSIX-she.patch
     
    Comment 1
    1. Joel Sherrill, Fri, 09 Mar 2018 19:10:16 GMT
    2. description: modified (diff)
    Comment 2
    1. Joel Sherrill, Fri, 09 Mar 2018 19:26:18 GMT
    2. status: changed from new to closed
    3. version: set to 5
    4. resolution: set to fixed
    5. milestone: set to 5.1

    This didn't close automatically on the commit.

    ​http://git.rtems.org/rtems/commit/?id=4dfeba3a0e53d4b697b07f9c10783c411e43ccdf


    3329 - Trac Login Failure (bad password) Causes Internal Error

    Link https://devel.rtems.org/ticket/3329
    Id 3329
    Reporter Joel Sherrill
    Created 9 March 2018 19:14:46
    Modified 20 October 2018 16:08:31
    Owner Amar Takhar
    Type infra
    Component tool/website
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Behavior is as expected with a bad user name.

    Try to login to Trac with a bad password:

    Oops…
    Trac detected an internal error: ProgrammingError?: (1064, "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'sid='joel.sherrill' AND authenticated=1 AND name='failed_logins_count__ at line 1")
    There was an internal error in Trac. It is recommended that you notify your local Trac administrator with the information needed to reproduce the issue.
    To that end, you could anonymous ProgrammingError?: (1064, "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'sid='joel.sherrill' AND authenticated=1 AND name='failed_logins_count__ at line 1") ==== How to Reproduce ====

    While doing a POST operation on /login, Trac issued an internal error.

    __(please provide additional details here)__

    Request parameters:

    {u'__FORM_TOKEN': u'0dc25ae350c181046ceae015',
    u'password': u'XXX',
    u'referer': u'https://devel.rtems.org/ticket/3328',
    'user_locked': False,
    u'username': u'joel.sherrill'}

    User agent: Mozilla/5.0 (X11; Linux x86_64) KHTML/4.14.8 (like Gecko) Konqueror/4.14 Fedora/4.14.8-6.el7_3

    System Information

    __System information not available__

    Enabled Plugins

    __Plugin information not available__

    Interface Customization

    __Interface customization information not available__

    Python Traceback
    Traceback (most recent call last):
    File "/data/src/trac/trac/web/main.py", line 620, in _dispatch_request
    dispatcher.dispatch(req)
    File "/data/src/trac/trac/web/main.py", line 220, in dispatch
    chosen_handler = self._pre_process_request(req, chosen_handler)
    File "/data/src/trac/trac/web/main.py", line 429, in _pre_process_request
    chosen_handler = filter_.pre_process_request(req, chosen_handler)
    File "/data/trac/plugins/TracAccountManager-0.5.dev0-py2.7.egg/acct_mgr/api.py", line 478, in pre_process_request
    if not req.session.authenticated or \
    File "/data/src/trac/trac/web/api.py", line 491, in __getattr__
    value = self.callbacks[name](self)
    File "/data/src/trac/trac/web/main.py", line 354, in _get_session
    return Session(self.env, req)
    File "/data/src/trac/trac/web/session.py", line 243, in __init__
    if req.authname == 'anonymous':
    File "/data/src/trac/trac/web/api.py", line 491, in __getattr__
    value = self.callbacks[name](self)
    File "/data/src/trac/trac/web/main.py", line 172, in authenticate
    authname = authenticator.authenticate(req)
    File "/data/trac/plugins/TracAccountManager-0.5.dev0-py2.7.egg/acct_mgr/util.py", line 81, in wrap
    return func(self, *args, **kwds)
    File "/data/trac/plugins/TracAccountManager-0.5.dev0-py2.7.egg/acct_mgr/web_ui.py", line 395, in authenticate
    guard.failed_count(f_user, req.remote_addr)
    File "/data/trac/plugins/TracAccountManager-0.5.dev0-py2.7.egg/acct_mgr/guard.py", line 107, in failed_count
    set_user_attribute(self.env, user, key, count)
    File "/data/trac/plugins/TracAccountManager-0.5.dev0-py2.7.egg/acct_mgr/model.py", line 509, in set_user_attribute
    (value, username, attribute))
    File "/data/src/trac/trac/db/util.py", line 128, in execute
    cursor.execute(query, params if params is not None else [])
    File "/data/src/trac/trac/db/util.py", line 72, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
    File "/usr/local/lib/python2.7/site-packages/MySQLdb/cursors.py", line 205, in execute
    self.errorhandler(self, exc, value)
    File "/usr/local/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
    raise errorclass, errorvalue
    ProgrammingError: (1064, "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'sid='joel.sherrill' AND authenticated=1 AND name='failed_logins_count'' at line 1")
    ` Create a ticket.
    The action that triggered the error was:
    POST: /login
    TracGuide — The Trac User and Administration Guide
    Comment 1
    1. Amar Takhar, Fri, 09 Mar 2018 22:40:22 GMT
    2. owner: set to Amar Takhar
    3. status: changed from new to accepted
    4. type: changed from defect to infra

    Sigh this is a part of why upgrading trac is so annoying anytime I fix something another part breaks I really need to redo the entire system.

    Thanks for the report I've put it on the list since it's not critical I'm not worried about it.

    Comment 2
    1. Amar Takhar, Sat, 20 Oct 2018 16:08:31 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed
    4. milestone: set to 5.1

    I upgraded TracAccountManager? this should no longer happen.


    3334 - deadlock in _once()

    Link https://devel.rtems.org/ticket/3334
    Id 3334
    Reporter Stavros Passas
    Created 13 March 2018 13:17:56
    Modified 18 February 2019 07:34:12
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    RTEMS threads getting locked up when using certain c++ functionality.
    Issue happens for example when std::future is combined with std::async.

    Investigating deeper, seems like this happens if std::async executes before std::future gets scheduled to run. Both of these create a pthread_once instance.

    _once() uses a common semaphore for all calls, thus the first function (async.get usually) gets the lock, calls its “init” function (which blocks until the second function has completed. After this, std::future also uses pthread_once to execute, but because the lock is already taken, it also blocks, casing a deadlock.

    Attached you can find a test application that reproduces the deadlock.

    Attachments:

    1 Stavros Passas, Tue, 13 Mar 2018 13:19:22 GMT
      attach: set to Add-test-executing-interlocking-pthread_once.patch
     
    2 Stavros Passas, Tue, 13 Mar 2018 13:28:56 GMT
      attach: set to 3334-Fix-pthread_once-deadlock.patch
     
    Comment 1
    1. Stavros Passas, Tue, 13 Mar 2018 13:22:26 GMT

    Copying the suggestion from Sebastian, (from the mailing list) about this issue:

    "Please open a ticket and provide a test case for the RTEMS test suite. Maybe we have to use dedicated mutexes for each pthread_once_t object. This is what Linux and FreeBSD do. This would require a Newlib update."

    Comment 2
    1. Stavros Passas, Tue, 13 Mar 2018 13:34:02 GMT

    I agree with Sebastian, that using one dedicated mutex for each pthread_once_t instance would be a longer term and elegant solution, but it would also add overhead for each pthread_t instance.

    I am adding a different proposed solution, which doesn't require newlib changes (and increasing the pthread_t size):

    The _once implementation uses a single mutex. Currently this mutex protects the whole function, while I believe we need to protect reads/writes to the once_state variable only. Concurrent tasks finding the state on RUNNING, could just yield until the state becomes ONCE_STATE_COMPLETE.

    Comment 3
    1. Sebastian Huber, Tue, 13 Mar 2018 14:12:26 GMT
    2. milestone: changed from 4.11.4 to 5.1

    Please send patches to the mailing list.

    The yield loop may fail if thread priorities come into play. It should be replaced with a condition variable. So, for the once implementation we need a mutex and a condition variable (#include ). There is currently no condition variable with API mutex support. We need protection from asynchronous deletion. Maybe use _Thread_Set_life_protection() directly in _Once().

    If we want to back port this fix to RTEMS 4.11, then we have to use instead of .

    Comment 4
    1. Chris Johns, Sun, 14 Oct 2018 01:12:03 GMT

    What is happening with this ticket?

    Comment 5
    1. Chris Johns, Sun, 14 Oct 2018 01:13:12 GMT
    2. version: changed from 4.11 to 5
    Comment 6
    1. Chris Johns, Sun, 14 Oct 2018 20:27:03 GMT
    2. status: changed from new to assigned
    3. version: changed from 5 to 6
    4. milestone: changed from 5.1 to Indefinite
    Comment 7
    1. Sebastian Huber, Mon, 15 Oct 2018 05:05:17 GMT
    2. owner: set to Sebastian Huber
    Comment 8
    1. Sebastian Huber, Tue, 12 Feb 2019 12:20:52 GMT
    2. status: changed from assigned to accepted
    3. version: changed from 6 to 5
    4. milestone: changed from Indefinite to 5.1
    Comment 9
    1. Sebastian Huber, Mon, 18 Feb 2019 06:26:41 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In e4ad14cc/rtems:

    score: Avoid some deadlocks in _Once() Recursive usage of the same pthread_once_t results now in a deadlock. Previously, an error of EINVAL was returned. This usage scenario is invalid according to the POSIX pthread_once() specification. Close #3334.
    Comment 10
    1. Sebastian Huber, Mon, 18 Feb 2019 07:34:12 GMT

    In 3d65f45/rtems:

    psxtests/psxonce01: Fix typo Update #3334.

    3339 - Several PowerPC linker commands do not support constructors/destructors with priority

    Link https://devel.rtems.org/ticket/3339
    Id 3339
    Reporter Joel Sherrill
    Created 14 March 2018 18:45:58
    Modified 20 December 2019 06:17:26
    Owner Sebastian Huber <sebastian.huber@…>
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This BSP shouldn't have trouble linking any of the tests so I was surprised at this failure.

    gmake[6]: Entering directory `/data/home/joel/rtems-work/rtems-testing/rtems/build-powerpc-qemuppc-rtems/powerpc-rtems5/c/qemuppc/testsuites/sptests/spglobalcon02'
    powerpc-rtems5-gcc -mcpu=603e -Dppc603e -O2 -g -fno-keep-inline-functions -mcpu=603e -Dppc603e -B/home/joel/rtems-work/rtems-testing/rtems/build-powerpc-qemuppc-rtems/powerpc-rtems5/c/qemuppc/lib/libbsp/powerpc/qemuppc -B/home/joel/rtems-work/rtems-testing/rtems/rtems/c/src/lib/libbsp/powerpc/qemuppc/startup/ -specs bsp_specs -qrtems -L../../../../../qemuppc/lib -L/home/joel/rtems-work/rtems-testing/rtems/rtems/c/src/lib/libbsp/powerpc/shared/startup -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -o spglobalcon02.exe init.o
    /data/home/joel/rtems-work/tools/5/bin/../lib/gcc/powerpc-rtems5/7.3.0/../../../../powerpc-rtems5/bin/ld: section .ctors.64535 LMA [00000000ffc19780,00000000ffc19783] overlaps section .sdata LMA [00000000ffc19780,00000000ffc19807]
    collect2: error: ld returned 1 exit status
    gmake[6]: __* [spglobalcon02.exe] Error 1
    gmake[6]: Leaving directory `/data/home/joel/rtems-work/rtems-testing/rtems/build-powerpc-qemuppc-rtems/powerpc-rtems5/c/qemuppc/testsuites/sptests/spglobalcon02'
    gmake[5]: __* [spglobalcon02] Error 2

    Comment 1
    1. Sebastian Huber, Fri, 16 Mar 2018 14:12:46 GMT

    In 9860cc7/rtems:

    bsps/powerpc: Fix linker command files Update #3339.
    Comment 2
    1. Sebastian Huber, Fri, 16 Mar 2018 14:12:56 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 2e5cf7f/rtems:

    bsps/powerpc: Use shared linker command file Close #3339.
    Comment 3
    1. Sebastian Huber, Sat, 17 Mar 2018 10:08:19 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted
    4. summary: changed from qemuppc fails to link spglobalcon02 to Several PowerPC linker commands do not support constructors/destructors with priority
    Comment 4
    1. Sebastian Huber, Mon, 26 Mar 2018 09:12:25 GMT

    In 1048a165/rtems:

    bsp/tqm8xx: Use shared linker command file Update #3339.
    Comment 5
    1. Sebastian Huber, Wed, 25 Apr 2018 18:36:17 GMT

    In b3e5aa5/rtems:

    bsp/qemuppc: Install linkcmds.base Update #3339. Close #3411.
    Comment 6
    1. Sebastian Huber, Tue, 07 May 2019 08:32:35 GMT

    In 30d61a6/rtems:

    bsps/powerpc: Fix constructors with priority Update #3339.
    Comment 7
    1. Sebastian Huber, Fri, 20 Dec 2019 06:17:26 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    In 86abbb6e/rtems:

    bsps/powerpc: Support constructors with priority Close #3339.

    3340 - gen83xx warning for macros redefined

    Link https://devel.rtems.org/ticket/3340
    Id 3340
    Reporter Joel Sherrill
    Created 14 March 2018 21:06:00
    Modified 16 March 2018 13:24:45
    Owner Sebastian Huber
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    log/powerpc-hsc_cm01.log:/home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/powerpc/gen83xx/include/bsp/hwreg_vals.h:244:0: warning: "FPGA_START" redefined
    log/powerpc-hsc_cm01.log:/home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/powerpc/gen83xx/include/bsp/hwreg_vals.h:246:0: warning: "FPGA_SIZE" redefined

    Looking at the code, it is pretty clear that the macros are redefined. Unfortunately one of the three has a different value the second time:

    ========================================
    /* fpga BCSR register */
    #define FPGA_START 0xF8000000
    #define FPGA_SIZE 0x8000
    #define FPGA_END (FPGA_START+FPGA_SIZE-1)

    /*

    • working values for various registers, used in start/start.S
      */

    /* fpga config 16 MB size */
    #define FPGA_CONFIG_START 0xF8000000
    #define FPGA_CONFIG_SIZE 0x01000000
    /* fpga register 8 MB size */
    #define FPGA_REGISTER_START 0xF9000000
    #define FPGA_REGISTER_SIZE 0x00800000
    /* fpga fifo 8 MB size */
    #define FPGA_FIFO_START 0xF9800000
    #define FPGA_FIFO_SIZE 0x00800000

    #define FPGA_START (FPGA_CONFIG_START) __ fpga window size 32 MByte
    #define FPGA_SIZE (0x02000000)
    #define FPGA_END (FPGA_START+FPGA_SIZE-1) __

    ========================================

    Comment 1
    1. Joel Sherrill, Wed, 14 Mar 2018 21:06:25 GMT
    2. owner: changed from sebastian to Sebastian Huber
    Comment 2
    1. Sebastian Huber, Fri, 16 Mar 2018 13:24:45 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 9b61342/rtems:

    bsp/gen83xx: Fix define redefinitions Close #3340.

    3341 - sparc64: Macro Redefined

    Link https://devel.rtems.org/ticket/3341
    Id 3341
    Reporter Joel Sherrill
    Created 14 March 2018 21:08:54
    Modified 23 March 2018 16:35:50
    Owner Gedare Bloom
    Type defect
    Component arch/sparc64
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    log/sparc64-usiii.log:/home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/sparc64/include/arch/stack.h:56:0: warning: "STACK_BIAS" redefined

    This is defined in two header files with the same value. Not sure what the proper fix is.

    Comment 1
    1. Joel Sherrill, Wed, 14 Mar 2018 21:09:39 GMT
    2. owner: set to Gedare Bloom
    3. status: changed from new to assigned
    Comment 2
    1. Gedare Bloom, Fri, 23 Mar 2018 16:35:50 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d7fd3bc/rtems:

    sparc64: remove header file with duplicated macros The boot/stack.h header contains duplicated macros that are redundant to arch/stack.h. Delete the boot/stack.h and replace its one use by the arch/stack.h. Closes #3341.

    3342 - pthread_setschedparam() has incorrect prototype

    Link https://devel.rtems.org/ticket/3342
    Id 3342
    Reporter Joel Sherrill
    Created 14 March 2018 22:32:00
    Modified 24 July 2018 07:06:52
    Owner Joel Sherrill
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    We are missing the const on the third parameter. This requires a change to newlib and RTEMS. The correct prototype is:

    int pthread_setschedparam(

    pthread_t thread,
    int policy,
    const struct sched_param *param

    )

    Comment 1
    1. Joel Sherrill, Wed, 14 Mar 2018 22:32:12 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Tue, 20 Mar 2018 18:45:49 GMT

    Change pushed to newlib. I have a patch pending for RTEMS pending a tool bump.

    Comment 3
    1. Sebastian Huber, Fri, 06 Jul 2018 05:27:12 GMT

    In 77fbbd6/rtems:

    posix: Check for new prototypes Update #3342. Update #3343.
    Comment 4
    1. Sebastian Huber, Tue, 24 Jul 2018 07:06:52 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In dc6b940/rtems-source-builder:

    5: Update Newlib Update RISC-V GCC to a GCC 9 branch commit. Close #3342. Close #3343. Update #3452.

    3343 - pthread_mutex_getprioceiling() has incorrect prototype

    Link https://devel.rtems.org/ticket/3343
    Id 3343
    Reporter Joel Sherrill
    Created 14 March 2018 22:34:01
    Modified 24 July 2018 07:06:52
    Owner Joel Sherrill
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    We are missing the const and restrict on the first parameter. This requires a change to newlib and RTEMS. The correct prototype is:

    int pthread_mutex_getprioceiling(

    const pthread_mutex_t *restrict mutex,
    int *prioceiling

    )

    Comment 1
    1. Joel Sherrill, Wed, 14 Mar 2018 22:34:10 GMT
    2. owner: changed from joel to Joel Sherrill
    Comment 2
    1. Joel Sherrill, Tue, 20 Mar 2018 18:45:55 GMT

    Change pushed to newlib. I have a patch pending for RTEMS pending a tool bump.

    Comment 3
    1. Sebastian Huber, Fri, 06 Jul 2018 05:27:12 GMT

    In 77fbbd6/rtems:

    posix: Check for new prototypes Update #3342. Update #3343.
    Comment 4
    1. Sebastian Huber, Tue, 24 Jul 2018 07:06:52 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In dc6b940/rtems-source-builder:

    5: Update Newlib Update RISC-V GCC to a GCC 9 branch commit. Close #3342. Close #3343. Update #3452.

    3344 - mcf5272/mcf5272.h Timer3 Duplicate Definition

    Link https://devel.rtems.org/ticket/3344
    Id 3344
    Reporter Joel Sherrill
    Created 15 March 2018 14:44:25
    Modified 16 March 2018 13:51:04
    Owner Joel Sherrill
    Type defect
    Component arch/m68k
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This .h file uses the same macro names for two blocks of INT macros. My assumption given that the second looks to be a different INT, is that it should not be INT3 again but INT3.

    --- a/bsps/m68k/include/mcf5272/mcf5272.h
    +++ b/bsps/m68k/include/mcf5272/mcf5272.h
    @@ -88,9 +88,9 @@

    #define MCF5272_ICR1_INT3_PI (bit(23))
    #define MCF5272_ICR1_INT3_IPL(x) ((x) << 20)
    #define MCF5272_ICR1_INT3_MASK ((7) << 20)

    -#define MCF5272_ICR1_INT3_PI (bit(19))
    -#define MCF5272_ICR1_INT3_IPL(x) ((x) << 16)
    -#define MCF5272_ICR1_INT3_MASK ((7) << 16)
    +#define MCF5272_ICR1_INT4_PI (bit(19))
    +#define MCF5272_ICR1_INT4_IPL(x) ((x) << 16)
    +#define MCF5272_ICR1_INT4_MASK ((7) << 16)

    Comment 1
    1. Joel Sherrill, Thu, 15 Mar 2018 14:44:32 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Fri, 16 Mar 2018 13:51:04 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    ​https://git.rtems.org/rtems/commit/?id=0c70535d54d27f95c25ad221f2ed8ba23c52ac4b


    3345 - mvme3100 spaces needed around quote in macro definitions in bsp.h

    Link https://devel.rtems.org/ticket/3345
    Id 3345
    Reporter Joel Sherrill
    Created 15 March 2018 14:48:10
    Modified 16 March 2018 13:50:16
    Owner Joel Sherrill
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Various BSP_I2c_XXX_DEV_NAME macros have a stray " at the end of the first parameter.

    Comment 1
    1. Joel Sherrill, Thu, 15 Mar 2018 22:17:14 GMT
    2. summary: changed from mvme3100 extra quote in macro definitions in bsp.h to mvme3100 spaces needed around quote in macro definitions in bsp.h
    Comment 2
    1. Joel Sherrill, Fri, 16 Mar 2018 13:50:16 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    ​https://git.rtems.org/rtems/commit/?id=dce920aea8f2fa286e014ad95f74a4ddb7854469


    3346 - bf533.h

    Link https://devel.rtems.org/ticket/3346
    Id 3346
    Reporter Joel Sherrill
    Created 15 March 2018 14:53:55
    Modified 16 March 2018 13:49:57
    Owner Joel Sherrill
    Type defect
    Component arch/bfin
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    TIMER_STATUS, TIMER< DISABLE, and TIMER_ENABLE are defined in bf52x.h and in bf533.h. Disable second definition in full bf533 register set list and add a sanity check to ensure it stays the same.

    In file included from /home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/bfin/TLL6527M/include/bsp.h:28:0,

    from ../../../../../rtems/c/src/libchip/display/disp_hcms29xx.c:26:

    /home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/bfin/include/bf52x.h:43:0: warning: "TIMER_STATUS" redefined

    #define TIMER_STATUS 0xffc00648

    Comment 1
    1. Joel Sherrill, Fri, 16 Mar 2018 13:49:57 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    ​https://git.rtems.org/rtems/commit/?id=74fe9ceda52c5749f341f57cb9f064276ca3532b


    3348 - beatnick:spaces needed around quote in macro definitions in bsp.h

    Link https://devel.rtems.org/ticket/3348
    Id 3348
    Reporter Joel Sherrill
    Created 15 March 2018 22:18:58
    Modified 16 March 2018 13:49:20
    Owner Joel Sherrill
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Macros need spaces around ","

    Comment 1
    1. Joel Sherrill, Fri, 16 Mar 2018 13:49:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    ​https://git.rtems.org/rtems/commit/?id=8307723dd3f4f282d1847b17ae7ac9db35af8784


    3349 - pc386 edid.h invalid macro names

    Link https://devel.rtems.org/ticket/3349
    Id 3349
    Reporter Joel Sherrill
    Created 15 March 2018 22:20:20
    Modified 16 March 2018 13:38:44
    Owner Joel Sherrill
    Type defect
    Component arch/i386
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Minus sign not underbar in macro name.

    -#define DVS_HDMI-a 0x2
    -#define DVS_HDMI-b 0x3
    +#define DVS_HDMI_a 0x2
    +#define DVS_HDMI_b 0x3

    Comment 1
    1. Joel Sherrill, Fri, 16 Mar 2018 13:38:44 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In be3d7d7/rtems:

    pc386/include/edid.h: Fix macro name to use _ not - Closes #3349.

    3350 - sptimecounter02 warning due to defining _KERNEL and disabling part of <sys/time.h>

    Link https://devel.rtems.org/ticket/3350
    Id 3350
    Reporter Joel Sherrill
    Created 15 March 2018 22:32:28
    Modified 16 March 2018 07:22:01
    Owner Sebastian Huber
    Type defect
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The bottom of is protected by ifndef _KERNEL where gettimeofday() is prototyped. sptimecounter02 is the only test which trips this.

    In file included from /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/include/rtems/confdefs.h:323:0,

    from ../../../../../../../rtems/c/src/../../testsuites/sptests/sptimecounter02/init.c:268:

    /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/include/rtems/imfs.h: In function 'IMFS_update_atime':
    /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/include/rtems/imfs.h:345:3: warning: implicit declaration of function 'gettimeofday' [-Wimplicit-function-declaration]

    gettimeofday( &now, 0 ); ~

    Comment 1
    1. Joel Sherrill, Thu, 15 Mar 2018 22:32:44 GMT
    2. owner: changed from sebastian to Sebastian Huber
    Comment 2
    1. Sebastian Huber, Fri, 16 Mar 2018 07:22:01 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 478dc89/rtems:

    imfs: Use most efficient way to get the time As a side-effect, this fixes some warnings. Close #3350.

    3352 - Warning in all lpc176x variants

    Link https://devel.rtems.org/ticket/3352
    Id 3352
    Reporter Joel Sherrill
    Created 16 March 2018 16:50:30
    Modified 21 March 2018 06:43:55
    Owner Sebastian Huber
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    bsps/arm/lpc176x/include/bsp.h defines OPERATION_COUNT in an attempt to override the autoconf generated constant. This conflicts and results in this warning:

    /home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/arm/lpc176x/include/bsp.h:42:0: warning: "OPERATION_COUNT" redefined

    I understand why this is lowered by the BSP but the mechanism used is not good. And if the include file order is different between tests, you could get the BSP value or the autoconf generated value based on the order.

    This warning needs to be fixed and a safer mechanism for a BSP to override OPERATION_COUNT defined.

    My first suggestion is to use BSP_OPERATION_COUNT and add logic to one of the common test .h files to undef OPERATION_COUNT and redefine it to BSP_OPERATION_COUNT if it is defined.

    A safer option might be to change the name of the autoconf generated variable to OPERATION_COUNT_DEFAULT and rely on logic in a common test support .h to define OPERATION_COUNT to OPERATION_COUNT_DEFAULT or BSP_OPERATION_DEFAULT.

    Comment 1
    1. Joel Sherrill, Fri, 16 Mar 2018 16:51:10 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    4. version: set to 5
    5. component: changed from admin to arch/arm
    6. milestone: set to 5.1
    Comment 2
    1. Sebastian Huber, Mon, 19 Mar 2018 06:05:39 GMT

    This BSP is not from me. It was added with a promise to merge into the lpc24xx BSP. I tend to remove it.

    Comment 3
    1. Sebastian Huber, Mon, 19 Mar 2018 06:11:31 GMT

    ​https://lists.rtems.org/pipermail/devel/2014-June/007110.html

    Maybe we should just consider this BSP as unmaintained.

    Comment 4
    1. Sebastian Huber, Wed, 21 Mar 2018 06:43:55 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 26623e3/rtems:

    bsp/lpc176x: Remove blunt OPERATION_COUNT define BSP-specific test customization needs a more sophisticated approach. Close #3352.

    3354 - PowerPC BSPs duplicate PAGE_MASK, etc redefinition

    Link https://devel.rtems.org/ticket/3354
    Id 3354
    Reporter Joel Sherrill
    Created 16 March 2018 18:29:45
    Modified 29 March 2018 14:12:26
    Owner Joel Sherrill
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The following BSPs:

    powerpc-beatnik
    powerpc-mcp750
    powerpc-mtx603e
    powerpc-mvme2100
    powerpc-mvme2307
    powerpc-mvme5500
    powerpc-qemuprep-altivec
    powerpc-qemuprep

    use bsps/powerpc/include/libcpu/page.h which defines _ALIGN, PAGE_MASK, and PAGE_SIZE. These are defined by . I think the solution is to delete the versions in libcpu/page.h. Comments appreciated.

    ===================
    In file included from ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mvme5500/../../powerpc/shared/startup/pgtbl_setup.c:3:0:
    /home/joel/rtems-work/rtems-testing/rtems/rtems/bsps/powerpc/include/libcpu/page.h:22:0: warning: "PAGE_MASK" redefined

    #define PAGE_MASK (~(PAGE_SIZE-1))

    In file included from /data/home/joel/rtems-work/tools/5/powerpc-rtems5/include/sys/_cpuset.h:36:0,

    from /data/home/joel/rtems-work/tools/5/powerpc-rtems5/include/sys/cpuset.h:45,
    from /data/home/joel/rtems-work/tools/5/powerpc-rtems5/include/sys/_pthreadtypes.h:24,
    from /data/home/joel/rtems-work/tools/5/powerpc-rtems5/include/sys/types.h:239,
    from /data/home/joel/rtems-work/tools/5/powerpc-rtems5/include/sys/time.h:43,
    from /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/include/rtems/score/timestamp.h:43,
    from /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/include/rtems/score/thread.h:36,
    from /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/include/rtems/score/heap.h:22,
    from /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/include/rtems/rtems/types.h:26,
    from /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/include/rtems.h:31,
    from ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mvme5500/../../powerpc/shared/startup/pgtbl_setup.c:1:

    /data/home/joel/rtems-work/tools/5/powerpc-rtems5/include/machine/param.h:70:0: note: this is the location of the previous definition

    #define PAGE_MASK (PAGE_SIZE - 1)

    Comment 1
    1. Joel Sherrill, Thu, 29 Mar 2018 14:12:26 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 0b8a6d7/rtems:

    Eliminate PowerPC libcpu/page.h Started to eliminate warnings and then realized that only one one-line macro in the file was used by a few files. The rest of the file was was not needed. Eliminate the file. Closes #3354.

    3358 - Deprecate rtems_disk_create_phys(), etc.

    Link https://devel.rtems.org/ticket/3358
    Id 3358
    Reporter Sebastian Huber
    Created 22 March 2018 06:10:15
    Modified 27 November 2018 11:46:37
    Owner Sebastian Huber
    Type task
    Component lib/block
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3485
    Blocked by  

    Description

    There are currently two implementations of a block device (disk). Deprecate the legacy rtems_disk_create_phys(), etc. implementation. Remove all RTEMS internal uses except in the block01 test. Add RTEMS_DEPRECATED attribute to API.

    Comment 1
    1. Sebastian Huber, Fri, 18 May 2018 08:45:25 GMT

    In 30c3898/rtems:

    libblock: Init deps in rtems_blkdev_create() Update #3358.
    Comment 2
    1. Sebastian Huber, Fri, 18 May 2018 08:45:35 GMT

    In c4d35fb/rtems:

    libchip: Use rtems_blkdev_create() Update #3358.
    Comment 3
    1. Sebastian Huber, Fri, 18 May 2018 08:45:45 GMT

    In 70502b48/rtems:

    libtests/block05: Use rtems_blkdev_create() Update #3358.
    Comment 4
    1. Sebastian Huber, Mon, 06 Aug 2018 07:05:18 GMT
    2. blocking: set to 3485
    Comment 5
    1. Sebastian Huber, Mon, 06 Aug 2018 07:06:35 GMT
    2. version: set to 5
    3. milestone: changed from 6.1 to 5.1
    Comment 6
    1. Sebastian Huber, Tue, 07 Aug 2018 05:40:22 GMT

    In 24b94c4/rtems:

    ramdisk: Use rtems_blkdev_create() Update #3358.
    Comment 7
    1. Sebastian Huber, Tue, 07 Aug 2018 05:40:32 GMT

    In 16f3f10/rtems:

    nvdisk: Use rtems_blkdev_create() Update #3358.
    Comment 8
    1. Sebastian Huber, Tue, 07 Aug 2018 05:40:42 GMT

    In 0fe7133/rtems:

    flashdisk: Use rtems_blkdev_create() Update #3358.
    Comment 9
    1. Sebastian Huber, Tue, 07 Aug 2018 05:40:53 GMT

    In 1dec54f9/rtems:

    bsps/lm32: Use rtems_blkdev_create() Update #3358.
    Comment 10
    1. Sebastian Huber, Tue, 07 Aug 2018 05:41:03 GMT

    In d279e74/rtems:

    bsp/smdk2410: Use rtems_blkdev_create() Update #3358.
    Comment 11
    1. Sebastian Huber, Tue, 07 Aug 2018 05:41:13 GMT

    In 6782771/rtems:

    libtests/block05: Avoid uninitialized variable Update #3358.
    Comment 12
    1. Sebastian Huber, Tue, 07 Aug 2018 05:41:24 GMT

    In bde8be2/rtems:

    libtests/block06: Use rtems_blkdev_create() Update #3358.
    Comment 13
    1. Sebastian Huber, Tue, 07 Aug 2018 05:41:34 GMT

    In 117f7b1/rtems:

    libtests/block08: Use rtems_blkdev_create() Update #3358.
    Comment 14
    1. Sebastian Huber, Tue, 07 Aug 2018 05:41:44 GMT

    In 5005bfc/rtems:

    libtests/block09: Use rtems_blkdev_create() Update #3358.
    Comment 15
    1. Sebastian Huber, Tue, 07 Aug 2018 05:41:55 GMT

    In 6f34f13/rtems:

    libtests/block10: Use rtems_blkdev_create() Update #3358.
    Comment 16
    1. Sebastian Huber, Tue, 07 Aug 2018 05:42:06 GMT

    In 5e4bab7/rtems:

    libtests/block12: Use rtems_blkdev_create() Update #3358.
    Comment 17
    1. Sebastian Huber, Tue, 07 Aug 2018 05:42:16 GMT

    In 3278d20/rtems:

    libtests/block13: Use rtems_blkdev_create() Update #3358.
    Comment 18
    1. Sebastian Huber, Tue, 07 Aug 2018 05:42:27 GMT

    In fa12e06d/rtems:

    libtests/block14: Use rtems_blkdev_create() Update #3358.
    Comment 19
    1. Sebastian Huber, Tue, 07 Aug 2018 05:42:37 GMT

    In bf80279/rtems:

    libtests/block15: Use rtems_blkdev_create() Update #3358.
    Comment 20
    1. Sebastian Huber, Tue, 07 Aug 2018 05:42:47 GMT

    In 698093d/rtems:

    libblock: Use rtems_blkdev_create_partition() Update #3358.
    Comment 21
    1. Sebastian Huber, Tue, 07 Aug 2018 05:42:57 GMT

    In f7cecc33/rtems:

    libchip/ata: Use rtems_blkdev_create() Update #3358.
    Comment 22
    1. Sebastian Huber, Tue, 07 Aug 2018 05:43:08 GMT

    In 1836c6a/rtems:

    bsp/gen5200: Avoid deprecated routine Update #3358.
    Comment 23
    1. Sebastian Huber, Tue, 07 Aug 2018 05:43:18 GMT

    In dd66fda/rtems:

    tests: Avoid deprecated rtems_disk_io_initialize() Update #3358.
    Comment 24
    1. Sebastian Huber, Tue, 07 Aug 2018 05:43:28 GMT

    In ab96aec/rtems:

    dosfs: Avoid deprecated routine Update #3358.
    Comment 25
    1. Sebastian Huber, Tue, 07 Aug 2018 05:43:38 GMT

    In b152d33/rtems:

    fileio: Avoid deprecated rtems_disk_obtain() Update #3358.
    Comment 26
    1. Sebastian Huber, Tue, 07 Aug 2018 05:43:49 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 0b038bd4/rtems:

    libblock: Add RTEMS_DEPRECATED Close #3358.
    Comment 27
    1. Sebastian Huber, Thu, 06 Sep 2018 05:05:10 GMT

    In ccdce9d8/rtems:

    libchip/ata: Fix ATA_DRIVER_TABLE_ENTRY Drop unused and deprecated functions from the ATA_DRIVER_TABLE_ENTRY. Update #3358. Close #3510.
    Comment 28
    1. Sebastian Huber, Tue, 27 Nov 2018 11:46:37 GMT

    In 06331e4/rtems:

    dosfs: Fix device identifier Update #3358.

    3374 - rtems-test does not honor --mail-from argument

    Link https://devel.rtems.org/ticket/3374
    Id 3374
    Reporter Joel Sherrill
    Created 26 March 2018 23:18:07
    Modified 14 October 2018 01:07:51
    Owner Chris Johns
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This is on the master but may apply to other branches.

    $ /home/joel/rtems-work/rtems-tools__tester/rtems-test --rtems-tools=/home/joel/rtems-work/tools/5 --rtems-bsp=erc32 --log=run.log --mail --mail-from=joel@… --mail-to=build@… ./sparc-rtems5/c/erc32/testsuites/samples/base_sp/base_sp.exe
    error: no valid from address for mail __

    The rtems-test command will work if you have a ~/.mailrc with something like this:

    set from="Joel Sherrill "

    Comment 1
    1. Joel Sherrill, Mon, 26 Mar 2018 23:18:18 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Sun, 14 Oct 2018 01:07:51 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3375 - Remove command line pre-processor defines

    Link https://devel.rtems.org/ticket/3375
    Id 3375
    Reporter Sebastian Huber
    Created 27 March 2018 05:19:46
    Modified 15 October 2018 05:29:18
    Owner Sebastian Huber
    Type enhancement
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Command line defines defined by the build system make it difficult get a consistent view of the sources from other entities, e.g. static code analysis, code editors and reviews.

    Command line defines are currently used here:

    c/src/lib/libbsp/mips/hurricane/Makefile.am:libbsp_a_CPPFLAGS = $(AM_CPPFLAGS) -DRM52XX
    c/src/lib/libbsp/mips/rbtx4938/Makefile.am:libbsp_a_CPPFLAGS = $(AM_CPPFLAGS) -DTX49
    c/src/lib/libbsp/mips/jmr3904/Makefile.am:libbsp_a_CPPFLAGS = $(AM_CPPFLAGS) -DTX39
    cpukit/pppd/Makefile.am:libpppd_a_CPPFLAGS = $(AM_CPPFLAGS) -D__BSD_VISIBLE -I$(srcdir)/../libmd
    cpukit/libfs/Makefile.am:libjffs2_a_CPPFLAGS += -D__ECOS
    cpukit/libfs/Makefile.am:libjffs2_a_CPPFLAGS += '-DKBUILD_MODNAME="JFFS2"'
    cpukit/mghttpd/Makefile.am:# libmghttpd_a_CPPFLAGS += -DHAVE_MD5
    cpukit/mghttpd/Makefile.am:libmghttpd_a_CPPFLAGS += -DNO_SSL -DNO_POPEN -DNO_CGI -DUSE_WEBSOCKET
    cpukit/librpc/Makefile.am:librpc_CPPFLAGS = -D_RPC_read=read -D_RPC_write=write -D_RPC_close=close \
    cpukit/libnetworking/Makefile.am:libnetworking_CPPFLAGS = -DINET -DNFS \
    cpukit/libnetworking/Makefile.am:libc_CPPFLAGS = -DNOPOLL -DNOSELECT -D__BSD_VISIBLE -D_THREAD_SAFE
    cpukit/libnetworking/Makefile.am:lib_CPPFLAGS = -DNOPOLL -DNOSELECT
    cpukit/libnetworking/Makefile.am:lib_a_CPPFLAGS = $(AM_CPPFLAGS) $(lib_CPPFLAGS) -D__BSD_VISIBLE
    cpukit/libdl/Makefile.am:libdl_a_CPPFLAGS = $(AM_CPPFLAGS) -DRTEMS_RTL_RAP_LOADER=1 -DRTEMS_RTL_ELF_LOADER=1
    Comment 1
    1. Chris Johns, Tue, 27 Mar 2018 06:15:31 GMT

    What are you thinking of doing?

    Comment 2
    1. Sebastian Huber, Tue, 27 Mar 2018 06:18:03 GMT

    Move the defines to a header file.

    Comment 3
    1. Joel Sherrill, Tue, 27 Mar 2018 23:09:52 GMT

    For places where the source comes from other places (e.g. JFFS2, etc), what's the approach that doesn't modify the upstream source?

    Comment 4
    1. Sebastian Huber, Wed, 28 Mar 2018 05:02:03 GMT

    We just have to be careful to avoid potential conflicts with upstream merges. JFFS2 is the only area with an active upstream.

    Comment 5
    1. Chris Johns, Wed, 28 Mar 2018 23:25:38 GMT

    Replying to Sebastian Huber:

    We just have to be careful to avoid potential conflicts with upstream merges. JFFS2 is the only area with an active upstream.

    Thank you.

    Comment 6
    1. Sebastian Huber, Wed, 04 Apr 2018 11:51:33 GMT

    In 4f0dca3a/rtems:

    bsps: Move version.c and use bspopts.h This patch is a part of the BSP source reorganization. Update #3285. Update #3375.
    Comment 7
    1. Sebastian Huber, Mon, 30 Apr 2018 06:08:38 GMT

    In 6ac6a5c8/rtems:

    jffs2: Do not use command line defines Update #3375.
    Comment 8
    1. Sebastian Huber, Mon, 10 Sep 2018 09:36:43 GMT

    In cb68253/rtems:

    network: Use kernel/user space header files Add and use and similar to the libbsd to avoid command line defines and defines scattered throught the code base. Simplify cpukit/libnetworking/Makefile.am. Update #3375.
    Comment 9
    1. Sebastian Huber, Thu, 04 Oct 2018 08:50:16 GMT

    In e069f7fe/rtems:

    rpc: Use configuration header file Update #3375.
    Comment 10
    1. Sebastian Huber, Thu, 04 Oct 2018 08:50:27 GMT

    In 06060da/rtems:

    pppd: Simplify Makefile.am Update #3375.
    Comment 11
    1. Sebastian Huber, Thu, 04 Oct 2018 08:50:37 GMT

    In 2e77151/rtems:

    mghttpd: Add configuration to source file Update #3375.
    Comment 12
    1. Sebastian Huber, Thu, 04 Oct 2018 08:50:47 GMT

    In f373bdc0/rtems:

    libdl: Avoid command line defines Update #3375.
    Comment 13
    1. Sebastian Huber, Thu, 04 Oct 2018 08:50:58 GMT

    In 2d17e88/rtems:

    bsps/mips: Remove unused command line defines Update #3375.
    Comment 14
    1. Sebastian Huber, Wed, 10 Oct 2018 11:59:34 GMT

    In 6cdaa85/rtems:

    shell: Use #include "..." for local header files Update #3375.
    Comment 15
    1. Joel Sherrill, Sat, 13 Oct 2018 22:52:24 GMT

    How much is left to do on this ticket?

    Comment 16
    1. Sebastian Huber, Mon, 15 Oct 2018 05:29:18 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In fb12215/rtems:

    build: Remove specialized CPPFLAGS Close #3375.

    3376 - Remove cklength program

    Link https://devel.rtems.org/ticket/3376
    Id 3376
    Reporter Sebastian Huber
    Created 27 March 2018 05:47:55
    Modified 15 June 2018 05:16:11
    Owner Sebastian Huber
    Type task
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The cklength program (tools/build/cklength.c) has no license information and is unused in the RTEMS build. General usability is questionable, for example a

    awk 'length($0) > 80' < file 

    performs a similar task. Remove it.

    Comment 1
    1. Chris Johns, Thu, 26 Apr 2018 02:39:38 GMT

    OK to remove.

    Comment 2
    1. Sebastian Huber, Fri, 15 Jun 2018 05:16:11 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In f4fee72b/rtems:

    tools: Remove cklength This program has no license information and is unused in the RTEMS build. General usability is questionable, for example a
    awk 'length($0) > 80' < file
    performs a similar task. Remove it. Close #3376.

    3377 - Remove eolstrip program

    Link https://devel.rtems.org/ticket/3377
    Id 3377
    Reporter Sebastian Huber
    Created 27 March 2018 05:52:26
    Modified 15 June 2018 05:16:21
    Owner Sebastian Huber
    Type task
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The eolstrip program (tools/build/eolstrip.c) has no license information and is unused in the RTEMS build. General usability is questionable, for example a

    sed -i 's/[[:space:]]*$//' file 

    performs a similar task. Remove it.

    Comment 1
    1. Chris Johns, Thu, 26 Apr 2018 02:39:48 GMT

    OK to remove.

    Comment 2
    1. Sebastian Huber, Fri, 15 Jun 2018 05:16:21 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 64fa76bb/rtems:

    tools: Remove eolstrip This program has no license information and is unused in the RTEMS build. General usability is questionable, for example a
    sed -i 's/:space:?*$__' file __
    performs a similar task. Remove it. Close #3377.

    3378 - Remove unhex program

    Link https://devel.rtems.org/ticket/3378
    Id 3378
    Reporter Sebastian Huber
    Created 27 March 2018 05:57:58
    Modified 15 June 2018 05:16:31
    Owner Sebastian Huber
    Type task
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The unhex program (tools/build/unhex.c) has no license information and is unused in the RTEMS build. Users of HEX files should consider to use ELF instead. Remove it.

    Comment 1
    1. Chris Johns, Thu, 26 Apr 2018 02:39:59 GMT

    OK to remove.

    Comment 2
    1. Sebastian Huber, Fri, 15 Jun 2018 05:16:31 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 31f0eb9e/rtems:

    tools: Remove unhex This program has no license information and is unused in the RTEMS build. Users of HEX files should consider to use ELF instead. Remove it. Close #3378.

    3379 - Remove packhex program

    Link https://devel.rtems.org/ticket/3379
    Id 3379
    Reporter Sebastian Huber
    Created 27 March 2018 06:08:39
    Modified 15 June 2018 05:42:25
    Owner Sebastian Huber
    Type task
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The packhex program ( tools/build/packhex.c) is exported to the standard RTEMS build infrastructure via the PACKHEX variable. It is used by some legacy BSPs. It as unclear license information:

    /*****  P A C K H E X . C  ************************************************
    *
    * Packhex is a hex-file compaction utility. It attempts to concatenate
    * hex records to produce more size-efficient packaging.
    *
    * Limitations: Input files must be correctly formatted. This utility
    * is not robust enough to detect hex-record formatting
    * errors.
    *
    * Published: May 1993 Embedded Systems Programming magazine
    * "Creating Faster Hex Files"
    *
    * URL: ESP magazine: http://www.embedded.com
    * Source Code: ftp://ftp.mfi.com/pub/espmag/1993/pakhex.zip
    *
    * Author: Mark Gringrich
    *
    * Compiler: Microsoft C 6.0
    * cl /F 1000 packhex.c
    *
    **************************************************************************/

    Move it to rtems-tools.

    Comment 1
    1. Chris Johns, Thu, 26 Apr 2018 02:40:11 GMT

    OK to remove.

    Comment 2
    1. Sebastian Huber, Thu, 07 Jun 2018 05:03:34 GMT
    2. summary: changed from Move unhex program to rtems-tools to Move packhex program to rtems-tools
    Comment 3
    1. Sebastian Huber, Thu, 14 Jun 2018 09:45:24 GMT
    2. summary: changed from Move packhex program to rtems-tools to Remove packhex program

    This program has no license information and is unused in the RTEMS build. Users of HEX files should consider to use ELF instead. Remove it.

    Comment 4
    1. Sebastian Huber, Fri, 15 Jun 2018 05:17:12 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In e8b28ba/rtems:

    tools: Remove packhex All tools should be removed from the RTEMS source repository at some point in time. Tools with a BSD-style license will be moved to the RTEMS tools repository. Unfortunately, this tool has no license information. Remove all uses of this tool from the code base. Users of HEX files should consider to use ELF instead. Close #3379.
    Comment 5
    1. Joel Sherrill, Fri, 15 Jun 2018 05:27:50 GMT

    Users of this tool cannot use ELF because this is used with boards where you must download in hex formats.

    Comment 6
    1. Chris Johns, Fri, 15 Jun 2018 05:42:25 GMT

    Replying to Joel Sherrill:

    Users of this tool cannot use ELF because this is used with boards where you must download in hex formats.

    If you logically extend this should we support all possible formats users can download? I suggest we do not.

    The code is available for users to integrate into their workflow.


    3380 - Move rtems-bin2c program to rtems-tools

    Link https://devel.rtems.org/ticket/3380
    Id 3380
    Reporter Sebastian Huber
    Created 27 March 2018 06:12:10
    Modified 15 June 2018 05:16:00
    Owner Sebastian Huber
    Type task
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The rtems-bin2c program (tools/build/rtems-bin2c.c) is exported to the standard RTEMS build infrastructure via the BIN2C variable. Move it to rtems-tools.

    Comment 1
    1. Chris Johns, Thu, 26 Apr 2018 02:40:24 GMT

    OK to move.

    Comment 2
    1. Sebastian Huber, Fri, 15 Jun 2018 05:04:57 GMT

    In 1cd75c4/rtems-tools:

    bin2c: Import from RTEMS Corresponding RTEMS commit is 75933d5d25cd50f80162b7a0d2f66a5534e1763f. Update #3380.
    Comment 3
    1. Sebastian Huber, Fri, 15 Jun 2018 05:05:04 GMT

    In 1a89c3d/rtems-tools:

    bin2c: Fix warnings Update #3380.
    Comment 4
    1. Sebastian Huber, Fri, 15 Jun 2018 05:12:37 GMT

    In 528ee18/rtems-source-builder:

    5: Update tools to ship rtems-bin2c Update #3380.
    Comment 5
    1. Sebastian Huber, Fri, 15 Jun 2018 05:16:00 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In ea092ccc/rtems:

    tools: Remove rtems-bin2c This tool is now included in the RTEMS tools repository. Close #3380.

    3381 - rtems-test command line documentation appears to be out of date

    Link https://devel.rtems.org/ticket/3381
    Id 3381
    Reporter Joel Sherrill
    Created 27 March 2018 19:25:53
    Modified 28 April 2020 05:27:54
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    ​https://docs.rtems.org/branches/master/user/tools/tester.html#command-line-help does not look like the current output of the --help.

    This may also apply to other branches and branch specific tickets filed.

    Comment 1
    1. Joel Sherrill, Tue, 27 Mar 2018 19:26:10 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    4. component: changed from tool to doc
    Comment 2
    1. Gedare Bloom, Sat, 04 Apr 2020 20:52:10 GMT

    The simple solution is to not show the excerpt of --help output. Having these output examples that are not forward-compatible is a bit of a pain.

    Comment 3
    1. Chris Johns, Tue, 28 Apr 2020 05:22:16 GMT

    Replying to Gedare Bloom:

    The simple solution is to not show the excerpt of --help output. Having these output examples that are not forward-compatible is a bit of a pain.

    I agree. I will remove it.

    Comment 4
    1. Chris Johns, Tue, 28 Apr 2020 05:27:54 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 8bf866b/rtems-docs:

    user/tester: Remove command line help as output Closes #3381

    3382 - Testsuite Makefile merge to one per group of tests

    Link https://devel.rtems.org/ticket/3382
    Id 3382
    Reporter Chris Johns
    Created 5 April 2018 02:46:39
    Modified 19 October 2018 00:30:39
    Owner Chris Johns
    Type enhancement
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Merge the nested Makefile.am files into a single file per group of tests.

    A single Makefile.am for all tests is not practical at this point in time because a test is an estimated 7 lines and with over 750 tests this means the file would be too big and a conflict hot spot.

    Comment 1
    1. Chris Johns, Mon, 09 Apr 2018 22:36:29 GMT

    In 18f77699/rtems:

    testsuite: Autoconf test check support. The autoconf function checks the state of a test for the BSP and controls the building of the test. This change is part of the testsuite Makefile.am reorganisation. Update #3382
    Comment 2
    1. Chris Johns, Mon, 09 Apr 2018 22:36:39 GMT

    In 32f2629b/rtems:

    testsuite/benchmarks: Merged nested Makefile.am files into one Makefile.am This change is part of the testsuite Makefile.am reorganization. Update #3382
    Comment 3
    1. Chris Johns, Mon, 09 Apr 2018 22:36:49 GMT

    In 5c65b98/rtems:

    testsuite/libtests: Merged nested Makefile.am files into one Makefile.am This change is part of the testsuite Makefile.am reorganization. Update #3382
    Comment 4
    1. Chris Johns, Mon, 09 Apr 2018 22:37:00 GMT

    In 8967e5f/rtems:

    testsuite/fstests: Merged nested Makefile.am files into one Makefile.am This change is part of the testsuite Makefile.am reorganization. Update #3382
    Comment 5
    1. Chris Johns, Mon, 09 Apr 2018 22:37:12 GMT

    In 3206879f/rtems:

    testsuite/mptests: Merged nested Makefile.am files into one Makefile.am This change is part of the testsuite Makefile.am reorganization. Update #3382
    Comment 6
    1. Chris Johns, Mon, 09 Apr 2018 22:37:24 GMT

    In 2a99a6a/rtems:

    testsuite/psxtests: Merged nested Makefile.am files into one Makefile.am This change is part of the testsuite Makefile.am reorganization. Update #3382
    Comment 7
    1. Chris Johns, Mon, 09 Apr 2018 22:37:46 GMT

    In dfc57eb/rtems:

    testsuite/psxtmtests: Merged nested Makefile.am files into one Makefile.am This change is part of the testsuite Makefile.am reorganization. Update #3382
    Comment 8
    1. Chris Johns, Mon, 09 Apr 2018 22:38:07 GMT

    In 590a5809/rtems:

    testsuite/irhealstone: Merged nested Makefile.am files into one Makefile.am This change is part of the testsuite Makefile.am reorganization. Update #3382
    Comment 9
    1. Chris Johns, Mon, 09 Apr 2018 22:38:22 GMT

    In d027e6bb/rtems:

    testsuite/samples: Merged nested Makefile.am files into one Makefile.am This change is part of the testsuite Makefile.am reorganization. Update #3382
    Comment 10
    1. Chris Johns, Mon, 09 Apr 2018 22:38:39 GMT

    In 8074fa0b/rtems:

    testsuite/smptests: Merged nested Makefile.am files into one Makefile.am This change is part of the testsuite Makefile.am reorganization. Update #3382
    Comment 11
    1. Chris Johns, Mon, 09 Apr 2018 22:38:55 GMT

    In bc06753/rtems:

    testsuite/sptests: Merged nested Makefile.am files into one Makefile.am This change is part of the testsuite Makefile.am reorganization. Update #3382
    Comment 12
    1. Chris Johns, Mon, 09 Apr 2018 22:39:06 GMT

    In cc14545e/rtems:

    testsuite/tmtests: Merged nested Makefile.am files into one Makefile.am This change is part of the testsuite Makefile.am reorganization. Update #3382
    Comment 13
    1. Chris Johns, Mon, 09 Apr 2018 22:39:17 GMT

    In ee3d7dcb/rtems:

    testsuites: Remove the test check from the subdir support. Leave the parallel support so each test group builds in parallel. Update #3382
    Comment 14
    1. Chris Johns, Mon, 09 Apr 2018 22:39:28 GMT

    In cb7b4dc4/rtems:

    bsp/lpc24xx: Exclude iconv POSIX tests. These are now built to executables and are too large for this BSP. This change is part of the testsuite Makefile.am reorganization. Update #3382
    Comment 15
    1. Sebastian Huber, Tue, 10 Apr 2018 10:39:13 GMT

    In 2eaea422/rtems:

    sptests: Fix AM_CONDITIONAL Update #3382.
    Comment 16
    1. Chris Johns, Fri, 19 Oct 2018 00:30:39 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    This task is finished.


    3383 - Require --enable-rtemsbsp with --enable-smp or --enable-multiprocessor

    Link https://devel.rtems.org/ticket/3383
    Id 3383
    Reporter Chris Johns
    Created 9 April 2018 06:06:41
    Modified 9 April 2018 22:47:28
    Owner Chris Johns
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    There is a limited number of BSPs that support SMP or MP so using the BSP wildcard will result in a failed build. Require the user provide a BSP.

    Comment 1
    1. Joel Sherrill, Mon, 09 Apr 2018 13:44:55 GMT
    2. summary: changed from Require --enable-rtemsbsb with --enable-smp or --enable-multiprocessor to Require --enable-rtemsbsp with --enable-smp or --enable-multiprocessor
    Comment 2
    1. Chris Johns, Mon, 09 Apr 2018 22:47:28 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    See e1664027/rtems for the changeset.


    3384 - Prefer int for int32_t

    Link https://devel.rtems.org/ticket/3384
    Id 3384
    Reporter Sebastian Huber
    Created 9 April 2018 06:09:46
    Modified 13 December 2019 06:07:28
    Owner Sebastian Huber
    Type enhancement
    Component tool/gcc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Common systems like Linux and FreeBSD define int32_t to int. This means a lot of third party code works well in these cases:

    #include 
    void f(int32_t);
    void f(int);
    void g(int32_t *);
    void h(void)
    {
    int i;
    g(&i);
    }

    On RTEMS you get however in C

    test.c:5:6: error: conflicting types for 'f'
    void f(int);
    ^
    test.c:3:6: note: previous declaration of 'f' was here
    void f(int32_t);
    ^
    test.c: In function 'h':
    test.c:12:4: warning: passing argument 1 of 'g' from incompatible pointer type [-Wincompatible-pointer-types]
    g(&i);
    ^
    test.c:7:6: note: expected 'int32_t * {aka long int *}' but argument is of type 'int *'
    void g(int32_t *);

    and C++

    test.c: In function 'void h()':
    test.c:12:4: error: invalid conversion from 'int*' to 'int32_t* {aka long int*}' [-fpermissive]
    g(&i);
    ^~
    test.c:7:6: note: initializing argument 1 of 'void g(int32_t*)'
    void g(int32_t *);
    ^

    This is due to a Newlib speciality which uses long for int32_t if long is a 32-bit type. To ease the use of third party software in RTEMS we should override this option and use int for int32_t just like the standard host operating systems (e.g. Linux and FreeBSD). Only a small GCC patch is required to do this:

    diff --git a/gcc/config/rtems.h b/gcc/config/rtems.h
    index 439199d4cbb..9b1408efe6f 100644
    --- a/gcc/config/rtems.h
    +++ b/gcc/config/rtems.h
    @@ -48,3 +48,7 @@
    -latomic -lc -lgcc --end-group %{!qnolinkcmds: -T linkcmds%s} } }"
    #define TARGET_POSIX_IO
    +
    +/* Use int for int32_t (see stdint-newlib.h). */
    +#undef STDINT_LONG32
    +#define STDINT_LONG32 0
    Comment 1
    1. Joel Sherrill, Mon, 09 Apr 2018 13:39:53 GMT

    Just to keep it clean, what if int is 16 bits on the target?

    Comment 2
    1. Sebastian Huber, Mon, 09 Apr 2018 13:46:46 GMT

    See newlib-stdint.h in GCC sources:

    [...]
    `#define INT32_TYPE (STDINT_LONG32 ? "long int" : INT_TYPE_SIZE == 32 ? "int" : SHORT_TYPE_SIZE == 32 ? "short int" : CHAR_TYPE_SIZE == 32 ? "signed char" : 0)`
    [...] 

    So, 16-bit targets should not use this option.

    Comment 3
    1. Sebastian Huber, Thu, 14 Jun 2018 05:21:24 GMT

    Committed to GCC as:

    ​https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=261582 ​https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=261583 ​https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=261584

    Comment 4
    1. Sebastian Huber, Thu, 14 Jun 2018 05:23:35 GMT
    2. summary: changed from Change int32_t to int to Prefer int for int32_t
    Comment 5
    1. Sebastian Huber, Tue, 11 Dec 2018 07:39:39 GMT

    In b4e80fb/rtems-source-builder:

    5: Update GCC 7.3.0 to 7.4.0 Update #3384.
    Comment 6
    1. Sebastian Huber, Thu, 13 Dec 2018 10:34:46 GMT

    In 258129e/rtems-source-builder:

    5: Fix x86_64 GCC 7.4.0 build Update #3384.
    Comment 7
    1. Sebastian Huber, Tue, 29 Jan 2019 08:22:22 GMT

    In 4f3a253/rtems:

    psxtmtests: Fix format warnings Update #3384.
    Comment 8
    1. Joel Sherrill, Thu, 12 Dec 2019 23:11:05 GMT

    Can this be closed?

    Comment 9
    1. Sebastian Huber, Fri, 13 Dec 2019 06:07:14 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    Comment 10
    1. Sebastian Huber, Fri, 13 Dec 2019 06:07:28 GMT
    2. version: set to 5

    3385 - Generate an error if RTEMS's gcc is not found when the user runs configure

    Link https://devel.rtems.org/ticket/3385
    Id 3385
    Reporter Chris Johns
    Created 9 April 2018 06:15:46
    Modified 9 April 2018 22:22:51
    Owner Chris Johns
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Generate an error when the user runs configure if one cannot be found in the path.

    Comment 1
    1. Chris Johns, Mon, 09 Apr 2018 06:16:38 GMT
    2. description: modified (diff)
    3. summary: changed from Generate an error is RTEMS's gcc is not found when the user runs configure to Generate an error if RTEMS's gcc is not found when the user runs configure
    Comment 2
    1. Chris Johns, Mon, 09 Apr 2018 22:22:51 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 9f6f026/rtems:

    Generate an error if no valid gcc is found when configure runs. Close #3385.

    3386 - Trac's git changeset browsing is suspect.

    Link https://devel.rtems.org/ticket/3386
    Id 3386
    Reporter Chris Johns
    Created 9 April 2018 23:11:19
    Modified 20 October 2018 21:15:43
    Owner Amar Takhar
    Type defect
    Component admin
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority high
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    It is critical this interface works because we have moved to Trac for release notes and the release notes contain links to the changesets because we reference the tickets in the commits.

    Some requests work:

  • 900c40730dbee34cd7a6f1c03c80896951bf1b9c/rtems
  • d8de6b9dbe4ab1ef375ecce55e8bfb1028c5dd13/rtems
  • 9704efb4ec088a472842cbc9bc46392685ebc806/rtems
  • and others do not:

  • 2afb22b7e1ebcbe40373ff7e0efae7d207c655a9/rtems
  • Notes:

    • items 2. and 3. are either side of the changeset a. in the commit history of RTEMS.
    • Clicking on 3. and then the Next Changeset link also fails.
    Comment 1
    1. Amar Takhar, Sat, 20 Oct 2018 21:15:43 GMT
    2. status: changed from assigned to closed
    3. resolution: set to invalid

    This is a known issue and will only be fixed by upgrading to Trac 1.3 The diff is just too large and Apache times out before it's done. You can use git.rtems.org to view it as it's written in C and not some kludgy python:

    ​https://git.rtems.org/rtems/commit/?id=2afb22b7e1ebcbe40373ff7e0efae7d207c655a9


    3387 - Add subdir-objects to automake flags

    Link https://devel.rtems.org/ticket/3387
    Id 3387
    Reporter Chris Johns
    Created 10 April 2018 05:59:45
    Modified 19 December 2019 08:14:20
    Owner Sebastian Huber
    Type defect
    Component build
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This will be fixed by the new build system, see #3818.

    Comment 1
    1. Chris Johns, Wed, 11 Apr 2018 01:58:07 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In aa567bc1/rtems:

    configure: Add subdir-objects to all automake flags. This option silences warning with automake-1.16.1 allowing us to upgrade to that version. This change has been tested with automake-1.12.6 and automake-1.16.1. It seems version 1.16.1 configures slower than 1.12.6 for the same source and BSP. The newer versions is 6 second slower. Close #3387.
    Comment 2
    1. Sebastian Huber, Wed, 11 Apr 2018 05:21:30 GMT

    I am not sure, but I think this breaks the BSP build. We have now for example in the build tree:

    pwd
    sparc-rtems5/c/erc32/lib/libbsp/sparc/erc32
    make clean
    test -z "" || rm -f
    test -z "librtemsbsp.a" || rm -f librtemsbsp.a
    rm -f *.o
    rm -f ../../../../../../bsps/shared/*.o
    rm -f ../../../../../../bsps/shared/cache/*.o
    rm -f ../../../../../../bsps/shared/dev/display/*.o
    rm -f ../../../../../../bsps/shared/dev/flash/*.o
    rm -f ../../../../../../bsps/shared/dev/i2c/*.o
    rm -f ../../../../../../bsps/shared/dev/ide/*.o
    rm -f ../../../../../../bsps/shared/dev/rtc/*.o
    rm -f ../../../../../../bsps/shared/dev/serial/*.o
    rm -f ../../../../../../bsps/shared/irq/*.o
    rm -f ../../../../../../bsps/shared/net/*.o
    rm -f ../../../../../../bsps/shared/shmdr/*.o
    rm -f ../../../../../../bsps/shared/start/*.o
    rm -f ../../shared/*.o
    rm -f ../shared/*.o
    rm -f ../shared/irq/*.o
    rm -f ../shared/startup/*.o
    rm -f clock/*.o
    rm -f console/*.o
    rm -f erc32sonic/*.o
    rm -f gnatsupp/*.o
    rm -f startup/*.o
    rm -f timer/*.o 

    This assumes that the build and source tree have the same layout. However, this is not the case. For example:

    pwd
    sparc-rtems5/c/erc32/lib/libbsp/sparc/erc32
    ls ../../../../../..
    at697f  bsps  c  erc32  gr712rc  gr740  leon2  leon3  ut699  ut700 

    The critical issues is that the bsps directory is not BSP-specific.

    Comment 3
    1. Sebastian Huber, Wed, 11 Apr 2018 05:21:40 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted
    Comment 4
    1. Chris Johns, Wed, 11 Apr 2018 06:04:13 GMT

    Replying to Sebastian Huber:

    I am not sure, but I think this breaks the BSP build.

    I think it exposes a bug in the BSP Makefile support. Object files must stay contained under the BSP directory. Why does the cpukit not have a problem?

    Comment 5
    1. Sebastian Huber, Wed, 11 Apr 2018 06:07:22 GMT

    The problem is that we are right in between a move of the BSP sources from one tree to another.

    Comment 6
    1. Chris Johns, Wed, 11 Apr 2018 06:11:10 GMT

    Will the move clean up the build tree and avoid this issue once the move is done? If so the only thing that is broken is building more than one BSP at a time. Is that a problem for you?

    Comment 7
    1. Sebastian Huber, Wed, 11 Apr 2018 06:21:34 GMT

    To finish the move will need a couple of weeks (more than four I guess). Do I have to use the BSP builder to build the BSPs?

    Comment 8
    1. Chris Johns, Wed, 11 Apr 2018 06:41:40 GMT

    Replying to Chris Johns:

    Will the move clean up the build tree and avoid this issue once the move is done?

    Nice, I am looking forward to this happening.

    If so the only thing that is broken is building more than one BSP at a time. Is that a problem for you?

    That is one way.

    Just thought of a simpler solution that may work. What if you remove the subdir-objects option from the just the effected Makefile.am file(s)? This leave the parts of the build tree that are fixed ready and as you fix the broken parts the option can be added. It also lets automake-1.16.1 indicate we have a problem in the areas we have not fixed.

    Does that work?

    Comment 9
    1. Sebastian Huber, Thu, 12 Apr 2018 05:55:53 GMT

    In 4ff09d5b/rtems:

    build: Remove subdir-objects from BSP configure.ac The subdir-objects do not work currently due to BSP sources in bsps and c and the existing build tree layout. Update #3387.
    Comment 10
    1. Sebastian Huber, Thu, 12 Apr 2018 09:14:04 GMT
    2. owner: changed from Chris Johns to Sebastian Huber
    3. status: changed from reopened to assigned
    Comment 11
    1. Sebastian Huber, Fri, 20 Apr 2018 13:31:12 GMT

    In 234f0a2d/rtems:

    build: Remove subdir-objects from Ada tests Somehow it does not work. With this Automake option you get: gmake[6]: Entering directory '/build/sparc-rtems5/c/erc32/testsuites/ada/sptests' Making all-am in sp01 gmake[7]: Entering directory '/build/sparc-rtems5/c/erc32/testsuites/ada/sptests/sp01' gmake[7]: __* No rule to make target 'init.o', needed by 'ada_sp01.exe'. Stop. __ Update #3387.
    Comment 12
    1. Joel Sherrill, Thu, 12 Dec 2019 23:13:52 GMT

    Is this ticket "won't fix" with the move to the new build system?

    Comment 13
    1. Sebastian Huber, Fri, 13 Dec 2019 06:05:12 GMT

    Yes, provided we move to the new build system.

    Comment 14
    1. Chris Johns, Fri, 13 Dec 2019 12:53:29 GMT

    Replying to Sebastian Huber:

    Yes, provided we move to the new build system.

    I have been using the build system when doing some work week and I am now addicted.

    I would like us to resolve the tickets we have to clear 5.0 then branch the repos. I can then prepare a release. This would release master for the merge the new build system.

    Comment 15
    1. Sebastian Huber, Thu, 19 Dec 2019 08:14:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to wontfix
    4. description: modified (diff)

    3388 - rtems-tester: possible parsing error for qemuprep-altivec on exclude SMP configuration

    Link https://devel.rtems.org/ticket/3388
    Id 3388
    Reporter Joel Sherrill
    Created 11 April 2018 22:30:55
    Modified 6 April 2020 05:09:31
    Owner chrisj@…
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords rtems-tester
    Cc  
    Blocking  
    Blocked by  

    Description

    These failures have persisted across all the autoconf changes:

    Failures:

    powerpc/qemuprep-altivec:

    configure --target=powerpc-rtems5 --enable-rtemsbsp=qemuprep-altivec\
    --prefix=/home/joel/rtems-work/bsps --enable-networking --enable-smp
    ld/collect2:0 error: no error message found!

    powerpc/qemuprep-altivec:

    configure --target=powerpc-rtems5 --enable-rtemsbsp=qemuprep-altivec\
    --prefix=/home/joel/rtems-work/bsps --enable-debug --enable-smp
    ld/collect2:0 error: no error message found!

    powerpc/qemuprep-altivec:

    configure --target=powerpc-rtems5 --enable-rtemsbsp=qemuprep-altivec\
    --prefix=/home/joel/rtems-work/bsps --enable-debug --enable-\
    networking --enable-smp
    ld/collect2:0 error: no error message found!

    powerpc/qemuprep-altivec:

    configure --target=powerpc-rtems5 --enable-rtemsbsp=qemuprep-altivec\
    --prefix=/home/joel/rtems-work/bsps --enable-smp
    ld/collect2:0 error: no error message found!

    I checked and it looks like qemuprep-altivec is listed in the smp excludes section.

    It is the only BSP with a - in the name that is in smp-excludes. Could it be that the
    matching fails in this case?

    The other is pc586-sse which is SMP excluded also but using a different mechanism..

    Comment 1
    1. Chris Johns, Fri, 19 Oct 2018 00:34:17 GMT

    This should be fixed in a recent rtems-tools. Please test and closed fixed if it is fixed.

    Comment 2
    1. Chris Johns, Fri, 19 Oct 2018 00:35:16 GMT

    Why rtems-tester in the subject line?

    Comment 3
    1. Gedare Bloom, Mon, 06 Apr 2020 05:09:31 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3389 - Warning flags have disappeared with recent autoconf changes

    Link https://devel.rtems.org/ticket/3389
    Id 3389
    Reporter Joel Sherrill
    Created 11 April 2018 23:47:13
    Modified 14 October 2018 00:50:39
    Owner  
    Type defect
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    As of March 30, the compiler invocations had warnings flags. As of today (4/11), there are no warnings flag on most of the compiler invocations.

    Something has been lost in the updates.

    Comment 1
    1. Chris Johns, Thu, 12 Apr 2018 00:28:12 GMT

    Are you able to git bisect and find the commit?

    Comment 2
    1. Joel Sherrill, Wed, 18 Apr 2018 13:44:07 GMT

    I was unable to pin down the commit with a git bisect.

    Comment 3
    1. Sebastian Huber, Mon, 17 Sep 2018 11:32:44 GMT

    Fixed by [32481371e9e9e33aabf5e8634750ecd697c85531/rtems].

    Comment 4
    1. Chris Johns, Sun, 14 Oct 2018 00:50:39 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    3390 - NFS: Remove support for cexp

    Link https://devel.rtems.org/ticket/3390
    Id 3390
    Reporter Sebastian Huber
    Created 12 April 2018 05:08:31
    Modified 12 April 2018 05:17:00
    Owner Sebastian Huber
    Type task
    Component network/legacy
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    There is some support for cexp and tests in the NFS client directory:

    cpukit/libfs/src/nfsclient/src/cexphelp.c
    cpukit/libfs/src/nfsclient/src/dirutils.c
    cpukit/libfs/src/nfsclient/src/nfs.modini.c
    cpukit/libfs/src/nfsclient/src/nfsTest.c
    cpukit/libfs/src/nfsclient/src/rpcio.modini.c

    There are also some *.rel files installed. This stuff is probably unused. If it is still in use it should move elsewhere, e.g. some general cexp support outside of the main RTEMS sources. Dead/untested code should not be present in the RTEMS code base.

    See also:

    ​https://lists.rtems.org/pipermail/users/2018-April/032182.html

    Comment 1
    1. Sebastian Huber, Thu, 12 Apr 2018 05:17:00 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 9e36910/rtems:

    NFS: Remove support for cexp Avoid use of RTEMS_RELLDFLAGS. Close #3390.

    3392 - infinite loop in RSB's path when a prefix path is not writable

    Link https://devel.rtems.org/ticket/3392
    Id 3392
    Reporter Chris Johns
    Created 13 April 2018 03:05:53
    Modified 13 April 2018 03:10:08
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The code gets the dirname() of the path stepping up until there is no path however dirname('/') is / so the path never has a length of 0.

    Comment 1
    1. Chris Johns, Fri, 13 Apr 2018 03:06:15 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to accepted
    4. component: changed from admin to tool/rsb
    Comment 2
    1. Chris Johns, Fri, 13 Apr 2018 03:10:08 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In cabaff8/rtems-source-builder:

    sb/path: Walk up to root checking if a path is writable. A dirname of / is / so the path will never have a length of 0. Close #3392

    3395 - rtems-ld does not remove executable when there is an output error

    Link https://devel.rtems.org/ticket/3395
    Id 3395
    Reporter Chris Johns
    Created 14 April 2018 03:29:54
    Modified 14 April 2018 04:17:57
    Owner Chris Johns
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    An error when outputting an executable does not clean up the file and leaves an incorrect format file.

    This is happening with the beagle bone black BSP and test dl06.

    Comment 1
    1. Chris Johns, Sat, 14 Apr 2018 03:30:09 GMT
    2. description: modified (diff)
    Comment 2
    1. Chris Johns, Sat, 14 Apr 2018 04:17:57 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 82c8788/rtems-tools:

    rtemstoolkit/rtl-file: Remove a file on close if requested Close #3395

    3396 - rtems-ld does not handle R_ARM_V4BX relocation records

    Link https://devel.rtems.org/ticket/3396
    Id 3396
    Reporter Chris Johns
    Created 16 April 2018 01:54:13
    Modified 16 April 2018 01:57:46
    Owner Chris Johns
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The R_ARM_V4BX does not have a symbol and this raised an error with dl06 with a ARMv7 instruction set when merging sections when creating a RAP image.

    Ignore this relocation record.

    Comment 1
    1. Chris Johns, Mon, 16 Apr 2018 01:57:46 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In ec419a0/rtems-tools:

    rtemstoolkit/rap: Ignore R_ARM_V4BX relocation records Note, this removes the detalis needed to alter the instruction for an ARMv4 instruction set. Currently this type of record is not handled in the RAP format loader and the RTL loader ignores it. Close #3396

    3397 - The register keyword is deprecated in C++11

    Link https://devel.rtems.org/ticket/3397
    Id 3397
    Reporter Sebastian Huber
    Created 16 April 2018 05:22:14
    Modified 17 April 2018 05:06:01
    Owner Sebastian Huber
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The following code gives a warning with GCC and -std=c++17:

    void f(void)
    {
    register int i;
    }
    test.cc: In function ‘void f()’:
    test.cc:3:15: warning: ISO C++1z does not allow ‘register’ storage class specifier [-Wregister]
    register int i;
    ^

    Remove the use of the register keyword at least in the public header files for C++ compatibility.

    Comment 1
    1. Sebastian Huber, Tue, 17 Apr 2018 05:06:01 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In f35c3be9/rtems:

    Remove register keyword from public header files The following code
    void f(void) {
    register int i;
    }
    gives a warning with GCC and -std=c++17
    test.cc: In function ‘void f()’: test.cc:3:15: warning: ISO C++1z does not allow ‘register’ storage class specifier [-Wregister]
    register int i;
    and clang with -std=c++14
    test.cc:3:3: warning: 'register' storage class specifier is deprecated and incompatible with C++1z [-Wdeprecated-register]
    register int i;
    1 warning generated.
    Remove the use of the register keyword at least in the public header files for C++ compatibility. Close #3397.

    3401 - dl06: tms570&#42 Mixed LSB/MSB Error

    Link https://devel.rtems.org/ticket/3401
    Id 3401
    Reporter Joel Sherrill
    Created 17 April 2018 13:54:23
    Modified 14 October 2018 22:06:16
    Owner chrisj@…
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by 3402

    Description

    ld-arm-tms570ls3137_hdk-rtems/arm-rtems5/c/tms570ls3137_hdk/testsuites/libtests'
    rtems-ld -r /home/joel/rtems-work/rtems-testing/rtems/build-arm-tms570ls3137_hdk-rtems/arm-rtems5/c/tms570ls3137_hdk -O rap -b dl06.pre -e rtems_main -s \

    -o dl06.rap dl06-o1.o dl06-o2.o -lm

    error: elf:check_file: /data/home/joel/rtems-work/tools/5/bin/../lib/gcc/arm-rtems5/7.3.0/../../../../arm-rtems5/lib/libc.a:lib_a-_Exit.o@23760: Mixed data types not allowed (LSB/MSB).

    Comment 1
    1. Joel Sherrill, Tue, 17 Apr 2018 13:55:00 GMT
    2. owner: set to chrisj@…
    3. status: changed from new to assigned
    Comment 2
    1. Chris Johns, Wed, 18 Apr 2018 01:29:19 GMT
    2. blockedby: set to 3402
    Comment 3
    1. Joel Sherrill, Sun, 14 Oct 2018 21:57:35 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 632bb17/rtems:

    libtests/Makefile.am: Add CPU_CFLAGS to rtems-ld invocation closes #3401, #3402.
    Comment 4
    1. Joel Sherrill, Sun, 14 Oct 2018 21:59:18 GMT

    In 36fde51/rtems-tools:

    rtemstoolkit/rld-cc.cpp: Accept -EL, -EB, and -Gn machine flags closes #3401, #3402, $3424.
    Comment 5
    1. Joel Sherrill, Sun, 14 Oct 2018 22:06:16 GMT

    In 8992d20/rtems-source-builder:

    rtems-tools-5-1.cfg: Bump to latest closes #3401, #3402, #3424.

    3402 - dl06: mips hurricane Mixed Endian Error

    Link https://devel.rtems.org/ticket/3402
    Id 3402
    Reporter Joel Sherrill
    Created 17 April 2018 13:57:15
    Modified 14 October 2018 22:06:16
    Owner chrisj@…
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3401
    Blocked by  

    Description

    Also occurs on rbtx4925 and rbtx4938

    rtems-ld -r /home/joel/rtems-work/rtems-testing/rtems/build-mips-hurricane-rtems/mips-rtems5/c/hurricane -O rap -b dl06.pre -e rtems_main -s \

    -o dl06.rap dl06-o1.o dl06-o2.o -lm

    error: elf:check_file: /data/home/joel/rtems-work/tools/5/bin/../lib/gcc/mips-rtems5/7.3.0/../../../../mips-rtems5/lib/libc.a:lib_a-_Exit.o@23298: Mixed data types not allowed (LSB/MSB).

    Comment 1
    1. Chris Johns, Wed, 18 Apr 2018 01:15:58 GMT

    Ouch, I will need to think about this one because rtems-ld does not know about mutilib configurations and the BSP has -mips3 -EL as options to the linker.

    Comment 2
    1. Chris Johns, Wed, 18 Apr 2018 01:28:13 GMT

    Looking at the rtemstoolkit/rld-cc.cpp function get_library_path() is asking gcc for the path to a library and if this is being used it may be a simple matter of adding the CFLAGS or CPU_FLAGS to rtems-ld.

    I suspect -E will need to be added to the flag filter list so as a machine flag.

    Comment 3
    1. Chris Johns, Wed, 18 Apr 2018 01:29:19 GMT
    2. blocking: set to 3401
    Comment 4
    1. Joel Sherrill, Sun, 14 Oct 2018 21:57:35 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 632bb17/rtems:

    libtests/Makefile.am: Add CPU_CFLAGS to rtems-ld invocation closes #3401, #3402.
    Comment 5
    1. Joel Sherrill, Sun, 14 Oct 2018 21:59:18 GMT

    In 36fde51/rtems-tools:

    rtemstoolkit/rld-cc.cpp: Accept -EL, -EB, and -Gn machine flags closes #3401, #3402, $3424.
    Comment 6
    1. Joel Sherrill, Sun, 14 Oct 2018 22:06:16 GMT

    In 8992d20/rtems-source-builder:

    rtems-tools-5-1.cfg: Bump to latest closes #3401, #3402, #3424.

    3403 - RSB RTEMS tool set build is irreproducible

    Link https://devel.rtems.org/ticket/3403
    Id 3403
    Reporter Sebastian Huber
    Created 18 April 2018 05:17:25
    Modified 18 April 2018 08:07:30
    Owner Sebastian Huber
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity major
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The RTEMS 5 tool set contains the RTEMS tools (rtems-tools). The version of the RTEMS tools is determined by the tool set build time since the current Git master branch is fetched. Instead use an explicit RTEMS tools version (similar to all other tools, e.g. Binutils, Newlib, GCC, GDB) to make the RTEMS tool set independent of the arbitrary build time.

    Comment 1
    1. Sebastian Huber, Wed, 18 Apr 2018 08:07:30 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 50593d4/rtems-source-builder:

    5: Use a specific RTEMS tools version Download via cgit archive. Close #3403.

    3407 - Move Gaisler.org and Gaisler.se hosted RSB patches to rtems.org

    Link https://devel.rtems.org/ticket/3407
    Id 3407
    Reporter Joel Sherrill
    Created 24 April 2018 22:58:15
    Modified 23 October 2018 21:48:12
    Owner  
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Jiri has suggested that the patches used in the RSB that are hosted by him be moved to rtems.org and the RSB patches link be changed.

    This impacts at least qemu.

    Comment 1
    1. Chris Johns, Wed, 25 Apr 2018 02:21:41 GMT

    Please avoid personal directories on ftp.rtems.org. There are no other accessible paths on that host.

    You can use a ticket and attachments. I cannot see a way to get a txt version of our mailing list archives.

    Comment 2
    1. Chris Johns, Fri, 19 Oct 2018 00:19:07 GMT
    2. owner: chrisj@… deleted

    Can someone else please handle this?

    Comment 3
    1. Joel Sherrill, Tue, 23 Oct 2018 17:05:31 GMT

    I only see this one patch referencing Jiri's servers:

    ./tools/rtems-gdb-7.12-1.cfg:%patch add gdb https://gaisler.org/gdb/gdb-7.12.1-sis-leon2-leon3.diff 

    The current rtems-gdb-8.0.1-1.cfg references a ticket attachment.

    %patch add gdb https://devel.rtems.org/raw-attachment/ticket/3460/gdb-8.0.1-sis-leon2-leon3.diff 

    Is it OK to close this since the current sparc/gdb build doesn't touch his server?

    Comment 4
    1. Chris Johns, Tue, 23 Oct 2018 21:48:12 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Yes it is fine to close this ticket, I will do it. I will clean out the configs on the 5 branch when it is created.


    3409 - Strip down configure checks to the bare minimum

    Link https://devel.rtems.org/ticket/3409
    Id 3409
    Reporter Sebastian Huber
    Created 25 April 2018 13:40:20
    Modified 19 December 2019 08:14:40
    Owner Sebastian Huber
    Type task
    Component build
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    There are a lot of configure checks which produce HAVE_* defines which are no longer used or superfluous since we demand a recent Newlib version anyway.

    Comment 1
    1. Sebastian Huber, Wed, 02 May 2018 07:58:46 GMT

    In b422aa3f/rtems:

    tests: Remove configure feature checks Update #3409.
    Comment 2
    1. Sebastian Huber, Tue, 23 Oct 2018 14:02:37 GMT

    In 3cf12c9/rtems:

    Remove strlcat(), strlcpy(), strsep(), readdir_r() These functions are provided by Newlib since 2002. Update #3409.
    Comment 3
    1. Sebastian Huber, Tue, 23 Oct 2018 14:02:40 GMT

    In 87a9900f/rtems:

    Remove isatty() These functions are provided by Newlib since 2000. Update #3409.
    Comment 4
    1. Sebastian Huber, Tue, 23 Oct 2018 14:02:44 GMT

    In 658ec75/rtems:

    Remove assert() This function is provided by Newlib since 2000. Update #3409.
    Comment 5
    1. Sebastian Huber, Tue, 23 Oct 2018 14:02:47 GMT

    In e161767e/rtems:

    Remove ttyname() This function is provided by Newlib since 2000. Update #3409.
    Comment 6
    1. Sebastian Huber, Tue, 23 Oct 2018 14:02:51 GMT

    In 79d145a7/rtems:

    Remove optional getrusage() declaration Declaration provided by Newlib since 2014. Update #3409.
    Comment 7
    1. Sebastian Huber, Tue, 23 Oct 2018 14:02:54 GMT

    In f59edebf/rtems:

    Remove getcwd() This function is provided by Newlib since 2000. Update #3409.
    Comment 8
    1. Sebastian Huber, Tue, 23 Oct 2018 14:02:58 GMT

    In 167654e/rtems:

    Remove checks for flockfile(), etc. declarations Declarations provided by Newlib since 2002. Update #3409.
    Comment 9
    1. Sebastian Huber, Tue, 23 Oct 2018 14:03:02 GMT

    In 6da1bb0/rtems:

    Remove superfluous configure checks The results of these checks are unused, covered by other checks or check obvious things. Update #3409.
    Comment 10
    1. Sebastian Huber, Tue, 30 Oct 2018 12:34:10 GMT

    In 7e2aabd7/rtems:

    config: Fix check networking This Autoconf macro used cache variables which are not longer present. Update #3409.
    Comment 11
    1. Sebastian Huber, Thu, 19 Dec 2019 08:14:40 GMT
    2. status: changed from assigned to closed
    3. resolution: set to wontfix

    This will be fixed by the new build system, see #3818.


    3410 - Remove bin2boot program used by i386 BSPs

    Link https://devel.rtems.org/ticket/3410
    Id 3410
    Reporter Sebastian Huber
    Created 25 April 2018 13:55:39
    Modified 27 April 2018 05:13:31
    Owner Sebastian Huber
    Type task
    Component arch/i386
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    For which boot loader is this? Can it be removed?

    The sources have no copyright information.

    Comment 1
    1. Sebastian Huber, Fri, 27 Apr 2018 05:13:31 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 3d703f4/rtems:

    bsp/pc386: Remove bin2boot support Update #3408. Close #3410.

    3411 - qemuppc does not install linkcmds.base

    Link https://devel.rtems.org/ticket/3411
    Id 3411
    Reporter Joel Sherrill
    Created 25 April 2018 14:51:14
    Modified 25 April 2018 18:36:17
    Owner Sebastian Huber
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    examples-v2 fail to compile qemuppc because linkcmds.base is not installed.

    They build OK for sparc/erc32. This must be a minor glitch from the build system changes.

    Comment 1
    1. Joel Sherrill, Wed, 25 Apr 2018 14:51:45 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Wed, 25 Apr 2018 18:36:17 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In b3e5aa5/rtems:

    bsp/qemuppc: Install linkcmds.base Update #3339. Close #3411.

    3413 - examples-v2 both_hello and triple_period fail to build

    Link https://devel.rtems.org/ticket/3413
    Id 3413
    Reporter Joel Sherrill
    Created 25 April 2018 21:47:30
    Modified 19 December 2019 13:47:44
    Owner Sebastian Huber
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    examples-v2 doesn't build for qemuppc. both_hello fails because of something going on with rtems-ld. Taking that out of the wscript results in getting further but fails with an undefined error for the same symbol.

    /home/joel/rtems-work/tools/5/bin/powerpc-rtems5-gcc: hello-deep.o: In function `wrapThread_Life_action_handler':
    /home/joel/rtems-work/tools/5/bin/powerpc-rtems5-gcc: /home/joel/rtems-work/examples-v2/build/powerpc-rtems5-qemuppc/ hello-deep.c:1304: undefined reference to `_Thread_Life_action_handler'
    /home/joel/rtems-work/tools/5/bin/powerpc-rtems5-gcc: collect2: error: ld returned 1 exit status

    error: linking: Linker error

    Comment 1
    1. Chris Johns, Thu, 26 Apr 2018 03:33:03 GMT

    The score thread definition files have not been updated after a change in the score:

    ​https://git.rtems.org/rtems-tools/tree/linkers/rtems-score-thread.ini#n8

    which is referenced from:

    ​https://git.rtems.org/examples-v2/tree/hello/both_hello/hello-deep.ini#n21

    I am OK with a change to remove the definition being pushed.

    Note, adding libdwarf support to rtems-tools would remove the need for these files.

    Please remember rtems-tools repo changes require an RSB update to have the RSB pick up any changes.

    Comment 2
    1. Sebastian Huber, Thu, 19 Dec 2019 09:09:45 GMT

    In 7045cc3/rtems-tools:

    linkers: Remove _Thread_Life_action_handler This is a static function. Update #3413.
    Comment 3
    1. Sebastian Huber, Thu, 19 Dec 2019 09:14:21 GMT

    In f484118/rtems-source-builder:

    5: Update rtems-tools Update #3413.
    Comment 4
    1. Sebastian Huber, Thu, 19 Dec 2019 09:23:53 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    I was able to build the examples with these patches.

    Comment 5
    1. Joel Sherrill, Thu, 19 Dec 2019 13:47:44 GMT

    It really would be better to have dynamic loading examples in rtems-examples rather than just bolting on some odd build stuff to an unrelated example. Neither both_hello or triple_period are intended to demonstrate dynamic loading and don't use it.


    3415 - Add examples and tests as components

    Link https://devel.rtems.org/ticket/3415
    Id 3415
    Reporter Joel Sherrill
    Created 25 April 2018 23:53:32
    Modified 13 October 2018 22:27:53
    Owner Chris Johns
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    It seems as if we should have tests and examples as components.

    Comment 1
    1. Joel Sherrill, Wed, 25 Apr 2018 23:54:01 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Sat, 13 Oct 2018 22:27:53 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Test and examples have been added.


    3416 - Update Ubuntu RSB Instructions for 17.10

    Link https://devel.rtems.org/ticket/3416
    Id 3416
    Reporter Joel Sherrill
    Created 26 April 2018 18:29:05
    Modified 12 December 2019 22:24:30
    Owner Joel Sherrill <joel@…>
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The command in 3.1.5 of the RSB guide for Ubuntu seems to work for 17.10 but on at least one system gives the error:

    Error :: You must put some 'source' URIs in your sources.list

    A description of how to address this is at:

    ​https://askubuntu.com/questions/496549/error-you-must-put-some-source-uris-in-your-sources-list

    Perhaps this would be useful info to update the RSB guide with (updated Ubuntu works + hint)

    Attachments:

    1 Marçal Comajoan Cara, Sun, 11 Nov 2018 16:47:43 GMT
      attach: set to 0001-Update-list-of-required-packages-for-building-on-Ubu.patch
    Comment 1
    1. Chris Johns, Sun, 14 Oct 2018 01:08:44 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to accepted
    Comment 2
    1. Chris Johns, Fri, 19 Oct 2018 00:25:12 GMT
    2. owner: Chris Johns deleted
    3. status: changed from accepted to new

    I do not user Ubuntu. A user would be the best person to do this as they can test it.

    Comment 3
    1. Marçal Comajoan Cara, Sun, 11 Nov 2018 16:47:06 GMT

    I tried building RTEMS on Ubuntu 18.04 and it worked great with the packages installed by using only this command:

    __Error: Failed to load processor bash__
    No macro or processor named 'bash' found

    This package list is based on the output of sb-check and error messages I got during the installation which I corrected installing the packages above. This probably also works for Ubuntu 17.10 but 18.04 is more important because it's LTS while 17.10 not. Because of this, Ubuntu 17.10 is also unsupported since July 19, 2018.

    I also think that the part which mentions Xubuntu (the Xfce Ubuntu flavour) is redundant because every official Ubuntu flavour has the same base packages (the packages that change from flavour to flavour are the desktop environment related ones like the file managers, graphical text editors, etc. but usually not development packages like the ones that are required to build RTEMS). The id in the link (​https://docs.rtems.org/branches/master/user/hosts/posix.html#xubuntu <-), also should be ubuntu instead of xubuntu.

    With the patch attached here I fixed and updated everything.

    Comment 4
    1. Joel Sherrill, Thu, 12 Dec 2019 22:24:13 GMT

    The documentation changes did not include information on "Error :: You must put some 'source' URIs in your sources.list" being reported. As this occurred on an Ubuntu version that was not LTS, it is not being added. If this error occurs in the future on a LTS release, then add this information.

    Comment 5
    1. Joel Sherrill, Thu, 12 Dec 2019 22:24:30 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 9316722/rtems-docs:

    user/hosts/posix.rst: Update Ubuntu instructions. Note that the ticket has instructions for what to do if the error message "Error :: You must put some 'source' URIs in your sources.list" is reported. As this occurred on an Ubuntu version that was not LTS, it is not being added. If this error occurs in the future on a LTS release, then add this information. closes #3416.

    3417 - Add libdwarf to elftoolchain and provide a C++ wrapper

    Link https://devel.rtems.org/ticket/3417
    Id 3417
    Reporter Chris Johns
    Created 29 April 2018 01:58:27
    Modified 19 October 2018 00:23:15
    Owner Chris Johns
    Type enhancement
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Update the elftoolchain and add libdwarf.

    Provide a C++ framework to create reusable access to libdwarf.

    Comment 1
    1. Chris Johns, Sun, 29 Apr 2018 01:58:46 GMT
    2. type: changed from defect to enhancement
    Comment 2
    1. Chris Johns, Sun, 29 Apr 2018 02:10:28 GMT

    In 0c5db2d/rtems-tools:

    rtemstoolkit: Update elftoolchain to the latest code. The update is taken from ​https://github.com/elftoolchain/elftoolchain. Update #3417
    Comment 3
    1. Chris Johns, Mon, 30 Apr 2018 05:51:44 GMT

    In 771e7f1/rtems-tools:

    rtemstoolkit: Update elftoolchain to the latest code. The update is taken from:
    ​https://svn.code.sf.net/p/elftoolchain/code/trunk
    Update #3417
    Comment 4
    1. Chris Johns, Mon, 30 Apr 2018 05:51:55 GMT

    In 4bb3996/rtems-tools:

    rtemstoolkit: Add libdwarf from elftoolchain. The code is taken from:
    ​https://svn.code.sf.net/p/elftoolchain/code/trunk
    Update #3417
    Comment 5
    1. Chris Johns, Tue, 19 Jun 2018 03:42:41 GMT

    In 558cab8/rtems-tools:

    rtemstoolkit: Add libdwarf C++ interface. Provide a C++ interface to libdwarf to: Manage DWARF debug data Manage CU Manage DIE Handle CU line addresses Handle CU source files Update #3417
    Comment 6
    1. Chris Johns, Fri, 19 Oct 2018 00:23:15 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    The wrapper has been added to rtems-tools.


    3418 - Remove difftest and sorttimes test tools

    Link https://devel.rtems.org/ticket/3418
    Id 3418
    Reporter Sebastian Huber
    Created 30 April 2018 06:12:18
    Modified 2 May 2018 07:58:57
    Owner Sebastian Huber
    Type task
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Evaluation of test results and report generation should move to somewhere else, e.g. the RTEMS tester.

    Comment 1
    1. Sebastian Huber, Wed, 02 May 2018 07:58:57 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 397df7a/rtems:

    tests: Remove difftest and sorttimes tools Close #3418.

    3419 - Always build network services (tftpfs, ftpfs, ftpd, telnetd, libdebugger)

    Link https://devel.rtems.org/ticket/3419
    Id 3419
    Reporter Sebastian Huber
    Created 30 April 2018 07:15:30
    Modified 8 May 2018 06:07:02
    Owner Sebastian Huber
    Type enhancement
    Component network/legacy
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Always build network services (tftpfs, ftpfs, ftpd, telnetd, libdebugger) which only depend on the POSIX socket API (provided by Newlib header files) as support libraries. Remove them from libbsd.

    The network services must reside in dedicated libraries to avoid a cyclic dependency between libbsd.a and librtemscpu.a.

    Comment 1
    1. Sebastian Huber, Wed, 02 May 2018 07:59:18 GMT

    In dd8e4b7/rtems:

    libdebugger: Move to separate library Always build remote TCP support since it depends only on the POSIX socket API. It works with the legacy network stack and libbsd. Move it to a separate libdebugger.a library to allow an easy use with libbsd via "-ldebugger -lbsd" otherwise we would have a cyclic dependency between libbsd.a and librtemscpu.a. Update #3419.
    Comment 2
    1. Sebastian Huber, Wed, 02 May 2018 07:59:28 GMT

    In c3bab73b/rtems:

    tftpfs: Always build TFTP client Move TFTP client filesystem to separate library libtftpfs.a. Conditionally use legacy network stack features, e.g. BOOTP support. Update #3419.
    Comment 3
    1. Sebastian Huber, Wed, 02 May 2018 07:59:39 GMT

    In fea9a7a/rtems:

    ftpfs: Always build FTP client Move FTP client filesystem to separate library libftpfs.a. Update #3419.
    Comment 4
    1. Sebastian Huber, Wed, 02 May 2018 07:59:49 GMT

    In bf76d5f/rtems:

    network: Import latest from FreeBSD Update #3419.
    Comment 5
    1. Sebastian Huber, Wed, 02 May 2018 08:00:00 GMT

    In 4fed5ac/rtems:

    ftpd: Fairplay with libbsd Update #3419.
    Comment 6
    1. Sebastian Huber, Wed, 02 May 2018 08:00:10 GMT

    In 32b5b23/rtems:

    ftpd: Use floating-point tasks due to syslog() Update #3419.
    Comment 7
    1. Sebastian Huber, Wed, 02 May 2018 08:00:20 GMT

    In b771cb4/rtems:

    ftpd: Always build FTP daemon Add support for libbsd initialization. Update #3419.
    Comment 8
    1. Sebastian Huber, Wed, 02 May 2018 08:00:31 GMT

    In b80b34c3/rtems:

    telnetd: Always build telnet daemon Add support for libbsd initialization. Update #3419.
    Comment 9
    1. Sebastian Huber, Wed, 02 May 2018 08:00:41 GMT

    In 8d52a0e2/rtems:

    telnetd: Use syslog() instead of printk() Update #3419.
    Comment 10
    1. Sebastian Huber, Wed, 02 May 2018 08:01:29 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 443a058/rtems-libbsd:

    Use network services from RTEMS Close #3419.
    Comment 11
    1. Sebastian Huber, Wed, 02 May 2018 08:37:00 GMT

    In 634b3bf/rtems-libbsd:

    rtems-debugger: Remove files They are now in the main RTEMS sources. Update #3419.
    Comment 12
    1. Chris Johns, Thu, 03 May 2018 02:21:40 GMT

    Does this change require user applications update their list of libraries linked to use the services moved to separate libraries?

    Comment 13
    1. Sebastian Huber, Thu, 03 May 2018 05:25:55 GMT

    Yes, the old network stack already had libftpd.a and libtelnetd.a. In the libbsd it was previously included. The libtftpfs.a and libftpfs.a are new. The debugger support with libdebugger.a will be new in RTEMS 5.1.

    Comment 14
    1. Chris Johns, Thu, 03 May 2018 05:39:58 GMT

    Thank you. I just wanted this noted for the release notes.

    Comment 15
    1. Christian Mauderer, Fri, 04 May 2018 05:16:48 GMT

    In dd35ec5/rtems-libbsd:

    waf: Allow to add libs per test. Update #3419.
    Comment 16
    1. Sebastian Huber, Tue, 08 May 2018 06:07:02 GMT

    In eaa1709/rtems:

    ftpd: Fix infinite recursion in yield() Update #3419.

    3421 - New Trac components for Coverage and Trace

    Link https://devel.rtems.org/ticket/3421
    Id 3421
    Reporter Joel Sherrill
    Created 30 April 2018 23:21:24
    Modified 13 October 2018 22:29:02
    Owner chrisj@…
    Type defect
    Component admin
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Both coverage and tracing are large enough areas that lumping them into tools or other random categories makes work on them harder to trac.

    Please add coverage and tracing. Coverage could be a subcategory of tools.T Tracing could be a standalone component. It has target and tool components.

    Comment 1
    1. Joel Sherrill, Sat, 13 Oct 2018 22:29:02 GMT
    2. status: changed from assigned to closed
    3. resolution: set to wontfix

    These should be filed as tool with an appropriate keyword.


    3423 - examples-v2: m68k/powerpc BSPs undefined reference to _Thread_Life_action_handler

    Link https://devel.rtems.org/ticket/3423
    Id 3423
    Reporter Joel Sherrill
    Created 1 May 2018 14:36:26
    Modified 2 May 2018 00:30:39
    Owner  
    Type defect
    Component admin
    Status closed
    Resolution duplicate
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    fat_ramdisk is failing to link on multiple m68k and powerpc BSPs. Errors below the list of BSPs

    m68k-av5282
    m68k-gen68340
    m68k-gen68360
    m68k-gen68360_040
    m68k-mcf5206elite
    m68k-mcf52235
    m68k-mcf5225x
    m68k-mcf5235
    m68k-mcf5329
    m68k-mrm332
    m68k-pgh360
    m68k-uC5282
    powerpc-mpc8260ads
    powerpc-qemuppc
    powerpc-qoriq_e6500_64
    powerpc-ss555

    [20/20] Processing rtrace: build/m68k-rtems5-av5282/filesystem/fat_ramdisk/init.c.4.o build/m68k-rtems5-av5282/filesystem/fat_ramdisk/fs-root-tar.c.4.o -> build/m68k-rtems5-av5282/filesystem/fat_ramdisk/fat_ramdisk.texe
    /home/joel/rtems-work/tools/5/bin/m68k-rtems5-gcc: /tmp/ccIRjaaa.o: In function `__wrap__Thread_Life_action_handler':
    /home/joel/rtems-work/tools/5/bin/m68k-rtems5-gcc: /tmp/cckrhaaa.c:1248: undefined reference to `_Thread_Life_action_handler'
    /home/joel/rtems-work/tools/5/bin/m68k-rtems5-gcc: collect2: error: ld returned 1 exit status
    error: linking: Linker error
    Comment 1
    1. Chris Johns, Wed, 02 May 2018 00:24:47 GMT
    2. description: modified (diff)
    Comment 2
    1. Chris Johns, Wed, 02 May 2018 00:29:00 GMT
    2. status: changed from new to closed
    3. resolution: set to duplicate

    This is the a duplicate of #3413 so I am closing it. The solution is in that ticket.

    Comment 3
    1. Joel Sherrill, Wed, 02 May 2018 00:30:39 GMT

    #3413 should be updated with the list of BSPs which fail.


    3424 - examples-v2: no MIPS BSPs pass configuration step

    Link https://devel.rtems.org/ticket/3424
    Id 3424
    Reporter Joel Sherrill
    Created 1 May 2018 14:44:24
    Modified 14 October 2018 22:06:16
    Owner Joel Sherrill
    Type defect
    Component examples
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Checking for program 'ar'                  : /home/joel/rtems-work/tools/5/bin/mips-rtems5-ar
    Checking for program 'g++, c++' : /home/joel/rtems-work/tools/5/bin/mips-rtems5-g++
    Checking for program 'ar' : /home/joel/rtems-work/tools/5/bin/mips-rtems5-ar
    Checking for program 'gas, gcc' : /home/joel/rtems-work/tools/5/bin/mips-rtems5-gcc
    Checking for program 'ar' : /home/joel/rtems-work/tools/5/bin/mips-rtems5-ar
    Compiler version (mips-rtems5-gcc) : 7.3.0 20180125 (RTEMS 5, RSB 6d9c77c77d271d1fc2dfe8493d6713930b52a6dd, Newlib 3.0.0)
    Checking for RTEMS CPU options header : started
    -> processing test results : 1 test failed
    One of the tests has failed, read config.log for more information
    (complete log in /data/home/joel/rtems-work/examples-v2/build/config.log)
    + check_fatal 1 'failed waf configure - examples-v2 on rbtx4925'
    Comment 1
    1. Chris Johns, Wed, 02 May 2018 00:31:06 GMT

    The check for RTEMS CPU options header fails. Does the BSP install rtems/score/cpuopts.h?

    Comment 2
    1. Chris Johns, Wed, 02 May 2018 00:33:52 GMT
    2. description: modified (diff)

    Also the output says to read config.log for more information. Could you please report what it says is failing?

    Comment 3
    1. Joel Sherrill, Sat, 13 Oct 2018 22:34:50 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    4. component: changed from admin to examples
    Comment 4
    1. Joel Sherrill, Sun, 14 Oct 2018 20:52:58 GMT

    With the Makefile.inc system, all tests build successfully and this is the command sequence for hello_world_c

    mips-rtems5-gcc --pipe -B/home/joel/rtems-work/tools/5/bsp-install/mips-rtems5/rbtx4925/lib/ -specs bsp_specs -qrtems   -Wall  -O2 -g -fomit-frame-pointer -ffunction-sections -fdata-sections    -mips3 -G0 -EL       -c   -o o-optimize/test.o test.c
    mips-rtems5-gcc --pipe -B/home/joel/rtems-work/tools/5/bsp-install/mips-rtems5/rbtx4925/lib/ -specs bsp_specs -qrtems   -Wall  -O2 -g -fomit-frame-pointer -ffunction-sections -fdata-sections    -mips3 -G0 -EL      -Wl,--gc-sections   -mips3 -G0 -EL   -o o-optimize/hello.exe  o-optimize/test.o 

    With the following waf command, the configure fails:

     ./waf configure --rtems=/home/joel/rtems-work/tools/5/bsp-install \
      --rtems-tools=/home/joel/rtems-work/tools/5 --rtems-bsps=mips/rbtx4925 

    The test probe gcc is this:

    ['/home/joel/rtems-work/tools/5/bin/mips-rtems5-g++', '-qrtems', '-B/home/joel/rtems-work/tools/5/bsp-install/mips-rtems5/lib/', '-B/home/joel/rtems-work/tools/5/bsp-install/mips-rtems5/rbtx4925/lib/', '--specs', 'bsp_specs', '-mips3', '-mips3', '-fomit-frame-pointer', '-fomit-frame-pointer', '-ffunction-sections', '-ffunction-sections', '-fdata-sections', '-fdata-sections', 'test.cpp.1.o', '-o/home/joel/rtems-work/examples-v2/build/.conf_check_2580b0f878d416be57b9cf3634e02230/testbuild/testprog', '-Wl,-Bstatic', '-Wl,-Bdynamic']
    err: /home/joel/rtems-work/tools/5/lib/gcc/mips-rtems5/7.3.0/../../../../mips-rtems5/bin/ld: /home/joel/rtems-work/tools/5/bsp-install/mips-rtems5/rbtx4925/lib/start.o: compiled for a little endian system and target is big endian 

    Notice the -G0 and -EL (or -EB) are missing.

    Comment 5
    1. Joel Sherrill, Sun, 14 Oct 2018 21:16:34 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 2fec1c5/rtems_waf:

    rtems.py: Pass -EL, -EB, and -Gn to link phase closes #3424.
    Comment 6
    1. Joel Sherrill, Sun, 14 Oct 2018 21:20:39 GMT

    In 5e3264d/examples-v2:

    rtems_waf: Update to get #3424
    Comment 7
    1. Joel Sherrill, Sun, 14 Oct 2018 22:06:16 GMT

    In 8992d20/rtems-source-builder:

    rtems-tools-5-1.cfg: Bump to latest closes #3401, #3402, #3424.

    3425 - examples-v2: PowerPC fails to build fat_ramdisk

    Link https://devel.rtems.org/ticket/3425
    Id 3425
    Reporter Joel Sherrill
    Created 1 May 2018 14:57:39
    Modified 11 June 2018 12:48:21
    Owner  
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    beatnik, gwlcfm, haleakala, mpc5566evb, mpc5566evb_spe, mpc5566evb_spe, mpc5643l_evb, mpc5668g, mpc5674f_ecu508_app, mpc5674f_ecu508_boot, mpc5674fevb, mpc5674fevb_spe, mpc5674f_rsm6, mvme3100, mvme3100, phycore_mpc5554, qemuprep-altivec, qemuprep

    [5/7] Compiling build/powerpc-rtems5-beatnik/filesystem/fat_ramdisk/fs-root.tar
    In file included from /home/joel/rtems-work/bsp-install//powerpc-rtems5/beatnik/lib/include/libcpu/powerpc-utility.h:40:0,
    from /home/joel/rtems-work/bsp-install//powerpc-rtems5/beatnik/lib/include/bsp/vectors.h:40,
    from /home/joel/rtems-work/bsp-install//powerpc-rtems5/beatnik/lib/include/bsp.h:27,
    from ../../gdb/overwrite/rtems_init.c:7:
    /home/joel/rtems-work/bsp-install//powerpc-rtems5/beatnik/lib/include/rtems/powerpc/powerpc.h:283:2: error: #error "Unsupported CPU Model"
    #error "Unsupported CPU Model"
    ^~~~~
    In file included from /home/joel/rtems-work/bsp-install//powerpc-rtems5/beatnik/lib/include/libcpu/powerpc-utility.h:40:0,
    from /home/joel/rtems-work/bsp-install//powerpc-rtems5/beatnik/lib/include/bsp/vectors.h:40,
    from /home/joel/rtems-work/bsp-install//powerpc-rtems5/beatnik/lib/include/bsp.h:27,
    from ../../hello/hello_world_c/test.c:21:
    /home/joel/rtems-work/bsp-install//powerpc-rtems5/beatnik/lib/include/rtems/powerpc/powerpc.h:283:2: error: #error "Unsupported CPU Model"
    #error "Unsupported CPU Model"
    ^~~~~
    Waf: Leaving directory `/data/home/joel/rtems-work/examples-v2/build/powerpc-rtems5-beatnik'
    Build failed
    Comment 1
    1. Chris Johns, Wed, 02 May 2018 00:38:16 GMT
    2. description: modified (diff)

    Please run with -v and have a look at the command line and compare it to a similar compile in the testsuite? Is there something in the BSP configuration that is not being set in the BSP's pkg-config file?

    Comment 2
    1. Joel Sherrill, Wed, 02 May 2018 17:09:51 GMT

    From waf -v

    [1/7] Compiling hello/hello_world_c/test.c
    12:04:58 runner ['/home/joel/rtems-work/tools/5/bin/powerpc-rtems5-gcc', '-qrtems', '-B/home/joel/rtems-work/bsp-install//powerpc-rtems5/lib/', '-B/home/joel/rtems-work/bsp-install//powerpc-rtems5/mpc5566evb/lib/', '--specs', 'bsp_specs', '-mcpu=8540', '-mcpu=8540', '-meabi', '-meabi', '-msdata=sysv', '-msdata=sysv', '-fno-common', '-fno-common', '-msoft-float', '-msoft-float', '-mno-spe', '-mno-spe', '-mstrict-align', '-mstrict-align', '-fno-keep-inline-functions', '-fno-keep-inline-functions', '-ffunction-sections', '-ffunction-sections', '-fdata-sections', '-fdata-sections', '-O2', '-g', '-DHAVE_RTEMS_SCORE_CPUOPTS_H=1', '-DHAVE_RTEMS_H=1', '../../hello/hello_world_c/test.c', '-c', '-o/data/home/joel/rtems-work/examples-v2/build/powerpc-rtems5-mpc5566evb/hello/hello_world_c/test.c.1.o']
    [2/7] Compiling gdb/overwrite/rtems_init.c
    12:04:58 runner ['/home/joel/rtems-work/tools/5/bin/powerpc-rtems5-gcc', '-qrtems', '-B/home/joel/rtems-work/bsp-install//powerpc-rtems5/lib/', '-B/home/joel/rtems-work/bsp-install//powerpc-rtems5/mpc5566evb/lib/', '--specs', 'bsp_specs', '-mcpu=8540', '-mcpu=8540', '-meabi', '-meabi', '-msdata=sysv', '-msdata=sysv', '-fno-common', '-fno-common', '-msoft-float', '-msoft-float', '-mno-spe', '-mno-spe', '-mstrict-align', '-mstrict-align', '-fno-keep-inline-functions', '-fno-keep-inline-functions', '-ffunction-sections', '-ffunction-sections', '-fdata-sections', '-fdata-sections', '-O2', '-g', '-DHAVE_RTEMS_SCORE_CPUOPTS_H=1', '-DHAVE_RTEMS_H=1', '../../gdb/overwrite/rtems_init.c', '-c', '-o/data/home/joel/rtems-work/examples-v2/build/powerpc-rtems5-mpc5566evb/gdb/overwrite/rtems_init.c.1.o']
    In file included from /home/joel/rtems-work/bsp-install//powerpc-rtems5/mpc5566evb/lib/include/libcpu/powerpc-utility.h:40:0,
                     from /home/joel/rtems-work/bsp-install//powerpc-rtems5/mpc5566evb/lib/include/bsp.h:39,
                     from ../../hello/hello_world_c/test.c:21:
    /home/joel/rtems-work/bsp-install//powerpc-rtems5/mpc5566evb/lib/include/rtems/powerpc/powerpc.h:283:2: error: #error "Unsupported CPU Model"
     #error "Unsupported CPU Model"
      ^~~~~
    In file included from /home/joel/rtems-work/bsp-install//powerpc-rtems5/mpc5566evb/lib/include/libcpu/powerpc-utility.h:40:0,
                     from /home/joel/rtems-work/bsp-install//powerpc-rtems5/mpc5566evb/lib/include/bsp.h:39,
                     from ../../gdb/overwrite/rtems_init.c:7:
    /home/joel/rtems-work/bsp-install//powerpc-rtems5/mpc5566evb/lib/include/rtems/powerpc/powerpc.h:283:2: error: #error "Unsupported CPU Model"
     #error "Unsupported CPU Model"
      ^~~~~
    Waf: Leaving directory `/data/home/joel/rtems-work/examples-v2/build/powerpc-rtems5-mpc5566evb'
    Build failed
     -> task in 'hello.exe' failed with exit status 1:
            {task 21579488: c test.c -> test.c.1.o}
    ['/home/joel/rtems-work/tools/5/bin/powerpc-rtems5-gcc', '-qrtems', '-B/home/joel/rtems-work/bsp-install//powerpc-rtems5/lib/', '-B/home/joel/rtems-work/bsp-install//powerpc-rtems5/mpc5566evb/lib/', '--specs', 'bsp_specs', '-mcpu=8540', '-mcpu=8540', '-meabi', '-meabi', '-msdata=sysv', '-msdata=sysv', '-fno-common', '-fno-common', '-msoft-float', '-msoft-float', '-mno-spe', '-mno-spe', '-mstrict-align', '-mstrict-align', '-fno-keep-inline-functions', '-fno-keep-inline-functions', '-ffunction-sections', '-ffunction-sections', '-fdata-sections', '-fdata-sections', '-O2', '-g', '-DHAVE_RTEMS_SCORE_CPUOPTS_H=1', '-DHAVE_RTEMS_H=1', '../../hello/hello_world_c/test.c', '-c', '-o/data/home/joel/rtems-work/examples-v2/build/powerpc-rtems5-mpc5566evb/hello/hello_world_c/test.c.1.o']
     -> task in 'overwrite.exe' failed with exit status 1:
            {task 21579848: c rtems_init.c -> rtems_init.c.1.o}
    ['/home/joel/rtems-work/tools/5/bin/powerpc-rtems5-gcc', '-qrtems', '-B/home/joel/rtems-work/bsp-install//powerpc-rtems5/lib/', '-B/home/joel/rtems-work/bsp-install//powerpc-rtems5/mpc5566evb/lib/', '--specs', 'bsp_specs', '-mcpu=8540', '-mcpu=8540', '-meabi', '-meabi', '-msdata=sysv', '-msdata=sysv', '-fno-common', '-fno-common', '-msoft-float', '-msoft-float', '-mno-spe', '-mno-spe', '-mstrict-align', '-mstrict-align', '-fno-keep-inline-functions', '-fno-keep-inline-functions', '-ffunction-sections', '-ffunction-sections', '-fdata-sections', '-fdata-sections', '-O2', '-g', '-DHAVE_RTEMS_SCORE_CPUOPTS_H=1', '-DHAVE_RTEMS_H=1', '../../gdb/overwrite/rtems_init.c', '-c', '-o/data/home/joel/rtems-work/examples-v2/build/powerpc-rtems5-mpc5566evb/gdb/overwrite/rtems_init.c.1.o'] 

    Looks like the -D option from the CPU_CFLAGS is missing and many of the options are duplicated.

    CPU_CFLAGS = -mcpu=8540 -meabi -msdata=sysv -fno-common $(CPU_CFLAGS_FLOAT) \
        -D__ppc_generic -mstrict-align 
    Comment 3
    1. Chris Johns, Thu, 03 May 2018 02:25:09 GMT

    Thank you, it is what I suspected. There are BSPs where something special or different is happening. It highlights the issue with BSP configurations in a format like make.

    If we can collect what we need to have on the CFLAGS in the .pc files I can look at fixing it.

    Comment 4
    1. Joel Sherrill, Mon, 07 May 2018 20:07:13 GMT

    The underlying problem is that the rtems_waf application support eats a few gcc arguments that are needed to build applications. In this case it is -Dxxx where xxx is a macro indicating PowerPC type.

    The proper solution to this is to ban use of -D in the required BSP CFLAGS. We should not require a -D to be specified on the application command line to either compiler correctly or at all.

    This impacts some PowerPC BSPs and defining the expected symbol in bsp.h will work based on this traceback.

    In file included from /home/joel/rtems-work/bsp-install__powerpc-rtems5/mpc5566evb/lib/include/libcpu/powerpc-utility.h:40:0, __

    from /home/joel/rtems-work/bsp-install__powerpc-rtems5/mpc5566evb/lib/include/bsp.h:39, from ../../gdb/overwrite/rtems_init.c:7:

    /home/joel/rtems-work/bsp-install__powerpc-rtems5/mpc5566evb/lib/include/rtems/powerpc/powerpc.h:283:2: error: #error "Unsupported CPU Model"

    #error "Unsupported CPU Model"

    My solution is to move the -D in impacted PowerPC BSPs from CFLAGS (or CPU_CFLAGS) to bsp.h

    Comment 5
    1. Chris Johns, Mon, 07 May 2018 21:04:02 GMT

    Replying to Joel Sherrill:

    My solution is to move the -D in impacted PowerPC BSPs from CFLAGS (or CPU_CFLAGS) to bsp.h

    I agree, applications should only be required to match some machine related flags to make sure the correct ABI is being used.

    Comment 6
    1. Sebastian Huber, Tue, 08 May 2018 07:37:02 GMT

    There are a couple of BSPs which use -D flags:

    grep -- -D bsps/*/*/config/*
    bsps/arm/rtl22xx/config/rtl22xx_t.cfg:#CPU_CFLAGS += -mthumb-interwork -D __THUMB_INTERWORK__ -mthumb
    bsps/arm/rtl22xx/config/rtl22xx_t.cfg:#CPU_ASFLAGS += -D __THUMB_INTERWORK__  -mthumb-interwork
    bsps/arm/smdk2410/config/smdk2410.cfg:CPU_CFLAGS = -mcpu=arm920t -DCPU_S3C2410
    bsps/powerpc/beatnik/config/beatnik.cfg:CPU_CFLAGS = -mcpu=7400 -D__ppc_generic
    bsps/powerpc/haleakala/config/haleakala.cfg:CPU_CFLAGS = -mcpu=405 -Dppc405
    bsps/powerpc/motorola_powerpc/config/mcp750.cfg:CPU_CFLAGS = -mcpu=750 -Dmpc750
    bsps/powerpc/motorola_powerpc/config/mtx603e.cfg:CPU_CFLAGS = -mcpu=603e -Dppc603e
    bsps/powerpc/motorola_powerpc/config/mvme2100.cfg:CPU_CFLAGS = -mcpu=603e -Dppc603e
    bsps/powerpc/motorola_powerpc/config/qemuprep-altivec.cfg:CPU_CFLAGS = -mcpu=7400 -mmultiple -mstring -mstrict-align -D__ppc_generic
    bsps/powerpc/motorola_powerpc/config/qemuprep.cfg:CPU_CFLAGS = -mcpu=powerpc -mmultiple -mstring -mstrict-align -D__ppc_generic
    bsps/powerpc/mpc55xxevb/config/mpc55xx.inc:    -D__ppc_generic -mstrict-align
    bsps/powerpc/mpc8260ads/config/mpc8260ads.cfg:CPU_CFLAGS = -mcpu=603e -mstrict-align -Dmpc8260 \
    bsps/powerpc/mvme3100/config/mvme3100.cfg:CPU_CFLAGS = -mcpu=powerpc -msoft-float -D__ppc_generic
    bsps/powerpc/mvme5500/config/mvme5500.cfg:CPU_CFLAGS = -mcpu=7450 -mtune=7450 -Dmpc7455
    bsps/powerpc/psim/config/psim.cfg:CPU_CFLAGS = -meabi -mcpu=603e -msdata=sysv -fno-common -Dppc603e
    bsps/powerpc/qemuppc/config/qemuppc.cfg:CPU_CFLAGS = -mcpu=603e  -Dppc603e
    bsps/powerpc/qoriq/config/qoriq_e6500_32.cfg:   -D__ppc_generic
    bsps/powerpc/qoriq/config/qoriq_e6500_64.cfg:   -D__ppc_generic
    bsps/powerpc/qoriq/config/qoriq.inc:    -D__ppc_generic
    bsps/powerpc/ss555/config/ss555.cfg:CPU_CFLAGS = -mcpu=$(GCC_CPU_MODEL) -Dmpc555
    bsps/powerpc/t32mppc/config/t32mppc.cfg:        -D__ppc_generic
    bsps/powerpc/tqm8xx/config/tqm8xx.inc:CPU_CFLAGS = -mcpu=860 -Dmpc860 \
    bsps/powerpc/virtex4/config/virtex4.cfg:CPU_CFLAGS = -mcpu=405 -Dppc405
    bsps/powerpc/virtex5/config/virtex5.cfg:CPU_CFLAGS = -mcpu=440 -Dppc440 -msoft-float
    bsps/powerpc/virtex/config/virtex.cfg:CPU_CFLAGS = -mcpu=403 -Dppc405 -meabi -msdata=sysv -fno-common
    bsps/sparc64/niagara/config/niagara.cfg:CPU_CFLAGS = -mcpu=niagara -DSUN4V
    bsps/sparc64/usiii/config/usiii.cfg:CPU_CFLAGS = -mcpu=ultrasparc3 -DUS3 -DSUN4U 

    We should ban the use of command line defines.

    Getting rid of the -D__ppc_generic is easy. Getting rid of the -Dppc405, etc. is more difficult and there is some interaction with the GCC specs:

    #undef CPP_OS_DEFAULT_SPEC
    `#define CPP_OS_DEFAULT_SPEC "\`
    %{!mcpu*:  %{!Dppc*: %{!Dmpc*: -Dmpc750} } }\
    %{mcpu=403:  %{!Dppc*: %{!Dmpc*: -Dppc403}  } } \
    %{mcpu=505:  %{!Dppc*: %{!Dmpc*: -Dmpc505}  } } \
    %{mcpu=601:  %{!Dppc*: %{!Dmpc*: -Dppc601}  } } \
    %{mcpu=602:  %{!Dppc*: %{!Dmpc*: -Dppc602}  } } \
    %{mcpu=603:  %{!Dppc*: %{!Dmpc*: -Dppc603}  } } \
    %{mcpu=603e: %{!Dppc*: %{!Dmpc*: -Dppc603e} } } \
    %{mcpu=604:  %{!Dppc*: %{!Dmpc*: -Dmpc604}  } } \
    %{mcpu=750:  %{!Dppc*: %{!Dmpc*: -Dmpc750}  } } \
    %{mcpu=821:  %{!Dppc*: %{!Dmpc*: -Dmpc821}  } } \
    %{mcpu=860:  %{!Dppc*: %{!Dmpc*: -Dmpc860}  } } \
    %{mcpu=8540: %{!Dppc*: %{!Dmpc*: -Dppc8540}  } } \
    %{mcpu=e6500: -D__PPC_CPU_E6500__}" 
    Comment 7
    1. Joel Sherrill, Tue, 08 May 2018 22:35:29 GMT

    In 2a1171d8/rtems:

    rtl22xx_t.cfg: Remove comment with -D THUMB_INTERWORK Updates #3425.
    Comment 8
    1. Joel Sherrill, Thu, 10 May 2018 22:25:29 GMT

    In c8dcdf54/rtems:

    sparc64 niagara, usiii: Remove -D options from cfg file and move to bspopts.h Updates #3425.
    Comment 9
    1. Joel Sherrill, Thu, 10 May 2018 22:27:19 GMT

    I think this ticket is down to the PowerPC BSPs. If you had a solution in mind Sebastian, please implement it.

    Comment 10
    1. Sebastian Huber, Fri, 11 May 2018 04:57:20 GMT

    I don't have time for this ticket at least in the next two weeks.

    Comment 11
    1. Joel Sherrill, Tue, 15 May 2018 14:25:55 GMT

    In 9d62874/rtems:

    sparc64 BSPs: Hard define configuration required settings Updates #3425.
    Comment 12
    1. Joel Sherrill, Tue, 15 May 2018 23:04:01 GMT

    Replying to Sebastian Huber:

    I don't have time for this ticket at least in the next two weeks.

    Is the approach I used on the arm and sparc64 BSPs acceptable? I am testing a similar patch for the PowerPC BSPs. Use BSP_SETOPTS when variants and AC_DEFINE when there are no variants.

    If so, this will eliminate the use of -Dxxx in .cfg files.

    Comment 13
    1. Joel Sherrill, Fri, 18 May 2018 13:22:54 GMT

    In eaf5bec/rtems:

    virtex5: Move -Dxxx to configure.ac Updates #3425.
    Comment 14
    1. Joel Sherrill, Fri, 18 May 2018 13:24:32 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    No BSPs use -D in CFLAGS now. #3431 is a ticket to track some identified follow up work.

    Comment 15
    1. Sebastian Huber, Mon, 11 Jun 2018 12:48:11 GMT

    In 07c5976/rtems:

    bsps/powerpc: Hack to fix the build The ppc405 define must be checked before the ppc403 define. The ppc405 define is provided by . The ppc403 define is provided by GCC as a built-in define if no ppc* or mpc* define is set via the command line (see GCC sources "gcc/config/rs6000/rtems.h"). Update #3425.
    Comment 16
    1. Sebastian Huber, Mon, 11 Jun 2018 12:48:21 GMT

    In 5249a4c/rtems:

    powerpc: Fix ss555 build The mpc555 define is provided via . It must not be used in cpukit header files. Update #3425.

    3432 - Remove Simple SMP Priority Scheduler

    Link https://devel.rtems.org/ticket/3432
    Id 3432
    Reporter Joel Sherrill
    Created 23 May 2018 19:10:36
    Modified 17 September 2018 11:34:20
    Owner  
    Type enhancement
    Component score
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This scheduler was the first SMP scheduler added. It was created to have an easy SMP scheduler to debug. This was especially important when all of the SMP modifications and support were new. A Simple Scheduler has a use case as a low resource alternative for small uniprocessor systems. But the SMP variant just doesn't seem to have a good use case. If you have an SMP system, the application is almost certain to have enough resources where the more complicated data structures used by the other schedulers wouldn't be a burden. The Deterministic Priority Scheduler uses ~3K for FIFO with 256 priorities. This should not be an issue for an SMP system.

    This ticket is a proposal to remove this as no longer having a use case.

    Comment 1
    1. Sebastian Huber, Fri, 25 May 2018 07:59:43 GMT

    Please don't remove this scheduler. I may change it a bit to support also the simple one-to-one and one-to-all thread processor affinities. It uses very simple data structures which yield a small object code size. Even big SMP machines may have a small L1 cache.

    Comment 2
    1. Sebastian Huber, Mon, 17 Sep 2018 11:34:20 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    This scheduler implementation should not be removed. It is useful in clustered scheduler scenarios.


    3433 - Add SMP support for RISC-V

    Link https://devel.rtems.org/ticket/3433
    Id 3433
    Reporter Sebastian Huber
    Created 25 May 2018 07:10:47
    Modified 9 January 2019 09:37:21
    Owner Sebastian Huber
    Type project
    Component arch/riscv
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by 3452, 3453, 3459

    Description

    The project includes the following tasks:

    • add CPU counter support
    • add context validation code
    • add BSP support for Qemu
    • add support for device tree provided by Qemu
    • fix all unexpected test suite failures running on Qemu
    • add build system support to enable an SMP build
    • add SMP implementation
    Comment 1
    1. Sebastian Huber, Fri, 25 May 2018 07:11:14 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to accepted
    Comment 2
    1. Sebastian Huber, Wed, 13 Jun 2018 08:45:14 GMT
    2. blockedby: set to 3452, 3453
    Comment 3
    1. Sebastian Huber, Mon, 18 Jun 2018 06:30:48 GMT
    2. blockedby: changed from 3452, 3453 to 3452, 3453, 3459
    Comment 4
    1. Sebastian Huber, Fri, 29 Jun 2018 08:31:10 GMT

    In 7b7e340/rtems-tools:

    tester: Add rv64imafd_medany.ini Update #3433.
    Comment 5
    1. Sebastian Huber, Fri, 29 Jun 2018 09:54:24 GMT

    In 9e3bb45/rtems:

    bsp/riscv_generic: New linker command file This linker command file is based on the "riscv64-rtems5-ld --verbose" output. Update #3433.
    Comment 6
    1. Sebastian Huber, Fri, 29 Jun 2018 09:54:45 GMT

    In 41e2295/rtems:

    bsp/riscv_generic: Use standard optimization flags Update #3433.
    Comment 7
    1. Sebastian Huber, Fri, 29 Jun 2018 09:54:56 GMT

    In 6f5d88a/rtems:

    bsp/riscv_generic: Rename to "riscv" Update #3433.
    Comment 8
    1. Sebastian Huber, Fri, 29 Jun 2018 09:55:06 GMT

    In f3da074a/rtems:

    bsp/riscv: Add new BSP variants The latest RISC-V tool chain introduced new multilib variants. Add corresponding BSP variants. Update #3433.
    Comment 9
    1. Sebastian Huber, Fri, 29 Jun 2018 09:55:17 GMT

    In 37a1fc2/rtems:

    bsp/riscv: Remove unused BSP options Update #3433.
    Comment 10
    1. Sebastian Huber, Fri, 29 Jun 2018 09:55:27 GMT

    In 16d905f/rtems:

    bsp/riscv: Add BSP options to define RAM region Update #3433.
    Comment 11
    1. Sebastian Huber, Fri, 29 Jun 2018 09:55:50 GMT

    In fef0a41/rtems:

    bsp/riscv: Do not clear integer registers at start There is no need to do this. Update #3433.
    Comment 12
    1. Sebastian Huber, Fri, 29 Jun 2018 09:56:01 GMT

    In 52f4fb6/rtems:

    riscv: Format assembler files Use tabs to match the GCC generated assembler output. Update #3433.
    Comment 13
    1. Sebastian Huber, Fri, 29 Jun 2018 09:56:11 GMT

    In b0ee789/rtems:

    bsp/riscv: Use memset() to clear .bss Update #3433.
    Comment 14
    1. Sebastian Huber, Fri, 29 Jun 2018 09:56:22 GMT

    In 9b2ef07f/rtems:

    bsp/riscv: Load global pointer Update #3433.
    Comment 15
    1. Sebastian Huber, Fri, 29 Jun 2018 09:56:33 GMT

    In 7c3b0df1/rtems:

    riscv: Implement ISR set/get level Fix prototypes. Update #3433.
    Comment 16
    1. Sebastian Huber, Fri, 29 Jun 2018 09:56:44 GMT

    In 853c5ef/rtems:

    build: Enable RISC-V SMP build Update #3433.
    Comment 17
    1. Sebastian Huber, Fri, 29 Jun 2018 09:56:56 GMT

    In 2086948/rtems:

    riscv: Add dummy SMP support Update #3433.
    Comment 18
    1. Sebastian Huber, Fri, 29 Jun 2018 09:57:07 GMT

    In fe2cd01/rtems:

    bsp/riscv: Add device tree support Update #3433.
    Comment 19
    1. Sebastian Huber, Fri, 29 Jun 2018 09:57:18 GMT

    In 5f5c450/rtems:

    bsp/riscv: Add SMP startup synchronization Update #3433.
    Comment 20
    1. Sebastian Huber, Fri, 29 Jun 2018 09:57:29 GMT

    In c558cc4/rtems:

    bsp/riscv: Fix vector table for lp64 Update #3433.
    Comment 21
    1. Sebastian Huber, Fri, 29 Jun 2018 09:57:39 GMT

    In 1232cd46/rtems:

    bsp/riscv: Add device tree support for console Update #3433.
    Comment 22
    1. Sebastian Huber, Fri, 29 Jun 2018 09:57:50 GMT

    In cdfed94f/rtems:

    bsp/riscv: Rework clock driver Use device tree provided timebase frequency. Do not write to read-only mtime register. Update #3433.
    Comment 23
    1. Sebastian Huber, Fri, 29 Jun 2018 09:58:00 GMT

    In ff7b104/rtems:

    bsp/riscv: Remove bsp_interrupt_handler_default() It duplicated the default implementation. Update #3433.
    Comment 24
    1. Sebastian Huber, Fri, 29 Jun 2018 09:58:10 GMT

    In bc3bdf2/rtems:

    riscv: Optimize and fix interrupt disable/enable Use the atomic read and clear operation to disable interrupts. Do not write the complete mstatus. Instead, set only the MIE bit depending on the level parameter. Update #3433.
    Comment 25
    1. Sebastian Huber, Fri, 29 Jun 2018 09:58:20 GMT

    In 3be4478f/rtems:

    riscv: Avoid namespace pollution Remove include from (which is visible via for example). Update #3433.
    Comment 26
    1. Sebastian Huber, Fri, 29 Jun 2018 09:58:31 GMT

    In 0fd8287/rtems:

    riscv: Add _CPU_Get_current_per_CPU_control() Update #3433.
    Comment 27
    1. Sebastian Huber, Fri, 29 Jun 2018 09:58:41 GMT

    In 9704d86f/rtems:

    riscv: Enable interrupts during dispatch after ISR The code sequence is derived from the ARM code (see _ARMV4_Exception_interrupt). Update #2751. Update #3433.
    Comment 28
    1. Sebastian Huber, Fri, 29 Jun 2018 09:58:52 GMT

    In 98f051e/rtems:

    riscv: Remove RISCV_GCC_RED_ZONE_SIZE The current ABI says that there is no stack red zone: ​https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md "Procedures must not rely upon the persistence of stack-allocated data whose addresses lie below the stack pointer." Update #3433.
    Comment 29
    1. Sebastian Huber, Fri, 29 Jun 2018 09:59:03 GMT

    In 9510742/rtems:

    riscv: Fix CPU_STACK_ALIGNMENT According to the RISC-V psABI ​https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md the stack alignment is 128 bits (16 bytes). Update #3433.
    Comment 30
    1. Sebastian Huber, Fri, 29 Jun 2018 09:59:13 GMT

    In a49a3c8e/rtems:

    riscv: Do not clear thread context Do not clear the complete thread context. Initialize only the necessary members. The Context_Control::is_executing member must be preserved across _CPU_Context_Initialize() calls. Update #3433.
    Comment 31
    1. Sebastian Huber, Fri, 29 Jun 2018 09:59:23 GMT

    In 04698eb/rtems:

    riscv: Properly align the thread stack Update #3433.
    Comment 32
    1. Sebastian Huber, Fri, 29 Jun 2018 09:59:33 GMT

    In 2987c4f/rtems:

    riscv: Remove x8 initialization The RISC-V psABI ​https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md does not mention that this is a frame pointer. Update #3433.
    Comment 33
    1. Sebastian Huber, Fri, 29 Jun 2018 09:59:44 GMT

    In b706b4a/rtems:

    riscv: Remove mstatus from thread context The mstatus register contains no thread-specific state which must be saved/restored during a context switch. Machine interrupts (MIE) must be enabled during a context switch. Create separate CPU_Interrupt_frame structure. Update #3433.
    Comment 34
    1. Sebastian Huber, Fri, 29 Jun 2018 09:59:54 GMT

    In 8f035cb/rtems:

    riscv: Implement _CPU_Context_volatile_clobber() Update #3433.
    Comment 35
    1. Sebastian Huber, Fri, 29 Jun 2018 10:00:04 GMT

    In 71af1a4/rtems:

    riscv: Make some CPU port defines visible to asm Move SREG and LREG assembler defines to . Update #3433.
    Comment 36
    1. Sebastian Huber, Fri, 29 Jun 2018 10:00:14 GMT

    In 40f81ce6/rtems:

    riscv: Implement _CPU_Context_validate() Update #3433.
    Comment 37
    1. Sebastian Huber, Fri, 29 Jun 2018 10:00:25 GMT

    In dffc08c/rtems:

    riscv: Fix interrupt save/restore Update #3433.
    Comment 38
    1. Sebastian Huber, Fri, 29 Jun 2018 10:00:35 GMT

    In a8188730/rtems:

    riscv: Fix _CPU_Context_Initialize() prototype Update #3433.
    Comment 39
    1. Sebastian Huber, Fri, 29 Jun 2018 10:00:45 GMT

    In e43994d/rtems:

    riscv: Optimize context switch and interrupts Save/restore non-volatile registers in _CPU_Context_switch(). Save/restore volatile registers in _ISR_Handler(). Update #3433.
    Comment 40
    1. Sebastian Huber, Fri, 29 Jun 2018 10:00:55 GMT

    In afb60eb/rtems:

    riscv: Remove dead code Update #3433.
    Comment 41
    1. Sebastian Huber, Fri, 29 Jun 2018 10:01:05 GMT

    In 694e79a0/rtems:

    riscv: Add TLS support Update #3433.
    Comment 42
    1. Sebastian Huber, Fri, 29 Jun 2018 10:01:16 GMT

    In 995e91e8/rtems:

    riscv: Fix global construction Update #3433.
    Comment 43
    1. Sebastian Huber, Fri, 29 Jun 2018 10:01:26 GMT

    In 5235238/rtems:

    riscv: Add floating-point support Update #3433.
    Comment 44
    1. Sebastian Huber, Fri, 29 Jun 2018 10:01:36 GMT

    In 109bc1c7/rtems:

    riscv: Add SMP context switch support Update #3433.
    Comment 45
    1. Sebastian Huber, Fri, 29 Jun 2018 10:09:06 GMT

    In 79d69ae/rtems:

    riscv: Fix SMP context switch support Update #3433.
    Comment 46
    1. Sebastian Huber, Fri, 29 Jun 2018 10:09:16 GMT

    In 79d69ae/rtems:

    riscv: Fix SMP context switch support Update #3433.
    Comment 47
    1. Sebastian Huber, Fri, 29 Jun 2018 10:57:42 GMT

    In b36bf5b/rtems:

    score: Increase PER_CPU_CONTROL_SIZE_APPROX Increase the PER_CPU_CONTROL_SIZE_APPROX on 64-bit targets. Update #3433.
    Comment 48
    1. Sebastian Huber, Mon, 02 Jul 2018 13:22:23 GMT

    In e07b51a7/rtems:

    riscv: Fix fcsr initialization Update #3433.
    Comment 49
    1. Sebastian Huber, Fri, 06 Jul 2018 05:27:22 GMT

    In e755782/rtems:

    riscv: Clear reservations See also RISC-V User-Level ISA V2.3, comment in section 8.2 "Load-Reserved/Store?-Conditional Instructions". Update #3433.
    Comment 50
    1. Sebastian Huber, Fri, 06 Jul 2018 08:06:38 GMT

    In 6418c91d/rtems:

    Update config.guess and config.sub Update via: wget -O config.guess '​https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD' wget -O config.sub '​https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD' Update #3433.
    Comment 51
    1. Sebastian Huber, Fri, 06 Jul 2018 12:28:33 GMT

    In dd32e2b2/rtems:

    riscv: Implement CPU counter Update #3433.
    Comment 52
    1. Sebastian Huber, Fri, 06 Jul 2018 12:28:43 GMT

    In bca36d9/rtems:

    riscv: Add LADDR assembler define An address must be loaded to a register according to the code model. Add LADDR define for use in assembler code. Update #3433.
    Comment 53
    1. Sebastian Huber, Fri, 06 Jul 2018 12:28:54 GMT

    In 31f90a2/rtems:

    bsp/riscv: Simplify printk() support This is a prepartion to add NS16550 driver support to the console driver. Update #3433.
    Comment 54
    1. Sebastian Huber, Fri, 06 Jul 2018 12:29:04 GMT

    In 1a19239/rtems:

    bsp/riscv: Add console support for NS16550 devices Update #3433.
    Comment 55
    1. Sebastian Huber, Tue, 24 Jul 2018 07:13:55 GMT

    In 3a646426/rtems:

    score: Add _CPU_Instruction_illegal() On some architectures/simulators it is difficult to provoke an exception with misaligned or illegal data loads. Use an illegal instruction instead. Update #3433.
    Comment 56
    1. Sebastian Huber, Wed, 25 Jul 2018 08:10:25 GMT

    In d779a1e2/rtems:

    riscv: Add exception codes Update #3433.
    Comment 57
    1. Sebastian Huber, Wed, 25 Jul 2018 08:10:35 GMT

    In 5694b0c/rtems:

    riscv: New CPU_Exception_frame Use the CPU_Interrupt_frame for the volatile context. Add non-volatile registers and extra state on top of it. Update #3433.
    Comment 58
    1. Sebastian Huber, Wed, 25 Jul 2018 08:10:45 GMT

    In 8db3f0e/rtems:

    riscv: Rework exception handling Remove _CPU_ISR_install_raw_handler() and _CPU_ISR_install_vector() functions. Applications can install an exception handler via the fatal error handler to handle synchronous exceptions. Handle interrupt exceptions via _RISCV_Interrupt_dispatch() which must be provided by the BSP. Update #3433.
    Comment 59
    1. Sebastian Huber, Wed, 25 Jul 2018 08:10:56 GMT

    In 7fe4855/rtems:

    bsp/riscv: Fix HTIF warnings Update #3433.
    Comment 60
    1. Sebastian Huber, Wed, 25 Jul 2018 08:11:06 GMT

    In 791d9ac5/rtems:

    bsp/riscv: Disable HTIF support by default The HTIF is a legacy machinery. Update #3433.
    Comment 61
    1. Sebastian Huber, Wed, 25 Jul 2018 08:11:16 GMT

    In 3a263a9b/rtems:

    bsp/riscv: Add and use riscv_fdt_get_address() Update #3433.
    Comment 62
    1. Sebastian Huber, Wed, 25 Jul 2018 08:11:26 GMT

    In dda6e06/rtems:

    bsp/riscv: Add reset via for SiFive? Test Finisher Update #3433.
    Comment 63
    1. Sebastian Huber, Wed, 25 Jul 2018 08:11:37 GMT

    In f5fd8eb/rtems:

    bsps/riscv: Update linker-symbols.h Update #3433.
    Comment 64
    1. Sebastian Huber, Wed, 25 Jul 2018 08:11:41 GMT

    In d3d115a/rtems-tools:

    tester: Add use virt machine for rv64imafd_medany Update #3433.
    Comment 65
    1. Sebastian Huber, Wed, 25 Jul 2018 08:11:48 GMT

    In c2670de/rtems:

    riscv: Use wfi instruction for idle task Update #3433.
    Comment 66
    1. Sebastian Huber, Wed, 25 Jul 2018 08:11:58 GMT

    In 6b9ef09/rtems:

    riscv: Add CLINT and PLIC support The CLINT and PLIC need some per-processor state. Update #3433.
    Comment 67
    1. Sebastian Huber, Wed, 25 Jul 2018 08:12:09 GMT

    In 447fd89/rtems:

    bsp/riscv: Add basic SMP startup Update #3433.
    Comment 68
    1. Sebastian Huber, Wed, 25 Jul 2018 08:12:19 GMT

    In 6552ba8/rtems:

    bsp/riscv: Use CPU counter btimer Update #3433.
    Comment 69
    1. Sebastian Huber, Wed, 25 Jul 2018 08:12:30 GMT

    In bd560386/rtems:

    bsp/riscv: Add simple SMP support to clock driver This is a hack. The clock interrupt should be handled by each hart. Update #3433.
    Comment 70
    1. Sebastian Huber, Wed, 25 Jul 2018 08:12:40 GMT

    In adede135/rtems:

    bsp/riscv: Add PLIC support Update #3433.
    Comment 71
    1. Sebastian Huber, Wed, 25 Jul 2018 08:12:50 GMT

    In 581a0f88/rtems:

    bsp/riscv: Use interrupt driven NS16550 driver Update #3433.
    Comment 72
    1. Sebastian Huber, Fri, 27 Jul 2018 11:26:50 GMT

    In 65f52d0/rtems:

    samples/minimum: Use default interrupt stack size Update #3433.
    Comment 73
    1. Sebastian Huber, Fri, 27 Jul 2018 13:07:35 GMT

    In cfc9573/rtems:

    riscv: Rework CPU counter support Update #3433.
    Comment 74
    1. Sebastian Huber, Fri, 27 Jul 2018 13:07:45 GMT

    In 44c2d393/rtems:

    bsp/riscv: Fix inter-processor interrupts The previous version worked only on a patched Qemu. Writes to mip are illegal according to the The RISC-V Instruction Set Manual, Volume II: Privileged Architecture, Privileged Architecture Version 1.10. Update #3433.
    Comment 75
    1. Sebastian Huber, Tue, 31 Jul 2018 05:14:14 GMT

    In d906ce3/rtems:

    libtests: Use CONFIGURE_INIT_TASK_TABLE_SIZE Using CONFIGURE_MINIMUM_TASK_STACK_SIZE increases also the interrupt stack size. This is an issue on some BSPs. Use CONFIGURE_INIT_TASK_TABLE_SIZE instead. Update #3433.
    Comment 76
    1. Sebastian Huber, Wed, 01 Aug 2018 09:18:31 GMT

    In 48cbd63/rtems:

    bsp/riscv: Fix clock driver Do not assume that mtime is zero at boot time. Update #3433.
    Comment 77
    1. Sebastian Huber, Wed, 01 Aug 2018 09:18:42 GMT

    In 529154b/rtems:

    bsp/riscv: Initialize FPU depending on ISA Initialize fcsr to zero for a defined rounding mode. Update #3433.
    Comment 78
    1. Sebastian Huber, Wed, 01 Aug 2018 09:19:12 GMT

    In 56b0387/rtems:

    bsp/riscv: Add NS16750 support to console driver Update #3433.
    Comment 79
    1. Sebastian Huber, Wed, 01 Aug 2018 09:19:23 GMT

    In dee2ebb/rtems:

    bsp/riscv: Remove unused variable Update #3433.
    Comment 80
    1. Sebastian Huber, Thu, 02 Aug 2018 07:28:46 GMT

    In 3d11c1e/rtems:

    bsp/riscv: Fix a synchronization issue for PLIC Update #3433.
    Comment 81
    1. Sebastian Huber, Thu, 02 Aug 2018 07:44:35 GMT

    In 28b8cf9b/rtems:

    riscv: Fix CPU_ALIGNMENT Update #3433.
    Comment 82
    1. Sebastian Huber, Thu, 02 Aug 2018 10:53:46 GMT

    In d909c5f/rtems-docs:

    cpu-supplement: Add RISC-V chapter Update #3433.
    Comment 83
    1. Sebastian Huber, Thu, 02 Aug 2018 11:21:52 GMT

    In 24326a8/rtems-docs:

    user: Add RISC-V BSP section Update #3433.
    Comment 84
    1. Sebastian Huber, Thu, 02 Aug 2018 12:40:02 GMT

    In 4c740de/rtems:

    bsp/riscv: Fix build with RTEMS_SMP undefined Update #3433.
    Comment 85
    1. Sebastian Huber, Thu, 02 Aug 2018 13:33:21 GMT

    In 141d502/rtems:

    bsp/riscv: Add missing BSP variant Update #3433.
    Comment 86
    1. Sebastian Huber, Mon, 06 Aug 2018 07:07:27 GMT
    2. version: set to 5
    3. milestone: changed from 6.1 to 5.1
    Comment 87
    1. Sebastian Huber, Mon, 06 Aug 2018 07:51:44 GMT

    In 5d957c9/rtems-tools:

    tester: Add RISC-V support to BSP builder Update #3433.
    Comment 88
    1. Sebastian Huber, Tue, 07 Aug 2018 05:02:03 GMT

    In d343f83/rtems-tools:

    tester: Exclude SMP build of some RISC-V BSPs It makes no sense to build BSPs without support for atomic instructions with SMP enabled. Update #3433.
    Comment 89
    1. Sebastian Huber, Tue, 07 Aug 2018 05:06:46 GMT

    In 01600ac/rtems-source-builder:

    5: Update tools for RISC-V BSP builder support Update #3433.
    Comment 90
    1. Sebastian Huber, Sat, 11 Aug 2018 13:44:10 GMT

    In 142770b/rtems-docs:

    c-user: SMP is supported on RISC-V Update #3433.
    Comment 91
    1. Sebastian Huber, Thu, 06 Sep 2018 05:16:22 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    The RISC-V SMP support is now in a good shape.

    Comment 92
    1. Sebastian Huber, Wed, 09 Jan 2019 09:37:21 GMT

    In b9ffc41c/rtems:

    riscv: Enable robust thread dispatch It must be enabled, since the context switch code does not save/restore the interrupt status. Update #3433.

    3434 - Add CONFIGURE_MINIMUM_POSIX_THREAD_STACK_SIZE configuration option

    Link https://devel.rtems.org/ticket/3434
    Id 3434
    Reporter Sebastian Huber
    Created 25 May 2018 08:39:15
    Modified 8 August 2018 06:54:00
    Owner Sebastian Huber
    Type enhancement
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Joel Sherrill, Fri, 25 May 2018 15:10:03 GMT

    What is your rationale and use case?

    Comment 2
    1. Sebastian Huber, Fri, 25 May 2018 15:56:59 GMT

    The use case is to overrule this somewhat arbitrary rule that the minimum POSIX thread stack size is twice the minimum standard stack size.

    Comment 3
    1. Sebastian Huber, Wed, 08 Aug 2018 06:48:53 GMT

    In fd27bae/rtems:

    CONFIGURE_MINIMUM_POSIX_THREAD_STACK_SIZE Make CONFIGURE_MINIMUM_POSIX_THREAD_STACK_SIZE configurable by the user. Update #3434.
    Comment 4
    1. Sebastian Huber, Wed, 08 Aug 2018 06:54:00 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 806806c/rtems-docs:

    c-user: CONFIGURE_MINIMUM_POSIX_THREAD_STACK_SIZE Close #3434.

    3435 - Add test case for CONFIGURE_BSP_PREREQUISITE_DRIVERS configuration option

    Link https://devel.rtems.org/ticket/3435
    Id 3435
    Reporter Sebastian Huber
    Created 25 May 2018 08:42:49
    Modified 6 September 2018 05:12:56
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This configuration option is untested

    Comment 1
    1. Joel Sherrill, Fri, 25 May 2018 15:09:24 GMT
    2. status: changed from assigned to closed
    3. resolution: set to wontfix

    It is used in deployed use code. Off the top of my head, it was used on a custom erc32 board to initialize a VMEBus and associated hardware before any other drivers were initialized. This was very specifically needed to extend -- not modify -- an existing BSP.

    If you want a test added, great. But this has a very legitimate use case. It should not be deleted.

    Comment 2
    1. Sebastian Huber, Mon, 28 May 2018 05:01:33 GMT
    2. status: changed from closed to reopened
    3. resolution: wontfix deleted
    4. description: modified (diff)
    5. summary: changed from Remove CONFIGURE_BSP_PREREQUISITE_DRIVERS configuration option to Add test case for CONFIGURE_BSP_PREREQUISITE_DRIVERS configuration option
    Comment 3
    1. Sebastian Huber, Thu, 06 Sep 2018 05:12:56 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    In 0e907232/rtems:

    sptests/spconfig01: New test Close #3435.

    3436 - Remove clock driver Clock_driver_support_shutdown_hardware() hook

    Link https://devel.rtems.org/ticket/3436
    Id 3436
    Reporter Sebastian Huber
    Created 25 May 2018 12:32:59
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component dev
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    Most applications use a clock driver and most BSPs use the clock driver framework provided by clockimpl.h. This framework offers a Clock_driver_support_shutdown_hardware() hook which is used like this.

    #ifdef Clock_driver_support_shutdown_hardware
    /**
    * @brief Clock_exit
    *
    * This routine allows the clock driver to exit by masking the interrupt and
    * disabling the clock's counter.
    */
    void Clock_exit( void )
    {
    Clock_driver_support_shutdown_hardware();
    /* do not restore old vector */
    }
    #endif
    ...
    #ifdef Clock_driver_support_shutdown_hardware
    atexit( Clock_exit );
    #endif

    The aim is to stop clock tick interrupts at some late point in the exit() procedure.

    The use of atexit() pulls in malloc() which pulls in errno. It is incompatible with the intention of the CONFIGURE_DISABLE_NEWLIB_REENTRANCY configuration option.

    The exit() function must be called from thread context, so accompanied clock tick interrupts should cause no harm. On the contrary, someone may assume a normal operating system operation, e.g. working timeouts.

    Remove the superfluous Clock_driver_support_shutdown_hardware() hook.

    Comment 1
    1. Sebastian Huber, Fri, 29 Jun 2018 08:16:31 GMT

    In c765aa0/rtems-docs:

    bsp-howto: Mention clock driver hook removal Update #3436.
    Comment 2
    1. Sebastian Huber, Fri, 29 Jun 2018 09:53:27 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 7ee59313/rtems:

    Remove Clock_driver_support_shutdown_hardware() The aim of this clock driver hook was to stop clock tick interrupts at some late point in the exit() procedure. The use of atexit() pulls in malloc() which pulls in errno. It is incompatible with the intention of the CONFIGURE_DISABLE_NEWLIB_REENTRANCY configuration option. The exit() function must be called from thread context, so accompanied clock tick interrupts should cause no harm. On the contrary, someone may assume a normal operating system operation, e.g. working timeouts. Remove the Clock_driver_support_shutdown_hardware() clock driver hook. Close #3436.
    Comment 3
    1. Sebastian Huber, Wed, 11 Dec 2019 08:06:32 GMT

    In a6b2080/rtems:

    clock: Remove Clock_exit() from API This function is no longer supported by the standard clock driver implementation (clockimpl.h). Update #3436.
    Comment 4
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3437 - Replace use of printk() in free() with a fatal error

    Link https://devel.rtems.org/ticket/3437
    Id 3437
    Reporter Sebastian Huber
    Created 25 May 2018 12:56:20
    Modified 5 June 2018 07:14:01
    Owner Sebastian Huber
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    An invalid heap usage such as a double free is usually a fatal error. Replace the use of printk() in free() with a fatal error. Introduce a new fatal error source for heap errors.

    Comment 1
    1. Sebastian Huber, Tue, 05 Jun 2018 07:13:27 GMT

    In de9b7d7/rtems:

    Add RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE An invalid heap usage such as a double free is usually a fatal error since this indicates a use after free. Replace the use of printk() in free() with a fatal error. Update #3437.
    Comment 2
    1. Sebastian Huber, Tue, 05 Jun 2018 07:14:01 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In aaf9c78/rtems-docs:

    c-user: RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE Close #3437.

    3443 - Remove shgen program

    Link https://devel.rtems.org/ticket/3443
    Id 3443
    Reporter Sebastian Huber
    Created 7 June 2018 05:05:07
    Modified 13 June 2018 07:58:18
    Owner Sebastian Huber
    Type task
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Rename it to rtems-shgen.

    Comment 1
    1. Sebastian Huber, Wed, 13 Jun 2018 07:47:32 GMT
    2. summary: changed from Move shgen to rtems-tools to Remove shgen

    After discussion on devel@… it was decided to remove this tool due to its license (GPL).

    Comment 2
    1. Sebastian Huber, Wed, 13 Jun 2018 07:48:12 GMT
    2. summary: changed from Remove shgen to Remove shgen program
    Comment 3
    1. Sebastian Huber, Wed, 13 Jun 2018 07:58:18 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 8c62cf4/rtems:

    tools: Remove shgen All tools should be removed from the RTEMS source repository at some point in time. Tools with a BSD-style license will be moved to the RTEMS tools repository. Unfortunately, the shgen tool is GPL licensed. Remove all uses of this tool from the code base. Replace generated files with stub functions. If users of this BSP still exist, they can reimplement the functionality using a BSD-style license. Close #3443.

    3444 - Remove nios2gen program

    Link https://devel.rtems.org/ticket/3444
    Id 3444
    Reporter Sebastian Huber
    Created 7 June 2018 05:05:52
    Modified 29 June 2018 09:55:38
    Owner Sebastian Huber
    Type task
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Rename it to rtems-nios2gen

    Comment 1
    1. Sebastian Huber, Wed, 13 Jun 2018 07:49:19 GMT
    2. summary: changed from Move nios2gen to rtems-tools to Remove nios2gen program

    After discussion on devel@… it was decided to remove this program due to its license (RTEMS GPL).

    Comment 2
    1. Sebastian Huber, Fri, 15 Jun 2018 05:15:39 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 46c2da6/rtems:

    tools: Remove nios2gen All tools should be removed from the RTEMS source repository at some point in time. Tools with a BSD-style license will be moved to the RTEMS tools repository. Unfortunately, the this tool is RTEMS GPL licensed. If users of this tool still exist, they can reimplement the functionality using a BSD-style license and add it to the RTEMS tools. Close #3444.
    Comment 3
    1. Sebastian Huber, Fri, 29 Jun 2018 09:55:38 GMT

    In 38024362/rtems:

    bsp/riscv: Fix some warnings Update #3444.

    3445 - Remove multigen script

    Link https://devel.rtems.org/ticket/3445
    Id 3445
    Reporter Sebastian Huber
    Created 7 June 2018 05:52:26
    Modified 15 June 2018 05:16:42
    Owner Sebastian Huber
    Type task
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This script is unused and out dated.

    Comment 1
    1. Sebastian Huber, Fri, 15 Jun 2018 05:16:42 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 1346d27/rtems:

    tools: Remove multigen This script is unused and out dated. Close #3445.

    3446 - Remove cvsignore-add.sh script

    Link https://devel.rtems.org/ticket/3446
    Id 3446
    Reporter Sebastian Huber
    Created 7 June 2018 05:54:34
    Modified 15 June 2018 05:16:52
    Owner Sebastian Huber
    Type task
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This script is obsolete since moving to Git.

    Comment 1
    1. Sebastian Huber, Fri, 15 Jun 2018 05:16:52 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a94a0f5/rtems:

    tools: Remove cvsignore-add.sh This script is obsolete since moving to Git. Close #3446.

    3447 - Remove rtems-testsuite-autostuff script

    Link https://devel.rtems.org/ticket/3447
    Id 3447
    Reporter Sebastian Huber
    Created 7 June 2018 06:12:51
    Modified 15 June 2018 05:17:02
    Owner Sebastian Huber
    Type task
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    It is not used.

    Comment 1
    1. Sebastian Huber, Fri, 15 Jun 2018 05:17:02 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In df7f0ac6/rtems:

    tools: Remove rtems-testsuite-autostuff It is not used. Close #3447.

    3451 - Remove size_rtems script

    Link https://devel.rtems.org/ticket/3451
    Id 3451
    Reporter Sebastian Huber
    Created 13 June 2018 07:52:21
    Modified 15 June 2018 05:15:50
    Owner Sebastian Huber
    Type task
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This script is horribly out of date. A new version could be placed in RTEMS tools if necessary.

    Comment 1
    1. Joel Sherrill, Wed, 13 Jun 2018 08:17:24 GMT

    I don't disagree with removing this. The question this script is trying to answer is "what's the code space requirement for RTEMS?" This is usually asked as "How big is RTEMS?" The answer is that it depends.

    This script produced a report similar to some other RTOS when it was written. Buy I evolved to think that the linked size of sample reference applications like base_sp, minimum, hello, minimum networking, etc.

    A real application will vary in size based on the set of services it uses. Often those services depends on things that add code which we wouldn't consider part of RTEMS. A C++ application with megabytes of code from the C++ Standard Library is large but may use a very small but of code from RTEMS itself. The Qt demos were similar.

    Also size varies by architecture, optimization level, gcc version, function section linking, etc.

    There is no single answer and no standard guides. So we need to decide what we think is useful, explain it, and watch it.

    Comment 2
    1. Sebastian Huber, Fri, 15 Jun 2018 05:15:50 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 9eb1494f/rtems:

    tools: Remove size_rtems This script is horribly out of date. A new version could be placed in RTEMS tools if necessary. Close #3451.

    3452 - Update RISC-V tool chain to support standard 64-bit chips

    Link https://devel.rtems.org/ticket/3452
    Id 3452
    Reporter Sebastian Huber
    Created 13 June 2018 08:42:32
    Modified 20 August 2018 12:55:53
    Owner Sebastian Huber
    Type enhancement
    Component arch/riscv
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3433
    Blocked by  

    Description

    First step is to include this bug fix in Binutils:

    ​https://sourceware.org/bugzilla/show_bug.cgi?id=23244

    Second step is a multilib update. Third step is a merge of the riscv32 and riscv64 tool chains into a single riscv tool chain.

    Comment 1
    1. Sebastian Huber, Wed, 13 Jun 2018 08:45:14 GMT
    2. blocking: set to 3433
    Comment 2
    1. Sebastian Huber, Wed, 13 Jun 2018 08:47:12 GMT

    In 9530518/rtems-source-builder:

    Build only the Binutils The Binutils and GDB share a repository. In order to build the Binutils from a repository snapshot some components must be disabled. Update #3452.
    Comment 3
    1. Sebastian Huber, Wed, 13 Jun 2018 08:47:28 GMT

    In f432e19/rtems-source-builder:

    5: Update RISC-V Binutils This includes the following bug fix: ​https://sourceware.org/bugzilla/show_bug.cgi?id=23244 Update #3452.
    Comment 4
    1. Sebastian Huber, Wed, 20 Jun 2018 06:36:21 GMT

    In 8ee4e8c/rtems-source-builder:

    5: Update RISC-V Binutils and GDB This includes the following bug fix: ​https://sourceware.org/bugzilla/show_bug.cgi?id=23305 Update #3452.
    Comment 5
    1. Sebastian Huber, Fri, 22 Jun 2018 04:24:21 GMT

    In 4bd8de5/rtems-source-builder:

    5: Use GCC 8 snapshot for RISC-V This picks up the new multilib set for RISC-V. Update #3452.
    Comment 6
    1. Sebastian Huber, Tue, 24 Jul 2018 07:06:52 GMT

    In dc6b940/rtems-source-builder:

    5: Update Newlib Update RISC-V GCC to a GCC 9 branch commit. Close #3342. Close #3343. Update #3452.
    Comment 7
    1. Sebastian Huber, Tue, 24 Jul 2018 07:06:59 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d33c151/rtems-source-builder:

    5: Merge riscv32 and riscv64 into riscv After several upstream updates in Binutils, GCC, Newlib, and GDB it is now possible to use a common riscv tool chain for the 32-bit and 64-bit RISC-V. Update GDB to ce73f310150418a9a1625ab60a527d959096a9e2 Git commit. Close #3452.
    Comment 8
    1. Sebastian Huber, Tue, 24 Jul 2018 10:10:47 GMT

    In 2ef6dfe9/rtems-source-builder:

    5: Fix rtems-all due to recent RISC-V changes Update #3452.
    Comment 9
    1. Sebastian Huber, Wed, 25 Jul 2018 12:06:34 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    Another tool chain issue:

    ​https://sourceware.org/bugzilla/show_bug.cgi?id=23451

    Comment 10
    1. Sebastian Huber, Thu, 26 Jul 2018 07:08:20 GMT

    In 2cd6cef/rtems-source-builder:

    5: Change riscv to riscv32 This is a temporary workaround for this bug: ​https://sourceware.org/bugzilla/show_bug.cgi?id=23451 It is not clear how this can be resolved upstream. Update #3452.
    Comment 11
    1. Sebastian Huber, Mon, 30 Jul 2018 08:10:59 GMT

    In c40d126/rtems-source-builder:

    5: Change riscv32 back to riscv Update Binutils to include a bug fix for: ​https://sourceware.org/bugzilla/show_bug.cgi?id=23451 Update #3452.
    Comment 12
    1. Sebastian Huber, Fri, 03 Aug 2018 10:06:11 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    In 8f74240/rtems-source-builder:

    5: Update Newlib It includes a fix for bug in the ctype support, some FreeBSD compatibility changes in for libbsd and a new configuration option for all targets newlib/configure.host which is used by the RISC-V port. Close #3452.
    Comment 13
    1. Sebastian Huber, Mon, 20 Aug 2018 12:55:53 GMT

    In 79c83cd/rtems-source-builder:

    5: Update Newlib for RISC-V Use the latest Newlib to fix the GCC libgomp build (TLS support was not detected due to broken crt0). Update #3452.

    3453 - Add RISC-V GDB

    Link https://devel.rtems.org/ticket/3453
    Id 3453
    Reporter Sebastian Huber
    Created 13 June 2018 08:43:25
    Modified 13 June 2018 08:47:35
    Owner Sebastian Huber
    Type enhancement
    Component arch/riscv
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3433
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Wed, 13 Jun 2018 08:45:14 GMT
    2. blocking: set to 3433
    Comment 2
    1. Sebastian Huber, Wed, 13 Jun 2018 08:47:20 GMT

    In d8daad2/rtems-source-builder:

    Build only the GDB The Binutils and GDB share a repository. In order to build the GDB from a repository snapshot some components must be disabled. Update #3453.
    Comment 3
    1. Sebastian Huber, Wed, 13 Jun 2018 08:47:35 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 8ef0d73/rtems-source-builder:

    5: Add GDB for RISC-V Mainline GDB support for RISC-V is not yet in a released GDB version. Close #3453.

    3454 - Tracing Framework Documentation in User Manual

    Link https://devel.rtems.org/ticket/3454
    Id 3454
    Reporter Vidushi Vashishth
    Created 14 June 2018 11:19:36
    Modified 20 February 2019 09:54:08
    Owner Vidushi Vashishth
    Type task
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords GSoC'18
    Cc Sebastian Huber Chris Johns Gedare Bloom
    Blocking  
    Blocked by  

    Description

    1) Write up a new chapter in the user manual regarding the existing tracing framework in RTEMS. Include a description of the components of the tracing framework and the various techniques used to generate traces currently. Add explanatory demonstrations and samples.

    2) Expand the chapter to include CTF generation (currently under development) as it evolves.

    Comment 1
    1. Vidushi Vashishth, Mon, 18 Jun 2018 05:31:43 GMT

    In 8f4f80d/rtems-docs:

    Adding Trace Documentation Updates #3454 This commit adds Tracing Framework Chapter in the RTEMS User Manual It comprises of subchapters on RTEMS Trace Linker, Capture Engine, Trace generation techniques explaining trace generation using Trace Buffering and Printk generators and sample demonstrations.
    Comment 2
    1. Sebastian Huber, Wed, 20 Feb 2019 09:54:08 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    4. component: changed from admin to doc
    5. milestone: set to 5.1

    3455 - Remove install-if-change script

    Link https://devel.rtems.org/ticket/3455
    Id 3455
    Reporter Sebastian Huber
    Created 15 June 2018 05:40:58
    Modified 18 June 2018 05:12:45
    Owner Sebastian Huber
    Type task
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The last installed tool in RTEMS repository is the install-if-change script. This script does the same as the standard "install" program with an additional feature to install variants via the -V command line option.

    This script is used by the standard Makefile support:

    c/src/make/host.cfg.in:INSTALL_CHANGE=$(PROJECT_BIN)/install-if-change

    The INSTALL_CHANGE is used by:

    c/src/make/host.cfg.in:ifndef INSTALL_CHANGE
    c/src/make/host.cfg.in:INSTALL_CHANGE=$(PROJECT_BIN)/install-if-change
    c/src/make/host.cfg.in:INSTALL_VARIANT=$(INSTALL_CHANGE) -V "$(LIB_VARIANT)"

    Is the variant stuff still supported?

    I would remove the support for it and replace the "install-if-change" script with the standard "install" program.

    Comment 1
    1. Sebastian Huber, Fri, 15 Jun 2018 06:22:33 GMT

    The script has no license information.

    Comment 2
    1. Joel Sherrill, Fri, 15 Jun 2018 06:40:12 GMT

    Remove it and uses on technical grounds. The remaining use isn't enough to even make the lack of license a factor.

    Comment 3
    1. Sebastian Huber, Mon, 18 Jun 2018 05:12:45 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In bac8d934/rtems:

    tools: Remove install-if-change program The last installed tool in RTEMS repository is the install-if-change script. It is not used to build/install BSPs. This script does the same as the standard "install" program with an additional feature to install variants via the -V command line option. This script is used by the standard Makefile support: c/src/make/host.cfg.in:INSTALL_CHANGE=$(PROJECT_BIN)/install-if-change The INSTALL_CHANGE is used by: c/src/make/host.cfg.in:ifndef INSTALL_CHANGE c/src/make/host.cfg.in:INSTALL_CHANGE=$(PROJECT_BIN)/install-if-change c/src/make/host.cfg.in:INSTALL_VARIANT=$(INSTALL_CHANGE) -V "$(LIB_VARIANT)" Remove the support for variant installation and instead use the standard "install" program. This breaks application Makefiles using the standard Makefile support of RTEMS. Close #3455.

    3458 - rtems-test should not use the env PATH to find covoar

    Link https://devel.rtems.org/ticket/3458
    Id 3458
    Reporter Chris Johns
    Created 17 June 2018 23:09:23
    Modified 19 June 2018 03:45:15
    Owner Chris Johns <chrisj@…>
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords coverage rtems-test
    Cc  
    Blocking  
    Blocked by  

    Description

    The rtems-test command should know where covoar is when invoking it. It cannot use the environment's path. The path can contain invalid or outdated versions with subtle issues that could be hard to find.

    There should be no need to run install to use and test rtems-test with coverage.

    The rtems-test python code for running the tests knows where it is and adjusts. For example using an absolute path to rtems-tests in a build directly results in it being able to find the development tree rtemstoolkit and configuration data. The command needs to be taught to find the development version of covoar.

    Note, currently covoar needs external tools and this is currently using the environment's path however there is work underway to remove this dependence so there case does not need to be handled.

    Comment 1
    1. Chris Johns, Mon, 18 Jun 2018 05:33:29 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed
    Comment 2
    1. Chris Johns, Tue, 19 Jun 2018 03:45:15 GMT
    2. owner: set to Chris Johns <chrisj@…>

    In e341a65/rtems-tools:

    tester: Make the path to covoar absolute to ignore the env PATH. Using the environment's path to find covoar allow invalid versions to be used which may vary in subtle ways. Find and use the covoar that is build with the version of 'rtems-test'. This patch means you do not need to install the tools before running improving the development experience. Closes #3458

    3459 - Rework initialization and interrupt stack support

    Link https://devel.rtems.org/ticket/3459
    Id 3459
    Reporter Sebastian Huber
    Created 18 June 2018 06:29:46
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3433
    Blocked by  

    Description

    We need an initialization stack to run the sequential system initialization before multitasking is enabled. The system initialization is done with interrupts disabled.

    We need an interrupt stack for interrupt processing. This helps to avoid a per thread stack overhead for interrupt processing. The size for interrupt stack is application dependent, e.g. maximum interrupt nest level, stack demands of interrupt handlers.

    The initialization and interrupt stacks are needed for each processor in the system.

    Since interrupts are disabled during the sequential system initialization we can re-use the interrupt stack for the initialization stack. This is important for low end targets, with very limited RAM sizes. We need the initialization stack before a proper C run-time environment is set up e.g. we cannot assume that the access to global data is available. The stack memory area begin and size should be available via global symbols (named addresses). On some BSPs, e.g. ARM, this is done via the linker command file.

    It should be possible to set the stack size via the CONFIGURE_INTERRUPT_STACK_SIZE configuration option and not via some magic stuff in linker command files.

    Many BSPs set the BSS area to zero during system initialization. Thus, the initialization stack must not be contained in the BSS area.

    The interrupt stack implementation is currently controlled by the following CPU port defines:

    /**
    * Does RTEMS manage a dedicated interrupt stack in software?
    *
    * If TRUE, then a stack is allocated in @ref _ISR_Handler_initialization.
    * If FALSE, nothing is done.
    *
    * If the CPU supports a dedicated interrupt stack in hardware,
    * then it is generally the responsibility of the BSP to allocate it
    * and set it up.
    *
    * If the CPU does not support a dedicated interrupt stack, then
    * the porter has two options: (1) execute interrupts on the
    * stack of the interrupted task, and (2) have RTEMS manage a dedicated
    * interrupt stack.
    *
    * If this is TRUE, @ref CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.
    *
    * Only one of @ref CPU_HAS_SOFTWARE_INTERRUPT_STACK and
    * @ref CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE. It is
    * possible that both are FALSE for a particular CPU. Although it
    * is unclear what that would imply about the interrupt processing
    * procedure on that CPU.
    *
    * Port Specific Information:
    *
    * XXX document implementation including references if appropriate
    */
    #define CPU_HAS_SOFTWARE_INTERRUPT_STACK FALSE
    /**
    * Does this CPU have hardware support for a dedicated interrupt stack?
    *
    * If TRUE, then it must be installed during initialization.
    * If FALSE, then no installation is performed.
    *
    * If this is TRUE, @ref CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.
    *
    * Only one of @ref CPU_HAS_SOFTWARE_INTERRUPT_STACK and
    * @ref CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE. It is
    * possible that both are FALSE for a particular CPU. Although it
    * is unclear what that would imply about the interrupt processing
    * procedure on that CPU.
    *
    * Port Specific Information:
    *
    * XXX document implementation including references if appropriate
    */
    #define CPU_HAS_HARDWARE_INTERRUPT_STACK TRUE
    /**
    * Does RTEMS allocate a dedicated interrupt stack in the Interrupt Manager?
    *
    * If TRUE, then the memory is allocated during initialization.
    * If FALSE, then the memory is allocated during initialization.
    *
    * This should be TRUE is CPU_HAS_SOFTWARE_INTERRUPT_STACK is TRUE.
    *
    * Port Specific Information:
    *
    * XXX document implementation including references if appropriate
    */
    #define CPU_ALLOCATE_INTERRUPT_STACK TRUE

    Do the following steps to unify and simplify the initialization and interrupt stack support.

  • Add RTEMS_DECLARE_GLOBAL_SYMBOL() and RTEMS_DEFINE_GLOBAL_SYMBOL() macros to basedefs.h, to allow a global symbol definition via C code, e.g. in confdefs.h, to make the interrupt stack size available to the low level initialization code.
  • Add a special input section ".rtemsstack" to the linker command files to allow a placement of the interrupt stacks. The BSPs can provide the optimal memory location for this section, e.g. on-chip RAM, tightly-coupled memory.
  • This makes the CPU_HAS_SOFTWARE_INTERRUPT_STACK and CPU_HAS_HARDWARE_INTERRUPT_STACK CPU port defines superfluous, since the low level initialization code has all information available via global symbols.

    This makes the CPU_ALLOCATE_INTERRUPT_STACK CPU port define superfluous, since the interrupt stacks are allocated by confdefs.h for all architectures. There is no need for BSP-specific linker command file magic.

    The optional _CPU_Interrupt_stack_setup() is still useful to customize the registration of the interrupt stack area in the per-CPU information.

    Comment 1
    1. Sebastian Huber, Mon, 18 Jun 2018 06:30:48 GMT
    2. blocking: set to 3433
    Comment 2
    1. Sebastian Huber, Tue, 19 Jun 2018 13:27:08 GMT

    In b0c3ba2f/rtems:

    bsps: Remove superfluous bsp_processor_count This is unused copy and paste stuff. Update #3459.
    Comment 3
    1. Sebastian Huber, Wed, 20 Jun 2018 07:34:03 GMT

    Just for reference, the reuse of the initialization stack for the interrupt stack is only possible because boot_card() is a no-return function. This was not the case in RTEMS versions before 4.11.

    Comment 4
    1. Sebastian Huber, Fri, 22 Jun 2018 04:30:39 GMT

    In cc3edaa/rtems:

    config: SMP only CONFIGURE_MAXIMUM_PROCESSORS Do not set the CONFIGURE_MAXIMUM_PROCESSORS in uni-processor default configuration, since this may lead to an oversize workspace. Update #3459.
    Comment 5
    1. Sebastian Huber, Fri, 22 Jun 2018 04:30:49 GMT

    In 8ff5916c/rtems:

    stackchk: Remove dead code Update #3459.
    Comment 6
    1. Sebastian Huber, Fri, 22 Jun 2018 04:31:00 GMT

    In 1cb2e748/rtems:

    stackchk: Refactor Stack_check_Dump_threads_usage Update #3459.
    Comment 7
    1. Sebastian Huber, Fri, 22 Jun 2018 04:31:10 GMT

    In c47ad8e/rtems:

    stackchk: Add SMP support Check the interrupt stacks of all processors. Set up the interrupt stack of the current processor for high water testing in the thread begin extension. This must be done after multi-threading started, since the initialization stacks may reuse the interrupt stacks. Disable thread dispatching in SMP configurations to prevent thread migration. Writing to the interrupt stack is only safe if done from the corresponding processor in thread context. Update #3459.
    Comment 8
    1. Sebastian Huber, Fri, 22 Jun 2018 04:31:21 GMT

    In fe46647e/rtems:

    score: Macros to declare and define global symbols Add RTEMS_DEFINE_GLOBAL_SYMBOL() and add RTEMS_DECLARE_GLOBAL_SYMBOL(). Update #3459.
    Comment 9
    1. Sebastian Huber, Fri, 29 Jun 2018 09:53:49 GMT

    In c8df844/rtems:

    score: Add CPU_INTERRUPT_STACK_ALIGNMENT Add CPU port define for the interrupt stack alignment. The alignment should take the stack ABI and the cache line size into account. Update #3459.
    Comment 10
    1. Sebastian Huber, Fri, 29 Jun 2018 09:54:00 GMT

    In 715d616/rtems:

    bsps: Support .rtemsstack.* linker input sections Use a dedicated memory region or place it between the BSS and workspace. Update #3459.
    Comment 11
    1. Sebastian Huber, Fri, 29 Jun 2018 09:54:14 GMT

    In 511dc4b/rtems:

    Rework initialization and interrupt stack support Statically initialize the interrupt stack area (_Configuration_Interrupt_stack_area_begin, _Configuration_Interrupt_stack_area_end, and _Configuration_Interrupt_stack_size) via . Place the interrupt stack area in a special section ".rtemsstack.interrupt". Let BSPs define the optimal placement of this section in their linker command files (e.g. in a fast on-chip memory). This change makes makes the CPU_HAS_SOFTWARE_INTERRUPT_STACK and CPU_HAS_HARDWARE_INTERRUPT_STACK CPU port defines superfluous, since the low level initialization code has all information available via global symbols. This change makes the CPU_ALLOCATE_INTERRUPT_STACK CPU port define superfluous, since the interrupt stacks are allocated by confdefs.h for all architectures. There is no need for BSP-specific linker command file magic (except the section placement), see previous ARM linker command file as a bad example. Remove _CPU_Install_interrupt_stack(). Initialize the hardware interrupt stack in _CPU_Initialize() if necessary (e.g. m68k_install_interrupt_stack()). The optional _CPU_Interrupt_stack_setup() is still useful to customize the registration of the interrupt stack area in the per-CPU information. The initialization stack can reuse the interrupt stack, since interrupts are disabled during the sequential system initialization, and the boot_card() function does not return. This stack resuse saves memory. Changes per architecture: arm: Mostly replace the linker symbol based configuration of stacks with the standard configuration via CONFIGURE_INTERRUPT_STACK_SIZE. The size of the FIQ, ABT and UND mode stack is still defined via linker symbols. These modes are rarely used in applications and the default values provided by the BSP should be sufficient in most cases. Remove the bsp_processor_count linker symbol hack used for the SMP support. This is possible since the interrupt stack area is now allocated by the linker and not allocated from the heap. This makes some configure.ac stuff obsolete. Remove the now superfluous BSP variants altcycv_devkit_smp and realview_pbx_a9_qemu_smp. bfin: Remove unused magic linker command file allocation of initialization stack. Maybe a previous linker command file copy and paste problem? In the start.S the initialization stack is set to a hard coded value. lm32, m32c, mips, nios2, riscv, sh, v850: Remove magic linker command file allocation of initialization stack. Reuse interrupt stack for initialization stack. m68k: Remove magic linker command file allocation of initialization stack. Reuse interrupt stack for initialization stack. powerpc: Remove magic linker command file allocation of initialization stack. Reuse interrupt stack for initialization stack. Used dedicated memory region (REGION_RTEMSSTACK) for the interrupt stack on BSPs using the shared linkcmds.base (replacement for REGION_RWEXTRA). sparc: Remove the hard coded initialization stack. Use the interrupt stack for the initialization stack on the boot processor. This saves 16KiB of RAM. Update #3459.
    Comment 12
    1. Sebastian Huber, Tue, 03 Jul 2018 05:07:40 GMT

    In 156b227/rtems-tools:

    tester: Remove obsolete BSP variants Update #3459.
    Comment 13
    1. Sebastian Huber, Tue, 03 Jul 2018 05:12:58 GMT

    In 25f4db0/rtems-source-builder:

    5: Update tools to not build obsolete BSP variants Update #3459.
    Comment 14
    1. Sebastian Huber, Thu, 19 Jul 2018 05:38:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In efd581f/rtems-docs:

    cpu-supplement: Update interrupt stack paragraph Close #3459.
    Comment 15
    1. Sebastian Huber, Tue, 31 Jul 2018 05:13:55 GMT

    In 334e1d2/rtems:

    confdefs: Fix uniprocessor configuration Introduce a new internal define _CONFIGURE_MAXIMUM_PROCESSORS and ensure that it is _CONFIGURE_MAXIMUM_PROCESSORS > 1 only in SMP configurations. This avoids to allocate data structures for non-existing additional processors in uniprocessor configuration. Update #3459.
    Comment 16
    1. Sebastian Huber, Fri, 03 Aug 2018 11:04:49 GMT

    In 42f9963d/rtems:

    score: Remove superfluous semicolon This avoids warnings like this: warning: ISO C does not allow extra ';' outside of a function [-Wpedantic]
    RTEMS_DECLARE_GLOBAL_SYMBOL( abc );
    Update #3459.
    Comment 17
    1. Sebastian Huber, Mon, 03 Sep 2018 05:03:42 GMT

    In fad3f79b/rtems:

    bsps: BSP_INTERRUPT_STACK_AT_WORK_AREA_BEGIN Remove the BSP_INTERRUPT_STACK_AT_WORK_AREA_BEGIN hack. The interrupt stacks are now allocated by the linker. Update #3459.
    Comment 18
    1. Sebastian Huber, Thu, 06 Sep 2018 05:05:31 GMT

    In 54d87f2/rtems:

    bsps/powerpc: Simplify ppc_exc_initialize() Remove parameters from ppc_exc_initialize() since all BSPs passed the same values. Update #3459.
    Comment 19
    1. Sebastian Huber, Fri, 21 Sep 2018 06:08:11 GMT

    In 56e61e24/rtems:

    Remove INTERNAL_ERROR_INTERRUPT_STACK_TOO_SMALL The configured interrupt stack size (CONFIGURE_INTERRUPT_STACK_SIZE) is checked against the minimum task stack size. The minium tasks task stack size is also a configuration option (CONFIGURE_MINIMUM_TASK_STACK_SIZE). So, this check does not really help in case of configuration errors. In addition, the interrupt stack is also re-used as the initialization stack in most BSPs. It is probably better to use a stack checker to detect problems. Update #3459.
    Comment 20
    1. Sebastian Huber, Fri, 21 Sep 2018 06:08:34 GMT

    In 4221d93/rtems:

    stackchk: Improve support for interrupt stacks Prepare the interrupt stack which may be used by the boot processor as initialization stack with the stack sanity pattern. Check the interrupt stack of the current processor in the thread begin and switch extension. Update #3459.
    Comment 21
    1. Sebastian Huber, Mon, 24 Sep 2018 07:16:51 GMT

    In 7d1acc03/rtems:

    stackchk: Fix interrupt stack preparation We have to prepare the interrupt stack of each processor. Update #3459.
    Comment 22
    1. Sebastian Huber, Thu, 08 Nov 2018 07:11:03 GMT

    In ff081aee/rtems:

    score: Rename interrupt stack symbols Rename _Configuration_Interrupt_stack_area_begin in _ISR_Stack_area_begin, _Configuration_Interrupt_stack_area_end in _ISR_Stack_area_end, and _Configuration_Interrupt_stack_size in _ISR_Stack_size. Move definitions to . The new names are considerable shorter and in the right namespace. Update #3459.
    Comment 23
    1. Sebastian Huber, Wed, 14 Nov 2018 07:00:19 GMT

    In 5f32da0/rtems:

    bsp/or1k: Use interrupt stack for init stack Update #3459.
    Comment 24
    1. Sebastian Huber, Wed, 14 Nov 2018 07:48:05 GMT

    In a13b89b/rtems:

    bsp/i386: Use interrupt stack for init stack Update #3459.
    Comment 25
    1. Sebastian Huber, Mon, 19 Nov 2018 06:20:40 GMT

    In cc61d5c/rtems:

    bsps/m68k: Use interrupt stack for init stack Update #3459.
    Comment 26
    1. Sebastian Huber, Mon, 19 Nov 2018 06:20:49 GMT

    In 84e59b7c/rtems:

    bsps/powerpc: Use interrupt stack for init stack Move start.o to separate file. Update #3459.
    Comment 27
    1. Sebastian Huber, Mon, 19 Nov 2018 06:20:57 GMT

    In 508f319e/rtems:

    bsps/mips: Use interrupt stack for init stack Update #3459.
    Comment 28
    1. Sebastian Huber, Mon, 19 Nov 2018 06:21:05 GMT

    In a74ee417/rtems:

    bsps/bfin: Use interrupt stack for init stack Update #3459.
    Comment 29
    1. Sebastian Huber, Mon, 19 Nov 2018 06:21:13 GMT

    In 0ce6bf3/rtems:

    bsps/epiphany: Use interrupt stack for init stack Update #3459.
    Comment 30
    1. Sebastian Huber, Mon, 19 Nov 2018 06:21:22 GMT

    In 5f5bbd1/rtems:

    bsps/x86_64: Use interrupt stack for init stack Update #3459.
    Comment 31
    1. Sebastian Huber, Mon, 19 Nov 2018 06:21:30 GMT

    In 0989001/rtems:

    bsps/sparc64: Use interrupt stack for init stack Update #3459.
    Comment 32
    1. Sebastian Huber, Mon, 19 Nov 2018 06:21:37 GMT

    In 38f81bfc/rtems:

    bsps/nios2: Use interrupt stack for init stack Update #3459.
    Comment 33
    1. Sebastian Huber, Mon, 19 Nov 2018 06:21:45 GMT

    In 0a6a4ddb/rtems:

    bsps/moxie: Use interrupt stack for init stack Update #3459.
    Comment 34
    1. Sebastian Huber, Mon, 21 Jan 2019 08:18:34 GMT

    In 95c1921/rtems:

    bsps/arm: Remove unused bsp_stack_irq_size Update #3459.
    Comment 35
    1. Sebastian Huber, Fri, 15 Mar 2019 06:34:26 GMT

    In 9e48958/rtems:

    bsps/powerpc: Initialize stack earlier The eabi() call may use the stack. Update #3459.
    Comment 36
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3460 - GDB 8 SIS LEON2 LEON3 Patches

    Link https://devel.rtems.org/ticket/3460
    Id 3460
    Reporter Chris Johns
    Created 19 June 2018 00:18:39
    Modified 8 February 2019 09:23:44
    Owner Chris Johns
    Type defect
    Component tool/gdb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords leon2 leon3 sis gdb
    Cc  
    Blocking  
    Blocked by  

    Description

    Jiri patch for gdb-8.0.1.

    Attachments:

    1 Chris Johns, Tue, 19 Jun 2018 00:19:51 GMT
      attach: set to gdb-8.0.1-sis-leon2-leon3.diff
     
    2 Sebastian Huber, Mon, 17 Dec 2018 06:20:50 GMT
      attach: set to gdb-8.0.1-sis-leon3-smp.diff
    3 Chris Johns, Tue, 05 Feb 2019 04:19:58 GMT
      attach: set to gdb-8.2.1-sis-2.11.patch.bz2
     
    4 Chris Johns, Tue, 05 Feb 2019 04:20:30 GMT
      attach: set to gdb-8.2.1-riscv-config.patch
     
    5 Sebastian Huber, Fri, 08 Feb 2019 09:21:36 GMT
      attach: set to gdb-8.2.1-sis-2.12.patch
    6 Jiri Gaisler, Sun, 03 Mar 2019 08:54:25 GMT
      attach: set to gdb-8.2.1-sis-2.13.patch
     
    7 Jiri Gaisler, Thu, 08 Aug 2019 20:17:36 GMT
      attach: set to gdb-8.2.1-disable-sis.patch
     
    Comment 1
    1. Chris Johns, Tue, 19 Jun 2018 23:38:28 GMT

    In c571517/rtems-source-builder:

    gdb: Add a gdb-common configuration and have gdb-7-1 include it. Updates #3460
    Comment 2
    1. Chris Johns, Tue, 19 Jun 2018 23:38:37 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In ea6a042/rtems-source-builder:

    gdb: Download the gdb-8.0.1-sis-leon2-leon3 patch from an RTEMS ticket Closes #3460
    Comment 3
    1. Sebastian Huber, Mon, 17 Dec 2018 06:21:14 GMT
    2. summary: changed from GDB 8 SIS LEON2 LEON3 Patch to GDB 8 SIS LEON2 LEON3 Patches
    3. version: set to 5
    4. milestone: set to 5.1
    Comment 4
    1. Jiri Gaisler, Mon, 17 Dec 2018 07:17:39 GMT

    In 96673d7/rtems-source-builder:

    5: Add SMP support to SIS Update #3460.
    Comment 5
    1. Jiri Gaisler, Mon, 17 Dec 2018 07:21:41 GMT

    In 820eba4/rtems-tools:

    tester: Run leon3-sis with four processors Update #3460.
    Comment 6
    1. Sebastian Huber, Fri, 08 Feb 2019 09:23:44 GMT

    In ee40e0b/rtems-source-builder:

    5: Add GDB SIS patch Update #3460.

    3461 - Canadian cross compilation of RTEMS tools not supported for x86_64-w64-mingw32

    Link https://devel.rtems.org/ticket/3461
    Id 3461
    Reporter Sebastian Huber
    Created 19 June 2018 10:12:15
    Modified 19 June 2018 10:22:54
    Owner Sebastian Huber
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Tue, 19 Jun 2018 10:13:48 GMT

    In 2149755/rtems-source-builder:

    Fix CXC compilation of RTEMS tools Update #3461.
    Comment 2
    1. Sebastian Huber, Tue, 19 Jun 2018 10:17:47 GMT

    In 845054a/rtems-tools:

    Fix CXC build for x86-w64-mingw32 Update #3461.
    Comment 3
    1. Sebastian Huber, Tue, 19 Jun 2018 10:22:54 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 9e95b79/rtems-source-builder:

    5: Update tools for CXC x86_64-w32-mingw32 support Close #3461.

    3463 - Convert covoar to use DWARF function data

    Link https://devel.rtems.org/ticket/3463
    Id 3463
    Reporter Chris Johns
    Created 21 June 2018 07:46:46
    Modified 14 October 2018 01:07:48
    Owner  
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Convert covoar to use DWARF function data for the executable symbol table. Objdump is still needed for the instruction decode which is needed to find the instruction address boundaries.

    Comment 1
    1. Chris Johns, Sun, 14 Oct 2018 01:07:48 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    3465 - Integrate all changes from Linux v3.11 to v4.17 made in the JFFS2 sources

    Link https://devel.rtems.org/ticket/3465
    Id 3465
    Reporter Sebastian Huber
    Created 2 July 2018 05:40:49
    Modified 8 October 2018 05:16:02
    Owner Sebastian Huber
    Type task
    Component fs/jffs2
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The original import version of the JFFS2 sources was Linux v3.11 (September 2013). Update the JFFS2 sources to Linux v4.17.

    The Git command to generate the patches is:

    git format-patch v3.11..v4.17 -- include/uapi/linux/jffs2.h fs/jffs2/LICENCE fs/jffs2/acl.h fs/jffs2/build.c fs/jffs2/compr.c fs/jffs2/compr.h fs/jffs2/compr_rtime.c fs/jffs2/compr_rubin.c fs/jffs2/compr_zlib.c fs/jffs2/debug.c fs/jffs2/debug.h fs/jffs2/erase.c fs/jffs2/gc.c fs/jffs2/jffs2_fs_i.h fs/jffs2/jffs2_fs_sb.h fs/jffs2/nodelist.c fs/jffs2/nodelist.h fs/jffs2/nodemgmt.c fs/jffs2/read.c fs/jffs2/readinode.c fs/jffs2/scan.c fs/jffs2/summary.h fs/jffs2/write.c fs/jffs2/xattr.h 

    We need a source file transformation in the patches:

    sed -i 's%/fs/jffs2%/cpukit/libfs/src/jffs2/src%g' 00* 

    To support the first commit:

    From e8bbeeb755a077cfc0f814b07739f9225642d65c Mon Sep 17 00:00:00 2001
    From: Cody P Schafer
    Date: Thu, 23 Jan 2014 15:56:11 -0800
    Subject: [PATCH 01/24] fs/jffs2: use rbtree postorder iteration helper instead
    of opencoding
    Use rbtree_postorder_for_each_entry_safe() to destroy the rbtree instead
    of opencoding an alternate postorder iteration that modifies the tree
    Signed-off-by: Cody P Schafer
    Cc: Michel Lespinasse
    Cc: Jan Kara
    Cc: David Woodhouse
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    we have to a postorder iterator to the red-black tree support code.

    The remaining 23 patches are easy to apply.

    Comment 1
    1. Sebastian Huber, Mon, 16 Jul 2018 05:54:17 GMT

    In 6539bea/rtems:

    score: Add postorder tree iteration support Update #3465.
    Comment 2
    1. Sebastian Huber, Mon, 16 Jul 2018 05:58:13 GMT

    In 877aeab/rtems:

    linux: Install This makes it possible to test this API. Update #3465.
    Comment 3
    1. Sebastian Huber, Mon, 16 Jul 2018 06:02:08 GMT

    In 0cb4257/rtems:

    linux: Simplify Remove the placeholder struct rb_node and use RBTree_Node directly via some C pre-processor defines to adjust the member names. Update #3465.
    Comment 4
    1. Sebastian Huber, Mon, 16 Jul 2018 06:06:03 GMT

    In 22d9575/rtems:

    linux: Add rbtree_postorder_for_each_entry_safe() Update #3465.
    Comment 5
    1. Sebastian Huber, Mon, 16 Jul 2018 06:51:28 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 00a19d6/rtems:

    jffs2: Add README Add README to document the corrspending Linux version and the update procedure. Close #3465.
    Comment 6
    1. Sebastian Huber, Thu, 19 Jul 2018 05:12:49 GMT

    In b4f15d8/rtems:

    jffs2: Rename README to VERSION This makes it easer to find files describing an upstream version, e.g. via "find -name VERSION". Update #3465.
    Comment 7
    1. Sebastian Huber, Mon, 08 Oct 2018 05:16:02 GMT

    In 4a7c6867/rtems:

    Fix rbtree_postorder_for_each_entry_safe() Use the non-standard typeof operator to avoid code generation errors with clang and use of uninitialized variable warnings with GCC and Coverity Scan. Update #3465.

    3471 - Update libfdt as of date 2018-07-09

    Link https://devel.rtems.org/ticket/3471
    Id 3471
    Reporter Sebastian Huber
    Created 18 July 2018 07:30:59
    Modified 19 July 2018 05:07:52
    Owner Sebastian Huber
    Type project
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The initial import of libfdt was in 2015. Update it to the version as of date 2018-07-09.

    Comment 1
    1. Sebastian Huber, Thu, 19 Jul 2018 05:07:26 GMT
    2. description: modified (diff)
    3. summary: changed from Update libfdt to latest version to Update libfdt as of date 2018-07-09
    Comment 2
    1. Sebastian Huber, Thu, 19 Jul 2018 05:07:52 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 2af004e/rtems:

    dtc: Add VERSION file Close #3471.

    3472 - Update of libbsd to a version close to the FreeBSD 12 release

    Link https://devel.rtems.org/ticket/3472
    Id 3472
    Reporter Sebastian Huber
    Created 19 July 2018 05:20:30
    Modified 24 January 2019 06:35:25
    Owner Sebastian Huber
    Type project
    Component network/libbsd
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by 3507, 3508

    Description

    The FreeBSD project is about to prepare the FreeBSD 12 release soon:

    ​https://www.freebsd.org/releases/12.0R/schedule.html

    Use this time frame to update the libbsd stepwise to a FreeBSD trunk version close to the FreeBSD 12 release.

    Comment 1
    1. Sebastian Huber, Thu, 19 Jul 2018 05:28:07 GMT
    2. summary: changed from Update of libbsd to close to FreeBSD 12 release to Update of libbsd to a version close to the FreeBSD 12 release
    Comment 2
    1. Sebastian Huber, Wed, 08 Aug 2018 06:50:24 GMT

    In 71948f76/rtems:

    sys/event.h: Update version FreeBSD tag Update #3472.
    Comment 3
    1. Sebastian Huber, Fri, 10 Aug 2018 05:16:12 GMT

    In b8eae140/rtems:

    Add dummy PRI_MIN_KERN to Update #3472.
    Comment 4
    1. Sebastian Huber, Thu, 23 Aug 2018 12:39:04 GMT

    In a36aa86/rtems:

    Add dummy PI_SOFT to Update #3472.
    Comment 5
    1. Sebastian Huber, Fri, 24 Aug 2018 07:08:28 GMT

    In 6695d02/rtems:

    Update FreeBSD kernel timespec support This change is based on the following FreeBSD commit: "Make timespecadd(3) and friends public The timespecadd(3) family of macros were imported from NetBSD back in r35029. However, they were initially guarded by #ifdef _KERNEL. In the meantime, we have grown at least 28 syscalls that use timespecs in some way, leading many programs both inside and outside of the base system to redefine those macros. It's better just to make the definitions public. Our kernel currently defines two-argument versions of timespecadd and timespecsub. NetBSD, OpenBSD, and FreeDesktop?.org's libbsd, however, define three-argument versions. Solaris also defines a three-argument version, but only in its kernel. This revision changes our definition to match the common three-argument version. Bump _FreeBSD_version due to the breaking KPI change. Discussed with: cem, jilles, ian, bde Differential Revision: ​https://reviews.freebsd.org/D14725" To make the change public (outside #ifdef _KERNEL) it must be integrated in Newlib. Update #3472.
    Comment 6
    1. Sebastian Huber, Fri, 24 Aug 2018 07:37:03 GMT

    In f62c62d/rtems-libbsd:

    Update rtems-bsd-kernel-namespace.h Update #3472.
    Comment 7
    1. Sebastian Huber, Mon, 27 Aug 2018 05:41:55 GMT

    In 27c89d7/rtems:

    Add FreeBSD kernel space header files Move the kernel space content of some Newlib provided header files to RTEMS and libbsd. This allows to use the Newlib provided header files with different FreeBSD baselines. Update #3472.
    Comment 8
    1. Sebastian Huber, Mon, 27 Aug 2018 05:42:05 GMT

    In 6d70a11/rtems:

    Include in The FreeBSD kernel started to use the bool type. Update #3472.
    Comment 9
    1. Sebastian Huber, Mon, 27 Aug 2018 05:45:56 GMT

    In 63084c1/rtems-libbsd:

    IPFW(4): Remove FreeBSD import This firewall was not ported to RTEMS and is just dead code which may make trouble during FreeBSD baseline updates. It also increased the compile-time of the library for nothing. Update #3472.
    Comment 10
    1. Sebastian Huber, Mon, 27 Aug 2018 05:46:04 GMT

    In ee738dd/rtems-libbsd:

    WPA_SUPPLICANT(8): Remove unused files Remove unused files which may make trouble during FreeBSD baseline updates. It also increased the compile-time of the library for nothing. Update #3472.
    Comment 11
    1. Sebastian Huber, Mon, 27 Aug 2018 05:46:12 GMT

    In 4c22b5c/rtems-libbsd:

    Add FreeBSD kernel space header files Move the kernel space content of some Newlib provided header files to RTEMS and libbsd. This allows to use the Newlib provided header files with different FreeBSD baselines. Update #3472.
    Comment 12
    1. Sebastian Huber, Mon, 27 Aug 2018 05:46:19 GMT

    In dd60daa/rtems-libbsd:

    Allow *.c as kernel space header files This is a workaround for the FreeBSD kernel space source file
    sys/opencrypto/xform.c
    which includes a bunch of *.c files. Update #3472.
    Comment 13
    1. Sebastian Huber, Tue, 28 Aug 2018 05:13:25 GMT

    In 0230202/rtems-source-builder:

    5: Update Newlib Pick up POSIX header file changes for an upcomming FreeBSD baseline update in libbsd. Update #3472. Close #3491.
    Comment 14
    1. Sebastian Huber, Tue, 28 Aug 2018 06:06:30 GMT
    2. blockedby: set to 3507
    Comment 15
    1. Sebastian Huber, Tue, 28 Aug 2018 07:41:50 GMT

    In 100e66f/rtems-libbsd:

    kvaddr_t is now provided by Update #3472.
    Comment 16
    1. Sebastian Huber, Wed, 29 Aug 2018 12:24:14 GMT
    2. blockedby: changed from 3507 to 3507, 3508
    Comment 17
    1. Sebastian Huber, Mon, 10 Sep 2018 09:37:39 GMT

    In e58f1cd3/rtems:

    Add more dummy values to Update #3472.
    Comment 18
    1. Sebastian Huber, Fri, 21 Sep 2018 08:36:41 GMT

    In ab4fe11/rtems-libbsd:

    CONTRIBUTING.md: Avoid explicit commit numbers Update #3472.
    Comment 19
    1. Sebastian Huber, Fri, 21 Sep 2018 08:36:48 GMT

    In 2707771/rtems-libbsd:

    libbsd.txt: Avoid explicit versions Update #3472.
    Comment 20
    1. Sebastian Huber, Fri, 21 Sep 2018 08:37:13 GMT

    In de261e0/rtems-libbsd:

    Update to FreeBSD head 2017-06-01 Git mirror commit dfb26efac4ce9101dda240e94d9ab53f80a9e131. Update #3472.
    Comment 21
    1. Sebastian Huber, Fri, 21 Sep 2018 08:37:23 GMT

    In c37f9fb/rtems-libbsd:

    Update to FreeBSD head 2017-08-01 Git mirror commit f5002f5e5f78cae9f0269d812dc0aedb0339312c. Update #3472.
    Comment 22
    1. Sebastian Huber, Fri, 21 Sep 2018 08:37:32 GMT

    In e4a8065/rtems-libbsd:

    Update to FreeBSD head 2017-10-01 Git mirror commit b2f0376b45428f13151d229c5ae9d4d8f74acbd1. Update #3472.
    Comment 23
    1. Sebastian Huber, Fri, 21 Sep 2018 08:37:46 GMT

    In bb80d9d/rtems-libbsd:

    Update to FreeBSD head 2017-12-01 Git mirror commit e724f51f811a4b2bd29447f8b85ab5c2f9b88266. Update #3472.
    Comment 24
    1. Sebastian Huber, Fri, 21 Sep 2018 08:37:57 GMT

    In 18fa92c/rtems-libbsd:

    Update to FreeBSD head 2018-02-01 Git mirror commit d079ae0442af8fa3cfd6d7ede190d04e64a2c0d4. Update #3472.
    Comment 25
    1. Sebastian Huber, Fri, 21 Sep 2018 08:38:07 GMT

    In 2df56db/rtems-libbsd:

    Update to FreeBSD head 2018-04-01 Git mirror commit 8dfb1ccc26d1cea7e2529303003ff61f9f1784c4. Update #3472.
    Comment 26
    1. Sebastian Huber, Fri, 21 Sep 2018 08:38:20 GMT

    In bcdce02/rtems-libbsd:

    Update to FreeBSD head 2018-06-01 Git mirror commit fb63610a69b0eb7f69a201ba05c4c1a7a2739cf9. Update #3472.
    Comment 27
    1. Sebastian Huber, Fri, 21 Sep 2018 08:38:28 GMT

    In baf1ca7/rtems-libbsd:

    ck: Use atomic built-ins Update #3472.
    Comment 28
    1. Sebastian Huber, Fri, 21 Sep 2018 08:38:35 GMT

    In 3becda1/rtems-libbsd:

    ck: Define CK_MD_PPC32_LWSYNC if available This is option has a huge performance impact. Update #3472.
    Comment 29
    1. Sebastian Huber, Fri, 21 Sep 2018 08:38:50 GMT

    In 3489e3b/rtems-libbsd:

    Update to FreeBSD head 2018-09-17 Git mirror commit 6c2192b1ef8c50788c751f878552526800b1e319. Update #3472.
    Comment 30
    1. Sebastian Huber, Fri, 21 Sep 2018 08:38:58 GMT

    In 1af372a/rtems-libbsd:

    ck: No hardware barriers in uniprocessor configs Update #3472.
    Comment 31
    1. Sebastian Huber, Fri, 21 Sep 2018 08:39:06 GMT

    In be6515d/rtems-libbsd:

    ck: Use relaxed memory order if possible In uniprocessor configurations we can use a relaxed memory order and compiler memory barriers should be sufficient. Update #3472.
    Comment 32
    1. Sebastian Huber, Mon, 24 Sep 2018 06:01:50 GMT

    In 7aba2a4/rtems-libbsd:

    ck: Install header files Update #3472.
    Comment 33
    1. Sebastian Huber, Thu, 13 Dec 2018 10:34:48 GMT

    In f80abf0/rtems-source-builder:

    5: Update Newlib Pick up updates from FreeBSD. Update #3472.
    Comment 34
    1. Sebastian Huber, Fri, 21 Dec 2018 11:04:36 GMT

    In 78dc8cd/rtems-source-builder:

    5: Update Newlib Pick up FreeBSD compatibility improvements. Update #3472.
    Comment 35
    1. Sebastian Huber, Thu, 24 Jan 2019 06:35:25 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    The master branch is now based on a post FreeBSD 12 release trunk. There is now also a 5-freebsd-12 branch which tracks the FreeBSD stable/12 branch.


    3475 - Add RTEMS_PREDICT_TRUE() and RTEMS_PREDICT_FALSE() for static branch prediction hints

    Link https://devel.rtems.org/ticket/3475
    Id 3475
    Reporter Sebastian Huber
    Created 24 July 2018 06:51:56
    Modified 25 July 2018 08:10:04
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add macros to for the GNU extension builtin_expect(). Use RTEMS_PREDICT_TRUE() and RTEMS_PREDICT_FALSE() similar to the FreeBSD predict_true() and predict_false(). Alternatives are the Linux likely() and unlikely() or directly the GCC builtin_expect(), however, the FreeBSD names seem to be the most easy to understand.

    Comment 1
    1. Sebastian Huber, Tue, 24 Jul 2018 06:52:30 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Wed, 25 Jul 2018 08:10:04 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a1f7d7d/rtems:

    score: RTEMS_PREDICT_TRUE(), RTEMS_PREDICT_FALSE() Add RTEMS_PREDICT_TRUE() and RTEMS_PREDICT_FALSE() for static branch prediction hints. Close #3475.

    3478 - RISCV BSP Tester Cleanup Needed

    Link https://devel.rtems.org/ticket/3478
    Id 3478
    Reporter Joel Sherrill
    Created 25 July 2018 23:30:21
    Modified 24 August 2018 05:14:07
    Owner Sebastian Huber
    Type defect
    Component arch/riscv
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    rtems-tools currently has the following bsp testing configurations:

    $ find . -name "*riscv*ini"
    ./tester/rtems/rtems-bsps-riscv64.ini
    ./tester/rtems/testing/bsps/riscv64_generic.ini
    ./tester/rtems/testing/bsps/riscv_generic.ini
    ./tester/rtems/rtems-bsps-riscv32.ini

    rtems-bsps.ini does not include the riscv.

    tester/rtems/rtems-bsps-tiers.ini does not list the riscv

    Comment 1
    1. Joel Sherrill, Wed, 25 Jul 2018 23:30:37 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Fri, 24 Aug 2018 05:14:07 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Fixed by #3433.


    3480 - CONFIGURE_MINIMUM_TASK_STACK_SIZE may affect CONFIGURE_INTERRUPT_STACK_SIZE

    Link https://devel.rtems.org/ticket/3480
    Id 3480
    Reporter Sebastian Huber
    Created 30 July 2018 05:55:31
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type defect
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    In case an application defines CONFIGURE_MINIMUM_TASK_STACK_SIZE, then this may change the CONFIGURE_INTERRUPT_STACK_SIZE as well:

    #ifndef CONFIGURE_INTERRUPT_STACK_SIZE
    #ifdef BSP_INTERRUPT_STACK_SIZE
    #define CONFIGURE_INTERRUPT_STACK_SIZE BSP_INTERRUPT_STACK_SIZE
    #else
    #define CONFIGURE_INTERRUPT_STACK_SIZE CONFIGURE_MINIMUM_TASK_STACK_SIZE
    #endif
    #endif

    I think this is not what a user expects.

    Comment 1
    1. Sebastian Huber, Mon, 30 Jul 2018 05:57:30 GMT

    This behaviour is more or less documented:

    ​https://docs.rtems.org/branches/master/c-user/configuring_a_system.html#configure-interrupt-stack-size

    The documentation doesn't mention that BSP_INTERRUPT_STACK_SIZE is involved too.

    Comment 2
    1. Sebastian Huber, Mon, 30 Jul 2018 05:58:03 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 3
    1. Sebastian Huber, Wed, 24 Oct 2018 05:03:10 GMT

    In 05a5366/rtems-docs:

    c-user: Modify CONFIGURE_INTERRUPT_STACK_SIZE Use CPU_STACK_MINIMUM_SIZE instead of CONFIGURE_MINIMUM_TASK_STACK_SIZE to set the default value. Clarify documentation. Update #3480.
    Comment 4
    1. Sebastian Huber, Thu, 25 Oct 2018 04:43:01 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 24b5807/rtems:

    config: Modify CONFIGURE_INTERRUPT_STACK_SIZE Use CPU_STACK_MINIMUM_SIZE instead of CONFIGURE_MINIMUM_TASK_STACK_SIZE to set the default value. Close #3480.
    Comment 5
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3482 - Relax the buffer alignment required by rtems_partition_create()

    Link https://devel.rtems.org/ticket/3482
    Id 3482
    Reporter Sebastian Huber
    Created 2 August 2018 12:37:58
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    Buffer alignment required by rtems_partition_create() is too strict since it is checked via _Addresses_Is_aligned() which is

    RTEMS_INLINE_ROUTINE bool _Addresses_Is_aligned (
    const void *address
    )
    {
    #if (CPU_ALIGNMENT == 0)
    return true;
    #else
    return (((uintptr_t)address % CPU_ALIGNMENT) == 0);
    #endif
    }

    The CPU_ALIGNMENT must take long double and vector data type alignment requirements into account. For the partition maintenance only pointer alignment is required. The user should ensure that its buffer is suitable for the items it wants to manage. The user should not be burdened to provide buffers with the maximum architecture alignment, e.g. why need a 16 byte aligned buffer if you want to manage items with 4 byte integers only?

    Comment 1
    1. Sebastian Huber, Fri, 03 Aug 2018 11:04:28 GMT

    In 27bbc05/rtems:

    score: Remove CPU_PARTITION_ALIGNMENT Use the CPU_SIZEOF_POINTER alignment instead. The internal alignment requirement is defined by the use of Chain_Node (consisting of two pointers) to manage the free chain of partitions. It seems that previously the condition
    CPU_PARTITION_ALIGNMENT >= sizeof(Chain_Node)
    was true on all CPU ports. Now, we need an additional check. Update #3482.
    Comment 2
    1. Sebastian Huber, Fri, 03 Aug 2018 11:04:38 GMT

    In 83ca9f0a/rtems:

    rtems: Relax partition buffer area alignment The partition buffer area alignment required by rtems_partition_create() was too strict since it was checked via _Addresses_Is_aligned() which uses CPU_ALIGNMENT. The CPU_ALIGNMENT must take long double and vector data type alignment requirements into account. For the partition maintenance only pointer alignment is required (Chain_Node, which consists of two pointers). The user should ensure that its partition buffer area is suitable for the items it wants to manage. The user should not be burdened to provide buffers with the maximum architecture alignment, e.g. why need a 16 byte aligned buffer if you want to manage items with 4 byte integers only? Update #3482.
    Comment 3
    1. Sebastian Huber, Mon, 06 Aug 2018 06:04:50 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a0e6488/rtems-docs:

    c-user: Update partition create documentation Add an example. Close #3482.
    Comment 4
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3484 - RFS: Remove stray call of rtems_disk_release() in rtems_rfs_buffer_sync()

    Link https://devel.rtems.org/ticket/3484
    Id 3484
    Reporter Sebastian Huber
    Created 6 August 2018 06:10:16
    Modified 10 August 2018 04:55:38
    Owner Sebastian Huber
    Type defect
    Component fs/rfs
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3494, 3495
    Blocked by  

    Description

    The function rtems_rfs_buffer_sync() erroneously calls rtems_disk_release(). This screws up the reference counting of the disk.

    Comment 1
    1. Sebastian Huber, Tue, 07 Aug 2018 05:24:56 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    4. version: changed from 4.10 to 5
    5. milestone: changed from 4.10.3 to 5.1
    Comment 2
    1. Sebastian Huber, Tue, 07 Aug 2018 05:40:10 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d56e68b/rtems:

    rfs: Remove erroneous call of rtems_disk_release() The function rtems_rfs_buffer_sync() erroneously calls rtems_disk_release(). This screws up the reference counting of the disk. Close #3484.
    Comment 3
    1. Sebastian Huber, Fri, 10 Aug 2018 04:54:58 GMT
    2. blocking: set to 3494
    Comment 4
    1. Sebastian Huber, Fri, 10 Aug 2018 04:55:38 GMT
    2. blocking: changed from 3494 to 3494, 3495

    3486 - Use uintptr_t and size_t instead of uint32_t in rtems_partition_create()

    Link https://devel.rtems.org/ticket/3486
    Id 3486
    Reporter Sebastian Huber
    Created 6 August 2018 08:42:31
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    Use uintptr_t to specify the length of the partition buffer area instead of uint32_t. This is in line with rtems_region_create(). On 64-bit targets, the length may exceed 4GiB. Use size_t for the buffer size, since on some targets the single object size is less than the overall address range, e.g. m32c sizeof(uintptr_t) > sizeof(size_t).

    Comment 1
    1. Sebastian Huber, Fri, 10 Aug 2018 05:17:59 GMT

    In 66cb142/rtems:

    rtems: Parameter types in rtems_partition_create() Use uintptr_t to specify the length of the partition buffer area instead of uint32_t. This is in line with rtems_region_create(). On 64-bit targets, the length may exceed 4GiB. Use size_t for the buffer size, since on some targets the single object size is less than the overall address range, e.g. m32c sizeof(uintptr_t) > sizeof(size_t). Update #3486.
    Comment 2
    1. Sebastian Huber, Fri, 10 Aug 2018 05:18:10 GMT

    In b2de426/rtems:

    score: Fix _Addresses_Subtract() Use architecture-specific integer type for an address difference. Update #3486.
    Comment 3
    1. Sebastian Huber, Fri, 10 Aug 2018 05:20:18 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 0c4f2be/rtems-docs:

    c-user: Adjust integer types in partition create Close #3486.
    Comment 4
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3488 - Remove CONFIGURE_HAS_OWN_MOUNT_TABLE

    Link https://devel.rtems.org/ticket/3488
    Id 3488
    Reporter Sebastian Huber
    Created 8 August 2018 07:10:12
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    RTEMS has the configuration option CONFIGURE_HAS_OWN_MOUNT_TABLE since 1999. This configuration option is broken since RTEMS 4.11. Remove this broken configuration option.

    Comment 1
    1. Sebastian Huber, Wed, 19 Sep 2018 08:52:32 GMT

    In 5fa0a1f6/rtems:

    config: Remove CONFIGURE_HAS_OWN_MOUNT_TABLE RTEMS had the configuration option CONFIGURE_HAS_OWN_MOUNT_TABLE since This configuration option was broken since RTEMS 4.11. Remove this broken configuration option. Update #3488.
    Comment 2
    1. Sebastian Huber, Wed, 19 Sep 2018 08:53:13 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 11040cf/rtems-docs:

    c-user: Remove CONFIGURE_HAS_OWN_MOUNT_TABLE Close #3488.
    Comment 3
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3489 - Obsolete CONFIGURE_HAS_OWN_CONFIGURATION_TABLE

    Link https://devel.rtems.org/ticket/3489
    Id 3489
    Reporter Sebastian Huber
    Created 8 August 2018 07:13:06
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3490
    Blocked by  

    Description

    Obsolete the CONFIGURE_HAS_OWN_CONFIGURATION_TABLE configuration option. The RTEMS configuration should be done via explicit configuration options to allow more freedom for implementation changes.

    Comment 1
    1. Sebastian Huber, Wed, 08 Aug 2018 07:14:19 GMT
    2. blocking: set to 3490
    Comment 2
    1. Chris Johns, Wed, 08 Aug 2018 07:28:53 GMT

    Should this be deprecated for a release before being removed?

    Maybe the question should be asked on the user and devel lists if there are users?

    Comment 3
    1. Sebastian Huber, Wed, 08 Aug 2018 07:30:23 GMT

    Normally, I would say that we should deprecate it, however, it is broken since RTEMS 4.11 and we didn't get a bug report or complaint. There is also no test case for this configuration option.

    Comment 4
    1. Sebastian Huber, Wed, 08 Aug 2018 07:31:47 GMT

    Replying to Sebastian Huber:

    Normally, I would say that we should deprecate it, however, it is broken since RTEMS 4.11 and we didn't get a bug report or complaint. There is also no test case for this configuration option.

    Sorry, I answered to the wrong ticket.

    Obsolete == deprecate? Next step is remove in 6.1 (#3490).

    Comment 5
    1. Chris Johns, Wed, 08 Aug 2018 07:37:57 GMT

    Thank you. Anyone interested can now see the reason.

    Comment 6
    1. Sebastian Huber, Wed, 08 Aug 2018 07:41:30 GMT

    Sorry, I added some confusion. The reason for this change is in the ticket description. Maybe I should delete this comment:

    ​https://devel.rtems.org/ticket/3489#comment:3

    Comment 7
    1. Sebastian Huber, Wed, 19 Sep 2018 08:52:44 GMT

    In 68f339b6/rtems:

    Remove CONFIGURE_HAS_OWN_CONFIGURATION_TABLE The RTEMS configuration should be done via explicit configuration options to allow more freedom for implementation changes. Update #3489. Update #3490.
    Comment 8
    1. Sebastian Huber, Wed, 19 Sep 2018 08:53:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In cec2f2c/rtems-docs:

    Remove CONFIGURE_HAS_OWN_CONFIGURATION_TABLE Close #3489. Close #3490.
    Comment 9
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3490 - Remove CONFIGURE_HAS_OWN_CONFIGURATION_TABLE

    Link https://devel.rtems.org/ticket/3490
    Id 3490
    Reporter Sebastian Huber
    Created 8 August 2018 07:14:19
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by 3489, 3735

    Description

    This configuration option was obsoleted in RTEMS 5.1.

    Comment 1
    1. Joel Sherrill, Wed, 08 Aug 2018 13:42:38 GMT

    I think I proposed removing option on the devel@ list a while back. Normally I prefer to deprecate for one cycle as this ticket proposes but I don't see how anyone could be using this. The rate of change to the internal configuration with addition of SMP has been intense. There have been no questions indicating someone is trying to trail the CONFIGURE_xxx interface on their own.

    It isn't a huge feature, but I really don't think it is used. If there is consensus, I wouldn't be opposed to killing it now. But now a huge deal.

    Comment 2
    1. Sebastian Huber, Thu, 06 Sep 2018 05:14:46 GMT
    2. version: changed from 6 to 5
    3. milestone: changed from 6.1 to 5.1
    Comment 3
    1. Sebastian Huber, Wed, 19 Sep 2018 08:52:44 GMT

    In 68f339b6/rtems:

    Remove CONFIGURE_HAS_OWN_CONFIGURATION_TABLE The RTEMS configuration should be done via explicit configuration options to allow more freedom for implementation changes. Update #3489. Update #3490.
    Comment 4
    1. Sebastian Huber, Wed, 19 Sep 2018 08:53:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In cec2f2c/rtems-docs:

    Remove CONFIGURE_HAS_OWN_CONFIGURATION_TABLE Close #3489. Close #3490.
    Comment 5
    1. Sebastian Huber, Tue, 09 Apr 2019 06:59:10 GMT
    2. blockedby: changed from 3489 to 3489, 3735
    Comment 6
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3491 - Align mprotect() prototype with POSIX

    Link https://devel.rtems.org/ticket/3491
    Id 3491
    Reporter Sebastian Huber
    Created 8 August 2018 09:16:59
    Modified 28 August 2018 05:13:25
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The correct prototype is:

    int    mprotect(void *, size_t, int); 
    Comment 1
    1. Sebastian Huber, Fri, 10 Aug 2018 05:15:40 GMT

    In aac36d15/rtems:

    posix: Add configure check for mprotect() Update #3491.
    Comment 2
    1. Sebastian Huber, Tue, 28 Aug 2018 05:13:25 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 0230202/rtems-source-builder:

    5: Update Newlib Pick up POSIX header file changes for an upcomming FreeBSD baseline update in libbsd. Update #3472. Close #3491.

    3496 - Remove superfluous interrupt enable in _Thread_Dispatch_enable()

    Link https://devel.rtems.org/ticket/3496
    Id 3496
    Reporter Sebastian Huber
    Created 10 August 2018 05:08:18
    Modified 20 August 2018 06:37:24
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3497
    Blocked by  

    Description

    The _Thread_Dispatch_enable() contains a superfluous interrupt enable. This bug had probably no effect since the interrupt enable is idempotent on all CPU ports.

    RTEMS_INLINE_ROUTINE void _Thread_Dispatch_enable( Per_CPU_Control *cpu_self )
    {
    uint32_t disable_level = cpu_self->thread_dispatch_disable_level;
    if ( disable_level == 1 ) {
    ISR_Level level;
    _ISR_Local_disable( level );
    if (
    cpu_self->dispatch_necessary
    #if defined(RTEMS_SCORE_ROBUST_THREAD_DISPATCH)
    || !_ISR_Is_enabled( level )
    #endif
    ) {
    _Thread_Do_dispatch( cpu_self, level ); <-- This function enabled interrupts
    } else {
    cpu_self->thread_dispatch_disable_level = 0;
    _Profiling_Thread_dispatch_enable( cpu_self, 0 );
    }
    _ISR_Local_enable( level ); <-- Here we enable it again
    } else {
    _Assert( disable_level > 0 );
    cpu_self->thread_dispatch_disable_level = disable_level - 1;
    }
    }
    Comment 1
    1. Sebastian Huber, Fri, 10 Aug 2018 05:09:03 GMT
    2. blocking: set to 3497
    Comment 2
    1. Sebastian Huber, Fri, 10 Aug 2018 05:09:33 GMT
    2. component: changed from admin to score
    Comment 3
    1. Sebastian Huber, Mon, 20 Aug 2018 06:37:24 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d14f934/rtems:

    score: Fix ISR enable in _Thread_Dispatch_enable() This bug had probably no effect since the interrupt enable is idempotent on all CPU ports. Close #3496.

    3498 - Command and Variable Index is empty

    Link https://devel.rtems.org/ticket/3498
    Id 3498
    Reporter Jens Schweikhardt
    Created 10 August 2018 07:23:11
    Modified 20 August 2018 06:27:25
    Owner Sebastian Huber
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The Command and Variable Index, ​https://docs.rtems.org/branches/master/cpu-supplement/command.html does not contain any commands or variables.

    If this chapter does not apply to RTEMS it should not be generated.
    If it does apply, it should contain what its title promises.

    Comment 1
    1. Sebastian Huber, Fri, 10 Aug 2018 07:28:50 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to accepted
    4. version: set to 5
    5. milestone: set to 5.1
    Comment 2
    1. Sebastian Huber, Mon, 20 Aug 2018 06:27:25 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 762b8d7/rtems-docs:

    cpu-supplement: Remove empty command/vars chapter Close #3498.

    3499 - The "Index" chapter is empty

    Link https://devel.rtems.org/ticket/3499
    Id 3499
    Reporter Jens Schweikhardt
    Created 10 August 2018 07:26:57
    Modified 20 August 2018 06:27:38
    Owner Sebastian Huber
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The "Index" chapter, ​https://docs.rtems.org/branches/master/cpu-supplement/genindex.html is empty.

    This chapter should contain a usable and helpful index or not be generated at all.

    Comment 1
    1. Sebastian Huber, Fri, 10 Aug 2018 07:36:55 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to accepted
    4. version: set to 5
    5. milestone: set to 5.1

    Due to the hierarchical structure of this document I think an index is not necessary. There is also probably nobody available to write one.

    Comment 2
    1. Sebastian Huber, Mon, 20 Aug 2018 06:27:38 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 67195aa/rtems-docs:

    cpu-supplement: Remove empty index Due to the hierarchical structure an index is not absolutely necessary and an empty index is not helpful. The document sources contain no index directives. Close #3499.

    3500 - Change rtems_waf's RTEMS path check from bin to share/rtems`

    Link https://devel.rtems.org/ticket/3500
    Id 3500
    Reporter Chris Johns
    Created 12 August 2018 01:14:11
    Modified 12 August 2018 01:59:21
    Owner Chris Johns <chrisj@…>
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords rtems_waf libbsd
    Cc  
    Blocking  
    Blocked by  

    Description

    Currently rtems_waf checks for a bin directory in the RTEMS path. There is no bin directory any more so this test needs to be changed to share/rtems.

    Comment 1
    1. Chris Johns, Sun, 12 Aug 2018 01:59:21 GMT
    2. owner: set to Chris Johns <chrisj@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In c0d52d5/rtems_waf:

    Change RTEMS path check from bin to share/rtems. There is no bin directory anymore with RTEMS 5 so the test fails. Check for the share/rtems directory. Closes #3500.

    3501 - MSR_RI defined multiple places

    Link https://devel.rtems.org/ticket/3501
    Id 3501
    Reporter Joel Sherrill
    Created 14 August 2018 23:23:02
    Modified 15 August 2018 15:44:16
    Owner Christian Mauderer
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Two files define the MSR_RI macro. Since one is a register name on the PowerPC, this shows up on 48 PowerPC BSPs. This is one example.

    log/powerpc-qoriq_e6500_64.log:../../../../../../rtems/c/src/../../cpukit/dev/serial/sc16is752-regs.h:117:0: warning: "MSR_RI" redefined
    log/powerpc-qoriq_e6500_64.log: #define MSR_RI (1u << 6)
    log/powerpc-qoriq_e6500_64.log: #define MSR_RI (1<<1) /* Recoverable Exception */
    log/powerpc-qoriq_e6500_64.log:../../../../../../rtems/c/src/../../cpukit/dev/serial/sc16is752-regs.h:117:0: warning: "MSR_RI" redefined
    log/powerpc-qoriq_e6500_64.log: #define MSR_RI (1u << 6)
    log/powerpc-qoriq_e6500_64.log: #define MSR_RI (1<<1) /* Recoverable Exception */

    Comment 1
    1. Joel Sherrill, Tue, 14 Aug 2018 23:23:52 GMT
    2. owner: set to Christian Mauderer
    3. status: changed from new to assigned

    Assigning to Christian since the git log says he added the file cpukit/dev/serial/sc16is752-regs.h

    Comment 2
    1. Christian Mauderer, Wed, 15 Aug 2018 07:41:32 GMT

    Also I didn't add the file but only the line in that file, it's quite clearly my responsibility. I was sure that this driver is only used in the ATSAM-BSP. But it seems that it is compiled for every BSP. I'll add a prefix to the register names and send a patch.

    Comment 3
    1. Christian Mauderer, Wed, 15 Aug 2018 15:44:16 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In dcaea71/rtems:

    dev/sc16is752: Add name space for field names. The field names for the registers generated a name collision (MSR_RI on the power pc). This patch adds a SC16IS752_ prefix for all field names. Closes #3501.

    3502 - PL111_LCD_CONTROL_LCD_BPP_16 Redefined

    Link https://devel.rtems.org/ticket/3502
    Id 3502
    Reporter Joel Sherrill
    Created 14 August 2018 23:31:03
    Modified 20 August 2018 06:36:58
    Owner Sebastian Huber
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The constant PL111_LCD_CONTROL_LCD_BPP_16 is defined twice in the file bsps/arm/include/bsp/arm-pl111-regs.h:

    #define PL111_LCD_CONTROL_LCD_BPP_16 0x04U
    #define PL111_LCD_CONTROL_LCD_BPP_24 0x05U
    #define PL111_LCD_CONTROL_LCD_BPP_16 0x06U
    #define PL111_LCD_CONTROL_LCD_BPP_12 0x07U

    Given the context, I am guessing the first one should be BPP_32 but since Sebastian added the file, I am assuming he has docs and can answer this question for sure.

    Comment 1
    1. Joel Sherrill, Tue, 14 Aug 2018 23:31:18 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Mon, 20 Aug 2018 06:36:58 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 2cd3716/rtems:

    bsps/arm: Fix PL111 register define re-definition Close #3502.

    3503 - PDF Documentation is missing an index

    Link https://devel.rtems.org/ticket/3503
    Id 3503
    Reporter Chris Johns
    Created 21 August 2018 01:15:54
    Modified 21 August 2018 05:00:24
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The PDF generated documents have an empty index.

    Comment 1
    1. Chris Johns, Tue, 21 Aug 2018 02:14:12 GMT

    We cannot have a genindex.rst file, the documentation reserves this for a generated file. Removing the genindex entry from the TOC of a document results in the PDF having an index. Removing the genindex entry from the TOC removes the index from the HTML generated output.

    The solution is to specialize the HTML template however the template processing in common and common/waf.py looks broken. The path in common/conf.py is a build path that is not present and the common templates are copied into each docs HTML build tree and the path in the file is relative to the top directory.

    Comment 2
    1. Chris Johns, Tue, 21 Aug 2018 03:48:28 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 5ce8e43/rtems-docs:

    build: Fix indexing so it works on HTML and PDF. Remove all genindex.rst files, these are generated and should not exist in our source. Fix the HTML templates so the local specialisation works. Add a index link to the sidebar for HTML. Note, there is no TOC entry for the index in the PDF output and I cannot figure out how to add one. Closes #3503
    Comment 3
    1. Sebastian Huber, Tue, 21 Aug 2018 05:00:24 GMT
    2. component: changed from admin to doc

    3504 - Warning and formatting in bsps/powerpc/mpc55xxevb/dev/dspi.c

    Link https://devel.rtems.org/ticket/3504
    Id 3504
    Reporter Joel Sherrill
    Created 22 August 2018 17:01:54
    Modified 6 September 2018 05:05:21
    Owner Sebastian Huber
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This is a printf format warning. Also the file is formatted with tabs and not two spaces.

    In file included from ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/../../../../../../bsps/powerpc/mpc55xxevb/dev/dspi.c:32:0:
    ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/../../../../../../bsps/powerpc/mpc55xxevb/dev/dspi.c: In function 'mpc55xx_dspi_edma_done':
    /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/include/rtems/status-checks.h:88:23: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t {aka long unsigned int}' [-Wformat=]

    RTEMS_SYSLOG_PRINT( "%s: " fmt, func, ##VA_ARGS)

    /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/include/rtems/status-checks.h:76:15: note: in definition of macro 'RTEMS_SYSLOG_PRINT'

    printk( fmt, ##VA_ARGS)

    /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/include/rtems/status-checks.h:109:3: note: in expansion of macro 'RTEMS_SYSLOG'

    RTEMS_SYSLOG( "Error: " fmt, ##VA_ARGS) ~

    ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/../../../../../../bsps/powerpc/mpc55xxevb/dev/dspi.c:122:3: note: in expansion of macro 'RTEMS_SYSLOG_ERROR'

    RTEMS_SYSLOG_ERROR( "eDMA error: 0x%08x\n", error_status); ~

    ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/../../../../../../bsps/powerpc/mpc55xxevb/dev/dspi.c:122:41: note: format string is defined here

    RTEMS_SYSLOG_ERROR( "eDMA error: 0x%08x\n", error_status);

    ~ %08lx

    Comment 1
    1. Joel Sherrill, Wed, 22 Aug 2018 17:02:09 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 06 Sep 2018 05:05:21 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 9a21fc7/rtems:

    bsp/mpc55xxevb: Fix format warning Close #3504.

    3505 - powerpc/virtex redefined warning

    Link https://devel.rtems.org/ticket/3505
    Id 3505
    Reporter Joel Sherrill
    Created 22 August 2018 17:39:21
    Modified 15 October 2018 05:14:44
    Owner Sebastian Huber
    Type defect
    Component arch/powerpc
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by 3549

    Description

    This looks like ppc403 and ppc405 are both defined but I am not seeing source of the ppc405 definition. The warning is in this section of code:

    #if defined (ppc403)
    #define exisr 0x040 /* DCR: external interrupt status register */
    #define exier 0x042 /* DCR: external interrupt enable register */
    #endif /* ppc403 */
    #if defined(ppc405)
    #define exisr 0x0C0 /* DCR: external interrupt status register */
    #define exier 0x0C2 /* DCR: external interrupt enable register */
    #endif /* ppc405 */

    In file included from /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/include/rtems/score/percpu.h:25:0,

    from ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/virtex/../../../../../../bsps/powerpc/shared/exceptions/ppc_exc_async_normal.S:16:

    /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/score/cpu/powerpc/include/rtems/asm.h:228:0: warning: "exisr" redefined

    #define exisr 0x0C0 /* DCR: external interrupt status register */

    /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/score/cpu/powerpc/include/rtems/asm.h:224:0: note: this is the location of the previous definition

    #define exisr 0x040 /* DCR: external interrupt status register */

    /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/score/cpu/powerpc/include/rtems/asm.h:229:0: warning: "exier" redefined

    #define exier 0x0C2 /* DCR: external interrupt enable register */

    /home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/score/cpu/powerpc/include/rtems/asm.h:225:0: note: this is the location of the previous definition

    #define exier 0x042 /* DCR: external interrupt enable register */

    Comment 1
    1. Joel Sherrill, Wed, 22 Aug 2018 17:39:34 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Wed, 05 Sep 2018 05:41:38 GMT

    Some ppc* defines are RTEMS-specific GCC built-in defines.

    Comment 3
    1. Joel Sherrill, Sun, 14 Oct 2018 00:52:17 GMT

    We discussed removing this BSP on the mailing list. Is the resolution of this ticket to refer to a ticket to remove this BSP before 5.1 and close this as won't fix?

    Comment 4
    1. Sebastian Huber, Mon, 15 Oct 2018 05:14:44 GMT
    2. status: changed from assigned to closed
    3. resolution: set to wontfix
    4. blockedby: set to 3549

    3506 - waf for building RTEMS applications needs updating

    Link https://devel.rtems.org/ticket/3506
    Id 3506
    Reporter Joel Sherrill
    Created 23 August 2018 16:18:59
    Modified 19 October 2018 00:28:55
    Owner Chris Johns
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Because there are no native tools in the RTEMS tree anymore, the RTEMS install point will not have a bin/ directory. If the --rtems-tools and --rtems directories are different, the sanity check by __waf configure__ for ${rtems}/bin fails. See examples-v2.

    + ./waf configure -v --rtems=/home/joel/rtems-work/bsp-install --rtems-tools=/home/joel/rtems-work/tools/5 --rtems-bsps=powerpc/qemuppc
    Setting top to : /home/joel/rtems-work/examples-v2
    Setting out to : /home/joel/rtems-work/examples-v2/build
    RTEMS path is not valid. No bin directory found.
    (complete log in /home/joel/rtems-work/examples-v2/build/config.log)
    Comment 1
    1. Joel Sherrill, Thu, 23 Aug 2018 16:19:22 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Chris Johns, Fri, 19 Oct 2018 00:28:55 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    The rtems_waf git module has been fixed ..

    ​https://git.rtems.org/rtems_waf/commit/?id=c0d52d5fcd9cad9b63479b92a0abf4fa5f5c99f3


    3507 - Add flexible per-CPU data

    Link https://devel.rtems.org/ticket/3507
    Id 3507
    Reporter Sebastian Huber
    Created 28 August 2018 06:06:30
    Modified 19 February 2019 08:18:30
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3472
    Blocked by  

    Description

    Add means to declare, define and get custom per-CPU data. The API should cover the APIs defined by the Linux and FreeBSD header files.

    Comment 1
    1. Sebastian Huber, Mon, 10 Sep 2018 09:37:07 GMT

    In cfc4231d/rtems:

    score: Add flexible per-CPU data Update #3507.
    Comment 2
    1. Sebastian Huber, Mon, 10 Sep 2018 09:38:06 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d90c813/rtems-docs:

    c-user: Mention per-processor data Close #3507.
    Comment 3
    1. Sebastian Huber, Mon, 10 Sep 2018 10:03:36 GMT

    In 1fe1b820/rtems:

    score: Fix PER_CPU_DATA_GET_BY_OFFSET() Add uniprocessor version for PER_CPU_DATA_GET_BY_OFFSET(). Fix warnings in uniprocessor configurations. Update #3507.
    Comment 4
    1. Sebastian Huber, Mon, 17 Sep 2018 06:58:44 GMT

    In aaa6653/rtems:

    score: Fix PER_CPU_DATA_ITEM_DECLARE() Fix PER_CPU_DATA_ITEM_DECLARE() for targets with a small-data area. Update #3507.
    Comment 5
    1. Sebastian Huber, Wed, 19 Sep 2018 09:58:17 GMT

    In 776464a/rtems:

    score: Allocate per-CPU data only if necessary The _Workspace_Allocate_aligned() would returns a non-NULL pointer for a zero size allocation request if there is enough memory available. This conflicts with the size estimate of zero in _Workspace_Space_for_per_CPU_data() if the per-CPU data set is empty. Update #3507.
    Comment 6
    1. Sebastian Huber, Wed, 19 Dec 2018 08:50:59 GMT

    In 7c19e50/rtems:

    score: Fix per-CPU data allocation Allocate the per-CPU data for secondary processors directly from the heap areas before heap initialization and not via _Workspace_Allocate_aligned(). This avoids dependency on the workspace allocator. It fixes also a problem on some platforms (e.g. QorIQ) where at this early point in the system initialization the top of the RAM is used by low-level startup code on secondary processors (boot pages). Update #3507.
    Comment 7
    1. Sebastian Huber, Tue, 19 Feb 2019 08:18:30 GMT

    In 789b0ca/rtems-docs:

    c-user: INTERNAL_ERROR_NO_MEMORY_FOR_PER_CPU_DATA Update #3507.

    3508 - Add support for thread to processor pinning

    Link https://devel.rtems.org/ticket/3508
    Id 3508
    Reporter Sebastian Huber
    Created 29 August 2018 12:24:14
    Modified 10 September 2018 09:38:15
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3472
    Blocked by  

    Description

    FreeBSD started to use lock-free data structures (Concurrency Kit) with epoch based reclamation (EBR) in May 2018. The goal of this synchronization approach is to avoid atomic read-modify-write operations in the fast path. The algorithms need highly efficient access to per-processor data. This gives raise to add a new feature to RTEMS: thread to processor pinning. Thread pinning is orthogonal to thread processor affinity and overrules the processor affinity settings of a thread. It is intended for temporary use in short critical sections which allow preemption.

    Comment 1
    1. Sebastian Huber, Mon, 10 Sep 2018 09:37:18 GMT

    In d8bc0730/rtems:

    score: Modify _Scheduler_Unblock() In SMP configurations, obtain the scheduler node for the block and unblock operations through the same way via Thread_Control::Scheduler::Scheduler_node. This symmetry is important in a follow up patch which introduces thread pinning. Update #3508.
    Comment 2
    1. Sebastian Huber, Mon, 10 Sep 2018 09:37:29 GMT

    In 7097962/rtems:

    score: Add thread pin/unpin support Add support to temporarily pin a thread to its current processor. This may be used to access per-processor data structures in critical sections with enabled thread dispatching, e.g. a pinned thread is allowed to block. Update #3508.
    Comment 3
    1. Sebastian Huber, Mon, 10 Sep 2018 09:38:15 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 7c58036/rtems-docs:

    c-user: Mention thread pinning Close #3508.

    3510 - ATA driver uses deprecated rtems_blkdev services

    Link https://devel.rtems.org/ticket/3510
    Id 3510
    Reporter Joel Sherrill
    Created 31 August 2018 13:43:17
    Modified 6 September 2018 05:05:10
    Owner Sebastian Huber
    Type defect
    Component lib/block
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This shows up building fileio on the following BSPs.

    i386/pc386
    i386/pc486
    i386/pc586
    i386/pc586-sse
    i386/pc686
    i386/pcp4
    powerpc/brs5l
    powerpc/brs6l
    powerpc/dp2
    powerpc/icecube
    powerpc/pm520_cr825
    powerpc/pm520_ze30

    Comment 1
    1. Joel Sherrill, Fri, 31 Aug 2018 13:43:43 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Thu, 06 Sep 2018 05:05:10 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In ccdce9d8/rtems:

    libchip/ata: Fix ATA_DRIVER_TABLE_ENTRY Drop unused and deprecated functions from the ATA_DRIVER_TABLE_ENTRY. Update #3358. Close #3510.

    3511 - int/pointer size warnings in powerpc-qoriq_e6500_64

    Link https://devel.rtems.org/ticket/3511
    Id 3511
    Reporter Joel Sherrill
    Created 4 September 2018 22:57:18
    Modified 5 September 2018 04:56:38
    Owner Sebastian Huber
    Type defect
    Component arch/powerpc
    Status closed
    Resolution duplicate
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    These all look suspiciously like real issues:

    $ grep warning log/powerpc-qoriq_e6500_64.log
    ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/qoriq/../../../../../../bsps/powerpc/qoriq/start/bspstart.c:173:5: warning: passing argument 1 of 'qoriq_initialize_exceptions' makes pointer from integer without a cast [-Wint-conversion]
    ../../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:57:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
    ../../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:64:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
    ../../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:488:11: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'long int' [-Wformat=]
    ../../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt-shell.c:536:13: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'long int' [-Wformat=]
    ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/qoriq/../../../../../../bsps/powerpc/shared/exceptions/ppc_exc_alignment.c:28:25: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
    ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/qoriq/../../../../../../bsps/powerpc/shared/exceptions/ppc_exc_initialize.c:38:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]

    Comment 1
    1. Joel Sherrill, Tue, 04 Sep 2018 22:57:32 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Wed, 05 Sep 2018 04:56:38 GMT
    2. status: changed from assigned to closed
    3. resolution: set to duplicate

    Duplicate of #3156.


    3512 - sb-check:No python command with Python 2 and Python 3 installed

    Link https://devel.rtems.org/ticket/3512
    Id 3512
    Reporter Justin
    Created 6 September 2018 01:40:46
    Modified 14 October 2018 01:02:51
    Owner  
    Type defect
    Component tool/rsb
    Status closed
    Resolution duplicate
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    On Ubuntu 18.04.1 LTS there is no command named Python. I have the following Python commands:

    python2.7    python3.6    python3.6m-config
    python3m-config python 2.7-config python3.6-config python3-config python3
    python3.6m python3m

    I am going to symlink python2.7 to python to make it work, but there should be a better solution.

    Comment 1
    1. Chris Johns, Sun, 14 Oct 2018 01:02:51 GMT
    2. status: changed from new to closed
    3. resolution: set to duplicate

    See #3537


    3513 - Convert tqm8xx console driver to new Termios API

    Link https://devel.rtems.org/ticket/3513
    Id 3513
    Reporter Sebastian Huber
    Created 12 September 2018 09:47:05
    Modified 17 September 2018 07:00:16
    Owner Sebastian Huber
    Type task
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3034
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Mon, 17 Sep 2018 06:59:25 GMT

    In 7b93d857/rtems:

    bsp/tqm8xx: Use IRQ extensions API Update #3513.
    Comment 2
    1. Sebastian Huber, Mon, 17 Sep 2018 06:59:35 GMT

    In 53fb03fe/rtems:

    bsp/tqm8xx: Move rxBuf to channel descriptor Update #3513.
    Comment 3
    1. Sebastian Huber, Mon, 17 Sep 2018 06:59:45 GMT

    In 68920e7f/rtems:

    bsp/tqm8xx: Move DMA support to channel descriptor Update #3513.
    Comment 4
    1. Sebastian Huber, Mon, 17 Sep 2018 06:59:56 GMT

    In d22147e/rtems:

    bsp/tqm8xx: Convert console to new Termios API Update #3513.
    Comment 5
    1. Sebastian Huber, Mon, 17 Sep 2018 07:00:06 GMT

    In 688e101a/rtems:

    bsp/tqm8xx: Fix polled vs. interrupt output Update #3513.
    Comment 6
    1. Sebastian Huber, Mon, 17 Sep 2018 07:00:16 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 62cb39d7/rtems:

    bsp/tqm8xx: Remove unused files Close #3513.

    3516 - sb-set-builder should report disk usage of build

    Link https://devel.rtems.org/ticket/3516
    Id 3516
    Reporter Joel Sherrill
    Created 13 September 2018 17:09:34
    Modified 27 September 2018 22:18:50
    Owner Chris Johns
    Type enhancement
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Helping others work through the hello world, it is common for their VM images to not have enough disk space for the build to complete. It would be useful if the set-builder could report disk usage of the build/ directory. This information could be fed into the Users Guide.

    It is frustrating and a bad experience to watch the build fail 90% of the way through.

    Comment 1
    1. Joel Sherrill, Thu, 13 Sep 2018 17:09:54 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Thu, 13 Sep 2018 18:28:23 GMT

    I did a sparc tools build and it used 7.9 GB in build/. That probably means you need 12-15GB to have all the sources, rtems, and build RTEMS. Needs to be verified by others and to other architectures.

    Comment 3
    1. Chris Johns, Thu, 13 Sep 2018 23:38:24 GMT
    2. type: changed from defect to enhancement
    Comment 4
    1. Chris Johns, Sat, 15 Sep 2018 23:38:54 GMT

    What do you define as space that needs to be accounted for?

    The build tree after each package in a build set has been built? Installed files? Source and patches?
    Comment 5
    1. Joel Sherrill, Sun, 16 Sep 2018 00:00:08 GMT

    Replying to Chris Johns:

    What do you define as space that needs to be accounted for?

    The build tree after each package in a build set has been built? Installed files? Source and patches?

    Good questions. The ultimate answer is all of that. :)

    The build tree peak is a critical piece of information. I saw people run out of disk space during the gcc/newlib phase. If we knew that, our instructions could give guidance. I did a no clean and was left with 8GB in build for SPARC. That's probably harsh if normally each package's build is cleaned. But SPARC now has more multilibs than I expected but arm and powerpc both have a lot also.

    The question is "how much do I need to build the tools for architecture X?" That includes source tarballs, git, patches, peak space for untar'ed, and peak build usage. And ideally we want to give advice that leaves people enough room to clone RTEMS and build it.

    How can we get the input to give good advice that avoids folks running out of build space during the "getting started"?

    Comment 6
    1. Chris Johns, Sun, 16 Sep 2018 03:35:55 GMT

    I have taken a look at implementing this and it is not easy and complex to do so I do not think I will adding this feature.

    The prep, build and clean are all part of a shell script that is generated and run and while I could add some du commands to the script to dump the sizes there is no way to capture the output in a way that can be reported.

    I feel it is simpler to create a script to wrap the sb-set-builder command with the --no-clean option and then dump the sizes once built. If this is run on a machine with plenty of storage you should be able to get the results to update the user manual.

    Comment 7
    1. Chris Johns, Mon, 17 Sep 2018 04:06:24 GMT

    Replying to Chris Johns:

    I have taken a look at implementing this and it is not easy and complex to do so I do not think I will adding this feature.

    The prep, build and clean are all part of a shell script that is generated and run and while I could add some du commands to the script to dump the sizes there is no way to capture the output in a way that can be reported.

    I have taken a further look and it looks like the clean phase of the script is not being used and the RSB is cleaning a build in Python. This makes implementing something possible. I still need to check all the .cfg files to see if this is true.

    The issue is any shell variables defined in one phase could be used in another phase and splitting the scripts means the variables or settings will not seen in subsequent phases.

    Comment 8
    1. Chris Johns, Thu, 20 Sep 2018 03:20:07 GMT

    I am concerned there is another issue which cause the overflow of a VM disk. What is in the 7.9G build directory?

    I have a patch I am testing which gives the following output for a rtems-sparc build:

    Build Sizes: usage: 3.661GB total: 2.412GB (sources: 1.472GB, patches: 6.630MB, installed 955.801MB) 

    The full output is:

    $ ../source-builder/sb-set-builder --prefix=/opt/work/rtems/5 --log=5-sparc.txt 5/rtems-sparc
    RTEMS Source Builder - Set Builder, 5 (a16bfe19effa modified)
    Build Set: 5/rtems-sparc
    Build Set: 5/rtems-autotools.bset
    Build Set: 5/rtems-autotools-internal.bset
    config: tools/rtems-autoconf-2.69-1.cfg
    package: autoconf-2.69-x86_64-freebsd11.1-1
    building: autoconf-2.69-x86_64-freebsd11.1-1
    sizes: autoconf-2.69-x86_64-freebsd11.1-1: 7.506MB (installed: 0.000B)
    cleaning: autoconf-2.69-x86_64-freebsd11.1-1
    config: tools/rtems-automake-1.12.6-1.cfg
    package: automake-1.12.6-x86_64-freebsd11.1-1
    building: automake-1.12.6-x86_64-freebsd11.1-1
    sizes: automake-1.12.6-x86_64-freebsd11.1-1: 8.326MB (installed: 0.000B)
    cleaning: automake-1.12.6-x86_64-freebsd11.1-1
    cleaning: autoconf-2.69-x86_64-freebsd11.1-1
    cleaning: automake-1.12.6-x86_64-freebsd11.1-1
    Build Sizes: usage: 8.326MB total: 1.479GB (sources: 1.472GB, patches: 6.630MB, installed 0.000B)
    Build Set: Time 0:00:05.622352
    Build Set: 5/rtems-autotools-base.bset
    config: tools/rtems-autoconf-2.69-1.cfg
    package: autoconf-2.69-x86_64-freebsd11.1-1
    building: autoconf-2.69-x86_64-freebsd11.1-1
    sizes: autoconf-2.69-x86_64-freebsd11.1-1: 7.503MB (installed: 3.033MB)
    cleaning: autoconf-2.69-x86_64-freebsd11.1-1
    reporting: tools/rtems-autoconf-2.69-1.cfg -> autoconf-2.69-x86_64-freebsd11.1-1.txt
    reporting: tools/rtems-autoconf-2.69-1.cfg -> autoconf-2.69-x86_64-freebsd11.1-1.xml
    config: tools/rtems-automake-1.12.6-1.cfg
    package: automake-1.12.6-x86_64-freebsd11.1-1
    building: automake-1.12.6-x86_64-freebsd11.1-1
    sizes: automake-1.12.6-x86_64-freebsd11.1-1: 8.325MB (installed: 2.264MB)
    cleaning: automake-1.12.6-x86_64-freebsd11.1-1
    reporting: tools/rtems-automake-1.12.6-1.cfg -> automake-1.12.6-x86_64-freebsd11.1-1.txt
    reporting: tools/rtems-automake-1.12.6-1.cfg -> automake-1.12.6-x86_64-freebsd11.1-1.xml
    installing: autoconf-2.69-x86_64-freebsd11.1-1 -> /opt/work/rtems/5
    installing: automake-1.12.6-x86_64-freebsd11.1-1 -> /opt/work/rtems/5
    cleaning: autoconf-2.69-x86_64-freebsd11.1-1
    cleaning: automake-1.12.6-x86_64-freebsd11.1-1
    Build Sizes: usage: 8.325MB total: 1.484GB (sources: 1.472GB, patches: 6.630MB, installed 5.298MB)
    Build Set: Time 0:00:07.382470
    Build Set: Time 0:00:13.008615
    config: devel/expat-2.1.0-1.cfg
    package: expat-2.1.0-x86_64-freebsd11.1-1
    building: expat-2.1.0-x86_64-freebsd11.1-1
    sizes: expat-2.1.0-x86_64-freebsd11.1-1: 4.171MB (installed: 623.483KB)
    cleaning: expat-2.1.0-x86_64-freebsd11.1-1
    reporting: devel/expat-2.1.0-1.cfg -> expat-2.1.0-x86_64-freebsd11.1-1.txt
    reporting: devel/expat-2.1.0-1.cfg -> expat-2.1.0-x86_64-freebsd11.1-1.xml
    config: tools/rtems-binutils-2.31.1.cfg
    package: sparc-rtems5-binutils-2.31.1-x86_64-freebsd11.1-1
    building: sparc-rtems5-binutils-2.31.1-x86_64-freebsd11.1-1
    sizes: sparc-rtems5-binutils-2.31.1-x86_64-freebsd11.1-1: 250.532MB (installed: 29.078MB)
    cleaning: sparc-rtems5-binutils-2.31.1-x86_64-freebsd11.1-1
    reporting: tools/rtems-binutils-2.31.1.cfg -> sparc-rtems5-binutils-2.31.1-x86_64-freebsd11.1-1.txt
    reporting: tools/rtems-binutils-2.31.1.cfg -> sparc-rtems5-binutils-2.31.1-x86_64-freebsd11.1-1.xml
    config: tools/rtems-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9.cfg
    package: sparc-rtems5-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9-x86_64-freebsd11.1-1
    building: sparc-rtems5-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9-x86_64-freebsd11.1-1
    sizes: sparc-rtems5-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9-x86_64-freebsd11.1-1: 3.661GB (installed: 846.775MB)
    cleaning: sparc-rtems5-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9-x86_64-freebsd11.1-1
    reporting: tools/rtems-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9.cfg -> sparc-rtems5-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9-x86_64-freebsd11.1-1.txt
    reporting: tools/rtems-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9.cfg -> sparc-rtems5-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9-x86_64-freebsd11.1-1.xml
    config: tools/rtems-gdb-8.0.1-1.cfg
    package: sparc-rtems5-gdb-8.0.1-x86_64-freebsd11.1-1
    building: sparc-rtems5-gdb-8.0.1-x86_64-freebsd11.1-1
    sizes: sparc-rtems5-gdb-8.0.1-x86_64-freebsd11.1-1: 223.999MB (installed: 12.948MB)
    cleaning: sparc-rtems5-gdb-8.0.1-x86_64-freebsd11.1-1
    reporting: tools/rtems-gdb-8.0.1-1.cfg -> sparc-rtems5-gdb-8.0.1-x86_64-freebsd11.1-1.txt
    reporting: tools/rtems-gdb-8.0.1-1.cfg -> sparc-rtems5-gdb-8.0.1-x86_64-freebsd11.1-1.xml
    config: tools/rtems-tools-5-1.cfg
    package: rtems-tools-d343f830f4dae8e84b4b44902347c60cf18b2ffd-1
    building: rtems-tools-d343f830f4dae8e84b4b44902347c60cf18b2ffd-1
    sizes: rtems-tools-d343f830f4dae8e84b4b44902347c60cf18b2ffd-1: 189.996MB (installed: 66.392MB)
    cleaning: rtems-tools-d343f830f4dae8e84b4b44902347c60cf18b2ffd-1
    reporting: tools/rtems-tools-5-1.cfg -> rtems-tools-d343f830f4dae8e84b4b44902347c60cf18b2ffd-1.txt
    reporting: tools/rtems-tools-5-1.cfg -> rtems-tools-d343f830f4dae8e84b4b44902347c60cf18b2ffd-1.xml
    config: tools/rtems-kernel-5.cfg
    package: sparc-rtems5-kernel-5-1
    building: sparc-rtems5-kernel-5-1
    sizes: sparc-rtems5-kernel-5-1: 8.308KB (installed: 0.000B)
    cleaning: sparc-rtems5-kernel-5-1
    reporting: tools/rtems-kernel-5.cfg -> sparc-rtems5-kernel-5-1.txt
    reporting: tools/rtems-kernel-5.cfg -> sparc-rtems5-kernel-5-1.xml
    installing: expat-2.1.0-x86_64-freebsd11.1-1 -> /opt/work/rtems/5
    installing: sparc-rtems5-binutils-2.31.1-x86_64-freebsd11.1-1 -> /opt/work/rtems/5
    installing: sparc-rtems5-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9-x86_64-freebsd11.1-1 -> /opt/work/rtems/5
    installing: sparc-rtems5-gdb-8.0.1-x86_64-freebsd11.1-1 -> /opt/work/rtems/5
    installing: rtems-tools-d343f830f4dae8e84b4b44902347c60cf18b2ffd-1 -> /opt/work/rtems/5
    installing: sparc-rtems5-kernel-5-1 -> /opt/work/rtems/5
    cleaning: expat-2.1.0-x86_64-freebsd11.1-1
    cleaning: sparc-rtems5-binutils-2.31.1-x86_64-freebsd11.1-1
    cleaning: sparc-rtems5-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9-x86_64-freebsd11.1-1
    cleaning: sparc-rtems5-gdb-8.0.1-x86_64-freebsd11.1-1
    cleaning: rtems-tools-d343f830f4dae8e84b4b44902347c60cf18b2ffd-1
    cleaning: sparc-rtems5-kernel-5-1
    Build Sizes: usage: 3.661GB total: 2.412GB (sources: 1.472GB, patches: 6.630MB, installed 955.801MB)
    Build Set: Time 0:20:56.188572 
    Comment 9
    1. Chris Johns, Thu, 27 Sep 2018 21:37:41 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 38fd56c/rtems-source-builder:

    sb: Monitor the build disk usage. Report the usage, total and various sizes Track the size of a build of a package in a build set to determine the maximum amout of disk space used. This can be used as a guide to documenting how much space a user needs to set aside to build a specific set of tools. The %clean stage of a build is now split into a separate script. I do not think this is an issue because I could not find any %clean sections in any build configs we have. In time support for the %clean section will be removed, the package builder cleans up. Closes #3516
    Comment 10
    1. Chris Johns, Thu, 27 Sep 2018 22:18:50 GMT

    In 079f95a/rtems-source-builder:

    sb: Add build sizes to the email report. Include build sizes in the email report. Updates #3516

    3517 - RSB Ubuntu Host Requirements Missing Some

    Link https://devel.rtems.org/ticket/3517
    Id 3517
    Reporter Joel Sherrill
    Created 13 September 2018 18:27:17
    Modified 25 September 2018 19:23:16
    Owner Joel Sherrill <joel@…>
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add libncurses5-dev and zlib1g-dev to Ubuntu apt-get instructions

    Also bison and flex seemed to be missing per one of the persons trying it.

    Comment 1
    1. Joel Sherrill, Thu, 13 Sep 2018 18:38:10 GMT
    2. description: modified (diff)
    Comment 2
    1. Joel Sherrill, Tue, 25 Sep 2018 19:23:16 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 86baa5d/rtems-docs:

    rsb/hosts.rst: Add more packages needed on Ubuntu Closes #3517.

    3518 - RSB MacOS Nits

    Link https://devel.rtems.org/ticket/3518
    Id 3518
    Reporter Joel Sherrill
    Created 13 September 2018 18:37:28
    Modified 25 September 2018 18:45:01
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The MacOS section of the RSB manual has some minor things that need to be fixed:

    • says Serria when it should be Sierra (I think).
    • has +sb-check+ which indicates a formatting error

    Please review as a Mac user and make sure that's it. :)

    Comment 1
    1. Joel Sherrill, Tue, 25 Sep 2018 18:45:01 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 11b5e9b/rtems-docs:

    RSB: Fix MacOS typos Close #3518.

    3519 - RSB does not strictly check args

    Link https://devel.rtems.org/ticket/3519
    Id 3519
    Reporter Chris Johns
    Created 15 September 2018 07:25:12
    Modified 15 September 2018 07:44:05
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The RSB loose argument parsing in the RSB needs to change. The RSB needs to strictly check arguments to avoid simple user errors.

    Comment 1
    1. Chris Johns, Sat, 15 Sep 2018 07:44:05 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a16bfe1/rtems-source-builder:

    sb: Raise an error if an option is not registered and unknown. Close #3519.

    3520 - Remove CONFIGURE_HAS_OWN_FILESYSTEM_TABLE

    Link https://devel.rtems.org/ticket/3520
    Id 3520
    Reporter Sebastian Huber
    Created 17 September 2018 08:25:55
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    This configuration is untested and undocumented. Remove it to avoid a potential exposure of internal data structures to the application domain.

    Comment 1
    1. Sebastian Huber, Wed, 19 Sep 2018 08:52:21 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In bd5cec41/rtems:

    config: Remove CONFIGURE_HAS_OWN_FILESYSTEM_TABLE This configuration was untested and undocumented. Remove it to avoid a potential exposure of internal data structures to the application domain. Close #3520.
    Comment 2
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3522 - Update mDNSResponder to Apple version v878.30.4

    Link https://devel.rtems.org/ticket/3522
    Id 3522
    Reporter Sebastian Huber
    Created 19 September 2018 12:35:55
    Modified 20 September 2018 09:29:08
    Owner Sebastian Huber
    Type task
    Component network/libbsd
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Download

    mDNSResponder-561.1.1.tar.gz
    mDNSResponder-567.tar.gz
    mDNSResponder-576.30.4.tar.gz
    mDNSResponder-625.41.2.tar.gz
    mDNSResponder-765.1.2.tar.gz
    mDNSResponder-765.20.4.tar.gz
    mDNSResponder-765.30.11.tar.gz
    mDNSResponder-765.50.9.tar.gz
    mDNSResponder-878.1.1.tar.gz
    mDNSResponder-878.20.3.tar.gz
    mDNSResponder-878.30.4.tar.gz

    from

    ​https://opensource.apple.com/tarballs/mDNSResponder/

    Merge each update into libbsd/mDNSResponder.

    Comment 1
    1. Sebastian Huber, Thu, 20 Sep 2018 09:27:30 GMT

    In 152d81f/rtems-libbsd:

    mDNSResponder: Increase stack size The current stack size was insuffient on a test run of the foobarclient test program. Update #3522.
    Comment 2
    1. Sebastian Huber, Thu, 20 Sep 2018 09:27:38 GMT

    In 111789e/rtems-libbsd:

    mDNSResponder: Update to v561.1.1 The sources can be obtained via: ​https://opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-561.1.1.tar.gz Update #3522.
    Comment 3
    1. Sebastian Huber, Thu, 20 Sep 2018 09:27:46 GMT

    In e36ca10/rtems-libbsd:

    mDNSResponder: Update to v567 The sources can be obtained via: ​https://opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-567.tar.gz Update #3522.
    Comment 4
    1. Sebastian Huber, Thu, 20 Sep 2018 09:27:54 GMT

    In 49ebc73/rtems-libbsd:

    mDNSResponder: Update to v576.30.4 The sources can be obtained via: ​https://opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-576.30.4.tar.gz Update #3522.
    Comment 5
    1. Sebastian Huber, Thu, 20 Sep 2018 09:28:03 GMT

    In f761b29/rtems-libbsd:

    mDNSResponder: Update to v625.41.2 The sources can be obtained via: ​https://opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-625.41.2.tar.gz Update #3522.
    Comment 6
    1. Sebastian Huber, Thu, 20 Sep 2018 09:28:16 GMT

    In f01edf1/rtems-libbsd:

    mDNSResponder: Update to v765.1.2 The sources can be obtained via: ​https://opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-765.1.2.tar.gz Move mDNS_StartResolveService() and mDNS_StopResolveService() to an RTEMS-specific file (rtemsbsd/mdns/mDNSResolveService.c) using the v576.30.4 implementation. Apple removed these functions without explanation. Update #3522.
    Comment 7
    1. Sebastian Huber, Thu, 20 Sep 2018 09:28:23 GMT

    In fc605b3/rtems-libbsd:

    mDNSResponder: Update to v765.20.4 The sources can be obtained via: ​https://opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-765.20.4.tar.gz Update #3522.
    Comment 8
    1. Sebastian Huber, Thu, 20 Sep 2018 09:28:31 GMT

    In 7d33d36/rtems-libbsd:

    mDNSResponder: Update to v765.30.11 The sources can be obtained via: ​https://opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-765.30.11.tar.gz Update #3522.
    Comment 9
    1. Sebastian Huber, Thu, 20 Sep 2018 09:28:40 GMT

    In a814950/rtems-libbsd:

    mDNSResponder: Update to v765.50.9 The sources can be obtained via: ​https://opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-765.50.9.tar.gz Update #3522.
    Comment 10
    1. Sebastian Huber, Thu, 20 Sep 2018 09:28:52 GMT

    In 4c086a2/rtems-libbsd:

    mDNSResponder: Update to v878.1.1 The sources can be obtained via: ​https://opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-878.1.1.tar.gz Update #3522.
    Comment 11
    1. Sebastian Huber, Thu, 20 Sep 2018 09:29:00 GMT

    In 1e55d820/rtems-libbsd:

    mDNSResponder: Update to v878.20.3 The sources can be obtained via: ​https://opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-878.20.3.tar.gz Update #3522.
    Comment 12
    1. Sebastian Huber, Thu, 20 Sep 2018 09:29:08 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 2723609/rtems-libbsd:

    mDNSResponder: Update to v878.30.4 The sources can be obtained via: ​https://opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-878.30.4.tar.gz Close #3522.

    3523 - Add FEC network interface driver for TQM8XX

    Link https://devel.rtems.org/ticket/3523
    Id 3523
    Reporter Sebastian Huber
    Created 20 September 2018 12:09:59
    Modified 21 September 2018 08:39:45
    Owner Sebastian Huber
    Type task
    Component network/libbsd
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Import legacy network driver and port it to libbsd.

    Comment 1
    1. Sebastian Huber, Fri, 21 Sep 2018 08:39:14 GMT

    In 860d833/rtems-libbsd:

    if_ffec_mpc8xx: Import legacy driver from RTEMS Imported from RTEMS commit 1fe1b820de02c274c2b2b3431340152734ee9fb6 (2018-09-12). Update #3523.
    Comment 2
    1. Sebastian Huber, Fri, 21 Sep 2018 08:39:21 GMT

    In 457b4fc/rtems-libbsd:

    if_ffec_mpc8xx: Port driver to libbsd Update #3523.
    Comment 3
    1. Sebastian Huber, Fri, 21 Sep 2018 08:39:29 GMT

    In d101ed8/rtems-libbsd:

    if_ffec_mpc8xx: New MDIO driver support Update #3523.
    Comment 4
    1. Sebastian Huber, Fri, 21 Sep 2018 08:39:37 GMT

    In 1b70957/rtems-libbsd:

    if_ffec_mpc8xx: Use M_NOWAIT for incoming frames Update #3523.
    Comment 5
    1. Sebastian Huber, Fri, 21 Sep 2018 08:39:45 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 6103496/rtems-libbsd:

    if_ffec_mpc8xx: Fix incoming data invalidation With a write-back cache dirty cache lines may be evicted which could overwrite new data. Close #3523.

    3525 - Add MMC/SDCard support for i.MX 7Dual BSP

    Link https://devel.rtems.org/ticket/3525
    Id 3525
    Reporter Sebastian Huber
    Created 25 September 2018 07:39:45
    Modified 28 September 2018 16:08:38
    Owner Sebastian Huber
    Type enhancement
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Port device drivers from FreeBSD for i.MX 7Dual uSDHC module.

    Comment 1
    1. Sebastian Huber, Tue, 25 Sep 2018 08:02:26 GMT

    In b42dea9/rtems-libbsd:

    CONFIG_INTRHOOK(9): Port to RTEMS Some device drivers (e.g. MMC) need a complex intialization with working callouts. Remove the dummy CONFIG_INTRHOOK() implementation and replace it with the real one from FreeBSD. Make sure TIMEOUT(9) services work at this point. Update #3525.
    Comment 2
    1. Sebastian Huber, Tue, 25 Sep 2018 08:02:34 GMT

    In 13840c1/rtems-libbsd:

    Update gpio interface Update #3525.
    Comment 3
    1. Sebastian Huber, Tue, 25 Sep 2018 08:02:42 GMT

    In 7e8e177/rtems-libbsd:

    imx/imx_gpio.c: Import from FreeBSD Update #3525.
    Comment 4
    1. Sebastian Huber, Tue, 25 Sep 2018 08:02:50 GMT

    In 06dd40e/rtems-libbsd:

    imx/imx_gpio.c: Port to RTEMS Update #3525.
    Comment 5
    1. Sebastian Huber, Tue, 25 Sep 2018 08:02:57 GMT

    In 6721f56/rtems-libbsd:

    fsl_sdhci.c: Import from FreeBSD Update #3525.
    Comment 6
    1. Sebastian Huber, Tue, 25 Sep 2018 08:03:05 GMT

    In b382502/rtems-libbsd:

    fsl_sdhci.c: Port to RTEMS Update #3525.
    Comment 7
    1. Sebastian Huber, Tue, 25 Sep 2018 08:14:09 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In bd25da8/rtems-docs:

    user: Add i.MX 7D MMC/SDCard driver Close #3525.
    Comment 8
    1. Sebastian Huber, Thu, 27 Sep 2018 05:23:40 GMT

    In 69a24c3/rtems:

    bsp/imx: Add imx_ccm_sdhci_hz() Update #3525.
    Comment 9
    1. Sebastian Huber, Thu, 27 Sep 2018 05:28:51 GMT

    In 8645b550/rtems-libbsd:

    fsl_sdhci.c: Fix missing include error Update #3525.
    Comment 10
    1. Sebastian Huber, Fri, 28 Sep 2018 16:08:38 GMT

    In b54bd95/rtems-libbsd:

    fsl_sdhci.c: Fix missing include error Update #3525.

    3526 - Convert PTY driver to new Termios API

    Link https://devel.rtems.org/ticket/3526
    Id 3526
    Reporter Sebastian Huber
    Created 25 September 2018 08:38:57
    Modified 2 October 2018 05:13:16
    Owner Sebastian Huber
    Type task
    Component dev/serial
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3034
    Blocked by 3528

    Description

    Comment 1
    1. Sebastian Huber, Wed, 26 Sep 2018 05:53:03 GMT
    2. blockedby: set to 3528
    Comment 2
    1. Sebastian Huber, Mon, 01 Oct 2018 10:34:12 GMT

    In ac9f808/rtems:

    pppd: Remove unused get_pty() function Update #3526.
    Comment 3
    1. Sebastian Huber, Mon, 01 Oct 2018 10:34:24 GMT

    In b980f363/rtems:

    telnetd: Convert pty driver to new Termios API Update #3526.
    Comment 4
    1. Sebastian Huber, Mon, 01 Oct 2018 10:35:16 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a346ebba/rtems:

    telnetd: Remove CONFIGURE_MAXIMUM_PTYS Add a rtems_telnetd_config_table::client_maximum member to the Telnet configuration. Close #3526. Close #3528.
    Comment 5
    1. Sebastian Huber, Tue, 02 Oct 2018 05:13:16 GMT

    In 38c1a41/rtems-libbsd:

    telnetd: Update due to API changes Update #3526.

    3528 - Remove undocumented and untested CONFIGURE_MAXIMUM_PTYS

    Link https://devel.rtems.org/ticket/3528
    Id 3528
    Reporter Sebastian Huber
    Created 26 September 2018 05:53:03
    Modified 1 October 2018 10:35:16
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3526
    Blocked by  

    Description

    Remove the undocumented and untested CONFIGURE_MAXIMUM_PTYS configuration option. Add a rtems_telnetd_config_table::client_maximum member to the Telnet configuration.

    Comment 1
    1. Sebastian Huber, Mon, 01 Oct 2018 10:34:37 GMT

    In 0413b14/rtems:

    telnetd: Remove superfluous global variable Update #3528.
    Comment 2
    1. Sebastian Huber, Mon, 01 Oct 2018 10:35:16 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a346ebba/rtems:

    telnetd: Remove CONFIGURE_MAXIMUM_PTYS Add a rtems_telnetd_config_table::client_maximum member to the Telnet configuration. Close #3526. Close #3528.

    3529 - Fix issues raised by Coverity Scan for Telnet server

    Link https://devel.rtems.org/ticket/3529
    Id 3529
    Reporter Sebastian Huber
    Created 26 September 2018 08:36:27
    Modified 18 October 2018 10:51:42
    Owner Sebastian Huber
    Type task
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by 3533, 3543

    Description

    Comment 1
    1. Sebastian Huber, Fri, 28 Sep 2018 08:04:51 GMT
    2. blockedby: set to 3533
    Comment 2
    1. Sebastian Huber, Tue, 09 Oct 2018 12:56:35 GMT
    2. blockedby: changed from 3533 to 3533, 3543
    Comment 3
    1. Sebastian Huber, Wed, 10 Oct 2018 11:59:23 GMT

    In 2806e10/rtems:

    telnetd: Ignore setsockopt() return status Update #3529.
    Comment 4
    1. Sebastian Huber, Thu, 18 Oct 2018 10:51:32 GMT

    Coverity Scan no longer complains about the Telnet server code since this commit [26b58b7e4af27b632a3765249ba8f8a9b024fa08/rtems].

    Comment 5
    1. Sebastian Huber, Thu, 18 Oct 2018 10:51:42 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3530 - Fix issues raised by Coverity Scan for FTP server

    Link https://devel.rtems.org/ticket/3530
    Id 3530
    Reporter Sebastian Huber
    Created 26 September 2018 08:37:12
    Modified 4 March 2020 07:22:16
    Owner Sebastian Huber
    Type task
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by 3545

    Description

    Comment 1
    1. Sebastian Huber, Thu, 04 Oct 2018 08:50:06 GMT

    In f004b2b8/rtems:

    Use rtems_task_exit() Update #3530. Update #3533.
    Comment 2
    1. Sebastian Huber, Mon, 08 Oct 2018 05:16:22 GMT

    In e761fb4/rtems:

    ftpd: Avoid NULL pointer checks before free() They are superfluous and just bloat the code. Update #3530.
    Comment 3
    1. Sebastian Huber, Mon, 08 Oct 2018 05:16:33 GMT

    In dcf42bb2/rtems:

    ftpd: Remove FTPD_SessionInfo_t::pass member There is no need to keep the password throughout the session. Update #3530.
    Comment 4
    1. Sebastian Huber, Mon, 08 Oct 2018 05:16:43 GMT

    In 51da629/rtems:

    ftpd: Avoid malloc() and sscanf() Move the user name to the session information. Update #3530.
    Comment 5
    1. Sebastian Huber, Mon, 08 Oct 2018 05:16:53 GMT

    In 479a28e0/rtems:

    ftpd: Avoid use of uninitialized memory Update #3530.
    Comment 6
    1. Sebastian Huber, Mon, 08 Oct 2018 05:17:04 GMT

    In df97c4d2/rtems:

    ftpd: Avoid resource leak Update #3530.
    Comment 7
    1. Sebastian Huber, Mon, 08 Oct 2018 05:17:14 GMT

    In be8de0ff/rtems:

    ftpd: Fix insecure chroot() handling Ensure that the rtems_libio_set_private_env() was successful before the chroot(). Update #3530.
    Comment 8
    1. Sebastian Huber, Tue, 09 Oct 2018 05:44:18 GMT

    In 2f784d7/rtems:

    ftpd: Check return status of getsockname() Update #3530.
    Comment 9
    1. Sebastian Huber, Tue, 09 Oct 2018 05:44:32 GMT

    In 5bd75823/rtems:

    ftpd: Remove superfluous temporary buffer Update #3530.
    Comment 10
    1. Sebastian Huber, Wed, 10 Oct 2018 11:59:13 GMT

    In 84a5921d/rtems:

    ftpd: Restructure chroot() handling. Remove superfluous setting of errno = 0. Update #3530.
    Comment 11
    1. Sebastian Huber, Thu, 11 Oct 2018 08:49:05 GMT
    2. blockedby: set to 3545
    Comment 12
    1. Sebastian Huber, Fri, 12 Oct 2018 12:16:56 GMT

    In 35c533f/rtems-source-builder:

    5: Update Newlib Pick up POSIX header file changes and improved opendir() implementation. This addesses time of check and time of use error conditions (TOCTOU). Update #3530. Update #3545. Update #3546. Update #3547.
    Comment 13
    1. Sebastian Huber, Fri, 02 Nov 2018 10:58:42 GMT

    In 706802f8/rtems:

    ftpd: Make send_dirline() more robust Account for large file names. Update #3530.
    Comment 14
    1. Sebastian Huber, Fri, 02 Nov 2018 10:58:50 GMT

    In 8c3cd1e8/rtems:

    ftpd: Deal with too long command lines Update #3530.
    Comment 15
    1. Sebastian Huber, Fri, 02 Nov 2018 10:58:58 GMT

    In fa0adf36/rtems:

    ftpd: Avoid TOCTOU problem Assume that opendir() returns only non-NULL if we actually open a directory. Update #3530.
    Comment 16
    1. Joel Sherrill, Fri, 02 Nov 2018 14:16:10 GMT

    Just an FYI that I have been trying to put the URL for the corresponding RTEMS tickets in the Coverity comment for the CID. Not sure it will ever be useful but best to be thorough in case we need it in the future.

    Comment 17
    1. Sebastian Huber, Thu, 19 Dec 2019 08:20:33 GMT

    An up to date Coverity run would be nice to see if all issues are fixed.

    Comment 18
    1. Joel Sherrill, Thu, 19 Dec 2019 14:49:38 GMT

    I just submitted one. Hopefully it will pop out soon.

    Comment 19
    1. Sebastian Huber, Wed, 04 Mar 2020 07:22:16 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    I reviewed all CIDs with respect to the FTP server. I think further improvements require some modelling in Coverity so remove the taint from data.


    3531 - Add POSIX Attribute Reports for More Than Scheduler (examples-v2)

    Link https://devel.rtems.org/ticket/3531
    Id 3531
    Reporter Joel Sherrill
    Created 26 September 2018 14:43:37
    Modified 8 October 2018 15:56:51
    Owner Joel Sherrill
    Type defect
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords examples
    Cc  
    Blocking  
    Blocked by  

    Description

    Add programs to report default attributes for various POSIX objects including barriers, condition variables, message queues, mutexes, pthreads, and rwlocks. The programs should be able to run on any POSIX host and report what it uses for object attribute defaults.

    Object attribute defaults are unspecified by POSIX. The portable practice is to explicitly set every attribute. These programs allow one to probe and compare various operating system implementations.

    Comment 1
    1. Joel Sherrill, Wed, 26 Sep 2018 14:43:47 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Mon, 08 Oct 2018 15:56:51 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In f4ce641/examples-v2:

    Add various programs to report default attributes for various POSIX objects Closes #3531.

    3532 - RSB source only download is host specific

    Link https://devel.rtems.org/ticket/3532
    Id 3532
    Reporter Chris Johns
    Created 27 September 2018 22:59:29
    Modified 21 May 2019 23:27:31
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The RSB source only download is host specific. Configurations for builds can restrict sources or patches by host to work around specific host issues. Currently a source only download is host specific because the host check is based on the host the RSB is being run on.

    The release process uses source only downloading to create the complete set of sources in a release. This issue means some host specific source may not be captured.

    I am yet to figure how to resolve this issue because the download logic is driven by the configuration scripts and this type of logic exists in configuration files such as rtems-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9.cfg:

    %if %{_build_os} == freebsd || %{_build_os} == darwin
    %patch add gcc --rsb-file=freebsd-libgcc-sed-fix.patch -p0 https://gcc.gnu.org/bugzilla/attachment.cgi?id=41380
    %hash sha256 freebsd-libgcc-sed-fix.patch 8a11bd619c2e55466688e328da00b387d02395c1e8ff4a99225152387a1e60a4
    %endif

    The simpler construct in rtems-tools-common-1.cfg of:

     %ifos win32 mingw ming32
    SB_BUILD_ROOT_WAF=$SB_BUILD_ROOT$(echo %{_prefix} | cut -c 1-2)
    %else
    SB_BUILD_ROOT_WAF=$SB_BUILD_ROOT
    %endif

    is easier to manage as the %ifos logic can always return True however the %else path also need to be followed and this could break the logic in a configuration file. Yes, the example is not about sources or patches however it shows what could be used.
    I do not think creating a new variable such as %{download_only}and adding logic to the configuration file will help, for example:

    %if %{download_only} || %{_build_os} == freebsd || %{_build_os} == darwin
    %patch add gcc foobar-bsd.patch
    %else
    %patch add gcc foobar-gnu.patch
    %endif

    We require the logic to follow the %if True path __and__ the %else path.

    Comment 1
    1. Chris Johns, Thu, 27 Sep 2018 23:08:52 GMT
    2. description: modified (diff)
    Comment 2
    1. Chris Johns, Tue, 21 May 2019 23:27:31 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a74e432/rtems-source-builder:

    sb: Add sb-get-sources to download all referenced source files. Downloads all files into a single directory Iterates over all supported hosts to get any host dependent source no matter which host you run the command on. Closes #3532

    3533 - Add rtems_task_exit()

    Link https://devel.rtems.org/ticket/3533
    Id 3533
    Reporter Sebastian Huber
    Created 28 September 2018 08:04:51
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3529
    Blocked by  

    Description

    The rtems_task_delete(RTEMS_SELF) function does not return. In order to aid compilers and static analysis tools provide an rtems_task_exit() function which can be specified as a no return function.

    void rtems_task_exit(void) RTEMS_NO_RETURN; 

    This is similar to the POSIX equivalent.

    void pthread_exit (void *__value_ptr) __dead2; 
    Comment 1
    1. Sebastian Huber, Thu, 04 Oct 2018 08:49:55 GMT

    In e50e3f70/rtems:

    rtems: Add rtems_task_exit() Update #3533.
    Comment 2
    1. Sebastian Huber, Thu, 04 Oct 2018 08:50:06 GMT

    In f004b2b8/rtems:

    Use rtems_task_exit() Update #3530. Update #3533.
    Comment 3
    1. Sebastian Huber, Thu, 04 Oct 2018 09:05:52 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 6a20bd2/rtems-docs:

    c-user: Document rtems_task_exit() Close #3533.
    Comment 4
    1. Sebastian Huber, Fri, 05 Oct 2018 05:31:58 GMT

    In 8352d41/rtems:

    spthreadlife01: A task exit must not return Update #3533.
    Comment 5
    1. Sebastian Huber, Mon, 08 Oct 2018 05:15:42 GMT

    In 51b3cbca/rtems:

    tests: Use rtems_task_exit() Update #3533.
    Comment 6
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3535 - Remove stdin, stdout, stderr convenience routines for CEXP

    Link https://devel.rtems.org/ticket/3535
    Id 3535
    Reporter Sebastian Huber
    Created 1 October 2018 06:18:05
    Modified 4 October 2018 08:49:45
    Owner Sebastian Huber
    Type task
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    These functions should be moved to a general CEXP support.

    Comment 1
    1. Sebastian Huber, Thu, 04 Oct 2018 08:49:45 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 57a7ecde/rtems:

    telnetd: Remove CEXP convenience routines Close #3535.

    3536 - Move RTEMS configuration data to a common config directory

    Link https://devel.rtems.org/ticket/3536
    Id 3536
    Reporter Chris Johns
    Created 2 October 2018 06:49:45
    Modified 3 October 2018 01:51:51
    Owner Chris Johns
    Type task
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Move the rtems-bsp-builder configuration files to a common area in the RTEMS Tools project and create an rtems.py module to handle the configuration. This allows a number of tools access to the arch/bsp data.

    In time this directory of data can move into the rtems.git repo.

    Comment 1
    1. Chris Johns, Wed, 03 Oct 2018 01:51:51 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 5416cfa/rtems-tools:

    config: Create a config directory and move the RTEMS arch/bsp data to it. Closes #3536

    3537 - RSB and RTEMS Tools Support for python2 and python3

    Link https://devel.rtems.org/ticket/3537
    Id 3537
    Reporter Chris Johns
    Created 2 October 2018 21:38:43
    Modified 25 December 2018 01:15:53
    Owner Chris Johns
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Upstream python does not create a python command any more and creates python2 and python3. Distributions and operating systems are starting to ship without the python command.

    The RSB and RTEMS Tools python commands need to be updated and tested so they run on Python2 and Python3 and support added to use the available commands.

    Comment 1
    1. Sebastian Huber, Thu, 04 Oct 2018 05:55:01 GMT

    Do we have a host platform without python3 support? If not, then I would simply use python3 and stop using python/python2.

    Comment 2
    1. Chris Johns, Thu, 04 Oct 2018 06:30:58 GMT

    Replying to Sebastian Huber:

    Do we have a host platform without python3 support? If not, then I would simply use python3 and stop using python/python2.

    In time we will need to switch to python3 however I am not in a position to go over all the code and do this. I think it also makes things difficult or at least more complicated for users with established environment to get such a hard error. We should consider a softer landing if this is possible. I am considering moving to a shell script that checks for python2 then python3 and if not found outputs a user friendly error message. The existing code is moved into the python directories run from the python command line. Once we are happy with python3 we can switch the order we check. A script would let us add an environment variable we could use to force a version to test with without needing symlinks etc.

    Comment 3
    1. Sebastian Huber, Thu, 04 Oct 2018 06:40:08 GMT

    I think we already have a fairly good Python 3 support, since on a recent msys2 there is no Python 2 available?

    One issue is probably the RTEMS Tester. We had some difficulties with the TFTP Server:

    ​https://github.com/msoulier/tftpy/pull/94

    The latest tftpy seems to work only with Python 3.5, but not 3.4.

    Comment 4
    1. Chris Johns, Thu, 04 Oct 2018 07:21:09 GMT

    Replying to Sebastian Huber:

    I think we already have a fairly good Python 3 support, since on a recent msys2 there is no Python 2 available?

    I agree we seem to be in good shape so this is not about our code or even the developer set ups. I am concerned about user set ups and considering the effect on them.

    Also, will there be a python4, if so do we go through all this again?

    One issue is probably the RTEMS Tester. We had some difficulties with the TFTP Server:

    ​https://github.com/msoulier/tftpy/pull/94

    The latest tftpy seems to work only with Python 3.5, but not 3.4.

    Hmmm.

    Comment 5
    1. Chris Johns, Fri, 12 Oct 2018 16:48:06 GMT
    2. severity: changed from normal to blocker

    We need this working for a release.

    Comment 6
    1. Chris Johns, Fri, 19 Oct 2018 00:21:47 GMT
    2. status: changed from assigned to accepted
    Comment 7
    1. Chris Johns, Sun, 21 Oct 2018 00:02:49 GMT

    In 13f4c37/rtems-source-builder:

    sb: Add support to search for a suitable version of python. The command python has been removed from upstream python and python2 and python3 is now used. This patch wraps the commands in a shell script that locates a suitable python to run. Updates #3537
    Comment 8
    1. Chris Johns, Wed, 24 Oct 2018 10:46:06 GMT

    In e2209fa/rtems-source-builder:

    sb: Fix rtems-build-dep to handle various issues Remove CR characters on Windows. Force the compiler to output English so the pattern matching works. Updates #3537.
    Comment 9
    1. Joel Sherrill, Wed, 24 Oct 2018 18:42:23 GMT

    In 0794cc3/rtems-source-builder:

    rtems-build-dep: Add support for Cygwin updates #3537.
    Comment 10
    1. Chris Johns, Thu, 08 Nov 2018 22:58:32 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In e058db0/rtems-tools:

    python: Provide support to select a valid python version. Update imports after wrapping the code. Fix python3 issues. Fix config path issues for in repo and install runs. Closes #3537
    Comment 11
    1. Chris Johns, Mon, 17 Dec 2018 23:59:24 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    Support for python-config needs to be added. FreeBSD 11.2-RELEASE-p5 has:

    $ find /usr/local/ -name Python.h
    /usr/local/include/python3.6m/Python.h 

    Notice the m in the path. The python-config command gives:

    $ python3-config --includes
    -I/usr/local/include/python3.6m -I/usr/local/include/python3.6m 

    The RSB should detect and use a suitable the python-config command to find the include paths and to use those paths before looks at default paths.

    Comment 12
    1. Chris Johns, Tue, 25 Dec 2018 01:15:53 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    In 257c926/rtems-source-builder:

    gdb/python: Use python-config for the configuration if found. Do not assume the installed paths for the header and library. Ask python-config if found. Close #3537.

    3538 - Classic API Barrier Wait Section Title Has Wrong Name

    Link https://devel.rtems.org/ticket/3538
    Id 3538
    Reporter Joel Sherrill
    Created 3 October 2018 16:18:12
    Modified 5 October 2018 21:27:59
    Owner Joel Sherrill
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The section title says obtain not wait.

    Likely also applies to 4.11.

    Comment 1
    1. Joel Sherrill, Wed, 03 Oct 2018 16:18:20 GMT
    2. owner: set to Joel Sherrill
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Fri, 05 Oct 2018 21:27:59 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 304bc2c/rtems-docs:

    barrier_manager.rst: Fix Barrier Wait Section Title closes #3538.

    3539 - Remove CPU_PROVIDES_IDLE_THREAD_BODY

    Link https://devel.rtems.org/ticket/3539
    Id 3539
    Reporter Sebastian Huber
    Created 4 October 2018 06:04:34
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the CPU_PROVIDES_IDLE_THREAD_BODY option to avoid unnecessary conditional compilation.

    Comment 1
    1. Sebastian Huber, Mon, 08 Oct 2018 05:15:31 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 8776bb9/rtems:

    score: Remove CPU_PROVIDES_IDLE_THREAD_BODY Remove the CPU_PROVIDES_IDLE_THREAD_BODY option to avoid unnecessary conditional compilation. Close #3539.
    Comment 2
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3542 - Remove keep_stdio feature from Telnet service

    Link https://devel.rtems.org/ticket/3542
    Id 3542
    Reporter Sebastian Huber
    Created 9 October 2018 12:14:38
    Modified 10 October 2018 12:06:50
    Owner Sebastian Huber
    Type task
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The Telnet service started via rtems_telnetd_start() has a keep_stdio feature. This just a task and executes the command function in a loop. For this kind of service we do not library support. This can be done by an application task on its own. Remove this functionality and provide only the real Telnet services.

    Comment 1
    1. Sebastian Huber, Wed, 10 Oct 2018 12:06:50 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 629faf9/rtems:

    telnetd: Remove keep stdio feature The Telnet service started via rtems_telnetd_start() had a keep stdio feature. This just created a task and executed the command function in a loop. For this kind of service we do not library support. This can be done by an application task on its own. Remove this feature and provide only the real Telnet server functionality. Use syslog() for error and status messages. Add test program for the Telnet server. Close #3542.

    3543 - Change Telnet server to allocate most resources during initialization

    Link https://devel.rtems.org/ticket/3543
    Id 3543
    Reporter Sebastian Huber
    Created 9 October 2018 12:56:35
    Modified 11 October 2018 07:12:08
    Owner Sebastian Huber
    Type task
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3529
    Blocked by  

    Description

    The Telnet server currently creates the resources needed for a client connection on demand. Allocate most resources during initialization to avoid sporadic resource shortage issues.

    Comment 1
    1. Sebastian Huber, Thu, 11 Oct 2018 07:11:14 GMT

    In 6d3ec58/rtems:

    telnetd: Simplify task spawn function Use the minimum task size for the telnet server task since it has to deal only with simple socket operations. Update #3543.
    Comment 2
    1. Sebastian Huber, Thu, 11 Oct 2018 07:11:25 GMT

    In 1c567c5/rtems:

    telnetd: Rename shell_args to telnetd_session Update #3543.
    Comment 3
    1. Sebastian Huber, Thu, 11 Oct 2018 07:11:35 GMT

    In bf4c7ff6/rtems:

    telnetd: Create server socket at start Update #3543.
    Comment 4
    1. Sebastian Huber, Thu, 11 Oct 2018 07:11:46 GMT

    In 0f0e130/rtems:

    telnetd: Allocate the server context Update #3543.
    Comment 5
    1. Sebastian Huber, Thu, 11 Oct 2018 07:11:57 GMT

    In 0dc303f/rtems:

    telnetd: Create sessions at start Update #3543.
    Comment 6
    1. Sebastian Huber, Thu, 11 Oct 2018 07:12:08 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 26b58b7e/rtems:

    telnetd: Add server port to configuration Close #3543.

    3545 - Support O_DIRECTORY open() flag

    Link https://devel.rtems.org/ticket/3545
    Id 3545
    Reporter Sebastian Huber
    Created 11 October 2018 08:49:05
    Modified 23 October 2018 14:02:07
    Owner Sebastian Huber
    Type task
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3530
    Blocked by  

    Description

    Use this flag in opendir().

    Comment 1
    1. Sebastian Huber, Fri, 12 Oct 2018 12:16:56 GMT

    In 35c533f/rtems-source-builder:

    5: Update Newlib Pick up POSIX header file changes and improved opendir() implementation. This addesses time of check and time of use error conditions (TOCTOU). Update #3530. Update #3545. Update #3546. Update #3547.
    Comment 2
    1. Sebastian Huber, Thu, 18 Oct 2018 09:13:10 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 4af18b3/rtems:

    Support O_DIRECTORY open() flag Close #3545.
    Comment 3
    1. Sebastian Huber, Tue, 23 Oct 2018 14:02:07 GMT

    In 92e0eed/rtems:

    psxreaddir: Adjust test due to opendir() changes Update #3545.

    3546 - Support O_NOFOLLOW open() flag

    Link https://devel.rtems.org/ticket/3546
    Id 3546
    Reporter Sebastian Huber
    Created 11 October 2018 08:50:06
    Modified 23 October 2018 14:02:33
    Owner Sebastian Huber
    Type task
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Fri, 12 Oct 2018 12:16:56 GMT

    In 35c533f/rtems-source-builder:

    5: Update Newlib Pick up POSIX header file changes and improved opendir() implementation. This addesses time of check and time of use error conditions (TOCTOU). Update #3530. Update #3545. Update #3546. Update #3547.
    Comment 2
    1. Sebastian Huber, Tue, 23 Oct 2018 14:02:33 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 1ad26cd/rtems:

    Support O_NOFOLLOW open() flag Close #3546.

    3547 - Support O_CLOEXEC open() flag

    Link https://devel.rtems.org/ticket/3547
    Id 3547
    Reporter Sebastian Huber
    Created 11 October 2018 08:50:59
    Modified 23 October 2018 14:02:29
    Owner Sebastian Huber
    Type task
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This is a POSIX flag. Make sure its use causes no open failure.

    Comment 1
    1. Sebastian Huber, Fri, 12 Oct 2018 12:16:56 GMT

    In 35c533f/rtems-source-builder:

    5: Update Newlib Pick up POSIX header file changes and improved opendir() implementation. This addesses time of check and time of use error conditions (TOCTOU). Update #3530. Update #3545. Update #3546. Update #3547.
    Comment 2
    1. Sebastian Huber, Tue, 23 Oct 2018 14:02:29 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 3825926/rtems:

    Support O_CLOEXEC open() flag Make sure this flag is ignored and does not prevent a successful open. Close #3547.

    3549 - Obsolete powerpc/virtex BSP

    Link https://devel.rtems.org/ticket/3549
    Id 3549
    Reporter Sebastian Huber
    Created 15 October 2018 05:11:29
    Modified 15 October 2018 05:15:00
    Owner Sebastian Huber
    Type task
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3505, 3550
    Blocked by  

    Description

    This BSP is quite old (was added 1995), unmaintained and likely without users:

    ​https://lists.rtems.org/pipermail/users/2018-September/032557.html

    Comment 1
    1. Sebastian Huber, Mon, 15 Oct 2018 05:12:06 GMT
    2. blocking: set to 3550
    Comment 2
    1. Sebastian Huber, Mon, 15 Oct 2018 05:14:44 GMT
    2. blocking: changed from 3550 to 3505, 3550
    Comment 3
    1. Sebastian Huber, Mon, 15 Oct 2018 05:15:00 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3551 - Move default configuration to separate library

    Link https://devel.rtems.org/ticket/3551
    Id 3551
    Reporter Sebastian Huber
    Created 15 October 2018 06:21:45
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 2514
    Blocked by  

    Description

    An RTEMS application default configuration is contained in cpukit/libmisc/dummy/default-configuration.c. This default configuration is contained in librtemscpu.a. This has at least two problems:

  • Application configuration errors may pull in the default configuration which in turn leads to multiply define symbols error. This is quite confusing. You have to consult the linker map file to figure out what cased the pull in of the default configurations. You need to know what a linker map file is and how you generate it with your build system. This is not very user friendly.
  • It prevents the use of default configuration items for each subsystem in librtemscpu.a. This can be used to reduce the size of the configuration itself.
  • Proposed change: Move the default configuration to a separate library, e.g. librtemsdefaultconfig.a.

    Comment 1
    1. Sebastian Huber, Tue, 23 Oct 2018 14:12:55 GMT

    In 1b89636/rtems_waf:

    Avoid default RTEMS application configuration Use a test body with a proper RTEMS application configuration to avoid a dependency on the default configuration. Do not include directly since this header file is an implementation detail. Update #3551.
    Comment 2
    1. Sebastian Huber, Thu, 25 Oct 2018 05:52:50 GMT

    In 2ce13cf/rtems-libbsd:

    Update rtems_waf Update #3551.
    Comment 3
    1. Sebastian Huber, Thu, 25 Oct 2018 05:57:01 GMT

    In 15c9509/examples-v2:

    Update rtems_waf Update #3551.
    Comment 4
    1. Sebastian Huber, Tue, 30 Oct 2018 06:11:50 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 55b69ed/rtems:

    Move default config to librtemsdefaultconfig.a An RTEMS application default configuration is contained in cpukit/libmisc/dummy/default-configuration.c. This default configuration was contained in librtemscpu.a. This had at least two problems: Application configuration errors may have pulled in the default configuration which in turn lead to multiply define symbols error. This was quite confusing. You had to consult the linker map file to figure out what cased the pull in of the default configuration. You needed to know what a linker map file is and how you generate it with your build system. This was not very user friendly. It prevented the use of default configuration items for each subsystem in librtemscpu.a. This may be used to reduce the size of the configuration itself. Move the default configuration to the separate library librtemsdefaultconfig.a. Close #3551.
    Comment 5
    1. Sebastian Huber, Thu, 08 Nov 2018 13:00:54 GMT

    In 942d52a/rtems:

    build: Fix library order Update #3551.
    Comment 6
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3552 - cpu usage error in SMP mode

    Link https://devel.rtems.org/ticket/3552
    Id 3552
    Reporter jameszxj
    Created 17 October 2018 05:38:26
    Modified 19 December 2019 13:21:22
    Owner Chris Johns
    Type defect
    Component shell
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    • CPU load dispaly error in SMP mode

    Load Average: 100.510% Load: 100.966% Idle: 99.033%

    In fact,CPU is doing nothing.

    • priority display unreadable in SMP mode
      in diffrent Schedulers priority is map to a core priority, I think unmap

    maybe reasonable when display the infomation

    I create a patch about this,see the attachment.

    Attachments:

    1 jameszxj, Wed, 17 Oct 2018 05:38:48 GMT
      attach: set to cpuusagetop.patch
    Comment 1
    1. Chris Johns, Fri, 19 Oct 2018 00:11:38 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to accepted
    Comment 2
    1. Chris Johns, Thu, 19 Dec 2019 13:21:22 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In c737748b/rtems:

    libmisc/top: Fix the idle time and priorities on SMP This patch is based on the patch attached to #3552 submitted by jameszxj. Closes #3552

    3553 - rtems-libbsd Missing waf in Top Directory

    Link https://devel.rtems.org/ticket/3553
    Id 3553
    Reporter Joel Sherrill
    Created 18 October 2018 21:53:12
    Modified 26 October 2018 21:14:41
    Owner  
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity critical
    Keywords waf
    Cc  
    Blocking  
    Blocked by  

    Description

    At least examples-v2 and rtems-libbsd use waf to build. examples-v2 has a copy of waf known to work for the users' convenience. rtems-libsd is missing one. Add one to rtems-libbsd.

    Also (if there are other repos using waf), make sure they have a copy of waf also.

    Comment 1
    1. Joel Sherrill, Thu, 25 Oct 2018 22:06:08 GMT
    2. summary: changed from rterms-libbsd Missing waf in Top Directory to rtems-libbsd Missing waf in Top Directory
    Comment 2
    1. Joel Sherrill, Fri, 26 Oct 2018 21:14:41 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    ​https://git.rtems.org/rtems-libbsd/commit/?id=4ed04cbc0696f0f78029241b8224e7eab4f9bbfe


    3554 - rtems-libbsd README.waf Needs an Update Sweep

    Link https://devel.rtems.org/ticket/3554
    Id 3554
    Reporter Joel Sherrill
    Created 18 October 2018 21:54:48
    Modified 22 January 2019 14:04:04
    Owner Sebastian Huber
    Type defect
    Component network/libbsd
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    It is out of date at least by mentioning 4.12 instead of 5. If there are other nits or issues, they need to be addressed while updating the release info.

    Comment 1
    1. Joel Sherrill, Thu, 18 Oct 2018 21:55:02 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to assigned
    Comment 2
    1. Sebastian Huber, Tue, 22 Jan 2019 14:04:04 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Fixed with [9e7f3b73b26c2c724caf2560744894f1108a386b/rtems-libbsd].


    3555 - IRC bots need to be registered to join #rtems

    Link https://devel.rtems.org/ticket/3555
    Id 3555
    Reporter Amar Takhar
    Created 18 October 2018 23:58:46
    Modified 19 October 2018 02:02:00
    Owner Amar Takhar
    Type infra
    Component admin
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords irc
    Cc  
    Blocking  
    Blocked by  

    Description

    Due to the spam on Freenode only registered users can join #rtems. The bots both need accounts now.

    Comment 1
    1. Amar Takhar, Fri, 19 Oct 2018 02:02:00 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    This is fixed, stupid spammers!


    3557 - Test ticket

    Link https://devel.rtems.org/ticket/3557
    Id 3557
    Reporter Amar Takhar
    Created 20 October 2018 14:47:19
    Modified 20 October 2018 15:21:51
    Owner Amar Takhar
    Type infra
    Component admin
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3175
    Blocked by  

    Description

    Using this as a test ticket to test out my fix.

    Comment 1
    1. Amar Takhar, Sat, 20 Oct 2018 14:47:26 GMT

    Test comment 1

    Comment 2
    1. Amar Takhar, Sat, 20 Oct 2018 14:47:32 GMT

    Test comment 2

    Comment 3
    1. Amar Takhar, Sat, 20 Oct 2018 14:57:04 GMT

    Okay this should email me in comment:2 with the fix that email will not be sent. The fix isn't in testing to make sure I get the unwanted email.

    Comment 4
    1. Amar Takhar, Sat, 20 Oct 2018 14:58:26 GMT

    Another test to be sure.

    Comment 5
    1. Amar Takhar, Sat, 20 Oct 2018 15:09:32 GMT

    Testing fix.

    Comment 6
    1. Amar Takhar, Sat, 20 Oct 2018 15:10:13 GMT

    Removing fix and testing old method to be sure.

    Comment 7
    1. Amar Takhar, Sat, 20 Oct 2018 15:12:21 GMT

    The fix in comment:5 worked great. I removed it and it was broken again this should be the last test before I attempt to close #3175

    Comment 8
    1. Amar Takhar, Sat, 20 Oct 2018 15:16:59 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Fix works as expected see -- I forgot to open a ticket for this #2932 is unrelated.

    Comment 9
    1. Amar Takhar, Sat, 20 Oct 2018 15:21:27 GMT
    2. type: changed from defect to infra
    3. blocking: changed from 2932 to 3175
    4. summary: changed from Test ticket (Fix for #2932) to Test ticket

    I never opened a ticket or this #2932 is for a different issue.


    3558 - Update TracSpamFilter

    Link https://devel.rtems.org/ticket/3558
    Id 3558
    Reporter Amar Takhar
    Created 20 October 2018 15:36:23
    Modified 20 October 2018 15:36:36
    Owner Amar Takhar
    Type infra
    Component admin
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Updated to the latest Trac Spam Filter and upgraded captcha to v2 to avoid any errors. This was reported a while back and should fix any issues.

    There are more please open a new ticket.

    Comment 1
    1. Amar Takhar, Sat, 20 Oct 2018 15:36:36 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Please re-open if there any other captcha / spam issues.


    3559 - Fix NavAdd plugin.

    Link https://devel.rtems.org/ticket/3559
    Id 3559
    Reporter Amar Takhar
    Created 20 October 2018 15:50:26
    Modified 21 October 2018 03:35:43
    Owner Amar Takhar
    Type infra
    Component admin
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc Joel Sherrill Chris Johns
    Blocking  
    Blocked by  

    Description

    I had no idea but this had gotten removed in the last upgrade I've re-added it.

    This makes a few changes to the navigation:

    • "New Ticket" now goes to /wiki/NewTicket
    • There is a new button "New Ticket (direct)" in the upper right for those who want to directly go to creating a ticket.
    • "My Tickets" used to go to a query but now goes to the new wiki:MyTickets page.

    These changes existed years ago when NavAdd? was working I opened this ticket in case anyone has complaints about it coming back if not I will close it in a few days.

    Comment 1
    1. Gedare Bloom, Sat, 20 Oct 2018 18:43:40 GMT

    Seems fine to me.

    Comment 2
    1. Amar Takhar, Sun, 21 Oct 2018 03:35:43 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Based on feedback I'm closing this early it can always be re-opened and if required.


    3560 - Fix FlexibleAssignTo

    Link https://devel.rtems.org/ticket/3560
    Id 3560
    Reporter Amar Takhar
    Created 20 October 2018 18:39:22
    Modified 21 October 2018 03:36:03
    Owner Amar Takhar
    Type infra
    Component admin
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by 2933

    Description

    When we first went to trac we had restrictions on the 'owner' to developers only. When track was upgraded this broke completely but all the code to handle this was already in place.

    I took the time to fix it today so we have dropdowns again.

    I've created this ticket to see if anyone has an issue with this should we keep it? Drop it? I know it's been years but it was our original choice.

    See any ticket the 'reassign to' and on a new ticket the 'assign to' is now a dropdown. These are based on trac permissions so we can always add more if we need it but it really should be restricted to having a project member be the owner so we can ensure tickets are closed and sorted properly.

    Comment 1
    1. Joel Sherrill, Sat, 20 Oct 2018 18:45:16 GMT

    I'm not sure what this changes so don't have an opinion yet. If it sucks, I am sure someone will complain. Lol

    Comment 2
    1. Gedare Bloom, Sat, 20 Oct 2018 18:45:41 GMT

    With this we lose the ability to set the owner to the "Needs Funding" category to indicate that no developer is willing to be responsible for it.

    Comment 3
    1. Amar Takhar, Sat, 20 Oct 2018 19:01:53 GMT

    Replying to Gedare:

    With this we lose the ability to set the owner to the "Needs Funding" category to indicate that no developer is willing to be responsible for it.

    Thank you I have just fixed this.

    Comment 4
    1. Amar Takhar, Sat, 20 Oct 2018 21:46:33 GMT

    Replying to Joel Sherrill:

    I'm not sure what this changes so don't have an opinion yet. If it sucks, I am sure someone will complain. Lol

    Look at these two pages:

    ​https://devel.rtems.org/newticket ​https://devel.rtems.org/ticket/3560

    Check the "assign" and "assign to" or "ressign-to" fields it is now a restricted dropdown. It used to be like this years ago.

    Comment 5
    1. Amar Takhar, Sat, 20 Oct 2018 22:58:08 GMT
    2. blockedby: set to 2933
    Comment 6
    1. Amar Takhar, Sun, 21 Oct 2018 03:36:03 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Based on feedback I am closing this it can always be re-opened if there are any issues.


    3561 - Migrate to CommitTicketUpdater

    Link https://devel.rtems.org/ticket/3561
    Id 3561
    Reporter Amar Takhar
    Created 21 October 2018 00:13:37
    Modified 21 November 2018 23:14:33
    Owner Amar Takhar
    Type infra
    Component admin
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority highest
    Severity critical
    Keywords git
    Cc Joel Sherrill Chris Johns Sebastian Huber
    Blocking  
    Blocked by 2233, 3238

    Description

    The old script was ancient and outdated. I've now killed it off and moved to the internal system described here:

    ​https://trac.edgewall.org/wiki/CommitTicketUpdater

    This should handle all scenarios if it does not please let me know. I will leave this ticket open for a week or so.

    Comment 1
    1. Chris Johns, Sun, 21 Oct 2018 21:15:11 GMT

    Should ​https://devel.rtems.org/wiki/Developer/Git/Committers be updated with something about the triggers, even a link to Trac doco?

    Comment 2
    1. Amar Takhar, Sun, 21 Oct 2018 21:28:55 GMT

    Replying to Chris Johns:

    Should ​https://devel.rtems.org/wiki/Developer/Git/Committers be updated with something about the triggers, even a link to Trac doco?

    Great idea how is this? wiki:Developer/Git/Committers#TicketUpdates

    Comment 3
    1. Chris Johns, Tue, 23 Oct 2018 06:23:25 GMT
    2. priority: changed from normal to highest
    3. severity: changed from normal to critical

    Git pushes are not updating __Trac__ up as report by Sebastian in an email..

    ​https://git.rtems.org/rtems_waf/commit/?id=1b896361d302aeda0145af90972aea863e28898f

    It didn't update the ticket:

    ​https://devel.rtems.org/ticket/3551

    It doesn't show up in the Git view in Trac:

    ​https://devel.rtems.org/log/rtems_waf

    The common git hook /data/support/git-support/hooks/post-receive-3 for __Trac__ is commented out:

    stat -x /data/support/git-support/hooks/post-receive-3 | grep Modify
    Modify: Sun Oct 21 00:09:04 2018 

    I suggest we manually update all tickets until this is resolved. I am not sure why this has been done.

    Comment 4
    1. Amar Takhar, Tue, 23 Oct 2018 13:48:36 GMT

    Replying to Chris Johns:

    I suggest we manually update all tickets until this is resolved. I am not sure why this has been done.

    It was done due to the numerous complaints about tickets not updating especially with multiple commits.

    The way we were doing has been unsupported for over 4 years now it's broken and hacky this change was inevitable I'll look into it I can manually force trac to update the tickets as required so we won't lose anything.

    Comment 5
    1. Amar Takhar, Tue, 23 Oct 2018 14:08:21 GMT

    I forced an update and changed how I was doing the update we'll see if it works this way.

    Comment 6
    1. Chris Johns, Tue, 23 Oct 2018 21:46:07 GMT

    Replying to Amar Takhar:

    I forced an update and changed how I was doing the update we'll see if it works this way.

    Could you please explain the change and is there anything we need to do, I am confused if we still need to manually handle ticket updates?

    Comment 7
    1. Sebastian Huber, Wed, 24 Oct 2018 05:05:35 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Thanks for fixing this. The automatic update worked with this commit:

    [05a5366469ee4ee7776f70dceea631ea57a63b19/rtems-docs]

    Comment 8
    1. Sebastian Huber, Fri, 26 Oct 2018 17:17:54 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    I checked in four commits at once:

    ​https://git.rtems.org/rtems/log/?qt=range&q=01595a4f321ad890270a3bc3e21c98ba51163562..24b58072ff1ac5a1691374aa139807bf866bf01a

    Only the last commit updated the ticket system. This one for example didn't update the corresponding ticket:

    ​https://git.rtems.org/rtems/commit/?id=4b801acc2003073c50b381435896a29f29e51a3c

    ​https://devel.rtems.org/ticket/2514#comment:41

    Comment 9
    1. Amar Takhar, Thu, 15 Nov 2018 02:18:10 GMT

    While working on Buildbot I discovered what was causing this issue. The changeset updating in trac wasn't properly iterating over every commit in a push just the parent.

    I have changed it now hopefully it should catch everything now. Let me know if it doesn't thanks.

    Comment 10
    1. Sebastian Huber, Fri, 16 Nov 2018 06:25:22 GMT

    I committed this to rtems-docs:

    ​https://git.rtems.org/rtems-docs/commit/?id=e49e4056c7d4b7fa35881cfc3522c6e038940e84

    I received this from Git:

    git push origin e49e4056c7d4b7fa35881cfc3522c6e038940e84:master
    Counting objects: 4, done.
    Delta compression using up to 12 threads.
    Compressing objects: 100% (4/4), done.
    Writing objects: 100% (4/4), 481 bytes | 481.00 KiB/s, done.
    Total 4 (delta 3), reused 0 (delta 0)
    remote: 0: init
    remote: 1: mail vc@rtems.org
    remote: NoSuchChangeset: No changeset e49e4056c7d4b7fa35881cfc3522c6e038940e84 in the repository
    remote: 4: IRC
    remote: fatal: bad object e49e4056c7d4b7fa35881cfc3522c6e038940e84
    remote: irc notice: Invalid number of commits: 0
    remote: 5: Buildbot
    To ssh://dispatch.rtems.org/data/git/rtems-docs.git
       1a704cd..e49e405  e49e4056c7d4b7fa35881cfc3522c6e038940e84 -> master 

    The corresponding tickets were not updated, e.g. #3584.

    Comment 11
    1. Amar Takhar, Fri, 16 Nov 2018 23:07:44 GMT

    I reworked a lot of these scripts to make it much easier to modify going forward as a few more will be added. I left some old variables in one of them that were statically set to 'rtems'.

    This should fix this problem please let me know if it does not.

    Comment 12
    1. Amar Takhar, Wed, 21 Nov 2018 23:14:33 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    I have not heard any complaints and multiple references should work now as the bug was extremely clear. If it's still an issue please re-open.


    3562 - Use a short paths for the RSB temporary build path on Windows

    Link https://devel.rtems.org/ticket/3562
    Id 3562
    Reporter Chris Johns
    Created 22 October 2018 00:58:24
    Modified 5 November 2018 04:47:51
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The %{_tmproot} path is currently based on a BuildRoot setting in the build configuration files. The line is:

    BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n) 

    This is for a shared $TEMP path plus the name is not shortened so on Windowss these paths become long.
    Remove the BuildRoot from all configuration files and add support for a shortened temporary path. Windows needs short paths due to the 256 max. path length issue.

    Comment 1
    1. Chris Johns, Mon, 22 Oct 2018 00:58:42 GMT
    2. component: changed from admin to tool/rsb
    Comment 2
    1. Chris Johns, Mon, 05 Nov 2018 04:47:51 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 96c414c/rtems-source-builder:

    windows: Remove BuildRoot? from all configs, add a short tmp path. Closes #3562.

    3568 - RSB: UnboundLocalError: local variable 'build_max_size_human' referenced before assignment

    Link https://devel.rtems.org/ticket/3568
    Id 3568
    Reporter Sebastian Huber
    Created 25 October 2018 05:59:20
    Modified 11 January 2019 06:25:45
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    ../source-builder/sb-set-builder --prefix=/build/rtems/5 5/rtems-or1k

    ...
    config: tools/rtems-gcc-4.9.3-newlib-08eab6396f678cf5e5968acaed0bae9fd129983b.cfg
    package: or1k-rtems5-gcc-4.9.3-newlib-08eab6396f678cf5e5968acaed0bae9fd129983b-x86_64-linux-gnu-1
    warning: gcc-4.9.3-or1k.patch: no hash found
    building: or1k-rtems5-gcc-4.9.3-newlib-08eab6396f678cf5e5968acaed0bae9fd129983b-x86_64-linux-gnu-1
    error: building or1k-rtems5-gcc-4.9.3-newlib-08eab6396f678cf5e5968acaed0bae9fd129983b-x86_64-linux-gnu-1
    Build FAILED
    See error report: rsb-report-or1k-rtems5-gcc-4.9.3-newlib-08eab6396f678cf5e5968acaed0bae9fd129983b-x86_64-linux-gnu-1.txt
    error: building or1k-rtems5-gcc-4.9.3-newlib-08eab6396f678cf5e5968acaed0bae9fd129983b-x86_64-linux-gnu-1
    Mailing report: build@rtems.org
    Traceback (most recent call last):
    File "../source-builder/sb/cmd-set-builder.py", line 26, in
    setbuilder.run()
    File "/scratch/git-rtems-source-builder/source-builder/sb/setbuilder.py", line 619, in run
    b.build(deps, mail = mail)
    File "/scratch/git-rtems-source-builder/source-builder/sb/setbuilder.py", line 530, in build
    body += 'Maximum build usage: ' + build_max_size_human + os.linesep
    UnboundLocalError: local variable 'build_max_size_human' referenced before assignment
    Comment 1
    1. Sebastian Huber, Fri, 11 Jan 2019 06:25:45 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 5f6ad9d/rtems-source-builder:

    Fix 'build_max_size_human' ref. before assignment Close #3568.

    3569 - waf version in various rtems-repositories incompatible with python 3.7

    Link https://devel.rtems.org/ticket/3569
    Id 3569
    Reporter Malte Münch
    Created 25 October 2018 07:31:14
    Modified 27 February 2020 07:50:31
    Owner Chris Johns
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords waf, python
    Cc  
    Blocking  
    Blocked by  

    Description

    The current waf version included in rtems-tools is waf 1.9.9 (389f3f3b289f6b835a21ad4e128076cdb463d34d)

    it crashes when executed with python3. The current version of waf is 2.0.12 and resolves this issue.

    Attachments:

    1 Malte Münch, Thu, 25 Oct 2018 07:31:53 GMT
      attach: set to Bildschirmfoto von 2018-10-25 09-30-47.png
     
    Comment 1
    1. Chris Johns, Sun, 11 Nov 2018 00:51:33 GMT
    2. milestone: set to 5.1
    Comment 2
    1. Christian Mauderer, Tue, 18 Dec 2018 17:32:24 GMT

    This is a problem with old waf versions and python 3.7. See ​https://gitlab.com/ita1024/waf/commit/facdc0b173d933073832c768ec1917c553cb369c for details.

    Comment 3
    1. Christian Mauderer, Tue, 18 Dec 2018 17:37:35 GMT

    In e59f4ee/rtems-tools:

    waf: Update to waf-2.0.13. This fixes a problem with python 3.7. Update #3569.
    Comment 4
    1. Christian Mauderer, Wed, 19 Dec 2018 09:03:11 GMT
    2. summary: changed from waf version in rtems-tools incompatible with python3 to waf version in various rtems-repositories incompatible with python 3.7

    That problem is also true for the following three repositories:

    rtems-libbsd rtems-docs examples-v2

    I adapted the title of the bug report to reflect that.

    Comment 5
    1. Christian Mauderer, Fri, 21 Dec 2018 15:06:00 GMT

    In 2fac55d/rtems-source-builder:

    5/rtems-tools: Update RTEMS tools Picks up the new waf in rtems-tools to be compatible with python 3.7 and some tester updates. Update #3569.
    Comment 6
    1. Sebastian Huber, Tue, 25 Feb 2020 08:02:47 GMT
    2. component: changed from tool/rsb to build
    Comment 7
    1. Sebastian Huber, Wed, 26 Feb 2020 10:41:30 GMT

    In 4a2f3e5/rtems-tools:

    waf: Update to waf-2.0.19 Update #3569.
    Comment 8
    1. Sebastian Huber, Wed, 26 Feb 2020 10:46:33 GMT

    In 14c5cb7/rtems-source-builder:

    5: Update rtems-tools Pick up update to waf-2.0.19. Update #3569.
    Comment 9
    1. Sebastian Huber, Wed, 26 Feb 2020 13:27:20 GMT

    In e068cbf/rtems-docs:

    waf: Update to waf-2.0.19 Update #3569.
    Comment 10
    1. Sebastian Huber, Thu, 27 Feb 2020 07:49:59 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    I updated also rtems-libbd and rtems-examples (these repositories seem to be not covered by the server Git hooks).


    3576 - gdb 8.0.1 sis does not build on Cygwin

    Link https://devel.rtems.org/ticket/3576
    Id 3576
    Reporter Joel Sherrill
    Created 30 October 2018 23:13:30
    Modified 14 November 2018 18:47:45
    Owner Joel Sherrill
    Type defect
    Component tool/gdb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords sis, cygwin
    Cc  
    Blocking  
    Blocked by  

    Description

    Cygwin no longer has libtermcap. gdb/sim/erc32 needs a patch to find libncurses. Upstream gdb patch already merged.

    ​https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=c1230d1bab8e36e1aa40f3bbadcef9b5d9ddc041

    This ticket is just to contain a patch that applies cleanly to gdb 8.0.1 and to track adding that patch to the RSB.

    Attachments:

    1 Joel Sherrill, Tue, 30 Oct 2018 23:17:00 GMT
      attach: set to gdb-8.0.1-sis-cygwin.diff
     
    Comment 1
    1. Joel Sherrill, Mon, 12 Nov 2018 20:13:15 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 84a94f7/rtems-source-builder:

    rtems-gdb-8.0.1-1.cfg: Add Cygwin patch for ncurses not termcap This also updates windows.py to distinguish betweem MSYS2 and Cygwin. closes #3576.
    Comment 2
    1. Joel Sherrill, Wed, 14 Nov 2018 18:47:45 GMT

    In 384ff19/rtems-source-builder:

    rtems-gdb-8.0.1-1.cfg: Correct previous commit. Updates #3576.

    3577 - Avoid CLooG and ISL host depencencies for target GCC

    Link https://devel.rtems.org/ticket/3577
    Id 3577
    Reporter Sebastian Huber
    Created 31 October 2018 07:21:59
    Modified 6 November 2018 09:50:23
    Owner Sebastian Huber
    Type enhancement
    Component tool/gcc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    We already use GCC in-tree libraries for MPFR, MPC, GMP and zlib. Use them also for CLooG and ISL. This helps to ensure that the same target code is generated across host systems. It also helps to avoid GCC build issues in case future versions of ISL and CLooG available on the host system are incompatible to the GCC version picked up by the RSB for RTEMS.

    Comment 1
    1. Sebastian Huber, Mon, 05 Nov 2018 07:12:29 GMT

    Since GCC 5 the CLooG library is no longer necessary.

    Comment 2
    1. Sebastian Huber, Tue, 06 Nov 2018 09:50:16 GMT

    In 509dfbd/rtems-source-builder:

    Support in-tree CLooG and ISL libraries for GCC Update #3577.
    Comment 3
    1. Sebastian Huber, Tue, 06 Nov 2018 09:50:23 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 9955b1a/rtems-source-builder:

    5: Use in-tree ISL libraries for GCC Close #3577.

    3579 - testsuite's rtems-test-check.py python version support

    Link https://devel.rtems.org/ticket/3579
    Id 3579
    Reporter Chris Johns
    Created 1 November 2018 02:27:40
    Modified 8 November 2018 23:20:25
    Owner Chris Johns <chrisj@…>
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This command used in the testsuite needs to find a suitable python or the build system needs to find it and invoke it with that python.

    Comment 1
    1. Chris Johns, Thu, 08 Nov 2018 23:20:25 GMT
    2. owner: set to Chris Johns <chrisj@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 06ced25/rtems:

    testsuite: Add python verison support to rtems-test-check.py Closes #3579

    3583 - Add rtems_malloc() and rtems_calloc()

    Link https://devel.rtems.org/ticket/3583
    Id 3583
    Reporter Sebastian Huber
    Created 7 November 2018 11:56:08
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    The standard C/POSIX functions malloc() and calloc() set errno in case of an error. A dependency to errno pulls in getreent() which pulls in a lot of data structures and functions. This is an issue in low level code especially in the area of a basic board support package initialization and device drivers.

    Provide rtems_malloc() and rtems_calloc() functions declared in which do the same as the corresponding C/POSIX functions except setting errno.

    The posix_memalign() and aligned_alloc() functions do not have this issue with the errno.

    Comment 1
    1. Sebastian Huber, Mon, 12 Nov 2018 14:43:46 GMT

    In c1f3c2b8/rtems:

    score: Add and use malloc() family attributes Update #3583.
    Comment 2
    1. Sebastian Huber, Mon, 12 Nov 2018 14:43:54 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 6efc831/rtems:

    Add rtems_malloc() and rtems_calloc() Close #3583.
    Comment 3
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3585 - Deprecate proc_ptr

    Link https://devel.rtems.org/ticket/3585
    Id 3585
    Reporter Sebastian Huber
    Created 7 November 2018 12:38:13
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3586
    Blocked by 3599

    Description

    See comment in basedefs.h

     /**
    * XXX: Eventually proc_ptr needs to disappear!!!
    */
    typedef void * proc_ptr;
    Comment 1
    1. Sebastian Huber, Wed, 07 Nov 2018 12:39:29 GMT
    2. blocking: set to 3586
    Comment 2
    1. Sebastian Huber, Thu, 08 Nov 2018 15:15:33 GMT
    2. blockedby: set to 3599
    Comment 3
    1. Sebastian Huber, Mon, 12 Nov 2018 14:41:25 GMT

    In b15b288/rtems:

    score: Deprecate proc_ptr Update #3585.
    Comment 4
    1. Sebastian Huber, Mon, 12 Nov 2018 14:41:33 GMT

    In 3faa8459/rtems:

    rtems: Simplify rtems_interrupt_catch() Remove casts and superfluous inline functions. Update #3585.
    Comment 5
    1. Sebastian Huber, Mon, 12 Nov 2018 14:41:40 GMT

    In d997aa1/rtems:

    no_cpu: Remove use of proc_ptr Update #3585.
    Comment 6
    1. Sebastian Huber, Mon, 12 Nov 2018 14:41:48 GMT

    In 685aa28/rtems:

    arm: Remove use of proc_ptr Update #3585.
    Comment 7
    1. Sebastian Huber, Mon, 12 Nov 2018 14:41:57 GMT

    In 8203db45/rtems:

    bfin: Remove use of proc_ptr Update #3585.
    Comment 8
    1. Sebastian Huber, Mon, 12 Nov 2018 14:42:05 GMT

    In a043ff8/rtems:

    epiphany: Remove use of proc_ptr Update #3585.
    Comment 9
    1. Sebastian Huber, Mon, 12 Nov 2018 14:42:13 GMT

    In 3c6a6e8/rtems:

    i386: Remove use of proc_ptr Update #3585.
    Comment 10
    1. Sebastian Huber, Mon, 12 Nov 2018 14:42:21 GMT

    In 0e16fa45/rtems:

    lm32: Remove use of proc_ptr Update #3585.
    Comment 11
    1. Sebastian Huber, Mon, 12 Nov 2018 14:42:29 GMT

    In 5c6edee/rtems:

    m68k: Remove use of proc_ptr Update #3585.
    Comment 12
    1. Sebastian Huber, Mon, 12 Nov 2018 14:42:36 GMT

    In b6be8f33/rtems:

    mips: Remove use of proc_ptr Update #3585.
    Comment 13
    1. Sebastian Huber, Mon, 12 Nov 2018 14:42:44 GMT

    In 264e128/rtems:

    moxie: Remove use of proc_ptr Update #3585.
    Comment 14
    1. Sebastian Huber, Mon, 12 Nov 2018 14:42:52 GMT

    In 12dfa5e/rtems:

    nios2: Remove use of proc_ptr Update #3585.
    Comment 15
    1. Sebastian Huber, Mon, 12 Nov 2018 14:42:59 GMT

    In 54c5ffc/rtems:

    or1k: Remove use of proc_ptr Update #3585.
    Comment 16
    1. Sebastian Huber, Mon, 12 Nov 2018 14:43:07 GMT

    In ed9da8e/rtems:

    powerpc: Remove use of proc_ptr Update #3585.
    Comment 17
    1. Sebastian Huber, Mon, 12 Nov 2018 14:43:15 GMT

    In 510fbfc3/rtems:

    sh: Remove use of proc_ptr Update #3585.
    Comment 18
    1. Sebastian Huber, Mon, 12 Nov 2018 14:43:23 GMT

    In ce37237f/rtems:

    sparc: Remove use of proc_ptr Update #3585.
    Comment 19
    1. Sebastian Huber, Mon, 12 Nov 2018 14:43:31 GMT

    In 70928bc9/rtems:

    sparc64: Remove use of proc_ptr Update #3585.
    Comment 20
    1. Sebastian Huber, Mon, 12 Nov 2018 14:43:38 GMT

    In 4539e307/rtems:

    x86_64: Remove use of proc_ptr Update #3585.
    Comment 21
    1. Joel Sherrill, Thu, 12 Dec 2019 23:18:18 GMT

    This appears to have been resolved last year. There are no references to proc_ptr beyond the following:

    b15b2881 cpukit/include/rtems/score/basedefs.h       (Sebastian Huber     2018-11-08 06:25:06 +0100 564)   typedef void * proc_ptr RTEMS_DEPRECA 
    Comment 22
    1. Joel Sherrill, Thu, 12 Dec 2019 23:18:26 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    Comment 23
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3587 - Deprecate rtems_context

    Link https://devel.rtems.org/ticket/3587
    Id 3587
    Reporter Sebastian Huber
    Created 7 November 2018 12:42:48
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3588
    Blocked by  

    Description

    The rtems_context typedef as no corresponding API. A user can do nothing with it. It is only used in cpukit/libmisc/monitor/mon-monitor.c and cpukit/libmisc/monitor/mon-editor.c in RTEMS. Deprecate it in this release.

    Comment 1
    1. Sebastian Huber, Wed, 07 Nov 2018 12:43:40 GMT
    2. blocking: set to 3588
    Comment 2
    1. Sebastian Huber, Wed, 07 Nov 2018 12:44:06 GMT
    2. component: changed from admin to rtems
    Comment 3
    1. Sebastian Huber, Wed, 07 Nov 2018 12:44:33 GMT
    2. description: modified (diff)
    Comment 4
    1. Sebastian Huber, Wed, 07 Nov 2018 12:46:12 GMT
    2. description: modified (diff)
    Comment 5
    1. Sebastian Huber, Thu, 08 Nov 2018 07:11:27 GMT

    In ef30eb1/rtems:

    monitor: Remove dead code Update #3587. Update #3589.
    Comment 6
    1. Sebastian Huber, Fri, 09 Nov 2018 06:25:51 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 0ac4a77/rtems:

    rtems: Deprecate rtems_context The rtems_context typedef as no corresponding API. A user can do nothing with it. Close #3587.
    Comment 7
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3589 - Deprecate rtems_context_fp

    Link https://devel.rtems.org/ticket/3589
    Id 3589
    Reporter Sebastian Huber
    Created 7 November 2018 12:45:29
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3590
    Blocked by  

    Description

    The rtems_context_fp typedef as no corresponding API. A user can do nothing with it. It is only used in cpukit/libmisc/monitor/mon-editor.c in RTEMS. Deprecate it in this release.

    Comment 1
    1. Sebastian Huber, Wed, 07 Nov 2018 12:45:47 GMT
    2. blocking: 3588 deleted
    Comment 2
    1. Sebastian Huber, Wed, 07 Nov 2018 12:47:08 GMT
    2. blocking: set to 3590
    Comment 3
    1. Sebastian Huber, Thu, 08 Nov 2018 07:11:27 GMT

    In ef30eb1/rtems:

    monitor: Remove dead code Update #3587. Update #3589.
    Comment 4
    1. Sebastian Huber, Fri, 09 Nov 2018 06:25:59 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 7e86e00/rtems:

    rtems: Deprecate rtems_context_fp The rtems_context_fp typedef as no corresponding API. A user can do nothing with it. Close #3589.
    Comment 5
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3591 - Deprecate region_information_block

    Link https://devel.rtems.org/ticket/3591
    Id 3591
    Reporter Sebastian Huber
    Created 7 November 2018 12:49:28
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3592
    Blocked by  

    Description

    The region_information_block typedef as no corresponding API. It has no proper namespace prefix. A user can do nothing with it. It is only used in cpukit/libmisc/cpuuse/cpuusagetop.c and cpukit/libmisc/shell/main_mallocinfo.c in RTEMS. Deprecate it in this release.

    Comment 1
    1. Sebastian Huber, Wed, 07 Nov 2018 12:49:41 GMT
    2. blocking: 3590 deleted
    Comment 2
    1. Sebastian Huber, Wed, 07 Nov 2018 12:50:21 GMT
    2. blocking: set to 3592
    Comment 3
    1. Sebastian Huber, Fri, 09 Nov 2018 06:26:07 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d53862a/rtems:

    rtems: Deprecate region_information_block The region_information_block typedef as no corresponding API. It has no proper namespace prefix. A user can do nothing with it. Close #3591.
    Comment 4
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3593 - Deprecate rtems_thread_cpu_usage_t

    Link https://devel.rtems.org/ticket/3593
    Id 3593
    Reporter Sebastian Huber
    Created 7 November 2018 12:52:54
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3594
    Blocked by  

    Description

    The rtems_thread_cpu_usage_t typedef as no corresponding API. It violates the POSIX namespace. A user can do nothing with it. It is only used in cpukit/include/rtems/rtems/ratemon.h in RTEMS. Deprecate it in this release.

    Comment 1
    1. Sebastian Huber, Wed, 07 Nov 2018 12:53:29 GMT
    2. blocking: set to 3594
    Comment 2
    1. Sebastian Huber, Fri, 09 Nov 2018 06:26:15 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In aacc7a0/rtems:

    rtems: Deprecate rtems_thread_cpu_usage_t The rtems_thread_cpu_usage_t typedef as no corresponding API. It violates the POSIX namespace. A user can do nothing with it. Close #3593.
    Comment 3
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3595 - Deprecate rtems_rate_monotonic_period_time_t

    Link https://devel.rtems.org/ticket/3595
    Id 3595
    Reporter Sebastian Huber
    Created 7 November 2018 13:00:28
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3596
    Blocked by  

    Description

    The rtems_rate_monotonic_period_time_t typedef as no corresponding API. It violates the POSIX namespace. A user can do nothing with it. It is only used in cpukit/include/rtems/rtems/ratemon.h in RTEMS. Deprecate it in this release.

    Comment 1
    1. Sebastian Huber, Wed, 07 Nov 2018 13:01:09 GMT
    2. blocking: set to 3596
    Comment 2
    1. Sebastian Huber, Fri, 09 Nov 2018 06:26:22 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 1e039fb3/rtems:

    rtems: Deprecate rtems_rate_monotonic_period_time_t The rtems_rate_monotonic_period_time_t typedef as no corresponding API. It violates the POSIX namespace. A user can do nothing with it. Close #3595.
    Comment 3
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3598 - Move internal types of API objects to separate header file

    Link https://devel.rtems.org/ticket/3598
    Id 3598
    Reporter Sebastian Huber
    Created 8 November 2018 07:49:11
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    The header file still exposes a lot of implementation details via the definition of internal data structures, e.g. the *_Control structures of the API objects. They are only necessary for the application configuration. Move them to separate header files. Currently we have:

    Use

    for this new header file.

    Potential new header files are:

    • rtems/extensiondata.h
    • rtems/rtems/asrdata.h
    • rtems/rtems/barrierdata.h
    • rtems/rtems/dpmemdata.h
    • rtems/rtems/eventdata.h
    • rtems/rtems/messagedata.h
    • rtems/rtems/partdata.h
    • rtems/rtems/ratemondata.h
    • rtems/rtems/regiondata.h
    • rtems/rtems/semdata.h
    • rtems/rtems/tasksdata.h
    • rtems/rtems/timerdata.h
    Comment 1
    1. Sebastian Huber, Thu, 08 Nov 2018 07:59:33 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Thu, 08 Nov 2018 08:09:48 GMT
    2. description: modified (diff)
    Comment 3
    1. Sebastian Huber, Thu, 08 Nov 2018 08:11:57 GMT
    2. description: modified (diff)
    Comment 4
    1. Sebastian Huber, Thu, 08 Nov 2018 09:47:26 GMT
    2. description: modified (diff)
    Comment 5
    1. Sebastian Huber, Thu, 08 Nov 2018 12:19:56 GMT
    2. description: modified (diff)
    Comment 6
    1. Sebastian Huber, Thu, 08 Nov 2018 12:20:15 GMT

    In ac8025c/rtems:

    libcsupport: Add missing include Update #3598.
    Comment 7
    1. Sebastian Huber, Thu, 08 Nov 2018 12:20:23 GMT

    In 4f4ed2f0/rtems:

    rtems: Add missing include Update #3598.
    Comment 8
    1. Sebastian Huber, Fri, 09 Nov 2018 14:08:40 GMT

    In 0288536/rtems:

    bsps: Include missing header files Update #3598.
    Comment 9
    1. Sebastian Huber, Fri, 09 Nov 2018 14:08:50 GMT

    In fdd3b85/rtems:

    bsp/motorola_powerpc: Include Update #3598.
    Comment 10
    1. Sebastian Huber, Fri, 09 Nov 2018 14:09:00 GMT

    In 5841e0b/rtems:

    bsp/lpc32xx: Include missing Update #3598.
    Comment 11
    1. Sebastian Huber, Fri, 09 Nov 2018 14:09:09 GMT

    In 84aedca/rtems:

    Include missing Update #3598.
    Comment 12
    1. Sebastian Huber, Mon, 12 Nov 2018 14:37:48 GMT

    In 93fae332/rtems:

    Include missing Update #3598.
    Comment 13
    1. Sebastian Huber, Mon, 12 Nov 2018 14:37:56 GMT

    In 78bbe59/rtems:

    rtems: Move internal structures to ratemondata.h Update #3598.
    Comment 14
    1. Sebastian Huber, Mon, 12 Nov 2018 14:38:05 GMT

    In 257cf74/rtems:

    rtems: Move internal structures to asrdata.h Update #3598.
    Comment 15
    1. Sebastian Huber, Mon, 12 Nov 2018 14:38:13 GMT

    In bdd4eb8/rtems:

    rtems: Remove Modes_Control Use rtems_mode directly. This is in line with rtems_attribute and rtems_option. Update #3598.
    Comment 16
    1. Sebastian Huber, Mon, 12 Nov 2018 14:38:22 GMT

    In 395a49e1/rtems:

    rtems: Move internal structures to barrierdata.h Update #3598.
    Comment 17
    1. Sebastian Huber, Mon, 12 Nov 2018 14:38:30 GMT

    In 72a4a42/rtems:

    rtems: Move internal structures to dpmemdata.h Update #3598.
    Comment 18
    1. Sebastian Huber, Mon, 12 Nov 2018 14:38:38 GMT

    In efc227cd/rtems:

    rtems: Move internal structures to eventdata.h Update #3598.
    Comment 19
    1. Sebastian Huber, Mon, 12 Nov 2018 14:38:47 GMT

    In 257668d/rtems:

    rtems: Move internal structures to messagedata.h Update #3598.
    Comment 20
    1. Sebastian Huber, Mon, 12 Nov 2018 14:38:56 GMT

    In f00c5c6/rtems:

    rtems: Move internal structures to partdata.h Update #3598.
    Comment 21
    1. Sebastian Huber, Mon, 12 Nov 2018 14:39:04 GMT

    In e8e914b3/rtems:

    rtems: Move internal structures to regiondata.h Update #3598.
    Comment 22
    1. Sebastian Huber, Mon, 12 Nov 2018 14:39:12 GMT

    In 739df1f5/rtems:

    rtems: Move internal structures to semdata.h Update #3598.
    Comment 23
    1. Sebastian Huber, Mon, 12 Nov 2018 14:39:20 GMT

    In b7af3e44/rtems:

    rtems: Move internal structures to tasksdata.h Update #3598.
    Comment 24
    1. Sebastian Huber, Mon, 12 Nov 2018 14:39:29 GMT

    In e1b7c188/rtems:

    rtems: Move internal structures to timerdata.h Update #3598.
    Comment 25
    1. Sebastian Huber, Mon, 12 Nov 2018 14:39:37 GMT

    In 5fc855d/rtems:

    rtems: Move internal structures to extensiondata.h Update #3598.
    Comment 26
    1. Sebastian Huber, Mon, 12 Nov 2018 14:39:45 GMT

    In 742d6db/rtems:

    score: Remove empty Update #3598.
    Comment 27
    1. Sebastian Huber, Mon, 12 Nov 2018 14:39:53 GMT

    In a11b98c/rtems:

    score: Avoid include of Update #3598.
    Comment 28
    1. Sebastian Huber, Mon, 12 Nov 2018 14:40:01 GMT

    In 98c01a5/rtems:

    rtems: Avoid in API Use a real function for rtems_clock_get_uptime_seconds(). Update #3598.
    Comment 29
    1. Sebastian Huber, Mon, 12 Nov 2018 14:40:10 GMT

    In ccc6695/rtems:

    score: Introduce Separate the definitions related to watchdog ticks from the watchdog structures. Update #3598.
    Comment 30
    1. Sebastian Huber, Mon, 12 Nov 2018 14:40:18 GMT

    In 9763245/rtems:

    rtems: Remove superfluous include Update #3598.
    Comment 31
    1. Sebastian Huber, Mon, 12 Nov 2018 14:40:26 GMT

    In 805f9c26/rtems:

    score: Avoid complex include in heap.h Update #3598.
    Comment 32
    1. Sebastian Huber, Mon, 12 Nov 2018 14:40:34 GMT

    In 2fa014db/rtems:

    rtems: Avoid include of Update #3598.
    Comment 33
    1. Sebastian Huber, Mon, 12 Nov 2018 14:40:43 GMT

    In e897c7d/rtems:

    rtems: Avoid include of Update #3598.
    Comment 34
    1. Sebastian Huber, Mon, 12 Nov 2018 14:40:51 GMT

    In a6e7d5e4/rtems:

    score: Move internal structures to objectdata.h Update #3598.
    Comment 35
    1. Sebastian Huber, Mon, 12 Nov 2018 14:41:00 GMT

    In 3b69a0e2/rtems:

    rtems: Simplify includes in Update #3598.
    Comment 36
    1. Sebastian Huber, Mon, 12 Nov 2018 14:41:08 GMT

    In 356b07e6/rtems:

    score: Includes in Include implementation header files only if necessary. Update #3598.
    Comment 37
    1. Sebastian Huber, Mon, 12 Nov 2018 14:41:17 GMT

    In 963c6c2/rtems:

    score: Move internal structures to userextdata.h Update #3598.
    Comment 38
    1. Sebastian Huber, Tue, 13 Nov 2018 09:18:02 GMT

    In 9f87c45/rtems-libbsd:

    Include missing Update #3598.
    Comment 39
    1. Sebastian Huber, Wed, 14 Nov 2018 06:24:28 GMT

    In dc563556/rtems:

    Include missing Update #3598.
    Comment 40
    1. Sebastian Huber, Mon, 26 Nov 2018 11:31:39 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 5fc727f/rtems:

    score: Remove include from . Close #3598.
    Comment 41
    1. Sebastian Huber, Mon, 26 Nov 2018 11:31:42 GMT

    In eaa5ea84/rtems:

    score: Introduce Move Heap_Information_block to separate header file to hide heap implementation details from . Update #3598.
    Comment 42
    1. Sebastian Huber, Fri, 07 Dec 2018 13:33:58 GMT

    In ef23838/rtems:

    score: Avoid sbintime_t in API headers The sbintime_t is a non-POSIX type and not visible if strict standard options are selected. Move implementation details from to . Update #3598.
    Comment 43
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3599 - Remove m32c architecture port

    Link https://devel.rtems.org/ticket/3599
    Id 3599
    Reporter Sebastian Huber
    Created 8 November 2018 15:15:01
    Modified 19 November 2018 09:00:10
    Owner Sebastian Huber
    Type task
    Component arch/m32c
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3143, 3585, 3613
    Blocked by  

    Description

    The m32c architecture port is incomplete, e.g. important features such as interrupt support are missing. It never run on real hardware. The tools are out dated and unmaintained. There are no known users:

    ​https://lists.rtems.org/pipermail/users/2018-January/031991.html

    Comment 1
    1. Sebastian Huber, Thu, 08 Nov 2018 15:15:33 GMT
    2. blocking: set to 3585
    Comment 2
    1. Sebastian Huber, Mon, 12 Nov 2018 06:02:58 GMT

    In bfcf1473/rtems:

    m32c: Remove this target Update #3599.
    Comment 3
    1. Sebastian Huber, Mon, 12 Nov 2018 06:03:34 GMT

    In 1a704cd/rtems-docs:

    Remove m32c architecture port Update #3599.
    Comment 4
    1. Sebastian Huber, Mon, 12 Nov 2018 06:04:33 GMT

    In bd59c23/rtems-tools:

    Remove m32c support Update #3599.
    Comment 5
    1. Sebastian Huber, Mon, 12 Nov 2018 06:04:56 GMT

    In 25a5f24/rtems-source-builder:

    m32c: Remove this build set Update #3599.
    Comment 6
    1. Sebastian Huber, Mon, 12 Nov 2018 06:44:18 GMT
    2. blocking: changed from 3585 to 3143, 3585
    Comment 7
    1. Sebastian Huber, Wed, 14 Nov 2018 06:00:04 GMT

    In d665fdb/rtems-source-builder:

    5: Update RTEMS tools Pick up m32c removal. Update #3599.
    Comment 8
    1. Sebastian Huber, Mon, 19 Nov 2018 08:59:54 GMT
    2. blocking: changed from 3143, 3585 to 3143, 3585, 3613
    Comment 9
    1. Sebastian Huber, Mon, 19 Nov 2018 09:00:10 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3600 - Update or1k tools to use GCC master

    Link https://devel.rtems.org/ticket/3600
    Id 3600
    Reporter Joel Sherrill
    Created 9 November 2018 14:46:19
    Modified 12 December 2019 23:16:24
    Owner Joel Sherrill
    Type defect
    Component arch/or1k
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Stafford Horne emailed me to say that he just pushed the or1k gcc to the FSF repository. We can now switch from gcc 4.9.3 to a hash from the gcc master. I was testing periodically from his repository before the merge so it should be working.

    I am marking this as a blocker but expect it to be easy and quick to resolve. We don't want to release using gcc 4.9.3 for any target.

    Comment 1
    1. Joel Sherrill, Thu, 12 Dec 2019 23:16:24 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Closing. Our gcc is now at:

     ~/rtems-cron-5/tools/5/bin/or1k-rtems5-gcc --version
    or1k-rtems5-gcc (GCC) 9.2.0 20190812 (RTEMS 5, RSB 83fa79314dd87c0a8c78fd642b2cea3138be8dd6, Newlib d14714c69)
    Copyright (C) 2019 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 

    3602 - Update or1k tool chain to use the upstream GCC

    Link https://devel.rtems.org/ticket/3602
    Id 3602
    Reporter Sebastian Huber
    Created 12 November 2018 06:45:12
    Modified 14 November 2018 06:02:25
    Owner Sebastian Huber
    Type task
    Component arch/or1k
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3143
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Mon, 12 Nov 2018 06:46:03 GMT
    2. blocking: set to 3143
    Comment 2
    1. Sebastian Huber, Wed, 14 Nov 2018 06:00:10 GMT

    In c5ad16a/rtems-source-builder:

    5: Use latest Binutils for riscv This is a preparation to update or1k to use the latest GCC. Update #3602.
    Comment 3
    1. Sebastian Huber, Wed, 14 Nov 2018 06:00:16 GMT

    In 55aff90/rtems-source-builder:

    5: Use latest GCC for riscv This is a preparation to update or1k to use the latest GCC. Update #3602.
    Comment 4
    1. Sebastian Huber, Wed, 14 Nov 2018 06:00:28 GMT

    In 8241563/rtems-source-builder:

    5: Use latest Binutils and GCC for or1k Update #3602.
    Comment 5
    1. Sebastian Huber, Wed, 14 Nov 2018 06:02:25 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 28bf4ca/rtems:

    or1k: Support GCC 9 Close #3602.

    3603 - Remove support for 16-bit object identifiers

    Link https://devel.rtems.org/ticket/3603
    Id 3603
    Reporter Sebastian Huber
    Created 12 November 2018 07:49:11
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    The RTEMS_USE_16_BIT_OBJECT define is not set by an RTEMS port. Remove support for 16-bit object identifiers. If someone really wants to use RTEMS on a 16-bit target, then it is better to use self-contained objects instead of playing around with object identifier optimizations.

    Comment 1
    1. Sebastian Huber, Wed, 21 Nov 2018 07:06:49 GMT

    In 59e7209f/rtems:

    score: Remove support for RTEMS_USE_16_BIT_OBJECT The RTEMS_USE_16_BIT_OBJECT define is not set by an RTEMS port. Remove support for 16-bit object identifiers. If someone really wants to use RTEMS on a 16-bit target, then it is better to use self-contained objects instead of playing around with object identifier optimizations. Update #3603.
    Comment 2
    1. Sebastian Huber, Wed, 21 Nov 2018 07:09:12 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 92745a4/rtems-docs:

    c-user: Remove 16-bit object identifiers Close #3603.
    Comment 3
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3604 - RTL Unresolved Symbols from common section on i386/pc686 (cloned)

    Link https://devel.rtems.org/ticket/3604
    Id 3604
    Reporter Joseph Hickey
    Created 13 November 2018 06:13:24
    Modified 27 November 2018 06:12:05
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Cloned from #3527:

    By default GCC puts uninitialized global variables into a common section in the ELF file. When attempting to load the resulting ELF file at runtime using dlopen(), these global symbols are not resolved as expected.

    The RTL reports unresolved symbols, and runtime code that take the address of the global get NULL instead.

    This is reproducible using the libtests/dl01 example by adding a global variable to the module code. I will attach a patch that replicates the issue.

    Test platform is QEMU using pc686 BSP, RTEMS source version 4.11.3 (latest on 4.11 git branch as of this writing)

    Comment 1
    1. Chris Johns, Tue, 13 Nov 2018 06:14:16 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to accepted
    Comment 2
    1. Chris Johns, Thu, 22 Nov 2018 02:17:39 GMT

    In 803eac9/rtems:

    libdl: Manage the allocation of common uninitialised variables. The use of separate text and data results in uninitialised variables being placed in the common section. There is no section in ELF for the common variables so the loader needs to create the section and allocate the variables in that section. This patch does that. The patch adds a second pass over the symbols. The issue can also be seen as a section 65522 error. Updates #3604
    Comment 3
    1. Chris Johns, Tue, 27 Nov 2018 06:12:05 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    3605 - RTL Allows Unloading a Module other Modules Depend Upon (cloned)

    Link https://devel.rtems.org/ticket/3605
    Id 3605
    Reporter Kevin Gordon
    Created 13 November 2018 06:18:07
    Modified 12 December 2019 18:19:17
    Owner  
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity major
    Keywords RTL dlopen dlcose
    Cc  
    Blocking  
    Blocked by  

    Description

    Cloned from #3195:

    Consider the following example using ELF .o files from compiled source files module-0.c and module-1.c from ticket #3194:

    module-0.o is loaded using dlopen() with no code or data dependencies.
    module-1.o is loaded using dlopen() with both code and data dependencies on module-0 which are resolved by RTL.

    The RTL function dlcose() returns no error when module-0 is unloaded, when it should return an error and not unload module-0. This becomes quite dangerous because a subsequent call to module1Function1() in the currently-loaded module-1.o, which accesses shared_resource_0[ ] and calls module0Function0(), will result in an unexpected trap on qemu or the call succeeding with the correct return value on hardware when it should not.

    The erroneous successful unload() of module-0 aside, it appears as though the resources are not actually deleted and I believe this ticket is related to tickets #3192 and #3194.

    Architecture is sparc-leon3 using both the RTEMS 4.11.1 public release and rtems master @f043b9bd3bf25626fb1a311dd7fa041eacc68adc with rtems-source-builder @55f2d69e9b67cde23d61375fa34ef5b0f04a985d.

    Execution environments are qemu-system-sparc and LEON3 UT700 hardware.

    Comment 1
    1. Chris Johns, Thu, 22 Nov 2018 02:17:31 GMT

    In 03139d5b/rtems:

    libdl: Add object file dependencies to track references Tracking references lets us manage when an object file can be unloaded. If an object file has references to it, it cannot be unloaded. Modules that depend on each other cannot be unloaded. Updates #3605
    Comment 2
    1. Chris Johns, Thu, 12 Dec 2019 17:08:23 GMT

    Kevin, is this fixed? It would be nice if we can close this ticket.

    Comment 3
    1. Chris Johns, Thu, 12 Dec 2019 18:19:17 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    The email bounced. I will close this.


    3609 - Update Spike Version in RSB (RISC-V simulator)

    Link https://devel.rtems.org/ticket/3609
    Id 3609
    Reporter Joel Sherrill
    Created 15 November 2018 23:15:54
    Modified 1 April 2020 23:21:54
    Owner Hesham Almatary
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The spike version in the RSB does not run the test executables. Per Hesham, we should be using a newer version from git.

    This is one of the two alternative simulators to run RISC-V executables. At the moment, neither Spike nor Qemu are usable for the RISC-V as present in the RSB.

    Comment 1
    1. Hesham Almatary, Fri, 16 Nov 2018 09:43:42 GMT

    RSB should already build an updated version of Spike as of this commit:​https://github.com/RTEMS/rtems-source-builder/commit/693e6b518d1710793096cdb11f806d9e511a8972

    Do you have any issues running RTEMS with it?

    Comment 2
    1. Sebastian Huber, Thu, 19 Dec 2019 11:19:28 GMT

    Is this issue fixed?

    Comment 3
    1. Joel Sherrill, Thu, 19 Dec 2019 14:05:20 GMT

    The RSB appears to be updated based on this build list result from my build this week.

    ​https://lists.rtems.org/pipermail/build/2019-December/009507.html

    But... none of the RISC-V BSPs ran correctly on Spike so there is something wrong still:

    ​https://lists.rtems.org/pipermail/build/2019-December/009509.html

    Could be Spike but more easily the rtems-tools configuration for the execution of the simulator. Does it work for you Hesham?

    Comment 4
    1. Joel Sherrill, Wed, 01 Apr 2020 23:21:54 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    I updated the RSB to have a functional Spike with a git version. Results have been posted to build@


    3612 - RTL unresolved compaction does not update string indexes after removing a string

    Link https://devel.rtems.org/ticket/3612
    Id 3612
    Reporter Chris Johns
    Created 19 November 2018 04:21:17
    Modified 27 November 2018 06:13:13
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The RTL unresolved compaction does not update the string indexes when compacting.

    Comment 1
    1. Chris Johns, Tue, 27 Nov 2018 06:13:13 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3620 - CommitTicketUpdater does not process commits in order

    Link https://devel.rtems.org/ticket/3620
    Id 3620
    Reporter Sebastian Huber
    Created 26 November 2018 11:39:26
    Modified 14 December 2018 06:06:38
    Owner Amar Takhar
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The new CommitTicketUpdater? does not process commits in order. For example see:

    ​https://devel.rtems.org/ticket/3598#comment:40 ​https://devel.rtems.org/ticket/3598#comment:41

    Compare with Git commit order:

    ​https://git.rtems.org/rtems/log/?id=eaa5ea84eaf1b3dab72d7a7a6578f0dc59e55396&qt=range&q=1947449a5d6f01a44ccc61eda3e78ef7e06da952..5fc727fe77a632f9df38161a8474007dab020608

    Comment 1
    1. Amar Takhar, Wed, 05 Dec 2018 03:33:42 GMT

    Hmm, this is the order that git-rev gives it to the script. I'll play around and try to figure out.

    Since there are only two commits I can't tell if it's simply reversed I'd need at least 4 multiple times to see if I can simply reverse the order to fix this.

    Comment 2
    1. Chris Johns, Wed, 05 Dec 2018 03:39:39 GMT

    Why not create a test repo as a personal repo and add the hooks for testing?

    Comment 3
    1. Sebastian Huber, Fri, 07 Dec 2018 13:36:46 GMT

    I pushed at least seven commits today in one rush:

    ​https://devel.rtems.org/ticket/3621

    They show up in reverse order.

    Comment 4
    1. Amar Takhar, Fri, 07 Dec 2018 13:38:34 GMT

    Okay great thanks all I need to do is reverse the order of the commits fed into the updater. I'll do that shortly.

    Comment 5
    1. Amar Takhar, Fri, 07 Dec 2018 13:41:28 GMT

    Replying to Chris Johns:

    Why not create a test repo as a personal repo and add the hooks for testing?

    Because we use quite a few scripts that do unique things for RTEMS infrastructure. It would be a lot of work to get the same environment running elsewhere for a check that can be done the next time 4 commits are pushed at the same time. Outside of aesthetics the tickets are still being updated. I'm not sure where the offending area is but now I think I know we'll see.

    Comment 6
    1. Amar Takhar, Fri, 07 Dec 2018 13:45:39 GMT

    Since this is never been a problem before I didn't notice that git rev-list by default shows reverse chronological order. I added --reverse to the commandline hopefully that fixes this issue.

    Please let me know if this fixes the issue.

    Comment 7
    1. Sebastian Huber, Fri, 14 Dec 2018 06:06:26 GMT
    2. milestone: changed from Indefinite to 5.1

    Thanks, it works now:

    ​https://devel.rtems.org/ticket/3621#comment:11

    Comment 8
    1. Sebastian Huber, Fri, 14 Dec 2018 06:06:38 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3621 - Statically initialize object information structures

    Link https://devel.rtems.org/ticket/3621
    Id 3621
    Reporter Sebastian Huber
    Created 26 November 2018 12:50:51
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    Statically initialize the object information structures to make the configuration easier to review and simplify the debugging.

    The workspace size estimate generated by looks currently like this:

     const rtems_configuration_table Configuration = { ( ( ( (ssize_t) ((((((1 +
    0) != 0 ? 1 : 0) * ((Objects_Maximum) ((1 + 0) & ~0x80000000U))) *
    (sizeof(Configuration_Thread_control))) != 0 ? 1 : 0) * ((((((1 + 0) != 0 ? 1 :
    0) * ((Objects_Maximum) ((1 + 0) & ~0x80000000U))) *
    (sizeof(Configuration_Thread_control)) + (2 * sizeof(uintptr_t) +
    (sizeof(Heap_Protection_block_begin) + sizeof(Heap_Protection_block_end)))) +
    ((((sizeof(Heap_Block)) + (8) - 1) - ((sizeof(Heap_Block)) + (8) - 1) % (8))) -
    1) - (((((1 + 0) != 0 ? 1 : 0) * ((Objects_Maximum) ((1 + 0) & ~0x80000000U)))
    * (sizeof(Configuration_Thread_control)) + (2 * sizeof(uintptr_t) +
    (sizeof(Heap_Protection_block_begin) + sizeof(Heap_Protection_block_end)))) +
    ((((sizeof(Heap_Block)) + (8) - 1) - ((sizeof(Heap_Block)) + (8) - 1) % (8)))

    [more than 500 similar lines]

    1) - (((sizeof(Configuration_Initial_Extensions) /
    sizeof((Configuration_Initial_Extensions)[0])) *
    sizeof(User_extensions_Switch_control) + (2 * sizeof(uintptr_t) +
    (sizeof(Heap_Protection_block_begin) + sizeof(Heap_Protection_block_end)))) +
    ((((sizeof(Heap_Block)) + (8) - 1) - ((sizeof(Heap_Block)) + (8) - 1) % (8))) -
    1) % ((((sizeof(Heap_Block)) + (8) - 1) - ((sizeof(Heap_Block)) + (8) - 1) %
    (8)))))) + 0 + 0 + (0 * 1024) + ((((2 * sizeof(uintptr_t) +
    (sizeof(Heap_Protection_block_begin) + sizeof(Heap_Protection_block_end)))) +
    (8) - 1) - (((2 * sizeof(uintptr_t) + (sizeof(Heap_Protection_block_begin) +
    sizeof(Heap_Protection_block_end)))) + (8) - 1) % (8)) ),

    The object controls reside on the heap even for fixed object count configuration. Using a statically allocated array makes it easier to find the objects during debugging.

    Comment 1
    1. Chris Johns, Tue, 27 Nov 2018 00:53:30 GMT

    Replying to Sebastian Huber:

    The object controls reside on the heap even for fixed object count configuration. Using a statically allocated array makes it easier to find the objects during debugging.

    It is not clear me to what the requirements are these change are being based on? Is there some overriding push for everything to be static tables every where.

    Static tables for initialisation do solve some issues such as audit-able configuration control but are there other use cases where this may not be a good fit. I cannot tell. For example statically inflexible kernel initialisation and libdl do not sit well together. The demands on the kernel configuration from the loadable code can vary and does and if you consider libdl as a means to produce "golden images" having the ability to vary the configuration is important. I have built systems where the bootloader loads the kernel configuration data and then loads the application. Can this still be done?

    Comment 2
    1. Sebastian Huber, Tue, 27 Nov 2018 06:00:08 GMT

    You can still do whatever you want after the system is initialized. I just want to get rid of the workspace allocations used during the system startup and instead use storage allocated by the linker.

    Comment 3
    1. Chris Johns, Tue, 27 Nov 2018 06:05:25 GMT

    Great and thank you.

    Comment 4
    1. Sebastian Huber, Fri, 07 Dec 2018 13:33:28 GMT

    In f70079c/rtems:

    score: Remove Objects_Information::the_api Remove Objects_Information::the_class. This information is already contained in Objects_Information::maximum_id. Update #3621.
    Comment 5
    1. Sebastian Huber, Fri, 07 Dec 2018 13:33:31 GMT

    In 1c2d178/rtems:

    score: Remove Objects_Information::maximum This information is already present in Objects_Information::maximum_id. Add and use _Objects_Get_maximum_index(). Update #3621.
    Comment 6
    1. Sebastian Huber, Fri, 07 Dec 2018 13:33:35 GMT

    In 3899bc1a/rtems:

    score: Optimize object lookup Use the maximum ID for the ID to object translation. Using the maximum ID gets rid of an additional load from the object information in _Objects_Get(). In addition, object lookups fail for every ID in case the object information is cleared to zero. This makes it a bit more robust during system startup (see new tests in spconfig02). The local table no longer needs a NULL pointer entry at array index zero. Adjust all the object iteration loops accordingly. Remove Objects_Information::minimum_id since it contains only redundant information. Add _Objects_Get_minimum_id() to get the minimum ID. Update #3621.
    Comment 7
    1. Sebastian Huber, Fri, 07 Dec 2018 13:33:38 GMT

    In 359a3a3/rtems:

    score: Rename Objects_Information::allocation_size Rename Objects_Information::allocation_size in Objects_Information::objects_per_block. Adjust integer types in _Objects_Shrink_information() and _Objects_Free(). Update #3621.
    Comment 8
    1. Sebastian Huber, Fri, 07 Dec 2018 13:33:41 GMT

    In 0da9d80/rtems:

    score: Rename Objects_Information::size Rename Objects_Information::size to Objects_Information::object_size. Change its type from size_t to uint16_t and move it to reduce the size of Objects_Information. Update #3621.
    Comment 9
    1. Sebastian Huber, Fri, 07 Dec 2018 13:33:44 GMT

    In 9c9c6a9/rtems:

    score: Remove Objects_Information::is_string Use Objects_Information::name_length to store this information. Update #3621.
    Comment 10
    1. Sebastian Huber, Fri, 07 Dec 2018 13:33:48 GMT

    In d6e3473/rtems:

    score: Remove dead code Update #3621.
    Comment 11
    1. Sebastian Huber, Fri, 14 Dec 2018 06:04:01 GMT

    In 8b0e752/rtems:

    score: Remove Objects_Information::auto_extend Use Objects_Information::objects_per_block to provide this information. Add and use _Objects_Is_auto_extend(). Update #3621.
    Comment 12
    1. Sebastian Huber, Fri, 14 Dec 2018 06:04:05 GMT

    In 0f5b2c09/rtems:

    rtems: Use object information to get config max Use functions instead of macros. Add missing rtems_configuration_get_maximum_*() functions. Update #3621.
    Comment 13
    1. Sebastian Huber, Fri, 14 Dec 2018 06:04:08 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 21275b58/rtems:

    score: Static Objects_Information initialization Statically allocate the objects information together with the initial set of objects either via . Provide default object informations with zero objects via librtemscpu.a. This greatly simplifies the workspace size estimate. RTEMS applications which do not use the unlimited objects option are easier to debug since all objects reside now in statically allocated objects of the right types. Close #3621.
    Comment 14
    1. Sebastian Huber, Thu, 02 Jan 2020 08:49:12 GMT

    In a320aedd/rtems:

    score: Fix objects node initialization The objects node is statically initialized to one. Clear the node field before it is set. Update #3621.
    Comment 15
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3622 - Remove cache routines working with a processor set

    Link https://devel.rtems.org/ticket/3622
    Id 3622
    Reporter Sebastian Huber
    Created 26 November 2018 12:57:27
    Modified 28 November 2018 13:54:28
    Owner Sebastian Huber
    Type task
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The following cache manager API functions are exotic, complex, very hard to use correctly, not used in the RTEMS code base, and apparently unused by applications (​https://lists.rtems.org/pipermail/users/2018-November/032764.html). Remove these functions

    /**
    * @brief Flushes multiple data cache lines for a set of processors
    *
    * Dirty cache lines covering the area are transferred to memory.
    * Depending on the cache implementation this may mark the lines as invalid.
    *
    * This operation should not be called from interrupt context.
    *
    * @param[in] addr The start address of the area to flush.
    * @param[in] size The size in bytes of the area to flush.
    * @param[in] setsize The size of the processor set.
    * @param[in] set The target processor set.
    */
    void rtems_cache_flush_multiple_data_lines_processor_set(
    const void *addr,
    size_t size,
    const size_t setsize,
    const cpu_set_t *set
    );
    /**
    * @brief Invalidates multiple data cache lines for a set of processors
    *
    * The cache lines covering the area are marked as invalid. A later read
    * access in the area will load the data from memory.
    *
    * In case the area is not aligned on cache line boundaries, then this
    * operation may destroy unrelated data.
    *
    * This operation should not be called from interrupt context.
    *
    * @param[in] addr The start address of the area to invalidate.
    * @param[in] size The size in bytes of the area to invalidate.
    * @param[in] setsize The size of the processor set.
    * @param[in] set The target processor set.
    */
    void rtems_cache_invalidate_multiple_data_lines_processor_set(
    const void *addr,
    size_t size,
    const size_t setsize,
    const cpu_set_t *set
    );
    /**
    * @brief Flushes the entire data cache for a set of processors
    *
    * This operation should not be called from interrupt context.
    *
    * @see rtems_cache_flush_multiple_data_lines().
    *
    * @param[in] setsize The size of the processor set.
    * @param[in] set The target processor set.
    */
    void rtems_cache_flush_entire_data_processor_set(
    const size_t setsize,
    const cpu_set_t *set
    );
    /**
    * @brief Invalidates the entire cache for a set of processors
    *
    * This function is responsible for performing a data cache
    * invalidate. It invalidates the entire cache for a set of
    * processors.
    *
    * This operation should not be called from interrupt context.
    *
    * @param[in] setsize The size of the processor set.
    * @param[in] set The target processor set.
    */
    void rtems_cache_invalidate_entire_data_processor_set(
    const size_t setsize,
    const cpu_set_t *set
    );
    Comment 1
    1. Sebastian Huber, Tue, 27 Nov 2018 07:09:13 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 0a75a4aa/rtems:

    Remove rtems_cache_*_processor_set() functions The following rtems_cache_*_processor_set() cache manager API functions are exotic, complex, very hard to use correctly, not used in the RTEMS code base, and apparently unused by applications. Close #3622.
    Comment 2
    1. Sebastian Huber, Wed, 28 Nov 2018 13:54:28 GMT

    In 5bf0c1a/rtems:

    bsps/sparc: Fix SMP build Update #3622.

    3624 - MSYS2 builds appear to ignore tcfg file

    Link https://devel.rtems.org/ticket/3624
    Id 3624
    Reporter Joel Sherrill
    Created 26 November 2018 23:44:53
    Modified 11 November 2019 14:04:43
    Owner  
    Type defect
    Component build
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Building m68k/mrm332 on Linux and MSYS2 to compare results. Builds with all tests on Linux. Multiple build failures on MSYS2. Some appear to be because on MSYS2, tests are being build which are marked as exclude in the .tcfg file. For example, ​https://git.rtems.org/rtems/tree/bsps/m68k/mrm332/config/mrm332-testsuite.tcfg#n11 says that fsdosfsname01 should be excluded but it is being built as shown below:

    m68k-rtems5-gcc  -mcpu=cpu32 -Os -g -fomit-frame-pointer -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -B./../../lib/libbsp/m68k/mrm332 -B/home/jrs007/rtems-work/rtems/bsps/m68k/mrm332/start -specs bsp_specs -qrtems -L./../../cpukit -L/home/jrs007/rtems-work/rtems/bsps/m68k/shared/start -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar  -o fsdosfsname01.exe fsdosfsname01/fsdosfsname01-init.o support/fsdosfsname01-ramdisk_support.o ./../../lib/libbsp/m68k/mrm332/librtemsbsp.a ./../../cpukit/librtemscpu.a
    c:/msys64/home/jrs007/rtems-work/tools/5/bin/../lib/gcc/m68k-rtems5/7.3.0/../../../../m68k-rtems5/bin/ld.exe: fsdosfsname01.exe section `.text' will not fit in region `rom'
    c:/msys64/home/jrs007/rtems-work/tools/5/bin/../lib/gcc/m68k-rtems5/7.3.0/../../../../m68k-rtems5/bin/ld.exe: region `rom' overflowed by 874128 bytes
    collect2.exe: error: ld returned 1 exit status
    make[5]: *** [Makefile:1910: fsdosfsname01.exe] Error 1
    Comment 1
    1. Chris Johns, Mon, 11 Nov 2019 03:53:47 GMT
    2. component: changed from admin to build
    Comment 2
    1. Sebastian Huber, Mon, 11 Nov 2019 14:04:43 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    This will be fixed by the new build system, see #3818.


    3625 - RTL Allows Unloading a Module other Modules Depend Upon (cloned)

    Link https://devel.rtems.org/ticket/3625
    Id 3625
    Reporter Kevin Gordon
    Created 27 November 2018 06:15:09
    Modified 27 November 2018 06:15:37
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity major
    Keywords RTL dlopen dlcose
    Cc  
    Blocking  
    Blocked by  

    Description

    Cloned from #3195:

    Consider the following example using ELF .o files from compiled source files module-0.c and module-1.c from ticket #3194:

    module-0.o is loaded using dlopen() with no code or data dependencies.
    module-1.o is loaded using dlopen() with both code and data dependencies on module-0 which are resolved by RTL.

    The RTL function dlcose() returns no error when module-0 is unloaded, when it should return an error and not unload module-0. This becomes quite dangerous because a subsequent call to module1Function1() in the currently-loaded module-1.o, which accesses shared_resource_0[ ] and calls module0Function0(), will result in an unexpected trap on qemu or the call succeeding with the correct return value on hardware when it should not.

    The erroneous successful unload() of module-0 aside, it appears as though the resources are not actually deleted and I believe this ticket is related to tickets #3192 and #3194.

    Architecture is sparc-leon3 using both the RTEMS 4.11.1 public release and rtems master @f043b9bd3bf25626fb1a311dd7fa041eacc68adc with rtems-source-builder @55f2d69e9b67cde23d61375fa34ef5b0f04a985d.

    Execution environments are qemu-system-sparc and LEON3 UT700 hardware.

    Comment 1
    1. Chris Johns, Tue, 27 Nov 2018 06:15:37 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    This has been fixed on master for RTEMS 5.


    3626 - sigtimedwait() needed when POSIX is disabled

    Link https://devel.rtems.org/ticket/3626
    Id 3626
    Reporter Joel Sherrill
    Created 27 November 2018 14:45:01
    Modified 30 November 2018 14:37:09
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    When POSIX is disabled, psxmsgq01 does not link. Should we enable sigtimedwait() when POSIX is disabled or disable this test?

    /data/home/joel/rtems-work/tools/5/bin/../lib/gcc/powerpc-rtems5/7.3.0/../../../../powerpc-rtems5/bin/ld: psxmsgq01/psxmsgq01-init.o: in function `wait_for_signal':
    /home/joel/rtems-work/rtems-testing/rtems/build-powerpc-ss555-rtems/powerpc-rtems5/c/ss555/testsuites/psxtests/../../../../../../rtems/c/src/../../testsuites/psxtests/psxmsgq01/init.c:932: undefined reference to `sigtimedwait'
    Comment 1
    1. Sebastian Huber, Wed, 28 Nov 2018 06:15:05 GMT

    I would not enable signals by default. The signal implementation in RTEMS is quite bad.

    #2263 #2607 #2690 #2716

    The test should be only enabled if the POSIX API is enabled.

    Comment 2
    1. Joel Sherrill, Thu, 29 Nov 2018 22:35:32 GMT

    This is weirder than it seems. Only these BSPs fail to build:

    m68k-mcf5206elite m68k-mcf52235 m68k-mrm332 moxie-moxiesim powerpc-haleakala powerpc-mpc8260ads powerpc-qemuppc powerpc-qoriq_e6500_64 powerpc-ss555

    I have built every BSP and those fail. Why only those?

    And I don't disagree about no signals with POSIX is disabled. But you can't disable the entirety of psxmsgq01. It tests a lot more than just mq_notify().

    Comment 3
    1. Joel Sherrill, Thu, 29 Nov 2018 23:40:03 GMT

    Looks like not enough is disabled based on POSIX API being unavailable. I have ss555 building and will build all overnight to see if that resolves it. ss555 does have a gcc option for no-inline set. I wonder if the others do also. Maybe a weird optimization difference leaving the method in

    Comment 4
    1. Joel Sherrill, Fri, 30 Nov 2018 14:37:09 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In e54a266e/rtems:

    psxmsgq01/init.c: Disable signal usage when POSIX disabled closes #3626.

    3629 - Add RSB reporting section to the documentation.

    Link https://devel.rtems.org/ticket/3629
    Id 3629
    Reporter Chris Johns
    Created 30 November 2018 00:39:06
    Modified 5 April 2020 20:56:51
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc chris@…
    Blocking  
    Blocked by  

    Description

    As reported in this email ​https://lists.rtems.org/pipermail/users/2018-November/032802.html:

    "I could imagine that the GCC 6.3.0 of the TASTE VM isn't suitable to build RTEMS toolchain with RTEMS source builder & kernel masters but I can't find information which of all those config files of RSB I have to use for a successful build (targets: ARM, x86-64). This is pretty frustrating and very disappointing. There are so many variables which are not exactly documented, at least for the current version of RSB/kernel."

    there is no documented way to get a configuration report of an RSB configuration. The documentation needs to be updated to show how this can be done. For example:

    $ ./source-builder/sb-reports 5/rtems-sparc
    $ less 5-rtems-sparc.txt
    Comment 1
    1. Gedare Bloom, Sun, 05 Apr 2020 20:56:51 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In cbdfde0/rtems-docs:

    user/rsb: describe how to create configuration reports Closes #3629.

    3630 - Build of rtems-tools fails with i686-w64-mingw32

    Link https://devel.rtems.org/ticket/3630
    Id 3630
    Reporter Markus Bernd Moessner
    Created 2 December 2018 16:01:32
    Modified 28 April 2020 01:45:51
    Owner Chris Johns
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Hi,

    I am following

    ​https://docs.rtems.org/branches/master/user/hosts/windows.html

    to build a Windows Host toolchain on Linux Mint 19. However, the build of rtems-tools fails with: "unknown host: i686-w64-mingw32".

    I can track the issue down to the function "check_options" in the wscript. The function expects a host called "mingw32" or "x86_64-w64-mingw32". My naive solution would be to simply extend the list with "i686-w64-mingw32", but I've just started with RTEMS so I might have choosen a wrong path in an earlier step.

    Attachments:

    1 Markus Bernd Moessner, Sun, 02 Dec 2018 16:05:51 GMT
      attach: set to rsb-report-rtems-tools-6db01e577fed1dc88018106b81dd531f2ecc1fd0-1.txt
     
    2 Markus Bernd Moessner, Sun, 02 Dec 2018 16:06:58 GMT
      attach: set to 0001-Allow-build-with-i686-w64-mingw32.patch
     
    Comment 1
    1. Markus Bernd Moessner, Mon, 03 Dec 2018 09:13:10 GMT
    2. component: changed from admin to arch/arm
    Comment 2
    1. Markus Bernd Moessner, Mon, 03 Dec 2018 19:15:43 GMT

    Build works fine with a 64bit toolchain. The reason why I was using i686 was the example given in

    ​https://docs.rtems.org/branches/master/rsb/cross-canadian-cross.html#cross-building

    Comment 3
    1. Chris Johns, Tue, 04 Dec 2018 03:23:36 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to accepted
    4. milestone: set to 5.1

    Thanks. I will update the documentation and will close the ticket when I commit the change.

    Comment 4
    1. Markus Bernd Moessner, Thu, 06 Dec 2018 21:00:30 GMT

    Dear Chris,

    sorry for getting back on this, but the question that I have is: is it intendend / expected that the build fails with the i686 toolchain? If not - then i'll look into it and submit a patch. If it is expected - well yeah please update the documentation.

    Thanks & Regards Markus

    Comment 5
    1. Chris Johns, Sun, 09 Dec 2018 23:41:50 GMT

    Replying to Markus Bernd Moessner:

    sorry for getting back on this, but the question that I have is: is it intendend / expected that the build fails with the i686 toolchain?

    No it is not. It is a simple matter of there being limited time and many possible combinations.

    If not - then i'll look into it and submit a patch. If it is expected - well yeah please update the documentation.

    Updates are most welcome. Thank you.

    Comment 6
    1. Markus Bernd Moessner, Mon, 10 Dec 2018 16:57:22 GMT

    Ok, thank you for taking the time to clarify this.

    Comment 7
    1. kaidoho, Tue, 28 Apr 2020 01:45:51 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In a1a05c7/rtems-tools:

    Allow build with i686-w64-mingw32 Closes #3630

    3636 - Add rtems_scheduler_get_maximum_priority()

    Link https://devel.rtems.org/ticket/3636
    Id 3636
    Reporter Sebastian Huber
    Created 6 December 2018 08:55:46
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    The maximum task priority depends on the scheduler instance. It is a configuration parameter. Add a function to get it at runtime.

    /**
    * @brief Gets the maximum task priority of the specified scheduler instance.
    *
    * @param[in] scheduler_id Identifier of the scheduler instance.
    * @param[out] priority Pointer to a task priority value.
    *
    * @retval RTEMS_SUCCESSFUL Successful operation.
    * @retval RTEMS_INVALID_ADDRESS The @a priority parameter is @c NULL.
    * @retval RTEMS_INVALID_ID Invalid scheduler instance identifier.
    */
    rtems_status_code rtems_scheduler_get_maximum_priority(
    rtems_id scheduler_id,
    rtems_task_priority *priority
    );
    Comment 1
    1. Sebastian Huber, Fri, 07 Dec 2018 13:33:51 GMT

    In 7ee6437/rtems:

    rtems: Add rtems_scheduler_get_maximum_priority() Update #3636.
    Comment 2
    1. Sebastian Huber, Mon, 10 Dec 2018 08:20:21 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 16f33fd/rtems-docs:

    c-user: rtems_scheduler_get_maximum_priority() Close #3636.
    Comment 3
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3637 - Fix rtems_task_restart() argument type

    Link https://devel.rtems.org/ticket/3637
    Id 3637
    Reporter Sebastian Huber
    Created 6 December 2018 09:47:22
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type defect
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity major
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    The argument type must be rtems_task_argument in rtems_task_restart() similar to rtems_task_start(). This is a severe issue on 64-bit targets since it prevents to pass pointer values to the task.

    Comment 1
    1. Sebastian Huber, Thu, 06 Dec 2018 10:03:19 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 4e46ba8/rtems:

    rtems: Fix rtems_task_restart() argument type Close #3637.
    Comment 2
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3649 - Error with IRC anouncing in examples-v2 commits.

    Link https://devel.rtems.org/ticket/3649
    Id 3649
    Reporter Joel Sherrill
    Created 9 December 2018 15:42:37
    Modified 13 February 2019 20:02:31
    Owner Amar Takhar
    Type infra
    Component admin
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords git, hooks
    Cc  
    Blocking  
    Blocked by  

    Description

    remote: 1: mail vc@rtems.org
    remote: 2: update github
    remote: 4: IRC
    remote: usage:
    remote: 5: Buildbot
    To ssh://joel@dispatch.rtems.org/data/git/examples-v2.git
     ced6542..276a025  am -> master
    Comment 1
    1. Chris Johns, Sun, 09 Dec 2018 23:35:56 GMT

    I suggest comparing the post commit hook in the hooks directory in the exmaples-v2 repo on dispatch.rtems.org with another working repo to see if something needs to be updated.

    Comment 2
    1. Amar Takhar, Wed, 13 Feb 2019 20:02:19 GMT
    2. status: changed from assigned to accepted

    This should have been fixed when I redid all the hooks I have not heard any complaints since then.

    Comment 3
    1. Amar Takhar, Wed, 13 Feb 2019 20:02:31 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    Re-open if it's still an issue.


    3651 - Sphinx 1.8 PDF (latex) on FreeBSD does not build

    Link https://devel.rtems.org/ticket/3651
    Id 3651
    Reporter Chris Johns
    Created 9 December 2018 23:09:32
    Modified 12 December 2019 16:46:31
    Owner  
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity critical
    Keywords sphinx latex pdf
    Cc  
    Blocking  
    Blocked by  

    Description

    The build fails with pdfindex complaining on an __Undefined Control Sequence__:

    ! Undefined control sequence.
    \spxpagem
    l.88 ...ecture}, \hyperindexformat{\spxpagem}{183}

    The Tex is:

    \item[{Architecture\index{Architecture@\spxentry{Architecture}|spxpagem}\phantomsection\label{\detokenize{glossary/index:term-architecture`] \leavevmode 

    And the IDX entry from makeindex is:

    \item \spxentry {Architecture}, \hyperindexformat{\spxpagem}{183} 
    Comment 1
    1. Chris Johns, Tue, 08 Jan 2019 23:24:50 GMT

    Sphinx provides a Makefile in the build directory and this uses latexmk to create the PDF. I have seen posts from sphinx developers stating the Makefile should be used when building a PDF.

    Sphinx 1.8 and later references \spxpagem which is provided in a support file called sphinx.xdy. The Makefile references this file in the xindy options:

    export XINDYOPTS = -L english -C utf8  -M sphinx.xdy 

    The issue on FreeBSD with texlive-full-20150521 is the lack of the xindy command:

    $ type xindy
    xindy: not found 

    And latexmk expects it to exist.

    Comment 2
    1. Chris Johns, Thu, 12 Dec 2019 16:46:31 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    3664 - RSB config parsing slow on python3

    Link https://devel.rtems.org/ticket/3664
    Id 3664
    Reporter Chris Johns
    Created 18 December 2018 00:52:25
    Modified 25 December 2018 01:15:50
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords RSB python3
    Cc  
    Blocking  
    Blocked by  

    Description

    The execute support on python3 is slow and this slows the config file parsing.

    Comment 1
    1. Chris Johns, Tue, 25 Dec 2018 01:15:50 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In c2d2338/rtems-source-builder:

    sb/execute: Port the rtemstoolkit performance fixes for python3 Close #3664.

    3665 - Add low level event recording infrastructure

    Link https://devel.rtems.org/ticket/3665
    Id 3665
    Reporter Sebastian Huber
    Created 19 December 2018 07:01:36
    Modified 19 December 2019 09:26:09
    Owner Sebastian Huber
    Type enhancement
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add low level event recording infrastructure for system and user defined events. The infrastructure should be able to record high frequency events such as

    • SMP lock acquire/release,
    • interrupt entry/exit,
    • thread switches,
    • UMA zone allocate/free,
    • Ethernet packet input/output, etc.

    It should allow post-mortem analysis in fatal error handlers, e.g. the last events should be in the record buffer, the newest event overwrites the oldest event. It should be possible to detect record buffer overflows for consumers that expect a continuous stream of events, e.g. to display the system state in real-time.

    The framework should support high-end SMP machines (more than 1GHz processor frequency, more than four processors).

    The existing capture engine tries to solve this problem, but its performance is not good enough for high-end production systems. The main issues are the variable-size buffers and the use of SMP locks for synchronization. To fix this, the API would change significantly.

    Add a new API instead. The implementation should use per-processor data structures and no atomic read-modify-write operations. It is pretty much a per-processor ring buffer for record events.

    Use the CPU counter to get the time of events. Combine it with periodic uptime events to synchronize it with CLOCK_REALTIME.

    Here is an example of the

    /**
    * @brief Produces a record item.
    *
    * @param event The record event without a time stamp for the item.
    * @param data The record data for the item.
    */
    void rtems_record_produce( rtems_record_event event, rtems_record_data data );

    function PowerPC machine code generated by GCC:

    00000000 :
    0: 7d 00 00 a6 mfmsr r8
    4: 7c 00 01 46 wrteei 0
    8: 7d 2e 82 a6 mfspr r9,526
    c: 7d 50 42 a6 mfsprg r10,0
    10: 81 4a 02 b4 lwz r10,692(r10)
    14: 55 29 50 2a rlwinm r9,r9,10,0,21
    18: 7d 23 1b 78 or r3,r9,r3
    1c: 81 2a 00 00 lwz r9,0(r10)
    20: 80 ca 00 08 lwz r6,8(r10)
    24: 38 e9 00 01 addi r7,r9,1
    28: 7d 29 30 38 and r9,r9,r6
    2c: 55 29 18 38 rlwinm r9,r9,3,0,28
    30: 7d 2a 4a 14 add r9,r10,r9
    34: 90 69 00 48 stw r3,72(r9)
    38: 90 89 00 4c stw r4,76(r9)
    3c: 7c 20 04 ac lwsync
    40: 90 ea 00 00 stw r7,0(r10)
    44: 7d 00 01 06 wrtee r8
    48: 4e 80 00 20 blr

    Just 19 instructions, no branches, no stack frame, no atomic-read-modify-write, just a light weight synchronization to ensure that the consumer reads not half finished items.

    Comment 1
    1. Sebastian Huber, Tue, 29 Jan 2019 12:57:00 GMT

    In dca6184/rtems:

    Add low level event recording support Add low level event recording infrastructure for system and user defined events. The infrastructure is able to record high frequency events such as SMP lock acquire/release, interrupt entry/exit, thread switches, UMA zone allocate/free, and Ethernet packet input/output, etc. It allows post-mortem analysis in fatal error handlers, e.g. the last events are in the record buffer, the newest event overwrites the oldest event. It is possible to detect record buffer overflows for consumers that expect a continuous stream of events, e.g. to display the system state in real-time. The implementation supports high-end SMP machines (more than 1GHz processor frequency, more than four processors). Add a new API instead. The implementation uses per-processor data structures and no atomic read-modify-write operations. It is uses per-processor ring buffers to record the events. The CPU counter is used to get the time of events. It is combined with periodic uptime events to synchronize it with CLOCK_REALTIME. The existing capture engine tries to solve this problem also, but its performance is not good enough for high-end production systems. The main issues are the variable-size buffers and the use of SMP locks for synchronization. To fix this, the API would change significantly. Update #3665.
    Comment 2
    1. Sebastian Huber, Wed, 30 Jan 2019 10:32:21 GMT

    In 03cdd5ea/rtems:

    record: Add enum value for each event Update #3665.
    Comment 3
    1. Sebastian Huber, Fri, 01 Feb 2019 08:52:23 GMT

    In d06b195/rtems-docs:

    c-user: Add event recording configuration Update #3665.
    Comment 4
    1. Sebastian Huber, Fri, 01 Feb 2019 08:52:25 GMT

    In 21c4a44/rtems-docs:

    user: Add basic event recording documentation Update #3665.
    Comment 5
    1. Sebastian Huber, Tue, 12 Mar 2019 13:03:10 GMT

    In d91951fb/rtems:

    record: Rename internal per-CPU events Update #3665.
    Comment 6
    1. Sebastian Huber, Tue, 12 Mar 2019 13:03:14 GMT

    In ebb8c28e/rtems:

    record: Add system call entry/exit events This corresponds to the Linux syscall_entry_* and syscall_exit_* events. Update #3665.
    Comment 7
    1. Sebastian Huber, Tue, 12 Mar 2019 13:03:17 GMT

    In 01a5ced5/rtems:

    record: Add more system events Update #3665.
    Comment 8
    1. Sebastian Huber, Tue, 20 Aug 2019 20:51:11 GMT

    In f9dce02/rtems-tools:

    record: New program Update #3665.
    Comment 9
    1. Sebastian Huber, Tue, 27 Aug 2019 06:47:34 GMT

    In a8af7a14/rtems:

    record: Fix thread names on 64-bit targets Also fixes the thread names on signed char targets. Update #3665.
    Comment 10
    1. Sebastian Huber, Tue, 27 Aug 2019 06:47:37 GMT

    In e273e7a9/rtems:

    record: Add data size to client This is necessary to get the thread names properly on 32-bit and 64-bit targets. Update #3665.
    Comment 11
    1. Sebastian Huber, Tue, 27 Aug 2019 06:52:40 GMT

    In 577f986/rtems-tools:

    record: Move per-CPU variables to separate context Update #3665.
    Comment 12
    1. Sebastian Huber, Tue, 27 Aug 2019 06:52:42 GMT

    In 91d0d1d/rtems-tools:

    record: Simplify packet context setup Update #3665.
    Comment 13
    1. Sebastian Huber, Tue, 27 Aug 2019 06:52:44 GMT

    In e488c98/rtems-tools:

    record: Move base context to client context Update #3665.
    Comment 14
    1. Sebastian Huber, Tue, 27 Aug 2019 06:52:46 GMT

    In 6c4b770/rtems-tools:

    record: Add CPU to idle thread names Update #3665.
    Comment 15
    1. Sebastian Huber, Tue, 27 Aug 2019 06:52:48 GMT

    In 3f45f38/rtems-tools:

    record: Add data size to client This is necessary to get the thread names properly on 32-bit and 64-bit targets. Update #3665.
    Comment 16
    1. Sebastian Huber, Tue, 27 Aug 2019 06:52:50 GMT

    In 3c42656/rtems-tools:

    record: Support thread names on 32-bit targets Update #3665.
    Comment 17
    1. Sebastian Huber, Wed, 28 Aug 2019 14:02:53 GMT

    In a2684c2b/rtems:

    record: Use BSS section instead of per-CPU data The .rtemsrwset section is used for the per-CPU data. This section has loadable content. Place the ring buffers in the BSS section to avoid large executable image sizes. Not using the per-CPU data makes it possible to initialize the record support earlier. Update #3665.
    Comment 18
    1. Sebastian Huber, Wed, 28 Aug 2019 14:02:56 GMT

    In 3eb8d783/rtems:

    record: Introduce This helps to get rid of the dependency in . Update #3665.
    Comment 19
    1. Sebastian Huber, Wed, 28 Aug 2019 14:03:00 GMT

    In 956a2ef/rtems:

    record: Add variants for critical sections Update #3665.
    Comment 20
    1. Sebastian Huber, Thu, 29 Aug 2019 14:02:42 GMT

    In 58bd67b/rtems:

    record: Add more system events Reduce the system dependencies to allow tracing of very low level functions, for example the interrupt disable/enable. Introduce general purpose RTEMS_RECORD_CALLER and RTEMS_RECORD_LINE events. Update #3665.
    Comment 21
    1. Sebastian Huber, Thu, 29 Aug 2019 14:05:45 GMT

    In b1abc7d/rtems-tools:

    record: Synchronize with RTEMS Update #3665.
    Comment 22
    1. Sebastian Huber, Fri, 30 Aug 2019 07:01:18 GMT

    In d78082c/rtems:

    record: Introduce _Record_Drain() This allows its use in crash dump procedures. Update #3665.
    Comment 23
    1. Sebastian Huber, Fri, 30 Aug 2019 07:01:22 GMT

    In 11f196d6/rtems:

    record: Simplify configuration Update #3665.
    Comment 24
    1. Sebastian Huber, Fri, 30 Aug 2019 07:01:27 GMT

    In 1e18f64/rtems:

    record: Initialize records earlier The _Record_Initialize() function depends only initialized read-only data. Call it as the first initialization step to allow tracing of the complete system initialization. Update #3665.
    Comment 25
    1. Sebastian Huber, Fri, 30 Aug 2019 09:49:35 GMT

    In 8ace7ead/rtems:

    record: Add system events Add system events to identify the target system. Add system events to transfer blocks of memory and register sets. Update #3665.
    Comment 26
    1. Sebastian Huber, Fri, 30 Aug 2019 09:53:09 GMT

    In 67f7638/rtems-tools:

    record: Synchronize with RTEMS Update #3665.
    Comment 27
    1. Sebastian Huber, Fri, 30 Aug 2019 13:03:47 GMT

    In 1c72ad7/rtems:

    record: Add system events Add system events for memory allocation/free. Update #3665.
    Comment 28
    1. Sebastian Huber, Fri, 30 Aug 2019 17:50:29 GMT

    In f127341/rtems-tools:

    record: Synchronize with RTEMS Update #3665.
    Comment 29
    1. Sebastian Huber, Mon, 02 Sep 2019 05:56:58 GMT

    In e41e9961/rtems:

    record: Add system events Update #3665.
    Comment 30
    1. Sebastian Huber, Mon, 02 Sep 2019 06:14:50 GMT

    In 7cb3a0f/rtems-tools:

    record: Synchronize with RTEMS Update #3665.
    Comment 31
    1. Sebastian Huber, Tue, 03 Sep 2019 13:03:20 GMT

    In e0ac299/rtems-tools:

    record: Convert to C++ Formatted with: clang-format -style=Chromium -i trace/record/record-main-lttng.cc Update #3665.
    Comment 32
    1. Sebastian Huber, Tue, 03 Sep 2019 13:03:22 GMT

    In a124bdb/rtems-tools:

    record: Add Client base class Update #3665.
    Comment 33
    1. Sebastian Huber, Wed, 04 Sep 2019 11:48:07 GMT

    In fb5b75a/rtems-tools:

    record: Use exceptions Update #3665.
    Comment 34
    1. Sebastian Huber, Wed, 04 Sep 2019 11:48:10 GMT

    In ce308fa/rtems-tools:

    record: Only create necessary stream files Rename the files to stream_* so that they appear after the metadata file. This makes it easier to open a new trace in Trace Compass. Update #3665.
    Comment 35
    1. Sebastian Huber, Wed, 04 Sep 2019 11:48:12 GMT

    In ff942d5/rtems-tools:

    record: Simplify CopyThreadName?() Update #3665.
    Comment 36
    1. Sebastian Huber, Wed, 04 Sep 2019 11:48:15 GMT

    In 0df7b2f/rtems-tools:

    record: Add support for interrupt handlers Update #3665.
    Comment 37
    1. Sebastian Huber, Wed, 04 Sep 2019 11:48:17 GMT

    In 58edee9/rtems-tools:

    record: Simplify content and packet size Update #3665.
    Comment 38
    1. Sebastian Huber, Wed, 04 Sep 2019 12:03:39 GMT

    In 876ace8/rtems-tools:

    record: Simplify command line options Update #3665.
    Comment 39
    1. Sebastian Huber, Wed, 04 Sep 2019 12:43:10 GMT

    In 71929ce/rtems-tools:

    record: Add limit option Update #3665.
    Comment 40
    1. Sebastian Huber, Thu, 05 Sep 2019 08:50:08 GMT

    In 0b12f00/rtems-tools:

    record: Clean up metadata Update #3665.
    Comment 41
    1. Sebastian Huber, Thu, 05 Sep 2019 08:50:26 GMT

    In 07829ca/rtems-tools:

    record: Use C++ header files and namespace std Update #3665.
    Comment 42
    1. Sebastian Huber, Thu, 05 Sep 2019 08:50:28 GMT

    In f8f91d6/rtems-tools:

    record: Add generic record events Update #3665.
    Comment 43
    1. Sebastian Huber, Mon, 09 Sep 2019 05:05:59 GMT

    In c331bdc/rtems:

    record: Allow tracing of ISR disable/enable Directly use the CPU port API in boot_card() to allow tracing of the higher level interrupt disable/enable routines, e.g. _ISR_Local_disable() and _ISR_Local_enable(). Currently, there is no configuration option to enable this. Below is a patch. It may be used to investigate some nasty low level bugs in the system. Update #3665. diff --git a/cpukit/include/rtems/score/isrlevel.h b/cpukit/include/rtems/score/isrlevel.h index c42451d010..46d361ddc2 100644 --- a/cpukit/include/rtems/score/isrlevel.h +++ b/cpukit/include/rtems/score/isrlevel.h @@ -40,6 +40,10 @@ extern "C" {
    */
    typedef uint32_t ISR_Level;
    +uint32_t rtems_record_interrupt_disable( void ); + +void rtems_record_interrupt_enable( uint32_t level ); +
    /__ __
    @brief Disables interrupts on this processor. * @@ -56,8 +60,7 @@ typedef uint32_t ISR_Level;
    */
    `#define _ISR_Local_disable( _level ) \ `
    do { \
    _CPU_ISR_Disable( _level ); \ RTEMS_COMPILER_MEMORY_BARRIER(); \ + _level = rtems_record_interrupt_disable(); \
    } while (0)
    /__ __
    @@ -72,10 +75,7 @@ typedef uint32_t ISR_Level; _ISR_Local_disable(). */
    `#define _ISR_Local_enable( _level ) \ `
    do { \ RTEMS_COMPILER_MEMORY_BARRIER(); \ _CPU_ISR_Enable( _level ); \ } while (0) + rtems_record_interrupt_enable( _level )
    /__ __
    @brief Temporarily enables interrupts on this processor. @@ -98,9 +98,8 @@ typedef uint32_t ISR_Level;
    */
    `#define _ISR_Local_flash( _level ) \ `
    do { \
    RTEMS_COMPILER_MEMORY_BARRIER(); \ _CPU_ISR_Flash( _level ); \ RTEMS_COMPILER_MEMORY_BARRIER(); \ + rtems_record_interrupt_enable( _level ); \ + _level = rtems_record_interrupt_disable(); \
    } while (0)
    /
    Comment 44
    1. Sebastian Huber, Tue, 01 Oct 2019 07:55:23 GMT

    In c1eb577/rtems:

    libtests/record01: Fix test failure Update #3665.
    Comment 45
    1. Sebastian Huber, Wed, 02 Oct 2019 04:38:31 GMT

    In a314544a/rtems:

    record: Add wrappers for malloc() functions Introduce new library librtemsrecordwrap.a which contains wrappers for operating system functions which produce entry/exit events. The wrappers can be selected during link time via the GNU ld --wrap option. Update #3665.
    Comment 46
    1. Sebastian Huber, Thu, 19 Dec 2019 09:26:09 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    All the basic functionality is integrated. New features/bugs should use new tickets.


    3666 - Add support for C++17 std::aligned_alloc

    Link https://devel.rtems.org/ticket/3666
    Id 3666
    Reporter Sebastian Huber
    Created 19 December 2018 07:56:55
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    In C++17 there is a std::aligned_alloc():

    ​https://en.cppreference.com/w/cpp/memory/c/aligned_alloc

    Unfortunately, it doesn't work with RTEMS currently:

    ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85904

    Provide aligned_alloc() and memalign() (as a strong alias to aligned_alloo()) by RTEMS.

    Comment 1
    1. Sebastian Huber, Fri, 21 Dec 2018 06:56:55 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 2158621/rtems:

    Add aligned_alloc() and memalign() Ensure that the C++17 aligned new operator works. Close #3666.
    Comment 2
    1. Sebastian Huber, Thu, 10 Jan 2019 10:35:55 GMT

    In 8eaf136d/rtems:

    memalign: Add missing attributes to fix warning Update #3666.
    Comment 3
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3667 - Support data cache disable on ARMv7-AR

    Link https://devel.rtems.org/ticket/3667
    Id 3667
    Reporter Sebastian Huber
    Created 21 December 2018 09:32:08
    Modified 10 January 2019 07:12:37
    Owner Sebastian Huber
    Type enhancement
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Fri, 21 Dec 2018 09:33:17 GMT

    In ba85655/rtems:

    ARM_CACHE_L1_CPU_SUPPORT_PROVIDES_RANGE_FUNCTIONS Remove this superfluous define. Update #3667.
    Comment 2
    1. Sebastian Huber, Fri, 21 Dec 2018 09:33:21 GMT

    In a6f70e1/rtems:

    bsps: Remove superfluous comments in cacheimpl.h Remove superfluous blank lines. Update #3667.
    Comment 3
    1. Sebastian Huber, Fri, 21 Dec 2018 09:33:24 GMT

    In 5e0ab02/rtems:

    bsps: Update cache manager documentation Update #3667.
    Comment 4
    1. Sebastian Huber, Fri, 21 Dec 2018 09:33:28 GMT

    In b0c2d48/rtems:

    bsps: Add CPU_CACHE_SUPPORT_PROVIDES_DISABLE_DATA Update #3667.
    Comment 5
    1. Sebastian Huber, Fri, 21 Dec 2018 09:33:31 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 41a557bc/rtems:

    bsps/arm: Add ARMv7-AR disable data cache Close #3667.
    Comment 6
    1. Thomas Dörfler, Thu, 10 Jan 2019 07:12:34 GMT

    In 0abe47f/rtems:

    bsps/arm: Fix typo in disable cache for ARMv7-AR Update #3667.
    Comment 7
    1. Sebastian Huber, Thu, 10 Jan 2019 07:12:37 GMT

    In e7d623e7/rtems:

    bsps/arm: Conditional ARMv7-AR data cache disable Update #3667. Close #3674.

    3668 - Commit message in examples-v2 and libbsd didn't trigger a ticket update.

    Link https://devel.rtems.org/ticket/3668
    Id 3668
    Reporter Christian Mauderer
    Created 21 December 2018 15:22:00
    Modified 2 April 2020 20:11:17
    Owner Amar Takhar
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    On 19.12.2018 I pushed a commit to the rtems-libbsd with a keyword that should have updated a ticket. But the ticket didn't pick up the commit:

    Commit: ​https://git.rtems.org/rtems-libbsd/commit/?id=91566dda7f52b5eba04df159770b4797ba652f20

    Ticket: ​https://devel.rtems.org/ticket/3569

    The same message format worked from rtems-tools and rtems-source-builder. Did I something wrong?

    Comment 1
    1. Sebastian Huber, Mon, 07 Jan 2019 07:46:27 GMT
    2. summary: changed from Commit message in Libbsd didn't trigger a ticket update. to Commit message in examples-v2 and libbsd didn't trigger a ticket update.
    Comment 2
    1. Amar Takhar, Thu, 02 Apr 2020 20:11:17 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    4. milestone: set to 5.1

    This was fixed a long time ago the issue was in the update scripts not updating multiple commits in one push only the first one was being handled.


    3669 - rtems-docs.git does not build with Sphinx 1.8.2 and 1.8.3

    Link https://devel.rtems.org/ticket/3669
    Id 3669
    Reporter Chris Johns
    Created 24 December 2018 22:46:14
    Modified 6 February 2019 21:30:22
    Owner Amar Takhar
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The docs do not build with Sphinx 1.8. Recent posts indicate some changes to support unicode indexes via xindy have caused this and the solution being discussed is to use the generate Makefile ...

    ​https://github.com/rtfd/readthedocs.org/issues/4454

    The need to use the Makefile is debatable however what it contains is important as it defines what needs to happen.

    This recent issue can be seen in the Tex generated file for the User Manual (user.tex). It contains:

    \item[{Waf\index{Waf@\spxentry{Waf}|spxpagem}\phantomsection\label{\detokenize{glossary/index:term-waf`] \leavevmode
    Waf build system. For more information see \sphinxurl{http://www.waf.io/}

    Our current build uses pdflatex directly and there is an error as spxpagem is not defined.

    If you inspect a version 1.8 generated Makefile the command latexmk is used. This wraps the PDF generation so the correct number of passes are performed. Using this tool should be considered.

    The Makefile contains:

    export XINDYOPTS = -L english -C utf8  -M sphinx.xdy 

    The sphinx.xdy contains the needed spxpagem. I can only conclude sphinx needs to be built with xindy because the reference is always generated.

    The problem for building FreeBSD is xindy is not an available command.

    Comment 1
    1. Amar Takhar, Tue, 25 Dec 2018 00:11:19 GMT
    2. owner: set to Amar Takhar
    3. status: changed from new to accepted

    I'll sort this out, I've been aware this change was going to happen for a while now but since FreeBSD ports only has Sphinx 1.6.5 I haven't hit it yet.

    Comment 2
    1. Joel Sherrill, Wed, 26 Dec 2018 18:52:50 GMT

    FWIW I tried two CentOS 7 computers with Sphinx 1.8. Neither gets anywhere close to this point. Neither even creates a Makefile in the build tree. They both fail immediately with this:

    joel@devel rtems-docs]$ ./waf
    Waf: Entering directory `/home/joel/rtems-work/rtems-docs/build'
    Waf: Leaving directory `/home/joel/rtems-work/rtems-docs/build'
    invalid number of source/target for bld(posted=True, target=[/home/joel/rtems-work/rtems-docs/build/user/latex/capt-of.sty, /home/joel/rtems-work/rtems-docs/build/user/latex/eqparbox.sty, /home/joel/rtems-work/rtems-docs/build/user/latex/environ.sty, /home/joel/rtems-work/rtems-docs/build/user/latex/ifplatform.sty, /home/joel/rtems-work/rtems-docs/build/user/latex/trimspaces.sty, /home/joel/rtems-work/rtems-docs/build/user/latex/slantsc.sty, /home/joel/rtems-work/rtems-docs/build/user/latex/upquote.sty, /home/joel/rtems-work/rtems-docs/build/user/latex/rtemsextrafonts.sty], idx=1, meths=['process_subst', 'process_rule', 'process_source'], source=['../common/latex/capt-of.sty', '../common/latex/eqparbox.sty', '../common/latex/environ.sty', '../common/latex/ifplatform.sty', '../common/latex/trimspaces.sty', '../common/latex/slantsc.sty', '../common/latex/upquote.sty'], path=/home/joel/rtems-work/rtems-docs/user, is_copy=True, features=['subst']) in /home/joel/rtems-work/rtems-docs/user 

    Both have a texlive install from around 20 Nov 2018. There is nothing much in the build/ directory after running waf configure and waf.

    [joel@devel rtems-docs]$ find build -type f
    build/c4che/build.config.py
    build/c4che/_cache.py
    build/config.log
    build/.lock-waf_linux2_build 
    Comment 3
    1. Sebastian Huber, Thu, 03 Jan 2019 11:37:22 GMT

    On openSUSE 15.0 I use a sphinx 1.8.1 with Python 3 and it works. I don't have a xindy tool installed.

    Comment 4
    1. Sebastian Huber, Thu, 03 Jan 2019 11:51:00 GMT

    I updated to sphinx 1.8.2 and 1.8.3. On both versions I experience the reported issue, e.g.

    cd build/user/latex
    pdflatex -shell-escape user.tex
    ...
    [182] [183]
    ! Undefined control sequence.
     \spxpagem
    l.88 ...ecture}, \hyperindexformat{\spxpagem}{181}
    ? 
    Comment 5
    1. Sebastian Huber, Thu, 03 Jan 2019 11:51:21 GMT
    2. summary: changed from rtems-docs.git does not build with Sphinx 1.8 to rtems-docs.git does not build with Sphinx 1.8.2 and 1.8.3
    Comment 6
    1. Chris Johns, Mon, 07 Jan 2019 05:31:20 GMT

    I suspect all future versions will behave the same way.

    Comment 7
    1. Chris Johns, Tue, 05 Feb 2019 09:35:41 GMT

    For FreeBSD we need to wait until a texlive update. This bug is tracking the progress:

    ​https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211997

    Comment 8
    1. Chris Johns, Wed, 06 Feb 2019 02:59:17 GMT

    With the help of the sphinx project I have resolved the issue. The issue in github is:

    ​https://github.com/sphinx-doc/sphinx/issues/6021

    I will be working on a patch to sort this out.

    Comment 9
    1. Chris Johns, Wed, 06 Feb 2019 21:30:22 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In a3b0a40/rtems-docs:

    Fix building with Sphinx 1.8 and later. Provide the pytnon.ist file for makeindex. Add support for xelatex building so we can switch if we want too. Closes #3669

    3670 - examples-v2 uses deprecated or obsolete RTEMS interfaces

    Link https://devel.rtems.org/ticket/3670
    Id 3670
    Reporter Chris Johns
    Created 26 December 2018 00:39:19
    Modified 7 January 2019 07:45:58
    Owner joel@…
    Type defect
    Component examples
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The examples need to be change to use what ever is the newer method of doing something.

    ../../filesystem/fat_ramdisk/init.c:46:3: warning: 'rtems_blkdev_generic_open' is deprecated [-Wdeprecated-declarations]
    open_entry: rtems_blkdev_generic_open,
    ^~~~~~~~~~
    In file included from /opt/work/chris/rtems/kernel/5/arm-rtems5/xilinx_zynq_zedboard/lib/include/rtems/ramdisk.h:17:0,
    from ../../filesystem/fat_ramdisk/init.c:16:
    /opt/work/chris/rtems/kernel/5/arm-rtems5/xilinx_zynq_zedboard/lib/include/rtems/blkdev.h:408:1: note: declared here
    rtems_blkdev_generic_open(
    ^~~~~~~~~~~~~~~~~~~~~~~~~
    ../../filesystem/fat_ramdisk/init.c:47:3: warning: 'rtems_blkdev_generic_close' is deprecated [-Wdeprecated-declarations]
    close_entry: rtems_blkdev_generic_close,
    ^~~~~~~~~~~
    In file included from ../../ticker/low_ticker/init.c:88:0:
    /opt/work/chris/rtems/kernel/5/arm-rtems5/xilinx_zynq_zedboard/lib/include/rtems/confdefs.h:3276:4: warning: #warning "The CONFIGURE_TERMIOS_DISABLED configuration option is obsolete since RTEMS 5.1" [-Wcpp]
    #warning "The CONFIGURE_TERMIOS_DISABLED configuration option is obsolete since RTEMS 5.1"
    ^~~~~~~
    Comment 1
    1. Sebastian Huber, Fri, 04 Jan 2019 06:55:37 GMT

    Should the examples work with all RTEMS versions or just RTEMS 5?

    Comment 2
    1. Chris Johns, Mon, 07 Jan 2019 05:29:58 GMT

    Replying to Sebastian Huber:

    Should the examples work with all RTEMS versions or just RTEMS 5?

    I suppose the examples should be equivalent to what a user sees so in this case they should build with RTEMS 5 and have no errors or warnings. The examples are captured as part of a release which means there is a history and the changes needed for RTEMS.

    If I had an application that needed to work with 4.11 and 5 I would detect the version and conditionally handle the changes in the build system and code.

    I am OK with them building for RTEMS 5.

    Comment 3
    1. Sebastian Huber, Mon, 07 Jan 2019 07:45:58 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    I fixed the issues. Trac didn't update the ticket.


    3672 - No i386 BSP can link all tests after cache manager changes

    Link https://devel.rtems.org/ticket/3672
    Id 3672
    Reporter Joel Sherrill
    Created 10 January 2019 00:22:19
    Modified 29 January 2019 08:03:10
    Owner  
    Type defect
    Component arch/i386
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    /data/home/joel/rtems-work/tools/5/bin/../lib/gcc/i386-rtems5/7.4.0/../../../../i386-rtems5/bin/ld: ./../../lib/libbsp/i386/pc386/librtemsbsp.a(cache.o): in function `rtems_cache_invalidate_entire_instruction':
    /home/joel/rtems-work/rtems-testing/rtems/build-i386-pc486-rtems/i386-rtems5/c/pc486/lib/libbsp/i386/pc386/../../../../../../../../rtems/c/src/lib/libbsp/i386/pc386/../../../../../../bsps/i386/shared/cache/../../../shared/cache/cacheimpl.h:350: undefined reference to `_CPU_cache_invalidate_entire_instruction'

    Comment 1
    1. Sebastian Huber, Thu, 10 Jan 2019 06:39:04 GMT
    2. owner: Sebastian Huber deleted
    3. status: changed from assigned to new

    I think this is due to this typo fix here:

    ​https://git.rtems.org/rtems/commit/?id=750e79519a8061fecbf23ea7c96a7767b1099267

    Could someone with i386 knowledge please resolve this ticket.

    Comment 2
    1. Sebastian Huber, Tue, 29 Jan 2019 08:03:10 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Fixed by [12dfe5dcb1412db47c51d4736551d81a7c77d064/rtems].


    3673 - xilinx_zynq_a9_qemu - fails to link psxconfig01

    Link https://devel.rtems.org/ticket/3673
    Id 3673
    Reporter Joel Sherrill
    Created 10 January 2019 00:24:33
    Modified 10 January 2019 07:12:41
    Owner Sebastian Huber
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This is with POSIX disabled.

    /home/joel/rtems-work/rtems-testing/rtems/build-arm-xilinx_zynq_a9_qemu-rtems/arm-rtems5/c/xilinx_zynq_a9_qemu/testsuites/psxtests/../../../../../../rtems/c/src/../../testsuites/psxtests/psxconfig01/init.c:499: undefined reference to `timer_create'
    collect2: error: ld returned 1 exit status

    Comment 1
    1. Joel Sherrill, Thu, 10 Jan 2019 00:27:19 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Thu, 10 Jan 2019 07:06:34 GMT

    Interesting, this is due to the -O0 optimization level. For the erc32 the empty loop is optimized away and there is no reference.

    Comment 3
    1. Sebastian Huber, Thu, 10 Jan 2019 07:12:41 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 3a5c71d/rtems:

    psxconfig01: Fix pre-processor conditions Do not rely on compiler optimizations to throw away empty loops. Close #3673.

    3674 - Raspberry Pi Fails to Build

    Link https://devel.rtems.org/ticket/3674
    Id 3674
    Reporter Joel Sherrill
    Created 10 January 2019 00:25:36
    Modified 10 January 2019 07:12:37
    Owner Sebastian Huber
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/cache/cache-v7ar-disable-data.S: Assembler messages:
    ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/cache/cache-v7ar-disable-data.S:47: Error: selected processor does not support `dmb' in ARM mode
    ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/cache/cache-v7ar-disable-data.S:53: Error: selected processor does not support `isb' in ARM mode
    ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/cache/cache-v7ar-disable-data.S:77: Error: selected processor does not support `isb' in ARM mode
    ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/cache/cache-v7ar-disable-data.S:85: Error: invalid constant (3ff) after fixup
    ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/cache/cache-v7ar-disable-data.S:92: Error: invalid constant (7fff) after fixup
    gmake[6]: __* [cache-v7ar-disable-data.o] Error 1 __

    Comment 1
    1. Sebastian Huber, Thu, 10 Jan 2019 07:12:37 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In e7d623e7/rtems:

    bsps/arm: Conditional ARMv7-AR data cache disable Update #3667. Close #3674.

    3675 - RSB: Change default prefix to OS prefix + "rtems" + $rtems_version

    Link https://devel.rtems.org/ticket/3675
    Id 3675
    Reporter Sebastian Huber
    Created 17 January 2019 10:34:17
    Modified 18 February 2019 13:42:25
    Owner Sebastian Huber
    Type enhancement
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The user manual contains this about prefixes:

    "A further reason not to use the standard prefix is to allow more than one version of RTEMS to exist on your host machine at a time. The autoconf and automake tools required by RTEMS are not versioned and vary between the various versions of RTEMS. If you use a single prefix such as the standard prefix there is a chance parts from a package of different versions may interact. This should not happen but it can.

    For POSIX or Unix hosts, the RTEMS Project uses /opt/rtems as it’s standard prefix. We view this prefix as a production level path, and we prefer to place development versions under a different prefix away from the production versions. Under this top level prefix we place the various versions we need for development. For example the version 4.11.0 prefix would be /opt/rtems/4.11.0. If an update called 4.11.1 is released the prefix would be /opt/rtems/4.11.1. These are recommendations and the choice of what you use is entirely yours. You may decide to have a single path for all RTEMS 4.11 releases of /opt/rtems/4.11."

    The default prefix selected by the RSB should take this into account. Use OS prefix + "rtems" + $rtems_version, e.g. on Linux for RTEMS 5: "/opt/rtems/5".

    Comment 1
    1. Sebastian Huber, Thu, 17 Jan 2019 10:34:30 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to accepted
    Comment 2
    1. Sebastian Huber, Tue, 22 Jan 2019 08:57:44 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In d523d4c/rtems-source-builder:

    sb: Change default prefix Use OS prefix + "rtems" + $rtems_version as the default prefix to automatically separate different RTEMS versions. Close #3675.
    Comment 3
    1. Sebastian Huber, Mon, 18 Feb 2019 13:42:25 GMT

    In eae5454/rtems-docs:

    user: Rework Prefixes section Rename it to "Choose an Installation Prefix". Update #3675.

    3677 - ARM BSP contains ARM code in THUMB only build

    Link https://devel.rtems.org/ticket/3677
    Id 3677
    Reporter Chris Johns
    Created 21 January 2019 00:41:14
    Modified 29 January 2019 08:04:26
    Owner  
    Type defect
    Component tool/gcc
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The xilinx_zynq_a9_qemu BSP contains a memcpy that is ARM mode code and not THUMB. This can be seen with hello.exe and vlan01.exe in the libbsd examples.

    The script run with the command that follows shows there is a single ARM function in the executable. The python script is:

    from __future__ import print_function
    import sys
    for line in sys.stdin:
    ls = line.split()
    if len(ls) == 8 and ls[0][-1] == ':' and ls[3] == 'FUNC':
    addr = int(ls[1], 16)
    if addr & 1 == 0:
    print(ls[7])

    Command with output:

    $ arm-rtems5-readelf -a `find . -name hello.exe` | python ./arm-thumb.py
    memcpy

    The presence of this single function makes me wonder why and if something is wrong in the building of the memcpy function.
    Examination with rtems-exeinfo shows the code is built by GNU AS from the file memcpy-armv7a.S while other asm files are not generating ARM code. The section of the output from:

    $ rtems-exeinfo -a `find . -name hello.exe` 

    is:

     GNU AS 2.31.1: 14 objects
    | arm_exc_interrupt.S
    | armv4-exception-default.S
    | bpabi.S
    | bpabi.S
    | bsp-start-memcpy.S
    | cpu_asm.S
    | lib1funcs.S
    | lib1funcs.S
    | lib1funcs.S
    | memchr.S
    | memcpy-armv7a.S
    | start.S
    | strcmp-armv7.S
    | strlen-armv7.S

    GNU LD is correctly managing the interworking and the code runs however is this behavior expected and understood?
    Note, the existence of this code breaks libdl's loading of dhcpcd.c as section .rel.text.dhcpcd_handle_hwaddr contains a R_ARM_THM_JUMP24 relocation record which requires a veneer in large memory application as well as bl to blx support. This support could be added but I am not currently in favor of having this support for something that should not happen.

    Comment 1
    1. Chris Johns, Mon, 21 Jan 2019 00:44:30 GMT

    Hmmmm .... ​https://github.com/RTEMS/sourceware-mirror-newlib-cygwin/blob/master/newlib/libc/machine/arm/memcpy-armv7a.S#L47

    Comment 2
    1. Sebastian Huber, Mon, 21 Jan 2019 06:17:19 GMT

    The interworking support is mandatory in ARM EABI. The memcpy() code is from ARM, I guess they know what they are doing.

    Comment 3
    1. Sebastian Huber, Tue, 29 Jan 2019 08:04:26 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    3678 - Add RISC-V BSP with support for the grlib

    Link https://devel.rtems.org/ticket/3678
    Id 3678
    Reporter Sebastian Huber
    Created 22 January 2019 10:18:53
    Modified 13 December 2019 19:17:33
    Owner Jiri Gaisler
    Type project
    Component arch/riscv
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Tue, 22 Jan 2019 11:53:23 GMT

    In 31720925/rtems:

    grlib: Move header files Update #3678.
    Comment 2
    1. Sebastian Huber, Tue, 22 Jan 2019 11:53:26 GMT

    In 7eb606d3/rtems:

    grlib: Move source files Update #3678.
    Comment 3
    1. Jiri Gaisler, Tue, 22 Jan 2019 11:53:29 GMT

    In 411c297/rtems:

    grlib: make apbuart driver independent of bsp Update #3678.
    Comment 4
    1. Jiri Gaisler, Tue, 22 Jan 2019 11:53:33 GMT

    In 5981c8ca/rtems:

    grlib: use rtems_interrupt_handler_install() Update #3678.
    Comment 5
    1. Jiri Gaisler, Tue, 22 Jan 2019 11:53:36 GMT

    In 9b2b389/rtems:

    grlib: use cpu-independent routines for uncached access Update #3678.
    Comment 6
    1. Jiri Gaisler, Tue, 22 Jan 2019 11:53:39 GMT

    In c1dcd6af/rtems:

    grlib: make memory coherency cpu-independent Update #3678.
    Comment 7
    1. Jiri Gaisler, Tue, 22 Jan 2019 11:53:43 GMT

    In d3d4e77/rtems:

    riscv: add griscv bsp Update #3678.
    Comment 8
    1. Sebastian Huber, Tue, 22 Jan 2019 11:59:09 GMT

    In 5973f92/rtems-docs:

    user: Stub documentation for griscv BSP Update #3678.
    Comment 9
    1. Joel Sherrill, Fri, 13 Dec 2019 15:22:53 GMT

    Jiri.. can this ticket be closed or are there more activities pending? We are trying to close tickets to clear way for a release.

    Thanks.

    Comment 10
    1. Jiri Gaisler, Fri, 13 Dec 2019 19:17:33 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    RISC-V grlib support merged and functioning well. Documentation somewhat lacking but ticket can be closed.


    3682 - Add BSP for Xilinx Zynq UltraScale+ MPSoC platform

    Link https://devel.rtems.org/ticket/3682
    Id 3682
    Reporter Sebastian Huber
    Created 23 January 2019 08:30:54
    Modified 19 December 2019 08:05:20
    Owner Sebastian Huber
    Type project
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The goal is to add RTEMS support for the Cortex-A53 processors in AArch32 mode. There are currently no plans to support the Cortex-R5 or the AArch64 mode.

    Comment 1
    1. Nils Hölscher, Tue, 26 Mar 2019 09:26:36 GMT

    Hi,

    I am interested in realizing this Project during GSoC 2019. Hoping to find interested mentors.

    Best, Nils Hölscher

    Comment 2
    1. Sebastian Huber, Wed, 27 Mar 2019 06:36:53 GMT

    This project is probably too complex for a GSoC project. I am not available as a mentor.

    Comment 3
    1. Jeff Kubascik, Thu, 11 Apr 2019 05:29:34 GMT

    In b0c420b9/rtems:

    bsp/zynq-uart: Remove zynq_uart_instances from header This variable is BSP specific and should be removed from the driver header file. Update #3682.
    Comment 4
    1. Jeff Kubascik, Thu, 11 Apr 2019 05:29:38 GMT

    In b004430/rtems:

    bsp/zynq-uart: Move Zynq UART driver to shared directory This driver will be shared with the xilinx-zynqmp BSP. Update #3682.
    Comment 5
    1. Jeff Kubascik, Thu, 11 Apr 2019 05:29:42 GMT

    In 677d5167/rtems:

    bsp/xilinx-zynqmp: Stub out Xilinx MPSoC BSP Source files were copied from xilinx-zynq. Update #3682.
    Comment 6
    1. Jeff Kubascik, Thu, 11 Apr 2019 05:29:46 GMT

    In 77f9a1b/rtems:

    bsp/xilinx-zynqmp: Implement Ultra96 target Modifications to get xilinx-zynqmp BSP working on an Ultra96 board. Update #3682.
    Comment 7
    1. Sebastian Huber, Thu, 19 Dec 2019 08:05:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In c9f5e20/rtems-docs:

    user: Mention xilinx-zynqmp BSP Close #3682.

    3683 - Git clone via HTTPS does not give much interactive feedback

    Link https://devel.rtems.org/ticket/3683
    Id 3683
    Reporter Sebastian Huber
    Created 28 January 2019 12:19:27
    Modified 12 December 2019 16:56:24
    Owner  
    Type infra
    Component admin
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    A Git clone via HTTPS does not give much interactive feedback. This could result in users thinking that a network issue exists and let them abort the command.

    git clone https://git.rtems.org/rtems-libbsd
    Cloning into 'rtems-libbsd'...
    Checking out files: 100% (5159/5159), done.

    vs.

    git clone git://git.rtems.org/rtems-libbsd.git
    Cloning into 'rtems-libbsd'...
    remote: Counting objects: 34566, done.
    remote: Compressing objects: 100% (8700/8700), done.
    remote: Total 34566 (delta 24457), reused 34566 (delta 24457)
    Receiving objects: 100% (34566/34566), 30.33 MiB | 1.34 MiB/s, done.
    Resolving deltas: 100% (24457/24457), done.
    Checking out files: 100% (5159/5159), done.
    Comment 1
    1. Sebastian Huber, Mon, 28 Jan 2019 12:35:07 GMT

    Cloning the RSB via HTTPS doesn't work for me:

    git clone https://git.rtems.org/rtems-source-builder rsb
    Cloning into 'rsb'... 
    Comment 2
    1. Sebastian Huber, Tue, 29 Jan 2019 07:15:57 GMT

    Ok, a git clone works via HTTPS, but it is extremely slow:

    time git clone https://git.rtems.org/rtems-source-builder rsb
    Cloning into 'rsb'...
    real    6m41.242s
    user    0m5.766s
    sys     0m3.054s 
    time git clone git://git.rtems.org/rtems-source-builder.git rsb
    Cloning into 'rsb'...
    remote: Counting objects: 8758, done.
    remote: Compressing objects: 100% (5222/5222), done.
    remote: Total 8758 (delta 6078), reused 5028 (delta 3494)
    Receiving objects: 100% (8758/8758), 2.89 MiB | 1.12 MiB/s, done.
    Resolving deltas: 100% (6078/6078), done.
    real    0m4.469s
    user    0m0.415s
    sys     0m0.083s 
    Comment 3
    1. Chris Johns, Tue, 12 Feb 2019 21:30:12 GMT

    The https access has recently been discussed on the devel list. This thread is the start:

    ​https://lists.rtems.org/pipermail/devel/2019-February/024816.html

    Comment 4
    1. Chris Johns, Thu, 12 Dec 2019 16:56:24 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    I am going to close this ticket. The documentation uses git://.

    If this is important funding is need to see why that we need to sort out in cgit.


    3684 - rtems_print_buffer is broken

    Link https://devel.rtems.org/ticket/3684
    Id 3684
    Reporter Chris Johns
    Created 29 January 2019 03:37:14
    Modified 8 February 2019 23:08:03
    Owner Chris Johns
    Type defect
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Consider this call:

    #include 
    rtems_print_buffer ((const unsigned char *) "\x12\x23\x56\x78", 4);

    On psim you get:

    1f 2f 5f 7f                                     |.#Vx            | 
    Comment 1
    1. Chris Johns, Tue, 29 Jan 2019 03:39:55 GMT

    The line in Dump_Line:

    rtems_putc(hexlist[0xf]); 

    should be:

    rtems_putc(hexlist[c & 0xf]); 
    Comment 2
    1. Sebastian Huber, Tue, 29 Jan 2019 09:10:42 GMT

    Yes, looks good.

    Comment 3
    1. Chris Johns, Sat, 02 Feb 2019 04:21:28 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 4
    1. Chris Johns, Fri, 08 Feb 2019 23:08:03 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 2d8a9c79/rtems:

    libmisc: Fix rtems_print_buffer Closes #3684

    3685 - Add large memory support to libdl

    Link https://devel.rtems.org/ticket/3685
    Id 3685
    Reporter Chris Johns
    Created 2 February 2019 04:32:04
    Modified 2 January 2020 11:54:11
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add large memory support to libdl. Some architectures use small relative offsets with smaller instructions for performance reasons. Object files loaded at addresses that are outside the relative range require trampoline calls that bridge the instruction in the object to the target symbol. The mechanism used depends on the archives.

    Libdl requires generic support to parse the relocation record before the object file allocation to provide the memory to hold the trampoline calls.

    The ARM and PowerPC architectures require trampolines. This is called veneers on ARM.

    Comment 1
    1. Chris Johns, Fri, 08 Feb 2019 23:08:11 GMT

    In b08278e/rtems:

    powerpc/psim: Increase the psim memory to 256M This allows test dl09 to run and test PowePC backend trampoline support. Updates #3685
    Comment 2
    1. Chris Johns, Fri, 08 Feb 2019 23:08:35 GMT

    In d8c70ba6/rtems:

    libdl: Add support for trampolines Trampolines or fixups for veneers provide long jump support for instruciton sets that implement short relative address branches. The linker provides trampolines when creating a static image. This patch adds trampoline support to libdl and the ARM architecture. The dl09 test requires enough memory so modules are outside the relative branch instruction ranges for the architecture. Updates #3685
    Comment 3
    1. Chris Johns, Fri, 08 Feb 2019 23:08:38 GMT

    In 194eb403/rtems:

    libdl: Add support for large memory programs Add trampolines to support relocs that are out of range on support architectures. Support not loading separate text/data sections in an object file if the symbol provided in the section is a duplicate. A base image may have pulled in part of an object and another part needs to be dynamically loaded. Refactor the unresolved handling to scale to hundreds of unresolved symbols when loading large number of files. Updates #3685
    Comment 4
    1. Chris Johns, Fri, 08 Feb 2019 23:08:42 GMT

    In 6c9f017/rtems:

    libdl: Add powerpc large memory and small data support. Add support for architecure sections that can be handled by the architecture back end. Add trampoline/fixup support for PowerPC. This means the PowerPC now supports large memory loading of applications. Add a bit allocator to manage small block based regions of memory. Add small data (sdata/sbss) support for the PowerPC. The support makes the linker allocated small data region of memory a global resource available to libdl loaded object files. Updates #3687 Updates #3685
    Comment 5
    1. Chris Johns, Tue, 19 Feb 2019 22:09:47 GMT

    In 22afb034/rtems:

    libdl/alloc: Add a locking interface to the allocator. Allow an allocator to lock the allocations. This is needed to lock the heap allocator so the text and trampoline table are as close together as possible to allow for the largest possible object file size. Update the default heap allocator to lock the heap allocator. Update ELF loading to lock the allocator. Updates #3685
    Comment 6
    1. Sebastian Huber, Fri, 13 Dec 2019 08:33:02 GMT

    b08278e/rtems leads to the following run-time error on PSIM:

    BATs must not overlap; area 0x08000000..0x09000000 hits DBAT 0
    BATs must not overlap; area 0x0c000000..0x0d000000 hits DBAT 0 

    The RAM overlaps with the PCI area:

     /*
       * Setup BATs and enable MMU
       */
      /* Memory */
      setdbat(0, 0x0<<28, 0x0<<28, 1<<28, _PAGE_RW);
      setibat(0, 0x0<<28, 0x0<<28, 1<<28,        0);
      /* PCI    */
      setdbat(1, 0x8<<24, 0x8<<24, 1<<24,  IO_PAGE);
      setdbat(2, 0xc<<24, 0xc<<24, 1<<24,  IO_PAGE); 
    Comment 7
    1. Sebastian Huber, Fri, 13 Dec 2019 08:41:49 GMT

    Increasing the RAM size to 256MiB (0x10000000) on PSIM breaks also the shared memory support:

    typedef struct {
      /* 0x0c000000 - 0x0c007FFF - AMD 29F040 */
      volatile uint8_t Flash[ 512 * 1024 ];
      /* 0x0c080000 - 0x0c0FFFFF - NVRAM/NVRAM */
      volatile uint8_t nvram[ 512 * 1024 ];
      /* 0x0c100000 - 0x0c100007 - NVRAM/RTC */
      psim_rtc_t RTC;
      /* 0x0c100008 - 0x0c10000F - NVRAM/RTC */
      uint8_t gap1[8];
      /* 0x0c100010 - 0x0c10001b - System V IPC Semaphore */
      psim_sysv_sem_t Semaphore;
      /* 0x0c10001c - 0x0c10001f - NVRAM/RTC */
      uint8_t gap2[4];
      /* 0x0c100020 - 0x0c10005F - Ethernet */
      volatile uint8_t Ethtap[ 64 ];
      /* 0x0c100060 - 0x0c10FFFF - NVRAM/RTC */
      uint8_t gap3[65440];
      /* 0x0c110000 - 0x0c12FFFF - System V IPC Shared Memory */
      uint8_t SharedMemory[ 128 * 1024 ];
      /* 0x0c130000 - 0x0c170000 - OpenPIC IRQ Controller */
      volatile uint8_t OpenPIC[ 256 * 1024 ];
    } psim_registers_t; 

    I suggest to revert this change.

    Comment 8
    1. Chris Johns, Tue, 17 Dec 2019 20:18:36 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    The large memory support in libdl task has finished. The psim issue should be moved to another ticket and the solution is to change the address map of the devices as suggested by Joel on the devel@ list.

    Comment 9
    1. Sebastian Huber, Thu, 02 Jan 2020 11:54:11 GMT

    See #3849.


    3686 - Add library searching and loading to libdl

    Link https://devel.rtems.org/ticket/3686
    Id 3686
    Reporter Chris Johns
    Created 2 February 2019 04:55:41
    Modified 1 June 2020 11:17:38
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Provide support to search library files (archives) for symbols loading the object file that contains the symbol. The support shall:

  • Parse a configuration file called /etc/libdl.conf for the list of archive symbols to load. Support fnmatch() wildcard parsing. Allow runtime updates reloading if there is a change.
  • Maintain archive symbol tables in memory to improve symbol search performance. Archives must have a ranlib generated symbol table. Reload an archive if it has changed.
  • Make sure separate text and data built object files is supported. Assume a duplicate symbol means that section and symbol has already been loaded. Load all sections not loaded. There is no need to be efficient at this point in time.
  • Add support to check if there are any system wide unresolved symbols.
  • Automatically unloaded archive object files that are not referenced.
  • Duplicate symbols in archives is not an error. The first archive that has the symbol in an object file is loaded.
  • The feature adds __symbol based demand loading__ of object files to libdl. A user loads an object file using the dlopen function and unresolved symbols are loaded from the libraries hosted on the target.

    Comment 1
    1. Chris Johns, Fri, 08 Feb 2019 23:08:15 GMT

    In 89c59be/rtems:

    libdl: Add symbol searching and loading from archives. Load archive symbol tables to support searching of archives for symbols. Search archive symbols and load the object file that contains the symbol. Search the global and archives until all remaining unresolved symbols are not found. Group the loaded object files in the pending queue. Run the object file and loaded dependents as a group before adding to the main object list. Remove orphaned object files after references are removed. Updates #3686
    Comment 2
    1. Chris Johns, Fri, 08 Feb 2019 23:08:19 GMT

    In 85b59974/rtems:

    libtests/dl02: Update the rtl-shell path. Updates #3686
    Comment 3
    1. Chris Johns, Fri, 08 Feb 2019 23:08:23 GMT

    In bac53634/rtems:

    libtests/dl02: Update the rtl-shell path. More verbose test. Updates #3686
    Comment 4
    1. Chris Johns, Fri, 08 Feb 2019 23:08:26 GMT

    In a7c6176/rtems:

    libtest/dl08: Add a test for archives. Create 2 archives. Load 1 object file which loads 6 object files from the libraries. Updates #3686
    Comment 5
    1. Chris Johns, Tue, 19 Feb 2019 22:09:52 GMT

    In be62def9/rtems:

    libdl/archive: Return false on read failure. Coverity issue 1442641 Updates #3686
    Comment 6
    1. Chris Johns, Tue, 19 Feb 2019 22:09:56 GMT

    In 62b01ab/rtems:

    libdl/archive: Fix the config file string index while removing tailing white space. Coverity issue 1442540 Updates #3686
    Comment 7
    1. Chris Johns, Tue, 19 Feb 2019 22:10:00 GMT

    In 7aa0530/rtems:

    libdl/archive: Check for an overflow of the symbol table. Coverty 1442636 Updates #3686
    Comment 8
    1. Chris Johns, Tue, 19 Feb 2019 22:10:03 GMT

    In c5615ddc/rtems:

    libdl/unresolved: Fix return value for rtems_rtl_unresolved_remove Coverity 1399717 Updates #3686
    Comment 9
    1. Sebastian Huber, Wed, 13 Mar 2019 07:15:22 GMT

    In 286e935/rtems:

    Regenerate cpukit/headers.am Updates #3686.
    Comment 10
    1. Chris Johns, Wed, 26 Feb 2020 03:51:41 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    Comment 11
    1. Sebastian Huber, Mon, 01 Jun 2020 11:16:17 GMT
    2. blocking: set to 3993
    Comment 12
    1. Sebastian Huber, Mon, 01 Jun 2020 11:17:38 GMT
    2. blocking: 3993 deleted

    3687 - Add architecture section support to libdl and support PowerPC's small data.

    Link https://devel.rtems.org/ticket/3687
    Id 3687
    Reporter Chris Johns
    Created 2 February 2019 05:18:03
    Modified 26 February 2020 03:52:04
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add support for architecture specific sections. Allow architecture back end support to handle sections that are specific to an architecture.

    Add PowerPC sdata and sbss support. The PowerPC can support a __small data__ 64K continuous system wide region of memory. Small data accesses are faster as the instruction is smaller however the variable is referenced as a signed 16bit offset from the register r13. This register is offset from the region's base address by 32K. The linker creates the .sdata and .sbss regions and sets the _SDA_BASE_ symbol which is loaded into r13. Any run-time loaded code with small data support needs space in the small data region therefore a BSP needs a way to define the space and the linker needs to allocate it. Provide a way for PowerPC BSPs to add extra memory to the small data region.

    RTEMS supports the PowerPC EABI and uses sysv small data allocations. RTEMS uses the default variable size of 8 as the selector for a variable to be allocated in the small data region. The GCC user manual recommends all code is built with the same settings. Dynamically loaded code could be built with small data disabled and if enabled the default size is recommended.

    Note, small data is system wide which means a default size of 8 allows only 8192 8 byte variables.

    Provide an allocator to manage the available small data memory.

    Comment 1
    1. Chris Johns, Fri, 08 Feb 2019 23:08:42 GMT

    In 6c9f017/rtems:

    libdl: Add powerpc large memory and small data support. Add support for architecure sections that can be handled by the architecture back end. Add trampoline/fixup support for PowerPC. This means the PowerPC now supports large memory loading of applications. Add a bit allocator to manage small block based regions of memory. Add small data (sdata/sbss) support for the PowerPC. The support makes the linker allocated small data region of memory a global resource available to libdl loaded object files. Updates #3687 Updates #3685
    Comment 2
    1. Sebastian Huber, Mon, 11 Feb 2019 10:43:14 GMT

    In eec706e2/rtems:

    bsps/powerpc: Fix small data area section Fix small data area in case no fixed size is desired. Rename bsp_section_set_sdata_sbss_size into bsp_section_small_data_area_size since this symbol reflects the overall small data area size (including space for libdl). Do not use bsp_section_sbss_size before definition in linker command file. Add new symbols to . Update #3687.
    Comment 3
    1. Chris Johns, Mon, 18 Feb 2019 00:28:02 GMT

    In 3ecb207/rtems:

    libdl/rap: Add the section alloc call after section load was split Updates #3687
    Comment 4
    1. Chris Johns, Wed, 06 Mar 2019 19:34:29 GMT

    In ec1dd51a/rtems:

    libdl: Add small data support to the remaining PowerPC BSPs. Updates #3687
    Comment 5
    1. Chris Johns, Wed, 26 Feb 2020 03:52:04 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3688 - rtems-docs fails to build with python3

    Link https://devel.rtems.org/ticket/3688
    Id 3688
    Reporter Chris Johns
    Created 6 February 2019 09:07:24
    Modified 12 December 2019 17:00:59
    Owner  
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Generating generated-posix-compliance.rst fails with Python3 as reported in

    ​https://github.com/sphinx-doc/sphinx/issues/6021#issuecomment-460701861

    Comment 1
    1. Chris Johns, Thu, 12 Dec 2019 17:00:59 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    ​https://lists.rtems.org/pipermail/devel/2019-February/024753.html


    3692 - libdl does not honour write unlock/lock for sections

    Link https://devel.rtems.org/ticket/3692
    Id 3692
    Reporter Chris Johns
    Created 14 February 2019 02:59:42
    Modified 14 February 2019 23:06:22
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The allocator does no honour write unlock and lock for read-only sections as it should. This can used to write protect executable memory.

    Comment 1
    1. Chris Johns, Thu, 14 Feb 2019 23:06:22 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In e309f77/rtems:

    libdl: Allocator does not unlock and lock memory on loading. Close #3692

    3693 - libdl incorrectly handles MIPS16hi/lo relocs

    Link https://devel.rtems.org/ticket/3693
    Id 3693
    Reporter Chris Johns
    Created 14 February 2019 23:13:30
    Modified 28 April 2020 04:00:12
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords libdl mips
    Cc sergkruglov@…
    Blocking  
    Blocked by  

    Description

    This issue was reported back is 2016 and it slipped through. I am creating a ticket here to track the issue.

    ​https://lists.rtems.org/pipermail/users/2016-January/029740.html

    Attachments:

    1 Chris Johns, Fri, 15 Feb 2019 02:29:55 GMT
      attach: set to libdl-rtl-mdreloc-mips-hi16-lo16.diff
     
    Comment 1
    1. Chris Johns, Thu, 14 Feb 2019 23:15:51 GMT

    The patch creates global data between the architecture relocator and the format. I wonder how the ELF format handles the same reloc records?

    The latest code has support for architecture specific handling of reloc records. I wonder if this new infrastructure can be used to achieve the same thing?

    Comment 2
    1. Chris Johns, Tue, 28 Apr 2020 04:00:12 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 0b416759/rtems:

    libdl/mips: Fix MIPS16hi/lo relocation support. This patch is an updated version from: ​https://lists.rtems.org/pipermail/users/2016-January/029740.html Closes #3693

    3694 - shm_open has logically unreachable code (Coverity ID: 1399706, 1399714)

    Link https://devel.rtems.org/ticket/3694
    Id 3694
    Reporter Joel Sherrill
    Created 19 February 2019 18:10:33
    Modified 14 March 2019 19:26:24
    Owner Gedare Bloom
    Type defect
    Component fs
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords coverity
    Cc  
    Blocking  
    Blocked by  

    Description

    Coverity ID: 1399706 and 1399714
    File: shmopen.c
    Method: shm_open for first

     dead_error_condition: The condition oflag & 0 cannot be true.
    289 if ( oflag & O_RDONLY ) {
    CID 1399706 (#1 of 1): Logically dead code (DEADCODE)
    dead_error_line: Execution cannot reach this statement: flags |= 2U;.
    290 flags |= LIBIO_FLAGS_READ;
    291 } else {

    URL: ​https://scan5.coverity.com/reports.htm#v29811/p10069/fileInstanceId=153084281&defectInstanceId=42558012&mergedDefectId=1399706&fileStart=1&fileEnd=250

    Same issue at other place in same file:

    197  int flags;
    dead_error_condition: The condition oflag & 0 cannot be true.
    198 if ( oflag & O_RDONLY ) {
    CID 1399714 (#1 of 1): Logically dead code (DEADCODE)
    dead_error_line: Execution cannot reach this statement: flags = 4;.
    199 flags = RTEMS_FS_PERMS_READ;
    200 } else {
    Comment 1
    1. Joel Sherrill, Tue, 19 Feb 2019 18:12:13 GMT
    2. description: modified (diff)
    3. summary: changed from shm_open has logically unreachable code (Coverity ID: 1399706) to shm_open has logically unreachable code (Coverity ID: 1399706, 1399714)
    Comment 2
    1. Gedare Bloom, Thu, 14 Mar 2019 16:08:10 GMT

    the fix is something along the lines of

    (oflag & O_ACCMODE) == O_RDONLY

    to check for read-only

    Comment 3
    1. Joel Sherrill, Thu, 14 Mar 2019 19:26:24 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 31e8f1b/rtems:

    shmopen.c: Fix logically unreachable code (Coverity ID: 1399706, 1399714) Closes #3694.

    3696 - Basic Support for Trace Compass

    Link https://devel.rtems.org/ticket/3696
    Id 3696
    Reporter Sebastian Huber
    Created 20 February 2019 12:02:45
    Modified 2 April 2020 08:58:00
    Owner Sebastian Huber
    Type project
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords SoC,statistics
    Cc  
    Blocking  
    Blocked by  

    Description

    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 #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, ​barectf, #2961 and #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.

    Comment 1
    1. Gedare Bloom, Thu, 28 Feb 2019 21:07:23 GMT
    2. keywords: SoC testing added; GSoC removed
    Comment 2
    1. Gedare Bloom, Thu, 28 Feb 2019 21:09:32 GMT
    2. keywords: statistics added; testing removed
    Comment 3
    1. Ravindra Kumar Meena, Fri, 31 May 2019 10:01:13 GMT

    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

    Comment 4
    1. Christian Mauderer, Mon, 10 Feb 2020 20:30:04 GMT

    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.

    Comment 5
    1. Sebastian Huber, Thu, 02 Apr 2020 08:58:00 GMT
    2. status: changed from assigned to closed
    3. version: set to 5
    4. resolution: set to fixed
    5. milestone: set to 5.1

    3699 - Wrong system register specified for ARM virtual timer value retrieval

    Link https://devel.rtems.org/ticket/3699
    Id 3699
    Reporter Kinsey Moore
    Created 21 February 2019 19:23:32
    Modified 22 February 2019 07:29:53
    Owner Sebastian Huber
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords gpt,timer,arm
    Cc  
    Blocking  
    Blocked by  

    Description

    In arm_cp15_get_counter_pl1_virtual_timer_value() in cpukit/score/cpu/arm/include/libcpu/arm-cp15.h, the system register specified by "p15, 0, %[val], c14, c2, 0" is actually the system register for the physical timer value. This should be "p15, 0, %[val], c14, c3, 0" for the virtual timer value as used in the setter.

    Comment 1
    1. Sebastian Huber, Fri, 22 Feb 2019 07:27:47 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to accepted
    4. version: set to 5
    5. milestone: set to 5.1
    Comment 2
    1. Kinsey Moore, Fri, 22 Feb 2019 07:29:53 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 7abc497/rtems:

    bsps/arm: Fix system register for virtual timer The system register in use for retrieval of the virtual timer value was mistakenly copied from the physical timer value retrieval function. Virtual timer value retrieval should use the same system register as the virtual timer value setter. Close #3699.

    3708 - Remove Doxygen comments from confdefs.h

    Link https://devel.rtems.org/ticket/3708
    Id 3708
    Reporter Sebastian Huber
    Created 26 February 2019 14:22:06
    Modified 1 June 2020 11:27:20
    Owner Sebastian Huber
    Type task
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3705
    Blocked by  

    Description

    The confdefs.h file contains Doxygen comments. They are not helpful and lead to a confusing Doxygen output. The documentation place for the RTEMS configuration is the RTEMS Classic API Guide:

    ​https://docs.rtems.org/branches/master/c-user/configuring_a_system.html

    Comment 1
    1. Chris Johns, Wed, 27 Feb 2019 23:48:33 GMT

    Can a link be added so doxygen generate docs point to the documentation?

    Comment 2
    1. Joel Sherrill, Wed, 27 Feb 2019 23:52:08 GMT

    I am against a patch that removes them without verifying that all info in the Doxygen comments is already in the Classic API Guide. There has to be at least some information in confdefs.h comments that isn't in the manual.

    Comment 3
    1. Sebastian Huber, Thu, 28 Feb 2019 14:18:19 GMT

    I think we all agreed that the user documentation is in the manuals and Doxygen is for internal use, e.g. for RTEMS contributors.

    If something is in Doxygen comments in confdefs.h which is not in the manual, then of course we should update the manual.

    Comment 4
    1. Sebastian Huber, Mon, 01 Jun 2020 11:27:20 GMT
    2. status: changed from assigned to closed
    3. version: changed from 6 to 5
    4. resolution: set to fixed
    5. milestone: changed from 6.1 to 5.1

    Removing the Doxygen markup from was a side-effect of #3875. With the new specification items for the application configuration options it would be possible to generate Doxygen markup for them: #3994.


    3720 - mfill shell command uses the wrong arguments for the memset()

    Link https://devel.rtems.org/ticket/3720
    Id 3720
    Reporter Sebastian Huber
    Created 8 March 2019 06:38:41
    Modified 8 March 2019 06:40:08
    Owner Sebastian Huber
    Type defect
    Component shell
    Status closed
    Resolution fixed
    Version 4.9
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Jonathan Brandmeyer, Fri, 08 Mar 2019 06:40:08 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 2e8a66d/rtems:

    shell: Correct argument order of mfill Close #3720.

    3724 - bsp/lpc24xx: Convert SSP driver to Linux API

    Link https://devel.rtems.org/ticket/3724
    Id 3724
    Reporter Sebastian Huber
    Created 12 March 2019 14:58:39
    Modified 18 March 2019 09:28:16
    Owner Sebastian Huber
    Type task
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Tue, 12 Mar 2019 15:00:06 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 1400210/rtems:

    bsp/lpc24xx: Convert SSP driver to Linux API Use interrupts instead of polled or DMA driven mode. Change license to BSD-2-Clause. Close #3724.
    Comment 2
    1. Sebastian Huber, Mon, 18 Mar 2019 08:54:22 GMT

    In 4480a83/rtems-docs:

    bsp-howto: Update SPI chapter Update #3724.
    Comment 3
    1. Sebastian Huber, Mon, 18 Mar 2019 09:28:16 GMT

    In 808ef17/rtems-docs:

    user: Add basic lpc24xx description Update #3724. Update #3725.

    3725 - bsp/lpc24xx: Convert I2C driver to Linux API

    Link https://devel.rtems.org/ticket/3725
    Id 3725
    Reporter Sebastian Huber
    Created 12 March 2019 14:59:01
    Modified 8 May 2019 11:13:18
    Owner Sebastian Huber
    Type task
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Mon, 18 Mar 2019 08:33:00 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 007d4e12/rtems:

    bsp/lpc24xx: Convert I2C driver to Linux API Change license to BSD-2-Clause. Close #3725.
    Comment 2
    1. Sebastian Huber, Mon, 18 Mar 2019 08:54:24 GMT

    In 15f4670/rtems-docs:

    bsp-howto: Update I2C chapter Update ##3725.
    Comment 3
    1. Sebastian Huber, Mon, 18 Mar 2019 09:28:16 GMT

    In 808ef17/rtems-docs:

    user: Add basic lpc24xx description Update #3724. Update #3725.
    Comment 4
    1. Sebastian Huber, Wed, 08 May 2019 11:13:18 GMT

    In 271b8a6/rtems:

    bsp/lpc24xx: Remove obsolete BSP optinons Update #3725.

    3728 - Set small data seciton to max size for mvme5500 and motorola_powerpc BSPs

    Link https://devel.rtems.org/ticket/3728
    Id 3728
    Reporter Chris Johns
    Created 29 March 2019 22:38:50
    Modified 1 April 2019 03:24:56
    Owner Chris Johns
    Type enhancement
    Component bsps
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    These are large memory targets that can support libdl. Make the small data memory the maximum size.

    Comment 1
    1. Chris Johns, Mon, 01 Apr 2019 03:24:56 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 294c6f4/rtems:

    Set the small data section size to max. for mvme5500 and mvme2100 BSPs Closes #3728

    3731 - Add rtems_scheduler_get_processor()

    Link https://devel.rtems.org/ticket/3731
    Id 3731
    Reporter Sebastian Huber
    Created 4 April 2019 07:33:54
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3989
    Blocked by  

    Description

    Add rtems_scheduler_get_processor() as a replacement for rtems_get_current_processor(). The rtems_get_current_processor() is a bit orphaned. Adopt it by the Scheduler Manager. This is in line with the glibc sched_getcpu() function.

    Comment 1
    1. Sebastian Huber, Tue, 09 Apr 2019 06:11:49 GMT

    In 03c9f24/rtems:

    rtems: Add rtems_scheduler_get_processor() Add rtems_scheduler_get_processor() as a replacement for rtems_get_current_processor(). The rtems_get_current_processor() is a bit orphaned. Adopt it by the Scheduler Manager. This is in line with the glibc sched_getcpu() function. Deprecate rtems_get_current_processor(). Update #3731.
    Comment 2
    1. Sebastian Huber, Tue, 09 Apr 2019 06:13:06 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 3495a91/rtems-docs:

    c-user: Document rtems_scheduler_get_processor() Close #3731.
    Comment 3
    1. Sebastian Huber, Thu, 28 May 2020 13:28:09 GMT
    2. blocking: set to 3989
    Comment 4
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3732 - Add rtems_scheduler_get_processor_maximum()

    Link https://devel.rtems.org/ticket/3732
    Id 3732
    Reporter Sebastian Huber
    Created 4 April 2019 07:36:27
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3990
    Blocked by  

    Description

    Add rtems_scheduler_get_processor_maximum() as a replacement for rtems_get_processor_count(). The rtems_get_processor_count() is a bit orphaned. Adopt it by the Scheduler Manager. The count is also misleading, since the processor set may have gaps and the actual count of online processors may be less than the value returned by rtems_get_processor_count().

    Comment 1
    1. Sebastian Huber, Fri, 05 Apr 2019 06:17:36 GMT
    2. description: modified (diff)
    3. summary: changed from Add rtems_scheduler_get_maximum_processor() to Add rtems_scheduler_get_processor_maximum()
    Comment 2
    1. Sebastian Huber, Tue, 09 Apr 2019 06:11:52 GMT

    In f9219db/rtems:

    rtems: Add rtems_scheduler_get_processor_maximum() Add rtems_scheduler_get_processor_maximum() as a replacement for rtems_get_processor_count(). The rtems_get_processor_count() is a bit orphaned. Adopt it by the Scheduler Manager. The count is also misleading, since the processor set may have gaps and the actual count of online processors may be less than the value returned by rtems_get_processor_count(). Update #3732.
    Comment 3
    1. Sebastian Huber, Tue, 09 Apr 2019 06:13:08 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 53300c8/rtems-docs:

    c-user: rtems_scheduler_get_processor_maximum() Close #3732.
    Comment 4
    1. Sebastian Huber, Thu, 11 Apr 2019 07:19:29 GMT

    In cfcd6dc9/rtems:

    score: Rename _SMP_Processor_count Rename _SMP_Processor_count in _SMP_Processor_maximum to be in line with the API level rtems_scheduler_get_processor_maximum(). Update #3732.
    Comment 5
    1. Sebastian Huber, Thu, 11 Apr 2019 07:19:32 GMT

    In ad87de4/rtems:

    score: Rename _SMP_Get_processor_count() Rename _SMP_Get_processor_count() in _SMP_Get_processor_maximum() to be in line with the API level rtems_scheduler_get_processor_maximum(). Update #3732.
    Comment 6
    1. Sebastian Huber, Thu, 28 May 2020 13:29:14 GMT
    2. blocking: set to 3990
    Comment 7
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3733 - Add general reg support to libdebugger

    Link https://devel.rtems.org/ticket/3733
    Id 3733
    Reporter Chris Johns
    Created 5 April 2019 06:13:28
    Modified 9 April 2019 05:05:23
    Owner Chris Johns
    Type enhancement
    Component lib/debugger
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Testing master on a Zynq reports:

    (gdb) target remote 10.10.5.45:1122
    Remote debugging using 10.10.5.45:1122
    Truncated register 19 in remote 'g' packet

    It looks to me like gdb is now smart enough to know this ARM arch has a NEON and floating point registers:

    (gdb) maint print registers
    Name Nr Rel Offset Size Type
    r0 0 0 0 4 uint32_t
    r1 1 1 4 4 uint32_t
    r2 2 2 8 4 uint32_t
    r3 3 3 12 4 uint32_t
    r4 4 4 16 4 uint32_t
    r5 5 5 20 4 uint32_t
    r6 6 6 24 4 uint32_t
    r7 7 7 28 4 uint32_t
    r8 8 8 32 4 uint32_t
    r9 9 9 36 4 uint32_t
    r10 10 10 40 4 uint32_t
    r11 11 11 44 4 uint32_t
    r12 12 12 48 4 uint32_t
    sp 13 13 52 4 *1
    lr 14 14 56 4 uint32_t
    pc 15 15 60 4 *1
    f0 16 16 64 12 _arm_ext
    f1 17 17 76 12 _arm_ext
    f2 18 18 88 12 _arm_ext
    f3 19 19 100 12 _arm_ext
    f4 20 20 112 12 _arm_ext
    f5 21 21 124 12 _arm_ext
    f6 22 22 136 12 _arm_ext
    f7 23 23 148 12 _arm_ext
    fps 24 24 160 4 uint32_t
    cpsr 25 25 164 4 uint32_t

    The target support in libdebugger is a simple array of 32bit ints. This needs to change to handle registers at various offsets. The lack of fp regs was a simplification at the time I first implement this server. Loos like I need to sort this out.

    Comment 1
    1. Chris Johns, Sat, 06 Apr 2019 00:39:37 GMT
    2. status: changed from new to accepted

    I suspect the more recent gdb we are using is checking the g register data length and libdebugger was not returning the correct amount for the ARM processor.

    Comment 2
    1. Chris Johns, Sat, 06 Apr 2019 00:43:24 GMT

    Adding support for offsets to the ARM backend has things working. The following is with master RSB, kernel and libbsd:

     $ /opt/work/rtems/5/bin/arm-rtems5-gdb ./build/arm-rtems5-xilinx_zynq_zedboard-default/debugger01.exe
    GNU gdb (GDB) 8.2.1
    Copyright (C) 2018 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later 
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    Type "show copying" and "show warranty" for details.
    This GDB was configured as "--host=x86_64-freebsd11.2 --target=arm-rtems5".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    .
    Find the GDB manual and other documentation resources online at:
        .
    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from ./build/arm-rtems5-xilinx_zynq_zedboard-default/debugger01.exe...done.
    (gdb) target remote 10.10.5.45:1122
    Remote debugging using 10.10.5.45:1122
    0x00000030 in ?? ()
    (gdb) info threads
      Id   Target Id                                                                                                    Frame
    * 1    Thread 1.167837697 (UI1  (0a010001), priority(c:508 r:508), stack(s: 32768 a:0x44dda0), state(TIME:SUSP:IS)) 0x00000030 in ?? ()
      2    Thread 1.167837698 (SHLL (0a010002), priority(c:  2 r:  2), stack(s: 32768 a:0x456590), state(SEM:SUSP))     arm_interrupt_disable () at /opt/work/chris/rtems/kernel/rtems.git/cpukit/score/cpu/arm/include/rtems/score/cpu.h:299
    (gdb) info reg
    r0             0x2c7184            2912644
    r1             0x2c7184            2912644
    r2             0x2c7184            2912644
    r3             0x2c7184            2912644
    r4             0x30be70            3194480
    r5             0x40e660            4253280
    r6             0x7184be70          1904524912
    r7             0x7184002c          1904476204
    r8             0x7184002c          1904476204
    r9             0x7184002c          1904476204
    r10            0xbe70002c          3195011116
    r11            0xea680030          3932684336
    r12            0xbe700040          3195011136
    sp             0xc5000030          0xc5000030
    lr             0xbe6c0044          3194748996
    pc             0x30                0x30
    cpsr           0x0                 0
    (gdb) thread 2
    [Switching to thread 2 (Thread 1.167837698)]
    #0  arm_interrupt_disable () at /opt/work/chris/rtems/kernel/rtems.git/cpukit/score/cpu/arm/include/rtems/score/cpu.h:299
    299       __asm__ volatile (
    (gdb) bt
    #0  arm_interrupt_disable () at /opt/work/chris/rtems/kernel/rtems.git/cpukit/score/cpu/arm/include/rtems/score/cpu.h:299
    #1  _Thread_Do_dispatch (cpu_self=, level=) at /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/score/src/threaddispatch.c:309
    #2  0x0022d09a in _Semaphore_Wait_timed_ticks (_sem=_sem@entry=0x455e38, ticks=ticks@entry=0) at /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/score/src/semaphore.c:100
    #3  0x002254fa in rtems_binary_semaphore_wait_timed_ticks (ticks=0, binary_semaphore=0x455e38) at /opt/work/chris/rtems/kernel/rtems.git/cpukit/include/rtems/thread.h:263
    #4  fillBufferQueue (tty=0x455da8) at /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/libcsupport/src/termios.c:1509
    #5  rtems_termios_read_tty (tty=tty@entry=0x455da8, buffer=buffer@entry=0x44c94b <__sf+67> "\r", initial_count=initial_count@entry=1) at /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/libcsupport/src/termios.c:1538
    #6  0x0022562c in rtems_termios_imfs_read (iop=0x41aec8 , buffer=0x44c94b <__sf+67>, count=1) at /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/libcsupport/src/termios.c:2052
    #7  0x00223be8 in read (fd=, buffer=, count=) at /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/libcsupport/src/read.c:44
    #8  0x00241c12 in __sread (ptr=, cookie=0x44c908 <__sf>, buf=, n=) at ../../../../../../../../../gcc-7.4.0/newlib/libc/stdio/stdio.c:47
    #9  0x00241782 in __srefill_r (ptr=ptr@entry=0x40ed18 <_RTEMS_tasks_Objects+1720>, fp=fp@entry=0x44c908 <__sf>) at ../../../../../../../../../gcc-7.4.0/newlib/libc/stdio/refill.c:117
    #10 0x0024188c in __srget_r (ptr=ptr@entry=0x40ed18 <_RTEMS_tasks_Objects+1720>, fp=fp@entry=0x44c908 <__sf>) at ../../../../../../../../../gcc-7.4.0/newlib/libc/stdio/rget.c:42
    #11 0x0023abfc in fgetc (fp=fp@entry=0x44c908 <__sf>) at ../../../../../../../../../gcc-7.4.0/newlib/libc/stdio/fgetc.c:110
    #12 0x00232858 in rtems_shell_getchar (in=in@entry=0x44c908 <__sf>) at /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/libmisc/shell/shell_getchar.c:123
    #13 0x00231704 in rtems_shell_line_editor (size=128, out=0x44c988 <__sf+128>, in=0x44c908 <__sf>, prompt=, count=, cmds=0x45e360) at /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/libmisc/shell/shell.c:225
    #14 rtems_shell_main_loop (shell_env_arg=) at /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/libmisc/shell/shell.c:880
    #15 0x0023255e in rtems_shell_task (task_argument=) at /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/libmisc/shell/shell.c:679
    #16 0x0022ad3a in _Thread_Handler () at /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/score/src/threadhandler.c:135
    #17 0x0022abbc in _Thread_Do_dispatch (cpu_self=, level=) at /opt/work/chris/rtems/kernel/rtems.git/c/src/../../cpukit/score/src/threaddispatch.c:299
    #18 0x00000000 in ?? ()
    Backtrace stopped: previous frame identical to this frame (corrupt stack?)
    (gdb) 
    Comment 3
    1. Chris Johns, Tue, 09 Apr 2019 05:05:23 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 2c09b71/rtems:

    libdebugger: Use an offset table to format GDB g packets. Adding support for a register offset table lets FPU registers be supported if added to the backend. Closes #3733.

    3734 - Add RTEMS_CONST attribute

    Link https://devel.rtems.org/ticket/3734
    Id 3734
    Reporter Sebastian Huber
    Created 5 April 2019 06:41:32
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    Add RTEMS_CONST attribute to make the compiler specific attribute ((const)) available.

    Comment 1
    1. Sebastian Huber, Fri, 05 Apr 2019 06:42:35 GMT
    2. component: changed from rtems to score
    Comment 2
    1. Sebastian Huber, Tue, 09 Apr 2019 06:11:45 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 3c50c328/rtems:

    score: Add RTEMS_CONST Close #3734.
    Comment 3
    1. Sebastian Huber, Tue, 09 Apr 2019 06:18:43 GMT

    In 71c5b005/rtems:

    spmisc01: Use RTEMS_CONST Update #3734.
    Comment 4
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3735 - Remove CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE

    Link https://devel.rtems.org/ticket/3735
    Id 3735
    Reporter Sebastian Huber
    Created 9 April 2019 06:59:10
    Modified 17 December 2019 07:56:09
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3490
    Blocked by  

    Description

    Remove the CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE configuration option. The RTEMS configuration should be done via explicit configuration options to allow more freedom for implementation changes. The use of this configuration option had a note in the documentation:

    "This is a configuration parameter which is very unlikely to be used by an application. If you find yourself wanting to use it in an application, please reconsider and discuss this on the RTEMS Users mailing list."

    No discussion took place in a couple of years about this topic.

    Comment 1
    1. Sebastian Huber, Fri, 13 Dec 2019 09:10:35 GMT

    In d24b301/rtems:

    config: CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE Obsolete the CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE configuration option. Update #3735.
    Comment 2
    1. Sebastian Huber, Fri, 13 Dec 2019 09:10:41 GMT

    In 24f8915/rtems:

    config: Add _MPCI_Configuration Replace the user MPCI configuration table with a system provided _MPCI_Configuration. Update #3735.
    Comment 3
    1. Sebastian Huber, Fri, 13 Dec 2019 09:10:44 GMT

    In 1d9f509e/rtems:

    config: Statically allocate MP thread proxies Update #3735.
    Comment 4
    1. Sebastian Huber, Fri, 13 Dec 2019 09:10:48 GMT

    In 3fba9de2/rtems:

    config: Statically allocate MP object controls Update #3735.
    Comment 5
    1. Sebastian Huber, Fri, 13 Dec 2019 09:10:51 GMT

    In 78211376/rtems:

    score: Remove _Workspace_Allocate_or_fatal_error() This function is unused. Update #3735.
    Comment 6
    1. Sebastian Huber, Fri, 13 Dec 2019 13:07:10 GMT

    In 93d5323/rtems-docs:

    c-user: CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE Obsolete the CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE configuration option. Update #3735.
    Comment 7
    1. Sebastian Huber, Tue, 17 Dec 2019 07:56:09 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3736 - PowerPC Beatnik BSP C++ exceptions broken

    Link https://devel.rtems.org/ticket/3736
    Id 3736
    Reporter Chris Johns
    Created 11 April 2019 00:08:08
    Modified 11 November 2019 03:51:30
    Owner Sebastian Huber <sebastian.huber@…>
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Running cdtest.exe fails. I am wondering if there is an issue in the linkcmd scripts this BSP uses. The psim works.

    The trace is:

    config addr is 0xf1000cf8
    config data is 0xf1000cfc
    Welcome to RTEMS rtems-5.0.0 (PowerPC/Generic (classic FPU)/beatnik)
    CPU: MPC7457
    Board Type: MVME5500-0161 (S/N E1712C9)
    Bus Clock Freq: 133333333 Hz
    CPU Clock Freq: 1000000000 Hz
    Memory: 536870912 bytes
    -----------------------------------------
    Now BSP_mem_size = 0x1fe00000
    Configuration.work_space_size = a170
    Page table setup finished; will activate it NOW...
    Going to start PCI buses scanning and initialization
    Number of PCI buses found is : 3
    MSR 0x2003032
    Exit from bspstart
    Universe II PCI-VME bridge detected at 0x82000000, IRQ 76
    Universe Master Ports:
    Port VME-Addr Size PCI-Adrs Mode:
    0: 0x20000000 0x0e000000 0x90000000 A32, D64 [MBLT], Dat, Sup
    1: 0x00000000 0x00ff0000 0x9f000000 A24, D64 [MBLT], Dat, Sup
    2: 0x00000000 0x00010000 0x9fff0000 A16, D64, Dat, Sup
    7: 0x00000000 0x01000000 0x9e000000 CSR, D64, Dat, Sup
    Universe Slave Ports:
    Port VME-Addr Size PCI-Adrs Mode:
    0: 0x90000000 0x1fe00000 0x00000000 A32, Pgm, Dat, Sup, Usr, PWEN, PRE
    N
    vmeUniverse IRQ manager: looking for registers on VME...
    Trying to find CRG on VME...
    vmeUniverse IRQ manager - registers not found on VME; falling back to PCI
    *** BEGIN OF TEST CONSTRUCTOR/DESTRUCTOR ***
    *** TEST VERSION: 5.0.0.8a8b95aa1d6932ba9d2acd7a785100f7d0919205-modified
    *** TEST STATE: EXPECTED-PASS
    *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
    *** TEST TOOLS: 7.4.0 20181206 (RTEMS 5, RSB 9a3e12e5820918057633798c3fe2
    a1f952fb4e56, Newlib 1d35a003f)
    GLOBAL: Hey I'm in base class constructor number 1 for 0x5c404.
    GLOBAL: Hey I'm in base class constructor number 2 for 0x5c410.
    GLOBAL: Hey I'm in derived class constructor number 3 for 0x5c410.
    LOCAL: Hey I'm in base class constructor number 4 for 0x6cbdc.
    LOCAL: Hey I'm in base class constructor number 5 for 0x6cbd0.
    LOCAL: Hey I'm in base class constructor number 6 for 0x6cbc4.
    LOCAL: Hey I'm in base class constructor number 7 for 0x6cbb8.
    LOCAL: Hey I'm in derived class constructor number 8 for 0x6cbb8.
    IO Stream not tested
    LOCAL: Hey I'm in derived class destructor number 8 for 0x6cbb8.
    Derived class - Instantiation order 8
    LOCAL: Hey I'm in base class destructor number 7 for 0x6cbb8.
    Derived class - Instantiation order 8
    LOCAL: Hey I'm in base class destructor number 6 for 0x6cbc4.
    Derived class - Instantiation order 6
    LOCAL: Hey I'm in base class destructor number 5 for 0x6cbd0.
    Derived class - Instantiation order 5
    LOCAL: Hey I'm in base class destructor number 4 for 0x6cbdc.
    Derived class - Instantiation order 5
    *** TESTING C++ EXCEPTIONS ***
    fatal source: RTEMS_FATAL_SOURCE_EXIT
    bsp_fatal_extension(): RTEMS terminated
    Comment 1
    1. Sebastian Huber, Thu, 11 Apr 2019 06:42:09 GMT

    Maybe related to #3339.

    Comment 2
    1. Chris Johns, Thu, 11 Apr 2019 07:06:51 GMT

    Replying to Sebastian Huber:

    Maybe related to #3339.

    If you mean a broken linkcmd file, yes. There are a number of BSP specific linkcmd files and this is hurting us, these BSPs and their users. A common linkcmd file for the arch means a simulator is able to do a lot of the needed testing.

    We have a lot of important systems running PowerPC BSPs and there are issues. I think it would be good to sort this out but we need someone to do this or use a support service and we need someone with enough gear or access to people with the gear it to make the changes and get a working base line.

    Comment 3
    1. Sebastian Huber, Tue, 07 May 2019 08:32:31 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In f6895c6/rtems:

    bsps/powerpc: Fix C++ exception handling Close #3736.
    Comment 4
    1. Chris Johns, Mon, 11 Nov 2019 03:51:30 GMT
    2. component: changed from admin to arch/powerpc

    3741 - libdl loading ELF objects from libbsd NFS file system ends in a deadlock

    Link https://devel.rtems.org/ticket/3741
    Id 3741
    Reporter dufault
    Created 27 April 2019 12:51:51
    Modified 4 May 2019 02:22:01
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords run-time-loader libdl
    Cc  
    Blocking  
    Blocked by  

    Description

    For ELF files the run-time loader calls this chain:

    • __rtems_rtl_elf_file_load()__
    • __rtems_rtl_alloc_lock()__
    • __rtems_rtl_alloc_heap()__
    • ___RTEMS_Lock_allocator()__

    ___RTEMS_Lock_allocator()__ locks all heap operations. RTL then calls __read()__ and for NFS file systems the NFS threads try to use the heap, locking up the system.

    Comment 1
    1. Chris Johns, Sun, 28 Apr 2019 01:44:02 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to accepted
    4. milestone: set to 5.1
    Comment 2
    1. Chris Johns, Tue, 30 Apr 2019 07:25:22 GMT

    The default RTL allocator (heap) uses the file system while holding the heap allocator lock and if the file system uses the heap we end up in a deadlock. LibBSD's NFS implementation uses the heap.

    The allocator lock/unlock logic was added when the trampoline changes were added. Trampolines provide large memory support and is documented in the User Manual (​https://docs.rtems.org/branches/master/user/exe/loader.html#large-memory). The trampoline table needs to be close to the code using it or it may be out of range. If something allocates a large piece of memory between allocating the text memory and the trampoline table the relocation to the trampoline will be out of range.

    There are two unknowns until the memory is allocated and code is loaded. The first is the location in memory and the second is the instruction the relocation record is pointing too. The location lets us determine the distance from the instruction to the target address and if it is in range and the instruction lets the arch back-end know determine the range the instruction has.

    The ELF loader can be split into a finer set of stages to do as much processing before allocating memory however as stated above the two unknowns need to be resolved.

    The most robust solution is to add code to build a table of relocation records that could require trampolines. While the allocator lock is being held:

    Lock the allocator Allocate the sections Locate the symbols Determine the number of trampolines using the cached relocation records Allocate the trampoline table Unlock the allocator

    The number of trampolines can be determined using the relocation table data held in memory. The relocation table could be implemented in a similar way the unresolved externals is done with a common pool of blocks that grows and shrinks based on demand. A block allocation should aid the heap with fragmentation.

    Comment 3
    1. Chris Johns, Thu, 02 May 2019 01:45:27 GMT
    2. summary: changed from libdl load of ELF objects on NFS file system lock up to libdl loadinf ELF objects from libbsd NFS file system ends in a deadlock

    I have:

    Implemented caching any reloc record that could result in a trampoline using the unresolved table. This table is suitable for the purpose. I have not refactored the unresolved code to relabel the code to be common to unresolved and trampolines at this point in time, I have simply added the trampoline code to the unresolved code with a separate RTL internal header to isolate the interface. Increased the block size for the unresolved table from 64 to 256 and a block is allocated when in the resolved table is opened and one block is always held. It is not clear to me how many tramp reloc records a large object file or an incrementally link object file could have. Added per object file trampoline stats to help track what is happening.

    The output for the PowerPC psim BSP for test dl09 with the test hacked to show the trampoline stats is:

    RTL List:
     /dl09-o1.o
      trampolines:
          slots     : 3
          size      : 48
          slot size : 16
          used      : 1
          relocs    : 0
          unresolved: 3
          yield     : 33%
     /dl09-o2.o
      trampolines:
          slots     : 7
          size      : 112
          slot size : 16
          used      : 7
          relocs    : 6
          unresolved: 1
          yield     : 100%
     /dl09-o5.o
      trampolines:
          slots     : 6
          size      : 96
          slot size : 16
          used      : 6
          relocs    : 6
          unresolved: 0
          yield     : 100%
     /dl09-o3.o
      trampolines:
          slots     : 37
          size      : 592
          slot size : 16
          used      : 13
          relocs    : 12
          unresolved: 25
          yield     : 35%
     /dl09-o4.o
      trampolines:
          slots     : 8
          size      : 128
          slot size : 16
          used      : 8
          relocs    : 7
          unresolved: 1
          yield     : 100% 

    The dl09 test is a bit special because it does a large heap allocation between the loading of each object modules so the yields are close to 100%. The yield indicates how successful the slot usage is. There is an element of estimation in the allocation size of the table.

    Note, /dl09-o3.o exposes a new issue related to the way the unresolved external trampoline slots are managed. This file has a yield of 35% because there are 25 unresolved relocation records. Most of these turn out to be small data (SDATA) relocations and do not need trampolines because they are in the small data section which is limited in size and these are for data which can be jumped too.

    If we look at test dl08 we get:

    RTL List:
     /dl08-o1.o
      trampolines:
          slots     : 1
          size      : 16
          slot size : 16
          used      : 0
          relocs    : 0
          unresolved: 1
          yield     : 0%
     /libdl08_1.a:dl08-o2.o
      trampolines:
          slots     : 1
          size      : 16
          slot size : 16
          used      : 0
          relocs    : 0
          unresolved: 1
          yield     : 0%
     /libdl08_2.a:dl08-o3.o
      trampolines:
          slots     : 25
          size      : 400
          slot size : 16
          used      : 0
          relocs    : 0
          unresolved: 25
          yield     : 0%
     /libdl08_1.a:dl08-o4.o
      trampolines:
          slots     : 1
          size      : 16
          slot size : 16
          used      : 0
          relocs    : 0
          unresolved: 1
          yield     : 0%
     /libdl08_2.a:dl08-o6-123456789-123456789.o
      trampolines: no slots allocated
     /libdl08_2.a:dl08-o5.o
      trampolines:
          slots     : 1
          size      : 16
          slot size : 16
          used      : 0
          relocs    : 0
          unresolved: 1
          yield     : 0% 

    Notice we have a yield of 0% because no trampolines are needed and everything is within range. Again we have the same issue noted above with /libdl08_2.a:dl08-o3.o.

    Comment 4
    1. Chris Johns, Thu, 02 May 2019 01:47:14 GMT
    2. summary: changed from libdl loadinf ELF objects from libbsd NFS file system ends in a deadlock to libdl loading ELF objects from libbsd NFS file system ends in a deadlock
    Comment 5
    1. Chris Johns, Fri, 03 May 2019 00:12:02 GMT

    I have worked on the way the relocs are parsed and now have dl09 on the psim and xilinx_zynq_a9_qemu BSPs reporting trampoline usage of:

    RTL List:
     /dl09-o1.o
      trampolines:
          slots     : 1
          size      : 16
          slot size : 16
          used      : 1
          relocs    : 1
          unresolved: 0
          yield     : 100%
     /dl09-o2.o
      trampolines:
          slots     : 7
          size      : 112
          slot size : 16
          used      : 7
          relocs    : 7
          unresolved: 0
          yield     : 100%
     /dl09-o5.o
      trampolines:
          slots     : 6
          size      : 96
          slot size : 16
          used      : 6
          relocs    : 6
          unresolved: 0
          yield     : 100%
     /dl09-o3.o
      trampolines:
          slots     : 13
          size      : 208
          slot size : 16
          used      : 13
          relocs    : 13
          unresolved: 0
          yield     : 100%
     /dl09-o4.o
      trampolines:
          slots     : 8
          size      : 128
          slot size : 16
          used      : 8
          relocs    : 8
          unresolved: 0
          yield     : 100% 

    The dl08 results still have a 0% yield but the number of slots is lower:

    RTL List:
     /dl08-o1.o
      trampolines:
          slots     : 1
          size      : 16
          slot size : 16
          used      : 0
          relocs    : 1
          unresolved: 0
          yield     : 0%
     /libdl08_1.a:dl08-o2.o
      trampolines:
          slots     : 1
          size      : 16
          slot size : 16
          used      : 0
          relocs    : 1
          unresolved: 0
          yield     : 0%
     /libdl08_2.a:dl08-o3.o
      trampolines:
          slots     : 1
          size      : 16
          slot size : 16
          used      : 0
          relocs    : 1
          unresolved: 0
          yield     : 0%
     /libdl08_1.a:dl08-o4.o
      trampolines:
          slots     : 1
          size      : 16
          slot size : 16
          used      : 0
          relocs    : 1
          unresolved: 0
          yield     : 0%
     /libdl08_2.a:dl08-o6-123456789-123456789.o
      trampolines:
          slots     : 0
          size      : 0
          slot size : 16
          used      : 0
          relocs    : 0
          unresolved: 0
          yield     : 0%
     /libdl08_2.a:dl08-o5.o
      trampolines:
          slots     : 1
          size      : 16
          slot size : 16
          used      : 0
          relocs    : 1
          unresolved: 0
          yield     : 0% 
    Comment 6
    1. Chris Johns, Fri, 03 May 2019 00:46:02 GMT

    I have posted a reasonable solution to the bug but I think there is a better solution. The current trampoline processing is reloc record based and it should target symbol based. A trampoline to a target symbol will be the same set of instructions and could be shared by relocations. This would drop the trampoline slot count.

    A change would move away from a trampoline cache of each record to a cache of target symbols referenced by reloc records. The tramp check would see which symbols are in range and which are out of range to determine the number of slots to allocate. A relocation record that is not the full address range would still need a slot if the symbol is unresolved. The symbol cache entry would reference count reloc records referencing it and be deleted once there are no more references. The symbol cache entry would hold the trampoline slot number once allocated for use by other relocation records.

    Note, the trampoline code is transparent to the execution of the object code and only has the target symbol address in it therefore it can be shared by more than one relocation record.

    The unresolved table code may need to be split as the symbol record may grow the size of the record union and effect the memory footprint for unresolved symbols.

    Comment 7
    1. Chris Johns, Sat, 04 May 2019 02:22:01 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In b36c5209/rtems:

    libdl: Do not access the ELF file while the allocator is locked. Load symbols before allocation. Parse reloc records and place any reloc recs in a cache to use while the allocator is locked. Relocate symbols after section allocation. Split section loading into allocation/locating and loading. Update all arch back-ends with a new reloc interface to control tramp handling. Add -a and -t to the object list shell command. Closes #3741

    3742 - T_config conflicting type qualifiers for 'config'

    Link https://devel.rtems.org/ticket/3742
    Id 3742
    Reporter Chris Johns
    Created 4 May 2019 02:20:37
    Modified 6 May 2019 05:57:55
    Owner joel@…
    Type defect
    Component test
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Running the rtems-bsp-builder on FreeBSD is give an error in ttest01 for bsps:

    • arm/csb336
    • arm/csb337
    • arm/csb637
    • arm/kit637_v6
    • mips/csb350

    The error being reported is:

    error: testsuites/libtests/ttest01/init.c:146:23: error: conflicting type qualifiers for 'config' 

    The builder command line is:

    /opt/work/chris/rtems/rt/rtems-tools.git/tester/rtems-bsp-builder \
    --rtems-tools=/opt/work/rtems/5 \
    --rtems=/opt/work/chris/rtems/kernel/rtems.git \
    --log=everything-tests \
    --profile=everything \
    --build=tests \
    --jobs=7/6

    A BSP configure command line is:

    /opt/work/chris/rtems/kernel/rtems.git/configure \
    --target=mips-rtems5 --enable-rtemsbsp=csb350 --prefix=/opt/rtems/5 \
    --enable-tests --disable-smp
    Comment 1
    1. Sebastian Huber, Mon, 06 May 2019 05:57:55 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    In 8bd4f61c/rtems:

    bsps: Remove bogus config declaration Replace it with a proper struct rtems_bsdnet_ifconfig forward declaration. Close #3742.

    3743 - RSB os and arch config logic is broken

    Link https://devel.rtems.org/ticket/3743
    Id 3743
    Reporter Chris Johns
    Created 6 May 2019 23:13:46
    Modified 10 May 2019 02:44:45
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The config file processing of conditionals:

    • %ifos
    • %ifnos
    • %ifarch

    do not correctly process lists of arguments. The argument list is split in 2 with the first element correct handled and the remaining treated as a lump. The argument list needs to be split evenly.

    Comment 1
    1. Chris Johns, Fri, 10 May 2019 02:44:45 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 0956a2c/rtems-source-builder:

    sb/config: Fix os and arch conditional logic. Correctly split the argument list and check each element. Closes #3743

    3746 - libdl test dl05.exe failing

    Link https://devel.rtems.org/ticket/3746
    Id 3746
    Reporter Chris Johns
    Created 13 May 2019 00:17:57
    Modified 14 May 2019 00:19:54
    Owner Chris Johns <chrisj@…>
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3745
    Blocked by  

    Description

    This test is failing because the second stage of the symbol loading does not check if a section referenced by a symbol has been loaded.

    It is not clear yet if the lack of support in libdl for group sections is a factor.

    Comment 1
    1. Chris Johns, Mon, 13 May 2019 22:57:17 GMT
    2. owner: set to Chris Johns <chrisj@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 74883be5/rtems:

    libdl: Fix loading symbol that reference unknown sections. Make the symbol parsing and loading stage match. Check for possible overflow of the tables when loading. Closes #3746
    Comment 2
    1. Chris Johns, Tue, 14 May 2019 00:19:54 GMT

    In d0f627d/rtems:

    libdl: Fix size bug in loading symbols. This was introduced in 74883be5d4b5fa166179d6003032f6eac2e0f544. Updates #3746

    3747 - Address Cortex-M3 Errata 602117

    Link https://devel.rtems.org/ticket/3747
    Id 3747
    Reporter Sebastian Huber
    Created 13 May 2019 13:23:15
    Modified 21 May 2019 04:44:10
    Owner Sebastian Huber
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    While testing on a NXP LPC1788 it found that this chip is affected by the Cortex-M3 Errata 602117. NXP didn't bother to document this in their errata sheet for the chip:

    ​https://www.nxp.com/docs/en/errata/ES_LPC177X_8X.pdf

    To avoid the issues, you have to compile everything with -mfix-cortex-m3-ldrd. This option is enabled by default, if you use -mcpu=cortex-m3.

    I think we have to change our GCC multilibs to account for this errata. For example:

    diff --git a/gcc/config/arm/t-rtems b/gcc/config/arm/t-rtems
    index 026a5895662..e276b4f3e57 100644
    --- a/gcc/config/arm/t-rtems
    +++ b/gcc/config/arm/t-rtems
    @@ -1,7 +1,7 @@
    # Custom RTEMS multilibs for ARM
    -MULTILIB_OPTIONS = mbig-endian mthumb march=armv6-m/march=armv7-a/march=armv7-r/march=armv7-m/mcpu=cortex-m7 mfpu=neon/mfpu=vfp/mfpu=vfpv3-d16/mfpu=fpv4-sp-d16/mfpu=fpv5-d16 mfloat-abi=hard
    -MULTILIB_DIRNAMES = eb thumb armv6-m armv7-a armv7-r armv7-m cortex-m7 neon vfp vfpv3-d16 fpv4-sp-d16 fpv5-d16 hard
    +MULTILIB_OPTIONS = mbig-endian mthumb march=armv6-m/march=armv7-a/march=armv7-r/mcpu=cortex-m3/mcpu=cortex-m4/mcpu=cortex-m7 mfpu=neon/mfpu=vfp/mfpu=vfpv3-d16/mfpu=fpv4-sp-d16/mfpu=fpv5-d16 mfloat-abi=hard
    +MULTILIB_DIRNAMES = eb thumb armv6-m armv7-a armv7-r cortex-m3 cortex-m4 cortex-m7 neon vfp vfpv3-d16 fpv4-sp-d16 fpv5-d16 hard
    # Enumeration of multilibs
    @@ -16,7 +16,8 @@ MULTILIB_REQUIRED += mthumb/march=armv7-a/mfpu=neon/mfloat-abi=hard
    MULTILIB_REQUIRED += mthumb/march=armv7-a
    MULTILIB_REQUIRED += mthumb/march=armv7-r/mfpu=vfpv3-d16/mfloat-abi=hard
    MULTILIB_REQUIRED += mthumb/march=armv7-r
    -MULTILIB_REQUIRED += mthumb/march=armv7-m/mfpu=fpv4-sp-d16/mfloat-abi=hard
    +MULTILIB_REQUIRED += mthumb/mcpu=cortex-m3
    +MULTILIB_REQUIRED += mthumb/mcpu=cortex-m4
    +MULTILIB_REQUIRED += mthumb/mcpu=cortex-m4/mfpu=fpv4-sp-d16/mfloat-abi=hard
    MULTILIB_REQUIRED += mthumb/mcpu=cortex-m7/mfpu=fpv5-d16/mfloat-abi=hard
    -MULTILIB_REQUIRED += mthumb/march=armv7-m
    MULTILIB_REQUIRED += mthumb
    Comment 1
    1. Sebastian Huber, Tue, 14 May 2019 06:56:12 GMT

    In 72271f6/rtems-source-builder:

    5: Update GCC 7 baseline Pick up ARM multilib changes to address Cortex-M3 Errata 602117. Update #3747.
    Comment 2
    1. Sebastian Huber, Tue, 14 May 2019 09:08:23 GMT

    In b446457/rtems:

    bsps/arm: Adjust machine flags for ARMv7-M Update machine flags for Cortex-M3 and Cortex-M4 based BSPs to account for Cortex-M3 Errata 602117 which required GCC multilib changes. Update #3747.
    Comment 3
    1. Sebastian Huber, Wed, 15 May 2019 05:21:31 GMT

    In 7f51440/rtems-docs:

    cpu-supplement: Update ARM multilibs Update #3747.
    Comment 4
    1. Sebastian Huber, Tue, 21 May 2019 04:44:10 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    The GCC multilib changes are now in GCC 7, 8, 9 and trunk (10).


    3748 - libdl uses a linear symbol search on object file symbols

    Link https://devel.rtems.org/ticket/3748
    Id 3748
    Reporter Chris Johns
    Created 14 May 2019 00:32:24
    Modified 22 May 2019 00:03:14
    Owner Chris Johns <chrisj@…>
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Symbol searching has two parts, searching the object file and searching the global symbol table. Currently the object file search is linear and the global table search uses a hash table.

    A large incrementally linked object file can have a large local and global set of symbols and this can slow the loading process. This issue does not show up for small object files with a few symbols which is typically how our libraries are made.

    Change the object file symbol search to a binary search (bsearch). A hash table for each object file would increase the in memory object file footprint by a significant amount and would harm the small object file use case that only have a few symbols. A binary search is a suitable compromise.

    Comment 1
    1. Chris Johns, Wed, 22 May 2019 00:03:14 GMT
    2. owner: set to Chris Johns <chrisj@…>
    3. status: changed from assigned to closed
    4. resolution: set to fixed

    In 327e45da/rtems:

    libdl: Sort object file symbols and use a binary search to find Replace the linear object file symbol search with a binary search. Sort the object file symbols after loading. Closes #3748

    3751 - No documentation on Region Get Information Directives

    Link https://devel.rtems.org/ticket/3751
    Id 3751
    Reporter Joel Sherrill
    Created 20 May 2019 22:29:14
    Modified 12 December 2019 22:07:25
    Owner Joel Sherrill <joel@…>
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords classic, region
    Cc  
    Blocking  
    Blocked by  

    Description

    rtems_region_get_information and rtems_region_get_free_information are not documented in the Classic API Users Guide. They have been present since at least 4.6 and should be documented.

    Comment 1
    1. Joel Sherrill, Thu, 12 Dec 2019 22:07:25 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 43e0d78/rtems-docs:

    region_manager.rst: Add docs for region get info and get free info closes #3751.

    3753 - Rename CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS

    Link https://devel.rtems.org/ticket/3753
    Id 3753
    Reporter Joel Sherrill
    Created 21 May 2019 15:43:26
    Modified 19 December 2019 07:57:47
    Owner Sebastian Huber <sebastian.huber@…>
    Type defect
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS probably should not mention LIBIO as that is an internal component/organization aid which should not be visible to the user.

    This ticket is to discuss renaming CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS to just CONFIGURE_MAXIMUM_FILE_DESCRIPTORS.

    Perhaps deprecate now and obsolete in next major version. Include code to warn and map old name to new.

    Thoughts?

    Comment 1
    1. Sebastian Huber, Wed, 22 May 2019 05:45:29 GMT

    I like CONFIGURE_MAXIMUM_FILE_DESCRIPTORS better, however, do we really want to tinker with this configuration option which is used probably in hundreds of application configurations? It will probably force users to do something like this

    #if RTEMS_VERSION >= 5
    `#define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS X`
    `#else`
    `#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS X`
    `#endif 
    `
    Comment 2
    1. Chris Johns, Thu, 12 Dec 2019 23:30:31 GMT

    Sebastian, can this be worked on while you are playing with the config?

    Comment 3
    1. Sebastian Huber, Fri, 13 Dec 2019 06:04:11 GMT

    Yes, I work on this. I hope to finish the configuration related stuff by end of next week.

    Comment 4
    1. Sebastian Huber, Thu, 19 Dec 2019 07:55:54 GMT

    In 3cec2df/rtems:

    config: CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS Rename CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS into CONFIGURE_MAXIMUM_FILE_DESCRIPTORS. Update #3753.
    Comment 5
    1. Sebastian Huber, Thu, 19 Dec 2019 07:57:47 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 2c58b5f/rtems-docs:

    c-user: CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS Rename CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS in CONFIGURE_MAXIMUM_FILE_DESCRIPTORS. Close #3753.

    3754 - Users Guide Ubuntu Instructions Have Typo

    Link https://devel.rtems.org/ticket/3754
    Id 3754
    Reporter Joel Sherrill
    Created 3 June 2019 16:19:42
    Modified 15 August 2019 21:04:38
    Owner Joel Sherrill
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    sudu should be sudo

    Comment 1
    1. Joel Sherrill, Mon, 03 Jun 2019 16:21:34 GMT
    2. description: modified (diff)
    Comment 2
    1. Joel Sherrill, Thu, 15 Aug 2019 21:04:38 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 13baaca/rtems-docs:

    hosts/posix.rst: Fix typo of sudu to sudo Closes #3754.

    3756 - Condition codes in PSR are destroyed by lazy FP context switch

    Link https://devel.rtems.org/ticket/3756
    Id 3756
    Reporter Sebastian Huber
    Created 6 June 2019 06:37:59
    Modified 6 June 2019 06:41:41
    Owner Sebastian Huber
    Type defect
    Component arch/sparc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    ​https://lists.rtems.org/pipermail/devel/2019-June/026014.html

    Comment 1
    1. Sebastian Huber, Thu, 06 Jun 2019 06:41:38 GMT

    In 7d7cbf3c/rtems:

    sparc: Improve _CPU_Context_validate() Use the FPU and check that the condition codes in the PSR are preserved. Update #3756.
    Comment 2
    1. Maksim E. Kozlov, Thu, 06 Jun 2019 06:41:41 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a3818705/rtems:

    sparc: Fix missed restoring of PSR in syscall_lazy_fp_switch It is needed to restore PSR just before return because condition codes are dirty after the CMP instructions and this may cause undefined program behavior after returning from the switching procedure (on following branch instruction, for example). Close #3756.

    3760 - BBB MMU update crashes

    Link https://devel.rtems.org/ticket/3760
    Id 3760
    Reporter Chris Johns
    Created 17 June 2019 02:46:24
    Modified 12 August 2019 23:01:20
    Owner Chris Johns <chrisj@…>
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Calling arm_cp15_set_translation_table_entries() on a BBB (Cortex-A8) crashes in the call to arm_cp15_tlb_invalidate_entry_all_asids(). There is no HYP support in the BBB's A8. The cp15 register is documented in the A8 manual but the BBB device from TI does not have the support built in.

    A check of the A8 doco from ARM says this is for use in HYP mode so should we be using without checking if HYP is supported and if it is active? I am also wondering if we use should be using it on the Zynq. I have no idea why the Zync (A9) does not complain, it may be ignoring the invalidate request.

    While looking at this code I was wondering why we do not follow ARM's recommendation of 'break-make' updates of the TLB? I do not know we could support such a process because we may be asked to invalidate the entry for the text section we are running in to update it.

    Note, following the other path in the call works on a BBB.

    Comment 1
    1. Chris Johns, Tue, 25 Jun 2019 10:08:06 GMT

    The implementation is:

    ARM_CP15_TEXT_SECTION static inline void
    arm_cp15_tlb_invalidate_entry_all_asids(const void *mva)
    {
      ARM_SWITCH_REGISTERS;
      mva = ARM_CP15_TLB_PREPARE_MVA(mva);
      __asm__ volatile (
        ARM_SWITCH_TO_ARM
        "mcr p15, 0, %[mva], c8, c7, 3\n"
        ARM_SWITCH_BACK
        : ARM_SWITCH_OUTPUT
        : [mva] "r" (mva)
      );
    } 

    The cp15 register c8, 0, c7, 3 is undefined for a Cortex-A8 (ARM's document DDI0334K p3-12). The conditional define in arm_cp15_set_translation_table_entries catches the Cortex-A8.

    Comment 2
    1. Sebastian Huber, Tue, 25 Jun 2019 10:42:44 GMT

    Can the availability checked via a feature register at runtime?

    Comment 3
    1. Chris Johns, Tue, 25 Jun 2019 10:44:49 GMT

    Replying to Sebastian Huber:

    Can the availability checked via a feature register at runtime?

    Yes I think so. The test can be for variant 3 or earlier for the Cortex-A8 and 4 or higher for Cortex-A9 or later.

    Comment 4
    1. Chris Johns, Tue, 30 Jul 2019 22:38:00 GMT
    2. owner: set to Chris Johns <chrisj@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 98d6792/rtems:

    arm: Select the TLB invalidate based on the core's Id variant. Closes #3760
    Comment 5
    1. Chris Johns, Mon, 12 Aug 2019 23:01:20 GMT

    In 15b6f44d/rtems:

    arm/tlb: Fix the MP affinity check to invalidate ASIDs. The TI's CortexA7 MP MPIDR register returns 0 Updates #3760

    3762 - Return the current handler from ARM cp15 set exception call

    Link https://devel.rtems.org/ticket/3762
    Id 3762
    Reporter Chris Johns
    Created 25 June 2019 08:39:58
    Modified 27 June 2019 23:04:23
    Owner Chris Johns
    Type enhancement
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Update the cp15 call arm_cp15_set_exception_handler() to return the current handler. This lets code catch and return an exception handler, for example code to probe suspect hardware.

    This is need to probe the memory map debug registers for debug v7 implementations.

    Comment 1
    1. Chris Johns, Thu, 27 Jun 2019 23:04:23 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In c43071f/rtems:

    arm: Return the current handler from arm_cp15_set_exception_handler Closes #3762

    3763 - RSB SIS build fails on FreeBSD

    Link https://devel.rtems.org/ticket/3763
    Id 3763
    Reporter Chris Johns
    Created 26 June 2019 22:36:11
    Modified 24 July 2019 05:01:30
    Owner Chris Johns <chrisj@…>
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The RSB SIS build for RISCV fails on FreeBSD with:

    + CFLAGS='-O2 -pipe -fbracket-depth=1024 -I/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-chris/5/rtems-sis/opt/work/rtems/5/include ' ./configure '--build=x86_64-freebsd12.0' '--host=x86_64-freebsd12.0' '--program-prefix=sis-rtems5-' '--prefix='
    checking for a BSD-compatible install... /usr/bin/install -c
    checking whether build environment is sane... yes
    checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
    checking for gawk... no
    checking for mawk... no
    checking for nawk... nawk
    checking whether make sets $(MAKE)... yes
    checking for x86_64-freebsd12.0-gcc... /usr/bin/cc -O2 -pipe -fbracket-depth=1024 -I/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-chris/5/rtems-sis/opt/work/rtems/5/include
    checking whether the C compiler works... yes
    checking for C compiler default output file name... a.out
    checking for suffix of executables...
    checking whether we are cross compiling... no
    checking for suffix of object files... o
    checking whether we are using the GNU C compiler... yes
    checking whether /usr/bin/cc -O2 -pipe -fbracket-depth=1024 -I/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-chris/5/rtems-sis/opt/work/rtems/5/include accepts -g... yes
    checking for /usr/bin/cc -O2 -pipe -fbracket-depth=1024 -I/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-chris/5/rtems-sis/opt/work/rtems/5/include option to accept ISO C89... none needed
    checking for style of include used by make... GNU
    checking dependency style of /usr/bin/cc -O2 -pipe -fbracket-depth=1024 -I/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-chris/5/rtems-sis/opt/work/rtems/5/include... gcc3
    checking how to run the C preprocessor... /usr/bin/cc -O2 -pipe -fbracket-depth=1024 -I/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-chris/5/rtems-sis/opt/work/rtems/5/include -E
    checking for grep that handles long lines and -e... /usr/bin/grep
    checking for egrep... /usr/bin/grep -E
    checking for ANSI C header files... yes
    checking for sys/types.h... yes
    checking for sys/stat.h... yes
    checking for stdlib.h... yes
    checking for string.h... yes
    checking for memory.h... yes
    checking for strings.h... yes
    checking for inttypes.h... yes
    checking for stdint.h... yes
    checking for unistd.h... yes
    checking fcntl.h usability... yes
    checking fcntl.h presence... yes
    checking for fcntl.h... yes
    checking stddef.h usability... yes
    checking stddef.h presence... yes
    checking for stddef.h... yes
    checking for stdlib.h... (cached) yes
    checking for string.h... (cached) yes
    checking sys/time.h usability... yes
    checking sys/time.h presence... yes
    checking for sys/time.h... yes
    checking for unistd.h... (cached) yes
    checking termios.h usability... yes
    checking termios.h presence... yes
    checking for termios.h... yes
    checking for readline in -lreadline... no
    configure: error: the required "readline" library is missing
    Comment 1
    1. Chris Johns, Wed, 24 Jul 2019 05:01:30 GMT
    2. owner: set to Chris Johns <chrisj@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 5eb4282/rtems-source-builder:

    devel/sis: Fix building the SIS on FreeBSD Update to SIS 2.17 which has internal readline support for the hosts which do not have readline. Closes #3763

    3768 - Add staging support to Makefile.inc

    Link https://devel.rtems.org/ticket/3768
    Id 3768
    Reporter Chris Johns
    Created 19 July 2019 07:52:06
    Modified 21 July 2019 22:20:20
    Owner Chris Johns
    Type enhancement
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add support to allow staging of an RTEMS BSP build so dependent packages can be built in a single RBS buildset build.

    Comment 1
    1. Chris Johns, Sun, 21 Jul 2019 22:20:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 270c5df5/rtems:

    Makefile.inc: Add support for staged builds. Allow the RTEMS_ROOT to be conditionally supplied. This can be a staging area before being moved to the final install prefix location. Update the default.cfg to use RTEMS_ROOT and to not rely on the exec_prefix so it's paths can be staged. Fix and add the needed configure subs. Closes #3768

    3769 - RSB BSP Buildsets

    Link https://devel.rtems.org/ticket/3769
    Id 3769
    Reporter Chris Johns
    Created 21 July 2019 22:29:18
    Modified 22 July 2019 21:58:10
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add support to the RSB for BSP build sets. The support includes building 3rd party packages for a BSP.

  • Add BSP buildset support
  • Build packages for a BSP
  • Stage buildset builds if not the outer build so dependent packages and be built before a package and used
  • Fix packages to support staged builds
  • Comment 1
    1. Chris Johns, Mon, 22 Jul 2019 21:58:10 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 831ae05/rtems-source-builder:

    rtems/bsp: Build packages for the beagle BSP. Closes #3769

    3770 - RSB 3rd party packages failing to build

    Link https://devel.rtems.org/ticket/3770
    Id 3770
    Reporter Chris Johns
    Created 21 July 2019 22:40:55
    Modified 12 December 2019 17:05:47
    Owner  
    Type defect
    Component tool/rsb
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The following packages do not build or have issues and will be removed if they are not updated:

  • ntp
  • microwindows
  • nxlib
  • lwip
  • The lwip patch used by this package needs to be updated. The install target for the Makefile does not support DESTDIR and cannot be staged. It is being built however a lack of DESTDIR is not compatible with the requirements of the RSB for staged builds. The package installs directly to the prefix which is not suppose to happen.

    The packages will need to be fixed or removed before 5.1. There is no point releasing the RSB with packages that are broken.

    Comment 1
    1. Chris Johns, Thu, 12 Dec 2019 17:05:47 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    I am going to close this ticket and these packages will not be available with the RSB. With no RSB support I do not know who builds these packages and if they are valid?


    3773 - RPi fails to boot

    Link https://devel.rtems.org/ticket/3773
    Id 3773
    Reporter Chris Johns
    Created 26 July 2019 00:31:57
    Modified 26 July 2019 07:25:32
    Owner Chris Johns
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The RPi BSP fails to boot with the current master. A bsect of the repo shows the failure appears after this change [bdec62c4/rtems].

    Comment 1
    1. Sebastian Huber, Fri, 26 Jul 2019 07:25:25 GMT

    In 0f5c1d53/rtems:

    bsps/arm: Remove register init for ARMv7-M There are no known ARMv7-M chips with a dual lockstep mode. Update #3773.
    Comment 2
    1. Sebastian Huber, Fri, 26 Jul 2019 07:25:28 GMT

    In 0ee2125/rtems:

    bsps/arm: Move register init to start.S This makes it easier to review changes in start.S. Update #3773.
    Comment 3
    1. Sebastian Huber, Fri, 26 Jul 2019 07:25:32 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 1e6380b/rtems:

    bsps/arm: Move HYP to SVC change to start.S This fixes the corruption of r3 by the call to bsp_start_arm_drop_hyp_mode(). Moving the code makes it easier to review changes in start.S. Close #3773.

    3774 - RPi2 SMP does not build

    Link https://devel.rtems.org/ticket/3774
    Id 3774
    Reporter Chris Johns
    Created 27 July 2019 00:28:09
    Modified 30 July 2019 09:03:30
    Owner Sebastian Huber <sebastian.huber@…>
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity major
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    arm-rtems5-gcc  -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a7 -O1 -g -ffunction-sections -fdata-sections -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -B./../../lib/libbsp/arm/raspberrypi -B/opt/work/chris/rtems/kernel/rtems.git/bsps/arm/raspberrypi/start -specs bsp_specs -qrtems -L./../../cpukit -L/opt/work/chris/rtems/kernel/rtems.git/bsps/arm/shared/start -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -Wl,--gc-sections -o calloc.norun.exe POSIX/calloc.o ./../../cpukit/librtemsdefaultconfig.a ./../../lib/libbsp/arm/raspberrypi/librtemsbsp.a ./../../cpukit/librtemscpu.a ./../../cpukit/librtemstest.a
    /opt/work/rtems/5/lib/gcc/arm-rtems5/7.4.0/../../../../arm-rtems5/bin/ld: calloc.norun.exe section `.rtemsstack' will not fit in region `VECTOR_RAM'
    /opt/work/rtems/5/lib/gcc/arm-rtems5/7.4.0/../../../../arm-rtems5/bin/ld: section .start VMA [0000000000008000,00000000000085ff] overlaps section .rtemsstack VMA [0000000000000040,000000000002003f]
    /opt/work/rtems/5/lib/gcc/arm-rtems5/7.4.0/../../../../arm-rtems5/bin/ld: region `VECTOR_RAM' overflowed by 114752 bytes

    Configured with ...

    /opt/work/chris/rtems/kernel/rtems.git/configure --target=arm-rtems5 --prefix=/opt/work/chris/rtems/kernel/5 --disable-networking --enable-maintainer-mode --enable-rtems-debug --enable-tests --enable-rtemsbsp=raspberrypi2 --enable-smp 
    Comment 1
    1. Sebastian Huber, Tue, 30 Jul 2019 09:03:30 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In c5fd79cd/rtems:

    arm/raspberrypi: Fix linker map Add NULL-pointer protection. Make MMU table read-only. Move vector table to start section. Close #3774.

    3775 - libdl does not handle ARM mode reloc tramp parsing

    Link https://devel.rtems.org/ticket/3775
    Id 3775
    Reporter Chris Johns
    Created 27 July 2019 23:13:30
    Modified 27 July 2019 23:17:12
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The BBB fails on libdl tests because the trampoline parsing of reloc records does not handle the ABS type relocs when the code is built in ARM mode.

    Comment 1
    1. Chris Johns, Sat, 27 Jul 2019 23:17:12 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 5a678de/rtems:

    libdl/arm: Fix ARM mode trampoline parsing of relocs No need to dump globals syms in test dl01 when tracing Closes #3775

    3776 - libdl ARM does not support ARM mode trampolines.

    Link https://devel.rtems.org/ticket/3776
    Id 3776
    Reporter Chris Johns
    Created 28 July 2019 04:55:42
    Modified 4 August 2019 02:36:16
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The BBB is ARM mode and crashes dl09.exe. This is due to only Thumb mode trampoline support.

    Comment 1
    1. Chris Johns, Sun, 04 Aug 2019 02:36:16 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 8c66acc8/rtems:

    libdl/arm: Add support for ARM trampolines Closes #3776

    3777 - libdl object unload debugger delete support is broken

    Link https://devel.rtems.org/ticket/3777
    Id 3777
    Reporter Chris Johns
    Created 4 August 2019 05:14:30
    Modified 11 August 2019 22:53:16
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The test dl09.exe crashes on BBB, Zedboard, and RPi2 but runs on arm qemu and psim. The issue is uncovered by the heap protection support in free() where the free block has been touched.

    It turns out _rtld_linkmap_delete() list code is broken. The object module's block should not be walked to the end.

    Comment 1
    1. Chris Johns, Sun, 11 Aug 2019 22:53:16 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 9cb19ded/rtems:

    libdl/debugger: Fix the broken list delete when unloading an object module. Closes #3777

    3781 - RSB crashes in case the host as an unreadable directory in "/"

    Link https://devel.rtems.org/ticket/3781
    Id 3781
    Reporter Sebastian Huber
    Created 9 August 2019 10:42:57
    Modified 3 December 2019 05:53:07
    Owner Sebastian Huber
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    butrfeld@elektra:~/rtemsSMP/src/rsb/rtems$ ../source-builder/sb-set-builder --source-only-download 5/rtems-sparc
    RTEMS Source Builder - Set Builder, 5 (29fab0500e22)
    Traceback (most recent call last):
    File "../source-builder/sb/cmd-set-builder.py", line 26, in
    setbuilder.run()
    File "/users/staff/butrfeld/rtemsSMP/src/rsb/source-builder/sb/setbuilder.py", line 674, in run
    if not check.host_setup(opts):
    File "/users/staff/butrfeld/rtemsSMP/src/rsb/source-builder/sb/check.py", line 127, in host_setup
    if not path_check(opts):
    File "/users/staff/butrfeld/rtemsSMP/src/rsb/source-builder/sb/check.py", line 115, in path_check
    elif not path.exists(p):
    File "/users/staff/butrfeld/rtemsSMP/src/rsb/source-builder/sb/path.py", line 131, in exists
    return _exists(shell(paths))
    File "/users/staff/butrfeld/rtemsSMP/src/rsb/source-builder/sb/path.py", line 124, in _exists
    return basename(p) in ['.'] + listdir(dirname(p))
    File "/users/staff/butrfeld/rtemsSMP/src/rsb/source-builder/sb/path.py", line 118, in listdir
    return os.listdir(hp)
    OSError: [Errno 13] Permission denied: '/adm'

    The root directory "/" looks like this:

    butrfeld@elektra:/$ ls -ls
    total 89
    4 drwxr-x---+ 6 root root 4096 Nov 5 2018 adm
    4 drwxr-xr-x 2 root root 4096 Apr 10 06:17 bin
    Comment 1
    1. Sebastian Huber, Fri, 09 Aug 2019 10:49:09 GMT

    In source-builder/sb/check.py:

    def path_check(opts, silent = False):
        if 'PATH' in os.environ:
            paths = os.environ['PATH'].split(os.pathsep)
            for p in paths:
                if len(p.strip()) == 0:
                    if not silent:
                        log.notice('error: environment PATH contains an empty path')
                    return False
                elif not options.host_windows and (p.strip() == '.' or p.strip() == '..'):
                    if not silent:
                        log.notice('error: environment PATH invalid path: %s' % (p))
                    return False
                elif not path.exists(p):
                    if not silent and opts.warn_all():
                        log.notice('warning: environment PATH not found: %s' % (p))
                elif not path.isdir(p):
                    if not silent and opts.warn_all():
                        log.notice('warning: environment PATH not a directory: %s' % (p))
        return True 

    The path.exists() seems to be rather complicated, why is it necessary in addition to path.isdir()? What is the overall goal of this check? Is it not the responsibility of the user to take care of his $PATH variable?

    Comment 2
    1. Sebastian Huber, Wed, 27 Nov 2019 13:52:12 GMT

    This bug is still open. It is a show stopper on some systems.

    Comment 3
    1. Sebastian Huber, Wed, 27 Nov 2019 13:55:58 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to accepted

    I suggest to remove this check. I think the RSB tries to be smarter than necessary here.

    Comment 4
    1. Sebastian Huber, Fri, 29 Nov 2019 06:34:35 GMT

    I am not sure if these hard errors are really useful, e.g.

    $ export PATH=::$PATH
    $ ./source-builder/sb-set-builder --prefix=/build/rtems/5 5/rtems-arm --source-only-download
    RTEMS Source Builder - Set Builder, 5 (f3b44b25d135)
    error: environment PATH contains an empty path
    error: host build environment is not set up correctly
    Build FAILED 

    Why don't we just issue a warning? If something goes wrong the warning will show up in the logs.

    Comment 5
    1. Chris Johns, Sun, 01 Dec 2019 23:14:09 GMT

    I wonder how many issues have been fixed by having this check present that users cleaned up?

    If we remove this test and we get no increase in issues then the test did nothing and our users all had clean environments. An increase means it did serve a purpose. I also think your point about the RSB nannying our users this way may be a step too far so making the tests just warnings and no fatal would be a good compromise. It would let us request the output with debugging a specific user problem.

    Comment 6
    1. Sebastian Huber, Mon, 02 Dec 2019 08:48:07 GMT

    Nannying fits quite well. The empty path check is not superfluous. If I remove it, then RSB fails with:

    $ export PATH=::$PATH
    $ ../source-builder/sb-set-builder 5/rtems-arm --source-only-download
    error: unknown application load error
    error: unknown application load error 
    Comment 7
    1. Sebastian Huber, Tue, 03 Dec 2019 05:53:07 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 784f518/rtems-source-builder:

    Be more resilient against $PATH errors Close #3781.

    3783 - MSYS2 RSB build error

    Link https://devel.rtems.org/ticket/3783
    Id 3783
    Reporter jameszxj
    Created 12 August 2019 07:55:10
    Modified 9 September 2019 14:31:06
    Owner  
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I tried to update the compiler to RSB master, and encountered an error.
    command line:

    ../source-builder/sb-set-builder --dry-run --with-download 5/rtems-arm

    error messgae:

    config: tools/rtems-gdb-8.2.1-1.cfg
    error: shell macro failed: sh -c "/mingw64/bin/python2-config --ldflags | awk 'BEGIN{FS=" "}/python/{for(i=1;iBuild FAILED
    Build Set: Time 0:00:47.324763
    Build FAILED __

    Attachments:

    1 jameszxj, Mon, 12 Aug 2019 07:57:03 GMT
      attach: set to errmsg.png
    Comment 1
    1. jameszxj, Mon, 09 Sep 2019 14:31:06 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    This error is the same as #3972, #3972 has been fixed.


    3785 - Add RISC-V BSP with support for the Freedom E310 Arty A7 FPGA

    Link https://devel.rtems.org/ticket/3785
    Id 3785
    Reporter pragnesh
    Created 16 August 2019 10:26:44
    Modified 16 April 2020 23:47:04
    Owner  
    Type task
    Component arch/riscv
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords #RISCV, #FREEDOME310, #ARTYA7
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Joel Sherrill, Fri, 16 Aug 2019 13:25:22 GMT

    Please update the description of this ticket to clarify. My questions include:

    Are you planning to submit a BSP variant for this or are you asking for one? Either way please link to the hardware, manuals, etc.
    Comment 2
    1. pragnesh, Fri, 16 Aug 2019 13:38:55 GMT

    Replying to Joel Sherrill:

    Please update the description of this ticket to clarify. My questions include:

    Are you planning to submit a BSP variant for this or are you asking for one? Either way please link to the hardware, manuals, etc.

    1) Are you planning to submit a BSP variant for this or are you asking for one?

    I have already sent a patch for this new BSP varient (Freedom E310) to devel@ rtems.org, I created this ticket so that i can give reference in the commit message. i followed this ​https://docs.rtems.org/branches/master/user/support/contrib.html

    Let me know, Is this a right procedure to submit a patch?

    2) Either way please link to the hardware, manuals, etc.

    I will update the same in description.

    Comment 3
    1. pragnesh, Mon, 19 Aug 2019 08:59:01 GMT

    Link for the hardware and manuals

    ​https://www.sifive.com/documentation (Freedom FE310-G002 Manual) ​https://www.digikey.com/eewiki/display/LOGIC/Digilent+Arty+A7+with+Xilinx+Artix-7+Implementing+SiFive+FE310+RISC-V ​https://sifive.cdn.prismic.io/sifive%2Fed96de35-065f-474c-a432-9f6a364af9c8_sifive-e310-arty-gettingstarted-v1.0.6.pdf
    Comment 4
    1. Pragnesh Patel, Wed, 23 Oct 2019 06:12:46 GMT

    In a7f5e42c/rtems:

    riscv: add freedom E310 Arty A7 bsp Added support for Sifive Freedom FE310 soc on Arty A7 FPGA board. Update #3785. Signed-off-by: Pragnesh Patel
    Comment 5
    1. Sebastian Huber, Thu, 14 Nov 2019 10:49:33 GMT

    In df9426f/rtems:

    bsp/riscv: riscv_get_core_frequency() Always provide this function. Return 0 by default. Fix formatting. Simplify function. Update #3785.
    Comment 6
    1. Sebastian Huber, Thu, 14 Nov 2019 10:49:36 GMT

    In 5a1bc179/rtems:

    bsp/riscv: Remove bogus Automake conditional Update #3785.
    Comment 7
    1. Sebastian Huber, Thu, 14 Nov 2019 10:49:43 GMT

    In ae554670/rtems:

    bsp/riscv: Fix format and warnings Update #3785.
    Comment 8
    1. Pragnesh Patel, Fri, 29 Nov 2019 07:46:02 GMT

    In f0864b3/rtems-docs:

    user: Add frdme310arty BSP varient Signed-off-by: Pragnesh Patel Update #3785.
    Comment 9
    1. Joel Sherrill, Thu, 12 Dec 2019 17:19:47 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Closing. The BSP and user manual contents are merged. Thank you for submitting the BSP


    3789 - TMS570 applciation build error

    Link https://devel.rtems.org/ticket/3789
    Id 3789
    Reporter Andreas Werner
    Created 23 August 2019 08:47:26
    Modified 19 December 2019 10:00:52
    Owner Sebastian Huber
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    expected behaviour

    Build without errors and without runtime errors

    undesired behaviour

    bsp_start_hook_0_done is undefined
    CPACR Register is not setup

    target hardware

    Hercules Safety MCU development Kit TMS570 MCU

    toolchain version

    Modified GCC, binutils and gdb build script to build armeb compiler build with RTEMS Source Builder master(see patches for RTEMS Soucre Builder)
    I need a ARM Compiler with Big Endian Support as default for TMS570.

    configuration options for bsp

    ../rtems/configure '--prefix=[bsp path]/bsp/armeb-rtems5' '--host=arm-rtems5' '--target=arm-rtems5' '--enable-posix' '--enable-rtems-debug' '--disable-tests' '--disable-networking' '--enable-rtemsbsp=tms570ls3137_hdk' 'CC_FOR_TARGET=armeb-rtems5-gcc' 'CXX_FOR_TARGET=armeb-rtem5-gcc' 'AR=armeb-rtems5-ar' 'TMS570_USE_HWINIT_STARTUP=1'

    Test on master commit RTEMS (4a9a58ea8ad75248af5876c01ef654f9bc59c312)

    Bug Fix

    define simbol bsp_start_hook_0_done in start.S
    add if defined(ARM_ARCH_7R)
    see patches

    Comment 1
    1. Andreas Werner, Fri, 23 Aug 2019 08:51:44 GMT

    I can't upload Atachments the patches and files can be found under: ​https://www.cs.hs-rm.de/~werner/rtems/bugreport/

    Comment 2
    1. Sebastian Huber, Mon, 26 Aug 2019 05:57:34 GMT
    2. owner: set to Sebastian Huber
    3. status: changed from new to accepted
    4. component: changed from bsps to arch/arm
    5. milestone: set to 5.1

    The problem is triggered by the TMS570_USE_HWINIT_STARTUP=1 BSP option. In bspstarthooks-hwinit.c we have:

    #if 1
      /*
       * Do not depend on link register to be restored to
       * correct value from stack. If TCRAM self test is enabled
       * the all stack content is zeroed there.
       */
      bsp_start_hook_0_done();
    `#endif 

    Leading to:

    bsps/arm/tms570/start/bspstarthooks-hwinit.c:375: undefined reference to `bsp_start_hook_0_done' 
    `
    Comment 3
    1. Sebastian Huber, Thu, 19 Dec 2019 10:00:52 GMT
    2. status: changed from accepted to closed
    3. resolution: set to fixed

    In 2497da06/rtems:

    bsps/arm: Export bsp_start_hook_0_done Close #3789.

    3792 - RSB fails to build on MSYS2

    Link https://devel.rtems.org/ticket/3792
    Id 3792
    Reporter Jeff Mayes
    Created 5 September 2019 14:02:25
    Modified 6 September 2019 01:53:14
    Owner Chris Johns
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Fresh install of Windows 10, with updates. Then installed MSYS2 as instructed here: ​https://docs.rtems.org/branches/master/user/hosts/windows.html#msys2

    Fetched the RSB, and then tried to build rtems-sparc tools, like this…

    $ ../source-builder/sb-set-builder --prefix=/home/mayes/dev/rtems/5 5/rtems-sparc
    RTEMS Source Builder - Set Builder, 5 (b45df48a51bc)
    Build Set: 5/rtems-sparc
    Build Set: 5/rtems-autotools.bset
    Build Set: 5/rtems-autotools-internal.bset
    config: tools/rtems-autoconf-2.69-1.cfg



    config: devel/expat-2.1.0-1.cfg
    package: expat-2.1.0-x86_64-w64-mingw32-1
    building: expat-2.1.0-x86_64-w64-mingw32-1
    sizes: expat-2.1.0-x86_64-w64-mingw32-1: 9.229MB (installed: 2.037MB)
    cleaning: expat-2.1.0-x86_64-w64-mingw32-1
    reporting: devel/expat-2.1.0-1.cfg -> expat-2.1.0-x86_64-w64-mingw32-1.txt
    reporting: devel/expat-2.1.0-1.cfg -> expat-2.1.0-x86_64-w64-mingw32-1.xml
    config: tools/rtems-gdb-8.3-1.cfg
    error: shell macro failed: sh -c "/mingw64/bin/python2-config --ldflags | awk 'BEGIN{FS=" "}/python/{for(i=1;iBuild FAILED
    Build Set: Time 0:07:19.564000
    Build FAILED __

    This happens when using Python3 and also when using Python2.

    Comment 1
    1. Chris Johns, Thu, 05 Sep 2019 23:24:07 GMT

    The issue is due to the shell command string containing " character that are not escaped. On MinGW these commands have to use the MSYS2 shell and not the host's shell which is some form of cmd.exe. The command to invoke the MSYS2 shell is ...

    ​https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/config.py#n430

    The wrapping of the string in "" effects the shell's processing.

    Comment 2
    1. Chris Johns, Thu, 05 Sep 2019 23:31:43 GMT

    The failing command on Windows is:

    sh -c "/mingw64/bin/python2-config --ldflags | awk 'BEGIN{FS=" "}/python/{for(i=1;i
    
    
    Comment 3
    1. Chris Johns, Fri, 06 Sep 2019 01:53:14 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d8b2719/rtems-source-builder:

    sb/config: Escape double quotes on Windows for shell macros Closes #3792

    3793 - trace record tool does not build on Windows

    Link https://devel.rtems.org/ticket/3793
    Id 3793
    Reporter Chris Johns
    Created 6 September 2019 01:59:33
    Modified 12 December 2019 16:56:09
    Owner  
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity major
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The error is:

    ../trace/record/record-main-lttng.c:32:10: fatal error: sys/queue.h: No such file or directory
    #include

    This is with the version the RSB is using

    Comment 1
    1. Chris Johns, Fri, 06 Sep 2019 02:15:05 GMT

    rtems-tools master is also broken ...

    Waf: Leaving directory `D:/opt/rtems/rtems-tools.git/build'
    ../trace/record/record-client-base.cc:30:10: fatal error: arpa/inet.h: No such file or directory
    `#include `
              ^~~~~~~~~~~~~
    compilation terminated.
    Build failed 
    Comment 2
    1. Chris Johns, Thu, 12 Dec 2019 16:53:04 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    Fixed.

    Comment 3
    1. Chris Johns, Thu, 12 Dec 2019 16:55:56 GMT
    2. status: changed from closed to reopened
    3. resolution: wontfix deleted

    Reopen to fix the close reason.

    Comment 4
    1. Chris Johns, Thu, 12 Dec 2019 16:56:09 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    3794 - Initial POSIX Signals Mask Incorrect

    Link https://devel.rtems.org/ticket/3794
    Id 3794
    Reporter Joel Sherrill
    Created 10 September 2019 17:53:23
    Modified 1 October 2019 07:16:54
    Owner Joel Sherrill
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords POSIX, signals, compliance
    Cc  
    Blocking  
    Blocked by  

    Description

    RTEMS initial signal mask for the "process" does not match the behavior of Linux, FreeBSD, and Cygwin.

    There are some subtle rules which need to be followed for the value of the created thread's signal mask. Because signals are part of C99 and enhanced by POSIX, both Classic API tasks and POSIX threads have to have them enabled.

  • Internal system threads should have no signals enabled. They have no business executing user signal handlers -- especially IDLE.
  • The initial signal mask for other threads needs to follow the implication of a pure C99 environment which only has the methods raise() and signal(). This implies that all signals are unmasked until the thread explicitly uses a POSIX methods to block some. This applies to both Classic tasks and POSIX threads created as initalization tasks/threads (e.g. before the system is up).
  • After the initial threads are created, the signal mask should be inherited from the creator. This can be done based on system state.
  • RTEMS behavior was incorrect by blocking all signals initially and for Classic API tasks.

    __Notes__:

    • The default signal mask does not matter for any application that does not use POSIX signals.
    • It is assumed that Classic API tasks should provide a compliant C run-time environment. Hence the defalt signal mask state matters.

    Impact on Applications and Tests
    ================================
    In general, an application should always explicitly block or unmask any signals that it intends to process. If there is concern about which thread may process it, then it should be blocked in all threads that are not intended to process it. The following code can be used to block all signals. This method can be used in the initialization task/thread to mimic historical behavior:

    static void block_all_signals(void)
    {
    int sc;
    sigset_t mask;
    sc = sigfillset( &mask );
    // check sc == 0
    sc = pthread_sigmask( SIG_BLOCK, &mask, NULL );
    // check sc == 0
    }
    Comment 1
    1. Joel Sherrill, Wed, 25 Sep 2019 19:52:37 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 8798372/rtems:

    Correct initial POSIX signals mask
    + Modify POSIX thread create extension to ensure expected
    initial signal mask is provided to system threads, initial tasks and threads, and inheritied by tasks and threads.
    + Adds psxsignal07 to verify functionality when using a POSIX
    Initialization thread and POSIX threads.
    + Adds psxsignal08 to verify functionality when using a Classic API
    Initialization task and Classic API tasks.
    Closes #3794.
    Comment 2
    1. Sebastian Huber, Tue, 01 Oct 2019 07:16:54 GMT

    In aeb981e/rtems:

    psxtests/psxualarm: Fix test failure Update #3794.

    3796 - docs/develenv directory structure bitrot

    Link https://devel.rtems.org/ticket/3796
    Id 3796
    Reporter Gedare Bloom
    Created 12 September 2019 04:38:01
    Modified 12 December 2019 23:04:10
    Owner Joel Sherrill <joel@…>
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The directory structure described in the Development Environment Guide is outdated and does not reflect changes made in relocating BSPs to the bsps/ directory and refactoring the include paths.

    Comment 1
    1. Joel Sherrill, Thu, 12 Dec 2019 23:04:10 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 2e3dc9f/rtems-docs:

    develenv/directory.rst: Update directory structure description closes #3796.

    3797 - Add LLVM as a package

    Link https://devel.rtems.org/ticket/3797
    Id 3797
    Reporter Chris Johns
    Created 14 September 2019 23:48:01
    Modified 12 December 2019 23:34:49
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add 5/rtems-llvm to build LLVM for supported hosts.

    This can used to help resolve the dependency the recent trace changes have created by using LLVM symbol/dwarf support.

    Comment 1
    1. Chris Johns, Thu, 12 Dec 2019 23:34:49 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3798 - Add sockatmark to libbsd

    Link https://devel.rtems.org/ticket/3798
    Id 3798
    Reporter Joel Sherrill
    Created 25 September 2019 17:05:00
    Modified 19 December 2019 09:52:34
    Owner Sebastian Huber
    Type enhancement
    Component network/libbsd
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords POSIX-Compliance
    Cc  
    Blocking  
    Blocked by  

    Description

    Now that pselect() is in libbsd, sockatmark() is the only method called out by any of the four POSIX profiles in the FACE Technical Standard (​http://opengroup.org/face) which is not provided by rtems-libbsd.

    Comment 1
    1. Sebastian Huber, Thu, 19 Dec 2019 09:52:34 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Ticket updates via commits didn't work.


    3800 - termios - Add Capability to Generate SIGINTR and SIGQUIT

    Link https://devel.rtems.org/ticket/3800
    Id 3800
    Reporter Joel Sherrill
    Created 2 October 2019 21:48:42
    Modified 7 May 2020 13:07:43
    Owner Joel Sherrill
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords termios, POSIX, EINTR
    Cc  
    Blocking  
    Blocked by  

    Description

    Currently the RTEMS termios implementation does not examine the ISIG setting in the termios attributes and thus does not examine input for the INTR (ctl-C) and QUIT (ctl-\) characters. As a consequence, it cannot return -1/EINTR.

    The proposed solution implements a point at which a default handler can do nothing like currently or the application can use the following new method which allows them to register the RTEMS provided method rtems_termios_posix_isig_handler().

    rtems_termios_isig_status_code rtems_termios_register_isig_handler(
    rtems_termios_isig_handler handler
    );

    The method rtems_termios_posix_isig_handler() is provided and has the POSIX compliant behavior of generating SIGINTR for the VINTR character and SIGQUIT for the VQUIT character.

    The user also can register rtems_termios_default_isig_handler() to return to the default behavior.

    The tests termios10 (polled IO) and termios11 (interrupt driven IO) are added to exercise this behavior.

    Comment 1
    1. Joel Sherrill, Mon, 07 Oct 2019 21:39:22 GMT
    2. keywords: EINTR added
    3. description: modified (diff)
    Comment 2
    1. Joel Sherrill, Wed, 09 Oct 2019 19:34:25 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 667501a/rtems:

    termios: Add Capability to Generate SIGINTR and SIGQUIT This patch adds the ability for termios to send SIGINTR on receipt of VINTR and SIGQUIT for VKILL and return -1/EINTR from read() on a termios channel. Importantly, this patch does not alter the default behavior or force POSIX signal code in just because termios is used. The application must explicitly enable the POSIX behavior of generating a signal upon receipt of these characters. This is discussed in the POSIX standard:
    ​https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html
    Closes #3800.
    Comment 3
    1. Sebastian Huber, Sat, 01 Feb 2020 14:03:08 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    The implementation breaks the canonical input mode as shown by test case termios09.

    Comment 4
    1. Sebastian Huber, Sat, 01 Feb 2020 14:11:27 GMT

    The implementation introduced a new enum:

    /**
     * @brief Type returned by all input processing (isig) methods
     */
    typedef enum {
      /**
       * This indicates that the input character was processed
       * and possibly placed into the buffer.
       */
      RTEMS_TERMIOS_ISIG_WAS_PROCESSED,
      /**
       * This indicates that the input character was not processed and
       * subsequent processing is required.
       */
      RTEMS_TERMIOS_ISIG_WAS_NOT_PROCESSED,
      /**
       * This indicates that the character was processed and determined
       * to be one that requires a signal to be raised (e.g. VINTR or
       * VKILL). The tty must be in the right termios mode for this to
       * occur. There is no further processing of this character required and
       * the pending read() operation should be interrupted.
       */
      RTEMS_TERMIOS_ISIG_INTERRUPT_READ
    } rtems_termios_isig_status_code; 

    What was the rationale for the two status codes RTEMS_TERMIOS_ISIG_WAS_PROCESSED and RTEMS_TERMIOS_ISIG_WAS_NOT_PROCESSED?

    What should a handler do if it returns RTEMS_TERMIOS_ISIG_WAS_PROCESSED? The default handler just returns RTEMS_TERMIOS_ISIG_WAS_NOT_PROCESSED.

    Comment 5
    1. Sebastian Huber, Mon, 10 Feb 2020 08:01:48 GMT

    In 90f11edd/rtems:

    termios: Fix input canonical mode Canonical input processing was broken by 667501a314ba75f80f1c13c6b43dd35d0a00efd1 as shown by test case termios09. Update #3800.
    Comment 6
    1. Joel Sherrill, Thu, 02 Apr 2020 01:03:02 GMT

    Sebastian can this be closed now?

    Comment 7
    1. Sebastian Huber, Thu, 02 Apr 2020 05:07:40 GMT

    Replying to Joel Sherrill:

    Sebastian can this be closed now?

    See comment 4.

    Comment 8
    1. Chris Johns, Tue, 28 Apr 2020 01:53:39 GMT

    Ping?

    Comment 9
    1. Sebastian Huber, Mon, 04 May 2020 14:55:44 GMT

    Joel, I have no idea what you had in mind with the rtems_termios_isig_status_code, see my comment #4. Is this part of the API which applications may implement? The

    rtems_termios_isig_status_code rtems_termios_posix_isig_handler(
      unsigned char             c,
      struct rtems_termios_tty *tty
    )
    {
      if (c == tty->termios.c_cc[VINTR]) {
        raise(SIGINT);
        return RTEMS_TERMIOS_ISIG_INTERRUPT_READ;
      }
      if (c == tty->termios.c_cc[VQUIT]) {
        raise(SIGQUIT);
        return RTEMS_TERMIOS_ISIG_INTERRUPT_READ;
      }
      return RTEMS_TERMIOS_ISIG_WAS_NOT_PROCESSED;
    } 

    doesn't use RTEMS_TERMIOS_ISIG_WAS_PROCESSED for example. The "unsigned char" should be probably cc_t.

    Comment 10
    1. Joel Sherrill, Mon, 04 May 2020 15:30:41 GMT

    I added the enum for readability. This is a very odd path and having a real name versus a boolean seemed to me to make the code clearer. We could add a debug assert before the return RTEMS_TERMIOS_IPROC_CONTINUE and then the enum RTEMS_TERMIOS_ISIG_WAS_NOT_PROCESSED would be used.

    I was leaning to improving the readability with the enum names. It was also not 100% clear to be that there would not end up ever being a third case.

    static rtems_termios_iproc_status_code
    iproc (unsigned char c, struct rtems_termios_tty *tty)
    {
      /*
       * If signals are enabled, then allow possibility of VINTR causing
       * SIGINTR and VQUIT causing SIGQUIT. Invoke user provided isig handler.
       */
      if ((tty->termios.c_lflag & ISIG)) {
        if ((c == tty->termios.c_cc[VINTR]) || (c == tty->termios.c_cc[VQUIT])) {
          rtems_termios_isig_status_code rc;
          rc = (*termios_isig_handler)(c, tty);
          if (rc == RTEMS_TERMIOS_ISIG_INTERRUPT_READ) {
             return RTEMS_TERMIOS_IPROC_INTERRUPT;
          }
          return RTEMS_TERMIOS_IPROC_CONTINUE;
        }
      } 
    Comment 11
    1. Chris Johns, Tue, 05 May 2020 02:28:14 GMT

    I am attempting to follow the flow of this ticket to see what the issue is. Sebastian, Joel pushed the patch on 2 Oct 2019, then you updated the ticket with comment:4 around Feb 1 2020 plus a patch to fix the change Joel pushed removing references to one of the enum values. The change only updated the ticket. It was confusing for me to determining the status and action that needs to happen. I have now taken the time to do this.

    In regards to enum's one of the fixes for ticket #3969 highlights a subtle issue with bool as a return type then changing code to need more return values. There is no upgrade path I consider __clean__ or __safe__ (?) if there is a need to add more return states than a bool's true and false. The libdl ticket shows what happens if you move to an enum from bool as compilers, coverity etc cannot see enough to know any code that was if (!returned_bool_now_enum()) ... maybe wrong. In the case of libdl the true or 1 became .*_no_error and 0 so a valid or no error result was incorrectly handled in code not updated. I think in important interfaces an enum should be considered desirable even if there is only two states and even if only one state is currently being used, i.e. what we now have.

    I agree the documentation should indicate how to use the enum results returned. Can someone please update the enum's comments so a user knows how to handle them if returned?

    Thanks

    Comment 12
    1. Sebastian Huber, Thu, 07 May 2020 13:07:43 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    In 153b2669/rtems:

    termios: Replace rtems_termios_isig_status_code Merge the rtems_termios_isig_status_code and rtems_termios_iproc_status_code enums into a single rtems_termios_iproc_status_code which is now a part of the API. Simplify rtems_termios_posix_isig_handler() to avoid unreachable code. Close #3800.

    3802 - RSB Build of Spike Fails on Second TIme (bug in upstream spike)

    Link https://devel.rtems.org/ticket/3802
    Id 3802
    Reporter Joel Sherrill
    Created 17 October 2019 13:25:35
    Modified 13 December 2019 15:21:06
    Owner Hesham Almatary
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    See ​https://github.com/riscv/riscv-isa-sim/issues/348

    When this is fixed in the upstream, bump the hash in the RSB. Until then, use the attached patch.

    Attachments:

    1 Joel Sherrill, Thu, 17 Oct 2019 13:50:42 GMT
      attach: set to 0001-Correct-Permission-on-Installed-Headers-and-Binaries.patch
     
    Comment 1
    1. Joel Sherrill, Wed, 23 Oct 2019 22:55:00 GMT

    In 68870df/rtems-source-builder:

    Update Spike RSB recipe and correct installed permissions Updates #3802.
    Comment 2
    1. Joel Sherrill, Thu, 24 Oct 2019 12:32:44 GMT

    Assigning to Hesham. Chris worked with me to simplify the recipe and apply my patch for this specific issue. Hesham concurrently had a patch to bump the spike version.

    Hesham.. please use this ticket when you commit your changes on top of mine. Thanks.

    Comment 3
    1. Hesham Almatary, Thu, 24 Oct 2019 14:34:58 GMT

    OK to push this one? ​https://lists.rtems.org/pipermail/devel/2019-October/055910.html

    Comment 4
    1. Chris Johns, Thu, 24 Oct 2019 23:17:08 GMT

    Replying to Hesham Almatary:

    OK to push this one? ​https://lists.rtems.org/pipermail/devel/2019-October/055910.html

    What is all$ as a target? Is this something specific to spike?

    Comment 5
    1. Joel Sherrill, Fri, 13 Dec 2019 15:21:06 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Spike builds now. The commit that fixed this probably missed including the ticket number.


    3803 - RSB ssl context error fetching qemu patches

    Link https://devel.rtems.org/ticket/3803
    Id 3803
    Reporter Joel Sherrill
    Created 28 October 2019 22:04:27
    Modified 5 April 2020 04:56:23
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    It looks like there is a bug in the code that fetches source/patches. Jiri's site is a simple https:

    making dir: /home/joel/rtems-work/rtems-source-builder/bare/patches
    _url: https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch -> /home/joel/rtems-work/rtems-source-builder/bare/patches/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch
    download: (full) https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch -> patches/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch
    download: https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch -> patches/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch
    download: no ssl context
    download: https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch: error:
    error: downloading https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch: all paths have failed, giving up

    This is a build with the following script:

    version=5
    # variant="-couverture"
    time ../source-builder/sb-set-builder \
    --trace \
    --log=l-qemu.txt \
    --prefix=${HOME}/rtems-work/tools/${version} \
    devel/qemu${variant}
    Comment 1
    1. Chris Johns, Tue, 29 Oct 2019 04:36:13 GMT

    Are you sure it is a bug? I do not see the issue and have been downloading these files a lot over the last few days with the RSB.

    Comment 2
    1. Joel Sherrill, Tue, 29 Oct 2019 15:22:07 GMT

    Replying to Chris Johns:

    Are you sure it is a bug? I do not see the issue and have been downloading these files a lot over the last few days with the RSB.

    Jiri has a patch which moves the patches to another server. This resolves it for me. But I am on Centos 7 and have tried Python 2.7 and 3.6. The patches load in a browser but don't fetch. Not sure what's up. I don't see this on any other package or patch.

    Comment 3
    1. Chris Johns, Tue, 29 Oct 2019 18:28:21 GMT

    Replying to Joel Sherrill:

    Jiri has a patch which moves the patches to another server. This resolves it for me.

    But this does not find out if there is an issue. Lets not paper over the issue. Your debugging of this would help.

    But I am on Centos 7 and have tried Python 2.7 and 3.6. The patches load in a browser but don't fetch. Not sure what's up. I don't see this on any other package or patch.

    The code is ...

    ​https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/download.py#n367

    Please add a raise here ...

    ​https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/download.py#n390

    so the failure is printed. Even better if you could add code to better report the exception it would help long term. Python has great doco on exceptions and catching them.

    Comment 4
    1. Jiri Gaisler, Wed, 30 Oct 2019 11:23:58 GMT

    The issue could have been caused by some temporary network problem to or in my server. How about if I attach the Leon3 Qemu patches to this ticket and modify RSB to fetch the patches from here ...? We used to do that for the sis/gdb patches and that worked OK.

    Comment 5
    1. Joel Sherrill, Wed, 30 Oct 2019 12:42:04 GMT

    I tried this again yesterday and this morning and did not have issues. I am closing this as spurious network issues. We can always reopen it.

    Comment 6
    1. Chris Johns, Wed, 30 Oct 2019 20:50:27 GMT

    Replying to Jiri Gaisler:

    The issue could have been caused by some temporary network problem to or in my server. How about if I attach the Leon3 Qemu patches to this ticket and modify RSB to fetch the patches from here ...? We used to do that for the sis/gdb patches and that worked OK.

    That is for Jiri to comment on. No one else is having problems and I think it is something local to your setup.

    Comment 7
    1. Gedare Bloom, Sun, 05 Apr 2020 04:56:23 GMT
    2. status: changed from assigned to closed
    3. resolution: set to invalid

    3804 - sb-get-sources: Error repo_mail referenced before assignment

    Link https://devel.rtems.org/ticket/3804
    Id 3804
    Reporter Joel Sherrill
    Created 30 October 2019 12:31:47
    Modified 5 April 2020 04:50:56
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This occurred on CentOS 7 with Python 2.7.5 and 3.6.

    $ ../source-builder/sb-get-sources   bare/qemu
    RTEMS Source Builder - Get Sources, 5 (5ecf0181b494)
    Traceback (most recent call last):
    File "../source-builder/sb/cmd-get-sources.py", line 26, in
    getsources.run()
    File "/home/joel/rtems-work/rtems-source-builder/source-builder/sb/getsources.py", line 631, in run
    opts = load_options(args, argopts)
    File "/home/joel/rtems-work/rtems-source-builder/source-builder/sb/getsources.py", line 588, in load_options
    opts = options(argv, argopts, defaults)
    File "/home/joel/rtems-work/rtems-source-builder/source-builder/sb/getsources.py", line 167, in __init__
    self.sb_git()
    File "/home/joel/rtems-work/rtems-source-builder/source-builder/sb/getsources.py", line 276, in sb_git
    if repo_mail is not None:
    UnboundLocalError: local variable 'repo_mail' referenced before assignment
    Comment 1
    1. Gedare Bloom, Sun, 05 Apr 2020 04:50:56 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    This appears to have been fixed in [443b8ce3/rtems-source-builder]


    3805 - libdebugger build error on atsamv

    Link https://devel.rtems.org/ticket/3805
    Id 3805
    Reporter Joel Sherrill
    Created 30 October 2019 13:30:05
    Modified 30 October 2019 20:48:48
    Owner Chris Johns
    Type defect
    Component lib/debugger
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This was caught in a build sweep using rtems-bsp-builder.

    Configure command:

    /home/joel/rtems-cron-5/rtems/configure --target=arm-rtems5 --enable-rtemsbsp=atsamv --prefix=/home/joel/rtems-cron-5/tools/5/bsps --enable-rtems-debug --disable-smp 

    Compiler output:

    arm-rtems5-gcc --pipe -DHAVE_CONFIG_H   -I. -I/home/joel/rtems-cron-5/b-atsam/arm-rtems5/c/atsamv/include -I/home/joel/rtems-cron-5/rtems/cpukit/include -I/home/joel/rtems-cron-5/rtems/cpukit/score/cpu/arm/include -I/home/joel/rtems-cron-5/rtems/cpukit/libnetworking   -mthumb -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard -O2 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT libdebugger/rtems-debugger-arm.o -MD -MP -MF $depbase.Tpo -c -o libdebugger/rtems-debugger-arm.o /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c &&\
    mv -f $depbase.Tpo $depbase.Po
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c: In function 'arm_debug_mmap_enable':
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:826:12: warning: unused variable 'abort_handler' [-Wunused-variable]
    void* abort_handler;
    ^~~~~~~~~~~~~
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c: In function 'arm_debug_unlock_abort':
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:1593:53: error: 'arm_switch_reg' undeclared (first use in this function)
    #define EXCEPTION_ENTRY_EXC() (void) arm_switch_reg
    ^
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:1609:3: note: in expansion of macro 'EXCEPTION_ENTRY_EXC'
    EXCEPTION_ENTRY_EXC();
    ^~~~~~~~~~~~~~~~~~~
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:1593:53: note: each undeclared identifier is reported only once for each function it appears in
    #define EXCEPTION_ENTRY_EXC() (void) arm_switch_reg
    ^
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:1609:3: note: in expansion of macro 'EXCEPTION_ENTRY_EXC'
    EXCEPTION_ENTRY_EXC();
    ^~~~~~~~~~~~~~~~~~~
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:1607:24: warning: variable 'frame' set but not used [-Wunused-but-set-variable]
    CPU_Exception_frame* frame;
    ^~~~~
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c: In function 'target_exception_undefined_instruction':
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:1593:53: error: 'arm_switch_reg' undeclared (first use in this function)
    #define EXCEPTION_ENTRY_EXC() (void) arm_switch_reg
    ^
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:1619:3: note: in expansion of macro 'EXCEPTION_ENTRY_EXC'
    EXCEPTION_ENTRY_EXC();
    ^~~~~~~~~~~~~~~~~~~
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c: In function 'target_exception_supervisor_call':
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:1593:53: error: 'arm_switch_reg' undeclared (first use in this function)
    #define EXCEPTION_ENTRY_EXC() (void) arm_switch_reg
    ^
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:1642:3: note: in expansion of macro 'EXCEPTION_ENTRY_EXC'
    EXCEPTION_ENTRY_EXC();
    ^~~~~~~~~~~~~~~~~~~
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c: In function 'target_exception_prefetch_abort':
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:1593:53: error: 'arm_switch_reg' undeclared (first use in this function)
    #define EXCEPTION_ENTRY_EXC() (void) arm_switch_reg
    ^
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:1659:3: note: in expansion of macro 'EXCEPTION_ENTRY_EXC'
    EXCEPTION_ENTRY_EXC();
    ^~~~~~~~~~~~~~~~~~~
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c: In function 'target_exception_data_abort':
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:1593:53: error: 'arm_switch_reg' undeclared (first use in this function)
    #define EXCEPTION_ENTRY_EXC() (void) arm_switch_reg
    ^
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:1676:3: note: in expansion of macro 'EXCEPTION_ENTRY_EXC'
    EXCEPTION_ENTRY_EXC();
    ^~~~~~~~~~~~~~~~~~~
    At top level:
    /home/joel/rtems-cron-5/rtems/c/src/../../cpukit/libdebugger/rtems-debugger-arm.c:1605:1: warning: 'arm_debug_unlock_abort' defined but not used [-Wunused-function]
    arm_debug_unlock_abort(void)
    Comment 1
    1. Chris Johns, Wed, 30 Oct 2019 20:47:02 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    This has been fixed. See the simpler beaglebone error, I think number 10. I think your source tree is not up to date in your build system.

    Comment 2
    1. Chris Johns, Wed, 30 Oct 2019 20:48:48 GMT

    ​https://git.rtems.org/rtems/commit/?id=32c9b831094e5d8474e07e87e978bc33f1472f1c ​https://git.rtems.org/rtems/commit/?id=2fdbdbc8b17a40837c53d70106f99eb8ec7c7988


    3806 - Add fatal error for heap errors

    Link https://devel.rtems.org/ticket/3806
    Id 3806
    Reporter Sebastian Huber
    Created 31 October 2019 12:10:55
    Modified 5 November 2019 11:50:33
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Currently, the following fatal error is generate in case of heap errors:

     static void _Heap_Protection_block_error_default(
    Heap_Control *heap,
    Heap_Block *block
    )
    {
    /* FIXME */
    _Terminate( INTERNAL_ERROR_CORE, 0xdeadbeef );
    }

    Replace this with a dedicated fatal error source and a context structure (similar to assert()).

    Comment 1
    1. sebastian.huber, Tue, 05 Nov 2019 11:50:12 GMT

    In 3859cd63/rtems:

    rtems-5: Improve heap fatal error information Update #3806.
    Comment 2
    1. Sebastian Huber, Tue, 05 Nov 2019 11:50:33 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In dee158c/rtems-docs:

    c-user: Document RTEMS_FATAL_SOURCE_HEAP Close #3806.

    3808 - Fix qemu-couverture-git RSB download file name

    Link https://devel.rtems.org/ticket/3808
    Id 3808
    Reporter Chris Johns
    Created 1 November 2019 05:35:36
    Modified 13 December 2019 15:13:47
    Owner Joel Sherrill
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The file name for qemu-couverture-git is a git hash. This results in a file in a release source directory that has no meaning ...

    ​https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m1911/sources/

    The release build output shows the issue ...

    package: qemu-e9299f7591c8ecf3389922f4e7672b6bc5deae71-x86_64-pc-solaris2-1
    download: https://github.com/AdaCore/qemu/archive/e9299f7591c8ecf3389922f4e7672b6bc5deae71.tar.gz -> sources/e9299f7591c8ecf3389922f4e7672b6bc5deae71.tar.gz
    redirect: https://codeload.github.com/AdaCore/qemu/tar.gz/e9299f7591c8ecf3389922f4e7672b6bc5deae71
    downloading: sources/e9299f7591c8ecf3389922f4e7672b6bc5deae71.tar.gz - 0.0 bytes
    Comment 1
    1. Joel Sherrill, Fri, 13 Dec 2019 15:13:47 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 6c65fc2/rtems-source-builder:

    qemu-couverture-git-1.cfg: Use an identifiable name for the download file. closes #3808.

    3809 - Fix epiphany-rtems5-gdb-7.8 RSB download file name

    Link https://devel.rtems.org/ticket/3809
    Id 3809
    Reporter Chris Johns
    Created 1 November 2019 05:38:29
    Modified 12 December 2019 21:32:33
    Owner Joel Sherrill <joel@…>
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The file name for epiphany-rtems5-gdb-7.8 is a git hash. This results in a file in a release source directory that has no meaning ...

    ​https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m1911/sources/

    The release build output shows the issue ...

    download: https://github.com/adapteva/epiphany-binutils-gdb/archive/f05996c7c42e6b2781946acbab15... -> sources/f05996c7c42e6b2781946acbab153a481ce3fd0b.zip
    redirect: https://codeload.github.com/adapteva/epiphany-binutils-gdb/zip/f05996c7c42e6b2781946ac...
    downloading: sources/f05996c7c42e6b2781946acbab153a481ce3fd0b.zip - 0.0 bytes
    Comment 1
    1. Joel Sherrill, Thu, 12 Dec 2019 21:32:33 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In b5aa2f0/rtems-source-builder:

    5/rtems-epiphany.bset: Rework to have meaningful name for gdb closes #3809.

    3810 - Use the release details in the release build docs

    Link https://devel.rtems.org/ticket/3810
    Id 3810
    Reporter Chris Johns
    Created 1 November 2019 05:42:25
    Modified 28 April 2020 05:18:42
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The docs in a release have the hash in the version, it should be the version number with the snapshot details.

    Comment 1
    1. Chris Johns, Tue, 28 Apr 2020 05:18:42 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Fixed in the release scripts... ​https://git.rtems.org/rtems-release/commit/?id=158da70322fb3c4d8bc0f444e6bfd07fb2832495


    3811 - Release source path on ftp.rtems.org is wrong

    Link https://devel.rtems.org/ticket/3811
    Id 3811
    Reporter Chris Johns
    Created 3 November 2019 01:19:06
    Modified 12 November 2019 17:44:37
    Owner Chris Johns <chrisj@…>
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords release
    Cc  
    Blocking  
    Blocked by  

    Description

    The released source directory in the release snapshot is wrong. The RSB is fetching .. ​https://ftp.rtems.org/pub/rtems/releases/5/5.0.0-m1911/sources

    Comment 1
    1. Chris Johns, Mon, 11 Nov 2019 03:49:16 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    ​https://git.rtems.org/rtems-release/commit/?id=669f17dfba4554eafa8ebc82c437133cd51e8ed9

    Comment 2
    1. Chris Johns, Tue, 12 Nov 2019 17:44:37 GMT
    2. owner: set to Chris Johns <chrisj@…>

    In 669f17d/rtems-release:

    rsb: Set the correct release snapshot path. Closes #3811

    3812 - Released RSB has no source set for rtems-tools

    Link https://devel.rtems.org/ticket/3812
    Id 3812
    Reporter Chris Johns
    Created 3 November 2019 20:55:07
    Modified 28 February 2020 04:26:59
    Owner Chris Johns
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords release
    Cc  
    Blocking  
    Blocked by  

    Description

    Building a release RSB fails in the rtems-tools build with:

    script: 85: rtems_tools_source="rtems-tools-5.0.0-m1911"
    script: 86: source_dir_rtems_tools=${rtems_tools_source}
    source setup: rtems-tools-5.0.0-m1911-1: source rtems-tools -q -n ${rtems_tools_source}
    error: no source set: rtems-tools (source-rtems-tools)
    Comment 1
    1. Chris Johns, Mon, 11 Nov 2019 03:49:57 GMT
    2. keywords: release added
    Comment 2
    1. Chris Johns, Fri, 28 Feb 2020 04:26:59 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Fixed


    3813 - RSB does not handle --rsb-file in releases

    Link https://devel.rtems.org/ticket/3813
    Id 3813
    Reporter Chris Johns
    Created 3 November 2019 22:34:52
    Modified 29 April 2020 05:14:11
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    A released RSB does not handle the set source option --rsb-file:

    package: arm-rtems5-gcc-fb371a33fa6-newlib-6661a67-x86_64-freebsd12.0-1
    download: https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m1911/sources/fb371a33fa6 -> sources/gnu-mirror-gcc-fb371a33fa6.tar.gz
    download: https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m1911/sources/fb371a33fa6: error: HTTP Error 404: Not Found
    download: https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m1911/fb371a33fa6 -> sources/gnu-mirror-gcc-fb371a33fa6.tar.gz
    download: https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m1911/fb371a33fa6: error: HTTP Error 404: Not Found
    download: https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/fb371a33fa6 -> sources/gnu-mirror-gcc-fb371a33fa6.tar.gz
    downloading: sources/gnu-mirror-gcc-fb371a33fa6.tar.gz - 93.6MB

    The released source has the --rsb-file name as the file name and not the URL file name. The transformation occurred when the release process downloaded the files to make the release.
    The release fails to find the source in the RTEMS file server and falls back to the home site to fetch the source.

    Comment 1
    1. Chris Johns, Wed, 29 Apr 2020 05:14:11 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Pushed ...

    ​https://git.rtems.org/rtems-release/commit/?id=5e16156b814762fa57ab049cfb80e4614124d04f

    and built a release and tested it with a test URL and the beagleboneblack BSP stack built.


    3814 - Releasing creates 2 copies or the kernel and tools.

    Link https://devel.rtems.org/ticket/3814
    Id 3814
    Reporter Chris Johns
    Created 4 November 2019 03:46:47
    Modified 18 November 2019 22:16:04
    Owner Chris Johns
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords release
    Cc  
    Blocking  
    Blocked by  

    Description

    The release snapshot m1911 as found here:

    ​https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m1911/

    has a kernel (rtems-5.0.0-m1911.tar.xz) in the top directory and another copy in the sources directory.

    The top level copy is the head of the branch, in this case master while I suspect the copy in the sources directory is created by the RSB when collecting the source.

    Which is correct for a release? I am not sure, the tagged version in the RSB or the release packaged version?

    I tend to think the release packaged version is used and the RSB collected versions should not be collected. They are only useful when working from git.

    Comment 1
    1. Chris Johns, Mon, 11 Nov 2019 03:50:25 GMT
    2. keywords: release added
    Comment 2
    1. Chris Johns, Mon, 18 Nov 2019 22:16:01 GMT

    In 6950f22/rtems-source-builder:

    sb: Add support for a comma separated release path list. Updates #3814
    Comment 3
    1. Chris Johns, Mon, 18 Nov 2019 22:16:04 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In f0b0a70/rtems-source-builder:

    rtems: Fix kernel and tools release source package selection. Closes #3814

    3815 - Improve SMP EDF scheduler configuration

    Link https://devel.rtems.org/ticket/3815
    Id 3815
    Reporter Sebastian Huber
    Created 5 November 2019 10:29:08
    Modified 15 April 2020 14:57:22
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    It is currently quite easy to misconfigure the SMP EDF scheduler so that not enough memory is reserved for the scheduler data structures. The only feedback to the user from these configuration errors is a memory corruption. Improve the configuration means or at least issue a fatal error.

    Comment 1
    1. Sebastian Huber, Fri, 20 Dec 2019 06:17:22 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 806fe963/rtems:

    config: Improve EDF SMP scheduler configuration Use CONFIGURE_MAXIMUM_PROCESSORS to configure the EDF SMP scheduler context. This avoids hard to debug configuration errors resulting in memory corruptions. Close #3815.
    Comment 2
    1. Sebastian Huber, Wed, 15 Apr 2020 14:57:22 GMT

    In 7b7efb2/rtems-docs:

    c-user: Fix RTEMS_SCHEDULER_EDF_SMP() Update #3815.

    3817 - RSB fails on FreeBSD 12.0 (32bit and 64bit)

    Link https://devel.rtems.org/ticket/3817
    Id 3817
    Reporter Jeff Mayes
    Created 5 November 2019 16:59:03
    Modified 28 April 2020 01:49:17
    Owner Chris Johns
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Fails to build GDB for both the Arm and Sparc architectures.

    RTEMS Tools Project - Source Builder Error Report
    Build: error: building sparc-rtems5-gdb-8.3-x86_64-freebsd12.0-1
    Command Line: ../source-builder/sb-set-builder --prefix=/home/mayes/dev/rtems/5 5/rtems-sparc
    Python: 3.6.9 (default, Oct 24 2019, 01:18:01) [GCC 4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)]
    git://git.rtems.org/rtems-source-builder.git/origin/9a1cf9a2d940a4f79cd822f05c8fb13a4c0ec3bb
    FreeBSD rtbf64b 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 GENERIC amd64
    CXXLD gdb
    /usr/bin/ld: error: undefined symbol: libiconv_open
    >>> referenced by charset.c
    >>> charset.o:(convert_between_encodings(char const*, char const*, unsigned char const*, unsigned int, int, obstack*, transliterations))
    /usr/bin/ld: error: undefined symbol: libiconv
    >>> referenced by charset.c
    >>> charset.o:(convert_between_encodings(char const*, char const*, unsigned char const*, unsigned int, int, obstack*, transliterations))
    /usr/bin/ld: error: undefined symbol: libiconv_close
    >>> referenced by charset.c
    >>> charset.o:(convert_between_encodings(char const*, char const*, unsigned char const*, unsigned int, int, obstack*, transliterations))
    /usr/bin/ld: error: undefined symbol: libiconv_close
    >>> referenced by charset.c
    >>> charset.o:(convert_between_encodings(char const*, char const*, unsigned char const*, unsigned int, int, obstack*, transliterations))
    /usr/bin/ld: error: undefined symbol: libiconv_open
    >>> referenced by charset.c
    >>> charset.o:(wchar_iterator::wchar_iterator(unsigned char const*, unsigned long, char const*, unsigned long))
    /usr/bin/ld: error: undefined symbol: libiconv_close
    >>> referenced by charset.c
    >>> charset.o:(wchar_iterator::~wchar_iterator())
    /usr/bin/ld: error: undefined symbol: libiconv_close
    >>> referenced by charset.c
    >>> charset.o:(validate(gdbarch*))
    c++: error: linker command failed with exit code 1 (use -v to see invocation)
    gmake[2]: *** [Makefile:1889: gdb] Error 1
    gmake[2]: Leaving directory '/usr/home/mayes/dev/rsb/rtems/build/sparc-rtems5-gdb-8.3-x86_64-freebsd12.0-1/build/gdb'
    gmake[1]: *** [Makefile:8792: all-gdb] Error 2
    gmake[1]: Leaving directory '/usr/home/mayes/dev/rsb/rtems/build/sparc-rtems5-gdb-8.3-x86_64-freebsd12.0-1/build'
    gmake: *** [Makefile:849: all] Error 2
    shell cmd failed: /bin/sh -ex /usr/home/mayes/dev/rsb/rtems/build/sparc-rtems5-gdb-8.3-x86_64-freebsd12.0-1/do-build
    error: building sparc-rtems5-gdb-8.3-x86_64-freebsd12.0-1
    Comment 1
    1. Chris Johns, Tue, 05 Nov 2019 23:34:10 GMT
    2. description: modified (diff)
    3. milestone: set to 5.1
    Comment 2
    1. Sebastian Huber, Wed, 06 Nov 2019 10:26:42 GMT

    I was able to build the RTEMS 5 tools with 12.0-RELEASE-p2. I will try to update to the latest FreeBSD 12 and see what happens.

    Comment 3
    1. Joel Sherrill, Wed, 06 Nov 2019 14:35:01 GMT

    Replying to Sebastian Huber:

    I was able to build the RTEMS 5 tools with 12.0-RELEASE-p2. I will try to update to the latest FreeBSD 12 and see what happens.

    This is with a fresh install from their images. Jeff can give you the URL if it matters. Hopefully, there is something stupid on our side and not a difference between FreeBSD pre-release images and the final release image.

    Comment 4
    1. Sebastian Huber, Wed, 06 Nov 2019 14:38:09 GMT

    I did an update to FreeBSD 12.1 and at least ARM is building fine:

    ​https://lists.rtems.org/pipermail/build/2019-November/008065.html

    Comment 5
    1. Chris Johns, Wed, 06 Nov 2019 21:37:59 GMT

    Do you have libiconv installed?

    $ pkg which /usr/local/lib/libiconv.a
    /usr/local/lib/libiconv.a was installed by package libiconv-1.14_11 
    Comment 6
    1. Sebastian Huber, Thu, 07 Nov 2019 06:00:10 GMT

    Yes, I have the same output. We installed the following packages:

    pkg install git
    pkg install python
    pkg install bison
    pkg install gmake
    pkg install subversion
    pkg install makeinfo
    pkg install texinfo 
    Comment 7
    1. Joel Sherrill, Thu, 07 Nov 2019 13:46:24 GMT

    Strangely, it looks like the autoconf tests must be passing to detect libiconv but when it comes time to link, the symbols aren't there.

    Do you know how to turn on verbose mode so the make shows the real commands? That might help some.

    Comment 8
    1. Jeff Mayes, Thu, 07 Nov 2019 15:04:17 GMT

    I updated to FreeBSD 12.1 yesterday, but it still fails the same way.

    Yes, I have libiconv installed, same version shown above.

    However, I didn't have subversion or makeinfo installed. Just installed subversion, so I'll try again and report back. What's up with makeinfo?

    # pkg install makeinfo
    Updating FreeBSD repository catalogue...
    FreeBSD repository is up to date.
    All repositories are up to date.
    pkg: No packages available to install matching 'makeinfo' have been found in the repositories 
    Comment 9
    1. Jeff Mayes, Thu, 07 Nov 2019 16:22:39 GMT

    Still fails after subversion install, unsurprisingly.

    Does this look correct? I excluded matches in /home directories.

    # find / -name "libiconv*"
    /usr/ports/converters/libiconv
    /usr/lib/i18n/libiconv_std.so.4
    /usr/lib/i18n/libiconv_none.so
    /usr/lib/i18n/libiconv_std.so
    /usr/lib/i18n/libiconv_none.so.4
    /usr/lib/debug/boot/kernel/libiconv.ko.debug
    /usr/local/share/licenses/libiconv-1.14_11
    /usr/local/share/doc/libiconv
    /usr/local/lib/libiconv.a
    /usr/local/lib/libiconv.so.2
    /usr/local/lib/libiconv.so.2.5.1
    /usr/local/lib/libiconv.so
    /usr/lib32/i18n/libiconv_none.so
    /usr/lib32/i18n/libiconv_std.so.4
    /usr/lib32/i18n/libiconv_std.so
    /usr/lib32/i18n/libiconv_none.so.4
    /boot/kernel/libiconv.ko
    /boot/kernel.old/libiconv.ko
    /var/cache/pkg/libiconv-1.14_11-1b77da9274.txz
    /var/cache/pkg/libiconv-1.14_11.txz 
    Comment 10
    1. Chris Johns, Thu, 07 Nov 2019 21:29:46 GMT

    Replying to Jeff Mayes:

    Does this look correct? I excluded matches in /home directories.

    # find / -name "libiconv*" .. [snip] ...

    FreeBSD makes a __distinction__ between /usr and /usr/local. Anything under /usr excluding /usr/local is part of the base OS and you should not touch. Additional packages or ports are installed under /usr/local. If you look back at comment 5 by me you will see I have referenced a /usr/local path and not a /usr path like you have.

    There are a couple of paths ...

    You need to check if you have the libiconv package installed as ask in comment 5. Maybe try pkg info | grep libiconv to see. When I originally added libiconv support for FreeBSD the OS versions of the libraries were not up to date and so the libiconv port was needed. The OS versions maybe suitable now, however at a guess I would say they are not as the build fails. You could look closely at the errors and OS provided library to know.
    Comment 11
    1. Chris Johns, Thu, 07 Nov 2019 21:32:40 GMT

    Replying to Joel Sherrill:

    Strangely, it looks like the autoconf tests must be passing to detect libiconv but when it comes time to link, the symbols aren't there.

    Do you know how to turn on verbose mode so the make shows the real commands? That might help some.

    The log contains all the command and if that is not enough detail try --trace (1)

    The log will show a shell script is created and I think that script is run with set -x which prints the commands. On a failed build the script is left in the build tree.

    (1) ​https://docs.rtems.org/branches/master/user/rsb/commands.html#set-builder-sb-set-builder

    Comment 12
    1. Joel Sherrill, Thu, 07 Nov 2019 22:04:58 GMT

    Replying to Chris Johns:

    Replying to Joel Sherrill:

    Strangely, it looks like the autoconf tests must be passing to detect libiconv but when it comes time to link, the symbols aren't there.

    Do you know how to turn on verbose mode so the make shows the real commands? That might help some.

    The log contains all the command and if that is not enough detail try --trace (1)

    The log will show a shell script is created and I think that script is run with set -x which prints the commands. On a failed build the script is left in the build tree.

    The RSB isn't the problem here. It is the GDB build itself. They have gone to a quiet build which only prints something like "CCLD gdb" which isn't helpful at all.

    I think you mentioned that the main libiconv package may be broken and that there is another in ports. Is that correct? If so, should the default one be removed and the ports one used?

    Comment 13
    1. Chris Johns, Thu, 07 Nov 2019 22:39:43 GMT

    Replying to Joel Sherrill:

    Replying to Chris Johns:

    Replying to Joel Sherrill:

    Strangely, it looks like the autoconf tests must be passing to detect libiconv but when it comes time to link, the symbols aren't there.

    Do you know how to turn on verbose mode so the make shows the real commands? That might help some.

    The log contains all the command and if that is not enough detail try --trace (1)

    The log will show a shell script is created and I think that script is run with set -x which prints the commands. On a failed build the script is left in the build tree.

    The RSB isn't the problem here. It is the GDB build itself. They have gone to a quiet build which only prints something like "CCLD gdb" which isn't helpful at all.

    I am OK with that change. There is so much rubbish printed that is meaningless. Assuming automake I suggest you have a look at.

    ​https://www.gnu.org/software/automake/manual/html_node/Automake-Silent-Rules.html

    Try adding V=1 to the make command line.

    I think you mentioned that the main libiconv package may be broken and that there is another in ports. Is that correct?

    I am not sure it is broken, that depends on how it is used and the interfaces provided. Is this library part of a standard? If it is not then I would not use "broken".

    If so, should the default one be removed and the ports one used?

    No, ports are added. FreeBSD provides the kernel and base user land as a release. This means a libiconv may be provided by the OS base if it is needed that is suitable for the base OS user land executables. A port is also provided so there may be differences other software such as gdb requires.

    I feel you are approaching the issue from a Linux point of view which is a kernel as a separate configuration item plus the distro's user land where all the user land is under /usr as one big and hopefully happy family. FreeBSD follows the historical (?) path of the kernel and base user land being a single controlled and released item and so you do not touch it. The benefit is the base OS is tested to work and if you do not touch it no matter what you install you can at least recover back to that base.

    Comment 14
    1. Joel Sherrill, Sun, 05 Apr 2020 16:24:00 GMT

    The only response I got on the gdb list said the person manually overrode where libiconv was located. I can't seem to find that email now. The autoconf is broken, known broken, ...

    I have no idea why this works for others. It is still broken as of my overnight build.

    ​https://lists.rtems.org/pipermail/build/2020-April/012863.html

    If this works for others on FreeBSD 12, I would like to know how.

    Comment 15
    1. Chris Johns, Mon, 06 Apr 2020 00:04:13 GMT

    I recently add this to for 12 ...

    ​https://git.rtems.org/rtems-source-builder/commit/source-builder/sb/freebsd.py?id=599c4d7c87fab531014a614f2a32b56be0a3ce28 ​https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/freebsd.py#n113

    Is there an issue on 12 with this?

    Comment 16
    1. Joel Sherrill, Mon, 06 Apr 2020 00:12:59 GMT

    The failure per ​https://lists.rtems.org/pipermail/build/2020-April/012863.html (sparc) and ​https://lists.rtems.org/pipermail/build/2020-April/012855.html (riscv) is in sis. I have no idea is this is before or after where gdb would be built and trip the iconv issue. Looks like a separate issue.

    checking whether make sets $(MAKE)... yes
    checking build system type... x86_64-pc-freebsd12.1
    checking host system type... x86_64-pc-freebsd12.1
    checking for x86_64-freebsd12.1-gcc... no
    checking for gcc... gcc
    checking whether the C compiler works... no
    configure: error: in `/usr/home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sis-2.21-x86_64-freebsd12.1-1/sis-2.21':
    configure: error: C compiler cannot create executables
    See `config.log' for more details
    shell cmd failed: /bin/sh -ex  /usr/home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sis-2.21-x86_64-freebsd12.1-1/do-build
    error: building sis-2.21-x86_64-freebsd12.1-1
      See error report: rsb-report-sis-2.21-x86_64-freebsd12.1-1.txt
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
    Comment 17
    1. Chris Johns, Mon, 06 Apr 2020 06:49:26 GMT

    Are you building gdb with gcc and not cc?

    Comment 18
    1. Joel Sherrill, Fri, 17 Apr 2020 13:06:38 GMT

    I have uninstalled GCC on our test machine. That seems to have resolved this.

    How do we want to account for, document, and check this?

    Comment 19
    1. Chris Johns, Tue, 28 Apr 2020 01:49:17 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    I have updated the documentation. There was another ticket for that task.


    3821 - Port NVMe support from FreeBSD to libbsd

    Link https://devel.rtems.org/ticket/3821
    Id 3821
    Reporter Sebastian Huber
    Created 13 November 2019 11:56:46
    Modified 19 December 2019 09:04:10
    Owner Sebastian Huber
    Type project
    Component network/libbsd
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Comment 1
    1. Sebastian Huber, Wed, 13 Nov 2019 20:23:32 GMT

    In 9506754/rtems-libbsd:

    NVME(4): Import from FreeBSD Update #3821.
    Comment 2
    1. Sebastian Huber, Thu, 19 Dec 2019 09:04:10 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Some commits are missing in this ticket.


    3822 - Release created VERSION file in rtems-tools-.&#42.tar.xz is wrong

    Link https://devel.rtems.org/ticket/3822
    Id 3822
    Reporter Chris Johns
    Created 15 November 2019 23:48:50
    Modified 26 March 2020 07:12:11
    Owner Chris Johns
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords release
    Cc  
    Blocking  
    Blocked by  

    Description

    A build of the VERSION file in the release rtems-tools source package is reporting:

    invalid version file: error: Invalid version file: ./VERSION: No option 'revision' in section: 'version' 
    Comment 1
    1. Chris Johns, Mon, 18 Nov 2019 22:16:06 GMT

    In 5f7c53a/rtems-source-builder:

    sb: Align the version processing with rtems-tools. Use the same VERSION file format as rtems-tools so a common release generation can be used. The version.py is almost the same as rtems-tools. There are some minor differences, one is the RTEMS version is present in this file while rtems-tool uses config/rtems-release.ini. Updates #3822
    Comment 2
    1. Chris Johns, Thu, 26 Mar 2020 07:12:11 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3823 - Untar_ family doesn't handle nested directories

    Link https://devel.rtems.org/ticket/3823
    Id 3823
    Reporter Jonathan Brandmeyer
    Created 20 November 2019 06:03:11
    Modified 26 November 2019 07:35:06
    Owner Sebastian Huber <sebastian.huber@…>
    Type defect
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority low
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    At least, not in some circumstances.

    For example, foo/bar.txt untar's just fine, but foo/bar/baz.txt does not. If sub-directory foo/ exists first, then foo/bar/baz.txt does unpack correctly.

    We only use the Untar_*() family during our initial programming workflow, so hacking around this problem wasn't too laborious for us.

    Comment 1
    1. Chris Johns, Wed, 20 Nov 2019 22:24:42 GMT

    What happens if you add --format=ustar to your tar command ?

    Comment 2
    1. Sebastian Huber, Thu, 21 Nov 2019 08:08:50 GMT

    In 11455b2e/rtems:

    imfs: Fix IMFS_make_linearfile() Fix prototype. Fix node size. Linfiles are dynamically turned into memfiles. Update #3823.
    Comment 3
    1. Sebastian Huber, Mon, 25 Nov 2019 10:45:48 GMT

    In b6f66d9/rtems:

    untar: Unify untar support Update #3823.
    Comment 4
    1. Sebastian Huber, Mon, 25 Nov 2019 10:45:52 GMT
    2. owner: set to Sebastian Huber <sebastian.huber@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 2de05dd/rtems:

    untar: Make path also for symbolic links Close #3823.
    Comment 5
    1. Jonathan Brandmeyer, Mon, 25 Nov 2019 18:45:57 GMT

    Thanks for the fixes; I'll retest in our workflow shortly. Our team is in a "frozen for release" state at the moment, so we're somewhat behind RTEMS master right now.

    Using the ustar format had no effect.

    Comment 6
    1. Sebastian Huber, Tue, 26 Nov 2019 06:33:58 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    I added a test case and noticed, that the path creation is still broken.

    Comment 7
    1. Sebastian Huber, Tue, 26 Nov 2019 07:35:06 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    In 4551f5f/rtems:

    untar: Properly make parent path Close #3823.

    3826 - top on SMP shows invalid priorities

    Link https://devel.rtems.org/ticket/3826
    Id 3826
    Reporter Chris Johns
    Created 24 November 2019 23:26:08
    Modified 12 December 2019 21:55:00
    Owner  
    Type defect
    Component shell
    Status closed
    Resolution duplicate
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Running top on a Zynq zc706 gives ...

     ID         | NAME                | RPRI | CPRI   | TIME                | TOTAL   | CURRENT
    ------------+---------------------+---------------+---------------------+---------+--^^----
    0x0a010008 | IRQS | 4611686018427388000 | 4611686018427388000 | 2.437559 | 0.000 | 0.022

    The code in question is ... ​https://git.rtems.org/rtems/tree/cpukit/libmisc/cpuuse/cpuusagetop.c#n447

    What is best API to show a priority that makes this code robust?

    Comment 1
    1. Joel Sherrill, Sun, 24 Nov 2019 23:54:50 GMT

    What do you mean by robust?

    It is showing score priority so that is clearly confusing for POSIX threads. But a mixed system is also co fusing.

    Comment 2
    1. Chris Johns, Mon, 25 Nov 2019 00:04:38 GMT

    Replying to Joel Sherrill:

    What do you mean by robust?

    One that returns "a" priority we can document and is not effected by implementation changes.

    It is showing score priority so that is clearly confusing for POSIX threads. But a mixed system is also co fusing.

    Yes but that I feel that is a property of top's implementation. For example we could add options to show the score view or we show API priorities etc.

    Comment 3
    1. Sebastian Huber, Mon, 25 Nov 2019 06:39:23 GMT

    It shows the correct score priority. If you want to show priorities mapped to a specific API, then you have to add this on top of it.

    Comment 4
    1. Chris Johns, Thu, 12 Dec 2019 17:57:14 GMT

    The code is ​https://git.rtems.org/rtems/tree/cpukit/libmisc/cpuuse/cpuusagetop.c#n451.

    It seems _Thread_Get_unmapped_real_priority is not clearing the new extra bits used in the priority.

    Comment 5
    1. Sebastian Huber, Thu, 12 Dec 2019 18:57:51 GMT

    The Priority_Control contains 64 bits. The least significant bit is used to indicate if the priority is appended or prepended to its priority group. This bit is removed by the _Thread_Get_unmapped_real_priority(). The other 63 bits are defined by a particular scheduler algorithm. The only invariant is the lower values indicate a higher priority (importance).

    Comment 6
    1. Chris Johns, Thu, 12 Dec 2019 21:03:19 GMT

    How do we take that value and get the actual priority?

    Comment 7
    1. Chris Johns, Thu, 12 Dec 2019 21:55:00 GMT
    2. status: changed from new to closed
    3. resolution: set to duplicate

    Duplicate of #3552.


    3830 - Build problems with user names which contain space characters

    Link https://devel.rtems.org/ticket/3830
    Id 3830
    Reporter Sebastian Huber
    Created 3 December 2019 07:14:50
    Modified 3 December 2019 10:53:21
    Owner Sebastian Huber
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The RSB uses the user name as path components. This does not work well if the user name contains space characters. Use the user ID number instead.

    Comment 1
    1. Sebastian Huber, Tue, 03 Dec 2019 10:53:21 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In e26d86f/rtems-source-builder:

    Use user ID number instead of name This helps to avoid issues with user names which contain space characters. Close #3830.

    3831 - Duplicate description of Tiers and Rules

    Link https://devel.rtems.org/ticket/3831
    Id 3831
    Reporter Joel Sherrill
    Created 3 December 2019 15:07:35
    Modified 12 December 2019 17:29:08
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I think ​https://docs.rtems.org/branches/master/user/hardware/tiers.html is intended to be the real site of this information. However, ​https://devel.rtems.org/wiki/Developer/Architectures also describes the tiers rules with slightly different language.

    I think the Wiki page can be reviewed and removed. But any references and sub-pages should be dealt with at the same time. ​https://devel.rtems.org/search?q=Developer%2FArchitectures&noquickjump=1&wiki=on shows two sub-pages to deal with:

    • ​https://devel.rtems.org/wiki/Developer/Architectures/ARM which is one sentence and can be removed.
    • ​https://devel.rtems.org/wiki/Developer/Architectures/ARM/ARM-EABI which probably should move to the Users Manual.

    This would eliminate a few pages and a point of duplication for a very important concept to the RTEMS Project.

    Comment 1
    1. Sebastian Huber, Wed, 04 Dec 2019 13:26:37 GMT

    I removed both ARM pages. The information was out of date since a couple of years.

    Comment 2
    1. Joel Sherrill, Wed, 04 Dec 2019 13:28:09 GMT

    Thanks. I tripped across this doing the FSW slides. Were there links to these pages?

    Comment 3
    1. Sebastian Huber, Wed, 04 Dec 2019 13:31:34 GMT

    How can we figure out if there are links?

    The Developer/Architectures? looks like content which should be synchronized with the user manual and then get deleted.

    Comment 4
    1. Christian Mauderer, Thu, 05 Dec 2019 14:34:51 GMT

    I would interpret the two sources slightly different:

    The manual (at docs.rtems.org) sounds like tires are a per commit property. That would mean that every published result tells "The BSP has this Tire on commit/release xyz". That seems like a sane approach. The wiki on the other hand tells something about "all commits". That's a quite inaccurate description. It doesn't tell what the first commit is. So in theory every commit since RTEMS exists has to build and work for that board. That is just is impossible. Beneath that the wiki allows simulator results in tire 1. So it's not entirely clear what the difference to tire 2 is.

    I would vote for dropping the inaccurate description in the wiki in favor of the more accurate one in the manual.

    Comment 5
    1. Joel Sherrill, Thu, 12 Dec 2019 17:00:11 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 01be513/rtems-docs:

    user/hardware/tiers.rst: Merge info from Wiki. Tiers had a write up on the Wiki which was similar but different. Merged content from the Wiki which allows the Wiki page to be deleted. closes #3831.
    Comment 6
    1. Joel Sherrill, Thu, 12 Dec 2019 17:29:08 GMT

    Wiki page deleted.

    Sebastian: I searched for the Wiki page name in only wiki pages. Maybe there is another way but that confirmed it had no refernces.


    3833 - Simplify RTEMS semaphore configuration

    Link https://devel.rtems.org/ticket/3833
    Id 3833
    Reporter Sebastian Huber
    Created 9 December 2019 08:53:03
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    In SMP configurations, the maximum count of MrsP semaphores must be configured via CONFIGURE_MAXIMUM_MRSP_SEMAPHORES. The MrsP semaphore implementation predates the addition of self-contained synchronization objects. At this time, the potential memory reduction was justified considering the more complex configuration and additional use of the workspace. With the availability of self-contained synchronization options, e.g. POSIX mutexes, this is no longer justified. Memory constrained applications should use the self-contained synchronization objects. Remove the CONFIGURE_MAXIMUM_MRSP_SEMAPHORES configuration option. This has only an impact on applications which use SMP and a large number of scheduler instances.

    Comment 1
    1. Sebastian Huber, Wed, 11 Dec 2019 08:06:41 GMT

    In 01f8c12e/rtems:

    rtems: Optimize semaphore control block Move variant, discipline, and global information to flags stored in a node pointer of active semaphores. Update #3833.
    Comment 2
    1. Sebastian Huber, Wed, 11 Dec 2019 08:06:45 GMT

    In 46865542/rtems:

    rtems: Simplify semaphore configuration The MrsP semaphore implementation predates the addition of self-contained synchronization objects. At this time, the potential memory reduction was justified considering the more complex configuration and additional use of the workspace. With the availability of self-contained synchronization options, e.g. POSIX mutexes, this is no longer justified. Memory constrained applications should use the self-contained synchronization objects. Remove the CONFIGURE_MAXIMUM_MRSP_SEMAPHORES configuration option. This has only an impact on applications which use SMP and a large number of scheduler instances. Update #3833.
    Comment 3
    1. Sebastian Huber, Wed, 11 Dec 2019 08:12:11 GMT

    In f7d56f5/rtems-docs:

    c-user: Obsolete CONFIGURE_MAXIMUM_MRSP_SEMAPHORES Update #3833.
    Comment 4
    1. Sebastian Huber, Thu, 19 Dec 2019 09:02:28 GMT

    In a6887d9/rtems-docs:

    c-user: CONFIGURE_MAXIMUM_MRSP_SEMAPHORES Remove use of CONFIGURE_MAXIMUM_MRSP_SEMAPHORES in example. Fix other configuration options. Update #3833.
    Comment 5
    1. Sebastian Huber, Thu, 19 Dec 2019 09:02:30 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In b12e82d/rtems-docs:

    c-user: Clarify CONFIGURE_MAXIMUM_SEMAPHORES Close #3833.
    Comment 6
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3834 - Simplify clock driver

    Link https://devel.rtems.org/ticket/3834
    Id 3834
    Reporter Sebastian Huber
    Created 9 December 2019 08:55:27
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component dev
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    Use a system initialization handler to initialize the clock driver instead of using a legacy IO driver. This makes the system initialization more modular and removes a bit of overhead introduced by the legacy IO driver dependency.

    Comment 1
    1. Sebastian Huber, Wed, 11 Dec 2019 08:06:35 GMT

    In bb99cd0d/rtems:

    clock: Simplify driver initialization Use a system initialization handler instead of a legacy IO driver. Update #3834.
    Comment 2
    1. Sebastian Huber, Thu, 19 Dec 2019 08:12:44 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d585fcb/rtems-docs:

    bsp-howto: Clarify clock driver initialization Close #3834.
    Comment 3
    1. Sebastian Huber, Thu, 02 Jan 2020 08:49:09 GMT

    In a3706d4c/rtems:

    bsps/powerpc: Fix warning Update #3834.
    Comment 4
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3835 - Support statically allocated threads

    Link https://devel.rtems.org/ticket/3835
    Id 3835
    Reporter Sebastian Huber
    Created 9 December 2019 09:09:11
    Modified 10 November 2022 09:58:49
    Owner Sebastian Huber
    Type enhancement
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by 3838

    Description

    In some applications it is desirable to have statically allocated resources for all operating system objects.

    In addition to the thread control block, up to four memory areas are currently allocated by a thread:

  • stack area
  • TLS area
  • FP context
  • thread queue heads
  • Currently the FP context and the TLS area are separately allocated from the workspace. This complicates the workspace size estimate. Add the FP context and TLS size to the stack size and place them in the stack area. This makes it also possible to move the stack area allocation out of _Thread_Initialize(). Use a hook to get the thread queue heads which is configured depending on the unlimited objects option of the configuration.

    Statically allocate the stacks for internal threads (e.g. idle and MPCI receive server) in a dedicated linker section (similar to the interrupt stacks). Mention this in the Classic API Guide configuration chapter.

    Comment 1
    1. Chris Johns, Mon, 09 Dec 2019 11:47:18 GMT

    Does this assume TLS is a fixed size? I would need to revisit how TLS support would be managed in the dynamic loading situation. At a guess I suspect it will break possible soluitons and that concerns me. I would prefer we do not wedged libdl in to a corner with change for a use case I do not fully understand. Maybe a detailed use case would help.

    Comment 2
    1. Sebastian Huber, Mon, 09 Dec 2019 11:55:41 GMT

    Nothing stops you from reallocating the TLS area on demand. In the worst case you waste a bit of memory. I don't think this change here will add constraints to libdl.

    Comment 3
    1. Sebastian Huber, Mon, 09 Dec 2019 11:58:24 GMT

    For clarification, the pointer to the TLS area in the thread control block will remain as is.

    Comment 4
    1. Chris Johns, Mon, 09 Dec 2019 12:24:02 GMT

    Great, that helps. Thanks.

    Comment 5
    1. Joel Sherrill, Mon, 09 Dec 2019 12:38:58 GMT

    In at least two applications I have helped with that had custom allocators, this sounds like it might not work. They had special mmu permissions on their stack memory.

    Comment 6
    1. Sebastian Huber, Mon, 09 Dec 2019 12:51:01 GMT

    I would consider the FP context and the thread-local storage of a thread to be in the same access domain. These data areas should be private to a thread.

    Comment 7
    1. Sebastian Huber, Wed, 11 Dec 2019 14:26:21 GMT
    2. blockedby: set to 3838
    Comment 8
    1. Joel Sherrill, Thu, 12 Dec 2019 18:09:46 GMT

    Replying to Sebastian Huber:

    I would consider the FP context and the thread-local storage of a thread to be in the same access domain. These data areas should be private to a thread.

    I don't know if this was intended to respond to my concern with custom stack allocators or not. In the systems I know have used this, the memory is not available (mapped dynamically) or known statically (RTEMS runs in virtual address space).

    How does this work with custom stack allocators?

    Comment 9
    1. Sebastian Huber, Thu, 12 Dec 2019 18:54:18 GMT

    Replying to Joel Sherrill:

    Replying to Sebastian Huber:

    I would consider the FP context and the thread-local storage of a thread to be in the same access domain. These data areas should be private to a thread.

    I don't know if this was intended to respond to my concern with custom stack allocators or not. In the systems I know have used this, the memory is not available (mapped dynamically) or known statically (RTEMS runs in virtual address space).

    How does this work with custom stack allocators?

    The availability of statically initialized threads doesn't mean that everyone has to use them. They are optional. I also have no intention to remove the custom stack allocator. What changes is that the memory area allocated for the stack is used also to contain the thread-local storage and the FP context. These memory areas are private to a thread and non-executable. I really don't know what a potential problem could be with a custom allocator.

    I plan to statically initialize the stacks for the idle threads and the MPCI receive server thread. They will reside in special linker sections so that a BSP or application can control the placement in memory.

    Comment 10
    1. Sebastian Huber, Fri, 03 Jan 2020 06:37:06 GMT
    2. description: modified (diff)
    Comment 11
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:08 GMT

    In bf39a9e/rtems:

    score: Remove superfluous FP types/defines Update #3835.
    Comment 12
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:11 GMT

    In a0211fc9/rtems:

    score: Simplify thread stack allocation Remove superfluous Thread_Control::Start::stack member. Update #3835.
    Comment 13
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:14 GMT

    In 0bde56b/rtems:

    score: Simplify thread stack free Update #3835.
    Comment 14
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:17 GMT

    In 0e1ac917/rtems:

    score: Remove _Stack_Ensure_minimum() call This call is superfluous since _Thread_Initialize() will do this also. Update #3835.
    Comment 15
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:21 GMT

    In fc398fd/rtems:

    score: Simplify FP context allocation Use the stack area to allocate the FP context. This considerably simplifies the application configuration since the task count no longer influences the configured work space size. With this change the stack space size is overestimated since an FP context for each thread is accounted. Memory constraint applications can use the stack size for fine tuning. Update #3835.
    Comment 16
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:24 GMT

    In f4dbf37d/rtems:

    score: Simplify TLS area allocation Use the stack area to allocate the TLS area. Update #3835.
    Comment 17
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:27 GMT

    In 00c7ad4/rtems:

    score: Split stack allocator configuration This allows the linker garbage collection to perform its work. Update #3835.
    Comment 18
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:31 GMT

    In a08dcb2/rtems:

    score: Add Thread_Configuration Add the Thread_Configuration structure to reduce the parameter count of _Thread_Initialize(). This makes it easier to add more parameters in the future. It simplifies the code generation since most architectures do not have that many registers available for function parameters. Update #3835.
    Comment 19
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:34 GMT

    In 4c9deb6c/rtems:

    score: Add _Stack_Extend_size() Update #3835.
    Comment 20
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:37 GMT

    In 01d5944/rtems:

    score: Move thread stack allocation Move thread stack allocation to caller side of _Thread_Initialize(). Update #3835.
    Comment 21
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:40 GMT

    In 32991495/rtems:

    score: Statically allocate idle/MPCI stacks Place idle and MPCI stacks into extra linker sections. This can be optionally used by applications to control the placement of the stacks. Update #3835.
    Comment 22
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:43 GMT

    In 6f3bc0e/rtems:

    score: Add _Objects_Free_objects_block() This is a preparation to allow a customization of the objects information extend. Update #3835.
    Comment 23
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:47 GMT

    In 2485156/rtems:

    score: Split up objects allocation Split up the different objects allocation methods into separate functions. This helps to avoid a dependency on the workspace in case no objects or a static set of objects is configured. Change license to BSD-2-Clause according to file histories. Update #3053. Update #3835.
    Comment 24
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:50 GMT

    In 6135747/rtems:

    score: Split up objects free Split up the different objects free methods into separate functions. This helps to avoid a dependency on the workspace in case no objects or a static set of objects is configured. Update #3835.
    Comment 25
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:53 GMT

    In 8e118f22/rtems:

    score: Inline _Objects_Namespace_remove_u32() This function is simple enough to be inlined. Update #3835.
    Comment 26
    1. Sebastian Huber, Wed, 12 Feb 2020 15:12:57 GMT

    In 36e59b2/rtems:

    score: _Objects_Extend_information() Return block index in _Objects_Extend_information(). This allows to customize the objects information extend. Update #3835.
    Comment 27
    1. Sebastian Huber, Wed, 12 Feb 2020 15:13:00 GMT

    In 8ff1af1/rtems:

    score: Add _Freechain_Is_empty() Update #3835.
    Comment 28
    1. Sebastian Huber, Wed, 12 Feb 2020 15:13:03 GMT

    In 4eab96b/rtems:

    score: Add _Freechain_Pop() Update #3835.
    Comment 29
    1. Sebastian Huber, Wed, 12 Feb 2020 15:13:06 GMT

    In 8a43adb/rtems:

    score: Add _Freechain_Extend() Update #3835.
    Comment 30
    1. Sebastian Huber, Wed, 12 Feb 2020 15:13:10 GMT

    In dd9e501/rtems:

    score: Add _Objects_Activate_unlimited() Update #3835.
    Comment 31
    1. Sebastian Huber, Wed, 12 Feb 2020 15:13:13 GMT

    In fc32904/rtems:

    score: Add _Objects_Allocate_with_extend() Update #3835.
    Comment 32
    1. Sebastian Huber, Wed, 12 Feb 2020 15:13:16 GMT

    In d252e20a/rtems:

    score: Simplify _Thread_Initialize() Allocate new thread queue heads during objects information extend. This removes an error case and the last dependency on the workspace in _Thread_Initialize(). Update #3835.
    Comment 33
    1. Sebastian Huber, Tue, 25 Feb 2020 08:19:35 GMT

    In ed15643/rtems-tools:

    linkers: Update due to API changes Update #3835.
    Comment 34
    1. Sebastian Huber, Tue, 25 Feb 2020 13:51:04 GMT

    In 01c97e64/rtems:

    score: Fix label defined but not used warning Update #3835.
    Comment 35
    1. Sebastian Huber, Thu, 05 Mar 2020 14:33:16 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In c6c06ae/rtems-docs:

    c-user: Document task memory Close #3835.
    Comment 36
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added
    Comment 37
    1. Sebastian Huber, Fri, 14 Oct 2022 09:41:47 GMT

    In 15bba4ae/rtems:

    score: Move Thread_Control::Registers member Place this member placed directly after the end of the common block so that the structure offsets are as small as possible. This helps on instruction set architectures with a very limited range for intermediate values. For example, see the aeabi_read_tp() implementation for ARM Thumb-1. Update #3835.
    Comment 38
    1. Sebastian Huber, Fri, 14 Oct 2022 09:41:49 GMT

    In 4c89fbcd/rtems:

    score: Add CPU_THREAD_LOCAL_STORAGE_VARIANT Update #3835.
    Comment 39
    1. Sebastian Huber, Fri, 14 Oct 2022 09:42:01 GMT

    In 45ee958/rtems:

    config: Add CONFIGURE_IDLE_TASK_STORAGE_SIZE By default, allocate the IDLE task storage areas from the RTEMS Workspace. This avoids having to estimate the thread-local storage size in the default configuration. Add the application configuration option CONFIGURE_IDLE_TASK_STORAGE_SIZE to request a static allocation of the task storage area for IDLE tasks. Update #3835. Update #4524.
    Comment 40
    1. Sebastian Huber, Fri, 14 Oct 2022 09:42:03 GMT

    In 64fbeaa/rtems:

    score: INTERNAL_ERROR_IDLE_THREAD_STACK_TOO_SMALL Ensure that the IDLE storage allocator did allocate a suffiently large area. Update #3835. Update #4524.
    Comment 41
    1. Sebastian Huber, Thu, 10 Nov 2022 09:58:49 GMT

    In 8f6dd3c/rtems:

    arm: Fix Armv7-M TLS support Set the thread ID register in the CPU context. Update #3835. Close #4753.

    3836 - Specify the application configuration options

    Link https://devel.rtems.org/ticket/3836
    Id 3836
    Reporter Sebastian Huber
    Created 10 December 2019 12:24:50
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3923, 3924
    Blocked by 2806, 3900, 3901

    Description

    The application configuration is currently specified by the RTEMS Classic API Guide, the test cases, and the implementation. Add the application configuration to specification items maintained by Doorstop to "spec/acfg" in a repository. Generate the documentation from the specification items.

    The specification and the generator scripts are contained in:

    ​https://git.rtems.org/sebh/rtems-qual.git

    Comment 1
    1. Sebastian Huber, Tue, 10 Dec 2019 12:25:17 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Wed, 11 Dec 2019 08:07:31 GMT

    In bc9ce65/rtems-docs:

    c-user: Move basic system configuration Move the basic system configuration to the front. Rename it to "General System Configuration". Update #3836.
    Comment 3
    1. Sebastian Huber, Wed, 11 Dec 2019 08:07:33 GMT

    In 9d20816/rtems-docs:

    c-user: Move unlimited options to general config Update #3836.
    Comment 4
    1. Sebastian Huber, Wed, 11 Dec 2019 08:07:35 GMT

    In 3a3271e/rtems-docs:

    c-user: Move unlimited configuration options Rename unlimited subsection headers. Update #3836.
    Comment 5
    1. Sebastian Huber, Wed, 11 Dec 2019 08:07:38 GMT

    In a184ff4/rtems-docs:

    c-user: Move CONFIGURE_MEMORY_OVERHEAD Move CONFIGURE_MEMORY_OVERHEAD to general system configuration. Remove now empty "Seldom Used Configuration Parameters" section. Update #3836.
    Comment 6
    1. Sebastian Huber, Wed, 11 Dec 2019 08:07:40 GMT

    In 579d6f2/rtems-docs:

    c-user: CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS Move CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS to general system configuration. Remove now empty "C Library Support Configuration" section. Update #3836.
    Comment 7
    1. Sebastian Huber, Fri, 06 Mar 2020 15:28:34 GMT
    2. blockedby: set to 3900, 3901
    Comment 8
    1. Sebastian Huber, Mon, 09 Mar 2020 06:43:14 GMT

    In 851e4df/rtems-docs:

    c-user: Remove copyright from Petr Benes The content introduced by a commit in the RTEMS main repository
    commit 418de420a05609ba8919822b553706963a8d3a7b Author: Joel Sherrill Date: Wed Oct 5 19:59:47 2011 +0000
    2011-10-05 Joel Sherrill
    Petr Benes
    PR 1912/doc
    user/conf.t, user/schedule.t: Rework to add scheduler specific information. is no longer in this file. According to the file history, this was the only content introduced by Petr Benes. Also during the relicensing of the documentation to CC-BY-SA-4.0 in 2016 it was proclaimed that OAR was the only copyright holder of the RTEMS documentation present in the RTEMS main repository. Update #3836.
    Comment 9
    1. Sebastian Huber, Mon, 09 Mar 2020 06:43:16 GMT

    In a174ae4/rtems-docs:

    c-user: Clarify BSP related configuration options Sort options alphabetically. Update #3836.
    Comment 10
    1. Sebastian Huber, Mon, 09 Mar 2020 06:43:19 GMT

    In 988e7ca/rtems-docs:

    c-user: Clarify message queue configuration Update #3836.
    Comment 11
    1. Sebastian Huber, Mon, 09 Mar 2020 06:43:21 GMT

    In e3f6819/rtems-docs:

    c-user: Canonicalize configuration section names Update #3836.
    Comment 12
    1. Sebastian Huber, Mon, 09 Mar 2020 06:43:23 GMT

    In 7a414f9/rtems-docs:

    c-user: Sort configuration options alphabetically Update #3836.
    Comment 13
    1. Sebastian Huber, Mon, 09 Mar 2020 06:43:25 GMT

    In c078afb/rtems-docs:

    c-user: Minor format fixes Update #3836.
    Comment 14
    1. Sebastian Huber, Thu, 12 Mar 2020 09:32:40 GMT

    In a526872/rtems-docs:

    c-user: Split up configuring_a_system.rst Introduce an index file for this chapter. This helps to generate some sections from the specification in the future. Start with moving "Introduction" up to "Unlimited Objects" to a new file. Update #3836.
    Comment 15
    1. Sebastian Huber, Thu, 12 Mar 2020 09:32:42 GMT

    In ac9d49d/rtems-docs:

    c-user: Move "General System Configuration" Update #3836.
    Comment 16
    1. Sebastian Huber, Thu, 12 Mar 2020 09:32:44 GMT

    In bf995cf/rtems-docs:

    c-user: Move "Classic API Configuration" Update #3836.
    Comment 17
    1. Sebastian Huber, Thu, 12 Mar 2020 09:32:46 GMT

    In a9e6a1d/rtems-docs:

    c-user: Move "Classic API Initialization Task Configuration" Update #3836.
    Comment 18
    1. Sebastian Huber, Thu, 12 Mar 2020 09:32:48 GMT

    In 16b0d3f/rtems-docs:

    c-user: Move "POSIX API Configuration" Update #3836.
    Comment 19
    1. Sebastian Huber, Thu, 12 Mar 2020 09:32:50 GMT

    In 2a761cf/rtems-docs:

    c-user: Move "POSIX Initialization Thread Configuration" Update #3836.
    Comment 20
    1. Sebastian Huber, Thu, 12 Mar 2020 09:32:52 GMT

    In bdd17e5/rtems-docs:

    c-user: Move "Task Stack Allocator Configuration" Update #3836.
    Comment 21
    1. Sebastian Huber, Thu, 12 Mar 2020 09:32:55 GMT

    In 4d74cbd/rtems-docs:

    c-user: Move "Message Queue Buffer Configuration" Update #3836.
    Comment 22
    1. Sebastian Huber, Thu, 12 Mar 2020 09:32:57 GMT

    In c0a70db/rtems-docs:

    c-user: Move "Filesystem Configuration" Update #3836.
    Comment 23
    1. Sebastian Huber, Thu, 12 Mar 2020 09:32:59 GMT

    In 1af97ad/rtems-docs:

    c-user: Move "Block Device Cache Configuration" Update #3836.
    Comment 24
    1. Sebastian Huber, Thu, 12 Mar 2020 09:33:01 GMT

    In 4bb586b/rtems-docs:

    c-user: Move "BSP Related Configuration Options" Update #3836.
    Comment 25
    1. Sebastian Huber, Thu, 12 Mar 2020 09:33:03 GMT

    In 38032b0/rtems-docs:

    c-user: Move "Idle Task Configuration" Update #3836.
    Comment 26
    1. Sebastian Huber, Thu, 12 Mar 2020 09:33:05 GMT

    In 275f4a0/rtems-docs:

    c-user: Move "General Scheduler Configuration" Update #3836.
    Comment 27
    1. Sebastian Huber, Thu, 12 Mar 2020 09:33:07 GMT

    In 020d2e7/rtems-docs:

    c-user: Move "Clustered Scheduler Configuration" Update #3836.
    Comment 28
    1. Sebastian Huber, Thu, 12 Mar 2020 09:33:09 GMT

    In 41ac3da/rtems-docs:

    c-user: Move "Device Driver Configuration" Update #3836.
    Comment 29
    1. Sebastian Huber, Thu, 12 Mar 2020 09:33:11 GMT

    In 088a1f8/rtems-docs:

    c-user: Move "Multiprocessing Configuration" Update #3836.
    Comment 30
    1. Sebastian Huber, Thu, 12 Mar 2020 09:33:13 GMT

    In b71fb43/rtems-docs:

    c-user: Move "PCI Library Configuration" Update #3836.
    Comment 31
    1. Sebastian Huber, Thu, 12 Mar 2020 09:33:15 GMT

    In a388de9/rtems-docs:

    c-user: Move "Event Recording Configuration" Update #3836.
    Comment 32
    1. Sebastian Huber, Thu, 12 Mar 2020 09:33:17 GMT

    In 1fd339b/rtems-docs:

    c-user: Move "Ada Configuration" Update #3836.
    Comment 33
    1. Sebastian Huber, Thu, 12 Mar 2020 09:33:19 GMT

    In 88dd013/rtems-docs:

    c-user: Move "Obsolete Configuration Options" Update #3836.
    Comment 34
    1. Sebastian Huber, Fri, 13 Mar 2020 12:29:19 GMT

    In 03a735f/rtems-docs:

    c-user: Clarify message buffer configuration The help macro CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE() is not a configuration option. Move it into the documentatation of the CONFIGURE_MESSAGE_BUFFER_MEMORY configuration option. Move this option to the general system configuration group. Update #3836.
    Comment 35
    1. Sebastian Huber, Fri, 13 Mar 2020 12:29:21 GMT

    In b34f2de/rtems-docs:

    c-user: Reorder configuration option groups Sort the configuration option groups according to the likelihood a user will define options of a group. Update #3836.
    Comment 36
    1. Sebastian Huber, Tue, 17 Mar 2020 13:13:47 GMT

    In f3076bc/rtems-docs:

    c-user: Sort configuration options alphabetically Update #3836.
    Comment 37
    1. Sebastian Huber, Tue, 17 Mar 2020 13:42:18 GMT

    In 5fb9a1c/rtems-docs:

    c-user: Add missing configuration option notes Update #3836.
    Comment 38
    1. Sebastian Huber, Tue, 17 Mar 2020 13:42:20 GMT

    In c3ebd83/rtems-docs:

    c-user: Fix sorting in filesystem configuration Update #3836.
    Comment 39
    1. Sebastian Huber, Tue, 17 Mar 2020 14:05:46 GMT

    In 5e54ffe/rtems-docs:

    c-user: Add configuration option index entry Update #3836.
    Comment 40
    1. Sebastian Huber, Tue, 17 Mar 2020 14:06:11 GMT

    In f75e0be/rtems-docs:

    c-user: Fix format Update #3836.
    Comment 41
    1. Sebastian Huber, Tue, 17 Mar 2020 14:27:00 GMT

    In 7a8d697/rtems-docs:

    c-user: Add reference to proxies Update #3836.
    Comment 42
    1. Sebastian Huber, Wed, 18 Mar 2020 06:32:46 GMT

    In 79fb6fd/rtems-docs:

    c-user: Canonicalize configuration option groups Update #3836.
    Comment 43
    1. Sebastian Huber, Mon, 30 Mar 2020 06:49:24 GMT

    In 0103b68/rtems-docs:

    c-user: Fix typo in file name Update #3836.
    Comment 44
    1. Sebastian Huber, Thu, 02 Apr 2020 07:47:20 GMT

    In 39ca06c/rtems-docs:

    c-user: Clarify config options use Update #3836.
    Comment 45
    1. Sebastian Huber, Thu, 02 Apr 2020 07:47:22 GMT

    In c95e3e3/rtems-docs:

    c-user: Move CONFIGURE_MAXIMUM_PRIORITY Move this option to the scheduler configuration options. Update #3836.
    Comment 46
    1. Sebastian Huber, Thu, 02 Apr 2020 08:27:13 GMT
    2. blockedby: changed from 3900, 3901 to 2806, 3900, 3901
    Comment 47
    1. Sebastian Huber, Thu, 02 Apr 2020 08:32:33 GMT
    2. blocking: set to 3923
    Comment 48
    1. Sebastian Huber, Thu, 02 Apr 2020 08:35:24 GMT
    2. blocking: changed from 3923 to 3923, 3924
    Comment 49
    1. Sebastian Huber, Thu, 02 Apr 2020 08:40:52 GMT
    2. description: modified (diff)
    Comment 50
    1. Sebastian Huber, Thu, 02 Apr 2020 08:41:43 GMT
    2. summary: changed from Specify and test application configuration to Specify the application configuration options
    Comment 51
    1. Sebastian Huber, Fri, 03 Apr 2020 06:58:23 GMT

    In 7e33a80/rtems:

    config: Remove filesystem entry config options Remove the following undocumented configuration options: CONFIGURE_FILESYSTEM_ENTRY_DOSFS CONFIGURE_FILESYSTEM_ENTRY_FTPFS CONFIGURE_FILESYSTEM_ENTRY_IMFS CONFIGURE_FILESYSTEM_ENTRY_JFFS2 CONFIGURE_FILESYSTEM_ENTRY_NFS CONFIGURE_FILESYSTEM_ENTRY_RFS CONFIGURE_FILESYSTEM_ENTRY_TFTPFS Update #3836.
    Comment 52
    1. Sebastian Huber, Fri, 03 Apr 2020 06:59:38 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    All configuration options are now documented and specified through the documentation.

    Comment 53
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3837 - Rename CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS

    Link https://devel.rtems.org/ticket/3837
    Id 3837
    Reporter Sebastian Huber
    Created 11 December 2019 08:03:54
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component config
    Status closed
    Resolution duplicate
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    Rename CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS in CONFIGURE_MAXIMUM_FILE_DESCRIPTORS. Issue a C preprocessor warning if CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS is used and map it to CONFIGURE_MAXIMUM_FILE_DESCRIPTORS.

    Comment 1
    1. Sebastian Huber, Tue, 17 Dec 2019 08:20:40 GMT
    2. status: changed from assigned to closed
    3. resolution: set to duplicate

    Duplicate of #3753.

    Comment 2
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3838 - Rework work area initialization

    Link https://devel.rtems.org/ticket/3838
    Id 3838
    Reporter Sebastian Huber
    Created 11 December 2019 14:26:21
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component bsps
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3835, 3843, 3861, 3925
    Blocked by  

    Description

    The work area initialization is done by the BSP through bsp_work_area_initialize(). This approach predates the system initialization through the system initialization linker set. The workspace and C program heap are unconditionally initialized. With the availability of statically initialized threads a system without workspace and C program heap is feasible. Change the work area initialization so that components are initialized on demand. To achieve this:

  • Add a Memory Handler which provides support for low level handling of memory areas which are handed over to the higher level Heap Handler.
  • Add an implementation of _Memory_Get() to each BSP (basically a restructuring of the bsp_work_area_initialize() implementations).
  • See optimization opportunity in #3925.

    Comment 1
    1. Chris Johns, Wed, 11 Dec 2019 16:01:24 GMT

    This needs to be explained in more detail.

    What happens to BSPs that are not in the tree?

    Comment 2
    1. Sebastian Huber, Wed, 11 Dec 2019 16:31:41 GMT

    I am not sure what needs to be explained in more detail. This is mostly a mechanical change which just rearranges existing things a bit differently.

    As usual, maintainers of BSPs which are not in the mainline RTEMS source have to pay a price and have to update their BSPs by themself. With an updated documentation, this shouldn't be an issue.

    Comment 3
    1. Chris Johns, Thu, 12 Dec 2019 18:08:47 GMT

    Replying to Sebastian Huber:

    I am not sure what needs to be explained in more detail. This is mostly a mechanical change which just rearranges existing things a bit differently.

    I think there are somethings, for example take "components are initialized on demand", what is a "component" and what does "initialized on demand" mean?

    I am OK with working through the detail but this will have to wait until I find the time. If you do not mind waiting let me know.

    As usual, maintainers of BSPs which are not in the mainline RTEMS source have to pay a price and have to update their BSPs by themself. With an updated documentation, this shouldn't be an issue.

    A number of users cannot submit their BSPs and we have attempted to maintain a BSP API. Maybe we should define a formal BSP interface that cannot be touched without careful consideration?

    Comment 4
    1. Sebastian Huber, Thu, 12 Dec 2019 18:48:09 GMT

    Replying to Chris Johns:

    Replying to Sebastian Huber:

    I am not sure what needs to be explained in more detail. This is mostly a mechanical change which just rearranges existing things a bit differently.

    I think there are somethings, for example take "components are initialized on demand", what is a "component" and what does "initialized on demand" mean?

    The two components are the workspace and the C program heap. On demand means that they are only initialized if functions of these components are used by the application.

    I am OK with working through the detail but this will have to wait until I find the time. If you do not mind waiting let me know.

    As usual, maintainers of BSPs which are not in the mainline RTEMS source have to pay a price and have to update their BSPs by themself. With an updated documentation, this shouldn't be an issue.

    A number of users cannot submit their BSPs and we have attempted to maintain a BSP API. Maybe we should define a formal BSP interface that cannot be touched without careful consideration?

    I do this with careful consideration. This change request is the result of a multi year work consisting of lots of small steps to make it possible to fully statically initialize RTEMS. Yes, it breaks the API, but adopting an existing BSP can be done easily in less than one hour. Also if you use a standard linker command file, then you can use the default implementation in your external BSP.

    Comment 5
    1. Sebastian Huber, Mon, 16 Dec 2019 07:51:32 GMT
    2. blocking: changed from 3835 to 3835, 3843
    Comment 6
    1. Sebastian Huber, Tue, 04 Feb 2020 05:23:46 GMT
    2. blocking: changed from 3835, 3843 to 3835, 3843, 3861
    Comment 7
    1. Sebastian Huber, Tue, 04 Feb 2020 06:03:26 GMT

    In 1cb9257/rtems:

    score: Add Memory Handler Update #3838.
    Comment 8
    1. Sebastian Huber, Tue, 04 Feb 2020 06:03:30 GMT

    In c477d927/rtems:

    score: Add _Memory_Fill() Update #3838.
    Comment 9
    1. Sebastian Huber, Tue, 04 Feb 2020 06:03:34 GMT

    In ffa1153/rtems:

    bsps: Add RamEnd? to linker command files Update #3838.
    Comment 10
    1. Sebastian Huber, Tue, 04 Feb 2020 06:03:37 GMT

    In 34a7a12f/rtems:

    bsps: Add RTEMS_SYSINIT_BSP_EARLY Add new BSP system initialization step for work to be performed before the work areas are initialized. Update #3838.
    Comment 11
    1. Sebastian Huber, Tue, 04 Feb 2020 06:03:41 GMT

    In c184b0c/rtems:

    stackchk: Add RTEMS_SYSINIT_ISR_STACK Use a dedicated system initialization step for the stack checker interrupt stack support. Update #3838.
    Comment 12
    1. Sebastian Huber, Tue, 04 Feb 2020 06:03:45 GMT

    In 07e2eac/rtems:

    bsps: Remove uses of BSP_GET_WORK_AREA_DEBUG The code covered by BSP_GET_WORK_AREA_DEBUG was basically dead code since there was no normal way to activate it (e.g. via a BSP configuration option). A follow up patch will bring back this feature through a CONFIGURE_VERBOSE_SYSTEM_INITIALIZATION configuration option. Update #3838.
    Comment 13
    1. Sebastian Huber, Tue, 04 Feb 2020 06:03:48 GMT

    In eea21eac/rtems:

    bsps: Rework work area initialization The work area initialization was done by the BSP through bsp_work_area_initialize(). This approach predated the system initialization through the system initialization linker set. The workspace and C program heap were unconditionally initialized. The aim is to support RTEMS application configurations which do not need the workspace and C program heap. In these configurations, the workspace and C prgram heap should not get initialized. Change all bsp_work_area_initialize() to implement _Memory_Get() instead. Move the dirty memory, sbrk(), per-CPU data, workspace, and malloc() heap initialization into separate system initialization steps. This makes it also easier to test the individual initialization steps. This change adds a dependency to _Heap_Extend() to all BSPs. This dependency will be removed in a follow up change. Update #3838.
    Comment 14
    1. Sebastian Huber, Tue, 04 Feb 2020 06:03:52 GMT

    In f7c5f94/rtems:

    sysinit: Add RTEMS_SYSINIT_ORDER_LAST_BUT_[1-9] Update #3838.
    Comment 15
    1. Sebastian Huber, Tue, 04 Feb 2020 06:03:56 GMT

    In c344e58/rtems:

    Use RTEMS_SYSINIT_ORDER_LAST_BUT_5 Use RTEMS_SYSINIT_ORDER_LAST_BUT_5 instead of RTEMS_SYSINIT_ORDER_LAST to allow applications and support functions to place system initialization handlers behind the standard handlers. Update #3838.
    Comment 16
    1. Sebastian Huber, Tue, 04 Feb 2020 06:22:23 GMT

    In 813ada5/rtems-docs:

    c-user: Update system initialization chapter Update #2408. Update #3838.
    Comment 17
    1. Sebastian Huber, Tue, 04 Feb 2020 08:58:48 GMT

    In 4205250/rtems-docs:

    bsp-howto: Rework system initialization chapter Update #2852. Update #3838.
    Comment 18
    1. Sebastian Huber, Tue, 04 Feb 2020 10:26:04 GMT

    In ccaec966/rtems:

    libtests/malloc04: Fix typo Update #3838.
    Comment 19
    1. Sebastian Huber, Fri, 14 Feb 2020 09:06:57 GMT

    In 33d89af/rtems:

    smpfatal09: Fix test case Update #3838.
    Comment 20
    1. Sebastian Huber, Thu, 02 Apr 2020 08:48:23 GMT
    2. blocking: changed from 3835, 3843, 3861 to 3835, 3843, 3861, 3925
    Comment 21
    1. Sebastian Huber, Thu, 02 Apr 2020 08:49:21 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    4. description: modified (diff)
    Comment 22
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3839 - RTEMS revision does not handle -

    Link https://devel.rtems.org/ticket/3839
    Id 3839
    Reporter Chris Johns
    Created 11 December 2019 15:41:47
    Modified 11 December 2019 15:57:43
    Owner Chris Johns
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    RTEMS configure logic that takes a version number and splits it into major, minor and revision values. The current release snapshots have a version number of 5.0.0-m1912 and this is not correct parsed.

    Comment 1
    1. Chris Johns, Wed, 11 Dec 2019 15:57:43 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 86c70e71/rtems:

    Support pasring - in a version string Closes #3839

    3840 - Add CONFIGURE_IMFS_ENABLE_MKFIFO

    Link https://devel.rtems.org/ticket/3840
    Id 3840
    Reporter Sebastian Huber
    Created 11 December 2019 16:35:57
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    Obsolete undocumented configuration options CONFIGURE_MAXIMUM_FIFOS and CONFIGURE_MAXIMUM_PIPES. Replace them with a new option: CONFIGURE_IMFS_ENABLE_MKFIFO.

    Comment 1
    1. Sebastian Huber, Wed, 11 Dec 2019 16:46:26 GMT

    In b1b6dd71/rtems:

    pipe: Use condition variables Use self-contained condition variables instead of Classic API barriers. This simplifies the implementation and configuration. Update #3840.
    Comment 2
    1. Sebastian Huber, Fri, 13 Dec 2019 09:10:31 GMT

    In 6f6091b3/rtems:

    config: Add CONFIGURE_IMFS_ENABLE_MKFIFO Obsolete undocumented configuration options CONFIGURE_MAXIMUM_FIFOS and CONFIGURE_MAXIMUM_PIPES. Replace these options with the new CONFIGURE_IMFS_ENABLE_MKFIFO configuration option. Update #3840.
    Comment 3
    1. Sebastian Huber, Fri, 13 Dec 2019 13:07:13 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d954241/rtems-docs:

    c-user: Document CONFIGURE_IMFS_ENABLE_MKFIFO Close #3840.
    Comment 4
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3841 - Add rtems_object_get_local_node()

    Link https://devel.rtems.org/ticket/3841
    Id 3841
    Reporter Sebastian Huber
    Created 12 December 2019 06:20:47
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    Add

    /**
    * @brief Get the local MPCI node number.
    *
    * @return The local MPCI node number.
    */
    uint16_t rtems_object_get_local_node( void );

    to avoid the direct use of internal data structures.

    Comment 1
    1. Sebastian Huber, Fri, 13 Dec 2019 09:10:38 GMT

    In a00dff42/rtems:

    rtems: Add and use rtems_object_get_local_node() Update #3841.
    Comment 2
    1. Sebastian Huber, Fri, 20 Dec 2019 06:18:15 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 2e02ee0/rtems-docs:

    c-user: Document rtems_object_get_local_node() Close #3841.
    Comment 3
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3842 - RSB RTEMS version message string is fixed to the git hash

    Link https://devel.rtems.org/ticket/3842
    Id 3842
    Reporter Chris Johns
    Created 12 December 2019 15:18:06
    Modified 12 December 2019 16:14:05
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The version embedded in the RTEMS version message is currently the git hash. This breaks in a release where the version is reported as no-repo. The RTEMS version message is embedded in the gcc version string.

    Comment 1
    1. Chris Johns, Thu, 12 Dec 2019 16:14:05 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 5f2a4d2/rtems-source-builder:

    rtems: Set the RTEMS release message's RSB version correctly Closes #3842

    3843 - Add CONFIGURE_DIRTY_MEMORY

    Link https://devel.rtems.org/ticket/3843
    Id 3843
    Reporter Sebastian Huber
    Created 16 December 2019 07:51:32
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type enhancement
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by 3838

    Description

    Change the BSP_DIRTY_MEMORY BSP option (build-time configuration) into a CONFIGURE_DIRTY_MEMORY application configuration option (link-time configuration).

    Comment 1
    1. Sebastian Huber, Tue, 04 Feb 2020 14:13:44 GMT

    Should this be a boolean feature macro or should we allow to specify the byte used to dirty the memory?

    #define CONFIGURE_DIRTY_MEMORY 

    vs.

    #define CONFIGURE_DIRTY_MEMORY 0xab 
    Comment 2
    1. Sebastian Huber, Mon, 10 Feb 2020 08:00:28 GMT

    In 2d07ce6/rtems:

    config: Add CONFIGURE_DIRTY_MEMORY Replace the BSP_DIRTY_MEMORY BSP option with a CONFIGURE_DIRTY_MEMORY configuration option. Update #3843.
    Comment 3
    1. Sebastian Huber, Mon, 10 Feb 2020 12:49:16 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In e57733a/rtems-docs:

    c-user: Document CONFIGURE_DIRTY_MEMORY Close #3843.
    Comment 4
    1. Sebastian Huber, Tue, 11 Feb 2020 06:27:17 GMT

    In 0cdd482/rtems-docs:

    c-user: Clarify CONFIGURE_DIRTY_MEMORY Update #3843.
    Comment 5
    1. Sebastian Huber, Tue, 11 Feb 2020 06:34:22 GMT

    In c95724b/rtems-docs:

    c-user: Use contents instead of content The memory values are countable. Update #3843.
    Comment 6
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3844 - Remove CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE

    Link https://devel.rtems.org/ticket/3844
    Id 3844
    Reporter Sebastian Huber
    Created 17 December 2019 08:03:28
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove the CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE configuration option. The RTEMS configuration should be done via explicit configuration options to allow more freedom for implementation changes. The CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE configuration option had no test case. There was an attempt to get user feedback about this option:

    ​https://lists.rtems.org/pipermail/users/2019-April/033131.html

    Comment 1
    1. Sebastian Huber, Thu, 19 Dec 2019 07:55:51 GMT

    In e6f2b54/rtems:

    config: CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE Remove CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE. Update #3844.
    Comment 2
    1. Sebastian Huber, Thu, 19 Dec 2019 07:57:45 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 89e23da/rtems-docs:

    c-user: CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE Remove CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE. Close #3844.
    Comment 3
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3845 - Remove Ada-specific configuration options

    Link https://devel.rtems.org/ticket/3845
    Id 3845
    Reporter Sebastian Huber
    Created 17 December 2019 13:47:37
    Modified 23 June 2021 07:16:03
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    We have currently three Ada related configuration options:

    • CONFIGURE_GNAT_RTEMS
    • CONFIGURE_MAXIMUM_ADA_TASKS
    • CONFIGURE_MAXIMUM_FAKE_ADA_TASKS

    The CONFIGURE_MAXIMUM_FAKE_ADA_TASKS option has no effect. The CONFIGURE_GNAT_RTEMS is mandatory to use the CONFIGURE_MAXIMUM_ADA_TASKS option. So, if you just use

    #define CONFIGURE_MAXIMUM_ADA_TASKS 123

    then you get a re-definition warning and hopefully pay attention to it. This is not very user friendly from point of view.

    The CONFIGURE_MAXIMUM_ADA_TASKS just adds the configured count to CONFIGURE_MAXIMUM_POSIX_THREADS.

    The original purpose of these was to:

    CONFIGURE_GNAT_RTEMS - add in resources required by Ada run-time independent
    of the number of Ada tasks (e.g. POSIX threads)

    CONFIGURE_MAXIMUM_ADA_TASKS - add in POSIX threads, condition variable,
    and mutex required for each Ada task

    CONFIGURE_MAXIMUM_FAKE_ADA_TASKS - add in condition variables and mutex
    required by Ada run-time for a task/thread created outside the Ada run-time which
    invokes Ada code and is thus a user of the run-time.

    Given that you can turn on unlimited threads now and condition variables and mutexes
    are static, I don't think they have a need any longer. Plus it sounds like they bit rotted.
    If we needed them still, they would have to be fixed.

    We still need documentation that Ada tasks are POSIX threads and must be accounted
    for in configuring the system. So when moving documentation around, please make that
    point clear in the CONFIGURE_MAXIMUM_POSIX_THREADS description.

    See also:

    ​https://lists.rtems.org/pipermail/devel/2019-December/056523.html

    Comment 1
    1. Sebastian Huber, Thu, 19 Dec 2019 07:55:58 GMT

    In 88c198b/rtems:

    config: Remove Ada configuration options Update #3845.
    Comment 2
    1. Sebastian Huber, Thu, 19 Dec 2019 07:57:49 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In da309b9/rtems-docs:

    c-user: Remove Ada configuration options Close #3845.
    Comment 3
    1. Sebastian Huber, Thu, 19 Dec 2019 09:19:25 GMT

    In 51fd6b4/rtems:

    config: Fix CONFIGURE_MAXIMUM_POSIX_THREADS Bug was introduced by previous commit. Update #3845.
    Comment 4
    1. Sebastian Huber, Wed, 23 Jun 2021 07:16:03 GMT
    2. keywords: qualification added

    3848 - Libdebugger test in libbsd should depend on libdebugger.a

    Link https://devel.rtems.org/ticket/3848
    Id 3848
    Reporter Chris Johns
    Created 21 December 2019 04:21:55
    Modified 5 March 2020 11:05:19
    Owner Chris Johns
    Type defect
    Component network/libbsd
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The test should be built based on this library being present. The PowerPC does not support libdebugger.

    Attachments:

    1 Chris Johns, Wed, 04 Mar 2020 11:53:19 GMT
      attach: set to libbsd-library-check.diff
     
    Comment 1
    1. Chris Johns, Sat, 21 Dec 2019 04:22:15 GMT
    2. summary: changed from Libdebugger test in libbsd should depend on liubdebugger.a to Libdebugger test in libbsd should depend on libdebugger.a
    Comment 2
    1. Chris Johns, Wed, 04 Mar 2020 11:53:45 GMT

    It looks like debugger.h is being installed when there is no support and this is tripping the test in libbsd so it thinks there is libdebugger support.

    I attach a patch to add a library check however this fails because of link errors for a BSP that has the library.

    It looks like the include install support in RTEMS needs to be fixed.

    Comment 3
    1. Chris Johns, Thu, 05 Mar 2020 10:16:03 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 4
    1. Chris Johns, Thu, 05 Mar 2020 11:05:19 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3849 - Fix PSIM memory map

    Link https://devel.rtems.org/ticket/3849
    Id 3849
    Reporter Sebastian Huber
    Created 2 January 2020 11:53:27
    Modified 6 March 2020 03:29:17
    Owner Joel Sherrill <joel@…>
    Type defect
    Component arch/powerpc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    b08278e/rtems leads to the following run-time error on PSIM:

    BATs must not overlap; area 0x08000000..0x09000000 hits DBAT 0
    BATs must not overlap; area 0x0c000000..0x0d000000 hits DBAT 0

    The RAM overlaps with the PCI area:

     /*
    * Setup BATs and enable MMU
    */
    /* Memory */
    setdbat(0, 0x0<<28, 0x0<<28, 1<<28, _PAGE_RW);
    setibat(0, 0x0<<28, 0x0<<28, 1<<28, 0);
    /* PCI */
    setdbat(1, 0x8<<24, 0x8<<24, 1<<24, IO_PAGE);
    setdbat(2, 0xc<<24, 0xc<<24, 1<<24, IO_PAGE);

    Increasing the RAM size to 256MiB (0x10000000) on PSIM breaks also the shared memory support:

    typedef struct {
    /* 0x0c000000 - 0x0c007FFF - AMD 29F040 */
    volatile uint8_t Flash[ 512 * 1024 ];
    /* 0x0c080000 - 0x0c0FFFFF - NVRAM/NVRAM */
    volatile uint8_t nvram[ 512 * 1024 ];
    /* 0x0c100000 - 0x0c100007 - NVRAM/RTC */
    psim_rtc_t RTC;
    /* 0x0c100008 - 0x0c10000F - NVRAM/RTC */
    uint8_t gap1[8];
    /* 0x0c100010 - 0x0c10001b - System V IPC Semaphore */
    psim_sysv_sem_t Semaphore;
    /* 0x0c10001c - 0x0c10001f - NVRAM/RTC */
    uint8_t gap2[4];
    /* 0x0c100020 - 0x0c10005F - Ethernet */
    volatile uint8_t Ethtap[ 64 ];
    /* 0x0c100060 - 0x0c10FFFF - NVRAM/RTC */
    uint8_t gap3[65440];
    /* 0x0c110000 - 0x0c12FFFF - System V IPC Shared Memory */
    uint8_t SharedMemory[ 128 * 1024 ];
    /* 0x0c130000 - 0x0c170000 - OpenPIC IRQ Controller */
    volatile uint8_t OpenPIC[ 256 * 1024 ];
    } psim_registers_t;

    Proposed solution is to adjust the memory map so that 256MiB of RAM are supported. Probably needs changes in rtems-tools.

    Comment 1
    1. Joel Sherrill, Thu, 05 Mar 2020 22:58:03 GMT

    The code posted here misses the most important part -- the simulator device tree (​https://git.rtems.org/rtems-tools/tree/tester/rtems/testing/bsps/psim-device-tree). All of the device addresses start with 0x0c000000 which was OK when the RAM was smaller. But increasing the RAM to 256MB (0x10000000) resulted in the RAM overlapping the devices. The simplest option I see is to change the leading 0x0c... to 0xfc... in all device addresses and avoid the conflict.

    As best I can tell, the set of changes is pretty small:

    Change rtems-tools/tester/testing/bsps/psim-device-tree to use 0xFC for all devices. This reconfigures the "hardware" Change rtems/bsps/powerpc/psim/linkcmds to change new base address of of all the devices which are at the symbol PSIM Delete rtems/bsps/powerpc/start/device-tree and update the BSP README to note where the device tree file is. Also update the README to note that you don't need a modified gdb since the modifications have been in since the last century and no one knows the papyrus BSP anymore. I can't even remember it. Change rtems/bsps/start/bspstart.c to fix 0x0c to 0xfc in the PCI setdbat calls. Note: I don't remember how a base address is broken down to be passed in

    I think that's it.

    Comment 2
    1. Joel Sherrill, Fri, 06 Mar 2020 03:27:01 GMT

    In 097ea1e/rtems:

    psim: Rework device tree so devices do not conflict with 256MB RAM updates #3849.
    Comment 3
    1. Joel Sherrill, Fri, 06 Mar 2020 03:29:17 GMT
    2. owner: set to Joel Sherrill <joel@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 3833c39/rtems-tools:

    psim-device-tree: Rework so devices do not conflict with 256MB RAM closes #3849.

    3856 - posix_devctl - Add support for SOCKCLOSE

    Link https://devel.rtems.org/ticket/3856
    Id 3856
    Reporter Joel Sherrill
    Created 15 January 2020 17:37:41
    Modified 17 January 2020 22:13:45
    Owner Joel Sherrill
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords posix, conformance, compliance
    Cc  
    Blocking  
    Blocked by  

    Description

    The FACE Technical Standard, Edition 3.0 and later require the definition of the subcommand SOCKCLOSE in .

    Reference: ​https://www.opengroup.org/face

    The SOCKCLOSE constant has previously been added to in newlib.

    Comment 1
    1. Joel Sherrill, Fri, 17 Jan 2020 22:13:45 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 5e7b3c65/rtems:

    posix_devctl - Add support for SOCKCLOSE The FACE Technical Standard, Edition 3.0 and later require the definition of the subcommand SOCKCLOSE in . Reference: ​​https://www.opengroup.org/face closes #3856.

    3857 - Use EAGAIN for POSIX mq wait in ISR error

    Link https://devel.rtems.org/ticket/3857
    Id 3857
    Reporter Joel Sherrill
    Created 24 January 2020 13:59:24
    Modified 1 February 2020 13:58:17
    Owner Joel Sherrill
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc Martin Erik Werner
    Blocking  
    Blocked by  

    Description

    POSIX message queues which are about to block in an ISR currently return ENOMEM. This is a status not listed by POSIX. The better status is EAGAIN per ​https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_receive.html.

    Comment 1
    1. Joel Sherrill, Fri, 24 Jan 2020 14:48:59 GMT

    In 565df31/rtems-docs:

    posix-users/message_passing.rst: Add status for cannot block in ISR Updates #3857.
    Comment 2
    1. Martin Erik Werner, Fri, 24 Jan 2020 14:49:35 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In e225545/rtems:

    Use EAGAIN for POSIX mq wait in ISR error Modify the status code returned by _CORE_message_queue_Submit() when it detects a wait about to happen in an ISR (which would be deadly) to return a status which translated to EAGAIN instead of ENOMEM. This is only relevant for POSIX message queues, since Classic API message queues cannot block on send. The motivation is to match the "most related" errno value returned from mq_send() and mq_timedsend() according to POSIX, via Open Group:
    [EAGAIN]
    The O_NONBLOCK flag is set in the message queue description associated with mqdes, and the specified message queue is full.
    or via the RTEMS POSIX users documentation
    EAGAIN
    The message queue is non-blocking, and there is no room on the queue for another message as specified by the mq_maxmsg.
    Neither of these matches the case ofi avoided ISR wait perfectly, but they seem to be the closest equivalent, unless it is desirable to keep a new non-standard error for this case. It is presumed that this is not desirable. The previously returned ENOMEM error value is not documented in either the Open Group or the RTEMS POSIX uses documentation. A companion patch corrects the documentation to include this error condition. Based on the discussion in: ​https://lists.rtems.org/pipermail/devel/2020-January/056891.html closes #3857. Message-Id:
    Comment 3
    1. Sebastian Huber, Sat, 01 Feb 2020 13:58:17 GMT

    In b4387313/rtems:

    psxmsgq03: Adjust test case Commit e22554535796fc29a7ed7c5e2338128e324a621d changed the error status from ENOMEM to EAGAIN. Update #3857.

    3859 - No output from joel scripts in telnet

    Link https://devel.rtems.org/ticket/3859
    Id 3859
    Reporter Chris Johns
    Created 29 January 2020 23:59:17
    Modified 13 August 2020 09:38:54
    Owner Chris Johns
    Type defect
    Component shell
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Running a joel script in a telnet session results in the output being sent to the global stdout. For example:

    $ telnet 1.2.3.4
    Trying 1.2.3.4...
    Connected to 1.2.3.4.
    Escape character is '^]'.
    RTEMS Shell on /dev/pty0. Use 'help' to list commands.
    [/] # cat j
    #! joel
    ls -las /
    [/] # ./j
    [/] #

    The bug is a new shell main loop task will default to the global stdout, stdin etc and has no information about the parent's std handles. A joel script runs in it's own work task and does not know the telnet's std handles.

    There are a related set of issues in the handling of the shell_env variable, POSIX key handling and the use of the external call rtems_shell_main_loop.

    The telnet example in libbsd has:

    static void
    telnet_shell(char *name, void *arg)
    {
    rtems_shell_env_t env;
    memset(&env, 0, sizeof(env));
    env.devname = name;
    env.taskname = "TLNT";
    env.login_check = NULL;
    env.forever = false;
    rtems_shell_main_loop(&env);
    }

    This is problematic as control of the env has been lost and this make backwards comptatable changes difficult. Control of this struct needs to be brought back under the shell code.

    Currently the posix key is set in the parent task only when the run entry point is used. The run's created shell_env is then passed to the shell's main loop task as an argument from which it is cloned. This means an env is malloced in each run call and again in the main loop of the shell.

    The current code leaks memory as repeated calls to a joel script in a shell will set the key over and over. The destructor is only called when the task is deleted. We have to assume the cleanup of any shell_env allocated externally to the shell code has to be handled externally.

    Setting the key in the main loop task is problematic because telnet code such as the example in libbsd uses a local stack shell_env and the key has a destructor that blindly free's the key's memory when a task is released.

    Changes:

  • Add parent_stdout, parent_stdin, and parent_stderr to the shell_env and set to the parent's std handles.
  • Add a managed flag to shell_env and only set when allocated by rtems_shell_init_env. Change rtems_shell_env_free to only free the shell_env if managed.
  • Remove all key sets and have only one in the shell's main loop code.
  • Change rtems_shell_init_env to get the current tasks key and clone that before cloning the global env.
  • Update rtems_shell_dup_current_env to set the parent std handles.
  • Have the main loop use the parent std handles rather than the global handles.
  • Check the magic field has been set in the shell's main loop and raise an error if not set. The only code to set this field should reside in shell.c. Code such as libbsd will need to call rtems_shell_dup_current_env.
  • Comment 1
    1. Sebastian Huber, Tue, 04 Feb 2020 16:25:01 GMT

    Sounds that it is currently pretty broken.

    What about changing the managed member into a destroy handler which is initialized by the constructor?

    Comment 2
    1. Chris Johns, Wed, 05 Feb 2020 02:14:46 GMT

    Replying to Sebastian Huber:

    Sounds that it is currently pretty broken.

    There seems to be a few overlapping issues that make things a little confusing.

    What about changing the managed member into a destroy handler which is initialized by the constructor?

    Yes, my patch I am testing does this. I have an issue on 4.11 where a printf line in changes what happens and I am not sure why. I need to resolve this. I will then create a 4.11 clone of this ticket and post a patch for that branch.

    Comment 3
    1. Chris Johns, Mon, 10 Feb 2020 21:59:43 GMT

    Replying to Chris Johns:

    I have an issue on 4.11 where a printf line in changes what happens and I am not sure why. I need to resolve this. I will then create a 4.11 clone of this ticket and post a patch for that branch.

    I have chased the issue down to how we set up the re-entrant struct newlib uses in our threads. My changes follow what exists ...

     FILE *input = fopen(shell_env->input, "r");
      if (input == NULL)
         error(...);
      stdin = input; 

    The only calls on stdin before the assignment are fileno(stdin) and this does not touch the re-entrant struct so the first call to libc after the assignment is setvbuf(stdout, NULL, _IONBF, 0); and newlib performs it's lazy initialisation and resets the re-entrant struct.

    This issue is present on 4.11 and 5 as far as I can see.

    Comment 4
    1. Chris Johns, Tue, 11 Feb 2020 00:26:20 GMT
    2. blockedby: set to 3870
    Comment 5
    1. Chris Johns, Mon, 17 Feb 2020 04:51:50 GMT

    It is not easy making a joel test because of the way we have used the linker mapped printf to printk.

    Comment 6
    1. Sebastian Huber, Mon, 17 Feb 2020 06:42:57 GMT

    Only printf(), puts(), and putchar() are wrapped. The shell related code should use fprintf() etc. Using printf() would be a bug.

    Comment 7
    1. Chris Johns, Mon, 17 Feb 2020 20:51:46 GMT

    A test is not easy as a shell test cannot use any standard commands, eg echo because these call printf. The post test patch provides a command that uses fprintf and this works enough to test the shell start, main loop, and input and output support.

    Comment 8
    1. Chris Johns, Tue, 18 Feb 2020 02:55:20 GMT
    2. blockedby: 3870 deleted
    Comment 9
    1. Sebastian Huber, Tue, 18 Feb 2020 06:06:14 GMT

    It is a bug that the echo command uses putchar(). It should use fputc(c, stdout).

    Comment 10
    1. Chris Johns, Tue, 18 Feb 2020 06:55:17 GMT

    Replying to Sebastian Huber:

    It is a bug that the echo command uses putchar(). It should use fputc(c, stdout).

    Could you please explain why?

    Other commands like ls use printf.

    Comment 11
    1. Sebastian Huber, Tue, 18 Feb 2020 07:02:47 GMT

    Every shell related code which uses printf(), puts(), putchar(), etc. which work on file descriptors is broken. The file descriptors are global. Only the stdin, stdout, and stderr file pointers are thread-specific.

    Comment 12
    1. Chris Johns, Tue, 18 Feb 2020 07:09:20 GMT

    But ls works nicely with telnet, actually all commands I know of work well with the redirection we implement. I am sorry you have lost here with your bug comment.

    My comments relate to our testsuite and the hack we have to switch printf via the linker to keep the tests as small as possible.

    Comment 13
    1. Sebastian Huber, Tue, 18 Feb 2020 07:27:06 GMT

    Sorry for the confusion. I checked the Newlib code and it actually uses stdout for printf(). I thought it uses directly a file descriptor, but this is not the case. I vaguely remember that Ralf changed some printf() to fprintf(stdout, ...) for whatever reason.

    Comment 14
    1. Chris Johns, Thu, 09 Apr 2020 00:21:41 GMT

    I have found the default command handler in libbsd needs updating ...

    ​https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/telnetd/telnetd-service.c#n72

    The input and output fields needs have strings. I will change the shell's handling of NULL to reference the parent descriptors to catch user's code.

    Comment 15
    1. Chris Johns, Tue, 14 Apr 2020 22:30:49 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d007cc2/rtems:

    libmisc/shell: Fix the handling of joel scripts in telnet Fix the passing of std[in/out] to child threads Fix deleting of managed memory in the key destructor Only set the key in the main loop thread Only allocate a shell env outside of the main loop Fix memory leak if the task start fails Remove error level from shell env, it cannot be returned this way. Add exit_code but the API is broken so it cannot be returned. Closes #3859
    Comment 16
    1. Sebastian Huber, Thu, 06 Aug 2020 06:47:29 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    The telnet shell

    static void
    telnet_shell(char *name, void *arg)
    {
        rtems_shell_env_t env;
        memset(&env, 0, sizeof(env));
        env.devname = name;
        env.taskname = "TLNT";
        env.login_check = NULL;
        env.forever = false;
        rtems_shell_main_loop(&env);
    } 

    used in the libbsd test code is now broken:

    telnet 169.254.140.254
    Trying 169.254.140.254...
    Connected to 169.254.140.254.
    Escape character is '^]'.
    invalid shell environment passed to the main loop)
    Connection closed by foreign host. 

    How should the code be instead?

    Comment 17
    1. Sebastian Huber, Thu, 06 Aug 2020 06:50:18 GMT
    2. severity: changed from normal to blocker
    Comment 18
    1. Sebastian Huber, Thu, 06 Aug 2020 06:51:07 GMT

    There should be an advice in the migration section in the user manual.

    Comment 19
    1. Chris Johns, Thu, 06 Aug 2020 10:42:21 GMT

    The example code provided is broken and has always been broken. I only know it exists because libbsd had it. The ticket describes the situation and item 7) in the list says how it is to be resolved and that interface has always been there for just this situation.

    Please unblock this ticket. Thanks.

    Comment 20
    1. Sebastian Huber, Thu, 06 Aug 2020 11:17:13 GMT

    I have to fix the code in libbsd. This code was also copied to applications which are now also broken. This is definitely something for the migration section.

    Comment 21
    1. Chris Johns, Thu, 06 Aug 2020 11:51:15 GMT

    Thanks and yes something should be added. I will take a look.

    Comment 22
    1. Sebastian Huber, Thu, 06 Aug 2020 11:58:17 GMT

    Replying to Chris Johns:

    Thanks and yes something should be added. I will take a look.

    ​https://lists.rtems.org/pipermail/devel/2020-August/061166.html

    I already fixed libbsd (the commits don't show up in the tickets).

    Comment 23
    1. Sebastian Huber, Thu, 06 Aug 2020 17:22:46 GMT

    The proposed fix doesn't work. If you close a telnet session and try to connect again the target crashes with a NULL pointer access:

    #0  fileno (f=0x0) at ../../../../../../../../gnu-mirror-gcc-c72a1b6/newlib/libc/stdio/fileno.c:69
    #1  0x0042e866 in rtems_shell_main_loop (shell_env=0x0) at ../../../cpukit/libmisc/shell/shell.c:910
    #2  0x00104880 in telnet_shell (name=0x774600 "/dev/pty4", arg=0x0) at ../../testsuite/media01/test_main.c:133
    #3  0x004113e8 in telnetd_session_task (arg=7816628) at ../../../cpukit/telnetd/telnetd.c:179
    #4  0x00425f78 in _Thread_Handler () at ../../../cpukit/score/src/threadhandler.c:143 
    Comment 24
    1. Sebastian Huber, Fri, 07 Aug 2020 07:10:16 GMT

    The following change fixes the NULL pointer access:

    diff --git a/cpukit/libmisc/shell/shell.c b/cpukit/libmisc/shell/shell.c
    index 0b06e8b4d1..72aeb23c43 100644
    --- a/cpukit/libmisc/shell/shell.c
    +++ b/cpukit/libmisc/shell/shell.c
    @@ -234,12 +234,6 @@ static void rtems_shell_clear_shell_env(void)
       eno = pthread_setspecific(rtems_shell_current_env_key, NULL);
       if (eno != 0)
         rtems_error(0, "pthread_setspecific(shell_current_env_key): clear");
    -
    -  /*
    -   * Clear stdin and stdout file pointers of they will be closed
    -   */
    -  stdin = NULL;
    -  stdout = NULL;
     }
     /* 

    What is the purpose of this code?

    Comment 25
    1. Chris Johns, Fri, 07 Aug 2020 07:18:44 GMT

    A thread instance that inherits the std* file handles does not close them, for example a joel script would close the parents session's handles.

    Comment 26
    1. Sebastian Huber, Fri, 07 Aug 2020 07:25:05 GMT

    Setting the stdin and stdout to NULL pointers doesn't look like a good idea to me. I still don't understand what you want to do with this. Which code reads the stdin and stdout pointers and checks them for NULL?

    Comment 27
    1. Chris Johns, Fri, 07 Aug 2020 07:28:25 GMT

    Nothing more than what was in the code before .. ​https://git.rtems.org/rtems/tree/cpukit/libmisc/shell/shell.c?h=4.11#n242 Something else must has changed. I had tested it on RTEMS 5.

    Comment 28
    1. Sebastian Huber, Fri, 07 Aug 2020 07:31:24 GMT

    I have this problem on the RTEMS 5 branch using RTEMS 5 tools.

    Comment 29
    1. Chris Johns, Fri, 07 Aug 2020 07:33:38 GMT

    Yes I am seeing it as well. I am little confused.

    I am not sure why the closing of a previous session would effect a new session as the parent (telnetd) should be handling this. The new session should have a new set of std* handles?

    Comment 30
    1. Sebastian Huber, Fri, 07 Aug 2020 07:42:18 GMT

    For my taste the shell code tinkers too much with the std* handles. I lost track who is responsible for set up and tear down. What is the purpose of the

     FILE *parent_stdin;
      FILE *parent_stdout;
      FILE *parent_stderr; 

    Who is the parent?

    Comment 31
    1. Chris Johns, Fri, 07 Aug 2020 07:49:21 GMT

    I have a pretty good handle (hah pun intended) on these handles. I will try and take a look.

    The parent handles are the wrapper of the shell env. For example they are global handles for a console shell. With telnetd they are the session handles. If you run a joel script they are ones used:

    [/] # cat j
    #! joel
    ls -las /
    cat /j
    [/] # ./j
    total 6
    0 drwxr-xr-x   1 root  root   6160 Jan  1  1988 dev
    0 drwxr-xr-x   1 root  root   2240 Jan  1  1988 etc
    0 -rwxrwxrwx   1 root  root     31 Jan  1  1988 j
    1 drwx--x--x   3 root  root    512 Jan  1  1988 ram
    0 drwxr-xr-x   1 root  root      0 Jan  1  1988 tmp
    0 drwxr-xr-x   1 root  root    280 Jan  1  1988 var
    #! joel
    ls -las /
    cat /j 

    The threads that run the joel script inherit the telnet session handlers.

    Comment 32
    1. Chris Johns, Sat, 08 Aug 2020 07:45:29 GMT

    I have looked into the issue and the reuse of the telnetd session thread is clashing with the way the shell's environment is currently being cleaned up. The telnetd software creates a number of sessions and it reuses these sessions for the incoming connections. This means the pty file handles assigned to each session are reused. Clearing these file handles corrupts the telnetd session.

    Setting of stdin, stdout and also stderr to NULL when cleaning up a shell environment is important because thread termination closes those files if present and open and if the file pointers have been inherited from the parent thread the parent can be left without a valid stdin, stdout and stderr. This happens with a joel script. It could also happen with a command that is placed in the background (if we supported this) or a command that dispatches a worker thread.

    This ticket was originally about a bug where joel script output was not redirected to the parent thread's stdout. They happened to work for the console because the console shell's standard handles are the global ones. A new thread inherits the global handles and the clean up also manages the closing of those, or the lack of it. However a joel script with telnet was broken.

    The solution is to move the setting of stdin, stdout and stderr out of clearing the environment and to only do this when the rtems_shell_task exits the rtems_shell_main_loop.

    For the record a debug trace from shell.c running a joel script is:

    shell[0a010001]: run: env: 0x62accd0
    shell[0a010001]: run out: 1 (0xbeb028)
    shell[0a010001]: run  in: 0 (0xbeafa8)
    shell[0a01001c]: env: 0x62accd0
    shell[0a01001c]: child out: 1 (0xbeb028)
    shell[0a01001c]: child  in: 0 (0xbeafa8)
    shell[0a010017]: dup: global: copy: 0x2f5d1b8 out: 166 (0x2f02738) in: 165 (0x2f026b8)
    shell[0a010017]: env: 0x2f5d1b8
    shell[0a010017]: child out: 166 (0x2f02738)
    shell[0a010017]: child  in: 165 (0x2f026b8)
    shell[0a010017]: script: in: /j out: stdout
    shell[0a010017]: run: env: 0x63558a8
    shell[0a010017]: run out: 166 (0x2f02738)
    shell[0a010017]: run  in: 165 (0x2f026b8)
    shell[0a01001d]: env: 0x63558a8
    shell[0a01001d]: child out: 166 (0x2f02738)
    shell[0a01001d]: child  in: 35 (0x629b260)
    shell[0a01001d]: end: 0 0
    shell[0a01001d]: child in-to-close: 0x629b260
    shell[0a01001d]: child out-to-close: 0
    shell[0a010017]: run: end: sc:0 ec:0
    shell[0a010017]: script: end: 0
    shell[0a010017]: end: 0 0
    shell[0a010017]: child in-to-close: 0
    shell[0a010017]: child out-to-close: 0 
    Comment 33
    1. Chris Johns, Mon, 10 Aug 2020 05:13:42 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    In 95036a45/rtems:

    shell: Only clear std handles when the shell task exits Clearing the std file handles when the main loop exited crashes telnetd as it reuses its session threads. Closes #3859
    Comment 34
    1. Sebastian Huber, Mon, 10 Aug 2020 09:47:45 GMT

    In cb4358c/rtems-docs:

    user: Add shell environment migration aid Update #3859.
    Comment 35
    1. Sebastian Huber, Thu, 13 Aug 2020 09:38:54 GMT

    In 49f7e05/rtems-docs:

    user: Fix format Update #3859.

    3861 - Add CONFIGURE_VERBOSE_SYSTEM_INITIALIZATION

    Link https://devel.rtems.org/ticket/3861
    Id 3861
    Reporter Sebastian Huber
    Created 4 February 2020 05:23:46
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type enhancement
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by 3838

    Description

    Add a configuration option to print some information during system initialization.

    Comment 1
    1. Sebastian Huber, Tue, 04 Feb 2020 06:03:59 GMT

    In e44ae80/rtems:

    config: Add CONFIGURE_VERBOSE_SYSTEM_INITIALIZATION Update #3861.
    Comment 2
    1. Sebastian Huber, Tue, 04 Feb 2020 06:05:02 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 069bfac/rtems-docs:

    c-user: Add CONFIGURE_VERBOSE_SYSTEM_INITIALIZATION Close #3861.
    Comment 3
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3862 - Canonicalize CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY

    Link https://devel.rtems.org/ticket/3862
    Id 3862
    Reporter Sebastian Huber
    Created 4 February 2020 10:46:29
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type enhancement
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    The CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY configuration option is documented to be a boolean feature macro (is defined or undefined). However, in confdefs.h it uses the values TRUE and FALSE. It is the only configuration option implemented like this. Change it to use defined/undefined instead like the other options. This affects existing application configurations which use:

    #define CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY FALSE 

    An unintentional zero of the workspace has an effect on the system boot time. This is an acceptable trade-off for the more canonical configuration.

    Comment 1
    1. Sebastian Huber, Thu, 06 Feb 2020 14:22:27 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 1d43a97/rtems:

    config: CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY Canonicalize CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY and use defined/undefined instead of TRUE/FALSE. Close #3862.
    Comment 2
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3863 - Remove support for the BSP_ZERO_WORKSPACE_AUTOMATICALLY BSP option

    Link https://devel.rtems.org/ticket/3863
    Id 3863
    Reporter Sebastian Huber
    Created 4 February 2020 10:56:55
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    BSPs had the option to enable the CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY via the BSP_ZERO_WORKSPACE_AUTOMATICALLY BSP option. There is no BSP which defines this option. In addition, it makes no sense that a BSP can influence this high level system configuration.

    Comment 1
    1. Sebastian Huber, Thu, 06 Feb 2020 14:22:20 GMT

    In cadff8f7/rtems:

    config: Remove BSP_ZERO_WORKSPACE_AUTOMATICALLY Update #3863.
    Comment 2
    1. Sebastian Huber, Thu, 06 Feb 2020 14:24:19 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In df2dcdb/rtems-docs:

    Remove BSP_ZERO_WORKSPACE_AUTOMATICALLY Close #3863.
    Comment 3
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3864 - rtems-tester does not work with gdb simulators

    Link https://devel.rtems.org/ticket/3864
    Id 3864
    Reporter Joel Sherrill
    Created 4 February 2020 20:33:36
    Modified 29 March 2020 23:04:57
    Owner Chris Johns
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    It appears that something has broken with the rtems-tester on gdb simulators. On the latest run, I had to kill the tester by hand when it hung. On other times, it appears to abort with a lock issue.

    Comment 1
    1. Joel Sherrill, Tue, 04 Feb 2020 20:33:45 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Chris Johns, Fri, 27 Mar 2020 04:53:21 GMT

    I m looking into this and I cannot get psim-run to work with the latest tools and kernel. I get ...

    $ rtems-test --rtems-bsp=psim-run `find . -name hello.exe`
    RTEMS Testing - Tester, 5.0.not_released
     Command Line: /opt/work/rtems/5/bin/rtems-test --rtems-bsp=psim-run ./powerpc-rtems5/c/psim/testsuites/samples/hello.exe
     Host: FreeBSD hihi 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64
     Python: 3.7.6 (default, Jan 30 2020, 01:18:54) [Clang 6.0.1 (tags/RELEASE_601/final 335540)]
    Host: FreeBSD-12.1-RELEASE-p2-amd64-64bit-ELF (FreeBSD hihi 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64 amd64)
    [1/1] p:0 f:0 u:0 e:0 I:0 B:0 t:0 i:0 W:0 | powerpc/psim: hello.exe
    [1/1] p:0 f:0 u:0 e:0 I:0 B:0 t:0 i:0 W:0 | powerpc/psim: hello.exe
    Result: invalid    Time: 0:00:01.002526 hello.exe
    =>  run: /opt/work/rtems/5/bin/powerpc-rtems5-run -f /opt/work/rtems/5/share/rtems/tester/rtems/testing/bsps/psim-device-tree ./powerpc-rtems5/c/psim/testsuites/samples/hello.exe
    ] core_find_mapping() - access to unmaped address, attach a default map to handle this - addr=0xfc131000 nr_bytes=0x4 processor=0x8e7a40 cia=0x15d8
    ]
    Passed:        0
    Failed:        0
    User Input:    0
    Expected Fail: 0
    Indeterminate: 0
    Benchmark:     0
    Timeout:       0
    Invalid:       1
    Wrong Version: 0
    Wrong Build:   0
    Wrong Tools:   0
    ----------------
    Total:         1
    Invalid:
     hello.exe
    Average test time: 0:00:01.286947
    Testing time     : 0:00:01.286947 

    Has the psim device tree been updated?

    Comment 3
    1. Chris Johns, Fri, 27 Mar 2020 05:45:26 GMT

    Crashing at ..

     t = openpic_read(&OpenPIC->Global.Feature_Reporting0);
        15d4:       39 2b 10 00     addi    r9,r11,4096
            __asm__ __volatile__("lwbrx %0,0,%1; eieio" : "=r" (ret) : 
    Comment 4
    1. Chris Johns, Fri, 27 Mar 2020 06:19:54 GMT

    The rtems-tools master works. I will now check my tools build.

    Comment 5
    1. Chris Johns, Sun, 29 Mar 2020 23:03:48 GMT

    In 753eb94/rtems-tools:

    tester/gdb: Add lock timing and remote fetching registers. Add timing for the locks to aid performance profiling Remove fetching registers as the MI parser is slow on pyton2 Updates #3864
    Comment 6
    1. Chris Johns, Sun, 29 Mar 2020 23:04:57 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3865 - Fix linker set item declarations for small data area targets

    Link https://devel.rtems.org/ticket/3865
    Id 3865
    Reporter Sebastian Huber
    Created 5 February 2020 07:39:33
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    Some targets (e.g. 32-bit PowerPC) have a small-data area. Linker set items are not in the small data area. We have to tell this the compiler, otherwise linker error may occur due to a mismatch of relocations. There are two options to do this.

  • We can declare items as an array of unspecified size and define items as an array with one element. The problem with this is that it breaks existing code, e.g. an item initializer would have to change.
  • We add the section to the declaration. The problem is that in this case we need a dedicated declaration macro for the ordered items.
  • Since item declarations are rarely used, we select option 2.

    Comment 1
    1. Sebastian Huber, Thu, 06 Feb 2020 14:22:17 GMT

    In 9fac9f9/rtems:

    score: Fix linker sets on small data area targets Update #3865.
    Comment 2
    1. Sebastian Huber, Thu, 06 Feb 2020 14:24:21 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a4b23d9/rtems-docs:

    c-user: Document new linker set macros Adjust copyright. Linker sets were introduced in 2015. Update #2408. Close #3865.
    Comment 3
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3868 - newlib links breaks mingw build

    Link https://devel.rtems.org/ticket/3868
    Id 3868
    Reporter Chris Johns
    Created 10 February 2020 00:47:07
    Modified 12 February 2020 03:48:59
    Owner Chris Johns <chrisj@…>
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The following patch in newlib adds links and Windows does not have symlinks and it is emulated as copy. This complicates a bsdtar extraction of source ...

    ​https://github.com/RTEMS/sourceware-mirror-newlib-cygwin/commit/cfc4955234828881145a20987c8a0a3cd373585c

    I tried the -E option that was added to the RSB to extract the tar file a second time, this has worked with other tar files with symlinks however it does not work. I have no investigated why.

    We need Windows building to make a release.

    __Note, this is in the tools/rsb component however is not an RSB bug. I need input on what the RSB needs to do to fix this issue if that is the path we take.__

    Comment 1
    1. Chris Johns, Mon, 10 Feb 2020 05:12:53 GMT

    Hand testing with MSYS's tar (GNU tar) indicates links are handled with a suitable file copy.

    It could be changing the RSB from bsdtar to tar may be a workable solution. The use of bsdtar seems to be before 2012 ...

    ​https://git.rtems.org/rtems-source-builder/commit/?id=8f84a6b3a0bc7cbce09605f39329d3832682bf63

    I remember there was a number of issues getting the source unpacked on Windows. I can build arm tools with tar.

    Comment 2
    1. Chris Johns, Wed, 12 Feb 2020 03:48:59 GMT
    2. owner: set to Chris Johns <chrisj@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 22135c9/rtems-source-builder:

    windows: Use GNU tar to unpack source The bsdtar command does not handle symlinks cleanly, GNU tar does Closes #3868

    3871 - Remove rtems_configuration_get_posix_api_configuration()

    Link https://devel.rtems.org/ticket/3871
    Id 3871
    Reporter Sebastian Huber
    Created 13 February 2020 15:20:03
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    The corresponding data structure not longer exists. This function was not tested.

    Comment 1
    1. Sebastian Huber, Mon, 17 Feb 2020 07:46:52 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In f613778/rtems:

    Remove rtems_configuration_get_posix_api_configuration() The corresponding data structure not longer exists. This function was not tested and documented. Close #3871.
    Comment 2
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3873 - Remove CONFIGURE_HAS_OWN_INIT_TASK_TABLE

    Link https://devel.rtems.org/ticket/3873
    Id 3873
    Reporter Sebastian Huber
    Created 14 February 2020 07:09:03
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    The CONFIGURE_HAS_OWN_INIT_TASK_TABLE and CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE are the last *_HAS_OWN_* configuration options. These two options are probably unused, see also:

    ​https://lists.rtems.org/pipermail/users/2019-April/033129.html ​https://lists.rtems.org/pipermail/users/2019-April/033130.html

    Removing them simplifies the configuration. If there is a real user need which shows up after the removal, we can resurrect them on demand.

    Using CONFIGURE_HAS_OWN_INIT_TASK_TABLE would have required the use of the undocumented CONFIGURE_INIT_TASK_TABLE and CONFIGURE_INIT_TASK_TABLE_SIZE configuration options.

    Comment 1
    1. Sebastian Huber, Fri, 14 Feb 2020 07:21:04 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Fri, 14 Feb 2020 07:22:20 GMT
    2. description: modified (diff)
    Comment 3
    1. Sebastian Huber, Tue, 25 Feb 2020 11:32:37 GMT

    In 6b0873f/rtems:

    config: Remove CONFIGURE_HAS_OWN_INIT_TASK_TABLE The CONFIGURE_HAS_OWN_INIT_TASK_TABLE and CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE are the last *_HAS_OWN_* configuration options. These two options are probably unused, see also: ​https://lists.rtems.org/pipermail/users/2019-April/033129.html ​https://lists.rtems.org/pipermail/users/2019-April/033130.html Removing them simplifies the configuration. If there is a real user need which shows up after the removal, we can resurrect them on demand. Using CONFIGURE_HAS_OWN_INIT_TASK_TABLE would have required the use of the undocumented CONFIGURE_INIT_TASK_TABLE and CONFIGURE_INIT_TASK_TABLE_SIZE configuration options. Update #3873.
    Comment 4
    1. Sebastian Huber, Tue, 25 Feb 2020 11:32:40 GMT

    In 9520ec3/rtems:

    config: Simplify initialization task config With the removal of the CONFIGURE_HAS_OWN_INIT_TASK_TABLE configuration option at most one Classic API user initialization task can be configured. Provide an RTEMS API configuration table for backward compatibility. Update #3873.
    Comment 5
    1. Sebastian Huber, Tue, 25 Feb 2020 11:35:19 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 3738a74/rtems-docs:

    c-user: Obsolete CONFIGURE_HAS_OWN_INIT_TASK_TABLE The CONFIGURE_HAS_OWN_INIT_TASK_TABLE and CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE are the last *_HAS_OWN_* configuration options. These two options are probably unused, see also: ​https://lists.rtems.org/pipermail/users/2019-April/033129.html ​https://lists.rtems.org/pipermail/users/2019-April/033130.html Removing them simplifies the configuration. If there is a real user need which shows up after the removal, we can resurrect them on demand. Using CONFIGURE_HAS_OWN_INIT_TASK_TABLE would have required the use of the undocumented CONFIGURE_INIT_TASK_TABLE and CONFIGURE_INIT_TASK_TABLE_SIZE configuration options. Close #3873.
    Comment 6
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3874 - Remove CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE

    Link https://devel.rtems.org/ticket/3874
    Id 3874
    Reporter Sebastian Huber
    Created 14 February 2020 07:09:37
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    The CONFIGURE_HAS_OWN_INIT_TASK_TABLE and CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE are the last *_HAS_OWN_* configuration options. These two options are probably unused, see also:

    ​https://lists.rtems.org/pipermail/users/2019-April/033129.html ​https://lists.rtems.org/pipermail/users/2019-April/033130.html

    Removing them simplifies the configuration. If there is a real user need which shows up after the removal, we can resurrect them on demand.

    Using CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE would have required the use of the undocumented CONFIGURE_POSIX_INIT_THREAD_TABLE_NAME and CONFIGURE_POSIX_INIT_THREAD_TABLE_SIZE configuration options.

    Comment 1
    1. Sebastian Huber, Fri, 14 Feb 2020 07:21:21 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Tue, 25 Feb 2020 11:32:48 GMT

    In 3b4795b4/rtems:

    config: Remove CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE The CONFIGURE_HAS_OWN_INIT_TASK_TABLE and CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE are the last *_HAS_OWN_* configuration options. These two options are probably unused, see also: ​https://lists.rtems.org/pipermail/users/2019-April/033129.html ​https://lists.rtems.org/pipermail/users/2019-April/033130.html Removing them simplifies the configuration. If there is a real user need which shows up after the removal, we can resurrect them on demand. Using CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE would have required the use of the undocumented CONFIGURE_POSIX_INIT_THREAD_TABLE_NAME and CONFIGURE_POSIX_INIT_THREAD_TABLE_SIZE configuration options. Update #3874.
    Comment 3
    1. Sebastian Huber, Tue, 25 Feb 2020 11:35:21 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d10e3b1/rtems-docs:

    c-user: Obsolete CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE The CONFIGURE_HAS_OWN_INIT_TASK_TABLE and CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE are the last *_HAS_OWN_* configuration options. These two options are probably unused, see also: ​https://lists.rtems.org/pipermail/users/2019-April/033129.html ​https://lists.rtems.org/pipermail/users/2019-April/033130.html Removing them simplifies the configuration. If there is a real user need which shows up after the removal, we can resurrect them on demand. Using CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE would have required the use of the undocumented CONFIGURE_POSIX_INIT_THREAD_TABLE_NAME and CONFIGURE_POSIX_INIT_THREAD_TABLE_SIZE configuration options. Close #3874.
    Comment 4
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3875 - Split up confdefs.h in component based header files

    Link https://devel.rtems.org/ticket/3875
    Id 3875
    Reporter Sebastian Huber
    Created 14 February 2020 13:13:44
    Modified 17 November 2021 08:12:17
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    The confdefs.h header file is large, complex, and hard to review. Split it up into component header files to make it easier to maintain and review.

    The general approach is to place the default configuration of things in
    librtemscpu.a. The benefit is that the application configuration object file
    will only include data structures which have a user-defined value.

    The component based header files include their dependencies explicitly. It
    should be possible to include component based header files separately to ease
    testing. For example we could use this template:

     #ifndef _RTEMS_CONFDEFS_FOOBAR_H
    #define _RTEMS_CONFDEFS_FOOBAR_H
    #ifndef __CONFIGURATION_TEMPLATE_h
    #error "Do not include this file directly, use instead"
    #endif
    #if defined(CONFIGURE_INIT) && \
    defined(CONFIGURE_FOOBAR_STUFF) && \
    defined(CONFIGURE_MORE_FOOBAR_STUFF)
    /* Foobar includes */
    #ifdef __cplusplus
    extern "C" {
    #endif /* __cplusplus */
    /* Configure foobar. */
    #ifdef __cplusplus
    }
    #endif /* __cplusplus */
    #endif /* CONFIGURE_INIT */
    #endif /* _RTEMS_CONFDEFS_FOOBAR_H */

    In case CONFIGURE_INIT is not defined, then including should
    expose nothing to the C compiler.

    Here is a first proposal to group the configuration in components:

    rtems/
    confdefs.h
    This file just includes the component based header files listed below.
    confdefs/
    bdbuf.h
    classicobj.h
    Classic API objects
    classictasksinit.h
    Classic initialization task
    driverclock.h
    Clock driver and related configuration, e.g. CONFIGURE_MICROSECONDS_PER_TICK
    driverconsolesimple.h
    Simple console driver configuration
    driverlegacy.h
    Legacy IO driver configuration table
    extensions.h
    User extensions, internal extensions
    filesystem.h
    Filesystem configuration
    general.h
    Basic stuff which is mandatory to configure, e.g. ISR stacks, per-CPU information
    libpci.h
    PCI library configuration
    malloc.h
    Malloc configuration
    mpci.h
    MPCI specific configuration options
    msgq.h
    General message queue configuration
    obsolete.h
    Warning about the use of obsolete configure options
    posixkeys.h
    POSIX keys
    posixobj.h
    POSIX objects
    posixthreadsinit.h
    POSIX initialization threads
    scheduler.h
    Scheduler configuration
    support.h
    Support macros for confdefs header files
    threads.h
    General thread configuration (e.g. thread control block)
    unlimited.h
    Unlimited objects configuration
    Comment 1
    1. Sebastian Huber, Mon, 17 Feb 2020 07:47:03 GMT

    In 58864627/rtems:

    config: Remove unused declaration and defines Update #3875.
    Comment 2
    1. Sebastian Huber, Thu, 20 Feb 2020 07:56:45 GMT

    In 874a5ef/rtems-docs:

    c-user: Clarify CONFIGURE_MAXIMUM_PRIORITY Update #3875.
    Comment 3
    1. Sebastian Huber, Mon, 24 Feb 2020 06:32:45 GMT

    In 61a2b3e/rtems-docs:

    c-user: Clarify filesystem configuration Update #3875.
    Comment 4
    1. Sebastian Huber, Tue, 25 Feb 2020 11:32:26 GMT

    In f6fcfea1/rtems:

    mptests/mp14: Include missing header file Include for MPCI_Print_statistics(). Update #3875.
    Comment 5
    1. Sebastian Huber, Tue, 25 Feb 2020 11:32:30 GMT

    In 5d1d348/rtems:

    libtests/stackchk: Include missing header file Update #3875.
    Comment 6
    1. Sebastian Huber, Tue, 25 Feb 2020 11:32:33 GMT

    In 77ee827/rtems:

    sptests/spcbssched03: Include missing header file Update #3875.
    Comment 7
    1. Sebastian Huber, Tue, 25 Feb 2020 11:32:52 GMT

    In b8648bd/rtems:

    config: Add _Watchdog_Microseconds_per_tick Move the microseconds per tick configuration constant out of the configuration table. Add WATCHDOG_MICROSECONDS_PER_TICK_DEFAULT and use it to provide a default definition of the watchdog ticks constants. Update #3875.
    Comment 8
    1. Sebastian Huber, Tue, 25 Feb 2020 11:32:55 GMT

    In 308a2e0f/rtems:

    config: Add _Watchdog_Ticks_per_timeslice Move the ticks per timeslice configuration constant out of the configuration table. Add WATCHDOG_TICKS_PER_TIMESLICE_DEFAULT and use it to provide a default definition of the watchdog ticks per timeslice constant. Update #3875.
    Comment 9
    1. Sebastian Huber, Tue, 25 Feb 2020 11:32:58 GMT

    In c70d112/rtems:

    config: Add _Thread_Idle_stack_size Move the idle thread stack size configuration constant out of the configuration table. Add THREAD_IDLE_STACK_SIZE_DEFAULT and use it to provide a default definition of the idle thread stack size constant. Update #3875.
    Comment 10
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:01 GMT

    In 5180762c/rtems:

    config: Add _Thread_Idle_body Move the idle thread body configuration constant out of the configuration table. Provide a default definition of the idle thread body constant. Update #3875.
    Comment 11
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:04 GMT

    In ba7b2df7/rtems:

    config: Add _Workspace_Size Move the workspace size configuration constant out of the configuration table. Update #3875.
    Comment 12
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:08 GMT

    In ad85c00/rtems:

    config: Add _Workspace_Is_unified Move the unified workspace configuration constant out of the configuration table. Provide a default definition of the unified workspace constant. Update #3875.
    Comment 13
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:11 GMT

    In 567455b6/rtems:

    config: Add _SMP_Processor_configure_maximum Move the processor maximum configuration constant out of the configuration table. Update #3875.
    Comment 14
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:14 GMT

    In ba46b936/rtems:

    config: Add _SMP_Is_enabled Move the is SMP enabled configuration constant out of the configuration table. Since this was the last configuration constant in rtems_configuration_table, remove this type. Update #3875.
    Comment 15
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:42 GMT

    In 0561cc1/rtems:

    config: Remove _Configure_Max_Objects() Use rtems_resource_maximum_per_allocation() directly. The use of _Configure_Zero_or_one() was superfluous. Update #3875.
    Comment 16
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:45 GMT

    In cadd8d1/rtems:

    config: Add Unify handling of obsolete configuration options. Remove comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 17
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:49 GMT

    In 55a7316/rtems:

    config: Add Derive copyright and license for new file form the file history. Update #3875.
    Comment 18
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:52 GMT

    In f45d0b2f/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 19
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:55 GMT

    In 0f8e139e/rtems:

    config: Add Remove comments and copyrightable content from the moved content. Use BSD-2-Clause for new file according to file history of . Update #3053. Update #3875.
    Comment 20
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:59 GMT

    In 1608221/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 21
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:02 GMT

    In 591e9736/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 22
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:06 GMT

    In 691b614/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 23
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:09 GMT

    In 03aff2c/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Move the default configuration to library files so that application configurations do not include the definitions for the default case. Update #3053. Update #3875.
    Comment 24
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:13 GMT

    In 1d35bf2a/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 25
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:17 GMT

    In 32561f5/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 26
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:20 GMT

    In fb0caca/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 27
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:23 GMT

    In 8f3419b/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 28
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:27 GMT

    In b15d1cb/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 29
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:30 GMT

    In 8314933/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 30
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:34 GMT

    In fe84ab5/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 31
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:37 GMT

    In 7b6596f5/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 32
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:41 GMT

    In 40db051/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 33
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:44 GMT

    In f5a2fd86/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 34
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:48 GMT

    In d20209b/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 35
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:51 GMT

    In 35e58c45/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 36
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:55 GMT

    In 1fb1cf1/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Update #3053. Update #3875.
    Comment 37
    1. Sebastian Huber, Tue, 25 Feb 2020 11:34:59 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a78495ed/rtems:

    config: Add Remove all comments and copyrightable content from the moved content. Use BSD-2-Clause license for new file. Change licence of to BSD-2-Clause according to file history. Update #3053. Close #3875.
    Comment 38
    1. Sebastian Huber, Tue, 25 Feb 2020 13:03:49 GMT

    In 470dfa1f/rtems:

    config: Resurrect NULL_DRIVER_TABLE_ENTRY This define may be used by application configurations for the CONFIGURE_APPLICATION_EXTRA_DRIVERS definition. Update #3875.
    Comment 39
    1. Sebastian Huber, Wed, 04 Mar 2020 08:26:38 GMT

    In fdeaa64/rtems:

    config: Remove include The use of CONFIGURE_APPLICATION_NEEDS_TIMER_DRIVER does not define anything, so remove the include. Update #3875.
    Comment 40
    1. Sebastian Huber, Tue, 14 Apr 2020 14:30:16 GMT

    In 4f32722/rtems:

    config: Fix typo Update #3875.
    Comment 41
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added
    Comment 42
    1. Sebastian Huber, Wed, 17 Nov 2021 08:12:13 GMT

    In 32cee883/rtems:

    config: CONFIGURE_DISABLE_BSP_SETTINGS Evaluate CONFIGURE_DISABLE_BSP_SETTINGS for each affected application configuration option. This makes the code easier to review since the influence of CONFIGURE_DISABLE_BSP_SETTINGS is locally visible in the code. Update #3875.
    Comment 43
    1. Sebastian Huber, Wed, 17 Nov 2021 08:12:17 GMT

    In c47daf6f/rtems:

    config: Fix IO driver table initialization Check all IO driver table configuration options which are used to initialize _IO_Driver_address_table[]. Checks for the following settings were missing: CONFIGURE_BSP_PREREQUISITE_DRIVERS CONFIGURE_APPLICATION_PREREQUISITE_DRIVERS CONFIGURE_APPLICATION_NEEDS_WATCHDOG_DRIVER CONFIGURE_APPLICATION_EXTRA_DRIVERS Update #3875.

    3876 - Remove CONFIGURE_DISABLE_SMP_CONFIGURATION

    Link https://devel.rtems.org/ticket/3876
    Id 3876
    Reporter Sebastian Huber
    Created 15 February 2020 10:20:54
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    The CONFIGURE_DISABLE_SMP_CONFIGURATION configuration option and rtems_configuration_is_smp_enabled() were added during the SMP support development cycle as a workaround to fix some testsuite failures in SMP configurations. Replace this configuration option with tests for specific conditions. The configuration option was undocumented.

    Comment 1
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:20 GMT

    In 1ada3e55/rtems:

    score: Add _SMP_Need_inter_processor_interrupts() Test for the proper system condition instead of using the rtems_configuration_is_smp_enabled() workaround. Update #3876.
    Comment 2
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:24 GMT

    In 51614bd5/rtems:

    bsps/clock: Use _SMP_Get_processor_maximum() Use a specific test to enable the fast idle mode instead of using the rtems_configuration_is_smp_enabled() workaround. Update #3876.
    Comment 3
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:27 GMT

    In 5b8d80d7/rtems:

    config: CONFIGURE_INIT_TASK_INITIAL_MODES Determine the default for CONFIGURE_INIT_TASK_INITIAL_MODES depeding on whether RTEMS_SMP is defined or not. In the tests, use CONFIGURE_INIT_TASK_INITIAL_MODES to explicitly request RTEMS_NO_PREEMPT mode if necessary. Update #3876.
    Comment 4
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:30 GMT

    In e50e42b8/rtems:

    score: _Scheduler_Is_non_preempt_mode_supported() If the non-preempt mode for threads is supported depends on the scheduler implementation. Add _Scheduler_Is_non_preempt_mode_supported() to indicate this. Update #3876.
    Comment 5
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:33 GMT

    In ca82a603/rtems:

    rtems: Change timer server task mode setting Use the non-preempt mode only in uni-processor configurations. Update #3876.
    Comment 6
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:36 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In c7f748a/rtems:

    config: Remove CONFIGURE_DISABLE_SMP_CONFIGURATION The CONFIGURE_DISABLE_SMP_CONFIGURATION configuration option and rtems_configuration_is_smp_enabled() were added during the SMP support development cycle as a workaround to fix some testsuite failures in SMP configurations. All use cases were replaced with tests for specific conditions. The configuration option and test macro were undocumented. Close #3876.
    Comment 7
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3881 - Add API functions to map a task priority to/from a POSIX thread priority

    Link https://devel.rtems.org/ticket/3881
    Id 3881
    Reporter Sebastian Huber
    Created 24 February 2020 12:44:30
    Modified 3 March 2020 06:16:14
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Mapping task priorities to/from POSIX thread priorities is probably done in many applications. There seems to be no API to help doing this. Add the following API functions to map a task priority to/from a POSIX thread priority:

    /**
    * @brief Map a task priority to the corresonding POSIX thread priority.
    *
    * @param scheduler_id Identifier of the scheduler instance.
    * @param priority The task priority to map.
    * @param[out] posix_priority Pointer to a POSIX thread priority value.
    *
    * @retval RTEMS_SUCCESSFUL Successful operation.
    * @retval RTEMS_INVALID_ADDRESS The @a posix_priority parameter is @c NULL.
    * @retval RTEMS_INVALID_ID Invalid scheduler instance identifier.
    * @retval RTEMS_INVALID_PRIORITY Invalid task priority.
    */
    rtems_status_code rtems_scheduler_map_to_posix_priority(
    rtems_id scheduler_id,
    rtems_task_priority priority,
    int *posix_priority
    );
    /**
    * @brief Map a POSIX thread priority to the corresonding task priority.
    *
    * @param scheduler_id Identifier of the scheduler instance.
    * @param posix_priority The POSIX thread priority to map.
    * @param[out] priority Pointer to a task priority value.
    *
    * @retval RTEMS_SUCCESSFUL Successful operation.
    * @retval RTEMS_INVALID_ADDRESS The @a priority parameter is @c NULL.
    * @retval RTEMS_INVALID_ID Invalid scheduler instance identifier.
    * @retval RTEMS_INVALID_PRIORITY Invalid POSIX thread priority.
    */
    rtems_status_code rtems_scheduler_map_from_posix_priority(
    rtems_id scheduler_id,
    int posix_priority,
    rtems_task_priority *priority
    );
    Comment 1
    1. Sebastian Huber, Tue, 03 Mar 2020 06:14:42 GMT

    In 38736c6/rtems:

    rtems: Add rtems_scheduler_map_priority_to_posix() Update #3881.
    Comment 2
    1. Sebastian Huber, Tue, 03 Mar 2020 06:14:46 GMT

    In 18020109/rtems:

    rtems: Add rtems_scheduler_map_priority_from_posix() Update #3881.
    Comment 3
    1. Sebastian Huber, Tue, 03 Mar 2020 06:16:12 GMT

    In e458fed/rtems-docs:

    c-user: rtems_scheduler_map_priority_to_posix() Update #3881.
    Comment 4
    1. Sebastian Huber, Tue, 03 Mar 2020 06:16:14 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In ac61465/rtems-docs:

    c-user: rtems_scheduler_map_priority_from_posix() Close #3881.

    3882 - Add POSIX user environment pointer to TCB

    Link https://devel.rtems.org/ticket/3882
    Id 3882
    Reporter Sebastian Huber
    Created 25 February 2020 06:17:52
    Modified 25 February 2020 11:33:17
    Owner Sebastian Huber
    Type enhancement
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The IO library uses a POSIX key to store an optional POSIX user environment pointer. This pulls in the POSIX keys support in every application configuration. Add a user environment pointer to the thread control block (TCB) instead. Applications which do not need the POSIX user environment will just get an overhead of one pointer per thread.

    Comment 1
    1. Sebastian Huber, Tue, 25 Feb 2020 11:33:17 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In ba74ebde/rtems:

    libio: Add POSIX user environment pointer to TCB The IO library used a POSIX key to store an optional POSIX user environment pointer. This pulled in the POSIX keys support in every application configuration. Add a user environment pointer to the thread control block (TCB) instead. Applications which do not need the POSIX user environment will just get an overhead of one pointer per thread. Close #3882.

    3885 - Context switch extension is broken in SMP configurations

    Link https://devel.rtems.org/ticket/3885
    Id 3885
    Reporter Sebastian Huber
    Created 25 February 2020 17:40:26
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type defect
    Component score
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    The context switch extensions are called during _Thread_Do_dispatch():

    void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, ISR_Level level )
    {
    Thread_Control *executing;
    executing = cpu_self->executing;
    ...
    do {
    Thread_Control *heir;
    heir = _Thread_Get_heir_and_make_it_executing( cpu_self );
    ...
    _User_extensions_Thread_switch( executing, heir );
    ...
    _Context_Switch( &executing->Registers, &heir->Registers );
    ...
    } while ( cpu_self->dispatch_necessary );
    ...
    }

    In uniprocessor configurations, the context switch extensions are called for all thread switches except the very first thread switch to the initialization thread. However, in SMP configurations, the context switch may be invalidated and updated in the low-level _Context_Switch() routine. See:

    ​https://docs.rtems.org/branches/master/c-user/symmetric_multiprocessing_services.html#thread-dispatch-details

    In case such an update happens, a thread executes on the processor which was not visible to the context switch extensions. This can confuse for example event record consumers which use events generated by a context switch extension.

    Fixing this is not straight forward. The context switch extensions call must move after the low-level context switch. The problem here is that we may end up in _Thread_Handler(). Adding the context switch extensions call to _Thread_Handler() covers now also the thread switch to the initialization thread. We also have to save the last executing thread of the processor. Registers or the stack cannot be used for this purpose. We have to add it to the per-processor information. Existing extensions may be affected, since now context switch extensions use the stack of the heir thread.

    Calling the thread switch extensions in the low level context switch is difficult since at this point an intermediate stack is used which is only large enough to enable servicing of interrupts.

    Comment 1
    1. Joel Sherrill, Tue, 25 Feb 2020 18:34:30 GMT

    As I recall, doing this in _Thread_Handler is similar to having to restore FPU. Are there other actions with this characteristic?

    Comment 2
    1. Chris Johns, Wed, 26 Feb 2020 02:55:06 GMT

    Is this an issue that needs to be fixed for RTEMS 5?

    Comment 3
    1. Sebastian Huber, Wed, 26 Feb 2020 08:47:44 GMT

    Replying to Chris Johns:

    Is this an issue that needs to be fixed for RTEMS 5?

    Yes, I think that the thread switch extensions should work in SMP configurations.

    Comment 4
    1. Sebastian Huber, Wed, 26 Feb 2020 08:49:11 GMT

    Moving the thread switch extension calls into the context of the heir thread breaks for example the stack checker. It checks that the current stack pointer is in the stack area of a thread.

    Comment 5
    1. Sebastian Huber, Wed, 26 Feb 2020 08:51:14 GMT
    2. description: modified (diff)
    Comment 6
    1. Chris Johns, Thu, 27 Feb 2020 00:23:43 GMT

    Replying to Sebastian Huber:

    Moving the thread switch extension calls into the context of the heir thread breaks for example the stack checker. It checks that the current stack pointer is in the stack area of a thread.

    Is a patch to fix the stack checker being worked on?

    I know of applications that have this running during development.

    Comment 7
    1. Sebastian Huber, Thu, 27 Feb 2020 06:58:32 GMT

    Replying to Chris Johns:

    Replying to Sebastian Huber:

    Moving the thread switch extension calls into the context of the heir thread breaks for example the stack checker. It checks that the current stack pointer is in the stack area of a thread.

    Is a patch to fix the stack checker being worked on?

    I know of applications that have this running during development.

    This was easy to fix:

    ​https://lists.rtems.org/pipermail/devel/2020-February/057759.html

    I just wanted to highlight that this change can easily break existing extensions.

    Comment 8
    1. Chris Johns, Thu, 27 Feb 2020 22:46:31 GMT

    Thanks.

    Comment 9
    1. Sebastian Huber, Mon, 02 Mar 2020 06:52:07 GMT

    In fcb11510/rtems:

    score: Fix context switch extensions (SMP) In uniprocessor and SMP configurations, the context switch extensions were called during _Thread_Do_dispatch(): void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, ISR_Level level ) {
    Thread_Control *executing;
    executing = cpu_self->executing;
    ... do {
    Thread_Control *heir;
    heir = _Thread_Get_heir_and_make_it_executing( cpu_self ); ... _User_extensions_Thread_switch( executing, heir ); ... _Context_Switch( &executing->Registers, &heir->Registers ); ...
    } while ( cpu_self->dispatch_necessary ); ...
    } In uniprocessor configurations, this is fine and the context switch extensions are called for all thread switches except the very first thread switch to the initialization thread. However, in SMP configurations, the context switch may be invalidated and updated in the low-level _Context_Switch() routine. See:
    ​https://docs.rtems.org/branches/master/c-user/symmetric_multiprocessing_services.html#thread-dispatch-details
    In case such an update happens, a thread will execute on the processor which was not seen in the previous call of the context switch extensions. This can confuse for example event record consumers which use events generated by a context switch extension. Fixing this is not straight forward. The context switch extensions call must move after the low-level context switch. The problem here is that we may end up in _Thread_Handler(). Adding the context switch extensions call to _Thread_Handler() covers now also the thread switch to the initialization thread. We also have to save the last executing thread (ancestor) of the processor. Registers or the stack cannot be used for this purpose. We have to add it to the per-processor information. Existing extensions may be affected, since now context switch extensions use the stack of the heir thread. The stack checker is affected by this. Calling the thread switch extensions in the low-level context switch is difficult since at this point an intermediate stack is used which is only large enough to enable servicing of interrupts. Update #3885.
    Comment 10
    1. Sebastian Huber, Tue, 03 Mar 2020 06:30:26 GMT

    In 198c07e5/rtems:

    sptests/spextensions01: Add comment Update #3885.
    Comment 11
    1. Sebastian Huber, Tue, 03 Mar 2020 12:13:32 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 8bd4e6a/rtems-docs:

    c-user: Document thread switch extension changes Close #3885.
    Comment 12
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3887 - Do not report remotes in RSB build log if --mail is used

    Link https://devel.rtems.org/ticket/3887
    Id 3887
    Reporter Chris Johns
    Created 27 February 2020 22:45:21
    Modified 6 April 2020 03:34:02
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Do not include the remote repos in a build repo is the --mail option is used. This avoids posting private repo configuration data for a user. This ticket is in response to this discussion ...

    ​https://lists.rtems.org/pipermail/devel/2020-February/057765.html

    If --mail is used report the remote repos as:

    Remotes:
    [ removed, contact me@there.here for details ]

    and keep the remotes for builds that are not posted.

    Attachments:

    1 Gedare Bloom, Sun, 05 Apr 2020 03:34:52 GMT
      attach: set to 0001-sb-setbuilder-do-not-include-remotes-in-mailed-repor.patch
    Comment 1
    1. Gedare Bloom, Mon, 06 Apr 2020 03:34:02 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 4727c3e/rtems-source-builder:

    sb/reports: add sanitize parameter enabled for --mail Adds a --sanitize option to command line for reports.py and also for the reports.report() interface from setbuilder.py to remove the Remotes information from git. Closes #3887.

    3888 - Update rtems_waf in libbsd

    Link https://devel.rtems.org/ticket/3888
    Id 3888
    Reporter Chris Johns
    Created 28 February 2020 03:01:05
    Modified 11 August 2021 17:03:21
    Owner Chris Johns
    Type defect
    Component network/libbsd
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Update master and the 5-freebsd-12 branch.

    Comment 1
    1. Vijay Kumar Banerjee, Sat, 04 Apr 2020 12:43:07 GMT

    This ticket was referenced in the following commit: ​https://git.rtems.org/rtems-libbsd/commit/?h=5-freebsd-12&id=2b9172c9d42d056b6fb16d667091e2ee3ac64009

    But it didn't close. Shall we manually change it to "fixed"?

    Comment 2
    1. Gedare Bloom, Mon, 06 Apr 2020 05:13:42 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed
    Comment 3
    1. Gedare Bloom, Mon, 06 Apr 2020 05:17:57 GMT

    I guess it wasn't pushed to master. Chris, reopen if you still need to keep track of this.

    Comment 4
    1. Zacchaeus Leung, Wed, 11 Aug 2021 17:03:21 GMT

    In 8df5764/rtems:

    Test needed for timer_create with CLOCK_MONOTONC the timer_create() method can use CLOCK_MONOTONIC but there was no test for this. Also it implements the functionality to create a CLOCK_MONOTONIC timer and gettime() . Closes #3888

    3893 - RSB staging changes have broken building a 3rd party package

    Link https://devel.rtems.org/ticket/3893
    Id 3893
    Reporter Chris Johns
    Created 1 March 2020 09:31:14
    Modified 3 March 2020 23:22:05
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The staging changes let a fully staged vertical stack to build however building the packages for an installed tool chain and BSP is broken.

    ../source-builder/sb-set-builder --log=bbb-pkg.txt --prefix=/build/rtems/install/5 --host=arm-rtems5 --with-rtems-bsp=beagleboneblack 5/rtems-packages 
    Comment 1
    1. Chris Johns, Tue, 03 Mar 2020 02:01:26 GMT

    In 175ce0b/rtems-source-builder:

    sb/config: Expanded nested shell commands Updates #3893
    Comment 2
    1. Chris Johns, Tue, 03 Mar 2020 02:01:28 GMT

    In 4295d3d/rtems-source-builder:

    sb/config: Add paths checks to %{path ...} Updates #3893
    Comment 3
    1. Chris Johns, Tue, 03 Mar 2020 02:01:31 GMT

    In 96d55ab/rtems-source-builder:

    sb/pkgconfig: Cache pkgconfig based on a file name not name Caching on name falsely assumed checks across different config instances in nested build sets as used in vertical stack building was valid. This stopped a valid check for a prefix seeing if a valid BSP config was present. Updates #3893
    Comment 4
    1. Chris Johns, Tue, 03 Mar 2020 02:01:33 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In abd98a2/rtems-source-builder:

    rtems/bsps: Fix building 3rd party packages with various options Fix locating valid tools and BSP. If either is found in the staging area use that else use the specific --with-* option and if not present use the --prefix. Locate the tools by checking if the arch's C compiler is a valid file. No other checks are made on the tools. Locate a BSB by checking for a valid pkgconfig file for the BSP. Only filter flags if the BSP is in the staging area Closes #3893
    Comment 5
    1. Chris Johns, Tue, 03 Mar 2020 10:39:27 GMT
    2. status: changed from closed to reopened
    3. resolution: fixed deleted

    The change is broken on Python 3. This has cause the m2003 snapshot to fail.

    Comment 6
    1. Chris Johns, Tue, 03 Mar 2020 23:22:05 GMT
    2. status: changed from reopened to closed
    3. resolution: set to fixed

    In 9e49d20/rtems-source-builder:

    sb/pkgconfig: Fix python2 issue with caching changes Closes #3893

    3894 - Replace the device filesystem with a specialization of the IMFS

    Link https://devel.rtems.org/ticket/3894
    Id 3894
    Reporter Sebastian Huber
    Created 3 March 2020 10:49:08
    Modified 2 April 2020 09:25:15
    Owner Sebastian Huber
    Type enhancement
    Component fs
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3898
    Blocked by  

    Description

    New device drivers (e.g. Termios, I2C, SPI, libbsd) use IMFS generic nodes to hook into the filesystem. This does not work with the device filesystem enabled by the

    #define CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM 

    configuration option. Replace the device filesystem with a specialization of the IMFS.

    Comment 1
    1. Chris Johns, Tue, 03 Mar 2020 21:14:52 GMT

    Will the changes include the examples and the devfs hello world example?

    How doe the size of this approach compare to the devfs approach?

    Comment 2
    1. Sebastian Huber, Wed, 04 Mar 2020 05:48:53 GMT

    Replying to Chris Johns:

    Will the changes include the examples and the devfs hello world example?

    Yes, the aim is to fix this example so that it works with Termios based console drivers.

    How doe the size of this approach compare to the devfs approach?

    I don't have numbers yet. I guess it will slightly increase.

    You can further reduce the code size if you disable the support for the legacy IO drivers and use the new IMFS_add_node() instead.

    I don't think this matters. If you want a minimal setup, then why do you want to use the POSIX open/read/write API to access devices? The POSIX functions pull in errno for example which pulls in the re-entrancy support which pulls in a hell of dependencies.

    Comment 3
    1. Sebastian Huber, Wed, 04 Mar 2020 08:46:30 GMT

    In 0b0cd93/rtems:

    imfs: Remove IMFS_NODE_FLAG_NAME_ALLOCATED Remove IMFS_NODE_FLAG_NAME_ALLOCATED and instead replace the node control in rename operations. This avoids a special case in the general node destruction which pulled in free(). Update #3894.
    Comment 4
    1. Sebastian Huber, Wed, 04 Mar 2020 08:46:34 GMT

    In 13b71f8/rtems:

    imfs: Simplify IMFS_create_node() Update #3894.
    Comment 5
    1. Sebastian Huber, Wed, 04 Mar 2020 08:46:37 GMT

    In fa44c39/rtems:

    imfs: Add IMFS_add_node() Update #3894.
    Comment 6
    1. Sebastian Huber, Wed, 04 Mar 2020 08:46:40 GMT

    In 7e3b5c0/rtems:

    console: Use IMFS_add_node() for simple console Change license to BSD-2-Clause according to file history. Update #3053. Update #3894.
    Comment 7
    1. Sebastian Huber, Wed, 04 Mar 2020 08:46:44 GMT

    In fa3005f/rtems:

    console: Use IMFS_add_node() for simple task cons Change license to BSD-2-Clause according to file history. Update #3053. Update #3894.
    Comment 8
    1. Sebastian Huber, Wed, 04 Mar 2020 18:05:38 GMT
    2. blocking: set to 3898
    Comment 9
    1. Sebastian Huber, Fri, 06 Mar 2020 06:58:06 GMT

    Replying to Sebastian Huber:

    Replying to Chris Johns:

    How doe the size of this approach compare to the devfs approach?

    I don't have numbers yet. I guess it will slightly increase.

    I checked the code size change of the devfs04 test before and after the change to the IMFS specialization:

    size pre/devfs04.exe

    text data bss dec hex filename

    57328 1152 17312 75792 12810 pre/devfs04.exe

    size post/devfs04.exe

    text data bss dec hex filename

    58384 1152 16096 75632 12770 post/devfs04.exe

    The code size increases by 1056 bytes on SPARCV8.

    In case the support for legacy IO drivers is disabled via

    #define CONFIGURE_IMFS_DISABLE_MKNOD_DEVICE
    `#define CONFIGURE_IMFS_DISABLE_MKNOD 

    the code size drops to:` size devfs04.exe

    text data bss dec hex filename

    56496 1152 16096 73744 12010 devfs04.exe

    Using IMFS_add_node() gives you access to all file handlers and removes four layers of indirection, e.g.

    read() -> device_read() -> rtems_deviceio_read() -> rtems_io_read() -> _IO_Driver_address_table -> device handler

    compared to

    read() -> device handler.

    Comment 10
    1. Sebastian Huber, Mon, 09 Mar 2020 18:00:01 GMT

    In 85c9145f/rtems:

    imfs: Use _IMFS_get_time() Update #3894.
    Comment 11
    1. Sebastian Huber, Mon, 09 Mar 2020 18:00:04 GMT

    In 83994913/rtems:

    imfs: Constify imfs_memfile_bytes_per_block The CONFIGURE_IMFS_MEMFILE_BYTES_PER_BLOCK value is validated by . Changing this value during runtime could lead to memory corruption. Update #3894.
    Comment 12
    1. Sebastian Huber, Mon, 09 Mar 2020 18:00:08 GMT

    In 277b9dd/rtems:

    imfs: Remove unused handlers Update #3894.
    Comment 13
    1. Sebastian Huber, Mon, 09 Mar 2020 18:00:11 GMT

    In 103a371/rtems:

    imfs: Simplify code generation Update #3894.
    Comment 14
    1. Sebastian Huber, Mon, 09 Mar 2020 18:00:14 GMT

    In 0161b93d/rtems:

    imfs: Replace devfs with an IMFS specialization Add a simplified path evaluation function IMFS_eval_path_devfs() for a device only IMFS configuration. The code size can be further reduced by the application if it disables the support for legacy IO drivers via:
    `#define CONFIGURE_IMFS_DISABLE_MKNOD #define CONFIGURE_IMFS_DISABLE_MKNOD_DEVICE `
    Obsolete CONFIGURE_MAXIMUM_DEVICES. Remove BSP_MAXIMUM_DEVICES. Update #3894. Update #3898.
    Comment 15
    1. Sebastian Huber, Wed, 01 Apr 2020 07:05:50 GMT

    In 7cec259/rtems:

    config: Remove CONFIGURE_FILESYSTEM_DEVFS This filesystem no longer exists. Remove unused RTEMS_FILESYSTEM_TYPE_DEVFS. Update #3894.
    Comment 16
    1. Sebastian Huber, Thu, 02 Apr 2020 09:25:15 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3895 - Add a migration to RTEMS 5 chapter to User Manual

    Link https://devel.rtems.org/ticket/3895
    Id 3895
    Reporter Sebastian Huber
    Created 4 March 2020 07:19:10
    Modified 15 April 2020 14:57:14
    Owner Sebastian Huber
    Type task
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Add a chapter to the User Manual to aid the user to migrate applications from previous RTEMS versions to RTEMS 5.

    Comment 1
    1. Chris Johns, Wed, 04 Mar 2020 08:23:07 GMT

    Thanks for adding the ticket.

    I am happy to add this section. I will complete my current doco task and then do this.

    Comment 2
    1. Chris Johns, Thu, 12 Mar 2020 21:23:52 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 4726207/rtems-docs:

    user: Add a migration chapter This is a start with the hope we collect useful pieces to aid porting. Please add to this. Closes #3895
    Comment 3
    1. Sebastian Huber, Wed, 15 Apr 2020 14:57:14 GMT

    In 02bded3/rtems-docs:

    user: Update migration guide Update #3895.

    3896 - RSB option --source-only-download does not work with releases

    Link https://devel.rtems.org/ticket/3896
    Id 3896
    Reporter Chris Johns
    Created 4 March 2020 08:46:39
    Modified 4 March 2020 09:37:42
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The RSB option --source-only-download does not work for releases

    Comment 1
    1. Chris Johns, Wed, 04 Mar 2020 09:37:42 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 3b0032d/rtems-source-builder:

    sb/options: Let --source-only-download download releases The release procedure uses the sb-set-sources command now. Closes #3896

    3898 - Remove CONFIGURE_MAXIMUM_DEVICES

    Link https://devel.rtems.org/ticket/3898
    Id 3898
    Reporter Sebastian Huber
    Created 4 March 2020 18:05:38
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type task
    Component config
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by 3894

    Description

    This configuration option was only used by the device filesystem which will be replaced by a special configuration of the IMFS.

    Comment 1
    1. Sebastian Huber, Mon, 09 Mar 2020 18:00:14 GMT

    In 0161b93d/rtems:

    imfs: Replace devfs with an IMFS specialization Add a simplified path evaluation function IMFS_eval_path_devfs() for a device only IMFS configuration. The code size can be further reduced by the application if it disables the support for legacy IO drivers via:
    `#define CONFIGURE_IMFS_DISABLE_MKNOD #define CONFIGURE_IMFS_DISABLE_MKNOD_DEVICE `
    Obsolete CONFIGURE_MAXIMUM_DEVICES. Remove BSP_MAXIMUM_DEVICES. Update #3894. Update #3898.
    Comment 2
    1. Sebastian Huber, Fri, 13 Mar 2020 12:29:24 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 1ce24d3/rtems-docs:

    c-user: Obsolete CONFIGURE_MAXIMUM_DEVICES Close #3898.
    Comment 3
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3900 - New template for boolean feature defines

    Link https://devel.rtems.org/ticket/3900
    Id 3900
    Reporter Sebastian Huber
    Created 6 March 2020 15:16:53
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type task
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3836
    Blocked by  

    Description

    All boolean feature defines are undefined by default. The current template is a bit awkward. Change the application configuration option template for boolean feature defines to:

    .. index:: CONFIGURE_XYZ
    .. _CONFIGURE_XYZ:
    CONFIGURE_XYZ
    -------------
    CONSTANT:
    ``CONFIGURE_XYZ``
    OPTION TYPE:
    This configuration option is a boolean feature define.
    DEFAULT CONFIGURATION:
    If this configuration option is undefined, then not ABC or something else.
    DESCRIPTION:
    In case this configuration option is defined, then ABC.
    NOTES:
    Notes for XYZ.
    Comment 1
    1. Sebastian Huber, Fri, 06 Mar 2020 15:19:52 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Fri, 06 Mar 2020 15:28:34 GMT
    2. blocking: set to 3836
    Comment 3
    1. Sebastian Huber, Tue, 24 Mar 2020 06:50:57 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In dfe0ec0/rtems-docs:

    c-user: Use new template for feature config opts Try to bring all descriptions up to date. Add cross-references to several options. Close #3900.
    Comment 4
    1. Sebastian Huber, Mon, 30 Mar 2020 09:16:33 GMT

    In 2f18a53/rtems-docs:

    c-user: Use new template for feature config opts Update #3900.
    Comment 5
    1. Sebastian Huber, Mon, 30 Mar 2020 09:50:19 GMT

    In e26f874/rtems-docs:

    c-user: Avoid self references Update #3900.
    Comment 6
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3901 - New template for configuration options with a value

    Link https://devel.rtems.org/ticket/3901
    Id 3901
    Reporter Sebastian Huber
    Created 6 March 2020 15:27:25
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type task
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3836
    Blocked by  

    Description

    Change the documentation template for configuration options with a value to:

    .. _CONFIGURE_XYZ:
    CONFIGURE_XYZ
    -------------
    CONSTANT:
    ``CONFIGURE_XYZ``
    OPTION TYPE:
    This configuration option is an integer define.
    VALUE CONSTRAINTS:
    The specified value must be greater than or equal to X and less than or
    equal to Y.
    DEFAULT VALUE:
    The default value is Z.
    DESCRIPTION:
    This configuration option defines the ABC.
    NOTES:
    Notes for XYZ.

    Use OPTION TYPE instead of DATA TYPE since we have to characterize the option an not just the value of an option. This is in line with #3900.

    Use VALUE RANGE instead of RANGE to be more specific.

    Comment 1
    1. Sebastian Huber, Fri, 06 Mar 2020 15:28:34 GMT
    2. blocking: set to 3836
    Comment 2
    1. Sebastian Huber, Fri, 27 Mar 2020 11:54:18 GMT
    2. description: modified (diff)
    Comment 3
    1. Sebastian Huber, Wed, 01 Apr 2020 07:03:28 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 7bad894/rtems-docs:

    c-user: Use new template for integer config opts Try to bring all descriptions up to date. Add cross-references to several options. Clarify configuration value constraints. Use this template also for initializer type options. Close #3901.
    Comment 4
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3903 - raspberrypi2 libbsd 5-freebsd-12 does not build

    Link https://devel.rtems.org/ticket/3903
    Id 3903
    Reporter Chris Johns
    Created 8 March 2020 00:38:30
    Modified 4 April 2020 17:49:17
    Owner Christian Mauderer <christian.mauderer@…>
    Type defect
    Component network/libbsd
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The build is failing with ...

    /opt/work/rtems/5/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: ./libbsd.a(rtems-kernel-nexus.c.18.o): in function `nexus_ofw_map_intr':
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/rtems-libbsd-v2b9172c9d42d056b6fb16d667091e2ee3ac64009-arm-rtems5-1/rtems-libbsd-2b9172c9d42d056b6fb16d667091e2ee3ac64009/build/arm-rtems5-raspberrypi2-default/../../rtemsbsd/rtems/rtems-kernel-nexus.c:359: undefined reference to `bsp_fdt_map_intr'
    collect2: error: ld returned 1 exit status

    Is something on master that needs to be back ported to the 5-freebsd-12 branch?

    Attachments:

    1 Christian Mauderer, Tue, 10 Mar 2020 07:52:10 GMT
      attach: set to 0001-bsp-raspberry-Add-a-bsp_fdt_map_intr.patch
     
    Comment 1
    1. Chris Johns, Sun, 08 Mar 2020 00:39:59 GMT
    2. description: modified (diff)
    Comment 2
    1. Sebastian Huber, Sun, 08 Mar 2020 09:34:03 GMT

    The bsp_fdt_map_intr() must be provided by the BSP, e.g. bsps/arm/beagle/start/bspstart.c.

    Comment 3
    1. Christian Mauderer, Sun, 08 Mar 2020 21:16:06 GMT

    The same bug happens for libbsd master. Niteesh recently enabled FDT support for this BSP (following my suggestion) to be able to support the console for Pi2 and Pi3. It seems that I missed that libbsd doesn't build anymore when reviewing the patches. So the bug is not in libbsd but in RTEMS.

    Comment 4
    1. Christian Mauderer, Sun, 08 Mar 2020 21:50:56 GMT

    And of course - like everything else on this chip family - the interrupts can't be simple on RPi. There are at least two groups. Interrupts from the GPU and ones from the normal system.

    See ​https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt?id=791d3ef2e11100449837dc0b6fe884e60ca3a484 and ​https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt?id=36464580e658019ac7be26a08c4679bee0454d2c

    The interrupts in the device tree look like this:

     // GPIO - 49 to 52 in RTEMS
        interrupts = <2 17>, <2 18>, <2 19>, <2 20>;
        // USB - 9 in RTEMS
        interrupts = <1 9>;
        // Mailbox - most likely 65 in RTEMS
        interrupts = <0 1>; 

    So I __assume__ it should be a mapping like follows (in pseudo code):

    #define MAGIC_OFFSET_FOR_SECOND_LEVEL 32
        switch(first_number) {
        case 0:
            return second_number + BCM2835_IRQ_ID_BASIC_BASE_ID;
            break;
        case 1:
            return second_number;
            break;
        case 2:
            return second_number + MAGIC_OFFSET_FOR_SECOND_LEVEL;
            break;
        default:
            /* Handle invalid interrupt */
            break;
        } 
    Comment 5
    1. Sebastian Huber, Mon, 09 Mar 2020 06:27:45 GMT

    At least it looks like the API can handle this.

    Comment 6
    1. Christian Mauderer, Tue, 10 Mar 2020 07:51:33 GMT

    I created a patch that should work. But I didn't have the time to test it yet. I'll test it in the next few days.

    Comment 7
    1. Christian Mauderer, Sat, 04 Apr 2020 10:55:45 GMT

    Sorry for the long delay: The patch works and delivers the correct results (tested for the three cases GPIO0, USB and MBOX mentioned above). I'll send it to the mailing list.

    Comment 8
    1. Christian Mauderer, Sat, 04 Apr 2020 17:49:17 GMT
    2. owner: set to Christian Mauderer <christian.mauderer@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In bb8ae78/rtems:

    bsp/raspberry: Add a bsp_fdt_map_intr(). Fixes #3903

    3904 - Add methods to dump the event records in base64 encoding (optionally zlib compressed)

    Link https://devel.rtems.org/ticket/3904
    Id 3904
    Reporter Sebastian Huber
    Created 13 March 2020 08:28:26
    Modified 12 April 2020 16:05:15
    Owner Sebastian Huber
    Type enhancement
    Component unspecified
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    This helps to get the event records easily via a serial line in case of a crash.

    Comment 1
    1. Sebastian Huber, Fri, 13 Mar 2020 11:36:12 GMT
    2. summary: changed from Add methods to dump the event records in base64 encoding (optinally compressed) to Add methods to dump the event records in base64 encoding (optionally zlib compressed)
    Comment 2
    1. Sebastian Huber, Wed, 18 Mar 2020 06:50:00 GMT

    In a6b36334/rtems:

    score: Add _IO_Base64() Update #3904.
    Comment 3
    1. Sebastian Huber, Wed, 18 Mar 2020 06:50:04 GMT

    In c584d4e/rtems:

    rtems: Add rtems_put_char() Update #3904.
    Comment 4
    1. Sebastian Huber, Wed, 18 Mar 2020 06:50:07 GMT

    In ab42b3e/rtems:

    record: Add rtems_record_dump() Add rtems_record_dump_base64() and rtems_record_dump_base64_zlib(). Add CONFIGURE_RECORD_FATAL_DUMP_BASE64 and CONFIGURE_RECORD_FATAL_DUMP_BASE64_ZLIB configuration options. Update #3904.
    Comment 5
    1. Sebastian Huber, Thu, 19 Mar 2020 06:38:45 GMT

    In 14f0957/rtems-tools:

    record: Fix format Update #3904.
    Comment 6
    1. Sebastian Huber, Thu, 19 Mar 2020 06:38:47 GMT

    In 4aa0d5f/rtems-tools:

    record: Guard config.h include Update #3904.
    Comment 7
    1. Sebastian Huber, Thu, 19 Mar 2020 06:38:50 GMT

    In 8db5ce1/rtems-tools:

    record: Format file header Update #3904.
    Comment 8
    1. Sebastian Huber, Thu, 19 Mar 2020 06:38:52 GMT

    In b60abbf/rtems-tools:

    record: Add INI file parser Import from: ​https://github.com/benhoyt/inih commit 351217124ddb3e3fe2b982248a04c672350bb0af Author: Stephan Lachnit Date: Sun Mar 1 07:31:28 2020 +0100
    r48 release (#100)
    Bump copyright to 2020 Remove makefile for static library meson: version 48
    Signed-off-by: Stephan Lachnit
    Update #3904.
    Comment 9
    1. Sebastian Huber, Thu, 19 Mar 2020 06:38:55 GMT

    In b066705/rtems-tools:

    record: Add option to print config default values Update #3904.
    Comment 10
    1. Sebastian Huber, Thu, 19 Mar 2020 06:38:57 GMT

    In bfc8f2d/rtems-tools:

    record: Add filter base class Update #3904.
    Comment 11
    1. Sebastian Huber, Thu, 19 Mar 2020 06:38:59 GMT

    In 5bc9f73/rtems-tools:

    record: Add base64 filter class Update #3904.
    Comment 12
    1. Sebastian Huber, Thu, 19 Mar 2020 06:39:02 GMT

    In d964171/rtems-tools:

    record: Add support for base64 encoded input Update #3904.
    Comment 13
    1. Sebastian Huber, Thu, 19 Mar 2020 06:39:04 GMT

    In 5fa2c3b/rtems-tools:

    record: Add zlib filter class Update #3904.
    Comment 14
    1. Sebastian Huber, Thu, 19 Mar 2020 06:39:06 GMT

    In 390522a/rtems-tools:

    record: Add support for zlib compressed input Update #3904.
    Comment 15
    1. Sebastian Huber, Thu, 19 Mar 2020 06:39:08 GMT

    In 16eff9b/rtems-tools:

    record: Increase input buffer and alignment Update #3904.
    Comment 16
    1. Sebastian Huber, Mon, 23 Mar 2020 06:06:22 GMT

    In 68f90be/rtems-source-builder:

    5: Update rtems-tools Pick up new features for rtems-record-lttng. Update #3904.
    Comment 17
    1. Sebastian Huber, Mon, 23 Mar 2020 06:41:33 GMT

    In 3fd4889/rtems:

    conf: Improve evaluation of event recording opts Check for configuration errors earlier. Allow fatal dumps without the other extensions. Add some warnings. Update #3904.
    Comment 18
    1. Sebastian Huber, Tue, 24 Mar 2020 06:50:59 GMT

    In 62d58f2/rtems-docs:

    c-user: Document new event record config options Update #3904.
    Comment 19
    1. Sebastian Huber, Sun, 12 Apr 2020 16:05:15 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In ea4c098/rtems-docs:

    user: Document event recording Close #3904.

    3907 - Update Getting Started Instructions

    Link https://devel.rtems.org/ticket/3907
    Id 3907
    Reporter Joel Sherrill
    Created 15 March 2020 18:59:51
    Modified 4 April 2020 19:36:21
    Owner  
    Type task
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords small, tasks
    Cc  
    Blocking  
    Blocked by  

    Description

    ​https://devel.rtems.org/wiki/GSoC/GettingStarted reflects how SIS was used before it was split from GDB into a separate program.

    Ensure this information is in the Users Guide as a Getting Started. We need a Getting Started task for student programs.

    Discuss keeping the old instructions under a subheading for older versions.

    This ticket can be closed when it is determined that the wiki page content is distributed and updated/removed properly

    Comment 1
    1. Joel Sherrill, Sun, 15 Mar 2020 19:01:52 GMT
    2. type: changed from enhancement to task
    Comment 2
    1. niteesh, Sat, 04 Apr 2020 18:27:44 GMT

    I have sent a patch for this. And the website has also been updated. Can you please close this ticket?

    Comment 3
    1. Gedare Bloom, Sat, 04 Apr 2020 19:36:21 GMT
    2. status: changed from new to closed
    3. version: set to 5
    4. resolution: set to fixed
    5. milestone: set to 5.1

    3909 - rtems_waf with python2 needs to handle unicode strings with waf

    Link https://devel.rtems.org/ticket/3909
    Id 3909
    Reporter Chris Johns
    Created 17 March 2020 10:18:53
    Modified 30 March 2020 00:22:11
    Owner Chris Johns
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Waf will not support Python 2 unicode strings and there is a use case that appears now and again where the user report an error something like:

    Cannot create ///h/ 

    The waf ticket is ​https://gitlab.com/ita1024/waf/-/issues/2283.

    Comment 1
    1. Chris Johns, Mon, 30 Mar 2020 00:22:11 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    ​https://git.rtems.org/rtems-libbsd/commit/?id=508836451b282e016d0310e8913e95fd2cd6b0f3


    3911 - Remove gdbarmsim

    Link https://devel.rtems.org/ticket/3911
    Id 3911
    Reporter Joel Sherrill
    Created 19 March 2020 20:18:10
    Modified 20 March 2020 18:38:42
    Owner  
    Type enhancement
    Component bsps
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Broken as a consequence of ARM rework that did not get done to this BSP. On top of that, there are at least 3 BSPs supported by Qemu which have more peripheral support with the Zynq being at the top of that list.

    Comment 1
    1. Joel Sherrill, Fri, 20 Mar 2020 14:36:41 GMT

    In [changeset:"37e7cc5f4ce7ed46b5ea2de56d9066d121d851cb/rtems" 37e7cc5/rtems]:

    (The changeset message doesn't reference this ticket)

    Comment 2
    1. Joel Sherrill, Fri, 20 Mar 2020 14:37:13 GMT

    In [changeset:"87e49d4cf93924b5c855fbf9429cff2cdb212f8f/rtems-docs" 87e49d4/rtems-docs]:

    (The changeset message doesn't reference this ticket)

    Comment 3
    1. Joel Sherrill, Fri, 20 Mar 2020 14:37:50 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Closing commit messages accidentally refer to #3611.

    Comment 4
    1. Joel Sherrill, Fri, 20 Mar 2020 18:38:42 GMT

    In 9b9e0dd/rtems-tools:

    gdbarmsim: Remove all variants Updates #3911.

    3914 - Spike has hard-coded path to DTC

    Link https://devel.rtems.org/ticket/3914
    Id 3914
    Reporter Joel Sherrill
    Created 21 March 2020 18:32:08
    Modified 25 March 2020 15:22:23
    Owner Joel Sherrill
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Spike has a fully qualified hard-coded path to dtc which when built with the RSB ends up being inside the temporary tree.

    RTEMS Discussion: ​https://lists.rtems.org/pipermail/devel/2020-March/058489.html

    Filed as Spike bug: ​https://github.com/riscv/riscv-isa-sim/issues/427

    Comment 1
    1. Joel Sherrill, Mon, 23 Mar 2020 20:11:06 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 12e02ad/rtems-source-builder:

    Spike: Update to include fix for hard-coded path to dtc Closes #3914.
    Comment 2
    1. Joel Sherrill, Wed, 25 Mar 2020 15:22:23 GMT

    In 71af2d9/rtems-source-builder:

    spike: Update to use exec that searches along PATH. Updates #3914.

    3919 - RSB may not download source of pkconfig checked packages

    Link https://devel.rtems.org/ticket/3919
    Id 3919
    Reporter Chris Johns
    Created 27 March 2020 03:33:40
    Modified 27 March 2020 03:40:50
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    There are config files with the following:

    #
    # The GLib build instructions. We use 2.x.x Release 1.
    #
    %ifn %{pkgconfig check glib-2.0}
    %include %{_configdir}/glib-2-1.cfg
    %endif

    If the glib package is present the config file is not loaded and the source is not downloaded with the sb-get-source package. Change the config to:

    #
    # The GLib build instructions. We use 2.x.x Release 1.
    #
    %if !%{pkgconfig check glib-2.0} || %{defined _rsb_getting_source}
    %include %{_configdir}/glib-2-1.cfg
    %endif
    Comment 1
    1. Chris Johns, Fri, 27 Mar 2020 03:40:50 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 9b7cdb7/rtems-source-builder:

    bare: Fix pkgconfig checks and getting source. If the package was installed the check does not build the package. This also meant getting the source failed. Closes #3919

    3921 - QorIQ clock tick interval is off by one hardware clock tick

    Link https://devel.rtems.org/ticket/3921
    Id 3921
    Reporter Sebastian Huber
    Created 2 April 2020 07:12:54
    Modified 2 April 2020 07:14:04
    Owner Sebastian Huber
    Type defect
    Component bsps
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The BCR initialization in qoriq_clock_initialize() is off by one resulting in a wrong clock interval.

    Comment 1
    1. Sebastian Huber, Thu, 02 Apr 2020 07:14:04 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 299a82f4/rtems:

    bsp/qoriq: Fix off by one error in clock init Close #3921.

    3927 - tclsh required to build sqlite -- makes all BSP bsets fail

    Link https://devel.rtems.org/ticket/3927
    Id 3927
    Reporter Joel Sherrill
    Created 2 April 2020 17:00:19
    Modified 3 April 2020 00:22:16
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    I'm not sure what to do about this. If building sqlite is a requirement, then host setup instructions, sb-check, etc are impacted. But dtc is a required component for a few things and the RSB deals with it. It is also possible to say that sqlite should not be in the BSP bsets.

    This is IMO a blocker at some level for the 5.1 release because it impacts building all bsets.

    + make -j 8 sqlite3.h libsqlite3.la
    tclsh /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mksqlite3h.tcl /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801 >sqlite3.h
    gcc  -g -o mkkeywordhash -DSQLITE_OMIT_WAL=1 -DSQLITE_ENABLE_COLUMN_METADATA=1  /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mkkeywordhash.c
    gcc  -g -o lemon /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/lemon.c
    /bin/sh: tclsh: command not found

    Comment 1
    1. Joel Sherrill, Thu, 02 Apr 2020 19:09:55 GMT

    Advice from Jonathan Brandmeyer (​https://lists.rtems.org/pipermail/devel/2020-April/058905.html).

    We just copied the amalgamation's single .c and .h file into our repository and built it as a single object into our application. So the following recommendations come only from an amateur reading of the sources on current rtems-source-builder master.

    3.8.8 is pretty old. I'd just jump straight to 3.30.1, the current release.

    Instead of downloading the sqlite-src zip, download sqlite-amalgamation or sqlite-autoconf and use that as a base. I think the bset's configuration invocation is OK, except that I would set different CFLAGS as described in the next couple of paragraphs. See also ​https://sqlite.org/amalgamation.html

    By default, the SQLite write-ahead-log relies on mmap to share some of its index structures between multiple processes. It looks like the current RTEMS bset disables the WAL entirely. Using the WAL gives much better performance than the rollback journal for write-intensive use cases. We used SQLite to reliably buffer up and stitch together segments of our field software update process, which fits the WAL very well. We set -DSQLITE_MAX_MMAP_SIZE=0 -DSQLITE_DEFAULT_LOCKING_MODE=1 at compile time to avoid mmap's use since RTEMS has neither a VMM nor multiple address spaces. It is still up to the application to choose either the WAL or the rollback journal. See also ​https://sqlite.org/wal.html#noshm

    We also added -DSQLITE_ENABLE_MEMSYS5 to our build, and used it to give SQLite its own memory spaces to operate on distinct from the rest of our application. We explicitly provided it with its own MEMSYS5 heap, page cache, and lookaside pools. RTEMS just needs to add the correct compile-time option to support this functionality. It is still up to the application to configure and monitor those memory pools at runtime. See also ​https://sqlite.org/malloc.html

    Comment 2
    1. Jonathan Brandmeyer, Fri, 03 Apr 2020 00:22:16 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 113c65c/rtems-source-builder:

    databases/sqlite: Update to 3.31.1 closes #3927.

    3936 - C++ thread-local storage broken on sparc64

    Link https://devel.rtems.org/ticket/3936
    Id 3936
    Reporter Sebastian Huber
    Created 6 April 2020 12:12:48
    Modified 6 April 2020 17:18:05
    Owner Gedare Bloom
    Type defect
    Component arch/sparc64
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    gmake[5]: Entering directory '/build/git-build/b-niagara/sparc64-rtems5/c/niagara/testsuites/sptests'
    sparc64-rtems5-g++ -mcpu=niagara -g -O2 -ffunction-sections -fdata-sections -Wall -B./../../lib/libbsp/sparc64/niagara -B/home/EB/sebastian_h/git-rtems-5/bsps/sparc64/niagara/start -specs bsp_specs -qrtems -L./../../cpukit -L/home/EB/sebastian_h/git-rtems-5/bsps/sparc64/shared/start -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -Wl,--gc-sections -o sptls02.exe sptls02/sptls02-init.o sptls02/sptls02-var.o ./../../lib/libbsp/sparc64/niagara/librtemsbsp.a ./../../cpukit/librtemscpu.a ./../../cpukit/librtemstest.a
    /build/rtems/5/lib/gcc/sparc64-rtems5/7.5.0/../../../../sparc64-rtems5/bin/ld: warning: dot moved backwards before `.got'
    /build/rtems/5/lib/gcc/sparc64-rtems5/7.5.0/../../../../sparc64-rtems5/bin/ld: warning: dot moved backwards before `.got'
    /build/rtems/5/lib/gcc/sparc64-rtems5/7.5.0/../../../../sparc64-rtems5/bin/ld: section .got LMA [00000000000317c0,00000000000317c7] overlaps section .data LMA [0000000000031018,00000000000319d7]

    One option is to disable this test on sparc64.

    Comment 1
    1. Gedare Bloom, Mon, 06 Apr 2020 16:15:43 GMT

    I'm going to take a brief look today. I haven't been using the sparc64 since 2012 so there is not much motive for me other than keeping it maintained. If it is too much trouble I will let it decay down the tiers toward deprecation.

    Comment 2
    1. Joel Sherrill, Mon, 06 Apr 2020 16:27:03 GMT

    I was disappointed in general when I looked for ABI definitions for TLS for various architectures. I think there is an Ulrich Drepper document describing a few (​https://akkadia.org/drepper/tls.pdf) but I think it is undefined for a lot of architectures.

    Does GCC have a default mechanism? I couldn't find any hint of architecture specific TLS in the few secondary architectures I looked at. If there is a default way of calling a method for TLS info, it would be great. But at this point, I don't think TLS works from a GCC perspective on maybe half the architectures we support.

    sparc64 isn't a secondary gcc architecture so I am sure it works in GCC. Whether we want it around long term is another question entirely.

    Comment 3
    1. Gedare Bloom, Mon, 06 Apr 2020 17:18:05 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 2db1fd85/rtems:

    sparc64: update linkcmds with missing sections for TLS Closes #3936.

    3938 - Many (~40) BSPs Fail to Link all Tests

    Link https://devel.rtems.org/ticket/3938
    Id 3938
    Reporter Joel Sherrill
    Created 6 April 2020 19:00:15
    Modified 8 April 2020 13:51:02
    Owner joel@…
    Type defect
    Component test
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    When configured as as show, ~40 BSPs (list below) cannot link all of the tests due to out of memory issues:

    ../rtems/configure --target=arm-rtems5 --prefix=/home/joel/rtems-work/bsp-install/ --disable-multiprocessing --enable-cxx --disable-rdbg --enable-maintainer-mode --enable-tests --disable-networking --disable-posix --disable-itron --disable-deprecated --disable-ada --disable-expada --enable-rtemsbsp=atsamv 

    arm-atsamv
    arm-lm3s3749
    arm-lm3s6965
    arm-lm4f120
    arm-lpc1768_mbed_ahb_ram_eth
    arm-lpc1768_mbed_ahb_ram
    arm-lpc1768_mbed
    arm-lpc2362
    arm-lpc23xx_tli800
    arm-lpc32xx_mzx_stage_1
    arm-rtl22xx
    arm-rtl22xx_t
    arm-stm32f105rc
    arm-stm32f4
    arm-tms570ls3137_hdk_intram
    arm-tms570ls3137_hdk
    arm-tms570ls3137_hdk_with_loader
    m68k-mcf52235
    m68k-mcf5225x
    m68k-mrm332
    powerpc-gwlcfm
    powerpc-mpc5566evb
    powerpc-mpc5566evb_spe
    powerpc-mpc5643l_dpu
    powerpc-mpc5643l_evb
    powerpc-mpc5668g
    powerpc-mpc5674f_ecu508_app
    powerpc-mpc5674f_ecu508_boot
    powerpc-mpc5674fevb
    powerpc-mpc5674fevb_spe
    powerpc-mpc5674f_rsm6
    sh-gensh1
    sh-gensh2
    sh-simsh1
    sh-simsh2e
    sh-simsh2
    sh-simsh4
    sparc64-niagara
    sparc64-usiii

    Comment 1
    1. Sebastian Huber, Mon, 06 Apr 2020 19:01:25 GMT

    I already fixed this in the new build system.

    Comment 2
    1. Sebastian Huber, Mon, 06 Apr 2020 19:05:55 GMT

    The sparc64 is #3936.

    Comment 3
    1. Joel Sherrill, Mon, 06 Apr 2020 19:08:12 GMT

    Is this an attempt to avoid fixing it on the master before we cut a release branch? This is a failure for ~25% of the BSPs in the tree.

    Comment 4
    1. Sebastian Huber, Mon, 06 Apr 2020 19:08:40 GMT

    In c547470e/rtems:

    tests: Small memory exclude for record02 Update #3938.
    Comment 5
    1. Sebastian Huber, Mon, 06 Apr 2020 19:10:10 GMT

    Replying to Joel Sherrill:

    Is this an attempt to avoid fixing it on the master before we cut a release branch? This is a failure for ~25% of the BSPs in the tree.

    No, it is a statement that I work on this!

    Comment 6
    1. Sebastian Huber, Mon, 06 Apr 2020 19:22:58 GMT

    In 92a3a19c/rtems:

    tests: Exclude record02 for some BSPs Update #3938.
    Comment 7
    1. Sebastian Huber, Mon, 06 Apr 2020 19:30:50 GMT

    I should be fixed.

    Comment 8
    1. Joel Sherrill, Mon, 06 Apr 2020 19:44:06 GMT

    Thanks. Building with your commit. arm/atsamv fails linking record02.

    I will post more as the build progresses or finishes.

    Comment 9
    1. Sebastian Huber, Mon, 06 Apr 2020 20:10:32 GMT

    The arm/atsamv should be fixed:

    ​https://git.rtems.org/rtems/diff/bsps/arm/atsam/config/atsamv-testsuite.tcfg?id=92a3a19c757ca0c62eaec2bb55621a562758627b

    Comment 10
    1. Joel Sherrill, Tue, 07 Apr 2020 22:15:03 GMT

    In f74d70e6/rtems:

    lm4f120-testsuite.tcfg: Add psxsignal07 Updates #3938.
    Comment 11
    1. Joel Sherrill, Tue, 07 Apr 2020 22:15:06 GMT

    In fe5d50ed/rtems:

    lpc1768_mbed_ahb_ram_eth-testsuite.tcfg: Add psxsignal07 Updates #3938.
    Comment 12
    1. Joel Sherrill, Tue, 07 Apr 2020 22:15:09 GMT

    In dcb097a/rtems:

    lpc2362-testsuite.tcfg: Add psxaoi03 and psxsignal07 Updates #3938.
    Comment 13
    1. Joel Sherrill, Tue, 07 Apr 2020 22:15:13 GMT

    In a7ea726f/rtems:

    lpc1768_mbed-testsuite.tcfg: Add psxaoi03 and psxsignal07 Updates #3938.
    Comment 14
    1. Joel Sherrill, Tue, 07 Apr 2020 22:15:16 GMT

    In af7e519/rtems:

    mcf52235-testsuite.tcfg: Add sp16 Updates #3938.
    Comment 15
    1. Joel Sherrill, Tue, 07 Apr 2020 22:15:19 GMT

    In f493534/rtems:

    lpc23xx_tli800-testsuite.tcfg: Add psxaoi03 and psxsignal07 Updates #3938.
    Comment 16
    1. Sebastian Huber, Wed, 08 Apr 2020 05:19:24 GMT

    Sorry for not catching the POSIX tests. I assigned a bit more RAM to my build ramdisk and now it builds with POSIX enabled.

    Comment 17
    1. Joel Sherrill, Wed, 08 Apr 2020 13:30:22 GMT

    I made a series of commits and an overnight build shows this is resolved. The epiphany is the only BSP which doesn't build and that's a GCC ICE.

    Thanks.

    Closing.

    Comment 18
    1. Joel Sherrill, Wed, 08 Apr 2020 13:51:02 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    3944 - qoriq_e500 BSP bset fails

    Link https://devel.rtems.org/ticket/3944
    Id 3944
    Reporter Joel Sherrill
    Created 8 April 2020 14:25:11
    Modified 28 April 2020 08:41:36
    Owner Sebastian Huber
    Type defect
    Component bsps
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Looks like curl isn't building for the qoriq_e500 bset. This seems like a weird outlier. Any ideas?

    checking for gethostbyname for Minix 3... no
    checking for gethostbyname for eCos... no
    checking for gethostbyname for AmigaOS bsdsocket.library... no
    checking for gethostbyname in -lnetwork... no
    checking for gethostbyname in -lnet... no
    configure: error: couldn't find libraries for gethostbyname()
    shell cmd failed: /bin/sh -ex /home/joel/rtems-work/rtems-source-builder/rtems/build/curl-v7.65.1-powerpc-rtems5-1/do-build
    error: building curl-v7.65.1-powerpc-rtems5-1
    Comment 1
    1. Sebastian Huber, Thu, 09 Apr 2020 08:00:17 GMT

    I tried to reproduce this issue and ended up with this local problem:

    configure:3441: powerpc-rtems5-gcc --version >&5
    powerpc-rtems5-gcc (GCC) 10.0.1 20200407 (experimental) [master revision fd83c39a6be:52ecef68e56:eed9b787db9ab73968ad4e799de5ce3c2eeb2c6c]
    Copyright (C) 2020 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    configure:3452: $? = 0
    configure:3441: powerpc-rtems5-gcc -v >&5
    Using built-in specs.
    COLLECT_GCC=powerpc-rtems5-gcc
    COLLECT_LTO_WRAPPER=/opt/rtems/5/lib/gcc/powerpc-rtems5/10.0.1/lto-wrapper
    Target: powerpc-rtems5
    Configured with: /home/EB/sebastian_h/archive/gcc-git/configure --prefix=/opt/rtems/5 --target=powerpc-rtems5  --verbose --with-gnu-as --with-gnu-ld --with-newlib --disable-libstdcxx-pch --disable-nls --disable-lto --disable-plugin --without-included-gettext --disable-wi
    n32-registry --enable-version-specific-runtime-libs --enable-threads --enable-newlib-iconv --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3
    ,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win
    _1255,win_1256,win_1257,win_1258 --enable-newlib-io-c99-formats --enable-libgomp --enable-languages=c,c++
    Thread model: rtems
    Supported LTO compression algorithms: zlib
    gcc version 10.0.1 20200407 (experimental) [master revision fd83c39a6be:52ecef68e56:eed9b787db9ab73968ad4e799de5ce3c2eeb2c6c] (GCC)
    configure:3452: $? = 0
    configure:3441: powerpc-rtems5-gcc -V >&5
    powerpc-rtems5-gcc: error: unrecognized command-line option '-V'
    powerpc-rtems5-gcc: fatal error: no input files
    compilation terminated.
    configure:3452: $? = 1
    configure:3441: powerpc-rtems5-gcc -qversion >&5
    powerpc-rtems5-gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'?
    powerpc-rtems5-gcc: fatal error: no input files
    compilation terminated.
    configure:3452: $? = 1
    configure:3472: checking whether the C compiler works
    configure:3494: powerpc-rtems5-gcc -mcpu=8540 -meabi -msdata=sysv -fno-common -mstrict-align -mspe -mabi=spe -mfloat-gprs=double -O2 -g -ffunction-sections -fdata-sections   conftest.c  >&5
    powerpc-rtems5-gcc: error: unrecognized command-line option '-mspe'
    powerpc-rtems5-gcc: error: unrecognized command-line option '-mabi=spe'
    powerpc-rtems5-gcc: error: unrecognized command-line option '-mfloat-gprs=double' 

    The build picks up the installed compiler and not the new one of the build set. I think this is a known issue. The compiler is not in my $PATH. It was picked up by the default prefix. I will try it again with an empty prefix.

    Comment 2
    1. Sebastian Huber, Thu, 09 Apr 2020 10:18:04 GMT

    The configure check doesn't use the linker garbage collection and this leads to undefined symbols:

    configure:6802: powerpc-rtems5-gcc -o conftest -qrtems -B/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/powerpc-rtems5/lib/ -B/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/powerpc-rtems5/qoriq_e500/lib/ --specs bsp_specs -mcpu=8540 -meabi -msdata=sysv -fno-common -mstrict-align -mspe -mabi=spe -mfloat-gprs=double -O2 -g -ffunction-sections -fdata-sections  -I/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/powerpc-rtems5/qoriq_e500/lib/include -L/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/powerpc-rtems5/qoriq_e500/lib -mcpu=8540 -meabi -msdata=sysv -mstrict-align -mspe -mabi=spe -mfloat-gprs=double  -L/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000/ftp/curl/build/rtems/bset-test/lib conftest.c -lbsd -lm -lz -lrtemsdefaultconfig >&5
    /scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/bin/../lib/gcc/powerpc-rtems5/7.5.0/../../../../powerpc-rtems5/bin/ld: /scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/powerpc-rtems5/qoriq_e500/lib/libbsd.a(ofw_subr.c.18.o): in function `_bsd_ofw_parse_bootargs':
    /scratch/git-rtems-source-builder/rtems/build/rtems-libbsd-v816a2f912f414f39467a6be901a96159f806c01d-x86_64-linux-gnu-1/rtems-libbsd-816a2f912f414f39467a6be901a96159f806c01d/build/powerpc-rtems5-qoriq_e500-default/../../freebsd/sys/dev/ofw/ofw_subr.c:207: undefined reference to `boot_parse_cmdline'
    /scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/bin/../lib/gcc/powerpc-rtems5/7.5.0/../../../../powerpc-rtems5/bin/ld: /scratch/git-rtems-source-builder/rtems/build/rtems-libbsd-v816a2f912f414f39467a6be901a96159f806c01d-x86_64-linux-gnu-1/rtems-libbsd-816a2f912f414f39467a6be901a96159f806c01d/build/powerpc-rtems5-qoriq_e500-default/../../freebsd/sys/dev/ofw/ofw_subr.c:207: undefined reference to `boothowto'
    /scratch/git-rtems-source-builder/rtems/build/rtems-libbsd-v816a2f912f414f39467a6be901a96159f806c01d-x86_64-linux-gnu-1/rtems-libbsd-816a2f912f414f39467a6be901a96159f806c01d/build/powerpc-rtems5-qoriq_e500-default/../../freebsd/sys/dev/ofw/ofw_subr.c:207:(.text._bsd_ofw_parse_bootargs+0x4a): unresolvable R_PPC_SDAREL16 relocation against symbol `boothowto'
    /scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/bin/../lib/gcc/powerpc-rtems5/7.5.0/../../../../powerpc-rtems5/bin/ld: /scratch/git-rtems-source-builder/rtems/build/rtems-libbsd-v816a2f912f414f39467a6be901a96159f806c01d-x86_64-linux-gnu-1/rtems-libbsd-816a2f912f414f39467a6be901a96159f806c01d/build/powerpc-rtems5-qoriq_e500-default/../../freebsd/sys/dev/ofw/ofw_subr.c:207: undefined reference to `boothowto'
    /scratch/git-rtems-source-builder/rtems/build/rtems-libbsd-v816a2f912f414f39467a6be901a96159f806c01d-x86_64-linux-gnu-1/rtems-libbsd-816a2f912f414f39467a6be901a96159f806c01d/build/powerpc-rtems5-qoriq_e500-default/../../freebsd/sys/dev/ofw/ofw_subr.c:207:(.text._bsd_ofw_parse_bootargs+0x5a): unresolvable R_PPC_SDAREL16 relocation against symbol `boothowto' 
    Comment 3
    1. Sebastian Huber, Thu, 09 Apr 2020 12:01:34 GMT

    I think the root cause for this and similar issues is that we have no reliable way to get the essential tool flags of an installed BSP. The new build system is supposed to fix this.

    Comment 4
    1. Sebastian Huber, Sun, 12 Apr 2020 16:13:52 GMT

    Why don't we add -Wl,--gc-sections to the standard linker flags?

    Comment 5
    1. Chris Johns, Tue, 28 Apr 2020 05:13:43 GMT

    Replying to Sebastian Huber:

    The build picks up the installed compiler and not the new one of the build set. I think this is a known issue. The compiler is not in my $PATH. It was picked up by the default prefix. I will try it again with an empty prefix.

    I am not sure how the PATH is being set. The prepend path is set here ... ​https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/setbuilder.py#n422 ... and this is the staging area. The build module does not play with the path and the defaults handles the prepend and postpend and extras ... ​https://git.rtems.org/rtems-source-builder/tree/source-builder/defaults.mc#n267 I am confused. Maybe using --trace and inspecting the variables would highlight the issue.

    Is there something in gcc causing the prefix to used?

    Comment 6
    1. Chris Johns, Tue, 28 Apr 2020 05:15:38 GMT

    Replying to Sebastian Huber:

    Why don't we add -Wl,--gc-sections to the standard linker flags?

    Is this issue closed? I have been building the kernel and libbsd with the RSB as separate steps for the e500 and e6500_32 are did not see any failures.

    Comment 7
    1. Sebastian Huber, Tue, 28 Apr 2020 05:29:54 GMT

    The error was in curl. I sent a patch to fix this issue: ​https://lists.rtems.org/pipermail/devel/2020-April/059305.html

    Comment 8
    1. Chris Johns, Tue, 28 Apr 2020 06:29:26 GMT

    Can we close the ticket?

    Comment 9
    1. Sebastian Huber, Tue, 28 Apr 2020 06:50:26 GMT

    The patch is not checked in, you wanted to adjust it a bit: ​https://lists.rtems.org/pipermail/devel/2020-April/059311.html

    Comment 10
    1. Sebastian Huber, Tue, 28 Apr 2020 06:51:40 GMT

    I can send also a v2 if you like, I just found it would be easier if you adjust it yourself.

    Comment 11
    1. Chris Johns, Tue, 28 Apr 2020 07:35:53 GMT

    Oh, I am sorry. I will have a look.

    Comment 12
    1. Chris Johns, Tue, 28 Apr 2020 07:50:25 GMT

    Does rtems_waf need the change as well? Is libbsd fixed?

    Comment 13
    1. Sebastian Huber, Tue, 28 Apr 2020 07:55:04 GMT

    Th rtems_waf and thus libbsd have another workaround to enable the linker garbage collection.

    Comment 14
    1. Chris Johns, Tue, 28 Apr 2020 08:41:36 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 13e4dfd/rtems-source-builder:

    rtems-bsb: Use linker garbage collection for BSP based builds Close #3944.

    3945 - Update DTC example on rtems-docs/user/rsb/configuration.rst

    Link https://devel.rtems.org/ticket/3945
    Id 3945
    Reporter Cláudio Maia
    Created 8 April 2020 16:46:21
    Modified 28 April 2020 06:27:25
    Owner Chris Johns
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority low
    Severity normal
    Keywords rtems-docs
    Cc  
    Blocking  
    Blocked by  

    Description

    The DTC example on rtems-docs/user/rsb/configuration.rst should be reviewed and updated in order to be consistent with what is available in the RSB tree.

    For instance, the link (​http://www.jdl.com/software) provided in the webpage is not available anymore and some environment variables described in the text need also to be verified ("DESTDIR" and a "DISTDIR"). Thus, it is needed to review this part of the documentation.

    Comment 1
    1. Joel Sherrill, Wed, 08 Apr 2020 17:17:32 GMT
    2. owner: set to Chris Johns
    3. status: changed from new to assigned
    4. milestone: changed from 6.1 to 5.1

    I don't like moving this back to 5.1 but it is wrong and according to git blame was written in 2016. I assigned it back to the author (per git blame). Hopefully a quick review and edit will get this into shape.

    Comment 2
    1. Chris Johns, Tue, 28 Apr 2020 06:27:25 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In ccc473b/rtems-docs:

    user/rsb: Update the configuration documentation Closes #3945

    3949 - clock_settime() can lead to a failed _Assert()

    Link https://devel.rtems.org/ticket/3949
    Id 3949
    Reporter Sebastian Huber
    Created 13 April 2020 17:07:07
    Modified 14 April 2020 05:21:53
    Owner Sebastian Huber
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    A time too far in the future can lead to a failed assertion in _Watchdog_Ticks_from_timespec(). This should be an error status instead.

    Comment 1
    1. Sebastian Huber, Tue, 14 Apr 2020 05:21:50 GMT

    In fb07f730/rtems:

    score: Return status in _TOD_Set() Update #3949.
    Comment 2
    1. Sebastian Huber, Tue, 14 Apr 2020 05:21:53 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In ea227af/rtems:

    score: Check time of day in _TOD_Set() Close #3949.

    3953 - rtems_extensions_create() accepts a NULL pointer table

    Link https://devel.rtems.org/ticket/3953
    Id 3953
    Reporter Sebastian Huber
    Created 16 April 2020 15:08:28
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type defect
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    It should return RTEMS_INVALID_ADDRESS instead.

    Comment 1
    1. Sebastian Huber, Fri, 17 Apr 2020 17:51:28 GMT

    In 3d73642/rtems:

    sapi: Add param check to rtems_extension_create() Check that the extensions table is not NULL. Change format. Update #3953.
    Comment 2
    1. Sebastian Huber, Fri, 17 Apr 2020 17:51:43 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In a19be8b/rtems-docs:

    c-user: Document rtems_extension_create() Close #3953.
    Comment 3
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3956 - RSB BSP build with tests does not keep a copy

    Link https://devel.rtems.org/ticket/3956
    Id 3956
    Reporter Chris Johns
    Created 16 April 2020 23:23:57
    Modified 28 April 2020 05:21:27
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The tests are not installed by default. Add support to the RSB to copy the tests to the installed BSP prefix.

    Comment 1
    1. Chris Johns, Tue, 28 Apr 2020 01:07:49 GMT

    In d14da0a/rtems-source-builder:

    rtems-kernel: Install tests when tests are built The tests in RTEMS are not installed so if a user requests the tests be built install them. Given the RSB cleans up building the tests and not installing does nothing. Fix the options handling the kernel build to be consistent Updates #3956
    Comment 2
    1. Chris Johns, Tue, 28 Apr 2020 01:32:30 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In b42e051/rtems-docs:

    user: Update the RSB BSP quick start to say where the tests are installed Closes #3956
    Comment 3
    1. Chris Johns, Tue, 28 Apr 2020 05:21:27 GMT

    In 47880bb/rtems-source-builder:

    rtems-kernel: Fix building without the rtems test option. Updates #3956

    3960 - Add to FreeBSD host setup information

    Link https://devel.rtems.org/ticket/3960
    Id 3960
    Reporter Joel Sherrill
    Created 17 April 2020 20:32:41
    Modified 28 April 2020 03:57:05
    Owner Chris Johns <chrisj@…>
    Type defect
    Component doc
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Installing GCC on FreeBSD 12 leads to build issues. This along with the issue that the GCC build should be done with the GNU sed
    in the $PATH during the RSB process needs to be added to the documentation here:

    ​https://docs.rtems.org/branches/master/user/hosts/posix.html#freebsd

    Comment 1
    1. Chris Johns, Mon, 27 Apr 2020 00:14:50 GMT
    2. owner: set to Chris Johns <chrisj@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 7fab12c/rtems-docs:

    freebsd: Update to reflect the current release 12 requirements Closes #3960
    Comment 2
    1. Joel Sherrill, Mon, 27 Apr 2020 12:51:10 GMT

    I read the change and didn't see sed mentioned. Did you want to make a note about that?

    Comment 3
    1. Sebastian Huber, Mon, 27 Apr 2020 14:18:21 GMT

    The RTEMS 5 build sets contain some workarounds for the GNU sed problem. So, for the RTEMS 5 release it is not necessary to mention the GNU sed.

    The RTEMS 6 build sets don't have them, so they don't build all on FreeBSD 12 using the BSD sed.

    Comment 4
    1. Chris Johns, Tue, 28 Apr 2020 03:57:05 GMT

    Replying to Joel Sherrill:

    I read the change and didn't see sed mentioned. Did you want to make a note about that?

    I added the package to the needed list to install ...

    ​https://git.rtems.org/rtems-docs/tree/user/hosts/posix.rst#n196


    3961 - bsps/arm: CPU counter based on arm generic timer doesn't work correctly

    Link https://devel.rtems.org/ticket/3961
    Id 3961
    Reporter Christian Mauderer
    Created 20 April 2020 06:30:19
    Modified 20 April 2020 07:08:59
    Owner Christian Mauderer
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3456
    Blocked by  

    Description

    On at least the imx BSP the CPU counter based on the arm generic timer isn't initialized correctly. The frequency is set to 0.

    Comment 1
    1. Christian Mauderer, Mon, 20 Apr 2020 07:08:59 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 222d6879/rtems:

    bsps/arm: Fix uninitialized value in generic timer _CPU_Counter_frequency() can be called by the rtems_counter initialization before arm_gt_clock_initialize() initializes the value used in _CPU_Counter_frequency(). Closes #3961.

    3966 - RSB bare version number if wrong.

    Link https://devel.rtems.org/ticket/3966
    Id 3966
    Reporter Chris Johns
    Created 3 May 2020 23:35:52
    Modified 8 May 2020 04:34:30
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The bare/bare-config.cfg has the wrong major version number for RTEMS.

    Comment 1
    1. Chris Johns, Fri, 08 May 2020 04:34:30 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 955c1c1/rtems-source-builder:

    bare/qemu: Fixes building on FreeBSD Move the qemu config to a common file shared by qemu and qemu4. Disable nettle on qemu4, FreeBSd complained. Add some extra git cleaning steps to the git path. These however do not full clean the qemu submodules and it is not worth the effort to try and fix. The devel/qemu will not build on machines with python set to python3. This will not be fixed, use qemu4. Closes #3966

    3967 - Release source package list is out of date

    Link https://devel.rtems.org/ticket/3967
    Id 3967
    Reporter Chris Johns
    Created 3 May 2020 23:37:43
    Modified 8 May 2020 08:05:35
    Owner Chris Johns
    Type defect
    Component release
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The source package list needs to be reviewed and updated:

    ​https://git.rtems.org/rtems-release/tree/rtems-source-packages

    Comment 1
    1. Chris Johns, Sun, 03 May 2020 23:38:44 GMT
    2. component: changed from admin to release
    Comment 2
    1. Chris Johns, Fri, 08 May 2020 08:05:35 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3968 - symlinks in RTEMS source tree

    Link https://devel.rtems.org/ticket/3968
    Id 3968
    Reporter Chris Johns
    Created 5 May 2020 00:52:18
    Modified 9 May 2020 12:10:55
    Owner Chris Johns
    Type defect
    Component test
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    There is a symlink is in the RTEMS git repo and source tree. We cannot have symlinks in released tar files because it breaks on Windows and MSYS:

    $ find . -type l
    ./testsuites/libtests/tar01/symlink

    MSYS reports:

    $ find . -type l
    ./testsuites/libtests/tar01/symlink

    The software engineering manual needs an entry stating symlinks cannot appear in the source repo or git in any RTEMS repos. The solution is to create a symlink on suitable hosts, i.e. not Windows when building.

    This ticket will address the removal and not state of the effected test. That will be the subject of another ticket if someone creates it.

    Comment 1
    1. Sebastian Huber, Thu, 07 May 2020 10:32:14 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In ef9517b7/rtems:

    libtests/tar0[12]: Add tar archive Do not generate the test tar archive on the host computer since not all file systems support symbolic links. Close #3968.
    Comment 2
    1. Sebastian Huber, Sat, 09 May 2020 12:10:55 GMT

    In ea2d923/rtems:

    libtests/tar01: Remove files of tar01.tar archive Update #3968.

    3969 - dl06 fails on all libdl supported architectures

    Link https://devel.rtems.org/ticket/3969
    Id 3969
    Reporter Chris Johns
    Created 5 May 2020 01:29:25
    Modified 5 May 2020 05:03:58
    Owner Chris Johns
    Type defect
    Component lib/dl
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The test dl06 fails on all libdl supported architectures.

    Comment 1
    1. Chris Johns, Tue, 05 May 2020 01:32:22 GMT

    In 6de89d9/rtems-tools:

    linkers/ld: Output all reloc records to the RAP file Updates #3969
    Comment 2
    1. Chris Johns, Tue, 05 May 2020 05:03:36 GMT

    In 285cda3/rtems:

    libdl: Fix comment. Updates #3969
    Comment 3
    1. Chris Johns, Tue, 05 May 2020 05:03:40 GMT

    In fe77587/rtems:

    libdl/sparc: Print trace message of reloc failture path Updates #3969
    Comment 4
    1. Chris Johns, Tue, 05 May 2020 05:03:44 GMT

    In b77670fd/rtems:

    libdl/obj: Fix RAP format call table. Updates #3969
    Comment 5
    1. Chris Johns, Tue, 05 May 2020 05:03:47 GMT

    In d5fc2a6a/rtems:

    libdl/obj-cache: Fail if the read offset is past the file length The check was for greater than and not equal or greater Updates #3969
    Comment 6
    1. Chris Johns, Tue, 05 May 2020 05:03:51 GMT

    In 3635d6a/rtems:

    libdl/obj-comp: Add trace prints when decompressing Updates #3969
    Comment 7
    1. Chris Johns, Tue, 05 May 2020 05:03:54 GMT

    In b7702c54/rtems:

    libdl/rap: Correctly check the return enum from rela calls The change from bool to an enum did not trip a compiler warning and only the rel path was changed. The rela path was missed so archs like SPARC failed. Updates #3969
    Comment 8
    1. Chris Johns, Tue, 05 May 2020 05:03:58 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 3f50e8e/rtems:

    testsuite/dl06: Add a local define to control tracing Closes #3969

    3970 - Deprecate use _RTEMS_version at API level

    Link https://devel.rtems.org/ticket/3970
    Id 3970
    Reporter Sebastian Huber
    Created 5 May 2020 12:34:08
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3972, 3978
    Blocked by  

    Description

    The global variable _RTEMS_version was declared via and may be used directly by application code. Applications should use rtems_get_version_string() instead. Mark this variable as deprecated and move it to an internal header file in RTEMS 6.

    Comment 1
    1. Sebastian Huber, Tue, 05 May 2020 12:55:41 GMT
    2. blocking: set to 3972
    Comment 2
    1. Sebastian Huber, Wed, 06 May 2020 06:02:33 GMT

    In 4b9b6dd/rtems:

    Use rtems_get_version_string() Update #3970.
    Comment 3
    1. Sebastian Huber, Wed, 06 May 2020 06:02:37 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 34b098e/rtems:

    rtems: Deprecate use of _RTEMS_version Close #3970.
    Comment 4
    1. Sebastian Huber, Mon, 11 May 2020 05:48:32 GMT
    2. blocking: changed from 3972 to 3972, 3978
    Comment 5
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3971 - Deprecate use of RTEMS_MAXIMUM_NAME_LENGTH

    Link https://devel.rtems.org/ticket/3971
    Id 3971
    Reporter Sebastian Huber
    Created 5 May 2020 12:46:30
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3972, 3979
    Blocked by  

    Description

    This define is unused and undocumented. It is available via . Deprecate its use.

    Comment 1
    1. Sebastian Huber, Tue, 05 May 2020 12:55:41 GMT
    2. blocking: set to 3972
    Comment 2
    1. Sebastian Huber, Wed, 06 May 2020 06:02:40 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 3d86d83/rtems:

    rtems: Deprecate RTEMS_MAXIMUM_NAME_LENGTH This define is not documented, not used in the RTEMS code base, and longer than sizeof(rtems_name). Close #3971.
    Comment 3
    1. Sebastian Huber, Mon, 11 May 2020 05:49:22 GMT
    2. blocking: changed from 3972 to 3972, 3979
    Comment 4
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3972 - Deprecate <rtems/system.h>

    Link https://devel.rtems.org/ticket/3972
    Id 3972
    Reporter Sebastian Huber
    Created 5 May 2020 12:55:41
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3980
    Blocked by 3970, 3971, 3978, 3979

    Description

    This header file is included by and contains only deprecated or internal content. Deprecate its use at API level.

    Comment 1
    1. Sebastian Huber, Wed, 06 May 2020 06:02:43 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 63274da/rtems:

    rtems: Deprecate Close #3972.
    Comment 2
    1. Sebastian Huber, Mon, 11 May 2020 05:48:32 GMT
    2. blockedby: changed from 3970, 3971 to 3970, 3971, 3978
    Comment 3
    1. Sebastian Huber, Mon, 11 May 2020 05:49:22 GMT
    2. blockedby: changed from 3970, 3971, 3978 to 3970, 3971, 3978, 3979
    Comment 4
    1. Sebastian Huber, Mon, 11 May 2020 05:50:27 GMT
    2. blocking: set to 3980
    Comment 5
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3973 - Add rtems_get_copyright_notice() and deprecate _Copyright_Notice

    Link https://devel.rtems.org/ticket/3973
    Id 3973
    Reporter Sebastian Huber
    Created 5 May 2020 12:58:51
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking 3981
    Blocked by  

    Description

    Deprecate the use of _Copyright_Notice at API level and instead provide a new function rtems_get_copyright_notice().

    Comment 1
    1. Sebastian Huber, Wed, 06 May 2020 06:02:47 GMT

    In 1af8e45b/rtems:

    rtems: Add rtems_get_copyright_notice() Update #3973.
    Comment 2
    1. Sebastian Huber, Wed, 06 May 2020 06:02:50 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In d30a352/rtems:

    rtems: Deprecate _Copyright_Notice Close #3973.
    Comment 3
    1. Sebastian Huber, Mon, 11 May 2020 06:25:06 GMT
    2. blocking: set to 3981
    Comment 4
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    3974 - Deprecate ephipany port in rtems5 and remove in rtems6

    Link https://devel.rtems.org/ticket/3974
    Id 3974
    Reporter Joel Sherrill
    Created 7 May 2020 01:28:02
    Modified 7 May 2020 04:37:16
    Owner  
    Type defect
    Component arch/epiphany
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking 3941
    Blocked by  

    Description

    This port has not built in a while and gcc does not appear to be getting fixed. It has been at Tier 4 for a while because of this.

    If this port is of interest, work to get gcc fixed and help resurrect this port.

    Deprecate for RTEMS 5.x
    Remove in RTEMS 6.x

    Comment 1
    1. Sebastian Huber, Thu, 07 May 2020 04:36:41 GMT
    2. blocking: set to 3941
    Comment 2
    1. Sebastian Huber, Thu, 07 May 2020 04:37:16 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    It is already in the release notes.


    3976 - Released RSB qemu4 source download fails.

    Link https://devel.rtems.org/ticket/3976
    Id 3976
    Reporter Chris Johns
    Created 9 May 2020 00:43:47
    Modified 10 June 2020 05:00:09
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The RSB attempts to download:

    ​https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2005-2/sources/qemu-git-42d58e7.tar.xz

    and the release process has captured:

    qemu-4.1.0-leon3.patch
    qemu-couverture-03a7fbcce52e0bca7f033ccba79e7856e82bb437.tar.gz
    qemu-git-v4.1.0.tar.xz
    Comment 1
    1. Chris Johns, Wed, 10 Jun 2020 00:32:21 GMT

    I have fixed the RSB scripts so the release source is referenced and I am now getting this message from QEMU:

    + PKG_CONFIG_DEFAULT_PATH='' PKG_CONFIG_PATH=/build/rtems/releases/build/5.0.0-m2006-1/rtems-source-builder-5.0.0-m2006-1/bare/build/tmp/sb-500/devel/qemu4/build/rtems/releases/install/5.0.0-m2006-1/lib/pkgconfig PKG_CONFIG_BUILD_TOP_DIR=/build/rtems/releases/build/5.0.0-m2006-1/rtems-source-builder-5.0.0-m2006-1/bare/build/tmp/sb-500/devel/qemu4 LD_LIBRARY_PATH=/build/rtems/releases/build/5.0.0-m2006-1/rtems-source-builder-5.0.0-m2006-1/bare/build/tmp/sb-500/devel/qemu4/build/rtems/releases/install/5.0.0-m2006-1/lib LDFLAGS='-Wl,-rpath -Wl,/build/rtems/releases/install/5.0.0-m2006-1/lib -L/build/rtems/releases/build/5.0.0-m2006-1/rtems-source-builder-5.0.0-m2006-1/bare/build/tmp/sb-500/devel/qemu4/build/rtems/releases/install/5.0.0-m2006-1/lib ' CFLAGS=' ' ../qemu-git-v4.1.0/configure '--prefix=/build/rtems/releases/install/5.0.0-m2006-1' '--make=gmake' --disable-werror --disable-tools --disable-pie --disable-vnc --disable-sdl --disable-gtk --disable-opengl --disable-netmap --disable-nettle
    ERROR: missing file /build/rtems/releases/build/5.0.0-m2006-1/rtems-source-builder-5.0.0-m2006-1/bare/build/qemu-v4.1.0-x86_64-freebsd12.1-1/qemu-git-v4.1.0/ui/keycodemapdb/README
    This is not a GIT checkout but module content appears to
    be missing. Do not use 'git archive' or GitHub download links
    to acquire QEMU source archives. Non-GIT builds are only
    supported with source archives linked from:
      https://www.qemu.org/download/#source
    Developers working with GIT can use scripts/archive-source.sh
    if they need to create valid source archives. 

    This means any build of qemu taken from git will fail as a release. The qemu4 build is qemu-4.1.0 so it may be simpler to move to using the release source than git. I do not think modeling the QEMU source release process in our release process is a good idea.

    __NOTE:__ Making the change will require some testing on Linux by Zynq and RISCV core developers before I branch.

    Comment 2
    1. Chris Johns, Wed, 10 Jun 2020 05:00:09 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 42b7e8a/rtems-source-builder:

    devel/qemu4: Use release source tarball Git cannot be used for a release as our release process does not package the source in a manner qemu expects. Closes #3976

    3987 - ARMv7-M Exception handler does not store the SP

    Link https://devel.rtems.org/ticket/3987
    Id 3987
    Reporter Sebastian Huber
    Created 27 May 2020 07:24:32
    Modified 27 May 2020 08:25:27
    Owner Sebastian Huber
    Type defect
    Component arch/arm
    Status closed
    Resolution fixed
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The default exception handler on ARMv7-M does not store the SP of the exception context to the exception frame.

    Comment 1
    1. Sebastian Huber, Wed, 27 May 2020 08:25:27 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In bd750c9e/rtems:

    arm: Fix ARMv7-M exception handler Store the stack pointer of the exception context to the exception frame. Close #3987.

    3992 - Release URL path with sources is wrong

    Link https://devel.rtems.org/ticket/3992
    Id 3992
    Reporter Chris Johns
    Created 28 May 2020 23:14:50
    Modified 4 June 2020 02:28:53
    Owner Chris Johns
    Type defect
    Component release
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The path is wrong in the release scripts.

    Comment 1
    1. Chris Johns, Thu, 04 Jun 2020 02:28:53 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    3995 - Release doxygen support is broken

    Link https://devel.rtems.org/ticket/3995
    Id 3995
    Reporter Chris Johns
    Created 3 June 2020 04:29:24
    Modified 4 June 2020 02:29:11
    Owner Chris Johns
    Type defect
    Component release
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The doxygen support has been updated in the repository and the release scripts have not been updated.

    Comment 1
    1. Chris Johns, Thu, 04 Jun 2020 02:29:11 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    4002 - Beaglebone and PC BSP stacks do not build

    Link https://devel.rtems.org/ticket/4002
    Id 4002
    Reporter Chris Johns
    Created 10 June 2020 23:41:56
    Modified 15 June 2020 07:33:45
    Owner  
    Type defect
    Component bsps
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority highest
    Severity blocker
    Keywords  
    Cc  
    Blocking 3985
    Blocked by  

    Description

    The Beaglebone and PC BSPs do not build with the RSB master (42b7e8a4faa4a4601a69da78e02092ebdb81b7d9). These are the only two BSPs I have tried.

    The build fails on the first package (sqlite). The sqlite standard autoconf configure compiler test fails with a number of missing symbols.

    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/arm-rtems5-gcc \
    -qrtems -B/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/arm-rtems5/lib/ \
    -B/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/arm-rtems5/beagleboneblack/lib/ \
    --specs bsp_specs -mcpu=cortex-a8 -O2 -g -ffunction-sections -fdata-sections \
    -DSQLITE_MAX_MMAP_SIZE=0 -DSQLITE_DEFAULT_LOCKING_MODE=1 -DSQLITE_ENABLE_MEMSYS5 \
    -I/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/arm-rtems5/beagleboneblack/lib/include \
    -L/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/arm-rtems5/beagleboneblack/lib \
    -mcpu=cortex-a8 -Wl,--gc-sections \
    -L/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500/databases/sqlite/opt/work/rtems/5/lib \
    conftest.c
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/arm-rtems5/beagleboneblack/lib/start.o: in function `bsp_start_hook_0_done':
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-153b26699ee10eb760816ca0d030fe4cd80e1ce7/build/arm-rtems5/c/beagleboneblack/lib/libbsp/arm/beagle/../../../../../../../../rtems-153b26699ee10eb760816ca0d030fe4cd80e1ce7/c/src/lib/libbsp/arm/beagle/../../../../../../bsps/arm/shared/start/start.S:202: undefined reference to `_ISR_Stack_size'
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-153b26699ee10eb760816ca0d030fe4cd80e1ce7/build/arm-rtems5/c/beagleboneblack/lib/libbsp/arm/beagle/../../../../../../../../rtems-153b26699ee10eb760816ca0d030fe4cd80e1ce7/c/src/lib/libbsp/arm/beagle/../../../../../../bsps/arm/shared/start/start.S:207: undefined reference to `_ISR_Stack_area_begin'
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/arm-rtems5/beagleboneblack/lib/librtemsbsp.a(bbb-i2c.o): in function `am335x_i2c_transfer':
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-153b26699ee10eb760816ca0d030fe4cd80e1ce7/build/arm-rtems5/c/beagleboneblack/lib/libbsp/arm/beagle/../../../../../../../../rtems-153b26699ee10eb760816ca0d030fe4cd80e1ce7/c/src/lib/libbsp/arm/beagle/../../../../../../bsps/arm/beagle/i2c/bbb-i2c.c:358: undefined reference to `_Watchdog_Microseconds_per_tick'
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-153b26699ee10eb760816ca0d030fe4cd80e1ce7/build/arm-rtems5/c/beagleboneblack/lib/libbsp/arm/beagle/../../../../../../../../rtems-153b26699ee10eb760816ca0d030fe4cd80e1ce7/c/src/lib/libbsp/arm/beagle/../../../../../../bsps/arm/beagle/i2c/bbb-i2c.c:399: undefined reference to `_Watchdog_Microseconds_per_tick'
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-153b26699ee10eb760816ca0d030fe4cd80e1ce7/build/arm-rtems5/c/beagleboneblack/lib/libbsp/arm/beagle/../../../../../../../../rtems-153b26699ee10eb760816ca0d030fe4cd80e1ce7/c/src/lib/libbsp/arm/beagle/../../../../../../bsps/arm/beagle/i2c/bbb-i2c.c:428: undefined reference to `_Watchdog_Microseconds_per_tick'
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-153b26699ee10eb760816ca0d030fe4cd80e1ce7/build/arm-rtems5/c/beagleboneblack/lib/libbsp/arm/beagle/../../../../../../../../rtems-153b26699ee10eb760816ca0d030fe4cd80e1ce7/c/src/lib/libbsp/arm/beagle/../../../../../../bsps/arm/beagle/i2c/bbb-i2c.c:428: undefined reference to `_Watchdog_Microseconds_per_tick'
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/arm-rtems5/beagleboneblack/lib/librtemscpu.a(i2c-bus.o): in function `i2c_bus_ioctl':
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-153b26699ee10eb760816ca0d030fe4cd80e1ce7/build/arm-rtems5/c/beagleboneblack/cpukit/../../../../../rtems-153b26699ee10eb760816ca0d030fe4cd80e1ce7/c/src/../../cpukit/dev/i2c/i2c-bus.c:167: undefined reference to `_Watchdog_Microseconds_per_tick'
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/arm-rtems5/beagleboneblack/lib/librtemscpu.a(i2c-bus.o):/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-153b26699ee10eb760816ca0d030fe4cd80e1ce7/build/arm-rtems5/c/beagleboneblack/cpukit/../../../../../rtems-153b26699ee10eb760816ca0d030fe4cd80e1ce7/c/src/../../cpukit/dev/i2c/i2c-bus.c:167: more undefined references to `_Watchdog_Microseconds_per_tick' follow
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/arm-rtems5/beagleboneblack/lib/librtemscpu.a(threadsetstate.o): in function `_Scheduler_Block':
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-153b26699ee10eb760816ca0d030fe4cd80e1ce7/rtems-153b26699ee10eb760816ca0d030fe4cd80e1ce7/cpukit/include/rtems/score/schedulerimpl.h:287: undefined reference to `_Scheduler_Table'
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-153b26699ee10eb760816ca0d030fe4cd80e1ce7/rtems-153b26699ee10eb760816ca0d030fe4cd80e1ce7/cpukit/include/rtems/score/schedulerimpl.h:287: undefined reference to `_Scheduler_Table'
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-153b26699ee10eb760816ca0d030fe4cd80e1ce7/rtems-153b26699ee10eb760816ca0d030fe4cd80e1ce7/cpukit/include/rtems/score/schedulerimpl.h:287: undefined reference to `_Scheduler_Table'
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-153b26699ee10eb760816ca0d030fe4cd80e1ce7/rtems-153b26699ee10eb760816ca0d030fe4cd80e1ce7/cpukit/include/rtems/score/schedulerimpl.h:287: undefined reference to `_Scheduler_Table'
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/arm-rtems5/beagleboneblack/lib/librtemscpu.a(threadyield.o): in function `_Scheduler_Yield':
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-153b26699ee10eb760816ca0d030fe4cd80e1ce7/rtems-153b26699ee10eb760816ca0d030fe4cd80e1ce7/cpukit/include/rtems/score/schedulerimpl.h:225: undefined reference to `_Scheduler_Table'
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/arm-rtems5/beagleboneblack/lib/librtemscpu.a(threadyield.o):/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-153b26699ee10eb760816ca0d030fe4cd80e1ce7/rtems-153b26699ee10eb760816ca0d030fe4cd80e1ce7/cpukit/include/rtems/score/schedulerimpl.h:225: more undefined references to `_Scheduler_Table' follow
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld: /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-500-staging/arm-rtems5/beagleboneblack/lib/librtemscpu.a(userextiterate.o): in function `_User_extensions_Iterate':
    /opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-153b26699ee10eb760816ca0d030fe4cd80e1ce7/build/arm-rtems5/c/beagleboneblack/cpukit/../../../../../rtems-153b26699ee10eb760816ca0d030fe4cd80e1ce7/c/src/../../cpukit/score/src/userextiterate.c:167: undefined reference to `_User_extensions_Initial_count'
    [snip]

    Removing the -Wl,--gc-sections argument from the command line works.

    It seems there is conflict between the flags -Wl,--gc-sections for LibBSD to link and how autoconf link tests are constructed.

    I would like this ticket to only be closed when the Beaglebone and PC BSP stacks build with the RSB git master and a release snapshot on Linux and FreeBSD.

    Comment 1
    1. Chris Johns, Thu, 11 Jun 2020 22:22:46 GMT
    2. blocking: set to 3985
    Comment 2
    1. Sebastian Huber, Mon, 15 Jun 2020 05:15:20 GMT

    I cannot reproduce this problem with the following command:

    ../source-builder/sb-set-builder --prefix=/build/rtems/5.1 --no-clean 5/bsps/pc
    ...
    reporting: net/protobuf-2.6.1-1.cfg -> protobuf-2.6.1-i386-rtems5-1.txt
    reporting: net/protobuf-2.6.1-1.cfg -> protobuf-2.6.1-i386-rtems5-1.xml
    staging: protobuf-2.6.1-i386-rtems5-1 -> /scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging
    Build Set: Time 0:00:41.351672
    Build Set: Time 0:03:56.786477
    installing: 5/bsps/pc -> /build/rtems/5.1
    Staging Size: 1.387GB
    Build Set: Time 0:25:46.568974 

    Which command line option did you use? Was something installed in the prefix? Was the build directory clean?

    Comment 3
    1. Sebastian Huber, Mon, 15 Jun 2020 06:28:23 GMT

    This works also:

    ../source-builder/sb-set-builder --prefix=/build/rtems/5.1 --no-clean 5/bsps/beagleboneblack
    ...
    reporting: net/protobuf-2.6.1-1.cfg -> protobuf-2.6.1-arm-rtems5-1.txt
    reporting: net/protobuf-2.6.1-1.cfg -> protobuf-2.6.1-arm-rtems5-1.xml
    staging: protobuf-2.6.1-arm-rtems5-1 -> /scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging
    Build Set: Time 0:00:42.319813
    Build Set: Time 0:04:07.640366
    installing: 5/bsps/beagleboneblack -> /build/rtems/5.1
    Staging Size: 3.267GB
    Build Set: Time 0:42:13.692753 

    I have a different Autoconf command line:

    configure:3322: checking whether the C compiler works
    configure:3344: arm-rtems5-gcc -qrtems -B/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/lib/ -B/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/beagleboneblack/lib/ --specs bsp_specs -mcpu=cortex-a8 -O2 -g -ffunction-sections -fdata-sections  -DSQLITE_MAX_MMAP_SIZE=0 -DSQLITE_DEFAULT_LOCKING_MODE=1 -DSQLITE_ENABLE_MEMSYS5 -I/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/beagleboneblack/lib/include -L/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/beagleboneblack/lib  -mcpu=cortex-a8   -Wl,--gc-sections -L/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000/databases/sqlite/build/rtems/5.1/lib conftest.c -lbsd -lm -lz -lrtemsdefaultconfig 

    Please note that there is an -lrtemsdefaultconfig which I don't see in the original report.

    Comment 4
    1. Chris Johns, Mon, 15 Jun 2020 06:31:49 GMT

    Replying to Sebastian Huber:

    I cannot reproduce this problem with the following command:

    ../source-builder/sb-set-builder --prefix=/build/rtems/5.1 --no-clean 5/bsps/pc
    ...
    reporting: net/protobuf-2.6.1-1.cfg -> protobuf-2.6.1-i386-rtems5-1.txt
    reporting: net/protobuf-2.6.1-1.cfg -> protobuf-2.6.1-i386-rtems5-1.xml
    staging: protobuf-2.6.1-i386-rtems5-1 -> /scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging
    Build Set: Time 0:00:41.351672
    Build Set: Time 0:03:56.786477
    installing: 5/bsps/pc -> /build/rtems/5.1
    Staging Size: 1.387GB
    Build Set: Time 0:25:46.568974 

    Which command line option did you use?

    RTEMS Source Builder - Set Builder, 5 (42b7e8a4faa4 modified)

    Command Line: ../source-builder/sb-set-builder --prefix=/opt/work/rtems/5-test --log=i386.txt --trace 5/bsps/pc

    (the modification is unrelated)

    Was something installed in the prefix?

    Yes and no and both failed.

    Was the build directory clean?

    Yes.

    Comment 5
    1. Chris Johns, Mon, 15 Jun 2020 06:33:09 GMT

    Replying to Sebastian Huber:

    I have a different Autoconf command line:

    configure:3322: checking whether the C compiler works
    configure:3344: arm-rtems5-gcc -qrtems -B/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/lib/ -B/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/beagleboneblack/lib/ --specs bsp_specs -mcpu=cortex-a8 -O2 -g -ffunction-sections -fdata-sections  -DSQLITE_MAX_MMAP_SIZE=0 -DSQLITE_DEFAULT_LOCKING_MODE=1 -DSQLITE_ENABLE_MEMSYS5 -I/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/beagleboneblack/lib/include -L/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/beagleboneblack/lib  -mcpu=cortex-a8   -Wl,--gc-sections -L/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000/databases/sqlite/build/rtems/5.1/lib conftest.c -lbsd -lm -lz -lrtemsdefaultconfig 

    Please note that there is an -lrtemsdefaultconfig which I don't see in the original report.

    Where does that library get inserted into the libraries list for an autoconf test link?

    Comment 6
    1. Sebastian Huber, Mon, 15 Jun 2020 06:37:40 GMT

    Replying to Chris Johns:

    Replying to Sebastian Huber:

    I have a different Autoconf command line:

    configure:3322: checking whether the C compiler works
    configure:3344: arm-rtems5-gcc -qrtems -B/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/lib/ -B/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/beagleboneblack/lib/ --specs bsp_specs -mcpu=cortex-a8 -O2 -g -ffunction-sections -fdata-sections  -DSQLITE_MAX_MMAP_SIZE=0 -DSQLITE_DEFAULT_LOCKING_MODE=1 -DSQLITE_ENABLE_MEMSYS5 -I/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/beagleboneblack/lib/include -L/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/beagleboneblack/lib  -mcpu=cortex-a8   -Wl,--gc-sections -L/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000/databases/sqlite/build/rtems/5.1/lib conftest.c -lbsd -lm -lz -lrtemsdefaultconfig 

    Please note that there is an -lrtemsdefaultconfig which I don't see in the original report.

    Where does that library get inserted into the libraries list for an autoconf test link?

    I have an unmodified RSB (cbae90a5817a6b66f8d576b7e95c7df46c5f0833).

    Comment 7
    1. Sebastian Huber, Mon, 15 Jun 2020 06:43:07 GMT

    We have:

    #
    # Check for installed libraries.
    #
    # - Check is LibBSD is install
    # - Add librtemsdefaultconfig so configure scripts work.
    #
    # Note: default BSP flags include the standard RTEMS libraries.
    #
    %define rtems-dep-check %(%{_sbdir}/sb/rtems-build-dep -c %{with_tools}/bin/%{rtems_bsp_cc}
    %define rtems-libbsd %{rtems-dep-check} -L %{rtems_bsp_libpath} -l libbsd.a)
    %if %{rtems-libbsd} == found
     %define rtems_bsp_libs %{rtems_bsp_libs} -lbsd -lm -lz
    %endif
    %define rtems-defaultconfig %{rtems-dep-check} -L %{rtems_bsp_libpath} -l librtemsdefaultconfig.a)
    %if %{rtems-defaultconfig} == found
     %define rtems_bsp_libs %{rtems_bsp_libs} -lrtemsdefaultconfig
    %endif 

    Maybe there is an issue with the macro evaluation on your system. I don't see the -lbsd -lm -lz in your report also.

    Comment 8
    1. Chris Johns, Mon, 15 Jun 2020 06:43:29 GMT

    Replying to Sebastian Huber:

    Replying to Chris Johns:

    Replying to Sebastian Huber:

    I have a different Autoconf command line:

    configure:3322: checking whether the C compiler works
    configure:3344: arm-rtems5-gcc -qrtems -B/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/lib/ -B/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/beagleboneblack/lib/ --specs bsp_specs -mcpu=cortex-a8 -O2 -g -ffunction-sections -fdata-sections  -DSQLITE_MAX_MMAP_SIZE=0 -DSQLITE_DEFAULT_LOCKING_MODE=1 -DSQLITE_ENABLE_MEMSYS5 -I/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/beagleboneblack/lib/include -L/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000-staging/arm-rtems5/beagleboneblack/lib  -mcpu=cortex-a8   -Wl,--gc-sections -L/scratch/git-rtems-source-builder/rtems/build/tmp/sb-10000/databases/sqlite/build/rtems/5.1/lib conftest.c -lbsd -lm -lz -lrtemsdefaultconfig 

    Please note that there is an -lrtemsdefaultconfig which I don't see in the original report.

    Where does that library get inserted into the libraries list for an autoconf test link?

    This library is a requirement for rtems-libbsd. The check is in rtems/rtems-bsp.cfg. I wonder is this test is broken ...

    %define rtems-defaultconfig %{rtems-dep-check} -L %{rtems_bsp_libpath} -l librtemsdefaultconfig.a)
    %if %{rtems-defaultconfig} == found
     %define rtems_bsp_libs %{rtems_bsp_libs} -lrtemsdefaultconfig
    %endif 

    I have an unmodified RSB (cbae90a5817a6b66f8d576b7e95c7df46c5f0833).

    The only difference is the RTEMS 6 tools update.

    Comment 9
    1. Chris Johns, Mon, 15 Jun 2020 06:59:44 GMT

    Replying to Chris Johns:

    (the modification is unrelated)

    I think it is related. The effect of looking for the reason the libcurl does not build for Joel effected the output of the dep check script and that effected this test.

    Checking and adding the -lrtemsdefaultconfig is OK for building rtems-libbsd dependent packages because any executables created when building those packages cannot and will never run if loaded onto a target.

    I am building with the same git hash as you, that is master.

    Comment 10
    1. Chris Johns, Mon, 15 Jun 2020 07:33:45 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    I am not seeing any error now. This is a error generated by me when looking into #3985.


    4005 - Remove RTEMS_MP_NOT_CONFIGURED error condition

    Link https://devel.rtems.org/ticket/4005
    Id 4005
    Reporter Sebastian Huber
    Created 16 June 2020 05:07:49
    Modified 23 June 2021 07:07:55
    Owner Sebastian Huber
    Type enhancement
    Component rtems
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords qualification
    Cc  
    Blocking  
    Blocked by  

    Description

    Some objects can be created with a local or global scope in a multiprocessing network. In non-multiprocessing configurations setting the scope to local or global had no effect since such a system can be viewed as a multiprocessing system with just one node. One and all nodes is the same in such a system. However, if multiprocessing was configured, creation of a global object in a single node system resulted in an RTEMS_MP_NOT_CONFIGURED error. Remove this error condition for symmetry with the non-multiprocessing setup. This is in line with the task affinity behaviour in SMP systems.

    Comment 1
    1. Sebastian Huber, Thu, 18 Jun 2020 05:10:06 GMT

    In 46c23871/rtems:

    rtems: Remove RTEMS_MP_NOT_CONFIGURED error Some objects can be created with a local or global scope in a multiprocessing network. In non-multiprocessing configurations setting the scope to local or global had no effect since such a system can be viewed as a multiprocessing network with just one node. One and all nodes is the same in such a network. However, if multiprocessing was configured, creation of a global object in a single node network resulted in an RTEMS_MP_NOT_CONFIGURED error. Remove this error condition for symmetry to the non-multiprocessing setup. This is in line with the task affinity behaviour in SMP systems. Update #4005.
    Comment 2
    1. Sebastian Huber, Thu, 18 Jun 2020 05:13:36 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 1b2468c/rtems-docs:

    c-user: Remove RTEMS_MP_NOT_CONFIGURED error Some objects can be created with a local or global scope in a multiprocessing network. In non-multiprocessing configurations setting the scope to local or global had no effect since such a system can be viewed as a multiprocessing network with just one node. One and all nodes is the same in such a network. However, if multiprocessing was configured, creation of a global object in a single node network resulted in an RTEMS_MP_NOT_CONFIGURED error. Remove this error condition for symmetry to the non-multiprocessing setup. This is in line with the task affinity behaviour in SMP systems. Close #4005.
    Comment 3
    1. Sebastian Huber, Wed, 23 Jun 2021 07:07:55 GMT
    2. keywords: qualification added

    4006 - rtems-test target_exe_filter fails when there is no filter

    Link https://devel.rtems.org/ticket/4006
    Id 4006
    Reporter Chris Johns
    Created 16 June 2020 22:42:22
    Modified 16 June 2020 22:43:34
    Owner Chris Johns <chrisj@…>
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    If a BSP does not have a target_exe_filter the executable file name to load is set to None and the load fails.

    Comment 1
    1. Chris Johns, Tue, 16 Jun 2020 22:43:34 GMT
    2. owner: set to Chris Johns <chrisj@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 4f5485e/rtems-tools:

    rtems-test: target_exe_filter fails when there is no filter Closes #4006

    4010 - Update mDNSResponder to Apple version v878.30.4

    Link https://devel.rtems.org/ticket/4010
    Id 4010
    Reporter Sebastian Huber
    Created 19 June 2020 10:58:40
    Modified 23 June 2020 16:23:20
    Owner Sebastian Huber
    Type enhancement
    Component network/libbsd
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Download

    • mDNSResponder-878.50.17.tar.gz
    • mDNSResponder-878.70.2.tar.gz
    • mDNSResponder-878.200.35.tar.gz
    • mDNSResponder-878.230.2.tar.gz
    • mDNSResponder-878.240.1.tar.gz
    • mDNSResponder-878.250.4.tar.gz
    • mDNSResponder-878.260.1.tar.gz
    • mDNSResponder-878.270.2.tar.gz

    from

    ​https://opensource.apple.com/tarballs/mDNSResponder/

    Merge each update into libbsd/mDNSResponder.

    These updates may contain security bug fixes.

    Comment 1
    1. Sebastian Huber, Fri, 19 Jun 2020 11:23:39 GMT
    2. summary: changed from Update mDNSResponder to Apple version v878.30.4 (cloned) to Update mDNSResponder to Apple version v878.30.4
    Comment 2
    1. Sebastian Huber, Tue, 23 Jun 2020 16:23:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    Changes are included in 5-freebsd-12 and master branch.


    4014 - RSB RTEMS 5 Post Branch Clean

    Link https://devel.rtems.org/ticket/4014
    Id 4014
    Reporter Chris Johns
    Created 26 June 2020 00:35:34
    Modified 12 August 2020 03:09:26
    Owner Chris Johns
    Type task
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Remove configuration and build set files from the RSB on the 5 branch that are not part of an RTEMS 5 release or are not referenced. This is a standard post release branch activity. For example removing the RTEMS 6 tool build set files.

    Comment 1
    1. Chris Johns, Wed, 12 Aug 2020 01:40:33 GMT

    In 020c63f/rtems-source-builder:

    rtems: Remove RTEMS 6 build sets. Updates #4014
    Comment 2
    1. Chris Johns, Wed, 12 Aug 2020 01:40:36 GMT

    In 673f9ad/rtems-source-builder:

    5: Remove unused configuration files for the release Updates #4014
    Comment 3
    1. Chris Johns, Wed, 12 Aug 2020 01:40:38 GMT

    In 4da24fb/rtems-source-builder:

    bare/libusb: Fix the configuration and add a hash Updates #4014
    Comment 4
    1. Chris Johns, Wed, 12 Aug 2020 03:09:26 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    4015 - Sqlite has stopped http access

    Link https://devel.rtems.org/ticket/4015
    Id 4015
    Reporter Chris Johns
    Created 26 June 2020 01:47:42
    Modified 26 June 2020 01:55:34
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The SQLite website has stopped serving http requests. Change to https.

    Comment 1
    1. Chris Johns, Fri, 26 Jun 2020 01:55:34 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 6537f4b/rtems-source-builder:

    sqlite: Change to https for downloading the source package. Closes #4015

    4016 - shm_unlink uses uninitialized obj_err on successful return from _POSIX_Shm_Get_by_name

    Link https://devel.rtems.org/ticket/4016
    Id 4016
    Reporter Kinsey Moore
    Created 28 June 2020 00:18:51
    Modified 11 August 2020 12:52:15
    Owner Kinsey Moore <kinsey.moore@…>
    Type defect
    Component posix
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In the nominal case checked by spsysinit01, obj_err in shm_unlink is unmodified when _POSIX_Shm_Get_by_name returns non-NULL. In the case of shm_unlink, this means an uninitialized value is passed into the switch and it appears this test was passing by virtue of the stack having the right value on it in most cases.

    Comment 1
    1. Chris Johns, Tue, 30 Jun 2020 07:55:19 GMT
    2. component: changed from admin to posix
    Comment 2
    1. Kinsey Moore, Thu, 06 Aug 2020 18:45:47 GMT

    The patches to fix this for 5.x and master have been posted to the mailing list for a while now.

    Comment 3
    1. Chris Johns, Mon, 10 Aug 2020 05:43:55 GMT

    Can you please provide the links to the devel list archive for the post patches?

    Comment 4
    1. Kinsey Moore, Mon, 10 Aug 2020 11:47:50 GMT

    Sure, this is the first patch posted for master back in January: ​https://lists.rtems.org/pipermail/devel/2020-January/056993.html

    And this is the more recent patch posted for 5.x specifically for this issue: ​https://lists.rtems.org/pipermail/devel/2020-June/060292.html

    Comment 5
    1. Chris Johns, Mon, 10 Aug 2020 23:26:50 GMT

    Thanks. Joel or someone who knows this part of the POSIX code is going to have to review these changes. I am working towards an RC2 so if the review is not done I will be forced to bump then to 5.2.

    Comment 6
    1. Joel Sherrill, Tue, 11 Aug 2020 12:33:12 GMT

    These are OK to push to the 5 branch and master. According to the mailing list archives, Gedare did review and approve one.

    Comment 7
    1. Kinsey Moore, Tue, 11 Aug 2020 12:48:50 GMT
    2. owner: set to Kinsey Moore <kinsey.moore@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In e95c00a7/rtems:

    posix: Only check shm_unlink obj_err if necessary In the nominal case checked by spsysinit01, obj_err is unmodified if _POSIX_Shm_Get_by_name returns non-NULL. In the case of shm_unlink, this means an uninitialized value is passed into the switch and it appears tests using it were passing by virtue of the stack having the right value on it in most cases. This now checks obj_err only if _POSIX_Shm_Get_by_name returns NULL. Close #4016
    Comment 8
    1. Kinsey Moore, Tue, 11 Aug 2020 12:52:15 GMT

    In 14749c45/rtems:

    posix: Only check shm_unlink obj_err if necessary In the nominal case checked by spsysinit01, obj_err is unmodified if _POSIX_Shm_Get_by_name returns non-NULL. In the case of shm_unlink, this means an uninitialized value is passed into the switch and it appears tests using it were passing by virtue of the stack having the right value on it in most cases. This now checks obj_err only if _POSIX_Shm_Get_by_name returns NULL. Close #4016

    4017 - RSB --host and --target option trigger the bset tarball

    Link https://devel.rtems.org/ticket/4017
    Id 4017
    Reporter Chris Johns
    Created 29 June 2020 09:19:36
    Modified 30 June 2020 08:04:35
    Owner Chris Johns
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Deep in the set builder is an old piece of logic to trigger tarballs when in a cross-compile environment. This dates back to cross-compling tool sets.

    The adding the kernel and 3rd party packages means the RSB command line can have the --host and --target options and if the kernel and a package like libbsd are on a single command line the --host and --target trigger a tarball install and this breaks the build.

    Fix:

    • Remove the tarball trigger.
    • Check the kernel and packages are not effected. Having both may break a package build if passed automatically to a configure command line.
    Comment 1
    1. Chris Johns, Tue, 30 Jun 2020 08:04:35 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 9b1545f/rtems-source-builder:

    sb/options: A Canadian Cross is a different host, build and target The check must make sure each is different. Closes #4017

    4021 - PowerPC for libbsd does not build

    Link https://devel.rtems.org/ticket/4021
    Id 4021
    Reporter Chris Johns
    Created 30 June 2020 07:48:12
    Modified 12 August 2020 03:03:06
    Owner Chris Johns <chrisj@…>
    Type defect
    Component network/libbsd
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority high
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Building a kernel and libbsd for the --with-rtems-bsp=mvme3100 libbsd fails with:

    In file included from /build/rtems/releases/build/5.1.0-rc1/install/powerpc-rtems5/mvme3100/lib/include/bsp.h:27:0,
    from ../../rtemsbsd/include/rtems/bsd/local/opt_usb.h:2,
    from ../../freebsd/sys/dev/usb/usb.h:46,
    from ../../freebsd/sys/dev/usb/usb_busdma.c:53:
    /build/rtems/releases/build/5.1.0-rc1/install/powerpc-rtems5/mvme3100/lib/include/libcpu/io.h:53:20: error: redefinition of 'eieio'
    static inline void eieio(void)
    ^~~~~
    In file included from ../../freebsd/sys/sys/systm.h:45:0,
    from ../../freebsd/sys/dev/usb/usb_busdma.c:39:
    ../../freebsd/sys/powerpc/include/machine/cpufunc.h:168:1: note: previous definition of 'eieio' was here
    eieio(void)
    ^~~~~
    In file included from ../../freebsd/sys/sys/systm.h:45:0,
    from ../../rtemsbsd/sys/arm/at91/at91_mci.c:38:
    ../../freebsd/sys/powerpc/include/machine/cpufunc.h:168:1: error: redefinition of 'eieio'
    eieio(void)
    ^~~~~
    In file included from /build/rtems/releases/build/5.1.0-rc1/install/powerpc-rtems5/mvme3100/lib/include/bsp.h:27:0,
    from /build/rtems/releases/build/5.1.0-rc1/install/powerpc-rtems5/mvme3100/lib/include/bsp/fdt.h:18,
    from ../../rtemsbsd/include/rtems/bsd/local/opt_platform.h:1,
    from ../../rtemsbsd/sys/arm/at91/at91_mci.c:32:
    /build/rtems/releases/build/5.1.0-rc1/install/powerpc-rtems5/mvme3100/lib/include/libcpu/io.h:53:20: note: previous definition of 'eieio' was here
    static inline void eieio(void)
    ^~~~~

    This is using 5.1.0-rc1.

    Comment 1
    1. Chris Johns, Tue, 30 Jun 2020 07:49:56 GMT
    2. description: modified (diff)
    Comment 2
    1. Chris Johns, Sat, 25 Jul 2020 05:50:55 GMT

    There ae a number of version of eieio in RTEMS. The implementation in io.h is:

    __asm__ __volatile__ ("eieio"); 

    and the FreeBSD is:

     __asm __volatile ("eieio" : : : "memory"); 

    I am not sure about the specifics of needing the memory constrain but I wonder if it is something we should do? I do not know the PowerPC well enough to know the effect of having memory as a constraint.

    Comment 3
    1. Sebastian Huber, Mon, 27 Jul 2020 04:42:09 GMT

    The "memory" clobber is important. Without it this instruction makes little sense.

    I think the real issue is the includes .

    We also have an ppc_enforce_in_order_execution_of_io() in .

    Comment 4
    1. Chris Johns, Tue, 28 Jul 2020 05:37:18 GMT

    Replying to Sebastian Huber:

    The "memory" clobber is important. Without it this instruction makes little sense.

    OK. I will add it.

    I think the real issue is the includes .

    We also have an ppc_enforce_in_order_execution_of_io() in .

    There are a number of eieio instructions in various pieces of code. I have renamed the function in io.h and LibBSD builds. Given this is for a release I am looking to only make small changes.

    Comment 5
    1. Chris Johns, Wed, 12 Aug 2020 03:03:06 GMT
    2. owner: set to Chris Johns <chrisj@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 5284e812/rtems:

    powerpc/io: The eieio() function clashes with FreeBSD. Change. Closes #4021

    4028 - i386: SMP-System hangs with non-consecutive APIC IDs

    Link https://devel.rtems.org/ticket/4028
    Id 4028
    Reporter Jan Sommer
    Created 15 July 2020 15:36:19
    Modified 8 October 2020 13:30:29
    Owner Jan Sommer <jan.sommer@…>
    Type defect
    Component arch/i386
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    If a processor enumerates its cores non-consecutively (e.g. 0,2,4,8 for a tested Intel Atom) the mapping to the per_CPU structures is not correct.

    Comment 1
    1. Jan Sommer, Wed, 15 Jul 2020 15:44:29 GMT

    I just noticed its not the per_cpu structures which does not work, but the IPIs are sent to the wrong CPU, because of the wrong mapping.

    I have a patch ready, but I experience an error when I try to attach a file to this ticket.

    Comment 2
    1. Jan Sommer, Thu, 16 Jul 2020 13:08:26 GMT
    2. owner: set to Jan Sommer <jan.sommer@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In a1f9265c/rtems:

    bsps/pc386: Fix IPI for non-consecutive APICIDs properly use the cpu <-> apic maps for IPIs Closes #4028.
    Comment 3
    1. Joel Sherrill, Thu, 08 Oct 2020 13:30:29 GMT

    In 560c08c/rtems:

    bsps/include/bsp/fatal.h: Add GRLIB specific fatal error updates #4028.

    4030 - i386: ISR can overwrite its own stack during system initialization

    Link https://devel.rtems.org/ticket/4030
    Id 4030
    Reporter Jan Sommer
    Created 22 July 2020 12:38:02
    Modified 29 July 2020 09:41:18
    Owner Jan Sommer <jan.sommer@…>
    Type defect
    Component arch/i386
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity major
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    During testing the rtems-libbsd examples, we experienced GP exceptions from within the ISR from time to time during initalization.

    When the init task is restored for the first time and the a pending interrupt is available, an ISR could overwrite its own return address if it is spawned between restoring the eflags register and restoring the esp register.

    Comment 1
    1. Jan Sommer, Wed, 29 Jul 2020 09:41:18 GMT
    2. owner: set to Jan Sommer <jan.sommer@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 849d7418/rtems:

    i386: Fix possible race condition on first context restore Make sure that the esp is restored before the eflags register. When the init task is initially restored, system interrupts are activated when the eflags register is loaded. If the esp register still points to an address in the interrupt stack area (from early system initlization) the ISR might overwrite its own stack. Closes #4030

    4033 - Add rtems_interrupt_server_create() and rtems_interrupt_server_destroy()

    Link https://devel.rtems.org/ticket/4033
    Id 4033
    Reporter Sebastian Huber
    Created 31 July 2020 06:52:59
    Modified 5 August 2020 05:01:10
    Owner Sebastian Huber
    Type enhancement
    Component lib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Currently, the only way to create interrupt servers is rtems_interrupt_server_initialize(). This function creates the default interrupt server and in SMP configurations additional interrupt servers for the additional processors. The interrupt server is heavily used by libbsd. This includes the epoch based reclamation which performs time consuming resource and memory deallocation work. This does not work well with time critical services, for example an UART over SPI or I2C. One approach to address this problem is to allow the application to create custom interrupt servers with the right priority and task properties. The interrupt server API accounted for this, however, it was not yet implemented.

    Add rtems_interrupt_server_create() and rtems_interrupt_server_destroy() for this purpose.

    Comment 1
    1. Sebastian Huber, Sat, 01 Aug 2020 09:55:44 GMT
    2. description: modified (diff)
    3. summary: changed from Add rtems_interrupt_server_build() and rtems_interrupt_server_destroy() to Add rtems_interrupt_server_create() and rtems_interrupt_server_destroy()
    Comment 2
    1. Sebastian Huber, Mon, 03 Aug 2020 06:51:58 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 5eb07731/rtems:

    rtems: Add rtems_interrupt_server_create() Add rtems_interrupt_server_destroy(). Before this patch, the only way to create interrupt servers was rtems_interrupt_server_initialize(). This function creates the default interrupt server and in SMP configurations additional interrupt servers for the additional processors. The interrupt server is heavily used by libbsd. This includes the epoch based reclamation which performs time consuming resource and memory deallocation work. This does not work well with time critical services, for example an UART over SPI or I2C. One approach to address this problem is to allow the application to create custom interrupt servers with the right priority and task properties. The interrupt server API accounted for this, however, it was not implemented before this patch. Close #4033.
    Comment 3
    1. Sebastian Huber, Wed, 05 Aug 2020 05:00:20 GMT

    In 534f9dbe/rtems:

    arm/atsam: Make interrupt server configurable The external UART over SPI device SC16IS752 uses the interrupt server for interrupt processing. The interrupt server is also heavily used by libbsd. The interrupt processing for the SC16IS752 is time critical and doesn't work if network traffic is processed at the same priority. With #4033 custom interrupt servers are available. Change atsam_sc16is752_spi_create() to support user-defined interrupt servers. Introduced atsam_sc16is752_spi_config to cut down the argument count of this function. Close #4038.
    Comment 4
    1. Sebastian Huber, Wed, 05 Aug 2020 05:01:10 GMT

    In 1b421585/rtems:

    arm/atsam: Make interrupt server configurable The external UART over SPI device SC16IS752 uses the interrupt server for interrupt processing. The interrupt server is also heavily used by libbsd. The interrupt processing for the SC16IS752 is time critical and doesn't work if network traffic is processed at the same priority. With #4033 custom interrupt servers are available. Change atsam_sc16is752_spi_create() to support user-defined interrupt servers. Introduced atsam_sc16is752_spi_config to cut down the argument count of this function. Close #4039.

    4038 - arm/atsam/SC16IS752: Make interrupt server configurable

    Link https://devel.rtems.org/ticket/4038
    Id 4038
    Reporter Sebastian Huber
    Created 3 August 2020 07:41:35
    Modified 5 August 2020 05:00:20
    Owner Sebastian Huber
    Type enhancement
    Component arch/arm
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The external UART over SPI device SC16IS752 uses the interrupt server for interrupt processing. The interrupt server is also heavily used by libbsd. The interrupt processing for the SC16IS752 is time critical and doesn't work if network traffic is processed at the same priority. With #4033 custom interrupt servers are available. Change atsam_sc16is752_spi_create() to support user-defined interrupt servers. Introduced atsam_sc16is752_spi_config to cut down the argument count of this function.

    Comment 1
    1. Sebastian Huber, Wed, 05 Aug 2020 05:00:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 534f9dbe/rtems:

    arm/atsam: Make interrupt server configurable The external UART over SPI device SC16IS752 uses the interrupt server for interrupt processing. The interrupt server is also heavily used by libbsd. The interrupt processing for the SC16IS752 is time critical and doesn't work if network traffic is processed at the same priority. With #4033 custom interrupt servers are available. Change atsam_sc16is752_spi_create() to support user-defined interrupt servers. Introduced atsam_sc16is752_spi_config to cut down the argument count of this function. Close #4038.

    4049 - RTEMS version number 5.1 breaks RTEMS version code

    Link https://devel.rtems.org/ticket/4049
    Id 4049
    Reporter Chris Johns
    Created 13 August 2020 03:08:27
    Modified 14 August 2020 21:17:56
    Owner  
    Type defect
    Component build
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The rtems.git code assumes major.minor.revision and changing it to version.revision breaks the configure processing to create the cpuopts.h file. For example using 5.1-rc2 as the version string results in:

    In file included from /build/rtems/releases/build/5.1-rc2/rtems-source-builder-5.1-rc2/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-5.1-rc2/rtems-5.1-rc2/cpukit/include/rtems/score/basedefs.h:31:0,
    from /build/rtems/releases/build/5.1-rc2/rtems-source-builder-5.1-rc2/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-5.1-rc2/rtems-5.1-rc2/cpukit/include/rtems/rtems/status.h:21,
    from /build/rtems/releases/build/5.1-rc2/rtems-source-builder-5.1-rc2/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-5.1-rc2/rtems-5.1-rc2/cpukit/include/rtems.h:29,
    from ../../../../../rtems-5.1-rc2/c/src/../../cpukit/sapi/src/version.c:27:
    ../../../../../rtems-5.1-rc2/c/src/../../cpukit/sapi/src/version.c: In function 'rtems_version_minor':
    /build/rtems/releases/build/5.1-rc2/rtems-source-builder-5.1-rc2/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-5.1-rc2/build/arm-rtems5/c/beagleboneblack/include/rtems/score/cpuopts.h:62:27: error: 'rc2' undeclared (first use in this function)
    #define __RTEMS_MINOR__ 1-rc2
    ^
    ../../../../../rtems-5.1-rc2/c/src/../../cpukit/sapi/src/version.c:48:10: note: in expansion of macro '__RTEMS_MINOR__'
    return __RTEMS_MINOR__;
    ^~~~~~~~~~~~~~~
    /build/rtems/releases/build/5.1-rc2/rtems-source-builder-5.1-rc2/rtems/build/arm-rtems5-kernel-beagleboneblack-1/arm-rtems5-kernel-beagleboneblack-1-5.1-rc2/build/arm-rtems5/c/beagleboneblack/include/rtems/score/cpuopts.h:62:27: note: each undeclared identifier is reported only once for each function it appears in
    #define __RTEMS_MINOR__ 1-rc2
    ^
    ../../../../../rtems-5.1-rc2/c/src/../../cpukit/sapi/src/version.c:48:10: note: in expansion of macro '__RTEMS_MINOR__'
    return __RTEMS_MINOR__;
    ^~~~~~~~~~~~~~~
    ../../../../../rtems-5.1-rc2/c/src/../../cpukit/sapi/src/version.c:49:1: warning: control reaches end of non-void function [-Wreturn-type]
    }
    ^
    gmake[4]: *** [Makefile:11437: sapi/src/version.o] Error 1

    I suggest the release script adds the third digit. Note, this is a hack however given this point in the release anything else is too late.

    Comment 1
    1. Chris Johns, Fri, 14 Aug 2020 21:17:56 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Fixed on the 5 branch of rtems-release.git.


    4051 - libbsd test fails to build

    Link https://devel.rtems.org/ticket/4051
    Id 4051
    Reporter Chris Johns
    Created 13 August 2020 08:44:07
    Modified 14 August 2020 21:18:29
    Owner  
    Type defect
    Component release
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity blocker
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In file included from ../../testsuite/cdev01/test_main.c:153:0:
    ../../testsuite/include/rtems/bsd/test/default-init.h: In function 'Init':
    ../../testsuite/include/rtems/bsd/test/default-init.h:48:31: error: 'TEST_STATE' undeclared (first use in this function); did you mean 'TEST_WRITE'?
    rtems_test_begin(TEST_NAME, TEST_STATE);
    ^~~~~~~~~~
    TEST_WRITE
    ../../testsuite/include/rtems/bsd/test/default-init.h:48:31: note: each undeclared identifier is reported only once for each function it appears in
    In file included from ../../testsuite/arphole/test_main.c:118:0:
    ../../testsuite/include/rtems/bsd/test/default-network-init.h: In function 'Init':
    ../../testsuite/include/rtems/bsd/test/default-network-init.h:195:30: error: 'TEST_STATE' undeclared (first use in this function); did you mean 'TEST_NAME'?
    rtems_test_begin(TEST_NAME, TEST_STATE);
    ^~~~~~~~~~
    TEST_NAME
    ../../testsuite/include/rtems/bsd/test/default-network-init.h:195:30: note: each undeclared identifier is reported only once for each function it appears in
    In file included from ../../testsuite/commands01/test_main.c:340:0:
    ../../testsuite/include/rtems/bsd/test/default-init.h: In function 'Init':
    ../../testsuite/include/rtems/bsd/test/default-init.h:48:31: error: 'TEST_STATE' undeclared (first use in this function); did you mean 'TEST_NAME'?
    rtems_test_begin(TEST_NAME, TEST_STATE);
    ^~~~~~~~~~
    TEST_NAME
    ../../testsuite/include/rtems/bsd/test/default-init.h:48:31: note: each undeclared identifier is reported only once for each function it appears in
    In file included from ../../testsuite/condvar01/test_main.c:404:0:
    ../../testsuite/include/rtems/bsd/test/default-init.h: In function 'Init':
    ../../testsuite/include/rtems/bsd/test/default-init.h:48:31: error: 'TEST_STATE' undeclared (first use in this function); did you mean 'TEST_NAME'?
    rtems_test_begin(TEST_NAME, TEST_STATE);
    ^~~~~~~~~~
    TEST_NAME
    ../../testsuite/include/rtems/bsd/test/default-init.h:48:31: note: each undeclared identifier is reported only once for each function it appears in
    In file included from ../../testsuite/dhcpcd01/test_main.c:78:0:
    ../../testsuite/include/rtems/bsd/test/default-network-init.h: In function 'Init':
    ../../testsuite/include/rtems/bsd/test/default-network-init.h:195:30: error: 'TEST_STATE' undeclared (first use in this function); did you mean 'TEST_NAME'?
    rtems_test_begin(TEST_NAME, TEST_STATE);
    ^~~~~~~~~~
    TEST_NAME
    ../../testsuite/include/rtems/bsd/test/default-network-init.h:195:30: note: each undeclared identifier is reported only once for each function it appears in
    In file included from ../../testsuite/crypto01/test_main.c:204:0:
    ../../testsuite/include/rtems/bsd/test/default-init.h: In function 'Init':
    ../../testsuite/include/rtems/bsd/test/default-init.h:48:31: error: 'TEST_STATE' undeclared (first use in this function); did you mean 'TEST_NAME'?
    rtems_test_begin(TEST_NAME, TEST_STATE);
    ^~~~~~~~~~
    TEST_NAME
    ../../testsuite/include/rtems/bsd/test/default-init.h:48:31: note: each undeclared identifier is reported only once for each function it appears in
    In file included from ../../testsuite/dhcpcd02/test_main.c:55:0:
    ../../testsuite/include/rtems/bsd/test/default-network-init.h: In function 'Init':
    ../../testsuite/include/rtems/bsd/test/default-network-init.h:195:30: error: 'TEST_STATE' undeclared (first use in this function); did you mean 'TEST_NAME'?
    rtems_test_begin(TEST_NAME, TEST_STATE);
    ^~~~~~~~~~
    TEST_NAME
    ../../testsuite/include/rtems/bsd/test/default-network-init.h:195:30: note: each undeclared identifier is reported only once for each function it appears in
    ../../testsuite/evdev01/init.c: In function 'Init':
    ../../testsuite/evdev01/init.c:574:30: error: 'TEST_STATE' undeclared (first use in this function); did you mean 'TEST_NAME'?
    rtems_test_begin(TEST_NAME, TEST_STATE);
    ^~~~~~~~~~
    TEST_NAME
    ../../testsuite/evdev01/init.c:574:30: note: each undeclared identifier is reported only once for each function it appears in
    In file included from ../../testsuite/foobarclient/test_main.c:283:0:
    ../../testsuite/include/rtems/bsd/test/default-network-init.h: In function 'Init':
    ../../testsuite/include/rtems/bsd/test/default-network-init.h:195:30: error: 'TEST_STATE' undeclared (first use in this function); did you mean 'TEST_NAME'?
    rtems_test_begin(TEST_NAME, TEST_STATE);
    ^~~~~~~~~~
    TEST_NAME
    ../../testsuite/include/rtems/bsd/test/default-network-init.h:195:30: note: each undeclared identifier is reported only once for each function it appears in
    In file included from ../../testsuite/foobarserver/test_main.c:227:0:
    ../../testsuite/include/rtems/bsd/test/default-network-init.h: In function 'Init':
    ../../testsuite/include/rtems/bsd/test/default-network-init.h:195:30: error: 'TEST_STATE' undeclared (first use in this function); did you mean 'TEST_NAME'?
    rtems_test_begin(TEST_NAME, TEST_STATE);
    ^~~~~~~~~~
    TEST_NAME
    ../../testsuite/include/rtems/bsd/test/default-network-init.h:195:30: note: each undeclared identifier is reported only once for each function it appears in
    ../../testsuite/epoch01/test_main.c:82:2: error: unknown type name 'rtems_test_parallel_context'
    rtems_test_parallel_context base;
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~
    ../../testsuite/epoch01/test_main.c:100:11: error: unknown type name 'rtems_test_parallel_context'; did you mean 'rtems_assert_context'?
    test_init(rtems_test_parallel_context *base, void *arg, size_t active_workers)
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~
    rtems_assert_context
    ../../testsuite/epoch01/test_main.c:110:11: error: unknown type name 'rtems_test_parallel_context'; did you mean 'rtems_assert_context'?
    test_fini(rtems_test_parallel_context *base, const char *name,
    Comment 1
    1. Chris Johns, Thu, 13 Aug 2020 08:47:07 GMT

    The build log is showing:

    + cd /build/rtems/releases/build/5.1-rc2/rtems-source-builder-5.1-rc2/rtems/build/rtems-libbsd-b96abfd647154f10ea8f7fac68e25676636eded5-x86_64-freebsd12.1-1 

    This looks like the wrong branch or version is being packaged.

    Comment 2
    1. Chris Johns, Thu, 13 Aug 2020 11:57:05 GMT
    2. component: changed from network/libbsd to release

    It looks like the release to branch mapping in the release script is broken. This was added to handle the inconsistent branch naming in libbsd:

    Package rtems-source-builder 5: master 

    The branch should be 5 not master.

    Comment 3
    1. Chris Johns, Fri, 14 Aug 2020 21:18:29 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    Fix, the right branch is being used.


    4056 - bsps/xilinx-zynq: Flush TX-Buffer before initializing the zynq-uart (cloned)

    Link https://devel.rtems.org/ticket/4056
    Id 4056
    Reporter Jan Sommer
    Created 20 August 2020 07:12:07
    Modified 22 August 2020 07:30:22
    Owner Jan Sommer <jan.sommer@…>
    Type defect
    Component bsps
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Cloned from #4055:

    We experienced that u-boot (at least from Xilinx repositories) does not wait until all its output has left the TX Buffer of the stdout uart, before handing over to the RTEMS application

    This causes some garbage output at the begin of the RTEMS application in some cases and corrupts the test begin marker prohibiting rtems-test to recognize the test correctly.

    Proposed fix is to let RTEMS wait until the TX Buffer of the uart is empty before configuring and using it.

    Comment 1
    1. Jan Sommer, Sat, 22 Aug 2020 07:29:38 GMT
    2. owner: set to Jan Sommer <jan.sommer@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In b87efa7/rtems:

    bsp/xilinx-zynq: Flush TX-Buffer before initializing uart Closes #4055 Closes #4056
    Comment 2
    1. Jan Sommer, Sat, 22 Aug 2020 07:30:22 GMT

    In 61ccb9c0/rtems:

    bsp/xilinx-zynq: Flush TX-Buffer before initializing uart Closes #4055 Closes #4056

    4057 - RSB 5/rtems-arm fails to build on Windows

    Link https://devel.rtems.org/ticket/4057
    Id 4057
    Reporter Chris Johns
    Created 20 August 2020 22:31:06
    Modified 25 August 2020 04:05:44
    Owner  
    Type defect
    Component tool/newlib
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority highest
    Severity critical
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    In file included from ../../../../../../../../../../../gcc-7.5.0/newlib/libm/machine/arm/s_ceil.c:39:0:
    ../../../../../../../../../../../gcc-7.5.0/newlib/libm/machine/arm/../../math/s_ceil.c:23:10: fatal error: fdlibm.h: No such file or directory
    #include "fdlibm.h"
    ^~~~~~~~~~
    compilation terminated.
    make[9]: *** [Makefile:310: lib_a-s_ceil.o] Error 1
    make[9]: *** Waiting for unfinished jobs....
    In file included from ../../../../../../../../../../../gcc-7.5.0/newlib/libm/machine/arm/s_floor.c:39:0:
    ../../../../../../../../../../../gcc-7.5.0/newlib/libm/machine/arm/../../math/s_floor.c:65:10: fatal error: fdlibm.h: No such file or directory
    #include "fdlibm.h"
    ^~~~~~~~~~
    compilation terminated.
    Comment 1
    1. Chris Johns, Tue, 25 Aug 2020 04:05:44 GMT
    2. status: changed from new to closed
    3. resolution: set to fixed

    I am going to close this. The issues I am seeing with rtems-release-test on Windows are related to file paths exceeding the maximum limit on Windows.


    4083 - i386: bad asm in smp mode (rtems.git/5)

    Link https://devel.rtems.org/ticket/4083
    Id 4083
    Reporter Gedare Bloom
    Created 21 September 2020 17:22:31
    Modified 2 October 2020 16:40:19
    Owner Gedare Bloom
    Type defect
    Component arch/i386
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Cloned from #4076:

    A note for me (or someone) to make the fix outlined on the mailing list.

    cpukit/score/cpu/i386/include/rtems/asm.h:157   movb
    imps_apic_cpu_map(\REG),\REG        /* CPU ID in REG */

    The assembler is right to complain. movb has to target one of the
    1-byte mnemonics, so this should be %al for the LSB of %eax. One needs
    to check through this logic carefully, but I think the right thing to
    do here is:
    movzbl     imps_apic_cpu_map(\REG),\REG

    That should do the trick. Can you test it locally?

    Sure! Builds fine and testsuite testing reveals:

    Joel would like this fixed on 5.

    Comment 1
    1. Gedare Bloom, Mon, 21 Sep 2020 17:23:05 GMT
    2. description: modified (diff)
    Comment 2
    1. Gedare Bloom, Fri, 02 Oct 2020 16:40:19 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 40f23cea/rtems:

    i386/score: fix assembly mnemonic This is a backport for assembler error observed in 6. Although the assembler error does not appear in 5, the backport was requested. Closes #4083.

    4137 - The select mechanism does not support asynchronous device communication

    Link https://devel.rtems.org/ticket/4137
    Id 4137
    Reporter only_yipie
    Created 9 October 2020 10:58:44
    Modified 10 November 2022 00:01:46
    Owner  
    Type defect
    Component admin
    Status closed
    Resolution invalid
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords select
    Cc  
    Blocking  
    Blocked by  

    Description

    The select mechanism does not support asynchronous device communication.

    Comment 1
    1. only_yipie, Fri, 09 Oct 2020 11:22:27 GMT
    2. milestone: changed from 4.9.5 to 5.1
    Comment 2
    1. Joel Sherrill, Fri, 09 Oct 2020 12:49:30 GMT

    I am trouble interpreting what this is even saying does not work. It mentions no specific devices, APIs, or includes a test case. select() now does work on termios devices if that was what this was about.

    It needs clarification or closing as no idea what to do.

    Comment 3
    1. only_yipie, Sun, 21 Mar 2021 08:33:26 GMT
    2. version: changed from 4.9 to 4.11
    Comment 4
    1. only_yipie, Sun, 21 Mar 2021 09:36:44 GMT

    well, I mean that the select() does not implement the mentioned function Replying to Joel Sherrill:

    I am trouble interpreting what this is even saying does not work. It mentions no specific devices, APIs, or includes a test case. select() now does work on termios devices if that was what this was about.

    It needs clarification or closing as no idea what to do.

    Comment 5
    1. Chris Johns, Thu, 10 Nov 2022 00:01:46 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    We need more information to work on this.


    4138 - the atomicity of some operations cannot be guaranteed.

    Link https://devel.rtems.org/ticket/4138
    Id 4138
    Reporter only_yipie
    Created 9 October 2020 11:11:21
    Modified 10 November 2022 00:02:42
    Owner  
    Type defect
    Component tool/gcc
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords gcc、atomicity.h
    Cc  
    Blocking  
    Blocked by  

    Description

    The atomic operations _atmoic_add() and exchange_and_add() of the gcci386 tool chain do not use the lock instruction, thus the atomicity of operations cannot be guaranteed.
    The related file is "gcc-4.9.3/libstdc++-v3/config/cpu/i386/atomicity.h".

    Comment 1
    1. only_yipie, Fri, 09 Oct 2020 11:24:16 GMT
    2. milestone: changed from 4.9.5 to 5.1
    Comment 2
    1. Joel Sherrill, Fri, 09 Oct 2020 11:25:57 GMT

    Is this not fixed with the recent multilib change?

    Comment 3
    1. only_yipie, Sun, 21 Mar 2021 09:32:21 GMT
    2. version: changed from 4.9 to 4.11
    Comment 4
    1. only_yipie, Sun, 21 Mar 2021 09:33:42 GMT

    no we used our own method to improve this problem and we will submit the solution later. Replying to Joel Sherrill:

    Is this not fixed with the recent multilib change?

    Comment 5
    1. Chris Johns, Thu, 10 Nov 2022 00:02:42 GMT
    2. status: changed from new to closed
    3. version: changed from 4.11 to 5
    4. resolution: set to wontfix

    Please reopen with the mentioned changes.


    4139 - low efficiency of sending inter-core interrupts

    Link https://devel.rtems.org/ticket/4139
    Id 4139
    Reporter only_yipie
    Created 9 October 2020 11:19:06
    Modified 10 November 2022 00:06:24
    Owner  
    Type defect
    Component lib
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords inter-core interrupts
    Cc  
    Blocking  
    Blocked by  

    Description

    In the pc386 board-level support package, calling UDELAY(100) in send_api() results in low efficiency of sending inter-core interrupts.
    The related file is "c/src/lib/libbsp/i386/shared/smp/smp-imps.c".

    Comment 1
    1. only_yipie, Fri, 09 Oct 2020 11:24:39 GMT
    2. milestone: changed from 4.9.5 to 5.1
    Comment 2
    1. only_yipie, Sun, 21 Mar 2021 09:31:00 GMT
    2. version: changed from 4.9 to 4.11

    we improve the performance by deleting the udelay(100)

    Comment 3
    1. Chris Johns, Thu, 10 Nov 2022 00:06:24 GMT
    2. status: changed from new to closed
    3. version: changed from 4.11 to 5
    4. resolution: set to wontfix

    Please reopen when the fixes are provided.


    4170 - Raspberry Pi booting files from master branch not working

    Link https://devel.rtems.org/ticket/4170
    Id 4170
    Reporter Miguel Garcia-Gordillo
    Created 4 November 2020 08:50:37
    Modified 10 November 2022 00:07:39
    Owner  
    Type defect
    Component doc
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords raspberrypi2, boot
    Cc  
    Blocking  
    Blocked by  

    Description

    In order to execute an RTEMS 5.1 image in a Raspberry Pi 2, documentation (​https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/user/bsps/bsps-arm.html#setup-sd-card) specifies that the boot files can be downloaded from ​https://github.com/raspberrypi/firmware/tree/master/boot

    Last commit that I could check is 0c3ecac5... and it does not work.

    On the other hand, I could check the version in tag 1.20190718 and it works. ​https://github.com/raspberrypi/firmware/tree/1.20190718/boot

    Maybe documentation can be updated to link with the correct version of Raspberry Pi booting.

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 00:07:39 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    Please use RTEMS 6 (main branch)


    4210 - rtems-record-lttng '-e' option does not verify existance

    Link https://devel.rtems.org/ticket/4210
    Id 4210
    Reporter Ryan Long
    Created 4 January 2021 22:55:59
    Modified 10 November 2022 00:08:28
    Owner  
    Type defect
    Component tool
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    When using the rtems-record-lttng program, I was not getting an error when using the program in a directory where the ELF executable file did not exist.

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 00:08:28 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    Please reopen when a fix is provided.


    4325 - Ubuntu's gcc preventing QEMU from being built

    Link https://devel.rtems.org/ticket/4325
    Id 4325
    Reporter Ryan Long
    Created 9 March 2021 15:05:27
    Modified 10 November 2022 00:09:34
    Owner  
    Type defect
    Component tool/rsb
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Ubuntu version: 20.4
    GCC version: (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

    Error:

    ../../glib-2.46.2/gio/gdbusauth.c: In function '_g_dbus_auth_run_server':
    ../../glib-2.46.2/gio/gdbusauth.c:1295:11: error: '%s' directive argument is null [-Werror=format-overflow=]
    1295 | debug_print ("SERVER: WaitingForBegin, read '%s'", line);
    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 00:09:34 GMT
    2. status: changed from new to closed
    3. resolution: set to wontfix

    Please reopen when being worked on or a fix is available.


    4352 - about get cpu number

    Link https://devel.rtems.org/ticket/4352
    Id 4352
    Reporter only_yipie
    Created 21 March 2021 09:11:45
    Modified 10 November 2022 00:10:48
    Owner  
    Type defect
    Component bsps
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords cpu number
    Cc  
    Blocking  
    Blocked by  

    Description

    The x86 multi-core version can get the correct core number on qemu, but the core number is wrong on the real machine which supports hyper-threaded.
    the related files are
    c\src\lib\libbsp\i386\shared\smp\smp-imp.c
    c\src\lib\libbsp\i386\shared\smp\getcpuid.c

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 00:10:48 GMT
    2. status: changed from new to closed
    3. version: changed from 4.11 to 5
    4. resolution: set to wontfix

    Please reopen when being worked on or a fix is available.


    4353 - the pci initialization part cannot pass the initialization

    Link https://devel.rtems.org/ticket/4353
    Id 4353
    Reporter only_yipie
    Created 21 March 2021 09:26:25
    Modified 10 November 2022 00:11:16
    Owner  
    Type defect
    Component admin
    Status closed
    Resolution wontfix
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    the pci initialization part of x86 version cannot be initialized on the real machine.
    the realted file is
    bsp/i386/shared/pci/pcibios.c

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 00:11:16 GMT
    2. status: changed from new to closed
    3. version: changed from 4.11 to 5
    4. resolution: set to wontfix

    Please reopen when being worked on or a fix is available.


    4362 - about error number

    Link https://devel.rtems.org/ticket/4362
    Id 4362
    Reporter only_yipie
    Created 27 March 2021 02:32:47
    Modified 10 November 2022 01:07:27
    Owner  
    Type defect
    Component network/legacy
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority low
    Severity trivial
    Keywords ERROR NUMBER
    Cc  
    Blocking  
    Blocked by  

    Description

    We found that there is an error code defined as 5, usually the error code is defined as -1, which will cause confusion in the return value of the program, although this error code has not been used.
    related file is
    cpukit\ftpd\ftpd.h in line 66 #define ERROR 5

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 01:07:27 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid
    4. version: changed from 4.11 to 5
    5. component: changed from admin to network/legacy

    I do not understand the issue.


    4385 - grlib/genirq: Bad returned value when enabling/disabling interrupt

    Link https://devel.rtems.org/ticket/4385
    Id 4385
    Reporter GabrielMoyano
    Created 13 April 2021 05:46:42
    Modified 16 April 2021 06:50:42
    Owner Moyano Gabriel <gabriel.moyano@…>
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version  
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The function genirq_set_active() can return a value greater than 1 under some conditions

    This function is used by genirq_enable() and genirq_disable() and both of them returns the value returned by genirq_set_active(). According to the documentation in genirq.h, they should return -1, 0 or 1.

    When this issue can happen? If there are 3 entries in the list of IRQ and 2 of them are already enabled, the variable enabled would be 2, because of enabled += isrentry->enabled.

    As a possible solution, the value of enabled can changed to 1 if it's greater than 1.

    Comment 1
    1. Moyano, Gabriel, Fri, 16 Apr 2021 06:50:42 GMT
    2. owner: set to Moyano, Gabriel <gabriel.moyano@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In bc806d4/rtems:

    grlib/genirq: Taking into account that it could be more than one ISR enabled/disabled Closes #4385

    4457 - shell command problem

    Link https://devel.rtems.org/ticket/4457
    Id 4457
    Reporter tianye
    Created 11 June 2021 08:22:06
    Modified 10 November 2022 00:41:51
    Owner  
    Type defect
    Component shell
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    If one task is default mode, "task" command in shell echo "P:T:nA", actually default task mode is "P:nT:nA"

    func:rtems_monitor_dump_modes

    Comment 1
    1. tianye, Fri, 11 Jun 2021 08:22:59 GMT
    2. summary: changed from shell command task problem to shell command problem
    Comment 2
    1. Chris Johns, Thu, 10 Nov 2022 00:41:51 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid
    4. component: changed from admin to shell

    Not sure what the issue is.


    4465 - m68k/uC5282: _fini epilog is missing

    Link https://devel.rtems.org/ticket/4465
    Id 4465
    Reporter Gedare Bloom
    Created 1 July 2021 18:53:31
    Modified 1 July 2021 19:00:58
    Owner Gedare Bloom
    Type defect
    Component arch/m68k
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Between 4.11 and 5, something changed that causes the _fini() to raise an exception.

    0005d428 <_fini>:

    5d428: 4e56 0000 linkw %fp,#0 5d42c: 0000 .short 0x0000

    0000 as an instruction is causing the exception. The problem appears to be in the linkcmds.

    Comment 1
    1. Gedare Bloom, Thu, 01 Jul 2021 19:00:58 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In e5a1b15/rtems:

    m68k/uC5282: linkcmds KEEP and SORT sections Fixes a problem with bad epilog code in _fini and to keep sections necessary with the -ffunction/data-sections. Closes #4465.

    4495 - rtems-tools does not build with up-to-date llvm

    Link https://devel.rtems.org/ticket/4495
    Id 4495
    Reporter Christian Mauderer
    Created 17 August 2021 06:39:51
    Modified 17 August 2021 10:58:20
    Owner Christian Mauderer
    Type defect
    Component admin
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    On the 5 branch of the rtems-source-builder, rtems-tools can't be build if the llvm on the host is (for example) version 10 or newer. Reason is that the llvm headers use a newer C++ standard starting from that version.

    On the 6 branch there already is a patch for that:

    ​https://git.rtems.org/rtems-tools/commit/?id=37ad446d9dce3438d6d32e1caf56d3fdccdd2ad0

    Comment 1
    1. Christian Mauderer, Tue, 17 Aug 2021 09:21:59 GMT

    In 0a5d205/rtems-tools:

    trace: Use c++14 instead of c++11 if possible llvm version 10 uses features from c++14 standard in the headers. With that, the record/record-main-lttng.cc doesn't build any more. This patch makes sure that c++14 is used if it is available. Updates #4495
    Comment 2
    1. Christian Mauderer, Tue, 17 Aug 2021 10:58:20 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In c7870f6/rtems-source-builder:

    rtems-tools: Pick up fix for modern llvm Closes #4495

    4535 - acess JFFS2 sb->s_root question

    Link https://devel.rtems.org/ticket/4535
    Id 4535
    Reporter chenjin_zhong
    Created 27 October 2021 14:34:15
    Modified 28 October 2021 05:21:11
    Owner  
    Type defect
    Component fs/jffs2
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Hi, I have found when access global structure without mutex or spinlock about JFFS2. The code in RTEMS5.1 are listed as follows:

    fs-rtems.c:

    1) __ Add to the icache __

    for (cached_inode = sb->s_root; cached_inode != NULL;

    cached_inode = cached_inode->i_cache_next) {

    if (cached_inode->i_cache_next == NULL) {

    cached_inode->i_cache_next = inode; __ Current last in cache points to newcomer
    inode->i_cache_prev = cached_inode; __ Newcomer points back to last
    break;

    }

    }

    2) __ Check for this inode in the cache __

    for (inode = sb->s_root; inode != NULL; inode = inode->i_cache_next) {

    if (inode->i_ino == ino) {

    inode->i_count++;
    break;

    }

    }

    when multi-tasks or threads access sb->s_root simultaneously, The behavior is unknown.

    Comment 1
    1. Sebastian Huber, Thu, 28 Oct 2021 05:19:18 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance:

    static void rtems_jffs2_do_lock(struct super_block *sb)
    {
            rtems_recursive_mutex_lock(&sb->s_mutex);
    }
    static void rtems_jffs2_do_unlock(struct super_block *sb)
    {
            rtems_recursive_mutex_unlock(&sb->s_mutex);
    } 
    Comment 2
    1. Sebastian Huber, Thu, 28 Oct 2021 05:21:11 GMT
    2. component: changed from admin to fs/jaffs2

    4536 - acess JFFS2 sb->s_root

    Link https://devel.rtems.org/ticket/4536
    Id 4536
    Reporter chenjin_zhong
    Created 27 October 2021 14:47:06
    Modified 28 October 2021 18:29:00
    Owner  
    Type defect
    Component fs/jffs2
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Hi, I have found when access global structure without mutex or spinlock about JFFS2 may cause indetermination. The peice of source code in RTEMS5.1 are listed as follows:

    fs-rtems.c:

    1) __ Add to the icache __

    for (cached_inode = sb->s_root; cached_inode != NULL;

    cached_inode = cached_inode->i_cache_next) {

    if (cached_inode->i_cache_next == NULL) {

    cached_inode->i_cache_next = inode; __ Current last in cache points to newcomer
    inode->i_cache_prev = cached_inode; __ Newcomer points back to last
    break;

    }

    }

    2) __ Check for this inode in the cache __

    for (inode = sb->s_root; inode != NULL; inode = inode->i_cache_next) {

    if (inode->i_ino == ino) {

    inode->i_count++;
    break;

    }

    }

    when multi-tasks or threads access sb->s_root simultaneously, The behavior is unknown.

    Comment 1
    1. Sebastian Huber, Thu, 28 Oct 2021 05:19:37 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance:

    static void rtems_jffs2_do_lock(struct super_block *sb)
    {
            rtems_recursive_mutex_lock(&sb->s_mutex);
    }
    static void rtems_jffs2_do_unlock(struct super_block *sb)
    {
            rtems_recursive_mutex_unlock(&sb->s_mutex);
    } 
    Comment 2
    1. Sebastian Huber, Thu, 28 Oct 2021 05:21:30 GMT
    2. component: changed from admin to fs/jaffs2
    Comment 3
    1. chenjin_zhong, Thu, 28 Oct 2021 14:53:51 GMT
    2. status: changed from closed to reopened
    3. resolution: invalid deleted

    Replying to Sebastian Huber:

    Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance:

    static void rtems_jffs2_do_lock(struct super_block *sb)
    {
            rtems_recursive_mutex_lock(&sb->s_mutex);
    }
    static void rtems_jffs2_do_unlock(struct super_block *sb)
    {
            rtems_recursive_mutex_unlock(&sb->s_mutex);
    } 

    Suppose that a GC thread or other thread/task calls jffs2_garbage_collect_pass, and then operates sb->s_root by jffs2_iget.meanwhile, the main task accesing sb->s_root. a global lock for each JFFS2 instance can't work.

    Comment 4
    1. Sebastian Huber, Thu, 28 Oct 2021 18:29:00 GMT
    2. status: changed from reopened to closed
    3. resolution: set to invalid

    Replying to chenjin_zhong:

    Replying to Sebastian Huber:

    Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance:

    static void rtems_jffs2_do_lock(struct super_block *sb)
    {
            rtems_recursive_mutex_lock(&sb->s_mutex);
    }
    static void rtems_jffs2_do_unlock(struct super_block *sb)
    {
            rtems_recursive_mutex_unlock(&sb->s_mutex);
    } 

    Suppose that a GC thread or other thread/task calls jffs2_garbage_collect_pass, and then operates sb->s_root by jffs2_iget.meanwhile, the main task accesing sb->s_root. a global lock for each JFFS2 instance can't work.

    It is not a high performance approach, but it works. See testsuites/fstests/fsjffs2gc01/init.c.


    4537 - mutex is not initilaized in jffs2_new_inode

    Link https://devel.rtems.org/ticket/4537
    Id 4537
    Reporter chenjin_zhong
    Created 27 October 2021 14:59:07
    Modified 28 October 2021 14:45:13
    Owner  
    Type defect
    Component fs/jffs2
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    HI, I have found when call jffs2_new_inode to create inode. the f->sem is not initiliazed and lock, but it is be unlocked. The peice of source code is as follows:

    struct _inode *jffs2_new_inode (struct _inode *dir_i, int mode, struct jffs2_raw_inode *ri)
    {

    struct _inode *inode;
    struct super_block *sb = dir_i->i_sb;
    struct jffs2_sb_info *c;
    struct jffs2_inode_info *f;
    int ret;

    D1(printk(KERN_DEBUG "jffs2_new_inode(): dir_i %ld, mode 0x%x\n", dir_i->i_ino, mode));
    c = JFFS2_SB_INFO(sb);

    inode = new_inode(sb);

    if (!inode)

    return ERR_PTR(-ENOMEM);

    f = JFFS2_INODE_INFO(inode);
    jffs2_init_inode_info(f);

    memset(ri, 0, sizeof(*ri));
    /* Set OS-specific defaults for new inodes */
    ri->uid = cpu_to_je16(geteuid());
    ri->gid = cpu_to_je16(getegid());
    ri->mode = cpu_to_jemode(mode);
    ret = jffs2_do_new_inode (c, f, mode, ri);
    if (ret) {

    __ forceful evict: f->sem is locked already, and the __ inode is bad.
    if (inode->i_cache_prev)

    inode->i_cache_prev->i_cache_next = inode->i_cache_next;

    if (inode->i_cache_next)

    inode->i_cache_next->i_cache_prev = inode->i_cache_prev;

    __mutex_unlock(&(f->sem))__;
    jffs2_clear_inode(inode);
    memset(inode, 0x6a, sizeof(*inode));
    free(inode);
    return ERR_PTR(ret);

    }
    inode->i_nlink = 1;
    inode->i_ino = je32_to_cpu(ri->ino);
    inode->i_mode = jemode_to_cpu(ri->mode);
    inode->i_gid = je16_to_cpu(ri->gid);
    inode->i_uid = je16_to_cpu(ri->uid);
    inode->i_atime = inode->i_ctime = inode->i_mtime = get_seconds();
    ri->atime = ri->mtime = ri->ctime = cpu_to_je32(inode->i_mtime);
    inode->i_size = 0;
    return inode;

    }

    Comment 1
    1. Joel Sherrill, Wed, 27 Oct 2021 18:38:19 GMT

    The code in this file is related to similar code for ports of JFFS2. Can you compare this to the current code for Linux and other ports to see what they do? That might significantly ease the analysis for all these issues.

    Comment 2
    1. Sebastian Huber, Thu, 28 Oct 2021 05:20:02 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance:

    static void rtems_jffs2_do_lock(struct super_block *sb)
    {
            rtems_recursive_mutex_lock(&sb->s_mutex);
    }
    static void rtems_jffs2_do_unlock(struct super_block *sb)
    {
            rtems_recursive_mutex_unlock(&sb->s_mutex);
    } 
    Comment 3
    1. Sebastian Huber, Thu, 28 Oct 2021 05:20:15 GMT
    2. component: changed from admin to fs/jaffs2
    Comment 4
    1. chenjin_zhong, Thu, 28 Oct 2021 14:34:47 GMT

    Replying to Joel Sherrill:

    The code in this file is related to similar code for ports of JFFS2. Can you compare this to the current code for Linux and other ports to see what they do? That might significantly ease the analysis for all these issues.

    I have compared it with Linux JFFS2. The peice of source code in Linux is as follows,As shown in black-body section, the f->sem is not be initialized and locked in RTEMS.

    struct jffs2_sb_info *c; struct jffs2_raw_inode latest_node; union jffs2_device_node jdev; struct inode *inode; dev_t rdev = 0; int ret;

    jffs2_dbg(1, "%s(): ino == %lu\n", func, ino);

    inode = iget_locked(sb, ino); if (!inode)

    return ERR_PTR(-ENOMEM);

    if (!(inode->i_state & I_NEW))

    return inode;

    f = JFFS2_INODE_INFO(inode); c = JFFS2_SB_INFO(inode->i_sb);

    jffs2_init_inode_info(f); __mutex_lock(&f->sem);__

    ret = jffs2_do_read_inode(c, f, inode->i_ino, &latest_node); if (ret)

    goto error;

    inode->i_mode = jemode_to_cpu(latest_node.mode); i_uid_write(inode, je16_to_cpu(latest_node.uid)); i_gid_write(inode, je16_to_cpu(latest_node.gid)); inode->i_size = je32_to_cpu(latest_node.isize); inode->i_atime = ITIME(je32_to_cpu(latest_node.atime)); inode->i_mtime = ITIME(je32_to_cpu(latest_node.mtime)); inode->i_ctime = ITIME(je32_to_cpu(latest_node.ctime));

    set_nlink(inode, f->inocache->pino_nlink);

    inode->i_blocks = (inode->i_size + 511) >> 9;

    Comment 5
    1. chenjin_zhong, Thu, 28 Oct 2021 14:42:27 GMT
    2. status: changed from closed to reopened
    3. resolution: invalid deleted
    Comment 6
    1. Sebastian Huber, Thu, 28 Oct 2021 14:45:13 GMT
    2. status: changed from reopened to closed
    3. resolution: set to invalid

    Yes, the f->sem is an empty structure, it is not initialized, it is not used, locked or whatever in RTEMS. This is intentional and not a bug. I repeat: __The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance.__


    4538 - mutex is not initilaized in jffs2_read_inode

    Link https://devel.rtems.org/ticket/4538
    Id 4538
    Reporter chenjin_zhong
    Created 27 October 2021 15:13:14
    Modified 28 October 2021 18:26:10
    Owner  
    Type defect
    Component fs/jffs2
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    HI, I have found when call jffs2_read_inode to read inode. the f->sem is not initiliazed and locked, but it is be unlocked. The peice of source code is as follows:
    static int jffs2_read_inode (struct _inode *inode)
    {

    struct jffs2_inode_info *f;
    struct jffs2_sb_info *c;
    struct jffs2_raw_inode latest_node;
    int ret;

    D1(printk(KERN_DEBUG "jffs2_read_inode(): inode->i_ino == %lu\n", inode->i_ino));

    f = JFFS2_INODE_INFO(inode);
    c = JFFS2_SB_INFO(inode->i_sb);

    jffs2_init_inode_info(f);
    ret = jffs2_do_read_inode(c, f, inode->i_ino, &latest_node);

    if (ret) {

    __mutex_unlock(&f->sem);__ return ret;

    }

    inode->i_mode = jemode_to_cpu(latest_node.mode);
    inode->i_uid = je16_to_cpu(latest_node.uid);
    inode->i_gid = je16_to_cpu(latest_node.gid);
    inode->i_size = je32_to_cpu(latest_node.isize);
    inode->i_atime = je32_to_cpu(latest_node.atime);
    inode->i_mtime = je32_to_cpu(latest_node.mtime);
    inode->i_ctime = je32_to_cpu(latest_node.ctime);

    inode->i_nlink = f->inocache->pino_nlink; __mutex_unlock(&f->sem);

    __

    D1(printk(KERN_DEBUG "jffs2_read_inode() returning\n"));
    return 0;

    }

    Comment 1
    1. Sebastian Huber, Thu, 28 Oct 2021 05:20:50 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid
    4. component: changed from admin to fs/jaffs2

    Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance:

    static void rtems_jffs2_do_lock(struct super_block *sb)
    {
            rtems_recursive_mutex_lock(&sb->s_mutex);
    }
    static void rtems_jffs2_do_unlock(struct super_block *sb)
    {
            rtems_recursive_mutex_unlock(&sb->s_mutex);
    } 
    Comment 2
    1. chenjin_zhong, Thu, 28 Oct 2021 14:40:25 GMT
    2. status: changed from closed to reopened
    3. resolution: invalid deleted

    Replying to Sebastian Huber:

    Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance:

    static void rtems_jffs2_do_lock(struct super_block *sb)
    {
            rtems_recursive_mutex_lock(&sb->s_mutex);
    }
    static void rtems_jffs2_do_unlock(struct super_block *sb)
    {
            rtems_recursive_mutex_unlock(&sb->s_mutex);
    } 

    I have compared it with Linux JFFS2. The peice of source code in Linux is as follows,As shown in black-body section, the f->sem is not be initialized and locked in RTEMS.

    struct jffs2_sb_info *c;
    struct jffs2_raw_inode latest_node;
    union jffs2_device_node jdev;
    struct inode *inode;
    dev_t rdev = 0;
    int ret;
    jffs2_dbg(1, "%s(): ino == %lu\n", func, ino);
    inode = iget_locked(sb, ino);
    if (!inode)
    return ERR_PTR(-ENOMEM);
    if (!(inode->i_state & I_NEW))
    return inode;
    f = JFFS2_INODE_INFO(inode);
    c = JFFS2_SB_INFO(inode->i_sb);
    jffs2_init_inode_info(f);
    mutex_lock(&f->sem);
    ret = jffs2_do_read_inode(c, f, inode->i_ino, &latest_node);
    if (ret)
    goto error;
    inode->i_mode = jemode_to_cpu(latest_node.mode);
    i_uid_write(inode, je16_to_cpu(latest_node.uid));
    i_gid_write(inode, je16_to_cpu(latest_node.gid));
    inode->i_size = je32_to_cpu(latest_node.isize);
    inode->i_atime = ITIME(je32_to_cpu(latest_node.atime));
    inode->i_mtime = ITIME(je32_to_cpu(latest_node.mtime));
    inode->i_ctime = ITIME(je32_to_cpu(latest_node.ctime));
    set_nlink(inode, f->inocache->pino_nlink);
    inode->i_blocks = (inode->i_size + 511) >> 9; 
    Comment 3
    1. Sebastian Huber, Thu, 28 Oct 2021 14:43:37 GMT
    2. status: changed from reopened to closed
    3. resolution: set to invalid

    Yes, the f->sem is an empty structure, it is not initialized, it is not used, locked or whatever in RTEMS. This is intentional and not a bug. I repeat: __The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance.__

    Comment 4
    1. chenjin_zhong, Thu, 28 Oct 2021 15:05:51 GMT

    Replying to Sebastian Huber:

    Yes, the f->sem is an empty structure, it is not initialized, it is not used, locked or whatever in RTEMS. This is intentional and not a bug. I repeat: __The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance.__

    Thank you! I got it. but we Suppose that a GC thread or other thread/task and main task calls jffs2_do_readinode simultaneous. a global lock for each JFFS2 instance can't work.

    Comment 5
    1. chenjin_zhong, Thu, 28 Oct 2021 15:07:51 GMT
    2. status: changed from closed to reopened
    3. resolution: invalid deleted
    Comment 6
    1. Sebastian Huber, Thu, 28 Oct 2021 18:26:10 GMT
    2. status: changed from reopened to closed
    3. resolution: set to invalid

    Replying to chenjin_zhong:

    Replying to Sebastian Huber:

    Yes, the f->sem is an empty structure, it is not initialized, it is not used, locked or whatever in RTEMS. This is intentional and not a bug. I repeat: __The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance.__

    Thank you! I got it. but we Suppose that a GC thread or other thread/task and main task calls jffs2_do_readinode simultaneous. a global lock for each JFFS2 instance can't work.

    It is not a high performance approach, but it works. See testsuites/fstests/fsjffs2gc01/init.c.


    4539 - rtems_filesystem_table compile

    Link https://devel.rtems.org/ticket/4539
    Id 4539
    Reporter chenjin_zhong
    Created 29 October 2021 06:27:19
    Modified 10 November 2022 00:42:49
    Owner  
    Type defect
    Component admin
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Hi, when the macro __ CONFIGURE_APPLICATION_DISABLE_FILESYSTEM__ is defined, rtems_filesystem_table is undefined during linking process.

    Comment 1
    1. Joel Sherrill, Fri, 29 Oct 2021 13:34:40 GMT

    Do you have a simple test case to let us see what is happening for you? There are 6 tests in the RTEMS Test Suite which use CONFIGURE_APPLICATION_DISABLE_FILESYSTEM so I suspect you have used something which implicitly requires a file system. Perhaps your application needs a minimal file system for device nodes.

    Comment 2
    1. chenjin_zhong, Tue, 02 Nov 2021 06:38:37 GMT

    I just compile sp01 with __CONFIGURE_APPLICATION_DISABLE_FILESYSTEM__. I rechecked the source code in RTEMS5.1. I found that __rtems_filesystem_table__ is only be defined in confdefs/libio.h. the global variable __rtems_filesystem_table__ is used by __rtems_filesystem_iterate__ in libcsupport/src/mount-mgr.c. Therefore, the undefined error may bu caused by __CONFIGURE_APPLICATION_DISABLE_FILESYSTEM__.

    Comment 3
    1. Chris Johns, Thu, 10 Nov 2022 00:42:49 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    If you have referenced a function that pulls in the file system this will happen.


    4541 - rtems_jffs2_rmnod function problem

    Link https://devel.rtems.org/ticket/4541
    Id 4541
    Reporter chenjin_zhong
    Created 1 November 2021 14:54:19
    Modified 12 November 2021 13:50:17
    Owner  
    Type enhancement
    Component fs/jffs2
    Status closed
    Resolution worksforme
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Hi, the dir_i->i_mode must be S_IFDIR in this situation.therefore, I want to know when the dir_i->i_mode is S_IFREG? this function can it be optimized? the code is listed below.

    static int rtems_jffs2_rmnod(

    const rtems_filesystem_location_info_t *parentloc,
    const rtems_filesystem_location_info_t *loc)

    {

    struct _inode *dir_i =
    rtems_jffs2_get_inode_by_location(parentloc);
    struct _inode *entry_i = rtems_jffs2_get_inode_by_location(loc);
    char *name;
    size_t namelen;
    int eno = rtems_jffs2_cache_fd_name(entry_i, &name, &namelen);
    if (eno == 0) {

    switch (dir_i->i_mode & S_IFMT) {

    __case S_IFDIR:__

    eno = -jffs2_rmdir(dir_i, entry_i, name,

    namelen);

    break;

    case S_IFREG:

    eno = -jffs2_unlink(dir_i, entry_i,

    name,namelen);

    break;

    default:

    eno = EINVAL;
    break;

    }

    }

    return rtems_jffs2_eno_to_rv_and_errno(eno);

    }

    Comment 1
    1. Sebastian Huber, Fri, 12 Nov 2021 13:49:58 GMT
    2. status: changed from new to closed
    3. resolution: set to worksforme

    The rmnod_h file system operation is used by unlink() and rmdir().

    Comment 2
    1. Sebastian Huber, Fri, 12 Nov 2021 13:50:17 GMT
    2. component: changed from admin to fs/jaffs2

    4553 - Adapt improved mailer.py for rtems-tools 5 branch

    Link https://devel.rtems.org/ticket/4553
    Id 4553
    Reporter Ryan Long
    Created 1 December 2021 16:23:33
    Modified 16 December 2021 21:27:01
    Owner Alex White <alex.white@…>
    Type defect
    Component tool
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Adapted the patch applied to master to fix mail support for rtems-tools so that it works with the 5 branch.

    Comment 1
    1. Ryan Long, Wed, 01 Dec 2021 16:27:41 GMT
    2. summary: changed from Adapt improved mailer.py to Adapt improved mailer.py for rtems-tools
    Comment 2
    1. Ryan Long, Wed, 01 Dec 2021 16:36:11 GMT
    2. summary: changed from Adapt improved mailer.py for rtems-tools to Adapt improved mailer.py for rtems-tools 5 branch
    Comment 3
    1. Alex White, Thu, 16 Dec 2021 21:26:51 GMT

    In 56779ec/rtems-tools:

    rtemstoolkit/mailer.py: Return full smtp-host arg value This fixes mail.smtp_host() so that it returns the full argument value rather than just the second character. Updates #4553
    Comment 4
    1. Alex White, Thu, 16 Dec 2021 21:26:53 GMT

    In 6759c3c/rtems-tools:

    rtemstoolkit: Filter mail options from log output This filters mail-related options out before logging the command line options. This is needed to prevent leaking potentially sensitive information via logs and emails. Updates #4553
    Comment 5
    1. Alex White, Thu, 16 Dec 2021 21:26:56 GMT

    In a7efe4a/rtems-tools:

    rtemstoolkit/mailer.py: Add SMTP login options This adds more options so that the user can authenticate with the SMTP server. Updates #4553
    Comment 6
    1. Alex White, Thu, 16 Dec 2021 21:26:59 GMT

    In f7f1a3e/rtems-tools:

    rtemstoolkit/mailer.py: Add --use-gitconfig option This adds the option to pull mail-related configuration values from the user's git configuration. Updates #4553
    Comment 7
    1. Alex White, Thu, 16 Dec 2021 21:27:01 GMT
    2. owner: set to Alex White <alex.white@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In bdd785a/rtems-tools:

    rtems-bsp-builder: Fix mail support This fixes a problem with mailer options support that occurred because check.py uses argparse.ArgumentParser? instead of tester.rt.options. Closes #4553

    4554 - Adapt improved mailer.py for RSB 5 branch

    Link https://devel.rtems.org/ticket/4554
    Id 4554
    Reporter Ryan Long
    Created 1 December 2021 16:36:03
    Modified 16 December 2021 21:36:06
    Owner Alex White <alex.white@…>
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    Adapted the patch applied to master to fix mail support for the RSB so that it works with the 5 branch.

    Comment 1
    1. Alex White, Thu, 16 Dec 2021 21:36:06 GMT
    2. owner: set to Alex White <alex.white@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 6225ead/rtems-source-builder:

    sb: Merge mailer changes from rtems-tools This adds the improved mailer.py script from rtems-tools. Closes #4554

    4561 - Fix build issue with qemu4 on Ubuntu

    Link https://devel.rtems.org/ticket/4561
    Id 4561
    Reporter Ryan Long
    Created 3 December 2021 18:47:42
    Modified 15 December 2021 14:02:09
    Owner Ryan Long <ryan.long@…>
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The following issue occurs when trying to build qemu4 on Ubuntu.

    /usr/bin/ld: linux-user/syscall.o: in function `do_syscall1':
    /mnt/sdb/rtems-work/rtems-source-builder/bare/build/qemu-4.1.0-x86_64-linux-gnu-1/qemu-4.1.0/linux-user/syscall.c:7660: undefined reference to `stime'
    Comment 1
    1. Ryan Long, Fri, 03 Dec 2021 18:54:45 GMT

    This issue came up in the ROS port. It's been fixed, but we need to add in the patch. The issue and patch can be found here ​https://github.com/micro-ROS/micro_ros_setup/issues/397.

    Comment 2
    1. Ryan Long, Fri, 03 Dec 2021 19:09:18 GMT
    2. version: changed from 6 to 5
    3. milestone: changed from 6.1 to 5.1
    Comment 3
    1. Ryan Long, Wed, 15 Dec 2021 14:02:09 GMT
    2. owner: set to Ryan Long <ryan.long@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 2e98eec/rtems-source-builder:

    devel/qemu4: Add patches so qemu4 can build These patches add patches that fix the build issues preventing qemu4 from building on Ubuntu. Closes #4561

    4562 - Bump dtc on rtems5 to match rtems6

    Link https://devel.rtems.org/ticket/4562
    Id 4562
    Reporter Ryan Long
    Created 3 December 2021 18:52:37
    Modified 15 December 2021 14:02:07
    Owner Ryan Long <ryan.long@…>
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    The hash for dtc needs to be bumped to fix some build errors on rtems5.

    Comment 1
    1. Ryan Long, Wed, 15 Dec 2021 14:02:07 GMT
    2. owner: set to Ryan Long <ryan.long@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 612c4d0/rtems-source-builder:

    devel/dtc: Bump dtc hash to match rtems6 Bumped dtc version to get rid of build failure for dtc. Closes #4562

    4598 - about MIPS architecture support

    Link https://devel.rtems.org/ticket/4598
    Id 4598
    Reporter ostyche
    Created 11 February 2022 03:22:28
    Modified 10 November 2022 00:58:15
    Owner  
    Type defect
    Component admin
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords loongson3a1k
    Cc  
    Blocking  
    Blocked by  

    Description

    Added support for the board support package of Loongson Technology Corporation company's products-LS3A1000 processor.The relevant file path is \c\src\lib\libbsp\mips\loongson3a\

    The files involved in the question were uploaded by git user ostyche who created a branch at 10:55 am on February 11, 2022

    Comment 1
    1. Gedare Bloom, Fri, 11 Feb 2022 15:39:14 GMT

    Hello ostyche, is there an attachment or patch submission to the devel mailing list to go with this ticket? It sounds like you have a new MIPS BSP?

    Comment 2
    1. Chris Johns, Thu, 10 Nov 2022 00:58:15 GMT
    2. status: changed from new to closed
    3. version: changed from 4.11 to 5
    4. resolution: set to invalid

    Please reopen when being worked on or a fix is available.


    4599 - support pmu under MIPS platform

    Link https://devel.rtems.org/ticket/4599
    Id 4599
    Reporter ostyche
    Created 11 February 2022 03:25:59
    Modified 10 November 2022 00:58:51
    Owner  
    Type defect
    Component arch/mips
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords pmu
    Cc  
    Blocking  
    Blocked by  

    Description

    Added support for PMU(Performance Monitoring Unit) under MIPS platform.The relevant file path is \c\src\lib\libbsp\mips\ shared\pmu
    The files involved in the question were uploaded by git user ostyche who created a branch at 10:55 am on February 11, 2022

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 00:58:51 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid
    4. version: changed from 4.11 to 5
    5. component: changed from admin to arch/mips

    Please reopen when being worked on or a fix is available.


    4600 - non-alignment exception

    Link https://devel.rtems.org/ticket/4600
    Id 4600
    Reporter ostyche
    Created 11 February 2022 03:30:07
    Modified 10 November 2022 00:59:32
    Owner  
    Type defect
    Component arch/mips
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords non-alignment
    Cc  
    Blocking  
    Blocked by  

    Description

    We improved the exception handling mechanism under the MIPS architecture by handling non-alignment exception appropriately.The relevant file paths are \c\src\lib\libbsp\mips\shared\irq\vectorexceptions.c, \c\src\lib\libbsp\mips\shared\irq\exception.S

    The files involved in the question were uploaded by git user ostyche who created a branch at 10:55 am on February 11, 2022

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 00:59:32 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid
    4. version: changed from 4.11 to 5
    5. component: changed from admin to arch/mips

    Please reopen when being worked on or a fix is available.


    4601 - support for 64KB clusters DOSFS

    Link https://devel.rtems.org/ticket/4601
    Id 4601
    Reporter ostyche
    Created 11 February 2022 03:32:22
    Modified 10 November 2022 01:00:50
    Owner  
    Type defect
    Component fs/fat
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords dosfs
    Cc  
    Blocking  
    Blocked by  

    Description

    Added support for 64KB clusters in DOSFS.The relevant file path is \cpukit\libfs\src\dosfs\msdos_format.c
    The files involved in the question were uploaded by git user ostyche who created a branch at 10:55 am on February 11, 2022

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 01:00:50 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid
    4. version: changed from 4.11 to 5
    5. component: changed from admin to fs/fat

    Please reopen when being worked on or a fix is available.

    We do not know where the sources are you refer to.


    4602 - support commands such as rename

    Link https://devel.rtems.org/ticket/4602
    Id 4602
    Reporter ostyche
    Created 11 February 2022 03:37:19
    Modified 10 November 2022 01:01:51
    Owner  
    Type defect
    Component network/legacy
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords rename、ftp
    Cc  
    Blocking  
    Blocked by  

    Description

    We modify the FTP server code to support commands such as rename.The relevant file paths are \cpukit\ftpd\ftpd.c
    The files involved in the question were uploaded by git user ostyche who created a branch at 10:55 am on February 11, 2022

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 01:01:51 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid
    4. version: changed from 4.11 to 5
    5. component: changed from admin to network/legacy

    Please reopen when being worked on or a fix is available.


    4603 - Added support for Intel I210

    Link https://devel.rtems.org/ticket/4603
    Id 4603
    Reporter ostyche
    Created 11 February 2022 03:39:20
    Modified 10 November 2022 01:02:35
    Owner  
    Type defect
    Component network/legacy
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords I210
    Cc  
    Blocking  
    Blocked by  

    Description

    Added support for Intel I210 NIC(Network Interface Card) drives.The relevant file path is \cpukit\I210\
    The files involved in the question were uploaded by git user ostyche who created a branch at 10:55 am on February 11, 2022

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 01:02:35 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid
    4. version: changed from 4.11 to 5
    5. component: changed from admin to network/legacy

    Please reopen when being worked on or a fix is available.


    4604 - Telnet client protocols

    Link https://devel.rtems.org/ticket/4604
    Id 4604
    Reporter ostyche
    Created 11 February 2022 03:41:03
    Modified 10 November 2022 01:03:14
    Owner  
    Type defect
    Component admin
    Status closed
    Resolution invalid
    Version 4.11
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords Telnet
    Cc  
    Blocking  
    Blocked by  

    Description

    RTEMS doesn’t support Telnet client protocols

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 01:03:14 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    It does in the legacy and libbsd stacks.


    4605 - TFTP client protocols

    Link https://devel.rtems.org/ticket/4605
    Id 4605
    Reporter ostyche
    Created 11 February 2022 03:42:18
    Modified 10 November 2022 01:03:57
    Owner  
    Type defect
    Component network/legacy
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords TFTP
    Cc  
    Blocking  
    Blocked by  

    Description

    RTEMS doesn’t support TFTP client protocols.

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 01:03:57 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid
    4. version: changed from 4.11 to 5
    5. component: changed from admin to network/legacy

    It does support TFTP.


    4606 - TFTP server protocols

    Link https://devel.rtems.org/ticket/4606
    Id 4606
    Reporter ostyche
    Created 11 February 2022 03:43:22
    Modified 10 November 2022 01:04:55
    Owner  
    Type defect
    Component network/legacy
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords TFTP
    Cc  
    Blocking  
    Blocked by  

    Description

    RTEMS doesn’t support TFTP server protocols.

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 01:04:22 GMT
    2. version: changed from 4.11 to 5
    3. component: changed from admin to network/legacy

    Please reopen when being worked on or a fix is available.

    Comment 2
    1. Chris Johns, Thu, 10 Nov 2022 01:04:55 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid

    4608 - Added support for Intel 82580

    Link https://devel.rtems.org/ticket/4608
    Id 4608
    Reporter ostyche
    Created 11 February 2022 03:47:20
    Modified 10 November 2022 01:05:29
    Owner  
    Type defect
    Component network/legacy
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords 82580
    Cc  
    Blocking  
    Blocked by  

    Description

    Added support for Intel 82580 NIC drives.The relevant file path is \cpukit\82580\
    The files involved in the question were uploaded by git user ostyche who created a branch at 10:55 am on February 11, 2022

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 01:05:29 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid
    4. version: changed from 4.11 to 5
    5. component: changed from admin to network/legacy

    Please reopen when being worked on or a fix is available.


    4609 - support for DMA access

    Link https://devel.rtems.org/ticket/4609
    Id 4609
    Reporter ostyche
    Created 11 February 2022 03:49:27
    Modified 10 November 2022 01:06:04
    Owner  
    Type defect
    Component lib/block
    Status closed
    Resolution invalid
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords IDE
    Cc  
    Blocking  
    Blocked by  

    Description

    we modify the IDE hard disk drive architecture, improve the IDE hard disk drive function, and add support for DMA access.The relevant file paths are \c\src\lib\libbsp\i386\pc386\ide\idecfg.c, \c\src\libchip\ide\
    The files involved in the question were uploaded by git user ostyche who created a branch at 10:55 am on February 11, 2022

    Comment 1
    1. Chris Johns, Thu, 10 Nov 2022 01:06:04 GMT
    2. status: changed from new to closed
    3. resolution: set to invalid
    4. version: changed from 4.11 to 5
    5. component: changed from admin to lib/block

    Please reopen when being worked on or a fix is available.


    4660 - Spike failing to build with RSB 5 on Ubuntu 21.04

    Link https://devel.rtems.org/ticket/4660
    Id 4660
    Reporter Ryan Long
    Created 25 May 2022 18:13:09
    Modified 2 June 2022 15:08:11
    Owner Ryan Long <ryan.long@…>
    Type defect
    Component tool/rsb
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords  
    Cc  
    Blocking  
    Blocked by  

    Description

    With the current hash of the RSB, I'm getting the following error on Ubuntu.

    ./fesvr/dtm.cc: In member function 'uint32_t dtm_t::get_xlen()':
    ./fesvr/dtm.cc:488:16: error: 'runtime_error' is not a member of 'std'
    488 | throw std::runtime_error("FESVR DTM Does not support 128-bit");
    | ^~~~~~~~~~~~~
    ./fesvr/dtm.cc:505:14: error: 'runtime_error' is not a member of 'std'
    505 | throw std::runtime_error("FESVR DTM can't determine XLEN. Aborting");
    | ^~~~~~~~~~~~~
    ./fesvr/dtm.cc:506:1: warning: control reaches end of non-void function [-Wreturn-type]
    506 | }
    | ^
    make: *** [Makefile:347: dtm.o] Error 1
    make: *** Waiting for unfinished jobs....
    shell cmd failed: /bin/sh -ex /home/tester/rtems-cron-5/rtems-source-builder/bare/build/spike-66b44bfbedda562a32e4a2cd0716afbf731b69cd-x86_64-linux-gnu-1/do-build
    Comment 1
    1. Ryan Long, Thu, 02 Jun 2022 15:08:11 GMT
    2. owner: set to Ryan Long <ryan.long@…>
    3. status: changed from new to closed
    4. resolution: set to fixed

    In 7f6cfad/rtems-source-builder:

    devel/spike-1.1.0: bump hash Bump the hash of spike to match the 1.1.0 release Closes #4660

    4692 - Python 3.8 introduces new warning about using operator "is" with a literal

    Link https://devel.rtems.org/ticket/4692
    Id 4692
    Reporter Konrad Schwarz
    Created 1 August 2022 15:50:29
    Modified 12 August 2022 14:18:53
    Owner Chris Johns
    Type enhancement
    Component test
    Status closed
    Resolution fixed
    Version 5
    Milestone 5.1
    Priority normal
    Severity normal
    Keywords Python 3.8
    Cc  
    Blocking  
    Blocked by  

    Description

    Python 3.8 introduces a new warning: using the "is" operator as an equality operation is incorrect (although it works by chance on CPython). To compare for equality, the "==" operator must be used.

    Warnings popped up when I called rtems-tester.

    Attached please find patches for this case.

    Attachments:

    1 Konrad Schwarz, Mon, 01 Aug 2022 15:59:00 GMT
      attach: set to 0001-Python-3.8-warning-about-is-vs-in-comparisons-of-lit.patch
     
    Comment 1
    1. Joel Sherrill, Mon, 01 Aug 2022 15:51:56 GMT
    2. owner: changed from joel@… to Chris Johns
    3. status: changed from new to assigned
    Comment 2
    1. Joel Sherrill, Mon, 01 Aug 2022 15:52:39 GMT

    Konrad, there are no patches attached (yet I hope).

    And thanks in advance for the patches.

    Comment 3
    1. Konrad Schwarz, Fri, 12 Aug 2022 14:18:53 GMT
    2. status: changed from assigned to closed
    3. resolution: set to fixed

    In 04d6aa3/rtems-tools:

    Python 3.8 warning about "is" vs "==" in comparisons of literals Signed-off-by: Konrad Schwarz Closes #4692