Kyvos was updated

@Mlehto
Unless you use the yet unreleased fixed kernel on a real PegasosII then the kernel up to and including 4.1FEUpdate2 has a known problem with configuring interrupts on PegasosII that BBoot does fix. This was found on QEMU but affects real PegasosII as well so using BBoot on that might help too (and it also boots faster). This can lead to lost interrupts if multiple devices use the same interrupt and that happens more on PegasosII due to how the firmware assigns interrupts. The BBoot README has some info on how to use it on real PegasosII. Removing a card may only help by reducing number of interrupts so the problem happens less frequently but it's not really fixed. Only updated kernel or BBoot fixes that config issue.
On QEMU this problem is fixed using BBoot too but interrupts still don't seem to work with passed through graphics cards so that's a different and unrelated issue that is not fixed yet which likely does not affect real machines but specific to vfio-pci.

@balaton

Thank you. Really. Have to check bboot and use it.

Today I released a new version of Kyvos, which reach the 1.5.0. This is a smaller release with a couple of features implemented and a reported bug fix.
https://ko-fi.com/post/Kyvos-1-5-0-released-C0C51LTQXL

Here is a list of the latest changes

### Added
- Added the options "zoom to fit" and "zoom interpolation"
- Added a new tab to keep notes for each VM

### Fixed
- Fixed an issue with the bboot path when there is a space

Kyvos can be downloaded at https://ko-fi.com/s/6476fdadd2

Sorry to ask...

I get in AmigaOS4 and also MOS the same error:

"There was an error with the VM and it couldn't start. Please check the configuration"

Where I'm wrong?

The creation of VW was completed ok...

@Tuxedo
I guess you are Windows, right? It is a little bit difficult for me to help you with the information you provide.

I would suggest you get the qemu command with all its arguments (right-click on the vm and select the arguments menu) and paste them in a terminal. Then execute it. This will provide you more information, that will be useful for me to help you.

Also, please download and read the manual, especially the FAQ section, which has a lot of useful information.

If you can't figure out the error, paste here the result, as well as the command that is used.

Quote:

Its ok or have to do something else?

On the FAQ section the error I write before wasn't explained so I wrote here...

Yes, I use win11.

The qemu you have installed does not support the SDL renderer. Did you download the Windows version mentioned in the manual or something else?

I simply run kyvos and let him download all needed...maybe something went wrong in that process(I do it with kyvos 1.4.0

Where I've to get the right qemu version?

Thank you.

@Tuxedo
The issue you have is with the installed QEmu on your system. Kyvos doesn't download it. This needs to be installed manually. I provide information where to download it in the manual that is available to be downloaded from the same place you got Kyvos. Also, the same information is available at https://github.com/walkero-gr/kyvos

Thank you.
Since kyvos will download some dependencies I tought it downloaded also qemu, instead it was iustalled by me who know when...

Keep Up Good work!

@Tuxedo
Quote:

Yeah, Kyvos can't and shouldn't do that because qemu and 7zip, which my app uses, need to be installed system wise. Especially when Windows and macOS are so picky on what software is installed, and if that has been signed with their companies etc. Also, with Linux there are so many different distributions and ways to install them, that would be time and energy consuming to support all of them. So, I prefer to leave it to the users.

@balaton

Managed to get archlinux and qemu up. Actually Os4.1 works surprisingly well with sm501 emu. Even on generic i7 laptop. Its not rocket but not sluggis either.

Allso bboot works on my real pegasos2 now. You mean that bboot fixes edge/level on interrupts? That really should change things, let see. After all, it is welcome fix, as no one knows when updated kernel will be published. I install usb2 card back, it shows difference pretty fast.

Wich fixes bboot includes regarding to problems on OS4.1 on Pegasos2?

I scanned today all devices connected on OF and irqs looks fine there. Have to double check.


Thanks anyway, qemu is pretty cool :) Ordered R9 270 card, let see results with that.

@Mlehto
Quote:

Here is a brief description:
"BBoot is also needed to fix up 64 bit BARs and interrupts for the AmigaOS kernel or even to boot a real machine faster"
You can find a detailed description here -> https://codeberg.org/qmiga/bboot/raw/branch/master/README.rst

Quote:
Running vfio-pci GPU on QEMU Pegasos2 is a bit complicated.
It is easier to do it on QEMU A1.
@walkero wrote that Kyvos is not a program for running AmigaOS4 through QEMU in highly compiled configurations.
This program was not written for that purpose. You will most likely have to do everything from the console or scripts.

@smarkusg

Thanks.

I tried to get Amigaone-version but seems to be sold out. It may hang some sites but didnt get answer for question about availability. Will buy if ever available again. My AmigaOne broke and it was before FE time. Luckilly around same time as peg2 version came out.

I didnt get clear picture from readme, wich of these bboot fix. If Im read correctly from here and there, BARs and edge/level is fixed. Look behind bridges may or may not work, not possible to test as I dont have pci-pcie riser for example.


This is allmost thread-hijacking but… OF fiddling, IRQ findings.

Four known broblems. Below more or less correct.

- Kernel doesnt see behind bridges
- 64bit BARS are alien to kernel, needs to be trunkated to 32bit
- interupts are set to level, should be (falling) edge
- All devices mapped to interrupt 0x09 on OS side.

First two leads incompability at minimum, last two affects stability on some circumstances seriously.

Interrupts to set edge affects stability more than all mapped same irq. PCI standard says level, period. That was obvious on A1 uboot, where set them level made it pretty unstable and freezing was problem. It was long ago, but if I remember correctly, boards were delivered at start interrupts set on level. Can be wrong. It was time when all these strange irq, level/edge things were pretty new to amiga folk, as you dont need to think them on classic. So no people to blame.

If all irqs are mapped to same address, it leads irq thunder. Kernel needs to make more work to take care about situation, at some level at least. No catastrophe, some performance hit probably. Some drivers cant share irq. This leads instability. Suspected by me and probably others rtl8139 and usb2.0 at least.



I scanned via serial terminal both buses /pci@80000000 and /pci@8C000000 and _all_ devices behind them inside OF and at first look I got picture that IRQs are just fine there. Havent had time to double check results yet. If so, irq mapping scheme on OS is not OF fault. They are addressed to same irq elsewhere. My peg2 2b2 has newest OF delivered with board, newer than publicly available 050404. Could dump current OF out and downgrade it to 050404, but without very good argument I dont do it, because swapping firmwares forth and back can brick whole machine.


I scanned OF devices because planned to set IRQs inside OF by forth script launched inside bboot.fth but as for my findings it is unneccessary. IRQs are messed elsewhere, it seems.

Compared to uboot OF is really pain in the *ss to fiddle around. By the way.

As a side note, bboot on real peg2 works bit different to amigaboot.of as next.

When OS is installed, first small FFS partition is made. There resides amigaboot.of. Next partition wich usually is SFS02 has OS. After installation both has boot priority 0. Amigaboot.of is happy with that, it boots to OS. Bboot cant understand difference between that and tries to find OS from first partition with highest boot pri (it seems) and boots from first partition. Result is boot picture without booting to OS. Fixed that setting first partition boot pri to -3. After that boots to OS.

Dont remember nothing about initial installation, it was perry much 15 yrs ago.

That is pretty all what I know about that Pegasos, OF, bboot and os4.1fe :) Text is complete as it can be read any level of knowledge of amiga.

@balaton


Still unclear if we talk about edge/level fix or all irq on same 0x09.

I checked all interrupts on real peg2 board yesterday on OF. They seems to be fine. Double checked. So what one could fix and where? Nothing to do on OF it seems.

After booting with bboot irqs are still 0x09, same as with amigaboot.of.

Altought set interrupts to level is anyway very good.

Didnt want to mess this thread more, please check:

https://www.amigans.net/modules/newbb/viewtopic.php?post_id=157113