Hello,
We are trying to boot Xen on a Samsung XE303C12 Chromebook aka "snow" following
the suggestions in the slide show presentation here:
https://www.slideshare.net/xen_com_mgr/xpds16-porting-xen-on-arm-to-a-new-soc-julien-grall-arm
This device uses an exynos5250 SOC dual core 1.7 GHz with 2 MB RAM, it is
a Samsung armv7 chip with virtualization extensions.
In particular, we have it working fairly well both on the bare metal with
a recent 6.1.59 Linux LTS kernel and also with a recent 5.4.257 LTS
kernel with KVM, the older LTS kernel version is used to test KVM because
support for KVM on arm v7 was removed from Linux around kernel version
5.7. So we know we have the hypervisor mode enabled because we were able
to use it with KVM.
For Xen, we are using the latest Debian build of Xen 4.17 for the Debian
armhf architecture:
(XEN) Xen version 4.17.2-pre (Debian 4.17.1+2-gb773c48e36-1)
(pkg-xen-devel@xxxxxxxxxxxxxxxxxxxxxxx) (arm-linux-gnueabihf-gcc (Debian
12.2.0-14) 12.2.0) debug=n Thu May 18 19:26:30 UTC 2023
The Linux kernel is a custom build that adds the Xen config kernel
options (CONFIG_XEN_DOM0, etc) on top of a kernel that works well on the
same Chromebook model on the bare metal. I can provide the config options
of the kernel that was used if that is helpful.
Our method of booting is to have u-boot boot the Xen hypervisor and load
the device tree after adding the dom0 to the otherwise unaltered device
tree from the Linux kernel using u-boot fdt commands to add a /chosen
node, as described on the Xen wiki and in the pages linked from there. We
have also tried adding and loading an initrd.img using the device tree
/chosen node but that made no difference in our tests.
We actually have the Linux LTS kernel version 6.1.59 working as dom0 with
Xen using the same version of u-boot that we used for KVM, but with a big
problem.
The problem we see is that when booting the 6.1.59 kernel version as dom0
with Xen, the screen is totally dark and the only way to access the
system is remotely through ssh. Logs indicate most everything else is
working, such as the wifi card so we can access it remotely via ssh and a
USB optical mouse lights up when connected so USB is also working.
Obviously, the disk is also working. The Chromebook is configured to boot
from the device's SD card slot by turning on Chrome OS developer mode
options to enable booting from the SD card slot.
The mystery is that when booting the exact same 6.1.59 kernel on the bare
metal instead of booting it as dom0 on Xen, it boots up with full access
to the screen and we can interact with the system using the X.org windows
system. But booting as dom0 with Xen, the screen is totally dark and the
only access we have to the system is through the network via ssh. Also,
when booting the 5.4.257 kernel with KVM in hypervisor mode, the screen
works and we can interact with the system through the X.org windows
system.
Exploring the log file,we have seen the errors below :
With Xen (or in bare metal):
1999-12-31T20:03:21.728453-05:
00 devuan-bunsen kernel: [ 2.535938] [drm] Exynos DRM: using
14400000.fimd device for DMA mapping operations
1999-12-31T20:03:21.728461-05:00 devuan-bunsen kernel: [ 2.536139]
exynos-drm exynos-drm: bound 14400000.fimd (ops 0xc0d96354)
1999-12-31T20:03:21.728471-05:00 devuan-bunsen kernel: [ 2.536274]
exynos-drm exynos-drm: bound 14450000.mixer (ops 0xc0d97554)
1999-12-31T20:03:21.728480-05:00 devuan-bunsen kernel: [ 2.536493]
exynos-drm exynos-drm: bound 145b0000.dp-controller (ops 0xc0d97278)
1999-12-31T20:03:21.728491-05:00 devuan-bunsen kernel: [ 2.536520]
exynos-drm exynos-drm: bound 14530000.hdmi (ops 0xc0d97bd0)
...
1999-12-31T20:03:21.729272-05:00 devuan-bunsen kernel: [ 3.493686]
Console: switching to colour frame buffer device 170x48
1999-12-31T20:03:21.729282-05:00 devuan-bunsen kernel: [ 3.521747]
exynos-drm exynos-drm: [drm] fb0: exynosdrmfb frame buffer device
1999-12-31T20:03:21.729292-05:00 devuan-bunsen kernel: [ 3.522831] [drm]
Initialized exynos 1.1.0 20180330 for exynos-drm on minor 0
In this case,the kernel is able to use the exynos-drm kernel to start the
fb0 device.
But with Xen we get this error with exynos-drm:
1999-12-31T20:01:09.722790-05:00 devuan-bunsen kernel: [ 2.606812] [drm]
Exynos DRM: using 14400000.fimd device for DMA mapping operations
1999-12-31T20:01:09.722795-05:00 devuan-bunsen kernel: [ 2.606884]
exynos-drm exynos-drm: bound 14400000.fimd (ops 0xc0d96354)
1999-12-31T20:01:09.722800-05:00 devuan-bunsen kernel: [ 2.606999]
exynos-mixer 14450000.mixer: [drm:exynos_drm_register_dma] *ERROR* Device
14450000.mixer lacks support for IOMMU
1999-12-31T20:01:09.722805-05:00 devuan-bunsen kernel: [ 2.607044]
exynos-drm exynos-drm: failed to bind 14450000.mixer (ops 0xc0d97554): -22
1999-12-31T20:01:09.722810-05:00 devuan-bunsen kernel: [ 2.607162]
exynos-drm exynos-drm: adev bind failed: -22
1999-12-31T20:01:09.722815-05:00 devuan-bunsen kernel: [ 2.607183]
exynos-dp: probe of 145b0000.dp-controller failed with error -22
Any ideas why booting the same Linux kernel that results in a working
X.org display on the bare metal instead as dom0 on Xen would cause the
display to remain dark, but most other basic functions would work, such
as network, disk, and USB ?
--
Mario.
We are trying to boot Xen on a Samsung XE303C12 Chromebook aka "snow" following
the suggestions in the slide show presentation here:
https://www.slideshare.net/xen_com_mgr/xpds16-porting-xen-on-arm-to-a-new-soc-julien-grall-arm
This device uses an exynos5250 SOC dual core 1.7 GHz with 2 MB RAM, it is
a Samsung armv7 chip with virtualization extensions.
In particular, we have it working fairly well both on the bare metal with
a recent 6.1.59 Linux LTS kernel and also with a recent 5.4.257 LTS
kernel with KVM, the older LTS kernel version is used to test KVM because
support for KVM on arm v7 was removed from Linux around kernel version
5.7. So we know we have the hypervisor mode enabled because we were able
to use it with KVM.
For Xen, we are using the latest Debian build of Xen 4.17 for the Debian
armhf architecture:
(XEN) Xen version 4.17.2-pre (Debian 4.17.1+2-gb773c48e36-1)
(pkg-xen-devel@xxxxxxxxxxxxxxxxxxxxxxx) (arm-linux-gnueabihf-gcc (Debian
12.2.0-14) 12.2.0) debug=n Thu May 18 19:26:30 UTC 2023
The Linux kernel is a custom build that adds the Xen config kernel
options (CONFIG_XEN_DOM0, etc) on top of a kernel that works well on the
same Chromebook model on the bare metal. I can provide the config options
of the kernel that was used if that is helpful.
Our method of booting is to have u-boot boot the Xen hypervisor and load
the device tree after adding the dom0 to the otherwise unaltered device
tree from the Linux kernel using u-boot fdt commands to add a /chosen
node, as described on the Xen wiki and in the pages linked from there. We
have also tried adding and loading an initrd.img using the device tree
/chosen node but that made no difference in our tests.
We actually have the Linux LTS kernel version 6.1.59 working as dom0 with
Xen using the same version of u-boot that we used for KVM, but with a big
problem.
The problem we see is that when booting the 6.1.59 kernel version as dom0
with Xen, the screen is totally dark and the only way to access the
system is remotely through ssh. Logs indicate most everything else is
working, such as the wifi card so we can access it remotely via ssh and a
USB optical mouse lights up when connected so USB is also working.
Obviously, the disk is also working. The Chromebook is configured to boot
from the device's SD card slot by turning on Chrome OS developer mode
options to enable booting from the SD card slot.
The mystery is that when booting the exact same 6.1.59 kernel on the bare
metal instead of booting it as dom0 on Xen, it boots up with full access
to the screen and we can interact with the system using the X.org windows
system. But booting as dom0 with Xen, the screen is totally dark and the
only access we have to the system is through the network via ssh. Also,
when booting the 5.4.257 kernel with KVM in hypervisor mode, the screen
works and we can interact with the system through the X.org windows
system.
Exploring the log file,we have seen the errors below :
With Xen (or in bare metal):
1999-12-31T20:03:21.728453-05:
00 devuan-bunsen kernel: [ 2.535938] [drm] Exynos DRM: using
14400000.fimd device for DMA mapping operations
1999-12-31T20:03:21.728461-05:00 devuan-bunsen kernel: [ 2.536139]
exynos-drm exynos-drm: bound 14400000.fimd (ops 0xc0d96354)
1999-12-31T20:03:21.728471-05:00 devuan-bunsen kernel: [ 2.536274]
exynos-drm exynos-drm: bound 14450000.mixer (ops 0xc0d97554)
1999-12-31T20:03:21.728480-05:00 devuan-bunsen kernel: [ 2.536493]
exynos-drm exynos-drm: bound 145b0000.dp-controller (ops 0xc0d97278)
1999-12-31T20:03:21.728491-05:00 devuan-bunsen kernel: [ 2.536520]
exynos-drm exynos-drm: bound 14530000.hdmi (ops 0xc0d97bd0)
...
1999-12-31T20:03:21.729272-05:00 devuan-bunsen kernel: [ 3.493686]
Console: switching to colour frame buffer device 170x48
1999-12-31T20:03:21.729282-05:00 devuan-bunsen kernel: [ 3.521747]
exynos-drm exynos-drm: [drm] fb0: exynosdrmfb frame buffer device
1999-12-31T20:03:21.729292-05:00 devuan-bunsen kernel: [ 3.522831] [drm]
Initialized exynos 1.1.0 20180330 for exynos-drm on minor 0
In this case,the kernel is able to use the exynos-drm kernel to start the
fb0 device.
But with Xen we get this error with exynos-drm:
1999-12-31T20:01:09.722790-05:00 devuan-bunsen kernel: [ 2.606812] [drm]
Exynos DRM: using 14400000.fimd device for DMA mapping operations
1999-12-31T20:01:09.722795-05:00 devuan-bunsen kernel: [ 2.606884]
exynos-drm exynos-drm: bound 14400000.fimd (ops 0xc0d96354)
1999-12-31T20:01:09.722800-05:00 devuan-bunsen kernel: [ 2.606999]
exynos-mixer 14450000.mixer: [drm:exynos_drm_register_dma] *ERROR* Device
14450000.mixer lacks support for IOMMU
1999-12-31T20:01:09.722805-05:00 devuan-bunsen kernel: [ 2.607044]
exynos-drm exynos-drm: failed to bind 14450000.mixer (ops 0xc0d97554): -22
1999-12-31T20:01:09.722810-05:00 devuan-bunsen kernel: [ 2.607162]
exynos-drm exynos-drm: adev bind failed: -22
1999-12-31T20:01:09.722815-05:00 devuan-bunsen kernel: [ 2.607183]
exynos-dp: probe of 145b0000.dp-controller failed with error -22
Any ideas why booting the same Linux kernel that results in a working
X.org display on the bare metal instead as dom0 on Xen would cause the
display to remain dark, but most other basic functions would work, such
as network, disk, and USB ?
--
Mario.