On Mon, 13 Feb 2017 22:19:45 +0000
James Hogan <[email protected]> wrote:
> Hi Alban,
>
> On Mon, Feb 13, 2017 at 09:38:08PM +0100, Alban wrote:
> > From: Alban Bedel <[email protected]>
> >
> > Compressed images (vmlinuz.bin) have to be loaded at a specific
> > address that differ from the address normaly used for vmlinux.bin.
> > This is because the decompressor just write its output at the address
> > vmlinux.bin should be loaded at, and it shouldn't overwrite itself.
> > This limitation mean that the bootloader must be configured differently
> > when loading a vmlinux.bin or a vmlinuz.bin image, this is annoying
> > and a source of error.
> >
> > To workaround this we extend the compressed loader to cope with being
> > loaded at (nearly) any address. During the early init a jump is used
> > to compute the offset between the current address and the linked
> > address, if they differ the whole image is first copied to the linked
> > address before proceeding.
> >
> > Some load address won't work, for example if there is an overlap with
> > the range where vmlinuz.bin should be loaded. However for the typical
> > case of using the vmlinux.bin address that won't be the case.
> >
> > Signed-off-by: Alban Bedel <[email protected]>
> > Suggested-by: Jonas Gorski <[email protected]>
> > ---
> > Changelog:
> > v2: * Rework the code as suggested by Jonas Gorski to autodetect the
> > load address and remove the need for a Kconfig option.
> > ---
> > arch/mips/boot/compressed/head.S | 23 +++++++++++++++++++++++
> > 1 file changed, 23 insertions(+)
> >
> > diff --git a/arch/mips/boot/compressed/head.S b/arch/mips/boot/compressed/head.S
> > index 409cb48..3c25a96 100644
> > --- a/arch/mips/boot/compressed/head.S
> > +++ b/arch/mips/boot/compressed/head.S
> > @@ -25,6 +25,29 @@ start:
> > move s2, a2
> > move s3, a3
> >
> > + /* Get the offset between the current address and linked address */
> > + PTR_LA t0, reloc_label
> > + bal reloc_label
> > + nop
> > +reloc_label:
> > + subu t0, ra, t0
> > +
> > + /* If there is no offset no reloc is needed */
> > + beqz t0, clear_bss
> > + nop
> > +
> > + /* Move the text, data section and DTB to the correct address */
> > + PTR_LA a0, .text
> > + addu a1, t0, a0
> > + PTR_LA a2, _edata
> > +copy_vmlinuz:
> > + lw a3, 0(a1)
> > + sw a3, 0(a0)
> > + addiu a0, a0, 4
> > + bne a2, a0, copy_vmlinuz
> > + addiu a1, a1, 4
>
> Does this need to sync the icache and resolve the instruction hazard
> before jumping into the newly written code?
>
> E.g. on mips32/64 r2 and later you could I think "synci" at SYNCI_Step
> intervals (as determined by RDHWR instruction), followed by a "sync" and
> then using "jr.hb" instead of "jr" to clear the instruction hazard while
> jumping to the newly written code.
>
> That is roughly what arch/mips/kernel/relocate.c and
> arch/mips/kernel/head.S do, but as mentioned that assumes MIPS32/64 r2+,
> and at least 2 platforms selecting SYS_SUPPORTS_ZBOOT* also select
> CPU_HAS_CPU_MIPS32_R1.
This was a long time ago but I still like to finish this. However I'm
not very really versed into this kind of very low level subjects, so
I would appreciate if somebody could tell me if the cache sync is needed
here or not. All I can says is that it currently work on ATH79 which is
a mips32 r2, but that doesn't mean it is correct.
Also note that no such cache sync is done on the decompressed kernel,
wouldn't that also be needed?
Alban