Форум разработчиков электроники ELECTRONIX.ru

Помощь - Поиск - Пользователи - Календарь

Полная версия этой страницы: проблема с Bootloaderом

Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Системы на ПЛИС - System on a Programmable Chip (SoPC)

Serg`

Dec 4 2008, 20:27

Доброе время суток!!

У меня есть SSRAM и FLASH они имеет общие шины адреса A[0:18] и данных для SSRAM - AD[0:32] и для FLASH - AD[0:8]. Работаю я в ЕДК9.2. Использую ЕМЦ где 1-ым банком идет SSRAM вторым FLASH это в кратце.

Я хотел бы использовать FLASH для загрузки плис (так как использую оперативную память SSRAM и нужно самому писать bootloader для загрузки из Platform_Flash, а т.к. у меня стоит параллельная Platform_Flash XCF32p а примера bootloderа для нее я е нашел, только для последовательной, то проще грузиться из FLASH т.к. в таком случае хилинкс сам генерит bootloadеr).

Так вот проблема в следующем, если для своего проэкта (например

Код

print("ALL_OK\r\n");

) в качестве оперативной пямяти я выбираю брам(в линкер скрипте), затем шью FLASH как по инструкции, то все в ожуре, тоесть нормально работает. От сюда я делаю вывод, что FLASH в норме!

Если же если для того же проэкта в качестве оперативной пямяти я выбираю SSRAM(в линкер скрипте), то дойдя до 8 строчки bootloderа выдаеться ошибка о неправильном формате данных во FLASH (он должен быть SREC) и на этом конец!!

Еще добавлю что SSRAM по мнению хилинкса рабочая так как тесты ее 32-,16- и 8-разрядный по итогам автосгенеренного хилинксом проекта TESTAPPMEM успешны (PASSED) и под отладчиком в SDK при использовании срам в качестве оперативки (прописываю в линкер скрипте) все работает!!

Так в чем может быто проблема??? Я грешу на общие шины!!Хотя это уже давно проверенная практика и обе микросхеммы разделены CSами, но тогда что может быть ведь раздельно они работают!!??

Есть еще один выход написать bootloader для параллельнной Platform_Flash XCF32p но я даже не знаю с чего начать посмотрел на хилинксе нашел ХАПП482 для последовательной, мб попробую его покорячить!!С такой задачей ни кто не сталкивася??Поделитесь опытом и если можно сорцами или примерами!!

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

Serg`

Dec 5 2008, 08:18

И еще нашел такую штуку от немцев называеться ю бут ни кто не пользовался???

http://www.denx.de/wiki/PPCEmbedded/WebHome

http://www.denx.de/wiki/U-Boot/WebHome

http://www.denx.de/wiki/DULG/Manual

Serg`

Dec 8 2008, 16:47

Не ужели ни у кого не было похожей проблемы ну хотя бы с праллельной ПРОМ???

id_gene

Dec 9 2008, 07:47

Цитата(Serg` @ Dec 4 2008, 23:27)

Если же если для того же проэкта в качестве оперативной пямяти я выбираю SSRAM(в линкер скрипте), то дойдя до 8 строчки bootloderа выдаеться ошибка о неправильном формате данных во FLASH (он должен быть SREC) и на этом конец!!

С такой проблемой не сталкивался, но дело-то в линковщике, а не в аппаратной системе.
Можно, например, сгенерировать на стороне проект, в котором по адресам SSRAM подсунуть накристальную память, собрать код там, а потом подсунуть его в ваш проект.

Serg`

Dec 9 2008, 20:33

Цитата(id_gene @ Dec 9 2008, 11:47)

Хорошо завтра с утра попробую о результатах тогда же напишу спасибо за совет!! А ЕДК даст на 0х00000000 подсунуть ссрам??

id_gene

Dec 10 2008, 07:22

Цитата(Serg` @ Dec 9 2008, 23:33)

С ЕДК я не работал, но я имел ввиду следующее: сейчас у вас две памяти в адресном пространстве процессора: флэш по адресу 0x1 и ссрам по адресу 0x0. в новом проекте вы собираете все то же самое, только без ссрам, а по адресу 0х0 кладете накристальную память с такой же шириной данных. Тогда у вас линковщик не ругается, вставляет загрузчик, а потом вы этот код подсовываете своей изначальной системе, и, наверное

, что-нибудь получится. Не вижу для этого препятствий (опять же, с ЕДК не работал).
Промоделировать хорошо бы...

