@afxgroup
I can't help woth that but there should be examples on line on how to use the e500 machine so you should be able to search and find onw. Of course you'd need to emulate something that the guest has drivers for so it amy depend on the guest you're trying to run.

Also the sources fot the included U-boot-e500 firmware is in qemu/roms/u-boot so you may check what config it uses to find out what it shoulc support. If the dir is empty look at git submodule and to build it see qemu/roms/Makefile:

@Maijestro
I get further than that with the U-Boot menu coming up and also loading and starting Linux so maybe check that the U-Boot image is correct. It's just the last 512KB of the update.image binary that can be cut as described in the comment in qemu/hw/ppc/amigaone.c.
You can just use -bios path/to/u-boot-amigaone.bin without -L the 0L is only needed if you need other rom images that come with QEMU but it does not find it. I never needed to use that as it finds that if you run from the build dir.

The correct u-boot-amigaone.bin should have MD5 sum: 36d9f14f05ff5d539cc56844ff1f5d25

@Maijestro
I've tried that Linux image but it does not boot yet. It seems to look for something at

repeating this endlessly but I don't know what should be there. The answer for this is somewhere in the Linux source but I have not found it yet.

@jap
No those are downloadable but don't contain the low level info I'd need. What would help is developer docs for the Articia S chip with register documentation or some knowledge about how it maps memory spaces as currenlty I see sofware trying to access memory at random locations where things don't appear but I think maybe programming Artivia regs could map these there but I don't know how that works so don't know what to emulate. I've figured that PCI host config reg 0x56 should map nvram but we don't emulate that but the cdrom driver pokes this reg a lot that generates logs that makes debugging more difficult so I have to filter these out.

So what would help are docs on Articia (already have docs for VIA chips so don't need those) and the u-boot source of an actual version that matches a binary known to work on the real machine. (If we can't find that I'll have to replace it with the sam460ex version adding the now removed AmigaOne pieces from upstream U-boot so I can get around this but it would be helpful to test with a firmware that was working on the real machine to ensure it's correctly emulated. We'll need some firmware source to include the firmware in QEMU eventually as GPL binaries withohut source cannot be distributed.)

I've finxed the IDE ports (not final only a hack now but gets around the problem at least for the firmware) so now if somebody have an AmigaOS CD for AmigaOne it might even try to boot. I'm not sure it would also work but unless somebody tries I'll never know so this is all I could do for now. To try it clone the repo from above, checkout amigaone branch, build --target-list=ppc-softmmu config as usual then try qemu-system-ppc -M amigaone and you also need -device VGA,romfile=VGABIOS-lgpl-latest.bin to avoid the bios emulator in u-boot to crash and get picture but for AmigaOS you'd need to do the same as for pegasos2 and add siliconmotion502.driver and also add -device sm501. You can use this guide for that:
http://zero.eik.bme.hu/~balaton/qemu/amiga/aos_pegasos2.html to prepare a boot disk. This now depends on you to test and tell me what it does then I can try to improve it but can't test it in detail myself and also would like to encourage others to at least share info on how to make this better. If you want to see all th emissing stuff add -d unimp,guest_errors which lists a lot of things and of those I don't even know what should most be. (I know port 0x80 which is for debugging only so should not be an issue and the access to the nvram at the beginning at something 0xed... which is not yet emulated for any of these machines). If you know the rest you can help to share knowledge or implement it and send patches. If this does something and seem to be at least minimally working I'll clean it up and may try to submit for QEMU 8.2 but we have time for that. I maybe try a Linux image sometimes and if at least that boots then there's a chance it can get upstream sometimes in the future but would need cleanup of the via ide stuff.

@smarkusg
You have two machine options in that command line (-M is synonym for -machine). I wonder why it did not give an error but one of those should be enough.

@joerg
I guess that would be 3 years instead of 2 for GPL but it's older than that too. Anyway Does somebody have AmigaOne firmware images that are known to work and maybe the source for them too? I think @sailor wrote about newer versions than the 1.1.1 that's available officially. I can try to rebuild it from older U-Boot releases but I'd rather start from something known to work on real machine first. I guess for now I have the next issue to solve is the ide emulation but if somebody wants to try if any of the network cards work with the firmware and it could netboot or if the USB emulatoin works with USB storge those could be tested. I won't have time to try those any time soon.

@joerg
Is that compatible with any of these?

qemu-system-ppc -device help

Storage devices:
name "am53c974", bus PCI, desc "AMD Am53c974 PCscsi-PCI SCSI adapter"
name "dc390", bus PCI, desc "Tekram DC-390 SCSI adapter"
name "lsi53c810", bus PCI
name "lsi53c895a", bus PCI, alias "lsi"

I think the AmigaOne ROM listed 1000:000f PCI ID but I did not find that in QEMU, it has

so 000f is not there but if it's close to one of the above it may be tried to emulate that.

@Maijestro
If AmigaOS does not have a driver for virtio-scsi then how could it see disks attached to that? The AmigaOne firmware printed scsi not found with a vendor/device id of an LSI scsi contoller but QEMU emulates a somewhat newer version of that so probably it won't work unless one of the emulated scsi controllers in QEMU matches a driver in AmigaOS.

For guests that have virtio drivers maybe using virtio-blk is better as it has less legacy stuff, only pure virtio which should be the fastest and simplest. For AmigaOS that's the same as for virtio-gpu and virtio-net: drivers need to be written.

@Maijestro
Quote:

Sure it would have the same problems with only sm501 emulated as pegasos2 or sam460ex plus maybe some more due to not emulating amigaone hardware correctly yet. I did not have time to write more about it but currently only a single pci bus is emulated, the bridge does nothing and most of the articia functions are also missing but this may not be a problem if AmigaOS does not change or use them then it's enough to emulate it the way the firmware puts it for AmigaOS to be able to boot. Later this can be enhanced if necessary,

What is the advantage then? More people could use it and you won't need 3 versions of AmigaOS but if you have either Pegasos2, Sam460ex or AmigaOne version then it should be usable. If there were really more AmigaOne users than the others then maybe more people have the CD laying around so they could do something with it now. Also having different firmware we can cross check if a problem is found if it happens with one machine or both so we can know if it's something with the emulation or only one machine behaves differently. Also gfx cards are known to work with AmigaOne so if they can be made working with pass through then we know the pegasos2 version may be different. It just adds more options to allow more people to use it and since the code is mostly shared between pegasos2 and amigaone it's not too difficult to support both. Only the system controller is different Marvell Discovery vs. Mai Articia but the via chips are very similar and already share a lot of code in QEMU so there's not much to write to add support for amigaone as well.

Before somebody comes up with the idea, not X1000 and X5000 won't be emulated (unless somebody wants to do the work but I don't plan to) becuase those have very different hardware so other than PPC emulation probably not much could be reused so it would be too much work unlike adding amigaone based on existing code.

