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

[Andy Yan]

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