[gem5-users] Re: Fail to Boot Multicore Arm System with KVM CPU

[Wenqi Yin via gem5-users]

HI Giacomo, 

I add that line of code you pointed me to to the fs_bigLittle.py, now I can 
boot into the terminal, however, the kernel cannot bring all but one cpu 
online. It’s also a bit strange in the sense that I specify ‘-smp 12’, and 
inside the guest when I check lscpu, it shows total of 13 CPUs and only cpu0 is 
online, cpu1-12 are offline. 

I tried both the stock kernel as well as compiling kernel myself following your 
suggestions from earlier email, both have the same issue. Do you have any 
suggestions on what could be causing the problem?

Best, 
Wenqi

> On Apr 1, 2021, at 03:28, Giacomo Travaglini  
> wrote:
> 
> Yes, apologies, I forgot to mention that.
> As your host is likely using a GICv3 interrupt controller, you need to 
> entirely emulate the GICv2 and Generic Timer in userspace (gem5).
> 
> This is done via the simulate_gic (as you have already done) and by removing 
> the system register interface info from the DTB node
> 
> Here's an example:
> 
> https://github.com/gem5/gem5/blob/stable/tests/gem5/configs/arm_generic.py#L99
> 
> Let me know if this works
> 
> Kind Regards
> 
> Giacomo
> 
> 
>> -Original Message-
>> From: wq...@utexas.edu 
>> Sent: 31 March 2021 19:18
>> To: Giacomo Travaglini ; gem5 users mailing
>> list ; wq...@utexas.edu
>> Subject: Re: [gem5-users] Fail to Boot Multicore Arm System with KVM CPU
>> 
>> Hi Giacomo,
>> 
>> Thanks for your reply. I tried the solution you suggested, but seems there
>> are still problems. Just make sure I understood correctly, I specified the
>> 'machine-type' as 'VExpress_GEM5_V1' and in the VExpress_GEM5_V1_Base
>> class's definition (src/dev/arm/RealView.py), when instantiating the gic, I 
>> use:
>> 
>> gic = kvm_gicv2_class(dist_addr=0x2c001000, cpu_addr=0x2c002000,
>>   it_lines=512, gem5_extensions=True)
>> 
>> The kvm_gicv2_class will be resolved as MuxingKvmGic, which inherent from
>> GicV2 class. To make sure the change applied, I also change the default value
>> of gem5_extensions from False to True in the GicV2 class's definition
>> (src/dev/arm/Gic.py). After rebuild, when starting gem5 there will be a panic
>> says "KVM: failed to create virtual CPU" (from /src/cpu/kvm/vm.cc, when
>> using ioctl to create vcpu)
>> 
>> Another thing I tried is to set the "simulate_gic" of the MuxingKvmGic class
>> from False to True, this seems help me get around the vCPU creation failure,
>> however, at some point it faces an assertion failure of:
>> 
>> gem5.opt: build/ARM/sim/eventq.hh:763: void
>> EventQueue::schedule(Event*, Tick, bool): Assertion `when >= getCurTick()'
>> failed.
>> Program aborted at tick 112565277000
>> 
>> Best,
>> 
>> Wenqi
>> 
>> On 3/31/21 7:57 AM, Giacomo Travaglini wrote:
>>> Hi Wenqi,
>>> 
>>> First of all thanks for the detailed explanation of your problem.
>>> 
 -Original Message-
 From: wqyin--- via gem5-users 
 Sent: 30 March 2021 22:47
 To: gem5-users@gem5.org; wq...@utexas.edu
 Cc: wq...@utexas.edu
 Subject: [gem5-users] Fail to Boot Multicore Arm System with KVM CPU
 
 Hello all,
 
 I am trying to model a multicore arm64 system with the
 example/arm/fs_bigLittle.py using kvm cpu. However, when I specify "-
 machine-type VExpress_Gem5_V2_XXX", the kernel panic during booting,
 giving an error message of:
 
 [0.00] GICv3: Distributor has Range Selector support [0.00]
 GICv3: no VLPI support, direct LPI support [0.00] ITS [mem
 0x2e01-0x2e02] [0.00] ITS@0x2e01: allocated
 262144 Devices
 @fc60 (flat, esz 8, psz 64K, shr 1)
 [0.00] ITS@0x2e01: allocated 8192 Interrupt
>> Collections
 @fc46 (flat, esz 8, psz 64K, shr 1) [0.00] GIC: using LPI 
 property
 table @0xfc47 [0.00] ITS: Allocated 1792 chunks for
>> LPIs
 [0.00] GICv3: CPU0: found redistributor 0 region
 0:0x2c01
 [0.00] CPU0: using LPI pending table @0xfc48
>> [0.00]
 GIC: using cache flushing for LPI property table [0.00] GICv3: GIC:
 unable to set SRE (disabled at EL2), panic ahead [0.00] 
 
>> [ cut
 here ] [0.00] kernel BUG at /work/gem5-
 scripts/submodules/linux/arch/arm64/kernel/entry.S:602!
 [0.00] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [
 0.00]
 Modules linked in:
 [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.18.0+ #1
 [0.00] Hardware name: V2P-CA15 (DT) [0.00] pstate:
>> 8085
 (Nzcv daIf -PAN -UAO)
>>> Unfortunately KVM with GICv3 is not currently supported.
>>> 
 I saw this error message regardless of how many vCPU I try to model.
 However, when I switch to machine-type of "VExpress-Gem5", the guest
 can boot, but it only allows up to 8 vCPUs. I suppose this is because
 in thi

[gem5-users] Re: IGbE_e1000 card not connected

[Νικόλαος Ταμπουρατζής via gem5-users]

Dear Giacomo,

I use the instructions to extract the guest binaries but I get the  
same. When I try to execute without --dtb=armv8_gem5_v1_1cpu.dtb (to  
autogenerate the DTB), I get after 2 minutes the following:


[0.200664] ---[ end Kernel panic - not syncing: VFS: Unable to mount  
root fs on unknown-block(0,0) ]---



Best regards,
Nikolaos Tampouratzis


Παραθέτοντας από Giacomo Travaglini via gem5-users :


Hi Nikos,
This rings a bell:  
https://www.mail-archive.com/gem5-users@gem5.org/msg19174.html


How are you extracting the guest binaries? Make sure the kernel  
image doesn't get corrupted in the process


Kind Regards

Giacomo


-Original Message-
From: Νικόλαος Ταμπουρατζής via gem5-users 
Sent: 01 April 2021 19:25
To: gem5 users mailing list 
Cc: Νικόλαος Ταμπουρατζής 
Subject: [gem5-users] Re: IGbE_e1000 card not connected


Dear Giacomo,

Thank you very much for your very good instructions!!

Before I add the card, I download the latest v21 gem5 and execute the
following command (the dtb is updated with correct addresses):

$GEM5/build/ARM/gem5.opt -d $GEM5/node1
$GEM5/configs/example/arm/starter_fs.py --kernel=vmlinux.arm64 --disk-
image=linaro-minimal-aarch64.img --dtb=armv8_gem5_v1_1cpu.dtb

but I get kernel panic:

0: system.remote_gdb: listening for remote gdb on port 7000
info: Using bootloader at address 0x10
info: Using kernel entry physical address at 0x8008
warn: DTB file specified, but no device tree support in kernel
warn: Existing EnergyCtrl, but no enabled DVFSHandler found.
panic: panic condition !e occurred: Failed to find kernel symbol 'panic'
Memory Usage: 2619356 KBytes
Program aborted at tick 0
--- BEGIN LIBC BACKTRACE ---
/home/riscv/gem5/build/ARM/gem5.opt(_Z15print_backtracev+0x2c)[0x556
4f3e562bc]
/home/riscv/gem5/build/ARM/gem5.opt(_Z12abortHandleri+0x48)[0x5564f3
eb8828]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f1536bc0980]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f15367fbfb7]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f15367fd921]
/home/riscv/gem5/build/ARM/gem5.opt(+0xb26b8f)[0x5564f3e4ab8f]
/home/riscv/gem5/build/ARM/gem5.opt(+0xd5a1b2)[0x5564f407e1b2]
/home/riscv/gem5/build/ARM/gem5.opt(_ZN6ArmISA7FsLinux7startupEv+0
x447)[0x5564f407ea27]
/home/riscv/gem5/build/ARM/gem5.opt(+0x1983956)[0x5564f4ca7956]
/home/riscv/gem5/build/ARM/gem5.opt(+0xb54fdc)[0x5564f3e78fdc]
/usr/lib/x86_64-linux-
gnu/libpython3.6m.so.1.0(_PyCFunction_FastCallDict+0x20a)[0x7f153632558
a]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17bec8)[0x7f153628dec8]
/usr/lib/x86_64-linux-
gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f15362943
03]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17ba0f)[0x7f153628da0f]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c0fc)[0x7f153628e0fc]
/usr/lib/x86_64-linux-
gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f15362943
03]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17a803)[0x7f153628c803]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c2be)[0x7f153628e2be]
/usr/lib/x86_64-linux-
gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f15362943
03]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17a803)[0x7f153628c803]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c2be)[0x7f153628e2be]
/usr/lib/x86_64-linux-
gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f15362943
03]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17ba0f)[0x7f153628da0f]
/usr/lib/x86_64-linux-
gnu/libpython3.6m.so.1.0(PyEval_EvalCodeEx+0x3e)[0x7f153628e4ce]
/usr/lib/x86_64-linux-
gnu/libpython3.6m.so.1.0(PyEval_EvalCode+0x1b)[0x7f153628f24b]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x18855d)[0x7f153629a55d]
/usr/lib/x86_64-linux-
gnu/libpython3.6m.so.1.0(_PyCFunction_FastCallDict+0x1bb)[0x7f153632553
b]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c1ec)[0x7f153628e1ec]
/usr/lib/x86_64-linux-
gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f15362943
03]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17ba0f)[0x7f153628da0f]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c0fc)[0x7f153628e0fc]
/usr/lib/x86_64-linux-
gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f15362943
03]
--- END LIBC BACKTRACE ---
Aborted (core dumped)


Best regards,
Nikolaos Tampouratzis

Παραθέτοντας από Giacomo Travaglini via gem5-users :

> Hi Nikos,
>
>> -Original Message-
>> From: Νικόλαος Ταμπουρατζής via gem5-users 
>> Sent: 31 March 2021 21:04
>> To: gem5-users@gem5.org
>> Cc: Νικόλαος Ταμπουρατζής 
>> Subject: [gem5-users] IGbE_e1000 card not connected
>>
>> Dear gem5 community,
>>
>> I would like to use the IGbE_e1000 card in the latest gem5 version in
>> ARM FS mode. As I can see the card is connected only in VExpress_EMM
>> and VExpress_EMM64. However, I cannot boot correctly the latest gem5
>> version either in VExpress_EMM or VExpress_EMM64 using the
>> 20180409.tar.xz kernels and images from the following link:
>>
https://www.gem5.

[gem5-users] gem5 fs mode error

[ABD ALRHMAN ABO ALKHEEL via gem5-users]

Hello Everyone,

I got the following error when i run spec2006 benchmark on gem5 fs mode.
Any help would be appreciated.

Error

Aborting: command not found
abdkhail@proton:~/fs_gem5/gem5$ EXT4-fs (hda1): Remounting filesystem read-only
-bash: syntax error near unexpected token `hda1'

