@Hans
Interrupts probably only retrigger if level sensitive is used so is it set correctly in PIC? Does this only happen with BBoot or also with booting from pegasos2.rom? If only with BBoot maybe we're missing some PIC or other init that the firmware does normally.

I've checked the docs and emulation. VIA southbridges function 0 (ISA bridge) config register 0x54 is documented to set PIRQ inputs to edge or level sensitive, default is level sensitive. BBoot sets this for amigaone but not for pegasos2 but this does not matter as this register is not emulated and always set to level sensitive. This is (more or less) implemented in qemu/hw/isa/vt82c686.c::via_isa_set_irq(). It should keep track of interrupt states and keep the interrupt raised as long as there's one source active. But PIRQ pins are kept track together so if a PCI device uses more than one pin (PCI has INTA-INTD) or maybe if more than one device uses the same pin (but the latter should be handled by the PCI emulation so should not be a problem) it might clear PCI interrupts. I wonder if uint16_t mask = BIT(f) calculation should be moved after the switch (f) to keep track of PIRQ pins separately?

After that it goes to the i8259 PIC emulation and I don't know what that does with it and when does it raise the CPU interrupt. That may need to be checked separately but no time for that and without being able to test and reproduce the issue it's hard to check.

Does this patch help at all with this issue?

The call to OS4 that queries the bridge device does not fail but when the PCI bridge is found SFS then checks for the Pericom bridge and that's not there so then returns 0 from the function that checks for bridges but I don't know if that's normal or not, maybe it fails later. Even adding a pericom bridge device does not make it work. It would be simpler for @joerg to check the source than for me to debug a binary only blob.

Could somebody with a real sam460 (any variant may probably do if no EX is available) post the output of lspci or showconfig to see what devices exist on real machine? Maybe the bridge is different on real machine and that's why it fails? I could not find any useful logs on-line so far from real sam460. Also could somebody with real SAM460 confirm which SFS versions work on real machine? (We have 1.277 on Aminet, 1.286 on 4.1Upd1, 1.290 in 4.1Upd5 and later including 4.1FE and 1.293 in Enhancer that I don't have. Could somebody with real sam460 test which of these work and which don't to avoid any issues with that.)

It looks like the function that checks PCI bridges returns 0 and that makes it exit. Even if it finds 1014:27f it goes on trying 12d8:8150 then exits with 0 which the caller treats as an error and closes dos.library and exits (even if I add a dummy 8150 bridge device to sam460ex). At least that's what I think without the source. If you have the source please check this function and tell me what it may be missing on QEMU that it checks additionally to PCI device IDs. It may be some property of the PCI bridge is missing on QEMU that it looks for.

@joerg
OK, I don't have Enhancer but we should aim to fix it for 1.290 that's on the install CD otherwise it would be difficult to install a system. I assume that version should work on real hardware if it comes with the sam460 install CD.
If I enable WaitPkt/ReplyPkt logs in Snoopy I also get the same logs but the ReplyPkt is followed by close(dos.library) on QEMU sam460ex.

Where does SFS version 1.293 come from? The install CD seems to have 1.290 and did not find a new version in updates 1 and 2.
The Aminet 1.277 version also fails on pegasos2 the same way as 1.290 on sam460ex but 1.290 works on pegasos2. I'm still lost about what makes it exit on sam460ex. This happens somewhere after it checked the system type but before opening other libraries.

On pegasos2 where it recognises the same USB driver with SFS I get:

Maybe this gives @joerg or sombody else an idea at what point it could fail so we can check that further.

Edit: SFS version 1.277 from Aminet seems to only search for amigone PCI bridge so it does not seem to have sam specific code but still exits the same as above:

So maybe it has nothing to do with sam specific parts but something in generic code does not behave on emulated PPC440 than on real machine? As there's no crash report or any error given I have no idea how to find where it stops.

Yes, I've also found that on AOS4 one should use Snoopy instead of SnoopDOS I've tried to get some logs of attaching a USB drive with an SFS filesystem on it:

There's a FAIL while trying to open newfilesystem.resource but it still goes a bit further checking PCI bridges and exits somewhere after that. Without knowing what it tries to do it's hard to tell so I hope @joerg can remember something or check it and give some hints otherwise I'd need to do more experimenting. Also I'm not sure what else to enable in Snoopy to get more useful logs.

So when a USB disk with an SFS partition is attached an SFS task is spawned but then it seems to exit. How to trace what it tries to do? Is there an strace equivalent? Something like SnoopDOS but maybe that only traces DOS calls and not what SFS calls at that point. If we can identify where SFS stops maybe we can find what's missing or different on emulated sam460ex which breaks it but I don't know how to do that under AmigaOS.
The kernel logs don't give enough info and using higher log levels generate too many unrelated logs that obscure the SFS task logs.

@white
Maybe find the old thread or make a new one for these AmiCygnix experiments so this thread is kept for Hans's virtio-gpu issue.

@Maijestro
Quote:
I wonder if that's because of AltiVec. Maybe you could also try pegasos2 with -cpu g3 (or one of the suitable 750 variants that SFS or whatever else likes, the difference between them I think is not emulated nor relevant so it just changes the PVR value) for comparison to confirm it's because of missing AltiVec or BookE CPU on sam460ex. In case it's AltiVec, these measurements may be different on x86_64.

Quote:
That's a U-Boot issue, even on real machine but the updated U-Boot that fixes it is not available for download any more from aCube and the version that was used for QEMU is too old to fix this. You could avoid this by only adding the -drive if=none,id=ufat,... part to QEMU command line but not the -device usb-storage,drive=ufat and instead enter 'device_add usb-storage,drive=ufat' in QEMU monitor after boot to hot-plug the USB device so U-Boot does not see it. (I've tested this works while trying to debug SFS.) It's less convenient so maybe just use network share instead.

I have tried to find out why SFS does not work on QEMU sam460ex but since it does not log any error it's hard to see what happens. I've tried booting with debug kernel and logging enabled and it seems that SFS starts. (During startup it seems to look for PCI bridge to determine what system it's running on. It checks Mai Logic Articia S for amigaone, the bridge in 460EX for sam460 and a Pericom bridge that I don't know which system uses.) It seems a task for the volume is added but then after some other tasks are run it just exits for unknown reason. That's all I could find out and don't know how to debug this further. A shortened log excerpt is:

Does anybody know what the above mean and how it could be traced to find out why it stops? This was during boot, maybe I should try attaching a disk with an SFS partition after boot and see if it could be traced better that way but I don't know how to debug these under AmigaOS and don't have suitable setup for that so it's more work than I'm willing to do now.

It does the same when attaching the disk as usb-storage after boot:

so it seems to exit for some reason when trying to detect a volume but it does not tell why. At least the kernel module seems to be loaded and "working" but it cannot handle volumes.

@white
I don't think your problems in AmiCygnix were related to the guest network card type but more likely to port forwarding or other network setup on the host but you can try with -device ne2k_pci instead of -device rtl8139 and see if it works at all (could be it does not work if the driver expects something the QEMU emulation does not support) or try the udpated rtl8139 driver that was mentioned above in case that works better (but if you had no connection at all and not a connection that breaks then it's a different issue than this updated driver fixes).

@Maijestro
Quote:
OK so easy workaround: don't update beyond Update 1 for now when using sam460ex.

Quote:
That sounds like most of this is coming from using SFS on amigaone/pegasos2 and comparing that to sam460ex without SFS.

Quote:
I think you also had the same problem before on pegasos2 with disk cache disabled. So the fix could be either enabling cache for FFS (@joerg mentioned something about that on the other forum) or trying to use the 68k version of SFS that works and then compare that to pegasos2. You're still using disk partition instead of image file for pegasos2 so it could still be a bit faster because of that but I think most of the problems you mentioned could be avoided with using Update 1 and the 68k SFS on sam460ex and get a system that works as good as pegasos2. In case somebody is interested to try that and find out I'd like to hear about the results. At least CPU benchmarks don't show a big difference now in QEMU 9.0 so if it's still slower then that's because of something else. I'd like to find out and make sam460ex work well too because those who have that version should also be able to use it. Considering that the files on the CD of these AmigaOS versions are mostly the same apart from the kernel and modules it does not make much sense to get more of them when you already have one. Unless maybe if you're using it a lot or need different versions for testing but for normal usage any of amigaone/pegasos2 or sam460ex should be sufficient. But looks like for sam460ex there are still some more bugs to fix.

Quote:
I don't remember this USB issue either. I should look at that but considering that sam460ex uses usb keyboard and mouse by default I think USB should work. What's the issue you're referring to? Maybe it's just that there aren't enough ports emulated so you'd also need to add another USB card to add more devices. The real machine has an on-board hub but that's not emulated because the hub in QEMU did not support the needed USB version if I remember correctly.

I hoped sam640ex will really be much more usable with QEMU 9.0 so I'd like to find a way to make it work instead of just telling people not to use it.

@joerg
Quote:
So does this driver on the install CD also support 8029? QEMU also emulates that as -device ne2k_pci so maybe that can also be tested then as an alternative to fix the problem with previous driver versions. As the driver is named rtl8139 I did not know it also supported other similar chips as well so I've never tried.

@Maijestro
Quote:
OK I forgot about that. This affects only the SFS version on the install CD but we still don't know why is that if it works on real machine. But an easy workaround is to replace it with another version that works, either from Enhancer Software or OS4Depot should work.

Quote:
You've surely told me about this before but I've forgotten. What's the issue with Update 2? If Update 1 still works then maybe stay at that version for now on sam460ex until it's debugged.

Quote:
Since @nox already has a real sam460ex with the corresponding version and experience installing it it's probably simplest to try that first and see how well it works emulated. An amigaone/pegasos2 version would not be that much faster, maybe just a little bit so I don't think it's worth the investment to get another version just to try it. If you start without any versiono then it's better to go with the amigaone or pegasos2 but if somebody already has sam460ex version that's also supposed to work so I'd say try that first and get other versions later when using the emulation more.

Quote:
I guess you've said the same just less detailed.

Quote:
What's the issue with SDL1/2 on sam460ex?

@joerg
Quote:
I meant the general case as most AmigaOS software probably don't support AltiVec and for those there's probably not much difference with QEMU 9.0. With older QEMU versions sam460ex was slower but this should be improved with 9.0. Of course 460EX does not have AltiVec so if you want to use that you need a machine with G4 and corresponding AmigaOS version but it would need to be tested if that helps on QEMU or not. I think the limited FPU performance also holds back most AltiVec code so maybe it's not that much faster on QEMU at the moment but did not do profiling to find that out.

@noXLar
The Classic iso won't work with QEMU (it should work with UAE that emulates classic machine but needs QEMU plugin for PPC) but the sam460 version runs with QEMU's sam460ex machine. Make sure to use the latest 9.0-rc1 or rc2 for now (final 9.0 will be released in about 2 weeks) for sam460ex as 9.0 should be much faster for sam460ex than previous QEMU versions. With QEMU 9.0 there's probably not that much difference between pegasos2/amigaone and sam460ex versions any more so if you already have that no need to get another one. The sam460ex version is also easier to install as the firmware is included with QEMU and the SM502 driver is on the iso so it should just boot without any fiddling that's needed to get the pegasos2/amigaone versions running and it's closest to real machine in installation. Pegasos2/amigaone might still run a bit faster but with QEMU 9.0 it's probably not that big difference any more as the biggest issue was solved that made sam460ex emulation slower.

@Hans
I've re-read your first post and you wrote that you've set your handler to highest priority so it was basically do the logging I was suggesting but found you got no interrupts even as first handler. Then checked the PPC manual to see what could disable interrupts and found there's an MSR[EE] bit that can mask it out. There's also a comment in the manual:
Quote:
I don't quite get what does that mean but maybe when the CPU calls an exception handler it disables further interrupts and something needs to enable it. Don't know if rfi does that or needs to be done explicitly but you could check that this bit is not masking out interrupts and where it would need to be enabled/disabled. I don't think emulation is completely broken, it's more likely something in AmigaOS does something that leaves the system in an unexpected state. The CPU register values can be checked in QEMU monitor with 'info registers' any time.

@sailor
Quote:
No idea, probably none of them.
Quote:
The GPL says that whoever distributes binaries of GPL code should also accompany it with the source or at least an address where you can get the source. So contact whover sent you the board that contains the U-Boot binary and they should sort it out otherwise they would illegally distribute binaries they are not allowed to so they should stop doing that and play by the rules.

@Hans
Quote:
Maybe nobody does as it's quite big. But usually it's only needed to know the parts you care about. Interrupts in QEMU are just callback functions that get called. At the bottom the device emulation sets the interrupt which calls in the interrupt controller model (in this case qemu/hw/intc/i8259.c) that then eventually calls the CPU model's interrupt handler. On pegasos2 the i8259 PICs are embedded in the VIA VI8231 (modelled in qemu/hw/isa/vt82c686.c) where the PCI interrupts are also connected. The VT8231 has an output interrupt pin which is connected to a GPIO pin of the MV64361 north bridge and the interrupt output of the MV64361 is connected to the CPU interrupt input. The PCI IRQs are also connected to the MV64361 separately, so the guest could either program the PIC in the south bridge or the MV64361 to get CPU interrupt for PCI IRQs but most guests seem to use the PIC only. On amigaone this is simpler as the interrupt output of the VT82C686B is connected to the the CPU interrupt directly without going through the north bridge (I don't know if that's how the real machine does but since I don't have much info on the ArticiaS this was the simplest way to make it work). But the PIC emulation and the south bridge emulation is shared between amigaone and pegasos2 so they should behave the same. The sam460ex uses different CPU and interrupt controller model so testing that may get different results.

Quote:
On pegasos2 everything is configured to use IRQ9 so all interrupts from via-ac97, USB, and PCI cards will raise that. As this makes it quite frequent it's more likely some race condition will happen and since all drivers are on this single IRQ chain if one of them screws up then all other handlers may be affected. The problem may be there on amigaone too but since these are mapped to different interrupts they may not happen that frequently. I think adding a logging handler to the chain in AmigaOS might be the best way to debug it. You could even move that handler around to find the driver which stops.
Quote:
These are documented in the i8259 PIC docs. Interrupt Mask Register and Interrupt Service Register. AFAIU interrupts with 1 bit in IMR are masked out, and 1 in IRR means the interrupt is raised. If the OS gets an interrupt it should check the PIC to know which IRQ it is then check each device configured to use that IRQ to know which one wants attention.
Quote:
AFAIK the Edge/Level trigger is set by the ELCR register (or the LTIM bit in some global control register but AmigaOS does not touch that).

I've tried running with -bios pegasos2.rom -trace enable="pic_io*" and see what the PICs are set using the info pic command in the monitor. All PIC regs start out as 0, then pegasos2.rom does some setup:

and at the smartfirmware OK prompt:

after AmigaOS starts it programs the PIC on its own:

then this repeats a lot as the IDE for the CD and maybe timer or other sources generate interrupts, at some random point later I get
Don't know if it's any help but just to show how to debug this in QEMU and how you can check the PIC state and interrupts. I think it would be easier to debug it from the AmigaOS side as I think if you get an exception for the interrupts then the problem is not in emulation but in the handlers on the AmigaOS side.