What the fastest possible x64 emulation way of OS4 today ?

Looks like internet search engines remember my stuff more than I do. I've found this that I've done before:
https://mail.coreboot.org/hyperkitty/l ... PJOVMGZPMRNZFOX56SFUCPLX/
Look at pci-map-in which likely has parts that we need to decode the property values but I haven't tried.

Was about to say that i've just grasped the encoding. You supply 3 unencoded ints (hi, med and lo to encode-phys and you're left with an address and length on the stack.

I'll have a look at what you just posted.

@MartinW
The OF PCI binding doc has examples of how these values for reg and assigned-addresses should look like. You-d get 3 phys vlaues and two size values for each bar so to decode them you need one decode-phys and two decode-int's but I'm not sure about the order. The value that has the space code and needs to be modified is phys.hi which may be the first or last returned by decode-phys. I also don't know more without experimenting.

@balaton

That sounds like a plan. I was going through my sources from when I was hacking with CFE to see what it put in registers when calling a binary. The result must be somewhere else as I didn't find any info extracted. However, what is important is the OF hook, as any boot loader can disregard anything else and the OF hook the core point from which it operates.

The only other important info would be the address range it needs to run in. I was disassembling the Pegasos amigaboot.of, or as I called it, pegaboot, and it first relocates itself before launching. I'd need to check the asm. It was something like $200000. Without it, at least on the X1000 to where it needs to be, interfacing with OF will simply not work. In my case it refused to print anything on screen when using OF write routines.

Now, if you are going to write a replacement for amigaboot.of, it will take time. So, you would want this to be a last resort, since it means it's non standard if the intention was better OS4 emulation. But, given was it does is load in files from combined file lists and send the result to a loader, that may save from some nitty gritty being the job of the loader is to process a list, link it all and launch it where it needs to be.

@balaton

I really need to pay more attention! I spent hours last night banging my head against a wall because I couldn't work out how to open the device properly. Every time I tried to access the properies it would hang. I just noticed you posted the code to do so back at #642. I feel proper stupid now!!

So I wil have another look later now that I have that.

I also just found that if you go to /pci and issue show-pci-full you get a far more human readable output. This isn't the full output and the 64bit device here is the USB controller I used on my M1 Mac just for testing:

OK, now we're talking - I'm getting the right values out now. I just need to work out how to replace the array and I can manually fudge up a test. Tonight hopefully...

Common Martin, i refresh every hour amigans.net hoping to have a "yeaah!" from you saying that you were able to deal with ! :)

Lol! Sorry, got to work too you know :D

This is still just a simple test

Before:


After:


What you're seeing here is, I've (manually) decoded the single entry in "assigned-addresses", modified the low 32bits to 0x84204111 instead of 0x84204000 and put it back in it's place.

So now I need to work out how to do it for multiple addresses and also the reg. Or at least I think I need to do the reg.

I don't know how to wrap it all up in a script just yet but given I didn't know anything about PCI or Forth until this week, one step at a time!!

[edit] And just to be clear, yes, I know those aren't the bits I'm meant to be flipping, I'm just messing right now.

OK, I guess I know how to add multiple address ranges (bars?) then.

@balaton
do I need to flip the 64bit entries in the reg too or just the assigned addresses?

@MartinW

Well, things are typical addresses do not have odd values, its typical aligned by 2, 4 or 8.

So bit0 is allways 0, or bit0 and bit1 is allways 0, or bit0, bit1 and bit3 is allways 0. (Depending on alignment)
so this should not be flipped.

I think you messed it up. Also modern computer use pages memory, address space is only available to the program when its assigned to a PCI card.

the driver will ask for access, it will then give a IO space, and address space, then it give it up when it’s not needed, so address space can be used for something else.

IO controller will need to be able to take request from the guest OS, and pass it to host, get what it as and translate into quest hardware emulation somehow, transparently.

@LiveForIt

Quote:

You can safely ignore the numbers there they are utterly meaningless, that was just me working out the forth syntax to modify the array which I've now done.

For the record, I'm really not convinced this is going to work, but sometime shortly we'll have the answer to that

[EDIT] Actually, looking at the numbers I have in front of me, I can see why we're at least testing it because on this older video card, even though the bars are being probed as 64bit all the numbers are within the first 32bit, so yeah, maybe. On my RX580, the ranges spanned the 32bit boundary and were actually 64bit numbers so in that instance I don't really see how it would physically work, I mean, the memory regions and the registers have to actually be where we're saying they are don't they?

But honestly, don't take my word for it.

@MartinW

In emulators I have worked with (Basilisk and EUAE), (it might not work like this on QEMU).

its like this memory map is allocated in host OS, so its at a offset.

So address 0x00000000 in the guest can be at 0x00A0A0A0 in host (where it was allocated).
So translate a guest address to host I add 0x00A0A0A0 to address.
To translate a host address to guest OS I simply subtract 0x00A0A0A0 to address.

