[ipxe-devel] [RFC] Why does ARM set -mcpu=cortex-a15

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.

Re: [ipxe-devel] [PATCH 1/1] [efi] avoid unaligned read in efi_devpath_end()

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    bne.n   8 >>

[ipxe-devel] [PATCH 1/1] [arm] add -mno-unaligned-access compiler flag

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_devpath_end(). The flag is usable both with GCC and LLVM. With some console commands enabled bin-arm32-efi/snp.efi grows from 148448 to 154464 bytes. Signed-off-by:

Re: [ipxe-devel] [PATCH 1/1] [efi] avoid unaligned read in efi_devpath_end()

On 28/03/18 20:23, Heinrich Schuchardt wrote: : 0: 7803ldrbr3, [r0, #0] <<< Reading on byte 2: 2b7fcmp r3, #127; 0x7f 4: d100bne.n 8 6: 4770bx lr 8: 8843

Re: [ipxe-devel] [PATCH 1/1] [efi] avoid unaligned read in efi_devpath_end()

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 to produce an unaligned access abort, since it just >>> dereferences

Re: [ipxe-devel] [PATCH 1/1] [efi] avoid unaligned read in efi_devpath_end()

On 28/03/18 20:11, Heinrich Schuchardt wrote: with the patch above I reach the iPXE prompt on a BananaPi. But when executing the dhcp command I see another "data abort", see below. I am trying to track down, in which routine this happens. The error occurs in monojob_wait(). Where do I find the

Re: [ipxe-devel] [PATCH 1/1] [efi] avoid unaligned read in efi_devpath_end()

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 to produce an unaligned access abort, since it just dereferences individual bytes.  What do you see if you disassemble the object

Re: [ipxe-devel] [PATCH 1/1] [efi] avoid unaligned read in efi_devpath_end()

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: Heinrich Schuchardt

Re: [ipxe-devel] [PATCH 1/1] [efi] avoid unaligned read in efi_devpath_end()

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 path->Length was on an uneven address. > >

Re: [ipxe-devel] [PATCH 1/1] [efi] avoid unaligned read in efi_devpath_end()

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 path->Length was on an uneven address. There's no way that the code: -( (

[ipxe-devel] [PATCH 1/1] [efi] avoid unaligned read in efi_devpath_end()

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 file

Re: [ipxe-devel] [PATCH 1/1] elf2efi: add support for R_ARM_REL32

On 27/03/18 18:07, Heinrich Schuchardt wrote: 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. Applied; thank