Is the ppc440 "bamboo" board in QEMU still of any use?

Is the ppc440 "bamboo" board in QEMU still of any use?

[Thomas Huth]

  Hi,

I tried to build a current Linux kernel for the "bamboo" board and use it in 
QEMU, but QEMU then quickly aborts with:

  pci.c:262: pci_bus_change_irq_level: Assertion `irq_num >= 0' failed.

(or with a "DCR write error" if I try to use the cuImage instead).

I googled a little bit and found this discussion:

https://qemu-devel.nongnu.narkive.com/vYHona3u/emulating-powerpc-440ep-with-qemu-system-ppcemb#post2

Seems like this board was used for KVM on the PPC440 only, and has never 
been enabled with the TCG emulation?

Well, KVM support on the 440 has been removed years ago already:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2677b8dd8de0dc1496ede4da09b9dfd59f15cea

So is this "bamboo" board dead code in QEMU now? Or does anybody still have 
a kernel binary which could be used for testing it? Note: This board does 
not support "-bios", so u-boot or other firmwares are certainly also not an 
option here...
Should we mark "bamboo" as deprecated nowadays?

  Thomas

Re: Is the ppc440 "bamboo" board in QEMU still of any use?

[Christophe Leroy]

Le 14/10/2021 à 11:31, Thomas Huth a écrit :
> 
>   Hi,
> 
> I tried to build a current Linux kernel for the "bamboo" board and use 
> it in QEMU, but QEMU then quickly aborts with:
> 
>   pci.c:262: pci_bus_change_irq_level: Assertion `irq_num >= 0' failed.
> 
> (or with a "DCR write error" if I try to use the cuImage instead).
> 
> I googled a little bit and found this discussion:
> 
> https://qemu-devel.nongnu.narkive.com/vYHona3u/emulating-powerpc-440ep-with-qemu-system-ppcemb#post2 
> 
> 
> Seems like this board was used for KVM on the PPC440 only, and has never 
> been enabled with the TCG emulation?
> 
> Well, KVM support on the 440 has been removed years ago already:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2677b8dd8de0dc1496ede4da09b9dfd59f15cea 
> 
> 
> So is this "bamboo" board dead code in QEMU now? Or does anybody still 
> have a kernel binary which could be used for testing it? Note: This 
> board does not support "-bios", so u-boot or other firmwares are 
> certainly also not an option here...
> Should we mark "bamboo" as deprecated nowadays?
> 

I have the following change in QEMU to be able to run the bamboo, found 
it some time ago via google (can't remember where):

diff --git a/hw/ppc/ppc4xx_pci.c b/hw/ppc/ppc4xx_pci.c
index 8147ba6f94..600e89e791 100644
--- a/hw/ppc/ppc4xx_pci.c
+++ b/hw/ppc/ppc4xx_pci.c
@@ -246,7 +246,7 @@ static int ppc4xx_pci_map_irq(PCIDevice *pci_dev, 
int irq_num)

      trace_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot);

-    return slot - 1;
+    return slot ? slot - 1 : slot;
  }

  static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level)
---

It's probably no the final change, but at least it allows booting bamboo 
on qemu again.

Christophe

Re: Is the ppc440 "bamboo" board in QEMU still of any use?

[Christophe Leroy]

