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

2017-12-01 Thread You, Benjamin
Hi Cameron,

> >I get serial output from edk2 with the release build and the debug build.
> >However this serial output does not include the boot menu, I just get 
> >progress
> >and error codes (and debug messages in debug mode).
> >I have attached a runtime log of a recent debug build.

>From your log, I cannot see the below prompt message:

"F2 or Down  to enter Boot Manager Menu.
ENTER   to boot directly."

With my system, there is above message shown in serial. When I press F2
upon the message, the boot manager is shown.

The message is printed in PlatformBootManagerAfterConsole() in 
CorebootPayloadPkg\Library\PlatformBootManagerLib\PlatformBootManager.c.
Not sure what went wrong, but you might add some debug message to trace the
execution flow.

Or, have you been able to boot to UEFI Shell? If yes, you may type "exit"
from the Shell prompt, and boot manager should show up.

Thanks,

- ben

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


Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian MMIO

2017-12-01 Thread Kinney, Michael D
Udit,

I agree with your concern.

I am in favor of adding new APIs that perform the
byte swap operations.

Mike

> -Original Message-
> From: Udit Kumar [mailto:udit.ku...@nxp.com]
> Sent: Friday, December 1, 2017 9:58 AM
> To: Leif Lindholm ; Meenakshi
> Aggarwal ; Varun Sethi
> 
> Cc: Kinney, Michael D ; edk2-
> de...@lists.01.org; Gao, Liming ;
> Ard Biesheuvel 
> Subject: RE: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support
> for big-endian MMIO
> 
> Thanks Leif,
> 
> > It may require a little bit more of up-front work, but
> the end result will be a
> > platform port that works with the intended edk2 design
> principles rather than
> 
> Yes, this will be re-design/code for us, breaking all
> software pieces into
> smaller blocks and exposing protocol from the same.
> This could be managed.
> 
> But how do you see,  if there is such dependency oN lib.
> Say a driver which is in BE mode, and is using DebugLib
> (BaseDebugLibSerialPort)
> And DebugLib uses SerialPortLib, which is in LE mode
> 
> Thanks
> Udit
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Leif
> > Lindholm
> > Sent: Friday, December 01, 2017 4:28 PM
> > To: Meenakshi Aggarwal 
> > Cc: Kinney, Michael D ;
> edk2-devel@lists.01.org;
> > Gao, Liming ; Ard Biesheuvel
> > 
> > Subject: Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add
> support for big-endian
> > MMIO
> >
> > On Thu, Nov 30, 2017 at 04:15:38AM +, Meenakshi
> Aggarwal wrote:
> > > Hi Leif, Mike,
> > >
> > >
> > > NXP boards, at present, have few controllers with big
> endian and other
> > > with little endian memory access.
> >
> > Sure, this is not a problem.
> >
> > > Maximum controllers depend on SocLib library for
> clock information and
> > > endianness for SocLib and controllers is different.
> >
> > OK, I see in SocLib you have something called a Gur
> that is read once (and again
> > does a special per-device Pcd dance for runtime
> selection between
> > byteswapping Mmio and plain Mmio).
> >
> > > So this option will not work for us,
> > >   You would then just do (in your .dsc):
> > >   Platform/NXP/Drivers/WatchDog/WatchDogDxe.inf {
> > >   IoLib|
> > >   }
> > >
> > > Because all libraries included by WatchDog will then
> access BE mode Mmio
> > APIs.
> >
> > Which libraries performing Mmio accesses are you
> intending to include in your
> > watchdog driver? You have submitted none as part of
> this series.
> >
> > > And breaking code into separate modules with
> different access will be
> > > very difficult.
> >
> > It may require a little bit more of up-front work, but
> the end result will be a
> > platform port that works with the intended edk2 design
> principles rather than
> > against them. And that will reduce the overall effort
> (not to mention code
> > duplication).
> >
> > From the patches you have sent, the only required
> change I see (if a
> > byteswapping IoLib was added to edk2) would be to
> create a tiny driver for this
> > "Gur" device that installs a protocol containing a
> single function for reading
> > from that device's register space. That driver can be
> built against the swapping
> > or non-swapping IoLib as appropriate.
> >
> > > Watchdog is not the only module which need BE Mmio
> APIs, we have MMC
> > > and other controllers also with same requirement.
> >
> > And the same solutions are possible everywhere.
> >
> > Best Regards,
> >
> > Leif
> >
> > > We need BE Mmio APIs with a different name.
> > >
> > > Please see the possibility.
> > >
> > > Thanks & Regards,
> > > Meenakshi
> > >
> > > > -Original Message-
> > > > From: Leif Lindholm
> [mailto:leif.lindh...@linaro.org]
> > > > Sent: Thursday, November 30, 2017 1:19 AM
> > > > To: Kinney, Michael D 
> > > > Cc: Meenakshi Aggarwal
> ; Gao, Liming
> > > > ; edk2-devel@lists.01.org;
> Ard Biesheuvel
> > > > 
> > > > Subject: Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add
> support for
> > > > big-endian MMIO
> > > >
> > > > I guess there is no strict rule about a driver only
> directly
> > > > accessing one piece of HW?
> > > >
> > > > Still, that would be one possible solution:
> breaking accesses to a
> > > > separate HW in need of byteswapping out into its
> own module and
> > > > letting it override IoLib version there.
> > > >
> > > > Regards,
> > > >
> > > > Leif
> > > >
> > > > On Wed, Nov 29, 2017 at 07:25:05PM +, Kinney,
> Michael D wrote:
> > > > > Leif,
> > > > >
> > > > > I agree that this should be described as byte
> swapping.
> > > > >
> > > > > What about a module that needs to access HW with
> and without the
> > > > > bytes swapped?  It 

