Re: [edk2] Build SCT with edk2

[Udit Kumar]

> It seems building SCT is supported with edk2 UDK2017 and not something
SCT build fails on UDK2017 as well 

Below is patch suggested by Supreet with UDK2017 

tmp/sct_workspace/edk2$ git diff

diff --git a/BaseTools/Source/C/Makefiles/app.makefile 
b/BaseTools/Source/C/Makefiles/app.makefile
index e414551b4a..6017b2dd59 100644
--- a/BaseTools/Source/C/Makefiles/app.makefile
+++ b/BaseTools/Source/C/Makefiles/app.makefile
@@ -23,6 +23,6 @@ all: $(MAKEROOT)/bin $(APPLICATION)
$(APPLICATION): $(OBJECTS)
$(LINKER) -o $(APPLICATION) $(BUILD_LFLAGS) $(OBJECTS) 
-L$(MAKEROOT)/libs $(LIBS)

-$(OBJECTS): ../Include/Common/BuildVersion.h
+$(OBJECTS): $(MAKEROOT)/Include/Common/BuildVersion.h

Regards
Udit 

> -Original Message-
> From: edk2-devel  On Behalf Of Ashish
> Singhal
> Sent: Thursday, March 28, 2019 1:40 AM
> To: edk2-devel@lists.01.org
> Cc: Eric Jin 
> Subject: [edk2] Build SCT with edk2
> 
> Hello,
> 
> It seems building SCT is supported with edk2 UDK2017 and not something
> recent. When I tried building it with tip, it fails. Is someone already 
> working
> on making sure SCT can be built with edk2 tip?
> 
> Thanks
> Ashish
> 
> ---
> This email message is for the sole use of the intended recipient(s) and may
> contain confidential information.  Any unauthorized review, use, disclosure
> or distribution is prohibited.  If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message.
> ---
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.0
> 1.org%2Fmailman%2Flistinfo%2Fedk2-
> develdata=02%7C01%7Cudit.kumar%40nxp.com%7C316c2d64dd8e47
> 99dd5308d6b2f03a7a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
> 7C636893142185731611sdata=sA%2F9u6YP5HyMt6w%2BfenjQhtibS5
> ZaqHGlYJZWJbw0CI%3Dreserved=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 4/4] ArmPkg/GenericWatchdogDxe: implement RegisterHandler() method

[Udit Kumar]

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Tuesday, December 18, 2018 6:40 PM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Leif Lindholm
> ; Sami Mujawar ; Thomas
> Panakamattam Abraham ; Meenakshi Aggarwal
> ; Udit Kumar ; Matteo
> Carlini ; Nariman Poushin
> 
> Subject: [PATCH 4/4] ArmPkg/GenericWatchdogDxe: implement
> RegisterHandler() method
> 
> Even though UEFI does not appear to use it, let's implement the complete PI
> watchdog protocol, including handler registration, which will be invoked 
> instead
> of the ResetSystem() runtime service when the watchdog timer expires.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.c | 34
> ++--
>  1 file changed, 25 insertions(+), 9 deletions(-)
> 
> diff --git a/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.c
> b/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.c
> index 717a180a64ec..21118a3c88d1 100644
> --- a/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.c
> +++ b/ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.c
> @@ -42,6 +42,7 @@ STATIC UINTN mTimerFrequencyHz = 0;  STATIC UINT64
> mNumTimerTicks = 0;
> 
>  STATIC EFI_HARDWARE_INTERRUPT2_PROTOCOL *mInterruptProtocol;
> +STATIC EFI_WATCHDOG_TIMER_NOTIFYmWatchdogNotify;
> 
>  STATIC
>  VOID
> @@ -107,17 +108,25 @@ WatchdogInterruptHandler (
>)
>  {
>STATIC CONST CHAR16 ResetString[]= L"The generic watchdog timer ran out.";
> +  UINT64  TimerPeriod;
> 
>WatchdogDisable ();
> 
>mInterruptProtocol->EndOfInterrupt (mInterruptProtocol, Source);
> 
> -  gRT->ResetSystem (
> - EfiResetCold,
> - EFI_TIMEOUT,
> - StrSize (ResetString),
> - (VOID *) 
> - );
> +  //
> +  // The notify function should be called with the elapsed number of
> + ticks  // since the watchdog was armed, which should exceed the timer 
> period.
> +  // We don't actually know the elapsed number of ticks, so let's
> + return  // the timer period plus 1.
> +  //
> +  if (mWatchdogNotify != NULL) {
> +TimerPeriod = ((TIME_UNITS_PER_SECOND / mTimerFrequencyHz) *
> mNumTimerTicks);
> +mWatchdogNotify (TimerPeriod + 1);
> +  } else {
> +gRT->ResetSystem (EfiResetCold, EFI_TIMEOUT, StrSize (ResetString),
> +   (CHAR16 *)ResetString);
> +  }

Here too, please handle reset in all cases 
 
>// If we got here then the reset didn't work
>ASSERT (FALSE);
> @@ -155,9 +164,16 @@ WatchdogRegisterHandler (
>IN EFI_WATCHDOG_TIMER_NOTIFYNotifyFunction
>)
>  {
> -  // ERROR: This function is not supported.
> -  // The watchdog will reset the board
> -  return EFI_UNSUPPORTED;
> +  if (mWatchdogNotify == NULL && NotifyFunction == NULL) {
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  if (mWatchdogNotify != NULL && NotifyFunction != NULL) {
> +return EFI_ALREADY_STARTED;
> +  }
> +
> +  mWatchdogNotify = NotifyFunction;
> +  return EFI_SUCCESS;
>  }
> 
>  /**
> --
> 2.17.1

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

Re: [edk2] [PATCH 2/4] ArmPlatformPkg/SP805WatchdogDxe: switch to interrupt mode

[Udit Kumar]

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Tuesday, December 18, 2018 6:40 PM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Leif Lindholm
> ; Sami Mujawar ; Thomas
> Panakamattam Abraham ; Meenakshi Aggarwal
> ; Udit Kumar ; Matteo
> Carlini ; Nariman Poushin
> 
> Subject: [PATCH 2/4] ArmPlatformPkg/SP805WatchdogDxe: switch to interrupt
> mode
> 
> The SP805 watchdog driver doesn't implement the PI watchdog protocol fully,
> but always simply resets the system if the watchdog time runs out.
> 
> However, the hardware does support the intended usage model, as long as the
> SP805 is wired up correctly. So let's implement interrupt based mode 
> involving a
> handler that is registered by the DXE core and invoked when the watchdog runs
> out. In the interrupt handler, we invoke the notify function if one was 
> registered,
> or call the ResetSystem() runtime service otherwise (as per the UEFI spec)

Specs, says 
If no handler has been registered, or the registered handler returns, then the 
system will be reset by calling the Runtime Service ResetSystem().
My understanding is that we have to ResetSystem() always irrespective of notify 
function

 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPlatformPkg/ArmPlatformPkg.dec|  1 +
>  ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805Watchdog.c  | 95
> ++--
>  ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf |  6 +-
>  3 files changed, 75 insertions(+), 27 deletions(-)
> 
> diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec
> b/ArmPlatformPkg/ArmPlatformPkg.dec
> index 5f67e7415469..44c00bd0c133 100644
> --- a/ArmPlatformPkg/ArmPlatformPkg.dec
> +++ b/ArmPlatformPkg/ArmPlatformPkg.dec
> @@ -70,6 +70,7 @@
>## SP805 Watchdog
> 
> gArmPlatformTokenSpaceGuid.PcdSP805WatchdogBase|0x0|UINT32|0x00
> 23
> 
> gArmPlatformTokenSpaceGuid.PcdSP805WatchdogClockFrequencyInHz|32000|
> UINT32|0x0021
> +
> +
> gArmPlatformTokenSpaceGuid.PcdSP805WatchdogInterrupt|0|UINT32|0x
> 00
> + 2E
> 
>## PL011 UART
> 
> gArmPlatformTokenSpaceGuid.PL011UartClkInHz|2400|UINT32|0x00
> 1F
> diff --git a/ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805Watchdog.c
> b/ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805Watchdog.c
> index 12c2f0a1fe49..4f09acf1fa28 100644
> --- a/ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805Watchdog.c
> +++ b/ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805Watchdog.c
> @@ -21,12 +21,17 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
> +#include 
>  #include 
> 
>  #include "SP805Watchdog.h"
> 
> -STATIC EFI_EVENT  mEfiExitBootServicesEvent;
> +STATIC EFI_EVENTmEfiExitBootServicesEvent;
> +STATIC EFI_HARDWARE_INTERRUPT_PROTOCOL  *mInterrupt;
> +STATIC EFI_WATCHDOG_TIMER_NOTIFYmWatchdogNotify;
> +STATIC UINT32   mTimerPeriod;
> 
>  /**
>Make sure the SP805 registers are unlocked for writing.
> @@ -65,6 +70,33 @@ SP805Lock (
>}
>  }
> 
> +STATIC
> +VOID
> +EFIAPI
> +SP805InterruptHandler (
> +  IN  HARDWARE_INTERRUPT_SOURCE   Source,
> +  IN  EFI_SYSTEM_CONTEXT  SystemContext
> +  )
> +{
> +  //
> +  // The notify function should be called with the elapsed number of
> +ticks
> +  // since the watchdog was armed, which should exceed the timer period.
> +  // We don't actually know the elapsed number of ticks, so let's
> +return
> +  // the timer period plus 1.
> +  //
> +  if (mWatchdogNotify != NULL) {
> +mWatchdogNotify (mTimerPeriod + 1);
> +  } else {
> +gRT->ResetSystem (EfiResetCold, EFI_TIMEOUT, 0, NULL);
> +  }

Shouldn't we ResetSystem in all cases.
 

> +
> +  SP805Unlock ();
> +  MmioWrite32 (SP805_WDOG_INT_CLR_REG, 0); // write of any value clears
> + the irq  SP805Lock ();
> +
> +  mInterrupt->EndOfInterrupt (mInterrupt, Source); }
> +

IMO, this routine should be 
1/ Handle IT
2/ Do callback mWatchdogNotify
3/ Reset the system.

>  /**
>Stop the SP805 watchdog timer from counting down by disabling interrupts.
>  **/
> @@ -149,9 +181,16 @@ SP805RegisterHandler (
>IN EFI_WATCHDOG_TIMER_NOTIFYNotifyFunction
>)
>  {
> -  // ERROR: This function is not supported.
> -  // The hardware watchdog will reset the board
> -  return EFI_INVALID_PARAMETER;
> +  if (mWatchdogNotify == NULL && NotifyFunction == NULL) {
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  if (mWatchdogNotify != NULL && NotifyFunction != NULL) {
> +return EFI_ALREADY_STARTED;
> +  }
> +
> +  mWatchd

Re: [edk2] SP805 driver

[Udit Kumar]

> > > > Coming back to hardware, which does not have mask around wdt, how
> > > > to implement this feature.
> > >
> > > Simple - you can't.
> > >
> > > You can absolutely implement exactly the functionality you have
> > > today, with minimal changes to the protocol - it just should not be
> > > registered as an implementation of
> EFI_WATCHDOG_TIMER_ARCH_PROTOCOL.
> >
> > I believe,  EFI_WATCHDOG_TIMER_ARCH_PROTOCOL is must Are you
> > suggesting to EFI_WATCHDOG_TIMER_ARCH_PROTOCOL from
> MdeModulePkg and
> > hook platform specific code with this.
> > Or simply register EFI_WATCHDOG_TIMER_ARCH_PROTOCOL with dummy
> functions.
> 
> Are you referring to
> MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf?

Yes !! 
 
> That is certainly what most of the platforms in edk2-platforms use.
> 
> The EFI_WATCHDOG_TIMER_ARCH_PROTOCOL is used by core code.
> 
> If you want to use your hardware watchdog as part of your platform specific
> code, that is absolutely fine and probably a very good idea - but it has 
> nothing to
> do with this protocol.  There is nothing forcing you to use the platform-
> independent EFI_WATCHDOG_TIMER_ARCH_PROTOCOL for this.

Yes, this was idea to use 
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
and if needed, install a custom protocol for hardware wdt. And this to be used 
by platform specific code.

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

Re: [edk2] SP805 driver

[Udit Kumar]

> -Original Message-
> From: Leif Lindholm 
> Sent: Tuesday, December 18, 2018 2:56 PM


> 
> On Tue, Dec 18, 2018 at 05:20:59AM +0000, Udit Kumar wrote:
> > Thanks for note Leif,
> >
> > I am trying to understand this behavior  of specification.
> >
> > >"If no handler has been registered, or the registered handler
> > >returns, then the system will be reset by calling the Runtime Service
> > >ResetSystem()."
> > I believe,  this handler needs to be called by wdt driver after wdt is
> > expired. Meaning , we want wdt to work without resetting the system.
> > Therefore a mask is needed with wdt, which will prevent to reset the
> > system.   I see it working, at least for SP805, because of PMU mask
> > bits.
> 
> Yes, if the WDT can be configured to generate an interrupt instead of a
> hardware reset, it can be used to implement this protocol.

Here I am just thinking of one condition , some application started the wdt
and CPU got stuck somewhere in ISR routine, 
Now this wdt is expired. We will end up in hang system. 
I agree doing reset in graceful manner is always great, but In this case, 
resetting the 
as it is, will be more useful. 

Thought ? 
 
> > Also ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.c has this
> limitation.
> > I haven’t read spec of this wdt.  I hope there should a mask around.
> 
> No, the situation for the GenericWatchdogDxe is not as dire.
> 
> Correct: it does not permit registering software handlers (which perhaps we
> should do something about, but is ... acceptable).
> 
> _But_, it still conforms to the above text; when the timer expires, it resets 
> the
> system by calling the ResetSystem() service. It does not directly force a
> hardware reset.

Hmm, this does partly by calling  ResetSystem(), however this does not 
Allow to install handler in WatchdogRegisterHandler.

> The severe problem is not the lack of the ability to register the software 
> handler
> (which does remove much of the utility), but the removal of reset control from
> the system firmware.
> 
> > Coming back to hardware, which does not have mask around wdt, how to
> > implement this feature.
> 
> Simple - you can't.
> 
> You can absolutely implement exactly the functionality you have today, with
> minimal changes to the protocol - it just should not be registered as an
> implementation of EFI_WATCHDOG_TIMER_ARCH_PROTOCOL.

I believe,  EFI_WATCHDOG_TIMER_ARCH_PROTOCOL is must 
Are you suggesting to EFI_WATCHDOG_TIMER_ARCH_PROTOCOL from MdeModulePkg
and hook platform specific code with this.
Or simply register EFI_WATCHDOG_TIMER_ARCH_PROTOCOL with dummy functions.

> Then your platform code can invoke this custom protocol as needed.
 
> Regards,
> 
> Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] SP805 driver

[Udit Kumar]

Thanks for note Leif,

I am trying to understand this behavior  of specification.

>"If no handler has been registered, or the registered handler returns, then 
>the system will be reset by calling the Runtime Service ResetSystem()."
I believe,  this handler needs to be called by wdt driver after wdt is expired. 
Meaning , we want wdt to work without resetting the system.
Therefore a mask is needed with wdt, which will prevent to reset the system.   
I see it working, at least for SP805, because of PMU mask bits.

Also ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.c has this limitation.
I haven’t read spec of this wdt.  I hope there should a mask around.

Coming back to hardware, which does not have mask around wdt, how to implement 
this feature.


Regards
Udit


From: Leif Lindholm 
Sent: Monday, December 17, 2018 6:25 PM
To: Sami Mujawar ; Thomas Panakamattam Abraham 

Cc: Meenakshi Aggarwal ; Udit Kumar 
; Ard Biesheuvel ; edk2-devel 
(edk2-devel@lists.01.org) ; Ming Huang 
; Heyi Guo ; Matteo Carlini 
; Nariman Poushin 
Subject: SP805 driver

Hi Sami, Thomas, (and others on cc)

NXP are upstreaming a set containing an implementation of
EFI_WATCHDOG_TIMER_ARCH_PROTOCOL using a hardware watchdog as backing.
This idea comes from the SP805 driver ArmPlatformPkg/Drivers/SP805WatchdogDxe, 
which does the same.

The problem is that this is a horrible idea. The point of the 
EFI_WATCHDOG_TIMER_ARCH_PROTOCOL is that it lets you schedule software events 
when the watchdog timer expires. However, the SP805 driver does not let you do 
this:

EFI_STATUS
EFIAPI
SP805RegisterHandler (
  IN CONST EFI_WATCHDOG_TIMER_ARCH_PROTOCOL   *This,
  IN EFI_WATCHDOG_TIMER_NOTIFYNotifyFunction
  )
{
  // ERROR: This function is not supported.
  // The hardware watchdog will reset the board
  return EFI_INVALID_PARAMETER;
}

From section 12.14 of the PI 1.6 spec:
"If no handler has been registered, or the registered handler returns, then the 
system will be reset by calling the Runtime Service ResetSystem()."
Blatantly, any driver that does the above (and initializes hardware that will 
reset the system without software control) will violate this.

Meanwhile, the only two ARM platforms that include this driver are TC2 and FVP.

Now, NXP are not at fault for following examples given to them in the reference 
ARM driver section - but can we please keep further people from making the same 
mistake?
So my question to {Sami|Thomas} is - can we nuke this driver, and if so, can 
you provide the patches to remove it from edk2 and the resulting ones needed 
for edk2-platforms?

I have no issues with reintroducing a fixed SP805 driver in the future that 
does not claim to conform to the above protocol.

Finally - both the D03 and D05 platform .dsc files, as well as the Hisilicon 
ArmPlatformLib, contain references to it. (Ming/Heyi - please provide a patch.)

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

Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot

[Udit Kumar]

Hi Ard 

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Monday, December 3, 2018 7:35 PM
> To: Laszlo Ersek 
> Cc: Udit Kumar ; Andrew Fish ; Leif
> Lindholm ; Ruiyu Ni ; edk2-
> de...@lists.01.org; Zeng, Star 
> Subject: Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot
> 
> On Mon, 3 Dec 2018 at 14:45, Laszlo Ersek  wrote:
> >
> > On 12/03/18 11:03, Udit Kumar wrote:
> > > Hi Laszlo
> > >
> > >> Are you using the latest edk2?
> > > Yes, when I hit the bug, first step was to move to latest edk2. But this 
> > > didn't
> helped.
> > >
> > > I am not sure, why we are keeping PL011 Fifo mode off in default
> configuration.
> >
> > Sorry, I don't know: although the subject logic has gone through
> > several updates over time, the default that you point out seems to go
> > back to commit 051e63bb551a ("ArmPlatformPkg/PL011Uart: Allowed to
> > change UART settings in its initialization function", 2012-02-29). And
> > that commit doesn't explain the default.
> >
> 
> The default setting for
> gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth is 1 not 0, and so
> you will end up with a 1 character FIFO setting. I wonder if we could improve

Setting this Pcd to zero will fix problem for me, 
With  PcdUartDefaultReceiveFifoDepth as 1, we are disabling the Fifo at IP 
level whereas for 0 we are enabling IP fifo.

> PL011UartInitializePort () in PL011UartLib to deal with this better.

Suggest, if IP level Fifo can be kept enabled, always ?

> Note that this also affects platforms that can switch between DT and ACPI 
> boot:
> the same PL011 is described as a 'dumb' SBSA uart in the latter case, and so 
> it is
> up to the firmware to configure the UART FIFO correctly, or you will not be 
> able
> to use the UART under the ACPI OS.

For my ACPI boot (without SPCR table), I hit the same issue.

OS  (Linux, not sure of other OSes) except FIFO to be enabled by 
firmware/boot-loader. 

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

Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot

[Udit Kumar]

Hi Laszlo 

> Are you using the latest edk2?
Yes, when I hit the bug, first step was to move to latest edk2. But this didn't 
helped.

I am not sure, why we are keeping PL011 Fifo mode off in default configuration. 
 

Regards
Udit

> -Original Message-
> From: Laszlo Ersek 
> Sent: Monday, December 3, 2018 3:27 PM
> To: Udit Kumar ; af...@apple.com
> Cc: Ni, Ruiyu ; edk2-devel@lists.01.org; Zeng, Star
> 
> Subject: Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot
> 
> On 11/30/18 10:13, Udit Kumar wrote:
> > Thanks Laszlo/Andrew
> > Finally I manage to get logs from user-space,  problem  was fifo of PL011 
> > uart
> was not getting enable in case of direct boot.
> > But in case of boot via UiApp, some piece of code was setting serial port
> attribute to enable this ( I still to figure out from where).
> > OS rely on boot-loader to enable this bit.
> 
> Are you using the latest edk2?
> 
> I vaguely recall some refactoring around PL011 (and in general, serial) 
> attributes
> from a year (or more?) ago. Hmm
> 
> b462f25a21e1 MdeModulePkg/SerialDxe: Describe correctly
> EFI_DEVICE_ERROR for SetAttributes
> 13d378fc82d4 MdeModulePkg/SerialDxe: Fix return valued in SerialSetAttributes
> 7ce5af40c98b MdeModulePkg/SerialDxe: Do not fail reset when SetAttributes is
> not supported
> 
> and
> 
> 91cc526b15ff MdeModulePkg/SerialDxe: Fix not able to change serial attributes
> 
> Thanks
> Laszlo
> 
> >> -Original Message-
> >> From: Laszlo Ersek 
> >> Sent: Thursday, November 29, 2018 11:31 PM
> >> To: Udit Kumar ; af...@apple.com
> >> Cc: Ni, Ruiyu ; edk2-devel@lists.01.org; Zeng, Star
> >> 
> >> Subject: Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct
> boot
> >>
> >> On 11/29/18 14:12, Udit Kumar wrote:
> >>> Thanks Laszlo,
> >>>
> >>>
> >>>> I can only think of some terminal control sequences that are *not*
> >>>> printed to the terminal when you don't enter UiApp manually. I don't
> >>>> understand how that could cause the exact symptom you describe, but I
> have
> >> no better explanation.
> >>>>
> >>>> Can you try other serial communication programs on your desktop? Such
> >>>> as "minicom" or "screen"?
> >>>
> >>> Screen didn't help.
> >>> Moreover , using different OS distributions show same similar behavior !!
> >>>
> >>>> Also, can you try changing your "console=..." kernel param(s)?
> >>>
> >>> You meant baud-rate ?
> >>
> >> Yes, and more. The options that the "console=" kernel parameter takes.
> >>
> >>>
> >>> On uefi side,  could you help me if there is some extra information
> >>> passed to OS in path UiApp -> BootDevice,
> >>
> >> I don't think so. Nothing comes to my mind anyway.
> >>
> >>> I could see , some of additional protocols are installed in above
> >>> path, I am not sure if those are used  by  OS or OS Loader (grub in my 
> >>> case)
> >> somehow.
> >>
> >> Well, UiApp generally connects all drivers to all devices -- normally a 
> >> platform
> >> BDS would not want to do this, for the sake of booting quickly --, which 
> >> likely
> >> results in more protocol instances being installed in the system. That
> shouldn't
> >> cause a difference for how serial behaves once the OS has booted.
> >>
> >> Thanks
> >> Laszlo

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

Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot

[Udit Kumar]

Thanks Laszlo/Andrew
Finally I manage to get logs from user-space,  problem  was fifo of PL011 uart 
was not getting enable in case of direct boot.
But in case of boot via UiApp, some piece of code was setting serial port 
attribute to enable this ( I still to figure out from where). 
OS rely on boot-loader to enable this bit.
 
Regards
Udit

> -Original Message-
> From: Laszlo Ersek 
> Sent: Thursday, November 29, 2018 11:31 PM
> To: Udit Kumar ; af...@apple.com
> Cc: Ni, Ruiyu ; edk2-devel@lists.01.org; Zeng, Star
> 
> Subject: Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot
> 
> On 11/29/18 14:12, Udit Kumar wrote:
> > Thanks Laszlo,
> >
> >
> >> I can only think of some terminal control sequences that are *not*
> >> printed to the terminal when you don't enter UiApp manually. I don't
> >> understand how that could cause the exact symptom you describe, but I have
> no better explanation.
> >>
> >> Can you try other serial communication programs on your desktop? Such
> >> as "minicom" or "screen"?
> >
> > Screen didn't help.
> > Moreover , using different OS distributions show same similar behavior !!
> >
> >> Also, can you try changing your "console=..." kernel param(s)?
> >
> > You meant baud-rate ?
> 
> Yes, and more. The options that the "console=" kernel parameter takes.
> 
> >
> > On uefi side,  could you help me if there is some extra information
> > passed to OS in path UiApp -> BootDevice,
> 
> I don't think so. Nothing comes to my mind anyway.
> 
> > I could see , some of additional protocols are installed in above
> > path, I am not sure if those are used  by  OS or OS Loader (grub in my case)
> somehow.
> 
> Well, UiApp generally connects all drivers to all devices -- normally a 
> platform
> BDS would not want to do this, for the sake of booting quickly --, which 
> likely
> results in more protocol instances being installed in the system. That 
> shouldn't
> cause a difference for how serial behaves once the OS has booted.
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot

[Udit Kumar]

Thanks Laszlo,

 
> I can only think of some terminal control sequences that are *not* printed to
> the terminal when you don't enter UiApp manually. I don't understand how that
> could cause the exact symptom you describe, but I have no better explanation.
> 
> Can you try other serial communication programs on your desktop? Such as
> "minicom" or "screen"?

Screen didn't help.
Moreover , using different OS distributions show same similar behavior !!
 
> Also, can you try changing your "console=..." kernel param(s)?

You meant baud-rate ? 

On uefi side,  could you help me if there is some extra information passed to 
OS in path 
UiApp -> BootDevice, 

I could see , some of additional protocols are installed in above path, I am 
not sure if those are
used  by  OS or OS Loader (grub in my case)  somehow.


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

Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot

[Udit Kumar]

Thanks for pointers Andrew
But if I use emulated runtime variables or say efi=noruntime, I am getting same 
behavior.
On device tree, I see device tree same in both cases.

In case of direct boot, only user space console is corrupted whereas kernel 
space console
already prints good characters.

FYI, 
Both user space and kernel space are on same kermit session

Regards
Udit


> -Original Message-
> From: af...@apple.com 
> Sent: Thursday, November 29, 2018 7:22 AM
> To: Udit Kumar 
> Cc: edk2-devel@lists.01.org; Ni, Ruiyu ; Zeng, Star
> 
> Subject: Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot
> 
> Udit,
> 
> Memory map differences would be expected as UiApp.efi is going to allocate
> memory too. The OS Loader starts off as an EFI Application so it needs to know
> EFI time allocations in addition to what allocations are legal for the OS to 
> use.
> 
> In general how EFI communicates with the OS is via EFI NVRAM Variables. You
> can look at the Table in section "3.3 Globally Defined Variables" of the UEFI
> Spec. The OSprot will also figure out information about the platform from ACPI
> tables published by the EFI firmware. Also the OS Loader is an EFI App so it 
> can
> access any protocol mentioned in the UEFI Spec. So form example on a Unix like
> OS the OS Loader may construct a Device Tree and pass it up to the kernel. It 
> is
> going to be the code in the OS loader that does all this magic. If your 
> working
> with a FOSS OS you may want to try and dump that device tree, and see if
> something is different. Then you could try to figure out the code in the OS
> Loader that produces that part of the device tree.
> 
> Thanks,
> 
> Andrew Fish
> 
> > On Nov 28, 2018, at 5:42 PM, Udit Kumar  wrote:
> >
> > Hi ,
> > I am looking for information/Help. If UEFI passed different
> > information to OS, in below boot path
> >
> >  1.  Enter into Setup menu (By pressing Esc key), On display of
> > UiApp.efi on console, select device to boot OS  2.  Let the boot OS
> > without user intervention from same device as of 1
> >
> > I could see, UEFI pass different memory map in case of 1 and 2.
> > Is there some other/extra information is being shared with OS/OS Loader.
> >
> > For me, if I use 1) for booting  then OS boots okay, If I use option
> > 2) for booting then when user-space prints are printed as garbage.
> > Whereas kernel space prints are good on serial console
> >
> > Thanks
> > Udit
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
> > ts.01.org%2Fmailman%2Flistinfo%2Fedk2-
> develdata=02%7C01%7Cudit.ku
> >
> mar%40nxp.com%7C2188b5d2f4cb4c3fafbf08d6559d53d7%7C686ea1d3bc2b4c
> 6fa92
> >
> cd99c5c301635%7C0%7C0%7C636790531534117827sdata=lD8yDYmuqO
> hf5co6y
> > gkjTV9HTi1Kft8y4xJFOgU6TJE%3Dreserved=0

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

[edk2] Help on boot manager 'Boot Manager Menu' and direct boot

[Udit Kumar]

Hi ,
I am looking for information/Help. If UEFI passed different information to OS, 
in below boot path

  1.  Enter into Setup menu (By pressing Esc key), On display of UiApp.efi on 
console, select device to boot OS
  2.  Let the boot OS without user intervention from same device as of 1

I could see, UEFI pass different memory map in case of 1 and 2.
Is there some other/extra information is being shared with OS/OS Loader.

For me, if I use 1) for booting  then OS boots okay,
If I use option 2) for booting then when user-space prints are printed as 
garbage. Whereas kernel space prints are good on serial console

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

Re: [edk2] [PATCH] NetworkPkg/IScsiDxe: add debug logs for failed SetVariable attempts

[Udit Kumar]

> -Original Message-
> From: edk2-devel  On Behalf Of
> Vijayenthiran Subramaniam
> Sent: Tuesday, November 20, 2018 4:10 PM
> To: edk2-devel@lists.01.org; siyuan...@intel.com; jiaxin...@intel.com
> Cc: Vijayenthiran Subramaniam 
> Subject: [edk2] [PATCH] NetworkPkg/IScsiDxe: add debug logs for failed
> SetVariable attempts
> 
> Add debug messages for failed attempts to write to a variable.
> 
> Cc: Siyuan Fu 
> Cc: Jiaxin Wu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Vijayenthiran Subramaniam
> 
> ---
>  NetworkPkg/IScsiDxe/IScsiMisc.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/NetworkPkg/IScsiDxe/IScsiMisc.c b/NetworkPkg/IScsiDxe/IScsiMisc.c
> index dd0d32dcda16..46760d79a8f3 100644
> --- a/NetworkPkg/IScsiDxe/IScsiMisc.c
> +++ b/NetworkPkg/IScsiDxe/IScsiMisc.c
> @@ -845,6 +845,8 @@ IScsiCreateAttempts (
>  );
>  FreePool (AttemptConfigOrder);
>  if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "%a: SetVariable failed with return: %r\n",
> +__FUNCTION__, Status));
>return Status;
>  }
> 
> @@ -887,6 +889,8 @@ IScsiCreateAttempts (
>  );
>  FreePool (AttemptConfigData);
>  if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "%a: SetVariable failed with return: %r\n",
> +__FUNCTION__, Status));
>return Status;
>  }
>}

Since you are printing, same text for both failure , how will you decide which 
SetVariable is failed 
You can choose to have different text or __LINE__ should help 


> --
> 2.17.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01
> .org%2Fmailman%2Flistinfo%2Fedk2-
> develdata=02%7C01%7Cudit.kumar%40nxp.com%7C5faa1c1f546046d1f1
> a708d64ed7ff20%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C6367
> 83086961408415sdata=RZdmCRaq8x0ps9gu13YAoWf8lsGS9zH2fAdnDLbP
> 3rE%3Dreserved=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 edk-platforms 1/2] Platform/HiKey960: add PL011UartClockLib

[Udit Kumar]

> -Original Message-
> From: edk2-devel  On Behalf Of Haojian
> Zhuang
> Sent: Thursday, August 9, 2018 8:16 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH v1 edk-platforms 1/2] Platform/HiKey960: add
> PL011UartClockLib
> 
> Since PL011UartClockLib is required by PL011 SerialPortLib.
> 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Haojian Zhuang 
> ---
>  Platform/Hisilicon/HiKey960/HiKey960.dsc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Platform/Hisilicon/HiKey960/HiKey960.dsc
> b/Platform/Hisilicon/HiKey960/HiKey960.dsc
> index be13714b9c19..15990b788336 100644
> --- a/Platform/Hisilicon/HiKey960/HiKey960.dsc
> +++ b/Platform/Hisilicon/HiKey960/HiKey960.dsc
> @@ -45,6 +45,7 @@ [LibraryClasses.common]
>DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
> 
> +
> PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartCl
> ockLib.inf

I think, this lib is part of common dsc of HiSilicon platforms . 
 
> SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib
> .inf
> 
> RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031Re
> alTimeClockLib.inf
>TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
> --
> 2.7.4
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.01.org%2Fmailman%2Flistinfo%2Fedk2-
> develdata=02%7C01%7Cudit.kumar%40nxp.com%7C6ace3239bab84b
> e9ded708d5fda23ca8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%
> 7C636693795605123423sdata=ixi5vsyZ1Z471FoRFlCRvRx9IrcNGgXY3gt
> 3QglboA8%3Dreserved=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/1] ArmPkg/OpteeLib: Add APIs to communicate with OP-TEE

[Udit Kumar]

 
> > So you do not really need an MM partition running alongside OP-TEE?
> >
> 
> Agree that most of secure services can be implemented as static
> (pseudo) TAs. But if I think about services like RAS error handling and
> firmware updates. Is Trusted OS (OP-TEE or any third party OS) an
> appropriate place to implement these platform specific services?

In my view, UEFI/MM services should be TOS specific. 
These must be independent of TOS. 

> Regards,
> Sumit
> 
> > >
> > > So it looks like they complement each other and we will have more
> > > robustness once we migrate to v8.4 Secure-EL2 Hypervisor for
> > > isolation support.
> >
> > In a way yes! The robustness bit is not really related to the
> > interface used to access as service.
> >
> > >
> > > Please feel free to correct me if I missed something.
> >
> > Hope this makes sense.
> >
> > cheers,
> > Achin
> >
> > >
> > > Regards,
> > > Sumit
> > >
> > > [1]
> > >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fin
> > >
> focenter.arm.com%2Fhelp%2Ftopic%2Fcom.arm.doc.den0028b%2FARM_DE
> N0028
> > >
> B_SMC_Calling_Convention.pdfdata=02%7C01%7Cudit.kumar%40nxp.
> com
> > >
> %7C8e3b0815c5424819b54f08d60d043499%7C686ea1d3bc2b4c6fa92cd99c5
> c3016
> > >
> 35%7C0%7C0%7C636710709050808156sdata=ad%2BlzFhGuZo9weUA
> CLYz3h%2
> > > FiGtRRbibouX7uXxrRQfw%3Dreserved=0
> > > [2]
> > >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fin
> > >
> focenter.arm.com%2Fhelp%2Ftopic%2Fcom.arm.doc.den0060a%2FDEN0060
> A_AR
> > >
> M_MM_Interface_Specification.pdfdata=02%7C01%7Cudit.kumar%40
> nxp
> > >
> .com%7C8e3b0815c5424819b54f08d60d043499%7C686ea1d3bc2b4c6fa92cd
> 99c5c
> > >
> 301635%7C0%7C0%7C636710709050808156sdata=CdVkFdX0dYkb%2F
> 8LzQXtJ
> > > WjlKjIsBoG1QHjxVvTIlV8k%3Dreserved=0
> > >
> > > > Thanks
> > > > Matteo
> > > >
> > > > [1]:
> > > >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > >
> Fcommunity.arm.com%2Fprocessors%2Fb%2Fblog%2Fposts%2Farchitecting-
> > > > more-secure-world-with-isolation-and-virtualizationdata=02%7C
> > > >
> 01%7Cudit.kumar%40nxp.com%7C8e3b0815c5424819b54f08d60d043499%7
> C686
> > > >
> ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636710709050808156
> p;sda
> > > >
> ta=fCaQAmaYd7Qur81A%2BRPvJ373e2uRuE0IJFTUDx8JzfU%3Dreserve
> d=0
> > > >
> > > > > -Original Message-
> > > > > From: Udit Kumar 
> > > > > Sent: 24 August 2018 18:46
> > > > > To: Ard Biesheuvel ; Matteo Carlini
> > > > > 
> > > > > Cc: Sumit Garg ; edk2-devel@lists.01.org;
> > > > > tee- d...@lists.linaro.org; daniel.thomp...@linaro.org;
> > > > > jens.wiklan...@linaro.org; Rod Dorris 
> > > > > Subject: RE: [edk2] [PATCH 1/1] ArmPkg/OpteeLib: Add APIs to
> > > > > communicate with OP-TEE
> > > > >
> > > > > Hi Ard
> > > > >
> > > > > > If MM mode is fundamentally incompatible with OP-TEE, then you
> > > > > > cannot run both at the same time,
> > > > >
> > > > > Both cannot coexist unless you have v8.4 CPU
> > > > >
> > > > > Regards
> > > > > Udit
> > > > >
> > > > > >
> > > > > >
> > > > > > >> -Original Message-
> > > > > > >> From: edk2-devel  On
> > > > > > >> Behalf Of Sumit Garg
> > > > > > >> Sent: Friday, August 24, 2018 2:51 PM
> > > > > > >> To: edk2-devel@lists.01.org
> > > > > > >> Cc: daniel.thomp...@linaro.org; tee-...@lists.linaro.org;
> > > > > > >> jens.wiklan...@linaro.org
> > > > > > >> Subject: [edk2] [PATCH 1/1] ArmPkg/OpteeLib: Add APIs to
> > > > > > >> communicate with OP-TEE
> > > > > > >>
> > > > > > >> Add following APIs to communicate with OP-TEE static TA:
> > > > > > >> 1. OpteeInit
> > > > > > >> 2. OpteeOpenSession
> > > > > > >> 3. OpteeCloseSession
> > > > > > >> 4. OpteeInvokeFunc
> > > > > > >

Re: [edk2] [PATCH 1/1] ArmPkg/OpteeLib: Add APIs to communicate with OP-TEE

[Udit Kumar]

Hi Ard 
 
> If MM mode is fundamentally incompatible with OP-TEE, then you cannot
> run both at the same time,

Both cannot coexist unless you have v8.4 CPU

Regards
Udit
 
> 
> 
> >> -Original Message-
> >> From: edk2-devel  On Behalf Of Sumit
> >> Garg
> >> Sent: Friday, August 24, 2018 2:51 PM
> >> To: edk2-devel@lists.01.org
> >> Cc: daniel.thomp...@linaro.org; tee-...@lists.linaro.org;
> >> jens.wiklan...@linaro.org
> >> Subject: [edk2] [PATCH 1/1] ArmPkg/OpteeLib: Add APIs to communicate
> >> with OP-TEE
> >>
> >> Add following APIs to communicate with OP-TEE static TA:
> >> 1. OpteeInit
> >> 2. OpteeOpenSession
> >> 3. OpteeCloseSession
> >> 4. OpteeInvokeFunc
> >>
> >> Cc: Ard Biesheuvel 
> >> Cc: Leif Lindholm 
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Sumit Garg 
> >> ---
> >>  ArmPkg/Include/Library/OpteeLib.h  | 102 ++
> >>  ArmPkg/Library/OpteeLib/Optee.c| 358
> >> +
> >>  ArmPkg/Library/OpteeLib/OpteeLib.inf   |   2 +
> >>  ArmPkg/Library/OpteeLib/OpteeSmc.h |  43 +++
> >>  .../Include/IndustryStandard/GlobalPlatform.h  |  60 ++--
> >>  5 files changed, 531 insertions(+), 34 deletions(-)  create mode
> >> 100644 ArmPkg/Library/OpteeLib/OpteeSmc.h
> >>  copy ArmPkg/Include/Library/OpteeLib.h =>
> >> MdePkg/Include/IndustryStandard/GlobalPlatform.h (53%)
> >>
> >> diff --git a/ArmPkg/Include/Library/OpteeLib.h
> >> b/ArmPkg/Include/Library/OpteeLib.h
> >> index f65d8674d9b8..c323f49072f8 100644
> >> --- a/ArmPkg/Include/Library/OpteeLib.h
> >> +++ b/ArmPkg/Include/Library/OpteeLib.h
> >> @@ -25,10 +25,112 @@
> >>  #define OPTEE_OS_UID2  0xaf630002
> >>  #define OPTEE_OS_UID3  0xa5d5c51b
> >>
> >> +#define OPTEE_MSG_ATTR_TYPE_NONE0x0
> >> +#define OPTEE_MSG_ATTR_TYPE_VALUE_INPUT 0x1
> >> +#define OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT0x2
> >> +#define OPTEE_MSG_ATTR_TYPE_VALUE_INOUT 0x3
> >> +#define OPTEE_MSG_ATTR_TYPE_MEM_INPUT   0x9
> >> +#define OPTEE_MSG_ATTR_TYPE_MEM_OUTPUT  0xa
> >> +#define OPTEE_MSG_ATTR_TYPE_MEM_INOUT   0xb
> >> +
> >> +#define OPTEE_MSG_ATTR_TYPE_MASK0xff
> >> +
> >> +typedef struct {
> >> +  UINT64BufPtr;
> >> +  UINT64Size;
> >> +  UINT64ShmRef;
> >> +} OPTEE_MSG_PARAM_MEM;
> >> +
> >> +typedef struct {
> >> +  UINT64A;
> >> +  UINT64B;
> >> +  UINT64C;
> >> +} OPTEE_MSG_PARAM_VALUE;
> >> +
> >> +typedef struct {
> >> +  UINT64 Attr;
> >> +  union {
> >> +OPTEE_MSG_PARAM_MEM  Mem;
> >> +OPTEE_MSG_PARAM_VALUEValue;
> >> +  } U;
> >> +} OPTEE_MSG_PARAM;
> >> +
> >> +#define MAX_PARAMS   4
> >> +
> >> +typedef struct {
> >> +UINT32 Cmd;
> >> +UINT32 Func;
> >> +UINT32 Session;
> >> +UINT32 CancelId;
> >> +UINT32 Pad;
> >> +UINT32 Ret;
> >> +UINT32 RetOrigin;
> >> +UINT32 NumParams;
> >> +
> >> +// NumParams tells the actual number of element in Params
> >> +OPTEE_MSG_PARAMParams[MAX_PARAMS];
> >> +} OPTEE_MSG_ARG;
> >> +
> >> +#define OPTEE_UUID_LEN   16
> >> +
> >> +//
> >> +// struct OPTEE_OPEN_SESSION_ARG - Open session argument
> >> +// @Uuid:   [in] UUID of the Trusted Application
> >> +// @Session:[out] Session id
> >> +// @Ret:[out] Return value
> >> +// @RetOrigin   [out] Origin of the return value
> >> +//
> >> +typedef struct {
> >> +UINT8 Uuid[OPTEE_UUID_LEN];
> >> +UINT32Session;
> >> +UINT32Ret;
> >> +UINT32RetOrigin;
> >> +} OPTEE_OPEN_SESSION_ARG;
> >> +
> >> +//
> >> +// struct OPTEE_INVOKE_FUNC_ARG - Invoke function argument
> >> +// @Func:   [in] Trusted Application function, specific to the TA
> >> +// @Session:[in] Session id
> >> +// @Ret:[out] Return value
> >> +// @RetOrigin   [out] Origin of the return value
> >> +// @Params  [inout] Parameters for function to be invoked
> >> +//
> >> +typedef struct {
> >> +UINT32 Func;
> >> +UINT32 Session;
> >> +UINT32 Ret;
> >> +UINT32 RetOrigin;
> >> +OPTEE_MSG_PARAMParams[MAX_PARAMS];
> >> +} OPTEE_INVOKE_FUNC_ARG;
> >> +
> >>  BOOLEAN
> >>  EFIAPI
> >>  IsOpteePresent (
> >>VOID
> >>);
> >>
> >> +EFI_STATUS
> >> +EFIAPI
> >> +OpteeInit (
> >> +  VOID
> >> +  );
> >> +
> >> +EFI_STATUS
> >> +EFIAPI
> >> +OpteeOpenSession (
> >> +  IN OUT OPTEE_OPEN_SESSION_ARG  *OpenSessionArg
> >> +  );
> >> +
> >> +EFI_STATUS
> >> +EFIAPI
> >> +OpteeCloseSession (
> >> +  IN UINT32  Session
> >> +  );
> >> +
> >> +EFI_STATUS
> >> +EFIAPI
> >> +OpteeInvokeFunc (
> >> +  IN OUT OPTEE_INVOKE_FUNC_ARG   *InvokeFuncArg
> >> +  );
> >> +
> >>  #endif
> >> diff --git 

Re: [edk2] [PATCH 1/1] ArmPkg/OpteeLib: Add APIs to communicate with OP-TEE

[Udit Kumar]

Hi Sumit 
What use case you have in mind, to interface op-tee with UEFI. 

What ARM proposed (Matteo in cc), to run MM mode in Secure side of machine with 
SPM. 
Moreover SPD (OP-TEE) and SPM(MM mode) cannot co-exists on current arm devices. 
Then how do you see MM mode working.

Regards
Udit


> -Original Message-
> From: edk2-devel  On Behalf Of Sumit
> Garg
> Sent: Friday, August 24, 2018 2:51 PM
> To: edk2-devel@lists.01.org
> Cc: daniel.thomp...@linaro.org; tee-...@lists.linaro.org;
> jens.wiklan...@linaro.org
> Subject: [edk2] [PATCH 1/1] ArmPkg/OpteeLib: Add APIs to communicate
> with OP-TEE
> 
> Add following APIs to communicate with OP-TEE static TA:
> 1. OpteeInit
> 2. OpteeOpenSession
> 3. OpteeCloseSession
> 4. OpteeInvokeFunc
> 
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Sumit Garg 
> ---
>  ArmPkg/Include/Library/OpteeLib.h  | 102 ++
>  ArmPkg/Library/OpteeLib/Optee.c| 358
> +
>  ArmPkg/Library/OpteeLib/OpteeLib.inf   |   2 +
>  ArmPkg/Library/OpteeLib/OpteeSmc.h |  43 +++
>  .../Include/IndustryStandard/GlobalPlatform.h  |  60 ++--
>  5 files changed, 531 insertions(+), 34 deletions(-)  create mode 100644
> ArmPkg/Library/OpteeLib/OpteeSmc.h
>  copy ArmPkg/Include/Library/OpteeLib.h =>
> MdePkg/Include/IndustryStandard/GlobalPlatform.h (53%)
> 
> diff --git a/ArmPkg/Include/Library/OpteeLib.h
> b/ArmPkg/Include/Library/OpteeLib.h
> index f65d8674d9b8..c323f49072f8 100644
> --- a/ArmPkg/Include/Library/OpteeLib.h
> +++ b/ArmPkg/Include/Library/OpteeLib.h
> @@ -25,10 +25,112 @@
>  #define OPTEE_OS_UID2  0xaf630002
>  #define OPTEE_OS_UID3  0xa5d5c51b
> 
> +#define OPTEE_MSG_ATTR_TYPE_NONE0x0
> +#define OPTEE_MSG_ATTR_TYPE_VALUE_INPUT 0x1
> +#define OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT0x2
> +#define OPTEE_MSG_ATTR_TYPE_VALUE_INOUT 0x3
> +#define OPTEE_MSG_ATTR_TYPE_MEM_INPUT   0x9
> +#define OPTEE_MSG_ATTR_TYPE_MEM_OUTPUT  0xa
> +#define OPTEE_MSG_ATTR_TYPE_MEM_INOUT   0xb
> +
> +#define OPTEE_MSG_ATTR_TYPE_MASK0xff
> +
> +typedef struct {
> +  UINT64BufPtr;
> +  UINT64Size;
> +  UINT64ShmRef;
> +} OPTEE_MSG_PARAM_MEM;
> +
> +typedef struct {
> +  UINT64A;
> +  UINT64B;
> +  UINT64C;
> +} OPTEE_MSG_PARAM_VALUE;
> +
> +typedef struct {
> +  UINT64 Attr;
> +  union {
> +OPTEE_MSG_PARAM_MEM  Mem;
> +OPTEE_MSG_PARAM_VALUEValue;
> +  } U;
> +} OPTEE_MSG_PARAM;
> +
> +#define MAX_PARAMS   4
> +
> +typedef struct {
> +UINT32 Cmd;
> +UINT32 Func;
> +UINT32 Session;
> +UINT32 CancelId;
> +UINT32 Pad;
> +UINT32 Ret;
> +UINT32 RetOrigin;
> +UINT32 NumParams;
> +
> +// NumParams tells the actual number of element in Params
> +OPTEE_MSG_PARAMParams[MAX_PARAMS];
> +} OPTEE_MSG_ARG;
> +
> +#define OPTEE_UUID_LEN   16
> +
> +//
> +// struct OPTEE_OPEN_SESSION_ARG - Open session argument
> +// @Uuid:   [in] UUID of the Trusted Application
> +// @Session:[out] Session id
> +// @Ret:[out] Return value
> +// @RetOrigin   [out] Origin of the return value
> +//
> +typedef struct {
> +UINT8 Uuid[OPTEE_UUID_LEN];
> +UINT32Session;
> +UINT32Ret;
> +UINT32RetOrigin;
> +} OPTEE_OPEN_SESSION_ARG;
> +
> +//
> +// struct OPTEE_INVOKE_FUNC_ARG - Invoke function argument
> +// @Func:   [in] Trusted Application function, specific to the TA
> +// @Session:[in] Session id
> +// @Ret:[out] Return value
> +// @RetOrigin   [out] Origin of the return value
> +// @Params  [inout] Parameters for function to be invoked
> +//
> +typedef struct {
> +UINT32 Func;
> +UINT32 Session;
> +UINT32 Ret;
> +UINT32 RetOrigin;
> +OPTEE_MSG_PARAMParams[MAX_PARAMS];
> +} OPTEE_INVOKE_FUNC_ARG;
> +
>  BOOLEAN
>  EFIAPI
>  IsOpteePresent (
>VOID
>);
> 
> +EFI_STATUS
> +EFIAPI
> +OpteeInit (
> +  VOID
> +  );
> +
> +EFI_STATUS
> +EFIAPI
> +OpteeOpenSession (
> +  IN OUT OPTEE_OPEN_SESSION_ARG  *OpenSessionArg
> +  );
> +
> +EFI_STATUS
> +EFIAPI
> +OpteeCloseSession (
> +  IN UINT32  Session
> +  );
> +
> +EFI_STATUS
> +EFIAPI
> +OpteeInvokeFunc (
> +  IN OUT OPTEE_INVOKE_FUNC_ARG   *InvokeFuncArg
> +  );
> +
>  #endif
> diff --git a/ArmPkg/Library/OpteeLib/Optee.c
> b/ArmPkg/Library/OpteeLib/Optee.c index 574527f8b5ea..2111022d3662
> 100644
> --- a/ArmPkg/Library/OpteeLib/Optee.c
> +++ b/ArmPkg/Library/OpteeLib/Optee.c
> @@ -14,11 +14,19 @@
> 
>  **/
> 
> +#include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
> 
>  #include 
> 

Re: [edk2] Tool to check memory leaks

[Udit Kumar]

Thanks Jiewen

> -Original Message-
> From: Yao, Jiewen [mailto:jiewen@intel.com]
> Sent: Thursday, August 2, 2018 6:24 PM
> To: Udit Kumar ; edk2-devel@lists.01.org
> Cc: Sumit Batra 
> Subject: RE: Tool to check memory leaks
> 
> Please refer to
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FMemory-leak-
> detection-with-memory-profile-
> featuredata=02%7C01%7Cudit.kumar%40nxp.com%7Ca2004032ed144
> 4b8729408d5f8770101%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %7C636688112374410700sdata=PF%2BzraEcqtfzy6K5N6T0RGFHNQTK
> Aap3QGQCwUnzkxg%3Dreserved=0
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Udit Kumar
> > Sent: Thursday, August 2, 2018 5:00 PM
> > To: edk2-devel@lists.01.org
> > Cc: Sumit Batra 
> > Subject: [edk2] Tool to check memory leaks
> >
> > Hi All
> > Is there some tool/debug option in edk2 to detect memory leak.
> > Thanks
> > Udit
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
> > ts.01.org%2Fmailman%2Flistinfo%2Fedk2-
> develdata=02%7C01%7Cudit.ku
> >
> mar%40nxp.com%7Ca2004032ed1444b8729408d5f8770101%7C686ea1d3bc2
> b4c6fa92
> >
> cd99c5c301635%7C0%7C0%7C636688112374410700sdata=JpJI1U9eYC
> AHH0DAg
> > 7IEp1mesytfHVjvVoZa%2Bmmz0NY%3Dreserved=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Tool to check memory leaks

[Udit Kumar]

Hi All
Is there some tool/debug option in edk2 to detect memory leak.
Thanks
Udit
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Help on AutoGen Files

[Udit Kumar]

Thanks Andrew and Marvin,

> You cannot explicitly influence the order of the calls, but implicitly via the
> dependency tree, which means you need to make SerialPortLib depend on your
> LibraryClass instance.

Looks this is difficult that I can force order on already available code. 

> Worst case you can demote FpgaInterfaceInit () from being a constructor to 
> just

Currently I am forcing the clock lib to call FpgaInterfaceInit first, this 
clock lib 
gives input clock to PL011 serial driver. 

Regards
Udit

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Andrew Fish
> Sent: Thursday, July 19, 2018 11:56 PM
> To: Marvin H?user 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Help on AutoGen Files
> 
> Udit,
> 
> As Marvin points out the [LibraryClasses] section of the INF file are going to
> imply the order of the library constructor calls in the AutoGen
> 
> Worst case you can demote FpgaInterfaceInit () from being a constructor to 
> just
> being a public library function that the other lib can call explicitly from 
> its
> constructor. Maybe that is too drastic and you could must move a function out
> of FpgaInterfaceInit () and make that function part of the Public library
> interface?
> 
> Thanks,
> 
> Andrew Fish
> 
> > On Jul 19, 2018, at 11:14 AM, Marvin H?user 
> wrote:
> >
> > Hey Udit,
> >
> > You cannot explicitly influence the order of the calls, but implicitly via 
> > the
> dependency tree, which means you need to make SerialPortLib depend on your
> LibraryClass instance.
> > You did not mention which SerialPortLib instance you use, but probably you
> need to execute FpgaInterfaceInit() earlier in platform code or fork 
> SerialPortLib
> for now.
> >
> > Regards,
> > Marvin
> >
> >> -Original Message-
> >> From: edk2-devel  On Behalf Of Udit
> >> Kumar
> >> Sent: Thursday, July 19, 2018 9:33 AM
> >> To: edk2-devel@lists.01.org
> >> Subject: [edk2] Help on AutoGen Files
> >>
> >> Hi Experts,
> >> How I can change the order of initialization in Constructor list of 
> >> autogen file.
> >> In my build system, if I look at
> >> MdeModulePkg/Universal/PCD/Pei/Pcd/DEBUG/AutoGen.c
> >> Below is function of Library Constructor List
> >>
> >> VOID
> >> EFIAPI
> >> ProcessLibraryConstructorList (
> >>  IN   EFI_PEI_FILE_HANDLE   FileHandle,
> >>  IN CONST EFI_PEI_SERVICES  **PeiServices
> >>  )
> >> {
> >>  EFI_STATUS  Status;
> >>
> >>  Status = BaseDebugLibSerialPortConstructor ();  ASSERT_EFI_ERROR
> >> (Status);
> >>
> >>  Status = PeiServicesTablePointerLibConstructor (FileHandle,
> >> PeiServices);  ASSERT_EFI_ERROR (Status);
> >>
> >>  Status = TimerConstructor ();
> >>  ASSERT_EFI_ERROR (Status);
> >>
> >>  Status = FpgaInterfaceInit ();
> >>  ASSERT_EFI_ERROR (Status);
> >>
> >> }
> >>
> >>
> >> My problem is SerialPortConstructor needs frequency, which can be
> >> retrieved after  FpgaInterfaceInit() Therefore, my preferred way for
> >> this constructor list will be
> >> FpgaInterfaceInit() followed by  BaseDebugLibSerialPortConstructor()
> >>
> >> how I can achieve this.
> >>
> >>
> >> Many Thanks
> >> Udit
> >> ___
> >> edk2-devel mailing list
> >> edk2-devel@lists.01.org
> >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> >> sts.01.org%2Fmailman%2Flistinfo%2Fedk2-
> develdata=02%7C01%7Cudit.
> >>
> kumar%40nxp.com%7C5df5baccbdde4daa481808d5eda51660%7C686ea1d3bc2
> b4c6f
> >>
> a92cd99c5c301635%7C0%7C0%7C636676215665542230sdata=6CnFNG5
> t05yH%
> >> 2FOSYpcbp%2F1gWQenUyWcJ%2Fb7C0Yt1n5Y%3Dreserved=0
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
> > ts.01.org%2Fmailman%2Flistinfo%2Fedk2-
> develdata=02%7C01%7Cudit.ku
> >
> mar%40nxp.com%7C5df5baccbdde4daa481808d5eda51660%7C686ea1d3bc2b4
> c6fa92
> >
> cd99c5c301635%7C0%7C0%7C636676215665542230sdata=6CnFNG5t05y
> H%2FOS
> > Ypcbp%2F1gWQenUyWcJ%2Fb7C0Yt1n5Y%3Dreserved=0
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01
> .org%2Fmailman%2Flistinfo%2Fedk2-
> develdata=02%7C01%7Cudit.kumar%40nxp.com%7C5df5baccbdde4daa4
> 81808d5eda51660%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636
> 676215665542230sdata=6CnFNG5t05yH%2FOSYpcbp%2F1gWQenUyWcJ
> %2Fb7C0Yt1n5Y%3Dreserved=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Help on AutoGen Files

[Udit Kumar]

Hi Experts,
How I can change the order of initialization in Constructor list of autogen 
file.
In my build system, if I look at
MdeModulePkg/Universal/PCD/Pei/Pcd/DEBUG/AutoGen.c
Below is function of Library Constructor List

VOID
EFIAPI
ProcessLibraryConstructorList (
  IN   EFI_PEI_FILE_HANDLE   FileHandle,
  IN CONST EFI_PEI_SERVICES  **PeiServices
  )
{
  EFI_STATUS  Status;

  Status = BaseDebugLibSerialPortConstructor ();
  ASSERT_EFI_ERROR (Status);

  Status = PeiServicesTablePointerLibConstructor (FileHandle, PeiServices);
  ASSERT_EFI_ERROR (Status);

  Status = TimerConstructor ();
  ASSERT_EFI_ERROR (Status);

  Status = FpgaInterfaceInit ();
  ASSERT_EFI_ERROR (Status);

}


My problem is SerialPortConstructor needs frequency, which can be retrieved 
after  FpgaInterfaceInit()
Therefore, my preferred way for this constructor list will be
FpgaInterfaceInit() followed by  BaseDebugLibSerialPortConstructor()

how I can achieve this.


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

[edk2] [edk2-platforms][PATCH v3] Platform: Add PL011UartClock Lib

[Udit Kumar]

This patch include default implementation of PL011
clock lib

[v3]
   Update in HiSilicon common dsc
[v2]
  Updated name of clock lib

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal 
---
 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc   | 1 +
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 1 +
 Platform/LeMaker/CelloBoard/CelloBoard.dsc   | 1 +
 Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 1 +
 Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 1 +
 Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc  | 1 +
 Silicon/Hisilicon/Hisilicon.dsc.inc  | 1 +
 7 files changed, 7 insertions(+)

diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
index aad5f47..9f9885f 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
@@ -106,6 +106,7 @@ DEFINE DO_CAPSULE   = FALSE
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
   # ARM PL011 UART Driver
+  
PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
 
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
index 8a43d31..3a7dad4 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
@@ -87,6 +87,7 @@
   
RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
   TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
   # ARM PL011 UART Driver
+  
PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
diff --git a/Platform/LeMaker/CelloBoard/CelloBoard.dsc 
b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
index 7cd166d..0ca027e 100644
--- a/Platform/LeMaker/CelloBoard/CelloBoard.dsc
+++ b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
@@ -102,6 +102,7 @@ DEFINE DO_FLASHER   = FALSE
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
   # ARM PL011 UART Driver
+  
PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
 
diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
index d363156..ba01551 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
@@ -118,6 +118,7 @@
   
PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
   DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
   
DebugAgentTimerLib|EmbeddedPkg/Library/DebugAgentTimerLibNull/DebugAgentTimerLibNull.inf
+  
PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
 
diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
index 402319b..d506ca1 100644
--- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
+++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
@@ -115,6 +115,7 @@
   
PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
   DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
   
DebugAgentTimerLib|EmbeddedPkg/Library/DebugAgentTimerLibNull/DebugAgentTimerLibNull.inf
+  
PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
 
diff --git a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc 
b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
index 8d0a5bd..87799ee 100644
--- a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
+++ b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
@@ -102,6 +102,7 @@ DEFINE DO_FLASHER   = FALSE
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
   # ARM PL011 UART Driver
+  
PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
 
diff --git 

[edk2] [PATCH v3 0/2] ArmPlatformPkg: PL011 Dynamic clock freq Support

[Udit Kumar]

[v3]
  Incorporated review comments of v2

[v2]
   Incorporated review comments of v1



Udit Kumar (2):
  ArmPlatformPkg: PL011 Dynamic clock freq Support
  ArmPlatformPkg: Include PL011UartClock Lib

 ArmPlatformPkg/ArmPlatformPkg.dec  |  1 +
 ArmPlatformPkg/ArmPlatformPkg.dsc  |  1 +
 ArmPlatformPkg/Include/Library/PL011UartClockLib.h | 31 +++
 .../PL011SerialPortLib/PL011SerialPortLib.c|  5 +--
 .../PL011SerialPortLib/PL011SerialPortLib.inf  |  1 +
 .../Library/PL011UartClockLib/PL011UartClockLib.c  | 29 +
 .../PL011UartClockLib/PL011UartClockLib.inf| 36 ++
 7 files changed, 102 insertions(+), 2 deletions(-)
 create mode 100644 ArmPlatformPkg/Include/Library/PL011UartClockLib.h
 create mode 100644 ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
 create mode 100644 
ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf

-- 
1.9.1

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

[edk2] [PATCH v3 1/2] ArmPlatformPkg: PL011 Dynamic clock freq Support

[Udit Kumar]

Some platform support dynamic clocking, Which is controlled
by some jumper setting or hardware registers.
Result of that PCD PL011UartClkInHz needs to be updated for
frequency change.
This patch implements support for dynamic frequency for
PL011 uart.
This patch implements default lib, which is using Pcd.
Platform which needs dynamic clocking needs implement
PL011UartClockLib

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Udit Kumar 
---
 ArmPlatformPkg/ArmPlatformPkg.dec  |  1 +
 ArmPlatformPkg/ArmPlatformPkg.dsc  |  1 +
 ArmPlatformPkg/Include/Library/PL011UartClockLib.h | 31 +++
 .../Library/PL011UartClockLib/PL011UartClockLib.c  | 29 +
 .../PL011UartClockLib/PL011UartClockLib.inf| 36 ++
 5 files changed, 98 insertions(+)
 create mode 100644 ArmPlatformPkg/Include/Library/PL011UartClockLib.h
 create mode 100644 ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
 create mode 100644 
ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf

diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec 
b/ArmPlatformPkg/ArmPlatformPkg.dec
index dff4598..5f67e74 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -36,6 +36,7 @@
   LcdHwLib|Include/Library/LcdHwLib.h
   LcdPlatformLib|Include/Library/LcdPlatformLib.h
   NorFlashPlatformLib|Include/Library/NorFlashPlatformLib.h
+  PL011UartClockLib|Include/Library/PL011UartClockLib.h
   PL011UartLib|Include/Library/PL011UartLib.h
 
 [Guids.common]
diff --git a/ArmPlatformPkg/ArmPlatformPkg.dsc 
b/ArmPlatformPkg/ArmPlatformPkg.dsc
index 0013106..d504e76 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dsc
+++ b/ArmPlatformPkg/ArmPlatformPkg.dsc
@@ -105,6 +105,7 @@
   ArmPlatformPkg/Library/LcdPlatformNullLib/LcdPlatformNullLib.inf
   ArmPlatformPkg/Library/NorFlashPlatformNullLib/NorFlashPlatformNullLib.inf
   ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
+  ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
   ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
   ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
   ArmPlatformPkg/Library/PrePiHobListPointerLib/PrePiHobListPointerLib.inf
diff --git a/ArmPlatformPkg/Include/Library/PL011UartClockLib.h 
b/ArmPlatformPkg/Include/Library/PL011UartClockLib.h
new file mode 100644
index 000..04c7d51
--- /dev/null
+++ b/ArmPlatformPkg/Include/Library/PL011UartClockLib.h
@@ -0,0 +1,31 @@
+/** @file
+*
+*  Copyright 2018 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 __PL011UARTCLOCKLIB_H__
+#define __PL011UARTCLOCKLIB_H__
+
+/**
+
+  Return baud clock frequency of  PL011.
+
+  @return return frequency of PL011 in Hz
+
+**/
+UINT32
+EFIAPI
+PL011UartClockGetFreq (
+  VOID
+  );
+
+#endif
diff --git a/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c 
b/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
new file mode 100644
index 000..6f0f61c
--- /dev/null
+++ b/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
@@ -0,0 +1,29 @@
+/** @file
+*
+*  Copyright 2018 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 
+
+/**
+  Return clock in for PL011 Uart IP
+
+  @return Pcd PL011UartClkInHz
+**/
+UINT32
+EFIAPI
+PL011UartClockGetFreq (
+  VOID
+  )
+{
+  return FixedPcdGet32 (PL011UartClkInHz);
+}
diff --git a/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf 
b/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
new file mode 100644
index 000..90193e6
--- /dev/null
+++ b/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
@@ -0,0 +1,36 @@
+#/* @file
+#  Copyright 2018 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.
+#
+#

[edk2] [PATCH v3 2/2] ArmPlatformPkg: Include PL011UartClock Lib

[Udit Kumar]

This patch gets PL011 baud rate clock from
pl011 uart clock lib instead of Pcd.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Udit Kumar 
---
 ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c   | 5 +++--
 ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c 
b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
index 6aa8063..212991d 100644
--- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
+++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -48,7 +49,7 @@ SerialPortInitialize (
 
   return PL011UartInitializePort (
(UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
-   FixedPcdGet32 (PL011UartClkInHz),
+   PL011UartClockGetFreq(),
,
,
,
@@ -156,7 +157,7 @@ SerialPortSetAttributes (
 {
   return PL011UartInitializePort (
(UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
-   FixedPcdGet32 (PL011UartClkInHz),
+   PL011UartClockGetFreq(),
BaudRate,
ReceiveFifoDepth,
Parity,
diff --git a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf 
b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
index 3683e06..5ce5b2f 100644
--- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
+++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
@@ -26,6 +26,7 @@
   PL011SerialPortLib.c
 
 [LibraryClasses]
+  PL011UartClockLib
   PL011UartLib
   PcdLib
 
-- 
1.9.1

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

Re: [edk2] [PATCH 1/2] ArmPlatformPkg: PL011 Dynamic clock freq Support

[Udit Kumar]

Thanks for review Ard. 

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, June 11, 2018 3:35 PM
> To: Udit Kumar 
> Cc: Leif Lindholm ; edk2-devel@lists.01.org
> Subject: Re: [PATCH 1/2] ArmPlatformPkg: PL011 Dynamic clock freq
> Support
> 
> Hello Udit,
> 
> Apologies for not bringing this up the first time, but I have some additional
> comments. The first time around, I only had a cursory look because at that
> point I was still skeptical whether we needed this library in the first place.

I hope, now you agree to have this lib 

> On 5 June 2018 at 19:59, Udit Kumar  wrote:
> > Some platform support dynamic clocking, Which is controlled by some
> > jumper setting or hardware registers.
> > Result of that PCD PL011UartClkInHz needs to be updated for frequency
> > change.
> > This patch implements support for dynamic frequency for
> > PL011 uart.
> > This patch implements default lib, which is using Pcd.
> > Platform which needs dynamic clocking needs implement
> > PL011UartClockLib
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Udit Kumar 
> > ---
> >  ArmPlatformPkg/ArmPlatformPkg.dec  |  1 +
> >  ArmPlatformPkg/Include/Library/PL011UartClockLib.h | 32
> > +++
> .../Library/PL011UartClockLib/PL011UartClockLib.c  | 29
> +
> >  .../PL011UartClockLib/PL011UartClockLib.inf| 37
> ++
> 
> Please add a reference to the new library in the [Components] section of
> ArmPlatformPkg.dsc as well, so we can build it standalone.

Ok 
 
> >  4 files changed, 99 insertions(+)
> >  create mode 100644
> ArmPlatformPkg/Include/Library/PL011UartClockLib.h
> >  create mode 100644
> > ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
> >  create mode 100644
> > ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
> >
> > diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec
> > b/ArmPlatformPkg/ArmPlatformPkg.dec
> > index dff4598..5f67e74 100644
> > --- a/ArmPlatformPkg/ArmPlatformPkg.dec
> > +++ b/ArmPlatformPkg/ArmPlatformPkg.dec
> > @@ -36,6 +36,7 @@
> >LcdHwLib|Include/Library/LcdHwLib.h
> >LcdPlatformLib|Include/Library/LcdPlatformLib.h
> >NorFlashPlatformLib|Include/Library/NorFlashPlatformLib.h
> > +  PL011UartClockLib|Include/Library/PL011UartClockLib.h
> >PL011UartLib|Include/Library/PL011UartLib.h
> >
> >  [Guids.common]
> > diff --git a/ArmPlatformPkg/Include/Library/PL011UartClockLib.h
> > b/ArmPlatformPkg/Include/Library/PL011UartClockLib.h
> > new file mode 100644
> > index 000..93813a0
> > --- /dev/null
> > +++ b/ArmPlatformPkg/Include/Library/PL011UartClockLib.h
> > @@ -0,0 +1,32 @@
> > +/** @file
> > +*
> > +*  Copyright 2018 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
> > +*
> >
> +https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fo
> pe
> > +nsource.org%2Flicenses%2Fbsd-
> license.php=02%7C01%7Cudit.kumar%40
> >
> +nxp.com%7C2ac27eb60055478ac37d08d5cf82d550%7C686ea1d3bc2b4c
> 6fa92cd99c
> >
> +5c301635%7C0%7C0%7C636643083195138179=C%2F2MhK2ZA6
> XPmC5c8byWlK3
> > +xAC6rFmLYofPKlj6M7%2FI%3D=0
> > +*
> > +*  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 __PL011CLOCKLIB_H__
> > +#define __PL011CLOCKLIB_H__
> 
> Nit: use __PL011UARTCLOCKLIB_H__ to match the filename.

My miss, thanks  will do in v3
 
> > +
> > +
> > +/**
> > +  Return frequency of PL011.
> > +
> 
> Mention the baud clock?

Sure 
> > +  By default this function returns FixedPcdGet32 (PL011UartClkInHz)
> > +
> 
> Drop this line please, it is not part of the prototype

Ok 
 
> > +  @return Return frequency of PL011
> > +
> > +**/
> > +UINT32
> > +ArmPlatformGetPL011ClockFreq (
> 
> The ArmPlatform prefix is unnecessary here: please use
> PL011UartClockGetFreq() instead.

Ok 
 
> > +  VOID
> > +  );
> > +
> > +#endif
> > diff --git
> > a/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
> > b/ArmPlatformPkg/Library/PL011Uart

Re: [edk2] [PATCH 2/2] ArmPlatformPkg: Include PL011UartClock Lib

[Udit Kumar]

Thanks Ard 

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, June 11, 2018 3:37 PM
> To: Udit Kumar 
> Cc: Leif Lindholm ; edk2-devel@lists.01.org
> Subject: Re: [PATCH 2/2] ArmPlatformPkg: Include PL011UartClock Lib
> 
> On 5 June 2018 at 19:59, Udit Kumar  wrote:
> > This patch includes, PL011UartClock lib.
> >
> > In case of no implemenation of this Clock Lib, Pcd value will be used
> > for PL011 frequency.
> >
> 
> Please improve the commit log. You are modifying the code to obtain the
> PL011 baud clock frequency from a library instead of a PCD

Ok 
 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Udit Kumar 
> > ---
> >  ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c   | 5
> +++--
> >  ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf | 1
> > +
> >  2 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git
> > a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> > b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> > index 6aa8063..c73e8db 100644
> > --- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> > +++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> > @@ -19,6 +19,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >
> > @@ -48,7 +49,7 @@ SerialPortInitialize (
> >
> >return PL011UartInitializePort (
> > (UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> > -   FixedPcdGet32 (PL011UartClkInHz),
> > +   ArmPlatformGetPL011ClockFreq(),
> > ,
> > ,
> > ,
> > @@ -156,7 +157,7 @@ SerialPortSetAttributes (  {
> >return PL011UartInitializePort (
> > (UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> > -   FixedPcdGet32 (PL011UartClkInHz),
> > +   ArmPlatformGetPL011ClockFreq(),
> > BaudRate,
> > ReceiveFifoDepth,
> > Parity,
> > diff --git
> > a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> > b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> > index 3683e06..5ce5b2f 100644
> > --- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> > +++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> > @@ -26,6 +26,7 @@
> >PL011SerialPortLib.c
> >
> >  [LibraryClasses]
> > +  PL011UartClockLib
> >PL011UartLib
> >PcdLib
> >
> 
> You need to add a library resolution to
> ArmPlatformPkg/ArmPlatformPkg.dsc for this library or you will break the
> build.

I will do this, 

FYI,
With update in edk2-platform, my compile was ok for Juno and NXP boards 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] Platform: Add PL011UartClock Lib

[Udit Kumar]

[v2]
  Updated name of clock lib

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal 
---
 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc   | 1 +
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 1 +
 Platform/Hisilicon/D05/D05.dsc   | 2 ++
 Platform/Hisilicon/HiKey/HiKey.dsc   | 1 +
 Platform/Hisilicon/HiKey960/HiKey960.dsc | 1 +
 Platform/LeMaker/CelloBoard/CelloBoard.dsc   | 1 +
 Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 1 +
 Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 1 +
 Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc  | 1 +
 9 files changed, 10 insertions(+)

diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
index 5e564f6..8dc58a6 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
@@ -106,6 +106,7 @@ DEFINE DO_CAPSULE   = FALSE
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
   # ARM PL011 UART Driver
+  
PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
 
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
index 8a43d31..3a7dad4 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
@@ -87,6 +87,7 @@
   
RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
   TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
   # ARM PL011 UART Driver
+  
PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc
index b6e1a9d..8396550 100644
--- a/Platform/Hisilicon/D05/D05.dsc
+++ b/Platform/Hisilicon/D05/D05.dsc
@@ -96,6 +96,7 @@
   UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
 
   LpcLib|Silicon/Hisilicon/Hi1610/Library/LpcLib/LpcLib.inf
+  
PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
 
 [LibraryClasses.common.SEC]
@@ -104,6 +105,7 @@
 
 [LibraryClasses.common.DXE_RUNTIME_DRIVER]
   I2CLib|Silicon/Hisilicon/Library/I2CLib/I2CLibRuntime.inf
+  
PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
 
 [BuildOptions]
diff --git a/Platform/Hisilicon/HiKey/HiKey.dsc 
b/Platform/Hisilicon/HiKey/HiKey.dsc
index 83dd68a..f158529 100644
--- a/Platform/Hisilicon/HiKey/HiKey.dsc
+++ b/Platform/Hisilicon/HiKey/HiKey.dsc
@@ -46,6 +46,7 @@
   DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
 
+  
PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
   
RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
   TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
diff --git a/Platform/Hisilicon/HiKey960/HiKey960.dsc 
b/Platform/Hisilicon/HiKey960/HiKey960.dsc
index 79e6875..a65c5b4 100644
--- a/Platform/Hisilicon/HiKey960/HiKey960.dsc
+++ b/Platform/Hisilicon/HiKey960/HiKey960.dsc
@@ -45,6 +45,7 @@
   DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
 
+  
PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
   
RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
   TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
diff --git a/Platform/LeMaker/CelloBoard/CelloBoard.dsc 
b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
index 7cd166d..0ca027e 100644
--- a/Platform/LeMaker/CelloBoard/CelloBoard.dsc
+++ b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
@@ -102,6 +102,7 @@ DEFINE DO_FLASHER   = FALSE
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
   # ARM PL011 UART Driver
+  
PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
 
diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 

[edk2] [PATCH 1/2] ArmPlatformPkg: PL011 Dynamic clock freq Support

[Udit Kumar]

Some platform support dynamic clocking, Which is controlled
by some jumper setting or hardware registers.
Result of that PCD PL011UartClkInHz needs to be updated for
frequency change.
This patch implements support for dynamic frequency for
PL011 uart.
This patch implements default lib, which is using Pcd.
Platform which needs dynamic clocking needs implement
PL011UartClockLib

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Udit Kumar 
---
 ArmPlatformPkg/ArmPlatformPkg.dec  |  1 +
 ArmPlatformPkg/Include/Library/PL011UartClockLib.h | 32 +++
 .../Library/PL011UartClockLib/PL011UartClockLib.c  | 29 +
 .../PL011UartClockLib/PL011UartClockLib.inf| 37 ++
 4 files changed, 99 insertions(+)
 create mode 100644 ArmPlatformPkg/Include/Library/PL011UartClockLib.h
 create mode 100644 ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
 create mode 100644 
ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf

diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec 
b/ArmPlatformPkg/ArmPlatformPkg.dec
index dff4598..5f67e74 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -36,6 +36,7 @@
   LcdHwLib|Include/Library/LcdHwLib.h
   LcdPlatformLib|Include/Library/LcdPlatformLib.h
   NorFlashPlatformLib|Include/Library/NorFlashPlatformLib.h
+  PL011UartClockLib|Include/Library/PL011UartClockLib.h
   PL011UartLib|Include/Library/PL011UartLib.h
 
 [Guids.common]
diff --git a/ArmPlatformPkg/Include/Library/PL011UartClockLib.h 
b/ArmPlatformPkg/Include/Library/PL011UartClockLib.h
new file mode 100644
index 000..93813a0
--- /dev/null
+++ b/ArmPlatformPkg/Include/Library/PL011UartClockLib.h
@@ -0,0 +1,32 @@
+/** @file
+*
+*  Copyright 2018 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 __PL011CLOCKLIB_H__
+#define __PL011CLOCKLIB_H__
+
+
+/**
+  Return frequency of PL011.
+
+  By default this function returns FixedPcdGet32 (PL011UartClkInHz)
+
+  @return Return frequency of PL011
+
+**/
+UINT32
+ArmPlatformGetPL011ClockFreq (
+  VOID
+  );
+
+#endif
diff --git a/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c 
b/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
new file mode 100644
index 000..b56af14
--- /dev/null
+++ b/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
@@ -0,0 +1,29 @@
+/** @file
+*
+*  Copyright 2018 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 
+
+/**
+  Return clock in for PL011 Uart IP.
+**/
+UINT32
+ArmPlatformGetPL011ClockFreq (
+  VOID
+  )
+{
+  // This function needs to be implemented on platforms which supports
+  // dynamic clocking to avoid re-building of UEFI firmware for PL011
+  // clock change
+  return FixedPcdGet32 (PL011UartClkInHz);
+}
diff --git a/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf 
b/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
new file mode 100644
index 000..5f6f699
--- /dev/null
+++ b/ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
@@ -0,0 +1,37 @@
+#/* @file
+#  Copyright 2018 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= 0x0001000A
+  BASE_NAME  = PL011UartClockLib
+  FILE_GUID  = af8fef24-afbb-472a-b8b7-13101a79703c
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = PL011UartClockLib
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  ArmPkg/ArmPkg.dec
+  ArmPlatformPkg/ArmPlatformPkg.dec
+
+[LibraryClasses]
+  ArmLib
+  DebugLib
+
+[Sources.common]
+  PL011UartClockLib.c
+
+[FixedPcd]
+  gArmPlatformTokenSpaceGui

[edk2] [PATCH v2 0/2] ArmPlatformPkg: PL011 Dynamic clock freq Support

[Udit Kumar]

[v2]
   Incorporated review comments of v1

Udit Kumar (2):
  ArmPlatformPkg: PL011 Dynamic clock freq Support
  ArmPlatformPkg: Include PL011UartClock Lib

 ArmPlatformPkg/ArmPlatformPkg.dec  |  1 +
 ArmPlatformPkg/Include/Library/PL011UartClockLib.h | 32 +++
 .../PL011SerialPortLib/PL011SerialPortLib.c|  5 +--
 .../PL011SerialPortLib/PL011SerialPortLib.inf  |  1 +
 .../Library/PL011UartClockLib/PL011UartClockLib.c  | 29 +
 .../PL011UartClockLib/PL011UartClockLib.inf| 37 ++
 6 files changed, 103 insertions(+), 2 deletions(-)
 create mode 100644 ArmPlatformPkg/Include/Library/PL011UartClockLib.h
 create mode 100644 ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.c
 create mode 100644 
ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf

-- 
1.9.1

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

[edk2] [PATCH 2/2] ArmPlatformPkg: Include PL011UartClock Lib

[Udit Kumar]

This patch includes, PL011UartClock lib.

In case of no implemenation of this Clock Lib,
Pcd value will be used for PL011 frequency.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Udit Kumar 
---
 ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c   | 5 +++--
 ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c 
b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
index 6aa8063..c73e8db 100644
--- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
+++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -48,7 +49,7 @@ SerialPortInitialize (
 
   return PL011UartInitializePort (
(UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
-   FixedPcdGet32 (PL011UartClkInHz),
+   ArmPlatformGetPL011ClockFreq(),
,
,
,
@@ -156,7 +157,7 @@ SerialPortSetAttributes (
 {
   return PL011UartInitializePort (
(UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
-   FixedPcdGet32 (PL011UartClkInHz),
+   ArmPlatformGetPL011ClockFreq(),
BaudRate,
ReceiveFifoDepth,
Parity,
diff --git a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf 
b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
index 3683e06..5ce5b2f 100644
--- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
+++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
@@ -26,6 +26,7 @@
   PL011SerialPortLib.c
 
 [LibraryClasses]
+  PL011UartClockLib
   PL011UartLib
   PcdLib
 
-- 
1.9.1

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

Re: [edk2] [PATCH 1/2] ArmPlatformPkg: PL011 Dynamic clock freq Support

[Udit Kumar]

> -Original Message-
> From: Alexei Fedorov [mailto:alexei.fedo...@arm.com]
> Sent: Tuesday, June 5, 2018 6:01 PM
> To: Udit Kumar ; edk2-devel@lists.01.org;
> ard.biesheu...@linaro.org; leif.lindh...@linaro.org
> Subject: RE: [edk2] [PATCH 1/2] ArmPlatformPkg: PL011 Dynamic clock freq
> Support
> 
> Please see my comment in-lined
> 
> > -Original Message-
> > From: edk2-devel  On Behalf Of Udit
> > Kumar
> > Sent: 05 June 2018 00:36
> > To: edk2-devel@lists.01.org; ard.biesheu...@linaro.org;
> > leif.lindh...@linaro.org
> > Subject: [edk2] [PATCH 1/2] ArmPlatformPkg: PL011 Dynamic clock freq
> > Support
> >
> > Some platform support dynamic clocking, Which is controlled by some
> > jumper setting or hardware registers.
> > Result of that PCD PL011UartClkInHz needs to be updated for frequency
> change.
> > This patch implements support for dynamic frequency for
> > PL011 uart.
> > This patch implement NULL lib for such platform where Pcd clock
> > frequency to
> > PL011 can change
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Udit Kumar 
> > ---
> >  .../Include/Library/ArmPlatformClockLib.h  | 32 
> > 
> >  .../ArmPlatformClockLib.inf| 33 
> > 
> >  .../ArmPlatformClockLibNull.c  | 35 
> > ++
> >  3 files changed, 100 insertions(+)
> >  create mode 100644
> > ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h
> >  create mode 100644
> > ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.inf
> >  create mode 100644
> > ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLibNull
> > .c
> >
> > diff --git a/ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h
> > b/ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h
> > new file mode 100644
> > index 000..f9d1425
> > --- /dev/null
> > +++ b/ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h
> > @@ -0,0 +1,32 @@
> > +/** @file
> > +*
> > +*  Copyright 2018 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
> > +*
> > +https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fope
> > +nsource.org%2Flicenses%2Fbsd-
> license.php=02%7C01%7Cudit.kumar%40
> >
> +nxp.com%7Cdd365496e05b46d7be4508d5cae0286e%7C686ea1d3bc2b4c6fa9
> 2cd99c
> >
> +5c301635%7C0%7C1%7C636637986464241388=rmypRtJplfoFQHAftihQ
> tfqHQ
> > +IcLO0Xele3IKdab6fM%3D=0
> > +*
> > +*  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 _ARMPLATFORMCLOCKLIB_H_
> > +#define _ARMPLATFORMCLOCKLIB_H_
> > +
> > +
> > +/**
> > +  Return frequency of PL011.
> > +
> > +  If this function return 0 then fixed value in Pcd will be used
> 
> Why cannot this function just return FixedPcdGet32 (PL011UartClkInHz) if
> dynamic clocking is not supported?

Ok, agreed with Ard's comment too 
Thanks
 
> > +
> > +  @return Return frequency of PL011
> > +
> > +**/
> > +UINT32
> > +ArmPlatformGetPL011ClockFreq (
> > +  VOID
> > +  );
> > +
> > +#endif
> > diff --git
> > a/ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.i
> > nf
> > b/ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.i
> > nf
> > new file mode 100644
> > index 000..b708ad3
> > --- /dev/null
> > +++ b/ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockL
> > +++ ib
> > +++ .inf
> > @@ -0,0 +1,33 @@
> > +#/* @file
> > +#  Copyright 2018 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 #
> > +https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fope
> > +nsource.org%2Flicenses%2Fbsd-
> license.php=02%7C01%7Cudit.kumar%40
> >
> +nxp.com%7Cdd365496e05b46d7be4508d5cae0286e%7C686ea1d3bc2b4c6fa9
> 2cd99c
> >
> +5c301635%7C0%7C1%7C636637986464241388=

Re: [edk2] [PATCH 1/2] ArmPlatformPkg: PL011 Dynamic clock freq Support

[Udit Kumar]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, June 5, 2018 5:56 PM
> To: Udit Kumar 
> Cc: edk2-devel@lists.01.org; Leif Lindholm 
> Subject: Re: [edk2][PATCH 1/2] ArmPlatformPkg: PL011 Dynamic clock freq
> Support
> 
> On 5 June 2018 at 14:23, Ard Biesheuvel  wrote:
> > On 5 June 2018 at 01:35, Udit Kumar  wrote:
> >> Some platform support dynamic clocking, Which is controlled by some
> >> jumper setting or hardware registers.
> >> Result of that PCD PL011UartClkInHz needs to be updated for frequency
> >> change.
> >> This patch implements support for dynamic frequency for
> >> PL011 uart.
> >> This patch implement NULL lib for such platform where Pcd clock
> >> frequency to PL011 can change
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Udit Kumar 
> >
> > I'm not crazy about this. How exactly are you reading the frequency in
> > your case?
> >
> >> ---
> >>  .../Include/Library/ArmPlatformClockLib.h  | 32 
> >> 
> >>  .../ArmPlatformClockLib.inf| 33 
> >> 
> >>  .../ArmPlatformClockLibNull.c  | 35 
> >> ++
> >>  3 files changed, 100 insertions(+)
> >>  create mode 100644
> >> ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h
> >>  create mode 100644
> >> ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.in
> >> f  create mode 100644
> >> ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLibNul
> >> l.c
> >>
> >
> > ArmPlatformClockLib doesn't make sense, since this is specific to PL011, no?
> >
> >
> >> diff --git a/ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h
> >> b/ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h
> >> new file mode 100644
> >> index 000..f9d1425
> >> --- /dev/null
> >> +++ b/ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h
> >
> > Please add new library classes to the package .dec file
> >
> >> @@ -0,0 +1,32 @@
> >> +/** @file
> >> +*
> >> +*  Copyright 2018 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
> >> +*
> >> +https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fop
> >> +ensource.org%2Flicenses%2Fbsd-
> license.php=02%7C01%7Cudit.kumar%
> >>
> +40nxp.com%7C1293bf5f16dd456e1a4708d5cadf750d%7C686ea1d3bc2b4c6fa
> 92cd
> >>
> +99c5c301635%7C0%7C0%7C636637983450007594=1qT2ZTJAYabHBvcQ
> kNXnP
> >> +PPQgM038f7hSYUa7r2Hhvo%3D=0
> >> +*
> >> +*  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 _ARMPLATFORMCLOCKLIB_H_
> >> +#define _ARMPLATFORMCLOCKLIB_H_
> >> +
> >> +
> >> +/**
> >> +  Return frequency of PL011.
> >> +
> >> +  If this function return 0 then fixed value in Pcd will be used
> >> +
> >> +  @return Return frequency of PL011
> >> +
> >> +**/
> >> +UINT32
> >> +ArmPlatformGetPL011ClockFreq (
> >> +  VOID
> >> +  );
> >> +
> >> +#endif
> >> diff --git
> >> a/ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.
> >> inf
> >> b/ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.
> >> inf
> >> new file mode 100644
> >> index 000..b708ad3
> >> --- /dev/null
> >> +++ b/ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClock
> >> +++ Lib.inf
> >> @@ -0,0 +1,33 @@
> >> +#/* @file
> >> +#  Copyright 2018 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 #
> >> +https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fop
> >> +ensource.org%

Re: [edk2] [PATCH 1/2] ArmPlatformPkg: PL011 Dynamic clock freq Support

[Udit Kumar]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, June 5, 2018 5:54 PM
> To: Udit Kumar 
> Cc: edk2-devel@lists.01.org; Leif Lindholm 
> Subject: Re: [edk2][PATCH 1/2] ArmPlatformPkg: PL011 Dynamic clock freq
> Support
> 
> On 5 June 2018 at 01:35, Udit Kumar  wrote:
> > Some platform support dynamic clocking, Which is controlled by some
> > jumper setting or hardware registers.
> > Result of that PCD PL011UartClkInHz needs to be updated for frequency
> > change.
> > This patch implements support for dynamic frequency for
> > PL011 uart.
> > This patch implement NULL lib for such platform where Pcd clock
> > frequency to PL011 can change
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Udit Kumar 
> 
> I'm not crazy about this. How exactly are you reading the frequency in your
> case?

On our SOC, we have sysclk, which is going to system PLL. System PLL generate 
the
clocks for different IPs. 
Sysclk can be 66MHz to 100Mhz, the value of sysclk is read from FPGA register.
To get IP clock, we need to read system PLL multiplier, Which is derived from 
a programmable hardware configuration called RCW (Reset configuration Word)   

 
> > ---
> >  .../Include/Library/ArmPlatformClockLib.h  | 32
> 
> >  .../ArmPlatformClockLib.inf| 33 
> > 
> >  .../ArmPlatformClockLibNull.c  | 35
> ++
> >  3 files changed, 100 insertions(+)
> >  create mode 100644
> > ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h
> >  create mode 100644
> >
> ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.inf
> >  create mode 100644
> >
> ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLibNull
> > .c
> >
> 
> ArmPlatformClockLib doesn't make sense, since this is specific to PL011, no?

Ok, I will rename it 
 
> 
> > diff --git a/ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h
> > b/ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h
> > new file mode 100644
> > index 000..f9d1425
> > --- /dev/null
> > +++ b/ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h
> 
> Please add new library classes to the package .dec file

Ok 
 
> > @@ -0,0 +1,32 @@
> > +/** @file
> > +*
> > +*  Copyright 2018 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
> > +*
> >
> +https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fop
> e
> > +nsource.org%2Flicenses%2Fbsd-
> license.php=02%7C01%7Cudit.kumar%40
> >
> +nxp.com%7Cad5930949e7843640e4e08d5cadf3192%7C686ea1d3bc2b4
> c6fa92cd99c
> >
> +5c301635%7C0%7C0%7C636637982321509959=EjBUXzY%2F0DcM
> OZ22tlOlSK0
> > +tZqANTqrgS%2BtgzLXLxrY%3D=0
> > +*
> > +*  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 _ARMPLATFORMCLOCKLIB_H_
> > +#define _ARMPLATFORMCLOCKLIB_H_
> > +
> > +
> > +/**
> > +  Return frequency of PL011.
> > +
> > +  If this function return 0 then fixed value in Pcd will be used
> > +
> > +  @return Return frequency of PL011
> > +
> > +**/
> > +UINT32
> > +ArmPlatformGetPL011ClockFreq (
> > +  VOID
> > +  );
> > +
> > +#endif
> > diff --git
> >
> a/ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.i
> > nf
> >
> b/ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.i
> > nf
> > new file mode 100644
> > index 000..b708ad3
> > --- /dev/null
> > +++
> b/ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockL
> > +++ ib.inf
> > @@ -0,0 +1,33 @@
> > +#/* @file
> > +#  Copyright 2018 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 #
> >
> +https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fop
> e
> > +nsource.org%2Flicenses%2Fbsd-
> license.php=02%7C01%7Cudit.kumar%40
> >

[edk2] [edk2-platforms][PATCH] Platform: Add ArmPlatformClockNULL Lib

[Udit Kumar]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal 
---
 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc   | 1 +
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 1 +
 Platform/Hisilicon/D05/D05.dsc   | 2 ++
 Platform/Hisilicon/HiKey/HiKey.dsc   | 1 +
 Platform/Hisilicon/HiKey960/HiKey960.dsc | 1 +
 Platform/LeMaker/CelloBoard/CelloBoard.dsc   | 1 +
 Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 1 +
 Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 1 +
 Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc  | 1 +
 9 files changed, 10 insertions(+)

diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
index 5e564f6..7d9c062 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
@@ -106,6 +106,7 @@ DEFINE DO_CAPSULE   = FALSE
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
   # ARM PL011 UART Driver
+  
ArmPlatformClockLib|ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.inf
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
 
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
index 8a43d31..f6f68e2 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
@@ -87,6 +87,7 @@
   
RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
   TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
   # ARM PL011 UART Driver
+  
ArmPlatformClockLib|ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.inf
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc
index b6e1a9d..83e99a8 100644
--- a/Platform/Hisilicon/D05/D05.dsc
+++ b/Platform/Hisilicon/D05/D05.dsc
@@ -96,6 +96,7 @@
   UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
 
   LpcLib|Silicon/Hisilicon/Hi1610/Library/LpcLib/LpcLib.inf
+  
ArmPlatformClockLib|ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
 
 [LibraryClasses.common.SEC]
@@ -104,6 +105,7 @@
 
 [LibraryClasses.common.DXE_RUNTIME_DRIVER]
   I2CLib|Silicon/Hisilicon/Library/I2CLib/I2CLibRuntime.inf
+  
ArmPlatformClockLib|ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
 
 [BuildOptions]
diff --git a/Platform/Hisilicon/HiKey/HiKey.dsc 
b/Platform/Hisilicon/HiKey/HiKey.dsc
index 83dd68a..8bee33f 100644
--- a/Platform/Hisilicon/HiKey/HiKey.dsc
+++ b/Platform/Hisilicon/HiKey/HiKey.dsc
@@ -46,6 +46,7 @@
   DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
 
+  
ArmPlatformClockLib|ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
   
RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
   TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
diff --git a/Platform/Hisilicon/HiKey960/HiKey960.dsc 
b/Platform/Hisilicon/HiKey960/HiKey960.dsc
index 79e6875..9b1e213 100644
--- a/Platform/Hisilicon/HiKey960/HiKey960.dsc
+++ b/Platform/Hisilicon/HiKey960/HiKey960.dsc
@@ -45,6 +45,7 @@
   DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
 
+  
ArmPlatformClockLib|ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
   
RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
   TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
diff --git a/Platform/LeMaker/CelloBoard/CelloBoard.dsc 
b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
index 7cd166d..e6857e7 100644
--- a/Platform/LeMaker/CelloBoard/CelloBoard.dsc
+++ b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
@@ -102,6 +102,7 @@ DEFINE DO_FLASHER   = FALSE
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
   # ARM PL011 UART Driver
+  
ArmPlatformClockLib|ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.inf
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
 
diff --git 

[edk2] [PATCH 1/2] ArmPlatformPkg: PL011 Dynamic clock freq Support

[Udit Kumar]

Some platform support dynamic clocking, Which is controlled
by some jumper setting or hardware registers.
Result of that PCD PL011UartClkInHz needs to be updated for
frequency change.
This patch implements support for dynamic frequency for
PL011 uart.
This patch implement NULL lib for such platform where
Pcd clock frequency to PL011 can change

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Udit Kumar 
---
 .../Include/Library/ArmPlatformClockLib.h  | 32 
 .../ArmPlatformClockLib.inf| 33 
 .../ArmPlatformClockLibNull.c  | 35 ++
 3 files changed, 100 insertions(+)
 create mode 100644 ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h
 create mode 100644 
ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.inf
 create mode 100644 
ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLibNull.c

diff --git a/ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h 
b/ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h
new file mode 100644
index 000..f9d1425
--- /dev/null
+++ b/ArmPlatformPkg/Include/Library/ArmPlatformClockLib.h
@@ -0,0 +1,32 @@
+/** @file
+*
+*  Copyright 2018 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 _ARMPLATFORMCLOCKLIB_H_
+#define _ARMPLATFORMCLOCKLIB_H_
+
+
+/**
+  Return frequency of PL011.
+
+  If this function return 0 then fixed value in Pcd will be used
+
+  @return Return frequency of PL011
+
+**/
+UINT32
+ArmPlatformGetPL011ClockFreq (
+  VOID
+  );
+
+#endif
diff --git 
a/ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.inf 
b/ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.inf
new file mode 100644
index 000..b708ad3
--- /dev/null
+++ b/ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLib.inf
@@ -0,0 +1,33 @@
+#/* @file
+#  Copyright 2018 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= 0x0001000A
+  BASE_NAME  = ArmPlatformClockLibNull
+  FILE_GUID  = af8fef24-afbb-472a-b8b7-13101a79703c
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = ArmPlatformClockLib
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  ArmPkg/ArmPkg.dec
+  ArmPlatformPkg/ArmPlatformPkg.dec
+
+[LibraryClasses]
+  ArmLib
+  DebugLib
+
+[Sources.common]
+  ArmPlatformClockLibNull.c
diff --git 
a/ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLibNull.c 
b/ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLibNull.c
new file mode 100644
index 000..28eaa63
--- /dev/null
+++ b/ArmPlatformPkg/Library/ArmPlatformClockLibNull/ArmPlatformClockLibNull.c
@@ -0,0 +1,35 @@
+/** @file
+*
+*  Copyright 2018 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 
+
+
+
+/**
+  Return clock in for PL011 Uart IP.
+**/
+UINT32
+ArmPlatformGetPL011ClockFreq (
+  VOID
+  )
+{
+  // Implement platform specific code
+  // and return PL011 freq
+
+  // Some platform supports dynamic clocking,
+  // This function needs to be implemented on platforms which supports
+  // dynamic clocking to avoid re-building of UEFI firmware for PL011
+  // clock change
+  return 0;
+}
-- 
1.9.1

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

[edk2] [PATCH 2/2] ArmPlatformPkg: Include ArmPlatformClock Lib

[Udit Kumar]

This patch includes, ArmPlatformClock in PL011 lib.

In case of NULL implemenation of Clock Lib, Pcd
value will be used for PL011 frequency.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Udit Kumar 
---
 ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c   | 7 +--
 ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c 
b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
index 6aa8063..40fa50a 100644
--- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
+++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
@@ -17,11 +17,14 @@
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
 #include 
 
+
+
 /** Initialise the serial device hardware with default settings.
 
   @retval RETURN_SUCCESSThe serial device was initialised.
@@ -48,7 +51,7 @@ SerialPortInitialize (
 
   return PL011UartInitializePort (
(UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
-   FixedPcdGet32 (PL011UartClkInHz),
+   ArmPlatformGetPL011ClockFreq() ? ArmPlatformGetPL011ClockFreq() : 
FixedPcdGet32 (PL011UartClkInHz),
,
,
,
@@ -156,7 +159,7 @@ SerialPortSetAttributes (
 {
   return PL011UartInitializePort (
(UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
-   FixedPcdGet32 (PL011UartClkInHz),
+   ArmPlatformGetPL011ClockFreq() ? ArmPlatformGetPL011ClockFreq() : 
FixedPcdGet32 (PL011UartClkInHz),
BaudRate,
ReceiveFifoDepth,
Parity,
diff --git a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf 
b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
index 3683e06..9820811 100644
--- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
+++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
@@ -26,6 +26,7 @@
   PL011SerialPortLib.c
 
 [LibraryClasses]
+  ArmPlatformClockLib
   PL011UartLib
   PcdLib
 
-- 
1.9.1

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

Re: [edk2] [PATCH v2 04/17] ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.

[Udit Kumar]

Hi Supreeth, 
One question on this patch 
We are asking permission on base-address and changing the permission of 
memory based upon base and size. 
I haven't looked at other part of code which manage this , 
But will there be possibility that, base address is given correctly and length 
may over-lap the other MMU entry.

Regards
Udit 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Supreeth Venkatesh
> Sent: Saturday, May 5, 2018 2:11 AM
> To: edk2-devel@lists.01.org
> Cc: ard.biesheu...@linaro.org; leif.lindh...@linaro.org; jiewen@intel.com;
> liming@intel.com; michael.d.kin...@intel.com
> Subject: [edk2] [PATCH v2 04/17] ArmPkg/ArmMmuLib: Add MMU Library
> suitable for use in S-EL0.
> 
> The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
> Platforms. Privileged firmware e.g. ARM Trusted Firmware sets up its
> architectural context including the initial translation tables for the
> S-EL1/EL0 translation regime. The MM environment will still request ARM
> TF to change the memory attributes of memory regions during
> initialization.
> 
> The Standalone MM image is a FV that encapsulates the MM foundation
> and drivers. These are PE-COFF images with data and text segments.
> To initialise the MM environment, Arm Trusted Firmware has to create
> translation tables with sane default attributes for the memory
> occupied by the FV. This library sends SVCs to ARM Trusted Firmware
> to request memory permissions change for data and text segments.
> 
> This patch adds a simple MMU library suitable for execution in S-EL0 and
> requesting memory permissions change operations from Arm Trusted Firmware.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta 
> Signed-off-by: Supreeth Venkatesh 
> ---
>  .../ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c  | 195
> +
>  1 file changed, 195 insertions(+)
>  create mode 100644
> ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c
> 
> diff --git
> a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c
> b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c
> new file mode 100644
> index 00..0f5e68d2d4
> --- /dev/null
> +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c
> @@ -0,0 +1,195 @@
> +/** @file
> +*  File managing the MMU for ARMv8 architecture in S-EL0
> +*
> +*  Copyright (c) 2017 - 2018, 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
> +*
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenso
> urce.org%2Flicenses%2Fbsd-
> license.php=02%7C01%7Cudit.kumar%40nxp.com%7C776b728240f7402b
> 029708d5b1ff7179%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63
> 6610633113917388=KGmnTNpIKqIXyS2sdVH1I2EaCd8rhm%2BKI05JuxYv8
> Aw%3D=0
> +*
> +*  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 
> +
> +EFI_STATUS
> +GetMemoryPermissions (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  OUT UINT32*MemoryAttributes
> +  )
> +{
> +  ARM_SVC_ARGS  GetMemoryPermissionsSvcArgs = {0};
> +
> +  GetMemoryPermissionsSvcArgs.Arg0 =
> ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64;
> +  GetMemoryPermissionsSvcArgs.Arg1 = BaseAddress;
> +  GetMemoryPermissionsSvcArgs.Arg2 = 0;
> +  GetMemoryPermissionsSvcArgs.Arg3 = 0;
> +
> +  ArmCallSvc ();
> +  if (GetMemoryPermissionsSvcArgs.Arg0 ==
> ARM_SVC_SPM_RET_INVALID_PARAMS) {
> +*MemoryAttributes = 0;
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  *MemoryAttributes = GetMemoryPermissionsSvcArgs.Arg0;
> +  return EFI_SUCCESS;
> +}
> +
> +EFI_STATUS
> +RequestMemoryPermissionChange (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length,
> +  IN  UINTN Permissions
> +  )
> +{
> +  EFI_STATUSStatus;
> +  ARM_SVC_ARGS  ChangeMemoryPermissionsSvcArgs = {0};
> +
> +  ChangeMemoryPermissionsSvcArgs.Arg0 =
> ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64;
> +  ChangeMemoryPermissionsSvcArgs.Arg1 = BaseAddress;
> +  ChangeMemoryPermissionsSvcArgs.Arg2 = (Length >= EFI_PAGE_SIZE) ? \
> + Length >> EFI_PAGE_SHIFT : 1;
> +  ChangeMemoryPermissionsSvcArgs.Arg3 = Permissions;
> +
> +  ArmCallSvc ();
> +
> +  Status = ChangeMemoryPermissionsSvcArgs.Arg0;
> +
> +  switch (Status) {
> +  case ARM_SVC_SPM_RET_SUCCESS:
> +Status = EFI_SUCCESS;
> +break;
> +
> +  case ARM_SVC_SPM_RET_NOT_SUPPORTED:
> +Status = EFI_UNSUPPORTED;
> +  

Re: [edk2] [PATCH v2 03/17] ArmPkg/Include: Add MM interface SVC return codes.

[Udit Kumar]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Supreeth Venkatesh
> Sent: Saturday, May 5, 2018 2:11 AM
> To: edk2-devel@lists.01.org
> Cc: ard.biesheu...@linaro.org; leif.lindh...@linaro.org; jiewen@intel.com;
> liming@intel.com; michael.d.kin...@intel.com
> Subject: [edk2] [PATCH v2 03/17] ArmPkg/Include: Add MM interface SVC return
> codes.
> 
> This patch adds the Management Mode(MM) - Secure Partition Manager(SPM)
> SVC return codes.
> Also, It corrects SVC ID for retrieving SPM version information.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta 
> Signed-off-by: Supreeth Venkatesh 
> ---
>  ArmPkg/Include/IndustryStandard/ArmMmSvc.h | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
> b/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
> index 4c7b6c3386..a64b9ec23c 100644
> --- a/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
> +++ b/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
> @@ -20,7 +20,7 @@
>   * delegated events and request the Secure partition manager to perform
>   * privileged operations on its behalf.
>   */
> -#define ARM_SVC_ID_SPM_VERSION_AARCH64 0xC460
> +#define ARM_SVC_ID_SPM_VERSION_AARCH32 0x8460
>  #define ARM_SVC_ID_SP_EVENT_COMPLETE_AARCH64   0xC461
>  #define ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64   0xC464
>  #define ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64   0xC465
> @@ -40,4 +40,11 @@
>  c_perm) & SET_MEM_ATTR_CODE_PERM_MASK) <<
> SET_MEM_ATTR_CODE_PERM_SHIFT) | \
>  (( (d_perm) & SET_MEM_ATTR_DATA_PERM_MASK) <<
> SET_MEM_ATTR_DATA_PERM_SHIFT))
> 
> +/* MM SVC Return error codes */
> +#define ARM_SVC_SPM_RET_SUCCESS   0
> +#define ARM_SVC_SPM_RET_NOT_SUPPORTED-1
> +#define ARM_SVC_SPM_RET_INVALID_PARAMS   -2
> +#define ARM_SVC_SPM_RET_DENIED   -3
> +#define ARM_SVC_SPM_RET_NO_MEMORY-5

Please see if you want to define errors as negative.
AFAIK, in edk2 negative errors are not used 

> +
>  #endif
> --
> 2.16.2
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01
> .org%2Fmailman%2Flistinfo%2Fedk2-
> devel=02%7C01%7Cudit.kumar%40nxp.com%7Ca6dc7d4a80e24bad73b80
> 8d5b1ff6f28%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63661063
> 3010245207=IHWYNFk0W2OKDQ%2BYEkJFmpi14mkXJyhblAdZQK7jM%2
> B0%3D=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 02/17] ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.

[Udit Kumar]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Supreeth Venkatesh
> Sent: Saturday, May 5, 2018 2:11 AM
> To: edk2-devel@lists.01.org
> Cc: ard.biesheu...@linaro.org; leif.lindh...@linaro.org; jiewen@intel.com;
> liming@intel.com; michael.d.kin...@intel.com
> Subject: [edk2] [PATCH v2 02/17] ArmPkg/Drivers: Add
> EFI_MM_COMMUNICATION_PROTOCOL DXE driver.
> 
> PI v1.5 Specification Volume 4 defines Management Mode Core Interface
> and defines EFI_MM_COMMUNICATION_PROTOCOL. This protocol provides a
> means of communicating between drivers outside of MM and MMI
> handlers inside of MM.
> 
> This patch implements the EFI_MM_COMMUNICATION_PROTOCOL DXE
> runtime
> driver for AARCH64 platforms. It uses SMCs allocated from the standard
> SMC range defined in DEN0060A_ARM_MM_Interface_Specification.pdf
> to communicate with the standalone MM environment in the secure world.
> 
> This patch also adds the MM Communication driver (.inf) file to
> define entry point for this driver and other compile
> related information the driver needs.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta 
> Signed-off-by: Supreeth Venkatesh 
> ---
>  .../Drivers/MmCommunicationDxe/MmCommunication.c   | 408
> +
>  .../Drivers/MmCommunicationDxe/MmCommunication.inf |  50 +++
>  2 files changed, 458 insertions(+)
>  create mode 100644
> ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
>  create mode 100644
> ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> 
> diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> new file mode 100644
> index 00..8ba1790af9
> --- /dev/null
> +++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> @@ -0,0 +1,408 @@
> +/** @file
> +
> +  Copyright (c) 2016-2018, 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
> +
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenso
> urce.org%2Flicenses%2Fbsd-
> license.php=02%7C01%7Cudit.kumar%40nxp.com%7Cc6986ed63017483b
> 89dd08d5b1ff6c2d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63
> 6610632972644435=CoYRxTy3iCIKcy2xXEF6BJl1qNQEPZTLHBX9pXmrHR
> w%3D=0
> +
> +  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 
> +
> +#define MM_MAJOR_VER_MASK0x
> +#define MM_MINOR_VER_MASK0x
> +#define MM_MAJOR_VER_SHIFT   16
> +
> +const UINT32 MM_MAJOR_VER = 1;
> +const UINT32 MM_MINOR_VER = 0;

This should be UINT16 , as compare is done against UINT16 

> +
> +//
> +// Address, Length of the pre-allocated buffer for communication with the
> secure
> +// world.
> +//
> +STATIC ARM_MEMORY_REGION_DESCRIPTOR  mNsCommBuffMemRegion;
> +
> +// Notification event when virtual address map is set.
> +STATIC EFI_EVENT  mSetVirtualAddressMapEvent;
> +
> +//
> +// Handle to install the MM Communication Protocol
> +//
> +STATIC EFI_HANDLE  mMmCommunicateHandle;
> +
> +/**
> +  Communicates with a registered handler.
> +
> +  This function provides an interface to send and receive messages to the
> +  Standalone MM environment on behalf of UEFI services.  This function is 
> part
> +  of the MM Communication Protocol that may be called in physical mode prior
> to
> +  SetVirtualAddressMap() and in virtual mode after SetVirtualAddressMap().
> +
> +  @param[in]  ThisThe EFI_MM_COMMUNICATION_PROTOCOL
> +  instance.
> +  @param[in, out] CommBuffer  A pointer to the buffer to convey
> +  into MMRAM.
> +  @param[in, out] CommSizeThe size of the data buffer being
> +  passed in. This is optional.
> +
> +  @retval EFI_SUCCESS The message was successfully posted.
> +  @retval EFI_INVALID_PARAMETER   The CommBuffer was NULL.
> +  @retval EFI_BAD_BUFFER_SIZE The buffer size is incorrect for the MM
> +  implementation. If this error is
> +  returned, the MessageLength field in
> +  the CommBuffer header or the integer
> +  pointed by CommSize are updated to 
> reflect
> +  the maximum payload size the
> +  implementation 

Re: [edk2] [PATCH] MdePkg: add big-endian MMIO BaseBeIoLib

[Udit Kumar]

Hi Laszlo 

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, April 17, 2018 3:12 PM
> To: Udit Kumar <udit.ku...@nxp.com>; Leif Lindholm
> <leif.lindh...@linaro.org>
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org;
> Gao, Liming <liming@intel.com>
> Subject: Re: [edk2] [PATCH] MdePkg: add big-endian MMIO BaseBeIoLib
> 
> On 04/17/18 10:15, Udit Kumar wrote:
> > Hi Laszlo,
> >
> > Considering all possible option is best to have in code 
> > But IMO, We are running UEFI on LE CPU only, Not sure someone is running on
> BE. AFAIK even specs says LE.
> >
> >> (c) assuming we introduce a CPU with BE byte order, the same driver
> >> source will work (for both LE and BE devices), only the lib
> >> instances will have to be switched around. (This might even happen
> >> dynamically, via function pointers.)
> >
> > I assume , when we say CPU in BE , this means we are talking here new
> > CPU architecture and new SOC.  So I expect some changes in hardware IP as
> well.
> > If not then, I see still this working with patch of Leif
> >
> > Like
> > CPU (LE,) Driver (LE) Uses Mmio
> > CPU (LE,) Driver (BE) Uses BeMmio (Mmio with swap)
> >
> > CPU (BE,) Driver (LE) Uses Mmio (Does read and Swap) <-- This will be
> > new Mmio Lib for particular architecture CPU (BE,) Driver (BE) Uses
> > BeMmio (Mmio with swap)  <-- Swap of swap will make same value
> >
> > With this, I see driver code is same irrespective of CPU arch
> >
> > thoughts ?
> 
> Apparently I've needlessly complicated things already. Feel free to proceed as
> you see fit.

You haven't complicated the things , rather helping to get better solution !!
For me, patch from Leif, seems to work on BE or LE CPU. 
With as it is patch, Apart from edk2 coding rules, one limitation  I see for BE 
CPU having BE IP device driver, swap will be done twice.

On lighter note, 
To keep things simple, I need to request hardware designer to stay away from BE 
IP in next SOC  

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

Re: [edk2] [PATCH] MdePkg: add big-endian MMIO BaseBeIoLib

[Udit Kumar]

Hi Laszlo, 

Considering all possible option is best to have in code  
But IMO, We are running UEFI on LE CPU only, Not sure someone is running on BE. 
AFAIK even specs says LE. 

> (c) assuming we introduce a CPU with BE byte order, the same driver
> source will work (for both LE and BE devices), only the lib
> instances will have to be switched around. (This might even happen
> dynamically, via function pointers.)

I assume , when we say CPU in BE , this means we are talking here new CPU 
architecture
and new SOC.  So I expect some changes in hardware IP as well.
If not then, I see still this working with patch of Leif 

Like 
CPU (LE,) Driver (LE) Uses Mmio
CPU (LE,) Driver (BE) Uses BeMmio (Mmio with swap)

CPU (BE,) Driver (LE) Uses Mmio (Does read and Swap) <-- This will be new Mmio 
Lib for particular architecture 
CPU (BE,) Driver (BE) Uses BeMmio (Mmio with swap)  <-- Swap of swap will make 
same value 

With this, I see driver code is same irrespective of CPU arch 

thoughts ? 

Thanks 
Udit 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, April 17, 2018 1:03 AM
> To: Leif Lindholm 
> Cc: Kinney, Michael D ; edk2-devel@lists.01.org;
> Gao, Liming 
> Subject: Re: [edk2] [PATCH] MdePkg: add big-endian MMIO BaseBeIoLib
> 
> On 04/16/18 12:07, Leif Lindholm wrote:
> > On Fri, Apr 13, 2018 at 11:32:35PM +, Kinney, Michael D wrote:
> >> Leif,
> >>
> >> I am curious why a Swap class/instances is not sufficient.
> >>
> >> Currently EDK II follows the UEFI/PI specs, which for all supported
> >> CPU architectures use little endian ABI. The BaseIoLib follows the
> >> endianness of the CPU.  If UEFI/PI added a CPU that was big endian, I
> >> would expect BaseIoLib when built for that CPU would perform big
> >> endian operations.
> >>
> >> Am I missing something?
> >
> > If you did add a big-endian CPU, you could then find yourself in the
> > exact opposite situation and require a little-endian i/o access
> > library. Which would be implemented exactly as the contents of
> > IoLibSwap.c.
> >
> > The header file necessarily needs to be endianness-specific, and if
> > the coding style had permitted functions in header files, my automatic
> > reaction would have been to make all of these static inline helper
> > functions (even with the code duplication).
> 
> First, to remind myself of the previous discussion (and please correct me if I
> remember incorrectly): whether swapping is needed or not depends on both
> CPU byte order and device byte order. However, the library API names that
> device drivers use should reflect device byte order *only* (regardless of CPU
> byte order). This way,
> 
> (a) developers that write device drivers can focus on the devices,
> regardless of what CPU the driver is compiled for,
> 
> (b) library classes for both LE and BE devices can be used together in
> the same driver module,
> 
> (c) assuming we introduce a CPU with BE byte order, the same driver
> source will work (for both LE and BE devices), only the lib
> instances will have to be switched around. (This might even happen
> dynamically, via function pointers.)
> 
> Now, after staring at this patch long and hard, here's my understanding.
> Crucially, you take the IoLib class to mean "it doesn't swap". You don't take 
> it to
> mean "it talks to LE devices". This is evident from the source file 
> "IoLibSwap.c",
> where you add the swapping on top of IoLib.
> That's fine, but it will have consequences:
> 
> (1) We need a separate library class called IoSwapLib (not IoLibSwap),
> implemented under "MdePkg/Library/BaseIoSwapLib/BaseIoSwapLib.c",
> and without the preprocessor trickery. There should be one library
> instance only, adding nothing but byte swapping on top of IoLib.
> 
> (2) We need separate library classes called BeIoLib and LeIoLib. These
> provide the ultimate APIs that I describe near the top. In total we
> should have four library instances that are explicit about device
> endianness. This means four INF files, and a single shared C source
> file, *with* the preprocessor trickery.
> 
> (2.1) BaseBeIoLib.inf: implements the BeIoLib functions on top of IoLib,
>   that is, without swapping -- this means that it is suitable for
>   talking to BE devices on BE CPUs.
> 
> (2.2) BaseBeIoLibSwap.inf: implements the BeIoLib functions on top of
>   IoSwapLib -- talks to BE devices on LE CPUs.
> 
> (2.3) BaseLeIoLib.inf: implements LeIoLib functions on top of IoLib --
>   talks to LE devices on LE CPUs.
> 
> (2.4) BaseLeIoLibSwap.inf: implements LeIoLib functions on top of
>   IoSwapLib -- talks to LE devices on BE CPUs.
> 
> IMO, it's fine if you only want to add the BeIoLib class now, with its
> BaseBeIoLibSwap instance only. But the IoSwapLib and BeIoLib classes must
> 

Re: [edk2] [PATCH] MdePkg: add big-endian MMIO BaseBeIoLib

[Udit Kumar]

Hi Mike, 

Do we want to support BE CPUs, ?
If yes then Last discussion of Lazlo is valid, where driver don't need to take 
care of CPU endianness. 

Regards
Udit 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Kinney, Michael D
> Sent: Monday, April 16, 2018 7:41 PM
> To: Leif Lindholm ; Kinney, Michael D
> 
> Cc: edk2-devel@lists.01.org; Laszlo Ersek ; Gao, Liming
> 
> Subject: Re: [edk2] [PATCH] MdePkg: add big-endian MMIO BaseBeIoLib
> 
> Leif,
> 
> I agree that the opposite use case is a BE CPU
> needing a LE operation.
> 
> I think we only need a single lib class and lib
> Instance that does the byte swap and we should
> not use Le or Be in any of the names of the class,
> instance, or APIs.  Just "Swap".
> 
> The 4 cases
> 
> * LE CPU, LE I/O.  Use BaseIoLib
> * BE CPU, BE I/O.  Use BaseIoLib
> * LE CPU, BE I/O.  Use BaseIoSwapLib
> * BE CPU, LE I/O.  Use BaseIoSwapLib
> 
> Mike
> 
> 
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: Monday, April 16, 2018 3:07 AM
> > To: Kinney, Michael D 
> > Cc: edk2-devel@lists.01.org; Laszlo Ersek
> > ; Gao, Liming 
> > Subject: Re: [edk2] [PATCH] MdePkg: add big-endian MMIO
> > BaseBeIoLib
> >
> > On Fri, Apr 13, 2018 at 11:32:35PM +, Kinney,
> > Michael D wrote:
> > > Leif,
> > >
> > > I am curious why a Swap class/instances is not
> > sufficient.
> > >
> > > Currently EDK II follows the UEFI/PI specs, which for
> > > all supported CPU architectures use little endian
> > ABI.
> > > The BaseIoLib follows the endianness of the CPU.  If
> > > UEFI/PI added a CPU that was big endian, I would
> > expect
> > > BaseIoLib when built for that CPU would perform big
> > endian
> > > operations.
> > >
> > > Am I missing something?
> >
> > If you did add a big-endian CPU, you could then find
> > yourself in the
> > exact opposite situation and require a little-endian
> > i/o access
> > library. Which would be implemented exactly as the
> > contents of
> > IoLibSwap.c.
> >
> > The header file necessarily needs to be endianness-
> > specific, and if
> > the coding style had permitted functions in header
> > files, my automatic
> > reaction would have been to make all of these static
> > inline helper
> > functions (even with the code duplication).
> >
> > /
> > Leif
> >
> > > Mike
> > >
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-
> > > > boun...@lists.01.org] On Behalf Of Leif Lindholm
> > > > Sent: Friday, April 13, 2018 12:32 PM
> > > > To: Kinney, Michael D 
> > > > Cc: edk2-devel@lists.01.org; Laszlo Ersek
> > > > ; Gao, Liming
> > 
> > > > Subject: Re: [edk2] [PATCH] MdePkg: add big-endian
> > MMIO
> > > > BaseBeIoLib
> > > >
> > > > On Fri, Apr 13, 2018 at 07:24:06PM +, Kinney,
> > > > Michael D wrote:
> > > > > Hi Leif,
> > > > >
> > > > > I think we need to look at the names.  I see a
> > mix of
> > > > > "Be" and "Swap".  We should pick one and use it
> > > > > consistently.
> > > >
> > > > This was what I meant by the comments:
> > > > ---
> > > > This modified version introduces a single BeIoLib
> > > > instance, backed by
> > > > a source-file that could be used also for a
> > > > hypothetical LeIoLib.
> > > > There is no LeIoLib.h included though.
> > > >
> > > > While this is arguably overengineered, I do feel
> > > > reasonably strongly
> > > > that code should be named for what it does, not for
> > how
> > > > it is used,
> > > > and doing it this way lets me follow that rule.
> > > > ---
> > > >
> > > > Clearly this is open for discussion, but the above
> > is
> > > > my opinion and
> > > > the code intentionally reflects that.
> > > >
> > > > Regards,
> > > >
> > > > Leif
> > > >
> > > > > Mike
> > > > >
> > > > > > -Original Message-
> > > > > > From: Leif Lindholm
> > > > [mailto:leif.lindh...@linaro.org]
> > > > > > Sent: Friday, April 13, 2018 10:42 AM
> > > > > > To: edk2-devel@lists.01.org
> > > > > > Cc: Kinney, Michael D
> > ;
> > > > > > Gao, Liming ; Laszlo
> > Ersek
> > > > > > ; udit.ku...@nxp.com
> > > > > > Subject: [PATCH] MdePkg: add big-endian MMIO
> > > > > > BaseBeIoLib
> > > > > >
> > > > > > When performing MMIO to a destination of the
> > > > opposite
> > > > > > endianness to the
> > > > > > executing processor, this library provides
> > > > automatic
> > > > > > byte order reversal
> > > > > > on inputs and outputs.
> > > > > >
> > > > > > Contributed-under: TianoCore Contribution
> > Agreement
> > > > 1.1
> > > > > > Signed-off-by: Leif Lindholm
> > > > 
> > > > > > ---
> > > > > >
> > > > > > Udit, many apologies for this dragging out -
> > 

Re: [edk2] [PATCH] MdePkg: add big-endian MMIO BaseBeIoLib

[Udit Kumar]

Thanks Leif 
This is really useful, We will re-spin our patches based on this 
Regards
Udit

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Friday, April 13, 2018 11:12 PM
> To: edk2-devel@lists.01.org
> Cc: Michael D Kinney <michael.d.kin...@intel.com>; Liming Gao
> <liming@intel.com>; Laszlo Ersek <ler...@redhat.com>; Udit Kumar
> <udit.ku...@nxp.com>
> Subject: [PATCH] MdePkg: add big-endian MMIO BaseBeIoLib
> 
> When performing MMIO to a destination of the opposite endianness to the
> executing processor, this library provides automatic byte order reversal on
> inputs and outputs.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm <leif.lindh...@linaro.org>
> ---
> 
> Udit, many apologies for this dragging out - back-to-back conferences, 
> holidays,
> and lots of catching up.
> 
> This modified version introduces a single BeIoLib instance, backed by a 
> source-
> file that could be used also for a hypothetical LeIoLib.
> There is no LeIoLib.h included though.

I assume at present, there is no need of LeIoLib as specs itself supports LE 
only.

> While this is arguably overengineered, I do feel reasonably strongly that code
> should be named for what it does, not for how it is used, and doing it this 
> way
> lets me follow that rule.

You are being too futuristic  

Reviewed by Udit Kumar

> I have not duplicated the .uni file together with the .inf, since this 
> follows what
> is done in BaseIoLibIntrinsic.
> 
>  MdePkg/Include/Library/BeIoLib.h   | 376 +++
>  MdePkg/Library/BaseIoLibSwap/BaseBeIoLib.inf   |  48 +++
>  MdePkg/Library/BaseIoLibSwap/BaseIoLibSwap.uni |  23 ++
>  MdePkg/Library/BaseIoLibSwap/IoLibSwap.c   | 477
> +
>  MdePkg/MdePkg.dec  |   3 +
>  5 files changed, 927 insertions(+)
>  create mode 100644 MdePkg/Include/Library/BeIoLib.h  create mode 100644
> MdePkg/Library/BaseIoLibSwap/BaseBeIoLib.inf
>  create mode 100644 MdePkg/Library/BaseIoLibSwap/BaseIoLibSwap.uni
>  create mode 100644 MdePkg/Library/BaseIoLibSwap/IoLibSwap.c
> 
> diff --git a/MdePkg/Include/Library/BeIoLib.h
> b/MdePkg/Include/Library/BeIoLib.h
> new file mode 100644
> index 00..5b2dc1a8e1
> --- /dev/null
> +++ b/MdePkg/Include/Library/BeIoLib.h
> @@ -0,0 +1,376 @@
> +/** @file
> +  Provide byte-swapping services to access MMIO registers.
> +
> +Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved.
> +Copyright (c) 2017, AMD Incorporated. All rights reserved.
> +Copyright (c) 2018, Linaro 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
> +https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopens
> +ource.org%2Flicenses%2Fbsd-
> license.php=02%7C01%7Cudit.kumar%40nxp.
> +com%7C2f6c31eed3854caa00b408d5a165e4d7%7C686ea1d3bc2b4c6fa92cd9
> 9c5c3016
> +35%7C0%7C0%7C636592381374030897=c0FF7EKjnDdTqTMP%2BVDzjO
> BEhI5DE0F
> +jV8w5dOgIpoQ%3D=0
> +
> +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 __BE_IO_LIB_H__
> +#define __BE_IO_LIB_H__
> +
> +/**
> +  Reads a 16-bit MMIO register of opposite endianness.
> +
> +  Reads the 16-bit MMIO register specified by Address.
> +  The 16-bit read value is returned in reversed byte order.
> +  This function must guarantee that all MMIO read and write  operations
> + are serialized.
> +
> +  @param  Address The MMIO register to read.
> +
> +  @return The value read.
> +
> +**/
> +UINT16
> +EFIAPI
> +BeMmioRead16 (
> +  IN  UINTN Address
> +  );
> +
> +/**
> +  Writes a 16-bit MMIO register of opposite endianness.
> +
> +  Writes the 16-bit MMIO register specified by Address with the
> + byte-reversed  version of the value specified by Value and returns the 
> original
> Value.
> +  This function must guarantee that all MMIO read and write  operations
> + are serialized.
> +
> +  @param  Address The MMIO register to write.
> +  @param  Value   The value to write to the MMIO register.
> +
> +  @return Value.
> +
> +**/
> +UINT16
> +EFIAPI
> +BeMmioWrite16 (
> +  IN  UINTN Address,
> +  IN  UINT16Value
> +  );
> +
> +/**
> +  Reads a 16-bit MMIO register of opposi

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Udit Kumar]

Hi Laszlo/Leif,

For short term, is this ok to keep this lib under Silicon/NXP, here we are 
assuming  
CPU will always on be LE mode whereas IP can vary between LE/BE mode ?

For long term, we can discuss on APIs/name of Lib/Function name etc
We will update our code, as per agreement.

For me, Suggested approach is ok as well to keep CPU endianness in ARM package.
but need views from Ard/Leif here.

Thanks
Udit

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, February 23, 2018 4:17 PM
> To: Udit Kumar <udit.ku...@nxp.com>; Leif Lindholm
> <leif.lindh...@linaro.org>
> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> ard.biesheu...@linaro.org
> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
> for Big Endian Mmio APIs
> 
> On 02/23/18 11:25, Udit Kumar wrote:
> >
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >> Of Laszlo Ersek
> >> Sent: Thursday, February 22, 2018 7:26 PM
> >> To: Leif Lindholm <leif.lindh...@linaro.org>
> >> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> >> ard.biesheu...@linaro.org
> >> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add
> >> support for Big Endian Mmio APIs
> >>
> >> On 02/22/18 12:52, Leif Lindholm wrote:
> >>> On Thu, Feb 22, 2018 at 09:34:05AM +0100, Laszlo Ersek wrote:
> >>
> >>>>> But that brings back the complication as to how we have a driver
> >>>>> that needs an LE IO library to write output, and a BE IO library
> >>>>> to manipulate the hardware.
> >>>>
> >>>> Can you please explain the "write output" use case more precisely?
> >>>>
> >>>> My thinking would be this:
> >>>>
> >>>> - Use the IoLib class directly for "writing output" in little
> >>>> endian byte order (which is still unclear to me sorry).
> >>>
> >>> If the IoLib class is mapped to a an instance that byte-swaps
> >>> (hereto referred to as BeIoLib if IoLibSwap is unsuitable), would we
> >>> not then end up mapping the non-swapping, currently implemented in
> >>> BaseLibIoIntrinsic, variant as BeIoLib? Or if not, do we end up
> >>> needing to duplicated all IoLib implementation .infs to provide an
> >>> IoLib and a BeIoLib for each?
> >>>
> >>> It's at that point I burst an aneurysm.
> >>> Am I overthinking/underthinking this?
> >>
> >> We need two library classes, one for talking to LE devices and
> >> another to BE devices. These should be usable in a given module at
> >> the same time, as Ard says.
> >>
> >> Both library classes need to work on both LE and BE CPUs (working
> >> from your suggestion that UEFI might grow BE CPU support at some
> >> point). Whether that is implemented by dumb, separate library
> >> instances (yielding in total 2*2=4 library instances), or by smart,
> >> CPU-endianness-agnostic library instances (in total, 2), is a
> >> different question.
> >>
> >> Note that such "smarts" could be less than trivial to implement:
> >> - check CPU endianness in each library API?
> >> - or check in the lib constructor only, and flip some function
> >>   pointers?
> >> - use a dynamic PCD for caching CPU endianness?
> >> - use a HOB for the same?
> >> - use a lib global variable (for caching only on the module level)?
> >>
> >> I think the solution that saves the most on the *source* code size
> >> is:
> >> - introduce the BeIoLib class
> >> - duplicate the MMIO functions from BaseIoLibIntrinsic to the one
> >>   BeIoLib instance that we introduce
> >> - modify the MMIO functions in *both* lib instances (original LE, and
> >>   new BE), like this:
> >>
> >>   - If the CPU architecture is known to be bound to a single
> >> endianness, then hardcode the appropriate operation. This can be
> >> done with preprocessor macros, or with the architecture support
> >> of INF files / separate source files. For example, on IA32 and
> >> X64, the IoLib instance should work transparently,
> >> unconditionally, and the BeIoLib instance should byte-swap,
> >> unconditionally.
> >>
> >>   - On other CPU arches, all the wider-than-byte MMIO functions, in
> >> *both* lib instances should 

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Udit Kumar]

Hi Laszlo


> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, February 23, 2018 4:29 PM
> To: Udit Kumar <udit.ku...@nxp.com>; Pankaj Bansal
> <pankaj.ban...@nxp.com>; Leif Lindholm <leif.lindh...@linaro.org>
> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> ard.biesheu...@linaro.org; Meenakshi Aggarwal
> <meenakshi.aggar...@nxp.com>
> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
> for Big Endian Mmio APIs
> 
> On 02/23/18 11:39, Udit Kumar wrote:
> >
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Laszlo Ersek
> >> Sent: Friday, February 23, 2018 2:51 PM
> >> To: Pankaj Bansal <pankaj.ban...@nxp.com>; Leif Lindholm
> >> <leif.lindh...@linaro.org>
> >> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> >> ard.biesheu...@linaro.org
> >> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add
> support
> >> for Big Endian Mmio APIs
> >>
> >> On 02/23/18 09:40, Pankaj Bansal wrote:
> >>> Hi All
> >>>
> >>>> -Original Message-
> >>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> Of
> >>>> Laszlo Ersek
> >>>> Sent: Thursday, February 22, 2018 7:26 PM
> >>>> To: Leif Lindholm <leif.lindh...@linaro.org>
> >>>> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> >>>> ard.biesheu...@linaro.org
> >>>> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add
> >> support
> >>>> for Big Endian Mmio APIs
> >>>>
> >>>> On 02/22/18 12:52, Leif Lindholm wrote:
> >>>>> On Thu, Feb 22, 2018 at 09:34:05AM +0100, Laszlo Ersek wrote:
> >>>>
> >>>>>>> But that brings back the complication as to how we have a driver
> >>>>>>> that needs an LE IO library to write output, and a BE IO library to
> >>>>>>> manipulate the hardware.
> >>>>>>
> >>>>>> Can you please explain the "write output" use case more precisely?
> >>>>>>
> >>>>>> My thinking would be this:
> >>>>>>
> >>>>>> - Use the IoLib class directly for "writing output" in little endian
> >>>>>> byte order (which is still unclear to me sorry).
> >>>>>
> >>>>> If the IoLib class is mapped to a an instance that byte-swaps (hereto
> >>>>> referred to as BeIoLib if IoLibSwap is unsuitable), would we not then
> >>>>> end up mapping the non-swapping, currently implemented in
> >>>>> BaseLibIoIntrinsic, variant as BeIoLib? Or if not, do we end up
> >>>>> needing to duplicated all IoLib implementation .infs to provide an
> >>>>> IoLib and a BeIoLib for each?
> >>>>>
> >>>>> It's at that point I burst an aneurysm.
> >>>>> Am I overthinking/underthinking this?
> >>>>
> >>>> We need two library classes, one for talking to LE devices and another
> to
> >> BE
> >>>> devices. These should be usable in a given module at the same time, as
> >> Ard
> >>>> says.
> >>>>
> >>>> Both library classes need to work on both LE and BE CPUs (working
> from
> >> your
> >>>> suggestion that UEFI might grow BE CPU support at some point).
> >>>> Whether that is implemented by dumb, separate library instances
> >> (yielding in
> >>>> total 2*2=4 library instances), or by smart, CPU-endianness-agnostic
> >> library
> >>>> instances (in total, 2), is a different question.
> >>>>
> >>>> Note that such "smarts" could be less than trivial to implement:
> >>>> - check CPU endianness in each library API?
> >>>> - or check in the lib constructor only, and flip some function pointers?
> >>>> - use a dynamic PCD for caching CPU endianness?
> >>>> - use a HOB for the same?
> >>>> - use a lib global variable (for caching only on the module level)?
> >>>>
> >>>> I think the solution that saves the most on the *source* code size is:
> >>>> - introduce the BeIoLib class
> >>>> - duplicate the MMIO f

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Udit Kumar]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Friday, February 23, 2018 2:51 PM
> To: Pankaj Bansal ; Leif Lindholm
> 
> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> ard.biesheu...@linaro.org
> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
> for Big Endian Mmio APIs
> 
> On 02/23/18 09:40, Pankaj Bansal wrote:
> > Hi All
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Laszlo Ersek
> >> Sent: Thursday, February 22, 2018 7:26 PM
> >> To: Leif Lindholm 
> >> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> >> ard.biesheu...@linaro.org
> >> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add
> support
> >> for Big Endian Mmio APIs
> >>
> >> On 02/22/18 12:52, Leif Lindholm wrote:
> >>> On Thu, Feb 22, 2018 at 09:34:05AM +0100, Laszlo Ersek wrote:
> >>
> > But that brings back the complication as to how we have a driver
> > that needs an LE IO library to write output, and a BE IO library to
> > manipulate the hardware.
> 
>  Can you please explain the "write output" use case more precisely?
> 
>  My thinking would be this:
> 
>  - Use the IoLib class directly for "writing output" in little endian
>  byte order (which is still unclear to me sorry).
> >>>
> >>> If the IoLib class is mapped to a an instance that byte-swaps (hereto
> >>> referred to as BeIoLib if IoLibSwap is unsuitable), would we not then
> >>> end up mapping the non-swapping, currently implemented in
> >>> BaseLibIoIntrinsic, variant as BeIoLib? Or if not, do we end up
> >>> needing to duplicated all IoLib implementation .infs to provide an
> >>> IoLib and a BeIoLib for each?
> >>>
> >>> It's at that point I burst an aneurysm.
> >>> Am I overthinking/underthinking this?
> >>
> >> We need two library classes, one for talking to LE devices and another to
> BE
> >> devices. These should be usable in a given module at the same time, as
> Ard
> >> says.
> >>
> >> Both library classes need to work on both LE and BE CPUs (working from
> your
> >> suggestion that UEFI might grow BE CPU support at some point).
> >> Whether that is implemented by dumb, separate library instances
> (yielding in
> >> total 2*2=4 library instances), or by smart, CPU-endianness-agnostic
> library
> >> instances (in total, 2), is a different question.
> >>
> >> Note that such "smarts" could be less than trivial to implement:
> >> - check CPU endianness in each library API?
> >> - or check in the lib constructor only, and flip some function pointers?
> >> - use a dynamic PCD for caching CPU endianness?
> >> - use a HOB for the same?
> >> - use a lib global variable (for caching only on the module level)?
> >>
> >> I think the solution that saves the most on the *source* code size is:
> >> - introduce the BeIoLib class
> >> - duplicate the MMIO functions from BaseIoLibIntrinsic to the one
> >>   BeIoLib instance that we introduce
> >> - modify the MMIO functions in *both* lib instances (original LE, and
> >>   new BE), like this:
> >>
> >>   - If the CPU architecture is known to be bound to a single endianness,
> >> then hardcode the appropriate operation. This can be done with
> >> preprocessor macros, or with the architecture support of INF files /
> >> separate source files. For example, on IA32 and X64, the IoLib
> >> instance should work transparently, unconditionally, and the BeIoLib
> >> instance should byte-swap, unconditionally.
> >>
> >>   - On other CPU arches, all the wider-than-byte MMIO functions, in
> >> *both* lib instances should do something like this:
> >>
> >> //
> >> // at file scope
> >> //
> >> STATIC CONST UINT16 mOne = 1;
> >>
> >> //
> >> // at function scope
> >> //
> >> if (*(CONST UINT8 *) == 1) {
> >>   //
> >>   // CPU in LE mode:
> >>   // - work transparently in the IoLib instance
> >>   // - byte-swap in the BeIoLib instance
> >>   //
> >> } else {
> >>   //
> >>   // CPU in BE mode:
> >>   // - byte-swap in the IoLib instance
> >>   // - work transparently in the BeIoLib instance
> >>   //
> >> }
> >
> > I suggest this approach :
> >
> > 1. Add BeMmio* functions in existing IoLib. BeMmio* functions will swap
> the input before write and swap output after read and so on.
> > Mmio* functions will not perform any byte swapping
> > 2. create second instance (a copy) of this IoLib for CPUs that are Big 
> > Endian.
> We can call it BigEndianIoLib.
> >  In this library Mmio* functions will swap the input before write and
> swap output after read and so on.
> >  BeMmio* functions will not perform any byte swapping.
> > 3. Include the instance of IoLib in dsc file based on cpu endianness that 
> > the
> platform 

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Udit Kumar]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Thursday, February 22, 2018 7:26 PM
> To: Leif Lindholm 
> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> ard.biesheu...@linaro.org
> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
> for Big Endian Mmio APIs
> 
> On 02/22/18 12:52, Leif Lindholm wrote:
> > On Thu, Feb 22, 2018 at 09:34:05AM +0100, Laszlo Ersek wrote:
> 
> >>> But that brings back the complication as to how we have a driver
> >>> that needs an LE IO library to write output, and a BE IO library to
> >>> manipulate the hardware.
> >>
> >> Can you please explain the "write output" use case more precisely?
> >>
> >> My thinking would be this:
> >>
> >> - Use the IoLib class directly for "writing output" in little endian
> >> byte order (which is still unclear to me sorry).
> >
> > If the IoLib class is mapped to a an instance that byte-swaps (hereto
> > referred to as BeIoLib if IoLibSwap is unsuitable), would we not then
> > end up mapping the non-swapping, currently implemented in
> > BaseLibIoIntrinsic, variant as BeIoLib? Or if not, do we end up
> > needing to duplicated all IoLib implementation .infs to provide an
> > IoLib and a BeIoLib for each?
> >
> > It's at that point I burst an aneurysm.
> > Am I overthinking/underthinking this?
> 
> We need two library classes, one for talking to LE devices and another to BE
> devices. These should be usable in a given module at the same time, as Ard
> says.
> 
> Both library classes need to work on both LE and BE CPUs (working from
> your suggestion that UEFI might grow BE CPU support at some point).
> Whether that is implemented by dumb, separate library instances (yielding
> in total 2*2=4 library instances), or by smart, CPU-endianness-agnostic
> library instances (in total, 2), is a different question.
> 
> Note that such "smarts" could be less than trivial to implement:
> - check CPU endianness in each library API?
> - or check in the lib constructor only, and flip some function pointers?
> - use a dynamic PCD for caching CPU endianness?
> - use a HOB for the same?
> - use a lib global variable (for caching only on the module level)?
> 
> I think the solution that saves the most on the *source* code size is:
> - introduce the BeIoLib class
> - duplicate the MMIO functions from BaseIoLibIntrinsic to the one
>   BeIoLib instance that we introduce
> - modify the MMIO functions in *both* lib instances (original LE, and
>   new BE), like this:
> 
>   - If the CPU architecture is known to be bound to a single endianness,
> then hardcode the appropriate operation. This can be done with
> preprocessor macros, or with the architecture support of INF files /
> separate source files. For example, on IA32 and X64, the IoLib
> instance should work transparently, unconditionally, and the BeIoLib
> instance should byte-swap, unconditionally.
> 
>   - On other CPU arches, all the wider-than-byte MMIO functions, in
> *both* lib instances should do something like this:
> 
> //
> // at file scope
> //
> STATIC CONST UINT16 mOne = 1;
> 
> //
> // at function scope
> //
> if (*(CONST UINT8 *) == 1) {
>   //
>   // CPU in LE mode:
>   // - work transparently in the IoLib instance
>   // - byte-swap in the BeIoLib instance
>   //
> } else {
>   //
>   // CPU in BE mode:
>   // - byte-swap in the IoLib instance
>   // - work transparently in the BeIoLib instance
>   //
> }

You meant, sort of cpu_to_le and cpu_to_be sort of APIs 
Thanks
Udit
 
> Thanks,
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.
> 01.org%2Fmailman%2Flistinfo%2Fedk2-
> devel=02%7C01%7Cudit.kumar%40nxp.com%7C930d96bb226d4491df2
> d08d579fc1717%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63654
> 9046016636482=0uPLjiDP60oNVSdbh44gostMx2id%2BzdLYjk8t%2BLwJ
> tU%3D=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC PATCH] MdePkg: add byte-swapping MMIO BaseIoLibSwap

[Udit Kumar]

Hi Ard. 

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, February 21, 2018 11:39 PM
> To: Leif Lindholm <leif.lindh...@linaro.org>
> Cc: edk2-devel@lists.01.org; Michael D Kinney
> <michael.d.kin...@intel.com>; Liming Gao <liming@intel.com>;
> Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>; Udit Kumar
> <udit.ku...@nxp.com>; Varun Sethi <v.se...@nxp.com>
> Subject: Re: [RFC PATCH] MdePkg: add byte-swapping MMIO BaseIoLibSwap
> 
> On 21 February 2018 at 15:25, Leif Lindholm <leif.lindh...@linaro.org>
> wrote:
> > When performing MMIO to a destination of the opposite endianness to
> > the executing processor, this library provides automatic byte order
> > reversal on inputs and outputs.
> >
> 
> As pointed out by Laszlo, 'opposite' is ill defined, as it is not a property 
> of
> the device nor is it a property of the CPU/platform (even though UEFI is
> likely to remain little endian for the foreseeable
> future)

Is this assumption, of part of UEFI specs ?
 
> So BigEndianIoLib seems more appropriate as a library class, and it does
> need to be a separate class so that a single driver can perform both LE and
> BE MMIO (which, as was pointed out, is the case for any driver that drives a
> BE MMIO peripheral but uses LE MMIO for serial port DEBUG output)

Yes, We need two lib here, we can discuss on name.

Thanks 
Udit 

> 
> 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Leif Lindholm <leif.lindh...@linaro.org>
> > ---
> >
> > As promised in the dark and distant past:
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w
> > .mail-archive.com%2Fedk2-
> devel%40lists.01.org%2Fmsg33447.html=02%
> >
> 7C01%7Cudit.kumar%40nxp.com%7C503430fe81e544d1df8b08d57956346f%7
> C686ea
> >
> 1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636548333521065509=
> AR1g64t
> > C4ag8V18MYGN5bimkXe7FQj%2BEYbzONr%2BLFXM%3D=0
> >
> > This starts out as a clone of MdePkg/Include/Library/IoLib.h,
> > implementing simple wrappers that depend on an IoLib instance to
> > perform any actual accesses.
> >
> > Comments are mostly nonsense, since they've not been changed from
> > their originals in IoLib.h. If people feel this library is a sensible
> > approach, I'll fix that up before I send a v1.
> >
> > I have explicitly excluded:
> > - non-MMIO accesses (could you really end up with mixed endianness in
> >   such a system?)
> > - bitfields (would either require duplicating code or merging this all
> >   into the BaseIoLibIntrinsic module, which is already a bit on the
> >   bloated side)
> > - buffers operations (let's avoid those until we find we need them)
> >
> > MdePkg/Include/Library/IoLibSwap.h | 395 
> 
> If you create a library class, please declare it in the .dec file
> 
> >  MdePkg/Library/BaseIoLibSwap/BaseIoLibSwap.inf |  44 +++
> > MdePkg/Library/BaseIoLibSwap/BaseIoLibSwap.uni |  23 ++
> >  MdePkg/Library/BaseIoLibSwap/IoLibSwap.c   | 491
> +
> >  MdePkg/MdePkg.dec  |   3 +
> >  MdePkg/MdePkg.dsc  |   1 +
> >  6 files changed, 957 insertions(+)
> >  create mode 100644 MdePkg/Include/Library/IoLibSwap.h
> >  create mode 100644 MdePkg/Library/BaseIoLibSwap/BaseIoLibSwap.inf
> >  create mode 100644 MdePkg/Library/BaseIoLibSwap/BaseIoLibSwap.uni
> >  create mode 100644 MdePkg/Library/BaseIoLibSwap/IoLibSwap.c
> >
> > diff --git a/MdePkg/Include/Library/IoLibSwap.h
> > b/MdePkg/Include/Library/IoLibSwap.h
> > new file mode 100644
> > index 00..f13c8d86e7
> > --- /dev/null
> > +++ b/MdePkg/Include/Library/IoLibSwap.h
> > @@ -0,0 +1,395 @@
> > +/** @file
> > +  Provide byte-swapping services to access MMIO registers.
> > +
> > +Copyright (c) 2006 - 2012, Intel Corporation. All rights
> > +reserved. Copyright (c) 2017, AMD Incorporated. All rights
> > +reserved. Copyright (c) 2018, Linaro 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
> >
> +https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fope
> > +nsource.org%2Flicenses%2Fbsd-
> license.php=02%7C01%7Cudit.kumar%40
> >
> +nxp.com%7C503430fe81e544d1df8b08d57956346f%7C686ea1d

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Udit Kumar]

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Wednesday, February 21, 2018 9:16 PM
> Subject: Re: [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big
> Endian Mmio APIs
> 
> Apologies for dropping the ball on this series during my sabbatical.
> 
> For this particular patch, I would still like to see a core library provide 
> the
> needed functionality. I just sent out an RFC of a possible implementation.
> 
> Regardless, a key point is that this isn't about "big-endian", it is about
> endianness opposite to the executing processor.

Ok.
But We should know endianness of CPU and associated IP at the start. 
Most of time  We are in little endian mode, therefore we had BeMmioxx.

Anyway for me this is ok to rename as SwapMmioxx, if you are making
CPU endianness variant as well.

> /
> Leif
> 
> On Fri, Feb 16, 2018 at 02:19:57PM +0530, Meenakshi wrote:
> > From: Meenakshi Aggarwal 
> >
> > This library add supports for BE read/write and other MMIO helper
> > function.
> > In this data swapped after reading from MMIO and before write using
> > MMIO.
> > It can be used by any module with BE address space.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Meenakshi Aggarwal 
> > ---
> >  Silicon/NXP/Include/Library/BeIoLib.h   | 332
> ++
> >  Silicon/NXP/Library/BeIoLib/BeIoLib.c   | 400
> 
> >  Silicon/NXP/Library/BeIoLib/BeIoLib.inf |  31 +++
> >  3 files changed, 763 insertions(+)
> >  create mode 100644 Silicon/NXP/Include/Library/BeIoLib.h
> >  create mode 100644 Silicon/NXP/Library/BeIoLib/BeIoLib.c
> >  create mode 100644 Silicon/NXP/Library/BeIoLib/BeIoLib.inf
> >
> > diff --git a/Silicon/NXP/Include/Library/BeIoLib.h
> > b/Silicon/NXP/Include/Library/BeIoLib.h
> > new file mode 100644
> > index 000..a58883a
> > --- /dev/null
> > +++ b/Silicon/NXP/Include/Library/BeIoLib.h
> > @@ -0,0 +1,332 @@
> > +/** BeIoLib.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
> > + *
> >
> +https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fope
> > +nsource.org%2Flicenses%2Fbsd-
> license.php=02%7C01%7Cudit.kumar%40
> >
> +nxp.com%7Cf911978f84484376f56e08d5794237e8%7C686ea1d3bc2b4c6fa92
> cd99c
> >
> +5c301635%7C0%7C0%7C636548247671415204=GTzQcn%2FbZmfV41%
> 2BwBELVN
> > +n1OUYJ3zz2ARFG6kF2rvcg%3D=0
> > + *
> > + *  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 __BE_IOLIB_H__
> > +#define __BE_IOLIB_H__
> > +
> > +#include 
> > +
> > +/**
> > +  MmioRead8 for Big-Endian modules.
> > +
> > +  @param  Address The MMIO register to read.
> > +
> > +  @return The value read.
> > +
> > +**/
> > +UINT8
> > +EFIAPI
> > +BeMmioRead8 (
> > +  IN  UINTN Address
> > +  );
> > +
> > +/**
> > +  MmioRead16 for Big-Endian modules.
> > +
> > +  @param  Address The MMIO register to read.
> > +
> > +  @return The value read.
> > +
> > +**/
> > +UINT16
> > +EFIAPI
> > +BeMmioRead16 (
> > +  IN  UINTN Address
> > +  );
> > +
> > +/**
> > +  MmioRead32 for Big-Endian modules.
> > +
> > +  @param  Address The MMIO register to read.
> > +
> > +  @return The value read.
> > +
> > +**/
> > +UINT32
> > +EFIAPI
> > +BeMmioRead32 (
> > +  IN  UINTN Address
> > +  );
> > +
> > +/**
> > +  MmioRead64 for Big-Endian modules.
> > +
> > +  @param  Address The MMIO register to read.
> > +
> > +  @return The value read.
> > +
> > +**/
> > +UINT64
> > +EFIAPI
> > +BeMmioRead64 (
> > +  IN  UINTN Address
> > +  );
> > +
> > +/**
> > +  MmioWrite8 for Big-Endian modules.
> > +
> > +  @param  Address The MMIO register to write.
> > +  @param  Value   The value to write to the MMIO register.
> > +
> > +**/
> > +UINT8
> > +EFIAPI
> > +BeMmioWrite8 (
> > +  IN  UINTN Address,
> > +  IN  UINT8 Value
> > +  );
> > +
> > +/**
> > +  MmioWrite16 for Big-Endian modules.
> > +
> > +  @param  Address The MMIO register to write.
> > +  @param  Value   The value to write to the MMIO register.
> > +
> > +**/
> > +UINT16
> > +EFIAPI
> > +BeMmioWrite16 (
> > +  IN  UINTN Address,
> > +  IN  UINT16Value
> > +  );
> > +
> > +/**
> > +  MmioWrite32 for Big-Endian modules.
> > +
> > +  @param  Address The MMIO register to write.
> > +  @param  Value   The value to write to the MMIO register.
> > +
> > +**/
> > +UINT32
> > +EFIAPI
> > +BeMmioWrite32 (
> > +  IN  UINTN Address,
> > +  IN  UINT32Value
> > +  );
> > +
> > +/**
> > +  MmioWrite64 for Big-Endian modules.
> > +
> > +  @param  Address The MMIO register to write.
> > 

[edk2] [ArmPlatformPkg][Patch] reset x11 before use

[Udit Kumar]

This patch reset x11 to zero before using it.
x11 is marked as caller saved register, therefore before using it
default (reset) value should be assigned.

If ArmPlatformPeiBootAction function is using x11 then some of
calculation in this routine may go wrong.

Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: Udit Kumar <udit.ku...@nxp.com>
---
 ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S 
b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
index a81709d..d391fc1 100644
--- a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
+++ b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
@@ -60,6 +60,7 @@ _SetupStack:
   // Because the 'push' instruction is equivalent to 'stmdb' (decrement 
before), we need to increment
   // one to the top of the stack. We check if incrementing one does not 
overflow (case of DRAM at the
   // top of the memory space)
+  mov x11, 0
   adds  x11, x1, #1
   b.cs  _SetupOverflowStack
 
-- 
1.9.1

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

Re: [edk2] [RFC] SATA : Implemented NXP errata A008402

[Udit Kumar]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, January 10, 2018 3:23 PM
> To: Udit Kumar <udit.ku...@nxp.com>
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Meenakshi Aggarwal
> <meenakshi.aggar...@nxp.com>; edk2-devel@lists.01.org; Zeng, Star
> <star.z...@intel.com>; leif.lindh...@linaro.org
> Subject: Re: [edk2] [RFC] SATA : Implemented NXP errata A008402
> 
> On 10 January 2018 at 09:43, Udit Kumar <udit.ku...@nxp.com> wrote:
> > Hi Ruiyu,
> >
> >> -Original Message-
> >> >
> >> > And this change will not impact any other hardware so no one is
> >> > basically
> >> impacted by this change.
> >>
> >> Your buggy HW only need the value zero. But the addition of PCD
> >> exposes an interface that can use any size of PRD.
> >> I am not sure the AtaAtapiPassThru can work if some platform sets the
> >> PCD value to others than 0 or 3F_h.
> >
> > I don't see someone using this driver will set Pcd randomly, but I
> > agree on this point other value should be handled.
> > Error or Assert could be added, if Pcd value is not 0 or 3F_h.
> >
> >> Can you please
> >>   just duplicate the AtaAtapiPassThru in your platform?
> >> Because the driver is very stable today, not much code sync effort
> >> will be needed if core version is changed.
> >
> > Duplicating is always a possibility :), but When we will push this
> > duplicated driver (just for one line change) for upstreaming.
> > will this be acceptable ??
> 
> My main concern with this (and with using a PCD) is that the setting affects
> all SATA controllers in the system, including ones the you stick into a PCIe
> slot.

Agreed,  If two types of Sata controllers are used then this patch 
may break one controller. 
At present, we don’t have anyone asking SATA controller behind PCIe
but we shouldn’t ignore this. This is valid use case. 

> So I think forking the driver is the only possible solution, but it will not 
> be a
> one-line change: you need to ensure that you apply the workaround only to
> the SATA controllers in the SoC.

Yes, Considering unrelated SATA controllers this will be more than copy 

> --
> Ard.

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

Re: [edk2] [RFC] SATA : Implemented NXP errata A008402

[Udit Kumar]

Hi Ruiyu, 

> -Original Message-
> >
> > And this change will not impact any other hardware so no one is basically
> impacted by this change.
> 
> Your buggy HW only need the value zero. But the addition of PCD exposes
> an interface that can use any size of PRD.
> I am not sure the AtaAtapiPassThru can work if some platform sets the PCD
> value to others than 0 or 3F_h.

I don't see someone using this driver will set Pcd randomly, but I agree on this
point other value should be handled. 
Error or Assert could be added, if Pcd value is not 0 or 3F_h.

> Can you please
>   just duplicate the AtaAtapiPassThru in your platform?
> Because the driver is very stable today, not much code sync effort will be
> needed if core version is changed.

Duplicating is always a possibility :), but When we will push this duplicated 
driver
(just for one line change) for upstreaming.
will this be acceptable ??

Thanks

 
> >
> >>>
> >>> Workaround:
> >>> Set PRD length to 0 when creating a PRD entry for a maximum data
> >>> transfer size of 4 MB to fix the erratum.
> >>>
> >>> Contributed-under: TianoCore Contribution Agreement 1.1
> >>> Signed-off-by: Meenakshi Aggarwal 
> >>> ---
> >>>MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c   | 2 +-
> >>>MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf | 1 +
> >>>MdeModulePkg/MdeModulePkg.dec  | 3 +++
> >>>3 files changed, 5 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
> >> b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
> >>> index e6de5d6..fb6dc0b 100644
> >>> --- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
> >>> +++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
> >>> @@ -591,7 +591,7 @@ AhciBuildCommand (
> >>>if (RemainedData < EFI_AHCI_MAX_DATA_PER_PRDT) {
> >>>  AhciRegisters->AhciCommandTable-
> >>> PrdtTable[PrdtIndex].AhciPrdtDbc = (UINT32)RemainedData - 1;
> >>>} else {
> >>> -  AhciRegisters->AhciCommandTable-
> >>> PrdtTable[PrdtIndex].AhciPrdtDbc = EFI_AHCI_MAX_DATA_PER_PRDT - 1;
> >>> +  AhciRegisters->AhciCommandTable-
> >>> PrdtTable[PrdtIndex].AhciPrdtDbc = PcdGet32 (PcdPrdtMaxDataLength);
> >>>}
> >>>
> >>>Data64.Uint64 = (UINT64)MemAddr; diff --git
> >> a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
> >> b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
> >>> index 82d5f7a..8921dd5 100644
> >>> --- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
> >>> +++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
> >>> @@ -70,6 +70,7 @@
> >>>
> >>>[Pcd]
> >>>  gEfiMdeModulePkgTokenSpaceGuid.PcdAtaSmartEnable   ##
> >> SOMETIMES_CONSUMES
> >>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdPrdtMaxDataLength
> >>>
> >>># [Event]
> >>># EVENT_TYPE_PERIODIC_TIMER ## SOMETIMES_CONSUMES diff --git
> >>> a/MdeModulePkg/MdeModulePkg.dec
> >> b/MdeModulePkg/MdeModulePkg.dec
> >>> index 8efad57..b2f9f2b 100644
> >>> --- a/MdeModulePkg/MdeModulePkg.dec
> >>> +++ b/MdeModulePkg/MdeModulePkg.dec
> >>> @@ -1434,6 +1434,9 @@
> >>>  # @Prompt Console Output Row of Text Setup
> >>>
> >>
> gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutRow|25|UINT32|0x40
> >> 0e
> >>>
> >>> +  ## This PCD specifies the Maximum data length for a PRD Entry
> >>> +
> >>
> gEfiMdeModulePkgTokenSpaceGuid.PcdPrdtMaxDataLength|0x3F|UIN
> >> T32|0x400f
> >>> +
> >>>[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic,
> >> PcdsDynamicEx]
> >>>  ## UART clock frequency is for the baud rate configuration.
> >>>  # @Prompt Serial Port Clock Rate.
> >>>
> >>
> >>
> >> --
> >> Thanks,
> >> Ray
> >> ___
> >> edk2-devel mailing list
> >> edk2-devel@lists.01.org
> >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> >> st
> >> s.01.org%2Fmailman%2Flistinfo%2Fedk2-
> >>
> devel=02%7C01%7Cmeenakshi.aggarwal%40nxp.com%7C60cadf13ac95
> >>
> 48486c4908d55712d85c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %
> >>
> 7C636510660888390946=4oW2agf8z869IMz%2F7%2B2di9vC%2BB3js7K
> >> hJx1LR2b4Tc4%3D=0
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
> > ts.01.org%2Fmailman%2Flistinfo%2Fedk2-
> devel=02%7C01%7Cudit.kumar%
> >
> 40nxp.com%7C0b697e2364f348745a7c08d5580cf5bf%7C686ea1d3bc2b4c6fa9
> 2cd99
> >
> c5c301635%7C0%7C0%7C636511735060291299=eWI7ueE5wzr2oSNv0t
> CP5hBE0
> > uEfB9S0PyABHWocBaA%3D=0
> >
> 
> 
> --
> Thanks,
> Ray
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.
> 01.org%2Fmailman%2Flistinfo%2Fedk2-
> devel=02%7C01%7Cudit.kumar%40nxp.com%7C0b697e2364f348745a7c
> 

Re: [edk2] [PATCH] ArmPlatformPkg/MemoryInitPeiLib: mark primary FV region as boot services data

[Udit Kumar]

Thanks Ard, 
This works for us as well 
Few comments inline 


Regards
Udit

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, January 02, 2018 9:21 PM
> To: edk2-devel@lists.01.org
> Cc: leif.lindh...@linaro.org; vladimir.olovyanni...@broadcom.com; Udit
> Kumar <udit.ku...@nxp.com>; Meenakshi Aggarwal
> <meenakshi.aggar...@nxp.com>; Ard Biesheuvel
> <ard.biesheu...@linaro.org>
> Subject: [PATCH] ArmPlatformPkg/MemoryInitPeiLib: mark primary FV region
> as boot services data
> 
> Commit 8ae5fc182941 ("ArmPlatformPkg/MemoryInitPeiLib: don't reserve
> primary FV in memory") deleted the code that removes the memory covering
> the primary firmware volume from the memory map. The assumption was
> that
> this is no longer necessary now that we no longer expose compression and
> PE/COFF loader library code from the PrePi module to DXE core.
> 
> However, the FV is still declared, and so code may attempt to access it
> anyway, which may cause unexpected results depending on whether the
> memory has been reused for other purposes in the mean time.
> 
> So reinstate the code that splits off the resource descriptor HOB that
> describes the firmware device, but this time, don't mark the memory as
> unusable, but create a memory allocation HOB that marks the region as
> boot services data.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> ---
> Vladimir, Udit, Meenakshi: please confirm whether this code works for you.
> 
>  ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c | 74
> 
>  1 file changed, 74 insertions(+)
> 
> diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> index d03214b5df66..d1b5c0be9497 100644
> --- a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> +++ b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> @@ -70,7 +70,11 @@ MemoryPeim (
>  {
>ARM_MEMORY_REGION_DESCRIPTOR *MemoryTable;
>EFI_RESOURCE_ATTRIBUTE_TYPE  ResourceAttributes;
> +  UINT64   ResourceLength;
>EFI_PEI_HOB_POINTERS NextHob;
> +  EFI_PHYSICAL_ADDRESS FdTop;
> +  EFI_PHYSICAL_ADDRESS SystemMemoryTop;
> +  EFI_PHYSICAL_ADDRESS ResourceTop;
>BOOLEAN  Found;
> 
>// Get Virtual Memory Map from the Platform Library
> @@ -117,6 +121,76 @@ MemoryPeim (
>  );
>}
> 
> +  //
> +  // Reserve the memory space occupied by the firmware volume
> +  //
> +
> +  SystemMemoryTop = (EFI_PHYSICAL_ADDRESS)PcdGet64
> (PcdSystemMemoryBase) + (EFI_PHYSICAL_ADDRESS)PcdGet64
> (PcdSystemMemorySize);
> +  FdTop = (EFI_PHYSICAL_ADDRESS)PcdGet64 (PcdFdBaseAddress) +
> (EFI_PHYSICAL_ADDRESS)PcdGet32 (PcdFdSize);
> +
> +  // EDK2 does not have the concept of boot firmware copied into DRAM. To
> avoid the DXE
> +  // core to overwrite this area we must create a memory allocation HOB for
> the region,
> +  // but this only works if we split off the underlying resource descriptor 
> as
> well.
> +  if ((PcdGet64 (PcdFdBaseAddress) >= PcdGet64 (PcdSystemMemoryBase))
> && (FdTop <= SystemMemoryTop)) {
> +Found = FALSE;
> +
> +// Search for System Memory Hob that contains the firmware
> +NextHob.Raw = GetHobList ();
> +while ((NextHob.Raw = GetNextHob
> (EFI_HOB_TYPE_RESOURCE_DESCRIPTOR, NextHob.Raw)) != NULL) {
> +  if ((NextHob.ResourceDescriptor->ResourceType ==
> EFI_RESOURCE_SYSTEM_MEMORY) &&
> +  (PcdGet64 (PcdFdBaseAddress) >= NextHob.ResourceDescriptor-
> >PhysicalStart) &&
> +  (FdTop <= NextHob.ResourceDescriptor->PhysicalStart +
> NextHob.ResourceDescriptor->ResourceLength))
> +  {
> +ResourceAttributes = NextHob.ResourceDescriptor->ResourceAttribute;
> +ResourceLength = NextHob.ResourceDescriptor->ResourceLength;
> +ResourceTop = NextHob.ResourceDescriptor->PhysicalStart +
> ResourceLength;
> +
> +if (PcdGet64 (PcdFdBaseAddress) == NextHob.ResourceDescriptor-
> >PhysicalStart) {
> +  if (SystemMemoryTop != FdTop) {
> +// Create the System Memory HOB for the firmware with the non-
> present attribute

Please correct comments, now this memory is present 

> +BuildResourceDescriptorHob (EFI_RESOURCE_SYSTEM_MEMORY,
> +ResourceAttributes,
> +PcdGet64 (PcdFdBaseAddress),
> +PcdGet32 (PcdFdSize))

Re: [edk2] [PATCH 5/7] ArmPlatformPkg/MemoryInitPeiLib: don't reserve primary FV in memory

[Udit Kumar]

Hi Vladimir
How re-allocation or say drivers are dispatched on your system. 
Could you check addresses, where FV is kept and where this is getting 
dispatched 

Thx 
Udit

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Vladimir Olovyannikov
> Sent: Wednesday, December 27, 2017 3:22 AM
> To: Ard Biesheuvel <ard.biesheu...@linaro.org>; edk2-devel@lists.01.org
> Cc: leif.lindh...@linaro.org
> Subject: Re: [edk2] [PATCH 5/7] ArmPlatformPkg/MemoryInitPeiLib: don't
> reserve primary FV in memory
> 
> Hi Ard, Meenakshi,
> 
> I am having a problem I cannot explain the reason for, with this commit on
> an ARM64 platform.
> 
>ArmPlatformPkg/MemoryInitPeiLib: don't reserve primary FV in memory
> 
> Now that PrePi no longer exposes its internal code via special HOBs,
> we can remove the special handling of the primary FV, which needed to
> be reserved so that DXE core could call into the PE/COFF and LZMA
> libraries in the PrePi module.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Udit Kumar <udit.ku...@nxp.com>
> Signed-off-by: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>
> [ardb: updated commit log]
> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>
> 
> If a Shell is built "as is" from the source tree, there are no issues.
> However, if I slightly modify Shell.c like in the following patch:
> 
> diff --git a/ShellPkg/Application/Shell/Shell.c
> b/ShellPkg/Application/Shell/Shell.c
> index 577e17311bea..bbbdde8ced96 100644
> --- a/ShellPkg/Application/Shell/Shell.c
> +++ b/ShellPkg/Application/Shell/Shell.c
> @@ -339,6 +339,11 @@ UefiMain (
>EFI_HANDLE  ConInHandle;
>EFI_SIMPLE_TEXT_INPUT_PROTOCOL  *OldConIn;
>SPLIT_LIST  *Split;
> +  CHAR16  *DelayStr;
> +  CHAR16  *NoMapStr;
> +  UINTN   DelayVarSize;
> +  UINTN   NoMapVarSize;
> +  BOOLEAN SilentStart;
> 
>if (PcdGet8(PcdShellSupportLevel) > 3) {
>  return (EFI_UNSUPPORTED);
> @@ -360,6 +365,7 @@ UefiMain (
>ShellInfoObject.PageBreakEnabled=
> PcdGetBool(PcdShellPageBreakDefault);
>ShellInfoObject.ViewingSettings.InsertMode  =
> PcdGetBool(PcdShellInsertModeDefault);
>ShellInfoObject.LogScreenCount  = PcdGet8
> (PcdShellScreenLogCount  );
> +  SilentStart = FALSE;
> 
>//
>// verify we dont allow for spec violation @@ -452,6 +458,21 @@ UefiMain
> (
>goto FreeResources;
>  }
> 
> +if (!ShellInfoObject.ShellInitSettings.BitUnion.Bits.Delay) {
> +  // Command line has priority over the variable
> +  Status = ShellFindEnvVarInList(L"startupdelay", ,
> , NULL);
> +  if (!EFI_ERROR (Status)) {
> +ShellInfoObject.ShellInitSettings.Delay = ShellStrToUintn
> (DelayStr);
> +  }
> +}
> +
> +if (!ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoMap) {
> +  Status = ShellFindEnvVarInList(L"silentstart", ,
> , NULL);
> +  if (!EFI_ERROR (Status)) {
> +SilentStart = (BOOLEAN)ShellStrToUintn (NoMapStr);
> +  }
> +}
> +
>  //
>  // If shell support level is >= 1 create the mappings and paths
>  //
> @@ -492,7 +513,7 @@ UefiMain (
>  //
>  // Display the version
>  //
> -if (!ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoVersion) {
> +if (!ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoVersion &&
> !SilentStart) {
>  ShellPrintHiiEx (
>0,
>gST->ConOut->Mode->CursorRow, @@ -529,7 +550,7 @@ UefiMain (
>  //
>  // Display the mapping
>  //
> -if (PcdGet8(PcdShellSupportLevel) >= 2 &&
> !ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoMap) {
> +if (PcdGet8(PcdShellSupportLevel) >= 2 &&
> !ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoMap && !SilentStart) {
>Status = RunCommand(L"map");
>ASSERT_EFI_ERROR(Status);
>  }
> 
> Shell fails to load.
> Here is an excerpt from the debug log:
> 
> add-symbol-file
> /uefi/Build/StingrayPkg/DEBUG_GCC5/AARCH64/ShellPkg/Application/Shell/
> Shel
> l/DEBUG/Shell.dll 0x8848
> Loading driver at 0x0008847F000 EntryPoint=0x0008848 Shell.efi
> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 8D095118
> ProtectUefiImageCommon - 0x8D08ED

Re: [edk2] Documentation on "dh" shell command

[Udit Kumar]

Hi Jaben 

Dh says like 
14C: IPv4
14D: SimpleFileSystem DiskIO BlockIO DevicePath(..R,0x7D5FDC4F,0x2,0xA001))

But documentation is not saying what is column 1, 2 and so on 
What I am looking for description of output of dh command with various options 

Thanks
Udit 

> -Original Message-
> From: Carsey, Jaben [mailto:jaben.car...@intel.com]
> Sent: Wednesday, December 13, 2017 10:54 PM
> To: Udit Kumar <udit.ku...@nxp.com>; edk2-devel@lists.01.org
> Subject: RE: [edk2] Documentation on "dh" shell command
> 
> Udit,
> 
> There are some examples in the shell spec just before the table you found,
> but no exact output requirement for dh. What handle information are you
> looking for?  Maybe we can add that to the dynamic help for the command
> (the stuff users can see from "dh =?").
> 
> -Jaben
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Udit Kumar
> > Sent: Wednesday, December 13, 2017 4:48 AM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] Documentation on "dh" shell command
> > Importance: High
> >
> > Hi,
> > Could you help me, where I can get documentation on output of dh shell
> > command.
> > UEFI_Shell_Spec_2_2.pdf , table 18 is giving details of sfo option
> > only for each column.
> >
> > Thanks
> > Udit
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
> > ts.01.org%2Fmailman%2Flistinfo%2Fedk2-
> devel=02%7C01%7Cudit.kumar%
> >
> 40nxp.com%7C2626239c4c294e1f4bea08d5424e5da9%7C686ea1d3bc2b4c6fa
> 92cd99
> >
> c5c301635%7C0%7C0%7C636487826719107108=doxsRb2xej47877db0
> h0z4uam
> > 1mQh%2BKT2ryBpV4mJv4%3D=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Documentation on "dh" shell command

[Udit Kumar]

Hi, 
Could you help me, where I can get documentation on output of dh shell command.
UEFI_Shell_Spec_2_2.pdf , table 18 is giving details of sfo option only for 
each column.

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

Re: [edk2] [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support for Watchdog driver

[Udit Kumar]

> Because when the hardware watchdog times out, it triggers a hard system reset,
> without any software interaction.

Little more complexity around this piece of h/w
e.g once watchdog is started it cannot be stopped. 
Most caller seems to set timeout of 5 mins and later stopping watchdog. 
But actually watchdog is not stopped and OS needs to be loaded within this time 
or some
specific application needs to ping it.

Thx
Udit


> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Thursday, December 07, 2017 9:04 PM
> To: Gao, Liming <liming....@intel.com>
> Cc: Udit Kumar <udit.ku...@nxp.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Meenakshi Aggarwal
> <meenakshi.aggar...@nxp.com>; ard.biesheu...@linaro.org; edk2-
> de...@lists.01.org; Varun Sethi <v.se...@nxp.com>
> Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support
> for Watchdog driver
> 
> Liming,
> 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> mail-archive.com%2Fedk2-
> devel%40lists.01.org%2Fmsg32761.html=02%7C01%7Cudit.kumar%40nxp
> .com%7Cb5a84bfc5cdc435a605e08d53d87ff95%7C686ea1d3bc2b4c6fa92cd99c
> 5c301635%7C0%7C0%7C636482576674878205=w3k%2B7Aw6D78uaTty
> GOh%2F8JUSiHVIdpCPkBudMth6m%2Fw%3D=0
> Search for WdogRegisterHandler.
> 
> This topic is entirely unrelated to any _usage_ of watchdog timer protocol.
> 
> The topic is only whether it is reasonable to _implement_
> EFI_WATCHDOG_TIMER_ARCH_PROTOCOL for a hardware watchdog that
> *cannot* cause a callback to a handler function.
> Because when the hardware watchdog times out, it triggers a hard system reset,
> without any software interaction.
> 
> /
> Leif
> 
> On Thu, Dec 07, 2017 at 02:54:08PM +, Gao, Liming wrote:
> > Leif:
> >   I don't review the whole patch serial. Could you point your usage
> >   case on watch dog timer protocol?
> >
> > Thanks
> > Liming
> > > -Original Message-
> > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > > Sent: Thursday, December 7, 2017 7:04 PM
> > > To: Gao, Liming <liming@intel.com>
> > > Cc: Udit Kumar <udit.ku...@nxp.com>; Kinney, Michael D
> > > <michael.d.kin...@intel.com>; Meenakshi Aggarwal
> > > <meenakshi.aggar...@nxp.com>; ard.biesheu...@linaro.org;
> > > edk2-devel@lists.01.org; Varun Sethi <v.se...@nxp.com>
> > > Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP :
> > > Add support for Watchdog driver
> > >
> > > Hi Liming,
> > >
> > > On Thu, Dec 07, 2017 at 07:11:38AM +, Gao, Liming wrote:
> > > > Leif:
> > > >   I don't see the core driver uses
> > > >   WatchdogTimer->RegisterHandler(). When it returns unsupported, it
> > > >   means the additional handler can't be registered. DxeCore uses
> > > >   WatchdogTimer->SetTimerPeriod(). This service is implemented in
> > > >   your driver.
> > > >
> > > >   Watchdog protocol is defined in PI spec. Spec describes that this
> > > >   protocol provides the services required to implement the Boot
> > > >   Service SetWatchdogTimer(). It provides a service to set the
> > > >   amount of time to wait before firing the watchdog timer, and it
> > > >   also provides a service to register a handler that is invoked when
> > > >   the watchdog timer fires. This protocol can implement the watchdog
> > > >   timer by using the event and timer Boot Services, or it can make
> > > >   use of custom hardware. If no handler has been registered, or the
> > > >   registered handler returns, then the system will be reset by
> > > >   calling the Runtime Service ResetSystem(). So, this protocol is
> > > >   required.
> > >
> > > I am not disputing that the protocol is not required. I am
> > > suggesting that this hardware watchdog _cannot_ be used to register a
> handler.
> > >
> > > If this hardware watchdog does not get updated in time, that causes
> > > an immediate hardware reset of the processor.
> > >
> > > Because of this, I believe EFI_WATCHDOG_TIMER_ARCH_PROTOCOL is not
> > > the appropriate way to make use of it.
> > >
> > > Please let me know whether you agree.
> > >
> > > Regards,
> > >
> > > Leif
> > >
> > > > Thanks
> > > > Liming
> > > > >-Original Message-
> > > > >From: Leif Lindholm [mailto

Re: [edk2] [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support for Watchdog driver

[Udit Kumar]

Hi Liming, 

> DxeCore uses WatchdogTimer->SetTimerPeriod(). This service is implemented in
> your driver.

Callers of SetTimerPeriod are ignoring error reported. 
Is they assume this call will be perfect or they are ok in case some error on 
watchdog service. 

 
Regards
Udit 

> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Thursday, December 07, 2017 12:42 PM
> To: Leif Lindholm <leif.lindh...@linaro.org>; Udit Kumar
> <udit.ku...@nxp.com>
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Meenakshi Aggarwal
> <meenakshi.aggar...@nxp.com>; ard.biesheu...@linaro.org; edk2-
> de...@lists.01.org; Varun Sethi <v.se...@nxp.com>
> Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support
> for Watchdog driver
> 
> Leif:
>   I don't see the core driver uses WatchdogTimer->RegisterHandler(). When it
> returns unsupported, it means the additional handler can't be registered.
> DxeCore uses WatchdogTimer->SetTimerPeriod(). This service is implemented in
> your driver.
> 
>   Watchdog protocol is defined in PI spec. Spec describes that this protocol
> provides the services required to implement the Boot Service
> SetWatchdogTimer(). It provides a service to set the amount of time to wait
> before firing the watchdog timer, and it also provides a service to register a
> handler that is invoked when the watchdog timer fires. This protocol can
> implement the watchdog timer by using the event and timer Boot Services, or it
> can make use of custom hardware. If no handler has been registered, or the
> registered handler returns, then the system will be reset by calling the 
> Runtime
> Service ResetSystem(). So, this protocol is required.
> 
> Thanks
> Liming
> >-Original Message-
> >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> >Sent: Tuesday, December 05, 2017 7:06 PM
> >To: Udit Kumar <udit.ku...@nxp.com>
> >Cc: Gao, Liming <liming@intel.com>; Kinney, Michael D
> ><michael.d.kin...@intel.com>; Meenakshi Aggarwal
> ><meenakshi.aggar...@nxp.com>; ard.biesheu...@linaro.org; edk2-
> >de...@lists.01.org; Varun Sethi <v.se...@nxp.com>
> >Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> >support for Watchdog driver
> >
> >On Tue, Dec 05, 2017 at 05:07:00AM +, Udit Kumar wrote:
> >> >   I suggest return EFI_UNSUPPORTED for this case. The protocol
> >implementation
> >> > could return its status besides spec defined status.
> >>
> >> Thanks to help me , how core will treat this error 1/  Wdt not
> >> available 2/ ignoring this error 3/ core is not registering handler I
> >> guess 3 is valid,
> >
> >Looking at Core/Dxe/Misc/SetWatchdogTimer.c:
> >  //
> >  // Attempt to set the timeout
> >  //
> >  Status = gWatchdogTimer->SetTimerPeriod (gWatchdogTimer,
> >  MultU64x32 (Timeout, WATCHDOG_TIMER_CALIBRATE_PER_SECOND));
> >
> >  //
> >  // Check for errors
> >  //
> >  if (EFI_ERROR (Status)) {
> >return EFI_DEVICE_ERROR;
> >  }
> >
> >The SetWatchdogTimer() call would always return EFI_DEVICE_ERROR.
> >
> >> On side track, looks wdt is not used by core services then do we
> >> really need this as part of arch protocol ?
> >
> >Yes, that was ultimately what I was implying with my question regarding
> >whether this protocol is relevant for a watchdog that can only ever
> >reset the system on timeout.
> >
> >The protocol looks to me to be designed to use a dedicated generic
> >timer as backing for a software watchdog.
> >
> >Liming, Mike?
> >
> >If that is the case, then I agree this driver should probably not
> >implement this protocol, but rather set up a timer event (or a
> >dedicated timer) to stroke the watchdog.
> >
> >Regards,
> >
> >Leif
> >
> >> regards
> >> Udit
> >>
> >> > -Original Message-
> >> > From: Gao, Liming [mailto:liming@intel.com]
> >> > Sent: Monday, December 04, 2017 8:53 PM
> >> > To: Leif Lindholm <leif.lindh...@linaro.org>; Kinney, Michael D
> >> > <michael.d.kin...@intel.com>
> >> > Cc: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>;
> >> > ard.biesheu...@linaro.org; edk2-devel@lists.01.org; Udit Kumar
> >> > <udit.ku...@nxp.com>; Varun Sethi <v.se...@nxp.com>
> >> > Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP :
> >> > Add
> >support
> &

Re: [edk2] [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support for Watchdog driver

[Udit Kumar]

>   I suggest return EFI_UNSUPPORTED for this case. The protocol implementation
> could return its status besides spec defined status.

Thanks to help me , how core will treat this error  
1/  Wdt not available 
2/ ignoring this error 
3/ core is not registering handler  
I guess 3 is valid, 

On side track, looks wdt is not used by core services then do we really need 
this 
as part of arch protocol ?

regards
Udit 

> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Monday, December 04, 2017 8:53 PM
> To: Leif Lindholm <leif.lindh...@linaro.org>; Kinney, Michael D
> <michael.d.kin...@intel.com>
> Cc: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>;
> ard.biesheu...@linaro.org; edk2-devel@lists.01.org; Udit Kumar
> <udit.ku...@nxp.com>; Varun Sethi <v.se...@nxp.com>
> Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support
> for Watchdog driver
> 
> Leif:
>   I suggest return EFI_UNSUPPORTED for this case. The protocol implementation
> could return its status besides spec defined status.
> 
> Thanks
> Liming
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: Monday, December 4, 2017 10:36 PM
> > To: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming
> > <liming@intel.com>
> > Cc: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>;
> > ard.biesheu...@linaro.org; edk2-devel@lists.01.org;
> > udit.ku...@nxp.com; v.se...@nxp.com
> > Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> > support for Watchdog driver
> >
> > Mike, Liming, as MdePkg mainteiners - one question below:
> >
> > On Mon, Nov 27, 2017 at 04:21:50PM +0530, Meenakshi Aggarwal wrote:
> > > diff --git a/Platform/NXP/Drivers/WatchDog/WatchDog.c
> > > b/Platform/NXP/Drivers/WatchDog/WatchDog.c
> > > new file mode 100644
> > > index 000..a9c70ef
> > > --- /dev/null
> > > +++ b/Platform/NXP/Drivers/WatchDog/WatchDog.c
> > > @@ -0,0 +1,421 @@
> >
> > ...
> >
> > > +/**
> > > +  This function registers the handler NotifyFunction so it is
> > > +called every time
> > > +  the watchdog timer expires.  It also passes the amount of time
> > > +since the last
> > > +  handler call to the NotifyFunction.
> > > +  If NotifyFunction is not NULL and a handler is not already
> > > +registered,
> > > +  then the new handler is registered and EFI_SUCCESS is returned.
> > > +  If NotifyFunction is NULL, and a handler is already registered,
> > > +  then that handler is unregistered.
> > > +  If an attempt is made to register a handler when a handler is
> > > +already registered,
> > > +  then EFI_ALREADY_STARTED is returned.
> > > +  If an attempt is made to unregister a handler when a handler is
> > > +not registered,
> > > +  then EFI_INVALID_PARAMETER is returned.
> > > +
> > > +  @param  This The EFI_TIMER_ARCH_PROTOCOL instance.
> > > +  @param  NotifyFunction   The function to call when a timer interrupt 
> > > fires.
> This
> > > +   function executes at TPL_HIGH_LEVEL. The DXE 
> > > Core will
> > > +   register a handler for the timer interrupt, 
> > > so it can know
> > > +   how much time has passed. This information is 
> > > used to
> > > +   signal timer based events. NULL will 
> > > unregister the handler.
> > > +
> > > +  @retval EFI_SUCCESS   The watchdog timer handler was 
> > > registered.
> > > +  @retval EFI_ALREADY_STARTED   NotifyFunction is not NULL, and a
> handler is already
> > > +registered.
> > > +  @retval EFI_INVALID_PARAMETER NotifyFunction is NULL, and a handler
> was not
> > > +previously registered.
> > > +
> > > +**/
> > > +STATIC
> > > +EFI_STATUS
> > > +EFIAPI
> > > +WdogRegisterHandler (
> > > +  IN EFI_WATCHDOG_TIMER_ARCH_PROTOCOL   *This,
> > > +  IN EFI_WATCHDOG_TIMER_NOTIFY  NotifyFunction
> > > +  )
> > > +{
> > > +  // ERROR: This function is not supported.
> > > +  // The hardware watchdog will reset the board
> > > +  return EFI_INVALID_PARAMETER;
> >
> > Michael, Liming - what's your take on this?
> >
> > Is EFI_WATCHDOG_TIMER_ARCH_PROTOCOL suitable for use with a pure-hw
> > watchdog such as this?
> >
> > If so, what would be a suitable return code here?
> > EFI_INVALID_PARAMETER does not look ideal.
> >
> > /
> > 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

[Udit Kumar]

>
> > > > 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 <meenakshi.aggar...@nxp.com>; Gao, Liming
> > > > > <liming@intel.com>
> > > > > Cc: Kinney, Michael D <michael.d.kin...@intel.com>;
> > > > > edk2-devel@lists.01.org; Ard Biesheuvel
> > > > > <ard.biesheu...@linaro.org>
> > > > > 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 always know which endianness we are
> > > > > building for.
> > > > > What we need is a byteswapping flavour of IoLib.
> > > > >
> > > > > So Liming, what if we do something like adding a
> > > > > MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSwa
> > > > > p.inf
> > > > > ---
> > > > > [Defines]
> > > > >   INF_VERSION= 0x0001001A
> > > > >   BASE_NAME  =
> > > > > BaseIoLibIntrinsicSwap
> > > > >   MODULE_UNI_FILE=
> > > > > BaseIoLibIntrinsic.uni
> > > > >   FILE_GUID  = d4a60d44-3688-4a50-
> > > > > b2d0-5c6fc2422523
> > > > >   MODULE_TYPE= BASE
> > > > >   VERSION_STRING = 1.0
> > > > >   LIBRARY_CLASS  = IoLib
> > > > >
> > > > >
> > > > > #
> > > > > #  VALID_ARCHITECTURES   = IA32 X64 EBC IPF ARM
> > > > > AARCH64
> > > > > #
> > > > >
> > > > > [Sources]
> > > > >   BaseIoLibIntrinsicInternal.h
> > > > >   IoHighLevel.c
> > > > >   IoLib.c
> > > > >   IoLibEbc.c # Asserts on all i/o port accesses
> > > > >   IoLibMmioBuffer.c
> > > > >
> > > > > [Packages]
> > > > >   MdePkg/MdePkg.dec
> > > > >
> > > > > [LibraryClasses]
> > > > >   DebugLib
> > > > >   BaseLib
> > > > >
> > > > > [BuildOptions]
> > > > >   GCC:*_*_*_CC_FLAGS  = -DSWAP_BYTES
> > > > > ---
> > > > >
> > > > > And then add
> > > > >
> > > > > #ifdef SWAP_BYTES
> > > > >   return SwapBytesXX (Value);
> > > > > #else
> > > > >   return Value;
> > 

Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux

[Udit Kumar]

Hi Ard, 
Sorry for coming back late on this 
Are you ok to apply this patch in edk2

Thx
Udit

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Sakar
> Arora
> Sent: Wednesday, September 20, 2017 1:50 PM
> To: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Cc: edk2-devel@lists.01.org; leif.lindh...@linaro.org
> Subject: Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> 
> Thanks for the information. Seems my understanding was not correct in this
> context. I have no other doubts on this change.
> 
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, September 20, 2017 12:02 PM
> To: Sakar Arora <sakar.ar...@arm.com>
> Cc: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>; edk2-
> de...@lists.01.org; leif.lindh...@linaro.org
> Subject: Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> 
> On 19 September 2017 at 22:32, Sakar Arora <sakar.ar...@arm.com> wrote:
> > The DXE core dispatcher relies on the available memory to allocate space for
> loading the rest of the modules from the UEFI image. If we declare the UEFI
> image memory space (from which DXE dispatcher reads the efi modules) open to
> allocation, it might lead to data corruption, depending on the location of 
> UEFI
> image and cumulative size of uncompressed EFI modules.
> >
> > Also, since UEFI allows unloading and loading of drivers at runtime, IMO, 
> > there
> is a need to preserve the UEFI image even after all the modules have been
> decompressed and loaded in the boot sequence.
> >
> 
> None of this is relevant. The uncompressed firmware volume containing DXE
> core and everything else is preserved as before. The only thing that gets
> discarded is the outer FV, which only contains the PrePi SEC module, and the
> compressed FV, neither of which is ever touched again after DXE core has
> started executing. So we should not register the FV in the first place, and 
> not
> reserve the memory so we don't lose it.
> 
> If you still think this may break anything, could you please elaborate?
> 
> 
> 
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Tuesday, September 19, 2017 6:18 PM
> > To: Sakar Arora <sakar.ar...@arm.com>
> > Cc: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>;
> > edk2-devel@lists.01.org; leif.lindh...@linaro.org
> > Subject: Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> >
> > On 19 September 2017 at 01:07, Sakar Arora <sakar.ar...@arm.com> wrote:
> >> This change will create the possibility for memory space holding the UEFI
> image to be over-written by the DXE core code, since this space will then be
> available for allocation.
> >
> > Yes. But why does this matter after the entire payload has been decompressed
> into memory already?
> >
> >
> >> Any such change, if required, should be done just before booting the OS.
> >>
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >> Of Meenakshi Aggarwal
> >> Sent: Tuesday, September 19, 2017 6:02 PM
> >> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org;
> >> ard.biesheu...@linaro.org
> >> Subject: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> >>
> >> While creating Hob list, ArmPlatformPkg is hiding UEFI memory.
> >> whereas this memory can be used by OS.
> >>
> >> This patch, allows OS to use UEFI code area.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Udit Kumar <udit.ku...@nxp.com>
> >> Signed-off-by: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>
> >> ---
> >>  ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c | 69
> >> -
> >>  1 file changed, 69 deletions(-)
> >>
> >> diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> >> b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> >> index 2feb11f..d03214b 100644
> >> --- a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> >> +++ b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> >> @@ -70,11 +70,7 @@ MemoryPeim (
> >>  {
> >>ARM_MEMORY_REGION_DESCRIPTOR *MemoryTable;
> >>EFI_RESOURCE_ATTRIBUTE_TYPE  ResourceAttributes;
> >> -  UINT64   ResourceLength;
> >>EFI_PEI_HOB_POINTERS NextHob;
> >> -  EFI_PHYSICAL_ADDRESS FdTop;
> >> -  EF

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

[Udit Kumar]

> >> Hmnnn it sounds like jedec,spi-nor meets this test.
> >>
> >> There is only one property in the DT bindings that describes the
> >> device itself (fast read support) rather than its "bus address" (chip
> >> select, frequency). Further, that single property is obsolete, at
> >> least for Linux; the kernel driver now contains a quirks tables to
> >> look up by device ID whether fast read is supported and will use that
> >> on non-DT systems (and also to censor broken DT systems ;-) ).
> >
> > You mean, this more on bus frame work, how to probe slave.
> > Example rtc-ds3232.c , when is spi mode just need name but for i2c
> > mode it needs of_match_table
> I mean nothing more or less than that PRP0001 + compatible:jedec,spi-nor is
> tolerable within the ACPI tables (rather than allocating a HID) because it 
> has no
> properties[1] beyond the bus configuration that ACPI can already describe

Thanks.  So tables are tolerable with PRP0001 + compatible
 
> I'm afraid I don't understand how rtc-ds3232.c fits into this topic; there 
> are no

Not directly , but just to mention that this is more on bus frame work (or say
controller driver) how they are probing their slaves. 

> documented device tree bindings for the SPI variant of this part and, in any 
> case,
> an RTC should use the ACPI interfaces
> (rtc-cmos.c) so the choice HID is a moot point; it should not be in the ACPI 
> tables
> at all.

Sure, RTC will not be exposed by acpi tables. 

> 
> Daniel.
> 
> 
> [1] Assuming one accepts the argument that the m25p,fast-read property
>  can be ignored.
>  ignored.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 1/9] Platform/NXP: Add support for Big Endian Mmio APIs

[Udit Kumar]

Hi Leif, 

> Hmm, was there a cover letter for this v2? I can only find the one from v1 in 
> my
> inbox? Usually it is helpful to keep the cover letter and add comments on what
> has changed since the previous revision.
> 
> Also, can you generate the patches with
> --subject-prefix="PATCH edk2-platforms"
> to ensure a predictable email header for edk2-platforms patches?
> 
> Now, for this actual patch...
> This looks like a useful thing. It also looks like a very generic thing. I 
> would think
> it could live in edk2/MdePkg, but perhaps we can simply migrate it there if we
> see additional users outside of the NXM platforms.

This is our preferred way, if this can be pushed to edk2/MdePkg but 
in another discussion , Liming suggested to keep as local lib.

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

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

[Udit Kumar]

Hi Andrew 
 
> Udit,
> 
> I think it is more like you only need ACPI if you don't have a driver.

Ok, then ACPI or say firmware needs to export AML methods, which are known to 
OS.

> If it is standard bus with standard drivers the OS code can do power 
> management
> without any help from ACPI. 

In some cases there could be some config registers in IP, which could 
leads to power down mode, then probably power management could be done
without ACPI. 
If we have clock and regulators doing power management,  then ACPI is needed.
No ? 

> In general ACPI exists to abstract chipsets that don't
> have OS drivers, or mother board layout of power plains, GPIOs, etc.

I can think of for power management, without specific driver if such
Power saving is limited to internal SOC.

For example, say temperature of mother board is read using 
some sensor connected with SOC over i2c line. And in SOC
i2c interface is behind some controller.
How do you see to read temperature without having a OS drivers.
For power management based on  temperature, we may not need a
driver.


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

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

[Udit Kumar]

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

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


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

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

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

[Udit Kumar]

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

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

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

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

[Udit Kumar]

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

Regards
Udit

From: af...@apple.com [mailto:af...@apple.com]
Sent: Wednesday, November 22, 2017 11:05 PM
To: Udit Kumar <udit.ku...@nxp.com>
Cc: Daniel Thompson <daniel.thomp...@linaro.org>; Ard Biesheuvel 
<ard.biesheu...@linaro.org>; edk2-devel@lists.01.org; Leif Lindholm 
<leif.lindh...@linaro.org>
Subject: Re: [edk2] [RFC] ACPI table HID/CID allocation

FYI now that the UEFI Forum owns the ACPI Spec here is the location to register 
a new PNP ID or ACPI ID: 
https://stash.sd.apple.com/projects/COREOSMACFW/repos/macefifirmware/pull-requests/630/overview<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstash.sd.apple.com%2Fprojects%2FCOREOSMACFW%2Frepos%2Fmacefifirmware%2Fpull-requests%2F630%2Foverview=02%7C01%7Cudit.kumar%40nxp.com%7C1a3ff6112c264748866708d531cf4d9b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636469688791080091=Cgf%2B0oIi8sbAFYi%2FUghFBBWJzkfUhNPEvRDiLRyvd%2FQ%3D=0>.
 Anyone can make a request.

PNP ID Registry: 
http://www.uefi.org/pnp_id_list<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uefi.org%2Fpnp_id_list=02%7C01%7Cudit.kumar%40nxp.com%7C1a3ff6112c264748866708d531cf4d9b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636469688791080091=CFZj6YvToS%2FseGn38djKKARF8JpoMUvkwChZf3JHwzo%3D=0>
ACPI ID Registry: 
http://www.uefi.org/acpi_id_list<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uefi.org%2Facpi_id_list=02%7C01%7Cudit.kumar%40nxp.com%7C1a3ff6112c264748866708d531cf4d9b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636469688791080091=DWgfdanDSssKaYcJ0UJ4djgy6l4lxdv%2BfdHCrif9JHA%3D=0>

Thanks,

Andrew Fish

On Nov 22, 2017, at 5:39 AM, Udit Kumar 
<udit.ku...@nxp.com<mailto:udit.ku...@nxp.com>> wrote:

Hi Daniel



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

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

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


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

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



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

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

Thanks
Udit



Daniel.




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


Regards
Udit


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

On 21 November 2017 at 13:24, Udit Kumar 
<udit.ku...@nxp.com<mailto:udit.ku...@nxp.com>> wrote:

Thanks Ard,

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

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


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

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

Sure,


For sure, AML methods (as needed _

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

[Udit Kumar]

Hi Daniel 


> > For external devices (for which HID is not available), you suggest to
> > go with PRP0001 + compatible or that device driver needs add ACPI HID
> support.
> 
> I don't think internal or external to the SoC would be any kind of deciding 
> factor
> in how to best to bind, simply because I don't understand why there is no HID
> available.

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

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

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

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

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

Thanks
Udit 

> 
> Daniel.
> 
> 
> >
> > As you pointed out, are external devices to SOC such exception to use
> > PRP0001 + compatible be it i2c slave or SPI slave ?
> >
> >
> > Regards
> > Udit
> >
> >> -Original Message-----
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: Tuesday, November 21, 2017 7:34 PM
> >> To: Udit Kumar <udit.ku...@nxp.com>
> >> Cc: Leif Lindholm <leif.lindh...@linaro.org>;
> >> edk2-devel@lists.01.org; Varun Sethi <v.se...@nxp.com>; Daniel
> >> Thompson <daniel.thomp...@linaro.org>; Graeme Gregory
> >> <graeme.greg...@linaro.org>
> >> Subject: Re: [RFC] ACPI table HID/CID allocation
> >>
> >> On 21 November 2017 at 13:24, Udit Kumar <udit.ku...@nxp.com> wrote:
> >>> Thanks Ard,
> >>>
> >>> My intend of this email to know, what is right way to define HID and
> >>> CID in ACPI firmware i.e
> >>>
> >>> Device(XYZ) {
> >>>  Name(_HID, "NXP0001")
> >>>  Name(_CID, "PRP0001")
> >>>Device(Slave1) {
> >>>  Name(_CID, "PRP0001")
> >>>   }
> >>> }
> >>> is ok or
> >>>
> >>>
> >>> Device(XYZ) {
> >>>  Name(_HID, "NXP0001")
> >>>  Name(_CID, " NXP0001")
> >>>Device(Slave1) {
> >>>  Name(_CID, " NXP0002")
> >>>   }
> >>> }
> >>> Seems good
> >>>
> >>
> >> I don't think it makes a lot of sense to use the same value for _HID
> >> and _CID, so you can just drop the latter.
> >
> > Sure,
> >
> >>> For sure, AML methods (as needed _ON/OFF/RST/STA etc) /_DSD will to
> >>> be
> >> coded in table using either of.
> >>>
> >>> Please see more in line
> >>>
> >>> Regards
> >>> Udit
> >>>
> >>>> -Original Message-
> >>>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >>>> Sent: Tuesday, November 21, 2017 5:59 PM
> >>>> To: Udit Kumar <udit.ku...@nxp.com>
> >>>> Cc: Leif Lindholm <leif.lindh...@linaro.org>;
> >>>> edk2-devel@lists.01.org; Varun Sethi <v.se...@nxp.com>; Daniel
> >>>> Thompson <daniel.thomp...@linaro.org>; Graeme Gregory
> >>>> <graeme.greg...@linaro.org>
> >>>> Subject: Re: [RFC] ACPI table HID/CID allocation
> >>>>
> >>>> On 21 November 2017 at 11:32, Udit Kumar <udit.ku...@nxp.com>
> wrote:
> >>>>>
> >>>>>> On 21 November 2017 at 09:59, Udit Kumar <udit.ku...@nxp.com>
> >> wrote:
> >>>>>>> Thanks Ard.
> >>>>>>> Below table was for example. I am not converting whole DT to
> >>>>>>> ACPI tables :) My idea is to reduce Linux patches for probing as
> possible.
> >>>>>>> Also keeping firmware and OS separately then Let firmware e

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

[Udit Kumar]

Thanks Ard, 
For internal SOC devices, this is perfectly ok to drop PRP0001 from CID. 

> This could be a valid reason to use PRP0001 + compatible, for things like I2C
> slaves that are external to the SoC

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

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


Regards
Udit

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, November 21, 2017 7:34 PM
> To: Udit Kumar <udit.ku...@nxp.com>
> Cc: Leif Lindholm <leif.lindh...@linaro.org>; edk2-devel@lists.01.org; Varun
> Sethi <v.se...@nxp.com>; Daniel Thompson <daniel.thomp...@linaro.org>;
> Graeme Gregory <graeme.greg...@linaro.org>
> Subject: Re: [RFC] ACPI table HID/CID allocation
> 
> On 21 November 2017 at 13:24, Udit Kumar <udit.ku...@nxp.com> wrote:
> > Thanks Ard,
> >
> > My intend of this email to know, what is right way to define HID and
> > CID in ACPI firmware i.e
> >
> > Device(XYZ) {
> > Name(_HID, "NXP0001")
> > Name(_CID, "PRP0001")
> >   Device(Slave1) {
> > Name(_CID, "PRP0001")
> >  }
> > }
> > is ok or
> >
> >
> > Device(XYZ) {
> > Name(_HID, "NXP0001")
> > Name(_CID, " NXP0001")
> >   Device(Slave1) {
> > Name(_CID, " NXP0002")
> >  }
> > }
> > Seems good
> >
> 
> I don't think it makes a lot of sense to use the same value for _HID and 
> _CID, so
> you can just drop the latter.

Sure, 
 
> > For sure, AML methods (as needed _ON/OFF/RST/STA etc) /_DSD will to be
> coded in table using either of.
> >
> > Please see more in line
> >
> > Regards
> > Udit
> >
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: Tuesday, November 21, 2017 5:59 PM
> >> To: Udit Kumar <udit.ku...@nxp.com>
> >> Cc: Leif Lindholm <leif.lindh...@linaro.org>;
> >> edk2-devel@lists.01.org; Varun Sethi <v.se...@nxp.com>; Daniel
> >> Thompson <daniel.thomp...@linaro.org>; Graeme Gregory
> >> <graeme.greg...@linaro.org>
> >> Subject: Re: [RFC] ACPI table HID/CID allocation
> >>
> >> On 21 November 2017 at 11:32, Udit Kumar <udit.ku...@nxp.com> wrote:
> >> >
> >> >> On 21 November 2017 at 09:59, Udit Kumar <udit.ku...@nxp.com>
> wrote:
> >> >> > Thanks Ard.
> >> >> > Below table was for example. I am not converting whole DT to
> >> >> > ACPI tables :) My idea is to reduce Linux patches for probing as 
> >> >> > possible.
> >> >> > Also keeping firmware and OS separately then Let firmware expose
> >> >> > both way (HID and PRP1) and Linux to decide binding
> >> >>
> >> >> No.
> >> >>
> >> >> You are still assuming ACPI and DT device drivers bind at the same
> >> >> level, and they don't.
> >> >
> >> > No, my above comments was just limited to binding.
> >>
> >> Yes, but if you leave it to the OS to decide which binding it uses,
> >> you will have to support all of them into eternity. And the more
> >> detailed binding you need to support may limit you in the available
> >> choices when it comes to making hardware changes, something ACPI allows
> you to do.
> >
> > Thanks,
> > Is this ok to say , we can provide max same properties in driver as of
> > DT (with _DSD) , But prefer to use AML methods.
> > With note, clocking regulators are out of scope here.
> >
> 
> Yes. _DSD may be used to describe device specific data that goes beyond what
> ACPI can express natively. Using _DSD to describe clocks and regulators is an
> absolute no-go. Putting things like "status" or "dma-coherent" in _DSD
> properties is absolutely unacceptable as well.
> But even things like initialization data that the driver programs into the 
> device a
> single time really do not belong in _DSD. Instead, it should be the firmware 
> that
> initializes the device, and presents it to the OS in its initialized state.
>

Agreed, I never meant something to add in DSD which

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

[Udit Kumar]

Thanks Ard, 

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

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


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

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

Please see more in line 

Regards
Udit

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, November 21, 2017 5:59 PM
> To: Udit Kumar <udit.ku...@nxp.com>
> Cc: Leif Lindholm <leif.lindh...@linaro.org>; edk2-devel@lists.01.org; Varun
> Sethi <v.se...@nxp.com>; Daniel Thompson <daniel.thomp...@linaro.org>;
> Graeme Gregory <graeme.greg...@linaro.org>
> Subject: Re: [RFC] ACPI table HID/CID allocation
> 
> On 21 November 2017 at 11:32, Udit Kumar <udit.ku...@nxp.com> wrote:
> >
> >> On 21 November 2017 at 09:59, Udit Kumar <udit.ku...@nxp.com> wrote:
> >> > Thanks Ard.
> >> > Below table was for example. I am not converting whole DT to ACPI
> >> > tables :) My idea is to reduce Linux patches for probing as possible.
> >> > Also keeping firmware and OS separately then Let firmware expose
> >> > both way (HID and PRP1) and Linux to decide binding
> >>
> >> No.
> >>
> >> You are still assuming ACPI and DT device drivers bind at the same
> >> level, and they don't.
> >
> > No, my above comments was just limited to binding.
> 
> Yes, but if you leave it to the OS to decide which binding it uses, you will 
> have to
> support all of them into eternity. And the more detailed binding you need to
> support may limit you in the available choices when it comes to making
> hardware changes, something ACPI allows you to do.

Thanks,  
Is this ok to say , we can provide max same properties in driver as of DT
(with _DSD) , But prefer to use AML methods.
With note, clocking regulators are out of scope here. 

 
> > Right, here device driver should know that device is present in
> > system, I see probe function (device-driver binding) is way to know this.
> > Then driver can execute AML methods exposed by firmware.
> >
> 
> Yes, declaring the presence of the device is the main purpose of describing it
> both in ACPI and in DT.
> 
> >> An ACPI device has AML methods to manage power state and perform
> >> other device related low-level tasks. The device driver has no
> >> knowledge of the hardware beyond what it needs to invoke those abstract
> methods.
> >
> > You meant, If we need to update driver for AML methods then why not to
> update binding as well . ?
> >
> 
> No. What I am saying is that you should not expose two different bindings, and
> let the OS choose.

Ok, got it , then PRP1 stuff should be used only at urgent or say 
no other choice left , Right ? 
 
> > On side track,
> >  With limited search,  I got many each driver is having (acpi_id and
> > of_id), looks, acpi support is added on the top of DT flavored drivers.
> > and therefore acpi tables are following the same.
> > Sorry to say, reference I am looking at (edk2-platform) JunoPkg and
> > VExpressPkg, Has following devices has description similar to Device tree
> > Device (NET0) {
> > Device (SREG) {
> > Device (VIRT) {
> 
> These were taken from the ACPI tables for an emulator
> 
> >Device(KMI0) {
> 
> I have no clue what kind of device this is
> 
> >Device(ETH0) {
> 
> This one uses _DSD as intended, to set device properties in a DT compatible
> fashion, but note that this does *not* include the 'compatible' property, nor
> anything else that ACPI defines itself (status, dma-coherent, etc)

Let me put in simple way,
A simple driver can survive only with _DSD in acpi world. (clocking/regulators 
are used
as said in UEFI/ACPI)

Copying below from Juno, 
Are below kind of tables are acceptable ? 

Device(ETH0) {
  Name(_HID, "ARMH9118")
  Name(_UID, Zero)
  Name(_CRS, ResourceTemplate() {
  Memory32Fixed(ReadWrite, 0x1800, 0x1000)
  Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive) { 192 }
  })
  Name(_DSD, Package() {
   ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),

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

[Udit Kumar]

 
> On 21 November 2017 at 09:59, Udit Kumar <udit.ku...@nxp.com> wrote:
> > Thanks Ard.
> > Below table was for example. I am not converting whole DT to ACPI
> > tables :) My idea is to reduce Linux patches for probing as possible.
> > Also keeping firmware and OS separately then Let firmware expose both
> > way (HID and PRP1) and Linux to decide binding
> 
> No.
> 
> You are still assuming ACPI and DT device drivers bind at the same level, and
> they don't.

No, my above comments was just limited to binding. 
Right, here device driver should know that device is present in system, 
I see probe function (device-driver binding) is way to know this. 
Then driver can execute AML methods exposed by firmware.
 
> An ACPI device has AML methods to manage power state and perform other
> device related low-level tasks. The device driver has no knowledge of the
> hardware beyond what it needs to invoke those abstract methods.

You meant, If we need to update driver for AML methods then why not to update 
binding as well . ?

On side track, 
 With limited search,  I got many each driver is having (acpi_id and of_id), 
looks, acpi support is added on the top of DT flavored drivers.
and therefore acpi tables are following the same.
Sorry to say, reference I am looking at (edk2-platform) JunoPkg and 
VExpressPkg, 
Has following devices has description similar to Device tree 
Device (NET0) {
Device (SREG) {
Device (VIRT) {
   Device(KMI0) {
   Device(ETH0) {
Where no AML method is exposed. Then I expect OS driver to manage this device.
While grepping over few other edk2-platforms.  Looks some of methods 
are abstracted, not whole device. 


> A DT device describes everything in detail, and requires clock and regulator
> drivers and other bits and pieces that are tightly coupled to details of the
> hardware.
> 
> So now, you have the worst of both worlds:
> 
> - you need to implement all of this in firmware so ACPI can support it,
> - you have to expose the internals to the OS so DT can support it.

Yes, for time being or may be longer, DT support needs to be there 
along with ACPI introduction.

Are you suggesting here to abstract whole device details from 
OS and expose AML methods to be used by device driver. 
And maintain two drivers instead of fitting DT style driver into ACPI world ?
 
> The result is that you lose *all* of the benefits of ACPI, because the power 
> of
> the abstraction is that you can modify the low-level implementation on the
> firmware side without the need for modifying the OS. *That* is the value
> proposition of ACPI, the ability to run last year's OS on this year's 
> hardware.


> Implementing ACPI in the way you propose is absolutely pointless, sorry to be
> harsh about it.
> 
> --
> Ard.
> 
> 
> > Please see inline as well
> >
> > Regards
> > Udit
> >
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: Tuesday, November 21, 2017 3:08 PM
> >> To: Udit Kumar <udit.ku...@nxp.com>
> >> Cc: Leif Lindholm <leif.lindh...@linaro.org>; edk2-devel@lists.01.org; 
> >> Varun
> >> Sethi <v.se...@nxp.com>; Daniel Thompson <daniel.thomp...@linaro.org>;
> >> Graeme Gregory <graeme.greg...@linaro.org>
> >> Subject: Re: [RFC] ACPI table HID/CID allocation
> >>
> >> On 21 November 2017 at 09:19, Udit Kumar <udit.ku...@nxp.com> wrote:
> >> > Hi,
> >> >
> >> > I am enabling ACPI on NXP platform , In order to do minimal changes in
> >> > Linux driver for device-driver binding.
> >> >
> >> > I want to use PRP0001 device as CID and HID as actual (NXP allocated 
> >> > HID).
> >> >
> >> > So that Linux can bind with PRP0001 and  compatible field, where as
> >> > other OS (Window etc) can rely on HID.
> >> >
> >> > Below is sample, ACPI table for SPI controller and its slave device.
> >> >
> >> >
> >> >
> >> > Hope this approach is ok ?
> >> >
> >>
> >> No, it is not.
> >>
> >> Architecting an ACPI platform is not a matter of taking a device tree and
> >> converting each node into an ACPI device.
> >
> > No , no, Here I am not converting everything from DT to ACPI
> >
> >> Linux/DT makes no assumptions about the presence of firmware. This means
> >> most device drivers have to manage clocks, regulators etc because they will
> not
> >> be in a known state. Also, the OS can own all devices in the system.
> >
> > Thanks to Linux documentation , I noted th

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

[Udit Kumar]

Thanks Ard. 
Below table was for example. I am not converting whole DT to ACPI tables :) 
My idea is to reduce Linux patches for probing as possible.  
Also keeping firmware and OS separately then 
Let firmware expose both way (HID and PRP1) and Linux to decide binding 
Please see inline as well 

Regards
Udit

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, November 21, 2017 3:08 PM
> To: Udit Kumar <udit.ku...@nxp.com>
> Cc: Leif Lindholm <leif.lindh...@linaro.org>; edk2-devel@lists.01.org; Varun
> Sethi <v.se...@nxp.com>; Daniel Thompson <daniel.thomp...@linaro.org>;
> Graeme Gregory <graeme.greg...@linaro.org>
> Subject: Re: [RFC] ACPI table HID/CID allocation
> 
> On 21 November 2017 at 09:19, Udit Kumar <udit.ku...@nxp.com> wrote:
> > Hi,
> >
> > I am enabling ACPI on NXP platform , In order to do minimal changes in
> > Linux driver for device-driver binding.
> >
> > I want to use PRP0001 device as CID and HID as actual (NXP allocated HID).
> >
> > So that Linux can bind with PRP0001 and  compatible field, where as
> > other OS (Window etc) can rely on HID.
> >
> > Below is sample, ACPI table for SPI controller and its slave device.
> >
> >
> >
> > Hope this approach is ok ?
> >
> 
> No, it is not.
> 
> Architecting an ACPI platform is not a matter of taking a device tree and
> converting each node into an ACPI device.

No , no, Here I am not converting everything from DT to ACPI
 
> Linux/DT makes no assumptions about the presence of firmware. This means
> most device drivers have to manage clocks, regulators etc because they will 
> not
> be in a known state. Also, the OS can own all devices in the system.

Thanks to Linux documentation , I noted this, During hand off ACPI
firmware needs to ensure proper clocking. 
 
> Linux/ACPI relies on the firmware to set up clocks and regulators, and uses
> abstract firmware methods to manage power states etc. Also, due to the
> dependency on UEFI, things like the RTC and NOR flash are not exposed to the
> OS via device nodes, but via UEFI runtime services.

Agreed, RTC and NOR (containing firmware)  should not exposed to Linux or OS. 
 
> In a nutshell, the difference between ACPI and DT is that the handoff point
> between the OS and the firmware is at a different abstraction level.
> 
> So no, it is not ok to use PRP0001 + compatible for everything. It may be
> acceptable in some exceptional cases, but you will have to explain why.
> Everything else should use proper ACPI bindings.

HID is not going away , I am keeping with PRP0001 + compatible
and let linux driver to decide what to use. 

If PRP0001 + compatible is restricted or meant for limited use
then I can assign HID for NXP devices or say driver managed by NXP.
For other vendors, will this be accepted to have HID something like NXP00xx  ??
 
> --
> Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Udit Kumar]

Hi,

I am enabling ACPI on NXP platform , In order to do minimal changes in Linux 
driver for device-driver binding.

I want to use PRP0001 device as CID and HID as actual (NXP allocated HID).

So that Linux can bind with PRP0001 and  compatible field, where as other OS 
(Window etc) can rely on HID.

Below is sample, ACPI table for SPI controller and its slave device.



Hope this approach is ok ?



Thanks

Udit





Scope(_SB)

{

Device(SPI0) {

Name(_HID, "NXP0001")

Name(_CID, "PRP0001")

Name(_CRS, ResourceTemplate() {

}) // end of _CRS for i2c0 device

Name (_DSD, Package () {

ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),

Package () {

Package() {"compatible", " fsl,ls2085a-dspi"},

}

}) // end of DSD SPI device

Device (EEP0) {

Name(_HID, " NXP0002")  //HID can be discussed with 
flash vendor

Name(_CID, "PRP0001") // m25p80 flash

Name(_CRS, ResourceTemplate()

{

   SPISerialBus()

}) // ResourceTemplate()

Name (_DSD, Package () {

ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),

Package () {

Package() {"compatible", "st,m25p80"},

}

} // End of e2prom device

} // end of SPI device

}



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

[edk2] Why we need CapsuleLib even platform does not support this feature

[Udit Kumar]

Hi, 
I recently noticed in my build as well, we need to include CapsuleLib even 
platform does not support Capsule update feature. 
Thanks to help me, why this dependency is added in edk2. 

Regards
Udit

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
> Biesheuvel
> Sent: Tuesday, November 14, 2017 4:48 PM
> To: Kalyan Nagabhirava 
> Cc: edk2-devel@lists.01.org; Leif Lindholm ; Mark
> Gregotski 
> Subject: Re: [edk2] [PATCH edk2-platforms]: resolving Hikey platform build 
> error
> 
> On 14 November 2017 at 11:16, Kalyan Nagabhirava
>  wrote:
> >
> > "Instance of library class [CapsuleLib] is not found" build error is
> > coming for Hikey platform, to resolve this issueadded CapsuleLib to
> > "LibraryClasses.common" section
> >
> > diff --git a/Platform/Hisilicon/HiKey/HiKey.dsc
> > b/Platform/Hisilicon/HiKey/HiKey.dsc
> > index 968e8ac..2e3b1c8 100644
> > --- a/Platform/Hisilicon/HiKey/HiKey.dsc
> > +++ b/Platform/Hisilicon/HiKey/HiKey.dsc
> > @@ -61,6 +61,7 @@
> >
> > SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchroni
> > SynchronizationLib|zationLib.inf
> >
> >FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
> > +
> > + CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.
> > + inf
> >
> >
> UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootM
> an
> > UefiBootManagerLib|agerLib.inf
> >
> >
> PlatformBootManagerLib|ArmPkg/Library/PlatformBootManagerLib/PlatformB
> > PlatformBootManagerLib|ootManagerLib.inf
> >BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
> >
> >
> 
> Thanks Kalyan
> 
> Could you resend it as a proper patch, please? I.e., with the appropriate
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> 
> and Signed-off-by line,
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01
> .org%2Fmailman%2Flistinfo%2Fedk2-
> devel=02%7C01%7Cudit.kumar%40nxp.com%7Cc1807332add6499fcd730
> 8d52b516fad%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6364625
> 51151191358=joABHCm%2F3Iu0jfplBE3Ora9ffp3IfuNuu2GfOgOTsV8%3D
> =0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Tftp assert fix for openfile failure case

[Udit Kumar]

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Wednesday, November 08, 2017 8:52 PM
> To: Udit Kumar <udit.ku...@nxp.com>
> Cc: Vabhav Sharma <vabhav.sha...@nxp.com>; edk2-devel@lists.01.org;
> ruiyu...@intel.com; jaben.car...@intel.com; ard.biesheu...@linaro.org;
> siyuan...@intel.com; ting...@intel.com
> Subject: Re: [PATCH] Tftp assert fix for openfile failure case
> 
> On Wed, Nov 08, 2017 at 05:15:49AM +, Udit Kumar wrote:
> > > > diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > > b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > > index fbde3bf..6425fc5 100755
> > > > --- a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > > +++ b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > > @@ -509,6 +509,7 @@ ShellCommandRunTftp (
> > > >);
> > > >goto NextHandle;
> > >
> > > Wow, a goto in a foor loop in a 320-line function.
> > > What could possibly go wrong?
> >
> > Instead of being on some volume, if you are on Shell.
> > Then file open will fail.
> 
> Sure. The above was a snarky comment on the state of the existing code.
> 
> > > >  }
> > > > +DataSize = FileSize;
> > > >
> > > >  Status = DownloadFile (Mtftp4, RemoteFilePath,
> > > > AsciiRemoteFilePath,
> > > FileSize, BlockSize, );
> > > >  if (EFI_ERROR (Status)) {
> > > > @@ -539,7 +540,6 @@ ShellCommandRunTftp (
> > > >goto NextHandle;
> > > >  }
> > > >
> > > > -DataSize = FileSize;
> > > >  Status = ShellWriteFile (FileHandle, , Data);
> > > >  if (!EFI_ERROR (Status)) {
> > > >ShellStatus = SHELL_SUCCESS;
> > > > --
> > > > 1.9.1
> > >
> > > So, a wider question:
> > > This shell command was introduced in the heyday of "let's
> > > reimplement U-Boot in the EDK2 tree". Mainly, from my impression, it
> > > seems to be used in order that people don't need to learn how boot
> > > managers and device paths work.
> >
> > When you say about complete boot, then this may not be useful.
> >
> > > Am I being too harsh?
> > > Are there practical uses for this?
> >
> > For doing some sort of unit testing of given interface. I found this
> > useful. During development, this is useful to transfer generic file to
> > development board.
> 
> OK, I can see how it could be useful.
> My opposition is based on three things:
> 1) people _are_ trying to use it for boot

I agree with this, please see my previous comments, 
' When you say about complete boot, then this may not be useful.'

> 2) not a command described by UEFI Shell spec, but I keep seeing
>platforms including it even in RELEASE builds (most likely because 1)
> 3) code quality/maintainability

> > > If the code is to be kept, I think (from a quick glance) that I
> > > would also like to see
> > >   *Data = NULL
> > > in the error path of DownloadFile().
> 
> OK, so we don't need to drop it right now, but what's your take on this
> comment?

I am fine, if you prefer to remove this then we will develop some test 
application
for unit tests.
In case, we need to maintain this piece of code then above needs to fix as 
well. 

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

Re: [edk2] [PATCH] Tftp assert fix for openfile failure case

[Udit Kumar]

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Tuesday, November 07, 2017 11:25 PM
> To: Vabhav Sharma <vabhav.sha...@nxp.com>
> Cc: edk2-devel@lists.01.org; ruiyu...@intel.com; jaben.car...@intel.com;
> ard.biesheu...@linaro.org; siyuan...@intel.com; ting...@intel.com; Udit
> Kumar <udit.ku...@nxp.com>
> Subject: Re: [PATCH] Tftp assert fix for openfile failure case
> 
> On Fri, Nov 03, 2017 at 07:56:32PM +0530, Vabhav wrote:
> > Issue:
> > when file open is failed, assert was seen due to freeing 0 size page
> >
> > Reason:
> > DataSize is remain zero if error is reported in ShellOpenFileByName
> >
> > Fix:
> > Update DataSize as soon as FileSize is available
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Udit Kumar <udit.ku...@nxp.com>
> > Signed-off-by: Vabhav <vabhav.sha...@nxp.com>
> > ---
> >  ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > index fbde3bf..6425fc5 100755
> > --- a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > +++ b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > @@ -509,6 +509,7 @@ ShellCommandRunTftp (
> >);
> >goto NextHandle;
> 
> Wow, a goto in a foor loop in a 320-line function.
> What could possibly go wrong?

Instead of being on some volume, if you are on Shell. 
Then file open will fail. 
 
> >  }
> > +DataSize = FileSize;
> >
> >  Status = DownloadFile (Mtftp4, RemoteFilePath, AsciiRemoteFilePath,
> FileSize, BlockSize, );
> >  if (EFI_ERROR (Status)) {
> > @@ -539,7 +540,6 @@ ShellCommandRunTftp (
> >goto NextHandle;
> >  }
> >
> > -DataSize = FileSize;
> >  Status = ShellWriteFile (FileHandle, , Data);
> >  if (!EFI_ERROR (Status)) {
> >ShellStatus = SHELL_SUCCESS;
> > --
> > 1.9.1
> 
> So, a wider question:
> This shell command was introduced in the heyday of "let's reimplement U-Boot
> in the EDK2 tree". Mainly, from my impression, it seems to be used in order 
> that
> people don't need to learn how boot managers and device paths work.

When you say about complete boot, then this may not be useful. 

> Am I being too harsh?
> Are there practical uses for this?

For doing some sort of unit testing of given interface. I found this useful.
During development, this is useful to transfer generic file to development 
board. 

> Or should we delete it from the tree?
 
 
> If the code is to be kept, I think (from a quick glance) that I would also 
> like to see
> *Data = NULL in the error path of DownloadFile().
> 
> /
> Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC PATCH edk2-platforms 1/3] Silicon/NXP: add RTC support library for PCF8563 I2C IP

[Udit Kumar]

Thanks Ard, 
Your another patch set is addressing my concern 

Regards
Udit

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, November 06, 2017 4:41 PM
> To: Udit Kumar <udit.ku...@nxp.com>
> Cc: edk2-devel@lists.01.org; leif.lindh...@linaro.org;
> daniel.thomp...@linaro.org
> Subject: Re: [edk2] [RFC PATCH edk2-platforms 1/3] Silicon/NXP: add RTC
> support library for PCF8563 I2C IP
> 
> On 6 November 2017 at 11:09, Udit Kumar <udit.ku...@nxp.com> wrote:
> > Thanks Ard.
> > This will allow to use PCF8563 on any platform not limiting to targeted
> platform.
> 
> Yes, that was the intention.
> 
> > Few comments are inline.
> >
> 
> Thanks.
> 
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >> Of Ard Biesheuvel
> >> Sent: Friday, November 03, 2017 3:47 PM
> >> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org;
> >> daniel.thomp...@linaro.org
> >> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> >> Subject: [edk2] [RFC PATCH edk2-platforms 1/3] Silicon/NXP: add RTC
> >> support library for PCF8563 I2C IP
> >>
> >> Add a RealTimeClockLib implementation for the NXP PCF8563 as used on
> >> the Socionext Developer Box board. Note that the standard I2C
> >> protocol stack does not support runtime use, so this driver invokes
> >> the I2C master protocol directly. This requires support from the
> >> platform side as well, and so this driver will only attach to a I2C
> >> master that has the gPcf8563RealTimeClockLibI2cMasterProtolGuid
> >> protocol installed on its handle. It is up to the platform to ensure
> >> that the driver producing the I2C master protocol in question is
> >> runtime capable, and is not shared with the I2C protocol stack (i.e.,
> >> it should not have the I2C Bus Configuration Management protocol installed
> as well).
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> >> ---
> >>  Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
> |
> >> 385 
> >>
> >> Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.d
> >> ec |
> >> 29 ++
> >>
> >> Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.i
> >> nf |
> >> 52 +++
> >>  3 files changed, 466 insertions(+)
> >>
> >> diff --git
> >> a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib
> >> .c
> >> b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib
> >> .c
> >> new file mode 100644
> >> index ..fea65a225d7f
> >> --- /dev/null
> >> +++
> >> b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib
> >> .c
> >> @@ -0,0 +1,385 @@
> >> +/** @file
> >> +
> >> +  Copyright (c) 2017, Linaro, 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
> >> +
> >> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fope
> >> nso
> >> urce.org%2Flicenses%2Fbsd-
> >>
> license.php=02%7C01%7Cudit.kumar%40nxp.com%7C6faa68073eef4ed07
> >>
> 25208d522a40d65%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636
> >>
> 453010374642660=vDhroHNG20VCsMtj7%2FggWcWRG8hwt5fbV1Kv4R
> >> Na98Q%3D=0
> >> +
> >> +  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 
> >> +
> >> +#define SLAVE_ADDRESS (FixedPcdGet8 (PcdI2cSlaveAddress))
> >> +#define PCF8563_DATA_REG_OFFSET   0x2
> >> +
> >> +#define PCF8563_SECONDS_MASK  0x7f
> >> +#define PCF8563_MINUTES_MASK  0x7f
> >> +#define PCF8563_HOURS_MASK0x3f
> >> +#defi

Re: [edk2] [RFC PATCH edk2-platforms 1/3] Silicon/NXP: add RTC support library for PCF8563 I2C IP

[Udit Kumar]

Thanks Ard. 
This will allow to use PCF8563 on any platform not limiting to targeted 
platform. 
Few comments are inline.

Regards
Udit 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
> Biesheuvel
> Sent: Friday, November 03, 2017 3:47 PM
> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org;
> daniel.thomp...@linaro.org
> Cc: Ard Biesheuvel 
> Subject: [edk2] [RFC PATCH edk2-platforms 1/3] Silicon/NXP: add RTC support
> library for PCF8563 I2C IP
> 
> Add a RealTimeClockLib implementation for the NXP PCF8563 as used on
> the Socionext Developer Box board. Note that the standard I2C protocol
> stack does not support runtime use, so this driver invokes the I2C master
> protocol directly. This requires support from the platform side as well,
> and so this driver will only attach to a I2C master that has the
> gPcf8563RealTimeClockLibI2cMasterProtolGuid protocol installed on its
> handle. It is up to the platform to ensure that the driver producing
> the I2C master protocol in question is runtime capable, and is not
> shared with the I2C protocol stack (i.e., it should not have the I2C
> Bus Configuration Management protocol installed as well).
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c   |
> 385 
>  Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec |
> 29 ++
>  Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf |
> 52 +++
>  3 files changed, 466 insertions(+)
> 
> diff --git
> a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
> b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
> new file mode 100644
> index ..fea65a225d7f
> --- /dev/null
> +++
> b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
> @@ -0,0 +1,385 @@
> +/** @file
> +
> +  Copyright (c) 2017, Linaro, 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
> +
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenso
> urce.org%2Flicenses%2Fbsd-
> license.php=02%7C01%7Cudit.kumar%40nxp.com%7C6faa68073eef4ed07
> 25208d522a40d65%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636
> 453010374642660=vDhroHNG20VCsMtj7%2FggWcWRG8hwt5fbV1Kv4R
> Na98Q%3D=0
> +
> +  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 
> +
> +#define SLAVE_ADDRESS (FixedPcdGet8 (PcdI2cSlaveAddress))
> +#define PCF8563_DATA_REG_OFFSET   0x2
> +
> +#define PCF8563_SECONDS_MASK  0x7f
> +#define PCF8563_MINUTES_MASK  0x7f
> +#define PCF8563_HOURS_MASK0x3f
> +#define PCF8563_DAYS_MASK 0x3f
> +#define PCF8563_WEEKDAYS_MASK 0x07
> +#define PCF8563_MONTHS_MASK   0x1f
> +#define PCF8563_CENTURY_MASK  0x80
> +
> +#define EPOCH_BASE2000
> +
> +STATIC EFI_HANDLE mI2cMasterHandle;
> +STATIC VOID   *mDriverEventRegistration;
> +STATIC EFI_I2C_MASTER_PROTOCOL*mI2cMaster;
> +STATIC EFI_EVENT  mRtcVirtualAddrChangeEvent;
> +
> +typedef struct {
> +  UINTN   OperationCount;
> +  EFI_I2C_OPERATION   SetAddressOp;
> +  EFI_I2C_OPERATION   GetSetDateTimeOp;
> +} RTC_I2C_REQUEST;
> +
> +#pragma pack(1)
> +typedef struct {
> +  UINT8 VL_seconds;
> +  UINT8 Minutes;
> +  UINT8 Hours;
> +  UINT8 Days;
> +  UINT8 Weekdays;
> +  UINT8 Century_months;
> +  UINT8 Years;
> +} RTC_DATETIME;
> +#pragma pack()
> +
> +/**
> +  Returns the current time and date information, and the time-keeping
> +  capabilities of the hardware platform.
> +
> +  @param  Time  A pointer to storage to receive a snapshot of
> +the current time.
> +  @param  Capabilities  An optional pointer to a buffer to receive 
> the
> +real time clock device's capabilities.
> +
> +  @retval EFI_SUCCESS   The operation completed successfully.
> +  @retval EFI_INVALID_PARAMETER Time is NULL.
> +  @retval EFI_DEVICE_ERROR  The time could not be retrieved due to
> hardware
> +error.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +LibGetTime (
> +  OUT EFI_TIME*Time,
> +  OUT EFI_TIME_CAPABILITIES   *Capabilities
> +  )
> +{
> +  RTC_I2C_REQUEST Op;
> +  RTC_DATETIME

Re: [edk2] Storing Non volatile variables on SD/NAND

[Udit Kumar]

Thanks Jeremy 

> Hi,
> 
> On 10/27/2017 10:09 PM, Udit Kumar wrote:
> >> (along those lines)
> >>
> >> 6 - Build an emulated disk controller as well as NV region in el3 (or
> >> el2) and export them to UEFI & the OS as real devices. Then
> >> trap/forward requests to the actual storage device, which is
> >> "hidden". This AFAIK was the basic idea behind the PS/2 emulation in
> >> x86/SMM. Again, probably not a high performance option.
> >
> > You mean, have a driver in el3 or el2 and UEFI or OS is doing smc call to 
> > get
> things done.
> > On this line,  some sort of permission manager could reside in el3 or el2.
> > Either UEFI or OS driver needs to make a call, if they are allowed to
> > access this specific controller or other driver is accessing it.
> > With this  performance issue could be ironed out .
> 
> That isn't really what I meant, what I was thinking about was creating an
> emulated (AHCI for example) controller where accesses to the "register" space
> would trap to synchronous data/external aborts. That way the firmware and OS
> could use existing drivers without knowledge that the device was in any way
> special. If you create a driver and do SMC/whatever calls, then your basically
> doing #5..

This may work if both OS and UEFI are residing is same EL level.  
Do you mean, to get access to controller use this trap or entire AHCI space in
unmapped area, which will leads to synchronous aborts.

> 
> >
> > Regards
> > Udit
> >
> >> -Original Message-
> >> From: Jeremy Linton [mailto:jeremy.lin...@arm.com]
> >> Sent: Friday, October 27, 2017 11:16 PM
> >> To: Ard Biesheuvel <ard.biesheu...@linaro.org>; Udit Kumar
> >> <udit.ku...@nxp.com>
> >> Cc: edk2-devel@lists.01.org; Andrew Fish <af...@apple.com>;
> >> olivier.mar...@arm.com; Vladimir Olovyannikov
> >> <vladimir.olovyanni...@broadcom.com>
> >> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> >>
> >> On 09/20/2017 12:39 PM, Ard Biesheuvel wrote:
> >>> On 20 September 2017 at 10:34, Udit Kumar <udit.ku...@nxp.com> wrote:
> >>>>
> >>>> When we want to have UEFI and OS accessing same media ,
> >>>> Possibilities I see
> >>>>
> >>>> 1- Patch OS For status check of media (diversion from generic OS),
> >>>> Good case
> >> will be modify low level driver.
> >>>> But we may end up some surprises on synchronization.
> >>>>
> >>>> 2- no runtime service for OS . I guess this will not be possible
> >>>>
> >>>> 3- Way the  Vladimir implemented for eMMC, This has risk of losing
> >>>> data in
> >> case of AC power off.
> >>>>
> >>>> 4- update hardware with dual view (Ard suggestion)
> >>>>
> >>>
> >>> 5 - abstract direct block device access into a firmware service that
> >>> is exposed via a DXE_RUNTIME_DRIVER.
> >>
> >> (along those lines)
> >>
> >> 6 - Build an emulated disk controller as well as NV region in el3 (or
> >> el2) and export them to UEFI & the OS as real devices. Then
> >> trap/forward requests to the actual storage device, which is
> >> "hidden". This AFAIK was the basic idea behind the PS/2 emulation in
> >> x86/SMM. Again, probably not a high performance option.
> >>
> >>
> >>>
> >>> The UEFI spec allows you to expose entry points into a
> >>> DXE_RUNTIME_DRIVER module via a UEFI configuration table, and the OS
> >>> can use a driver that uses the abstracted device rather than the
> >>> real device. Performance is going to be terrible, probably, and lots
> >>> of things that are specific to SD/MMC will no longer work, but it is
> >>> a possibility nonetheless.
> >>> ___
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org
> >>>
> >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> >> sts.01
> >> .org%2Fmailman%2Flistinfo%2Fedk2-
> >>
> devel=02%7C01%7Cudit.kumar%40nxp.com%7Cfe11f07ea67a4efa7d1b08
> >>
> d51d629deb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63644723
> >>
> 1755528994=FYnH3ItGhXmqxNr%2BnaJBFMcKKduf%2FcS06JEA6dT6ZQA
> >> %3D=0
> >>>
> >

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

Re: [edk2] Storing Non volatile variables on SD/NAND

[Udit Kumar]

> (along those lines)
> 
> 6 - Build an emulated disk controller as well as NV region in el3 (or
> el2) and export them to UEFI & the OS as real devices. Then trap/forward
> requests to the actual storage device, which is "hidden". This AFAIK was the
> basic idea behind the PS/2 emulation in x86/SMM. Again, probably not a high
> performance option.

You mean, have a driver in el3 or el2 and UEFI or OS is doing smc call to get 
things done. 
On this line,  some sort of permission manager could reside in el3 or el2. 
Either UEFI or OS driver needs to make a call, if they are allowed to access 
this 
specific controller or other driver is accessing it. 
With this  performance issue could be ironed out . 

Regards
Udit

> -Original Message-
> From: Jeremy Linton [mailto:jeremy.lin...@arm.com]
> Sent: Friday, October 27, 2017 11:16 PM
> To: Ard Biesheuvel <ard.biesheu...@linaro.org>; Udit Kumar
> <udit.ku...@nxp.com>
> Cc: edk2-devel@lists.01.org; Andrew Fish <af...@apple.com>;
> olivier.mar...@arm.com; Vladimir Olovyannikov
> <vladimir.olovyanni...@broadcom.com>
> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> 
> On 09/20/2017 12:39 PM, Ard Biesheuvel wrote:
> > On 20 September 2017 at 10:34, Udit Kumar <udit.ku...@nxp.com> wrote:
> >>
> >> When we want to have UEFI and OS accessing same media , Possibilities
> >> I see
> >>
> >> 1- Patch OS For status check of media (diversion from generic OS), Good 
> >> case
> will be modify low level driver.
> >> But we may end up some surprises on synchronization.
> >>
> >> 2- no runtime service for OS . I guess this will not be possible
> >>
> >> 3- Way the  Vladimir implemented for eMMC, This has risk of losing data in
> case of AC power off.
> >>
> >> 4- update hardware with dual view (Ard suggestion)
> >>
> >
> > 5 - abstract direct block device access into a firmware service that
> > is exposed via a DXE_RUNTIME_DRIVER.
> 
> (along those lines)
> 
> 6 - Build an emulated disk controller as well as NV region in el3 (or
> el2) and export them to UEFI & the OS as real devices. Then trap/forward
> requests to the actual storage device, which is "hidden". This AFAIK was the
> basic idea behind the PS/2 emulation in x86/SMM. Again, probably not a high
> performance option.
> 
> 
> >
> > The UEFI spec allows you to expose entry points into a
> > DXE_RUNTIME_DRIVER module via a UEFI configuration table, and the OS
> > can use a driver that uses the abstracted device rather than the real
> > device. Performance is going to be terrible, probably, and lots of
> > things that are specific to SD/MMC will no longer work, but it is a
> > possibility nonetheless.
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01
> .org%2Fmailman%2Flistinfo%2Fedk2-
> devel=02%7C01%7Cudit.kumar%40nxp.com%7Cfe11f07ea67a4efa7d1b08
> d51d629deb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63644723
> 1755528994=FYnH3ItGhXmqxNr%2BnaJBFMcKKduf%2FcS06JEA6dT6ZQA
> %3D=0
> >

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

Re: [edk2] Storing Non volatile variables on SD/NAND

[Udit Kumar]

Thanks Ard. 

> The UEFI spec allows you to expose entry points into a DXE_RUNTIME_DRIVER
> module via a UEFI configuration table, and the OS can use a driver that uses 
> the
> abstracted device rather than the real device. Performance is going to be

Could you point me to some sample driver using this scheme, 
Mainly around OS implementation 

Regards 
Udit

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, September 20, 2017 11:09 PM
> To: Udit Kumar <udit.ku...@nxp.com>
> Cc: Pankaj Bansal <pankaj.ban...@nxp.com>; Andrew Fish <af...@apple.com>;
> olivier.mar...@arm.com; Vladimir Olovyannikov
> <vladimir.olovyanni...@broadcom.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> 
> On 20 September 2017 at 10:34, Udit Kumar <udit.ku...@nxp.com> wrote:
> >
> > When we want to have UEFI and OS accessing same media , Possibilities
> > I see
> >
> > 1- Patch OS For status check of media (diversion from generic OS), Good case
> will be modify low level driver.
> > But we may end up some surprises on synchronization.
> >
> > 2- no runtime service for OS . I guess this will not be possible
> >
> > 3- Way the  Vladimir implemented for eMMC, This has risk of losing data in
> case of AC power off.
> >
> > 4- update hardware with dual view (Ard suggestion)
> >
> 
> 5 - abstract direct block device access into a firmware service that is 
> exposed via
> a DXE_RUNTIME_DRIVER.
> 
> The UEFI spec allows you to expose entry points into a DXE_RUNTIME_DRIVER
> module via a UEFI configuration table, and the OS can use a driver that uses 
> the
> abstracted device rather than the real device. Performance is going to be
> terrible, probably, and lots of things that are specific to SD/MMC will no 
> longer
> work, but it is a possibility nonetheless.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Storing Non volatile variables on SD/NAND

[Udit Kumar]

Hi Andrew, 

> The concept of a runtime EFI driver is in the UEFI spec, but the issue is 
> there is no
> way to tell the OS to not bind it's driver for that device that is universal. 
> If you
> boot an unmodified OS it is going to conflict with the EFI runtime service.

In order to bind driver with universal device, OS driver could be modified
and device tree could indicate if this storage is shared with BIOS runtime. 
(Assuming booting Linux)
 
But I am struggling here, how OS will get services of this driver. 
I assume in Linux, struct efi_runtime_services is fixed  as per specs. 

Will this modified driver, needs to access unsigned long runtime; of struct efi 
to get 
UEFI run time services ? 


> My gut feel is if the OS has a driver for the device it may be better to make 
> the
> media format the architectural point. That way the OS can read/write it via a
> driver/app. There could be an UEFI Services Table entry that implies what
> scheme is being used. That way there is only every one owner of the hardware
> device. I assume #3 is like this?

Yeah , probably can think of this,  if OS update the runtime variables without
help of UEFI runtime services using some sort of file system.  

Thanks
Udit

> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Wednesday, September 20, 2017 11:16 PM
> To: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Cc: Udit Kumar <udit.ku...@nxp.com>; edk2-devel@lists.01.org;
> olivier.mar...@arm.com; Vladimir Olovyannikov
> <vladimir.olovyanni...@broadcom.com>
> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> 
> 
> > On Sep 20, 2017, at 10:39 AM, Ard Biesheuvel <ard.biesheu...@linaro.org>
> wrote:
> >
> > On 20 September 2017 at 10:39, Ard Biesheuvel <ard.biesheu...@linaro.org>
> wrote:
> >> On 20 September 2017 at 10:34, Udit Kumar <udit.ku...@nxp.com> wrote:
> >>>
> >>> When we want to have UEFI and OS accessing same media ,
> >>> Possibilities I see
> >>>
> >>> 1- Patch OS For status check of media (diversion from generic OS), Good
> case will be modify low level driver.
> >>> But we may end up some surprises on synchronization.
> >>>
> >>> 2- no runtime service for OS . I guess this will not be possible
> >>>
> >>> 3- Way the  Vladimir implemented for eMMC, This has risk of losing data in
> case of AC power off.
> >>>
> >>> 4- update hardware with dual view (Ard suggestion)
> >>>
> >>
> >> 5 - abstract direct block device access into a firmware service that
> >> is exposed via a DXE_RUNTIME_DRIVER.
> >>
> >> The UEFI spec allows you to expose entry points into a
> >> DXE_RUNTIME_DRIVER module via a UEFI configuration table, and the OS
> >> can use a driver that uses the abstracted device rather than the real
> >> device. Performance is going to be terrible, probably, and lots of
> >> things that are specific to SD/MMC will no longer work, but it is a
> >> possibility nonetheless.
> >
> > BTW this would go beyond the UEFI spec, and would effectively be a
> > PI/UEFI dependent feature.
> 
> The concept of a runtime EFI driver is in the UEFI spec, but the issue is 
> there is no
> way to tell the OS to not bind it's driver for that device that is universal. 
> If you
> boot an unmodified OS it is going to conflict with the EFI runtime service.
> 
> My gut feel is if the OS has a driver for the device it may be better to make 
> the
> media format the architectural point. That way the OS can read/write it via a
> driver/app. There could be an UEFI Services Table entry that implies what
> scheme is being used. That way there is only every one owner of the hardware
> device. I assume #3 is like this?
> 
> Thanks,
> 
> Andrew Fish
> 
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [PATCH v2 2/3] ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.

[Udit Kumar]

Hi 

> +  Status = gBS->AllocatePages (AllocateAddress,
> +   EfiRuntimeServicesData,
> +   EFI_SIZE_TO_PAGES 
> (mNsCommBuffMemRegion.Length),
> +   );
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "MmCommunicateInitialize: Failed to allocate MM-
> NS Buffer Memory Space\n"));
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  // Install the communication protocol  Status =
> + gBS->InstallProtocolInterface (,
> +  ,
> +  EFI_NATIVE_INTERFACE,
> +  );  if
> + (EFI_ERROR(Status)) {
> +DEBUG ((DEBUG_ERROR, "MmCommunicationInitialize: Failed to install MM
> communication protocol\n"));

In case of error, you could free the above allocated memory 

> +return EFI_INVALID_PARAMETER;
> +  

Regards
Udit 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Supreeth Venkatesh
> Sent: Wednesday, October 25, 2017 10:03 PM
> To: edk2-devel@lists.01.org
> Cc: leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v2 2/3] ArmPkg/Drivers: Add
> EFI_MM_COMMUNICATION_PROTOCOL DXE driver.
> 
> PI v1.5 Specification Volume 4 defines Management Mode Core Interface and
> defines EFI_MM_COMMUNICATION_PROTOCOL. This protocol provides a
> means of communicating between drivers outside of MM and MMI handlers
> inside of MM.
> 
> This patch implements the EFI_MM_COMMUNICATION_PROTOCOL DXE
> runtime driver for AARCH64 platforms. It uses SMCs allocated from the standard
> SMC range defined in
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Finfocen
> ter.arm.com%2Fhelp%2Ftopic%2Fcom.arm.doc.den0060a%2FDEN0060A_ARM_
> MM_Interface_Specification.pdf=02%7C01%7Cudit.kumar%40nxp.com%7
> C43194cfd48f84756da6908d51bc6185b%7C686ea1d3bc2b4c6fa92cd99c5c3016
> 35%7C0%7C1%7C636445460008712743=Nk9bnFSzqB4zxCcyd4C2HyqZ2a
> Iluu%2FWKXOVho4a6g8%3D=0
> to communicate with the standalone MM environment in the secure world.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta 
> Signed-off-by: Supreeth Venkatesh 
> ---
>  .../Drivers/MmCommunicationDxe/MmCommunication.c   | 339
> +
>  1 file changed, 339 insertions(+)
>  create mode 100644
> ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> 
> diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> new file mode 100644
> index 00..ecf70e666c
> --- /dev/null
> +++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> @@ -0,0 +1,339 @@
> +/** @file
> +
> +  Copyright (c) 2016-2017, 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
> +
> + https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopen
> + source.org%2Flicenses%2Fbsd-
> license.php=02%7C01%7Cudit.kumar%40nx
> +
> p.com%7C43194cfd48f84756da6908d51bc6185b%7C686ea1d3bc2b4c6fa92cd9
> 9c5c3
> +
> 01635%7C0%7C0%7C636445460008712743=%2Fw7nb5B%2Bw3NKLV4v
> 5LwcaQ0%2
> + F6gh2Cva%2FEyDsb69NEAM%3D=0
> +
> +  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 
> +
> +/**
> +  Communicates with a registered handler.
> +
> +  This function provides an interface to send and receive messages to
> + the  Standalone MM environment on behalf of UEFI services.  This
> + function is part  of the MM Communication Protocol that may be called
> + in physical mode prior to
> +  SetVirtualAddressMap() and in virtual mode after SetVirtualAddressMap().
> +
> +  @param[in]  ThisThe EFI_MM_COMMUNICATION_PROTOCOL
> instance.
> +  @param[in, out] CommBuffer  A pointer to the buffer to convey into
> MMRAM.
> +  @param[in, out] CommSizeThe size of the data buffer being 
> passed
> in.On exit, the size of data
> +  being returned. Zero if the handler 
> does not wish to reply
> with any data.
> +
> +  @retval EFI_SUCCESS The message was successfully posted.
> +  @retval EFI_INVALID_PARAMETER   The CommBuffer was NULL.
> +  @retval EFI_BAD_BUFFER_SIZE The buffer is too large for the MM
> implementation. If this error is
> +  returned, the MessageLength field in 
> the CommBuffer
> header or the integer
> +  pointed by 

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

[Udit Kumar]

Hi Meenakshi/Liming, 
My 2 cents, around this. 

1)
Having a new lib for BE read might not be helpful for us, 
e.g. a IP which is in BE mode access the UART for print or system registers 
which are in LE, 
then with new Lib, we will get all read/write in BE mode 

2)
Especially for our IPs, which are changing from BE to LE depending on platform. 
As said before, having BE read lib with API name of MmioRead32 etc, will not 
help (I guess Meenakshi already seen some problems around this)
Adding a new lib with MmioRead32BE API name could help, but IP driver we need 
to take care of IP mode either by Pcd or #define, to select MmioRead32 or 
MmioRead32BE. 
This conditional compile needs to be done for all IPs (which works in BE/LE 
mode on different platforms). 

My preferred way of implementation to use one function in IP driver, 
And based on IP mode, do the switch. 

New Lib could have function like below 
MmioRead32Generic(IN  UINTN Address, BOOL IsIPBE) {
   UINT32Value;
 
   ASSERT ((Address & 3) == 0);
   Value = *(volatile UINT32*)Address;
   If(IsIPBE)
 Value = SwapBytes32(Value);
 return  Value;
}

And IP driver can use it 
MmioRead32Generic(ADDR, FixedPcdGet(This_IP_Mode_For_This_platform)

Comments are welcome. 

Regards
Udit

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao,
> Liming
> Sent: Monday, October 16, 2017 8:48 AM
> To: Meenakshi Aggarwal ; Ard Biesheuvel
> ; Kinney, Michael D ;
> edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian
> MMIO
> 
> Meenakshi:
>   I suggest to introduce new IoLib library instance, not to add new IoLib 
> APIs.
> New IoLib library instance will perform IO operation as the big endian. You 
> can
> update MdePkg/Library/BaseIoLibIntrinsic instance, add new source file and
> new INF for it.
> 
> UINT32
> EFIAPI
> MmioRead32 (
>   IN  UINTN Address
>   )
> {
>   UINT32Value;
> 
>   ASSERT ((Address & 3) == 0);
>   Value = *(volatile UINT32*)Address;
>   return SwapBytes32(Value);
> }
> 
> Thanks
> Liming
> >-Original Message-
> >From: Meenakshi Aggarwal [mailto:meenakshi.aggar...@nxp.com]
> >Sent: Friday, October 13, 2017 2:07 PM
> >To: Ard Biesheuvel ; Kinney, Michael D
> >; edk2-devel@lists.01.org; Gao, Liming
> >
> >Subject: RE: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for
> >big-endian MMIO
> >
> >Hi All,
> >
> >
> >It’s a pretty old discussion, we have left the upstreaming of NXP
> >package in between because of some other work, but have started it again
> now.
> >
> >
> >Issue  : Few NXP modules support Big Endian MMIOs as these are ported
> >from PowerPC.
> >
> >Solution suggested : Create a separate library for BE MMIO APIs.
> >
> >
> >So what I have done is, I have created a separate library to support BE
> >MMIO APIs and currently keeping it to my package.
> >This library is basically a wrapper over existing MMIO APIs.
> >
> >UINT32
> >EFIAPI
> >BeMmioRead32 (
> >  IN  UINTN Address
> >  )
> >{
> >  UINT32  Value;
> >
> >  Value = MmioRead32(Address);
> >
> >  return SwapBytes32(Value);
> >}
> >
> >
> >Need your opinion on below optinos:
> >
> >1. Will this be a good idea to make this library a part of MdePkg? OR
> >
> >2. Add a new file e.g. IoBeMmio.c like IoHighLevel.c in
> >MdePkg/Library/BaseIoLibIntrinsic/
> > And made these APIs a part of IoLib itself. OR
> >
> >3. Keep this library internal to NXP package.
> >
> >
> >Please provide your inputs.
> >
> >
> >Thanks & Regards,
> >Meenakshi
> >
> >> -Original Message-
> >> From: Bhupesh Sharma
> >> Sent: Monday, October 17, 2016 3:28 PM
> >> To: Ard Biesheuvel ; Kinney, Michael D
> >> 
> >> Cc: Gao, Liming ; edk2-de...@ml01.01.org;
> >> Meenakshi Aggarwal 
> >> Subject: RE: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for
> >> big-endian MMIO
> >>
> >> Hi Ard,
> >>
> >> > -Original Message-
> >> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> > Sent: Monday, October 17, 2016 1:12 PM
> >> > To: Kinney, Michael D 
> >> > Cc: Gao, Liming ; Bhupesh Sharma
> >> > ; edk2-de...@ml01.01.org
> >> > Subject: Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-
> >> > endian MMIO
> >> >
> >> > On 17 October 2016 at 05:10, Kinney, Michael D
> >> >  wrote:
> >> > > Bhupesh,
> >> > >
> >> > > It is also possible to add an ARM specific PCD to select
> >> > > endianness and update
> >> > > MdePkg/Library/BaseIoLibIntrinsic/IoLibArm.c to use that PCD in
> >> > > MmioRead/Write() APIs in that file to support both endian types.
> >> > > You 

Re: [edk2] USB Enumeration

[Udit Kumar]

Ticket 
https://bugzilla.tianocore.org/show_bug.cgi?id=729 is created. 

Thx
Udit

> -Original Message-
> From: Udit Kumar
> Sent: Thursday, October 05, 2017 6:55 PM
> To: 'Zeng, Star' <star.z...@intel.com>
> Cc: edk2-devel-01 <edk2-devel@lists.01.org>
> Subject: RE: [edk2] USB Enumeration
> 
> Thanks Star.
> I will open the ticket with needed information.
> 
> What looks to me when we are enabling slot again then memory for all endpoint
> is not allocated.
> Allocation is done for endpoint[0] say slot context.
> 
> FYI, If I ignore this error then assert is reported in
> /MdeModulePkg/Core/Dxe/Mem/Page.c(722)
> 
> Regards
> Udit
> 
> > -Original Message-
> > From: Zeng, Star [mailto:star.z...@intel.com]
> > Sent: Thursday, October 05, 2017 6:16 PM
> > To: Udit Kumar <udit.ku...@nxp.com>; edk2-devel-01  > de...@lists.01.org>
> > Cc: Zeng, Star <star.z...@intel.com>
> > Subject: RE: [edk2] USB Enumeration
> >
> > We (I) did not see this appearance before, but the ASSERT should be
> unexpected.
> >
> > Could you try to use error handling instead of ASSERT for this line of
> > code and see whether it works or not for you?
> >
> > What are the models of the Host controller and USB device?
> > Do you have full debug log for that?
> > Did you meet the ASSERT before(for example, using the code base at the
> > beginning of this year) with the same Host controller and USB device?
> >
> > Could you submit Bugzilla at https://bugzilla.tianocore.org/ with the
> > information for the questions you have above? Then we can have follow
> > up to check the detail by the information provided (if we can produce
> > it by ourselves, that will be better). :)
> >
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Udit Kumar
> > Sent: Thursday, October 5, 2017 8:05 PM
> > To: edk2-devel-01 <edk2-devel@lists.01.org>
> > Subject: [edk2] USB Enumeration
> >
> > Dear Edk2 Expert,
> >
> > With edk2 shell, I am doing simple copy with USB, Flow is below
> >
> > Start- USB device is enumerated and given address 1.
> > 1. On Shell , cp a b
> > 2- After a while Host controller reports an error
> > 3- Layer above Host controller, reset the USB port
> > 4-  and Slot is enabled again ( this time address 2 was given)
> > 5- Now FatIFileAccess calls FatCleanupVolume, which in turn calls
> > XhcBulkTransfer And assert is reported at
> > MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c(1800): TrsRing != ((void *)
> > 0)
> >
> > Is this expected behavior to assert, or reporting an error will be
> > fine in such cases.
> >
> > Thanks for help
> >
> > Regards
> > Udit
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] USB Enumeration

[Udit Kumar]

Thanks Star. 
I will open the ticket with needed information. 

What looks to me when we are enabling slot again
then memory for all endpoint is not allocated.
Allocation is done for endpoint[0] say slot context.

FYI, If I ignore this error then assert is reported in 
/MdeModulePkg/Core/Dxe/Mem/Page.c(722)

Regards
Udit

> -Original Message-
> From: Zeng, Star [mailto:star.z...@intel.com]
> Sent: Thursday, October 05, 2017 6:16 PM
> To: Udit Kumar <udit.ku...@nxp.com>; edk2-devel-01  de...@lists.01.org>
> Cc: Zeng, Star <star.z...@intel.com>
> Subject: RE: [edk2] USB Enumeration
> 
> We (I) did not see this appearance before, but the ASSERT should be 
> unexpected.
> 
> Could you try to use error handling instead of ASSERT for this line of code 
> and
> see whether it works or not for you?
> 
> What are the models of the Host controller and USB device?
> Do you have full debug log for that?
> Did you meet the ASSERT before(for example, using the code base at the
> beginning of this year) with the same Host controller and USB device?
> 
> Could you submit Bugzilla at https://bugzilla.tianocore.org/ with the 
> information
> for the questions you have above? Then we can have follow up to check the
> detail by the information provided (if we can produce it by ourselves, that 
> will be
> better). :)
> 
> 
> Thanks,
> Star
> -----Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Udit
> Kumar
> Sent: Thursday, October 5, 2017 8:05 PM
> To: edk2-devel-01 <edk2-devel@lists.01.org>
> Subject: [edk2] USB Enumeration
> 
> Dear Edk2 Expert,
> 
> With edk2 shell, I am doing simple copy with USB, Flow is below
> 
> Start- USB device is enumerated and given address 1.
> 1. On Shell , cp a b
> 2- After a while Host controller reports an error
> 3- Layer above Host controller, reset the USB port
> 4-  and Slot is enabled again ( this time address 2 was given)
> 5- Now FatIFileAccess calls FatCleanupVolume, which in turn calls
> XhcBulkTransfer And assert is reported at
> MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c(1800): TrsRing != ((void *) 0)
> 
> Is this expected behavior to assert, or reporting an error will be fine in 
> such
> cases.
> 
> Thanks for help
> 
> Regards
> Udit
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] USB Enumeration

[Udit Kumar]

Dear Edk2 Expert, 

With edk2 shell, I am doing simple copy with USB, 
Flow is below 

Start- USB device is enumerated and given address 1.
1. On Shell , cp a b
2- After a while Host controller reports an error 
3- Layer above Host controller, reset the USB port
4-  and Slot is enabled again ( this time address 2 was given)
5- Now FatIFileAccess calls FatCleanupVolume, which in turn calls 
XhcBulkTransfer
And assert is reported at
MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c(1800): TrsRing != ((void *) 0)

Is this expected behavior to assert, or reporting an error will be fine in such 
cases. 

Thanks for help 

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

Re: [edk2] [PATCH] MdeModulePkg/DxeCore: Add comments for the ASSERT to check NULL ptr

[Udit Kumar]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hao
> Wu
> Sent: Thursday, September 28, 2017 12:31 PM
> To: edk2-devel@lists.01.org
> Cc: Hao Wu ; Michael D Kinney
> ; Jiewen Yao ; Star Zeng
> 
> Subject: [edk2] [PATCH] MdeModulePkg/DxeCore: Add comments for the
> ASSERT to check NULL ptr
> 
> Commit 8932679df5be046feba30fae80776c5815232a08 adds an ASSERT for
> checking NULL pointer dereference.
> 
> This commit adds comments to clarify the reason for using ASSERT as the check.
> 
> Cc: Star Zeng 
> Cc: Michael D Kinney 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Core/Dxe/Hand/Handle.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Hand/Handle.c
> b/MdeModulePkg/Core/Dxe/Hand/Handle.c
> index 2db441725c..344ff1fe02 100644
> --- a/MdeModulePkg/Core/Dxe/Hand/Handle.c
> +++ b/MdeModulePkg/Core/Dxe/Hand/Handle.c
> @@ -1175,10 +1175,15 @@ Done:
>  //
>  if (!EFI_ERROR (Status) || Status == EFI_ALREADY_STARTED) {
>//
> +  // According to above logic, if 'Prot' is NULL, then the 'Status' must 
> be
> +  // EFI_UNSUPPORTED. Here the 'Status' is not EFI_UNSUPPORTED, so 'Prot'
> +  // must be not NULL.
> +  //
> +  ASSERT (Prot != NULL);
> +  //

I think , we should take care of no debug environment here 
If MDEPKG_NDEBUG is not defined and Prot is NULL then 
shouldn't we return error ?

>// EFI_ALREADY_STARTED is not an error for bus driver.
>// Return the corresponding protocol interface.
>//
> -  ASSERT (Prot != NULL);
>*Interface = Prot->Interface;
>  } else if (Status == EFI_UNSUPPORTED) {
>//
> --
> 2.12.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] SNP transmit print

[Udit Kumar]

Thanks Meenakshi for digging a bit more 

If we have use like below 
Library/DxeNetLib/DxeNetLib.c
Status = Snp->Transmit (Snp, 0, Length, Packet, NULL, NULL, NULL);
if ((Status != EFI_SUCCESS) && (Status != EFI_NOT_READY)) {
  Status = EFI_DEVICE_ERROR;
  break;
}
Then, we can simple put print when Status is EFI_DEVICE_ERROR;

But with below We are retrying once ☹ ,  What I think if first time if you got 
error 
EFI_NOT_READY, then after MnpRecycleTxBuf we likely not to get this error. 
I am not 100% sure here. 

What I think, in MdeModulePkg/Universal/Network/SnpDxe/Transmit.c 
Have print only for EFI_NOT_READY. 
And in MdeModulePkg/Universal/Network/MnpDxe/MnpIo.c, print error as well 
for second case. 
Hope this helps 

Thanks
Udit

> -Original Message-
> From: Meenakshi Aggarwal
> Sent: Friday, September 22, 2017 3:56 PM
> To: Udit Kumar <udit.ku...@nxp.com>; edk2-devel@lists.01.org
> Cc: feng.t...@intel.com; star.z...@intel.com
> Subject: RE: SNP transmit print
> 
> Hi Udit,
> 
> Yes, I think we should print this message is Status is EFI_DEVICE_ERROR 
> because
> in case of EFI_NOT_READY, we are retrying:
> 
>   //
>   // Transmit the packet through SNP.
>   //
>   Status = Snp->Transmit (
>   Snp,
>   HeaderSize,
>   Length,
>   Packet,
>   TxData->SourceAddress,
>   TxData->DestinationAddress,
>   
>   );
>   if (Status == EFI_NOT_READY) {
> Status = MnpRecycleTxBuf (MnpDeviceData);
> if (EFI_ERROR (Status)) {
>   Token->Status = EFI_DEVICE_ERROR;
>   goto SIGNAL_TOKEN;
> }
> 
> DEBUG ((EFI_D_ERROR, "Snp->Transmit  retry\n"));
> Status = Snp->Transmit (
> Snp,
> HeaderSize,
> Length,
> Packet,
> TxData->SourceAddress,
> TxData->DestinationAddress,
> 
> );
>   }
> 
> (MdeModulePkg/Universal/Network/MnpDxe/MnpIo.c)
> 
> 
> Please suggest if we can remove this print in case of BUSY status.
> 
> Thanks,
> Meenakshi
> 
> > -Original Message-
> > From: Udit Kumar
> > Sent: Thursday, September 21, 2017 5:21 PM
> > To: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>; edk2-
> > de...@lists.01.org
> > Subject: RE: SNP transmit print
> >
> > I think these error prints should be check against Status
> >
> > Regards
> > Udit
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > > Of Meenakshi Aggarwal
> > > Sent: Thursday, September 21, 2017 3:36 PM
> > > To: edk2-devel@lists.01.org
> > > Subject: [edk2] SNP transmit print
> > >
> > > Hi,
> > >
> > >
> > > While performing tftp using PCI interface, below message is coming
> > > continuously:
> > >
> > > Snp->undi.transmit()  8000h:4h
> > >
> > > Snp->undi.transmit()  8000h:4h
> > > [==> ]   34812 Kb
> > > Snp->undi.transmit()  8000h:4h
> > >
> > > Snp->undi.transmit()  8000h:4h
> > >
> > > Snp->undi.transmit()  8000h:4h
> > >
> > > Snp->undi.transmit()  8000h:4h
> > >
> > >
> > > It is coming from file
> > "MdeModulePkg/Universal/Network/SnpDxe/Transmit.c"
> > >
> > >   DEBUG (
> > > (EFI_D_ERROR,
> > > "\nSnp->undi.transmit()  %xh:%xh\n",
> > > Snp->Cdb.StatFlags,
> > > Snp->Cdb.StatCode)
> > > );
> > >
> > >
> > > I want to know if it is really an error message because tftp and
> > > ping are working perfectly, but this error message is coming.
> > >
> > >
> > > Thanks,
> > > Meenakshi
> > >
> > >
> > >
> > > ___
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] SNP transmit print

[Udit Kumar]

I think these error prints should be check against Status 

Regards
Udit

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Meenakshi Aggarwal
> Sent: Thursday, September 21, 2017 3:36 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] SNP transmit print
> 
> Hi,
> 
> 
> While performing tftp using PCI interface, below message is coming
> continuously:
> 
> Snp->undi.transmit()  8000h:4h
> 
> Snp->undi.transmit()  8000h:4h
> [==> ]   34812 Kb
> Snp->undi.transmit()  8000h:4h
> 
> Snp->undi.transmit()  8000h:4h
> 
> Snp->undi.transmit()  8000h:4h
> 
> Snp->undi.transmit()  8000h:4h
> 
> 
> It is coming from file "MdeModulePkg/Universal/Network/SnpDxe/Transmit.c"
> 
>   DEBUG (
> (EFI_D_ERROR,
> "\nSnp->undi.transmit()  %xh:%xh\n",
> Snp->Cdb.StatFlags,
> Snp->Cdb.StatCode)
> );
> 
> 
> I want to know if it is really an error message because tftp and ping are 
> working
> perfectly, but this error message is coming.
> 
> 
> Thanks,
> Meenakshi
> 
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux

[Udit Kumar]

Hi Liming

>So, for this case, I suggest to
> create memory hob instead of resource hob with non present memory attribute.

ARM package is already creating a memory HoB for the same.

Thanks
Udit

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao,
> Liming
> Sent: Wednesday, September 20, 2017 8:29 PM
> To: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>; edk2-
> de...@lists.01.org; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> 
> To reserve the memory resource in boot phase and open them for OS phase,
> after create system resource hob, we can create memory allocation hob to take
> some range in PEI phase. Then, these ranges will not be allocated in DXE 
> phase,
> but they will still be reported in UEFI memory map. So, for this case, I 
> suggest to
> create memory hob instead of resource hob with non present memory attribute.
> 
> Thanks
> Liming
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Meenakshi Aggarwal
> > Sent: Tuesday, September 19, 2017 8:32 PM
> > To: edk2-devel@lists.01.org; leif.lindh...@linaro.org;
> > ard.biesheu...@linaro.org
> > Subject: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> >
> > While creating Hob list, ArmPlatformPkg is hiding UEFI memory.
> > whereas this memory can be used by OS.
> >
> > This patch, allows OS to use UEFI code area.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Udit Kumar <udit.ku...@nxp.com>
> > Signed-off-by: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>
> > ---
> >  ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c | 69
> > -
> >  1 file changed, 69 deletions(-)
> >
> > diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> > b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> > index 2feb11f..d03214b 100644
> > --- a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> > +++ b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> > @@ -70,11 +70,7 @@ MemoryPeim (
> >  {
> >ARM_MEMORY_REGION_DESCRIPTOR *MemoryTable;
> >EFI_RESOURCE_ATTRIBUTE_TYPE  ResourceAttributes;
> > -  UINT64   ResourceLength;
> >EFI_PEI_HOB_POINTERS NextHob;
> > -  EFI_PHYSICAL_ADDRESS FdTop;
> > -  EFI_PHYSICAL_ADDRESS SystemMemoryTop;
> > -  EFI_PHYSICAL_ADDRESS ResourceTop;
> >BOOLEAN  Found;
> >
> >// Get Virtual Memory Map from the Platform Library @@ -121,71
> > +117,6 @@ MemoryPeim (
> >  );
> >}
> >
> > -  //
> > -  // Reserved the memory space occupied by the firmware volume
> > -  //
> > -
> > -  SystemMemoryTop = (EFI_PHYSICAL_ADDRESS)PcdGet64
> > (PcdSystemMemoryBase) + (EFI_PHYSICAL_ADDRESS)PcdGet64
> > (PcdSystemMemorySize);
> > -  FdTop = (EFI_PHYSICAL_ADDRESS)PcdGet64 (PcdFdBaseAddress) +
> > (EFI_PHYSICAL_ADDRESS)PcdGet32 (PcdFdSize);
> > -
> > -  // EDK2 does not have the concept of boot firmware copied into
> > DRAM. To avoid the DXE
> > -  // core to overwrite this area we must mark the region with the
> > attribute non-present
> > -  if ((PcdGet64 (PcdFdBaseAddress) >= PcdGet64 (PcdSystemMemoryBase)) &&
> (FdTop <= SystemMemoryTop)) {
> > -Found = FALSE;
> > -
> > -// Search for System Memory Hob that contains the firmware
> > -NextHob.Raw = GetHobList ();
> > -while ((NextHob.Raw = GetNextHob
> (EFI_HOB_TYPE_RESOURCE_DESCRIPTOR, NextHob.Raw)) != NULL) {
> > -  if ((NextHob.ResourceDescriptor->ResourceType ==
> EFI_RESOURCE_SYSTEM_MEMORY) &&
> > -  (PcdGet64 (PcdFdBaseAddress) >= NextHob.ResourceDescriptor-
> >PhysicalStart) &&
> > -  (FdTop <= NextHob.ResourceDescriptor->PhysicalStart +
> NextHob.ResourceDescriptor->ResourceLength))
> > -  {
> > -ResourceAttributes = NextHob.ResourceDescriptor->ResourceAttribute;
> > -ResourceLength = NextHob.ResourceDescriptor->ResourceLength;
> > -ResourceTop = NextHob.ResourceDescriptor->PhysicalStart +
> ResourceLength;
> > -
> > -if (PcdGet64 (PcdFdBaseAddress) == NextHob.ResourceDescriptor-
> >PhysicalStart) {
> > -  if (SystemMemoryTop == FdTop) {
> > -NextHob.ResourceDescriptor->ResourceAttribute = 
> > ResourceAttributes
> & ~EFI_RESOURCE_ATTRIBU

Re: [edk2] Storing Non volatile variables on SD/NAND

[Udit Kumar]

When we want to have UEFI and OS accessing same media , 
Possibilities I see 

1- Patch OS For status check of media (diversion from generic OS), Good case 
will be modify low level driver. 
But we may end up some surprises on synchronization.
 
2- no runtime service for OS . I guess this will not be possible

3- Way the  Vladimir implemented for eMMC, This has risk of losing data in case 
of AC power off. 

4- update hardware with dual view (Ard suggestion) 

Thanks to add, if I missed some option here. 

> This use case also arises for single-board systems like raspberry-pi, which 
> do not
> have an onboard flash.
> The boot firmware/bootloader as well as operating system are loaded from SD
> card.
> https://www.raspberrypi.org/documentation/configuration/config-txt/


Raspberry follow the different boot scheme.  What I think, Linux running on 
Raspberry/ARM is unware of UEFI boot. 

Copied text 
Stage 1 boot is in the on-chip ROM. Loads Stage 2 in the L2 cache
Stage 2 is bootcode.bin. Enables SDRAM and loads Stage 3
Stage 3 is loader.bin. It knows about the .elf format and loads start.elf
Stage 4: start.elf loads kernel.img. It then also reads config.txt, cmdline.txt 
and bcm2835.dtb If the dtb file exists, it is loaded at 0×100 & kernel @ 0×8000 
If disable_commandline_tags is set it loads kernel @ 0×0 Otherwise it loads 
kernel @ 0×8000 and put ATAGS at 0×100
Stage 5: kernel.img is then run on the ARM

I think up to stage 4, we have GPU . 
Here SD is exclusivity used by UEFI or OS. Any corrections ?  
 

Thanks
Udit

> -Original Message-
> From: Pankaj Bansal
> Sent: Wednesday, September 20, 2017 8:22 PM
> To: Andrew Fish <af...@apple.com>; Udit Kumar <udit.ku...@nxp.com>; edk2-
> de...@lists.01.org
> Cc: Vladimir Olovyannikov <vladimir.olovyanni...@broadcom.com>;
> olivier.mar...@arm.com; Ard Biesheuvel <ard.biesheu...@linaro.org>
> Subject: RE: [edk2] Storing Non volatile variables on SD/NAND
> 
> This use case also arises for single-board systems like raspberry-pi, which 
> do not
> have an onboard flash.
> The boot firmware/bootloader as well as operating system are loaded from SD
> card.
> https://www.raspberrypi.org/documentation/configuration/config-txt/
> 
> Thanks & Regards,
> Pankaj Bansal
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Andrew Fish
> Sent: Wednesday, September 20, 2017 10:48 AM
> To: Udit Kumar <udit.ku...@nxp.com>
> Cc: edk2-devel@lists.01.org; Vladimir Olovyannikov
> <vladimir.olovyanni...@broadcom.com>; olivier.mar...@arm.com; Ard
> Biesheuvel <ard.biesheu...@linaro.org>
> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> 
> 
> > On Sep 19, 2017, at 10:09 PM, Udit Kumar <udit.ku...@nxp.com> wrote:
> >
> >>> On Sep 19, 2017, at 9:27 PM, Udit Kumar <udit.ku...@nxp.com> wrote:
> >>>
> >>>
> >>>> On 18 September 2017 at 22:28, Udit Kumar <udit.ku...@nxp.com>
> wrote:
> >>>>> Thanks Vladimir,
> >>>>> With your design, you did delayed write to eMMC due to sharing
> >>>>> with OS.  But it works for you:) Say if eMMC controllers offers
> >>>>> you a status bit, if eMMC storage is being used for not. Then this
> >>>>> could be possible to
> >>>> update at run time, both OS/UEFI needs to check and wait if
> >>>> controller is being used.
> >>>>
> >>>> That is the problem right there. The nice thing about a firmware
> >>>> spec is that you don't have to care about how it was implemented if
> >>>> you adhere to
> >> the API rules.
> >>>
> >>> Yup, we are fine as long as long UEFI firmware is stored on dedicated
> media.
> >>>
> >>>> Imposing additional restrictions (such as requiring the OS to be
> >>>> careful about not using the eMMC when it may be in use by the
> >>>> firmware) defeats the purpose of using UEFI, since you won't be
> >>>> able to use a
> >> generic OS anyway.
> >>>>
> >>>
> >>> Hmm,  so far, I haven't come across where UEFI specs says, we need a
> >>> separate Storage for firmware. (May be I missed some part of specs)
> >>> Irrespective of storage media, we have this problem if OS and UEFI
> >>> shares same storage.
> >>>
> >>
> >> Udit,
> >>
> >> Can you point out the spec that states you can't boot Linux and
> >> Windows at the same time on a PC? :)
> >>
> >> When you write a spec it is not practical

Re: [edk2] Storing Non volatile variables on SD/NAND

[Udit Kumar]

> > On Sep 19, 2017, at 9:27 PM, Udit Kumar <udit.ku...@nxp.com> wrote:
> >
> >
> >> On 18 September 2017 at 22:28, Udit Kumar <udit.ku...@nxp.com> wrote:
> >>> Thanks Vladimir,
> >>> With your design, you did delayed write to eMMC due to sharing with
> >>> OS.  But it works for you:) Say if eMMC controllers offers you a
> >>> status bit, if eMMC storage is being used for not. Then this could
> >>> be possible to
> >> update at run time, both OS/UEFI needs to check and wait if
> >> controller is being used.
> >>
> >> That is the problem right there. The nice thing about a firmware spec
> >> is that you don't have to care about how it was implemented if you adhere 
> >> to
> the API rules.
> >
> > Yup, we are fine as long as long UEFI firmware is stored on dedicated media.
> >
> >> Imposing additional restrictions (such as requiring the OS to be
> >> careful about not using the eMMC when it may be in use by the
> >> firmware) defeats the purpose of using UEFI, since you won't be able to 
> >> use a
> generic OS anyway.
> >>
> >
> > Hmm,  so far, I haven't come across where UEFI specs says, we need a
> > separate Storage for firmware. (May be I missed some part of specs)
> > Irrespective of storage media, we have this problem if OS and UEFI
> > shares same storage.
> >
> 
> Udit,
> 
> Can you point out the spec that states you can't boot Linux and Windows at the
> same time on a PC? :)
> 
> When you write a spec it is not practical do document what is not possible, 
> you
> can only document the API the rest is implied by the implementation. So for
> example the UEFI spec does not document why the firmware and OS can't share
> a hardware device, just like you can't have 2 operating systems running on 
> bare
> metal at the same time. It is a little like Occam's Razor the reason that the
> firmware and the OS can not share a hardware device is the mechanics of how
> to share a hardware device is not defined in the spec, thus it is not part of 
> the
> API and not possible.

Right,  This is left on implementation how to put firmware and OS.
Ideally, keeping both storage separate  is best case, no need to sync between 
two.

My reply to Ard, was to highlight that in any case (NOR or eMMC /NAND)
if we are keeping OS and firmware on same storage, we will have same 
issue not limited to  eMMC.

For some requirement, if we need to keep firmware and OS on same media, 
Then implementation should make sure there is exclusive access (be it
NOR controller, SD controller etc). 

Thanks
Udit

> Thanks,
> 
> Andrew Fish
> 
> >>> For sure,  some synchronization issues need to be ironed out (or
> >>> maybe I am
> >> just dreaming here).
> >>>
> >>> On part 2) where you forked VariableRuntime driver , could we think
> >>> of updating VariableRuntime driver, to support non-XIP or memory
> >>> mapped
> >> devices.
> >>>
> >>
> >> I think being able to support non-memorymapped FV volumes for the
> >> variable store would be a big improvement. This does require changes
> >> to both the FaultTolerantWrite drivers and the VariableRuntime
> >> drivers, which both appear in PEI, DXE and SMM flavors, and require
> >> thorough review due to the security impact bugs have in this layer, so 
> >> this is a
> rather large chunk of work to take on.
> >
> > Thanks,  your list is longer than what I was thinking :-) I think, for
> > embedded world with UEFI, later or sooner, this will be required.
> >
> > Thanks
> > Udit
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] Storing Non volatile variables on SD/NAND

[Udit Kumar]

> On 18 September 2017 at 22:28, Udit Kumar <udit.ku...@nxp.com> wrote:
> > Thanks Vladimir,
> > With your design, you did delayed write to eMMC due to sharing with
> > OS.  But it works for you:) Say if eMMC controllers offers you a
> > status bit, if eMMC storage is being used for not. Then this could be 
> > possible to
> update at run time, both OS/UEFI needs to check and wait if controller is 
> being
> used.
> 
> That is the problem right there. The nice thing about a firmware spec is that 
> you
> don't have to care about how it was implemented if you adhere to the API 
> rules.

Yup, we are fine as long as long UEFI firmware is stored on dedicated media. 

> Imposing additional restrictions (such as requiring the OS to be careful 
> about not
> using the eMMC when it may be in use by the firmware) defeats the purpose of
> using UEFI, since you won't be able to use a generic OS anyway.
> 

Hmm,  so far, I haven't come across where UEFI specs says, we need a separate
Storage for firmware. (May be I missed some part of specs)
Irrespective of storage media, we have this problem if OS and UEFI shares same  
storage. 

> > For sure,  some synchronization issues need to be ironed out (or maybe I am
> just dreaming here).
> >
> > On part 2) where you forked VariableRuntime driver , could we think of
> > updating VariableRuntime driver, to support non-XIP or memory mapped
> devices.
> >
> 
> I think being able to support non-memorymapped FV volumes for the variable
> store would be a big improvement. This does require changes to both the
> FaultTolerantWrite drivers and the VariableRuntime drivers, which both appear
> in PEI, DXE and SMM flavors, and require thorough review due to the security
> impact bugs have in this layer, so this is a rather large chunk of work to 
> take on.

Thanks,  your list is longer than what I was thinking :-)
I think, for embedded world with UEFI, later or sooner, this will be required.

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

Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux

[Udit Kumar]

Thanks for this, 

If memory is marked as reserved by HobList then gDS->AddMemorySpace will return 
 error 15. No ? 

Regards
Udit


> -Original Message-
> From: Sakar Arora [mailto:sakar.ar...@arm.com]
> Sent: Tuesday, September 19, 2017 4:51 PM
> To: Udit Kumar <udit.ku...@nxp.com>; Meenakshi Aggarwal
> <meenakshi.aggar...@nxp.com>; edk2-devel@lists.01.org;
> leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: RE: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> 
> You could use the DXE services method gDS->AddMemorySpace to add this
> memory space to the global gMemoryMap. This is the memory map linux efi
> stub reads to get information about all the available system memory.
> 
> Thanks,
> Sakar
> 
> -Original Message-
> From: Udit Kumar [mailto:udit.ku...@nxp.com]
> Sent: Tuesday, September 19, 2017 3:41 PM
> To: Sakar Arora <sakar.ar...@arm.com>; Meenakshi Aggarwal
> <meenakshi.aggar...@nxp.com>; edk2-devel@lists.01.org;
> leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: RE: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> 
> Thanks Sakar,
> I am wondering, how we can add this memory before OS,  please suggest.
> I guess, we cannot add in HobList when we are in DXE or BDS.
> 
> Regards
> Udit
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Sakar Arora
> > Sent: Tuesday, September 19, 2017 1:37 PM
> > To: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>; edk2-
> > de...@lists.01.org; leif.lindh...@linaro.org;
> > ard.biesheu...@linaro.org
> > Subject: Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> >
> > This change will create the possibility for memory space holding the
> > UEFI image to be over-written by the DXE core code, since this space
> > will then be available for allocation. Any such change, if required,
> > should be done just before booting the OS.
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Meenakshi Aggarwal
> > Sent: Tuesday, September 19, 2017 6:02 PM
> > To: edk2-devel@lists.01.org; leif.lindh...@linaro.org;
> > ard.biesheu...@linaro.org
> > Subject: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> >
> > While creating Hob list, ArmPlatformPkg is hiding UEFI memory.
> > whereas this memory can be used by OS.
> >
> > This patch, allows OS to use UEFI code area.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Udit Kumar <udit.ku...@nxp.com>
> > Signed-off-by: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>
> > ---
> >  ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c | 69
> > -
> >  1 file changed, 69 deletions(-)
> >
> > diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> > b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> > index 2feb11f..d03214b 100644
> > --- a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> > +++ b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> > @@ -70,11 +70,7 @@ MemoryPeim (
> >  {
> >ARM_MEMORY_REGION_DESCRIPTOR *MemoryTable;
> >EFI_RESOURCE_ATTRIBUTE_TYPE  ResourceAttributes;
> > -  UINT64   ResourceLength;
> >EFI_PEI_HOB_POINTERS NextHob;
> > -  EFI_PHYSICAL_ADDRESS FdTop;
> > -  EFI_PHYSICAL_ADDRESS SystemMemoryTop;
> > -  EFI_PHYSICAL_ADDRESS ResourceTop;
> >BOOLEAN  Found;
> >
> >// Get Virtual Memory Map from the Platform Library @@ -121,71
> > +117,6 @@ MemoryPeim (
> >  );
> >}
> >
> > -  //
> > -  // Reserved the memory space occupied by the firmware volume
> > -  //
> > -
> > -  SystemMemoryTop = (EFI_PHYSICAL_ADDRESS)PcdGet64
> > (PcdSystemMemoryBase) + (EFI_PHYSICAL_ADDRESS)PcdGet64
> > (PcdSystemMemorySize);
> > -  FdTop = (EFI_PHYSICAL_ADDRESS)PcdGet64 (PcdFdBaseAddress) +
> > (EFI_PHYSICAL_ADDRESS)PcdGet32 (PcdFdSize);
> > -
> > -  // EDK2 does not have the concept of boot firmware copied into
> > DRAM. To avoid the DXE
> > -  // core to overwrite this area we must mark the region with the
> > attribute non- present
> > -  if ((PcdGet64 (PcdFdBaseAddress) >= PcdGet64 (PcdSystemMemoryBase))
> > && (FdTop <= SystemMemoryTop)) {
> > -Found = FALSE;
> > -
> > -// Search for System Memory Hob that contains the firmware
> > -NextHob.Raw = GetHobList ();
&

Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux

[Udit Kumar]

Thanks Sakar, 
I am wondering, how we can add this memory before OS,  please suggest. 
I guess, we cannot add in HobList when we are in DXE or BDS.

Regards
Udit 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Sakar
> Arora
> Sent: Tuesday, September 19, 2017 1:37 PM
> To: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>; edk2-
> de...@lists.01.org; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> 
> This change will create the possibility for memory space holding the UEFI 
> image
> to be over-written by the DXE core code, since this space will then be 
> available
> for allocation. Any such change, if required, should be done just before 
> booting
> the OS.
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Meenakshi Aggarwal
> Sent: Tuesday, September 19, 2017 6:02 PM
> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org;
> ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> 
> While creating Hob list, ArmPlatformPkg is hiding UEFI memory.
> whereas this memory can be used by OS.
> 
> This patch, allows OS to use UEFI code area.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Udit Kumar <udit.ku...@nxp.com>
> Signed-off-by: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>
> ---
>  ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c | 69 
> -
>  1 file changed, 69 deletions(-)
> 
> diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> index 2feb11f..d03214b 100644
> --- a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> +++ b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> @@ -70,11 +70,7 @@ MemoryPeim (
>  {
>ARM_MEMORY_REGION_DESCRIPTOR *MemoryTable;
>EFI_RESOURCE_ATTRIBUTE_TYPE  ResourceAttributes;
> -  UINT64   ResourceLength;
>EFI_PEI_HOB_POINTERS NextHob;
> -  EFI_PHYSICAL_ADDRESS FdTop;
> -  EFI_PHYSICAL_ADDRESS SystemMemoryTop;
> -  EFI_PHYSICAL_ADDRESS ResourceTop;
>BOOLEAN  Found;
> 
>// Get Virtual Memory Map from the Platform Library @@ -121,71 +117,6 @@
> MemoryPeim (
>  );
>}
> 
> -  //
> -  // Reserved the memory space occupied by the firmware volume
> -  //
> -
> -  SystemMemoryTop = (EFI_PHYSICAL_ADDRESS)PcdGet64
> (PcdSystemMemoryBase) + (EFI_PHYSICAL_ADDRESS)PcdGet64
> (PcdSystemMemorySize);
> -  FdTop = (EFI_PHYSICAL_ADDRESS)PcdGet64 (PcdFdBaseAddress) +
> (EFI_PHYSICAL_ADDRESS)PcdGet32 (PcdFdSize);
> -
> -  // EDK2 does not have the concept of boot firmware copied into DRAM. To
> avoid the DXE
> -  // core to overwrite this area we must mark the region with the attribute 
> non-
> present
> -  if ((PcdGet64 (PcdFdBaseAddress) >= PcdGet64 (PcdSystemMemoryBase)) &&
> (FdTop <= SystemMemoryTop)) {
> -Found = FALSE;
> -
> -// Search for System Memory Hob that contains the firmware
> -NextHob.Raw = GetHobList ();
> -while ((NextHob.Raw = GetNextHob
> (EFI_HOB_TYPE_RESOURCE_DESCRIPTOR, NextHob.Raw)) != NULL) {
> -  if ((NextHob.ResourceDescriptor->ResourceType ==
> EFI_RESOURCE_SYSTEM_MEMORY) &&
> -  (PcdGet64 (PcdFdBaseAddress) >= NextHob.ResourceDescriptor-
> >PhysicalStart) &&
> -  (FdTop <= NextHob.ResourceDescriptor->PhysicalStart +
> NextHob.ResourceDescriptor->ResourceLength))
> -  {
> -ResourceAttributes = NextHob.ResourceDescriptor->ResourceAttribute;
> -ResourceLength = NextHob.ResourceDescriptor->ResourceLength;
> -ResourceTop = NextHob.ResourceDescriptor->PhysicalStart +
> ResourceLength;
> -
> -if (PcdGet64 (PcdFdBaseAddress) == NextHob.ResourceDescriptor-
> >PhysicalStart) {
> -  if (SystemMemoryTop == FdTop) {
> -NextHob.ResourceDescriptor->ResourceAttribute = 
> ResourceAttributes
> & ~EFI_RESOURCE_ATTRIBUTE_PRESENT;
> -  } else {
> -// Create the System Memory HOB for the firmware with the non-
> present attribute
> -BuildResourceDescriptorHob (EFI_RESOURCE_SYSTEM_MEMORY,
> -ResourceAttributes &
> ~EFI_RESOURCE_ATTRIBUTE_PRESENT,
> -PcdGet64 (PcdFdBaseAddress),
> -PcdGet32 (PcdFdSize));
> -
> -// Top of the FD is system memory available for UEFI
> - 

Re: [edk2] Storing Non volatile variables on SD/NAND

[Udit Kumar]

Thanks Vladimir, 
With your design, you did delayed write to eMMC due to sharing with OS.  But it 
works for you:)
Say if eMMC controllers offers you a status bit, if eMMC storage is being used 
for not. Then this 
could be possible to update at run time, both OS/UEFI needs to check and wait 
if controller is being used.
For sure,  some synchronization issues need to be ironed out (or maybe I am 
just dreaming here). 

On part 2) where you forked VariableRuntime driver , could we think of updating 
VariableRuntime driver, 
to support non-XIP or memory mapped devices. 

Thanks
Udit 

> -Original Message-
> From: Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com]
> Sent: Monday, September 18, 2017 10:22 PM
> To: Ard Biesheuvel <ard.biesheu...@linaro.org>; Udit Kumar
> <udit.ku...@nxp.com>
> Cc: grant.lik...@linaro.org; edk2-devel@lists.01.org; olivier.mar...@arm.com
> Subject: RE: [edk2] Storing Non volatile variables on SD/NAND
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Ard Biesheuvel
> > Sent: Monday, September 18, 2017 8:43 AM
> > To: Udit Kumar
> > Cc: grant.lik...@linaro.org.; edk2-devel@lists.01.org;
> > olivier.mar...@arm.com
> > Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> >
> > On 18 September 2017 at 06:52, Udit Kumar <udit.ku...@nxp.com> wrote:
> > > Hi EDK-2 Experts,
> > > I am looking to store NV variables on SD/NAND device.
> > >
> > > While browsing, I came across some old post at link,
> > > http://feishare.com/efimail/messages/20130319-1700-
> > Re__edk2__Regarding
> > > _storing_Boot_Device_Config_in_persistent_memory-Olivier_Martin.html
> > >
> > > Looks like, this is possible easily.
> >
> > That's a bold statement dude :-)
> >
> > >>> What you need to support Non-Volatile UEFI variables is a
> Non-Volatile
> > Memory. And also a driver that implements the EFI Firmware Volume
> > Block protocol for this NVM device.
> > >
> > > But MdeModulePkg does Copymem from NV variable start memory to
> > some
> > > allocated buffers.  With SD/NAND Copymem is not possible, Is this
> > > something changes since 2013 or there are some other way to use
> > > SD/NAND
> > >
> >
> > No, SD/MMC cannot currently be used as the backing store for the EFI
> > variable store. The problem is that the variable protocols are
> architectural
> > protocols in PI that need to be present before any driver model
> > drivers
> are
> > dispatched, and so putting the variable store on block devices is not
> > something that the PI software architecture currently supports (unless
> you
> > reimplement the whole driver stack as DXE drivers).
> >
> > On top of that, it is almost impossible to share a block device that
> sits behind
> > a controller between the firmware and the OS at runtime (i.e., for
> > SetVariable() calls made by efibootmgr under Linux), because only a
> single
> > agent can take ownership of the controller at any given time. (You
> /could/
> > dedicate the SD/MMC to the firmware entirely, and boot from SATA or
> > USB, but this is out of the question on most platforms that need to
> > use
> SD/MMC
> > for that variable backing store, i.e., mobile platforms)
> >
> > The best thing would be for you to convince the hardware architects in
> your
> > company to design and implement dual-ported SD/MMC controllers that
> > allow a single SD/MMC to have two logical views that are independent
> > (although I'm unsure if that is even possible in the context of the
> SD/MMC
> > specifications)
> >
> > Thanks,
> > Ard.
> Udit,
> Ard is absolutely right.
> 
> Following design I had to implement variable store on the EMMC boot partition
> 1 (not exactly SD card, but close; the same is applied to NAND I guess).
> To do that I forked VariableRuntime driver and changed it to do cache writes
> into the store (just modifying store memory) at runtime.
> This is because you cannot share eMMC store between OS (Linux)  and the UEFI
> service at the same time, and you cannot predict when OS writes/reads to/from
> the EMMC device.
> So I do cache writes at runtime (just modifying store in memory), and flush 
> the
> store on reboot/shutdown.
> For this purpose my ResetSystemLib calls into the Variable service and forces
> flush. Variable service reinitiates eMMC controller and really writes into the
> store on the eMMC. Real flush is also performed on ExitBootServices().
> 
> As a big drawback an 

Re: [edk2] Storing Non volatile variables on SD/NAND

[Udit Kumar]

Thanks Ard / Jeremy. 

Say SD/NAND is just used for UEFI firmware then this is something doable. 

> > Having the firmware/variable store and OS root/boot on the same device
> > is fundamentally flawed.

I agree in case of SD/NAND, partitioning and synchronization with OS will be 
tough task. 
Even in case of NOR flash, if this is exposed as mtd device as well, then 
accessing from 
OS and UEFI poses same challenge .

Thanks
Udit

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, September 19, 2017 2:23 AM
> To: Jeremy Linton <jeremy.lin...@arm.com>
> Cc: Udit Kumar <udit.ku...@nxp.com>; grant.lik...@linaro.org.
> <grant.lik...@linaro.org>; edk2-devel@lists.01.org; olivier.mar...@arm.com
> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> 
> On 18 September 2017 at 13:47, Jeremy Linton <jeremy.lin...@arm.com>
> wrote:
> > On 09/18/2017 10:43 AM, Ard Biesheuvel wrote:
> >>
> >> On 18 September 2017 at 06:52, Udit Kumar <udit.ku...@nxp.com> wrote:
> >>>
> >>> Hi EDK-2 Experts,
> >>> I am looking to store NV variables on SD/NAND device.
> >>>
> >>> While browsing, I came across some old post at link,
> >>>
> >>> http://feishare.com/efimail/messages/20130319-1700-Re__edk2__Regardi
> >>> ng_storing_Boot_Device_Config_in_persistent_memory-Olivier_Martin.ht
> >>> ml
> >>>
> >>> Looks like, this is possible easily.
> >>
> >>
> >> That's a bold statement dude :-)
> >>
> >>>>> What you need to support Non-Volatile UEFI variables is a
> >>>>> Non-Volatile Memory. And also a driver that implements the EFI
> >>>>> Firmware Volume Block protocol for this NVM device.
> >>>
> >>>
> >>> But MdeModulePkg does Copymem from NV variable start memory to some
> >>> allocated buffers.  With SD/NAND Copymem is not possible, Is this
> >>> something changes since 2013 or there are some other way to use
> >>> SD/NAND
> >>>
> >>
> >> No, SD/MMC cannot currently be used as the backing store for the EFI
> >> variable store. The problem is that the variable protocols are
> >> architectural protocols in PI that need to be present before any
> >> driver model drivers are dispatched, and so putting the variable
> >> store on block devices is not something that the PI software
> >> architecture currently supports (unless you reimplement the whole
> >> driver stack as DXE drivers).
> >>
> >> On top of that, it is almost impossible to share a block device that
> >> sits behind a controller between the firmware and the OS at runtime
> >> (i.e., for SetVariable() calls made by efibootmgr under Linux),
> >> because only a single agent can take ownership of the controller at
> >> any given time. (You /could/ dedicate the SD/MMC to the firmware
> >> entirely, and boot from SATA or USB, but this is out of the question
> >> on most platforms that need to use SD/MMC for that variable backing
> >> store, i.e., mobile platforms)
> >>
> >> The best thing would be for you to convince the hardware architects
> >> in your company to design and implement dual-ported SD/MMC
> >> controllers that allow a single SD/MMC to have two logical views that
> >> are independent (although I'm unsure if that is even possible in the
> >> context of the SD/MMC specifications)
> >
> >
> > Which still has the problems of selecting "use whole disk" during an
> > OS install bricking the machine. Or similarly if the emmc layout isn't
> > just right having gparted automatically "fix" the partition table (as
> > it does with many of the hikey images) again bricking the machine.
> >
> > Having the firmware/variable store and OS root/boot on the same device
> > is fundamentally flawed. I've went down the path of simply disabling
> > the hikey/emmc for use beyond the firmware/variable storage on the
> > hikey. Of course I ran smack into the problem of making the block
> > device DXE's run-time safe which I've about concluded is far harder
> > than simply writing a monolithic variablestore->emmc driver.
> >
> > The ideal situation for the Hikey, is probably to solder a SPI flash
> > to the SPI controller and put the firmware/variable store on that, and
> > leave the eMMC entirely for linux's use.
> >
> 
> Oh, I completely agree that HiKey is a trainwreck in this regard. I asked for 
> a
> 96boards mezzanine board with a SPI NOR more than 2 years ago so we could
> prototype this stuff properly, but it never materialized.
> 
> But eMMC *can* potentially be used in a meaningful way, if we use a MMC boot
> partition for the UEFI image and the RPMB partition for the variable store 
> (which
> would arguably be the only way to get a truly tamper proof *and* rollback
> protected varstore, which is what you minimally need to implement UEFI secure
> boot)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Storing Non volatile variables on SD/NAND

[Udit Kumar]

Hi EDK-2 Experts, 
I am looking to store NV variables on SD/NAND device. 

While browsing, I came across some old post at link, 
http://feishare.com/efimail/messages/20130319-1700-Re__edk2__Regarding_storing_Boot_Device_Config_in_persistent_memory-Olivier_Martin.html
 

Looks like, this is possible easily. 
>> What you need to support Non-Volatile UEFI variables is a Non-Volatile 
>> Memory. And also a driver that implements the EFI Firmware Volume Block 
>> protocol for this NVM device.

But MdeModulePkg does Copymem from NV variable start memory to some allocated 
buffers.  With SD/NAND Copymem is not possible, Is this something changes since 
2013 or there are some other way to use SD/NAND 

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