Playing around is pretty much all I do - once things work they get boring
Are we sure that the bridge isn't causing the issues with the 9250 under OS4? I suppose we are given that it works fine in Morphos. Although I would say that jumping to a bit of a conclusion.
Not that a 9250 is really an ideal end-game card anyway. Would be better if the more modern cards worked and you have them covered anyway.
Never say never. But the Voodoo3 3000 works great with the same bridge and AmigaOS4. It's more likely that there's no vbios init. And the OS4 driver cannot handle a uninitialized card.
QEMU 8.02 sam460ex Passthrough [...] 2. Radeon 9250 has the same result as Pegasos2. Boot logo ok. But workbench backdrop and windows messed up. Except for icons. And a crash shortly after.
Try if downgrading it to a framebuffer helps, the required monitor tooltype should be something like "BLITTER=No" (IIRC it used to be "NOBLITTER=Yes" older versions).
Quote:
It's more likely that there's no vbios init. And the OS4 driver cannot handle a uninitialized card.
The Voodoo drivers work without executing the x86 BIOS, but AFAIK it's the only PCI card for which this is the case. Maybe the Permedia2 driver as well, because of the CyberVisionPPC, but probably nothing else.
I just think about using qemu with whatever I want. EULA etc. Like there are old modded versions of VMWare from a few years ago that used to work MAC emulation.
It really seems to me a discourse out of place also from the ethical point of view of those who spend hours programming to "give away" code capable of making "amiga" work in this case.
Among other things, a 20-year-old system even if it is called "NG" and sold at crazy prices.
There shouldn't even be a mention of licensing ethics. After our generation AmigaOS will disappear permanently.
I have been using AmigaOS in emulation for many years. And I buy AmigaOS software when I like it and need it for my hobby.
Precisely by paying those who develop it
But until now I have never dreamed of starting to use TOR and all the rest to put everything online and all the stuff in my possession. Including the various packages dedicated to 3.xx
So I repeat mentioning EULA and all clauses should not be mentioned. More than a note, it seems to me the usual decades-old "AMIGA" story.
If you try something experimental it's fine as long as the material isn't shared. Otherwise it is useless to talk about all this.
Not to mention how the quake code was made available many years ago to the "AMIGA" public.
@MartinW GPU pass through for AmigaOS currently does not seem to work so not usable at the moment. We're trying to find out here why and how to fix it. If you have a motherboard that has PCIe and PCI slots then it probably has a bridge on the board so it's still the same as using an external bridge. (Maybe there were older motherboards that had both PCI and PCIe in their chipset but recent systems are PCIe native and only have PCI slot through a bridge chip.) I think @geennaam used a Pericom bridge which are said to be good and generally work but this can depend on a lot of things. The older CPU with VT-x may not be enough for pass through, I think that's needed for using KVM but pass through needs VT-d that's IOMMU virtualisation.
Looking at the datasheet of the ICH10R IO controller chip it's connected to, it looks like it's a fully independent PCI Bus. But it's a moot point anyway if it can't be passed through.
I didn't know the difference between VT-d and VT-x.
So back in it's box and back on the shelf it goes then. I won't get rid of it as it's the last system I have here with Floppy and IDE (aside from classic Amiga) but it's not going to be any help here.
I'm not convinced that a system supporting VT-d and providing a dedicated PCI bus will exist (outside of proprietery hardware where you may as well buy a NG system). The two technologies are just at different points in time.
2. Radeon 9250 has the same result as Pegasos2. Boot logo ok. But workbench backdrop and windows messed up. Except for icons. And a crash shortly after.
Do you see any errors when running the card ROM by the firmware? Are you adding an emulated VGA to circumvent missing x-vga=on option? I think that may be a problem because then the firmware talks to the emulated VGA card and may not init the passed through card properly and looks like AmigaOS driver can't fix that up but needs the BIOS ROM running. To solve this we likely need to fix x-vga option for older Radeon cards as noted in the comments in QEMU source. All that somebody would need to do is read qemu/hw/vfio/pci-quirks.c and understand what it does then modify it to work with older cards insted of the HD Radeons. It's not that long and half of it is for Nvidia cards that can be ignored so it's doable if somebody wants to. Just waiting for it to happen won't make any progress. I may eventually get there and fix it if nobody does by then but it may be a long time as I have no use for that myself so not high on my list.
When do you see these messages? At start, during firmware or after AmigaOS driver touches the card? What are the numbers in the arguments of vfio_dma_map correspond to? I think it should be the BARs of the card but if those are missing in AmigaOS then that may be a bigger problem at the moment because without a frame buffer BAR we won't get any output.
Quote:
Unlike the Pegasos2, the commandline doesn't need the sam460 uboot image. Is it embedded in the target?
Since sam460ex firmware is GPL licensed it can be included in QEMU. It's in pc-bios/u-boot-sam460-20100605.bin and compiled from the sources that I had to add some fixies, source is at https://gitlab.com/qemu-project/u-boot-sam460ex.git
Quote:
Overall description of sam460 emulation in QEMU8.02 with one word: Unstable
What do you mean by unstable compared to pegasos2? It's slower but did you get any other problems with it?
I only checked the 13 years old version on GitHub, which doesn't include FFS support, but it's probably outdated. Really DOS\0? Doesn't make any sense, more code required and slower than DOS\1.
It is I found. The blank readme isn't very informative and isn't even a common MD file. It's version 0.91. Also missing from the readme.
The 0.93 is on the ACube site. There is one guide here. And the guide mentions FFS0 support.
It's required for booting the Sam4x0 versions of AROS, and supposed to make booting Linux easier. If you don't need AROS support it doesn't make any sense to use it for booting AmigaOS.
I imagine not many would want to use a Sam for AROS. Then again the same could be said for Linux. It would make Linux booting easier by supporting a DTB. But it could still work from SLB. The installers tend to lack support for the "old" method".
Pegasos2 has hit a brick wall at the moment for passthrough. Likely an issue that can only be solved in the kernel.
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?
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?
This is back to hardware again. I'd be happy to investigate this, I even know someone who is somewhat of a Forth protagonist (right word?) and would probably be keen to point me in the right direction but my hands are tied without hardware.
I guess I could look blind, but I'd prefer to spend my time looking into something that I have the hardware for. Definitely appreciate how it must feel right now though :)
@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
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?
I'll pass. I was just going along the ride to help out. But somehow got sucked into an EULA dispute. And immediatly called retard and clown for that by a moobunny resident. Today I was just wrapping up with the sam460 to cover the loose ends. And now I'm back to real hardware again.
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?
I do not know Forth, but i do have some big script generated some ten or more years ago for boot menu for my pegasos2, to load up amigaos4, morphos and co. Maybe this script can be used as a learn point for ? all those scripting languages are the same in general, just syntax different.
If it will be of any help as base point for making necessary script to change regs, then there is:
\ FORTH - Script generated by BootCreator 1.2 (25.01.2007)
\
\ terminal control stuff
\
: TTY.CSI d# 27 EMIT ASCII [ EMIT ;
: TTY.HOME TTY.CSI ASCII H EMIT ;
: TTY.CLR_EOS TTY.CSI ASCII J EMIT ;
: TTY.HOME_CLR TTY.HOME TTY.CLR_EOS ;
\
\ boot menu stuff
\
: my-max-boot-num 4 ;
: my-boot-default 1 ;
: my-boot-delay d# 05 ; \ unit = 100 ms
: my-print-menu ( -- )
TTY.HOME_CLR
." " cr
." Boot Menu" cr
." " cr
." 1: AmigaOS4.1 FE u2" cr
." 2: MorphOS 3.18" cr
." 3: MorphOS 3.18 with rdo=33555456 and invzeropage (debug)" cr
." 4: Leave Boot Menu (-)" cr
." " cr
;
: my-boot-case ( num -- )
." " cr
case
1 of " /pci/ide/disk@0,0:0 amigaboot.of " endof
2 of " /pci/ide/disk@0,0:3 boot.img bootdevice=dh2 rd " endof
3 of " /pci/ide/disk@0,0:3 boot.img bootdevice=dh2 rd rdo=33555456 ed=invzeropage " endof
4 of abort endof
endcase
$boot
;
: my-input-num ( wait-period max-boot-num default-num -- boot-num )
1 \ loop-inc = 1
3 pick 0 do
0d emit
." press 1-"
( wait-period max-boot-num default-num loop-inc )
2 pick ascii 0 + emit
dup 1 = if
." within "
3 pick i - d# 10 / .d
." seconds"
then
." (default: "
over ascii 0 + emit
." ) : "
d# 100 ms
key? if
key
( wait-period max-boot-num default-num loop-inc key )
dup 0d = if \ return pressed
drop leave
then
ascii 0 -
( wait-period max-boot-num default-num loop-inc num )
dup 1 5 pick
( wait-period max-boot-num default-num loop-inc num num 1 max-boot-num )
between if
rot drop swap leave
then
( wait-period max-boot-num default-num loop-inc num )
2drop 0 \ loop-inc = 0
then
dup +loop
drop
( wait-period max-boot-num boot-num )
nip nip
;
my-print-menu
my-boot-delay my-max-boot-num my-boot-default my-input-num
my-boot-case
Through, we need to know what to change and where (I am about those 32 vs 64 bars)
@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.
I spent the last hour or so looking at all that. Like you say, it's pretty cryptic. I think I at least have a clue where to start, and I've at least worked out how to create the file and so on.
Don't hold your breath as I feel way out of my depth here but I'm at least trying.
I'm going to head to the sofa and my macbook air to at least see about decoding the "assigned-addresses" from the properties. I realise that on a booting emulated machine they won't be 64 bit but the noise of an uninitialised GFX card is getting to me. If I get to the point of having some forth that can decode the properties then I can come back to this machine.
Incidentally the only way I could stop QEMU from choking on the card BIOS was to remove it from the vfio-pci device with romfile="". I have no idea if OS4 needs it later or not.
I'm going to head to the sofa and my macbook air to at least see about decoding the "assigned-addresses" from the properties. I realise that on a booting emulated machine they won't be 64 bit but the noise of an uninitialised GFX card is getting to me. If I get to the point of having some forth that can decode the properties then I can come back to this machine.
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:
Incidentally the only way I could stop QEMU from choking on the card BIOS was to remove it from the vfio-pci device with romfile="". I have no idea if OS4 needs it later or not.
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.
Last night I opted for sleep. I did find some bits and pieces earlier related to Mac, but along a very similar fashion to this script so I have a couple of examples now. I will update if there is anything to report from my end.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga 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
