Re: [Xen-devel] Remaining EFI Xen on ARM issues (on Juno at least)

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-10-22 at 10:51 +0100, Jan Beulich wrote:
> >>> On 22.10.14 at 10:47, <Ian.Campbell@xxxxxxxxxx> wrote:
> > 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?
> 
> According to my own experience, the path used to invoke xen.efi
> (no matter whether from the shell of a boot manager entry) is
> sufficient to access all other files (which are getting resolved
> relative to xen.efi's location). However, I don't think I ever tried
> running something from the root of a file system. And of course I
> have no idea how similar the code bases are your and my firmware
> got built from.

You are always running from (/boot/)EFI/$vendor/ or similar I suppose.

> > I'm a bit confused why -cfg=fs2:cfg (or fs2:/cfg or fs2:\cfg) doesn't
> 
> Out of those, afaik only the variant using a backslash is valid (the
> first one being valid only if the current directory is the root of the
> fs; I don't recall whether EFI maintains per-FS CWDs or just a
> single global one).

OK, that makes sense.

> Did you verify that your EFI binary got control passed at all (i.e.
> whether it really is an issue with reading the config file)?

It prints:
        Xen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI 
loader
        No configuration file found.
So I'm pretty sure xen.efi has been called.

> > 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?
> 
> Quite possible - ours is derived from code we had been using for an
> abandoned OS project over ten years ago.

OK, so it probably is worth investigating what Xen does differently a
little then.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel