KVM on 440GP

KVM on 440GP

[Corey Minyard]

I'm playing around with KVM on an ebony board (440GP), just trying to 
get it to work, really.  I followed the instructions at 
http://www.linux-kvm.org/page/PowerPC and I used the 2.6.33 branch of 
the kvm kernel repository.  When I try to run kvm, qemu appears to abort 
and actually logs me off.

Doing a little debugging, I found that qemu_memalign() is calling abort 
because posix_memalign() is failing.  I haven't done any more debugging 
than that.

Since I already had to fix a kernel issue to get it the kernel code to 
initialize since the platform was reported as ppc440gp, not ppc440, I'm 
wondering how hard it's going to be to get this working.  Does anyone 
have this working at all?  Should I back up to a previous version?  Any 
help would be appreciated.

Thanks,

-corey

Here's the change I made to get kvm in the kernel to initialize:


Index: kvm/arch/powerpc/kvm/44x.c
=================================--- kvm.orig/arch/powerpc/kvm/44x.c
+++ kvm/arch/powerpc/kvm/44x.c
@@ -42,7 +42,7 @@ int kvmppc_core_check_processor_compat(v
 {
        int r;

-       if (strcmp(cur_cpu_spec->platform, "ppc440") = 0)
+       if (strncmp(cur_cpu_spec->platform, "ppc440", 6) = 0)
                r = 0;
        else
                r = -ENOTSUPP;

Re: KVM on 440GP

[Corey Minyard]

Corey Minyard wrote:
> I'm playing around with KVM on an ebony board (440GP), just trying to 
> get it to work, really.  I followed the instructions at 
> http://www.linux-kvm.org/page/PowerPC and I used the 2.6.33 branch of 
> the kvm kernel repository.  When I try to run kvm, qemu appears to 
> abort and actually logs me off.
>
> Doing a little debugging, I found that qemu_memalign() is calling 
> abort because posix_memalign() is failing.  I haven't done any more 
> debugging than that.
Well, I discovered that the default memory is 128M, and that's too much 
memory for a VM running on a machine with 128M.  I fixed that problem, 
and now it's doing something, though no console so not sure what.

I guess my questions below and the patch still apply.

-corey

>
> Since I already had to fix a kernel issue to get it the kernel code to 
> initialize since the platform was reported as ppc440gp, not ppc440, 
> I'm wondering how hard it's going to be to get this working.  Does 
> anyone have this working at all?  Should I back up to a previous 
> version?  Any help would be appreciated.
>
> Thanks,
>
> -corey
>
> Here's the change I made to get kvm in the kernel to initialize:
>
>
> Index: kvm/arch/powerpc/kvm/44x.c
> =================================> --- kvm.orig/arch/powerpc/kvm/44x.c
> +++ kvm/arch/powerpc/kvm/44x.c
> @@ -42,7 +42,7 @@ int kvmppc_core_check_processor_compat(v
> {
>        int r;
>
> -       if (strcmp(cur_cpu_spec->platform, "ppc440") = 0)
> +       if (strncmp(cur_cpu_spec->platform, "ppc440", 6) = 0)
>                r = 0;
>        else
>                r = -ENOTSUPP;
>
>

Re: KVM on 440GP

[Hollis Blanchard]

On Fri, Jan 22, 2010 at 7:27 AM, Corey Minyard <minyard@acm.org> wrote:
> Corey Minyard wrote:
>>
>> I'm playing around with KVM on an ebony board (440GP), just trying to get
>> it to work, really.  I followed the instructions at
>> http://www.linux-kvm.org/page/PowerPC and I used the 2.6.33 branch of the
>> kvm kernel repository.  When I try to run kvm, qemu appears to abort and
>> actually logs me off.
>>
>> Doing a little debugging, I found that qemu_memalign() is calling abort
>> because posix_memalign() is failing.  I haven't done any more debugging than
>> that.
>
> Well, I discovered that the default memory is 128M, and that's too much
> memory for a VM running on a machine with 128M.  I fixed that problem, and
> now it's doing something, though no console so not sure what.
>
> I guess my questions below and the patch still apply.
>
> -corey
>
>>
>> Since I already had to fix a kernel issue to get it the kernel code to
>> initialize since the platform was reported as ppc440gp, not ppc440, I'm
>> wondering how hard it's going to be to get this working.  Does anyone have
>> this working at all?  Should I back up to a previous version?  Any help
>> would be appreciated.
>>
>> Thanks,
>>
>> -corey
>>
>> Here's the change I made to get kvm in the kernel to initialize:
>>
>>
>> Index: kvm/arch/powerpc/kvm/44x.c
>> =================================>> --- kvm.orig/arch/powerpc/kvm/44x.c
>> +++ kvm/arch/powerpc/kvm/44x.c
>> @@ -42,7 +42,7 @@ int kvmppc_core_check_processor_compat(v
>> {
>>       int r;
>>
>> -       if (strcmp(cur_cpu_spec->platform, "ppc440") = 0)
>> +       if (strncmp(cur_cpu_spec->platform, "ppc440", 6) = 0)
>>               r = 0;
>>       else
>>               r = -ENOTSUPP;
>>
>>

Thanks! The patch looks good to me. It's unfortunate that 440GP is
reported is "ppc440gp", while every other 440 variant is reported is
"ppc440", but that's just how it goes I guess. It shouldn't be too
difficult to get things working, since the cores are more or less the
same. There has been a little accidental build breakage introduced in
the 440 code recently (work to support the "Book S" KVM port), but
it's all been simple stuff.

As for console, you probably want to use qemu's "-nographic" or at
least "-serial stdio" options.

-Hollis

Re: KVM on 440GP

[Corey Minyard]

Hollis Blanchard wrote:
>
>
> Thanks! The patch looks good to me. It's unfortunate that 440GP is
> reported is "ppc440gp", while every other 440 variant is reported is
> "ppc440", but that's just how it goes I guess. It shouldn't be too
> difficult to get things working, since the cores are more or less the
> same. There has been a little accidental build breakage introduced in
> the 440 code recently (work to support the "Book S" KVM port), but
> it's all been simple stuff.
>   
There's more basic build problems with the kernel at the head of 
development, but that doesn't seem related to kvm.

> As for console, you probably want to use qemu's "-nographic" or at
> least "-serial stdio" options.
>   
Thanks for the info.  However, "-serial stdio" doesn't seem to work.  I get:


root@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M 
bamboo -kernel uImage.bamboo -L . -append "" -m 64 -serial stdio
chardev: opening backend "stdio" failed
qemu: could not open serial device 'stdio': Success


I'm using the qemu at git://git.savannah.nongnu.org/qemu.git, not the 
one at git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git, because the 
latter wouldn't build.  I suppose those are the build problems you speak 
of.  I'll see if I can get the latter working.

Thanks a bunch!

-corey

Re: KVM on 440GP

[Alexander Graf]

On 22.01.2010, at 18:23, Corey Minyard wrote:

> Hollis Blanchard wrote:
>> 
>> 
>> Thanks! The patch looks good to me. It's unfortunate that 440GP is
>> reported is "ppc440gp", while every other 440 variant is reported is
>> "ppc440", but that's just how it goes I guess. It shouldn't be too
>> difficult to get things working, since the cores are more or less the
>> same. There has been a little accidental build breakage introduced in
>> the 440 code recently (work to support the "Book S" KVM port), but
>> it's all been simple stuff.
>>  
> There's more basic build problems with the kernel at the head of development, but that doesn't seem related to kvm.
> 
>> As for console, you probably want to use qemu's "-nographic" or at
>> least "-serial stdio" options.
>>  
> Thanks for the info.  However, "-serial stdio" doesn't seem to work.  I get:
> 
> 
> root@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M bamboo -kernel uImage.bamboo -L . -append "" -m 64 -serial stdio
> chardev: opening backend "stdio" failed
> qemu: could not open serial device 'stdio': Success

BookE KVM uses virtio console, no? I think that was explained on the wiki too.

> I'm using the qemu at git://git.savannah.nongnu.org/qemu.git, not the one at git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git, because the latter wouldn't build.  I suppose those are the build problems you speak of.  I'll see if I can get the latter working.

That's the correct one.

Alex

Re: KVM on 440GP

[Hollis Blanchard]

On Fri, Jan 22, 2010 at 9:27 AM, Alexander Graf <agraf@suse.de> wrote:
>
> On 22.01.2010, at 18:23, Corey Minyard wrote:
>
>> Hollis Blanchard wrote:
>>> As for console, you probably want to use qemu's "-nographic" or at
>>> least "-serial stdio" options.
>>>
>> Thanks for the info.  However, "-serial stdio" doesn't seem to work.  I get:
>>
>> root@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M bamboo -kernel uImage.bamboo -L . -append "" -m 64 -serial stdio
>> chardev: opening backend "stdio" failed
>> qemu: could not open serial device 'stdio': Success

Haven't seen that one. :( Does the same thing happen if you remove
--enable-kvm? If so, it sounds like an issue for
qemu-devel@nongnu.org. (No code will actually run like that, since
qemu is missing 440 MMU emulation, but it's an easy way to identify
the culprit.)

> BookE KVM uses virtio console, no? I think that was explained on the wiki too.

Sure doesn't. Book E SoCs typically contain NS16550-compatible UARTs,
so qemu's normal serial emulation works just fine.

-Hollis

Re: KVM on 440GP

[Corey Minyard]

Alexander Graf wrote:
>   
>> I'm using the qemu at git://git.savannah.nongnu.org/qemu.git, not the one at git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git, because the latter wouldn't build.  I suppose those are the build problems you speak of.  I'll see if I can get the latter working.
>>     
>
> That's the correct one.
>   
I assume you mean git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git is 
the correct one.

There's lots of problems getting it to compile.  There's no support in 
target-ppc for KVM_CAP_MP_STATE, so I'm currently backing up kernels 
until I find one that doesn't have that capability.

Thanks,

-corey

Re: KVM on 440GP

[Alexander Graf]

On 22.01.2010, at 19:29, Corey Minyard wrote:

> Alexander Graf wrote:
>>  
>>> I'm using the qemu at git://git.savannah.nongnu.org/qemu.git, not the one at git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git, because the latter wouldn't build.  I suppose those are the build problems you speak of.  I'll see if I can get the latter working.
>>>    
>> 
>> That's the correct one.
>>  
> I assume you mean git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git is the correct one.
> 
> There's lots of problems getting it to compile.  There's no support in target-ppc for KVM_CAP_MP_STATE, so I'm currently backing up kernels until I find one that doesn't have that capability.

I mean git://git.savannah.nongnu.org/qemu.git is the correct one. The KVM support in qemu-kvm is broken. Same as for S390 :-).

Alex

Re: KVM on 440GP

[Corey Minyard]

Alexander Graf wrote:
> On 22.01.2010, at 19:29, Corey Minyard wrote:
>
>   
>> Alexander Graf wrote:
>>     
>>>  
>>>       
>>>> I'm using the qemu at git://git.savannah.nongnu.org/qemu.git, not the one at git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git, because the latter wouldn't build.  I suppose those are the build problems you speak of.  I'll see if I can get the latter working.
>>>>    
>>>>         
>>> That's the correct one.
>>>  
>>>       
>> I assume you mean git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git is the correct one.
>>
>> There's lots of problems getting it to compile.  There's no support in target-ppc for KVM_CAP_MP_STATE, so I'm currently backing up kernels until I find one that doesn't have that capability.
>>     
>
> I mean git://git.savannah.nongnu.org/qemu.git is the correct one. The KVM support in qemu-kvm is broken. Same as for S390 :-).
>
> Alex
>   
Ah, ok, then I am using the right one.

I tried using telnet for the console, and it worked for a little while:

root@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M bamb
oo -kernel uImage.bamboo -L . -append "" -m 64 -serial tcp::4444,server
QEMU waiting for connection on: tcp:0.0.0.0:4444,server
Truncating memory to 64 MiB to fit SDRAM controller limits.
QEMU 0.12.50 monitor - type 'help' for more information
(qemu) info kvm
kvm support: enabled
(qemu)

So things are getting closer, but there's no output on the telnet screen.

Doing an "info registers" causes qemu to abort.

Now, nothing should have changed, but it's crashing at startup:

root@ebony:~# ./qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uI
mage.bamboo -L . -append "" -m 64 -serial tcp::4444,server
QEMU waiting for connection on: tcp:0.0.0.0:4444,server
Truncating memory to 64 MiB to fit SDRAM controller limits.
QEMU 0.12.0 monitor - type 'help' for more information
(qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000000

NIP 00000000   LR 00000000 CTR 00000000 XER 00000000
MSR 00000000 HID0 00000300  HF 00000000 idx 0
Segmentatio

backtrace show the invalid memory address, and the segfault is due to 
something happening while printing out the information.

Still poking around.

-corey

Re: KVM on 440GP

[Hollis Blanchard]

On Fri, Jan 22, 2010 at 11:13 AM, Corey Minyard <minyard@acm.org> wrote:
>
> I tried using telnet for the console, and it worked for a little while:
>
> root@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M bamb
> oo -kernel uImage.bamboo -L . -append "" -m 64 -serial tcp::4444,server
> QEMU waiting for connection on: tcp:0.0.0.0:4444,server
> Truncating memory to 64 MiB to fit SDRAM controller limits.
> QEMU 0.12.50 monitor - type 'help' for more information
> (qemu) info kvm
> kvm support: enabled
> (qemu)
>
> So things are getting closer, but there's no output on the telnet screen.
>
> Doing an "info registers" causes qemu to abort.

I believe that's a known bug.

> Now, nothing should have changed, but it's crashing at startup:
>
> root@ebony:~# ./qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uI
> mage.bamboo -L . -append "" -m 64 -serial tcp::4444,server
> QEMU waiting for connection on: tcp:0.0.0.0:4444,server
> Truncating memory to 64 MiB to fit SDRAM controller limits.

I don't think it's related, but there must be a silly bug in
ppc4xx_sdram_adjust(). 128MB should require just a single bank in the
SDRAM controller.

> QEMU 0.12.0 monitor - type 'help' for more information
> (qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000000
>
> NIP 00000000   LR 00000000 CTR 00000000 XER 00000000
> MSR 00000000 HID0 00000300  HF 00000000 idx 0
> Segmentatio
>
> backtrace show the invalid memory address, and the segfault is due to
> something happening while printing out the information.

If you provide the backtrace, I can see if it looks familiar...

-Hollis

Re: KVM on 440GP

[Corey Minyard]

Hollis Blanchard wrote:
> On Fri, Jan 22, 2010 at 11:13 AM, Corey Minyard <minyard@acm.org> wrote:
>   
>> I tried using telnet for the console, and it worked for a little while:
>>
>> root@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M bamb
>> oo -kernel uImage.bamboo -L . -append "" -m 64 -serial tcp::4444,server
>> QEMU waiting for connection on: tcp:0.0.0.0:4444,server
>> Truncating memory to 64 MiB to fit SDRAM controller limits.
>> QEMU 0.12.50 monitor - type 'help' for more information
>> (qemu) info kvm
>> kvm support: enabled
>> (qemu)
>>
>> So things are getting closer, but there's no output on the telnet screen.
>>
>> Doing an "info registers" causes qemu to abort.
>>     
>
> I believe that's a known bug.
>   
The following patch, which is almost certainly wrong, works around the 
problem:

diff --git a/hw/ppc440.c b/hw/ppc440.c
index abe0a56..03ae356 100644
--- a/hw/ppc440.c
+++ b/hw/ppc440.c
@@ -44,6 +44,7 @@ CPUState *ppc440ep_init(ram_addr_t *ram_size, PCIBus 
**pcip,
     qemu_irq *pic;
     qemu_irq *irqs;
     qemu_irq *pci_irqs;
+    uint32_t sysclk = 33333333;
 
     if (cpu_model = NULL)
         cpu_model = "405"; // XXX: should be 440EP
@@ -53,6 +54,9 @@ CPUState *ppc440ep_init(ram_addr_t *ram_size, PCIBus 
**pcip,
         exit(1);
     }
 
+    /* Set time-base frequency to sysclk */
+    ppc_emb_timers_init(env, sysclk);
+
     ppc_dcr_init(env, NULL, NULL);
 
     /* interrupt controller */


>   
>> Now, nothing should have changed, but it's crashing at startup:
>>
>> root@ebony:~# ./qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uI
>> mage.bamboo -L . -append "" -m 64 -serial tcp::4444,server
>> QEMU waiting for connection on: tcp:0.0.0.0:4444,server
>> Truncating memory to 64 MiB to fit SDRAM controller limits.
>>     
>
> I don't think it's related, but there must be a silly bug in
> ppc4xx_sdram_adjust(). 128MB should require just a single bank in the
> SDRAM controller.
>
>   
>> QEMU 0.12.0 monitor - type 'help' for more information
>> (qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000000
>>
>> NIP 00000000   LR 00000000 CTR 00000000 XER 00000000
>> MSR 00000000 HID0 00000300  HF 00000000 idx 0
>> Segmentatio
>>
>> backtrace show the invalid memory address, and the segfault is due to
>> something happening while printing out the information.
>>     
>
> If you provide the backtrace, I can see if it looks familiar...
>
> -Hollis
>
>   
Here's how far I can get now:

root@xilinx-ml507:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 64 
-M bambo
o -kernel uImage.bamboo -L . -append "" -serial tcp::4444,server
QEMU waiting for connection on: tcp:0.0.0.0:4444,server
Truncating memory to 64 MiB to fit SDRAM controller limits.
QEMU 0.12.50 monitor - type 'help' for more information
(qemu) info cpus
* CPU #0: nip=0x00000000
(qemu) info registers
NIP 00000000   LR 00000000 CTR 00000000 XER 00000000
MSR 00000000 HID0 00000300  HF 00000000 idx 0
TB 00000000 00000bb4 DECR 00000000
GPR00 0000000000000000 0000000000fffff8 0000000000000000 0000000000000000
GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
CR 00000000  [ -  -  -  -  -  -  -  -  ]             RES 00000000
FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPSCR 00000000
SRR0 00000000 SRR1 00000000 SDR1 101d23e0
(qemu) x/10x 0
00000000: 0x00000000 0x00000000 0x00000000 0x00000000
00000010: 0x00000000 0x00000000 0x00000000 0x00000000
00000020: 0x00000000 0x00000000
(qemu)


So the ROM doesn't seem to be set up properly, though bamboo.dtb is in 
the current directory.

I'm wondering if it is something bad about the memory setup.

-corey

Re: KVM on 440GP

[Hollis Blanchard]

On Fri, Jan 22, 2010 at 12:04 PM, Corey Minyard <minyard@acm.org> wrote:
> Here's how far I can get now:
>
> root@xilinx-ml507:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 64 -M
> bambo
> o -kernel uImage.bamboo -L . -append "" -serial tcp::4444,server
> QEMU waiting for connection on: tcp:0.0.0.0:4444,server
> Truncating memory to 64 MiB to fit SDRAM controller limits.
> QEMU 0.12.50 monitor - type 'help' for more information
> (qemu) info cpus
> * CPU #0: nip=0x00000000
> (qemu) info registers
> NIP 00000000   LR 00000000 CTR 00000000 XER 00000000
> MSR 00000000 HID0 00000300  HF 00000000 idx 0
> TB 00000000 00000bb4 DECR 00000000
> GPR00 0000000000000000 0000000000fffff8 0000000000000000 0000000000000000
> GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> CR 00000000  [ -  -  -  -  -  -  -  -  ]             RES 00000000
> FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPSCR 00000000
> SRR0 00000000 SRR1 00000000 SDR1 101d23e0
> (qemu) x/10x 0
> 00000000: 0x00000000 0x00000000 0x00000000 0x00000000
> 00000010: 0x00000000 0x00000000 0x00000000 0x00000000
> 00000020: 0x00000000 0x00000000
> (qemu)
>
>
> So the ROM doesn't seem to be set up properly, though bamboo.dtb is in the
> current directory.
>
> I'm wondering if it is something bad about the memory setup.

I was just given an Ebony (440GP) board, and I can verify your
results. Did you manage to make any more progress? Unfortunately I
will be traveling for a couple weeks...

Also, I don't suppose you have access to any other 440 variants? I
believe the 440GP is the only one to use the 440x4 core, while the
others use 440x5.

-Hollis

Re: KVM on 440GP

[Corey Minyard]

Hollis Blanchard wrote:
> On Fri, Jan 22, 2010 at 12:04 PM, Corey Minyard <minyard@acm.org> wrote:
>   
>> Here's how far I can get now:
>>
>>     
snip
>>
>> So the ROM doesn't seem to be set up properly, though bamboo.dtb is in the
>> current directory.
>>
>> I'm wondering if it is something bad about the memory setup.
>>     
>
> I was just given an Ebony (440GP) board, and I can verify your
> results. Did you manage to make any more progress? Unfortunately I
> will be traveling for a couple weeks...
>   
No, I gave up, it wasn't that critical for me.

> Also, I don't suppose you have access to any other 440 variants? I
> believe the 440GP is the only one to use the 440x4 core, while the
> others use 440x5.
>   
I might somewhere at work, but it would be hard to dig up.

-corey