[U-Boot] [PATCH 0/2] improve hello_world standalone application for arm

[U-Boot] [PATCH 0/2] improve hello_world standalone application for arm

[Max Krummenacher]

This series addresses
- hardcoded entry address, use LOADADDR if available as the entry point instead
- fix thumb build, jumping with 'go' to the entry point expects arm code

Note that in addition to the two fixes I've seen random freezes
or 'random' printed stuff when using an early linaro gcc 6 compiler.
Adding an initialized variable helped in that case
static int dummy_var_in_text = 1;
I assume that this forces alignment of some linker sections.
(e.g. I see that __bss_start points to 0x1201027e, with the variable
this moves to 0x12010280)

However with the current linaro compilers this does not happen so I
don't propose a patch for this issue.
Linaro GCC 5.4-2017.05 5.4.1 20170404
Linaro GCC 6.3-2017.05 6.3.1 20170404
Linaro GCC 7.1-2017.05 7.1.1 20170510

This series is available at http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next


Max Krummenacher (2):
  arm: use $loadaddr as the standalone entry point
  hello_world.c: fix entry point in case of arm thumb binary

 arch/arm/config.mk                |  4 ++++
 doc/README.standalone             |  2 +-
 examples/standalone/hello_world.c | 15 +++++++++++++++
 3 files changed, 20 insertions(+), 1 deletion(-)

-- 
2.13.1

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

[Max Krummenacher]

Different SoCs have different RAM layouts, so providing
$(CONFIG_LOADADDR) instead of the constant 0xc100000 for
CONFIG_STANDALONE_LOAD_ADDR is probably more appropriate.

Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
---

 arch/arm/config.mk    | 4 ++++
 doc/README.standalone | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 1a77779db4..8f56c7433f 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -9,7 +9,11 @@ ifndef CONFIG_STANDALONE_LOAD_ADDR
 ifneq ($(CONFIG_ARCH_OMAP2PLUS),)
 CONFIG_STANDALONE_LOAD_ADDR = 0x80300000
 else
+ifndef CONFIG_LOADADDR
 CONFIG_STANDALONE_LOAD_ADDR = 0xc100000
+else
+CONFIG_STANDALONE_LOAD_ADDR = $(CONFIG_LOADADDR)
+endif
 endif
 endif
 
diff --git a/doc/README.standalone b/doc/README.standalone
index 659a12f6cb..17d740c44b 100644
--- a/doc/README.standalone
+++ b/doc/README.standalone
@@ -53,7 +53,7 @@ Design Notes on Exporting U-Boot Functions to Standalone Applications:
 			Load address	Start address
 	x86		0x00040000	0x00040000
 	PowerPC		0x00040000	0x00040004
-	ARM		0x0c100000	0x0c100000
+	ARM		CONFIG_LOADADDR	CONFIG_LOADADDR
 	MIPS		0x80200000	0x80200000
 	Blackfin	0x00001000	0x00001000
 	NDS32		0x00300000	0x00300000
-- 
2.13.1

[U-Boot] [PATCH 2/2] hello_world.c: fix entry point in case of arm thumb binary

[Max Krummenacher]

If compiling for thumb the U-Boot 'go' command can not jump to the entry
point, as the jump will be done in the assumption that the code jumped to
is using the arm instruction set.

So add add a simple forwarder in arm instruction set which then jumps
to the 'real' entry.

Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>

---

 examples/standalone/hello_world.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/examples/standalone/hello_world.c b/examples/standalone/hello_world.c
index bd8b392315..0b859ca4bd 100644
--- a/examples/standalone/hello_world.c
+++ b/examples/standalone/hello_world.c
@@ -8,6 +8,21 @@
 #include <common.h>
 #include <exports.h>
 
