[PATCH 2/7] efi: Allow runtime relocate to be disabled

Ilias Apalodimas ilias.apalodimas at linaro.org
Tue May 21 19:32:25 CEST 2024


On Tue, 21 May 2024 at 17:42, Jiaxun Yang <jiaxun.yang at flygoat.com> wrote:
>
>
>
> 在2024年5月21日五月 下午2:58,Ilias Apalodimas写道:
> > Hi Jiaxun,
> >
> > On Fri, 17 May 2024 at 19:33, Jiaxun Yang <jiaxun.yang at flygoat.com> wrote:
> >>
> >> Allow runtime relocate to be disabled because on MIPS we
> >> never do that. It's guaranteed that OS won't call
> >> set_virtual_address_map and convert_pointer as well.
> >
> > Who guarantees that? Is it only for Linux?
> Hi Ilias,
>
> It's guarantee by all the existing implementations, ventoy,
> linux etc.
>

What's ventoy? Googling it seems to be a tool for writing images?

> It's nearly impossible to run MIPS OS in virtual (or paged)
> segment. All MIPS OS and bootloaders are running in KSEG/XKPHYS
> segment, which directly mapping lower bits of virtual address
> into physical address. So I suppose set_virtual_address_map
> is unnecessary on MIPS because the mapping for U-Boot is
> always here and can't be disabled in hardware.
>

Fair enough, I am not too happy with the restriction but I think it's
ok to start with

> >
> >>
> >> On MIPS KSEG0 is always mapped to memory and there is no
> >> way to disable it for kernel mode. Both EFI runtime and
> >> kernel lays in this segment, so relocation is totally
> >> unnecessary.
> >>
> >> Also U-Boot does not use traditional .dyn.rel to perform
> >> relocation on MIPS, that makes implementation of runtime
> >> relocation pretty hard.
> >
> > It already works on other architectures so I suppose it's only a
> > matter of adding it?
>
> MIPS is odd here, we are not compiling U-Boot with -fPIC, instead
> we use our own tools to generate relocation records and embedded
> them into U-Boot.
>
> Adding relocation support requires modifications to that tool
> "tools/mips-relocs.c" and also processing our own record format
> here.
>
> Given that set_virtual_address_map have no practice use on MIPS,
> I think the best way to handle it is to leave set_virtual_address_map
> alone.

hrrm any idea why? Was that a pre-existing state in mips? Perhaps we
can fix it in the future.

That being said, I was away on a conference, I'll have a look at the
mips patches, but probably next week

Cheers
/Ilias
>
> Thanks
> >
> > Thanks
> > /Ilias
> >>
> [...]
> --
> - Jiaxun


More information about the U-Boot mailing list