主题中讨论的其他器件: FLASHTOOL
工具/软件:Linux
您好!
我们部署了两款使用 OMAP-L138处理器的产品。 问题是、其中许多(不幸的是、其中许多)安装了非常旧版本的 U-Boot、其中包含非常旧的 NAND 闪存驱动程序、当 NAND 器件产生位错误时、会导致现场单元变成砖型。
挑战在于、由于这些单元位于数百个位置、因此需要通过 Linux shell 脚本实现。 如果能从 Linux 中通过 U-Boot 分区进行写操作、我将不胜感激。
非常感谢、
Bill
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.
工具/软件:Linux
您好!
我们部署了两款使用 OMAP-L138处理器的产品。 问题是、其中许多(不幸的是、其中许多)安装了非常旧版本的 U-Boot、其中包含非常旧的 NAND 闪存驱动程序、当 NAND 器件产生位错误时、会导致现场单元变成砖型。
挑战在于、由于这些单元位于数百个位置、因此需要通过 Linux shell 脚本实现。 如果能从 Linux 中通过 U-Boot 分区进行写操作、我将不胜感激。
非常感谢、
Bill
大家好、是的、这是我4年前的老线程!
不幸的是、我从未真正能够使这个旧解决方案可靠地工作。 但是、当我开始阅读时、这个问题已经成为一个问题、我们必须解决这个问题、并尝试提出一个解决方案、以便现场的单元可以重新编程、并且不必通过 RMA 来重新刷写。
因此、我现在尝试使用构建最新的 U-Boot、而不需要单独的 UBL。 我从您提到的最后一个线程获得了代码基础 URL (我在下面粘贴了它、但出于某种原因、粘贴后、它被下面的大图标"覆盖")。 URL 仍在主题中列出: e2e.ti.com/.../1259113
下面是我尝试构建它时发生的情况: 我将在以下 VM 上构建它:
$ uname -a
Cygwin_NT-6.1 Volga-Win7 2.10.0 (0.35/3) 2018-02-02 15:16 x86_64 Cygwin
bgoetz@Volga-Win7 ~/AP4/board-support/u-boot-2017.01+gitAUTOINC+340fb36f04-g340fb36f04
$
以下是我尝试在其基础上进行构建时的输出:
bgoetz@Volga-Win7 ~/AP4/board-support/u-boot-2017.01+gitAUTOINC+340fb36f04-g340fb36f04
$ make cross_compile=arm-linux-gnueabi- distclean
/home/bgoetz/ap4/gcc-linaro-6.2.1-ti2017.01-armv5-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-gcc:/home/bgoetz/ap4/gcc-linaro-6.2.1-ti2017.01-armv5-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-gcc:无法执行二进制文件
/bin/sh:/home/bgoetz/ap4/gcc-linaro-6.2.1-ti2017.01-armv5-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-gcc:无法执行二进制文件:EXEC 格式错误
dirname:操作数丢失
请尝试'irname --help'获取更多信息。
make:***[Makefile:1455:_clear_drivers]中断
bgoetz@Volga-Win7 ~/AP4/board-support/u-boot-2017.01+gitAUTOINC+340fb36f04-g340fb36f04
$ objdump -f /home/bgoetz/ap4/gcc-linaro-6.2.1-ti2017.01-armv5-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-gcc
/home/bgoetz/ap4/gcc-linaro-6.2.1-ti2017.01-armv5-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-gcc:文件格式 elf64-x86-64
架构:i386:x86-64、标志0x00000112:
Exec_P、has、Syms、D_Paged
起始地址0x0000000000403040
bgoetz@Volga-Win7 ~/AP4/board-support/u-boot-2017.01+gitAUTOINC+340fb36f04-g340fb36f04
$这几个 ls
/usr/bin/ls
bgoetz@Volga-Win7 ~/AP4/board-support/u-boot-2017.01+gitAUTOINC+340fb36f04-g340fb36f04
$ objdump -f /usr/bin/ls
/usr/bin/ls:文件格式 PEI-x86-64
体系结构:i386:x86-64、标志0x0000010a:
Exec_P、has 调试、D_分 页
起始地址0x0000000100401000
bgoetz@Volga-Win7 ~/AP4/board-support/u-boot-2017.01+gitAUTOINC+340fb36f04-g340fb36f04
$
如果我想构建 U-Boot、我应该在 PC 上安装什么版本的虚拟机?
非常感谢、
Bill
实际上、考虑一下、如果我可以将实际源代码用于 nandwrite 可执行文件、而不是仅使用我在某人的 git 在线存储库中找到的源代码、这对我更有好处。
我注意到该可执行文件不是 busybox 的一部分。 该可执行文件是使用 Code Composer 编译的、还是仅使用.c 文件中的普通交叉编译器编译的? 您能给我指一下我可以在早上下载并编译它的位置吗?
再次感谢 Bill
所以这个图变得更浓...
我能够从 git 下载 MTD 实用程序。 然后能够对其进行交叉编译和链接、然后在我们的目标器件上运行。 这是一个稍旧的版本、但我认为它应该足够了。
因此,当我查看代码并一直跟踪代码的实际写入 OOB 数据的位置时,调用 MTD_WRITE_OOB (),然后调用 DO_OOB_OP()。
在该例程中,它调用 ioctl(),因此需要更改的代码(以不同的格式编写 OOB)实际上位于 Linux 内部。 哦...!
建立与设备驱动程序连接的调用为:
如果((FD =开路(MTD_DEVICE、O_RDWR))=-1)
SYS_errmsg_die ("%s"、MTD_DEVICE);
其中 MTD_DEVICE 为"/dev/mtd1。
在 DO_OOB_OP()中,写入 OOB 的调用为:
RET = ioctl (fd、cmd、&OOB);
尊敬的 Ron:
感谢您提供的信息!
因此、我面临的问题是、我无法在客户站点上当前安装的这些设备上"按原样"运行'shf_omap-L138.exe'文件。 我需要能够在当前已启动并正在运行的系统上运行该程序。 也就是说、我需要能够从 Linux 运行它。 如下所示:
Linux 下
串行闪存器可在安装了最新开源 Mono Framework 的 Linux 计算机上运行。 除以下命令外,这些步骤与 Windows 环境相同:
以上内容将直接在其上有 L-138的 Linux 系统上运行! 换句话说、在器件本身上、U-Boot 需要重写。 因此、我似乎可以对单声道实用程序进行交叉编译、使其在与我们的运输系统相同的操作系统下运行。 我需要对其进行修改、以便它不是通过 UART 连接加载程序、而是将其从 NAND 闪存加载到 RAM 中。 加载到 RAM 中后、跳转到它以某种方式执行它。 完成后、继续并重新引导系统。 系统启动时、将运行最新的 UBL/U-Boot。
那么、这是有道理的、这是可能的吗?
非常感谢、
Bill
那么、进度!
我已经能够解锁 U-Boot 分区、现在、当我按照 mdeneen 的建议使用工具 github.com/.../flashtool 时(谢谢您 BTW!) 我可以使用以下命令写入 UBL + U-Boot 分区:
root@Arago:~#./flashtool - legacy /dev/mtd2 -s 0 -ubi mtd1.hex
实际上、这几乎可以正常工作、写入数据和 OOB 数据、但 OOB 数据会写入错误的位置:
它写入:
0x00000200:FF 关断关断 FF 46 F9 a0 b4 bf DE 2e B7 53 B6
0x00000410:FF 关断关断 FF 85 02 1b F5 0A 59 fa d0 43 4e
0x00000620:FF 关断关断 FF fb f3 04 7d 02 F5 430A A7 6e
OOB 数据:FF 关断 FF AB C6 E6 b9 FD 4b 86 62 9b (这是来自 nanddump 输出的第四条 OOB 数据线)
等等
因此、它会正确跳过前6个字节、并写入10个正确的字节、但是、它不是在块的末尾写入它、而是写入0x200字节。
以下是它的预期外观:
0x000007e0:14 00 00 8a 00 00 50 E3 02 00 0A 01 00 50 E3
0x000007f0:10 00 00 1a 05 00 ea 04 00 a0 E3 ff 1c a0 E3
OOB 数据:FF 关断 FF 46 F9 a0 b4 bf DE 2e B7 53 B6
OOB 数据:FF 关断 FF 85 02 1b F5 0A 59 fa d0 43 4e
OOB 数据:FF 关断 FF fb f3 04 7d 02 F5 430A A7 6e
OOB 数据:FF 关断 FF AB C6 E7 b9 FD 4b 86 62 9b
0x00000800:22 2c a0 E3 8a fe ff EB 04 00 a0 e1 10 80 BD e8
0x00000810:0b 10 a0 E3 00 20 a0 E3 03 30 a0 E3 5e FE ff EB
请注意、OOB 数据是正确的!
关闭!
我猜我需要修改 flashtool.c 并确定如何获取实际块大小(或者只需对其进行硬编码、因为我只需要正确写入、然后再也不使用它、因为问题将得到解决。)
再次感谢、
Bill