[U-Boot] Should UEFI be disabled on ARM11 boards by default?
Dear maintainers,
"Pull request for UEFI sub-system for efi-2020-01-rc4" disables the UEFI sub-system for all boards except ARMv8, ARMv7, ARM11. This is necessary as UEFI requires support for unaligned access. For ARM11 a function is provided to switch unaligned access support on.
Tom suggested to disable UEFI by default on ARM11 to reduce the size of the U-Boot binary. This would concern the following boards:
evb-ast2500_defconfig flea3_defconfig integratorcp_cm1136_defconfig mx31pdk_defconfig mx35pdk_defconfig rpi_0_w_defconfig rpi_defconfig woodburn_defconfig woodburn_sd_defconfig
At least the Raspberry boards should have no problem with UEFI enabled.
Do you see a necessity to use EFI_LOADER=n as default for any of the boards in the list above?
Best regards
Heinrich
Hi Heinrich,
On Tue, Nov 19, 2019 at 3:46 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
mx31pdk_defconfig mx35pdk_defconfig
No problem on disabling UEFI for the mx31/mx35 boards.
On 11/19/19 8:17 PM, Fabio Estevam wrote:
Hi Heinrich,
On Tue, Nov 19, 2019 at 3:46 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
mx31pdk_defconfig mx35pdk_defconfig
No problem on disabling UEFI for the mx31/mx35 boards.
Hello Fabio,
thanks for the swift reply.
https://git.kontron-electronics.de/linux/uboot-exceet/tree/2108f4c4a302a021a... suggests to use as partition:
0x00000000-0x00080000 : "Bootloader"
If you are constrained to 512 KiB, disabling UEFI on the MX35PDK might make sense.
On the MX31 we have OF_LIBFDT=n, so UEFI is not available anyway.
--
I tried to build mx35pdk_defconfig and mx35pdk_defconfig. I got an error
unrecognized -march target: armv5
Why is U-Boot built with -march=armv5 on ARM1136 and ARM1176 though they are armv6?
arch/arm/Makefile:11: arch-$(CONFIG_CPU_ARM1136) =-march=armv5 arch-$(CONFIG_CPU_ARM1176) =-march=armv5t
GCC 9.2.1 supports only the following armv5 and armv6 architectures:
armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk armv6t2 armv6-m armv6s-m
So at least the ARM1136 entry should be corrected. Which value would you suggest?
Best regards
Heinrich
Hi Heinrich,
On Tue, Nov 19, 2019 at 5:38 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
I tried to build mx35pdk_defconfig and mx35pdk_defconfig. I got an error
unrecognized -march target: armv5
Why is U-Boot built with -march=armv5 on ARM1136 and ARM1176 though they are armv6?
arch/arm/Makefile:11: arch-$(CONFIG_CPU_ARM1136) =-march=armv5 arch-$(CONFIG_CPU_ARM1176) =-march=armv5t
GCC 9.2.1 supports only the following armv5 and armv6 architectures:
armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk armv6t2 armv6-m armv6s-m
So at least the ARM1136 entry should be corrected. Which value would you suggest?
Maybe the generic armv6 entry?
Thanks
On Tue, Nov 19, 2019 at 10:44 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Dear maintainers,
"Pull request for UEFI sub-system for efi-2020-01-rc4" disables the UEFI sub-system for all boards except ARMv8, ARMv7, ARM11. This is necessary as UEFI requires support for unaligned access. For ARM11 a function is provided to switch unaligned access support on.
Tom suggested to disable UEFI by default on ARM11 to reduce the size of the U-Boot binary. This would concern the following boards:
evb-ast2500_defconfig
Sounds good to me for evb-ast2500
flea3_defconfig integratorcp_cm1136_defconfig mx31pdk_defconfig mx35pdk_defconfig rpi_0_w_defconfig rpi_defconfig woodburn_defconfig woodburn_sd_defconfig
At least the Raspberry boards should have no problem with UEFI enabled.
Do you see a necessity to use EFI_LOADER=n as default for any of the boards in the list above?
Best regards
Heinrich
On 19/11/2019 19:44, Heinrich Schuchardt wrote:
Dear maintainers,
"Pull request for UEFI sub-system for efi-2020-01-rc4" disables the UEFI sub-system for all boards except ARMv8, ARMv7, ARM11. This is necessary as UEFI requires support for unaligned access. For ARM11 a function is provided to switch unaligned access support on.
Tom suggested to disable UEFI by default on ARM11 to reduce the size of the U-Boot binary. This would concern the following boards:
evb-ast2500_defconfig flea3_defconfig integratorcp_cm1136_defconfig mx31pdk_defconfig mx35pdk_defconfig rpi_0_w_defconfig rpi_defconfig woodburn_defconfig woodburn_sd_defconfig
At least the Raspberry boards should have no problem with UEFI enabled.
So I'd prefer to have UEFI enabled on the RPi boards, so that we have one consistent boot for all Raspberry Pi variants.
Regards, Matthias
Do you see a necessity to use EFI_LOADER=n as default for any of the boards in the list above?
Best regards
Heinrich
On Tue, Nov 19, 2019 at 7:44 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Tom suggested to disable UEFI by default on ARM11 to reduce the size of the U-Boot binary. This would concern the following boards:
(...)
integratorcp_cm1136_defconfig
That's fine to go without UEFI.
Yours, Linus Walleij
X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.0 From: Heinrich Schuchardt xypron.glpk@gmx.de Date: Tue, 19 Nov 2019 19:44:47 +0100 Content-Language: en-US Cc: U-Boot Mailing List u-boot@lists.denx.de, Alexander Graf agraf@csgraf.de Content-Type: text/plain; charset="utf-8"; Format="flowed"
Dear maintainers,
"Pull request for UEFI sub-system for efi-2020-01-rc4" disables the UEFI sub-system for all boards except ARMv8, ARMv7, ARM11. This is necessary as UEFI requires support for unaligned access. For ARM11 a function is provided to switch unaligned access support on.
Tom suggested to disable UEFI by default on ARM11 to reduce the size of the U-Boot binary. This would concern the following boards:
evb-ast2500_defconfig flea3_defconfig integratorcp_cm1136_defconfig mx31pdk_defconfig mx35pdk_defconfig rpi_0_w_defconfig rpi_defconfig woodburn_defconfig woodburn_sd_defconfig
At least the Raspberry boards should have no problem with UEFI enabled.
Do you see a necessity to use EFI_LOADER=n as default for any of the boards in the list above?
OpenBSD (quite deliberately) doesn't support these, so from our standpoint this would be fine.
participants (6)
-
Fabio Estevam -
Heinrich Schuchardt -
Linus Walleij -
Maksym Sloyko -
Mark Kettenis -
Matthias Brugger