Hi Richard,
Detlev Zundel wrote:
<snip> > > 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 ThomasF@hyperion-entertainment.com") and if no NACK is seen include the changes anyway at some point.
Thanks Detlev