What the fastest possible x64 emulation way of OS4 today ?

I've also found this which I've started to read:
https://www.filibeto.org/products-n-so ... /docs/pdf/806-1379-10.pdf

That (IMO) seems to do a slightly better job of explaining things.

I have to say though that how you get from this (qemu monitor output)


To this (OpenFirmware device properties)


is still largely a complete mystery. I'm hoping that somewhere in this FCode documentation there will be some clue about decoding those entries.

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

@balaton

You look like you've gone down much the same path as me, but as you already have familiarity with the topic, you're managing more, quicker than I am. I arrived at the get-my-property seemingly not doing anything much and decided I needed to work through some Forth tutorials if I was ever going to get anywhere.

Giving my brain a rest now for tonight. If nothing else I'll know some forth at the end of this

Since I'm not entirely sure that playing about with a card that is the most powerful one supported by OS4 is the smartest idea, I did earlier buy an older, less powerful and importantly, silent card. It was only the cost of 2 beers so if I still can't make it work I don't really care.

I nearly bought a Sam460LE board. That would have been an awful lot more !!

PS: I only really looked at the Sun docs because their explanation of the address notation seemed a little less cryptic.

@balaton

Okay I checked and boot loader code gets passed three parameters. This is what amigaboot.of would pass to the loader.of. But likely what's more important is what gets passed to amigaboot.of by the firmware though it shouldn't be too different. I'll need to look again for that. It should match OF binary standards.

int _start(char *OS, struct List *KickList, int (*OFI)(void *))

So OS is a string like "AmigaOS4". KickList is a list of modules. OFI is the OF interface or hook.

@MartinW

Quote:
Those addresses are invalid, suggesting that they haven't been set.

Here's what the SM501's details look like (after booting):

Notice how the actual address ranges are shown.

It also looks like devices that aren't used by the firmware, are only configured at boot time. Here's what the SM501 looks like before the boot command has been called:


This raises the question of who does the configuring?

There's another oddity. AmigaOS 4 shows BARs 0 & 1 configured for the ethernet controller, but this is what qemu's monitor shows:


It looks like the OS is only using BAR0, because the Mem enable bit isn't set in the command register. Does the monitor only show the BARs correctly for devices that have been enabled?

Hans

@geennaam



Finally figured out what this is. From here, the PCI bus address configuration read by the OS is in the following format:

npt000ss bbbbbbbb dddddfff rrrrrrrr

Where:
- n NOT relocatable (0 if relocatable, 1 if fixed).
- p prefetchable (cacheable).
- t aliased (Non-Relocatable I/O), below 1 MB (Memory), or below 64 KB (relocatable I/O).
- s 2-bit address space (Configuration [00], I/O [01], 32-bit Memory [10], 64-bit Memory [11]).
- b 8-bit bus number.
- d 5-bit device number.
- f 3-bit function number.
- r 8-bit register number.

Notice the "ss" in the format string. SS = 11b (i.e., 3) means 64-bit memory. This confirms that it's the Pegasos-II AmigaOS 4 kernel that can't handle 64-bit BARs.

Is there a way to tweak the configuration tree? The OS should be able to use the BAR if the ss field was modified to 10b (i.e., 2).

Hans

@Hans

https://wiki.laptop.org/go/Device_Tree_Hacking

Could be useful for a real Pegasos2 as well. Although it will probably not make much sense to run a HD or RX card in one of those.

That’s what we’ve been trying to do. I’m currently at the “learning enough forth to get by” stage. I think it needs an ‘encode-phys’ in whatever syntax it needs and whatever values.

@MartinW

As far as I can tell, you can simply overwrite the existing property with a new value.

Yes, but I don't think you can just toggle those two bits. I think you have to read phys.hi, phys.med, phy.lo for the existing value, modify phys.hi to set those two bits to 10, then re-add the 3 32bit integers using encode-phys.

*unless*, you can somehow get the address of the 32bit phys.hi and toggle the bits in-memory directly in Forth. That isn't something I'd considered. Either way, I'm a good few evenings away from having the knowledge to actually do it. Not that there's any rush!

I did mention it before but even then, I need to wait for the Radeon HD card to arrive because I don't have the drivers for the RX. I'll gladly buy them if this can be made to work, but right now I don't have them. Until I can get the 64bit bar resovled, drivers are not a concern anyway.

@MartinW

This is how i understand it as well. You cannot toggle bits but you need to overwrite with a new value.
But since nvram isn't emulated. A script doesn't make sense anyways because it will not be saved. So I was thinking of direct manipulation in this stage.

@Hans

Do you know if the VGA Bios needs to be read and loaded into memory by the Pegasos2 boot process or does OS4 do this independently.

This is another issue with the RX580 on the Pegasos2. Qemu fails to process the BIOS, it causes an error so in order to prevent that error I bypass it with romfile="". If I leave it to read the BIOS then it does display the first page of it in the properties so it's unclear if the error is an issue or not. But it might be another reason to wait for the HD5450 to arrive.

Yes, I know that's a poor card, but it's a test point.

@geennaam
Quote:

Well, yes and no. Ideally yes, we'd be able to store it in nvram but I've already tested having the script on the OS4 side on DH0: and you can quite happily execute the script and then at the end of the script kick off the actual boot. Or worst case scenario run two commands instead of one:



It's not ideal, but it would work. Script or not, right now I'm just looking at a way to hard code values for `/pci/display@2` which is of course all very specific to my board but it can be expanded from there.

@geennaam

Quote:
Looks promising, although some of the commands they list don't work on the Pegasos II (at least, not in qemu). The .properties command also behaves differently. Other systems display the raw hex values, whereas the Pegasos-II firmware displays what looks like a decoded version of it.

Forth scripts look rather cryptic to me, so I hope we have some Forth experts here.

Quote:
The driver can read the ROM directly from the card.

Hans

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

@Hans
Quote:

Thank you - at least that's something I don't need to be too concerned about then.

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

@balaton

About timings of QEMU 8.1 (official release) it's not a very important stuff, we will work on your fork so there's no need ho have any kind of stress.
You should have joined Amigans some time ago, I feel we are taking great steps forwards in few days.
..And any improvement made for QEMU could be useful also for real hardware (i.e. Pegasos 2).

@balaton

there's a lot to take in there. i'll have another read tonight. I didn't appreciate we had to explicitly open the device, I had incorrectly assumed that something like:



would suffice.

@Hans

How to write strings or hex words seems to work according to what's described on that site.

For example:



Will update the property "name" with the new string value (geennaam)



and writing hexadecimal values van be done like this:



writing multiple 32bits words to a property goes like this:



What we only need is a raw dump of the "reg" and "assigned-addresses" properties to get their format.