Re: [XEN v1] xen/Arm: Probe the entry point address of an uImage correctly

[Ayan Kumar Halder <ayankuma@xxxxxxx>]

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 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.

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.
>         * ...
>   - 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.
- Ayan

> Cheers,
[1] https://lists.zephyrproject.org/g/devel/message/8805

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

--- Begin Message ---

• To: Ayan Kumar Halder <ayankuma@xxxxxxx>, Jaxson Han <jaxson.han@xxxxxxx>, "npitre@xxxxxxxxxxxx" <npitre@xxxxxxxxxxxx>
• From: Carlo Caione <ccaione@xxxxxxxxxxxx>
• Date: Mon, 12 Dec 2022 15:05:39 +0100
• Authentication-results: spf=pass (sender IP is 209.85.167.49) smtp.mailfrom=baylibre.com; dkim=pass (signature was verified) header.d=baylibre-com.20210112.gappssmtp.com;dmarc=bestguesspass action=none header.from=baylibre.com;compauth=pass reason=109
• Cc: Julien Grall <julien@xxxxxxx>, devel@xxxxxxxxxxxxxxxxxxxxxxx, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>

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

--- End Message ---