arm: vf610: move device tree after kernel image
PATCH 1/1 arm: vf610: move device tree after kernel image
Since the device tree relocation is disabled (fdt_high set to 0xffffffff), U-Boot keeps the device tree at its load address 0x81000000. The kernel uncompresses itself to 0x80008000 by default, hence this limits the maximum (uncompressed) kernel size to somewhat below 16MiB, otherwise the device tree gets overwritten by the kernel data...
Move the device tree load address to 0x84000000 to avoid that the device tree being overwritten by the kernel.
--- include/configs/vf610twr.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/vf610twr.h +1 -1
@@ -129,7 +129,7 @@"fdt_high=0xffffffff\0" \"initrd_high=0xffffffff\0" \"fdt_file=vf610-twr.dtb\0" \ -"fdt_addr=0x81000000\0" \ +"fdt_addr=0x84000000\0" \"boot_fdt=try\0" \"ip_dyn=yes\0" \ "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
Signature · 1 line
2.6.1
PATCH 1/1 arm: vf610: move device tree after kernel image
Hello Stefan,
Quoted 9 lines · Stefan Agner
Since the device tree relocation is disabled (
fdt_highset to0xffffffff), U-Boot keeps the device tree at its load address0x81000000. The kernel uncompresses itself to0x80008000by default, hence this limits the maximum (uncompressed) kernel size to somewhat below 16MiB, otherwise the device tree gets overwritten by the kernel data...Move the device tree load address to
0x84000000to avoid that the device tree being overwritten by the kernel.
OOC, why is device tree relocation disabled? I'm asking because by manually placing the device tree (or anything else) high in DDR, one runs the risk of overwriting some of U-Boot's data.
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 arm: vf610: move device tree after kernel image
Quoted 11 lines · Albert ARIBAUD
Hello Stefan,
Quoted 7 lines · Stefan Agner
Since the device tree relocation is disabled (
fdt_highset to0xffffffff), U-Boot keeps the device tree at its load address0x81000000. The kernel uncompresses itself to0x80008000by default, hence this limits the maximum (uncompressed) kernel size to somewhat below 16MiB, otherwise the device tree gets overwritten by the kernel data...
Quoted 6 lines
Quoted 2 lines
Move the device tree load address to
0x84000000to avoid that the device tree being overwritten by the kernel.OOC, why is device tree relocation disabled? I'm asking because by manually placing the device tree (or anything else) high in DDR, one runs the risk of overwriting some of U-Boot's data.
Also, nitpick: this is not "vf610:" but "vf610twr:" (although some other vf610 boards might need to perform the same fix, depending on the size of their kernel) -- not that it requires a v2, mind you, the committer could just fix the subject on-the-fly.
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 arm: vf610: move device tree after kernel image
In reply to Albert ARIBAUDQuoted 11 lines · Albert ARIBAUD
Hello Stefan,
Quoted 7 lines · Stefan Agner
Since the device tree relocation is disabled (
fdt_highset to0xffffffff), U-Boot keeps the device tree at its load address0x81000000. The kernel uncompresses itself to0x80008000by default, hence this limits the maximum (uncompressed) kernel size to somewhat below 16MiB, otherwise the device tree gets overwritten by the kernel data...
Quoted 6 lines
Quoted 2 lines
Move the device tree load address to
0x84000000to avoid that the device tree being overwritten by the kernel.OOC, why is device tree relocation disabled? I'm asking because by manually placing the device tree (or anything else) high in DDR, one runs the risk of overwriting some of U-Boot's data.
I guess this has been done for Cortex-M4 firmwares running from DDR. As Tom pointed out, this can be archived in a nicer way using bootm_size.
--
Stefan
PATCH 1/1 arm: vf610: move device tree after kernel image
Hello Stefan,
Quoted 15 lines · Stefan Agner
Quoted 14 lines · Albert ARIBAUD
Hello Stefan,
Quoted 9 lines · Stefan Agner
Since the device tree relocation is disabled (
fdt_highset to0xffffffff), U-Boot keeps the device tree at its load address0x81000000. The kernel uncompresses itself to0x80008000by default, hence this limits the maximum (uncompressed) kernel size to somewhat below 16MiB, otherwise the device tree gets overwritten by the kernel data...Move the device tree load address to
0x84000000to avoid that the device tree being overwritten by the kernel.
Quoted 6 lines
Quoted 3 lines
OOC, why is device tree relocation disabled? I'm asking because by manually placing the device tree (or anything else) high in DDR, one runs the risk of overwriting some of U-Boot's data.
I guess this has been done for Cortex-M4 firmwares running from DDR. As Tom pointed out, this can be archived in a nicer way using
bootm_size.
Thanks -- I've just seen Tom's answer. I guess I'll update pcm052 too...
Quoted 1 line
Stefan
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 arm: vf610: move device tree after kernel image
In reply to Stefan AgnerQuoted 20 lines · Stefan Agner
Since the device tree relocation is disabled (
fdt_highset to0xffffffff), U-Boot keeps the device tree at its load address0x81000000. The kernel uncompresses itself to0x80008000by default, hence this limits the maximum (uncompressed) kernel size to somewhat below 16MiB, otherwise the device tree gets overwritten by the kernel data...Move the device tree load address to
0x84000000to avoid that the device tree being overwritten by the kernel.Signed-off-by Stefan Agner <[email protected]>--- include/configs/vf610twr.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)include/configs/vf610twr.h +0
-0
include/configs/vf610twr.h line 135
Quoted 8 lines
include/configs/vf610twr.h +1
-1@@ -129,7 +129,7 @@"fdt_high=0xffffffff\0" \"initrd_high=0xffffffff\0" \"fdt_file=vf610-twr.dtb\0" \ -"fdt_addr=0x81000000\0" \ +"fdt_addr=0x84000000\0" \"boot_fdt=try\0" \"ip_dyn=yes\0" \ "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
OK, this is all wrong :( Please take a look at include/configs/ti_armv7_common.h and DEFAULT_LINUX_BOOT_ENV (and the giant comment block explaining the values).
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151014/22d3c53f/attachment.sig>
PATCH 1/1 arm: vf610: move device tree after kernel image
Hi Tom,
Quoted 26 lines · Tom Rini
Quoted 24 lines · Stefan Agner
Since the device tree relocation is disabled (
fdt_highset to0xffffffff), U-Boot keeps the device tree at its load address0x81000000. The kernel uncompresses itself to0x80008000by default, hence this limits the maximum (uncompressed) kernel size to somewhat below 16MiB, otherwise the device tree gets overwritten by the kernel data...Move the device tree load address to
0x84000000to avoid that the device tree being overwritten by the kernel.Signed-off-by Stefan Agner <[email protected]>--- include/configs/vf610twr.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)include/configs/vf610twr.h +0
-1@@ -129,7 +129,7 @@"fdt_high=0xffffffff\0" \"initrd_high=0xffffffff\0" \"fdt_file=vf610-twr.dtb\0" \ -"fdt_addr=0x81000000\0" \
Quoted 8 lines
include/configs/vf610twr.h line 135
Quoted 4 lines
include/configs/vf610twr.h +1
-0+"fdt_addr=0x84000000\0" \"boot_fdt=try\0" \"ip_dyn=yes\0" \ "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \OK, this is all wrong :( Please take a look at
include/configs/ti_armv7_common.handDEFAULT_LINUX_BOOT_ENV(and the giant comment block explaining the values).
This default environment is quite old, and according to the log it came from Timesys/Freescales initial BSP.
The end of the DDR is commonly used for the second Cortex-M4 core. Hence I guess fdt_high=0xffffffff has been set to avoid that U-Boot relocates the device tree into the DDR area used by the M4. Note that this board only has 128MiB of RAM,
I see that the comments in ti_armv7_common.h is mostly about moving stuff into the upper 128MiB, which we don't have. So, with these two things in mind, what do you want me to do differently?
--
Stefan
PATCH 1/1 arm: vf610: move device tree after kernel image
Quoted 41 lines · Stefan Agner
Hi Tom,
Quoted 26 lines · Tom Rini
Quoted 24 lines · Stefan Agner
Since the device tree relocation is disabled (
fdt_highset to0xffffffff), U-Boot keeps the device tree at its load address0x81000000. The kernel uncompresses itself to0x80008000by default, hence this limits the maximum (uncompressed) kernel size to somewhat below 16MiB, otherwise the device tree gets overwritten by the kernel data...Move the device tree load address to
0x84000000to avoid that the device tree being overwritten by the kernel.Signed-off-by Stefan Agner <[email protected]>--- include/configs/vf610twr.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)include/configs/vf610twr.h +0
-1@@ -129,7 +129,7 @@"fdt_high=0xffffffff\0" \"initrd_high=0xffffffff\0" \"fdt_file=vf610-twr.dtb\0" \ -"fdt_addr=0x81000000\0" \Quoted 8 lines
include/configs/vf610twr.h line 135
Quoted 4 lines
include/configs/vf610twr.h +1
-0+"fdt_addr=0x84000000\0" \"boot_fdt=try\0" \"ip_dyn=yes\0" \ "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \OK, this is all wrong :( Please take a look at
include/configs/ti_armv7_common.handDEFAULT_LINUX_BOOT_ENV(and the giant comment block explaining the values).This default environment is quite old, and according to the log it came from Timesys/Freescales initial BSP.
Quoted 8 lines
The end of the DDR is commonly used for the second Cortex-M4 core. Hence I guess fdt_high=0xffffffff has been set to avoid that U-Boot relocates the device tree into the DDR area used by the M4. Note that this board only has 128MiB of RAM,
I see that the comments in
ti_armv7_common.his mostly about moving stuff into the upper 128MiB, which we don't have. So, with these two things in mind, what do you want me to do differently?
So, we want to use bootm_size whenever possible as the way to tell U-Boot "kernel, ramdisk (if present) and fdt (if present) need to exist within thus chunk of memory". So instead of saying fdt_high/initrd_high=0xffffffff we leave those alone, set bootm_size to howmuch we can set aside for those three things and let U-Boot sort out making sure things don't overlap and if they need to be moved.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151014/6f77ef41/attachment.sig>