Hey Wolfgang,
Hmm, I think I might not have made my point clear enough ... my
apologies! Either that or I have a fundamental misunderstanding of the
issue (more likely).
No. See the FAQ entry. The entry point address really depends on te
code. If you add code, it can be basically anywehre - there may other
functions preceed the entry point, etc.
I had a look at this FAQ entry, and I think it's addressing a different
point than the issue I'm seeing here. This part of the FAQ tells the
user that the load point of their standalone function may differ due to
the particular linker or link map they're using. This is totally fine
and I understand that this is subject to change, and naturally if you're
attempting to run a standalone application from an address other than
its base address defined at link time, then the application won't
execute correctly.
In my situation, I specifically told my linker to set my example
application's start address to to be the same as the hello_world example
(0x40000). Presumably the same problems would have occurred regardless
of where I loaded it due to the fact that I was beginning execution four
bytes into the code, thus skipping the first instruction (as outlined in
the examples).
Of course, I understand that the situation becomes very different when
alternative compilers and linkers are thrown into the mix.
I'd be very interested to know which incidents in the past had caused
the standalone examples to fail to execute correctly from their base
address yet work correctly from a 4 byte offset, because as a relative
newcomer to development at this level of abstraction, this threw me a
massive red herring until I realised that actually, for my example, the
first instruction is -crucial- (stack frame allocation), and I can't
work out in my head how the example actually works correctly when loaded
at a 4 byte offset.
Thanks!
Dave George
Stay informed by joining the Rapita Systems mailing list
http://www.rapitasystems.com/contact/mailing_list
For real-time verifications issues and discussion, follow the Rapita Systems
blog
http://www.rapitasystems.com/blog
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
