[OpenBIOS] Faulty Qemu SPARC64 IDE emulation?

[Igor Kovalenko]

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.

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.

- 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'm positive there are more issues with address mappings
done by openbios, both for client program code and for own
use as well. If someone could enlighten me on how memory
mappings should look like at the time client program receives
control, it would be sincerely appreciated.

-- 
Kind regards,
Igor V. Kovalenko
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sparc64-ofmem-claim-bootmap
Type: application/octet-stream
Size: 576 bytes
Desc: not available
URL: <http://lists.openbios.org/pipermail/openbios/attachments/20091213/19d851ba/attachment.dmg>