Of course in emulation we would not have any of the problems with hardware bugs so even if it was problematic on real hardware it could still work with QEMU. For the ide problem I think I know what it is, the firmware seems to try to use the IDE controller in VIA chip in legacy mode but that's not emulated in QEMU because everything else seems to use PCI mode with BARs so only that's emulated. The device should start with BARs mapped to legacy ports but looks like nothing is enabling the device so it does not show up. I'll try to fix this and see if that works and we can think of emulating legacy mode later. This was considered before but the problem is that legacy mode is using ISA and ISA emulation in QEMU is very old code so it's either ISA or PCI but switching between the two like the VIA chip allows is not easy to implement and I did not want to rewrite the ISA code for that. Maybe there were some chnages for this since then when I've looked at it for pegasos2 a few years ago so eventually this can be fixed or hacked around somehow if only legacy mode is needed for amigaone.

Also I'm not sure what I should see so maybe I'll need to search for some videos showing how real AmgiaOne behaved on booting. I just wanted to make sure that the on board IDE worked at all and I don't get anything recognised because of not emulating it correctly before I try to debug something that's supposed to be broken even on real hardware.

Thanks for bringing this into a new thread, hope this will become useful for some eventually.

@joerg
Quote:

After reading @sailor's excellent article about AmigaOne XE I realised that it's basically the same machine as pegasos1 which is the same as pegasos2, even the memory layout is very similar so it would not be too difficult to emulate it as well because except the Articia-S everything else is already there (at least more or less as there are missing parts in the VIA stuff but it was shown enough to run AmigaOS). So I did an experiment to see how much work would it be.

