Documentation needs to be produced in docs/ava.md.

Xen on AVA

Build Status

baremetal-sdk and virtualization-sdk images build without issue.

Hi,

I just built a bunch of machines here, and noticed that the generic-arm64 machine only builds an uncompressed root filesystem, which is 5GB. For local builds that's fine, but for CI environments that can get expensive quickly. Other machines (n2sdp, ava) produce a compressed image (.wic.gz), can we get that for generic-arm64 as well?

| Image--5.15.44+git0+947149960e_eb3df10e3f-r0-generic-arm64-20220630143628.bin   | 42M  |
| ewaol-baremetal-image-efi-disk.wks                                              | 473B |
| ewaol-baremetal-image-generic-arm64-20220701174054.rootfs.manifest              | 115K |
| ewaol-baremetal-image-generic-arm64-20220701174054.rootfs.wic                   | 5G   | *****
| ewaol-baremetal-image-generic-arm64-20220701174054.testdata.json                | 341K | 
| ewaol-baremetal-image.env                                                       | 5K   | 
| linuxaa64.efi.stub                                                              | 76K  | 
| modules--5.15.44+git0+947149960e_eb3df10e3f-r0-generic-arm64-20220630143628.tgz | 11M  | 
| systemd-bootaa64.efi                                                            | 112K | 

BSP Creation post Xen addition to EWAOL

Image Creation (wks.in)

The meta-raspberrypi layer provides sdcard_image-rpi.bbclass, which provides a known layout for a partitioned Raspberry Pi SD card. boot.cmd.xen.in in meta-virtualization then uses this layout to create a u-boot script to refer to the appropriate image offsets (among other things) on the SD card.

This augments the standard EWAOL imaging process in a couple of key ways:

• Creates a dependency on u-boot, which in turn changes the image format needed to be generated (from Image to uImage), as well as the overall boot process.
• Upheaves the existing EWAOL design methodology by moving from Xen receiving its system configuration from DeviceTree/ACPI to receiving it from a u-boot script.

DeviceTree

The solution implemented upstream is to write a Xen DeviceTree augmentation recipe, which is platform-specific, then deploying this, as well as xen proper, into the image using EWAOL_WIC_IMAGE_EXTRA_DEPENDS:<machine>. This poses an issue in the short-term for work in this repository, as there is effectively a need to augment xen-devicetree for each system we support.

Support for N1 in this regard involves removing PMU nodes, adding PCIe nodes, adding a chosen node with xen,*-bootargs compatible entries. A similar structure will be required for other machines.

This is actually kind of a problem spot for Xen in general. Even for the RPi 4 u-boot script, we need to tell Xen in which DeviceTree node PCI resides.

General BSP (machine) stuff

Need to tell BB where to find wks config with WKS_SEARCH_PATH and WKS_FILE. Need to deploy appropriate DeviceTree and EFI boot files.

getting this error:

ERROR: No recipes in default available for:
  /home/ubuntu/meta-ewaol-machine/meta-ewaol-ext/recipes-ewaol/recipes-containers/docker/docker-moby_%.bbappend

on clean checkout / build of hardknott branch for the imx8 target