Sure, at the moment we don't know for sure on GPU passthrough if the register addresses (I think that's what we're talking about, I know which addresses I mean in the output / code anyway) should be left undefined as they appear to be on real Pegasos2, whether the IRQ's should be mapped when they are unassigned by firmware and so on.
Dunno if you check thread about real pegasos2-with-bridge, but i find out, that morphos kernel, do see both bridge, and RadeonHD in, and, RadeonHD in both audio and video parts sitting on IRQ#9, too. Even being on BUS#1 of PCI0 line.
It doesn't happen with pegasos2.rom either, only with bboot. So this was why I was trying to find out what was different between the two but it doesn't appear to be anything that's obvious from the printed output.
If I use the old method of pegasos2 rom with my manual fixes I can boot and use OS4 normally albeit it with Interrupt=No in the HD driver. It's slow however so something isn't right.
@kas1e
So this means that what we're doing should really work, yes? I didn't try morphos. I could do, but so far it has never been happy with the card whichever method I use.
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.
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.
It also didn't help when I added a bit of code to set the command to 0 for 0:0.0 - so I'm not sure there's a huge amount of point in worrying about it.
The Bios would be my suspicion too. We know it tries to process it on the RX cards because it fails and causes errors. The HD card I have it doesn't throw an error so must be getting to the end of the ROM.
There's definitely mileage in still using bboot if it can patch the 64 bit BARs. That's a pain to do manually. So far I was not able to get it to boot using bboot with the pegasos2 rom. It would fail to find initrd start. Maybe I've done something wrong in my zip file. I haven't debugged it yet.
I'll message you this evening. The changes weren't anything major. One missing file (missing from OS4), one tiny code change and one linker change.
] It also didn't help when I added a bit of code to set the command to 0 for 0:0.0 - so I'm not sure there's a huge amount of point in worrying about it.
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:
There's definitely mileage in still using bboot if it can patch the 64 bit BARs. That's a pain to do manually. So far I was not able to get it to boot using bboot with the pegasos2 rom. It would fail to find initrd start. Maybe I've done something wrong in my zip file. I haven't debugged it yet.
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.)
If running the BIOS ROM is needed then you're stuck with pegasos2.rom
Running the gfx card x86 BIOS ROM with the firmware x86 emulator is required for nearly all gfx cards, only very few AmigaOS 4.x gfx drivers like Voodoo3, maybe Permedia2 and Cirrus as well, don't need it. The AmigaOS 4.x version for classic Amigas includes an own x86 emulator which executes the gfx card BIOS since there is no firmware, but AFAIK that x86 emulator isn't included in any other version of AmigaOS 4.x.
@LiveForIt Sorry, I don't know anything about the Radeon HD and RX drivers, but the old ATIRadeon driver definitely couldn't work without executing the x86 BIOS ROM.
But it's not related to fast reboots, maybe it's executed on each fast reboot on classic Amigas, but on AmigaOne, Sam4x0, etc. the x86 BIOS of cards supported by the ATIRadeon driver is only executed once by the firmware.
The classic Amiga x86 emulator is a separate kickstart module, x86emu.resource or something like that. But I don't know what, if anything, happens if you have a classic Amiga version of AmigaOS 4.x as well and add it from there to the kickstart/kicklayout of other AmigaOS 4.x versions.
Edited by joerg on 2023/7/27 16:55:50 Edited by joerg on 2023/7/27 16:57:16
AmigaOS would examine the device tree for some things but generally the Kick modules provide specific drivers for those machines. So they would expect Exec and Expansion to have it all mapped out. Things like PCI devices should be found on the device tree but I don't know the internals of what the OS is doing to go missing.
By the sounds of it, with client interface, DTB and RTAS provisions VOF already provides a of what is needed. PPC Linux has forth scripts so if it can execute that to boot Linux on Pegasos it already goes a fair way. Unless it only has boot script and not kernel but that is out of scope for firmware.
Something like VOF may have have helped my case where a simple OF binary I created failed to work and print a message on screen. I even asked online on some OF project page if something was needed to get it working. The reply I got back was something about forth. Somehow I had failed to specify that I was compiling a binary and directly using client interface. But as it turned out nothing was technically wrong with my code, it's just how the OF hack in the X1000 works, where it ignores code that isn't in the special execute segment.
So as I understand it now with the machine and devices QEMU knows what it has to emulate, builds a list of devices, then resets them inside itself.
As to emulating the X1000, if it could use VOF for a fast boot, then that would beneficial in being faster than the real thing. I do realise a lot is needed for a full machine emulation. I waste a bit of time on the X1000 if it crashes and reboots while testing. That means 2 minutes before I can continue some work. My older XE is booted in 40 seconds. My X1000 is just thinking about booting at the 1 minute mark.
Most of the limitations surrounding OS4 emulation centre on Win/UAE and the hardware model. Sam breaks from this as will Pegasos emulation. This is already a superior experience. Well, aside from working out of the box, with a GUI and easy installer. The only other thing is device transparency such as USB ports and DVD drives. Plus decent graphic card support. This laptop I'm using has a Radeon chipset backup with Intel being main. Be good if QEMU could virtualise the Radeon and allow a driver inside QEMU to program it. Of course this goes from hardware emulation to hardware direct driving. But QEMU does have hypervisor support for doing it on CPU level. Would a graphic hypervisor be the next big thing for virtualization?
OS4 does have ATI drivers. At least R200 is supported. Not sure about R100. I recall a thread somewhere where someone wanted to write a driver. It wasn't easy finding the info. And became unclear as there is graphics, P96 and card APIs to use. Though right now most API's have been merged into graphics API. Don't recall what happened with it. It's just finding a source for clear and concise documentation. A lot of things in AmigaOS are possible with plenty of programs but finding how to do it with example code in one organised place is harder to come by.
BTW, I recalled issues I had with QEMU. I was emulating MorphOS on Pegasos. It kept scaling the screen. This was okay on boot but once in Ambient it was practically unusable. QEMU would not let me specify exact resolution. I'm on a laptop so really need native resolution or at least for it to display smaller at 1:1 pixels. If I could change MOS screenmode it would be fine so it worked that way. But QEMU itself would not budge in the resolution it used. It would not change. I was advised to read the docs. So I did and all I could find was that specifying display resolution was unsupported. Which I found surprising as by then QEMU was well established. I had to give up on it and use a real PPC laptop machine which fortunately I found I had left under my TV table. It was a couple of years back so maybe it's improved. IDK.
I do think the warm reboot issue is a software issue. On the same hardware, the older V3 driver can soft reboot, but the V5 cannot. My R7 250 is fine with warm reboot but won't work if I upgrade driver.
As solving it with x86 emulation. Well, that may be too slow. If it takes as long as an X1000 which takes at least 10 seconds, then a ten second delay of nothing may be too long, even if it's still shorter than a full reboot.
But, given the machine isn't fully reset, I wonder if the driver could simply blank the output. Divert it to a reserved framebuffer that is just enough to keep the graphics chip working while the OS resets itself. Perhaps even going into a monitor blanking mode if needed.
There's an exception to this. An RX card in an X1000 with the CFE disable jumper set. It can work in OS4. So the RX driver can bring it up. In this case the card firmware is not emulated on bootup. But somehow the driver is able to initialise the card. So possibly it's only needed for CFE to be visible but can work otherwise. The Radeon driver can reset the card itself then or at least to a point it is usable.
I tried in recent days Qemu with SAM460 emulation. I haven't had any major problems, but SAM460 emulation is very slow.
I decided to try it today with Pegasos 2. Unfortunately, I don't have firmware for this computer, so I wanted to use the BBoot tool. I did everything with the instructions. I use the Qemu compilation for Windows dated 22.08.2023 After that I typed the command line:
Thanks for the hint. I was using the public version 53.12 from OS4Depot, but I remembered that it wouldn't work for me even when I was emulating the SAM460. Fortunately, as a beta tester of the system, I also have access to a non-public version 53.11, which has the same featuress, and works with SAM460 emulation and it turns out that it also works with Pegasos 2 Emulation.
Thanks for the hint. I was using the public version 53.12 from OS4Depot, but I remembered that it wouldn't work for me even when I was emulating the SAM460. Fortunately, as a beta tester of the system, I also have access to a non-public version 53.11, which has the same featuress, and works with SAM460 emulation and it turns out that it also works with Pegasos 2 Emulation.
Ok perfect, they found a solution for the problem themselves. The public version 53.12 on Os4Depot does not work with the Pegasos 2/AmigaOs4.1 Install.CD/ISO from AmigaOs4.1.
The SiliconMotion.Chip 53.12 can only be used after FE Update 2 under AmigaOs4.1 for Pegasos 2, I suspect it is because of the newer kernel.
Version 53.9 (AmigaOs4.1 Update 3) on the other hand works very well with the Pegasos 2 Install ISO/CD.
You will quickly notice that the Pegasos 2 emulation is much better than the Sam460 and currently works really well.
@all
I have already included this in my installation instructions. Unfortunately the instructions are in German, but I can easily translate them into English and maybe upload them to Os4Depot or another available hoster if you are interested. The installation guide describes the way of the complete installation via Qemu Pegasos 2 BBoot and AmigaOs4.1.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
@mufa Just in case others will have the same problem. The command line has to be on one line without new lines in it or if you want to break the long line you need to use line continuation character at the end of each line except the last one which is \ on Unix/Linux and ^ on Windows.
You will quickly notice that the Pegasos 2 emulation is much better than the Sam460 and currently works really well.
The problem with sam460ex is that it's an embedded CPU that has software TLB for MMU and emulating it in QEMU seems to have some problems. In particular AmigaOS seems to use tlbwe instruction often (maybe on every task change) which then flushes all TLB entries in QEMU's softmmu that kills performance. One should look at what this instruction should do (look up in PPC BookE docs or the 440 core user manual that the 460EX also uses (there's a 460 core but the 460EX is a 440 CPU just confusingly named) then find out how it's emulated in QEMU and see if it could be improved to not flush all TLBs just the one that's written. This does not happen with G3 and G4 CPUs as those have a hardware TLB which is emulated in different code in QEMU that handles this better. This is the biggest issue, once this is fixed there may be another problem that there are more exceptions on sam460ex which may also take more time to handle. This is again related to differences in how embedded PPC CPU works. Otherwise the CPU emulation is the same so there should be no other problems, just those parts which are different between BookS and BookE CPUs.
Quote:
I have already included this in my installation instructions. Unfortunately the instructions are in German, but I can easily translate them into English and maybe upload them to Os4Depot or another available hoster if you are interested. The installation guide describes the way of the complete installation via Qemu Pegasos 2 BBoot and AmigaOs4.1.
I should update my docs to describe these better but I did not have time for that yet. Eventually I'll get there sometimes but the BBoot README should provide some info but people don't seem to read READMEs.
[quote] The installation guide describes the way of the complete installation via Qemu Pegasos 2 BBoot and AmigaOs4.1. I should update my docs to describe these better but I did not have time for that yet. Eventually I'll get there sometimes but the BBoot README should provide some info but people don't seem to read READMEs.
Qemu is very complex in the configuration, it took me as an AmigaOs "beginner" almost half a year to understand things a bit better.
How to use your bootloader is understood by most people, but it's about the whole installation Qemu Pegasos 2/BBoot AmigaOs4.1. Qemu is line based and under MacOs/Windows there are no usable gui's that could simplify it.
Of course I agree with you once you understand things, configuring under Qemu is relatively easy as many things work the same as under real hardware, you just have to tell them manually and that's what makes it so complicated at the moment. Otherwise I can only say that the people who have set up Qemu and AmigaOs4.1, especially the Pegasos 2 emulation are consistently enthusiastic, compared to WinUae/FlowerPot (MacOS).
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
