QEMU v11.0.0 is released. I've updated my page (link in signature), see News section where you might find something useful for somebody.

@kas1e
Yes, looks like VGABIOS-lgpl-latest.bin does not work with ati-vga. You need a ROM from a real card matching the emulated chip so only Rage128Pro and RV100 (M6/7000) might work. For cirrus-vga there's VGABIOS-lgpl-latest.cirrus.bin that might work with the bios emulator in original ROM (I haven't tested). It's known that default QEMU vgabios does not work with BIOS emulators in any AmigaNG I've tried they all seem to crash on an i368 opcode that these bios ROMs have. Maybe newer x86emu versions can handle that? The model=rv100 has bugs before QEMU v11.0.0 and even with that latest QEMU it's not emulated enough for any more advanced driver to work with so it won't work with AmigaOS. If you want to test with newer cards you'd need vfio-pci pass-through and a real card.

@kas1e
VGABIOS-lgpl-latest-banshee.bin I think is for Voodoo emulation. Maybe you need VGABIOS-lgpl-latest.bin for plain VGA which should also work with ati-vga. Did you try R7000/RV100 bios with -device ati-vga,model=rv100? You probably need latest QEMU from git for that though as there were fixes recently in ati-vga.
SM501 does not have VGA compatibility and thus VGA registers but -device VGA and ati-vga supports VGA modes and ports, these should be mapped in the ISA ports range where serial is where we found the clash with parallel port so I think original PegasosII ROM also accessses these registers. You can see ports in QEMU monitor with info mtree command.

@Hypex
Looks like it failed for you before it could look for the zip. The log you posted looks like how the first 0.9-alpha version crashed trying to access serial. Sorry, but I then replaced it with a version that disables serial without updating the version number so just redownload it and use the current 0.9-alpha which should not have this problem. If you redirect to serial from CFE that might work, the problem is with direct access to serial. BBoot has this to be portable contrary to what you suggested because BBoot also runs on QEMU amigaone without any firmware so it can only write messages through direct serial access which should work on all machines except there's apparently an issue with caches specific to X1000. I'll need to fix this eventually but did not get to that yet. If the location of ramdisk is passed in the registers BBoot should pick it up but so far others who tried it did not report that worked so loading Kickstart.zip at the default address for BBoot (0x600000) should work sans CFE bugs in commands that should do that.

@Hypex
These are what Open Firmware calls client interface. Then CFE is like VOF in QEMU that only emulates this and provides enough of the Open Firmware enviromnent that simple boot loaders need. Except that CFE also supports reading blocks from disks which isn't implemented in QEMU's VOF.

@smarkusg
You found that an NVMe SSD is faster than a SATA3 one. That's nothing new. To compare how the pass through works you should compare similar disks with pass through or using nvme emulation using local file with the same guest driver. That's probably better comparison to measure the pass through as other parameters are more similar and the measurement would show more of the pass through than other effects. Maybe you're not interested to do such test and I'm not requesting you to do it, just noting that comparing pass thorugh nvme with one driver and image file on SATA3 SSD (with IDE and another driver?) is not much useful comparison.

@kas1e
You could see output with os4_commandline set but that's also not default and on pegasos also needs to be defined with nodefaultbytes (there's a Forth script called bootloader_prepare for that on the install CD that you can call). And you need to do that at every boot because NVRAM is not emulated on QEMU so saveenv has nowhere to save.

@kas1e
Do you have siliconmotion502.chip in your Kickstart (the Pegasos2 CD does not have it so you need a boot partition on your test disk I think)? You can also set os4_commandline env var to get serial debug and use kernel.debug to see if kernel starts or not.

@kas1e
These used to work but haven't tested it recently. The parallel port issue you found has not been fixed and as I predicted I forgot. I've tried now and these VGA ROMs indeed don't seem to work for me either but did not debug it yet. However your problem with amigaboot.of is very likely not related to display as it should boot even without any vga card (like -vga none -device sm501) so if you get output on serial you can use that and stop trying ati-vga. To find the issue with amigaboot.of here are some tips: If there's a debug in SF that you compile for the openfirmware client interface enable it to see what amigaboot.of calls. Also make a dump-all with the original firmware and yours and compare them if there are any differences. Maybe those can show where something is missing.
EDIT: OK quick patch is to comment out:

that disables remapping parallel port address so it won't cover the vga and with that at least rage128progl16mb.VBI works. But as I said this likely won't make a differnce for your problem.
(I likely won't be able to make a proper fix because this stems from interaction of different devices vga and parallel that are only indirectly used and not controlled by vt82xx. Two possible fixes I've noted before could be changing priorities but that's out of control of vt82xx or emulating enabling/disabling ECP+EPP features of parallel which could be done but:
1. currently parallel device emulation has no switch for advanced features so it's always enabled
2. vga and parallel are very basic devices used by a lot of machines so changing it could break something I don't know about or would need migration compatibility that I can't test
so it's just too much work for something that does not normally cause problems for most users.)

@kas1e
Quote:
I have a page about that too. I admit these aren't easy to find but I've documented everything somewhere. This is mentioned on ati-vga development page but that refers to an earlier bug ticket with sam460ex that wasn't moved to codeberg so maybe it's not obvious. TL;DR: BIOS emulators in PPC firmwares can't run QEMU default vgabios, it still works, you can type commands and they run but you'll only get errors instead of output. You need a VGA ROM that works, either the generic Bochs VGABIOS or a ROM matching the emulated card. There are some BIOSes at the Rage128Pro vgamuseum page from which rage128progl16mb.VBI should work as -device ati-vga,romfile= rage128progl16mb.VBI

@Hypex
Quote:
No BBoot likely could not find it because zip was loaded at wrong address. According to the above output ramdisk command may load at the default 0x24000000 address not at the -addr you specified. According to previous posts load command is also broken in other ways that it honors -addr but without also specifing -max with the exact size of the zip to the byte it either loads 0 bytes or tries to load too many and crashes. The commands @kas1e gave before (adjusting the -max number to be your zip size) should work but you did something else. Also BBoot does print debug and errors but serial on X1000 is not yet supported so these are printed in the CFE console (provided you used the 0.9-alpha version from earlier post) so look for it there but you did not post that part of the output so I don't know what it said. Older BBoot versions won't work or could tell you that on X1000 as there's no support for that machine in those versions. (Older BBoot version could still tell you machine is not supported if you 'setenv bboot "Of V5 Ab"' that disables serial output but all it would tell you is unknown machine.)

@smarkusg
First I only had the older up050404 ROM and that's what I tested with QEMU and documented. Later the one on MorphOS storage surfaced and first did not work with older QEMU versions but should work now with more recent QEMU versions (I don't remember which version exactly but quite a few years ago) but since AFAIK newer ROM only tweaks memory init which is not needed on QEMU it should not matter which version one uses.

@kas1e
What I know about pegasos2 firmware I documented at my QEMU pegasos2 development page that I linked to in the previous thread already.
I don't think you'd see a bPlan logo from SF built without bPlan's changes and maybe you would not see output a PCI VGA before your SF can see PCI devices. The open source SmartFirmware lacks the machine specific parts so you need to adapt the bebox or whatever you used for the pegasosII but then the pegasosII SF also has the x86 emulator hacked in to initialise PC VGA cards which I think is also not in the open source version and may be a bPlan addition too. But maybe it's not needed on QEMU as SF has a vga driver that accesses the ISA ports so needs at least that part working (but it may already work if it can find the ISA ports of the serial). This driver only accesses the default VGA (or even CGA compatibility?) mode so that should work with QEMU VGA or ati-vga without any ROM and the x68 emulator is only needed for real cards.
For machine specific init for the Marvell Discovery II chip and the bios emulator you could get inspiration and code from U-Boot. Apparently there was a development board from Marvell called DB64360 that was once supported by U-Boot and mentioned in u-boot/doc/README.scrapyard that it was removed on 2014-10-27 so it should still be in versions before that. That's probably most of the init code in bPlan bootstrap part. For the bios emu I think you want the latest from the Sam U-Boot that supports RX cards so you can look there.
For flash emulation look in qemu/hw/block/pflash_cfi*.c or qemu/hw/block/m25p80.c If your flash chip is compatible to any of these you might try to use these but maybe they are not fully emulating all the features or exactly what you need. Otherwise I don't know if QEMU can emulate it.

@Hypex
Quote:
Reading the above I can't make sense of what you're trying make sense but RTAS is part of PowerPC CHRP (Common Hardware Reference Platform) so look for that specification, it's documented in there. The OS needs to "instantiate RTAS" which copies some code that calls back intro the ROM which the OS later needs to call if it wants to access RTAS services. You can see in QEMU pegasos.c which RTAS services are needed by AmigaOS because I only bothered to implement those.

@kas1e
Quote:
The datasheet I've found (not sure it's the exact same chip) said these could take 100,000 reflash cycles so unlikely you could kill them. Maybe there's no need to desolder it before it dies to avoid damaging the board.

@kas1e
I don't know but I don't think any OF implementation is still developed since Sun and Apple stopped using it so the one from 20 years ago may still be the latest. If you try to get that ported I'd suggest to first try to reconstruct the pegasos2 ROM so you know better what to do than trying to port it right away to a different platform but maybe it's easier to port in a different way, I don't know.
The pegasos2 rom seems to have two parts: a compressed image at around 0x20000 that is called oftest_64M.rom which I think is actual SmartFirmware that you could build from the open sources maybe with some patches and a loader called PegasosII Boot Strap that first starts, inits the machine and memory and then uncompresses and starts SmartFirmware. This is the bPlan code that isn't open sourced. This also includes a low level monitor called IKARUS low level console that is entered when no memory is found. You can force that on QEMU with removing the SPD EEPROM by commenting these lines (and the variable definitions) in qemu/hw/ppc/pegasos.c::pegasos_init()

then you get

This has a helpful help command: pressing ? prints #RTFM but there's some info on this here. The output above shows what this code is doing and you can probably trace on QEMU what registers these access so to reconstruct it you'd need to reverse and reimplement it then combine with the SmartFirmware. If SmartFirmware has a compressed loader then this may be based on that with the above hardware init added. if that loader is not in SmartFirmware it may be similar to what PMON does. The most complex part is probably getting SPD data over i2c and init the memory controller based on that.
I've asked bPlan before if they could open source their part but I never got any answer from them. Genesi open sourced what they had including the full schematics that I've linked from my page about Pegasos2 emulation.

@derfs
Replying post #60 in previous page.
In QEMU the MV64361 and Articia are both emulated and don't emulate any of the floating buffer or transparency mentioned in the explanation so if that comes from an AI it's BS. It looks more likely something else is wrong. Maybe it just does not look for memory BARs at the right address as the PCI memory windows might be at different addresses on the two machines but if it found the config registers and the IO BAR it should also be able to look up the memory BAR. Maybe AmigaOS does not map these by default and BBoot or the A1 firmware did not do that either so maybe something needs to do that? Can you compare "info pci" and "info mtree" output on the two machines to see if the BAR needed is mapped and where? I think I've asked those outputs before but did not see an answer.

@joerg
Quote:
That's strange. Who maintains U-Boot now? I once asked about it and was told that the sources for AmigaOne XE U-Boot used to be in some Hyperion CVS that's no longer up for a long time and it wasn't migrated to what they have now so maybe it's only in some archives that nobody seems to know where it is. It was probably never fully upstreamed to U-Boot, the parts that were there are for an older G3 based SE board anyway. I've tried and could compile that but it does not work for XE and missing a lot of parts anyway. I think the Sam U-Boot versions were made based on this so @m3x might have it but when I asked here he did not reply.

Quote:
What's not working? The A1 U-Boot binary is still available from Hyperion and it works with QEMU so you can use that if you want it just does not come with QEMU because that would need to include sources as well. (Maybe the sam460ex version will be kicked from QEMU at one point too as that also does not compile with modern compilers so it's a pain for package maintianers who want to rebuild everyting from source.)

Quote:
If I understood correctly the reason for that was that they wanted to stay on the same kernel version for all plarforms and they could not update X5000 beyond one point due to some unfixed issue in more recent versions so they could only advance until that which also happens to be before the PCI fixes for pegasos2 but it wasn't intentional but more due to being unable to fix something else that held things back. Maybe they can resolve that and release it in some future update.
Quote:Wasn't it that the recent agreement about not continuing to sue each other allows Hyperion to make elecronical versions for download possible? Then this could be resolved too.

@kas1e
If you're lucky and the method implementations call into some high level block device layer and not in low level drivers directly they could work for USB too unless this is the API layer that different devices have to implement in a device specific way. But if CFE can load stuff from USB there's somewhere an implementation for these that only need to be hooked to the device tree methods.

@kas1e
Problem with U-Boot is that X1000 and PegasosII versions of AmigaOS expect OpenFirmware, they use rtas to access PCI and other things that you'd either need to emulate on U-Boot in a boot loader replacing amigaboot.of or need a new kernel that works with U-Boot. Porting SmartFirmware would give the OF environment so no change needed in the OS. (Also other OSes expect OF on these machines so they won't boot on your U-Boot but could on an OF implementation.) The AmigaOS specific U-Boot hacks are also a mess that need to be ported to recent U-Boot versions so maybe the OF is better at least using some official API of the firmware not AmigaOS specific patches not in upstream. The porting is about the same work for any firmware as you'd need platform specific init and drivers so no difference in that.

@kas1e
I doubt that was Hyperion that hacked an OpenFirmware implementation on top of CFE because they had U-Boot on other machines so they had to change amigaboot and kernel to work with OpenFirmware (then after that was done for X1000 they could also support Pegasos2 as that hardware is similar to AmigaOne but with OF). Instead it was likely PAsemi who did that because they wanted to make a PPC chip that can boot MacOS which needs OpenFirmware but they had CFE so probably added an OF compatibility on top. This is just a guess but sounds plausible.
That the /options node lists env vars does not mean you can change the devtree. It's easy to implement /options to provide the env vars on access but that does not mean CFE has other device tree manipulation implemented. But if it supports interpret from the client interface (as amigaboot.of uses that) then you could try sending commands over that that create a device tree node or set properties and see if that works. It could be CFE does not have a full Forth interpreter and it just emulates the interpret calls the boot loaders use (as I've done once in VOF for interpret mem-alloc to make amigaboot.of go further but then it sent more interpret commands to read the disks which would have been harder to emulate).
At this point it may be easier to replace amigaboot.of with something or look at porting some other firmware to X1000 if you can recover the initial hardware init from CFE.bin and reimplement that in real OpenFirmware as in: AIX/PReP under QEMU How-To (source) but this needs Forth which might be a barrier to most but if you want a challenge it definitely is; or SmartFirmware which then you could also use to do the same on PegasosII and free the firmware of that machine as well. So instead of patching CFE you could try to get the hardware init that sets up memory controller and PCI buses and devices and hack that in SmartFirmware and see if you can get a working OF that way then AmigaOS and its bootloader might not need changes and still work. This looks more likely than porting U-Boot which would need a different kernel or emulating OF on top of U-Boot.
But if somebody still has the CFE sources that would be the most helpful. PAsemi was bought by Apple and they have no use for this firmware so if you can find a contact maybe you can ask if they still have it somewhere. Not likely they answer but maybe they do and then you at least have the hardware init to make a new firmware. Was the PAsemi CFE open source? How did AEon/Hyperion got it to modify it? Looks like it was part of the SDK described here. Does somebody still have a copy of that SDK? Even if the whole SDK is not free the CFE sources might be so could be distributed.