Vslav, в планах нет?Сообщение от Vslav
Vslav, в планах нет?
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Нету. Реверс штука дорогая, все подряд реверсить не будешьVslav, в планах нет?
1801ВМ2 есть - и то хорошо.
- - - Добавлено - - -
Это не может быть прерывание от таймера? Отключено?
Конечно, надо добить, такой путь уже прошли, было бы обидно бросить.
Да, я помню. Но там не мгновенно - надо всю структуру проектов переделывать. Сейчас 3 процессора и 7 плат - и в итоге 21 проект, и еще процессор и три платы на подходе (С5, династия Тан и IGLOO) - будет 4x10 - 40. Перебор, и оно будет квадратично продолжаться с ростом матрицы, вот думаю как это все в линейный рост перевести.
Конечно отключено. Я пробовал включить - сообщений о незапланированном прерывании становится меньше, и при каждом запуске их количество начинает меняться. Что-то странное происходит с прерываниями.
Я уж думаю - может быть, это я неправильно управление памятью настроил? В документации на МС1201 информации об карте памяти практически нет, а схемотехнически все это спрятано в микросхеме D39 по имени 1801ВП1-013.
Из всхех кусочов информции, что удалось собрать, я предопложил, что
в юзерском режиме:
000000 - 157776 - RAM
160000 - 177776 - страница ввода-вывода с портами устройств
В режиме пульта:
000000 - 137776 - ничего нет
140000 - 157776 - ПЗУ 055
160000 - 177776 - RAM
Портов в этой конфигурации вообще нет, поэтому монитор с портами общается только через спецкоманды чтения-записи userspace.
И, судя по дизассемблированной части монитора, я если и ошибся, то не очень сильно. Буду в выходные искать дальше, откуда лезут эти незапланированные прерывания.
Насколько я понял, этот контроллер прерываний специфичен именно для ВМ2, поскольку через него реализовано безадресное чтение. У ВМ1 такого нет, а про LSI я не в курсе. И именно в реализации безадресного чтения и допущена ошибка.Да, я помню. Но там не мгновенно - надо всю структуру проектов переделывать
По-моему, достаточно исправить 1 файл vm2/hdl/wbc/lib/wbc_vic.v, он общий для всех плат, поддерживаемых этим проектом.
Вроде бы правильно.
А должен быть вообще один для всех плат и процессоров, с параметризацией. LSI тоже его использует (но не использует безадресное чтение).
Надо ковырять 055 чтобы понять когда выводится сообщение о незапланированном прерывании и пытаться поймать это место.
Да место-то как раз более-менее понятно...
Если опираться только на результат дизассемблирования, то пока видна единственная ситуация, в которой это может произойти. Получается, что при выходе из прерывания по RTI не восстанавливается бит 8 PSW, управляющий режимом user/halt. В результате управление уходит не в монитор а хрен знает куда - по адресу 170004 в юзерском пространстве ничего нет, возникает таймаут шины и незапланированный вылет по вектору 4. Обработчик вектора 4 выводит сообщение о незапланированном прерывании и делает RTI, и далее все по кругу несколько раз, пока стек не затрет какие-то куски кода в памяти.
Как вариант, бит 8 может быть и восстанавливается, но при этом не поднимается бит wb_adr[16] (который бывший SEL) - тогда не переключается карта памяти с теми же самыми последствиями.
В выходные постараюсь написать тестовую программку, моделирующую эту ситуацию, тогда станет понятнее. Может быть, я и не прав. Тут надо тщательно разбираться.
В тестовой SoC есть прерывания от таймера, я проверю восстановление PSW8 и адрес wb_adr_o[16].
Да тут аппаратные прерывания как таковые для проверки не нужны.
Тут такая ситуация. Монитор по команде Т переписывает весь тестовый код из ПЗУ в младший банк ОЗУ и передает туда управление командой START. Далее отрабатывается тест, и затем происходит возврат в монитор вот таким способом:
По адресу 170004, а это теневой банк ОЗУ, лежит команда JMP на бесконечный цикл обработки пультовых команд. И вот в этот момент, после RTI, и происходит незапланированное прерывание. Понятно, что если сигнал SEL не поднимется, то так и будет - после RTI управление уйдет на несуществующие адреса.Код:ROM:002306 loc_2306: ; CODE XREF: sub_1570+104↑J ROM:002306 ; default_int_handler+20↑J ... ROM:002306 012746 000740 mov #740, -(SP) ROM:002312 012746 170004 mov #loc_170004, -(SP) ROM:002316 000002 rti
Надо это дело проверить. Я написал простенькую тестовую программку:
Эта программка моделирует вышеописанный возврат в монитор - заталкивает в стек PSW с поднятым 8 битом. Запускаю. В терминале:Код:.WORD START .WORD 0 .= 100 START: MOV #410,SP MOV #740,-(SP) MOV #RMON,-(SP) RTI RMON: MOV #MSG2,R3 CALL printstr MFPS R3 CALL PNUM STOP: BR STOP MSG2: .ASCIZ <15><12>"* PSW = "Вроде все правильно, бит 8 PSW установился.Код:* PSW = 177744
Дальше чисто программными способами, без изменения схемы, не проверить. У меня на моей плате есть 4 светодиода. Я подвесил на один из них бит 16 адреса:
Запускаю схему - светодиод не светится. То есть adr[16]==0. А поскольку программа в конце зацикливается и начинает топтаться по одним и тем же адресам, то все транзакции на шине должны быть с wb_adr[16]==1, и светодиод должен ярко светиться.Код:reg [16:0] indaddr; always @ (posedge wb_stb) indaddr [16:0] <= wb_adr [16:0]; assign led0=indaddr[16];
Вот она, проблема.
Остается промоделировать все это в моделсиме. Осциллограмму сюда я вставлять не буду, бесполезно это, прикладываю ее в архив. На ней хорошо видно:
1. Процессор читает слово 740 с адреса 000406. Это он из стека достал новый PSW.
2. По адресу 000116 читается 12703. Это уже выбирается первая команда после возврата по RTI. Адрес - именно 000116, ,бит 16==0, то есть перехода в режим пульта не было. Хотя в PSW бит 8 поднялся.
Вот и все мои на данный момент изыскания. Прикладываю архив с тестовой программкой. Конечно, запускать ее имеет больше смысла в симуляторе.
Жаааль
Отож. Но если желающие реверсить будут - то сфотаем кристалл 1806ВМ2, это можно себе позволить
У меня то желание есть, но вот времени, увы... И даже не предвидится... И до пенсии ещё далеко
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
