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

[Pali Rohár]

On Sunday 19 March 2023 02:30:07 Martin Rowe wrote:
> On Mon, 6 Mar 2023 at 18:40, Pali Rohár <pali at kernel.org> wrote:
> 
> > 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 can only set 0, 1, 2, and 7; the others result in `exit not allowed from
> main input shell.`

Bingo, you found a new bug in u-boot mmc code. I hope that this patch fixes it:
https://patchwork.ozlabs.org/project/uboot/patch/20230319163342.15385-1-pali@kernel.org/

> > 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.
> >
> 
> The only part that seems to be preserved is the partition_enable; ack and
> access both reset to 0.

Ok, it is possible that U-Boot itself overwrite access bits and hence
via "mmc partconf" command it is not possible to "print it".

Could you try to check current settings in SPL via mmc.c hook which I
described in previous email?

> > 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.
> >
> 
> 7 invalid attempts before it finds u-boot in the userdata partition:
> 
> <user output>
> 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.
> 
> U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> +1000)
> </user output>

Ok, so this test fully confirms my theory about what "Switching
BootPartitions" means.

> 
> > 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.
> >
> 
> Changing just the checksum at 0x1F results in BootROM producing no output
> and just hanging. I've tried on each boot partition (with the others
> zeroed) and can't get any results at all. I also tried a valid header and
> zeroes for the rest of the image; same result.

Ok, probably this is another hit of debug log BootROM bug (as I
documented it in kwboot.1 manpage). In this case we are not able to get
BootROM output over UART.