Thanks guys. Andrew and Aaron especially. Now things make sense!!
Rafael R. Machado Em qui, 2 de jun de 2016 às 13:40, <[email protected]> escreveu: > Hi Rafael, > > The short answer is that no, once pages of memory are converted from > available to another type, they will never be converted back to available, > and this is as intended. > > The long answer is complex. Firmware is, at its most basic level, meant to > initialize hardware and give control to an operating system. There are > multiple goals the firmware wants to achieve as part of this. It wants to > deterministic (the next boot wants to be as close to this boot as possible > in the order of drivers run, the amout of memory consumed, the memory > fragmentation, etc) . To keep the memory footprint to a minimum and the > memory fragmentation to a minimum, the EDK2 creates memory bins for each > type of memory that is defined in the specification. These memory bins are > meant to prevent memory fragmentation (and thus reduce the number of memory > map entries, E820 entries, etc, etc). The amount of memory required for > each memory type is tracked in the EDK2 and saved so that when memory is > discovered, the amount of each memory type will be allocated in contiguous > chunks, and that these chunks will be large enough to accommodate all > allocations for the rest of the boot process. > > So in this case, when you boot to Shell, you have essentially completed > the end of the firmware process and the system has uefi booted. The Boot > Services are still available, and you can allocate memory, etc, but the > deterministic portion of the boot process has completed. Any of your > interactions, allocations, etc, are outside of the known amount memory that > was used in previous boots, which will cause available memory to be > converted to boot services memory. > > Also keep in mind that since the firmware's goal is to transfer control to > an operating system, and that when the operating system calls exit boot > services, all boot services memory used by the firmware is abandoned. > After its abandoned, it becomes available for the operating system to use, > so the changes in the memory map's boot services have no effect. > > I hope this helps clarify your questions. > > > > > > From: Rafael Machado <[email protected]> > To: [email protected] > Cc: "Carsey, Jaben" <[email protected]>, " > [email protected]" <[email protected]>, edk2-devel < > [email protected]>, Andrew Fish <[email protected]> > Date: 06/02/2016 05:49 AM > Subject: Re: [edk2] Memory Consumption after BLT (GOP) > Sent by: "edk2-devel" <[email protected]> > ------------------------------ > > > > Hi everyone / Aaron > > I was studying Aaron's message to be sure I got everything he explained. > Now I have just one last question. > > You mentioned that the calls to LocateHandleBuffer, AllocatePool and > GOP->BLT change some memory types and allocate them. > I can confirm that this is exactly what happens. Before the memory is > decreased I have this map from the memmap uefi shell command: > > available 0000000064059000-0000000064086FFF 000000000000002E > 000000000000000F > > BS_data : 10,774 Pages (44,130,304) > available : 407,183 Pages (1,667,821,568) > > And after some executions I have this map: > > available 0000000064059000-0000000064085FFF 000000000000002D > 000000000000000F > BS_data 0000000064086000-0000000064086FFF 0000000000000001 > 000000000000000F > > BS_data : 10,775 Pages (44,134,400) > available : 407,182 Pages (1,667,817,472) > > Now my question is. > After my function is done shouldn't the memory that was converted to > BS_Data, and that was released, go back to the "available memory" memory > type ? Since this is not happening seems there is some leak at some place. > I did a test executing the application 10k times, and BS_Data keeps > increasing and available keeps decreasing. > > At the and the result is: > > LoaderData: 26 Pages (106,496) > BS_data : 14,201 Pages (58,167,296) > available : 403,755 Pages (1,653,780,480) > > > Just one additional information. Some memory was stolen from LoaderData > memory type. It was bigger at the first execution: > > LoaderData: 649 Pages (2,658,304) > > > Any comments are well received. > > Thanks and regards > Rafael R. Machado > > > Em qua, 1 de jun de 2016 às 16:52, Rafael Machado < > [email protected]> escreveu: > > > Amazing explanation Aaron!! > > Thanks a lot!! > > > > Rafael R. Machado > > > > Em qua, 1 de jun de 2016 às 15:29, <[email protected]> escreveu: > > > >> Hi Rafael, > >> > >> I think your application is exposing some of the rough edges of the EDK2 > >> memory allocation routines. > >> > >> Your application is calling allocatepool for boot servies data. It is > >> first doing this to get a handle buffer of GOP devices, then it is doing > >> this to create a Blt buffer. > >> > >> Your application does free this memory, but once you understand how the > >> internals of the edk2 memory allocation work, the behavior is as > expected. > >> e > >> When you call allocate pool, if the amount of memory that you are trying > >> to allocate is greater than a page then the edk2 will round the amount > of > >> memory that you are requesting up to the next page and just allocate > pages > >> of memory to you. > >> > >> If you call allocate pool, and the amount of memory you are trying to > >> allocate is less than a page of memory, the edk2 will look at the > current > >> sets of memory that are of the type you are trying to allocate > >> (EfiBootServicesData in your case). If it can find an available amount > of > >> memory in its previously allocated pages, it will return that memory to > >> you. If it cannot find that amount of memory, it will convert available > >> pages of memory into the type of memory and give that to you. > >> > >> If your example code's case, you allocate for a handle buffer, then you > >> allocate for a gop blt buffer, then you call blt (which may perform > memory > >> allocations too). In all of this, you may have exhausted the amount of > >> BootServicesData pages that were currently available and caused the > system > >> to convert available memory into Boot Services Data memory. > >> > >> I hope this helps explain the behavior that you are seeing. > >> > >> > >> > >> > >> From: Andrew Fish <[email protected]> > >> To: Rafael Machado <[email protected]> > >> Cc: "Carsey, Jaben" <[email protected]>, " > >> [email protected]" <[email protected]> > >> Date: 06/01/2016 11:16 AM > >> Subject: Re: [edk2] Memory Consumption after BLT (GOP) > >> Sent by: "edk2-devel" <[email protected]> > >> ------------------------------ > >> > >> > >> > >> > >> > On Jun 1, 2016, at 11:10 AM, Rafael Machado < > >> [email protected]> wrote: > >> > > >> > The draw application is this one: > >> > > >> > >> Yikes that is hard for me to read without indentation.... > >> > >> Why don't you try putting some of the GraphicProtocol calls in a loop to > >> see if that leaks more memory? > >> > >> Thanks, > >> > >> Andrew Fish > >> > >> > #include <Uefi.h> > >> > #include <Library/UefiBootServicesTableLib.h> > >> > #include <Library/MemoryAllocationLib.h> > >> > #include <Library/UefiLib.h> > >> > #include <Library/PrintLib.h> > >> > #include <Library/DebugLib.h> > >> > #include <Protocol/GraphicsOutput.h> > >> > #include <Protocol/EdidActive.h> > >> > > >> > #define BoxWidth 100 > >> > #define BoxHeight 100 > >> > > >> > EFI_STATUS PrintImage(EFI_HANDLE ImageHandle, UINTN ImagePositionX, > >> UINTN > >> > ImagePositionY){ > >> > > >> > UINTN Size; > >> > EFI_STATUS Status; > >> > UINTN HandleIndex = 0; > >> > EFI_HANDLE *HandleArray = NULL; > >> > EFI_GRAPHICS_OUTPUT_PROTOCOL *GraphicProtocol = NULL; > >> > EFI_GUID gGraphicalProtocol = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID; > >> > EFI_GUID gEdidActivated = EFI_EDID_ACTIVE_PROTOCOL_GUID; > >> > EFI_EDID_ACTIVE_PROTOCOL *EdidActivated = NULL; > >> > EFI_GRAPHICS_OUTPUT_BLT_PIXEL* inMemoryImage = NULL; > >> > > >> > Status = gBS->LocateHandleBuffer(ByProtocol, > >> > &gEfiGraphicsOutputProtocolGuid, > >> > NULL, > >> > &Size, > >> > &HandleArray); > >> > > >> > if(!EFI_ERROR(Status)) > >> > { > >> > for(HandleIndex=0; HandleIndex<Size; HandleIndex++) > >> > { > >> > > >> > Status = gBS->OpenProtocol(HandleArray[HandleIndex], > >> > &gGraphicalProtocol, > >> > (VOID**) &GraphicProtocol, > >> > ImageHandle, > >> > NULL, > >> > EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL); > >> > > >> > if(EFI_ERROR(Status)){ > >> > > >> > gBS->CloseProtocol(HandleArray[HandleIndex], > >> > &gGraphicalProtocol, > >> > ImageHandle, > >> > NULL); > >> > > >> > GraphicProtocol = NULL; > >> > > >> > continue; > >> > } else { > >> > > >> > // Verifies if current handle corresponds to current video > >> > Status = gBS->OpenProtocol(HandleArray[HandleIndex], > >> > &gEdidActivated, > >> > (VOID**) &EdidActivated, > >> > ImageHandle, > >> > NULL, > >> > EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL); > >> > > >> > if(EFI_ERROR(Status)){ > >> > > >> > gBS->CloseProtocol(HandleArray[HandleIndex], > >> > &gGraphicalProtocol, > >> > ImageHandle, > >> > NULL); > >> > > >> > GraphicProtocol = NULL; > >> > > >> > gBS->CloseProtocol(HandleArray[HandleIndex], > >> > &gEdidActivated, > >> > ImageHandle, > >> > NULL); > >> > > >> > EdidActivated = NULL; > >> > > >> > continue; > >> > } else { > >> > break; > >> > } > >> > } > >> > } > >> > > >> > if(!EFI_ERROR(Status)) > >> > { > >> > Status = gBS->AllocatePool(EfiBootServicesData, > >> > sizeof(EFI_GRAPHICS_OUTPUT_BLT_PIXEL) * > >> > BoxWidth * BoxHeight, > >> > &inMemoryImage); > >> > > >> > if(!EFI_ERROR(Status)) > >> > { > >> > > >> > gBS->SetMem(inMemoryImage, > >> > sizeof(EFI_GRAPHICS_OUTPUT_BLT_PIXEL) * > >> > BoxWidth * BoxHeight, > >> > 0xFF); > >> > > >> > Status = GraphicProtocol->Blt(GraphicProtocol, > >> > inMemoryImage, > >> > EfiBltBufferToVideo, > >> > 0, > >> > 0, > >> > ImagePositionX, > >> > ImagePositionY, > >> > BoxWidth, > >> > BoxHeight, > >> > 0); > >> > > >> > if(EFI_ERROR(Status)){ > >> > Print(L"Fail to print Image"); > >> > goto CLEAR; > >> > } > >> > } else { > >> > Print(L"Fail to allocate buffer"); > >> > goto CLEAR; > >> > } > >> > > >> > }else{ > >> > Print(L"Fail to locate GraphicIoProtocol devices"); > >> > goto CLEAR; > >> > } > >> > } > >> > > >> > CLEAR: > >> > > >> > if(inMemoryImage != NULL) { > >> > FreePool(inMemoryImage); > >> > inMemoryImage = NULL; > >> > } > >> > > >> > if(GraphicProtocol != NULL) { > >> > > >> > Status = gBS->CloseProtocol(HandleArray[HandleIndex], > >> > &gGraphicalProtocol, > >> > ImageHandle, > >> > NULL); > >> > > >> > GraphicProtocol = NULL; > >> > } > >> > > >> > if(EdidActivated != NULL) { > >> > > >> > Status = gBS->CloseProtocol(HandleArray[HandleIndex], > >> > &gEdidActivated, > >> > ImageHandle, > >> > NULL); > >> > > >> > EdidActivated = NULL; > >> > } > >> > > >> > if(HandleArray != NULL) { > >> > FreePool(HandleArray); > >> > HandleArray = NULL; > >> > } > >> > > >> > return Status; > >> > } > >> > > >> > > >> > EFI_STATUS testeMain(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE > >> *SystemTable) > >> > { > >> > return PrintImage(ImageHandle, 50, 50); > >> > } > >> > > >> > > >> > Unfortunately I don't have this systems GOP driver code. > >> > > >> > Thanks and Regards. > >> > Rafael R. Machado > >> > > >> > Em qua, 1 de jun de 2016 às 15:02, Carsey, Jaben < > >> [email protected]> > >> > escreveu: > >> > > >> >> It’s possible that you found a leak in the driver. Have you double > >> >> checked your drawing app to be sure it’s not leaking anything? Do > you > >> have > >> >> source for the driver? > >> >> > >> >> -Jaben > >> >> > >> >> > >> >> From: Rafael Machado [mailto:[email protected] > <[email protected]> > >> <[email protected]>] > >> >> Sent: Wednesday, June 01, 2016 11:00 AM > >> >> To: Carsey, Jaben <[email protected]> > >> >> Cc: [email protected] > >> >> Subject: Re: [edk2] Memory Consumption after BLT (GOP) > >> >> Importance: High > >> >> > >> >> I did that :) > >> >> > >> >> To get the available memory I did the following function: > >> >> > >> >> EFI_STATUS CalculateAvaiableMemoryForDebug (VOID) > >> >> { > >> >> > >> >> EFI_STATUS Status = EFI_SUCCESS; > >> >> EFI_MEMORY_DESCRIPTOR *MemMap = NULL; > >> >> EFI_MEMORY_DESCRIPTOR *Desc; > >> >> UINTN DescriptorSize = 0; > >> >> UINT32 DescriptorVersion = 0; UINTN MapKey; > >> >> UINTN MemMapSize = sizeof(EFI_MEMORY_DESCRIPTOR); > >> >> UINTN Index = 0; > >> >> UINTN NoDesc = 0; > >> >> > >> >> > >> >> UINTN TotalOfPages = 0; > >> >> UINTN TotalOfFreePages = 0; > >> >> UINTN TotalOfBlocks = 0; > >> >> UINTN CurrentBlock = 0; > >> >> > >> >> > >> >> > >> >> if (MemMap != NULL) { > >> >> FreePool(MemMap); > >> >> } > >> >> > >> >> Status = gBS->AllocatePool(EfiBootServicesData, > >> >> MemMapSize, > >> >> (VOID**)&MemMap); > >> >> > >> >> if (Status == EFI_SUCCESS) { > >> >> Status = gBS->GetMemoryMap(&MemMapSize, > >> >> MemMap, > >> >> &MapKey, > >> >> &DescriptorSize, > >> >> &DescriptorVersion); > >> >> } else { > >> >> Status = EFI_DEVICE_ERROR; > >> >> } > >> >> > >> >> if (Status == EFI_SUCCESS) { > >> >> > >> >> CurrentBlock = 1; > >> >> Desc = MemMap; > >> >> NoDesc = MemMapSize / DescriptorSize; > >> >> > >> >> for(Index = 0; Index < NoDesc; Index++) { > >> >> > >> >> if (Desc->Type == EfiConventionalMemory) { > >> >> TotalOfFreePages += (UINTN) Desc->NumberOfPages; > >> >> TotalOfBlocks++; > >> >> } > >> >> > >> >> TotalOfPages += (UINTN) Desc->NumberOfPages; > >> >> > >> >> Desc = NextMemoryDescriptor (Desc, DescriptorSize); > >> >> } > >> >> > >> >> } else { > >> >> Status = EFI_DEVICE_ERROR; > >> >> } > >> >> > >> >> if (MemMap != NULL) { > >> >> FreePool(MemMap); > >> >> } > >> >> > >> >> DEBUG_LOG(DbgFileModeMemoryAvailable, > >> >> DEBUG_LEVEL_DUMP, > >> >> L"-----Available Pages: %ld --------\n", > >> >> TotalOfFreePages); > >> >> > >> >> > >> >> return Status; > >> >> } > >> >> > >> >> The available memory also decreases in this case. > >> >> I didn't find any leak at this function too. > >> >> > >> >> I'm considering some problem with other driver that is causing this > >> >> memory decrease during the execution time. > >> >> > >> >> Thanks > >> >> Rafael R. Machado > >> >> > >> >> Em qua, 1 de jun de 2016 às 14:53, Carsey, Jaben < > >> [email protected] > >> >> <mailto:[email protected] <[email protected]> < > [email protected]>>> escreveu: > >> >> Well... sadly the best way to debug would be to get the memory map > >> >> yourself, run your graphical operation, and then compare all inside > the > >> >> same program (assuming that you allocate no memory within your memory > >> map > >> >> acquisitions). > >> >> > >> >> -Jaben > >> >> > >> >>> -----Original Message----- > >> >>> From: edk2-devel [mailto:[email protected] > <[email protected]> > >> <[email protected]><mailto: > >> >> [email protected]>] On Behalf Of > >> >>> Rafael Machado > >> >>> Sent: Wednesday, June 01, 2016 10:33 AM > >> >>> To: Carsey, Jaben <[email protected]< > >> mailto:[email protected] <[email protected]> < > [email protected]> > >> >>>> > >> >>> Cc: [email protected]<mailto:[email protected] > <[email protected]> > >> <[email protected]>> > >> >>> Subject: Re: [edk2] Memory Consumption after BLT (GOP) > >> >>> Importance: High > >> >>> > >> >>> The system has one page decreased after some executions. > >> >>> I used the following script to check this: > >> >>> > >> >>> FS1: > >> >>> echo -off > >> >>> memmap >> memmapShellBefore.txt > >> >>> for %a run (1 10) > >> >>> TestesImagemBMP.efi > >> >>> memmap >> memmapShellAfter_%a.txt > >> >>> endfor > >> >>> > >> >>> The decrease happened at execution number 4 and 9 > >> >>> From execution 1 to 2, and 2 to 3 no decrease was detected. The > same > >> >> with > >> >>> execution 4 to 5, 5 to 6 6 to 7 and 7 to 8 > >> >>> > >> >>> I thought that since I'm using the script no command log was saved > by > >> the > >> >>> shell application. > >> >>> At the begin I added a echo -off to avoid scroll. > >> >>> > >> >>> > >> >>> Thanks and Regards > >> >>> Rafael R. Machado > >> >>> > >> >>> Em qua, 1 de jun de 2016 às 14:13, Carsey, Jaben < > >> [email protected] > >> >> <mailto:[email protected] <[email protected]> < > [email protected]>>> > >> >>> escreveu: > >> >>> > >> >>>> Does the pattern continue or level off after time? > >> >>>> > >> >>>> I ask as the shell will make some allocations to save things like > >> >> command > >> >>>> history and output history for up/down page up/page down support... > >> >>>> > >> >>>> -Jaben > >> >>>> > >> >>>>> On Jun 1, 2016, at 10:10 AM, Rafael Machado < > >> >>>> [email protected]<mailto: > >> >> [email protected]>> wrote: > >> >>>>> > >> >>>>> Hi Everyone. > >> >>>>> > >> >>>>> I'm doing some tests related to the GOP and graphical > applications. > >> >>>>> What I've seeing is that after calling the GOP->BLT several times > >> the > >> >>>>> available memory from the system decrease. > >> >>>>> > >> >>>>> For example. When the system just boot I have the following at the > >> >> uefi > >> >>>>> shell memmap command: > >> >>>>> > >> >>>>> reserved : 124 Pages (507,904) > >> >>>>> LoaderCode: 186 Pages (761,856) > >> >>>>> LoaderData: 24 Pages (98,304) > >> >>>>> BS_code : 1,719 Pages (7,041,024) > >> >>>>> BS_data : 10,774 Pages (44,130,304) > >> >>>>> RT_code : 256 Pages (1,048,576) > >> >>>>> RT_data : 660 Pages (2,703,360) > >> >>>>> *available : 407,184 Pages (1,667,825,664)* > >> >>>>> ACPI_recl : 96 Pages (393,216) > >> >>>>> ACPI_NVS : 129 Pages (528,384) > >> >>>>> MemMapIO : 1 Pages (4,096) > >> >>>>> Total Memory: 1,644 MB (1,724,530,688) Bytes > >> >>>>> > >> >>>>> After executing a sample application that just draw a white box 10 > >> >>>> times, I > >> >>>>> have the following: > >> >>>>> > >> >>>>> reserved : 124 Pages (507,904) > >> >>>>> LoaderCode: 186 Pages (761,856) > >> >>>>> LoaderData: 24 Pages (98,304) > >> >>>>> BS_code : 1,719 Pages (7,041,024) > >> >>>>> BS_data : 10,776 Pages (44,138,496) > >> >>>>> RT_code : 256 Pages (1,048,576) > >> >>>>> RT_data : 660 Pages (2,703,360) > >> >>>>> * available : 407,182 Pages (1,667,817,472)* > >> >>>>> ACPI_recl : 96 Pages (393,216) > >> >>>>> ACPI_NVS : 129 Pages (528,384) > >> >>>>> MemMapIO : 1 Pages (4,096) > >> >>>>> Total Memory: 1,644 MB (1,724,530,688) Bytes > >> >>>>> > >> >>>>> > >> >>>>> So the situation is that on a Graphical UEFI application, there > is a > >> >>>>> possibility of getting too much memory. > >> >>>>> As much as I execute the application the available memory keeps > >> >>>> decreasing. > >> >>>>> > >> >>>>> Could someone please help me to find some problem on the sample > >> >>>> application > >> >>>>> code ? > >> >>>>> > >> >>>>> " > >> >>>>> #include <Uefi.h> > >> >>>>> #include <Library/UefiBootServicesTableLib.h> > >> >>>>> #include <Library/MemoryAllocationLib.h> > >> >>>>> #include <Library/UefiLib.h> > >> >>>>> #include <Library/PrintLib.h> > >> >>>>> #include <Library/DebugLib.h> > >> >>>>> #include <Protocol/GraphicsOutput.h> > >> >>>>> #include <Protocol/EdidActive.h> > >> >>>>> > >> >>>>> #define BoxWidth 100 > >> >>>>> #define BoxHeight 100 > >> >>>>> > >> >>>>> EFI_STATUS PrintImage(EFI_HANDLE ImageHandle, UINTN > ImagePositionX, > >> >>> UINTN > >> >>>>> ImagePositionY){ > >> >>>>> > >> >>>>> UINTN Size; > >> >>>>> EFI_STATUS Status; > >> >>>>> UINTN HandleIndex = 0; > >> >>>>> EFI_HANDLE *HandleArray = NULL; > >> >>>>> EFI_GRAPHICS_OUTPUT_PROTOCOL *GraphicProtocol = NULL; > >> >>>>> EFI_GUID gGraphicalProtocol = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID; > >> >>>>> EFI_GUID gEdidActivated = EFI_EDID_ACTIVE_PROTOCOL_GUID; > >> >>>>> EFI_EDID_ACTIVE_PROTOCOL *EdidActivated = NULL; > >> >>>>> EFI_GRAPHICS_OUTPUT_BLT_PIXEL* inMemoryImage = NULL; > >> >>>>> > >> >>>>> Status = gBS->LocateHandleBuffer(ByProtocol, > >> >>>>> &gEfiGraphicsOutputProtocolGuid, > >> >>>>> NULL, > >> >>>>> &Size, > >> >>>>> &HandleArray); > >> >>>>> > >> >>>>> if(!EFI_ERROR(Status)) > >> >>>>> { > >> >>>>> for(HandleIndex=0; HandleIndex<Size; HandleIndex++) > >> >>>>> { > >> >>>>> > >> >>>>> Status = gBS->OpenProtocol(HandleArray[HandleIndex], > >> >>>>> &gGraphicalProtocol, > >> >>>>> (VOID**) &GraphicProtocol, > >> >>>>> ImageHandle, > >> >>>>> NULL, > >> >>>>> EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL); > >> >>>>> > >> >>>>> if(EFI_ERROR(Status)){ > >> >>>>> > >> >>>>> gBS->CloseProtocol(HandleArray[HandleIndex], > >> >>>>> &gGraphicalProtocol, > >> >>>>> ImageHandle, > >> >>>>> NULL); > >> >>>>> > >> >>>>> GraphicProtocol = NULL; > >> >>>>> > >> >>>>> continue; > >> >>>>> } else { > >> >>>>> > >> >>>>> // Verifies if current handle corresponds to current video > >> >>>>> Status = gBS->OpenProtocol(HandleArray[HandleIndex], > >> >>>>> &gEdidActivated, > >> >>>>> (VOID**) &EdidActivated, > >> >>>>> ImageHandle, > >> >>>>> NULL, > >> >>>>> EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL); > >> >>>>> > >> >>>>> if(EFI_ERROR(Status)){ > >> >>>>> > >> >>>>> gBS->CloseProtocol(HandleArray[HandleIndex], > >> >>>>> &gGraphicalProtocol, > >> >>>>> ImageHandle, > >> >>>>> NULL); > >> >>>>> > >> >>>>> GraphicProtocol = NULL; > >> >>>>> > >> >>>>> gBS->CloseProtocol(HandleArray[HandleIndex],>> >>>>> > &gEdidActivated, > >> >>>>> ImageHandle, > >> >>>>> NULL); > >> >>>>> > >> >>>>> EdidActivated = NULL; > >> >>>>> > >> >>>>> continue; > >> >>>>> } else { > >> >>>>> break; > >> >>>>> } > >> >>>>> } > >> >>>>> } > >> >>>>> > >> >>>>> if(!EFI_ERROR(Status)) > >> >>>>> { > >> >>>>> Status = gBS->AllocatePool(EfiBootServicesData, > >> >>>>> sizeof(EFI_GRAPHICS_OUTPUT_BLT_PIXEL) * > >> >>>>> BoxWidth * BoxHeight, > >> >>>>> &inMemoryImage); > >> >>>>> > >> >>>>> if(!EFI_ERROR(Status)) > >> >>>>> { > >> >>>>> > >> >>>>> gBS->SetMem(inMemoryImage, > >> >>>>> sizeof(EFI_GRAPHICS_OUTPUT_BLT_PIXEL) * > >> >>>>> BoxWidth * BoxHeight, > >> >>>>> 0xFF); > >> >>>>> > >> >>>>> Status = GraphicProtocol->Blt(GraphicProtocol, > >> >>>>> inMemoryImage, > >> >>>>> EfiBltBufferToVideo, > >> >>>>> 0, > >> >>>>> 0, > >> >>>>> ImagePositionX, > >> >>>>> ImagePositionY, > >> >>>>> BoxWidth, > >> >>>>> BoxHeight, > >> >>>>> 0); > >> >>>>> > >> >>>>> if(EFI_ERROR(Status)){ > >> >>>>> Print(L"Fail to print Image"); > >> >>>>> goto CLEAR; > >> >>>>> } > >> >>>>> } else { > >> >>>>> Print(L"Fail to allocate buffer"); > >> >>>>> goto CLEAR; > >> >>>>> } > >> >>>>> > >> >>>>> }else{ > >> >>>>> Print(L"Fail to locate GraphicIoProtocol devices"); > >> >>>>> goto CLEAR; > >> >>>>> } > >> >>>>> } > >> >>>>> > >> >>>>> CLEAR: > >> >>>>> > >> >>>>> if(inMemoryImage != NULL) { > >> >>>>> FreePool(inMemoryImage); > >> >>>>> inMemoryImage = NULL; > >> >>>>> } > >> >>>>> > >> >>>>> if(GraphicProtocol != NULL) { > >> >>>>> > >> >>>>> Status = gBS->CloseProtocol(HandleArray[HandleIndex], > >> >>>>> &gGraphicalProtocol, > >> >>>>> ImageHandle, > >> >>>>> NULL); > >> >>>>> > >> >>>>> GraphicProtocol = NULL; > >> >>>>> } > >> >>>>> > >> >>>>> if(EdidActivated != NULL) { > >> >>>>> > >> >>>>> Status = gBS->CloseProtocol(HandleArray[HandleIndex], > >> >>>>> &gEdidActivated, > >> >>>>> ImageHandle, > >> >>>>> NULL); > >> >>>>> > >> >>>>> EdidActivated = NULL; > >> >>>>> } > >> >>>>> > >> >>>>> if(HandleArray != NULL) { > >> >>>>> FreePool(HandleArray); > >> >>>>> HandleArray = NULL; > >> >>>>> } > >> >>>>> > >> >>>>> return Status; > >> >>>>> } > >> >>>>> > >> >>>>> > >> >>>>> EFI_STATUS testMain(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE > >> >>>> *SystemTable) > >> >>>>> { > >> >>>>> return PrintImage(ImageHandle, 50, 50); > >> >>>>> } > >> >>>>> " > >> >>>>> > >> >>>>> > >> >>>>> Any help will be really useful. > >> >>>>> > >> >>>>> Thanks and Regards > >> >>>>> Rafael R. Machado > >> >>>>> _______________________________________________ > >> >>>>> edk2-devel mailing list > >> >>>>> [email protected]<mailto:[email protected] > <[email protected]> > >> <[email protected]>> > >> >>>>> https://lists.01.org/mailman/listinfo/edk2-devel > >> >>>> > >> >>> _______________________________________________ > >> >>> edk2-devel mailing list > >> >>> [email protected]<mailto:[email protected] > <[email protected]> > >> <[email protected]>> > >> >>> https://lists.01.org/mailman/listinfo/edk2-devel > >> >> _______________________________________________ > >> >> edk2-devel mailing list > >> >> [email protected] > >> >> https://lists.01.org/mailman/listinfo/edk2-devel > >> >> > >> > _______________________________________________ > >> > edk2-devel mailing list > >> > [email protected] > >> > https://lists.01.org/mailman/listinfo/edk2-devel > >> > >> _______________________________________________ > >> edk2-devel mailing list > >> [email protected] > >> https://lists.01.org/mailman/listinfo/edk2-devel > >> > >> > >> > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel > > > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
