@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.
@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
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.
Great work! I will have a test tonight. I’ve migrated to an older PC (i7 6700k) which actually has a faster single core frequency and no complications with resizable BARs. I did some quick tests and the passthrough still worked and gave the exact same results as my gaming PC. It just frees the gaming PC back up for gaming duties 😁
@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.
Or, is the Marvell Discovery II chipset's cache already coherent?
Should be, since that was the reason for using the Marvell in the Pegasos2 instead of the Articia-S in the Pegasos1.
Okay, so it's worth trying then. I'm skeptical if it'll work, though, because the graphics card needs the RAM's actual physical address, but AmigaOS' DMA/memory functions can only give a 32-bit physical address.
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.
GART requires cache coherency, so it won't work on hardware that doesn't have cache coherency. If it will work on an emulated machine (due to the host's caches being coherent), but not the real hardware, then yes, I need to be able to detect emulation if I'm going to enable it for the benefit of emulation users.
However, it appears that the Pegasos II's caches are coherent, so this is no longer an issue.
bboot worked first time here under emulation. But given that's probably an almost identical setup to what you developed against that shouldn't be a big surprise.
I just downloaded zip-bin off of OS4depot, zipped it up and off I went. I did unzip on macOS and re-zip having edited the Kicklayout file, but after zipping from the command line it worked on the new file quite happily.
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.
Zip from the command line works just fine. I don't know where that came from but it's not pointing to a brew symlink so I think it's a system installed command.
I'll try on passthrough hardware tonight. Would be great if this works. Saves a lot of messing about in OpenFirmware
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.
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.
I had some unexpected 'lowercase vs. uppercase' issues for the name of the zip file, as well as whats in the kickstartlayout file vs the names of the actual files.
Im getting the kickstart files to load, but before i get the passthrough gfx output on the 2nd screen my pc hard crashes!
Not sure what to try and check to be honest.
*edit*
also use
-append "os4_commandline serial munge debuglevel=3"
I've had a hard crash or two on the RX cards. They don't like the VM to be loaded more than once and require a physical reboot in between. I suppose it could be similar with the R9 but I don't remember having those issues with that card.
@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.
Im ignoring the passthrough card first so that i can check things are running as they should. Running the same kicklayout which includes RadeonHD driver, but just using -device sm501.
1st bug is getting a crash in AmigaOS on module nvgetvar, which im assuming is because we are not using the pesasos firmware now.
Dump of context at 0xEFC6CBA0
Trap type: DSI exception
Machine State (raw): 0x0000D030
Machine State (verbose): [ExtInt on] [User] [IAT on] [DAT on]
Instruction pointer: 0x7FCD6BCC
Crashed process: nvgetvar (0x60C7D7C0)
DSI verbose error description: Access not found in hash or BAT (page fault)
Access was a load operation
0: 7FCD6124 5FB5FF40 ABADCAFE 00000000 5FB5FC69 5FCD8088 00000001 80808080
8: 02048A81 0000006F 02048A88 00000064 010D41B9 ABADCAFE 5FBF49B4 5FB60010
16: 02330000 EFC95F00 02330000 00010000 5FBF49B0 60773C40 01843848 60775A70
24: 6FF7E044 60F1F580 00000000 5FCE0000 00000000 6FF96300 02172C88 6FE69BA0
CR: 35955353 XER: ABA1CAFE CTR: 0000005D LR: 7FCD6158
DSISR: 40000000 DAR: 00000000
Kernel command line: os4_commandline serial munge debuglevel=3
balaton wrote:@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
I now tried to create the kickstart folder with "zip -r Kickstart.zip Kickstart/" as described in the readme and mount it with Qemu and BBoot. Again some modules are not found and I don't know why. It is exactly the way you described in the readme. I took the Kickstart folder from my AmigaOs4.1 installation.
@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.
@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).
@Maijestro I guess BBoot's kicklayout parsing isn't very error tolerant yet, make sure upper-/lower-case are the same, no space at the end of a line, at the end of the file an empty line (not that it's MODULE Kickstart/mounter.library<EOF> instead of MODULE Kickstart/mounter.library<LF>), don't edit the kicklayout file with default editors of incompatible OSes using <CR><LF> (CP/M,MS-DOS, Windows) or <CR> (MacOS) instead of <LF>, etc.