[RaspberryPi 5] Unable to load signed boot.img w/initramfs > 30MB

[SyedFaisalAli]

Describe the bug

This seems similar to #375

The understanding from docs is "The maximum size for a ramdisk file is 96MB", but this appears to be limited to Raspberry Pi4 with observed behavior. On Pi5, a signed boot.img fails to load past 30MB. Below 30MB, the kernel and a small initramfs shell (1.3MB) is successfully loaded from ramdisk.

If the signed boot is disabled but ramdisk is set in config, the boot.img (Tested around 60MB) is able to be read and kernel loads, however, the initramfs fails to load and continues to main root partition. Below 30MB, the kernel and initramfs shell successfully loads.

Some clarifications on the size limits over ramdisk vs signed boot would be helpful. If possible, raising this limit like what was done with 2711 would help allow for bigger initramfs with tools to support LUKS encryption and decryption before main rootfs mounting.

Steps to reproduce the behaviour

Build a signed boot.img greater than 30MB.

Device (s)

Raspberry Pi 5

Bootloader configuration.

[all]
BOOT_UART=1
POWER_OFF_ON_HALT=1

# Boot Order Codes, from https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#BOOT_ORDER
# Try SD first (1), followed by, USB (RP1), NVMe PCIe, then network
BOOT_ORDER=0xf146

# Disable self-update mode - to prevent automatic updates of unsigned bootloader images
ENABLE_SELF_UPDATE=0

# Select signed-boot mode in the EEPROM. This can be used to during development
# to test the signed boot image. Once secure boot is enabled via OTP this setting
# has no effect i.e. it is always 1.
SIGNED_BOOT=1

System

OS/Version: Yocto-based Kirkstone Distribution
Bootloader Version:

2024/06/05 16:41:49
version 6fe0b091c7cb1c5da26b7f41cc24c42840531a83 (release)
timestamp 1717602109
update-time 1729103195
capabilities 0x0000007f

Firmware Version:

2024/06/05 16:41:49 
Copyright (c) 2012 Broadcom
version 6fe0b091 (release) (embedded)

Kernel Version: Linux CAM-2CCF67509B94 6.1.77-v8-16k #1 SMP PREEMPT Thu Feb 8 15:07:10 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux

Bootloader logs

  1.27 RPi: BOOTSYS release VERSION:6fe0b091 DATE: 2024/06/05 TIME: 16:41:49
  1.31 BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1717602109 serial 8f7b63c3 boardrev d041
70 stc 1631177
  1.41 AON_RESET: 00000003 PM_RSTS 00001000
  1.48 RP1_BOOT chip ID: 0x20001927
  1.51 PM_RSTS: 0x00001000
  1.51 part 00000000 reset_info 00000000
  1.55 PMIC reset-event 00000000 rtc 671043a8 alarm 00000000 enabled 0
  1.61 uSD voltage 3.3V
  1.80 Initialising SDRAM 'Micron' 32Gb x2 total-size: 64 Gbit 4267
  1.83 DDR 4267 1 0 64 152
  3.29 OTP boardrev d04170 bootrom a a
  3.30 Customer key hash 0000000000000000000000000000000000000000000000000000000000000000
  3.37 VC-JTAG unlocked
  3.60 RP1_BOOT chip ID: 0x20001927

  4.70 RP1_BOOT chip ID: 0x20001927
  4.71 RP1_BOOT: fw size 25992
  4.26 PCI2 init
  4.26 PCI2 reset
  4.71 PCIe scan 00001de4:00000001
  4.71 RP1_CHIP_INFO 20001927

  4.74 RPi: BOOTLOADER release VERSION:6fe0b091 DATE: 2024/06/05 TIME: 16:41:49
  4.81 BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1717602109 serial 8f7b63c3 boardrev d041
