1. Devel
  2. Topics

Queries regarding the boot requirements for Zephyr on Arm platform

Ayan Kumar Halder
 

Hi Zephyr Arm Team,

Greetings.

I am trying to support Zephyr as a domU kernel from Xen and I was asked some questions from the Xen-devel community.

Context - https://patchwork.kernel.org/project/xen-devel/patch/20221208124929.55268-1-ayan.kumar.halder@.../

I will list the questions (Q) and I will give my understanding (A) based on the code. Please confirm or correct me if I am mistaken.

Can you describe the expectation of Zephyr for the following components:

Q) - 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

A) Zephyr is expected to run as a baremetal binary. When loading from Xen or uboot, the interrupts should be disabled.

There is nothing mentioned about the state of caches, but I assume I/D caches will have to be disabled. Otherwise, there is a chance of reading stale instructions from I cache.

The state of the system should be similar to how it is out of reset state (SVC or EL1).

When Zephyr is loaded in memory, I am expecting the image to be cleaned to PoC. However, I am not very sure on this.

Q) - State of the co-processor registers:
     * Can we call the kernel with I-cache enabled?

A) I assume I cache needs to be disabled.

Q) - State of the general purpose registers:

A) The general purpose registers can be in an in-determinate state.

Q) For instance, Linux expects a pointer to the device-tree in r0 

A) Zephyr is built with a device tree. Thus, it does not expect pre-determined values in r0, r1, etc.

Kind regards,
Ayan

-------- Forwarded Message --------
Subject: Re: [XEN v1] xen/Arm: Probe the entry point address of an uImage correctly
Date: Fri, 9 Dec 2022 19:19:21 +0000
From: Julien Grall <julien@...>
To: Ayan Kumar Halder <ayankuma@...>, Michal Orzel <michal.orzel@...>, Ayan Kumar Halder <ayan.kumar.halder@...>, xen-devel@...
CC: sstabellini@..., stefanos@..., Volodymyr_Babchuk@..., bertrand.marquis@..., Oleksandr Tyshchenko <oleksandr_tyshchenko@...>


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

Carlo Caione
 

On 12/12/2022 13:37, Ayan Kumar Halder wrote:
Hi Zephyr Arm Team,
Hello,

A) Zephyr is expected to run as a baremetal binary. When loading
from Xen or uboot, the interrupts should be disabled.
Correct. We disable the interrupts at boot for good measure before but
in theory you want the interrupts to be disabled before jumping to Zephyr.

There is nothing mentioned about the state of caches, but I assume I/D caches will have to be disabled. Otherwise, there is a chance of reading stale instructions from I cache.
Correct. When zephyr is chain-loaded by u-boot we usually disable I/D
caches from u-boot itself before jumping.

The state of the system should be similar to how it is out of reset state (SVC or EL1).
Yes, the only caveat is that in Zephyr you have to set CONFIG_ARMV8_A_NS
whether you are booting from EL3 or EL1.

When Zephyr is loaded in memory, I am expecting the image to be cleaned to PoC. However, I am not very sure on this.
The BSS is cleared as part of the boot process with z_bss_zero() and
data is copied with z_data_copy(), see [1] for more details.

A) I assume I cache needs to be disabled.
Yup.

A) The general purpose registers can be in an in-determinate state.
We do not make any assumption about the state of the GPR at boot. If
there is an hidden dependency, that is a bug to fix.

A) Zephyr is built with a device tree. Thus, it does not expect pre-determined values in r0, r1, etc.
Correct.

Ciao!

[1]
https://github.com/zephyrproject-rtos/zephyr/blob/main/arch/arm64/core/prep_c.c#L54

--
Carlo Caione

1 - 2 of 2