Re: [edk2] [PATCH] ArmPlatformPkg: remove ArmGetCpuCountPerCluster () from ArmPlatformLib

[Ard Biesheuvel]

On 24 November 2017 at 17:04, Leif Lindholm  wrote:
> On Wed, Nov 15, 2017 at 02:20:48PM +, Ard Biesheuvel wrote:
>> The only user of ArmPlatformLib's ArmGetCpuCountPerCluster () is itself
>> an ArmPlatformLib implementation, i.e., ArmVExpressLibRTSM.
>>
>> Given that we'd prefer to get rid of ArmPlatformLib entirely, let's
>> remove ArmGetCpuCountPerCluster () from the API as a first step.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>
> I'm thinking this is technically a bit iffy. But the less iffy way
> would be to add a local .h file to hold the prototype, which feels a
> bit crazy for a transitional thing. So:
> Reviewed-by: Leif Lindholm 
>

Thanks

Pushed as 4cebe0453fea40330afb6b8f2372287e723e6e3f
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] ACPI table HID/CID allocation

[Andrew Fish]

> On Nov 25, 2017, at 4:56 AM, Udit Kumar  wrote:
> 
> 
> 
>> -Original Message-
>> From: Daniel Thompson [mailto:daniel.thomp...@linaro.org]
>> Sent: Thursday, November 23, 2017 1:42 AM
>> To: Ard Biesheuvel 
>> Cc: Udit Kumar ; Leif Lindholm
>> ; edk2-devel@lists.01.org; Varun Sethi
>> ; Graeme Gregory 
>> Subject: Re: [RFC] ACPI table HID/CID allocation
>> 
> 
>>> 
>>> PRP0001 + compatible was invented to avoid the need to allocate a _HID
>>> for each and every component in existence that can already be
>>> identified by a DT compatible string (and little else except, e.g., a
>>> I2C slave address) and is not deeply engrained in the SoC in terms of
>>> clock tree, power states etc. So while internal/external may not be
>>> the most accurate distinction, it is still a useful one IMHO.
>> 
>> Hmnnn it sounds like jedec,spi-nor meets this test.
>> 
>> There is only one property in the DT bindings that describes the device
>> itself (fast read support) rather than its "bus address" (chip select,
>> frequency). Further, that single property is obsolete, at least for
>> Linux; the kernel driver now contains a quirks tables to look up by
>> device ID whether fast read is supported and will use that on non-DT
>> systems (and also to censor broken DT systems ;-) ).
> 
> 
> You mean, this more on bus frame work, how to probe slave. 
> Example rtc-ds3232.c , when is spi mode just need name 
> but for i2c mode it needs of_match_table
> 

Udit,

I think it is more like you only need ACPI if you don't have a driver. If it is 
standard bus with standard drivers the OS code can do power management without 
any help from ACPI. In general ACPI exists to abstract chipsets that don't have 
OS drivers, or mother board layout of power plains, GPIOs, etc. 

Thanks,

Andrew Fish


> Thanks 
> Udit 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] Delete BdsLib dependency from Android loaders

[Leif Lindholm]

On Sat, Nov 25, 2017 at 03:25:21PM +, Ard Biesheuvel wrote:
> On 25 November 2017 at 13:27, Leif Lindholm  wrote:
> > AndroidBoot and AndroidFastboot (as well as their shared component
> > AndroidBootImgLib) have minor dependencies on BdsLib.
> >
> > First fix up a missing mapping in EmbeddedPkg.dsc to let the modules
> > build standalone. Then get rid of the use of BdsLib.
> >
> > Leif Lindholm (2):
> >   EmbeddedPkg: add UefiRuntimeLib resolution to package .dsc
> >   EmbeddedPkg: get rid of BdsLib dependency from Android*Boot
> >
> 
> Reviewed-by: Ard Biesheuvel 

Thanks!
Pushed as 108ff4a04b..a64d587294.

/
Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Enabling boot menu via serial & PXE boot in CorebootPayloadPkg

[You, Benjamin]

Hi Cameron,

BTW, please use debug build for Coreboot Payload, such that debug
information can be shown in serial console from the very early stage in the
Payload's execution. This would help validating the functioning of serial.

Thanks,

- ben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of You,
> Benjamin
> Sent: Saturday, November 25, 2017 11:25 PM
> To: Cameron Craig ; 'edk2-devel@lists.01.org'
> 
> Subject: Re: [edk2] Enabling boot menu via serial & PXE boot in
> CorebootPayloadPkg
> 
> Hi Cameron,
> 
> CorebootPayloadPkg does support serial output as user interface. To enable
> serial, the CorebootPayloadPkg retrieves serial information from Coreboot
> through CorebootModulePkg\Library\CbParseLib\CbParseLib.c =>
> CbParseSerialInfo(), which is called by CorebootPayloadPkg\Library\
> PlatformHookLib\PlatformHookLib.c => PlatformHookSerialPortInitialize(),
> which is in turn called by CorebootModulePkg\Library\BaseSerialPortLib16550
> \BaseSerialPortLib16550.c ==> SerialPortInitialize().
> 
> Have you seen serial output info during Coreboot? If the answer is no, then
> Coreboot should be tweaked. If the answer is yes, but you cannot see serial
> output in Coreboot Payload, then probably the above call sequence needs to
> be checked. If you do not have a debugger, one way to trace code flow is to
> insert raw serial outputs in the code flow. This should be doable since
> Coreboot already does serial output. Once the serial output functions
> correctly in the Coreboot Payload, Boot Menu / UI through serial should be
> automatically supported.
> 
> On networking, you might refer to the Minnow Board v3 source tree, at
> https://github.com/tianocore/edk2-platforms/tree/devel-MinnowBoard3-
> UDK2017
> 
> Minnow Board v3 uses the same SOC as Leaf Hill. You might look at
> Platform/BroxtonPlatformPkg/PlatformPkg.fdf file for a reference on which
> components are used for network / PXE.
> 
> Thanks,
> 
> - ben
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Cameron Craig
> > Sent: Friday, November 24, 2017 5:16 PM
> > To: 'edk2-devel@lists.01.org' 
> > Subject: [edk2] Enabling boot menu via serial & PXE boot in
> CorebootPayloadPkg
> >
> > Hi all,
> >
> > I'm new to this list and new to edk2 integration.
> > Currently I'm working on an Intel Leaf Hill CRB, attempting to produce a
> > coreboot payload consisting of a Tianocore EDKII UDK 2017 UEFI boot
> manager.
> >
> > I have basic functionality, but a few useful features are currently missing 
> > from
> > my build:
> >
> > 1. User interface via serial.
> > We will not have the luxury of a video output so need to be able to navigate
> the
> > boot menu etc. via serial.
> > In an ideal world I would be looking for a Boolean value to toggle :) But I
> > imagine there might be a little more to it.
> >
> > 2. PXE Boot.
> > So far I have sources and built an UNDI driver and pinged a local network
> device.
> > I have also attempted to enable the necessary features for PXE boot [1].
> > But I get an error message:
> > ```
> > $ ipconfig
> > MAC Address: 
> > Broadcast MAC: FF FF FF FF FF FF
> > ipconfig: Locate protocol error: 'PXE base code protocol'
> > ```
> > So I'm thinking some drivers are not being loaded?
> >
> > Any suggestions for enabling these features would be greatly appreciated.
> >
> > [1] https://github.com/tianocore/tianocore.github.io/wiki/NetworkPkg-
> > Getting-Started-Guide -> FEATURES ENABLING
> >
> > Cheers,
> > Cameron
> >
> >
> > Cameron Craig | Graduate Software Engineer | Exterity Limited
> > tel: +44 1383 828 250 | fax:  | mobile:
> > e: cameron.cr...@exterity.com | w: www.exterity.com
> >
> > Exterity is a leading provider of IP Video and Digital Signage solutions 
> > that
> helps
> > organizations to harness the power of video to communicate, educate and
> > entertain. Our end-to-end solutions enable you to take TV and video content
> > directly from any source and manage its delivery, live or on demand, to any
> > connected device via your existing network. For more information or to
> > schedule a product demonstration, contact Exterity on +44(0)1383 828 250 or
> > visit www.exterity.com
> >
> > Legal Notice
> > Unless expressly stated otherwise, this message is confidential and may be
> > privileged. It is intended for the addressee(s) only. Access to this e-mail 
> > by
> > anyone else is unauthorized. If you are not an addressee, any disclosure or
> > copying of the contents of this e-mail or any action taken (or not taken) in
> > reliance on it is unauthorized and may be unlawful. If you are not an 
> > addressee,
> > please inform the sender immediately.
> >
> > Exterity Limited is registered in Scotland under No. 225313 with its 
> > registered
> > office at Ridge Way, Hillend Industrial Park, Dalgety Bay, KY11 9JD.
> >
> >
> >
> 

Re: [edk2] [PATCH 0/2] Delete BdsLib dependency from Android loaders

[Ard Biesheuvel]

On 25 November 2017 at 13:27, Leif Lindholm  wrote:
> AndroidBoot and AndroidFastboot (as well as their shared component
> AndroidBootImgLib) have minor dependencies on BdsLib.
>
> First fix up a missing mapping in EmbeddedPkg.dsc to let the modules
> build standalone. Then get rid of the use of BdsLib.
>
> Leif Lindholm (2):
>   EmbeddedPkg: add UefiRuntimeLib resolution to package .dsc
>   EmbeddedPkg: get rid of BdsLib dependency from Android*Boot
>

Reviewed-by: Ard Biesheuvel 

>  EmbeddedPkg/Application/AndroidBoot/AndroidBootApp.c | 4 ++--
>  EmbeddedPkg/Application/AndroidBoot/AndroidBootApp.inf   | 1 -
>  EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c | 1 -
>  EmbeddedPkg/EmbeddedPkg.dsc  | 7 ++-
>  EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.inf  | 1 +
>  5 files changed, 5 insertions(+), 9 deletions(-)
>
> --
> 2.11.0
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Enabling boot menu via serial & PXE boot in CorebootPayloadPkg

[You, Benjamin]

Hi Cameron,

CorebootPayloadPkg does support serial output as user interface. To enable
serial, the CorebootPayloadPkg retrieves serial information from Coreboot 
through CorebootModulePkg\Library\CbParseLib\CbParseLib.c => 
CbParseSerialInfo(), which is called by CorebootPayloadPkg\Library\
PlatformHookLib\PlatformHookLib.c => PlatformHookSerialPortInitialize(), 
which is in turn called by CorebootModulePkg\Library\BaseSerialPortLib16550
\BaseSerialPortLib16550.c ==> SerialPortInitialize(). 

