On Sun, Jan 31, 2021 at 9:43 PM Tamas K Lengyel <tamas.k.leng...@gmail.com> wrote: > > On Sun, Jan 31, 2021 at 8:59 PM Elliott Mitchell <ehem+...@m5p.com> wrote: > > > > On Sun, Jan 31, 2021 at 06:50:36PM -0500, Tamas K Lengyel wrote: > > > On Sun, Jan 31, 2021 at 6:33 PM Elliott Mitchell <ehem+un...@m5p.com> > > > wrote: > > > > > > > > On Sun, Jan 31, 2021 at 02:06:17PM -0500, Tamas K Lengyel wrote: > > > > > (XEN) Unable to retrieve address 0 for > > > > > /scb/pcie@7d500000/pci@1,0/usb@1,0 > > > > > (XEN) Device tree generation failed (-22). > > > > > > > > > Does anyone have an idea what might be going wrong here? I tried > > > > > building the dtb without using the dtb overlay but it didn't seem to > > > > > do anything. > > > > > > > > If you go to line 1412 of the file xen/arch/arm/domain_build.c and > > > > replace the "return res;" with "continue;" that will bypass the issue. > > > > The 3 people I'm copying on this message though may wish to ask > > > > questions > > > > about the state of your build tree. > > > > > > I'll try that but it's a pretty hacky work-around ;) > > > > Actually no, it simply causes Xen to ignore these entries. The patch > > I've got ready to submit to this list also adjusts the error message to > > avoid misinterpretation, but does pretty well exactly this. > > > > My only concern is whether it should ignore the entries only for Domain 0 > > or should always ignore them. > > > > > > > > Presently the rpixen script is grabbing the RPF's 4.19 branch, dates > > > > point to that last being touched last year. Their tree is at > > > > cc39f1c9f82f6fe5a437836811d906c709e0661c. > > > > > > I've moved the Linux branch up to 5.10 because there had been a fair > > > amount of work that went into fixing Xen on RPI4, which got merged > > > into 5.9 and I would like to be able to build upstream everything > > > without the custom patches coming with the rpixen script repo. > > > > Please keep track of where your kernel source is checked out at since > > there was a desire to figure out what was going on with the device-trees. > > > > > > Including "console=hvc0 console=AMA0 console=ttyS0 console=tty0" in the > > kernel command-line should ensure you get output from the kernel if it > > manages to start (yes, Linux does support having multiple consoles at the > > same time). > > No output from dom0 received even with the added console options > (+earlyprintk=xen). The kernel build was from rpi-5.10.y > c9226080e513181ffb3909a905e9c23b8a6e8f62. I'll check if it still boots > with 4.19 next.
The dtb overlay is giving me the following error with both 4.19 and 5.10: arch/arm64/boot/dts/overlays/pi4-64-xen.dtbo: Warning (pci_bridge): /fragment@1/__overlay__: node name is not "pci" or "pcie" arch/arm64/boot/dts/overlays/pi4-64-xen.dtbo: Warning (pci_bridge): /fragment@1/__overlay__: missing ranges for PCI bridge (or not a bridge) arch/arm64/boot/dts/overlays/pi4-64-xen.dtbo: Warning (pci_bridge): /fragment@1/__overlay__: incorrect #address-cells for PCI bridge arch/arm64/boot/dts/overlays/pi4-64-xen.dtbo: Warning (pci_bridge): /fragment@1/__overlay__: incorrect #size-cells for PCI bridge arch/arm64/boot/dts/overlays/pi4-64-xen.dtbo: Warning (pci_device_bus_num): Failed prerequisite 'pci_bridge' The overlays are defined in https://github.com/dornerworks/xen-rpi4-builder/blob/master/patches/linux/0001-Add-Xen-overlay-for-the-Pi-4.patch as: +/dts-v1/; +/plugin/; + +/ { + compatible = "brcm,bcm2711"; + + fragment@0 { + target-path = "/chosen"; + __overlay__ { + #address-cells = <0x1>; + #size-cells = <0x1>; + xen,xen-bootargs = "console=dtuart dtuart=/soc/serial@7e215040 sync_console dom0_mem=512M dom0_mem=512M bootscrub=0"; + + dom0 { + compatible = "xen,linux-zimage", "xen,multiboot-module"; + reg = <0x00400000 0x01000000>; + }; + }; + }; + + fragment@1 { + target-path = "/scb/pcie@7d500000"; + __overlay__ { + device_type = "pci"; + }; + }; +}; +// Xen configuration for Pi 4 Don't really know what those warnings mean or how to fix them but perhaps they are relevant to why Xen also complains? Tamas
