├── .bookignore ├── .github └── workflows │ └── gitbook-action.yml ├── .gitignore ├── 10_uefi_service_binding_protocol ├── 101_service_binding_protocol_implementations.md ├── 102_service_driver.md ├── 103_uefi_driver_model_driver.md └── README.md ├── 11_uefi_driver_and_controller_names ├── 111_component_name_protocol_implementations.md ├── 112_getdrivername_implementations.md ├── 113_getcontrollername_implementations │ ├── 1131_device_drivers.md │ ├── 1132_bus_drivers_and_hybrid_drivers.md │ └── README.md ├── 114_testing_component_name_protocols.md └── README.md ├── 12_uefi_driver_configuration ├── 121_hii_overview │ ├── 1211_hii_database_and_package_lists.md │ └── README.md ├── 122_general_steps_for_implementing_hii_functionali.md ├── 123_hii_protocols │ ├── 1231_hii_database_protocol_and_hii_string_protocol.md │ ├── 1232_hii_config_routing_protocol.md │ ├── 1233_hii_config_access_protocol.md │ ├── 1234_rarely_used_hii_protocols.md │ └── README.3.md ├── 124_hii_functionality │ ├── 1241_branding,_and_displaying_a_banner.md │ ├── 1242_specifying_supported_languages.md │ ├── 1243_specifying_configuration_information.md │ ├── 1244_making_configuration_data_available_to_other_.md │ ├── 1245_check_to_see_if_configuration_parameters_are_.md │ └── README.4.md ├── 125_forms_and_vfr_files.md ├── 126_hii_implementation_recommendations │ ├── 1261_minimize_callbacks.md │ ├── 1262_dont_reparse_the_package_list.md │ ├── 1263_concentrate_on_critical_aspects_of_the_driver.md │ ├── 1264_perform_usability_testing.md │ └── README.6.md ├── 127_porting_to_uefi_hii_functionality.md └── README.md ├── 13_uefi_driver_diagnostics ├── 131_driver_diagnostics_protocol_implementations.md ├── 132_rundiagnostics_implementations │ ├── 1321_device_drivers.md │ ├── 1322_bus_drivers_and_hybrid_drivers.md │ ├── 1323_rundiagnostics_as_a_uefi_application.md │ └── README.md ├── 133_testing_driver_diagnostics_protocols.md └── README.md ├── 14_driver_health_protocol ├── 141_driver_health_protocol_implementation.md ├── 142_gethealthstatus_implementations │ ├── 1421_device_drivers.md │ ├── 1422_bus_drivers_and_hybrid_drivers.md │ └── README.md ├── 143_repair_implementation │ ├── 1431_device_drivers.md │ ├── 1432_bus_drivers_and_hybrid_drivers.md │ └── README.3.md └── README.md ├── 15_driver_family_override_protocol ├── 151_driver_family_override_protocol_implementation.md ├── 152_getversion_implementation.md └── README.md ├── 16_driver_supported_efi_version_protocol ├── 161_driver_supported_efi_version_protocol_implemen.md └── README.md ├── 17_bus-specific_driver_override_protocol ├── 171_bus_specific_driver_override_protocol_implemen.md ├── 172_private_context_data_structure.md ├── 173_bus_specific_driver_override_protocol_installa.md ├── 174_getdriver_implementation.md ├── 175_adding_driver_image_handles.md └── README.md ├── 18_pci_driver_design_guidelines ├── 181_pci_root_bridge_io_protocol_drivers.md ├── 182_pci_bus_drivers │ ├── 1821_hot-plug_pci_buses.md │ └── README.md ├── 183_pci_drivers │ ├── 1831_supported.md │ ├── 1832_start_and_stop.md │ ├── 1833_pci_cards_with_multiple_pci_controllers.md │ └── README.3.md ├── 184_accessing_pci_resources │ ├── 1841_memory-mapped_io_ordering_issues.md │ ├── 1842_hardfailsoftfail.md │ ├── 1843_when_a_pci_device_does_not_receive_resources.md │ └── README.4.md ├── 185_pci_dma │ ├── 1851_map_service_cautions.md │ ├── 1852_weakly_ordered_memory_transactions.md │ ├── 1853_bus_master_read_and_write_operations.md │ ├── 1854_bus_master_common_buffer_operations.md │ ├── 1855_gb_memory_boundary.txt │ ├── 1856_dma_bus_master_read_operation.md │ ├── 1857_dma_bus_master_write_operation.md │ ├── 1858_dma_bus_master_common_buffer_operation.md │ └── README.5.md ├── 186_pci_optimization_techniques │ ├── 1861_pci_io_fill_operations.md │ ├── 1862_pci_io_fifo_operations.md │ ├── 1863_pci_io_copymem_operations.md │ ├── 1864_pci_configuration_header_operations.md │ ├── 1865_pci_io_mmio_buffer_operations.md │ ├── 1866_pci_io_polling_operations.md │ └── README.6.md ├── 187_pci_option_rom_images │ ├── 1871_efirom_utility.md │ ├── 1872_using_inf_file_to_generate_pci_option_rom_ima.md │ ├── 1873_using_fdf_file_to_generate_pci_option_rom_ima.md │ └── README.7.md └── README.md ├── 19_usb_driver_design_guidelines ├── 191_usb_host_controller_driver │ ├── 1911_driver_binding_protocol_supported.md │ ├── 1912_driver_binding_protocol_start.md │ ├── 1913_driver_binding_protocol_stop.md │ ├── 1914_usb_2_host_controller_protocol_data_transfer_.md │ └── README.md ├── 192_usb_bus_driver.md ├── 193_usb_device_driver │ ├── 1931_driver_binding_protocol_supported.md │ ├── 1932_driver_binding_protocol_start_and_stop.md │ ├── 1933_io_protocol_implementations.md │ ├── 1934_state_machine_consideration.md │ └── README.3.md ├── 194_debug_techniques │ ├── 1941_debug_message_output.md │ ├── 1942_usb_bus_analyzer.md │ ├── 1943_usbcheckusbcv_tool.md │ └── README.4.md ├── 195_nonconforming_usb_devices.md └── README.md ├── 1_introduction ├── 11_overview │ ├── 111_assumptions.md │ └── README.md ├── 12_organization_of_this_document.md ├── 13_related_information │ ├── 131_uefi_specifications.md │ ├── 132_industry_standard_bus_specifications.md │ ├── 133_other_specifications.md │ ├── 134_edk_ii_and_udk2010_development_kit.md │ └── README.3.md ├── 14_typographic_conventions.md └── README.md ├── 20_scsi_driver_design_guidelines ├── 201_scsi_host_controller_driver │ ├── 2011_single-channel_scsi_adapters.md │ ├── 2012_multi-channel_scsi_adapters.md │ ├── 2013_scsi_adapters_with_raid.md │ ├── 2014_implementing_driver_binding_protocol.md │ ├── 2015_implementing_extended_scsi_pass_thru_protocol.md │ ├── 2016_scsi_command_set_device_considerations.md │ ├── 2017_discover_a_scsi_channel.md │ ├── 2018_scsi_device_path.md │ └── README.md ├── 202_scsi_bus_driver.md ├── 203_scsi_device_driver │ ├── 2031_driver_binding_protocol_supported.md │ ├── 2032_driver_binding_protocol_start_and_stop.md │ ├── 2033_io_protocol_implementations.md │ └── README.3.md └── README.md ├── 21_ata_driver_design_guidelines ├── 211_ata_host_controller_driver │ ├── 2111_implementing_driver_binding_protocol.md │ ├── 2112_implementing_ata_pass_thru_protocol.md │ ├── 2113_ata_command_set_considerations.md │ ├── 2114_ata_device_paths.md │ └── README.md ├── 212_ata_bus_driver.md ├── Make sure section 212 gets committed.txt └── README.md ├── 22_text_console_driver_design_guidelines ├── 221_assumptions.md ├── 222_simple_text_input_protocol_implementation │ ├── 2221_reset_implementation.md │ ├── 2222_readkeystroke_and_readkeystrokeex_implementat.md │ ├── 2223_waitforkey_and_waitforkeyex_notification_impl.md │ ├── 2224_setstate_implementation.md │ ├── 2225_registerkeynotify_implementation.md │ ├── 2226_unregisterkeynotify_implementation.md │ └── README.md ├── 223_simple_text_output_protocol_implementation │ ├── 2231_reset_implementation.md │ ├── 2232_outputstring_implementation.md │ ├── 2233_teststring_implementation.md │ ├── 2234_querymode_implementation.md │ ├── 2235_setmode_implementation.md │ ├── 2236_setattribute_implementation.md │ ├── 2237_clearscreen_implementation.md │ ├── 2238_setcursorposition_implementation.md │ ├── 2239_enablecursor_implementation.md │ └── README.3.md ├── 224_serial_io_protocol_implementations │ ├── 2241_reset_implementation.md │ ├── 2242_setattributes_implementation.md │ ├── 2243_setcontrol_and_getcontrol_implementation.md │ ├── 2244_write_and_read_implementation.md │ └── README.4.md └── README.md ├── 23_graphics_driver_design_guidelines ├── 231_assumptions.md ├── 232_graphics_output_protocol_implementation │ ├── 2321_single_output_graphics_adapters.md │ ├── 2322_multiple_output_graphics_adapters.md │ ├── 2323_driver_binding_protocol_implementation.md │ ├── 2324_querymode,_setmode,_and_blt_implementation.md │ └── README.md ├── 233_edid_discovered_protocol_implementation.md ├── 234_edid_active_protocol_implementation.md ├── 235_edid_override_protocol_implementation │ ├── 2351_getedid_implementation.md │ └── README.5.md └── README.md ├── 24_mass_storage_driver_design_guidelines ├── 241_assumptions.md ├── 242_block_io_protocol_implementations │ ├── 2421_reset_implementation.md │ ├── 2422_readblocks_and_readblocksex_implementation.md │ ├── 2423_writeblocks_and_writeblockex_implementation.md │ ├── 2424_flushblocks_and_flushblocksex_implementation.md │ └── README.md ├── 243_storage_security_protocol_implementation.md └── README.md ├── 25_network_driver_design_guidelines ├── 251_assumptions.md ├── 252_nii_protocol_and_undi_implementations │ ├── 2521_exit_boot_services_event.md │ ├── 2522_set_virtual_address_map_event.md │ ├── 2523_memory_leaks_caused_by_undi.md │ └── README.md ├── 253_simple_network_protocol_implementations.md ├── 254_managed_network_protocol_implementations.md └── README.md ├── 26_user_credential_driver_design_guidelines ├── 261_assumptions.md ├── 262_user_credential_protocol_implementation.md └── README.md ├── 27_load_file_driver_design_guidelines ├── 271_assumptions.md ├── 272_load_file_protocol_implementation │ ├── 2721_loadfile_implementation.md │ └── README.md └── README.md ├── 28_ipf_platform_porting_considerations ├── 281_general_notes_about_porting_to_ipf_platforms.md ├── 282_alignment_faults.md ├── 283_casting_pointers.md ├── 284_packed_structures.md ├── 285_uefi_device_paths.md ├── 286_pci_configuration_header_64-bit_bar.md ├── 287_speculation_and_floating_point_register_usage.md └── README.md ├── 29_efi_byte_code_porting_considerations ├── 291_no_assembly_support.md ├── 292_no_c++_support.md ├── 293_no_floating_point_support.md ├── 294_use_of_sizeof │ ├── 2941_global_variable_initialization.md │ ├── 2942_case_statements.md │ └── README.md ├── 295_natural_integers_and_fixed_size_integers.md ├── 296_memory_ordering.md ├── 297_performance_considerations │ ├── 2971_performance_considerations_for_data_types.md │ └── README.7.md ├── 298_uefi_driver_entry_point.md └── README.md ├── 2_uefi_driver_implementation_checklist ├── 21_design_and_implementation_of_uefi_drivers.md ├── 22_how_to_implement_features_in_edk_ii.md └── README.md ├── 30_building_uefi_drivers ├── 301_prerequisites.md ├── 302_create_edk_ii_package.md ├── 303_create_uefi_driver_directory │ ├── 3031_disk_io_driver_example.md │ ├── 3032_reserved_directory_names.md │ ├── 3033_ebc_virtual_machine_driver_example.md │ └── README.md ├── 304_adding_a_uefi_driver_to_dsc_file.md ├── 305_building_a_uefi_driver.md └── README.md ├── 31_testing_and_debugging_uefi_drivers ├── 311_native_and_ebc.md ├── 312_compiler_optimizations.md ├── 313_uefi_shell_debugging │ ├── 3131_testing_specific_protocols.md │ ├── 3132_other_testing.md │ ├── 3133_loading_uefi_drivers.md │ ├── 3134_unloading_uefi_drivers.md │ ├── 3135_connecting_uefi_drivers.md │ ├── 3136_driver_and_device_information.md │ ├── 3137_testing_the_driver_configuration_protocol.md │ ├── 3138_testing_the_driver_diagnostics_protocols.md │ └── README.md ├── 314_debugging_code_statements │ ├── 3141_configuring_debuglib_with_edk_ii.md │ ├── 3142_capturing_debug_messages.md │ └── README.4.md ├── 315_post_codes │ ├── 3151_post_card_debug.md │ ├── 3152_other_options.md │ └── README.5.md └── README.md ├── 32_distributing_uefi_drivers ├── 321_pci_option_rom.md ├── 322_integrated_in_platform_flash.md ├── 323_efi_system_partition.md └── README.md ├── 3_foundation ├── 310_uefi_driver_model │ ├── 3101_device_driver.md │ ├── 3102_bus_driver.md │ ├── 3103_hybrid_driver.md │ └── README.10.md ├── 311_service_drivers.md ├── 312_root_bridge_driver.md ├── 313_initializing_driver.md ├── 314_uefi_driver_model_connection_process │ ├── 3141_connectcontroller.md │ ├── 3142_loading_uefi_option_rom_drivers.md │ ├── 3143_disconnectcontroller.md │ └── README.14.md ├── 315_platform_initialization │ ├── 31510_boot_manager_driver_list_processing.md │ ├── 31511_boot_manager_bootnext_processing.md │ ├── 31512_boot_manager_boot_option_processing.md │ ├── 3151_connecting_pci_root_bridges.md │ ├── 3152_connecting_the_pci_bus.md │ ├── 3153_connecting_consoles.md │ ├── 3154_console_drivers.md │ ├── 3155_console_variables.md │ ├── 3156_conin.md │ ├── 3157_conout.md │ ├── 3158_errout.md │ ├── 3159_boot_manager_connect_all_processing.md │ └── README.15.md ├── 31_basic_programming_model.md ├── 32_objects_managed_by_uefi-based_firmware.md ├── 33_uefi_system_table.md ├── 34_handle_database.md ├── 35_guids.md ├── 36_protocols_and_handles │ ├── 361_protocols_are_produced_and_consumed.md │ ├── 362_protocol_interface_structure.md │ ├── 363_protocols_provided_in_addition_to_the_uefi_spe.md │ ├── 364_multiple_protocol_instances.md │ ├── 365_tag_guid.md │ └── README.md ├── 37_uefi_images │ ├── 371_applications.md │ ├── 372_drivers.md │ └── README.7.md ├── 38_events_and_task_priority_levels │ ├── 381_defining_priority.md │ ├── 382_creating_locks.md │ ├── 383_using_callbacks.md │ └── README.8.md ├── 39_uefi_device_paths │ ├── 391_how_drivers_use_device_paths.md │ ├── 392_ipf_considerations_for_device_path_data_struct.md │ ├── 393_environment_variables.md │ └── README.9.md └── README.md ├── 4_general_driver_design_guidelines ├── 41_common_coding_practices │ ├── 411_type_checking.md │ ├── 412_avoid_name_collisions.md │ ├── 413_maximize_warning_levels.md │ ├── 414_compiler_optimizations.md │ └── README.md ├── 42_maximize_platform_compatibility │ ├── 4210_minimize_time_in_notification_functions.md │ ├── 4211_use_proper_task_priority_levels.md │ ├── 4212_design_to_be_re-entrant.md │ ├── 4213_do_not_use_hidden_pci_option_rom_regions.md │ ├── 4214_store_configuration_data_with_device.md │ ├── 4215_do_not_use_hard-coded_device_path_nodes.md │ ├── 4216_do_not_cause_errors_on_shared_storage_devices.md │ ├── 4217_limit_use_of_console_services.md │ ├── 4218_offer_alternatives_to_function_keys.md │ ├── 421_never_assume_all_uefi_drivers_are_executed.md │ ├── 422_eliminate_system_memory_assumptions.md │ ├── 423_use_uefi_memory_allocation_services.md │ ├── 424_do_not_make_assumptions.md │ ├── 425_never_directly_access_hardware_resources.md │ ├── 426_memory_ordering.md │ ├── 427_dma.md │ ├── 428_supporting_older_efi_specifications_and_uefi_s.md │ ├── 429_reduce_poll_frequency.md │ └── README.2.md ├── 43_maximize_cpu_compatibility │ ├── 431_assignment_and_comparison_operators.md │ ├── 432_casting_pointers.md │ ├── 433_converting_pointers.md │ ├── 434_uefi_data_type_sizes.md │ ├── 435_negative_numbers.md │ ├── 436_returning_pointers_in_a_function_parameter.md │ ├── 437_array_subscripts.md │ ├── 438_piecemeal_structure_allocations.md │ └── README.3.md ├── 44_optimization_techniques │ ├── 441_size_reduction.bak.md │ ├── 441_size_reduction.md │ ├── 442_performance_optimizations.md │ ├── 443_copymem_and_setmem_operations.md │ └── README.4.md └── README.md ├── 5_uefi_services ├── 51_services_that_uefi_drivers_commonly_use │ ├── 511_memory_allocation_services.md │ ├── 512_miscellaneous_services.md │ ├── 513_handle_database_and_protocol_services.md │ ├── 514_task_priority_leveltpl_services.md │ ├── 515_event_services.md │ ├── 516_settimer.md │ ├── 517_stall.md │ └── README.md ├── 52_services_that_uefi_drivers_rarely_use │ ├── 5210_installconfigurationtable.md │ ├── 5211_getnextmonotoniccount.md │ ├── 521_connectcontroller_and_disconnectcontroller.md │ ├── 522_reinstallprotocolinterface.md │ ├── 523_locatedevicepath.md │ ├── 524_loadimage_and_startimage.md │ ├── 525_getvariable_and_setvariable.md │ ├── 526_queryvariableinfo.md │ ├── 527_gettime.md │ ├── 528_calculatecrc32.md │ ├── 529_convertpointer.md │ └── README.2.md ├── 53_services_that_uefi_drivers_should_not_use │ ├── 5310_settime,_getwakeuptime,_and_setwakeuptime.md │ ├── 5311_getmemorymap.md │ ├── 5312_exitbootservices.md │ ├── 5313_setvirtualaddressmap.md │ ├── 5314_querycapsulecapabilities.md │ ├── 5315_updatecapsule.md │ ├── 5316_resetsystem.md │ ├── 5317_exit.md │ ├── 5318_getnexthighmonotoniccount.md │ ├── 531_installprotocolinterface.md │ ├── 532_uninstallprotocolinterface.md │ ├── 533_handleprotocol.md │ ├── 534_locatehandle.md │ ├── 535_protocolsperhandle.md │ ├── 536_registerprotocolnotify.md │ ├── 537_unloadimage.md │ ├── 538_getnextvariablename.md │ ├── 539_setwatchdogtimer.md │ └── README.3.md └── README.md ├── 6_uefi_driver_categories ├── 61_device_drivers │ ├── 611_required_device_driver_features.md │ ├── 612_optional_device_driver_features.md │ ├── 613_compatibility_with_older_efiuefi_specification.md │ ├── 614_device_drivers_with_one_driver_binding_protoco.md │ ├── 615_device_drivers_with_multiple_driver_binding_pr.md │ ├── 616_device_driver_protocol_management.md │ └── README.md ├── 62_bus_drivers │ ├── 6210_bus_drivers_that_produce_children_with_multip.md │ ├── 621_required_bus_driver_features.md │ ├── 622_optional_bus_driver_features.md │ ├── 623_bus_drivers_with_one_driver_binding_protocol.md │ ├── 624_bus_drivers_with_multiple_driver_binding_proto.md │ ├── 625_bus_driver_protocol_and_child_management.md │ ├── 626_bus_drivers_that_produce_one_child_in_start.md │ ├── 627_bus_drivers_that_produce_all_children_in_start.md │ ├── 628_bus_drivers_that_produce_at_most_one_child_in_.md │ ├── 629_bus_drivers_that_produce_no_children_in_start.md │ └── README.2.md ├── 63_hybrid_drivers │ ├── 631_required_hybrid_driver_features.md │ ├── 632_optional_hybrid_driver_features.md │ └── README.3.md ├── 64_service_drivers.md ├── 65_root_bridge_drivers.md ├── 66_initializing_drivers.md └── README.md ├── 7_driver_entry_point ├── 710_root_bridge_driver_entry_point.md ├── 711_runtime_drivers.md ├── 71_optional_features.md ├── 72_uefi_driver_model │ ├── 721_single_driver_binding_protocol.md │ ├── 722_multiple_driver_binding_protocols.md │ ├── 723_adding_driver_health_protocol_feature.md │ ├── 724_adding_driver_family_override_protocol_feature.md │ └── README.md ├── 73_adding_the_driver_supported_efi_version_protoco.md ├── 74_adding_hii_packages_feature.md ├── 75_adding_hii_config_access_protocol_feature.md ├── 76_adding_the_unload_feature.md ├── 77_adding_the_exit_boot_services_feature.md ├── 78_initializing_driver_entry_point.md ├── 79_service_driver_entry_point.md └── README.md ├── 8_private_context_data_structures ├── 81_containing_record_macro.md ├── 82_data_structure_design.md ├── 83_allocating_private_context_data_structures.md ├── 84_freeing_private_context_data_structures.md ├── 85_retrieving_private_context_data_structures.md └── README.md ├── 9_driver_binding_protocol ├── 91_driver_binding_protocol_implementations.md ├── 92_driver_binding_protocol_template.md ├── 93_testing_driver_binding_protocol.md └── README.md ├── CODEOWNERS ├── CONTRIBUTIONS.txt ├── EXAMPLES.md ├── FIGURES.md ├── LICENSE.txt ├── README.md ├── SUMMARY.md ├── TABLES.md ├── _layouts ├── ebook │ ├── page.html │ ├── pdf_footer.html │ ├── pdf_header.html │ └── summary.html ├── layout.html └── website │ ├── footer.html │ ├── header.html │ ├── languages.html │ ├── layout.html │ ├── page.html │ └── summary.html ├── appendix_a_edk_ii_file_templates ├── README.md ├── a1_uefi_driver_template.md ├── a2_uefi_driver_optional_protocol_templates │ ├── README.md │ ├── a21_componentnamec_file.md │ ├── a22_driverconfigurationc_file.md │ ├── a23_hiiconfigaccessc_file.md │ ├── a24_driverhealthc_file.md │ ├── a25_driverfamilyoverridec_file.md │ ├── a26_busspecificdriveroverridec_file.md │ └── a27_driverdiagnosticsc_file.md ├── a3_uefi_driver_io_protocol_templates │ ├── README.3.md │ ├── a310_simplenetworkc_file.md │ ├── a311_usercredentialc_file.md │ ├── a312_loadfilec_file.md │ ├── a31_usb2hcc_file.md │ ├── a32_extscsipassthruc_file.md │ ├── a33_atapassthruc_file.md │ ├── a34_simpletextinputc_file.md │ ├── a35_simpletextoutputc_file.md │ ├── a36_serialioc_file.md │ ├── a37_graphicsoutputc_file.md │ ├── a38_blockioc_file.md │ └── a39_niiundic_file.md ├── a4_platform_specific_uefi_driver_templates │ ├── README.4.md │ └── a41_edidoverridec_file.md └── a5_edk_ii_package_extension_templates │ ├── README.5.md │ ├── a51_protocol_file_template.md │ ├── a52_guid_file_template.md │ ├── a53_library_class_file_template.md │ └── a54_including_protocols,_guids,_and_library_classe.md ├── appendix_b_edk_ii_sample_drivers.md ├── appendix_c_glossary.md ├── book.json ├── cover.jpg ├── media ├── DriverHealthStatusState.gif ├── DriverHealthStatusState.jpg ├── DriverHealthStatusState.png ├── TianocoreTitlePageLogo.jpg ├── image1.jpg ├── image11.jpg ├── image13.jpg ├── image15.jpg ├── image17.png ├── image18.jpg ├── image20.jpg ├── image22.jpg ├── image24.jpg ├── image26.jpg ├── image28.jpg ├── image3.jpg ├── image30.jpg ├── image32.jpg ├── image34.jpg ├── image36.jpg ├── image38.jpg ├── image40.jpg ├── image42.jpg ├── image44.jpg ├── image46.jpg ├── image48.jpg ├── image5.jpg ├── image50.jpg ├── image52.jpg ├── image54.jpg ├── image56.jpg ├── image58.jpg ├── image7.jpg └── image9.jpg └── styles ├── epub.css ├── mobi.css ├── pdf.css └── website.css /.bookignore: -------------------------------------------------------------------------------- 1 | /.github 2 | .gitignore 3 | .bookignore 4 | -------------------------------------------------------------------------------- /.github/workflows/gitbook-action.yml: -------------------------------------------------------------------------------- 1 | name: 'Gitbook Action Build' 2 | on: 3 | pull_request_target: 4 | types: 5 | - opened 6 | - edited 7 | - reopened 8 | - synchronize 9 | push: 10 | branches: 11 | - master 12 | - main 13 | - release/* 14 | workflow_dispatch: 15 | 16 | jobs: 17 | publish-gitbook-docs: 18 | name: Publish GitBook Docs 19 | runs-on: ubuntu-latest 20 | steps: 21 | - name: Publish GitBook Docs 22 | uses: tianocore-docs/publish-gitbook-docs@main 23 | with: 24 | token: ${{secrets.GITBOOK_ACTION_PERSONAL_TOKEN}} 25 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Node rules: 2 | ## Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) 3 | .grunt 4 | 5 | ## Dependency directory 6 | ## Commenting this out is preferred by some people, see 7 | ## https://docs.npmjs.com/misc/faq#should-i-check-my-node_modules-folder-into-git 8 | /node_modules 9 | 10 | # Book build output 11 | /_book 12 | 13 | # eBook build output 14 | /book.epub 15 | /book.mobi 16 | /book.pdf -------------------------------------------------------------------------------- /12_uefi_driver_configuration/124_hii_functionality/1241_branding,_and_displaying_a_banner.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 12.4.1 Branding, and displaying a banner 33 | 34 | HII makes it easier for vendors to brand their drivers. This includes 35 | displaying a unique splash screen or banner. This is done through HII forms. 36 | However, the forms themselves are defined in the VFR (visual forms 37 | representation) programming language. (See the VFR Programming Language 38 | Specification). 39 | -------------------------------------------------------------------------------- /12_uefi_driver_configuration/124_hii_functionality/README.4.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 12.4 HII functionality 33 | 34 | HII functionality offers several benefits. One of the biggest is that HII 35 | functionality takes advantage of the platform's existing browser to standardize 36 | forms and change the way data is presented to the user. UEFI Drivers no longer 37 | need to include a browser and this simplifies drivers, helps reduce driver 38 | size, and helps standardize the interface for users. Also, because the forms 39 | support language localization, the driver no longer needs to manually manage 40 | language strings. Instead, the HII interface displays forms as appropriate for 41 | the languages specified by the driver writer. 42 | -------------------------------------------------------------------------------- /12_uefi_driver_configuration/126_hii_implementation_recommendations/1263_concentrate_on_critical_aspects_of_the_driver.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 12.6.3 Concentrate on critical aspects of the driver 33 | 34 | Often people focus on what they can easily see of a driver, which tends to be 35 | the browser, not the actual driver. However, with HII functionality, a driver 36 | no longer needs to include its own browser. Instead, the driver can take 37 | advantage of the platform's browser and other code already written and a part 38 | of the platform. 39 | 40 | ********** 41 | **TIP:** Concentrate on the important parts of the driver (what it does), not 42 | on the more visible, probably browser-related, aspects. A UEFI 2.x conformant 43 | driver uses the platform's existing browser anyway 44 | ********** 45 | -------------------------------------------------------------------------------- /12_uefi_driver_configuration/126_hii_implementation_recommendations/1264_perform_usability_testing.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 12.6.4 Perform usability testing 33 | 34 | Many developers do not perform usability testing on their forms. When 35 | implementing HII functionality, make sure to test for ease of use, readability 36 | of the fields and forms, and the logical flow of concepts from forms to 37 | sub-forms. 38 | -------------------------------------------------------------------------------- /12_uefi_driver_configuration/126_hii_implementation_recommendations/README.6.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 12.6 HII Implementation Recommendations 33 | -------------------------------------------------------------------------------- /16_driver_supported_efi_version_protocol/README.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | # 16 Driver Supported EFI Version Protocol 33 | 34 | The Driver Supported EFI Version Protocol allows a UEFI Driver to specify the 35 | version of the _UEFI Specification_ it follows. The version information follows 36 | the same format as the _Revision_ field in the `EFI_TABLE_HEADER` of the EFI 37 | System Table. This feature is _required_ for UEFI Drivers on PCI and other plug 38 | in cards, but is only _recommended_ for all UEFI Drivers. 39 | -------------------------------------------------------------------------------- /18_pci_driver_design_guidelines/181_pci_root_bridge_io_protocol_drivers.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 18.1 PCI Root Bridge I/O Protocol Drivers 33 | 34 | UEFI firmware for a platform typically implements a Root Bridge Driver that 35 | produces the PCI Root Bridge I/O Protocol. This code is chipset specific and 36 | directly accesses the chipset resources producing the services of the PCI Root 37 | Bridge I/O Protocol. A sample driver for systems with a PC-AT-compatible 38 | chipset is included in EDK II. The source code for this driver is found in the 39 | EDK II package called `PcAtChipsetPkg` in the directory 40 | `PcAtChipsetPkg/PciHostBridgeDxe`. 41 | -------------------------------------------------------------------------------- /18_pci_driver_design_guidelines/182_pci_bus_drivers/1821_hot-plug_pci_buses.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 18.2.1 Hot-plug PCI buses 33 | 34 | The PCI bus driver in the EDK II does not support hot-plug events in the 35 | pre-boot environment. The PCI bus driver functions correctly with 36 | hot-plug-capable hardware, but the hot-add, hot-remove, and hot-replace events 37 | are only supported while an OS that supports hot-plug events is executing. The 38 | PCI bus driver requires updates to support hot-plug events in the pre-boot 39 | environment. 40 | -------------------------------------------------------------------------------- /18_pci_driver_design_guidelines/185_pci_dma/README.5.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 18.5 PCI DMA 33 | 34 | There are three types of DMA transactions that can be implemented using the 35 | services of the PCI I/O Protocol: 36 | 37 | * Bus master read transactions 38 | 39 | * Bus master write transactions 40 | 41 | * Common buffer transactions 42 | 43 | The PCI I/O Protocol services used to manage PCI DMA transactions include: 44 | 45 | * `PciIo->AllocateBuffer()` 46 | 47 | * `PciIo->FreeBuffer()` 48 | 49 | * `PciIo->Map()` 50 | 51 | * `PciIo->Unmap()` - `PciIo->Flush()` 52 | -------------------------------------------------------------------------------- /18_pci_driver_design_guidelines/186_pci_optimization_techniques/README.6.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 18.6 PCI Optimization Techniques 33 | 34 | Several techniques can be used to reduce size and optimize the performance of a 35 | UEFI Driver requiring access to PCI related resources. The following sections 36 | show examples of these techniques applicable to the services provided by the 37 | PCI I/O Protocol. 38 | -------------------------------------------------------------------------------- /19_usb_driver_design_guidelines/191_usb_host_controller_driver/1913_driver_binding_protocol_stop.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 19.1.3 Driver Binding Protocol Stop() 33 | 34 | The `Stop()` service must perform the reverse of the steps the `Start()` 35 | service performs. The USB host controller driver is required to make sure that 36 | there are no memory leaks or handle leaks, as well as making sure that hardware 37 | is stopped accordingly, including restoration of the PCI I/O Protocol 38 | attributes as described in _Chapter 18_. 39 | -------------------------------------------------------------------------------- /19_usb_driver_design_guidelines/194_debug_techniques/1941_debug_message_output.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 19.4.1 Debug Message Output 33 | 34 | One typical debug technique is to output debug messages. The EDK II library 35 | `DebugLib` provides the `DEBUG()` and `ASSERT()` macros to output debug 36 | messages (see _Chapter 31_ of this guide for details on the usage of the 37 | `DEBUG()` and `ASSERT()` macros). Messages may be sent at the entry point and 38 | exit point of functions. When this is done, a log of the call stack is produced 39 | that may help locate the source of the error. It is not suggested to print the 40 | debug message in a frequently called function, such as a timer handler because 41 | this can starve execution cycles at lower TPLs and can significant change the 42 | behavior of the drivers under debug. 43 | -------------------------------------------------------------------------------- /19_usb_driver_design_guidelines/194_debug_techniques/README.4.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 19.4 Debug Techniques 33 | 34 | Several techniques can be used to debug the USB driver stack. The following 35 | discussions describe these techniques. 36 | -------------------------------------------------------------------------------- /1_introduction/13_related_information/131_uefi_specifications.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 1.3.1 UEFI Specifications 33 | 34 | _Unified Extensible Firmware Interface_, version 2.3.1, The UEFI Forum, 2010, http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_3_1.pdf. 35 | Find information about the differences between different versions of the _UEFI 36 | Specification_ at http://www.uefi.org/specifications. 37 | 38 | _Microsoft Portable Executable and Common Object File Format Specification_, 39 | Microsoft Corporation, http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx. 40 | 41 | _Microsoft Extensible Firmware Initiative FAT32 File System Specification_, 42 | Version 1.03, Microsoft Corporation, December 6, 2000, 43 | http://msdn.microsoft.com/enus/windows/hardware/gg463080. 44 | -------------------------------------------------------------------------------- /1_introduction/13_related_information/README.3.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 1.3 Related information 33 | 34 | This chapter contains references to specifications, publications and tools 35 | referenced by other sections of this guide that may be useful in the 36 | development of UEFI Drivers. Find more information about UEFI tables, UEFI 37 | protocols, UEFI GUIDs, UEFI device types and UEFI status codes in the _UEFI 38 | Specification_ at http://uefi.org/specifications. This same information is also available from the 39 | Doxygen-generated help documents in the UDK2010 MdePkg. All source code 40 | examples in this guide follow the C coding style defined in the _EDK II C 41 | Coding Standard Specification_. 42 | -------------------------------------------------------------------------------- /1_introduction/README.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | # 1 Introduction 33 | 34 | UEFI is a modular, extensible interface that abstracts the details of platform 35 | hardware from an operating system (OS). It complements existing interfaces, 36 | helps manufacturers create OS-neutral add-in products, and provides an 37 | efficient replacement for PC BIOS legacy option ROMs. 38 | -------------------------------------------------------------------------------- /20_scsi_driver_design_guidelines/203_scsi_device_driver/2032_driver_binding_protocol_start_and_stop.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 20.3.2 Driver Binding Protocol Start() and Stop() 33 | 34 | The `Start()` service of the Driver Binding Protocol for a SCSI device driver 35 | or host controller driver opens the SCSI I/O Protocol with an attribute of 36 | `EFI_OPEN_PROTOCOL_BY_DRIVER.` The service then installs the I/O abstraction 37 | protocol for the SCSI device onto the handle on which the 38 | `EFI_SCSI_IO_PROTOCOL` is installed. 39 | -------------------------------------------------------------------------------- /20_scsi_driver_design_guidelines/203_scsi_device_driver/2033_io_protocol_implementations.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 20.3.3 I/O Protocol Implementations 33 | 34 | Once a SCSI device driver has been started, it must process I/O requests for 35 | the I/O abstraction that was installed in Driver Binding `Start()`. In the case 36 | of the SCSI Disk Driver, these I/O abstractions are the Block I/O Protocol, the Block I/O 2 37 | Protocol, and optionally the Storage Security Command Protocol. The Block I/O 38 | Protocols use the SCSI I/O Protocol to build SCSI command to perform operations 39 | to detect drive capabilities, read sectors, and write sectors. The EDK II 40 | `MdePkg` also provide the library called `UefiScsiLib` that provides functions 41 | to simplify the use of the SCSI I/O Protocol. 42 | -------------------------------------------------------------------------------- /20_scsi_driver_design_guidelines/203_scsi_device_driver/README.3.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 20.3 SCSI Device Driver 33 | 34 | SCSI device drivers use services provided by `EFI_SCSI_IO_PROTOCOL` to produce 35 | one or more protocols that provide I/O abstractions of a SCSI device. SCSI 36 | device drivers must follow the UEFI Driver Model. The EDK II provides a SCSI 37 | Device Driver for blockoriented SCSI devices such as hard drives, CD-ROM, and 38 | DVD-ROM. The implementation of the SCSI Disk Driver is found in the 39 | `MdeModulePkg` in the directory `MdeModulePkg/Bus/Scsi/ScsiDiskDxe`. 40 | -------------------------------------------------------------------------------- /21_ata_driver_design_guidelines/Make sure section 212 gets committed.txt: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/21_ata_driver_design_guidelines/Make sure section 212 gets committed.txt -------------------------------------------------------------------------------- /22_text_console_driver_design_guidelines/222_simple_text_input_protocol_implementation/2221_reset_implementation.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 22.2.1 Reset() Implementation 33 | 34 | The reset function is for resetting the input device hardware. This only takes 35 | a single parameter which is whether to do an extended or a basic functionality 36 | test following the reset operation. This functions implementation is dependent 37 | on the underlying hardware specifications. However, it is recommended that the 38 | basic functionality test perform as quickly as an operation as possible to 39 | support fast boot times. 40 | -------------------------------------------------------------------------------- /22_text_console_driver_design_guidelines/222_simple_text_input_protocol_implementation/2223_waitforkey_and_waitforkeyex_notification_impl.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 22.2.3 WaitForKey and WaitForKeyEx Notification Implementation 33 | 34 | When the _WaitForKey_ and _WaitForKeyEx_ events are created, they must be 35 | associated with an event notification function. This event notification 36 | function checks to see if one or more keystrokes are currently available from 37 | the console input device. If one or more keystrokes are currently available 38 | from the console input device, then the _WaitForKey_ and _WaitForKeyEx_ events 39 | must be placed into the signaled state by calling the UEFI Boot Service `SignalEvent()`. 40 | -------------------------------------------------------------------------------- /22_text_console_driver_design_guidelines/222_simple_text_input_protocol_implementation/2224_setstate_implementation.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 22.2.4 SetState() Implementation 33 | 34 | The `SetState()` function sets the state on the input device such as Caps Lock, 35 | Num Lock, and Scroll Lock. Updating the state on the device being managed may 36 | perform actions such as changing the state of a user visible indicator, and 37 | also changes the keystroke information returned by `ReadKeyStroke()` and 38 | `ReadKeyStrokeEx()` for keys that are affected by state changes. 39 | -------------------------------------------------------------------------------- /22_text_console_driver_design_guidelines/222_simple_text_input_protocol_implementation/2225_registerkeynotify_implementation.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 22.2.5 RegisterKeyNotify() Implementation 33 | 34 | This function registers a notification function that is called when a specified 35 | keystroke is pressed by the user. This function must create a unique handle 36 | value that is returned, so a previous key registration can be unregistered 37 | using `UnregisterKeyNotify()`. The UEFI Driver is responsible for generating 38 | unique handle values so no two active registrations ever use the same handle 39 | value. 40 | -------------------------------------------------------------------------------- /22_text_console_driver_design_guidelines/222_simple_text_input_protocol_implementation/2226_unregisterkeynotify_implementation.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 22.2.6 UnregisterKeyNotify() Implementation 33 | 34 | This function unregisters a keystroke notification that was registered through 35 | `RegisterKeyNotify()`. 36 | -------------------------------------------------------------------------------- /22_text_console_driver_design_guidelines/223_simple_text_output_protocol_implementation/2232_outputstring_implementation.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 22.3.2 OutputString() Implementation 33 | 34 | `OutputString()` is the function used to output Unicode strings to the console. 35 | It is responsible for verifying the printability of the string passed, fixing 36 | it if required, and displaying it on the console. The steps to follow are: 37 | 1. Verify that the current mode is good. 38 | 2. Check each character to see if it is printable as text or graphics. 39 | Characters that are not printable as text or graphics are skipped. 40 | 3. Print all printable characters. 41 | 4. Update position of the cursor in the *Mode. 42 | 5. Return `EFI_SUCCESS` or `EFI_WARN_UNKNOWN_GLYPH` if some had to be fixed 43 | before printing. 44 | -------------------------------------------------------------------------------- /22_text_console_driver_design_guidelines/223_simple_text_output_protocol_implementation/2233_teststring_implementation.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 22.3.3 TestString() Implementation 33 | 34 | The `TestString()` function verifies that all the characters in the string can 35 | be printed. That is why they do not need to be fixed if they were passed into 36 | the `OutputString()` function. Using the same internal function to do the 37 | verification for the two functions is a good way to make sure that these 38 | functions are consistent. 39 | -------------------------------------------------------------------------------- /22_text_console_driver_design_guidelines/223_simple_text_output_protocol_implementation/2235_setmode_implementation.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 22.3.5 SetMode() Implementation 33 | 34 | The `SetMode()` function is used to select which of the supported output modes 35 | the upper layer wishes to use. The choice should be verified to be a 36 | supportable mode and then the selected mode should be made the currently active 37 | output mode. After this done (and success is guaranteed) update the 38 | `Mode->Mode` variable with the new currently active mode. 39 | 40 | ********** 41 | **Note:** _All devices that support the Simple Text Output Protocol must 42 | minimally support an 80 x 25 character mode. Additional modes are optional._ 43 | ********** 44 | -------------------------------------------------------------------------------- /22_text_console_driver_design_guidelines/223_simple_text_output_protocol_implementation/2236_setattribute_implementation.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 22.3.6 SetAttribute() Implementation 33 | 34 | Setting the attributes is how the upper layers define how the screen printing 35 | should occur. This affects the background and foreground colors that are used 36 | when either `OutputString()` or `ClearScreen()` is called. This function by 37 | itself does not change anything already printed to the console. 38 | -------------------------------------------------------------------------------- /22_text_console_driver_design_guidelines/223_simple_text_output_protocol_implementation/2237_clearscreen_implementation.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 22.3.7 ClearScreen() Implementation 33 | 34 | `ClearScreen()` makes the entire console have no text on it and makes it all 35 | the currently selected background color. The cursor is also set to the (0, 0) 36 | position (upper left square). 37 | -------------------------------------------------------------------------------- /22_text_console_driver_design_guidelines/223_simple_text_output_protocol_implementation/2238_setcursorposition_implementation.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 22.3.8 SetCursorPosition() Implementation 33 | 34 | `SetCursorPosition()` selects a new location for the cursor within the 35 | currently selected console's valid geometry. The new position's row must be 36 | less than the _Row_ returned to `QueryMode()` and likewise the new position's 37 | column must be less than the _Column_ returned to `QueryMode()`. The following 38 | figure shows a representation of the screen coordinates. 39 | 40 | ###### Figure 25-Console Geometry 41 | 42 | ![](../../media/image48.jpg) 43 | -------------------------------------------------------------------------------- /22_text_console_driver_design_guidelines/223_simple_text_output_protocol_implementation/2239_enablecursor_implementation.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 22.3.9 EnableCursor() Implementation 33 | 34 | The `EnableCursor()` function tells the driver whether or not to show the 35 | cursor on the console. This has no impact on the position or functionality of 36 | the cursor, but only its visible state. 37 | -------------------------------------------------------------------------------- /22_text_console_driver_design_guidelines/224_serial_io_protocol_implementations/2241_reset_implementation.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 22.4.1 Reset() Implementation 33 | 34 | When this function is called the UEFI Driver must reset the hardware. There is 35 | no basic or extended functionality required for this reset function unlike the 36 | other reset functions in the console protocols. 37 | -------------------------------------------------------------------------------- /23_graphics_driver_design_guidelines/232_graphics_output_protocol_implementation/2321_single_output_graphics_adapters.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 23.2.1 Single output graphics adapters 33 | 34 | Graphics controllers that are connected to a single output device are the 35 | simplest type of UEFI graphics driver. They produce a single child handle and 36 | attach both Device Path and Graphics Output protocols onto that handle. They 37 | need a single data structure to manage the device. An example of a single 38 | output graphics driver stack is shown below. 39 | 40 | ###### Figure 26-Example single-output graphics driver Implementation 41 | 42 | ![](../../media/image50.jpg) 43 | -------------------------------------------------------------------------------- /23_graphics_driver_design_guidelines/232_graphics_output_protocol_implementation/2322_multiple_output_graphics_adapters.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 23.2.2 Multiple output graphics adapters 33 | 34 | Multiple output graphics drivers (dual or more) are not significantly more 35 | complicated than a single channel adapter in UEFI. An important consideration 36 | is that many graphics adapters may run in a single output mode in the pre-boot 37 | environment; they may then switch to multi-output mode when the higher 38 | performance OS driver loads for the device. An example of a dual output 39 | graphics adapter follows. 40 | 41 | ###### Figure 27-Example dual-output graphics driver implementation 42 | 43 | ![](../../media/image52.jpg) 44 | -------------------------------------------------------------------------------- /23_graphics_driver_design_guidelines/235_edid_override_protocol_implementation/2351_getedid_implementation.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 23.5.1 GetEdid() Implementation 33 | 34 | The `GetEdid()` function returns the handle, attributes (override always, 35 | never, only if nothing is returned), and the new EDID information. This is then 36 | used by UEFI Drivers for graphics controller to produce the EDID Active 37 | Protocol. 38 | -------------------------------------------------------------------------------- /24_mass_storage_driver_design_guidelines/242_block_io_protocol_implementations/2421_reset_implementation.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 24.2.1 Reset() Implementation 33 | 34 | The `Reset()` function resets the block device hardware. During this operation 35 | the UEFI Driver must ensure that the device is functioning correctly. Neither of these 36 | operations should take a significant amount of time. If the ExtendedVerification flag is set to `TRUE`, then the driver may take extra time to make sure that the device is functioning. 37 | -------------------------------------------------------------------------------- /25_network_driver_design_guidelines/254_managed_network_protocol_implementations.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 25.4 Managed Network Protocol Implementations 33 | 34 | Exposing MNP instead has many of the same advantages of implementing SNP and it 35 | reduces one extra layer of drivers. One disadvantage of implementing MNP 36 | instead of SNP, or NII and UNDI is that the VLAN Config Protocol must also be 37 | implemented. In addition, the Managed Network Protocol also requires a Service 38 | Binding Protocol to be implemented. See _Chapter 10_ covering the Service 39 | Binding Protocol. In many cases, since two additional protocols must be 40 | implemented in addition to the Managed Network Protocol, it is `recommended` 41 | that the Simple Network Protocol be implemented instead of the Managed Network 42 | Protocol. 43 | -------------------------------------------------------------------------------- /27_load_file_driver_design_guidelines/271_assumptions.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 27.1 Assumptions 33 | 34 | The rest of this chapter assumes that the Driver Checklist in _Chapter 2_ has 35 | been followed and that the following items have already been identified: 36 | 37 | * UEFI Driver Type 38 | 39 | * Optional UEFI Driver features 40 | 41 | * Supported CPU architectures 42 | 43 | * Consumed protocols that are used to produce the User Credential Protocol. 44 | 45 | UEFI drivers that produce the Load File Protocol typically follow the UEFI 46 | Driver Model. 47 | 48 | However, it is possible to implement UEFI drivers that directly produce the 49 | Load File Protocol for a single device in a platform. In this case a Root 50 | Bridge Driver implementation may be more appropriate than a UEFI Driver Model 51 | implementation. 52 | -------------------------------------------------------------------------------- /29_efi_byte_code_porting_considerations/291_no_assembly_support.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 29.1 No Assembly Support 33 | 34 | The only tools that are provided with the Intel(R) C Compiler for EFI Byte Code 35 | are a C compiler and a linker. No assemblers for EBC are provided. The lack of 36 | an EBC assembler is by design, because the EBC instruction set is optimized for 37 | a C compiler. If a UEFI Driver is being ported to EBC, all assembly language 38 | sources for 32-bit and 64-bit processors must be ported to C language sources. 39 | -------------------------------------------------------------------------------- /29_efi_byte_code_porting_considerations/292_no_c++_support.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 29.2 No C++ Support 33 | 34 | The Intel(R) C Compiler for EFI Byte Code does not support C++. If there is any 35 | C++ code in a UEFI driver being ported to EBC, then that C++ language sources 36 | must be converted to C language sources. 37 | -------------------------------------------------------------------------------- /29_efi_byte_code_porting_considerations/293_no_floating_point_support.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 29.3 No Floating Point Support 33 | 34 | There is no floating-point support in the EBC virtual machine, which means that 35 | the type `float` is not supported by the Intel(R) C Compiler for EFI Byte Code. 36 | If a UEFI Driver is being ported to EBC and the UEFI Driver uses floating-point math, 37 | then the UEFI Driver must be converted to use fixed-point math based on integer 38 | operands and operators. 39 | -------------------------------------------------------------------------------- /29_efi_byte_code_porting_considerations/295_natural_integers_and_fixed_size_integers.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 29.5 Natural Integers and Fixed Size Integers 33 | 34 | UEFI Drivers should only use the integer data types defined in the Calling 35 | Conventions section of the _UEFI Specification_. Even when this recommendation 36 | is followed, there is an additional limitation of the EBC architecture. UEFI 37 | Drivers with arithmetic calculations and comparisons between following integer 38 | types must be avoided: 39 | 40 | * `INTN` and `UINT8` 41 | 42 | * `INTN` and `UINT16` 43 | 44 | * `INTN` and `UINT32` 45 | 46 | * `UINTN` and `INT64` 47 | -------------------------------------------------------------------------------- /30_building_uefi_drivers/303_create_uefi_driver_directory/3031_disk_io_driver_example.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 30.3.1 Disk I/O Driver Example 33 | 34 | A more complete example of a simple UEFI Driver that follows the UEFI Driver 35 | Model is the Disk I/O driver in the MdeModulePkg. The directory path and INF 36 | file and source files are shown in the example below. 37 | 38 | ###### Example 261-Disk I/O UEFI Driver Source Files 39 | 40 | ``` 41 | MdeModulePkg\ 42 | Universal\ Disk\ 43 | DiskIoDxe\ 44 | ComponentName.c 45 | Diskio.c 46 | Diskio.h 47 | DiskIoDxe.inf 48 | ``` 49 | -------------------------------------------------------------------------------- /31_testing_and_debugging_uefi_drivers/311_native_and_ebc.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 31.1 Native and EBC 33 | 34 | When possible, provide a driver in both native-instruction-set and EBC binary 35 | forms. Providing both of these forms allows the OEM firmware to simulate 36 | testing the driver in a fast, best-case scenario and a slower scenario. If the 37 | driver is tested to work as both an EBC and native-instruction-set binary, it 38 | is expected that there are fewer timing sensitivities to the driver, and it is 39 | more robust. 40 | -------------------------------------------------------------------------------- /31_testing_and_debugging_uefi_drivers/313_uefi_shell_debugging/3134_unloading_uefi_drivers.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 31.3.4 Unloading UEFI drivers 33 | 34 | This table lists UEFI Shell commands that can be used to unload a UEFI driver 35 | if it is unloadable. 36 | 37 | ###### Table 43-UEFI Shell commands for unloading UEFI drivers 38 | 39 | ``` 40 | Command 41 | Shell> Unload 27 42 | ``` 43 | -------------------------------------------------------------------------------- /31_testing_and_debugging_uefi_drivers/314_debugging_code_statements/3142_capturing_debug_messages.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 31.4.2 Capturing Debug Messages 33 | 34 | In addition, the parameters for the serial port on the "target" system (the 35 | system under test) must be setup correctly, including baud rate, data bits, 36 | stop bits, and flow control. The settings on the target system must match the 37 | settings on the host system that is receiving the debug data. The EDK II 38 | includes sample code for serial port debug output for the PEI phase, in the MDE 39 | module package. The MDE module package also includes sample code for serial 40 | port debug output for the DXE phase 41 | -------------------------------------------------------------------------------- /31_testing_and_debugging_uefi_drivers/315_post_codes/3152_other_options.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 31.5.2 Other options 33 | 34 | Another option is to use some type of byte-stream-based device. This device 35 | could include a UART or a SMBus, for example. Like the POST card, the idea is 36 | to use the services of the PCI Root Bridge I/O or PCI I/O Protocols to 37 | initialize and send characters to the byte-stream device. 38 | -------------------------------------------------------------------------------- /32_distributing_uefi_drivers/322_integrated_in_platform_flash.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 32.2 Integrated in Platform FLASH 33 | 34 | A manufacturer that produces UEFI Drivers for their devices may choose to work 35 | with platform manufacturers to have their UEFI Drivers integrated into the UEFI 36 | firmware for a target platform. UEFI Drivers can be provided in source or 37 | binary form, and it is up to the platform manufacturer to integrate those UEFI 38 | Drivers into their UEFI platform firmware images and verify that the UEFI 39 | Driver is loaded and executed properly. 40 | -------------------------------------------------------------------------------- /32_distributing_uefi_drivers/README.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | # 32 Distributing UEFI Drivers 33 | 34 | Once a UEFI Driver is implemented and validated and ready to be released, there 35 | are only a few ways that the UEFI Driver can be installed onto a target 36 | platform. These include: 37 | 38 | * PCI Option ROM on a PCI add-in card. 39 | 40 | * Integrated into the platform firmware FLASH image. 41 | 42 | * A file in an EFI System Partition. 43 | -------------------------------------------------------------------------------- /3_foundation/310_uefi_driver_model/3103_hybrid_driver.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 3.10.3 Hybrid driver 33 | 34 | A hybrid driver manages and enumerates a bus controller. Its `Start()` function 35 | creates one or more child handles and installs protocols into the child 36 | handles. Its `Start()` function also installs protocols onto the handle for the 37 | bus controller itself. 38 | -------------------------------------------------------------------------------- /3_foundation/313_initializing_driver.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 3.13 Initializing Driver 33 | 34 | An initializing driver does not create any handles and it does not add any 35 | protocols to the handle database. Instead, this type of driver performs some 36 | initialization operations and then intentionally returns an error code so the 37 | driver is unloaded from system memory. The EDK II does not currently include 38 | examples of UEFI initializing drivers. 39 | -------------------------------------------------------------------------------- /3_foundation/314_uefi_driver_model_connection_process/3143_disconnectcontroller.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 3.14.3 DisconnectController() 33 | 34 | `DisconnectController()` performs the opposite of `ConnectController()`. It 35 | requests that drivers managing a controller release the controller. 36 | -------------------------------------------------------------------------------- /3_foundation/315_platform_initialization/3158_errout.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 3.15.8 ErrOut 33 | 34 | In this example, _ErrOut_ is the same as _ConOut_. So the connection process 35 | for _ConOut_ is executed one more time. 36 | 37 | ``` 38 | ErrOut = Acpi(HWP0002,0,PNP0A03)/Pci(1|1)/Uart(9600 N81)/ 39 | VenMsg(Vt100+);Acpi(HWP0002,0,PNP0A03)/Pci(4|0) 40 | ``` 41 | -------------------------------------------------------------------------------- /3_foundation/36_protocols_and_handles/362_protocol_interface_structure.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 3.6.2 Protocol interface structure 33 | 34 | The following figure shows a single handle and protocol from the handle 35 | database produced by a UEFI driver. The protocol is composed of a GUID and a 36 | protocol interface structure. 37 | 38 | Many times, the UEFI driver that produces a protocol interface maintains 39 | additional private data fields. The protocol interface structure itself simply 40 | contains pointers to the protocol function. The protocol functions are actually 41 | contained within the UEFI driver. A UEFI driver may produce one protocol or 42 | many protocols depending on the driver's complexity. 43 | 44 | ###### Figure 4-Construction of a Protocol 45 | 46 | ![](../../media/image7.jpg) 47 | -------------------------------------------------------------------------------- /3_foundation/36_protocols_and_handles/365_tag_guid.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 3.6.5 Tag GUID 33 | 34 | A protocol may be nothing more than a GUID with no associated data structure. 35 | This GUID is also known as a _tag GUID_. Such a protocol can be useful, for 36 | example, to mark a device handle as special in some way or allow other UEFI 37 | images to find the device handle easily by querying the system for the device 38 | handles with that protocol GUID attached. 39 | -------------------------------------------------------------------------------- /3_foundation/38_events_and_task_priority_levels/381_defining_priority.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 3.8.1 Defining priority 33 | 34 | Notification functions at higher priorities can interrupt the execution of 35 | notification functions executing at a lower priority. 36 | 37 | The mechanism for defining the priority (in which notification functions are 38 | executed), is used only when more than one event is in the signaled state at 39 | the same time. In these cases, the notification function that has been 40 | registered with the higher priority is executed first. 41 | -------------------------------------------------------------------------------- /3_foundation/39_uefi_device_paths/393_environment_variables.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 3.9.3 Environment variables 33 | 34 | Device paths are also used when certain environment variables are built and 35 | stored in non-volatile storage. There are a number of environment variables 36 | defined in the Boot Manager chapter of the _UEFI Specification_. These 37 | variables define the following: 38 | 39 | * Console input devices 40 | 41 | * Console output devices 42 | 43 | * Standard error devices 44 | 45 | * The drivers that need to be loaded prior to an OS boot 46 | 47 | * The boot selections that the platform supports 48 | 49 | The UEFI boot manager, UEFI utilities, and UEFI-conformant operating systems 50 | manage these environment variables as operating systems are installed and 51 | removed from a platform. 52 | -------------------------------------------------------------------------------- /4_general_driver_design_guidelines/41_common_coding_practices/412_avoid_name_collisions.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 4.1.2 Avoid Name Collisions 33 | 34 | Compilers and linkers guarantee that there are no function name or global 35 | variable name collisions within a single UEFI Driver, but the compilers and 36 | linkers cannot check for function name or global variable name collisions 37 | between UEFI Drivers. This inability to check is a concern when debuggers are 38 | used that can perform source-level debugging or can display function names. 39 | _Appendix A_ contains source code templates that help avoid function name 40 | collisions between UEFI Drivers by using the name of the driver in the function 41 | names. 42 | -------------------------------------------------------------------------------- /4_general_driver_design_guidelines/41_common_coding_practices/414_compiler_optimizations.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 4.1.4 Compiler Optimizations 33 | 34 | Test UEFI Drivers built with compiler optimizations enabled and disabled. This 35 | helps identify odd code errors that might not manifest at lower optimization 36 | levels. It also helps identify if a UEFI Driver is sensitive to differences in 37 | execution speed. A UEFI Driver that works at lower levels of optimization, but 38 | not at higher levels, may be missing logic for a required synchronization. 39 | -------------------------------------------------------------------------------- /4_general_driver_design_guidelines/42_maximize_platform_compatibility/4210_minimize_time_in_notification_functions.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 4.2.10 Minimize Time in Notification Functions 33 | 34 | UEFI drivers should not spend a lot of time in their event notification 35 | functions because this blocks the normal execution mode of the system. A UEFI 36 | driver using a periodic timer event can always save some state information and 37 | wait for the next timer tick if the driver needs to wait for a device to 38 | respond. The USB bus driver is an example driver in the EDK II that uses 39 | periodic timer events. 40 | -------------------------------------------------------------------------------- /4_general_driver_design_guidelines/42_maximize_platform_compatibility/4212_design_to_be_re-entrant.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 4.2.12 Design to be re-entrant 33 | 34 | Design all UEFI Drivers to manage multiple controllers. This requires that the 35 | controller specific information be managed in its own data structure. The 36 | practical manifestation of this requirement is that all the data that must be 37 | local to the instance (context) of the protocol must **not** be stored in global 38 | variables. Instead, collect data into a private context data structure so that 39 | each time an I/O protocol installs onto a handle, a new version of the 40 | structure is allocated from memory. This concept is described in detail in 41 | _Chapter 8_ of this guide. 42 | -------------------------------------------------------------------------------- /4_general_driver_design_guidelines/42_maximize_platform_compatibility/427_dma.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 4.2.7 DMA 33 | 34 | System memory buffers used for DMA should not be allocated from a specific 35 | address or below a specific address. In addition, UEFI drivers must always use 36 | I/O abstractions to setup and complete DMA transactions. 37 | 38 | It is not legal to program a system memory address into a DMA bus master. This 39 | programming works on chipsets that have a one-to-one mapping between system 40 | memory addresses and PCI DMA addresses, but it does not work with chipsets that 41 | remap DMA transactions. 42 | -------------------------------------------------------------------------------- /4_general_driver_design_guidelines/42_maximize_platform_compatibility/README.2.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 4.2 Maximize Platform Compatibility 33 | 34 | UEFI drivers should make as few assumptions about a system's architecture as 35 | possible. Minimizing the number of assumptions maximizes the UEFI driver's 36 | platform compatibility. It also reduces the amount of driver maintenance that 37 | is required when a UEFI Driver is deployed on new platforms. 38 | -------------------------------------------------------------------------------- /4_general_driver_design_guidelines/43_maximize_cpu_compatibility/432_casting_pointers.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 4.3.2 Casting pointers 33 | 34 | Pointers can be cast from one pointer type to another pointer type. However, 35 | pointers should never be cast to a fixed-size data type, and fixed-size data 36 | types should never be cast to pointers. 37 | 38 | The size of a pointer varies depending on the platform architecture, such as 39 | 32-bit versus 64-bit platforms. If any assumptions are made that a pointer to a 40 | function or a pointer to a data structure is a 32-bit value, then that code may 41 | not run on 64-bit platforms with physical memory above 4 GB. 42 | -------------------------------------------------------------------------------- /4_general_driver_design_guidelines/44_optimization_techniques/README.4.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 4.4 Optimization Techniques 33 | 34 | There are several techniques you can be use to optimize a UEFI driver. These 35 | techniques can be broken down into the following two categories: 36 | 37 | * Techniques to reduce the size of UEFI drivers 38 | 39 | * Techniques to improve the performance of UEFI drivers 40 | 41 | Sometimes these techniques complement each other―sometimes they are at odds 42 | with each other. For example, a UEFI driver may grow in size to meet a specific 43 | 44 | performance goal. The driver writer is required to make the appropriate 45 | compromises in the selection of these driver optimization techniques. 46 | -------------------------------------------------------------------------------- /5_uefi_services/53_services_that_uefi_drivers_should_not_use/5310_settime,_getwakeuptime,_and_setwakeuptime.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 5.3.10 SetTime(), GetWakeupTime(), and SetWakeupTime() 33 | 34 | UEFI drivers should not modify the system time or the wakeup timer. The 35 | management of these timer services should be left to the UEFI boot manager, an 36 | OEM-provided utility, or an operating system. 37 | -------------------------------------------------------------------------------- /5_uefi_services/53_services_that_uefi_drivers_should_not_use/5312_exitbootservices.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 5.3.12 ExitBootServices() 33 | 34 | This service hands control of the platform from UEFI conformant firmware to a 35 | UEFI conformant operating system. It should be invoked only by UEFI OS loaders 36 | or OS kernels. It should never be called by a UEFI driver. Refer to the Image 37 | Services section in the _UEFI Specification_ for more information about this 38 | service. 39 | -------------------------------------------------------------------------------- /5_uefi_services/53_services_that_uefi_drivers_should_not_use/5313_setvirtualaddressmap.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 5.3.13 SetVirtualAddressMap() 33 | 34 | This service is used only by UEFI OS loaders or OS kernels when an operating 35 | system requests UEFI Runtime Services be mapped using virtual addresses. It 36 | must be called after `ExitBootServices()` is called. As a result, it is not 37 | legal for UEFI drivers to call this service. 38 | -------------------------------------------------------------------------------- /5_uefi_services/53_services_that_uefi_drivers_should_not_use/5314_querycapsulecapabilities.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 5.3.14 QueryCapsuleCapabilities() 33 | 34 | UEFI drivers should not use this service. It is typically used by an operating 35 | system or an OEM provided utility to test to see if a capsule or capsules can 36 | be updated via `UpdateCapsule()` service as part of a capsule update action. 37 | -------------------------------------------------------------------------------- /5_uefi_services/53_services_that_uefi_drivers_should_not_use/5315_updatecapsule.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 5.3.15 UpdateCapsule() 33 | 34 | UEFI drivers should not use this service. It is typically used by an operating 35 | system or an OEM provided utility to pass a capsule to the firmware as part of 36 | a capsule update action. 37 | -------------------------------------------------------------------------------- /5_uefi_services/53_services_that_uefi_drivers_should_not_use/531_installprotocolinterface.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 5.3.1 InstallProtocolInterface() 33 | 34 | This service adds one protocol interface to an existing handle or creates a new 35 | handle. This service has been replaced by the 36 | `InstallMultipleProtocolInterfaces()` service, so all UEFI drivers should use 37 | the replacement service. Using this replacement service provides additional 38 | flexibility and additional error checking and produces smaller EFI drivers. 39 | -------------------------------------------------------------------------------- /5_uefi_services/53_services_that_uefi_drivers_should_not_use/532_uninstallprotocolinterface.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 5.3.2 UninstallProtocolInterface() 33 | 34 | This service removes one protocol interface from a handle in the handle database. The functionality of this service has been replaced by `UninstallMultipleProtocolInterfaces()`. This service uninstalls one or more protocol interfaces from the same handle. Using this replacement service provides additional flexibility and produces smaller UEFI drivers. 35 | -------------------------------------------------------------------------------- /5_uefi_services/53_services_that_uefi_drivers_should_not_use/533_handleprotocol.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 5.3.3 HandleProtocol() 33 | 34 | UEFI drivers should not use this service because a UEFI drivers that uses this 35 | service to lookup protocol is not conformant with the UEFI Driver Model. 36 | Instead, `OpenProtocol()` should be used because it provides equivalent 37 | functionality, and it also allows the Handle Database to track the components 38 | that are using different protocol interfaces in the handle database. 39 | -------------------------------------------------------------------------------- /5_uefi_services/53_services_that_uefi_drivers_should_not_use/534_locatehandle.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 5.3.4 LocateHandle() 33 | 34 | This service returns an array of handles that support a specified protocol. 35 | This service requires the caller to allocate the return buffer. The 36 | `LocateHandleBuffer()` service is easier to use and produces smaller 37 | executables because it allocates the return buffer for the caller. 38 | -------------------------------------------------------------------------------- /5_uefi_services/53_services_that_uefi_drivers_should_not_use/535_protocolsperhandle.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 5.3.5 ProtocolsPerHandle() 33 | 34 | This service retrieves the list of protocols that are installed on a handle. In 35 | general, UEFI drivers know what protocols are installed on the handles that the 36 | UEFI driver is managing, so this service is not required for proper UEFI Driver 37 | operation. This service is typically used by UEFI applications, such as 38 | diagnostics or debug utilities, that need to traverse the entire contents of 39 | the Handle Database. 40 | -------------------------------------------------------------------------------- /5_uefi_services/53_services_that_uefi_drivers_should_not_use/537_unloadimage.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 5.3.7 UnloadImage() 33 | 34 | This service unloads a UEFI Driver from memory that was previously loaded using 35 | the UEFI Boot Service `LoadImage()`. There are currently no known use cases for 36 | this service from a UEFI Driver. `UnloadImage()` is typically used from a UEFI 37 | Application like the UEFI Shell to manage the set of active UEFI Drivers. 38 | 39 | ********** 40 | **Caution:** A UEFI Driver must never use this service to unload itself. This 41 | service frees all the memory associated with the UEFI Driver and returns 42 | control to the location the UEFI Driver used to reside in memory, thereby 43 | producing unexpected results. 44 | ********** 45 | -------------------------------------------------------------------------------- /5_uefi_services/53_services_that_uefi_drivers_should_not_use/539_setwatchdogtimer.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 5.3.9 SetWatchdogTimer() 33 | 34 | UEFI drivers should not use this service. The watchdog timer is managed by the 35 | UEFI boot manager. 36 | -------------------------------------------------------------------------------- /6_uefi_driver_categories/61_device_drivers/README.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 6.1 Device drivers 33 | 34 | All device drivers following the UEFI driver model share a set of common 35 | characteristics. The next two sections describe the required and optional 36 | features for device drivers. These sections are followed by a detailed 37 | description of device drivers that produce both single and multiple instances 38 | of the Driver Binding Protocol. 39 | -------------------------------------------------------------------------------- /6_uefi_driver_categories/62_bus_drivers/623_bus_drivers_with_one_driver_binding_protocol.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 6.2.3 Bus drivers with one driver binding protocol 33 | 34 | The driver entry point of a bus driver is very similar to the driver entry 35 | point of a device driver. The discussion in _Section 6.1.4_ applies equally 36 | well to both bus drivers and device drivers. The differences between bus 37 | drivers and device drivers are exposed in the implementations of the Driver 38 | Binding Protocol. The following sections describe the behaviors of the 39 | `Start()` function of the Driver Binding Protocol for each type of bus driver. 40 | -------------------------------------------------------------------------------- /6_uefi_driver_categories/62_bus_drivers/627_bus_drivers_that_produce_all_children_in_start.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### 6.2.7 Bus drivers that produce all children in Start() 33 | 34 | If a bus driver is always required to enumerate all of its child devices, then 35 | the _RemainingDevicePath_ parameter should be ignored in the `Supported()` and 36 | `Start()` services of the `EFI_DRIVER_BINDING_PROTOCOL`. All of the child 37 | handles should be produced in the first call to `Start()`. 38 | -------------------------------------------------------------------------------- /6_uefi_driver_categories/66_initializing_drivers.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## 6.6 Initializing Drivers 33 | 34 | An initializing driver does not create any handles and it does not add any 35 | protocols to the handle database. Instead, this type of driver performs some 36 | initialization operations and then intentionally returns an error code so the 37 | driver is unloaded from system memory. There are currently no examples of 38 | initializing drivers in the EDK II. 39 | -------------------------------------------------------------------------------- /CODEOWNERS: -------------------------------------------------------------------------------- 1 | # tianocore-docs CODEOWNERS 2 | 3 | * @leiflindholm @mdkinney @ajfish @ardbiesheuvel @makubacki 4 | -------------------------------------------------------------------------------- /LICENSE.txt: -------------------------------------------------------------------------------- 1 | Redistribution and use in source (original document form) and 'compiled' 2 | forms (converted to PDF, epub, HTML and other formats) with or without 3 | modification, are permitted provided that the following conditions are met: 4 | 5 | 1. Redistributions of source code (original document form) must retain the 6 | above copyright notice, this list of conditions and the following 7 | disclaimer as the first lines of this file unmodified. 8 | 9 | 2. Redistributions in compiled form (transformed to other DTDs, converted to 10 | PDF, epub, HTML and other formats) must reproduce the above copyright 11 | notice, this list of conditions and the following disclaimer in the 12 | documentation and/or other materials provided with the distribution. 13 | 14 | THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR 15 | IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 16 | MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 17 | EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 18 | SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 19 | PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; 20 | OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, 21 | WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR 22 | OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF 23 | ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 24 | -------------------------------------------------------------------------------- /_layouts/ebook/page.html: -------------------------------------------------------------------------------- 1 | {% extends "layout.html" %} 2 | 3 | {% block title %}{{ page.title }}{% endblock %} 4 | {% block description %}{{ page.description }}{% endblock %} 5 | 6 | {% block style %} 7 | {### Include theme css before plugins css ###} 8 | {% if not fileExists(config.styles.print) %} 9 | {% if options.format %} 10 | 11 | {% else %} 12 | 13 | {% endif %} 14 | {% endif %} 15 | 16 | {{ super() }} 17 | 18 | {### Custom stylesheets for the book ###} 19 | 20 | {% for type, style in config.styles %} 21 | {% if fileExists(style) and (type == "ebook" or type == "print" or type == options.format) %} 22 | 23 | {% endif %} 24 | {% endfor %} 25 | {% endblock %} 26 | 27 | {% block body %} 28 |
29 | {% block page %} 30 |

{{ page.title }}

31 | {% if options.format == "mobi" %} 32 |
33 | {{ page.content|safe }} 34 |
35 | {% else %} 36 |
37 | {{ page.content|safe }} 38 |
39 | {% endif %} 40 | {% endblock %} 41 |
42 | {% endblock %} 43 | -------------------------------------------------------------------------------- /_layouts/ebook/pdf_footer.html: -------------------------------------------------------------------------------- 1 | {% extends "./page.html" %} 2 | 3 | {% block body %} 4 |
5 | {% if book.draft %} 6 |

7 |

DRAFT FOR REVIEW [{{ gitbook.time|date('MM/DD/YYYY hh:mm:ss') }}]
8 |
{{ page.num }}
9 |

10 | {% else %} 11 |

12 |

{{ book.version }}
13 |
{{ page.num }}
14 |

15 | {% endif %} 16 |
17 | {% endblock %} 18 | -------------------------------------------------------------------------------- /_layouts/ebook/pdf_header.html: -------------------------------------------------------------------------------- 1 | {% extends "./page.html" %} 2 | 3 | {% block body %} 4 |
5 |

6 | {% if book.draft %} 7 |

{{ book.title }}[DRAFT]
8 | {% else %} 9 |
{{ book.title }}
10 | {% endif %} 11 |
{{ page.title }}
12 |

13 |
14 | {% endblock %} 15 | -------------------------------------------------------------------------------- /_layouts/layout.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | {% block title %}{{ config.title|d("GitBook", true) }}{% endblock %} 7 | 8 | 9 | 10 | {% if config.author %}{% endif %} 11 | {% if config.isbn %}{% endif %} 12 | {% block style %} 13 | {% for resource in plugins.resources.css %} 14 | {% if resource.url %} 15 | 16 | {% else %} 17 | 18 | {% endif %} 19 | {% endfor %} 20 | {% endblock %} 21 | {% block head %}{% endblock %} 22 | 23 | 24 | {% block body %}{% endblock %} 25 | {% block javascript %}{% endblock %} 26 | 27 | 28 | -------------------------------------------------------------------------------- /_layouts/website/footer.html: -------------------------------------------------------------------------------- 1 | {% block book_footer %} 2 |
3 |
4 | {% if book.draft %} 5 |

6 |
{{ book.title }}
7 |
DRAFT [{{ gitbook.time|date('MM/DD/YYYY hh:mm:ss') }}]
8 |
{{ book.version }}
9 |

10 | {% else %} 11 |

12 |
{{ book.title }}
13 |
{{ book.version }}
14 |

15 | {% endif %} 16 |
17 | {% endblock %} 18 | -------------------------------------------------------------------------------- /_layouts/website/header.html: -------------------------------------------------------------------------------- 1 | {% block book_header %} 2 | 13 |
14 | 17 | {% if book.draft %} 18 |

19 |
{{ book.title }}
20 |
DRAFT [{{ gitbook.time|date('MM/DD/YYYY hh:mm:ss') }}]
21 |
{{ book.version }}
22 |

23 | {% else %} 24 |

25 |
{{ book.title }}
26 |
{{ book.version }}
27 |

28 | {% endif %} 29 |
30 |
31 | {% endblock %} 32 | -------------------------------------------------------------------------------- /_layouts/website/languages.html: -------------------------------------------------------------------------------- 1 | {% extends "./layout.html" %} 2 | 3 | {% block title %}{{ "LANGS_CHOOSE"|t }} · {{ super() }}{% endblock %} 4 | 5 | {% block body %} 6 | 19 | {% endblock %} 20 | -------------------------------------------------------------------------------- /_layouts/website/layout.html: -------------------------------------------------------------------------------- 1 | {% extends "layout.html" %} 2 | 3 | {% block head %} 4 | {{ super() }} 5 | 6 | 7 | 8 | 9 | 10 | 11 | {% endblock %} 12 | 13 | {% block style %} 14 | {### Include theme css before plugins css ###} 15 | 16 | 17 | {{ super() }} 18 | 19 | {### Custom stylesheets for the book ###} 20 | 21 | {% for type, style in config.styles %} 22 | {% if fileExists(style) and type == "website" %} 23 | 24 | {% endif %} 25 | {% endfor %} 26 | {% endblock %} 27 | 28 | {% block body %}{% endblock %} 29 | -------------------------------------------------------------------------------- /_layouts/website/summary.html: -------------------------------------------------------------------------------- 1 | {% macro articles(_articles) %} 2 | {% for article in _articles %} 3 |
  • 4 | {% if article.path and getPageByPath(article.path) %} 5 | 6 | {% elif article.url %} 7 | 8 | {% else %} 9 | 10 | {% endif %} 11 | {% if article.level != "0" and config.pluginsConfig['theme-default'].showLevel %} 12 | {{ article.level }}. 13 | {% endif %} 14 | {{ article.title }} 15 | {% if article.path or article.url %} 16 | 17 | {% else %} 18 | 19 | {% endif %} 20 | 21 | {% if article.articles.length > 0 %} 22 | 25 | {% endif %} 26 |
    • 27 | {% endfor %} 28 | {% endmacro %} 29 | 30 | 62 | -------------------------------------------------------------------------------- /appendix_a_edk_ii_file_templates/a2_uefi_driver_optional_protocol_templates/README.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## A.2 _UEFI Driver Optional Protocol Templates_ 33 | 34 | This section contains templates for the implementation of optional protocols 35 | that may be part of a UEFI Driver implementation. This includes the following: 36 | 37 | * Component Name Protocols 38 | 39 | * Driver Configuration Protocols 40 | 41 | * HII Config Access Protocol 42 | 43 | * Driver Health Protocol 44 | 45 | * Driver Family Override Protocol 46 | 47 | * Bus Specific Driver Override Protocol 48 | 49 | * Driver Diagnostics Protocols 50 | -------------------------------------------------------------------------------- /appendix_a_edk_ii_file_templates/a2_uefi_driver_optional_protocol_templates/a25_driverfamilyoverridec_file.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ### A.2.5 _DriverFamilyOverride.c File_ 33 | 34 | ###### Example A-10-Driver Family Override Protocol implementation template 35 | 36 | ```c 37 | /** @file 38 | <> 39 | <> 40 | <> 41 | <> 42 | **/ 43 | 44 | #include "<>.h" 45 | 46 | GLOBAL_REMOVE_IF_UNREFERENCED 47 | EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL g<>DriverFamilyOverride = { 48 | <>DriverFamilyOverrideGetVersion 49 | }; 50 | 51 | UINT32 52 | EFIAPI 53 | <>DriverFamilyOverrideGetVersion ( 54 | IN EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL *This 55 | ) 56 | { 57 | return 0; 58 | } 59 | ``` 60 | -------------------------------------------------------------------------------- /appendix_a_edk_ii_file_templates/a3_uefi_driver_io_protocol_templates/README.3.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## A.3 _UEFI Driver I/O Protocol Templates_ 33 | 34 | This section contains templates for the implementation of protocols that 35 | provide I/O services or services to abstract a specific type of device 36 | hardware. This includes the following: 37 | 38 | * USB Host Controllers 39 | 40 | * SCSI Host Controllers 41 | 42 | * ATA Host Controllers 43 | 44 | * Simple Text Input Devices 45 | 46 | * Simple Text Output Devices 47 | 48 | * Serial Port (UART) Controllers 49 | 50 | * Graphics Controllers 51 | 52 | * Network Interface Controllers 53 | 54 | * Mass Storage Device (Hard Disk, CD-ROM, DVD-ROM, FLASH drive) 55 | 56 | * User Credential Devices (Smart Card, Fingerprint Readers, etc.) 57 | -------------------------------------------------------------------------------- /appendix_a_edk_ii_file_templates/a4_platform_specific_uefi_driver_templates/README.4.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## A.4 _Platform Specific UEFI Driver Templates_ 33 | 34 | This section contains templates for the implementation of protocols that are 35 | typically provided with the UEFI platform firmware. 36 | -------------------------------------------------------------------------------- /appendix_a_edk_ii_file_templates/a5_edk_ii_package_extension_templates/README.5.md: -------------------------------------------------------------------------------- 1 | 31 | 32 | ## A.5 _EDK II Package Extension Templates_ 33 | 34 | This section contains templates for the extending the contents of an EDK II 35 | package. This is not a common operation, but some UEFI Driver implementations 36 | may choose to define new protocols, new GUIDs, or new library classes. This 37 | section also covers how to include protocols, GUIDs, and library classes in a 38 | UEFI Driver. 39 | -------------------------------------------------------------------------------- /book.json: -------------------------------------------------------------------------------- 1 | { 2 | "variables" : { 3 | "draft" : "yes", 4 | "title" : "EDK II Driver Writer's Guide for UEFI 2.3.1", 5 | "version" : "Revision 1.10" 6 | }, 7 | "plugins": ["puml-aleung"], 8 | "pluginsConfig": {} 9 | } 10 | -------------------------------------------------------------------------------- /cover.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/cover.jpg -------------------------------------------------------------------------------- /media/DriverHealthStatusState.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/DriverHealthStatusState.gif -------------------------------------------------------------------------------- /media/DriverHealthStatusState.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/DriverHealthStatusState.jpg -------------------------------------------------------------------------------- /media/DriverHealthStatusState.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/DriverHealthStatusState.png -------------------------------------------------------------------------------- /media/TianocoreTitlePageLogo.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/TianocoreTitlePageLogo.jpg -------------------------------------------------------------------------------- /media/image1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image1.jpg -------------------------------------------------------------------------------- /media/image11.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image11.jpg -------------------------------------------------------------------------------- /media/image13.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image13.jpg -------------------------------------------------------------------------------- /media/image15.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image15.jpg -------------------------------------------------------------------------------- /media/image17.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image17.png -------------------------------------------------------------------------------- /media/image18.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image18.jpg -------------------------------------------------------------------------------- /media/image20.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image20.jpg -------------------------------------------------------------------------------- /media/image22.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image22.jpg -------------------------------------------------------------------------------- /media/image24.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image24.jpg -------------------------------------------------------------------------------- /media/image26.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image26.jpg -------------------------------------------------------------------------------- /media/image28.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image28.jpg -------------------------------------------------------------------------------- /media/image3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image3.jpg -------------------------------------------------------------------------------- /media/image30.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image30.jpg -------------------------------------------------------------------------------- /media/image32.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image32.jpg -------------------------------------------------------------------------------- /media/image34.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image34.jpg -------------------------------------------------------------------------------- /media/image36.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image36.jpg -------------------------------------------------------------------------------- /media/image38.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image38.jpg -------------------------------------------------------------------------------- /media/image40.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image40.jpg -------------------------------------------------------------------------------- /media/image42.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image42.jpg -------------------------------------------------------------------------------- /media/image44.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image44.jpg -------------------------------------------------------------------------------- /media/image46.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image46.jpg -------------------------------------------------------------------------------- /media/image48.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image48.jpg -------------------------------------------------------------------------------- /media/image5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image5.jpg -------------------------------------------------------------------------------- /media/image50.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image50.jpg -------------------------------------------------------------------------------- /media/image52.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image52.jpg -------------------------------------------------------------------------------- /media/image54.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image54.jpg -------------------------------------------------------------------------------- /media/image56.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image56.jpg -------------------------------------------------------------------------------- /media/image58.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image58.jpg -------------------------------------------------------------------------------- /media/image7.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image7.jpg -------------------------------------------------------------------------------- /media/image9.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tianocore-docs/edk2-UefiDriverWritersGuide/98808290faf5568e09161b929876d7e855a384d9/media/image9.jpg -------------------------------------------------------------------------------- /styles/epub.css: -------------------------------------------------------------------------------- 1 | p { 2 | font-family: sans, sans-serif, Arial; 3 | } 4 | 5 | body { 6 | font-family: sans, sans-serif, Arial; 7 | } 8 | 9 | h1 { 10 | color: #0860A8; 11 | font-weight: normal; 12 | font-size: 190%; 13 | text-transform: uppercase; 14 | } 15 | 16 | h2 { 17 | color: #0860A8; 18 | font-size: 130% 19 | } 20 | 21 | h3 { 22 | color: #0860A8; 23 | font-weight: bold; 24 | font-size: 100% 25 | } 26 | 27 | h4 { 28 | color: #0860A8; 29 | font-size: 90% 30 | } 31 | 32 | h5 { 33 | font-weight: bold; 34 | font-size: 90%; 35 | } 36 | 37 | h6 { 38 | font-weight: bold; 39 | font-size: 90%; 40 | text-align: center; 41 | } 42 | 43 | img { 44 | max-width: 100%; 45 | height: auto; 46 | } 47 | 48 | -------------------------------------------------------------------------------- /styles/mobi.css: -------------------------------------------------------------------------------- 1 | p { 2 | font-family: sans, sans-serif, Arial; 3 | } 4 | 5 | body { 6 | font-family: sans, sans-serif, Arial; 7 | } 8 | 9 | h1 { 10 | color: #0860A8; 11 | font-weight: bold; 12 | font-size: 170%; 13 | text-transform: uppercase; 14 | } 15 | 16 | h2 { 17 | color: #0860A8; 18 | font-weight: bold; 19 | font-size: 160% 20 | } 21 | 22 | h3 { 23 | color: #0860A8; 24 | font-weight: bold; 25 | font-size: 150% 26 | } 27 | 28 | h4 { 29 | color: #0860A8; 30 | font-weight: bold; 31 | font-size: 140% 32 | } 33 | 34 | h5 { 35 | font-weight: bold; 36 | font-size: 130%; 37 | } 38 | 39 | h6 { 40 | font-weight: bold; 41 | font-size: 100%; 42 | text-align: center; 43 | } 44 | 45 | img { 46 | max-width: 100%; 47 | height: auto; 48 | } 49 | 50 | -------------------------------------------------------------------------------- /styles/pdf.css: -------------------------------------------------------------------------------- 1 | p { 2 | font-family: sans, sans-serif, Arial; 3 | } 4 | 5 | body { 6 | font-family: sans, sans-serif, Arial; 7 | } 8 | 9 | h1 { 10 | font-family: Intel Clear; 11 | color: #0071C5; 12 | font-weight: bold; 13 | font-size: 20pt; 14 | } 15 | 16 | h2 { 17 | font-family: Intel Clear; 18 | color: #0071C5; 19 | font-weight: bold; 20 | font-size: 16pt; 21 | } 22 | 23 | h3 { 24 | font-family: Intel Clear; 25 | color: #0071C5; 26 | font-weight: bold; 27 | font-size: 14pt; 28 | } 29 | 30 | h4 { 31 | font-family: Intel Clear; 32 | color: #0071C5; 33 | font-weight: bold; 34 | font-size: 12pt; 35 | } 36 | 37 | h5 { 38 | font-family: Intel Clear; 39 | font-weight: bold; 40 | font-size: 11pt; 41 | } 42 | 43 | /* h6 is used for table, figure, and example captions */ 44 | h6 { 45 | font-family: Intel Clear; 46 | font-weight: bold; 47 | font-size: 10pt; 48 | text-align: center; 49 | } 50 | 51 | /* test items 52 | @page { 53 | size: landscape; 54 | orientation: landscape; 55 | } 56 | 57 | code { 58 | font-family: Courier New; 59 | font-size: 10pt; 60 | color: #8B0000; 61 | } 62 | 63 | pre code { 64 | font-family: Courier New; 65 | font-size: 10pt; 66 | color: #8B0000; 67 | } 68 | 69 | pre { 70 | font-family: Courier New; 71 | font-size: 10pt; 72 | color: #8B0000; 73 | } 74 | 75 | blockquote { 76 | font-family: Courier New; 77 | font-size: 10pt; 78 | color: #8B0000; 79 | } 80 | 81 | img { 82 | max-width: 100%; 83 | height: auto; 84 | } 85 | 86 | table tr { 87 | page-break-inside: avoid; 88 | } 89 | 90 | div.section-1, 91 | div.section-2 { 92 | page-break-before: auto; 93 | } 94 | 95 | .markdown-section table { 96 | table-layout: fixed; 97 | display:block; 98 | overflow-x: auto; 99 | } 100 | 101 | */ 102 | -------------------------------------------------------------------------------- /styles/website.css: -------------------------------------------------------------------------------- 1 | p { 2 | font-family: sans, sans-serif, Arial; 3 | } 4 | 5 | body { 6 | font-family: sans, sans-serif, Arial; 7 | } 8 | 9 | h1 { 10 | color: #0860A8; 11 | font-weight: normal; 12 | font-size: 190%; 13 | text-transform: uppercase; 14 | } 15 | 16 | h2 { 17 | color: #0860A8; 18 | font-size: 130% 19 | } 20 | 21 | h3 { 22 | color: #0860A8; 23 | font-weight: bold; 24 | font-size: 100% 25 | } 26 | 27 | h4 { 28 | color: #0860A8; 29 | font-size: 90% 30 | } 31 | 32 | h5 { 33 | font-weight: bold; 34 | font-size: 90%; 35 | } 36 | 37 | h6 { 38 | font-weight: bold; 39 | font-size: 90%; 40 | text-align: center; 41 | } 42 | 43 | img { 44 | max-width: 100%; 45 | height: auto; 46 | } 47 | 48 | --------------------------------------------------------------------------------