Neeraj Ladkani | 30 Oct 16:53 2012
Picon

Re: [edk2] Both legacy OpROM and UEFI BSD loaded

System can boot either in Legacy or in UEFI mode… so platform bios can give a option to user to choose the mode in which they want network / storage oprom to run. 


Exception of this could be a need of preboot features( e.g. CLP ) if which might be implemented only in one mode of oprom,

 


On Tue, Oct 30, 2012 at 8:57 PM, <edk2-devel-request <at> lists.sourceforge.net> wrote:
Send edk2-devel mailing list submissions to
        edk2-devel <at> lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/edk2-devel
or, via email, send a message with subject or body 'help' to
        edk2-devel-request <at> lists.sourceforge.net

You can reach the person managing the list at
        edk2-devel-owner <at> lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of edk2-devel digest..."


Today's Topics:

   1. Re: EFI_FILE_PROTOCOL.Delete() failing with
      EFI_WARN_DELETE_FAILURE (Kashif Memon)
   2. Re: [PATCH v3 3/4] OvmfPkg: Add LoadLinuxLib library
      implementation (Laszlo Ersek)
   3. Re: Both legacy OpROM and UEFI BSD loaded (Joe Thomas)


----------------------------------------------------------------------

Message: 1
Date: Mon, 29 Oct 2012 18:18:50 -0700
From: Kashif Memon <kashif <at> nvelo.com>
Subject: Re: [edk2] EFI_FILE_PROTOCOL.Delete() failing with
        EFI_WARN_DELETE_FAILURE
To: edk2-devel <at> lists.sourceforge.net
Message-ID:
        <CAH38s=vt9b4f=0gUCnEsXt4tZGoJ27aaq3Zq6wnDP=uA5_QYUQ <at> mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Thanks for all the replies.
Actually the problem was not the permissions, since I had tried the
read+write combination already.

The problem was the variable type of the "root" variable.

Here is the original declaration that I was using that caused the problem:
    EFI_FILE_HANDLE                   root;

Here is the declaration that worked:
    EFI_FILE_PROTOCOL                 root;

Thanks.
Kashif...

On Fri, Oct 26, 2012 at 4:13 AM, duck wilson <duck.54321 <at> gmail.com> wrote:

> Opening the file in create mode is the problem. Change this:
>
>
>     status = root->Open (
>                    root,
>                    file,
>                    L"\\EFI\\BOOT\\FILE.TXT",
>                    EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE |
> EFI_FILE_MODE_CREATE,
>                    0
>                    );
>
> to this:
>
>
>     status = root->Open (
>                    root,
>                    file,
>                    L"\\EFI\\BOOT\\FILE.TXT",
>                    EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE,
>                    0
>                    );
>
>
>
> On Wed, Oct 24, 2012 at 10:59 AM, Kashif Memon <kashif <at> nvelo.com> wrote:
>
>> Hello,
>>
>> I am trying to delete a file on the system partition from an UEFI
>> app using the Delete function within EFI_FILE_PROTOCOL, but it is returning
>> with a EFI_WARN_DELETE_FAILURE.
>>
>> I can read the file without any problem, but delete doesn't seem to work.
>>
>> Any ideas?
>>
>> Here is the code:
>>     // get the handle for EFI Simple File System protocol
>>     status = gBS->LocateDevicePath (
>>                   &gEfiSimpleFileSystemProtocolGuid,
>>                   &ourDevicePath,
>>                   &handle
>>                   );
>>     if (status != EFI_SUCCESS) {
>>         return (status);
>>     }
>>
>>     // get the pointer for the volume
>>     status = gBS->HandleProtocol (
>>                   handle,
>>                   &gEfiSimpleFileSystemProtocolGuid,
>>                   &volume
>>                   );
>>     if (status != EFI_SUCCESS) {
>>         return (status);
>>     }
>>
>>     // Open the root directory of the volume
>>     root = NULL;
>>     status = volume->OpenVolume (
>>                      volume,
>>                      &root
>>                      );
>>     if ((status != EFI_SUCCESS) || (root == NULL)) {
>>         return (status);
>>     }
>>
>>     // Open file.txt file
>>     status = root->Open (
>>                    root,
>>                    file,
>>                    L"\\EFI\\BOOT\\FILE.TXT",
>>                    EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE |
>> EFI_FILE_MODE_CREATE,
>>                    0
>>                    );
>>     if (status != EFI_SUCCESS) {
>>         return (status);
>>     }
>>
>>     // Delete the file
>>     status = (*file)->Delete (*file);
>>     if (status != EFI_SUCCESS) {
>>         Print (L"Deletion failed, status = %d.\n",
>>                status);
>>         return (status);
>>     }
>>
>> Thanks.
>> Kashif...
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel <at> lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> edk2-devel mailing list
> edk2-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 2
Date: Tue, 30 Oct 2012 12:46:03 +0100
From: Laszlo Ersek <lersek <at> redhat.com>
Subject: Re: [edk2] [PATCH v3 3/4] OvmfPkg: Add LoadLinuxLib library
        implementation
