rpi: image generation

I have local changes for the Raspberry Pi that can automatically generate an image to be flashed on the SD card (e.g. with dd).

This mechanism uses genimage, so no sudo is needed. It generates a FAT32 partition of 64 MiB and an ext4 partition that just fits its contents with a small free space. I also have scripts to auto-expand the ext4 partition and FS to fill the SD card.

Are you interested in any of this, or do you prefer to keep the current manual approach that makes it possible to do just anything custom?

Dear Beno?t Th?baudeau,

Quoted 8 lines · Beno?t Th?baudeau

I have local changes for the Raspberry Pi that can automatically generate an image to be flashed on the SD card (e.g. with dd).

This mechanism uses genimage, so no sudo is needed. It generates a FAT32 partition of 64 MiB and an ext4 partition that just fits its contents with a small free space. I also have scripts to auto-expand the ext4 partition and FS to fill the SD card.

Quoted 3 lines

Are you interested in any of this, or do you prefer to keep the current manual approach that makes it possible to do just anything custom?

I am interested in seeing more examples of genimage usage. I believe Vivien Didelot, who submitted the patch to use genimage for the Wandboard configuration, was also planning on submitting more genimage related patches.

Automate the preparation of the generated image files for the Raspberry Pi firmware:
- mark the kernel image as supporting Device Tree,
- place the marked kernel image and the DTBs into the rpi-firmware folder.

The instructions in readme.txt are updated accordingly.

Signed-off-by Beno?t Th?baudeau <[email protected]>

---
 board/raspberrypi/post-image.sh | 17 ++++++++
 board/raspberrypi/readme.txt    | 90 ++++++++++++++++++-----------------------
 configs/raspberrypi2_defconfig  |  2 +
 configs/raspberrypi_defconfig   |  2 +
 4 files changed, 60 insertions(+), 51 deletions(-)
 create mode 100755 board/raspberrypi/post-image.sh

board/raspberrypi/post-image.sh new file +7 -0

new file mode 100755
index 0000000..db9c53c
@@ -0,0 +1,17 @@
+#!/bin/bash -e
+
+RPI_FW_BIN_DIR="${BINARIES_DIR}/rpi-firmware"
+KERNEL_IMG="${BINARIES_DIR}/zImage"
+KERNEL_RPI_FW_IMG="${RPI_FW_BIN_DIR}/zImage"
+
+# A special marker must be appended to the kernel image so that the firmware of

board/raspberrypi/readme.txt +3 -1

@@ -61,77 +61,65 @@ Result of the build
 After building, you should obtain this tree:
 
     output/images/
-    +-- rootfs.tar                  [0]
+    +-- rootfs.cpio                 [0]
+    +-- rootfs.tar                  [1]
     +-- rpi-firmware/
+    |   +-- bcm2708-rpi-b.dtb       [2]

Why not simply:

    cp -l "${BINARIES_DIR}/"*.dtb "${RPI_FW_BIN_DIR}"

I'd prefer we keep the DTB files where they were installed, so the user does not get confused.

As I said above, I'd prefer the DTB files be left in their original location, with the ones in rpi-firmware/ being only copies of, or hard-links to, the originals.

Add init scripts to auto-expand the persistent rootfs on the first boot to fill the medium.

These scripts follow the same procedure as raspi-config. The root partition is first expanded, then a reboot is required, then the rootfs is expanded. Each script removes itself once run.

The volatile (initramfs) rootfs is not affected by this change.

The instructions in readme.txt are updated accordingly.

Signed-off-by Beno?t Th?baudeau <[email protected]>

Hi Vivien, Yann, all,

On 22/08/2015 22:01, Beno?t Th?baudeau wrote:

So the initial contents of the unused space on the SD card seem to have an influence, and there seems to be a bug somewhere (Linux, resize2fs, genext2fs, tune2fs, or lack of call to e2fsck before calling resize2fs but this would not be reliable with an online partition).

