RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

Just FYI, the ECR for RISC-V would be released in UEFI spec v2.8C in Jan 2021. 
The draft one is now released in USWG website.

Abner

> -Original Message-
> From: Chang, Abner (HPS SW/FW Technologist)
> Sent: Monday, November 23, 2020 12:11 AM
> To: Atish Patra 
> Cc: Heinrich Schuchardt ; Ard Biesheuvel
> ; Atish Patra ; boot-
> architect...@lists.linaro.org; Grant Likely ; Rick Chen
> 
> Subject: RE: EBBR: RISC-V handoff to OS
> 
> The public release date is unsure yet. Some ECRs are still under discussion 
> for
> catching up with UEFI next release.
> Will let you know once I know it.
> 
> Abner
> 
> > -Original Message-
> > From: Atish Patra [mailto:ati...@atishpatra.org]
> > Sent: Sunday, November 22, 2020 4:27 PM
> > To: Chang, Abner (HPS SW/FW Technologist) 
> > Cc: Heinrich Schuchardt ; Ard Biesheuvel
> > ; Atish Patra ; boot-
> > architect...@lists.linaro.org; Grant Likely ;
> > Rick Chen 
> > Subject: Re: EBBR: RISC-V handoff to OS
> >
> > On Fri, Nov 20, 2020 at 10:48 PM Chang, Abner (HPS SW/FW Technologist)
> >  wrote:
> > >
> > > Hi Heinrich,
> > > This change will be published in UEFI spec 2.8 C and 2.9, FYI.
> > >
> >
> > That's awesome. Thanks for working on this. What is the public release
> > date for 2.8 C/2.9 ?
> >
> > > Abner
> > >
> > > > -Original Message-
> > > > From: Chang, Abner (HPS SW/FW Technologist)
> > > > Sent: Saturday, October 3, 2020 11:24 AM
> > > > To: Heinrich Schuchardt ; Ard Biesheuvel
> > > > 
> > > > Cc: Atish Patra ;
> > > > boot-architecture@lists.linaro.org;
> > > > Grant Likely ; Rick Chen
> > > > ; Atish Patra 
> > > > Subject: RE: EBBR: RISC-V handoff to OS
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > > > > Sent: Friday, September 25, 2020 10:49 PM
> > > > > To: Chang, Abner (HPS SW/FW Technologist)
> ;
> > > > Ard
> > > > > Biesheuvel 
> > > > > Cc: Atish Patra ;
> > > > > boot-architecture@lists.linaro.org;
> > > > > Grant Likely ; Rick Chen
> > > > > ; Atish Patra 
> > > > > Subject: Re: EBBR: RISC-V handoff to OS
> > > > >
> > > > > On 25.09.20 16:42, Chang, Abner (HPS SW/FW Technologist) wrote:
> > > > > >
> > > > > >
> > > > > >> -Original Message-
> > > > > >> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > > > > >> Sent: Friday, September 25, 2020 6:26 PM
> > > > > >> To: Chang, Abner (HPS SW/FW Technologist)
> > > > > >> ;
> > > > > Ard
> > > > > >> Biesheuvel 
> > > > > >> Cc: Atish Patra ;
> > > > > >> boot-architecture@lists.linaro.org;
> > > > > >> Grant Likely ; Rick Chen
> > > > > >> ; Atish Patra 
> > > > > >> Subject: Re: EBBR: RISC-V handoff to OS
> > > > > >>
> > > > > >> On 9/25/20 8:06 AM, Chang, Abner (HPS SW/FW Technologist)
> wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>>> -Original Message-
> > > > > >>>> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > > > > >>>> Sent: Thursday, September 24, 2020 8:43 PM
> > > > > >>>> To: Ard Biesheuvel 
> > > > > >>>> Cc: Chang, Abner (HPS SW/FW Technologist)
> > > > ;
> > > > > >>>> boot-architecture@lists.linaro.org; Atish Patra
> > > > > >>>> ; Rick Chen ;
> > > > > >>>> Atish Patra ; Grant Likely
> > > > > >>>> 
> > > > > >>>> Subject: Re: EBBR: RISC-V handoff to OS
> > > > > >>>>
> > > > > >>>> On 24.09.20 14:05, Ard Biesheuvel wrote:
> > > > > >>>>> On Thu, 24 Sep 2020 at 08:07, Heinrich Schuchardt
> > > > > >>>>> 
> > > > > >>>> wrote:
> > > > > >>>>>>
> > > > > >>>>>> On 9/24/20 5:35 AM, Chang, Abner (HPS SW/FW Technologist)
> > > > wrote:
>

RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

The public release date is unsure yet. Some ECRs are still under discussion for 
catching up with UEFI next release.
Will let you know once I know it.

Abner

> -Original Message-
> From: Atish Patra [mailto:ati...@atishpatra.org]
> Sent: Sunday, November 22, 2020 4:27 PM
> To: Chang, Abner (HPS SW/FW Technologist) 
> Cc: Heinrich Schuchardt ; Ard Biesheuvel
> ; Atish Patra ; boot-
> architect...@lists.linaro.org; Grant Likely ; Rick Chen
> 
> Subject: Re: EBBR: RISC-V handoff to OS
> 
> On Fri, Nov 20, 2020 at 10:48 PM Chang, Abner (HPS SW/FW Technologist)
>  wrote:
> >
> > Hi Heinrich,
> > This change will be published in UEFI spec 2.8 C and 2.9, FYI.
> >
> 
> That's awesome. Thanks for working on this. What is the public release date
> for 2.8 C/2.9 ?
> 
> > Abner
> >
> > > -Original Message-
> > > From: Chang, Abner (HPS SW/FW Technologist)
> > > Sent: Saturday, October 3, 2020 11:24 AM
> > > To: Heinrich Schuchardt ; Ard Biesheuvel
> > > 
> > > Cc: Atish Patra ;
> > > boot-architecture@lists.linaro.org;
> > > Grant Likely ; Rick Chen ;
> > > Atish Patra 
> > > Subject: RE: EBBR: RISC-V handoff to OS
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > > > Sent: Friday, September 25, 2020 10:49 PM
> > > > To: Chang, Abner (HPS SW/FW Technologist) ;
> > > Ard
> > > > Biesheuvel 
> > > > Cc: Atish Patra ;
> > > > boot-architecture@lists.linaro.org;
> > > > Grant Likely ; Rick Chen
> > > > ; Atish Patra 
> > > > Subject: Re: EBBR: RISC-V handoff to OS
> > > >
> > > > On 25.09.20 16:42, Chang, Abner (HPS SW/FW Technologist) wrote:
> > > > >
> > > > >
> > > > >> -Original Message-
> > > > >> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > > > >> Sent: Friday, September 25, 2020 6:26 PM
> > > > >> To: Chang, Abner (HPS SW/FW Technologist)
> > > > >> ;
> > > > Ard
> > > > >> Biesheuvel 
> > > > >> Cc: Atish Patra ;
> > > > >> boot-architecture@lists.linaro.org;
> > > > >> Grant Likely ; Rick Chen
> > > > >> ; Atish Patra 
> > > > >> Subject: Re: EBBR: RISC-V handoff to OS
> > > > >>
> > > > >> On 9/25/20 8:06 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
> > > > >>>
> > > > >>>
> > > > >>>> -Original Message-
> > > > >>>> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > > > >>>> Sent: Thursday, September 24, 2020 8:43 PM
> > > > >>>> To: Ard Biesheuvel 
> > > > >>>> Cc: Chang, Abner (HPS SW/FW Technologist)
> > > ;
> > > > >>>> boot-architecture@lists.linaro.org; Atish Patra
> > > > >>>> ; Rick Chen ;
> > > > >>>> Atish Patra ; Grant Likely
> > > > >>>> 
> > > > >>>> Subject: Re: EBBR: RISC-V handoff to OS
> > > > >>>>
> > > > >>>> On 24.09.20 14:05, Ard Biesheuvel wrote:
> > > > >>>>> On Thu, 24 Sep 2020 at 08:07, Heinrich Schuchardt
> > > > >>>>> 
> > > > >>>> wrote:
> > > > >>>>>>
> > > > >>>>>> On 9/24/20 5:35 AM, Chang, Abner (HPS SW/FW Technologist)
> > > wrote:
> > > > >>>>>>> Ok Heinrich, thanks for the clarification. I also read
> > > > >>>>>>> through this thread
> > > > >>>> again and understand the intention you would like to have
> > > > >>>> some sentences in the UEFI spec.
> > > > >>>>>>>
> > > > >>>>>>> I realize that we are trying to put sentences in the
> > > > >>>>>>> RISC-V calling
> > > > >>>> convention in UEFI spec to support the specific UEFI firmware
> > > > >>>> implementation of using gp/tp.
> > > > >>>>>>> Uboot UEFI firmware uses tp in HART to record the HART ID
> > > > >>>>>>> and uses gp
> &g

RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

Hi Heinrich,
This change will be published in UEFI spec 2.8 C and 2.9, FYI.

Abner

> -Original Message-
> From: Chang, Abner (HPS SW/FW Technologist)
> Sent: Saturday, October 3, 2020 11:24 AM
> To: Heinrich Schuchardt ; Ard Biesheuvel
> 
> Cc: Atish Patra ; boot-architecture@lists.linaro.org;
> Grant Likely ; Rick Chen ;
> Atish Patra 
> Subject: RE: EBBR: RISC-V handoff to OS
> 
> 
> 
> > -Original Message-
> > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > Sent: Friday, September 25, 2020 10:49 PM
> > To: Chang, Abner (HPS SW/FW Technologist) ;
> Ard
> > Biesheuvel 
> > Cc: Atish Patra ;
> > boot-architecture@lists.linaro.org;
> > Grant Likely ; Rick Chen ;
> > Atish Patra 
> > Subject: Re: EBBR: RISC-V handoff to OS
> >
> > On 25.09.20 16:42, Chang, Abner (HPS SW/FW Technologist) wrote:
> > >
> > >
> > >> -Original Message-----
> > >> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > >> Sent: Friday, September 25, 2020 6:26 PM
> > >> To: Chang, Abner (HPS SW/FW Technologist) ;
> > Ard
> > >> Biesheuvel 
> > >> Cc: Atish Patra ;
> > >> boot-architecture@lists.linaro.org;
> > >> Grant Likely ; Rick Chen
> > >> ; Atish Patra 
> > >> Subject: Re: EBBR: RISC-V handoff to OS
> > >>
> > >> On 9/25/20 8:06 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
> > >>>
> > >>>
> > >>>> -Original Message-
> > >>>> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > >>>> Sent: Thursday, September 24, 2020 8:43 PM
> > >>>> To: Ard Biesheuvel 
> > >>>> Cc: Chang, Abner (HPS SW/FW Technologist)
> ;
> > >>>> boot-architecture@lists.linaro.org; Atish Patra
> > >>>> ; Rick Chen ; Atish
> > >>>> Patra ; Grant Likely 
> > >>>> Subject: Re: EBBR: RISC-V handoff to OS
> > >>>>
> > >>>> On 24.09.20 14:05, Ard Biesheuvel wrote:
> > >>>>> On Thu, 24 Sep 2020 at 08:07, Heinrich Schuchardt
> > >>>>> 
> > >>>> wrote:
> > >>>>>>
> > >>>>>> On 9/24/20 5:35 AM, Chang, Abner (HPS SW/FW Technologist)
> wrote:
> > >>>>>>> Ok Heinrich, thanks for the clarification. I also read through
> > >>>>>>> this thread
> > >>>> again and understand the intention you would like to have some
> > >>>> sentences in the UEFI spec.
> > >>>>>>>
> > >>>>>>> I realize that we are trying to put sentences in the RISC-V
> > >>>>>>> calling
> > >>>> convention in UEFI spec to support the specific UEFI firmware
> > >>>> implementation of using gp/tp.
> > >>>>>>> Uboot UEFI firmware uses tp in HART to record the HART ID and
> > >>>>>>> uses gp
> > >>>> in the boot-HART to maintain the global data structure of uboot.
> > >>>>>>
> > >>>>>> tp is only used to store information on the secondary harts
> > >>>>>> which does not enter the UEFI payload. So for U-Boot the only
> > >>>>>> problematic register is gp.
> > >>> If you are using opensbi solution,  you should consider to use
> > >>> firmware
> > >> context mechanism because that is designed for any firmware
> > >> solutions to maintain its own data structure for any purposes.
> > >>
> > >> I will have a look at it.
> > > If you would like to know how do we define and initial the firmware
> > context, then you can check https://github.com/tianocore/edk2-
> > platforms/blob/master/Platform/RISC-
> > V/PlatformPkg/Universal/Sec/SecMain.c and
> > https://github.com/tianocore/edk2-platforms/blob/master/Silicon/RISC-
> > V/ProcessorPkg/Include/IndustryStandard/RiscVOpensbi.h.
> > > Thus the data structure you put in gp could be in firmware context,
> > > also
> > means that we don’t need that much constraints mentioned in UEFI spec.
> > > We can still submit that paragraph to USWG, but it would be hard to
> > remove it from UEFI spec if once day we don’t need it for the backward
> > compatibility.
> > >
> > >> Thanks for the link below.
> > > Below link is for the edk2 opensbi firmware extension

RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

> -Original Message-
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Friday, September 25, 2020 10:49 PM
> To: Chang, Abner (HPS SW/FW Technologist) ; Ard
> Biesheuvel 
> Cc: Atish Patra ; boot-architecture@lists.linaro.org;
> Grant Likely ; Rick Chen ;
> Atish Patra 
> Subject: Re: EBBR: RISC-V handoff to OS
> 
> On 25.09.20 16:42, Chang, Abner (HPS SW/FW Technologist) wrote:
> >
> >
> >> -Original Message-
> >> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> >> Sent: Friday, September 25, 2020 6:26 PM
> >> To: Chang, Abner (HPS SW/FW Technologist) ;
> Ard
> >> Biesheuvel 
> >> Cc: Atish Patra ;
> >> boot-architecture@lists.linaro.org;
> >> Grant Likely ; Rick Chen ;
> >> Atish Patra 
> >> Subject: Re: EBBR: RISC-V handoff to OS
> >>
> >> On 9/25/20 8:06 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
> >>>
> >>>
> >>>> -----Original Message-
> >>>> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> >>>> Sent: Thursday, September 24, 2020 8:43 PM
> >>>> To: Ard Biesheuvel 
> >>>> Cc: Chang, Abner (HPS SW/FW Technologist) ;
> >>>> boot-architecture@lists.linaro.org; Atish Patra
> >>>> ; Rick Chen ; Atish
> >>>> Patra ; Grant Likely 
> >>>> Subject: Re: EBBR: RISC-V handoff to OS
> >>>>
> >>>> On 24.09.20 14:05, Ard Biesheuvel wrote:
> >>>>> On Thu, 24 Sep 2020 at 08:07, Heinrich Schuchardt
> >>>>> 
> >>>> wrote:
> >>>>>>
> >>>>>> On 9/24/20 5:35 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
> >>>>>>> Ok Heinrich, thanks for the clarification. I also read through
> >>>>>>> this thread
> >>>> again and understand the intention you would like to have some
> >>>> sentences in the UEFI spec.
> >>>>>>>
> >>>>>>> I realize that we are trying to put sentences in the RISC-V
> >>>>>>> calling
> >>>> convention in UEFI spec to support the specific UEFI firmware
> >>>> implementation of using gp/tp.
> >>>>>>> Uboot UEFI firmware uses tp in HART to record the HART ID and
> >>>>>>> uses gp
> >>>> in the boot-HART to maintain the global data structure of uboot.
> >>>>>>
> >>>>>> tp is only used to store information on the secondary harts which
> >>>>>> does not enter the UEFI payload. So for U-Boot the only
> >>>>>> problematic register is gp.
> >>> If you are using opensbi solution,  you should consider to use
> >>> firmware
> >> context mechanism because that is designed for any firmware solutions
> >> to maintain its own data structure for any purposes.
> >>
> >> I will have a look at it.
> > If you would like to know how do we define and initial the firmware
> context, then you can check https://github.com/tianocore/edk2-
> platforms/blob/master/Platform/RISC-
> V/PlatformPkg/Universal/Sec/SecMain.c and
> https://github.com/tianocore/edk2-platforms/blob/master/Silicon/RISC-
> V/ProcessorPkg/Include/IndustryStandard/RiscVOpensbi.h.
> > Thus the data structure you put in gp could be in firmware context, also
> means that we don’t need that much constraints mentioned in UEFI spec.
> > We can still submit that paragraph to USWG, but it would be hard to
> remove it from UEFI spec if once day we don’t need it for the backward
> compatibility.
> >
> >> Thanks for the link below.
> > Below link is for the edk2 opensbi firmware extensions.
> >
> >>
> >>>
> >>>>>>
> >>>>>
> >>>>> Secondary CPUs could be used to invoke runtime services, though.
> >>>>>
> >>>>>>> The reason I can think of the reason to use tp/gp is because
> >>>>>>> S-Mode
> >>>> UEFI firmware (or S-mode payload?) is not able to get mhartid, so
> >>>> uboot stores HART ID in tp. Because there is nowhere to maintain
> >>>> the global data structure for uboot and the mscratch is occupied by
> >>>> opensbi, thus uboot uses gp to maintain the pointer to global context.
> >>>>>>> Because both tp and gp are non-privileged registers so uboot (or
> >>>>>>> payload?) can get the information f

RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

> -Original Message-
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Friday, September 25, 2020 6:26 PM
> To: Chang, Abner (HPS SW/FW Technologist) ; Ard
> Biesheuvel 
> Cc: Atish Patra ; boot-architecture@lists.linaro.org;
> Grant Likely ; Rick Chen ;
> Atish Patra 
> Subject: Re: EBBR: RISC-V handoff to OS
> 
> On 9/25/20 8:06 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
> >
> >
> >> -Original Message-
> >> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> >> Sent: Thursday, September 24, 2020 8:43 PM
> >> To: Ard Biesheuvel 
> >> Cc: Chang, Abner (HPS SW/FW Technologist) ;
> >> boot-architecture@lists.linaro.org; Atish Patra
> >> ; Rick Chen ; Atish Patra
> >> ; Grant Likely 
> >> Subject: Re: EBBR: RISC-V handoff to OS
> >>
> >> On 24.09.20 14:05, Ard Biesheuvel wrote:
> >>> On Thu, 24 Sep 2020 at 08:07, Heinrich Schuchardt
> >>> 
> >> wrote:
> >>>>
> >>>> On 9/24/20 5:35 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
> >>>>> Ok Heinrich, thanks for the clarification. I also read through
> >>>>> this thread
> >> again and understand the intention you would like to have some
> >> sentences in the UEFI spec.
> >>>>>
> >>>>> I realize that we are trying to put sentences in the RISC-V
> >>>>> calling
> >> convention in UEFI spec to support the specific UEFI firmware
> >> implementation of using gp/tp.
> >>>>> Uboot UEFI firmware uses tp in HART to record the HART ID and uses
> >>>>> gp
> >> in the boot-HART to maintain the global data structure of uboot.
> >>>>
> >>>> tp is only used to store information on the secondary harts which
> >>>> does not enter the UEFI payload. So for U-Boot the only problematic
> >>>> register is gp.
> > If you are using opensbi solution,  you should consider to use firmware
> context mechanism because that is designed for any firmware solutions to
> maintain its own data structure for any purposes.
> 
> I will have a look at it.
If you would like to know how do we define and initial the firmware context, 
then you can check 
https://github.com/tianocore/edk2-platforms/blob/master/Platform/RISC-V/PlatformPkg/Universal/Sec/SecMain.c
 and 
https://github.com/tianocore/edk2-platforms/blob/master/Silicon/RISC-V/ProcessorPkg/Include/IndustryStandard/RiscVOpensbi.h.
Thus the data structure you put in gp could be in firmware context, also means 
that we don’t need that much constraints mentioned in UEFI spec.
We can still submit that paragraph to USWG, but it would be hard to remove it 
from UEFI spec if once day we don’t need it for the backward compatibility.

>Thanks for the link below.
Below link is for the edk2 opensbi firmware extensions. 

> 
> >
> >>>>
> >>>
> >>> Secondary CPUs could be used to invoke runtime services, though.
> >>>
> >>>>> The reason I can think of the reason to use tp/gp is because
> >>>>> S-Mode
> >> UEFI firmware (or S-mode payload?) is not able to get mhartid, so
> >> uboot stores HART ID in tp. Because there is nowhere to maintain the
> >> global data structure for uboot and the mscratch is occupied by
> >> opensbi, thus uboot uses gp to maintain the pointer to global context.
> >>>>> Because both tp and gp are non-privileged registers so uboot (or
> >>>>> payload?) can get the information from those registers easily,
> >>>>> right? (But is this a security hole that any software can hack
> >>>>> tp/gp? However, this is the different topic, just ignore this)
> >>>>
> >>>> As said U-Boot restores value of gp when entered from UEFI via the
> API.
> >>>>
> >>>> We should do the same when serving interrupts and exceptions.
> >>>>
> >>>
> >>> When?
> >>>
> >>> We should carefully consider the difference between before-EBS and
> >>> after-EBS here:
> >>>
> >>> Before EBS:
> >>> Interrupt/exception handlers are owned by the UEFI firmware (Uboot
> >>> or EDK2). The OS or any other EFI payload must not interfere with
> >>> this, and only use function call interfaces to interact with the system.
> >>
> >> There is a gap in U-Boot for interrupts/exceptions before
> >> ExitBootServices() that I will have to close.
> >>
> >> Bes

RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

> -Original Message-
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Thursday, September 24, 2020 8:43 PM
> To: Ard Biesheuvel 
> Cc: Chang, Abner (HPS SW/FW Technologist) ;
> boot-architecture@lists.linaro.org; Atish Patra ; Rick
> Chen ; Atish Patra ; Grant
> Likely 
> Subject: Re: EBBR: RISC-V handoff to OS
> 
> On 24.09.20 14:05, Ard Biesheuvel wrote:
> > On Thu, 24 Sep 2020 at 08:07, Heinrich Schuchardt 
> wrote:
> >>
> >> On 9/24/20 5:35 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
> >>> Ok Heinrich, thanks for the clarification. I also read through this thread
> again and understand the intention you would like to have some sentences
> in the UEFI spec.
> >>>
> >>> I realize that we are trying to put sentences in the RISC-V calling
> convention in UEFI spec to support the specific UEFI firmware
> implementation of using gp/tp.
> >>> Uboot UEFI firmware uses tp in HART to record the HART ID and uses gp
> in the boot-HART to maintain the global data structure of uboot.
> >>
> >> tp is only used to store information on the secondary harts which
> >> does not enter the UEFI payload. So for U-Boot the only problematic
> >> register is gp.
If you are using opensbi solution,  you should consider to use firmware context 
mechanism because that is designed for any firmware solutions to maintain its 
own data structure for any purposes.

