@MartinW
Quote:

I think for now it would be enough to just document what is needed and maybe an example script and it's OK if people would have to make their own scripts now. On the longer term we could do this in C instead of Forth either in my boot loader or in QEMU itself after we got rid of pegasos2.rom so unless this would be something for real pegasos2 owners a generic Forth script to patch this may not be needed. Those few people who have both a pegasos2 and a PCIe bridbe can probably write their own script. Although generating the script externally based on info from the machine might also be an option so it's up to you what you want to spend your time with. It's doable in forth and probebly not more complex than finding out how do loop works and then deciode=phys and flip the bit with AND'ing the right number with a bit mask to change the mem space as but this may take a few days to write in Forth and won't be needed later for Virtual OpenFirmware in QEMU.

@MartinW
The errors you see with the ROM is not actially from QEMU but from the BIOS emulator in the pegasos2 firmware. The driver needs the ROM as it contains tables with info about the card that it reads but may not need the ROM to actually run or maybe it just runs enough for it to get the card in a state good enough for the driver but can't set it up for text mode to get output during the firmware. This may be annoying but if it works after booting then maybe it's not a problem.

Do the network card and GPU share an interrupt? Is there a way to list that under AmigaOS? If you boot a ppc linux on pegasos2 with passed through card you could get these info with lspci -v and cat /proc/interrupts I think.

@MartinW
As for the network related freezes, if this could be debugged to find the reason it might be possible to fix but for that we would need some more info on what happens or a way to reliably reproduce it. It sounds like it may be a missing interrupt or I don't really know because all the report so far had not much more info than that it does not work but not enough details to tell why.

@LiveForIt
The pegasos2 firmware also has x86 BIOS emulator similar to the sam460ex u-boot but the one in pegasos2 seems to be older and has problems running some newer card ROMs which might be needed for init'ing the card. Unfortunately, unlike the sam460ex firmware, the pegasos2 ROM is not fully open source so we can't update the BIOS support in it only replace it. The x86 emulator in sam460ex firmware already works on PowerPC so porting to that is not needed but porting to run on pegasos2 instead of sam460ex is needed as these use different firmwares and the firmware is hardware specific so you can't use the sam460ex firmware on a pegasos2.
Anyway we have a mostly clear path to make this work, it just needs more time to work on it to make it reality.

@MartinW
Brilliant! Thank you for testing the theory and proving it. Even if it's not a user friendly way and may need people to write their own script for now just documenting what chagnes are needed could help some and we may be able to do a more user friendly script based on that or incorporate it in my boot loader once I finish that. How is it with the car ROM? Does the VGA BIOS of the HD5450 runs with tthe pegasos2 firmware without problems or it seems that's not needed as long as the BARs show up in AnimgaOS?

@MartinW
You can redirect both monitor and serial with -serial mon:stdio then try Ctrl-A h for help. Basically you can change betseen the two with Ctrl-A c. There are other options, if you don't want to type in serial you can redirect that to file or there are even options to open pipes or tcp ports so you could connect with telnet or netcat but I don't know the syntax for those, they should be in the QEMU docs.

There's also some doc on BAR values here https://wiki.osdev.org/PCI#Base_Address_Registers and if I got that right the lower part of the address goes in the second 32 bit BAR so maybe if you have BAR0 64 bit you may need to declare it as BAR1 32 bit so the OS tries to write 0x14 not 0x10 which would map the device too high (i.e. 0x9000000000000000 instead of 0x90000000) but I'm not sure what I say makes sense, I'm just guessing so check with info mtree and other info commands first.

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

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

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

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

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.

