Who's Online |
61 user(s) are online ( 43 user(s) are browsing Forums)
Members: 1
Guests: 60
AlfredOne,
more...
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/30 13:49
#921
|
Quite a regular 
|
@white
I've linked some docs before that says for remote X connections you need these things:
1. The X server where you want the window to appear (AmiCygnix in this case) should allow connections on port 6000 for its display 0. This may need adding -listen tcp on newer Linux systems but don't know how to check that on AmigaOS.
2. The X client (app you want to run) has to be able to access that port over the network. You either need the two machines see each other like through a tap device or via port forwarding in slirp. In the latter case you'd have host port 6010 forwarded to guest port 6000 so connecting to localhost:6010 on the host is like connecting to 10.0.2.15:6000 on the guest but you can't access that network directly as it's behind slirp's NAT so you need the port forwarding. It's the same as setting up a web server running on the LAN to be accessible from your router's IP for outside machines. To have X client connect to localhost:6010 set DISPLAY to localhost:10
3. The X server authentication must allow the guest to connect. You may either need to copy .Xauthority to the guest or disable X auth altogether with xhost + which is not recommended of your machine it accessible from outside becuase then everybody can snoop your keyboard but may be OK if it's behind a NAT and only accessible from the host.
All the above should be taken care of by ssh X forwarding so if you already can ssh from AmiCygnix to your host then just enable X forwarding in ssh server and client config and use ssh -X or ssh -Y which should set up authentication and DISPLAY itself and forward traffic over the ssh connection so you don't need to separately configyre port forwarding either.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/30 13:38
#922
|
Quite a regular
|
@kas1e Quote: Sadly it's uknown why pegasos2 can't handle radeonRX/HD over bridges :( Even mA1 can (which is even older). Maybe because tryuing to pass through PCIe cards to a machine that has only PCI just can't work but if that's not the problem then maybe it could be fixed but needs to be understood better first. I don't know mA1 and how that can use HD/RX cards. What bridges you use there? Is there a way somebody solved it with real pegasos? The results I've seen so far suggest either the card ROM is not running correctly or the VRAM BAR is not mapped for some reason, maybe because it's not where older cards have it and firmware does not handle that or maybe it's too large for PCI? I don't know somebody who wants this to work should look at it and try to find out. In the meantime I'm trying to figure out how PCIe works on sam460ex so I can emulate that then we can also try with that and compare the results which mihgt help us further.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/30 13:31
#923
|
Quite a regular
|
@geennaam What firmware output and BIOS ROM resutls you get when using x-vga=on with 9250 and bochs-display? Does the pegasos2 firmware runs the card ROM in this case, does it init the display? I think mixing passing through a VGA card without its VGA bits and emulating those separately does not sound like a good idea if the card ROM wants to talk to the VGA part too. ATI ROMs have VESA BIOS ROM so likely wants to use the VGA bits too so I think those should come from the real card as well but this may need some set up on the host. I've read somewhere thatusing i915 driver for on board Intel GPU on the host may have problems with passing through VGA so you may either need a kernel patch (which disables acceleration on host) or not load the i915 driver (which disables graphics altogether on the host so you only get text console). There may be some info on this is these posts (that I did not read yet but I think it might help): https://vfio.blogspot.com/2014/08/vfiovga-faq.htmlhttp://vfio.blogspot.com/2014/08/what ... with-vga-arbitration.htmlhttps://wiki.archlinux.org/title/PCI_passthrough_via_OVMF
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/30 13:14
#924
|
Quite a regular
|
@Hans Yes the register names currently match Rage128Pro but I'll change CCE regs to use Radeon names as those are only used by MacOS for Rage and once we get Radeon working better probably that will be preferred. I've only included these in the logs as they clearly demonstrate the endianness problem. In the meantime I've found that some regs are accesssed via ther IO BAR and those should be little endian while the MMIO regs BAR is switched to big endian. In QEMU the IO BAR is just an alias to the MMIO region so I can't switch endianness separately but this is easy to fix and doing that I now get correct endianness values in register accesss. What I still need to find is when to switch modes as AmigaOS seems to enable dispay and DAC before setting up resolution, timing and pixel format so when later it does that again that's ignored by ati-vga because every guest does this differently and it causes flicker when later setting display parameters changing window size so ati-vga only enables display when writing some regs which worked so far for other guests but AmigaOS seems to do yet another sequence so I'll need to tweak this to get some picture. Quote:
As for geennaam's actual Radeon 9250, the reason why it won't work on AmigaOS 4 but does on MorphOS is most likely down to the OS4 driver needing the firmware to do the low-level initialization properly. If the MorphOS driver includes code to do that, then it'll work even if the firmware doesn't. IIRC, AmigaOS 4 does have code to run the VGABIOS, but it's only included in AmigaOS 4.x for classic Amiga hardware (where it's needed if you have a Radeon card plugged into a PCI bus like the Mediator).
I think this may be related to some mixup with x-vga=on and adding an emulated VGA as well. It may happen that the BIOS is partially talking to the emulated VGA instead of the passed through one and that's why it fails to run? I think what should work is passing through the card with x-vga=on and only using bochs-display but this to work may need the issue mentioned in the comment in QEMU vfio-pci fixed. Somebody may want to look at that comment and find out what it means and if it's relevant for passing through a 9250.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/30 13:02
#925
|
Quite a regular
|
@geennaam
If this is DNS problem then it may be worked around by not using the slirp DNS but set some other DNS server manually in the guest (only overriding DNS setting not the IP). I think some people on MorphOS who had problems booting also said using manual settings works better and this may be why tap can work better.
If this is an old bug it's probably not fixed because it's not reported to those who could fix it. libslirp is now a separate project not part of QEMU any more so this should probably be checked in their bug tracker and reported there to get somebody look at it.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/30 12:58
#926
|
Quite a regular
|
@white
You can use --enable/--disable options with Linux as well they are not specific to macOS. The dbus and slirp options should be auto detected so if you have libslirp-dev (or what is's called on your distro) package installed then user network will be built. Adding --enable-slirp menas it will give error and fail when no slirp is detected instead of building without -netdev user so you can make sure that way tho config will be what you want. The --enable-lto option enables Link Time Optimisation which is a compiler optimisation that will take more time to compile and may be faster or break depending on compiler version. One may try to enable even more compiler optimisations with --extra-cflags=-O3 but not sure if that helps. Compiling from QEMU master has latest patches that may improve FPU a little but may need the disable dbus option if you get an error related to that.
For the network it may depend on your QEMU command line. When using -detdev user then the guest can only use the 10.0.2.x network that slirp presents to the guest and will NAT traffic from it to the host network. If you enable DHCP in the guest the it will get an IP address starting from 10.0.2.15 from slirp's built in DHVP server and it will configure other parameters to use slirp services. You can manually set another IP address such as the 172.18.x.x one you did but that won't work with -netdev user. It's like connecting a machine to a router that's set up to use 10.0.2.x but manually configuring that machine to use a different network.
With -netdev tap no NAT, DHCP or DNS services will be provided by QEMU, all it does then is to connect the emualted card to the tap device on the host and then you can configure it and route it how you like it. That means you'll either need to do NAT on your host with iptables to allow the guest to access the internet or bridge the tap device to your physical network card inthe host to allow the guest to access your LAN and get an IP address from your router or just use the tap device to communicate with the guest from the host like it was a virtual network cable on end plugged in the host and the other end in the guest.
I think the problem is that you don't yet fully understand these options and therefore not configuring these correctly. Either search for some docs and learn about this or just forget all that and use -netdev user with the hostfwd option I've told before to redirect guest port 6000 to host port 6010 and in AmigaOS do not set any network parameters manually just set it to use DHCP which should set everthing correctly.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/29 20:16
#927
|
Quite a regular
|
OK I think I've found the reg bit for endianness. I see in the AmigaOS log:
ati_mm_write 4 0xe0 CNFG_CNTL <- 0x10
and in ATI reg docs:
CONFIG_CNTL - RW - 32 bits - [IOReg,MMReg:0xE0]
APER_REG_ENDIAN bits 5:4 default 0
There's no further info on that but I guess this should flip register aperture endianness to big endian which is definitely not done in QEMU and I'll have to find out how this could be emulated. If we can't change memory region endienness on the fly then we need two of them and swap them on this bit. I'll ask on the QEMU list unless I can find it out. (Or we could just do the swap in the handler functions if the bit is set which may be the simple route for now for testing.) That should at least get better results with ati-vga and AmigaOS but does not explain why @geennaam did not get it work with passed through card bceause I assume this bit should work there. Update: I've tried to implement byte swapping now which makes most of the register values show up correctly but now some regs are wrong such as 0x50 CRTC_GEN_CNTL, 0xf8 CNFG_MEMSIZE, 0x108 CONFIG_APER_SIZE that are now byre swapped. Is this bit only supposed to swap some regs but not others or how does this work. Maybe there are different ways to access registers but in QEMU they end up in the same place. I'll need to check because I forgot how I implemented it back then. I think I put this aside for now and do something else.
Edited by balaton on 2023/6/29 21:36:24
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/29 15:01
#928
|
Quite a regular
|
@MartinW
Some people reported problems with network but others not. I'm not sure why that happens or how to find out so if somebody has an idea how to debug that from the AmigaOS side that may help. I could only suggest to try emulating different network device for the guest, see -device help for what's available but I think most of those have no driver in AmigaOS. The ne2k_pci is NE2000/RTL8029 compatible but maybe the drivers are not any better. I can't do much about this problem so if anybody has any idea how to find out why it hangs please speak up.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/29 14:39
#929
|
Quite a regular
|
@geennaam Quote:
-device VGA,romfile="" will show the Pegasos SmartFirmware output in the QEMU window
Does that mean when using this with 9250 on vfio-pci without x-vga=on you see output in the emulated VGA? That's odd because this card does not have ROM so it must be the ATI ROM that writes something there but in that case those writes should go to the ATI card so that's why I said you'd better use bochs-display,romfile="" with x-vga=on on the ATI card instead. Or I'm just completly missing what you say.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/29 14:35
#930
|
Quite a regular
|
@MartinW Quote:
I'm wondering if I should try to find a second hand card and likely a bridge card as well since my PC only has PCIe. I do have an older motherboard that is I think has an i7 6700k in it. That has a PCI slot but it probably getting a bit slow and I'd have no idea if it supports pass-through. It certainly predates it being popular that's for sure.
According to https://en.wikipedia.org/wiki/List_of_ ... ocessors#%22Skylake-S%22_(quad-core,_14_nm) i7-6700K has VT-d so it should be OK but the motherboard chipset and BIOS must also handle it. As for how fast it would be it may worth a try if you already have that machine before getting new one because if it works it might at least be a good start. You've mentioned problems with network. What specifically? On macOS you can either use -netdev user or -netdev vmnet but the latter may need some setup or run as root, I'm not sure. I think @Maijestro had something on it in the guide published on amiga-nows.de. If you're interested in trying to write a driver looking at making an AmigaOS driver for virtio-net may be a good way to start and learn. Borh the virtio-net device and Amiga API for network drivers (is that SANA2?) should be documented and sample code should be available. Once you get understanding how this works all other virtio device use the same mechanism to talk to the device which is a memory mapped ring buffer not unlike what ATI cards use so it should be simple to interface to those.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/29 14:02
#931
|
Quite a regular
|
@geennaam
Thanks for gathering these in one post for convenience.
You say multifunction=on should be on function 0 but the command lines have it on function 1 (e.g. host=03:04.1,multifunction=on) which is correct? The qemu command has some garbage at the front. I did not follow what happens if you use VGA but I'd say using bochs-display and adding x-vga=on for the 9250 as well may be better otherwise there may be some mix up between the emulated VGA and the passed through card which also has VGA mode.
Edit: Unless of course x-vga=on does not work with 9250 which could be based on the comment in source but I'm not sure it's even needed by AmigaOS, probably not as that only cares about the PCI BARs
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/29 13:46
#932
|
Quite a regular
|
@Hans MorphOS pokes the regs much more, it even seems to do weird stuff like accessing VGA paged memory for some reason but ends up doing similar things eventually:
ati_mm_read 4 0x158 MEM_SDRAM_MODE_REG -> 0x10100000
ati_mm_write 4 0x284 unknown <- 0x0
ati_mm_write 4 0x228 CRTC_OFFSET_CNTL <- 0x0
ati_mm_write 4 0x328 CRTC2_OFFSET_CNTL 0x0
ati_mm_write 4 0x64 GPIO_DVI_DDC <- 0x30000
-- lots of DDC to read EDID
ati_mm_write 1 0x23 unknown <- 0x2
ati_mm_write 1 0x23 unknown <- 0x0
ati_mm_write 1 0x23 unknown <- 0x2
ati_mm_write 2 0x28e unknown <- 0x8000
ati_mm_write 1 0x5b DAC_CNTL <- 0xff
ati_mm_write 1 0x59 DAC_CNTL <- 0x40
ati_mm_write 2 0x28e unknown <- 0x8000
ati_mm_write 1 0x10 BIOS_0_SCRATCH <- 0x4
ati_mm_write 1 0x57 CRTC_EXT_CNTL 0
ati_mm_write 1 0x57 CRTC_EXT_CNTL 0
ati_mm_write 2 0x24 unknown <- 0x2
ati_mm_write 1 0x24 unknown <- 0x2
ati_mm_write 1 0x3f8 CRTC2_GEN_CNTL <- 0x0
ati_mm_write 1 0x55 CRTC_EXT_CNTL 0
ati_mm_write 1 0x27c unknown <- 0x0
ati_mm_write 2 0x24 unknown <- 0x2
ati_mm_write 1 0x27c unknown <- 0x0
ati_mm_write 1 0x28f unknown <- 0x80
ati_mm_write 1 0x293 unknown <- 0x80
ati_mm_write 1 0x8 CLOCK_CNTL_INDEX <- 0x83
ati_mm_write 4 0xc CLOCK_CNTL_DATA <- 0x3c
ati_mm_write 1 0x8 CLOCK_CNTL_INDEX <- 0x84
ati_mm_write 4 0xc CLOCK_CNTL_DATA <- 0x301c0
-- more poking here
ati_mm_write 4 0x224 CRTC_OFFSET <- 0x0
ati_mm_write 4 0x22c CRTC_PITCH <- 0x100
14.073| Radeon: Failed to initialise Radeon DMA
ati_mm_write 4 0x774 PM4_FPU_FPA <- 0x0
ati_mm_write 4 0x770 PM4_FPU_FPB <- 0x0
ati_mm_write 4 0x7d4 PM4_MICROCODE_ADDR <- 0x0
ati_mm_write 4 0x7dc PM4_MICROCODE_DATAH <- 0x0
ati_mm_write 4 0x7e0 PM4_MICROCODE_DATAL <- 0x21007000
ati_mm_write 4 0x7dc PM4_MICROCODE_DATAH <- 0x0
ati_mm_write 4 0x7e0 PM4_MICROCODE_DATAL <- 0x20007000
ati_mm_write 4 0x7dc PM4_MICROCODE_DATAH <- 0x4
ati_mm_write 4 0x7e0 PM4_MICROCODE_DATAL <- 0xb4
ati_mm_write 4 0x7dc PM4_MICROCODE_DATAH <- 0x4
ati_mm_write 4 0x7e0 PM4_MICROCODE_DATAL <- 0xb8
ati_mm_write 4 0x7dc PM4_MICROCODE_DATAH <- 0x0
ati_mm_write 4 0x7e0 PM4_MICROCODE_DATAL <- 0x6f5b4d4c
Here I can see these are byte swapped compared to AmigaOS log. I've also noticed that MorphOS driver waits for the CCE FIFO to have empty slots befire writing and stops there as we report 0 but AmigaOS don't seem to care just write to the FIFO anyway. Not sure it checks in a different way or could overflow the FIFO on real card.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/29 13:40
#933
|
Quite a regular
|
@Hans There don't seem to be much communication with the card by the AmigaOS Radeon driver before setting up CCE but I don't have time to go through each of those now but maybe somebody can spot something. I get:
ati_mm_write 4 0x230 OVR_CLR <- 0x0
ati_mm_write 4 0x234 OVR_WID_LEFT_RIGHT <- 0x0
ati_mm_write 4 0x238 OVR_WID_TOP_BOTTOM <- 0x0
ati_mm_write 4 0x420 OV0_SCALE_CNTL <- 0x0
ati_mm_write 4 0x1c0 MPP_TB_CONFIG <- 0x0
ati_mm_write 4 0x1c8 MPP_GP_CONFIG <- 0x0
ati_mm_write 4 0xf0 GEN_RESET_CNTL <- 0x0
ati_mm_write 4 0x540 SUBPIC_CNTL <- 0x0
ati_mm_write 4 0xc40 unknown <- 0x0
ati_mm_write 4 0x94 I2C_CNTL_1 <- 0x0
ati_mm_write 4 0x950 CAP0_TRIG_CNTL <- 0x0
ati_mm_write 4 0x9c0 CAP1_TRIG_CNTL <- 0x0
ati_mm_write 4 0x224 CRTC_OFFSET <- 0x0
ati_mm_write 4 0x228 CRTC_OFFSET_CNTL 0x0
ati_mm_write 4 0x58 DAC_CNTL <- 0x100ff
ati_mm_write 4 0x22c CRTC_PITCH <- 0x50000000
ati_mm_write 4 0x224 CRTC_OFFSET 0x3
ati_mm_write 4 0x50 CRTC_GEN_CNTL <- 0x3
ati_mm_write 4 0x200 CRTC_H_TOTAL_DISP <- 0x63004f00
ati_mm_write 4 0x250 unknown <- 0x63004f00
ati_mm_write 4 0x204 CRTC_H_SYNC_STRT_WID <- 0x90028800
ati_mm_write 4 0x2c4 unknown <- 0x90028800
ati_mm_write 4 0x208 CRTC_V_TOTAL_DISP <- 0xf02df01
ati_mm_write 4 0x254 unknown <- 0xf02df01
ati_mm_write 4 0x20c CRTC_V_SYNC_STRT_WID 0x0
ati_mm_write 4 0x8 CLOCK_CNTL_INDEX <- 0x88000000
ati_mm_write 4 0xc CLOCK_CNTL_DATA <- 0x3000000
ati_mm_write 4 0xb74 unknown <- 0x0
ati_mm_write 4 0xb78 unknown <- 0xff3f0000
ati_mm_write 4 0xb7c unknown <- 0xa000
ati_mm_write 4 0x7d4 PM4_MICROCODE_ADDR <- 0x0
ati_mm_write 4 0x7dc PM4_MICROCODE_DATAH <- 0x0
ati_mm_write 4 0x7e0 PM4_MICROCODE_DATAL <- 0x700021
ati_mm_write 4 0x7dc PM4_MICROCODE_DATAH <- 0x0
ati_mm_write 4 0x7e0 PM4_MICROCODE_DATAL <- 0x700020
ati_mm_write 4 0x7dc PM4_MICROCODE_DATAH <- 0x4000000
ati_mm_write 4 0x7e0 PM4_MICROCODE_DATAL <- 0xb4000000
ati_mm_write 4 0x7dc PM4_MICROCODE_DATAH <- 0x4000000
ati_mm_write 4 0x7e0 PM4_MICROCODE_DATAL <- 0xb8000000
ati_mm_write 4 0x7dc PM4_MICROCODE_DATAH <- 0x0
ati_mm_write 4 0x7e0 PM4_MICROCODE_DATAL <- 0x4c4d5b6f
The above may be missing some lines as the forum engine just seems to drop them. Also the register names may be different from Radeon as it was originally for Rage128Pro but the addresses are mostly the same.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/29 11:27
#934
|
Quite a regular
|
@joerg
Looks like it's a bit confusing to follow all the messages here so we may not be on the same page. I'd add to what @geennaam said above that to my understanding the above setup now works with MorophOS passing through the 9250 but does not get picture with AmigaOS. I was trying to debug why so I tried to reproduce the same with ati-vga emulated Radeon 7000 which is incomplete so does not get picture even with MorphOS but I can still look at what the driver does with the card and this is where I saw MorphOS programming the card with meaningful data but with the AmigaOS I see byte swapped values when it tries to set up CCE. I did not look further so I don't know yet why and if it's the same issue with a passed through card but that's all I could find so far. I'll need more time to analyse the logs and find what ati-vga register might not be emulated correctly at which point I might end up seeing the same problem @geennaam is having with passed through card as if it's a card feature that should work with passed through card unless vfio-pci might interfere somehow.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/29 9:04
#935
|
Quite a regular
|
@joerg Quote: The main reason for using a 2nd level bootloader, for example the SLB_v2 used on the AmigaOne XE/SE/µA1, was to be able to use closed source software.
If the code of it would have been included in the GPL U-Boot directly instead all parts of it would have to be GPL as well and therefore large parts of it would never have been implemented. That's OK but I'm still not sure what's the interface between amigaboot.of and loader.of. Is it the same as what slb_v2 uses? The latter is probably implemented by ub2lb that I've now checked would load kernel modules itself so I have that part but not sure what to pass for loader.of. The ub2lb passes some board info which may be U-Boot specific on OF maybe it needs the same parameters that OF would pass? Also now that it seems loader.of also talks to OF then likely passing the device tree is not needed and the device tree walk I see in amigaboot.of is just to find devices to boot from? Initially I though it would make some structure from that info to lass to the loader but if loader.of will do that then it's even simpler. Quote: PCI(e) access depends on the machine specific parts of the kernel, without changes in the PCI code of the kernel no driver could work in a QEmu version not emulating real hardware. Virtio is not tied to PCI, some virt machines have it memory mapped but since PCI is pretty standard it would be easy to come up with something without much difficulty. Quote: Check the MMU/TLB emulation in QEmu. I don't know if it's used by the AmigaOS kernel, but for example Book E CPUs have a per page endian bit.
If you enable the little-endian bit for pages used by little-endian PCI parts you can simply access them normally as if it would be big-endian, without having to use any byte swapping code. I've seen it on pegasos2 with G4 CPU so I don't thins it's that. Since similar facility in Marvell chip would log and swap all BARs mapped in a PCI window I also don't think that's used. So it's most likely some ATI register somewhere.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/29 8:52
#936
|
Quite a regular
|
@Hans Quote: The old Radeon cards have registers that control byte-swapping for VRAM accesses over PCI. The atiradeon.chip sets the byte-swapping registers for the entire VRAM to based on the pixel format of the bitmap that's currently being accessed. We're talking about old Radeon driver both 9250 and the emulated M6/7000 use that. The frame buffer endianness bit should be handled as I've implemented that for MacOS that also uses it but having two apertures with different endianness to frame buffer is not supported. The real card can do that but in QEMU ati-vga the frame buffer is switched to big endian when a big endian aperture is enabled. But as @geennaam said the problem is not with frame buffer BAR but with MMIO BAR. I see writes there with wrong endianness around the rime when CCE is enabled. The whole microcode upload and what comes after that is byte swapped but maybe at the initial stages it's still OK so the card is switched to graphics mode but at some point MMIO bar may be switched to big endian too which I think is not emulated. I'll need to check that if I find some regs for that. But with a passed through real card I think this should not be a problem do maybe there's another issue after this one.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/28 22:31
#937
|
Quite a regular
|
@geennaam MorphOS generates a lot of unassigned reads but those should not appear for AmigaOS. Also a lot of them are duplicated so you could reduce the size by filtering the output through uniq -c for example:
qemu-system-ppc ... 2>&1 | uniq -c
should print duplicated lines with a leading count thus making the log much more managable.
Edited by balaton on 2023/6/28 23:51:47
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/28 22:02
#938
|
Quite a regular
|
@Hypex Quote:
I don't think it's documented anywhere and likely you won't get any answers if you ask. But, the ub2lb project can be a starter. That works on the Sam though, which is different to the Pegasos, but contains info on how to boot an OS4 kernel.
Yes I think I meant ub2lb/parthenope when I said AROS bootloader. But doesn't that just load amigaboot file and launches it? Does it replicate what amigaboot does and loads the kernel modules itself? I've looked at the source but it's not very clear. Quote:
What amigaboot.of is doing, is talking to OpenFirmware, what ever one is in the host firmware. Cannot confirm but likely it uses OF hooks to read system and files in. It then passes control over to the Kicklayout EXEC binary to boot the system.
The Open Firmware part is clear to me. I tested amigaboot.of with the minimal open firmware in QEMU and know what it misses to run and what OF client interface functions it uses but I don't know what it does with the data it retrieves from OF. That is what kind of structure should it build from the OF device tree and how should it pass to the kernel. So I'd need more info on that part, all the others I don't care about. Quote:
Now, there is a Pegasos version and X1000 version of amigaboot. There's also X5000 version but that is amigaboot.ub running under UBoot so totally different port for the most part. It depends on the hardware or OF set up,
The different versions are probably just to talk to the different firmwares in these machines. There are at least 3 kinds of firmware interfaces so there are that many boot loader versions but these likely only differ in the firmware side which I know for OF, I only need info on the kernel facing side that makes the module list in memory and prepares the info about the machine and starts the kernel. I'd look for info, docs or hints on that, the rest I can handle. Quote: CFE doesn't execute real CFE binaries, since CFE is only a "user" interface. It's all OF under the hood even if it hides it. A CFE binary is just an OF binary. OK then maybe there are only two versions, one for OF and one for U-Boot wuth the U-Boot part already open source but that's not too interesting. Quote:
So, the boot sequence goes, Smart/CFE-OF -> amigaboot.of -> EXEC loader.of.
I'd need the interface between amigaboot.of and loader.of and to know what structures in memory loader.of needs and where to pass them. The rest is just firmware dependent or trivial. Quote:
Amigaboot loads all the Kick modules in, links them all in a list, then sends it off to loader.of which is a raw binary that takes the Kick list and bootstraps the kernel.
Yes this is the part that would be interesting if it was documented in a bit more detail. Quote: All along amigaboot.of and loader.of have access to OF and hooks. Only at the end is OF killed by the OS. Or "Quiesce" as Linux calls kernel it.
quiesce is the OF client interface word for closing down and stop using firmware services after boot so it's not just how Linux calls it. The OF client interface is well documented in its standard. Quote: You can easily write your own chain loader this way. I'm not sure about that part, I think I'm still missing the structs and calling convention of loader.of to be able to reimplement amigaboot.of. Quote: I also tried running yaboot (Linux bootloader) on my X1000 but it crashed. Lol. I don't know if it loads to a particular address, since it is Mac specific, but I wonder if it could be recompiled to be compatible with Pegasos or X1000 if that helps. Since yaboot probably can't load AmigaOS I don't think it would help much.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/28 21:30
#939
|
Quite a regular
|
@joerg Quote: That's next to impossible since it includes code from several developers and you'd need to get new licences from all of them, or remove their parts. Yes that's unfortunate and makes this more difficult. But it may worth considering the option and then find it won't work than to give up without even trying. Quote:
For example you wont get any open source licence from me and at least the support for booting from SFS partitions would have to be removed in open source versions of amigaboot.of and amigaboot.ub, and if it's using anything from the CDFileSystem sources support for booting from ISO9660 has to be removed, or reimplemented from scratch, as well.
That's actually fine with me, I don't need those parts anyway and finding an open source ISO and FFS file system is pretty easy to replace those parts. But I may not even need them as I can pass the boor files from the host as an initrd so I don't need to read anything from disk which simplifies this a lot. So if you don't want your parts to be included, those can be dropped. It's just that this is work to be done which makes it more difficult than just deciding on a license change. Quote: I very much doubt there are developers in A-EONs kernel team with the time and/or motivation to implement an AmigaOS 4.1 QEmu kernel. That A-EON has any interest in porting the kernel to QEmu is unlikely as well. The kernel works fine already so no changes to it is needed. All that's needed are some drivers which should be simple to write without "porting" the kernel.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/28 21:17
#940
|
Quite a regular
|
@kas1e
Thanks, this confirms that these errors are normal and not a sign of any problem. Indeed, @geennaam found it works with a card passed through to MorphOS so the problem with AmigaOS is likely that it uses some feature that's not emulated correctly. Once we find out what that is it can be fixed.
@geennaam
Since the log does not show up, either that's not what is used here or maybe it could try to write these regs unaligned (i.e. not doing a 32 bit write to the reg address but e.g. a byte write to reg addr+3). But since these control the endianness of the whole PCI window that would break all other cards that are also mapped there so maybe it uses something ATI specific for this but then why that did not work when passing through real card? It could be we're looking at two different problems and this is just preventing me to reproduce the problem with ati-vga. This needs more investigation.
As for the amount of logs, you tell me... I was looking at those logs for a few years now. I'll try to do something about the excessive logging with guest_errors with pegasos2. I submitted a patch before but it was not accepted as others liked the current behaviour but I'll try again.
Edited by balaton on 2023/6/28 22:04:26
|
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback 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
