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
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
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
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 0ea970e
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
---
TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Brown <mc...@ipxe.org>
---
EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c
b/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c
index 8af23df..aaba
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
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
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
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
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
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
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
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
On 31/03/16 14:06, Dong, Eric wrote:
1. Enhance the Results string for ExtractConfig function like below:
Request = “GUID===&…”
Results = “GUIDValue1=Value2=Value3…”
PS: Red string you can get from the input Request string. Blue string is
the true value for each knob in your driver.
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===&=&=&...&=
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
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
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
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
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
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
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
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
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
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
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
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
32 matches
Mail list logo
