From mboxrd@z Thu Jan 1 00:00:00 1970 From: Detlev Zundel Date: Mon, 18 Jan 2010 11:44:23 +0100 Subject: [U-Boot] [PATCH] PPC: Record uboot's relocated address in RAM and show in bdinfo. In-Reply-To: <4B509E5E.8090002@RuggedCom.com> (Richard Retanubun's message of "Fri, 15 Jan 2010 11:57:02 -0500") References: <4B508900.70400@RuggedCom.com> <4B509E5E.8090002@RuggedCom.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Richard, > Detlev Zundel wrote: > >> >> Please excuse my ignorance, but why not simply remove the #ifdef >> CONFIG_AMIGAONEG3SE in board_init_f? Actually I was hoping to remove >> the Amigaone special case. >> >> Cheers >> Detlev >> > I prefer getting the data from board_init_r because we really are > running from RAM at that point; dest_addr is a passed in function > param. I see, thanks for the explanation. > In board_init_f, the addr variable is just what the calculated address > is. If we must do the copy there I'd like to move the gd->relocaddr = > addr to just before the call to relocate_code, that way if the > calculation code got reworked/refactored, we always copy the correct > addr variable. Yes, I also agree - if we want to have it in _f, we should move the assignment. > Plus the line: debug ("Now running in RAM - U-Boot at: %08lx\n", dest_addr); in board_init_r > > Is the de-facto place where documentations that I've seen refer to for > figuring out where u-boot is relocated, so making the assignment there > makes it clearer. > > All these leads to my preference of getting it from board_init_r. Actually I do not have a strong preference myself. The only thing I could think of is that an earlier assignment discloses the information also when debugging problems in relocation. On the other hand if you _do_ debug the relocation it is unlikely that you need the variable, so this argument does not tip the scale in any direction. > I'll be happy to submit a V2 that takes out the CONFIG_AMIGAONEG3SE > copy operation in board_init_f as well, but I can't confirm if that > does not break the AMIGAONE board. Yes, please send such a follow-on patch. Not being able to test a change is rather the norm in U-Boot, so it is acceptable to simply CC the relevant maintainer ("Thomas Frieden ") and if no NACK is seen include the changes anyway at some point. Thanks Detlev -- It's like manually inflatable airbags -- people will never think to use it in time to actually get any help from it. -- Miles Bader in <20030607122005.GA1086@gnu.org> -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de