[Log_in 0]

Всем доброго дня. Разбираюсь с Cyclone V SoC Development Kit, а точнее с ARM-овской составляющей.Через дебаг DS-5 запустил проект с HelloWorld. И тут возникает масса вопросов:

1. можно ли прошивать через Run, а не дебаг,

2. как подключаются библиотеки. Нужные файлы нашел в altera\13.1\embedded\ip\altera\hps\altera_hps\hwlib. Отправили их в папу DS-5/include, командой #include .h файлы подключаются, но функции из одноименных .с файлов - ни в какаю, даже если их подключить в ручную. При этом компилятор начинает придираться к ";", брейкам в циклам и прочим вещам. Я начал грешить на компилятор и пытаться настроить его, но лучше опять не стало.

До этого знаком был с АRM через Stm и Keil,(+немного кокоса), а тут такая борода! Подскажите советом, или быть может развернутым примером. Осознаю свое незнание в этом вопросе и готов учиться.

[warrior-2001 0]

... а тут такая борода! Подскажите советом, или быть может развернутым примером. Осознаю свое незнание в этом вопросе и готов учиться.

 

Боюсь что совет дан постом выше. Совместно с программистом в фоновом режиме уже месяц мучаю кит, саппорт, да и сам мучаюсь, но дальше модификации готовых примеров так и не смог продвинуться. Так же интересует в первую очередь bare metal и так же хотелось бы для начала освоить работу с ARM с минимальной поддержкой FPGA части или вообще без неё.

 

Всю FPGA часть проверил - там всё ок. Однако корректно провести инициализацию всей обвязки HPS без участия FPGA настолько тяжело, что проще уж перейти к решению создания некоего простого проекта для FPGA, чтобы просто инициализацию HPS производил и запускал его. А уж потом функции пользовательские выполнять. Как-то так.

 

 

[StewartLittle 41]

Так же интересует в первую очередь bare metal и так же хотелось бы для начала освоить работу с ARM с минимальной поддержкой FPGA части или вообще без неё.

Уф, вроде удалось победить bare metal, причем c использованием штатного прелоадера :) - армовское приложение само загружает конфигурацию в FPGA, потом FPGA'шной частью проекта же и управляет. Сейчас приложение грузится по JTAG'у и дебажится со всеми положенными фичами.

Но я пока на смог решить задачу преобразования кода приложения в формат, необходимый для записи в QSPI (причем прелоадер в QSPI записать удалось).

За праздники постараюсь привести мысли в порядок и немного "причесать" проект :)

[gosu-art 0]

 

Было бы интересно посмотреть на "прическу" :rolleyes:

[WitFed 1]

2 Log_in :

Я вот тоже как рыба об лёд которую неделю, но понял, что в стандартной поставке EDS как минимум 3 разных компилятора (это зовётся toolchain, цепочка с make, ассемблером, линкером, архивером и мало ли чем ещё необходимым), хотя сама Студия DS-5 выбрать позволяет штук 20, в том числе для Mac-ов, но потом ругается на незапуск.

В ds-5/bin пара: arm-linux-gnueabi-* и armcc (который бывший Keil, возможно, и требует спец-лицензирования), и в host_tools/mentor/gnu/arm/baremetal/bin -- arm-none-eabi от Менторов.

Эти все ребята конкурирующих организаций и несовместимы друг с другом по бинарникам и даже по исходникам (возможно, диалект С можно и подстроить типа на -99). Кто-то может компилить под baremetal, кто-то -- под Линукс, вроде бы есть совместимость слева направо, но не наоборот.

Либы для каждого компилятора свои и вряд ли удастся слинковать что-то с чужими, даже если и поюзать успешно тамошний h-ник. У меня так абсолютно не находились open(), write(), lseek(),.. etc. Скрипты линкера с размапом памятей тоже несовместимы. Но если пускаешь конкретный toolchain, "всё своё" он находит сам.

Используемый в конкретном примере toolchain можно выявить, заглянув в его Makefile -- там обычно находится нечто типа:

CROSS_COMPILE := arm-none-eabi

CC := $(CROSS_COMPILE)gcc

LD := $(CROSS_COMPILE)ld

...