Le 14/10/2021 à 12:34, Christophe Leroy a écrit :
> 
> 
> Le 14/10/2021 à 11:31, Thomas Huth a écrit :
>>
>>   Hi,
>>
>> I tried to build a current Linux kernel for the "bamboo" board and use 
>> it in QEMU, but QEMU then quickly aborts with:
>>
>>   pci.c:262: pci_bus_change_irq_level: Assertion `irq_num >= 0' failed.
>>
>> (or with a "DCR write error" if I try to use the cuImage instead).
>>
>> I googled a little bit and found this discussion:
>>
>> https://qemu-devel.nongnu.narkive.com/vYHona3u/emulating-powerpc-440ep-with-qemu-system-ppcemb#post2 
>>
>>
>> Seems like this board was used for KVM on the PPC440 only, and has 
>> never been enabled with the TCG emulation?
>>
>> Well, KVM support on the 440 has been removed years ago already:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2677b8dd8de0dc1496ede4da09b9dfd59f15cea 
>>
>>
>> So is this "bamboo" board dead code in QEMU now? Or does anybody still 
>> have a kernel binary which could be used for testing it? Note: This 
>> board does not support "-bios", so u-boot or other firmwares are 
>> certainly also not an option here...
>> Should we mark "bamboo" as deprecated nowadays?
>>
> 
> I have the following change in QEMU to be able to run the bamboo, found 
> it some time ago via google (can't remember where):
> 
> diff --git a/hw/ppc/ppc4xx_pci.c b/hw/ppc/ppc4xx_pci.c
> index 8147ba6f94..600e89e791 100644
> --- a/hw/ppc/ppc4xx_pci.c
> +++ b/hw/ppc/ppc4xx_pci.c
> @@ -246,7 +246,7 @@ static int ppc4xx_pci_map_irq(PCIDevice *pci_dev, 
> int irq_num)
> 
>       trace_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot);
> 
> -    return slot - 1;
> +    return slot ? slot - 1 : slot;
>   }
> 
>   static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level)
> ---
> 
> It's probably no the final change, but at least it allows booting bamboo 
> on qemu again.
> 

Found the source : 
https://www.mail-archive.com/qemu-devel@nongnu.org/msg769121.html

Christophe

Re: Is the ppc440 "bamboo" board in QEMU still of any use?

[Cédric Le Goater]

On 10/14/21 12:34, Christophe Leroy wrote:
> 
> 
> Le 14/10/2021 à 11:31, Thomas Huth a écrit :
>>
>>   Hi,
>>
>> I tried to build a current Linux kernel for the "bamboo" board and use it in QEMU, but QEMU then quickly aborts with:
>>
>>   pci.c:262: pci_bus_change_irq_level: Assertion `irq_num >= 0' failed.
>>
>> (or with a "DCR write error" if I try to use the cuImage instead).
>>
>> I googled a little bit and found this discussion:
>>
>> https://qemu-devel.nongnu.narkive.com/vYHona3u/emulating-powerpc-440ep-with-qemu-system-ppcemb#post2
>>
>> Seems like this board was used for KVM on the PPC440 only, and has never been enabled with the TCG emulation?
>>
>> Well, KVM support on the 440 has been removed years ago already:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2677b8dd8de0dc1496ede4da09b9dfd59f15cea
>>
>> So is this "bamboo" board dead code in QEMU now? Or does anybody still have a kernel binary which could be used for testing it? Note: This board does not support "-bios", so u-boot or other firmwares are certainly also not an option here...
>> Should we mark "bamboo" as deprecated nowadays?
>>
> 
> I have the following change in QEMU to be able to run the bamboo, found it some time ago via google (can't remember where):
> 
> diff --git a/hw/ppc/ppc4xx_pci.c b/hw/ppc/ppc4xx_pci.c
> index 8147ba6f94..600e89e791 100644
> --- a/hw/ppc/ppc4xx_pci.c
> +++ b/hw/ppc/ppc4xx_pci.c
> @@ -246,7 +246,7 @@ static int ppc4xx_pci_map_irq(PCIDevice *pci_dev, int irq_num)
> 
>       trace_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot);
> 
> -    return slot - 1;
> +    return slot ? slot - 1 : slot;
>   }
> 
>   static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level)

could you try to use :

static inline int ppce500_pci_map_irq_slot(int devno, int irq_num)
{
     return (devno + irq_num) % 4;
}

Thanks,

C.

Re: Is the ppc440 "bamboo" board in QEMU still of any use?

[Mark Cave-Ayland]

On 14/10/2021 11:47, Christophe Leroy wrote:

