[PATCH 0/4] fix PowerPC 440 Bamboo platform emulation

[PATCH 0/4] fix PowerPC 440 Bamboo platform emulation

[Hollis Blanchard]

These patches get the PowerPC Bamboo platform working again. I've re-written
two of the patches based on feedback from qemu-devel.

Note that this platform still only works in conjunction with KVM, since the
PowerPC 440 MMU is still not accurately emulated by TCG.

[PATCH 1/4] Fix "make install" with a cross toolchain

[Hollis Blanchard]

We must be able to use a non-native strip executable, but not all
versions of 'install' support the --strip-program option (e.g.
OpenBSD). Accordingly, we can't use 'install -s', and we must run strip
separately.

Signed-off-by: Hollis Blanchard <hollis@penguinppc.org>
Cc: blauwirbel@gmail.com
---
 Makefile.target |    5 ++++-
 configure       |    4 +++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 8a9c427..00bf6f9 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -326,7 +326,10 @@ clean:
 
 install: all
 ifneq ($(PROGS),)
-	$(INSTALL) -m 755 $(STRIP_OPT) $(PROGS) "$(DESTDIR)$(bindir)"
+	$(INSTALL) -m 755 $(PROGS) "$(DESTDIR)$(bindir)"
+ifneq ($(STRIP),)
+	$(STRIP) $(patsubst %,"$(DESTDIR)$(bindir)/%",$(PROGS))
+endif
 endif
 
 # Include automatically generated dependency files
diff --git a/configure b/configure
index a20371c..146dac0 100755
--- a/configure
+++ b/configure
@@ -80,6 +80,7 @@ make="make"
 install="install"
 objcopy="objcopy"
 ld="ld"
+strip="strip"
 helper_cflags=""
 libs_softmmu=""
 libs_tools=""
@@ -125,6 +126,7 @@ cc="${cross_prefix}${cc}"
 ar="${cross_prefix}${ar}"
 objcopy="${cross_prefix}${objcopy}"
 ld="${cross_prefix}${ld}"
+strip="${cross_prefix}${strip}"
 
 # default flags for all hosts
 QEMU_CFLAGS="-fno-strict-aliasing $QEMU_CFLAGS"
@@ -2227,7 +2229,7 @@ if test "$debug" = "yes" ; then
   echo "CONFIG_DEBUG_EXEC=y" >> $config_host_mak
 fi
 if test "$strip_opt" = "yes" ; then
-  echo "STRIP_OPT=-s" >> $config_host_mak
+  echo "STRIP=${strip}" >> $config_host_mak
 fi
 if test "$bigendian" = "yes" ; then
   echo "HOST_WORDS_BIGENDIAN=y" >> $config_host_mak
-- 
1.7.2

[PATCH 2/4] ppc4xx: correct SDRAM controller warning message condition

[Hollis Blanchard]

The message "Truncating memory to %d MiB to fit SDRAM controller limits"
should be displayed only when a user chooses an amount of RAM which
can't be represented by the PPC 4xx SDRAM controller (e.g. 129MB, which
would only be valid if the controller supports a bank size of 1MB).

Signed-off-by: Hollis Blanchard <hollis@penguinppc.org>
---
 hw/ppc4xx_devs.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/ppc4xx_devs.c b/hw/ppc4xx_devs.c
index b15db81..be130c4 100644
--- a/hw/ppc4xx_devs.c
+++ b/hw/ppc4xx_devs.c
@@ -684,7 +684,7 @@ ram_addr_t ppc4xx_sdram_adjust(ram_addr_t ram_size, int nr_banks,
     }
 
     ram_size -= size_left;
-    if (ram_size)
+    if (size_left)
         printf("Truncating memory to %d MiB to fit SDRAM controller limits.\n",
                (int)(ram_size >> 20));
 
-- 
1.7.2

[PATCH 3/4] ppc4xx: don't unregister RAM at reset

[Hollis Blanchard]

