проблема с Bootloaderом, Связка SSRAM+FLASH Опции

[Serg`]

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

У меня есть 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`]

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

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

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

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

[Serg`]

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

[id_gene]

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

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

[Serg`]

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

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

[id_gene]

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

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

[Serg`]

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

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

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


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

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

[id_gene]

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

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

[Serg`]

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

[Serg`]

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

[Serg`]

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

[Serg`]

ДА!!

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

Все дело в секции _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 не найдена и мы вываливаемся с ошибкой!!

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

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

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

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

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

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

Прикрепленные файлы

 boot_TERMINAL.txt ( 45.76 килобайт ) Кол-во скачиваний: 202
 bootloader.txt ( 4.75 килобайт ) Кол-во скачиваний: 569

 

[Zinger]

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

[Serg`]

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

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

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

[Krys]

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

[krux]

обычно, нужен кусок кода, копирующий основной выполняемый код из 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]

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

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

[Krys]

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

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

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

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

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