Re: [PATCH v4 0/5] powerpc/kvm: Add MPC8544DS board support

2009-03-02 Thread Aurelien Jarno
On Thu, Feb 26, 2009 at 06:35:40PM +0800, Liu Yu wrote:
 patch 1: enable mpic for E500 platform.
 patch 2: add E500 pci controller emulation.
 patch 3: add E500 irq support.
 patch 4: add MPC8544DS board support.
 patch 5: FDT of MPC8544DS
 

Thanks, whole series applied.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/5] kvm/powerpc: Enable MPIC for E500 platform.

2009-03-02 Thread Aurelien Jarno
On Fri, Feb 27, 2009 at 10:04:17PM +0200, Blue Swirl wrote:
 On 2/27/09, Liu Yu-B13201 yu@freescale.com wrote:
 
 
-Original Message-
From: Blue Swirl [mailto:blauwir...@gmail.com]
Sent: Friday, February 27, 2009 2:47 AM
To: Liu Yu-B13201
Cc: qemu-de...@nongnu.org; aurel...@aurel32.net;
holl...@us.ibm.com; kvm-ppc@vger.kernel.org
Subject: Re: [PATCH 1/5] kvm/powerpc: Enable MPIC for E500 platform.
   
On 2/26/09, Liu Yu yu@freescale.com wrote:
 MPIC and OpenPIC have very similar design.
  So a lot of code can be reused.

  Modification mainly include:
  1. keep struct openpic_t to the maximum size of both MPIC
and OpenPIC.
  2. endianess swap.
MPIC has the same endianess as target, so no need to
swap for MPIC.
  3. using different init functions and function pointers
for reset and irq raise.

  Haven't test OpenPIC.

  Signed-off-by: Liu Yu yu@freescale.com
   
  +struct {
  +CPUReadMemoryFunc **read;
  +CPUWriteMemoryFunc **write;
  +target_phys_addr_t start_addr;
  +ram_addr_t size;
  +} list[] = {
  +{mpic_glb_read, mpic_glb_write,
MPIC_GLB_REG_START, MPIC_GLB_REG_SIZE},
  +{mpic_tmr_read, mpic_tmr_write,
MPIC_TMR_REG_START, MPIC_TMR_REG_SIZE},
  +{mpic_ext_read, mpic_ext_write,
MPIC_EXT_REG_START, MPIC_EXT_REG_SIZE},
  +{mpic_int_read, mpic_int_write,
MPIC_INT_REG_START, MPIC_INT_REG_SIZE},
  +{mpic_msg_read, mpic_msg_write,
MPIC_MSG_REG_START, MPIC_MSG_REG_SIZE},
  +{mpic_msi_read, mpic_msi_write,
MPIC_MSI_REG_START, MPIC_MSI_REG_SIZE},
  +{mpic_cpu_read, mpic_cpu_write,
MPIC_CPU_REG_START, MPIC_CPU_REG_SIZE},
  +};
   
static const ?
   
 
 
  Why static? It's allocated on stack and will be free when function return.
 
 True, but it will be constructed for every call. But as this function
 will be called only once, it does not matter too much.
 

I have committed another patch to fix that.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Qemu-devel] [PATCH 1/5] kvm/powerpc: Enable MPIC for E500 platform.

2009-02-19 Thread Aurelien Jarno
On Tue, Feb 17, 2009 at 04:55:51PM +0200, Blue Swirl wrote:
 On 2/17/09, Liu Yu yu@freescale.com wrote:
  MPIC and OpenPIC have very similar design.
   So a lot of code can be reused.
 
   Modification mainly include:
   1. keep struct openpic_t to the maximum size of both MPIC and OpenPIC.
   2. endianess swap.
 MPIC has the same endianess as target, so no need to swap for MPIC.
 
 I don't think this is correct, the host can still be different endian
 from target.
 

I do not agree. As long as we don't manipulate host memory, the host
endianess has nothing to do. The values are simply passed by value, they
don't need to be swapped.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Qemu-devel] [PATCH 2/6] kvm/powerpc: Add freescale pci controller's support