Then I retried with a 16-GiB SD card on a Raspberry Pi B, and it was very slow too. Same if the resize is performed on a PC. However, it's very quick with raspi-config and the latest Raspbian image. The main difference seemed to be the block size (4 KiB on Raspbian vs. 1 KiB with mke2img), so I hacked mke2img to test with genext2fs -B 4096 and tune2fs -J size=4, but it did not make things faster, only the image bigger (about 512 MiB, probably the minimal size for 4-KiB blocks). So I don't know which ones, but it's probably some ext4 parameters that are having an influence on the resize2fs speed here. Any idea?

Quoted 3 lines · On Thursday 27 August 2015 11:02:02 Beno?t Th?baudeau wrote:

Hi Vivien, Yann, all,

On 22/08/2015 22:01, Beno?t Th?baudeau wrote:

[...]

Quoted 5 lines

So the initial contents of the unused space on the SD card seem to have an influence, and there seems to be a bug somewhere (Linux, resize2fs, genext2fs, tune2fs, or lack of call to e2fsck before calling resize2fs but this would not be reliable with an online partition).

Quoted 9 lines

Then I retried with a 16-GiB SD card on a Raspberry Pi B, and it was very slow too. Same if the resize is performed on a PC. However, it's very quick with raspi-config and the latest Raspbian image. The main difference seemed to be the block size (4 KiB on Raspbian vs. 1 KiB with mke2img), so I hacked mke2img to test with genext2fs -B 4096 and tune2fs -J size=4, but it did not make things faster, only the image bigger (about 512 MiB, probably the minimal size for 4-KiB blocks). So I don't know which ones, but it's probably some ext4 parameters that are having an influence on the resize2fs speed here. Any idea?

Yes, I have an idea :-) Did you try sparse_super?

Quoted 19 lines · J?r?me Pouiller

Quoted 3 lines · On Thursday 27 August 2015 11:02:02 Beno?t Th?baudeau wrote:

Hi Vivien, Yann, all,

On 22/08/2015 22:01, Beno?t Th?baudeau wrote:

[...]

Quoted 14 lines

So the initial contents of the unused space on the SD card seem to have an influence, and there seems to be a bug somewhere (Linux, resize2fs, genext2fs, tune2fs, or lack of call to e2fsck before calling resize2fs but this would not be reliable with an online partition).

Then I retried with a 16-GiB SD card on a Raspberry Pi B, and it was very slow too. Same if the resize is performed on a PC. However, it's very quick with raspi-config and the latest Raspbian image. The main difference seemed to be the block size (4 KiB on Raspbian vs. 1 KiB with mke2img), so I hacked mke2img to test with genext2fs -B 4096 and tune2fs -J size=4, but it did not make things faster, only the image bigger (about 512 MiB, probably the minimal size for 4-KiB blocks). So I don't know which ones, but it's probably some ext4 parameters that are having an influence on the resize2fs speed here. Any idea?

Quoted 1 line

Yes, I have an idea :-) Did you try sparse_super?

[...]

Awesome, it works, even if resizing the partition online. Thanks for the tip!

I'll send a patch changing mke2img to allow the use of this option.

Quoted 6 lines · On Saturday 22 August 2015 22:01:28 Beno?t Th?baudeau wrote:

Add init scripts to auto-expand the persistent rootfs on the first boot to fill the medium.

These scripts follow the same procedure as raspi-config. The root partition is first expanded, then a reboot is required, then the rootfs is expanded. Each script removes itself once run.

[..]

Quoted 16 lines

board/raspberrypi/readme.txt +0 -0

index d63e71e..7ee783b 100644
@@ -34,10 +34,13 @@ And for model 2 B:
   $ make raspberrypi2_defconfig
 
 If you want to use a persistent rootfs, the generated ext4 rootfs image

fits its -contents with only a small (but sensible) margin of free space by default, so -you might want to adjust "Filesystem images"/"ext2/3/4 root filesystem"/ -"size in blocks (leave at 0 for auto calculation)" depending on your needs, then -skip to "Build the rootfs", below. +contents with only a small (but sensible) margin of free space by default, but +it is auto-expanded on the first boot to fill the medium. You can however adjust +"Filesystem images"/"ext2/3/4 root filesystem"/ +"size in blocks (leave at 0 for auto calculation)" to fit your needs. The