+/*
+ * Make thumb work by providing a forwarder to the (thumb) entry point
+ * compiled for arm instruction set.
+ * Don't compile this for thumb only CPUs.
+ */
+#if defined(__thumb__) && defined(__ARM_ARCH_ISA_ARM)
+void __attribute__((unused)) __attribute__ ((naked)) dummy2(void)
+{
+asm volatile( \
+"	.code 32\n" \
+"	.arm\n" \
+"	ldr pc,=hello_world\n");
+}
+#endif
+
 int hello_world (int argc, char * const argv[])
 {
 	int i;
-- 
2.13.1

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

[Wolfgang Denk]

Dear Max,

In message <20170812090346.7887-2-max.krummenacher@toradex.com> you wrote:
> Different SoCs have different RAM layouts, so providing
> $(CONFIG_LOADADDR) instead of the constant 0xc100000 for
> CONFIG_STANDALONE_LOAD_ADDR is probably more appropriate.

At least the wording of the Subject should be fixed.

It is fundamentaaly broken to associate the names "loadaddr" and
"entry point" with each other.  Both are completely independent
entities which mean totally different things. It is pure chance if
the entry point of some loaded image should be at the very beginning
of this image, but this is almost never the case.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The bad reputation UNIX has gotten is totally undeserved, laid on by
people who don't understand, who have not gotten in there  and  tried
anything."          -- Jim Joyce, owner of Jim Joyce's UNIX Bookstore

[U-Boot] [PATCH 0/2] improve hello_world standalone application for arm

[Wolfgang Denk]

Dear Max,

In message <20170812090346.7887-1-max.krummenacher@toradex.com> you wrote:
> 
> This series addresses
> - hardcoded entry address, use LOADADDR if available as the entry point instead

I'm not sure which sort of problem you are trying to fix, but what
you describe here is inherently broken.

The entry point of an image is almost never ever at the beginning of
an image.

Naked-by: Wolfgang Denk <wd@denx.de>

Sorry!


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What is wanted is not the will to believe,  but the will to find out,
which is the exact opposite.
		        -- Bertrand Russell, "Skeptical Essays", 1928

[U-Boot] [PATCH 2/2] hello_world.c: fix entry point in case of arm thumb binary

[Wolfgang Denk]

Dear Max,

In message <20170812090346.7887-3-max.krummenacher@toradex.com> you wrote:
> If compiling for thumb the U-Boot 'go' command can not jump to the entry
> point, as the jump will be done in the assumption that the code jumped to
> is using the arm instruction set.
> 
> So add add a simple forwarder in arm instruction set which then jumps
> to the 'real' entry.

This description makes no sense to me.  Whatever you do, the address
where the image starts executuin is what is called the entry point.
Whether this is needs special code to swutch to thumb mode or not
does not make any difference.  Whichever address you use with the
"go" command is the "entry point".

Also, can the mode switching not be done inside the body of the
regular hello_world() function?  This would be much better as it
wuld allow to always use the same method to determine the entry
point address (line running "nm" on the binary and grepping for the
name "hello_world").  With your code, you would have to fix all
documentation and explain that the entry pooint name is suddenly
domething totally different (and an unexpected, unusal name like
"dummy2" as well) for thumb images.

Sorry, but this does not seem a good idea to me.

Naked-by: Wolfgang Denk <wd@denx.de>

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The use of anthropomorphic terminology when  dealing  with  computing
systems is a symptom of professional immaturity.   -- Edsger Dijkstra

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

[Max Krummenacher]

Dear Wolfgang

Am Samstag, den 12.08.2017, 20:29 +0200 schrieb Wolfgang Denk:
> Dear Max,
> 
> In message <20170812090346.7887-2-max.krummenacher@toradex.com> you wrote:
> > 
> > Different SoCs have different RAM layouts, so providing
> > $(CONFIG_LOADADDR) instead of the constant 0xc100000 for
> > CONFIG_STANDALONE_LOAD_ADDR is probably more appropriate.
> 
> At least the wording of the Subject should be fixed.

Ok, will do. The issue is that linking the standalone application
to have its text segment at a hardcoded address is less
likely to work than using an address provided by the board
configuration as a possible load address.

Will reword the commit message in a v2 series accordingly.

Max

> 
> It is fundamentaaly broken to associate the names "loadaddr" and
> "entry point" with each other.  Both are completely independent
> entities which mean totally different things. It is pure chance if
> the entry point of some loaded image should be at the very beginning
> of this image, but this is almost never the case.
> 
> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot] [PATCH 0/2] improve hello_world standalone application for arm

