[GSOC 2019 Proposal] Make virtualization available on Beagleboard-x15

I would like to propose the project for GSoC 2019 as a student.
My project idea is to make Xen hypervisor available and easy to use on beagleboard-x15. To achieve this, I am planning to write Xen-supporting code and tutorials for Xen setup on the board. Another project goal is to improve user experience by working on optimizations for Beagleboard’s kernel virtualization support code and/or on user-space tools.
Previously, the problem was discussed in xen mailing list and in beagleboard mailing list. The general solution wasn’t provided and it seems that the problem still does exist. At the same time, the topic starter agreed to co-mentor this project.
Expected outcomes: working Xen hypervisor on Beagleboard-x15 with Linux in Dom0 and DomU, set of step-by-step tutorial for Xen and the board and user-space tools for managing interVM operations.
Possible future work: after this project it will be easier to work with virtualization on the board, to explore new privacy related techniques (e.g. to use QubesOS).
Goal: to make ARM-based virtualization available for end users.
Hardware Skills: basic electronics.
Software Skills: C, C++, Linux kernel, Xen.
Possible Mentors: Andrew Henderson, Michael Welling.
Co-mentors: Stefano Stabellini from Xen, Iain Hunter.
Upstream Repository: N/A.
References: N/A.

Also, Julien Grall from ARM agreed to co-mentor the project.

This task could be quite difficult, depending upon your background/experience and how much you can leverage the existing XenARM code and similar platform-specific patches. Do you have a general plan on how to accomplish this project? Can any of the existing platforms (xen/arch/arm/platforms/.c) be used as a starting point? Do you have experience working through the boot-up process within the U-Boot code the prepare the environment for Xen? And then working through the Xen debugging process? Do you anticipate any additional work in xen/drivers/.c to support the X15?

Andrew

Hello Andrew,

I agree this project is pretty sophisticated but that is also one of the main reasons I want to participate in GSoC with it - it would be hard for me to make it on my own. Also GSoC gives additional motivation and increases mentors’ attention to my problems.

I have some experience with OMAP-L137 (with u-boot, Linux and baremetal) and with RISC-V (I have ported rtems on it during GSOC2017).
Currently, I don’t have a clear vision on what exactly I will have to accomplish during this project.
As far as I know, the main problem with Beagleboard-x15 will be its interrupt controller, so, I will have to make it work in xen. At the same time xen has support for OMAP5432 uEVM. So, it should be possible to make xen work in BBB-x15.
And of course I am really interested to make as much as possible drivers work with xen.

Right now, I am trying to build an environment in qemu. It’ll be qemu vexpress-a15+u-boot+xen+Linux+busybox. And I have much more difficulties with it in qemu than I had with a real board (omap-l137). My current issue is that I am trying to setup a tftpboot on vexpress-a15 machine, the problem is to set up a connection from the default controller inside of a vexpress-a15 board to host machine. I will probably try to use virt machine in qemu because it will really simplify my life. My current attempts you can find here: https://medium.com/@denisobrezkov/xen-on-arm-and-qemu-1654f24dea75 (draft)
My gsoc 2017 project: https://summerofcode.withgoogle.com/archive/2017/projects/4780624749527040/
Weekly reports for it: https://devel.rtems.org/wiki/GSoC/2017

Hello,

right now I am still fighting with u-boot on qemu on virt machine.
Somehow, with a 'user' network I can't boot via tftpboot. So, I am going
to use a TAP network.

My question is how to enhance the quality of my application? I welcome
any suggestions. The initial application can be found here:
https://groups.google.com/forum/#!topic/beagleboard-gsoc/sdlCUdc6tuk

When you use uboot with QEMU, instead of tftpboot you can simply use the
QEMU command line option "-device loader,file=XXX,addr=XXX" to load a
binary at a location in memory. For instance:

    -device loader,file=/local/arm-vm/Image,force-raw=on,addr=0x45000000 \
    -device loader,file=/local/arm-vm/xen,force-raw=on,addr=0x49000000 \
    -device loader,file=/local/arm-vm/virt-gicv3.dtb,force-raw=on,addr=0x44000000 \

No need for tftpboot.

Hi,

