[U-Boot-Users] Function pointers after relocation
Greetings
When u-boot has relocated from Flash to RAM, it is correct that function pointers (eg. getenv()) still point to the Flash code rather than the RAM copy? Would this be corrected by changing the link address, in which case where do I find it (the link address that is) - in the .lds file?
board = mpc866ads (fads alike) cpu = mpc866 (mpc860 alike) all changes based on ads860+fads merge!!
Hello,
in message 3F0267CB.8040904@tait.co.nz you wrote:
When u-boot has relocated from Flash to RAM, it is correct that function pointers (eg. getenv()) still point to the Flash code rather than the RAM copy? Would this be corrected by changing the link address, in which case where do I find it (the link address that is) - in the .lds file?
This is not correct. The problem is that staticlly initialized data (like initialized function pointers() must be manually relocated. If there is such a thing left pointing to flash, it is a bug and should be fixed.
Which part of the code are you speaking of?
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
This is not correct. The problem is that staticlly initialized data (like initialized function pointers() must be manually relocated. If there is such a thing left pointing to flash, it is a bug and should be fixed.
Which part of the code are you speaking of?
Opps - a typo in the example!! I meant to say the pointer env_get_char() which is initialised to env_get_char_init and remains pointing at the Flash copy of that function after relocation.
As it happens I think we have another problem in getting to our environment since the gd->env_ptr value seems to be garbage!! I don't see that running the code from Flash should in itself be a real problem (although undesirable).
More info later if it's relevent...
Is this at all related to this problem:
http://sourceforge.net/mailarchive/message.php?msg_id=5376039
i.e. env not being copied from flash in relocate() when ENV_IS_EMBEDDED is set?
On Thu, Jul 03, 2003 at 10:01:46AM +1200, Robin Gilks wrote:
Wolfgang Denk wrote:
This is not correct. The problem is that staticlly initialized data (like initialized function pointers() must be manually relocated. If there is such a thing left pointing to flash, it is a bug and should be fixed.
Which part of the code are you speaking of?
Opps - a typo in the example!! I meant to say the pointer env_get_char() which is initialised to env_get_char_init and remains pointing at the Flash copy of that function after relocation.
As it happens I think we have another problem in getting to our environment since the gd->env_ptr value seems to be garbage!! I don't see that running the code from Flash should in itself be a real problem (although undesirable).
More info later if it's relevent...
-- Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks@tait.co.nz New Zealand
This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Nye Liu wrote:
Is this at all related to this problem:
http://sourceforge.net/mailarchive/message.php?msg_id=5376039
i.e. env not being copied from flash in relocate() when ENV_IS_EMBEDDED is set?
The effect is the same but the setting of ENV_IS_EMBEDDED is neither here nor there as I'm starting from a configuration file for the FADS board. This has only 8 sectors of 256k each so it makes no sense to embed the environment (wastes too much space) - the problem as you say is that it never gets copied out of Flash into RAM !!
I'm going to 'have a go' at cpu/mpc8xx/start.S to modify it for the FADS case but since I've never used ppc assembler before it may take a while!!
I think if I can identify where I get the source (presumably GOT(environment)) and destination (not found this yet) addresses and the length of the environment (I'll use the config define) at the assembler level then I'll be able to hack something together!!
Never will so few lines of code have taken so long to write :-))
Nye Liu wrote:
Is this at all related to this problem:
http://sourceforge.net/mailarchive/message.php?msg_id=5376039
i.e. env not being copied from flash in relocate() when ENV_IS_EMBEDDED is set?
Turned out that it was CFG_MONITOR_LEN which was defined as being too large so the pre-processor stuff in include/environment.h was setting ENV_IS_EMBEDDED when it shouldn't.
Sorted that, quick tweak to remove un-necessary GOT(environment) from start.S (since its not in the image it won't be in the GOT table!!) and it all works :-))
This is identical to my 8xx problem.
Wolfgang, still not convinced those GOT(environment) need #ifdef ENV_IS_EMBEDDED?
On Wed, Jul 09, 2003 at 04:46:11PM +1200, Robin Gilks wrote:
Nye Liu wrote:
Is this at all related to this problem:
http://sourceforge.net/mailarchive/message.php?msg_id=5376039
i.e. env not being copied from flash in relocate() when ENV_IS_EMBEDDED is set?
Turned out that it was CFG_MONITOR_LEN which was defined as being too large so the pre-processor stuff in include/environment.h was setting ENV_IS_EMBEDDED when it shouldn't.
Sorted that, quick tweak to remove un-necessary GOT(environment) from start.S (since its not in the image it won't be in the GOT table!!) and it all works :-))
-- Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks@tait.co.nz New Zealand
In message 20030709161534.GA4022@orca.internal.zumanetworks.com you wrote:
This is identical to my 8xx problem.
Wolfgang, still not convinced those GOT(environment) need #ifdef ENV_IS_EMBEDDED?
Ummm... yes. But I'd like to have a board in the lab where I can verify that the modfication works / does not break anything. But I'm too busy to do anything about this right now.
Please keep reminding me from time to time ;-)
Best regards,
Wolfgang Denk
Hi!
This is me reminding you that the top of the tree still does not restore the environment on most 8xx boards...
Please revisit this. This is your monthly reminder!
On Wed, Jul 09, 2003 at 06:37:22PM +0200, Wolfgang Denk wrote:
In message 20030709161534.GA4022@orca.internal.zumanetworks.com you wrote:
This is identical to my 8xx problem.
Wolfgang, still not convinced those GOT(environment) need #ifdef ENV_IS_EMBEDDED?
Ummm... yes. But I'd like to have a board in the lab where I can verify that the modfication works / does not break anything. But I'm too busy to do anything about this right now.
Please keep reminding me from time to time ;-)
:)
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de Behind every great man, there is a woman -- urging him on. -- Harry Mudd, "I, Mudd", stardate 4513.3
In message 20030802001858.GA23651@zumanetworks.com you wrote:
This is me reminding you that the top of the tree still does not restore the environment on most 8xx boards...
I don't think your claim of "most 8xx boards" is valid. All boards I was able to test (because I had access to the hardware) are OK. The only board with (potential) problems I am aware of is the ICU862.
Or am I wrong?
Please revisit this. This is your monthly reminder!
Thanks.
Best regards,
Wolfgang Denk
Sorry, yes, it affects FADS and ICU86x, I have 5 different boards now, all are similar to the fads, which is why it feels like "most 8xx" to me.
apologies for the hyperbole.
On Sat, Aug 02, 2003 at 11:37:08AM +0200, Wolfgang Denk wrote:
In message 20030802001858.GA23651@zumanetworks.com you wrote:
This is me reminding you that the top of the tree still does not restore the environment on most 8xx boards...
I don't think your claim of "most 8xx boards" is valid. All boards I was able to test (because I had access to the hardware) are OK. The only board with (potential) problems I am aware of is the ICU862.
Or am I wrong?
Please revisit this. This is your monthly reminder!
Thanks.
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de Put your Nose to the Grindstone! -- Amalgamated Plastic Surgeons and Toolmakers, Ltd.
In message 20030803082459.GA27299@orca.internal.zumanetworks.com you wrote:
Sorry, yes, it affects FADS and ICU86x, I have 5 different boards now, all are similar to the fads, which is why it feels like "most 8xx" to me.
Well, can you please submit a patch that works for your boards? I will try to setup a ICU862 board ASAP to verify that it works there, too.
apologies for the hyperbole.
A little nudging here and there is perfectly OK with me :-)
Best regards,
Wolfgang Denk
nyet@mrv.com wrote:
Sorry, yes, it affects FADS and ICU86x, I have 5 different boards now, all are similar to the fads, which is why it feels like "most 8xx" to me.
apologies for the hyperbole.
The changes I made to cpu/mpc8xx/start.S sorted this out for us (as supplied a couple of weeks ago to this list) - I've not been able to work out why FADS and ICU862 are treated as a special case. Simply putting the environment after the code such that its *NOT* embedded and removing the special case in the GOT table works OK - maybe its coincidence :-))
Dear Robin,
in message 3F03564A.4090807@tait.co.nz you wrote:
Which part of the code are you speaking of?
Opps - a typo in the example!! I meant to say the pointer env_get_char() which is initialised to env_get_char_init and remains pointing at the Flash copy of that function after relocation.
I cannot verify this problem. It works fine for me (i. e. env_get_char() will be relocated correctly to point to the in-RAM copy of the function).
Best regards,
Wolfgang Denk
Hi Wolfgang
Wolfgang Denk wrote:
Dear Robin,
in message 3F03564A.4090807@tait.co.nz you wrote:
Which part of the code are you speaking of?
Opps - a typo in the example!! I meant to say the pointer env_get_char() which is initialised to env_get_char_init and remains pointing at the Flash copy of that function after relocation.
I cannot verify this problem. It works fine for me (i. e. env_get_char() will be relocated correctly to point to the in-RAM copy of the function).
Yup - you're quite right :-))
This was a symptom of our incorrect config where CONFIG_MONITOR_LEN was incorrectly defined making the code think the environment was embedded when it wasn't. Our debugging logic was suffering a Friday afternoon (or maybe it was a blond) moment...
I hope to release the MPC866ADS board updates to you this week - just cleaning up the diffs against the latest CVS now.
participants (4)
-
Nye Liu -
nyet＠mrv.com
-
Robin Gilks -
Wolfgang Denk