[U-Boot] [PATCH] Set ramdisk_addr_r to a higher address location on meson-gxbb.
Set ramdisk_addr_r to 0x20000000, otherwise it may conflict with kernel_addr_r location (0x01080000) with a moderately large kernel.
Signed-off-by: Vagrant Cascadian vagrant@debian.org ---
include/configs/meson-gxbb-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/meson-gxbb-common.h b/include/configs/meson-gxbb-common.h index cc2b5b61d4..32602cb7c2 100644 --- a/include/configs/meson-gxbb-common.h +++ b/include/configs/meson-gxbb-common.h @@ -48,7 +48,7 @@ "scriptaddr=0x1f000000\0" \ "kernel_addr_r=0x01080000\0" \ "pxefile_addr_r=0x01080000\0" \ - "ramdisk_addr_r=0x10000000\0" \ + "ramdisk_addr_r=0x20000000\0" \ MESON_FDTFILE_SETTING \ BOOTENV
On Wed, Apr 12, 2017 at 02:28:05PM -0700, Vagrant Cascadian wrote:
Set ramdisk_addr_r to 0x20000000, otherwise it may conflict with kernel_addr_r location (0x01080000) with a moderately large kernel.
Signed-off-by: Vagrant Cascadian vagrant@debian.org
include/configs/meson-gxbb-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/meson-gxbb-common.h b/include/configs/meson-gxbb-common.h index cc2b5b61d4..32602cb7c2 100644 --- a/include/configs/meson-gxbb-common.h +++ b/include/configs/meson-gxbb-common.h @@ -48,7 +48,7 @@ "scriptaddr=0x1f000000\0" \ "kernel_addr_r=0x01080000\0" \ "pxefile_addr_r=0x01080000\0" \
- "ramdisk_addr_r=0x10000000\0" \
- "ramdisk_addr_r=0x20000000\0" \
We also need to start setting bootm_size. Quoting myself from include/configs/ti_armv7_common.h: /* * We setup defaults based on constraints from the Linux kernel, which should * also be safe elsewhere. We have the default load at 32MB into DDR (for * the kernel), FDT above 128MB (the maximum location for the end of the * kernel), and the ramdisk 512KB above that (allowing for hopefully never * seen large trees). We say all of this must be within the first 256MB * as that will normally be within the kernel lowmem and thus visible via * bootm_size and we only run on platforms with 256MB or more of memory. */ ... "bootm_size=0x10000000\0" \
On 2017-04-12, Tom Rini wrote:
We also need to start setting bootm_size. Quoting myself from include/configs/ti_armv7_common.h: /*
- We setup defaults based on constraints from the Linux kernel, which should
- also be safe elsewhere. We have the default load at 32MB into DDR (for
- the kernel), FDT above 128MB (the maximum location for the end of the
- kernel), and the ramdisk 512KB above that (allowing for hopefully never
- seen large trees). We say all of this must be within the first 256MB
- as that will normally be within the kernel lowmem and thus visible via
- bootm_size and we only run on platforms with 256MB or more of memory.
*/ ... "bootm_size=0x10000000\0" \
I mostly add the variables defined in doc/README.distro for boards I'm adding distro_bootcmd support to, and there's no mention of bootm_size there.
Are there other places that it would make more sense to document or add documentation for this variable setting?
Does bootm_size impact bootz/booti as well, or is it just used with bootm?
live well, vagrant
Am 12.04.2017 um 23:28 schrieb Vagrant Cascadian:
Set ramdisk_addr_r to 0x20000000, otherwise it may conflict with kernel_addr_r location (0x01080000) with a moderately large kernel.
Signed-off-by: Vagrant Cascadian vagrant@debian.org
include/configs/meson-gxbb-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/meson-gxbb-common.h b/include/configs/meson-gxbb-common.h index cc2b5b61d4..32602cb7c2 100644 --- a/include/configs/meson-gxbb-common.h +++ b/include/configs/meson-gxbb-common.h @@ -48,7 +48,7 @@ "scriptaddr=0x1f000000\0" \ "kernel_addr_r=0x01080000\0" \ "pxefile_addr_r=0x01080000\0" \
- "ramdisk_addr_r=0x10000000\0" \
- "ramdisk_addr_r=0x20000000\0" \
So that's at 512 MiB. Have you checked for any S905 devices (e.g., TV boxes) with little RAM?
No objection here, I'm not using $ram_addr_r on S905 due to GRUB.
MESON_FDTFILE_SETTING \ BOOTENV
Regards, Andreas
On 2017-04-12, Andreas Färber wrote:
Am 12.04.2017 um 23:28 schrieb Vagrant Cascadian:
Set ramdisk_addr_r to 0x20000000, otherwise it may conflict with kernel_addr_r location (0x01080000) with a moderately large kernel.
...
diff --git a/include/configs/meson-gxbb-common.h b/include/configs/meson-gxbb-common.h index cc2b5b61d4..32602cb7c2 100644 --- a/include/configs/meson-gxbb-common.h +++ b/include/configs/meson-gxbb-common.h @@ -48,7 +48,7 @@ "scriptaddr=0x1f000000\0" \ "kernel_addr_r=0x01080000\0" \ "pxefile_addr_r=0x01080000\0" \
- "ramdisk_addr_r=0x10000000\0" \
- "ramdisk_addr_r=0x20000000\0" \
So that's at 512 MiB. Have you checked for any S905 devices (e.g., TV boxes) with little RAM?
I didn't. I just picked a value out of the air and tried it. :)
I just now tested with 0x12000000 and it worked, where 0x10000000 consistantly failed.
Debian ships a largely modular multiplatform kernel, so should be on the small side, and the current value (0x10000000) conflicted.
Not sure how much of a buffer 0x12000000 gives for the kernel to grow, but that's considerably less than 0x20000000 (at 512MiB), and still works for me so far...
live well, vagrant
On 2017-04-12, Vagrant Cascadian wrote:
On 2017-04-12, Andreas Färber wrote:
Am 12.04.2017 um 23:28 schrieb Vagrant Cascadian:
Set ramdisk_addr_r to 0x20000000, otherwise it may conflict with kernel_addr_r location (0x01080000) with a moderately large kernel.
...
diff --git a/include/configs/meson-gxbb-common.h b/include/configs/meson-gxbb-common.h index cc2b5b61d4..32602cb7c2 100644 --- a/include/configs/meson-gxbb-common.h +++ b/include/configs/meson-gxbb-common.h @@ -48,7 +48,7 @@ "scriptaddr=0x1f000000\0" \ "kernel_addr_r=0x01080000\0" \ "pxefile_addr_r=0x01080000\0" \
- "ramdisk_addr_r=0x10000000\0" \
- "ramdisk_addr_r=0x20000000\0" \
So that's at 512 MiB. Have you checked for any S905 devices (e.g., TV boxes) with little RAM?
I didn't. I just picked a value out of the air and tried it. :)
The other option is to lower the kernel_addr_r and fdt_addr_r locations, but I'm not sure how much lower they can get, if at all.
I just now tested with 0x12000000 and it worked, where 0x10000000 consistantly failed.
After some more experimenting, with ramdisk_addr_r=0x10100000 it still fails to load, with ramdisk_addr_r=0x10200000 it works, at least with the current kernel I'm testing with:
=> setenv ramdisk_addr_r 0x10100000 => boot switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 2177 bytes read in 16 ms (132.8 KiB/s) ## Executing script at 1f000000 14819840 bytes read in 737 ms (19.2 MiB/s) 16119 bytes read in 38 ms (414.1 KiB/s) 17551127 bytes read in 873 ms (19.2 MiB/s) Booting Debian 4.11.0-rc6+ from mmc 0:1... ## Flattened Device Tree blob at 01000000 Booting using the fdt blob at 0x1000000 Loading Ramdisk to 7ce9c000, end 7df58f17 ... OK Loading Device Tree to 000000007ce95000, end 000000007ce9bef6 ... OK
Starting kernel ...
And then it just hangs.
The kernel image I'm booting is almost 15MB, uncompressed. I'm guessing if "booti" would support compressed kernels, this would allieviate the problem, but it will take some time before that's common (on Debian, at least).
live well, vagrant
participants (3)
-
Andreas Färber -
Tom Rini -
Vagrant Cascadian