___
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: IGbE_e1000 card not connected

[Giacomo Travaglini via gem5-users]

Hi Nikos,
This rings a bell: 
https://www.mail-archive.com/gem5-users@gem5.org/msg19174.html

How are you extracting the guest binaries? Make sure the kernel image doesn't 
get corrupted in the process

Kind Regards

Giacomo

> -Original Message-
> From: Νικόλαος Ταμπουρατζής via gem5-users 
> Sent: 01 April 2021 19:25
> To: gem5 users mailing list 
> Cc: Νικόλαος Ταμπουρατζής 
> Subject: [gem5-users] Re: IGbE_e1000 card not connected
>
>
> Dear Giacomo,
>
> Thank you very much for your very good instructions!!
>
> Before I add the card, I download the latest v21 gem5 and execute the
> following command (the dtb is updated with correct addresses):
>
> $GEM5/build/ARM/gem5.opt -d $GEM5/node1
> $GEM5/configs/example/arm/starter_fs.py --kernel=vmlinux.arm64 --disk-
> image=linaro-minimal-aarch64.img --dtb=armv8_gem5_v1_1cpu.dtb
>
> but I get kernel panic:
>
> 0: system.remote_gdb: listening for remote gdb on port 7000
> info: Using bootloader at address 0x10
> info: Using kernel entry physical address at 0x8008
> warn: DTB file specified, but no device tree support in kernel
> warn: Existing EnergyCtrl, but no enabled DVFSHandler found.
> panic: panic condition !e occurred: Failed to find kernel symbol 'panic'
> Memory Usage: 2619356 KBytes
> Program aborted at tick 0
> --- BEGIN LIBC BACKTRACE ---
> /home/riscv/gem5/build/ARM/gem5.opt(_Z15print_backtracev+0x2c)[0x556
> 4f3e562bc]
> /home/riscv/gem5/build/ARM/gem5.opt(_Z12abortHandleri+0x48)[0x5564f3
> eb8828]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f1536bc0980]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f15367fbfb7]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f15367fd921]
> /home/riscv/gem5/build/ARM/gem5.opt(+0xb26b8f)[0x5564f3e4ab8f]
> /home/riscv/gem5/build/ARM/gem5.opt(+0xd5a1b2)[0x5564f407e1b2]
> /home/riscv/gem5/build/ARM/gem5.opt(_ZN6ArmISA7FsLinux7startupEv+0
> x447)[0x5564f407ea27]
> /home/riscv/gem5/build/ARM/gem5.opt(+0x1983956)[0x5564f4ca7956]
> /home/riscv/gem5/build/ARM/gem5.opt(+0xb54fdc)[0x5564f3e78fdc]
> /usr/lib/x86_64-linux-
> gnu/libpython3.6m.so.1.0(_PyCFunction_FastCallDict+0x20a)[0x7f153632558
> a]
> /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17bec8)[0x7f153628dec8]
> /usr/lib/x86_64-linux-
> gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f15362943
> 03]
> /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17ba0f)[0x7f153628da0f]
> /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c0fc)[0x7f153628e0fc]
> /usr/lib/x86_64-linux-
> gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f15362943
> 03]
> /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17a803)[0x7f153628c803]
> /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c2be)[0x7f153628e2be]
> /usr/lib/x86_64-linux-
> gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f15362943
> 03]
> /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17a803)[0x7f153628c803]
> /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c2be)[0x7f153628e2be]
> /usr/lib/x86_64-linux-
> gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f15362943
> 03]
> /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17ba0f)[0x7f153628da0f]
> /usr/lib/x86_64-linux-
> gnu/libpython3.6m.so.1.0(PyEval_EvalCodeEx+0x3e)[0x7f153628e4ce]
> /usr/lib/x86_64-linux-
> gnu/libpython3.6m.so.1.0(PyEval_EvalCode+0x1b)[0x7f153628f24b]
> /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x18855d)[0x7f153629a55d]
> /usr/lib/x86_64-linux-
> gnu/libpython3.6m.so.1.0(_PyCFunction_FastCallDict+0x1bb)[0x7f153632553
> b]
> /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c1ec)[0x7f153628e1ec]
> /usr/lib/x86_64-linux-
> gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f15362943
> 03]
> /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17ba0f)[0x7f153628da0f]
> /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c0fc)[0x7f153628e0fc]
> /usr/lib/x86_64-linux-
> gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f15362943
> 03]
> --- END LIBC BACKTRACE ---
> Aborted (core dumped)
>
>
> Best regards,
> Nikolaos Tampouratzis
>
> Παραθέτοντας από Giacomo Travaglini via gem5-users  us...@gem5.org>:
>
> > Hi Nikos,
> >
> >> -Original Message-
> >> From: Νικόλαος Ταμπουρατζής via gem5-users 
> >> Sent: 31 March 2021 21:04
> >> To: gem5-users@gem5.org
> >> Cc: Νικόλαος Ταμπουρατζής 
> >> Subject: [gem5-users] IGbE_e1000 card not connected
> >>
> >> Dear gem5 community,
> >>
> >> I would like to use the IGbE_e1000 card in the latest gem5 version in
> >> ARM FS mode. As I can see the card is connected only in VExpress_EMM
> >> and VExpress_EMM64. However, I cannot boot correctly the latest gem5
> >> version either in VExpress_EMM or VExpress_EMM64 using the
> >> 20180409.tar.xz kernels and images from the following link:
> >>
> https://www.gem5.org/documentation/general_docs/fullsystem/guest_bin
> >> aries.
> >>
> >> So I achieve to boot the gem5 using the VExpress_GEM5_V1 machine
> type
> >> (specifically through this configuration: $GEM5/b

[gem5-users] Re: IGbE_e1000 card not connected

[Νικόλαος Ταμπουρατζής via gem5-users]

Dear Giacomo,

Thank you very much for your very good instructions!!

Before I add the card, I download the latest v21 gem5 and execute the  
following command (the dtb is updated with correct addresses):


$GEM5/build/ARM/gem5.opt -d $GEM5/node1  
$GEM5/configs/example/arm/starter_fs.py --kernel=vmlinux.arm64  
--disk-image=linaro-minimal-aarch64.img --dtb=armv8_gem5_v1_1cpu.dtb


but I get kernel panic:

0: system.remote_gdb: listening for remote gdb on port 7000
info: Using bootloader at address 0x10
info: Using kernel entry physical address at 0x8008
warn: DTB file specified, but no device tree support in kernel
warn: Existing EnergyCtrl, but no enabled DVFSHandler found.
panic: panic condition !e occurred: Failed to find kernel symbol 'panic'
Memory Usage: 2619356 KBytes
Program aborted at tick 0
--- BEGIN LIBC BACKTRACE ---
/home/riscv/gem5/build/ARM/gem5.opt(_Z15print_backtracev+0x2c)[0x5564f3e562bc]
/home/riscv/gem5/build/ARM/gem5.opt(_Z12abortHandleri+0x48)[0x5564f3eb8828]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f1536bc0980]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f15367fbfb7]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f15367fd921]
/home/riscv/gem5/build/ARM/gem5.opt(+0xb26b8f)[0x5564f3e4ab8f]
/home/riscv/gem5/build/ARM/gem5.opt(+0xd5a1b2)[0x5564f407e1b2]
/home/riscv/gem5/build/ARM/gem5.opt(_ZN6ArmISA7FsLinux7startupEv+0x447)[0x5564f407ea27]
/home/riscv/gem5/build/ARM/gem5.opt(+0x1983956)[0x5564f4ca7956]
/home/riscv/gem5/build/ARM/gem5.opt(+0xb54fdc)[0x5564f3e78fdc]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyCFunction_FastCallDict+0x20a)[0x7f153632558a]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17bec8)[0x7f153628dec8]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f1536294303]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17ba0f)[0x7f153628da0f]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c0fc)[0x7f153628e0fc]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f1536294303]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17a803)[0x7f153628c803]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c2be)[0x7f153628e2be]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f1536294303]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17a803)[0x7f153628c803]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c2be)[0x7f153628e2be]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f1536294303]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17ba0f)[0x7f153628da0f]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyEval_EvalCodeEx+0x3e)[0x7f153628e4ce]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyEval_EvalCode+0x1b)[0x7f153628f24b]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x18855d)[0x7f153629a55d]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyCFunction_FastCallDict+0x1bb)[0x7f153632553b]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c1ec)[0x7f153628e1ec]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f1536294303]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17ba0f)[0x7f153628da0f]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c0fc)[0x7f153628e0fc]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f1536294303]
--- END LIBC BACKTRACE ---
Aborted (core dumped)


