Skip to contentSkip to conversation

arm: vf610: move device tree after kernel image

PATCH New Stefan Agner 3 participants 8 messages Oct 14, 2015

lore
Share & tools
lore
#0 lore raw

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
index 324ba8f..1d15f35 100644
@@ -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
#1 lore raw

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_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.

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.
#2 lore raw

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_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...

Quoted 6 lines
Quoted 2 lines

Move the device tree load address to 0x84000000 to 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.
#3 lore raw

PATCH 1/1 arm: vf610: move device tree after kernel image

In reply to Albert ARIBAUD
Quoted 11 lines · Albert ARIBAUD

Hello Stefan,

Quoted 7 lines · Stefan Agner

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...

Quoted 6 lines
Quoted 2 lines

Move the device tree load address to 0x84000000 to 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

#4 lore raw

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_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.

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.
#5 lore raw

PATCH 1/1 arm: vf610: move device tree after kernel image

In reply to Stefan Agner
Quoted 20 lines · Stefan Agner

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 +0 -0
index 324ba8f..1d15f35 100644

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>
#6 lore raw

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_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 +0 -1
index 324ba8f..1d15f35 100644
@@ -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.h and DEFAULT_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

#7 lore raw

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_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 +0 -1
index 324ba8f..1d15f35 100644
@@ -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.h and DEFAULT_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.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?

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>