Модифицированная прошивка для глитчеров

[Alibaba 0]

Этот набор прошивок для любых глитчеров на основе xc2c64 для глюка корон. Основное отличие от стандартных прошивок: на дебаг светодиод выведен postout, тайминги reset оптимизированы под короткие провода (аналог 4_3),  тайминги i2c сигналов приведены в норму, оптимизирован код (уменьшено количество логических элементов используемых в CPLD, особенно в высокочастотной части схемы).

 

Зачем на дебаг выведен на postout? 1. По светодиоду можно оценить есть ли контакт к ножке postout процессора ещё до установки радиатора на процессор. 2. По миганию светодиода можно выявить половину всех дефектов распайки глитчера (i2c шина, reset). 3. По светодиоду можно оптимизировать запуск (подбирать длину ресета) хотя в этом большой необходимости нет. 4. По светодиоду видно что приставка стартанула, за пару секунд до включения светодиода spdif и кольца.

 

При использовании этих прошивок не должно быть конденсаторов на ресете. Если это Matrix - не надо запаивать перемычку подключающую конденсаторы. Если Runner (не лайт) необходимо выпаять конденсаторы около переключателя phat - slim. На лайте конденсаторы подключаются перемычками  - не надо их запаивать. Дипами можно подстроить момент. Резистор на 100 ом в цепи ресета тоже не нужен.

 

Набор прошивок - http://yadi.sk/d/P4wIY-oyCh3wC

Исходники - http://yadi.sk/d/mX9z3b3jCh3n3

Фото размещения глитча - http://yadi.sk/d/VxE5dEyiC7Pr7

 

Рекомендую начать с 21866_3 или 21865_3.

 

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

 

[dontazavr 0]

@Alibaba, Конечно выкладывай,пусть народ потестит и отпишется о результатах.

[ment33 0]

имеет смысл проверить только на E

а так для задротов юзающих говно шляпу от TX

[Alibaba 0]

@Alibaba, Конечно выкладывай,пусть народ потестит и отпишется о результатах.

Прошивка для тринити работает, но ещё не доведена. Позже выложу. 

[jove 0]

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

[ment33 0]

навесной кондер и кольцо решает. 

[jove 0]

Да еслиб. Пробовал ДГХ-РГХ, пробовал х360РАН (на нем перебрал все перемычки и кондеры по мануалу), пробовал кулранер красный. Длину резета делал экранированным, одножильным, многожильным, длиной 30, 50, 80. Пробовал кондеры от 220 до 330. Или бесконечные резеты или дрыгает кулерами. Пробовал разные точки резета и разную укладку. Пробовал разные сборщики и кселлы. Бесполезно.

Изменено 14 ноября 2013 пользователем jove

[Alibaba 0]

Аналогичный набор прошивок для тринити - http://yadi.sk/d/XqlBCaXuCiKEL

 

Подключение глитча стандартное, clock берется с Hana чипа. Я использую 17360_2 с cr3 лайт. Дипами подстраиваю. Конденсаторов в цепи ресета быть не должно. Резистор на 100 ом в цепи ресета по необходимости. Провода от глитча до проца короткие, без петель. 

Изменено 15 ноября 2013 пользователем Alibaba

[jove 0]

Походу вы глубоко в теме. Объясните убогому почему на тринити нужен был резет длиной 50см, а на короне нет и в вашей прошивке длинный резет тоже не нужен. Столько времени для меня это было непостижимой тайной бытия.

[ment33 0]

легких путей не ищем? матрикс друг + то что я сказал. старо и работоспособно. 

[byFredijkeee 0]

Надо будет затестить. На старты (в смысли быстрее-медленнее) на нормальных коронах (не глючных, о которых в первом посту речь) влияет?

[tonik 0]

если как написано это аналог 4_3, то все изменения только ради postout дебаг.

наличие контакта postout можно проверить мультиметром тоже до установки радиатора и самого чипа

 

Alibaba, есть ли разница во времени старта ?

[Alibaba 0]

Походу вы глубоко в теме. Объясните убогому почему на тринити нужен был резет длиной 50см, а на короне нет и в вашей прошивке длинный резет тоже не нужен. Столько времени для меня это было непостижимой тайной бытия.

 

Теория проста. У процессора бокса есть минимальная длительность импульса сигнала ресет. Если подавать импульс меньше минимально допустимого - процессор обрабатывает его не корректно. Часть схемы процессора успевает обнулиться, а часть продолжает работать дальше. Этот баг и используют. Необходимо ресетом попасть в определенную команду кода и тогда проверка на легальность кода проходит успешно.

