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 states that it supports zImage/Image and
does not mention uImage.
A header is one thing, the boot requirements are another. Supporting
uImage is ok but if we specify
that it must be a u-boot header added on top of zImage/Image.
Let me first confine to Arm32 only.
zephyr.bin has to be loaded at a fixed address with which it has been
built.
So, we could either use zImage header (where 'start_address' can be used
to specify the load address).
Or uImage (where -a is used to specify the load address).
Adding uImage header on top of zImage does not make sense.
Now for Arm64, we do need to parse the zImage header
#ifdef CONFIG_ARM_64
if ( info->type == DOMAIN_64BIT )
{
return info->mem.bank[0].start + info->zimage.text_offset;
}
#endif
Again, adding uImage header on top of zImage header does not make sense
as well.
Also, I believe zImage boot requirements are specific for linux kernel.
Correct. But then this is what Xen tries to adhere to when preparing the
guest. So...
zephyr or any other RTOS may not follow the same boot requirements.
... if Zephyr or any other RTOS have different requirements, then we may
need to modify Xen.
Can you describe the expectation of Zephyr for the following components:
- State of the memory/cache:
* Should the image be cleaned to PoC or more?
* What about the area not part of the binary (e.g. BSS)?
* What about the rest of the memory
- State of the co-processor registers:
* Can we call the kernel with I-cache enabled?
* ...
- State of the general purpose registers:
* For instance, Linux expects a pointer to the device-tree in r0
Cheers,
--
Julien Grall
