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,
<[email protected]>wrote:
> Send edk2-devel mailing list submissions to
> [email protected]
>
> 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
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> 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 <[email protected]>
> Subject: Re: [edk2] EFI_FILE_PROTOCOL.Delete() failing with
> EFI_WARN_DELETE_FAILURE
> To: [email protected]
> Message-ID:
> <CAH38s=vt9b4f=0gUCnEsXt4tZGoJ27aaq3Zq6wnDP=
> [email protected]>
> 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 <[email protected]> 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 <[email protected]> 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
> >> [email protected]
> >> 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
> > [email protected]
> > 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 <[email protected]>
> Subject: Re: [edk2] [PATCH v3 3/4] OvmfPkg: Add LoadLinuxLib library
> implementation
> To: Jordan Justen <[email protected]>
> Cc: [email protected], Matt Fleming
> <[email protected]>
> Message-ID: <[email protected]>
> 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 <[email protected]>
>
> Laszlo
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 30 Oct 2012 09:26:58 -0600
> From: Joe Thomas <[email protected]>
> Subject: Re: [edk2] Both legacy OpROM and UEFI BSD loaded
> To: "[email protected]"
> <[email protected]>
> Message-ID:
> <[email protected]>
> 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:[email protected]]
> Sent: Thursday, October 25, 2012 2:58 AM
> To: [email protected]
> 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:[email protected]]
> Sent: Thursday, October 25, 2012 2:59 PM
> To: [email protected]
> 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:[email protected]]<mailto:[mailto:[email protected]
> ]>
> Sent: Wednesday, October 24, 2012 10:32 PM
> To: '[email protected]'
> 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:[email protected]]
> Sent: Wednesday, October 24, 2012 1:41 AM
> To: [email protected]<mailto:
> [email protected]>
> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
