[gem5-users] Re: riscv-ubuntu 20.04 FS mode

2022-03-21 Thread Νικόλαος Ταμπουρατζής via gem5-users 

I use the following configuration:

$GEM5/build/RISCV/gem5.fast -d $GEM5/node0  
$GEM5/configs/example/gem5_library/riscv-ubuntu-run.py


To be noticed that I have changed the riscv-ubuntu-run.py in order to  
use your new image as follows:


...
image = CustomDiskImageResource(
local_path = "$HOME/kernels/disks/riscv-ubuntu.img",
disk_root_partition = "1", # This is the partition in the disk  
image to use. 'None' if there is no disk image

)


board.set_kernel_disk_workload(
# The RISCV bootloader will be automatically downloaded to the
# `~/.cache/gem5` directory if not already present.
# The riscv-ubuntu boot-test was tested with riscv-bootloader-5.10
kernel=Resource(
"riscv-bootloader-vmlinux-5.10",
),
disk_image = image,
)
...

Best regards,
Nikos

Quoting Bobby Bruce :


What configuration script are you using?

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Mon, Mar 21, 2022 at 9:50 AM Νικόλαος Ταμπουρατζής via gem5-users <
gem5-users@gem5.org> wrote:


Dear Boddy,

Thank you for the image and instructions! However, when I try to
simulate the image through gem5, after 3 hours the gem5 simulation is
automatically killed (after  the following terminal output)

.

[  OK  ] Started Unattended Upgrades Shutdown.
[  OK  ] Started LSB: automatic crash report generation.
[  OK  ] Finished Hold until boot process finishes up.
[  OK  ] Finished Terminate Plymouth Boot Screen.
[  OK  ] Started Serial Getty on hvc0.
[  OK  ] Started Serial Getty on ttyS0.
  Starting Set console scheme...

As a result, the terminal prompt is not shown...


To be noticed that the gem5 output is the following:

..
build/RISCV/arch/riscv/isa.cc:559: warn: 2647474672536: context 1:
17 consecutive SC failures.
build/RISCV/arch/riscv/isa.cc:559: warn: 2680581940794: context 0:
16 consecutive SC failures.
build/RISCV/arch/riscv/isa.cc:559: warn: 2818816451577: context 1:
18 consecutive SC failures.
Killed


Best regards,
Nikos


Quoting Bobby Bruce via gem5-users :

> Hey Nikos,
>
> While not any faster, this new disk image,
>
http://dist.gem5.org/v21-2/images/riscv/ubuntu-20-04/riscv-ubuntu-20220318.img.gz
,
> has been uploaded. We believe it's more stable. The older one
occasionally
> didn't boot correctly (at least on our end). This is the same resource,
so
> your scripts should continue to work, but now they'll pull this image
which
> we believe is more stable. Sorry we took so long getting this live.
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Mon, Mar 14, 2022 at 12:08 PM Νικόλαος Ταμπουρατζής <
> ntampourat...@ece.auth.gr> wrote:
>
>> Dear Boddy,
>>
>> I have used the same gem5_init.sh in gem5 X86 architecture and all
>> systemd services bypassed and it is working properly without READ-ONLY
>> permissions. So, I believe that it is related either to riscv-image or
>> gem5 configuration.
>>
>> Best regards,
>> Nikos
>>
>>
>>
>> Quoting Bobby Bruce :
>>
>> > Ok, I just thought about this a bit further, if you skip all the init
>> > processes in this manner the OS will boot as read-only. This is by
>> design.
>> > So while you can pass a script here, it can only do read-only things.
>> Your
>> > choices are either to boot properly (with standard init stuff) or
accept
>> > this restriction.
>> >
>> > --
>> > Dr. Bobby R. Bruce
>> > Room 3050,
>> > Kemper Hall, UC Davis
>> > Davis,
>> > CA, 95616
>> >
>> > web: https://www.bobbybruce.net
>> >
>> >
>> > On Mon, Mar 14, 2022 at 11:38 AM Νικόλαος Ταμπουρατζής <
>> > ntampourat...@ece.auth.gr> wrote:
>> >
>> >> Thank you Boddy!
>> >>
>> >> I have also used this image but I get the same READ-ONLY problem.
>> >> However, I would like to use Ubuntu in order to install packages
using
>> >> apt-get install through qemu. Using the "init=/root/gem5_init.sh"
>> >> command both images boot only in 10 minutes.
>> >>
>> >> Best regards,
>> >> Nikos
>> >>
>> >>
>> >> Quoting Bobby Bruce :
>> >>
>> >> > Just remembered: If you're wanting to bi-pass large parts of the
>> Ubuntu
>> >> OS
>> >> > like this, you may just want to use the "riscv-disk-image" (
>> >> >
>> http://dist.gem5.org/dist/v21-2/images/riscv/busybox/riscv-disk.img.gz
),
>> >> an
>> >> > example usage of which can be found in
>> >> > "configs/example/gem5_library/riscv-fs.py":
>> >> >
>> >> > ```
>> >> > ./build/RISCV/gem5.opt configs/example/gem5_library/riscv-fs.py
>> >> > ```
>> >> >
>> >> > This disk image is based on BusyBox, which is very light-weight.
The
>> >> source
>> >> > for building this image is found here:
>> >> >
>> >>
>>
https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/riscv-fs
>> >> >
>> >> > --
>> >> > Dr. Bobby R. Bruce
>> >> > Room 3050,
>> >> > Kemper Hall, UC Davis
>> >> > Davis,
>> >> > CA, 95616
>> >> >
>> >> > web:

[gem5-users] Re: riscv-ubuntu 20.04 FS mode

2022-03-21 Thread Νικόλαος Ταμπουρατζής via gem5-users 

Dear Boddy,

Thank you for the image and instructions! However, when I try to  
simulate the image through gem5, after 3 hours the gem5 simulation is  
automatically killed (after  the following terminal output)


.

[  OK  ] Started Unattended Upgrades Shutdown.
[  OK  ] Started LSB: automatic crash report generation.
[  OK  ] Finished Hold until boot process finishes up.
[  OK  ] Finished Terminate Plymouth Boot Screen.
[  OK  ] Started Serial Getty on hvc0.
[  OK  ] Started Serial Getty on ttyS0.
 Starting Set console scheme...

