Andrew,
Can't we think of UEFI as being preemptive and threaded; the event handlers
are like threads. Certainly we are missing some infrastructure for
thread-like constructs, but I am just curious about what you mean when you
say "signal based and not threaded."
-chip
On Thu, May 16, 2013 at 11:08 AM, Andrew Fish <af...@apple.com> wrote:
>
>
> On May 16, 2013, at 10:50 AM, Tim Lewis <tim.le...@insyde.com> wrote:
>
> > Stephen --
> >
> > No, on most UEFI implementations timer is running and, in the shell,
> polling-related events are happening all the time (to check for
> input-related device status change)
> >
> > Could the DXE core do on-demand only? Probably, but that is not the
> current EDK2 implementation, as far as I understand it.
> >
>
> Tim you are correct. The CoreTimerTick() function in the DXE gets called
> at the default period set by the Timer Architectural Protocol. The
> CoreTimerTick() checks the internal queues and decides if an EFI based
> timer event needs to be signaled. The timer tick starts when the Timer
> Architectural protocol driver is loaded, and the code I pointed to was an
> event handler for the installation of architectural protocols by a driver
> in the DXE Core. By definition all the PI architectural protocol drivers
> must be loaded prior to running any EFI driver/application since they are
> needed to make all the EFI services work. This is why no dependency
> expression in a drivers INF file means depend on all architectural
> protocols and does not imply a depex of TRUE.
>
> Given drivers like USB and networking always use the timer tick, even if
> an optimization was made to "adjust the period" based on need ticks would
> still be happening.
>
> Since EFI is signal based and not threaded, you are either in the main
> thread (running a driver or applications entry point) or a signaled event.
> Thus if you are in the CoreTimerTick() and no event is called that time
> conceptually is waisted (you could have been doing work on the main
> thread). I guess some one could profile how much time in the boot is spent
> in a CoreTimerTick() where no work is done and that is the best case how
> much boot time your could get back from reprogramming the timer tick to the
> next needed value. There will be some amount of book keeping required to
> calculate these values to program into the timer.
>
> Thanks,
>
> Andrew Fish
>
> > Tim
> >
> > -----Original Message-----
> > From: Stephen Polkowski [mailto:step...@centtech.com]
> > Sent: Thursday, May 16, 2013 10:31 AM
> > To: edk2-devel@lists.sourceforge.net
> > Subject: Re: [edk2] how timer and interrupt works in UEFI？
> >
> >
> > Hi Andrew,
> >
> > Thanks for answering this question. I was curious about
> interrupts as well. If I understand you correctly, a timer exists and it
> is only used when a driver or a program requests it.
> >
> > So, when we come up in a basic UEFI Shell the system is
> essentially tickless?
> >
> > Thanks,
> >
> > Stephen
> >
> >
> > Andrew Fish wrote:
> >>
> >> On May 16, 2013, at 7:16 AM, "zzhh.happy" <zzhh.ha...@163.com
> >> <mailto:zzhh.ha...@163.com>> wrote:
> >>
> >>> Hi all,
> >>>
> >>> I'm fresh man for studying UEFI,and there are some questions ,is
> >>> there anyone can help,thanks!
> >>> as we know there is only on interrupt that is the timer,it works as
> >>> the heartbeat timer.but in X86 platform i can't find the timer
> >>> interrupt handle function. except bellow service *CoreTimerTick,*but
> >>> there is a input parameter *Duration,*never heard that interrupt
> >>> service have input parameter,if yes, who pass it in?
> >>> and there are my question:
> >>>
> >> UEFI does not define how the timer works, just that it exists. The
> >> UEFI Platform Initialization Specification 1.2.1
> >> <http://www.uefi.org/specs/platform_agreement> (also called PI spec)
> >> defines how the timer works in the edk2 http://www.uefi.org/specs/.
> >>
> >> The PI defines a set of Architectural Protocol that produce the
> >> hardware services needed to produce the EFI services. If you look in
> >> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/
> >> Core/Dxe/DxeMain/DxeProtocolNotify.c
> >> you will see the mArchProtocols array that contains a list of these
> >> architectural protocols, and some globals that filled in when the
> >> protocols are registered.
> >>
> >> So basically the CPU AP, gEfiCpuArchProtocolGuid, abstracts interrupt
> >> handling in a processor agnostic way (Same DXE Core source works for
> >> Itainum, IA32, X64, and ARM). The Timer AP, gEfiTimerArchProtocolGuid,
> >> depends on the CPU AP and produces the timer tick for the platform.
> >>> 1.in x86 platform what is the heartbeat,is it the leagcy 8254?
> >> It can be any timer. It is what ever Timer AP driver gets included in
> >> the firmware. Search for drivers installing gEfiTimerArchProtocolGuid.
> >>> 2.what is the interrupt vector number?
> >> There is not a standard. It is platform specific and set by the driver.
> >> Some drivers may offer a PCD config setting to change the vector.
> >>> 3.where is the IDT table exist in memery after the timer start
> >>> ticking
> >> The CPU AP driver sets up the IDT. For X64/IA32 the IDT is not at a
> >> fixed address. Search for a driver installing gEfiCpuArchProtocolGuid.
> >> Note: There is an assemble instruction that lets you know the address,
> >> but it is probably a very bad idea to patch anything into the table
> >> directly as debuggers need to cooperate with the CPU AP to hook
> >> vectors, so you may break the debugger or the CPU AP. You can use
> >> gEfiCpuArchProtocolGuid services to hook an interrupt vector if that
> >> is what you need to do.
> >> There are C functions that implement common assembly instruction in
> >> the BaseLib. So AsmReadIdtr().
> >>> 4.what is the heartbeat service handle,and how it registered to the
> >>> cpu's interrupt verctor table.
> >> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/
> >> Core/Dxe/DxeMain/DxeProtocolNotify.c
> >>
> >> When the Timer AP service is registered the DXE Core does:
> >>
> >> gTimer->RegisterHandler (gTimer, CoreTimerTick);
> >>
> >> Which registers the DXE Cores timer callback.
> >>
> >> This is an example gEfiCpuArchProtocolGuid driver:
> >> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/UefiCpuPkg/Cp
> >> uDxe/ This is not the driver you would find on a real platform as
> >> there is a large amount of processor specific initialization that is
> >> required, but it shows the general concepts.
> >>
> >> Thanks,
> >>
> >> Andrew Fish
> >>>
> >>> thanks very much.
> >>>
> >>>
> >>> VOID
> >>> EFIAPI
> >>> *CoreTimerTick* (
> >>> IN UINT64 Duration
> >>> )
> >>> /*++
> >>> Routine Description:
> >>> Called by the platform code to process a tick.
> >>> Arguments: Duration - The number of 100ns elasped since the last
> >>> call to TimerTick
> >>> Returns: None
> >>> --*/
> >>> {
> >>> IEVENT *Event;
> >>> // Check runtiem flag in case there are ticks while exiting boot
> >>> services
> >>> CoreAcquireLock (&mEfiSystemTimeLock);
> >>> // Update the system time
> >>> mEfiSystemTime += Duration;
> >>> // If the head of the list is expired, fire the timer event
> >>> // to process it
> >>> if (!IsListEmpty (&mEfiTimerList)) {
> >>> Event = CR (mEfiTimerList.ForwardLink, IEVENT, u.Timer.Link,
> >>> EVENT_SIGNATURE);
> >>> if (Event->u.Timer.TriggerTime <= mEfiSystemTime) {
> >>> CoreSignalEvent (mEfiCheckTimerEvent);
> >>> }
> >>> }
> >>> CoreReleaseLock (&mEfiSystemTimeLock); }
> >>> 2013-05-16
> >>> ---------------------------------------------------------------------
> >>> ---
> >>> zzhh.happy
> >>> ---------------------------------------------------------------------
> >>> --------- AlienVault Unified Security Management (USM) platform
> >>> delivers complete security visibility with the essential security
> >>> capabilities. Easily and efficiently configure, manage, and operate
> >>> all of your security controls from a single console and one unified
> >>> framework. Download a free trial.
> >>> http://p.sf.net/sfu/alienvault_d2d___________________________________
> >>> ____________
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.sourceforge.net
> >>> <mailto:edk2-devel@lists.sourceforge.net>
> >>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
> >>
> >>
> >> ----------------------------------------------------------------------
> >> --
> >>
> >> ----------------------------------------------------------------------
> >> -------- AlienVault Unified Security Management (USM) platform
> >> delivers complete security visibility with the essential security
> >> capabilities. Easily and efficiently configure, manage, and operate
> >> all of your security controls from a single console and one unified
> >> framework. Download a free trial.
> >> http://p.sf.net/sfu/alienvault_d2d
> >>
> >>
> >> ----------------------------------------------------------------------
> >> --
> >>
> >> _______________________________________________
> >> edk2-devel mailing list
> >> edk2-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/edk2-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> > http://p.sf.net/sfu/alienvault_d2d
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
> >
> >
> ------------------------------------------------------------------------------
> > AlienVault Unified Security Management (USM) platform delivers complete
> > security visibility with the essential security capabilities. Easily and
> > efficiently configure, manage, and operate all of your security controls
> > from a single console and one unified framework. Download a free trial.
> > http://p.sf.net/sfu/alienvault_d2d
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
