On 25 June 2015 at 05:33, Liu, Yingke D wrote:
> Ard,
>
> Following is the full GenFw patch, please confirm it:
>
> BaseTools: Update GenFw to support 4K alignment.
>
> Get maximum section alignment from ELF sections
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard
Hi, Baranee
Which case do you think the EvtTrb would be NULL?
Thanks
Feng
-Original Message-
From: Anbazhagan, Baraneedharan [mailto:[email protected]]
Sent: Thursday, June 25, 2015 10:43
To: Eric Wittmayer; Tian, Feng; [email protected]
Subject: RE: [edk2] XHCI question
At past we only did TPer Reset for ATA device in AtaBus driver.
Now a common logic to do TPer Reset is extracted and putted in TcgMor module.
By this way, all encrypted drives whose driver produces EFI_STORAGE_SECURITY_
COMMAND_PROTOCOL could be force reset at EndOfDxe.
Tian Feng (2):
MdeModule
The TPer Reset operation is a common logic. So it's added into
SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf module and
would be triggered at EndOfDxe.
By this way, all encrypted drives which produce EFI_STORAGE_SECURITY_
RPOTOCOL interface would be force reset when MOR is set.
Contributed-un
The TPer Reset operation would be moved into SecurityPkg/Tcg/
MemoryOverwriteControl/TcgMor.inf module and be triggered at EndOfDxe.
By this way, all encrypted drives which produce EFI_STORAGE_SECURITY_
RPOTOCOL interface would be force reset when MOR is set.
Contributed-under: TianoCore Contribu
Ard,
Following is the full GenFw patch, please confirm it:
BaseTools: Update GenFw to support 4K alignment.
Get maximum section alignment from ELF sections
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
BaseTools/Source/C/GenFw/Elf32Convert.c | 16 ++
> -Original Message-
> From: Eric Wittmayer [mailto:[email protected]]
> Sent: Wednesday, June 24, 2015 8:15 PM
> To: 'Tian, Feng'; [email protected]; Anbazhagan, Baraneedharan
> Subject: RE: [edk2] XHCI question
>
> Hi Feng,
> I see what Baranee is saying.
> The UEFI sp
Hi Feng,
I see what Baranee is saying.
The UEFI spec says in describing UsbBulkTransfer " If an error other than
timeout occurs during the USB
transfer, then EFI_DEVICE_ERROR is returned and the detailed status code
will be returned in the
Status parameter."
I suggest that the following change
Hi, Baranee
1. XhcCheckUrbResult() reports URB transfer state in Urb->Result rather than
Urb->Finished.
2. XhcCheckUrbResult() is an internal function rather than an exposed interface
for upper layer.
3. XhcBulkTransfer() returns status according to Urb->Result rather than others.
Please let m
Hi Ard
You are right that END_OF_DXE must be signal in Bds.
My thought is that this event should be signal in "platform BDS" instead of
"generic BDS".
The reason is that only platform know when to exit platform manufacture auth
state, and platform may have some special step before that.
Signin
> > > > Whether XhcCheckUrbResult returns correct error status in case of
> > failure?
> > > > XhcCheckUrbResult function header indicates it should report URB
> > > > transfer state - Urb->Finished (seems to align with EhciDxe) but
> > > > the implementation is trying to return EFI_STATUS and it d
> -Original Message-
> From: Anbazhagan, Baraneedharan [mailto:[email protected]]
> Sent: Wednesday, June 24, 2015 2:11 PM
> To: Eric Wittmayer; [email protected]
> Subject: RE: [edk2] XHCI question
>
> > -Original Message-
> > From: Eric Wittmayer [mailto:e...@fresc
> -Original Message-
> From: Eric Wittmayer [mailto:[email protected]]
> Sent: Wednesday, June 24, 2015 12:13 AM
> To: [email protected]; Anbazhagan, Baraneedharan
> Subject: RE: [edk2] XHCI question
>
> > Date: Tue, 23 Jun 2015 23:16:05 +
> > From: "Anbazhagan, Bar
> -Original Message-
> From: Roy Franz [mailto:[email protected]]
> Sent: Wednesday, June 24, 2015 12:52 PM
> To: Kinney, Michael D
> Cc: [email protected]
> Subject: Re: [edk2] [PATCH] MdePkg: Describe submission of a patch
> authored by someone else
>
> On Wed, Jun 24
On Wed, Jun 24, 2015 at 11:46 AM, Kinney, Michael D
wrote:
> Roy,
>
> I do not have any issues with adding this detailed description when multiple
> authors are involved in a single patch.
>
> In general, I think it would be good to avoid having multiple Signed-off-by
> in a single patch. From
According to paragraph 5.1.2.1 of the PI spec vol 2 version 1.4, the
EFI_END_OF_DXE_EVENT_GUID event must be signalled prior to invoking any
UEFI drivers, applications, or connecting consoles.
This implements the event signalling in a new GenericBdsLib function
BdsLibSignalEndOfDxeEvent (), and ad
Roy,
I do not have any issues with adding this detailed description when multiple
authors are involved in a single patch.
In general, I think it would be good to avoid having multiple Signed-off-by in
a single patch. From one perspective, it could be possible for the patch to be
broken up int
On Wed, Jun 24, 2015 at 4:23 AM, Olivier Martin wrote:
> I think your change should be integrated to a new top file
> 'Contributions.txt' and all the package 'Contributions.txt' should refer to
> this file.
> Otherwise we will start to get some inconsistencies between
> 'Contributions.txt'.
ed
On 24 June 2015 at 18:05, Andrew Fish wrote:
>
> On Jun 23, 2015, at 8:30 AM, Ard Biesheuvel
> wrote:
>
> This is an RFC series to elicit discussion regarding the use of linker
> script,
> and the fact that we use the somewhat obscure 'large' C model for building
> EDK2 for AArch64.
>
>
> Sorry I
> On Jun 23, 2015, at 8:30 AM, Ard Biesheuvel wrote:
>
> This is an RFC series to elicit discussion regarding the use of linker script,
> and the fact that we use the somewhat obscure 'large' C model for building
> EDK2 for AArch64.
Sorry I missed why the `large C` module is being used?
Also
> the Property Table support in UEFI 2.5 requires the use of an explicit linker
> script so that sections are 4 KB aligned, and .text and .data are guaranteed
> not to share a 4 KB page frame, again for allowing them to be mapped with
> different permissions. This maps poorly onto AArch64, ag
On 24 June 2015 at 17:21, Cohen, Eugene wrote:
>> + * Since some AArch64 code is aligned to 0x800 (i.e., the vector table),
>> we
>> + * need to use at least this alignment for .text.
>
> >From what I can see the vector table code uses .align directives to increase
> >the alignment size whic
> + * Since some AArch64 code is aligned to 0x800 (i.e., the vector table), we
> + * need to use at least this alignment for .text.
>From what I can see the vector table code uses .align directives to increase
>the alignment size which is propagated into the resulting ELF. The PE-COFF
>conv
Warning: long and messy email ahead.
On 06/24/15 15:37, Ard Biesheuvel wrote:
> On 24 June 2015 at 14:51, Laszlo Ersek wrote:
>> On 06/24/15 13:28, Ard Biesheuvel wrote:
>>> On 24 June 2015 at 13:15, Olivier Martin
>>> wrote:
I think this patch should move to
IntelFrameworkModulePkg/Un
On 24 June 2015 at 14:51, Laszlo Ersek wrote:
> On 06/24/15 13:28, Ard Biesheuvel wrote:
>> On 24 June 2015 at 13:15, Olivier Martin wrote:
>>> I think this patch should move to IntelFrameworkModulePkg/Universal/BdsDxe.
>>> It is a PI specification requirement to signal gEfiEndOfDxeEventGroupGui
On 06/24/15 13:28, Ard Biesheuvel wrote:
> On 24 June 2015 at 13:15, Olivier Martin wrote:
>> I think this patch should move to IntelFrameworkModulePkg/Universal/BdsDxe.
>> It is a PI specification requirement to signal gEfiEndOfDxeEventGroupGuid at
>> the end of the DXE phase.
>>
>
> Yes, that
On 06/24/15 09:25, Gao, Liming wrote:
> Laszlo:
> Ok. If so, people can contact the first S-o-b if they find any issue in
> this patch. Right?
Yes.
In particular, the semi-official git-svn mirror retains the generic git
property that "committer" and "author" are maintained separately.
Although
On 24 June 2015 at 13:15, Olivier Martin wrote:
> I think this patch should move to IntelFrameworkModulePkg/Universal/BdsDxe.
> It is a PI specification requirement to signal gEfiEndOfDxeEventGroupGuid at
> the end of the DXE phase.
>
Yes, that makes sense, I guess. But assuming most of its use
I think your change should be integrated to a new top file 'Contributions.txt'
and all the package 'Contributions.txt' should refer to this file.
Otherwise we will start to get some inconsistencies between 'Contributions.txt'.
-Original Message-
From: Roy Franz [mailto:[email protected]
I think this patch should move to IntelFrameworkModulePkg/Universal/BdsDxe. It
is a PI specification requirement to signal gEfiEndOfDxeEventGroupGuid at the
end of the DXE phase.
-Original Message-
From: Ard Biesheuvel [mailto:[email protected]]
Sent: 24 June 2015 11:25
To: edk2-
Currently, the ArmVirtPkg platforms fail to signal the end-of-DXE
event 'gEfiEndOfDxeEventGroupGuid' when entering the BDS phase,
which results in some loss of functionality, i.e., variable reclaim
in the VariableDxe drivers, and the splitting of the memory regions
that is part of the recently adde
On 24 June 2015 at 10:26, Gao, Liming wrote:
> Got your point. I agree with this change. We will include it in the patch and
> add you in Signed-off-by list.
>
OK, thanks.
There is one additional issue though: when using alignment of > 4 KB,
the GenFw tool may crash, since it tries to pad out t
Ard:
Thanks for your comments, update the script as following:
/* OUTPUT_FORMAT(efi-bsdrv-x86_64) */
SECTIONS
{
/* . = 0 + SIZEOF_HEADERS; */
. = 0x280;
.text:ALIGN(0x1000)
{
*(.text .stub .text.* .gnu.linkonce.t.*)
. = ALIGN(0x20);
}
.data: ALIGN(0x1000)
{
*(
.ro
The patch looks good.
Best Regards,
Tim
From: Wei, David
Sent: Wednesday, June 24, 2015 4:09 PM
To: '[email protected]'
Cc: Wu, Mike; He, Tim; Lu, ShifeiX A
Subject: [edk2][Patch]Vlv2TbltDevicePkg: Remove wakeup capability of GPIO_SUS1
and GPIO_SUS2
Remove wakeup capability of GP
On 24 June 2015 at 10:21, Gao, Liming wrote:
> Ard:
> I am not sure who remember the detail history. If no one knows it, I
> suggest to keep them as-is.
>
Well, with the new 2.5 feature that actually makes code RO and data
XP, I think it would be nice to make sure that rodata lives in the
form
Got your point. I agree with this change. We will include it in the patch and
add you in Signed-off-by list.
-Original Message-
From: Ard Biesheuvel [mailto:[email protected]]
Sent: Wednesday, June 24, 2015 4:19 PM
To: [email protected]
Subject: Re: [edk2] [Patch
Ard:
I am not sure who remember the detail history. If no one knows it, I suggest
to keep them as-is.
On alignment, do you suggest use ".text 0x1000 : ALIGN(0x1000) {"?
Thanks
Liming
-Original Message-
From: Ard Biesheuvel [mailto:[email protected]]
Sent: Tuesday, June 23,
On 24 June 2015 at 10:15, Gao, Liming wrote:
> Ard:
> Good suggestion. How about go through every Shdr and choose the max
> Shdr->sh_addralign? The alignment should be power of 2.
>
Indeed. Something like this seems to work fine:
"""
diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c
b/Bas
Ard:
Good suggestion. How about go through every Shdr and choose the max
Shdr->sh_addralign? The alignment should be power of 2.
Thanks
Liming
-Original Message-
From: Ard Biesheuvel [mailto:[email protected]]
Sent: Tuesday, June 23, 2015 5:14 PM
To: [email protected]
Remove wakeup capability of GPIO_SUS1 and GPIO_SUS2.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Wei mailto:[email protected]>>
Thanks,
David | SSG BIOS
BoardGpios.h.patch
Description: BoardGpios.h.patch
Hi all,
On MinnowMax I work on Windows 8.1 with UART.
In BIOS Setup I enable UART. In LSS & SCC Configuration menu in BIOS
Setup I enable : LSS HSUART #1 Support , LSS HSUART #1 FlowCtrl , LSS
HSUART #2 Support , and LSS HSUART #2 FlowCtrl . But I don't know if I
need to in BIOS Setup i
Reviewed-by: Liming Gao
-Original Message-
From: Qiu, Shumin
Sent: Tuesday, June 23, 2015 2:30 PM
To: [email protected]
Cc: Carsey, Jaben; Gao, Liming
Subject: [PATCH] MdePkg\Library\UefiFileHandleLib: Make FileHandleWriteLine
support both ASCII and UNICODE file.
When th
On 23 June 2015 at 17:30, Ard Biesheuvel wrote:
> Hello all,
>
> This is an RFC series to elicit discussion regarding the use of linker script,
> and the fact that we use the somewhat obscure 'large' C model for building
> EDK2 for AArch64.
>
> Some observations that brought about this series:
> -
Laszlo:
Ok. If so, people can contact the first S-o-b if they find any issue in this
patch. Right?
Besides, I still want to clarify below two.
1. Any changes made by the submitter should be noted above the submitter's
Signed-off-by line.
[Liming] It means the description is required to se
On 06/24/15 00:12, Jordan Justen wrote:
> On 2015-06-23 12:53:49, Laszlo Ersek wrote:
>> At the moment we work with a UC default MTRR type, and set three memory
>> ranges to WB:
>> - [0, 640 KB),
>> - [1 MB, LowerMemorySize),
>> - [4 GB, 4 GB + UpperMemorySize).
>>
>> Unfortunately, coverage for th
On 06/24/15 03:36, Gao, Liming wrote:
> This rule means the submitter is also Signed-off-by. Right?
Yes.
> I originally understand Signed-off-by means the patch authors, not
> submitter. Could you let me why add this new rule?
In the particular case that inspired this documentation patch, I and
46 matches
Mail list logo
