Hi Johan, On 2023-02-18 12:48, Johan Jonker wrote: > > > On 2/18/23 05:43, Johan Jonker wrote: >> Hi Jonas, >> >> On 2/17/23 21:52, Jonas Karlman wrote: >>> Sync init size limit from vendor u-boot: >> >> This sync might not be correct. >> Please recheck with each SoC or limit your change to the rk3328 SoC if prove >> fails. >> Could Kever disclose SoC details here? >> >> Johan >> >>> >>> px30: 12KiB (+2KiB) >> >>> rk3066: 32KiB (+2KiB) >> >> >> On the rk3066 the limitation depends on the bootrom logic and the tpl >> location it is loaded in memory: >> >> //SPL >> flash_boot_size = idb_buf[0].flash_boot_size; >> size = flash_boot_size - 5; >> if ( size >= 32763 ) >> flash_boot_size = 10; >> //TPL >> flash_data_size = idb_buf[0].flash_data_size; >> if (flash_data_size - 4 >= 61 || >> flash_boot_size < flash_data_size || >> flash_data_size & 3) { >> flash_data_size = 4; >> } >> >> offset = idb_buf[0].boot_code1_offset + start; >> >> === >> >> CONFIG_TPL_TEXT_BASE=0x10080C00 >> TPL/SPL truncated to 2048 = 4 sectors of 512bytes per NAND page. >> Header size = 4 x 512bytes >> >> limit1: flash_data_size - 4 >= 61 >> limit2: flash_boot_size < flash_data_size >>
Interesting details, not sure from where this is referenced, is this from the bootrom code? If my understanding is correct these refer to the same thing: usBootDataSize = flash_data_size = init_size usBootCodeSize = flash_boot_size = init_boot_size With 32KiB limit these would then in extreme case be: flash_data_size = 4 + 64 = 68 (full use of 32KiB) flash_boot_size = 68 + 1024 = 1092 (RK_MAX_BOOT_SIZE) and with a 30KiB limit: flash_data_size = 4 + 60 = 64 (full use of 30KiB) flash_boot_size = 68 + 1024 = 1088 (RK_MAX_BOOT_SIZE) With these limitations I fully understand why the value for rk3066 should not be changed, thanks. >> === >> >> usFlashDataSec = (ALIGN(dwLoaderDataSize, 2048)) / SECTOR_SIZE; >> usFlashBootSec = (ALIGN(dwLoaderSize, 2048)) / SECTOR_SIZE; >> >> dwSectorNum = 4 + usFlashDataSec + usFlashBootSec; >> >> pSec0->usBootDataSize = usFlashDataSec; >> pSec0->usBootCodeSize = usFlashDataSec + usFlashBootSec; >> >>> rk3328: 30KiB (+2KiB) >>> rk3568: 60KiB (-16KiB) >>> >>> This makes it possible to use latest vendor TPL with RK3328 without >>> getting a size limit error running the mkimage command. >>> >>> Signed-off-by: Jonas Karlman <jo...@kwiboo.se> >>> --- >>> v3: >>> - Sync with vendor u-boot as-is >>> - Update commit message to include size changes >>> >>> v2: >>> - New patch >>> >>> tools/rkcommon.c | 10 +++++----- >>> 1 file changed, 5 insertions(+), 5 deletions(-) >>> >>> diff --git a/tools/rkcommon.c b/tools/rkcommon.c >>> index 1f1eaa16752b..630e54b1a54d 100644 >>> --- a/tools/rkcommon.c >>> +++ b/tools/rkcommon.c >>> @@ -121,20 +121,20 @@ struct spl_info { >>> }; >>> >>> static struct spl_info spl_infos[] = { >>> - { "px30", "RK33", 0x2800, false, RK_HEADER_V1 }, >>> + { "px30", "RK33", 0x4000 - 0x1000, false, RK_HEADER_V1 }, >>> { "rk3036", "RK30", 0x1000, false, RK_HEADER_V1 }, >> > >>> - { "rk3066", "RK30", 0x8000 - 0x800, true, RK_HEADER_V1 }, >> >> This is OK. >> >>> - { "rk3128", "RK31", 0x1800, false, RK_HEADER_V1 }, >> > >>> + { "rk3066", "RK30", 0x8000, true, RK_HEADER_V1 }, >> >> This wrong. > > This 0x8000 value was introduced in the manufacturer kernel with this patch. > rockchip: mkimage: add support for rockchip nand boot image > https://github.com/rockchip-linux/u-boot/commit/6f14746b0c5977b93f126c43b2a80198758399b9>> > > However mainline u-boot for rk3066 makes use of BROM. > rockchip: rk3188: use boot0 hook to load up SPL in 2 steps > https://source.denx.de/u-boot/u-boot/-/commit/4d9253fb76f59c6f474ca54fe2d45c5706cd86e3>> > > It follows the same size rules as for rk3188. > /* spl size 32kb sram - 2kb bootrom */ >From what I could find in datasheet and TRM, the rk3066 have 64KiB sram and the rk3188 have 32KiB, but I have learned you can not always trust the datasheet and TRM :-) > > Unless Philipp Tomsich or someone else explains that it should be something > different, please keep it as it is. I fully agree, I will keep the value for rk3066 as it is. The limit for rk3328 and rk3568 are the only ones I can confirm fixes existing issues. rk3328: vendor tpl size is exceeding the current limit of 28KiB rk3568: only has 64KiB sram, current limit of 76 KiB do not fit Will limit the change to only include rk3328 and rk3568. Regards, Jonas > > Johan > > >> >> printf "%d\n" $(((0x8000 - 0x800 ) / 512)) >> 60 sectors of size 512 >> >> >>> + { "rk3128", "RK31", 0x2000 - 0x800, false, RK_HEADER_V1 }, >>> { "rk3188", "RK31", 0x8000 - 0x800, true, RK_HEADER_V1 }, >>> { "rk322x", "RK32", 0x8000 - 0x1000, false, RK_HEADER_V1 }, >>> { "rk3288", "RK32", 0x8000, false, RK_HEADER_V1 }, >>> { "rk3308", "RK33", 0x40000 - 0x1000, false, RK_HEADER_V1 }, >>> - { "rk3328", "RK32", 0x8000 - 0x1000, false, RK_HEADER_V1 }, >>> + { "rk3328", "RK32", 0x8000 - 0x800, false, RK_HEADER_V1 }, >>> { "rk3368", "RK33", 0x8000 - 0x1000, false, RK_HEADER_V1 }, >>> { "rk3399", "RK33", 0x30000 - 0x2000, false, RK_HEADER_V1 }, >>> { "rv1108", "RK11", 0x1800, false, RK_HEADER_V1 }, >>> { "rv1126", "110B", 0x10000 - 0x1000, false, RK_HEADER_V1 }, >>> - { "rk3568", "RK35", 0x14000 - 0x1000, false, RK_HEADER_V2 }, >>> + { "rk3568", "RK35", 0x10000 - 0x1000, false, RK_HEADER_V2 }, >>> }; >>> >>> /**