SDK uses BLOCKS to define locations in the FLASH.
3.1.1.4.5. Booting tiboot3.bin, tispl.bin and u-boot.img from eMMC boot partition (For K3 class of SoCs)
<for boot0 location>
boot0 partition (8 MB) user partition 0x0+----------------------------------+ 0x0+-------------------------+ | tiboot3.bin (1 MB) | | | 0x400+----------------------------------+ | | | tispl.bin (2 MB) | | | 0x1400+----------------------------------+ | rootfs | | u-boot.img (4 MB) | | | 0x3400+----------------------------------+ | | | environment (128 KB) | | | 0x3500+----------------------------------+ | | | backup environment (128 KB) | | | 0x3600+----------------------------------+ +-------------------------+
Which aligns with k3_dfu.env
dfu_alt_info_emmc=
rawemmc raw 0 0x800000 mmcpart 1;
rootfs part 0 2;
tiboot3.bin.raw raw 0x0 0x400 mmcpart 1;
tispl.bin.raw raw 0x400 0x1000 mmcpart 1;
u-boot.img.raw raw 0x1400 0x2000 mmcpart 1;
u-env.raw raw 0x3400 0x100 mmcpart 1;
sysfw.itb.raw raw 0x3600 0x800 mmcpart 1
ALL THIS DATA IS in BLOCKS as the mmc commands in uEnv_ethernet_emmc_am62xx-evm.txt are 'block centric'
From the TRM:
"""
The ROM Code will start reading from the memory boot sector, filesystem, or boot partition as specified by the
BOOTMODE pins. Only FAT32 and FAT16 formats are supported in filesystem mode. It will continue reading
data from the memory and storing it in internal RAM until a complete image has been read. In RAW mode only,
the ROM supports a redundant image at offset 0x400000 in case the initial image fails to be recognized. When
the complete image has been read and found in good integrity, the ROM Code will branch to the address defined
in the Boot Info field of the boot header.
When eMMC boot is used as a backup boot option, only User Data Area (UDA) in filesystem mode is supported.
Raw mode is not supported. Additionally, boot will only occur in 1-bit mode during backup booting.
"""
THE TRM has 0x40 0000 as the boot1 offset.
This converts to blocks as 0x2000 blocks. Which appears to lie within the flash memory map of boot0.
If however the TRM MEANT 0x400000 in blocks (which is just weird - given HW folks use 4byte aligned addresses for all registers).
Then this makes sense. and indeed it works (tested it).
Thus the TRM is either in error if you interpret this as bytes off set (default interpretation) or it is in error because it does not indicate the units correctly.
TEST CODE:Steps: Set Bootmode[15:0] = 00010000 11001011 Ether backup, eMMC primary Boot to eMMC using tiboot3.bin/tispl.bin/u-boot.image starting at offset 0x0 Interrupt u-Boot boot. Erase and program boot images: mmc erase 0x400000 0x400000 dhcp tiboot3.bin.emmc mmc write ${loadaddr} 0x400000 0x400 dhcp tispl.bin.emmc mmc write ${loadaddr} 0x400400 0x1000 dhcp u-boot.img.emmc mmc write ${loadaddr} 0x401400 0x2000 Corrupt the boot 1 flash space mmc erase 0x000000 0x100 Confirm board boots to u-boot Board should boot to u-boot and try to find RFS. If it fails it will attempt BACKUP modes.