The PowerPC 4xx SDRAM controller emulation unregisters RAM in its reset
callback. However, qemu_system_reset() is now called at initialization
time, so all RAM is unregistered before starting the guest (!).

Signed-off-by: Hollis Blanchard <hollis@penguinppc.org>

---
 hw/ppc4xx_devs.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

This fixes a critical bug in PowerPC 440 Bamboo board emulation.

diff --git a/hw/ppc4xx_devs.c b/hw/ppc4xx_devs.c
index be130c4..7f698b8 100644
--- a/hw/ppc4xx_devs.c
+++ b/hw/ppc4xx_devs.c
@@ -619,7 +619,6 @@ static void sdram_reset (void *opaque)
     /* We pre-initialize RAM banks */
     sdram->status = 0x00000000;
     sdram->cfg = 0x00800000;
-    sdram_unmap_bcr(sdram);
 }
 
 void ppc4xx_sdram_init (CPUState *env, qemu_irq irq, int nbanks,
-- 
1.7.2

[PATCH 4/4] ppc4xx: load Bamboo kernel, initrd, and fdt at fixed addresses

[Hollis Blanchard]

We can't use the return value of load_uimage() for the kernel because it
can't account for BSS size, and the PowerPC kernel does not relocate
blobs before zeroing BSS.

Instead, we now load at the fixed addresses chosen by u-boot (the normal
firmware for the board).

Signed-off-by: Hollis Blanchard <hollis@penguinppc.org>

---
 hw/ppc440_bamboo.c |   39 ++++++++++++++++++---------------------
 1 files changed, 18 insertions(+), 21 deletions(-)

This fixes a critical bug in PowerPC 440 Bamboo board emulation.

diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c
index d471d5d..34ddf45 100644
--- a/hw/ppc440_bamboo.c
+++ b/hw/ppc440_bamboo.c
@@ -27,6 +27,11 @@
 
 #define BINARY_DEVICE_TREE_FILE "bamboo.dtb"
 
+/* from u-boot */
+#define KERNEL_ADDR  0x1000000
+#define FDT_ADDR     0x1800000
+#define RAMDISK_ADDR 0x1900000
+
 static int bamboo_load_device_tree(target_phys_addr_t addr,
                                      uint32_t ramsize,
                                      target_phys_addr_t initrd_base,
@@ -98,10 +103,8 @@ static void bamboo_init(ram_addr_t ram_size,
     uint64_t elf_lowaddr;
     target_phys_addr_t entry = 0;
     target_phys_addr_t loadaddr = 0;
-    target_long kernel_size = 0;
-    target_ulong initrd_base = 0;
     target_long initrd_size = 0;
-    target_ulong dt_base = 0;
+    int success;
     int i;
 
     /* Setup CPU. */
@@ -118,15 +121,15 @@ static void bamboo_init(ram_addr_t ram_size,
 
     /* Load kernel. */
     if (kernel_filename) {
-        kernel_size = load_uimage(kernel_filename, &entry, &loadaddr, NULL);
-        if (kernel_size < 0) {
-            kernel_size = load_elf(kernel_filename, NULL, NULL, &elf_entry,
-                                   &elf_lowaddr, NULL, 1, ELF_MACHINE, 0);
+        success = load_uimage(kernel_filename, &entry, &loadaddr, NULL);
+        if (success < 0) {
+            success = load_elf(kernel_filename, NULL, NULL, &elf_entry,
+                               &elf_lowaddr, NULL, 1, ELF_MACHINE, 0);
             entry = elf_entry;
             loadaddr = elf_lowaddr;
         }
         /* XXX try again as binary */
-        if (kernel_size < 0) {
+        if (success < 0) {
             fprintf(stderr, "qemu: could not load kernel '%s'\n",
                     kernel_filename);
             exit(1);
@@ -135,26 +138,20 @@ static void bamboo_init(ram_addr_t ram_size,
 
     /* Load initrd. */
     if (initrd_filename) {
-        initrd_base = kernel_size + loadaddr;
-        initrd_size = load_image_targphys(initrd_filename, initrd_base,
-                                          ram_size - initrd_base);
+        initrd_size = load_image_targphys(initrd_filename, RAMDISK_ADDR,
+                                          ram_size - RAMDISK_ADDR);
 
         if (initrd_size < 0) {
-            fprintf(stderr, "qemu: could not load initial ram disk '%s'\n",
-                    initrd_filename);
+            fprintf(stderr, "qemu: could not load ram disk '%s' at %x\n",
+                    initrd_filename, RAMDISK_ADDR);
             exit(1);
         }
     }
 
     /* If we're loading a kernel directly, we must load the device tree too. */
     if (kernel_filename) {
-        if (initrd_base)
-            dt_base = initrd_base + initrd_size;
-        else
-            dt_base = kernel_size + loadaddr;
-
-        if (bamboo_load_device_tree(dt_base, ram_size,
-                        initrd_base, initrd_size, kernel_cmdline) < 0) {
+        if (bamboo_load_device_tree(FDT_ADDR, ram_size, RAMDISK_ADDR,
+                                    initrd_size, kernel_cmdline) < 0) {
             fprintf(stderr, "couldn't load device tree\n");
             exit(1);
         }
@@ -163,7 +160,7 @@ static void bamboo_init(ram_addr_t ram_size,
 
         /* Set initial guest state. */
         env->gpr[1] = (16<<20) - 8;
-        env->gpr[3] = dt_base;
+        env->gpr[3] = FDT_ADDR;
         env->nip = entry;
         /* XXX we currently depend on KVM to create some initial TLB entries. */
     }
-- 
1.7.2

Re: [Qemu-devel] [PATCH 4/4] ppc4xx: load Bamboo kernel, initrd,

[Edgar E. Iglesias]

On Wed, Aug 04, 2010 at 05:21:37PM -0700, Hollis Blanchard wrote:
> We can't use the return value of load_uimage() for the kernel because it
> can't account for BSS size, and the PowerPC kernel does not relocate
> blobs before zeroing BSS.
> 
> Instead, we now load at the fixed addresses chosen by u-boot (the normal
> firmware for the board).
> 
> Signed-off-by: Hollis Blanchard <hollis@penguinppc.org>


This looks good to me, thanks Hollis.

Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>


> 
> ---
>  hw/ppc440_bamboo.c |   39 ++++++++++++++++++---------------------
>  1 files changed, 18 insertions(+), 21 deletions(-)
> 
> This fixes a critical bug in PowerPC 440 Bamboo board emulation.
> 
> diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c
> index d471d5d..34ddf45 100644
> --- a/hw/ppc440_bamboo.c
> +++ b/hw/ppc440_bamboo.c
> @@ -27,6 +27,11 @@
>  
>  #define BINARY_DEVICE_TREE_FILE "bamboo.dtb"
>  
> +/* from u-boot */
> +#define KERNEL_ADDR  0x1000000
> +#define FDT_ADDR     0x1800000
> +#define RAMDISK_ADDR 0x1900000
> +
>  static int bamboo_load_device_tree(target_phys_addr_t addr,
>                                       uint32_t ramsize,
>                                       target_phys_addr_t initrd_base,
> @@ -98,10 +103,8 @@ static void bamboo_init(ram_addr_t ram_size,
>      uint64_t elf_lowaddr;
>      target_phys_addr_t entry = 0;
>      target_phys_addr_t loadaddr = 0;
> -    target_long kernel_size = 0;
> -    target_ulong initrd_base = 0;
>      target_long initrd_size = 0;
> -    target_ulong dt_base = 0;
> +    int success;
>      int i;
>  
>      /* Setup CPU. */
> @@ -118,15 +121,15 @@ static void bamboo_init(ram_addr_t ram_size,
>  
>      /* Load kernel. */
>      if (kernel_filename) {
> -        kernel_size = load_uimage(kernel_filename, &entry, &loadaddr, NULL);
> -        if (kernel_size < 0) {
> -            kernel_size = load_elf(kernel_filename, NULL, NULL, &elf_entry,
> -                                   &elf_lowaddr, NULL, 1, ELF_MACHINE, 0);
> +        success = load_uimage(kernel_filename, &entry, &loadaddr, NULL);
> +        if (success < 0) {
> +            success = load_elf(kernel_filename, NULL, NULL, &elf_entry,
> +                               &elf_lowaddr, NULL, 1, ELF_MACHINE, 0);
>              entry = elf_entry;
>              loadaddr = elf_lowaddr;
>          }
>          /* XXX try again as binary */
> -        if (kernel_size < 0) {
> +        if (success < 0) {
>              fprintf(stderr, "qemu: could not load kernel '%s'\n",
>                      kernel_filename);
>              exit(1);
> @@ -135,26 +138,20 @@ static void bamboo_init(ram_addr_t ram_size,
>  
>      /* Load initrd. */
>      if (initrd_filename) {
> -        initrd_base = kernel_size + loadaddr;
> -        initrd_size = load_image_targphys(initrd_filename, initrd_base,
> -                                          ram_size - initrd_base);
> +        initrd_size = load_image_targphys(initrd_filename, RAMDISK_ADDR,
> +                                          ram_size - RAMDISK_ADDR);
>  
>          if (initrd_size < 0) {
> -            fprintf(stderr, "qemu: could not load initial ram disk '%s'\n",
> -                    initrd_filename);
> +            fprintf(stderr, "qemu: could not load ram disk '%s' at %x\n",
> +                    initrd_filename, RAMDISK_ADDR);
>              exit(1);
>          }
>      }
>  
>      /* If we're loading a kernel directly, we must load the device tree too. */
>      if (kernel_filename) {
> -        if (initrd_base)
> -            dt_base = initrd_base + initrd_size;
> -        else
> -            dt_base = kernel_size + loadaddr;
> -
> -        if (bamboo_load_device_tree(dt_base, ram_size,
> -                        initrd_base, initrd_size, kernel_cmdline) < 0) {
> +        if (bamboo_load_device_tree(FDT_ADDR, ram_size, RAMDISK_ADDR,
> +                                    initrd_size, kernel_cmdline) < 0) {
>              fprintf(stderr, "couldn't load device tree\n");
>              exit(1);
>          }
> @@ -163,7 +160,7 @@ static void bamboo_init(ram_addr_t ram_size,
>  
>          /* Set initial guest state. */
>          env->gpr[1] = (16<<20) - 8;
> -        env->gpr[3] = dt_base;
> +        env->gpr[3] = FDT_ADDR;
>          env->nip = entry;
>          /* XXX we currently depend on KVM to create some initial TLB entries. */
>      }
> -- 
> 1.7.2
> 
> 

RE: [PATCH 4/4] ppc4xx: load Bamboo kernel, initrd, and fdt at fixed addresses

[Liu Yu-B13201]

 

> -----Original Message-----
> From: kvm-ppc-owner@vger.kernel.org 
> [mailto:kvm-ppc-owner@vger.kernel.org] On Behalf Of Hollis Blanchard
> Sent: Thursday, August 05, 2010 8:22 AM
> To: qemu-devel@nongnu.org
> Cc: kvm-ppc@vger.kernel.org
> Subject: [PATCH 4/4] ppc4xx: load Bamboo kernel, initrd, and 
> fdt at fixed addresses
> 
> We can't use the return value of load_uimage() for the kernel 
> because it
> can't account for BSS size, and the PowerPC kernel does not relocate
> blobs before zeroing BSS.
> 
> Instead, we now load at the fixed addresses chosen by u-boot 
> (the normal
> firmware for the board).
> 

Hollis,

What will us do if the uImage become bigger and fixed size is not
enough?


Yu

Re: [PATCH 4/4] ppc4xx: load Bamboo kernel, initrd, and fdt at fixed

[Hollis Blanchard]

On Thu, Aug 5, 2010 at 7:39 PM, Liu Yu-B13201 <B13201@freescale.com> wrote:
>
>
>> -----Original Message-----
>> From: kvm-ppc-owner@vger.kernel.org
>> [mailto:kvm-ppc-owner@vger.kernel.org] On Behalf Of Hollis Blanchard
>> Sent: Thursday, August 05, 2010 8:22 AM
>> To: qemu-devel@nongnu.org
>> Cc: kvm-ppc@vger.kernel.org
>> Subject: [PATCH 4/4] ppc4xx: load Bamboo kernel, initrd, and
>> fdt at fixed addresses
>>
>> We can't use the return value of load_uimage() for the kernel
>> because it
>> can't account for BSS size, and the PowerPC kernel does not relocate
>> blobs before zeroing BSS.
>>
>> Instead, we now load at the fixed addresses chosen by u-boot
>> (the normal
>> firmware for the board).
>>
>
> What will us do if the uImage become bigger and fixed size is not
> enough?

That was my question to Edgar, which was not answered. In u-boot, one
would change some environment variables. With this code in qemu, the
only recourse would be to edit ppc440_bamboo.c and rebuild.

Perhaps in the future we can do something more sophisticated by
specifying load addresses in a qemu device tree, but I don't
understand that stuff enough to know if that is an intended use.

-Hollis

Re: [Qemu-devel] Re: [PATCH 4/4] ppc4xx: load Bamboo kernel,

[Edgar E. Iglesias]

On Fri, Aug 06, 2010 at 10:55:36AM -0700, Hollis Blanchard wrote:
> On Thu, Aug 5, 2010 at 7:39 PM, Liu Yu-B13201 <B13201@freescale.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: kvm-ppc-owner@vger.kernel.org
> >> [mailto:kvm-ppc-owner@vger.kernel.org] On Behalf Of Hollis Blanchard
> >> Sent: Thursday, August 05, 2010 8:22 AM
> >> To: qemu-devel@nongnu.org
> >> Cc: kvm-ppc@vger.kernel.org
> >> Subject: [PATCH 4/4] ppc4xx: load Bamboo kernel, initrd, and
> >> fdt at fixed addresses
> >>
> >> We can't use the return value of load_uimage() for the kernel
> >> because it
> >> can't account for BSS size, and the PowerPC kernel does not relocate
> >> blobs before zeroing BSS.
> >>
> >> Instead, we now load at the fixed addresses chosen by u-boot
> >> (the normal
> >> firmware for the board).
> >>
> >
> > What will us do if the uImage become bigger and fixed size is not
> > enough?
> 
> That was my question to Edgar, which was not answered. In u-boot, one
> would change some environment variables. With this code in qemu, the
> only recourse would be to edit ppc440_bamboo.c and rebuild.

My objection to the first patch was mainly about putting ppc related
magics into the generic load_uimage call. If you want to do clever
things in the ppc bootloading code, that may be fine, but in IMO you
should try to mimic the uboot behaviour as much as possible when loading
uimages.

Cheers

Re: [Qemu-devel] [PATCH 0/4] fix PowerPC 440 Bamboo platform

[Edgar E. Iglesias]

On Wed, Aug 04, 2010 at 05:21:33PM -0700, Hollis Blanchard wrote:
> These patches get the PowerPC Bamboo platform working again. I've re-written
> two of the patches based on feedback from qemu-devel.
> 
> Note that this platform still only works in conjunction with KVM, since the
> PowerPC 440 MMU is still not accurately emulated by TCG.

Is that the Book-E MMU?

In case it is, I've got a couple of fairly ugly patches somewhere that
at least made it possible for me to boot linux on a TCG emulated
ppc 440. I'll see if I can dig them out and post them.

Cheers

Re: [PATCH 0/4] fix PowerPC 440 Bamboo platform emulation

[Hollis Blanchard]

On 08/04/2010 05:21 PM, Hollis Blanchard wrote:
> These patches get the PowerPC Bamboo platform working again. I've re-written
> two of the patches based on feedback from qemu-devel.

Hi Aurelien, any comment on these?


Hollis Blanchard
Mentor Graphics, Embedded Systems Division