> >>
> >
> > Secondary CPUs could be used to invoke runtime services, though.
> >
> >>> The reason I can think of the reason to use tp/gp is because S-Mode
> UEFI firmware (or S-mode payload?) is not able to get mhartid, so uboot
> stores HART ID in tp. Because there is nowhere to maintain the global data
> structure for uboot and the mscratch is occupied by opensbi, thus uboot uses
> gp to maintain the pointer to global context.
> >>> Because both tp and gp are non-privileged registers so uboot (or
> >>> payload?) can get the information from those registers easily,
> >>> right? (But is this a security hole that any software can hack
> >>> tp/gp? However, this is the different topic, just ignore this)
> >>
> >> As said U-Boot restores value of gp when entered from UEFI via the API.
> >>
> >> We should do the same when serving interrupts and exceptions.
> >>
> >
> > When?
> >
> > We should carefully consider the difference between before-EBS and
> > after-EBS here:
> >
> > Before EBS:
> > Interrupt/exception handlers are owned by the UEFI firmware (Uboot or
> > EDK2). The OS or any other EFI payload must not interfere with this,
> > and only use function call interfaces to interact with the system.
> 
> There is a gap in U-Boot for interrupts/exceptions before
> ExitBootServices() that I will have to close.
> 
> Best regards
> 
> Heinrich
> 
> >
> > After EBS:
> > Interrupt/exception handlers are owned by the OS. The UEFI firmware
> > can be entered on any CPU with interrupts enabled or disabled, and the
> > UEFI firmware should not interfere with interrupt handling or
> > exception vectors etc.
> >
> >
> >
> >> Concerning security we have to remember that an UEFI payload has the
> >> same powers as the firmware itself. When it comes to hacking you have
> >> lost once you execute a hostile payload. What we can try to guard
> >> against to some degree are non-compliant payloads.
> >>
> >
> > Agreed. Everything runs at the same permission level, so any software
> > running under UEFI has the same powers as the UEFI firmware itself.
> >
> >>> Did we spec out above behavior in uboot RISC-V spec or the
> implementation design guide at somewhere? I am not quite familiar with
> uboot area though.
> >>
> >> The patch series
> >>
> >> doc: global data pointer
> >> INVALID URI REMOVED
> 3A__patchwork.ozlabs
> >> .org_project_uboot_list_-3Fseries-
> 3D202971=DwIFaQ=C5b8zRQO1miGmBe
> >>
> VZ2LFWg=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E=QMu
> q0JhboDWbE
> >> qbx6d4dZeXY2Pk0-PICJzRJKNT4wRY=UjTczoF1vjt5-
> uUzkvB6QFgGIsCUpuTMrSjX
> >> Zh8LbGA=
> >>
> >> starts closing the documentation gap in U-Boot.
> >>
> >>>
> >>> Another problem comes to my mind is even though we save gp/tp upon
> the entry of ExitBootService (or other UEFI APIs) and replaced with the
> uboot ones, what if the interrupt/exception happens and delegated to the
> payload event handler during ExitBootService (or oth

RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

Ok Heinrich, thanks for the clarification. I also read through this thread 
again and understand the intention you would like to have some sentences in the 
UEFI spec.

I realize that we are trying to put sentences in the RISC-V calling convention 
in UEFI spec to support the specific UEFI firmware implementation of using 
gp/tp.
Uboot UEFI firmware uses tp in HART to record the HART ID and uses gp in the 
boot-HART to maintain the global data structure of uboot. 
The reason I can think of the reason to use tp/gp is because S-Mode UEFI 
firmware (or S-mode payload?) is not able to get mhartid, so uboot stores HART 
ID in tp. Because there is nowhere to maintain the global data structure for 
uboot and the mscratch is occupied by opensbi, thus uboot uses gp to maintain 
the pointer to global context.
Because both tp and gp are non-privileged registers so uboot (or payload?) can 
get the information from those registers easily, right? (But is this a security 
hole that any software can hack tp/gp? However, this is the different topic, 
just ignore this)
Did we spec out above behavior in uboot RISC-V spec or the implementation 
design guide at somewhere? I am not quite familiar with uboot area though.

Another problem comes to my mind is even though we save gp/tp upon the entry of 
ExitBootService (or other UEFI APIs) and replaced with the uboot ones, what if 
the interrupt/exception happens and delegated to the payload event handler 
during ExitBootService (or other UEFI APIs)? The ownership is messed up at this 
point, right?

In edk2 RISC-V port, we use "firmware_context" in sbi_platforms which provided 
opensbi through mscratch to maintain the firmware specific context. With this, 
firmware can maintain its own data structure without bothering any other 
industrial specs. Because S-Mode firmware can't access to mhartid and  the 
sbi-scratch which is stored in mscratch, so we have Edk2OpensbiLib that 
registers the firmware specific sbi extension functions using "Firmware Code 
Base Specific SBI Extension Space, Extension Ids 0x0A00 through 0x0AFF" 
defined in sbi spec. That is a separate spec for RISC-V edk2 firmware sbi 
extension function (This reminds me I forget to document it). Then edk2 can get 
the necessary information using edk2 extension sbi call. 

You would agree with that we don’t have to mention the gp/tp usage in the 
calling convention just because of the uboot implementation. And we don’t have  
mention any connection/relationship between  gp/tp usage and the specific UEFI 
firmware implementation. The sentence must be also generic to other UEFI 
firmware solutions such as edk2 which doesn't care about destroying gp/tp (so 
far).

In the RISC-V assembly programmer's handbook in RISC-V spec, gp/tp are not 
given either the caller or callee to save the value, so we can spec out 
something in UEFI spec based on this calling convention.

The sentence which I consider reasonable is ,
"In view of gp and tp registers are not assigned the specific owner to save and 
restore their values in the calling convention (refer to "RISC-V assembly 
programmer's handbook" section in RISC-V Unprivileged ISA specification), UEFI 
firmware must not having assumption of owning the write access to these 
register at any circumstances such as in EFI Boot service, EFI Runtime service, 
EFI Management Mode service and in any UEFI firmware interfaces which may 
invoked by the external firmware payload,  or altering the values of gp/tp 
registers results in the interference in the asynchronous callback to the 
external firmware payload . Whether and how to preserve gp and tp during UEFI 
firmware environment is UEFI firmware implementation-specific. RISC-V platform 
firmware integrator should refer to the corresponding design specification of 
the particular UEFI firmware solution."

I believe this initial sentence still needs some revises, please just modify 
above paragraph if you don't like it. We can keep discussing this  based on 
above paragraph.

Thanks

> -Original Message-
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Thursday, September 24, 2020 2:20 AM
> To: Chang, Abner (HPS SW/FW Technologist) ;
> boot-architecture@lists.linaro.org; Atish Patra 
> Cc: Rick Chen ; Atish Patra ;
> Grant Likely ; Ard Biesheuvel 
> Subject: Re: EBBR: RISC-V handoff to OS
> 
> On 9/23/20 5:01 PM, Chang, Abner (HPS SW/FW Technologist) wrote:
> >
> >
> >> -Original Message-
> >> From: Chang, Abner (HPS SW/FW Technologist)
> >> Sent: Wednesday, September 23, 2020 10:55 PM
> >> To: 'Heinrich Schuchardt' ; boot-
> >> architect...@lists.linaro.org; Atish Patra 
> >> Cc: Rick Chen ; Atish Patra
> >> ; Grant Likely ; Ard
> >> Biesheuvel 
> >> Subject: RE: EBBR: RISC-V handoff to OS
> >>
> >>
> >>

RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

> -Original Message-
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Wednesday, September 23, 2020 3:42 PM
> To: Chang, Abner (HPS SW/FW Technologist) ;
> boot-architecture@lists.linaro.org; Atish Patra 
> Cc: Rick Chen ; Atish Patra ;
> Grant Likely ; Ard Biesheuvel 
> Subject: Re: EBBR: RISC-V handoff to OS
> 
> On 23.09.20 08:51, Chang, Abner (HPS SW/FW Technologist) wrote:
> >
> >
> >> -Original Message-
> >> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> >> Sent: Wednesday, September 23, 2020 2:18 PM
> >> To: Chang, Abner (HPS SW/FW Technologist) ;
> >> boot-architecture@lists.linaro.org; Atish Patra
> >> 
> >> Cc: Rick Chen ; Atish Patra
> >> ; Grant Likely ; Ard
> >> Biesheuvel 
> >> Subject: Re: EBBR: RISC-V handoff to OS
> >>
> >> On 9/23/20 7:24 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
> >>>
> >>>
> >>>> -----Original Message-
> >>>> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> >>>> Sent: Tuesday, September 22, 2020 5:30 PM
> >>>> To: boot-architecture@lists.linaro.org; Chang, Abner (HPS SW/FW
> >>>> Technologist) ; Atish Patra
> >>>> 
> >>>> Cc: boot-architecture@lists.linaro.org; Rick Chen
> >>>> ; Atish Patra ; Grant
> >>>> Likely ; Ard Biesheuvel 
> >>>> Subject: RE: EBBR: RISC-V handoff to OS
> >>>>
> >>>> Am 22. September 2020 08:30:57 MESZ schrieb "Chang, Abner (HPS
> >> SW/FW
> >>>> Technologist)" :
> >>>>>
> >>>>>
> >>>>>> -Original Message-----
> >>>>>> From: Atish Patra [mailto:ati...@atishpatra.org]
> >>>>>> Sent: Tuesday, September 22, 2020 2:08 PM
> >>>>>> To: Chang, Abner (HPS SW/FW Technologist)
> 
> >>>>>> Cc: Heinrich Schuchardt ; Atish Patra
> >>>>>> ; boot-architecture@lists.linaro.org; Grant
> >>>>> Likely
> >>>>>> ; Ard Biesheuvel ; Rick
> >> Chen
> >>>>>> 
> >>>>>> Subject: Re: EBBR: RISC-V handoff to OS
> >>>>>>
> >>>>>> On Mon, Sep 21, 2020 at 6:11 PM Chang, Abner (HPS SW/FW
> >>>>>> Technologist)  wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -Original Message-
> >>>>>>>> From: Atish Patra [mailto:ati...@atishpatra.org]
> >>>>>>>> Sent: Tuesday, September 22, 2020 2:28 AM
> >>>>>>>> To: Heinrich Schuchardt 
> >>>>>>>> Cc: Atish Patra ;
> >>>>>>>> boot-architecture@lists.linaro.org;
> >>>>>>>> Grant Likely ; Ard Biesheuvel
> >>>>>>>> ; Rick Chen ; Chang,
> >> Abner
> >>>>>> (HPS
> >>>>>>>> SW/FW Technologist) 
> >>>>>>>> Subject: Re: EBBR: RISC-V handoff to OS
> >>>>>>>>
> >>>>>>>> On Mon, Sep 21, 2020 at 9:23 AM Heinrich Schuchardt
> >>>>>>>>  wrote:
> >>>>>>>>>
> >>>>>>>>> Hello Atish,
> >>>>>>>>>
> >>>>>>>>> the UEFI spec has this sentence:
> >>>>>>>>>
> >>>>>>>>> "When UEFI firmware handoff control to OS, the RISC-V is
> >>>>> operated
> >>>>>>>>> in machine-mode privilege." (M-mode is the equivalent to EL3
> >>>>>>>>> in
> >>>>> ARM).
> >>>>>>> Yes, this is a pretty old section in UEFI spec even before
> >>>>>>> OpenSBI
> >>>>> as I can
> >>>>>> remember and haven't been updated to sync with latest status
> >>>>>> RISC-V
> >>>>> works.
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>> This does not make any sense to me when using a secure
> >>>>> execution
> >>>>>>>>> environement (SEE) like OpenSBI.
> >>>>>>>>>
> >>>>>>>>> The hand-off should occur in S-Mode if 

RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