The guest OS registers are always operating with virtual addresses, not real addresses.

Quote:

well, I don't think it matters, if you add and substract a 64bit offset or 32bit offset,
to get host address, it should not matter. If ends up at the correct address at end of the day, it should work.

if you come up with something more interesting like:
hostAddress64 = toHostUpper[ guestAddress32 >> 16 ] + (guestAddress32 & 0xFFFF)

The question is how complicated the mapping to allow it mapped to host, perhaps is some kind of function table that does the address translation. like EUAE does (it does this becouse it emulates hardware)

Basilisk does not need to, as ROM is patched, and it does not emulate hardware.

Or maybe something more modern and exotic.

At the moment all I'm doing is attempting to address the 32 vs 64bit as mentioned here: #630

So with my script, I can now boot and I know the system is booted because I can see alsa errors where I would expect to hear sound if my alsa setup worked on this computer (something for another time), but as you can tell, I don't have a picture on the screen.

But I think this now looks reasonable:



Thats the same as before the script but with the 64bit flag not set.

@MartinW
Great progress and promising fesults. Learining Forth in a few days is really great thing, it's simple but can be challenging to use so it's always takes some effort. I can't tell if both reg and assigned-addresses are needed, this depends on what the OS and drivers look for but since their format is the same and the bits to flip are at the same place then if you can change on you can change both just run the same operation wiht different property name. As far as I know the reg property defines what BARs the card has, it jost describes their type and length but has no addresses. The reg property is for the firmware to know what resources a card has. The assigned-addresses property is then added by the firmare when it maps the BARs and I'd expect thtat this is what the DS checks if it does not do its own mapping but relies on what the firmware did but I don't know what AmigaOS does. Yes it may only work if the addresses fit in the memory windows so the OS can read/write them but if the large BAR is the video RAM it may still see part of the memory so don't know what happens in that case. First step would just be to change the BARs to 32 bit and see if AmigaOS sees the BARs then. If that does not make it work we can investigate furhter.

@LiveForIt
There are no host addresses involved here, those are only present for QEMU but the guest does not know about them and does not have to know. What the pegasos2 firmware sees is the same as running on a real machine (except some parts are missing as they are not emulated) so it only sees guest addresses. The problem is that pegasos2 has a 32bit address space and some ot is is reserved to map PCI devices. If the BARs are larger and don't fit in these windows the OS won't see them or only partially see them. It does not matter that the host is 64bit and can map the card, it just passes through the card to the guest and the guest has to handle the large BARs somewhere within its address space. The pegasos2 firmware at least recognises 64bit BRAs but AmigaOS does not like them so these are missing after boot so the video card driver can't talk to the card. There's some evidence that on other real machines these work when the 64bit BARs are declared as 32bit ignoring the top of them so this is what we'd like to try with the pegasos2. It does not matter for this that it's running on an emulator, connecting such a card with a PCIe to PCI bridge to a real pegasos2 would get the same result.

@all
While you experimenting on QEMU side, i want give a go on real pegasos2 with real PCI->PCIe bridge. Did anyone maybe have any model number which were tested at least on other amigang machines and works ?

@Martin
If you can, share plz what you have now (the script i mean)

@kas1e

Unfortunately, at this point it's not a script as such so not going to be a lot of use to anyone else, I've basically typed in forth commands at the Open Firmware prompt to get it to spit out the numbers, pasted them into a code editor, modified the relevant bits and then added Forth commands to push them back in in their modified form.

If this were to work then we can look at scripting it. But with my lack of Forth knowledge that's not going to happen overnight.

Anyway, without comments:



This is exactly the same but with all the raw numbers in comments

Did not follow the entire discussion, but tried to keep on track.
So is there maybe a chance to get more modern ATI Radeon cards to work on Peg2?

@MartinW
Great so what if you enable debug logs with os4_commandline as was mentined in this thread before. Do you get some errors from the OS scanning cards or the gfx card driver? Can you boot with sm501 and the passed through card so you can check if the BARs now show up?
Or if you can't get picture but there's a command from the shell to list these infos you could run that from startup-sequence redirecting to SER: to get output on serial.

Also check info mtree and info pci or info qtree after booting to see if the card is actually mapped. It may be that SmartFirmware assigned addresses but did not map this or AmigaOS tried to map it but wrote the wrong BAR. I think for 64bit BARs two registers are used so instead of BAR0 and BAR1 you just have BAR0 using both 0x10 and 0x14 config regs and I'm not sure which of these should be written to set a 32 bit address. It could be that it should go on 0x14 although PCI is little endian so maybe it should be in 0x10 but I don't know. In short I think if the BARs now show up in AmigaOS then check that they are also programmed so that the card resources actually show up in info mtree where the values say it should be. If it doesn't and AmigaOS don't map these then the script may need to also store the right values to the BARs, look at config-l! for that.