To: Jordan Justen <jordan.l.justen <at> intel.com>
Cc: edk2-devel <at> lists.sourceforge.net, Matt Fleming
        <matt.fleming <at> intel.com>
Message-ID: <508FBDFB.7040609 <at> redhat.com>
Content-Type: text/plain; charset=ISO-8859-1

comments in-line

On 10/26/12 19:35, Jordan Justen wrote:

> +STATIC
> +VOID
> +SetupLinuxMemmap (
> +  IN OUT struct boot_params        *Bp
> +  )
> +{
> +  EFI_STATUS                           Status;
> +  UINT8                                TmpMemoryMap[1];
> +  UINTN                                MapKey;
> +  UINTN                                DescriptorSize;
> +  UINT32                               DescriptorVersion;
> +  UINTN                                MemoryMapSize;
> +  EFI_MEMORY_DESCRIPTOR                *MemoryMap;
> +  EFI_MEMORY_DESCRIPTOR                *MemoryMapPtr;
> +  UINTN                                Index;
> +  struct efi_info                      *Efi;
> +  struct e820_entry                    *LastE820;
> +  struct e820_entry                    *E820;
> +  UINTN                                E820EntryCount;
> +  EFI_PHYSICAL_ADDRESS                 LastEndAddr;
> +
> +  //
> +  // Get System MemoryMapSize
> +  //
> +  MemoryMapSize = sizeof (TmpMemoryMap);
> +  Status = gBS->GetMemoryMap (
> +                  &MemoryMapSize,
> +                  (EFI_MEMORY_DESCRIPTOR *)TmpMemoryMap,
> +                  &MapKey,
> +                  &DescriptorSize,
> +                  &DescriptorVersion
> +                  );
> +  ASSERT (Status == EFI_BUFFER_TOO_SMALL);
> +  //
> +  // Enlarge space here, because we will allocate pool now.
> +  //
> +  MemoryMapSize += EFI_PAGE_SIZE;
> +  MemoryMap = AllocatePool (MemoryMapSize);
> +  ASSERT (MemoryMap != NULL);
> +
> +  //
> +  // Get System MemoryMap
> +  //
> +  Status = gBS->GetMemoryMap (
> +                  &MemoryMapSize,
> +                  MemoryMap,
> +                  &MapKey,
> +                  &DescriptorSize,
> +                  &DescriptorVersion
> +                  );
> +  ASSERT_EFI_ERROR (Status);
> +
> +  LastE820 = &Bp->e820_map[0];

LastE820 here should be set to NULL...

> +  E820 = &Bp->e820_map[0];
> +  E820EntryCount = 0;
> +  LastEndAddr = 0;
> +  MemoryMapPtr = MemoryMap;
> +  for (Index = 0; Index < (MemoryMapSize / DescriptorSize); Index++) {
> +    UINTN E820Type = 0;
> +
> +    if (MemoryMap->NumberOfPages == 0) {
> +      continue;
> +    }
> +
> +    switch(MemoryMap->Type) {
> +    case EfiReservedMemoryType:
> +    case EfiRuntimeServicesCode:
> +    case EfiRuntimeServicesData:
> +    case EfiMemoryMappedIO:
> +    case EfiMemoryMappedIOPortSpace:
> +    case EfiPalCode:
> +      E820Type = E820_RESERVED;
> +      break;
> +
> +    case EfiUnusableMemory:
> +      E820Type = E820_UNUSABLE;
> +      break;
> +
> +    case EfiACPIReclaimMemory:
> +      E820Type = E820_ACPI;
> +      break;
> +
> +    case EfiLoaderCode:
> +    case EfiLoaderData:
> +    case EfiBootServicesCode:
> +    case EfiBootServicesData:
> +    case EfiConventionalMemory:
> +      E820Type = E820_RAM;
> +      break;
> +
> +    case EfiACPIMemoryNVS:
> +      E820Type = E820_NVS;
> +      break;
> +
> +    default:
> +      DEBUG ((
> +        EFI_D_ERROR,
> +        "Invalid EFI memory descriptor type (0x%x)!\n",
> +        MemoryMap->Type
> +        ));
> +      continue;
> +    }
> +
> +    if ((LastE820 != NULL) &&
> +        (LastE820->type == (UINT32) E820Type) &&

... because here "LastE820->type" should not even be investigated unless
we have added at least one entry. (Currently, the contents of *LastE820
on the first occasion we reach this code is indeterminate, it is
something we copied from the host into the kernel setup buffer via fw_cfg.)

(I think Matt mentioned something like this last time -- apologies for
not reviewing this function more thoroughly in the v2 posting!)

> +        (MemoryMap->PhysicalStart == LastEndAddr)) {
> +      LastE820->size += EFI_PAGES_TO_SIZE (MemoryMap->NumberOfPages);

In this block "LastEndAddr" should be increased too, by the same number
of bytes.

> +    } else {
> +      if (E820EntryCount >= (sizeof (Bp->e820_map) / sizeof (Bp->e820_map[0]))) {
> +        break;
> +      }
> +      E820->type = (UINT32) E820Type;
> +      E820->addr = MemoryMap->PhysicalStart;
> +      E820->size = EFI_PAGES_TO_SIZE (MemoryMap->NumberOfPages);
> +      LastE820 = E820;
> +      LastEndAddr = E820->addr + E820->size;
> +      E820++;
> +      E820EntryCount++;
> +    }
> +
> +    //
> +    // Get next item
> +    //
> +    MemoryMap = (EFI_MEMORY_DESCRIPTOR *)((UINTN)MemoryMap + DescriptorSize);
> +  }
> +  Bp->e820_entries = (UINT8) E820EntryCount;
> +
> +  Efi = &Bp->efi_info;
> +  Efi->efi_systab = (UINT32)(UINTN) gST;
> +  Efi->efi_memdesc_size = (UINT32) DescriptorSize;
> +  Efi->efi_memdesc_version = DescriptorVersion;
> +  Efi->efi_memmap = (UINT32)(UINTN) MemoryMapPtr;
> +  Efi->efi_memmap_size = (UINT32) MemoryMapSize;
> +#ifdef MDE_CPU_IA32
> +  Efi->efi_loader_signature = SIGNATURE_32 ('E', 'L', '3', '2');
> +#else
> +  Efi->efi_systab_hi = ((UINT64)(UINTN) gST) >> 32;
> +  Efi->efi_memmap_hi = ((UINT64)(UINTN) MemoryMapPtr) >> 32;
> +  Efi->efi_loader_signature = SIGNATURE_32 ('E', 'L', '6', '4');
> +#endif
> +
> +  gBS->ExitBootServices (gImageHandle, MapKey);
> +}

