Where does SFS version 1.293 come from? The install CD seems to have 1.290 and did not find a new version in updates 1 and 2. The Aminet 1.277 version also fails on pegasos2 the same way as 1.290 on sam460ex but 1.290 works on pegasos2. I'm still lost about what makes it exit on sam460ex. This happens somewhere after it checked the system type but before opening other libraries.
@joerg OK, I don't have Enhancer but we should aim to fix it for 1.290 that's on the install CD otherwise it would be difficult to install a system. I assume that version should work on real hardware if it comes with the sam460 install CD. If I enable WaitPkt/ReplyPkt logs in Snoopy I also get the same logs but the ReplyPkt is followed by close(dos.library) on QEMU sam460ex.
It looks like the function that checks PCI bridges returns 0 and that makes it exit. Even if it finds 1014:27f it goes on trying 12d8:8150 then exits with 0 which the caller treats as an error and closes dos.library and exits (even if I add a dummy 8150 bridge device to sam460ex). At least that's what I think without the source. If you have the source please check this function and tell me what it may be missing on QEMU that it checks additionally to PCI device IDs. It may be some property of the PCI bridge is missing on QEMU that it looks for.
I assume that version should work on real hardware if it comes with the sam460 install CD.
Depends on the version of the install CD: - The SFS versions (I don't remember which versions of SFS were included on which versions of the AmigaOS 4.x CDs) included until Amiga OS 4.1 Update 5 or 6, the last AmigaOS 4.x distribution for which Hyperion had the permission to include my SFS versions as free contribution on the CDs, should work. - Pirate copies of my software, for example the SFS version included by Hyperion despite explicit prohibition to continue using any of my AmigaOS 4.x software on their AmigaOS 4.1 CDs, for example AmigaOS 4.1 Update 7/"Final Edition" or anything later, should fail. It's not limited to SFS, most of my AmigaOS 4.x software illegally distributed on such AmigaOS 4.1 CDs, for example AmiDVD and several others should fail as well. No matter if real hardware or emulated.
I assume that version should work on real hardware if it comes with the sam460 install CD.
Depends on the version of the install CD: - The SFS versions (I don't remember which versions of SFS were included on which versions of the AmigaOS 4.x CDs) included until Amiga OS 4.1 Update 5 or 6, the last AmigaOS 4.x distribution for which Hyperion had the permission to include my SFS versions as free contribution on the CDs, should work. - Pirate copies of my software, for example the SFS version included by Hyperion despite explicit prohibition to continue using any of my AmigaOS 4.x software on their AmigaOS 4.1 CDs, for example AmigaOS 4.1 Update 7/"Final Edition" or anything later, should fail. It's not limited to SFS, most of my AmigaOS 4.x software illegally distributed on such AmigaOS 4.1 CDs, for example AmiDVD and several others should fail as well. No matter if real hardware or emulated.
SFS v1.277 PPC on aminet (and v1.293 in enhancer) has the same issue as v1.290 on the AOS4.1FE iso as far as I can tell, where-as SFS v1.277 68k works.
@derfs I'll fix any problems with the Enhancer Software versions of SFS, but that may take some months (no public release until it was successfully tested by several beta testers) until a public update can be released. No support for the ancient Aminet/OS4Depot versions any more, neither m68k nor PPC, and of course especially none for the versions on Hyperion's AmigaOS piracy software collection CDs like "AmigaOS 4.1 Final Edition".
BTW: I never expected to still have to support the ancient SFS (of course it's better than FFS, but even SFS was designed already about 30 years ago, for HD partitions up to about 100 MB), the much better NGFS should have been available since at least 15 years...
Sorry, I mentioned the different SFS versions to show that it is less likely an issue with SFS, but more to do with the OS4 function call SFS is using that fails the check for the PCI bridge.
The call to OS4 that queries the bridge device does not fail but when the PCI bridge is found SFS then checks for the Pericom bridge and that's not there so then returns 0 from the function that checks for bridges but I don't know if that's normal or not, maybe it fails later. Even adding a pericom bridge device does not make it work. It would be simpler for @joerg to check the source than for me to debug a binary only blob.
Could somebody with a real sam460 (any variant may probably do if no EX is available) post the output of lspci or showconfig to see what devices exist on real machine? Maybe the bridge is different on real machine and that's why it fails? I could not find any useful logs on-line so far from real sam460. Also could somebody with real SAM460 confirm which SFS versions work on real machine? (We have 1.277 on Aminet, 1.286 on 4.1Upd1, 1.290 in 4.1Upd5 and later including 4.1FE and 1.293 in Enhancer that I don't have. Could somebody with real sam460 test which of these work and which don't to avoid any issues with that.)
I saw that you posted a patch for "ppc440_pcix.c" yesterday. I checked quickly Qemu with sam460.I plugged in a disk image with SFS initializes and works.
I have SFS with ES - version 1.293 Qemu version 9 RC1 Thank you
@Maijestro sii3112 is a SATA card not SCSI (but it really uses the same ATA emulation as via-ata used on amigaone/pegasos2). The sii3112 is used by default on sam460ex and should work, it has nothing to do with the SFS issue.
@smarkusg I've sent the patch but 9.0-rc3 was tagged just now so it probably missed 9.0 and will only be in 9.0.1. I'd still need the lspci or showconfig output from a real Sam460 as I've asked above to confirm it's the right fix but seems to resolve the problem at least for now. Too bad I got to know about this too late (it was reported before but I forgot) so looks like it could not be fixed for 9.0. (There's still a slim chance for 9.0 if there will be an rc4 but otherwise you'll need to wait until 9.0.1 or 9.1 in August or compile your own QEMU to have this patch.)
I'd still need the lspci or showconfig output from a real Sam460 as I've asked above to confirm it's the right fix but seems to resolve the problem at least for now
I don't know too many people who have a real sam460, but if no one answers, I'll try to ask around and let you know @.
I've sent the patch but 9.0-rc3 was tagged just now so it probably missed 9.0 and will only be in 9.0.1. I'd still need the lspci or showconfig output from a real Sam460 as I've asked above to confirm it's the right fix but seems to resolve the problem at least for now. Too bad I got to know about this too late (it was reported before but I forgot) so looks like it could not be fixed for 9.0. (There's still a slim chance for 9.0 if there will be an rc4 but otherwise you'll need to wait until 9.0.1 or 9.1 in August or compile your own QEMU to have this patch.)
I can't confirm that!
Tested with Qemu Master Machine Sam460/AmigaOs4.1 FE Update 2/Kernel Update 1. I used the patch from here:
Tested with SFS 1.293 all my SFS partitions are not shown. Maybe I made a mistake, but I checked it 3 times and compiled Qemu with the new patch. Or newer AmigaOs4.1 updates make it unusable again.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE