Review Board 2.0.15


ARM: Add support for a dumb IDE controller

Review Request #292 - Created Nov. 8, 2010 and submitted

Information
Ali Saidi
gem5
Reviewers
Default
ARM: Add support for a dumb IDE controller

   
Posted (Nov. 8, 2010, 9:56 a.m.)



  
src/dev/ide_ctrl.cc (Diff revision 1)
 
 
Is this something that we should deal with on a per device basis, or is this a more generic thing?  Also, is this something that should be configured by the user, or is this something that's either fixed or gleaned from the OS?
  1. It seems rather arbitrary, but the world of function pointers that sets this value in the OS is pretty deep. I think having the user configure it is fine, there isn't a really good way we could grab it from the OS since there isn't once place where there is a device struct that describes a ide controller. These values only seem to apply to the IDE device. 
  2. I'm also really curious what's going on with these values. We should probably figure out what they're for before we go hacking them in. Also, please make sure an X86 kernel still boots with this change. I remember getting the IDE controller to work was a little finicky at least partially because of its legacy fixed IO port locations, and it might break even though other ISAs are ok.
Ship it!
Posted (Nov. 8, 2010, 10:55 p.m.)



  
Posted (Nov. 9, 2010, 4:59 a.m.)



  
src/dev/ide_ctrl.cc (Diff revision 1)
 
 
They're passed in by the code that asks the kernel to probe for an ide device being there. 1 is just a hardcoded constant in the arm code that's calling it, no magic. If the values default to 0, as they do, there wont' be any difference in the normal code path. 

Since I'm sure you have a working environment to run linux/x86 if you could toss in this patch and run it to verify that would be great. 
Posted (Nov. 9, 2010, 5 a.m.)



  
Posted (Nov. 9, 2010, 5 a.m.)



  
Posted (Nov. 9, 2010, 5 a.m.)



  
src/dev/ide_ctrl.cc (Diff revision 1)
 
 
They're passed in by the code that asks the kernel to probe for an ide device being there. 1 is just a hardcoded constant in the arm code that's calling it, no magic. If the values default to 0, as they do, there wont' be any difference in the normal code path. 

Since I'm sure you have a working environment to run linux/x86 if you could toss in this patch and run it to verify that would be great.