board/raspberrypi/readme.txt And for model 2 B: · line 43

Quoted 3 lines

board/raspberrypi/readme.txt +3 -0

+auto-expansion is controlled by
+board/raspberrypi/rootfs-overlay/etc/init.d/S*expand-root*. Skip to
+"Build the rootfs", below.

Isn't safer to auto-expand partition while flashing SD Card instead of doing it online?

Maybe you can explain how to resize partition in README or provide a script like the one I sent you a few days ago (named sdflash.sh), no?

Add init scripts to auto-expand the persistent rootfs on the first boot to fill the medium.

Quoted 2 lines · Beno?t Th?baudeau

Add init scripts to auto-expand the persistent rootfs on the first boot to fill the medium.

Wonder if it wouldn't be better to have a package section in buildroot for commonly used init scripts like this?

I don't think resizing the rootfs is specific to only this board. And by making it a package you could do "depends on !BR2_TARGET_ROOTFS_INITRAMFS" instead of grep magic in the post build script.

Add init scripts to auto-expand the persistent rootfs on the first boot to fill the medium.

board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart new file +1 -0

new file mode 100755
index 0000000..7f19e7a
@@ -0,0 +1,36 @@
+#!/bin/sh

board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart new file +25 -0

+		else
+			fdisk "${BLOCK_DEV}" <<-EOF &>/dev/null
+				d
+				$PART_NUM
+				n
+				p
+				$PART_NUM
+				$PART_START
+
+				w
+			EOF
+			echo "done"
+		fi
+		rm -f /etc/init.d/S22expand-rootpart
+		if [ "${PART_START}" ]; then
+			reboot -f
+			while true; do :; done
+		fi
+		exit 2
+		;;
+	*)
+		echo "Usage: $0 start" >&2
+		exit 1
+		;;
+esac

board/raspberrypi/rootfs-overlay/etc/init.d/S23expand-rootfs new file +16 -0

new file mode 100755
index 0000000..7b3f286
@@ -0,0 +1,16 @@
+#!/bin/sh
+
+case "$1" in
+	start)
+		echo -n "Expanding the root FS: "
+		resize2fs /dev/mmcblk0p2 &>/dev/null
+		ret=$?
+		[ ${ret} -eq 0 ] && echo "done" || echo "failed"
+		rm -f /etc/init.d/S23expand-rootfs
+		exit ${ret}
+		;;
+	*)
+		echo "Usage: $0 start" >&2
+		exit 1
+		;;
+esac

configs/raspberrypi2_defconfig +0 -0

index 73dc290..2e064e0 100644

configs/raspberrypi2_defconfig +0 -0

  BR2_TOOLCHAIN_BUILDROOT_CXX=y
 
  BR2_TARGET_GENERIC_GETTY_PORT="tty1"

Quoted 2 lines · Beno?t Th?baudeau

Add init scripts to auto-expand the persistent rootfs on the first boot to fill the medium.

Had a look at your script, but think it has more dependencies than strictly necessary.

Quoted 18 lines

diff --git
a/board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart b/board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart new file mode 100755
index 0000000..7f19e7a

board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart new file +8 -0

@@ -0,0 +1,36 @@
+#!/bin/sh
+
+case "$1" in
+       start)
+               echo -n "Expanding the root partition: "
+               BLOCK_DEV="/dev/mmcblk0"
+               PART_NUM="2"
+               PART_START="$(parted -ms "${BLOCK_DEV}" unit s p

2>/dev/null | \
+ grep "^${PART_NUM}:" | cut -d : -f 2 | sed

board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart line 11

Quoted 3 lines

's/s$//')"

board/raspberrypi/rootfs-overlay/etc/init.d/S22expand-rootpart new file +2 -0

+               if [ -z "${PART_START}" ]; then
+                       echo "failed"

