[U-Boot-Users] Function pointers after relocation

[U-Boot-Users] Function pointers after relocation

[Robin Gilks]

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!!


-- 
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

[U-Boot-Users] Function pointers after relocation

[Wolfgang Denk]

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

-- 
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."

[U-Boot-Users] Function pointers after relocation

[Robin Gilks]

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 at tait.co.nz
New Zealand

[U-Boot-Users] Function pointers after relocation

[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() 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 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

-- 
Nye Liu
nliu at mrv.com
(818) 772-6235x248

"Who would be stupid enough to quote a fictitious character?"
	-- Don Quixote

[U-Boot-Users] Function pointers after relocation

[Robin Gilks]

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 :-))


-- 
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

[U-Boot-Users] Function pointers after relocation

[Robin Gilks]

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 at tait.co.nz
New Zealand

[U-Boot-Users] Function pointers after relocation

[nyet at mrv.com]

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 at tait.co.nz
> New Zealand

[U-Boot-Users] Function pointers after relocation

[Wolfgang Denk]

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 at denx.de
Behind every great man, there is a woman -- urging him on.
	-- Harry Mudd, "I, Mudd", stardate 4513.3

[U-Boot-Users] Function pointers after relocation

[Wolfgang Denk]

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

-- 
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

[U-Boot-Users] Function pointers after relocation

[Robin Gilks]

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.

-- 
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

[U-Boot-Users] Function pointers after relocation

[Nye Liu]

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 at denx.de
> Behind every great man, there is a woman -- urging him on.
> 	-- Harry Mudd, "I, Mudd", stardate 4513.3

-- 
Nye Liu
nliu at mrv.com
(818) 772-6235x248

"Who would be stupid enough to quote a fictitious character?"
	-- Don Quixote

[U-Boot-Users] Function pointers after relocation

[Wolfgang Denk]

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 at denx.de
Put your Nose to the Grindstone!
                 -- Amalgamated Plastic Surgeons and Toolmakers, Ltd.

[U-Boot-Users] Function pointers after relocation

[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.

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 at denx.de
> Put your Nose to the Grindstone!
>                  -- Amalgamated Plastic Surgeons and Toolmakers, Ltd.

[U-Boot-Users] Function pointers after relocation

[Wolfgang Denk]

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

-- 
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."

[U-Boot-Users] Function pointers after relocation

[Robin Gilks]

nyet at 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 :-))


-- 
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