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!!
Signature · 5 lines
Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks at tait.co.nz New Zealand
Hello,
Quoted 5 lines · in message <[email protected]> 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
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de "Have you lived in this village all your life?" "No, not yet."
Quoted 7 lines · Wolfgang Denk
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...
Signature · 5 lines
Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks at tait.co.nz New Zealand
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?
Quoted 39 lines · Robin Gilks
Quoted 7 lines · Wolfgang Denk
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 toenv_get_char_initand 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_ptrvalue 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...
Signature · 17 lines
Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks at 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 at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Signature · 6 lines
Nye Liu nliu at mrv.com (818) 772-6235x248 "Who would be stupid enough to quote a fictitious character?" -- Don Quixote
Quoted 7 lines · Nye Liu
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()whenENV_IS_EMBEDDEDis 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 :-))
Signature · 5 lines
Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks at tait.co.nz New Zealand
Quoted 7 lines · Nye Liu
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()whenENV_IS_EMBEDDEDis 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 :-))
Signature · 5 lines
Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks at tait.co.nz New Zealand
This is identical to my 8xx problem.
Wolfgang, still not convinced those GOT(environment) need #ifdef ENV_IS_EMBEDDED?
Quoted 24 lines · Robin Gilks
Quoted 7 lines · Nye Liu
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()whenENV_IS_EMBEDDEDis set?Turned out that it was
CFG_MONITOR_LENwhich was defined as being too large so the pre-processor stuff ininclude/environment.hwas settingENV_IS_EMBEDDEDwhen 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 :-))Signature · 5 lines
Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks at tait.co.nz New Zealand
Quoted 4 lines · In message <[email protected]> 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
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Behind every great man, there is a woman -- urging him on. -- Harry Mudd, "I, Mudd", stardate 4513.3
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!
Quoted 11 lines · Wolfgang Denk
Quoted 4 lines · In message <[email protected]> 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 ;-)
:)
Quoted 9 lines
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Behind every great man, there is a woman -- urging him on. -- Harry Mudd, "I, Mudd", stardate 4513.3
Signature · 6 lines
Nye Liu nliu at mrv.com (818) 772-6235x248 "Who would be stupid enough to quote a fictitious character?" -- Don Quixote
Quoted 3 lines · In message <[email protected]> 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?
Quoted 1 line
Please revisit this. This is your monthly reminder!
Thanks.
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Put your Nose to the Grindstone!
-- Amalgamated Plastic Surgeons and Toolmakers, Ltd.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.
Quoted 24 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> 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?
Quoted 1 line
Please revisit this. This is your monthly reminder!
Thanks.
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Put your Nose to the Grindstone! -- Amalgamated Plastic Surgeons and Toolmakers, Ltd.
Quoted 3 lines · In message <[email protected]> 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.
Quoted 1 line
apologies for the hyperbole.
A little nudging here and there is perfectly OK with me :-)
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Quote from a recent meeting: "We are going to continue having these meetings everyday until I find out why no work is getting done."
Quoted 6 lines · nyet at mrv.com
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 :-))
Signature · 5 lines
Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks at tait.co.nz New Zealand
Dear Robin,
Quoted 6 lines · in message <[email protected]> you wrote:
Quoted 2 lines
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 toenv_get_char_initand 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
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Vulcans worship peace above all. -- McCoy, "Return to Tomorrow", stardate 4768.3
Hi Wolfgang
Quoted 6 lines · Wolfgang Denk
Dear Robin,
Quoted 2 lines · in message <[email protected]> you wrote:
Quoted 1 line
Which part of the code are you speaking of?
Quoted 9 lines
Quoted 3 lines
Opps - a typo in the example!! I meant to say the pointer
env_get_char()which is initialised toenv_get_char_initand 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.
Signature · 5 lines
Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks at tait.co.nz New Zealand