thank you. I am trying to boot only Linux zImage and dtb (dumped by
qemu) right now from u-boot command. But I got no repsonse from the kernel:

=> setenv bootargs "earlyprintk=serial,ttyAMA0 console=ttyAMA0"
=> printenv bootargs
bootargs=earlyprintk=serial,ttyAMA0 console=ttyAMA0
=> bootz 0x41000000 - 0x42000000
Kernel image @ 0x41000000 [ 0x000000 - 0x3fd960 ]
## Flattened Device Tree blob at 42000000
Booting using the fdt blob at 0x42000000
Using Device Tree in place at 42000000, end 42102fff

Starting kernel ...

Probably, I should pass a better string to the kernel

I am running it like this:

~/bin/qemu-3.1.0/arm-softmmu/qemu-system-arm -machine virt -m 128M -bios
u-boot.bin -device loader,file=zImage,force-raw=on,addr=0x41000000
-device loader,file=virt.dtb,force-raw=on,addr=0x42000000 -nographic
-no-reboot

Hello,

Hello Denis,

right now I am still fighting with u-boot on qemu on virt machine.
Somehow, with a 'user' network I can't boot via tftpboot. So, I am going
to use a TAP network.

My question is how to enhance the quality of my application? I welcome
any suggestions. The initial application can be found here:
https://groups.google.com/forum/#!topic/beagleboard-gsoc/sdlCUdc6tuk

I would recommend to try to break-down the tasks to add support of the board on Xen.

Most of the devices are controlled by the hardware domain (aka Dom0). Looking at the board, it is based on TI DR74 SOC. Xen already support some board from the same family, so you should be able to re-use some of the code.

As you mentioned in your application, the major work in Xen will be around the interrupt controller. For an overview of the work to do, you might want to read:
     - [1] it is a series sent in 2015 to support crossbar in Xen.
     - [2] it is a series sent in 2017 to support other interrupts controller than the GIC in Xen.

Regarding other softwares, Xen depends on:
   - U-boot: It should start Xen from EL2. Do you know what is the state of U-boot for this board?
   - Linux: Is it using upstream? Or a specific vendor tree?

Best regards,

[1] https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg03920.html
[2] https://patchwork.kernel.org/patch/9668327/

Hi,

Hi Denis,

thank you. I am trying to boot only Linux zImage and dtb (dumped by
qemu) right now from u-boot command. But I got no repsonse from the kernel:

=> setenv bootargs "earlyprintk=serial,ttyAMA0 console=ttyAMA0"
=> printenv bootargs
bootargs=earlyprintk=serial,ttyAMA0 console=ttyAMA0
=> bootz 0x41000000 - 0x42000000
Kernel image @ 0x41000000 [ 0x000000 - 0x3fd960 ]
## Flattened Device Tree blob at 42000000
Booting using the fdt blob at 0x42000000
Using Device Tree in place at 42000000, end 42102fff

Starting kernel ...

Probably, I should pass a better string to the kernel

I would recommend to turn on CONFIG_DEBUG_LL, so you get very early message from kernel.

If it is still stuck, then you could use gdb to see where the kernel is stuck.

Cheers,

Hi,

I would recommend to try to break-down the tasks to add support of the
board on Xen.

Most of the devices are controlled by the hardware domain (aka Dom0).
Looking at the board, it is based on TI DR74 SOC. Xen already support
some board from the same family, so you should be able to re-use some
of the code.

As you mentioned in your application, the major work in Xen will be
around the interrupt controller. For an overview of the work to do,
you might want to read:
- [1] it is a series sent in 2015 to support crossbar in Xen.
- [2] it is a series sent in 2017 to support other interrupts
controller than the GIC in Xen.

Regarding other softwares, Xen depends on:
- U-boot: It should start Xen from EL2. Do you know what is the
state of U-boot for this board?

There is a support for the board:

http://git.denx.de/?p=u-boot.git;a=commit;h=1e4ad74b875f4da91193afffb0bb0db90ec7b886

https://elinux.org/Beagleboard:BeagleBoard-X15#U-Boot

Though, I can't find beagle_x15_defconfig in the upstream u-boot.

- Linux: Is it using upstream? Or a specific vendor tree?

It is written that it is supported. Dts files exist for different
revisions in the mainline kernel.

