5

我正在构建一个旨在在 ARM Cortex-M0+ 微控制器上运行的软件。它包括一个 USB 引导加载程序，在调用函数时作为辅助程序运行。我memcpy在编译期间插入函数时遇到问题。

背景

链接描述文件是一切开始的地方。其中大部分都非常简单和标准。该程序也存储在.text其中并从那里执行。里面的所有东西都.text存储在芯片的闪存部分。

奇怪的是引导加载程序运行的部分。为了能够在不覆盖引导加载程序代码的情况下写入所有闪存，我的引导加载程序入口点将引导加载程序程序的副本启动到微控制器的 SRAM 部分，然后从那里执行它。这样，引导加载程序可以安全地擦除设备上的所有闪存，而不会无意中删除自身。

这是通过在链接器脚本中做一个伪造的“覆盖”来实现的（真实的OVERLAY与我的用例不太匹配）：

/**
 * The bootloader and general ram live in the same area of memory
 * NOTE: The bootloader gets its own special RAM space and it lives on top
 * of both .data and .bss.
 */

_shared_start = .;
.bootloader _shared_start : AT(_end_flash)
{
    /* We keep the bootloader and its data together */
    _start_bootloader_flash = LOADADDR(.bootloader);
    _start_bootloader = .;
    *(.bootloader.data)
    *(.bootloader.data.*)
    . = ALIGN(1024); /* Interrupt vector tables must be aligned to a 1024-byte boundary */
    *(.bootloader.interrupt_vector_table)
    *(.bootloader)
    _end_bootloader = .;
}

.data _shared_start : AT(_end_flash + SIZEOF(.bootloader))
{
    _start_data_flash = LOADADDR(.data);
    _start_data = .;
    *(.data)
    *(.data.*)
    *(.shdata)
    _end_data = .;
}
. = _shared_start + SIZEOF (.data);
_bootloader_size = _end_bootloader - _start_bootloader;
_data_size = _end_data - _start_data;

_end_flash是对上一节末尾的引用，它将所有数据存储在闪存中（.text基本上.rodata所有.init只读的东西都会卡在那里）。

这样做的结果是.dataand.bss部分通常位于 RAM 中。但是，这些.bootloader部分也位于 RAM 中的相同位置。编译时，这两个部分都按顺序存储到闪存中。在我的crt0例程中，该.data部分从闪存复制到 RAM 中的相应地址（由 指定_start_data），并且该.bss部分被归零。我在该部分.text中存储了一个附加部分，该部分通过将其数据从闪存复制到 RAM 来启动引导加载程序，覆盖.data和中的任何内容.bss。引导加载程序的唯一退出是系统重置，因此它可以破坏正在运行的程序的数据。将引导加载程序复制到 RAM 后，它会执行它。

问题

显然，编译覆盖程序并确保所有引用都对齐可能存在一些问题。为了减轻从普通程序访问引导加载程序代码或从普通程序或引导加载程序访问的问题.data，.bss我在链接器脚本中有以下三行：

NOCROSSREFS(.bootloader .text);
NOCROSSREFS(.bootloader .data);
NOCROSSREFS(.bootloader .bss);

现在，每当我在.text（可能被引导加载程序擦除）、.data（引导加载程序位于其之上）或.bss（再次，引导加载程序位于其之上）和该.bootloader部分之间存在交叉时，编译器错误将是发布。

在我真正开始编写代码之前，这很有效。我的部分代码包括一些结构复制和其他类似的东西。显然，编译器决定这样做（bootloader_函数位于该.bootloader部分中）：

20000340 <bootloader_usb_endp0_handler>:
...
20000398:   1c11        adds    r1, r2, #0
2000039a:   1c1a        adds    r2, r3, #0
2000039c:   f000 f8e0   bl  20000560 <__memcpy_veneer>
...
20000560 <__memcpy_veneer>:
20000560:   b401        push    {r0}
20000562:   4802        ldr r0, [pc, #8]    ; (2000056c <__memcpy_veneer+0xc>)
20000564:   4684        mov ip, r0
20000566:   bc01        pop {r0}
20000568:   4760        bx  ip
2000056a:   bf00        nop
2000056c:   00000869    andeq   r0, r0, r9, ror #16

在我的芯片架构中，0x20000000直到大约的地址0xE000000都位于 SRAM 中（设备上实际上只有 4Kb）。下面的任何地址0x1fffffc00都位于闪存部分。

问题是这样的：在位于我的.bootloader部分 ( ) 的函数中，插入了对( 、和)bootloader_usb_endp0_handler的引用，因为我正在执行结构复制等操作。它所引用的地址是地址，它存在于闪存中……可以被擦除。memcpy2000039c200005622000056cmemcpy0x00000869

具体代码是：

static setup_t last_setup;
last_setup = *((setup_t*)(bdt->addr));

where setup_tis a two-word struct and bdt->addris avoid*我知道指向看起来像 a 的数据setup_t。此行生成对 的调用memcpy。

我的问题是：我真的很想保留我的结构复制。这很方便。有没有办法指定编译器将 memcpy 放入默认部分以外的特定部分？我希望仅针对引导加载程序模块发生这种情况。所有其他代码都可以memcpy...我只想为我的引导加载程序模块提供一份特殊的.bootloader副本

如果这根本不可能，我将要么在汇编中编写整个引导加载程序（不是那么有趣），要么走单独编译引导加载程序的路线，将它作为一个相当长的十六进制字符串包含在最终程序中，然后执行将其复制到 RAM 后的字符串。字符串路线对我的吸引力不是很好，因为它易碎且难以实施......所以任何其他建议也将不胜感激。

该模块的编译行是：

arm-none-eabi-gcc -Wall -fno-common -mthumb -mcpu=cortex-m0plus -ffreestanding -fno-builtin -nodefaultlibs -nostdlib -O0 -c src/bootloader.c -o obj/bootloader.o

通常优化会是-Os，但我试图摆脱memcpy......它没有用。

另外，我看过这个问题，但没有解决问题。

4

1 回答 1

0

我从未尝试过，但您可能会使用EXTERN()链接器脚本指令强制加载您的 newlibmemcpy()两次 - 首先在引导加载程序链接阶段进入您想要的部分，然后取消定义它并将其第二次链接到您的“正常”代码中。

于 2015-01-23T07:39:38.377 回答