I just realized I'm using the MI_example protocol, which is listed as not working for ARM on the gem5 status matrix, so I switched to using MOESI_hammer. Looking into this, I've found that it's setting the phys_mem_size as physmem (256MB) + nvmem (64MB). My guess is we're not integrating nvmem with Ruby correctly, but I'm not sure how to fix this. In the latest repo, it's done here: http://repo.gem5.org/gem5/file/3c7232fec7fd/src/dev/arm/RealView.py
148 <http://repo.gem5.org/gem5/file/3c7232fec7fd/src/dev/arm/RealView.py#l148> def setupBootLoader(self, mem_bus, cur_sys, loc): 149 <http://repo.gem5.org/gem5/file/3c7232fec7fd/src/dev/arm/RealView.py#l149> self.nvmem = SimpleMemory(range = AddrRange(Addr('2GB'), 150 <http://repo.gem5.org/gem5/file/3c7232fec7fd/src/dev/arm/RealView.py#l150> size = '64MB'), 151 <http://repo.gem5.org/gem5/file/3c7232fec7fd/src/dev/arm/RealView.py#l151> zero = True) 152 <http://repo.gem5.org/gem5/file/3c7232fec7fd/src/dev/arm/RealView.py#l152> self.nvmem.port = mem_bus.master In my FSConfig.py, I have self.piobus passed into the function. The code from MOESI_hammer.py: http://repo.gem5.org/gem5/file/3c7232fec7fd/configs/ruby/MOESI_hammer.py 133 <http://repo.gem5.org/gem5/file/3c7232fec7fd/configs/ruby/MOESI_hammer.py#l133> phys_mem_size = 0 134 <http://repo.gem5.org/gem5/file/3c7232fec7fd/configs/ruby/MOESI_hammer.py#l134> for mem in system.memories.unproxy(system): 135 <http://repo.gem5.org/gem5/file/3c7232fec7fd/configs/ruby/MOESI_hammer.py#l135> phys_mem_size += long(mem.range.second) - long(mem.range.first) + 1 136 <http://repo.gem5.org/gem5/file/3c7232fec7fd/configs/ruby/MOESI_hammer.py#l136> mem_module_size = phys_mem_size / options.num_dirs If I set the nvmem "size" to 2GB (same as its Range), it gets past the assertion, but fails with a segmentation fault. -Andrew On Sun, Apr 15, 2012 at 3:46 PM, Andrew Cebulski <[email protected]> wrote: > I'm also trying to get Ruby in ARM FS working, but I'm working off a pull > of gem5 from today. I'm running into the same issue I think, but you > didn't give the error I'm getting. Here it is: > > gem5.opt: build/ARM/mem/ruby/system/DirectoryMemory.cc:164: AbstractEntry* > DirectoryMemory::lookup(PhysAddress): Assertion `idx < m_num_entries' > failed. > > I turned on tracing off RubyCache, and also see an invalid access to > 0x80000000. > > Here are the lines leading up to the assertion: > > 0: system.dir_cntrl0.directory: Looking up address: [0x354700, line > 0x354700] > 0: system.dir_cntrl0.directory: Looking up address: [0x354700, line > 0x354700] > 0: system.dir_cntrl0.directory: Looking up address: [0x354700, line > 0x354700] > 0: system.dir_cntrl0.directory: Looking up address: [0x80000000, > line 0x80000000] > > Anyone know how to fix this problem? This is my first attempt at getting > Ruby to work with Arm. > > Thanks, > Andrew > > > On Sun, Apr 1, 2012 at 6:20 PM, Tony <[email protected]> wrote: > >> Tony Feng <tony.fengkai <at> gmail.com> writes: >> >> > >> > >> > Hi, >> > >> > In M5Port::recvFunctional of RubyPort.cc, if the isPhysMemAddress test >> fails, >> does it necessarily mean it is a packet sent to a pio port? >> > >> > I added some debugging info, found the packet has an invalid source id, >> and a >> destination address of 0x80000000, whereas I believe the system port >> range is 0 >> - 0x7ffffff. Could anyone share thoughts on this? >> > >> > >> > Thanks, >> > Tony >> > >> > >> > >> > _______________________________________________ >> > gem5-users mailing list >> > gem5-users <at> gem5.org >> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> >> I believe I've found where went wrong, but still don't know the solution. >> >> Since I was running ARM FS with Ruby, the bootloader needs to be setup: >> info: Using bootloader at address 0x80000000 >> >> this msg was shown immediately after I caught a functional access for >> address >> 0x8000000. >> >> Maybe something is wrong with the bootloader setup. The way that I >> implemented >> it in FSConfig.py is: >> self.realview.nvmem = PhysicalMemory(range = AddrRange(Addr('2GB'), size = >> '64MB'), zero = True) >> self.boot_loader = binary('boot.arm') >> self.boot_loader_mem = self.realview.nvmem >> self.realview.nvmem.port = self.piobus.master >> >> where the piobus is directly connected to the memory: >> self.piobus.master = physmem.port >> >> Could anyone observe anything wrong here? Or could anyone explain why a >> request >> has the address of the bootloader? >> >> Thanks, >> Tony >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
