GART patch for RadeonRX on SAM460

@All

So I have successfully created a patch that enables GART in RadeonRX 2.12 on the Sam460 (only the Sam460; the 440
is not supported for now).

Grab it here: https://kas1e.mikendezign.com/aos4/mesa/sam460_rx212_gart_patch.zip

The only supported version is RadeonRX 2.12 on the Sam460. Only two variants of 2.12 are supported:

- release version of 2.12 driver (size 1.772.772)
- debug version of 2.12 driver (size 1.901.344)

The placement order in the Kicklayout doesn’t matter: its cold-start priority is +66,so it runs before RadeonRX’s
RXCardPatch, which has priority +65.

To be sure that it works, you should see this line on the serial when the patch runs and correctly activated:




Don’t expect big improvements, but at least some. Here are some relevant results showing what you may expect:


Tests done on my SAM460LE + RadeonRX 560 2GB:





Now if someone want technical details how it done, there is:


As you may know, Radeon RX already contains GART support for other machines, so the core functionality was there;
but its Sam460 path is off and lacks the required platform-specific handling. Of course, we can’t simply enable
it, as doing so safely requires the correct Sam460 specific initialization (thanks to Max for sharing necessary
information), proper memory attributes, CPU/GPU cache synchronization and a few small driver corrections.

So, to enable it, the patch does not modify the real binary, but instead patches it in memory. All changes remain
active until reboot, while the actual driver file remains unchanged. I had to patch the necessary allocation and
cache-management paths to redirect them to my own hooks (mostly with a one instruction change). The hooks then
continue into the original functions while adding the required memory and cache handling.And while this may sound
complicated, it is still simpler than replacing the whole memory manager.

Technically speaking, this is what happen when you load this .kmod patch:

-- Verifies the exact RadeonRX2.12 (resident version number, few insructions match and required memory mappings)

-- Patches private RadeonRX funcs by installing hooks in its GART allocs, mapping, and cache-management paths.

-- The hooks provide the missing Sam460-specific handling:

- When RadeonRX allocates GART-related memory,the hook lets the original allocation complete and then applies
the correct memory attributes to the actual allocated range.
- When memory ownership moves between the CPU and GPU, the hooks perform the required cache flushes,invalida-
tions, and synchronization and then preserve the original RadeonRX operations and return control to the
driver afterward.

-- Finally, using the Sam460 MMU setup information provided by Max, the module sets the required PPC460EX MMU
control bit and opens RadeonRX’s existing GART gate. RadeonRX then continues its normal initialization using
its own GART allocator and memory manager.

One of the trickiest parts of creating the patch was modifying RadeonRX’s loaded executable code because its code
pages are protected by the MMU. They are readable and executable but not writable, so attempting to replace an
instruction directly causes a DSI exception, even in supervisor mode..

The CPU in Sam460 uses 2 TLB translation spaces called TS0 and TS1. They are two separate sets of physical memory
address mappings that the CPU can select independently for execution and data access. And on Sam460, the RadeonRX
driver address is mapped in both spaces as follows:



As expected,when I tried to write through TS1,which is not writable,it naturally caused a DSI. But I still needed
to modify the instructions used through TS1, because those are RadeonRX’s executable code.

Since I found that TS0 maps the same physical memory, is writable, and has matching cache attributes,this gave me
an idea: while the patch code is running, instruction execution remains in TS1, while data access is temporarily
switched to TS0 only to write each replacement instruction (usually a branch to one of our hooks).

I.e.:



Before each write, the module verifies the expected original instruction through the normal TS1 mapping and then
after writing the replacement through the writable TS0 mapping, it restores data access to TS1 and synchronizes
the data and instruction caches, so the CPU executing through TS1 sees the modified instruction. It then checks
the result through the normal protected mapping and banana!

So give it a go plz, and report your finding.

And if you like it , remember that driver itself were done by Hans, and necessary SAM460 adaptation information
were provided by Max, i only hack and slash the memory.


Thanks!

Not an Sam460 user, but Спасибо !