qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Cannot Access Memory


From: Jesse Millwood
Subject: Cannot Access Memory
Date: Mon, 04 Oct 2021 17:47:41 -0400
User-agent: Cyrus-JMAP/3.5.0-alpha0-1322-g921842b88a-fm-20210929.001-g921842b8

Hello,

I am a bit new to PowerPC and the guts of QEMU. Long time user, first time source diver. I am trying to boot up a uboot image provided by a vendor that uses the e500 cores. The entry point to the U-boot elf seems to be in a region where I can not access the memory. 

I am invoking qemu 6.1 like so:
qemu-system-ppc -monitor stdio -M ppce500 -cpu e500v2 -smp 2 -m 4G -bios ./srcs/u-boot-vendor/u-boot -s -S

The entry point to the vendor elf is in a high address at 0xfff80000.
When I run it at first it doesn't print anything out. When I have it stopped and investigate the memory with gdb I get a message that it cannot access memory there:

gdb>  x/32xh $pc
0xfff80000 <_start>: Cannot access memory at address 0xfff80000

When I investigate with the qemu monitor I find the boundary where the memory is inaccessible:
(qemu) x/32xh 0x0
0000000000000000: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
0000000000000010: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
0000000000000020: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
0000000000000030: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
(qemu) x/32xh 0x3fffff0
03fffff0: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
04000000: Cannot access memory

With "info mtree" I can see that this should be a fine location that resides in RAM:
(qemu) info mtree
address-space: memory
  0000000000000000-ffffffffffffffff (prio 0, i/o): system
    0000000000000000-00000000ffffffff (prio 0, ram): mpc8544ds.ram
    0000000f00000000-0000000f07ffffff (prio 0, i/o): platform bus
    0000000fe0000000-0000000fe00fffff (prio 0, i/o): e500-ccsr
      0000000fe0003000-0000000fe0003013 (prio 0, i/o): mpc-i2c
      0000000fe0004500-0000000fe0004507 (prio 0, i/o): serial
      0000000fe0008000-0000000fe0008fff (prio 0, i/o): pci-container
        0000000fe0008000-0000000fe0008003 (prio 0, i/o): pci-conf-idx
        0000000fe0008004-0000000fe0008007 (prio 0, i/o): pci-conf-data
        0000000fe0008c00-0000000fe0008fff (prio 0, i/o): pci.reg
      0000000fe0040000-0000000fe007ffff (prio 0, i/o): openpic
        0000000fe0040000-0000000fe00410ef (prio 0, i/o): glb
        0000000fe00410f0-0000000fe004130f (prio 0, i/o): tmr
        0000000fe0041600-0000000fe00417ff (prio 0, i/o): msi
        0000000fe0043800-0000000fe0043fff (prio 0, i/o): summary
        0000000fe0050000-0000000fe0051fff (prio 0, i/o): src
        0000000fe0060000-0000000fe007f0ff (prio 0, i/o): cpu
      0000000fe00e0000-0000000fe00e0fff (prio 0, i/o): mpc8544.guts
      0000000fe00ff000-0000000fe00fffff (prio 0, i/o): mpc8xxx_gpio
    0000000fef000000-0000000fef0003ff (prio 0, i/o): e500 spin pv device

I can successfully run the u-boot for the qemu machine and do notice that it's entry point is quite a bit lower, at 0xf00000. This is fine and all but I don't understand why I cannot access the 4GiB of memory that I invoked qemu with at the beginning.

I am not uncomfortable diving into the source and tweaking some things to increase the accessible memory for my platform. Does anyone have any pointers as to how to let the e500plat machine load a u-boot binary to a higher address? From poking around in the source it looks like the "memory_region_add_subregion" call in e500.c is allocating memory from 0 to the size that the ram is. Are there other size constraints hard coded somewhere? I've used 4GB of ram on other platforms.

Thanks for any pointers,
Jesse

reply via email to

[Prev in Thread] Current Thread [Next in Thread]