Хорошо бы, если б кто-то самый продвинутый своим телекино-прошарингом в этой пока что куче мусора изложил на 2-3 страничках со ссылками суть всех процессов от замысла до получения работающего по включению питания "голого" результата более-менее приличного размера, ибо Альтерное и пр. контрагентов (7 нянек практически) больно недружелюбное и отсылочное. "Видъ сверъху" никак не находится в массе М и даже Г ;)

У меня лично при добавлении к HelloWorld большого контента он просто падает в непредсказуемых местах (в необработанный и неопознанный exception по адресу FFFF0000, видимо), особенно на Release, даже не доходя до main(). На Debug всё получше, но чтение хостового файла порцией более 3 байт или выход из функции при отладке по F7 вместо F5 приводят в тот же адрес.

Ещё из мелочи -- при хождении отладчиком Студии даже на Debug половина переменных Undefined в окошке Variables, ну и в Expressions, а мыша над переменной не демонстрирует её значения никогда, к чему я давно привык в современном софте.

Виндовые привычки уходить не хотят, хочется удобств не во дворе, makefile-сы писать не обучен, а вроде пока только один armcc это тянет своим интеллектом для DS-5 :(

Бывает в мире хоть одна Студия, чтобы из makefile могла импортировать всю тамошнюю начинку при переходе в режим "Generate Makefiles automatically" до последнего чекбокса, а при выходе из него -- засунула обратно ? ;)

Изменено 30 апреля, 2014 пользователем WitFed

[gosu-art 0]

А кто нибудь вообще использует Альтеровский SoC в реальных проектах? На Zynq'e уже видел в интернете железяки, а вот на C5(А5) SOC - нет. :laughing:

[winipuh 0]

А кто нибудь вообще использует Альтеровский SoC в реальных проектах? На Zynq'e уже видел в интернете железяки, а вот на C5(А5) SOC - нет. :laughing:

Регулярно смотрю Avnet, Digikey, Arrow и проч.

ZYNQ на складах есть. И цена на них уже упала до 50-60$ (год назад на самые младшие кристаллы в превью было от 150-200).

А вот SoC V там нет! Есть позиция. Цены с хилыми синхронизируют. Но 'Quote' везде по нулям...

 

[WitFed 1]

Наша фирма, допустим, без Альтеры никуда -- её спинномозговые решения сильно подходят к нашему IQ, для затяжки разработок и отмывки на 2 порядка больших ресурсов с кормлением потенциальных противников ;)

Только если Обамные вялотекущие процессы на Украине обострятся донельзя, придётся искать китайские аналоги ;)

По идее, всё сильно упростится, если вместо многоплатных и многолитровых жутко долго отлаживаемых без отладчика девайсов можно будет поставить заказчикам спичечный коробок с непомерным функционалом, ну типа ЯФонов современных, хотя тогда требовать кучу денег будет трудней -- нашим ЛПР-людям в отличие почему-то от ненаших обычно важен РАЗМЕР РЕЗУЛЬТАТА! ;)

На www.rocketboards.org у авторов платы довольно много приличных описаний, ну и в ug_soc_eds.pdf, я после N-ного прочтения по кругу неродной мовы в сбойное ОЗУ начал что-то как-то уже соображать, надо пытаться обобщить. С Nios IDE было гораздо яснее с самого начала, хотя флэшь она зашивать тоже не умеет сама.

Все проблемы из-за нехватки ПЗУ/ОЗУ в ARM-процессоре, иначе весь этот многостадийный порядок можно было б сильно упростить. Кто-то где-то видел, можно ли юзерам трогать ROM в Альтерной версии ARM-ядер ? Исходники BootROM есть ? Я абсолютно не встретил пока что.

Постулируемый аксиомно порядок загрузки 1.BootROM .. 2.Preloader .. 3.U-Boot .. 4.Linux (или намёками BareMetal вместо 3-4) вполне может быть сокращён в конкретном случае до 1.BootROM .. 2.BareMetal, если найти у ARM исходники самого BootROM, вырезать оттуда избыточно универсальную функциональность и добавить инициализацию SDRAM, куда он уме сразу и загрузит наше рабочее приложение.

