Re: Cannot Access Memory

[Jesse Millwood]

Fabiano,

Thanks for the tips!

Right at boot and before anything is continued from gdb, the output of 'info registers' is:

(qemu) info registers

NIP fff80000   LR 00000000 CTR 00000000 XER 00000000 CPU#0

MSR 00000000 HID0 00000000  HF 24000002 iidx 1 didx 1

TB 00000000 00000000 DECR 0

GPR00 0000000000000000 0000000000fffff8 0000000000000000 0000000001800000

GPR04 0000000000000000 0000000000000000 0000000045504150 0000000004000000

GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000

GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000

GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000

GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000

GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000

GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000

CR 00000000  [ -  -  -  -  -  -  -  -  ]             RES ffffffff

FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000

FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000

FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000

FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000

FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000

FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000

FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000

FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000

FPSCR 00000000

SRR0 00000000  SRR1 00000000    PVR 80210022 VRSAVE 00000000

SPRG0 00000000 SPRG1 00000000  SPRG2 00000000  SPRG3 00000000

SPRG4 00000000 SPRG5 00000000  SPRG6 00000000  SPRG7 00000000

CSRR0 00000000 CSRR1 00000000 MCSRR0 00000000 MCSRR1 00000000

  TCR 00000000   TSR 00000000    ESR 00000000   DEAR 00000000

  PIR 00000000 DECAR 00000000   IVPR 00000000   EPCR 00000000

MCSR 00000000 SPRG8 00000000    EPR 00000000

MCAR 00000000  PID1 00000000   PID2 00000000    SVR 00000000

MAS0 00000000  MAS1 00000000   MAS2 00000000   MAS3 00000000

MAS4 00000000  MAS6 00000000   MAS7 00000000    PID 00000000

MMUCFG 00000000 TLB0CFG 04110200 TLB1CFG 101cc010

(qemu) info roms

addr=0000000000000020 size=0x018090 mem=ram name="./srcs/u-boot-vendor/u-boot ELF program header segment 1"

addr=00000000fff80000 size=0x080000 mem=ram name="./srcs/u-boot-vendor/u-boot ELF program header segment 0"

(qemu) x/32xh $pc

fff80000: Cannot access memory

So it looks like it starts up with the NIP being the same as what I see as the entry point to the elf. I can't continue with gdb because it says "Cannot access memory at address 0xfff80000".

I'd say that the general purpose, floating, and condition registers look fine.

I'm looking at the NXP EREF: A Programmer's Reference Manual for e500 core family and it looks like TLB0CFG and TLB1CFG are 64 bit registers. I only see 32 bits here in info registers. The manual only shows the top 32 bits though.

I was looking in the EREF book and it says that "The MMU model for embedded devices assumes that translation is always enabled (there is no real mode)". Is this different than what is implemented in QEMU?

Thanks

----- Original message -----

From: Fabiano Rosas <farosas@linux.ibm.com>

To: Jesse Millwood <jesse_dev@fastmail.com>, qemu-ppc@nongnu.org

Subject: Re: Cannot Access Memory

Date: Tuesday, October 05, 2021 9:08 AM

"Jesse Millwood" <jesse_dev@fastmail.com> writes:

> 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: 

What does 'info registers' say after it hangs? If it cannot access

memory I would expect it to raise an exception to QEMU quite

clearly. Not printing anything suggests it might be stuck in an

exception loop.

The output of 'info roms' might be useful as well, because we need to

see if the place in memory where QEMU loaded uboot is not in conflict

with the elf entry-point. QEMU might also be setting the PC to somewhere

else. The output of 'info registers' before hitting continue in GDB

should tell you what the NIP is set to.

>

> 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 think there are limits to the amount of memory that can be accessed in

Real Mode. Would need to check the relevant PowerISA version for e500v2.

>

> 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