Для настройки точного попадания в нужное место есть несколько вариантов:

1. Изменять длину провода на ресет. Меняется емкость линии и время прохождения сигнала по ней.

2. Подбирать тайминги ресета в глитчере.

В моих прошивках тайминги подобраны для минимальных длин проводов. Есть ещё путь к улучшению стартов - увеличение тактовой частоты глитчера, что позволяет более точно попадать в нужное место.

На счет улучшения запуска корон. В тринити глитчер и процессор почти синхронизированы. Дисбаланс вносит только PLL процессора, отсюда хорошие результаты запуска. В короне нет синхронизации между ними и по пути от кварца бокса до процессора стоит две PLL - одна в южном мосте, другая в процессоре. Посему сигнал ресета гуляет вокруг нужного места на величину равную рассинхронизации гличера и процессора и в определенные моменты попадает в нужное место. Пока не будет синхронизации между процессором и глитчером быстрых запусков на коронах не будет.  

Изменено 15 ноября 2013 пользователем Alibaba

[byFredijkeee 0]

@Alibaba, Таки полезная инфа!) :zadrot: 

Всё-таки, без теории некуда ;) Писали бы такое в факах для новичков. А то делают как роботы (ну, как роботы, ужасно настроенные роботы), а потом плодят тем по форумам. :khm:

[RichY 0]

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

Поясню почему я считаю, что проц выключается в момент подачи Z на RST. Если бы CPU_RST отвечал только за перезагрузку, то длительность импульса не влияла бы совсем! Проц поймал перепад уровня - оп, перезагрузился. И ему уже плевать, на длительность. Но нет, народ все равно подбирает импульсы. 

 

А так, прошивок я тоже много делал. Вот только тестировать не на чем, боксами я не занимаюсь. Вершина творения умела перебирать тайминги, запоминать успешный и даже забывать его в случае 7 неуспешных попыток старта.. Очень сложно было это всё в xc2c64a засунуть

Итого вышло, что лучше всего по-прежнему работает оптимизированная 4_3 (да, и я её оптимизировал когда-то) :-)

Писали бы такое в факах для новичков

О даа. Писал раньше. Выходили очень большие статьи. Громааадные. Те, кто осилил их чтение - конечно же, начинали понимать суть процесса и думали своими мозгами. Увы, большинство хотело лишь алгоритм действий. И им пофиг на смысл. Отсюда и вопросы на форумах

[Alibaba 0]

Обычно в процессорах сигнал ресет не связан с питанием. Цифровые схемы после включения питания могут находятся в неопределенном состоянии и для приведения их в состояние начального запуска реализуют специальные цепи в том числе и сигнал ресет. Практически все процессоры инициализируются одинаково - подается питание и удерживается ресет в течении некоторого времени после подачи питания, для приведения схем в начальное состояние. По моему не суть важно, как этот глюк происходит внутри процессора. Об этом могут знать только разработчики схемы процессора.  Главное что-бы внешнее воздействие приводило к желаемому результату. На счет аналоговой природы глюка - позволю себе не согласиться. Дело все в том, что внутренности процессора работают на высокой частоте, точно сказать не могу, но гораздо выше рабочей частоты глитча и попасть ресетом в нужную точку при таком раскладе практически невозможно. "Колдовство" - как раз и есть точная подстройка тайминга, которую невозможно реализовать программно по причине низкой тактовой частоты глитчера.

Изменено 15 ноября 2013 пользователем Alibaba

[ment33 0]

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

Поясню почему я считаю, что проц выключается в момент подачи Z на RST. Если бы CPU_RST отвечал только за перезагрузку, то длительность импульса не влияла бы совсем! Проц поймал перепад уровня - оп, перезагрузился. И ему уже плевать, на длительность. Но нет, народ все равно подбирает импульсы. 

 

А так, прошивок я тоже много делал. Вот только тестировать не на чем, боксами я не занимаюсь. Вершина творения умела перебирать тайминги, запоминать успешный и даже забывать его в случае 7 неуспешных попыток старта.. Очень сложно было это всё в xc2c64a засунуть

Итого вышло, что лучше всего по-прежнему работает оптимизированная 4_3 (да, и я её оптимизировал когда-то) :-)

 

О даа. Писал раньше. Выходили очень большие статьи. Громааадные. Те, кто осилил их чтение - конечно же, начинали понимать суть процесса и думали своими мозгами. Увы, большинство хотело лишь алгоритм действий. И им пофиг на смысл. Отсюда и вопросы на форумах