Стартовать можно будет за полсекунды, в пику всем современным ОСям, которые и не люблю за тормоза и абсолютно необоснованную раздутость. Красиво жить не запретишь, и раз уж "Altera Edition Toolkit", можно было б потроха все спрятать за GUI, как в QSys, их не так и много!

Чем больше сущностей в ПО (и чужих исходников, родных для совершенно иного типа мозга и распознаваемых достаточно долго до состояния доверия), тем больше слабопроверенных связей между ними и ниже надёжность, сертифицируемость и антизакладочность, несмотря на издревле постулируемое повторное использование наработок, вроде бы полезное, но ввиду гигантизма объёмов готового кода не очень вмещающееся в

следующие поколения разработчиков.

Плохо, что Альтера, ARM или rocketboards не предоставляют сразу в IDE 1-кнопочного механизма прошивки своего свежескомпиленного ELF-файла во флэшь, предварительно заданную в опциях, своим же зашивателем, без мататы с кучей софта, его доками, джамперами, консолями!.. Чтоб нажал, подождал 100%, питание передёрнул -- и лампочки замигали в нужной зависимости!

Все настройки, откуда чего брать всему семейству лоадеров, вполне могут быть записаны в той же флэши BootROM. Ну просто более-менее дружественная идеология Винды (за бабки) ещё не проникла в Линду (за просто так) и заставляет ковыряться под капотом вместо автосервиса ;)

Почему все "железные" джамперы и свитчи не выведены в софт и не скрыты его "внешним управлением" с записью в энергонезависимом ОЗУ, неясно. Там можно было бы выбирать конфигурации из заранее готовых с подсказками, а не бегать слепыми глазами по 50 мелким точкам, ну и кнопочки жать в IDE, лампочки там же наблюдать... хотя это уже перебор фантазии ;)

А то вот никак не пойму, для BOOTSEL* единицу задаёт "1-2 Shorted" или "2-3 Shorted" ? Чтобы было с чем ковыряться в дальнейших табличках загрузки HPS ;)

 

Теперь к живым баранам! Скачал cv_soc_devkit_ghrd.tar.gz из http://releases.rocketboards.org/release/2013.11/gsrd/ghrd, сделал с ним всё, что написано в http://www.rocketboards.org/foswiki/Docume...n/GSRDPreloader, только настроил загрузку из QSPI в bsp-editor, убрал из SD.

Пока компилилось, навыдавало подозрений своих типа:

make[1]: Предупреждение: Время изменения файла `/cygdrive/t/wit/ds-5/gsrd/cv_soc_devkit_ghrd/software/spl_bsp/uboot-socfpga/include/config.mk' находится в будущем (22)
make[3]: Предупреждение: Время изменения файла `/cygdrive/t/wit/ds-5/gsrd/cv_soc_devkit_ghrd/software/spl_bsp/uboot-socfpga/spl/arch/arm/cpu/armv7/.depend' находится в будущем (22)
make[2]: Предупреждение: Время изменения файла `.depend' находится в будущем (22)
make[2]: Цель `_depend' не требует выполнения команд.
make[2]: предупреждение: Неправильный ход часов.  Сборка может быть неполной.

Не знаю, насколько это смертельно, при первом разе же не должно быть опасно, целей же вообще не существовало ?

Это у меня в шару T: на другом компе всё настроено, там время чуть другое, что-то в королевстве Датско-Линдовом не учитывается.

 

Полученный T:\Wit\DS-5\gsrd\cv_soc_devkit_ghrd\software\spl_bsp\preloader-mkpimage.bin записал на QSPI командой:

User@U /cygdrive/t/wit/ds-5/gsrd/cv_soc_devkit_ghrd/software/spl_bsp
$ quartus_hps -c 1 -o PV -a 0 preloader-mkpimage.bin
Info: *******************************************************************
Info: Running Quartus II 32-bit Programmer
    Info: Version 13.1.4 Build 182 03/12/2014 SJ Full Version
    ...
