|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Remaining EFI Xen on ARM issues (on Juno at least)
On Tue, Oct 21, 2014 at 7:17 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: > (trimming the CC list a bit) > > On Tue, 2014-10-21 at 09:17 +0100, Ian Campbell wrote: >> and applied. > > So with this in place I'm seeing a couple of remaining issues (running > on Juno). I've loaded xen.efi, Image, juno.dtb and a file called cfg > into NOR, cfg contains: > > [global] > default=default > > [default] > options=console=dtuart dtuart=serial0 conswitch=x > kernel=Image console=hvc0 earlycon=pl011,0x7ff80000 rootwait > root=/dev/sda1 > dtb=juno > > (nb the juno firmware strips the extensions, hence juno not juno.dtb) > > I've used the boot manager to create a boot entry: > [1] Linux from NOR Flash > [2] Linux EFI TFTP > [3] Xen from NOR Flash > [4] Shell > [5] Boot Manager > Start: 5 > [1] Add Boot Device Entry > [2] Update Boot Device Entry > [3] Remove Boot Device Entry > [4] Reorder Boot Device Entries > [5] Update FDT path > [6] Set Boot Timeout > [7] Return to main menu > Choice: 1 > [1] NOR Flash (63 MB) > [2] Firmware Volume (63 MB) > [3] Firmware Volume (63 MB) > [4] VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) > [5] VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) > [6] PXE on MAC Address: 00:02:F7:00:58:73 > [7] TFTP on MAC Address: 00:02:F7:00:58:73 > Select the Boot Device: 1 > File path of the EFI Application or the kernel: xen > Is your application is an OS loader? [y/n] n > Arguments to pass to the EFI Application: -cfg=cfg > Description for this new Entry: Xen from NOR Flash (2nd try) > > Then: > [1] Linux from NOR Flash > [2] Linux EFI TFTP > [3] Xen from NOR Flash > [4] Xen from NOR Flash (2nd try) > [5] Shell > [6] Boot Manager > Start: 4 > Xen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI > loader > No configuration file found. > [1] Linux from NOR Flash > [2] Linux EFI TFTP > [3] Xen from NOR Flash > [4] Xen from NOR Flash (2nd try) > [5] Shell > [6] Boot Manager > Start: > > But if I use the shell (fs2: is the NOR flash) > > Press ESC in 5 seconds to skip startup.nsh or any other key to > continue. > Shell> fs2: > FS2:\> dir > Directory of: FS2:\ > 00/00/0000 00:00 1,071,716 fip > 00/00/0000 00:00 755,472 xen > 00/00/0000 00:00 6,325,424 Image > 00/00/0000 00:00 10,185 juno > 00/00/0000 00:00 172 cfg > 00/00/0000 00:00 12,296 bl1 > 6 File(s) 8,175,265 bytes > 0 Dir(s) > FS2:\> xen -cfg=cfg > Xen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI > loader > juno: 0x00000009fadf7000-0x00000009fadf97c9 > Image: 0x00000009fa405000-0x00000009faa0d4b0 > - UART enabled - > - CPU 00000100 booting - > - Current EL 00000008 - > - Xen starting at EL2 - > - Zero BSS - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) Checking for initrd in /chosen > (XEN) RAM: 0000000080000000 - 00000000dfffffff > (XEN) RAM: 00000000e00f0000 - 00000000febcffff > (XEN) RAM: 00000000febd7000 - 00000000feffffff > (XEN) RAM: 0000000880000000 - 00000009fa404fff > (XEN) RAM: 00000009fac05000 - 00000009fada9fff > (XEN) RAM: 00000009fadab000 - 00000009fadf2fff > (XEN) RAM: 00000009fadf7000 - 00000009fadf8fff > (XEN) RAM: 00000009fadfd000 - 00000009faf6efff > (XEN) RAM: 00000009fafaa000 - 00000009fe42afff > (XEN) RAM: 00000009fe42b000 - 00000009fe918fff > (XEN) RAM: 00000009fe919000 - 00000009fec4efff > > So it works from the shell but not the boot manager. I wondered if it > might relate to UEFI's equivalent of $CWD at the point it loads xen vs > the point at which xen tries to read things, so I've tried various > things like -cfg=fs2:\cfg (with various combinations of /, \ and > nothing) in the boot mgmr with no luck. I ran into a similar issue when working on a LAVA test case - startup.nsh is run with the CWD not set, and no files can be found. The EFI boot code uses the file path from the LOADED_IMAGE_PROTOCOL to look up the parent directory, and then uses this to look for the configuration file. For the lava testing I now cd to the location of xen before running it, and this resolves the problem, so it does seem to be CWD related. I had done my development work using the FVP model semi-hosting, which avoided this problem, likely due to some of the tricks it plays. This logic is unchanged by my patches, and I haven't looked in detail as to what it does. I'm not sure what CWD should be set to for bootmenu items or for startup.nsh - I don't know if EDK2 on arm64 is not setting this properly, or if the logic in the EFI code is wrong. > > The second issue is that sometimes: > FS2:\> xen -cfg=cfg > Xen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI > loader > juno: 0x00000009fadf9000-0x00000009fadfb7c9 > Image: 0x00000009fa405000-0x00000009faa0d4b0 > Cannot obtain memory map: ErrCode: 0x8000000000000005 > > I'm not sure but this seems to correlate at least somewhat with trying > (unsuccessfully) trying to use the boot manager path before dropping to > the shell. It invariable works on a second attempt. This I think I understand. For ARM we get the map size, then allocate memory for it (allocating some extra), then get the map into the allocated buffer. The problem is that while we allocate extra memory, we don't adjust the size variable, so when we pass the size to the GetMemoryMap it is the exact size required, even though we have allocated more. The error code is "BUFFER_TOO_SMALL". I'll post a patch shortly which will hopefully fix this for you. > > Anyone got any ideas on any of this? > > Ian. > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |