Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
409 user(s) are online (268 user(s) are browsing Forums)

Members: 1
Guests: 408

murasame, more...

Support us!

Headlines

Forum Index


Board index » All Posts (balaton)




Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@white
Quote:

this is the qemu 8.0.3 command line:

Are you sure it's QEMU 8.0.3? That version didn't have -initrd yet I think unless that patch made it in stable without me noticing but it's more likely a typo. All should be testing 8.1 rc release now so we can fix any bugs for the release.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@joerg
Quote:
I can change it in the next SFS update, but until now that never was a problem since all other bootloaders (classic Amiga, SLB_V2, amigaboot.(ub|of)) are case insensitive.
The only problem might have been using a case-sensitive formatted SFS partition for the kickstart files, but I'm not sure any of the boot-loaders supports that at all.


More exactly Amiga file systems are usually case insensitive so the bootloader passing a name with a different case would still read the file. There's nothing in the bootloaders to handle this, it's because of the file systems. BBoot cannot read from disk so it reads from a zip instead which is case sensitive but I don't want to add special handling as it may later also read from disk and then reading from a case sensitive file system will be the same.

If you correct this in SFS consider that all other file system modules seem to be using capital S as FileSystem only SFS uses lower case so maybe it was supposed to be corrected by renaming the module but the Kicklayout entry was missed as it still loads that way on case insensitive file systems. It seems the upper case version comes with Enhancer Software so perhaps that should also change Kicklayout when installing the new module.

I've made some changes to Kicklayout parsing to be more tolerant in next version but I don't plan to handle case sensitivity there.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@Maijestro, @joerg

There may be some issues with parsing but BBoot is case sensitive and don't plan to make it insensitive (no strcasecmp in minimal libc) so you should match file case. I did a diff of the names in Kicklayout and zip listing above and it found this:

-Kickstart/SmartFilesystem
+Kickstart/SmartFileSystem

This is what I said in first reply: "check that 1. it's there, 2. its name matches what's in Kicklayout"

Leading spaces should not cause problem and ; lines should also be ignored even with spaces before them. I'll check white space at end that may cause trouble and may need to be handled.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@derfs
Does that crash cause any issue apart from the log? The emulated pegasos2 does not have nvram so even using the pegasos2.rom it would not be able to read anything but if it uses rtas then with VOF even the rtas calls are not implemented. I can look into that if it causes a problem but since there's nothing to return it does not matter if the result is only this log message but no other problems in AmigaOS.

If it's a problem with unimplemented rtas call you should see messages saying "Unknown RTAS token..." when using -d unimp QEMU option when the crash happens. That would confirm this is calling rtas and does not handle error from there (becuase on real firmware these are implemented).

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@Maijestro
Maybe it's the commented out MODULE lines in your Kicklayout. Those should be ignored but could be I got parsing wrong for this case. I'll check but for now you could use an unmodified Kicklayout (apart from adding the sm502 driver).

The .DS_store is added by macOS, it should not cause a problem though as anything not referenced in Kicklayout will not be extracted anyway.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@derfs
Debug output would help to do anything about it, without that we could just say good luck to you. If the host crashes you could try redirecting serial output to file (I think it's -serial file:output.txt or similar, check QEMU docs) and hope that it won't crash befote that's written or you can try removing the driver for passed through card from Kicklayout in zip so it won't load and boot with sm501 to see what AmigaOS gets in case it crashes when the driver touches the card. Did this work before? Then you can also try using pegasos2.rom and compare the values for the card's BAR.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@smarkusg
Quote:

2GB memory ? ;-D


Yes, this is another issue this approach fixes as the 1GB limit came from the firmware but since we don't need it any more we also lose all it's limitations as well.

That's why I though it worth to pursue this as this gets more than two birds with a stone as they say.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@MartinW
Quote:

For any other Mac users reading this, it's worth noting that it doesn't like a zip file where you've just right clicked the Kickstart folder and selected "compress". It finds it and can count the number of entries but fails to decompress it. That's MacOS likely using some different compression and I wouldn't think worth dwelling on.


Looks like macOS creates broken zip that way but it's easy to fix which is now committed to git and will be in 0.2 version eventially.

Quote:

I'll try on passthrough hardware tonight. Would be great if this works. Saves a lot of messing about in OpenFirmware

Even if it does not work the printed numbers should help you with the Forth script as the numbers on the left of | are the raw assigned-addresses values that is not easy to get from SmartFirmware. Bit hopefully it also replaces the script and does everything what's needed.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@kas1e
Yes, it's explained in the REAdME (I've spent some time writing that so you should also spend some reading it :) ) When using real machine it's the same as when using pegasos2.rom, you need to use the bboot.fth script after you edit the Kickstart.zip length in it (because I could not find out how to get that from Forth and did not want to spend too much time on that). It should output on serial but if that does not work even after tuning settings mentioned in README I can add option to use OF console instead. It would be interesting to see values from real machine for comparison and if it can fix 64 bit BAR for PCIe card there.

Go to top


Re: Booting qemu Pegasos II over TFTP
Just can't stay away
Just can't stay away


@Maijestro
I have docs on that but it's a complex device so not keen on emulating it as there are already other network cards emulated. It's possible that the pegasos2 firmware does not have an rtl8139 driver and only supports the on board ethernet, I don't know and we have no source to check. But maybe bboot can help with this too, it can't do tftp but editing the zip on the host may be easier and scriptable so it could be almost as good as using tftp. (Tftp support could also be added to bboot but then it would also need a network driver so it would become more complex and I've only found small driver for ne2k not rtl8139 so I won't consider adding it to bboot yet, maybe using the zip initrd can work for now.)

Go to top


Re: qemu and tap network on Windows
Just can't stay away
Just can't stay away


@Maijestro
No, that will forward port 9000 to 9004. Check QEMU docs on this, it's here. You probably need 5 hostfwd options for each port in 9000-9004

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@Maijestro
Quote:
Qemu was built from the git master sources from https://scm.osdn.net/gitroot/qmiga/qemu.git


I'm not keeping that repo up to date, only commit development versions there so you're better off using QEMU master (that's currently at 8.1-rc0) unless you want to test patches from the qmiga repo.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@Maijestro
Can you try to get some verbose listing of your zip file showing file compression used? The minimal unzip in bboot only supports store and deflate so if your zip utility used something else bboot can't read it (assuming you really have SmartFilesystem in the zip and it wasn't missed somehow and matches the name listed in Kicklayout). Maybe try a different zip utility to create the zip file, the zip command under Linux (that should also be available in brew or macports on macOS) worked for me. Using that you can get verbose listing with unzip -v Kickstart.zip. The error says "cannot find file" so check that 1. it's there, 2. its name matches what's in Kicklayout

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@Hans
You should not need to do anything special on emulation. It should emulate the hardware and work the same so you should not need to detect it either.

There are no caches emulated in QEMU so you also should not need to care about cache coherency as QEMU does not cache anything.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@derfs
There's also info qom-tree which should help identifying what device /machine/peripheral-anon/device[0] may refer to and maybe you should try to give bboot a try and post the log that should show how BARs are set up or if it could fix them.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@all

Introducing BBoot, the boot loader I proposed before and was werking on. This should be useful for multiple use cases. The main goal is to be able to boot AmigaOS without needing pegasos2.rom but it should also help with other problems such as debugging PCI pass through as it will try to fix BARs or at least provide detailed info on how the firmware and card sees them. More info on the project page at:
https://osdn.net/projects/qmiga/wiki/SubprojectBBoot
and supposed to be available under File releases there but since OSDN seems to be dying since recently I've also uploaded it here:
http://zero.eik.bme.hu/~balaton/amiga/bboot/

The README in the package should give some idea on how to use it. One important details that -initrd option needs QEMU compiled from git master so if you're using older version it will not work. (There's a generic loader that may be used instead but I have no idea how to use it but ir's documented in the QEMU docs if somebody really wants to find out.)

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@MartinW
I wasn't clear in the post above about my boot loader that what I've found about sm502 driver needing assigned addresses, BARs programmed and IRQ programmed via PCI config reg 0x3c of the card might also be relevant for passed through cards, althogh I don't know if the Radeon drivers need the same. But in any case check that when at the firmware prompt the card has these set up and if not these might need to be patched from the script converting BARs. In particular IRQ should be set to 9, if not then it may check the wrong IRQ or miss them that leads to a hang. I think the pegasos2.rom would set this for all PCI cards unconditionally but maybe worth a check. This may not even show up in info pci although that lists IRQ for some devices it does not show it for sm501 for example but I don't know why. So one has to check the PCI config reg 0x3c somehow. I don't know an easy way, maybe -trace enable="pci*" shows accesses to config regs and one can check there. Maybe it's not causing the IRQ issue with passed through cards but worths a try checking it anyway.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@joerg
But that Alpha layer and the hardware alpha blending that uses it are not used by the AmigaOS driver so it does not have to move any data there. It already does software compositing for 16 bit mode as the sm502 driver has no compositing support and I think it could just do the same with 32 bit too so there's no hadware limitation here just a driver limitation. How I know it's not used? QEMU does not emulate any of it and we still get picture in AmigaOS. What we had to add was some blitter ops that are used but that should work the same in 32 bit mode. It may be too slow on a real sam460ex with a 1GHz CPU but people use PCIe gfx cards there anyways and it could be usable with QEMU. But since @m3x did not react on any of this I think he's not interested to change this driver any more so we're stuck with what we have. To resolve the problem need to write a new driver but then target a better option such as virtio. So this is just to understand if there's a hadware limitation or a software one. I think there's no hardware problem just that driver was only made for 8 and 16 bit modes.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


Quote:
Still trying to find out how to boot AmigaOS without pegasos2.rom

I've figured this out. Looks like it crashed on wrong assigned-addresses properties. It seems at least the sm502 driver needs both an assigned-addresses property and the card being programmed by the firmware with noth the BARs written with the values corresponding to the assigned-addresses AND also PCI config reg 0x3c set to the IRQ it should use (which is 9 for everything on pegasos2). After that it boots but I still have some things hard coded in QEMU for it so now I'll have to find out what else is needed and try to do all this from the boot loader so we don't need changes in QEMU as other guests don't need any of this so this should really be in AmigaOS that we can now patch up in the boot loader instead. This will take some time to to but I don't see a blocking issue now.

This may be different for other graphics drivers but it seems AmigaOS relies more on firmware setting things up than other guests do.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


@Hans
Quote:
The problem with compositing, is that the SM502 only supports the alpha channel being in a separate bitmap (or bitplane), whereas AmigaOS mostly uses ARGB32 bitmaps, with the alpha channel included in the chunky 32-bit pixel. Emulating compositing with ARGB32 using a separate alpha bitmap isn't easy, and would be very slow if the SM502 isn't able to extract an alpha channel from an ARGB32 bitmap and write it to a separate alpha bitmap.

Hans


I did not read all the SM502 docs but AFAIU the separate alpha bitmap is only used for compositing graphics output to a video input (as this chip was probably meant to be used in a set top box or similar) but in 32bit graphics mode without video layer it stores RGBA and just ignores the A part so you could store the alpha channel there and use it for software rendering, can't you?

Go to top



TopTop
« 1 ... 45 46 47 (48) 49 50 51 ... 57 »




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project