As a result, the terminal prompt is not shown...


To be noticed that the gem5 output is the following:

..
build/RISCV/arch/riscv/isa.cc:559: warn: 2647474672536: context 1:  
17 consecutive SC failures.
build/RISCV/arch/riscv/isa.cc:559: warn: 2680581940794: context 0:  
16 consecutive SC failures.
build/RISCV/arch/riscv/isa.cc:559: warn: 2818816451577: context 1:  
18 consecutive SC failures.

Killed


Best regards,
Nikos


Quoting Bobby Bruce via gem5-users :


Hey Nikos,

While not any faster, this new disk image,
http://dist.gem5.org/v21-2/images/riscv/ubuntu-20-04/riscv-ubuntu-20220318.img.gz,
has been uploaded. We believe it's more stable. The older one occasionally
didn't boot correctly (at least on our end). This is the same resource, so
your scripts should continue to work, but now they'll pull this image which
we believe is more stable. Sorry we took so long getting this live.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Mon, Mar 14, 2022 at 12:08 PM Νικόλαος Ταμπουρατζής <
ntampourat...@ece.auth.gr> wrote:


Dear Boddy,

I have used the same gem5_init.sh in gem5 X86 architecture and all
systemd services bypassed and it is working properly without READ-ONLY
permissions. So, I believe that it is related either to riscv-image or
gem5 configuration.

Best regards,
Nikos



Quoting Bobby Bruce :

