pegasos2: rom reconstruction

@kas1e
Let's wrap up the radeonrx topic first.

pegasos2.rom.org = original firmware pegasos2.rom
pegasos2_kas1e.rom - your new firmware version
testkas1e.hdf = disk image with AmigaOS 4.1FE containing Update 3 (kernel 54.57) and standard boot via amigaboot.off
testkas1e-2.hdf = disk image with AmigaOS 4.1FE containing Update 3 (kernel 54.57) and standard boot via bboot (bboot.fth)
Tested on an ASUS RX 560 Dual Fan OC 2 GB graphics card and QEMU-11.

1. Booting on the original PEG2 firmware and standard system boot
".qemu-system-ppc -M pegasos2 -m 1024 -bios pegasos2.rom.org -rtc base=localtime -serial none -vga none -nographic -parallel none -device ide-hd,drive=hd-drive,bus=ide.0 -drive file=testkas1e.hdf,if=none, id=hd-drive,format=raw -device vfio-pci,host=01:00.0,x-vga=on,multifunction=on,bus=pci.0,x-igd-gms=0xff -device vfio-pci,host=01:00.1,bus=pci.0....."

The system does not boot; there is no firmware output screen on the RadeonRX card.

2. Booting on the original PEG2 firmware and booting the bboot system
".qemu-system-ppc -M pegasos2 -m 1024 -bios pegasos2.rom.org -rtc base=localtime -serial none -vga none -nographic -parallel none -device ide-hd,drive=hd-drive,bus=ide.0 -drive file=testkas1e-2.hdf,if=none, id=hd-drive,format=raw -device vfio-pci,host=01:00.0,x-vga=on,multifunction=on,bus=pci.0,x-igd-gms=0xff -device vfio-pci,host=01:00.1,bus=pci.0....."

The system boots correctly, no firmware output screen on the RadeonRX card
screen -> https://ibb.co/YBJjdy4N

3. Booting on the new PEG2 firmware and standard system boot
".qemu-system-ppc -M pegasos2 -m 1024 -bios pegasos2_kas1e.rom -rtc base=localtime -serial stdio -vga none -nographic -parallel none -device ide-hd,drive=hd-drive,bus=ide.0 -drive file=testkas1e.hdf,if=none, id=hd-drive,format=raw -device vfio-pci,host=01:00.0,x-vga=on,multifunction=on,bus=pci.0,x-igd-gms=0xff -device vfio-pci,host=01:00.1,bus=pci.0....."
The system does not boot; there is a firmware output screen on the RadeonRX card.
screen -> https://ibb.co/8LGzjYyw


screen ->https://ibb.co/HDWggYfc
In AOS4 debug mode, an infinite loop of the error “Could not get the video RAM resource range” appears continuously.

4. Booting on the new PEG2 firmware and starting the bboot system.
".qemu-system-ppc -M pegasos2 -m 1024 -bios pegasos2_kas1e.rom -rtc base=localtime -serial stdio -vga none -nographic -parallel none -device ide-hd,drive=hd-drive,bus=ide.0 -drive file=testkas1e-2.hdf, if=none,id=hd-drive,format=raw -device vfio-pci,host=01:00.0,x-vga=on,multifunction=on,bus=pci.0,x-igd-gms=0xff -device vfio-pci,host=01:00.1,bus=pci.0....."
The system does not boot; there is a firmware output screen on the RadeonRX card.
screen -> https://ibb.co/8LGzjYyw

In AOS4 debug mode, an infinite loop of the error “Could not get the video RAM resource range” appears continuously.

screen-> https://ibb.co/HDWggYfc

RadeonRx only works on my machine with the original pegasos2.rom firmware and bboot..

@kas1e
Quote:
Here's a very simple example using sm501 in QEMU.
Test code:

Based on this example, it seems that pegasos2_kas1e.rom is trying to change something it shouldn't. Perhaps when it is unable to initialize VGABIOS, it tries to force a change?
The original pegasos2.rom behaves correctly.
test video -> https://youtu.be/ZSJgQdRSdZQ

@smarkusg
Ok thanks, that enough for me to play with, will keep you informed once deal with or have more info about.

@mlehto
Quote:

Any gfx card have it's x86 bios which we run over emulator, which do "POST" (basic init of video card, etc): so, we do this "emulator POST initialization" only for the card we choose (that only for firmware itself) , so to avoid extra time spend on card which is not the one to show firmware on.

@kas1e
There is one more thing that might be useful: I tested pegasos2_kas1e.rom under QEMU on Linux.
For the test, I used ‘-device virtio-gpu-pci’
1.
Test for pegasos2.rom – the system boots up and the kernel loads correctly

2.
Test for pegasos2_kas1e.rom – error when loading the Linux kernel. The system freezes/fails to boot.

At this point, the Linux kernel freezes during boot.

I am unable to test the SM501 on Linux. Support is disabled in the kernel.
# CONFIG_MFD_SM501 is not set

VIRTO has these settings.
CONFIG_DRM_VIRTIO_GPU=m

I think it may be a problem with RTAS. The "instantiating rtas" line is missing in your failed case. RTAS has functions to read PCI config which I think these OSes use so maybe that's not correctly implemented. I think MorphOS does not use it but reads PCI config directly so you can cross check if MorphOS boots, then it's likely an RTAS problem.

@balaton
You're right about that, because I did check it, but I didn't mention it here as the topic concerns AmigaOS4.
Morphos boots up with the sm501 card.

@smarkusg
I don't remember exactly, it was discussed on this forum somewhere, but I think Hans's changes for PCI bridge support in the latest unreleased pegasos2 kernel may also changed AmigaOS to not use RTAS for this so if @kas1e uses that kernel version, that may explain why this problem did not occur there. Earlier in this thread I think @kas1e also mentioned something about RTAS only supporting first PCI bus which is a limitation of how it is defined and cannot easily be changed because it's what the OSes depend on so I think it does not worth trying to fix it in firmware if it's already fixed in the kernel. For QEMU every device is on the PCI bus anyway so this would only be an issue with real machine with a bridge and the easiest way to support that is to release the fixed kernel not to break the firmware for it. Basically I think the OS can use RTAS to discover the devices on the PCI bus including the bridge but then needs to use its own bridge driver to access devices behind the bridge where it can't use RTAS any more.

@balaton
Quote:

In the version i send to smarkusg, RTAS was a blob-massive in c-array taken fully from original. I currently already rewrote it on readable assembler code, but so far it was original which i didn't touch (only lately). But it still of course can be problems as vga based code were new (original sources of smartfirmware didn't have any).

Quote:

Yes, morphos has it's own pci probe code, and it sure like that because when we for example check on what bus and where bridge and device in placed in morphos, it shows the logical: all usuall stuff on pci0/bus0, the AGP video as expected on pci1/bus0 , the bride in pci on pci0/bus0 as expected too, and the card behind the bridge is on pci0/bus1 , as expected too.

On amigaos4, even with fixed kernel, while bridge is on bus0 as expected, the RadeonHD card and it's Audio is on bus 2 , not on bus1 , who know why and what the reasons behind, but looks a bit unlogical.

Also, i do not get why in Ranger on pegasos2 , the whole list is Flat. I mean, for example if we take amigaone and sam boards, when you go to pci bus in ranger, and you check bridge , it have "+" which you can tick, and it will expand to show you what is on this bridge. On pegasos2 , there is no single "+" for anything, everything comes like a flat list. And i do not know why too , because if we use not RTAS in fixed kernel , but direct pci config access, then it should be no "flat" anymore. But maybe RTAS there involved again somehow, dunno.

And yes amigaos4 , originally (and in public kernel) just an RTAS usage. But RTAS on original smartfirmware have bugs as we know, and the ones which i find already is : any non zero PCI bus numbers, (like bus 1 behind a PCI2PCIe bridge), were for first encoded incorrectly and for second routed through the wrong config registers. So as result, read-pci-config and write-pci-config fail.

What Hans did is in 54.57 kernel add fix for 64/32bar issue (the one you fixed in BBOOT before), and this 54.57 kernel is out in public now with update3. Then, in 54.66 he add direct pci config access instead of RTAS , because, and of mention issues i find, and , because there also were issues with reading from wrong memory or something, so he always return 0xFFFFFFFF when trying to do so via RTAS, and then allocation of the memory always were failed (and, that by the way the same on Linux for pegasos2, they also code for RTAS, and also for card behind a bridge have 0x00000000 when trying to alloc memory for).

Now, we in situation of total mess with kernel : it's owned by AEON, and who know if ever any new kernel will be released. I mean, it can ends up that we will have no new kernel release ever.

And, with what we left now (at least as i see it):

RTAS should be fixed in firmware in any case, because

1). we have only 54.57 kernel, and if that will be last one (which we always should think about as a possible outcome), we need to work with that limitation. So, fixing RTAS and related bugs will make it works.

2). Morphos has it's own pci probing code, that ok, but Linux same fail with RTAS, of course, we can add code to linux for direct pci config register usage, but i do not want to , and ISOs of linux long ago done, no one will ever know there any update if i will fix it in linux source code, etc, so , fixing RTAS will help casual known .isos of linux for peg2 to work too with bridge.

So.. What i tried to do for now, is to fix properly RTAS, so os4's RTAS-usage code will have it all correctly, and we will have no needs for kernel update in that regard. But if ever there will be kernel update, then no problems too, as this one will works over direct pci config register usage.

@kas1e
Quote:
Just a guess but it may be confusion between pci and bus numbers. I mean PegasosII has pci0 and pci1 and maybe the bridge was added as pci2 not pci0/bus1?

Quote:
AFAIK it's not AEon only Trevor personally so maybe he's more sensible about letting it released.

Quote:
If you can do that just by fixing the RTAS call alone then that's probably OK but if it also needs changing the device tree I would not go that far for this. But this may be trying to patch up bugs in Linux and AmigaOS kernel instead of fixing those.