On 12/12/2022 19:04, Ayan Kumar Halder wrote:
On 09/12/2022 19:19, Julien Grall wrote:
Hi Ayan,
Hi Julien,
Hi,
I checked with the Zephyr mantainers. Their response is provided [1].
Thanks for checking.
On 09/12/2022 19:10, Ayan Kumar Halder wrote:
zImage and Image are image prot
On 09/12/2022 19:19, Julien Grall wrote:
Hi Ayan,
Hi Julien,
I checked with the Zephyr mantainers. Their response is provided [1].
On 09/12/2022 19:10, Ayan Kumar Halder wrote:
zImage and Image are image protocols, uImage is not. It is just a
legacy u-boot header (no requirements
\wrt boo
Hi Ayan,
On 09/12/2022 19:10, Ayan Kumar Halder wrote:
zImage and Image are image protocols, uImage is not. It is just a
legacy u-boot header (no requirements
\wrt booting,memory,registers, etc.). It can be added on top of
anything (even vmlinux or a text file).
So I guess this is why Xen state
Hi Michal,
On 09/12/2022 08:53, Michal Orzel wrote:
On 08/12/2022 19:42, Ayan Kumar Halder wrote:
On 08/12/2022 16:53, Julien Grall wrote:
Hi,
Hi,
On 08/12/2022 15:24, Michal Orzel wrote:
On 08/12/2022 14:51, Julien Grall wrote:
Caution: This message originated from an External Source. Use
On 08/12/2022 19:42, Ayan Kumar Halder wrote:
>
> On 08/12/2022 16:53, Julien Grall wrote:
>> Hi,
> Hi,
>>
>> On 08/12/2022 15:24, Michal Orzel wrote:
>>> On 08/12/2022 14:51, Julien Grall wrote:
Caution: This message originated from an External Source. Use proper
caution when opening
On 08/12/2022 18:42, Ayan Kumar Halder wrote:
> On 08/12/2022 16:53, Julien Grall wrote:
>> On 08/12/2022 15:24, Michal Orzel wrote:
>>> So the first issue with Zephyr is that it does not support zImage
>>> protocol for arm32.
>>> Volodymyr added support only for Image header for arm64 Zephyr.
>>>
On Thu, 8 Dec 2022, Ayan Kumar Halder wrote:
> On 08/12/2022 16:53, Julien Grall wrote:
> > Hi,
> Hi,
> >
> > On 08/12/2022 15:24, Michal Orzel wrote:
> > > On 08/12/2022 14:51, Julien Grall wrote:
> > > > Caution: This message originated from an External Source. Use proper
> > > > caution when op
On 08/12/2022 16:53, Julien Grall wrote:
Hi,
Hi,
On 08/12/2022 15:24, Michal Orzel wrote:
On 08/12/2022 14:51, Julien Grall wrote:
Caution: This message originated from an External Source. Use proper
caution when opening attachments, clicking links, or responding.
Hi,
Title extra NIT:
Hi,
On 08/12/2022 15:24, Michal Orzel wrote:
On 08/12/2022 14:51, Julien Grall wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
Hi,
Title extra NIT: I have seen it multiple time and so far refrain to
On 08/12/2022 15:24, Michal Orzel wrote:
Hi,
Hi,
On 08/12/2022 14:51, Julien Grall wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
Hi,
Title extra NIT: I have seen it multiple time and so far re
On 08.12.2022 14:51, Julien Grall wrote:
> On 08/12/2022 12:49, 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
Hi,
On 08/12/2022 14:51, Julien Grall wrote:
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Hi,
>
> Title extra NIT: I have seen it multiple time and so far refrain to say
> it. Please use 'arm' ra
On 08/12/2022 13:51, Julien Grall wrote:
Hi,
Hi Julien,
Title extra NIT: I have seen it multiple time and so far refrain to
say it. Please use 'arm' rather than 'Arm'. This is for consistency in
the way we name the subsystem in the title.
I will take care of it henceforth.
On 08/12/2022
Hi,
Title extra NIT: I have seen it multiple time and so far refrain to say
it. Please use 'arm' rather than 'Arm'. This is for consistency in the
way we name the subsystem in the title.
On 08/12/2022 12:49, Ayan Kumar Halder wrote:
Currently, kernel_uimage_probe() does not set info->zimage.
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
15 matches
Mail list logo