@joerg
IVORs are a BookE thing so only valid for sam460ex but not applicable for pegasso2, there are probably similar fixed exceptions for some of these (or they work differently on BookS PPC is closer to).

For the performance monitor features I haven't checked but maybe QEMU does not emulate these and some of them might not even be possible such as cycle count given that QEMU is not cycle exact and even getting number of executed instructions may be difficult considering that QEMU JITs guest code into TCG opcodes which it compiles to host code then runs it possibly from cache so it may be difficult to correlate code that's run to guest instructions so I would not be surprised if these are missing and may not even be possible to implement.

If profiling can work with just a timer and the problem is that this timer interrupt is not raised that may be fixable but if it needs full performance monitoring support in CPU that may only work with KVM on PPC host not under emulated PPC. All this is still just guessing so any of the above could be wrong but looks likely.

@white
OK so then they already know about the problem and hopefully will be fixed eventually. Until then either use 8.1 or QEMU master from git if you want to test latest changes. Amigaone is only in my qmiga repo for now.

@Maijestro
Yes I know all this takes time, that's why I'd like more people to add in some time otherwise it will take forever for me alone.

In the little free time I had I've tried compiling a U-Boot from source for amigaone which would be needed to be able to submit the patches for inclusion in QEMU. I found that old U-Boot versions don't compile with newer gcc any more and newer U-Boot versions dropped the AmigaOneG3SE board. I could add back this board in the sam460ex 2010.06.05 U-Boot version and compile that and it starts but crashes within the BIOS emulator even if I use the same bios emulator that works with the sam460ex U-Boot. So something is still wrong in either the board support code, bios emulator glue code or in CPU support for 74xx CPUs. Also the sources for the AmigaOne board seem to be missing parts and the binary U-Boot says Board: AmigaOne while the one in upstream U-Boot says Board: AmigaOneG3SE so I think what's upstream is not the complete source for the AmigaOne binary U-Boot we're using and I could not reconstruct it.

That's where I'm stuck now in upstreaming amigaone patches. I've written to some people asking for the U-Boot source but hot no reply so far so if somebody has a source that at some point should have worked please pass it to me. (I have all the U-Boot versions in git so don't need any of those but actual AmigaOne U-Boot source corresponding to the binary on Hyperion's site that should have been available on asking in the 3 years it was released. Somebody should have asked and saved it I hope. If I can't get this I'd need to emulate U-Boot as well which is more work I'd like to avoid.

@joerg
I think timebase should work as that's widely used, the debug interrupt may more likely have some issues. Once that's confirmed to be used here somebody could read the CPU docs to understand how this is supposed to work then write a test case to check or check the code in qemu/target/ppc/ to see if it's emulated correctly (as that code emulates all CPUs it may be hard to find without detailed knowledge).

@white
Go to qenu.org and read there. You can either send an email to qemu-devel@nongnu.org and cc Marc-Amdre who was in the patch signed-off-by as he wrote the series that now asserts or you can create a ticket in QEMU's bug tracker on gitlab (I've never used that and won't get notified about bugs entered there but maybe some people check there so for this issue that should also work).

@white
Report the problem to QEMU otherwise it will never be fixed.
Also what about -display sdl -vga none -device sm501 Does that give error to? Then without -vga none just using -device sm501 ? Maybe it's because we don't have default vga that's causing a problem but I don't get that with QEMU master and -vga none -device sm501 so maybe 8.1.1 is missing some patch that's in master. The QEMU people who broke this should know better so just let them know.

@afxgroup
I still don't know what hardware interrupt would IPM->SetInterruptVector(1, &CounterInt); hook into. You could check in info irq if that interrupt happens but that lists hardware interrupt numbers so first we would need to know what hardware interrupt this means then we can check if that's generated.

@afxgroup
Which interrupt? Where can you see it's not called? From the QEMU side you can enable either -d int which logs every CPU interrupt that will be a flood of logs so probably won't be able to find anything in it unless you know what to look for or -trace enable="pic*" to get logs about the ISA PICs or there are "info irq" and "info pic" commands in QEMU Monitor to get some info but one would need to know again what to look for for these to be useful.

@Maijestro
As the interrupt handling is slightly different between amigaone and pegasos2 I suspected it's some problem there but without more details I can't find it. Now testng with Volker seems to confirm this but it's still not sure if this is because something is not emulated correctly or roo frequent interrupts are just too slow in emulation. If it's just slow maybe increasing the buffer size in AHI could avoid this as that should make the interrupts less frequent but I don't know how to set that and have no time to experiment with it.

Maybe it helps if I write down what I know which is what I've written. The VIA chip has two embedded ISA PICs, these are created in hw/isa/vt82686.c::via_isa_realize() calling i8259_init() and just use the existing QEMU ISA PIC emulation that should generally work as all other machines using ISA PIC use this although we had to add some legacy mode which nothing else used but AmigaOS so there may be some corner cases but it's less likely. This emulation is used by both amigaone and pegasos2. The PCI interrupts are also connected to VIA chip and this may not be emulated in all detail but should work as long as everything is mapped to a single interrupt as it is in pegasso2 and amigaone apparently. This was discussed in the email thread on qemu list I've linked in the other thread when discussing passed through GPU interrupts and the patches in the pegasos2 branch of the qmiga repo tried to solve but testing with those patches made no difference so maybe this isn't the problem either but could be if something in AmigaOS relies on something that happens differently on real hardware. The ISA and PCI interrupts should raise the cpu_intr of the VIA chip which is connected to the PPC CPU external interrupt in hw/ppc/amigaone.c (the pegasos2 routes this through the MV64361 GPP input so it's a bit more complex there). Then acknowledging the interrupts can either be done writing PIC registers or using a virtual acknowledge register of the north bridge which seems to be used in AmigaOS, this is emulated in hw/pci-host/articia.c for amigaone and hw/pci-host/mv64361.c for pegasos2.

That's all I did and don't know if any of these could be wrong or something missing. For that I'd need some advice from somebody who actually knows how these machines work and how AmigaOS uses these. We apparently have some problem with interrupts which is causeing problems on amigaone and likely also the netowork freeze issue on pegasos2 but I don'w know what to fix or even what to check without some help so I'm not working on this just wait for somebody to find out what the problem is so we can then think about how to fix it. The hard part is identifying the problem, once it's understood, implementing a fix is usually simple.

@afxgroup
Quote:
First of all, does the same work on real pegasos2? Just to rule out the possibility that this is a problem with AmigaOS or gprof in general and indeed related to emulation. If it works on real machine then how does it work? What processor features it relies on to collect the profiling info? Once you know that you can check if those are emulated correctly. Searching for similar problem found a bug that says this can happen when some timer interrupts are not happening but I don't know how to check that and which timer would it be. Or it could also rely on some debugging feature of the CPU that's not emulated. Maybe trying with -cpu G3 could be useful as older CPUs probably had less exotic features so higher chance they are working better.

@Maijestro
This may depend on the trace backend you compiled QEMU with. I usually use --enable-trace-backends=log which just logs to the stdout/stderr and can be redirected from there but Volker preferred simpletrace that writes a binary file and needs to be processed with a python script to get the logs instead. I don't know what you did but seems to be solved anyway.

I can't debug QEMU audio stuff so whatever is useful for Volker. If need some help from me you can cc me on emails but probably can't help much as I don't know how these things work. I've just implemented the emulation of the sound part following the chip datasheet then the rest is done by QEMU and AmigaOS so don't know what those parts are doing so if the problem comes from those parts we need an expert on those to find it.

@white
I can't reproduce the same with SDL ui backend so try with -display sdl. This assert was added recently in commit
https://gitlab.com/qemu-project/qemu/- ... 5c8817fb18fb25650507b69f8
Report to qemu-devel list also cc-ing the patch author in Signed-off-by in the commit message or in QEMU bug tracker.

@joerg
Interesting, but probably not practically useful. The -hda option is best avoided in favour of -drive which won't have this problem and only a bit more complex to use. The -cdrom is similar but that's OK as CDs aren't writable but in case anybody is wondering the equivalent to -cdrom would be -drive media=cdrom,format=raw,file=path I think, the difference is that -cdrom always adds ide-cd device as secondary master while -drive may pick something else, I don't know how it works internally. I think -drive media=disk or cdrom also works for scsi disks with if=scsi maybe but I'm also not sure about that. Then it would add scsi-hd or scsi-cd but you'd need a scsi controller for that. One of the emulated ones may work if changing device ID but that's only interesting if you need more than 4 HD/CD that the VIA IDE can handle. Or on sam460ex where there's only two sata ports emulated with sii3112.

Having both MBR and RDB seems to be very fragile, maybe a more useful way to use it would be having a protective MBR as used by GPT which adds one partition covering the whole disk in MBR so OSes that only know about MBR won't break the GPT partitions. The same could be done for RDB disks so Windows would not break it maybe when connecting a HDD to that but don't know if that's a real problem.

@white
Your problem isn't pulseaudio but that you're running QEMU as root. Why not run it under your user and then you should not have to change pulseaudio? To access the disk partition from your user change its owner or access rights first as root so your user can access it then you don't have to run QEMU as root. If you want to automate this you'd have to create an udev rule (likely in /etc/udev/rules.d) to change the owner/file mode or add an ACL when the device is connected. You'd have to look up the udev docs and find out how to do this but it's the common way on Linux. It does not matter which distro you use. The difference is mostly in the package manager and maybe some settings are different but any distro largely works the same.

I can't comment on the pulseaudio docs you've quoted but the second one talks about output to multiple devices so that's definitely not applicable, the fisrt may be but not needed. I think also pulsaudio is mostly not needed either, I removed it from my system completely and use alsa but it may not be esasy to remove (I had to recompile some packages to get rid of dependencies). If using alsa QEMU audiodev then some options are needed to avoid broken sound that are noted on my qmiga.osdn.io page in the pegasos2 guide at known problems). But all this is not needed if you don't run QEMU as root.

Changing the access mode for the partition to allow access from your user makes it less secure but since AmigaOS does not have security anyway and any task can break your disk in the VM, if you accept that and using AmigaOS and connect to the internet from it, then having a partition writable from your linux user is no bigger problem than that so this is likely acceptable.

@Maijestro
The log is not useful to me but hopefully Volker can find out something from it. I think he said previously that the AHI prefs test sound uses too small buffers so it won't play correctly but other apps do it differently. But maybe not on amigaone, I don't know and only hope Volker is interested enough to find this out. What you could try is getting the same logs with pegasos2 as well where it works and try to compare if any settings are different (apart from memory addresses which would of course be different) but that needs some digging of the AHI sources to find out what the numbers in the debug log actually mean. That's why they aren't useful to me because I don't want to spend time to read the AHI source and find out. Maybe somebody who already knows it could look at it or somebody who interested enough to learn this.

@white
You already figured out the option to use instead of -hda. I think I've explained these before in some post above but basically -hda is only usable if you don't want to write to block 0 (that is set up partitions or RDB on the disk) otherwise you better use more detailed option with -drive. This has two forms, the full form is defining the drive separately and then add it to a device (this is useful for example when adding a scsi disk)

or a shortcut form of the above that will add the device part automatically

for the valid media values check the QEMU docs but I think it can be disk, cdrom, virtio or something like that (or maybe that's if=virtio) and will add hd, cd or virtio-blk device depending on that. This may not always do what you want but for simple machines with 2 IDE channels it usually works.

For using disks and partitions from a VM, consider the reply to @Reth about being careful to only use the disk or partition from either the host or guest at a time, which means that you have to unmount the partition on the host). The device /dev/sda5 is just a file in Unix so who can access it is decided by its file access mode. If you want you user to be able to access it without sudo you could change it's owner or group to your user and change the file mode accordingly just be aware that any process running under your user name then can write to the partition so it's not secure any more. I don't know if there's a better way, maybe QEMU has something like nbd or similar to more securely share disks partitions between machines but I don't know how that works.

The problem with sound is probably that you use pulsaudio which you can access from your user but not as root so QEMU then falls back to the alsa driver but pulsaudio keeps the sound device open so it does not work with alsa then. So you should find out how to make the pulsaudio running under your user usable as root too (or run QEMU as your user as said above then you don't get this problem).

@Reth
Quote:
No. Imagine you have a hard disk somehow connected to two machines (you can't do it with physical HDD but that's whay you do here virtually) and both of them trying to write to it without coordination. Unless you use a special cluster filesystem that can handle that the data on the disk will be corrupted as the two machines don't know about what the other one did so they only modify the filesystem for their own changes and overwrite each other. So never do that. If you pass a partition or disk to the virtual machine you should never access it from the host while the VM is running. (If using a partition from the VM other partitions on the same disk can be used but you have to unmount the partition that you assign to the VM.)

If you want to share disk space between host and guest you need some coordination between the two machines. As no cluster filesystems exist for AmigaOS the only way to do that would be to have either guest or host handle the partition with shared data and the other party access it via some network mount. Or somebody would need to write a driver for 9p protocol which QEMU can use to share a host directory with the guest.

@white
The amigaone branch in the qmiga repo is currently 8.1.0 with the amigaone patches so it should also work for pegasos2 the same as 8.1.0 but additionally has amigaone machine that isn't in upstream QEMU yet.

@MigthyMax
Quote:

I don't know much about virtio devices but it's likely the driver needs to configure the virt queues and let the device know about it before it would receive any data from the device. Here are some links that may have some useful info:

https://www.redhat.com/en/blog/deep-di ... -networking-and-vhost-net
https://www.redhat.com/en/blog/virtque ... tio-ring-how-data-travels
https://marz.utk.edu/my-courses/cosc562/virtio/

and the ultimative documentation is the virtio spec but that's a bit long and may be overwhelming at first but that should be your definitive source of information.

@joerg
Quote:

When using BBoot with -kernel (i.e. without pegasos2.rom so running under QEMU VOF as BBoot could also be used with pegasos2.rom) BBoot will assign addresses to PCI BARs and program the BAR registers accordingly, as seem in the debug output it prints. This is because AmigaOS kernel does not do this unlike Linux or MorphOS which scan PCI devices and assign addresses on their own. So even when booting with BBoot PCI devices should be set up and show up in Ranger. The only part BBoot does not do is to run the BIOS option ROM of the card but this should not be needed for virtio devices. The virtio-net-pci device may have a ROM but that's only to support network booting on pc machine so likley would not work with pegasos2.rom anyway and the device itself should not need any init done by the ROM. The driver should detect and then init the device according to the virtio spec on how virtio-net should work.

Quote:

I'd say the need to run the ROM is the exception for some gfx cards rather than the norm and the reason for that is that these GPU devices might require quite complex and undocumented init procedures that thier ROM implements so that's the easiest way to get them working but this is not normally required for other devices, especially virtual ones that usually don't need any init from the guest other then the driver establishing the communication channels in the shared memory. As for emulated R100 I think that should work even without running any ROM because what the ROM does is setting up card clocks and memory controller (basically booting the hardware on the card) and set up screen timings all of which make no sense in an emulated envirionment where these aren't needed. So this can just be skipped and the driver can start from there and the device can be emulated in the state where ROM would have left it on real machine so this won't be an issue even for ati-vga. The issue for ati-vga now is just not emulating enough of it yet for the driver to be able to use it.

Quote:

I don't know for sure either but I think even if it has BIOS ROM that's only for network boot and should work without that (after all virtio-net is used on all other emulated machines where no BIOS ROMs are used). So no need to use pegasos2.rom or do anything with the BIOS, the driver just needs to set up the device and start communicating via virtqueue. This may need writing some stucts in the device memory (you'd use the virtual base address to access that) then let the device know where it finds the queue (which may need the physical address as the device only knows about phys addesses as it has no idea about CPU's MMU).

@MigthyMax
BBoot should patch 64bit BARs to change their type to 32bit so the pegasos2 AmigaOS kernel recognises it. It should also tell you what it did, just read the debug output:

The meaning of the numbers are explained in the BBoot README and OpenFirmware PCI binding docs. If you use pegasos2.rom then you can still use BBoot with bboot.fth to apply the BAR patches or you can do the same with a Forth script instead. (If you use BBoot with a newer kernel and don't want it to touch the PCI config then you can use "Os V5 Ab" bboot opts string instead of the default "Os V5 Apb" (Apb is Action PCI, Boot so removing p from it will skip that and only boot without patching or printing PCI data)).

You should probably check with Ranger how the AmigaOS kernel sees the BARs of the device and can use info pci and info qtree commands from the QEMU Monitor to see what's their status on the QEMU side.