Коллеги, вот в комплекте GHRD для De0-Nano-SoC идут два xml-ника: hps_common_board_info.xml и soc_system_board_info.xml.
Они нужны на этапе сборки DeviceTree командой sopc2dts - ей как раз эти два файлика подсовываются. Насколько я понимаю их содержимое, там описывается архитектура soc-системы с точки зрения процессора - что где сидит, как с чем связано, выставляются тайминги, скорости и т.п.
И вот какой вопрос возник: если собираю свою систему с нуля со своими sopc-присосками к процессору, то как мне получить такие файлы для своей системы? Насколько я понял в этих ваших интернетах, файлы эти пишутся какими-то неведомыми Богами-производителями плат. И все берут за основу как раз эти терасиковские файлы (из GHRD). А как создать свой под свою систему? Неужели в нашем энергичном 21-м веке надо писать такой xml ручками? Не, не вопрос - я конечно напишу если так и надо, но как-то это дико - везде куча тулзов для автоматической генерации чего угодно из чего угодно, а тут - неужели вот так вручную по хардкору?
Спасибо.
Полная версия этой страницы: Как самому создать файлы board info .xml?
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Системы на ПЛИС - System on a Programmable Chip (SoPC)
Что то мне кажется что oc_system.xml создаётся Qsys автоматически.
hps_common надо отдельно смотреть.
hps_common надо отдельно смотреть.
hps_common_board_info.xml и soc_system_board_info.xml. И как вы с ними в итоге решили вопрос?
Ох и повозились мы с друже......
Отвечаю на свой же вопрос. Инфа архиценная:
- их самих править не надо
- создается третий файл xml (надо ручками, ручками)
- в него добавляется кастомное железо (Нажмите для просмотра прикрепленного файла)
- потом толкаем генерёж (Нажмите для просмотра прикрепленного файла, переименовать в .bat)
- батник генерит из xml файлы dts и dtb
Как-то так.
Полезная инфа:
https://github.com/altera-opensource/sopc2dts
https://rocketboards.org/foswiki/Documentat...reeGenerator140
собирать по примерам
ЗЫ: нам повезло, у нас всего одно кастомное устройство, видимое из линукса - это дма. А вот тем у кого ядрышки поболее и посложнее, тут уж.... не позавидую )))
Отвечаю на свой же вопрос. Инфа архиценная:
- их самих править не надо
- создается третий файл xml (надо ручками, ручками)
- в него добавляется кастомное железо (Нажмите для просмотра прикрепленного файла)
- потом толкаем генерёж (Нажмите для просмотра прикрепленного файла, переименовать в .bat)
- батник генерит из xml файлы dts и dtb
Как-то так.
Полезная инфа:
https://github.com/altera-opensource/sopc2dts
https://rocketboards.org/foswiki/Documentat...reeGenerator140
собирать по примерам
ЗЫ: нам повезло, у нас всего одно кастомное устройство, видимое из линукса - это дма. А вот тем у кого ядрышки поболее и посложнее, тут уж.... не позавидую )))
Мне удобнее всего ручками править .dts файл, добавляя в него нужную периферию.
Несложный и хорошо читаемый синтаксис, к примеру:
в отличие от нечитаемых .xml
Несложный и хорошо читаемый синтаксис, к примеру:
Код
i2c_fpga: i2c_fpga@0x100000000 {
compatible = "mycore,i2c-master-0.1";
reg = <0x00000001 0x00000000 0x00000010>;
interrupt-parent = <&hps_0_arm_gic_0>;
interrupts = <0 40 4>;
clocks = <&clk_0>;
speed-mode = <100000>;
};
compatible = "mycore,i2c-master-0.1";
reg = <0x00000001 0x00000000 0x00000010>;
interrupt-parent = <&hps_0_arm_gic_0>;
interrupts = <0 40 4>;
clocks = <&clk_0>;
speed-mode = <100000>;
};
в отличие от нечитаемых .xml
Т.е. из GHRD мы должны взять .dts или .xml и дописать туда свое.
У меня же получается, что исходный GHRD проект от Terasic под ядро линукса 3.12
А дальнейшая инструкция с https://rocketboards.org/foswiki/Documentation/AVCVGSRD171 под более свежее ядро например.
То правильно ли я понимаю, что даже если я сделаю свои .dtb их нельзя будет использовать под более свежие версии линукса?
У меня же получается, что исходный GHRD проект от Terasic под ядро линукса 3.12
А дальнейшая инструкция с https://rocketboards.org/foswiki/Documentation/AVCVGSRD171 под более свежее ядро например.
То правильно ли я понимаю, что даже если я сделаю свои .dtb их нельзя будет использовать под более свежие версии линукса?
Не могу сказать.... Пробуйте....
Цитата(chirik @ Oct 23 2017, 17:48) 
То правильно ли я понимаю, что даже если я сделаю свои .dtb их нельзя будет использовать под более свежие версии линукса?
Думаю, что неправильно понимаете.
Новые версии линукса, как правило, совместимы с софтом, написанным под старые версии.
Тем более это должно относится к файлам Device Three.
Это, в конце концов, простые текстовые описания, без указания версии ядра.
Цитата(sonycman @ Oct 23 2017, 15:56)
Мне удобнее всего ручками править .dts файл, добавляя в него нужную периферию.
Несложный и хорошо читаемый синтаксис, к примеру:
в отличие от нечитаемых .xml
Несложный и хорошо читаемый синтаксис, к примеру:
Код
i2c_fpga: i2c_fpga@0x100000000 {
compatible = "mycore,i2c-master-0.1";
reg = <0x00000001 0x00000000 0x00000010>;
interrupt-parent = <&hps_0_arm_gic_0>;
interrupts = <0 40 4>;
clocks = <&clk_0>;
speed-mode = <100000>;
};
compatible = "mycore,i2c-master-0.1";
reg = <0x00000001 0x00000000 0x00000010>;
interrupt-parent = <&hps_0_arm_gic_0>;
interrupts = <0 40 4>;
clocks = <&clk_0>;
speed-mode = <100000>;
};
в отличие от нечитаемых .xml
При таком подходе проблем с sysid_qsys id и timestamp не возникает? они же будут не соответствовать заново генерированной системе из qsys ?
Код
sysid_qsys: sysid@0x100001000 {
compatible = "altr,sysid-16.1", "altr,sysid-1.0";
reg = <0x00000001 0x00001000 0x00000008>;
clocks = <&clk_0>;
id = <2899645186>;
timestamp = <1492500749>;
}; //end sysid@0x100001000 (sysid_qsys)
compatible = "altr,sysid-16.1", "altr,sysid-1.0";
reg = <0x00000001 0x00001000 0x00000008>;
clocks = <&clk_0>;
id = <2899645186>;
timestamp = <1492500749>;
}; //end sysid@0x100001000 (sysid_qsys)
И не подскажите почему в примерах при генерации dts в sopc2dts указывают опцию --bridge-removal all ??
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.