On Fri, 2007-02-16 at 08:58 -0700, Alex Williamson wrote:
> On Fri, 2007-02-16 at 17:29 +0900, Horms wrote:
> > Does phys_efi work on linux (w/o xen) for you? I sent patches
> > to ia64-linux recently, I can send them your way if you like.
> > I ask because I am intrigued to know if phys_efi (as currently
> > implemented) works on your platform at all.
>
> I dunno, I'll give it a try. I noticed later that there was some
> kind of SAL error earlier in the log (I don't have the log atm to double
> check). I'll look over it again. Thanks,
Nope. I tried 2.6.20 plus the phys_efi patch sent to linux-ia64. It
appears that none of my SAL calls work w/ the patch:
SAL_CAL_FLUSH failed with -6510615555426900571
Failed to register rendezvous interrupt with SAL (status -6510615555426900571)
SMP: Can't set SAL AP Boot Rendezvous: Unknown SAL status code
SAL_FREQ_BASE_PLATFORM failed: Unknown SAL status code
SAL/PAL failed to obtain frequency info---inventing reasonable values
This, of course, means that I don't get PCI config accesses to work, so
I don't find any devices to boot to :(
I'm kind of confused by the kernel-parameters.txt update in the patch
that indicates phys_efi has an effect on how SAL and PAL calls are made.
SAL and PAL are still getting called in virtual mode, and probably
failing because we don't register they're runtime memory. I think if
we're going to skip SetVirtualAddressMap, then we need to make sure PAL
and SAL are using physical mode too. We already have physical mode PAL
calls, but no dynamic way to switch to them. SAL would need a similar
SAL_CALL_PHYS. All EFI/SAL/PAL calls are going to be slower in physical
mode too... Thanks,
Alex
--
Alex Williamson HP Open Source & Linux Org.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home