GSoC_2026: Introduction and Poof of work - Lahiru Gunathilake

[bllgg]

Hello everyone,

I am Lahiru Gunathilake. I am a research student at RMIT University in Melbourne. I am interested in contributing to the Message Queue Improvements and Fixes project.

At the moment, I am going through the linked items to have a better understanding.

Background
I work mainly on UNIX like operating systems, embedded systems and low-level software development. Most of my work is in C, with experience in Linux kernel modules development, debugging, device tree configuration, and system bring-up using Yocto.

Proof of work

• I set up the RTEMS 7 development environment and toolchain successfully in a virtual machine.

• My project prefix is $HOME/RTEMS/. Hope this is okay.

• I built and ran the Hello World example for the SPARC as described in the RTEMS documentation (screenshot is attached).
  

  

• After running the Hello world program, I created the patch file as follows (screenshot is attached).
  

  

Thanks.

[gedare]

Thanks. Your email address will be publicly available in the git repository after you submit MRs, so you should use one that you are satisfied with having out in public.

You can add yourself to tracking/2026 · main · RTEMS / Programs / Google Summer of Code · GitLab.

Please search here for any open topics related to your project interest, and if there aren’t any then you can start a new topic to discuss a project interest.

[bllgg]

Hi Gedare,
Thank you for letting me know. I will continue to use the current email.

[bllgg]

Hi @gedare,

While going through the projects, I changed my mind to contribute to the CAN stack improvement project. Therefore, I created a merge request to change the project in the tracking page MR.

Please let me know if there any other things to change such as the title of this discussion.

Thank you.

[gedare]

OK, you should be able to find an open topic or two related to this project idea.

[bllgg]

Dear @gedare, @michallenc and @ppisa,

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:

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:

Even though I tried pressing enter, nothing happened. I kindly appreciate any of your insights or guidance to move forward from this point. Thank you in advance.

[gedare]

I would suggest you create a new post that describes this issue.