> Le 14/10/2021 à 12:34, Christophe Leroy a écrit :
>>
>>
>> Le 14/10/2021 à 11:31, Thomas Huth a écrit :
>>>
>>>   Hi,
>>>
>>> I tried to build a current Linux kernel for the "bamboo" board and use it in QEMU, 
>>> but QEMU then quickly aborts with:
>>>
>>>   pci.c:262: pci_bus_change_irq_level: Assertion `irq_num >= 0' failed.
>>>
>>> (or with a "DCR write error" if I try to use the cuImage instead).
>>>
>>> I googled a little bit and found this discussion:
>>>
>>> https://qemu-devel.nongnu.narkive.com/vYHona3u/emulating-powerpc-440ep-with-qemu-system-ppcemb#post2 
>>>
>>>
>>> Seems like this board was used for KVM on the PPC440 only, and has never been 
>>> enabled with the TCG emulation?
>>>
>>> Well, KVM support on the 440 has been removed years ago already:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2677b8dd8de0dc1496ede4da09b9dfd59f15cea 
>>>
>>>
>>> So is this "bamboo" board dead code in QEMU now? Or does anybody still have a 
>>> kernel binary which could be used for testing it? Note: This board does not 
>>> support "-bios", so u-boot or other firmwares are certainly also not an option 
>>> here...
>>> Should we mark "bamboo" as deprecated nowadays?
>>>
>>
>> I have the following change in QEMU to be able to run the bamboo, found it some 
>> time ago via google (can't remember where):
>>
>> diff --git a/hw/ppc/ppc4xx_pci.c b/hw/ppc/ppc4xx_pci.c
>> index 8147ba6f94..600e89e791 100644
>> --- a/hw/ppc/ppc4xx_pci.c
>> +++ b/hw/ppc/ppc4xx_pci.c
>> @@ -246,7 +246,7 @@ static int ppc4xx_pci_map_irq(PCIDevice *pci_dev, int irq_num)
>>
>>       trace_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot);
>>
>> -    return slot - 1;
>> +    return slot ? slot - 1 : slot;
>>   }
>>
>>   static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level)
>> ---
>>
>> It's probably no the final change, but at least it allows booting bamboo on qemu 
>> again.
>>
> 
> Found the source : https://www.mail-archive.com/qemu-devel@nongnu.org/msg769121.html

Ah yes, that thread rings a bell. I think the important part was in my initial reply 
at https://www.mail-archive.com/qemu-devel@nongnu.org/msg769115.html: in other words 
ppc4xx_pci_map_irq() function expects the IRQ number to range from 1 to 4.

When I looked at this the issue was caused by the guest writing to PCI configuration 
space to disable PCI interrupts: this ends up calling pci_update_irq_disabled() as below:

/* Called after interrupt disabled field update in config space,
  * assert/deassert interrupts if necessary.
  * Gets original interrupt disable bit value (before update). */
static void pci_update_irq_disabled(PCIDevice *d, int was_irq_disabled)
{
     int i, disabled = pci_irq_disabled(d);
     if (disabled == was_irq_disabled)
         return;
     for (i = 0; i < PCI_NUM_PINS; ++i) {
         int state = pci_irq_state(d, i);
         pci_change_irq_level(d, i, disabled ? -state : state);
     }
}

Since the IRQ is disabled pci_change_irq_level() ends up being called with -1 which 
triggers the assert().

My feeling is that the existing assert() is correct, since from what I can see 
without it there would be an IRQ array underflow, however I wasn't sure whether 
passing a negative number to pci_change_irq_level() is supposed to be valid?


ATB,

Mark.

Re: Is the ppc440 "bamboo" board in QEMU still of any use?

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 4610 bytes --]

On Thu, 14 Oct 2021, Mark Cave-Ayland wrote:
> On 14/10/2021 11:47, Christophe Leroy wrote:
>> Le 14/10/2021 à 12:34, Christophe Leroy a écrit :
>>> Le 14/10/2021 à 11:31, Thomas Huth a écrit :
>>>> 
>>>>   Hi,
>>>> 
>>>> I tried to build a current Linux kernel for the "bamboo" board and use it 
>>>> in QEMU, but QEMU then quickly aborts with:
>>>> 
>>>>   pci.c:262: pci_bus_change_irq_level: Assertion `irq_num >= 0' failed.
>>>> 
>>>> (or with a "DCR write error" if I try to use the cuImage instead).
>>>> 
>>>> I googled a little bit and found this discussion:
>>>> 
>>>> https://qemu-devel.nongnu.narkive.com/vYHona3u/emulating-powerpc-440ep-with-qemu-system-ppcemb#post2 
>>>> 
>>>> Seems like this board was used for KVM on the PPC440 only, and has never 
>>>> been enabled with the TCG emulation?
>>>> 
>>>> Well, KVM support on the 440 has been removed years ago already:
>>>> 
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2677b8dd8de0dc1496ede4da09b9dfd59f15cea 
>>>> 
>>>> So is this "bamboo" board dead code in QEMU now? Or does anybody still 
>>>> have a kernel binary which could be used for testing it? Note: This board 
>>>> does not support "-bios", so u-boot or other firmwares are certainly also 
>>>> not an option here...
>>>> Should we mark "bamboo" as deprecated nowadays?
>>>> 
>>> 
>>> I have the following change in QEMU to be able to run the bamboo, found it 
>>> some time ago via google (can't remember where):
>>> 
>>> diff --git a/hw/ppc/ppc4xx_pci.c b/hw/ppc/ppc4xx_pci.c
>>> index 8147ba6f94..600e89e791 100644
>>> --- a/hw/ppc/ppc4xx_pci.c
>>> +++ b/hw/ppc/ppc4xx_pci.c
>>> @@ -246,7 +246,7 @@ static int ppc4xx_pci_map_irq(PCIDevice *pci_dev, int 
>>> irq_num)
>>> 
>>>       trace_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot);
>>> 
>>> -    return slot - 1;
>>> +    return slot ? slot - 1 : slot;
>>>   }
>>> 
>>>   static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level)
>>> ---
>>> 
>>> It's probably no the final change, but at least it allows booting bamboo 
>>> on qemu again.
>>> 
>> 
>> Found the source : 
>> https://www.mail-archive.com/qemu-devel@nongnu.org/msg769121.html
>
> Ah yes, that thread rings a bell. I think the important part was in my 
> initial reply at 
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg769115.html: in other 
> words ppc4xx_pci_map_irq() function expects the IRQ number to range from 1 to 
> 4.
>
> When I looked at this the issue was caused by the guest writing to PCI 
> configuration space to disable PCI interrupts: this ends up calling 
> pci_update_irq_disabled() as below:
>
> /* Called after interrupt disabled field update in config space,
> * assert/deassert interrupts if necessary.
> * Gets original interrupt disable bit value (before update). */
> static void pci_update_irq_disabled(PCIDevice *d, int was_irq_disabled)
> {
>    int i, disabled = pci_irq_disabled(d);
>    if (disabled == was_irq_disabled)
>        return;
>    for (i = 0; i < PCI_NUM_PINS; ++i) {
>        int state = pci_irq_state(d, i);
>        pci_change_irq_level(d, i, disabled ? -state : state);
>    }
> }
>
> Since the IRQ is disabled pci_change_irq_level() ends up being called with -1 
> which triggers the assert().
>
> My feeling is that the existing assert() is correct, since from what I can 
> see without it there would be an IRQ array underflow, however I wasn't sure 
> whether passing a negative number to pci_change_irq_level() is supposed to be 
> valid?