Info: Command: quartus_hps -c 1 -o PV -a 0 preloader-mkpimage.bin
Current hardware is: USB-BlasterII [USB-1]
Found HPS at device 1
HPS Device IDCODE: 0x4BA00477
AHB Port is located at port 0
APB Port is located at port 1
Boot Info: 1.8V QSPI Flash
Start HPS Quad SPI flash programming ...
Initialize QSPI peripheral and flash controller ...
Read Silicon ID of Quad SPI flash ...
   Quad SPI Flash silicon ID is 0x1020BA20
      Flash device matched
         Manufacturer: Micron
         Device: QSPI_512
Enable Four Byte Addressing ...
Sector Erase Quad SPI flash ...
   Sector Erase Info: Start Addr at 0x00000000 for 4 sector(s)
      Sector Erase Quad SPI flash at 0x00000000
      Sector Erase Quad SPI flash at 0x00010000
      Sector Erase Quad SPI flash at 0x00020000
      Sector Erase Quad SPI flash at 0x00030000
Program Quad SPI flash ...
Verify Quad SPI flash ...
Info: Quartus II 32-bit Programmer was successful. 0 errors, 0 warnings
    Info: Peak virtual memory: 64 megabytes
    Info: Processing ended: Thu May 08 08:19:43 2014
    Info: Elapsed time: 00:01:23
    Info: Total CPU time (on all processors): 00:00:16

из-под оболочки, потом приложение Altera-SoCFPGA-HardwareLib-FPGA-CV-ARMCC из примеров, которое нормально моргает диодиками, обработал командами по намёкам Альтеры:

objcopy --gap-fill=0xff -O binary hwlib.axf hwlib.bin
mkimage -A arm -O u-boot -T standalone -C none -a 0x02000000 -e 0 -n "baremetal image" -d hwlib.bin hwlib.img

и зашил:

User@U /cygdrive/t/wit/ds-5/gsrd/cv_soc_devkit_ghrd/software/spl_bsp
$ quartus_hps -c 1 -o PV -a 0x60000 hwlib.img.bin
Info: *******************************************************************
Info: Running Quartus II 32-bit Programmer
    Info: Version 13.1.4 Build 182 03/12/2014 SJ Full Version
    ...
Info: Command: quartus_hps -c 1 -o PV -a 0x60000 hwlib.img.bin
Current hardware is: USB-BlasterII [USB-1]
Found HPS at device 1
HPS Device IDCODE: 0x4BA00477
AHB Port is located at port 0
APB Port is located at port 1
Boot Info: 1.8V QSPI Flash
Start HPS Quad SPI flash programming ...
Initialize QSPI peripheral and flash controller ...
Read Silicon ID of Quad SPI flash ...
   Quad SPI Flash silicon ID is 0x1020BA20
      Flash device matched
         Manufacturer: Micron
         Device: QSPI_512
Enable Four Byte Addressing ...
Sector Erase Quad SPI flash ...
   Sector Erase Info: Start Addr at 0x00060000 for 7 sector(s)
      Sector Erase Quad SPI flash at 0x00060000
      Sector Erase Quad SPI flash at 0x00070000
      Sector Erase Quad SPI flash at 0x00080000
      Sector Erase Quad SPI flash at 0x00090000
      Sector Erase Quad SPI flash at 0x000A0000
      Sector Erase Quad SPI flash at 0x000B0000
      Sector Erase Quad SPI flash at 0x000C0000
Program Quad SPI flash ...
Verify Quad SPI flash ...
Info: Quartus II 32-bit Programmer was successful. 0 errors, 0 warnings
    Info: Peak virtual memory: 60 megabytes
    Info: Processing ended: Thu May 08 08:22:48 2014
    Info: Elapsed time: 00:02:11
    Info: Total CPU time (on all processors): 00:00:25

Вообще, странно долгим выглядит процесс записи/верификации флэши прогой quartus_hps через JTAG. У меня хост через него выдавал почти 100 К/с из семихостингового файла, писал тоже примерно так же, так что видимая проблема порядка менее 3 К/с явно не в подключении.

Да, Jumper Setting сделал на QSPI, как приказано: J28 right shorted, J29 left shorted, J30 left shorted, дёрнув питание перед этим и после.

Дёрнул опять питание -- голяк, не моргнуло ни разу, в RS-консоль вылезло только:

