From: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
To: Hollis Blanchard <hollis@penguinppc.org>
Cc: qemu-devel@nongnu.org, kvm-ppc@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH 4/4] ppc4xx: load Bamboo kernel, initrd, and fdt at fixed addresses
Date: Thu, 5 Aug 2010 06:57:21 +0200 [thread overview]
Message-ID: <20100805045721.GA20525@laped.lan> (raw)
In-Reply-To: <1280967697-1875-5-git-send-email-hollis@penguinppc.org>
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
>
>
next prev parent reply other threads:[~2010-08-05 4:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-05 0:21 [Qemu-devel] [PATCH 0/4] fix PowerPC 440 Bamboo platform emulation Hollis Blanchard
2010-08-05 0:21 ` [Qemu-devel] [PATCH 1/4] Fix "make install" with a cross toolchain Hollis Blanchard
2010-08-05 0:21 ` [Qemu-devel] [PATCH 2/4] ppc4xx: correct SDRAM controller warning message condition Hollis Blanchard
2010-08-05 0:21 ` [Qemu-devel] [PATCH 3/4] ppc4xx: don't unregister RAM at reset Hollis Blanchard
2010-08-05 0:21 ` [Qemu-devel] [PATCH 4/4] ppc4xx: load Bamboo kernel, initrd, and fdt at fixed addresses Hollis Blanchard
2010-08-05 4:57 ` Edgar E. Iglesias [this message]
2010-08-06 2:39 ` [Qemu-devel] " Liu Yu-B13201
2010-08-06 17:55 ` [Qemu-devel] " Hollis Blanchard
2010-08-06 18:12 ` Edgar E. Iglesias
2010-08-05 5:01 ` [Qemu-devel] [PATCH 0/4] fix PowerPC 440 Bamboo platform emulation Edgar E. Iglesias
2010-08-19 17:24 ` [Qemu-devel] " Hollis Blanchard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100805045721.GA20525@laped.lan \
--to=edgar.iglesias@gmail.com \
--cc=hollis@penguinppc.org \
--cc=kvm-ppc@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).