arm64: Documentation: clarify Image placement in physical RAM
PATCH 1/1 arm64: Documentation: clarify Image placement in physical RAM
The early init code maps the kernel image using statically allocated page tables. This means that we can only allow Image to be placed such that we can map its entire static footprint using a single table entry at all but the lowest level. So update the documentation to reflect that the Image should not cross a 512 MB boundary, which ensures the above on both 4k and 64k pages kernels.
--- Documentation/arm64/booting.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
Documentation/arm64/booting.txt +3 -2
@@ -113,8 +113,9 @@ The Image must be placed text_offset bytes from a 2MB aligned base address near the start of usable system RAM and called there. Memory below that base address is currently unusable by Linux, and therefore it is strongly recommended that this location is the start of system RAM. -At least image_size bytes from the start of the image must be free for -use by the kernel. +The physical memory region consisting of image_size bytes counting from +the start of the image must be free for use by the kernel, and must not +cross a 512 MB physical alignment boundary. Any memory described to the kernel (even that below the 2MB aligned base address) which is not marked as reserved from the kernel e.g. with a
Signature · 1 line
1.8.3.2
PATCH 1/1 arm64: Documentation: clarify Image placement in physical RAM
Quoted 9 lines · Ard Biesheuvel
The early init code maps the kernel image using statically allocated page tables. This means that we can only allow Image to be placed such that we can map its entire static footprint using a single table entry at all but the lowest level. So update the documentation to reflect that the Image should not cross a 512 MB boundary, which ensures the above on both 4k and 64k pages kernels.
Signed-off-by Ard Biesheuvel <[email protected]>
Quoted 24 lines
--- Documentation/arm64/booting.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)Documentation/arm64/booting.txt +3
-2@@ -113,8 +113,9 @@ The Image must be placed text_offset bytes from a 2MB aligned base address near the start of usable system RAM and called there. Memory below that base address is currently unusable by Linux, and therefore it is strongly recommended that this location is the start of system RAM. -At least image_size bytes from the start of the image must be free for -use by the kernel. +The physical memory region consisting of image_size bytes counting from +the start of the image must be free for use by the kernel, and must not +cross a 512 MB physical alignment boundary. Any memory described to the kernel (even that below the 2MB aligned base address) which is not marked as reserved from the kernel e.g. with aSignature · 1 line
1.8.3.2
PATCH 1/1 arm64: Documentation: clarify Image placement in physical RAM
Quoted 9 lines · Mark Rutland
Quoted 8 lines · Ard Biesheuvel
The early init code maps the kernel image using statically allocated page tables. This means that we can only allow Image to be placed such that we can map its entire static footprint using a single table entry at all but the lowest level. So update the documentation to reflect that the Image should not cross a 512 MB boundary, which ensures the above on both 4k and 64k pages kernels.
Quoted 4 lines
Quoted 1 line
Signed-off-by Ard Biesheuvel <[email protected]>Acked-by Mark Rutland <[email protected]>
Thanks.
Note that the text is still wrong wrt to the FDT:
"""
The device tree blob (dtb) must be placed on an 8-byte boundary within the first 512 megabytes from the start of the kernel image [...] """
but perhaps we should discuss first if we want to relax the requirement that it shares the same 512 MB aligned region with the kernel.
(RFC patch sent out last Friday, but there are some caveats)
Signature · 1 line
Ard.
Quoted 24 lines
Quoted 24 lines
--- Documentation/arm64/booting.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)Documentation/arm64/booting.txt +3
-3@@ -113,8 +113,9 @@ The Image must be placed text_offset bytes from a 2MB aligned base address near the start of usable system RAM and called there. Memory below that base address is currently unusable by Linux, and therefore it is strongly recommended that this location is the start of system RAM. -At least image_size bytes from the start of the image must be free for -use by the kernel. +The physical memory region consisting of image_size bytes counting from +the start of the image must be free for use by the kernel, and must not +cross a 512 MB physical alignment boundary. Any memory described to the kernel (even that below the 2MB aligned base address) which is not marked as reserved from the kernel e.g. with a --1.8.3.2
PATCH 1/1 arm64: Documentation: clarify Image placement in physical RAM
Quoted 23 lines · Ard Biesheuvel
Quoted 9 lines · Mark Rutland
Quoted 8 lines · Ard Biesheuvel
The early init code maps the kernel image using statically allocated page tables. This means that we can only allow Image to be placed such that we can map its entire static footprint using a single table entry at all but the lowest level. So update the documentation to reflect that the Image should not cross a 512 MB boundary, which ensures the above on both 4k and 64k pages kernels.
Quoted 4 lines
Quoted 1 line
Signed-off-by Ard Biesheuvel <[email protected]>Acked-by Mark Rutland <[email protected]>Thanks.
Note that the text is still wrong wrt to the FDT:"""
The device tree blob (dtb) must be placed on an 8-byte boundary within the first 512 megabytes from the start of the kernel image [...] """
Quoted 4 lines
but perhaps we should discuss first if we want to relax the requirement that it shares the same 512 MB aligned region with the kernel.
(RFC patch sent out last Friday, but there are some caveats)
I think we do; I've commented in that thread.
Assuming everyone else is happy with that, I guess these two patches should be kept as a series.
Thanks,
Mark.