On Sat, 7 Mar 2020, Mark Cave-Ayland wrote:
On 06/03/2020 22:59, BALATON Zoltan wrote:
I've done a quick grep of the source tree and AFAICT the only IDE controller
that
tries to use the PCI_INTERRUPT_LINE register is via-ide, which means this
should be
fairly easy. In short:
1) Add qemu_irq
On 06/03/2020 22:59, BALATON Zoltan wrote:
I've done a quick grep of the source tree and AFAICT the only IDE
controller that
tries to use the PCI_INTERRUPT_LINE register is via-ide, which means this
should be
fairly easy. In short:
1) Add qemu_irq
On Fri, 6 Mar 2020, Mark Cave-Ayland wrote:
On 06/03/2020 19:38, BALATON Zoltan wrote:
On Fri, 6 Mar 2020, Mark Cave-Ayland wrote:
On 06/03/2020 12:06, BALATON Zoltan wrote:
On Fri, 6 Mar 2020, Mark Cave-Ayland wrote:
On 05/03/2020 23:35, BALATON Zoltan wrote:
On real hardware this may be
On 06/03/2020 19:38, BALATON Zoltan wrote:
> On Fri, 6 Mar 2020, Mark Cave-Ayland wrote:
>> On 06/03/2020 12:06, BALATON Zoltan wrote:
>>> On Fri, 6 Mar 2020, Mark Cave-Ayland wrote:
On 05/03/2020 23:35, BALATON Zoltan wrote:
> On real hardware this may be true but in QEMU how would it
On Fri, 6 Mar 2020, Mark Cave-Ayland wrote:
On 06/03/2020 12:06, BALATON Zoltan wrote:
On Fri, 6 Mar 2020, Mark Cave-Ayland wrote:
On 05/03/2020 23:35, BALATON Zoltan wrote:
On real hardware this may be true but in QEMU how would it otherwise raise the
correct interrupt line the guest
On 06/03/2020 12:40, BALATON Zoltan wrote:
> On Fri, 6 Mar 2020, Mark Cave-Ayland wrote:
>> On 06/03/2020 00:21, BALATON Zoltan wrote:
>>> On Fri, 6 Mar 2020, BALATON Zoltan wrote:
On Thu, 5 Mar 2020, Mark Cave-Ayland wrote:
> On 04/03/2020 22:33, BALATON Zoltan wrote:
> another
On 06/03/2020 12:06, BALATON Zoltan wrote:
> On Fri, 6 Mar 2020, Mark Cave-Ayland wrote:
>> On 05/03/2020 23:35, BALATON Zoltan wrote:
>>> On real hardware this may be true but in QEMU how would it otherwise raise
>>> the
>>> correct interrupt line the guest expects? This probably does not
On Fri, 6 Mar 2020, Mark Cave-Ayland wrote:
On 06/03/2020 00:21, BALATON Zoltan wrote:
On Fri, 6 Mar 2020, BALATON Zoltan wrote:
On Thu, 5 Mar 2020, Mark Cave-Ayland wrote:
On 04/03/2020 22:33, BALATON Zoltan wrote:
another possibility: PCI configuration space register 0x3d (Interrupt pin) is
Hi guys,
On Sun, Mar 1, 2020 at 6:54 PM Mark Cave-Ayland
wrote:
>
> On 01/03/2020 16:42, BALATON Zoltan wrote:
>
> >> The other part I'm not sure about is that I can't see how
> >> via_ide_set_irq() can ever
> >> raise a native PCI IRQ - comparing with my experience on cmd646, should
> >>
On Fri, 6 Mar 2020, Mark Cave-Ayland wrote:
On 05/03/2020 23:35, BALATON Zoltan wrote:
On real hardware this may be true but in QEMU how would it otherwise raise the
correct interrupt line the guest expects? This probably does not matter for
pegasos2
but I think is needed for 100% native mode
On 06/03/2020 00:21, BALATON Zoltan wrote:
> On Fri, 6 Mar 2020, BALATON Zoltan wrote:
>> On Thu, 5 Mar 2020, Mark Cave-Ayland wrote:
>>> On 04/03/2020 22:33, BALATON Zoltan wrote:
>>> another possibility: PCI configuration space register 0x3d (Interrupt pin)
>>> is
>>> documented as having
On 05/03/2020 23:35, BALATON Zoltan wrote:
>> I just a quick look at the PCI specification and found this interesting
>> paragraph in
>> the section about "Interrupt Line":
>>
>>
>> "The Interrupt Line register is an eight-bit register used to communicate
>> interrupt
>> line routing
On Fri, 6 Mar 2020, BALATON Zoltan wrote:
On Thu, 5 Mar 2020, Mark Cave-Ayland wrote:
On 04/03/2020 22:33, BALATON Zoltan wrote:
another possibility: PCI configuration space register 0x3d (Interrupt pin)
is
documented as having value 0 == Legacy IRQ routing which should be the
initial value
On Thu, 5 Mar 2020, Mark Cave-Ayland wrote:
On 04/03/2020 22:33, BALATON Zoltan wrote:
AFAICT this then only leaves the question: why does the firmware set
PCI_INTERRUPT_LINE to 9, which is presumably why you are seeing problems running
MorphOS under QEMU.
Linux does try to handle both true
On 04/03/2020 22:33, BALATON Zoltan wrote:
>> AFAICT this then only leaves the question: why does the firmware set
>> PCI_INTERRUPT_LINE to 9, which is presumably why you are seeing problems
>> running
>> MorphOS under QEMU.
>
> Linux does try to handle both true native
On Wed, 4 Mar 2020, Mark Cave-Ayland wrote:
On 04/03/2020 00:22, BALATON Zoltan wrote:
So on that basis the best explanation as to what is happening is the
comment in the link you provided here:
On 04/03/2020 00:22, BALATON Zoltan wrote:
So on that basis the best explanation as to what is happening is the
comment in the link you provided here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/powerpc/platforms/chrp/pci.c?h=v4.14.172#n353
On Tue, 3 Mar 2020, Mark Cave-Ayland wrote:
On 02/03/2020 21:40, BALATON Zoltan wrote:
I had a quick look at the schematics linked from the page above, and they
confirm
that the VIA IDE interface is connected directly to IRQs 14 and 15 and not to
the PCI
interrupt pins.
Where did you see
On 02/03/2020 21:40, BALATON Zoltan wrote:
>> I had a quick look at the schematics linked from the page above, and they
>> confirm
>> that the VIA IDE interface is connected directly to IRQs 14 and 15 and not
>> to the PCI
>> interrupt pins.
>
> Where did you see that? What I got from trying
On Mon, 2 Mar 2020, Mark Cave-Ayland wrote:
On 01/03/2020 21:30, BALATON Zoltan wrote:
On Sun, 1 Mar 2020, Mark Cave-Ayland wrote:
On 01/03/2020 18:53, BALATON Zoltan wrote:
On Sun, 1 Mar 2020, BALATON Zoltan wrote:
is not legacy mode but "not 100% native mode". The prog-if is set to 0x8a
On 01/03/2020 21:30, BALATON Zoltan wrote:
> On Sun, 1 Mar 2020, Mark Cave-Ayland wrote:
>> On 01/03/2020 18:53, BALATON Zoltan wrote:
>>> On Sun, 1 Mar 2020, BALATON Zoltan wrote:
is not legacy mode but "not 100% native mode". The prog-if is set to 0x8a
which
corresponds to
On Sun, 1 Mar 2020, Mark Cave-Ayland wrote:
On 01/03/2020 18:53, BALATON Zoltan wrote:
On Sun, 1 Mar 2020, BALATON Zoltan wrote:
is not legacy mode but "not 100% native mode". The prog-if is set to 0x8a which
corresponds to native mode but this is what the Linux fixup function does,
firmware
On 01/03/2020 18:53, BALATON Zoltan wrote:
> On Sun, 1 Mar 2020, BALATON Zoltan wrote:
>> is not legacy mode but "not 100% native mode". The prog-if is set to 0x8a
>> which
>> corresponds to native mode but this is what the Linux fixup function does,
>> firmware
>> sets it to 0x8f which means
On Sun, 1 Mar 2020, BALATON Zoltan wrote:
is not legacy mode but "not 100% native mode". The prog-if is set to 0x8a
which corresponds to native mode but this is what the Linux fixup function
does, firmware sets it to 0x8f which means native mode.
I mean, 0x8a legacy mode and 0x8f native mode,
On Sun, 1 Mar 2020, Mark Cave-Ayland wrote:
On 01/03/2020 16:42, BALATON Zoltan wrote:
The other part I'm not sure about is that I can't see how via_ide_set_irq() can
ever
raise a native PCI IRQ - comparing with my experience on cmd646, should there
not be
a pci_set_irq(d, level) at the end?
On 01/03/2020 16:42, BALATON Zoltan wrote:
>> The other part I'm not sure about is that I can't see how via_ide_set_irq()
>> can ever
>> raise a native PCI IRQ - comparing with my experience on cmd646, should
>> there not be
>> a pci_set_irq(d, level) at the end?
>
> According to my tests with
On Sun, 1 Mar 2020, Mark Cave-Ayland wrote:
On 01/03/2020 11:35, Mark Cave-Ayland wrote:
On 29/02/2020 23:02, BALATON Zoltan wrote:
Some machines operate in "non 100% native mode" where interrupts are
fixed at legacy IDE interrupts and some guests expect this behaviour
without checking based
On Sun, 1 Mar 2020, Mark Cave-Ayland wrote:
On 29/02/2020 23:02, BALATON Zoltan wrote:
Some machines operate in "non 100% native mode" where interrupts are
fixed at legacy IDE interrupts and some guests expect this behaviour
without checking based on knowledge about hardware. Even Linux has
On 01/03/2020 11:35, Mark Cave-Ayland wrote:
> On 29/02/2020 23:02, BALATON Zoltan wrote:
>
>> Some machines operate in "non 100% native mode" where interrupts are
>> fixed at legacy IDE interrupts and some guests expect this behaviour
>> without checking based on knowledge about hardware. Even
On 29/02/2020 23:02, BALATON Zoltan wrote:
> Some machines operate in "non 100% native mode" where interrupts are
> fixed at legacy IDE interrupts and some guests expect this behaviour
> without checking based on knowledge about hardware. Even Linux has
> arch specific workarounds for this that
Some machines operate in "non 100% native mode" where interrupts are
fixed at legacy IDE interrupts and some guests expect this behaviour
without checking based on knowledge about hardware. Even Linux has
arch specific workarounds for this that are activated on such boards
so this needs to be
31 matches
Mail list logo
