Re: [Qemu-devel] [PATCH 15/15] ppc: Add aCube Sam460ex board

2017-08-24 Thread David Gibson 
On Thu, Aug 24, 2017 at 11:37:09PM +0200, BALATON Zoltan wrote:
> On Thu, 24 Aug 2017, David Gibson wrote:
> > On Wed, Aug 23, 2017 at 01:12:06PM +0200, BALATON Zoltan wrote:
> > > On Wed, 23 Aug 2017, David Gibson wrote:
> > > > On Sun, Aug 20, 2017 at 07:23:05PM +0200, BALATON Zoltan wrote:
> > > > > Add emulation of aCube Sam460ex board based on AMCC 460EX embedded 
> > > > > SoC.
> > > > > This is not a full implementation yet with a lot of components still
> > > > > missing but enough to start a Linux kernel and the U-Boot firmware.
> > > > > 
> > > > > Signed-off-by: François Revol 
> > > > > Signed-off-by: BALATON Zoltan 
> > > > 
> > > > As usual, only fairly superficial review here.
> > > > 
> > > > > ---
> > > > >  default-configs/ppcemb-softmmu.mak |   3 +
> > > > >  hw/ppc/Makefile.objs   |   2 +
> > > > >  hw/ppc/sam460ex.c  | 611 
> > > > > +
> > > > >  3 files changed, 616 insertions(+)
> > > > >  create mode 100644 hw/ppc/sam460ex.c
> > > > > 
> > > > > diff --git a/default-configs/ppcemb-softmmu.mak 
> > > > > b/default-configs/ppcemb-softmmu.mak
> > > > > index 635923a..90b42f0 100644
> > > > > --- a/default-configs/ppcemb-softmmu.mak
> > > > > +++ b/default-configs/ppcemb-softmmu.mak
> > > [...]
> > > > > +/*/
> > > > > +/* SPD eeprom content from mips_malta.c */
> > > > 
> > > > What's the connection with mips_malta?
> > > 
> > > The board's firmware wants to see SPD EEPROMs of the connected memory 
> > > while
> > > initialising the memory controller. This is why we need to implement SDRAM
> > > controller, I2C and SPD EEPROMs. MIPS malta board had already SPD EEPROM
> > > implementation so this is based on that. The comment just indicates where
> > > this code comes from.
> > 
> > Ok.
> > 
> > [snip]
> > > > > +env->nip = bi->entry;
> > > > > +
> > > > > +/* Create a mapping for the kernel.  */
> > > > > +mmubooke_create_initial_mapping(env, 0, 0);
> > > > > +env->gpr[6] = tswap32(EPAPR_MAGIC);
> > > > 
> > > > I'm pretty sure the tswap can't be right here.  env->gpr is in host
> > > > native order and I'd expect the constant to be as well.
> > > 
> > > I know nothing about this, maybe Francois remembers why it's there. But
> > > booting linux with -kernel works so it's probably either correct or does 
> > > not
> > > matter.
> > 
> > Have you attempted it on both BE and LE hosts though?
> 
> No, I don't have a BE host, only tried on LE. I'm guessing this may come
> from hw/ppc/virtex_ml507.c where EPAPR_MAGIC is also swapped.

Sounds like virtex is wrong too - bet they haven't tried on a BE host either.

