[PATCH v2 03/16] image: Take entry point as an output of setup_booti
Yao Zi
me at ziyao.cc
Thu Jul 2 23:10:47 CEST 2026
On Thu, Jul 02, 2026 at 02:55:22PM -0600, Tom Rini wrote:
> On Thu, Jul 02, 2026 at 08:39:44PM +0000, Yao Zi wrote:
> > On Wed, Jul 01, 2026 at 11:39:40AM -0600, Tom Rini wrote:
> > > On Wed, Jul 01, 2026 at 11:17:55AM +0000, Yao Zi wrote:
> > >
> > > > From: Jiaxun Yang <jiaxun.yang at flygoat.com>
> > > >
> > > > For LoongArch the start of the image is not the entry
> > > > point to the image.
> > > >
> > > > We refactor the code base to allow entry point to be
> > > > supplied by setup_booti.
> > > >
> > > > Signed-off-by: Jiaxun Yang <jiaxun.yang at flygoat.com>
> > > > Signed-off-by: Yao Zi <me at ziyao.cc>
> > > > ---
> > > >
> > > > Changed from v1
> > > > - Correct type of "entry" argument for RISC-V and sandbox
> > >
> > > Can you please also provide a link to
> > > https://www.kernel.org/doc/html/latest/arch/loongarch/booting.html which
> > > probably should cover this, but I'm not entirely sure does?
> >
> > It does in a non-obvious way, quoting part of the image header,
> >
> > u32 MZ_MAGIC /* "MZ", MS-DOS header */
> > u32 res0 = 0 /* Reserved */
> > u64 kernel_entry /* Kernel entry point */
> >
> > comparing it to the RISC-V version[1],
> >
> > u32 code0; /* Executable code */
> > u32 code1; /* Executable code */
> > u64 text_offset; /* Image load offset, little endian */
> > u64 image_size; /* Effective Image size, little endian */
> >
> > The start of LoongArch image isn't marked as executable.
>
> Perhaps it's worth clarifying in the kernel documentation then? Thanks.
Sure, Jiaxun and I plan to improve the kernel side documentation, and
additionally improve LoongArch image header to make the image executable
from its start, aligning with aarch64 and riscv64.
However, there isn't a promise when it would land, and even with the
improvement to image header, we still have to parse the text_offset
field to keep compatibility with older images.
> > Additionally, should I include the URL of "latest" kernel documentation,
> > or using a link with explicit kernel version (e.g. [2]) to ensure the
> > content doesn't change or become 404 over time?
>
> Ah, true, yes, lets point at the v7.1 tag, or whatever you're testing
> this against, to cover future changes if any.
>
> --
> Tom
Best regards,
Yao Zi
More information about the U-Boot
mailing list