On Fri, Oct 04, 2019 at 10:49:28AM +0100, Julien Grall wrote: > Hi Brian, > > On 04/10/2019 01:25, Brian Woods wrote: > > > >In the log, there's: > >(XEN) MODULE[0]: 0000000001400000 - 00000000015328f1 Xen > >(XEN) MODULE[1]: 00000000076d2000 - 00000000076dc080 Device Tree > >(XEN) MODULE[2]: 00000000076df000 - 0000000007fff364 Ramdisk > >(XEN) MODULE[3]: 0000000000080000 - 0000000003180000 Kernel > >(XEN) RESVD[0]: 00000000076d2000 - 00000000076dc000 > >(XEN) RESVD[1]: 00000000076df000 - 0000000007fff364 > > > >Linux kernel -> 8_0000 - 318_0000 > >Xen -> 140_0000 - 153_28f1 > > > >There's something not quite right here... I'm guessing Xen was working > >at the address before because it was out of the "range" of the Linux > >kernel. Now I guess I need to look into if it's a Xen or u-boot issue. > > The loading address you wrote match the ones you seem to have requested in > U-boot: > > Filename 'yocto-Image'. > Load address: 0x80000 > > Filename 'xen-custom.ub'. > Load address: 0x1400000 > > But the size does not match the one you provided in the Device-Tree: > > Bytes transferred = 18215424 (115f200 hex) > > vs > > 0x0000000003180000 - 0x0000000000080000 = 0x3100000 > > This is always a risk when you write in advance the size of the binaries and > location in the Device-Tree. If you are using tftp/load from FS, it is much > less risky to provide a U-boot script that will generate the Xen DT node. > > Cheers, > > -- > Julien Grall
Yeah. When I went in and changed the end address in the device tree and it all worked. I'm guessing Xen could use some warnings and some other things to alert the user that the device tree may need tweaking or at the very least some checks. It seems that the blame wasn't primarily on Xen, although it didn't do anyone any favors. -- Brian Woods _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