Have you seen serial output info during Coreboot? If the answer is no, then 
Coreboot should be tweaked. If the answer is yes, but you cannot see serial
output in Coreboot Payload, then probably the above call sequence needs to 
be checked. If you do not have a debugger, one way to trace code flow is to
insert raw serial outputs in the code flow. This should be doable since 
Coreboot already does serial output. Once the serial output functions
correctly in the Coreboot Payload, Boot Menu / UI through serial should be 
automatically supported.

On networking, you might refer to the Minnow Board v3 source tree, at
https://github.com/tianocore/edk2-platforms/tree/devel-MinnowBoard3-UDK2017

Minnow Board v3 uses the same SOC as Leaf Hill. You might look at 
Platform/BroxtonPlatformPkg/PlatformPkg.fdf file for a reference on which 
components are used for network / PXE.

Thanks,

- ben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Cameron Craig
> Sent: Friday, November 24, 2017 5:16 PM
> To: 'edk2-devel@lists.01.org' 
> Subject: [edk2] Enabling boot menu via serial & PXE boot in CorebootPayloadPkg
> 
> Hi all,
> 
> I'm new to this list and new to edk2 integration.
> Currently I'm working on an Intel Leaf Hill CRB, attempting to produce a
> coreboot payload consisting of a Tianocore EDKII UDK 2017 UEFI boot manager.
> 
> I have basic functionality, but a few useful features are currently missing 
> from
> my build:
> 
> 1. User interface via serial.
> We will not have the luxury of a video output so need to be able to navigate 
> the
> boot menu etc. via serial.
> In an ideal world I would be looking for a Boolean value to toggle :) But I
> imagine there might be a little more to it.
> 
> 2. PXE Boot.
> So far I have sources and built an UNDI driver and pinged a local network 
> device.
> I have also attempted to enable the necessary features for PXE boot [1].
> But I get an error message:
> ```
> $ ipconfig
> MAC Address: 
> Broadcast MAC: FF FF FF FF FF FF
> ipconfig: Locate protocol error: 'PXE base code protocol'
> ```
> So I'm thinking some drivers are not being loaded?
> 
> Any suggestions for enabling these features would be greatly appreciated.
> 
> [1] https://github.com/tianocore/tianocore.github.io/wiki/NetworkPkg-
> Getting-Started-Guide -> FEATURES ENABLING
> 
> Cheers,
> Cameron
> 
> 
> Cameron Craig | Graduate Software Engineer | Exterity Limited
> tel: +44 1383 828 250 | fax:  | mobile:
> e: cameron.cr...@exterity.com | w: www.exterity.com
> 
> Exterity is a leading provider of IP Video and Digital Signage solutions that 
> helps
> organizations to harness the power of video to communicate, educate and
> entertain. Our end-to-end solutions enable you to take TV and video content
> directly from any source and manage its delivery, live or on demand, to any
> connected device via your existing network. For more information or to
> schedule a product demonstration, contact Exterity on +44(0)1383 828 250 or
> visit www.exterity.com
> 
> Legal Notice
> Unless expressly stated otherwise, this message is confidential and may be
> privileged. It is intended for the addressee(s) only. Access to this e-mail by
> anyone else is unauthorized. If you are not an addressee, any disclosure or
> copying of the contents of this e-mail or any action taken (or not taken) in
> reliance on it is unauthorized and may be unlawful. If you are not an 
> addressee,
> please inform the sender immediately.
> 
> Exterity Limited is registered in Scotland under No. 225313 with its 
> registered
> office at Ridge Way, Hillend Industrial Park, Dalgety Bay, KY11 9JD.
> 
> 
> _
> _
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> _
> _
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] [edk2-platforms]: Adding usb Host driver support from OpenPlatformPkg hikey-wip branch

[Leif Lindholm]

Hi Kalyan,

This is a huge (and much appreciated) contribution.
However, in order to simplify reviewing, could you please:
1) Configure your edk2-platforms clone as described in
   
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contributor-workflow
   (step 5 onwards)
2) Split this patch up into
   1) DwUsbDxe
   2) DwUsbHostDxe
   3) HiKey-specific changes/additions.

It would probably also be worth cc:ing Jeremy Linton
(jeremy.lin...@arm.com) on this set.

For some early high-level feedback:
* I see you have included UncachedMemoryAllocationLib under HiKey.
  We did delete that library for a reason - it does not really do what
  people seem to think it does.
  Ard: could you pitch in with a more suitable solution?
* The DwNonPci module is not really part of the generic driver, but
  something that could be integrated somewhere in the platform
  initialization (HiKeylib?).

Best Regards,

Leif

On Mon, Nov 20, 2017 at 03:55:44PM +0530, kalyan-nagabhirava wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: kalyan-nagabhirava 
> ---
>  Platform/Hisilicon/HiKey/HiKey.dec |4 +
>  Platform/Hisilicon/HiKey/HiKey.dsc |   11 +
>  Platform/Hisilicon/HiKey/HiKey.fdf |3 +
>  .../Include/Library/UncachedMemoryAllocationLib.h  |  665 ++
>  .../Hisilicon/HiKey/Library/ArmDmaLib/ArmDmaLib.c  |  342 +++
>  .../HiKey/Library/ArmDmaLib/ArmDmaLib.inf  |   50 +
>  .../UncachedMemoryAllocationLib.c  |  692 ++
>  .../UncachedMemoryAllocationLib.inf|   45 +
>  Silicon/Synopsys/Usb/DwNonPci/DwNonPciUsbDxe.inf   |   47 +
>  Silicon/Synopsys/Usb/DwNonPci/InitController.c |   37 +
>  Silicon/Synopsys/Usb/DwUsbDxe/ComponentName.c  |  244 ++
>  Silicon/Synopsys/Usb/DwUsbDxe/ComponentName.h  |  148 ++
>  Silicon/Synopsys/Usb/DwUsbDxe/DwUsbDxe.c   | 2324 
> 
>  Silicon/Synopsys/Usb/DwUsbDxe/DwUsbDxe.dec |   42 +
>  Silicon/Synopsys/Usb/DwUsbDxe/DwUsbDxe.h   |  534 +
>  Silicon/Synopsys/Usb/DwUsbDxe/DwUsbDxe.inf |   60 +
>  Silicon/Synopsys/Usb/DwUsbHostDxe/ComponentName.c  |  243 ++
>  Silicon/Synopsys/Usb/DwUsbHostDxe/ComponentName.h  |  148 ++
>  Silicon/Synopsys/Usb/DwUsbHostDxe/DwUsbHostDxe.c   | 2043 +
>  Silicon/Synopsys/Usb/DwUsbHostDxe/DwUsbHostDxe.h   |  121 +
>  Silicon/Synopsys/Usb/DwUsbHostDxe/DwUsbHostDxe.inf |   61 +
>  Silicon/Synopsys/Usb/DwUsbHostDxe/DwcHw.h  |  792 +++
>  22 files changed, 8656 insertions(+)
>  create mode 100644 
> Platform/Hisilicon/HiKey/Include/Library/UncachedMemoryAllocationLib.h
>  create mode 100644 Platform/Hisilicon/HiKey/Library/ArmDmaLib/ArmDmaLib.c
>  create mode 100644 Platform/Hisilicon/HiKey/Library/ArmDmaLib/ArmDmaLib.inf
>  create mode 100644 
> Platform/Hisilicon/HiKey/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
>  create mode 100644 
> Platform/Hisilicon/HiKey/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
>  create mode 100644 Silicon/Synopsys/Usb/DwNonPci/DwNonPciUsbDxe.inf
>  create mode 100644 Silicon/Synopsys/Usb/DwNonPci/InitController.c
>  create mode 100644 Silicon/Synopsys/Usb/DwUsbDxe/ComponentName.c
>  create mode 100644 Silicon/Synopsys/Usb/DwUsbDxe/ComponentName.h
>  create mode 100644 Silicon/Synopsys/Usb/DwUsbDxe/DwUsbDxe.c
>  create mode 100644 Silicon/Synopsys/Usb/DwUsbDxe/DwUsbDxe.dec
>  create mode 100644 Silicon/Synopsys/Usb/DwUsbDxe/DwUsbDxe.h
>  create mode 100644 Silicon/Synopsys/Usb/DwUsbDxe/DwUsbDxe.inf
>  create mode 100644 Silicon/Synopsys/Usb/DwUsbHostDxe/ComponentName.c
>  create mode 100644 Silicon/Synopsys/Usb/DwUsbHostDxe/ComponentName.h
>  create mode 100644 Silicon/Synopsys/Usb/DwUsbHostDxe/DwUsbHostDxe.c
>  create mode 100644 Silicon/Synopsys/Usb/DwUsbHostDxe/DwUsbHostDxe.h
>  create mode 100644 Silicon/Synopsys/Usb/DwUsbHostDxe/DwUsbHostDxe.inf
>  create mode 100644 Silicon/Synopsys/Usb/DwUsbHostDxe/DwcHw.h
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH v2 0/4] Armada 7k/8k variable support

[Leif Lindholm]

On Tue, Nov 21, 2017 at 07:46:17AM +0100, Marcin Wojtas wrote:
> Hi,
> 
> I submit v2 of the Armada variable support with the style of
> the MvFvbDxe driver fixed and other minor modifications. Depex
> configuration was moved from 4/4 to previous patches. Details
> can be found in the changelog and commit messages.
> 
> Patches are available in the github:
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/var-upstream-r20171121
> 
> I'm looking forward to the comments or remarks.

For 2-4/4:
Reviewed-by: Leif Lindholm 

