[U-Boot] [PATCH 0/5] fix the boot issue of Rockchip RK3036
Andy Yan
andy.yan at rock-chips.com
Mon Jul 3 08:02:59 UTC 2017
Hi Philipp:
On 2017年06月30日 16:14, Dr. Philipp Tomsich wrote:
> Andy,
>
>> On 30 Jun 2017, at 09:47, Andy Yan <andy.yan at 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
>>
>>
>
>
>
More information about the U-Boot
mailing list