Thanks Andrew!
Thanks,
Manish
On Mon, Jul 7, 2014 at 9:38 PM, Andrew Fish wrote:
>
> On Jul 7, 2014, at 8:24 PM, manish mahajan wrote:
>
> > Hi All,
> >
> > I have a very basic question. How can I use string related standard
> library functions (strlen/strstr etc) in BdsLib? Are there any eq
Chen,
Thanks! Done at r15624.
Reviewed-by: Jeff Fan
Jeff
-Original Message-
From: chen.fan.f...@cn.fujitsu.com [mailto:chen.fan.f...@cn.fujitsu.com]
Sent: Tuesday, July 08, 2014 5:18 PM
To: edk2-devel@lists.sourceforge.net
Cc: Fan, Jeff
Subject: Re: [edk2] [PATCH] UefiCpuPkg/ArchExce
Martin:
Per Andrew comment, this value is the recommended constant. If so, we don't
need to add one PCD for it unless someone has the strong request to configure
it.
Thanks
Liming
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Tuesday, July 08, 2014 9:26 PM
To: 'Andrew Fish'; Gao,
Jordan:
Yes. I am studying git format. :)
Good catch. The original code is wrong. I check SetMem.asm. It should be
$-0x10
Thanks
Liming
-Original Message-
From: Justen, Jordan L
Sent: Wednesday, July 09, 2014 6:37 AM
To: edk2-devel@lists.sourceforge.net; Gao, Liming; af...@apple.com
On 2014-07-07 02:04:54, Gao, Liming wrote:
> Andrew:
>
> We did some fix in MdePkg to support Clang compiler. I also verify those
>change in GCC46 tool chain. Could you help review it?
I wonder if you might consider using git send-email. It makes it
easier to review, and send comments on
On 07/08/14 22:57, Peter Maydell wrote:
> On 8 July 2014 21:13, Laszlo Ersek wrote:
>> It's not immediately obvious which "branch" of your porting guide (ie.
>> "edk2 from cold boot" vs. "edk2 as 2nd stage boot loader") to pick,
>> because the design of the virtual board (== qemu-system-aarch64 -M
Sorry, I understand.
Thanks for your great patience!
On 09 июля 2014 г., at 0:27, Sergey Isakov wrote:
> Andrew,
> In this case buffer is not record. It is empty array.
> It is a pointer used by C program as UINT8* Buffer and doesn’t contain POOL
> record.
> It must be special codes in FreePool
Andrew,
In this case buffer is not record. It is empty array.
It is a pointer used by C program as UINT8* Buffer and doesn’t contain POOL
record.
It must be special codes in FreePool to get the Head of Pool list but these
codes absent.
On 09 июля 2014 г., at 0:21, Andrew Fish wrote:
>
> On Ju
On Jul 8, 2014, at 1:02 PM, Sergey Isakov wrote:
>
> On 08 июля 2014 г., at 23:56, Andrew Fish wrote:
>
>> ASSERT(Buffer != NULL);
>> //
>> // Get the head & tail of the pool entry
>> //
>> Head = CR (Buffer, POOL_HEAD, Data, POOL_HEAD_SIGNATURE);
>> ASSERT(Head != NULL);
>>
> CR
On 07/08/14 16:51, Olivier Martin wrote:
> Hi Lazlo,
>
> I might have missed some of your questions. But here are the first answers.
> I have tried to clarify the differences between these different components
> ArmPlatformPkg/Sec, ArmPlatformPkg/PrePi, ArmPlatformPkg/PrePeiCore in this
> wikipage
On 08 июля 2014 г., at 23:56, Andrew Fish wrote:
> ASSERT(Buffer != NULL);
> //
> // Get the head & tail of the pool entry
> //
> Head = CR (Buffer, POOL_HEAD, Data, POOL_HEAD_SIGNATURE);
> ASSERT(Head != NULL);
>
CR macro will not find POOL_HEAD structure. It assumes buffer contain
I see no such codes.
I see FreePool(buff) == CoreFreePool(buff) that calls
EFI_STATUS
CoreFreePoolI (
IN VOID *Buffer
)
{
And there is no search for private POOL data.
There is such search at AllocatePool but it forgotten at FreePool.
On 08 июля 2014 г., at 22:58, Andrew Fish wrote:
>
On Jul 8, 2014, at 11:13 AM, Sergey Isakov wrote:
> But the sequence
> ——
> UINT8 *buff = (UINT8 *)AllocateZeroPool(len);
> FreePool(buff);
> ———
> assumes that the buff is an array of 0x00 and doesn’t contain any signature
> or data structure.
> Isn’t it?
>
Yes, assuming len > 0. And if len
But the sequence
——
UINT8 *buff = (UINT8 *)AllocateZeroPool(len);
FreePool(buff);
———
assumes that the buff is an array of 0x00 and doesn’t contain any signature or
data structure.
Isn’t it?
On 08 июля 2014 г., at 20:38, Andrew Fish wrote:
>
> On Jul 8, 2014, at 9:15 AM, Sergey Isakov wrote:
Hi Olivier,
Yes, this is for the UEFI port for BeagleBoneBlack.
I am building a single FD that consists of both SEC and PEI. SEC is loaded from
the x-loader, and I am trying to figure out how to pass over to PEI.
The source is at [1] -- I call return_from_exception() on
PcdFvBaseAddress after I
On Jul 8, 2014, at 9:15 AM, Sergey Isakov wrote:
> No Andrew,
> hi got a message from this check
> (TYPE *) (_ASSERT (CR has Bad Signature), Record) :
> and not from NULL pointer
>
Yes this function has an ASSERT(Buffer != NULL); before the CR() macro, so a
NULL pointer would yield a diffe
No Andrew,
hi got a message from this check
(TYPE *) (_ASSERT (CR has Bad Signature), Record) :
and not from NULL pointer
Sergey
On 08 июля 2014 г., at 17:55, Andrew Fish wrote:
>
> On Jul 8, 2014, at 5:53 AM, Sergey Isakov wrote:
>
>> Hi all,
>> This is really looks like a bug. See logic
I ran into some 3rd party INF files that use mixed case for the FILE_GUID and
this was confusing my debugger Python scripts. I think it is better for the
Guid.xref file to output the GUID strings in upper case.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish
Having used Authenticode on Windows, I know that without a timestamp the
signature will be considered invalid once the certificate has expired.
Is the same true with UEFI?
I don't see anything about timestamping in the documentation
(SigningUefiImages etc.) but on Windows 8.1 Microsoft's EFI fi
Hi Lazlo,
I might have missed some of your questions. But here are the first answers.
I have tried to clarify the differences between these different components
ArmPlatformPkg/Sec, ArmPlatformPkg/PrePi, ArmPlatformPkg/PrePeiCore in this
wikipage: http://tianocore.sourceforge.net/wiki/ArmPlatformPk
Hello Olivier, Michael,
I'm trying to understand the early (SEC/PEI) code flow in
ArmPlatformPkg, in particular with regard to the configuration of the
early (temporary) SEC/PEI stack+heap, and then how the permanent PEI
memory are determined.
The motivation for this is that in an aarch64 virtual
Hi Liming,
I have another idea. May be it will be more appropriate if we can make the
module to be compiled by nasm and change clang tool chain to use nasm.
Sergey
On 08.07.2014, at 4:57, Gao, Liming wrote:
> Sergey:
> Yes. This is the possible solution. But, the previous code has the hard
>
On Jul 8, 2014, at 5:53 AM, Sergey Isakov wrote:
> Hi all,
> This is really looks like a bug. See logics:
> FreePool(buff) mapped to CoreFreePool(buff) that calls CoreFreePoolI(buff);
> and we see here
> --
> EFI_STATUS
> CoreFreePoolI (
> IN VOID *Buffer
> )
> {
> POOL
Actually, I was thinking to replace this canary value by a FixedPcd but I do
not remember why I have not done it. I might have just forgot it.
Olivier
From: Andrew Fish [mailto:af...@apple.com]
Sent: 08 July 2014 02:14
To: Gao, Liming
Cc: Olivier Martin; Mike Kinney;
edk2-buildtools-de...@lis
Hi all,
This is really looks like a bug. See logics:
FreePool(buff) mapped to CoreFreePool(buff) that calls CoreFreePoolI(buff); and
we see here
--
EFI_STATUS
CoreFreePoolI (
IN VOID *Buffer
)
{
POOL*Pool;
POOL_HEAD *Head;
POOL_TAIL *Tail;
POOL_FREE *Fre
Hi Varad,
Can you give a bit more details on your boot flow.
Where do you start the SEC from (Flash?)? Is SEC and PEI in the same FD
file?
I guess it is the related to the UEFI support for the BeagleBoneBlack?
Looking at the code in
https://github.com/varadgautam/TexasInstrumentsPkg/blob/master/B
Dear All,
I use AllocateZeroPool to allocate memory and use FreePool to free:
UINT8 *buff = (UINT8 *)AllocateZeroPool(len);
FreePool(buff);
But I got this error:
ASSERT MdeModulePkg\Core\Dxe\Mem\Pool.c(425): CR has Bad Signature
What is the problem?
Can I use other method to do this? I use VC t
On Tue, 2014-07-08 at 07:30 +, Fan, Jeff wrote:
> Hi, Chen
>
> Thanks your fix.
>
> I will help to check-in your fix. I also noticed 2 same typos in other files
> in attached patch file.
>
> Reviewed-by: Jeff Fan
Hi, Jeff
Thanks for your review. I also found there were more typos in
Hi, Chen
Thanks your fix.
I will help to check-in your fix. I also noticed 2 same typos in other files
in attached patch file.
Reviewed-by: Jeff Fan
Thanks!
Jeff
-Original Message-
From: Chen Fan [mailto:chen.fan.f...@cn.fujitsu.com]
Sent: Tuesday, July 08, 2014 2:05 PM
To: edk2-de
2014-07-08 2:25 GMT+02:00 Tian, Feng :
> Oh, from the shell "drivers" cmd log, the BIOS is using AMI's usb stack
> rather than EDKII usb stack.
>
> Your code logic looks good. I am not sure why you don't get correct return
> data. It may be related with AMI's usb implementation. You have to ask A
30 matches
Mail list logo