Serg`

Dec 10 2008, 16:41

Попробовал сегодня!

При создании нового проекта все ок на ссрам по фдресу 0х0 не ругался!Только под отладчиком не запустился!Попробовал без оладчика!!Тот же эффект!Пересобрал софтовый проект и получил то де что и было до этого тоесть

srec line 1 ok.
.
.
.
.
.
.
srec line 8 ERROR: srec line is corrupted.

Мб есть еще идеи???

srec line это линии с загрузчика во флэшь!!

id_gene

Dec 11 2008, 06:48

Цитата(Serg` @ Dec 10 2008, 19:41)

srec line 8 ERROR: srec line is corrupted.
srec line это линии с загрузчика во флэшь!!

SREC - это мотороловский формат образа флеши.
Ошибка там может быть, если не соблюден формат или не сошлась контрльная сумма.

Serg`

Dec 11 2008, 11:16

Но тогда возникает вопрос: почему при прошивке флеша елф файлом в котором оперативка - накристальная формат генериться верно(в него преобразовывает сам флешврайтер) а при прошивке флеша елф файлом в котором оперативка - ссрам этот формат коцаеться!!??

Serg`

Dec 16 2008, 21:21

Блин ну помогите ктонить этот бутлодер меня уже задолбал!!!

Serg`

Dec 21 2008, 07:42

Вроди разобрался сам!! Просто поместил все что можно в накристалку, а то не можно в срам!!Пока что пашет!Гружусь с интеловской флэшки!!Только остался вопрос с платформ флэш!!Ни кто на нем бутлодера не делал???Просто из интереса!!

Serg`

Dec 24 2008, 11:41

ДА!!

Все оказалось не так то просто!!!

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

Если грузить ее в накристалку то все работает!!Но если же грузить ее в СРАМ даже для простейшего проэкта - ошибка!!

Я порылся в исходниках бутлодера и нашел вот какую вещь

Код

static int8_t flash_get_srec_line (uint8_t *buf)
{
    uint8_t c;
    int8_t count = 0;

    while (1) {
    c  = *flbuf++;


     print ("\r\nC=0x");
    putnum (c);

    if (c == 0xD) {
            /* Eat up the 0xA too */
        c = *flbuf++;
        return 0;
    }

    *buf++ = c;
    count++;


     print ("\r\nCOUNT=0x");
    putnum (count);


    if (count > SREC_MAX_BYTES)
        return LD_SREC_LINE_ERROR;
    }
}

SREC_MAX_BYTES = 78
flbuf = (uint8_t*)FLASH_IMAGE_BASEADDR - это адрес с которого начинаеться чтение, у меня 0х87000000(флэшка)

это кусок бутлодера (он не большой), весь он приведен в приложении.

Так вот как вы видите в этой функции опрашиваеться flbuf через с и как тока будет найдена синхропосылка 0хD мы вываливаемся из нее.

Я посмотрел терминалом (полностью листинг приведен в приложении) что у нас в с и выяснил удивительную штуку:

Код

EDK Bootloader:

C=0x00000053
COUNT=0x00000001
C=0x00000030
COUNT=0x00000002
C=0x00000031
COUNT=0x00000003
C=0x00000033
COUNT=0x00000004
C=0x00000030
COUNT=0x00000005
C=0x00000030
COUNT=0x00000006
C=0x00000030
COUNT=0x00000007
C=0x00000030
COUNT=0x00000008
C=0x00000034
COUNT=0x00000009
C=0x00000044
COUNT=0x0000000a
C=0x00000035
COUNT=0x0000000b
C=0x00000039
COUNT=0x0000000c
C=0x00000035
COUNT=0x0000000d
C=0x00000046
COUNT=0x0000000e
C=0x00000034
COUNT=0x0000000f
C=0x00000032
COUNT=0x00000010
C=0x00000034
COUNT=0x00000011
C=0x00000046
COUNT=0x00000012
C=0x00000034
COUNT=0x00000013
C=0x00000046
COUNT=0x00000014
C=0x00000035
COUNT=0x00000015
C=0x00000034
COUNT=0x00000016
C=0x00000032
COUNT=0x00000017
C=0x00000045
COUNT=0x00000018
C=0x00000036
COUNT=0x00000019
C=0x00000035
COUNT=0x0000001a
C=0x00000036
COUNT=0x0000001b
C=0x00000043
COUNT=0x0000001c
C=0x00000036
COUNT=0x0000001d
C=0x00000036
COUNT=0x0000001e
C=0x00000032
COUNT=0x0000001f
C=0x00000045
COUNT=0x00000020
C=0x00000037
COUNT=0x00000021
C=0x00000033
COUNT=0x00000022
C=0x00000037
COUNT=0x00000023
C=0x00000032
COUNT=0x00000024
C=0x00000036
COUNT=0x00000025
C=0x00000035
COUNT=0x00000026
C=0x00000036
COUNT=0x00000027
C=0x00000033
COUNT=0x00000028
C=0x00000037
COUNT=0x00000029
C=0x00000033
COUNT=0x0000002a
!!!!C=0x0000000d
Bootloader: Processed (0x)00000001 S-records
C=0x00000053
COUNT=0x00000001
C=0x00000033
COUNT=0x00000002
C=0x00000030
        .
        .
        .
        .
        .
        .
        .