70 stc 4681504
  4.91 AON_RESET: 00000003 PM_RSTS 00001000
  4.95 PCIEx1: PWR 0 DET_WAKE 1
  4.23 usb_pd_init status 3
  4.24 USB_PD CONFIG 0 43
  4.27 Boot mode: NVME (06) order f14
  4.29 PCI1 init
  4.30 PCI1 reset
  4.97 PCIe scan 0000144d:0000a80a
  4.98 PCIe scan 0000144d:0000a80a
  5.10 VID 0x144d MN Samsung SSD 980 PRO 1TB                
  5.13 NVME on 0
  6.92 MBR: 0x00000001,38453281 type: 0xee
  6.93 MBR: 0x00000000,       0 type: 0x00
  6.97 MBR: 0x00000000,       0 type: 0x00
  6.01 MBR: 0x00000000,       0 type: 0x00
  6.05 USB-PD: src-cap PDO object1 0x0a0191f4
  6.09 Current 5000 mA
  6.11 Voltage 5000 mV
  6.13 USB-PD: src-cap PDO object2 0x0002d12c
  6.17 Current 3000 mA
  6.19 Voltage 9000 mV
  6.21 USB-PD: src-cap PDO object3 0x0003c0e1
  6.25 Current 2250 mA
  6.27 Voltage 12000 mV
  6.29 USB-PD: src-cap PDO object4 0x0004b0b4
  6.34 Current 1800 mA
  6.36 Voltage 15000 mV
  6.38 Trying partition: 0
  6.40 GPT c3070f387082874291fc49548cdcce28 000000001 0024ac021 num-partitions 128 entry-size 128
  6.49 GPT partition: 0 ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 000004000..000057331
  6.56 Matched GUID bootable-part-idx 0 want partition 0
  6.61 type: 16 lba: 16384 'mkfs.fat' '  V       ^ ' clusters 42551 (8)
  6.68 rsc 8 fat-sectors 168 root dir cluster 1 sectors 32 entries 512
  6.74 FAT16 clusters 42551
  6.78 [nvme] autoboot.txt not found
  6.80 Select partition rsts 0 C(boot_partition) 0 EEPROM config 0 result 0
  6.86 Trying partition: 0
  6.89 GPT c3070f387082874291fc49548cdcce28 000000001 0024ac021 num-partitions 128 entry-size 128
  6.98 GPT partition: 0 ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 000004000..000057331
  6.05 Matched GUID bootable-part-idx 0 want partition 0
  6.10 type: 16 lba: 16384 'mkfs.fat' '  V       ^ ' clusters 42551 (8)
  6.16 rsc 8 fat-sectors 168 root dir cluster 1 sectors 32 entries 512
  6.23 FAT16 clusters 42551
  6.25 secure-boot
  6.27 Loading boot.img ...
  6.30 boot.sig
  6.31 hash: 966e65f7da967e09c2c8916e93f0c48b1acb24d53e76b642a69779f78272c7ce
  6.38 ts: 1729119077
  6.40 rsa2048: 8ea7f542e67f4fee4ac16a85833ea3f25881b4a3849d4c257f39415900b1654f4ce57a84b6c308c95f9
0243a80c4cd12191978cfe501b335758b1904a1a566ade4e0ea0a1eb7fe691dfbab9a1fa7fcdea2ba58c602ece58cff47de
f82e7caa742d40e7c57fe574e2c9b5367c618721aa7fe3a2b36a9c57df6ff6e6077c160c0ca1d9e25df3bde6bd7396ec6b7
f73d3d808de281f063882754f5e45408a73fa69a003a6c9ae2f6363f68330d7f8135f1689e786ed8879827242eef7ef937e
a3a7189e36ae1c809f5f912e81dffba2e75a395906392358d657b9d1a550a589021e2c3655040168e0ff64ef504ff7afba8
9e1258c793777be6999254a8a4f411288
  7.47 Verifying
 14.00 Bad signature boot.img
 14.54 Error 12 loading boot.img
 14.54 Boot mode: USB-MSD (04) order f1
 14.66 NVME off
 14.71 XHCI-STOP
 14.71 xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d
 14.75 USBSTS 1
 14.78 xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d
 14.83 xHC0 ports 3 slots 64 intrs 4
 14.95 XHCI-STOP
 14.95 xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d
 14.99 USBSTS 1
 14.02 xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d
 14.07 xHC1 ports 3 slots 64 intrs 4

USB boot

No response

NVMe boot

$ sudo nvme list
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev  
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1     S5P2NS0X313793H      Samsung SSD 980 PRO 1TB                  1         187.55  GB /   1.00  TB    512   B +  0 B   5B2QGXA7

