[2/8] x86: start64: Add a hook at 64-bit entry

From: Aiden Park <aiden.park at intel.com>

This will allow a board or cpu to do its specific initialization
at 64-bit entry if U-Boot is a pure 64-bit binary.

Signed-off-by: Aiden Park <aiden.park at intel.com>
---
 arch/x86/cpu/start64.S | 5 +++++
 1 file changed, 5 insertions(+)

Hi Aiden,

On Tue, 21 Apr 2020 at 18:45, <aiden.park at intel.com> wrote:
>
> From: Aiden Park <aiden.park at intel.com>
>
> This will allow a board or cpu to do its specific initialization
> at 64-bit entry if U-Boot is a pure 64-bit binary.
>
> Signed-off-by: Aiden Park <aiden.park at intel.com>
> ---
>  arch/x86/cpu/start64.S | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/x86/cpu/start64.S b/arch/x86/cpu/start64.S
> index 7be834788b..b8ac5aab57 100644
> --- a/arch/x86/cpu/start64.S
> +++ b/arch/x86/cpu/start64.S
> @@ -13,6 +13,11 @@
>  .globl _start
>  .type _start, @function
>  _start:
> +#if defined(CONFIG_X86_RUN_64BIT_ONLY)
> +       jmp     init_64bit_entry
> +.globl init_64bit_entry_ret
> +init_64bit_entry_ret:
> +#endif

Would it be safe to do this always? Is that a standard register to
have the HOB pointer be in? If so, we could always store it. We could
also make sure that U-Boot passes it on too.

Note that U-Boot has a struct arch_spl_handoff which is how it passes
the HOB through.

>         /* Set up memory using the existing stack */
>         mov     %rsp, %rdi
>         call    board_init_f_alloc_reserve
> --
> 2.20.1
>

Regards,
Simon

Hi Simon,

> -----Original Message-----
> From: Simon Glass <sjg at chromium.org>
> Sent: Sunday, April 26, 2020 1:16 PM
> To: Park, Aiden <aiden.park at intel.com>
> Cc: Bin Meng <bmeng.cn at gmail.com>; U-Boot Mailing List <u-
> boot at lists.denx.de>
> Subject: Re: [PATCH 2/8] x86: start64: Add a hook at 64-bit entry
> 
> Hi Aiden,
> 
> On Tue, 21 Apr 2020 at 18:45, <aiden.park at intel.com> wrote:
> >
> > From: Aiden Park <aiden.park at intel.com>
> >
> > This will allow a board or cpu to do its specific initialization at
> > 64-bit entry if U-Boot is a pure 64-bit binary.
> >
> > Signed-off-by: Aiden Park <aiden.park at intel.com>
> > ---
> >  arch/x86/cpu/start64.S | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/x86/cpu/start64.S b/arch/x86/cpu/start64.S index
> > 7be834788b..b8ac5aab57 100644
> > --- a/arch/x86/cpu/start64.S
> > +++ b/arch/x86/cpu/start64.S
> > @@ -13,6 +13,11 @@
> >  .globl _start
> >  .type _start, @function
> >  _start:
> > +#if defined(CONFIG_X86_RUN_64BIT_ONLY)
> > +       jmp     init_64bit_entry
> > +.globl init_64bit_entry_ret
> > +init_64bit_entry_ret:
> > +#endif
> 
> Would it be safe to do this always? Is that a standard register to have the HOB
> pointer be in? If so, we could always store it. We could also make sure that U-
> Boot passes it on too.
Unfortunately, it's not. This is to cover pre-stage firmware's calling convention.
The calling convention of 64-bit Slim Bootloader is that HOB address is in rcx.

> 
> Note that U-Boot has a struct arch_spl_handoff which is how it passes the HOB
> through.
Thanks for your information. Let me try to leverage arch_spl_handoff to pass HOB.

> 
> >         /* Set up memory using the existing stack */
> >         mov     %rsp, %rdi
> >         call    board_init_f_alloc_reserve
> > --
> > 2.20.1
> >
> 
> Regards,
> Simon

Best Regards,
Aiden