[gem5-users] ??????Re: Garnet

Thanks for your reply! The video on YouTube is a online teaching video, the teacher shows me how to run the garnet_standalone and the run results. In his results, the latency is almost 11, but my results are different, and my friend changes the garnet version to garnet2.0, the results she gets

[gem5-users] Re: VExpress_GEM5_V1, Ethernet, and BARs

Giacomo, Replacing the third word on line 70 of the dtsi [1] with `0x0` resolved the collision! Aside, running without the `--dtb` argument caused numerous failures (including an inability to enumerate PCI devices) leading up to a panic. Thanks to you both for your input resolving this, I

[gem5-users] Re: VExpress_GEM5_V1, Ethernet, and BARs

I think the problem lies in the DTB and more specifically in the range mapping https://github.com/gem5/gem5/blob/stable/system/arm/dt/platforms/vexpress_gem5_v1_base.dtsi#L70 Could you replace the third word with 0x0? Otherwise you could rely on DTB autogeneration (simply omit the --dtb

[gem5-users] Re: VExpress_GEM5_V1, Ethernet, and BARs

Yeah, the first time it gets offset in the PciDevice constructor, and the second time is in a call to PciDevice::writeConfig() by the PCI host. Does it look like the `GenericArmPciHost` used by VExpress_GEM5_V1 (but not VExpress_EMM) might be the source of the double-offset? -jrb

[gem5-users] Re: VExpress_GEM5_V1, Ethernet, and BARs

I haven't looked at this closely, but it's normal for the values in the BARs to be displaced based on the platform object's idea of where the PCI ranges are in the address space, ie there is an offset for config space, etc. It sounds to me like this offset is being added in twice, one by the

[gem5-users] Re: VExpress_GEM5_V1, Ethernet, and BARs

Gabe, It looks like after being initialized properly to 0x4000'000 range, the BAR0 start for the Ethernet device is getting changed from 0x4000' to 0x8000' in a call to `PciMemBar::write()` [1] once the driver loads. [1]

[gem5-users] Re: Garnet

Hmm you can go back to an older version of garnet by cloning an older version of gem5 - but I don’t think you need to. Lets try to figure out what’s going on. What do you mean by the result being different from the YouTube video? Can you also try running with --inj-vnet=0 .. this injects only

[gem5-users] Re: VExpress_GEM5_V1, Ethernet, and BARs

Giacomo, That's good to know. We're running `fs.py` with `system/arm/dt/armv7_gem5_v1_1cpu.dtb` which we've copied into our working directory. Full invocation: ``` ./gem5/build/ARM/gem5.opt \ gem5/configs/example/fs.py \ --bootloader ./boot.arm \ --kernel=./vmlinux \

[gem5-users] Re: VExpress_GEM5_V1, Ethernet, and BARs

Out of curiosity, which DTB are you using? IMO the kernel shouldn't write 800 to the PCI Bar, knowing there is DRAM there and this is notified via the DTB Kind Regards Giacomo > -Original Message- > From: Bohren, Jonathan via gem5-users > Sent: 22 January 2021 12:51 > To: gem5

[gem5-users] Re: VExpress_GEM5_V1, Ethernet, and BARs

Gabe, Yeah, this is a very recent version of `develop`. This is after rebasing a recent proposed change `38796` [1] (which disables the HDLcd) onto `develop` HEAD from 2020-01-20: ``` c6e3fd79f (develop-rebase-38796) dev-arm, system-arm: Remove HDLcd from VExpress_GEM5_VX platforms b9ce8848e