工具/软件:Linux
大家好、
我需要实施 U-boot 解决方案、该解决方案将能够判断器件的引导位置。
我发现 AM335有一个非常类似的情况: 这里
该解决方案使用 RTC 暂存寄存器将引导器件保存在 SPL 中、然后在稍后从全面的 U-Boot 中读回。
但是、该解决方案不适用于 AM57xx。
我检查了 AM57xx 的技术手册、并在 地址 0x48838060处找到了 RTC_SCRAATCH0_REG。
然后我编写了以下代码:
#define CONFIG_AM57X_RTC_BASE 0x48838000
#define CONFIG_AM57X_RTC_SCRATCCH0 0x60
#define BOOT_DEVICE_SAVE_REGISTER (CONFIG_AM57X_RTC_BASE + CONFIG_AM57X_RTC_SCRATCCH0)
#ifdef CONFIG_SPL_Build
static void save_boot_device (void)
{
*(((u32 *)(boot_device_save_register))= spl_boot_device ();
}
#endif
u32 boot_device (void)
{
返回*((u32 *)(boot_device_save_register));
}
//将引导设备存储在环境变量'boot_device'中*/
static void setenv_boot_device (void)
{
switch (boot_device()){
case boot_device_MMC1:{
setenv ("boot_device"、"sdcard");
中断;
}
case boot_device_MMC2_2:{
setenv ("boot_device"、"eMMC");
中断;
}
默认值:{
setenv ("boot_device"、"unknown");
中断;
}
}
我在 board_late_init()中调用 setenv_boot_device()。
然而 、boot_device_save_register (RTC_SCRATCH0_REG)的内容始终为0x0。
例如、在 u-boot 中对其进行读取/写入:
=> MD.L 0x48838060 1. 48838060:00000000 … => MW.L 0x48838060 DEADBEEF => MD.L 0x48838060 1. 48838060:00000000 … =>
或 Linux:
root@am57xx-phycore-RDK:~ evmem2 0x48838060 w /dev/mem opened。 映射到地址 bb6f9c000的内存。 在地址0x48838060 (bb6f9c060)处读取:0x00000000 root@am57xx-phycore-RDK:~ evmem2 0x48838060 w 0xDEADBEF /dev/mem 已打开。 映射到地址 bb6fd7000的内存。 在地址0x48838060 (bb6fd7060)处读取:0x00000000 在地址0x48838060 (b6fd7060)处写入:0xDEADBEEF、回读0xDEADBEEF root@am57xx-phycore-RDK:~ü devmem2 0x48838060 w /dev/mem 已打开。 映射到地址 bb6fe5000的内存。 在地址0x48838060 (bb6fe5060)读取:0x00000000 root@am57xx-phycore-RDK:~
AM57x 与 AM335有何不同?
RTC_SCRATCH0_REG 中缺少什么内容?
我出了什么问题?
谢谢
Primoz