Hi again,
I found the issue.
When we add arguments to the kernel, the default arguments that are
required for the FS to work properly are erased from the kernel_command!
The default kernel_command is "earlyprintk=ttyS0 console=ttyS0
lpj=7999923 root=/dev/hda". But if kernel_args != [] in
set_kernel_disk_workload, the only arguments added are the ones
specified in that list!
Is this a feature or a bug? I was expecting the optional kernel
arguments to be ADDED to the default arguments, and not replace them...
Kind regards,
Joao Vieira
On 24/01/23 12:10, João Vieira via gem5-users wrote:
Hi,
I am trying to limit the memory used by Linux so that I am left with
some physically addressable memory to use with accelerators in FS mode.
In physical systems, to do this, it suffices to boot the kernel with
the argument "mem=MAX_MEM", where MAX_MEM represents the maximum
memory that Linux can access and also the corresponding upper address.
However, when I add that kernel argument, the system just does not
boot (I get no output in the m5 terminal). If I remove that argument,
everything works fine. I am using the gem5 standard library and my
code is as follows:
========================================================================
requires(
isa_required=ISA.X86,
coherence_protocol_required=CoherenceProtocol.MESI_TWO_LEVEL,
)
memory = SingleChannelDDR3_1600(size="3GB")
processor = SimpleProcessor(cpu_type=CPUTypes.TIMING, num_cores=1)
cache_hierarchy = MESITwoLevelCacheHierarchy(
l1d_size="32kB",
l1d_assoc=8,
l1i_size="32kB",
l1i_assoc=8,
l2_size="1MB",
l2_assoc=16,
num_l2_banks=1,
)
board = X86Board(
clk_freq="3GHz",
processor=processor,
memory=memory,
cache_hierarchy=cache_hierarchy,
)
board.set_kernel_disk_workload(
kernel=CustomResource("fs_x86/binaries/vmlinux"),
kernel_args=["mem=2G"],
disk_image=CustomDiskImageResource("fs_x86/disks/gem5_base.img"),
)
simulator = Simulator(board=board)
simulator.run()
========================================================================
Does anyone have a clue of what the problem is or is there any other
logs that I can look at to understand where the boot process halts?
Thanks in advance!
Kind regards,
Joao Vieira
--
Joao Vieira
ECE PhD Student at Tecnico Lisboa | INESC-ID, Portugal
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
