[OpenBIOS] Faulty Qemu SPARC64 IDE emulation?

[Blue Swirl]

On Sun, Dec 13, 2009 at 11:53 AM, Igor Kovalenko
<igor.v.kovalenko at gmail.com> wrote:
> On Fri, Dec 11, 2009 at 12:49 AM, Igor Kovalenko
> <igor.v.kovalenko at gmail.com> wrote:
>> On Fri, Dec 11, 2009 at 12:22 AM, Nick Couchman <Nick.Couchman at seakr.com> wrote:
>>>>
>>>> Ide emulation issue is not on qemu list yet. From what I see here it
>>>> is not really a driver implementation fault because driver callback
>>>> gets bogus pointer. Probably this is caused by some clash with low
>>>> memory location where device i/o space is mapped.
>>>
>>> Pardon my ignorance, but are you saying that Qemu is throwing a bogus pointer back to OpenBIOS, or that there's something wrong with OpenBIOS that's requesting the wrong memory location?  So is it worth opening a thread on the qemu-devel list, or is everyone who needs to work the problem already on this list?
>>
>> I think it's both parties, in that openbios calls cause qemu code to
>> crash, which should not happen. Still the crash is in emulation code,
>> and that is to be fixed eventually.
>> What I'm sure about at the moment is that we can work around qemu
>> issues in this area by moving most of pci address space out of 32bit
>> memory. Related change to qemu is already proposed on the qemu-devel
>> list quite a while ago, and most of the required changes are now
>> implemented, like 64bit wide addressing for mapped pci memory space -
>> that is now possible. What's left is the actual remapping change, that
>> would need more time to get into code base, as current proposal may be
>> seen as functional but conceptually wrong workaround.
>> That said I'd be happy to see a fix for this cmd646 crash issue in
>> qemu, and will look into tracing this crash to root cause.
>
> The qemu issue with cmd646 amounts to a bug in reading or writing
> registers for second dma channel. It appears to be a regression, but
> withoud cmd646 documentation it is not clear how to fix it. It may be
> that original cmd646 code is misinterpreting dma channel data.
> First channel should work though.

I found the data sheet from:
http://www.datasheet.org.uk/pdf/Datasheet-03/DSA0038524.pdf

However, it refers to Intel docs for bus master register programming.

> How we get to dma channel registers? Those are mapped into
> low 16mb of memory by openbios startup code, and it turns out
> that we do not claim that mapped memory so it is still claimable.
> Milax loader claims that memory for it's own needs, and loading
> data there does write something to cmd646 dma channel registers.
>
> How do we solve this?
>
> - My original idea was to relocate i/o space so that low physical
> memory address space does not intersect with i/o space. A few
> required changes to both qemu and openbios code are in the works.

I think this would be closest to how real HW operates.

> - Alternatively we can claim mapped address space, so milax
> loader does not use it on it's own. Please see the patch attached,
> it allows to skip cmd646 implementation issue since openbios
> will not access broken part of register space.

I didn't see any improvement in the few tests I tried. I guess the
patch does not hurt, though.