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....@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() ? > >>> > >> 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. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
