Avoiding reload on ARM U-BOOT
Hello everyone
im trying to port u-boot 2011-09 to a new board with an arm based SOC
i found that u-boot will always relocate the code even if it is placed already in DDR which is the case with my SOC.
is there any clean way to avoid relocating the u-boot ? does the various SPL configs have something to do with that ?
if yes which one should i define ?
Thanks in advance
Yehuda
Signature · 2 lines
View this message in context: http://old.nabble.com/Avoiding-reload-on-ARM-U-BOOT-tp33250726p33250726.html Sent from the Uboot - Users mailing list archive at Nabble.com.
Quoted 6 lines
Hello everyone
im trying to port u-boot 2011-09 to a new board with an arm based SOC
i found that u-boot will always relocate the code even if it is placed already in DDR which is the case with my SOC.
The u-boot is always relocated to the end of the DRAM, which is likely what you want. And it's quite a quick process. So if you are manufacturing your soc with various size of RAM, you want the relocation to happen. What SoC is that anyway?
Quoted 3 lines
is there any clean way to avoid relocating the u-boot ? does the various SPL configs have something to do with that ?
Not really and you don't want this to happen.
M
Quoted 6 lines
if yes which one should i define ?
Thanks in advance
Yehuda
A message that is not in the archive (sent off-list or not yet received): CAN2=dsw9rAkzKftow5Opo5vpXFiUz90i7941+WfViwN_BwqAkA@mail.gmail.com
Quoted 1 line
Hello Marek
ALWAYS CC U-BOOT ML
Quoted 6 lines
Thank you for your answer
My SOC (Marvells Armada Controller) uses a bootrom code to copy to initialize the DRAM and to copy the u-boot image. so the entire DRAM init and copy sequence in u-boot is redundant.
I see. I know about this soc's bootrom. Though it still can't place the bootloader properly to the end of DRAM.
Quoted 5 lines
in previous version there was a way to avoid this. i find it limiting that there isn't a way in the new version.
Why would i want to relocate the code anyway ?
See above, to place it to the end of DRAM.
Quoted 30 lines
Yehuda
Quoted 26 lines · Marek Vasut
Quoted 6 lines
Hello everyone
im trying to port u-boot 2011-09 to a new board with an arm based SOC
i found that u-boot will always relocate the code even if it is placed already in DDR which is the case with my SOC.
The u-boot is always relocated to the end of the DRAM, which is likely what you
want. And it's quite a quick process. So if you are manufacturing your soc with
various size of RAM, you want the relocation to happen. What SoC is that anyway?Quoted 2 lines
is there any clean way to avoid relocating the u-boot ? does the various SPL configs have something to do with that ?
Not really and you don't want this to happen.
M
Quoted 5 lines
if yes which one should i define ?
Thanks in advance
Yehuda
Hello again
Sorry for slipping the u-boot list e-mail address
i understand the benefit of relocating u-boot to the end of DRAM but in systems where boot time is critical this redundant copy is undesirable. anyway i understand there is no official way of avoiding it.
One more question i have is regarding the SPL Framework. i read all the documentation i could find about the SPL but i don't think i fully understand the usage of this framework. since i noticed several SPL Macros around the relocation code i suspected it has something to do with relocation or u-boot running as secondary boot program
i would appreciate a short explanation when CONFIG_SPL or CONFIG_NAND_SPL should be set ?
Thanks again
Yehuda
Quoted 57 lines · Marek Vasut
Quoted 1 line
Hello Marek
ALWAYS CC U-BOOT ML
Quoted 6 lines
Thank you for your answer
My SOC (Marvells Armada Controller) uses a bootrom code to copy to initialize the DRAM and to copy the u-boot image. so the entire DRAM init and copy sequence in u-boot is redundant.
I see. I know about this soc's bootrom. Though it still can't place the bootloader properly to the end of DRAM.
Quoted 2 lines
in previous version there was a way to avoid this. i find it limiting
that
Quoted 3 lines
there isn't a way in the new version.
Why would i want to relocate the code anyway ?
See above, to place it to the end of DRAM.
Quoted 4 lines
Yehuda
On Thu, Feb 2, 2012 at 11:34 AM, Marek Vasut <[email protected]>
Quoted 5 lines · wrote:
Quoted 5 lines
Quoted 5 lines
Hello everyone
im trying to port u-boot 2011-09 to a new board with an arm based SOC
i found that u-boot will always relocate the code even if it is
placed
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
already in DDR which is the case with my SOC.
The u-boot is always relocated to the end of the DRAM, which is likely what you
want. And it's quite a quick process. So if you are manufacturing your soc with
various size of RAM, you want the relocation to happen. What SoC isthat
Quoted 14 lines
Quoted 14 lines
anyway?
Quoted 2 lines
is there any clean way to avoid relocating the u-boot ? does the various SPL configs have something to do with that ?
Not really and you don't want this to happen.
M
Quoted 5 lines
if yes which one should i define ?
Thanks in advance
Yehuda
Quoted 7 lines
Hello again
Sorry for slipping the u-boot list e-mail address
i understand the benefit of relocating u-boot to the end of DRAM but in systems where boot time is critical this redundant copy is undesirable. anyway i understand there is no official way of avoiding it.
You can boot linux directly via SPL if your boottime is critical. And, if you do not want to boot linux directly, implement some "hit key to interrupt direct booting sequence" into SPL.
Quoted 6 lines
One more question i have is regarding the SPL Framework. i read all the documentation i could find about the SPL but i don't think i fully understand the usage of this framework. since i noticed several SPL Macros around the relocation code i suspected it has something to do with relocation or u-boot running as secondary boot program
If you can read only a small piece of eg. NAND with your bootrom, you use SPL. The purpose is to init the system (ram, gpio ...) and load the u-boot (the big bootloader).
M
Quoted 70 lines
i would appreciate a short explanation when
CONFIG_SPLorCONFIG_NAND_SPLshould be set ?Thanks again
Yehuda
Quoted 61 lines · Marek Vasut
Quoted 1 line
Hello Marek
ALWAYS CC U-BOOT ML
Quoted 5 lines
Thank you for your answer
My SOC (Marvells Armada Controller) uses a bootrom code to copy to initialize the DRAM and to copy the u-boot image. so the entire DRAM init and copy sequence in u-boot is redundant.
I see. I know about this soc's bootrom. Though it still can't place the bootloader properly to the end of DRAM.
Quoted 1 line
in previous version there was a way to avoid this. i find it limiting
that
Quoted 3 lines
there isn't a way in the new version.
Why would i want to relocate the code anyway ?
See above, to place it to the end of DRAM.
Quoted 3 lines
Yehuda
On Thu, Feb 2, 2012 at 11:34 AM, Marek Vasut <[email protected]>
Quoted 6 lines · wrote:
Quoted 6 lines
Quoted 6 lines
Hello everyone
im trying to port u-boot 2011-09 to a new board with an arm based SOC
i found that u-boot will always relocate the code even if it is
placed
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
already in DDR which is the case with my SOC.
The u-boot is always relocated to the end of the DRAM, which is likely what you
want. And it's quite a quick process. So if you are manufacturing your soc with
various size of RAM, you want the relocation to happen. What SoC isthat
Quoted 14 lines
Quoted 14 lines
anyway?
Quoted 2 lines
is there any clean way to avoid relocating the u-boot ? does the various SPL configs have something to do with that ?
Not really and you don't want this to happen.
M
Quoted 5 lines
if yes which one should i define ?
Thanks in advance
Yehuda
Quoted 9 lines · Marek Vasut
Quoted 7 lines
Hello again
Sorry for slipping the u-boot list e-mail address
i understand the benefit of relocating u-boot to the end of DRAM but in systems where boot time is critical this redundant copy is undesirable. anyway i understand there is no official way of avoiding it.
You can boot linux directly via SPL if your boottime is critical.
To this purpose I have posted the final version of the patchset to boot Linux directly from SPL - maybe you can try this way on your hardware.
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de =====================================================================