
Hi Wolfgang Denk,
Thanks a lot for all the clarification and help. I really appreciate your support.
I have few question with reards to the start.S file for MIPS. What is the significance of CONFIG_SYS_MONITOR_BASE ?? why is this used as the base/source address in relocate_code in mips start.S file while for ARM we use the _start as base/source address?
secondly for ARM we compare the source and destination address and skip the copy_loop(in ARM specific start.S file) if both are same, while this has not been implemented for MIPS.
I had to make similar changes in the start.S file (MIPS version) to skip the copying section.
Thanks, Pandu.
P.S: I am aware that you are out till 14th but I thought of posting it as these are valid arguments.
On Fri, Mar 4, 2011 at 6:23 AM, Wolfgang Denk wd@denx.de wrote:
Dear Pandurang Kale,
In message AANLkTinTqxJPU9Gwye_8pT2PcUxR8E36=zm78ypc1740@mail.gmail.com you wrote:
For MIPS I do not find the TEXT_BASE symbol, there is
SYS_CFG_MONITOR_BASE
Please check again. MIPS uses CONFIG_SYS_TEXT_BASE like all other architectures.
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,
You should not try to avoid this. It is a useful feature, even if you load U-Boot to RAM separately.
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?
You did not understand what I wrote:
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 meant: do you see CONFIG_SKIP_RELOCATE_UBOOT in recent ARM code, on working (compilable) ARM boards?
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.
Please re-read what I wrote. In general, U-Boot's load address cannot be determined at compile time, at least not without crippeling it from some interesting features. You should really not try doing things differently to everybody else. We had similar discussins not so long ago for AMR, so please just re-read this in the archives.
Best regards,
Wolfgang Denk
-- 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