Note that the existing start sector can also be found in /sys/class/block/mmcblk0p2/start
So can remove the parted dependency.

Quoted 6 lines

configs/raspberrypi2_defconfig +0 -0

index 73dc290..2e064e0 100644
@@ -3,6 +3,7 @@ BR2_cortex_a7=y

configs/raspberrypi2_defconfig BR2_cortex_a7=y

Quoted 3 lines

configs/raspberrypi2_defconfig +0 -0

  BR2_ARM_EABIHF=y
  BR2_ARM_FPU_NEON_VFPV4=y
  +BR2_TOOLCHAIN_BUILDROOT_GLIBC=y

Why is glibc required?
Isn't it possible to just set the right options (like wchar, largefile) for uclibc?

Quoted 8 lines

configs/raspberrypi2_defconfig +2 -0

  BR2_TOOLCHAIN_BUILDROOT_CXX=y
    BR2_TARGET_GENERIC_GETTY_PORT="tty1"

@@ -27,6 +28,13 @@ BR2_LINUX_KERNEL_INTREE_DTS_NAME="bcm2709-rpi-2-b"
  BR2_PACKAGE_RPI_FIRMWARE=y
  # BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTB_OVERLAYS is not set
  +BR2_PACKAGE_E2FSPROGS=y
+BR2_PACKAGE_E2FSPROGS_RESIZE2FS=y
+BR2_PACKAGE_PARTED=y

configs/raspberrypi2_defconfig BR2_LINUX_KERNEL_INTREE_DTS_NAME="bcm2709-rpi-2-b" · line 37

Quoted 4 lines

configs/raspberrypi2_defconfig +4 -0

+BR2_PACKAGE_UTIL_LINUX_BINARIES=y
+
+BR2_ROOTFS_OVERLAY="board/raspberrypi2/rootfs-overlay"
+BR2_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypi2/post-build.sh"

Why is UTIL_LINUX_BINARIES necessary?
If for fdisk,

doesn't busybox provides this as well?

The SoC of the Raspberry Pi 1 is an ARM1176JZF-S, which features a VFPv2 FPU, so use the EABIhf target ABI, which is more efficient than EABI. This is also the default on Raspbian.

Signed-off-by Beno?t Th?baudeau <[email protected]>

---
 configs/raspberrypi_defconfig | 1 +
 1 file changed, 1 insertion(+)

Applied, thanks. I actually believe we should be doing the same for all ARMv6/ARMv7 platforms, except if there is a specific issue with using EABIhf (such as existing pre-built binaries that are EABI only).

Maybe we should even use EABIhf by default on ARMv6+.

Dear Thomas Petazzoni,

Quoted 3 lines · Thomas Petazzoni

Applied, thanks. I actually believe we should be doing the same for all ARMv6/ARMv7 platforms, except if there is a specific issue with using EABIhf (such as existing pre-built binaries that are EABI only).

Yes, there is such an issue because some hardware vendors provide closed libraries that use soft-FP. It was the case e.g. for i.MX6 (audio/video CODEC and GPU libraries), but they now provide hard-float binaries IIRC. So such a change should be checked on a per-platform basis.

Quoted 2 lines

Maybe we should even use EABIhf by default on ARMv6+.

Yes, I think that it would be a sane default, and it would still be possible to set EABI for a specific platform for which EABIhf would not apply.

Best regards,
Beno?t
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Applied, thanks. I actually believe we should be doing the same for all ARMv6/ARMv7 platforms, except if there is a specific issue with using EABIhf (such as existing pre-built binaries that are EABI only).

Maybe we should even use EABIhf by default on ARMv6+.

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

"Peter" == Peter Korsgaard <[email protected]> writes:

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hi,

Quoted 5 lines

Applied, thanks. I actually believe we should be doing the same for all ARMv6/ARMv7 platforms, except if there is a specific issue with using EABIhf (such as existing pre-built binaries that are EABI only).

Maybe we should even use EABIhf by default on ARMv6+.

Agreed!

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Beno?t" == Beno?t Th?baudeau <[email protected]> writes:

Set EABIhf as the default target ABI for the ARM processors that have or may have a VFP unit, since this ABI is the most efficient in that case. Of course, EABI can still be selected manually if needed.

Signed-off-by Beno?t Th?baudeau <[email protected]>

---
 arch/Config.in.arm | 1 +
 1 file changed, 1 insertion(+)

arch/Config.in.arm +0 -0

index 4d10f4c..f0110b1 100644

arch/Config.in.arm endchoice · line 191

Quoted 9 lines

arch/Config.in.arm +1 -0

index 4d10f4c..f0110b1 100644
@@ -188,6 +188,7 @@ endchoice
 choice
 	prompt "Target ABI"
 	depends on BR2_arm || BR2_armeb
+	default BR2_ARM_EABIHF if BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2

I think we should only do it when we are certain it will run, E.G. arm926 (our default variant) selects MAYBE_HAS_VFPV2, but it is afaik quite rare to see arm9s with a vfp.

Committed with that changed, thanks.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Dear Peter Korsgaard,

Quoted 14 lines · Peter Korsgaard

arch/Config.in.arm endchoice · line 191

Quoted 9 lines

arch/Config.in.arm +1 -0

index 4d10f4c..f0110b1 100644
@@ -188,6 +188,7 @@ endchoice
 choice
 	prompt "Target ABI"
 	depends on BR2_arm || BR2_armeb
+	default BR2_ARM_EABIHF if BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2

I think we should only do it when we are certain it will run, E.G. arm926 (our default variant) selects MAYBE_HAS_VFPV2, but it is afaik quite rare to see arm9s with a vfp.

Quoted 1 line

Committed with that changed, thanks.

default BR2_ARM_EABIHF if BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2

was indeed wrong, since having BR2_ARM_CPU_MAYBE_HAS_VFPV2 does not indicate that the SoC has VFP.

However, unlike BR2_ARM_CPU_HAS_NEON which gets selected even on ARM cores for which NEON is optional, but for which the user has explicitly requested NEON support to be enabled (through BR2_ARM_ENABLE_NEON), it is not the case for the VFP option. I think we should do that. Otherwise, BR2_ARM_CPU_HAS_VFPV2 will not be true, even if the VFPv2 unit is actually available and used.

Quoted 6 lines

However, unlike BR2_ARM_CPU_HAS_NEON which gets selected even on ARM cores for which NEON is optional, but for which the user has explicitly requested NEON support to be enabled (through BR2_ARM_ENABLE_NEON), it is not the case for the VFP option. I think we should do that. Otherwise, BR2_ARM_CPU_HAS_VFPV2 will not be true, even if the VFPv2 unit is actually available and used.

But packages should use the BR2_ARM_FPU_VFPV2 (and 3/4) symbols to check if they should use the VFP, and not BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2

I don't think kconfig will let us both have these options depend on BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2 and select BR2_ARM_CPU_HAS_VFPV2.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Peter,

Quoted 7 lines · Peter Korsgaard

Quoted 6 lines

However, unlike BR2_ARM_CPU_HAS_NEON which gets selected even on ARM cores for which NEON is optional, but for which the user has explicitly requested NEON support to be enabled (through BR2_ARM_ENABLE_NEON), it is not the case for the VFP option. I think we should do that. Otherwise, BR2_ARM_CPU_HAS_VFPV2 will not be true, even if the VFPv2 unit is actually available and used.

Quoted 2 lines

But packages should use the BR2_ARM_FPU_VFPV2 (and 3/4) symbols to check if they should use the VFP, and not BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2

But then they have to test BR2_ARM_FPU_VFPV2 || BR2_ARM_FPU_VFPV3 || BR2_ARM_FPU_VFPV3D16 || ...

If they just want to know if a VFP is available.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Beno?t" == Beno?t Th?baudeau <[email protected]> writes:

Set EABIhf as the default target ABI for the ARM processors that have or may have a VFP unit, since this ABI is the most efficient in that case. Of course, EABI can still be selected manually if needed.

