Hello Michael,
when the system running iPXE is slower than the iSCSI server the
transfer of large file reproducibly fails.
The failure starts when the receive buffer is filled up. No message is
sent by iPXE for a few seconds. Afterwords a new login to the iSCSI
server occurs.
Here is some of th
On 14.07.19 17:00, Christian Nilsson wrote:
On Sun, 14 Jul 2019, 16:18 Heinrich Schuchardt, mailto:xypron.g...@gmx.de>> wrote:
Hello Michael,
building bin-i386-efi/snp.efi fails with GCC 9.1.0.
I am using the testing branch of the Manjaro distribution.
Best r
Hello Michael,
building bin-i386-efi/snp.efi fails with GCC 9.1.0.
I am using the testing branch of the Manjaro distribution.
Best regards
Heinrich
[BUILD] bin-i386-efi/string.o
core/gdbudp.c: In function ‘gdbudp_configure’:
core/gdbudp.c:235:47: error: taking address of packed member of ‘
On 1/19/19 1:14 PM, Christian Nilsson wrote:
> On Sat, 19 Jan 2019 at 13:03, Heinrich Schuchardt wrote:
>>
>> Hello Michael,
>>
>> Linux distributions are struggling hard to create reproducible builds.
>> This means if you run the make script twice you should g
Hello Michael,
Linux distributions are struggling hard to create reproducible builds.
This means if you run the make script twice you should get exactly the
same binary. Cf. https://wiki.debian.org/ReproducibleBuilds
Currently iPXE is introducing a random number as build id:
# Command to generat
Hello Michael,
this patch still is needed to build bin-arm64-efi/snp.efi.
Any reason why this cannot be merged?
Best regards
Heinrich
On 08/25/2018 08:01 AM, Heinrich Schuchardt wrote:
> On 08/24/2018 01:34 AM, Michael Brown wrote:
>> On 23/08/18 21:12, Heinrich Schuchardt wrote:
Hello Michael,
this patch still is needed to build bin-arm64-efi/snp.efi.
Any reason why this cannot be merged?
Best regards
Heinrich
On 08/25/2018 08:06 AM, Heinrich Schuchardt wrote:
> Patch 1c47eb186e7e ("[build] Conditionalise use of -mabi=lp64 for ARM64
> builds") ca
On 08/04/2018 02:57 PM, Heinrich Schuchardt wrote:
> The following patch breaks building for arm64 with GCC 8.1.0 (as
> supplied by package gcc-aarch64-linux-gnu in Debian Buster):
>
> commit 1a7746603bca1022b63c406c9459525312a2b2b6
> Author: Michael Brown
> Date: Fri Ju
On 08/26/2018 11:33 AM, Heinrich Schuchardt wrote:
> On 08/04/2018 02:57 PM, Heinrich Schuchardt wrote:
>> The following patch breaks building for arm64 with GCC 8.1.0 (as
>> supplied by package gcc-aarch64-linux-gnu in Debian Buster):
>>
>> commit 1a7746603bca1
t; \
^~~
include/errno.h:534:16: note: in expansion of macro ‘__einfo_error’
GCC 4.8 is obsolete. It has not seen any update since 2014.
So let's remove the undocumented operand modifer.
Fixes: 1a7746603bca ("Fix use of inline assembly on GCC 4.8 ARM64 builds")
Signed-off-by
Thanks for reviewing.
Is there also an architecture specific bin/error target?
Maybe we need some architecture specific #define for the prefix.
Regards
Heinrich
Am 26.08.18, 23:47, Michael Brown schrieb:
On 26/08/18 11:45, Heinrich Schuchardt wrote:
> diff --git a/src/include/errno.h b/
guments to ‘-mabi=’ are: ms sysv
make[3]: *** [Makefile.housekeeping:1397: util/elf2efi64] Error 1
Fixed: 1c47eb186e7e ("[build] Conditionalise use of -mabi=lp64 for ARM64
builds")
Signed-off-by: Heinrich Schuchardt
---
src/arch/arm64/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --
On 08/24/2018 01:34 AM, Michael Brown wrote:
> On 23/08/18 21:12, Heinrich Schuchardt wrote:
>> Avoid the following error with gcc 7.3:
>>
>> In function ‘process_section’,
>> inlined from ‘elf2pe.isra.4’ at util/elf2efi.c:914:25:
>> util/elf2efi.c:497:2: e
new->hdr.Name ) );
^~~~
cc1: all warnings being treated as errors
The truncation to eight charactres is desired here, so we don't want this
warning to create an error.
Signed-off-by: Heinrich Schuchardt
---
src/util/el
On 08/04/2018 02:57 PM, Heinrich Schuchardt wrote:
> The following patch breaks building for arm64 with GCC 8.1.0 (as
> supplied by package gcc-aarch64-linux-gnu in Debian Buster):
>
> commit 1a7746603bca1022b63c406c9459525312a2b2b6
> Author: Michael Brown
> Date: Fri Ju
m': invalid address mode
__asm__ ( ".section \".einfo\", \"\", " PROGBITS_OPS "\n\t" \
^~~
include/errno.h:589:17: note: in expansion of macro ‘__einfo_erro
Please, correct the coding.
Best regards
Heinrich Schuchardt
On 03/29/2018 06:08 PM, Heinrich Schuchardt wrote:
> On 03/29/2018 11:20 AM, Mark Rutland wrote:
>> Hi,
>>
>> On Wed, Mar 28, 2018 at 10:19:50PM +0200, Heinrich Schuchardt wrote:
>>> Without the flag a "data abort" occured when compiling with gcc 6.3 for
&
On 03/29/2018 11:20 AM, Mark Rutland wrote:
> Hi,
>
> On Wed, Mar 28, 2018 at 10:19:50PM +0200, Heinrich Schuchardt wrote:
>> Without the flag a "data abort" occured when compiling with gcc 6.3 for
>> armhf and running on an Allwinner A20 SOC in function efi_devpa
Hello Michael,
I have some questions concerning the compilation flags used by iPXE on ARM.
There are a lot of different ARM CPUs available. Why do we set
-mcpu=cortex-a15?
This would for instance exclude i.mx6 CPUs which are Cortex-A9.
The Allwinner A20 I am currently testing on is Cortex-A7.
A
On 03/28/2018 09:25 PM, Michael Brown wrote:
> On 28/03/18 20:23, Heinrich Schuchardt wrote:
>> :
>> 0: 7803 ldrb r3, [r0, #0] <<< Reading on byte
>> 2: 2b7f cmp r3, #127 ; 0x7f
>> 4: d100
ned-off-by: Heinrich Schuchardt
---
src/arch/arm32/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/arch/arm32/Makefile b/src/arch/arm32/Makefile
index 3a7c0923..fc72af11 100644
--- a/src/arch/arm32/Makefile
+++ b/src/arch/arm32/Makefile
@@ -5,6 +5,7 @@ SRCDIRS += arch/ar
On 03/28/2018 09:12 PM, Michael Brown wrote:
> On 28/03/18 20:10, Heinrich Schuchardt wrote:
>>> There's no way that the code:
>>>
>>>> - ( ( path->Length[1] << 8 ) | path->Length[0] ) );
>>>
>>> should ever be able
On 03/28/2018 08:49 PM, Heinrich Schuchardt wrote:
> The old coding resulted in a "data abort" when compiled with gcc 6.3 for
> armhf and run on an Allwinner A20 SOC.
>
> The unaligned access occured when path->Length was on an uneven address.
>
> Signed-off-by: He
On 03/28/2018 09:02 PM, Michael Brown wrote:
> On 28/03/18 19:49, Heinrich Schuchardt wrote:
>> The old coding resulted in a "data abort" when compiled with gcc 6.3 for
>> armhf and run on an Allwinner A20 SOC.
>>
>> The unaligned access occured when
The old coding resulted in a "data abort" when compiled with gcc 6.3 for
armhf and run on an Allwinner A20 SOC.
The unaligned access occured when path->Length was on an uneven address.
Signed-off-by: Heinrich Schuchardt
---
src/interface/efi/efi_utils.c | 7 +--
1 fi
The relocation type R_ARM_REL32 is generated when building
bin-arm32-efi/snp.efi using gcc 6.3 and ld 2.28.
R_ARM_REL32 is a program counter (PC) relative 32 bit relocation so we can
ignore it like all other PC relative relocations.
Signed-off-by: Heinrich Schuchardt
---
src/util/elf2efi.c | 1
ip many PC-relative relocations.
Should R_ARM_REL32 be added to this list?
Best regards
Heinrich Schuchardt
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
.
>
> Heinrich: Could you please test and let me know if this fixes iSCSI
> booting within U-Boot?
>
> Thanks,
>
> Michael
>
Thank you for your swift response.
The essential patch on the U-Boot side is
https://lists.denx.de/pipermail/u-boot/2018-March/323678.html
On 03/24/2018 05:24 PM, Heinrich Schuchardt wrote:
> On 03/24/2018 05:16 PM, Heinrich Schuchardt wrote:
>> As noted in the comments, UEFI manages to combines the all of the
>> worst aspects of both a polling design (inefficiency and inability to
>> sleep until something intere
On 03/24/2018 05:16 PM, Heinrich Schuchardt wrote:
> As noted in the comments, UEFI manages to combines the all of the
> worst aspects of both a polling design (inefficiency and inability to
> sleep until something interesting happens) and of an interrupt-driven
> design (the comple
Hello Michael,
local files can be addressed as
file:///path/filename.ext
according to RFC 1738.
iPXE deviates from this notation by using
file:/path/filename.ext
Unfortunately on none of the pages
http://ipxe.org/cmd/chain
http://ipxe.org/cmd/kernel
a file uri is shown.
Especially for the
Hello Michael,
do you have any plans for supporting the EFI_ISCSI_INITIATOR_NAME_PROTOCOL?
This service could be used to seed environment variable initiator-iqn
(cf. http://ipxe.org/cfg/initiator-iqn).
Best regards
Heinrich
___
ipxe-devel mailing l
In version U-Boot 2018.03-rc1 all patches have been merged that are
needed to launch iPXE's snp.efi target and boot from an iSCSI drive on
ARM systems.
The only adjustment necessary in iPXE was disabling CPU nap using
src/config/local/nap.h.
http://git.denx.de/?p=u-boot.git;a=blob;f=doc/READ
iscsi drives are exposed to grub.
Best regards
Heinrich Schuchardt
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
,0xa6d56afb,0x800,0x3f800)
is not a child device of
/HD(1,MBR,0xa6d56afb,0x800,0x3f800)
Signed-off-by: Heinrich Schuchardt
---
src/interface/efi/efi_block.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/interface/efi/efi_block.c b/src/interface/efi/efi_block.c
index c6445ab6..9a71fd08 100644
Hello Michael,
the colors used by iPXE seem to depend on random addresses:
interface/efi/efi_wrap.c:47:#define colour &efi_systab_wrapper
interface/efi/efi_timer.c:53:#define colour &efi_jiffies
arch/x86/core/runtime.c:84:#define colour &cmdline_image
arch/x86/core/cachedhcp.c:48:#define colour &
On 09/24/2017 07:15 PM, Michael Brown wrote:
> On 10/09/17 07:37, Heinrich Schuchardt wrote:
>> Indicate if the executable was compiled to create 32- or 64-bit EFI
>> files.
>> Enumerate EFI subsystems.
>> Treat -? like -h.
>
> Any particular reason for this
Relocation type R_ARM_V4BX requires no computation.
It marks the location of an ARMv4 branch exchange instruction.
Signed-off-by: Heinrich Schuchardt
---
When using elf2efi.c in a separate project I happened to stumble
over this relocation type.
I would prefer if the change could be integrated
Indicate if the executable was compiled to create 32- or 64-bit EFI
files.
Enumerate EFI subsystems.
Treat -? like -h.
Signed-off-by: Heinrich Schuchardt
---
src/util/elf2efi.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/util/elf2efi.c b/src/util
On 08/26/2017 07:00 PM, Michael Brown wrote:
> On 26/08/17 17:11, Heinrich Schuchardt wrote:
>>> If you somehow have SetTimer() working without being interrupt driven,
>>> then I am prepared to commit a patch to iPXE which avoids halting the
>>> CPU if interrupts
On 07/14/2017 11:03 AM, Michael Brown wrote:
> On 14/07/17 03:39, Heinrich Schuchardt wrote:
>>> I assume that the equivalent is true on ARM, but you should check the
>>> documentation to be sure.
>>
>> And what do we do if some interrupts are implemented by a pla
On 08/25/2017 11:11 PM, Michael Brown wrote:
> On 25/08/17 20:17, Heinrich Schuchardt wrote:
>> I have finally succeeded to get the network running when starting iPXE
>> from U-Boot. So we will be able to use iPXE on Raspberry Pi class
>> devices.
>
> Awesome!
>
&
Hello Michael,
I have finally succeeded to get the network running when starting iPXE
from U-Boot. So we will be able to use iPXE on Raspberry Pi class devices.
I have an iSCSI target to which I easily can connect using openscsi.
Unfortunately with iPXE's snp.efi I get the errors below.
Could yo
On 08/20/2017 11:28 PM, Michael Brown wrote:
> On 20/08/17 21:25, Heinrich Schuchardt wrote:
>> U-Boot exposes the Simple Network Protocol in the UEFI interface but no
>> underlying PCI devices.
>>
>> As shown in the appended log the start routine of the binding protoco
The user class option for DHCP is defined in RFC 3004.
The third byte of the user class data must be the length
of the first user class value.
Signed-off-by: Heinrich Schuchardt
---
src/net/udp/dhcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/net/udp/dhcp.c b/src
Hello Michael,
U-Boot exposes the Simple Network Protocol in the UEFI interface but no
underlying PCI devices.
As shown in the appended log the start routine of the binding protocol
gives up after finding no PCI device related to the SNP service
(EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL_GUID_31
On 07/14/2017 12:08 AM, Michael Brown wrote:
> On 13/07/17 06:50, Heinrich Schuchardt wrote:
>>> You could add code in efiarm_nap.c and/or efix86_nap.c to detect whether
>>> or not it is safe to sleep the CPU. The attached (completely untested)
>>> patch demonstrates
On 07/14/2017 12:15 AM, Michael Brown wrote:
> On 13/07/17 12:00, Heinrich Schuchardt wrote:
>> Why do we need cpu_nap in the keyboard loop at all when we are in an
>> UEFI context. Shouldn't UEFI WaitForEvent be used to care about the idle
>> CPU?
>
>
On 07/13/2017 01:35 AM, Michael Brown wrote:
> On 12/07/17 19:50, Heinrich Schuchardt wrote:
>> On 07/12/2017 08:35 PM, Michael Brown wrote:
>>> On 12/07/17 19:15, Heinrich Schuchardt wrote:
>>>> Nope. Interrupts are not supported by U-Boot. To get them r
On 07/13/2017 01:35 AM, Michael Brown wrote:
> On 12/07/17 19:50, Heinrich Schuchardt wrote:
>> On 07/12/2017 08:35 PM, Michael Brown wrote:
>>> On 12/07/17 19:15, Heinrich Schuchardt wrote:
>>>> Nope. Interrupts are not supported by U-Boot. To get them r
On 07/12/2017 08:34 PM, Michael Brown wrote:
> On 12/07/17 19:20, Heinrich Schuchardt wrote:
>>> Not quite. It's supposed to find the closest SNP-supporting parent of
>>> the specified device. The idea is not just to find any SNP, but to find
>>> the SNP from
On 07/12/2017 08:35 PM, Michael Brown wrote:
> On 12/07/17 19:15, Heinrich Schuchardt wrote:
>> Nope. Interrupts are not supported by U-Boot. To get them running every
>> architecture implementation would have to be changed.
>>
>> U-Boot simply uses a call inside the w
On 07/12/2017 08:06 PM, Michael Brown wrote:
> On 12/07/17 19:03, Heinrich Schuchardt wrote:
>>> That patch seems to completely negate the purpose of the existing
>>> efi_locate_device() function. What is it that you are trying to
>>> achieve?
>>
>> My
On 07/12/2017 08:05 PM, Michael Brown wrote:
> On 12/07/17 18:57, Heinrich Schuchardt wrote:
>> On 07/12/2017 07:47 PM, Michael Brown wrote:
>>> On 12/07/17 18:45, Heinrich Schuchardt wrote:
>>>> U-Boot runs single-threaded without interrupts.
>>>> When cp
On 07/12/2017 07:49 PM, Michael Brown wrote:
> On 12/07/17 18:46, Heinrich Schuchardt wrote:
>> Currently efi_locate_device looks for a device supporting a
>> protocol only in the list of parents. This leads to errors like
>> EFIDEV m...@72000.blk has no parent sup
On 07/12/2017 07:47 PM, Michael Brown wrote:
> On 12/07/17 18:45, Heinrich Schuchardt wrote:
>> U-Boot runs single-threaded without interrupts.
>> When cpu_nap is called the process is never woken up again.
>
> #ifdef is not allowed for this sort of fix, sorry.
What is your
efi_locate_device returns the device if it supports
the protocol. Otherwise it returns the fist device it can find
supporting the protocol.
Signed-off-by: Heinrich Schuchardt
---
src/interface/efi/efi_utils.c | 57 ++-
1 file changed, 29 insertions(+), 28
U-Boot runs single-threaded without interrupts.
When cpu_nap is called the process is never woken up again.
With the patch we can use environment variable CPUNONAP
to disable cpu_nap when building iPXE, e.g.
CPUNONAP=1
Signed-off-by: Heinrich Schuchardt
---
src/Makefile.housekeeping
#x27; has become
obsolete.
Tag `XML_SCHEMA' at line 1110 of file `doxygen.cfg' has become obsolete.
Tag `XML_DTD' at line 1116 of file `doxygen.cfg' has become obsolete.
doxygen no longer ships with the FreeSans font.
The patch contains the changes after running
doxygen -u dox
On 06/24/2017 11:14 AM, Christian Nilsson wrote:
> On Sat, Jun 24, 2017 at 8:20 AM, Heinrich Schuchardt
> wrote:
>> Hello Christian,
>>
>> thank you for supplying the page http://ipxe.org/appnote/buildtargets/.
>
> It has been needing documentation for quite som
i
sections:
http://ipxe.org/docs#application_notes
http://ipxe.org/download#source_code
In http://ipxe.org/download#source_code the line
make
without any build target should be replaced by
make [platform]/[driver].[extension]
to match your application note.
Best regards
Heinrich
ss it would help to cut down build time to create separate static
libraries for hardware drivers and other drivers.
Targets snponly and undionly would not have to build the hardware driver
library.
Best regards
Heinrich Schuchardt
$ make V=1 bin-arm64-efi/snponly.efi
gcc -DARCH=arm64 -DPLA
On 06/23/2017 07:52 PM, Christian Nilsson wrote:
> On Fri, Jun 23, 2017 at 7:19 PM, Heinrich Schuchardt
> wrote:
>> I try to build ipxe on arm64 Debian Stretch:
>>
>> git checkout 14e3b4b29a96eda6230b1c2dac6cc5e793235d5a
>> cd src/
>> make V=1 bin-arm64-efi
‘-q’
gcc: error: unrecognized command line option ‘--gc-sections’; did you mean
‘--data-sections’?
: recipe for target 'bin-arm64-efi/snp' failed
$ gcc --version
gcc (Debian 6.3.0-18) 6.3.0 20170516
Linker options should be passed with -Wl.
Signed-off-by: Heinrich Schuchardt
64 matches
Mail list logo
