Radeon display core register map
Radeon display core register map
I am thinking about buying a bundle of some older AMD graphics cards for experimenting (mostly Northern Islands GPUs). I can find a lot of documentation for their ISA and 3D engine, but not much about 2D (modesetting and stuff). All I know is that they use DCE5 display engine. I bet I could reverse Linux drivers, but that's a lot of work. Am I missing something?
Re: Radeon display core register map
In order to configure the device, there does not seem to be any alternative to Linux sources.
One can cut down on the amount of code that needs to be written by noting down the exact versions of the structures that your particular card must adhere to.
The major steps involved in configuring the device are:
(1) Implementing the ATOMBIOS virtual machine.
(2) POSTing the BIOS by executing the ATOM_CMD_INIT table (on the said virtual machine)
(3) Loading the microcode and 'golden' registers.
(4) Intializing the power manager (DPM) to the default clock and voltage.
(5) Initializing the rings (DMA, IH, GFX). The drivers also run simple tests on GFX and DMA rings to see that the rings are setup correctly and that the GPU responds to the commands. You can initially set up a target to reach this state, since it helps confirm that the above steps at least bring the GPU where its command processor is in a working condition.
(6) Setting up GART (seems optional if you do not have a need for it). This is the reverse of the PCIe window. Through GART, the GPU can access page frames of system RAM.
(7) Modesetting the selected mode (initializing the crtc, encoder, and connectors, and changing the power state to correspond to the selected mode. The virtual machine again is utilized here).
Scanning the Linux driver source first should help you reach the understanding of the general layout of the steps.
The ATOMBIOS itself can be dissassembled to see what code its runs. Dissassemblers such as AtomDis are available on the web. But, there's no need to disassemble the BIOS for normal functioning of the card; make sure that the virtual machine instructions are implemented correctly, else incorrect implementations can potentially hang the host system (even if the card is passed through to a x86 VM) while running the BIOS code.
There are old demos that you can find in order to get an idea about filling up the command streams.
One such demo is here: https://gitlab.freedesktop.org/mesa/r600_demo.
One can cut down on the amount of code that needs to be written by noting down the exact versions of the structures that your particular card must adhere to.
The major steps involved in configuring the device are:
(1) Implementing the ATOMBIOS virtual machine.
(2) POSTing the BIOS by executing the ATOM_CMD_INIT table (on the said virtual machine)
(3) Loading the microcode and 'golden' registers.
(4) Intializing the power manager (DPM) to the default clock and voltage.
(5) Initializing the rings (DMA, IH, GFX). The drivers also run simple tests on GFX and DMA rings to see that the rings are setup correctly and that the GPU responds to the commands. You can initially set up a target to reach this state, since it helps confirm that the above steps at least bring the GPU where its command processor is in a working condition.
(6) Setting up GART (seems optional if you do not have a need for it). This is the reverse of the PCIe window. Through GART, the GPU can access page frames of system RAM.
(7) Modesetting the selected mode (initializing the crtc, encoder, and connectors, and changing the power state to correspond to the selected mode. The virtual machine again is utilized here).
Scanning the Linux driver source first should help you reach the understanding of the general layout of the steps.
The ATOMBIOS itself can be dissassembled to see what code its runs. Dissassemblers such as AtomDis are available on the web. But, there's no need to disassemble the BIOS for normal functioning of the card; make sure that the virtual machine instructions are implemented correctly, else incorrect implementations can potentially hang the host system (even if the card is passed through to a x86 VM) while running the BIOS code.
There are old demos that you can find in order to get an idea about filling up the command streams.
One such demo is here: https://gitlab.freedesktop.org/mesa/r600_demo.