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

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

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)?

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.