Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
83 user(s) are online (45 user(s) are browsing Forums)

Members: 1
Guests: 82

MickJT, more...

Support us!

Headlines

 
  Register To Post  

« 1 ... 31 32 33 (34) 35 36 37 ... 75 »
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
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.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
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.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@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.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@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.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@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 show-pci-full 
Br Bus Dv F Vend Dev  Vendor         Chip         Description
===============================================================================
 
0   0  0 0 11AB 6460 Marvell        MV6436x      System Controller for PowerPC Processors
 0   0  1 0 126F 0501 Sil Motion                  
                      8000.0000
-          83FF.FFFF BAR 0 MEM
                      8400.0000
-          841F.FFFF BAR 1 MEM
 0   0  2 0 10EC 8139 Realtek        RT8139A
/B/C  Fast Ethernet Adapter
                      0000.1101
-          0000.11FF BAR 0 I/O
                      8420.0000
-          8420.00FF BAR 1 MEM
                      8424.0000
-          8427.FFFF BIOS  MEM
 0   0  3 0 1B36 000D                             
            0000.0000.8420.4004
-0000.0001.8420.7FFF BAR 1 MEM


Amiga x5040 ı 16GB ı RX580
GB-A1000 060@100,
A1200 PiStorm32-Lite CM4
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
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...


Amiga x5040 ı 16GB ı RX580
GB-A1000 060@100,
A1200 PiStorm32-Lite CM4
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Home away from home
Home away from home


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

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


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


Amiga x5040 ı 16GB ı RX580
GB-A1000 060@100,
A1200 PiStorm32-Lite CM4
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
This is still just a simple test

Before:
ok .properties
vendor
-id             0x1B36 (6966)
device-id             0xD (13)
revision-id           0x1 (1)
class-
code            0xC0330 (787248)
subsystem-id          0x1AF4 (6900)
subsystem-vendor-id   0x1100 (4352)
interrupts            0x1 (1)
devsel-speed          0x0 (0)
min-grant             0x0 (0)
max-latency           0x0 (0)
name                  "usb"
reg                   3:0
                      x3
,0,10,0:4000
assigned
-addresses    x3,0,10,84204000:4000


After:
ok .properties
vendor
-id             0x1B36 (6966)
device-id             0xD (13)
revision-id           0x1 (1)
class-
code            0xC0330 (787248)
subsystem-id          0x1AF4 (6900)
subsystem-vendor-id   0x1100 (4352)
interrupts            0x1 (1)
devsel-speed          0x0 (0)
min-grant             0x0 (0)
max-latency           0x0 (0)
name                  "usb"
reg                   3:0
                      x3
,0,10,0:4000
assigned
-addresses    x3,0,10,84204111:4000


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.


Amiga x5040 ı 16GB ı RX580
GB-A1000 060@100,
A1200 PiStorm32-Lite CM4
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
reg                   3:0
                      x3
,0,10,0:4000
assigned
-addresses    x3,0,10,84204111:4000
                      x3
,0,10,84204111:4000
                      x3
,0,10,84204111:4000


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?

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Home away from home
Home away from home


See User information
@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.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@LiveForIt

Quote:

Well, things are typical addresses do not have odd values, its typical aligned by 2, 4 or 8. I think you messed it up


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.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Home away from home
Home away from home


See User information
@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:
even though the bars are being probed as 64bit all the numbers are within the first 32bit


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.


Edited by LiveForIt on 2023/7/6 21:14:36
Edited by LiveForIt on 2023/7/6 21:16:58
Edited by LiveForIt on 2023/7/6 21:18:58
Edited by LiveForIt on 2023/7/6 21:19:39
(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
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:

reg                   2:0
                      mp2
,0,10,0:10000000
                      m2
,0,18,0:20000
                      i2
,0,20,0:100
assigned
-addresses    mp2,0,10,90000000:10000000
                      m2
,0,18,84200000:20000
                      i2
,0,20,FE001100:100


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

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@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.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@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.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Home away from home
Home away from home


See User information
@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)

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@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:

\ Fixup Script for Radeon HD5450 in 0d:00
\

s
" /pci/display@2" find-device
open ( -- ) true ;
s" /pci/display@2" open-dev to my-self

\ reg

0 0 h
# 00001000 encode-phys 0 encode-int encode+ 0 encode-int encode+
0 0 h# 42001010 encode-phys 0 encode-int encode+ h# 10000000 encode-int encode+
0 0 h# 02001018 encode-phys 0 encode-int encode+ h# 20000 encode-int encode+
0 0 h# 01001020 encode-phys 0 encode-int encode+ h# 100 encode-int encode+
encodeencodeencode" reg" property

\ assigned
-addresses

h
# 90000000 0 h# 42001010 encode-phys 0 encode-int encode+ h# 10000000 encode-int encode+
h# 84200000 0 h# 02001018 encode-phys 0 encode-int encode+ h# 00020000 encode-int encode+
h# fe001100 0 h# 01001020 encode-phys 0 encode-int encode+ h# 00000100 encode-int encode+
encodeencode" assigned-addresses" property

device
-end


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

\ Fixup Script for Radeon HD5450 in Gaming PC
\
  
s
" /pci/display@2" find-device
open ( -- ) true ;

s" /pci/display@2" open-dev to my-self

\ assigned
-addresses

\ 1
-------------------------------
\ xp2,0,10,90000000:10000000
\ from  0100 0011 0000 0000 0001 0000 0001 0000
\   to  0100 0010 0000 0000 0001 0000 0001 0000
\       
\ HI     
[0x430010101124077584
\ MD    
[0x000000000
\ LO    
[0x90000000] -1879048192  
\
\ INT    
[0x000000000
\ INT     
[0x10000000268435456

h
# 90000000 0 h# 42001010 encode-phys 0 encode-int encode+ h# 10000000 encode-int encode+

\ 2-------------------------------
\
\ x2
,0,18,84200000:20000
\ HI    
[0x0300101850335768
\ MD    
[0x000000000
\ LO    
[0x84200000] -2078277632
\
\ INT     
[0x000000000
\ INT    
[0x00020000131072

h
# 84200000 0 h# 02001018 encode-phys 0 encode-int encode+ h# 00020000 encode-int encode+

\ 3-------------------------------
\
\ i2
,0,20,FE001100:100
\ HI    
[0x0100102016781344
\ MD    
[0x000000000
\ LO    
[0xFE001100] -33550080
\
\ INT     
[0x000000000
\ INT    
[0x00000100256

h
# fe001100 0 h# 01001020 encode-phys 0 encode-int encode+ h# 00000100 encode-int encode+

encodeencode" assigned-addresses" property


\ reg

\ 2
:0
\ HI     
[0x000010004096
\ MD    
[0x000000000
\ LO    
[0x000000000
\
\ INT    
[0x000000000
\ INT    
[0x000000000

0 0 h
# 00001000 encode-phys 0 encode-int encode+ 0 encode-int encode+

\ xp2,0,10,0:10000000
\ from 0100 0011 0000 0000 0001 0000 0001 0000
\   to 0100 0010 0000 0000 0001 0000 0001 0000
\
\ HI    
[0x430010101124077584
\ MD    
[0x000000000
\ LO    
[0x000000000
\
\ INT    
[0x000000000
\ INT    
[0x10000000268435456

0 0 h
# 42001010 encode-phys 0 encode-int encode+ h# 10000000 encode-int encode+

\ x2,0,18,0:20000
\ from 0100 0011 0000 0000 0001 0000 0001 0000
\   to 0100 0010 0000 0000 0001 0000 0001 0000
\
\ HI    
[0x0300101850335768
\ MD    
[0x000000000
\ LO    
[0x000000000
\
\ INT    
[0x000000000
\ INT    
[0x00020000131072

0 0 h
# 02001018 encode-phys 0 encode-int encode+ h# 20000 encode-int encode+


\ i2,0,20,0:100
\
\ HI    
[0x0100102016781344
\ MD    
[0x000000000
\ LO    
[0x000000000
\
\ INT    
[0x000000000
\ INT    
[0x00000100256

0 0 h
# 01001020 encode-phys 0 encode-int encode+ h# 100 encode-int encode+

encodeencodeencode" reg" property

device
-end

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Just popping in
Just popping in


See User information
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?

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@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.

Go to top

  Register To Post
« 1 ... 31 32 33 (34) 35 36 37 ... 75 »

 




Currently Active Users Viewing This Thread: 2 ( 0 members and 2 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project