> -Original Message-
> From: Chang, Abner (HPS SW/FW Technologist)
> Sent: Wednesday, September 23, 2020 10:55 PM
> To: 'Heinrich Schuchardt' ; boot-
> architect...@lists.linaro.org; Atish Patra 
> Cc: Rick Chen ; Atish Patra ;
> Grant Likely ; Ard Biesheuvel 
> Subject: RE: EBBR: RISC-V handoff to OS
> 
> 
> 
> > -Original Message-
> > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > Sent: Wednesday, September 23, 2020 3:42 PM
> > To: Chang, Abner (HPS SW/FW Technologist) ;
> > boot-architecture@lists.linaro.org; Atish Patra
> > 
> > Cc: Rick Chen ; Atish Patra ;
> > Grant Likely ; Ard Biesheuvel 
> > Subject: Re: EBBR: RISC-V handoff to OS
> >
> > On 23.09.20 08:51, Chang, Abner (HPS SW/FW Technologist) wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > >> Sent: Wednesday, September 23, 2020 2:18 PM
> > >> To: Chang, Abner (HPS SW/FW Technologist) ;
> > >> boot-architecture@lists.linaro.org; Atish Patra
> > >> 
> > >> Cc: Rick Chen ; Atish Patra
> > >> ; Grant Likely ; Ard
> > >> Biesheuvel 
> > >> Subject: Re: EBBR: RISC-V handoff to OS
> > >>
> > >> On 9/23/20 7:24 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
> > >>>
> > >>>
> > >>>> -Original Message-
> > >>>> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > >>>> Sent: Tuesday, September 22, 2020 5:30 PM
> > >>>> To: boot-architecture@lists.linaro.org; Chang, Abner (HPS SW/FW
> > >>>> Technologist) ; Atish Patra
> > >>>> 
> > >>>> Cc: boot-architecture@lists.linaro.org; Rick Chen
> > >>>> ; Atish Patra ; Grant
> > >>>> Likely ; Ard Biesheuvel 
> > >>>> Subject: RE: EBBR: RISC-V handoff to OS
> > >>>>
> > >>>> Am 22. September 2020 08:30:57 MESZ schrieb "Chang, Abner (HPS
> > >> SW/FW
> > >>>> Technologist)" :
> > >>>>>
> > >>>>>
> > >>>>>> -Original Message-
> > >>>>>> From: Atish Patra [mailto:ati...@atishpatra.org]
> > >>>>>> Sent: Tuesday, September 22, 2020 2:08 PM
> > >>>>>> To: Chang, Abner (HPS SW/FW Technologist)
> > 
> > >>>>>> Cc: Heinrich Schuchardt ; Atish Patra
> > >>>>>> ; boot-architecture@lists.linaro.org;
> > >>>>>> Grant
> > >>>>> Likely
> > >>>>>> ; Ard Biesheuvel ; Rick
> > >> Chen
> > >>>>>> 
> > >>>>>> Subject: Re: EBBR: RISC-V handoff to OS
> > >>>>>>
> > >>>>>> On Mon, Sep 21, 2020 at 6:11 PM Chang, Abner (HPS SW/FW
> > >>>>>> Technologist)  wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> -Original Message-
> > >>>>>>>> From: Atish Patra [mailto:ati...@atishpatra.org]
> > >>>>>>>> Sent: Tuesday, September 22, 2020 2:28 AM
> > >>>>>>>> To: Heinrich Schuchardt 
> > >>>>>>>> Cc: Atish Patra ;
> > >>>>>>>> boot-architecture@lists.linaro.org;
> > >>>>>>>> Grant Likely ; Ard Biesheuvel
> > >>>>>>>> ; Rick Chen ; Chang,
> > >> Abner
> > >>>>>> (HPS
> > >>>>>>>> SW/FW Technologist) 
> > >>>>>>>> Subject: Re: EBBR: RISC-V handoff to OS
> > >>>>>>>>
> > >>>>>>>> On Mon, Sep 21, 2020 at 9:23 AM Heinrich Schuchardt
> > >>>>>>>>  wrote:
> > >>>>>>>>>
> > >>>>>>>>> Hello Atish,
> > >>>>>>>>>
> > >>>>>>>>> the UEFI spec has this sentence:
> > >>>>>>>>>
> > >>>>>>>>> "When UEFI firmware handoff control to OS, the RISC-V is
> > >>>>> operated
> > >>>>>>>>> in machine-mode privilege." (M-mode is the equivalent to EL3
>

RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

> -Original Message-
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Wednesday, September 23, 2020 3:42 PM
> To: Chang, Abner (HPS SW/FW Technologist) ;
> boot-architecture@lists.linaro.org; Atish Patra 
> Cc: Rick Chen ; Atish Patra ;
> Grant Likely ; Ard Biesheuvel 
> Subject: Re: EBBR: RISC-V handoff to OS
> 
> On 23.09.20 08:51, Chang, Abner (HPS SW/FW Technologist) wrote:
> >
> >
> >> -Original Message-
> >> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> >> Sent: Wednesday, September 23, 2020 2:18 PM
> >> To: Chang, Abner (HPS SW/FW Technologist) ;
> >> boot-architecture@lists.linaro.org; Atish Patra
> >> 
> >> Cc: Rick Chen ; Atish Patra
> >> ; Grant Likely ; Ard
> >> Biesheuvel 
> >> Subject: Re: EBBR: RISC-V handoff to OS
> >>
> >> On 9/23/20 7:24 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
> >>>
> >>>
> >>>> -----Original Message-
> >>>> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> >>>> Sent: Tuesday, September 22, 2020 5:30 PM
> >>>> To: boot-architecture@lists.linaro.org; Chang, Abner (HPS SW/FW
> >>>> Technologist) ; Atish Patra
> >>>> 
> >>>> Cc: boot-architecture@lists.linaro.org; Rick Chen
> >>>> ; Atish Patra ; Grant
> >>>> Likely ; Ard Biesheuvel 
> >>>> Subject: RE: EBBR: RISC-V handoff to OS
> >>>>
> >>>> Am 22. September 2020 08:30:57 MESZ schrieb "Chang, Abner (HPS
> >> SW/FW
> >>>> Technologist)" :
> >>>>>
> >>>>>
> >>>>>> -Original Message-----
> >>>>>> From: Atish Patra [mailto:ati...@atishpatra.org]
> >>>>>> Sent: Tuesday, September 22, 2020 2:08 PM
> >>>>>> To: Chang, Abner (HPS SW/FW Technologist)
> 
> >>>>>> Cc: Heinrich Schuchardt ; Atish Patra
> >>>>>> ; boot-architecture@lists.linaro.org; Grant
> >>>>> Likely
> >>>>>> ; Ard Biesheuvel ; Rick
> >> Chen
> >>>>>> 
> >>>>>> Subject: Re: EBBR: RISC-V handoff to OS
> >>>>>>
> >>>>>> On Mon, Sep 21, 2020 at 6:11 PM Chang, Abner (HPS SW/FW
> >>>>>> Technologist)  wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -Original Message-
> >>>>>>>> From: Atish Patra [mailto:ati...@atishpatra.org]
> >>>>>>>> Sent: Tuesday, September 22, 2020 2:28 AM
> >>>>>>>> To: Heinrich Schuchardt 
> >>>>>>>> Cc: Atish Patra ;
> >>>>>>>> boot-architecture@lists.linaro.org;
> >>>>>>>> Grant Likely ; Ard Biesheuvel
> >>>>>>>> ; Rick Chen ; Chang,
> >> Abner
> >>>>>> (HPS
> >>>>>>>> SW/FW Technologist) 
> >>>>>>>> Subject: Re: EBBR: RISC-V handoff to OS
> >>>>>>>>
> >>>>>>>> On Mon, Sep 21, 2020 at 9:23 AM Heinrich Schuchardt
> >>>>>>>>  wrote:
> >>>>>>>>>
> >>>>>>>>> Hello Atish,
> >>>>>>>>>
> >>>>>>>>> the UEFI spec has this sentence:
> >>>>>>>>>
> >>>>>>>>> "When UEFI firmware handoff control to OS, the RISC-V is
> >>>>> operated
> >>>>>>>>> in machine-mode privilege." (M-mode is the equivalent to EL3
> >>>>>>>>> in
> >>>>> ARM).
> >>>>>>> Yes, this is a pretty old section in UEFI spec even before
> >>>>>>> OpenSBI
> >>>>> as I can
> >>>>>> remember and haven't been updated to sync with latest status
> >>>>>> RISC-V
> >>>>> works.
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>> This does not make any sense to me when using a secure
> >>>>> execution
> >>>>>>>>> environement (SEE) like OpenSBI.
> >>>>>>>>>
> >>>>>>>>> The hand-off should occur in S-Mode if 

RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

> -Original Message-
> From: Atish Patra [mailto:ati...@atishpatra.org]
> Sent: Wednesday, September 23, 2020 3:17 PM
> To: Chang, Abner (HPS SW/FW Technologist) 
> Cc: Heinrich Schuchardt ; boot-
> architect...@lists.linaro.org; Rick Chen ; Atish Patra
> ; Grant Likely ; Ard
> Biesheuvel 
> Subject: Re: EBBR: RISC-V handoff to OS
> 
> On Tue, Sep 22, 2020 at 11:51 PM Chang, Abner (HPS SW/FW Technologist)
>  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > > Sent: Wednesday, September 23, 2020 2:18 PM
> > > To: Chang, Abner (HPS SW/FW Technologist) ;
> > > boot-architecture@lists.linaro.org; Atish Patra
> > > 
> > > Cc: Rick Chen ; Atish Patra
> > > ; Grant Likely ; Ard
> > > Biesheuvel 
> > > Subject: Re: EBBR: RISC-V handoff to OS
> > >
> > > On 9/23/20 7:24 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
> > > >
> > > >
> > > >> -----Original Message-
> > > >> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > > >> Sent: Tuesday, September 22, 2020 5:30 PM
> > > >> To: boot-architecture@lists.linaro.org; Chang, Abner (HPS SW/FW
> > > >> Technologist) ; Atish Patra
> > > >> 
> > > >> Cc: boot-architecture@lists.linaro.org; Rick Chen
> > > >> ; Atish Patra ; Grant
> > > >> Likely ; Ard Biesheuvel 
> > > >> Subject: RE: EBBR: RISC-V handoff to OS
> > > >>
> > > >> Am 22. September 2020 08:30:57 MESZ schrieb "Chang, Abner (HPS
> > > SW/FW
> > > >> Technologist)" :
> > > >>>
> > > >>>
> > > >>>> -Original Message-
> > > >>>> From: Atish Patra [mailto:ati...@atishpatra.org]
> > > >>>> Sent: Tuesday, September 22, 2020 2:08 PM
> > > >>>> To: Chang, Abner (HPS SW/FW Technologist)
> 
> > > >>>> Cc: Heinrich Schuchardt ; Atish Patra
> > > >>>> ; boot-architecture@lists.linaro.org;
> > > >>>> Grant
> > > >>> Likely
> > > >>>> ; Ard Biesheuvel ; Rick
> > > Chen
> > > >>>> 
> > > >>>> Subject: Re: EBBR: RISC-V handoff to OS
> > > >>>>
> > > >>>> On Mon, Sep 21, 2020 at 6:11 PM Chang, Abner (HPS SW/FW
> > > >>>> Technologist)  wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>> -Original Message-
> > > >>>>>> From: Atish Patra [mailto:ati...@atishpatra.org]
> > > >>>>>> Sent: Tuesday, September 22, 2020 2:28 AM
> > > >>>>>> To: Heinrich Schuchardt 
> > > >>>>>> Cc: Atish Patra ;
> > > >>>>>> boot-architecture@lists.linaro.org;
> > > >>>>>> Grant Likely ; Ard Biesheuvel
> > > >>>>>> ; Rick Chen ; Chang,
> > > Abner
> > > >>>> (HPS
> > > >>>>>> SW/FW Technologist) 
> > > >>>>>> Subject: Re: EBBR: RISC-V handoff to OS
> > > >>>>>>
> > > >>>>>> On Mon, Sep 21, 2020 at 9:23 AM Heinrich Schuchardt
> > > >>>>>>  wrote:
> > > >>>>>>>
> > > >>>>>>> Hello Atish,
> > > >>>>>>>
> > > >>>>>>> the UEFI spec has this sentence:
> > > >>>>>>>
> > > >>>>>>> "When UEFI firmware handoff control to OS, the RISC-V is
> > > >>> operated
> > > >>>>>>> in machine-mode privilege." (M-mode is the equivalent to EL3
> > > >>>>>>> in
> > > >>> ARM).
> > > >>>>> Yes, this is a pretty old section in UEFI spec even before
> > > >>>>> OpenSBI
> > > >>> as I can
> > > >>>> remember and haven't been updated to sync with latest status
> > > >>>> RISC-V
> > > >>> works.
> > > >>>>>
> > > >>>>>>>
> > > >>>>>>> This does not make any sense to me when using a secur

RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

> -Original Message-
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Wednesday, September 23, 2020 2:18 PM
> To: Chang, Abner (HPS SW/FW Technologist) ;
> boot-architecture@lists.linaro.org; Atish Patra 
> Cc: Rick Chen ; Atish Patra ;
> Grant Likely ; Ard Biesheuvel 
> Subject: Re: EBBR: RISC-V handoff to OS
> 
> On 9/23/20 7:24 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
> >
> >
> >> -Original Message-
> >> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> >> Sent: Tuesday, September 22, 2020 5:30 PM
> >> To: boot-architecture@lists.linaro.org; Chang, Abner (HPS SW/FW
> >> Technologist) ; Atish Patra
> >> 
> >> Cc: boot-architecture@lists.linaro.org; Rick Chen
> >> ; Atish Patra ; Grant Likely
> >> ; Ard Biesheuvel 
> >> Subject: RE: EBBR: RISC-V handoff to OS
> >>
> >> Am 22. September 2020 08:30:57 MESZ schrieb "Chang, Abner (HPS
> SW/FW
> >> Technologist)" :
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: Atish Patra [mailto:ati...@atishpatra.org]
> >>>> Sent: Tuesday, September 22, 2020 2:08 PM
> >>>> To: Chang, Abner (HPS SW/FW Technologist) 
> >>>> Cc: Heinrich Schuchardt ; Atish Patra
> >>>> ; boot-architecture@lists.linaro.org; Grant
> >>> Likely
> >>>> ; Ard Biesheuvel ; Rick
> Chen
> >>>> 
> >>>> Subject: Re: EBBR: RISC-V handoff to OS
> >>>>
> >>>> On Mon, Sep 21, 2020 at 6:11 PM Chang, Abner (HPS SW/FW
> >>>> Technologist)  wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -Original Message-
> >>>>>> From: Atish Patra [mailto:ati...@atishpatra.org]
> >>>>>> Sent: Tuesday, September 22, 2020 2:28 AM
> >>>>>> To: Heinrich Schuchardt 
> >>>>>> Cc: Atish Patra ;
> >>>>>> boot-architecture@lists.linaro.org;
> >>>>>> Grant Likely ; Ard Biesheuvel
> >>>>>> ; Rick Chen ; Chang,
> Abner
> >>>> (HPS
> >>>>>> SW/FW Technologist) 
> >>>>>> Subject: Re: EBBR: RISC-V handoff to OS
> >>>>>>
> >>>>>> On Mon, Sep 21, 2020 at 9:23 AM Heinrich Schuchardt
> >>>>>>  wrote:
> >>>>>>>
> >>>>>>> Hello Atish,
> >>>>>>>
> >>>>>>> the UEFI spec has this sentence:
> >>>>>>>
> >>>>>>> "When UEFI firmware handoff control to OS, the RISC-V is
> >>> operated
> >>>>>>> in machine-mode privilege." (M-mode is the equivalent to EL3 in
> >>> ARM).
> >>>>> Yes, this is a pretty old section in UEFI spec even before OpenSBI
> >>> as I can
> >>>> remember and haven't been updated to sync with latest status RISC-V
> >>> works.
> >>>>>
> >>>>>>>
> >>>>>>> This does not make any sense to me when using a secure
> >>> execution
> >>>>>>> environement (SEE) like OpenSBI.
> >>>>>>>
> >>>>>>> The hand-off should occur in S-Mode if the CPU supports it and
> >>>>>>> only in M-Mode when the CPU only supports M-mode.
> >>>>>>>
> >>>>>> +Abner
> >>>>>>
> >>>>>> Yes. Abner has already submitted an ECR for this & few other
> >>> RISC-V
> >>>>>> related changes to UEFI spec. I am not sure about the current
> >>> status
> >>>> though.
> >>>>>>
> >>>>>> @Abner: Do you know the latest status ?
> >>>>> Yes, the ECR was submitted to USWG for review, however the
> meeting
> >>>>> canceled often recently and the process goes slow. I will keep
> >>>>> following up
> >>>>>
> >>>>>> Maybe you also attach the latest ECR here for a broader review.
> >>>>> I may not allowed to public ECR here unless all people in the
> >>> mailing
> >>>>> list are the members of UEFI org… but the sentence we revised in
> >>> ECR
> >>>>> is as below,
> >>>>>
> >>>>> &quo

RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

> -Original Message-
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Tuesday, September 22, 2020 5:30 PM
> To: boot-architecture@lists.linaro.org; Chang, Abner (HPS SW/FW
> Technologist) ; Atish Patra
> 
> Cc: boot-architecture@lists.linaro.org; Rick Chen ;
> Atish Patra ; Grant Likely ;
> Ard Biesheuvel 
> Subject: RE: EBBR: RISC-V handoff to OS
> 
> Am 22. September 2020 08:30:57 MESZ schrieb "Chang, Abner (HPS SW/FW
> Technologist)" :
> >
> >
> >> -Original Message-
> >> From: Atish Patra [mailto:ati...@atishpatra.org]
> >> Sent: Tuesday, September 22, 2020 2:08 PM
> >> To: Chang, Abner (HPS SW/FW Technologist) 
> >> Cc: Heinrich Schuchardt ; Atish Patra
> >> ; boot-architecture@lists.linaro.org; Grant
> >Likely
> >> ; Ard Biesheuvel ; Rick Chen
> >> 
> >> Subject: Re: EBBR: RISC-V handoff to OS
> >>
> >> On Mon, Sep 21, 2020 at 6:11 PM Chang, Abner (HPS SW/FW Technologist)
> >>  wrote:
> >> >
> >> >
> >> >
> >> > > -Original Message-
> >> > > From: Atish Patra [mailto:ati...@atishpatra.org]
> >> > > Sent: Tuesday, September 22, 2020 2:28 AM
> >> > > To: Heinrich Schuchardt 
> >> > > Cc: Atish Patra ;
> >> > > boot-architecture@lists.linaro.org;
> >> > > Grant Likely ; Ard Biesheuvel
> >> > > ; Rick Chen ; Chang, Abner
> >> (HPS
> >> > > SW/FW Technologist) 
> >> > > Subject: Re: EBBR: RISC-V handoff to OS
> >> > >
> >> > > On Mon, Sep 21, 2020 at 9:23 AM Heinrich Schuchardt
> >> > >  wrote:
> >> > > >
> >> > > > Hello Atish,
> >> > > >
> >> > > > the UEFI spec has this sentence:
> >> > > >
> >> > > > "When UEFI firmware handoff control to OS, the RISC-V is
> >operated
> >> > > > in machine-mode privilege." (M-mode is the equivalent to EL3 in
> >ARM).
> >> > Yes, this is a pretty old section in UEFI spec even before OpenSBI
> >as I can
> >> remember and haven't been updated to sync with latest status RISC-V
> >works.
> >> >
> >> > > >
> >> > > > This does not make any sense to me when using a secure
> >execution
> >> > > > environement (SEE) like OpenSBI.
> >> > > >
> >> > > > The hand-off should occur in S-Mode if the CPU supports it and
> >> > > > only in M-Mode when the CPU only supports M-mode.
> >> > > >
> >> > > +Abner
> >> > >
> >> > > Yes. Abner has already submitted an ECR for this & few other
> >RISC-V
> >> > > related changes to UEFI spec. I am not sure about the current
> >status
> >> though.
> >> > >
> >> > > @Abner: Do you know the latest status ?
> >> > Yes, the ECR was submitted to USWG for review, however the meeting
> >> > canceled often recently and the process goes slow. I will keep
> >> > following up
> >> >
> >> > > Maybe you also attach the latest ECR here for a broader review.
> >> > I may not allowed to public ECR here unless all people in the
> >mailing
> >> > list are the members of UEFI org… but the sentence we revised in
> >ECR
> >> > is as below,
> >> >
> >> > "When UEFI firmware handoff control to Supervisor mode OS, RISC-V
> >boot
> >> hart must be operated in Supervisor mode, and the memory addressing
> >> must be operated in Bare mode which is no memory address translation
> >or
> >> protection through the virtual page table entry."
> >> >
> >>
> >> Thanks.
> >>
> >> > We didn’t mention hand-off to M-Mode if CPU only support M-Mode
> >> because we only verified edk2 RISC-V port in S-Mode with OpenSBI, but
> >> didn’t try it on M-Mode even though the code is ready there.
> >> >
> >>
> >> That's correct. We can't run UEFI applications run time services in
> >M-mode as
> >> it requires virtual memory in current setup.
> >> I think it is better to keep that way there is a specific demand and
> >value in
> >> running UEFI applications in M-mode.
> >>
> >> > >
> >> > > > We should prescribe this in the EBBR and somehow get the 

RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

