Interrupts on real pegasos2 on OF after boot

@balaton, Hand and anyone...

I checked all interrupts on pegasos2 board OF via serial link.

Interrupts seems to be ok on OF, not at least all addressed to same irq, what was claimed elsewhere. ok, there is Silicon image card on same as ide, but it is not OF problem and it may changed if moved other slot. Anyway my idea to adjust irq's on OF with forth-script is obsolete. There is not much to adjust.

Here is dump cleared a bit from real peg2 board, if you want to check. Actually comments very welcome. I can post whole dump, if needed. OF settings on boot. Forgot to get firewire though.

Two buses

/pci@80000000
/pci@8C000000

isa@C is behind /pci@80000000



First devices, buses, then devices with irq and explanation.



All devices etc on board.

ok show-devs
/ (chrp)
/openprom
/openprom/client-services
/aliases
/options
/packages
/packages/terminal-emulator
/packages/deblocker
/packages/disk-label
/packages/obp-tftp
/chosen
/memory@0 (memory)
/cpus
/cpus/PowerPC,74x7 (cpu)
/cpus/PowerPC,74x7/l2-cache (l2-cache)
/cpus/PowerPC,74x7/l3-cache (l3-cache)
/rtas
/failsafe (serial)
/ethernet
/ethernet/port1 (network)
/pci@80000000 (pci)
/pci@80000000/host@0
/pci@80000000/firewire@1
/pci@80000000/raid@5
/pci@80000000/isa@C (isa)
/pci@80000000/isa@C/serial@i2F8 (serial)
/pci@80000000/isa@C/8042@i60 ()
/pci@80000000/isa@C/keyboard@i60 (keyboard)
/pci@80000000/isa@C/rtc@i70 (rtc)
/pci@80000000/isa@C/timer@i40 (timer)
/pci@80000000/isa@C/fdc@i3F0 (fdc)
/pci@80000000/isa@C/lpt@i3BC (lpt)
/pci@80000000/ide@C,1 (spi)
/pci@80000000/ide@C,1/disk@0,0 (block)
/pci@80000000/ide@C,1/cdrom@1,0 (block)
/pci@80000000/usb@C,2 (usb)
/pci@80000000/usb@C,3 (usb)
/pci@80000000/other@C,4
/pci@80000000/sound@C,5
/pci@80000000/pci1106,3068@C,6
/pci@80000000/ethernet@D (network)
/pci@C0000000 (pci)
/pci@C0000000/host@0
/pci@C0000000/display@8
/bootconsole (bootconsole)
/pci@80000000 (pci)
/pci@80000000/host@0
/pci@80000000/firewire@1
/pci@80000000/raid@5
/pci@80000000/isa@C (isa)
/pci@80000000/isa@C/serial@i2F8 (serial)
/pci@80000000/isa@C/8042@i60 ()
/pci@80000000/isa@C/keyboard@i60 (keyboard)
/pci@80000000/isa@C/rtc@i70 (rtc)
/pci@80000000/isa@C/timer@i40 (timer)
/pci@80000000/isa@C/fdc@i3F0 (fdc)
/pci@80000000/isa@C/lpt@i3BC (lpt)
/pci@80000000/ide@C,1 (spi)
/pci@80000000/ide@C,1/disk@0,0 (block)
/pci@80000000/ide@C,1/cdrom@1,0 (block)
/pci@80000000/usb@C,2 (usb)
/pci@80000000/usb@C,3 (usb)
/pci@80000000/other@C,4
/pci@80000000/sound@C,5
/pci@80000000/pci1106,3068@C,6
/pci@80000000/ethernet@D (network)
/pci@C0000000 (pci)
/pci@C0000000/host@0
/pci@C0000000/display@8
/bootconsole (bootconsole)
ok



Bus settings pci@8, pci@c, /pci@8/isa@C, /pci@8/host@0 , /pci@C/host@0

.properties /pci@80000000
ok .properties
name "pci"
device_type "pci"
#address-cells 0x3 (3)
#size-cells 0x2 (2)
clock-frequency 0x1FCA055 (33333333)
ranges [0x30 bytes]
[000] 01000000 00000000 00000000 FE000000
[010] 00000000 00010000 02000000 00000000
[020] 80000000 80000000 00000000 40000000

8259-interrupt-acknowledge 0xF1000CB4 (-251654988)
reg 80000000:40000000
pci-bridge-number 0x0 (0)
bus-range 0:1
ok



ok dev /pci@C0000000/
ok .properties
name "pci"
device_type "pci"
#address-cells 0x3 (3)
#size-cells 0x2 (2)
clock-frequency 0x3F940AA (66666666)
ranges [0x30 bytes]
[000] 01000000 00000000 00000000 F8000000
[010] 00000000 00010000 02000000 00000000
[020] C0000000 C0000000 00000000 20000000

reg C0000000:20000000
pci-bridge-number 0x1 (1)
bus-range 0:1
ok



/pci@80000000/isa@C
ok .properties
vendor-id 0x1106 (4358)
device-id 0x8231 (33329)
revision-id 0x10 (16)
class-code 0x60100 (393472)
subsystem-id 0x0 (0)
subsystem-vendor-id 0x0 (0)
.vendor-name "VIA"
.part-number "VT8231"
.description "PCI to ISA Bridge"
.class "Bridge Device"
.subclass "PCI/ISA"
devsel-speed 0x1 (1)
min-grant 0x0 (0)
max-latency 0x0 (0)
name "isa"
reg C:0
compatible [0x6A bytes]
[000] 73610069 046E616D 65000000 60000000
[010] 00000000 00000000 00000000 00000372
[020] 65670073 61006904 6E616D65 00000060
[030] 00000000 00000000 00000000 00000000
[040] 00037265 67007361 0069046E 616D6500
[050] 00006000 00000000 00000000 00000000
[060] 00000000 03726567 0000

device_type "isa"
#address-cells 0x2 (2)
#size-cells 0x1 (1)
ranges
eisa-slots 0x0 (0)
clock-frequency 0x7F2815 (8333333)
slot-names 0x0 (0)
assigned-addresses
ok



/pci@80000000/host@0
ok ls
ok .properties
vendor-id 0x11AB (4523)
device-id 0x6460 (25696)
revision-id 0x3 (3)
class-code 0x60000 (393216)
subsystem-id 0x0 (0)
subsystem-vendor-id 0x0 (0)
.vendor-name "Marvell"
.part-number "MV6436x"
.description "System Controller for PowerPC Processors"
.class "Bridge Device"
.subclass "Host/PCI"
devsel-speed 0x0 (0)
min-grant 0x0 (0)
max-latency 0x0 (0)
name "host"
reg 0:0
assigned-addresses
ok



ok dev /pci@C0000000/host@0
ok pwd
/pci@C0000000/host@0
ok ls
ok .properties
vendor-id 0x11AB (4523)
device-id 0x6460 (25696)
revision-id 0x3 (3)
class-code 0x60000 (393216)
subsystem-id 0x0 (0)
subsystem-vendor-id 0x0 (0)
.vendor-name "Marvell"
.part-number "MV6436x"
.description "System Controller for PowerPC Processors"
.class "Bridge Device"
.subclass "Host/PCI"
devsel-speed 0x1 (1)
66mhz-capable
fast-back-to-back
min-grant 0x0 (0)
max-latency 0x0 (0)
name "host"
reg 0:0
assigned-addresses
ok


Next devices on /pci@80000000


Device / interrupt address / epxlanation

host@0 , Marvell MV6436x System Controller for PowerPC Processors Bridge Device
raid@5 / 0x1 (1) , Silicon image 3114 on pci slot 3
isa@C / no irq / pci to isa bridge (on MV6436x bridge)
ide@C,1 / 0x1 (1) , PCI IDE Controller on VT82C586/596/686
usb@C,2 / 0x4 (4) / USB on VT83C572
usb@C,2 / 0x4 (4) / USB on VT83C572
usb@C,3 / 0x4 (4) / USB on VT83C572
other@C,4 / no irq assigned / VT8235 Power Management Controller, Bridge Device
sound@C,5 / 0x3 (3), VT82C686A/B AC97 Audio Codec
pci1106,3068@C,6 / 0x3 (3), VT82C686/686A/686B AC97 Modem Codec
ethernet@D / 0x1 (1) / Rhine II PCI Fast Ethernet Controller


Next devices behind isa@C (on /pci@80000000)


Device / interrupt address / epxlanation

serial@i2F8 / 0x8 bytes [000] 00000003 00000000
8042@i60 / interrupt-cells 0x2 (2)
keyboard@i60 / [0x8 bytes] [000] 00000001 00000000
rtc@i70 / [0x8 bytes] [000] 00000008 00000000
timer@i40 / no irq on of displayed
lpt@i3BC / [0x8 bytes] [000] 00000007 00000000


