I've gotten ARM FS working with Ruby. The cost: 64MB of physical memory. The most important change that got it working was moving the boot loader to address 172MB (0x0C000000). Makefile is in for boot.arm is in system/arm/simple_bootloader/. I then changed the physical memory for my ArmUbuntu benchmark to 172MB.
So far what I've found is that the Timing CPU works fine in ARM FS with Ruby (MOESI_hammer). I was able to run the SPEC CPU2006 libquantum benchmark successfully. The detailed and arm_detailed CPUs haven't crashed, but seem to just hang. They might just be running extremely slow. This verifies that the issue, at a high level, is Ruby not handling disjoint memory correctly. Anybody on the list have an idea on how to fix this problem? Should I submit a diff with my all my changes to the reviewboard? Also, I've been looking at the programmer's reference (chapter 4) in the RealView_PBX user guide here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0440b/index.html Can anyone clarify the difference between the Northbridge DDR memory at 0x0 and the Northbridge DDR memory at 0x70000000? From the manual, it sounds like 0x70000000-0x7FFFFFFF is just a mirror of 0x00000000-0x0FFFFFFF. Does that mean it would be possible for us to get Ruby to use physical memory at 0x70000000-0x7FFFFFFF? That way their would be a contiguous chunk from 0x70000000 to 0x84000000. Thanks, Andrew On Sun, Apr 15, 2012 at 5:06 PM, Andrew Cebulski <[email protected]> wrote: > 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
