Welcome to follow VxWorks567
If forwarded, please indicate the source!
In the mid-1990s, Simply EFI was introduced to create a new boot firmware for the 64-bit Itanium platform (IA64), rather than adapting the existing 16-bit BIOS on IA32. It was renamed UEFI (Unified Extensible Firmware Interface) in version 2.0 and underwent many improvements to support both IA32 and X64.
Main differences between UEFI and BIOS:
Currently, UEFI supports the following systems:
The latest version of the UEFI specification is 2.10:
https://uefi.org/pressreleases
UEFI source code and platform-independent parts:
http://www.tianocore.com
1.1 Basic Design of UEFI Firmware
Systems supporting UEFI provide UEFI firmware in onboard non-volatile memory. UEFI runs at power-on or hard reset, initializing system hardware and the UEFI environment. The firmware can also load UEFI drivers for peripherals from NVRAM or the device’s ROM. UEFI firmware itself consists of multiple modules. Some are platform-independent, including core support and additional features. Others (e.g., low-level hardware initialization code and drivers) depend on hardware, usually proprietary. The specific combination of functions may vary by board.
UEFI provides a runtime environment that allows applications to execute. These can be boot utilities or the OS bootloader itself. UEFI executable applications must be in Microsoft PE32 (32-bit) or PE32+ (64-bit) format. UEFI runtime services are divided into two categories: boot services and operating system runtime services. Boot services APIs are quite extensive, providing support for file and network access as well as console I/O, but they are only available for boot utilities and loaders. When the OS loader is ready to hand over control to the operating system runtime module (kernel or higher loader stage), it must disable access to the boot services API. After that, only some runtime services are available.
UEFI services are provided in the form of APIs and divided into multiple protocols, with each API of a protocol identified by a globally unique GUID. UEFI applications can issue queries to determine if a specific GUID is registered. Upon successful query, a handle is returned that contains a set of function pointers, allowing the application to call the corresponding APIs of the protocol. Each protocol’s C header file is provided in the UEFI development kit, containing API function definitions and GUIDs.
For example, some UEFI supports PXE boot. A runtime UEFI application can query whether the PXE protocol is available. If so, it can use the PXE API to perform DHCP and obtain the operating system image; otherwise, the loader can check the disk-based file loading protocol.
This dynamic linking mechanism avoids UEFI applications from directly linking to the corresponding protocol and allows a single application to work with UEFI firmware with various feature sets.
It is important to note that service code is executed using the native CPU instruction set. This means that on X64 systems, the firmware code is compiled with the 64-bit X64-64 instruction set, and the CPU must be in long mode to run it. Moreover, UEFI firmware uses the x86-64 Microsoft C calling convention.
1.2. How does UEFI boot a system?
UEFI supports booting from hard drives, USB drives, floppy disks, or networks, depending on the features and drivers included in the UEFI firmware build. UEFI firmware loads all available boot device drivers and searches for all accessible paths that may contain the UEFI loader. It then executes the boot program, allowing it to load the OS image in turn. Each operating system needs its own UEFI-compatible loader, and its functionality depends on the operating system.
UEFI firmware selects boot devices that meet specific criteria, which vary slightly depending on whether the device is a disk or a network device. For removable disk devices, the following criteria apply:
-
The disk has the directory \efi\boot
-
This directory contains the file \efi\boot\boot{hardware type}.efi
-
-
-
-
-
bootia64.efi – (Itanium, VxWorks UEFI not supported)
-
bootriscv32.efi – (RISC-V 32-bit, VxWorks UEFI not supported)
-
bootriscv64.efi – (RISC-V 64-bit, VxWorks UEFI not supported)
-
bootriscv128.efi – (RISC-V 128-bit, VxWorks UEFI not supported)
For example, if a FAT32 formatted USB drive contains the file \efi\boot\bootia32.efi, the UEFI firmware will consider this USB drive as a boot device.
For disk booting, the firmware selects the boot file name based on its architecture. IA32 will look for the bootia32.efi file, while X64 will look for the bootx64.efi file. Most Intel systems that support UEFI use processors that support 64-bit, thus including the 64-bit UEFI build. Theoretically, such systems can run either IA32 or X64 versions of UEFI, but Intel tends to use the 64-bit version whenever possible. Currently, only a few Atom systems still use IA32. (Newer Atom processors also include 64-bit extensions, and IA32 support may gradually be phased out.)
For networks, the standards are different. The firmware does not search the boot path. Instead, the network interface used for booting must have the corresponding UEFI driver. The driver can be included in the UEFI firmware or in the device’s ROM. In this case, the UEFI firmware can use the device for PXE booting, with the actual boot path and boot file name specified by DHCP.
Some UEFI implementations for Intel x86 systems also support booting older operating systems that still require BIOS-based boot paths. These versions include a Compatibility Support Module (CSM) that can search for BIOS boot paths on disks with MBR partition tables.
If multiple devices are available, the UEFI firmware will create a list of boot paths. By default, it will prioritize paths on built-in hard drives. Users can select different paths through the firmware’s menu.
UEFI maintains some global variables in NVRAM that represent boot paths and boot order. According to the UEFI specification, these variable names are BootXXXX, where XXXX is a number between 0000 and 9999. Each BootXXXX variable is an EFI_LOAD_OPTION structure that describes the boot path and the EFI_DEVICE_PATH used to describe the system image location. A variable named BootOrder defines a UINT16 array that indicates the order of boot path selection. The value of this UINT16 is the XXXX part of the BootXXXX variable name.
Boot path variables are typically manipulated through the UEFI firmware menu, but UEFI programs can also manage them using the GetVariable() and SetVariable() services.
2. VxWorks UEFI Boot Loader
The VxWorks UEFI boot loader supports certain hardware platforms and provides source code.
-
Intel platforms, including IA32 and X64
-
ARM platforms, including AArch32 and AArch64
EFI files are generated using the Wind River LLVM toolchain, and the LLVM binutils convert the generated ELF files to PE32 or PE32+ format. The following systems are supported:
The currently supported version is 3.0.14:
https://sourceforge.net/projects/gnu-efi/
VxWorks can boot from local storage devices or networks, depending on the capabilities of the UEFI firmware.UEFI boot supports the following BSP:
3. Creating a Bootable Environment
The easiest way to create a UEFI boot system for VxWorks is to store the UEFI loader, VxWorks bootrom, and VxWorks image on a FAT32 formatted USB drive.
Assuming the FAT32 USB drive is E:. When a FAT file system contains the \EFI\BOOT\BOOT{hardware type}.EFI file, the UEFI firmware will consider it a boot device.
Create the following directory structure for booting Intel platforms:
-
-
-
E:\> copy C:\PATH\TO\BOOTIA32.EFI E:\EFI\BOOT
-
E:\> copy C:\PATH\TO\BOOTX64.EFI E:\EFI\BOOT
Both loaders can be stored simultaneously, allowing both 32-bit and 64-bit systems to boot.
The EFI loader looks for the file bootapp.sys in the \EFI\BOOT directory by default; if not found, it searches the root directory of the disk.Therefore, when booting Intel platforms:
-
E:\> copy C:\PATH\TO\vxWorks_romCompress E:\EFI\BOOT\bootapp.sys
-
E:\> copy C:\PATH\TO\vxWorks_romCompress E:\bootapp.sys
Finally, copy the VxWorks image to the root directory of the USB drive.
-
E:\> copy C:\PATH\TO\vxWorks E:
Or, directly load VxWorks:
If multiple boot devices are connected, most Intel platforms will prompt the user to enter the configuration menu via F2, for example:
[UEFI: ThingCo USB drive]
Alternatively, users can enter the BBS menu using F7.
The first item in the menu is CSM boot, specifying the device name through the USB drive. The firmware will consider the device to contain a legacy BIOS-compatible boot block and partition table, such as the boot block vxld.bin for VxWorks systems.
The second item is the UEFI boot for the same device. The firmware will use the corresponding BOOTXXX.EFI.
Sometimes, the UEFI firmware cannot automatically recognize the boot device. You can enter [Built-in UEFI shell] and load directly:
In this case, you can also create a Startup.nsh script in the root directory to execute automatically. The file only needs to contain one line:
If it is an IA32 system, it should be written as:
-
Create a FAT32 partition on the hard disk (not necessarily using the entire disk).
-
Create the directory \EFI\BOOT on the hard disk.
-
Copy the loader BOOT{hardware type}.EFI (for example, BOOTIA32.EFI / BOOTX64.EFI for Intel platforms) to this directory.
-
-
Refer to the above text to create a bootable USB drive containing the VxWorks UEFI loader.
-
Connect the USB drive, power on, and press F7 to enter the BBS menu.
-
-
After stopping with any key, press ‘M‘ or ‘m‘ to enter the boot manager.
-
Select Create a boot path, then select the hard disk partition containing the VxWorks UEFI loader and bootapp.sys.
-
-
Select Reset system.
Disk booting will vary depending on the UEFI firmware. If the disk contains a FAT32 system and \EFI\BOOT\BOOT{hardware type}.EFI boot file, it can be used directly.
However, the operating system installer can also create boot items for selecting specific boot devices and boot paths. This is achieved by manipulating the environment variables stored in NVRAM using UEFI’s GetVariable() and SetVariable().
The VxWorks UEFI loader has a built-in small boot path manager that allows users to create boot items through a simple menu.To access this interface, users can pause the boot process by pressing a key before the 3-second countdown, then press “M” or “m” to start the manager.
It includes the following options:
After selecting
