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:peter.mayd...@linaro.org] Sent: Thursday, April 06, 2017 10:38 AM To: Wu, Michael Y [US] (MS) Cc: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] EXT :Re: Emulating external registers On 6 April 2017 at 18:23, Wu, Michael Y [US] (MS) <michael...@ngc.com> 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, ®_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