[Max Krummenacher]

Dear Wolfgang

Am Samstag, den 12.08.2017, 20:32 +0200 schrieb Wolfgang Denk:
> Dear Max,
> 
> In message <20170812090346.7887-1-max.krummenacher@toradex.com> you wrote:
> > 
> > 
> > This series addresses
> > - hardcoded entry address, use LOADADDR if available as the entry point instead
> 
> I'm not sure which sort of problem you are trying to fix, but what
> you describe here is inherently broken.
> 
> The entry point of an image is almost never ever at the beginning of
> an image.

I was mislead by the table in point 6. of doc/README.standalone that it
is a design decision that the entry point is whatever is linked to the
beginning of the text segment. Thus the sloppy use of entry point and
load address.

Max
> 
> Naked-by: Wolfgang Denk <wd@denx.de>
> 
> Sorry!
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot] [PATCH 2/2] hello_world.c: fix entry point in case of arm thumb binary

[Max Krummenacher]

Dear Wolfgang

Am Samstag, den 12.08.2017, 20:39 +0200 schrieb Wolfgang Denk:
> Dear Max,
> 
> In message <20170812090346.7887-3-max.krummenacher@toradex.com> you wrote:
> > 
> > If compiling for thumb the U-Boot 'go' command can not jump to the entry
> > point, as the jump will be done in the assumption that the code jumped to
> > is using the arm instruction set.
> > 
> > So add add a simple forwarder in arm instruction set which then jumps
> > to the 'real' entry.
> 
> This description makes no sense to me.  Whatever you do, the address
> where the image starts executuin is what is called the entry point.
> Whether this is needs special code to swutch to thumb mode or not
> does not make any difference.  Whichever address you use with the
> "go" command is the "entry point".
> 
> Also, can the mode switching not be done inside the body of the
> regular hello_world() function?  This would be much better as it
> wuld allow to always use the same method to determine the entry
> point address (line running "nm" on the binary and grepping for the
> name "hello_world").  With your code, you would have to fix all
> documentation and explain that the entry pooint name is suddenly
> domething totally different (and an unexpected, unusal name like
> "dummy2" as well) for thumb images.

This again stems from my assumption that one has to write the
standalone application in a way that the entry point is actually
linked to the beginning of the binary.

One cannot put the mode switching from thumb to arm instruction set
inside the body of a C function, as the entry code prepended by
the compiler would be in thumb and thus an exception would occur
before the mode switching code gets executed.

Probably one can add a pragma conditionally so that the entry
function gets compiled in arm instruction set. I investigate
further and send a v2.

Max
> 
> Sorry, but this does not seem a good idea to me.
> 
> Naked-by: Wolfgang Denk <wd@denx.de>
> 
> Best regards,
> 
> Wolfgang Denk
> 

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

[Wolfgang Denk]

Dear Max,

In message <1502572898.17070.11.camel@gmail.com> you wrote:
> 
> Ok, will do. The issue is that linking the standalone application
> to have its text segment at a hardcoded address is less
> likely to work than using an address provided by the board

This may (or may not) be the case - but no matter how youlook at it,
chosing CONFIG_LOADADDR is definitely the wrong approach, as the
LOAD address has nothing to do with the ENTRY point address, so it
must in no case ever play a role when linking an image.

> configuration as a possible load address.

You are confused in your wording, and I'm afraid in your thinking,
too.