A comment from Peter Maydell in hw/ppc/ppc440_pcix.c which is similar code 
for sam460ex says:

/*
  * All four IRQ[ABCD] pins from all slots are tied to a single board
  * IRQ, so our mapping function here maps everything to IRQ 0.
  * The code in pci_change_irq_level() tracks the number of times
  * the mapped IRQ is asserted and deasserted, so if multiple devices
  * assert an IRQ at the same time the behaviour is correct.
  *
  * This may need further refactoring for boards that use multiple IRQ lines.
  */
static int ppc440_pcix_map_irq(PCIDevice *pci_dev, int irq_num)

So I guess negative values could be valid to mean decrease the number of 
times this was raised but I'm not sure. The sam460ex maps all PCI 
interrupts to a single IRQ so this function just returns 0 and let the 
hw/pci/pci.c deal with the rest. Something similar might work for 440ep 
but don't know what the real hardware does. I could not find any 
explanation or IRQ mapping in the data sheets I have on 440ep but this may 
be specific to the bamboo board and we don't have much info on that.

Regards,
BALATON Zoltan

Re: Is the ppc440 "bamboo" board in QEMU still of any use?

[Philippe Mathieu-Daudé]

On 10/14/21 13:29, Cédric Le Goater wrote:
> On 10/14/21 12:34, Christophe Leroy wrote:

>> I have the following change in QEMU to be able to run the bamboo,
>> found it some time ago via google (can't remember where):
>>
>> diff --git a/hw/ppc/ppc4xx_pci.c b/hw/ppc/ppc4xx_pci.c
>> index 8147ba6f94..600e89e791 100644
>> --- a/hw/ppc/ppc4xx_pci.c
>> +++ b/hw/ppc/ppc4xx_pci.c
>> @@ -246,7 +246,7 @@ static int ppc4xx_pci_map_irq(PCIDevice *pci_dev,
>> int irq_num)
>>
>>       trace_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot);
>>
>> -    return slot - 1;
>> +    return slot ? slot - 1 : slot;
>>   }
>>
>>   static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level)
> 
> could you try to use :
> 
> static inline int ppce500_pci_map_irq_slot(int devno, int irq_num)
> {
>     return (devno + irq_num) % 4;
> }

Is this pci_swizzle()?

Re: Is the ppc440 "bamboo" board in QEMU still of any use?

[Greg Kurz]

On Thu, 14 Oct 2021 17:26:53 +0200
Philippe Mathieu-Daudé <philmd@redhat.com> wrote:

> On 10/14/21 13:29, Cédric Le Goater wrote:
> > On 10/14/21 12:34, Christophe Leroy wrote:
> 
> >> I have the following change in QEMU to be able to run the bamboo,
> >> found it some time ago via google (can't remember where):
> >>
> >> diff --git a/hw/ppc/ppc4xx_pci.c b/hw/ppc/ppc4xx_pci.c
> >> index 8147ba6f94..600e89e791 100644
> >> --- a/hw/ppc/ppc4xx_pci.c
> >> +++ b/hw/ppc/ppc4xx_pci.c
> >> @@ -246,7 +246,7 @@ static int ppc4xx_pci_map_irq(PCIDevice *pci_dev,
> >> int irq_num)
> >>
> >>       trace_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot);
> >>
> >> -    return slot - 1;
> >> +    return slot ? slot - 1 : slot;
> >>   }
> >>
> >>   static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level)
> > 
> > could you try to use :
> > 
> > static inline int ppce500_pci_map_irq_slot(int devno, int irq_num)
> > {
> >     return (devno + irq_num) % 4;
> > }
> 
> Is this pci_swizzle()?
> 

Yes :-)

Re: Is the ppc440 "bamboo" board in QEMU still of any use?

[Thomas Huth]

On 14/10/2021 17.26, Philippe Mathieu-Daudé wrote:
> On 10/14/21 13:29, Cédric Le Goater wrote:
>> On 10/14/21 12:34, Christophe Leroy wrote:
> 
>>> I have the following change in QEMU to be able to run the bamboo,
>>> found it some time ago via google (can't remember where):
>>>
>>> diff --git a/hw/ppc/ppc4xx_pci.c b/hw/ppc/ppc4xx_pci.c
>>> index 8147ba6f94..600e89e791 100644
>>> --- a/hw/ppc/ppc4xx_pci.c
>>> +++ b/hw/ppc/ppc4xx_pci.c
>>> @@ -246,7 +246,7 @@ static int ppc4xx_pci_map_irq(PCIDevice *pci_dev,
>>> int irq_num)
>>>
>>>        trace_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot);
>>>
>>> -    return slot - 1;
>>> +    return slot ? slot - 1 : slot;
>>>    }
>>>
>>>    static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level)
>>
>> could you try to use :
>>
>> static inline int ppce500_pci_map_irq_slot(int devno, int irq_num)
>> {
>>      return (devno + irq_num) % 4;
>> }
> 
> Is this pci_swizzle()?

It's pci_swizzle, but I don't think that we should take irq_num into account 
here. The comment right in front of the function says:

  On Bamboo, all pins from each slot are tied to a single board IRQ

Similar comment in pc-bios/bamboo.dts:

  Bamboo has all 4 IRQ pins tied together per slot

So the return value should only depend on the slot number.

Not sure how to properly fix this yet, though.

  Thomas


PS: Found a working pre-compiled kernel for bamboo:
http://landley.net/aboriginal/downloads/binaries/system-image-powerpc-440fp.tar.gz

Re: Is the ppc440 "bamboo" board in QEMU still of any use?

[Mark Cave-Ayland]

On 14/10/2021 16:37, Thomas Huth wrote:

> On 14/10/2021 17.26, Philippe Mathieu-Daudé wrote:
>> On 10/14/21 13:29, Cédric Le Goater wrote:
>>> On 10/14/21 12:34, Christophe Leroy wrote:
>>
>>>> I have the following change in QEMU to be able to run the bamboo,
>>>> found it some time ago via google (can't remember where):
>>>>
>>>> diff --git a/hw/ppc/ppc4xx_pci.c b/hw/ppc/ppc4xx_pci.c
>>>> index 8147ba6f94..600e89e791 100644
>>>> --- a/hw/ppc/ppc4xx_pci.c
>>>> +++ b/hw/ppc/ppc4xx_pci.c
>>>> @@ -246,7 +246,7 @@ static int ppc4xx_pci_map_irq(PCIDevice *pci_dev,
>>>> int irq_num)
>>>>
>>>>        trace_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot);
>>>>
>>>> -    return slot - 1;
>>>> +    return slot ? slot - 1 : slot;
>>>>    }
>>>>
>>>>    static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level)
>>>
>>> could you try to use :
>>>
>>> static inline int ppce500_pci_map_irq_slot(int devno, int irq_num)
>>> {
>>>      return (devno + irq_num) % 4;
>>> }
>>
>> Is this pci_swizzle()?
> 
> It's pci_swizzle, but I don't think that we should take irq_num into account here. 
> The comment right in front of the function says:
> 
>   On Bamboo, all pins from each slot are tied to a single board IRQ
> 
> Similar comment in pc-bios/bamboo.dts:
> 
>   Bamboo has all 4 IRQ pins tied together per slot
> 
> So the return value should only depend on the slot number.
> 
> Not sure how to properly fix this yet, though.
> 
>   Thomas
> 
> 
> PS: Found a working pre-compiled kernel for bamboo:
> http://landley.net/aboriginal/downloads/binaries/system-image-powerpc-440fp.tar.gz

Hi Thomas,

Did you see my reply from earlier today? Last time I checked the backtrace from the 
assert() it was coming via pci_update_irq_disabled() although that's not to say that 
something else could have changed since the original thread.


ATB,

Mark.

Re: Is the ppc440 "bamboo" board in QEMU still of any use?

[Cédric Le Goater]

On 10/14/21 17:26, Philippe Mathieu-Daudé wrote:
> On 10/14/21 13:29, Cédric Le Goater wrote:
>> On 10/14/21 12:34, Christophe Leroy wrote:
> 
>>> I have the following change in QEMU to be able to run the bamboo,
>>> found it some time ago via google (can't remember where):
>>>
>>> diff --git a/hw/ppc/ppc4xx_pci.c b/hw/ppc/ppc4xx_pci.c
>>> index 8147ba6f94..600e89e791 100644
>>> --- a/hw/ppc/ppc4xx_pci.c
>>> +++ b/hw/ppc/ppc4xx_pci.c
>>> @@ -246,7 +246,7 @@ static int ppc4xx_pci_map_irq(PCIDevice *pci_dev,
>>> int irq_num)
>>>
>>>        trace_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot);
>>>
>>> -    return slot - 1;
>>> +    return slot ? slot - 1 : slot;
>>>    }
>>>
>>>    static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level)
>>
>> could you try to use :
>>
>> static inline int ppce500_pci_map_irq_slot(int devno, int irq_num)
>> {
>>      return (devno + irq_num) % 4;
>> }
> 
> Is this pci_swizzle()?

