72a455f9c9
This command is one of two that should be implemented by ATAPI devices. An ATAPI device are essentially optical devices which use SCSI commands which are transported over ATA using two special commands, a PACKET command which actually sends the SCSI commands, and an IDENTIFY command which is basically the same as the ATA IDENTIFY command but which is only implemented on ATAPI devices. In order to determine if the device connected to an IDE controller is an optical drive or a regular ATA hard drive, software can send the ATAPI_IDENTIFY_DEVICE command and see if gets an appropriate response. In gem5, this command was originally not implemented by the IDE disk model. If a driver attempted to send it, the gem5 model would panic and kill the simulation. To fix that problem, that command was added to the list of supported commands and just made a synonym for the ATA IDENTIFY command since they have essentially the same response. Unfortunately, this makes all ATA devices look like ATAPI devices, which is not what we have implemented. Instead, when we get this command, what we *should* do, as far as I can tell by reading this: http://users.utcluj.ro/~baruch/media/siee/labor/ATA-Interface.pdf is to set the ERR bit in the status register, and then set the ABRT bit in the error register to indicate that the command was not implemented. I've attempted to implement that into the model with this change by setting those bits as described, and then setting the "action" member to be ACT_CMD_ERROR. I think that action is there primarily to support cancelled transfers, but it seems like it has the desired effect(?). Since the error bits are not really explicitly set or managed by the model in most cases, this change also adds a little bit of code at the top of startCommand which clears them to zero. These bits are supposed to "contain the status of the last command executed", and if we're starting a new command, the error bits no longer apply. I'm confident that conceptually this is how the ATAPI_IDENTIFY_DEVICE command should behave in our model, at least unless we decide to implement real ATAPI models which actually accept SCSI commands, etc. I'm less confident that I've modified the model to actually implement that behavior, but as far as I can tell it doesn't seem to have broken anything, and now SeaBIOS no longer things our disk model is a CDROM drive. Change-Id: I2c0840e279e9caa89c21a4e7cbdbcaf6bccd92ac Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55523 Maintainer: Gabe Black <gabe.black@gmail.com> Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Gabe Black <gabe.black@gmail.com>
This is the gem5 simulator. The main website can be found at http://www.gem5.org A good starting point is http://www.gem5.org/about, and for more information about building the simulator and getting started please see http://www.gem5.org/documentation and http://www.gem5.org/documentation/learning_gem5/introduction. To build gem5, you will need the following software: g++ or clang, Python (gem5 links in the Python interpreter), SCons, zlib, m4, and lastly protobuf if you want trace capture and playback support. Please see http://www.gem5.org/documentation/general_docs/building for more details concerning the minimum versions of these tools. Once you have all dependencies resolved, type 'scons build/<CONFIG>/gem5.opt' where CONFIG is one of the options in build_opts like ARM, NULL, MIPS, POWER, SPARC, X86, Garnet_standalone, etc. This will build an optimized version of the gem5 binary (gem5.opt) with the the specified configuration. See http://www.gem5.org/documentation/general_docs/building for more details and options. The main source tree includes these subdirectories: - build_opts: pre-made default configurations for gem5 - build_tools: tools used internally by gem5's build process. - configs: example simulation configuration scripts - ext: less-common external packages needed to build gem5 - include: include files for use in other programs - site_scons: modular components of the build system - src: source code of the gem5 simulator - system: source for some optional system software for simulated systems - tests: regression tests - util: useful utility programs and files To run full-system simulations, you may need compiled system firmware, kernel binaries and one or more disk images, depending on gem5's configuration and what type of workload you're trying to run. Many of those resources can be downloaded from http://resources.gem5.org, and/or from the git repository here: https://gem5.googlesource.com/public/gem5-resources/ If you have questions, please send mail to gem5-users@gem5.org Enjoy using gem5 and please share your modifications and extensions.