[U-Boot] [PATCH 1/2] arm: use $loadaddr as the standalone entry point

[Max Krummenacher <max.oss.09@gmail.com>]

Hello all

Am Dienstag, den 15.08.2017, 07:39 -0400 schrieb Tom Rini:
> On Tue, Aug 15, 2017 at 09:32:30AM +0200, Wolfgang Denk wrote:
> > 
> > Dear Tom,
> > 
> > In message <20170814211300.GM20467@bill-the-cat> you wrote:
> > > 
> > > 
> > > But we're talking about CONFIG_STANDALONE_LOAD_ADDR not
> > > CONFIG_STANDALONE_ENTRY_POINT.  What we've been doing in
> > > arch/arm/config.mk has been on my to fix list for a long time, because
> > > it's been wrong for so many boards.  Setting this to CONFIG_LOADADDR is
> > > a reasonable default value.
> > 
> > No, it is not.  It is fundamentally broken. If you need a default
> > for the entry point address, then define one.  CONFIG_LOADADDR means
> > where the image gets loaded to, and almost all image formats have a
> > header in front of the payuload, so the entry point is somewhere
> > else.  And even if you load raw binary images, there is no guarantee
> > that the entry point is right at the start of the image,
> > 
> > Mixing things that are defined for different purposes (loading image
> > versus start address of the code) is a really bad idea.
> 
> What CONFIG_STANDALONE_LOAD_ADDR is, is the location that we want
> hello_world, or other example stand alone applications loaded into
> memory at.  CONFIG_LOADADDR is the safe default location to load things
> into memory at in order to run them.  At least on ARM, where there's a
> good number of different default memory layouts, what arch/arm/config.mk
> does today is broken for the majority of platforms.  We should be
> providing at least a functional default value here, which we are not
> today.  This in no way precludes a 'real' standalone application from
> linking and running at whatever it wants within a platforms memory map.

Wolfgang says that a board needs to decide on what image type to
use for the standalone application and then from that set an
appropriate CONFIG_STANDALONE_LOAD_ADDR in its board configuration.
Without that the standalone binaries are useless anyway and setting
a default in arch/arm/config.mk only purpose is that the build succeeds.

My motivation to write the patch in the first place (and Tom seems to
agree) is that for boards who define nothing at least the plain binary
is linked to a memory address where one can load something.

I can live with both views.

Note that I sent a v2 of the patchset addressing Wolfgang's first
emails. v2 hopefully dropped the wrong connection of load/link
address with entry point.

Max

>