[OpenBIOS] Faulty Qemu SPARC64 IDE emulation?

Igor Kovalenko igor.v.kovalenko at gmail.com
Sun Dec 13 18:49:35 CET 2009


On Sun, Dec 13, 2009 at 7:19 PM, Blue Swirl <blauwirbel at gmail.com> wrote:
> 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.

We also need to find out how memory mappings are laid out
preparing to run client code. It is not clear from of1275 docs.

>> - 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.

It stops writing over 0x700...0x70d range while loading block
from device, that range is where bmdma registers are mapped.
To see this logged I have to turn on DEBUG_IDE in qemu.

-- 
Kind regards,
Igor V. Kovalenko



More information about the OpenBIOS mailing list