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

[Tom Rini]

On Tue, Aug 15, 2017 at 03:21:15PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20170815113952.GE20467 at bill-the-cat> you wrote:
> > 
> > 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.
> 
> I agree up to here.
> 
> > 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.
> 
> This is where things become fishy.
> 
> We should use clean terms.

OK.

> Please keep in mind that even the term "load address" can mean two
> things: many people use this term (incorrectly) for the address where
> they load an image to on RAM, and unfortunately we even provide the
> "loadaddr" environment variable which carries this meaning.

We'll use this for now at least, for consistency.

> Originally, the term refers to the address where the image payload gets
> uncompressed and loaded to when unpacking the image.  For example,
> on Power architecture, a typical setup would look like:
> 
> Output of mkimage -l:
> 
> 	Image Name:   Linux-4.4.8
> 	Created:      Fri Apr 22 09:06:09 2016
> 	Image Type:   PowerPC Linux Kernel Image (gzip compressed)
> 	Data Size:    2009139 Bytes = 1962.05 kB = 1.92 MB
> 	Load Address: 00000000
> 	Entry Point:  00000000
> 
> We download the uImage file to - say - 0x400000 in RAM (so the
> environment variable "loadaddr" might be 0x400000),  but when we run
> "bootm", U-Boot will uncompress and _load_ the Linux kernel to the
> _Load_Address_ stored in the image header, i. e. 0x00000000, and then
> it will transfer control to the _Entry_Point_Address_, also stored
> in the image header, here also 0x00000000.
> 
> So we have:
> 
> download address (address of image in RAM):	0x00400000
> load address (start of unpacked kernel image):	0x00000000
> entry point (start of executable code):		0x00000000
> 
> 
> The term "load address" has always been meant to mean the address
> where the kernel gets _loaded_to_ by the bootm command.  I know that
> there has always been confusion of these terms, and I must have
> explained this at least a hundred times here before.

This is all true.  But it's also unrelated to what
CONFIG_STANDALONE_LOAD_ADDR is used for.  So...

> I would really appreciate if you helped to avoid mixing terms of
> different meaning.  If you have an idea how to avoid this it would
> be more than welcome - unfortunately the (mis)use of the loadaddr
> environment variable is so widespread that I feat there is no easy
> way out.

I think the first problem is that we need to rename
CONFIG_STANDALONE_LOAD_ADDR to CONFIG_EXAMPLE_STANDALONE_ENTRY_POINT to
be more precise about what it is doing and used for, all around.  And
then, I'm not sure.  I had an idea, but I seem to have found that at
least right this moment, hello_world.bin doesn't function for me and I
would swear I had unit tested be1b8679ce42 but it is not working for me
either.  But I'm going to put this down for the evening at least...

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170818/a2c65284/attachment.sig>