@@ -46,6 +46,14 @@ vol-up {
};
reserved-memory {
+ /* The rmtfs_mem needs to be guarded due to "XPU limitations"
+ * it is otherwise possible for an allocation adjacent to the
+ * rmtfs_mem region to trigger an XPU violation, causing a crash.
+ */
+ rmtfs_lower_guard: memory@f5b00000 {
+ no-map;
+ reg = <0 0xf5b00000 0 0x1000>;
+ };
/*
* The rmtfs memory region in downstream is 'dynamically allocated'
* but given the same address every time. Hard code it as this address is
@@ -59,6 +67,10 @@ rmtfs_mem: memory@f5b01000 {
qcom,client-id = <1>;
qcom,vmid = <15>;
};
+ rmtfs_upper_guard: memory@f5d01000 {
+ no-map;
+ reg = <0 0xf5d01000 0 0x2000>;
+ };
/*
* It seems like reserving the old rmtfs_mem region is also needed to prevent
The rmtfs_mem region is a weird one, downstream allocates it dynamically, and supports a "qcom,guard-memory" property which when set will reserve 4k above and below the rmtfs memory. A common from qcom 4.9 kernel msm_sharedmem driver: /* * If guard_memory is set, then the shared memory region * will be guarded by SZ_4K at the start and at the end. * This is needed to overcome the XPU limitation on few * MSM HW, so as to make this memory not contiguous with * other allocations that may possibly happen from other * clients in the system. */ When the kernel tries to touch memory that is too close the rmtfs region it may cause an XPU violation. Such is the case on the OnePlus 6 where random crashes would occur usually after boot. Reserve 4k above and below the rmtfs_mem to avoid hitting these XPU Violations. This doesn't entirely solve the random crashes on the OnePlus 6/6T but it does seem to prevent the ones which happen shortly after modem bringup. Signed-off-by: Caleb Connolly <caleb@connolly.tech> --- arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 12 ++++++++++++ 1 file changed, 12 insertions(+)