> Best regards,
> Marcin
> 
> Changelog:
> v1 -> v2:
> * Change patches order in order to safely apply related Depex modifications
> 
> * 1/4:
>   - Fix style (line breaking, openining brackets, alignment, typos)
>   - Rework MvFvbSetAttributes - because it can return only EFI_SUCCESS /
> EFI_INVALID_PARAMETER and should return FVB attributes,
> add debug information, that operation is not supported and return
> default values via MvFvbGetAttributes.
>   - Return EFI_SUCCESS, in case NumBytes == 0 in MvFvbRead.
> 
> * 2/4:
>   - Move Depex configuration from 4/4
> 
> * 3/4:
>   - Move Depex configuration from 4/4
>   - Reword and break commit message.
> 
> * 4/4:
>   - Remove Depex configuration
> 
> Marcin Wojtas (4):
>   Platform/Marvell: Introduce MvFvbDxe variable support driver
>   Marvell/Drivers: MvSpiFlash: Enable using driver in RT
>   Marvell/Drivers: MvSpiDxe: Enable using driver in RT
>   Marvell/Armada: Enable variables support
> 
>  Platform/Marvell/Armada/Armada.dsc.inc  |   25 +-
>  Platform/Marvell/Armada/Armada70x0.fdf  |6 +-
>  Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.c   |   58 +-
>  Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.h   |1 +
>  Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf |   11 +-
>  Platform/Marvell/Drivers/Spi/MvSpiDxe.c |   50 +-
>  Platform/Marvell/Drivers/Spi/MvSpiDxe.h |2 +
>  Platform/Marvell/Drivers/Spi/MvSpiDxe.inf   |9 +-
>  Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.c   | 1056 
> 
>  Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.h   |  114 +++
>  Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.inf |   91 ++
>  Platform/Marvell/Include/Protocol/Spi.h |7 +
>  Platform/Marvell/Marvell.dec|4 +
>  13 files changed, 1420 insertions(+), 14 deletions(-)
>  create mode 100644 Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.c
>  create mode 100644 Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.h
>  create mode 100644 Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.inf
> 
> -- 
> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH v2 1/4] Platform/Marvell: Introduce MvFvbDxe variable support driver

[Leif Lindholm]

On Tue, Nov 21, 2017 at 07:46:18AM +0100, Marcin Wojtas wrote:
> MvFvbDxe driver introduces non-volatile EFI variable support
> for Armada platforms. It relies on memory-mapped SPI read access.
> Implementation of EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL
> is done with using existing Marvell SPI infrastructure
> (SpiMasterProtocol and SpiFlashProtocol), thanks to which
> this driver will be able to support various combinations of
> flash devices and host controllers.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.c   | 1056 
> 
>  Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.h   |  114 +++
>  Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.inf |   91 ++
>  Platform/Marvell/Marvell.dec|1 +
>  4 files changed, 1262 insertions(+)
> 
> diff --git a/Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.c 
> b/Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.c
> new file mode 100644
> index 000..7a44f80
> --- /dev/null
> +++ b/Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.c
> @@ -0,0 +1,1056 @@
> +/*++ @file  MvFvbDxe.c
> +
> + Copyright (c) 2011 - 2014, ARM Ltd. All rights reserved.
> + Copyright (c) 2017 Marvell International Ltd.
> +
> + This program and the accompanying materials are licensed and made available
> + under the terms and conditions of the BSD License which accompanies this
> + distribution.  The full text of the license may be found at
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> + --*/
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "MvFvbDxe.h"
> +
> +STATIC EFI_EVENT mFvbVirtualAddrChangeEvent;
> +STATIC FVB_DEVICE*mFvbDevice;
> +
> +STATIC CONST FVB_DEVICE mMvFvbFlashInstanceTemplate = {
> +  {
> +0,// SpiFlash Chip Select ... NEED TO BE FILLED
> +0,// SpiFlash Maximum Frequency ... NEED TO BE FILLED
> +0,// SpiFlash Transfer Mode ... NEED TO BE FILLED
> +0,// SpiFlash Address Size ... NEED TO BE FILLED
> +NULL, // SpiFlash detailed information ... NEED TO BE FILLED
> +0,// HostRegisterBaseAddress ... NEED TO BE FILLED
> +0,// CoreClock ... NEED TO BE FILLED
> +  }, // SpiDevice
> +
> +  NULL, // SpiFlashProtocol ... NEED TO BE FILLED
> +  NULL, // SpiMasterProtocol ... NEED TO BE FILLED
> +  NULL, // Handle ... NEED TO BE FILLED
> +
> +  FVB_FLASH_SIGNATURE, // Signature
> +
> +  0, // DeviceBaseAddress ... NEED TO BE FILLED
> +  0, // RegionBaseAddress ... NEED TO BE FILLED
> +  SIZE_256KB, // Size
> +  0, // FvbOffset ... NEED TO BE FILLED
> +  0, // FvbSize ... NEED TO BE FILLED
> +  0, // StartLba
> +
> +  {
> +0, // MediaId ... NEED TO BE FILLED
> +FALSE, // RemovableMedia
> +TRUE,  // MediaPresent
> +FALSE, // LogicalPartition
> +FALSE, // ReadOnly
> +FALSE, // WriteCaching;
> +0, // BlockSize ... NEED TO BE FILLED
> +4, // IoAlign
> +0, // LastBlock ... NEED TO BE FILLED
> +0, // LowestAlignedLba
> +1, // LogicalBlocksPerPhysicalBlock
> +  }, //Media;
> +
> +  {
> +MvFvbGetAttributes,   // GetAttributes
> +MvFvbSetAttributes,   // SetAttributes
> +MvFvbGetPhysicalAddress,  // GetPhysicalAddress
> +MvFvbGetBlockSize,// GetBlockSize
> +MvFvbRead,// Read
> +MvFvbWrite,   // Write
> +MvFvbEraseBlocks, // EraseBlocks
> +NULL, // ParentHandle
> +  }, //  FvbProtocol;
> +
> +  {
> +{
> +  {
> +HARDWARE_DEVICE_PATH,
> +HW_VENDOR_DP,
> +{
> +  (UINT8)sizeof (VENDOR_DEVICE_PATH),
> +  (UINT8)((sizeof (VENDOR_DEVICE_PATH)) >> 8)
> +}
> +  },
> +  { 0xfc0cb972, 0x21df, 0x44d2, { 0x92, 0xa5, 0x78, 0x98, 0x99, 0xcb, 
> 0xf6, 0x61 } }
> +},
> +{
> +  END_DEVICE_PATH_TYPE,
> +  END_ENTIRE_DEVICE_PATH_SUBTYPE,
> +  { sizeof (EFI_DEVICE_PATH_PROTOCOL), 0 }
> +}
> +  } // DevicePath
> +};
> +
> +//
> +// The Firmware Volume Block Protocol is the low-level interface
> +// to a firmware volume. File-level access to a firmware volume
> +// should not be done using the Firmware Volume Block Protocol.
> +// Normal access to a firmware volume must use the Firmware
> +// Volume Protocol. Typically, only the file system driver that
> +// produces the Firmware Volume Protocol will bind to the
> +// Firmware Volume Block Protocol.
> +//
> +
> +/**
> +  Initialises the FV Header and Variable Store Header
> +  to support variable operations.
> +
> +  @param[in]  Ptr - Location to initialise the headers
> +
> +**/
> 

Re: [edk2] 答复: [PATCH v2 0/8] Implement stack guard feature

[Yao, Jiewen]

I do not think it is a good idea to push it now.

I think we need more thought on API design especially for pei/smm in the 
future. (My comment for 1.2/1.3/1.4)

thank you!
Yao, Jiewen


> 在 2017年11月25日，下午9:44，Fan Jeff  写道：
> 
> Jian,
> 
> I reviewed your patches and sent my minimal comments in other separate mail. 
> They should not impact the functionality.
> 
> I am ok if you push the v2 patches now and do the updating based on my 
> comments in separate patches later.
> 
> Reviewed-by: Jeff Fan 
> 
> Thanks!
> Jeff
> 
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Jian
>>> J
 Wang
 Sent: Wednesday, November 22, 2017 4:46 PM
 To: edk2-devel@lists.01.org
 Subject: [edk2] [PATCH v2 0/8] Implement stack guard feature
 
 Stack guard feature makes use of paging mechanism to monitor if there's a
 stack overflow occurred during boot. A new PCD PcdCpuStackGuard is added
>>> to
 enable/disable this feature. PCD PcdCpuStackSwitchExceptionList and
 PcdCpuKnownGoodStackSize are introduced to configure the required
 exceptions
 and stack size.
 
 If this feature is enabled, DxeIpl will setup page tables and set page 
 where
 the stack bottom is at to be NON-PRESENT. If stack overflow occurs, Page
 Fault exception will be triggered.
 
 In order to make sure exception handler works normally even when the stack
 is corrupted, stack switching is implemented in exception library.
 
 Due to the mechanism behind Stack Guard, this feature is only avaiable for
 UEFI drivers (memory avaiable). That also means it doesn't support NT32
 emulated platform (paging not supported).
 
 Validation works include:
  a. OVMF emulated platform: boot to shell (IA32/X64)
  b. Intel real platform: boot to shell (IA32/X64)
 
 Jian J Wang (8):
  MdeModulePkg/metafile: Add PCD PcdCpuStackGuard
  MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API
  MdePkg/BaseLib: Add stack switch related definitions for IA32
  MdeModulePkg/DxeIpl: Enable paging for Stack Guard
  UefiCpuPkg/UefiCpuPkg.dec: Add two new PCDs for stack switch
  UefiCpuPkg/MpLib: Add GDTR, IDTR and TR in saved AP data
  UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support
  UefiCpuPkg/CpuDxe: Initialize stack switch for MP
 
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   5 +-
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|   4 +
 MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c |   1 +
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   |  51 ++-
 .../Include/Library/CpuExceptionHandlerLib.h   |  18 +
 MdeModulePkg/MdeModulePkg.dec  |   7 +
 MdeModulePkg/MdeModulePkg.uni  |   7 +
 MdePkg/Include/Library/BaseLib.h   | 115 ++
 MdePkg/Library/BaseLib/BaseLib.inf |   3 +
 MdePkg/Library/BaseLib/Ia32/WriteTr.nasm   |  36 ++
 MdePkg/Library/BaseLib/X64/WriteTr.nasm|  37 ++
 UefiCpuPkg/CpuDxe/CpuDxe.inf   |   3 +
 UefiCpuPkg/CpuDxe/CpuMp.c  | 168
>> +
 UefiCpuPkg/CpuDxe/CpuMp.h  |  12 +
 .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  50 +++
 .../DxeCpuExceptionHandlerLib.inf  |   6 +
 .../Library/CpuExceptionHandlerLib/DxeException.c  |  53 ++-
 .../Ia32/ArchExceptionHandler.c| 167 +
 .../Ia32/ArchInterruptDefs.h   |   8 +
 .../Ia32/ExceptionTssEntryAsm.nasm | 398
 +
 .../PeiCpuExceptionHandlerLib.inf  |   1 +
 .../SecPeiCpuExceptionHandlerLib.inf   |   1 +
 .../SmmCpuExceptionHandlerLib.inf  |   1 +
 .../X64/ArchExceptionHandler.c | 133 +++
 .../CpuExceptionHandlerLib/X64/ArchInterruptDefs.h |   3 +
 UefiCpuPkg/Library/MpInitLib/MpLib.c   |  17 +
 UefiCpuPkg/Library/MpInitLib/MpLib.h   |   3 +
 UefiCpuPkg/UefiCpuPkg.dec  |  12 +
 28 files changed, 1304 insertions(+), 16 deletions(-)
 create mode 100644 MdePkg/Library/BaseLib/Ia32/WriteTr.nasm
 create mode 100644 MdePkg/Library/BaseLib/X64/WriteTr.nasm
 create mode 100644
 