Best regards,

[1]
https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg03920.html

[2] https://patchwork.kernel.org/patch/9668327/

Thank you. I will investigate them till the end of the week and look for
TI's docs on this.

Hi,

Hi,

Hi Denis,

thank you. I am trying to boot only Linux zImage and dtb (dumped by
qemu) right now from u-boot command. But I got no repsonse from the
kernel:

=> setenv bootargs "earlyprintk=serial,ttyAMA0 console=ttyAMA0"
=> printenv bootargs
bootargs=earlyprintk=serial,ttyAMA0 console=ttyAMA0
=> bootz 0x41000000 - 0x42000000
Kernel image @ 0x41000000 [ 0x000000 - 0x3fd960 ]
## Flattened Device Tree blob at 42000000
Booting using the fdt blob at 0x42000000
Using Device Tree in place at 42000000, end 42102fff

Starting kernel ...

Probably, I should pass a better string to the kernel

I would recommend to turn on CONFIG_DEBUG_LL, so you get very early
message from kernel.

If it is still stuck, then you could use gdb to see where the kernel
is stuck.

I found out the problem - I passed dtb as a qemu parameter and tried to
boot it. After that, I tried to boot dtb from default place (ram start
address) bootz 0x41000000 - 0x40000000 and it worked out! I've read
somewhere that u-boot modifies a dtb before passing it to the kernel,
maybe that was the reason. Anyway, now I can boot the kernel compiled
with defconfig for arm on virt machine and I will be trying to run
everything with xen.

Also, I was able to start gdb and attach it to qemu and load u-boot but
right now I am quite far from understanding on how it should be operated
with u-boot. Do you know some useful links on how to debug u-boot/kernel?

Hi Denis,
When I've worked on X15 with u-boot and kernel I have added an
infinite loop to the code to pause execution while I get the emulator
connected (in my case CCS on an XDS200)

volatile int loopHere=1;

// then where you want to code to stop for the emulator to connect

while (loopHere);

Once you have the emulator connected then just use debugger to set
loopHere to 0.
Occasionally in some kernel code this would screw up the code and I
spent many hours trying to catch a phantom error. In reality it was
critical kernel code that was broken changing the flow/adding extra
code. Once I understood that I was able to live with this side effect.

Iain

Hi,

>
> I would recommend to try to break-down the tasks to add support of the
> board on Xen.
>
> Most of the devices are controlled by the hardware domain (aka Dom0).
> Looking at the board, it is based on TI DR74 SOC. Xen already support
> some board from the same family, so you should be able to re-use some
> of the code.
>
> As you mentioned in your application, the major work in Xen will be
> around the interrupt controller. For an overview of the work to do,
> you might want to read:
> - [1] it is a series sent in 2015 to support crossbar in Xen.
> - [2] it is a series sent in 2017 to support other interrupts
> controller than the GIC in Xen.
>
> Regarding other softwares, Xen depends on:
> - U-boot: It should start Xen from EL2. Do you know what is the
> state of U-boot for this board?

There is a support for the board:

http://git.denx.de/?p=u-boot.git;a=commit;h=1e4ad74b875f4da91193afffb0bb0db90ec7b886

https://elinux.org/Beagleboard:BeagleBoard-X15#U-Boot

Though, I can't find beagle_x15_defconfig in the upstream u-boot.

am57xx_evm_defconfig

> - Linux: Is it using upstream? Or a specific vendor tree?
It is written that it is supported. Dts files exist for different
revisions in the mainline kernel.

Mainline runs out of the box.. (the only major diff left is all the
remoteproc_xyz drivers for all the other processors on board..)

Regards,

Hello,

I was a bit sick during last few days so wasn't able to work on the topic.

My current state is that I was able to run Linux with u-boot on
qemu-arm. Not much, but the next step is run xen and dom0.

Right now, I need to write a proposal and this is my first version:
https://elinux.org/GSoC_2019_Proposal:_Xen_on_Beagleboard-x15

I would really appreciate if you can provide some comments on it,
especially, about the timeline.

P.S. Sorry, if you have received two or three copies of the message - I had email delivery failures when I was trying to send the message from my email client app.

Hello all, I received my hardware request.