CTU CAN test doesn't prompt to the SHLL [/] in RTEMS 7

Architecture i386
1

Hello everyone,

I was able to set up RTEMS v7 on my PC and follow the instructions up to running the ./qemu-i386-pc686-2x-ctu-pci-run in rtems-canfd.

First, I ran the code in an RTEMS setup in an Ubuntu KVM and got the following results:

$ ./qemu-i386-pc686-2x-ctu-pci-run
qemu-system-x86_64: warning: host doesn’t support requested feature: CPUID.80000001H:ECX.svm [bit 2]

Then I thought it is because of the nested virtualization as I am running the qemu in a KVM

My next step was to set up RTEMS on my physical computer and redo the same procedure.

Then again, I got the same results as follows:

Screenshot from 2026-03-18 18-44-04
Screenshot from 2026-03-18 18-44-041098×824 226 KB

Afterwards, I realised this is related to the SVM option in QEMU, which is available for the AMD CPUs. My CPU is an Intel Core i5 CPU.

My next step was to disable the SVM option in the qemu-i386-pc686-2x-ctu-pci-run script. I used both

$QEMU -enable-kvm -kernel $APP_BINARY
-cpu host,svm=off
-nographic
-netdev user,id=n1 -device i82557b,netdev=n1
-append “–console=/dev/com1”
-object can-bus,id=canbus0-bus
-object can-host-socketcan,if=can0,canbus=canbus0-bus,id=canbus0-socketcan
-device kvaser_pci,canbus=canbus0-bus
-device ctucan_pci,canbus0=canbus0-bus,canbus1=canbus0-bus

and

$QEMU -enable-kvm -kernel $APP_BINARY
-cpu host,-svm
-nographic
-netdev user,id=n1 -device i82557b,netdev=n1
-append “–console=/dev/com1”
-object can-bus,id=canbus0-bus
-object can-host-socketcan,if=can0,canbus=canbus0-bus,id=canbus0-socketcan
-device kvaser_pci,canbus=canbus0-bus
-device ctucan_pci,canbus0=canbus0-bus,canbus1=canbus0-bus

within the script. Then the error disappeared. But the terminal never came to the SHLL [/] # terminal as mentioned in here to test the CAN functionality. It just stuck as follows:

Screenshot from 2026-03-18 18-47-37
Screenshot from 2026-03-18 18-47-371098×751 80.9 KB

Even though I tried pressing enter, nothing happened.

As my final step I tried the nographic option too.

$QEMU -enable-kvm -kernel $APP_BINARY
-cpu host,svm=off
-nographic
-netdev user,id=n1 -device i82557b,netdev=n1
-append “–console=/dev/com1”
-object can-bus,id=canbus0-bus
-object can-host-socketcan,if=can0,canbus=canbus0-bus,id=canbus0-socketcan
-device kvaser_pci,canbus=canbus0-bus
-device ctucan_pci,canbus0=canbus0-bus,canbus1=canbus0-bus

Still the same results as follows.

Screenshot from 2026-03-18 19-18-53
Screenshot from 2026-03-18 19-18-53812×444 72.3 KB

When I kept the system idle for sometime I received the following error message in the terminal.

qemu_system-x86_64: Slirp: Failed to send packet, ret: -1

I kindly appreciate any of your insights or guidance to move forward from this point. Thank you in advance.

Regards,
Lahiru

2

Are you able to use the shell example from testsuites/samples? I would start by ensuring that is working.

1 Like
3

The symptom of the problem is reported

pthread_setspecific(shell_current_env_key): set

The RTEMS shell (in the current versions) requires pthread_getspecific support which is dependent on the POSIX API feature compiled in.

So after you obtain default RTEMS configuration for i386_pc686 BSP

$RTEMS_DIR/waf bspdefaults --rtems-bsps=i386/pc686 -t "$RTEMS_DIR" -o "$MY_DIR" --prefix "/opt/rtems/7" >config.ini

You need to edit config.ini and enable RTEMS_POSIX_API by setting True, the whole line

# Enable support for POSIX signals, sporadic server and lio_listio()
RTEMS_POSIX_API = True

Then continue by regular build steps

$RTEMS_DIR/waf configure -t "$RTEMS_DIR" -o "$MY_DIR" --rtems-config "$MY_DIR/config.ini" --prefix "/opt/rtems/7" || exit 1
$RTEMS_DIR/waf || exit 1
$RTEMS_DIR/waf install || exit 1

Replace RTEMS_DIR and MY_DIR by appropriate paths.

2 Likes
4

Thank you very much for the guidance. I was able to successfully run the tests mentioned in the RTEMS-CANFD in both the KVM-based Ubuntu VM and my physical computer.

Screenshot from 2026-03-21 17-40-31
Screenshot from 2026-03-21 17-40-311516×895 323 KB

1 Like
5

Hello,

I have one more update regarding the config.ini generation using the
$RTEMS_DIR/waf bspdefaults --rtems-bsps=i386/pc686 -t "$RTEMS_DIR" -o "$MY_DIR" --prefix "/opt/rtems/7" >config.ini command.
The
SECTION_FLAGS appeared in 3 places, and it caused the waf configuration to fail. Therefore, I had to comment out the last 2 SECTION_FLAGS

# Section layout flags required for correct linker garbage collection.
# These flags are separated from OPTIMIZATION_FLAGS so that users may
# override optimization settings without removing the required section
# flags. Users may override these flags through the SECTION_FLAGS
# build option if different section handling behaviour is required.
SECTION_FLAGS = -ffunction-sections -fdata-sections
# Optimization flags passed to C and C++ compilers for the BSP.
BSP_OPTIMIZATION_FLAGS = ${SECTION_FLAGS} ${OPTIMIZATION_FLAGS}
# Section layout flags required for correct linker garbage collection.
# These flags are separated from OPTIMIZATION_FLAGS so that users may
# override optimization settings without removing the required section
# flags. Users may override these flags through the SECTION_FLAGS
# build option if different section handling behaviour is required.
SECTION_FLAGS = -ffunction-sections -fdata-sections
# Optimization flags passed to C and C++ compilers for the CPU kit.
CPUKIT_OPTIMIZATION_FLAGS = ${SECTION_FLAGS} ${OPTIMIZATION_FLAGS}
# Section layout flags required for correct linker garbage collection.
# These flags are separated from OPTIMIZATION_FLAGS so that users may
# override optimization settings without removing the required section
# flags. Users may override these flags through the SECTION_FLAGS
# build option if different section handling behaviour is required.
SECTION_FLAGS = -ffunction-sections -fdata-sections

Working on finding the root cause to generate it 3 times.

Thanks

6

I have noticed the problem today as well and opened issue

2 Likes