On Mon, 30 Sept 2024 at 21:05, Jan Lübbe <j...@pengutronix.de> wrote: > > On Mon, 2024-09-30 at 15:18 +0100, Peter Maydell wrote: > > On Fri, 6 Sept 2024 at 17:51, Jan Luebbe <j...@pengutronix.de> wrote: > > > > > > The enable bits in the EXT_CSD_PART_CONFIG ext_csd register do *not* > > > specify whether the boot partitions exist, but whether they are enabled > > > for booting. Existence of the boot partitions is specified by a > > > EXT_CSD_BOOT_MULT != 0. > > > > > > Currently, in the case of boot-partition-size=1M and boot-config=0, > > > Linux detects boot partitions of 1M. But as sd_bootpart_offset always > > > returns 0, all reads/writes are mapped to the same offset in the backing > > > file. > > > > > > Fix this bug by calculating the offset independent of which partition is > > > enabled for booting. > > > > Looking at the spec this change seems correct to me. > > > > Can you elaborate on when users might run into this bug? > > As far as I can see only aspeed.c sets boot-partition-size, > > and when it does so it also sets boot-config to 8. Or are > > we fixing this for the benefit of future board types? > > I stumbled across this when trying to use the eMMC emulation for the RAUC test > suite (with some unrelated local hacks, which I still need to clean up for > submission) [1]. Future boards would be affected as well. > > One other possible issue would be disabling the boot partition by using 'mmc > bootpart enable 0 0 /dev/mmcblk0' (or similar) from Linux. The layout of the > backing file shouldn't change in that case.
Thanks for the clarification. I've applied this patch to target-arm.next with the following paragraph added to the commit message: This bug is unlikely to affect many users with QEMU's current set of boards, because only aspeed sets boot-partition-size, and it also sets boot-config to 8. So to run into this a user would have to manually mark the boot partition non-booting from within the guest. and I cc'd it to stable. -- PMM
