Of course it's a means to sell more copies. But it is just cynical that you lecture me on a breach of the EULA when the whole QEMU effort is a breach of the EULA. QEMU is neither an amiga-branded nor amiga-licensed computer. If you want to abide to the rules then either stop cherry picking or don't try to lecture others. At this moment it's just for educational purposed for me. Actually the only reason why I am doing this is to help you in your effort. I own several real AmigaOnes so I'm not in need of qemu.
Sorry if you took it as cynical and lecturing, I just wanted to make sure people know what they are doing when they modify an AmigaOS CD. As said above QEMU does not break the EULA, it emulates hardware and can run other OSes so it has nothing to do with AmigaOS or its license. Just as the real hardware can run this OS so can the emulated one too. If thid is not allowed by the license that's not QEMU's or my problem but should be considered by those who want to run AmigaOS on it. So I just wanted to make it clear that I don't encourage anybody ro do anything that's against the license but what they do at the end is their decision. If you want to modify your sam440 cd then you can do that but maybe you should not advertise it.
I also have this showing in the os4 debug output, not sure what it means.
There is a large 15-20 second delay after 'MISC_TIMING 00000000' shows, and then once the table shows the OS boots as normal.
I think that's when the driver (maybe the SM502 driver) reads the EDID from the monitor and the table shown is the EDID info retrieved. As this shows QEMU monitor this isn't the external display but the emulated one. Reading the EDID bit by bit may be slow but I think this is not related to pass thorugh. I think there are two siliconmotion502.chip drivers and one of them has the delay while the other (maybe the older one) doesn't so you may try downgrading the driver if this is an issue.
Of course it's a means to sell more copies. But it is just cynical that you lecture me on a breach of the EULA when the whole QEMU effort is a breach of the EULA. QEMU is neither an amiga-branded nor amiga-licensed computer. If you want to abide to the rules then either stop cherry picking or don't try to lecture others. At this moment it's just for educational purposed for me. Actually the only reason why I am doing this is to help you in your effort. I own several real AmigaOnes so I'm not in need of qemu.
Quote:
This License allows you to install and use the AmigaOS on a single Amiga-branded or Amiga-licensed computer at a time
Balaton only means well and has only helpfully pointed out that they might not get into trouble. We know that the license issue of Amiga is very complicated and scattered, everyone tries to sue immediately to be able to profit something from the dropped apples.
But in the end what everyone does with his legally purchased AmigaOs4.1 in the private area is up to everyone and should not be a problem as long as it is not published as a complete package without permission.
The GPU passthrough thing I find really interesting and they do it really great. For me this will not be the solution as I still hope that the "ati-vga" can be improved by the gained information so that we can use the included drivers of AmigaOs4.1 under Qemu.
So don't worry about licenses for now, because we are doing experiments here that are private. Without this information, which is not publicly available, there will be no improvement of Qemu Peg2/Sam460.
Edited by Maijestro on 2023/7/2 20:22:07 Edited by Maijestro on 2023/7/2 20:29:00
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
I don't think this info is really going to add anything new, and because I am passing through an RX580, I think the issues are already known, but just I don't recall seeing anyone mention an "Unhandled 32 bit data prefix" error from Qemu yet.
I also don't think I can expect anything from OS4 anyway with this card without spending 80Gbp (sorry, wrong keyboard layout!) on the full enhancer software to get the Radeon RX drivers.
Anyway, that log, just in case it helps.
Let me know if there is anything more useful I could do. Otherwise I'll continue reading up on network drivers.
audio: Device via-ac97: audiodev default parameter is deprecated, please specify audiodev=audio0
PegasosII Boot Strap (c) 2002-2003 bplan GmbH
Running on CPU PVR:80020101 Enable L1 ICache... Done.
Clean/Flush Block enabled Reading W83194 : FAILED.
Setting Front Side Bus to 133MHz... FAILED.
Configuring DDR... Done.
Configuring PCI0... Done.
Configuring PCI1... Done.
Configuring ETH... Done.
Releasing IDE reset ... Done.
Configuring Legacy Devices Initializing KBD... Done.
Testing 10000000 Bytes, Pass: 00000000 Failed: 00000000
RAM TEST (fill linear)... Done.
FFFFFFFF
Does A1 XE use U-Boot? I only know pegasos2 and sam460ex so don't know what other machines have but Hans said it's from the pegasos2 era when U-Boot may not have been that popuiar.
Just in case of help :
old AmigaOnes from EyeTech (micro A1 , AmigaONE with G3 and AmigaONE XE with G4) – all use UBOOT.
All Sam models (440, eps, 460, crs, etc) – all also UBOOT.
X5000 be it with 020 or 040 also UBOOT.
The exception from the list is:
x1000 - CFE Firmware pegasos2 - SmartFirmware
On All Uboot supported machines RadeonHD/RadeonRX works. On X1000 (which is CFE, and not UBOOT) - RadeonHD/RadeonRX also works.
On pegasos2 via bridges no one were able to make it works, through, on AmigaONE XE it works through bridge for sure. But again, no one probably testing it on pegasos2 deeply enough to collect the necessary information about. And yes, AmigaONE XE is Uboot, while Pegasos2 is SmartFirmware.
OK,I couldn't help myself when I saw the comment about the qemu effort being a EULA breach. Someone is in full retard mode to make such claims. That's as absurd as claiming that VMWare or VirtualBox breach the EULAs for Windows, Linux or whatever OS a user chooses to run under them as a client. I get so tired of every thread being polluted by the anti piracy clown patrol. Rant over. Never go full retard.
Maybe we could check similar infos from U-Boot but I don't know how to get those. U-Boot shold have some help or docs.
AmigaOne U-Boot docs (should be the same, or at least very similar, for Sam U-Boot versions): http://www.intuitionbase.com/static.php?section=uboot Especially the "pci [bus] [long]" command should be able to display some information, but since it's not as detailed as the SmartFirmware ".properties" output it may not help much.
Next time that you feel such urge then start by looking into a mirror. Because you are way out of your league here.
a. You fail to understand the context of EULA discussion. Namely "It takes one to know one".
b. You are trying to prove a point with Windows without having actually read the Windows EULA. Because if you did, you would have known that Microsoft explicitly allows you to run Windows in a virtual machine: Quote:
.. In this agreement, "device" means hardware system (whether physical or virtual)....
c. Breach of EULA != Piracy. Distributing unlicensed copies = piracy.
d. I was not talking about QEMU itself. I was talking about the effort to run AmigaOS4 on QEMU. QEMU is neither an Amiga branded nor Amiga licensed computer. And therefore the effort of running AmigaOS4 on QEMU, in contrary to Windows, is a clear breach of the AmigaOS4 EULA by the user. Not by QEMU of course.
e.The following statement is very weak: Quote:
If thid is not allowed by the license that's not QEMU's or my problem but should be considered by those who want to run AmigaOS on it. So I just wanted to make it clear that I don't encourage anybody ro do anything that's against the license but what they do at the end is their decision.
Now do I oppose to running AmigaOS4.1 on an emulator? Not at all!. In my opinion you should be able to do as you like with products that you've paid for. And even a bit more so if it's only for educational purposes. EULAs are often constructed with the purpose to make you pay multiple times for the same product. But again the context was: "it takes one to know one".
And when it comes to EULAs in general, opinions don't count. Because it's the EULA versus civil law. If you have complaints about that then vote for someone else next time.
Edited by geennaam on 2023/7/3 8:07:20 Edited by geennaam on 2023/7/3 8:07:41 Edited by geennaam on 2023/7/3 8:10:26
Yes, thanks, I've also found that function later in parthenope and saw it loads modules and calls the exec binary so maybe I can start from that. I'm not familiar with the source just found a bug when trying to boot AROS on the sam460ex emulation which I did to check it so I had to fix the bug first to get it load.
That bug took me a month in my spare time to figure out. I modified the source so it would work on the XE models. A fairly trivial change to the boot sources and disabling Sam specific code. So it loaded up but then I found it would randomly crash! But it depended on if it was a fresh boot or a reboot I found out later. So if I kept rebooting to test it didn't show up. I grabbed a log of the crash over serial and UBoot isn't very informative about what caused it, ignores debug info in ELF, gives no clue what did it. So it became very annoying and I couldn't see what was doing it. In the end I did it the old fashioned way and bombed the code with printf's and tracked it to the CDFS reader. Which clearly was sending a NULL where there shouldn't be. For some reason on the Sam it allows it. I don't know how! The firmware violates its own API!
It makes me wonder if some quirk of the hardware fills location 0 with some address that happens to be readable. Or if the firmware does something to fill it in. By some chance on the Sam reading from 0 is legal. Don't know if tests were done on the hardware. Did anyone write or modify code to read back what 0 contains?
Also there is another bug in the Sam-ware. The keyboard goes dead when trying to read it from the key function. That would use USB. But I found recently the same can happen from a Micro A1. Using later beta unreleased firmware in any case.
Quote:
I think the OF ABI on what a binary run by the firmware gets is documented either in some OF standard or in CHRP but for me the easiest is to look at QEMU VOF: https://gitlab.com/qemu-project/qemu/- ... master/pc-bios/vof/main.c https://gitlab.com/qemu-project/qemu/- ... ter/pc-bios/vof/bootmem.c so according to that it would be (*kernel_addr)(initrd_addr, initrd_size, CI_entry); in r3, r4, r5 so I can start from that and see if I can get ti boot or do something at least.
Yes it's obvious there it sits in R5. Also looking up the PPC kernel source helps as it's right there in the entry point as an expected pointer. That would have been the best place for me to look had I known how the kernel runs on PPC at the time.
Another quirk is the kernel is loaded to 0 or at $C0000000 mapped to 0. Expected such a setup to crash. Somehow that works for Linux.
But the Sam has UBoot. So doesn't have OF. It can pass a DTB unlike the XE UBoot. The Pegasos has the Smart ware which is closer to OF and should be easier to work with and simulate. But lacks source like the Sam. Though Smart is supposed to to be the open Smart source. But with changes. That makes it like CFE on the X1000, can get original CFE source, but not the exact source that is in the X1000.
If that's the case it would require changes in the Pegasos2 kernel, the slb (slb_v2, amigaboot.(ub|of), Parthenope (which isn't usable anyway because it doesn't support any AmigaOS file system but only Linux (ext2fs) and AROS (SFS 1.84) ones)) can't fix it, nor can the AmigaOS gfx drivers.
Actually, it does. FFS0. Which isn't very useful but okay for a boot partition. Like Ext2.
But there isn't much information about Parthenope. The download from ACube is pretty much a source dump with a lucky binary included. The install guide is just a generic guide to compiling. No wonder people had trouble using it! How can people spend time creating a binary, regardless of the usefulness, but not include any documentation as to what it is or what it does or how to use it?
Obviously Parthenope is for hackers and not end users.
On All Uboot supported machines RadeonHD/RadeonRX works. On X1000 (which is CFE, and not UBOOT) - RadeonHD/RadeonRX also works.
It can for RX but not in a normal way. Some jumper needs setting on the board and there is no CFE output. If all you have is one Workbench that always gets booted it's no issue. But if you have a boot menu with multiple items you're blind sighted to chose an entry.
It can for RX but not in a normal way. Some jumper needs setting on the board and there is no CFE output. If all you have is one Workbench that always gets booted it's no issue. But if you have a boot menu with multiple items you're blind sighted to chose an entry.
That is known limitation, but in our context make no difference. In our context is important to know that kernel and hardware of x1000 can handle and hd and rx cards, and while CFE of x1000 cant show itdelf on rx cards, it still assign all registers,allocate memory and stuff correctly, so os4 loads up and showd fine after.
I wonder if it would be possible to run a program before amigaboot loads so it can work? One with an UEFI x86 emulator. A batch file would be too involved, if it could work, though it could be loaded off disk. A simple binary would break, since when it returns CFE would crash, before amigaboot could even start. I don't know if a command could load code it, so that when started it runs an emulator to setup card, then return and launch amigaboot.
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.
Overall description of sam460 emulation in QEMU8.02 with one word: Unstable
I've been looking at my older system that's here and am very tempted to start to build it up on the workbench later. It is from around 2009, uses an i7 950 CPU (so not 4700 or 6700 as I had previously guessed) but it still supports Intel VT-x. The BIOS has a single setting. Virtualisation enabled or not. But importantly it has a PCI slot, IDE and Floopy so I think it's a board I should keep anyway (nearly sold it a few times over the years).
If I'm going to test PCI passthrough without a bridge then I need to buy a GPU, like a £20 one from eBay or something, but frankly I'm getting completely lost as to all the options. Hans blog states Radeon HD does not work on Pegasos2 but not only is that page from around 2012 but that also doesn't take into account Qemu and I think we've proved that OS4 see's it OK haven't we?
I'd be happy with a decent WB resolution (1080?) and 2D acceleration for the moment, I'm not desperately concerned about 3D, I have my modern systems for that.
I don't know if me doing that would gain any insight for anyone whether it works or not for me?
Looking at it, the 9250 is about as modern as I can get without getting into PCIe territory which given the consistency of eBay listings is a minefield (saying they're PCI when they're clearly AGP or PCIe and so on).
I'll keep an eye out for one and see if I can get one for next to nothing. Right now it looks like about £40 which is fine if I knew the rest of the system was OK with passthrough and all the other variables. I'll keep looking.
It would be good if I could repeat your tests but without the bridge to rule it out.
[EDIT] Doesn't look like buying one is likely to be an option since the world appars to have latched onto them being Amiga Mediator compatible. Typical. I will keep an eye out though.
Actually, it does. FFS0. Which isn't very useful but okay for a boot partition. Like Ext2.
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.
Quote:
Obviously Parthenope is for hackers and not end users.
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.