@MartinW, @geennaam
MartinW already answered that sctipt can be stored on disk so that's not a problem. Later if I finish my boot loader we could add the same there too. One could just replace the properties without reading them but would need to know the numberts to put there. SmartFirmware unhelpfully does not list the numeric values but the string representation. Both of these are documented in the OpenFirmware PCI bindings that I've cited twice above. You could manually decode the string representation shown by .properties and encode them to integers that you add with encode-phys encode-int encode+ however many times those are needed. I think each BAR has multiple numbers accordfing to #address-cells and #size-cells properties of the parent device (in this case /pci) so ot would have 3 numbers for address and 2 for size and each entry might have two addresses and one size for PCI and system address and BAR length. Calculating these numbers by hand would only work for a single card as these may be different for each cards or the values could be different based on what other cards are present and how SmartFirmware allocates BARs. So a generic script would retrieve the values and only change the bits and reencode them.
I've got to the point to retrieve the values with get-my-property as described above. The obstackle was that if there's no open method defined on /pci/display node then we need to add one first so we can open-dev it. Then we get a length and a bunch of encoded numbers so maybe you need to do a loop and run decode-int that many times as the length shows to get the numbers but not sure what's the invers of encode+ which may be needed first to split the encoded value into the encoded ints as we only get a pointer from get-my-property and encode-int would give the numeric value of that and not the numbers encoded within it with encode+. I'd need to look at that more but maybe you can find out without me.

