Hi Tom,
On Mon, 6 Nov 2023 at 13:15, Tom Rini trini@konsulko.com wrote:
On Mon, Nov 06, 2023 at 12:58:46PM -0700, Simon Glass wrote:
Hi Tom,
On Mon, 6 Nov 2023 at 11:30, Tom Rini trini@konsulko.com wrote:
On Mon, Nov 06, 2023 at 10:25:00AM -0700, Simon Glass wrote:
Hi Tom,
On Sun, 5 Nov 2023 at 14:19, Tom Rini trini@konsulko.com wrote:
On Sun, Nov 05, 2023 at 01:03:51PM -0700, Simon Glass wrote:
This image type is supposed to ignore the load address. But at present it fails if the load address is missing. If it is zero, the image is loaded at address 0, which may not work on all boards.
Make use of the kernel_addr_r environment variable, instead, since this seems to be a more reliable final address for the kernel.
Another option would be to create a new Kconfig for this, or to use a region of memory known to be free, e.g. calculated from the DRAM banks. But in any case we should try to avoid conflicting with the kernel_addr_r variable. So the approach in this patch seems reasonable to me.
Signed-off-by: Simon Glass sjg@chromium.org
How are you creating the image in question here? A noload FIT is supposed to just supposed to go from where it is. Where do things fall down later?
The image is Image.gz built by Linux, for example. So compression = "gzip" which means that it has to be decompressed.
Things fall down as soon as U-Boot looks at the image, since it doesn't have the ARM64 magic.
Can you provide logs and env? "booti" is supposed to handle this case already, and if it's not we should figure out when / why it broke.
Do you mean booti handles compression? Yes, I can see that in the code.
Yes, you use "booti" with an Image.gz.
But in my case I am using bootm, since it is a FIT.
Shouldn't this be handled by the normal compression = "foo" logic? And in turn is that what's not working? If so, the commit messages aren't clear.
We are on the wrong commit here. See this one:
https://patchwork.ozlabs.org/project/uboot/patch/20231105130351.2.Ie34b75c75...
Perhaps this is supposed to work some other way, but to me it seems quite broken at present.
Regards, Simon