load address != entry point.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In any group of employed individuals the only naturally  early  riser
is  _always_  the office manager, who will _always_ leave reproachful
little notes ... on the desks of their subordinates.
                                - Terry Pratchett, _Lords and Ladies_

[U-Boot] [PATCH 2/2] hello_world.c: fix entry point in case of arm thumb binary

[Wolfgang Denk]

Dear Max,

In message <1502573515.17070.20.camel@gmail.com> you wrote:
> 
> This again stems from my assumption that one has to write the
> standalone application in a way that the entry point is actually
> linked to the beginning of the binary.

No, this stems from your confusion of load address and entry point
address.  Of course it is possib;e that the entry point is at the
very beginning of the binary.  In that case you must load the image
such into memory, that the start addresss of the binary is the same
as the entry point address.

But the load address is not the start of the binary in memory - it
is the start address of the _image_.   Almost always the bianry will
be just a payload within the image - in the most simple cases of the
lecagy uImage files the binary payload will be preceeded by a 64
byte image header.  So when your load addess is set to 0x100000,
the binary will NOT start at this address, but at an offset of 64
bytes.  So the entry poin can NEVER be the same as the load address,
as this is outside of the image payload.

> One cannot put the mode switching from thumb to arm instruction set
> inside the body of a C function, as the entry code prepended by
> the compiler would be in thumb and thus an exception would occur
> before the mode switching code gets executed.

If this cannot be a regular C funtion, we should still be able to
provide some trampoline code using the same name.  My main goal is
to avoid confugion to the user who expects that he can look up the
entry point address in the nm ouutput under the well-known name.

> Probably one can add a pragma conditionally so that the entry
> function gets compiled in arm instruction set. I investigate
> further and send a v2.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Do not follow where the path may lead....go instead where there is no
path and leave a trail.

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

[Tom Rini]

On Mon, Aug 14, 2017 at 09:36:35PM +0200, Wolfgang Denk wrote:
> Dear Max,
> 
> In message <1502572898.17070.11.camel@gmail.com> you wrote:
> > 
> > Ok, will do. The issue is that linking the standalone application
> > to have its text segment at a hardcoded address is less
> > likely to work than using an address provided by the board
> 
> This may (or may not) be the case - but no matter how youlook at it,
> chosing CONFIG_LOADADDR is definitely the wrong approach, as the
> LOAD address has nothing to do with the ENTRY point address, so it
> must in no case ever play a role when linking an image.
> 
> > configuration as a possible load address.
> 
> You are confused in your wording, and I'm afraid in your thinking,
> too.
> 
> load address != entry point.

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.

-- 
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/20170814/69599d8c/attachment.sig>

[U-Boot] [PATCH 2/2] hello_world.c: fix entry point in case of arm thumb binary

[Tom Rini]

On Sat, Aug 12, 2017 at 11:03:46AM +0200, Max Krummenacher wrote:

> If compiling for thumb the U-Boot 'go' command can not jump to the entry
> point, as the jump will be done in the assumption that the code jumped to
> is using the arm instruction set.
> 
> So add add a simple forwarder in arm instruction set which then jumps
> to the 'real' entry.
> 
> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>

This looks like a special case of what we're doing in f99993c10882 and
dc89c6fb778e and perhaps we need to move that kind of fixup around to
somewhere else, as I assume you've found this problem on a custom
application?  Or are you utilizing hello_world in some test suites?
Just curious, thanks!

-- 
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/20170814/bd0c79c3/attachment.sig>

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

[Wolfgang Denk]

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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The faster I go, the behinder I get.                 -- Lewis Carroll

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

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

-- 
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/20170815/ca92fa54/attachment.sig>

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

[Max Krummenacher]

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

> 

[U-Boot] [PATCH 2/2] hello_world.c: fix entry point in case of arm thumb binary

[Max Krummenacher]

Hello all

Am Montag, den 14.08.2017, 17:15 -0400 schrieb Tom Rini:

On Sat, Aug 12, 2017 at 11:03:46AM +0200, Max Krummenacher wrote:



If compiling for thumb the U-Boot 'go' command can not jump to the entry
point, as the jump will be done in the assumption that the code jumped to
is using the arm instruction set.

So add add a simple forwarder in arm instruction set which then jumps
to the 'real' entry.

Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>


This looks like a special case of what we're doing in f99993c10882 and
dc89c6fb778e and perhaps we need to move that kind of fixup around to
somewhere else, as I assume you've found this problem on a custom
application?  Or are you utilizing hello_world in some test suites?
Just curious, thanks!


I guess the difference to f99993c10882 and dc89c6fb778e is that one
knows from armv7m that the CPU is thumb only while on an armv7a
potentially both arm and thumb mode can be used.

Actually a customer asked how to run hello_world.bin, so I
tested with our regular defconfig and the produced hello_world.bin.

I'm having 'CONFIG_SYS_THUMB_BUILD=y' in e.g.
configs/colibri_imx6_nospl_defconfig thus all of the U-Boot code
including hello_world.c is compiled for thumb.

If I boot that U-Boot, load hello_world.bin into RAM at
CONFIG_STANDALONE_LOAD_ADDR and execute 'go CONFIG_STANDALONE_LOAD_ADDR'
I get output from the go command and then the CPU resets.

    Colibri iMX6 # tftp 0x12000000 hello_world.bin
      ...
    Colibri iMX6 # go 0x12000000                                                     
    ## Starting application at 0x12000000 ...                                       

With the patch I get the expected output.

But actually calling the 'go' command with bit 0 set works. So if
the user knows that he is having a thumb binary that would fix
the issue as well. With the current implementation the following works:

    Colibri iMX6 # go 0x12000001                                                    
    ## Starting application at 0x12000001 ...                                       
    Example expects ABI version 9                                                   
    Actual U-Boot ABI version 9                                                     
    Hello World                                                                     
    argc = 1                                                                        
    argv[0] = "0x12000001"                                                          
    argv[1] = "<NULL>"                                                              
    Hit any key to exit ...                                                         

Max

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

[Wolfgang Denk]

Dear Tom,

In message <20170815113952.GE20467@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.

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


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.



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I'd rather be led to hell than managed to heaven.

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

[Wolfgang Denk]

Dear Max,

In message <1502799746.3076.16.camel@gmail.com> you wrote:
> 
> Wolfgang says that a board needs to decide on what image type to
> use for the standalone application and then from that set an

No, I did not say this.  On contrary, this is not up to the "board"
to decide.  This is a decision tobe made by the end user, and U-Boot
shall not put any restrictions on this.  You may want to use a raw
binary image, someone else uses an ELF file or an uImage, and I
prefer to use a FIT image.

> appropriate CONFIG_STANDALONE_LOAD_ADDR in its board configuration.

The LOAD_ADDR you use it is a misleading name for where the image
gets loaded to in memory. Note that the payload can be compressed or
encrypted or what else.  The "load address" in the intended meaning
(as present in the image headers) is where the payload of the images
gets stored in memory (which may include decryption, uncompressing
or else).  And entry point is still something else.

> Without that the standalone binaries are useless anyway and setting
> a default in arch/arm/config.mk only purpose is that the build succeeds.

For the build process, only the "load address" and "entry point
address" in their original meaning should be interesting - but his
is not what CONFIG_STANDALONE_LOAD_ADDR provides.

> 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 also agree with this.  I just want to use a misleading name for
this default.  If you need an start address for the text segment
you should call it like that - we already have CONFIG_SYS_TEXT_BASE
and CONFIG_SPL_TEXT_BASE, so why not use CONFIG_STANDALONE_TEXT_BASE
here?

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

No, it does not, as it still uses CONFIG_LOADADDR (= default
download address of some image type) where you in fact mean the
default start address of the data payload only (and very likely this
is the same as the start of the text segment).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A verbal contract isn't worth the paper it's written on.
                                                    -- Samuel Goldwyn

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