2009-01-24 Thread Aurelien Jarno
;
 +
 +if (version_id != 1)
 +return -EINVAL;
 +
 +pci_device_load(controller-pci_dev, f);
 +
 +for (i = 0; i  PPCE500_PCI_NR_POBS; i++) {
 +qemu_get_be32s(f, controller-pob[i].potar);
 +qemu_get_be32s(f, controller-pob[i].potear);
 +qemu_get_be32s(f, controller-pob[i].powbar);
 +qemu_get_be32s(f, controller-pob[i].powar);
 +}
 +
 +for (i = 0; i  PPCE500_PCI_NR_PIBS; i++) {
 +qemu_get_be32s(f, controller-pib[i].pitar);
 +qemu_get_be32s(f, controller-pib[i].piwbar);
 +qemu_get_be32s(f, controller-pib[i].piwbear);
 +qemu_get_be32s(f, controller-pib[i].piwar);
 +}
 +qemu_get_be32s(f, controller-gasket_time);
 +
 +return 0;
 +}
 +
 +PCIBus *ppce500_pci_init(qemu_irq pci_irqs[4], target_phys_addr_t registers)
 +{
 +PPCE500PCIState *controller;
 +PCIDevice *d;
 +int index;
 +static int ppce500_pci_id;
 +
 +controller = qemu_mallocz(sizeof(PPCE500PCIState));
 +if (!controller)
 + return NULL;
 +
 +controller-pci_state.bus = pci_register_bus(mpc85xx_pci_set_irq,
 + mpc85xx_pci_map_irq,
 + pci_irqs, 0x88, 4);
 +d = pci_register_device(controller-pci_state.bus,
 +host bridge, sizeof(PCIDevice),
 +0, NULL, NULL);
 +
 +d-config[0x00] = 0x57; // vendor_id
 +d-config[0x01] = 0x19;
 +d-config[0x02] = 0x30; // device_id
 +d-config[0x03] = 0x00;
 +d-config[0x0a] = 0x20; // class_sub = other bridge type
 +d-config[0x0b] = 0x0B; // class_base = PCI_bridge
 +
 +controller-pci_dev = d;
 +
 +/* CFGADDR */
 +index = cpu_register_io_memory(0, pcie500_cfgaddr_read,
 +   pcie500_cfgaddr_write, controller);
 +if (index  0)
 +goto free;
 +cpu_register_physical_memory(registers + PCIE500_CFGADDR, 4, index);
 +
 +/* CFGDATA */
 +index = cpu_register_io_memory(0, pcie500_cfgdata_read,
 +   pcie500_cfgdata_write,
 +   controller-pci_state);
 +if (index  0)
 +goto free;
 +cpu_register_physical_memory(registers + PCIE500_CFGDATA, 4, index);
 +
 +index = cpu_register_io_memory(0, e500_pci_reg_read,
 +e500_pci_reg_write, controller);
 +if (index  0)
 + goto free;
 +cpu_register_physical_memory(registers + PCIE500_REG_BASE,
 +   PCIE500_REG_SIZE, index);
 +
 +/* XXX load/save code not tested. */
 +register_savevm(ppce500_pci, ppce500_pci_id++, 1,
 +ppce500_pci_save, ppce500_pci_load, controller);
 +
 +return controller-pci_state.bus;
 +
 +free:
 +printf(%s error\n, __func__);
 +qemu_free(controller);
 +return NULL;
 +}
 -- 
 1.5.4
 
 
 
 

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Qemu-devel] [PATCH 4/6] kvm/powerpc: extern one function for MPC85xx code use

2009-01-24 Thread Aurelien Jarno
On Thu, Jan 22, 2009 at 06:14:14PM +0800, Liu Yu wrote:
 Signed-off-by: Liu Yu yu@freescale.com
 ---
  target-ppc/kvm_ppc.c |2 +-
  target-ppc/kvm_ppc.h |2 ++
  2 files changed, 3 insertions(+), 1 deletions(-)

Thanks, applied.

 diff --git a/target-ppc/kvm_ppc.c b/target-ppc/kvm_ppc.c
 index f7ce52b..82c0f42 100644
 --- a/target-ppc/kvm_ppc.c
 +++ b/target-ppc/kvm_ppc.c
 @@ -22,7 +22,7 @@ static QEMUTimer *kvmppc_timer;
  static unsigned int kvmppc_timer_rate;
  
  #ifdef HAVE_FDT
 -static int kvmppc_read_host_property(const char *node_path, const char *prop,
 +int kvmppc_read_host_property(const char *node_path, const char *prop,
   void *val, size_t len)
  {
  char *path;
 diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h
 index e536a88..3792ef7 100644
 --- a/target-ppc/kvm_ppc.h
 +++ b/target-ppc/kvm_ppc.h
 @@ -11,5 +11,7 @@
  
  void kvmppc_init(void);
  void kvmppc_fdt_update(void *fdt);
 +int kvmppc_read_host_property(const char *node_path, const char *prop,
 + void *val, size_t len);
  
  #endif /* __KVM_PPC_H__ */
 -- 
 1.5.4
 
 
 
 

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Qemu-devel] [PATCH 3/9] powerpc/kvm: Enable mpic for E500 platform

2009-01-16 Thread Aurelien Jarno
On Fri, Jan 16, 2009 at 12:17:40PM -0600, Hollis Blanchard wrote:
 On Fri, 2009-01-16 at 13:34 +0800, Liu Yu wrote:
  
   -Original Message-
   From: Anthony Liguori [mailto:anth...@codemonkey.ws] 
   Sent: Friday, January 16, 2009 5:23 AM
   To: qemu-de...@nongnu.org
   Cc: Liu Yu-B13201; kvm-ppc@vger.kernel.org
   Subject: Re: [Qemu-devel] [PATCH 3/9] powerpc/kvm: Enable 
   mpic for E500 platform
   
   Liu Yu wrote:
The modify is based on original author's method
to switch openpic and mpic by static define,
like the switch between USE_INTEL_GW80314 and USE_MPCxxx.
(Although the support for intel has broken)
So they can't be used at the same time.
   
I guess it's not the correct way to do this.
but I am not sure is the USE_MPC85xx and openpic are still needed?
  
   
   Have you tested some of the other (TCG) boards (for instance, 
   with the 
   debian image Aurelien recently posted)?
   

This image is only for g3beige, it won't work on mac99 which is moreover
broken.

  You mean test powerpc mac99? No.
 
 It doesn't sound like mac99 works right now anyways, so that may not be
 possible to test.

Confirmed. We hope to get it working in the next few weeks/months using
OpenBIOS, the same way as for the g3beige machine.

  I only modified few places to the original code. I think it won't be 
  influenced.
  But mpic and openpic couldnot work in the same qemu binary with this patch.
  If they should both be supported, then I need to modify more.
 
 Due to the (artificial) ppc vs ppcemb split, I'm not sure this is a
 requirement.

Agreed. I am fine with some changes if they are only done for the ppcemb
binary.

 The only issue I can see is if there are ppc targets (e.g. 970) that
 use the same[1] MPIC as found on e500, and that is different from and
 not supported by the current OpenPIC emulation.

The person adding support for those ppc targets, will have to modify
the code to support both versions at runtime.

 [1] By same I mean substantially similar. As I understand it,
 OpenPIC and MPIC are very similar designs, but there are different
 bugs/quirks to different implementations. So even if e500's MPIC isn't
 *exactly* the same as 970 chipsets' MPIC, if they're close enough that
 the code could be shared, it should be.
 
 -- 
 Hollis Blanchard
 IBM Linux Technology Center
 
 
 
 

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   aure...@debian.org | aurel...@aurel32.net
   `-people.debian.org/~aurel32 | www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Qemu-devel] KVM PowerPC support v3

2008-12-16 Thread Aurelien Jarno
On Mon, Dec 15, 2008 at 06:17:28PM -0600, Hollis Blanchard wrote:
 I've fixed the configure output in patch #1, and the comment in patch #4. 
 Patch
 #2 was already acked.
 

Thanks, all applied. I still have a few questions though, see the
answer to individual patches.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   aure...@debian.org | aurel...@aurel32.net
   `-people.debian.org/~aurel32 | www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Qemu-devel] [PATCH 1/8] Move PPC4xx SDRAM controller emulation from ppc405_uc.c to ppc4xx_devs.c