U-Boot SPL 2013.01.01 (May 08 2014 - 11:00:52)
BOARD : Altera SOCFPGA Cyclone V Board
SDRAM: Initializing MMR registers
SDRAM: Calibrating PHY
SEQ.C: Preparing to start memory calibration
SEQ.C: CALIBRATION PASSED
SDRAM: ECC Enabled
SF: Read data capture delay calibrated to 3 (0 - 7)
SF: Detected N25Q512 with page size 65536, total: 67108864
Info: SDRAM ECC SBE @ 0x0040d240
Error: SDRAM ECC DBE occurred
sbecount = 1
erraddr = 0040d240
dropcount = 00000000
dropaddr = 00000000
### ERROR ### Please RESET the board ###

Начал отлаживать свой T:\Wit\DS-5\gsrd\cv_soc_devkit_ghrd\software\spl_bsp\uboot-socfpga\spl\u-boot-spl -- падает memset() SDRAM-а в финальной функции jump_to_image_no_args().

Убрал ему ECC в прелоадере, пересобрал -- память перестала глючить явно, и неявно вроде бы тоже, но моргания нет и вывод в консоль таков:

U-Boot SPL 2013.01.01 (May 08 2014 - 14:28:36)
BOARD : Altera SOCFPGA Cyclone V Board
SDRAM: Initializing MMR registers
SDRAM: Calibrating PHY
SEQ.C: Preparing to start memory calibration
SEQ.C: CALIBRATION PASSED
SF: Read data capture delay calibrated to 3 (0 - 7)
SF: Detected N25Q512 with page size 65536, total: 67108864

Начал отлаживать загруженное во флэшь приложение, ибо нашёл хорошую команду загрузки символьной информации в окошке Command:

file T:\Wit\DS-5\Altera-SoCFPGA-HardwareLib-FPGA-CV-ARMCC\hwlib.axf

По-любому, проект Altera-SoCFPGA-HardwareLib-FPGA-CV-ARMCC падает в функции _initio, а Altera-SoCFPGA-HardwareLib-FPGA-CV-GNU -- очень близко от начала на asm-команде SVC.

Пробанул напоследок поставочного древнего прелоадера из C:\altera\13.1\embedded\examples\hardware\cv_soc_devkit_ghrd\ и его потом подкаталога software/spl_bsp -- после вывода в RS-консоль первого прелоадера после некоторой задержки лезет второй из SD-карточки, хотя я его не разрешал абсолютно!

Короче, Склифосовский, ёжик в тумане прямо, а не я ! ;)

Стю, ты где ж там причесанный празднуешь ?!! ;)

 

Ещё процентов 80 Альтерцам надо дописать всего в описания, чтобы мы-юзеры не мучились неделями с этой "дружественной" системой ! ;)

Глюков ещё прямых много при наших детсадовских шатаниях, всё виснет часто, надо обязательно дёргать питание киту и перегружать DS-5, а при зависании DS-5 и снятии её из списка задач остаётся пущенным приложение, которые не даёт работать ей при повторном пуске или quartus_hps.

[WitFed 1]

Да, при старте моргающего диодиками приложения из-под отладчика с положениями джамперов на загрузку из QSPI оно тоже не хочет пускаться!

Вот что вычитал как альтернативу в cv_5400A.pdf, если с джамперами на SD работает как-то приложение:

The SD/MMC controller supports two booting modes:
• MBR (partition) mode
• The boot image is read from a custom partition (0xA2)
• The first image is located at the beginning of the partition, at offset 0x0
• Start address = partition start address
• Raw mode
• If the MBR signature is not found, SD/MMC driver assumes it is in raw mode.
• The boot image data is read directly from sectors in the user area and is located at the first sector of the SD/MMC.
• The first image is located at the start of the memory card, at offset 0
• Start address = 0

Немного коряво изложено, 2 альтернативы в 9 пунктах, но в целом понятно -- если есть в конце 0го сектора SD сигнатура 55AA, то на 2й стадии загрузки ищутся перед ней 4 заголовка разделов по 16 байт, в т.ч. главный с типом А2, иначе прелоадер считается лежащим 4 раза с начала SD по 64 К. Скомпилил прелоадера в этом направлении, хочу зашить:

User@U /cygdrive/t/wit/ds-5/gsrd/cv_soc_devkit_ghrd
$ quartus_hps -c 1 -o PV -a 0 preloader-mkpimage.bin
Info: *******************************************************************
Info: Running Quartus II 32-bit Programmer
    Info: Version 13.1.4 Build 182 03/12/2014 SJ Full Version
    ...
Info: Command: quartus_hps -c 1 -o PV -a 0 preloader-mkpimage.bin
Current hardware is: USB-BlasterII [USB-1]
Found HPS at device 1
HPS Device IDCODE: 0x4BA00477
AHB Port is located at port 0
APB Port is located at port 1
Error: BSEL (5) is neither from NAND nor QSPI, set the correct BSEL and powercycle your board
Error: Quartus II 32-bit Programmer was unsuccessful. 0 errors, 0 warnings
    Error: Peak virtual memory: 66 megabytes
    Error: Processing ended: Mon May 12 12:12:38 2014
    Error: Elapsed time: 00:00:06
    Error: Total CPU time (on all processors): 00:00:00

:( Если бы зашило что с 0, что в А2-партицию, можно было бы двигать дальше, а так и не знаю, чем ещё можно зашивать эту SD.

Похоже, за оставшиеся до Релиза-14.0 месяц-2 Альтерцам ещё пахать и пахать ради нашего и в конечном счёте своего щастья... ;)

 

Тут есть (в принципе) удобная засвеченная в текстах FAT-альтернатива -- как-то (не нашёл пока, как) зашить прелоадер (особо скомпиленный через макросы в "uboot-socfpga/include/configs/socfpga_common.h" "CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION 1" и "CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME "u-boot.img" ") в партицию типа А2, а само BM-приложение u-boot.img кидать уже из Винды в соседний большой произвольный раздел, вставив карточку через переходник (стр. 8-14 в ug_soc_eds.pdf, "Loading Next Image from FAT Partition on SD Card"). Но как-то не срастается длинная цепочка, хотя бы в принципе, и даже не понятно, где и как искать в ней ошибку или пути сращивания.

 

Кстати, в ug_soc_eds.pdf есть описки для "Getting Started with Bare Metal Debugging" в районе "Table 5-1: Project Files", там для разархивирования примера упоминается Altera-SoCFPGA-HelloWorld-Linux-GNU.tar.gz, который совсем не бывает BM. Скорей, по смыслу подойдёт Altera-SoCFPGA-HelloWorld-Baremetal-GNU.tar.gz, плюс имя скрипта в таблице debug-hosted.ds надо читать как semihost_setup.ds ;)

 

Возможно, я где-то и глючу, но совсем не первый. Сусанин уже тут порылся среди сырости и замутил болото... ;)

 

А Линукс не хочется трогать в принципе. За 10 лет эпизодических контактов с ним в основном нехороший осадок.

Конечно, всё можно реализовать руками, но очень не хочется ворошить маны, посему пусть останется для яйцеголовых ;)

Но принципиально кто-то поднял этот многосекундный путь и своё приложение сверху из флэши ?

Изменено 12 мая, 2014 пользователем WitFed

[WitFed 1]

Знающие люди говорят, что эта бодяга ещё долго будет тянуться.

Xilinx, допустим, в своей плате с год пудрили мозги до вменяемого состояния поднятия всех заявленных возможностей.

Я на форуме Альтеры аналогично просил настоящих и живительных подробностей зашивания BareMetal во флэшь, так там парень некий намекнул, что где-то 0 надо на 0х02000000 поменять по сравнению с доками, и всё срастётся, но у меня никак, и потом мои опровержительно-вопросительные посты просто больше не лезут в эту ветку ! Демократия в процессе ;)

[Log_in 0]

А кто-нибудь писал под ARM Cyclone-а? Сейчас пробую разобраться в их библиотеках, но тону в их десятках тысяч строк кода! Да и сам этот код не всегда компилируется, особенно ассемблерные вставки.

