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) 

Move to the first 4.12 milestone.

Milestone renamed

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.

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.

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

In 1822649/rtems:

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?

Please reopen if this is going to be worked on.

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.

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

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

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

There has been no feedback so lets consider it closed.

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.

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

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.

Sebastian has recommended avoiding this API.

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?

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.

Please reopen if this is to be worked on.

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.

Do you have a link?

Please repopen if this is to be worked on.

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

Please use the RISCV support in RTEMS 6.

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

Use master or RTEMS 6.

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.

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

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: 

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)

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.

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

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

In 7661402/rtems:

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 

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

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

In 20d8237/rtems:

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.

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.

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

Integrated in 7f47f2784138109b8363804c2aecd3d83231ab0f.

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()

In 6559511/rtems-docs:

In 5642fe5/rtems-docs:

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.

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

bspsmp.c is missing a licence header.

In 1f77518/rtems:

(The changeset message doesn't reference this ticket)

​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.

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 

In 18549295/rtems:

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.

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 

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

Please reopen when the bset is added.

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.

In 3d7da435/rtems:

In e71e271/rtems:

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. :)

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

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

In 7021c014/rtems:

See also:

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

Some areas were already fixed by #3057.

In 980cdb8/rtems:

In 3074eb0/rtems:

In 2497a46a/rtems:

Cloned from #4164.

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

In f84c4a5/rtems:

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.

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.

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

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

In 21ed8d11/rtems:

In 2a8f755/rtems:

Cloned from #4158:

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

In 1dbdf94e/rtems:

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

In dedc3e1d/rtems:

Cloned from #4223:

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

In 5ae7ec9/rtems:

Cloned from #4230:

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

In 5861e42/rtems:

In cc2a237/rtems:

In ef1ac8af/rtems:

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.

In 6d9843e/rtems:

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
----------------------------------------- 

In 388bd805/rtems:

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.

In 2f32370/rtems:

In 645dbc5/rtems:

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.

In 2f56b737/rtems:

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.

In 2f56b737/rtems:

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

In e621fd9/rtems-tools:

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

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

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.

In 3824960/rtems:

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:

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.

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.

GCC 10 defaults to -fno-common ...

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

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.

In d1bab98/rtems:

In 75fb7a0e/rtems:

In 96918af/rtems:

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

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

In a97a473/rtems:

In 1223f5e/rtems:

Select the new 1553 codec available specifically in GR740.

In 14fcf388/rtems:

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

In 8004ffb/rtems:

Minor fix, no need to add to 5.2 Changelog.

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.

In 84fb340/rtems:

Add the new AMBA PnP IDs of the new cores.

In 0ab993b/rtems:

Minor improvement, no need to add to 5.2 changelog.

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.

In da7cb87/rtems:

In 78b45cc5/rtems:

In 7db032cf/rtems:

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).

In e1062fae/rtems:

In c41e7ba/rtems:

In e180f281/rtems:

In 23cc5a6/rtems:

In c13205f/rtems:

Minor improvement, no need to add to 5.2 changelog.

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.

In 0ed294b6/rtems:

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.

In 81e4a15/rtems:

Is there the same assumption in RTEMS 4.8 too?

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

In d9d96f0/rtems:

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

In cb8379d/rtems: