Re: [U-Boot] [PATCH 0/5] fix the boot issue of Rockchip RK3036
Hi Philipp:
On 2017年06月30日 16:14, Dr. Philipp Tomsich wrote:
Andy,
On 30 Jun 2017, at 09:47, Andy Yan andy.yan@rock-chips.com wrote:
As Kever mentioned in [0], the RK3036 based boards could't bootup for a long time. After a git bisect, I found the RK3036 SPL code size has increased from patch [1] [2]. Before Tom's patch [1], the SPL size is 3160 bytes, but it becomes 4080 bytes after [1] applied. After a look at this patch, I realised I should disable SPL_USE_ARCH_MEMCPY/MEMSET, and the code size indeed come down after I disabled them. But I got a LD error after apply patch[2]: "undefined reference to memset", RK3036 SPL didn't use lib/string because of the sram space imitation. The compile succeed after CONFIG_SPL_LIBGENERIC_SUPPORT enabled, but the spl code size become 3248 bytes.
Additionally, Simon post patch [3] call printf to print a message before back to bootrom from spl, which make the spl code size increased to nearly 3.7 kb.
RK3036 SPL only has 4kb sram to use, the spl code will use 3.4 ~ 3.5 kb, the last 0.5kb are used for SP and GD, so there is no space for malloc.
gcc-6-arm-linux-gnueabi What version of GCC are you using? If your problem can also be solved by moving to GCC 6.3 (or newer) and the code-size improvements there, I’d rather just require a more recent GCC version.
I default use arm-linux-gnueabe-gcc v5.4. The current upstream kylin-rk3036_defconfig compiled by gcc-5.4 is 4384 bytes, the size comes down to 3936 bytes if I use arm-linux-gnueabihf-gcc v6.3 from linaro. But this is still too large for rk3036. Disable SPL_USE_ARCH_MEMCPY/MEMSET will make the spl size comes down to 3042 bytes by gcc v6.3. But I still need some hack: enable CONFIG_SPL_LIBGENERIC to get support for memset, masks Simon's print in bootrom.c, or the code size will become very large. Event though this hack make things work, we still lost a few hundreds bytes by function board_init_f_alloc_reserve, because platforms with very limit sram like rk3036 will return to bootrom after the dram initialized, they never use the malloc space. This few hundreds bytes is a large space for 4kb sarm, it's better to letf them for code or SP.
Another thing to check would be whether you are building SPL as a THUMB2 binary, as this can also help with the SPL size.
Yes, THUMB2 is default enabled.
To fix this issue on RK3036, I disabled CONFIG_SPL_LIBGENERIC_SUPPORT, also make board_init_f_alloc_reserve and board_init_f_init_reserve as weak function, then override them in rk3036-board-spl.c with a no malloc resered function.
[0] https://lists.denx.de/pipermail/u-boot/2017-May/292744.html [1] http://patchwork.ozlabs.org/patch/714593/ [2] http://patchwork.ozlabs.org/patch/714592/ [3] http://patchwork.ozlabs.org/patch/751080/
Andy Yan (5): board_init.c: make the reserve functions as weak rockchip: rk3036: only reserve space for GD and SP in SPL stage rockchip: configs: disable SPL_ARCH_MEMCPY/MEMSET for rk3036 rockchip: configs: add DEBUG UART for kylin board rockchip: add u-boot specific dts for rk3036 sdk
arch/arm/dts/rk3036-sdk-u-boot.dtsi | 11 +++++++++ arch/arm/mach-rockchip/rk3036-board-spl.c | 37 +++++++++++++++++++++++++++++++ common/init/board_init.c | 4 ++-- configs/evb-rk3036_defconfig | 2 ++ configs/kylin-rk3036_defconfig | 6 +++++ 5 files changed, 58 insertions(+), 2 deletions(-) create mode 100644 arch/arm/dts/rk3036-sdk-u-boot.dtsi
-- 2.7.4
On Mon, Jul 03, 2017 at 04:02:59PM +0800, Andy Yan wrote:
Hi Philipp:
On 2017年06月30日 16:14, Dr. Philipp Tomsich wrote:
Andy,
On 30 Jun 2017, at 09:47, Andy Yan andy.yan@rock-chips.com wrote:
As Kever mentioned in [0], the RK3036 based boards could't bootup for a long time. After a git bisect, I found the RK3036 SPL code size has increased from patch [1] [2]. Before Tom's patch [1], the SPL size is 3160 bytes, but it becomes 4080 bytes after [1] applied. After a look at this patch, I realised I should disable SPL_USE_ARCH_MEMCPY/MEMSET, and the code size indeed come down after I disabled them. But I got a LD error after apply patch[2]: "undefined reference to memset", RK3036 SPL didn't use lib/string because of the sram space imitation. The compile succeed after CONFIG_SPL_LIBGENERIC_SUPPORT enabled, but the spl code size become 3248 bytes.
Additionally, Simon post patch [3] call printf to print a message before back to bootrom from spl, which make the spl code size increased to nearly 3.7 kb.
RK3036 SPL only has 4kb sram to use, the spl code will use 3.4 ~ 3.5 kb, the last 0.5kb are used for SP and GD, so there is no space for malloc.
gcc-6-arm-linux-gnueabi What version of GCC are you using? If your problem can also be solved by moving to GCC 6.3 (or newer) and the code-size improvements there, I’d rather just require a more recent GCC version.
I default use arm-linux-gnueabe-gcc v5.4. The current upstream kylin-rk3036_defconfig compiled by gcc-5.4is 4384 bytes, the size comes down to 3936 bytes if I use arm-linux-gnueabihf-gcc v6.3 from linaro. But this is still too large for rk3036.
Please note that (and U-Boot should be complaining at you) that with v2018.01 we'll be moving to gcc-6.x or later for ARM.
Disable SPL_USE_ARCH_MEMCPY/MEMSET will make the spl size comesdown to 3042 bytes by gcc v6.3. But I still need some hack: enable CONFIG_SPL_LIBGENERIC to get support for memset, masks Simon's print in bootrom.c, or the code size will become very large. Event though this hack make things work, we still lost a few hundreds bytes by function board_init_f_alloc_reserve, because platforms with very limit sram like rk3036 will return to bootrom after the dram initialized, they never use the malloc space. This few hundreds bytes is a large space for 4kb sarm, it's better to letf them for code or SP.
Since we're really size constrained here maybe it makes sense to move that print to a debug() ?
For what it’s worth: GCC 7.1 (in an aarch64-unknown-elf configuration) is now our default build-environment for our RK3399 and RK3368 boards and works as expected.
On 04 Jul 2017, at 15:32, Tom Rini trini@konsulko.com wrote:
On Mon, Jul 03, 2017 at 04:02:59PM +0800, Andy Yan wrote:
Hi Philipp:
On 2017年06月30日 16:14, Dr. Philipp Tomsich wrote:
Andy,
On 30 Jun 2017, at 09:47, Andy Yan andy.yan@rock-chips.com wrote:
As Kever mentioned in [0], the RK3036 based boards could't bootup for a long time. After a git bisect, I found the RK3036 SPL code size has increased from patch [1] [2]. Before Tom's patch [1], the SPL size is 3160 bytes, but it becomes 4080 bytes after [1] applied. After a look at this patch, I realised I should disable SPL_USE_ARCH_MEMCPY/MEMSET, and the code size indeed come down after I disabled them. But I got a LD error after apply patch[2]: "undefined reference to memset", RK3036 SPL didn't use lib/string because of the sram space imitation. The compile succeed after CONFIG_SPL_LIBGENERIC_SUPPORT enabled, but the spl code size become 3248 bytes.
Additionally, Simon post patch [3] call printf to print a message before back to bootrom from spl, which make the spl code size increased to nearly 3.7 kb.
RK3036 SPL only has 4kb sram to use, the spl code will use 3.4 ~ 3.5 kb, the last 0.5kb are used for SP and GD, so there is no space for malloc.
gcc-6-arm-linux-gnueabi What version of GCC are you using? If your problem can also be solved by moving to GCC 6.3 (or newer) and the code-size improvements there, I’d rather just require a more recent GCC version.
I default use arm-linux-gnueabe-gcc v5.4. The current upstream kylin-rk3036_defconfig compiled by gcc-5.4 is 4384 bytes, the size comes down to 3936 bytes if I use arm-linux-gnueabihf-gcc v6.3 from linaro. But this is still too large for rk3036.
Please note that (and U-Boot should be complaining at you) that with v2018.01 we'll be moving to gcc-6.x or later for ARM.
Disable SPL_USE_ARCH_MEMCPY/MEMSET will make the spl size comes down to 3042 bytes by gcc v6.3. But I still need some hack: enable CONFIG_SPL_LIBGENERIC to get support for memset, masks Simon's print in bootrom.c, or the code size will become very large. Event though this hack make things work, we still lost a few hundreds bytes by function board_init_f_alloc_reserve, because platforms with very limit sram like rk3036 will return to bootrom after the dram initialized, they never use the malloc space. This few hundreds bytes is a large space for 4kb sarm, it's better to letf them for code or SP.
Since we're really size constrained here maybe it makes sense to move that print to a debug() ?
-- Tom
Hi Tom:
On 2017年07月04日 21:32, Tom Rini wrote:
On Mon, Jul 03, 2017 at 04:02:59PM +0800, Andy Yan wrote:
Hi Philipp:
On 2017年06月30日 16:14, Dr. Philipp Tomsich wrote:
Andy,
On 30 Jun 2017, at 09:47, Andy Yan andy.yan@rock-chips.com wrote:
As Kever mentioned in [0], the RK3036 based boards could't bootup for a long time. After a git bisect, I found the RK3036 SPL code size has increased from patch [1] [2]. Before Tom's patch [1], the SPL size is 3160 bytes, but it becomes 4080 bytes after [1] applied. After a look at this patch, I realised I should disable SPL_USE_ARCH_MEMCPY/MEMSET, and the code size indeed come down after I disabled them. But I got a LD error after apply patch[2]: "undefined reference to memset", RK3036 SPL didn't use lib/string because of the sram space imitation. The compile succeed after CONFIG_SPL_LIBGENERIC_SUPPORT enabled, but the spl code size become 3248 bytes.
Additionally, Simon post patch [3] call printf to print a message before back to bootrom from spl, which make the spl code size increased to nearly 3.7 kb.
RK3036 SPL only has 4kb sram to use, the spl code will use 3.4 ~ 3.5 kb, the last 0.5kb are used for SP and GD, so there is no space for malloc.
gcc-6-arm-linux-gnueabi What version of GCC are you using? If your problem can also be solved by moving to GCC 6.3 (or newer) and the code-size improvements there, I’d rather just require a more recent GCC version.
I default use arm-linux-gnueabe-gcc v5.4. The current upstream kylin-rk3036_defconfig compiled by gcc-5.4is 4384 bytes, the size comes down to 3936 bytes if I use arm-linux-gnueabihf-gcc v6.3 from linaro. But this is still too large for rk3036.
Please note that (and U-Boot should be complaining at you) that with v2018.01 we'll be moving to gcc-6.x or later for ARM.
Disable SPL_USE_ARCH_MEMCPY/MEMSET will make the spl size comesdown to 3042 bytes by gcc v6.3. But I still need some hack: enable CONFIG_SPL_LIBGENERIC to get support for memset, masks Simon's print in bootrom.c, or the code size will become very large. Event though this hack make things work, we still lost a few hundreds bytes by function board_init_f_alloc_reserve, because platforms with very limit sram like rk3036 will return to bootrom after the dram initialized, they never use the malloc space. This few hundreds bytes is a large space for 4kb sarm, it's better to letf them for code or SP.
Since we're really size constrained here maybe it makes sense to move that print to a debug() ?
Yes, move it to debug() will mask the printf in normal. But even so, we still lost a few hundreds bytes in function
board_init_f_alloc_reserve for malloc. RK3036 will returned to bootrom immediately after the sdram initialization, the few hundreds space for malloc pool is never used in SPL stage.
On Wed, Jul 05, 2017 at 09:08:47AM +0800, Andy Yan wrote:
Hi Tom:
On 2017年07月04日 21:32, Tom Rini wrote:
On Mon, Jul 03, 2017 at 04:02:59PM +0800, Andy Yan wrote:
Hi Philipp:
On 2017年06月30日 16:14, Dr. Philipp Tomsich wrote:
Andy,
On 30 Jun 2017, at 09:47, Andy Yan andy.yan@rock-chips.com wrote:
As Kever mentioned in [0], the RK3036 based boards could't bootup for a long time. After a git bisect, I found the RK3036 SPL code size has increased from patch [1] [2]. Before Tom's patch [1], the SPL size is 3160 bytes, but it becomes 4080 bytes after [1] applied. After a look at this patch, I realised I should disable SPL_USE_ARCH_MEMCPY/MEMSET, and the code size indeed come down after I disabled them. But I got a LD error after apply patch[2]: "undefined reference to memset", RK3036 SPL didn't use lib/string because of the sram space imitation. The compile succeed after CONFIG_SPL_LIBGENERIC_SUPPORT enabled, but the spl code size become 3248 bytes.
Additionally, Simon post patch [3] call printf to print a message before back to bootrom from spl, which make the spl code size increased to nearly 3.7 kb.
RK3036 SPL only has 4kb sram to use, the spl code will use 3.4 ~ 3.5 kb, the last 0.5kb are used for SP and GD, so there is no space for malloc.
gcc-6-arm-linux-gnueabi What version of GCC are you using? If your problem can also be solved by moving to GCC 6.3 (or newer) and the code-size improvements there, I’d rather just require a more recent GCC version.
I default use arm-linux-gnueabe-gcc v5.4. The current upstream kylin-rk3036_defconfig compiled by gcc-5.4is 4384 bytes, the size comes down to 3936 bytes if I use arm-linux-gnueabihf-gcc v6.3 from linaro. But this is still too large for rk3036.
Please note that (and U-Boot should be complaining at you) that with v2018.01 we'll be moving to gcc-6.x or later for ARM.
Disable SPL_USE_ARCH_MEMCPY/MEMSET will make the spl size comesdown to 3042 bytes by gcc v6.3. But I still need some hack: enable CONFIG_SPL_LIBGENERIC to get support for memset, masks Simon's print in bootrom.c, or the code size will become very large. Event though this hack make things work, we still lost a few hundreds bytes by function board_init_f_alloc_reserve, because platforms with very limit sram like rk3036 will return to bootrom after the dram initialized, they never use the malloc space. This few hundreds bytes is a large space for 4kb sarm, it's better to letf them for code or SP.
Since we're really size constrained here maybe it makes sense to move that print to a debug() ?
Yes, move it to debug() will mask the printf in normal. But even so, we still lost a few hundreds bytes in function
board_init_f_alloc_reserve for malloc. RK3036 will returned to bootrom immediately after the sdram initialization, the few hundreds space for malloc pool is never used in SPL stage.
Can you work the code paths out such that board_init_f_alloc_reserve would not be called then?
Hi Tom:
On 2017年07月05日 09:56, Tom Rini wrote:
On Wed, Jul 05, 2017 at 09:08:47AM +0800, Andy Yan wrote:
Hi Tom:
On 2017年07月04日 21:32, Tom Rini wrote:
On Mon, Jul 03, 2017 at 04:02:59PM +0800, Andy Yan wrote:
Hi Philipp:
On 2017年06月30日 16:14, Dr. Philipp Tomsich wrote:
Andy,
On 30 Jun 2017, at 09:47, Andy Yan andy.yan@rock-chips.com wrote:
As Kever mentioned in [0], the RK3036 based boards could't bootup for a long time. After a git bisect, I found the RK3036 SPL code size has increased from patch [1] [2]. Before Tom's patch [1], the SPL size is 3160 bytes, but it becomes 4080 bytes after [1] applied. After a look at this patch, I realised I should disable SPL_USE_ARCH_MEMCPY/MEMSET, and the code size indeed come down after I disabled them. But I got a LD error after apply patch[2]: "undefined reference to memset", RK3036 SPL didn't use lib/string because of the sram space imitation. The compile succeed after CONFIG_SPL_LIBGENERIC_SUPPORT enabled, but the spl code size become 3248 bytes.
Additionally, Simon post patch [3] call printf to print a message before back to bootrom from spl, which make the spl code size increased to nearly 3.7 kb.
RK3036 SPL only has 4kb sram to use, the spl code will use 3.4 ~ 3.5 kb, the last 0.5kb are used for SP and GD, so there is no space for malloc.
gcc-6-arm-linux-gnueabi What version of GCC are you using? If your problem can also be solved by moving to GCC 6.3 (or newer) and the code-size improvements there, I’d rather just require a more recent GCC version.
I default use arm-linux-gnueabe-gcc v5.4. The current upstream kylin-rk3036_defconfig compiled by gcc-5.4is 4384 bytes, the size comes down to 3936 bytes if I use arm-linux-gnueabihf-gcc v6.3 from linaro. But this is still too large for rk3036.
Please note that (and U-Boot should be complaining at you) that with v2018.01 we'll be moving to gcc-6.x or later for ARM.
Disable SPL_USE_ARCH_MEMCPY/MEMSET will make the spl size comesdown to 3042 bytes by gcc v6.3. But I still need some hack: enable CONFIG_SPL_LIBGENERIC to get support for memset, masks Simon's print in bootrom.c, or the code size will become very large. Event though this hack make things work, we still lost a few hundreds bytes by function board_init_f_alloc_reserve, because platforms with very limit sram like rk3036 will return to bootrom after the dram initialized, they never use the malloc space. This few hundreds bytes is a large space for 4kb sarm, it's better to letf them for code or SP.
Since we're really size constrained here maybe it makes sense to move that print to a debug() ?
Yes, move it to debug() will mask the printf in normal. But even so, we still lost a few hundreds bytes in function
board_init_f_alloc_reserve for malloc. RK3036 will returned to bootrom immediately after the sdram initialization, the few hundreds space for malloc pool is never used in SPL stage.
Can you work the code paths out such that board_init_f_alloc_reserve would not be called then?
board_init_f_alloc_reserve is called from crt0.S, in not so easy to work the code path out. And board_init_f_alloc_reserve also reserve space for GD, this is we needed. So I want make this function as weak, then I can override it in my board spl state.
On Wed, Jul 05, 2017 at 02:21:03PM +0800, Andy Yan wrote:
Hi Tom:
On 2017年07月05日 09:56, Tom Rini wrote:
On Wed, Jul 05, 2017 at 09:08:47AM +0800, Andy Yan wrote:
Hi Tom:
On 2017年07月04日 21:32, Tom Rini wrote:
On Mon, Jul 03, 2017 at 04:02:59PM +0800, Andy Yan wrote:
Hi Philipp:
On 2017年06月30日 16:14, Dr. Philipp Tomsich wrote:
Andy,
>On 30 Jun 2017, at 09:47, Andy Yan andy.yan@rock-chips.com wrote: > > >As Kever mentioned in [0], the RK3036 based boards could't >bootup for a long time. >After a git bisect, I found the RK3036 SPL code size has >increased from patch [1] [2]. Before Tom's patch [1], the >SPL size is 3160 bytes, but it becomes 4080 bytes after [1] >applied. After a look at this patch, I realised I should >disable SPL_USE_ARCH_MEMCPY/MEMSET, and the code size indeed >come down after I disabled them. But I got a LD error after >apply patch[2]: "undefined reference to memset", RK3036 SPL >didn't use lib/string because of the sram space imitation. >The compile succeed after CONFIG_SPL_LIBGENERIC_SUPPORT enabled, >but the spl code size become 3248 bytes. > >Additionally, Simon post patch [3] call printf to print a >message before back to bootrom from spl, which make the spl >code size increased to nearly 3.7 kb. > >RK3036 SPL only has 4kb sram to use, the spl code will use >3.4 ~ 3.5 kb, the last 0.5kb are used for SP and GD, so there >is no space for malloc. gcc-6-arm-linux-gnueabi What version of GCC are you using? If your problem can also be solved by moving to GCC 6.3 (or newer) and the code-size improvements there, I’d rather just require a more recent GCC version.
I default use arm-linux-gnueabe-gcc v5.4. The current upstream kylin-rk3036_defconfig compiled by gcc-5.4is 4384 bytes, the size comes down to 3936 bytes if I use arm-linux-gnueabihf-gcc v6.3 from linaro. But this is still too large for rk3036.
Please note that (and U-Boot should be complaining at you) that with v2018.01 we'll be moving to gcc-6.x or later for ARM.
Disable SPL_USE_ARCH_MEMCPY/MEMSET will make the spl size comesdown to 3042 bytes by gcc v6.3. But I still need some hack: enable CONFIG_SPL_LIBGENERIC to get support for memset, masks Simon's print in bootrom.c, or the code size will become very large. Event though this hack make things work, we still lost a few hundreds bytes by function board_init_f_alloc_reserve, because platforms with very limit sram like rk3036 will return to bootrom after the dram initialized, they never use the malloc space. This few hundreds bytes is a large space for 4kb sarm, it's better to letf them for code or SP.
Since we're really size constrained here maybe it makes sense to move that print to a debug() ?
Yes, move it to debug() will mask the printf in normal. But even so, we still lost a few hundreds bytes in function
board_init_f_alloc_reserve for malloc. RK3036 will returned to bootrom immediately after the sdram initialization, the few hundreds space for malloc pool is never used in SPL stage.
Can you work the code paths out such that board_init_f_alloc_reserve would not be called then?
board_init_f_alloc_reserve is called from crt0.S, in not so easy to work the code path out. And board_init_f_alloc_reserve also reserve space for GD, this is we needed. So I want make this function as weak, then I can override it in my board spl state.
Sounds like a reasonable path to explore, thanks.
Hi Andy,
Am Montag, 3. Juli 2017, 16:02:59 CEST schrieb Andy Yan:
On 2017年06月30日 16:14, Dr. Philipp Tomsich wrote:
On 30 Jun 2017, at 09:47, Andy Yan andy.yan@rock-chips.com wrote: As Kever mentioned in [0], the RK3036 based boards could't bootup for a long time. After a git bisect, I found the RK3036 SPL code size has increased from patch [1] [2]. Before Tom's patch [1], the SPL size is 3160 bytes, but it becomes 4080 bytes after [1] applied. After a look at this patch, I realised I should disable SPL_USE_ARCH_MEMCPY/MEMSET, and the code size indeed come down after I disabled them. But I got a LD error after apply patch[2]: "undefined reference to memset", RK3036 SPL didn't use lib/string because of the sram space imitation. The compile succeed after CONFIG_SPL_LIBGENERIC_SUPPORT enabled, but the spl code size become 3248 bytes.
Additionally, Simon post patch [3] call printf to print a message before back to bootrom from spl, which make the spl code size increased to nearly 3.7 kb.
RK3036 SPL only has 4kb sram to use, the spl code will use 3.4 ~ 3.5 kb, the last 0.5kb are used for SP and GD, so there is no space for malloc.
gcc-6-arm-linux-gnueabi What version of GCC are you using? If your problem can also be solved by moving to GCC 6.3 (or newer) and the code-size improvements there, I’d rather just require a more recent GCC version.
I default use arm-linux-gnueabe-gcc v5.4. The current upstream kylin-rk3036_defconfig compiled by gcc-5.4 is4384 bytes, the size comes down to 3936 bytes if I use arm-linux-gnueabihf-gcc v6.3 from linaro. But this is still too large for rk3036. Disable SPL_USE_ARCH_MEMCPY/MEMSET will make the spl size comes down to 3042 bytes by gcc v6.3. But I still need some hack: enable CONFIG_SPL_LIBGENERIC to get support for memset, masks Simon's print in bootrom.c, or the code size will become very large. Event though this hack make things work, we still lost a few hundreds bytes by function board_init_f_alloc_reserve, because platforms with very limit sram like rk3036 will return to bootrom after the dram initialized, they never use the malloc space. This few hundreds bytes is a large space for 4kb sarm, it's better to letf them for code or SP.
For a start, maybe you could take a look at Simon's size reduction series from april. The TPL-specific stuff may not be that interesting, but the first patch adds a totally slimmed down memset, which may be better for real hard size constraints
[PATCH v2 0/5] Patches to reduce TPL code size: https://www.mail-archive.com/u-boot@lists.denx.de/msg243443.html
Heiko
Hi Heiko:
On 2017年07月05日 03:54, Heiko Stübner wrote:
Hi Andy,
Am Montag, 3. Juli 2017, 16:02:59 CEST schrieb Andy Yan:
On 2017年06月30日 16:14, Dr. Philipp Tomsich wrote:
On 30 Jun 2017, at 09:47, Andy Yan andy.yan@rock-chips.com wrote: As Kever mentioned in [0], the RK3036 based boards could't bootup for a long time. After a git bisect, I found the RK3036 SPL code size has increased from patch [1] [2]. Before Tom's patch [1], the SPL size is 3160 bytes, but it becomes 4080 bytes after [1] applied. After a look at this patch, I realised I should disable SPL_USE_ARCH_MEMCPY/MEMSET, and the code size indeed come down after I disabled them. But I got a LD error after apply patch[2]: "undefined reference to memset", RK3036 SPL didn't use lib/string because of the sram space imitation. The compile succeed after CONFIG_SPL_LIBGENERIC_SUPPORT enabled, but the spl code size become 3248 bytes.
Additionally, Simon post patch [3] call printf to print a message before back to bootrom from spl, which make the spl code size increased to nearly 3.7 kb.
RK3036 SPL only has 4kb sram to use, the spl code will use 3.4 ~ 3.5 kb, the last 0.5kb are used for SP and GD, so there is no space for malloc.
gcc-6-arm-linux-gnueabi What version of GCC are you using? If your problem can also be solved by moving to GCC 6.3 (or newer) and the code-size improvements there, I’d rather just require a more recent GCC version.
I default use arm-linux-gnueabe-gcc v5.4. The current upstream kylin-rk3036_defconfig compiled by gcc-5.4 is4384 bytes, the size comes down to 3936 bytes if I use arm-linux-gnueabihf-gcc v6.3 from linaro. But this is still too large for rk3036. Disable SPL_USE_ARCH_MEMCPY/MEMSET will make the spl size comes down to 3042 bytes by gcc v6.3. But I still need some hack: enable CONFIG_SPL_LIBGENERIC to get support for memset, masks Simon's print in bootrom.c, or the code size will become very large. Event though this hack make things work, we still lost a few hundreds bytes by function board_init_f_alloc_reserve, because platforms with very limit sram like rk3036 will return to bootrom after the dram initialized, they never use the malloc space. This few hundreds bytes is a large space for 4kb sarm, it's better to letf them for code or SP.Heiko
For a start, maybe you could take a look at Simon's size reduction series from april. The TPL-specific stuff may not be that interesting, but the first patch adds a totally slimmed down memset, which may be better for real hard size constraints
[PATCH v2 0/5] Patches to reduce TPL code size: https://www.mail-archive.com/u-boot@lists.denx.de/msg243443.html
The SPL_TINY_MEMSET was included in my hack.
Heiko
participants (4)
-
Andy Yan -
Dr. Philipp Tomsich -
Heiko Stübner -
Tom Rini