您好!
在我们的系统中、我们通过以太网将 C6670连接到 Linux 主机 PC。 我们使用以太网启动过程。
长期以来、我们建立了一个过程、使用十六进制实用程序生成引导表、然后转换为适合引导的二进制文件。 查看 mcsdk_2_01_02_06\tools\boot_loader\examples\ethernet/Utilities\bconvert64x.c 和 mcsdk_2_01_02_06\tools\boot_loader\examples\ethernet/Utilities\bootpacket.c、我发现我可以自己进行这种转换。 首先、我们制作了简单的实用程序、用于将 ASCII 十六进制文件转换为二进制文件。 我怀疑提供了 bconvert64x.c 的奇特功能来处理不同的存储器组织以及可能的字节序转换。 由于我们的器件为32位、所有数据均为32位、因此我们不需要这种情况、并且我们始终在默认的小端模式下工作。 因此、我的实用程序仅包含将十六进制符号转换为二进制表示法、直到文件结束 我们也不使用 bootpacket.c、因为我们开发了自己的解决方案来重置 DSP、捕获其 ETh 就绪帧、拾取其 MAC 地址、并使用引导表片段编写和传输帧。 这对我们来说是完美的。
我不喜欢在处理过程中使用批处理文件来调用 TI 的十六进制实用程序、然后是我们的内部实用程序。 GCT 的机器到机器版本可能不同、批量查找正确 CGT 的自动化是我希望避免的工作。 同时、我在论坛中看到、有一种方法可以在 http://processors.wiki.ti.com/index.php/Projects_and_Build_Handbook_for_CCS#Pre_and_Post_Build_Steps 上生成二进制文件作为编译后处理步骤 、即"${CCS_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin "${BuildArtifactFileName}""${BuildArtifactFileBaseName}.bin""${CG_TOOL_ROOT}/bin/ofd2000 ""${CG_TOOL_ROOT"}/bin/hex2000 "/utils/tiobj2bin/mkhex4bin "。 当然可以
dsp.out
-a
-boot
-e _c_int00
-订购 L
ROM
{
ROM1:org = 0x0400、长度= 0x80000、memwidth = 32、romwidth = 32
文件={ dsp.btbl }
在此步骤中、我从开始接收引导表
//这是二进制02符号 $A0400、 0C 08 D0 40 00 44 60 0C 0B 18 28 04 53 01 07 53 38 00 00 00 3F 00
有趣的一点是、bconvert64实用程序会跳过前两行。 其次、我知道$A0400的重要性、但它与--bootorg 参数匹配。 我浏览了汇编语言用户指南和引导加载程序 UG、但没有加深我的理解、
问题2. 十六进制实用程序是否可以二进制形式提供输出?
问题3. 由十六进制实用程序生成的引导表中这两行的重要性是什么?
谢谢你。
