[jameshilliard]

Compare BCM2712's effective RAM capacity with the factory capacity from device tree or OTP before staging or flashing an update.

For mismatched boards, permit builds before 2024-09-23 or matching the running build. Check every bootable partition using rpi-bootloader-version because compatibility does not follow firmware date order. Keep normal latest-image selection and require a compatible image to be selected manually when an update is rejected.

Warn about possible RAM replacement and advise contacting the seller for undisclosed modifications. Document the policy and add isolated updater tests to CI.

Refs: #797

Without a RAM mismatch guard users risk bricking their devices, this creates a number of potentially undesirable situations:

• Users may avoid eeprom updates entirely because they don't want to risk bricking a device due to not knowing if their board has legit RAM or not. If updating risks bricking devices users will avoid updating, especially for cases where the hardware is difficult to replace if it were to fail.
• Users may not know that their hardware had unauthorized modifications and will blame raspberry pi rather than the seller for the hardware failure after updating eeprom.
• Users may not know their supply chain is contaminated with tampered hardware.
• Users may think raspberry pi is maliciously bricking working hardware.(i.e. like what happened with FTDIgate)

[timg236]

We aren’t going to carry patches for this.

[jameshilliard]

We aren’t going to carry patches for this.

How do you recommend distro's ensure that eeprom updates don't brick end user devices?

[timg236]

We aren't going to put time or effort into devices which have been miss-sold.