Quoted 5 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Beno?t" == Beno?t Th?baudeau <[email protected]> writes:

Set EABIhf as the default target ABI for the ARM processors that have or may have a VFP unit, since this ABI is the most efficient in that case. Of course, EABI can still be selected manually if needed.

On a related note, should we default to thumb2 if the CPU supports it?

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Beno?t" == Beno?t Th?baudeau <[email protected]> writes:

Quoted 7 lines · Peter Korsgaard

Quoted 5 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Beno?t" == Beno?t Th?baudeau <[email protected]> writes:

Set EABIhf as the default target ABI for the ARM processors that have or may have a VFP unit, since this ABI is the most efficient in that case. Of course, EABI can still be selected manually if needed.

On a related note, should we default to thumb2 if the CPU supports it?

I would say:

choice
prompt "ARM instruction set"
default BR2_ARM_INSTRUCTIONS_ARM if BR2_ARM_CPU_HAS_ARM default BR2_ARM_INSTRUCTIONS_THUMBS2 if BR2_ARM_CPU_HAS_THUMBS2 default BR2_ARM_INSTRUCTIONS_THUMBS if BR2_ARM_CPU_HAS_THUMBS

Quoted 12 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Beno?t" == Beno?t Th?baudeau <[email protected]> writes:

Quoted 7 lines · Peter Korsgaard

Quoted 5 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Beno?t" == Beno?t Th?baudeau <[email protected]> writes:

Set EABIhf as the default target ABI for the ARM processors that have or may have a VFP unit, since this ABI is the most efficient in that case. Of course, EABI can still be selected manually if needed.

On a related note, should we default to thumb2 if the CPU supports it?

I would say:

Quoted 5 lines

choice
prompt "ARM instruction set"
default BR2_ARM_INSTRUCTIONS_ARM if BR2_ARM_CPU_HAS_ARM default BR2_ARM_INSTRUCTIONS_THUMBS2 if BR2_ARM_CPU_HAS_THUMBS2 default BR2_ARM_INSTRUCTIONS_THUMBS if BR2_ARM_CPU_HAS_THUMBS

I'm not sure it makes sense to default to thumb1 even if the CPU supports it because of various compatibility issues

- So simply:

default BR2_ARM_INSTRUCTIONS_THUMBS2 if BR2_ARM_CPU_HAS_THUMBS2

(if no thumb2 is available, the first available option (ARM) is used).

Quoted 19 lines

Quoted 18 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Beno?t" == Beno?t Th?baudeau <[email protected]> writes:

Quoted 7 lines · Peter Korsgaard

Quoted 5 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Beno?t" == Beno?t Th?baudeau <[email protected]> writes:

Set EABIhf as the default target ABI for the ARM processors that have or may have a VFP unit, since this ABI is the most efficient in that case. Of course, EABI can still be selected manually if needed.

On a related note, should we default to thumb2 if the CPU supports it?

I would say:

choice
prompt "ARM instruction set"
default BR2_ARM_INSTRUCTIONS_ARM if BR2_ARM_CPU_HAS_ARM default BR2_ARM_INSTRUCTIONS_THUMBS2 if BR2_ARM_CPU_HAS_THUMBS2 default BR2_ARM_INSTRUCTIONS_THUMBS if BR2_ARM_CPU_HAS_THUMBS

Quoted 2 lines

I'm not sure it makes sense to default to thumb1 even if the CPU supports it because of various compatibility issues

It's the first default that wins, not the last one,

so above it's ARM over Thumb1.

Quoted 2 lines

- So simply:

Quoted 3 lines

default BR2_ARM_INSTRUCTIONS_THUMBS2 if BR2_ARM_CPU_HAS_THUMBS2

(if no thumb2 is available, the first available option (ARM) is used).

With ARM + Thumb2, I would rather use ARM to avoid compatibility issues, except on platforms very constrained on memory. On Cortex-M3, there's not even ARM. Or is it common to use Thumb2 on bigger platforms like Cortex-A*?