COUNT=0x0000002e
!!!!C=0x0000000d
Bootloader: Processed (0x)00000021 S-records
C=0x000000b0
COUNT=0x00000001
C=0x000000b0
COUNT=0x00000002
C=0x000000b0
COUNT=0x00000003
C=0x000000b0
COUNT=0x00000004
C=0x000000b0
COUNT=0x00000005
C=0x000000b0
COUNT=0x00000006
C=0x000000b0
COUNT=0x00000007
C=0x000000b0
COUNT=0x00000008
C=0x000000b0
COUNT=0x00000009
C=0x000000b0
COUNT=0x0000000a
C=0x000000b0
COUNT=0x0000000b
C=0x000000b0
COUNT=0x0000000c
C=0x000000b0
COUNT=0x0000000d
C=0x000000b0
COUNT=0x0000000e
C=0x000000b0
COUNT=0x0000000f
C=0x000000b0
COUNT=0x00000010
C=0x000000b0
COUNT=0x00000011
C=0x000000b0
COUNT=0x00000012
C=0x000000b0
COUNT=0x00000013
C=0x000000b0
COUNT=0x00000014
C=0x000000b0
COUNT=0x00000015
C=0x000000b0
COUNT=0x00000016
C=0x000000b0
COUNT=0x00000017
C=0x000000b0
COUNT=0x00000018
C=0x000000b0
COUNT=0x00000019
C=0x000000b0
COUNT=0x0000001a
C=0x000000b0
COUNT=0x0000001b
C=0x000000b0
COUNT=0x0000001c
C=0x000000b0
COUNT=0x0000001d
C=0x000000b0
COUNT=0x0000001e
C=0x000000b0
COUNT=0x0000001f
C=0x000000b0
COUNT=0x00000020
C=0x000000b0
COUNT=0x00000021
C=0x000000b0
COUNT=0x00000022
C=0x000000b0
COUNT=0x00000023
C=0x000000b0
COUNT=0x00000024
C=0x000000b0
COUNT=0x00000025
C=0x000000b0
COUNT=0x00000026
C=0x000000b0
COUNT=0x00000027
C=0x000000b0
COUNT=0x00000028
C=0x000000b0
COUNT=0x00000029
C=0x000000b0
COUNT=0x0000002a
C=0x000000b0
COUNT=0x0000002b
C=0x000000b0
COUNT=0x0000002c
C=0x000000b0
COUNT=0x0000002d
C=0x000000b0
COUNT=0x0000002e
C=0x000000b0
COUNT=0x0000002f
C=0x000000b0
COUNT=0x00000030
C=0x000000b0
COUNT=0x00000031
C=0x000000b0
COUNT=0x00000032
C=0x000000b0
COUNT=0x00000033
C=0x000000b0
COUNT=0x00000034
C=0x000000b0
COUNT=0x00000035
C=0x000000b0
COUNT=0x00000036
C=0x000000b0
COUNT=0x00000037
C=0x000000b0
COUNT=0x00000038
C=0x000000b0
COUNT=0x00000039
C=0x000000b0
COUNT=0x0000003a
C=0x000000b0
COUNT=0x0000003b
C=0x000000b0
COUNT=0x0000003c
C=0x000000b0
COUNT=0x0000003d
C=0x000000b0
COUNT=0x0000003e
C=0x000000b0
COUNT=0x0000003f
C=0x000000b0
COUNT=0x00000040
C=0x000000b0
COUNT=0x00000041
C=0x000000b0
COUNT=0x00000042
C=0x000000b0
COUNT=0x00000043
C=0x000000b0
COUNT=0x00000044
C=0x000000b0
COUNT=0x00000045
C=0x000000b0
COUNT=0x00000046
C=0x000000b0
COUNT=0x00000047
C=0x000000b0
COUNT=0x00000048
C=0x000000b0
COUNT=0x00000049
C=0x000000b0
COUNT=0x0000004a
C=0x000000b0
COUNT=0x0000004b
C=0x000000b0
COUNT=0x0000004c
C=0x000000b0
COUNT=0x0000004d
C=0x000000b0
COUNT=0x0000004e
!!!!C=0x000000b0
COUNT=0x0000004fERROR: SREC line is corrupted