> The only other
> place this magic number appears is in e500 where it's not swapped though so
> I don't really know what should be correct here. In u-boot sources
> (arch/powerpc/lib/bootm.c) it seems to use this magic if CONFIG_OF_LIBFDT is
> defined which seems to be set for this board so that means we likely need
> this (but maybe not for the legacy uImages I've tried). Since CPU is big
> endian and constant is defined on the host this probably should be
> cpu_to_be32(EPAPR_MAGIC). Does that sound better?

No.  It's going into a register, not memory, and the registers are in
host-native order, since they're being manipulated as whole values,
not byte arrays (the appropriate swaps for the guest endianness happen
when emulating load and store instructions).  Remember an integer is
just an integer - it's only when you encode it into a byte array that
it acquires an endianness.

Although it sounded from another part of this thread as if this might
be a non-epapr boot anyway, making the whole thing moot.

> [...]
> > > > > +/* FIXME: remove this after fixing l2sram mapping in 
> > > > > ppc440_uc.c? */
> > > > > +memory_region_init_ram(l2cache_ram, NULL, "ppc440.l2cache_ram", 
> > > > > 256 << 10,
> > > > > +   _abort);
> > > > > +memory_region_add_subregion(address_space_mem, 0x4LL, 
> > > > > l2cache_ram);
> > > > > +
> > > > > +/* USB */
> > > > > +sysbus_create_simple(TYPE_PPC4xx_EHCI, 0x4bffd0400, uic[2][29]);
> > > > > +dev = qdev_create(NULL, "sysbus-ohci");
> > > > > +qdev_prop_set_string(dev, "masterbus", "usb-bus.0");
> > > > > +qdev_prop_set_uint32(dev, "num-ports", 6);
> > > > > +qdev_init_nofail(dev);
> > > > > +sbdev = SYS_BUS_DEVICE(dev);
> > > > > +sysbus_mmio_map(sbdev, 0, 0x4bffd);
> > > > > +sysbus_connect_irq(sbdev, 0, uic[2][30]);
> > > > > +usb_create_simple(usb_bus_find(-1), "usb-kbd");
> > > > > +usb_create_simple(usb_bus_find(-1), "usb-mouse");
> > > > > +
> > > > > +/* PCI bus */
> > > > > +ppc460ex_pcie_init(env);
> > > > > +/*XXX: FIXME: is this correct? */
> > > > > +dev = sysbus_create_varargs("ppc440-pcix-host", 0xc0ec0,
> > > > > +

Re: [Qemu-devel] [PATCH 15/15] ppc: Add aCube Sam460ex board

2017-08-24 Thread David Gibson 
On Thu, Aug 24, 2017 at 11:43:18PM +0200, BALATON Zoltan wrote:
> On Thu, 24 Aug 2017, David Gibson wrote:
> > On Wed, Aug 23, 2017 at 01:43:56PM +0200, François Revol wrote:
> > > Le 23/08/2017 à 13:12, BALATON Zoltan a écrit :
> > > > > What's the connection with mips_malta?
> > > > 
> > > > The board's firmware wants to see SPD EEPROMs of the connected memory
> > > > while initialising the memory controller. This is why we need to
> > > > implement SDRAM controller, I2C and SPD EEPROMs. MIPS malta board had
> > > > already SPD EEPROM implementation so this is based on that. The comment
> > > > just indicates where this code comes from.
> > > 
> > > Indeed, and I copy-pasted from elsewhere for this.
> > > 
> > > > > > +fprintf(stderr, "qemu: Error registering flash memory.\n");
> > > > > 
> > > > > Use error_report() instead, please.
> > > 
> > > I guess this didn't exist back when I started writing it...
> > 
> > Probably not.
> > 
> > > > > > +/* Create reset TLB entries for BookE, mapping only the flash
> > > > > > memory.  */
> > > > > > +static void mmubooke_create_initial_mapping_uboot(CPUPPCState *env)
> > > > > > +{
> > > > > > +ppcemb_tlb_t *tlb = >tlb.tlbe[0];
> > > > > > +
> > > > > > +/* on reset the flash is mapped by a shadow TLB,
> > > > > > + * but since we don't implement them we need to use
> > > > > > + * the same values U-Boot will use to avoid a fault.
> > > > > > + */
> > > > > 
> > > > > Usually the reset state of the MMU is handled in the cpu code rather
> > > > > than the board code.  Is there a specific reason you need it in the
> > > > > board code here?
> > > > 
> > > > I'm not sure, probably lack of a better place. The ppc440_bamboo board
> > > > this is based on has it the same way in the board code. Maybe this could
> > > > be cleaned up when someone wants to QOMify the SoC models sometimes.
> > > 
> > > Thing is, the code allows both booting with U-Boot and with a kernel
> > > directly, and the MMU mapping differ in those cases.
> > > 
> > > Maybe the CPU reset should use the U-Boot setup and the kernel boot
> > > would just overwrite it?
> > 
> > Yes.  Basically the CPU reset should do what real hardware does - and
> > I'd expect u-boot to be written to work with that.  The kernel, on the
> > other hand will expect whatever mappings come out of u-boot (or
> > another bootloader).  Long term, I think you want to always use the
> > hardware setup and actually run the guest firmware to set up the
> > mappings the kernel expects.
> 
> Maybe we should emulate the nvram for that and then we could patch it to
> have it boot the kernel with the parameters specified in the command line?
> This would also be needed to avoid the warning from u-boot about bad
> checksum and always going with the built in defaults and would also allow
> users to store settings like on real hardware but it's not something that
> looks high priority to me at the moment.

That all sounds reasonable.

> >  For early development where it's useful
> > to be able to boot into a kernel without firmware, faking the right
> > mappings in the board code is perfectly reasonable.
> 
> So for now I'd just go with this, because there's much more to clean up and
> improve before this becomes and issue I think.

Yup, makes sense.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 15/15] ppc: Add aCube Sam460ex board

2017-08-24 Thread BALATON Zoltan 

On Thu, 24 Aug 2017, David Gibson wrote:

On Wed, Aug 23, 2017 at 01:43:56PM +0200, François Revol wrote:

Le 23/08/2017 à 13:12, BALATON Zoltan a écrit :

What's the connection with mips_malta?


The board's firmware wants to see SPD EEPROMs of the connected memory
while initialising the memory controller. This is why we need to
implement SDRAM controller, I2C and SPD EEPROMs. MIPS malta board had
already SPD EEPROM implementation so this is based on that. The comment
just indicates where this code comes from.


Indeed, and I copy-pasted from elsewhere for this.


+fprintf(stderr, "qemu: Error registering flash memory.\n");


Use error_report() instead, please.


I guess this didn't exist back when I started writing it...


Probably not.


+/* Create reset TLB entries for BookE, mapping only the flash
memory.  */
+static void mmubooke_create_initial_mapping_uboot(CPUPPCState *env)
+{
+ppcemb_tlb_t *tlb = >tlb.tlbe[0];
+
+/* on reset the flash is mapped by a shadow TLB,
+ * but since we don't implement them we need to use
+ * the same values U-Boot will use to avoid a fault.
+ */


Usually the reset state of the MMU is handled in the cpu code rather
than the board code.  Is there a specific reason you need it in the
board code here?


I'm not sure, probably lack of a better place. The ppc440_bamboo board
this is based on has it the same way in the board code. Maybe this could
be cleaned up when someone wants to QOMify the SoC models sometimes.


Thing is, the code allows both booting with U-Boot and with a kernel
directly, and the MMU mapping differ in those cases.

Maybe the CPU reset should use the U-Boot setup and the kernel boot
would just overwrite it?


Yes.  Basically the CPU reset should do what real hardware does - and
I'd expect u-boot to be written to work with that.  The kernel, on the
other hand will expect whatever mappings come out of u-boot (or
another bootloader).  Long term, I think you want to always use the
hardware setup and actually run the guest firmware to set up the
mappings the kernel expects.


Maybe we should emulate the nvram for that and then we could patch it to 
have it boot the kernel with the parameters specified in the command line? 
This would also be needed to avoid the warning from u-boot about bad 
checksum and always going with the built in defaults and would also allow 
users to store settings like on real hardware but it's not something that 
looks high priority to me at the moment.



 For early development where it's useful
to be able to boot into a kernel without firmware, faking the right
mappings in the board code is perfectly reasonable.


So for now I'd just go with this, because there's much more to clean up 
and improve before this becomes and issue I think.

Re: [Qemu-devel] [PATCH 15/15] ppc: Add aCube Sam460ex board

2017-08-24 Thread BALATON Zoltan 

On Thu, 24 Aug 2017, David Gibson wrote:

On Wed, Aug 23, 2017 at 01:12:06PM +0200, BALATON Zoltan wrote:

On Wed, 23 Aug 2017, David Gibson wrote:

On Sun, Aug 20, 2017 at 07:23:05PM +0200, BALATON Zoltan wrote:

Add emulation of aCube Sam460ex board based on AMCC 460EX embedded SoC.
This is not a full implementation yet with a lot of components still
missing but enough to start a Linux kernel and the U-Boot firmware.

Signed-off-by: François Revol 
Signed-off-by: BALATON Zoltan 


As usual, only fairly superficial review here.


---
 default-configs/ppcemb-softmmu.mak |   3 +
 hw/ppc/Makefile.objs   |   2 +
 hw/ppc/sam460ex.c  | 611 +
 3 files changed, 616 insertions(+)
 create mode 100644 hw/ppc/sam460ex.c

diff --git a/default-configs/ppcemb-softmmu.mak 
b/default-configs/ppcemb-softmmu.mak
index 635923a..90b42f0 100644
--- a/default-configs/ppcemb-softmmu.mak
+++ b/default-configs/ppcemb-softmmu.mak

[...]

+/*/
+/* SPD eeprom content from mips_malta.c */


What's the connection with mips_malta?


The board's firmware wants to see SPD EEPROMs of the connected memory while
initialising the memory controller. This is why we need to implement SDRAM
controller, I2C and SPD EEPROMs. MIPS malta board had already SPD EEPROM
implementation so this is based on that. The comment just indicates where
this code comes from.


Ok.

[snip]

+env->nip = bi->entry;
+
+/* Create a mapping for the kernel.  */
+mmubooke_create_initial_mapping(env, 0, 0);
+env->gpr[6] = tswap32(EPAPR_MAGIC);


I'm pretty sure the tswap can't be right here.  env->gpr is in host
native order and I'd expect the constant to be as well.


I know nothing about this, maybe Francois remembers why it's there. But
booting linux with -kernel works so it's probably either correct or does not
matter.


Have you attempted it on both BE and LE hosts though?


No, I don't have a BE host, only tried on LE. I'm guessing this may come 
from hw/ppc/virtex_ml507.c where EPAPR_MAGIC is also swapped. The only 
other place this magic number appears is in e500 where it's not swapped 
though so I don't really know what should be correct here. In u-boot 
sources (arch/powerpc/lib/bootm.c) it seems to use this magic if 
CONFIG_OF_LIBFDT is defined which seems to be set for this board so that 
means we likely need this (but maybe not for the legacy uImages I've 
tried). Since CPU is big endian and constant is defined on the host this 
probably should be cpu_to_be32(EPAPR_MAGIC). Does that sound better?


[...]

+/* FIXME: remove this after fixing l2sram mapping in ppc440_uc.c? */
+memory_region_init_ram(l2cache_ram, NULL, "ppc440.l2cache_ram", 256 << 10,
+   _abort);
+memory_region_add_subregion(address_space_mem, 0x4LL, l2cache_ram);
+
+/* USB */
+sysbus_create_simple(TYPE_PPC4xx_EHCI, 0x4bffd0400, uic[2][29]);
+dev = qdev_create(NULL, "sysbus-ohci");
+qdev_prop_set_string(dev, "masterbus", "usb-bus.0");
+qdev_prop_set_uint32(dev, "num-ports", 6);
+qdev_init_nofail(dev);
+sbdev = SYS_BUS_DEVICE(dev);
+sysbus_mmio_map(sbdev, 0, 0x4bffd);
+sysbus_connect_irq(sbdev, 0, uic[2][30]);
+usb_create_simple(usb_bus_find(-1), "usb-kbd");
+usb_create_simple(usb_bus_find(-1), "usb-mouse");
+
+/* PCI bus */
+ppc460ex_pcie_init(env);
+/*XXX: FIXME: is this correct? */
+dev = sysbus_create_varargs("ppc440-pcix-host", 0xc0ec0,
+uic[1][0], uic[1][20], uic[1][21], uic[1][22],
+NULL);
+pci_bus = (PCIBus *)qdev_get_child_bus(dev, "pci.0");
+if (!pci_bus) {
+fprintf(stderr, "couldn't create PCI controller!\n");
+exit(1);
+}
+memory_region_init_alias(isa, NULL, "isa_mmio", get_system_io(),
+ 0, 0x1);
+memory_region_add_subregion(get_system_memory(), 0xc0800, isa);


Does it really make sense to just embed the ISA IO space here, rather
than actually instanting a PCI<->ISA bridge?


I'm not sure if this is correct but I don't know how it's handled on real
hardware. The board does not have ISA and I don't think it has a bridge but
the IO space appears at this location according to the datasheet (In System
Memory Address Map it's listed as PCI I/O 0xc0800-0xc0800) and
clients expect PCI card's io registers to be accessible here. If anyone
knows how it's done on real hardware and if there's a better way to model
this please let me know.


Ah, ok.  I think the confusion here is that you can have PCI I/O space
without ISA or a system IO space.  In fact that's pretty standard on
things without a CPU level IO space (which means just about everything
except x86).

But in that case I'd expect the PCI host bridge to map its IO memory
regions

Re: [Qemu-devel] [PATCH 15/15] ppc: Add aCube Sam460ex board

2017-08-23 Thread David Gibson 
On Wed, Aug 23, 2017 at 01:12:06PM +0200, BALATON Zoltan wrote:
> On Wed, 23 Aug 2017, David Gibson wrote:
> > On Sun, Aug 20, 2017 at 07:23:05PM +0200, BALATON Zoltan wrote:
> > > Add emulation of aCube Sam460ex board based on AMCC 460EX embedded SoC.
> > > This is not a full implementation yet with a lot of components still
> > > missing but enough to start a Linux kernel and the U-Boot firmware.
> > > 
> > > Signed-off-by: François Revol 
> > > Signed-off-by: BALATON Zoltan 
> > 
> > As usual, only fairly superficial review here.
> > 
> > > ---
> > >  default-configs/ppcemb-softmmu.mak |   3 +
> > >  hw/ppc/Makefile.objs   |   2 +
> > >  hw/ppc/sam460ex.c  | 611 
> > > +
> > >  3 files changed, 616 insertions(+)
> > >  create mode 100644 hw/ppc/sam460ex.c
> > > 
> > > diff --git a/default-configs/ppcemb-softmmu.mak 
> > > b/default-configs/ppcemb-softmmu.mak
> > > index 635923a..90b42f0 100644
> > > --- a/default-configs/ppcemb-softmmu.mak
> > > +++ b/default-configs/ppcemb-softmmu.mak
> [...]
> > > +/*/
> > > +/* SPD eeprom content from mips_malta.c */
> > 
> > What's the connection with mips_malta?
> 
> The board's firmware wants to see SPD EEPROMs of the connected memory while
> initialising the memory controller. This is why we need to implement SDRAM
> controller, I2C and SPD EEPROMs. MIPS malta board had already SPD EEPROM
> implementation so this is based on that. The comment just indicates where
> this code comes from.

Ok.

[snip]
> > > +env->nip = bi->entry;
> > > +
> > > +/* Create a mapping for the kernel.  */
> > > +mmubooke_create_initial_mapping(env, 0, 0);
> > > +env->gpr[6] = tswap32(EPAPR_MAGIC);
> > 
> > I'm pretty sure the tswap can't be right here.  env->gpr is in host
> > native order and I'd expect the constant to be as well.
> 
> I know nothing about this, maybe Francois remembers why it's there. But
> booting linux with -kernel works so it's probably either correct or does not
> matter.

Have you attempted it on both BE and LE hosts though?

> 
> > > +env->gpr[7] = (16 << 20) - 8; /*bi->ima_size;*/
> > 
> > So, entering the kernel directly can be useful, particularly during
> > early development.  However, having both firmware and non-firmware
> > entry paths can lead to confusing bugs if there's a subtle difference
> > between the initial (to the kernel) states between the two paths.  For
> > that reason, the usual preferred way to implement -kernel is to still
> > run the usual firmware, but use some way of telling it to boot
> > immediately into the supplied kernel.
> > 
> > I won't object to merging it this way - just a wanrning that this may
> > bite you in the future if you're not careful.
> 
> Warning taken, at this point until firmware cannot reliably boot things
> having another way to test is useful to have. In the future when booting via
> firmware works well we can figure out what to do with this.

Fair enough.

[snip]
> > > +generate_eeprom_spd(_eeprom_buf[i * 256], ram_sizes[i]);
> > > +}
> > > +generate_eeprom_serial(_eeprom_buf[4 * 256]);
> > > +generate_eeprom_serial(_eeprom_buf[6 * 256]);
> > > +
> > > +/* IIC controllers */
> > > +dev = sysbus_create_simple(TYPE_PPC4xx_I2C, 0x4ef600700, uic[0][2]);
> > > +i2c[0] = PPC4xx_I2C(dev);
> > > +object_property_set_bool(OBJECT(dev), true, "realized", NULL);
> > > +smbus_eeprom_init(i2c[0]->bus, 8, smbus_eeprom_buf, 
> > > smbus_eeprom_size);
> > > +g_free(smbus_eeprom_buf);
> > > +
> > > +dev = sysbus_create_simple(TYPE_PPC4xx_I2C, 0x4ef600800, uic[0][3]);
> > > +i2c[1] = PPC4xx_I2C(dev);
> > > +
> > > +/* External bus controller */
> > > +ppc405_ebc_init(env);
> > > +
> > > +/* CPR */
> > > +ppc4xx_cpr_init(env);
> > > +
> > > +/* PLB to AHB bridge */
> > > +ppc4xx_ahb_init(env);
> > > +
> > > +/* System DCRs */
> > > +ppc4xx_sdr_init(env);
> > > +
> > > +/* MAL */
> > > +ppc4xx_mal_init(env, 4, 16, [2][3]);
> > > +
> > > +/* 256K of L2 cache as memory */
> > > +ppc4xx_l2sram_init(env);
> > 
> > Seems like a lot of this peripheral setup should be handled by a SoC
> > helper function, since it's not really board specific (I'm guessing).
> > I'm ok with that being a later clean up though.
> 
> I know, the ppc405 has an init function and I considered moving some of this
> to a similar function but I've left it here for now for simplicity until
> it's decided what's the best way to clean this up.

Ok, seems reasonable.

> > > +/* FIXME: remove this after fixing l2sram mapping in ppc440_uc.c? */
> > > +memory_region_init_ram(l2cache_ram, NULL, "ppc440.l2cache_ram", 256 
> > > << 10,
> > > +   _abort);
> > > +memory_region_add_subregion(address_space_mem, 0x4LL, 
> > >

Re: [Qemu-devel] [PATCH 15/15] ppc: Add aCube Sam460ex board

2017-08-23 Thread David Gibson 
On Wed, Aug 23, 2017 at 02:47:42PM +0200, BALATON Zoltan wrote:
> On Wed, 23 Aug 2017, François Revol wrote:
> > Le 23/08/2017 à 13:12, BALATON Zoltan a écrit :
> > > > What's the connection with mips_malta?
> > > 
> > > The board's firmware wants to see SPD EEPROMs of the connected memory
> > > while initialising the memory controller. This is why we need to
> > > implement SDRAM controller, I2C and SPD EEPROMs. MIPS malta board had
> > > already SPD EEPROM implementation so this is based on that. The comment
> > > just indicates where this code comes from.
> > 
> > Indeed, and I copy-pasted from elsewhere for this.
> > 
> > > > > +fprintf(stderr, "qemu: Error registering flash memory.\n");
> > > > 
> > > > Use error_report() instead, please.
> > 
> > I guess this didn't exist back when I started writing it...
> 
> No problem, I can take care of these.
> 
> > > > > +/* Create reset TLB entries for BookE, mapping only the flash
> > > > > memory.  */
> > > > > +static void mmubooke_create_initial_mapping_uboot(CPUPPCState *env)
> > > > > +{
> > > > > +ppcemb_tlb_t *tlb = >tlb.tlbe[0];
> > > > > +
> > > > > +/* on reset the flash is mapped by a shadow TLB,
> > > > > + * but since we don't implement them we need to use
> > > > > + * the same values U-Boot will use to avoid a fault.
> > > > > + */
> > > > 
> > > > Usually the reset state of the MMU is handled in the cpu code rather
> > > > than the board code.  Is there a specific reason you need it in the
> > > > board code here?
> > > 
> > > I'm not sure, probably lack of a better place. The ppc440_bamboo board
> > > this is based on has it the same way in the board code. Maybe this could
> > > be cleaned up when someone wants to QOMify the SoC models sometimes.
> > 
> > Thing is, the code allows both booting with U-Boot and with a kernel
> > directly, and the MMU mapping differ in those cases.
> > 
> > Maybe the CPU reset should use the U-Boot setup and the kernel boot
> > would just overwrite it?
> > 
> > > > > +env->nip = bi->entry;
> > > > > +
> > > > > +/* Create a mapping for the kernel.  */
> > > > > +mmubooke_create_initial_mapping(env, 0, 0);
> > > > > +env->gpr[6] = tswap32(EPAPR_MAGIC);
> > > > 
> > > > I'm pretty sure the tswap can't be right here.  env->gpr is in host
> > > > native order and I'd expect the constant to be as well.
> > > 
> > > I know nothing about this, maybe Francois remembers why it's there. But
> > > booting linux with -kernel works so it's probably either correct or does
> > > not matter.
> > 
> > Absolutely no idea. It seems to be there from the first commit in my own
> > history here.
> > 
> > I don't recall testing booting linux at all though.
> > Linux does check the magic, so it'd be weird if it booted:
> > 
> > https://github.com/torvalds/linux/blob/master/arch/powerpc/boot/epapr.c
> 
> Is this code used on Sam460 at all? Is U-Boot ePAPR compliant
> firmware?

It can be, depends on the build, I think.

> Isn't that only needed on OpenFirmware?

No, not at all.  True OF will generally *not* be ePAPR compliant -
ePAPR was explicitly built as a much simpler interface that doesn't
require an OF implementation.  It uses some concepts from OF,
specifically the contents of the device tree, but other than that it's
not related.

> 
> > But maybe it got added later than the version you tested?
> 
> I've tried some of these:
> http://www.supertuxkart-amiga.de/amiga/sam.html#downloads
> which also have kernel 4.5 so that's fairly recent. These kernels are
> "u-boot legacy uImage" so maybe they don't need ePAPR magic? Are there some
> docs on what the kernel expects on this board or it has to be dug out from
> U-Boot?

If it's a legacy uImage I suspect it's not using ePAPR.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 15/15] ppc: Add aCube Sam460ex board

2017-08-23 Thread David Gibson 
On Wed, Aug 23, 2017 at 01:43:56PM +0200, François Revol wrote:
> Le 23/08/2017 à 13:12, BALATON Zoltan a écrit :
> >> What's the connection with mips_malta?
> > 
> > The board's firmware wants to see SPD EEPROMs of the connected memory
> > while initialising the memory controller. This is why we need to
> > implement SDRAM controller, I2C and SPD EEPROMs. MIPS malta board had
> > already SPD EEPROM implementation so this is based on that. The comment
> > just indicates where this code comes from.
> 
> Indeed, and I copy-pasted from elsewhere for this.
> 
> >>> +fprintf(stderr, "qemu: Error registering flash memory.\n");
> >>
> >> Use error_report() instead, please.
> 
> I guess this didn't exist back when I started writing it...

Probably not.

> >>> +/* Create reset TLB entries for BookE, mapping only the flash
> >>> memory.  */
> >>> +static void mmubooke_create_initial_mapping_uboot(CPUPPCState *env)
> >>> +{
> >>> +ppcemb_tlb_t *tlb = >tlb.tlbe[0];
> >>> +
> >>> +/* on reset the flash is mapped by a shadow TLB,
> >>> + * but since we don't implement them we need to use
> >>> + * the same values U-Boot will use to avoid a fault.
> >>> + */
> >>
> >> Usually the reset state of the MMU is handled in the cpu code rather
> >> than the board code.  Is there a specific reason you need it in the
> >> board code here?
> > 
> > I'm not sure, probably lack of a better place. The ppc440_bamboo board
> > this is based on has it the same way in the board code. Maybe this could
> > be cleaned up when someone wants to QOMify the SoC models sometimes.
> 
> Thing is, the code allows both booting with U-Boot and with a kernel
> directly, and the MMU mapping differ in those cases.
> 
> Maybe the CPU reset should use the U-Boot setup and the kernel boot
> would just overwrite it?

Yes.  Basically the CPU reset should do what real hardware does - and
I'd expect u-boot to be written to work with that.  The kernel, on the
other hand will expect whatever mappings come out of u-boot (or
another bootloader).  Long term, I think you want to always use the
hardware setup and actually run the guest firmware to set up the
mappings the kernel expects.  For early development where it's useful
to be able to boot into a kernel without firmware, faking the right
mappings in the board code is perfectly reasonable.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 15/15] ppc: Add aCube Sam460ex board

2017-08-23 Thread BALATON Zoltan 

On Wed, 23 Aug 2017, François Revol wrote:

Le 23/08/2017 à 13:12, BALATON Zoltan a écrit :

What's the connection with mips_malta?


The board's firmware wants to see SPD EEPROMs of the connected memory
while initialising the memory controller. This is why we need to
implement SDRAM controller, I2C and SPD EEPROMs. MIPS malta board had
already SPD EEPROM implementation so this is based on that. The comment
just indicates where this code comes from.


Indeed, and I copy-pasted from elsewhere for this.


+fprintf(stderr, "qemu: Error registering flash memory.\n");


Use error_report() instead, please.


I guess this didn't exist back when I started writing it...


No problem, I can take care of these.


+/* Create reset TLB entries for BookE, mapping only the flash
memory.  */
+static void mmubooke_create_initial_mapping_uboot(CPUPPCState *env)
+{
+ppcemb_tlb_t *tlb = >tlb.tlbe[0];
+
+/* on reset the flash is mapped by a shadow TLB,
+ * but since we don't implement them we need to use
+ * the same values U-Boot will use to avoid a fault.
+ */


Usually the reset state of the MMU is handled in the cpu code rather
than the board code.  Is there a specific reason you need it in the
board code here?


I'm not sure, probably lack of a better place. The ppc440_bamboo board
this is based on has it the same way in the board code. Maybe this could
be cleaned up when someone wants to QOMify the SoC models sometimes.


Thing is, the code allows both booting with U-Boot and with a kernel
directly, and the MMU mapping differ in those cases.

Maybe the CPU reset should use the U-Boot setup and the kernel boot
would just overwrite it?


+env->nip = bi->entry;
+
+/* Create a mapping for the kernel.  */
+mmubooke_create_initial_mapping(env, 0, 0);
+env->gpr[6] = tswap32(EPAPR_MAGIC);


I'm pretty sure the tswap can't be right here.  env->gpr is in host
native order and I'd expect the constant to be as well.


I know nothing about this, maybe Francois remembers why it's there. But
booting linux with -kernel works so it's probably either correct or does
not matter.


Absolutely no idea. It seems to be there from the first commit in my own
history here.

I don't recall testing booting linux at all though.
Linux does check the magic, so it'd be weird if it booted:

https://github.com/torvalds/linux/blob/master/arch/powerpc/boot/epapr.c


Is this code used on Sam460 at all? Is U-Boot ePAPR compliant firmware? 
Isn't that only needed on OpenFirmware?



But maybe it got added later than the version you tested?


I've tried some of these: 
http://www.supertuxkart-amiga.de/amiga/sam.html#downloads
which also have kernel 4.5 so that's fairly recent. These kernels are 
"u-boot legacy uImage" so maybe they don't need ePAPR magic? Are there 
some docs on what the kernel expects on this board or it has to be dug out 
from U-Boot?



At least my current Haiku port ignores the magic for now.


+env->gpr[7] = (16 << 20) - 8; /*bi->ima_size;*/


So, entering the kernel directly can be useful, particularly during
early development.  However, having both firmware and non-firmware
entry paths can lead to confusing bugs if there's a subtle difference
between the initial (to the kernel) states between the two paths.  For
that reason, the usual preferred way to implement -kernel is to still
run the usual firmware, but use some way of telling it to boot
immediately into the supplied kernel.

I won't object to merging it this way - just a wanrning that this may
bite you in the future if you're not careful.


Warning taken, at this point until firmware cannot reliably boot things
having another way to test is useful to have. In the future when booting
via firmware works well we can figure out what to do with this.


Possibly we could dig the U-Boot environment...


+memory_region_init_alias(isa, NULL, "isa_mmio", get_system_io(),
+ 0, 0x1);
+memory_region_add_subregion(get_system_memory(), 0xc0800, isa);


Does it really make sense to just embed the ISA IO space here, rather
than actually instanting a PCI<->ISA bridge?


I'm not sure if this is correct but I don't know how it's handled on
real hardware. The board does not have ISA and I don't think it has a
bridge but the IO space appears at this location according to the
datasheet (In System Memory Address Map it's listed as PCI I/O
0xc0800-0xc0800) and clients expect PCI card's io registers to
be accessible here. If anyone knows how it's done on real hardware and
if there's a better way to model this please let me know.


Indeed it's the PCI I/O space, maybe it's just copy-paste error.

As for how to declare it, keep in mind this code is years old and I
fixed it several times when compilation broke, without really reading
the documentation (actually, do we have proper documentation for the
internal API?), and it kept changing over the years.


And I've also changed it while

Re: [Qemu-devel] [PATCH 15/15] ppc: Add aCube Sam460ex board

2017-08-23 Thread François Revol 
Le 23/08/2017 à 13:12, BALATON Zoltan a écrit :
>> What's the connection with mips_malta?
> 
> The board's firmware wants to see SPD EEPROMs of the connected memory
> while initialising the memory controller. This is why we need to
> implement SDRAM controller, I2C and SPD EEPROMs. MIPS malta board had
> already SPD EEPROM implementation so this is based on that. The comment
> just indicates where this code comes from.

Indeed, and I copy-pasted from elsewhere for this.

>>> +fprintf(stderr, "qemu: Error registering flash memory.\n");
>>
>> Use error_report() instead, please.

I guess this didn't exist back when I started writing it...

>>> +/* Create reset TLB entries for BookE, mapping only the flash
>>> memory.  */
>>> +static void mmubooke_create_initial_mapping_uboot(CPUPPCState *env)
>>> +{
>>> +ppcemb_tlb_t *tlb = >tlb.tlbe[0];
>>> +
>>> +/* on reset the flash is mapped by a shadow TLB,
>>> + * but since we don't implement them we need to use
>>> + * the same values U-Boot will use to avoid a fault.
>>> + */
>>
>> Usually the reset state of the MMU is handled in the cpu code rather
>> than the board code.  Is there a specific reason you need it in the
>> board code here?
> 
> I'm not sure, probably lack of a better place. The ppc440_bamboo board
> this is based on has it the same way in the board code. Maybe this could
> be cleaned up when someone wants to QOMify the SoC models sometimes.

Thing is, the code allows both booting with U-Boot and with a kernel
directly, and the MMU mapping differ in those cases.

Maybe the CPU reset should use the U-Boot setup and the kernel boot
would just overwrite it?

>>> +env->nip = bi->entry;
>>> +
>>> +/* Create a mapping for the kernel.  */
>>> +mmubooke_create_initial_mapping(env, 0, 0);
>>> +env->gpr[6] = tswap32(EPAPR_MAGIC);
>>
>> I'm pretty sure the tswap can't be right here.  env->gpr is in host
>> native order and I'd expect the constant to be as well.
> 
> I know nothing about this, maybe Francois remembers why it's there. But
> booting linux with -kernel works so it's probably either correct or does
> not matter.

Absolutely no idea. It seems to be there from the first commit in my own
history here.

I don't recall testing booting linux at all though.
Linux does check the magic, so it'd be weird if it booted:

https://github.com/torvalds/linux/blob/master/arch/powerpc/boot/epapr.c

But maybe it got added later than the version you tested?

At least my current Haiku port ignores the magic for now.

>>> +env->gpr[7] = (16 << 20) - 8; /*bi->ima_size;*/
>>
>> So, entering the kernel directly can be useful, particularly during
>> early development.  However, having both firmware and non-firmware
>> entry paths can lead to confusing bugs if there's a subtle difference
>> between the initial (to the kernel) states between the two paths.  For
>> that reason, the usual preferred way to implement -kernel is to still
>> run the usual firmware, but use some way of telling it to boot
>> immediately into the supplied kernel.
>>
>> I won't object to merging it this way - just a wanrning that this may
>> bite you in the future if you're not careful.
> 
> Warning taken, at this point until firmware cannot reliably boot things
> having another way to test is useful to have. In the future when booting
> via firmware works well we can figure out what to do with this.

Possibly we could dig the U-Boot environment...

>>> +memory_region_init_alias(isa, NULL, "isa_mmio", get_system_io(),
>>> + 0, 0x1);
>>> +memory_region_add_subregion(get_system_memory(), 0xc0800, isa);
>>
>> Does it really make sense to just embed the ISA IO space here, rather
>> than actually instanting a PCI<->ISA bridge?
> 
> I'm not sure if this is correct but I don't know how it's handled on
> real hardware. The board does not have ISA and I don't think it has a
> bridge but the IO space appears at this location according to the
> datasheet (In System Memory Address Map it's listed as PCI I/O
> 0xc0800-0xc0800) and clients expect PCI card's io registers to
> be accessible here. If anyone knows how it's done on real hardware and
> if there's a better way to model this please let me know.

Indeed it's the PCI I/O space, maybe it's just copy-paste error.

As for how to declare it, keep in mind this code is years old and I
fixed it several times when compilation broke, without really reading
the documentation (actually, do we have proper documentation for the
internal API?), and it kept changing over the years.

> 
>>> +/* PCI devices */
>>> +pci_create_simple(pci_bus, PCI_DEVFN(6, 0), "sm501");
>>> +/* SoC has a single SATA port but we don't emulate that yet
>>> + * However, firmware and usual clients have driver for SiI311x
>>> + * so add one for convenience by default */
>>> +pci_create_simple(pci_bus, -1, "sii3112");
>>
>> You should probably not create this

Re: [Qemu-devel] [PATCH 15/15] ppc: Add aCube Sam460ex board

2017-08-23 Thread BALATON Zoltan 

On Wed, 23 Aug 2017, David Gibson wrote:

On Sun, Aug 20, 2017 at 07:23:05PM +0200, BALATON Zoltan wrote:

Add emulation of aCube Sam460ex board based on AMCC 460EX embedded SoC.
This is not a full implementation yet with a lot of components still
missing but enough to start a Linux kernel and the U-Boot firmware.

Signed-off-by: François Revol 
Signed-off-by: BALATON Zoltan 


As usual, only fairly superficial review here.


---
 default-configs/ppcemb-softmmu.mak |   3 +
 hw/ppc/Makefile.objs   |   2 +
 hw/ppc/sam460ex.c  | 611 +
 3 files changed, 616 insertions(+)
 create mode 100644 hw/ppc/sam460ex.c

diff --git a/default-configs/ppcemb-softmmu.mak 
b/default-configs/ppcemb-softmmu.mak
index 635923a..90b42f0 100644
--- a/default-configs/ppcemb-softmmu.mak
+++ b/default-configs/ppcemb-softmmu.mak

[...]

+/*/
+/* SPD eeprom content from mips_malta.c */


What's the connection with mips_malta?


The board's firmware wants to see SPD EEPROMs of the connected memory 
while initialising the memory controller. This is why we need to implement 
SDRAM controller, I2C and SPD EEPROMs. MIPS malta board had already SPD 
EEPROM implementation so this is based on that. The comment just indicates 
where this code comes from.



+struct _eeprom24c0x_t {
+  uint8_t tick;
+  uint8_t address;
+  uint8_t command;
+  uint8_t ack;
+  uint8_t scl;
+  uint8_t sda;
+  uint8_t data;
+  uint8_t contents[256];
+};
+
+typedef struct _eeprom24c0x_t eeprom24c0x_t;
+
+static eeprom24c0x_t spd_eeprom = {
+.contents = {
+/* : */ 0x80, 0x08, 0xFF, 0x0D, 0x0A, 0xFF, 0x40, 0x00,
+/* 0008: */ 0x04, 0x75, 0x54, 0x00, 0x82, 0x08, 0x00, 0x01,
+/* 0010: */ 0x8F, 0x04, 0x02, 0x01, 0x01, 0x00, 0x00, 0x00,
+/* 0018: */ 0x00, 0x00, 0x00, 0x14, 0x0F, 0x14, 0x2D, 0xFF,
+/* 0020: */ 0x15, 0x08, 0x15, 0x08, 0x00, 0x00, 0x00, 0x00,
+/* 0028: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+/* 0030: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+/* 0038: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x12, 0xD0,
+/* 0040: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+/* 0048: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+/* 0050: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+/* 0058: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+/* 0060: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+/* 0068: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+/* 0070: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+/* 0078: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x64, 0xF4,
+},
+};
+
+static void generate_eeprom_spd(uint8_t *eeprom, ram_addr_t ram_size)
+{
+enum { SDR = 0x4, DDR1 = 0x7, DDR2 = 0x8 } type;
+uint8_t *spd = spd_eeprom.contents;
+uint8_t nbanks = 0;
+uint16_t density = 0;
+int i;
+
+/* work in terms of MB */
+ram_size >>= 20;
+
+while ((ram_size >= 4) && (nbanks <= 2)) {
+int sz_log2 = MIN(31 - clz32(ram_size), 14);
+nbanks++;
+density |= 1 << (sz_log2 - 2);
+ram_size -= 1 << sz_log2;
+}
+
+/* split to 2 banks if possible */
+if ((nbanks == 1) && (density > 1)) {
+nbanks++;
+density >>= 1;
+}
+
+if (density & 0xff00) {
+density = (density & 0xe0) | ((density >> 8) & 0x1f);
+type = DDR2;
+} else if (!(density & 0x1f)) {
+type = DDR2;
+} else {
+type = SDR;
+}
+
+if (ram_size) {
+fprintf(stderr, "Warning: SPD cannot represent final %dMB"
+" of SDRAM\n", (int)ram_size);
+}
+
+/* fill in SPD memory information */
+spd[2] = type;
+spd[5] = nbanks;
+spd[31] = density;
+#ifdef DEBUG_SDRAM
+printf("SPD: nbanks %d density %d\n", nbanks, density);
+#endif
+/* XXX: this is totally random */
+spd[9] = 0x10; /* CAS tcyc */
+spd[18] = 0x20; /* CAS bit */
+spd[23] = 0x10; /* CAS tcyc */
+spd[25] = 0x10; /* CAS tcyc */
+
+/* checksum */
+spd[63] = 0;
+for (i = 0; i < 63; i++) {
+spd[63] += spd[i];
+}
+
+/* copy for SMBUS */
+memcpy(eeprom, spd, sizeof(spd_eeprom.contents));
+}
+
+static void generate_eeprom_serial(uint8_t *eeprom)
+{
+int i, pos = 0;
+uint8_t mac[6] = { 0x00 };
+uint8_t sn[5] = { 0x01, 0x23, 0x45, 0x67, 0x89 };
+
+/* version */
+eeprom[pos++] = 0x01;
+
+/* count */
+eeprom[pos++] = 0x02;
+
+/* MAC address */
+eeprom[pos++] = 0x01; /* MAC */
+eeprom[pos++] = 0x06; /* length */
+memcpy([pos], mac, sizeof(mac));
+pos += sizeof(mac);
+
+/* serial number */
+eeprom[pos++] = 0x02; /* serial */
+eeprom[pos++] = 0x05; /* length */
+memcpy([pos], sn,

Re: [Qemu-devel] [PATCH 15/15] ppc: Add aCube Sam460ex board

2017-08-22 Thread David Gibson 
On Sun, Aug 20, 2017 at 07:23:05PM +0200, BALATON Zoltan wrote:
> Add emulation of aCube Sam460ex board based on AMCC 460EX embedded SoC.
> This is not a full implementation yet with a lot of components still
> missing but enough to start a Linux kernel and the U-Boot firmware.
> 
> Signed-off-by: François Revol 
> Signed-off-by: BALATON Zoltan 

As usual, only fairly superficial review here.

> ---
>  default-configs/ppcemb-softmmu.mak |   3 +
>  hw/ppc/Makefile.objs   |   2 +
>  hw/ppc/sam460ex.c  | 611 
> +
>  3 files changed, 616 insertions(+)
>  create mode 100644 hw/ppc/sam460ex.c
> 
> diff --git a/default-configs/ppcemb-softmmu.mak 
> b/default-configs/ppcemb-softmmu.mak
> index 635923a..90b42f0 100644
> --- a/default-configs/ppcemb-softmmu.mak
> +++ b/default-configs/ppcemb-softmmu.mak
> @@ -17,3 +17,6 @@ CONFIG_XILINX=y
>  CONFIG_XILINX_ETHLITE=y
>  CONFIG_LIBDECNUMBER=y
>  CONFIG_SM501=y
> +CONFIG_USB_EHCI_SYSBUS=y
> +CONFIG_IDE_SII3112=y
> +CONFIG_SAM460EX=y
> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
> index fc39fe4..0aaea5b 100644
> --- a/hw/ppc/Makefile.objs
> +++ b/hw/ppc/Makefile.objs
> @@ -27,3 +27,5 @@ obj-$(CONFIG_E500) += e500.o mpc8544ds.o e500plat.o
>  obj-$(CONFIG_E500) += mpc8544_guts.o ppce500_spin.o
>  # PowerPC 440 Xilinx ML507 reference board.
>  obj-$(CONFIG_XILINX) += virtex_ml507.o
> +# ACube Sam460ex board.
> +obj-$(CONFIG_SAM460EX) += ppc440_uc.o sam460ex.o
> diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
> new file mode 100644
> index 000..7cf4f6f
> --- /dev/null
> +++ b/hw/ppc/sam460ex.c
> @@ -0,0 +1,611 @@
> +/*
> + * QEMU aCube Sam460ex board emulation
> + *
> + * Copyright (c) 2012 François Revol
> + * Copyright (c) 2016-2017 BALATON Zoltan
> + *
> + * This file is derived from hw/ppc440_bamboo.c,
> + * the copyright for that material belongs to the original owners.
> + *
> + * This work is licensed under the GNU GPL license version 2 or later.
> + *
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu-common.h"
> +#include "qemu/cutils.h"
> +#include "qapi/error.h"
> +#include "hw/hw.h"
> +#include "sysemu/blockdev.h"
> +#include "hw/boards.h"
> +#include "sysemu/kvm.h"
> +#include "kvm_ppc.h"
> +#include "sysemu/device_tree.h"
> +#include "sysemu/block-backend.h"
> +#include "hw/loader.h"
> +#include "elf.h"
> +#include "exec/address-spaces.h"
> +#include "exec/memory.h"
> +#include "hw/ppc/ppc440.h"
> +#include "hw/ppc/ppc405.h"
> +#include "hw/block/flash.h"
> +#include "sysemu/sysemu.h"
> +#include "hw/sysbus.h"
> +#include "hw/char/serial.h"
> +#include "hw/i2c/ppc4xx_i2c.h"
> +#include "hw/i2c/smbus.h"
> +#include "hw/usb/hcd-ehci.h"
> +
> +#define BINARY_DEVICE_TREE_FILE "sam460ex.dtb"
> +#define UBOOT_FILENAME "u-boot-sam460-20100605.bin"
> +/* to extract the official U-Boot bin from the updater: */
> +/* dd bs=1 skip=$(($(stat -c '%s' updater/updater-460) - 0x8)) \
> + if=updater/updater-460 of=u-boot-sam460-20100605.bin */
> +
> +/* from Sam460 U-Boot include/configs/Sam460ex.h */
> +#define FLASH_BASE 0xfff0
> +#define FLASH_BASE_H   0x4
> +#define FLASH_SIZE (1 << 20)
> +#define UBOOT_LOAD_BASE0xfff8
> +#define UBOOT_SIZE 0x0008
> +#define UBOOT_ENTRY0xfffc
> +
> +/* from U-Boot */
> +#define EPAPR_MAGIC   (0x45504150)
> +#define KERNEL_ADDR   0x100
> +#define FDT_ADDR  0x180
> +#define RAMDISK_ADDR  0x190
> +
> +/* Sam460ex IRQ MAP:
> +   IRQ0  = ETH_INT
> +   IRQ1  = FPGA_INT
> +   IRQ2  = PCI_INT (PCIA, PCIB, PCIC, PCIB)
> +   IRQ3  = FPGA_INT2
> +   IRQ11 = RTC_INT
> +   IRQ12 = SM502_INT
> +*/
> +
> +#define SDRAM_NR_BANKS 4
> +
> +/* FIXME: See u-boot.git 8ac41e */
> +static const unsigned int ppc460ex_sdram_bank_sizes[] = {
> +1024 << 20, 512 << 20, 256 << 20, 128 << 20, 64 << 20, 32 << 20, 0
> +};
> +
> +struct boot_info {
> +uint32_t dt_base;
> +uint32_t dt_size;
> +uint32_t entry;
> +};
> +
> +/*/
> +/* SPD eeprom content from mips_malta.c */

What's the connection with mips_malta?

> +struct _eeprom24c0x_t {
> +  uint8_t tick;
> +  uint8_t address;
> +  uint8_t command;
> +  uint8_t ack;
> +  uint8_t scl;
> +  uint8_t sda;
> +  uint8_t data;
> +  uint8_t contents[256];
> +};
> +
> +typedef struct _eeprom24c0x_t eeprom24c0x_t;
> +
> +static eeprom24c0x_t spd_eeprom = {
> +.contents = {
> +/* : */ 0x80, 0x08, 0xFF, 0x0D, 0x0A, 0xFF, 0x40, 0x00,
> +/* 0008: */ 0x04, 0x75, 0x54, 0x00, 0x82, 0x08, 0x00, 0x01,
> +/* 0010: */ 0x8F, 0x04, 0x02, 0x01, 0x01, 0x00, 0x00, 0x00,
> +/* 0018: */ 0x00, 0x00, 0x00, 0x14, 0x0F, 0x14, 0x2D, 0xFF,
> +/* 0020: */ 0x15, 0x08, 0x15, 0x08, 0x00, 0x00, 0x00, 0x00,
> +/* 0028: */ 0x00, 0x00,

Re: [Qemu-devel] [PATCH 15/15] ppc: Add aCube Sam460ex board

2017-08-20 Thread Philippe Mathieu-Daudé 

Hi Zoltan,

On 08/20/2017 02:23 PM, BALATON Zoltan wrote:

Add emulation of aCube Sam460ex board based on AMCC 460EX embedded SoC.
This is not a full implementation yet with a lot of components still
missing but enough to start a Linux kernel and the U-Boot firmware.

Signed-off-by: François Revol 
Signed-off-by: BALATON Zoltan 
---
  default-configs/ppcemb-softmmu.mak |   3 +
  hw/ppc/Makefile.objs   |   2 +
  hw/ppc/sam460ex.c  | 611 +
  3 files changed, 616 insertions(+)
  create mode 100644 hw/ppc/sam460ex.c

diff --git a/default-configs/ppcemb-softmmu.mak 
b/default-configs/ppcemb-softmmu.mak
index 635923a..90b42f0 100644
--- a/default-configs/ppcemb-softmmu.mak
+++ b/default-configs/ppcemb-softmmu.mak
@@ -17,3 +17,6 @@ CONFIG_XILINX=y
  CONFIG_XILINX_ETHLITE=y
  CONFIG_LIBDECNUMBER=y
  CONFIG_SM501=y
+CONFIG_USB_EHCI_SYSBUS=y
+CONFIG_IDE_SII3112=y
+CONFIG_SAM460EX=y
diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index fc39fe4..0aaea5b 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -27,3 +27,5 @@ obj-$(CONFIG_E500) += e500.o mpc8544ds.o e500plat.o
  obj-$(CONFIG_E500) += mpc8544_guts.o ppce500_spin.o
  # PowerPC 440 Xilinx ML507 reference board.
  obj-$(CONFIG_XILINX) += virtex_ml507.o
+# ACube Sam460ex board.
+obj-$(CONFIG_SAM460EX) += ppc440_uc.o sam460ex.o
diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
new file mode 100644
index 000..7cf4f6f
--- /dev/null
+++ b/hw/ppc/sam460ex.c
@@ -0,0 +1,611 @@
+/*
+ * QEMU aCube Sam460ex board emulation
+ *
+ * Copyright (c) 2012 François Revol
+ * Copyright (c) 2016-2017 BALATON Zoltan
+ *
+ * This file is derived from hw/ppc440_bamboo.c,
+ * the copyright for that material belongs to the original owners.
+ *
+ * This work is licensed under the GNU GPL license version 2 or later.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "qemu/cutils.h"
+#include "qapi/error.h"
+#include "hw/hw.h"
+#include "sysemu/blockdev.h"
+#include "hw/boards.h"
+#include "sysemu/kvm.h"
+#include "kvm_ppc.h"
+#include "sysemu/device_tree.h"
+#include "sysemu/block-backend.h"
+#include "hw/loader.h"
+#include "elf.h"
+#include "exec/address-spaces.h"
+#include "exec/memory.h"
+#include "hw/ppc/ppc440.h"
+#include "hw/ppc/ppc405.h"
+#include "hw/block/flash.h"
+#include "sysemu/sysemu.h"
+#include "hw/sysbus.h"
+#include "hw/char/serial.h"
+#include "hw/i2c/ppc4xx_i2c.h"
+#include "hw/i2c/smbus.h"
+#include "hw/usb/hcd-ehci.h"
+
+#define BINARY_DEVICE_TREE_FILE "sam460ex.dtb"
+#define UBOOT_FILENAME "u-boot-sam460-20100605.bin"
+/* to extract the official U-Boot bin from the updater: */
+/* dd bs=1 skip=$(($(stat -c '%s' updater/updater-460) - 0x8)) \
+ if=updater/updater-460 of=u-boot-sam460-20100605.bin */
+
+/* from Sam460 U-Boot include/configs/Sam460ex.h */
+#define FLASH_BASE 0xfff0
+#define FLASH_BASE_H   0x4
+#define FLASH_SIZE (1 << 20)
+#define UBOOT_LOAD_BASE0xfff8
+#define UBOOT_SIZE 0x0008
+#define UBOOT_ENTRY0xfffc
+
+/* from U-Boot */
+#define EPAPR_MAGIC   (0x45504150)
+#define KERNEL_ADDR   0x100
+#define FDT_ADDR  0x180
+#define RAMDISK_ADDR  0x190
+
+/* Sam460ex IRQ MAP:
+   IRQ0  = ETH_INT
+   IRQ1  = FPGA_INT
+   IRQ2  = PCI_INT (PCIA, PCIB, PCIC, PCIB)
+   IRQ3  = FPGA_INT2
+   IRQ11 = RTC_INT
+   IRQ12 = SM502_INT
+*/
+
+#define SDRAM_NR_BANKS 4
+
+/* FIXME: See u-boot.git 8ac41e */
+static const unsigned int ppc460ex_sdram_bank_sizes[] = {
+1024 << 20, 512 << 20, 256 << 20, 128 << 20, 64 << 20, 32 << 20, 0
+};
+
+struct boot_info {
+uint32_t dt_base;
+uint32_t dt_size;
+uint32_t entry;
+};
+
+/*/
+/* SPD eeprom content from mips_malta.c */
+
+struct _eeprom24c0x_t {
+  uint8_t tick;
+  uint8_t address;
+  uint8_t command;
+  uint8_t ack;
+  uint8_t scl;
+  uint8_t sda;
+  uint8_t data;
+  uint8_t contents[256];
+};
+
+typedef struct _eeprom24c0x_t eeprom24c0x_t;
+
+static eeprom24c0x_t spd_eeprom = {
+.contents = {
+/* : */ 0x80, 0x08, 0xFF, 0x0D, 0x0A, 0xFF, 0x40, 0x00,
+/* 0008: */ 0x04, 0x75, 0x54, 0x00, 0x82, 0x08, 0x00, 0x01,
+/* 0010: */ 0x8F, 0x04, 0x02, 0x01, 0x01, 0x00, 0x00, 0x00,
+/* 0018: */ 0x00, 0x00, 0x00, 0x14, 0x0F, 0x14, 0x2D, 0xFF,
+/* 0020: */ 0x15, 0x08, 0x15, 0x08, 0x00, 0x00, 0x00, 0x00,
+/* 0028: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+/* 0030: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+/* 0038: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x12, 0xD0,
+/* 0040: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+/* 0048: */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+/* 0050: */ 0x00, 0x00, 0x00,