Hey it's a pre pci_swizzle() version :)

I guess all these PPC PCI models should be using this pci_swizzle()
routine.

Thanks Philippe.

C.

Re: Is the ppc440 "bamboo" board in QEMU still of any use?

[Thomas Huth]

On 14/10/2021 17.58, Mark Cave-Ayland wrote:
> On 14/10/2021 16:37, Thomas Huth wrote:
> 
>> On 14/10/2021 17.26, Philippe Mathieu-Daudé wrote:
>>> On 10/14/21 13:29, Cédric Le Goater wrote:
>>>> On 10/14/21 12:34, Christophe Leroy wrote:
>>>
>>>>> I have the following change in QEMU to be able to run the bamboo,
>>>>> found it some time ago via google (can't remember where):
>>>>>
>>>>> diff --git a/hw/ppc/ppc4xx_pci.c b/hw/ppc/ppc4xx_pci.c
>>>>> index 8147ba6f94..600e89e791 100644
>>>>> --- a/hw/ppc/ppc4xx_pci.c
>>>>> +++ b/hw/ppc/ppc4xx_pci.c
>>>>> @@ -246,7 +246,7 @@ static int ppc4xx_pci_map_irq(PCIDevice *pci_dev,
>>>>> int irq_num)
>>>>>
>>>>>        trace_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot);
>>>>>
>>>>> -    return slot - 1;
>>>>> +    return slot ? slot - 1 : slot;
>>>>>    }
>>>>>
>>>>>    static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level)
>>>>
>>>> could you try to use :
>>>>
>>>> static inline int ppce500_pci_map_irq_slot(int devno, int irq_num)
>>>> {
>>>>      return (devno + irq_num) % 4;
>>>> }
>>>
>>> Is this pci_swizzle()?
>>
>> It's pci_swizzle, but I don't think that we should take irq_num into 
>> account here. The comment right in front of the function says:
>>
>>   On Bamboo, all pins from each slot are tied to a single board IRQ
>>
>> Similar comment in pc-bios/bamboo.dts:
>>
>>   Bamboo has all 4 IRQ pins tied together per slot
>>
>> So the return value should only depend on the slot number.
>>
>> Not sure how to properly fix this yet, though.
>>
>>   Thomas
>>
>>
>> PS: Found a working pre-compiled kernel for bamboo:
>> http://landley.net/aboriginal/downloads/binaries/system-image-powerpc-440fp.tar.gz 
>>
> 
> Hi Thomas,
> 
> Did you see my reply from earlier today? Last time I checked the backtrace 
> from the assert() it was coming via pci_update_irq_disabled() although 
> that's not to say that something else could have changed since the original 
> thread.

Yes, I saw it ... it's just that I'm still in process of digesting the 
problem here .... I'll reply to that mail later, when I feel more confident 
with the topic...

  Thomas

Re: Is the ppc440 "bamboo" board in QEMU still of any use?

[Thomas Huth]

