U-Boot如何运行一个独立的二进制程序？
U-Boot How to run a standalone binary program?
我已经编译了一个简单的二进制文件（hello.bin）并将其存储在存储卡上。
我正在 运行使用 i.mx 6 四核处理器的 NXP Sabre 开发套件。我已经启动了 U-boot 并试图访问二进制文件并将其设为 运行。
hello.bin 可用，因为以下命令有效：
=> fatload mmc 1:4 0x20005000 hello.bin
reading hello.bin
按照我的理解，文件应该加载到地址为 0x20005000 的 RAM 中
所以我想测试二进制文件是否存在
=> md 0x20005000
20005000: 464c457f 00010101 00000000 00000000 .ELF............
20005010: 00280002 00000001 00010315 00000034 ..(.........4...
20005020: 000028f4 05000400 00200034 00280009 .(......4. ...(.
20005030: 00240025 70000001 00000454 00010454 %.$....pT...T...
看起来不错，因为起始位与我复制到 SD 卡的文件匹配。
当我尝试启动二进制文件时，设备报告未定义指令：
=> go 0x20005000
## Starting application at 0x20005000 ...
undefined instruction
pc : [<20005158>] lr : [<4ff71403>]
reloc pc : [<e7897158>] lr : [<17803403>]
sp : 4f56dd50 ip : 00000000 fp : 00000002
r10: 4f56f938 r9 : 4f56deb0 r8 : 4ffc3c40
r7 : 4ff713d9 r6 : 00000002 r5 : 20005000 r4 : 4f56f93c
r3 : 20005000 r2 : 4f56f93c r1 : 4f56f93c r0 : 00000000
Flags: nzCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
感谢您的帮助
请在 https://www.denx.de/wiki/view/DULG/UBootStandalone#Section_5.12.1.
处查找示例
go 不期望 ELF 二进制文件的开始，而是入口例程的地址。如果您想访问 U-Boot 例程，则必须重新定位二进制文件。
I have compiled a simple binary file (hello.bin) and stored it on a memory card.
你遗漏了很多重要的细节。
你是如何编译这个程序的，例如什么工具链，什么 makefile？
你 link 这个程序有图书馆吗？
The way I understand it the file should be loaded into RAM at the address 0x20005000
你是怎么得到这个"understanding"的？
通常，独立程序的加载地址取决于几个因素。
首先必须考虑可用内存（在目标板上）的地址。
其次，除非独立程序是可重定位的（在您的情况下不太可能），否则程序必须加载到程序 linked 时定义的 load/starting 地址。
程序的加载和起始地址可以从其映射文件中获得（即 linker 输出）。
When I try to start the binary, the device reports undefined instruction:
这就是 ELF header 为 "executed" 时发生的情况。
由于该文件显然包含一个 ELF header，因此其文件扩展名应该是 .elf 而不是 .bin.
这个可执行文件是如何获得误导性名称的？
您可能没有构建独立的二进制映像文件。
U-Boot 源代码的 examples/standalone/ 目录包含示例代码和用于构建独立二进制文件的 makefile，例如hello_world.bin.
请务必为 你的板 !
正确定义 CONFIG_STANDALONE_LOAD_ADDR
默认加载地址肯定不合适
the => bdinfo, command told me something about the DRAM bank, starts at 0x10000000 (7 zeros) and ends at 0x4000000.
（首先，不要在评论中添加重要信息。使用编辑功能将其添加到您的原始 post 中。）
您提供的 "information" 没有意义（即结束地址小于起始地址）。避免解释信息，而是简单地呈现（复制粘贴）实际输出。
I then used fatload mmc 1:4 0x10005000 hello.bin instead, which then seems to work. I guess I was writing to a out of bound address.
fatload命令只是将文件的内容复制到内存中。该副本的真正成功是通过验证内存来确认的，而不是命令的完成。
您的评论令人困惑，因为您没有提到任何先前的负载问题。
go 0x10005000 still does not work.
尝试任意 load/start 地址不是有效的调试技术。
"seems to work" 或 "still does not work" 的总和是对结果的 low-quality 描述。
参见 How To Ask Questions The Smart Way。
从另一个朋友那里得到了一些帮助，我发现它很有帮助所以我会 post 它：
您可以使用 Yocto 工具链，但您不能 link 针对 C 库（默认情况下完成），因此您必须向 GCC 添加一些额外的选项以让它知道，您也不能使用来自 U-Boot 的 go 指令跳转到您刚刚加载到内存中的 ELF 二进制文件，ELF 二进制文件必须转换为 'raw' 二进制文件（您的情况下的 ARM 指令列表）工具 objdump。一个 ELF 二进制文件，它是一种封装你的 code/your 数据和一些额外信息的特定格式，ELF 的第一部分是二进制文件的描述，所以现在，当你在 go第一个地址，你试图告诉 CPU 执行一些不是 ARM 指令的东西。您基本上想要执行我们称之为 ELF 二进制文件的“.text”部分。
我已经编译了一个简单的二进制文件（hello.bin）并将其存储在存储卡上。
我正在 运行使用 i.mx 6 四核处理器的 NXP Sabre 开发套件。我已经启动了 U-boot 并试图访问二进制文件并将其设为 运行。
hello.bin 可用，因为以下命令有效：
=> fatload mmc 1:4 0x20005000 hello.bin
reading hello.bin
按照我的理解，文件应该加载到地址为 0x20005000 的 RAM 中
所以我想测试二进制文件是否存在
=> md 0x20005000
20005000: 464c457f 00010101 00000000 00000000 .ELF............
20005010: 00280002 00000001 00010315 00000034 ..(.........4...
20005020: 000028f4 05000400 00200034 00280009 .(......4. ...(.
20005030: 00240025 70000001 00000454 00010454 %.$....pT...T...
看起来不错，因为起始位与我复制到 SD 卡的文件匹配。
当我尝试启动二进制文件时，设备报告未定义指令：
=> go 0x20005000
## Starting application at 0x20005000 ...
undefined instruction
pc : [<20005158>] lr : [<4ff71403>]
reloc pc : [<e7897158>] lr : [<17803403>]
sp : 4f56dd50 ip : 00000000 fp : 00000002
r10: 4f56f938 r9 : 4f56deb0 r8 : 4ffc3c40
r7 : 4ff713d9 r6 : 00000002 r5 : 20005000 r4 : 4f56f93c
r3 : 20005000 r2 : 4f56f93c r1 : 4f56f93c r0 : 00000000
Flags: nzCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
感谢您的帮助
请在 https://www.denx.de/wiki/view/DULG/UBootStandalone#Section_5.12.1.
处查找示例go 不期望 ELF 二进制文件的开始，而是入口例程的地址。如果您想访问 U-Boot 例程，则必须重新定位二进制文件。
I have compiled a simple binary file (hello.bin) and stored it on a memory card.
你遗漏了很多重要的细节。
你是如何编译这个程序的，例如什么工具链，什么 makefile？
你 link 这个程序有图书馆吗？
The way I understand it the file should be loaded into RAM at the address 0x20005000
你是怎么得到这个"understanding"的？
通常，独立程序的加载地址取决于几个因素。
首先必须考虑可用内存（在目标板上）的地址。
其次，除非独立程序是可重定位的（在您的情况下不太可能），否则程序必须加载到程序 linked 时定义的 load/starting 地址。
程序的加载和起始地址可以从其映射文件中获得（即 linker 输出）。
When I try to start the binary, the device reports undefined instruction:
这就是 ELF header 为 "executed" 时发生的情况。
由于该文件显然包含一个 ELF header，因此其文件扩展名应该是 .elf 而不是 .bin.
这个可执行文件是如何获得误导性名称的？
您可能没有构建独立的二进制映像文件。
U-Boot 源代码的 examples/standalone/ 目录包含示例代码和用于构建独立二进制文件的 makefile，例如hello_world.bin.
请务必为 你的板 !
正确定义 CONFIG_STANDALONE_LOAD_ADDR
默认加载地址肯定不合适
the => bdinfo, command told me something about the DRAM bank, starts at 0x10000000 (7 zeros) and ends at 0x4000000.
（首先，不要在评论中添加重要信息。使用编辑功能将其添加到您的原始 post 中。）
您提供的 "information" 没有意义（即结束地址小于起始地址）。避免解释信息，而是简单地呈现（复制粘贴）实际输出。
I then used fatload mmc 1:4 0x10005000 hello.bin instead, which then seems to work. I guess I was writing to a out of bound address.
fatload命令只是将文件的内容复制到内存中。该副本的真正成功是通过验证内存来确认的，而不是命令的完成。
您的评论令人困惑，因为您没有提到任何先前的负载问题。
go 0x10005000 still does not work.
尝试任意 load/start 地址不是有效的调试技术。
"seems to work" 或 "still does not work" 的总和是对结果的 low-quality 描述。
参见 How To Ask Questions The Smart Way。
从另一个朋友那里得到了一些帮助，我发现它很有帮助所以我会 post 它：
您可以使用 Yocto 工具链，但您不能 link 针对 C 库（默认情况下完成），因此您必须向 GCC 添加一些额外的选项以让它知道，您也不能使用来自 U-Boot 的 go 指令跳转到您刚刚加载到内存中的 ELF 二进制文件，ELF 二进制文件必须转换为 'raw' 二进制文件（您的情况下的 ARM 指令列表）工具 objdump。一个 ELF 二进制文件，它是一种封装你的 code/your 数据和一些额外信息的特定格式，ELF 的第一部分是二进制文件的描述，所以现在，当你在 go第一个地址，你试图告诉 CPU 执行一些不是 ARM 指令的东西。您基本上想要执行我们称之为 ELF 二进制文件的“.text”部分。