Hi All,
On 10/01/2023 12:30, Dmytro Firsov wrote:
On 09.01.23 11:36, Oleksandr Tyshchenko wrote:
On 08.01.23 18:06, Julien Grall wrote:
Hello Julien, Ayan, all
Hi Ayan,
...
The changes look good to me (with a few of comments below). That
said, before acking the code, I would like an
On 09.01.23 11:36, Oleksandr Tyshchenko wrote:
>
>
> On 08.01.23 18:06, Julien Grall wrote:
>
> Hello Julien, Ayan, all
>
>> Hi Ayan,
>> ...
>> 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
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,
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
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