!!!! - я пометил синхропосылки

с залипло на значении b0 C=0x000000b0 и все 78 раз с флэшки читаеться одно и тоже и соответственно синхропосылка 0хD не найдена и мы вываливаемся с ошибкой!!

От сюда вопрос что это может быть??

Я неправильно пишу во флэшь??

Не правильно читаю из флэшь??

Или что нибудь не правильно еще??

Подскажите!!Этот бутлодер уже меня замучил!!!

Файлик в приложение

Zinger

Jan 27 2009, 13:56

Привет всем. Ну что кто нибудь разобрался с загрузчиком? Может подскажете что и как там все работает, я что то не могу разобраться.

Serg`

Feb 3 2009, 13:37

Вот проэкт под xcf32p работает!! Сам тестил!!

http://ifolder.ru/10364928
Пароль:55555

ТОка прочитайте в хапп482 как правильно создать мцс файл!!Без этого не заработает!!

Krys

Dec 13 2017, 09:09

Здравствуйте. Попробую заняться некропостингом.
У нас есть проблема с запуском микроблейза из флешки сразу в DDR память. Т.е. есть ПЛИС спартан6, есть флешка (w25q128bw), есть DDR память к плисине. Раньше всё работало так, что загрузчик был в BRAM, загружал весь код из флешки в DDR и стартовал. Но потом мы забили кристалл подзавязку, и возник вопрос: зачем нам подключать к микроблейзу блочную память, если у нас завались внешней DDR? Сказано - сделано, развели такую прошивку, без BRAM. Всё отлично работает, если стартовать из SDK. Но как теперь сделать, чтобы загрузчик сразу грузился из флешки, а не из BRAM? Вообще не знаем, с какого боку подойти. Нигде не нашли, чтобы такой вариант описывался.
Заранее спасибо за подсказки.

krux

Dec 13 2017, 09:37

обычно, нужен кусок кода, копирующий основной выполняемый код из flash в ddr. после чего этот код делает goto по адресу, расположенному в ddr.
этот кусок кода должен быть в некоем ПЗУ, и на первую ячейку в этом ПЗУ должен указывать reset-вектор вашего microblaze.
раньше этим ПЗУ был ваш BRAM, проинициализированный прошивкой ПЛИС.

если у вас есть некая параллельная flash, подключенная непосредственно к ПЛИС, и из которой microblaze может выполнять код непосредственно - то можно использовать в качестве ПЗУ её.

есть и другой вариант - написать конечный автомат, который при запуске прошивки
1) зажимает ресет microblaze
2) ждёт готовности SPI flash и ddr к работе
3) копирует основной код из SPI flash в ddr
4) отпускает ресет microblaze

зы. при использовании "SDK" выполняемый код в ddr загружается через jtag.

toshas

Dec 13 2017, 11:00

Может быть это ?

https://www.xilinx.com/support/documentatio...uad-spi-ipi.pdf

Krys

Dec 14 2017, 02:23

toshas, спасибо, похожее, но проблема в том, что там дока про виваду, а в ней спартан6 не поддерживается. Но может как-то по аналогии получится

Цитата(krux @ Dec 13 2017, 16:37)

если у вас есть некая параллельная flash, подключенная непосредственно к ПЛИС, и из которой microblaze может выполнять код непосредственно - то можно использовать в качестве ПЗУ её.

И Вам спасибо. Правда второй флешки нет, ибо это так же избыточно (формально), как и изыскивать по крупицам блочную память под загрузчик в забитом кристалле при наличии вагона мегабайтов DDR памяти.

Цитата(krux @ Dec 13 2017, 16:37)

есть и другой вариант - написать конечный автомат, который при запуске прошивки

Тоже хороший вариант, но ресурсов съест ещё больше, чем просто задействование BRAM под загрузчик

Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.