Hi,
 
> >>>> arch/arm/cpu/armv7/lowlevel_init.S:.pushsection .text.s_init, "ax"
> >>>> arch/arm/cpu/armv7/lowlevel_init.S:WEAK(s_init)
> >>>> arch/arm/cpu/armv7/lowlevel_init.S:ENDPROC(s_init)
> >>>> arch/arm/cpu/armv7/lowlevel_init.S:     bl      s_init
> >>>>
> >>>> Maybe such a default lowlevel_init for armv8 could also have an s_init ?
> >>>>
> >>>>> What's concern with lowlevel_init()? It's also wired into existing
> >>>>> early hook function which's located inside start.S
> >>>> I would like to avoid duplicating lowlevel_init functionality as
> >>>> much as possible , common lowlevel_init would be very welcome .
> >>>
> >>> Sure, I can add the s_init to common lowlevel_init and moving the
> >>> codes to
> >> s_init.
> >> Thanks. Then the question is, how much of this stuff can be removed
> >> because it is part of generic lowlevel_init, I hope a lot.
> >
> > I'm not sure I completely understand your question, but I can share what
> we're going to do.
> 
> I am wondering if some of the code here can be deduplicated by using the
> generic lowlevel_init.S , i.e. if some of the code in lowlevel_init.S is 
> duplicate
> of the code in this custom lowlevel_init.S implementation.

No duplicate codes in both common lowlevel_init.S and custom lowlevel_init.S.

> 
> > Declaring a weak s_init function at lowlevel_init.S
> >
> > .pushsection .text.s_init, "ax"
> > WEAK(s_init)
> >     bx      lr
> > ENDPROC(s_init)
> > .popsection
> >
> > Calling s_init before lowlevel_init returned to parent call
> >                [...]
> >     bl s_init
> >     move lr, x29
> >                ret
> >
> > We will move the codes to s_init which is declared in our platform driver,
> arch/arm/mach-socfpga .
> >
> > The codes is needed to backup the data section as earlier as possible
> > to support warm reset / watchdog due to warm reset use case, where
> reloading SPL would be skipped after reset.
> If you need to run code very early and back up critical data, look at
> save_boot_params .

Thanks for suggesting this, we will try this out.

Regards,
Tien Fong

Reply via email to