Best regards,
Nikolaos Tampouratzis

Παραθέτοντας από Giacomo Travaglini via gem5-users :


Hi Nikos,


-Original Message-
From: Νικόλαος Ταμπουρατζής via gem5-users 
Sent: 31 March 2021 21:04
To: gem5-users@gem5.org
Cc: Νικόλαος Ταμπουρατζής 
Subject: [gem5-users] IGbE_e1000 card not connected

Dear gem5 community,

I would like to use the IGbE_e1000 card in the latest gem5 version in ARM FS
mode. As I can see the card is connected only in VExpress_EMM and
VExpress_EMM64. However, I cannot boot correctly the latest gem5 version
either in VExpress_EMM or VExpress_EMM64 using the 20180409.tar.xz
kernels and images from the following link:
https://www.gem5.org/documentation/general_docs/fullsystem/guest_bin
aries.

So I achieve to boot the gem5 using the VExpress_GEM5_V1 machine type
(specifically through this configuration: $GEM5/build/ARM/gem5.opt -d
$GEM5/node0 $GEM5/configs/example/fs.py
--kernel=vmlinux.vexpress_gem5_v1_64
--disk-image=linaro-minimal-aarch64.img
--machine-type=VExpress_GEM5_V1 --dtb=armv7_gem5_v1_1cpu.dtb).