No more comments.

*If* Matt finds no problems, I propose to commit this series, and fix
the above in a small follow-up patch. On that condition:

Reviewed-by: Laszlo Ersek <lersek <at> redhat.com>

Laszlo



------------------------------

Message: 3
Date: Tue, 30 Oct 2012 09:26:58 -0600
From: Joe Thomas <Joe.Thomas <at> dothill.com>
Subject: Re: [edk2] Both legacy OpROM and UEFI BSD loaded
To: "edk2-devel <at> lists.sourceforge.net"
        <edk2-devel <at> lists.sourceforge.net>
Message-ID:
        <235852D532FB204FB039DAF645E587C7250C700350 <at> dc-ex1.power.com>
Content-Type: text/plain; charset="us-ascii"

Our experience is that every platform BIOS will do it differently...

Expect that both legacy and UEFI will run, that you have no control over which runs first, and that calls may alternate between one and the other...

In other words, plan for the worst and you'll avoid a lot of debugging headaches down the road...
[One platform implemented CSM and alternated calls between legacy INT13 and UEFI BlockIo - really messes up the device registers when this happens... Big issues with boot manager on this system as well...]

// Joseph Thomas
// Principal Software Engineer
// Dot Hill Systems
// 2905 NorthWest Blvd., Suite 20
// Plymouth, MN 55441
// 763.226.2640

