[U-Boot] [PATCH] OMAP4: speed up booting on Pandaboard

[Sergiy Kibrik <sergiy.kibrik@globallogic.com>]

On 11/05/2010 03:12 PM, Nishanth Menon wrote:
> Sergiy Kibrik wrote, on 11/05/2010 08:35 AM:
>> On 11/04/2010 05:46 PM, Nishanth Menon wrote:
>>> Sergiy Kibrik wrote, on 11/04/2010 05:38 AM:
>>>> Improved default config for OMAP4 Pandaboard for faster boot:
>>>>      -reduced environment size to speed up memory initialization;
>>>>      -USB TTY driver turned off;
>>> Do we really want to do this?
>>
>> well, Pandaboard has serial port. It can be used instead of usbtty
> how about all those folks who dont have a serial cable handy instead
> would like to power the board + see the terminal over usb?

you're right, it can be the reason not to touch usbtty now.

> 
>>
>>>>      -tweaked blob load address to avoid image relocation (according to
>>>> default uImage load address);
>>>>
>>>> Signed-off-by: Sergiy Kibrik<sergiy.kibrik@globallogic.com>
>>> What kind of savings did we get? I am guessing we have some time x
>>> savings..
>>>
>>
>> reducing ENV_SIZE saves ~0.2 s.
>> turning off usbtty saves ~0.2 s.
>> changing loadaddr saves about a second. As shown my measurements, all
>> introduced changes save
>> about 1.3 - 1.5 seconds.
> for what? getting to u-boot shell prompt? if so, I wonder how it does it
> actually happen.
> 

no, not getting shell, but jumping to kernel. But even in case of getting shell, why we have to wait 1 more second?

>>
>>>> ---
>>>>    include/configs/omap4_panda.h |    8 ++++----
>>>>    1 files changed, 4 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/include/configs/omap4_panda.h
>>>> b/include/configs/omap4_panda.h
>>>> index 74defab..5aba424 100644
>>>> --- a/include/configs/omap4_panda.h
>>>> +++ b/include/configs/omap4_panda.h
>>>> @@ -62,10 +62,10 @@
>>>>
>>>>    /*
>>>>     * Size of malloc() pool
>>>> - * Total Size Environment - 256k
>>>> + * Total Size Environment - 2k
>>>>     * Malloc - add 256k
>>>>     */
>>>> -#define CONFIG_ENV_SIZE            (256<<   10)
>>>> +#define CONFIG_ENV_SIZE            (256<<   4)
>>> /me likes the change, but not sure how it saves boot time.
>>
>> again, it's about 0.2 seconds
> 
> surprised how changing env saves 0.2 seconds - apologies, I dont have a
> panda on hand at the moment to do some actual tests with the board and
> patch :(

I guess it's because of memory initializaion issues in mem_malloc_init(), and because of 256k environment it takes longer to do memset.

> 
>>
>>>
>>>>    #define CONFIG_SYS_MALLOC_LEN        (CONFIG_ENV_SIZE + (256<<  
>>>> 10))
>>>>                            /* initial data */
>>>>    /* Vector Base */
>>>> @@ -117,7 +117,7 @@
>>>>
>>>>    /* USB device configuration */
>>>>    #define CONFIG_USB_DEVICE        1
>>>> -#define CONFIG_USB_TTY            1
>>>> +#undef CONFIG_USB_TTY
>>> do we need to have the undef? it might be better to just drop the define
>>> perhaps? what impact do we have on boot time with this change?
>>
>> if someone wants to turn usbtty again, he can simply #define variable
>> again,
>> in case we drop the whole line it may be slightly harder to find out
> proper
>> variable in the code and then #define it all over again. I just thought
>>keeping it will clarify config in some way.
> 
> adding a comment will help
> /* enable this to get tty over usb */

THX, I'l do that.

>>>
>>>>    #define CONFIG_SYS_CONSOLE_IS_IN_ENV    1
>>>>
>>>>    /* Flash */
>>>> @@ -146,7 +146,7 @@
>>>>    #define CONFIG_ENV_OVERWRITE
>>>>
>>>>    #define CONFIG_EXTRA_ENV_SETTINGS \
>>>> -    "loadaddr=0x82000000\0" \
>>>> +    "loadaddr=0x80007FC0\0" \
>>> btw, Dumb question: how did we decide on this address? building from
>>> kernel.org, I see System.map @ c0004000 ==>  80004000
>>>
>>> when I do make uImage,
>>> /bin/bash /home/nmenon/Src/opensource/linux-2.6/scripts/mkuboot.sh -A
>>> arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n
>>> 'Linux-2.6.37-rc1-00005-gd88c092'
>>>
>> 0x80007FC0 is kernel load address (0x80008000) minus size of u-boot
>> header (64 bytes). So load address is exactly the same as image
>> address inside loaded blob, and we avoid memmoving kernel to it's load
>> address.
> thanks for the clarification -> it might be good for us to come up with
> something a bit more automated as you can, in theory run mkuboot.sh with
> a different address.
> 

in theory yes, but practically it's just a default config for default uImage target.
Can you suggest a way to coordinate load addresses across kernel & bootloader build?