начальный адрес gcc

В настоящее время я пытаюсь скомпилировать проект mbed в автономном режиме с использованием gcc-arm-embedded, но я хочу изменить начальный адрес, поскольку эта программа предназначена для использования с загрузчиком, поэтому в конечном итоге придется запускать с 0x10000. Я экспортировал свой проект как GCC-ARM-EMBEDDED и могу построить проект с помощью gcc. Однако я не знаю, как указать начальный адрес 0x10000. Я попытался изменить сценарий LPC1768.ld, изменив ORIGIN FLASH на 0x10000, но мне кажется, что он ничего не делает.

MEMORY
{
  FLASH (rx) : ORIGIN = 0x00010000, LENGTH = 0x70000
  RAM (rwx) : ORIGIN = 0x100000C8, LENGTH = 0x7F38

  USB_RAM(rwx) : ORIGIN = 0x2007C000, LENGTH = 16K
  ETH_RAM(rwx) : ORIGIN = 0x20080000, LENGTH = 16K
}

Есть ли в Makefile или где-то еще опция, которая поможет изменить начальный адрес программы, чтобы она могла работать правильно, когда я перехожу с загрузчика на адрес 0x10000?

РЕДАКТИРОВАТЬ:

Я думаю, что понимаю, чего мне нужно достичь, благодаря паре ответов, но по некоторым причинам я не могу заставить это работать. Mbed не экспортирует файл startup_LPC17xx.s, поэтому я попытался использовать файл из CMSIS, но безуспешно. Мне интересно, действительно ли мне нужно изменить код запуска, поскольку процесс выглядит следующим образом:

  • Загрузчик работает с 0x0000
  • Загрузчик выполнит некоторые проверки и в конечном итоге запустит пользовательское приложение с адресом 0x10000. Загрузчик фактически перемещает векторную таблицу перед переходом на 0x10000. Это пользовательское приложение, которое я пытаюсь создать с помощью gcc, оно не будет работать при включении питания, оно будет работать только после того, как загрузчик запустится. Не уверен, что это ясно, но я бы подумал, что сработает только изменение сценария компоновщика ... но это не так.

Подробная информация о скрипте компоновщика, в котором я изменил адрес этого раздела на 0x10000:

РАЗДЕЛЫ {

.text : 
{
    *startup_LPC17xx.o 
    KEEP(*(.isr_vector))
    *(.text*)

    KEEP(*(.init))
    KEEP(*(.fini))

    /* .ctors */
    *crtbegin.o(.ctors)
    *crtbegin?.o(.ctors)
    *(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
    *(SORT(.ctors.*))
    *(.ctors)

    /* .dtors */
    *crtbegin.o(.dtors)
    *crtbegin?.o(.dtors)
    *(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
    *(SORT(.dtors.*))
    *(.dtors)

    *(.rodata*)

    KEEP(*(.eh_frame*))
} > FLASH

.ARM.extab : etc..

РЕДАКТИРОВАТЬ2: Я добавил * startup_LPC17xx.o в свой сценарий, похоже, сейчас все работает нормально :)


gcc bootloader arm embedded cortex-m3
person batmat    schedule 08.10.2012    source источник
comment
Ищу в поисковой системе слово "голый металл". Я нашел это, например, balau82 .wordpress.com / 2010/02/14 /   -  person auselen    schedule 09.10.2012
comment
Итак, когда вы отлаживаете с помощью gcc, он не сбрасывает ваш загрузчик и правильно переходит к вашей основной функции?   -  person jjxtra    schedule 08.12.2016

Ответы (2)


arrow_upward
1
arrow_downward

В файле компоновщика укажите раздел, который начинается с 0x10000. Затем в вашем crt0 или аналогичном коде запуска вам необходимо определить обработчик записи сброса как находящийся в этом разделе, чтобы компоновщик поместил его туда. Это может быть через .section или #pragma или аналогичный механизм. Вы можете проверить, просмотрев сгенерированный файл карты компоновщика, чтобы увидеть, что он помещает ваш обработчик сброса в 0x10000.

person TJD    schedule 08.10.2012
comment
Спасибо за это, я добавил некоторые детали к своему вопросу, так как часть загрузчика очень важна для понимания того, чего я хочу достичь. - person batmat; 09.10.2012
comment
Это действительно имеет смысл и работает как шарм :) Извините за поздний ответ, но у нас возникли проблемы с компиляцией с помощью GCC, теперь все в порядке! Для записи я отредактировал сценарий компоновщика моего вопроса с тем, который в настоящее время работает. - person batmat; 16.11.2012

arrow_upward
0
arrow_downward

Я попытался изменить сценарий LPC1768.ld, изменив ORIGIN FLASH на 0x10000, но мне кажется, что он ничего не делает.

Проверьте настройки компоновщика, правильно ли вы используете скрипт компоновщика. Здесь работает с изменением ORIGIN и размера (LPC1768 с arm-none-eabi-gcc). Обратите внимание, что получившаяся программа больше не будет выполняться на «голом железе», поскольку таблица векторов будет находиться в неправильном положении: ваш загрузчик должен быть на месте, чтобы запустить ее.

Обратите внимание, что ваш загрузчик не должен переходить к 0x10000, а должен загружать вектор сброса из таблицы с 0x10004 в ПК. Бонусные баллы при загрузке MSP (указателя основного стека) из 0x10000 непосредственно перед этим.

person Turbo J    schedule 09.10.2012
comment
Спасибо за помощь TurboJ, я изменил скрипт LPC1768.ld в HelloWorld \ mbed \ LPC1768 \ GCC_ARM \. Мой makefile указывает скрипт компоновщика как: LINKER_SCRIPT = ./mbed/LPC1768/GCC_ARM/LPC1768.ld. Теперь, если я сборка с ORIGIN FLASH на 0x10000 или ORIGIN на 0x00000, я получаю точно такой же файл. Если я избавлюсь от файла LPC1768.ld, gcc будет жаловаться, так что я предполагаю, что он действительно его использует. Я думаю, что понимаю векторную часть, поскольку мне удалось скомпилировать некоторые проекты с помощью Keil uVision (по адресу 0x10000), но мы еще не собираемся покупать uVision, чтобы преодолеть ограничение по размеру, поэтому мы используем gcc. - person batmat; 11.10.2012