Key Learnings from EFI Framework Shipping Project

  • 967 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
967
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
12
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 1. Itanium® Architecture Requires EFI Aware OS 2. Same Code Worked for both x86 and Itanium® Systems 3. Driver Architecture 4. Conformance to modular components is continuously improving; UEFI and FFSA (Firmware Foundation Specification Alliance) 5. Driver model enables value-added components to be moved platform-to- platform 6. Higher-level drivers and apps MUCH better than BIOS . C-code debug output to Serial Console is easier and more familiar 7. First project with multiple BIOS resources. This can only be achieved with True Modularity 8. Educated engineering pool available

Transcript

  • 1. Key Learnings from EFI Framework Shipping Project Daniel Lin Marketing Director Genius Huang Senior Engineer Insyde Software PFIS003
  • 2. Agenda
    • Why EFI Framework from OEM’s viewpoints
    • Major differences in debugging methods between Framework and Legacy BIOS.
    • The power of using the Framework to speed up firmware development for your new platforms. 
    • How NVRAM variables are used in the Framework and the advantages over CMOS.
    • Reduce your engineering effort by leveraging legacy BIOS experience while using the Framework
  • 3. Agenda
    • Why EFI Framework from OEM’s viewpoint
    • Major differences in debugging methods between Framework and Legacy BIOS.
    • The power of using the Framework to speed up firmware development for your new platforms. 
    • How NVRAM variables are used in the Framework and the advantages over CMOS.
    • Reduce your engineering effort by leveraging legacy BIOS experience while using the Framework
  • 4. Why EFI Framework from OEM’s viewpoint
    • Multiple hardware's support
      • Dual core CPU, 64 bit CPU
    • New Features
      • VT, LT and xxT.
    • Time-To-Market
      • Easy to add and remove features
      • Easy to Reuse Code on future platforms
      • High Code Quality
      • Good Development and Debug Environment
      • Ability to Carve up the project and Outsource
      • Fast Engineering Learning Curve
  • 5. Framework is technical trend for OEM/ODM
    • “ C” Code
    • Code Reuse
    • Driver Model
    • Pre-boot Environment built-in
    • Networking built in (eg: PXE Boot)
    • Backward compatible with legacy BIOS
    legacy OS Loader Hardware Pre-EFI Modules UEFI PEI Foundation Foundation Compatibility Support Module EFI OS Loader Framework Drivers EFI Drivers legacy Option ROMs Driver Execution Environment Architectural Protocols Platform Drivers
  • 6. Viewpoints from a sever maker “Egenera”
    • OS EFI Requirement
    • New Features
    • Easy to add and remove features
    • Easy to Reuse Code on future platforms
    • High Code Quality
    • Good Development and Debug Environment
    • Ability to Carve up the project and Outsource
    • Fast Engineering Learning Curve
  • 7. Agenda
    • Why EFI framework from OEM’s viewpoint
    • Major differences in debugging methods between Framework and Legacy BIOS.
    • The power of using the Framework to speed up firmware development for your new platforms. 
    • How NVRAM variables are used in the Framework and the advantages over CMOS.
    • Reduce your engineering effort by leveraging legacy BIOS experience while using the Framework
  • 8. Debugging in legacy BIOS
    • Port 80 is traditional method for the BIOS debug
    • Port 80 with digits output only
    • Forces engineers to guess on execution location
    • Any advance debugging requires special design, additional software efforts or additional hardware.
  • 9. EFI Framework provides a powerful way of debugging
    • Built-in debugging mechanism
    • Debug messages output through serial port
    • Debug messages can be defined easily as detail as you need.
    • Any digits or wording can be transferred to the debug console without any additional programming efforts.
    • Symbolic debug message is supported.
  • 10. Insyde debug tools
    • Debug even before memory sizing
    • Set breakpoints in C language, showing converted disassembly codes simultaneously
    • Pure software tool connected thru standard USB 2.0, parallel port
    • Update flash ROM thru debugger tool
    Early state debug support, Source codes level debug, Cost saving and easy to use Host Target USB2.0 LPT USB2.0 LPT H2ODDT Hyper terminal USB /LPT cable/COM
  • 11. Using debug messages in code is the same as “printf”
    • Example of how to code output debug message in PEI and DXE phase
      • PEI phase
        • PEI_DEBUG ((PeiServices, EFI_D_INFO,”Messages”))
      • DXE/BDS phase
        • DEBUG ((EFI_D_ERROR,”Messages”))
  • 12. Easy to understand debug messages
  • 13. What is the way of debugging for EFI Framework?
    • Rich debugging messages
      • Register value
        • MEM,I/O and CPU
      • Data structure variable
      • Full name procedure
      • Comments
  • 14. Various debug tools for EFI Framework development
    • Hardware Debugging
      • American Arium
    • EFI Shell
      • Command Line Tools
    • Debug flags
      • Thru Hyper terminal to show the debug messages
    • DOS utilities
      • DEBUG.EXE
      • E820.EXE
      • DMITOOL.EXE
      • PCICHK.EXE & PCIDUMP.EXE
  • 15. Agenda
    • Why EFI framework from OEM’s viewpoint
    • Major differences in debugging methods between Framework and Legacy BIOS.
    • The power of using the Framework to speed up firmware development for your new platforms. 
    • How NVRAM variables are used in the Framework and the advantages over CMOS.
    • Reduce your engineering effort by leveraging legacy BIOS experience while using the Framework
  • 16. The power of using the Framework to speed up firmware development for your new platforms. 
    • Modular code structure
      • Exchangeable CPU drivers. Dothan vs. Yonah
    • Highly reusable modules/drivers
      • OEM features reusable
    • EFI Framework tolerates failure components with event log to record the debug messages
  • 17. Quick bring up works with EFI Framework
    • Create your own project folder
      • For your specific project
    • Customize GPIO value
      • based on the schematics
    • Customize PCI routing table
      • To assign correct resource for your project
    • Uses EMUVariable driver
      • To use RAM as Flash during bring-up stage
      • To save time before flash driver ready
    Highly utilizing CRB platform source codes
  • 18. Agenda
    • Why EFI framework from OEM’s viewpoint
    • Major differences in debugging methods between Framework and Legacy BIOS.
    • The power of using the Framework to speed up firmware development for your new platforms. 
    • How NVRAM variables are used in the Framework and the advantages over CMOS.
    • Reduce your engineering effort by leveraging legacy BIOS experience while using the Framework
  • 19. Contents of Flash part for EFI Framework
    • SEC,PEI and DXE (firmware volumes)
      • SEC initializes cache as RAM
      • Modules initial codes will be put into PEI phase
      • Device drivers will be put into DXE phase
    • EC ROM
      • Normally we will treat ECROM as an individual firmware volume
    • Option ROM /PXE
      • Put them into DXE firmware volume
    • CMOS replacement
      • NVRAM Non Volatile RAM
      • Variable storage
  • 20.
    • A Firmware Volume is a logical container.
    • A flash part may store one or more logical containers.
    • The files which are contained in a firmware volume must be accessed in:
      • Security (SEC) phase or
      • Pre-EFI Initialization (PEI) phase or
      • Driver Execution Environment (DXE) phase.
    What is a Firmware Volume?
  • 21. Rationale of Firmware Volume
    • Firmware Volume Architecture
    Firmware Volume Driver Firmware Volume Block Driver Firmware Storage Device Low Level Interface File Level Interface FvbService Flash Memory Device
  • 22. POST/ RunTime Code Boot Block DXE Phase Variable Storage SEC/PEI Phase VS. Firmware Volume Legacy BIOS H2O Firmware Volume Firmware Volume Flash Rom Map – Comparison between Legacy BIOS and EFI Framework
  • 23. The advantages of using Variable Storage
    • Flexible Variable Storage location in flash device
    • CMOS replacement
    • All variables can be defined with any data types such as byte, words, any string length depends on the variable storage total size.
    • Variables defragment- Two Variable Storage areas for Variable defragment and recovery.
  • 24. Variable Storage process flow diagram NVRAM 0 NVRAM 1 System Boot Store MEM to NVRAM1 and NVRAM 0 after process Defragment Memory NVRAM 0 Full Copy Failed to boot NVRAM 0 NVRAM 1 Memory Copy System Boot
  • 25. How to modify your Flash Rom Map of EFI for a Mobile case DXE Phase NVRAM / CPU micro code SEC/PEI Phase DXE Phase NVRAM/ CPU micro code SEC/PEI Phase EC Rom
  • 26. Agenda
    • Why EFI framework from OEM’s viewpoint
    • Major differences in debugging methods between Framework and Legacy BIOS.
    • The power of using the Framework to speed up firmware development for your new platforms. 
    • How NVRAM variables are used in the Framework and the advantages over CMOS.
    • Reduce your engineering effort by leveraging legacy BIOS experience while using the Framework
  • 27. Reduce your engineering effort by leveraging legacy BIOS experience while using the Framework
    • To reuse OEM drivers which were used in previous projects
    • Any drivers can be packaged as binary files since all implementations are using driver model.
    • Simultaneous co-development model- Different projects can be shared with the same feature in binary file format without source codes doing the re-compile.
  • 28. Example: How to add /remove an Application or drivers with simple way # # Drivers necessary to use the debugger # These are placed here so they will load early if they are desired. # NOTE: # Including these in the FV will take over use of the COM port. # EdkSampleUniversalDebuggerDebugportDxeDebugPort.inf FV=NULL EdkSampleCpuDebugSupportDxeDebugSupport.inf FV=NULL # # Following are the DXE drivers (alphabetical order) # BusIsaIsaBusDxeIsaBus.inf BusIsaIsaFloppyDxeIsaFloppy.inf $(SHELL_INF)Shell.inf # $(SHELL_INF)Shell.inf
  • 29. Life demo for a debug demonstration
    • Debug tool to show how Framework works with first initial PEI codes before memory sizing
    • Debug tool to show modules loading sequence
    • To show how to trace the source EFI Framework with Debug tools
  • 30. Summary
    • Time to Market
      • Various platform supports with unified EFI Framework is very beneficial for customers
    • Easy for debugging
      • EFI Framework embedded powerful debugging mechanism
    • Easy for development
      • Modularity provides flexibility for parallel developments
    • Reusable engineering efforts
      • New features for reuse for different platforms
  • 31. Additional EFI /Framework Sessions 16:50 - 17:40 Phoenix PFIS004 Implementing the PEI and DXE Within Phoenix TrustedCore* Oct. 28 Oct. 27 Date Done Insyde PFIS003 Key Learnings from EFI Framework Shipping Project Done AMI PFIS002 Implementing Manageable Server Platforms using EFI & The Framework 11:45 - 12:25 HP PSSS006 Implementing the Framework on non-Intel Chipsets Done Intel, HP PFIS001 “ Unified EFI” Industry Group introduction and the Firmware Bridge to the Intel ® EM64T and Microsoft Vista* Time Company ID Session
  • 32. Additional Resources for this Session
    • Complete US IDF presentation can be downloaded from the IDF web site – when prompted enter:
        • Username: idf
        • Password: fall2005
    • More web based info:
    • http://www.uefi.org
    • http://www.intel.com/technology/framework
    • http://www.intel.com/technology/efi
    • http://www.tianocore.org
  • 33. Please fill out the Session Evaluation Form. Thank You!
  • 34. Backup Slides
  • 35. Q&A
  • 36. Demonstration procedure-1
    • Hardware configuration
      • Host machine
      • Target Machine
      • Insyde USB cable
      • Serial port cable
    • Software configuration
      • Hyper terminal
      • H2ODDT
      • Insyde USB driver
  • 37. Demonstration scenario-I
    • Remove RAM from RAM slot
    • Show two windows for Hyper terminal and Insyde H2ODDT
    • Show break two break points when memory sizing–PEI memory init and error handle procedure
    • We also Show No memory detected at Hyper terminal side when detected no memory in RAM slot
    • Show source codes at DDT side- MC detect memory
    • Show the exact source code line when it hangs on both hyper terminal and DDT
  • 38. Demonstration scenario- II
    • Install RAM into RAM slot
    • Show the memory init without stop
    • Show the drivers loading sequence via command line window
  • 39. Demonstration scenario- III
    • Show host bridge bus0/device 1f /function 0
    • Show the platform driver how to modify PCI register values-
      • show the original register values-
      • Show platform driver is modifying a GPI rout register
      • Then we can see the change from PCI register dump windows
    • PCI E registers dump