spl: Weed out CONFIG_SYS_TEXT_BASE usage
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
The SPL loaders assume that the CONFIG_SYS_TEXT_BASE memory location is available and can be corrupted by loading ie. uImage or fitImage headers there. Sometimes it could be beneficial to load the headers elsewhere, ie. if CONFIG_SYS_TEXT_BASE is not yet writable while we still want to parse the image headers in some local onchip memory to ie. extract firmware from that image.
Add the possibility to override the location where the headers get loaded by introducing new function, spl_get_load_buffer() which takes two arguments -- offset from the CONFIG_SYS_TEXT_BASE and size of the data that are to be loaded there -- and returns a valid buffer address or hangs the system. The default behavior is the same as before, add the offset to CONFIG_SYS_TEXT_BASE and return that address. User can override the weak spl_get_load_buffer() function though.
---
V2: Fix build issues on multiple boards due to incorrect pointer casting
--- common/spl/spl.c | 5 +++++ common/spl/spl_ext.c | 3 +-- common/spl/spl_fat.c | 3 +-- common/spl/spl_fit.c | 6 +++--- common/spl/spl_mmc.c | 6 +++--- common/spl/spl_nand.c | 4 ++-- common/spl/spl_onenand.c | 3 +-- common/spl/spl_ram.c | 5 +++-- common/spl/spl_spi.c | 3 +-- common/spl/spl_ubi.c | 3 +-- include/spl.h | 9 +++++++++ 11 files changed, 30 insertions(+), 20 deletions(-)
common/spl/spl.c +5 -0
@@ -127,6 +127,11 @@ __weak void spl_board_prepare_for_boot(void)/* Nothing to do! */ } +__weak struct image_header *spl_get_load_buffer (ssize_t offset,size_t size) +{ +return (struct image_header *)(CONFIG_SYS_TEXT_BASE + offset); +} +void spl_set_header_raw_uboot (struct spl_image_info *spl_image) {ulong u_boot_pos =binman_sym (ulong, u_boot_any, image_pos);
common/spl/spl_ext.c +1 -2
@@ -16,8 +16,7 @@ int spl_load_image_ext(struct spl_image_info *spl_image,loff_t filelen, actlen;disk_partition_t part_info = {}; - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header )); + header =spl_get_load_buffer (-sizeof (*header),sizeof (*header));if (part_get_info (block_dev, partition, &part_info)) {printf ("spl: no partition table found\n" );
common/spl/spl_fat.c +1 -2
@@ -63,8 +63,7 @@ int spl_load_image_fat(struct spl_image_info *spl_image,if (err) goto end; - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header )); + header =spl_get_load_buffer (-sizeof (*header),sizeof (*header)); err =file_fat_read (filename, header,sizeof (struct image_header ));if (err <=0 )
common/spl/spl_fit.c +3 -3
@@ -357,7 +357,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,struct spl_image_info image_info;int node =-1 ;int images, ret; -int base_offset, align_len =ARCH_DMA_MINALIGN -1 ; +int base_offset, hsize, align_len =ARCH_DMA_MINALIGN -1 ;int index =0 ;/*
@@ -386,8 +386,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,* For FIT with data embedded, data is loaded as part of FIT image. * For FIT with external data, data is not loaded in this step. */ - fit = (void *)((CONFIG_SYS_TEXT_BASE - size - info->bl_len - - align_len) & ~align_len); + hsize = (size + info->bl_len + align_len) & ~align_len; + fit =spl_get_load_buffer (-hsize, hsize); sectors =get_aligned_image_size (info, size,0 ); count = info->read (info, sector, sectors, fit); debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu\n",
common/spl/spl_mmc.c +3 -3
@@ -55,13 +55,13 @@ int mmc_load_image_raw_sector(struct spl_image_info *spl_image, {unsigned long count;struct image_header *header; +struct blk_desc *bd =mmc_get_blk_desc (mmc);int ret =0 ; - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header )); + header =spl_get_load_buffer (-sizeof (*header), bd->blksz);/* read image header to find the image size & load address */ - count =blk_dread (mmc_get_blk_desc (mmc), sector,1 , header); + count =blk_dread (bd, sector,1 , header);debug ("hdr read sector %lx, count=%lu\n" , sector, count);if (count ==0 ) { ret = -EIO ;
common/spl/spl_nand.c +2 -2
@@ -83,8 +83,8 @@ static int spl_nand_load_image(struct spl_image_info *spl_image,#endif nand_init (); -/*use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (0 ,sizeof (*header)); +#ifdef CONFIG_SPL_OS_BOOT if (!spl_start_uboot ()) {/*
common/spl/spl_onenand.c +1 -2
@@ -21,8 +21,7 @@ static int spl_onenand_load_image(struct spl_image_info *spl_image,debug ("spl: onenand\n" ); -/*use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (0 ,CONFIG_SYS_ONENAND_PAGE_SIZE );/* Load u-boot */ onenand_spl_load_image (CONFIG_SYS_ONENAND_U_BOOT_OFFS ,CONFIG_SYS_ONENAND_PAGE_SIZE , (void *)header);
common/spl/spl_ram.c +3 -2
@@ -63,8 +63,9 @@ static int spl_ram_load_image(struct spl_image_info *spl_image,* No binman support or no information. For now, fix it * to the address pointed to by U-Boot. */ - u_boot_pos =CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header ); + header =spl_get_load_buffer (-sizeof (*header), +sizeof (*header)); + } header = (struct image_header *)map_sysmem (u_boot_pos,0 );
common/spl/spl_spi.c +1 -2
@@ -88,8 +88,7 @@ static int spl_spi_load_image(struct spl_image_info *spl_image,return -ENODEV ; } -/* use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (-sizeof (*header),0x40 );#if CONFIG_IS_ENABLED (OF_CONTROL ) && !CONFIG_IS_ENABLED (OF_PLATDATA ) payload_offs = fdtdec_get_config_int(gd->fdt_blob,
common/spl/spl_ubi.c +1 -2
@@ -61,8 +61,7 @@ int spl_ubi_load_image(struct spl_image_info *spl_image, puts("Loading Linux failed, falling back to U-Boot.\n"); }#endif - header = (struct image_header *) - (CONFIG_SYS_TEXT_BASE -sizeof (struct image_header )); + header =spl_get_load_buffer (-sizeof (*header),sizeof (header)); volumes[0 ].vol_id =CONFIG_SPL_UBI_LOAD_MONITOR_ID ; volumes[0 ].load_addr = (void *)header;
include/spl.h +9 -0
@@ -303,4 +303,13 @@ void board_return_to_bootrom(void);* the boot-payload */ void spl_perform_fixups (struct spl_image_info *spl_image); + +/* +* spl_get_load_buffer() - get buffer for loading partial image data +* +* Returns memory area which can be populated by partial image data, +* ie. uImage or fitImage header. +*/ +struct image_header *spl_get_load_buffer (ssize_t offset,size_t size); +#endif
Signature · 1 line
2.16.2
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
Quoted 157 lines · Marek Vasut
The SPL loaders assume that the
CONFIG_SYS_TEXT_BASEmemory location is available and can be corrupted by loading ie. uImage or fitImage headers there. Sometimes it could be beneficial to load the headers elsewhere, ie. ifCONFIG_SYS_TEXT_BASEis not yet writable while we still want to parse the image headers in some local onchip memory to ie. extract firmware from that image.Add the possibility to override the location where the headers get loaded by introducing new function,
spl_get_load_buffer()which takes two arguments -- offset from theCONFIG_SYS_TEXT_BASEand size of the data that are to be loaded there -- and returns a valid buffer address or hangs the system. The default behavior is the same as before, add the offset toCONFIG_SYS_TEXT_BASEand return that address. User can override the weakspl_get_load_buffer()function though.Signed-off-by Marek Vasut <[email protected]>Cc Tom Rini <[email protected]>---
V2: Fix build issues on multiple boards due to incorrect pointer casting--- common/spl/spl.c | 5 +++++ common/spl/spl_ext.c | 3 +-- common/spl/spl_fat.c | 3 +-- common/spl/spl_fit.c | 6 +++--- common/spl/spl_mmc.c | 6 +++--- common/spl/spl_nand.c | 4 ++-- common/spl/spl_onenand.c | 3 +-- common/spl/spl_ram.c | 5 +++-- common/spl/spl_spi.c | 3 +-- common/spl/spl_ubi.c | 3 +-- include/spl.h | 9 +++++++++ 11 files changed, 30 insertions(+), 20 deletions(-)common/spl/spl.c +5
-0@@ -127,6 +127,11 @@ __weak void spl_board_prepare_for_boot(void)/* Nothing to do! */ } +__weak struct image_header *spl_get_load_buffer (ssize_t offset,size_t size) +{ +return (struct image_header *)(CONFIG_SYS_TEXT_BASE + offset); +} +void spl_set_header_raw_uboot (struct spl_image_info *spl_image) {ulong u_boot_pos =binman_sym (ulong, u_boot_any, image_pos);common/spl/spl_ext.c +1
-2@@ -16,8 +16,7 @@ int spl_load_image_ext(struct spl_image_info *spl_image,loff_t filelen, actlen;disk_partition_t part_info = {}; - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header )); + header =spl_get_load_buffer (-sizeof (*header),sizeof (*header));if (part_get_info (block_dev, partition, &part_info)) {printf ("spl: no partition table found\n" );common/spl/spl_fat.c +1
-2@@ -63,8 +63,7 @@ int spl_load_image_fat(struct spl_image_info *spl_image,if (err) goto end; - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header )); + header =spl_get_load_buffer (-sizeof (*header),sizeof (*header)); err =file_fat_read (filename, header,sizeof (struct image_header ));if (err <=0 )common/spl/spl_fit.c +3
-3@@ -357,7 +357,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,struct spl_image_info image_info;int node =-1 ;int images, ret; -int base_offset, align_len =ARCH_DMA_MINALIGN -1 ; +int base_offset, hsize, align_len =ARCH_DMA_MINALIGN -1 ;int index =0 ;/* @@ -386,8 +386,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,* For FIT with data embedded, data is loaded as part of FIT image. * For FIT with external data, data is not loaded in this step. */ - fit = (void *)((CONFIG_SYS_TEXT_BASE - size - info->bl_len - - align_len) & ~align_len); + hsize = (size + info->bl_len + align_len) & ~align_len; + fit =spl_get_load_buffer (-hsize, hsize); sectors =get_aligned_image_size (info, size,0 ); count = info->read (info, sector, sectors, fit); debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu\n",common/spl/spl_mmc.c +3
-3@@ -55,13 +55,13 @@ int mmc_load_image_raw_sector(struct spl_image_info *spl_image, {unsigned long count;struct image_header *header; +struct blk_desc *bd =mmc_get_blk_desc (mmc);int ret =0 ; - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header )); + header =spl_get_load_buffer (-sizeof (*header), bd->blksz);/* read image header to find the image size & load address */ - count =blk_dread (mmc_get_blk_desc (mmc), sector,1 , header); + count =blk_dread (bd, sector,1 , header);debug ("hdr read sector %lx, count=%lu\n" , sector, count);if (count ==0 ) { ret = -EIO ;common/spl/spl_nand.c +2
-2@@ -83,8 +83,8 @@ static int spl_nand_load_image(struct spl_image_info *spl_image,#endif nand_init (); -/*use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (0 ,sizeof (*header)); +#ifdef CONFIG_SPL_OS_BOOT if (!spl_start_uboot ()) {/* common/spl/spl_onenand.c +1
-2@@ -21,8 +21,7 @@ static int spl_onenand_load_image(struct spl_image_info *spl_image,debug ("spl: onenand\n" ); -/*use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (0 ,CONFIG_SYS_ONENAND_PAGE_SIZE );/* Load u-boot */ onenand_spl_load_image (CONFIG_SYS_ONENAND_U_BOOT_OFFS ,CONFIG_SYS_ONENAND_PAGE_SIZE , (void *)header);common/spl/spl_ram.c +0
-0
common/spl/spl_ram.c static int spl_ram_load_image(struct spl_image_info *spl_image, · line 68
Quoted 8 lines
common/spl/spl_ram.c +3
-2@@ -63,8 +63,9 @@ static int spl_ram_load_image(struct spl_image_info *spl_image,* No binman support or no information. For now, fix it * to the address pointed to by U-Boot. */ - u_boot_pos =CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header ); + header =spl_get_load_buffer (-sizeof (*header), +sizeof (*header)); +
Using "spl_get_load_buffer()" here seems to be a bit misleading, as the address is used for "execute-in-place", not for loading.
Quoted 8 lines
common/spl/spl_ram.c +0
-0} header = (struct image_header *)map_sysmem (u_boot_pos,0 );common/spl/spl_spi.c +0
-0
common/spl/spl_spi.c static int spl_spi_load_image(struct spl_image_info *spl_image, · line 91
Quoted 6 lines
common/spl/spl_spi.c +1
-2@@ -88,8 +88,7 @@ static int spl_spi_load_image(struct spl_image_info *spl_image,return -ENODEV ; } -/* use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (-sizeof (*header),0x40 );
Shouldn't the first argument be 0 here instead of -sizeof(*header)?
Quoted 42 lines
common/spl/spl_spi.c +0
-0#if CONFIG_IS_ENABLED (OF_CONTROL ) && !CONFIG_IS_ENABLED (OF_PLATDATA ) payload_offs = fdtdec_get_config_int(gd->fdt_blob,common/spl/spl_ubi.c +1
-2@@ -61,8 +61,7 @@ int spl_ubi_load_image(struct spl_image_info *spl_image, puts("Loading Linux failed, falling back to U-Boot.\n"); }#endif - header = (struct image_header *) - (CONFIG_SYS_TEXT_BASE -sizeof (struct image_header )); + header =spl_get_load_buffer (-sizeof (*header),sizeof (header)); volumes[0 ].vol_id =CONFIG_SPL_UBI_LOAD_MONITOR_ID ; volumes[0 ].load_addr = (void *)header;include/spl.h +9
-1@@ -303,4 +303,13 @@ void board_return_to_bootrom(void);* the boot-payload */ void spl_perform_fixups (struct spl_image_info *spl_image); + +/* +* spl_get_load_buffer() - get buffer for loading partial image data +* +* Returns memory area which can be populated by partial image data, +* ie. uImage or fitImage header. +*/ +struct image_header *spl_get_load_buffer (ssize_t offset,size_t size); +#endif --2.16.2
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
Quoted 21 lines · Simon Goldschmidt
Quoted 20 lines · Marek Vasut
The SPL loaders assume that the
CONFIG_SYS_TEXT_BASEmemory location is available and can be corrupted by loading ie. uImage or fitImage headers there. Sometimes it could be beneficial to load the headers elsewhere, ie. ifCONFIG_SYS_TEXT_BASEis not yet writable while we still want to parse the image headers in some local onchip memory to ie. extract firmware from that image.Add the possibility to override the location where the headers get loaded by introducing new function,
spl_get_load_buffer()which takes two arguments -- offset from theCONFIG_SYS_TEXT_BASEand size of the data that are to be loaded there -- and returns a valid buffer address or hangs the system. The default behavior is the same as before, add the offset toCONFIG_SYS_TEXT_BASEand return that address. User can override the weakspl_get_load_buffer()function though.Signed-off-by Marek Vasut <[email protected]>Cc Tom Rini <[email protected]>---
V2: Fix build issues on multiple boards due to incorrect pointer casting
[...]
Quoted 8 lines
Quoted 8 lines
common/spl/spl_ram.c +0
-0@@ -63,8 +63,9 @@ static int spl_ram_load_image(struct spl_image_info *spl_image,* No binman support or no information. For now, fix it * to the address pointed to by U-Boot. */
Quoted 8 lines
common/spl/spl_ram.c static int spl_ram_load_image(struct spl_image_info *spl_image, · line 68
Quoted 5 lines
common/spl/spl_ram.c +3
-2- u_boot_pos =CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header ); + header =spl_get_load_buffer (-sizeof (*header), +sizeof (*header)); +Using "
spl_get_load_buffer()" here seems to be a bit misleading, as the address is used for "execute-in-place", not for loading.
Do you have a better solution ? Instead of hard-coding the load buffer address with some macro, this uses function which could be overridden. Whether it's XIP or not has nothing to do with it.
Quoted 11 lines
Quoted 11 lines
common/spl/spl_ram.c +0
-0} header = (struct image_header *)map_sysmem (u_boot_pos,0 );common/spl/spl_spi.c +0
-0@@ -88,8 +88,7 @@ static int spl_spi_load_image(struct spl_image_info *spl_image,return -ENODEV ; }
Quoted 5 lines
common/spl/spl_spi.c static int spl_spi_load_image(struct spl_image_info *spl_image, · line 91
Quoted 3 lines
common/spl/spl_spi.c +1
-2-/* use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (-sizeof (*header),0x40 );Shouldn't the first argument be 0 here instead of -sizeof(*header)?
No, because then the payload doesn't end up at CONFIG_SYS_TEXT_BASE .
[...]
Signature · 2 lines
Best regards, Marek Vasut
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
Quoted 43 lines · Marek Vasut
Quoted 21 lines · Simon Goldschmidt
Quoted 20 lines · Marek Vasut
The SPL loaders assume that the
CONFIG_SYS_TEXT_BASEmemory location is available and can be corrupted by loading ie. uImage or fitImage headers there. Sometimes it could be beneficial to load the headers elsewhere, ie. ifCONFIG_SYS_TEXT_BASEis not yet writable while we still want to parse the image headers in some local onchip memory to ie. extract firmware from that image.Add the possibility to override the location where the headers get loaded by introducing new function,
spl_get_load_buffer()which takes two arguments -- offset from theCONFIG_SYS_TEXT_BASEand size of the data that are to be loaded there -- and returns a valid buffer address or hangs the system. The default behavior is the same as before, add the offset toCONFIG_SYS_TEXT_BASEand return that address. User can override the weakspl_get_load_buffer()function though.Signed-off-by Marek Vasut <[email protected]>Cc Tom Rini <[email protected]>---
V2: Fix build issues on multiple boards due to incorrect pointer casting[...]
Quoted 8 lines
Quoted 8 lines
common/spl/spl_ram.c +0
-0@@ -63,8 +63,9 @@ static int spl_ram_load_image(struct spl_image_info *spl_image,* No binman support or no information. For now, fix it * to the address pointed to by U-Boot. */ Quoted 8 lines
common/spl/spl_ram.c static int spl_ram_load_image(struct spl_image_info *spl_image, · line 68
Quoted 5 lines
common/spl/spl_ram.c +3
-2- u_boot_pos =CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header ); + header =spl_get_load_buffer (-sizeof (*header), +sizeof (*header)); +Using "
spl_get_load_buffer()" here seems to be a bit misleading, as the address is used for "execute-in-place", not for loading.
Quoted 3 lines
Do you have a better solution ? Instead of hard-coding the load buffer address with some macro, this uses function which could be overridden. Whether it's XIP or not has nothing to do with it.
I meant the name is a bit misleading as it implies loading. But since the preferred way to do this is using binman, it's probably not worth adding yet another weak function for RAM boot?
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
common/spl/spl_ram.c +0
-0} header = (struct image_header *)map_sysmem (u_boot_pos,0 );common/spl/spl_spi.c +0
-0@@ -88,8 +88,7 @@ static int spl_spi_load_image(struct spl_image_info *spl_image,return -ENODEV ; }
Quoted 7 lines
Quoted 5 lines
common/spl/spl_spi.c static int spl_spi_load_image(struct spl_image_info *spl_image, · line 91
Quoted 3 lines
common/spl/spl_spi.c +1
-2-/* use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (-sizeof (*header),0x40 );Shouldn't the first argument be 0 here instead of -sizeof(*header)?
No, because then the payload doesn't end up at
CONFIG_SYS_TEXT_BASE.
Sorry, I haven't studied the code around the patch, only the patch. And I still think "header" has changed from "CONFIG_SYS_TEXT_BASE" to "CONFIG_SYS_TEXT_BASE - sizeof(*header)" with your patch. That might be a change required to get it work, I don't know that. But as this isn' mentioned in the commit message, to me it seemed like a copy and paste error or something.
Simon
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
Quoted 44 lines · Simon Goldschmidt
Quoted 43 lines · Marek Vasut
Quoted 21 lines · Simon Goldschmidt
Quoted 20 lines · Marek Vasut
The SPL loaders assume that the
CONFIG_SYS_TEXT_BASEmemory location is available and can be corrupted by loading ie. uImage or fitImage headers there. Sometimes it could be beneficial to load the headers elsewhere, ie. ifCONFIG_SYS_TEXT_BASEis not yet writable while we still want to parse the image headers in some local onchip memory to ie. extract firmware from that image.Add the possibility to override the location where the headers get loaded by introducing new function,
spl_get_load_buffer()which takes two arguments -- offset from theCONFIG_SYS_TEXT_BASEand size of the data that are to be loaded there -- and returns a valid buffer address or hangs the system. The default behavior is the same as before, add the offset toCONFIG_SYS_TEXT_BASEand return that address. User can override the weakspl_get_load_buffer()function though.Signed-off-by Marek Vasut <[email protected]>Cc Tom Rini <[email protected]>---
V2: Fix build issues on multiple boards due to incorrect pointer casting[...]
Quoted 16 lines
common/spl/spl_ram.c static int spl_ram_load_image(struct spl_image_info *spl_image, · line 68
Quoted 13 lines
common/spl/spl_ram.c +3
-2@@ -63,8 +63,9 @@ static int spl_ram_load_image(struct spl_image_info *spl_image,* No binman support or no information. For now, fix it * to the address pointed to by U-Boot. */ - u_boot_pos =CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header ); + header =spl_get_load_buffer (-sizeof (*header), +sizeof (*header)); +Using "
spl_get_load_buffer()" here seems to be a bit misleading, as the address is used for "execute-in-place", not for loading.
Quoted 7 lines
Quoted 3 lines
Do you have a better solution ? Instead of hard-coding the load buffer address with some macro, this uses function which could be overridden. Whether it's XIP or not has nothing to do with it.
I meant the name is a bit misleading as it implies loading. But since the preferred way to do this is using binman, it's probably not worth adding yet another weak function for RAM boot?
Do you have a better name that fits all the other usecases ? This function just gets you buffer into which you can load the image.
Quoted 17 lines
Quoted 17 lines
Quoted 16 lines
Quoted 8 lines
common/spl/spl_ram.c +0
-0} header = (struct image_header *)map_sysmem (u_boot_pos,0 );common/spl/spl_spi.c +0
-0common/spl/spl_spi.c static int spl_spi_load_image(struct spl_image_info *spl_image, · line 91
Quoted 6 lines
common/spl/spl_spi.c +1
-2@@ -88,8 +88,7 @@ static int spl_spi_load_image(struct spl_image_info *spl_image,return -ENODEV ; } -/* use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (-sizeof (*header),0x40 );Shouldn't the first argument be 0 here instead of -sizeof(*header)?
Quoted 8 lines
Quoted 1 line
No, because then the payload doesn't end up at
CONFIG_SYS_TEXT_BASE.Sorry, I haven't studied the code around the patch, only the patch. And I still think "header" has changed from "
CONFIG_SYS_TEXT_BASE" to "CONFIG_SYS_TEXT_BASE-sizeof(*header)" with your patch. That might be a change required to get it work, I don't know that. But as this isn' mentioned in the commit message, to me it seemed like a copy and paste error or something.
I suspect it's the SPI that's weird. Look at the surrounding code, IMO this is how it should be.
Quoted 2 lines
Simon
Signature · 2 lines
Best regards, Marek Vasut
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
Quoted 50 lines · Marek Vasut
Quoted 48 lines · Simon Goldschmidt
Quoted 46 lines · Marek Vasut
Quoted 21 lines · Simon Goldschmidt
Quoted 20 lines · Marek Vasut
The SPL loaders assume that the
CONFIG_SYS_TEXT_BASEmemory location is available and can be corrupted by loading ie. uImage or fitImage headers there. Sometimes it could be beneficial to load the headers elsewhere, ie. ifCONFIG_SYS_TEXT_BASEis not yet writable while we still want to parse the image headers in some local onchip memory to ie. extract firmware from that image.Add the possibility to override the location where the headers get loaded by introducing new function,
spl_get_load_buffer()which takes two arguments -- offset from theCONFIG_SYS_TEXT_BASEand size of the data that are to be loaded there -- and returns a valid buffer address or hangs the system. The default behavior is the same as before, add the offset toCONFIG_SYS_TEXT_BASEand return that address. User can override the weakspl_get_load_buffer()function though.Signed-off-by Marek Vasut <[email protected]>Cc Tom Rini <[email protected]>---
V2: Fix build issues on multiple boards due to incorrect pointer casting[...]
Quoted 8 lines
Quoted 8 lines
common/spl/spl_ram.c +0
-0@@ -63,8 +63,9 @@ static int spl_ram_load_image(struct spl_image_info *spl_image,* No binman support or no information. For now, fix it * to the address pointed to by U-Boot. */ Quoted 8 lines
common/spl/spl_ram.c static int spl_ram_load_image(struct spl_image_info *spl_image, · line 68
Quoted 5 lines
common/spl/spl_ram.c +3
-2- u_boot_pos =CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header ); + header =spl_get_load_buffer (-sizeof (*header), +sizeof (*header)); +Using "
spl_get_load_buffer()" here seems to be a bit misleading, as the address is used for "execute-in-place", not for loading.Do you have a better solution ? Instead of hard-coding the load buffer address with some macro, this uses function which could be overridden. Whether it's XIP or not has nothing to do with it.
Quoted 6 lines
Quoted 3 lines
I meant the name is a bit misleading as it implies loading. But since the preferred way to do this is using binman, it's probably not worth adding yet another weak function for RAM boot?
Do you have a better name that fits all the other usecases ? This function just gets you buffer into which you can load the image.
Not really. I just wonder if you have to override the location for some board, RAM booting might not work any more as it relies on a fixed address, not some generic buffer.
Maybe we could add the boot device to your new weak function? If we add some comment to the new weak function, that would have made it much more clear for me how to boot U-Boot from FPGA OnChip RAM when I tried some months ago :-)
Quoted 26 lines
Quoted 17 lines
Quoted 17 lines
Quoted 16 lines
Quoted 8 lines
common/spl/spl_ram.c +0
-0} header = (struct image_header *)map_sysmem (u_boot_pos,0 );common/spl/spl_spi.c +0
-0common/spl/spl_spi.c static int spl_spi_load_image(struct spl_image_info *spl_image, · line 91
Quoted 6 lines
common/spl/spl_spi.c +1
-2@@ -88,8 +88,7 @@ static int spl_spi_load_image(struct spl_image_info *spl_image,return -ENODEV ; } -/* use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (-sizeof (*header),0x40 );Shouldn't the first argument be 0 here instead of -sizeof(*header)?
Quoted 8 lines
Quoted 1 line
No, because then the payload doesn't end up at
CONFIG_SYS_TEXT_BASE.Sorry, I haven't studied the code around the patch, only the patch. And I still think "header" has changed from "
CONFIG_SYS_TEXT_BASE" to "CONFIG_SYS_TEXT_BASE-sizeof(*header)" with your patch. That might be a change required to get it work, I don't know that. But as this isn' mentioned in the commit message, to me it seemed like a copy and paste error or something.
Quoted 2 lines
I suspect it's the SPI that's weird. Look at the surrounding code, IMO this is how it should be.
Reading the code, I guess the exact location of 'header' is not important. So the code should still work after applying your patch, even if it changes the location of 'header'.
Simon
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
Quoted 55 lines · Simon Goldschmidt
Quoted 54 lines · Marek Vasut
Quoted 51 lines · Simon Goldschmidt
Quoted 43 lines · Marek Vasut
Quoted 21 lines · Simon Goldschmidt
Quoted 20 lines · Marek Vasut
The SPL loaders assume that the
CONFIG_SYS_TEXT_BASEmemory location is available and can be corrupted by loading ie. uImage or fitImage headers there. Sometimes it could be beneficial to load the headers elsewhere, ie. ifCONFIG_SYS_TEXT_BASEis not yet writable while we still want to parse the image headers in some local onchip memory to ie. extract firmware from that image.Add the possibility to override the location where the headers get loaded by introducing new function,
spl_get_load_buffer()which takes two arguments -- offset from theCONFIG_SYS_TEXT_BASEand size of the data that are to be loaded there -- and returns a valid buffer address or hangs the system. The default behavior is the same as before, add the offset toCONFIG_SYS_TEXT_BASEand return that address. User can override the weakspl_get_load_buffer()function though.Signed-off-by Marek Vasut <[email protected]>Cc Tom Rini <[email protected]>---
V2: Fix build issues on multiple boards due to incorrect pointer casting[...]
Quoted 8 lines
Quoted 8 lines
common/spl/spl_ram.c +0
-0@@ -63,8 +63,9 @@ static int spl_ram_load_image(struct spl_image_info *spl_image,* No binman support or no information. For now, fix it * to the address pointed to by U-Boot. */ Quoted 8 lines
common/spl/spl_ram.c static int spl_ram_load_image(struct spl_image_info *spl_image, · line 68
Quoted 5 lines
common/spl/spl_ram.c +3
-2- u_boot_pos =CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header ); + header =spl_get_load_buffer (-sizeof (*header), +sizeof (*header)); +Using "
spl_get_load_buffer()" here seems to be a bit misleading, as the address is used for "execute-in-place", not for loading.Quoted 3 lines
Do you have a better solution ? Instead of hard-coding the load buffer address with some macro, this uses function which could be overridden. Whether it's XIP or not has nothing to do with it.
I meant the name is a bit misleading as it implies loading. But since the preferred way to do this is using binman, it's probably not worth adding yet another weak function for RAM boot?
Quoted 6 lines
Quoted 2 lines
Do you have a better name that fits all the other usecases ? This function just gets you buffer into which you can load the image.
Not really. I just wonder if you have to override the location for some board, RAM booting might not work any more as it relies on a fixed address, not some generic buffer.
I do, yeah, the board is not upstream completely yet though, so I am just sending this as a cleanup.
Quoted 4 lines
Maybe we could add the boot device to your new weak function? If we add some comment to the new weak function, that would have made it much more clear for me how to boot U-Boot from FPGA OnChip RAM when I tried some months ago :-)
This really just gives you a buffer. I don't need to know which boot media is used. If there is a usecase, sure, it can be added later.
Quoted 26 lines
Quoted 26 lines
Quoted 25 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
common/spl/spl_ram.c +0
-0} header = (struct image_header *)map_sysmem (u_boot_pos,0 );common/spl/spl_spi.c +0
-0@@ -88,8 +88,7 @@ static int spl_spi_load_image(struct spl_image_info *spl_image,return -ENODEV ; }Quoted 7 lines
Quoted 5 lines
common/spl/spl_spi.c static int spl_spi_load_image(struct spl_image_info *spl_image, · line 91
Quoted 3 lines
common/spl/spl_spi.c +1
-2-/* use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (-sizeof (*header),0x40 );Shouldn't the first argument be 0 here instead of -sizeof(*header)?
No, because then the payload doesn't end up at
CONFIG_SYS_TEXT_BASE.Sorry, I haven't studied the code around the patch, only the patch. And I still think "header" has changed from "
CONFIG_SYS_TEXT_BASE" to "CONFIG_SYS_TEXT_BASE-sizeof(*header)" with your patch. That might be a change required to get it work, I don't know that. But as this isn' mentioned in the commit message, to me it seemed like a copy and paste error or something.
Quoted 6 lines
Quoted 2 lines
I suspect it's the SPI that's weird. Look at the surrounding code, IMO this is how it should be.
Reading the code, I guess the exact location of 'header' is not important. So the code should still work after applying your patch, even if it changes the location of 'header'.
The thing is, the payload (ie. uboot) is linked against the TEXT_BASE, so putting it at TEXT_BASE + offset can cause trouble.
Quoted 2 lines
Simon
Signature · 2 lines
Best regards, Marek Vasut
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
Quoted 67 lines · Marek Vasut
Quoted 55 lines · Simon Goldschmidt
Quoted 54 lines · Marek Vasut
Quoted 51 lines · Simon Goldschmidt
Quoted 43 lines · Marek Vasut
Quoted 21 lines · Simon Goldschmidt
Quoted 20 lines · Marek Vasut
The SPL loaders assume that the
CONFIG_SYS_TEXT_BASEmemory location is available and can be corrupted by loading ie. uImage or fitImage headers there. Sometimes it could be beneficial to load the headers elsewhere, ie. ifCONFIG_SYS_TEXT_BASEis not yet writable while we still want to parse the image headers in some local onchip memory to ie. extract firmware from that image.Add the possibility to override the location where the headers get loaded by introducing new function,
spl_get_load_buffer()which takes two arguments -- offset from theCONFIG_SYS_TEXT_BASEand size of the data that are to be loaded there -- and returns a valid buffer address or hangs the system. The default behavior is the same as before, add the offset toCONFIG_SYS_TEXT_BASEand return that address. User can override the weakspl_get_load_buffer()function though.Signed-off-by Marek Vasut <[email protected]>Cc Tom Rini <[email protected]>---
V2: Fix build issues on multiple boards due to incorrect pointer casting[...]
Quoted 8 lines
Quoted 8 lines
common/spl/spl_ram.c +0
-0@@ -63,8 +63,9 @@ static int spl_ram_load_image(struct spl_image_info *spl_image,* No binman support or no information. For now, fix it * to the address pointed to by U-Boot. */ Quoted 8 lines
common/spl/spl_ram.c static int spl_ram_load_image(struct spl_image_info *spl_image, · line 68
Quoted 5 lines
common/spl/spl_ram.c +3
-2- u_boot_pos =CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header ); + header =spl_get_load_buffer (-sizeof (*header), +sizeof (*header)); +Using "
spl_get_load_buffer()" here seems to be a bit misleading, as the address is used for "execute-in-place", not for loading.Quoted 3 lines
Do you have a better solution ? Instead of hard-coding the load buffer address with some macro, this uses function which could be overridden. Whether it's XIP or not has nothing to do with it.
I meant the name is a bit misleading as it implies loading. But since the preferred way to do this is using binman, it's probably not worth adding yet another weak function for RAM boot?
Quoted 6 lines
Quoted 2 lines
Do you have a better name that fits all the other usecases ? This function just gets you buffer into which you can load the image.
Not really. I just wonder if you have to override the location for some board, RAM booting might not work any more as it relies on a fixed address, not some generic buffer.
I do, yeah, the board is not upstream completely yet though, so I am just sending this as a cleanup.
Quoted 7 lines
Quoted 4 lines
Maybe we could add the boot device to your new weak function? If we add some comment to the new weak function, that would have made it much more clear for me how to boot U-Boot from FPGA OnChip RAM when I tried some months ago :-)
This really just gives you a buffer. I don't need to know which boot media is used. If there is a usecase, sure, it can be added later.
I may have a use case for one of our custom boards, but it's probably not worth doing that now.
Quoted 30 lines
Quoted 30 lines
Quoted 29 lines
Quoted 18 lines
Quoted 18 lines
Quoted 17 lines
Quoted 9 lines
common/spl/spl_ram.c +0
-0} header = (struct image_header *)map_sysmem (u_boot_pos,0 );common/spl/spl_spi.c +0
-0common/spl/spl_spi.c static int spl_spi_load_image(struct spl_image_info *spl_image, · line 91
Quoted 6 lines
common/spl/spl_spi.c +1
-2@@ -88,8 +88,7 @@ static int spl_spi_load_image(struct spl_image_info *spl_image,return -ENODEV ; } -/* use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (-sizeof (*header),0x40 );Shouldn't the first argument be 0 here instead of -sizeof(*header)?
Quoted 8 lines
Quoted 1 line
No, because then the payload doesn't end up at
CONFIG_SYS_TEXT_BASE.Sorry, I haven't studied the code around the patch, only the patch. And I still think "header" has changed from "
CONFIG_SYS_TEXT_BASE" to "CONFIG_SYS_TEXT_BASE-sizeof(*header)" with your patch. That might be a change required to get it work, I don't know that. But as this isn' mentioned in the commit message, to me it seemed like a copy and paste error or something.I suspect it's the SPI that's weird. Look at the surrounding code, IMO this is how it should be.
Quoted 6 lines
Quoted 3 lines
Reading the code, I guess the exact location of 'header' is not important. So the code should still work after applying your patch, even if it changes the location of 'header'.
The thing is, the payload (ie. uboot) is linked against the
TEXT_BASE, so putting it atTEXT_BASE+ offset can cause trouble.
Right. All I wanted to say is I saw something that changed but from the commit message, it didn't seem like it was intended. The rest seems fine to me right now, so if it's of any use:
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
Quoted 73 lines · Simon Goldschmidt
Quoted 72 lines · Marek Vasut
Quoted 55 lines · Simon Goldschmidt
Quoted 54 lines · Marek Vasut
Quoted 51 lines · Simon Goldschmidt
Quoted 43 lines · Marek Vasut
Quoted 21 lines · Simon Goldschmidt
Quoted 20 lines · Marek Vasut
The SPL loaders assume that the
CONFIG_SYS_TEXT_BASEmemory location is available and can be corrupted by loading ie. uImage or fitImage headers there. Sometimes it could be beneficial to load the headers elsewhere, ie. ifCONFIG_SYS_TEXT_BASEis not yet writable while we still want to parse the image headers in some local onchip memory to ie. extract firmware from that image.Add the possibility to override the location where the headers get loaded by introducing new function,
spl_get_load_buffer()which takes two arguments -- offset from theCONFIG_SYS_TEXT_BASEand size of the data that are to be loaded there -- and returns a valid buffer address or hangs the system. The default behavior is the same as before, add the offset toCONFIG_SYS_TEXT_BASEand return that address. User can override the weakspl_get_load_buffer()function though.Signed-off-by Marek Vasut <[email protected]>Cc Tom Rini <[email protected]>---
V2: Fix build issues on multiple boards due to incorrect pointer casting[...]
Quoted 8 lines
Quoted 8 lines
common/spl/spl_ram.c +0
-0@@ -63,8 +63,9 @@ static int spl_ram_load_image(struct spl_image_info *spl_image,* No binman support or no information. For now, fix it * to the address pointed to by U-Boot. */ Quoted 8 lines
common/spl/spl_ram.c static int spl_ram_load_image(struct spl_image_info *spl_image, · line 68
Quoted 5 lines
common/spl/spl_ram.c +3
-2- u_boot_pos =CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header ); + header =spl_get_load_buffer (-sizeof (*header), +sizeof (*header)); +Using "
spl_get_load_buffer()" here seems to be a bit misleading, as the address is used for "execute-in-place", not for loading.Quoted 3 lines
Do you have a better solution ? Instead of hard-coding the load buffer address with some macro, this uses function which could be overridden. Whether it's XIP or not has nothing to do with it.
I meant the name is a bit misleading as it implies loading. But since the preferred way to do this is using binman, it's probably not worth adding yet another weak function for RAM boot?
Quoted 6 lines
Quoted 2 lines
Do you have a better name that fits all the other usecases ? This function just gets you buffer into which you can load the image.
Not really. I just wonder if you have to override the location for some board, RAM booting might not work any more as it relies on a fixed address, not some generic buffer.
I do, yeah, the board is not upstream completely yet though, so I am just sending this as a cleanup.
Quoted 4 lines
Maybe we could add the boot device to your new weak function? If we add some comment to the new weak function, that would have made it much more clear for me how to boot U-Boot from FPGA OnChip RAM when I tried some months ago :-)
Quoted 5 lines
Quoted 2 lines
This really just gives you a buffer. I don't need to know which boot media is used. If there is a usecase, sure, it can be added later.
I may have a use case for one of our custom boards, but it's probably not worth doing that now.
Subsequent patch then ?
Quoted 42 lines
Quoted 29 lines
Quoted 29 lines
Quoted 28 lines
Quoted 17 lines
Quoted 17 lines
Quoted 16 lines
Quoted 8 lines
common/spl/spl_ram.c +0
-0} header = (struct image_header *)map_sysmem (u_boot_pos,0 );common/spl/spl_spi.c +0
-0common/spl/spl_spi.c static int spl_spi_load_image(struct spl_image_info *spl_image, · line 91
Quoted 6 lines
common/spl/spl_spi.c +1
-2@@ -88,8 +88,7 @@ static int spl_spi_load_image(struct spl_image_info *spl_image,return -ENODEV ; } -/* use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (-sizeof (*header),0x40 );Shouldn't the first argument be 0 here instead of -sizeof(*header)?
Quoted 8 lines
Quoted 1 line
No, because then the payload doesn't end up at
CONFIG_SYS_TEXT_BASE.Sorry, I haven't studied the code around the patch, only the patch. And I still think "header" has changed from "
CONFIG_SYS_TEXT_BASE" to "CONFIG_SYS_TEXT_BASE-sizeof(*header)" with your patch. That might be a change required to get it work, I don't know that. But as this isn' mentioned in the commit message, to me it seemed like a copy and paste error or something.I suspect it's the SPI that's weird. Look at the surrounding code, IMO this is how it should be.
Quoted 6 lines
Quoted 3 lines
Reading the code, I guess the exact location of 'header' is not important. So the code should still work after applying your patch, even if it changes the location of 'header'.
The thing is, the payload (ie. uboot) is linked against the
TEXT_BASE, so putting it atTEXT_BASE+ offset can cause trouble.Right. All I wanted to say is I saw something that changed but from the commit message, it didn't seem like it was intended. The rest seems fine to me right now, so if it's of any use:
Reviewed-by Simon Goldschmidt <[email protected]>
Signature · 2 lines
Best regards, Marek Vasut
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
Marek Vasut <[email protected]> schrieb am Mi., 15. Aug. 2018, 10:57:
Quoted 93 lines · Simon Goldschmidt
Quoted 10 lines · Marek Vasut
Quoted 9 lines · Simon Goldschmidt
Quoted 7 lines · Marek Vasut
Quoted 6 lines · Simon Goldschmidt
Quoted 4 lines · Marek Vasut
Quoted 3 lines · Simon Goldschmidt
Quoted 1 line
On Tue, Aug 14, 2018 at 11:27 AM Marek Vasut <[email protected]>
Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
The SPL loaders assume that the
CONFIG_SYS_TEXT_BASEmemorylocation
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
is available and can be corrupted by loading ie. uImage or
fitImage
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
headers there. Sometimes it could be beneficial to load the
headers
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
elsewhere, ie. if
CONFIG_SYS_TEXT_BASEis not yet writable whilewe
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
still want to parse the image headers in some local onchip memory
to
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
ie. extract firmware from that image.
Add the possibility to override the location where the headers get loaded by introducing new function,
spl_get_load_buffer()whichtakes
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
two arguments -- offset from the
CONFIG_SYS_TEXT_BASEand size ofthe
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
data that are to be loaded there -- and returns a valid buffer
address
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
or hangs the system. The default behavior is the same as before,
add
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
the offset to
CONFIG_SYS_TEXT_BASEand return that address. Usercan
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
override the weak
spl_get_load_buffer()function though.Signed-off-by Marek Vasut <[email protected]>Cc Tom Rini <[email protected]>---
V2: Fix build issues on multiple boards due to incorrect pointercasting
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
[...]
Quoted 5 lines
common/spl/spl_ram.c static int spl_ram_load_image(struct
Quoted 5 lines
common/spl/spl_ram.c +0
-0@@ -63,8 +63,9 @@ static int spl_ram_load_image(struct
spl_image_info*spl_image,Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
common/spl/spl_ram.c static int spl_ram_load_image(struct · line 63
Quoted 1 line
common/spl/spl_ram.c +0
-0* No binman support or no information. For now, fix it
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
common/spl/spl_ram.c static int spl_ram_load_image(struct · line 67
Quoted 4 lines
common/spl/spl_ram.c +0
-2* to the address pointed to by U-Boot. */ - u_boot_pos = CONFIG_SYS_TEXT_BASE - - sizeof(struct
image_header);Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
common/spl/spl_ram.c static int spl_ram_load_image(struct · line 66
Quoted 1 line
common/spl/spl_ram.c +1
-0+ header =spl_get_load_buffer(-sizeof(*header),
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
common/spl/spl_ram.c static int spl_ram_load_image(struct · line 67
Quoted 1 line
common/spl/spl_ram.c +1
-0+
sizeof(*header));Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
common/spl/spl_ram.c static int spl_ram_load_image(struct · line 68
Quoted 1 line
common/spl/spl_ram.c +1
-0+Using "
spl_get_load_buffer()" here seems to be a bit misleading, as the address is used for "execute-in-place", not for loading.Do you have a better solution ? Instead of hard-coding the load
buffer
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
address with some macro, this uses function which could be
overridden.
Quoted 21 lines
Quoted 21 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 1 line
Whether it's XIP or not has nothing to do with it.
I meant the name is a bit misleading as it implies loading. But since the preferred way to do this is using binman, it's probably not worth adding yet another weak function for RAM boot?
Quoted 6 lines
Quoted 2 lines
Do you have a better name that fits all the other usecases ? This function just gets you buffer into which you can load the image.
Not really. I just wonder if you have to override the location for some board, RAM booting might not work any more as it relies on a fixed address, not some generic buffer.
I do, yeah, the board is not upstream completely yet though, so I am just sending this as a cleanup.
Quoted 4 lines
Maybe we could add the boot device to your new weak function? If we add some comment to the new weak function, that would have made it much more clear for me how to boot U-Boot from FPGA OnChip RAM when I tried some months ago :-)
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
This really just gives you a buffer. I don't need to know which boot media is used. If there is a usecase, sure, it can be added later.
I may have a use case for one of our custom boards, but it's probably not worth doing that now.
Subsequent patch then ?
I'll send a patch if we really need that...
Quoted 51 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
common/spl/spl_ram.c static int spl_ram_load_image(struct · line 70
Quoted 2 lines
common/spl/spl_ram.c +0
-0} header = (struct image_header*)map_sysmem(u_boot_pos, 0);
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
common/spl/spl_spi.c static int spl_spi_load_image(struct
Quoted 6 lines
common/spl/spl_spi.c +0
-0@@ -88,8 +88,7 @@ static int spl_spi_load_image(struct
spl_image_info*spl_image,Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 8 lines
common/spl/spl_spi.c static int spl_spi_load_image(struct · line 91
Quoted 6 lines
common/spl/spl_spi.c +1
-2return -ENODEV ; } -/* use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (-sizeof (*header),0x40 );Shouldn't the first argument be 0 here instead of -sizeof(*header)?
No, because then the payload doesn't end up at
CONFIG_SYS_TEXT_BASE.
Quoted 15 lines
Quoted 15 lines
Quoted 14 lines
Quoted 10 lines
Quoted 7 lines
Sorry, I haven't studied the code around the patch, only the patch. And I still think "header" has changed from "
CONFIG_SYS_TEXT_BASE" to "CONFIG_SYS_TEXT_BASE-sizeof(*header)" with your patch. That might be a change required to get it work, I don't know that. But as this isn' mentioned in the commit message, to me it seemed like a copy and paste error or something.I suspect it's the SPI that's weird. Look at the surrounding code, IMO this is how it should be.
Reading the code, I guess the exact location of 'header' is not important. So the code should still work after applying your patch, even if it changes the location of 'header'.
Quoted 9 lines
Quoted 2 lines
The thing is, the payload (ie. uboot) is linked against the
TEXT_BASE, so putting it atTEXT_BASE+ offset can cause trouble.Right. All I wanted to say is I saw something that changed but from the commit message, it didn't seem like it was intended. The rest seems fine to me right now, so if it's of any use:
Reviewed-by Simon Goldschmidt <[email protected]>--
Best regards,
Marek Vasut
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
In reply to Marek VasutQuoted 15 lines · Marek Vasut
The SPL loaders assume that the
CONFIG_SYS_TEXT_BASEmemory location is available and can be corrupted by loading ie. uImage or fitImage headers there. Sometimes it could be beneficial to load the headers elsewhere, ie. ifCONFIG_SYS_TEXT_BASEis not yet writable while we still want to parse the image headers in some local onchip memory to ie. extract firmware from that image.Add the possibility to override the location where the headers get loaded by introducing new function,
spl_get_load_buffer()which takes two arguments -- offset from theCONFIG_SYS_TEXT_BASEand size of the data that are to be loaded there -- and returns a valid buffer address or hangs the system. The default behavior is the same as before, add the offset toCONFIG_SYS_TEXT_BASEand return that address. User can override the weakspl_get_load_buffer()function though.
Quoted 3 lines
Signed-off-by Marek Vasut <[email protected]>Cc Tom Rini <[email protected]>Reviewed-by Simon Goldschmidt <[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: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180926/c60c4946/attachment.sig>
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
In reply to Marek VasutHi Marek,
út 14. 8. 2018 v 11:27 odesílatel Marek Vasut <[email protected]> napsal:
Quoted 170 lines
The SPL loaders assume that the
CONFIG_SYS_TEXT_BASEmemory location is available and can be corrupted by loading ie. uImage or fitImage headers there. Sometimes it could be beneficial to load the headers elsewhere, ie. ifCONFIG_SYS_TEXT_BASEis not yet writable while we still want to parse the image headers in some local onchip memory to ie. extract firmware from that image.Add the possibility to override the location where the headers get loaded by introducing new function,
spl_get_load_buffer()which takes two arguments -- offset from theCONFIG_SYS_TEXT_BASEand size of the data that are to be loaded there -- and returns a valid buffer address or hangs the system. The default behavior is the same as before, add the offset toCONFIG_SYS_TEXT_BASEand return that address. User can override the weakspl_get_load_buffer()function though.Signed-off-by Marek Vasut <[email protected]>Cc Tom Rini <[email protected]>---
V2: Fix build issues on multiple boards due to incorrect pointer casting--- common/spl/spl.c | 5 +++++ common/spl/spl_ext.c | 3 +-- common/spl/spl_fat.c | 3 +-- common/spl/spl_fit.c | 6 +++--- common/spl/spl_mmc.c | 6 +++--- common/spl/spl_nand.c | 4 ++-- common/spl/spl_onenand.c | 3 +-- common/spl/spl_ram.c | 5 +++-- common/spl/spl_spi.c | 3 +-- common/spl/spl_ubi.c | 3 +-- include/spl.h | 9 +++++++++ 11 files changed, 30 insertions(+), 20 deletions(-)common/spl/spl.c +5
-0@@ -127,6 +127,11 @@ __weak void spl_board_prepare_for_boot(void)/* Nothing to do! */ } +__weak struct image_header *spl_get_load_buffer (ssize_t offset,size_t size) +{ +return (struct image_header *)(CONFIG_SYS_TEXT_BASE + offset); +} +void spl_set_header_raw_uboot (struct spl_image_info *spl_image) {ulong u_boot_pos = binman_sym(ulong, u_boot_any, image_pos);common/spl/spl_ext.c +1
-2@@ -16,8 +16,7 @@ int spl_load_image_ext(struct spl_image_info *spl_image,loff_t filelen, actlen;disk_partition_t part_info = {}; - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header)); + header =spl_get_load_buffer (-sizeof (*header),sizeof (*header));if (part_get_info (block_dev, partition, &part_info)) {printf("spl: no partition table found\n");common/spl/spl_fat.c +1
-2@@ -63,8 +63,7 @@ int spl_load_image_fat(struct spl_image_info *spl_image,if (err) goto end; - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header)); + header =spl_get_load_buffer (-sizeof (*header),sizeof (*header)); err =file_fat_read (filename, header,sizeof (struct image_header ));if (err <= 0)common/spl/spl_fit.c +1
-1@@ -357,7 +357,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image, struct spl_image_info image_info;int node =-1 ;int images, ret; -int base_offset, align_len =ARCH_DMA_MINALIGN -1 ; +int base_offset, hsize, align_len =ARCH_DMA_MINALIGN -1 ;int index =0 ;/*common/spl/spl_fit.c +2
-2@@ -386,8 +386,8 @@ int spl_load_simple_fit(struct spl_image_info*spl_image, * For FIT with data embedded, data is loaded as part of FIT image. * For FIT with external data, data is not loaded in this step. */ - fit = (void *)((CONFIG_SYS_TEXT_BASE - size - info->bl_len - - align_len) & ~align_len); + hsize = (size + info->bl_len + align_len) & ~align_len; + fit =spl_get_load_buffer (-hsize, hsize); sectors =get_aligned_image_size (info, size,0 ); count = info->read (info, sector, sectors, fit);debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu\n",
common/spl/spl_mmc.c +3
-3@@ -55,13 +55,13 @@ int mmc_load_image_raw_sector(struct spl_image_info *spl_image, {unsigned long count;struct image_header *header; +struct blk_desc *bd =mmc_get_blk_desc (mmc);int ret =0 ; - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header )); + header =spl_get_load_buffer (-sizeof (*header), bd->blksz);/* read image header to find the image size & load address */ - count =blk_dread (mmc_get_blk_desc (mmc), sector,1 , header); + count =blk_dread (bd, sector,1 , header);debug ("hdr read sector %lx, count=%lu\n" , sector, count);if (count ==0 ) {ret = -EIO;common/spl/spl_nand.c +2
-2@@ -83,8 +83,8 @@ static int spl_nand_load_image(struct spl_image_info *spl_image, #endif nand_init(); - /*use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE); + header = spl_get_load_buffer(0, sizeof(*header)); + #ifdef CONFIG_SPL_OS_BOOT if (!spl_start_uboot()) {/*common/spl/spl_onenand.c +1
-2@@ -21,8 +21,7 @@ static int spl_onenand_load_image(struct spl_image_info *spl_image,debug ("spl: onenand\n" ); -/*use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (0 ,CONFIG_SYS_ONENAND_PAGE_SIZE );/* Load u-boot */ onenand_spl_load_image(CONFIG_SYS_ONENAND_U_BOOT_OFFS,CONFIG_SYS_ONENAND_PAGE_SIZE, (void *)header);common/spl/spl_ram.c +0
-0@@ -63,8 +63,9 @@ static int spl_ram_load_image(struct spl_image_info *spl_image, * No binman support or no information. For now,fix it
* to the address pointed to by U-Boot. */
common/spl/spl_ram.c static int spl_ram_load_image(struct spl_image_info *spl_image, · line 68
Quoted 5 lines
common/spl/spl_ram.c +3
-2- u_boot_pos =CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header ); + header =spl_get_load_buffer (-sizeof (*header), +sizeof (*header)); +
I am curious how you have tested this change.
Because I see on my zc706 that this breaks my SPL boot flow. This should be assigned to u_boot_pos instead of header (which is done 2 line below)
and also here is additional empty line which shouldn't be there.
Quoted 8 lines
} header = (struct image_header *)map_sysmem(u_boot_pos, 0);common/spl/spl_spi.c +0
-0
common/spl/spl_spi.c static int spl_spi_load_image(struct spl_image_info · line 93
Quoted 8 lines
common/spl/spl_spi.c +1
-2@@ -88,8 +88,7 @@ static int spl_spi_load_image(struct spl_image_info *spl_image, return -ENODEV ; } -/* use CONFIG_SYS_TEXT_BASE as temporary storage area */ - header = (struct image_header *)(CONFIG_SYS_TEXT_BASE ); + header =spl_get_load_buffer (-sizeof (*header),0x40 );
And I am also curious why we have 0x40 here.
Thanks,
Michal
Signature · 5 lines
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
Quoted 1 line · Michal Simek
Hi Marek,
Hi,
[...]
Quoted 11 lines
Quoted 11 lines
common/spl/spl_ram.c +0
-0@@ -63,8 +63,9 @@ static int spl_ram_load_image(struct spl_image_info *spl_image, * No binman support or no information. For now,fix it
* to the address pointed to by U-Boot. */
-u_boot_pos=CONFIG_SYS_TEXT_BASE-
Quoted 8 lines
common/spl/spl_ram.c static int spl_ram_load_image(struct spl_image_info *spl_image, · line 68
Quoted 5 lines
common/spl/spl_ram.c +3
-1-sizeof (struct image_header ); + header =spl_get_load_buffer (-sizeof (*header), +sizeof (*header)); +I am curious how you have tested this change. Because I see on my zc706 that this breaks my SPL boot flow.
Definitely not on every single board we support ...
Quoted 3 lines
This should be assigned to
u_boot_posinstead of header (which is done 2 line below)
and also here is additional empty line which shouldn't be there.
Patches welcome. And yes, it should be u_boot_pos .
Signature · 2 lines
Best regards, Marek Vasut
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
Quoted 27 lines · Marek Vasut
Quoted 1 line · Michal Simek
Hi Marek,
Hi,
[...]
Quoted 11 lines
Quoted 11 lines
common/spl/spl_ram.c +0
-0@@ -63,8 +63,9 @@ static int spl_ram_load_image(struct spl_image_info *spl_image, * No binman support or no information. For now,fix it
* to the address pointed to by U-Boot. */
-u_boot_pos=CONFIG_SYS_TEXT_BASE-Quoted 8 lines
common/spl/spl_ram.c static int spl_ram_load_image(struct spl_image_info *spl_image, · line 68
Quoted 5 lines
common/spl/spl_ram.c +3
-1-sizeof (struct image_header ); + header =spl_get_load_buffer (-sizeof (*header), +sizeof (*header)); +I am curious how you have tested this change. Because I see on my zc706 that this breaks my SPL boot flow.
Quoted 1 line
Definitely not on every single board we support ...
non has asked for testing on every single board but you should test or at least ask for testing modes which you are not able to test yourself.
M
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
Quoted 28 lines · Michal Simek
Quoted 27 lines · Marek Vasut
Quoted 1 line · Michal Simek
Hi Marek,
Hi,
[...]
Quoted 19 lines
Quoted 11 lines
common/spl/spl_ram.c +0
-0@@ -63,8 +63,9 @@ static int spl_ram_load_image(struct spl_image_info *spl_image, * No binman support or no information. For now,fix it
* to the address pointed to by U-Boot. */common/spl/spl_ram.c static int spl_ram_load_image(struct spl_image_info *spl_image, · line 68
Quoted 5 lines
common/spl/spl_ram.c +3
-2- u_boot_pos =CONFIG_SYS_TEXT_BASE - -sizeof (struct image_header ); + header =spl_get_load_buffer (-sizeof (*header), +sizeof (*header)); +I am curious how you have tested this change. Because I see on my zc706 that this breaks my SPL boot flow.
Quoted 5 lines
Quoted 1 line
Definitely not on every single board we support ...
non has asked for testing on every single board but you should test or at least ask for testing modes which you are not able to test yourself.
You had the chance to review or test the patch while it was on the ML, it was there for a long time (months?), that's what the review process is for. Review process didn't catch it, so send a fix ...
Signature · 2 lines
Best regards, Marek Vasut
PATCH v2 1/1 spl: Weed out CONFIG_SYS_TEXT_BASE usage
Quoted 32 lines · Marek Vasut
Quoted 31 lines · Michal Simek
Quoted 28 lines · Marek Vasut
Quoted 1 line · Michal Simek
Hi Marek,
Hi,
[...]
Quoted 11 lines
Quoted 11 lines
common/spl/spl_ram.c +0
-0@@ -63,8 +63,9 @@ static int spl_ram_load_image(struct spl_image_info *spl_image, * No binman support or no information. For now,fix it
* to the address pointed to by U-Boot. */
-u_boot_pos=CONFIG_SYS_TEXT_BASE-Quoted 8 lines
common/spl/spl_ram.c static int spl_ram_load_image(struct spl_image_info *spl_image, · line 68
Quoted 5 lines
common/spl/spl_ram.c +3
-1-sizeof (struct image_header ); + header =spl_get_load_buffer (-sizeof (*header), +sizeof (*header)); +I am curious how you have tested this change. Because I see on my zc706 that this breaks my SPL boot flow.
Definitely not on every single board we support ...
Quoted 6 lines
Quoted 2 lines
non has asked for testing on every single board but you should test or at least ask for testing modes which you are not able to test yourself.
You had the chance to review or test the patch while it was on the ML, it was there for a long time (months?), that's what the review process is for. Review process didn't catch it, so send a fix ...
2 patches sent.
M