This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM623:用于 RAW 模式的 boot1备份分区根据 TRM 位于0x400000、该分区似乎位于每个 SDK 的 boot0空间内

Guru**** 2544610 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1336002/am623-the-boot1-backup-partition-for-raw-mode-is-located-at-0x400000-per-trm-this-seems-to-lie-within-boot0-space-per-sdk

器件型号:AM623

SDK 使用块来定义闪存中的位置。

PER : https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM62X/latest/exports/docs/linux/Foundational_Components U-Boot/UG-Memory.html#partition-eMMC-from-u-boot

3.1.4.5. 从 eMMC 引导分区引导 tiboot3.bin、tispl.bin 和 u-boot.img (适用于 K3类 SoC)

Boot0分区(8MB) 用户分区
0x0++------------------------------------------------------- + 0x0+---------------- + 
| tiboot3.bin (1MB) | | |
 0x400++--------------- + | | 
| tispl.bin (2MB) | | |0x1400+--------------- 
+ | rootfs | 
| u-boot.img (4MB) | | |0x3400+------------------ 
+ | | 
| 环境(128KB) | | |
 0x3500++---------------- + | | 
|备份环境(128 KB)| | | 0x3600++--------------- 
+ ---------------- + 

它与 k3_dfu.env 保持一致
dfu_alt_info_eMMC =
rawemmc RAW 0 0x800000 mmcpart 1;
rootfs 部件0 2;
tiboot3.bin.raw raw 0x0 0x400 mmcpart 1;
tispl.bin.raw raw 0x400 0x1000 mmcpart 1;
u-boot.img.RAW 0x1400 0x2000 mmcpart 1;
u-env.raw raw 0x3400 0x100 mmcpart 1;
sysfw.itb.raw 原始0x3600 0x800 mmcpart 1

所有这些数据都以块为单位、因为 uEnv_ethernet_emmc_am62xx-evm.txt 中的 MMC 命令是"以块为中心"的

来自 TRM:
""
ROM 代码将开始从内存引导扇区、文件系统或引导分区中读取、
BOOTMODE 引脚。 文件系统模式仅支持 FAT32和 FAT16格式。 它将继续读取
数据、并将其存储在内部 RAM 中、直到读取完整的映像为止。 仅在 RAW 模式下、
ROM 支持冗余 偏移量0x400000处的图像 如果无法识别初始图像。 在
已读取完整映像并确保其完整性、ROM 代码将分支到定义的地址
在引导标头的 Boot Info 字段中输入。
当 eMMC 引导用作备份引导选项时、仅支持文件系统模式下的用户数据区域(UDA)。
不支持 RAW 模式。 此外、在备份引导期间、仅在1位模式下进行引导。
""

TRM 将0x40 0000作为 BOOT1偏移。
这会将块转换为0x2000块。 它似乎位于 boot0的闪存映射中。

但如果 TRM 以块为单位表示0x400000 (这很奇怪-因为硬件人员为所有寄存器使用4字节对齐的地址)。

那么这是有道理的。 实际上、它是有效的(对其进行了测试)。

因此、如果您将其解释为字节关闭集(默认解释)、则 TRM 出错、或者因为它没有正确指示单位而出错。

测试代码:
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.



  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我在您之前提交的一个相关 e2e 中进行了更新
    e2e.ti.com/.../5089011
    => eMMC 引导分区和 UDA 是不同的硬件分区

    另一方面、eMMC UDA (仅限 RAW)上的 ROM 支持冗余引导(0x0和0x400000)。
    这使得一旦 eMMC UDA 用于 Linux/RootFS (通过 GPT 格式化的 FS)、就限制在 UDA (仅限原始)上使用 ROM 冗余引导。

    此致!
    -洪