static void alt_int_fixup_irq_stack(uint32_t stack_irq)
{
   // 1. Save the current SP
   // 2. Switch to the IRQ context
   // 3. Point SP to the stack IRQ block provided
   // 4. Switch back to SYS context
   // 5. Restore the saved "current" SP

   // Mode_USR     0x10
   // Mode_FIQ     0x11
   // Mode_IRQ     0x12
   // Mode_SVC     0x13
   // Mode_MON     0x16
   // Mode_ABT     0x17
   // Mode_UNDEF   0x1B
   // Mode_SYS     0x1F

   // I_Bit        0x80  @ when I bit is set, IRQ is disabled
   // F_Bit        0x40  @ when F bit is set, FIQ is disabled
   // NS_BIT       0x1   @ when NS bit is set, core in non-secure

   // r4 being used for stack_sys.
   // Consider adding "lr" to the list of mangled registers. This way GCC will push/pop {lr} for us.
   __asm(
       "push {lr}\n"
       "mov r4, sp\n"
//        "msr CPSR_c, #(0x12 | 0x80 | 0x40)\n"    //msr -  пересылка из РОН в РСН (стр.82
       "mov sp, %0\n"
//        "msr CPSR_c, #(0x1F | 0x80 | 0x40)\n" //без комментариев этих двух пересылок код не компилируется
       "mov sp, r4\n"
       "pop {lr}\n"

       : : "r" (stack_irq) : "sp", "r4"
       );
}

 

