[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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |