arm: update advice on kernel and FDT load address.
PATCH 1/1 arm: update advice on kernel and FDT load address.
Based on the discussion in [0]:
- Recommend that the kernel be placed under 128MiB ("for automatic RAM location to work", says Nico)
- Recommend that DTB larger than ~16KiB be placed after the 128MiB boundary (in order to avoid conflicting with the kernel decompressor, kernel is at most 32MiB) and within the lowmem region. Somewhat arbitrarily recommend placement below the 256MiB boundary, the real lowmem limit is likely up around 600-800MiB but varies.
[0] http://article.gmane.org/gmane.linux.ports.arm.kernel/254538
--- Documentation/arm/Booting | 14 +++++++++++--- 1 files changed, 11 insertions(+), 3 deletions(-)
Documentation/arm/Booting +11 -3
@@ -125,6 +125,13 @@ with the caveat that it may not be located at physical address 0 since the kernel interprets a value of 0 in r2 to mean neither a tagged list nor a dtb were passed. +If the DTB is larger than ~16KiB, such that placement in the first +16KiB would lead to a conflict with the kernel loaded at 32KiB (as +recommended below) which uses the memory between 16KiB-32KiB itself, +then the DTB should be placed after the first 128MiB of RAM in order +to avoid conflicting with the kernel decompressor. The recommnded +placement in this case just below the 256MiB boundary. + 5. Calling the kernel image ---------------------------
@@ -136,9 +143,10 @@ is stored in flash, and is linked correctly to be run from flash, then it is legal for the boot loader to call the zImage in flash directly. -The zImage may also be placed in system RAM (at any location) and -called there. Note that the kernel uses 16K of RAM below the image -to store page tables. The recommended placement is 32KiB into RAM. +The zImage may also be placed in system RAM and called there. The +kernel should be placed in the first 128MiB of RAM. Note that the +kernel uses 16KiB of RAM below the image to store page tables. The +recommended placement is 32KiB into RAM. In either case, the following conditions must be met:
Signature · 1 line
1.7.2.5
PATCH 1/1 arm: update advice on kernel and FDT load address.
Hi Ian,
/me plays English teacher :)
Quoted 27 lines · Ian Campbell
Based on the discussion in [0]:
- Recommend that the kernel be placed under 128MiB ("for automatic RAM location to work", says Nico)
- Recommend that DTB larger than ~16KiB be placed after the 128MiB boundary (in order to avoid conflicting with the kernel decompressor, kernel is at most 32MiB) and within the lowmem region. Somewhat arbitrarily recommend placement below the 256MiB boundary, the real lowmem limit is likely up around 600-800MiB but varies.[0] http://article.gmane.org/gmane.linux.ports.arm.kernel/254538
Signed-off-by Ian Campbell <[email protected]>Cc Russell King <[email protected]>Cc Nicolas Pitre <[email protected]>Cc Will Deacon <[email protected]>Cc Dave Martin <[email protected]>Cc Grant Likely <[email protected]>Cc linux-arm-kernel at lists.infradead.org--- Documentation/arm/Booting | 14 +++++++++++--- 1 files changed, 11 insertions(+), 3 deletions(-)Documentation/arm/Booting +0
-0
Documentation/arm/Booting with the caveat that it may not be located at physical address 0 since · line 132
Quoted 8 lines
Documentation/arm/Booting +5
-0@@ -125,6 +125,13 @@ with the caveat that it may not be located at physical address 0 since the kernel interprets a value of 0 in r2 to mean neither a tagged list nor a dtb were passed. +If the DTB is larger than ~16KiB, such that placement in the first +16KiB would lead to a conflict with the kernel loaded at 32KiB (as +recommended below) which uses the memory between 16KiB-32KiB itself, +then the DTB should be placed after the first 128MiB of RAM in order +to avoid conflicting with the kernel decompressor. The recommnded
recommended
It also looks like you're repeating part of what is said later regarding the 16k of page tables below the image. Also, we use 20k with LPAE.
Quoted 6 lines
Documentation/arm/Booting +2
-0+placement in this case just below the 256MiB boundary. + 5. Calling the kernel image ---------------------------
Documentation/arm/Booting is stored in flash, and is linked correctly to be run from flash, · line 149
Quoted 10 lines
Documentation/arm/Booting +4
-3@@ -136,9 +143,10 @@ is stored in flash, and is linked correctly to be run from flash, then it is legal for the boot loader to call the zImage in flash directly. -The zImage may also be placed in system RAM (at any location) and -called there. Note that the kernel uses 16K of RAM below the image -to store page tables. The recommended placement is 32KiB into RAM. +The zImage may also be placed in system RAM and called there. The +kernel should be placed in the first 128MiB of RAM. Note that the +kernel uses 16KiB of RAM below the image to store page tables. The +recommended placement is 32KiB into RAM.
This is a bit clunky since you say that the zImage may be placed in system RAM, then restrict that in the next sentence.
Will
PATCH 1/1 arm: update advice on kernel and FDT load address.
Quoted 35 lines · Will Deacon
Hi Ian,
/me plays English teacher :)
Quoted 30 lines · Ian Campbell
Based on the discussion in [0]:
- Recommend that the kernel be placed under 128MiB ("for automatic RAM location to work", says Nico)
- Recommend that DTB larger than ~16KiB be placed after the 128MiB boundary (in order to avoid conflicting with the kernel decompressor, kernel is at most 32MiB) and within the lowmem region. Somewhat arbitrarily recommend placement below the 256MiB boundary, the real lowmem limit is likely up around 600-800MiB but varies.[0] http://article.gmane.org/gmane.linux.ports.arm.kernel/254538
Signed-off-by Ian Campbell <[email protected]>Cc Russell King <[email protected]>Cc Nicolas Pitre <[email protected]>Cc Will Deacon <[email protected]>Cc Dave Martin <[email protected]>Cc Grant Likely <[email protected]>Cc linux-arm-kernel at lists.infradead.org--- Documentation/arm/Booting | 14 +++++++++++--- 1 files changed, 11 insertions(+), 3 deletions(-)Documentation/arm/Booting +0
-0@@ -125,6 +125,13 @@ with the caveat that it may not be located at physical address 0 since the kernel interprets a value of 0 in r2 to mean neither a tagged list nor a dtb were passed.
Quoted 7 lines
Documentation/arm/Booting with the caveat that it may not be located at physical address 0 since · line 132
Quoted 5 lines
Documentation/arm/Booting +5
-0+If the DTB is larger than ~16KiB, such that placement in the first +16KiB would lead to a conflict with the kernel loaded at 32KiB (as +recommended below) which uses the memory between 16KiB-32KiB itself, +then the DTB should be placed after the first 128MiB of RAM in order +to avoid conflicting with the kernel decompressor. The recommndedrecommended
Should've pressed F5, sorry...
Quoted 2 lines
It also looks like you're repeating part of what is said later regarding the 16k of page tables below the image.
yes, this was tricky since I wanted to justify the larger than 16KiB but that was a forward reference. I went with "as recommended below". Perhaps I should just omit the justification? Or perhaps "If the DTB is larger than ~16KiB (see below for why this particular value matters)...". Clunky :-(
Quoted 1 line
Also, we use 20k with LPAE.
I'll fold in an update along those lines too.
However given that this then makes everything more complicated (e.g. it's now DTB > ~12KiB in that case) perhaps we should just ditch the original recommendation to use the first 16KiB and switch to a recommendation of "as high as possible below 256MiB" across the board? That would remove the issue with repeating stuff from the next section too.
Quoted 9 lines
Quoted 9 lines
Documentation/arm/Booting +2
-0+placement in this case just below the 256MiB boundary. + 5. Calling the kernel image ---------------------------@@ -136,9 +143,10 @@ is stored in flash, and is linked correctly to be run from flash, then it is legal for the boot loader to call the zImage in flash directly.
Quoted 10 lines
Documentation/arm/Booting is stored in flash, and is linked correctly to be run from flash, · line 149
Quoted 7 lines
Documentation/arm/Booting +4
-3-The zImage may also be placed in system RAM (at any location) and -called there. Note that the kernel uses 16K of RAM below the image -to store page tables. The recommended placement is 32KiB into RAM. +The zImage may also be placed in system RAM and called there. The +kernel should be placed in the first 128MiB of RAM. Note that the +kernel uses 16KiB of RAM below the image to store page tables. The +recommended placement is 32KiB into RAM.This is a bit clunky since you say that the zImage may be placed in system RAM, then restrict that in the next sentence.
How about:
The kernel may also be placed in the first 128MiB of system RAM and called there. Note that the kernel uses 16KiB of RAM below the image to store page tables. The recommended placement is 32KiB into RAM.
?
Ian.
PATCH 1/1 arm: update advice on kernel and FDT load address.
Quoted 46 lines · Ian Campbell
Quoted 35 lines · Will Deacon
Hi Ian,
/me plays English teacher :)
Quoted 30 lines · Ian Campbell
Based on the discussion in [0]:
- Recommend that the kernel be placed under 128MiB ("for automatic RAM location to work", says Nico)
- Recommend that DTB larger than ~16KiB be placed after the 128MiB boundary (in order to avoid conflicting with the kernel decompressor, kernel is at most 32MiB) and within the lowmem region. Somewhat arbitrarily recommend placement below the 256MiB boundary, the real lowmem limit is likely up around 600-800MiB but varies.[0] http://article.gmane.org/gmane.linux.ports.arm.kernel/254538
Signed-off-by Ian Campbell <[email protected]>Cc Russell King <[email protected]>Cc Nicolas Pitre <[email protected]>Cc Will Deacon <[email protected]>Cc Dave Martin <[email protected]>Cc Grant Likely <[email protected]>Cc linux-arm-kernel at lists.infradead.org--- Documentation/arm/Booting | 14 +++++++++++--- 1 files changed, 11 insertions(+), 3 deletions(-)Documentation/arm/Booting +0
-0@@ -125,6 +125,13 @@ with the caveat that it may not be located at physical address 0 since the kernel interprets a value of 0 in r2 to mean neither a tagged list nor a dtb were passed.Quoted 7 lines
Documentation/arm/Booting with the caveat that it may not be located at physical address 0 since · line 132
Quoted 5 lines
Documentation/arm/Booting +5
-0+If the DTB is larger than ~16KiB, such that placement in the first +16KiB would lead to a conflict with the kernel loaded at 32KiB (as +recommended below) which uses the memory between 16KiB-32KiB itself, +then the DTB should be placed after the first 128MiB of RAM in order +to avoid conflicting with the kernel decompressor. The recommndedrecommended
Should've pressed F5, sorry...
Quoted 8 lines
Quoted 2 lines
It also looks like you're repeating part of what is said later regarding the 16k of page tables below the image.
yes, this was tricky since I wanted to justify the larger than 16KiB but that was a forward reference. I went with "as recommended below". Perhaps I should just omit the justification? Or perhaps "If the DTB is larger than ~16KiB (see below for why this particular value matters)...". Clunky :-(
Why not simply:
Make sure the loaded DTB doesn't conflict with the zImage decompressor which may relocate itself. A safe location is just above the 128MB boundary from start of RAM.
Quoted 10 lines
Quoted 1 line
Also, we use 20k with LPAE.
I'll fold in an update along those lines too.
However given that this then makes everything more complicated (e.g. it's now DTB > ~12KiB in that case) perhaps we should just ditch the original recommendation to use the first 16KiB and switch to a recommendation of "as high as possible below 256MiB" across the board? That would remove the issue with repeating stuff from the next section too.
Sure.
Quoted 21 lines
Quoted 10 lines
Quoted 10 lines
Documentation/arm/Booting +2
-0+placement in this case just below the 256MiB boundary. + 5. Calling the kernel image ---------------------------@@ -136,9 +143,10 @@ is stored in flash, and is linked correctly to be run from flash, then it is legal for the boot loader to call the zImage in flash directly.Quoted 10 lines
Documentation/arm/Booting is stored in flash, and is linked correctly to be run from flash, · line 149
Quoted 7 lines
Documentation/arm/Booting +4
-3-The zImage may also be placed in system RAM (at any location) and -called there. Note that the kernel uses 16K of RAM below the image -to store page tables. The recommended placement is 32KiB into RAM. +The zImage may also be placed in system RAM and called there. The +kernel should be placed in the first 128MiB of RAM. Note that the +kernel uses 16KiB of RAM below the image to store page tables. The +recommended placement is 32KiB into RAM.This is a bit clunky since you say that the zImage may be placed in system RAM, then restrict that in the next sentence.
Quoted 4 lines
How about:
The kernel may also be placed in the first 128MiB of system RAM and called there.
Not "may" but "must" if you have CONFIG_AUTO_ZRELADDR=y.
Quoted 3 lines
Note that the kernel uses 16KiB of RAM below
the image to store page tables. The recommended placement is
32KiB into RAM.
Well... not completely right.
You may load zImage anywhere in the first 128MB of RAM if you have CONFIG_AUTO_ZRELADDR=y. If CONFIG_AUTO_ZRELADDR=n then zImage may be loaded anywhere. In the former case, the zImage code will automatically determine the physical start of RAM. In the later case the start of RAM is hardcoded in the zImage binary.
Then, the zImage code will decompress the actual kernel image at an offset of (in most cases) 32KB from start of RAM. However, if the decompressed kernel would overwrite the loaded zImage where the decompressor code and data is located, then zImage will relocate itself just after the end of the decompressed kernel area before proceeding to the decompression. This is where you need to be careful about ramdisk/initrd and DTB load addresses.
The initial page table is therefore (in most cases again) just below the decompressed kernel location i.e. either Ffrom 16KB from start of RAM, or from 12KB if using LPAE.
You can therefore load everything (zImage, initrd, DTB) sequentially from the 32MB mark in RAM and be safe. By loading zImage that high, it most certainly won't need to relocate itself (unless the decompressed kernel is larger than 32MB which is very unlikely as I mentioned) and that will also make the boot process slightly faster.
Nicolas
PATCH 1/1 arm: update advice on kernel and FDT load address.
Quoted 25 lines · Nicolas Pitre
Quoted 3 lines · Ian Campbell
Note that the kernel uses 16KiB of RAM below
the image to store page tables. The recommended placement is
32KiB into RAM.Well... not completely right.
You may load zImage anywhere in the first 128MB of RAM if you have
CONFIG_AUTO_ZRELADDR=y. IfCONFIG_AUTO_ZRELADDR=nthen zImage may be loaded anywhere. In the former case, the zImage code will automatically determine the physical start of RAM. In the later case the start of RAM is hardcoded in the zImage binary.Then, the zImage code will decompress the actual kernel image at an offset of (in most cases) 32KB from start of RAM. However, if the decompressed kernel would overwrite the loaded zImage where the decompressor code and data is located, then zImage will relocate itself just after the end of the decompressed kernel area before proceeding to the decompression. This is where you need to be careful about ramdisk/initrd and DTB load addresses.
The initial page table is therefore (in most cases again) just below the decompressed kernel location i.e. either Ffrom 16KB from start of RAM, or from 12KB if using LPAE.
Quoted 5 lines
You can therefore load everything (zImage, initrd, DTB) sequentially from the 32MB mark in RAM and be safe. By loading zImage that high, it most certainly won't need to relocate itself (unless the decompressed kernel is larger than 32MB which is very unlikely as I mentioned) and that will also make the boot process slightly faster.
Hmm, how does that work with CONFIG_INITRAMFS_SOURCE, where the initramfs is built into the zImage? Would this impose a 32MB uncompressed limit on the size of the kernel + initramfs?
Will
PATCH 1/1 arm: update advice on kernel and FDT load address.
Quoted 3 lines · Will Deacon
Hmm, how does that work with
CONFIG_INITRAMFS_SOURCE, where the initramfs is built into the zImage? Would this impose a 32MB uncompressed limit on the size of the kernel + initramfs?
It does, especially if you have things like the CPU resume path in the .data section so it can access the data necessary to resume without violating the read-only nature of .text.
PATCH 1/1 arm: update advice on kernel and FDT load address.
In reply to Will DeaconDear Will Deacon,
Quoted 10 lines · Will Deacon
Quoted 9 lines
The initial page table is therefore (in most cases again) just below the decompressed kernel location i.e. either Ffrom 16KB from start of RAM, or from 12KB if using LPAE.
You can therefore load everything (zImage, initrd, DTB) sequentially from the 32MB mark in RAM and be safe. By loading zImage that high, it most certainly won't need to relocate itself (unless the decompressed kernel is larger than 32MB which is very unlikely as I mentioned) and that will also make the boot process slightly faster.
Quoted 3 lines
Hmm, how does that work with
CONFIG_INITRAMFS_SOURCE, where the initramfs is built into the zImage? Would this impose a 32MB uncompressed limit on the size of the kernel + initramfs?
I've recently had troubles with a kernel + bundled initramfs, when the compressed size of both exceeds something like 6 MB or so. I haven't done any serious testing as compressing with XZ worked around the problem, but I think there's some limit somewhere, but I guess 6 MB compressed isn't going to expand to 32 MB uncompressed so I'm not sure it's the limit you're referring to that I'm seeing.
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 arm: update advice on kernel and FDT load address.
In reply to Nicolas PitreQuoted 57 lines · Nicolas Pitre
Quoted 46 lines · Ian Campbell
Quoted 35 lines · Will Deacon
Hi Ian,
/me plays English teacher :)
Quoted 30 lines · Ian Campbell
Based on the discussion in [0]:
- Recommend that the kernel be placed under 128MiB ("for automatic RAM location to work", says Nico)
- Recommend that DTB larger than ~16KiB be placed after the 128MiB boundary (in order to avoid conflicting with the kernel decompressor, kernel is at most 32MiB) and within the lowmem region. Somewhat arbitrarily recommend placement below the 256MiB boundary, the real lowmem limit is likely up around 600-800MiB but varies.[0] http://article.gmane.org/gmane.linux.ports.arm.kernel/254538
Signed-off-by Ian Campbell <[email protected]>Cc Russell King <[email protected]>Cc Nicolas Pitre <[email protected]>Cc Will Deacon <[email protected]>Cc Dave Martin <[email protected]>Cc Grant Likely <[email protected]>Cc linux-arm-kernel at lists.infradead.org--- Documentation/arm/Booting | 14 +++++++++++--- 1 files changed, 11 insertions(+), 3 deletions(-)Documentation/arm/Booting +0
-0@@ -125,6 +125,13 @@ with the caveat that it may not be located at physical address 0 since the kernel interprets a value of 0 in r2 to mean neither a tagged list nor a dtb were passed.Quoted 7 lines
Documentation/arm/Booting with the caveat that it may not be located at physical address 0 since · line 132
Quoted 5 lines
Documentation/arm/Booting +5
-0+If the DTB is larger than ~16KiB, such that placement in the first +16KiB would lead to a conflict with the kernel loaded at 32KiB (as +recommended below) which uses the memory between 16KiB-32KiB itself, +then the DTB should be placed after the first 128MiB of RAM in order +to avoid conflicting with the kernel decompressor. The recommndedrecommended
Should've pressed F5, sorry...
Quoted 8 lines
Quoted 2 lines
It also looks like you're repeating part of what is said later regarding the 16k of page tables below the image.
yes, this was tricky since I wanted to justify the larger than 16KiB but that was a forward reference. I went with "as recommended below". Perhaps I should just omit the justification? Or perhaps "If the DTB is larger than ~16KiB (see below for why this particular value matters)...". Clunky :-(
Quoted 5 lines
Why not simply:
Make sure the loaded DTB doesn't conflict with the zImage decompressor which may relocate itself. A safe location is just above the 128MB boundary from start of RAM.
Sounds good.
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Also, we use 20k with LPAE.
I'll fold in an update along those lines too.
Quoted 8 lines
Quoted 6 lines
However given that this then makes everything more complicated (e.g. it's now DTB > ~12KiB in that case) perhaps we should just ditch the original recommendation to use the first 16KiB and switch to a recommendation of "as high as possible below 256MiB" across the board? That would remove the issue with repeating stuff from the next section too.
Sure.
I'll make this change.
Quoted 20 lines
Quoted 20 lines
Quoted 19 lines
Quoted 6 lines
Documentation/arm/Booting +2
-0+placement in this case just below the 256MiB boundary. + 5. Calling the kernel image ---------------------------Documentation/arm/Booting is stored in flash, and is linked correctly to be run from flash, · line 149
Quoted 10 lines
Documentation/arm/Booting +4
-3@@ -136,9 +143,10 @@ is stored in flash, and is linked correctly to be run from flash, then it is legal for the boot loader to call the zImage in flash directly. -The zImage may also be placed in system RAM (at any location) and -called there. Note that the kernel uses 16K of RAM below the image -to store page tables. The recommended placement is 32KiB into RAM. +The zImage may also be placed in system RAM and called there. The +kernel should be placed in the first 128MiB of RAM. Note that the +kernel uses 16KiB of RAM below the image to store page tables. The +recommended placement is 32KiB into RAM.This is a bit clunky since you say that the zImage may be placed in system RAM, then restrict that in the next sentence.
Quoted 6 lines
Quoted 4 lines
How about:
The kernel may also be placed in the first 128MiB of system RAM and called there.
Not "may" but "must" if you have
CONFIG_AUTO_ZRELADDR=y.
The "may" here is an alternative to the option of being in flash. Is that incompatible with AUTO_ZRELADDR?
Quoted 8 lines
From the ZRELADDR
Kconfigthe answer seems to be yes.Quoted 3 lines
Note that the kernel uses 16KiB of RAM below
the image to store page tables. The recommended placement is
32KiB into RAM.Well... not completely right.
To be fair this was part of the existing text ;)
Quoted 18 lines
You may load zImage anywhere in the first 128MB of RAM if you have
CONFIG_AUTO_ZRELADDR=y. IfCONFIG_AUTO_ZRELADDR=nthen zImage may be loaded anywhere. In the former case, the zImage code will automatically determine the physical start of RAM. In the later case the start of RAM is hardcoded in the zImage binary.Then, the zImage code will decompress the actual kernel image at an offset of (in most cases) 32KB from start of RAM. However, if the decompressed kernel would overwrite the loaded zImage where the decompressor code and data is located, then zImage will relocate itself just after the end of the decompressed kernel area before proceeding to the decompression. This is where you need to be careful about ramdisk/initrd and DTB load addresses.
The initial page table is therefore (in most cases again) just below the decompressed kernel location i.e. either Ffrom 16KB from start of RAM, or from 12KB if using LPAE.
Quoted 5 lines
You can therefore load everything (zImage, initrd, DTB) sequentially from the 32MB mark in RAM and be safe. By loading zImage that high, it most certainly won't need to relocate itself (unless the decompressed kernel is larger than 32MB which is very unlikely as I mentioned) and that will also make the boot process slightly faster.
OK. So it sounds like you want to change the existing recommendation of loading at 32KiB into RAM to instead recommend loading the kernel at 32MiB into RAM, at least for zImage/compressed kernels. Do we care about any other sort, e.g. bare or uncompressed images?
I think we do still care about people jumping direct to arch/arm/kernel/head.S rather than arch/arm/boot/compressed/head.S, don't we? It seems like the recommendation should remain 32KiB for "bare" kernels.
Actually I've just noticed that the existing text in Documentation/arm/Booting only talks about zImage and 32KiB, so perhaps not worrying about non-zImage is acceptable?
Ian.
PATCH 1/1 arm: update advice on kernel and FDT load address.
Quoted 3 lines · Ian Campbell
Actually I've just noticed that the existing text in
Documentation/arm/Bootingonly talks about zImage and 32KiB, so perhaps not worrying about non-zImage is acceptable?
Straight binary kernels have tighter requirements, because they're _not_ entirely position independent. Firstly, with dynamic physical offset, they calculate that based on their position in physical space when they're first called.
So, with a PAGE_OFFSET of 0xc0000000 and a link address of 0xc0008000, a binary kernel image better be placed at 0xXXXX8000, and it _will_ assume that RAM starts 32KiB below itself. And yes, the 32KiB offset applies as the kernel uses TEXTADDR-16KiB to store the initial page tables.
PATCH 1/1 arm: update advice on kernel and FDT load address.
Quoted 10 lines · Russell King - ARM Linux
Quoted 3 lines · Ian Campbell
Actually I've just noticed that the existing text in
Documentation/arm/Bootingonly talks about zImage and 32KiB, so perhaps not worrying about non-zImage is acceptable?Straight binary kernels have tighter requirements, because they're _not_ entirely position independent. Firstly, with dynamic physical offset, they calculate that based on their position in physical space when they're first called.
Quoted 5 lines
So, with a
PAGE_OFFSETof0xc0000000and a link address of0xc0008000, a binary kernel image better be placed at 0xXXXX8000, and it _will_ assume that RAM starts 32KiB below itself. And yes, the 32KiB offset applies as the kernel uses TEXTADDR-16KiB to store the initial page tables.
OK, so in the non-zImage case 32KiB is a Requirement and not just a recommendation. I'll update things to that affect.
This is turning out to be more complicated to write down than I imagined!
Ian.
PATCH 1/1 arm: update advice on kernel and FDT load address.
Quoted 11 lines · Ian Campbell
Quoted 10 lines · Russell King - ARM Linux
Quoted 3 lines · Ian Campbell
Actually I've just noticed that the existing text in
Documentation/arm/Bootingonly talks about zImage and 32KiB, so perhaps not worrying about non-zImage is acceptable?Straight binary kernels have tighter requirements, because they're _not_ entirely position independent. Firstly, with dynamic physical offset, they calculate that based on their position in physical space when they're first called.
Quoted 8 lines
Quoted 5 lines
So, with a
PAGE_OFFSETof0xc0000000and a link address of0xc0008000, a binary kernel image better be placed at 0xXXXX8000, and it _will_ assume that RAM starts 32KiB below itself. And yes, the 32KiB offset applies as the kernel uses TEXTADDR-16KiB to store the initial page tables.OK, so in the non-zImage case 32KiB is a Requirement and not just a recommendation. I'll update things to that affect.
Not quite a requirement. The basic requirements for plain images are:
kernel_offset = TEXT_OFFSET - PAGE_OFFSET
assert(kernel_offset >= 32KiB)
physical_memory = kernel_load_address - kernel_offset
assert(IS_ALIGNED(physical_memory, 2MiB))
for each memory node(node) {
assert(physical_memory <= node->start_address);
}In other words, you can't link a kernel for 0xc0008000, and then load it at (eg) 0xX000c000 or 0xX0004000 and expect it to work.