Dear Mr Rene De Jong,
Thanks for an elaborate reply. I took a while to see go through the ideas that
you had given before replying here.
You were right about the SSD flash translation layer, it does come between the
disk and disk interface. And so is my implementation. Following your
suggestions I studied the code of IDE_Controller and the Ide_Disk Class in
gem5. That helped alot. The Ide Disk does not pass the information about which
disk was called. Infact since each disk is created using its class in
FS_Config.py so when you write to a certain disk its write() function will
automatically be called which only takes the *data and the offset as
parameters.
Hence I have decided to create a new class for SsdDevices which is a copy of
the RawDiskImage class. I will replace the read and write functionality with my
read_nand() and write_nand() functionality. I guess I am in the right direction.
And yes the IDE_controller supports more than 2 disks. I have already tried
that with a dummy disk.
Thankyou so much. I was able to compile my model with gem5 but it is giving
errors in linking. I guess I should start a new thread for that??
Regards,
Hasan Ijaz
----------------------------------------------------------------------------------------------------------------------------------------
Hi Hassan Ijaz,
I am not completely sure what you are trying to do but I will try to answer
your questions as good as possible;
In the current gem5 version you will probably want to connect your disk to the
IDE interface. This interface supports both the COW and RAW disk
types. You are talking about an FTL layer to simulate an SSD, ideally
this layer is to be put in between the disk and the disk interface,
since that is the place where (in my understanding) in the non-simulated world
the translation will be made from logical addresses to physical
addresses for SSD's. When the software on the simulated system then
addresses the SSD disk behind the IDE interface, the FTL should
automatically be addressed. In this case you don't need to write any new
drivers/software, as long as you make sure that the kernel knows the
right address where it can find the disk. Your software will treat it as a
normal block device.
How such an transaction is detected to be for your device is depended on
the used protocol. What does Gentoo tell you about your disk system?
gem5 models the lowest layers, so if they have different IO addresses,
then you can see if your device is addressed directly, if it is done by
the controller passing on the message to a certain disk, then you will
need to monitor certain fields in the transfer request.
How the kernel discovers the devices depends on the version and
configuration of your kernel. If your kernel supports device trees than
you just have to change the dtb file and your gem5 configuration script. If
your kernel doesn't support that, then you probably have to do some
kernel hacking (most likely in arch/$YOURPLATFORM).
The IDE disk controller should support multiple disks. I am not sure what
the maximum is, but I think that three will still work.
If you want to write a new device, then you probably will need to write
the drivers in Linux as well (unless you will conform to a well known
standard for which drivers are already available in the kernel). In that case
you will need to attach it to a specific bus in gem5 (which I
suspect is going to be the IO bus). Have a look at the devices in
src/dev (e.g. ide_ctrl.hh may be useful) to see how it is done there.
So all things considered, what I think you can do is the following:
- Modify your FTL to go in between the disk (either RAW or COW) and the disk
interface
- Place multiple disks behind the IDE disk interface controller (this should be
a vector of disks)
- Start your Gentoo Linux
I hope I have clarified things for you, it all depends on what you want to do
and where the FTL model is going to be placed.
Regards,
René de Jong
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
