* [Qemu-devel] Initializing PC from memory on reset? @ 2011-11-23 23:59 Andreas Färber 2011-11-24 7:47 ` Peter Maydell 2011-11-25 16:25 ` [Qemu-devel] Memory read/write issues (was: Initializing PC from memory on reset?) Andreas Färber 0 siblings, 2 replies; 8+ messages in thread From: Andreas Färber @ 2011-11-23 23:59 UTC (permalink / raw) To: qemu-devel Developers Hi, Unlike PowerPC, an architecture that I'm trying to emulate does not store branch instructions in the reset vector but a memory address. I'm therefore trying to read physical address 0x00000 and store its value into my env->pc. I've verified by running with -S that xp /xh 0x00000 shows the expected value. When doing lduw_phys(0x00000) or cpu_read_physical_memory() in the CPU reset function though, I just seem to read from uninitialized memory (0xbaba). I've taken care to reorder CPU initialization to after the BIOS file is loaded in the machine initialization function. What am I doing wrong? Thanks, Andreas ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Initializing PC from memory on reset? 2011-11-23 23:59 [Qemu-devel] Initializing PC from memory on reset? Andreas Färber @ 2011-11-24 7:47 ` Peter Maydell 2011-11-24 21:24 ` Andreas Färber 2011-11-25 16:25 ` [Qemu-devel] Memory read/write issues (was: Initializing PC from memory on reset?) Andreas Färber 1 sibling, 1 reply; 8+ messages in thread From: Peter Maydell @ 2011-11-24 7:47 UTC (permalink / raw) To: Andreas Färber; +Cc: qemu-devel Developers On 23 November 2011 23:59, Andreas Färber <andreas.faerber@web.de> wrote: > Unlike PowerPC, an architecture that I'm trying to emulate does not > store branch instructions in the reset vector but a memory address. I'm > therefore trying to read physical address 0x00000 and store its value > into my env->pc. Have you looked at how M profile ARM does it? That has a similar "read memory for initial PC value". (There are some interesting wrinkles, not all of which we get quite right, regarding how this should interact with initial ELF image load and the user fiddling with PC and RAM in an attached debugger.) -- PMM ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Initializing PC from memory on reset? 2011-11-24 7:47 ` Peter Maydell @ 2011-11-24 21:24 ` Andreas Färber 0 siblings, 0 replies; 8+ messages in thread From: Andreas Färber @ 2011-11-24 21:24 UTC (permalink / raw) To: Peter Maydell; +Cc: qemu-devel Developers Am 24.11.2011 08:47, schrieb Peter Maydell: > On 23 November 2011 23:59, Andreas Färber <andreas.faerber@web.de> wrote: >> Unlike PowerPC, an architecture that I'm trying to emulate does not >> store branch instructions in the reset vector but a memory address. I'm >> therefore trying to read physical address 0x00000 and store its value >> into my env->pc. > > Have you looked at how M profile ARM does it? That has a similar > "read memory for initial PC value". (There are some interesting > wrinkles, not all of which we get quite right, regarding how this > should interact with initial ELF image load and the user fiddling > with PC and RAM in an attached debugger.) Thanks. I thought I had seen something like that but apparently grep'ed for the wrong keywords. Can anyone enlighten me why rom_ptr()+lduw_p() works at this point in time and lduw_phys() doesn't but later does? The MemoryRegion is initialized as a ram area. Is this a legacy issue (pre-Memory API)? Andreas ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Qemu-devel] Memory read/write issues (was: Initializing PC from memory on reset?) 2011-11-23 23:59 [Qemu-devel] Initializing PC from memory on reset? Andreas Färber 2011-11-24 7:47 ` Peter Maydell @ 2011-11-25 16:25 ` Andreas Färber 2011-11-27 8:32 ` [Qemu-devel] Memory read/write issues Avi Kivity 1 sibling, 1 reply; 8+ messages in thread From: Andreas Färber @ 2011-11-25 16:25 UTC (permalink / raw) To: qemu-devel Developers; +Cc: Avi Kivity, Alexander Graf Am 24.11.2011 00:59, schrieb Andreas Färber: > Unlike PowerPC, an architecture that I'm trying to emulate does not > store branch instructions in the reset vector but a memory address. I'm > therefore trying to read physical address 0x00000 and store its value > into my env->pc. > > I've verified by running with -S that xp /xh 0x00000 shows the expected > value. > > When doing lduw_phys(0x00000) or cpu_read_physical_memory() in the CPU > reset function though, I just seem to read from uninitialized memory > (0xbaba). I've taken care to reorder CPU initialization to after the > BIOS file is loaded in the machine initialization function. Another weird memory issue is that tcg_gen_qemu_st16() succeeds but the value stored doesn't show up with xp or x on the monitor but 0x0000. MOVW 0xf8,#0xfee0 (at 0x02010) is trying to write 0xfee0 to 0xFFFf8. Similarly, a subsequent tcg_gen_qemu_ld16u() reads 0x0000 from there. TCG snippet: https://github.com/afaerber/qemu-rl78/commit/d3880bd53a26d224c56d16a6ea5950019d411cf0 uint8_t sfrp = ldub_code(s->pc + 1) & ~0x1; uint16_t data = lduw_code(s->pc + 2); LOG_DISAS("MOVW 0x%" PRIx8 ",#0x%04" PRIx16 "\n", sfrp, data); TCGv addr = tcg_const_tl(0xFFF00 | sfrp); TCGv_i32 val = tcg_const_i32(data); tcg_gen_qemu_st16(val, addr, 0); /* for testing: */ tcg_gen_qemu_ld16u(env_sp, addr, 0); tcg_temp_free(addr); tcg_temp_free(val); (qemu) info mtree memory 00000000-fffffffe (prio 0): system 00000000-0000ffff (prio 0): rl78g13_pb.code_flash 000fef00-000ffeff (prio 0): rl78g13_pb.ram 000ffee0-000ffeff (prio 0): rl78g13_pb.gpr 000fff00-000fffff (prio 0): rl78g13_pb.sfr https://github.com/afaerber/qemu-rl78/blob/d3880bd53a26d224c56d16a6ea5950019d411cf0/hw/rl78g13_pb.c#L88 memory_region_init_ram(sfr, NULL, "rl78g13_pb.sfr", 256); memory_region_add_subregion(get_system_memory(), 0xFFF00, sfr); Anything obvious that I'm missing? Thanks, Andreas ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Memory read/write issues 2011-11-25 16:25 ` [Qemu-devel] Memory read/write issues (was: Initializing PC from memory on reset?) Andreas Färber @ 2011-11-27 8:32 ` Avi Kivity 2011-11-27 14:07 ` Andreas Färber 0 siblings, 1 reply; 8+ messages in thread From: Avi Kivity @ 2011-11-27 8:32 UTC (permalink / raw) To: Andreas Färber; +Cc: qemu-devel Developers, Alexander Graf On 11/25/2011 06:25 PM, Andreas Färber wrote: > Am 24.11.2011 00:59, schrieb Andreas Färber: > > Unlike PowerPC, an architecture that I'm trying to emulate does not > > store branch instructions in the reset vector but a memory address. I'm > > therefore trying to read physical address 0x00000 and store its value > > into my env->pc. > > > > I've verified by running with -S that xp /xh 0x00000 shows the expected > > value. > > > > When doing lduw_phys(0x00000) or cpu_read_physical_memory() in the CPU > > reset function though, I just seem to read from uninitialized memory > > (0xbaba). I've taken care to reorder CPU initialization to after the > > BIOS file is loaded in the machine initialization function. > > Another weird memory issue is that tcg_gen_qemu_st16() succeeds but the > value stored doesn't show up with xp or x on the monitor but 0x0000. > > MOVW 0xf8,#0xfee0 (at 0x02010) is trying to write 0xfee0 to 0xFFFf8. > > Similarly, a subsequent tcg_gen_qemu_ld16u() reads 0x0000 from there. > > TCG snippet: > https://github.com/afaerber/qemu-rl78/commit/d3880bd53a26d224c56d16a6ea5950019d411cf0 > > uint8_t sfrp = ldub_code(s->pc + 1) & ~0x1; > uint16_t data = lduw_code(s->pc + 2); > LOG_DISAS("MOVW 0x%" PRIx8 ",#0x%04" PRIx16 "\n", sfrp, data); > TCGv addr = tcg_const_tl(0xFFF00 | sfrp); > TCGv_i32 val = tcg_const_i32(data); > tcg_gen_qemu_st16(val, addr, 0); > > /* for testing: */ > tcg_gen_qemu_ld16u(env_sp, addr, 0); > > tcg_temp_free(addr); > tcg_temp_free(val); > > (qemu) info mtree > memory > 00000000-fffffffe (prio 0): system > 00000000-0000ffff (prio 0): rl78g13_pb.code_flash > 000fef00-000ffeff (prio 0): rl78g13_pb.ram > 000ffee0-000ffeff (prio 0): rl78g13_pb.gpr > 000fff00-000fffff (prio 0): rl78g13_pb.sfr > > https://github.com/afaerber/qemu-rl78/blob/d3880bd53a26d224c56d16a6ea5950019d411cf0/hw/rl78g13_pb.c#L88 > > memory_region_init_ram(sfr, NULL, "rl78g13_pb.sfr", 256); > memory_region_add_subregion(get_system_memory(), 0xFFF00, sfr); > > Anything obvious that I'm missing? This region is a little special in that it is a subpage RAM region, so it doesn't follow the normal paths where RAM is mapped directly to the guest. Maybe there's some bug in that area. If the target is big endian that could further complicate things. -- error compiling committee.c: too many arguments to function ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Memory read/write issues 2011-11-27 8:32 ` [Qemu-devel] Memory read/write issues Avi Kivity @ 2011-11-27 14:07 ` Andreas Färber 2011-11-27 14:17 ` Avi Kivity 0 siblings, 1 reply; 8+ messages in thread From: Andreas Färber @ 2011-11-27 14:07 UTC (permalink / raw) To: Avi Kivity; +Cc: qemu-devel Developers Am 27.11.2011 09:32, schrieb Avi Kivity: > On 11/25/2011 06:25 PM, Andreas Färber wrote: >> Am 24.11.2011 00:59, schrieb Andreas Färber: >>> Unlike PowerPC, an architecture that I'm trying to emulate does not >>> store branch instructions in the reset vector but a memory address. I'm >>> therefore trying to read physical address 0x00000 and store its value >>> into my env->pc. >>> >>> I've verified by running with -S that xp /xh 0x00000 shows the expected >>> value. >>> >>> When doing lduw_phys(0x00000) or cpu_read_physical_memory() in the CPU >>> reset function though, I just seem to read from uninitialized memory >>> (0xbaba). I've taken care to reorder CPU initialization to after the >>> BIOS file is loaded in the machine initialization function. >> >> Another weird memory issue is that tcg_gen_qemu_st16() succeeds but the >> value stored doesn't show up with xp or x on the monitor but 0x0000. >> >> MOVW 0xf8,#0xfee0 (at 0x02010) is trying to write 0xfee0 to 0xFFFf8. >> >> Similarly, a subsequent tcg_gen_qemu_ld16u() reads 0x0000 from there. >> >> TCG snippet: >> https://github.com/afaerber/qemu-rl78/commit/d3880bd53a26d224c56d16a6ea5950019d411cf0 >> >> uint8_t sfrp = ldub_code(s->pc + 1) & ~0x1; >> uint16_t data = lduw_code(s->pc + 2); >> LOG_DISAS("MOVW 0x%" PRIx8 ",#0x%04" PRIx16 "\n", sfrp, data); >> TCGv addr = tcg_const_tl(0xFFF00 | sfrp); >> TCGv_i32 val = tcg_const_i32(data); >> tcg_gen_qemu_st16(val, addr, 0); >> >> /* for testing: */ >> tcg_gen_qemu_ld16u(env_sp, addr, 0); >> >> tcg_temp_free(addr); >> tcg_temp_free(val); >> >> (qemu) info mtree >> memory >> 00000000-fffffffe (prio 0): system >> 00000000-0000ffff (prio 0): rl78g13_pb.code_flash >> 000fef00-000ffeff (prio 0): rl78g13_pb.ram >> 000ffee0-000ffeff (prio 0): rl78g13_pb.gpr >> 000fff00-000fffff (prio 0): rl78g13_pb.sfr >> >> https://github.com/afaerber/qemu-rl78/blob/d3880bd53a26d224c56d16a6ea5950019d411cf0/hw/rl78g13_pb.c#L88 >> >> memory_region_init_ram(sfr, NULL, "rl78g13_pb.sfr", 256); >> memory_region_add_subregion(get_system_memory(), 0xFFF00, sfr); >> >> Anything obvious that I'm missing? > > This region is a little special in that it is a subpage RAM region, so > it doesn't follow the normal paths where RAM is mapped directly to the > guest. Maybe there's some bug in that area. Thanks a lot! You were right, setting TARGET_PAGE_BITS to 8 solves this issue. I'd still like to fix this subpage case for others' benefit. Do you have any pointer where I should set breakpoints / review code? > If the target is big > endian that could further complicate things. Target and host are Little Endian, target is 20 bits using TARGET_LONG_BITS 32. Andreas ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Memory read/write issues 2011-11-27 14:07 ` Andreas Färber @ 2011-11-27 14:17 ` Avi Kivity 2011-11-27 22:16 ` Andreas Färber 0 siblings, 1 reply; 8+ messages in thread From: Avi Kivity @ 2011-11-27 14:17 UTC (permalink / raw) To: Andreas Färber; +Cc: qemu-devel Developers On 11/27/2011 04:07 PM, Andreas Färber wrote: > Thanks a lot! You were right, setting TARGET_PAGE_BITS to 8 solves this > issue. > > I'd still like to fix this subpage case for others' benefit. Do you have > any pointer where I should set breakpoints / review code? The subpage code (scheduled for demolition in 1.1) lives in exec.c. See subpage_init() and subpage_register(). I'd start with enabling DEBUG_SUBPAGE, fixing all the build errors, and looking at the output of subpage_readlen() and subpage_writelen(). -- error compiling committee.c: too many arguments to function ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Memory read/write issues 2011-11-27 14:17 ` Avi Kivity @ 2011-11-27 22:16 ` Andreas Färber 0 siblings, 0 replies; 8+ messages in thread From: Andreas Färber @ 2011-11-27 22:16 UTC (permalink / raw) To: Avi Kivity; +Cc: qemu-devel Developers Am 27.11.2011 15:17, schrieb Avi Kivity: > On 11/27/2011 04:07 PM, Andreas Färber wrote: >> Thanks a lot! You were right, setting TARGET_PAGE_BITS to 8 solves this >> issue. >> >> I'd still like to fix this subpage case for others' benefit. Do you have >> any pointer where I should set breakpoints / review code? > > The subpage code (scheduled for demolition in 1.1) lives in exec.c. See > subpage_init() and subpage_register(). I'd start with enabling > DEBUG_SUBPAGE, fixing all the build errors, and looking at the output of > subpage_readlen() and subpage_writelen(). With these hints I've figured out what's actually happening here: subpage_writelen() is reading a wrong index 2 == IO_MEM_UNASSIGNED from subpage_t and performing an unassigned memory write, confirmed by DEBUG_UNASSIGNED. In subpage_register(), we're taking the (memory & ~TARGET_PAGE_MASK) == IO_MEM_RAM path and setting IO_MEM_UNASSIGNED in subpage_t. Will investigate further tomorrow. Andreas ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-11-27 22:16 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-11-23 23:59 [Qemu-devel] Initializing PC from memory on reset? Andreas Färber 2011-11-24 7:47 ` Peter Maydell 2011-11-24 21:24 ` Andreas Färber 2011-11-25 16:25 ` [Qemu-devel] Memory read/write issues (was: Initializing PC from memory on reset?) Andreas Färber 2011-11-27 8:32 ` [Qemu-devel] Memory read/write issues Avi Kivity 2011-11-27 14:07 ` Andreas Färber 2011-11-27 14:17 ` Avi Kivity 2011-11-27 22:16 ` Andreas Färber
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).