Hi Andreas,
Thanks for the help. I think I figured out the cause of this problem. In
x86 system, e820 table tells the system which physical addresses are
available in the hardware. So I need to define proper entries in e826
dictionary inside FSConfig.py based on the defined memory controller
ranges. If I define three memory controller and configure their ranges in
e820, I get the following error. Please can someone expert in configuring
e820 table guide me how to fix this mapping issue? Thanks
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000010000000 (usable)
BIOS-e820: 0000000280000000 - 00000002c0000000 (usable)
BIOS-e820: 0000003100000000 - 0000003140000000 (usable)
end_pfn_map = 51642368
kernel direct mapping tables up to 3140000000 @ 100000-1c6000
DMI 2.5 present.
Zone PFN ranges:
DMA 0 -> 4096
DMA32 4096 -> 1048576
Normal 1048576 -> 51642368
early_node_map[4] active PFN ranges
0: 0 -> 159
0: 256 -> 65536
0: 2621440 -> 2883584
0: 51380224 -> 51642368
bootmem alloc of 2891972608 bytes failed!
Kernel panic - not syncing: Out of memory
PANIC: early exception rip ffffffff80215ca0 error 0 cr2 ffffffffff5fd030
Best Regards, Hassan
On 2 December 2013 17:37, Andreas Hansson <[email protected]> wrote:
> Hi Hassan,
>
> Someone skilled in the assumptions of x86 memory layout may be able to
> help you. I doubt there is an easy fix, but I could be wrong.
>
> For ARM it should not be a problem to have this “segmented” memory.
> Currently the gem5 ARM Linux System assumes a single range presented to the
> OS, but this could easily be fixed (see LinuxArmSystem::initState). If you
> take the plunge and go this route please share the patch on RB.
>
> Thanks,
>
> Andreas
>
> From: Ahmad Hassan <[email protected]>
> Reply-To: gem5 users mailing list <[email protected]>
> Date: Monday, 2 December 2013 16:18
>
> To: gem5 users mailing list <[email protected]>
> Subject: Re: [gem5-users] Running two SimpleDram instances simulataniously
>
> Hi Andreas,
>
> Please may I ask if you are experiencing the similar errors if you
> define a second main memory controller beyond IO physical address ranges?
> Would this be happening or this is completely an undesired behavior?
>
> If Linux always need contiguous physical address range for multiple
> memory controllers then is it possible to move IO address range from 3GB
> start address to something 128GB starting address and then define two main
> memory controllers that share the physical address range of 0GB to 128GB to
> have 128 GB RAM capacity please?
>
> In another attempt, I tried to move the first main memory controller
> starting from 0GB to 10GB but it doesn't work because linux is accessing
> memory between 0 to 128MB address range.
>
> Thanks again for your help.
>
> Best Regards, Hassan
>
>
>
>
> On 28 November 2013 15:55, Ahmad Hassan <[email protected]> wrote:
>
>> Hi Andreas,
>>
>> To make sure it is not caused by my local changes, I just cloned the
>> fresh revison 9644:07352f119e48 and defined two memory controllers as:
>>
>> self.physmem = SimpleDDR3(range = AddrRange(start="0GB",
>> size="2GB"))
>> self.physmem2 = SimpleDDR3(range = AddrRange(start="50GB",size="1GB"))
>> self.mem_ranges = [self.physmem.range,self.physmem2.range]
>>
>> Again, I see the same error where linux boot-up fails while accessing
>> physical address: 3217031168. It seems that guest OS assumes that All 3GB
>> space is contiguous.
>>
>> I don't know why it worked last week.
>>
>> Thanks for the help.
>>
>> Best Regards, Hassan
>>
>>
>>
>>
>> On 28 November 2013 14:50, Ahmad Hassan <[email protected]> wrote:
>>
>>> Hi Andreas,
>>>
>>> I assume so. I get this 'segmentation fault' while booting
>>> linux: ./build/X86/gem5.opt configs/example/fs.py
>>> --kernel=x86_64-vmlinux-2.6.22.9.smp
>>>
>>> But I think, I booted the linux last week with similar configuration
>>> and I think it worked fine. It seems bit strange to me that I am seeing
>>> this segmentation fault now.
>>>
>>> Best Regards, Hassan
>>>
>>>
>>> On 28 November 2013 13:53, Andreas Hansson <[email protected]>wrote:
>>>
>>>> Hi Hassan,
>>>>
>>>> What is it that is assuming that the memory is contiguous? The guest
>>>> OS?
>>>>
>>>> Andreas
>>>>
>>>> From: Ahmad Hassan <[email protected]>
>>>> Reply-To: gem5 users mailing list <[email protected]>
>>>> Date: Thursday, 28 November 2013 06:43
>>>>
>>>> To: gem5 users mailing list <[email protected]>
>>>> Subject: Re: [gem5-users] Running two SimpleDram instances
>>>> simulataniously
>>>>
>>>> Hi Andreas,
>>>>
>>>> I have defined two memory controllers:
>>>>
>>>> self.dram2_ctl = SimpleDDR3(range =
>>>> AddrRange(start='0MB',size='3GB'))
>>>> self.dram1_ctl = SimpleDDR3(range =
>>>> AddrRange(start='10GB',size='16GB'))
>>>>
>>>> But I am getting exception in findPort method where it raises because
>>>> it tries to access physical address 6438256672 for membus
>>>>
>>>> DPRINTF(BusAddrRanges, "Unable to find destination for addr %#llx, "
>>>> "will use default port\n", addr);
>>>>
>>>> As a result of that, I get segmentation fault during memcpy operation
>>>> in abstract_mem.cc:access
>>>> This error is happening because system is assuming that all the 19GB of
>>>> physical memory is contiguous. Please can you advise me how to fix this.
>>>> Thanks.
>>>>
>>>> Best Regards, Hassan
>>>>
>>>>
>>>>
>>>>
>>>> On 31 October 2013 18:00, Andreas Hansson <[email protected]>wrote:
>>>>
>>>>> Hi Ahmad,
>>>>>
>>>>> If you change the bus code then every bus in the system will do
>>>>> this, including the I/O bus. I suspect this is the reason for your error.
>>>>> You can keep on the hackish path and add a name check to only do this for
>>>>> the membus (or add a parameter to the bus and change the MemBus instance),
>>>>> or preferably get of the hackish path and rely on physical addresses and
>>>>> sort out your “placement” by assigning the appropriate physical addresses
>>>>> in your TLBs (or preferably in the OS).
>>>>>
>>>>> Red pill or blue pill.
>>>>>
>>>>> Andreas
>>>>>
>>>>> From: Ahmad Hassan <[email protected]>
>>>>> Reply-To: gem5 users mailing list <[email protected]>
>>>>> Date: Thursday, 31 October 2013 16:51
>>>>>
>>>>> To: gem5 users mailing list <[email protected]>
>>>>> Subject: Re: [gem5-users] Running two SimpleDram instances
>>>>> simulataniously
>>>>>
>>>>> Hi Andreas,
>>>>>
>>>>> In my system:
>>>>> DDR3 memory controller: Port ID 0 //2GB capacity
>>>>> DDR2 memory controller: Port ID 1 //1GB capacity
>>>>>
>>>>> So I want to do the following:
>>>>>
>>>>> When the packet comes into bus.cc:findPort then it searches for
>>>>> packet's physical address in the registered portMap of address ranges and
>>>>> returns the appropriate port ID. I don't want to do this. Instead, I want
>>>>> to select port based on the virtual address. I have list of virtual
>>>>> addresses say V=[V1....Vn] and I want to redirect all the packets with
>>>>> virtual address within set 'V' to DDR3 Port 0 and all other memory packets
>>>>> to the DDR2 port 1.
>>>>>
>>>>> In order to achieve this, I changed bus.cc:findPort as:
>>>>>
>>>>> if (search(V, pkt->req->getVaddr()) == true)
>>>>> dest_id = 0;
>>>>> else
>>>>> dest_id = 1;
>>>>>
>>>>> After that, abstract_mem.cc:access complained that the packet
>>>>> address doesn't belong to the range of PORT '1'. Just as a quick hack, I
>>>>> changed it as:
>>>>>
>>>>> old: uint8_t *hostAddr = pmemAddr + pkt->getAddr() - range.start();
>>>>> new: uint8_t *hostAddr = pmemAddr + pkt->getAddr() - 0; // Port ID 0
>>>>> range starts with '0'
>>>>>
>>>>> Now the linux starts booting but during the half way, it throws this
>>>>> cmos assertion. Please can you suggest the clean or right way of
>>>>> implementing what I am trying to achieve.
>>>>>
>>>>> Thanks a lot
>>>>>
>>>>> kind Regards, Ahmad
>>>>>
>>>>>
>>>>> On 31 October 2013 16:25, Andreas Hansson <[email protected]>wrote:
>>>>>
>>>>>> Hi Ahmad,
>>>>>>
>>>>>> I could be wrong, but judging by your mail, I get the impression
>>>>>> that you’re overriding the address decoding. That is essentially saying
>>>>>> “If
>>>>>> I send requests for address X to address Y, why do things not work?”. I
>>>>>> would be very surprised if it did, as two addresses will now map to the
>>>>>> same location :-). Perhaps I’m not understanding what you’ve changed.
>>>>>>
>>>>>> Andreas
>>>>>>
>>>>>> From: Ahmad Hassan <[email protected]>
>>>>>> Reply-To: gem5 users mailing list <[email protected]>
>>>>>> Date: Thursday, 31 October 2013 16:12
>>>>>>
>>>>>> To: gem5 users mailing list <[email protected]>
>>>>>> Subject: Re: [gem5-users] Running two SimpleDram instances
>>>>>> simulataniously
>>>>>>
>>>>>> HI Andreas,
>>>>>>
>>>>>> I have connected two memory controllers and I can see the following
>>>>>> two port IDs and their physical address ranges:
>>>>>>
>>>>>> Adding range [0 : 2147483647] for id 0 system.membus // 2GB
>>>>>> memory
>>>>>> Adding range [2147483648 : 3221225471] for id 1 system.membus
>>>>>> //1GB memroy
>>>>>>
>>>>>> Inside findPort method of bus.cc, if I assign the packet of port id
>>>>>> '0' to port id '1' then I get the following assertion error. This happens
>>>>>> in half way through the linux boot up:
>>>>>>
>>>>>> gem5.opt: build/X86/dev/x86/cmos.cc:70: virtual Tick
>>>>>> X86ISA::Cmos::write(PacketPtr): Assertion `pkt->getSize() == 1' failed.
>>>>>>
>>>>>> Please do you know what is causing that? Also I had to disable
>>>>>> assertion in abstract memory which validates that the packet's physical
>>>>>> address in with in the range of memory controller.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> kind Regards, Ahmad
>>>>>>
>>>>>> -- 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
>>>>>>
>>>>>
>>>>>
>>>>> -- 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
>>>>>
>>>>
>>>>
>>>> -- 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
>>>>
>>>
>>>
>>
>
> -- 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
