Re: Cannot Access Memory

[Fabiano Rosas]

"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