[U-Boot] [PATCH 0/5] fix the boot issue of Rockchip RK3036

[Heiko Stübner]

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 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.

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