| Message ID | 20170812090346.7887-2-max.krummenacher@toradex.com |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
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
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 >
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
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.
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
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.
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 >
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
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
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...
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
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(-)