qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH] fdc: remove sparc sun4m mutations


From: John Snow
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH] fdc: remove sparc sun4m mutations
Date: Thu, 19 Mar 2015 13:57:21 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0



On 03/19/2015 10:25 AM, Mark Cave-Ayland wrote:
On 17/03/15 06:43, Hervé Poussineau wrote:

Hi,

Le 16/03/2015 22:48, John Snow a écrit :
On 03/14/2015 12:50 PM, Hervé Poussineau wrote:
They were introduced in 6f7e9aec5eb5bdfa57a9e458e391b785c283a007 and
82407d1a4035e5bfefb53ffdcb270872f813b34c and lots of bug fixes were
done after that.

This fixes (at least) the detection of the floppy controller on
Debian 4.0r9/SPARC,
and SS-5's OBP initialization routine still works.


Removing workaround code from six years ago in a device we hardly
touch seems sane to me if it doesn't appear to break the machine it
was originally architected for (SS-5, from 82407d1a's commit
message), but I am not well versed in SPARC configurations,
unfortunately for us :)

It appears this quirk is active for a wide number of machine
configurations (basically all that appear under sun4m_machine_init) --
What's the risk of us breaking one of those configurations?

How did you test SS-5? (Can we test the others similarly? Is there a
justification for not doing so?)

According to 82407d1a4035e5bfefb53ffdcb270872f813b34c, there was
probably a hang when SS-5 OBP firmware was initializing the floppy. I
checked my change with the OBP SS-5 firmware 2.15, which doesn't hang
and goes up to firmware prompt. I also tested SS-4, SS-10 (OBP v3.45)
and SS-20 (OBP 2.25) which also go up to firmware prompt. I was unable
to test the other platforms with OBP.
Then, I tested SS-5 with Debian 4.0r9, and boot messages now detect the
floppy controller with "Floppy drive(s): fd0 is 1.44M" and "FDC 0 is a
S82078B"

However, in 82407d1a4035e5bfefb53ffdcb270872f813b34c, floppy was
probably not working, and is still broken after this commit. This may be
due to a missing DMA controller on sparc platform.

Yeah, I'm fairly sure from Hervé's work in this area that the existing
sun4m floppy disk could never function correctly anyway. Given that this
is the case, I'd be okay with having this patch applied for all sun4m
models so that it can at least be detected, and hopefully persuaded to
work with only a little more effort.


ATB,

Mark.


Sounds good to me. Will stage for 2.4.

Thanks,
--js



reply via email to

[Prev in Thread] Current Thread [Next in Thread]