Re: [Qemu-devel] EXT :Re: Emulating external registers

[Wu, Michael Y [US] (MS)]

Thank you for the suggestions. I found out that the issue was with how the bare 
metal program configured memory.
The program is now able to read and write from a pointer.

I included your unimplemented device into the g3 machine (mac_oldworld.c) I am 
emulating using the following code.
create_unimplemented_device("unimp",0x03400000,(4 << 20));

When I set a pointer to 0x03400000, I can read and write to that location. 
However I have no outputs from the read and write callbacks. I have the '-d 
unimp' set in the command arguments as well.

I added the create_unimplemented_device at the end of the function 
ppc_heathrow_init (mac_oldworld.c). Is my usage correct in adding this device 
to an existing machine?
In unimp.h, the comments mention that the priority is at -1000. Does that mean 
I can set a unimplemented device to a huge address range to pick up any 
read/writes?
 
-----Original Message-----
From: Peter Maydell [mailto:address@hidden 
Sent: Thursday, April 06, 2017 10:38 AM
To: Wu, Michael Y [US] (MS)
Cc: address@hidden
Subject: Re: [Qemu-devel] EXT :Re: Emulating external registers

On 6 April 2017 at 18:23, Wu, Michael Y [US] (MS) <address@hidden> wrote:
> I changed my code to the following and added the appropriate read,write 
> functions and a MemoryRegionOps.
>     memory_region_init_io(reg_memory, NULL, &reg_ops, reg,
>                           "reg_mem", 0x00000040); //set to 64 bytes
>     memory_region_add_subregion(sysmem, 0xFC000000, reg_memory);
>
> For the read function I just returned a zero. So if I were to read from the 
> address 0xFC000000 it should return a value of 0? The current issue I am 
> having is that gdb hangs when the pointer is accessed. I am starting to think 
> my bare-metal program is incorrect. I also added log messages in my read and 
> write functions. The read function was not accessed.

You'll probably find that what has happened is that your program has taken an 
exception which you don't have an exception handler installed for, and has then 
jumped off into nowhere or gone into an infinite loop of taking exceptions. 
(Probably hitting ^c in gdb will break into wherever it is.) It's a good idea 
in bare metal test code to write at least a minimal set of exception handlers 
that can print a message when an unexpected exception occurs and stop, so you 
don't get too confused.

You might also want to investigate QEMU's tracing:
-d in_asm,exec,cpu,int,nochain -D debug.log will write tracing to the debug.log 
file (a lot of it, and this set of trace flags slow down execution a lot, but 
if you're doing very small bare metal flags that should be ok). This can help 
in figuring out what your test program is doing. (Watch out that the in_asm 
shows when we first encounter a block of code, but if we execute the same bit 
of code a second time we'll only print the exec and cpu parts of the logging.)

thanks
-- PMM