Devices behind /pci@C0000000

Device / interrupt address / epxlanation

host@0, Marvell MV6436x System Controller for PowerPC Processors Bridge Device
display@8 / 0x1 (1) / ATI Display Controller

@Mlehto
Quote:
Of these BBoot fixes edge/level interrupts and 64bit BARs, it does not do others as those would need changing the device tree which is not really possible through the OF Client Interface so these would need fixed kernel or patching from OF before BBoot runs.

Quote:
The difference between edge and level triggering is that edge only signals the CPU once when the interrupt happens (on the rising edge of the interrupt line) and if the OS does not notice the interrupt will be lost which can lead to hangs. This could work if the OS keeps track of interrupts and counts how many of them happened and then handles all but in my understanding AmigaOS does not do that and while it handles an interrupt it can miss another of the same interrupt. With level triggering the interrupt is raised as long as there is a device holding the interrupt high so the OS will get another interrupt after handling one if there's another device still needing attention. This is clearly the behaviour that AmigaOS expects but it forgets to set the interrupt controller accordingly. This wasn't a problem on AmigaOne where the firmware set it and isn't a problem on Pegasos for Linux or MorphOS which set it for themselves. Fixed AmigaOS kernel will likely also do that but for the now available kernels BBoot can change the setting in the interrupt controller for this. This is done here, you can check VT8231 manual for the register meanings.
Quote:
In theory yes, with level trigger and same IRQ it should work but as you say there may be issues with some drivers sharing interrupts so in practice it may cause problems. I remember Hans mentioning somewhere on this forum that one of his drivers had problems with interrupt sharing which had to be fixed but that is also likely unreleased so this may still be a problem. Work around is to disable interrupts for graphics card in the monitor file tooltype but that may lead to lower performance. Another way to try to fix it is to map graphics card to other interrupt than other devices.
Quote:
For the rtl8139 the author of that has debugged it on the German os4welt forum (you can look it up there) and posted updated drivers but it wasn't clear if the problem was related to interrupt sharing, more likely some difference between emulated and real card but it wasn't a bug in emulation as that still confirms to the data sheet of the chip.
Quote:
What do you consider fine? The mapping is valid but a difference between AmigaOne and Pegasos is that AmigaOne maps devices to 4 interrupts so it's less likely to get shared interrupts while Pegasos maps all devices to IRQ9 so if there's a problem with sharing you'll likely get that.
Quote:
The OS could change interrupt mapping if it prefers not to share interrupts but AmigaOS doesn't do that and relies on the firmware entirely to set up PCI then it just reads the device tree and uses whatever it finds there. Some drivers init some devices but maybe partially and still rely on firmware to init the card. It's not like Linux where the drivers usually set up the card the way they need it and not rely on firmware to leave them in a working state. (AmigaOS comes from an environment where the firmware was also controlled by the OS developers so they could rely on it while Linux comes from PC where it had to handle all different BIOS varieties plus the level of testing and number of developers are also different so it's understandable why Linux does it better.)
Quote:
Where?
Quote:
I don't think you should downgrade firmware. There's a bit newer firmware version somewhere on MorphOS stroage, link posted somewhere on morph.zone but it does not fix any known problems with QEMU and I always tested with 050404 so that's what I recommended.
Quote:
AmigaOS does not change interrupt configuration. When turning the machine on PCI devices are unconfigured and something needs to do it. The firmware walks the PCI buses and assings BARs and interrupts then puts this info in the device tree where AmigaOS reads from. So on PegasosII it's only the firmware that decides how interrupts are mapped. QEMU without pegasos2.rom emulates the same so you should get consistent results with or without firmware. For testing you could try patching QEMU to assign different interrupts then try if it makes a difference if that's easier than doing it on real machine. You should also consult this documentation on how PCI is handled in OpenFirmware and what needs to be changed. The forth script to map interrupts differently should write the card's config register to set the interrupt then update the device tree to match.
Quote:
Unless amigaboot.of somehow passes the boot partition to the kernel I don't see how can that be different but I did not see amigaboot.of add any additional options so I don't see why you get different results. Are you sure your kickstart zip is the same as the Kickstart dir on your boot partition that amigaboot.of reads?