On 15/05/14 18:28, BALATON Zoltan wrote:
If you place a breakpoint on pmac_ide_transfer() then its invocation
of pmac_ide_atapi_transfer_cb() should be the first iteration which
sets up the DMA request, and the second invocation should be the
(failing) callback from the dma_bdrv_*() functions. But as I mentioned
before, I think the problem is that these functions shouldn't be
called in the first place when requesting a TOC.
OK, I've done that and stopped at the first invocation of
pmac_ide_atapi_transfer_cb. Here is a backtrace and the contents of some
data structures:
#0 pmac_ide_atapi_transfer_cb (opaque=0x5555563ccc68, ret=0)
at hw/ide/macio.c:55
#1 0x00005555556da6d0 in pmac_ide_transfer (io=0x5555563ccc68)
at hw/ide/macio.c:225
#2 0x00005555556eeee2 in start_input (ch=0x5555563ccc18, key=0, addr=
14777932, req_count=804, is_last=1) at hw/misc/macio/mac_dbdma.c:334
#3 0x00005555556ef444 in channel_run (ch=0x5555563ccc18)
at hw/misc/macio/mac_dbdma.c:489
#4 0x00005555556ef599 in DBDMA_run (s=0x5555563cba40)
at hw/misc/macio/mac_dbdma.c:531
#5 0x00005555556ef5f4 in DBDMA_run_bh (opaque=0x5555563cba40)
at hw/misc/macio/mac_dbdma.c:542
#6 0x00005555555f8200 in aio_bh_poll (ctx=0x55555637fc00) at async.c:81
#7 0x00005555555f7e59 in aio_poll (ctx=0x55555637fc00, blocking=false)
at aio-posix.c:188
#8 0x00005555555f8617 in aio_ctx_dispatch (source=0x55555637fc00,
callback=
0x0, user_data=0x0) at async.c:205
#9 0x00007ffff78ca6d5 in g_main_context_dispatch ()
from /lib64/libglib-2.0.so.0
#10 0x00005555557a0fde in glib_pollfds_poll () at main-loop.c:190
#11 0x00005555557a10de in os_host_main_loop_wait (timeout=15883632)
at main-loop.c:235
#12 0x00005555557a11b1 in main_loop_wait (nonblocking=0) at main-loop.c:484
#13 0x000055555584422c in main_loop () at vl.c:2075
#14 0x000055555584bcbf in main (argc=32, argv=0x7fffffffdc48, envp=
0x7fffffffdd50) at vl.c:4556
(lots cut)
So that looks like the correct request based upon it's size so what
happened when you stepped into pmac_ide_atapi_transfer_cb()...?
My testing was done with commit 80fc95d8bdaf3392106b131a97ca701fd374489a
already reverted as that was established before that it is not needed
any more which simplifies pmac_ide_atapi_transfer_cb() quite a bit
Sadly I've now found that this isn't the case (email to the qemu-devel
list to follow, but I've run out of time today) :(
but I
still can't understand the flow of this function and don't see where
should I add a condition to handle this lba=-1 case that happens with
READ_TOC using DMA. The reason I don't understand it is that the
different fields (sizes and indexes) in these structures that are used
in this callback don't make sense to me and I don't know how to use
cpu_physical_memory_write() to copy data from the ide buffer to the
guest memory as was suggested by Mark. Now that the problem is fairly
well understood, wouldn't it be easier to one of you who understands
what's happening to create a patch, instead of trying to explain all
this to me?
Well my understanding is that it's impossible to boot a MorphOS image
directly and requires all sorts of tricks with debuggers etc. Unless you
can provide a "run this and it breaks" test case, then the time barrier
for trying to fix bugs like this is exceptionally high.
You mention that you don't understand the fields and sizes, so explain
which ones you don't understand and ask. Search around for guides to how
ATAPI/IDE works, and compare with gdb output to find the correlation
with the IDEState variables. Have you tried looking at the header file
for cpu_physical_memory_write()? Even to someone who had never seen this
function before Alex's patches, it seems fairly obvious how the API
should work.
I'm afraid that there really is no alternative to spending the time
getting stuck into the code, experimenting, adding printf()'s in
exciting places, and then asking specific questions to the mailing list.
This part was last touched by Alexander Graf so I assume he knows how it
works and it would not be too hard for him to fix it. I'm happy to help
testing and providing more debugging info as needed but I'm not sure I
want to detangle it and figure out the whole block layer and DBDMA
without any documentation to be able to fix it myself. Would it be
possible to find some time for it in the foreseeable future? (That might
still be sooner than me wrapping my head around it.)
Please see above. FWIW based upon the your gdb output I've put together
the following patch which compiles, but that's all I can vouch for it.
Further testing and debugging will have to be done by you, although I
will try and respond to specific questions where possible.
ATB,
Mark.
diff --git a/hw/ide/macio.c b/hw/ide/macio.c
index da94580..96c2556 100644
--- a/hw/ide/macio.c
+++ b/hw/ide/macio.c
@@ -111,6 +111,14 @@ static void pmac_ide_atapi_transfer_cb(void *opaque, int ret)
return;
}
+ if (s->packet_transfer_size && s->lba == -1) {
+ MACIO_DPRINTF("non-IO ATAPI DMA transfer size: %d\n", io->len);
+ /* Copy ATAPI buffer directly to RAM and finish */
+ cpu_physical_memory_write(io->addr, s->io_buffer, io->len);
+ s->packet_transfer_size -= io->len;
+ MACIO_DPRINTF("end of non-IO ATAPI DMA transfer\n");
+ }
+
if (!s->packet_transfer_size) {
MACIO_DPRINTF("end of transfer\n");
ide_atapi_cmd_ok(s);
