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

[Nishanth Menon]

Sergiy Kibrik wrote, on 11/05/2010 10:44 AM:
> 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.
lets drop this change for the timebeing then.

>>>>>       -tweaked blob load address to avoid image relocation (according to
>>>>> default uImage load address);
>>>>>
>>>>> Signed-off-by: Sergiy Kibrik<sergiy.kibrik at 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?
aaah, it would be good to fix up $subject to reflect this. "speed up 
booting" can mean anything.

>>>>> ---
>>>>>     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.
>
interesting. thanks for the explanation.

>>>>
>>>>>     #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.
actually there are blokes who use it that way as well. for e.g., in the 
old days of using BuildRoot inside TI, it just did the mkimage outside 
instead of just doing make uImage.

> Can you suggest a way to coordinate load addresses across kernel&  bootloader build?
>
Hmm.. good point -> need to try an idea I am thinking at the moment - 
this info is present in the memory already -> just need to think how to 
drag it out
-- 
Regards,
Nishanth Menon