工具/软件:Linux
大家好、我知道我最近做了几篇这类文章、但我不断发现、随着我花更多的时间来解决问题、他们会被推至堆的底部、尤其是因为我已经多次回答了一条建议、没有听到任何回复。 我很抱歉。 但是、我想将我的所有问题整理到这个帖子中。
上一帖子: 
编辑:添加了我一直关注的 Wiki 调试步骤的链接,并修复了不存在的“从上面的链接”:) 
我的方法:
- 在存储器中没有 SD 卡/映像的情况下为板加电、请按照上述链接中的 JTAG 配置进行操作
- 通过工具加载 u-boot-spl.bin ->在 CCS7中加载存储器。 具体加载到0x40300000。
- 加载 u-boot-spl ELF 符号
- 将 PC 更改为0x40300000并运行 u-boot-spl
- 获取此消息

- 暂停调试器,通过 run->load 程序加载 u-boot
- 在这里、我不能单步执行、每次我尝试 PC 直接转到0x0000000C。 如果很重要、这就是 CCS 提供的错误以及内核寄存器

- 在 am57xx-evm.h 中启用调试宏不会显示任何调试信息
- printf 不打印任何内容
- 使用具有 PSDK 4纯副本的 AM572x EVM 执行上述操作会导致相同的行为、这可能会排除我先前的假设、即我们定制板的 EMIF/Lisa 配置不正确。
当我将 u-boot.img 和 MLO 放置在 SD 卡上的引导分区中、但在 rootfs 分区中没有任何内容时、EVM 将到达 U-Boot 控制台、在那里我可以获得 bdinfo 
我会将这些偏移用于我们的定制板、但它只有256MB 的 RAM、这些偏移明显超出了这些偏移、更不用说 U-Boot 会将自身重新定位到 SDRAM 堆栈的顶部。 同样、我实际上也尝试了使用该 relocaddr 值、但运气不好。 另一种选择是尝试通过调试 SPL 来查找 gd->relocaddr,但到目前为止未成功。 尝试将自定义电路板的 MLO 和 u-boot.img 放入 SD 卡并引导的相同方法时、UART 未打印任何内容。
我们之前的假设是 EMIF/Lisa 配置错误、但我们可以肯定、它们是正确的。 无论如何、我们的配置如下(Lisa 配置不是 SPRAC36工作簿提供的配置、因为我们发现它不正确)。 我们所需的 RAM 设置是 DDR3的一个连续256MB 块、仅映射到 EMIF2。 我们是硬件调平、我可以根据要求提供数据表。
静态常量结构 DMM_LISA 映射_regs beagle_x15_LISA 寄存器={
.dm_lisa_map_0 = 0x0、
.dm_lisa_map_1 = 0x0、
.dm_lisa_map_2 = 0x0、
.dm_lisa_map_3 = 0x80400200、
.in_ma_present = 0x1
};
静态常量结构 EMIF_REGS beagle_x15_emif2_DDR3_532mhz_EMIF_regs ={
SDRAM_CONFIG_INIT = 0x61855A32、
SDRAM_CONFIG = 0x61855A32、
SDRAM_CONFIG2 = 0x00000000、
.ref_ctrl = 0x000040F1、
.ref_ctrl_final = 0x00001035、
SDRAM_TIM1 = 0xcccf36ab、
SDRAM_TIT2 = 0x30457fda、
SDRAM_TIM3 = 0x407f83a8、
READ_IDLE_Ctrl = 0x00050000、
zq_config = 0x5007190b、
temp_alert_config = 0x00000000、
.EMIF_DDR_phy_ctlr_1_init = 0x0024400B、
.EMIF_DDR_phy_ctlr_1 = 0x0e24400b、
.EMIF_DDR_ext_phy_Ctrl_1 = 0x10040100、
.EMIF_DDR_ext_phy_Ctrl_2 = 0x0、
.EMIF_DDR_ext_phy_Ctrl_3 = 0x0、
.EMIF_DDR_ext_phy_Ctrl_4 = 0x0、
.EMIF_DDR_ext_phy_Ctrl_5 = 0x0、
.EMIF_RD_EV_LVL_RMP_WIN = 0x00000000、
.EMIF_rd_wr_lvl_RMP_ctl = 0x8000000、//启用硬件调平
.EMIF_rd_wr_lvl_ctl = 0x00000000、//硬件调平。 TRM 第3457页
.EMIF_rd_wr_exec_thresh = 0x00000305
};
静态常量 u32 beagle_x15_emif2_DDR3_ext_phy_Ctrl_const_regs[]={
0x10040100、//EMIF_EXT_PHY_CONTRAL_1
0x0、//EMIF_EXT_PHY_CONTRAL_2
0x0、//EMIF_EXT_PHY_CONTRAL_3
0x0、//EMIF_EXT_PHY_CONTRAL_4
0x0、//EMIF_EXT_PHY_CONTRAL_5
0x0、//EMIF_EXT_PHY_CONTRAL_6
0x0、//EMIF_EXT_PHY_CONTRAL_7
0x0、//EMIF_EXT_PHY_CONTRAL_8
0x0、//EMIF_EXT_PHY_CONTRAING_9.
0x0、//EMIF_EXT_PHY_CONTRAL_10
0x0、//EMIF_EXT_PHY_CONTRAL_11
0x0、//EMIF_EXT_PHY_CONTRAL_12
0x0、//EMIF_EXT_PHY_CONTRAL_13
0x0、//EMIF_EXT_PHY_CONTRAL_14
0x0、//EMIF_EXT_PHY_CONTRAL_15
0x0、//EMIF_EXT_PHY_CONTRAL_16
0x0、//EMIF_EXT_PHY_CONTRAL_17
0x0、//EMIF_EXT_PHY_CONTRAL_18
0x0、//EMIF_EXT_PHY_CONTRAL_19
0x0、//EMIF_EXT_PHY_CONTRAL_20
0x0、//EMIF_EXT_PHY_CONTRAL_21
0x0、//EMIF_EXT_PHY_CONTRAL_22
0x0、//EMIF_EXT_PHY_CONTRAL_23
0x40010080、//EMIF_EXT_PHY_CONTRAL_24
0x08102040、//EMIF_EXT_PHY_CONTRAL_25
0x0、//EMIF_EXT_PHY_CONTRAL_26
0x0、//EMIF_EXT_PHY_CONTRAL_27
0x0、//EMIF_EXT_PHY_CONTRAL_28
0x0、//EMIF_EXT_PHY_CONTRAL_29
0x0、//EMIF_EXT_PHY_CONTRAL_30
0x0、//EMIF_EXT_PHY_CONTRAL_31
0x0、//EMIF_EXT_PHY_CONTRAL_32
0x0、//EMIF_EXT_PHY_CONTRAL_33
0x0、//EMIF_EXT_PHY_CONTRAL_34
0x0 //EMIF_EXT_PHY_CONTRAL_35
};
由于我们能够在 u-boot-spl 运行完成后在 CCS 的"Memory"窗口中查看内存、因此我们相信我们处于 DDR3 RAM 中、这也是因为我们可以加载 U-Boot proper、这是一个4.4MB 的文件、比 AM5728上的高速缓存大。
考虑到具有已知工作器件树的 EVM 的运行方式与我们的定制板通过 JTAG 调试时的运行方式相同、因此研究这与器件树是否相关并不会产生太多结果。 起初、我想 U-Boot 本来可以在文件系统中查找 DTB 文件、但无论如何、器件树二进制文件会编译为 U-Boot 二进制文件。 与 EVM 相比、我们定制板的最大区别在于、定制板使用 MMC1和 MMC3作为 SD 卡笼。 MMC1是将引导 SD 加载到的单元。
因此、我的运行假设是、由于缺少适当的 printf 调试功能、难以确认定制板的器件树不起作用。 这种情况的证据是、当仅存在 MLO 和 u-boot.img 时、我可以从 EVM 进入 U-Boot 控制台、但当使用定制板完成同样的操作时、我不会收到任何内容。 然而、我们的定制板使用与 EVM 相同的 UART、并且可以在 SPL 期间打印消息、这证明了这一点。 我认为由于 preloader_console_init ()中的 SPL 调试初始化是在没有器件树的情况下完成的、因此这种证据充其量只是一个假象。
编辑2017年8月21日:我意识到我在使用 PSDK create-sdcard.sh 脚本时犯了一个简单的错误、错误地查找 u-boot 开发目录的预编译位置、并手动将我最近的 u-boot.img 和 MLO 加载到 SD 卡上的引导分区中。 我现在通过 UART 接收来自定制板的调试信息! 但是、我的板在以下位置挂起:
插入:表4031cd14,填充60/521 RV 81f13e0c => name="netboot" value="echo Booting from network ...;setenv autoload no;dhcp;运行 netloadimage;运行 netloadfdt; 运行 netargs;bootz ${loadaddr}-${fdtaddr}"
插件:免费(数据= 81f0ff88)
插入:完成
81f1a8c0
81f1a900
<2、0、1024>
81f1ad00
无法装入 ext2文件系统...
SPL_LOAD_IMAGE_ext:ext4fs 安装错误- 0
跳转到 U-Boot
已加载-跳转到 U-Boot...
图像入口点:0x80800000
当 U-Boot 实际上是 FAT 分区时,它似乎正在尝试将我的引导分区加载为 EXT2。 我的 rootfs 分区是 EXT4,但现在它是 emtpy。 当我使用 EVM 尝试此操作时、它工作正常、并正常跳转到 U-Boot。
编辑2017年8月21日#2:另一个问题、当我启动定制板时、我看到有关器件树的消息。 需要注意的是、我已经为定制板的器件树编辑了 am57xx-EVM-reva3.dts 文件、仅更新了 MMC 设置。
GC - clustnum:19931、startsect:22167
81f0ed00
81f0ed40.
大小:920128、得到:481728
图像:dst=80800000、data_offset=6f0、size=75990
这些选项中没有匹配的 DT:
am57xx-beagle-x15
am57xx-beagle-x15-revb1.
am57xx-EVM-reva3.
am572x-idk
am571x-idk
malloc_Simple:size=4、ptr = ed4c、limit=100000:81f0ed48
81f0ed80
81f0edc0
正在读取 uboot.env
81f0ee00
81f0f000
81f0f040
VFAT 支持已启用
FAT32、fat_sect:32、fatlength:1103
rootdir 从 cluster:2开始,扇区:2238,偏移量:117c00
数据开始于:2236
扇区大小:512,群集大小:1.
FAT 读取(sect=2238、cnt:1)、clust_size=1、DIRENTSPERBLOCK=16
81f0fc40.
RootMismatch:|MLO||
Rootvfatname:|u-boot.img|
RootMismatch:|u-boot.img|u-boot.img|
RootMismatch:|u-boot.img||
RootDentname ==空-6
**无法从 mmc0:1读取"uboot.env"**
使用默认环境
在 defconfig 中、我已将默认器件树更改为 CONFIG_DEFAULT_DEVICE_TREE="am57xx-EVM-reva3"
编辑2017年8月22日:在 /configs/am57xx_evm_defconfig 中注释 CONFIG_FIT = y 后、如所示 
我发现 U-Boot 试图通过器件树强行实施。 我已编辑或删除了我们未使用的 EVM 器件树的部分、但没有结果。 所附的调试日志来自 :e2e.ti.com/.../putty_5F00_g3_5F00_stripped_5F00_dt.log