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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