$ sudo nvme id-ctrl -H /dev/nvme0
NVME Identify Controller:
vid       : 0x144d
ssvid     : 0x144d
sn        : S5P2NS0X313793H     
mn        : Samsung SSD 980 PRO 1TB                 
fr        : 5B2QGXA7
rab       : 2
ieee      : 002538
cmic      : 0
  [3:3] : 0	ANA not supported
  [2:2] : 0	PCI
  [1:1] : 0	Single Controller
  [0:0] : 0	Single Port

mdts      : 7
cntlid    : 0x6
ver       : 0x10300
rtd3r     : 0x30d40
rtd3e     : 0x989680
oaes      : 0x200
[27:27] : 0	Zone Descriptor Changed Notices Not Supported
[14:14] : 0	Endurance Group Event Aggregate Log Page Change Notice Not Supported
[13:13] : 0	LBA Status Information Notices Not Supported
[12:12] : 0	Predictable Latency Event Aggregate Log Change Notices Not Supported
[11:11] : 0	Asymmetric Namespace Access Change Notices Not Supported
  [9:9] : 0x1	Firmware Activation Notices Supported
  [8:8] : 0	Namespace Attribute Changed Event Not Supported

ctratt    : 0x10
  [9:9] : 0	UUID List Not Supported
  [7:7] : 0	Namespace Granularity Not Supported
  [5:5] : 0	Predictable Latency Mode Not Supported
  [4:4] : 0x1	Endurance Groups Supported
  [3:3] : 0	Read Recovery Levels Not Supported
  [2:2] : 0	NVM Sets Not Supported
  [1:1] : 0	Non-Operational Power State Permissive Not Supported
  [0:0] : 0	128-bit Host Identifier Not Supported

rrls      : 0
cntrltype : 0
  [7:2] : 0	Reserved
  [1:0] : 0	Controller type not reported
fguid     : 
crdt1     : 0
crdt2     : 0
crdt3     : 0
oacs      : 0x17
  [9:9] : 0	Get LBA Status Capability Not Supported
  [8:8] : 0	Doorbell Buffer Config Not Supported
  [7:7] : 0	Virtualization Management Not Supported
  [6:6] : 0	NVMe-MI Send and Receive Not Supported
  [5:5] : 0	Directives Not Supported
  [4:4] : 0x1	Device Self-test Supported
  [3:3] : 0	NS Management and Attachment Not Supported
  [2:2] : 0x1	FW Commit and Download Supported
  [1:1] : 0x1	Format NVM Supported
  [0:0] : 0x1	Security Send and Receive Supported

acl       : 7
aerl      : 3
frmw      : 0x16
  [4:4] : 0x1	Firmware Activate Without Reset Supported
  [3:1] : 0x3	Number of Firmware Slots
  [0:0] : 0	Firmware Slot 1 Read/Write

lpa       : 0xf
  [4:4] : 0	Persistent Event log Not Supported
  [3:3] : 0x1	Telemetry host/controller initiated log page Supported
  [2:2] : 0x1	Extended data for Get Log Page Supported
  [1:1] : 0x1	Command Effects Log Page Supported
  [0:0] : 0x1	SMART/Health Log Page per NS Supported

elpe      : 63
npss      : 4
avscc     : 0x1
  [0:0] : 0x1	Admin Vendor Specific Commands uses NVMe Format

apsta     : 0x1
  [0:0] : 0x1	Autonomous Power State Transitions Supported

wctemp    : 355
cctemp    : 358
mtfa      : 0
hmpre     : 0
hmmin     : 0
tnvmcap   : 1000204886016
unvmcap   : 0
rpmbs     : 0
 [31:24]: 0	Access Size
 [23:16]: 0	Total Size
  [5:3] : 0	Authentication Method
  [2:0] : 0	Number of RPMB Units

edstt     : 35
dsto      : 0
fwug      : 0
kas       : 0
hctma     : 0x1
  [0:0] : 0x1	Host Controlled Thermal Management Supported

mntmt     : 318
mxtmt     : 356
sanicap   : 0x3
  [31:30] : 0	Additional media modification after sanitize operation completes successfully is not defined
  [29:29] : 0	No-Deallocate After Sanitize bit in Sanitize command Supported
    [2:2] : 0	Overwrite Sanitize Operation Not Supported
    [1:1] : 0x1	Block Erase Sanitize Operation Supported
    [0:0] : 0x1	Crypto Erase Sanitize Operation Supported

