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.kib...@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? _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot