bcm4908: Fix secondary CPU initialization

The CFE bootloader places a stub program in the first page of physical memory to hold the secondary CPUs until the boot CPU writes the release address, but does not splice a /reserved-memory node into the FDT to protect it. If Linux overwrites this program before execution reaches smp_prepare_cpus(), the secondary CPUs may become inaccessible.

This is only a problem with CFE, and then only until the secondary CPUs are brought online. Ideally, there would be some hypothetical mechanism we could use to indicate that this area of memory is sensitive only during boot. But as there is none, and since it is such a small amount of memory, it is easiest to reserve it unconditionally.

Therefore, add a /reserved-memory node to bcm4908.dtsi to protect the first 4KiB of physical memory.

Signed-off-by Sam Edwards <[email protected]>

---
  arch/arm64/boot/dts/broadcom/bcmbca/bcm4908.dtsi | 10 ++++++++++
  1 file changed, 10 insertions(+)

arch/arm64/boot/dts/broadcom/bcmbca/bcm4908.dtsi +10 -0

index 8b924812322c..c51b92387fad 100644
@@ -68,6 +68,16 @@ l2: l2-cache0 {
  		};
  	};
 
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		cfe-stub@0 {
+			reg = <0x0 0x0 0x0 0x1000>;
+		};
+	};
+
  	axi@81000000 {
  		compatible = "simple-bus";
  		#address-cells = <1>;

Quoted 11 lines · Sam Edwards

The CFE bootloader places a stub program in the first page of physical memory to hold the secondary CPUs until the boot CPU writes the release address, but does not splice a /reserved-memory node into the FDT to protect it. If Linux overwrites this program before execution reaches smp_prepare_cpus(), the secondary CPUs may become inaccessible.

This is only a problem with CFE, and then only until the secondary CPUs are brought online. Ideally, there would be some hypothetical mechanism we could use to indicate that this area of memory is sensitive only during boot. But as there is none, and since it is such a small amount of memory, it is easiest to reserve it unconditionally.

If we supported CPU hotplug on those platforms (do we?) then it actually does matter that this memory remains protected, and it cannot be reclaimed. This does not invalidate the commit message and I will take it as-is, but it it is not memory that we can necessarily reclaim that easily, if we did things properly.

Quoted 21 lines

Therefore, add a /reserved-memory node to bcm4908.dtsi to protect the first 4KiB of physical memory.

Signed-off-by Sam Edwards <[email protected]>

---
  arch/arm64/boot/dts/broadcom/bcmbca/bcm4908.dtsi | 10 ++++++++++
  1 file changed, 10 insertions(+)

arch/arm64/boot/dts/broadcom/bcmbca/bcm4908.dtsi +3 -0

index 8b924812322c..c51b92387fad 100644
@@ -68,6 +68,16 @@ l2: l2-cache0 {
              };
      };
 
+     reserved-memory {
+             #address-cells = <2>;
+             #size-cells = <2>;

arch/arm64/boot/dts/broadcom/bcmbca/bcm4908.dtsi l2: l2-cache0 { · line 83

Quoted 10 lines

arch/arm64/boot/dts/broadcom/bcmbca/bcm4908.dtsi +7 -0

+             ranges;
+
+             cfe-stub@0 {
+                     reg = <0x0 0x0 0x0 0x1000>;
+             };
+     };
+
      axi@81000000 {
              compatible = "simple-bus";
              #address-cells = <1>;

--
Florian

The CFE bootloader places a stub program in the first page of physical memory to hold the secondary CPUs until the boot CPU writes the release address, but does not splice a /reserved-memory node into the FDT to protect it. If Linux overwrites this program before execution reaches smp_prepare_cpus(), the secondary CPUs may become inaccessible.

This is only a problem with CFE, and then only until the secondary CPUs are brought online. Ideally, there would be some hypothetical mechanism we could use to indicate that this area of memory is sensitive only during boot. But as there is none, and since it is such a small amount of memory, it is easiest to reserve it unconditionally.

Therefore, add a /reserved-memory node to bcm4908.dtsi to protect the first 4KiB of physical memory.

Signed-off-by Sam Edwards <[email protected]>

---

The cpu-release-addr property is relevant only when the "spin-table" enable method is used. It is the physical address where the bootloader expects Linux to write the secondary CPU entry point's physical address. On this platform, only the CFE bootloader uses this method: U-Boot uses PSCI instead.

CFE actually walks the FDT to learn this address, so we're free to put it wherever we want. We only need to make sure that it goes in a reserved-memory block so that writing to it during early boot does not risk conflicting with an unrelated memory allocation: this was not done.

Since the previous patch reserved the first page of memory for CFE's secondary-CPU init stub, which is actually much smaller than a page, just put this address at the end of that page and it shall be so protected.

Signed-off-by Sam Edwards <[email protected]>

---