All I'd need for that is to know what it does and what the AmigaOS kernel needs at boot. Is this documented somewhere? Or if it's easier to just open source amigaboot.of I can figure that out without docs fron the source. The AROS boot loader does something very similar so likely it would not be too difficult to reimplent amigaboot.of based on that or even from scratch. That seems to be a better path then rewriting the pegasos2 firmware.
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.
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.
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, but amigaboot can only run if it is relocated to a specific address range. I found this out myself the hard way, when I tried to write CFE binaries using OF hooks to print messengers and they didn't do anything. Nor crash. After a month of doing my head in I found out nothing was wrong with my code, when I was examining amigaboot.of, and noticed it relocated itself. I copied the address into my linker setup and suddenly my CFE binaries worked! Yes side note, 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.
So, the boot sequence goes, Smart/CFE-OF -> amigaboot.of -> EXEC loader.of. 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. 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 kernel calls it. You can easily write your own chain loader this way.
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.
@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.
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.
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.
@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.
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.
Exactly. Also, assuming A-EON won't be interested in emulation is an instant fail. It doesn't take much to ask directly and find out for sure. Trevor was quite enthusiastic about the A.L.I.C.E. laptop several years ago...
@geennaam Quote:
If you see a difference in byte-swap behavior then this is something that is definitly worth investigating.
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.
The RadeonHD/RX doesn't do this, which is why their 16-bit modes are use "PC" endianness. Picasso96 performs direct CPU accesses to VRAM, so faking big-endian 16-bit pixel formats isn't possible without the register-based endianness swapping system (which isn't available in newer cards).
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.
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.
Quote:
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.
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.
@geennaam Quote:
If you see a difference in byte-swap behavior then this is something that is definitly worth investigating.
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.
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.
I am talking about access to registers themselves. Not about moving gfx data. So if those registers accesses are big endian instead of little endian then the configuration will be bogus.
I am talking about access to registers themselves. Not about moving gfx data. So if those registers accesses are big endian instead of little endian then the configuration will be bogus.
Okay, but you're getting an image on the Radeon 9250, right? That's not going to happen if registers are being written to with the wrong endianness. Mind you, some registers are in an I/O BAR, and others are in an MMIO BAR. So, it would be possible for some registers to be written to correctly, while others are not.
The Radeon 9250 also has registers controlling the endianness of certain subcomponents, such as the command processor.
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.
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.
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.
If it would be some ATI register it wouldn't work on a real Pegasos2 either, but since it does it has to be related to the emulation of the CPU or the Marvell.
Unless the problem with the 9250 pass-through tests is that it's not blacklisted on the host OS. The host OS gfx driver may set up something on the gfx card with which the Firmware and/or the AmigaOS drivers can't work with, they expect the gfx card (initial register contents, etc.) to be exactly as it is after system start or a hardware reset.
The whole idea of VFIO-PCI is that the host OS doesn't setup anything. As far as I know, QEMU even resets the PCI hardware at startup of emulation. Hence the message on the QEMU monitor output that it QEMU failed to change the power state of the card to D0.
(qemu) qemu-system-ppc: vfio: Unable to power on device, stuck in D3
Yes, that was a reply on the question if my GFX card works at all. But this was also verfied with MorphOS and passthrough afterwards.
Now with VFIO correctly configured, the second GFX isn't touched anymore by the host OS. QEMU resets the GPU on startup. The guest machine firmware and guest OS have to handle the GPU setup on their own.
@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.
Check what's being written to register 0x16c4 (RADEON_DP_DATATYPE) by the two OSes. From the Linux driver headers: #define RADEON_DP_DATATYPE 0x16c4 # define RADEON_HOST_BIG_ENDIAN_EN (1 << 29)
That register bit sets whether data sent to the command processor is big or little-endian (right up to and including the R5xx series of GPUs). With PowerPC you could enable that bit, or you could write to the command processor using a byte-swapped store instruction.
I just wanted to post and say that I registered here since I'm following this thread with great interest. I have been "using" OS4.1FE very occasionally since it was released for classic but I've never *really* used it since graphics support was always an issue. Just recently I became aware of the Pegasos2 / Qemu situation so I bought OS4.1 again and set that up. It's really very nice now on my M1 Mac but clearly still fails to deliver in the GPU department (and networking as it goes).
I am a developer of over 30 years for a living but I have zero knowledge of drivers so I very much fit into the category of "willing to learn", but I don't think having a complete noob sticking their nose in blindly asking a thousand questions would be remotely helpful right now. Please say if that's not the case or there is anything that you think could be helped with, otherwise I'll just go back to "lurking with interest".
I am toying with the idea of buying 4.1 hardware at the moment but obviously that is a big investment.
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
