Hi Gabe,
Thanks. Do you mean that X86 is working for SimpleCPU(both atomic &
timing) model for syscall emulation mode, but not for full simulation
O3CPU model?
The other issue is, I am trying to build the X86 disk-image for FS
run. In order to compile the linux kernel for X86, I got the configs
from your earlier posts. The steps I followed in order to make the x86
disk image using PtxDIST:-
(1) clone the linux-dist/projects-example/generic-i586-glibc project
in a particular workspace & select this ptxconfig
(2) select a possible h/w platform to build for. I selected the
platform-i586. This platformconfig lets me set up all target specific
settings.Major parts are:
• Toolchain (architecture and revision)
• boot loader
• root filesystem image type
• Linux kernel
(3) select the toolchain to be used to build everything for the target
/opt/OSELAS.Toolchain-1.99.3/i586-unknown-linux-gnu/gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/bin/
then PtxDist go command builds everything & PtxDist image command make
the final disk-image.
BUT, the disk image it made for me is of size 150 MB only. It should
be about 2GB. I guess definitely the image has not been built
properly. I am getting following error messages using that built x86 disk image.
command-line:-build/X86_FS/m5.opt configs/example/fs.py
--kernel=/dist/m5/system/binaries/vmlinux
Global frequency set at 1000000000000 ticks per second
info: kernel located at: /dist/m5/system/binaries/vmlinux
0: rtc: Real-time clock set to Sun Jan 1 00:00:00 2012
Listening for pc connection on port 3456
warn: Reading current count from inactive timer.
For more information see: http://www.m5sim.org/warn/1ea2be46
0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
**** REAL SIMULATION ****
info: Entering event queue @ 0. Starting simulation...
panic: Segment not present.
@ cycle 10000
[execute:build/X86_FS/arch/x86/atomic_simple_cpu_exec.cc, line 8476]
Memory Usage: 262956 KBytes
For more information see: http://www.m5sim.org/panic/bc153f92
Program aborted at cycle 10000
Aborted
Now I am trying with BusyBox, instead of PtxDIST. Is there any other
way that you can suggest me for building the image?please let me know.
Thanks and Regards,
Dibakar
On Mon, Sep 20, 2010 at 12:29 PM, Gabe Black <[email protected]> wrote:
> Sorry, I misspoke. It should be working for both of the simple CPUs
> right now, but no other models.
>
> Gabe
>
> Dibakar Gope wrote:
>> Hi Gabe,
>>
>> Thanks for your reply. So in order to make the predecode logic work for
>> timing simple CPU-model, which source code tree I should look for other than
>> fetch-decode code tree (src/cpu/o3)and build/X86_FS/arch/x86 code tree? And
>> how this predecode logic behaves differently for atomic & timing cpu mode?
>> Please let me know.
>>
>> Regards,
>> Dibakar
>>
>>
>>
>> Hello. The x86 predecode logic is working on the atomic CPUs but no
>> other CPU model right now. I've started to get it to work, but I'm going
>> to have to set that aside for a while.
>>
>> Gabe
>>
>> dibakar gope wrote:
>> > Hi All,
>> >
>> > I have few queries regarding the fetch & predecode logic
>> > implementation for variable-length x86 instruction in M5.
>> >
>> > (1) The next few lines of code has been taken from
>> > src/cpu/o3/fetch_impl.hh to illustrate the way fetch logic extracts
>> > MachInst (8 bytes)from the cacheline and send it to the predecoder for
>> > building a complete x86 instruction in terms of ExtMachInst object.
>> >
>> > src/cpu/o3/fetch_impl.hh:-
>> > line 1120:- // Get the instruction from the array of the cache line.
>> > inst = TheISA::gtoh(*reinterpret_cast<TheISA::MachInst *>
>> > (&cacheData[tid][offset]));
>> >
>> > predecoder.setTC(cpu->thread[tid]->getTC());
>> > predecoder.moreBytes(fetch_PC, fetch_PC, inst); //
>> > here inst is an instantiation of fixed-length MachInst (8 bytes)
>> >
>> > ext_inst = predecoder.getExtMachInst();
>> > staticInst = StaticInstPtr(ext_inst, fetch_PC);
>> > if (staticInst->isMacroop())
>> > line 1130:- macroop = staticInst;
>> >
>> > fetch_PC is the start of the cacheline.
>> > predecoder.moreBytes function (src/arch/x86/predecoder.hh) gets 8
>> > bytes of MachInst data, process it & Populates the fields in
>> > ExtMachInst object.
>> > predecoder.getExtMachInst (src/arch/x86/predecoder.hh) checks whether
>> > the ExtMachInst have got all the bytes for an particular x86
>> > instruction, otherwise this function will assert an error message.
>> >
>> > src/arch/x86/predecoder.hh:-
>> > const ExtMachInst & getExtMachInst()
>> > {
>> > assert(emiIsReady);
>> > emiIsReady = false;
>> > return emi;
>> > }
>> >
>> > So everytime an x86 instruction exceeds the given MachInst (8 bytes) &
>> > extends to the next 8 bytes, then in that iteration, the
>> > predecoder.getExtMachInst will always assert this error message &
>> > return an incomplete ExtMachInst back to calling fetch logic, but
>> > ideally it should not. So have anyone thought about that or is there
>> > anything missing in populating the ExtMachInst object?
>> >
>> > (2) predecoder.moreBytes function in above line of code shown is
>> > invoked with (fetch_PC, fetch_PC, inst) arguments, which will make the
>> > local variable "offset" zero in the code shown below.
>> > src/arch/x86/predecoder.hh:-
>> >
>> > line 189:- //Use this to give data to the predecoder. This should be
>> > used
>> > //when there is control flow.
>> > void moreBytes(Addr pc, Addr fetchPC, MachInst data)
>> > {
>> > DPRINTF(Predecoder, "Getting more bytes.\n");
>> > basePC = fetchPC;
>> > offset = (fetchPC >= pc) ? 0 : pc - fetchPC;
>> > fetchChunk = data;
>> > outOfBytes = false;
>> > process();
>> > line 199:- }
>> >
>> >
>> > This above local variable "offset" decides the starting byte in the
>> > given MachInst (8 bytes) from where the predecoder logic start
>> > considering a new x86 instruction. But since this above function in
>> > invoked with (fetch_PC, fetch_PC, inst) arguments, so everytime the
>> > offset variable will get a value of 0 irrespective of any correct
>> > starting byte of an instruction. And in turn the predecoder logic will
>> > consider a wrong byte as the start byte of an x86 instruction.
>> >
>> > So in short, has the logic for fetching an x86 variable length
>> > instruction (using the fetch, predecode & its interface logic)
>> > implemented entirely / or the implementation is still in progress? is
>> > the x86 fetch-predecode logic up & running and completely verified or
>> > something is still missing & need some fixes?
>> >
>> > Any kind of help will be highly appreciated.
>> >
>> > Thanks & Regards,
>> > Dibakar Gope
>> > Texas A&M university
>> > _______________________________________________
>> > m5-users mailing list
>> > [email protected]
>> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >
>>
>> _______________________________________________
>> m5-users mailing list
>> [email protected]
>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>
>>
>>
>
>
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