hmminds   : 0
hmmaxd    : 0
nsetidmax : 0
endgidmax : 1
anatt     : 0
anacap    : 0
  [7:7] : 0	Non-zero group ID Not Supported
  [6:6] : 0	Group ID does not change
  [4:4] : 0	ANA Change state Not Supported
  [3:3] : 0	ANA Persistent Loss state Not Supported
  [2:2] : 0	ANA Inaccessible state Not Supported
  [1:1] : 0	ANA Non-optimized state Not Supported
  [0:0] : 0	ANA Optimized state Not Supported

anagrpmax : 0
nanagrpid : 0
pels      : 0
sqes      : 0x66
  [7:4] : 0x6	Max SQ Entry Size (64)
  [3:0] : 0x6	Min SQ Entry Size (64)

cqes      : 0x44
  [7:4] : 0x4	Max CQ Entry Size (16)
  [3:0] : 0x4	Min CQ Entry Size (16)

maxcmd    : 256
nn        : 1
oncs      : 0x57
  [8:8] : 0	Copy Not Supported
  [7:7] : 0	Verify Not Supported
  [6:6] : 0x1	Timestamp Supported
  [5:5] : 0	Reservations Not Supported
  [4:4] : 0x1	Save and Select Supported
  [3:3] : 0	Write Zeroes Not Supported
  [2:2] : 0x1	Data Set Management Supported
  [1:1] : 0x1	Write Uncorrectable Supported
  [0:0] : 0x1	Compare Supported

fuses     : 0
  [0:0] : 0	Fused Compare and Write Not Supported

fna       : 0x5
  [2:2] : 0x1	Crypto Erase Supported as part of Secure Erase
  [1:1] : 0	Crypto Erase Applies to Single Namespace(s)
  [0:0] : 0x1	Format Applies to All Namespace(s)

vwc       : 0x7
  [2:1] : 0x3	The Flush command supports NSID set to FFFFFFFFh
  [0:0] : 0x1	Volatile Write Cache Present

awun      : 1023
awupf     : 0
icsvscc     : 1
  [0:0] : 0x1	NVM Vendor Specific Commands uses NVMe Format

nwpc      : 0
  [2:2] : 0	Permanent Write Protect Not Supported
  [1:1] : 0	Write Protect Until Power Supply Not Supported
  [0:0] : 0	No Write Protect and Write Protect Namespace Not Supported

acwu      : 0
ocfs      : 0
sgls      : 0
 [1:0]  : 0	Scatter-Gather Lists Not Supported

mnan      : 0
subnqn    : nqn.1994-11.com.samsung:nvme:980PRO:M.2:S5P2NS0X313793H     
ioccsz    : 0
iorcsz    : 0
icdoff    : 0
ctrattr   : 0
  [0:0] : 0	Dynamic Controller Model

msdbd     : 0
ps    0 : mp:8.49W operational enlat:0 exlat:0 rrt:0 rrl:0
          rwt:0 rwl:0 idle_power:- active_power:-
ps    1 : mp:4.48W operational enlat:0 exlat:200 rrt:1 rrl:1
          rwt:1 rwl:1 idle_power:- active_power:-
ps    2 : mp:3.18W operational enlat:0 exlat:1000 rrt:2 rrl:2
          rwt:2 rwl:2 idle_power:- active_power:-
ps    3 : mp:0.0400W non-operational enlat:2000 exlat:1200 rrt:3 rrl:3
          rwt:3 rwl:3 idle_power:- active_power:-
ps    4 : mp:0.0050W non-operational enlat:500 exlat:9500 rrt:4 rrl:4
          rwt:4 rwl:4 idle_power:- active_power:-

$ sudo nvme list-ns /dev/nvme0
[   0]:0x1

$ sudo nvme id-ns -H /dev/nvme0 --namespace-id=1
NVME Identify Namespace 1:
nsze    : 0x74706db0
ncap    : 0x74706db0
nuse    : 0x15d570e0
nsfeat  : 0
  [4:4] : 0	NPWG, NPWA, NPDG, NPDA, and NOWS are Not Supported
  [2:2] : 0	Deallocated or Unwritten Logical Block error Not Supported
  [1:1] : 0	Namespace uses AWUN, AWUPF, and ACWU
  [0:0] : 0	Thin Provisioning Not Supported