> Ok, I just thought about this a bit further, if you skip all the init
> processes in this manner the OS will boot as read-only. This is by
design.
> So while you can pass a script here, it can only do read-only things.
Your
> choices are either to boot properly (with standard init stuff) or accept
> this restriction.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Mon, Mar 14, 2022 at 11:38 AM Νικόλαος Ταμπουρατζής <
> ntampourat...@ece.auth.gr> wrote:
>
>> Thank you Boddy!
>>
>> I have also used this image but I get the same READ-ONLY problem.
>> However, I would like to use Ubuntu in order to install packages using
>> apt-get install through qemu. Using the "init=/root/gem5_init.sh"
>> command both images boot only in 10 minutes.
>>
>> Best regards,
>> Nikos
>>
>>
>> Quoting Bobby Bruce :
>>
>> > Just remembered: If you're wanting to bi-pass large parts of the
Ubuntu
>> OS
>> > like this, you may just want to use the "riscv-disk-image" (
>> >
http://dist.gem5.org/dist/v21-2/images/riscv/busybox/riscv-disk.img.gz),
>> an
>> > example usage of which can be found in
>> > "configs/example/gem5_library/riscv-fs.py":
>> >
>> > ```
>> > ./build/RISCV/gem5.opt configs/example/gem5_library/riscv-fs.py
>> > ```
>> >
>> > This disk image is based on BusyBox, which is very light-weight. The
>> source
>> > for building this image is found here:
>> >
>>
https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/riscv-fs
>> >
>> > --
>> > Dr. Bobby R. Bruce
>> > Room 3050,
>> > Kemper Hall, UC Davis
>> > Davis,
>> > CA, 95616
>> >
>> > web: https://www.bobbybruce.net
>> >
>> >
>> > On Mon, Mar 14, 2022 at 11:12 AM Bobby Bruce 
wrote:
>> >
>> >> Oh I see, I understand now. I thought you managed to disable some
>> systemd
>> >> jobs (something I think Hoa struggled with), but you're just
bypassing
>> them
>> >> by setting init to a script.
>> >>
>> >> Nice, I'll let you know when the new image is available. I'll see if
I
>> can
>> >> reproduce the error you found with the READ-ONLY problem on the new
>> image.
>> >>
>> >> --
>> >> Dr. Bobby R. Bruce
>> >> Room 3050,
>> >> Kemper Hall, UC Davis
>> >> Davis,
>> >> CA, 95616
>> >>
>> >> web: https://www.bobbybruce.net
>> >>
>> >>
>> >> On Mon, Mar 14, 2022 at 11:10 AM Νικόλαος Ταμπουρατζής <
>> >> ntampourat...@ece.auth.gr> wrote:
>> >>
>> >>> Dear Boddy,
>> >>>
>> >>> Thank you very much for the clarifications! I used the pre-build
disk
>> >>> image from gem5 resources
>> >>> (
https://github.com/gem5/gem5-resources/tree/stable/src/riscv-ubuntu),
>> >>> and I add the "init=/root/gem5_init.sh" command in the gem5 python
>> >>> script in order to bypass the systemd services.
>> >>>
>> >>> Please let me know when your new disk image is available!
>> >>>
>> >>> Thanks!
>> >>>
>> >>> Best regards,
>> >>> Nikos
>> >>>
>> >>>
>> >>> Quoting Bobby Bruce :
>> >>>
>> >>> > Hey Nikos,
>> >>> >
>> >>> > First, you can set your

[gem5-users] Re: “fatal: Unable to find destination for [0x10020000 : 0x10020000] on system.iobus”, when adding new BasicPioDevice device.

2022-03-21 Thread Giacomo Travaglini via gem5-users 
That’s great!

FYI, overriding the getAddrRanges is not strictly needed if the BasicPioDevice 
is correctly initialised. That basically means initialising pioAddr and pioSize 
member variables:

https://github.com/gem5/gem5/blob/stable/src/dev/io_device.cc#L81

I am telling you this as while you fixed the mapping issue, an incorrect value 
for pioAddr and pioSize could potentially lead to other kinds of bugs in your 
device implementation 

Kind Regards

Giacomo

From: Klein Joshua Alexander Harrison 
Date: Monday, 21 March 2022 at 16:13
To: Giacomo Travaglini , gem5 users mailing list 

Subject: Re: “fatal: Unable to find destination for [0x1002 : 0x1002] 
on system.iobus”, when adding new BasicPioDevice device.

Hi Giacomo,



Thanks again for the suggestion.  I was able to solve the issue -- it turns out 
I forgot to implement getAddrRanges!



For the record (and in case someone in the future runs into the same issue), I 
had to add the following in cus_device.hh under the class definition:



AddrRangeList getAddrRanges() const override;





and then the following implementation in cus_device.cc:



AddrRangeList

CusDevice::getAddrRanges() const

{

AddrRangeList ranges;

ranges.push_back(RangeSize(0x1002, 0x1000));

return ranges;

}





Thank you again for your help!



Best regards,

Joshua Klein


From: Giacomo Travaglini 
Sent: Monday, March 21, 2022 4:27:06 PM
To: Klein Joshua Alexander Harrison; gem5 users mailing list
Subject: Re: “fatal: Unable to find destination for [0x1002 : 0x1002] 
on system.iobus”, when adding new BasicPioDevice device.

Yes apologies, I now realize your range was already covered in the existing 
_off_chip_ranges list
I’d recommend you to debug with gdb what is returned by the 
CusDevice::getAddrRanges method. It gets called by the xbar and it effectively 
registers the device pio range in the interconnect map.

Kind Regards

Giacomo


From: Klein Joshua Alexander Harrison 
Date: Monday, 21 March 2022 at 15:11
To: Giacomo Travaglini , gem5 users mailing list 

Subject: Re: “fatal: Unable to find destination for [0x1002 : 0x1002] 
on system.iobus”, when adding new BasicPioDevice device.
Hi Giacomo,

Thank you for the suggestion.  I added the address range to the 
_off_chip_devices list as suggested, and confirmed the address range is present 
in the config.ini:

[system.bridge]
type=Bridge
…
ranges=201326592:268566527 268566528:268570624 268570625:536870912  
788529152:2147483647
req_size=16
resp_size=16
master=system.iobus.slave[0]
slave=system.membus.master[0]

Unfortunately however, I still run into the exact same issue.

Best regards,
Joshua Klein


From: Giacomo Travaglini 
Sent: Monday, March 21, 2022 3:24:02 PM
To: gem5 users mailing list
Cc: Klein Joshua Alexander Harrison
Subject: Re: “fatal: Unable to find destination for [0x1002 : 0x1002] 
on system.iobus”, when adding new BasicPioDevice device.

Hi Joshua.

You probably need to add the physical address range of your device to the 
_off_chip_ranges list [1]. This will be assigned to the membus->iobus bridge so 
that when the membus receives the cpu packet, it knows it must forward it to 
the io bridge

Let me know if this works

Kind Regards

Giacomo

[1]: 
https://github.com/gem5/gem5/blob/141cc37c2d4b93959d4c249b8f7e6a8b2ef75338/src/dev/arm/RealView.py#L1081

From: Klein Joshua Alexander Harrison via gem5-users 
Date: Monday, 21 March 2022 at 14:12
To: gem5-users@gem5.org 
Cc: Klein Joshua Alexander Harrison 
Subject: [gem5-users] “fatal: Unable to find destination for [0x1002 : 
0x1002] on system.iobus”, when adding new BasicPioDevice device.
Hi all,

I am trying to run an ARM full system simulation with a BasicPioDevice added 
onto the RealView Platform.  I am interested in interfacing it via ioremap.  
The device is set up like so in src/dev/arm/RealView.py (with the necessary C++ 
header/implementation files):

class CusDevice(BasicPioDevice):
type = ‘CusDevice’
cxx_header = "dev/arm/cus_device.hh”
pio_addr = Param.Addr(0x1002, "Address for custom device.”)


I then added it to the list of off-chip devices in RealView.py so it would be 
attached to the iobus, which is confirmed in the config.ini file:

[system.realview.cus_device]
type=CusDevice
…
pio_addr=268566528
pio_latency=10
power_model=
system=system
pio=system.iobus.master[9]


Then to access this device, I am using a kernel module that calls ioremap on 
the device’s address.  Ideally I want to read/write from /dev/cus_device to 
access it, but this is where I run into the fatal error:

root@aarch64-gem5:~/# echo h | /dev/cus_device
fatal: Unable to find destination for [0x1002 : 0x1002] on system.iobus


I have already confirmed that 0x1002 is within an IO memory region (more 
specifically, 0x1000-0x13ff are reserved for gem5-specific peripherals 
but only 0x1000-0x1001 are

[gem5-users] Re: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn

2022-03-21 Thread David Fong via gem5-users 
Hi Matt P,

When I tried the
--reg-alloc-policy=dynamic
a few runs did not improve and in fact got worse.
For now, I will not use this option.
Maybe the driver is not optimizing for this release.

I did update my runs to use

--gpu-to-dir-latency 100  (instead of 120)
--TCC_latency 12 (instead of 16)

And saw some with positive improvements and some with negative improvements.
But overall positive.

To determine the  improvement, I used the stats.txt and picked "allLatencyDist".
I was told to not use individual "CUsX latencies" since it's too focused on one 
CUs and one should look at the big picture.

system.cpu3.allLatencyDist::mean 91121342.881356

I choose the "allLatencyDist::mean" because it had similar % number as 
"storeLatency" and "loadLatency".
The sim times didn't complete earlier even with shorter latency so I decided to 
choose the overall latency.

Which stats do you think should improve overall ?

Thanks,

David


From: Poremba, Matthew 
Sent: Thursday, March 17, 2022 2:10 PM
To: David Fong ; Matt Sinclair ; 
gem5 users mailing list 
Cc: Kyle Roarty ; Bharadwaj, Srikant 

Subject: RE: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn


[AMD Official Use Only]

These would be valid for both as they both use the same cache protocol files.  
I'm not very familiar with how dGPU is hacked up in SE mode to look like a 
dGPU...


-Matt

From: David Fong mailto:da...@chronostech.com>>
Sent: Thursday, March 17, 2022 9:57 AM
To: Poremba, Matthew mailto:matthew.pore...@amd.com>>; 
Matt Sinclair mailto:sincl...@cs.wisc.edu>>; gem5 users 
mailing list mailto:gem5-users@gem5.org>>
Cc: Kyle Roarty mailto:kroa...@wisc.edu>>; Bharadwaj, Srikant 
mailto:srikant.bharad...@amd.com>>
Subject: RE: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn

[CAUTION: External Email]
Hi Matt P,

Thanks for the tip on latency parameters.

Are these parameters valid ONLY for DGPU with VRAM or these apply to both DGPU 
and APU ?

David

From: Poremba, Matthew mailto:matthew.pore...@amd.com>>
Sent: Thursday, March 17, 2022 7:51 AM
To: Matt Sinclair mailto:sincl...@cs.wisc.edu>>; David 
Fong mailto:da...@chronostech.com>>; gem5 users mailing 
list mailto:gem5-users@gem5.org>>
Cc: Kyle Roarty mailto:kroa...@wisc.edu>>; Bharadwaj, Srikant 
mailto:srikant.bharad...@amd.com>>
Subject: RE: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn


[AMD Official Use Only]

Hi David,


I don't think these are the parameters you want to be changing if you are 
trying to change the VRAM memory latency which it seems like you are based on 
the GDDR5 comment.  Those parameters are for the latency between CUs seeing a 
memory request and the request leaving the global memory pipeline, I believe.  
It doesn't really have anything to do with interconnect or the latency to VRAM 
memory.

I think the parameters you probably want are the latencies defined in the 
GPU_VIPER slicc files:

  *   l2_request_latency / l2_response_latency in GPU_VIPER-TCC.sm

It looks like in configs/ruby/GPU_VIPER.py there are some command line 
parameters for this which correspond to:

  *   --gpu-to-dir-latency / --TCC_latency


-Matt

From: Matt Sinclair mailto:sincl...@cs.wisc.edu>>
Sent: Wednesday, March 16, 2022 10:41 PM
To: David Fong mailto:da...@chronostech.com>>; gem5 
users mailing list mailto:gem5-users@gem5.org>>
Cc: Kyle Roarty mailto:kroa...@wisc.edu>>; Poremba, Matthew 
mailto:matthew.pore...@amd.com>>; Bharadwaj, Srikant 
mailto:srikant.bharad...@amd.com>>
Subject: RE: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn

[CAUTION: External Email]
Matt P or Srikant: can you please help David with the latency question?  You 
know the answers better than I do here.

Matt

From: David Fong mailto:da...@chronostech.com>>
Sent: Wednesday, March 16, 2022 5:47 PM
To: Matt Sinclair mailto:sincl...@cs.wisc.edu>>; gem5 
users mailing list mailto:gem5-users@gem5.org>>
Cc: Kyle Roarty mailto:kroa...@wisc.edu>>; Poremba, Matthew 
mailto:matthew.pore...@amd.com>>
Subject: RE: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn

Hi Matt S,

Thanks again for your quick reply with useful information.
I will rerun with -reg-alloc-policy=dynamic
in my mini regression to see If it makes a difference

As for LRN, I won't make modifications to lrn_config.dnnmark
unless it's required to run additional DNN tests.
The 4 tests : test_fwd_softmax, test_bwd_softmax, test_fwd_pool, and 
test_bwd_bn are good enough for now.

For Matt S and Matt P,
Are these parameters for "mem_req_latency" and "mem_resp_latency" valid for 
both APU (Carrizo) and GPU (VEGA) ?
gem5/src/gpu-compute/GPU.py
mem_req_latency = Param.Int(40, "Latency for request from the cu to ruby. "\
"Represents the pipeline to reach the TCP "\
"and specified in GPU clock cycles")
mem_resp_latency = Param.Int(40, "Latency for responses from ruby to the "\
 "cu. Represents the pipeline between the "\
 "TCP and cu as well as TCP

[gem5-users] Re: “fatal: Unable to find destination for [0x10020000 : 0x10020000] on system.iobus”, when adding new BasicPioDevice device.

2022-03-21 Thread Klein Joshua Alexander Harrison via gem5-users 
Hi Giacomo,


Thanks again for the suggestion.  I was able to solve the issue -- it turns out 
I forgot to implement getAddrRanges!


For the record (and in case someone in the future runs into the same issue), I 
had to add the following in cus_device.hh under the class definition:


AddrRangeList getAddrRanges() const override;



and then the following implementation in cus_device.cc:


AddrRangeList

CusDevice::getAddrRanges() const

{

AddrRangeList ranges;

ranges.push_back(RangeSize(0x1002, 0x1000));

return ranges;

}



Thank you again for your help!


Best regards,

Joshua Klein



From: Giacomo Travaglini 
Sent: Monday, March 21, 2022 4:27:06 PM
To: Klein Joshua Alexander Harrison; gem5 users mailing list
Subject: Re: “fatal: Unable to find destination for [0x1002 : 0x1002] 
on system.iobus”, when adding new BasicPioDevice device.

Yes apologies, I now realize your range was already covered in the existing 
_off_chip_ranges list
I’d recommend you to debug with gdb what is returned by the 
CusDevice::getAddrRanges method. It gets called by the xbar and it effectively 
registers the device pio range in the interconnect map.

Kind Regards

Giacomo


From: Klein Joshua Alexander Harrison 
Date: Monday, 21 March 2022 at 15:11
To: Giacomo Travaglini , gem5 users mailing list 

Subject: Re: “fatal: Unable to find destination for [0x1002 : 0x1002] 
on system.iobus”, when adding new BasicPioDevice device.
Hi Giacomo,

Thank you for the suggestion.  I added the address range to the 
_off_chip_devices list as suggested, and confirmed the address range is present 
in the config.ini:

[system.bridge]
type=Bridge
…
ranges=201326592:268566527 268566528:268570624 268570625:536870912  
788529152:2147483647
req_size=16
resp_size=16
master=system.iobus.slave[0]
slave=system.membus.master[0]

Unfortunately however, I still run into the exact same issue.

Best regards,
Joshua Klein


From: Giacomo Travaglini 
Sent: Monday, March 21, 2022 3:24:02 PM
To: gem5 users mailing list
Cc: Klein Joshua Alexander Harrison
Subject: Re: “fatal: Unable to find destination for [0x1002 : 0x1002] 
on system.iobus”, when adding new BasicPioDevice device.

Hi Joshua.

You probably need to add the physical address range of your device to the 
_off_chip_ranges list [1]. This will be assigned to the membus->iobus bridge so 
that when the membus receives the cpu packet, it knows it must forward it to 
the io bridge

Let me know if this works

Kind Regards

Giacomo

[1]: 
https://github.com/gem5/gem5/blob/141cc37c2d4b93959d4c249b8f7e6a8b2ef75338/src/dev/arm/RealView.py#L1081

From: Klein Joshua Alexander Harrison via gem5-users 
Date: Monday, 21 March 2022 at 14:12
To: gem5-users@gem5.org 
Cc: Klein Joshua Alexander Harrison 
Subject: [gem5-users] “fatal: Unable to find destination for [0x1002 : 
0x1002] on system.iobus”, when adding new BasicPioDevice device.
Hi all,

I am trying to run an ARM full system simulation with a BasicPioDevice added 
onto the RealView Platform.  I am interested in interfacing it via ioremap.  
The device is set up like so in src/dev/arm/RealView.py (with the necessary C++ 
header/implementation files):

class CusDevice(BasicPioDevice):
type = ‘CusDevice’
cxx_header = "dev/arm/cus_device.hh”
pio_addr = Param.Addr(0x1002, "Address for custom device.”)


I then added it to the list of off-chip devices in RealView.py so it would be 
attached to the iobus, which is confirmed in the config.ini file:

[system.realview.cus_device]
type=CusDevice
…
pio_addr=268566528
pio_latency=10
power_model=
system=system
pio=system.iobus.master[9]


Then to access this device, I am using a kernel module that calls ioremap on 
the device’s address.  Ideally I want to read/write from /dev/cus_device to 
access it, but this is where I run into the fatal error:

root@aarch64-gem5:~/# echo h | /dev/cus_device
fatal: Unable to find destination for [0x1002 : 0x1002] on system.iobus


I have already confirmed that 0x1002 is within an IO memory region (more 
specifically, 0x1000-0x13ff are reserved for gem5-specific peripherals 
but only 0x1000-0x1001 are actually used before adding the custom 
device).  In case it is relevant, I am using the Linux 5.4.0 kernel with an 
Ubuntu 18.04 LTS image.

Accessing the custom device at address 0x1002 on the iobus is the precise 
goal, so given that writing to /dev/cus_device tries to write data to the 
correct address on the iobus, and I know cus_device.pio is attached to the 
iobus.master with the correct address, I am not sure why gem5 is unable to find 
the destination.  Any ideas on how to approach this issue would be greatly 
appreciated.

Best regards,
Joshua Klein

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the

[gem5-users] Re: Running SPEChpc 2021 benchmarks with gem5

2022-03-21 Thread Chrysanthos Pepi via gem5-users 
Hello Hoa,

Thank you for your reply. It seems that I need to create an image file. I 
mistakenly assumed that the iso will work. Thus, I am looking into spec-2017 
gem5-resources 
repo,
 and I’m trying to understand what I need to change in order to build the image 
as in the config file there are scripts that are executed (runscript, 
post-installation, install-spec2017).

Kind regards,
Chrysanthos Pepi

From: Hoa Nguyen
Sent: Saturday, March 19, 2022 16:39
To: gem5 users mailing list
Cc: cpepi...@outlook.com
Subject: Re: [gem5-users] Running SPEChpc 2021 benchmarks with gem5

Hi Chrysanthos,

As indicated by this line,
> ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on 
> unknown-block(3,0) ]---
the problem seems to be that the root partition was identified incorrectly.

You can run the `fdisk` command to find the location of the root partition. For 
example,
/scr/hn/riscv-ubuntu-disk-images/> fdisk -l ubuntu.img
Disk ubuntu.img: 7.51 GiB, 8053063680 bytes, 15728640 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E2DAF0DA-8641-4639-AEF7-3E832D145D82

DeviceStart  End  Sectors  Size Type
ubuntu.img1  235554 15728606 15493053  7.4G Linux filesystem
ubuntu.img12 227362   235553 81924M Linux filesystem
ubuntu.img13 34 2081 20481M HiFive Unleashed FSBL
ubuntu.img14   208210273 81924M HiFive Unleashed BBL
ubuntu.img15  10274   227361   217088  106M EFI System

Partition table entries are not in disk order.

The largest partition is ubuntu.img1, so the mount point of / should be at 
/dev/vda1 (or /dev/vda, I don't remember this :D).

I assume that you are using the gem5 library. If that is the case, you can 
follow this example to set the mount point of / to another partition.
https://gem5.googlesource.com/public/gem5/+/refs/heads/stable/configs/example/gem5_library/x86-spec-cpu2017-benchmarks.py#240

It should look like,

board.set_kernel_disk_workload(
# The x86 linux kernel will be automatically downloaded to the
# `~/.cache/gem5` directory if not already present.
kernel=Resource(
"x86-linux-kernel-4.19.83",
),
# The location of the x86 SPEC CPU 2017 image
# Assume that it should be /dev/vda1
disk_image=CustomDiskImageResource(
"/path/to/the/disk/image",
disk_root_partition="1",
),
readfile_contents=command,
)

Regards,
Hoa Nguyen

On Sat, Mar 19, 2022 at 12:33 PM cpepi001--- via gem5-users 
mailto:gem5-users@gem5.org>> wrote:
Hello All,

I would like to ask if it's possible to run SPEChpc 2021 benchmarks using gem5.
I tried to run it with the x86-spec-cpu2017-benchmarks.py but I got the 
following error in the system.pc.com_1.device file:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,0)
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.19.83 #1
Hardware name:  , BIOS  06/08/2008
Call Trace:
 dump_stack+0x5d/0x79
 panic+0xe2/0x236
 mount_block_root+0x2b0/0x2e4
 ? set_debug_rodata+0xc/0xc
 prepare_namespace+0x15b/0x191
 kernel_init_freeable+0x23c/0x24c
 ? rest_init+0xa0/0xa0
 kernel_init+0x5/0xf0
 ret_from_fork+0x35/0x40
Kernel Offset: disabled
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(3,0) ]---

Does anyone knows how to properly configure it? if it's possible to run those 
benchmarks with gem5.

version: 21.2.1.0
command: build/X86/gem5.opt 
configs/example/gem5_library/x86-spec-hpc2021-benchmarks.py --image 
../hpc2021-1.0.3.iso --benchmark 505.lbm_t --size test
(x86-spec-hpc2021-benchmarks.py is the same as x86-spec-cpu2017-benchmarks.py 
with different benchmarks)

Best,
Chrysanthos
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to 
gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: “fatal: Unable to find destination for [0x10020000 : 0x10020000] on system.iobus”, when adding new BasicPioDevice device.

2022-03-21 Thread Giacomo Travaglini via gem5-users 
Yes apologies, I now realize your range was already covered in the existing 
_off_chip_ranges list
I’d recommend you to debug with gdb what is returned by the 
CusDevice::getAddrRanges method. It gets called by the xbar and it effectively 
registers the device pio range in the interconnect map.

Kind Regards

Giacomo


From: Klein Joshua Alexander Harrison 
Date: Monday, 21 March 2022 at 15:11
To: Giacomo Travaglini , gem5 users mailing list 

Subject: Re: “fatal: Unable to find destination for [0x1002 : 0x1002] 
on system.iobus”, when adding new BasicPioDevice device.
Hi Giacomo,

Thank you for the suggestion.  I added the address range to the 
_off_chip_devices list as suggested, and confirmed the address range is present 
in the config.ini:

[system.bridge]
type=Bridge
…
ranges=201326592:268566527 268566528:268570624 268570625:536870912  
788529152:2147483647
req_size=16
resp_size=16
master=system.iobus.slave[0]
slave=system.membus.master[0]

Unfortunately however, I still run into the exact same issue.

Best regards,
Joshua Klein


From: Giacomo Travaglini 
Sent: Monday, March 21, 2022 3:24:02 PM
To: gem5 users mailing list
Cc: Klein Joshua Alexander Harrison
Subject: Re: “fatal: Unable to find destination for [0x1002 : 0x1002] 
on system.iobus”, when adding new BasicPioDevice device.

Hi Joshua.

You probably need to add the physical address range of your device to the 
_off_chip_ranges list [1]. This will be assigned to the membus->iobus bridge so 
that when the membus receives the cpu packet, it knows it must forward it to 
the io bridge

Let me know if this works

Kind Regards

Giacomo

[1]: 
https://github.com/gem5/gem5/blob/141cc37c2d4b93959d4c249b8f7e6a8b2ef75338/src/dev/arm/RealView.py#L1081

From: Klein Joshua Alexander Harrison via gem5-users 
Date: Monday, 21 March 2022 at 14:12
To: gem5-users@gem5.org 
Cc: Klein Joshua Alexander Harrison 
Subject: [gem5-users] “fatal: Unable to find destination for [0x1002 : 
0x1002] on system.iobus”, when adding new BasicPioDevice device.
Hi all,

I am trying to run an ARM full system simulation with a BasicPioDevice added 
onto the RealView Platform.  I am interested in interfacing it via ioremap.  
The device is set up like so in src/dev/arm/RealView.py (with the necessary C++ 
header/implementation files):

class CusDevice(BasicPioDevice):
type = ‘CusDevice’
cxx_header = "dev/arm/cus_device.hh”
pio_addr = Param.Addr(0x1002, "Address for custom device.”)


I then added it to the list of off-chip devices in RealView.py so it would be 
attached to the iobus, which is confirmed in the config.ini file:

[system.realview.cus_device]
type=CusDevice
…
pio_addr=268566528
pio_latency=10
power_model=
system=system
pio=system.iobus.master[9]


Then to access this device, I am using a kernel module that calls ioremap on 
the device’s address.  Ideally I want to read/write from /dev/cus_device to 
access it, but this is where I run into the fatal error:

root@aarch64-gem5:~/# echo h | /dev/cus_device
fatal: Unable to find destination for [0x1002 : 0x1002] on system.iobus


I have already confirmed that 0x1002 is within an IO memory region (more 
specifically, 0x1000-0x13ff are reserved for gem5-specific peripherals 
but only 0x1000-0x1001 are actually used before adding the custom 
device).  In case it is relevant, I am using the Linux 5.4.0 kernel with an 
Ubuntu 18.04 LTS image.

Accessing the custom device at address 0x1002 on the iobus is the precise 
goal, so given that writing to /dev/cus_device tries to write data to the 
correct address on the iobus, and I know cus_device.pio is attached to the 
iobus.master with the correct address, I am not sure why gem5 is unable to find 
the destination.  Any ideas on how to approach this issue would be greatly 
appreciated.

Best regards,
Joshua Klein

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: “fatal: Unable to find destination for [0x10020000 : 0x10020000] on system.iobus”, when adding new BasicPioDevice device.

2022-03-21 Thread Klein Joshua Alexander Harrison via gem5-users 
Hi Giacomo,

Thank you for the suggestion.  I added the address range to the 
_off_chip_devices list as suggested, and confirmed the address range is present 
in the config.ini:

[system.bridge]
type=Bridge
…
ranges=201326592:268566527 268566528:268570624 268570625:536870912  
788529152:2147483647
req_size=16
resp_size=16
master=system.iobus.slave[0]
slave=system.membus.master[0]

Unfortunately however, I still run into the exact same issue.

Best regards,
Joshua Klein



From: Giacomo Travaglini 
Sent: Monday, March 21, 2022 3:24:02 PM
To: gem5 users mailing list
Cc: Klein Joshua Alexander Harrison
Subject: Re: “fatal: Unable to find destination for [0x1002 : 0x1002] 
on system.iobus”, when adding new BasicPioDevice device.

Hi Joshua.

You probably need to add the physical address range of your device to the 
_off_chip_ranges list [1]. This will be assigned to the membus->iobus bridge so 
that when the membus receives the cpu packet, it knows it must forward it to 
the io bridge

Let me know if this works

Kind Regards

Giacomo

[1]: 
https://github.com/gem5/gem5/blob/141cc37c2d4b93959d4c249b8f7e6a8b2ef75338/src/dev/arm/RealView.py#L1081

From: Klein Joshua Alexander Harrison via gem5-users 
Date: Monday, 21 March 2022 at 14:12
To: gem5-users@gem5.org 
Cc: Klein Joshua Alexander Harrison 
Subject: [gem5-users] “fatal: Unable to find destination for [0x1002 : 
0x1002] on system.iobus”, when adding new BasicPioDevice device.
Hi all,

I am trying to run an ARM full system simulation with a BasicPioDevice added 
onto the RealView Platform.  I am interested in interfacing it via ioremap.  
The device is set up like so in src/dev/arm/RealView.py (with the necessary C++ 
header/implementation files):

class CusDevice(BasicPioDevice):
type = ‘CusDevice’
cxx_header = "dev/arm/cus_device.hh”
pio_addr = Param.Addr(0x1002, "Address for custom device.”)


I then added it to the list of off-chip devices in RealView.py so it would be 
attached to the iobus, which is confirmed in the config.ini file:

[system.realview.cus_device]
type=CusDevice
…
pio_addr=268566528
pio_latency=10
power_model=
system=system
pio=system.iobus.master[9]


Then to access this device, I am using a kernel module that calls ioremap on 
the device’s address.  Ideally I want to read/write from /dev/cus_device to 
access it, but this is where I run into the fatal error:

root@aarch64-gem5:~/# echo h | /dev/cus_device
fatal: Unable to find destination for [0x1002 : 0x1002] on system.iobus


I have already confirmed that 0x1002 is within an IO memory region (more 
specifically, 0x1000-0x13ff are reserved for gem5-specific peripherals 
but only 0x1000-0x1001 are actually used before adding the custom 
device).  In case it is relevant, I am using the Linux 5.4.0 kernel with an 
Ubuntu 18.04 LTS image.

Accessing the custom device at address 0x1002 on the iobus is the precise 
goal, so given that writing to /dev/cus_device tries to write data to the 
correct address on the iobus, and I know cus_device.pio is attached to the 
iobus.master with the correct address, I am not sure why gem5 is unable to find 
the destination.  Any ideas on how to approach this issue would be greatly 
appreciated.

Best regards,
Joshua Klein

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: “fatal: Unable to find destination for [0x10020000 : 0x10020000] on system.iobus”, when adding new BasicPioDevice device.

2022-03-21 Thread Giacomo Travaglini via gem5-users 
Hi Joshua.

You probably need to add the physical address range of your device to the 
_off_chip_ranges list [1]. This will be assigned to the membus->iobus bridge so 
that when the membus receives the cpu packet, it knows it must forward it to 
the io bridge

Let me know if this works

Kind Regards

Giacomo

[1]: 
https://github.com/gem5/gem5/blob/141cc37c2d4b93959d4c249b8f7e6a8b2ef75338/src/dev/arm/RealView.py#L1081

From: Klein Joshua Alexander Harrison via gem5-users 
Date: Monday, 21 March 2022 at 14:12
To: gem5-users@gem5.org 
Cc: Klein Joshua Alexander Harrison 
Subject: [gem5-users] “fatal: Unable to find destination for [0x1002 : 
0x1002] on system.iobus”, when adding new BasicPioDevice device.
Hi all,

I am trying to run an ARM full system simulation with a BasicPioDevice added 
onto the RealView Platform.  I am interested in interfacing it via ioremap.  
The device is set up like so in src/dev/arm/RealView.py (with the necessary C++ 
header/implementation files):

class CusDevice(BasicPioDevice):
type = ‘CusDevice’
cxx_header = "dev/arm/cus_device.hh”
pio_addr = Param.Addr(0x1002, "Address for custom device.”)


I then added it to the list of off-chip devices in RealView.py so it would be 
attached to the iobus, which is confirmed in the config.ini file:

[system.realview.cus_device]
type=CusDevice
…
pio_addr=268566528
pio_latency=10
power_model=
system=system
pio=system.iobus.master[9]


Then to access this device, I am using a kernel module that calls ioremap on 
the device’s address.  Ideally I want to read/write from /dev/cus_device to 
access it, but this is where I run into the fatal error:

root@aarch64-gem5:~/# echo h | /dev/cus_device
fatal: Unable to find destination for [0x1002 : 0x1002] on system.iobus


I have already confirmed that 0x1002 is within an IO memory region (more 
specifically, 0x1000-0x13ff are reserved for gem5-specific peripherals 
but only 0x1000-0x1001 are actually used before adding the custom 
device).  In case it is relevant, I am using the Linux 5.4.0 kernel with an 
Ubuntu 18.04 LTS image.

Accessing the custom device at address 0x1002 on the iobus is the precise 
goal, so given that writing to /dev/cus_device tries to write data to the 
correct address on the iobus, and I know cus_device.pio is attached to the 
iobus.master with the correct address, I am not sure why gem5 is unable to find 
the destination.  Any ideas on how to approach this issue would be greatly 
appreciated.

Best regards,
Joshua Klein

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] “fatal: Unable to find destination for [0x10020000 : 0x10020000] on system.iobus”, when adding new BasicPioDevice device.

2022-03-21 Thread Klein Joshua Alexander Harrison via gem5-users 
Hi all,

I am trying to run an ARM full system simulation with a BasicPioDevice added 
onto the RealView Platform.  I am interested in interfacing it via ioremap.  
The device is set up like so in src/dev/arm/RealView.py (with the necessary C++ 
header/implementation files):

class CusDevice(BasicPioDevice):
type = ‘CusDevice’
cxx_header = "dev/arm/cus_device.hh”
pio_addr = Param.Addr(0x1002, "Address for custom device.”)


I then added it to the list of off-chip devices in RealView.py so it would be 
attached to the iobus, which is confirmed in the config.ini file:

[system.realview.cus_device]
type=CusDevice
…
pio_addr=268566528
pio_latency=10
power_model=
system=system
pio=system.iobus.master[9]


Then to access this device, I am using a kernel module that calls ioremap on 
the device’s address.  Ideally I want to read/write from /dev/cus_device to 
access it, but this is where I run into the fatal error:

root@aarch64-gem5:~/# echo h | /dev/cus_device
fatal: Unable to find destination for [0x1002 : 0x1002] on system.iobus


I have already confirmed that 0x1002 is within an IO memory region (more 
specifically, 0x1000-0x13ff are reserved for gem5-specific peripherals 
but only 0x1000-0x1001 are actually used before adding the custom 
device).  In case it is relevant, I am using the Linux 5.4.0 kernel with an 
Ubuntu 18.04 LTS image.

Accessing the custom device at address 0x1002 on the iobus is the precise 
goal, so given that writing to /dev/cus_device tries to write data to the 
correct address on the iobus, and I know cus_device.pio is attached to the 
iobus.master with the correct address, I am not sure why gem5 is unable to find 
the destination.  Any ideas on how to approach this issue would be greatly 
appreciated.

Best regards,
Joshua Klein

___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Read main memory directly in the timing model

2022-03-21 Thread Gabriel Busnot via gem5-users 
Hi,

I believe what you are trying to achieve is what is commonly called a 
"functional access". Though, I am not exactly sure about what is your intent 
when you say that you want to "bypass caches in order to maintain coherence" as 
it sounds contradictory to me.

If you chose to mix regular and cache-bypassing accesses to the same memory 
location without extra care, you will likely violate coherence and eventually 
face inconsistent data. The "extra care" usually consists in explicitly 
flushing caches to update main memory before bypassing the caches with 
subsequent accesses.

If you only want to maintain coherence, then you have to perform "direct memory 
accesses" using the functional access of the regular gem5 ports. This will 
result in an instantaneous access to the data you are looking for, wherever the 
most up-to-date version of the data is, while updating the caches state to 
maintain coherence.

Finally, if you really want to access main memory content and you really know 
what it can imply in terms of coherence violation, then you could directly 
connect your initiator to memory using an extra request port on the initiator 
side that you directly connect to the memory response port through a small XBar 
like the IOXBar. You will also have to bind to the XBar the port that was 
previously connected to the memory response port and the XBar output to memory. 
Don't forget to update the IOXBar default parameters to null latencies and the 
width to greater than cacheline size (likely 512 bits) in order not to 
introduce extra delays (it will still incur and extra clock cycle of delay, 
which is unlikely to cause any issue).

Best,
Gabriel
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Selecting and configuring a pre-fetcher

2022-03-21 Thread Navonil Chatterjee via gem5-users 


- Mail original -
De: "Eliot Moss via gem5-users" 
À: "gem5 users mailing list" 
Cc: "Eliot Moss" 
Envoyé: Dimanche 20 Mars 2022 00:23:01
Objet: [gem5-users] Selecting and configuring a pre-fetcher

Dear gem5-ers --

I've been running an x86 DerivO3CPU pretty much as it comes, and now would
like to configure it to correspond well to some reasonably recent Intel cpu.
I noticed that the standard config includes no prefetcher.  What would be a
reasonable prefetched configuration to set up?  What cpu is DerivO3CPU roughly
modeled on?  Other suggestions / guidance?

Regards - Eliot Moss
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Issue with strange virtual address access

2022-03-21 Thread liyan.chen--- via gem5-users 
Hi all,

I used the following command to view the virtual address translation process.

  build/X86/gem5.opt --debug-flags=Exec,TLB 
--debug-file=/home/liyan/Desktop/gem5/m5out/debug.txt configs/example/se.py 
--cpu-type=TimingSimpleCPU --caches --l2cache --mem-type=DRAMsim3 --num-cpus=1 
-c "tests/test-progs/hello/bin/x86/linux/hello" 

However, I found some strange virtual address such as 0x7fffee20

  56500: system.cpu.dtb: Translating vaddr 0x7fffee20.
  56500: system.cpu.dtb: In protected mode.
  56500: system.cpu.dtb: Paging enabled.
  56500: system.cpu.dtb: Handling a TLB miss for address 0x7fffee20 at pc 
0x400a55.
  56500: system.cpu.dtb: Mapping 0x7fffe000 to 0xbd000
  56500: system.cpu.dtb: Miss was serviced.
  56500: system.cpu.dtb: Entry found with paddr 0xbd000, doing protection 
checks.
  56500: system.cpu.dtb: Translated 0x7fffee20 -> 0xbde20.

And it(0x7fffee20) also appears here(I don't know whether there is any 
relationship)

  56500: system.cpu T0 : @_start+5: pop rsi   
  56500: system.cpu T0 : @_start+5.0  :   POP_R : ldis   t1, SS:[rsp] : MemRead 
:  D=0x0001 A=0x7fffee20
 110500: system.cpu T0 : @_start+5.1  :   POP_R : addi   rsp, rsp, 0x8 : IntAlu 
:  D=0x7fffee28
 110500: system.cpu T0 : @_start+5.2  :   POP_R : mov   rsi, rsi, t1 : IntAlu : 
 D=0x0001

Then I used following command to check the address in hello.dump file but 
didn't find such address.

  objdump -D hello > hello.dump

I'm not familiar with the compilation process and work flow of the core. Does 
anyone know why these address exist?

Any ideas are appreciated! Please reply if you have some advice. Thanks in 
advance!

Liyan Chen
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] ARM model - load instruction reads non-zero data from an address which was not written out prior (as per traces)

2022-03-21 Thread tom jose via gem5-users 
Hi ,
I was going through the load and store instructions from the GEM5 traces
and i could see that at some instances, the load instruction reads from an
address which was not written with valid data before. How is it reading
non-zero data from an address which was not written to? (From the GEM5
traces, there was no store done to the address to which we are trying to
read later on)
Example:
ldr   x28, [x0, #8]
lets say address = 0x7efe28
and this results in reading 0x004471e3 and storing in x28
But there was no memory write to 0x7efe28 done prior. So how are we
getting  0x004471e3?

Also, I tried running the simulation with Debug-Flags as "All" and i could
see :
system.cpu_cluster.cpus.execute: Memory data[0]: 0xe3
the e3 is the lower bits in the data which is read. So how is the upper
bits obtained?

details on the run:
./build/ARM/gem5.opt --debug-flags=All --debug-file=bm1_a77_trace
./configs/example/arm/starter_se.py --cpu minor --cpu-freq 3.0GHz
--mem-type DDR4_2400_8x8 ./tests/bm1

So is there a way to identify which process is writing data to these
addresses? Can i get them printed out to the GEM5 traces?

Please let me know if you require more information from my end.
Regards,
Tom
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s