>>> 
>> UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAsm.nasm
 
 --
 2.14.1.windows.1
 
 ___
 edk2-devel mailing list
 edk2-devel@lists.01.org
 https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 
> 

[edk2] 答复: [PATCH v2 0/8] Implement stack guard feature

[Fan Jeff]

Jian,

I reviewed your patches and sent my minimal comments in other separate mail. 
They should not impact the functionality.

I am ok if you push the v2 patches now and do the updating based on my comments 
in separate patches later.

Reviewed-by: Jeff Fan 

Thanks!
Jeff

> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jian
> > J
> > > Wang
> > > Sent: Wednesday, November 22, 2017 4:46 PM
> > > To: edk2-devel@lists.01.org
> > > Subject: [edk2] [PATCH v2 0/8] Implement stack guard feature
> > >
> > > Stack guard feature makes use of paging mechanism to monitor if there's a
> > > stack overflow occurred during boot. A new PCD PcdCpuStackGuard is added
> > to
> > > enable/disable this feature. PCD PcdCpuStackSwitchExceptionList and
> > > PcdCpuKnownGoodStackSize are introduced to configure the required
> > > exceptions
> > > and stack size.
> > >
> > > If this feature is enabled, DxeIpl will setup page tables and set page 
> > > where
> > > the stack bottom is at to be NON-PRESENT. If stack overflow occurs, Page
> > > Fault exception will be triggered.
> > >
> > > In order to make sure exception handler works normally even when the stack
> > > is corrupted, stack switching is implemented in exception library.
> > >
> > > Due to the mechanism behind Stack Guard, this feature is only avaiable for
> > > UEFI drivers (memory avaiable). That also means it doesn't support NT32
> > > emulated platform (paging not supported).
> > >
> > > Validation works include:
> > >   a. OVMF emulated platform: boot to shell (IA32/X64)
> > >   b. Intel real platform: boot to shell (IA32/X64)
> > >
> > > Jian J Wang (8):
> > >   MdeModulePkg/metafile: Add PCD PcdCpuStackGuard
> > >   MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API
> > >   MdePkg/BaseLib: Add stack switch related definitions for IA32
> > >   MdeModulePkg/DxeIpl: Enable paging for Stack Guard
> > >   UefiCpuPkg/UefiCpuPkg.dec: Add two new PCDs for stack switch
> > >   UefiCpuPkg/MpLib: Add GDTR, IDTR and TR in saved AP data
> > >   UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support
> > >   UefiCpuPkg/CpuDxe: Initialize stack switch for MP
> > >
> > >  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   5 +-
> > >  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|   4 +
> > >  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c |   1 +
> > >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   |  51 ++-
> > >  .../Include/Library/CpuExceptionHandlerLib.h   |  18 +
> > >  MdeModulePkg/MdeModulePkg.dec  |   7 +
> > >  MdeModulePkg/MdeModulePkg.uni  |   7 +
> > >  MdePkg/Include/Library/BaseLib.h   | 115 ++
> > >  MdePkg/Library/BaseLib/BaseLib.inf |   3 +
> > >  MdePkg/Library/BaseLib/Ia32/WriteTr.nasm   |  36 ++
> > >  MdePkg/Library/BaseLib/X64/WriteTr.nasm|  37 ++
> > >  UefiCpuPkg/CpuDxe/CpuDxe.inf   |   3 +
> > >  UefiCpuPkg/CpuDxe/CpuMp.c  | 168
> +
> > >  UefiCpuPkg/CpuDxe/CpuMp.h  |  12 +
> > >  .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  50 +++
> > >  .../DxeCpuExceptionHandlerLib.inf  |   6 +
> > >  .../Library/CpuExceptionHandlerLib/DxeException.c  |  53 ++-
> > >  .../Ia32/ArchExceptionHandler.c| 167 +
> > >  .../Ia32/ArchInterruptDefs.h   |   8 +
> > >  .../Ia32/ExceptionTssEntryAsm.nasm | 398
> > > +
> > >  .../PeiCpuExceptionHandlerLib.inf  |   1 +
> > >  .../SecPeiCpuExceptionHandlerLib.inf   |   1 +
> > >  .../SmmCpuExceptionHandlerLib.inf  |   1 +
> > >  .../X64/ArchExceptionHandler.c | 133 +++
> > >  .../CpuExceptionHandlerLib/X64/ArchInterruptDefs.h |   3 +
> > >  UefiCpuPkg/Library/MpInitLib/MpLib.c   |  17 +
> > >  UefiCpuPkg/Library/MpInitLib/MpLib.h   |   3 +
> > >  UefiCpuPkg/UefiCpuPkg.dec  |  12 +
> > >  28 files changed, 1304 insertions(+), 16 deletions(-)
> > >  create mode 100644 MdePkg/Library/BaseLib/Ia32/WriteTr.nasm
> > >  create mode 100644 MdePkg/Library/BaseLib/X64/WriteTr.nasm
> > >  create mode 100644
> > >
> >
> UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAsm.nasm
> > >
> > > --
> > > 2.14.1.windows.1
> > >
> > > ___
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] remove ARM BdsLib and FdtPlatformDxe

[Leif Lindholm]

On Mon, Nov 20, 2017 at 11:45:03AM +, Ard Biesheuvel wrote:
> Remove two pieces of legacy that are only used by platforms residing under
> Platform/ARM in edk2-platforms, and really shouldn't serve as examples for
> new contributions. So after migrating the code to edk2-platforms, remove it
> from EDK2.

1/2 should also delete
---
  # FDT installation
  EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf {

  # It depends on BdsLib that depends on TimerLib
  
TimerLib|MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
  }
---
from EmbeddedPkg/EmbeddedPkg.dsc

and 2/2 should delete the
---
  BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf
---
resolution from the same file.

2/2 should also delete the BdsLib references from ArmPkg/ArmPkg.dsc:
---
[LibraryClasses.common]
  BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf
---
and
---
[Components.common]
  ArmPkg/Library/BdsLib/BdsLib.inf
---

And both should be ordered after the Android*Boot patches I just sent out.
If you do that, and fold in the above comments:
Reviewed-by: Leif Lindholm 

> Ard Biesheuvel (2):
>   EmbeddedPkg: remove FdtPlatformDxe
>   ArmPkg: remove BdsLib and remaining ARM BDS related PCDs
> 
>  ArmPkg/ArmPkg.dec |8 -
>  ArmPkg/Library/BdsLib/BdsAppLoader.c  |  253 
>  ArmPkg/Library/BdsLib/BdsFilePath.c   | 1411 
> 
>  ArmPkg/Library/BdsLib/BdsHelper.c |  183 ---
>  ArmPkg/Library/BdsLib/BdsInternal.h   |  111 --
>  ArmPkg/Library/BdsLib/BdsLib.inf  |   69 -
>  ArmPkg/Library/BdsLib/BdsLoadOption.c |  272 
>  BeagleBoardPkg/BeagleBoardPkg.dsc |3 -
>  EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.c  |  461 ---
>  EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h  |  174 ---
>  EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf |   64 -
>  EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatformDxe.uni |  109 --
>  EmbeddedPkg/Drivers/FdtPlatformDxe/README.txt |   72 -
>  EmbeddedPkg/Drivers/FdtPlatformDxe/ShellDumpFdt.c |  279 
>  EmbeddedPkg/Drivers/FdtPlatformDxe/ShellSetFdt.c  |  468 ---
>  EmbeddedPkg/EmbeddedPkg.dec   |6 -
>  16 files changed, 3943 deletions(-)
>  delete mode 100644 ArmPkg/Library/BdsLib/BdsAppLoader.c
>  delete mode 100644 ArmPkg/Library/BdsLib/BdsFilePath.c
>  delete mode 100644 ArmPkg/Library/BdsLib/BdsHelper.c
>  delete mode 100644 ArmPkg/Library/BdsLib/BdsInternal.h
>  delete mode 100644 ArmPkg/Library/BdsLib/BdsLib.inf
>  delete mode 100644 ArmPkg/Library/BdsLib/BdsLoadOption.c
>  delete mode 100644 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.c
>  delete mode 100644 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h
>  delete mode 100644 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf
>  delete mode 100644 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatformDxe.uni
>  delete mode 100644 EmbeddedPkg/Drivers/FdtPlatformDxe/README.txt
>  delete mode 100644 EmbeddedPkg/Drivers/FdtPlatformDxe/ShellDumpFdt.c
>  delete mode 100644 EmbeddedPkg/Drivers/FdtPlatformDxe/ShellSetFdt.c
> 
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] 答复: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Fan Jeff]

Jian,



EFIAPI is not required for ArchSetupExcpetionStack().



Reviewed-by: Jeff Fan 



Jeff




From: edk2-devel  on behalf of Jian J Wang 

Sent: Wednesday, November 22, 2017 4:45:47 PM
To: edk2-devel@lists.01.org
Cc: Michael Kinney; Jiewen Yao; Eric Dong; Star Zeng
Subject: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack 
switch support

> v2:
>a. Move common TSS structure and API definitions to BaseLib.h
>b. Add EXCEPTION_STACK_SWITCH_DATA to convery data used to setup stack
>   switch. This can avoid allocating memory for it in this library.
>c. Add globals to reserve memory for stack switch initialized in early
>   phase of DXE core.
>d. Remove the filter code used to exclude boot modes which doesn't support
>   memory allocation because those memory can passed in by parameter now.
>e. Remove the nasm macro to define exception handler one by one and add a
>   function to return the start address of each handler.

If Stack Guard is enabled and there's really a stack overflow happened during
boot, a Page Fault exception will be triggered. Because the stack is out of
usage, the exception handler, which shares the stack with normal UEFI driver,
cannot be executed and cannot dump the processor information.

Without those information, it's very difficult for the BIOS developers locate
the root cause of stack overflow. And without a workable stack, the developer
cannot event use single step to debug the UEFI driver with JTAG debugger.

In order to make sure the exception handler to execute normally after stack
overflow. We need separate stacks for exception handlers in case of unusable
stack.

