On 17/04/18 09:01, Laszlo Ersek wrote:
The thing is, the BeIoLib and LeIoLib classes are already good for this
-- they can be implemented as you suggest. So no need to call the
function SwapIfNeededForBigEndianDeviceMmioRead16(), just call it
BeMmioRead16().
I know. I thought that suggesting a
On 16/04/18 21:42, Laszlo Ersek wrote:
On 04/16/18 16:34, Michael Brown wrote:
On 16/04/18 15:10, Kinney, Michael D wrote:
I think we only need a single lib class and lib
Instance that does the byte swap and we should
not use Le or Be in any of the names of the class,
instance, or APIs. Just
On 16/04/18 15:10, Kinney, Michael D wrote:
I agree that the opposite use case is a BE CPU
needing a LE operation.
I think we only need a single lib class and lib
Instance that does the byte swap and we should
not use Le or Be in any of the names of the class,
instance, or APIs. Just "Swap".
On 23/03/18 11:58, Wasim Khan wrote:
Ex: if auto-neg timeout is 5 seconds and if we have 10 network interfaces (all
are legal candidate for booting), and cable is connected to 3rd interface only
then 45 seconds will be wasted (5 seconds each for 9 interfaces) in auto-neg of
interfaces which ar
On 28/09/17 18:37, Konrad Rzeszutek Wilk wrote:
!!! X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID -
ExceptionData -
RIP - BEC2949C, CS - 0038, RFLAGS - 00210216
>
Find image 808610ed.efidrv (ImageBase=00
On 29/06/16 02:52, Gary Lin wrote:
On Tue, Jun 28, 2016 at 01:43:31PM +0100, Michael Brown wrote:
diff --git a/src/interface/efi/efi_hii.c b/src/interface/efi/efi_hii.c
index 0ea970e..506fc88 100644
--- a/src/interface/efi/efi_hii.c
+++ b/src/interface/efi/efi_hii.c
@@ -117,6 +117,7 @@ static
On 28/06/16 13:34, Michael Brown wrote:
On 28/06/16 13:30, Laszlo Ersek wrote:
On 06/24/16 06:39, Gary Lin wrote:
It seems that iPXE didn't initialize Scope, so the value was assigned
randomly (sort of).
diff --git a/src/interface/efi/efi_hii.c b/src/interface/efi/efi_hii.c
index 0e
On 28/06/16 13:30, Laszlo Ersek wrote:
On 06/24/16 06:39, Gary Lin wrote:
It seems that iPXE didn't initialize Scope, so the value was assigned
randomly (sort of).
diff --git a/src/interface/efi/efi_hii.c b/src/interface/efi/efi_hii.c
index 0ea970e..4b5aa9a 100644
--- a/src/interface/efi/efi_hi
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 (inclusive) are filled with
garbage.
Awesome debugging; than
Conform to the specification for GetStatus(), which states that "if
there are no transmit buffers to recycle and TxBuf is not NULL, *TxBuf
will be set to NULL".
Cc: Leif Lindholm
Cc: Ard Biesheuvel
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Mic
On 18/04/16 02:57, Liuxilong (A) wrote:
We also do not want to make all of the boards the same MAC
address. But our client requires us to do it. The client thinks that VLAN can
solve this conflict of the same MAC through VLAN's isolation. What do you think
about it?
It's a ba
On 15/04/16 12:00, Gao, Liming wrote:
In UI, the question is shown to user, such as checkbox, oneof,
orderlist, password. One HII driver exposes multiple questions. Those
questions may refer to one buffer storage. For this usage, the C
structure can be used as the buffer storage. Each question
On 14/04/16 15:24, Andrew Fish wrote:
It is hard to argue that using Hii to do simple things is kind of complex and
hard to Grok.
Not really. Three people on this list (myself, Laszlo, and Eric) all
managed to independently make the exact same mistake. Either we're all
incompetent, or ther
On 13/04/16 17:04, Gao, Liming wrote:
UEFI spec Chapter 31 Human Interface Infrastructure Overview and
Chapter section 2 Design discussion and Chapter 33 HII Configuration
Processing and Browser Protocol section 2 Configuration Strings gives
the details on UEFI HII design and Configuration str
On 13/04/16 15:55, Andrew Fish wrote:
OK, but why? What is the concrete purpose of this, that could not be achieved
by more simply having multiple EFI_HII_CONFIG_ACCESS_PROTOCOL instances?
I think it has to do with the limitation of one protocol per handle. If there
are multiple instances ho
On 13/04/16 03:33, Dong, Eric wrote:
Does the ConfigHdr have any meaning for EFI_HII_CONFIG_ACCESS_PROTOCOL,
or is it just a pointless blob of noise?
The GUID/NAME value in the ConfigHdr is get from the storage used in this
driver. If one driver has more than one storage, the Guid +
Name spec
On 06/04/16 14:39, Liuxilong (A) wrote:
Multiple boards connect to the DHCP server through a switch .
The MAC of each board is the same and building VLAN through the switch
to isolate each board.
Don't do that. Use a unique MAC address for each board.
If I understand you correctly,
On 05/04/16 03:10, Dong, Eric wrote:
On a separate but related note: The ConfigHdr portion of Request and
Response seems to contain absolutely zero information by the time it
reaches EFI_HII_CONFIG_ACCESS_PROTOCOL. As far as I can tell, it is
meaningful only to EFI_HII_CONFIG_ROUTING_PROTOCOL an
On 01/04/16 21:41, Laszlo Ersek wrote:
I am (and was) aware of "MdeModulePkg/Universal/DriverSampleDxe", the same
driver that Eric recommended as an example in this thread earlier. In my opinion, that
driver is supremely over-sized and -cluttered to be usable as a learning tool.
I'm glad it's
On 31/03/16 14:06, Dong, Eric wrote:
1. Enhance the Results string for ExtractConfig function like below:
Request = “GUID=&NAME=&PATH=&gateway&ip&netmask&…”
Results = “GUID=&NAME=&PATH=&gateway=Value1&ip=Value2&netmask=Value3…”
PS: Red string you can get from the input Request string. Blue stri
On 31/03/16 14:37, Michael Brown wrote:
In a nutshell, I think iPXE should:
- reflect the GUID / NAME / PATH triplet from the input to the output
verbatim,
- for each config knob requested, respond with
=.
(See also: "if a ConfigHdr is passed in with no request elements, all
of the set
On 31/03/16 11:13, Laszlo Ersek wrote:
Which translates to the following response string:
GUID=&NAME=&PATH=&=&=&...&=
In a nutshell, I think iPXE should:
- reflect the GUID / NAME / PATH triplet from the input to the output verbatim,
- for each config knob requested, respond with =.
(See also
On 31/03/16 07:40, Liuxilong (A) wrote:
Recently, we used our board to do some tests about PXE booting and
encountered an issue . Sometimes the PXE booting would fail when*the PXE
client sent a request to confirm IP but received the NACK from the DHCP
server*, which is displayed in the figure bel
On 31/03/16 02:17, Dong, Eric wrote:
Those sections of the UEFI spec are so badly written that I cannot begin
to guess what might count as either correct or incorrect.
Could you please give a concrete example of what you think iPXE should
be returning here?
We have a sample driver in MdeModule
On 30/03/16 16:27, Dong, Eric wrote:
I download the iPXE code and check the hii related code. I'm very confused why
you dynamic generate the ifr data? Why not use vfr file to descript the form
data? Use vfr file is much easy than dynamic generate it. Also I found you use
name/value store to sa
On 30/03/16 16:09, Dong, Eric wrote:
This error is caused by iPXE driver not return the correct string in
EFI_HII_CONFIG_ACCESS_PROTOCOL.ExtractConfig() function. Base on the spec
requirement, if the function return success, the Results string should follow
format. But the data returned by iPX
On 29/03/16 16:20, Laszlo Ersek wrote:
recent edk2 commit 8a45f80edad4 ("MdeModulePkg: Make HII configuration settings
available to OS runtime") seems to trigger an issue between edk2 and iPXE.
Thanks for debugging this!
Is iPXE misbehaving here? At the time that I implemented our HII
suppo
On 18/03/16 22:30, Laszlo Ersek wrote:
Unfortunately, I've run into a big issue: the DEBUG(()) macro. (To a
smaller extent, the ASSERT_EFI_ERROR() macro as well.) These macros
expand to the null replacement string when MDEPKG_NDEBUG is defined
(which is occasionally the case for RELEASE builds).
On 22/01/16 02:59, Fu, Siyuan wrote:
Thanks Michael, maybe use UUID is a good way to solve this issue. But I still
curious why the server has such requirement which is apparent violate the RFC
requirement. Could you provide more details?
The DHCPv6 RFC was designed without taking network boot
On 21/01/16 10:13, Jim Hung (洪銘駿) wrote:
There is one network issue in customer datacenter, the
“ClientID/DUID/Link-Layer Address” is not bundled with the MAC from source
network device if multi LANs on the system. And, this cause the PXE boot
failure at customer datacenter environment.
On ou
On 16/12/15 23:53, Mahan, Patrick wrote:
If the option ROM is disabled, would you agree that degrading the BARs from
64-bit to 32-bit should be skipped?
Also, if the driver is not coming from the option ROM, should the BARs still be
degraded?
There are use cases when the legacy network boot c
On 14/12/15 23:35, El-Haj-Mahmoud, Samer wrote:
We ran into the same issue of automatic demoation simply because of the
presence of an OptionROM. We believe this is an overly aggressive policy. In
fact, I have a patch that I am about to submit that adds a platform PCD to
enable/disable this po
On 26/10/15 11:05, Heyi Guo wrote:
I'm using PXE BC protocol in MdeModulePkg (and other network protocols
in the same package), and we found PXE might fail when there are two
DHCP servers in the subnet, one for dedicated PXE boot and one general
DHCP server.
How can I resolve such issue?
Fix t
On 19/10/15 18:20, Andrew Fish wrote:
I was porting some code the other day and I hit a compiler warning that
PXE_OPFLAGS_STATION_ADDRESS_READ and PXE_OPFLAGS_STATION_ADDRESS_WRITE had the
same value? Is this correct, I didn’t see the value in the UEFI spec?
https://github.com/tianocore/edk2/b
On 15/10/15 23:33, Andrew Fish wrote:
The EFI Driver Model, lets you connect and disconnect, drivers as needed. The
EFI networking stack supports the EFI Manged Network Protocol to help manage
the network stack configuration. This is what was intended for normal operation.
I’m just guessing bu
On 14/10/15 07:13, Andrei Borzenkov wrote:
Well, now we have two *applications* each holding exclusive open on
adapter. I do not know details about iPXE but if there is any remote
chance it does background polling we are back at square one.
iPXE will obtain exclusive access to the underlying SN
36 matches
Mail list logo
