Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1380076 > unrolled thread
| Started by | Masahiro Yamada <yamada.masahiro@socionext.com> |
|---|---|
| First post | 2016-04-15 20:10 +0200 |
| Last post | 2016-04-18 11:10 +0200 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH] arm64: dts: uniphier: add /memreserve/ for spin-table release address Masahiro Yamada <yamada.masahiro@socionext.com> - 2016-04-15 20:10 +0200
Re: [PATCH] arm64: dts: uniphier: add /memreserve/ for spin-table release address Mark Rutland <mark.rutland@arm.com> - 2016-04-18 10:50 +0200
Re: [PATCH] arm64: dts: uniphier: add /memreserve/ for spin-table release address Masahiro Yamada <yamada.masahiro@socionext.com> - 2016-04-18 11:00 +0200
Re: [PATCH] arm64: dts: uniphier: add /memreserve/ for spin-table release address Mark Rutland <mark.rutland@arm.com> - 2016-04-18 11:10 +0200
| From | Masahiro Yamada <yamada.masahiro@socionext.com> |
|---|---|
| Date | 2016-04-15 20:10 +0200 |
| Subject | [PATCH] arm64: dts: uniphier: add /memreserve/ for spin-table release address |
| Message-ID | <roglQ-7dz-19@gated-at.bofh.it> |
As Documentation/arm64/booting.txt says, the cpu-release-addr
location should be reserved.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
index 651c9d9..90909d2 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
@@ -42,6 +42,8 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
+/memreserve/ 0x80000100 0x00000008;
+
/ {
compatible = "socionext,ph1-ld20";
#address-cells = <2>;
--
1.9.1
[toc] | [next] | [standalone]
| From | Mark Rutland <mark.rutland@arm.com> |
|---|---|
| Date | 2016-04-18 10:50 +0200 |
| Subject | Re: [PATCH] arm64: dts: uniphier: add /memreserve/ for spin-table release address |
| Message-ID | <rpd2y-2oe-19@gated-at.bofh.it> |
| In reply to | #1380076 |
On Sat, Apr 16, 2016 at 02:58:58AM +0900, Masahiro Yamada wrote:
> As Documentation/arm64/booting.txt says, the cpu-release-addr
> location should be reserved.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
> index 651c9d9..90909d2 100644
> --- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
> +++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
> @@ -42,6 +42,8 @@
> * OTHER DEALINGS IN THE SOFTWARE.
> */
>
> +/memreserve/ 0x80000100 0x00000008;
> +
Please add a comment above the memreserve to mention what it is
protecting. That helps to avoid having this cargo-culted to cases where
it is not needed.
I take it that the code for the spin-table is not in RAM, and does not
need to be protected similarly?
Assuming so:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> / {
> compatible = "socionext,ph1-ld20";
> #address-cells = <2>;
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[toc] | [prev] | [next] | [standalone]
| From | Masahiro Yamada <yamada.masahiro@socionext.com> |
|---|---|
| Date | 2016-04-18 11:00 +0200 |
| Subject | Re: [PATCH] arm64: dts: uniphier: add /memreserve/ for spin-table release address |
| Message-ID | <rpdcf-2t5-9@gated-at.bofh.it> |
| In reply to | #1381385 |
Hi Mark, 2016-04-18 17:45 GMT+09:00 Mark Rutland <mark.rutland@arm.com>: > On Sat, Apr 16, 2016 at 02:58:58AM +0900, Masahiro Yamada wrote: >> As Documentation/arm64/booting.txt says, the cpu-release-addr >> location should be reserved. >> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> >> --- >> >> arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi >> index 651c9d9..90909d2 100644 >> --- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi >> +++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi >> @@ -42,6 +42,8 @@ >> * OTHER DEALINGS IN THE SOFTWARE. >> */ >> >> +/memreserve/ 0x80000100 0x00000008; >> + > > Please add a comment above the memreserve to mention what it is > protecting. That helps to avoid having this cargo-culted to cases where > it is not needed. OK, will do. > I take it that the code for the spin-table is not in RAM, and does not > need to be protected similarly? I use U-Boot to boot Linux for this board. The code for the spin-table is on SDRAM, and not protected. I already recognize this problem. The difficulty for U-Boot is that U-Boot relocates itself to the top of the DRAM. So, it is difficult to predict where the code will be placed. I will discuss this issue in the U-Boot ML. So, My current solution is pre-fetch the code for the spin-table onto I-cache. -- Best Regards Masahiro Yamada
[toc] | [prev] | [next] | [standalone]
| From | Mark Rutland <mark.rutland@arm.com> |
|---|---|
| Date | 2016-04-18 11:10 +0200 |
| Subject | Re: [PATCH] arm64: dts: uniphier: add /memreserve/ for spin-table release address |
| Message-ID | <rpdlT-2Qd-11@gated-at.bofh.it> |
| In reply to | #1381389 |
On Mon, Apr 18, 2016 at 05:55:14PM +0900, Masahiro Yamada wrote: > 2016-04-18 17:45 GMT+09:00 Mark Rutland <mark.rutland@arm.com>: > > I take it that the code for the spin-table is not in RAM, and does not > > need to be protected similarly? > > I use U-Boot to boot Linux for this board. > > The code for the spin-table is on SDRAM, and not protected. > > I already recognize this problem. > > The difficulty for U-Boot is that > U-Boot relocates itself to the top of the DRAM. > So, it is difficult to predict > where the code will be placed. > > I will discuss this issue in the U-Boot ML. Ok, please do. > So, My current solution is pre-fetch the code for the spin-table onto > I-cache. As you are probably aware, this is incredibly unsafe, and very likely to go wrong. Nothing guarantees that (stale) entries remain in the I-cache. I would very much advise fixing this ASAP. Thanks, Mark.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web