[PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Pali Rohár]

On Monday 06 March 2023 11:15:35 Martin Rowe wrote:
> On Sun, 5 Mar 2023 at 16:04, Pali Rohár <pali at kernel.org> wrote:
> > Could you try another test by completely erasing BOOT0, BOOT1 and USER
> > > data? And see what BootROM prints.
> >
> 
> =====================================
> BootROM - 1.73
> 
> Booting from MMC
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad h
> Trying Uart
> =====================================

Originally I though that I did not understand disassembled bootrom code
correctly but this logs proves that I did it correctly. Log is very
strange.

There is a loop which tries partition numbers 0x1, 0x2, ... 0x9, 0xa.

And if I'm looking at the bootrom code correctly it does bit-AND
operation on partition number with constant 0x7 and result is set into
mmc register 179 (partition_config).

So if I understand it correctly it means that bootrom automatically
clears boot_ack and boot_partition. And into partition_access it sets
the partition number. Hence numbers 0x9 and 0xa are trimmed and
aliased to 0x1 and 0x2; and number 0x8 overflows to 0x0.

Completely strange behavior and probably against how HW mmc boot
partitions should be used.

eMMC spec defines:
partition_access (low 3 bits of mmc 179/partition_config register):
0x0 : No access to boot partition (default)
0x1 : R/W boot partition 1
0x2 : R/W boot partition 2
0x3 : R/W Replay Protected Memory Block (RPMB)
0x4 : Access to General Purpose partition 1
0x5 : Access to General Purpose partition 2
0x6 : Access to General Purpose partition 3
0x7 : Access to General Purpose partition 4

I guess that you do not have general purpose partitions layout on emmc
and RPMB is not used too. So technically only 0x0, 0x1, and 0x2 are
available.

To confirm my theory, could you try to do following tests?

1. Check u-boot's "mmc partconf" settings are not preserved across
reboots.

2. Put valid image into userdata partition; erase boot 0 and boot 1; and
post bootrom output. There should be 7 invalid attempts with Switching
BootPartitions message.

3. Take valid image, invalidate kwb header checksum and put it on boot0;
plus erase boot1 and user. Bootrom should print "Invalid header
checksum" message and it should be two times. Once for 0x1 and second
time for overflowed 0x9.