Hi,
edk2/MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c:34:
error: ‘WorkingHeader’ undeclared (first use in this function)
It must be a parameter?
---
#include "FaultTolerantWrite.h"
EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER mWorkingBlockHeader = {ZERO_GUID, 0, 0,
0, 0, {0,
On Fri, 2013-01-18 at 02:59 +, Li, Elvin wrote:
> Hi David:
> CSM framework has mentioned the side effect that "all EFI
> drivers are disconnected and must be reconnected for proper EFI
> functioning". So if you call the legacy bios protocol interface
> LegacyBiosShadowAllLegacyOproms w
I just looked into a shell2 crash that I often encounter and it turns out
that the call to GetDevicePathsForImageAndFile() in
ShellPkg/Application/Shell/Shell.c returns an error (ie. some file system
doesn't give up its device and file path info properly?) and then the shell
asserts. Shell1 never
Hi Keeran,
I wish I'd seen this email earlier, I suspect you have either got it
working or you've given up by now!
On 20 December 2012 09:44, keeran k wrote:
> Hello,
>
> Am trying to get my hands on ARM-UEFI on Pandaboard 4430. I just followed
> the instructions given in readme.txt below link;
Reviewed-by: Jordan Justen
Please feel free to commit this change if you have time.
Thanks,
-Jordan
On Wed, Jan 16, 2013 at 10:56 AM, Andrew Fish wrote:
> Jordan,
>
> Thanks for the quick patch and fixing my bug leaving out the REX prefix, as I
> did not realize it was required.
>
> This pat
On 18.01.2013, at 22:45, Duane Voth wrote:
> I just looked into a shell2 crash that I often encounter and it turns out
> that the call to GetDevicePathsForImageAndFile() in
> ShellPkg/Application/Shell/Shell.c returns an error (ie. some file system
> doesn't give up its device and file path in
On 17.01.2013, at 15:17, Konstantin Filatov wrote:
> Hello,
>
>
> --- CpuDxe/CpuDxe.c
> +++ CpuDxe/CpuDxe.c
> @@ -1110,13 +1110,9 @@ RestoreInterruptDescriptorTableHandlerAddress (
>IN UINTN Index
>)
> {
> - if (Index < mOrigIdtEntryCount) {
> -gIdtTable[Index].Bits.OffsetLo
