Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: свежак KGP win32/arm/avr/mips/m68k
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > GNU/OpenSource средства разработки для avr/arm/mips
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20
klen
Цитата(Ash_snz @ Nov 9 2011, 09:35) *
Бойцы невидимого фронта сильно зависят от задач, которые ставят выше.
ОК, Раскладку нарисую. А почему чудной? вроде довольно последовательно...

чудной поому что Вы явно распихиваете объектники - зачем такой гимор? а если еще модуль появится в проекте - оптья скрипт править? я правильно понял содержимое скрипта?
Ash_snz
Цитата(klen @ Nov 9 2011, 12:29) *
чудной поому что Вы явно распихиваете объектники - зачем такой гимор? а если еще модуль появится в проекте - оптья скрипт править? я правильно понял содержимое скрипта?
Верно. Так и есть.

Карта:
ОЗУ 0xa000 0000 - 0xa00F FFFF (1MB)
ПЗУ 0xBFC0 0000 - 0xBFCF FFFF (1MB)
Это все виртуальные адреса.

При этом существует кешируемая память. т.е. физические адреса будут теже (кому в ОЗУ - тому в ОЗУ, кому в ПЗУ - тому в ПЗУ) а виртуальные станут на -0x2000 0000 меньше
Получается что при обращении по уменьшенному адресу данные побегут через кеш проца, но наруже попадают все равно туда же.
Кешируемое:
ОЗУ 0x8000 0000 - 0x800f ffff
ПЗУ 0x9fc0 0000 - 0x9fcf ffff

boot.o Мы четко располагаем в 0xbfc0 0000 это стартовый адрес - никуда не дется
except.o тоже четко в 0xbfc0 0180 это адрес обработчика прерываний.
tini.o - инициализация, расположили за ними.
Это все без вариантов в некешируемой области (еще и на ассемблере).

Текст основной программы main.o в кешируемую область, поэтому от адреса - 0x20000000, но расположили в бинарнике сразу за предыдущей секцией, чтобы не получать бинарник на полГига и запихать его в пзушку.

Расположение остальных секций - шаманство с переменными.

зы на самом деле при обращении в ПЗУ по стартовому адрему 0xbfc0 0000 мы попадаем не в начало ПЗУ, это ровно ее середина.
Соответственно начало ПЗУ в адресе 0xbfb0 0000 и размер ее 2МБ, но мы за первостью опытов используем только верхнюю половину размером с 1 МБ...
AHTOXA
Цитата(klen @ Nov 9 2011, 01:49) *
свежак для ARM. хост - linux64

http://klen.org/Files/DevTools/linux-x86_6..._64-20111108.7z
75.2 Mb


Что-то у меня не заработало (на M3). Ругается линкер:
Цитата
ld: warning: creating a segment to contain the file and program headers outside of any MEMORY region


Тестовый пример я постил здесь, на нём ошибка тоже проявляется.
Aaron
Цитата(klen @ Sep 25 2011, 15:33) *
...
сборка ARM для win32
http://klen.org//Files/DevTools/mingw32/ar...w32_20110925.7z
не тестировал

