ARM Packages: Removed trailing spaces
Trailing spaces create issue/warning when generating/applying patches. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ronald Cron <ronald.cron@arm.com> Reviewed-By: Olivier Martin <olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15833 6f19259b-4bc3-4df7-8a09-765794883524
This commit is contained in:
committed by
oliviermartin
parent
62d441fb17
commit
3402aac7d9
@@ -1,13 +1,13 @@
|
||||
/** @file
|
||||
The entry of the embedded BDS. This BDS does not follow the Boot Manager requirements
|
||||
of the UEFI specification as it is designed to implement an embedded systmes
|
||||
The entry of the embedded BDS. This BDS does not follow the Boot Manager requirements
|
||||
of the UEFI specification as it is designed to implement an embedded systmes
|
||||
propriatary boot scheme.
|
||||
|
||||
This template assume a DXE driver produces a SerialIo protocol not using the EFI
|
||||
This template assume a DXE driver produces a SerialIo protocol not using the EFI
|
||||
driver module and it will attempt to connect a console on top of this.
|
||||
|
||||
Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>
|
||||
|
||||
|
||||
This program and the accompanying materials
|
||||
are licensed and made available under the terms and conditions of the BSD License
|
||||
which accompanies this distribution. The full text of the license may be found at
|
||||
@@ -28,22 +28,22 @@ EFI_BDS_ARCH_PROTOCOL gBdsProtocol = {
|
||||
};
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
/**
|
||||
This function uses policy data from the platform to determine what operating
|
||||
system or system utility should be loaded and invoked. This function call
|
||||
also optionally make the use of user input to determine the operating system
|
||||
or system utility to be loaded and invoked. When the DXE Core has dispatched
|
||||
all the drivers on the dispatch queue, this function is called. This
|
||||
function will attempt to connect the boot devices required to load and invoke
|
||||
the selected operating system or system utility. During this process,
|
||||
additional firmware volumes may be discovered that may contain addition DXE
|
||||
drivers that can be dispatched by the DXE Core. If a boot device cannot be
|
||||
fully connected, this function calls the DXE Service Dispatch() to allow the
|
||||
DXE drivers from any newly discovered firmware volumes to be dispatched.
|
||||
Then the boot device connection can be attempted again. If the same boot
|
||||
device connection operation fails twice in a row, then that boot device has
|
||||
This function uses policy data from the platform to determine what operating
|
||||
system or system utility should be loaded and invoked. This function call
|
||||
also optionally make the use of user input to determine the operating system
|
||||
or system utility to be loaded and invoked. When the DXE Core has dispatched
|
||||
all the drivers on the dispatch queue, this function is called. This
|
||||
function will attempt to connect the boot devices required to load and invoke
|
||||
the selected operating system or system utility. During this process,
|
||||
additional firmware volumes may be discovered that may contain addition DXE
|
||||
drivers that can be dispatched by the DXE Core. If a boot device cannot be
|
||||
fully connected, this function calls the DXE Service Dispatch() to allow the
|
||||
DXE drivers from any newly discovered firmware volumes to be dispatched.
|
||||
Then the boot device connection can be attempted again. If the same boot
|
||||
device connection operation fails twice in a row, then that boot device has
|
||||
failed, and should be skipped. This function should never return.
|
||||
|
||||
@param This The EFI_BDS_ARCH_PROTOCOL instance.
|
||||
@@ -71,7 +71,7 @@ BdsEntry (
|
||||
UINTN Index;
|
||||
EFI_DEVICE_PATH_PROTOCOL *LoadImageDevicePath;
|
||||
EFI_DEVICE_PATH_PROTOCOL *FileSystemDevicePath;
|
||||
|
||||
|
||||
PERF_END (NULL, "DXE", NULL, 0);
|
||||
PERF_START (NULL, "BDS", NULL, 0);
|
||||
|
||||
@@ -82,12 +82,12 @@ BdsEntry (
|
||||
Size = 0x100;
|
||||
gST->FirmwareVendor = AllocateRuntimePool (Size);
|
||||
ASSERT (gST->FirmwareVendor != NULL);
|
||||
|
||||
|
||||
UnicodeSPrint (gST->FirmwareVendor, Size, L"BeagleBoard EFI %a %a", __DATE__, __TIME__);
|
||||
|
||||
//
|
||||
// Now we need to setup the EFI System Table with information about the console devices.
|
||||
// This code is normally in the console spliter driver on platforms that support multiple
|
||||
// This code is normally in the console spliter driver on platforms that support multiple
|
||||
// consoles at the same time
|
||||
//
|
||||
Status = gBS->LocateHandleBuffer (ByProtocol, &gEfiSimpleTextOutProtocolGuid, NULL, &NoHandles, &Buffer);
|
||||
@@ -97,15 +97,15 @@ BdsEntry (
|
||||
gST->StandardErrorHandle = Buffer[0];
|
||||
Status = gBS->HandleProtocol (Buffer[0], &gEfiSimpleTextOutProtocolGuid, (VOID **)&gST->ConOut);
|
||||
ASSERT_EFI_ERROR (Status);
|
||||
|
||||
|
||||
gST->StdErr = gST->ConOut;
|
||||
|
||||
|
||||
gST->ConOut->OutputString (gST->ConOut, L"BDS: Console Started!!!!\n\r");
|
||||
FreePool (Buffer);
|
||||
|
||||
|
||||
gConsolePresent = TRUE;
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
|
||||
Status = gBS->LocateHandleBuffer (ByProtocol, &gEfiSimpleTextInProtocolGuid, NULL, &NoHandles, &Buffer);
|
||||
if (!EFI_ERROR (Status)) {
|
||||
@@ -113,12 +113,12 @@ BdsEntry (
|
||||
gST->ConsoleInHandle = Buffer[0];
|
||||
Status = gBS->HandleProtocol (Buffer[0], &gEfiSimpleTextInProtocolGuid, (VOID **)&gST->ConIn);
|
||||
ASSERT_EFI_ERROR (Status);
|
||||
|
||||
|
||||
FreePool (Buffer);
|
||||
}
|
||||
|
||||
//
|
||||
// We now have EFI Consoles up and running. Print () will work now. DEBUG () and ASSERT () worked
|
||||
// We now have EFI Consoles up and running. Print () will work now. DEBUG () and ASSERT () worked
|
||||
// prior to this point as they were configured to use a more primative output scheme.
|
||||
//
|
||||
|
||||
@@ -138,7 +138,7 @@ BdsEntry (
|
||||
if (EFI_ERROR (Status)) {
|
||||
break;
|
||||
}
|
||||
|
||||
|
||||
if (HandleCount == OldHandleCount) {
|
||||
break;
|
||||
}
|
||||
@@ -186,9 +186,9 @@ BdsEntry (
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
//
|
||||
// Normal UEFI behavior is to process Globally Defined Variables as defined in Chapter 3
|
||||
// Normal UEFI behavior is to process Globally Defined Variables as defined in Chapter 3
|
||||
// (Boot Manager) of the UEFI specification. For this embedded system we don't do this.
|
||||
//
|
||||
|
||||
@@ -208,7 +208,7 @@ BdsEntry (
|
||||
}
|
||||
|
||||
//
|
||||
// EFI does not define the behaviour if all boot attemps fail and the last one returns.
|
||||
// EFI does not define the behaviour if all boot attemps fail and the last one returns.
|
||||
// So we make a policy choice to reset the system since this BDS does not have a UI.
|
||||
//
|
||||
gRT->ResetSystem (EfiResetShutdown, Status, 0, NULL);
|
||||
|
Reference in New Issue
Block a user