It not related to your problem, but:

1) You are using an armv8 kernel, with an armv7 DTB
2) We tend to discourage using fs.py for Arm simulations; I would  
recommend you having a look
At either configs/example/arm/fs_bigLITTLE.py or  
configs/example/arm/starter_fs.py depending on what you are trying  
to model




However, the IGbE_e1000 card is not included in the VExpress_GEM5_V1...
So I tried to connect it in VExpress_GEM5_Base (which is used from
VExpress_GEM5_V1). Specifically,

1) I add the following (below pci_host = Gen

[gem5-users] Re: understanding commMonitor output

[Joardar, Biresh Kumar via gem5-users]

Hi Miguel,
Thanks for the answer. I prepared my setup following this link and some other 
earlier discussions on the mailing list. Looks like my setup is ok. However, I 
am still confused about the actual physical address representation. Following 
is the trace I observe. The 3rd column is the physical address. Memory address 
is commonly represented using Hexadecimal format but there is no alphabet in 
the trace file. Is the address using decimal representation?
5,u,531425792,64,256,4986860244500
6,u,535891200,64,2,4986860333000
9,u,529653760,64,512,4986868293000
9,u,530137088,64,512,4986868293000
9,u,529657856,64,512,4986868293000

Thanks again,
Biresh

On Apr 1, 2021, at 3:40 AM, Miguel Antonio Avargues Gutiérrez via gem5-users 
mailto:gem5-users@gem5.org>> wrote:

Hope this helps, 
https://stackoverflow.com/questions/61052733/obtaining-physical-address-trace-from-gem5.

Greetings,
Miguel Antonio Avargues Gutiérrez.

El 31/03/2021 a las 18:57, Joardar, Biresh Kumar via gem5-users escribió:
Hello,
I intend to observe all the physical DRAM addresses that are accessed when an 
application is being executed in full-system mode. Following some earlier 
discussions on this mailing list, I used the commMonitor. I added the following 
lines to fs.py file:
test_sys.monitor = CommMonitor()
test_sys.monitor.trace = MemTraceProbe(trace_file = "monitor.ptrc.gz")

Next, I connected the CommMonitor as follows in the CacheConfig.py file:
system.l2.mem_side = system.monitor.slave
system.monitor.master = system.membus.slave

I create and then restore from a checkpoint just before the application is 
started. Following is my command line:
./build/X86/gem5.opt configs/example/fs.py --kernel 
/home/myComputer/Desktop/x86_64-vmlinux-2.6.28.4-smp --disk-image 
/home/myComputer/Desktop/x86root-parsec.img --script 
/home/myComputer/Desktop/gem5/configs/boot/test.rcS --caches --l2cache 
--checkpoint-restore=1 --restore-with-cpu=TimingSimpleCPU

Next, I use the decode_packet_trace.py file in utils folder to process the 
.ptrc file obtained after simulation. Following is a sample of the output of 
this step:
5,u,531425792,64,256,4986860244500
6,u,535891200,64,2,4986860333000
9,u,529653760,64,512,4986868293000
9,u,530137088,64,512,4986868293000
9,u,529657856,64,512,4986868293000
9,u,530022400,64,512,4986868293000
10,u,531425216,64,256,4986868293000
8,u,529655744,64,512,4986868294500
8,u,521711552,64,512,4986868294500
...

The 3rd column in this output seems to be the address. However, DRAM addresses 
are usually represented in Hexadecimal format. In the entire output file, I did 
not find any alphabet character. All addresses are just numbers. Is this 
expected output? Do I need to convert these addresses to hexadecimal format 
manually next or did I make a mistake in the full-sytem setup?
Thanks,
Biresh



___
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 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: IGbE_e1000 card not connected

[Giacomo Travaglini via gem5-users]

Hi Nikos,

> -Original Message-
> From: Νικόλαος Ταμπουρατζής via gem5-users 
> Sent: 31 March 2021 21:04
> To: gem5-users@gem5.org
> Cc: Νικόλαος Ταμπουρατζής 
> Subject: [gem5-users] IGbE_e1000 card not connected
>
> Dear gem5 community,
>
> I would like to use the IGbE_e1000 card in the latest gem5 version in ARM FS
> mode. As I can see the card is connected only in VExpress_EMM and
> VExpress_EMM64. However, I cannot boot correctly the latest gem5 version
> either in VExpress_EMM or VExpress_EMM64 using the 20180409.tar.xz
> kernels and images from the following link:
> https://www.gem5.org/documentation/general_docs/fullsystem/guest_bin
> aries.
>
> So I achieve to boot the gem5 using the VExpress_GEM5_V1 machine type
> (specifically through this configuration: $GEM5/build/ARM/gem5.opt -d
> $GEM5/node0 $GEM5/configs/example/fs.py
> --kernel=vmlinux.vexpress_gem5_v1_64
> --disk-image=linaro-minimal-aarch64.img
> --machine-type=VExpress_GEM5_V1 --dtb=armv7_gem5_v1_1cpu.dtb).

It not related to your problem, but:

1) You are using an armv8 kernel, with an armv7 DTB
2) We tend to discourage using fs.py for Arm simulations; I would recommend you 
having a look
At either configs/example/arm/fs_bigLITTLE.py or 
configs/example/arm/starter_fs.py depending on what you are trying to model

