Hi!
I would like to give some summary about the progress on my GSoC project (Porting Jailhouse into AGL). You can also read it with the links included on my GSoC project blog:
https://limoto.github.io/gsoc20-blog/2020/05/29/community-bonding-period.html
https://limoto.github.io/gsoc20-blog/2020/06/06/week1-building-and-getting-to-run.html
== Community Bonding Period (before the start)
During the community bonding period, I joined the AGL mailing list and introduced myself and my project. I also started to attend the regular Tuesday’s AGL Weekly Developer Calls and biweekly AGL Virtualization Expert Group calls.
During the calls with my mentor, we found out a new goal for the project. The goal is to make a real-time Jailhouse cell that will be given access to the CAN hardware peripheral. It will be able to reply to CAN messages that need a quick reply and pass the other to the Linux cell with AGL.
To implement that, I have got two Raspberry Pi 4s (4 GB and 2 GB version) and two pieces of the Waveshare CAN HAT. One of them will be used to run the AGL system with Jailhouse and one will be used as the counterpart on the CAN bus.
During the Virtualization EG call, I was asked if I was thinking about using virtio. It is a specification that allows virtual machines access to simplified virtual devices, so there is no need to emulate more complicated real hardware peripherals. I haven’t thought about that before, but it would make sense to use it. There would be a virtual CAN link between the real-time cell and the AGL cell. I was linked to a paper about using virtio on RTEMS real-time operating system. It implements networking over virtio, so it might serve as an example for implementing CAN bus. It seems that there is no specification for CAN over virtio, but there is some code of a Linux driver for virtio-can on GitHub.
Another thing to consider is the hardware support in RTEMS. There is a BSP for Raspberry Pi, but according to the comments in source code, it’s made for the original Raspberry Pi and Raspberry Pi 2. So I will have to try in on a RPi 4 and eventually port it. There are already drivers for SPI and UART in the RPi RTEMS BSP, but I haven’t found any RTEMS code for the MCP2515 controller used on the CAN HAT. So I will have to implement that.
There was a GSoC project about running RTEMS in Jailhouse, but I’m not sure how much usable is the outcome. So that is another thing to dive into.
So, the goal for next week is to compile and run AGL and Jailhouse both in QEMU and on the Raspberry. Then I will continue integrating them together.
== Week 1: Building and getting to run
During the first week, I planned to build and run both AGL and Jailhouse in QEMU and on the Raspberry Pi. I started with building the AGL master on my laptop, but I’ve run into some problems with the libxmlsec1 package trying to use my system headers instead of the ones from the AGL tree. I was recommended to use some supported distribution (e.g. Debian stable), as I’m using Arch Linux on my laptop and it’s not supported by Yocto Project. After running the build on a Debian machine, I was able to build it for qemu-x86_64 target. Then I wanted to build it for the Raspberry, so I followed the documentation and ran into problems with the libomxil package, so I haven’t included it and it worked well.
But I’ve got another problem when running the qemu-x86_64 image with QEMU. Using the QEMU command from the documentation, the system was not able to boot. It failed to mount the /boot partition and gave a rescue shell on the console. While I was investigating the problem, I noticed that someone just asked about the same problem on the mailing list. So, later I proposed my workarounds. But even after that, I was still not able to boot into the graphical interface. So I tried it on the Raspberry and it worked well. After playing with the QEMU command-line arguments, I tried to run the image using the runqemu script and the graphical interface was finally working. Despite this, I was still not able to boot into the graphical interface using the vmdk image. After using QEMU command-line arguments from the runqemu script, now it changes the resolution when it boots, but the screen remains black.
Then I moved onto Jailhouse. I have built Jailhouse images from the jailhouse-images GitHub repository for both QEMU-x86_64 and Raspberry Pi 4. They both worked well, so I’ve got some hands-on experience with Jailhouse and the example inmates provided. The Raspberry Pi 4 image is made for the 1 GiB RAM variant of the Raspberry, but it works on the 4 GiB variant as well. It just shrinks the memory visible to the system to 1 GiB after enabling Jailhouse.
Now, the plan is to make a Yocto recipe for building Jailhouse into AGL. I’m also trying to include my findings into the AGL documentation as I go.
Jakub
I would like to give some summary about the progress on my GSoC project (Porting Jailhouse into AGL). You can also read it with the links included on my GSoC project blog:
https://limoto.github.io/gsoc20-blog/2020/05/29/community-bonding-period.html
https://limoto.github.io/gsoc20-blog/2020/06/06/week1-building-and-getting-to-run.html
== Community Bonding Period (before the start)
During the community bonding period, I joined the AGL mailing list and introduced myself and my project. I also started to attend the regular Tuesday’s AGL Weekly Developer Calls and biweekly AGL Virtualization Expert Group calls.
During the calls with my mentor, we found out a new goal for the project. The goal is to make a real-time Jailhouse cell that will be given access to the CAN hardware peripheral. It will be able to reply to CAN messages that need a quick reply and pass the other to the Linux cell with AGL.
To implement that, I have got two Raspberry Pi 4s (4 GB and 2 GB version) and two pieces of the Waveshare CAN HAT. One of them will be used to run the AGL system with Jailhouse and one will be used as the counterpart on the CAN bus.
During the Virtualization EG call, I was asked if I was thinking about using virtio. It is a specification that allows virtual machines access to simplified virtual devices, so there is no need to emulate more complicated real hardware peripherals. I haven’t thought about that before, but it would make sense to use it. There would be a virtual CAN link between the real-time cell and the AGL cell. I was linked to a paper about using virtio on RTEMS real-time operating system. It implements networking over virtio, so it might serve as an example for implementing CAN bus. It seems that there is no specification for CAN over virtio, but there is some code of a Linux driver for virtio-can on GitHub.
Another thing to consider is the hardware support in RTEMS. There is a BSP for Raspberry Pi, but according to the comments in source code, it’s made for the original Raspberry Pi and Raspberry Pi 2. So I will have to try in on a RPi 4 and eventually port it. There are already drivers for SPI and UART in the RPi RTEMS BSP, but I haven’t found any RTEMS code for the MCP2515 controller used on the CAN HAT. So I will have to implement that.
There was a GSoC project about running RTEMS in Jailhouse, but I’m not sure how much usable is the outcome. So that is another thing to dive into.
So, the goal for next week is to compile and run AGL and Jailhouse both in QEMU and on the Raspberry. Then I will continue integrating them together.
== Week 1: Building and getting to run
During the first week, I planned to build and run both AGL and Jailhouse in QEMU and on the Raspberry Pi. I started with building the AGL master on my laptop, but I’ve run into some problems with the libxmlsec1 package trying to use my system headers instead of the ones from the AGL tree. I was recommended to use some supported distribution (e.g. Debian stable), as I’m using Arch Linux on my laptop and it’s not supported by Yocto Project. After running the build on a Debian machine, I was able to build it for qemu-x86_64 target. Then I wanted to build it for the Raspberry, so I followed the documentation and ran into problems with the libomxil package, so I haven’t included it and it worked well.
But I’ve got another problem when running the qemu-x86_64 image with QEMU. Using the QEMU command from the documentation, the system was not able to boot. It failed to mount the /boot partition and gave a rescue shell on the console. While I was investigating the problem, I noticed that someone just asked about the same problem on the mailing list. So, later I proposed my workarounds. But even after that, I was still not able to boot into the graphical interface. So I tried it on the Raspberry and it worked well. After playing with the QEMU command-line arguments, I tried to run the image using the runqemu script and the graphical interface was finally working. Despite this, I was still not able to boot into the graphical interface using the vmdk image. After using QEMU command-line arguments from the runqemu script, now it changes the resolution when it boots, but the screen remains black.
Then I moved onto Jailhouse. I have built Jailhouse images from the jailhouse-images GitHub repository for both QEMU-x86_64 and Raspberry Pi 4. They both worked well, so I’ve got some hands-on experience with Jailhouse and the example inmates provided. The Raspberry Pi 4 image is made for the 1 GiB RAM variant of the Raspberry, but it works on the 4 GiB variant as well. It just shrinks the memory visible to the system to 1 GiB after enabling Jailhouse.
Now, the plan is to make a Yocto recipe for building Jailhouse into AGL. I’m also trying to include my findings into the AGL documentation as I go.
Jakub
_._,_._,_
Links:
You receive all messages sent to this group.
View/Reply Online (#8404) |
Reply To Group
| Reply To Sender
|
Mute This Topic
| New Topic
Your Subscription |
Contact Group Owner |
Unsubscribe
[list-automotive-discussions82@xxxxxxxxxxx]
_._,_._,_
