On Fri, 20 Jun 2014, Mark Cave-Ayland wrote:
On 04/06/14 13:44, Alexander Graf wrote:
From: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Currently the macio DMA routines assume that all DMA requests are for
read/write
block transfers. This is not always the case for ATAPI, for example when
requesting a TOC where the response is generated directly in the IDE
buffer.
Detect these non-block ATAPI DMA transfers (where no lba is specified in
the
command) and copy the results directly into RAM as indicated by the DBDMA
descriptor. This fixes CDROM access under MorphOS.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Signed-off-by: Alexander Graf <ag...@suse.de>
I've just done a complete round of OpenBIOS tests and it looks as if this
patch introduces random hang failures (60% or so) into my Darwin image boot
tests.
The issue seems to be related as to the timing of the DMA callback relative
to reception of the IDE command; if the IDE transfer is invoked first (as
happens in Darwin) then we hang after sending the IDE command which is likely
because the DMA is not being completed correctly. There is also another
difference with MorphOS in that when the IDE transfer callback is invoked
first then s->packet_transfer_size == 0 and so the memory copy would always
copy 0 bytes.
After some experimentation, I've come up with the attached patch which should
retain the DMA memory copy, but instead invokes a further round of
pmac_ide_atapi_transfer_cb() with io->len == 0 and s->io_buffer_size == 0
which should terminate the DMA request correctly. At the very least it seems
to fix the hang on boot with my Darwin images.
Zoltan, please can you test the attached patch to see if this still allows
MorphOS to boot?
Also this patch seems to slow down Finnix boot very much.
Regards,
BALATON Zoltan