Xen on arm Chromebook seems to cause no display on screen

[Chuck Zmudzinski <brchuckz@xxxxxxxxxxxx>]

Hello,

We are trying to boot Xen on a Samsung XE303C12 Chromebook aka "snow" following 
the suggestions in the slide show presentiation 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.

Out 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.

We also have not yet done a thorough analysis of the differences in the kernel 
boot logs when booting on the bare metal vs. booting as dom0 on Xen, but 
nothing stood out in the logs as an obvious cause of this problem after a quick 
look at the logs.

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?