Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (balaton)

Bottom

« 1 2 (3) 4 5 6 ... 28 »

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/19 17:55 #41

Quite a regular

@geennaam
You aren't posting enough details to be able to guess what might still be some issues but it seems to be at least a step forward that it works now. To improve it we'd need more details and testing and debugging. Also it may help others who want to reproduce and furhter test this if you posted your QEMU command and host side setup needed for this. (Maybe go back to the old thread or open a new one for this topic.)
Quote:

- Radeon9250 refused to work properly.
- HD4850 resulted in a guru during opening of WB.

No idea but maybe rhese things would need to be fixed in QEMU for these cards: qemu/hw/vfio/pci-quirks.c (and there's another one further down below in the same file). Basically as far as I understand old cards with 32bit BARs had their registers in BAR1 but BAR0+BAR1 is needed for 64bit VRAM BAR so in newer cards the registers are moved to BAR4. QEMU does not try to detect the card just assumes BAR4 so it won't work with older cards unless somebody fixes those functions for older cards.
For the guru, we don't know unless you get and post a crash report at least.
Quote:

- RX560 still give me the following error and then nothing:
qemu-system-ppc: ../hw/pci/pcie.c:991: pcie_find_capability_list: Assertion `next <= PCIE_CONFIG_SPACE_SIZE - 8' failed. Aborted (core dumped)

No idea what this is either but maybe it would need PCIe extended config space that's not visible in PCI? Currently the PCIe ports of sam460ex aren't emulated (mainly because I don't have any docs on them) so you can only pass through cards as PCI. I've tried to emulate PCIe on sam460ex but haven't finished it yet. Maybe for QEMU 9.1 or later.
You could get a more detailed trace on where this error is coming from by running qemu-system-ppc under gdb (add gdb --args before your qemu command) and get a backtrace when it hits the assert. Maybe 'bt full' which also lists the function parameters rather than just the calls.

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/18 22:09 #42

Quite a regular

@geennaam
Quote:

So without further diagnostics, you at least know that nothing changed for vfio with the irq fix.

For these cards at least. But if I remember correctly there were other cards which worked with PCI pass through but had to disable IRQ to avoid problems. For those cards the IRQ fix might help.

I wouldn't know what's the problem with these cards that you've tried but do these work with a real PegasosII? I've heard from @joerg that amigaone was better for using such cards but they did not work with Pegasos. So if you have amigone version of AmigaOS you might try that with vfio. Also it might need the board firmware to run the card's BIOS so you may try running BBoot from pegasos2.rom (see README in BBoot, instead of -kernel bboot copy Kickstart.zip, bboot and bboot.fth to your boot volume and use boot hd:0 bboot.fth with -bios pegasos2.rom) or use U-Boot with amigaone. BBoot will just truncate 64bit BARs and fix IRQ controller setup on pegasos2 but won't try to set up gfx cards instead of the firmware or OS (that would need a BIOS emulator in BBoot).

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/15 0:28 #43

Quite a regular

@all
I've uploaded BBoot 0.7 (see https://qmiga.codeberg.page/) that might fix this even on real pegasos2 or when using passed through GPU on Linux host. Please test and let me know of any problems found.

Topic | Forum

balaton

Re: MPlayer 1.5 released!

Posted on: 4/15 0:24 #44

Quite a regular

Interestingly I don't get 403 and can wget the m3u8 but trying to play the URL with mplayer on x86 Linux results in the exact same error message that Maijestro posted above so I think it's not related to AmigaOS.

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/13 20:03 #45

Quite a regular

@Hans
What should ELCR be set on pegasos2 or how did you fix it in AmigaOS kernel so I can do the same in BBoot so it would work with current kernels until an updated one is avaiable (which might take long due to burocracy or legal issues so maybe until then a fix in BBoot could help but then it should do the same as the updated kernel will do).

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/13 19:58 #46

Quite a regular

@joerg
I've added some logging to elcr and did some tests. The amigaone firmware writes some values there then the amigaone kernel replaces them with mostly the same values on its own so it should also work without BBoot doing anything with that. On pegasos2 the firmware also writes some values but it only inits the first PIC for interrupts that the firmware itself uses and sets elcr of second pic to 0. The AmigaOS kernel on pegasos2 does not write elcr unlike on amigaone so it will use the values set by firmware which is wrong. Sounds like a pegasos2 kernel bug to me as this won't work with real machine either.

I could set values from BBoot but on amigaone it will be replaced by AmigaOS so does not matter and on pegasos2 writing the same value as the firmware does not work and writing other values from amigone does not match real machine. I may still try to do it for pegasos2 in a later BBoot release just to avoid some problems with older kernels and maybe this could also be useful on real machine before an update with the fix comes out but the problem still seems to be unrelated to BBoot or QEMU on pegasos2 and likely also broken on real machine.

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/13 19:01 #47

Quite a regular

@joerg
Quote:

for example https://github.com/torvalds/linux/blob ... r/arch/x86/kernel/i8259.c doesn't seem to mess around with ELCR in it's init function either. It just saves/restores it when required in other parts. Probably means even Linux uses the firmware/BIOS configured settings for it.

I can't tell if Linux doesn't do that elsewhere or it does not need to because it can handle shared edge triggered interrupts (probably the latter) but this also does not matter for AmigaOS on an uncommon PPC board what does Linux do on x86.

Quote:

In the 8259 docs I found writing 0x11 is called "initializing the PIC", but doesn't mention that that does a complete HW reset of it clearing/setting to default values all registers of it.
Therefore it shouldn't matter at all what the AmigaOS kernel does with LTIM as long as the firmware has set up ELCR correctly

The docs also say that after 0x11 you have to write a few init values which contain the LTIM bit so it will reset that and neither amigaone/pegasos2 firmware nor AmigaOS on those systems set the LTIM bit. I don't know about ELCR as I don't know how to trace that but the U-Boot sources we have don't have anything that would set it. Maybe it could be verified with info pic or printing the value from QEMU. But I'm not even sure if ELCR is supported on real VIA chips, I could not find it mentioned in the VIA chip docs so maybe that's why MorphOS uses the LTIM bit instead.

Quote:

using your BBoot as firmware replacement obviously doesn't.
Maybe U-Boot and CFE (unlikely) or SmartFirmware (more likely) don't configure it correctly to level, as required by AmigaOS, either, but that's no excuse for doing it wrong/not at all in BBoot.

Well I think that's a good excuse because if BBoot aims to replace the firmware then it should do the same as the firmware. If those firmwares don't set this then BBoot does not have to either. Since AmigaOS overwrites at least the LTIM bit and we have no evidence that ELCR is used or works on real hardware I think this should be set up by the AmigaOS kernel the way it likes, which Hans seems to also found and tried and said it works so then it's solved. I can try to patch things up in BBoot, like I do for 64 bit BARs for AmigaOS but probably it's better to fix things where they are best handled. I'll see if an update with a fix will be available before I try to patch things in BBoot.

Quote:

Yes, but the bug using edge instead of level triggered interrupts has to cause additional problems with it, as well as with any other hardware driver.

That's another unrelated issue and it's fixed as above also for RTL8139. It's possible that there are still further unrelated problems somewhere in QEMU netwrok handling, libslirp or macOS or wherever else but we need to debug them and solve them one by one not mixing everything because then we just get confused. We identified two issues so far and working on fixing those. If there are more they will be fixed too eventually once we understand what are those issues.

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/13 13:59 #48

Quite a regular

@joerg
Quote:

incomplete hardware initialization may be the reason for other problems as well, for example the RTL8139 driver not working.

That was debugged to be caused by some values not appearing in emulation the same way as on real hardware which the driver could not handle so nothing to do with hardware init or firmware. The emulation was also checked by the driver author and he said it confirms to the documentation so it's not clear where to fix it but there should be a way to fix it eventually either by making the driver to work with QEMU or make QEMU work more like real hardware. But I'm not the best person to do that as I don't have the driver sources and don't know how real hardware works so the driver author may know better.

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/13 13:52 #49

Quite a regular

@Hans
Quote:

The ELCR offsets are 0x4d0, and 0x4d1. The OS is *NOT* writing to them.

That's ISA IO port which may be memory mapped on PPC but the VIA docs don't mention it so I'm not sure it's supported. Maybe the only way for VIA is the LTIM bit then which MorphOS sets so it should be OK for AmigaOS to use that as well.

Quote:

I've already experimented with it, and enabling level triggered interrupts for PCI interrupts solves the problem where interrupts suddenly stop coming in.

OK so looks like this problem is solved then.

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/13 13:50 #50

Quite a regular

@joerg
The first thing AmigaOS kernel does on amigaone is this:


articia_reg_write: Unimplemented register write 0x80 1 <- b0

pic_ioport_write master 1 addr 0x1 val 0xff

pic_ioport_write master 0 addr 0x1 val 0xff

pic_ioport_write master 1 addr 0x0 val 0x11

pic_ioport_write master 1 addr 0x1 val 0x0

pic_ioport_write master 1 addr 0x1 val 0x4

pic_ioport_write master 1 addr 0x1 val 0x1

pic_ioport_write master 0 addr 0x0 val 0x11

pic_ioport_write master 0 addr 0x1 val 0x8

pic_ioport_write master 0 addr 0x1 val 0x2

pic_ioport_write master 0 addr 0x1 val 0x1

pic_ioport_write master 1 addr 0x0 val 0xb

pic_ioport_write master 0 addr 0x0 val 0xb

pic_ioport_write master 1 addr 0x1 val 0xff

pic_ioport_write master 0 addr 0x1 val 0xff

pic_ioport_write master 1 addr 0x1 val 0xfb

pic_ioport_write master 0 addr 0x1 val 0xff

pic_ioport_write master 1 addr 0x1 val 0xfa

pic_ioport_write master 0 addr 0x1 val 0xff

pic_ioport_read master 1 addr 0x1 val 0xfa

pic_ioport_write master 1 addr 0x1 val 0xfb

pic_ioport_write master 1 addr 0x0 val 0xb

pic_ioport_read master 1 addr 0x0 val 0x1

pic_ioport_write master 1 addr 0x0 val 0x60

pic_ioport_write master 1 addr 0x0 val 0xb

pic_ioport_read master 1 addr 0x0 val 0x0

pic_ioport_write master 1 addr 0x1 val 0xfa

pic_ioport_write master 0 addr 0x1 val 0xff

pic_ioport_read master 1 addr 0x0 val 0x0

pic_ioport_read master 1 addr 0x1 val 0xfa

pic_ioport_write master 1 addr 0x1 val 0xfb

pic_ioport_write master 1 addr 0x0 val 0xb

pic_ioport_read master 1 addr 0x0 val 0x1

pic_ioport_write master 1 addr 0x0 val 0x60

pic_ioport_write master 1 addr 0x0 val 0xb

AFAIK 0xff masks out all interrupts then 0x11 resets the PIC at which point it does not matter what the firmware has set as it needs to be reprogrammed which the AmigaOS kernel does. So I'm not convinced it actually works on real machine. It also works fine on QEMU as long as there's no heavy interrupt load, the problem only happens if multiple devices do a lot of interrupts. And on pegasos2 it happens faster because everything is on the same interrupt. I've heard real machines also lock up sometimes so maybe the bug also exists there just happens less freqently as there is no virtio-gpu generating a lot of interrupts. Now thanks to QEMU this could be debugged and fixing it would also make it work better on real machine.

The AmigaOne G3SE U-Boot sources we have upstream (which is not the same as the XE and may also be incomplete for G3SE) does not set PIC to level mode, it only sets the VIA PCI edge/level register to level mode which only affects the PCI interrupt inputs which should already be emulated in QEMU (with the fix that you've called failed attempt) as it implementes the default level mode. But that's not enough even on real hardware if the interrupt is shared with other than PCI devices as on pegasos2. This could be checked by testing the same on the amigaone machine or sam460ex but only Hans can test that and he only tried pegasos2 so far I think.

Interrupts can be shared in either level or edge mode but the OS has to do the right thing. If interrupts are edge triggered the OS has to keep the state itself and note interrupts to be serviced even while it services another one (as edge mode interrupts don't retrigger) or set the hardware to do this tracking by setting level mode then interrupt is kept raised as long as there are still pending devices.

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/13 13:39 #51

Quite a regular

@afxgroup
That's a quite unrelated repo of a fork of some random old U-Boot with unknown changes. Why not look at the upstream U-Boot repo and go back to before the G3SE was removed? I did that before and even tried to build a firmware from that for the amigaone but I've concluded that code upstream is not the same as the U-Boot binary on Hyperion site was built from and does not work so we can't use that as authorative source as the actual amigaone U-Boot may do some other things that were never upstreamed.

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/12 22:12 #52

Quite a regular

@m3x
And where have you found that? Posting only snippets does not help much because it's hard to see how these fit together. If this is from the U-Boot git before it was removed from it I've found that too. But this only programs the VIA south bridge and not the i8259 PIC. There's also i8259_init() which is called from interrupt_init() but I don't see where the latter is called from if at all. The i8259_init() seems to only do basic setup setting the LTIM bit to edge triggered and this is later redone by AmigaOS so probably does not matter as it will be overwritten anyway.

I still don't see how can this work on real machine unless the VIA ISA bridge 0x54 register in level mode means that PCI interrupts will be retriggered to PIC even when the PIC is in edge mode but then there's still a possibility of interrupts from internal chip functions also mapped to IRQ9 to get lost when the PIC is not in level mode so register 0x54 may only fix the PCI interrupts but I'm not even sure about that. I could try to implement that in QEMU but since it likely won't fix all problems and not needed when AmigaOS sets the PIC in level mode I'll leave it for now.

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/12 20:23 #53

Quite a regular

@joerg
The VIA south bridges are quite similar and the ISA PIC is an even older device that works the same way in all implementations as it has to be compatible with the original. But the source of the amigaone U-Boot is not available and nobody knows where is it. I've asked at several places for it but nobody could dig up a source. The only source available is a partial one for G3SE that was once in upstream U-Boot, but that does not include the menu parts. What's there seems to program the PIC to edge mode and have env vars for edge/level for the PCI interrupts (which is probably what the menu sets) and this is only used for setting config reg 0x54 of the ISA bridge. So if this is the same as the actual amigaone U-Boot then I wonder if this 0x54 reg overrides the ISA PIC setting or does it keep track of interrupts separately and retrigger the PIC? This register is not emulated in QEMU because I don't know if it's needed and not sure how it works. It there was some evidence about how it works on real machine I could implement that in QEMU but so far I'm not sure. This register defaults to level trigger so if unset then maybe the PCI interrupts are handled as level triggered before they are routed to the PIC so even with the PIC set to edge mode it would be retriggered by the ISA bridge? But even then that's only true for the PCI IRQ inputs and not the other internal devices that share the same interrupt so it seems to be better and the only correct way to set the PIC to level trigger.

Also if AmigaOS resets the PICs then it probably does not matter what the firmware has set it to and the OS would need to program it correctly.

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/12 13:18 #54

Quite a regular

@Hans
Quote:

The ELCR offsets are 0x4d0, and 0x4d1. The OS is *NOT* writing to them.

Does the firmware write them? If so this may be added to BBoot. (I've traced the firmware in the post you've linked to but I don't understand what those logs mean so I can't tell if there's something done by the firmware that AmigaOS might rely on.)

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/12 12:45 #55

Quite a regular

@Hans
Quote:

The problem is that the first write to each PIC's command register is 0x11. Bit 3 is zero, which puts the PIC in edge triggered mode.

That's the old gobal LTIM bit that wasn't even supported by QEMU until we found MorphOS uses that. All other modern systems use a newer way that can set edge/level per interrupt line. But I don't know where is that and how to program it, I only know about that because of this commit message:
https://patchew.org/QEMU/2023030209062 ... 37-1-dwmw2@infradead.org/
So check those ELCR bits too and maybe that should be used to fix this instead of the LTIM bit, although now both should work in QEMU.

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/11 20:42 #56

Quite a regular

@Georg
That's a vague idea. I wouldn't know what to check in QEMU without knowing what the OS might do to prevent nesting. Also how could that be tested on real hardware? So this would need to be elaborated further to be able to check that.

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/11 20:38 #57

Quite a regular

Yes I have two patches sent recently. I've updated the patch for SFS, new version is here: https://patchew.org/QEMU/2024041119244 ... 644E6026@zero.eik.bme.hu/ which is closer to previous behaviour but other than avoiding some warnings with -d unimp it probably works the same.

The other PIRQ/PINT patch fixes an issue with keeping track of PCI interrupt states. While it did not fix Hans's problem it does fix a bug so that patch is still valid.

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/11 14:36 #58

Quite a regular

@Hans
Quote:

The 8259 has a master and slave, and the slave is mapped through to one of the interrupt lines on the master (IRR = 2, so IRQ 1). The PCI interrupts appear to be routed to the slave (IRR = 2 as well, which is IRQ 9).

Your conclusion is probably right but just to correct the above. There are actually two 8259 PICs in a PC AT (XT had only one) and each can handle 8 interrupt inputs. The master PIC's output is connected to the CPU, the 2nd (slave) PIC's output is connected to INT2 (bit 2, value 4) of the master PIC also called the cascade interrupt that signals there's an interrupt on the slave PIC. Masking out INT2 on master will disable all interrupts >=8. IRQ9 is bit 1, value 2 on the slave so it's not the same bit on both PICs. IRQ1 on master is used by the keyboard.

There are some docs here: https://wiki.osdev.org/PIC and more links at the end of that document which have tables of which bit corresponds to what.

Quote:

So, when a PCI interrupt occurs, then bit 2 should be set on both the master and the slave.

Bit 2 on master, bit 1 on slave (counted starting from 0).

Topic | Forum

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/11 14:17 #59

Quite a regular

@Hans
Quote:

The PIC is programmed in edge-triggered mode

That sounds wrong if you want it to retrigger interrupts that were not yet serviced. I think edge mode will only trigger the interrupt once when the device signals it but does not keep the state, but I could be wrong about that.

I've asked this before but did you try if the problem also reproduces with -bios pegasos2.rom or using -machine sam460ex that does not use ISA PIC? I think either the firmware may set something in PIC that is missing from BBoot or there's something in the PIC emulation not working as AmigaOS expects. If the emulation or the expectation is wrong I can't tell but this ISA PIC model is used by everything in QEMU that has a PIC and all OSes running on those are fine with it so unless it's some obscure feature not normally relied upon the PIC model should be generally OK.

For getting values of registers you could also add debug printfs to QEMU if needed. Other than that I don't know the PIC or its emulation either so can't help much with that.

Topic | Forum

balaton

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 4/10 19:19 #60

Quite a regular

@Maijestro
sii3112 is a SATA card not SCSI (but it really uses the same ATA emulation as via-ata used on amigaone/pegasos2). The sii3112 is used by default on sam460ex and should work, it has nothing to do with the SFS issue.

@smarkusg
I've sent the patch but 9.0-rc3 was tagged just now so it probably missed 9.0 and will only be in 9.0.1. I'd still need the lspci or showconfig output from a real Sam460 as I've asked above to confirm it's the right fix but seems to resolve the problem at least for now. Too bad I got to know about this too late (it was reported before but I forgot) so looks like it could not be fixed for 9.0. (There's still a slim chance for 9.0 if there will be an rc4 but otherwise you'll need to wait until 9.0.1 or 9.1 in August or compile your own QEMU to have this patch.)

Topic | Forum

Top

« 1 2 (3) 4 5 6 ... 28 »