Hi Philipp:
On 2017年06月30日 16:14, Dr. Philipp Tomsich wrote:
Andy,
On 30 Jun 2017, at 09:47, Andy Yan <andy....@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