The problem is that there's no technical info available on the net about these machines other than marketing text these seem to be completely vanished or was never publicly available. I could not even find a Linux or AmigaOS boot log or anything like that which were still available for PegasosII. The firmware is downloadable from Hyperion but the source is not there (this may be a GPL violation, I've tried writing them but the address in the README is not working any more either). Anyway it was once upstream in U-Boot so found the commit that removed it which conveniently lists all changes related to AmigaOne that has at least some info. I still had to guess most of the Articia stuff from U-Boot and Linux sources so maybe I did not get that right and surely a lot is missing but I managed to write an emulation that boots to the firmware but then does not seem to find IDE to boot from (also I don't have AmigaOne version of AmigaOS so I would not be able to try anyway). The firmware pathces to U-Boot had comments about IDE not working so I'm not sure it ever worked on real machine, I've found info that due to to some early problems they used a SiliconImage IDE card instead (but not the SII3112 that QEMU already has for sam460ex so not sure it would work with that). So for now it just a proof of concept and up for interested people to experiment and find out how to make it a more complete emulation that could boot something but it's your chance to prove that there is more expertise around for AmigaOne than Pegasos2. As these mostly share the same components improving any of the two would also help the other so hopefully this will let more people to join and have fun.

I've uploaded what I have at https://osdn.net/projects/qmiga/scm/git/qemu/summary in the amigaone branch, do git checkout amigaone after cloning that repo and build as usual. Also see comments in hw/ppc/amigaone.c about vgabios and how to get firmware. See also https://osdn.net/projects/qmiga/wiki/DeveloperTips

So those with a real AmigaOne could try what works and what doesn't and give us more info about how it works on real machine as this is all I could find out and there seem to be no more info found by search engines.

@smarkusg
About donations, to quote from the same place you quoted it also says:
"I will work on what I like. I'd like this to become a collaborative effort so If you want some new feature or improvements then a better way is to start contributing to the project"
So donations won't change what I work on (I may still find something else more interesting and rather do that) but donations are appreciated of course so it's there if you think it's the best way to give a thanks but I'm also happy if people contribute their time to make this better so not all progress depends on me alone.

As for what I've found more interesting in tha past days than BBoot I'll say in the next post.

@MartinW
Quote:
There's no point in worrying about that. That would enable io a mem BARs which the host bridge that's 0:0.0 does not have and enable bus master which it does not need so while QEMU enables those it's not needed but does not hurt either ao it just results in different value but nothing else.

What I was thinking about if the cache line size could have somehting to do with slowness. This was suggested in @sailor's articles I think but I did not add this value to BBoot log and did not try to chnage it. If you have a cart that works but slow you could check this number in Ranger or in pegasos2 firmware and could try setting it. OF course if it doesn't even work yet that won't help.


Quote:

With latest BBoot version the readme should explain how to use it and bboot.fth should set these numbers automatically so you probably tried to boot hd:0 bboot instead of hd:0 bboot.fth on pegsasos2.rom (and you'll need the Kickstart.zip at the same place on hd:0 on a partition that the pegasos2 firmware can read so probably FFS file system.)

I also got to the same conclusion as @Hans that maybe if BBoot would move the device bekind the bridge to one level up to be at the same level as the bridge (and then fix up 64 bit BARs) then maybe the pegasos2 AmigaOS kernel might find it. But I don't have time to try that now so either wait until I get to that or the source is open so anybody can attempt to change it to do that.

(If you have a patch for BBoot I'd appreciate if you can send it to me so I can merge it and keep one up to date release with all the chnages just to make user's life easier so they don't have to follow a lot of forks.)

@sailor:

https://osdn.net/projects/qmiga/wiki/SubprojectBBoot

unfortunately OSDN is dying lately so here's an alternative download link that should work:

http://zero.eik.bme.hu/~balaton/amiga/bboot/

@MartinW

I'll look at the numbers when I have time sometimes but I think even without that I can guess some things. The difference in comand reg 0 vs. 7 is just how QEMU inits that value with VOF is different from what the firmware does but since the host bridge has no resources (BARs) it does not matter. I can change that in QEMU 8.2 after the freeze, I did not send a patch for 8.1 because this should not matter.

If it works with pegasos2.rom but not with -kernel bboot even though the numbers are the same then it's probably that pegasos2.rom runs the card's BIOS ROM but nothing in QEMU/VOF/BBoot will do that so ig that's needed then whatever that does should be replicated somewhere. If running the BIOS ROM is needed then you're stuck with pegasos2.rom but can still use bboot with pegasos2.rom through bboot.fth although probably not much useful other than getting the numbers printout or to fix 64 bit BARs without needing a Forth script for that.

Edit: There's a hardware compatibility list on MorphOS download page in a link at the top. That lists the hardware it should work with and what level of support it has for them. Probably only works with older HD cards.
If you've found problems with building bboot on AmigaOS you could let me know so I can try to fix it. Since this is AmigaOS related it's not unlikely somebody may try to use the AmigaOS SDK to compile it so making that easy might be useful. If you don't want to spam the thread with that you can send me via email or PM.

@joerg

That would be enough as one can start top at boot from WBStartup or startup-sequence or similar then leave it running to collect CPU time from boot. Then hopefully running the same things might show some difference to find which task may have something to do with this. If there's no difference then it's probably not a user program but something lower level. Measuring user/supervisor transitions could be checked if it correlates with syscall exceptions in info irq too.

@kas1e
It's not related that BBoot scns the bus and AmigaOS kernel scans it these just both seem to have the same issue to only consider the two top level PCI buses and not expect a lower level bridgw. Fising this in BBoot would print info and change 64bit BARs of the attached PCIe card but if then AmigaOS kernel does not read that info it won't fix it. Maybe we'd also need to make some other changes but that might be difficult or disable the AGP port if we move the info about the bridge there so it would be hard to debug but maybe still possible over serial. Also I can't test it so not sure yet how can I do this but did not have time to look at it in more detail yet.

I think on the AmigaOne XE this bridge also did not work but the other one did so maybe we'll have better luck with that. I think all the info needed can be gathered in one lot if you do dump-all then boot with BBoot with debug kernel and loglevel=7. I already have these for this bridge so only will be needed for the other bridge but then you can get it in one go and don't have to send different logs.

@joerg
Then how could @geennam use a passed through PCIe card?

@joerg
The millions of sc exceptions do come from somwhere so even if no apps use this somthing in the kernel definitely does and not even rarely.

Top would probably help if it lists cumulative CPU time from boot like under Unix.