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

[Julien Grall <julien@xxxxxxx>]

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