>
> However, the IGbE_e1000 card is not included in the VExpress_GEM5_V1...
> So I tried to connect it in VExpress_GEM5_Base (which is used from
> VExpress_GEM5_V1). Specifically,
>
> 1) I add the following (below pci_host = GenericArmPciHost)
>
> # Attach any PCI devices that are supported def attachPciDevices(self):
> self.ethernet = IGbE_e1000(pci_bus=0, pci_dev=0, pci_func=0,
> InterruptLine=1, InterruptPin=1)
>
> 2) I add the self.ethernet in def _off_chip_devices(self).
>
> Unfortunatelly, I get the following error after 2 minutes of simulation 
> (during
> this message: [0.135098] e1000 :00:00.0:
> enabling device ( -> 0002)):
>
> fatal: system.iobus has two ports responding within range
> [0x8000:0x8002]:
>  system.realview.ethernet.pio
>  system.iobridge.cpu_side_port
>
> Looking in previous gem5 versions, in the GenericArmPciHost there is not the
> "pci_mem_base=0x4000". So, I remove this and I am able to boot Linux
> and see the eth0 but I do not know if is correct to remove the
> pci_mem_base.

By removing the pci_mem_base you are basically removing the 0x4000 offset
And this is why the PIO address range stops overlapping with the iobridge.