на коронах TX 4_3 хватает. на тринити матрикс+кондер или говно от TX предварительно все сносится по рст + кондер (но все равно хуже чем матрикс) а конфига все два для тринити. и один для матриксов с кварцем.

 

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

[Feuerbard 0]

В моих прошивках тайминги подобраны для минимальных длин проводов. Есть ещё путь к улучшению стартов - увеличение тактовой частоты глитчера, что позволяет более точно попадать в нужное место.

На счет улучшения запуска корон. В тринити глитчер и процессор почти синхронизированы. Дисбаланс вносит только PLL процессора, отсюда хорошие результаты запуска. В короне нет синхронизации между ними и по пути от кварца бокса до процессора стоит две PLL - одна в южном мосте, другая в процессоре. Посему сигнал ресета гуляет вокруг нужного места на величину равную рассинхронизации гличера и процессора и в определенные моменты попадает в нужное место. Пока не будет синхронизации между процессором и глитчером быстрых запусков на коронах не будет.  

 

в stone была синхронизация с хбоксом  -  первая ревизия идеально на коронах работала , а потом на v 1,1 как то всё испортилось

[Alibaba 0]

HSTL линия к которой подключается стоне при глюке имеет частоту 25 мгц. Хорошо что эта частота синхронизирована с процем, но она гораздо меньше частоты процессора. Требуется большая аналоговая задержка, что они и сделали с помощью проволочного резистора (индуктивности) и конденсаторов. 

[twix 0]

Значит невозможно добиться таких же быстрых и стабильных запусков, как на тринити? Во что все упирается? В дорогие и более скоростные плисы и кварцы? Или еще что-то? Оч. интересно.

[Alibaba 0]

Есть много путей для улучшения:

1. Необходим сигнал с частотой как можно ближе к внутренней частоте процессора и синхронизированный с процессором. Я таких на плате не нашел, по причине отсутствия высокочастотных измерительных приборов. Если такой сигнал найдется, тогда можно говорить и о подборе плис.

2. Снизить внутреннюю частоту процессора. Приблизить её к скорости работы глитча. Но описания регистров PLL внутри процессора нет.

3. Изменить код загрузчика CB_A. На постаут выдавать дополнительные импульсы ближе к тому месту в которое нужно бить ресетом. Сокращение интервала уменьшает погрешность при рассинхронизации глитча и проца.  Это чистая теория, на практике не проверено.

[twix 0]

Благодарю Вас за инфу. Оч. редко можно услышать умные мысли настоящего профи. Всех благ!

[ment33 0]

грабли грабли грабли. как не которые любят на них наступать. вспоминается когда школьники нарыли осцил и зачем то "изучали" сигнал RST пытаясь понять зачем нужно кольцо. в итоге ни чего не нарыли и решили что кольцо не нужно там вообще. смеялся я очень долго....

[byFredijkeee 0]

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

Поясню почему я считаю, что проц выключается в момент подачи Z на RST. Если бы CPU_RST отвечал только за перезагрузку, то длительность импульса не влияла бы совсем! Проц поймал перепад уровня - оп, перезагрузился. И ему уже плевать, на длительность. Но нет, народ все равно подбирает импульсы. 

 

А так, прошивок я тоже много делал. Вот только тестировать не на чем, боксами я не занимаюсь. Вершина творения умела перебирать тайминги, запоминать успешный и даже забывать его в случае 7 неуспешных попыток старта.. Очень сложно было это всё в xc2c64a засунуть

Итого вышло, что лучше всего по-прежнему работает оптимизированная 4_3 (да, и я её оптимизировал когда-то) :-)

 

О даа. Писал раньше. Выходили очень большие статьи. Громааадные. Те, кто осилил их чтение - конечно же, начинали понимать суть процесса и думали своими мозгами. Увы, большинство хотело лишь алгоритм действий. И им пофиг на смысл. Отсюда и вопросы на форумах

Слава богу, я попал на такой фак :) Ну, ещё фак от XEO читал. Не поверишь, раза 3-4 читал от начала до конца, чтобы понять всю суть RGH)

[RoaDEviL 0]

Слава богу, я попал на такой фак :) Ну, ещё фак от XEO читал. Не поверишь, раза 3-4 читал от начала до конца, чтобы понять всю суть RGH)

Вся суть RGH на free60.org с самого начала была.