nlbaf   : 0
flbas   : 0
  [4:4] : 0	Metadata Transferred in Separate Contiguous Buffer
  [3:0] : 0	Current LBA Format Selected

mc      : 0
  [1:1] : 0	Metadata Pointer Not Supported
  [0:0] : 0	Metadata as Part of Extended Data LBA Not Supported

dpc     : 0
  [4:4] : 0	Protection Information Transferred as Last 8 Bytes of Metadata Not Supported
  [3:3] : 0	Protection Information Transferred as First 8 Bytes of Metadata Not Supported
  [2:2] : 0	Protection Information Type 3 Not Supported
  [1:1] : 0	Protection Information Type 2 Not Supported
  [0:0] : 0	Protection Information Type 1 Not Supported

dps     : 0
  [3:3] : 0	Protection Information is Transferred as Last 8 Bytes of Metadata
  [2:0] : 0	Protection Information Disabled

nmic    : 0
  [0:0] : 0	Namespace Multipath Not Capable

rescap  : 0
  [6:6] : 0	Exclusive Access - All Registrants Not Supported
  [5:5] : 0	Write Exclusive - All Registrants Not Supported
  [4:4] : 0	Exclusive Access - Registrants Only Not Supported
  [3:3] : 0	Write Exclusive - Registrants Only Not Supported
  [2:2] : 0	Exclusive Access Not Supported
  [1:1] : 0	Write Exclusive Not Supported
  [0:0] : 0	Persist Through Power Loss Not Supported

fpi     : 0x80
  [7:7] : 0x1	Format Progress Indicator Supported
  [6:0] : 0	Format Progress Indicator (Remaining 0%)

dlfeat  : 1
  [4:4] : 0	Guard Field of Deallocated Logical Blocks is set to 0xFFFF
  [3:3] : 0	Deallocate Bit in the Write Zeroes Command is Not Supported
  [2:0] : 0x1	Bytes Read From a Deallocated Logical Block and its Metadata are 0x00

nawun   : 0
nawupf  : 0
nacwu   : 0
nabsn   : 0
nabo    : 0
nabspf  : 0
noiob   : 0
nvmcap  : 1000204886016
mssrl   : 0
mcl     : 0
msrc    : 0
nsattr	: 0
nvmsetid: 0
anagrpid: 0
endgid  : 1
nguid   : 00000000000000000000000000000000
eui64   : 002538b34140c14a
LBA Format  0 : Metadata Size: 0   bytes - Data Size: 512 bytes - Relative Performance: 0 Best (in use)

Network (TFTP boot)

No response

[learmj]

ramdisk is set in config, the boot.img (Tested around 60MB) is able to be read and kernel loads, however, the initramfs fails to load and continues to main root partition. Below 30MB, the kernel and initramfs shell successfully loads.

Hi. To avoid any doubt, for both signed and signed boot scenarios, please state if your initramfs archive is embedded into the kernel image (image is a single monolithic blob), or if it's stored as a separate file (kernel and initramfs are separate)?

To verify if authentication is working correctly on a monolithic blob, you could create a file containing random data of a certain size, sign it, then check if the bootloader authenticates it upon load.

[SyedFaisalAli]

Hi!

Hi. To avoid any doubt, for both signed and signed boot scenarios, please state if your initramfs archive is embedded into the kernel image (image is a single monolithic blob), or if it's stored as a separate file (kernel and initramfs are separate)?

The Initramfs archive is stored as a separate file within boot.img. I forgot to show my config.txt in boot.img:

enable_uart=1
uart_2ndstage=1
disable_overscan=1
dtoverlay=dwc2,dr_mode=peripheral,nohdmi
start_file=start4.elf
fixup_file=fixup4.dat
initramfs initramfs.cpio.xz followkernel

Outer config in boot partition:

enable_uart=1
boot_ramdisk=1
uart_2ndstage=1

To verify if authentication is working correctly on a monolithic blob, you could create a file containing random data of a certain size, sign it, then check if the bootloader authenticates it upon load.

So, I created a 30MB file and signed:

dd if=/dev/urandom of=boot.img bs=1024 count=30000
rpi-eeprom-digest -i boot.img -o boot.sig -k private.pem