Ошибка выскакивает следующая: Description Resource Path Location Type Thumb encoding does not support an immediate here -- `msr CPSR_c,#(0x1F|0x80|0x40)' main_all_lib ;line 55, external location: :\Users\User\AppData\Local\Temp\ccQyZQWf.s C/C++ Problem

 

Находил упоминание, эту процедуру можно выполнить через обработчик событий svc, но как его правильно организовать пока тоже не знаю. Может кто сталкивался с чем-то подобным? Среда:DS-5, выбран компиляторDS-5 GCC

[WitFed 1]

Я тоже прыгаю вокруг да около уже который месяц, но глобально "видъ сверъху" никакой ;)

Прерывания не уважаю, поллинг всех входов в 1-нитевом приложении проще на порядок.

В конкретном случае видно, что Thumb-расширение почему-то недоступно. У компилятора ARMCC это находится в Опциях сразу, а GCC-шный компилятор любит makefile, и там надо править вручную, если только знать как.

Ключи вызова компилятора хорошо бы в студию вложением, весь лог из его консоли, а лучше б и весь проект архивом ! Он не очень большой же пока ? Тогда любой желающий скачает, импортирует, попрыгает быстренько, поправит в меру сил и выложит обратно с комментами.

Вообще, надо создавать спец-ветку про работу в DS-5, эта же имеет совсем частное имя, ну или переименовать как-то.

Изменено 28 мая, 2014 пользователем WitFed

[Log_in 0]

Вот здесь описана похожая ситуация и озвученный мной способ решения http://stackoverflow.com/questions/2065302...x13-doesnt-work, осталось понять способ организации обработчика. На счет makefile, действительно, когда пользовался ARMCC он создавался, правда другие проблемы вылезали, а этот не создает. .afx -файл генерирует, а make - нет. Это что, мне его в ручную создавать? И как тогда? Блин, эта борода с альтерой, имеет умопомрачительные размеры и крайне надуманную структуру, а еще говорят что у STM раздутая библиотека! И с отдельной веткой идея хорошая, вот только самим создать новую или подождать когда модератор перенесет сообщения в отдельную.

Залил на ifolder проект, может кто сможет мозги ему вправить) http://rusfolder.com/40850112

Изменено 30 мая, 2014 пользователем Log_in

[WitFed 1]

Надо бы и readme чтоб лежало на обозрение, ибо жуткий когнитивный диссонанс между главным файлом и остальной требухой ! Что вообще требуется от проекта ?

Все Baremetal примеры от Альтеры для тучи разных плат сделаны через ARMCC, мож это ловушка, но вряд ли настолько явная ! ;)

И второй компилятор для Baremetal -- arm-none-eabi-*, а в выложенном файле пускается arm-linux-gnueabi-gcc, он не может делать Baremetal, с моей точки зрения, именно из-за слова linux в названии, а слово "none" как раз говорит о bare. Вдруг у кого другие мнения -- пишите.

Не пойму, зачем в выложенном примере столько М файлов! Сплошной мусор, ИМХО!

Один hello.c спокойно собирается под armcc, находятся все h-ники, объёмы бровзингов и возможных траблов с компиляцией снижаются резко, только ещё нужно добавить scatter.scat (см. первое вложение: main_all_lib_.zip).

Что конкретно было плохо под armcc ?

Если плохо компилится встроенный ассемблер, это признак пути не туда, его можно вынести в отдельный файл, образцов нам дадено достаточно.

Я создал паралельно ветку специальную Работа с Altera SoC kit, в SoC EDS, DS-5 Altera Edition для нашей борды, там кидал ссылки, в том числе имя архива, который сразу находится и позволяет (будучи инсталлированным в Эклипс) не делать makefile руками, а красиво ГУИть все опции. Правда, clean он делает как-то не так.

И там есть ссылка на русский форум, где пацан собирал хорошее об ARM-ах, ещё лет 5 назад Baidu какой-то расписывал простенькие ARM-программки, в т.ч. и с прерываниями на asm для МК.

Вот тот же проект через arm-none-eabi-*, но пускаться на плате, правда, я не пробовал на плате обоих: main_all_lib__.zip.

Собирает себе makefile сам через вышеупомянутый плагин. Был порождён как DS-5 GCC в "C/C++ Build" / "Tool Chain Editor", а потом в "C/C++ Build" / "Settings" поменяны имена утилит с цепочки arm-linux-gnueabi- на arm-none-eabi-.

Почему-то саму цепочку arm-none-eabi- явно выбрать не удаётся в опциях. И плюс добавлен ключик линкера "-Taltera-socfpga-hosted.ld" с распайкой памяти -- его формат радикально отличается от scatter.scat, испольуемом armcc.

О прерываниях я уже писал, что очень стараюсь их избежать до последнего, ибо поллинг на 2 порядка легче, и если бы современные мобы обходились без Линуксов, которые им обеспечивают "ментально красивые" (но трансректальные, ИМХО) прослойки к железу с его тучами избыточных фич, тормозили бы на порядок меньше и грузились бы за полсекунды... ;)

В принципе, можно взять готовый работающий makefile-проект и обтачивать его понемногу убиранием/добавлением файлов сырцов через +=, каталогов инклюдов через то же +=, а остальные правила там не трогать или лишние отрезать типа .rbf, результат будет неплохой.

[Log_in 0]

Назначение проекта: подключить все библиотеки с целью предварительно проверки на работоспособность(с компилируются ли для начала) и зажечь на плате HPS -ые светодиоды подав на них логический ноль. И использованием ARMCC выходила проблема, что при выборе Gnu Make Builder, эклипс выдавал ошибку с сакральным обозначением Error 1, а точнее :make: *** [hello.o] Error 1. Кстати, эта же ошибка выдается при попытки скомпилировать Ваш первый по счету проект. Возможно это от того, что не удалось поставить указанные плагины. При выборе любого из шести( полное название модуля при его установке высвечивается как "GNU ARM C/C++ Cross Development Tools " пишу для проверки, правильности скаченного файла, что бы не было разговора о разных вещах) выдается сообщение:

Cannot complete the install because one or more required items could not be found.

Software being installed: GNU ARM C/C++ Cross Compiler Support 1.9.2.201404240550 (ilg.gnuarmeclipse.managedbuild.cross.feature.group 1.9.2.201404240550)

или в место GNU ARM C/C++ Cross Compiler Support название любого другого модуля из 6.

 

Во время компиляции второго проекта в консоль выводится следующее

**** Rebuild of configuration Default for project main_all_lib__ ****

 

**** Internal Builder is used for build ****

arm-none-eabi-gcc -IC:\altera\13.1\embedded\ip\altera\hps\altera_hps\hwlib\include -O2 -g -Wall -c -fmessage-length=0 -o hello.o ..\hello.c

arm-none-eabi-gcc -o main_all_lib__.axf hello.o

Build error occurred, build is stopped

Time consumed: 1660 ms.

В общем и тут засада, afx файл не создается. Либо из-за отсутствия плагинов, либо руки не из плеч)