2008-12-15 Thread Aurelien Jarno
 +/* invalidate all RAM mappings */
 +sdram_unmap_bcr(sdram);
 +sdram-status |= 0x8000;
 +}
 +if (!(sdram-cfg  0x4000)  (val  0x4000))
 +sdram-status |= 0x4000;
 +else if ((sdram-cfg  0x4000)  !(val  0x4000))
 +sdram-status = ~0x4000;
 +sdram-cfg = val;
 +break;
 +case 0x24: /* SDRAM_STATUS */
 +/* Read-only register */
 +break;
 +case 0x30: /* SDRAM_RTR */
 +sdram-rtr = val  0x3FF8;
 +break;
 +case 0x34: /* SDRAM_PMIT */
 +sdram-pmit = (val  0xF800) | 0x07C0;
 +break;
 +case 0x40: /* SDRAM_B0CR */
 +sdram_set_bcr(sdram-bcr[0], val, sdram-cfg  0x8000);
 +break;
 +case 0x44: /* SDRAM_B1CR */
 +sdram_set_bcr(sdram-bcr[1], val, sdram-cfg  0x8000);
 +break;
 +case 0x48: /* SDRAM_B2CR */
 +sdram_set_bcr(sdram-bcr[2], val, sdram-cfg  0x8000);
 +break;
 +case 0x4C: /* SDRAM_B3CR */
 +sdram_set_bcr(sdram-bcr[3], val, sdram-cfg  0x8000);
 +break;
 +case 0x80: /* SDRAM_TR */
 +sdram-tr = val  0x018FC01F;
 +break;
 +case 0x94: /* SDRAM_ECCCFG */
 +sdram-ecccfg = val  0x00F0;
 +break;
 +case 0x98: /* SDRAM_ECCESR */
 +val = 0xFFF0F000;
 +if (sdram-eccesr == 0  val != 0)
 +qemu_irq_raise(sdram-irq);
 +else if (sdram-eccesr != 0  val == 0)
 +qemu_irq_lower(sdram-irq);
 +sdram-eccesr = val;
 +break;
 +default: /* Error */
 +break;
 +}
 +break;
 +}
 +}
 +
 +static void sdram_reset (void *opaque)
 +{
 +ppc4xx_sdram_t *sdram;
 +
 +sdram = opaque;
 +sdram-addr = 0x;
 +sdram-bear = 0x;
 +sdram-besr0 = 0x; /* No error */
 +sdram-besr1 = 0x; /* No error */
 +sdram-cfg = 0x;
 +sdram-ecccfg = 0x; /* No ECC */
 +sdram-eccesr = 0x; /* No error */
 +sdram-pmit = 0x07C0;
 +sdram-rtr = 0x05F0;
 +sdram-tr = 0x00854009;
 +/* We pre-initialize RAM banks */
 +sdram-status = 0x;
 +sdram-cfg = 0x0080;
 +sdram_unmap_bcr(sdram);
 +}
 +
 +void ppc405_sdram_init (CPUState *env, qemu_irq irq, int nbanks,
 +target_phys_addr_t *ram_bases,
 +target_phys_addr_t *ram_sizes,
 +int do_init)
 +{
 +ppc4xx_sdram_t *sdram;
 +
 +sdram = qemu_mallocz(sizeof(ppc4xx_sdram_t));
 +if (sdram != NULL) {
 +sdram-irq = irq;
 +sdram-nbanks = nbanks;
 +memset(sdram-ram_bases, 0, 4 * sizeof(target_phys_addr_t));
 +memcpy(sdram-ram_bases, ram_bases,
 +   nbanks * sizeof(target_phys_addr_t));
 +memset(sdram-ram_sizes, 0, 4 * sizeof(target_phys_addr_t));
 +memcpy(sdram-ram_sizes, ram_sizes,
 +   nbanks * sizeof(target_phys_addr_t));
 +sdram_reset(sdram);
 +qemu_register_reset(sdram_reset, sdram);
 +ppc_dcr_register(env, SDRAM0_CFGADDR,
 + sdram, dcr_read_sdram, dcr_write_sdram);
 +ppc_dcr_register(env, SDRAM0_CFGDATA,
 + sdram, dcr_read_sdram, dcr_write_sdram);
 +if (do_init)
 +sdram_map_bcr(sdram);
 +}
 +}
 -- 
 1.5.6.5
 
 
 
 

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   aure...@debian.org | aurel...@aurel32.net
   `-people.debian.org/~aurel32 | www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Qemu-devel] [PATCH 3/8] Create a helper function to allow more flexible RAM allocation for PPC 4xx

2008-12-15 Thread Aurelien Jarno
On Mon, Dec 15, 2008 at 10:44:14AM -0600, Hollis Blanchard wrote:
 The 4xx SDRAM controller supports a small number of banks, and each bank must
 be one of a small set of sizes. The number of banks and the supported sizes
 varies by SoC.
 
 This function uses the user-specified RAM size to fill in the ram_bases and
 ram_sizes arrays required by ppc4xx_sdram_init().
 
 Signed-off-by: Hollis Blanchard holl...@us.ibm.com

Applied, thanks.

 ---
  hw/ppc4xx.h  |5 +
  hw/ppc4xx_devs.c |   42 ++
  2 files changed, 47 insertions(+), 0 deletions(-)
 
 diff --git a/hw/ppc4xx.h b/hw/ppc4xx.h
 index 3b98662..7832cd9 100644
 --- a/hw/ppc4xx.h
 +++ b/hw/ppc4xx.h
 @@ -48,6 +48,11 @@ enum {
  qemu_irq *ppcuic_init (CPUState *env, qemu_irq *irqs,
 uint32_t dcr_base, int has_ssr, int has_vr);
  
 +ram_addr_t ppc4xx_sdram_adjust(ram_addr_t ram_size, int nr_banks,
 +   target_phys_addr_t ram_bases[],
 +   target_phys_addr_t ram_sizes[],
 +   const unsigned int sdram_bank_sizes[]);
 +
  void ppc4xx_sdram_init (CPUState *env, qemu_irq irq, int nbanks,
  target_phys_addr_t *ram_bases,
  target_phys_addr_t *ram_sizes,
 diff --git a/hw/ppc4xx_devs.c b/hw/ppc4xx_devs.c
 index 2d27e23..939e066 100644
 --- a/hw/ppc4xx_devs.c
 +++ b/hw/ppc4xx_devs.c
 @@ -873,3 +873,45 @@ void ppc4xx_sdram_init (CPUState *env, qemu_irq irq, int 
 nbanks,
  sdram_map_bcr(sdram);
  }
  }
 +
 +/* Fill in consecutive SDRAM banks with 'ram_size' bytes of memory.
 + *
 + * sdram_bank_sizes[] must be 0-terminated.
 + *
 + * The 4xx SDRAM controller supports a small number of banks, and each bank
 + * must be one of a small set of sizes. The number of banks and the supported
 + * sizes varies by SoC. */
 +ram_addr_t ppc4xx_sdram_adjust(ram_addr_t ram_size, int nr_banks,
 +   target_phys_addr_t ram_bases[],
 +   target_phys_addr_t ram_sizes[],
 +   const unsigned int sdram_bank_sizes[])
 +{
 +ram_addr_t ram_end = 0;
 +int i;
 +int j;
 +
 +for (i = 0; i  nr_banks; i++) {
 +for (j = 0; sdram_bank_sizes[j] != 0; j++) {
 +unsigned int bank_size = sdram_bank_sizes[j];
 +
 +if (bank_size = ram_size) {
 +ram_bases[i] = ram_end;
 +ram_sizes[i] = bank_size;
 +ram_end += bank_size;
 +ram_size -= bank_size;
 +break;
 +}
 +}
 +
 +if (!ram_size) {
 +/* No need to use the remaining banks. */
 +break;
 +}
 +}
 +
 +if (ram_size)
 +printf(Truncating memory to %d MiB to fit SDRAM controller 
 limits.\n,
 +   (int)(ram_end  20));
 +
 +return ram_end;
 +}
 -- 
 1.5.6.5
 
 
 
 

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   aure...@debian.org | aurel...@aurel32.net
   `-people.debian.org/~aurel32 | www.aurel32.net
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html