Laszlo:
LMFA feature doesn't do PE image rebase at build time. Only XIP module needs
to be rebased at build time. LMFA feature will specify the loaded memory
address for each PE image. At build time, build tool records the memory address
into the one field of PE image. It doesn't rebase PE ima
Get the point, thanks.
Star
-Original Message-
From: Ni, Ruiyu
Sent: Thursday, June 29, 2017 10:50 AM
To: Zeng, Star ; edk2-devel@lists.01.org
Cc: Tian, Feng ; Wu, Hao A
Subject: RE: [edk2] [PATCH 0/3] Check timeout URB again after stopping endpoint
This patch supports a certain USB de
This patch supports a certain USB device that:
1. contain BULK IN endpoint
2. BULK read from HOST gets timeout if
a. there is no data from the endpoint in the device
b. the data comes late
For now, I haven't found any other USB devices that meet the above conditions
except the Bluetooth ho
Reviewed-by: Jeff Fan
-Original Message-
From: Bi, Dandan
Sent: Wednesday, June 28, 2017 10:43 AM
To: edk2-devel@lists.01.org
Cc: Brijesh Singh; Fan, Jeff
Subject: [patch] UefiCpuPkg: Fix coding style issues
Cc: Brijesh Singh
Cc: Jeff Fan
Contributed-under: TianoCore Contribution Agre
Jiaxin reports that the OvmfPkg/README instructions for downloading the
Intel PROEFI drivers, and the filenames in OvmfPkg/OvmfPkg*.fdf for
incorporating the same in the OVMF binaries, are no longer up to date; the
download link has stopped working.
Additionally, the IA32 driver binary is no more
When the GenFv utility from BaseTools composes a firmware volume, it
checks whether modules in the firmware volume are subject to build-time
relocation. The primary indication for relocation is whether the firmware
volume has a nonzero base address, according to the [FD] section(s) in the
FDF file
The current instructions in the README, and the filenames in the FDF
files, are out of date. They are updated in the second patch.
Including the new driver in DXEFV requires a separate one-liner build
tweak for DXEFV, which however takes a wall of text to explain. This is
done in the first patch.
Hi Amit,
Yes, I used the hex prefix :)
Hi Andrew,
Yes, I made sure to print out the EFI_HANDLE (ControllerHandle) that was
passed to the gBS->DisconnectController call. Below is the output:
FS0:\> TestApp.efi 175
Handle passed to gBS->DisconnectController call - 7219EA98 (175)
gBS->DisconnectCo
On 06/27/2017 09:42 PM, Dandan Bi wrote:
Cc: Brijesh Singh
Cc: Jeff Fan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi
---
UefiCpuPkg/Include/Register/Amd/Fam17Msr.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/UefiCpuPkg/Include/
Just a final check,
You used this
gBS->DisconnectController (
ConvertHandleIndexToHandle (0x175),
ConvertHandleIndexToHandle (0x176),
NULL);
not this
gBS->DisconnectController (
ConvertHandleIndexToHandle (175),
ConvertHandleIndexToHandle (176),
NULL);
righ
> On Jun 28, 2017, at 12:27 PM, TVKR wrote:
>
> Tried it, still no luck :(
>
> There is something in the Shell that makes the in-built disconnect without
> any issues but when the same DisconnectController is called from an
> application is fails.
>
It is more likely you are doing something w
Tried it, still no luck :(
There is something in the Shell that makes the in-built disconnect without
any issues but when the same DisconnectController is called from an
application is fails.
Thanks
On Wed, Jun 28, 2017 at 1:23 PM, Amit kumar wrote:
>
>
> EFI_STATUS
> EFIAPI
> UefiMain (
> I
EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLEImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_STATUS Status;
gBS->DisconnectController (
ConvertHandleIndexToHandle (0x175),
ConvertHandleIndexToHandle (0x176),
NULL);
return (Status);
}
_
On 06/28/17 20:10, Amit kumar wrote:
> sorry, wrong thread
Ah, OK. Ignore my questions then.
Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
On 06/28/17 20:08, Amit kumar wrote:
> Try this; just a quick thing
>
>
>
> EFI_STATUS
> EFIAPI
> UefiMain (
> IN EFI_HANDLEImageHandle,
> IN EFI_SYSTEM_TABLE *SystemTable
> )
> {
> EFI_STATUS Status;
>
> ConvertHandleIndexToHandle((UINTN)Intermediate);
>
>
> gBS->Disconnec
Try this; just a quick thing
EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLEImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_STATUS Status;
gBS->DisconnectController (
ConvertHandleIndexToHandle (175),
ConvertHandleIndexToHandle (176),
NULL);
r
sorry, wrong thread
From: edk2-devel on behalf of Star Zeng
Sent: Wednesday, June 28, 2017 6:52:50 PM
To: edk2-devel@lists.01.org
Cc: Liming Gao; Gabriel Somlo; Michael D Kinney; Laszlo Ersek; Star Zeng
Subject: [edk2] [PATCH V5] MdeModulePkg/DxeCore: Fixed Inte
Try this; just a quick thing
EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLEImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_STATUS Status;
ConvertHandleIndexToHandle((UINTN)Intermediate);
gBS->DisconnectController (
ConvertHandleIndexToHandle (175),
Convert
BTW, when I run the 'reconnect -r' the ControllerHandle changes to a new
value and I noticed that handle parsing functions like
ConvertHandleIndexToHandle/PARSE_HANDLE_DATABASE_DEVICES called from the
application aren't returning correct data (all though the same functions
seem to work correctly wh
Yes, the shell's in-built command disconnect (disconnect 175 176) worked
but DisconnectController call from the application still did not work.
On Wed, Jun 28, 2017 at 12:56 PM, Amit kumar wrote:
> okay, os tell me , did you try "disconnect 175 176" in UEFI shell ?
> ---
okay, os tell me , did you try "disconnect 175 176" in UEFI shell ?
From: TVKR
Sent: Wednesday, June 28, 2017 11:21:34 PM
To: Amit kumar
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] DisconnectController API not working.
Sorry, I wasn't clear in my last email.
Sorry, I wasn't clear in my last email. No it did not hang. The 'reconnect
-r' command completed successfully (no errors reported on screen).
On Wed, Jun 28, 2017 at 12:50 PM, Amit kumar wrote:
> Did it hang ?
> --
> *From:* TVKR
> *Sent:* Wednesday, June 28, 2017 10
Did it hang ?
From: TVKR
Sent: Wednesday, June 28, 2017 10:45:13 PM
To: Amit kumar
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] DisconnectController API not working.
Thanks for the suggestion Amit. I tried the reconnect -r but it doesn't seem to
help.
On Wed
Thanks for the suggestion Amit. I tried the reconnect -r but it doesn't
seem to help.
On Wed, Jun 28, 2017 at 10:29 AM, Amit kumar wrote:
> Hi Tresko,
> I looks like there is no problem with your implementation, as was the case
> with me.
> I can suggest you a quick trick here, if it won’t work
Hi Tresko,
I looks like there is no problem with your implementation, as was the case with
me.
I can suggest you a quick trick here, if it won’t work I will help you further
which might take a while.
Follow the steps below.
1. Go to refi shell
2. Reconnect -r
3. If the sysytem hangs.
4. Try to up
Hey Rafael,
The UEFI calling conventions are detailed in the UEFI specification, more
specifically section 2.3 of the UEFI 2.7 specification.
Regards,
Marvin.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Rafael Machado
> Sent: Wednesday
Hi Amit,
Here is the output. It is the call 'gBS->DisconnectController
(ControllerHandle, NULL, NULL)' (where ControllerHandle=7219EA98) that
doesn't seem to correctly work.
FS0:\> drivers
Output Truncated..
176 07042200 B Y Y 1 1 Intel(R) PRO/1000 7.3.18 PCI-E
PciRoot(0x0)/Pci(0x2,0x3)/Pci(0
On 06/28/17 15:22, Star Zeng wrote:
> From: Amit Kumar
>
> Change since v4: Revise the patch based on V4 sent by Amit Kumar
> 1) Only return the corresponding protocol interface in *Interface
> if the return status is EFI_SUCCESS or EFI_ALREADY_STARTED.
> 2) Interface is returned unmodified for a
Hi Tresko,
>Hi Amit,
>I am seeing the exact same issue on my system with DisconnectController. The
>shell command 'disconnect' works but when I use the gBS->DisconnectController
>>call from my application it doesn't seem to really disconnect the same
>controller (even though the call returns S
On Wed, Jun 28, 2017 at 09:22:50PM +0800, Star Zeng wrote:
> From: Amit Kumar
>
> Change since v4: Revise the patch based on V4 sent by Amit Kumar
> 1) Only return the corresponding protocol interface in *Interface
> if the return status is EFI_SUCCESS or EFI_ALREADY_STARTED.
> 2) Interface is re
Spec + Pach Looks fine to me.
- Original Message -
Sender : Star Zeng
Date : 2017-06-28 18:52 (GMT+5:30)
Title : [PATCH V5] MdeModulePkg/DxeCore: Fixed Interface returned by
CoreOpenProtocol
To : edk2-devel@lists.01.org
CC : Amit Kumar, null,
null, null,
null, null
From:
Ray,
Does XhciPei need the same update?
Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni
Sent: Wednesday, June 28, 2017 6:40 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH 0/3] Check timeout URB again after stopping en
From: Amit Kumar
Change since v4: Revise the patch based on V4 sent by Amit Kumar
1) Only return the corresponding protocol interface in *Interface
if the return status is EFI_SUCCESS or EFI_ALREADY_STARTED.
2) Interface is returned unmodified for all error conditions except
EFI_UNSUPPORTED and E
Just added note in https://mantis.uefi.org/mantis/view.php?id=1815, and I will
post the patch soon.
Thanks,
Star
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Wednesday, June 28, 2017 8:39 PM
To: Zeng, Star ; Amit Kumar ;
edk2-devel@lists.01.org
Cc: Kinney, Mich
On 28 June 2017 at 10:55, Zeng, Star wrote:
> Reviewed-by: Star Zeng
>
Thanks
Pushed as 1fb805b1eb5b
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, June 28, 2017 6:51 PM
> To: edk2-devel@lists.01.org; Zeng, Star ; Dong, Eric
>
> Cc:
On 06/28/17 11:34, Zeng, Star wrote:
> Laszlo,
>
> Summary the return status codes for OpenProtocol() as below.
> EFI_SUCCESS
> Return the protocol interface in *Interface if Attributes is not
> EFI_OPEN_PROTOCOL_TEST_PROTOCOL.
> EFI_INVALID_PARAMETER
> Do not update *Interface because one of
BTW, I ported the disconnect code (under
ShellPkg\Library\UefiShellDriver1CommandsLib) to a standalone application
and it fails too. Looks like there is something else in the shell app that
is taking care of properly disconnecting the controller.
Thanks
On Tue, Jun 27, 2017 at 5:54 PM, TVKR wrot
Hi everyone
I have a question.
Some time ago, at this conversation "
https://www.mail-archive.com/edk2-devel@lists.01.org/msg25383.html"; it was
mentioned the UEFI ABI calling convention.
I've tried to search for some document with the details of this calling
convention, but didn't find anything.
Reviewed-by: Star Zeng
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Wednesday, June 28, 2017 6:51 PM
To: edk2-devel@lists.01.org; Zeng, Star ; Dong, Eric
Cc: Tian, Feng ; leif.lindh...@linaro.org; Ard Biesheuvel
Subject: [PATCH v3] MdeModulePkg/Ata
The SATA spec mandates that link detection by the PHY completes within
10 ms after receiving a reset signal. However, there is no obligation
to uphold this requirement at the driver end as strictly as we do, and
as it turns out, some combinations of host and device (e.g., Samsung
850 EVO connected
On 28 June 2017 at 10:44, Zeng, Star wrote:
> The delay duration may be 0 - EFI_AHCI_BUS_PHY_DETECT_TIMEOUT ms, and the
> comments are for all cases, but not for specific cases.
>
> How about to just simplify the comments like below?
>
> //
> // Wait the Phy to detect the presence of
The delay duration may be 0 - EFI_AHCI_BUS_PHY_DETECT_TIMEOUT ms, and the
comments are for all cases, but not for specific cases.
How about to just simplify the comments like below?
//
// Wait the Phy to detect the presence of a device.
//
Thanks,
Star
-Original Message---
This fixes BULK data loss when transfer is detected as timeout but
finished just before stopping endpoint.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Hao A Wu
Cc: Star Zeng
Cc: Feng Tian
---
MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 31 --
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Hao A Wu
Cc: Star Zeng
Cc: Feng Tian
---
MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xh
Current implementation of IsTransferRingTrb only checks whether
the TRB is in the RING of the URB.
The patch enhanced the logic to check that whether the TRB belongs
to the transaction of URB.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Hao A Wu
Cc: Star Z
This fixes BULK data loss when transfer is detected as timeout but
finished just before stopping endpoint.
Ruiyu Ni (3):
MdeModulePkg/XhciDxe: Refine IsTransferRingTrb and IsAsyncIntTrb
MdeModulePkg/XhciDxe: Dump the CMD/EVENT/INT/BULK ring information
MdeModulePkg/XhciDxe: Check timeout URB
> On 28 Jun 2017, at 09:53, Zeng, Star wrote:
>
> The real delay may be 0ms if the DET register value just pass the check after
> the first AhciReadReg().
> But what does "Wait at least 10 ms" mean?
>
If there is a link, it may be detected in 0 ms. If there is no link, it will
take at least
The real delay may be 0ms if the DET register value just pass the check after
the first AhciReadReg().
But what does "Wait at least 10 ms" mean?
Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
Biesheuvel
Sent: Wednesday, June 28
Laszlo,
Summary the return status codes for OpenProtocol() as below.
EFI_SUCCESS
Return the protocol interface in *Interface if Attributes is not
EFI_OPEN_PROTOCOL_TEST_PROTOCOL.
EFI_INVALID_PARAMETER
Do not update *Interface because one of the parameters has a value that does
not allow this
On 28 June 2017 at 08:49, Tian, Feng wrote:
> Ard & Star,
>
> I agree this patch to solve device compatible issue as it has no side effect
> for normal case.
>
> Just a minor correction:
> SATA 2.5 spec says: "If a device is present, the Phy shall take no longer
> than 10 ms to indicate that it
On 28 June 2017 at 08:31, Zeng, Star wrote:
> The updated comments "Wait at least 10 ms" seems not correct.
>
That is the whole point of the change. The SATA spec mandates that the
PHY respond within 10 ms. It does *not* mandate that the software wait
10 ms or less, rather the opposite, i.e., tha
The updated comments "Wait at least 10 ms" seems not correct.
Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
Biesheuvel
Sent: Wednesday, June 28, 2017 4:23 PM
To: edk2-devel@lists.01.org; Zeng, Star
Cc: Tian, Feng ; Dong, Eric
The SATA spec mandates that link detection by the PHY completes within
10 ms after receiving a reset signal. However, there is no obligation
to uphold this requirement at the driver end as strictly as we do, and
as it turns out, some combinations of host and device (e.g., Samsung
850 EVO connected
Ard,
Could you also refine the comments below in AhciModeInitialization() in the
patch?
//
// Wait no longer than 10 ms to wait the Phy to detect the presence of a
device.
// It's the requirment from SATA1.0a spec section 5.2.
//
Thanks,
Star
-Original Message-
54 matches
Mail list logo
