Skip to contentSkip to conversation

configs: ti: armv7: Fixes bug in fit_loadaddr for ramfs boot

PATCH In review Andrew F. Davis 2 participants 5 messages Jul 17, 2017 – Jul 26, 2017

lore
Share & tools
lore

Andrew F. Davis

author
#0 lore raw

PATCH 1/1 configs: ti: armv7: Fixes bug in fit_loadaddr for ramfs boot

From: Madan Srinivas <[email protected]>

The load address of ramdisk, rdaddr is 0x88080000 and fit_loadaddr is defined as 0x88000000. This leaves only 512Kbytes for the fit image. When the FIT images are larger than this, it will overwite the ramdisk and cause the boot to fail.

For eg, The K2 HS fit images are a few MB and end up overwriting the ramdsk. This patch moves the fit_loadaddr to 0x87000000, leaving a 16MB window for the fit image. This memory can be reclaimed once the kernel starts running.

Signed-off-by Madan Srinivas <[email protected]>
---
 include/configs/ti_armv7_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/ti_armv7_common.h +1 -1
index a4676d3a7f..16ea22857f 100644
@@ -53,7 +53,7 @@
 
 #define DEFAULT_FIT_TI_ARGS \
 	"boot_fit=0\0" \
-	"fit_loadaddr=0x88000000\0" \
+	"fit_loadaddr=0x87000000\0" \
 	"fit_bootfile=fitImage\0" \
 	"update_to_fit=setenv loadaddr ${fit_loadaddr}; setenv bootfile ${fit_bootfile}\0" \
 	"loadfit=run args_mmc; bootm ${loadaddr}#${fdtfile};\0" \
Signature · 1 line
2.13.0
#1 lore raw

PATCH 1/1 configs: ti: armv7: Fixes bug in fit_loadaddr for ramfs boot

Quoted 22 lines · Andrew F. Davis

From: Madan Srinivas <[email protected]>

The load address of ramdisk, rdaddr is 0x88080000 and fit_loadaddr is defined as 0x88000000. This leaves only 512Kbytes for the fit image. When the FIT images are larger than this, it will overwite the ramdisk and cause the boot to fail.

For eg, The K2 HS fit images are a few MB and end up overwriting the ramdsk. This patch moves the fit_loadaddr to 0x87000000, leaving a 16MB window for the fit image. This memory can be reclaimed once the kernel starts running.

Signed-off-by Madan Srinivas <[email protected]>
---
 include/configs/ti_armv7_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/ti_armv7_common.h +0 -0
index a4676d3a7f..16ea22857f 100644

include/configs/ti_armv7_common.h line 59

Quoted 8 lines
include/configs/ti_armv7_common.h +1 -1
@@ -53,7 +53,7 @@
 
 #define DEFAULT_FIT_TI_ARGS \
 	"boot_fit=0\0" \
-	"fit_loadaddr=0x88000000\0" \
+	"fit_loadaddr=0x87000000\0" \
 	"fit_bootfile=fitImage\0" \
 	"update_to_fit=setenv loadaddr ${fit_loadaddr}; setenv bootfile ${fit_bootfile}\0" \
 	"loadfit=run args_mmc; bootm ${loadaddr}#${fdtfile};\0" \

OK, why is fit_loadaddr different from loadaddr?

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170718/29da9f30/attachment.sig>
author
#2 lore raw

PATCH 1/1 configs: ti: armv7: Fixes bug in fit_loadaddr for ramfs boot

Quoted 24 lines · Tom Rini
Quoted 23 lines · Andrew F. Davis

From: Madan Srinivas <[email protected]>

The load address of ramdisk, rdaddr is 0x88080000 and fit_loadaddr is defined as 0x88000000. This leaves only 512Kbytes for the fit image. When the FIT images are larger than this, it will overwite the ramdisk and cause the boot to fail.

For eg, The K2 HS fit images are a few MB and end up overwriting the ramdsk. This patch moves the fit_loadaddr to 0x87000000, leaving a 16MB window for the fit image. This memory can be reclaimed once the kernel starts running.

Signed-off-by Madan Srinivas <[email protected]>
---
 include/configs/ti_armv7_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/ti_armv7_common.h +0 -0
index a4676d3a7f..16ea22857f 100644
@@ -53,7 +53,7 @@
Quoted 10 lines

include/configs/ti_armv7_common.h line 59

Quoted 7 lines
include/configs/ti_armv7_common.h +1 -1
 #define DEFAULT_FIT_TI_ARGS \
 	"boot_fit=0\0" \
-	"fit_loadaddr=0x88000000\0" \
+	"fit_loadaddr=0x87000000\0" \
 	"fit_bootfile=fitImage\0" \
 	"update_to_fit=setenv loadaddr ${fit_loadaddr}; setenv bootfile ${fit_bootfile}\0" \
 	"loadfit=run args_mmc; bootm ${loadaddr}#${fdtfile};\0" \

OK, why is fit_loadaddr different from loadaddr?

Are you asking why they are different addresses? They need to be or the kernel will be unpacked from the FIT onto the FIT image (I think).

If you are asking why not use the variable 'fit_loadaddr' for all FIT loading activities it is because we use the same commands as loading other images, after 'update_to_fit' is run, any command that loads 'bootfile' to 'loadaddr' will load our FIT image correctly for us.

Andrew

#3 lore raw

PATCH 1/1 configs: ti: armv7: Fixes bug in fit_loadaddr for ramfs boot

Quoted 36 lines · Andrew F. Davis
Quoted 24 lines · Tom Rini
Quoted 23 lines · Andrew F. Davis

From: Madan Srinivas <[email protected]>

The load address of ramdisk, rdaddr is 0x88080000 and fit_loadaddr is defined as 0x88000000. This leaves only 512Kbytes for the fit image. When the FIT images are larger than this, it will overwite the ramdisk and cause the boot to fail.

For eg, The K2 HS fit images are a few MB and end up overwriting the ramdsk. This patch moves the fit_loadaddr to 0x87000000, leaving a 16MB window for the fit image. This memory can be reclaimed once the kernel starts running.

Signed-off-by Madan Srinivas <[email protected]>
---
 include/configs/ti_armv7_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/ti_armv7_common.h +0 -0
index a4676d3a7f..16ea22857f 100644
@@ -53,7 +53,7 @@
Quoted 10 lines

include/configs/ti_armv7_common.h line 59

Quoted 7 lines
include/configs/ti_armv7_common.h +1 -1
 #define DEFAULT_FIT_TI_ARGS \
 	"boot_fit=0\0" \
-	"fit_loadaddr=0x88000000\0" \
+	"fit_loadaddr=0x87000000\0" \
 	"fit_bootfile=fitImage\0" \
 	"update_to_fit=setenv loadaddr ${fit_loadaddr}; setenv bootfile ${fit_bootfile}\0" \
 	"loadfit=run args_mmc; bootm ${loadaddr}#${fdtfile};\0" \

OK, why is fit_loadaddr different from loadaddr?

Quoted 2 lines

Are you asking why they are different addresses? They need to be or the kernel will be unpacked from the FIT onto the FIT image (I think).

And here we get to one of the sad parts about FIT images. If you construct your FIT with:

                kernel at 1 { 
...
                        type = "kernel_noload";

Then you can do what I describe, load the FIT image to $loadaddr and this even works for when you include a ramdisk in the image too. Now, if you're using type = "kernel" which I suspect you are, it then depends on if there is overlap between where the FIT image is loaded into memory and where you set load/entry of the kernel inside of the FIT image.

And, I assume it's intentional that you're using a FIT image for kernel and device tree, but separate initrd file, and we wouldn't address the issue by including the ramdisk into the FIT itself.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170718/c28db1ba/attachment.sig>
#4 lore raw
In reply to Andrew F. Davis
Quoted 7 lines · Andrew F. Davis

From: Madan Srinivas <[email protected]>

The load address of ramdisk, rdaddr is 0x88080000 and fit_loadaddr is defined as 0x88000000. This leaves only 512Kbytes for the fit image. When the FIT images are larger than this, it will overwite the ramdisk and cause the boot to fail.

Quoted 6 lines

For eg, The K2 HS fit images are a few MB and end up overwriting the ramdsk. This patch moves the fit_loadaddr to 0x87000000, leaving a 16MB window for the fit image. This memory can be reclaimed once the kernel starts running.

Signed-off-by Madan Srinivas <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170726/6a3c23e6/attachment.sig>