[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Xen on Raspberry Pi 4


  • To: xen-users@xxxxxxxxxxxxxxxxxxxx
  • From: Paul Leiber <paul@xxxxxxxxxxxxxxxx>
  • Date: Fri, 4 Aug 2023 07:44:11 +0200
  • Arc-authentication-results: i=1; strato.com; arc=none; dkim=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1691127859; s=strato-dkim-0002; d=strato.com; h=In-Reply-To:From:References:To:Subject:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=6aHjFZgSPTkWMM2aepTWsbxZBksFc0lphUZwSwDGA4A=; b=kpR+mOfOz8fE8ejRA4A3o9WhroO87B0NynSXq2MWD2RlcZsZFamsdjkz5i2JvL3FDJ rRFIULNQAQz3DvxlmcvA0RxXdN4RDEr96trhAtuE4O9+9mZOCcl50Cx9Ekj4hOiWP/q2 lvLO4p2C6pT50MdSgiJ4BjubMRaAno2kVYSIt/ul1qsENXtr+SFCzsVDrQG3edwjVMup mrofGUjmCXzXsWr2Wgp6FAK4bBoCxAhgX3alMx6E4iplP0uy0x11ZuNMOZuMvEskj47z df9MoZjy58AVtCNr/MSGkL2F1Ea+t5byIDsmZF31GqyrwD9wdHIvJJFDE3sQ8tybjFA/ hoSA==
  • Arc-seal: i=1; a=rsa-sha256; t=1691127859; cv=none; d=strato.com; s=strato-dkim-0002; b=OZ9ZXSTKt6Z6ywSxsS15kgF2TAE35X9q0s1MHQCX9kxLOisiUltDV8iFK7gPSF7oR/ Tt9wUaSc9kl0uRBAoL+oyupgFcOq66DIVHAWjEcxyeZcQ6J/8C4CECiqod4equjAtFtF Rn3AREhVe2KL2Ru9rBWe/ZOiQBY0s5SzSu0CQFs/mAFSS+CKLb/htnq0e9v60Vie8n2w 5Tvu7jOSCKDya5c1dj9T2zLApGCXZHVTsSXtcMJBg27W0LlRmWjvF9kZPLwRM9Zqm04F tRhGGjnGOi7xebpy+s9YwdNRpH30VVFa6GaRczxGQ8ZaDOod5Ls0F9+VQE1Cyw+eQWbV aO8Q==
  • Delivery-date: Fri, 04 Aug 2023 05:45:14 +0000
  • List-id: Xen user discussion <xen-users.lists.xenproject.org>

Am 02.08.2023 um 23:03 schrieb Julien Grall:


On 02/08/2023 21:42, Paul Leiber wrote:
Hi list,

Hi Paul,


What I did was to install a standard Debian distribution booted via EFI/GRUB2 (following https://forums.raspberrypi.com/viewtopic.php?t=282839) and then install the xen-System-arm64 package via apt. I have output on a console via UART (at least when booting Debian without Xen, see hypothesis 3 below).

Booting Debian without Xen is working fine. (Although I only see the Grub selection menu via UART when no HDMI is plugged in while booting.)

Selecting Xen in Grub leads to the following output on the console right after Grub hands over:

Loading Xen 4.17-arm64.efi ...
Loading Linux 6.1.0-10-arm64 ...
Loading initial ramdisk ...
Using modules provided by bootloader in FDT
Xen 4.17.2-pre (c/s ) EFI loader

And then the output stops.


I have been using Debian + Xen + Grub + UEFI on Rpi4. UEFI firmwares are mostly shipped with ACPI only (IOW no Device-Tree support) This is not yet a fully supported configuration on Arm64 and therefore not enabled by default.

Can you check the kernel log when booting Debian without Xen for anything referring to ACPI? If so, you will need to Xen build yourself to enable ACPI (this is protected by EXPERT). Alternatively you could use U-boot where Device-Tree boot will be available.

Indeed, the device is using ACPI. There is an option in the UEFI settings to switch to Device-Tree, but that didn't have any effect I could see, other than plain Debian didn't boot anymore either.

I compiled Xen with the ACPI option for Arm, and got it running. Thank you very much for your hint, Julien!

For reference:

To enable the ACPI option, I went to the "xen" subdirectory in the Xen source main directory after "git clone" and did a "make menuconfig".

Out of convience, I initially intended to only rebuild the Debian Xen hypervisor package with the ACPI switch on, but that didn't work somehow. I couldn't find out why. I then created a "Frankenxen" with a newly built hypervisor and standard debian tools, which booted (yay!), but of course the xen tools didn't work. Using the repo to check out a Xen 17.1 version and build the hypervisor (so I could still rely on Debian updates for all the other Xen packages) also didn't work, Xen didn't boot. I then decided to build a complete Xen version from scratch from the master repo, which worked well. So perhaps this approach with enabling ACPI only works on Xen versions > 17.1?



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.