Hi,
Working with MinnowBoard Max, I run on errors. There is patch with correct
values.
Index: Vlv2TbltDevicePkg/Include/Library/SpiFlash.H
===
--- Vlv2TbltDevicePkg/Include/Library/SpiFlash.H (revision 1319)
+++
On Wed, Jun 22, 2016 at 07:24:32PM +0200, Laszlo Ersek wrote:
> Gary,
>
> On 06/22/16 17:33, Laszlo Ersek wrote:
> > On 06/22/16 17:24, Gerd Hoffmann wrote:
> >> On Mi, 2016-06-22 at 17:14 +0200, Laszlo Ersek wrote:
> >>> On 06/22/16 10:34, Michael Brown wrote:
> On 22/06/16 05:48, Laszlo
Shia:
Thanks for your contribution. I suggest to install system table with
gMemoryStatusCodeRecordGuid, don't introduce PCD. For SMM memory status code,
install SmmConfigurationTable with gMemoryStatusCodeRecordGuid. Then, for
PEI/DXE/SMM, they can all be found.
Thanks
Liming
>
well for the patch to go upstream it would have to get improved a lot.
I've tried to implement this in a way that doesn't need a different dsc but
the problem is that ShellLib's constructor ASSERT's if it can't find the
shell protocol and removing that would probably be against the spec's.
Also
I do have few comments:
1. Echo.c:84
If (OnFlag) {...} Else if (OffFlag) {...}
The above code can be changed to:
If (OnFlag || OffFlag) {...}
2. Echo.c:94
Does OriginalCmdLine contains empty spaces in the beginning?
After I checked the code in Shell.c I then knew that the spaces were
Reviewed-By: Wu Jiaxin
Best Regards!
Jiaxin
> -Original Message-
> From: Thomas Palmer [mailto:thomas.pal...@hpe.com]
> Sent: Wednesday, June 22, 2016 9:57 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; samer.el-haj-mahm...@hpe.com;
>
Hi, Marcin
You may misunderstand what I meant. Sorry for that.
At first, the SD_MMC_PASS_THRU protocol is defined by UEFI spec, you couldn't
change its interfaces.
Secondly, the transfer mode judgement should be done at SdMmcPciHcDxe driver.
This way could avoid introducing a new interface
Ard:
Could you send the updated FDF file that causes build failure? I would like
to see what issue here.
Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Wednesday, June 22, 2016 11:43 PM
> To: Ard
Mike:
For GUID C Name in DEC file, how to find its value? Or require it be defined
in the same package.
For VOID* byte array, could we support the usage to set the value in the
specified offset. For example, VOID* { 0, 1, 2, OFFSET(8) 3, 4, 5 }
Thanks
Liming
> -Original Message-
Hi, all
Now, edk2 master build failure with VS tool chain. This patch resolves it. If
no reject, I will like to push it today.
Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Liming Gao
> Sent: Wednesday, June 22, 2016 3:47
Reviewed-by: Fu Siyuan
> -Original Message-
> From: Wu, Jiaxin
> Sent: Wednesday, June 22, 2016 7:14 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Ryan
> Harkin
> Subject: [Patch]
> -Original Message-
> From: Ryan Harkin [mailto:ryan.har...@linaro.org]
> Sent: Wednesday, June 22, 2016 8:00 PM
> To: Wu, Jiaxin
> Cc: edk2-devel-01 ; Ye, Ting ;
> Fu, Siyuan
> Subject: Re: [Patch]
Reviewed-by: Eric Dong
> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, June 22, 2016 3:26 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric; Chan, Amy
> Subject: [PATCH] MdeModulePkg/Bds: Do not boot to UI again when BootNext
> points to UI
>
> Per UEFI
Hi
I have updated this RFC to V2 that includes a concepts provided by
Tim Lewis that includes extensions to initialize a VOID* PCD that
cannot be described with a C structure (e.g. UEFI Load Option).
The changes for V2 are:
* Update examples to cover new syntax cases
* Clarify that this
Hey all,
IScsiMisc and Snp (latter not part of V1) are the only code files I found using
these services during the event (within MdeModulePkg). A patch for NetworkPkg's
IScsiMisc has already been submitted and it still open for review from my side.
If anyone has found any other example, feel
Hey Michael,
Thank you for your input! This looks interesting.
Maybe it would be a good idea to provide the libraries that depend on Shell (in
master) with functions that call ASSERT (FALSE); for drivers? I do not need
file I/O, so I think your modifications might work out well for me. Would be
In my fork of edk2 I've added support for using StdLib without the Shell.
It's quite hacky(setenv/getenv are stubs, no File IO and maybe other things
hidden by linker GC and me not using all features).
But depending on which StdLib features you need this can work pretty good.
here's the commit
On 06/22/16 20:53, Achin Gupta wrote:
> Hi All,
>
> I having some trouble trying an experiment on the AARCH64 Base FVP with UEFI
> and
> ARM Trusted Firmware. There is a buffer that is allocated by the latter in
> DRAM
> with TZC-400 attributes that allow non-secure access. Its extents are made
> On Jun 22, 2016, at 12:38 PM, Marvin H?user
> wrote:
>
> Dear EDK2 developers,
>
> For an experimental project, I'm currently attempting to write a library
> wrapper for the disassembler library 'Capstone' in a similar manner to
> CryptoPkg's OpensslLib. As
Marvin,
Yes. A V2 version of the patch that eliminates memory alloc/free actions in
exit
boot services event notification functions looks like a very good idea to me.
Mike
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Marvin
> H?user
>
Dear EDK2 developers,
For an experimental project, I'm currently attempting to write a library
wrapper for the disassembler library 'Capstone' in a similar manner to
CryptoPkg's OpensslLib. As most C libraries, it also depends on the standard
headers, which are not provided by 'stock' EDK2. My
Hey Mike,
Yes, I'm aware of that and it has been the very reason for this patch. Despite
doing the same for SMM memory, which is nonsense (I just didn't think about it
being separate, sorry again), I still would like to have feedback of the
changes to IScsiMisc.c - there it's the same
Marvin,
If none of the exit boot services event handlers in a platform do any memory
allocation/free
actions, then only a single call to GetMemoryMap() is required because the
memory map key
will be the same.
As Andrew pointed out, these event notifications should not do alloc/free, so
if
Hi All,
I having some trouble trying an experiment on the AARCH64 Base FVP with UEFI and
ARM Trusted Firmware. There is a buffer that is allocated by the latter in DRAM
with TZC-400 attributes that allow non-secure access. Its extents are made
available to a UEFI DXE driver through an SMC. AFAIU,
On 06/22/16 05:15, Gao, Liming wrote:
> Laszlo:
> I don't find any other case. I have integrated your patches into
> https://github.com/lgao4/edk2.git branch nasm-v2. Please help check.
I retested the SMM_REQUIRE + S3 cases (Ia32 Fedora, Ia32X64 Fedora,
Ia32X64 Windows 8.1), with your nasm-v2
On 06/22/16 17:30, Ard Biesheuvel wrote:
> On 21 June 2016 at 17:43, Laszlo Ersek wrote:
>> (3) Actually, now I suggest to DEFINE the following macros at the top of the
>> file:
>>
>> DEFINE VARS_BASE = 0x0400
>> DEFINE VARS_BLOCKS = 3
>> DEFINE BLOCK_SIZE = 0x0004
Similar to how OVMF implements this, add a FD definition for the varstore
firmware volume and the FTW areas. The template was taken from the file
OvmfPkg/VarStore.fdf.inc, and subsequently modified to accommodate the
differences in NOR flash layout. This affects the FvLength, Checksum and
On 06/22/16 17:24, Gerd Hoffmann wrote:
> On Mi, 2016-06-22 at 17:14 +0200, Laszlo Ersek wrote:
>> On 06/22/16 10:34, Michael Brown wrote:
>>> On 22/06/16 05:48, Laszlo Ersek wrote:
In other words, the memcpy() quoted at the top copies 32 bytes into a
32-byte buffer, from a 20-byte
On 21 June 2016 at 17:43, Laszlo Ersek wrote:
> On 06/21/16 12:30, Ard Biesheuvel wrote:
>> Similar to how OVMF implements this, add a FD definition for the varstore
>> firmware volume and the FTW areas. This can be used by host side tooling
>> to manipulate a pristine varstore
On Mi, 2016-06-22 at 17:14 +0200, Laszlo Ersek wrote:
> On 06/22/16 10:34, Michael Brown wrote:
> > On 22/06/16 05:48, Laszlo Ersek wrote:
> >> In other words, the memcpy() quoted at the top copies 32 bytes into a
> >> 32-byte buffer, from a 20-byte buffer. It is the *source* buffer that is
> >>
On 7 June 2016 at 01:22, Daniil Egranov wrote:
> The patches add a new device configuration protocol and use it to configure
> a Marvell Yukon controller on the Juno platform with a valid MAC address.
>
> The device configuration protocol will enable a driver to
Very nice. I like this much more.
Reviewed-by: Jaben Carsey
Ray, what do you think?
-Jaben
> -Original Message-
> From: Qiu, Shumin
> Sent: Wednesday, June 22, 2016 1:51 AM
> To: edk2-devel@lists.01.org
> Cc: Qiu, Shumin ; Carsey, Jaben
>
On 06/22/16 10:34, Michael Brown wrote:
> On 22/06/16 05:48, Laszlo Ersek wrote:
>> In other words, the memcpy() quoted at the top copies 32 bytes into a
>> 32-byte buffer, from a 20-byte buffer. It is the *source* buffer that is
>> overflowed.
>>
>> As a result, bytes 20..31 of MacAddress
From: Jan Dąbroś
For multiple block write operation it is necessary to poll for device status
to be ready for next transaction. For sending SD_DEVICE_STATUS command it is
necessary to know device RCA. In order to make it possible, there is new
field added to SD_DEVICE
From: Joe Zhou
This delay is necessary for eMMC reset to working properly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Joe Zhou
Signed-off-by: Marcin Wojtas
Reviewed-by: Feng Tian
---
From: Jan Dąbroś
This patch adds IsDmaEnabled function to EFI_SD_MMC_PASS_THRU_PROTOCOL.
It returns information, if controller supports DMA transfer modes. New
interface is necessary in order to allow BlockIo layer to perform
transfers in PIO mode.
Contributed-under:
From: Jan Dąbroś
This patch adds SetBlockLen function, which sends transfer blocks
size setting to device.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jan Dabros
Signed-off-by: Marcin Wojtas
---
From: Jan Dąbroś
SD_STOP_TRANSMISSION command is necessary for multi block operations
(read and write). This patch adds such functionality for devices
not supporting DMA data transfer.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jan Dabros
Hello,
We are sending v2 of the fixes and PIO mode support. The main
change is replacing PCD introduction with new function added to
EFI_SD_MMC_PASS_THRU_PROTOCOL, which allows obtaining information
about DMA usage from host controller capabilities.
Any comments or remarks would be very welcome.
From: Joe Zhou
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Joe Zhou
Signed-off-by: Jan Dabros
Signed-off-by: Marcin Wojtas
---
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c | 2 +-
On 22 June 2016 at 16:46, Leif Lindholm wrote:
> On Tue, Jun 21, 2016 at 12:30:30PM +0200, Ard Biesheuvel wrote:
>> This series refactors some of the NOR flash code in ArmPlatformPkg and
>> ArmVirtPkg so that we can add an empty varstore definition to the
>> ArmVirtQemu
On Tue, Jun 21, 2016 at 12:30:30PM +0200, Ard Biesheuvel wrote:
> This series refactors some of the NOR flash code in ArmPlatformPkg and
> ArmVirtPkg so that we can add an empty varstore definition to the
> ArmVirtQemu amd ArmVirtQemuKernel FDFs. The refactoring is necessary to make
> NorFlashDxe
Reassign all interrupts to non-secure Group-1 if the GIC has its DS
(Disable Security) bit set. In this case, it is safe to assume that we
own the GIC, and that no other firmware has performed any configuration
yet, which means it is up to us to reconfigure the interrupts so they
can be taken by
On 22 June 2016 at 12:14, Jiaxin Wu wrote:
> This patch is used to fix the wrong IpSb->State update issue.
>
> Issue reproduce steps:
> 1 .First PXE boot, then boot to shell;
> 2. ifconfig -s eth0 dhcp (Success);
> 3. Reboot and do PXE, then boot to shell;
> 4. ifconfig -s
Hey Star,
> I am still curious what is the real issue Marvin met.
There is no issue I met, I simply want to save another call to GetMemoryMap()
because it may be altered during ExitBS(). It's a break of the specification,
but it sounds like Intel complying to its own sepcification is not a
This patch is used to fix the wrong IpSb->State update issue.
Issue reproduce steps:
1 .First PXE boot, then boot to shell;
2. ifconfig -s eth0 dhcp (Success);
3. Reboot and do PXE, then boot to shell;
4. ifconfig -s eth0 dhcp (Platform failed to get IP address no matter
how many times
Thanks, Ray. I will update patch to add the commit message you mentioned.
Regards,
Sunny Wang
-Original Message-
From: Ni, Ruiyu [mailto:ruiyu...@intel.com]
Sent: Wednesday, June 22, 2016 5:51 PM
To: Wang, Sunny (HPS SW) ; edk2-devel@lists.01.org
Cc: El-Haj-Mahmoud,
After offline discussing with Ray and Samer, I will update patch to completely
support the case where platform doesn't support BootManagerMenu
(BootManagerMenu doesn't be built into firmware). Thanks, Ray and Samer.
Regards,
Sunny Wang
-Original Message-
From: Ni, Ruiyu
Sunny,
I agree with this patch. After all the patch is an improvement though it cannot
fix all the bugs.
Please mention in the commit message that:
But there is a corner case even when the memory bins don't include the RAM disk
memory,
the memory used by all other modules exceeds
On 22 June 2016 at 09:45, Wu, Jiaxin wrote:
> Hi Ryan,
> I have root cause the issue:
>
Wow! You found it! I'm very pleased about that :-)
> Let me analyze this problem for you according below steps:
> 1 .First PXE boot, then boot to shell;
> 2. ifconfig -s eth0 dhcp
Cc Liming and Mike may have some comments.
Thanks,
Star
On 2016/6/22 17:17, Zeng, Star wrote:
On 2016/6/22 13:39, Bruce Cran wrote:
On 6/19/16 9:21 PM, Zeng, Star wrote:
1. The memory allocate and free in PiSmmCore are SMRAM that is not
related to UEFI memory map.
2. According to UEFI 2.6
On 2016/6/22 13:39, Bruce Cran wrote:
On 6/19/16 9:21 PM, Zeng, Star wrote:
1. The memory allocate and free in PiSmmCore are SMRAM that is not
related to UEFI memory map.
2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader
should have got the memory map before ExitBootServices.
Reviewed-by: Liming Gao for this serial.
> -Original Message-
> From: Justen, Jordan L
> Sent: Thursday, June 16, 2016 2:11 PM
> To: edk2-devel@lists.01.org
> Cc: Justen, Jordan L ; Zhu, Yonghong
> ; Gao, Liming
Difference with previous:
Use Shell command Lib API to get original command string.
Currently run 'echo -t' will get the result:
echo: Unknown flag - '-t'
The expected result is to display '-t' literally.
This patch adds special handle for 'echo'. 'echo' will not use the
general parameter parsing
Hi Ryan,
I have root cause the issue:
Let me analyze this problem for you according below steps:
1 .First PXE boot, then boot to shell;
2. ifconfig -s eth0 dhcp (Success);
3. Reboot and do PXE, then boot to shell;> The issue is enrolled by here
On this reboot, policy is DHCP (Changed by
PeiCore EntryPoint library _ModuleEntryPoint() will call PeiCore(), then call
CpuDeadLoop (). When NORETURN is added for PeiCore(), MSVC compiler will report
warning C4702: unreachable code for CpuDeadLoop (). And, the warning is treated
as error and cause build break. DxeMain() has the similar
Per UEFI spec the successful returning of boot option triggers boot
to UI. But when the BootNext just points to UI, it causes confusing.
So the patch avoids booting to UI again when the BootNext points to
UI.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
On Wed, Jun 22, 2016 at 02:34:19PM +0800, Gary Lin wrote:
> On Wed, Jun 22, 2016 at 12:49:03AM +0200, Laszlo Ersek wrote:
> > On 06/21/16 23:34, Laszlo Ersek wrote:
> >
> > > I believe that iPXE installs a HII formset that for some reason
> > > confuses this logic. I'll have to investigate more
On Wed, Jun 22, 2016 at 12:49:03AM +0200, Laszlo Ersek wrote:
> On 06/21/16 23:34, Laszlo Ersek wrote:
>
> > I believe that iPXE installs a HII formset that for some reason
> > confuses this logic. I'll have to investigate more (e.g., write some
> > debug code...) for a better understanding.
>
>
59 matches
Mail list logo