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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.10.14 at 12:45, <Ian.Campbell@xxxxxxxxxx> wrote:
> 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.

Yes.

>> 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.

Definitely. Did I overlook that being mentioned before?

>> > 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.

Or at least adding verbosity to the operations it does, to see when
which error code(s) get(s) returned. Since failure is being accounted
for (and recovered from), those error codes wouldn't normally make
sense to print out. But first of all - I suppose this NOR thing has a
proper file system (and hence a respective EFI protocol) on it? I ask
because iirc we can't currently handle being remote booted because
we expect a file system protocol, yet in that case it's a different one
that would need to be used. There simply was no-one to ask for
that functionality yet...

Jan


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