Re: [edk2] [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add debug asserts

2017-12-01 Thread Leif Lindholm
On Fri, Dec 01, 2017 at 05:34:52PM +, Ard Biesheuvel wrote:
> On 1 December 2017 at 16:33, Evan Lloyd  wrote:
> > Responses inline:
> >
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: 13 October 2017 08:33
> >> To: Evan Lloyd 
> >> Cc: edk2-devel@lists.01.org; "ard.biesheu...@linaro.org"@arm.com;
> >> "leif.lindh...@linaro.org"@arm.com;
> >> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
> >> Subject: Re: [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add
> >> debug asserts
> >>
> >> On 26 September 2017 at 21:15,   wrote:
> >> > From: Girish Pathak 
> >> >
> >> > This change adds some debug assertions e.g to catch NULL pointer
> >> > errors missing in PL11Lcd and HdLcd modules.
> >> >
> >> > This change also improves related error handling code.
> >> >
> >> > Contributed-under: TianoCore Contribution Agreement 1.1
> >> > Signed-off-by: Girish Pathak 
> >> > Signed-off-by: Evan Lloyd 
> >> > ---
> >> >
> >> ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdAr
> >> mVExpress.c   | 44 ++--
> >> >
> >> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL11
> >> 1LcdArmVExpress.c | 43 ++-
> >> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/HdLcd.c
> >> |  8 ++--
> >> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c
> >> |  8 ++--
> >> >  4 files changed, 90 insertions(+), 13 deletions(-)
> >> >
> >> > diff --git
> >> >
> >> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> >> ArmVE
> >> > xpress.c
> >> >
> >> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> >> ArmVE
> >> > xpress.c index
> >> >
> >> b9859a56988f7e5be0adbaa49048a683fe586bfe..58dd9f0c77e1bc9af559a
> >> 71d0c7c
> >> > ce72d71c6da5 100644
> >> > ---
> >> >
> >> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> >> ArmVE
> >> > xpress.c
> >> > +++
> >> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> >> A
> >> > +++ rmVExpress.c
> >> > @@ -140,6 +140,7 @@ LcdPlatformInitializeDisplay (
> >> >* buffer in bytes
> >> >*
> >> >* @retval EFI_SUCCESS Frame buffer memory allocation 
> >> > success.
> >> > +  * @retval EFI_INVALID_PARAMETER   VramBaseAddress or VramSize
> >> are NULL.
> >> >* @retval !(EFI_SUCCESS)  Other errors.
> >> >  **/
> >> >  EFI_STATUS
> >> > @@ -151,6 +152,13 @@ LcdPlatformGetVram (
> >> >EFI_STATUS  Status;
> >> >EFI_ALLOCATE_TYPE   AllocationType;
> >> >
> >> > +  // Check VramBaseAddress and VramSize are not NULL.
> >> > +  if (VramBaseAddress == NULL || VramSize == NULL) {
> >> > +ASSERT (VramBaseAddress != NULL);
> >> > +ASSERT (VramSize != NULL);
> >> > +return EFI_INVALID_PARAMETER;
> >> > +  }
> >> > +
> >> >// Set the vram size
> >> >*VramSize = LCD_VRAM_SIZE;
> >> >
> >> > @@ -169,6 +177,7 @@ LcdPlatformGetVram (
> >> >VramBaseAddress
> >> >);
> >> >if (EFI_ERROR (Status)) {
> >> > +ASSERT_EFI_ERROR (Status);
> >> >  return Status;
> >> >}
> >> >
> >> > @@ -179,8 +188,8 @@ LcdPlatformGetVram (
> >> >*VramSize,
> >> >EFI_MEMORY_WC
> >> >);
> >> > -  ASSERT_EFI_ERROR (Status);
> >> >if (EFI_ERROR (Status)) {
> >> > +ASSERT_EFI_ERROR (Status);
> >>
> >> What is the point of this change?
> > [[Evan Lloyd]] It is a minor efficiency improvement.  Since the
> > ASSERT can only fire when the if condition is true, it removes a
> > duplicated test from the main (non-error) code flow.  This is
> > irrelevant on hardware, but actually significant when running
> > debug builds on an emulator environment.
> 
> Fair enough. But I'd prefer to finally fix the DEBUG vs NOOPT build
> targets for ARM/AARCH64. DEBUG was never intended to be -O0 (and it is
> not on X86 either).
> 
> Code is complex enough as it is, and how to move trivial tests like
> this around for 'performance' reasons is a dimension I would like to
> avoid.

Echoing from an irc discussion with Ard:
I think NOOPT (and a !-O0 DEBUG) would be good to have for the ARM
architectures as well, both for GCC and CLANG.

Evan, have you done any investigation into the impact of optimization
on emulation performance?

My completely unfounded guess would be -O1 should be a good fit for
that environment, and hence for DEBUG. It would remove some of the
more insane bloat of -O0 without starting heavy inlining.
But as always, real numbers beat guesses.

(If -O2 is better than -O1, is -Os better than either?)

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


Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian MMIO

2017-12-01 Thread Udit Kumar
Thanks Leif, 

> It may require a little bit more of up-front work, but the end result will be 
> a
> platform port that works with the intended edk2 design principles rather than

Yes, this will be re-design/code for us, breaking all software pieces into
smaller blocks and exposing protocol from the same. 
This could be managed.

But how do you see,  if there is such dependency oN lib. 
Say a driver which is in BE mode, and is using DebugLib (BaseDebugLibSerialPort)
And DebugLib uses SerialPortLib, which is in LE mode 

Thanks 
Udit

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif
> Lindholm
> Sent: Friday, December 01, 2017 4:28 PM
> To: Meenakshi Aggarwal 
> Cc: Kinney, Michael D ; edk2-devel@lists.01.org;
> Gao, Liming ; Ard Biesheuvel
> 
> Subject: Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian
> MMIO
> 
> On Thu, Nov 30, 2017 at 04:15:38AM +, Meenakshi Aggarwal wrote:
> > Hi Leif, Mike,
> >
> >
> > NXP boards, at present, have few controllers with big endian and other
> > with little endian memory access.
> 
> Sure, this is not a problem.
> 
> > Maximum controllers depend on SocLib library for clock information and
> > endianness for SocLib and controllers is different.
> 
> OK, I see in SocLib you have something called a Gur that is read once (and 
> again
> does a special per-device Pcd dance for runtime selection between
> byteswapping Mmio and plain Mmio).
> 
> > So this option will not work for us,
> >   You would then just do (in your .dsc):
> >   Platform/NXP/Drivers/WatchDog/WatchDogDxe.inf {
> >   IoLib|
> >   }
> >
> > Because all libraries included by WatchDog will then access BE mode Mmio
> APIs.
> 
> Which libraries performing Mmio accesses are you intending to include in your
> watchdog driver? You have submitted none as part of this series.
> 
> > And breaking code into separate modules with different access will be
> > very difficult.
> 
> It may require a little bit more of up-front work, but the end result will be 
> a
> platform port that works with the intended edk2 design principles rather than
> against them. And that will reduce the overall effort (not to mention code
> duplication).
> 
> From the patches you have sent, the only required change I see (if a
> byteswapping IoLib was added to edk2) would be to create a tiny driver for 
> this
> "Gur" device that installs a protocol containing a single function for reading
> from that device's register space. That driver can be built against the 
> swapping
> or non-swapping IoLib as appropriate.
> 
> > Watchdog is not the only module which need BE Mmio APIs, we have MMC
> > and other controllers also with same requirement.
> 
> And the same solutions are possible everywhere.
> 
> Best Regards,
> 
> Leif
> 
> > We need BE Mmio APIs with a different name.
> >
> > Please see the possibility.
> >
> > Thanks & Regards,
> > Meenakshi
> >
> > > -Original Message-
> > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > > Sent: Thursday, November 30, 2017 1:19 AM
> > > To: Kinney, Michael D 
> > > Cc: Meenakshi Aggarwal ; Gao, Liming
> > > ; edk2-devel@lists.01.org; Ard Biesheuvel
> > > 
> > > Subject: Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for
> > > big-endian MMIO
> > >
> > > I guess there is no strict rule about a driver only directly
> > > accessing one piece of HW?
> > >
> > > Still, that would be one possible solution: breaking accesses to a
> > > separate HW in need of byteswapping out into its own module and
> > > letting it override IoLib version there.
> > >
> > > Regards,
> > >
> > > Leif
> > >
> > > On Wed, Nov 29, 2017 at 07:25:05PM +, Kinney, Michael D wrote:
> > > > Leif,
> > > >
> > > > I agree that this should be described as byte swapping.
> > > >
> > > > What about a module that needs to access HW with and without the
> > > > bytes swapped?  It gets more complex if a module is linked against
> > > > several libs and some libs access HW with bytes swapped and some
> > > > do not.
> > > >
> > > > Thanks,
> > > >
> > > > Mike
> > > >
> > > > > -Original Message-
> > > > > From: edk2-devel [mailto:edk2-devel- boun...@lists.01.org] On
> > > > > Behalf Of Leif Lindholm
> > > > > Sent: Wednesday, November 29, 2017 4:51 AM
> > > > > To: Meenakshi Aggarwal ; Gao, Liming
> > > > > 
> > > > > Cc: Kinney, Michael D ;
> > > > > edk2-devel@lists.01.org; Ard Biesheuvel
> > > > > 
> > > > > Subject: Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for
> > > > > big-endian MMIO
> > > > >
> > > > > Hi Meenakshi,
> > > > >
> > > > > I finally got around to looking at the watchdog code (that uses
> > > > > this 

Re: [edk2] [PATCH edk2-platforms v2] Silicon/SynQuacer: enable coherent DMA for NETSEC and eMMC

2017-12-01 Thread Ard Biesheuvel
On 1 December 2017 at 12:57, Leif Lindholm  wrote:
> On Thu, Nov 30, 2017 at 06:53:55PM +, Ard Biesheuvel wrote:
>> As it turns out, it is surprisingly easy to configure both the NETSEC
>> and eMMC devices as cache coherent for DMA, given that they are both
>> behind the same SMMU which is already configured in passthrough mode
>> by the firmware running on the SCP.
>>
>> So update the static SMMU configuration to make memory accesses performed
>> by these devices inner shareable inner/outer writeback cacheable, which
>> makes them cache coherent with the CPUs.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>
> Looks fine to me:
> Reviewed-by: Leif Lindholm 
> (If you want to hold back for Tested-by:s, feel free to.)
>

Thanks. It actually depends on the patch that adds the EMMC driver
stack, which depends on the SD/MMC override patches for EDK2, so it
needs to wait anyway.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms] Silicon/Fip006Dxe: map NOR_FLASH_INFO FSR flag with instance flag

2017-12-01 Thread Ard Biesheuvel
On 1 December 2017 at 12:59, Leif Lindholm  wrote:
> On Thu, Nov 30, 2017 at 06:58:28PM +, Ard Biesheuvel wrote:
>> From: Pipat Methavanitpong 
>>
>> Now that we incorporated NorFlashInfoLib into the Fip006Dxe driver,
>> replace the code that explicitly enables flag status register polling
>> for Micron NOR flash with a test of the flags field provided by
>> NorFlashInfoLib, which carries the same information.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Pipat Methavanitpong 
>> Signed-off-by: Ard Biesheuvel 
>
> Reviewed-by: Leif Lindholm 
>

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


Re: [edk2] [PATCH 18/19] ArmPlatformPkg: Reserving framebuffer at build

2017-12-01 Thread Ard Biesheuvel
On 1 December 2017 at 16:56, Evan Lloyd  wrote:
> Responses inline
>
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: 25 October 2017 19:10
>> To: Evan Lloyd 
>> Cc: edk2-devel@lists.01.org; "ard.biesheu...@linaro.org"@arm.com;
>> "leif.lindh...@linaro.org"@arm.com;
>> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
>> Subject: Re: [PATCH 18/19] ArmPlatformPkg: Reserving framebuffer at
>> build
>>
>> On 26 September 2017 at 21:15,   wrote:
>> > From: Girish Pathak 
>> >
>> > Currently frame buffer memory is either reserved in special VRAM or
>> > dynamically allocated using boot services memory allocation functions.
>> > When allocated using boot services calls the memory has to be
>> > allocated as EfiBootServicesData. Unfortunately failures have been
>> > seen with this case.  There is also an unfortunate lack of control on
>> > the placement of the frmae buffer.
>> >
>> > This change introduces two PCDs, PcdArmLcdFrameBufferBase and
>> > PcdArmLcdFrameBufferSize which enable build time reservation of the
>> > frame buffer, avoiding the need to allocate dynamically.  This allows
>> > the frame buffer to appear as "I/O memory" outside of the normal RAM
>> > map, which is similar to the "VRAM" case.
>> >
>> > This change has no impact on current code, only enables the option of
>> > build time reservation of frame buffers.
>> >
>>
>> Where is the memory actually being reserved? And if it is reserved, how can
>> the OS reclaim it if it is not interested in using the GOP?
>
> [[Evan Lloyd]] The memory is reserved by whatever sets the Pcd - normally the 
> .dsc.  It may or may not be system RAM.
> If it is excised from system memory, then there is no way for the OS to 
> reclaim it, as it can't differentiate that from the VRAM case.
> I'm not sure I see the relevance of that anyway.  Is our objective to provide 
> restricted firmware tightly tuned for a specific operating system in an 
> unrealistic mode, or to provide a generic example of firmware exercising the 
> standard interfaces and testing real use cases?
>

Is that intended as a rhetorical question? If you introduce a feature
that may take away RAM from the OS without a way to reclaim it, that
deserves a comment. At the very least, it would have saved me from
having to ask about it specifically.

Whether doing so is justified is another question, but that depends on
the expected users of this code (hence the need to document it)

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


Re: [edk2] [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add debug asserts

2017-12-01 Thread Ard Biesheuvel
On 1 December 2017 at 16:33, Evan Lloyd  wrote:
> Responses inline:
>
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: 13 October 2017 08:33
>> To: Evan Lloyd 
>> Cc: edk2-devel@lists.01.org; "ard.biesheu...@linaro.org"@arm.com;
>> "leif.lindh...@linaro.org"@arm.com;
>> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
>> Subject: Re: [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add
>> debug asserts
>>
>> On 26 September 2017 at 21:15,   wrote:
>> > From: Girish Pathak 
>> >
>> > This change adds some debug assertions e.g to catch NULL pointer
>> > errors missing in PL11Lcd and HdLcd modules.
>> >
>> > This change also improves related error handling code.
>> >
>> > Contributed-under: TianoCore Contribution Agreement 1.1
>> > Signed-off-by: Girish Pathak 
>> > Signed-off-by: Evan Lloyd 
>> > ---
>> >
>> ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdAr
>> mVExpress.c   | 44 ++--
>> >
>> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL11
>> 1LcdArmVExpress.c | 43 ++-
>> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/HdLcd.c
>> |  8 ++--
>> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c
>> |  8 ++--
>> >  4 files changed, 90 insertions(+), 13 deletions(-)
>> >
>> > diff --git
>> >
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
>> ArmVE
>> > xpress.c
>> >
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
>> ArmVE
>> > xpress.c index
>> >
>> b9859a56988f7e5be0adbaa49048a683fe586bfe..58dd9f0c77e1bc9af559a
>> 71d0c7c
>> > ce72d71c6da5 100644
>> > ---
>> >
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
>> ArmVE
>> > xpress.c
>> > +++
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
>> A
>> > +++ rmVExpress.c
>> > @@ -140,6 +140,7 @@ LcdPlatformInitializeDisplay (
>> >* buffer in bytes
>> >*
>> >* @retval EFI_SUCCESS Frame buffer memory allocation 
>> > success.
>> > +  * @retval EFI_INVALID_PARAMETER   VramBaseAddress or VramSize
>> are NULL.
>> >* @retval !(EFI_SUCCESS)  Other errors.
>> >  **/
>> >  EFI_STATUS
>> > @@ -151,6 +152,13 @@ LcdPlatformGetVram (
>> >EFI_STATUS  Status;
>> >EFI_ALLOCATE_TYPE   AllocationType;
>> >
>> > +  // Check VramBaseAddress and VramSize are not NULL.
>> > +  if (VramBaseAddress == NULL || VramSize == NULL) {
>> > +ASSERT (VramBaseAddress != NULL);
>> > +ASSERT (VramSize != NULL);
>> > +return EFI_INVALID_PARAMETER;
>> > +  }
>> > +
>> >// Set the vram size
>> >*VramSize = LCD_VRAM_SIZE;
>> >
>> > @@ -169,6 +177,7 @@ LcdPlatformGetVram (
>> >VramBaseAddress
>> >);
>> >if (EFI_ERROR (Status)) {
>> > +ASSERT_EFI_ERROR (Status);
>> >  return Status;
>> >}
>> >
>> > @@ -179,8 +188,8 @@ LcdPlatformGetVram (
>> >*VramSize,
>> >EFI_MEMORY_WC
>> >);
>> > -  ASSERT_EFI_ERROR (Status);
>> >if (EFI_ERROR (Status)) {
>> > +ASSERT_EFI_ERROR (Status);
>>
>> What is the point of this change?
> [[Evan Lloyd]] It is a minor efficiency improvement.  Since the ASSERT can 
> only fire when the if condition is true, it removes a duplicated test from 
> the main (non-error) code flow.  This is irrelevant on hardware, but actually 
> significant when running debug builds on an emulator environment.
>

Fair enough. But I'd prefer to finally fix the DEBUG vs NOOPT build
targets for ARM/AARCH64. DEBUG was never intended to be -O0 (and it is
not on X86 either).

Code is complex enough as it is, and how to move trivial tests like
this around for 'performance' reasons is a dimension I would like to
avoid.

>>
>> >  gBS->FreePages (*VramBaseAddress, EFI_SIZE_TO_PAGES (*VramSize));
>> >  return Status;
>> >}
>> > @@ -215,6 +224,7 @@ LcdPlatformSetMode (
>> >EFI_STATUSStatus;
>> >
>> >if (ModeNumber >= LcdPlatformGetMaxMode ()) {
>> > +ASSERT (ModeNumber < LcdPlatformGetMaxMode ());
>> >  return EFI_INVALID_PARAMETER;
>> >}
>> >
>> > @@ -264,6 +274,7 @@ LcdPlatformSetMode (
>> >*
>> >* @retval EFI_SUCCESS Success if the requested mode is 
>> > found.
>> >* @retval EFI_INVALID_PARAMETER   Requested mode not found.
>> > +  * @retval EFI_INVALID_PARAMETER   Info is NULL.
>> >  **/
>> >  EFI_STATUS
>> >  LcdPlatformQueryMode (
>> > @@ -271,7 +282,9 @@ LcdPlatformQueryMode (
>> >OUT EFI_GRAPHICS_OUTPUT_MODE_INFORMATION * CONST  Info
>> >)
>> >  {
>> > -  if (ModeNumber >= LcdPlatformGetMaxMode ()) {
>> > +  if (ModeNumber >= LcdPlatformGetMaxMode () || Info == NULL) {
>> > +ASSERT (ModeNumber < LcdPlatformGetMaxMode ());
>>
>> Please don't put anything that may 

Re: [edk2] [PATCH 03/19] ArmPlatformPkg: PL111 and HDLCD: add const qualifier

2017-12-01 Thread Ard Biesheuvel
On 1 December 2017 at 16:17, Evan Lloyd  wrote:
> Hi Ard.
> Response inline below
>
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: 12 October 2017 20:47
>> To: Evan Lloyd 
>> Cc: edk2-devel@lists.01.org; "ard.biesheu...@linaro.org"@arm.com;
>> "leif.lindh...@linaro.org"@arm.com;
>> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
>> Subject: Re: [PATCH 03/19] ArmPlatformPkg: PL111 and HDLCD: add const
>> qualifier
>>
>> On 26 September 2017 at 21:15,   wrote:
>> > From: Girish Pathak 
>> >
>> > This change adds some STATIC and CONST qualifiers (mainly to arguments
>> > of  functions) in PL111 and HdLcd modules.
>> >
>> > It doesn't add or modify any functionality.
>> >
>> > Contributed-under: TianoCore Contribution Agreement 1.1
>> > Signed-off-by: Girish Pathak 
>> > Signed-off-by: Evan Lloyd 
>> > ---
>> >
>> ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdAr
>> mVExpress.c   | 34 ++--
>> >
>> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL11
>> 1LcdArmVExpress.c | 34 ++--
>> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/HdLcd.c
>> |  4 +--
>> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c
>> |  4 +--
>> >  4 files changed, 38 insertions(+), 38 deletions(-)
>> >
>> > diff --git
>> >
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
>> ArmVE
>> > xpress.c
>> >
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
>> ArmVE
>> > xpress.c index
>> >
>> cfe3259d3c737de240350e8c3eab867b80c40948..b9859a56988f7e5be0ad
>> baa49048
>> > a683fe586bfe 100644
>> > ---
>> >
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
>> ArmVE
>> > xpress.c
>> > +++
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
>> A
>> > +++ rmVExpress.c
>> > @@ -46,7 +46,7 @@ typedef struct {
>> >
>> >  /** The display modes supported by the platform.
>> >  **/
>> > -LCD_RESOLUTION mResolutions[] = {
>> > +STATIC CONST LCD_RESOLUTION mResolutions[] = {
>> >{ // Mode 0 : VGA : 640 x 480 x 24 bpp
>> >  VGA, VGA_H_RES_PIXELS, VGA_V_RES_PIXELS,
>> LCD_BITS_PER_PIXEL_24,
>> >  VGA_OSC_FREQUENCY,
>> > @@ -144,8 +144,8 @@ LcdPlatformInitializeDisplay (  **/  EFI_STATUS
>> > LcdPlatformGetVram (
>> > -  OUT EFI_PHYSICAL_ADDRESS*  VramBaseAddress,
>> > -  OUT UINTN* VramSize
>> > +  OUT EFI_PHYSICAL_ADDRESS * CONST  VramBaseAddress,
>> > +  OUT UINTN * CONST VramSize
>>
>> What is the point of this CONST (and all the other occurrences in this patch)
>>
>> In all cases [AFAICT] the CONST applies to the argument itself, not to the
>> object it points to, which means the variable is CONST in the scope of the
>> function, but can still be dereferenced to assign the OUT value.
>>
>> This means your change is technically correct, but it is extremely
>> unidiomatic for EDK2, so an explanation why this driver needs this would be
>> highly appreciated.
>>
> [[Evan Lloyd]] The style is explicitly sanctioned by the Edk2 CCS ยง 5.6.2.4.2
> " Constant pointer to variable: UINTN * CONST ConstPointer;
> ConstPointer is a constant pointer to a variable UINTN."
>

That paragraph is not about function prototypes, but about constant
pointers in general.

> The real benefit is that it clearly identifies the pointer as not changed in 
> the function.
> In this specific instance that also makes it obvious that the OUT parameters 
> are not array bases, just pointers to individual values.
>
> On a broader note - why would you ever not have a const where something is 
> not modified?
>
> As another view, the "unidiomatic for EDK2" argument implies you have a very 
> high opinion of the existing ArmPlatformPkg code quality.
> The  "we have always done it that way" argument does not encourage quality 
> improvements.
>

This may all be true. But the fact remains that 99% of the EDK2 code
does not constify its function parameters, and I was simply asking why
we should deviate from that in this driver.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650 GOP driver.

2017-12-01 Thread Leif Lindholm
On Fri, Dec 01, 2017 at 01:12:49PM +, Evan Lloyd wrote:
> > whatsoever. If you introduce any library classes that abstract away
> > the differences between platforms, you can include a Null version of
> > such a library that simply does ASSERT (FALSE) in every function: this
> 
>  [[Evan Lloyd]] One could, indeed, do that.  We, however, would be
>  very reluctant to incur the overhead of rework in response to
>  spurious cavils from a maintainer when it is of no direct relevance
>  to us.

Rework is the expected norm for the first version of any patchset.
If that is not calculated into your schedules, you will continue to be
disappointed.

An open source project is not a scrapyard for proprietary code, it is
a collaborative environment where people and organisations work
together to achieve better results than they could hope for
individually.
Like these suggestions for rework are of no direct relevance to you,
your patches are of no direct relevance for the project - yet we have
taken the time to sit down, try to understand them, and give feedback
on how they could be improved to be of greater value to the community
as a whole.

I don't think I would be taking to hard a line if I suggest that you
apologise to Ard for your statement above.

Yes, we're all permitted to get annoyed and throw our toys out of the
pram from time to time, but personal attacks are not acceptable.

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


Re: [edk2] [PrintLib] Question about ASSERT_UNICODE_BUFFER

2017-12-01 Thread Kinney, Michael D
Gary,

The correct solution is to align the Unicode string buffer before using those 
APIs.

The assert for unaligned Unicode string has been in place for over 10 years, 
and we have always
been able to address this type of issue by fixing the calling code.

Mike

From: heyi.guo [mailto:heyi@linaro.org]
Sent: Thursday, November 30, 2017 10:58 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Kinney, Michael D 

Subject: [PrintLib] Question about ASSERT_UNICODE_BUFFER

Hi folks,

I think platforms supported in EDK2 should enable unaligned data access, so a 
CHAR16 * pointer still works even if the pointer itself is not aligned by 2. 
Therefore, can we remove ASSERT_UNICODE_BUFFER statements in PrintLib for 
Unicode operations? If the platform doesn't support unaligned access, it can 
generate some kind of exception instead of software assert.

The background is that we are importing a 3rd party driver and it packs a 
unicode string buffer into a structure, and #pragma pack(1) is used around the 
definition of this structure. So the alignment of the string buffer depends on 
the address of the whole structure and the members before it; it happened to be 
not aligned and we got assert during system post.

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


Re: [edk2] [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650 GOP driver.

2017-12-01 Thread Ard Biesheuvel
On 1 December 2017 at 13:12, Evan Lloyd  wrote:
>
>
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: 28 November 2017 18:18
>> To: Evan Lloyd 
>> Cc: edk2-devel@lists.01.org; Matteo Carlini ;
>> Leif Lindholm ; Girish Pathak
>> 
>> Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650
>> GOP driver.
>>
>> On 26 September 2017 at 21:15,   wrote:
>> > From: Girish Pathak 
>> >
>> > This change adds support for the ARM Mali DP500/DP500/DP650 display
>> > processors using the GOP protocol. It has been tested on FVP base
>> > models + DP550 support.
>> >
>> > This change does not modify functionality provided by PL111 or
>> > HDLCD. The driver should be suitable for those platforms
>> > that implement ARM Mali DP500/DP550/DP650 replacing PL111/HDLCD.
>> >
>> > Only "Layer Graphics" of the ARM Mali DP is configured for rendering
>> > the RGB/BGR format frame buffer to satisfy the UEFI GOP requirements
>> > Other layers e.g. video layers are not configured.
>> >
>> > NOTE: This change implements the Mali DP on models. Versions for actual
>> > hardware are liable to require extra handling for clock input changes,
>> > etc.
>> >
>> > Contributed-under: TianoCore Contribution Agreement 1.1
>> > Signed-off-by: Girish Pathak 
>> > Signed-off-by: Evan Lloyd 
>>
>> Hello Girish, Evan,
>>
>> (replying to 19/19 because I cannot find the cover letter in my
>> edk2-devel archive but this really applies to the whole series)
>>
>> I have been looking at these patches again now that I am trying to
>> clean up ArmPlatformPkg, which is currently a dumping ground for all
>> things vaguely ARM related, and is also structured quite differently
>> from other packages.
>>
>> Ideally, ArmPlatformPkg should only contain the following:
>> - library class interfaces under Include/Library; header files kept
>> here should only contain elements that define API
>> - driver specific include files Include/IndustryStandard but *only* if
>> they cannot be kept locally with the driver in question
>> - libraries under Library/
>> - drivers under Drivers/
>>
>> This aligns with the common arrangement adopted by most EDK2 packages.
>>
>> This series does many different things, and does not distinguish at
>> all between common code and code living under ArmVExpressPkg. Given
>
>  [[Evan Lloyd]] All of the commits in the series are in ArmPlatformPkg.
> You may be in the process of disentangling the VE specific bits, but hitherto 
> that has not been a consideration.  (Note: I'm not arguing against the 
> disentangling, only pointing out that it was not a factor at the point we 
> submitted the patches)
> The reason there are so many commits is only that we have been asked to break 
> things up into "bite sized" chunks for the convenience of maintainers.
> The aim was to make each a coherent item with a simple justification.
>
>> that I am trying to move ArmVExpressPkg out of EDK2 into
>> edk2-platforms (where it arguably belongs) having this series in limbo
>> for two months is basically blocking my work, and so I would like to
>> explore ways to proceed with this without interfering with each
>> other's work too much. At the same time, the way the code is
>> structured is a continuation of the pattern I am trying to get rid of,
>> so they will need some rework anyway in order to be upstreamable IMHO.
>
>  [[Evan Lloyd]] Not being psychic, we had not made allowance for your plans.
> However, if you take the trouble to look at the changes, they achieve exactly 
> the split you aim for.
> The display type code (PL011 and HDLCD) is unravelled from the VE code.
> All that remains would be to move the VE specific part into edk2-platforms.
>
>>
>> So could we split it up please? Assuming the intention is the ability
>> to reuse the Mali code on non-VExpress platforms, I would like to see
>> that code proposed separately, without any mention of VExpressPkg.dec
>
>  [[Evan Lloyd]] Given that the original code was unfortunate, I'm not sure 
> that it makes much difference what order the changes get made.
> Going West then North gets you to the same place as North then West  (except 
> near a pole).
> If you accept that there was a logical progression in the changes made, then 
> it might be better to not rejig things pointlessly.
>
>> whatsoever. If you introduce any library classes that abstract away
>> the differences between platforms, you can include a Null version of
>> such a library that simply does ASSERT (FALSE) in every function: this
>
>  [[Evan Lloyd]] One could, indeed, do that.  We, however, would be very 
> reluctant to incur the overhead of rework in response to spurious cavils from 
> a maintainer when it is of no direct relevance to us.
>

I don't think the suggestion that we evil 

Re: [edk2] [PATCH 2/2] QuarkPlatformPkg: Use DpDynamicCommand to replace PerformancePkg/dp

2017-12-01 Thread Steele, Kelly
Reviewed-by: Steele, Kelly 

My only comment is the fix in Quark.fdf, line #575:
# File System Modules 
# 
-!if $(PERFORMANCE_ENABLE)
-INF  MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
-!else
+!if not $(PERFORMANCE_ENABLE)
 INF  MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
 INF  MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
 INF  FatPkg/EnhancedFatDxe/Fat.inf
 !endif

I would suggest going with the following to keep with the style present in the 
rest of the file: 
# File System Modules 
#
!if $(PERFORMANCE_ENABLE)
-INF  MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
!else
 INF  MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
 INF  MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
 INF  FatPkg/EnhancedFatDxe/Fat.inf
 !endif

Thanks,
Kelly

-Original Message-
From: Ni, Ruiyu 
Sent: November 29, 2017 00:15
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Steele, Kelly 

Subject: [PATCH 2/2] QuarkPlatformPkg: Use DpDynamicCommand to replace 
PerformancePkg/dp

Remove FvSimpleFileSystemDxe from Quark.dsc/fdf because it's not needed by 
using DpDynamicCommand driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Michael D Kinney 
Cc: Kelly Steele 
---
 QuarkPlatformPkg/Quark.dsc| 15 +++
 QuarkPlatformPkg/Quark.fdf| 16 +---
 QuarkPlatformPkg/QuarkMin.dsc | 13 -  
QuarkPlatformPkg/QuarkMin.fdf | 12 
 4 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/QuarkPlatformPkg/Quark.dsc b/QuarkPlatformPkg/Quark.dsc index 
025653eee5..5624451e12 100644
--- a/QuarkPlatformPkg/Quark.dsc
+++ b/QuarkPlatformPkg/Quark.dsc
@@ -163,6 +163,9 @@ [LibraryClasses]
   
PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
 !endif
 
+  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
+  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
+
   OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
   IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -864,9 +867,6 @@ [Components.IA32]
   MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
   MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
   FatPkg/EnhancedFatDxe/Fat.inf
-!if $(PERFORMANCE_ENABLE)
-  MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
-!endif
 
   #
   # Capsule update
@@ -887,10 +887,11 @@ [Components.IA32]
   # Performance Application
   #
 !if $(PERFORMANCE_ENABLE)
-  PerformancePkg/Dp_App/Dp.inf {
+  ShellPkg/DynamicCommand/DpDynamicCommand/DpDynamicCommand.inf {
+
+  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
 
-  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
-  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
+  
+ PerformanceLib|MdeModulePkg/Library/DxeSmmPerformanceLib/DxeSmmPerform
+ anceLib.inf
   }
 !endif
 
@@ -910,8 +911,6 @@ [Components.IA32]
   
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
   
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
   
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
-  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
-  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
   
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
 
diff --git a/QuarkPlatformPkg/Quark.fdf b/QuarkPlatformPkg/Quark.fdf index 
19533b2281..5abe3b6f31 100644
--- a/QuarkPlatformPkg/Quark.fdf
+++ b/QuarkPlatformPkg/Quark.fdf
@@ -2,7 +2,7 @@
 # FDF file of Clanton Peak CRB platform with 32-bit DXE  #  # This package 
provides QuarkNcSocId platform specific modules.
-# Copyright (c) 2013 - 2016 Intel Corporation.
+# Copyright (c) 2013 - 2017 Intel Corporation.
 #
 # This program and the accompanying materials  # are licensed and made 
available under the terms and conditions of the BSD License @@ -574,14 +574,19 
@@ [FV.FVMAIN]  #  # File System Modules  # -!if $(PERFORMANCE_ENABLE) -INF  
MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
-!else
+!if not $(PERFORMANCE_ENABLE)
 INF  MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
 INF  MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
 INF  FatPkg/EnhancedFatDxe/Fat.inf
 !endif
 
+#
+# Performance Application
+#
+!if $(PERFORMANCE_ENABLE)
+INF  ShellPkg/DynamicCommand/DpDynamicCommand/DpDynamicCommand.inf
+!endif
+
 #
 # Trusted Platform Module
 #
@@ -677,9 +682,6 @@ [FV.PAYLOAD]
 # Shell and Applications
 #
 INF  RuleOverride = TIANOCOMPRESSED 

Re: [edk2] [PATCH 18/19] ArmPlatformPkg: Reserving framebuffer at build

2017-12-01 Thread Evan Lloyd
Responses inline

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 25 October 2017 19:10
> To: Evan Lloyd 
> Cc: edk2-devel@lists.01.org; "ard.biesheu...@linaro.org"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
> Subject: Re: [PATCH 18/19] ArmPlatformPkg: Reserving framebuffer at
> build
>
> On 26 September 2017 at 21:15,   wrote:
> > From: Girish Pathak 
> >
> > Currently frame buffer memory is either reserved in special VRAM or
> > dynamically allocated using boot services memory allocation functions.
> > When allocated using boot services calls the memory has to be
> > allocated as EfiBootServicesData. Unfortunately failures have been
> > seen with this case.  There is also an unfortunate lack of control on
> > the placement of the frmae buffer.
> >
> > This change introduces two PCDs, PcdArmLcdFrameBufferBase and
> > PcdArmLcdFrameBufferSize which enable build time reservation of the
> > frame buffer, avoiding the need to allocate dynamically.  This allows
> > the frame buffer to appear as "I/O memory" outside of the normal RAM
> > map, which is similar to the "VRAM" case.
> >
> > This change has no impact on current code, only enables the option of
> > build time reservation of frame buffers.
> >
>
> Where is the memory actually being reserved? And if it is reserved, how can
> the OS reclaim it if it is not interested in using the GOP?

[[Evan Lloyd]] The memory is reserved by whatever sets the Pcd - normally the 
.dsc.  It may or may not be system RAM.
If it is excised from system memory, then there is no way for the OS to reclaim 
it, as it can't differentiate that from the VRAM case.
I'm not sure I see the relevance of that anyway.  Is our objective to provide 
restricted firmware tightly tuned for a specific operating system in an 
unrealistic mode, or to provide a generic example of firmware exercising the 
standard interfaces and testing real use cases?

Regards,
Evan

>
>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Girish Pathak 
> > Signed-off-by: Evan Lloyd 
> > ---
> >  ArmPlatformPkg/ArmPlatformPkg.dec  
> >  |  4 
> >
...
> > --
> > Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")
> >
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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add debug asserts

2017-12-01 Thread Evan Lloyd
Responses inline:

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 13 October 2017 08:33
> To: Evan Lloyd 
> Cc: edk2-devel@lists.01.org; "ard.biesheu...@linaro.org"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
> Subject: Re: [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add
> debug asserts
>
> On 26 September 2017 at 21:15,   wrote:
> > From: Girish Pathak 
> >
> > This change adds some debug assertions e.g to catch NULL pointer
> > errors missing in PL11Lcd and HdLcd modules.
> >
> > This change also improves related error handling code.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Girish Pathak 
> > Signed-off-by: Evan Lloyd 
> > ---
> >
> ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdAr
> mVExpress.c   | 44 ++--
> >
> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL11
> 1LcdArmVExpress.c | 43 ++-
> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/HdLcd.c
> |  8 ++--
> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c
> |  8 ++--
> >  4 files changed, 90 insertions(+), 13 deletions(-)
> >
> > diff --git
> >
> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> ArmVE
> > xpress.c
> >
> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> ArmVE
> > xpress.c index
> >
> b9859a56988f7e5be0adbaa49048a683fe586bfe..58dd9f0c77e1bc9af559a
> 71d0c7c
> > ce72d71c6da5 100644
> > ---
> >
> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> ArmVE
> > xpress.c
> > +++
> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> A
> > +++ rmVExpress.c
> > @@ -140,6 +140,7 @@ LcdPlatformInitializeDisplay (
> >* buffer in bytes
> >*
> >* @retval EFI_SUCCESS Frame buffer memory allocation success.
> > +  * @retval EFI_INVALID_PARAMETER   VramBaseAddress or VramSize
> are NULL.
> >* @retval !(EFI_SUCCESS)  Other errors.
> >  **/
> >  EFI_STATUS
> > @@ -151,6 +152,13 @@ LcdPlatformGetVram (
> >EFI_STATUS  Status;
> >EFI_ALLOCATE_TYPE   AllocationType;
> >
> > +  // Check VramBaseAddress and VramSize are not NULL.
> > +  if (VramBaseAddress == NULL || VramSize == NULL) {
> > +ASSERT (VramBaseAddress != NULL);
> > +ASSERT (VramSize != NULL);
> > +return EFI_INVALID_PARAMETER;
> > +  }
> > +
> >// Set the vram size
> >*VramSize = LCD_VRAM_SIZE;
> >
> > @@ -169,6 +177,7 @@ LcdPlatformGetVram (
> >VramBaseAddress
> >);
> >if (EFI_ERROR (Status)) {
> > +ASSERT_EFI_ERROR (Status);
> >  return Status;
> >}
> >
> > @@ -179,8 +188,8 @@ LcdPlatformGetVram (
> >*VramSize,
> >EFI_MEMORY_WC
> >);
> > -  ASSERT_EFI_ERROR (Status);
> >if (EFI_ERROR (Status)) {
> > +ASSERT_EFI_ERROR (Status);
>
> What is the point of this change?
[[Evan Lloyd]] It is a minor efficiency improvement.  Since the ASSERT can only 
fire when the if condition is true, it removes a duplicated test from the main 
(non-error) code flow.  This is irrelevant on hardware, but actually 
significant when running debug builds on an emulator environment.

>
> >  gBS->FreePages (*VramBaseAddress, EFI_SIZE_TO_PAGES (*VramSize));
> >  return Status;
> >}
> > @@ -215,6 +224,7 @@ LcdPlatformSetMode (
> >EFI_STATUSStatus;
> >
> >if (ModeNumber >= LcdPlatformGetMaxMode ()) {
> > +ASSERT (ModeNumber < LcdPlatformGetMaxMode ());
> >  return EFI_INVALID_PARAMETER;
> >}
> >
> > @@ -264,6 +274,7 @@ LcdPlatformSetMode (
> >*
> >* @retval EFI_SUCCESS Success if the requested mode is found.
> >* @retval EFI_INVALID_PARAMETER   Requested mode not found.
> > +  * @retval EFI_INVALID_PARAMETER   Info is NULL.
> >  **/
> >  EFI_STATUS
> >  LcdPlatformQueryMode (
> > @@ -271,7 +282,9 @@ LcdPlatformQueryMode (
> >OUT EFI_GRAPHICS_OUTPUT_MODE_INFORMATION * CONST  Info
> >)
> >  {
> > -  if (ModeNumber >= LcdPlatformGetMaxMode ()) {
> > +  if (ModeNumber >= LcdPlatformGetMaxMode () || Info == NULL) {
> > +ASSERT (ModeNumber < LcdPlatformGetMaxMode ());
>
> Please don't put anything that may have a side effect inside ASSERT (), since
> they are dropped from RELEASE builds. You can just use ASSERT (FALSE)
> here, or use a temp variable.

 [[Evan Lloyd]] Agreed

>
>
> > +ASSERT (Info != NULL);
> >  return EFI_INVALID_PARAMETER;
> >}
> >
> > @@ -334,6 +347,28 @@ LcdPlatformGetTimings (
> >)
> >  {
> >if (ModeNumber >= LcdPlatformGetMaxMode ()) {
> > +ASSERT (ModeNumber < LcdPlatformGetMaxMode ());
>
> same here
[[Evan Lloyd]] Agreed
>
> > +return EFI_INVALID_PARAMETER;
> > +  }
> 

[edk2] [PATCH 0/3] Platform/NXP-Adding NXP MMC Host Driver

2017-12-01 Thread Vabhav
Following patches will add support of NXP MMC Host Driver in
edk2-platforms directory 'edk2-platforms/Platform/NXP'

Updated Directory structure for added folders in 'edk2-platforms/Platform/NXP'
will be:

Platform/NXP/
|-- Drivers
|   |-- MmcHostDxe
|   |   |-- MmcHostDxe.c
|   |   `-- MmcHostDxe.inf
|-- Include
|   `-- Library
|   `-- MmcLib.h
|-- Library
|   `-- MmcLib
|   |-- MmcInterface.c
|   |-- MmcInternal.h
|   |-- MmcLib.c
|   `-- MmcLib.inf

In Platform/NXP/Library:
MmcLib will be added

In Platform/NXP/Drivers:
MmcHostDxe driver will be added

Mmc host driver will produce gEfiMmcHostProtocolGuid which
will be used by consumed by MmcDxe driver of EmbeddedPkg.

Please review and look forward for your support in upstreaming
the patches in edk2-platforms.

Vabhav (3):
  Platform/NXP :Add Support for MMC Library
  Platform/NXP :Add Support of MMC Host Driver
  Compilation:Modify dsc,fdf files

 Platform/NXP/Drivers/MmcHostDxe/MmcHostDxe.c   | 418 +
 Platform/NXP/Drivers/MmcHostDxe/MmcHostDxe.inf |  42 ++
 Platform/NXP/Include/Library/MmcLib.h  | 138 ++
 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc   |  11 +
 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf   |   7 +
 Platform/NXP/Library/MmcLib/MmcInterface.c | 544 ++
 Platform/NXP/Library/MmcLib/MmcInternal.h  | 350 +++
 Platform/NXP/Library/MmcLib/MmcLib.c   | 597 +
 Platform/NXP/Library/MmcLib/MmcLib.inf |  39 ++
 9 files changed, 2146 insertions(+)
 create mode 100644 Platform/NXP/Drivers/MmcHostDxe/MmcHostDxe.c
 create mode 100644 Platform/NXP/Drivers/MmcHostDxe/MmcHostDxe.inf
 create mode 100644 Platform/NXP/Include/Library/MmcLib.h
 create mode 100644 Platform/NXP/Library/MmcLib/MmcInterface.c
 create mode 100644 Platform/NXP/Library/MmcLib/MmcInternal.h
 create mode 100644 Platform/NXP/Library/MmcLib/MmcLib.c
 create mode 100644 Platform/NXP/Library/MmcLib/MmcLib.inf
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH 3/3] Compilation:Modify dsc,fdf files

2017-12-01 Thread Vabhav
This patch adds support for compilation of NXP MMC
library and MMC Host Driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal 
Signed-off-by: Vabhav 
---
 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc | 11 +++
 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf |  7 +++
 2 files changed, 18 insertions(+)

diff --git a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc 
b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
index 19d4d30..134267f 100644
--- a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
+++ b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
@@ -39,6 +39,11 @@
   SocLib|edk2-platforms/Silicon/NXP/Chassis/LS1043aSocLib.inf
   
RealTimeClockLib|edk2-platforms/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.inf
 
+  #
+  # Mmc Lib
+  #
+  MmcLib|edk2-platforms/Platform/NXP/Library/MmcLib/MmcLib.inf
+
 [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"LS1043a RDB board"
 
@@ -74,4 +79,10 @@
   edk2-platforms/Platform/NXP/Drivers/WatchDog/WatchDogDxe.inf
   edk2-platforms/Platform/NXP/Drivers/I2cDxe/I2cDxe.inf
 
+  #
+  # MMC
+  #
+  EmbeddedPkg/Universal/MmcDxe/MmcDxe.inf
+  edk2-platforms/Platform/NXP/Drivers/MmcHostDxe/MmcHostDxe.inf
+
  ##
diff --git a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf 
b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
index 9a8f242..729f7a5 100644
--- a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
+++ b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
@@ -145,6 +145,13 @@ READ_LOCK_STATUS   = TRUE
 !endif
 
   #
+  # MMC
+  #
+  INF edk2-platforms/Platform/NXP/Drivers/MmcHostDxe/MmcHostDxe.inf
+  INF EmbeddedPkg/Universal/MmcDxe/MmcDxe.inf
+
+  #
+  #
   # FAT filesystem + GPT/MBR partitioning
   #
   INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
-- 
1.9.1

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


[edk2] [PATCH 2/3] Platform/NXP :Add Support of MMC Host Driver

2017-12-01 Thread Vabhav
This patch adds support for MMC host driver
Mmc host driver will produce gEfiMmcHostProtocolGuid which
will be consumed by MmcDxe driver of EmbeddedPkg

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal 
Signed-off-by: Vabhav 
---
 Platform/NXP/Drivers/MmcHostDxe/MmcHostDxe.c   | 418 +
 Platform/NXP/Drivers/MmcHostDxe/MmcHostDxe.inf |  42 +++
 2 files changed, 460 insertions(+)
 create mode 100644 Platform/NXP/Drivers/MmcHostDxe/MmcHostDxe.c
 create mode 100644 Platform/NXP/Drivers/MmcHostDxe/MmcHostDxe.inf

diff --git a/Platform/NXP/Drivers/MmcHostDxe/MmcHostDxe.c 
b/Platform/NXP/Drivers/MmcHostDxe/MmcHostDxe.c
new file mode 100644
index 000..81269bf
--- /dev/null
+++ b/Platform/NXP/Drivers/MmcHostDxe/MmcHostDxe.c
@@ -0,0 +1,418 @@
+/** @file
+
+  This file implement the MMC Host Protocol for the NXP SDHC controller.
+
+  Copyright 2017 NXP
+
+  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 
+
+UINT8  LastCmd;
+struct SdCmd Cmd;
+
+EFI_GUID mMmcDevicePathGuid = EFI_CALLER_ID_GUID;
+
+/**
+  Function to call library function to detect card presence
+
+  @param  This Pointer to MMC host protocol structure
+
+**/
+BOOLEAN
+MmcIsCardPresent (
+  IN EFI_MMC_HOST_PROTOCOL *This
+  )
+{
+  return DetectCardPresence ();
+}
+
+/**
+  Function to call library function to verify card is read only
+
+  @param  This Pointer to MMC host protocol structure
+
+**/
+BOOLEAN
+MmcIsReadOnly (
+  IN EFI_MMC_HOST_PROTOCOL *This
+  )
+{
+  return IsCardReadOnly ();
+}
+
+/**
+  Function to create command reseponse depeping upon
+  input command parameter
+
+  @param  MmcCmd MMC Command
+
+**/
+STATIC UINT32
+CreateResponseType (
+   IN  UINT32 MmcCmd
+  )
+{
+
+  UINT32 RespType;
+
+  RespType = 0;
+
+  if (MmcCmd & MMC_CMD_WAIT_RESPONSE) {
+RespType = MMC_RSP_PRESENT;
+
+if (MmcCmd & MMC_CMD_LONG_RESPONSE) {
+  RespType |= (MMC_RSP_136|MMC_RSP_CRC);
+}
+else if (!(MmcCmd & MMC_CMD_NO_CRC_RESPONSE)) {
+  RespType |= (MMC_RSP_CRC|MMC_RSP_OPCODE);
+}
+  }
+
+  if (MMC_GET_INDX(MmcCmd) == MMC_INDX(12)) {
+RespType |= MMC_RSP_BUSY;
+  }
+
+  return RespType;
+}
+
+/**
+  Function to send MMC command
+
+  @param  This Pointer to MMC host protocol structure
+  @param  MmcCmd   MMC Command
+  @param  Argument Argument if any
+
+**/
+EFI_STATUS
+MmcSendCommand (
+  IN EFI_MMC_HOST_PROTOCOL *This,
+  IN MMC_CMDMmcCmd,
+  IN UINT32 Argument
+  )
+{
+  EFI_STATUS  Status;
+
+  Cmd.CmdIdx = MMC_GET_INDX (MmcCmd);
+  Cmd.CmdArg = Argument;
+  Cmd.RespType = CreateResponseType (MmcCmd);
+
+  //Saved data in Cmd struct for commands that need a read/write.
+  //This is done because which setting Xfertype register we need
+  //information of block number and blocksize.
+  if ((Cmd.CmdIdx == MMC_INDX(6)) || (Cmd.CmdIdx == MMC_INDX(51)) ||
+   (Cmd.CmdIdx == MMC_INDX(17)) || (Cmd.CmdIdx == MMC_INDX(18)) ||
+   (Cmd.CmdIdx == MMC_INDX(24)) || (Cmd.CmdIdx == MMC_INDX(25))) {
+
+  if ((Cmd.CmdIdx == MMC_INDX(6)) && (LastCmd == MMC_INDX(55))) {
+Status = SendCmd (, NULL);
+  }
+  else {
+Status = EFI_SUCCESS;
+  }
+   } else {
+  Status = SendCmd (, NULL);
+   }
+
+  LastCmd = Cmd.CmdIdx;
+
+  return Status;
+}
+
+/**
+  Function to receive MMC command response
+
+  @param  This   Pointer to MMC host protocol structure
+  @param  Type   MMC Command response type
+  @param  Buffer Pointer to response Buffer
+
+**/
+EFI_STATUS
+MmcReceiveResponse (
+  IN EFI_MMC_HOST_PROTOCOL *This,
+  IN MMC_RESPONSE_TYPE  Type,
+  IN UINT32*Buffer
+  )
+{
+  EFI_STATUS Status;
+
+  if (Buffer == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  if (Type == MMC_RESPONSE_TYPE_R2) {
+Type |= MMC_RSP_136;
+  } else if (Type == MMC_RESPONSE_TYPE_R1b) {
+Type |= MMC_RSP_BUSY;
+  }
+
+  DEBUG_MSG ("MMC_RESPONSE_TYPE 0x%x for cmd %d \n", Type, LastCmd);
+
+  // if Last sent command is one among 6, 51, 17, 18, 24 and 25, then
+  // set data to 1 else 0
+  if ((LastCmd == MMC_INDX(6)) || (LastCmd == MMC_INDX(51)) ||
+  (LastCmd == MMC_INDX(17)) || (LastCmd == MMC_INDX(18)) ||
+  (LastCmd == MMC_INDX(24)) || (LastCmd == MMC_INDX(25))) {
+Status = RcvResp (Type, Buffer, 1);
+  } else {
+Status = RcvResp (Type, Buffer, 0);
+  }
+
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "Failed to receive response for %d \n", 

[edk2] [PATCH 1/3] Platform/NXP :Add Support for MMC Library

2017-12-01 Thread Vabhav
This patch adds support for MMC library(MmcLib)to
provide functions which will be used by MMC Host
driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal 
Signed-off-by: Vabhav 
---
 Platform/NXP/Include/Library/MmcLib.h  | 138 +++
 Platform/NXP/Library/MmcLib/MmcInterface.c | 544 ++
 Platform/NXP/Library/MmcLib/MmcInternal.h  | 350 +
 Platform/NXP/Library/MmcLib/MmcLib.c   | 597 +
 Platform/NXP/Library/MmcLib/MmcLib.inf |  39 ++
 5 files changed, 1668 insertions(+)
 create mode 100644 Platform/NXP/Include/Library/MmcLib.h
 create mode 100644 Platform/NXP/Library/MmcLib/MmcInterface.c
 create mode 100644 Platform/NXP/Library/MmcLib/MmcInternal.h
 create mode 100644 Platform/NXP/Library/MmcLib/MmcLib.c
 create mode 100644 Platform/NXP/Library/MmcLib/MmcLib.inf

diff --git a/Platform/NXP/Include/Library/MmcLib.h 
b/Platform/NXP/Include/Library/MmcLib.h
new file mode 100644
index 000..36941bc
--- /dev/null
+++ b/Platform/NXP/Include/Library/MmcLib.h
@@ -0,0 +1,138 @@
+/** @file
+  Header Defining The MMC Memory Controller Constants, Function Prototype, 
Structures Etc
+
+  Copyright 2017 NXP
+
+  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.
+
+**/
+
+#ifndef __MMCLIB_H__
+#define __MMCLIB_H__
+
+#include 
+#include 
+
+//define MMC_DEBUG to enable debug feature
+//#define MMC_DEBUG  1
+#ifdef MMC_DEBUG
+#define DEBUG_MSG(_Fmt,...)   DEBUG ((DEBUG_ERROR, "MMC: " _Fmt, 
##__VA_ARGS__));
+#else
+#define DEBUG_MSG(_Fmt,...)
+#endif
+
+/**
+ MMC RESPONSE TYPE
+**/
+#define MMC_RSP_PRESENT  (1 << 0)
+#define MMC_RSP_136  (1 << 1)  // 136 Bit Response
+#define MMC_RSP_CRC  (1 << 2)  // Expect Valid Crc
+#define MMC_RSP_BUSY (1 << 3)  // Card May Send Busy
+#define MMC_RSP_OPCODE   (1 << 4)  // Response Contains Opcode
+
+#define MMC_RSP_NONE (0)
+#define MMC_RSP_R1   (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE)
+#define MMC_RSP_R1b  (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE| \
+ MMC_RSP_BUSY)
+#define MMC_RSP_R2   (MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC)
+#define MMC_RSP_R3   (MMC_RSP_PRESENT)
+#define MMC_RSP_R4   (MMC_RSP_PRESENT)
+#define MMC_RSP_R5   (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE)
+#define MMC_RSP_R6   (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE)
+#define MMC_RSP_R7   (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE)
+
+/**
+  Find most significant set
+
+  @param   X  word to search
+
+  @retval most significant set bit number
+
+**/
+static inline INT32 GenericFls (INT32 X)
+{
+
+  INT32 I = 31;
+
+  for (I=31; I >= 0; I--) {
+if(X & (1<

Re: [edk2] [PATCH 03/19] ArmPlatformPkg: PL111 and HDLCD: add const qualifier

2017-12-01 Thread Evan Lloyd
Hi Ard.
Response inline below

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 12 October 2017 20:47
> To: Evan Lloyd 
> Cc: edk2-devel@lists.01.org; "ard.biesheu...@linaro.org"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
> Subject: Re: [PATCH 03/19] ArmPlatformPkg: PL111 and HDLCD: add const
> qualifier
>
> On 26 September 2017 at 21:15,   wrote:
> > From: Girish Pathak 
> >
> > This change adds some STATIC and CONST qualifiers (mainly to arguments
> > of  functions) in PL111 and HdLcd modules.
> >
> > It doesn't add or modify any functionality.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Girish Pathak 
> > Signed-off-by: Evan Lloyd 
> > ---
> >
> ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdAr
> mVExpress.c   | 34 ++--
> >
> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL11
> 1LcdArmVExpress.c | 34 ++--
> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/HdLcd.c
> |  4 +--
> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c
> |  4 +--
> >  4 files changed, 38 insertions(+), 38 deletions(-)
> >
> > diff --git
> >
> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> ArmVE
> > xpress.c
> >
> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> ArmVE
> > xpress.c index
> >
> cfe3259d3c737de240350e8c3eab867b80c40948..b9859a56988f7e5be0ad
> baa49048
> > a683fe586bfe 100644
> > ---
> >
> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> ArmVE
> > xpress.c
> > +++
> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> A
> > +++ rmVExpress.c
> > @@ -46,7 +46,7 @@ typedef struct {
> >
> >  /** The display modes supported by the platform.
> >  **/
> > -LCD_RESOLUTION mResolutions[] = {
> > +STATIC CONST LCD_RESOLUTION mResolutions[] = {
> >{ // Mode 0 : VGA : 640 x 480 x 24 bpp
> >  VGA, VGA_H_RES_PIXELS, VGA_V_RES_PIXELS,
> LCD_BITS_PER_PIXEL_24,
> >  VGA_OSC_FREQUENCY,
> > @@ -144,8 +144,8 @@ LcdPlatformInitializeDisplay (  **/  EFI_STATUS
> > LcdPlatformGetVram (
> > -  OUT EFI_PHYSICAL_ADDRESS*  VramBaseAddress,
> > -  OUT UINTN* VramSize
> > +  OUT EFI_PHYSICAL_ADDRESS * CONST  VramBaseAddress,
> > +  OUT UINTN * CONST VramSize
>
> What is the point of this CONST (and all the other occurrences in this patch)
>
> In all cases [AFAICT] the CONST applies to the argument itself, not to the
> object it points to, which means the variable is CONST in the scope of the
> function, but can still be dereferenced to assign the OUT value.
>
> This means your change is technically correct, but it is extremely
> unidiomatic for EDK2, so an explanation why this driver needs this would be
> highly appreciated.
>
[[Evan Lloyd]] The style is explicitly sanctioned by the Edk2 CCS ยง 5.6.2.4.2
" Constant pointer to variable: UINTN * CONST ConstPointer;
ConstPointer is a constant pointer to a variable UINTN."

The real benefit is that it clearly identifies the pointer as not changed in 
the function.
In this specific instance that also makes it obvious that the OUT parameters 
are not array bases, just pointers to individual values.

On a broader note - why would you ever not have a const where something is not 
modified?

As another view, the "unidiomatic for EDK2" argument implies you have a very 
high opinion of the existing ArmPlatformPkg code quality.
The  "we have always done it that way" argument does not encourage quality 
improvements.

Regards,
Evan
> >)
...
> > --
> > Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")
> >
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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH 1/4] Silicon/NXP:SocLib support for initialization of peripherals

2017-12-01 Thread Vabhav
This patch adds SocInit function to initialize
peripherals and print board,soc information.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vabhav 
---
 Silicon/NXP/Chassis/Chassis2/Soc.c  | 47 
 Silicon/NXP/Chassis/LS1043aSocLib.inf   |  2 ++
 Silicon/NXP/Chassis/LS1046aSocLib.inf   | 49 +
 Silicon/NXP/LS1046A/Include/SocSerDes.h | 55 +
 4 files changed, 153 insertions(+)
 create mode 100644 Silicon/NXP/Chassis/LS1046aSocLib.inf
 create mode 100644 Silicon/NXP/LS1046A/Include/SocSerDes.h

diff --git a/Silicon/NXP/Chassis/Chassis2/Soc.c 
b/Silicon/NXP/Chassis/Chassis2/Soc.c
index ff9575a..36ac886 100644
--- a/Silicon/NXP/Chassis/Chassis2/Soc.c
+++ b/Silicon/NXP/Chassis/Chassis2/Soc.c
@@ -116,6 +116,43 @@ GetSysInfo (
 }
 
 /**
+   Function to select pins depending upon pcd using supplemental
+   configuration unit(SCFG) extended RCW controlled pinmux control
+   register which contains the bits to provide pin multiplexing control.
+   This register is reset on HRESET.
+ **/
+VOID
+ConfigScfgMux (VOID)
+{
+  CCSR_SCFG *Scfg;
+  UINT32 UsbPwrFault;
+
+  Scfg = (VOID *)PcdGet64 (PcdScfgBaseAddr);
+  // Configures functionality of the IIC3_SCL to USB2_DRVVBUS
+  // Configures functionality of the IIC3_SDA to USB2_PWRFAULT
+
+  // LS1043A
+  // Configures functionality of the IIC4_SCL to USB3_DRVVBUS
+  // Configures functionality of the IIC4_SDA to USB3_PWRFAULT
+
+  // LS1046A
+  // USB3 is not used, configure mux to IIC4_SCL/IIC4_SDA
+  if (PcdGetBool(PcdMuxToUsb3))
+MmioWriteBe32 ((UINTN)>RcwPMuxCr0, CCSR_SCFG_RCWPMUXCRO_SELCR_USB);
+  else
+MmioWriteBe32 ((UINTN)>RcwPMuxCr0, 
CCSR_SCFG_RCWPMUXCRO_NOT_SELCR_USB);
+  MmioWriteBe32 ((UINTN)>UsbDrvVBusSelCr, 
CCSR_SCFG_USBDRVVBUS_SELCR_USB1);
+  UsbPwrFault = (CCSR_SCFG_USBPWRFAULT_DEDICATED <<
+CCSR_SCFG_USBPWRFAULT_USB3_SHIFT) |
+(CCSR_SCFG_USBPWRFAULT_DEDICATED <<
+CCSR_SCFG_USBPWRFAULT_USB2_SHIFT) |
+(CCSR_SCFG_USBPWRFAULT_SHARED <<
+CCSR_SCFG_USBPWRFAULT_USB1_SHIFT);
+  MmioWriteBe32 ((UINTN)>UsbPwrFaultSelCr, UsbPwrFault);
+  MmioWriteBe32 ((UINTN)>UsbPwrFaultSelCr, UsbPwrFault);
+}
+
+/**
   Function to initialize SoC specific constructs
   // CPU Info
   // SoC Personality
@@ -141,5 +178,15 @@ SocInit (
   PrintCpuInfo ();
   PrintRCW ();
 
+  //
+  // Due to the extensive functionality present on the chip and the limited 
number of external
+  // signals available, several functional blocks share signal resources 
through multiplexing.
+  // In this case when there is alternate functionality between multiple 
functional blocks,
+  // the signal's function is determined at the chip level (rather than at the 
block level)
+  // typically by a reset configuration word (RCW) option. Some of the 
signals' function are
+  // determined externel to RCW at Power-on Reset Sequence.
+  //
+  ConfigScfgMux();
+
   return;
 }
diff --git a/Silicon/NXP/Chassis/LS1043aSocLib.inf 
b/Silicon/NXP/Chassis/LS1043aSocLib.inf
index a7c6ee5..e12a705 100644
--- a/Silicon/NXP/Chassis/LS1043aSocLib.inf
+++ b/Silicon/NXP/Chassis/LS1043aSocLib.inf
@@ -45,3 +45,5 @@
   gNxpQoriqLsTokenSpaceGuid.PcdSerdes2Enabled
   gNxpQoriqLsTokenSpaceGuid.PcdGurBigEndian
   gNxpQoriqLsTokenSpaceGuid.PcdClkBaseAddr
+  gNxpQoriqLsTokenSpaceGuid.PcdMuxToUsb3
+  gNxpQoriqLsTokenSpaceGuid.PcdScfgBaseAddr
diff --git a/Silicon/NXP/Chassis/LS1046aSocLib.inf 
b/Silicon/NXP/Chassis/LS1046aSocLib.inf
new file mode 100644
index 000..9422a2a
--- /dev/null
+++ b/Silicon/NXP/Chassis/LS1046aSocLib.inf
@@ -0,0 +1,49 @@
+#  @file
+#
+#  Copyright 2017 NXP
+#
+#  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.
+#
+#
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = SocLib
+  FILE_GUID  = 5e9a2b48-a92a-4d55-87ec-e5e14a292f35
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = SocLib
+
+[Packages]
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  Platform/NXP/NxpQoriqLs.dec
+  Silicon/NXP/Chassis/Chassis2/Chassis2.dec
+  Silicon/NXP/LS1046A/LS1046A.dec
+
+[LibraryClasses]
+  BaseLib
+  BeIoLib
+  DebugLib
+  SerialPortLib
+
+[Sources.common]
+  Chassis.c
+  Chassis2/Soc.c
+  SerDes.c
+
+[FixedPcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString
+  gNxpQoriqLsTokenSpaceGuid.PcdGutsBaseAddr
+  gNxpQoriqLsTokenSpaceGuid.PcdPlatformFreqDiv
+  

[edk2] [PATCH 3/4] Platform/NXP: Add support for ArmPlatformLib

2017-12-01 Thread Vabhav
This patch adds support of adding ArmPlatformLib
for NXP LS1046ARDB board

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vabhav 
---
 .../Library/PlatformLib/ArmPlatformLib.c   | 106 
 .../Library/PlatformLib/ArmPlatformLib.inf |  70 
 .../Library/PlatformLib/NxpQoriqLsHelper.S |  39 +
 .../Library/PlatformLib/NxpQoriqLsMem.c| 181 +
 4 files changed, 396 insertions(+)
 create mode 100644 
Platform/NXP/LS1046aRdbPkg/Library/PlatformLib/ArmPlatformLib.c
 create mode 100644 
Platform/NXP/LS1046aRdbPkg/Library/PlatformLib/ArmPlatformLib.inf
 create mode 100644 
Platform/NXP/LS1046aRdbPkg/Library/PlatformLib/NxpQoriqLsHelper.S
 create mode 100644 
Platform/NXP/LS1046aRdbPkg/Library/PlatformLib/NxpQoriqLsMem.c

diff --git a/Platform/NXP/LS1046aRdbPkg/Library/PlatformLib/ArmPlatformLib.c 
b/Platform/NXP/LS1046aRdbPkg/Library/PlatformLib/ArmPlatformLib.c
new file mode 100644
index 000..e2b645f
--- /dev/null
+++ b/Platform/NXP/LS1046aRdbPkg/Library/PlatformLib/ArmPlatformLib.c
@@ -0,0 +1,106 @@
+/** ArmPlatformLib.c
+*
+*  Contains board initialization functions.
+*
+*  Based on BeagleBoardPkg/Library/BeagleBoardLib/BeagleBoard.c
+*
+*  Copyright (c) 2011-2012, ARM Limited. All rights reserved.
+*  Copyright 2017 NXP
+*
+*  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 
+
+extern VOID SocInit(VOID);
+
+/**
+  Return the current Boot Mode
+
+  This function returns the boot reason on the platform
+
+**/
+EFI_BOOT_MODE
+ArmPlatformGetBootMode (
+  VOID
+  )
+{
+  return BOOT_WITH_FULL_CONFIGURATION;
+}
+
+/**
+ Placeholder for Platform Initialization
+**/
+RETURN_STATUS
+ArmPlatformInitialize (
+  IN  UINTN MpId
+  )
+{
+ SocInit();
+ return RETURN_SUCCESS;
+}
+
+ARM_CORE_INFO LS1046aMpCoreInfoCTA72x4[] = {
+  {
+// Cluster 0, Core 0
+0x0, 0x0,
+
+// MP Core MailBox Set/Get/Clear Addresses and Clear Value
+(EFI_PHYSICAL_ADDRESS)0,
+(EFI_PHYSICAL_ADDRESS)0,
+(EFI_PHYSICAL_ADDRESS)0,
+(UINT64)0x
+  },
+};
+
+EFI_STATUS
+PrePeiCoreGetMpCoreInfo (
+  OUT UINTN   *CoreCount,
+  OUT ARM_CORE_INFO   **ArmCoreTable
+  )
+{
+  *CoreCount= sizeof(LS1046aMpCoreInfoCTA72x4) / sizeof(ARM_CORE_INFO);
+  *ArmCoreTable = LS1046aMpCoreInfoCTA72x4;
+
+  return EFI_SUCCESS;
+}
+
+ARM_MP_CORE_INFO_PPI mMpCoreInfoPpi = { PrePeiCoreGetMpCoreInfo };
+
+EFI_PEI_PPI_DESCRIPTOR  gPlatformPpiTable[] = {
+  {
+EFI_PEI_PPI_DESCRIPTOR_PPI,
+,
+
+  }
+};
+
+VOID
+ArmPlatformGetPlatformPpiList (
+  OUT UINTN   *PpiListSize,
+  OUT EFI_PEI_PPI_DESCRIPTOR  **PpiList
+  )
+{
+  *PpiListSize = sizeof(gPlatformPpiTable);
+  *PpiList = gPlatformPpiTable;
+}
+
+
+UINTN
+ArmPlatformGetCorePosition (
+  IN UINTN MpId
+  )
+{
+  return 1;
+}
diff --git a/Platform/NXP/LS1046aRdbPkg/Library/PlatformLib/ArmPlatformLib.inf 
b/Platform/NXP/LS1046aRdbPkg/Library/PlatformLib/ArmPlatformLib.inf
new file mode 100644
index 000..033f77a
--- /dev/null
+++ b/Platform/NXP/LS1046aRdbPkg/Library/PlatformLib/ArmPlatformLib.inf
@@ -0,0 +1,70 @@
+#/* @file
+#  Copyright (c) 2011-2013, ARM Limited. All rights reserved.
+#  Copyright (c) 2016, Freescale Semiconductor, Inc. All rights reserved.
+#
+#  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.
+#
+#*/
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = ArmPlatformLib
+  FILE_GUID  = 177a95a8-27c2-4582-8ba9-c87aa3e0ba75
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = ArmPlatformLib
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  ArmPlatformPkg/ArmPlatformPkg.dec
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdePkg/MdePkg.dec
+  Platform/NXP/NxpQoriqLs.dec
+
+[LibraryClasses]
+  ArmLib
+  SocLib
+
+[Sources.common]
+  NxpQoriqLsHelper.S| GCC
+  ArmPlatformLib.c
+  NxpQoriqLsMem.c
+
+[Ppis]
+  gArmMpCoreInfoPpiGuid
+
+[FeaturePcd]
+  gEmbeddedTokenSpaceGuid.PcdCacheEnable
+
+[FixedPcd]
+  gArmTokenSpaceGuid.PcdArmPrimaryCore
+  

[edk2] [PATCH 2/4] Silicon/NXP:Add support for PCF2129 Real Time Clock Library

2017-12-01 Thread Vabhav
This patch add support for NXP pcf2129 real time
clock library

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vabhav 
---
 Platform/NXP/Drivers/I2cDxe/I2cDxe.c   |  17 +-
 Silicon/NXP/Library/Pcf2129RtcLib/Pcf2129Rtc.h |  43 +++
 Silicon/NXP/Library/Pcf2129RtcLib/Pcf2129RtcLib.c  | 375 +
 .../NXP/Library/Pcf2129RtcLib/Pcf2129RtcLib.inf|  47 +++
 4 files changed, 474 insertions(+), 8 deletions(-)
 create mode 100644 Silicon/NXP/Library/Pcf2129RtcLib/Pcf2129Rtc.h
 create mode 100644 Silicon/NXP/Library/Pcf2129RtcLib/Pcf2129RtcLib.c
 create mode 100644 Silicon/NXP/Library/Pcf2129RtcLib/Pcf2129RtcLib.inf

diff --git a/Platform/NXP/Drivers/I2cDxe/I2cDxe.c 
b/Platform/NXP/Drivers/I2cDxe/I2cDxe.c
index 30eb6f4..ffbee74 100644
--- a/Platform/NXP/Drivers/I2cDxe/I2cDxe.c
+++ b/Platform/NXP/Drivers/I2cDxe/I2cDxe.c
@@ -538,7 +538,8 @@ StartRequest (
   UINT32   Length;
   UINT8*Buffer;
   UINT32   Flag;
-  UINT8RegAddress;
+  UINT32   RegAddress;
+  UINT32   OffsetLength;
 
   RegAddress = 0;
 
@@ -548,7 +549,10 @@ StartRequest (
 return EFI_INVALID_PARAMETER;
   }
 
-  for (Count = 0; Count < RequestPacket->OperationCount; Count++) {
+  OffsetLength = RequestPacket->Operation[0].LengthInBytes;
+  RegAddress = *RequestPacket->Operation[0].Buffer;
+
+  for (Count = 1; Count < RequestPacket->OperationCount; Count++) {
 Flag = RequestPacket->Operation[Count].Flags;
 Length = RequestPacket->Operation[Count].LengthInBytes;
 Buffer = RequestPacket->Operation[Count].Buffer;
@@ -559,12 +563,9 @@ StartRequest (
   return EFI_INVALID_PARAMETER;
 }
 
-if (Flag == I2C_FLAG_WRITE && Count == 0) {
-  RegAddress = *Buffer;
-  continue;
-} else if (Flag == I2C_FLAG_READ) {
+if (Flag == I2C_FLAG_READ) {
   Ret = I2cDataRead (PcdGet32 (PcdI2cBus), SlaveAddress,
-  RegAddress, sizeof(SlaveAddress)/8, Buffer, Length);
+  RegAddress, OffsetLength, Buffer, Length);
   if (Ret != EFI_SUCCESS) {
 DEBUG ((DEBUG_ERROR,"%a: I2c read operation failed (error %d)\n",
__FUNCTION__, Ret));
@@ -572,7 +573,7 @@ StartRequest (
   }
 } else if (Flag == I2C_FLAG_WRITE) {
   Ret = I2cDataWrite (PcdGet32 (PcdI2cBus), SlaveAddress,
-  RegAddress, sizeof(SlaveAddress)/8, Buffer, Length);
+  RegAddress, OffsetLength, Buffer, Length);
   if (Ret != EFI_SUCCESS) {
 DEBUG ((DEBUG_ERROR,"%a: I2c write operation failed (error %d)\n",
__FUNCTION__, Ret));
diff --git a/Silicon/NXP/Library/Pcf2129RtcLib/Pcf2129Rtc.h 
b/Silicon/NXP/Library/Pcf2129RtcLib/Pcf2129Rtc.h
new file mode 100644
index 000..735f697
--- /dev/null
+++ b/Silicon/NXP/Library/Pcf2129RtcLib/Pcf2129Rtc.h
@@ -0,0 +1,43 @@
+/** Pcf2129Rtc.h
+*
+*  Copyright 2017 NXP
+*
+*  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.
+*
+**/
+
+#ifndef __PCF2129RTC_H__
+#define __PCF2129RTC_H__
+
+/*
+ * RTC register addresses
+ */
+#define PCF2129_CTRL1_REG_ADDR  0x00  // Control Register 1
+#define PCF2129_CTRL2_REG_ADDR  0x01  // Control Register 2
+#define PCF2129_CTRL3_REG_ADDR  0x02  // Control Register 3
+#define PCF2129_SEC_REG_ADDR0x03
+#define PCF2129_MIN_REG_ADDR0x04
+#define PCF2129_HR_REG_ADDR 0x05
+#define PCF2129_DAY_REG_ADDR0x06
+#define PCF2129_WEEKDAY_REG_ADDR0x07
+#define PCF2129_MON_REG_ADDR0x08
+#define PCF2129_YR_REG_ADDR 0x09
+
+#define PCF2129_CTRL3_BIT_BLF   BIT2/* Battery Low Flag*/
+
+// Define EPOCH (1998-JANUARY-01) in the Julian Date representation
+#define EPOCH_JULIAN_DATE   2450815
+
+typedef struct {
+  UINTN   OperationCount;
+  EFI_I2C_OPERATION   SetAddressOp;
+  EFI_I2C_OPERATION   GetSetDateTimeOp;
+} RTC_I2C_REQUEST;
+
+#endif // __PCF2129RTC_H__
diff --git a/Silicon/NXP/Library/Pcf2129RtcLib/Pcf2129RtcLib.c 
b/Silicon/NXP/Library/Pcf2129RtcLib/Pcf2129RtcLib.c
new file mode 100644
index 000..b4ee61f
--- /dev/null
+++ b/Silicon/NXP/Library/Pcf2129RtcLib/Pcf2129RtcLib.c
@@ -0,0 +1,375 @@
+/** @PCF2129RtcLib.c
+  Implement EFI RealTimeClock with runtime services via RTC Lib for PCF2129 
RTC.
+
+  Based on RTC implementation available in
+  EmbeddedPkg/Library/TemplateRealTimeClockLib/RealTimeClockLib.c
+
+  Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
+  

[edk2] [PATCH 4/4] Compilation:Add the fdf,dsc and dec files

2017-12-01 Thread Vabhav
This patch adds firmware device,description and
declaration files to enable compilation for NXP
LS1046ARDB board.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vabhav 
---
 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc |   1 +
 Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dec |  30 +++
 Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dsc |  75 +++
 Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.fdf | 297 +++
 Platform/NXP/NxpQoriqLs.dec  |   1 +
 Platform/NXP/Readme.md   |   2 +-
 Silicon/NXP/LS1046A/LS1046A.dec  |  22 ++
 Silicon/NXP/LS1046A/LS1046A.dsc  |  79 +++
 8 files changed, 506 insertions(+), 1 deletion(-)
 create mode 100644 Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dec
 create mode 100644 Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dsc
 create mode 100644 Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.fdf
 create mode 100644 Silicon/NXP/LS1046A/LS1046A.dec
 create mode 100644 Silicon/NXP/LS1046A/LS1046A.dsc

diff --git a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc 
b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
index 19d4d30..3aa3407 100644
--- a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
+++ b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
@@ -47,6 +47,7 @@
   #
   gNxpQoriqLsTokenSpaceGuid.PcdSerdes2Enabled|FALSE
   gNxpQoriqLsTokenSpaceGuid.PcdPlatformFreqDiv|0x1
+  gNxpQoriqLsTokenSpaceGuid.PcdMuxToUsb3|TRUE
 
   #
   # Big Endian IPs
diff --git a/Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dec 
b/Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dec
new file mode 100644
index 000..bdede59
--- /dev/null
+++ b/Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dec
@@ -0,0 +1,30 @@
+#/** LS1046a board package.
+#
+#Copyright 2017 NXP
+#
+#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.
+#
+#**/
+
+[Defines]
+  PACKAGE_NAME   = LS1046aRdbPkg
+  PACKAGE_GUID   = 6eba6648-d853-4eb3-9761-528b82d5ab04
+
+
+#
+# Include Section - list of Include Paths that are provided by this package.
+#   Comments are used for Keywords and Module Types.
+#
+# Supported Module Types:
+#  BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER 
DXE_SMM_DRIVER DXE_SAL_DRIVER UEFI_DRIVER UEFI_APPLICATION
+#
+
+[Includes.common]
+  Include# Root include for the package
+
diff --git a/Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dsc 
b/Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dsc
new file mode 100644
index 000..ec9037b
--- /dev/null
+++ b/Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dsc
@@ -0,0 +1,75 @@
+#/** LS1046ARDB Board package.
+#
+#Copyright 2017 NXP
+#
+#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.
+#
+#**/
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  #
+  # Defines for default states.  These can be changed on the command line.
+  # -D FLAG=VALUE
+  #
+  PLATFORM_NAME  = LS1046aRdbPkg
+  PLATFORM_GUID  = 60169ec4-d2b4-44f8-825e-f8684fd42e4f
+  OUTPUT_DIRECTORY   = Build/LS1046aRdbPkg
+  FLASH_DEFINITION   = 
edk2-platforms/Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.fdf
+
+!include ../NxpQoriqLs.dsc
+!include ../../../Silicon/NXP/LS1046A/LS1046A.dsc
+
+[LibraryClasses.common]
+  
ArmPlatformLib|edk2-platforms/Platform/NXP/LS1046aRdbPkg/Library/PlatformLib/ArmPlatformLib.inf
+  
ResetSystemLib|ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
+  
SerialPortLib|edk2-platforms/Platform/NXP/Library/DUartPortLib/DUartPortLib.inf
+  BeIoLib|edk2-platforms/Platform/NXP/Library/BeIoLib/BeIoLib.inf
+  SocLib|edk2-platforms/Silicon/NXP/Chassis/LS1046aSocLib.inf
+  
RealTimeClockLib|edk2-platforms/Silicon/NXP/Library/Pcf2129RtcLib/Pcf2129RtcLib.inf
+
+[PcdsFixedAtBuild.common]
+  

[edk2] [PATCH 0/4] Platform/NXP-Adding NXP NOR IP

2017-12-01 Thread Vabhav
Following patches will add support of NXP NOR IP in edk2-platforms
directory 'edk2-platforms/Platform/NXP'

Updated Directory structure for added folders in 'edk2-platforms/Platform/NXP'
will be:
|-- Drivers
|   |-- NorFlashDxe
|   |   |-- NorFlashBlockIoDxe.c
|   |   |-- NorFlashDxe.c
|   |   |-- NorFlashDxe.inf
|   |   `-- NorFlashFvbDxe.c
|-- Include
|   `-- Library
|   |-- IfcBase.h
|   |-- Ifc.h
|   |-- NorFlash.h
|   `-- NorFlashLib.h
|-- Library
|   |-- IfcFlashLib
|   |   |-- IfcFlashLib.c
|   |   `-- IfcFlashLib.inf
|   `-- NorFlashLib
|   |-- CfiCommand.h
|   |-- CfiNorFlashLib.c
|   |-- CfiNorFlashLib.h
|   |-- IfcNorFlashLib.c
|   |-- NorFlashLib.c
|   `-- NorFlashLib.inf
|-- LS1043aRdbPkg
|   |-- Include
|   |   `-- Library
|   |   `-- IfcBoardSpecificLib.h
|   |-- LS1043aRdbPkg.dsc
|   |-- LS1043aRdbPkg.fdf
|   `-- VarStore.fdf.inc
|-- NxpQoriqLs.dsc

In Platform/NXP/Library:
IfcFlashLib and NorFlashLib will be added

In Platform/NXP/Drivers:
NorFlashDxe driver will be added

Platform/NXP/LS1043aRdbPkg will host VarStore.fdf.inc for runtime variable
support.

Please review and look forward for your support for upstreaming the patches in
edk2-platforms.


Vabhav (4):
  Platform/NXP : Add Integrated flash controller library support
  Platform/NXP : Add Support for NOR flash Library
  Platform/NXP : Add Support for NOR Flash driver
  Compilation:Modify dsc,fdf files and add inc file

 .../NXP/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c   | 254 +++
 Platform/NXP/Drivers/NorFlashDxe/NorFlashDxe.c | 446 
 Platform/NXP/Drivers/NorFlashDxe/NorFlashDxe.inf   |  65 ++
 Platform/NXP/Drivers/NorFlashDxe/NorFlashFvbDxe.c  | 807 +
 Platform/NXP/Include/Library/Ifc.h | 147 
 Platform/NXP/Include/Library/IfcBase.h | 139 
 Platform/NXP/Include/Library/NorFlash.h| 222 ++
 Platform/NXP/Include/Library/NorFlashLib.h |  67 ++
 .../Include/Library/IfcBoardSpecificLib.h  |  51 ++
 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc   |  22 +
 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf   |   9 +-
 Platform/NXP/LS1043aRdbPkg/VarStore.fdf.inc|  98 +++
 Platform/NXP/Library/IfcFlashLib/IfcFlashLib.c |  65 ++
 Platform/NXP/Library/IfcFlashLib/IfcFlashLib.inf   |  30 +
 Platform/NXP/Library/NorFlashLib/CfiCommand.h  |  99 +++
 Platform/NXP/Library/NorFlashLib/CfiNorFlashLib.c  | 184 +
 Platform/NXP/Library/NorFlashLib/CfiNorFlashLib.h  |  54 ++
 Platform/NXP/Library/NorFlashLib/IfcNorFlashLib.c  |  52 ++
 Platform/NXP/Library/NorFlashLib/NorFlashLib.c | 658 +
 Platform/NXP/Library/NorFlashLib/NorFlashLib.inf   |  42 ++
 Platform/NXP/NxpQoriqLs.dsc|   6 +-
 21 files changed, 3515 insertions(+), 2 deletions(-)
 create mode 100644 Platform/NXP/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c
 create mode 100644 Platform/NXP/Drivers/NorFlashDxe/NorFlashDxe.c
 create mode 100755 Platform/NXP/Drivers/NorFlashDxe/NorFlashDxe.inf
 create mode 100644 Platform/NXP/Drivers/NorFlashDxe/NorFlashFvbDxe.c
 create mode 100755 Platform/NXP/Include/Library/Ifc.h
 create mode 100644 Platform/NXP/Include/Library/IfcBase.h
 create mode 100644 Platform/NXP/Include/Library/NorFlash.h
 create mode 100644 Platform/NXP/Include/Library/NorFlashLib.h
 create mode 100755 
Platform/NXP/LS1043aRdbPkg/Include/Library/IfcBoardSpecificLib.h
 create mode 100644 Platform/NXP/LS1043aRdbPkg/VarStore.fdf.inc
 create mode 100644 Platform/NXP/Library/IfcFlashLib/IfcFlashLib.c
 create mode 100644 Platform/NXP/Library/IfcFlashLib/IfcFlashLib.inf
 create mode 100644 Platform/NXP/Library/NorFlashLib/CfiCommand.h
 create mode 100644 Platform/NXP/Library/NorFlashLib/CfiNorFlashLib.c
 create mode 100644 Platform/NXP/Library/NorFlashLib/CfiNorFlashLib.h
 create mode 100644 Platform/NXP/Library/NorFlashLib/IfcNorFlashLib.c
 create mode 100644 Platform/NXP/Library/NorFlashLib/NorFlashLib.c
 create mode 100644 Platform/NXP/Library/NorFlashLib/NorFlashLib.inf

-- 
1.9.1

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


[edk2] [PATCH 2/4] Platform/NXP : Add Support for NOR flash Library

2017-12-01 Thread Vabhav
This patch adds support for NOR flash library(NorFlashLib)
to provide functions which will be used by NOR flash
Driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vabhav 
---
 Platform/NXP/Include/Library/NorFlashLib.h|  67 +++
 Platform/NXP/Library/NorFlashLib/CfiCommand.h |  99 
 Platform/NXP/Library/NorFlashLib/CfiNorFlashLib.c | 184 ++
 Platform/NXP/Library/NorFlashLib/CfiNorFlashLib.h |  54 ++
 Platform/NXP/Library/NorFlashLib/IfcNorFlashLib.c |  52 ++
 Platform/NXP/Library/NorFlashLib/NorFlashLib.c| 658 ++
 Platform/NXP/Library/NorFlashLib/NorFlashLib.inf  |  42 ++
 7 files changed, 1156 insertions(+)
 create mode 100644 Platform/NXP/Include/Library/NorFlashLib.h
 create mode 100644 Platform/NXP/Library/NorFlashLib/CfiCommand.h
 create mode 100644 Platform/NXP/Library/NorFlashLib/CfiNorFlashLib.c
 create mode 100644 Platform/NXP/Library/NorFlashLib/CfiNorFlashLib.h
 create mode 100644 Platform/NXP/Library/NorFlashLib/IfcNorFlashLib.c
 create mode 100644 Platform/NXP/Library/NorFlashLib/NorFlashLib.c
 create mode 100644 Platform/NXP/Library/NorFlashLib/NorFlashLib.inf

diff --git a/Platform/NXP/Include/Library/NorFlashLib.h 
b/Platform/NXP/Include/Library/NorFlashLib.h
new file mode 100644
index 000..8eb0f82
--- /dev/null
+++ b/Platform/NXP/Include/Library/NorFlashLib.h
@@ -0,0 +1,67 @@
+/** @file
+
+ Copyright (c) 2011-2012, ARM Ltd. All rights reserved.
+ Copyright (c) 2016, Freescale Semiconductor. All rights reserved.
+ Copyright 2017 NXP
+
+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.
+
+ **/
+
+#ifndef _NOR_FLASH_LIB_H_
+#define _NOR_FLASH_LIB_H_
+
+#include 
+
+typedef struct {
+  UINTN DeviceBaseAddress;   // Start address of the Device Base Address (DBA)
+  UINTN RegionBaseAddress;   // Start address of one single region
+  UINTN Size;
+  UINTN BlockSize;
+  UINTN MultiByteWordCount;  // Maximum Word count that can be written to Nor 
Flash in multi byte write
+  UINTN WordWriteTimeOut;// single byte/word timeout usec
+  UINTN BufferWriteTimeOut;  // buffer write timeout usec
+  UINTN BlockEraseTimeOut;   // block erase timeout usec
+  UINTN ChipEraseTimeOut;// chip erase timeout usec
+} NorFlashDescription;
+
+EFI_STATUS
+NorFlashPlatformGetDevices (
+  OUT NorFlashDescription **NorFlashDevices,
+  OUT UINT32  *Count
+  );
+
+EFI_STATUS
+NorFlashPlatformFlashGetAttributes (
+  OUT NorFlashDescription *NorFlashDevices,
+  IN  UINT32  Count
+  );
+
+typedef struct {
+  UINT8 ChipSelect;
+  IFC_REGS* IfcRegs;
+} NorFlashInfo;
+
+VOID
+GetIfcNorFlashInfo (
+  IN NorFlashInfo *NorFlashInfo
+  );
+
+VOID
+GetIfcNorFlashTimings (
+  IN IfcTimings * NorIfcTimings
+  );
+
+typedef UINT16 FLASH_DATA;
+
+FLASH_DATA IfcNorFlashData (FLASH_DATA Val);
+
+VOID IfcNorWrite32 (VOID *a, UINT32 v);
+
+#endif /* _NOR_FLASH_LIB_H_ */
diff --git a/Platform/NXP/Library/NorFlashLib/CfiCommand.h 
b/Platform/NXP/Library/NorFlashLib/CfiCommand.h
new file mode 100644
index 000..5e755be
--- /dev/null
+++ b/Platform/NXP/Library/NorFlashLib/CfiCommand.h
@@ -0,0 +1,99 @@
+/** @CfiCommand.h
+
+  Copyright 2017 NXP
+
+  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.
+
+**/
+
+#ifndef __CFI_COMMAND_H__
+#define __CFI_COMMAND_H__
+
+// CFI Data "QRY"
+#define CFI_QRY_Q0x51
+#define CFI_QRY_R0x52
+#define CFI_QRY_Y0x59
+#define CFI_QRY  0x515259
+
+#define ENTER_CFI_QUERY_MODE_ADDR   0x0055
+#define ENTER_CFI_QUERY_MODE_CMD0x0098
+
+#define CFI_QUERY_UNIQUE_QRY_STRING 0x10
+
+// Offsets for CFI queries
+#define CFI_QUERY_TYP_TIMEOUT_WORD_WRITE0x1F
+#define CFI_QUERY_TYP_TIMEOUT_MAX_BUFFER_WRITE  0x20
+#define CFI_QUERY_TYP_TIMEOUT_BLOCK_ERASE   0x21
+#define CFI_QUERY_TYP_TIMEOUT_CHIP_ERASE0x22
+#define CFI_QUERY_MAX_TIMEOUT_WORD_WRITE0x23
+#define CFI_QUERY_MAX_TIMEOUT_MAX_BUFFER_WRITE  0x24
+#define CFI_QUERY_MAX_TIMEOUT_BLOCK_ERASE   0x25
+#define CFI_QUERY_MAX_TIMEOUT_CHIP_ERASE0x26
+#define CFI_QUERY_DEVICE_SIZE   0x27
+#define CFI_QUERY_MAX_NUM_BYTES_WRITE   

[edk2] [PATCH 3/4] Platform/NXP : Add Support for NOR Flash driver

2017-12-01 Thread Vabhav
This patch adds support for NOR flash Driver

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vabhav 
---
 .../NXP/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c   | 254 +++
 Platform/NXP/Drivers/NorFlashDxe/NorFlashDxe.c | 446 
 Platform/NXP/Drivers/NorFlashDxe/NorFlashDxe.inf   |  65 ++
 Platform/NXP/Drivers/NorFlashDxe/NorFlashFvbDxe.c  | 807 +
 Platform/NXP/Include/Library/NorFlash.h| 222 ++
 5 files changed, 1794 insertions(+)
 create mode 100644 Platform/NXP/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c
 create mode 100644 Platform/NXP/Drivers/NorFlashDxe/NorFlashDxe.c
 create mode 100755 Platform/NXP/Drivers/NorFlashDxe/NorFlashDxe.inf
 create mode 100644 Platform/NXP/Drivers/NorFlashDxe/NorFlashFvbDxe.c
 create mode 100644 Platform/NXP/Include/Library/NorFlash.h

diff --git a/Platform/NXP/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c 
b/Platform/NXP/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c
new file mode 100644
index 000..5f3c2ad
--- /dev/null
+++ b/Platform/NXP/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c
@@ -0,0 +1,254 @@
+/** @NorFlashBlockIoDxe.c
+
+  Based on NorFlash implementation available in 
ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c
+
+  Copyright (c) 2011 - 2014, ARM Ltd. All rights reserved.
+  Copyright 2017 NXP
+
+  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 
+
+//
+// BlockIO Protocol function EFI_BLOCK_IO_PROTOCOL.Reset
+//
+EFI_STATUS
+EFIAPI
+NorFlashBlockIoReset (
+  IN EFI_BLOCK_IO_PROTOCOL  *This,
+  IN BOOLEANExtendedVerification
+  )
+{
+  NOR_FLASH_INSTANCE *Instance;
+
+  Instance = INSTANCE_FROM_BLKIO_THIS(This);
+
+  DEBUG ((DEBUG_INFO, "NorFlashBlockIoReset(MediaId=0x%x)\n",
+This->Media->MediaId));
+
+  return NorFlashPlatformReset (Instance->DeviceBaseAddress);
+}
+
+//
+// BlockIO Protocol function EFI_BLOCK_IO_PROTOCOL.ReadBlocks
+//
+EFI_STATUS
+EFIAPI
+NorFlashBlockIoReadBlocks (
+  IN  EFI_BLOCK_IO_PROTOCOL   *This,
+  IN  UINT32  MediaId,
+  IN  EFI_LBA Lba,
+  IN  UINTN   BufferSizeInBytes,
+  OUT VOID*Buffer
+  )
+{
+  NOR_FLASH_INSTANCE   *Instance;
+  EFI_STATUS   Status;
+  EFI_BLOCK_IO_MEDIA   *Media;
+  UINTNNumBlocks;
+  UINT8*pReadBuffer;
+  UINTNBlockCount;
+  UINTNBlockSizeInBytes;
+  EFI_LBA  CurrentBlock;
+
+  Status = EFI_SUCCESS;
+
+  if ((This == NULL) || (Buffer == NULL)) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  Instance = INSTANCE_FROM_BLKIO_THIS(This);
+  Media = This->Media;
+
+  if (Media  == NULL) {
+DEBUG ((DEBUG_ERROR, "%a : Media is NULL\n", __FUNCTION__));
+return EFI_INVALID_PARAMETER;
+  }
+
+  NumBlocks = ((UINTN)BufferSizeInBytes) / Instance->Media.BlockSize ;
+
+  DEBUG ((DEBUG_BLKIO, "%a : (MediaId=0x%x, Lba=%ld, "
+"BufferSize=0x%x bytes (%d kB)"
+", BufferPtr @ 0x%p)\n",
+__FUNCTION__,MediaId, Lba,
+BufferSizeInBytes, Buffer));
+
+  if (!Media) {
+Status = EFI_INVALID_PARAMETER;
+  }
+  else if (!Media->MediaPresent) {
+Status = EFI_NO_MEDIA;
+  }
+  else if (Media->MediaId != MediaId) {
+Status = EFI_MEDIA_CHANGED;
+  }
+  else if ((Media->IoAlign >= 2) &&
+  (((UINTN)Buffer & (Media->IoAlign - 1)) != 0)) {
+Status = EFI_INVALID_PARAMETER;
+  }
+  else if (BufferSizeInBytes == 0) {
+// Return if we have not any byte to read
+Status = EFI_SUCCESS;
+  }
+  else if ((BufferSizeInBytes % Media->BlockSize) != 0) {
+// The size of the buffer must be a multiple of the block size
+DEBUG((DEBUG_ERROR, "%a : BlockSize in bytes = 0x%x\n",__FUNCTION__,
+ BufferSizeInBytes));
+Status = EFI_INVALID_PARAMETER;
+  } else if ((Lba + NumBlocks - 1) > Media->LastBlock) {
+// All blocks must be within the device
+DEBUG((DEBUG_ERROR, "%a : Read will exceed last block %d, %d, %d \n",
+__FUNCTION__, Lba, NumBlocks, Media->LastBlock));
+Status = EFI_INVALID_PARAMETER;
+  } else {
+BlockSizeInBytes = Instance->Media.BlockSize;
+
+/* Because the target *Buffer is a pointer to VOID,
+ * we must put all the data into a pointer
+ * to a proper data type, so use *pReadBuffer */
+pReadBuffer = (UINT8 *)Buffer;
+
+CurrentBlock = Lba;
+// Read data block by Block
+for (BlockCount = 0; BlockCount < NumBlocks; BlockCount++, 

[edk2] [PATCH 4/4] Compilation:Modify dsc, fdf files and add inc file

2017-12-01 Thread Vabhav
This patch adds support for compilation of IfcFlashLib,
NorFlashLib,Nor flash Driver and include runtime
variable support

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vabhav 
---
 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc | 22 +++
 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf |  9 ++-
 Platform/NXP/LS1043aRdbPkg/VarStore.fdf.inc  | 98 
 Platform/NXP/NxpQoriqLs.dsc  |  6 +-
 4 files changed, 133 insertions(+), 2 deletions(-)
 create mode 100644 Platform/NXP/LS1043aRdbPkg/VarStore.fdf.inc

diff --git a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc 
b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
index 19d4d30..4b3ac02 100644
--- a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
+++ b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
@@ -39,6 +39,16 @@
   SocLib|edk2-platforms/Silicon/NXP/Chassis/LS1043aSocLib.inf
   
RealTimeClockLib|edk2-platforms/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.inf
 
+  #
+  # Nor Lib
+  #
+  NorFlashLib|edk2-platforms/Platform/NXP/Library/NorFlashLib/NorFlashLib.inf
+
+  #
+  # IFC FLASH Lib
+  #
+  IfcFlashLib|edk2-platforms/Platform/NXP/Library/IfcFlashLib/IfcFlashLib.inf
+
 [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"LS1043a RDB board"
 
@@ -55,6 +65,13 @@
   gNxpQoriqLsTokenSpaceGuid.PcdWdogBigEndian|TRUE
 
   #
+  # NV Storage PCDs.
+  #
+  gArmTokenSpaceGuid.PcdVFPEnabled|1
+  gNxpQoriqLsTokenSpaceGuid.PcdFlashDeviceBase64|0x06000
+  gNxpQoriqLsTokenSpaceGuid.PcdFlashReservedRegionBase64|0x6030
+
+  #
   # I2C controller Pcds
   #
   gNxpQoriqLsTokenSpaceGuid.PcdI2cBus|0
@@ -74,4 +91,9 @@
   edk2-platforms/Platform/NXP/Drivers/WatchDog/WatchDogDxe.inf
   edk2-platforms/Platform/NXP/Drivers/I2cDxe/I2cDxe.inf
 
+  #
+  # NOR
+  #
+  edk2-platforms/Platform/NXP/Drivers/NorFlashDxe/NorFlashDxe.inf
+
  ##
diff --git a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf 
b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
index 9a8f242..902de2d 100644
--- a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
+++ b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
@@ -54,6 +54,7 @@ NumBlocks = 0xEC890
 gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
 FV = FVMAIN_COMPACT
 
+!include VarStore.fdf.inc
 
 

 #
@@ -103,7 +104,8 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
   INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   INF EmbeddedPkg/EmbeddedMonotonicCounter/EmbeddedMonotonicCounter.inf
-  INF MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf
+  INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+  INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
   INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
   INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
 
@@ -120,6 +122,11 @@ READ_LOCK_STATUS   = TRUE
   INF EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf
 
   #
+  # NOR Driver
+  #
+  INF edk2-platforms/Platform/NXP/Drivers/NorFlashDxe/NorFlashDxe.inf
+
+  #
   # Network modules
   #
   INF  MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
diff --git a/Platform/NXP/LS1043aRdbPkg/VarStore.fdf.inc 
b/Platform/NXP/LS1043aRdbPkg/VarStore.fdf.inc
new file mode 100644
index 000..0aea642
--- /dev/null
+++ b/Platform/NXP/LS1043aRdbPkg/VarStore.fdf.inc
@@ -0,0 +1,98 @@
+## @file
+#  FDF include file with FD definition that defines an empty variable store.
+#
+#  Copyright (c) 2016, Freescale Semiconductor. All rights reserved.
+#  Copyright (c) 2016, Linaro, Ltd. All rights reserved.
+#  Copyright (C) 2014, Red Hat, Inc.
+#  Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
+#
+#  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.
+#
+##
+
+[FD.LS1043aRdbNv_EFI]
+
+BaseAddress= 0x6030|gNxpQoriqLsTokenSpaceGuid.PcdNvFdBase  #The 
base address of the FLASH device
+Size   = 0x000C|gNxpQoriqLsTokenSpaceGuid.PcdNvFdSize  #The 
size in bytes of the FLASH device
+ErasePolarity = 1
+BlockSize  = 0x1
+NumBlocks  = 0xC
+
+#
+# Place NV Storage just above Platform Data Base
+#
+DEFINE NVRAM_AREA_VARIABLE_BASE= 0x
+DEFINE NVRAM_AREA_VARIABLE_SIZE= 0x0004
+DEFINE FTW_WORKING_BASE= $(NVRAM_AREA_VARIABLE_BASE) + 
$(NVRAM_AREA_VARIABLE_SIZE)
+DEFINE FTW_WORKING_SIZE= 0x0004
+DEFINE 

[edk2] [PATCH 1/4] Platform/NXP : Add Integrated flash controller library support

2017-12-01 Thread Vabhav
On NXP Layerscape SoCs,NOR Flash device interfacing is
via IFC and IfcFlashLib provides helper functions to be
used by NXP NOR flash library

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vabhav 
---
 Platform/NXP/Include/Library/Ifc.h | 147 +
 Platform/NXP/Include/Library/IfcBase.h | 139 +++
 .../Include/Library/IfcBoardSpecificLib.h  |  51 +++
 Platform/NXP/Library/IfcFlashLib/IfcFlashLib.c |  65 +
 Platform/NXP/Library/IfcFlashLib/IfcFlashLib.inf   |  30 +
 5 files changed, 432 insertions(+)
 create mode 100755 Platform/NXP/Include/Library/Ifc.h
 create mode 100644 Platform/NXP/Include/Library/IfcBase.h
 create mode 100755 
Platform/NXP/LS1043aRdbPkg/Include/Library/IfcBoardSpecificLib.h
 create mode 100644 Platform/NXP/Library/IfcFlashLib/IfcFlashLib.c
 create mode 100644 Platform/NXP/Library/IfcFlashLib/IfcFlashLib.inf

diff --git a/Platform/NXP/Include/Library/Ifc.h 
b/Platform/NXP/Include/Library/Ifc.h
new file mode 100755
index 000..8cc13f6
--- /dev/null
+++ b/Platform/NXP/Include/Library/Ifc.h
@@ -0,0 +1,147 @@
+/** @Ifc.h
+
+  Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
+  Copyright 2017 NXP
+
+  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.
+
+**/
+
+#ifndef __IFC_H__
+#define __IFC_H__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IFC_BANK_COUNT4
+
+#define IFC_CSPR_REG_LEN  148
+#define IFC_AMASK_REG_LEN 144
+#define IFC_CSOR_REG_LEN  144
+#define IFC_FTIM_REG_LEN  576
+
+#define IFC_CSPR_USED_LEN sizeof(IFC_CSPR) * \
+  IFC_BANK_COUNT
+
+#define IFC_AMASK_USED_LENsizeof(IFC_AMASK) * \
+  IFC_BANK_COUNT
+
+#define IFC_CSOR_USED_LEN sizeof(IFC_CSOR) * \
+  IFC_BANK_COUNT
+
+#define IFC_FTIM_USED_LEN sizeof(IFC_FTIM) * \
+  IFC_BANK_COUNT
+
+typedef enum {
+  IFC_CS0 = 0,
+  IFC_CS1,
+  IFC_CS2,
+  IFC_CS3,
+  IFC_CS4,
+  IFC_CS5,
+  IFC_CS6,
+  IFC_CS7,
+} IFC_CHIP_SEL;
+
+typedef enum {
+  IFC_FTIM0 = 0,
+  IFC_FTIM1,
+  IFC_FTIM2,
+  IFC_FTIM3,
+} IFC_FTIMS;
+
+typedef struct {
+  UINT32 CsprExt;
+  UINT32 Cspr;
+  UINT32 Res;
+} IFC_CSPR;
+
+typedef struct {
+  UINT32 Amask;
+  UINT32 Res[0x2];
+} IFC_AMASK;
+
+typedef struct {
+  UINT32 Csor;
+  UINT32 CsorExt;
+  UINT32 Res;
+} IFC_CSOR;
+
+typedef struct {
+  UINT32 Ftim[4];
+  UINT32 Res[0x8];
+}IFC_FTIM ;
+
+/*
+ * IFC controller NOR Machine registers
+ */
+typedef struct {
+  UINT32 NorEvterStat;
+  UINT32 Res1[0x2];
+  UINT32 NorEvterEn;
+  UINT32 Res2[0x2];
+  UINT32 NorEvterIntrEn;
+  UINT32 Res3[0x2];
+  UINT32 NorErattr0;
+  UINT32 NorErattr1;
+  UINT32 NorErattr2;
+  UINT32 Res4[0x4];
+  UINT32 NorCr;
+  UINT32 Res5[0xEF];
+} IFC_NOR;
+
+/*
+ * IFC Controller Registers
+ */
+typedef struct {
+  UINT32  IfcRev;
+  UINT32  Res1[0x2];
+  IFC_CSPRCsprCs[IFC_BANK_COUNT];
+  UINT8   Res2[IFC_CSPR_REG_LEN - IFC_CSPR_USED_LEN];
+  IFC_AMASK   AmaskCs[IFC_BANK_COUNT];
+  UINT8   Res3[IFC_AMASK_REG_LEN - IFC_AMASK_USED_LEN];
+  IFC_CSORCsorCs[IFC_BANK_COUNT];
+  UINT8   Res4[IFC_CSOR_REG_LEN - IFC_CSOR_USED_LEN];
+  IFC_FTIMFtimCs[IFC_BANK_COUNT];
+  UINT8   Res5[IFC_FTIM_REG_LEN - IFC_FTIM_USED_LEN];
+  UINT32  RbStat;
+  UINT32  RbMap;
+  UINT32  WpMap;
+  UINT32  IfcGcr;
+  UINT32  Res7[0x2];
+  UINT32  CmEvter_stat;
+  UINT32  Res8[0x2];
+  UINT32  CmEvterEn;
+  UINT32  Res9[0x2];
+  UINT32  CmEvterIntrEn;
+  UINT32  Res10[0x2];
+  UINT32  CmErattr0;
+  UINT32  CmErattr1;
+  UINT32  Res11[0x2];
+  UINT32  IfcCcr;
+  UINT32  IfcCsr;
+  UINT32  DdrCcrLow;
+  UINT32  Res12[0x2EA];
+  IFC_NOR IfcNor;
+} IFC_REGS;
+
+typedef struct {
+  UINT32 Ftim[IFC_BANK_COUNT];
+  UINT32 CsprExt;
+  UINT32 Cspr;
+  UINT32 Csor;
+  UINT32 Amask;
+} IfcTimings;
+
+#endif //__IFC_H__
diff --git a/Platform/NXP/Include/Library/IfcBase.h 
b/Platform/NXP/Include/Library/IfcBase.h
new file mode 100644
index 000..7020a29
--- /dev/null
+++ b/Platform/NXP/Include/Library/IfcBase.h
@@ -0,0 +1,139 @@
+/** @IfcLib.h
+
+  Copyright 2017 NXP
+
+  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 

[edk2] [platforms: PATCH v2 4/4] Marvell/Drivers: MvPhyDxe: Cleanup the header

2017-12-01 Thread Marcin Wojtas
This patch removes unused macros defined in MvPhyDxe.h, as well
as improves the style and comments. Pick single definition
of the autonegotiation timeout - two different macros were used
for the same purpose.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.c |   2 +-
 Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.h | 152 
 2 files changed, 31 insertions(+), 123 deletions(-)

diff --git a/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.c 
b/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.c
index e776a91..dd2edae 100644
--- a/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.c
+++ b/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.c
@@ -328,7 +328,7 @@ MvPhyInit1512 (
 
 DEBUG((DEBUG_ERROR, "MvPhyDxe: Waiting for PHY auto negotiation... "));
 for (i = 0; !(Data & BMSR_ANEGCOMPLETE); i++) {
-  if (i > PHY_ANEG_TIMEOUT) {
+  if (i > PHY_AUTONEGOTIATE_TIMEOUT) {
 DEBUG((DEBUG_ERROR, "timeout\n"));
 PhyDev->LinkUp = FALSE;
 return EFI_TIMEOUT;
diff --git a/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.h 
b/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.h
index 0c3d935..66974bb 100644
--- a/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.h
+++ b/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.h
@@ -34,137 +34,45 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
 #ifndef __MV_PHY_DXE_H__
 #define __MV_PHY_DXE_H__
 
-#define MII_BMCR  0x00  /* Basic mode control Register */
-#define MII_BMSR  0x01  /* Basic mode status Register  */
-#define MII_PHYSID1  0x02  /* PHYS ID 1   */
-#define MII_PHYSID2  0x03  /* PHYS ID 2   */
-#define MII_ADVERTISE  0x04  /* Advertisement control Reg   */
-#define MII_LPA0x05  /* Link partner ability Reg*/
-#define MII_EXPANSION  0x06  /* Expansion Register */
-#define MII_CTRL1000  0x09  /* 1000BASE-T control */
-#define MII_STAT1000  0x0a  /* 1000BASE-T status */
-#define MII_ESTATUS  0x0f  /* Extended Status */
-#define MII_DCOUNTER  0x12  /* Disconnect counter */
-#define MII_FCSCOUNTER  0x13  /* False carrier counter   */
-#define MII_NWAYTEST  0x14  /* N-way auto-neg test Reg */
-#define MII_RERRCOUNTER 0x15  /* Receive error counter   */
-#define MII_SREVISION  0x16  /* Silicon revision */
-#define MII_RESV1  0x17  /* Reserved...   */
-#define MII_LBRERROR  0x18  /* Lpback, rx, bypass error*/
-#define MII_PHYADDR  0x19  /* PHY address   */
-#define MII_RESV2  0x1a  /* Reserved...   */
-#define MII_TPISTATUS  0x1b  /* TPI status for 10mbps   */
-#define MII_NCONFIG  0x1c  /* Network interface config*/
-
-/* Basic mode control Register. */
-#define BMCR_RESV0x003f  /* Unused...   */
-#define BMCR_SPEED10000x0040  /* MSB of Speed (1000) */
-#define BMCR_CTST0x0080  /* Collision test */
-#define BMCR_FULLDPLX0x0100  /* Full duplex   */
-#define BMCR_ANRESTART0x0200  /* Auto negotiation restart*/
-#define BMCR_ISOLATE0x0400  /* Disconnect DP83840 from MII */
-#define BMCR_PDOWN0x0800  /* Powerdown the DP83840   */
-#define BMCR_ANENABLE0x1000  /* Enable auto negotiation */
-#define BMCR_SPEED1000x2000  /* Select 100Mbps */
-#define BMCR_LOOPBACK0x4000  /* TXD loopback bits */
-#define BMCR_RESET0x8000  /* Reset the DP83840 */
-
-/* Basic mode status Register. */
-#define BMSR_ERCAP0x0001  /* Ext-Reg capability */
-#define BMSR_JCD0x0002  /* Jabber detected */
-#define BMSR_LSTATUS0x0004  /* Link status   */
-#define BMSR_ANEGCAPABLE  0x0008  /* Able to do auto-negotiation */
-#define BMSR_RFAULT0x0010  /* Remote fault detected   */
-#define BMSR_ANEGCOMPLETE  0x0020  /* Auto-negotiation complete   */
-#define BMSR_RESV0x00c0  /* Unused...   */
-#define BMSR_ESTATEN0x0100  /* Extended Status in R15 */
-#define BMSR_100HALF20x0200  /* Can do 100BASE-T2 HDX */
-#define BMSR_100FULL20x0400  /* Can do 100BASE-T2 FDX */
-#define BMSR_10HALF0x0800  /* Can do 10mbps, half-duplex  */
-#define BMSR_10FULL0x1000  /* Can do 10mbps, full-duplex  */
-#define BMSR_100HALF0x2000  /* Can do 100mbps, half-duplex */
-#define BMSR_100FULL0x4000  /* Can do 100mbps, full-duplex */
-#define BMSR_100BASE40x8000  /* Can do 100mbps, 4k packets  */
-
-#define PHY_ANEG_TIMEOUT 4000
-
-#define PHY_INTERFACE_MODE_RGMII 0
-#define PHY_INTERFACE_MODE_RGMII_ID 1
-#define PHY_INTERFACE_MODE_RGMII_RXID 2
-#define PHY_INTERFACE_MODE_RGMII_TXID 3
-#define PHY_INTERFACE_MODE_SGMII 4
-#define PHY_INTERFACE_MODE_RTBI 5
-
-#define PHY_AUTONEGOTIATE_TIMEOUT 5000
+#define MII_BMCR   0x00  /* Basic mode 

[edk2] [platforms: PATCH v2 2/4] Marvell/Armada: Fix watchdog control base

2017-12-01 Thread Marcin Wojtas
Proper watchdog control base is 0xf061, so fix the
incorrect value.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
Reviewed-by: Leif Lindholm 
---
 Platform/Marvell/Armada/Armada.dsc.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
b/Platform/Marvell/Armada/Armada.dsc.inc
index 6040493..4b29691 100644
--- a/Platform/Marvell/Armada/Armada.dsc.inc
+++ b/Platform/Marvell/Armada/Armada.dsc.inc
@@ -269,7 +269,7 @@
   gEmbeddedTokenSpaceGuid.PcdMetronomeTickPeriod|1000
 
   # ARM SBSA Watchdog
-  gArmTokenSpaceGuid.PcdGenericWatchdogControlBase|0xF062
+  gArmTokenSpaceGuid.PcdGenericWatchdogControlBase|0xF061
   gArmTokenSpaceGuid.PcdGenericWatchdogRefreshBase|0xF060
   gArmTokenSpaceGuid.PcdGenericWatchdogEl2IntrNum|34
 
-- 
2.7.4

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


[edk2] [platforms: PATCH v2 1/4] Marvell/Armada: Switch to dynamic tftp command

2017-12-01 Thread Marcin Wojtas
After removal of the tftp library in EDK2, the tftp was
disabled on Armada platform. Re-enable this functionality
as a dynamic command on Armada 70x0 DB board. For this
purpose add it as a build-time selectable option, depending
on a new INCLUDE_TFTP_COMMAND parameter.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada/Armada.dsc.inc | 4 
 Platform/Marvell/Armada/Armada70x0.dsc | 1 +
 Platform/Marvell/Armada/Armada70x0.fdf | 3 +++
 3 files changed, 8 insertions(+)

diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
b/Platform/Marvell/Armada/Armada.dsc.inc
index 2a8a226..6040493 100644
--- a/Platform/Marvell/Armada/Armada.dsc.inc
+++ b/Platform/Marvell/Armada/Armada.dsc.inc
@@ -525,6 +525,10 @@
   gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
   }
 
+!ifdef $(INCLUDE_TFTP_COMMAND)
+  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
+!endif #$(INCLUDE_TFTP_COMMAND)
+
 
[BuildOptions.common.EDKII.DXE_CORE,BuildOptions.common.EDKII.DXE_DRIVER,BuildOptions.common.EDKII.UEFI_DRIVER,BuildOptions.common.EDKII.UEFI_APPLICATION]
   GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
 
diff --git a/Platform/Marvell/Armada/Armada70x0.dsc 
b/Platform/Marvell/Armada/Armada70x0.dsc
index 8e4cdb2..4e7d43c 100644
--- a/Platform/Marvell/Armada/Armada70x0.dsc
+++ b/Platform/Marvell/Armada/Armada70x0.dsc
@@ -44,6 +44,7 @@
   BUILD_TARGETS  = DEBUG|RELEASE
   SKUID_IDENTIFIER   = DEFAULT
   FLASH_DEFINITION   = Platform/Marvell/Armada/Armada70x0.fdf
+  DEFINE INCLUDE_TFTP_COMMAND= 1
 
 !include Armada.dsc.inc
 
diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
b/Platform/Marvell/Armada/Armada70x0.fdf
index ca92c60..c03bc42 100644
--- a/Platform/Marvell/Armada/Armada70x0.fdf
+++ b/Platform/Marvell/Armada/Armada70x0.fdf
@@ -176,6 +176,9 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
 
   # UEFI application (Shell Embedded Boot Loader)
   INF ShellPkg/Application/Shell/Shell.inf
+!ifdef $(INCLUDE_TFTP_COMMAND)
+  INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
+!endif #$(INCLUDE_TFTP_COMMAND)
 
   # Bds
   INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
-- 
2.7.4

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


[edk2] [platforms: PATCH v2 3/4] Marvell/Applications: FirmwareUpdate: Fix usage information

2017-12-01 Thread Marcin Wojtas
fupdate command's usage information referred to a deprecated
'-f' flag in 'examples' section. It was a residue from the
initial version of the application, removed during review
before merging to upstream branch. Correct the help information.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Applications/FirmwareUpdate/FUpdate.uni | Bin 5146 -> 5190 
bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.uni 
b/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.uni
index 
9d52e590c6d239621d226a240a3f9755210f52fe..146f624737d96e2cd354857dbb63390ebe2f347e
 100644
GIT binary patch
delta 56

[edk2] [platforms: PATCH v2 0/4] Armada 7k/8k - misc improvements pt.3

2017-12-01 Thread Marcin Wojtas
Hi,

The second version of the patchset brings the corrections
requested in the review. Details can be found in the changelog
below.

The patches are available in the github:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/misc-upstream-r20171201-2

I'm looking forward to your comments or remarks.

Best regards,
Marcin

Changelog:
v1 - > v2

* 1/4
- Add tftp as a build-time selectable option
- Update commit message

* 2/4
- Add RB

* 3/4
- Leave initial file format and reword commit message

* 4/4
- Leave PHY_AUTONEGOTIATE_TIMEOUT unmodified and
  remove double definition of the timeout.

Marcin Wojtas (4):
  Marvell/Armada: Switch to dynamic tftp command
  Marvell/Armada: Fix watchdog control base
  Marvell/Applications: FirmwareUpdate: Fix usage information
  Marvell/Drivers: MvPhyDxe: Cleanup the header

 Platform/Marvell/Applications/FirmwareUpdate/FUpdate.uni | Bin 5146 -> 5190 
bytes
 Platform/Marvell/Armada/Armada.dsc.inc   |   6 +-
 Platform/Marvell/Armada/Armada70x0.dsc   |   1 +
 Platform/Marvell/Armada/Armada70x0.fdf   |   3 +
 Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.c |   2 +-
 Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.h | 152 

 6 files changed, 40 insertions(+), 124 deletions(-)

-- 
2.7.4

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


Re: [edk2] [platforms: PATCH 3/4] Marvell/Applications: FirmwareUpdate: Fix usage information

2017-12-01 Thread Marcin Wojtas
2017-12-01 14:27 GMT+01:00 Leif Lindholm :
> On Fri, Dec 01, 2017 at 03:28:53AM +0100, Marcin Wojtas wrote:
>> fupdate command's usage information referred to a deprecated
>> flag in 'examples' section. Fix this and replace damaged
>> FUpdate.uni file with its proper text version.
>
> Mention which flag?

The '-f' flag was removed from the function after your review a really
long time ago. Someone just noticed it still is in the 'help'. I will
be more verbose in the commit log.

>
> Also, it's called .uni because it's unicode.
> Technically, it ought to be UCS-2, but I don't complain about UTF-8.
> I don't see any issues with the existing version, it only happens to
> be UTF-16 (according to 'file' - I guess it may be misidentified
> UCS-2). Emacs doesn't have any issues editing it.
>

I use vim, but will try emacs for this file then.

Marcin

> /
> Leif
>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Marcin Wojtas 
>> ---
>>  Platform/Marvell/Applications/FirmwareUpdate/FUpdate.uni | Bin 5146 -> 2300 
>> bytes
>>  1 file changed, 0 insertions(+), 0 deletions(-)
>>
>> diff --git a/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.uni 
>> b/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.uni
>> index 
>> 9d52e590c6d239621d226a240a3f9755210f52fe..293ae6650b92d04bcc977193ea4390e3d938a15f
>>  100644
>> GIT binary patch
>> literal 2300
>> zcmb_dU2mf}6n*DcTxDLS6>VqdVIMlXD-m!KO9WU9O(Ts|Q9fErfFmHS^6
>> zXrw5o7LnG
>> z#jRycYjfd|FY~hPOA2>7#Ikrr2eqfJ%uD%J7Bsxdo))q$sp?cS!P+LM$quA;0}YDy
>> zeQ9G;A^V||&-> zGmvblSNkqE==3bxtUCY(TWorl!z-!I{Hy&-<+hb|CGCJMhXF> z7hH1H7E)``lit*n!@XtE_`9Y{W<9BDqLixw;ro7o4nqd28aI1ZZzbiY{> zj>^=~O+%e0N6nYaAZ}h~vMD?C@aK$>`AnIK5lSxh5bj?{ov?^TdjE@*?heq;&> zo3b5D4@N_fLQF?ZhEB_@?mv2A8mQ@=OoS#}R2r1%@o1hlYf7!y53eB
>> zE$7jWs_T*RK+os&;3!C}sB8 zmAR~Bj_p!AvD0pAkG|{sV>QW&3liZX**GyHjH5Vw;2!g6zNKWv$PJ@y%$KW#R-x~)
>> zSdbHVm<^Jc&(kEt#LN-cInxW46Ksh+MllnD!kG9v@;ShO9y>w8nXrimuAh25SlR>t
>> z3c`eZzUB$SlF&9u$8FZfHVPNCX0f{hiZkavPqv20f+vB_wLmh5A}3C`oBB>nQ5r{~
>> zV1%+Pj|> zAsp!WHi?M2To2eIg9J{zwMR_B{!S5uMe>}rvt+{h{2z*-C2ktCwWbUiL^>A> zG7LSVvtaQ9cbWKR`Jq;RL8)LiG9->k3> z*y> zp+?zo!LHCM4rWUYscp1zkP`+$UTs9MIu5z8Cc{EsG?Ms&9Pa@b-V}`13qIP!Nan6a
>> zxp9Jj?Q3^^XIXcDezL4jb=JNVWreG-Y;RJWi?V^+ntq4yo> zX@mx`>FOjh2>a}%oB(Fl>^50Zwci!Epy&(D7P4#1aUZ90)iijHX5YK-t|?
>> zKTpx=5x_l0p9PC;5JrNFaf-(ODdQi$%ClO(w^25{{xz;%OwtYQu%>UWS_e}#QIw4?
>> zrNZVP&^1es2{-1(d*dp5bZ}JI{rEXj{y;mvU?SpF)mi^~d|@>@RsGj{Gk0TB-r~I(
>> KL8dx>8u1U73A2&_
>>
>> literal 5146
>> zcmd6r+fN%;5XR@ZQvZh)c}b%HX&?GPFOo4PK{A+nZD^!ODA<@-!Zx){5?{|h_
>> zFE$rNsuWrFo;^Ef=9_OW=dAzzXWQO<)1U9{J8Rm^uI> zKibb49olC}{B0L@rB7xDHkIUs=B9eG)Y@4Z@vN=;p=}x3`PSF$?W
>> znRSFCG{xEj8|lfNwBP7DmmDj`3CU11OCcU>eP;W*UL`#v$<1t{xvJ&2nh8x4p}x~S
>> zzT@#yqf9nHf*h8HN%K#l(jgTBAee3Ytq!n=Gc+oP_Dwv$v
>> zt=3M(e5SjCkC=0gC}?cGu!^_5)k^ktNNU*23OAF;~c(r>8^}9>6mfXN%-LnD7LC
>> zKppq!fvv)45Et=(n;1bSK3?k=o#?_3;=nW8t=ozGwg4Nr43&?> zmbUYdahaZ#KW}vR6m#gBrA(`Gg;j9kF}VRsd|S#g5h^f$R)*jgvaG6C)KqgICwrZx
>> zGQJoW*+VY4J;(K!|8P>ESeI3v#RFv*m|<#Os?D$**OxHmp0CfJI#V9+q1eOo0_oFy
>> zQT>6ae66zR+PwPzU%sM}h|fjJvNEa|4;ABqJcVPrV^J4Tb>20|HP=LK(TTju#~NKJ
>> z>g%c`DzIR1wL5uT6n!^v#g*6|37gk;wI9*N!5wu_?VOqX@lN2lxp(=Za?r}1XKJ}?
>> zvXUp!bI+gP&^xf_G#wcx;S~*z4$eHQ=tAC;%UR|qs9O3q6^XWDPbg}PS|3Tnt$gv0
>> z6)bz7dn^kVsk05FeWdT;9uMq$uf(o*JUT?t1sC$69;2Rp&|aELF4z9IZ#_G;hI&;?
>> 

[edk2] [Patch 00/14] Enable Structure PCD support in edk2

2017-12-01 Thread Liming Gao
All code are in https://github.com/tianocore/edk2-staging/tree/StructurePcdV3.
Patches are 544d8e..dd79a7. Unit Test cases are 89e7c7..1b2d19.
The patches will not be sent by mail. Please review them in edk2-staging.

Structure PCD is to support the same C structure/Enum/Macro definition in PCD,
and specify the value for individual fields in a VOID* PCD in DEC/DSC. It
includes the group of the sub features.
[BaseTools] Structure PCD value assignment in DEC/DSC
https://bugzilla.tianocore.org/show_bug.cgi?id=542
[BaseTools] Extended SKU Support - Inheritance
https://bugzilla.tianocore.org/show_bug.cgi?id=543
[BaseTools/PCD] Pcd Database size optimization for multi-SKU
https://bugzilla.tianocore.org/show_bug.cgi?id=546
[BaseTools/PCD/HiiDataBase] Collect DynamicHii PCD value as the default setting
for EFI Variable and HII VarStore.
https://bugzilla.tianocore.org/show_bug.cgi?id=611
[BaseTools] Build report update for Structure PCD value and SKU, DefaultStore
https://bugzilla.tianocore.org/show_bug.cgi?id=706

The main changes are in BaseTools to calculate structure PCD value.
Firmware code Pcd driver, HiiDataBase and Variable driver are updated.
And, PCD database format has been optimized. So, its version is changed
from current 6 to 7. Besides it, others are compatible. There is no impact
on current platform and current usage. If you find any breaking,
please raise it to me.

The detail changes are specified in each tracker and each RFC.

Unit Test:
1) Windows VS2015 Build TestPkg and Nt32Pkg
2) Linux GCC5 Build OvmfPkg
3) Verify Strucutre PCD field value collection
4) Verify Strucutre PCD from the different SKUs
5) Structure DynamicHii PCD is saved as the default EFI variable
6) Structure DynamicHii PCD impacts HII IFR default setting
7) Strucutre PCD field value is shown in build report.
8) Multiple SKU PCD values is shown in build report.

Liming Gao (14):
  BaseTools: Update Makefile to work at absolute path
  BaseTools: Add PcdValueCommon logic into C source CommonLib
  MdeModulePkg: Update PCD driver to support Dynamic PcdVpdBaseAddress
  MdeModulePkg: Enable Firmware to retrieve the default setting
  MdeModulePkg: Update PCD driver to support the optimized PcdDataBase
  MdeModulePkg: Pcd/HiiDatabase Update default setting format with max
size
  BaseTools: Support Structure PCD value assignment in DEC/DSC
  BaseTools: Collect DynamicHii PCD values and assign it to VPD PCD
Value
  BaseTools: Support Structure PCD value inherit between the different
SKUs
  BaseTools: PcdDataBase Optimization for multiple SkuIds
  BaseTools: Report Structure PCD value and SKU, DefaultStore info
  BaseTools: Update NV Default Header format to include the max size
  BaseTools: Optimize VPD PCD value for the different SKUs
  BaseTools: Fixed the issue of Multiple Skus are always disables

 BaseTools/Source/C/Common/GNUmakefile  |3 +-
 BaseTools/Source/C/Common/Makefile |3 +-
 BaseTools/Source/C/Common/PcdValueCommon.c |  607 +
 BaseTools/Source/C/Common/PcdValueCommon.h |   78 +
 BaseTools/Source/C/Makefiles/app.makefile  |2 +-
 BaseTools/Source/C/Makefiles/ms.app|4 +-
 BaseTools/Source/Python/AutoGen/AutoGen.py |  406 ++-
 BaseTools/Source/Python/AutoGen/GenC.py|   77 +-
 BaseTools/Source/Python/AutoGen/GenMake.py |2 +-
 BaseTools/Source/Python/AutoGen/GenPcdDb.py|  260 +-
 BaseTools/Source/Python/AutoGen/GenVar.py  |  341 +++
 BaseTools/Source/Python/Common/BuildToolError.py   |3 +
 BaseTools/Source/Python/Common/DataType.py |2 +
 BaseTools/Source/Python/Common/GlobalData.py   |6 +
 BaseTools/Source/Python/Common/Misc.py |  221 +-
 .../Source/Python/Common/ToolDefClassObject.py |1 -
 BaseTools/Source/Python/Common/VpdInfoFile.py  |   11 +-
 .../Source/Python/CommonDataClass/CommonClass.py   |5 +-
 .../Source/Python/CommonDataClass/DataClass.py |   11 +
 .../Source/Python/Workspace/BuildClassObject.py|   66 +
 BaseTools/Source/Python/Workspace/DecBuildData.py  |  463 
 BaseTools/Source/Python/Workspace/DscBuildData.py  | 1961 ++
 BaseTools/Source/Python/Workspace/InfBuildData.py  | 1212 +
 .../Source/Python/Workspace/MetaFileParser.py  |  311 ++-
 BaseTools/Source/Python/Workspace/MetaFileTable.py |   11 +-
 .../Source/Python/Workspace/WorkspaceCommon.py |   44 +-
 .../Source/Python/Workspace/WorkspaceDatabase.py   | 2834 +---
 BaseTools/Source/Python/build/BuildReport.py   |  296 +-
 BaseTools/Source/Python/build/build.py |2 +
 .../Include/Guid/PcdDataBaseSignatureGuid.h|   82 +-
 MdeModulePkg/MdeModulePkg.dec  |   20 +-
 MdeModulePkg/Universal/HiiDatabaseDxe/Database.c   |  470 
 .../Universal/HiiDatabaseDxe/HiiDatabase.h |9 +-
 .../Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf|1 +
 

Re: [edk2] [platforms: PATCH 2/4] Marvell/Armada: Fix watchdog control base

2017-12-01 Thread Marcin Wojtas
2017-12-01 14:19 GMT+01:00 Leif Lindholm :
> On Fri, Dec 01, 2017 at 03:28:52AM +0100, Marcin Wojtas wrote:
>> Proper watchdog control base is 0xf061, so fix the
>> incorrect value.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Marcin Wojtas 
>> ---
>>  Platform/Marvell/Armada/Armada.dsc.inc | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
>> b/Platform/Marvell/Armada/Armada.dsc.inc
>> index 1b68ef3..cf81615 100644
>> --- a/Platform/Marvell/Armada/Armada.dsc.inc
>> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
>> @@ -269,7 +269,7 @@
>>gEmbeddedTokenSpaceGuid.PcdMetronomeTickPeriod|1000
>>
>># ARM SBSA Watchdog
>> -  gArmTokenSpaceGuid.PcdGenericWatchdogControlBase|0xF062
>> +  gArmTokenSpaceGuid.PcdGenericWatchdogControlBase|0xF061
>
> Hmm, do we never start the watchdog, or how did we not notice this?
> I can confirm against the docs that the fix is correct, so:
> Reviewed-by: Leif Lindholm 
>

The problem was noticed when running SBSA test suite on a branch
already equipped with ACPI support.

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


Re: [edk2] [platforms: PATCH 1/4] Marvell/Armada: Switch to dynamic tftp command

2017-12-01 Thread Marcin Wojtas
Hi Leif,




2017-12-01 14:04 GMT+01:00 Leif Lindholm :
> On Fri, Dec 01, 2017 at 03:28:51AM +0100, Marcin Wojtas wrote:
>> After removal of the tftp library in EDK2, the tftp was
>> disabled on Armada platform. Re-enable this functionality
>> as a dynamic command.
>
> I did request this to be re-added as a build-time selectable option
> like it is done on the Hisilicon platforms.
>
> Including non-standard shell commands by default does not make sense
> to me.
>

Sure, I read your comment after sending the patch... Will correct it
of course in v2.

Best regards,
Marcin

>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Marcin Wojtas 
>> ---
>>  Platform/Marvell/Armada/Armada.dsc.inc | 1 +
>>  Platform/Marvell/Armada/Armada70x0.fdf | 1 +
>>  2 files changed, 2 insertions(+)
>>
>> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
>> b/Platform/Marvell/Armada/Armada.dsc.inc
>> index 2a8a226..1b68ef3 100644
>> --- a/Platform/Marvell/Armada/Armada.dsc.inc
>> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
>> @@ -524,6 +524,7 @@
>>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
>>gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
>>}
>> +  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
>>
>>  
>> [BuildOptions.common.EDKII.DXE_CORE,BuildOptions.common.EDKII.DXE_DRIVER,BuildOptions.common.EDKII.UEFI_DRIVER,BuildOptions.common.EDKII.UEFI_APPLICATION]
>>GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
>> diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
>> b/Platform/Marvell/Armada/Armada70x0.fdf
>> index ca92c60..65c6474 100644
>> --- a/Platform/Marvell/Armada/Armada70x0.fdf
>> +++ b/Platform/Marvell/Armada/Armada70x0.fdf
>> @@ -176,6 +176,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
>>
>># UEFI application (Shell Embedded Boot Loader)
>>INF ShellPkg/Application/Shell/Shell.inf
>> +  INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
>>
>># Bds
>>INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.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 3/4] Marvell/Applications: FirmwareUpdate: Fix usage information

2017-12-01 Thread Leif Lindholm
On Fri, Dec 01, 2017 at 03:28:53AM +0100, Marcin Wojtas wrote:
> fupdate command's usage information referred to a deprecated
> flag in 'examples' section. Fix this and replace damaged
> FUpdate.uni file with its proper text version.

Mention which flag?

Also, it's called .uni because it's unicode.
Technically, it ought to be UCS-2, but I don't complain about UTF-8.
I don't see any issues with the existing version, it only happens to
be UTF-16 (according to 'file' - I guess it may be misidentified
UCS-2). Emacs doesn't have any issues editing it.

/
Leif

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Applications/FirmwareUpdate/FUpdate.uni | Bin 5146 -> 2300 
> bytes
>  1 file changed, 0 insertions(+), 0 deletions(-)
> 
> diff --git a/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.uni 
> b/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.uni
> index 
> 9d52e590c6d239621d226a240a3f9755210f52fe..293ae6650b92d04bcc977193ea4390e3d938a15f
>  100644
> GIT binary patch
> literal 2300
> zcmb_dU2mf}6n*DcTxDLS6>VqdVIMlXD-m!KO9WU9O(Ts|Q9fErfFmHS^6
> zXrw5o7LnG
> z#jRycYjfd|FY~hPOA2>7#Ikrr2eqfJ%uD%J7Bsxdo))q$sp?cS!P+LM$quA;0}YDy
> zeQ9G;A^V||&- zGmvblSNkqE==3bxtUCY(TWorl!z-!I{Hy&-<+hb|CGCJMhXF z7hH1H7E)``lit*n!@XtE_`9Y{W<9BDqLixw;ro7o4nqd28aI1ZZzbiY{ zj>^=~O+%e0N6nYaAZ}h~vMD?C@aK$>`AnIK5lSxh5bj?{ov?^TdjE@*?heq;& zo3b5D4@N_fLQF?ZhEB_@?mv2A8mQ@=OoS#}R2r1%@o1hlYf7!y53eB
> zE$7jWs_T*RK+os&;3!C}sB8QW&3liZX**GyHjH5Vw;2!g6zNKWv$PJ@y%$KW#R-x~)
> zSdbHVm<^Jc&(kEt#LN-cInxW46Ksh+MllnD!kG9v@;ShO9y>w8nXrimuAh25SlR>t
> z3c`eZzUB$SlF&9u$8FZfHVPNCX0f{hiZkavPqv20f+vB_wLmh5A}3C`oBB>nQ5r{~
> zV1%+Pj| zAsp!WHi?M2To2eIg9J{zwMR_B{!S5uMe>}rvt+{h{2z*-C2ktCwWbUiL^>A zG7LSVvtaQ9cbWKR`Jq;RL8)LiG9->k3 z*y zp+?zo!LHCM4rWUYscp1zkP`+$UTs9MIu5z8Cc{EsG?Ms&9Pa@b-V}`13qIP!Nan6a
> zxp9Jj?Q3^^XIXcDezL4jb=JNVWreG-Y;RJWi?V^+ntq4yo zX@mx`>FOjh2>a}%oB(Fl>^50Zwci!Epy&(D7P4#1aUZ90)iijHX5YK-t|?
> zKTpx=5x_l0p9PC;5JrNFaf-(ODdQi$%ClO(w^25{{xz;%OwtYQu%>UWS_e}#QIw4?
> zrNZVP&^1es2{-1(d*dp5bZ}JI{rEXj{y;mvU?SpF)mi^~d|@>@RsGj{Gk0TB-r~I(
> KL8dx>8u1U73A2&_
> 
> literal 5146
> zcmd6r+fN%;5XR@ZQvZh)c}b%HX&?GPFOo4PK{A+nZD^!ODA<@-!Zx){5?{|h_
> zFE$rNsuWrFo;^Ef=9_OW=dAzzXWQO<)1U9{J8Rm^uI zKibb49olC}{B0L@rB7xDHkIUs=B9eG)Y@4Z@vN=;p=}x3`PSF$?W
> znRSFCG{xEj8|lfNwBP7DmmDj`3CU11OCcU>eP;W*UL`#v$<1t{xvJ&2nh8x4p}x~S
> zzT@#yqf9nHf*h8HN%K#l(jgTBAee3Ytq!n=Gc+oP_Dwv$v
> zt=3M(e5SjCkC=0gC}?cGu!^_5)k^ktNNU*23OAF;~c(r>8^}9>6mfXN%-LnD7LC
> zKppq!fvv)45Et=(n;1bSK3?k=o#?_3;=nW8t=ozGwg4Nr43&? zmbUYdahaZ#KW}vR6m#gBrA(`Gg;j9kF}VRsd|S#g5h^f$R)*jgvaG6C)KqgICwrZx
> zGQJoW*+VY4J;(K!|8P>ESeI3v#RFv*m|<#Os?D$**OxHmp0CfJI#V9+q1eOo0_oFy
> zQT>6ae66zR+PwPzU%sM}h|fjJvNEa|4;ABqJcVPrV^J4Tb>20|HP=LK(TTju#~NKJ
> z>g%c`DzIR1wL5uT6n!^v#g*6|37gk;wI9*N!5wu_?VOqX@lN2lxp(=Za?r}1XKJ}?
> zvXUp!bI+gP&^xf_G#wcx;S~*z4$eHQ=tAC;%UR|qs9O3q6^XWDPbg}PS|3Tnt$gv0
> z6)bz7dn^kVsk05FeWdT;9uMq$uf(o*JUT?t1sC$69;2Rp&|aELF4z9IZ#_G;hI&;?
> 

Re: [edk2] [platforms: PATCH 2/4] Marvell/Armada: Fix watchdog control base

2017-12-01 Thread Leif Lindholm
On Fri, Dec 01, 2017 at 03:28:52AM +0100, Marcin Wojtas wrote:
> Proper watchdog control base is 0xf061, so fix the
> incorrect value.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Armada/Armada.dsc.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
> b/Platform/Marvell/Armada/Armada.dsc.inc
> index 1b68ef3..cf81615 100644
> --- a/Platform/Marvell/Armada/Armada.dsc.inc
> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
> @@ -269,7 +269,7 @@
>gEmbeddedTokenSpaceGuid.PcdMetronomeTickPeriod|1000
>  
># ARM SBSA Watchdog
> -  gArmTokenSpaceGuid.PcdGenericWatchdogControlBase|0xF062
> +  gArmTokenSpaceGuid.PcdGenericWatchdogControlBase|0xF061

Hmm, do we never start the watchdog, or how did we not notice this?
I can confirm against the docs that the fix is correct, so:
Reviewed-by: Leif Lindholm 

>gArmTokenSpaceGuid.PcdGenericWatchdogRefreshBase|0xF060
>gArmTokenSpaceGuid.PcdGenericWatchdogEl2IntrNum|34
>  
> -- 
> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650 GOP driver.

2017-12-01 Thread Evan Lloyd


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 28 November 2017 18:18
> To: Evan Lloyd 
> Cc: edk2-devel@lists.01.org; Matteo Carlini ;
> Leif Lindholm ; Girish Pathak
> 
> Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650
> GOP driver.
>
> On 26 September 2017 at 21:15,   wrote:
> > From: Girish Pathak 
> >
> > This change adds support for the ARM Mali DP500/DP500/DP650 display
> > processors using the GOP protocol. It has been tested on FVP base
> > models + DP550 support.
> >
> > This change does not modify functionality provided by PL111 or
> > HDLCD. The driver should be suitable for those platforms
> > that implement ARM Mali DP500/DP550/DP650 replacing PL111/HDLCD.
> >
> > Only "Layer Graphics" of the ARM Mali DP is configured for rendering
> > the RGB/BGR format frame buffer to satisfy the UEFI GOP requirements
> > Other layers e.g. video layers are not configured.
> >
> > NOTE: This change implements the Mali DP on models. Versions for actual
> > hardware are liable to require extra handling for clock input changes,
> > etc.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Girish Pathak 
> > Signed-off-by: Evan Lloyd 
>
> Hello Girish, Evan,
>
> (replying to 19/19 because I cannot find the cover letter in my
> edk2-devel archive but this really applies to the whole series)
>
> I have been looking at these patches again now that I am trying to
> clean up ArmPlatformPkg, which is currently a dumping ground for all
> things vaguely ARM related, and is also structured quite differently
> from other packages.
>
> Ideally, ArmPlatformPkg should only contain the following:
> - library class interfaces under Include/Library; header files kept
> here should only contain elements that define API
> - driver specific include files Include/IndustryStandard but *only* if
> they cannot be kept locally with the driver in question
> - libraries under Library/
> - drivers under Drivers/
>
> This aligns with the common arrangement adopted by most EDK2 packages.
>
> This series does many different things, and does not distinguish at
> all between common code and code living under ArmVExpressPkg. Given

 [[Evan Lloyd]] All of the commits in the series are in ArmPlatformPkg.
You may be in the process of disentangling the VE specific bits, but hitherto 
that has not been a consideration.  (Note: I'm not arguing against the 
disentangling, only pointing out that it was not a factor at the point we 
submitted the patches)
The reason there are so many commits is only that we have been asked to break 
things up into "bite sized" chunks for the convenience of maintainers.
The aim was to make each a coherent item with a simple justification.

> that I am trying to move ArmVExpressPkg out of EDK2 into
> edk2-platforms (where it arguably belongs) having this series in limbo
> for two months is basically blocking my work, and so I would like to
> explore ways to proceed with this without interfering with each
> other's work too much. At the same time, the way the code is
> structured is a continuation of the pattern I am trying to get rid of,
> so they will need some rework anyway in order to be upstreamable IMHO.

 [[Evan Lloyd]] Not being psychic, we had not made allowance for your plans.
However, if you take the trouble to look at the changes, they achieve exactly 
the split you aim for.
The display type code (PL011 and HDLCD) is unravelled from the VE code.
All that remains would be to move the VE specific part into edk2-platforms.

>
> So could we split it up please? Assuming the intention is the ability
> to reuse the Mali code on non-VExpress platforms, I would like to see
> that code proposed separately, without any mention of VExpressPkg.dec

 [[Evan Lloyd]] Given that the original code was unfortunate, I'm not sure that 
it makes much difference what order the changes get made.
Going West then North gets you to the same place as North then West  (except 
near a pole).
If you accept that there was a logical progression in the changes made, then it 
might be better to not rejig things pointlessly.

> whatsoever. If you introduce any library classes that abstract away
> the differences between platforms, you can include a Null version of
> such a library that simply does ASSERT (FALSE) in every function: this

 [[Evan Lloyd]] One could, indeed, do that.  We, however, would be very 
reluctant to incur the overhead of rework in response to spurious cavils from a 
maintainer when it is of no direct relevance to us.

> allows the driver to be built standalone, and at the same time, forces
> you to keep the abstractions pure. I intend to create a separate
> ArmPlatformPkg.dsc platform description for CI purposes that covers
> all drivers and libraries 

Re: [edk2] [platforms: PATCH 4/4] Marvell/Drivers: MvPhyDxe: Cleanup the header

2017-12-01 Thread Leif Lindholm
On Fri, Dec 01, 2017 at 03:28:54AM +0100, Marcin Wojtas wrote:
> This patch removes unused macros defined in MvPhyDxe.h, as well
> as improves the style and comments.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.c |   2 +-
>  Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.h | 152 
> 
>  2 files changed, 31 insertions(+), 123 deletions(-)
> 
> diff --git a/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.c 
> b/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.c
> index e776a91..203dce2 100644
> --- a/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.c
> +++ b/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.c
> @@ -201,7 +201,7 @@ MvPhyParseStatus (
>  
>  DEBUG((DEBUG_ERROR,"MvPhyDxe: Waiting for PHY realtime link"));
>  while (!(Data & MIIM_88E1xxx_PHYSTAT_SPDDONE)) {
> -  if (i > PHY_AUTONEGOTIATE_TIMEOUT) {
> +  if (i > PHY_ANEG_TIMEOUT) {

I'm down with the cleanup, but this change is not needed, and ANEG
most certainly isn't an approved abbreviation. Please leave it as is.

>  DEBUG((DEBUG_ERROR," TIMEOUT !\n"));
>  PhyDev->LinkUp = FALSE;
>  break;
> diff --git a/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.h 
> b/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.h
> index 0c3d935..3cfcb80 100644
> --- a/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.h
> +++ b/Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.h
> @@ -34,137 +34,45 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
> DAMAGE.
>  #ifndef __MV_PHY_DXE_H__
>  #define __MV_PHY_DXE_H__
>  
> -#define MII_BMCR  0x00  /* Basic mode control Register */
> -#define MII_BMSR  0x01  /* Basic mode status Register  */
> -#define MII_PHYSID1  0x02  /* PHYS ID 1   */
> -#define MII_PHYSID2  0x03  /* PHYS ID 2   */
> -#define MII_ADVERTISE  0x04  /* Advertisement control Reg   */
> -#define MII_LPA0x05  /* Link partner ability Reg*/
> -#define MII_EXPANSION  0x06  /* Expansion Register */
> -#define MII_CTRL1000  0x09  /* 1000BASE-T control */
> -#define MII_STAT1000  0x0a  /* 1000BASE-T status */
> -#define MII_ESTATUS  0x0f  /* Extended Status */
> -#define MII_DCOUNTER  0x12  /* Disconnect counter */
> -#define MII_FCSCOUNTER  0x13  /* False carrier counter   */
> -#define MII_NWAYTEST  0x14  /* N-way auto-neg test Reg */
> -#define MII_RERRCOUNTER 0x15  /* Receive error counter   */
> -#define MII_SREVISION  0x16  /* Silicon revision */
> -#define MII_RESV1  0x17  /* Reserved...   */
> -#define MII_LBRERROR  0x18  /* Lpback, rx, bypass error*/
> -#define MII_PHYADDR  0x19  /* PHY address   */
> -#define MII_RESV2  0x1a  /* Reserved...   */
> -#define MII_TPISTATUS  0x1b  /* TPI status for 10mbps   */
> -#define MII_NCONFIG  0x1c  /* Network interface config*/
> -
> -/* Basic mode control Register. */
> -#define BMCR_RESV0x003f  /* Unused...   */
> -#define BMCR_SPEED10000x0040  /* MSB of Speed (1000) */
> -#define BMCR_CTST0x0080  /* Collision test */
> -#define BMCR_FULLDPLX0x0100  /* Full duplex   */
> -#define BMCR_ANRESTART0x0200  /* Auto negotiation restart*/
> -#define BMCR_ISOLATE0x0400  /* Disconnect DP83840 from MII */
> -#define BMCR_PDOWN0x0800  /* Powerdown the DP83840   */
> -#define BMCR_ANENABLE0x1000  /* Enable auto negotiation */
> -#define BMCR_SPEED1000x2000  /* Select 100Mbps */
> -#define BMCR_LOOPBACK0x4000  /* TXD loopback bits */
> -#define BMCR_RESET0x8000  /* Reset the DP83840 */
> -
> -/* Basic mode status Register. */
> -#define BMSR_ERCAP0x0001  /* Ext-Reg capability */
> -#define BMSR_JCD0x0002  /* Jabber detected */
> -#define BMSR_LSTATUS0x0004  /* Link status   */
> -#define BMSR_ANEGCAPABLE  0x0008  /* Able to do auto-negotiation */
> -#define BMSR_RFAULT0x0010  /* Remote fault detected   */
> -#define BMSR_ANEGCOMPLETE  0x0020  /* Auto-negotiation complete   */
> -#define BMSR_RESV0x00c0  /* Unused...   */
> -#define BMSR_ESTATEN0x0100  /* Extended Status in R15 */
> -#define BMSR_100HALF20x0200  /* Can do 100BASE-T2 HDX */
> -#define BMSR_100FULL20x0400  /* Can do 100BASE-T2 FDX */
> -#define BMSR_10HALF0x0800  /* Can do 10mbps, half-duplex  */
> -#define BMSR_10FULL0x1000  /* Can do 10mbps, full-duplex  */
> -#define BMSR_100HALF0x2000  /* Can do 100mbps, half-duplex */
> -#define BMSR_100FULL0x4000  /* Can do 100mbps, full-duplex */
> -#define BMSR_100BASE40x8000  /* Can do 100mbps, 4k packets  */
> -
> -#define PHY_ANEG_TIMEOUT 4000
> -
> -#define PHY_INTERFACE_MODE_RGMII 0
> -#define 

Re: [edk2] [platforms: PATCH 1/4] Marvell/Armada: Switch to dynamic tftp command

2017-12-01 Thread Leif Lindholm
On Fri, Dec 01, 2017 at 03:28:51AM +0100, Marcin Wojtas wrote:
> After removal of the tftp library in EDK2, the tftp was
> disabled on Armada platform. Re-enable this functionality
> as a dynamic command.

I did request this to be re-added as a build-time selectable option
like it is done on the Hisilicon platforms.

Including non-standard shell commands by default does not make sense
to me.

/
Leif

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Armada/Armada.dsc.inc | 1 +
>  Platform/Marvell/Armada/Armada70x0.fdf | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
> b/Platform/Marvell/Armada/Armada.dsc.inc
> index 2a8a226..1b68ef3 100644
> --- a/Platform/Marvell/Armada/Armada.dsc.inc
> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
> @@ -524,6 +524,7 @@
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
>gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
>}
> +  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
>  
>  
> [BuildOptions.common.EDKII.DXE_CORE,BuildOptions.common.EDKII.DXE_DRIVER,BuildOptions.common.EDKII.UEFI_DRIVER,BuildOptions.common.EDKII.UEFI_APPLICATION]
>GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
> b/Platform/Marvell/Armada/Armada70x0.fdf
> index ca92c60..65c6474 100644
> --- a/Platform/Marvell/Armada/Armada70x0.fdf
> +++ b/Platform/Marvell/Armada/Armada70x0.fdf
> @@ -176,6 +176,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
>  
># UEFI application (Shell Embedded Boot Loader)
>INF ShellPkg/Application/Shell/Shell.inf
> +  INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
>  
># Bds
>INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> -- 
> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms] Silicon/Fip006Dxe: map NOR_FLASH_INFO FSR flag with instance flag

2017-12-01 Thread Leif Lindholm
On Thu, Nov 30, 2017 at 06:58:28PM +, Ard Biesheuvel wrote:
> From: Pipat Methavanitpong 
> 
> Now that we incorporated NorFlashInfoLib into the Fip006Dxe driver,
> replace the code that explicitly enables flag status register polling
> for Micron NOR flash with a test of the flags field provided by
> NorFlashInfoLib, which carries the same information.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pipat Methavanitpong 
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
>  Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/NorFlashDxe.c | 22 
> +++-
>  1 file changed, 8 insertions(+), 14 deletions(-)
> 
> diff --git a/Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/NorFlashDxe.c 
> b/Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/NorFlashDxe.c
> index a521b1f3d167..8d6bca8739d0 100644
> --- a/Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/NorFlashDxe.c
> +++ b/Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/NorFlashDxe.c
> @@ -1129,6 +1129,7 @@ NorFlashCreateInstance (
>  {
>EFI_STATUS Status;
>NOR_FLASH_INSTANCE* Instance;
> +  NOR_FLASH_INFO *FlashInfo;
>UINT8 JedecId[3];
>  
>ASSERT(NorFlashInstance != NULL);
> @@ -1157,23 +1158,15 @@ NorFlashCreateInstance (
>NorFlashReset (Instance);
>  
>NorFlashReadID (Instance, JedecId);
> +  Status = NorFlashGetInfo (JedecId, , FALSE);
> +  if (EFI_ERROR (Status)) {
> +goto FreeInstance;
> +  }
>  
> -  DEBUG_CODE_BEGIN ();
> -{
> -  NOR_FLASH_INFO*FlashInfo;
> -
> -  Status = NorFlashGetInfo (JedecId, , FALSE);
> -  if (EFI_ERROR (Status)) {
> -goto FreeInstance;
> -  }
> -
> -  NorFlashPrintInfo (FlashInfo);
> -  FreePool (FlashInfo);
> -}
> -  DEBUG_CODE_END ();
> +  NorFlashPrintInfo (FlashInfo);
>  
>Instance->Flags = 0;
> -  if (JedecId[0] == NOR_FLASH_ID_STMICRO) {
> +  if (FlashInfo->Flags & NOR_FLASH_WRITE_FSR) {
>  Instance->Flags = NOR_FLASH_POLL_FSR;
>}
>  
> @@ -1198,6 +1191,7 @@ NorFlashCreateInstance (
>}
>  
>*NorFlashInstance = Instance;
> +  FreePool (FlashInfo);
>return EFI_SUCCESS;
>  
>  FreeInstance:
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms v2] Silicon/SynQuacer: enable coherent DMA for NETSEC and eMMC

2017-12-01 Thread Leif Lindholm
On Thu, Nov 30, 2017 at 06:53:55PM +, Ard Biesheuvel wrote:
> As it turns out, it is surprisingly easy to configure both the NETSEC
> and eMMC devices as cache coherent for DMA, given that they are both
> behind the same SMMU which is already configured in passthrough mode
> by the firmware running on the SCP.
> 
> So update the static SMMU configuration to make memory accesses performed
> by these devices inner shareable inner/outer writeback cacheable, which
> makes them cache coherent with the CPUs.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Looks fine to me:
Reviewed-by: Leif Lindholm 
(If you want to hold back for Tested-by:s, feel free to.)

> ---
> v2: update DeveloperBox as well
> update commit log to clarify that the SMMU is configured in pass through
> mode by the firmware running on the Cortex-M3 SCP
> 
>  Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
>  |  2 +-
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
>  |  2 +-
>  Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
>  |  2 ++
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Emmc.c   
>  |  2 +-
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
>  | 23 
>  Silicon/Socionext/SynQuacer/Include/Platform/MemoryMap.h 
>  |  4 
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerMemoryInitPeiLib/SynQuacerMemoryInitPeiLib.c
>  |  3 +++
>  7 files changed, 35 insertions(+), 3 deletions(-)
> 
> diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
> b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> index 7ca9fb104311..e1183b529b73 100644
> --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> @@ -600,7 +600,7 @@ [Components.common]
>NetworkPkg/HttpBootDxe/HttpBootDxe.inf
>Silicon/Socionext/SynQuacer/Drivers/Net/NetsecDxe/NetsecDxe.inf {
>  
> -  DmaLib|EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.inf
> +  DmaLib|EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.inf
>}
>  
>#
> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> index 10da45ad2837..637f6d414d24 100644
> --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> @@ -592,7 +592,7 @@ [Components.common]
>NetworkPkg/HttpBootDxe/HttpBootDxe.inf
>Silicon/Socionext/SynQuacer/Drivers/Net/NetsecDxe/NetsecDxe.inf {
>  
> -  DmaLib|EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.inf
> +  DmaLib|EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.inf
>}
>  
>#
> diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi 
> b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
> index 5e663c59efbd..ec784c70afe7 100644
> --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
> +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
> @@ -456,6 +456,7 @@
>  max-speed = <1000>;
>  max-frame-size = <9000>;
>  phy-handle = <>;
> +dma-coherent;
>  
>  #address-cells = <1>;
>  #size-cells = <0>;
> @@ -557,6 +558,7 @@
>  fujitsu,cmd-dat-delay-select;
>  clocks = <_alw_c_0 _alw_b_0>;
>  clock-names = "core", "iface";
> +dma-coherent;
>  status = "disabled";
>  };
>  };
> diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Emmc.c 
> b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Emmc.c
> index e577076ada4f..5a99283977fb 100644
> --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Emmc.c
> +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Emmc.c
> @@ -191,7 +191,7 @@ RegisterEmmc (
>  
>Status = RegisterNonDiscoverableMmioDevice (
>   NonDiscoverableDeviceTypeSdhci,
> - NonDiscoverableDeviceDmaTypeNonCoherent,
> + NonDiscoverableDeviceDmaTypeCoherent,
>   NULL,
>   ,
>   1,
> diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c 
> b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
> index c64ccf3b3c30..7e7c790a6113 100644
> --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
> +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
> @@ -123,6 +123,27 @@ FreeDevice:
>return Status;
>  }
>  
> +#define SMMU_SCR0 0x0
> +#define SMMU_SCR0_SHCFG_INNER (0x2 << 22)
> +#define SMMU_SCR0_MTCFG   (0x1 << 20)
> +#define SMMU_SCR0_MEMATTR_INNER_OUTER_WB  (0xf << 16)
> +
> +STATIC
> +VOID
> 

Re: [edk2] edk2 interface deprecation policy

2017-12-01 Thread Laszlo Ersek
On 12/01/17 03:27, Ni, Ruiyu wrote:
> I prefer to remove all deprecated items because I like clean:)
> But then lots of customer complains may come.
> 
> So just provide my thoughts:
> Deprecated items can be separated into:
> 
> 1. Definitions: E.g.: UgaDraw protocol, DriverConfiguration2 protocol
> Keep:
> But harm the newbie developers because they don't know which 
> interfaces should depend on.
> Remove:
> A pure world.
> But easy to cause build break. Yet easy to fix by downloading the 
> definitions from old revision.
> Proposal:
> Move all deprecated definitions to a DeprecatePkg/OldPkg. 
> 
> 2. Modules. E.g.: IntelFrameworkModulePkg/Universal/BdsDxe, 
> IntelFrameworkModulePkg/Bus/Isa/*
>  Keep:
>  Increase feature owner's maintain effort.
>  Cause confusing because new features won't be enabled in deprecated 
> modules.
>  Remove:
>   A pure world.
>   But easy to cause build break. Yet easy to fix by downloading the 
> definitions from old revision.
> Proposal:
>  Keep it if in IntelFramework[Module]Pkg because in future the two 
> pkgs will be deprecated.
>  Move it to DeprecatePkg/OldPkg if in Mde[Module]Pkg
> 
> 3. Libraries: E.g.: 
> IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode
>   Same as #2.
> 
> So how about we create another GIT repo and store the DeprecatePkg/OldPkg.
> Old consumers can download old stuffs from the other GIT repo.
> Eventually the IntelFramework[Module]Pkg can be moved to that repo as well.

I really like the DeprecatedPkg idea, but I think the package should
live in the *same* edk2 repository. Similarly to EdkCompatibilityPkg.

The benefit is that deprecation can occur gradually, and it all will be
part of one common git history.

(I don't feel strongly about this topic, I just thought I'd comment on
the "separate git repo" part -- I think there's value in keeping
DeprecatedPkg in edk2.)

Thanks
Laszlo


>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao,
>> Liming
>> Sent: Friday, December 1, 2017 9:51 AM
>> To: Felix Poludov ; af...@apple.com
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] edk2 interface deprecation policy
>>
>> Felix:
>>   I agree to define the tag to specify the deprecated definition, library 
>> and drivers.
>> If so, user can easily know which one is not used any more. But, I think we 
>> can
>> still keep them in edk2 project, because they have no negative impact.
>>
>> Thanks
>> Liming
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>> Felix Poludov
>>> Sent: Friday, December 01, 2017 6:12 AM
>>> To: af...@apple.com
>>> Cc: edk2-devel@lists.01.org
>>> Subject: Re: [edk2] edk2 interface deprecation policy
>>>
>>> I agree. It would be beneficial to have a mailing list discussion on
>>> how to deal with the deprecated item.
>>> In some cases it would make sense to tag an interface as deprecated,
>>> but keep in the code base for a while (6 month?) before actually deleting 
>>> it.
>>>
>>> -Original Message-
>>> From: af...@apple.com [mailto:af...@apple.com]
>>> Sent: Thursday, November 30, 2017 11:57 AM
>>> To: Felix Poludov
>>> Cc: edk2-devel@lists.01.org
>>> Subject: Re: [edk2] edk2 interface deprecation policy
>>>
>>> Felix,
>>>
>>> I don't think we have one
>>>
>>> Adding new interfaces does not impact the downstream projects, but
>>> depreciating interface can break stuff. Seems like it might at least be
>>> a good idea to have a depreciation discussion on the mailing  list. I'm
>>> open to other suggestions
>>>
>>> Thanks,
>>>
>>> Andrew Fish
>>>
 On Nov 30, 2017, at 6:00 AM, Felix Poludov  wrote:

 Does edk2 have a policy regarding deprecation of interface definition
>>> headers?
 I can see that definition of the UgaDraw protocol that was deprecated
 years
>>> ago (I believe in UEFI 2.0) is still part of the code base; yet,
>>> definition of the SMM Communication ACPI Table that was deprecated this
>>> year in UEFI 2.6B has already been removed.

 Please consider the environment before printing this email.

 The information contained in this message may be confidential and
>>> proprietary to American Megatrends, Inc.  This communication is
>>> intended to be read only by the individual or entity to whom it is
>>> addressed or by their designee. If the reader of this message is not
>>> the intended recipient, you are on notice that any distribution of this
>>> message, in any form, is strictly prohibited.  Please promptly notify
>>> the sender by reply e-mail or by telephone at 770-246-8600, and then delete 
>>> or
>> destroy all copies of the transmission.
 ___
 edk2-devel mailing list
 edk2-devel@lists.01.org
 

Re: [edk2] [Patch 0/2] Check Media status before starting DHCP process.

2017-12-01 Thread Laszlo Ersek
Hi Jiaxin,

On 12/01/17 09:38, Jiaxin Wu wrote:
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Karunakar P 
> Signed-off-by: Wu Jiaxin 
> 
> Jiaxin Wu (2):
>   MdeModulePkg/Dhcp4Dxe: Check Media status before starting DHCP
> process.
>   NetworkPkg/Dhcp6Dxe: Check Media status before starting DHCP process.
> 
>  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c | 13 -
>  NetworkPkg/Dhcp6Dxe/Dhcp6Impl.c | 14 +-
>  2 files changed, 25 insertions(+), 2 deletions(-)
> 

I assume this is to address
. If that's the
case, can you please add the BZ reference to the commit messages?

(No need to repost just because of this.)

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


Re: [edk2] [PATCH v2 3/8] OvmfPkg: conditionally disable reserved memory varstore emulation at build

2017-12-01 Thread Laszlo Ersek
On 12/01/17 11:53, Ard Biesheuvel wrote:
> On 1 December 2017 at 10:52, Laszlo Ersek  wrote:
>> On 12/01/17 09:51, Ard Biesheuvel wrote:
>>> On 30 November 2017 at 16:30, Laszlo Ersek  wrote:
 (All of the below is only relevant for SMM_REQUIRE=FALSE.)

 For the emulated variable store, PlatformPei allocates reserved memory (as
 early as possible, so that the address remains the same during reboot),
 and PcdEmuVariableNvStoreReserved carries the address to
 EmuVariableFvbRuntimeDxe.

 In addition, QemuFlashFvbServicesRuntimeDxe is always launched before
 EmuVariableFvbRuntimeDxe, so that if flash variables are available,
 QemuFlashFvbServicesRuntimeDxe can set PcdFlashNvStorageVariableBase64
 first, and EmuVariableFvbRuntimeDxe can exit early. This ordering is
 currently enforced by adding QemuFlashFvbServicesRuntimeDxe to the APRIORI
 DXE file.

 All of this is unnecessary when MEM_VARSTORE_EMU_ENABLE is set to FALSE.
 In such a build,

 - (almost) remove the dynamic default for PcdEmuVariableNvStoreReserved
   (we can't really do this because the PcdSet64() in
   ReserveEmuVariableNvStore() wouldn't compile),

>>>
>>> If that is the only concern, and the value is irrelevant, you could
>>> make it a patchable PCD instead
>>
>> This sounds interesting; I've never used patchable PCDs. Can you please
>> elaborate?
>>
>> Do you mean that for (SMM_REQUIRE==TRUE ||
>> MEM_VARSTORE_EMU_ENABLE==FALSE), the DSC file should list
>> PcdEmuVariableNvStoreReserved somewhere else?
>>
> 
> Yes.
> 
>> Does PcdSet work on patchable PCDs?
>>
> 
> Yes. It's a bit icky because the value does not actually propagate to
> other modules, but that doesn't matter in this case.

Hm, this sounds like a recipe. We have two sets of affected PCDs:

- PcdEmuVariableNvStoreReserved --> in the "flash required" builds, make
it patchable, don't bother setting a good value at build time, and the
PcdSet calls will compile (but won't ever be reached due to code logic)

- PcdFlashNvStorageVariableBase64, PcdFlashNvStorageFtwWorkingBase,
PcdFlashNvStorageFtwSpareBase: in the "flash required" builds, make them
patchable, *try* to set the right default values at build time, with SET
commands, and the PcdSet calls will compile (but won't ever be reached
due to code logic)

That could let us drop FlashNvStorageAddressLib. (On patch #6, only the
commit message would change.)

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


[edk2] [PATCH edk2-platforms 3/5] Platform/ARM: import HcdLcd glue library for VExpress

2017-12-01 Thread Ard Biesheuvel
Create a new LcdPlatformLib implementation for HdLcd on VExpress, based
on the existing code that lives in ArmPlatformPkg.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c  | 
285 
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf | 
 43 +++
 2 files changed, 328 insertions(+)

diff --git 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
new file mode 100644
index ..b1106ee19b98
--- /dev/null
+++ b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
@@ -0,0 +1,285 @@
+/**
+
+  Copyright (c) 2012, ARM Ltd. All rights reserved.
+
+  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 
+
+typedef struct {
+  UINT32 Mode;
+  UINT32 HorizontalResolution;
+  UINT32 VerticalResolution;
+  LCD_BPPBpp;
+  UINT32 OscFreq;
+
+  // These are used by HDLCD
+  UINT32 HSync;
+  UINT32 HBackPorch;
+  UINT32 HFrontPorch;
+  UINT32 VSync;
+  UINT32 VBackPorch;
+  UINT32 VFrontPorch;
+} LCD_RESOLUTION;
+
+
+LCD_RESOLUTION mResolutions[] = {
+  { // Mode 0 : VGA : 640 x 480 x 24 bpp
+VGA, VGA_H_RES_PIXELS, VGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
VGA_OSC_FREQUENCY,
+VGA_H_SYNC, VGA_H_BACK_PORCH, VGA_H_FRONT_PORCH,
+VGA_V_SYNC, VGA_V_BACK_PORCH, VGA_V_FRONT_PORCH
+  },
+  { // Mode 1 : SVGA : 800 x 600 x 24 bpp
+SVGA, SVGA_H_RES_PIXELS, SVGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
SVGA_OSC_FREQUENCY,
+SVGA_H_SYNC, SVGA_H_BACK_PORCH, SVGA_H_FRONT_PORCH,
+SVGA_V_SYNC, SVGA_V_BACK_PORCH, SVGA_V_FRONT_PORCH
+  },
+  { // Mode 2 : XGA : 1024 x 768 x 24 bpp
+XGA, XGA_H_RES_PIXELS, XGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
XGA_OSC_FREQUENCY,
+XGA_H_SYNC, XGA_H_BACK_PORCH, XGA_H_FRONT_PORCH,
+XGA_V_SYNC, XGA_V_BACK_PORCH, XGA_V_FRONT_PORCH
+  },
+  { // Mode 3 : SXGA : 1280 x 1024 x 24 bpp
+SXGA, SXGA_H_RES_PIXELS, SXGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
(SXGA_OSC_FREQUENCY/2),
+SXGA_H_SYNC, SXGA_H_BACK_PORCH, SXGA_H_FRONT_PORCH,
+SXGA_V_SYNC, SXGA_V_BACK_PORCH, SXGA_V_FRONT_PORCH
+  },
+  { // Mode 4 : UXGA : 1600 x 1200 x 24 bpp
+UXGA, UXGA_H_RES_PIXELS, UXGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
(UXGA_OSC_FREQUENCY/2),
+UXGA_H_SYNC, UXGA_H_BACK_PORCH, UXGA_H_FRONT_PORCH,
+UXGA_V_SYNC, UXGA_V_BACK_PORCH, UXGA_V_FRONT_PORCH
+  },
+  { // Mode 5 : HD : 1920 x 1080 x 24 bpp
+HD, HD_H_RES_PIXELS, HD_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
(HD_OSC_FREQUENCY/2),
+HD_H_SYNC, HD_H_BACK_PORCH, HD_H_FRONT_PORCH,
+HD_V_SYNC, HD_V_BACK_PORCH, HD_V_FRONT_PORCH
+  }
+};
+
+EFI_EDID_DISCOVERED_PROTOCOL  mEdidDiscovered = {
+  0,
+  NULL
+};
+
+EFI_EDID_ACTIVE_PROTOCOL  mEdidActive = {
+  0,
+  NULL
+};
+
+EFI_STATUS
+LcdPlatformInitializeDisplay (
+  IN EFI_HANDLE   Handle
+  )
+{
+  EFI_STATUS  Status;
+
+  // Set the FPGA multiplexer to select the video output from the motherboard 
or the daughterboard
+  Status = ArmPlatformSysConfigSet (SYS_CFG_MUXFPGA, 
ARM_VE_DAUGHTERBOARD_1_SITE);
+  if (EFI_ERROR(Status)) {
+return Status;
+  }
+
+  // Install the EDID Protocols
+  Status = gBS->InstallMultipleProtocolInterfaces (
+,
+,  ,
+,  ,
+NULL
+  );
+
+  return Status;
+}
+
+EFI_STATUS
+LcdPlatformGetVram (
+  OUT EFI_PHYSICAL_ADDRESS*  VramBaseAddress,
+  OUT UINTN* VramSize
+  )
+{
+  EFI_STATUS  Status;
+  EFI_ALLOCATE_TYPE   AllocationType;
+
+  // Set the vram size
+  *VramSize = LCD_VRAM_SIZE;
+
+  *VramBaseAddress = (EFI_PHYSICAL_ADDRESS)LCD_VRAM_CORE_TILE_BASE;
+
+  // Allocate the VRAM from the DRAM so that nobody else uses it.
+  if (*VramBaseAddress == 0) {
+AllocationType = AllocateAnyPages;
+  } else {
+AllocationType = AllocateAddress;
+  }
+  Status = gBS->AllocatePages (AllocationType, EfiBootServicesData, 
EFI_SIZE_TO_PAGES(((UINTN)LCD_VRAM_SIZE)), VramBaseAddress);
+  if (EFI_ERROR(Status)) {
+return Status;
+  }
+
+  // Mark the VRAM as write-combining. The VRAM is inside the DRAM, which is 
cacheable.
+  Status = gDS->SetMemorySpaceAttributes 

[edk2] [PATCH edk2-platforms 5/5] Platform/ARM: move TC2 to the new LcdGraphicsOutputDxe driver

2017-12-01 Thread Ard Biesheuvel
Update the TC2 .dsc and .fdf files to switch over to the refactored
LCD graphics output driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc | 8 
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf | 3 +--
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
index 98513b282fa7..c7307c741b64 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
@@ -50,7 +50,8 @@ [LibraryClasses.common]
   # ARM General Interrupt Driver in Secure and Non-secure
   ArmGicLib|ArmPkg/Drivers/ArmGic/ArmGicLib.inf
 
-  
LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
+  LcdHwLib|ArmPlatformPkg/Library/HdLcd/HdLcd.inf
+  
LcdPlatformLib|Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
 
   ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
 
@@ -158,7 +159,7 @@ [PcdsFixedAtBuild.common]
   ## PL111 Lcd & HdLcd
   gArmPlatformTokenSpaceGuid.PcdPL111LcdBase|0x1C1F
   gArmPlatformTokenSpaceGuid.PcdArmHdLcdBase|0x2B00
-  gArmVExpressTokenSpaceGuid.PcdHdLcdVideoModeOscId|5
+  gVExpressTokenSpaceGuid.PcdHdLcdVideoModeOscId|5
 !endif
 
   #
@@ -245,8 +246,7 @@ [Components.common]
 
   ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
-  #ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111LcdGraphicsOutputDxe.inf
-  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/HdLcdGraphicsOutputDxe.inf
+  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf
   ArmPkg/Drivers/TimerDxe/TimerDxe.inf
   ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf
 
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf 
b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf
index 3c75a51570b8..32d04e7c86fe 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf
@@ -97,8 +97,7 @@ [FV.FvMain]
   INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
   INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
-  #INF 
ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111LcdGraphicsOutputDxe.inf
-  INF ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/HdLcdGraphicsOutputDxe.inf
+  INF ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf
   INF ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf
 
   #
-- 
2.11.0

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


[edk2] [PATCH edk2-platforms 2/5] Platform/ARM: import PL111 glue library for VExpress

2017-12-01 Thread Ard Biesheuvel
Create a new LcdPlatformLib implementation for PL111 on VExpress, based
on the existing code that lives in ArmPlatformPkg.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/VExpressPkg/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c  | 
370 
 Platform/ARM/VExpressPkg/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf |  
44 +++
 2 files changed, 414 insertions(+)

diff --git 
a/Platform/ARM/VExpressPkg/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c 
b/Platform/ARM/VExpressPkg/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
new file mode 100644
index ..3f3ceb3d2fa8
--- /dev/null
+++ b/Platform/ARM/VExpressPkg/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
@@ -0,0 +1,370 @@
+/** @file
+
+  Copyright (c) 2011-2015, ARM Ltd. All rights reserved.
+  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 
+
+typedef struct {
+  UINT32 Mode;
+  UINT32 HorizontalResolution;
+  UINT32 VerticalResolution;
+  LCD_BPPBpp;
+  UINT32 OscFreq;
+
+  UINT32 HSync;
+  UINT32 HBackPorch;
+  UINT32 HFrontPorch;
+  UINT32 VSync;
+  UINT32 VBackPorch;
+  UINT32 VFrontPorch;
+} LCD_RESOLUTION;
+
+
+LCD_RESOLUTION mResolutions[] = {
+  { // Mode 0 : VGA : 640 x 480 x 24 bpp
+  VGA, VGA_H_RES_PIXELS, VGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
VGA_OSC_FREQUENCY,
+  VGA_H_SYNC, VGA_H_BACK_PORCH, VGA_H_FRONT_PORCH,
+  VGA_V_SYNC, VGA_V_BACK_PORCH, VGA_V_FRONT_PORCH
+  },
+  { // Mode 1 : SVGA : 800 x 600 x 24 bpp
+  SVGA, SVGA_H_RES_PIXELS, SVGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
SVGA_OSC_FREQUENCY,
+  SVGA_H_SYNC, SVGA_H_BACK_PORCH, SVGA_H_FRONT_PORCH,
+  SVGA_V_SYNC, SVGA_V_BACK_PORCH, SVGA_V_FRONT_PORCH
+  },
+  { // Mode 2 : XGA : 1024 x 768 x 24 bpp
+  XGA, XGA_H_RES_PIXELS, XGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
XGA_OSC_FREQUENCY,
+  XGA_H_SYNC, XGA_H_BACK_PORCH, XGA_H_FRONT_PORCH,
+  XGA_V_SYNC, XGA_V_BACK_PORCH, XGA_V_FRONT_PORCH
+  },
+  { // Mode 3 : SXGA : 1280 x 1024 x 24 bpp
+  SXGA, SXGA_H_RES_PIXELS, SXGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
(SXGA_OSC_FREQUENCY/2),
+  SXGA_H_SYNC, SXGA_H_BACK_PORCH, SXGA_H_FRONT_PORCH,
+  SXGA_V_SYNC, SXGA_V_BACK_PORCH, SXGA_V_FRONT_PORCH
+  },
+  { // Mode 4 : UXGA : 1600 x 1200 x 24 bpp
+  UXGA, UXGA_H_RES_PIXELS, UXGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
(UXGA_OSC_FREQUENCY/2),
+  UXGA_H_SYNC, UXGA_H_BACK_PORCH, UXGA_H_FRONT_PORCH,
+  UXGA_V_SYNC, UXGA_V_BACK_PORCH, UXGA_V_FRONT_PORCH
+  },
+  { // Mode 5 : HD : 1920 x 1080 x 24 bpp
+  HD, HD_H_RES_PIXELS, HD_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
(HD_OSC_FREQUENCY/2),
+  HD_H_SYNC, HD_H_BACK_PORCH, HD_H_FRONT_PORCH,
+  HD_V_SYNC, HD_V_BACK_PORCH, HD_V_FRONT_PORCH
+  },
+  { // Mode 6 : VGA : 640 x 480 x 16 bpp (565 Mode)
+  VGA, VGA_H_RES_PIXELS, VGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_16_565, 
VGA_OSC_FREQUENCY,
+  VGA_H_SYNC, VGA_H_BACK_PORCH, VGA_H_FRONT_PORCH,
+  VGA_V_SYNC, VGA_V_BACK_PORCH, VGA_V_FRONT_PORCH
+  },
+  { // Mode 7 : SVGA : 800 x 600 x 16 bpp (565 Mode)
+  SVGA, SVGA_H_RES_PIXELS, SVGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_16_565, 
SVGA_OSC_FREQUENCY,
+  SVGA_H_SYNC, SVGA_H_BACK_PORCH, SVGA_H_FRONT_PORCH,
+  SVGA_V_SYNC, SVGA_V_BACK_PORCH, SVGA_V_FRONT_PORCH
+  },
+  { // Mode 8 : XGA : 1024 x 768 x 16 bpp (565 Mode)
+  XGA, XGA_H_RES_PIXELS, XGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_16_565, 
XGA_OSC_FREQUENCY,
+  XGA_H_SYNC, XGA_H_BACK_PORCH, XGA_H_FRONT_PORCH,
+  XGA_V_SYNC, XGA_V_BACK_PORCH, XGA_V_FRONT_PORCH
+  },
+  { // Mode 9 : VGA : 640 x 480 x 15 bpp
+  VGA, VGA_H_RES_PIXELS, VGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_16_555, 
VGA_OSC_FREQUENCY,
+  VGA_H_SYNC, VGA_H_BACK_PORCH, VGA_H_FRONT_PORCH,
+  VGA_V_SYNC, VGA_V_BACK_PORCH, VGA_V_FRONT_PORCH
+  },
+  { // Mode 10 : SVGA : 800 x 600 x 15 bpp
+  SVGA, SVGA_H_RES_PIXELS, SVGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_16_555, 
SVGA_OSC_FREQUENCY,
+  SVGA_H_SYNC, SVGA_H_BACK_PORCH, SVGA_H_FRONT_PORCH,
+  SVGA_V_SYNC, SVGA_V_BACK_PORCH, SVGA_V_FRONT_PORCH
+  },
+  { // Mode 11 : XGA : 1024 x 768 x 15 bpp
+  XGA, XGA_H_RES_PIXELS, XGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_16_555, 
XGA_OSC_FREQUENCY,
+  XGA_H_SYNC, 

[edk2] [PATCH edk2-platforms 4/5] Platform/ARM: move FVP to the new LcdGraphicsOutputDxe driver

2017-12-01 Thread Ard Biesheuvel
Update the FVP .dsc and .fdf files to switch over to the refactored LCD
graphics output driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 5 +++--
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf | 2 +-
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 5 +
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
index a04159bb9741..8b20371e1e15 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
@@ -47,7 +47,8 @@ [LibraryClasses.common]
   
ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
   
NorFlashPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
 !ifdef EDK2_ENABLE_PL111
-  
LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
+  LcdHwLib|ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.inf
+  
LcdPlatformLib|Platform/ARM/VExpressPkg/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 !endif
 
   # Virtio Support
@@ -273,7 +274,7 @@ [Components.common]
   ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
   ArmPkg/Drivers/TimerDxe/TimerDxe.inf
 !ifdef EDK2_ENABLE_PL111
-  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111LcdGraphicsOutputDxe.inf
+  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf
 !endif
   ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf
 
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf 
b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf
index 1084eda3d367..d95b66073978 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf
@@ -114,7 +114,7 @@ [FV.FvMain]
   INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
   INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
 !ifdef EDK2_ENABLE_PL111
-  INF ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111LcdGraphicsOutputDxe.inf
+  INF ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf
 !endif
   INF ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf
 
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
index 1d6cd79333ef..93a2451dafd6 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
@@ -82,10 +82,7 @@ [LibraryClasses.common]
   
ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
   
NorFlashPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
   
ResetSystemLib|ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
-!ifdef EDK2_ENABLE_PL111
-  # ARM PL111 Lcd Driver
-  
LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
-!endif
+
   # ARM PL031 RTC Driver
   
RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
   TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
-- 
2.11.0

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


[edk2] [PATCH edk2-platforms 1/5] Platform/ARM: add VExpressPkg .dec file base on EDK2's ArmPlatformPkg.dec

2017-12-01 Thread Ard Biesheuvel
In preparation of moving the VExpress specific LCD glue libraries into
edk2-platforms, create a new package file for VExpress and clone some of
the LCD related PCDs.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/VExpressPkg/ArmVExpressPkg.dec | 34 
 1 file changed, 34 insertions(+)

diff --git a/Platform/ARM/VExpressPkg/ArmVExpressPkg.dec 
b/Platform/ARM/VExpressPkg/ArmVExpressPkg.dec
new file mode 100644
index ..e0826befd36b
--- /dev/null
+++ b/Platform/ARM/VExpressPkg/ArmVExpressPkg.dec
@@ -0,0 +1,34 @@
+#/** @file
+# Arm Versatile Express package.
+#
+#  Copyright (c) 2012-2015, ARM Limited. All rights reserved.
+#
+#  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.
+#
+#**/
+
+[Defines]
+  DEC_SPECIFICATION  = 0x0001001B
+  PACKAGE_NAME   = VExpressPkg
+  PACKAGE_GUID   = 75e9d922-0e01-411c-8182-92c52fd79402
+  PACKAGE_VERSION= 0.1
+
+[Guids.common]
+  gVExpressTokenSpaceGuid=  { 0xc0778830, 0x8999, 0x4eee, { 0x84, 0xdf, 
0x93, 0x93, 0x6f, 0xbc, 0x0a, 0xad } }
+
+[PcdsFixedAtBuild.common]
+  #
+  # MaxMode must be one number higher than the actual max mode,
+  # i.e. for actual maximum mode 2, set the value to 3.
+  #
+  # For a list of mode numbers look in LcdArmVExpress.c
+  #
+  gVExpressTokenSpaceGuid.PcdPL111LcdMaxMode|3|UINT32|0x0001
+  gVExpressTokenSpaceGuid.PcdPL111LcdVideoModeOscId|1|UINT32|0x0002
+  gVExpressTokenSpaceGuid.PcdHdLcdVideoModeOscId|0|UINT32|0x0003
-- 
2.11.0

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


[edk2] [PATCH 0/5] ArmPlatformPkg: refactor LcdGraphicsOutputDxe driver

2017-12-01 Thread Ard Biesheuvel
This is a rework of the patch 'ArmPlatformPkg: Reorganize Lcd Graphics Output'
sent out by Evan on September 26 [0]

I have split it up for easier review, and droppped then changes to VExpress
specific libraries and instead, moved those into edk2-platforms. A separate
series is forthcoming. All patches of this series except the last one can
be merged before the edk2-platforms series.

The purpose is to separate the LCD output graphics driver from ARM VExpress
specific details, so that the core code can be reused more easily, and the
platform specific code moved out of the main EDK2 repository.

Cc: Girish Pathak 
Cc: Evan Lloyd 

[0] https://lists.01.org/pipermail/edk2-devel/2017-September/015337.html

Ard Biesheuvel (5):
  ArmPlatformPkg: introduce LcdhwLib library class
  ArmPlatformPkg: implement LcdHwLib for PL111
  ArmPlatformPkg: implement LcdHwLib for HdLcd
  ArmPlatformPkg: create hw-agnostic LcdGraphicsOutputDxe driver
  ArmPlatformPkg: remove old PL111/HdLcd driver code

 ArmPlatformPkg/ArmPlatformPkg.dec  
 |   1 +
 ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c   
 | 285 ---
 
ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
   |  45 ---
 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
  | 370 
 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 |  44 ---
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h 
 |  21 +-
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/{PL111LcdGraphicsOutputDxe.inf => 
LcdGraphicsOutputDxe.inf} |  33 +-
 ArmPlatformPkg/Include/Library/LcdHwLib.h  
 |  65 
 ArmPlatformPkg/{Drivers/LcdGraphicsOutputDxe => Library/HdLcd}/HdLcd.c 
 |  31 +-
 ArmPlatformPkg/{Include/Drivers => Library/HdLcd}/HdLcd.h  
 |   0
 ArmPlatformPkg/{Drivers/LcdGraphicsOutputDxe/HdLcdGraphicsOutputDxe.inf => 
Library/HdLcd/HdLcd.inf} |  33 +-
 ArmPlatformPkg/{Drivers/LcdGraphicsOutputDxe => Library/PL111Lcd}/PL111Lcd.c   
 |   8 +-
 ArmPlatformPkg/{Include/Drivers => Library/PL111Lcd}/PL111Lcd.h
 |   0
 ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.inf   
 |  40 +++
 14 files changed, 159 insertions(+), 817 deletions(-)
 delete mode 100644 
ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
 delete mode 100644 
ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
 delete mode 100644 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
 delete mode 100644 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 rename 
ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/{PL111LcdGraphicsOutputDxe.inf => 
LcdGraphicsOutputDxe.inf} (71%)
 create mode 100644 ArmPlatformPkg/Include/Library/LcdHwLib.h
 rename ArmPlatformPkg/{Drivers/LcdGraphicsOutputDxe => Library/HdLcd}/HdLcd.c 
(86%)
 rename ArmPlatformPkg/{Include/Drivers => Library/HdLcd}/HdLcd.h (100%)
 rename ArmPlatformPkg/{Drivers/LcdGraphicsOutputDxe/HdLcdGraphicsOutputDxe.inf 
=> Library/HdLcd/HdLcd.inf} (55%)
 rename ArmPlatformPkg/{Drivers/LcdGraphicsOutputDxe => 
Library/PL111Lcd}/PL111Lcd.c (93%)
 rename ArmPlatformPkg/{Include/Drivers => Library/PL111Lcd}/PL111Lcd.h (100%)
 create mode 100644 ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.inf

-- 
2.11.0

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


[edk2] [PATCH 4/5] ArmPlatformPkg: create hw-agnostic LcdGraphicsOutputDxe driver

2017-12-01 Thread Ard Biesheuvel
Create a new LcdGraphicsOutputDxe driver from the existing sources that
takes its hardware abstractions from a LcdHwLib library instance rather
than from a .c file linked directly. All we need is a new .inf file, and
a minimal tweak to LcdGraphicsOutputDxe.h to reuse the LcdHwlib prototypes
rather than open code them.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak 
Signed-off-by: Evan Lloyd 
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h   | 21 
+---
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf | 54 

 2 files changed, 55 insertions(+), 20 deletions(-)

diff --git a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h 
b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h
index 8856b79901b6..b66efd34561f 100644
--- a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h
+++ b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h
@@ -18,6 +18,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -105,24 +106,4 @@ InitializeDisplay (
   IN LCD_INSTANCE* Instance
 );
 
-EFI_STATUS
-LcdIdentify (
-  VOID
-);
-
-EFI_STATUS
-LcdInitialize (
-  EFI_PHYSICAL_ADDRESS  VramBaseAddress
-);
-
-EFI_STATUS
-LcdSetMode (
-  IN UINT32  ModeNumber
-);
-
-VOID
-LcdShutdown (
-  VOID
-);
-
 #endif /* __ARM_VE_GRAPHICS_DXE_H__ */
diff --git 
a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf 
b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf
new file mode 100644
index ..e6424475f79d
--- /dev/null
+++ b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf
@@ -0,0 +1,54 @@
+#/** @file
+#
+#  Component description file for LcdGraphicsOutputDxe module
+#
+#  Copyright (c) 2011-2012, ARM Ltd. All rights reserved.
+#
+#  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.
+#
+#**/
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = LcdGraphicsOutputDxe
+  FILE_GUID  = 89464DAE-8DAA-41FE-A4C8-40D2175AF1E9
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= LcdGraphicsOutputDxeInitialize
+
+[Sources.common]
+  LcdGraphicsOutputDxe.c
+  LcdGraphicsOutputBlt.c
+
+[Packages]
+  ArmPlatformPkg/ArmPlatformPkg.dec
+  ArmPkg/ArmPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  ArmLib
+  BaseLib
+  BaseMemoryLib
+  DebugLib
+  LcdHwLib
+  LcdPlatformLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+  UefiLib
+
+[Protocols]
+  gEfiDevicePathProtocolGuid
+  gEfiGraphicsOutputProtocolGuid
+
+[FeaturePcd]
+  gArmPlatformTokenSpaceGuid.PcdGopDisableOnExitBootServices
+
+[Depex]
+  TRUE
-- 
2.11.0

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


[edk2] [PATCH 3/5] ArmPlatformPkg: implement LcdHwLib for HdLcd

2017-12-01 Thread Ard Biesheuvel
Convert the HdLcd specific code of LcdGraphicsOutputDxe into a LcdHwlib
implementation that we will wire up later into LcdGraphicsOutputDxe.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak 
Signed-off-by: Evan Lloyd 
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Library/HdLcd/HdLcd.c   | 158 
 ArmPlatformPkg/Library/HdLcd/HdLcd.h   |  89 +++
 ArmPlatformPkg/Library/HdLcd/HdLcd.inf |  42 ++
 3 files changed, 289 insertions(+)

diff --git a/ArmPlatformPkg/Library/HdLcd/HdLcd.c 
b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
new file mode 100644
index ..24efb68f23e3
--- /dev/null
+++ b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
@@ -0,0 +1,158 @@
+/** @file  Lcd.c
+
+  Copyright (c) 2011-2012, ARM Ltd. All rights reserved.
+
+  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 "HdLcd.h"
+
+/**
+ *
+ *  This file contains all the bits of the Lcd that are
+ *  platform independent.
+ *
+ **/
+
+STATIC
+UINTN
+GetBytesPerPixel (
+  IN  LCD_BPP   Bpp
+  )
+{
+  switch(Bpp) {
+  case LCD_BITS_PER_PIXEL_24:
+return 4;
+
+  case LCD_BITS_PER_PIXEL_16_565:
+  case LCD_BITS_PER_PIXEL_16_555:
+  case LCD_BITS_PER_PIXEL_12_444:
+return 2;
+
+  case LCD_BITS_PER_PIXEL_8:
+  case LCD_BITS_PER_PIXEL_4:
+  case LCD_BITS_PER_PIXEL_2:
+  case LCD_BITS_PER_PIXEL_1:
+return 1;
+
+  default:
+return 0;
+  }
+}
+
+EFI_STATUS
+LcdInitialize (
+  IN EFI_PHYSICAL_ADDRESS   VramBaseAddress
+  )
+{
+  // Disable the controller
+  MmioWrite32(HDLCD_REG_COMMAND, HDLCD_DISABLE);
+
+  // Disable all interrupts
+  MmioWrite32(HDLCD_REG_INT_MASK, 0);
+
+  // Define start of the VRAM. This never changes for any graphics mode
+  MmioWrite32(HDLCD_REG_FB_BASE, (UINT32) VramBaseAddress);
+
+  // Setup various registers that never change
+  MmioWrite32(HDLCD_REG_BUS_OPTIONS,  (4 << 8) | HDLCD_BURST_8);
+  MmioWrite32(HDLCD_REG_POLARITIES,   HDLCD_PXCLK_LOW | HDLCD_DATA_HIGH | 
HDLCD_DATEN_HIGH | HDLCD_HSYNC_LOW | HDLCD_VSYNC_HIGH);
+  MmioWrite32(HDLCD_REG_PIXEL_FORMAT, HDLCD_LITTLE_ENDIAN | 
HDLCD_4BYTES_PER_PIXEL);
+  MmioWrite32(HDLCD_REG_RED_SELECT,   (0 << 16 | 8 << 8 |  0));
+  MmioWrite32(HDLCD_REG_GREEN_SELECT, (0 << 16 | 8 << 8 |  8));
+  MmioWrite32(HDLCD_REG_BLUE_SELECT,  (0 << 16 | 8 << 8 | 16));
+
+  return EFI_SUCCESS;
+}
+
+EFI_STATUS
+LcdSetMode (
+  IN UINT32  ModeNumber
+  )
+{
+  EFI_STATUSStatus;
+  UINT32HRes;
+  UINT32HSync;
+  UINT32HBackPorch;
+  UINT32HFrontPorch;
+  UINT32VRes;
+  UINT32VSync;
+  UINT32VBackPorch;
+  UINT32VFrontPorch;
+  UINT32BytesPerPixel;
+  LCD_BPP   LcdBpp;
+
+
+  // Set the video mode timings and other relevant information
+  Status = LcdPlatformGetTimings (ModeNumber,
+  
+  ,,,);
+  ASSERT_EFI_ERROR (Status);
+  if (EFI_ERROR( Status )) {
+return EFI_DEVICE_ERROR;
+  }
+
+  Status = LcdPlatformGetBpp (ModeNumber,);
+  ASSERT_EFI_ERROR (Status);
+  if (EFI_ERROR( Status )) {
+return EFI_DEVICE_ERROR;
+  }
+
+  BytesPerPixel = GetBytesPerPixel(LcdBpp);
+
+  // Disable the controller
+  MmioWrite32(HDLCD_REG_COMMAND, HDLCD_DISABLE);
+
+  // Update the frame buffer information with the new settings
+  MmioWrite32(HDLCD_REG_FB_LINE_LENGTH, HRes * BytesPerPixel);
+  MmioWrite32(HDLCD_REG_FB_LINE_PITCH,  HRes * BytesPerPixel);
+  MmioWrite32(HDLCD_REG_FB_LINE_COUNT,  VRes - 1);
+
+  // Set the vertical timing information
+  MmioWrite32(HDLCD_REG_V_SYNC, VSync);
+  MmioWrite32(HDLCD_REG_V_BACK_PORCH,   VBackPorch);
+  MmioWrite32(HDLCD_REG_V_DATA, VRes - 1);
+  MmioWrite32(HDLCD_REG_V_FRONT_PORCH,  VFrontPorch);
+
+  // Set the horizontal timing information
+  MmioWrite32(HDLCD_REG_H_SYNC, HSync);
+  MmioWrite32(HDLCD_REG_H_BACK_PORCH,   HBackPorch);
+  MmioWrite32(HDLCD_REG_H_DATA, HRes - 1);
+  MmioWrite32(HDLCD_REG_H_FRONT_PORCH,  HFrontPorch);
+
+  // Enable the controller
+  MmioWrite32(HDLCD_REG_COMMAND, HDLCD_ENABLE);
+
+  return EFI_SUCCESS;
+}
+
+VOID
+LcdShutdown (
+  VOID
+  )
+{
+  // Disable the controller
+  MmioWrite32 (HDLCD_REG_COMMAND, HDLCD_DISABLE);
+}
+
+EFI_STATUS
+LcdIdentify (
+  VOID
+  )
+{
+  return 

[edk2] [PATCH 2/5] ArmPlatformPkg: implement LcdHwLib for PL111

2017-12-01 Thread Ard Biesheuvel
Convert the PL111 specific code of LcdGraphicsOutputDxe into a LcdHwlib
implementation that we will wire up later into LcdGraphicsOutputDxe.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak 
Signed-off-by: Evan Lloyd 
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c   | 126 +
 ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.h   | 149 
 ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.inf |  40 ++
 3 files changed, 315 insertions(+)

diff --git a/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c 
b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
new file mode 100644
index ..9b4a02045ab7
--- /dev/null
+++ b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
@@ -0,0 +1,126 @@
+/** @file  PL111Lcd.c
+
+  Copyright (c) 2011-2012, ARM Ltd. All rights reserved.
+
+  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 "PL111Lcd.h"
+
+/**
+ *
+ *  This file contains all the bits of the PL111 that are
+ *  platform independent.
+ *
+ **/
+
+EFI_STATUS
+LcdIdentify (
+  VOID
+  )
+{
+  DEBUG ((EFI_D_WARN, "Probing ID registers at 0x%lx for a PL111\n",
+PL111_REG_CLCD_PERIPH_ID_0));
+
+  // Check if this is a PL111
+  if (MmioRead8 (PL111_REG_CLCD_PERIPH_ID_0) == PL111_CLCD_PERIPH_ID_0 &&
+  MmioRead8 (PL111_REG_CLCD_PERIPH_ID_1) == PL111_CLCD_PERIPH_ID_1 &&
+ (MmioRead8 (PL111_REG_CLCD_PERIPH_ID_2) & 0xf) == PL111_CLCD_PERIPH_ID_2 
&&
+  MmioRead8 (PL111_REG_CLCD_PERIPH_ID_3) == PL111_CLCD_PERIPH_ID_3 &&
+  MmioRead8 (PL111_REG_CLCD_P_CELL_ID_0) == PL111_CLCD_P_CELL_ID_0 &&
+  MmioRead8 (PL111_REG_CLCD_P_CELL_ID_1) == PL111_CLCD_P_CELL_ID_1 &&
+  MmioRead8 (PL111_REG_CLCD_P_CELL_ID_2) == PL111_CLCD_P_CELL_ID_2 &&
+  MmioRead8 (PL111_REG_CLCD_P_CELL_ID_3) == PL111_CLCD_P_CELL_ID_3) {
+return EFI_SUCCESS;
+  }
+  return EFI_NOT_FOUND;
+}
+
+EFI_STATUS
+LcdInitialize (
+  IN EFI_PHYSICAL_ADDRESS   VramBaseAddress
+  )
+{
+  // Define start of the VRAM. This never changes for any graphics mode
+  MmioWrite32(PL111_REG_LCD_UP_BASE, (UINT32) VramBaseAddress);
+  MmioWrite32(PL111_REG_LCD_LP_BASE, 0); // We are not using a double buffer
+
+  // Disable all interrupts from the PL111
+  MmioWrite32(PL111_REG_LCD_IMSC, 0);
+
+  return EFI_SUCCESS;
+}
+
+EFI_STATUS
+LcdSetMode (
+  IN UINT32  ModeNumber
+  )
+{
+  EFI_STATUSStatus;
+  UINT32HRes;
+  UINT32HSync;
+  UINT32HBackPorch;
+  UINT32HFrontPorch;
+  UINT32VRes;
+  UINT32VSync;
+  UINT32VBackPorch;
+  UINT32VFrontPorch;
+  UINT32LcdControl;
+  LCD_BPP   LcdBpp;
+
+  // Set the video mode timings and other relevant information
+  Status = LcdPlatformGetTimings (ModeNumber,
+  
+  ,,,);
+  ASSERT_EFI_ERROR (Status);
+  if (EFI_ERROR( Status )) {
+return EFI_DEVICE_ERROR;
+  }
+
+  Status = LcdPlatformGetBpp (ModeNumber,);
+  ASSERT_EFI_ERROR (Status);
+  if (EFI_ERROR( Status )) {
+return EFI_DEVICE_ERROR;
+  }
+
+  // Disable the CLCD_LcdEn bit
+  LcdControl = MmioRead32( PL111_REG_LCD_CONTROL);
+  MmioWrite32(PL111_REG_LCD_CONTROL,  LcdControl & ~1);
+
+  // Set Timings
+  MmioWrite32 (PL111_REG_LCD_TIMING_0, HOR_AXIS_PANEL(HBackPorch, HFrontPorch, 
HSync, HRes));
+  MmioWrite32 (PL111_REG_LCD_TIMING_1, VER_AXIS_PANEL(VBackPorch, VFrontPorch, 
VSync, VRes));
+  MmioWrite32 (PL111_REG_LCD_TIMING_2, CLK_SIG_POLARITY(HRes));
+  MmioWrite32 (PL111_REG_LCD_TIMING_3, 0);
+
+  // PL111_REG_LCD_CONTROL
+  LcdControl = PL111_CTRL_LCD_EN | PL111_CTRL_LCD_BPP(LcdBpp) | 
PL111_CTRL_LCD_TFT | PL111_CTRL_BGR;
+  MmioWrite32(PL111_REG_LCD_CONTROL,  LcdControl);
+
+  // Turn on power to the LCD Panel
+  LcdControl |= PL111_CTRL_LCD_PWR;
+  MmioWrite32(PL111_REG_LCD_CONTROL,  LcdControl);
+
+  return EFI_SUCCESS;
+}
+
+VOID
+LcdShutdown (
+  VOID
+  )
+{
+  // Disable the controller
+  MmioAnd32 (PL111_REG_LCD_CONTROL, ~PL111_CTRL_LCD_EN);
+}
diff --git a/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.h 
b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.h
new file mode 100644
index ..18e28af805f6
--- /dev/null
+++ b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.h
@@ -0,0 +1,149 @@
+/** @file  PL111Lcd.h
+
+ Copyright (c) 2011, ARM Ltd. All 

[edk2] [PATCH 1/5] ArmPlatformPkg: introduce LcdhwLib library class

2017-12-01 Thread Ard Biesheuvel
Add the declaration and include file for the new LcdHwLib library class,
which will allow us to abstract away from platform  variations in the
LCD graphics output driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak 
Signed-off-by: Evan Lloyd 
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmPlatformPkg.dec |  1 +
 ArmPlatformPkg/Include/Library/LcdHwLib.h | 65 
 2 files changed, 66 insertions(+)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec 
b/ArmPlatformPkg/ArmPlatformPkg.dec
index 9d47e459eadc..9ccf540e5b80 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -32,6 +32,7 @@ [Includes.common]
   Include# Root include for the package
 
 [LibraryClasses]
+  LcdHwLib|Include/Library/LcdHwLib.h
   PL011UartLib|Include/Library/PL011UartLib.h
 
 [Guids.common]
diff --git a/ArmPlatformPkg/Include/Library/LcdHwLib.h 
b/ArmPlatformPkg/Include/Library/LcdHwLib.h
new file mode 100644
index ..a426cd392357
--- /dev/null
+++ b/ArmPlatformPkg/Include/Library/LcdHwLib.h
@@ -0,0 +1,65 @@
+/** @file LcdHwLib.h
+
+  This file contains interface functions for LcdHwLib of ArmPlatformPkg
+
+  Copyright (c) 2017, ARM Ltd. All rights reserved.
+
+  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.
+
+**/
+
+#ifndef LCD_HW_LIB_H_
+#define LCD_HW_LIB_H_
+
+#include 
+
+/** Check for presence of display
+ *
+ *  @retval EFI_SUCCESSPlatform implements display.
+ *  @retval EFI_NOT_FOUND  Display not found on the platform.
+ */
+EFI_STATUS
+LcdIdentify (
+  VOID
+);
+
+/** Initialize display.
+ *
+ *  @param  FrameBaseAddress   Address of the frame buffer.
+ *  @retval EFI_SUCCESSDisplay initialization success.
+ *  @retval !(EFI_SUCCESS) Display initialization failure.
+ *
+**/
+EFI_STATUS
+LcdInitialize (
+  EFI_PHYSICAL_ADDRESS  FrameBaseAddress
+);
+
+/** Set requested mode of the display.
+ *
+ *  @param  ModeNumber Display mode number.
+ *  @retval EFI_SUCCESSDisplay set mode success.
+ *  @retval EFI_DEVICE_ERROR   If mode not found/supported.
+ *
+**/
+EFI_STATUS
+LcdSetMode (
+  IN UINT32  ModeNumber
+);
+
+
+/** De-initializes the display.
+ *
+**/
+VOID
+LcdShutdown (
+  VOID
+);
+
+#endif /* LCD_HW_LIB_H_ */
-- 
2.11.0

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


[edk2] [PATCH edk2-platforms 0/5] Platform/ARM: move to new LCD graphics driver

2017-12-01 Thread Ard Biesheuvel
This is the edk2-platforms counterpart to the series against EDK2 that
refactors the LCD graphics output driver, and moves platform specific glue
out of the main repository.

Cc: Girish Pathak 
Cc: Evan Lloyd 

Ard Biesheuvel (5):
  Platform/ARM: add VExpressPkg .dec file base on EDK2's
ArmPlatformPkg.dec
  Platform/ARM: import PL111 glue library for VExpress
  Platform/ARM: import HcdLcd glue library for VExpress
  Platform/ARM: move FVP to the new LcdGraphicsOutputDxe driver
  Platform/ARM: move TC2 to the new LcdGraphicsOutputDxe driver

 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc| 
  8 +-
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf| 
  3 +-
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 
  5 +-
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf | 
  2 +-
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 
  5 +-
 Platform/ARM/VExpressPkg/ArmVExpressPkg.dec  | 
 34 ++
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c  | 
285 +++
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf | 
 43 +++
 Platform/ARM/VExpressPkg/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c| 
370 
 Platform/ARM/VExpressPkg/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf   | 
 44 +++
 10 files changed, 786 insertions(+), 13 deletions(-)
 create mode 100644 Platform/ARM/VExpressPkg/ArmVExpressPkg.dec
 create mode 100644 
Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
 create mode 100644 
Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
 create mode 100644 
Platform/ARM/VExpressPkg/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
 create mode 100644 
Platform/ARM/VExpressPkg/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf

-- 
2.11.0

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


[edk2] [PATCH 5/5] ArmPlatformPkg: remove old PL111/HdLcd driver code

2017-12-01 Thread Ard Biesheuvel
Now that LcdGraphicsOutputDxe has been refactored, remove the old code
that is no longer used.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak 
Signed-off-by: Evan Lloyd 
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c   
 | 285 ---
 
ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
   |  45 ---
 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
  | 370 
 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 |  44 ---
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/HdLcd.c
 | 133 ---
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/HdLcdGraphicsOutputDxe.inf 
 |  63 
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c 
 | 126 ---
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111LcdGraphicsOutputDxe.inf  
 |  59 
 ArmPlatformPkg/Include/Drivers/HdLcd.h 
 |  89 -
 ArmPlatformPkg/Include/Drivers/PL111Lcd.h  
 | 149 
 10 files changed, 1363 deletions(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
deleted file mode 100644
index b1106ee19b98..
--- 
a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
+++ /dev/null
@@ -1,285 +0,0 @@
-/**
-
-  Copyright (c) 2012, ARM Ltd. All rights reserved.
-
-  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 
-
-typedef struct {
-  UINT32 Mode;
-  UINT32 HorizontalResolution;
-  UINT32 VerticalResolution;
-  LCD_BPPBpp;
-  UINT32 OscFreq;
-
-  // These are used by HDLCD
-  UINT32 HSync;
-  UINT32 HBackPorch;
-  UINT32 HFrontPorch;
-  UINT32 VSync;
-  UINT32 VBackPorch;
-  UINT32 VFrontPorch;
-} LCD_RESOLUTION;
-
-
-LCD_RESOLUTION mResolutions[] = {
-  { // Mode 0 : VGA : 640 x 480 x 24 bpp
-VGA, VGA_H_RES_PIXELS, VGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
VGA_OSC_FREQUENCY,
-VGA_H_SYNC, VGA_H_BACK_PORCH, VGA_H_FRONT_PORCH,
-VGA_V_SYNC, VGA_V_BACK_PORCH, VGA_V_FRONT_PORCH
-  },
-  { // Mode 1 : SVGA : 800 x 600 x 24 bpp
-SVGA, SVGA_H_RES_PIXELS, SVGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
SVGA_OSC_FREQUENCY,
-SVGA_H_SYNC, SVGA_H_BACK_PORCH, SVGA_H_FRONT_PORCH,
-SVGA_V_SYNC, SVGA_V_BACK_PORCH, SVGA_V_FRONT_PORCH
-  },
-  { // Mode 2 : XGA : 1024 x 768 x 24 bpp
-XGA, XGA_H_RES_PIXELS, XGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
XGA_OSC_FREQUENCY,
-XGA_H_SYNC, XGA_H_BACK_PORCH, XGA_H_FRONT_PORCH,
-XGA_V_SYNC, XGA_V_BACK_PORCH, XGA_V_FRONT_PORCH
-  },
-  { // Mode 3 : SXGA : 1280 x 1024 x 24 bpp
-SXGA, SXGA_H_RES_PIXELS, SXGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
(SXGA_OSC_FREQUENCY/2),
-SXGA_H_SYNC, SXGA_H_BACK_PORCH, SXGA_H_FRONT_PORCH,
-SXGA_V_SYNC, SXGA_V_BACK_PORCH, SXGA_V_FRONT_PORCH
-  },
-  { // Mode 4 : UXGA : 1600 x 1200 x 24 bpp
-UXGA, UXGA_H_RES_PIXELS, UXGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
(UXGA_OSC_FREQUENCY/2),
-UXGA_H_SYNC, UXGA_H_BACK_PORCH, UXGA_H_FRONT_PORCH,
-UXGA_V_SYNC, UXGA_V_BACK_PORCH, UXGA_V_FRONT_PORCH
-  },
-  { // Mode 5 : HD : 1920 x 1080 x 24 bpp
-HD, HD_H_RES_PIXELS, HD_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24, 
(HD_OSC_FREQUENCY/2),
-HD_H_SYNC, HD_H_BACK_PORCH, HD_H_FRONT_PORCH,
-HD_V_SYNC, HD_V_BACK_PORCH, HD_V_FRONT_PORCH
-  }
-};
-
-EFI_EDID_DISCOVERED_PROTOCOL  mEdidDiscovered = {
-  0,
-  NULL
-};
-
-EFI_EDID_ACTIVE_PROTOCOL  mEdidActive = {
-  0,
-  NULL
-};
-
-EFI_STATUS
-LcdPlatformInitializeDisplay (
-  IN EFI_HANDLE   Handle
-  )
-{
-  EFI_STATUS  Status;
-
-  // Set the FPGA multiplexer to select the video output from the motherboard 
or the daughterboard
-  Status = ArmPlatformSysConfigSet (SYS_CFG_MUXFPGA, 
ARM_VE_DAUGHTERBOARD_1_SITE);
-  if (EFI_ERROR(Status)) {
-return Status;
-  }
-
-  // Install the EDID Protocols
-  Status = 

Re: [edk2] [PATCH v2 4/8] OvmfPkg: introduce FlashNvStorageAddressLib

2017-12-01 Thread Laszlo Ersek
On 12/01/17 12:03, Laszlo Ersek wrote:
> On 12/01/17 09:55, Ard Biesheuvel wrote:
>> On 30 November 2017 at 16:30, Laszlo Ersek  wrote:
>>> An OVMF binary built with
>>>
>>>   -D SMM_REQUIRE
>>>
>>> or with
>>>
>>>   -D MEM_VARSTORE_EMU_ENABLE=FALSE
>>>
>>> requires flash to be present at the expected (build-time determined)
>>> location; falling back to the emulated varstore is not possible.
>>>
>>> In such builds, we can replace the settings of the
>>> - varstore,
>>> - FTW working block,
>>> - and FTW spare area
>>> address PCDs in QemuFlashFvbServicesRuntimeDxe with identical settings in
>>> a new plug-in (NULL class) library, to be linked into variable-related
>>> PEIMs.
>>>
>>> This will enable such builds to access variables during the PEI phase,
>>> without dynamic flash detection and without ordering constraints against
>>> other PEIMs.
>>>
>>
>> Why can't we set these at build time in this case?
> 
> Hmm, let me think... Oh yes, I think I remember.
> 
> The PCDs that are used as *source* here (i.e., passed as arguments to
> PcdGet32()) *are* set at build time. However, they take some calculation
> at build time too, and they are set in the "OvmfPkg/OvmfPkg.fdf.inc"
> file, with explicit SET statments.
> 
> This is because you can build OVMF for a 1MB, 2MB, or 4MB unified flash
> image size, and the "source PCDs" in question depend on them.
> Furthermore, these "source PCDs" are fixed-at-build.
> 
> I think I couldn't find a way to set the defaults for the "target",
> dynamic, PCDs, from the build-time-calculated "source PCDs". The usual
> dynamic-default setting in the DSC does not work (because the default
> value is not a numeric constant), and, as far as I remember, when I
> tried the SET command on the dynamic ("target") PCDs as well, it simply
> didn't work.
> 
> The SET statements *could* work if the target PCDs could be made
> (conditionally) fixed-at-build as well, but then we run into the same
> build problem of ReserveEmuVariableNvStore() not compiling.
> 
> In short:
> 
> - the "target" PCDs have to remain dynamic, or else
> ReserveEmuVariableNvStore() won't compile,

correction -- ReserveEmuVariableNvStore() is totally irrelevant here;
what I meant here were the PcdSet calls for these "target" PCDs that
wouldn't compile in QemuFlashFvbServicesRuntimeDxe. (See patch 6.)

Thanks,
Laszlo

> 
> - as long as the "target" PCDs are dynamic, I cannot set their defaults
> at build time *from* the "source" fixed-at-build PCDs, which are
> calculated at each build separately, with the SET statement.
> 
> Thanks
> Laszlo
> 
> 
>>
>>> Cc: Anthony Perard 
>>> Cc: Ard Biesheuvel 
>>> Cc: Jordan Justen 
>>> Cc: Julien Grall 
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Laszlo Ersek 
>>> ---
>>>  OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf | 48 
>>> ++
>>>  OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c   | 53 
>>> 
>>>  2 files changed, 101 insertions(+)
>>>
>>> diff --git 
>>> a/OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf 
>>> b/OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf
>>> new file mode 100644
>>> index ..f79194f80de9
>>> --- /dev/null
>>> +++ b/OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf
>>> @@ -0,0 +1,48 @@
>>> +## @file
>>> +#
>>> +# A hook-in library for variable-related PEIMs, in order to set
>>> +# - gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64,
>>> +# - gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase,
>>> +# - gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase,
>>> +# from their gUefiOvmfPkgTokenSpaceGuid counterparts, just before those 
>>> PEIMs
>>> +# consume them.
>>> +#
>>> +# Copyright (C) 2017, Red Hat, Inc.
>>> +#
>>> +# 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.
>>> +#
>>> +##
>>> +
>>> +[Defines]
>>> +  INF_VERSION= 1.25
>>> +  BASE_NAME  = FlashNvStorageAddressLib
>>> +  FILE_GUID  = 5FF5A9F9-D01E-49EC-9A17-1682FC85122F
>>> +  MODULE_TYPE= BASE
>>> +  VERSION_STRING = 1.0
>>> +  LIBRARY_CLASS  = FlashNvStorageAddressLib|PEIM
>>> +  CONSTRUCTOR= SetFlashNvStorageAddresses
>>> +
>>> +[Sources]
>>> +  FlashNvStorageAddressLib.c
>>> +
>>> +[Packages]
>>> +  

Re: [edk2] [PATCH v2 4/8] OvmfPkg: introduce FlashNvStorageAddressLib

2017-12-01 Thread Laszlo Ersek
On 12/01/17 09:55, Ard Biesheuvel wrote:
> On 30 November 2017 at 16:30, Laszlo Ersek  wrote:
>> An OVMF binary built with
>>
>>   -D SMM_REQUIRE
>>
>> or with
>>
>>   -D MEM_VARSTORE_EMU_ENABLE=FALSE
>>
>> requires flash to be present at the expected (build-time determined)
>> location; falling back to the emulated varstore is not possible.
>>
>> In such builds, we can replace the settings of the
>> - varstore,
>> - FTW working block,
>> - and FTW spare area
>> address PCDs in QemuFlashFvbServicesRuntimeDxe with identical settings in
>> a new plug-in (NULL class) library, to be linked into variable-related
>> PEIMs.
>>
>> This will enable such builds to access variables during the PEI phase,
>> without dynamic flash detection and without ordering constraints against
>> other PEIMs.
>>
> 
> Why can't we set these at build time in this case?

Hmm, let me think... Oh yes, I think I remember.

The PCDs that are used as *source* here (i.e., passed as arguments to
PcdGet32()) *are* set at build time. However, they take some calculation
at build time too, and they are set in the "OvmfPkg/OvmfPkg.fdf.inc"
file, with explicit SET statments.

This is because you can build OVMF for a 1MB, 2MB, or 4MB unified flash
image size, and the "source PCDs" in question depend on them.
Furthermore, these "source PCDs" are fixed-at-build.

I think I couldn't find a way to set the defaults for the "target",
dynamic, PCDs, from the build-time-calculated "source PCDs". The usual
dynamic-default setting in the DSC does not work (because the default
value is not a numeric constant), and, as far as I remember, when I
tried the SET command on the dynamic ("target") PCDs as well, it simply
didn't work.

The SET statements *could* work if the target PCDs could be made
(conditionally) fixed-at-build as well, but then we run into the same
build problem of ReserveEmuVariableNvStore() not compiling.

In short:

- the "target" PCDs have to remain dynamic, or else
ReserveEmuVariableNvStore() won't compile,

- as long as the "target" PCDs are dynamic, I cannot set their defaults
at build time *from* the "source" fixed-at-build PCDs, which are
calculated at each build separately, with the SET statement.

Thanks
Laszlo


> 
>> Cc: Anthony Perard 
>> Cc: Ard Biesheuvel 
>> Cc: Jordan Justen 
>> Cc: Julien Grall 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
>> ---
>>  OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf | 48 
>> ++
>>  OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c   | 53 
>> 
>>  2 files changed, 101 insertions(+)
>>
>> diff --git 
>> a/OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf 
>> b/OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf
>> new file mode 100644
>> index ..f79194f80de9
>> --- /dev/null
>> +++ b/OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf
>> @@ -0,0 +1,48 @@
>> +## @file
>> +#
>> +# A hook-in library for variable-related PEIMs, in order to set
>> +# - gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64,
>> +# - gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase,
>> +# - gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase,
>> +# from their gUefiOvmfPkgTokenSpaceGuid counterparts, just before those 
>> PEIMs
>> +# consume them.
>> +#
>> +# Copyright (C) 2017, Red Hat, Inc.
>> +#
>> +# 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.
>> +#
>> +##
>> +
>> +[Defines]
>> +  INF_VERSION= 1.25
>> +  BASE_NAME  = FlashNvStorageAddressLib
>> +  FILE_GUID  = 5FF5A9F9-D01E-49EC-9A17-1682FC85122F
>> +  MODULE_TYPE= BASE
>> +  VERSION_STRING = 1.0
>> +  LIBRARY_CLASS  = FlashNvStorageAddressLib|PEIM
>> +  CONSTRUCTOR= SetFlashNvStorageAddresses
>> +
>> +[Sources]
>> +  FlashNvStorageAddressLib.c
>> +
>> +[Packages]
>> +  MdePkg/MdePkg.dec
>> +  MdeModulePkg/MdeModulePkg.dec
>> +  OvmfPkg/OvmfPkg.dec
>> +
>> +[LibraryClasses]
>> +  PcdLib
>> +
>> +[Pcd]
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
>> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwSpareBase
>> +  

Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian MMIO

2017-12-01 Thread Leif Lindholm
On Thu, Nov 30, 2017 at 04:15:38AM +, Meenakshi Aggarwal wrote:
> Hi Leif, Mike,
> 
> 
> NXP boards, at present, have few controllers with big endian and
> other with little endian memory access.

Sure, this is not a problem.

> Maximum controllers depend on SocLib library for clock information
> and endianness for SocLib and controllers is different.

OK, I see in SocLib you have something called a Gur that is read once
(and again does a special per-device Pcd dance for runtime selection
between byteswapping Mmio and plain Mmio).

> So this option will not work for us,
>   You would then just do (in your .dsc):
>   Platform/NXP/Drivers/WatchDog/WatchDogDxe.inf {
>   IoLib|
>   }
> 
> Because all libraries included by WatchDog will then access BE mode Mmio APIs.

Which libraries performing Mmio accesses are you intending to include
in your watchdog driver? You have submitted none as part of this series.

> And breaking code into separate modules with different access will
> be very difficult.

It may require a little bit more of up-front work, but the end result
will be a platform port that works with the intended edk2 design
principles rather than against them. And that will reduce the overall
effort (not to mention code duplication).

From the patches you have sent, the only required change I see (if a
byteswapping IoLib was added to edk2) would be to create a tiny driver
for this "Gur" device that installs a protocol containing a single
function for reading from that device's register space. That driver
can be built against the swapping or non-swapping IoLib as
appropriate.

> Watchdog is not the only module which need BE Mmio APIs, we have MMC
> and other controllers also with same requirement.

And the same solutions are possible everywhere.

Best Regards,

Leif

> We need BE Mmio APIs with a different name.
> 
> Please see the possibility.
>
> Thanks & Regards,
> Meenakshi
> 
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: Thursday, November 30, 2017 1:19 AM
> > To: Kinney, Michael D 
> > Cc: Meenakshi Aggarwal ; Gao, Liming
> > ; edk2-devel@lists.01.org; Ard Biesheuvel
> > 
> > Subject: Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian
> > MMIO
> > 
> > I guess there is no strict rule about a driver only directly accessing
> > one piece of HW?
> > 
> > Still, that would be one possible solution: breaking accesses to a
> > separate HW in need of byteswapping out into its own module and
> > letting it override IoLib version there.
> > 
> > Regards,
> > 
> > Leif
> > 
> > On Wed, Nov 29, 2017 at 07:25:05PM +, Kinney, Michael D wrote:
> > > Leif,
> > >
> > > I agree that this should be described as byte swapping.
> > >
> > > What about a module that needs to access HW with and
> > > without the bytes swapped?  It gets more complex if a
> > > module is linked against several libs and some libs
> > > access HW with bytes swapped and some do not.
> > >
> > > Thanks,
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-
> > > > boun...@lists.01.org] On Behalf Of Leif Lindholm
> > > > Sent: Wednesday, November 29, 2017 4:51 AM
> > > > To: Meenakshi Aggarwal ;
> > > > Gao, Liming 
> > > > Cc: Kinney, Michael D ;
> > > > edk2-devel@lists.01.org; Ard Biesheuvel
> > > > 
> > > > Subject: Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add
> > > > support for big-endian MMIO
> > > >
> > > > Hi Meenakshi,
> > > >
> > > > I finally got around to looking at the watchdog code
> > > > (that uses this
> > > > library), and that has convinced me the best solution
> > > > is to do what
> > > > Liming proposed.
> > > >
> > > > Looking at this snippet:
> > > >
> > > > > +STATIC
> > > > > +UINT16
> > > > > +EFIAPI
> > > > > +WdogRead (
> > > > > + ย IN ย UINTN ย  ย  Address
> > > > > + ย )
> > > > > +{
> > > > > + ย if (FixedPcdGetBool (PcdWdogBigEndian)) {
> > > > > + ย  ย return BeMmioRead16 (Address);
> > > > > + ย } else {
> > > > > + ย  ย return MmioRead16(Address);
> > > > > + ย }
> > > >
> > > > This is actually a pretty good demonstration of the
> > > > arguments that
> > > > were made with regards to how the BeIoLib could be just
> > > > another
> > > > implementation of IoLib.
> > > >
> > > > You would then just do (in your .dsc):
> > > > ย  Platform/NXP/Drivers/WatchDog/WatchDogDxe.inf {
> > > > ย  ย  IoLib|
> > > > ย  }
> > > >
> > > > This causes the big-endian version of the library to be
> > > > used for this
> > > > component. This makes these Wdog functions and
> > > > the Pcd
> > > > redundant, and the rest of the code can use
> > > > MmioRead16()/MmioWrite16()
> > > > directly.
> > > >
> > > > But then, it is not really a big-endian or litte-endian
> > > > version of the
> > > > library we need. We 

Re: [edk2] [PATCH v2 3/8] OvmfPkg: conditionally disable reserved memory varstore emulation at build

2017-12-01 Thread Ard Biesheuvel
On 1 December 2017 at 10:52, Laszlo Ersek  wrote:
> On 12/01/17 09:51, Ard Biesheuvel wrote:
>> On 30 November 2017 at 16:30, Laszlo Ersek  wrote:
>>> (All of the below is only relevant for SMM_REQUIRE=FALSE.)
>>>
>>> For the emulated variable store, PlatformPei allocates reserved memory (as
>>> early as possible, so that the address remains the same during reboot),
>>> and PcdEmuVariableNvStoreReserved carries the address to
>>> EmuVariableFvbRuntimeDxe.
>>>
>>> In addition, QemuFlashFvbServicesRuntimeDxe is always launched before
>>> EmuVariableFvbRuntimeDxe, so that if flash variables are available,
>>> QemuFlashFvbServicesRuntimeDxe can set PcdFlashNvStorageVariableBase64
>>> first, and EmuVariableFvbRuntimeDxe can exit early. This ordering is
>>> currently enforced by adding QemuFlashFvbServicesRuntimeDxe to the APRIORI
>>> DXE file.
>>>
>>> All of this is unnecessary when MEM_VARSTORE_EMU_ENABLE is set to FALSE.
>>> In such a build,
>>>
>>> - (almost) remove the dynamic default for PcdEmuVariableNvStoreReserved
>>>   (we can't really do this because the PcdSet64() in
>>>   ReserveEmuVariableNvStore() wouldn't compile),
>>>
>>
>> If that is the only concern, and the value is irrelevant, you could
>> make it a patchable PCD instead
>
> This sounds interesting; I've never used patchable PCDs. Can you please
> elaborate?
>
> Do you mean that for (SMM_REQUIRE==TRUE ||
> MEM_VARSTORE_EMU_ENABLE==FALSE), the DSC file should list
> PcdEmuVariableNvStoreReserved somewhere else?
>

Yes.

> Does PcdSet work on patchable PCDs?
>

Yes. It's a bit icky because the value does not actually propagate to
other modules, but that doesn't matter in this case.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2 3/8] OvmfPkg: conditionally disable reserved memory varstore emulation at build

2017-12-01 Thread Laszlo Ersek
On 12/01/17 09:51, Ard Biesheuvel wrote:
> On 30 November 2017 at 16:30, Laszlo Ersek  wrote:
>> (All of the below is only relevant for SMM_REQUIRE=FALSE.)
>>
>> For the emulated variable store, PlatformPei allocates reserved memory (as
>> early as possible, so that the address remains the same during reboot),
>> and PcdEmuVariableNvStoreReserved carries the address to
>> EmuVariableFvbRuntimeDxe.
>>
>> In addition, QemuFlashFvbServicesRuntimeDxe is always launched before
>> EmuVariableFvbRuntimeDxe, so that if flash variables are available,
>> QemuFlashFvbServicesRuntimeDxe can set PcdFlashNvStorageVariableBase64
>> first, and EmuVariableFvbRuntimeDxe can exit early. This ordering is
>> currently enforced by adding QemuFlashFvbServicesRuntimeDxe to the APRIORI
>> DXE file.
>>
>> All of this is unnecessary when MEM_VARSTORE_EMU_ENABLE is set to FALSE.
>> In such a build,
>>
>> - (almost) remove the dynamic default for PcdEmuVariableNvStoreReserved
>>   (we can't really do this because the PcdSet64() in
>>   ReserveEmuVariableNvStore() wouldn't compile),
>>
> 
> If that is the only concern, and the value is irrelevant, you could
> make it a patchable PCD instead

This sounds interesting; I've never used patchable PCDs. Can you please
elaborate?

Do you mean that for (SMM_REQUIRE==TRUE ||
MEM_VARSTORE_EMU_ENABLE==FALSE), the DSC file should list
PcdEmuVariableNvStoreReserved somewhere else?

Does PcdSet work on patchable PCDs?

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


Re: [edk2] [PATCH v2 0/8] OvmfPkg: add the Variable PEIM, defragment the UEFI memmap

2017-12-01 Thread Laszlo Ersek
On 12/01/17 09:42, Ard Biesheuvel wrote:
> On 30 November 2017 at 19:00, Jordan Justen  wrote:
>> As I recall, this enables a modest (non-essential) improvement in
>> fragmentation, at the cost of more ways to configure OVMF to hang
>> during boot. (With info available via debugcon.)
>>
>> I would prefer if were able to always fallback and continue boot.
>> Later, after GOP has started we could visibly warn the user that they
>> haven't properly enabled SMM and/or flash.
>>
>> If we had a way to do this, I would be in favor of displaying an error
>> message and delaying for 30 seconds before booting if flash has not
>> been enabled. (Or, if SMM was enabled in the build, but not set on the
>> command line.)
>>
>> At that point, I think we could start to transition to making flash an
>> boot requirement for OVMF. But first we need to be able to visibly
>> warn the user why they are not able to boot.
>>
> 
> That doesn't argue against this series, does it? AFAICT it only argues
> against building OVMF with a non-default value for
> MEM_VARSTORE_EMU_ENABLE

... which is explicitly documented in patch 8.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2 0/8] OvmfPkg: add the Variable PEIM, defragment the UEFI memmap

2017-12-01 Thread Laszlo Ersek
On 11/30/17 20:00, Jordan Justen wrote:
> As I recall, this enables a modest (non-essential) improvement in
> fragmentation,

My testing from 2 minutes ago shows that the UEFI memmap (as dumped by
the Linux guest) goes from 82 entries to 56 entries. I consider the
defragmentation a QoS question, and the patch set an avenue to further
features like S4.

> at the cost of more ways to configure OVMF to hang
> during boot. (With info available via debugcon.)

Yes.

The configuration is static, the default is sane, and distros can pretty
well decide if they want it or not, same as with SMM_REQUIRE. (Some
package providers offer multiple builds.)

> I would prefer if were able to always fallback and continue boot.

Sure, I would prefer that too. Can someone write it?

- Flash detection in the PEI phase, using the SMM_REQUIRE build, would
require OVMF to raise an SMI, enter SMM, do the detection, and propagate
the result.

- Assuming it works, all we get with it is that OVMF guests launched
with the "-bios" flag (including all OVMF/Xen guests) will get a PEI
phase r/o variable driver that has *zero* chance at returning actual
variable contents (because it cannot read the \NvVars file from the ESP,
even if there is such a partition and/or file.)

Is the above worth it, for users and packagers that consciously set
MEM_VARSTORE_EMU_ENABLE to FALSE at build, and then expect the binary to
boot with "-bios"?

> Later, after GOP has started we could visibly warn the user that they
> haven't properly enabled SMM and/or flash.

GOPs are provided by UEFI_DRIVER modules, generally. SMM/flash are
required much earlier than that.

Perhaps we could use status codes, and report them to the serial port.
Then I assume the complaint would be that (a) users don't understand
status codes, (b) users don't look at the serial port.

> If we had a way to do this, I would be in favor of displaying an error
> message and delaying for 30 seconds before booting if flash has not
> been enabled. (Or, if SMM was enabled in the build, but not set on the
> command line.)

An SMM build *must not* boot on a misconfigured QEMU.

> At that point, I think we could start to transition to making flash an
> boot requirement for OVMF. But first we need to be able to visibly
> warn the user why they are not able to boot.

I don't think this is a reasonable requirement.

First, the series does not make flash a requirement for OVMF, it allows
packagers to make that choice. Which they already have to make if they
consider SMM_REQUIRE.

Second, up till very recent commit d1de487dd2e7 ("MdeModulePkg/BdsDxe:
fall back to a Boot Manager Menu loop before hanging", 2017-11-22), OVMF
(and edk2) wouldn't report a boot failure to the console that was caused
by *much higher level* problems, such as booting a traditional BIOS / OS
disk image without having a CSM and a built-in shell. And when I tried
to introduce edk2-specific status codes for emitting more detail about
the boot process to the user, to the system console, I was asked to talk
to PIWG for standardizing the status codes first.

So on one hand, you want me to report very low level boot requirement
violations through a later, highly abstracted interface; and on the
other hand, when I try to report details of the *same* high abstraction
level, I'm directed to a standards body. I guess I give up. Thanks for
your time.

Laszlo

> 
> -Jordan
> 
> On 2017-11-30 08:30:21, Laszlo Ersek wrote:
>> Repo:   https://github.com/lersek/edk2.git
>> Branch: memmap_defrag_v2
>>
>> This version is identical to the v1 seres I posted in March. Some
>> patches of the v1 series have been committed. I've been rebasing and
>> using the rest since, and am now posting it as v2. References:
>>
>> * https://bugzilla.tianocore.org/show_bug.cgi?id=386
>>
>> * http://mid.mail-archive.com/20170314233246.17864-1-lersek@redhat.com
>>   https://lists.01.org/pipermail/edk2-devel/2017-March/008525.html
>>
>> * 
>> http://mid.mail-archive.com/20170327080544.24748-1-jordan.l.justen@intel.com
>>   https://lists.01.org/pipermail/edk2-devel/2017-March/009049.html
>>
>> Cc: Anthony Perard 
>> Cc: Ard Biesheuvel 
>> Cc: Jordan Justen 
>> Cc: Julien Grall 
>>
>> Thanks
>> Laszlo
>>
>> Laszlo Ersek (8):
>>   OvmfPkg: introduce PcdMemVarstoreEmuEnable feature flag
>>   OvmfPkg/QemuFlashFvbServicesRuntimeDxe: check PcdMemVarstoreEmuEnable
>>   OvmfPkg: conditionally disable reserved memory varstore emulation at
>> build
>>   OvmfPkg: introduce FlashNvStorageAddressLib
>>   OvmfPkg: include FaultTolerantWritePei and VariablePei
>>   OvmfPkg/QemuFlashFvbServicesRuntimeDxe: don't set flash PCDs if SMM or
>> no-emu
>>   OvmfPkg/PlatformPei: remedy UEFI memory map fragmentation
>>   OvmfPkg/README: document MEM_VARSTORE_EMU_ENABLE and memmap defrag
>>
>>  OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c   |  53 
>> +++
>>  

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

2017-12-01 Thread Cameron Craig
Added log as attachment.

>

Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: +44 1383 828 250 | fax:  | mobile:
e: cameron.cr...@exterity.com | w: www.exterity.com


-Original Message-
>From: Cameron Craig
>Sent: 01 December 2017 10:23
>To: 'You, Benjamin'; 'edk2-devel@lists.01.org'
>Subject: RE: [edk2] Enabling boot menu via serial & PXE boot in
>CorebootPayloadPkg
>
>Hi Benjamin,
>
>>> Interestingly, my debug build was complaining that it ran out of room
>>> when attempting to fit everything in the UEFIPAYLOAD.
>>> When I strip out the network additions and keep DEBUG on, Tianocore
>>> builds but errors at runtime:
>>> ```
>>> Failed to add memory space :0xFEE0 0x10 ``` I'm guessing I
>>> can increase the size of a region somewhere to avoid this issue?
>>
>>There has been a recent fix for this issue by commit e2ef8b9a68. Could
>>you please have a try?
>
>Nice! I tried that fix and can now run the debug build.
>
>>> I get serial output from coreboot and edk2, just not the boot menu.
>>
>>I will double check whether there is an issue with enabling serial with
>>release build.
>
>I get serial output from edk2 with the release build and the debug build.
>However this serial output does not include the boot menu, I just get progress
>and error codes (and debug messages in debug mode).
>I have attached a runtime log of a recent debug build.
>Given that I do get serial output I'm hoping that getting a boot menu via 
>serial
>is not far away.
>
>Thanks for the help so far!
>
>Cheers,
>Cameron

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
PROGRESS CODE: V03020003 I0
Loading PEIM at 0x08143C0 EntryPoint=0x0814600 CbSupportPeim.efi
PROGRESS CODE: V03020002 I0
0.  - 0FFF [10]
1. 1000 - 0009 [01]
2. 000A - 000F [02]
3. 0010 - 0FFF [01]
4. 1000 - 12150FFF [02]
5. 12151000 - 7AB25FFF [01]
6. 7AB26000 - 7AFF [10]
7. 7B00 - 7FFF [02]
8. D000 - D0FF [02]
9. E000 - EFFF [02]
10. FED1 - FED17FFF [02]
Low memory 0x7AB26000
SystemLowMemTop 0x8000
PeiMemBase: 0x76B2.
PeiMemSize: 0x400.
PeiInstallPeiMemory MemoryBegin 0x76B2, MemoryLength 0x400
Found one valid fv : 0x3E0083.
Install PPI: 49EDB1C1-BF21-4761-BB12-EB0031AABB39
Notify: PPI Guid: 49EDB1C1-BF21-4761-BB12-EB0031AABB39, Peim notify entry 
point: 807D48
The 1th FV start address is 0x083, size is 0x003E, handle is 
0x83
Install PPI: 7408D748-FC8C-4EE6-9288-C4BEC092A410
Actual Coreboot header: 7AB5B000.
Find CbMemTable Id 0x41435049, base 7AB37000, size 0x24000
Find CbMemTable Id 0x534D4254, base 7AB26000, size 0x800
Detected Acpi Table at 0x7AB37000, length 0x24000
Detected Smbios Table at 0x7AB26000, length 0x800
Create system table info guid hob
Find CbMemTable Id 0x41435049, base 7AB37000, size 0x24000
Find Rsdp at 7AB37000
Find Rsdt 0x7AB37030, Xsdt 0x7AB370E0
PmCtrl Reg 0x404
PmTimer Reg 0x408
Reset Reg 0xCF9
Reset Value 0x6
PmEvt Reg 0x400
PmGpeEn Reg 0x430
Create acpi board info guid hob
Found coreboot video frame buffer information
physical_address: 0xB000
x_resolution: 0x400
y_resolution: 0x300
bits_per_pixel: 0x20
bytes_per_line: 0x1000
red_mask_size: 0x8
red_mask_pos: 0x10
green_mask_size: 0x8
green_mask_pos: 0x8
blue_mask_size: 0x8
blue_mask_pos: 0x0
reserved_mask_size: 0x18
reserved_mask_pos: 0x18
Create frame buffer info guid hob
PROGRESS CODE: V03020003 I0
Temp Stack : BaseAddress=0x88000 Length=0x8000
Temp Heap  : BaseAddress=0x8 Length=0x8000
Total temporary memory:65536 bytes.
  temporary memory stack ever used: 32768 bytes.
  temporary memory heap used:   3880 bytes.
Old Stack size 32768, New stack size 131072
Stack Hob: BaseAddress=0x76B2 Length=0x2
Heap Offset = 0x76AC Stack Offset = 0x76AB
Loading PEIM at 0x0007AB14000 EntryPoint=0x0007AB1BE10 PeiCore.efi
Reinstall PPI: 8C8CE578-8A3D-4F1C-9935-896185C32DD3
Reinstall PPI: 5473C07A-3DCB-4DCA-BD6F-1E9689E7349A
Reinstall PPI: B9E0ABFE-5979-4914-977F-6DEE78C278A6
Install PPI: F894643D-C449-42D1-8EA8-85BDD8C65BDE
Loading PEIM at 0x0007AB0F000 EntryPoint=0x0007AB10103 DxeIpl.efi
PROGRESS CODE: V03020002 I0
PROGRESS CODE: V03020003 I0
Install PPI: 1A36E4E7-FAB6-476A-8E75-695A0576FDD7
Install PPI: 0AE8CE5D-E448-4437-A8D7-EBF5F194F731
DXE IPL Entry
Loading PEIM at 0x0007AAE7000 EntryPoint=0x0007AAE7240 DxeCore.efi
PROGRESS CODE: V03021001 I0
Loading DXE CORE at 0x0007AAE7000 EntryPoint=0x0007AAE7240
Install PPI: 605EA650-C65C-42E1-BA80-91A52AB618C6
HandOffToDxeCore() Stack Base: 0x7AAC7000, Stack Size: 0x2
PROGRESS 

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

2017-12-01 Thread Cameron Craig
Hi Benjamin,

>> Interestingly, my debug build was complaining that it ran out of room
>> when attempting to fit everything in the UEFIPAYLOAD.
>> When I strip out the network additions and keep DEBUG on, Tianocore
>> builds but errors at runtime:
>> ```
>> Failed to add memory space :0xFEE0 0x10 ``` I'm guessing I can
>> increase the size of a region somewhere to avoid this issue?
>
>There has been a recent fix for this issue by commit e2ef8b9a68. Could you
>please have a try?

Nice! I tried that fix and can now run the debug build.

>> I get serial output from coreboot and edk2, just not the boot menu.
>
>I will double check whether there is an issue with enabling serial with release
>build.

I get serial output from edk2 with the release build and the debug build.
However this serial output does not include the boot menu, I just get progress 
and error codes (and debug messages in debug mode).
I have attached a runtime log of a recent debug build.
Given that I do get serial output I'm hoping that getting a boot menu via 
serial is not far away.

Thanks for the help so far!

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



__
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


Re: [edk2] [PATCH v4 2/3] ArmVirtPkg: Fix build failure due to Tftp library removal

2017-12-01 Thread Laszlo Ersek
On 12/01/17 02:48, Ni, Ruiyu wrote:
> Laszlo,
> Thank you very much for that! I will try to become a talkaholic
> when writing commit messages next time.

I feel a bit of sarcasm directed at me in "talkaholic" :) I do deserve
that classification, no questions asked :)

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


Re: [edk2] [PATCH RFT] ArmVirtPkg/ArmVirtXen: move from Intel to generic BDS

2017-12-01 Thread Laszlo Ersek
On 11/30/17 21:31, Ard Biesheuvel wrote:
> ArmVirtXen is the only remaining consumer of ArmPlatformPkg's
> PlatformIntelBdsLib implementation, which is tightly coupled to the
> deprecated Intel BDS. So move ArmVirtXen to the generic BDS as well,
> allowing us to get rid of PlatformIntelBdsLib entirely.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/ArmVirtXen.dsc | 14 +++---
>  ArmVirtPkg/ArmVirtXen.fdf |  3 ++-
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index 11e073287a84..ae43d5990110 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -48,8 +48,9 @@ [LibraryClasses]
>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>  
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
> -  
> GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
> -  
> PlatformBdsLib|ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
> +  
> UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
> +  BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
> +  
> PlatformBootManagerLib|ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>  
>  [LibraryClasses.common.UEFI_DRIVER]
> @@ -86,6 +87,7 @@ [PcdsFixedAtBuild.common]
>gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|0
>  
>gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
> 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
>gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
> 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
>  
>  [PcdsPatchableInModule.common]
> @@ -199,7 +201,13 @@ [Components.common]
>MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> -  IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
> +  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
> +  MdeModulePkg/Application/UiApp/UiApp.inf {
> +
> +  NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
> +  NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
> +  
> NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
> +  }
>  
>OvmfPkg/XenBusDxe/XenBusDxe.inf
>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
> index 6586ce6be505..50e670254d52 100644
> --- a/ArmVirtPkg/ArmVirtXen.fdf
> +++ b/ArmVirtPkg/ArmVirtXen.fdf
> @@ -177,7 +177,8 @@ [FV.FvMain]
>INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> -  INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
> +  INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
> +  INF MdeModulePkg/Application/UiApp/UiApp.inf
>  
>INF OvmfPkg/XenBusDxe/XenBusDxe.inf
>INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> 

The patch looks fine, and I agree that the main thing that should decide
about it is testing by Julien.

Acked-by: Laszlo Ersek 

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


Re: [edk2] [PATCH v2 4/8] OvmfPkg: introduce FlashNvStorageAddressLib

2017-12-01 Thread Ard Biesheuvel
On 30 November 2017 at 16:30, Laszlo Ersek  wrote:
> An OVMF binary built with
>
>   -D SMM_REQUIRE
>
> or with
>
>   -D MEM_VARSTORE_EMU_ENABLE=FALSE
>
> requires flash to be present at the expected (build-time determined)
> location; falling back to the emulated varstore is not possible.
>
> In such builds, we can replace the settings of the
> - varstore,
> - FTW working block,
> - and FTW spare area
> address PCDs in QemuFlashFvbServicesRuntimeDxe with identical settings in
> a new plug-in (NULL class) library, to be linked into variable-related
> PEIMs.
>
> This will enable such builds to access variables during the PEI phase,
> without dynamic flash detection and without ordering constraints against
> other PEIMs.
>

Why can't we set these at build time in this case?

> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf | 48 
> ++
>  OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c   | 53 
> 
>  2 files changed, 101 insertions(+)
>
> diff --git 
> a/OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf 
> b/OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf
> new file mode 100644
> index ..f79194f80de9
> --- /dev/null
> +++ b/OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf
> @@ -0,0 +1,48 @@
> +## @file
> +#
> +# A hook-in library for variable-related PEIMs, in order to set
> +# - gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64,
> +# - gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase,
> +# - gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase,
> +# from their gUefiOvmfPkgTokenSpaceGuid counterparts, just before those PEIMs
> +# consume them.
> +#
> +# Copyright (C) 2017, Red Hat, Inc.
> +#
> +# 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.
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 1.25
> +  BASE_NAME  = FlashNvStorageAddressLib
> +  FILE_GUID  = 5FF5A9F9-D01E-49EC-9A17-1682FC85122F
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = FlashNvStorageAddressLib|PEIM
> +  CONSTRUCTOR= SetFlashNvStorageAddresses
> +
> +[Sources]
> +  FlashNvStorageAddressLib.c
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  MdeModulePkg/MdeModulePkg.dec
> +  OvmfPkg/OvmfPkg.dec
> +
> +[LibraryClasses]
> +  PcdLib
> +
> +[Pcd]
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwSpareBase
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase
> diff --git 
> a/OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c 
> b/OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c
> new file mode 100644
> index ..dc1280cc23f1
> --- /dev/null
> +++ b/OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c
> @@ -0,0 +1,53 @@
> +/** @file
> +
> +  A hook-in library for variable-related PEIMs, in order to set
> +  - gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64,
> +  - gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase,
> +  - gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase,
> +  from their gUefiOvmfPkgTokenSpaceGuid counterparts, just before those PEIMs
> +  consume them.
> +
> +  Copyright (C) 2017, Red Hat, Inc.
> +
> +  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 
> +
> +RETURN_STATUS
> +EFIAPI
> +SetFlashNvStorageAddresses (
> +  VOID
> +  )
> +{
> +  RETURN_STATUS PcdStatus;
> +
> +  PcdStatus = PcdSet64S (
> + 

Re: [edk2] [PATCH v2 3/8] OvmfPkg: conditionally disable reserved memory varstore emulation at build

2017-12-01 Thread Ard Biesheuvel
On 30 November 2017 at 16:30, Laszlo Ersek  wrote:
> (All of the below is only relevant for SMM_REQUIRE=FALSE.)
>
> For the emulated variable store, PlatformPei allocates reserved memory (as
> early as possible, so that the address remains the same during reboot),
> and PcdEmuVariableNvStoreReserved carries the address to
> EmuVariableFvbRuntimeDxe.
>
> In addition, QemuFlashFvbServicesRuntimeDxe is always launched before
> EmuVariableFvbRuntimeDxe, so that if flash variables are available,
> QemuFlashFvbServicesRuntimeDxe can set PcdFlashNvStorageVariableBase64
> first, and EmuVariableFvbRuntimeDxe can exit early. This ordering is
> currently enforced by adding QemuFlashFvbServicesRuntimeDxe to the APRIORI
> DXE file.
>
> All of this is unnecessary when MEM_VARSTORE_EMU_ENABLE is set to FALSE.
> In such a build,
>
> - (almost) remove the dynamic default for PcdEmuVariableNvStoreReserved
>   (we can't really do this because the PcdSet64() in
>   ReserveEmuVariableNvStore() wouldn't compile),
>

If that is the only concern, and the value is irrelevant, you could
make it a patchable PCD instead

> - prevent the reserved memory allocation and PCD setting in PlatformPei,
>
> - exclude EmuVariableFvbRuntimeDxe,
>
> - and drop QemuFlashFvbServicesRuntimeDxe from the APRIORI DXE file (since
>   it doesn't have to beat EmuVariableFvbRuntimeDxe in setting
>   PcdFlashNvStorageVariableBase64 any longer).
>
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>  OvmfPkg/OvmfPkgIa32.dsc | 4 +++-
>  OvmfPkg/OvmfPkgIa32X64.dsc  | 4 +++-
>  OvmfPkg/OvmfPkgX64.dsc  | 4 +++-
>  OvmfPkg/OvmfPkgIa32.fdf | 4 +++-
>  OvmfPkg/OvmfPkgIa32X64.fdf  | 4 +++-
>  OvmfPkg/OvmfPkgX64.fdf  | 4 +++-
>  OvmfPkg/PlatformPei/PlatformPei.inf | 1 +
>  OvmfPkg/PlatformPei/Platform.c  | 3 ++-
>  8 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 443da553d0a3..dd6be0de0445 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -502,7 +502,7 @@ [PcdsFixedAtBuild]
>
>  [PcdsDynamicDefault]
># only set when
> -  #   ($(SMM_REQUIRE) == FALSE)
> +  #   (($(SMM_REQUIRE) == FALSE) && ($(MEM_VARSTORE_EMU_ENABLE) == TRUE))
>gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
>
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
> @@ -871,10 +871,12 @@ [Components]
># Variable driver stack (non-SMM)
>#
>OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> +!if $(MEM_VARSTORE_EMU_ENABLE) == TRUE
>OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
>  
>PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
>}
> +!endif
>MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
>MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
>  
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 0fc81743bac4..84c578ac22a4 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -508,7 +508,7 @@ [PcdsFixedAtBuild.X64]
>
>  [PcdsDynamicDefault]
># only set when
> -  #   ($(SMM_REQUIRE) == FALSE)
> +  #   (($(SMM_REQUIRE) == FALSE) && ($(MEM_VARSTORE_EMU_ENABLE) == TRUE))
>gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
>
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
> @@ -881,10 +881,12 @@ [Components.X64]
># Variable driver stack (non-SMM)
>#
>OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> +!if $(MEM_VARSTORE_EMU_ENABLE) == TRUE
>OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
>  
>PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
>}
> +!endif
>MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
>MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
>  
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index db33be4bc0b7..b5d385101411 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -507,7 +507,7 @@ [PcdsFixedAtBuild]
>
>  [PcdsDynamicDefault]
># only set when
> -  #   ($(SMM_REQUIRE) == FALSE)
> +  #   (($(SMM_REQUIRE) == FALSE) && ($(MEM_VARSTORE_EMU_ENABLE) == TRUE))
>gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
>
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
> @@ -879,10 +879,12 @@ [Components]
># Variable driver stack (non-SMM)
>#
>OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> +!if $(MEM_VARSTORE_EMU_ENABLE) == TRUE
>

Re: [edk2] [PATCH v2 2/8] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: check PcdMemVarstoreEmuEnable

2017-12-01 Thread Ard Biesheuvel
On 30 November 2017 at 16:30, Laszlo Ersek  wrote:
> This patch parallels commit b963ec494c48 ("OvmfPkg:
> QemuFlashFvbServicesRuntimeDxe: adhere to -D SMM_REQUIRE", 2015-11-30) in
> that if QemuFlashDetected() fails -- because flash is not found --, not
> only SMM_REQUIRE=TRUE is a wrong build to execute, but
> MEM_VARSTORE_EMU_ENABLE=FALSE as well.
>
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf | 1 +
>  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf| 1 +
>  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c   | 1 +
>  3 files changed, 3 insertions(+)
>
> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
> b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> index c0dda75bf75f..cf30d5c8f021 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> @@ -87,6 +87,7 @@ [Pcd]
>
>  [FeaturePcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
> +  gUefiOvmfPkgTokenSpaceGuid.PcdMemVarstoreEmuEnable
>
>  [Depex]
>TRUE
> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf 
> b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
> index ba2d3679a46d..d5aa393dbc0b 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
> @@ -86,6 +86,7 @@ [Pcd]
>
>  [FeaturePcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
> +  gUefiOvmfPkgTokenSpaceGuid.PcdMemVarstoreEmuEnable
>
>  [Depex]
>TRUE
> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c 
> b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
> index 5677b5ee119c..60bc7a84bd6b 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
> @@ -246,6 +246,7 @@ QemuFlashInitialize (
>
>if (!QemuFlashDetected ()) {
>  ASSERT (!FeaturePcdGet (PcdSmmSmramRequire));
> +ASSERT (FeaturePcdGet (PcdMemVarstoreEmuEnable));
>  return EFI_WRITE_PROTECTED;
>}
>
> --
> 2.14.1.3.gb7cf6e02401b
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2 1/8] OvmfPkg: introduce PcdMemVarstoreEmuEnable feature flag

2017-12-01 Thread Ard Biesheuvel
On 30 November 2017 at 16:30, Laszlo Ersek  wrote:
> ... and the corresponding MEM_VARSTORE_EMU_ENABLE build define, which
> defaults to TRUE.
>
> Setting the build flag to FALSE will later enable the exclusion of the
> dynamically allocated, emulated, in-memory varstore.
>
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>  OvmfPkg/OvmfPkg.dec| 6 ++
>  OvmfPkg/OvmfPkgIa32.dsc| 4 
>  OvmfPkg/OvmfPkgIa32X64.dsc | 4 
>  OvmfPkg/OvmfPkgX64.dsc | 4 
>  4 files changed, 18 insertions(+)
>
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 27bcfc141e5a..f03dd7e27d6b 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -150,3 +150,9 @@ [PcdsFeatureFlag]
>#  runtime OS from tampering with firmware structures (special memory 
> ranges
>#  used by OVMF, the varstore pflash chip, LockBox etc).
>gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|FALSE|BOOLEAN|0x1e
> +
> +  ## This feature flag reports whether in-memory (that is, non-flash) 
> variable
> +  #  emulation is enabled. Note that with PcdSmmSmramRequire set to TRUE, 
> this
> +  #  setting is irrelevant, as SMM/SMRAM support always requires flash
> +  #  variables.
> +  gUefiOvmfPkgTokenSpaceGuid.PcdMemVarstoreEmuEnable|TRUE|BOOLEAN|3
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 9d23f8c162e4..443da553d0a3 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -39,6 +39,7 @@ [Defines]
>DEFINE HTTP_BOOT_ENABLE= FALSE
>DEFINE SMM_REQUIRE = FALSE
>DEFINE TLS_ENABLE  = FALSE
> +  DEFINE MEM_VARSTORE_EMU_ENABLE = TRUE
>
>#
># Flash size selection. Setting FD_SIZE_IN_KB on the command line directly 
> to
> @@ -410,6 +411,9 @@ [PcdsFeatureFlag]
>gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
>  !endif
> +!if $(MEM_VARSTORE_EMU_ENABLE) == FALSE
> +  gUefiOvmfPkgTokenSpaceGuid.PcdMemVarstoreEmuEnable|FALSE
> +!endif
>
>  [PcdsFixedAtBuild]
>gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index a9c667fed8b0..0fc81743bac4 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -39,6 +39,7 @@ [Defines]
>DEFINE HTTP_BOOT_ENABLE= FALSE
>DEFINE SMM_REQUIRE = FALSE
>DEFINE TLS_ENABLE  = FALSE
> +  DEFINE MEM_VARSTORE_EMU_ENABLE = TRUE
>
>#
># Flash size selection. Setting FD_SIZE_IN_KB on the command line directly 
> to
> @@ -415,6 +416,9 @@ [PcdsFeatureFlag]
>gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
>  !endif
> +!if $(MEM_VARSTORE_EMU_ENABLE) == FALSE
> +  gUefiOvmfPkgTokenSpaceGuid.PcdMemVarstoreEmuEnable|FALSE
> +!endif
>
>  [PcdsFixedAtBuild]
>gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index abf570512a38..db33be4bc0b7 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -39,6 +39,7 @@ [Defines]
>DEFINE HTTP_BOOT_ENABLE= FALSE
>DEFINE SMM_REQUIRE = FALSE
>DEFINE TLS_ENABLE  = FALSE
> +  DEFINE MEM_VARSTORE_EMU_ENABLE = TRUE
>
>#
># Flash size selection. Setting FD_SIZE_IN_KB on the command line directly 
> to
> @@ -415,6 +416,9 @@ [PcdsFeatureFlag]
>gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
>  !endif
> +!if $(MEM_VARSTORE_EMU_ENABLE) == FALSE
> +  gUefiOvmfPkgTokenSpaceGuid.PcdMemVarstoreEmuEnable|FALSE
> +!endif
>
>  [PcdsFixedAtBuild]
>gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
> --
> 2.14.1.3.gb7cf6e02401b
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2 0/8] OvmfPkg: add the Variable PEIM, defragment the UEFI memmap

2017-12-01 Thread Ard Biesheuvel
On 30 November 2017 at 19:00, Jordan Justen  wrote:
> As I recall, this enables a modest (non-essential) improvement in
> fragmentation, at the cost of more ways to configure OVMF to hang
> during boot. (With info available via debugcon.)
>
> I would prefer if were able to always fallback and continue boot.
> Later, after GOP has started we could visibly warn the user that they
> haven't properly enabled SMM and/or flash.
>
> If we had a way to do this, I would be in favor of displaying an error
> message and delaying for 30 seconds before booting if flash has not
> been enabled. (Or, if SMM was enabled in the build, but not set on the
> command line.)
>
> At that point, I think we could start to transition to making flash an
> boot requirement for OVMF. But first we need to be able to visibly
> warn the user why they are not able to boot.
>

That doesn't argue against this series, does it? AFAICT it only argues
against building OVMF with a non-default value for
MEM_VARSTORE_EMU_ENABLE


> On 2017-11-30 08:30:21, Laszlo Ersek wrote:
>> Repo:   https://github.com/lersek/edk2.git
>> Branch: memmap_defrag_v2
>>
>> This version is identical to the v1 seres I posted in March. Some
>> patches of the v1 series have been committed. I've been rebasing and
>> using the rest since, and am now posting it as v2. References:
>>
>> * https://bugzilla.tianocore.org/show_bug.cgi?id=386
>>
>> * http://mid.mail-archive.com/20170314233246.17864-1-lersek@redhat.com
>>   https://lists.01.org/pipermail/edk2-devel/2017-March/008525.html
>>
>> * 
>> http://mid.mail-archive.com/20170327080544.24748-1-jordan.l.justen@intel.com
>>   https://lists.01.org/pipermail/edk2-devel/2017-March/009049.html
>>
>> Cc: Anthony Perard 
>> Cc: Ard Biesheuvel 
>> Cc: Jordan Justen 
>> Cc: Julien Grall 
>>
>> Thanks
>> Laszlo
>>
>> Laszlo Ersek (8):
>>   OvmfPkg: introduce PcdMemVarstoreEmuEnable feature flag
>>   OvmfPkg/QemuFlashFvbServicesRuntimeDxe: check PcdMemVarstoreEmuEnable
>>   OvmfPkg: conditionally disable reserved memory varstore emulation at
>> build
>>   OvmfPkg: introduce FlashNvStorageAddressLib
>>   OvmfPkg: include FaultTolerantWritePei and VariablePei
>>   OvmfPkg/QemuFlashFvbServicesRuntimeDxe: don't set flash PCDs if SMM or
>> no-emu
>>   OvmfPkg/PlatformPei: remedy UEFI memory map fragmentation
>>   OvmfPkg/README: document MEM_VARSTORE_EMU_ENABLE and memmap defrag
>>
>>  OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c   |  53 
>> +++
>>  OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf |  48 
>> +++
>>  OvmfPkg/OvmfPkg.dec   |   6 
>> +
>>  OvmfPkg/OvmfPkgIa32.dsc   |  15 
>> +-
>>  OvmfPkg/OvmfPkgIa32.fdf   |   8 
>> +-
>>  OvmfPkg/OvmfPkgIa32X64.dsc|  15 
>> +-
>>  OvmfPkg/OvmfPkgIa32X64.fdf|   8 
>> +-
>>  OvmfPkg/OvmfPkgX64.dsc|  15 
>> +-
>>  OvmfPkg/OvmfPkgX64.fdf|   8 
>> +-
>>  OvmfPkg/PlatformPei/MemTypeInfo.c | 151 
>> 
>>  OvmfPkg/PlatformPei/Platform.c|  26 
>> +---
>>  OvmfPkg/PlatformPei/Platform.h|   5 
>> +
>>  OvmfPkg/PlatformPei/PlatformPei.inf   |   3 
>> +
>>  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf  |   1 
>> +
>>  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf |   1 
>> +
>>  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c   |  58 
>> +---
>>  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c|   1 
>> +
>>  OvmfPkg/README|  10 
>> ++
>>  18 files changed, 385 insertions(+), 47 deletions(-)
>>  create mode 100644 
>> OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.c
>>  create mode 100644 
>> OvmfPkg/Library/FlashNvStorageAddressLib/FlashNvStorageAddressLib.inf
>>  create mode 100644 OvmfPkg/PlatformPei/MemTypeInfo.c
>>
>> --
>> 2.14.1.3.gb7cf6e02401b
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [Patch 2/2] NetworkPkg/Dhcp6Dxe: Check Media status before starting DHCP process.

2017-12-01 Thread Jiaxin Wu
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Karunakar P 
Signed-off-by: Wu Jiaxin 
---
 NetworkPkg/Dhcp6Dxe/Dhcp6Impl.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/NetworkPkg/Dhcp6Dxe/Dhcp6Impl.c b/NetworkPkg/Dhcp6Dxe/Dhcp6Impl.c
index d8c0ad0..1107865 100644
--- a/NetworkPkg/Dhcp6Dxe/Dhcp6Impl.c
+++ b/NetworkPkg/Dhcp6Dxe/Dhcp6Impl.c
@@ -1,9 +1,9 @@
 /** @file
   This EFI_DHCP6_PROTOCOL interface implementation.
 
-  Copyright (c) 2009 - 2012, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved.
 
   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.
@@ -74,10 +74,11 @@ EfiDhcp6Start (
 {
   EFI_STATUS   Status;
   EFI_TPL  OldTpl;
   DHCP6_INSTANCE   *Instance;
   DHCP6_SERVICE*Service;
+  BOOLEAN  MediaPresent;
 
   if (This == NULL) {
 return EFI_INVALID_PARAMETER;
   }
 
@@ -99,10 +100,21 @@ EfiDhcp6Start (
   if (Instance->IaCb.Ia->State != Dhcp6Init) {
 return EFI_ALREADY_STARTED;
   }
 
   OldTpl   = gBS->RaiseTPL (TPL_CALLBACK);
+
+  //
+  // Check Media Satus.
+  //
+  MediaPresent = TRUE;
+  NetLibDetectMedia (Service->Controller, );
+  if (!MediaPresent) {
+Status = EFI_NO_MEDIA;
+goto ON_ERROR;
+  }
+
   Instance->UdpSts = EFI_ALREADY_STARTED;
 
   //
   // Send the solicit message to start S.A.R.R process.
   //
-- 
1.9.5.msysgit.1

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


[edk2] [Patch 0/2] Check Media status before starting DHCP process.

2017-12-01 Thread Jiaxin Wu
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Karunakar P 
Signed-off-by: Wu Jiaxin 

Jiaxin Wu (2):
  MdeModulePkg/Dhcp4Dxe: Check Media status before starting DHCP
process.
  NetworkPkg/Dhcp6Dxe: Check Media status before starting DHCP process.

 MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c | 13 -
 NetworkPkg/Dhcp6Dxe/Dhcp6Impl.c | 14 +-
 2 files changed, 25 insertions(+), 2 deletions(-)

-- 
1.9.5.msysgit.1

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


[edk2] [Patch 1/2] MdeModulePkg/Dhcp4Dxe: Check Media status before starting DHCP process.

2017-12-01 Thread Jiaxin Wu
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Karunakar P 
Signed-off-by: Wu Jiaxin 
---
 MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c 
b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
index 1db4c66..8780414 100644
--- a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
+++ b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
@@ -1,9 +1,9 @@
 /** @file
   This file implement the EFI_DHCP4_PROTOCOL interface.
 
-Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
 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
 
@@ -778,10 +778,11 @@ EfiDhcp4Start (
   IN EFI_EVENT  CompletionEvent   OPTIONAL
   )
 {
   DHCP_PROTOCOL *Instance;
   DHCP_SERVICE  *DhcpSb;
+  BOOLEAN   MediaPresent;
   EFI_STATUSStatus;
   EFI_TPL   OldTpl;
 
   //
   // First validate the parameters
@@ -807,10 +808,20 @@ EfiDhcp4Start (
   if ((DhcpSb->DhcpState != Dhcp4Init) && (DhcpSb->DhcpState != 
Dhcp4InitReboot)) {
 Status = EFI_ALREADY_STARTED;
 goto ON_ERROR;
   }
 
+  //
+  // Check Media Satus.
+  //
+  MediaPresent = TRUE;
+  NetLibDetectMedia (DhcpSb->Controller, );
+  if (!MediaPresent) {
+Status = EFI_NO_MEDIA;
+goto ON_ERROR;
+  }
+
   DhcpSb->IoStatus = EFI_ALREADY_STARTED;
 
   if (EFI_ERROR (Status = DhcpInitRequest (DhcpSb))) {
 goto ON_ERROR;
   }
-- 
1.9.5.msysgit.1

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


Re: [edk2] DHCP Process Starts Even there is NO Media Connected

2017-12-01 Thread Wu, Jiaxin
Thanks Karunakar, we suggest you create the patches as attached files. Then you 
can send it to 'edk2-devel@lists.01.org' directly with GIT command:):

git send-email xxx.patch xxx.patch xxx.patch 
--to=edk2-devel@lists.01.org --force

Thanks,
Jiaxin

> -Original Message-
> From: Karunakar P [mailto:karunak...@amiindia.co.in]
> Sent: Friday, December 1, 2017 2:05 PM
> To: Wu, Jiaxin ; Richardson, Brian
> ; Fu, Siyuan ; Ye, Ting
> ; 'edk2-devel@lists.01.org' 
> Subject: RE: DHCP Process Starts Even there is NO Media Connected
> 
> Please review the patch
> 
> [Patch] MdeModulePkg/Universal/Network/Dhcp4Dxe: Implantation of
> handling EFI_NO_MEDIA status code for DHCP4/6.Start()
> NetworkPkg/Dhcp6Dxe :  Implantation of handling EFI_NO_MEDIA status
> code for DHCP4/6.Start()
> 
> MdeModulePkg/Universal/Network/Dhcp4Dxe/ Dhcp4Impl.c | 11
> NetworkPkg/Dhcp6Dxe/ Dhcp6Impl.c |  11
> 2 files changed, 22 insertions(+)
> 
> a. MdeModulePkg/Universal/Network/Dhcp4Dxe/ Dhcp4Impl.c
> b. NetworkPkg/Dhcp6Dxe/ Dhcp6Impl.c
> 
> 
> a@ EfiDhcp4Start (
>   IN EFI_DHCP4_PROTOCOL *This,
>   IN EFI_EVENT  CompletionEvent   OPTIONAL
>   )
> {
>   DHCP_PROTOCOL *Instance;
>   DHCP_SERVICE  *DhcpSb;
>   EFI_STATUSStatus;
>   EFI_TPL   OldTpl;
> + BOOLEAN   MediaPresent;
> .
> .
> .
> OldTpl  = gBS->RaiseTPL (TPL_CALLBACK);
>  DhcpSb  = Instance->Service;
> 
> +  //
> + // Check media status before DHCP Start.
> +  //
> +  MediaPresent = TRUE;
> +  NetLibDetectMedia (DhcpSb->Controller, );
> +  if (!MediaPresent) {
> +Status = EFI_NO_MEDIA;
> + DEBUG((DEBUG_ERROR,"\nIn EfiDhcp4Start  MediaPresent Status
> = %r\n",Status));
> +goto ON_ERROR;
> + }
> 
>   if (DhcpSb->DhcpState == Dhcp4Stopped) {
> Status = EFI_NOT_STARTED;
> goto ON_ERROR;
>   }
> .
> .
> .
> }
> 
> 
> b @ EfiDhcp6Start (
>   IN EFI_DHCP6_PROTOCOL*This
>   )
> {
>   EFI_STATUS   Status;
>   EFI_TPL  OldTpl;
>   DHCP6_INSTANCE   *Instance;
>   DHCP6_SERVICE*Service;
> +  BOOLEAN  MediaPresent;
> .
> .
> .
> OldTpl   = gBS->RaiseTPL (TPL_CALLBACK);
> Instance->UdpSts = EFI_ALREADY_STARTED;
> 
> +  //
> +  // Check media status before DHCP Start.
> +  //
> +  MediaPresent = TRUE;
> +  NetLibDetectMedia (Service->Controller, );
> +  if (!MediaPresent) {
> +Status = EFI_NO_MEDIA;
> +DEBUG((DEBUG_ERROR,"\nIn EfiDhcp6Start  MediaPresent Status
> = %r\n",Status));
> +goto ON_ERROR;
> +  }
> 
>   //
>   // Send the solicit message to start S.A.R.R process.
>   //
>   Status = Dhcp6SendSolicitMsg (Instance);
> .
> .
> .
> }
> 
> 
> Thanks,
> Karunakar
> 
> -Original Message-
> From: Karunakar P
> Sent: Friday, December 01, 2017 11:10 AM
> To: 'Wu, Jiaxin'; Richardson, Brian; Fu, Siyuan; Ye, Ting; 'edk2-
> de...@lists.01.org'
> Subject: RE: DHCP Process Starts Even there is NO Media Connected
> 
> Hi Jiaxin,
> 
> I've updated the patch changes for Dhcp6Dxe driver also and attached the
> same for review.
> 
> Filed a tracker in TianoCore Bugzilla for this issue and attached the changes
> for review,
> https://bugzilla.tianocore.org/show_bug.cgi?id=804
> 
> Thanks,
> Karunakar
> 
> -Original Message-
> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Friday, December 01, 2017 9:15 AM
> To: Richardson, Brian; Karunakar P; Fu, Siyuan; Ye, Ting; 'edk2-
> de...@lists.01.org'
> Subject: RE: DHCP Process Starts Even there is NO Media Connected
> 
> Hi Karunakar,
> 
> Per your question #3.c, I think it's *unreasonable* to check Media Status for
> EFI_IP4_CONFIG2_SET_DATA.
> 
> Even there is no media connected, we still need to set the data instead of
> return directly. If the EFI_IP4_CONFIG2_SET_DATA.SetData() is to set the
> DHCP policy, the SetData() interface will try to do the DHCP process to get
> one valid default address, but if there is any failure happen in DHCP process
> (e.g. no media connected), we should continue change the policy to DHCP
> and return EFI_SUCCESS, which align with static policy. So, I don't prefer to
> check the Media Status in EFI_IP4_CONFIG2_SET_DATA.SetData().
> 
> I have reviewed your patch, the Dhcp4Dxe update is good to me. Can you
> send out the formal patch to the EDK2 community for the review or need us
> do to that? Note: don't forget to update the Dhcp6Dxe driver.
> 
> Also thanks Brain's reminder, please file a tracker in TianoCore Bugzilla for
> this issue.
> 
> Thanks,
> Jiaxin
> 
> > -Original Message-
> > From: Richardson, Brian
> > Sent: Thursday, November 30, 2017 11:02 PM
> > To: Karunakar P ; Wu, Jiaxin
> > ; Fu, Siyuan ; Ye, Ting
> > ; 'edk2-devel@lists.01.org'
> >