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 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
Zephyr is expected to run as a baremetal binary. When loading from Xen
or uboot, the interrupts should be disabled before jumping to Zephyr.
I/D caches need to be disabled as well.
For both 32-bit and 64-bit Linux, the instruction can may be on or off.
At the moment, Xen is choosing to disable it. But if that's a
requirement for Zephyr, then I think we should document it.
That said, from the answer on the other thread, it was not clear whether
this is a strong requirement or just because U-boot is doing it.
The image should be cleaned to PoC. The BSS is cleared as part of the
Zephyr boot process with z_bss_zero() and data is copied with
z_data_copy(), see [2] for more details.
- State of the co-processor registers:
* Can we call the kernel with I-cache enabled?
I cache needs to be disabled before calling kernel.
See above for the I-cache. However, this question was not only about the
I-cache. It was just an example to what I am looking for in this category.
It might be easier if you read linux/Documentation/arm/booting.rst and
let me know whether there is any expectation that don't match.
* ...
- State of the general purpose registers:
* For instance, Linux expects a pointer to the device-tree in r0
Zephyr does not make any assumption about the state of the GPR at boot.
Also, Zephyr is built with a device tree.
Cheers,
--
Julien Grall
