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

[Julien Grall <julien@xxxxxxx>]

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