IA processor allows to switch to a new stack during handling interrupt and
exception. But X64 and IA32 provides different ways to make it. X64 provides
interrupt stack table (IST) to allow maximum 7 different exceptions to have
new stack for its handler. IA32 doesn't have IST mechanism and can only use
task gate to do it since task switch allows to load a new stack through its
task-state segment (TSS).

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  50 +++
 .../DxeCpuExceptionHandlerLib.inf  |   6 +
 .../Library/CpuExceptionHandlerLib/DxeException.c  |  53 ++-
 .../Ia32/ArchExceptionHandler.c| 167 +
 .../Ia32/ArchInterruptDefs.h   |   8 +
 .../Ia32/ExceptionTssEntryAsm.nasm | 398 +
 .../PeiCpuExceptionHandlerLib.inf  |   1 +
 .../SecPeiCpuExceptionHandlerLib.inf   |   1 +
 .../SmmCpuExceptionHandlerLib.inf  |   1 +
 .../X64/ArchExceptionHandler.c | 133 +++
 .../CpuExceptionHandlerLib/X64/ArchInterruptDefs.h |   3 +
 11 files changed, 820 insertions(+), 1 deletion(-)
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAsm.nasm

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
index 740a58828b..30334105d2 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
@@ -48,6 +48,32 @@
 0xb21d9148, 0x9211, 0x4d8f, { 0xad, 0xd3, 0x66, 0xb1, 0x89, 0xc9, 0x2c, 
0x83 } \
   }

+#define CPU_STACK_SWITCH_EXCEPTION_NUMBER \
+  FixedPcdGetSize (PcdCpuStackSwitchExceptionList)
+
+#define CPU_STACK_SWITCH_EXCEPTION_LIST \
+  FixedPcdGetPtr (PcdCpuStackSwitchExceptionList)
+
+#define CPU_KNOWN_GOOD_STACK_SIZE \
+  FixedPcdGet32 (PcdCpuKnownGoodStackSize)
+
+#define CPU_TSS_GDT_SIZE (SIZE_2KB + CPU_TSS_DESC_SIZE + CPU_TSS_SIZE)
+
+#define IA32_GDT_TYPE_TSS   0x9
+#define IA32_GDT_ALIGNMENT  8
+
+typedef struct {
+  UINTN StackTop;
+  UINTN StackSize;
+  UINT8 *Exceptions;
+  UINTN ExceptionNumber;
+  IA32_IDT_GATE_DESCRIPTOR  *IdtTable;
+  IA32_SEGMENT_DESCRIPTOR   *GdtTable;
+  UINTN GdtSize;
+  IA32_TSS_DESCRIPTOR   *TssDesc;
+  IA32_TASK_STATE_SEGMENT   *Tss;
+} EXCEPTION_STACK_SWITCH_DATA;
+
 //
 // Record exception handler information
 //
@@ -288,5 +314,29 @@ CommonExceptionHandlerWorker (
   IN EXCEPTION_HANDLER_DATA  *ExceptionHandlerData
   );

+/**
+  Setup separate stack for specific exceptions.
+
+  @param[in] IdtTableIDT table base.
+**/
+EFI_STATUS
+EFIAPI
+ArchSetupExcpetionStack (
+  IN EXCEPTION_STACK_SWITCH_DATA  

Re: [edk2] [PATCH edk2-platforms 0/4] Platform/ARM: import BdsLib and FdtPlatformDxe

[Leif Lindholm]

On Mon, Nov 20, 2017 at 11:37:10AM +, Ard Biesheuvel wrote:
> The only remnant of the deprecated ARM BDS in EDK2 is its BdsLib, which is
> depended upon by FdtPlatformDxe in EmbeddedPkg, which itself is something
> we'd prefer to get rid of. Since only TC2 and Juno actually use this driver,
> let's move both FdtPlatformDxe and BdsLib under Platform/ARM, so that we can
> remove it from the main EDK2 repository.

I see no issue with this series as such (and agree with its intent).
However, on the EDK2 side, we still have some users of BdsLib in the
EmbeddedPkg Android loaders.

(I have sent out a trivial series to get rid of these, but this move
should be ordered against that set.)

Once that's in, for the series:
Reviewed-by: Leif Lindholm 

/
Leif

> Ard Biesheuvel (4):
>   Platform/ARM: import BdsLib from ArmPkg
>   Platform/ARM: import FdtPlatformDxe driver from EDK2
>   Platform/ARM/Juno: move to migrated FdtPlatformDxe
>   Platform/TC2: move to private FdtPlatformDxe implementation
>
>  Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatform.c  |  461 +++
>  Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatform.h  |  174 +++
>  Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.dec |   31 +
>  Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf |   65 +
>  Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.uni |  109 ++
>  Platform/ARM/Drivers/FdtPlatformDxe/README.txt |   72 +
>  Platform/ARM/Drivers/FdtPlatformDxe/ShellDumpFdt.c |  279 
>  Platform/ARM/Drivers/FdtPlatformDxe/ShellSetFdt.c  |  468 +++
>  Platform/ARM/JunoPkg/ArmJuno.dsc   |6 +-
>  Platform/ARM/JunoPkg/ArmJuno.fdf   |2 +-
>  Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf |3 +-
>  Platform/ARM/Library/BdsLib/BdsAppLoader.c |  253 
>  Platform/ARM/Library/BdsLib/BdsFilePath.c  | 1413 
> 
>  Platform/ARM/Library/BdsLib/BdsHelper.c|  183 +++
>  Platform/ARM/Library/BdsLib/BdsInternal.h  |  111 ++
>  Platform/ARM/Library/BdsLib/BdsLib.inf |   62 +
>  Platform/ARM/Library/BdsLib/BdsLoadOption.c|  272 
>  Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc  |6 +-
>  Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf  |2 +-
>  Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc   |5 +-
>  20 files changed, 3964 insertions(+), 13 deletions(-)
>  create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatform.c
>  create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatform.h
>  create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.dec
>  create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf
>  create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.uni
>  create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/README.txt
>  create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/ShellDumpFdt.c
>  create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/ShellSetFdt.c
>  create mode 100644 Platform/ARM/Library/BdsLib/BdsAppLoader.c
>  create mode 100644 Platform/ARM/Library/BdsLib/BdsFilePath.c
>  create mode 100644 Platform/ARM/Library/BdsLib/BdsHelper.c
>  create mode 100644 Platform/ARM/Library/BdsLib/BdsInternal.h
>  create mode 100644 Platform/ARM/Library/BdsLib/BdsLib.inf
>  create mode 100644 Platform/ARM/Library/BdsLib/BdsLoadOption.c
> 
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] 答复: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Fan Jeff]

Hi,



About 1.1), I agree with Jiewen’s suggestion. Besides it, we also need to 
provide dummy function of InitializeCpuExceptionStackSwitchHandlers() in NULL 
instance in MdeModulePkg/Library/CpuExceptionHandlerLibNull.

But we need to think about the return status carefully. For example, if return 
EFI_UNSUPPORTED in Pei/SMM instrance, we need to update public header file to 
add this return type.



Jeff




From: edk2-devel  on behalf of Wang, Jian J 

Sent: Thursday, November 23, 2017 2:43:44 PM
To: Yao, Jiewen; edk2-devel@lists.01.org
Cc: Kinney, Michael D; Dong, Eric; Zeng, Star
Subject: Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack 
switch support

1.1) Got your point. I'll add dummy function in this patch.
1.2) Yep, we're on the same page.
1.3) Here's my opinion:

Actually almost all MP code has such assumption: any AP configuration will copy
 from BSP. If we allow AP to call InitializeCpuExceptionHandlers(), we have to 
do a lot
of other changes than just updating InitializeCpuExceptionHandlers(). If so, it 
may
be premature to figure out a solution at this patch.

In addition, CpuDxe actually calls InitializeCpuInterruptHandlers() which 
covers the
functionalities of InitializeCpuExceptionHandlers() (its settings will be 
overwritten).
If we want AP to initialize interrupt and exception individually, maybe we 
should
let AP call InitializeCpuInterruptHandlers() instead.

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 2:16 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Zeng, Star ; Dong, Eric ;
> Kinney, Michael D 
> Subject: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
>
> Here is my thought for 1)
>
> 1.1) We must provide the InitializeCpuExceptionStackSwitchHandlers()
> implementation in Pei instance and Smm instance.
>
> The basic requirement is a library instance must provide symbol for functions
> declared in header file.
> It is ok to return unsupported. But we MUST provide the symbol.
>
> 1.2) For SMM, I think our ultimate goal is to remove SMM specific stack guard,
> and use the common one. Duplicating code is completely unnecessary, and it is
> easy to introduce bug. And unfortunately, we already have bug in existing SMM
> exception handler. -- That is a good reason to remove duplication.
>
> Again, it is not necessary to do it in this patch. I am totally OK to do it 
> in another
> patch.
>
> 1.3) For PEI, I do not think we can use current way to allocate stack in data
> section, because it might be readonly in pre-mem phase. We must use some
> other way.
>
> 1.4) I believe this patch has a hidden assumption is that:
> InitializeCpuExceptionHandlers() won't be called by multiple APs.
> If 2 or more APs call the it at same time, it might be broken because you use
> mNewStack for all the callers
> Is that right?
>
>
> Thank you
> Yao Jiewen
>
>
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, November 23, 2017 2:06 PM
> > To: Yao, Jiewen ; edk2-devel@lists.01.org
> > Cc: Zeng, Star ; Dong, Eric ;
> Kinney,
> > Michael D 
> > Subject: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > switch support
> >
> >
> >
> > > -Original Message-
> > > From: Yao, Jiewen
> > > Sent: Thursday, November 23, 2017 1:50 PM
> > > To: Wang, Jian J ; edk2-devel@lists.01.org
> > > Cc: Zeng, Star ; Dong, Eric ;
> > > Kinney, Michael D 
> > > Subject: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > > switch support
> > >
> > > Some thought:
> > >
> > > 1) I found InitializeCpuExceptionStackSwitchHandlers() is only implemented
> in
> > > DxeException.c.
> > > What about Pei/Smm instance?
> > >
> > > I think it is OK to not implement it at this moment. But we need make 
> > > sure no
> > > architecture issue if we want to enable it some time later.
> > >
> > Like what we discussed before, this series of patch is for Stack Guard 
> > feature
> > which
> > is only available for DXE (because Stack Guard needs paging to work). Stack
> > switch
> > is enabled for the sake of Stack Guard feature. So I think it's enough to
> > implement
> > it in DxeException.c. In addition, SMM has its own implementation of stack
> guard
> > and stack switch. It's not necessary to do it again.
> >
> > I agree with you that we should merge those common code but I think we
> should
> > do
> > it in a separate patch series since it's not Stack Guard relevant. And I've
> removed
> > all architecture issues I can think of. Current stack switch initialization 
> > should
> work
> > for both PEI and SMM 

