Without the driver inside the kicklayout , the PEX8111 chip and RX460 has all of the required (i think) 'commands' in order to be used, but the Pex chip loses IO and MEM and the Radeon gets disconnected when I put the RadeonRX.chip in the kickstart layout.
Also the RX.chip needs to put at the top of the layout otherwise uboot gives an error when loading the file, it also can't seem to co-exist with Petunia and USB so they have to be commented out.
Not that I expect anything out of it, but is there a way to get debugging info from uboot with a serial cable?
Fully aware that I'm digging myself a deeper hole here.
Edited by Helloworld on 2020/3/25 21:22:37 Edited by Helloworld on 2020/3/25 21:35:22
Looks like you have the driver starting up. So, can you see the RX 460's screen modes in ScreenMode prefs? Have you tried using them?
You may notice that ranger reports your card as having interrupt line 0xFF. From memory, that's wrong, and the machine will lock up the moment the graphics card sends an interrupt. So, you'll need to disable interrupts for that card.
Looks like you have the driver starting up. So, can you see the RX 460's screen modes in ScreenMode prefs? Have you tried using them?
Sorry, should have been more clear about it.
There are no screenmodes for the Polaris card as it does not get initialized and stays idle with a blinking cursor.
The Ranger shot is with the driver commented out of the kickstart layout, in which case I can boot with the 460 as the main card in uboot and it will switch to the 9250 after the kickstart files are loaded. with the RadeonRX.chip included in the kickstart layout then the RX460 will get disconnected and the pex chip will lose "IO" and "MEM" in Ranger.
Trying to boot with the RX460 as the main display in uboot with the RadeonRX.chip seems to result in a instant crash after the kickstart files are loaded, all drive activity immediately stops and the caps, num and scroll lock keys don't respond on the the ps/2 keyboard.
The Dumpdebugbuffer shot is captured with the 9250 and RadeonRX.chip but with the startup-sequence skipped as the 460 does not get initialized. the OS gets stuck in a inifinite loop at the OS4 splash screen after the kickstart files are loaded. (no crash, can still soft and hard reboot and go into the early start menu with the 9250)
The system has two monitors, "Radeon" and PCIGraphics both with interrupts unchecked.
Seems like it has the same dead ends as with the 7750 card last time, which is why I thought it would be a good idea to log what uboot is doing although I probably should have asked how to do that first on the Hyperion forums.
Ordered a serial cable which should arrive in a few days.
Edited by Helloworld on 2020/3/27 5:06:00 Edited by Helloworld on 2020/3/27 5:10:36 Edited by Helloworld on 2020/3/27 5:17:41
The Dumpdebugbuffer shot is captured with the 9250 and RadeonRX.chip but with the startup-sequence skipped as the 460 does not get initialized. the OS gets stuck in a inifinite loop at the OS4 splash screen after the kickstart files are loaded. (no crash, can still soft and hard reboot and go into the early start menu with the 9250)
The debug log entries starting with RadeonRX say that the RX 460 *is* being initialized. It's just not being used as the primary card.
The serial cable arrived, still need to figure out how to log debugging info from AmigaOS.
Been following this wiki page and so far I've been only able to log system configuration information and nothing while loading the kickstart files.
I guess it's because uboot has its serial baudrate at 115200, but AmigaOS' serial settings don't allow baudrate to go higher than 31250
Also using both "Serial" and "Munge" together in the commandline causes the system to crash.. off to the Hyperion forums...
I tried to use the RadeonRX.chip.debug driver with the debug kernel, but when I put both in the kickstart layout it causes uboot to fail loading the newlib library, which I cannot comment out, so it's either Radeon.chip.debug or kernel.debug.
I gave a shot capturing the debug buffer with RadeonRX.chip.debug alone with the startup-sequence skipped.
The RadeonRX.chip.debug will also remove MEM and IO from the Pex chip and disconnects the Polaris card.
The debugbuffer isn't much different when booting the first time
Quote:
RadeonRX (2): Could not identify the chipset RadeonRX (2): Identified the chipset as: POLARIS11 RadeonRX (2): Graphics card name is: Radeon RX Polaris11 RadeonRX (2): If - and only if - your card does not work or does not work optimally please submit a bug report at: http://www.spam.com/bugreports Remember to include the driver version, and the following card details: 0x67EF:0x174B:0xE348: <name of board> and *please* describe the problems you are seeing in detail. graphics.library AltiVec/VMX enabled graphics.library PPC74xx optimizations enabled RadeonRX (5): findRXCard called RadeonRX (5): Card 0 (0): 0x1002, 0x5960, unknown, other driver, active RadeonRX (5): Calling original FindCard() RadeonRX (5): Found a graphics card RadeonRX (5): initRXCard called RadeonRX (5): Calling original InitCard() 0000: 00 FF FF FF FF FF FF 00 22 F0 22 30 01 01 01 01 ........"."0.... 0010: 23 17 01 03 80 26 1E 78 2E FD 25 A2 58 4F 9F 26 #....&.x..%.XO.& 0020: 0D 50 54 A1 08 10 81 80 01 01 01 01 01 01 01 01 .PT............. 0030: 01 01 01 01 01 01 30 2A 00 98 51 00 2A 40 30 70 ......0*..Q.*@0p 0040: 13 00 78 2D 11 00 00 1E 00 00 00 FD 00 32 4C 18 ..x-.........2L. 0050: 53 11 00 0A 20 20 20 20 20 20 00 00 00 FC 00 48 S..............H 0060: 50 20 4C 41 31 39 35 36 78 0A 20 20 00 00 00 FF P.LA1956x....... 0070: 00 33 43 51 33 33 35 31 4A 43 48 0A 20 20 00 CF .3CQ3351JCH..... 0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
The RX driver seems to find the 9250? It finds card 0, 0x5960 is the Radeon 9250, it also prints a hex table, with "HP.LA1956x" which is the monitor the 9250 is connected to.
The 460 is connected to a BenQ 17-TZ1 1280x1024 lcd monitor via DVI.
Doing a softreset gives alot more information
Quote:
[RAM] Handler has started successfully. [DebugLevel=7] RadeonRX (5): findRXCard called RadeonRX (5): Card 1 (2): 0x1002, 0x67EF, Radeon RX Polaris11, supported, inactive RadeonRX (5): Found supported card RadeonRX (5): initRXCard called RadeonRX (5): Initializing card RadeonRX (2): Obtaining ITimer interface RadeonRX (2): Got ITimer interface RadeonRX (2): Returning from LibOpen(). RadeonRX (0): RadeonRX.chip 1.11 (14.8.2018) RadeonRX (6): <rxOpen> RadeonRX (4): Have altivec. RadeonRX (4): PCI device is a graphics card. RadeonRX (2): Identified the chipset as: POLARIS11 RadeonRX (2): Graphics card name is: Radeon RX Polaris11 RadeonRX (2): If - and only if - your card does not work or does not work optimally please submit a bug report at: http://www.spam.com/bugreports Remember to include the driver version, and the following card details: 0x67EF:0x174B:0xE348: <name of board> and *please* describe the problems you are seeing in detail. RadeonRX (5): RadeonRX (5): PCI_DEVICE_ID: 0x8111 RadeonRX (5): RadeonRX (5): PCI_VENDOR_ID: 0x10B5 RadeonRX (5): RadeonRX (5): PCI_STATUS: RadeonRX (5): ECP enable, RadeonRX (5): 66 MHz capable, RadeonRX (5): RadeonRX (5): RadeonRX (5): DEVSEL# timing 1, RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): PCI_COMMAND: RadeonRX (5): RadeonRX (5): RadeonRX (5): Bus master enabled, RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): PCI_CLASS: 0x60400 RadeonRX (5): RadeonRX (5): PCI_REVISION_ID: 0x21 RadeonRX (5): RadeonRX (5): PCI_HEADER_TYPE: 0x1 RadeonRX (5): RadeonRX (5): PCI_LATENCY_TIMER: 32 RadeonRX (5): RadeonRX (5): PCI_CACHE_LINE_SIZE: 8 RadeonRX (5): RadeonRX (5): PCI_SEC_LATENCY_TIMER: 0 RadeonRX (5): RadeonRX (5): PCI_PRIMARY_BUS: 0 RadeonRX (5): RadeonRX (5): PCI_SECONDARY_BUS: 2 RadeonRX (5): RadeonRX (5): PCI_SUBORDINATE_BUS: 2 RadeonRX (5): RadeonRX (5): PCI_SEC_STATUS: RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): DEVSEL# timing 0, RadeonRX (5): RadeonRX (5): RadeonRX (5): Received master abort, RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): PCI_IO_BASE (full): 0x3000 RadeonRX (5): RadeonRX (5): PCI_IO_LIMIT (full): 0x3FFF RadeonRX (5): RadeonRX (5): PCI_MEMORY_BASE (full): 0xB0200000 RadeonRX (5): RadeonRX (5): PCI_MEMORY_LIMIT (full): 0xB02FFFFF RadeonRX (5): RadeonRX (5): PCI_PREF(ETCH)_MEMORY_BASE (full): 0xA0000000 RadeonRX (5): RadeonRX (5): PCI_PREF(ETCH)_MEMORY_LIMIT (full): 0xB01FFFFF RadeonRX (5): RadeonRX (5): PCI_BRIDGE_CONTROL: RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): VGA enable, RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): RadeonRX (5): PCI_INTERRUPT_PIN: 0x1 RadeonRX (4): Enabling blind prefetch on the PEX 8111 bridge RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.7,0, because it is not a bridge device. RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.7,0, because it is not a bridge device. RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.7,0, because it is not a bridge device. RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.7,0, because it is not a bridge device.
PCI_INTERRUPT_PIN: 0X1 instead of 0xFF? The PEX8111's interrupt pin is 0x00 and the 9250's interrupt pin is 0x0A
It then proceeds to print "RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.7,0, because it is not a bridge" a couple hundred times it seems and suddenly ends.
Enabling the Radeon and PCIGraphics monitors won't affect the debug buffer
I gave that a go by putting newlib on the top of the layout, before RadeonRX.chip.debug.
Now it fails loading the intuition library, trying to put intuition.library.kmod before newlib or right after it will make it fail loading the graphics.library.kmod instead.
I don't think shuffling kickstart files around would help anymore, as it seems it always fails loading halfway the layout. I really ought to make that serial thread at Hyperion now.
Well yes because most things needs newlib.. unless they are statically compiled with Clib and newlib might need exec and that be the kernel, I guess. And I guess that intuition need to loaded before the driver.
But I do not know the full dependency’s tree so it better not to mess with it.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Looks like the pci-bridge reprogramming code is ending up in an infinite loop. Will need to fix that...
Quote:
PCI_INTERRUPT_PIN: 0X1 instead of 0xFF? The PEX8111's interrupt pin is 0x00 and the 9250's interrupt pin is 0x0A
I can't remember which slot uses which interrupt line, but 0xFF is wrong. The easiest way to find out is to stick a known working card in that slot, and check what Ranger says it was assigned.
Tried swapping around the sil0680 ide controller and got the following interrupt lines from the 33mhz slots
Upperslot: Line: 0x09 Pin: A Number: 25 (Previously PEX)
Middleslot: Line: 0x0B Pin: A Number: 27
Bottomslot: Line: 0x0A Pin: A Number: 26
The PEX8111 bridge chip got the same interrupt in every slot,
PEX8111: Line: 0x00 Pin: A Number: 16
Polaris11: Line: 0xFF Pin: A Number: 271
Also got serial output working from OS4, and you're right about "RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.7,0, because it is not a bridge" being an infinite loop, as it gets continuously printed when it gets stuck on the OS4 splash screen when booting with the 9250 and the Polaris driver included in the kicklayout file.
Some most likely inane findings
Trying to enable the PCIGraphics monitor when skipping the startup-sequence does start the RadeonRX driver and but doesn't go further than the following
Quote:
RadeonRX (5): RadeonRX graphics.library AltiVec/VMX enabled graphics.library PPC74xx optimizations enabled RadeonRX (5): findRXCard called RadeonRX (5): Card 0 (0): 0x1002, 0x5960, unknown, other driver, active RadeonRX (5): Calling original FindCard() RadeonRX (5): Found a graphics card RadeonRX (5): initRXCard called RadeonRX (5): Calling original InitCard()
System also is about to collapse as drawers and programs don't respond anymore.
The driver also prints this when trying to boot straight from the Polaris card in uboot and then halts after loading the kickstart files, it's also the only thing OS4 prints to the serial terminal.
Also discovered that the PEX card and the RX460 only get IO and MEM if the 460 is used as the uboot display card and the driver excluded from the kicklayout. booting with the 9250 as the uboot display card removes them, even though the driver is also excluded.
@LiveForIt
Does seem like some of the files are depended on others loading first. booting with the following order makes it fail much sooner when loading RadeonRX.chip
Still, strange though that the normal versions of the kernel and RadeonRX driver just work together as is but not the debug versions.
I have multiple configurations inside my kicklayout file and have it backed up on a usb stick, so I can mess around with it as much as I want. should anyone have a idea on how it should be ordered let me know.
Edited by Helloworld on 2020/3/31 0:14:40 Edited by Helloworld on 2020/3/31 0:21:46
Tried swapping around the sil0680 ide controller and got the following interrupt lines from the 33mhz slots
Upperslot: Line: 0x09 Pin: A Number: 25 (Previously PEX)
Middleslot: Line: 0x0B Pin: A Number: 27
Bottomslot: Line: 0x0A Pin: A Number: 26
The PEX8111 bridge chip got the same interrupt in every slot,
PEX8111: Line: 0x00 Pin: A Number: 16
Polaris11: Line: 0xFF Pin: A Number: 271
That's a UBoot bug. It should set the Polaris11's line, pin & number to match whatever the values for that slot are.
When I first started working on the RadeonHD.chip driver, I hard-coded the IRQ line into the driver for the slot I put it in. I cannot do that in a production driver, because those values vary by motherboard, & the driver doesn't know which slot you put the card in.
Quote:
Trying to enable the PCIGraphics monitor when skipping the startup-sequence does start the RadeonRX driver and but doesn't go further than the following
It's not really starting the RadeonRX driver. That's the PCIGraphics.card patch code passing control back to the original PCIGraphics.card.
Quote:
Also discovered that the PEX card and the RX460 only get IO and MEM if the 460 is used as the uboot display card and the driver excluded from the kicklayout. booting with the 9250 as the uboot display card removes them, even though the driver is also excluded.
That's a UBoot bug. It should set the Polaris11's line, pin & number to match whatever the values for that slot are.
When I first started working on the RadeonHD.chip driver, I hard-coded the IRQ line into the driver for the slot I put it in. I cannot do that in a production driver, because those values vary by motherboard, & the driver doesn't know which slot you put the card in.
oh wow
I understand that hardcoding IRQ's should not be done for a production driver, but maybe there could be a way for the end user to set IRQ?
Perhaps via an user created .txt file in the kickstart folder as an unsupported "as is - backdoor" kind of method?
I understand that hardcoding IRQ's should not be done for a production driver, but maybe there could be a way for the end user to set IRQ?
Perhaps via an user created .txt file in the kickstart folder as an unsupported "as is - backdoor" kind of method?
Theoretically, yes. You could add a kickstart module that runs before the graphics driver is started that fixes the IRQ. However, that would be rather hacky, and might be a pain in the butt to get right.
There are some settings regarding PCI (and AGP) IRQ in UBoot's menus, IIRC. Don't know if they are what is needed for this issue, though.
Setting the interrupt for the slot to "edge triggered" might prevent a total machine lockup, but the driver still wouldn't receive interrupts because the IRQ line was incorrectly set up by UBoot.
Uboot gives the option to change the IRQ number (7/9/10/11/13/Auto) and IRQ detection of PCI slots to "level" or "edge"
I can change the IRQ detection from slot A to slot D, not sure which is which as they aren't marked on the PCB or in the PDF manuel.
Here's a shot from the 7750 thread, where AmigaOS calls them interrupt A through D instead.
I tried to change detection from level to edge of one slot at a time and made sure to reboot after changing detection methode.
Setting any to Edge won't avoid the system getting stuck during the OS4 splash screen with "RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.7,0, because it is not a bridge device." continuously being printed to the terminal.
Trying to boot straight from the RX460 will still fail after loading the kickstart files with normal and debug drivers.
changing IRQ number doesn't seem to change anything.
Quote:
Better leave interrupts disabled for now...
Good to hear, I somehow made myself under the impression that IRQ was required for it to work, could you tell me what the disadvantage is of having interrupts disabled if you would mind?
Also does it matter for the driver that uboot has it's PCI/AGP bootcard option backwards? booting from AGP option will boot with the PCI card and vice versa.
Sorry to suddenly leave you both hanging, have been ill. (no corona)
Setting any to Edge won't avoid the system getting stuck during the OS4 splash screen with "RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.7,0, because it is not a bridge device." continuously being printed to the terminal.
Sorry, that's a driver bug. You won't be able to get beyond that until a fix is released.
Quote:
changing IRQ number doesn't seem to change anything.
Changing the IRQ number won't help, because you can't change it to the incorrect number that UBoot set it to (0xFF = 255).
Quote:
Good to hear, I somehow made myself under the impression that IRQ was required for it to work, could you tell me what the disadvantage is of having interrupts disabled if you would mind?
Interrupts is faster and more accurate. Without interrupts, the driver has to sit and poll until the next frame occurs (it's the vblank interrupt that you can enable/disable). That wastes CPU cycles, and also increases the chance that it'll be detected late.
Quote:
Also does it matter for the driver that uboot has it's PCI/AGP bootcard option backwards? booting from AGP option will boot with the PCI card and vice versa.