>
> I would appreciate it if anyone would like to explain me please! :)
>
> Best regards,
> Nikos
> ___
> 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

Your problem has luckily been solved by the gem5-21 release (I presume you are 
using 20.1 as 21 has just been released):

https://gem5-review.googlesource.com/c/public/gem5/+/39915

So checking out gem5-21 and recompiling the DTB should work.
However as I have already mentioned I recommend you to adopt a different config 
script if possible.

For example I am able to boot with the ethernet device by simply adding it to 
the PCI device list in starter_fs.py (I haven't tested its functionalities 
though)

diff --git a/configs/example/arm/starter_fs.py 
b/configs/example/arm/starter_fs.py
index 11190dbd6..d283e77c2 100644
--- a/configs/example/arm/starter_fs.py
+++ b/configs/example/arm/starter_fs.py
@@ -115,6 +115,7 @@ def create(args):
 # functionality to avoid writing changes to the stored copy of
 # the disk image.
 PciVirtIO(vio=VirtIOBlock(image=create_cow_image(args.disk_image))),
+IGbE_e1000(InterruptLine=1, InterruptPin=1)
 ]

No change to RealView.py and hence no recompilation  is needed: PCI devices are 
instantiated in the top level script (rather than in the platform module)
I am also relying on DTB autogeneration, so the command-line is as simple as 
(note I haven't specified the DTB):

$build/ARM/gem5.opt configs/example/arm/starter_fs.py --kernel vmlinux.arm64 
--disk-image ubuntu-18.04-arm64-docker.img

Kind Regards

Giacomo
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: m5 utility for ARM64

[Giacomo Travaglini via gem5-users]

Thanks Gabe for providing support.

I just want to add: judging by the disk image name 
(ubuntu-18.04-arm64-docker.img) I presume it is the prebuilt image provided by 
the gem5.org website.
That should already have the new m5 binary, so recompilation won't be 
necessary, and you can simply use m5 ops via

$m5 --addr 0x1001 exit

Kind Regards

Giacomo

> -Original Message-
> From: Gabe Black via gem5-users 
> Sent: 01 April 2021 04:02
> To: gem5 users mailing list 
> Cc: Gabe Black 
> Subject: [gem5-users] Re: m5 utility for ARM64
>
> Hi Jeageun, you should take a look at util/m5/README.md for an explanation
> of how the m5 utility works and how it should be used in different
> environments. It looks like it's trying to use the instruction based mechanism
> to call into gem5, and that won't work in KVM. In KVM, you have to use the
> magic address based mechanism. That's all spelled out in that README. There
> are also instructions there for building the utility if your version is too 
> old and
> doesn't have the updates reflected in that document. The older m5 utility
> would have to be recompiled to use a different mechanism, where with the
> new version you can select what mechanism to use from the command line.
>
> Gabe
>
> On Wed, Mar 31, 2021 at 7:11 PM JeaGeun Jung via gem5-users  us...@gem5.org  > wrote:
>
>
> Hi all,
>
> I'm trying to use m5 exit on the ARM image using
> http://dist.gem5.org/dist/current/arm/aarch-system-
> 201901106.tar.bz2.
>
> I boot this image using the following instruction
>
> ./build/ARM/gem5.opt configs/example/fs.py --kernel
> /data/gem5_image/vmlinux --disk-image /data/gem5_image/ubuntu-18.04-
> arm64-docker.img --mem-size=16GB --cpu-type=ArmV8KvmCPU -n4 --cpu-
> clock=3.2GHz
>
>
> In short, kvm cpu boot for ARM full system.
>
> In the gem5 image, I tried m5 exit, and it prints an error message.
> I use most updated gem5 develop branch.
>
> root@aarch64-gem5:~# m5 exit
> [  125.384290] m5[737]: undefined instruction: pc=00409290
> [  125.386245] Code: ff070110 d65f03c0 ff090110 d65f03c0 (ff210110)
> Illegal instruction
>
>
> I tried to compile m5 binary in gem5 image, but it doesn't work. How
> could I fix this bug?
>
> Thanks,
> Jeageun
>
>
>  FzLmVkdQ%3D%3D&type=zerocontent&guid=e24f5cca-555e-4bf7-b007-
> 4ad429b08dd6> ᐧ
> ___
> gem5-users mailing list -- gem5-users@gem5.org  us...@gem5.org>
> To unsubscribe send an email to gem5-users-le...@gem5.org
> 
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

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: Fail to Boot Multicore Arm System with KVM CPU

[Giacomo Travaglini via gem5-users]

Yes, apologies, I forgot to mention that.
As your host is likely using a GICv3 interrupt controller, you need to entirely 
emulate the GICv2 and Generic Timer in userspace (gem5).

This is done via the simulate_gic (as you have already done) and by removing 
the system register interface info from the DTB node

Here's an example:

https://github.com/gem5/gem5/blob/stable/tests/gem5/configs/arm_generic.py#L99

Let me know if this works

Kind Regards

Giacomo


> -Original Message-
> From: wq...@utexas.edu 
> Sent: 31 March 2021 19:18
> To: Giacomo Travaglini ; gem5 users mailing
> list ; wq...@utexas.edu
> Subject: Re: [gem5-users] Fail to Boot Multicore Arm System with KVM CPU
>
> Hi Giacomo,
>
> Thanks for your reply. I tried the solution you suggested, but seems there
> are still problems. Just make sure I understood correctly, I specified the
> 'machine-type' as 'VExpress_GEM5_V1' and in the VExpress_GEM5_V1_Base
> class's definition (src/dev/arm/RealView.py), when instantiating the gic, I 
> use:
>
> gic = kvm_gicv2_class(dist_addr=0x2c001000, cpu_addr=0x2c002000,
>it_lines=512, gem5_extensions=True)
>
> The kvm_gicv2_class will be resolved as MuxingKvmGic, which inherent from
> GicV2 class. To make sure the change applied, I also change the default value
> of gem5_extensions from False to True in the GicV2 class's definition
> (src/dev/arm/Gic.py). After rebuild, when starting gem5 there will be a panic
> says "KVM: failed to create virtual CPU" (from /src/cpu/kvm/vm.cc, when
> using ioctl to create vcpu)
>
> Another thing I tried is to set the "simulate_gic" of the MuxingKvmGic class
> from False to True, this seems help me get around the vCPU creation failure,
> however, at some point it faces an assertion failure of:
>
> gem5.opt: build/ARM/sim/eventq.hh:763: void
> EventQueue::schedule(Event*, Tick, bool): Assertion `when >= getCurTick()'
> failed.
> Program aborted at tick 112565277000
>
> Best,
>
> Wenqi
>
> On 3/31/21 7:57 AM, Giacomo Travaglini wrote:
> > Hi Wenqi,
> >
> > First of all thanks for the detailed explanation of your problem.
> >
> >> -Original Message-
> >> From: wqyin--- via gem5-users 
> >> Sent: 30 March 2021 22:47
> >> To: gem5-users@gem5.org; wq...@utexas.edu
> >> Cc: wq...@utexas.edu
> >> Subject: [gem5-users] Fail to Boot Multicore Arm System with KVM CPU
> >>
> >> Hello all,
> >>
> >> I am trying to model a multicore arm64 system with the
> >> example/arm/fs_bigLittle.py using kvm cpu. However, when I specify "-
> >> machine-type VExpress_Gem5_V2_XXX", the kernel panic during booting,
> >> giving an error message of:
> >>
> >> [0.00] GICv3: Distributor has Range Selector support [0.00]
> >> GICv3: no VLPI support, direct LPI support [0.00] ITS [mem
> >> 0x2e01-0x2e02] [0.00] ITS@0x2e01: allocated
> >> 262144 Devices
> >> @fc60 (flat, esz 8, psz 64K, shr 1)
> >> [0.00] ITS@0x2e01: allocated 8192 Interrupt
> Collections
> >> @fc46 (flat, esz 8, psz 64K, shr 1) [0.00] GIC: using LPI 
> >> property
> >> table @0xfc47 [0.00] ITS: Allocated 1792 chunks for
> LPIs
> >> [0.00] GICv3: CPU0: found redistributor 0 region
> >> 0:0x2c01
> >> [0.00] CPU0: using LPI pending table @0xfc48
> [0.00]
> >> GIC: using cache flushing for LPI property table [0.00] GICv3: GIC:
> >> unable to set SRE (disabled at EL2), panic ahead [0.00] 
> >> 
> [ cut
> >> here ] [0.00] kernel BUG at /work/gem5-
> >> scripts/submodules/linux/arch/arm64/kernel/entry.S:602!
> >> [0.00] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [
> >> 0.00]
> >> Modules linked in:
> >> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.18.0+ #1
> >> [0.00] Hardware name: V2P-CA15 (DT) [0.00] pstate:
> 8085
> >> (Nzcv daIf -PAN -UAO)
> > Unfortunately KVM with GICv3 is not currently supported.
> >
> >> I saw this error message regardless of how many vCPU I try to model.
> >> However, when I switch to machine-type of "VExpress-Gem5", the guest
> >> can boot, but it only allows up to 8 vCPUs. I suppose this is because
> >> in this config it doesn't support GICv3.
> >>
> >> For my use case, I do need more than 8 cpus in the modeled system,
> >> can anyone help me here?
> > We provide a workaround for that, allowing you to use more than 8 CPUs
> with GICv2.
> > That requires you to set the Gicv2.gem5_extensions parameter to True.
> > A change in the Linux GIC driver is also needed. IIRC the prebuilt binary
> should already contain that.
> > If not, you would have to rebuild the kernel yourself from the following
> Linux fork:
> >
> > https://gem5.googlesource.com/arm/linux/+/refs/heads/gem5/v4.15
> >
> > (Use the gem5_defconfig)
> >
> > Let me know if it works
> >
> >> Here is the environment I used for the experiment:
> >>
> >> Host: aarch64 pla

[gem5-users] Re: understanding commMonitor output

[Miguel Antonio Avargues Gutiérrez via gem5-users]

Hope this helps, 
https://stackoverflow.com/questions/61052733/obtaining-physical-address-trace-from-gem5.


Greetings,
Miguel Antonio Avargues Gutiérrez.

El 31/03/2021 a las 18:57, Joardar, Biresh Kumar via gem5-users escribió:

Hello,
I intend to observe all the physical DRAM addresses that are accessed 
when an application is being executed in full-system mode. Following 
some earlier discussions on this mailing list, I used the commMonitor. 
I added the following lines to fs.py file:

test_sys.monitor = CommMonitor()
test_sys.monitor.trace = MemTraceProbe(trace_file = "monitor.ptrc.gz")

Next, I connected the CommMonitor as follows in the CacheConfig.py file:
system.l2.mem_side = system.monitor.slave
system.monitor.master = system.membus.slave

I create and then restore from a checkpoint just before the 
application is started. Following is my command line:
./build/X86/gem5.opt configs/example/fs.py --kernel 
/home/myComputer/Desktop/x86_64-vmlinux-2.6.28.4-smp --disk-image 
/home/myComputer/Desktop/x86root-parsec.img --script 
/home/myComputer/Desktop/gem5/configs/boot/test.rcS --caches --l2cache 
--checkpoint-restore=1 --restore-with-cpu=TimingSimpleCPU


Next, I use the decode_packet_trace.py file in utils folder to process 
the .ptrc file obtained after simulation. Following is a sample of the 
output of this step:

5,u,531425792,64,256,4986860244500
6,u,535891200,64,2,4986860333000
9,u,529653760,64,512,4986868293000
9,u,530137088,64,512,4986868293000
9,u,529657856,64,512,4986868293000
9,u,530022400,64,512,4986868293000
10,u,531425216,64,256,4986868293000
8,u,529655744,64,512,4986868294500
8,u,521711552,64,512,4986868294500
...

The 3rd column in this output seems to be the address. However, DRAM 
addresses are usually represented in Hexadecimal format. In the entire 
output file, I did not find any alphabet character. All addresses are 
just numbers. Is this expected output? Do I need to convert these 
addresses to hexadecimal format manually next or did I make a mistake 
in the full-sytem setup?

Thanks,
Biresh


___
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: IGbE_e1000 card not connected

[Νικόλαος Ταμπουρατζής via gem5-users]

Dear Gabe,

I use the latest version of gem5 (I download it before 5 days). Please  
follow my instructions and I think that you can reproduce the error.


Best regards,
Nikos


Παραθέτοντας από Gabe Black via gem5-users :


Hi Nikos, how old is your gem5 checkout? The change below fixed some
aspects of how PCI devices are managed, including one which could cause
failures like you're seeing.

commit 9be18aa66ddb8db4da043279819d45bc72b7b086
Author: Gabe Black 
Date:   Fri Oct 2 03:00:04 2020 -0700

On Wed, Mar 31, 2021 at 1:04 PM Νικόλαος Ταμπουρατζής via gem5-users <
gem5-users@gem5.org> wrote:


Dear gem5 community,

I would like to use the IGbE_e1000 card in the latest gem5 version in
ARM FS mode. As I can see the card is connected only in VExpress_EMM
and VExpress_EMM64. However, I cannot boot correctly the latest gem5
version either in VExpress_EMM or VExpress_EMM64 using the
20180409.tar.xz kernels and images from the following link:
https://www.gem5.org/documentation/general_docs/fullsystem/guest_binaries.

So I achieve to boot the gem5 using the VExpress_GEM5_V1 machine type
(specifically through this configuration: $GEM5/build/ARM/gem5.opt -d
$GEM5/node0 $GEM5/configs/example/fs.py
--kernel=vmlinux.vexpress_gem5_v1_64
--disk-image=linaro-minimal-aarch64.img
--machine-type=VExpress_GEM5_V1 --dtb=armv7_gem5_v1_1cpu.dtb).

However, the IGbE_e1000 card is not included in the
VExpress_GEM5_V1... So I tried to connect it in VExpress_GEM5_Base
(which is used from VExpress_GEM5_V1). Specifically,

1) I add the following (below pci_host = GenericArmPciHost)

# Attach any PCI devices that are supported
def attachPciDevices(self):
self.ethernet = IGbE_e1000(pci_bus=0, pci_dev=0, pci_func=0,
InterruptLine=1, InterruptPin=1)

2) I add the self.ethernet in def _off_chip_devices(self).

Unfortunatelly, I get the following error after 2 minutes of
simulation (during this message: [0.135098] e1000 :00:00.0:
enabling device ( -> 0002)):

fatal: system.iobus has two ports responding within range
[0x8000:0x8002]:
 system.realview.ethernet.pio
 system.iobridge.cpu_side_port

Looking in previous gem5 versions, in the GenericArmPciHost there is
not the "pci_mem_base=0x4000". So, I remove this and I am able to
boot Linux and see the eth0 but I do not know if is correct to remove
the pci_mem_base.

I would appreciate it if anyone would like to explain me please! :)

Best regards,
Nikos
___
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