On 14/10/2021 13.44, Mark Cave-Ayland wrote:
> On 14/10/2021 11:47, Christophe Leroy wrote:
> 
>> Le 14/10/2021 à 12:34, Christophe Leroy a écrit :
>>>
>>>
>>> Le 14/10/2021 à 11:31, Thomas Huth a écrit :
>>>>
>>>>   Hi,
>>>>
>>>> I tried to build a current Linux kernel for the "bamboo" board and use 
>>>> it in QEMU, but QEMU then quickly aborts with:
>>>>
>>>>   pci.c:262: pci_bus_change_irq_level: Assertion `irq_num >= 0' failed.
>>>>
>>>> (or with a "DCR write error" if I try to use the cuImage instead).
>>>>
>>>> I googled a little bit and found this discussion:
>>>>
>>>> https://qemu-devel.nongnu.narkive.com/vYHona3u/emulating-powerpc-440ep-with-qemu-system-ppcemb#post2 
>>>>
>>>>
>>>> Seems like this board was used for KVM on the PPC440 only, and has never 
>>>> been enabled with the TCG emulation?
>>>>
>>>> Well, KVM support on the 440 has been removed years ago already:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2677b8dd8de0dc1496ede4da09b9dfd59f15cea 
>>>>
>>>>
>>>> So is this "bamboo" board dead code in QEMU now? Or does anybody still 
>>>> have a kernel binary which could be used for testing it? Note: This 
>>>> board does not support "-bios", so u-boot or other firmwares are 
>>>> certainly also not an option here...
>>>> Should we mark "bamboo" as deprecated nowadays?
>>>>
>>>
>>> I have the following change in QEMU to be able to run the bamboo, found 
>>> it some time ago via google (can't remember where):
>>>
>>> diff --git a/hw/ppc/ppc4xx_pci.c b/hw/ppc/ppc4xx_pci.c
>>> index 8147ba6f94..600e89e791 100644
>>> --- a/hw/ppc/ppc4xx_pci.c
>>> +++ b/hw/ppc/ppc4xx_pci.c
>>> @@ -246,7 +246,7 @@ static int ppc4xx_pci_map_irq(PCIDevice *pci_dev, int 
>>> irq_num)
>>>
>>>       trace_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot);
>>>
>>> -    return slot - 1;
>>> +    return slot ? slot - 1 : slot;
>>>   }
>>>
>>>   static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level)
>>> ---
>>>
>>> It's probably no the final change, but at least it allows booting bamboo 
>>> on qemu again.
>>>
>>
>> Found the source : 
>> https://www.mail-archive.com/qemu-devel@nongnu.org/msg769121.html
> 
> Ah yes, that thread rings a bell. I think the important part was in my 
> initial reply at 
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg769115.html: in other 
> words ppc4xx_pci_map_irq() function expects the IRQ number to range from 1 
> to 4.
> 
> When I looked at this the issue was caused by the guest writing to PCI 
> configuration space to disable PCI interrupts: this ends up calling 
> pci_update_irq_disabled() as below:
> 
> /* Called after interrupt disabled field update in config space,
>   * assert/deassert interrupts if necessary.
>   * Gets original interrupt disable bit value (before update). */
> static void pci_update_irq_disabled(PCIDevice *d, int was_irq_disabled)
> {
>      int i, disabled = pci_irq_disabled(d);
>      if (disabled == was_irq_disabled)
>          return;
>      for (i = 0; i < PCI_NUM_PINS; ++i) {
>          int state = pci_irq_state(d, i);
>          pci_change_irq_level(d, i, disabled ? -state : state);
>      }
> }
> 
> Since the IRQ is disabled pci_change_irq_level() ends up being called with 
> -1 which triggers the assert().

I think you likely mixed up the paramters here. The -1 is the "change" 
parameter, but the critical value that is tested in the assert() statement 
later is the irq_num variable which comes from the map_irq() function.

Now looking at ppc4xx_pci_map_irq(), I think the code is basically correct 
for the PCI slots 1 to 4. You can verify that with the image from

 
http://landley.net/aboriginal/downloads/binaries/system-image-powerpc-440fp.tar.gz

and by starting QEMU e.g. with:

qemu-system-ppc64  -kernel linux -initrd rootfs.cpio.gz \
   -M bamboo -device e1000  -device e1000 -device e1000 \
   -netdev user,id=u1 -device rtl8139,netdev=u1

You can see the 8139 card with "lspci" in the last slot, and a "ping 
10.0.2.2" only works if the map_irq function returns "slot - 1" in this case 
(otherwise it even crashes after a while).

Now back to the original problem: This seems to occur indeed since recent 
self-compiled Linux kernels also try to mess with the pci host bridge device 
in slot 0. So the question is only, which interrupt number should the 
map_irq() function return in case it has been called with the PCI host 
bridge device in slot 0?

Both hacks with "return slot ? slot - 1 : 0;" and "return (slot - 1) & 3" 
seem to work, as far as I can tell, and I think the IRQ for the host bridge 
is then ignored anyway, so maybe we should simply add one of the two and 
call it a day?

  Thomas