@kas1e
Technical knowledge isn't something god given or special talent. All it needs is ability to think logically and be able to read documentation ant then it only takes time. No need to say sorry, just spend the time needed to acquire technical knowledge.

I don't quite know what you get as I only see what you post here so I don't know what beta kernels do or how it appears in firmware. If there's a device node then that means the firmware does look behind the bridge but I'm not sure it inits the card correctly or AmigaOS can handle it without further tweaking like what BBoot does for cards not on the bridge. It does not show in BBoot output because BBoot does not handle bridges. I could enhance that but as I said it's probably a limited use case better handled in AmigaOS so even if BBoot fixed 64bit BARs behind the bridge maybe that would not be enough for it to work and still would need AmigaOS changes so then all of it could be handled there.

(Also realised where did you get 16 for BAR address. Forth is hex by default do dec# 16 is wriiten as 10 in Forth.)

@kas1e
BBoot on pegasos2 just lists the devices that the firmware detected so if the firmware does not look behind the bridge then BBoot won't do that by itself. This shows two things however. The correct format for config-addr which is more difficult to get from SmartFirmware so BBoot can help here, that's why I've added this output when we needed it for the 64bit BAR script (16 is not even a BAR, those are at 10,14 etc.). And that the firmware may not correctly init the bridge so to access devices behind it you'd need a driver for PCI bridge in AmigaOS first (or teach BBoot to handle bridges but then it would also need to modify the device tree which would get complex as AmigaOS gets the device tree from RTAS so then BBoot would also need to replace RTAS and that's the point where I said it would be too much work for a use case better fixed in AmigaOS in the first place and doing something else is better use of my time).

With QEMU amigaone I get good results (slower than real G4 but we know QEMU FPU is slow and this combines that with memory access that also gets slower for bigger blocks):

But with QEMU sam460ex something seems to be wrong:

which is odd as the FPU emulation is the same so maybe there's some memory access issues still left. (This is with my current development version but same result with QEMU 8.0.0 so at least not something I broke recently but don't know yet what causes it.)

Compiling stream.c with gcc 10.2.1 for Linux (with -mcpu=powerpc -O3 -DVERBOSE) and running it on QEMU sam460ex with Linux guest instead of AmigaOS I get:

So the validation error only happens on AmigaOS with the binary from @sailor. Could it be some problem with gcc 6 and -O3? I don't have AmigaOS compiler set up now so can't try it but if somebody can compile it with gcc 10 or without -O3 and verify if that runs correctly on QEMU sam460ex that may help further to locate why this fails.

@kas1e
That's what the OpenFirmware PCI doc should tell you as all this is documented there. BBoot might also help but you haven't posted the BBoot output with your bridge and card so I don't know. Or you can go back to the long thread where we've patched tha 64bit BARs from Forth, I think there was a script for it there so you can start from that too.

@joerg
Of course I know about AROS and maybe if it weren't for the fights between 3 independent groups in tha past 30 years but instead of duplicated efforts everybody could have agreed on contributing to one free and open source code base that would benefit everybody then it could be where Linux or at least Haiku is now. Unfortunately it did not go that way but maybe after 30 years it's not too late to try that eventually. I'm sure this was discussed before and what I say is nothing new so no need to repeat all the past debates but maybe people change and can reconsider decisions to keep AmigaOS alive in some form. If not then that's OK too, things will just go on like before.

I prefer GPL over BSD license for this because it makes sure that everyting will remain free for everybody so the most developers could contribute. Both who allow free like BSD and don't care much what it's used for and those who want it to be kept free. This worked for Linux and QEMU. The AROS license is similar to MPL which also says it should be kept free so it's not opposite and completely free like BSD but maybe less strict than GPL. Contrary to what some may believe GPL does not prevent commercial use, it just gives equal opportunity to everybody. There are/were whole companies like RedHat and Suse for example who lived from supporting open source operating systems and the base of macOS is also freely available so opening up AmigaOS would not make business impossible but those who hold the pieces maybe don't get this or think otherwise.

@flash
What needs improving on the MV64361 emulation in QEMU? I think it works well enough now. This chip has tons of features but if nothing uses them it does not worth emulating all details that will be unused. I think I already have a few unused things that weren't needed but implemented it anyway.

@Maijestro
I think somebody tested that before with real machine and ATI card with 16 bit mode (it's probably somewhere in the long QEMU pegasos2 thread, I think it was when we tested it with a Mario like game) and it did not reproduce the problem. I think somebody said back then that ATI cards support big endian 16bit mode but SM502 doesn't or something like that and it seems that some function used by graphics library does not take that into account on pegasos2. With the test from Capehill it's now also proven that it's not related to SDL code but it's something in AmigaOS. So we likely won't get more info from trying with real graphics card (unless somebody can try on real pegasos2 with a real SM501/502 card but those are probably rare so likely nobody has such card). The ATI cards were working even in 16 bit in previous tests so it should be the same result with a passed through card.

@white
Use the official QEMU sources from gitlab (see qemu.org Download menu item), I don't have a separate repo to use now.

I think you can set optimization level from configure without editing meson.build by adding -Doptimization=3 to configure. That would be better than modifying meson.build because then you can easily update from git. I don't know how much difference it makes but if you use opt 3 and see problems also check with the default optimization level just to make sure it's not some compile error. The results of opt 3 on Linux with gcc might be different than on macOS with clang.

For your QEMU command line -cpu 7457 -accel tcg are the default so you can drop these, only need to add -cpu if you want to use other than the default 7457 CPU. You can use -display gtk,zoom-to-fit=on,full-screen=on instead if separate -full-screen option that may be removed at some point and specifying it as a -display option is now preferred.

Instead of separate -drive if=none and corresponding -device ide-hd option there's a shortcut to define a drive with one option:

which does not need a separate -device ide-hd option so it's shorter and more readable. (Since QEMU 9.0 this also works with sam460ex now which previously did not support these short options.)

@Hans
I said I don't mind if others don't support or believe in free software and have other views. I just wanted to make clear my point of view and explain why I won't do much with this problem. I think it's better to be clear about that than just saying nothing so you don't have to wait if I reply or not and can go ahead with this task. What I said is not against you personally so don't take it as that.

I think keeping things closed especially in such small community just hinders progress and leads to unnecessary fights over who owns what and who gets the crumbs. It may be better to do like other communities who are keeping their beloved platform alive together like Haiku for example. AmigaOS is already obsolete and not fit for daily use (e.g. lacking support for modern hardware, memory protection, security and SMP just to name a few) so there's not much commercial value there and there isn't much hope that the handful of people who can be payed to work on it will ever make it reach the level of modern systems (or if their work will be published at all as others are still fighting over who can publish it in the first place). Making AmigaOS modern and a viable alternative OS would only be possible by allowing contribution from passionate developers but if they are discouraged seeing this state there won't be much progress. It reminds me of the book title from David "From Vultures to Vampires", looks like for AmigaOS4 we're still watching the vultures tearing apart the remains of it. I'd like to see a modern AmigaOS but I don't think the current closed source way will lead to that in our lifetime. So those who in charge may consider if there's some better way. That's why I don't want to help to keep the status quo and rather advocate free software. Sorry if this offends some people, I don't want to attack anybody just discuss views and get people consider alternative ways.

Some people are payed to work on free software so closed source is not the only way to earn a living. Even if kas1e could pay me I could not do much as I don't have the AmigaOS kernel source. If you get payed and fix it that still won't help me as I likely won't get a fixed version so there isn't much motivation for me to do much with this.

@Capehill
That changelog says "Compositing requires PatchCompositeTags on WinUAE, for example." I don't know what that does or means but if it's patching some kernel routines to work without hardware compositing then maybe that would be a solution here as well? It's still strange why the amigaone kernel works while pegasos2 has problems but despiite the two machines being similar in hardware the pegasos2 kernel also lacks some IRQ init that the amigaone one does so there might be some differences between these kernels.

@Capehill
Not sure what would be the correct output but I've tried it on QEMU amigaone,pegasos2,sam460ex machines just booting the 4.1FE install CD. The 8 bit and 32 bit looks the same on all 3 machines but 8 bit has text in different colors and gray background and 32 bit has all black text on gray background. The 16 bit one has blue-green background with black text and on pegasos2 also the text is broken (endianness issue?) whereas on amigaone (with same 7457 default cpu as pegasos2) and sam460ex the text is OK even in 16 bit mode. Using -M pegasos2 -cpu 750cxe fixes text in 16 bit mode. (This was tested before with SDL that endianness issues only happen on pegasos2 and with G4 CPU.)

To me this looks like some problem with pegasos2 kernel again assuming other components are the same on all three machines.

Maybe it would also be interesting to see how it displays on real sam460ex with the on-board SM502. Anybody could try that for comparison?

Software is licensed and you can only use it according to its license. The author has the right to decide what license the sofware is published under. It does not matter what you think, you only have two choices: accept the licence or not use the software. (This is also true for free software under GPL. You can use, distribute, modify it freely, even can ask for money to support it, but you can't make it non-free and have to give the same rights you got to others.) Those who produce commercial products and expect people to follow their licenses should also follow the license of the components they use themselves and should check and comply to those licenses.

In this case the HDA driver's license says it's only for non-commercial personal use and cannot be distributed as part of a commercial product or ask money for it. (I don't think this can be revoked once it's published so this driver version is still available under those terms and it allows to be distributed for personal use.) But the author can ask it to be removed from commercial products (or try to ask for some money for past "damage" but maybe there's not much profit made on any of this and we don't need more court cases so getting some agreement may be a more sensible approach).

The authors also have the right to decide if they want to support it further. license further versions under different license or stop making further versions. You can't force them to do something they don't want to.

Maybe people are too passionate about all these Amiga stuff and still hold on to their pieces which just hinders development so it would be better if there could be more cooperation instead of competition and forget commercial thinking where there's no real market but this seems to be the state of things now. I can only hope it will change in the future.

@Hans
Quote:

Then this may be a limitation in RTAS as it only has provision to pass a single address but not PCI domain or host. So if RTAS on pegasos2 interprets bus 1 as the AGP port (which is really another PCI domain) then maybe there's no way to access devices on bus 1 on the default PCI domain. You can test this theory if you get data from the AGP port with bus 1 and device for the card on that bus. Then reading bus 1 for device behind the bridge would try to access the wrong PCI domain and so won't find a device there because you can't have bus mean both bus and PCI domain so you could either access all devices on one domain or bus 0 of all domains depending on what RTAS uses the bus part of the PCI address for.

If my theory is true then you probably can't use RTAS and you'd need to write a proper PCI driver in AmigaOS to be able to access all devices on all domains. I could help with that but I only work for free on open source projects that I can then also use myself. But if I won't get the result and you're payed to do that and not me I'll let you figure that out (or you can hire me for consulting if needed). It's not difficult though, accessing PCI is not much different from other platforms which is well documented and I've already given you the docs where it's explained for pegasos2 as well. Also my code is free to study (not for copying into commercial projects though, so you should not copy&paste it but write your own from what you've learned from it).

Sorry for that but I believe in free software. I don't mind if others don't but then the rules of commercial software should be applied for those projects which means you get what you pay for.

@kas1e
I've read somewhere: "If all else fails read documentation." Ever thought about that? If you want to learn Forth try forth.com. Have you even seen old reverse Polish notation calculators that are stack based? Those where you had to type 5 3 + Enter or something like that to add two numbers and display the result? Forth works like that, so you have to push arguments to stack then call operation word and then you can find results on the stack that you need to print to get the result.

But this probably does not matter as it seems even if you can get the needed values from the SmartFirmware prompt they may not be accessible via RTAS.

@Hans
You probably don't have to be concerned about the PCI domain. I think a domain corresponds to a /pci node in the device tree but since the bridge and the devices behind it appear in the first domain where are all the other PCI devices it should be accessed the same way and don't need to consider the other domain where is only the AGP port. I don't know how this works with RTAS, but in OF you can cd into the right /pci node to call the corresponding config words for that domain or may need to open the device node first. The config words should take address in the same format as it appears in the device tree and I think the same should be true for RTAS or these mostly follow the same address encoding that the PCI spec describes and also shown in the OF PCI doc.

@kas1e
I would also have to read the OpenFiware PCI docs to check how the config-* words work, I don't remember that now. So you could have a look at that doc then try to read config space vars like vendor/device ID and BARs of your gfx card behind the bridge from the OpenFirmware prompt just to verify it works on the OF level at least and to find the right address that should work with RTAS too. Maybe access the SmartFirmware prompt via serial from another machine so you can cut&paste and don't have to type that much.

I don't know what Debian did, you have not posted enough details to understand what happened there. Maybe posting full Debian logs from boot and BBoot output with the card may help to see more (BBoot won't handle bridges but if the card appears in the device tree it should at least list basic info on it).

But I don't have PegasosII hardware, don't have these gfx cards and even if I had a card and it works with QEMU with pass through I don't have AmigaOS drivers for it so I'm not much interested in this.

@Hans
Quote:
I wrote it after reading the OpenFirmware PCI doc I've linked to above. Maybe also check the Marvell Discovery II docs as that provides the PCI bus on pegasos2.
Quote:
These are from libpayload as can be seen in the comment at the top of the file.

Did you try if you can access the card behind the bridge with config-l@ config-w@ and so on from the SmartFirmware prompt? Maybe you're just passing the wrong address to the RTAS function that's why it does not read the right bus.

@Hans
I don't know of any docs on pegasos2 specifically but there are some docs on OpenFirmware here: https://openfirmware.info/Bindings and on PCI there are many on the net. You may also look at some BSD sources but not GPL code if you want to use it in non-GPL closed source project.

@kas1e
I think PegasosII SmartFirmware may have a limit on how many blocks it can read so the boot partition should be at the beginning of the disk (maybe below some cylinder/block limit). Maybe it does not need to be hd:0 but if it's at the end of a large disk that's outside the limit. Try to put it fully within the first 2GB or so. It probably tries hd:0 by default that's why it says it should be first otherwise you'd need to type boot hd:1 ... or set some env var.
Also pegasos2 kernels contain an initrd so you may either need such kernel or some boot loader to load both kernel and initrd. So maybe you need to boot cuimage or boot img which have embedded initrd instead of vmlinuz that may be just the kernel.
I have some docs on what Linux distros I could boot on emulated machines here: https://www.qemu.org/docs/master/system/ppc/amigang.html I think for pegasos2 Debian 8.11 was the latest that supported it but maybe there some unofficial later versions.

@geennaam
Quote:
Is there a way to measure that? If adding a USB drive slows down the CPU even if it's idle then there's some problem somewhere. Unless you use that device why should it take CPU cycles just to have it mounted? If there's some way to show or measure this CPU slow down with the usb-storage then maybe we could find out what causes the slow down by profiling that to show where it slows down.