Перейти к содержанию
    

Как самому создать файлы board info .xml?

Коллеги, вот в комплекте GHRD для De0-Nano-SoC идут два xml-ника: hps_common_board_info.xml и soc_system_board_info.xml.

Они нужны на этапе сборки DeviceTree командой sopc2dts - ей как раз эти два файлика подсовываются. Насколько я понимаю их содержимое, там описывается архитектура soc-системы с точки зрения процессора - что где сидит, как с чем связано, выставляются тайминги, скорости и т.п.

 

И вот какой вопрос возник: если собираю свою систему с нуля со своими sopc-присосками к процессору, то как мне получить такие файлы для своей системы? Насколько я понял в этих ваших интернетах, файлы эти пишутся какими-то неведомыми Богами-производителями плат. И все берут за основу как раз эти терасиковские файлы (из GHRD). А как создать свой под свою систему? Неужели в нашем энергичном 21-м веке надо писать такой xml ручками? Не, не вопрос - я конечно напишу если так и надо, но как-то это дико - везде куча тулзов для автоматической генерации чего угодно из чего угодно, а тут - неужели вот так вручную по хардкору?

 

Спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Что то мне кажется что oc_system.xml создаётся Qsys автоматически.

hps_common надо отдельно смотреть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

hps_common_board_info.xml и soc_system_board_info.xml. И как вы с ними в итоге решили вопрос?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ох и повозились мы с друже......

Отвечаю на свой же вопрос. Инфа архиценная:

- их самих править не надо

- создается третий файл xml (надо ручками, ручками)

- в него добавляется кастомное железо (custom_dts_modules_info.xml)

- потом толкаем генерёж (java_soc_system_dtb.txt, переименовать в .bat)

- батник генерит из xml файлы dts и dtb

 

Как-то так.

Полезная инфа:

https://github.com/altera-opensource/sopc2dts

https://rocketboards.org/foswiki/Documentat...reeGenerator140

собирать по примерам

 

ЗЫ: нам повезло, у нас всего одно кастомное устройство, видимое из линукса - это дма. А вот тем у кого ядрышки поболее и посложнее, тут уж.... не позавидую )))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Мне удобнее всего ручками править .dts файл, добавляя в него нужную периферию.

Несложный и хорошо читаемый синтаксис, к примеру:

            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>;
            };

в отличие от нечитаемых .xml

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Т.е. из GHRD мы должны взять .dts или .xml и дописать туда свое.

 

У меня же получается, что исходный GHRD проект от Terasic под ядро линукса 3.12

А дальнейшая инструкция с https://rocketboards.org/foswiki/Documentation/AVCVGSRD171 под более свежее ядро например.

 

То правильно ли я понимаю, что даже если я сделаю свои .dtb их нельзя будет использовать под более свежие версии линукса?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

То правильно ли я понимаю, что даже если я сделаю свои .dtb их нельзя будет использовать под более свежие версии линукса?

Думаю, что неправильно понимаете.

Новые версии линукса, как правило, совместимы с софтом, написанным под старые версии.

 

Тем более это должно относится к файлам Device Three.

Это, в конце концов, простые текстовые описания, без указания версии ядра.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Мне удобнее всего ручками править .dts файл, добавляя в него нужную периферию.

Несложный и хорошо читаемый синтаксис, к примеру:

            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>;
            };

в отличие от нечитаемых .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)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И не подскажите почему в примерах при генерации dts в sopc2dts указывают опцию --bridge-removal all ??

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...