Re: [PATCH 03/16] image: Take entry point as an output of setup_booti

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2426 bytes --]

On Tue, Jun 11, 2024 at 03:01:00PM +0100, Jiaxun Yang wrote:
> 
> 
> 在2024年6月11日六月 下午2:52，Tom Rini写道：
> > On Tue, Jun 11, 2024 at 02:29:38PM +0100, Jiaxun Yang wrote:
> >> 
> >> 
> >> 在2024年6月11日六月 下午2:02，Heinrich Schuchardt写道：
> >> > On 22.05.24 17:34, Jiaxun Yang wrote:
> >> >> For LoongArch the start of the image is not the entry
> >> >> point to the image.
> >> >
> >> > Looking at arch/loongarch/kernel/head.S there seem to be two cases:
> >> >
> >> > * The kernel has an EFI stub (CONFIG_EFI_STUB=y).
> >> >    The legacy physical entry point is available at offset 0x08 of the
> >> > header.
> >> > * The kernel has no EFI stub.
> >> >    The kernel entry point matches the start of the image.
> >> >
> >> > Where do you differentiate between the cases?
> >> 
> >> Hi Heinrich,
> >> 
> >> In case there is no EFI stub LoongArch would use elf format vmlinux, there
> >> is no real "raw" image for us.
> >> 
> >> bootelf can't be used at the moment as it doesn't setup FDT and other environments
> >> properly.
> >> 
> >> I'm planning to implement a bootlinuxelf command for this case, as MIPS, LoongArch,
> >> xtensa are all using ELF as default kernel image format.
> >
> > Please note that we have CONFIG_CMD_ELF_FDT_SETUP already, so adjusting
> > things so that bootelf works for this case should be doable without a
> > new command.
> 
> This is a little bit broken as then you'll need to bring architecture specific
> functions to bootelf to setup boot registers, initrd etc. It's fine for Arm64 which
> you just need to throw fdt into a location in memory but for MIPS and LoongArch 
> you have to setup a good deal of other stuff.
> 
> Ideally those setups should be done with bootm_run_states as what we've done at
> booti, but that would be a semantic to bootelf command. I know many existing
> MIPS bare-metal applications rely on argc/argv style bootelf and I don't want to
> break them, thus I think a new command is necessary.

We should discuss this in its own thread, yeah. It's been a long while
since I had to bootelf something non-trivial and one of the issues is
that yes, a bunch of quiesce the system functionality wasn't done. Maybe
it's just a matter of adding a flag to bootelf to say we're booting an
OS rather than simple app and so call the normal boot os prep function
chain.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]