> -Original Message-
> From: Atish Patra [mailto:ati...@atishpatra.org]
> Sent: Tuesday, September 22, 2020 2:08 PM
> To: Chang, Abner (HPS SW/FW Technologist) 
> Cc: Heinrich Schuchardt ; Atish Patra
> ; boot-architecture@lists.linaro.org; Grant Likely
> ; Ard Biesheuvel ; Rick Chen
> 
> Subject: Re: EBBR: RISC-V handoff to OS
> 
> On Mon, Sep 21, 2020 at 6:11 PM Chang, Abner (HPS SW/FW Technologist)
>  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Atish Patra [mailto:ati...@atishpatra.org]
> > > Sent: Tuesday, September 22, 2020 2:28 AM
> > > To: Heinrich Schuchardt 
> > > Cc: Atish Patra ;
> > > boot-architecture@lists.linaro.org;
> > > Grant Likely ; Ard Biesheuvel
> > > ; Rick Chen ; Chang, Abner
> (HPS
> > > SW/FW Technologist) 
> > > Subject: Re: EBBR: RISC-V handoff to OS
> > >
> > > On Mon, Sep 21, 2020 at 9:23 AM Heinrich Schuchardt
> > >  wrote:
> > > >
> > > > Hello Atish,
> > > >
> > > > the UEFI spec has this sentence:
> > > >
> > > > "When UEFI firmware handoff control to OS, the RISC-V is operated
> > > > in machine-mode privilege." (M-mode is the equivalent to EL3 in ARM).
> > Yes, this is a pretty old section in UEFI spec even before OpenSBI as I can
> remember and haven't been updated to sync with latest status RISC-V works.
> >
> > > >
> > > > This does not make any sense to me when using a secure execution
> > > > environement (SEE) like OpenSBI.
> > > >
> > > > The hand-off should occur in S-Mode if the CPU supports it and
> > > > only in M-Mode when the CPU only supports M-mode.
> > > >
> > > +Abner
> > >
> > > Yes. Abner has already submitted an ECR for this & few other RISC-V
> > > related changes to UEFI spec. I am not sure about the current status
> though.
> > >
> > > @Abner: Do you know the latest status ?
> > Yes, the ECR was submitted to USWG for review, however the meeting
> > canceled often recently and the process goes slow. I will keep
> > following up
> >
> > > Maybe you also attach the latest ECR here for a broader review.
> > I may not allowed to public ECR here unless all people in the mailing
> > list are the members of UEFI org… but the sentence we revised in ECR
> > is as below,
> >
> > "When UEFI firmware handoff control to Supervisor mode OS, RISC-V boot
> hart must be operated in Supervisor mode, and the memory addressing
> must be operated in Bare mode which is no memory address translation or
> protection through the virtual page table entry."
> >
> 
> Thanks.
> 
> > We didn’t mention hand-off to M-Mode if CPU only support M-Mode
> because we only verified edk2 RISC-V port in S-Mode with OpenSBI, but
> didn’t try it on M-Mode even though the code is ready there.
> >
> 
> That's correct. We can't run UEFI applications run time services in M-mode as
> it requires virtual memory in current setup.
> I think it is better to keep that way there is a specific demand and value in
> running UEFI applications in M-mode.
> 
> > >
> > > > We should prescribe this in the EBBR and somehow get the UEFI spec
> > > > fixed afterwards.
> > > >
> > >
> > > I will add it to the RISC-V EBBR PR (haven't sent it yet).
> > >
> > > > An other issue is the calling convention. Chapter "2.3.7.3
> > > > Detailed Calling Convention" does not describe which registers are
> > > > saved by the UEFI payload's entry point and restored by the
> > > > payload before calling the UEFI API or returning to the UEFI
> > > > payload. This concerns especially registers gp (x3) and tp (x4).
> > > >
> > > > Into the EBBR or UEFI spec we should put a link to the "RISC-V ELF
> > > > psABI specification"
> > > > https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf
> > > > .md which is referenced by "The RISC-V Instruction Set Manual".
> > > >
> > > > From the "RISC-V ELF psABI specification" one might conclude that
> > > > the UEFI payload should not be allowed to change gp and tp before
> > > > calling
> > > > ExitBootServices() or SetVirtualAddressMap() whichever occurs last.
> > > >
> > >
> > > Agreed. Thanks for pointing this out. I think this should go into
> > > the UEFI spec instead o

RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

> -Original Message-
> From: Chang, Abner (HPS SW/FW Technologist)
> Sent: Tuesday, September 22, 2020 9:11 AM
> To: Atish Patra ; Heinrich Schuchardt
> 
> Cc: Atish Patra ; boot-architecture@lists.linaro.org;
> Grant Likely ; Ard Biesheuvel ;
> Rick Chen 
> Subject: RE: EBBR: RISC-V handoff to OS
> 
> 
> 
> > -Original Message-
> > From: Atish Patra [mailto:ati...@atishpatra.org]
> > Sent: Tuesday, September 22, 2020 2:28 AM
> > To: Heinrich Schuchardt 
> > Cc: Atish Patra ;
> > boot-architecture@lists.linaro.org;
> > Grant Likely ; Ard Biesheuvel ;
> > Rick Chen ; Chang, Abner (HPS SW/FW Technologist)
> > 
> > Subject: Re: EBBR: RISC-V handoff to OS
> >
> > On Mon, Sep 21, 2020 at 9:23 AM Heinrich Schuchardt
> >  wrote:
> > >
> > > Hello Atish,
> > >
> > > the UEFI spec has this sentence:
> > >
> > > "When UEFI firmware handoff control to OS, the RISC-V is operated in
> > > machine-mode privilege." (M-mode is the equivalent to EL3 in ARM).
> Yes, this is a pretty old section in UEFI spec even before OpenSBI as I can
> remember and haven't been updated to sync with latest status RISC-V works.
> 
> > >
> > > This does not make any sense to me when using a secure execution
> > > environement (SEE) like OpenSBI.
> > >
> > > The hand-off should occur in S-Mode if the CPU supports it and only
> > > in M-Mode when the CPU only supports M-mode.
> > >
> > +Abner
> >
> > Yes. Abner has already submitted an ECR for this & few other RISC-V
> > related changes to UEFI spec. I am not sure about the current status
> though.
> >
> > @Abner: Do you know the latest status ?
> Yes, the ECR was submitted to USWG for review, however the meeting
> canceled often recently and the process goes slow. I will keep following up
> 
> > Maybe you also attach the latest ECR here for a broader review.
> I may not allowed to public ECR here unless all people in the mailing list are
> the members of UEFI org… but the sentence we revised in ECR is as below,
> 
> "When UEFI firmware handoff control to Supervisor mode OS, RISC-V boot
> hart must be operated in Supervisor mode, and the memory addressing
> must be operated in Bare mode which is no memory address translation or
> protection through the virtual page table entry."
> 
> We didn’t mention hand-off to M-Mode if CPU only support M-Mode
> because we only verified edk2 RISC-V port in S-Mode with OpenSBI, but
> didn’t try it on M-Mode even though the code is ready there.
> 
> >
> > > We should prescribe this in the EBBR and somehow get the UEFI spec
> > > fixed afterwards.
> > >
> >
> > I will add it to the RISC-V EBBR PR (haven't sent it yet).
> >
> > > An other issue is the calling convention. Chapter "2.3.7.3 Detailed
> > > Calling Convention" does not describe which registers are saved by
> > > the UEFI payload's entry point and restored by the payload before
> > > calling the UEFI API or returning to the UEFI payload. This concerns
> > > especially registers gp (x3) and tp (x4).
> > >
> > > Into the EBBR or UEFI spec we should put a link to the "RISC-V ELF
> > > psABI specification"
> > > https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.m
> > > d which is referenced by "The RISC-V Instruction Set Manual".
> > >
> > > From the "RISC-V ELF psABI specification" one might conclude that
> > > the UEFI payload should not be allowed to change gp and tp before
> > > calling
> > > ExitBootServices() or SetVirtualAddressMap() whichever occurs last.
> > >
> >
> > Agreed. Thanks for pointing this out. I think this should go into the
> > UEFI spec instead of EBBR spec. Any suggestions ?
> To have this external link is good, I will add this link in ECR.
I add below sentence at the end of section 2.3.7.3.
" See “Link to UEFI Specification-Related Document” on https://uefi.org/uefi 
under the heading “RISC-EFL psABI Specification” for the more descriptions of 
RISC-V calling convention."

> >
> > > Due to this missing clarification U-Boot is currently saving gp
> > > before calling the entry point of the payload and restores it on
> > > reentry or on entry of an API call. Nothing is done for tp.
> > >
> > > Best regards
> > >
> > > Heinrich
> > >
> > > ___
> > > boot-architecture mailing list
> > > boot-architecture@lists.linaro.org
> > > https://lists.linaro.org/mailman/listinfo/boot-architecture
> >
> >
> >
> > --
> > Regards,
> > Atish
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

RE: EBBR: RISC-V handoff to OS

[Chang, Abner (HPS SW/FW Technologist)]

> -Original Message-
> From: Atish Patra [mailto:ati...@atishpatra.org]
> Sent: Tuesday, September 22, 2020 2:28 AM
> To: Heinrich Schuchardt 
> Cc: Atish Patra ; boot-architecture@lists.linaro.org;
> Grant Likely ; Ard Biesheuvel ;
> Rick Chen ; Chang, Abner (HPS SW/FW Technologist)
> 
> Subject: Re: EBBR: RISC-V handoff to OS
> 
> On Mon, Sep 21, 2020 at 9:23 AM Heinrich Schuchardt
>  wrote:
> >
> > Hello Atish,
> >
> > the UEFI spec has this sentence:
> >
> > "When UEFI firmware handoff control to OS, the RISC-V is operated in
> > machine-mode privilege." (M-mode is the equivalent to EL3 in ARM).
Yes, this is a pretty old section in UEFI spec even before OpenSBI as I can 
remember and haven't been updated to sync with latest status RISC-V works.

> >
> > This does not make any sense to me when using a secure execution
> > environement (SEE) like OpenSBI.
> >
> > The hand-off should occur in S-Mode if the CPU supports it and only in
> > M-Mode when the CPU only supports M-mode.
> >
> +Abner
> 
> Yes. Abner has already submitted an ECR for this & few other RISC-V related
> changes to UEFI spec. I am not sure about the current status though.
> 
> @Abner: Do you know the latest status ?
Yes, the ECR was submitted to USWG for review, however the meeting canceled 
often recently and the process goes slow. I will keep following up

> Maybe you also attach the latest ECR here for a broader review.
I may not allowed to public ECR here unless all people in the mailing list are 
the members of UEFI org… but the sentence we revised in ECR is as below,

"When UEFI firmware handoff control to Supervisor mode OS, RISC-V boot hart 
must be operated in Supervisor mode, and the memory addressing must be operated 
in Bare mode which is no memory address translation or protection through the 
virtual page table entry."

We didn’t mention hand-off to M-Mode if CPU only support M-Mode because we only 
verified edk2 RISC-V port in S-Mode with OpenSBI, but didn’t try it on M-Mode 
even though the code is ready there.

> 
> > We should prescribe this in the EBBR and somehow get the UEFI spec
> > fixed afterwards.
> >
> 
> I will add it to the RISC-V EBBR PR (haven't sent it yet).
> 
> > An other issue is the calling convention. Chapter "2.3.7.3 Detailed
> > Calling Convention" does not describe which registers are saved by the
> > UEFI payload's entry point and restored by the payload before calling
> > the UEFI API or returning to the UEFI payload. This concerns
> > especially registers gp (x3) and tp (x4).
> >
> > Into the EBBR or UEFI spec we should put a link to the "RISC-V ELF
> > psABI specification"
> > https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md
> > which is referenced by "The RISC-V Instruction Set Manual".
> >
> > From the "RISC-V ELF psABI specification" one might conclude that the
> > UEFI payload should not be allowed to change gp and tp before calling
> > ExitBootServices() or SetVirtualAddressMap() whichever occurs last.
> >
> 
> Agreed. Thanks for pointing this out. I think this should go into the UEFI 
> spec
> instead of EBBR spec. Any suggestions ?
To have this external link is good, I will add this link in ECR.
> 
> > Due to this missing clarification U-Boot is currently saving gp before
> > calling the entry point of the payload and restores it on reentry or
> > on entry of an API call. Nothing is done for tp.
> >
> > Best regards
> >
> > Heinrich
> >
> > ___
> > boot-architecture mailing list
> > boot-architecture@lists.linaro.org
> > https://lists.linaro.org/mailman/listinfo/boot-architecture
> 
> 
> 
> --
> Regards,
> Atish
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

RE: Adding RISC-V to EBBR

[Chang, Abner (HPS SW/FW Technologist)]

From: François Ozog [mailto:francois.o...@linaro.org]
Sent: Thursday, August 20, 2020 6:19 PM
To: Chang, Abner (HPS SW/FW Technologist) 
Cc: Ard Biesheuvel ; Atish Patra ; 
Grant Likely ; Boot Architecture Mailman List 
; Anup Patel ; David 
Abdurachmanov ; Palmer Dabbelt 
; Heinrich Schuchardt ; Schaefer, 
Daniel 
Subject: Re: Adding RISC-V to EBBR

Hi,

before commenting the proposal, I'd like to share my views on boot architecture.

I sense we are at an inflection point for the role of firmware, moving away 
from "let's start the OS as fast as possible" to "let's continue to do so but 
also provide additional (trust related) services".
So I envision the set of components that brings the OS up and offer (trust) 
services to OS/hypervisor/VMs/containers as a distinct logical software layer 
that I named "Trusted Substrate". This layer sits between silicon and 
OS/hypervisor. The services go beyond UEFI Runtime Services and may actually 
reside in protected worlds (which are implemented in various ways in different 
architectures - for instance in the Arm TrustZone, Intel Management Engine or 
in SGX isolated components).


In that context the "contract" between firmware and OS (mostly UEFI) is just 
one aspect of the boot architecture which should be specified in EBBR.


On Thu, 20 Aug 2020 at 10:55, Chang, Abner (HPS SW/FW Technologist) 
mailto:abner.ch...@hpe.com>> wrote:
I would suggest this,
1. Move ebbr to be managed under UEFi.org. Rename it to UEFI embedded base  
boot requirement.
I would say there are companion ECRs to the one you refer below that tried to 
do that. We are working on new version with additional explanations on the 
**whys** we propose the ECRs.
EBBR will continue to refer to UEFI parts (and UEFI section in EBBR shall 
shrink as we progress on the UEFI.org specification) but will go beyond UEFI as 
I described above for the Trusted Substrate and would need per architecture 
sections (trust services implementation).
So EBBR shall stay independent from UEFI.
[Abner]
Yes. I agree with you at this point. That depends on how do we position EBBR. 
EBBR should stay with UEFI if EBBR is only firmware requirements of how 
embedded system leverage UEFI firmware.
If it goes beyond UEFI firmware, then for sure it doesn’t have to be stayed in 
UEFI. Juts move UEFI stuff from EBBR to UEFI spec and make it as the reference 
in EBBR.

Is "Trusted Substrate" an ongoing task which someone is working on it and 
adding to EBBR? Or it is just a thought?
I don’t know the detail of "Trusted Substrate",  however I assume that is an 
abstract spec  and  firmware code base independent?

2. Add the section in UEFi EBBR for the  different archs, such as ARM and 
RISC-V.
3. Trim some spec mentioned in ebbr and move it to uefi/pi spec if the spec is 
generic to multiple archs.
One example is the Device Tree guid for DTB installed in EFI configuration 
table. Samer from ARM had ECR for this, but I suggest to pull out entire DT 
section from EBBR to UEFI spec because that is generic for both ARM and RISC-V. 
We also had an UEFI ECR for RISC-V in which we mention refer to EFI 
configuration table section for installing DTB.

Abner

Get Outlook for Android<https://aka.ms/ghei36>

From: Ard Biesheuvel mailto:a...@kernel.org>>
Sent: Thursday, August 20, 2020 2:45:38 PM
To: Atish Patra mailto:ati...@atishpatra.org>>; Grant 
Likely mailto:grant.lik...@arm.com>>; François Ozog 
mailto:francois.o...@linaro.org>>
Cc: Boot Architecture Mailman List 
mailto:boot-architecture@lists.linaro.org>>;
 Anup Patel mailto:a...@brainfault.org>>; David 
Abdurachmanov 
mailto:david.abdurachma...@gmail.com>>; Palmer 
Dabbelt mailto:pal...@dabbelt.com>>; Heinrich Schuchardt 
mailto:xypron.g...@gmx.de>>; Chang, Abner (HPS SW/FW 
Technologist) mailto:abner.ch...@hpe.com>>; Schaefer, 
Daniel mailto:daniel.schae...@hpe.com>>
Subject: Re: Adding RISC-V to EBBR

(+ Grant, Francois)

On Thu, 20 Aug 2020 at 02:04, Atish Patra 
mailto:ati...@atishpatra.org>> wrote:
>
> Hi All,
> We are interested in adopting EBBR as the boot specification for the
> embedded RISC-V platforms.
> We firmly believe that EBBR is a very well defined specification for
> boot requirement and there
> is no need for reinventing the wheel for RISC-V. Hence, this is a
> thread to discuss all the requirements
> for adding RISC-V to EBBR.  Here is my current understanding. Please
> correct me if I am wrong.
>
> Logistic Requirement:
> 1. As per the contribution guidelines[1], patches should be sent to
> boot-architecture@lists.linaro.org<mailto:boot-architecture@lists.linaro.org>.
> and the specification will be hosted under "ARM-software" Github.
> I am hoping that introducing RISC-V
> related changes are okay with t

Re: Adding RISC-V to EBBR

[Chang, Abner (HPS SW/FW Technologist)]

I would suggest this,
1. Move ebbr to be managed under UEFi.org. Rename it to UEFI embedded base  
boot requirement.
2. Add the section in UEFi EBBR for the  different archs, such as ARM and 
RISC-V.
3. Trim some spec mentioned in ebbr and move it to uefi/pi spec if the spec is 
generic to multiple archs.
One example is the Device Tree guid for DTB installed in EFI configuration 
table. Samer from ARM had ECR for this, but I suggest to pull out entire DT 
section from EBBR to UEFI spec because that is generic for both ARM and RISC-V. 
We also had an UEFI ECR for RISC-V in which we mention refer to EFI 
configuration table section for installing DTB.

Abner

Get Outlook for Android<https://aka.ms/ghei36>

From: Ard Biesheuvel 
Sent: Thursday, August 20, 2020 2:45:38 PM
To: Atish Patra ; Grant Likely ; 
François Ozog 
Cc: Boot Architecture Mailman List ; Anup 
Patel ; David Abdurachmanov 
; Palmer Dabbelt ; Heinrich 
Schuchardt ; Chang, Abner (HPS SW/FW Technologist) 
; Schaefer, Daniel 
Subject: Re: Adding RISC-V to EBBR

(+ Grant, Francois)

On Thu, 20 Aug 2020 at 02:04, Atish Patra  wrote:
>
> Hi All,
> We are interested in adopting EBBR as the boot specification for the
> embedded RISC-V platforms.
> We firmly believe that EBBR is a very well defined specification for
> boot requirement and there
> is no need for reinventing the wheel for RISC-V. Hence, this is a
> thread to discuss all the requirements
> for adding RISC-V to EBBR.  Here is my current understanding. Please
> correct me if I am wrong.
>
> Logistic Requirement:
> 1. As per the contribution guidelines[1], patches should be sent to
> boot-architecture@lists.linaro.org.
> and the specification will be hosted under "ARM-software" Github.
> I am hoping that introducing RISC-V
> related changes are okay with the current maintainers.
> 2. The specification is licensed under Creative Commons. The RISC-V
> related changes will refer to
> some of the RISC-V specifications as well. AFAIK, there shouldn't
> be an issue with that.
> 3. It should be okay to add other copyrights in addition to "Arm
> Limited and Contributors".
>
> Technical Requirement:
> 1. Software status:
> a. UEFI support for RISC-V Linux kernel is already available in
> the mailing list[2]. The targeted upstream
> merge is the 5.10 merge window.
> b. U-Boot already supports UEFI for RISC-V.
> c. EDK2 upstreaming is currently under progress [3] as well.
>
>   Is it okay to start sending patches for EBBR RISC-V related changes
> now or do we need to wait for EDK2 and Linux
>   kernel patches to be available upstream ?
>
> 2. RISC-V related sections in EBBR
> a. UEFI:
> Currently, RISC-V doesn't support a  EFI_RESET_SYSTEM boot
> service as firmware doesn't have a standard way
> to reset the system. There is a proposal to add a system reset
> function to Supervisor Binary Specification(SBI) which
> can be mapped to EFI_RESET_SYSTEM by the firmware. Apart from
> that, I believe RISC-V supports all UEFI boot and
> run time services mandated by EBBR. Is it a blocker for RISC-V
> EBBR compatibility?
> b. RISC-V Multiprocessor Startup Protocol: This section will
> contain the details of booting protocol for RISC-V and mandatory
> RISC-V specifications that need to be implemented.
> c. Firmware Storage: AFAIK, RISC-V platforms are already
> compatible with this.
>
> Please let me know if I missed something or oversimplified any
> requirement. We want to make RISC-V compatible with EBBR
> sooner than later and ready work on any missing pieces if any.
>
> [1] https://github.com/ARM-software/ebbr/blob/master/CONTRIBUTING.rst
> [2] https://lkml.org/lkml/2020/8/19/1252
> [3] 
> https://edk2.groups.io/g/devel/message/63831?p=,,,20,0,0,0::Created,,RISC-V,20,2,0,76053051
> [4] 
> https://lists.riscv.org/g/tech-unixplatformspec/message/49?p=,,,20,0,0,0::relevance,,Add+system+reset+extension,20,2,0,73235534
>
> --
> Regards,
> Atish
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

RE: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables

[Chang, Abner (HPS SW/FW Technologist)]

> -Original Message-
> From: Udit Kumar [mailto:udit.ku...@nxp.com]
> Sent: Wednesday, May 02, 2018 12:31 PM
> To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com>; Ard
> Biesheuvel <ard.biesheu...@linaro.org>
> Cc: Architecture Mailman List <boot-architecture@lists.linaro.org>; arm.ebbr-
> disc...@arm.com
> Subject: RE: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent
> variables
> 
> > > Also, eMMC controllers (which are more widely used on mobile
> > > platforms as the only available storage controller) use DMA under
> > > the OS, which complicates things even further when attempting to
> > > share such a controller between the OS and the firmware.
> > Agree with this. May need other implementations like cache in memory
> > during boot service and write back to partition by OS for this case.
> 
> Do you mean, firmware will treat boot media as read-only. And any write to
> device should be done by OS itself .
Yes. during runtime for EFI Variable in media case.

> few questions on this
> 1/ Interface between OS and firmware
The only interface is SetVariable (). However, return meaningful EFI status to 
tell OS it has to write EFI variable by itself.

> 2/ At run time, if there is any update in UEFI variables,  how to trigger OS 
> for
> update
There is no way to trigger OS to do the update in EFI Variable driver. This is 
also the piece I do not have clear idea for EFI variable in media case so far. 
The only possible solution could be return EFI_UNSUPPORTED (instead of 
EFI_DEVICE_ERROR) in SetVariable() during runtime. Then somehow OS maintains 
EFI variable by its own way. However, in order to support unified OS, SFW will 
have to pass some information of EFI variable to OS. Such as where is the EFI 
Variable located, what's the protocol to access to EFI Variable and etc.


___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

RE: DT handling, [Ref Linux-Efi]

[Chang, Abner (HPS SW/FW Technologist)]

> -Original Message-
> From: Udit Kumar [mailto:udit.ku...@nxp.com]
> Sent: Wednesday, May 02, 2018 12:26 PM
> To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com>;
> Alexander Graf <ag...@suse.de>; William Mills <wmi...@ti.com>
> Cc: boot-architecture@lists.linaro.org; n...@arm.com; Rod Dorris
> <rod.dor...@nxp.com>; arm.ebbr-disc...@arm.com
> Subject: RE: DT handling, [Ref Linux-Efi]
> 
> > We probably don't need to provide a genetic DT driver in UEFI U-Boot,
> > instead, we will have to mention how SoC/platform vendors publish
> > DTB/DTBO in EBBR spec.
> > For example,
> > The EFI_CONFIGURATION_TABLE in EFI System table could be used to
> > publish the pointer to DTB and DTBO. Declare two GUIDs in EBBR, one
> > for DTB another for DTBO. OS boot loader is responsible to merge
> > DTB/DTBO according DTB/DTBO discovered in EFI Configuration Table. To
> > read DT from EFI variable into memory, memory map to DT in EEPROM or
> > other mechanisms is platform implementation. No matter which approach,
> > DT producer has to create configuration table in EFI system table
> > follow the data structure defined in EBBR.
> > Another way instead of using GUID in configuration table is to publish
> > DTB/DTBO in EFI device path, this way is more UEFI oriented IMO.
> > However, we have to defined corresponding device path node in UEFI
> > spec for DT. Similar to using system configuration table. DT producer
> > has to install EFI device path for either DTB or DTBO. Then OS boot
> > loaders locate those EFI device paths of DTB and DTBO and merge it.
> 
> We are adding a requirement on OS boot loaders to merge it.
> IMO, merging should be done by firmware itself.
> In case, we want to host multiple distribution at same time, then this is 
> likely
> to go with OS boot loaders

That is fine to merge DT by firmware, we still can standardize how UBoot merges 
DT in EBBR. For example, SoC and other platform UBoot drivers produce their DT 
or DTO in their own drivers. UBoot provides a centralized EFI DT driver to 
collect DT/DTO from either EFI system configuration table or EFI device path. 
Then this centralized EFI DT driver produces the pointer to point to final DT 
in EFI system configuration table. OS boot loader cab just check EFI system 
configuration table to retrieve DT, something like this.

Abner
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

RE: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables

[Chang, Abner (HPS SW/FW Technologist)]

Hi Ard,

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Sunday, April 29, 2018 12:21 AM
> To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com>
> Cc: Daniel Thompson <daniel.thomp...@linaro.org>; Grant Likely
> <grant.lik...@arm.com>; Architecture Mailman List  architect...@lists.linaro.org>; l...@cam-list1.cambridge.arm.com;
> b...@cam-list1.cambridge.arm.com; arm.ebbr-disc...@arm.com
> Subject: Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent
> variables
> 
> On 28 April 2018 at 15:46, Chang, Abner (HPS SW/FW Technologist)
> <abner.ch...@hpe.com> wrote:
> > I am behind this topic and not familiar with embedded system with U-boot.
> Some dumb questions below.
> > Why there is no persistent storage on platform? I thought at least EEPROM
> is on platform. Can't EEPROM be the varstore for EFI variable? Or EEPROM is
> not allowed to write when during runtime? If EEPROM is not possible to be
> varstore, how about a region from on-board fixed storage? To simulate a
> partition as EFI varstore from on-platform storage for EFI variable 
> read/write.
> > And what is the problem that U-boot can't support SetVariable invoked by
> OS in runtime?
> >
> > One comment to support EFI variable in U-Boot is to refer to the
> implementation in EDK2 EFI variable.
> > In EDK2 variable design, another protocol "Firmware Volume Block
> Protocol" which defined in EFI PI (Platform Initialization spec ) is used as 
> the
> abstract layer to abstract storage mechanism from EFI variable driver. The
> underlying implementation of FVB protocol could access to any kind of
> storage, such as non-volatile flash, memory, disk or any, that is platform-
> specific implementation. We probably can apply the same concept of PI spec
> and edk2 variable implementation on U-Boot UEFI implementation. U-Boot
> Just provide the generic EFI Variable complaint driver and leave varstore
> implementation to platform designer.
> 
> The limitations are not in the software but in the hardware. Embedded or
> mobile platforms typically only have a single storage device that sits behind 
> a
> controller that is either owned by the firmware or by the OS, but not by both
> at the same time. MMC even has boot partitions and RPMB partitions
> beyond the primary storage area so that boot images, file systems and
> secure storage can all share the same flash device.
> 
> The same applies to EEPROMs on I2C: unless the platform has been carefully
> architected so that the I2C bus that hosts the EEPROM can be owned by the
> firmware entirely, you end up in a similar situation where both the firmware
> and the OS need to access MMIO control registers, and the UEFI spec does
> not provide any means of arbitration between the two.
> 
> Therefore, it makes little sense to try and reason about which piece of
> software does what and whether it is generic or provided by the platform.

Normally  firmware doesn’t access to varstore initiatively after 
ExitBootService. We actually can treat Runtime SetVariable () as part of OS 
driver. Just make sure the pointers used in runtime variable driver (and in 
firmware block driver) are translated to OS virtual address correctly. Also OS 
probably has to invoke SetVriable() in critical section or in higher priority 
threat. Then it should be ok to access to varstore under OS if low level FVB 
driver doesn’t reconfigure controller for varstore accesses. But access to 
varstore in MMC in both boot time and runtime is more complicated though, 
perhaps cache it in memory is more easier for varstore in partition case.


___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

RE: DT handling, [Ref Linux-Efi]

[Chang, Abner (HPS SW/FW Technologist)]

Some thoughts,

> -Original Message-
> From: arm.ebbr-discuss-boun...@arm.com [mailto:arm.ebbr-discuss-
> boun...@arm.com] On Behalf Of Udit Kumar
> Sent: Saturday, April 28, 2018 4:07 PM
> To: Alexander Graf ; William Mills 
> Cc: boot-architecture@lists.linaro.org; n...@arm.com; Rod Dorris
> ; arm.ebbr-disc...@arm.com
> Subject: Re: [Arm.ebbr-discuss] DT handling, [Ref Linux-Efi]
> 
> 
> Hi Alex
> 
> > -Original Message-
> > From: Alexander Graf [mailto:ag...@suse.de]
> > Sent: Friday, April 27, 2018 1:18 PM
> > To: Udit Kumar ; William Mills 
> > Cc: boot-architecture@lists.linaro.org; n...@arm.com; Rod Dorris
> > ; arm.ebbr-disc...@arm.com
> > Subject: Re: DT handling, [Ref Linux-Efi]
> >
> >
> >
> > On 27.04.18 08:24, Udit Kumar wrote:
> > > Hi
> > > There is bit of discussion on linux-efi too , to handle DT update
> > >
> > > I guess some members of this forum are active there too.
> > >
> > >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw
> > > ww
> > > .spinics.net%2Flists%2Flinux-
> efi%2Fmsg13700.html=02%7C01%7Cudit
> > > .k
> > >
> >
> umar%40nxp.com%7Cd320a10fef8446e2aec308d5ac132cd3%7C686ea1d3bc2
> b
> > 4c6fa9
> > >
> >
> 2cd99c5c301635%7C0%7C0%7C636604120716683231=USXfARVLtgi2um
> i
> > %2BSw
> > > LxLwJPqiDztVuNGpTGz09T0q0%3D=0
> > >
> > > To summaries
> > > 1/ Ownership of DTB
> > > IMO should be firmware and we should retain this ownership in EBBR
> > > as well, Any objections/thoughts ?
> >
> > I fully agree. On top of that we need to make clear that backward and
> > forward compatibility are not optional.
> 
> This will be on kernel drivers,  not to break the contract.
> 
> > For that I think we may need to actually give people workable
> > solutions to create device trees that are compatible with multiple levels of
> kernel support.
> > The main areas I'm aware of that keep breaking are:
> >
> >   * fine grained interrupt controller support
> >   * clock support
> >   * power domain support
> >   * pinctrl support
> 
> In-line with similar problems I am facing currently, new kernel doesn't boot
> with old uefi firmware.
> Kernel device tree is updated and therefore driver is, the combination of old
> device tree and new kernel is not working, This comes down to mainly on
> management of device trees.
> Here if we consider, firmware and kernel development is independent
> then driver should run with same level of functions with new kernel and old
> device tree.
> New functions/binding added in driver couldn't be used.
> 
> > Every time a device tree changes in any of the above, that usually
> > ends up in backwards incompatibility.
> >
> > My idea to solve that would be to basically create a device tree that
> > has self- contained overlays that only trigger when certain feature strings
> are available.
> 
> This will be good, but can we predict what will be overlays ?
> 
> > That way the base device tree could for example contain fixed clocks,
> > but an overlay can get applied when the clock driver is enabled in the
> > kernel configuration. That overlay would then enable the kernel to drive
> clocks.
> 
> With assumption, firmware has nothing to fix for overlays.
> i.e clock-frequency (if given in overlay)
> 
> > Further down, we could even extend dtc with annotations that indicate
> > "this property should only be exposed when feature string X is
> > available" to not force people to write overlays inside the device tree.
> >
> > >
> > > Update
> > > 1/ Updating whole device tree from OS [Capsule update can be used ]
> >
> > I think the device tree should be part of firmware. If you need to
> > update it, update your firmware (or a firmware specific method, not
> specified by EBBR).
> 
> Edk2, supports DTB as part of firmware and separate data blob as well..
> I think, this is work in progress by Bhupesh to update only DTB.
> 
> > > 2/ Just modifying the device tree DTBO
> >
> > Yes, dtbo support in the boot chain definitely makes sense.
> >
> > > My preferred way to handle DTBO in firmware will be
> > >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fs
> > > ou
> > >
> >
> rce.android.com%2Fdevices%2Farchitecture%2Fdto%2Fmultiple=02%7
> C0
> > 1
> > >
> >
> %7Cudit.kumar%40nxp.com%7Cd320a10fef8446e2aec308d5ac132cd3%7C686
> e
> > a1d3b
> > >
> >
> c2b4c6fa92cd99c5c301635%7C0%7C0%7C636604120716683231=a8rseb
> > EngRA
> > > dKP%2Fs3wFSfqMHYrOf4hn6JNfQpXdFgzU%3D=0
> > > See picture Runtime DTO implementation for multiple DTs
> > >
> > > To store this information in partition, options we have 1/ Run time
> > > variables
> >
> > You mean EFI variables? We could certainly have a driver in firmware
> > that reads certain EFI variables to apply dtbos from.
> 
> Yes,  there will be a need of generic driver which reads variable and merge
> DTB and DTBO.

We probably don't need to provide a genetic DT driver in UEFI U-Boot, 

RE: Question about EBBR

[Chang, Abner (HPS SW/FW Technologist)]

Understand now, thanks Dong, Daniel and Grant. That is the UEFI U-Boot port for 
embedded system. edk2 is not the only implementation for UEFI on embedded 
system segment.

Thanks

-Original Message-
From: Grant Likely [mailto:grant.lik...@arm.com] 
Sent: Friday, April 27, 2018 6:03 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com>
Cc: arm.ebbr-discuss <arm.ebbr-disc...@arm.com>; 
boot-architecture@lists.linaro.org
Subject: Re: Question about EBBR

Hi Abner,

Answers below...

On 27/04/2018 07:06, Chang, Abner (HPS SW/FW Technologist) wrote:
> Not sure if this mail list works or not.
>
> Hi Grant,
> GiIbert (from HPE, I think he is also in the mail list) and I are new to this 
> discussion thread . Here are couple questions for you, your answer can give 
> us the clear plan of EBBR spec.
>
> 1. I see EBBR spec on ARM web site, however seems it was released in last 
> Sep. Any newer version of this spec?

As Dong said, there is no newer version of the spec. The copy on the Arm 
website is only a draft release. The feedback we received on it was we need a 
more open process for this spec; hence this group.

> 2. The purpose of EBBR is to standardize embedded system firmware on 
> different processor archs and also intends abstract platform-specific 
> implementations?

The purpose of EBBR is to standardize the firmware interface for different 
platforms of the same architecture so that OS distributions can support 
multiple boards. For example, the SUSE AArch64 image should be able to boot on 
any EBBR compliant AArch64 platform (providing the SoC is supported in the SUSE 
kernel).

Originally EBBR was only intended to address Arm platforms, but after receiving 
interest from other architectures we've expanded the scope.

EBBR builds on existing specs, so it doesn't define a new firmware interface. 
Rather, it starts with the UEFI spec and adds additional requirements that are 
relevant for the embedded market.

> 3. EBBR aligns embedded SWF with UEFI spec (minimum requirements) and 
> leverage EDK2 implementation on uBoot?
>   3-1  That is to use uBoot to initialize and boot system, but uBoot 
> mimics UEFI protocols and EFI system table then boot to UEFI OS boot loader?
>   3-2  Or, Uboot could be one of EDK2 packages, wrap the necessary Uboot 
> drivers into UEFI protocols (like the UEFI binding on top of uBoot)  and 
> build it using EDK2 build process then generate EDK2 format system firmware?
>
> 3-2 makes more sense to me but not sure which one is EBBR intention. I 
> may have more question if the intention of EBBR is 3-2. :)
3-1 is the intent. EBBR specifies UEFI, but doesn't say anything about 
implementation. U-Boot implements a subset of the UEFI spec which is completely 
independed from EDK2/Tianocore. A vendor can produce an EBBR compliant system 
using either U-Boot or EDK2/Tianocore.

The first release of EBBR (level 0) will specify a subset of UEFI compliance. 
The intent is to reflect what is currently implemented in the U-Boot project. 
Therefore, a vendor who is currently using U-Boot firmware has an easy 
migration path to become EBBR compliant.

UEFI support in U-Boot is rapidly evolving, so I expect future revisions of 
EBBR (level 1 and onwards) to require a larger subset of UEFI, with the 
ultimate goal of being 100% compliant to the UEFI spec.

As you'll have gathered from the meeting, handling of persistent variables is 
an important topic right now. The UEFI spec requires the
GetVariable()/SetVariable() runtime services to work, but U-Boot does not yet 
have the ability to set variables at runtime. Similarly,
Tianocore/EDK2 on the 96Boards HiKey doesn't support setting variable at all. 
Therefore, EBBR needs to define the behaviour of firmware when
SetVariable() does not work.

Cheers,
g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture