Hi Julien,
I need a clarification.
On 20/12/2022 12:51, Ayan Kumar Halder wrote:
On 20/12/2022 12:14, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 20/12/2022 10:44, Ayan Kumar Halder wrote:
+
+ /*
+ * Currently, we support uImage headers for uncompressed
images only.
+ * Thus, i
On 20/12/2022 12:14, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 20/12/2022 10:44, Ayan Kumar Halder wrote:
+
+ /*
+ * Currently, we support uImage headers for uncompressed
images only.
+ * Thus, it is valid for the load address and start address
to be the
+ * same. This is
Hi Ayan,
On 20/12/2022 10:44, Ayan Kumar Halder wrote:
+
+ /*
+ * Currently, we support uImage headers for uncompressed images
only.
+ * Thus, it is valid for the load address and start address to
be the
+ * same. This is consistent with the uboot behavior (Refer
+ * "case
Hi Julien/Michal,
On 20/12/2022 10:05, Julien Grall wrote:
On 20/12/2022 09:44, Michal Orzel wrote:
Hi Ayan,
On 17/12/2022 20:38, Ayan Kumar Halder wrote:
Currently, kernel_uimage_probe() does not set info->zimage.start. As a
result, it contains the default value (ie 0). This causes,
kernel_z
On 20/12/2022 09:44, Michal Orzel wrote:
Hi Ayan,
On 17/12/2022 20:38, Ayan Kumar Halder wrote:
Currently, kernel_uimage_probe() does not set info->zimage.start. As a
result, it contains the default value (ie 0). This causes,
kernel_zimage_place() to treat the binary (contained within uImage) a
Hi Ayan,
On 17/12/2022 20:38, Ayan Kumar Halder wrote:
> Currently, kernel_uimage_probe() does not set info->zimage.start. As a
> result, it contains the default value (ie 0). This causes,
> kernel_zimage_place() to treat the binary (contained within uImage) as
> position independent executable. T
Currently, kernel_uimage_probe() does not set info->zimage.start. As a
result, it contains the default value (ie 0). 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