Решил осваивать C++, как пример изучаю scmRTOS.
Со старой сборкой (4.6.0 20101030) всё компилится и работает (пример из исходников ОС), а с указанной выше имеем:
Цитата
-----------------------------------------------------------
arm-kgp-eabi-gcc (Klen's GNU package (KGP) for ARM/elf platform) 4.7.0 20110618 (experimental)
--- C++ compiling ./src/main.cpp...
C:/DevTools/arm_kgp_eabi_x86_32/bin/arm-kgp-eabi-g++ -c -mcpu=cortex-m3 -mthumb -I "./src" -I "SamplesCommon" -I "scmRTOS/Common" -I "scmRTOS/Cortex-M3" -I "scmRTOS/Extensions/Profiler" -MD -DSTM32F10X_MD_VL -DVER_MAJOR=0 -DVER_MINOR=1 -Wa,-adhlns=./lst/main.lst -O3 -g -fno-exceptions -fno-rtti -ffunction-sections -fdata-sections -fno-threadsafe-statics -funsigned-bitfields -fshort-enums -Wall -Wextra -Winline -Wpointer-arith -Wredundant-decls -Wshadow -Wcast-qual -Wcast-align -pedantic -o obj/main.o ./src/main.cpp
mingw32-make: *** [obj/main.o] Error 1

Попробовал этот вызов запустить из консоли винды, получил:Нажмите для просмотра прикрепленного файла
Попробовал заменить эту библиотеку старой (от 4.6.0 сборки), сообщение осталось то же самое.
Ash_snz
2 Klen

Умудрился собрать бинарник со следующим скриптом->
И даже размер не гиговый.

CODE
MEMORY
{
ROM : ORIGIN = OxbfcOOOOO, LENGTH = 1M
/*ROM2 : ORIGIN = 0x10000000, LENGTH = 1M*/
RAM : ORIGIN = 0x80000000 , LENGTH = 1M
}
/*REGION_ALIAS ( "REGION_TEXT" , ROM) ; */
REGION_ALIAS("REGION_TXT1", ROM) ;
REGION__ALIAS ( "REGION_TXT2" , ROM) ;
REGION___ALIAS ( "REGION_TXT3" , ROM) ;
REGION__ALIAS ( "REGION_TXT4" , ROM) ;
REGION_ALIAS("REGION_RODATA", ROM) ;
REGION_ALIAS("REGION_DATA", RAM) ;
REGION_ALIAS("REGION_SDATA", RAM) ;
REGION_ALIAS("REGION_BSS", RAM) ;
REGION_ALIAS("REGION_SBSS", RAM) ;
REGION^ALIAS("REGION_DEFAULT",ROM) ;

SECTIONS
{
.txtl 0xbfc00000 :
{
boot.o(.text)
} > REGION_TXT1

.txt2 0xbfc00180 :
{
except.o(.text)
}>REGION_TXT2

.txt3 (ADDR(.txt2) + SIZEOF(.txt2)):
AT (ADDR(.txt2) + SIZEOF(.txt2))
{
tini.o(.text)
}>REGION_TXT3

.txt4 ((ADDR( .txt3) + SIZEOF(.txt3))-0x20000000 ) :
AT (ADDR( .txt3) + SIZEOF(.txt3))
{
main_text_start = . ;
CREATE_OBJECT_SYMBOLS
main.o(.text .text.* .text.cos)
mxm_ash.o(.text)
*(.text.*)
PROVIDE (errno = .);
}

.rodata:
AT (ADDR( .txt3) + SIZEOF(.txt3) + SIZEOF(.txt4))
{
*(.rodata .rodata.*)
}> REGION_RODATA

/*_gp = ALIGN(16) + 0x7ff0;*/

.sdata 0x80000000 :
AT (ADDR( .txt3) + SIZEOF(.txt3) + SIZEOF(.txt4) + SIZEOF(.rodata)
{
/*PROVIDE ( _errno = 0xbfc00000);*/
*(.sdata .sdata.* .gnu.linkonce.s.*)
} > REGION_SDATA

.sbss :
AT (ADDR(.rodata) + SIZEOF(.rodata) + SIZEOF(.sdata))
{
*(.dynsbss)
*(.sbss .sbss.* .gnu.linkonce.sb.*)
*(.scommon)
}> REGION_SBSS


.data:
AT (ADDR(.sbss) + SIZEOF(.sbss))
{
*(.data)
SORT(CONSTRUCTORS)
} > REGION_DATA


/*. = ADDR(.data) + SIZEOF(.data);
. = ALIGN (32);*/

.bss:
AT (ADDR(.data) + SIZEOF(.data))
{
*(.bss)
*(COMMON)
} > REGION_BSS

/*.default :
AT (ADDR(.rodata) + SIZEOF(.rodata) + SIZEOF(.sdata) + SIZEOF(.sbss)
{
*(.* .*.-*)
}*/


_gp = ALIGN(32);/* + Ox7ffO;*/

}


Принцип скрипта такой же, к сожалению.

По скрипту остались вопросы:
- где и зачем должен быть global pointer - _gp? в какой области памяти и вообще на кой он?
- где должен быть __errno? Смутно догадываюсь что это номер ошибки мат библиотеки.
- почему при расположении errno в оперативе он ругается R_MIPS_26 (кажется так)? Предполагаю что ошибка невозможности джампа через 26 битный адрес. Надо пересобирать libm для джампа по 32 разрядам?
klen
2_AHTOXA
это ж варнинг, у меня тоже ругается, и все работает после зашивки. я пока так и не выяснил причину варнинга потому что имени сегмента линкер не называет. надщ под отладчиком линкер смотреть. рабочая гипотиза что это что-то новое из разряда отладочных секций которые в скрипте не указаны, вот он ее и не знает куда сунуть и в конечном итоге выкидывает. поскольку прошивки работают и отлаживаются в микросхеме - я пока подзабил на это.

2_Aaron
".. точка входа в libstdc++ ..." это известная мне ситуация. дело в том что периодически меняется интерфейс libcstdc++ и тогда если компилятор пытается грузануть libcstdc++.dll(.so) не той версии (например если установлена еще и другая версия компилера)- например из за косяков с путями и тд - то он естественно отвалится. в дистрибутиве который я выкладываю всегда есть эти либы в /lib /lib64 для сошек, dll'ки всегда лежат в /bin вместе с бинарниками.

2_Ash_snz
по поводу символов в скрипте это - воля разработчика программы и библиотек - они могут по логике требовать адреса, ну наприме CRT коду нада знать начало и конец секций data и bss чтоб их проинициализировать. тут в каждом конкретном случае отделно нада разбиратся. По поводу R_MIPS_26 я точно не знаю, но очень похоже на то что вы сказали. пробуте вообще все пересобрать с поддержкой длинных вызовов - а там видно будет. Вообще не имея локументации на микросхемы все про комдивчик мне видится очень мутным - я полагал что будет еще проще чем с армами, судя по тому что имеет microchip c pic32 в котором также m4k ядро.
AHTOXA
Цитата(klen @ Nov 12 2011, 15:08) *
2_AHTOXA
это ж варнинг, у меня тоже ругается, и все работает после зашивки.

У меня не получилось даже зашить полученную прошивку, её не переваривает openocd. Да и судя по размеру полученных сегментов (text - 10k против 15k в прошлой версии, и т. д.), линкер там явно что-то выкинул.
Ещё смутили многочисленные вхождения чего-то типа .gnu.lto_.* в map-файле, хотя LTO я не включал.
klen
Цитата(AHTOXA @ Nov 12 2011, 13:29) *
У меня не получилось даже зашить полученную прошивку, её не переваривает openocd. Да и судя по размеру полученных сегментов (text - 10k против 15k в прошлой версии, и т. д.), линкер там явно что-то выкинул.
Ещё смутили многочисленные вхождения чего-то типа .gnu.lto_.* в map-файле, хотя LTO я не включал.


многочисленные .gnu.lto_.* это все теже секцции с кодом или данных при включенном секцеонировании --fdata-section -ffunction-section но с включенным еще и LTO. дело в том что все либы я собираю с LTO. если пользователь воткнет эту оптимизацию лоя своего кода и скажет линкеру оптимизировать то весь проект
заоптимизируется, а если бы я собирад без LTO либы - то тогдюа пользователдь смог бы отоптимизировать при линковке только свои объектники. Я дума причина не в этом. у меня то работает. значит различия не в компилере а в коде и опциях компилера и скрипте линкера. нада разбиратся. Попробуйте чтонить савсем простое скомилять и залинковать и посмотреть на выходной дамп - станет ясно где что произошло

а вот то что OpenOCD тупит на входной файл - это вообще жесть какаято. это может быть только если ELF битый и он не может от туда вытащить данные для зашивки... злобный косяг какойто. сборка последняя полностью или чтото намешано?
Ash_snz
Цитата(klen @ Nov 12 2011, 15:08) *
2_Ash_snz
По поводу R_MIPS_26 я точно не знаю, но очень похоже на то что вы сказали. пробуйте вообще все пересобрать с поддержкой длинных вызовов - а там видно будет. Вообще не имея документации на микросхемы все про комдивчик мне видится очень мутным - я полагал что будет еще проще чем с армами, судя по тому что имеет microchip c pic32 в котором также m4k ядро.
Смотри личку.
У нас кстати R3000 ядро.
Пересобрать, это Новая задача sm.gif Вызов принят.
В прошлый раз все было пересобрано великим Кленом под фаст маф и хард флоат.
klen
Цитата(Ash_snz @ Nov 12 2011, 19:50) *
У нас кстати R3000 ядро.

чето я попутол все.... действительно R3000
AHTOXA
Цитата(klen @ Nov 12 2011, 18:24) *
Попробуйте чтонить савсем простое скомилять и залинковать и посмотреть на выходной дамп - станет ясно где что произошло
а вот то что OpenOCD тупит на входной файл - это вообще жесть какаято. это может быть только если ELF битый и он не может от туда вытащить данные для зашивки... злобный косяг какойто. сборка последняя полностью или чтото намешано?

Ну вот тот самый тестовый пример, который я постил. Вот что на него говорит openocd:
Цитата
Error: No flash at address 0x07fff000
Error: address range 0x08000644 .. 0x080007ff is not sector-aligned
Command handler execution failed

openocd пробовал и из этой сборки, и прошлый, точно рабочий.
Ash_snz
Цитата(klen @ Nov 13 2011, 05:15) *
чето я попутол все.... действительно R3000
А не попадался ли какой мануал на тему - сборка с лонгджампами и без для чайников?
klen
Цитата(AHTOXA @ Nov 13 2011, 14:35) *
Ну вот тот самый тестовый пример, который я постил. Вот что на него говорит openocd:
openocd пробовал и из этой сборки, и прошлый, точно рабочий.


понятно. я посотрел под отладчиком как gold секциизакидывает в регионы памяти - у мня эта цифра тоже была. видимо это глюк локальный. пока могу предложить в папках bin /arm-kgp-eabi/bin поменять ld чтоб он указывал на ld.bfd а не ld.gold. По умолчанию в моей сборке при линковке используется голд, с обыным ld я разниы не заметил но голд преспективнее и наверно быстрее.

2_Ash_snz
с longcall ( longjump - это из другой оперы - переключение контекста в проге ) нет никаких хитростей. если неставить компилеру -mlong-calls то он пытается сделать короткий вызов - если адрес можно заменить смещением и даже самим адресом функции - это экономит такты проца, если воткнуть -mlong-calls то тогда адрес вычисляется впихивается в регистр и уже тогда вызываетя функция. можно непосдедственно управлять вызовом функции обявляя ее например
void __attribute__ ((long_call)) foo()
{
.......
}
такая функция будет вызыватся длинно.
также модно назначить блоку кода эту опцию
#pragma long_calls
.....any code with func long calls method...
#pragma no_long_calls

вот ссылка на ликбез http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc.pdf



Aaron
Цитата(klen @ Nov 12 2011, 12:08) *
2_Aaron
".. точка входа в libstdc++ ..." это известная мне ситуация. дело в том что периодически меняется интерфейс libcstdc++ и тогда если компилятор пытается грузануть libcstdc++.dll(.so) не той версии (например если установлена еще и другая версия компилера)- например из за косяков с путями и тд - то он естественно отвалится. в дистрибутиве который я выкладываю всегда есть эти либы в /lib /lib64 для сошек, dll'ки всегда лежат в /bin вместе с бинарниками.

Да, действительно. Нашлась ещё такая библиотека в mingw, а он у меня в path раньше прописан, чем kgp sm.gif значит просто до этого повезло и бинарный интерфейс библиотеки mingw и kgp совпадал!
AHTOXA
Цитата(klen @ Nov 15 2011, 01:38) *
видимо это глюк локальный. пока могу предложить в папках bin /arm-kgp-eabi/bin поменять ld чтоб он указывал на ld.bfd а не ld.gold.

Да, точно, так заработало. (Кстати, там не линки, а прямо копии были).
С LTO правда что-то не то выходит:
__________text data bss dec hex
без LTO: 13312 52 7448 20812 514c
__с LTO: 15616 36 19796 35448 8a78
Видимо, так и есть, какой-то локальный косяг.

Ув. klen, а не могли бы вы собрать для всех здесь что-нибудь стабильное? Типа, "4.6.0 RC", или что-то вроде того? Такая просьба здесь уже звучала, но видимо подзабылась уже. Дело в том, быть "на острие" и тестировать новые сборки безусловно приятно и интересно, но иногда надо на чём-то работатьsm.gif Хочется в таких случаях иметь что-то понадёжнее.
Пожалуйста! santa2.gif
Ash_snz
Цитата(klen @ Nov 15 2011, 01:38) *
2_Ash_snz
с longcall ( longjump - это из другой оперы - переключение контекста в проге ) нет никаких хитростей. если неставить компилеру -mlong-calls то он пытается сделать короткий вызов ...method...
#pragma no_long_calls

вот ссылка на ликбез http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc.pdf
В мэйкфайле лонгкол стоит. Мы его туда даже довольно давно затолкали оказывается. Т.е. получается что моя прога вроде как с лонгколами идет. а вот траблы возникают при попытках _errno в оперативу запихать. Ятак понимаю, это кусок матем библ., при том стандартной. Ни кто не владеет информацией - куда должен указывать этот символ(_errno) в ОЗУ или ПЗУ?
А не понадобиться ли пересобирать libm с long-call для этого дела?

и абсолютно такая же непонятка с global pointer - _gp - тоже ничего про него не знаю sad.gif описания какие-то вялые везде.

зы. сейчас использую memcpy для копирования инициализированных переменных (образа памяти) в ОЗУ. начинает работать лучше и лучше. Вот только выяснил нахождение глобальных переменных, но не локальных. Локальные в областсях .data? почему-то ни objdump ни readelf ни при создании карты (-М) не показывается где они живут.
ReAl
Цитата(AHTOXA @ Nov 15 2011, 16:33) *
Ув. klen, а не могли бы вы собрать для всех здесь что-нибудь стабильное? Типа, "4.6.0 RC", или что-то вроде того? Такая просьба здесь уже звучала, но видимо подзабылась уже. Дело в том, быть "на острие" и тестировать новые сборки безусловно приятно и интересно, но иногда надо на чём-то работатьsm.gif Хочется в таких случаях иметь что-то понадёжнее.

А ещё бы со статической линковкой библиотек... И для AVR тоже стабильную...

klen
Цитата(ReAl @ Nov 16 2011, 17:24) *
А ещё бы со статической линковкой библиотек... И для AVR тоже стабильную...


могу.
встречный вопрос - а как вы измерили что то что я выкладываю нестабильно? методику и результаты с номерами сборок в студию. впрос не празный, я лично нарвался на косяг тольок один раз с LTO. статистика будет полезна.

можно сделать сборку из релизов :
binutils 2.21
gcc 4.6.2
gdb 7.3.1
newlib 1.19.0
openocd 0.5.0

тока я не уверен что можно выдумать хитрый агрегативный критерий по которому эта сборка будет наилучшей из всех. но если народ требует можно и собрать.
с AVR были косяги с упаковкой отладочной информации в elf, я проконсультиюсь у авторов че де как с авр.
mips-вой сборкой кто пользуется?
AHTOXA
Цитата(klen @ Nov 16 2011, 22:07) *
могу.
встречный вопрос - а как вы измерили что то что я выкладываю нестабильно?

Я про все найденные проблемы рапортую прямо здесь. Но я тестирую не каждый свежак.
Но дело даже не в этом. Дело в том, что хочется иметь две сборки - тестовую, для души, и нечто вроде релизной - для дела. Не потому, что в свежаках непременно есть косяки, а потому, что они возможны.
Цитата(klen @ Nov 16 2011, 22:07) *
тока я не уверен что можно выдумать хитрый агрегативный критерий по которому эта сборка будет наилучшей из всех. но если народ требует можно и собрать.

Ну есть же у них какие-то стабильные отсечки? Альфа, бета, релиз-кандидат, релиз, релиз с исправлениями... Вот чтоб не ниже уровня релиз-кандидатаsm.gif
ReAl
Цитата(klen @ Nov 16 2011, 18:07) *
могу.
встречный вопрос - а как вы измерили что то что я выкладываю нестабильно?
Меня до сих пор больше AVR интересует.
Но вот из этого
http://electronix.ru/forum/index.php?showt...mp;#entry961742
у меня сборка AVR так и не заработала
http://electronix.ru/forum/index.php?showt...mp;#entry962552

Подбрасывал библиотеки из соседнего архива, вроде запустилось, но ругнулось на отсутствие ldscripts, подбросил их из предыдущей сборки, которую иногда запускаю (кажется, ещё от мая 2010) — начал падать ld.
Нюансов не помню, это на работе нужно опять смотреть и вспоминать.
Библиотеки не кешировал, запускаю с LD_LIBRARYPATH=чего_надо перед именем исполняемого бинарника.
http://electronix.ru/forum/index.php?showt...mp;#entry962230
(ну там может не lib, а lib64, по месту смотрел что надо)
С кешированием у меня ещё на сборках 2010 года потом вылазила проблема с каким-то другим софтом, с тех пор и не пробовал.
Потому и попросил статическую сборку.

Предыдущая сборка AVR и какая-то из более свежих ARM-овских так вполне работают.

Дома у меня сейчас на dell-овском ноуте убунта 10.04 32-битная (стояла на нём с завода, не менял), так что родным убунтячьим avr-gcc пользуюсь.
klen
ок. соберм из релизов. но что получится из этого нам пока не известно sm.gif
ARV
Цитата(klen @ Nov 17 2011, 10:41) *
ок. соберм из релизов. но что получится из этого нам пока не известно sm.gif
и, если можно, снизойдите до 32-битного варианта тоже...
Ash_snz
Цитата(klen @ Nov 16 2011, 22:07) *
mips-вой сборкой кто пользуется?
Мипсовой мы пользуемся... немножко особенной только sm.gif
klen
сборка хост x86_32 таргет ARM
http:///klen.org/Files/DevTools/x86_32-kgp-mingw/arm-kgp-eabi-x86_32-20111120.7z
собрано из релизных
binutils-2.21.1
gcc-4.6.2
gdb-7.3.1

не тестил - неначем, нет 32 битного масдая
Genadi Zawidowski
Потестил:

Сегодняшняя:

с ключём -flto:

C:\user\dds2\TC1\at91sam7s>make
arm-kgp-eabi-gcc ../crt_sam7s.o ../cp15_asm.o ../bandfilters.o ../board.o ../sequen.o ../encoder.o ../hardware.o ../hd44780.o ../dis
play.o ../keyboard.o ../keymaps.o ../nvram.o ../spifuncs.o ../formats.o ../synthcalcs.o ../uc1601s_small.o ../uc1601s_font.o ../uc16
01s_font_alt.o ../uc1601s.o ../twi.o ../tc1.o -mcpu=arm7tdmi -flto -Os -nostartfiles -T../sam7x64_rom.ld -Wl,-Map=tc1_rom.map,--cref
,--no-warn-mismatch -lm -o tc1_rom.elf
c:/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.2/../../../../arm-kgp-eabi/bin/ld.exe: cannot find -lugin
c:/kgp_arm_eabi/bin/../libexec/gcc/arm-kgp-eabi/4.6.2/liblto_plugin-0.dll: file not recognized: File format not recognized

collect2: ld returned 1 exit status
make.EXE: *** [tc1_rom.elf] Error 1

Без ключа -flto:

arm-kgp-eabi-gcc ../crt_sam7s.o ../cp15_asm.o ../bandfilters.o ../board.o ../sequen.o ../encoder.o ../hardware.o ../hd44780.o ../dis
play.o ../keyboard.o ../keymaps.o ../nvram.o ../spifuncs.o ../formats.o ../synthcalcs.o ../uc1601s_small.o ../uc1601s_font.o ../uc16
01s_font_alt.o ../uc1601s.o ../twi.o ../tc1.o -mcpu=arm7tdmi -Os -nostartfiles -T../sam7x64_rom.ld -Wl,-Map=tc1_rom.map,--cref,--no
-warn-mismatch -lm -o tc1_rom.elf
c:/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.2/../../../../arm-kgp-eabi/bin/ld.exe: cannot find -lgcc
collect2: ld returned 1 exit status

make.EXE: *** [tc1_rom.elf] Error 1


Первая сборка их тех, где появился -flto:

Без ключа -flto:

arm-kgp-eabi-gcc ../crt_sam7s.o ../cp15_asm.o ../bandfilters.o ../board.o ../sequen.o ../encoder.o ../hardware.o ../hd44780.o ../dis
play.o ../keyboard.o ../keymaps.o ../nvram.o ../spifuncs.o ../formats.o ../synthcalcs.o ../uc1601s_small.o ../uc1601s_font.o ../uc16
01s_font_alt.o ../uc1601s.o ../twi.o ../tc1.o -mcpu=arm7tdmi -Os -nostartfiles -T../sam7x64_rom.ld -Wl,-Map=tc1_rom.map,--cref,--no
-warn-mismatch -lm -o tc1_rom.elf
arm-kgp-eabi-size tc1_rom.elf
text data bss dec hex filename
36776 244 2192 39212 992c tc1_rom.elf

с ключём -flto:

arm-kgp-eabi-gcc ../crt_sam7s.o ../cp15_asm.o ../bandfilters.o ../board.o ../sequen.o ../encoder.o ../hardware.o ../hd44780.o ../dis
play.o ../keyboard.o ../keymaps.o ../nvram.o ../spifuncs.o ../formats.o ../synthcalcs.o ../uc1601s_small.o ../uc1601s_font.o ../uc16
01s_font_alt.o ../uc1601s.o ../twi.o ../tc1.o -mcpu=arm7tdmi -flto -Os -nostartfiles -T../sam7x64_rom.ld -Wl,-Map=tc1_rom.map,--cref
,--no-warn-mismatch -lm -o tc1_rom.elf
arm-kgp-eabi-size tc1_rom.elf
text data bss dec hex filename
35736 244 2184 38164 9514 tc1_rom.elf
klen
жесть какаято .....
ld.exe: cannot find -lugin это вообще откудо!!??
разберусь в чем косяки выложу.

ну теперь до кучи для avr

http://klen.org//Files/DevTools/x86_32-kgp..._32-20111121.7z
lto не включать - его тут нету.

ребята... мож всетаки перейдем на 64 битные системы, а то они както умирают со всех сторон...
ARV
Цитата(klen @ Nov 21 2011, 00:53) *
ребята... мож всетаки перейдем на 64 битные системы, а то они както умирают со всех сторон...

да мы бы с радостью, да только вот средства не позволяют.
adnega
На предыдущей версии собиралось без проблем.

C:\gcc\arm-kgp-eabi-x86_32_20111120\bin>arm-kgp-eabi-gcc.exe -mcpu=cortex-m3 -mthumb -g -O0 -c test.s -o test.o
test.s: Assembler messages:
test.s:103: Error: SVC is not permitted on this architecture

test.s:

@ 153 "c:/gcc/FreeRTOS/Source/portable/GCC/ARM_CM3/port.c" 1
ldr r0, =0xE000ED08
ldr r0, [r0]
ldr r0, [r0]
msr msp, r0
cpsie i
svc 0 <- 103 line
nop

klen
мне это все видется забавно.. а Вы говорите релизы..
такого говна повыкачивать я еще людям не предлагал!

просьба пока не пытатся скачивать архив с релизными версиями - там видимо хорошего ничего нет
до тех пор пока я на 32 битную хрюше не посмотрю как это все происходит.

но avr версию всетаки гляньте - я ее проверял - у меня простейший проект собрался.

нада сказать что собрать релизы с ходу как trunk у меня не получилось - куча косяков - в основном в конфигураиторах. приходилось руками помогать. хочу напомнить простую истину - релиз отлаженный для одной платфрмы не означает его релизность под другую. надо понимать что релизность в первую очередб относиться к кодогенератору RTL - тоесть к верхнему уровню, он собственно самое главное, а порты могут вообще в данный момент быть испорчены.

2_ARV это плохо что денег нет, у меня тоже их почемуто нет. чтото не так в консерватории - работаеш работаеш по 14 часов в сутки а их все нет и нет. sad.gif
AHTOXA
Цитата(klen @ Nov 21 2011, 12:12) *
до тех пор пока я на 32 битную хрюше не посмотрю как это все происходит.

На всякий случай напомню, что в венде 32-битные программы можно легко и непринуждённо запускать (проверять) и на 64-битной системе rolleyes.gif
klen
2_adnega
косяк с SVC в релизной версии - старый известный в ассемблере бинутилса про который уже все забыли, но вы просили релиз! как вы понимаете сборка будет как говорят патсаны 'дэцел нерелизная'

потестил. косяки устранены для arm сборки под винду, на выходных выложу. с avr сборкой как? пробовал ктонибудь?
Ash_snz
2 Klen
Все мучаем свой элдешник. Если все не так просто с мипсами. Есть пример какого-нибудь скрипта линкера чтобы можно было секции по адресам и не так некузяво как у нас (т.е. с объектными файлами)?
Если найдется буду примного благодарен.
klen
поправленая ARM сборка с релизным компиллером 4.6.2 для 32 битной винды

http://klen.org/Files/DevTools/x86_32-kgp-..._32-20111126.7z

я его протестил на XP, проекты собираются отлаживаются и работают после зашивки.
Genadi Zawidowski
lto отвалилось, но это не особо важно... Спасибо. Без него работает.

Код
arm-kgp-eabi-gcc ../crt_sam7s.o ../cp15_asm.o ../bandfilters.o ../board.o ../sequen.o ../encoder.o ../hardware.o ../hd44780.o ../dis
play.o ../keyboard.o ../keymaps.o ../nvram.o ../spifuncs.o ../formats.o ../synthcalcs.o ../uc1601s_small.o ../uc1601s_font.o ../uc16
01s_font_alt.o ../uc1601s.o ../twi.o ../tc1.o -mcpu=arm7tdmi -flto -Os -nostartfiles -T../sam7x64_rom.ld -Wl,-Map=tc1_rom.map,--cref
,--no-warn-mismatch  -lm  -o tc1_rom.elf
lto1.exe: internal compiler error: compressed stream: data error
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: arm-kgp-eabi-gcc returned 1 exit status
c:/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.2/../../../../arm-kgp-eabi/bin/ld.exe: lto-wrapper failed
collect2: ld returned 1 exit status
make.EXE: *** [tc1_rom.elf] Error 1
klen
да там в то время lto никто и гарантировал. он и щас то в вразработке.
AHTOXA
Проверил, работает.
Причём по размеру кода даже немножко уделывает arm-kgp-eabi-gcc.exe 4.7.0 20110328:
text data bss
34236 32 38344 4.7.0
34124 32 38344 4.6.2

LTO нет ни там ни там (для кортексов), для arm7tdmi в 4.7.0 LTO работает, а в 4.6.2 - компилится (работу проверить не на чем).

А, и ещё openocd следующей версии, как обычно с несовместимым форматом конфигурации... Не, конечно понятно, что при появлении stm32f2x, пришлось его обособить от stm32f1xx, но можно же было оставить stm32x как алиас stm32f1x для совместимости!
Теперь у меня под виндой и под линуксом разные версииsm.gif

ЗЫ. Спасибо, klen! beer.gif
adnega
Эхх...

test.s:493: Error: registers may not be the same -- `strexb r0,r0,[r1]'
test.s:517: Error: registers may not be the same -- `strexh r0,r0,[r1]'

test.s

Код
    .align    1
    .global    __STREXB
    .thumb
    .thumb_func
    .type    __STREXB, %function
__STREXB:
.LFB19:
    .loc 1 733 0
    .cfi_startproc
    @ args = 0, pretend = 0, frame = 0
    @ frame_needed = 0, uses_anonymous_args = 0
    @ link register save eliminated.
.LVL34:
    .loc 1 736 0
@ 736 "c:/gcc/lib/STM32F10x_StdPeriph_Lib_V3.5.0/Libraries/CMSIS/CM3/CoreSupport/core_cm3.c" 1
    strexb r0, r0, [r1]  <-- 493 line
@ 0 "" 2
.LVL35:
    .loc 1 738 0
    .thumb
    bx    lr
    .cfi_endproc
.LFE19:
    .size    __STREXB, .-__STREXB
    .align    1
    .global    __STREXH
    .thumb
    .thumb_func
    .type    __STREXH, %function
__STREXH:
.LFB20:
    .loc 1 750 0
    .cfi_startproc
    @ args = 0, pretend = 0, frame = 0
    @ frame_needed = 0, uses_anonymous_args = 0
    @ link register save eliminated.
.LVL36:
    .loc 1 753 0
@ 753 "c:/gcc/lib/STM32F10x_StdPeriph_Lib_V3.5.0/Libraries/CMSIS/CM3/CoreSupport/core_cm3.c" 1
    strexh r0, r0, [r1]  <-- 517 line


А это исходный текст
Код
/**
* @brief  STR Exclusive (8 bit)
*
* @param  value  value to store
* @param  *addr  address pointer
* @return        successful / failed
*
* Exclusive STR command for 8 bit values
*/
uint32_t __STREXB(uint8_t value, uint8_t *addr)
{
   uint32_t result=0;
  
   __ASM volatile ("strexb %0, %2, [%1]" : "=r" (result) : "r" (addr), "r" (value) );
   return(result);
}

/**
* @brief  STR Exclusive (16 bit)
*
* @param  value  value to store
* @param  *addr  address pointer
* @return        successful / failed
*
* Exclusive STR command for 16 bit values
*/
uint32_t __STREXH(uint16_t value, uint16_t *addr)
{
   uint32_t result=0;
  
   __ASM volatile ("strexh %0, %2, [%1]" : "=r" (result) : "r" (addr), "r" (value) );
   return(result);
}


A.3.8 LDREX and STREX
Load and Store Register Exclusive.
Syntax
LDREX{cond} Rt, [Rn {, #offset}]
STREX{cond} Rd, Rt, [Rn {, #offset}]
LDREXB{cond} Rt, [Rn]
STREXB{cond} Rd, Rt, [Rn]
LDREXH{cond} Rt, [Rn]
STREXH{cond} Rd, Rt, [Rn]
where
cond is an optional condition code; see “Conditional Execution” section on page 358.
Rd is the destination register for the returned status.
Rt is the register to load or store.
Rn is the register on which the memory address is based.
offset is an optional offset applied to the value in Rn. If offset is omitted, the address is the value in Rn.
Restrictions
In these instructions:
- Do not use PC.
- Do not use SP for Rd and Rt.
- For STREX, Rd must be different from both Rt and Rn.
- The value of offset must be a multiple of 4 in the range 0–1020.
klen
Цитата(adnega @ Nov 28 2011, 16:16) *
Эхх...

test.s:493: Error: registers may not be the same -- `strexb r0,r0,[r1]'
test.s:517: Error: registers may not be the same -- `strexh r0,r0,[r1]'


1. как то мимо проехал, просто закаментил CMSIS две эти функции потому как не разбирался - кто врет: асм на наличие двух одинаковых регистров, или компилятор врет при их генерации. судя по доке для strexb и strexb это не воспрещаться но и не написано что можно (я решил ничего не предпринимать по поводу этого косяка). этот тонкий момент я оставил на потом. кто точно знает как работает ядро по этому вопросу сообщите.
2. моя рабочая гипотеза - врет ассемблер, если так то его можно быстренько подправить (если не будет подводных камней).

2_AHTOXA
на мой взгляд они все правильно делают - открылись новые обстаятельства - рефаторинг проекта, а то и редизайнинг пока не позно!! а не ''рекостылинг" ка это делают большенство обезьяноподобных.... нехрен грязь размазывать во времени и пространстве - сразу жопу вытер, помыл и забыл. я бы также сделал. проблем то никаких - имя скрипта поменял и все.
AHTOXA
Цитата(klen @ Nov 28 2011, 22:57) *
на мой взгляд они все правильно делают - открылись новые обстаятельства - рефаторинг проекта, а то и редизайнинг пока не позно!! а не ''рекостылинг" ка это делают большенство обезьяноподобных....

Представляете, если бы авторы GCC вдруг решили поменять несколько ключей компилятора? Какой бы вой поднялся!
Мне кажется, в стан openocd проникли враги, и ведут там диверсионную деятельность.
Не, я вообще-то не против рефакторинга и даже редизайнинга, если это не мешает мне пользоваться продуктом. А у openocd я уж и не помню когда не было этого, там уже давно просто сплошной и непрерывный рефакторинг и редизайнинг! maniac.gif
Цитата(klen @ Nov 28 2011, 22:57) *
проблем то никаких - имя скрипта поменял и все.

У меня свой скрипт. Причём в каждом проекте свой. Так исторически сложилось. Теперь мне придётся все их править. Причём в данный момент на работе в винде у меня 0.6.0, а дома в линуксе - 0.4.0. Получается несовместимость по формату скриптов. Пока не придумал как выкручиваться...
А всего-то и надо было им - сделать старое наименование stm32x алиасом нового наименования stm32f1x. И потом хоть обрефакторились бы! laughing.gif
klen
Цитата(AHTOXA @ Nov 28 2011, 21:34) *
Представляете, если бы авторы GCC вдруг решили поменять несколько ключей компилятора? Какой бы вой поднялся!
Мне кажется, в стан openocd проникли враги, и ведут там диверсионную деятельность.
Не, я вообще-то не против рефакторинга и даже редизайнинга, если это не мешает мне пользоваться продуктом. А у openocd я уж и не помню когда не было этого, там уже давно просто сплошной и непрерывный рефакторинг и редизайнинг! maniac.gif

У меня свой скрипт. Причём в каждом проекте свой. Так исторически сложилось. Теперь мне придётся все их править. Причём в данный момент на работе в винде у меня 0.6.0, а дома в линуксе - 0.4.0. Получается несовместимость по формату скриптов. Пока не придумал как выкручиваться...
А всего-то и надо было им - сделать старое наименование stm32x алиасом нового наименования stm32f1x. И потом хоть обрефакторились бы! laughing.gif


в что мешает на линуксе 0.6,0 запустит? религяи не позволяет?
у меня исторически сложилось что скрипт один...

а это что такое я спрашиваю?
stm32.cfg:
Код
deprecated cfg file
echo "DEPRECATED! use script 'target/stm32f1x.cfg' not 'target/stm32.cfg'"
source [find target/stm32f1x.cfg]
#

stm32f2xxx.cfg:
Код
# deprecated cfg file
echo "DEPRECATED! use script 'target/stm32f2x.cfg' not 'target/stm32f2xxx.cfg'"
source [find target/stm32f2x.cfg]

klen
Цитата(klen @ Nov 28 2011, 20:57) *
1. как то мимо проехал, просто закаментил CMSIS две эти функции потому как не разбирался - кто врет: асм на наличие двух одинаковых регистров, или компилятор врет при их генерации. судя по доке для strexb и strexb это не воспрещаться но и не написано что можно (я решил ничего не предпринимать по поводу этого косяка). этот тонкий момент я оставил на потом. кто точно знает как работает ядро по этому вопросу сообщите.
2. моя рабочая гипотеза - врет ассемблер, если так то его можно быстренько подправить (если не будет подводных камней).

2_AHTOXA
на мой взгляд они все правильно делают - открылись новые обстаятельства - рефаторинг проекта, а то и редизайнинг пока не позно!! а не ''рекостылинг" ка это делают большенство обезьяноподобных.... нехрен грязь размазывать во времени и пространстве - сразу жопу вытер, помыл и забыл. я бы также сделал. проблем то никаких - имя скрипта поменял и все.




немного изменил в ассемблере проверку регистров в инструкциях strexb/strexh, теперь таких сообщений не должно быть:
/tmp/cc7ETq9C.s:508: Error: registers may not be the same -- `strexb r0,r0,[r1]'
/tmp/cc7ETq9C.s:533: Error: registers may not be the same -- `strexh r0,r0,[r1]'
теперь первый операнд не проверяется на равенство со вторым, одеако сравнивается с третьим и в случае совпадения будет сообщение об ошибке
тут нада покурить доку ARM CM3 и понять как правильно нада поступать. мгне описание кажется неоднозначным.
http://infocenter.arm.com/help/index.jsp?t...a/BABFFBJB.html
нада посовещатся

http://klen.org/Files/DevTools/x86_32-kgp-..._32-20111129.7z

сборка релизная для виды 32бит, полная копия 20111126 , за исключением binutils (троганный моими руками twak.gif )
AHTOXA
Цитата(klen @ Nov 29 2011, 02:17) *
в что мешает на линуксе 0.6,0 запустит? религяи не позволяет?

Религия-то позволяет. Просто знаний и умений в линуксе маловато. laughing.gif
Цитата(klen @ Nov 29 2011, 02:17) *
а это что такое я спрашиваю?
stm32.cfg:
Код
deprecated cfg file
echo "DEPRECATED! use script 'target/stm32f1x.cfg' not 'target/stm32.cfg'"
source [find target/stm32f1x.cfg]

Это не то. Это попытка сохранения совместимости на уровне имён конфигов. А меня волнует несовместимость по имени флеша в конфиге. То есть, строчка в моём конфиге
Код
flash bank $_FLASHNAME stm32x 0 0 0 0 $_TARGETNAME
теперь не работает, приходится её менять на
Код
flash bank $_FLASHNAME stm32f1x 0 0 0 0 $_TARGETNAME

Видимо мой способ использования openocd (со своим конфигом) не пришёл в голову разработчикам.
klen
Цитата(AHTOXA @ Nov 29 2011, 08:48) *
Религия-то позволяет. Просто знаний и умений в линуксе маловато. laughing.gif

Это не то. Это попытка сохранения совместимости на уровне имён конфигов. А меня волнует несовместимость по имени флеша в конфиге. То есть, строчка в моём конфиге
Код
flash bank $_FLASHNAME stm32x 0 0 0 0 $_TARGETNAME
теперь не работает, приходится её менять на
Код
flash bank $_FLASHNAME stm32f1x 0 0 0 0 $_TARGETNAME

Видимо мой способ использования openocd (со своим конфигом) не пришёл в голову разработчикам.


ну если все так трагично я могу помоч отцу русской демократии - докостылять версию из транка чтоб она одинаково реагировала на stm32x и stm32f1x и соответсвуеще ситуации назвать этот подарочный именной вариант openocd_0.6.0_SEFAFOTC (SPECIAL_EDITION_FOR_ANTOHA_FAN_OF_THE_COUCH)

под как какой хост нада?

вот откостыленная выерсия для linux64
http://klen.org/Files/DevTools/openocd_0.6...EFAFOTC.tar.bz2
на имя драйвера флеша stm32x реагирует также как на stm32f1x
AHTOXA
Да не, особой трагедии нет. Так, лёгкая печальsm.gif
За именную спецсборку - спасибо biggrin.gif Только тогда и под венду (можно 32) тоже sm.gif
adnega
А так пойдет?

Код
uint32_t __STREXB(uint8_t value, uint8_t *addr)
{
   uint32_t result=0;
  
  // __ASM volatile ("strexb %0, %2, [%1]" : "=r" (result) : "r" (addr), "r" (value) );
   __ASM volatile ("strexb r2, %2, [%1] \n" \
       "    mov %0, r2" : "=r" (result) : "r" (addr), "r" (value) : "r2" );
   return(result);
}


Из плюсов: не ругается и компилиться
Из минусов: правка стандартного файла и не гарантируется несовпадение регистров.
klen
Цитата(adnega @ Nov 29 2011, 12:59) *
А так пойдет?

Код
uint32_t __STREXB(uint8_t value, uint8_t *addr)
{
   uint32_t result=0;
  
  // __ASM volatile ("strexb %0, %2, [%1]" : "=r" (result) : "r" (addr), "r" (value) );
   __ASM volatile ("strexb r2, %2, [%1] \n" \
       "    mov %0, r2" : "=r" (result) : "r" (addr), "r" (value) : "r2" );
   return(result);
}


Из плюсов: не ругается и компилиться
Из минусов: правка стандартного файла и не гарантируется несовпадение регистров.


зачем извращатся лишней инструкцийе, попробуйте потестить оновленую сборку (-2 поста вверх), все соберется из стндартных исходников
adnega
Цитата(klen @ Nov 29 2011, 13:24) *
зачем извращатся лишней инструкцийе, попробуйте потестить оновленую сборку (-2 поста вверх), все соберется из стндартных исходников


Собирается.
Но про равенство регистров нужно помнить...
klen
Цитата(adnega @ Nov 29 2011, 14:50) *
Собирается.
Но про равенство регистров нужно помнить...

компилятор пусть помнит - у него голова кбольшая, как у лошади, а я луше знать буду, когда нада он мне напомнит.
adnega
Появилась доска STM32F4DISCOVERY.

Собрал из исходников демку для -mcpu=cortex-m4: без оптимизации работает, с оптимизацией - пока нет)
Демка сурьезная: играет WAV-файл с флешки.

P.S.: Не работает только с -Os, на -O1 и -O2 работает)
P.S.2: Работает на всех уровнях оптимизации!
Genadi Zawidowski
Цитата(adnega @ Dec 2 2011, 13:46) *
Появилась доска STM32F4DISCOVERY.

Собрал из исходников демку для -mcpu=cortex-m4: без оптимизации работает, с оптимизацией - пока нет)
Демка сурьезная: играет WAV-файл с флешки.

P.S.: Не работает только с -Os, на -O1 и -O2 работает)
P.S.2: Работает на всех уровнях оптимизации!

Попробуйте то же самое на yagarto - есть подозрение, что проблема в "демке", а не в компиляторе.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2014 Invision Power Services, Inc.