[edk2] [PATCH 2/2] EmbeddedPkg: get rid of BdsLib dependency from Android*Boot

[Leif Lindholm]

The sum use these applications made of BdsLib was one invocation of the
IS_DEVICE_PATH_NODE macro, and (incorrectly) being able to leave out a
dependency on gEfiLoadedImageProtocolGuid.

So expand the macro in place and add the missing dependency.
Then clean up the .dsc, .inf and #includes accordingly.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm 
---
 EmbeddedPkg/Application/AndroidBoot/AndroidBootApp.c | 4 ++--
 EmbeddedPkg/Application/AndroidBoot/AndroidBootApp.inf   | 1 -
 EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c | 1 -
 EmbeddedPkg/EmbeddedPkg.dsc  | 6 +-
 EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.inf  | 1 +
 5 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/EmbeddedPkg/Application/AndroidBoot/AndroidBootApp.c 
b/EmbeddedPkg/Application/AndroidBoot/AndroidBootApp.c
index 977167da40..e1e45e8146 100644
--- a/EmbeddedPkg/Application/AndroidBoot/AndroidBootApp.c
+++ b/EmbeddedPkg/Application/AndroidBoot/AndroidBootApp.c
@@ -15,7 +15,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -35,7 +34,8 @@ ValidateAndroidMediaDevicePath (
   NextNode = DevicePath;
   while (NextNode != NULL) {
 Node = NextNode;
-if (IS_DEVICE_PATH_NODE (Node, MEDIA_DEVICE_PATH, MEDIA_HARDDRIVE_DP)) {
+if (Node->Type == MEDIA_DEVICE_PATH &&
+Node->SubType == MEDIA_HARDDRIVE_DP) {
   return EFI_SUCCESS;
 }
 NextNode = NextDevicePathNode (Node);
diff --git a/EmbeddedPkg/Application/AndroidBoot/AndroidBootApp.inf 
b/EmbeddedPkg/Application/AndroidBoot/AndroidBootApp.inf
index f1ee0bdc82..c2bc68e733 100644
--- a/EmbeddedPkg/Application/AndroidBoot/AndroidBootApp.inf
+++ b/EmbeddedPkg/Application/AndroidBoot/AndroidBootApp.inf
@@ -28,7 +28,6 @@ [LibraryClasses]
   AndroidBootImgLib
   BaseLib
   BaseMemoryLib
-  BdsLib
   DebugLib
   DevicePathLib
   DxeServicesTableLib
diff --git a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c 
b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
index 1d9024b1ce..404aa68a05 100644
--- a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
+++ b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
diff --git a/EmbeddedPkg/EmbeddedPkg.dsc b/EmbeddedPkg/EmbeddedPkg.dsc
index d0af235f99..5b20176eed 100644
--- a/EmbeddedPkg/EmbeddedPkg.dsc
+++ b/EmbeddedPkg/EmbeddedPkg.dsc
@@ -288,11 +288,7 @@ [Components.ARM]
 
 [Components.ARM, Components.AARCH64]
   EmbeddedPkg/Application/AndroidBoot/AndroidBootApp.inf
-  EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf {
-
-  # It depends on BdsLib that depends on TimerLib
-  
TimerLib|MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
-  }
+  EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
   
EmbeddedPkg/Drivers/AndroidFastbootTransportUsbDxe/FastbootTransportUsbDxe.inf
   
EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcpDxe.inf
 
diff --git a/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.inf 
b/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.inf
index c92bac04f2..226b8b2324 100644
--- a/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.inf
+++ b/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.inf
@@ -43,6 +43,7 @@ [Packages]
 
 [Protocols]
   gAndroidBootImgProtocolGuid
+  gEfiLoadedImageProtocolGuid
 
 [Guids]
   gFdtTableGuid
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 0/2] Delete BdsLib dependency from Android loaders

[Leif Lindholm]

AndroidBoot and AndroidFastboot (as well as their shared component
AndroidBootImgLib) have minor dependencies on BdsLib.

First fix up a missing mapping in EmbeddedPkg.dsc to let the modules
build standalone. Then get rid of the use of BdsLib.

Leif Lindholm (2):
  EmbeddedPkg: add UefiRuntimeLib resolution to package .dsc
  EmbeddedPkg: get rid of BdsLib dependency from Android*Boot

 EmbeddedPkg/Application/AndroidBoot/AndroidBootApp.c | 4 ++--
 EmbeddedPkg/Application/AndroidBoot/AndroidBootApp.inf   | 1 -
 EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c | 1 -
 EmbeddedPkg/EmbeddedPkg.dsc  | 7 ++-
 EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.inf  | 1 +
 5 files changed, 5 insertions(+), 9 deletions(-)

-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 1/2] EmbeddedPkg: add UefiRuntimeLib resolution to package .dsc

[Leif Lindholm]

Required to build Android*Boot standalone.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm 
---
 EmbeddedPkg/EmbeddedPkg.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/EmbeddedPkg/EmbeddedPkg.dsc b/EmbeddedPkg/EmbeddedPkg.dsc
index d7ee6a3018..d0af235f99 100644
--- a/EmbeddedPkg/EmbeddedPkg.dsc
+++ b/EmbeddedPkg/EmbeddedPkg.dsc
@@ -83,6 +83,7 @@ [LibraryClasses.common]
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
   UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
+  UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
   
UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
   DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
   
UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] 答复: [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API

[Fan Jeff]

Hi,



I am not sure if this is good idea to define such arch specific definitions in 
MdeModulePkg. Moreover, we don’t know how ARM or other processors define this 
definition, either.



Jeff




From: edk2-devel  on behalf of Wang, Jian J 

Sent: Thursday, November 23, 2017 1:06:53 PM
To: Yao, Jiewen; edk2-devel@lists.01.org
Cc: Dong, Eric; Zeng, Star
Subject: Re: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h: Add a 
new API

Good idea. I think it should be defined in also in following file besides the 
new API

MdeModulePkg\Include\Library\CpuExceptionHandlerLib.h

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 12:08 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Dong, Eric ; Zeng, Star 
> Subject: RE: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h:
> Add a new API
>
> Hi
> I am a little worried about the way to use VOID * to pass arch dependent data.
>
> Can we define it clearly in each ARCH in the header file, and use a UNION to
> include all arch?
>
> I think both the caller and the callee need parse it. As such, VOID * is not 
> a good
> way.
>
> Thank you
> Yao Jiewen
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian
> J
> > Wang
> > Sent: Wednesday, November 22, 2017 4:46 PM
> > To: edk2-devel@lists.01.org
> > Cc: Yao, Jiewen ; Dong, Eric ;
> > Zeng, Star 
> > Subject: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h:
> Add
> > a new API
> >
> > > v2:
> > >Add prototype definition of InitializeCpuExceptionStackSwitchHandlers()
> >
> > A new API InitializeCpuExceptionStackSwitchHandlers() is introduced to
> support
> > initializing exception handlers being able to switch stack. StackSwitchData 
> > is
> > arch dependent and required by IA32 processor to convey resources reserved
> in
> > advance. This is necessary because the CpuExceptionHandlerLib will be linked
> > in different phases, in which there's no common way to reserve resources.
> >
> > EFI_STATUS
> > EFIAPI
> > InitializeCpuExceptionStackSwitchHandlers (
> >   IN VOID   *StackSwitchData  OPTIONAL
> >   );
> >
> > Cc: Star Zeng 
> > Cc: Eric Dong 
> > Cc: Jiewen Yao 
> > Suggested-by: Ayellet Wolman 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang 
> > ---
> >  MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h | 18
> > ++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > b/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > index 6cd8230127..68de4850e1 100644
> > --- a/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > +++ b/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > @@ -41,6 +41,24 @@ InitializeCpuExceptionHandlers (
> >IN EFI_VECTOR_HANDOFF_INFO   *VectorInfo OPTIONAL
> >);
> >
> > +/**
> > +  Setup separate stack for given exceptions. StackSwitchData is optional 
> > and
> its
> > +  content depends one the specific arch of CPU.
> > +
> > +  @param[in] StackSwitchData  Pointer to data required for setuping up
> > +  stack switch.
> > +
> > +  @retval EFI_SUCCESS The exceptions have been successfully
> > +  initialized.
> > +  @retval EFI_INVALID_PARAMETER   StackSwitchData contains invalid
> > content.
> > +
> > +**/
> > +EFI_STATUS
> > +EFIAPI
> > +InitializeCpuExceptionStackSwitchHandlers (
> > +  IN VOID   *StackSwitchData  OPTIONAL
> > +  );
> > +
> >  /**
> >Initializes all CPU interrupt/exceptions entries and provides the default
> > interrupt/exception handlers.
> >
> > --
> > 2.14.1.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] ACPI table HID/CID allocation

[Udit Kumar]

> -Original Message-
> From: Daniel Thompson [mailto:daniel.thomp...@linaro.org]
> Sent: Thursday, November 23, 2017 1:42 AM
> To: Ard Biesheuvel 
> Cc: Udit Kumar ; Leif Lindholm
> ; edk2-devel@lists.01.org; Varun Sethi
> ; Graeme Gregory 
> Subject: Re: [RFC] ACPI table HID/CID allocation
> 

> >
> > PRP0001 + compatible was invented to avoid the need to allocate a _HID
> > for each and every component in existence that can already be
> > identified by a DT compatible string (and little else except, e.g., a
> > I2C slave address) and is not deeply engrained in the SoC in terms of
> > clock tree, power states etc. So while internal/external may not be
> > the most accurate distinction, it is still a useful one IMHO.
> 
> Hmnnn it sounds like jedec,spi-nor meets this test.
> 
> There is only one property in the DT bindings that describes the device
> itself (fast read support) rather than its "bus address" (chip select,
> frequency). Further, that single property is obsolete, at least for
> Linux; the kernel driver now contains a quirks tables to look up by
> device ID whether fast read is supported and will use that on non-DT
> systems (and also to censor broken DT systems ;-) ).


You mean, this more on bus frame work, how to probe slave. 
Example rtc-ds3232.c , when is spi mode just need name 
but for i2c mode it needs of_match_table

Thanks 
Udit 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] ACPI table HID/CID allocation

[Udit Kumar]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, November 23, 2017 1:10 AM
> To: Daniel Thompson 
> Cc: Udit Kumar ; Leif Lindholm
> ; edk2-devel@lists.01.org; Varun Sethi
> ; Graeme Gregory 
> Subject: Re: [RFC] ACPI table HID/CID allocation
> 
> On 22 November 2017 at 11:30, Daniel Thompson
>  wrote:
> > On 21/11/17 18:10, Udit Kumar wrote:
> >>
> >> Thanks Ard,
> >> For internal SOC devices, this is perfectly ok to drop PRP0001 from CID.
> >>
> >>> This could be a valid reason to use PRP0001 + compatible, for things
> >>> like I2C slaves that are external to the SoC
> >>
> >>
> >> For external devices (for which HID is not available), you suggest to go
> >> with PRP0001 + compatible or that device driver needs add ACPI HID
> >> support.
> >
> >
> > I don't think internal or external to the SoC would be any kind of deciding
> > factor in how to best to bind, simply because I don't understand why there
> > is no HID available.
> >
> 
> PRP0001 + compatible was invented to avoid the need to allocate a _HID
> for each and every component in existence that can already be
> identified by a DT compatible string (and little else except, e.g., a
> I2C slave address) and is not deeply engrained in the SoC in terms of
> clock tree, power states etc. So while internal/external may not be
> the most accurate distinction, it is still a useful one IMHO.

Along with this line, say if a driver (what is available in kernel)
can work with PRP0001, and this driver is not exposing/need
any AML methods (i2c slave and flashes are good example here)
then no need to assign HID , right ? 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] ACPI table HID/CID allocation

[Udit Kumar]

Thanks Andrew,
We have one ACPI PNP ID.
I am looking for better way to define ACPI tables. Say a driver (could be slave 
or master) can work with PRP0001, (example flashes, i2c slaves)
then do we need to define HID for the same or not . With condition such driver 
don’t expose or need some AML methods to be implemented.

Regards
Udit

From: af...@apple.com [mailto:af...@apple.com]
Sent: Wednesday, November 22, 2017 11:05 PM
To: Udit Kumar 
Cc: Daniel Thompson ; Ard Biesheuvel 
; edk2-devel@lists.01.org; Leif Lindholm 

Subject: Re: [edk2] [RFC] ACPI table HID/CID allocation

FYI now that the UEFI Forum owns the ACPI Spec here is the location to register 
a new PNP ID or ACPI ID: 
https://stash.sd.apple.com/projects/COREOSMACFW/repos/macefifirmware/pull-requests/630/overview.
 Anyone can make a request.

PNP ID Registry: 
http://www.uefi.org/pnp_id_list
ACPI ID Registry: 
http://www.uefi.org/acpi_id_list

Thanks,

Andrew Fish

On Nov 22, 2017, at 5:39 AM, Udit Kumar 
> wrote:

Hi Daniel



For external devices (for which HID is not available), you suggest to
go with PRP0001 + compatible or that device driver needs add ACPI HID
support.

I don't think internal or external to the SoC would be any kind of deciding 
factor
in how to best to bind, simply because I don't understand why there is no HID
available.

This is more a choice/rule between allocating HID or using PRP0001.
HID could be assigned to external devices, and getting them reviewed
by maintainers.


Large OEMs and board manufacturers usually have their own vendor IDs and
sometimes have to use these to describe hardware (IIRC the SMC LAN9xxx on
the ARM Juno uses an ARM HID).

Thanks,  for this example.
This is good example for me, where HID allocation is not limited to Vendor 
devices.



Admittedly the part you are describing follows a JEDEC standard so it would be
nice to have more widely agreed bindings... however making SPI NOR FLASH
available as raw MTD device to the OS is sufficiently unusual in ACPI systems
that there may not be any prior art to follow.

Please take this as an example. ( Main point was to use HID or PRP0001)
Could be possible, if such device is exposed then this may not be used at all.
Thanks for help.

Thanks
Udit



Daniel.




As you pointed out, are external devices to SOC such exception to use
PRP0001 + compatible be it i2c slave or SPI slave ?


Regards
Udit


-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Tuesday, November 21, 2017 7:34 PM
To: Udit Kumar >
Cc: Leif Lindholm >;
edk2-devel@lists.01.org; Varun Sethi 
>; Daniel
Thompson >; 
Graeme Gregory
>
Subject: Re: [RFC] ACPI table HID/CID allocation

On 21 November 2017 at 13:24, Udit Kumar 
> wrote:

Thanks Ard,

My intend of this email to know, what is right way to define HID and
CID in ACPI firmware i.e

Device(XYZ) {
Name(_HID, "NXP0001")
Name(_CID, "PRP0001")
  Device(Slave1) {
Name(_CID, "PRP0001")
 }
}
is ok or


Device(XYZ) {
Name(_HID, "NXP0001")
Name(_CID, " NXP0001")
  Device(Slave1) {
Name(_CID, " NXP0002")
 }
}
Seems good

I don't think it makes a lot of sense to use the same value for _HID
and _CID, so you can just drop the latter.

Sure,


For sure, AML methods (as needed _ON/OFF/RST/STA etc) /_DSD will to
be
coded in table using either of.


Please see more in line

Regards
Udit


-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]

Re: [edk2] [PATCH edk2-platforms v5 0/6] add remaining support for Socionext SynQuacer

[Leif Lindholm]

On Fri, Nov 17, 2017 at 07:04:17PM +, Ard Biesheuvel wrote:
> These are the remaining patches that still need review after the majority
> of the Socionext SynQuacer support patches were merged.

All remaining patches in series:
Reviewed-by: Leif Lindholm 

> Changes since v4:
> - minor changes, please see the notes in the individual patches
> 
> Changes since v3:
> - remove ACPI support for now, we can add it on top if we manage to sort
>   out all the SoC quirks that make it difficult to have full support under
>   ACPI
> - add RTC support to DeveloperBox
> - add eMMC support to SynQuacerEvalBoard
> - incorporate review feedback on the SPI NOR driver (which was possible
>   after noticing that I did in fact have a manual for this IP)
> - map NOR and EEPROM as writeback cacheable non-shareable; this allows the
>   split FV hack to be reverted, and improves boot time considerably
> - some other minor changes have been applied, these have been added to the
>   individual patches as notes
> 
> Changes since v2:
> - converted NETSEC driver to UEFI driver model
> - added a platform DXE driver that declares the non-discoverable NETSEC
>   device for the UEFI driver model driver to bind to
> - remove hardcoded DRAM information - everything is now retrieved from
>   ARM Trusted Firmware
> - added DT descriptions of the GPIO and interrupt controller IP blocks
> - addressed various style issues and merge errors highlighted by Leif
> 
> Ard Biesheuvel (6):
>   Silicon/SynQuacer: implement 'clear NVRAM' feature using a DIP switch
>   Silicon/SynQuacer: add DT description of the SDHCI controller
>   Silicon/Socionext: implement I2C master protocol for SynQuacer I2C
>   Silicon/NXP: add RTC support library for PCF8563 I2C IP
>   Platform/DeveloperBox: wire up RTC support
>   Platform/SynQuacerEvalBoard: add eMMC driver stack
> 
>  Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
>  |  13 +-
>  Platform/Socionext/DeveloperBox/DeveloperBox.fdf 
>  |   6 +
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
>  |  12 +
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf 
>  |   8 +
>  Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
>  | 402 +
>  Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec  
>  |  31 ++
>  Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf  
>  |  52 ++
>  Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
>  |  27 +
>  Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts
>  |   4 +
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Emmc.c   
>  | 201 +++
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
>  |  88 ++-
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.h
>  |  37 ++
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf  
>  |  11 +-
>  Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/ComponentName.c  
>  | 185 ++
>  Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/DriverBinding.c  
>  | 238 
>  Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c
>  | 588 
>  Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.h
>  | 162 ++
>  Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf  
>  |  59 ++
>  Silicon/Socionext/SynQuacer/Include/Platform/MemoryMap.h 
>  |   8 +
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerMemoryInitPeiLib/SynQuacerMemoryInitPeiLib.c
>  |   4 +
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformPeiLib/SynQuacerPlatformPeiLib.c
>  |  30 +-
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformPeiLib/SynQuacerPlatformPeiLib.inf
>|   6 +
>  Silicon/Socionext/SynQuacer/SynQuacer.dec
>  |   8 +
>  23 files changed, 2160 insertions(+), 20 deletions(-)
>  create mode 100644 
> Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
>  create mode 100644 
> Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec
>  create mode 100644 
> Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf
>  create mode 100644 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Emmc.c
>  create mode 100644 
> Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.h
>  create mode 100644 
> Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/ComponentName.c
>  create mode 100644 
> 

Re: [edk2] [PATCH edk2-platforms v5 1/6] Silicon/SynQuacer: implement 'clear NVRAM' feature using a DIP switch

[Leif Lindholm]

On Fri, Nov 17, 2017 at 07:04:18PM +, Ard Biesheuvel wrote:
> Ordinary computers typically have a physical switch or jumper on the
> board that allows non-volatile settings to be cleared. Let's implement
> the same using DIP switch #1 on block #3, and clear the EFI variable
> store if it is set to ON at boot time.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
> v5: use MAX_UINT8 as 'not implemented' GPIO index

So, you say that ...

>  Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
>|  4 +++
>  Platform/Socionext/DeveloperBox/DeveloperBox.fdf 
>|  1 +
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
>|  4 +++
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf 
>|  1 +
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformPeiLib/SynQuacerPlatformPeiLib.c
>| 30 +++-
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformPeiLib/SynQuacerPlatformPeiLib.inf
>  |  6 
>  Silicon/Socionext/SynQuacer/SynQuacer.dec
>|  3 ++
>  7 files changed, 48 insertions(+), 1 deletion(-)
> 
> diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
> b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> index b73e88c5f29b..6c084efa9fb6 100644
> --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> @@ -381,6 +381,9 @@ [PcdsFixedAtBuild.common]
>gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorId|0x4f524e4c # LNRO
>gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorRevision|1
>  
> +  # set DIP switch DSW3-PIN1 (GPIO pin PD[0] on the SoC) to clear the 
> varstore
> +  gSynQuacerTokenSpaceGuid.PcdClearSettingsGpioPin|0
> +
>  [PcdsPatchableInModule]
>gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|0
>gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|0
> @@ -418,6 +421,7 @@ [Components.common]
>MdeModulePkg/Universal/FaultTolerantWritePei/FaultTolerantWritePei.inf
>MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
>MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> +  Silicon/Socionext/SynQuacer/Drivers/SynQuacerGpioPei/SynQuacerGpioPei.inf
>MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
>  
>
> NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
> diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.fdf 
> b/Platform/Socionext/DeveloperBox/DeveloperBox.fdf
> index 34100bb63da4..6cc523fac4f3 100644
> --- a/Platform/Socionext/DeveloperBox/DeveloperBox.fdf
> +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.fdf
> @@ -258,6 +258,7 @@ [FV.FVMAIN_COMPACT]
>INF MdeModulePkg/Universal/FaultTolerantWritePei/FaultTolerantWritePei.inf
>INF MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
>INF MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> +  INF 
> Silicon/Socionext/SynQuacer/Drivers/SynQuacerGpioPei/SynQuacerGpioPei.inf
>INF RuleOverride = FMP_IMAGE_DESC 
> Platform/Socionext/DeveloperBox/SystemFirmwareDescriptor/SystemFirmwareDescriptor.inf
>INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>  
> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> index dd1469decc5d..c8a9f39cd1ae 100644
> --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> @@ -369,6 +369,9 @@ [PcdsFixedAtBuild.common]
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0842
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0001
>  
> +  # set DIP switch DSW3-PIN1 (GPIO pin PD[0] on the SoC) to clear the 
> varstore
> +  gSynQuacerTokenSpaceGuid.PcdClearSettingsGpioPin|0
> +
>  [PcdsPatchableInModule]
>gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|0
>gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|0
> @@ -406,6 +409,7 @@ [Components.common]
>MdeModulePkg/Universal/FaultTolerantWritePei/FaultTolerantWritePei.inf
>MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
>MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
> +  Silicon/Socionext/SynQuacer/Drivers/SynQuacerGpioPei/SynQuacerGpioPei.inf
>MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
>  
>
> NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf 
> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> index 365085c8f243..4577bd316a1f 100644
> --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> @@ -248,6 +248,7 @@ [FV.FVMAIN_COMPACT]
>INF 

Re: [edk2] [PATCH edk2-platforms v2 00/13] Move ArmPlatformPkg stuff into edk2-platforms

[Leif Lindholm]

On Thu, Nov 16, 2017 at 05:58:30PM +, Ard Biesheuvel wrote:
> This is mostly a preparatory series that will allow us to get rid of a lot
> of code that is specific to only a single ARM development platform out of
> the main EDK2 tree.
> 
> First of all, it removes a couple of false dependencies of various platforms
> on libraries that are no longer used, or not actually used by the platform
> in question. Patches #5, #6 and #11 move the bulk of the support for ARM
> development platforms into edk2-platforms.
> 
> Ard Biesheuvel (13):
>   Platform: remove bogus ArmPlatformSecExtraActionLib references
>   Platform: remove bogus ArmTrustedMonitorLib references
>   Platform/ArmVExpress-FVP: remove bogus ArmPlatformSecLib reference
>   Platform/Hisilicon: remove bogus VExpress dependencies
>   Platform/ARM/Juno: import ArmJunoPkg from EDK2
>   Platform/ARM/VExpress: import VExpressPkg from EDK2

Again, please hold off on this one (import VExpressPkg) for a few days.
As far as I can see, the subsequent ones would not be affected and so
can be merged without conflict.

For all other patches in series:
Reviewed-by: Leif Lindholm 

>   Platform/ARM: remove outdated SP804 TimerLib reference
>   Platform/Hisilicon: remove SP804 PCD definitions
>   Platform: remove references to EBL libraries
>   Platform: remove stale PL35xSmcLib references
>   Platform/ARM: import BootMonFs and ArmShellCmdRunAxf from EDK2
>   Platform: remove stale EBL related PCD setting
>   Platform: switch to new PL011UartLib
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 00/19] ArmPlatformPkg: remove unused or migrated modules

[Leif Lindholm]

On Wed, Nov 15, 2017 at 04:56:18PM +, Ard Biesheuvel wrote:
> Remove everything from ArmPlatformPkg that is either unused, or so highly
> specific to development platforms manufactured by ARM Ltd. that they really
> don't belong in the main branch.
> 
> Note that the migration involves patches against edk2-platforms that add
> some of this code back under Platform/ARM. Most of it (but not all of it)
> has been posted as a separate series already.
> 
> Ard Biesheuvel (19):
>   ArmPkg: remove unused ArmGicSecLib library implementation
>   ArmPlatformPkg: remove ArmPlatformSecLib definition and
> implementations
>   ArmPlatformPkg: remove unused DebugSecExtraActionLib library
>   ArmPlatformPkg: remove ArmTrustedMonitorLib definition and
> implementation
>   ArmPlatformPkg: remove ArmGetCpuCountPerCluster () from ArmPlatformLib
>   ArmPlatformPkg: remove NorFlashArmVExpressLib
>   ArmPlatformPkg: remove ArmJunoPkg
>   ArmPlatformPkg/PL031RealTimeClockLib: drop ArmPlatformSysConfigLib
> reference
>   ArmPlatformPkg: remove ArmVExpressPkg

Please hold off on this one (remove ArmVExpressPkg) until we hear back
from Evan.

>   ArmPlatformPkg: remove ArmPlatformSysConfigLib library class

No separate comment on this one, just to break it away from the below.

>   ArmPlatformPkg: remove unused PL301Axi driver
>   ArmPlatformPkg: remove unused PL35x driver
>   ArmPlatformPkg: remove PL34xDmc driver
>   ArmPlatformPkg: remove unused PL310 driver
>   ArmPlatformPkg: remove unused ArmTrustZone driver
>   ArmPlatformPkg: remove unused SP804 driver and TimerLib
>   implementation

Please separate the "delete used drivers" from the rest of this set.
Let's give potential out-of-tree users a few weeks to respond.

My last working day before sabbatical is 15 Dec, so how about
Reviewed-by-if-no-comments-by-15-Dec: Leif Lindholm 
?

>   ArmPlatformPkg: remove unused L2X0CacheLibNull library
>   ArmPlatformPkg: remove EblCmdLib implementation
>   ArmPlatformPkg: remove BootMonFs and ArmShellCmdRunAxf

For the remainder:
Reviewed-by: Leif Lindholm 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Add EFI lock when creating new gauge record

[Heyi Guo]

Hi Star,

Sorry to make a mistake with the code package :)

Please see my test results below.


在 11/24/2017 5:41 PM, Zeng, Star 写道:

Good problem statement.

EndGaugeEx and GetGaugeEx also need to be updated as they are operating same 
memory buffer, otherwise the performance data may be messed up.

Another idea is to just use a global variable, for example mRecording, to 
prevent reentrance, but that there may be perf data missing.

How to realize " not impacted much " in " the performance measuring data was not 
impacted much by this patch "?
That means there is a little performance impact?
I tested more than 50 times on my platform with the original version and 
the modified one, and calculated the average "Total Duration", which 
were 32567ms and 32600ms respectively. So the performance impact almost 
can be ignored.


Could you re-measure with all StartGaugeEx, EndGaugeEx and GetGaugeEx add lock?

Good point. The above result was tested with all of them locked.

I also attached my patch.

Thanks and regards,

Gary (Heyi Guo)



Cc Liming.


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
Sent: Friday, November 24, 2017 3:04 PM
To: edk2-devel@lists.01.org
Cc: Carsey, Jaben ; Daryl McDaniel 

Subject: [edk2] [RFC] Add EFI lock when creating new gauge record

Hi folks,

We got occasional system exceptions after enabling performance measuring feature 
in edk2. After debugging, we found there is potential memory overflow in 
DXE/DXE_CORE PerformanceLib when PERF_START is reentered, and reentrance is 
possible since we are supporting something like USB hot-plug, which is a timer 
event where gBS->ConnectController might be called and then PERF will be called 
in CoreConnectSingleController.
However I can't reproduce the issue right now; please let me know if PERF 
reentrance is not theoretically possible in the latest edk2 code.

When StartGaugeEx is being reentered, not only the gauge record might be 
overwritten, more serious situation will be caused if gauge data buffer 
reallocation procedure is interrupted, between line 180 and 187 in 
DxeCorePerformanceLib.c specifically. There, mMaxGaugeRecords will be doubled 
twice (denoted as 4X), but mGaugeData only points to a buffer of size 2X, which 
will probably cause the following 2X memory to be overflowed when gauge records 
are increased.

My proposal is to add EFI lock with TPL notify in StartGaugeEx to avoid such 
situation. The test result seemed good on our platforms and the performance 
measuring data was not impacted much by this patch.

Please let me know your comments.

Thanks,

Gary (Heyi Guo)

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


--- Begin Message ---
From: Heyi Guo 

DXE performance gauge record access functions might be reentered since
we are supporting something like USB hot-plug, which is a timer event
where gBS->ConnectController might be called and then PERF will be
called in CoreConnectSingleController.

When StartGaugeEx is being reentered, not only the gauge record might
be overwritten, more serious situation will be caused if gauge data
buffer reallocation procedure is interrupted, between line 180 and 187
in DxeCorePerformanceLib.c specifically. There, mMaxGaugeRecords will
be doubled twice (denoted as 4X), but mGaugeData only points to a
buffer of size 2X, which will probably cause the following 2X memory
to be overflowed when gauge records are increased.

So we add EFI lock with with TPL_NOTIFY in
StartGaugeEx/EndGaugeEx/GetGaugeEx to avoid memory overflow and gauge
data corruption.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo 
---
 .../DxeCorePerformanceLib/DxeCorePerformanceLib.c  | 67 +-
 1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c 
b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
index 51f488a..7c0e207 100644
--- a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
+++ b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
@@ -63,6 +63,11 @@ PERFORMANCE_EX_PROTOCOL mPerformanceExInterface = {
 
 PERFORMANCE_PROPERTY  mPerformanceProperty;
 
+//
+//  Gauge record lock to avoid data corruption or even memory overflow
+//
+STATIC EFI_LOCK mPerfRecordLock = EFI_INITIALIZE_LOCK_VARIABLE (TPL_NOTIFY);
+
 /**
   Searches in the gauge array with keyword Handle, Token, Module and 
Identifier.
 
@@ -162,6 +167,12 @@ StartGaugeEx (
   UINTN OldGaugeDataSize;
   GAUGE_DATA_HEADER *OldGaugeData;
   UINT32Index;
+  EFI_STATUSStatus;
+
+  Status = EfiAcquireLockOrFail ();
+  if (EFI_ERROR (Status)) {
+return