All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roy Franz <roy.franz@linaro.org>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: Remaining EFI Xen on ARM issues (on Juno at least)
Date: Wed, 22 Oct 2014 09:47:40 +0100	[thread overview]
Message-ID: <1413967660.20604.47.camel@citrix.com> (raw)
In-Reply-To: <CAFECyb-eCDzb_C9owTWycLoaYSCNk_CTrv=mFo1P2AmbD_v58A@mail.gmail.com>

(adding Jan)

On Tue, 2014-10-21 at 20:59 -0700, Roy Franz wrote:
> On Tue, Oct 21, 2014 at 7:17 AM, Ian Campbell <Ian.Campbell@citrix.com> 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.

Since http://xenbits.xenproject.org/docs/unstable/misc/efi.html doesn't
mention any need to qualify paths with a disk: prefix I suppose x86
doesn't require anything like this. Jan can you confirm?

I'm a bit confused why -cfg=fs2:cfg (or fs2:/cfg or fs2:\cfg) doesn't
work, since they specify the disk directly, but maybe I just don't
understand this aspect of EFI and the application/stub needs to parse
that if it wants to support loading things from other volumes (and
doesn't, which is fine).

It's interesting that Linux on juno is correctly able to load the
dtb=juno from its command line. Is there some difference here between
the interfaces used by the Linux stub vs the Xen one?

Linux's handle_cmdline_files() helper is structured rather differently
to Xen's read_file() one, but it looks like the underlying EFI calls
(open_volume, file_read) are pretty similar. There's some path
manipulation stuff in both which I don't really grok.

> > The second issue is that sometimes:
[..]
> >         Cannot obtain memory map: ErrCode: 0x8000000000000005
[...]
> I'll post a patch shortly which will hopefully fix this for you.

Seen and acked, thanks!

Ian.

  reply	other threads:[~2014-10-22  8:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-21  3:55 [PATCH] xen/arm64: Use __flush_dcache_area instead of __flush_dcache_all Roy Franz
2014-10-21  3:57 ` Roy Franz
2014-10-21  8:17 ` Ian Campbell
2014-10-21 14:17   ` Remaining EFI Xen on ARM issues (on Juno at least) Ian Campbell
2014-10-22  3:59     ` Roy Franz
2014-10-22  8:47       ` Ian Campbell [this message]
2014-10-22  9:51         ` Jan Beulich
2014-10-22 10:45           ` Ian Campbell
2014-10-22 14:14             ` Jan Beulich
2014-10-22 14:24               ` Ian Campbell
2014-10-22 14:31                 ` Jan Beulich
2014-10-23 22:49                   ` Roy Franz
2014-10-25  0:29                     ` Roy Franz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1413967660.20604.47.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=roy.franz@linaro.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.