summaryrefslogtreecommitdiff
path: root/vnc.c
diff options
context:
space:
mode:
authorbalrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>2008-11-12 16:41:32 +0000
committerbalrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>2008-11-12 16:41:32 +0000
commit9167a69a816b8956d62da628b5b4dc87674647d6 (patch)
tree2b8cc4d96b15e23f4da15a1e9ff404aaa5af0f38 /vnc.c
parentc3b972c30d9052df7eb535a14b4e2c8c6bb12743 (diff)
downloadqemu-9167a69a816b8956d62da628b5b4dc87674647d6.tar.gz
qemu-9167a69a816b8956d62da628b5b4dc87674647d6.tar.bz2
qemu-9167a69a816b8956d62da628b5b4dc87674647d6.zip
Implement LSI53C895A quirks exposed by OpenServer (Justin Chevrier).
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
Diffstat (limited to 'vnc.c')
0 files changed, 0 insertions, 0 deletions