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