@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.

@kas1e
Debug level is still too low. Try with debuglevel=7 where [ScanController] messages appear with info about reading PCI info about cards. Maybe there's some info there about what's happening. From these logs it only looks like it finds the bridge but does not go down on it, only checks bus 0 and 2 but not 1 that's behind the bridge. I don't know why though.

@Maijestro
Quote:
It should be about the same if the same thing has been run in the guest when you collect these statistics so if you always do the same and get the stats at the same point then difference shows something if they are from runs where different things happened since starting QEMU then they don't show anything.

PPC interrupt 8 is syscall when guest executes sc instruction which is done when something is calling AmigaOS services so maybe something is running in guest that does more stuff sometimes? Is there some task manager where you can check what task is using CPU time and compare that?

@geennaam
Quote:

Does the card connected to the bridge show up in Ranger just missing BARs? If so it's probably a problem with 64 bit BARs. If it does not even show up then it's a problem with bridge. The AmigaOS log would give some more details on this with high enough log level. I've found the max you can go is 9, above that it would crash on bad debug code but maybe less is enough to get logs about device scanning as in higher levels memory management logs are too verbose and make too much noise. Experiment to find a level that doesn't have too much logs but still show [ScanDevice} messages.

Quote:

It's unlikely to be a power problem if the Driver doesn't even talk to the card. One other thins that could cause problem if the card ROM needs to run and I'm not sure pegasos2 firmware does that for cards behind a bridge but I also don't know how to find that out. If you connect the card to QEMU with pass through and get errors from firmware when running BIOS then if you connect the same card on real pegasosII with briege I think you should see the same errors so that could confirm if the BIOS runs or not.

@geennaam, @kas1e
You're trying to find problems with omitting important information so it's hard to debug this way. We now have BBoot and firmware output from real pegasos2 and found that pegasos2 firmware sees the card but we also know that pegaosos2 AmigaOS kernel won't see 64 bit bars so BBoot tries to change those to 32 bit BARs (this is when you get Truncared 64 bit BAR message). BBoot currently doesn't go down in the bridge so it won't do that for the card behind the brige, I'll need to find out how to do that. To see what AmigaOS sees from all this a debug log with kernel.debug and some higher loglevel where the [ScanDevice] or what it's called messages are logged could help to see where it fails.

@geennaam just posts way too little info to even follow what happens. I'm not even sure which cards he's testing and if they work or not so I'll just let you figure this out alone unless you can give more details. The difference in that case is if you boot with -kernel bboot then bboot will configure PCI devices so it will assign addresses and fix BARs itself and additionally it will also fix unset interrupts. All these fixes are logged in the BBoot output but since you haven't posted those I can't tell what it did. BBoot still could not handle a bridge in this config but since you're only passing through the card and not the bridge it also does not have to as the bridge is handled on the host. To get the same config as @kas1e one could pass through the bridge and use -bios pegasos2 firmware which would emulate what happens on real hardware more closely. Doing that and getting info mtree and info pci after AmigaOS boots might give some more info on what's set up and what may be missing.

I hope tha above makes sense, please read it multiple times if not clear for the first read as I don't have time to explain it in more detail. I'll look at extending BBoot to handle bridges but that would take a while.

@geennaam
On pegasos2 ultimately everything uses the ISA IRQ 9 and PCI INT pins are handled within PCI bus emulation so they are also shared. The pci.1 and pci.0 are separate buses so they have different PCI bus emulation but I think they PCI interrupts are connected to vt8231 PINT inpits which is then uses the PCI interrupt handler of the PCI bus the VT8231 is connected to that is pci.1 even for devices on pci.0 which may or may not be a problem. I also don't fully understand how this works in QEMU and this may have problems. I had may patch originally track each interrupt source separately but testing by Martin found it made no difference regarding freeze so that maybe caused by something else.

@MartinW
You'd need GNU make, maybe try gmake if make is a BSD make, I may be using some GNU extensions. For the library that's probably 64 bit but BBoot is 32 bit so needs corresponding libgcc. In makefile I have: powerpc64-linux-gnu-gcc -print-file-name=32 because in /usr/lib/gcc I have a libgcc.a for 64bit but there's a subdir called 32 with 32 bit versions of the same. If your distro packages it differently you may need to adjust it or it may have a different package for powerpc-linux-gnu-gcc instead of powerpc64 that contains the 32 bit version.

@geennaam
Good to hear it works. Having BBoot output from where it works would still be good to at least know what settings work and what don't.
The problem with resetting the card is independent of AmigaOS or BBoot or any of my code so can't help with that but I guess this may have something to do with the VGA part of the card being used by something. You should make sure your BIOS does not try to use the card and no driver is loaded for it in Linux. There were some mentions of vga arbitration and some patches needed for ATI cards somewhere but I may be completely wrong about this so try to search for and check info on this. The same problem happens when someone passes through GPU for Windows guest so I think there's some info on that somewhere.

@Maijestro
If in doubt read documentation: https://www.qemu.org/docs/master/system/monitor.html

Just type info jit or info irq in QEMU monitor. You can redirect the monitor to stdout with -monitor stdio in which case leave out -serial stdio or you can use -serial mon:stdio to multiplex both on the same window.

Your scren shot is not readable at all, it's two low resolution and your color scheme does not help either so can't somment on that.

Also apparently this problem of using graphics cards connected with a bridge was already solved in MoprhOS according to this thread:

https://morph.zone/modules/newbb_plus/ ... d=1215&forum=11&start=175

so that could help checking if the problem is with pass through, the bridge or AmigaOS. When you think you have a working setup with a card that MorphOS should support, preferably one that was tested in above thread (These are probably only some HD cards) then try with the MorphOS demo iso to see if that works which then mean it's probably something missing from AmigaOS that we might be able to patch up in BBoot or if it does not work then maybe it's somehting with the bridge or QEMU or your host setup that needs to be solved.

@geennaam
That's not enough info to see whu it fails. At least the BBoot output would also be needed. Other than that the error tells you where in QEMU source it failed: qemu/hw/pci/pcie.c line 92 so you could try to find out what does that do why it might not work. Likely getting unexpected values from where it's called and from where it's called can be found from a back trace that you can get with gdb either running QEMU under gdb or enabling coredumps with ulimit then analyse it with gdb after the crash. I can't tell any more from that error alone.

@Maijestro
info irq and info jit are QEMU monitor commands that print statistics about how many interrupts or events during jit happened that could impact performance. You should do about the same thing once when it's fast and once when it's slow and after the same code has been run in the guest check the stats to see if there's a difference that could show where the slowness could come from.