Age | Commit message (Collapse) | Author | Files | Lines |
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6000 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
This patch adds support for 64-bit Block Move instructions. There are multiple
modes for 64-bit Block moves, direct, indirect, and table indirect. This patch
implements Direct and Table indirect moves which are needed by 64-bit windows
and SYM_CONF_DMA_ADDRESSING_MODE=2 for the Linux sym53c8xx_2 driver respectively.
Two helper functions are included to check which mode the guest is using. For
64-bit direct moves, we fetch a 3rd DWORD and store the value in the DBMS
register. For Table Indirect moves, we look into the table for which register
contains the upper 32-bits of the 64-bit address. This selector value indicates
which register to pull the value from and into dnad64 register.
Finally, lsi_do_dma is updated to use the approriate register to build a 64-bit
DMA address if required.
With this patch, Windows XP x64, 2003 SP2 x64, can now install to scsi devices.
Linux SYM_CONF_DMA_ADDRESSING_MODE=2 need a quirk fixup in Patch 4 to function
properly.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5969 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
Register name should be: Dynamic Block Move Selector (dbms) according to page
215 of the LSI 53C895A Technical Manual[1].
1. http://www.lsi.com/DistributionSystem/AssetDocument/files/docs/techdocs/storage_stand_prod/SCSIControllers/lsi53c895a_tech_manual.pdf
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5968 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
Basically after each DMA transfer the Openserver driver would issue an
empty (0) SCRIPTS opcode. As the opcode is essentially a NOP it has no
second DWORD and therefore the DSP should only be incremented by 4 bytes
instead of the 8 bytes we currently do.
Here's a snippet of the log:
lsi_scsi: Data ready tag=0x100d9 len=16384
...
lsi_scsi: SCRIPTS dsp=068c5e50 opcode 01000400 arg 07a09000
lsi_scsi: DMA addr=0x07a09000 len=1024
lsi_scsi: SCRIPTS dsp=068c5e58 opcode 00000000 arg 01000400
lsi_scsi: Wrong phase got 1 expected 0
Note the 2nd DWORD after the empty opcode; the next opcode in the DMA
transfer sequence. As can be expected the address after that has the next
DMA address to use.
After the attached patch the DMA transfer is able to complete successfully:
lsi_scsi: SCRIPTS dsp=068c5e50 opcode 01000400 arg 07a0d000
lsi_scsi: DMA addr=0x07a0d000 len=1024
lsi_scsi: SCRIPTS dsp=068c5e5c opcode 01000400 arg 07a0d400
lsi_scsi: DMA addr=0x07a0d400 len=1024
...
Tested againsted Openserver 5.0.5 and Debian ARM.
Signed-off-by: Justin Chevrier <address@hidden>
Acked-by: Ryan Harper <ryanh@us.ibm.com>
Signed-off-by: Andrzej Zaborowski <andrew.zaborowski@intel.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5902 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
Signed-off-by: Justin Chevrier <address@hidden>
Acked-by: Ryan Harper <ryanh@us.ibm.com>
Acked-by: Chris Wright <chrisw@sous-sol.org>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5901 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
TARGET_FMT_plx includes a % for you. This fixes the following warning when
compiling with LSI_DEBUG enabled.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5760 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
This patch fixes Linux machines configured with > 4G of ram and using a
SCSI device.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5750 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
After going through the debug log and scratching my head for quite some
time. I found the following:
The problem was with this block move:
lsi_scsi: SCRIPTS dsp=0fae8e50 opcode 01000028 arg 00f63c40
lsi_scsi: DMA addr=0x00f63c40 len=36
The number of bytes to be transferred (len) should be 40 which corresponds
to the block transfer of length 0x28 (from opcode 01000028). Instead we
have a length of 36 (0x24). The code responsible for this is (in
'lsi_do_dma'):
if (count > s->current_dma_len)
count = s->current_dma_len;
Basically we're overwriting the length 40 with the value 36 which I
think we just left over in that variable from an earlier transfer. In my
patch below I initialize s->current_dma_len to s->dbc before we begin
the DMA transfer during Data In phase.
The attached patch gets Openserver 5.0.5 past the hardware detection
(and it lists the hard drive to boot, woohoo). It appears to stop a
little while later (doesn't seem SCSI related), but it's been so long since
I've booted Openserver I'm not sure what's supposted to happen after the HW
detection using the boot/root disks.
Props go to Craig Ringer for the initial post and the code that he posted
some of which is in this patch.
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5706 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5295 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
Raise UDC (Unexpected Disconnect) when a large enough number of
instructions has been executed by the SCRIPTS processor. This "solution"
is much simpler than temporarily interrupting execution.
This remedies the situation with Windows which downloads SCRIPTS code
that busy loops on guest main memory. Their drivers _do_ handle UDC
appropriately (at least XP and 2003).
It would be nicer to actually detect infinite loops, but until then,
this bandaid seems acceptable.
Since the situation seems to be rare enough, raise the number
of instructions to 10000 (previously 1000).
Three people other than myself had success with this patch.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5293 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@4986 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@3851 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@3797 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@3759 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@3674 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@3173 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@2735 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@2713 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@2699 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@2635 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@2580 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@2504 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@2139 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@2107 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@1946 c046a42c-6fe2-441c-8c8c-71466251a162
|