@@ -30,7 +30,7 @@ cpu0: cpu@0 {
compatible = "brcm,brahma-b53";
reg = <0x0>;
enable-method = "spin-table";
- cpu-release-addr = <0x0 0xfff8>;
+ cpu-release-addr = <0x0 0xff8>;
next-level-cache = <&l2>;
};
@@ -39,7 +39,7 @@ cpu1: cpu@1 {
compatible = "brcm,brahma-b53";
reg = <0x1>;
enable-method = "spin-table";
- cpu-release-addr = <0x0 0xfff8>;
+ cpu-release-addr = <0x0 0xff8>;
next-level-cache = <&l2>;
};
@@ -48,7 +48,7 @@ cpu2: cpu@2 {
compatible = "brcm,brahma-b53";
reg = <0x2>;
enable-method = "spin-table";
- cpu-release-addr = <0x0 0xfff8>;
+ cpu-release-addr = <0x0 0xff8>;
next-level-cache = <&l2>;
};
@@ -57,7 +57,7 @@ cpu3: cpu@3 {
compatible = "brcm,brahma-b53";
reg = <0x3>;
enable-method = "spin-table";
- cpu-release-addr = <0x0 0xfff8>;
+ cpu-release-addr = <0x0 0xff8>;
next-level-cache = <&l2>;
};
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 <CFSworks@gmail.com> --- arch/arm64/boot/dts/broadcom/bcmbca/bcm4908.dtsi | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)