Hi Matheus, ARM full-system simulation is actively used by a large number of people, and is well supported. At the moment you can use up to 8 cores.
Currently Ruby has some assumptions that prevents it from being used with ARM full-system simulation, so if that is what you are after there is some work to be done. That said, the gem5 memory system has the Cache, CoherentXBar, NoncoherentXBar, Bridge and DRAMCtrl components that you can use to build elaborate (and representative) on-chip memory systems. The flexibility of the components allow you to build many flavours of NUCA, NUMA systems, with striping/interleaving, snoop filtering, multi-hop crossbars etc. I would think this is enough for most use-cases. Andreas On 03/01/2015 00:04, "Matheus Alcântara Souza via gem5-users" <[email protected]> wrote: >Dear all, > >First, I wish you success and fortune in 2015. > >Reading C. Dirik question, I would ask if it is possible to simulate NoC >using ARM ISA and a FullSystem simulation. > >Maybe using Garnet, and up to how many cores? > >Thank you in advance! >Matheus Alcântara Souza > >> Em 02/01/2015, às 20:26, Cagdas Dirik (cdirik) via gem5-users >><[email protected]> escreveu: >> >> Thank you for the recommendation Andreas :) >> >> We (my team) will be looking at ARM full system pretty soon. For the >>time being though, I am working to get our X86 systems up and running. >> >> As a reference to others working on X86, I have resolved my issue. It >>was due to my inexperience with linux kernel development. I was using >> $ make vmlinux >> command and was trying to boot the simulator with >>linux-x.y.z/arch/x86/boot/compressed/vmlinux file. Apparently this files >>does not contain boot information - hence simulator would stuck at the >>very beginning. >> If instead I just use >> $ make >> and boot the simulator using linux-x.y.z/vmlinux file, everything >>continues as expected. >> >> Cagdas >> >> On Dec 20, 2014, at 8:59 AM, Andreas Hansson >><[email protected]<mailto:[email protected]>> wrote: >> >> Hi Cagdas, >> >> Merely a reflection on my side...I get the impression there is not many >>gem5 users out there doing X86 full system (based on the mailing list >>activity). With the risk of sounding a bit biased, the ARM full system >>support is far more tested and, I would argue, stable. ARM full system >>works with the latest and greatest in terms of Linux kernels, and also >>supports features like DVFS >>(http://www.gem5.org/Running_gem5#Experimenting_with_DVFS). I realise it >>might not fit with your use-case, but just in case. >> >> Andreas >> >> From: "Cagdas Dirik via gem5-users (cdirik)" >><[email protected]<mailto:[email protected]>> >> Reply-To: "Cagdas Dirik (cdirik)" >><[email protected]<mailto:[email protected]>>, gem5 users mailing list >><[email protected]<mailto:[email protected]>> >> Date: Saturday, 20 December 2014 00:54 >> To: gem5 users mailing list >><[email protected]<mailto:[email protected]>> >> Subject: [gem5-users] building kernel for X86 - gem5 hangs at the very >>beginning with new kernel >> >> Hi, >> >> I am trying to build my own kernel, boot my own disk image, and run X86 >>in FS mode . However I am running into issues with fresh built kernel >>because gem5 hangs at the very beginning, nothing happens. >> I can boot my debian image on qemu. I can also boot this image using >>out-of-box 2.6.22.9 kernel (although udev fails since it requires >>version 2.6.26) >> But I cannot boot this image using fresh built kernel. I tried both dev >>branch and stable branch. I also tried 2.6.26, 2.6.31 versions. All hang >>in the same way. I don’t suspect anything different on kernel config >>(especially with CPU type). >> >> I will follow guidelines in debugging page, and do some trace based >>debugging. But in the meantime, if someone can give me a hint I will >>greatly appreciate it. Are there any tool dependencies on building >>kernels for gem5? Are there any other small details others experienced >>that I am missing? Do others run into issues building their own kernel >>for gem5? >> >> One interesting thing is that when I compare my kernel vs. out-of-box >>kernel, entry point addresses looks suspiciously different (0x200 vs. >>0x200000 on out-of-box kernel). That may result in jumping to an >>unexpected address and result in system hang. Does anyone have any ideas >>why these addresses differ significantly? Or would that be an issue? >> >> Below are details and my command lines for reference. >> >> Thanks in advance! >> >> Cagdas >> >> I downloaded kernel 2.6.28.4 (since x86 full system downloads come with >>2.6.28.4 config). My steps building the kernel (nothing out of ordinary): >> >> $ wget >>https://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.28.4.tar.bz2 >> $ tar xjvf linux-2.6.28.4.tar.bz2 >> $ cp $M5_PATH/configs/linux-2.6.28.4 linux-2.6.28.4/.config >> $ cd linux-2.6.28.4 >> $ make oldconfig >> $ make -j 32 >> $ make vmlinux -j 32 >> >> My gcc is 4.1.2 >> >> $ gcc --version >> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-54) >> Copyright (C) 2006 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is >>NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>PURPOSE. >> >> If I boot this image using out-of-box kernel, gem5 boots fine (although >>udev fails with version being older than 2.6.26): >> >> $ build/X86/gem5.opt configs/example/fs.py >>--disk-image=debian-amd64.img --kernel=x86_64-vmlinux-2.6.22.9.smp >>--cpu-type=atomic --mem-type=simple_mem >> >> If I instead use custom built 2.6.28.4 kernel, gem5 hangs at the very >>beginning. Nothing happens in the system. >> >> $ build/X86/gem5.opt configs/example/fs.py >>--disk-image=debian-amd64.img --kernel=vmlinux-2.6.28.4 >>--cpu-type=atomic --mem-type=simple_mem >> gem5 Simulator System. http://gem5.org<http://gem5.org/> >> gem5 is copyrighted software; use the --copyright option for details. >> >> gem5 compiled Dec 19 2014 13:56:08 >> gem5 started Dec 19 2014 14:50:06 >> gem5 executing on rndarch17 >> command line: build/X86/gem5.opt configs/example/fs.py >>--disk-image=debian-amd64.img --kernel=vmlinux-2.6.28.4 >>--cpu-type=atomic --mem-type=simple_mem >> Global frequency set at 1000000000000 ticks per second >> info: kernel located at: >>/proj/adg/REV/sim/cdirik/gem5-sims/ya-dist/m5/system/binaries/vmlinux-2.6 >>.28.4 >> Listening for com_1 connection on port 3456 >> 0: rtc: Real-time clock set to Sun Jan 1 00:00:00 2012 >> 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 >> warn: Reading current count from inactive timer. >> **** REAL SIMULATION **** >> info: Entering event queue @ 0. Starting simulation... >> 5951693500: system.pc.com<http://system.pc.com/>_1.terminal: attach >>terminal 0 >> >> $ telnet 127.0.0.1 3456 >> Trying 127.0.0.1... >> Connected to localhost.localdomain (127.0.0.1). >> Escape character is '^]'. >> ==== m5 slave terminal: Terminal 0 ==== >> >> Here are the readelf outputs for two kernels for comparison: >> >> $ readelf -h $M5_PATH/binaries/x86_64-vmlinux-2.6.22.9.smp >> ELF Header: >> Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 >> Class: ELF64 >> Data: 2's complement, little endian >> Version: 1 (current) >> OS/ABI: UNIX - System V >> ABI Version: 0 >> Type: EXEC (Executable file) >> Machine: Advanced Micro Devices X86-64 >> Version: 0x1 >> Entry point address: 0x200000 >> Start of program headers: 64 (bytes into file) >> Start of section headers: 54040168 (bytes into file) >> Flags: 0x0 >> Size of this header: 64 (bytes) >> Size of program headers: 56 (bytes) >> Number of program headers: 5 >> Size of section headers: 64 (bytes) >> Number of section headers: 49 >> Section header string table index: 46 >> >> $ readelf -h $M5_PATH/binaries/vmlinux-2.6.28.4 >> ELF Header: >> Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 >> Class: ELF64 >> Data: 2's complement, little endian >> Version: 1 (current) >> OS/ABI: UNIX - System V >> ABI Version: 0 >> Type: EXEC (Executable file) >> Machine: Advanced Micro Devices X86-64 >> Version: 0x1 >> Entry point address: 0x200 >> Start of program headers: 64 (bytes into file) >> Start of section headers: 5037024 (bytes into file) >> Flags: 0x0 >> Size of this header: 64 (bytes) >> Size of program headers: 56 (bytes) >> Number of program headers: 2 >> Size of section headers: 64 (bytes) >> Number of section headers: 12 >> Section header string table index: 9 >> >> >> -- 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. >> >> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >>Registered in England & Wales, Company No: 2557590 >> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 >>9NJ, Registered in England & Wales, Company No: 2548782 >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >_______________________________________________ >gem5-users mailing list >[email protected] >http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
