@billt
Hi,
It's not about this topic but about AmigaOne SE/XE/uA1 U-Boot. Sorry for being off-topic but noticed you here and I think according to this thread:
https://amigaworld.net/modules/newbb/v ... _id=30736&forum=15#630521
you had the U-Boot sources for AmigaOne at least sometimes in the past. Do you still have it somewhere and could you please pass it on? I wrote to Hyperion about it but it seems it was lost and nobody knows where is it now so maybe only the old sources are available. It does not matter if it does not compile or work, I can attempt to fix it but we can't include firmware binaries in QEMU for amigaone unless we can recreate it from source. Including the firmware would remove one step of downloading it separately (it's GPL so can be freely dowloaded and distributed but QEMU only accepts binaries with source; we already have that for sam460ex but not for amigaone as the sources in upstream U-Boot were only partial and for older version).

@kas1e
Some small simplifications:

- In UnSelectIcon() you don't need parenthesis for return, so just:
return ISMACTION_Unselect;
(return is a statement not a function so usually does not need parenthesis around argument).

- Patched_DisplayBeep() still does not check caller as suggested by @msteed in post #19. Don't know if that's needed but may be a bit less likely to break by other tasks also calling this. On the other hand if there are two beeps at the same time, one from WB and one from something else and you suppress the one from other task and beep on the WB call it's still only one beep and for the user it does not matter where it comes from as long as there aren't two beeps. So not checking for the source of call and just supress the next beep as it does now might still work unless there's some big delay between calls.

- You may be able to remove some nested ifs and indentation in Patched_OpenWindowTagList() that could make it more readable by inverting condition and return early instead of having a distant else leg and nested ifs. I.e.:
if (!nw || stricmp(Caller->tc_Node.ln_Name, "Workbench") != 0 || !(nw->Flags & WFLG_WBENCHWINDOW) || (nw->Flags & WFLG_BACKDROP))
return Original_OpenWindowTagList(Self,nw, tagList);

Then the rest of the function does not need to be indented. (Indenting is already off as the if (Caller == NULL ) before it returns the same way so no need to indent what comes after. (There's also and extra space there after NULL but you could also write !Caller if you want to be even shorter.

- strncmp(strPtr+strlen(n->ln_Name)-1, ":", 1) != 0 is just strPtr[strlen(n->ln_Name)-1] != ':', no need to call a function to compare a single character. As you return from here you can also drop the else and deindent what comes after this as that will only run if the if was false and did not return here.

- Writing if ((n = IExec->GetSucc(n)) == NULL) in two lines is more readable so:
n = IExec->GetSucc(n);
if (n == NULL) or (!n)
is more explicit. Using the value of assignment is useful sometimes like in while ((n = succ(n) != NULL) but in this case it's just makes it less readable.

- I'm not sure this which_icon counting is fail safe and can't break if you select a bunch of icons and open them but while that's processing you're quick enough to select another bunch and try to open those as well (or even just remove the selection or change it). Maybe instead of counting icons you'd better save the n value (pointer in the list) and the head of selList and if you're called with the same selList then continue from last n. Or does WB return different selList each time or it will break anyway if selection is cleared and changed inbetween as selList is always the current selection? Saving the selList and checking it did not change seems to be better but I don't quite know how this works so I may be wrong.

@spotUP
Maijestro was faster to reply but yes, you have an error in your command (which we don't know what you used as you've only quoted the error not the command line). Check the docs linked in previous post which has commands to use that should work. If it still does not work after reading docs post your command as well not just the error. But as a guess you can't have two -drive-s with same id and to attach iso you can just use -cdrom or alternatively -drive media=cdrom,format=raw,file=... instead. It you have -drive if=none,id=something then you also need corresponding -device ide-cd or ide-hd with drive referring to which -drive to use. This is only needed for -drive if=none, the -drive media=disk or cdrom shortcuts add ide-cd or ide-hd device automatically.

Some news about QEMU and AmigaOS:

I've moved the project to qmiga.codeberg.page from the osdn.io address because that does not work reliably any more. Please use this address from now on. The wiki articles are also on codeberg.org/qmiga/pages/wiki now.

There is also a new BBoot release to simplify booting AmigaOne version but that needs latest QEMU from git master for now or the 8.2 release that will be out in one or two weeks. More info on using it is here.

@kas1e
Just some coding style comments.

You have in main uint32 sigmask = 0 and then the only usage is IExec->Wait(sigmask|SIGBREAKF_CTRL_C) so it seems to be constant 0 and I think you could just drop it and just do IExec->Wait(SIGBREAKF_CTRL_C) with same effect. You can also drop signals variable as you don't actually use it more than once and could just write:

while(1) {
if(IExec->Wait(SIGBREAKF_CTRL_C) & SIGBREAKF_CTRL_C) break;
}

and move the IDOS->Printf("patching cleaned\n"); from this if to after deinit() That's more consistent with init() and then you have just a single line in your main loop that's really simple and clear. Actually if IExec->Wait(SIGBREAKF_CTRL_C) only ever returns when mask is set you don't even need the & SIGBREAKF_CTRL_C in the if, I don't know what IExec->Wait() could return here.

Only struct Task *Caller is static the others are global. Since this is just a single file it does not matter anyway so you could either drop static from Caller or declare all of them static for consistency. Or just make Caller local to Patched_OpenWindowTagList() as it's not used from anywhere else so no need for it to be global. Maybe that's why it's static? You can also drop the inits to 0 from all of these as globals and static globals are init to 0 but it can be kept for more explicit code.

The value of Caller and ready_string are not checked before usage so if there's an error it could crash on trying to dereference NULL pointer or use a string that's not complete.

Move setting disable_flash_beep just before you call the command, after asprintf and checking ready_string to minimise the possibiliy something else also calls DisplayBeep before your command and clears the flag. This may also happen sometimes anyway I think but that was already said by the original poster of this idea. So just setting it right before calling the command is the best you can do to minimise that.

Finally you can write WBOBJA_FullPathSize,sizeof(fullpath) The sizeof operator also works for constant size arrays then you can't accidentally change it at one place and forget the other so it's usually recommended to have such constants at one place or declare a macro when needed at more than one place.

Looking at it more I've also found possible actual bug. In Patched_DisplayBeep() return is missing before Original_DisplayBeep() in the else. Compiling with -Wall should warn for function not returning something and catch that.

@MigthyMax
It's hard to know what you're doing without a lot of details or seeing the code so it's hard to help. I don't know what's happening but if you think writes don't reach QEMU you could add additional logging in the virtio-pci as I said before to see what values reach there.

Other than that, maybe check if addresses written in the queue are correct. I'm not sure but I think virtio devices need physical addresses as they don't know about the CPU virtual addresses so unless you have a one to one mapping you may need to translate addresses to physical memory locations that you tell the device to operate on.

Also you can try -trace enable="virtqueue*" to see changes to queue. See other trace entries in qemu/hw/virtio/trace-events.

@smarkusg
About SDL1 image error, in QEMU master there was a fix for an AltiVec bug so maybe check if that did anything but I don't think so as the same G4 CPU is used on amigaone too where it did not appear. So I still think that's the main question what part of code is only running on pegasos2 and not on amigaone or vice versa and why. There does not seem to be anything in SDL itself that could run differently so it may be the AltiVec gfx optimisations in graphics.library that works differently. Even though that's also enabled on amigaone it may have some checks not activated on pegasos2? But if nobody has sources for that library it might be hard to check.

@Maijestro
One important detail missing is if you pass through a USB device to QEMU you should make sure nothing is touching it on the host while passed through to guest. So USB storage devices should be unmounted on host before pass through and other devices may need their host drivers unloaded so it's only the guest driver which drives tham. Accessing a device by two drivers (one on the host and one in the guest) will just mess things up an lead to some breakage so always make sure there's only one driver driving the device. When passing it through that should be the guest driver so host should not drive it. You also need to make sure the user under QEMU is running can access the raw usb device. On macOS this may work, on Linux you may need to change owner or access rights of /dev/bus/usb/$X/$Y to the user or add an udev rule to do that or add an ACL for it on device plug. You can see $X and $Y with lsusb.

@kas1e
Could be made even more simple by doing

asprintf(&ready_string, "%s%c%c%s%c", filer_binary, ' ', '"', fullpath, '"');

which may be faster than calling it three times. You may want to check return value to make sure command is constructed correctly.

Also in main() you can drop the "notdone" variable as you "break;" out from the loop so it will never be checked and it can just be an endless loop with while (1).

I'd also move "filer_binary = argv[1];" to after argc is checked although it does not matter as it's not used before.

@TheMagicSN
Quote:

It does not crash just produces garbled graphics with some SDL1 apps. What's strange is this only happens on pegasos2 not on amigaone but these two machines are very much the same on the QEMU side so there must be some difference on the guest side. When booting pegasos2 kernel with debuglevel=7 I've noticed these logs:

which are the first things printed after kernel starts so probably part of graphics.library or siliconmotion502.chip as the logs from the SM502 driver follow immediately. This looks like it could have something to do with the issue (as it goes away when using -cpu g3) but don't know where these logs are coming from or if they are present on amigaone. Maybe this is something that somebody interested to find this out could start from. Anybody knows more about what these logs are and where they are coming from?

@MigthyMax
If you don't see access with -trace enable="pci*" when reading writing config space then it does not reach the emulated device. The pci_* trace points only show config space access, accesses to BAR aread may need enabling virtio trace points but qemu/hw/virtio/virtio-pci.c does not seem to have any. You can try to add printfs or traces to *_read/*_write functions in that file to see if they are called. Are you using the right address where it's mapped and is the correct enable bits set in the BAR? See Memory Space and IO Space bits in https://wiki.osdev.org/PCI#Command_Register (the Bus Master bit may also be needed if the device wants to write to memory with DMA). If the firmware does not know the device then it may only program the BARs but not actually enable the device so unless you enable it no access will succeed.

If you're the same person working in a virtio-net driver (you've mentioned virtio-blk above) then there may be only 2 people.

@MigthyMax
As for tracing from QEMU side look at qemu/hw/virtio/trace-events for trace points that cen be enabled. You can either add -trace enable="glob pattern" (can use multiple -trace options to enable different traces) or from the QEMU monitor. Also check info pci or info qtree and check that the BARs of the device are enabled and mapped or you can also use -trace enable="pci*" to check access to PCI regs. Adding -d unimp,guest_errors may also show access to wrong memory addresses but some of those are because of not emulated hardware so may not be an error.

Now there are at least 3 people working on virtio drivers independently. Isn't it time to collaborate on a virtio.library to avoid duplicated work? Is there anybody who wants to publish their virtio access routines under an open source license to make them a standard way to access virtio devices on AmigaOS that everybody can use?

@tekmage
Instead of modifying the CD maybe easier to create a boot partition as described on my pegasos2 install page:
http://zero.eikhttp://zero.eik.bme.hu ... u/amiga/aos_pegasos2.html

You need slb_v2 on the disk to boot on amigaone so you can't use amitools to partition the drive. Instead create an empty image and boot sam460ex then partition it installing slb_v2 from the System/L dir of the AmigaOne CD then create a boot partition and copy System/Kickstart from the AmigaOne CD to Kickstart on the boot partition. Then add siliconmotion502.chip from the Sam460 install CD and add it to Kickstart/Kicklayout and also comment out MODULE Kickstart/a1floppy.device.kmod when using QEMU older than future 8.2.

You should keep -serial stdio to see firmware messages, other debug logs are probably too verbose and not so helpful so not needed unless debugging.

I'll update the qmiga repo later (waiting for some fixes to be merged in QEMU master), it's still an older version so using QEMU master with the via-ide legacy mode patch series applied is recommended but may work with older version too. I think your problem may have been not disabling a1floppy.

@Hans
Is this with QEMU or on real machine with a bridge? If on QEMU is it using pegasos2.rom or with bboot? Can you boot Linux and check what that sees from the device? The lspci command has some options to dump the config regs so you can check with that what it sees. If this is through a bridge you may need to do something differently to access the other bus behind the bridge otherwise you may try to read device on the host bus not the bridge's bus so you'd get non-existing device that would return 0xff when you read it (which may be interpreted as 0 for BARs, I'm not sure). Maybe check some docs on how to handle PCI buses behind a bridge and check if the AmigaOS kernel does that correctly.

I'm posting this again so somebody with a real AmigaOne will see this because the previous post one was burried in recent activity on this thread.

Is there somebody with a real AmigaOne machine who could collect some boot logs? Currently A1XE is emulated so that would be the best but maybe at some point uA1 could also be added so any of these AmigaOne machines could do, they are probably quite similar with uA1 having some more hardware on board.

To collect logs you'd need to capture serial output and get what the firmware is writing there, booting AmigaOS after

preferable with debug kernel. And also booting linux and get the dmesg output during or after boot.

I hope the above make sense and there's somebody (like @kas1e or @sailor) with real AmigaOne G4 hardware who can collect such logs. It would help to compare these with the logs I get on QEMU when debugging emulation.

@kas1e
OK saw the post on other thread but still would need more context on what you're doing as I don't know what it's about.

@joerg
Even if -msoft-float is not a solution it might worth a try just to see if it changes anything. I can't tell if guest soft float would be slower/faster/same speed as QEMU soft float because while running in the host should be faster QEMU does a lot of checks and additional processing to emulate the CPU flags so if the guest does not do that it might be faster after it was JIT compiled so maybe it could help or be the same speed at worst. But it's still a guess that slow FPU causes to most problems, it may be something else so first we should try profiling to find what causes the issue then blame FPU. It's known to be slower than real hardware but maybe there are other things with bigger impact so those could be addressed too.

@Capehill
Where are the sources of that SDL1 version that exhibits the problem so we can check what it does? If it's the same on amigaone and pegasos2 and both use the same sm501 graphics card and CPU emulation in QEMU then how come it works on one but not on the other? Is there something different in AmigaOne version of AmigaOS vs. PegasosII version that could cause this? We should also be using the same siliconmotion502.chip driver on both and AmigaOS should also be the same on both. Still there should be something somewhere that makes it work on amigaone but fails on pegasos2 but there's nothing in QEMU to explain that so it should be somewhere else.

@kas1e
Are you sure you wanted to post this question in this thread? If so could you elaborate on what it is about as the context is missing so not sure what you're asking about. If it's about QEMU then you could try enabling some traces to see what happens. What traces to enable depends on what you want to debug but for pci devices adding -trace enable="pci*" at least shows access to PCI devices so you can see what the guest asked for and what it got. See -trace options in https://www.qemu.org/docs/master/system/invocation.html for more info and trace-events files in the sources for available sources for each subdir.

@TheMagicSN
Quote:
Tell whom to do that? QEMU is an open source project like the Linux kernel. There aren't people you can tell what to do. If somebody wants something to happen either do it and submit a patch or if can't do it may try to hire somebody to do it but otherwise it won't just happen. Looks like nobody cared to do either of these so far so it's still like that. I've tried before to enable hardfloat to test how much it would help and while it did run a but faster it made the current way slower and broke emulation of some bits in floating point status that probably nothing uses but breaking it is still not acceptable so I did not finish that and hardfloat remains disabled for PPC until somebody solves that it would both be correct and only use hardfloat if guest does not access these bits. We made some design how to do that but this is a bit more work that nobody wanted to put in yet. Somebody was interested once but then never came back with a patch so gave up without results.

But we don't know yet this is really the reason for running slower in higher resolutions so the question remains if there's a benchmark that shows this which I could try to profile and see what parts of emulation it uses so maybe it's something else that could be improved more easily.

There's also a possibility to use a real graphics card passing it through to the guest but that only works on Linux hosts and only with some graphics cards and it's not straight forward to set up so it's mainly for curiousity not something an average user might exploit. There were some experiments in one of the threads about it before and it could be made working but some bugs were also found which may need an updated AmigaOS kernel which isn't released yet so don't know how useful is that option other than for testing. (If you're on a laptop running Windows then it's not an option for you anyway.)