Hi Wolfgang Denk,
Thanks for the response. Please find my questions inline.
On Thu, Mar 3, 2011 at 11:11 PM, Wolfgang Denk wd@denx.de wrote:
Dear Pandurang Kale,
In message AANLkTikLJzuCSwOhMLz2sWy1j9a3LiV8zzY6=TjTfnrR@mail.gmail.com you wrote:
But when primary bootloader copies the uboot image to the RAM and passes
the
control to the uboot, uboot (MIPS version of start.S and arch/mips/lib/borad.c) tries to relocate the already copied image from RAM (the primary bootloader copied it to start
of
the RAM+1MB address) to top of the RAM (0x87fc0000) region thinking that
the
uboot image is stored in flash.
U-Boot does not "think" it is stored in flash - this is what you configured. If you know you're always loading it to a fixed RAM address, you can use this as reference for TEXT_BASE instead
For MIPS I do not find the TEXT_BASE symbol, there is SYS_CFG_MONITOR_BASE which it uses to relocate the code from the define symbol to high RAM address. how can I avoid this? As I see we have a switch defined for ARM, CONFIG_SKIP_RELOCATE_UBOOT, to skip the code relocation I cant find a similar instance in MIPS code. Can you please throw some light on getting the TEXT_BASE setting correctly for MIPS code? how can I do that?
.
All I need to do is skip the uboot relocate code in MIPS version of uboot
No, you do NOT want to do thjat, as it would cripple U-Boot and remove basic functionality from it.
I can see there is a switch for ARM processor,
CONFIG_SKIP_RELOCATE_UBOOT,
Are you looking at recent code and working boards?
I have recent uboot code for MIPS and I cant find any similar switch for MIPS codebase. arch/mips/lib/board.c and arch/mips/cpu/start.S
I would really appreciate if you can guide me to overcome this issue to
run
the uboot cleanly skipping the relocation.
Do do not want to skip relocation. U-Boot may need to auto-adjust it's start address dynamically, depending on configuration, system requirements and/or environment settings.
The uboot is already loaded in the RAM (by the primary boot loader) so I dont want uboot to again relocate itself from one location of RAM to its predefined high-memory region in RAM which I have explained in my first mail.
Best regards,
Wolfgang Denk
Thanks a lot,
Pandu
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de If God wanted me to touch my toes, he'd have put them on my knees.