/** @file\r
- The entry of the embedded BDS. This BDS does not follow the Boot Manager requirements \r
- of the UEFI specification as it is designed to implement an embedded systmes \r
+ The entry of the embedded BDS. This BDS does not follow the Boot Manager requirements\r
+ of the UEFI specification as it is designed to implement an embedded systmes\r
propriatary boot scheme.\r
\r
- This template assume a DXE driver produces a SerialIo protocol not using the EFI \r
+ This template assume a DXE driver produces a SerialIo protocol not using the EFI\r
driver module and it will attempt to connect a console on top of this.\r
\r
Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>\r
- \r
+\r
This program and the accompanying materials\r
are licensed and made available under the terms and conditions of the BSD License\r
which accompanies this distribution. The full text of the license may be found at\r
};\r
\r
\r
- \r
- \r
+\r
+\r
/**\r
- This function uses policy data from the platform to determine what operating \r
- system or system utility should be loaded and invoked. This function call \r
- also optionally make the use of user input to determine the operating system \r
- or system utility to be loaded and invoked. When the DXE Core has dispatched \r
- all the drivers on the dispatch queue, this function is called. This \r
- function will attempt to connect the boot devices required to load and invoke \r
- the selected operating system or system utility. During this process, \r
- additional firmware volumes may be discovered that may contain addition DXE \r
- drivers that can be dispatched by the DXE Core. If a boot device cannot be \r
- fully connected, this function calls the DXE Service Dispatch() to allow the \r
- DXE drivers from any newly discovered firmware volumes to be dispatched. \r
- Then the boot device connection can be attempted again. If the same boot \r
- device connection operation fails twice in a row, then that boot device has \r
+ This function uses policy data from the platform to determine what operating\r
+ system or system utility should be loaded and invoked. This function call\r
+ also optionally make the use of user input to determine the operating system\r
+ or system utility to be loaded and invoked. When the DXE Core has dispatched\r
+ all the drivers on the dispatch queue, this function is called. This\r
+ function will attempt to connect the boot devices required to load and invoke\r
+ the selected operating system or system utility. During this process,\r
+ additional firmware volumes may be discovered that may contain addition DXE\r
+ drivers that can be dispatched by the DXE Core. If a boot device cannot be\r
+ fully connected, this function calls the DXE Service Dispatch() to allow the\r
+ DXE drivers from any newly discovered firmware volumes to be dispatched.\r
+ Then the boot device connection can be attempted again. If the same boot\r
+ device connection operation fails twice in a row, then that boot device has\r
failed, and should be skipped. This function should never return.\r
\r
@param This The EFI_BDS_ARCH_PROTOCOL instance.\r
UINTN Index;\r
EFI_DEVICE_PATH_PROTOCOL *LoadImageDevicePath;\r
EFI_DEVICE_PATH_PROTOCOL *FileSystemDevicePath;\r
- \r
+\r
PERF_END (NULL, "DXE", NULL, 0);\r
PERF_START (NULL, "BDS", NULL, 0);\r
\r
Size = 0x100;\r
gST->FirmwareVendor = AllocateRuntimePool (Size);\r
ASSERT (gST->FirmwareVendor != NULL);\r
- \r
+\r
UnicodeSPrint (gST->FirmwareVendor, Size, L"BeagleBoard EFI %a %a", __DATE__, __TIME__);\r
\r
//\r
// Now we need to setup the EFI System Table with information about the console devices.\r
- // This code is normally in the console spliter driver on platforms that support multiple \r
+ // This code is normally in the console spliter driver on platforms that support multiple\r
// consoles at the same time\r
//\r
Status = gBS->LocateHandleBuffer (ByProtocol, &gEfiSimpleTextOutProtocolGuid, NULL, &NoHandles, &Buffer);\r
gST->StandardErrorHandle = Buffer[0];\r
Status = gBS->HandleProtocol (Buffer[0], &gEfiSimpleTextOutProtocolGuid, (VOID **)&gST->ConOut);\r
ASSERT_EFI_ERROR (Status);\r
- \r
+\r
gST->StdErr = gST->ConOut;\r
- \r
+\r
gST->ConOut->OutputString (gST->ConOut, L"BDS: Console Started!!!!\n\r");\r
FreePool (Buffer);\r
- \r
+\r
gConsolePresent = TRUE;\r
- } \r
- \r
+ }\r
+\r
\r
Status = gBS->LocateHandleBuffer (ByProtocol, &gEfiSimpleTextInProtocolGuid, NULL, &NoHandles, &Buffer);\r
if (!EFI_ERROR (Status)) {\r
gST->ConsoleInHandle = Buffer[0];\r
Status = gBS->HandleProtocol (Buffer[0], &gEfiSimpleTextInProtocolGuid, (VOID **)&gST->ConIn);\r
ASSERT_EFI_ERROR (Status);\r
- \r
+\r
FreePool (Buffer);\r
}\r
\r
//\r
- // We now have EFI Consoles up and running. Print () will work now. DEBUG () and ASSERT () worked \r
+ // We now have EFI Consoles up and running. Print () will work now. DEBUG () and ASSERT () worked\r
// prior to this point as they were configured to use a more primative output scheme.\r
//\r
\r
if (EFI_ERROR (Status)) {\r
break;\r
}\r
- \r
+\r
if (HandleCount == OldHandleCount) {\r
break;\r
}\r
}\r
}\r
}\r
- \r
+\r
//\r
- // Normal UEFI behavior is to process Globally Defined Variables as defined in Chapter 3 \r
+ // Normal UEFI behavior is to process Globally Defined Variables as defined in Chapter 3\r
// (Boot Manager) of the UEFI specification. For this embedded system we don't do this.\r
//\r
\r
}\r
\r
//\r
- // EFI does not define the behaviour if all boot attemps fail and the last one returns. \r
+ // EFI does not define the behaviour if all boot attemps fail and the last one returns.\r
// So we make a policy choice to reset the system since this BDS does not have a UI.\r
//\r
gRT->ResetSystem (EfiResetShutdown, Status, 0, NULL);\r
projects / mirror_edk2.git / blobdiff