Hi,
On 13 February 2017 at 09:37, Alban <albeu@xxxxxxx> wrote:
> On Thu, 9 Feb 2017 13:22:37 +0100
> Jonas Gorski <jonas.gorski@xxxxxxxxx> wrote:
>
>> Hi,
>>
>> On 5 February 2017 at 21:21, Alban <albeu@xxxxxxx> wrote:
>> > From: Alban Bedel <albeu@xxxxxxx>
>> >
>> > Normally compressed images have to be loaded at a different address to
>> > allow the decompressor to run. This add an option to let vmlinuz copy
>> > itself to the correct address from the normal vmlinux address.
>> >
>> > Signed-off-by: Alban Bedel <albeu@xxxxxxx>
>> > ---
>> > arch/mips/Kconfig | 8 ++++++++
>> > arch/mips/boot/compressed/head.S | 13 +++++++++++++
>> > 2 files changed, 21 insertions(+)
>> >
>> > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
>> > index b3c5bde..8074fc5 100644
>> > --- a/arch/mips/Kconfig
>> > +++ b/arch/mips/Kconfig
>> > @@ -2961,6 +2961,14 @@ choice
>> > bool "Extend builtin kernel arguments with bootloader arguments"
>> > endchoice
>> >
>> > +config ZBOOT_VMLINUZ_AT_VMLINUX_LOAD_ADDRESS
>> > + bool "Load compressed images at the same address as uncompressed"
>> > + depends on SYS_SUPPORTS_ZBOOT
>> > + help
>> > + vmlinux and vmlinuz normally have different load addresses, with
>> > + this option vmlinuz expect to be loaded at the same address as
>> > + vmlinux.
>> > +
>> > endmenu
>>
>> Okay, it took me a while to understand the intention of this change. I
>> thought it was for supporting the case that VMLINUZ_LOAD_ADDRESS ==
>> VMLINUX_LOAD_ADDRESS, but it is indented for VMLINUZ_LOAD_ADDRESS !=
>> VMLINUX_LOAD_ADDRESS, but still being loaded at VMLINUX_LOAD_ADDRESS.
>>
>> So I guess that this can only happen with vmlinuz.bin, as vmlinux's
>> ELF header will cause it to be loaded at the expected address (for
>> sane bootloaders at least).
>
> Yes, this is for bootloaders that use raw images. Having to configure
> different load addresses for compressed and uncompressed images was just
> too annoying.
>
>> > config LOCKDEP_SUPPORT
>> > diff --git a/arch/mips/boot/compressed/head.S b/arch/mips/boot/compressed/head.S
>> > index 409cb48..a215171 100644
>> > --- a/arch/mips/boot/compressed/head.S
>> > +++ b/arch/mips/boot/compressed/head.S
>> > @@ -25,6 +25,19 @@ start:
>> > move s2, a2
>> > move s3, a3
>> >
>> > +#ifdef CONFIG_ZBOOT_VMLINUZ_AT_VMLINUX_LOAD_ADDRESS
>>
>> With a bit of BAL trickery you could easily detect this at runtime and
>> then conditionally copy without requiring any additional config
>> symbols. Then you aren't limited to being executed from
>> VMLINUX_LOAD_ADDRESS.
>
> Could you expand a bit on what you mean with "BAL trickery"? I hoped
> that it would be possible to auto detect the current running address,
> but as I know very little about MIPS assembly I didn't found how that
> could be done.
With BAL (branch and link) you can do a pc-relative jump, and the
current address will be stored in $ra. comparing it with the expected
address will give you the offset by which you were loaded. To quote
the lzma-loader from OpenWrt/Lede[1]:
la t0, __reloc_label # get linked address of label
bal __reloc_label # branch and link to label to
nop # get actual address
__reloc_label:
subu t0, ra, t0 # get reloc_delta
beqz t0, __reloc_done # if delta is 0 we are in the
right place
nop
/* Copy our code to the right place */
la t1, _code_start # get linked address of _code_start
la t2, _code_end # get linked address of _code_end
addu t0, t0, t1 # calculate actual address of
_code_start
__reloc_copy:
...
__reloc_done:
...
Regards
Jonas
[1] https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/ar71xx/image/lzma-loader/src/head.S;h=47a7c9bd6300ad92e6a0d426c5f44bc0f3e7e85f;hb=HEAD#l49