Edit: Looks like encode+ just sticks the number to the end of the array increasing its length so I think you can back the numbers one by one with decode-int (or decide-phys when you know the next n values are a phys address) from the array returned by get-my-property. Since Forth is stack based the results will be on the top so you will need to either bring the array back to the top to get the next value (see stack manipulation in http://firmworks.com/QuickRef.html) or put the decoded ints somewhere like on the return stack (see >r r> words).

@Hypex
Yes thanks I've also found that and I think now I have everything to load the kickstart modules and start it replacing amigaboot.of. I'm currently writing a simple boot loader to test that with the goal to make it work with QEMU's virtual open firmware so that would:
- avoid needing pegasos2.rom
- avoid having to type boot command
- allow to detect more than 1GB RAM
- maybe boot faster
- and also giva us a place where we could later incorporate things like fixing up device tree, updating BIOS emulator or whatever is needed.
It will take some time to finish this so far I'm at the beginning but maybe by the time QEMU 8.1 comes out I can release something.

@walkero
I don't know the answer but I can confirm that using a Mac keyboard with Linux works so that could be an option. If you're stuck with a Windows keyboard it should be possible to change the mapping somewhere and there may be several places. First you can check what keycodes those keys generate (if you use X try xev) and see if you can remap them at the host so QEMU already gets the right codes. The Command keys of a Mac keyboard are mapped as Super_L and Super_R so if your windows menu key is something else you may want to set it as Super_R. If you only want to swap these keys within QEMU then I'm not sure there's an option for that. I saw several attempts to change this but not sure if any of those made it upstream and they seem to be within ui backends so would have to be done for each of those separtely. Likely none of these patches do what you want but maybe they show the places where these are handled within QEMU to check for further clues.
https://lists.nongnu.org/archive/html/ ... vel/2021-07/msg03718.html
https://lists.gnu.org/archive/html/qemu-devel/2021-07/msg07285.html
https://lists.nongnu.org/archive/html/ ... vel/2020-05/msg04533.html

@MartinW
The info you see in QEMU monitor are the values in the BARs which are encoded as reg properties in OF but the values aren't the same. Also from the output is looks like SmartFirmware allocates addresses for the BARs but does not map them, not sure this is normal and the OS shold map them later or SmartFirmware should take care of that. It does map some devices that it uses and maybe it would map the gfx card it the card rom did not crash? I don't know how this supposed to work.

As for getting the numeric values of the properties that the .properties command does not show because that uses the text representation instead I think the get-my-property word should do that but when I tried it did nothing. I think I now found out why. If you cd /pci/display and then try 'words' it shows nothing (at least with my test) so the device cannot be opened. So I've added an empty open word then got something back from get-my-property:


get-my-property is defined as

so the 0 on the top of stach is false (that you can test with =0 if) and the other two values are prop-addr and prop-len that should contain the numbers but don't know how to decode them.

However just for testing with one card that you know what should have you could mot care for getting/decoding and changing the values just replace them with the values that should be there and see if that makes any change in AmigaOS.

Edit: The Sun docs are quite good but talk about writing FCode drivers to be put in the card ROM which might work slightly differently as I think there are some restrictions for code compiled to FCode but maybe the parts about what to put in reg and assigned-addresses properties and how to encode them are the same.

@MartinW
There's also a sample script from Genesi that I've found at https://www.powerdeveloper.org/platforms/pegasos/devicetree that patches the device tree which could be useful as a starting point.

@MartinW
Quote:

You can add an emulated device with 64 bit BAR to test it without a gfx card. A simple one is -device qemu-xhci with only a single BAR or one that's more like the Radeon cards is -device igb network card that has both 32bit and 64 bit bars. This may help experimenting.
Quote:
This may be a problem if the AmigaOS driver needs the card ROM to run but we only can find out after getting past the 64bit BARs so the OS driver can talk to the card at all. Even if the firmware crashes and cannot get output it may run enough of the rom to get the card somewhat init but if not then we'll need to add another layer during boot to run the bios unless the bios emulation from classic could handle it and could be enabled on pegasos2 as some have mentioned it before. Once we at least have the 64bit BAR issue sorted we can think about that.

@geennaam
This can happen on forums, especially Amiga related ones. Maybe you could just ignore rpelies that are off-topic or don't make sense and not take it too serieously. Thanks for your testing so far, it helped a lot to identify problems and hopefully these can be fixed eventually. What could still help is to elaborate on what kind of instability you found with sam460ex compared to pegasos2?

I've found that with AmigaOS4.1FE it can crash if I don't wait for it to boot fully and start clicking around too fast after boot. If I wait a bit after boot for the dock to start and things to stabilise then it works well. I don't think this is emulation related and don't know if later updates improved it. I've only tried the boot CDs to test the emulation, I'm not using any of these OSes myself.

As for the Forth script it's not trivial due to the cryptic nature of Forth and OpenFirmware but what if you check the OF PCI docs at http://www.openbios.org/data/docs/bus.pci.pdf that I've linked above it says there are two space bits in these properties that tell if it's comfig, io, 32bit mem or 64bit mem so basically what we'd need to do is to retrieve the assigned-addresses property, decode it to the numbers shown in the doc, change the space bit of 64bit BARs to 32bit then encode the property again. I don't know what are the OF Forth words to do it and could not find an easy doc so it may take some experimentation and searching for docs and examples.

@MartinW
Didn't you say in post #604 that you have an RX card that you could pass through? By the way the errors about UNIMPLEMENTED EXTENDED OPCODE looks like what I get when pegasos2.rom crashes on the QEMU vgabios so did you have -vga none in your command line to disable it? You may need -device vfio-pci,x-vga=on to get the VGA from the passed thorugh card also sent to tthe virtual machine. If you don't get picture or still get errors then the card's ROM may be too new for the BIOS emulator in the pegasos2 firmware. You could temporarily add another video card to the virtual machine just to get a window to be able to redirect firmware input/output to serial so you need -serial stdio -device bochs-display,romfile="" to get a guest window where you cn type " /failsafe" io

@geennaam
Quote:
I'm not sure about that. If the problem is that AmigaOS cannot handle 64bit bars but would work with reporting them as 32bit bars since they are mapped in 32bit address space anyway then this should be possible to be fixed in a Forth script running on SmartFirmware that replaces the reg and assigned addresses properties of the card with same but changing 64 bit bars to 32 bit. This should be the place where AmigaOS gets the info about the card so fixing that up could avoid this problem. So anybody wants to learn Forth to find out how to write such a script or you'll just keep waiting for me to do that too?