On 08.01.23 18:06, Julien Grall wrote:
Hello Julien, Ayan, all
Hi Ayan,
On 21/12/2022 18:53, Ayan Kumar Halder wrote:
Currently, kernel_uimage_probe() does not read the load/entry point
address
set in the uImge header. Thus, info->zimage.start is 0 (default
value). This
causes, kernel_zimage_place() to treat the binary (contained within
uImage)
as position independent executable. Thus, it loads it at an incorrect
address.
The correct approach would be to read "uimage.load" and set
info->zimage.start. This will ensure that the binary is loaded at the
correct address. Also, read "uimage.ep" and set info->entry (ie kernel
entry
address).
If user provides load address (ie "uimage.load") as 0x0, then the
image is
treated as position independent executable. Xen can load such an image at
any address it considers appropriate. A position independent executable
cannot have a fixed entry point address.
This behavior is applicable for both arm32 and arm64 platforms.
Earlier for arm32 and arm64 platforms, Xen was ignoring the load and
entry
point address set in the uImage header. With this commit, Xen will use
them.
This makes the behavior of Xen consistent with uboot for uimage headers.
The changes look good to me (with a few of comments below). That said,
before acking the code, I would like an existing user of uImage (maybe
EPAM or Arm?) to confirm they are happy with the change.
I have just re-checked current patch in our typical Xen based
environment (no dom0less, Linux in Dom0) and didn't notice issues with
it. But we use zImage for Dom0's kernel, so kernel_uimage_probe() is not
called.
I CCed Dmytro Firsov who is playing with Zephyr in Dom0 and *might* use
uImage.
[snip]
