Re: [Qemu-ppc] [Qemu-devel] macio ide question/bug report

[Mark Cave-Ayland]

On 12/05/14 20:32, BALATON Zoltan wrote:

> On Mon, 12 May 2014, Mark Cave-Ayland wrote:
> > On 10/05/14 13:30, BALATON Zoltan wrote:
> > > That patch would be 80fc95d8bdaf3392106b131a97ca701fd374489a in QEMU
> > > master. I've tried reverting it and Darwin still boots (without -M
> > > mac99) up to the point where it asks to install as before but I don't
> > > know how good a test is this as I'm not sure it does unaligned accesses
> > > up to this point. I see accesses like this:
> > >
> > > pmac_ide_transfer(ATAPI) lba=ffffffff, buffer_index=30, len=930
> > > pmac_ide_transfer(ATAPI) lba=0, buffer_index=0, len=930
> >
> > Here is an example of an unaligned access, where the length is not a
> > multiple of 0x200 (512 bytes) which was required for the block layer
> > DMA APIs at the time it was written. If you can get to the same point
> > with the patch reverted, then it means Kevin's patchset for byte-level
> > rather than sector-level granularity for block requests is working.
>
> These logs were with the above commit reverted so it's probably not
> needed any more. I've tried booting Darwin 6.0.2, Darwin 8.0.1 up to the
> installation (did not install it) and Finnix 109 and they seem to work
> as before.

Okay that's definitely an improvement on what's there already :)  When I 
find a moment, I'll try some local testing here and see if it's worth 
submitting a patch.

> > > This still produces an error in MorphOS as before:
> > >
> > > DBDMA: writel 0x0000000000000d0c <= 0x00e5ac80
> > > DBDMA: channel 0x1a reg 0x3
> > > DBDMA: dbdma_cmdptr_load 0x00e5ac80
> > > ATAPI limit=0x8000 packet: 43 00 00 00 00 00 00 03 24 00 00 00
> > >
> > > DBDMA: DBDMA_run_bh
> > > DBDMA: writel 0x0000000000000d00 <= 0x80008000
> > > DBDMA: channel 0x1a reg 0x0
> > > DBDMA:     status 0x00008400
> > > DBDMA: readl 0x0000000000000d00 => 0x80008000
> > > DBDMA: channel 0x1a reg 0x0
> > > DBDMA: DBDMA_run_bh
> > > DBDMA: channel_run
> > > dbdma_cmd 0x7f7dddff5ae0
> > >      req_count 0x0324
> > >      command 0x3000
> > >      phy_addr 0x00e7dddc
> > >      cmd_dep 0x00000000
> > >      res_count 0x0000
> > >      xfer_status 0x0000
> > > DBDMA: start_input
> > > DBDMA: addr 0xe7dddc key 0x0
> > > pmac_ide_transfer(ATAPI) lba=ffffffff, buffer_index=0, len=324
> >
> > ^^^^^
> >
> > > io_buffer_size = 0
> > > io->len = 0x324
> > > sector_num=-1 size=20, cmd_cmd=0
> > > atapi_cmd_error: sense=0x5 asc=0x21
> > > done DMA
> > > DBDMA: dbdma_end

(cut)

> MorphOS and Darwin are definitely doing things differently. I hope
> someone who understands what is happening can explain it why one of them
> works while the other doesn't.

Which I hope is what I'm trying to do? From hw/ide/atapi.c you can see 
that command 0x43 is read the TOC which according to atapi_cmd_table 
should call cmd_read_toc_pma_atip(). You can see that in your MorphOS 
case you are getting a line with a "atapi_cmd_error" prefix which 
indicates that something is calling ide_atapi_cmd_error() to return an 
error code instead of ide_atapi_cmd_reply() which would output the 
"reply" prefix as seen in your Darwin case. So you need to step through 
these functions in QEMU in order to see why your ATAPI command is failing.


HTH,

Mark.