From: Li, Elvin [mailto:elvin.li <at> intel.com]
Sent: Thursday, October 25, 2012 2:58 AM
To: edk2-devel <at> lists.sourceforge.net
Subject: Re: [edk2] Both legacy OpROM and UEFI BSD loaded

We can run both UEFI and Legacy OpROM start in preboot, but it will bring potential problem as device configuration will be possibly messed up, unless the BIOS or UEFI/Legacy OpROM aware this. BlockIo protocol is used to access storage device in preboot phase, BlockIo protocol is based on either UEFI or Legacy OpROM, not possibly both.

From: Prakash, Sathya [mailto:Sathya.Prakash <at> lsi.com]
Sent: Thursday, October 25, 2012 2:59 PM
To: edk2-devel <at> lists.sourceforge.net
Subject: Re: [edk2] Both legacy OpROM and UEFI BSD loaded

It is two ROM images loaded in flash separately.  Loading into memory is not a problem, but if they are executed interchangeably will the initialization routines of OptionROM and BSD be called every time before the switch happens?  And whether the system firmware make sure both the services will not be used at same time?

Thanks
Sathya

From: Ramesh Raju [mailto:RameshR <at> ami.com]<mailto:[mailto:RameshR <at> ami.com]>
Sent: Wednesday, October 24, 2012 10:32 PM
To: 'edk2-devel <at> lists.sourceforge.net'
Subject: Re: [edk2] Both legacy OpROM and UEFI BSD loaded

Sathya,

  I assume that  both the images are packed in single option rom. Normal case will be, load only one image from option rom. But it's really depend on the UEFI firmware. They might loaded both the images to support both UEFI and Legacy OS booting.

Thanks,
Ramesh

From: Prakash, Sathya [mailto:Sathya.Prakash <at> lsi.com]
Sent: Wednesday, October 24, 2012 1:41 AM
To: edk2-devel <at> lists.sourceforge.net<mailto:edk2-devel <at> lists.sourceforge.net>
Subject: [edk2] Both legacy OpROM and UEFI BSD loaded

Hello All,
In our add-on controllers we flash both UEFI and Legacy OptionROM images and we have seen in some platforms both legacy OpROM and UEFI BSD are loaded by the UEFI system firmware. Is it acceptable case and if so do the system firmware can have the possibility of executing either of them in a interchangeable way (means whether the images or just loaded in memory are they both get executed simulatenously?)

PS: How the add on controllers has to behave for this?
Thanks
Sathya

The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct

------------------------------

_______________________________________________
edk2-devel mailing list
edk2-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


End of edk2-devel Digest, Vol 34, Issue 108
*******************************************

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
edk2-devel mailing list
edk2-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Gmane