Andrew Fish,
thank you,in this case,you are right.
but I think there may be other case that the user data just contain some
nosense-data
such as { UINT16 MyData[]={0x000c,0x000d,0x000d,0x000e} } to the editor,
the uefi editor may also meet this question,the editor may do not need output
this,
b
> On Jan 23, 2019, at 7:17 PM, krishnaLee wrote:
>
> Hi,
> I dumped a small log.txt from my work,but the log.txt showed in uefi shell,is
> not the same as it showed in notepad++.
> I had upload the log here:
> https://github.com/krishna116/test/blob/master/log.zip
>
>
> it seems the log showed
Hi,
I dumped a small log.txt from my work,but the log.txt showed in uefi shell,is
not the same as it showed in notepad++.
I had upload the log here:
https://github.com/krishna116/test/blob/master/log.zip
it seems the log showed in uefi shell had missed some strings...I don't know
why,please hel
David,
I think we got an agreement here to move CSM components in OvmfPkg.
I prefer we firstly clone the required CSM components in OvmfPkg right no.
Finally I can remove the IntelFrameworkModulePkg/IntelFrameworkPkg in one patch.
(I say "finally" because OVMF CSM dependency is not the only case th
On 01/23/19 15:02, Ard Biesheuvel wrote:
> On Wed, 23 Jan 2019 at 10:55, Laszlo Ersek wrote:
>>
>> On 01/23/19 10:26, Ard Biesheuvel wrote:
>>> On Wed, 23 Jan 2019 at 10:14, Laszlo Ersek wrote:
On 01/22/19 16:37, Ard Biesheuvel wrote:
>>
> Is SetUefiImageMemoryAttributes() being
> ca
On 1/22/19 6:34 PM, Laszlo Ersek wrote:
Okay, summary:
- forget the MdePkg and StdLib DSC files, build only AppPkg (or whatever
platform DSC it is that produces your UEFI application)
- make sure PcdDebugPropertyMask has bitmask 0x06 set when you build
AppPkg (or the appropriate platform
On 01/23/19 17:27, Tomas Pilar (tpilar) wrote:
>
>> The set of devices connected during BDS is platform policy. It is not
>> the "network stack" that calls Snp.Start(), but the platform BDS code
>> that calls gBS->ConnectController() on the device, possibly without a
>> good reason (e.g. without th
On 01/23/19 17:36, Gao, Liming wrote:
> Laszlo: By design, BaseTools generates GNUMakefile with the complete
> dependency. So, the generated GNUMakefile should support parallelism
> run. But, I don't verify this functionality. Have you found any
> limitation to forbid parallelism run in module GNUM
Tftp command always returned "SHELL_NOT_FOUND" which is treated as an
error by callers. Add missing line to clean the ShellStatus on
successful operation. If operation has failed, return the error status
if available.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vladimir
Hi Andrew,
I think it makes sense for new code to use the
UEFI type names and for existing code to remain unchanged.
>From looking at UefiBaseTypes.h, I do not think we should
move all types from that file into Base.h. If we really
wanted to do that, we could simple add #include of
UefiBaseType
> On Jan 23, 2019, at 8:27 AM, Tomas Pilar (tpilar)
> wrote:
>
>
>> The set of devices connected during BDS is platform policy. It is not
>> the "network stack" that calls Snp.Start(), but the platform BDS code
>> that calls gBS->ConnectController() on the device, possibly without a
>> good
Laszlo:
By design, BaseTools generates GNUMakefile with the complete dependency. So,
the generated GNUMakefile should support parallelism run. But, I don't verify
this functionality. Have you found any limitation to forbid parallelism run in
module GNUMakefile?
Thanks
Liming
> -Original M
> The set of devices connected during BDS is platform policy. It is not
> the "network stack" that calls Snp.Start(), but the platform BDS code
> that calls gBS->ConnectController() on the device, possibly without a
> good reason (e.g. without the device being present in a UEFI boot
> option). Th
On Wed, 23 Jan 2019 at 17:13, Leif Lindholm wrote:
>
> On Wed, Jan 23, 2019 at 04:55:28PM +0100, Ard Biesheuvel wrote:
> > On Wed, 23 Jan 2019 at 16:46, Leif Lindholm
> > wrote:
> > >
> > > On Mon, Jan 07, 2019 at 08:15:01AM +0100, Ard Biesheuvel wrote:
> > > > Currently, we always invalidate th
On Wed, Jan 23, 2019 at 05:16:57PM +0100, Ard Biesheuvel wrote:
> On Wed, 23 Jan 2019 at 17:13, Leif Lindholm wrote:
> >
> > On Wed, Jan 23, 2019 at 04:55:28PM +0100, Ard Biesheuvel wrote:
> > > On Wed, 23 Jan 2019 at 16:46, Leif Lindholm
> > > wrote:
> > > >
> > > > On Mon, Jan 07, 2019 at 08:1
On Wed, Jan 23, 2019 at 04:55:28PM +0100, Ard Biesheuvel wrote:
> On Wed, 23 Jan 2019 at 16:46, Leif Lindholm wrote:
> >
> > On Mon, Jan 07, 2019 at 08:15:01AM +0100, Ard Biesheuvel wrote:
> > > Currently, we always invalidate the TLBs entirely after making
> > > any modification to the page table
Hi,
On 01/23/19 11:55, Tomas Pilar (tpilar) wrote:
> Hi,
>
> Recently I have done some performance improvements to my network
> driver. I am however finding that on some platforms, it's becoming
> impossible to boot if the network cable has a lot of traffic on it
> that is not filtered by the NIC
On Wed, 23 Jan 2019 at 16:46, Leif Lindholm wrote:
>
> On Mon, Jan 07, 2019 at 08:15:01AM +0100, Ard Biesheuvel wrote:
> > Currently, we always invalidate the TLBs entirely after making
> > any modification to the page tables. Now that we have introduced
> > strict memory permissions in quite a nu
Hi,
(adding Alex, Gerd, Dave)
On 01/23/19 12:40, Wuzongyong (Euler Dept) wrote:
>
> Hi,
>
> Recently I do a test with edk2 on rhel platform.
Cool :) I don't frequently see RHEL-related reports on this list.
> I resized the gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size value to 1TB for
> suppor
On Mon, Jan 07, 2019 at 08:15:01AM +0100, Ard Biesheuvel wrote:
> Currently, we always invalidate the TLBs entirely after making
> any modification to the page tables. Now that we have introduced
> strict memory permissions in quite a number of places, such
> modifications occur much more often, an
Well, if we don't hear back, I can just commit it anyway before the
end of the week. One question/comment inline below:
On Tue, Jan 22, 2019 at 04:29:50AM +, Meenakshi Aggarwal wrote:
> Hi Jun, Haojian,
>
> Please review the patch.
>
> Thanks,
> Meenakshi
>
> > -Original Message-
>
Hi Ting,
Currently we see it on DELL 13G platforms. However, in my experience most
platforms will call Snp.Start() immediatelly following the ConnectController()
way before the boot manager is entered.
Cheers,
Tom
On 23/01/2019 14:14, Ye, Ting wrote:
> Hi Tom,
>
> As I known it is up to platfo
On 2019/1/23 20:15, Julien Grall wrote:
On 23/01/2019 01:41, Zeng, Star wrote:
Hi Julien,
Hi Star,
On 2019/1/22 12:30, Zeng, Star wrote:
On 2019/1/22 3:40, Ard Biesheuvel wrote:
On Mon, 21 Jan 2019 at 14:36, Julien Grall
wrote:
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Vari
Hi Tom,
As I known it is up to platform BDS when to connect network stack, or even not
to connect network stack. For example, in fast boot process, network stack will
not be connected thus Snp.Start() has no chance to be called.
May I know which platforms you see this issue?
Thanks,
Ting
On Wed, 23 Jan 2019 at 10:55, Laszlo Ersek wrote:
>
> On 01/23/19 10:26, Ard Biesheuvel wrote:
> > On Wed, 23 Jan 2019 at 10:14, Laszlo Ersek wrote:
> >> On 01/22/19 16:37, Ard Biesheuvel wrote:
>
> >>> Is SetUefiImageMemoryAttributes() being
> >>> called to remap the memory R-X ?
> >>
> >> No, i
On Wed, 23 Jan 2019 at 10:55, Laszlo Er
> > That's going to be a hard thing to keep from happening over time, as
> > this is valid C :(sek wrote:
>
> Hi All,
>
> On 01/23/19 04:43, Ni, Ray wrote:
> >> -Original Message-
> >> From: David Woodhouse
> >> Sent: Wednesday, January 23, 2019 12
On 23/01/2019 01:41, Zeng, Star wrote:
Hi Julien,
Hi Star,
On 2019/1/22 12:30, Zeng, Star wrote:
On 2019/1/22 3:40, Ard Biesheuvel wrote:
On Mon, 21 Jan 2019 at 14:36, Julien Grall wrote:
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
b/MdeModulePkg/Universal/Variabl
Mike:
Please refer to
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process
and contribute the patch.
And, please work on the patch in edk2 master instead of branch.
Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01
Hi,
Recently I do a test with edk2 on rhel platform. I resized the
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size value to 1TB for supporting
multiple GPUs passthrough which have large bars .
But when I started a VM with a virtio nic and booted from the changed OVMF, it
seems the VM failed to bo
Added the acpiview parser for the PPTT table.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Krzysztof Koch
---
The changes can be seen at:
https://github.com/KrzysztofKoch1/edk2/tree/woa_390_pptt_acpiview_v1
Notes:
v1:
- added a parser for PPTT in acpiview
Hi,
Recently I have done some performance improvements to my network driver. I am
however finding that on some platforms, it's becoming impossible to boot if the
network cable has a lot of traffic on it that is not filtered by the NIC itself
(broadcast, multicast or directed unicast). It would
Hi, all
The following modifications are made to enable EDK Driver Support BH720 CHIP.
--- /c/yx/edk2/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c 2019-01-21
15:36:12.188734400 -0800
+++ /c/MyWorkspace/edk2-vUDK2018/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c
2018-08-13 22:40:04.802226200
Hi, all
The following modifications are made to enable EDK Driver Support BH720 CHIP.
--- /c/yx/edk2/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
2019-01-21 15:36:12.186739600 -0800
+++
/c/MyWorkspace/edk2-vUDK2018/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
2019-01
On 01/23/19 10:26, Ard Biesheuvel wrote:
> On Wed, 23 Jan 2019 at 10:14, Laszlo Ersek wrote:
>> On 01/22/19 16:37, Ard Biesheuvel wrote:
>>> Is SetUefiImageMemoryAttributes() being
>>> called to remap the memory R-X ?
>>
>> No, it is not; the grub binary in question doesn't have the required
>> s
On Wed, 2019-01-23 at 10:46 +0100, Laszlo Ersek wrote:
> I'm fine if we move the generic CSM components into OvmfPkg, however I'm
> going to ask David to assume reviewer responsibilities for them.
>
> Given the current format of "Maintainers.txt", we couldn't spell out the
> exact pathnames of the
Hi All,
On 01/23/19 04:43, Ni, Ray wrote:
>> -Original Message-
>> From: David Woodhouse
>> Sent: Wednesday, January 23, 2019 12:23 AM
>> To: Ni, Ray ; Gerd Hoffmann ;
>> Laszlo Ersek ; Richardson, Brian
>>
>> Cc: Justen, Jordan L ; edk2-devel@lists.01.org;
>> Kevin O'Connor ; Anthony Pe
Hi Leif,
śr., 23 sty 2019 o 10:42 Leif Lindholm napisał(a):
>
> On Wed, Jan 23, 2019 at 09:28:40AM +0100, Marcin Wojtas wrote:
> > wt., 22 sty 2019 o 22:10 Leif Lindholm
> > napisał(a):
> > >
> > > On Tue, Jan 22, 2019 at 09:56:14PM +0100, Marcin Wojtas wrote:
> > > > > > > I think I gave my su
On Wed, Jan 23, 2019 at 09:28:40AM +0100, Marcin Wojtas wrote:
> wt., 22 sty 2019 o 22:10 Leif Lindholm napisał(a):
> >
> > On Tue, Jan 22, 2019 at 09:56:14PM +0100, Marcin Wojtas wrote:
> > > > > > I think I gave my suggestion for the resolution of this problem
> > > > > > (with
> > > > > > movi
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1485
Current FSP utilizes pre-allocated temporary memory from
boot loader for both heap and stack. To reduce overall
temporary memory usage FSP may share the same stack with
boot loader and only needs a smaller memory for heap,
no separate memory
Hi, all
The following modifications are made to enable EDK Driver Support BH720 CHIP.
---
/c/MyWorkspace/edk2-vUDK2018/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
2019-01-10 14:35:21.342736200 -0800
+++ /c/yx/edk2/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
2019-
On Wed, 23 Jan 2019 at 10:14, Laszlo Ersek wrote:
>
> On 01/22/19 16:37, Ard Biesheuvel wrote:
> > On Tue, 22 Jan 2019 at 16:09, Laszlo Ersek wrote:
> >>
> >> Performing thread-necromancy on a patch from 2015, which is today known
> >> as commit b7de7e3cab3f. Also CC'ing Christoffer and Marc.
> >
On 01/22/19 16:37, Ard Biesheuvel wrote:
> On Tue, 22 Jan 2019 at 16:09, Laszlo Ersek wrote:
>>
>> Performing thread-necromancy on a patch from 2015, which is today known
>> as commit b7de7e3cab3f. Also CC'ing Christoffer and Marc.
>>
>> Question at the bottom.
>>
>> On 12/07/15 08:06, Ard Biesheu
On Wed, 2019-01-23 at 07:12 +0100, Gerd Hoffmann wrote:
> > A one-size-fits-all BIOS using OVMF+CSM is very much
> > preferable.
>
> Building a one-size-fits-all BIOS is pretty much impossible due to CSM
> being incompatible with secure boot.
Booting with CSM is incompatible with Secure Boot, of
Hi Ray and Hao
Do you have any comments for this patch?
-Original Message-
From: Zhang, Chao B
Sent: Wednesday, January 23, 2019 2:22 PM
To: Chen, Chen A ; edk2-devel@lists.01.org
Cc: Ni, Ray
Subject: RE: [PATCH 3/3] FatPkg: Add GPT check in FatPei to support
Capsule-on-Disk feature.
Hi Leif,
wt., 22 sty 2019 o 22:10 Leif Lindholm napisał(a):
>
> On Tue, Jan 22, 2019 at 09:56:14PM +0100, Marcin Wojtas wrote:
> > > > > I think I gave my suggestion for the resolution of this problem (with
> > > > > moving StackBase to 0x0540 as the alternative) in my previous
> > > > > repl
45 matches
Mail list logo