After copying to the boot partition in our nvme stick, it verifies successfully:

 43.37 secure-boot
 43.39 Loading boot.img ...
 43.42 boot.sig
 43.43 hash: 01d752b596c5c8d277482a4e93b2e77f26cd2e3106363a91e67033e55eeddf9c
 43.50 ts: 1729176130
 43.52 rsa2048: 49adf45767915153ab089e886cd2e9bc4e88f5074f7b333c09b84d17f317fb08968216daee2a0d448b1
dc80ab267cdbddc8eae890724c95257c1d6bbe9aeb38a2a3f65813177f3c06e5e4e5b671b0ab16aa6ce8df895509ee1bffe
144b963093bbbe3c7907168aa6015015d1a7692fff1044edc11775c017d08f3ff3ddf0f8c398a04e30f9705a1570521a28d
17643beec93a13061f2e32b697aa4d3fb7757975d1f8fd006dcb8212034d03956cf9128e571d39335fc90a4e22a2192fcfd
b24c456e8b177f81bb9306a91d7b7d56d81bee712a47abd6516e2c7d700c1dbeff066132f8bfaf944fa0d98896eac4b91c7
05d63818ac1e2c9e07fa4a461b585ea7f
 44.14 Verifying
 47.07 RSA verify
 47.19 rsa-verify pass (0x0)

I then create a 31MB file and sign:

dd if=/dev/urandom of=boot.img bs=1024 count=31000
rpi-eeprom-digest -i boot.img -o boot.sig -k private.pem

Fails to load with bad signature.

134.69 type: 16 lba: 16384 'mkfs.fat' '  V       ^ ' clusters 42551 (8)
134.75 rsc 8 fat-sectors 168 root dir cluster 1 sectors 32 entries 512
134.82 FAT16 clusters 42551
134.84 secure-boot
134.86 Loading boot.img ...
134.89 boot.sig
134.90 Failed to parse signature file
134.93 Bad signature boot.sig
134.96 Error 12 loading boot.img

[learmj]

Your original description seems different to the 31 MB test, though.

  6.27 Loading boot.img ...
  6.30 boot.sig
...
  7.47 Verifying
 14.00 Bad signature boot.img
 14.54 Error 12 loading boot.img

vs

134.86 Loading boot.img ...
134.89 boot.sig
134.90 Failed to parse signature file
134.93 Bad signature boot.sig
134.96 Error 12 loading boot.img

The actual authentication check of the image doesn't look like it actually happened.

[timg236]

I just tried the 31MB image on a 2024/09/23 bootloader using the same command as you and it worked fine on SD, USB, NVMe

dd if=/dev/urandom of=boot.img bs=1024 count=30000
rpi-eeprom-digest -i boot.img -o boot.sig -k private.pem

Possibly a mismatch in the key or an issue with the NVMe.

It might be worth updating the bootloader and replacing the mass-storage-gadget64/boot.img file to see if you can still reproduce the issue.

[SyedFaisalAli]

Hi all, thanks so far!

Yes, it looks like I was mistaken (I might not have synced or copied the signature file correctly the second time). So, at 31M, the boot.img passed.

I'm trying higher sizes now by increasing every 10M. Just on the NVMe, this is the results I'm seeing, but I'll try the SDCard as well to see if there's any issue with the nvme on my end.

dd if=/dev/urandom of=boot.img bs=1024 count=31000 # Passed
dd if=/dev/urandom of=boot.img bs=1024 count=40000 # Passed
dd if=/dev/urandom of=boot.img bs=1024 count=50000 # Failed with Bad signature boot.img

It might be worth updating the bootloader and replacing the mass-storage-gadget64/boot.img file to see if you can still reproduce the issue.

Will update the bootloader as well. Last I tried mass-storage-gadget64/boot.img, it did load. The default image in the repo is about 30MB, but I don't believe I tried replacing it.

[SyedFaisalAli]

It turns out, the boot partition flashed to the nvme from our Yocto WIC image was not set up to format with FAT32, defaulting to FAT16 instead. This was the major difference after comparing with the Raspberry Pi Imager, which flashed its boot partition on the nvme with FAT32, and allowed loading of a larger boot.img without issue.

Oddly, this only mattered for the nvme as we were able to flash our WIC image onto an SDCard with FAT16 formatted boot and load the boot.img. We were also able to load a larger boot.img from USB on our default and the latest eeprom.

In any case, I appreciate the guidance! Feel free to close this ticket if needed.