BIOS Disassembling

[JKstate]

Нет там аппаратный затык у G2 и PCI по разному сигнал и вектор прерывания обрабатывать и пересылать надо.

[SWAT]

Все это грустные полуфабрикаты, которые в общем то толком и не работают. Клон BBA так и не доведен до рабочего состояния, а все остальное это мусор.
BBA в общем то тормоз (500 кбайт на загрзку это смешно, у меня SD адаптер до 650 выдает), LAN адаптер убожестно, те IDE интерфейсы что цепляли на G2 за это время такое же убожество (все они не больше 500 кбайт выдают).
На нормальной скорости не работает ни один из делавшихся когда либо девайсов для шины G2, хотя возможности у этой шины большие и зацепить можно до 4 устройств с разными DMA каналами, а прерываний хватит и на 32! А в реальности даже одно работает с горем по полам.

[cybdyn]

да, там потенциал у дрима куда больше, взять хотя бычастоту между холли процем(100мгц) и ширину шины 64бита, это по дма проц забирает с холли. уже какие скорости получаются!
а по ихнему-PCI, даже теоретически 25мгц частота / 16 бит шина. даже приблизительно далеко не 1-2 мб/с ))))

эх, главное добраться до дрима.... не знаю, я пока на распутье: толи за разводку плат взяться, толи скорее доотладить псио.
но браться за дримку по кускам не хочется, надо доделать предыдущие начинания и потом основательно взяться тут . благо наработки от пс1 пойдут и на дрим.

[SI{AY]

SWAT, а есть какие нибудь продвижения со схемой подключения харда, что OzOnE тебе присылал?

[SWAT]

Пока нет, сейчас у меня весит еще 2 проекта помимо основной работы, времени на них то не хватает. Как разгребусь с этим, займусь DS. Наверное не раньше марта.

[MetalliC]

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

на сколько я вижу из дебага код устанавливает "адрес последнего байта" в 5f74e4 и начинает читать данные из биоса, в процессе этого железяка считает неведомый CRC потока читаемых с G1 данных (а биос висит на G1), и когда адрес совпадает с тем, что был записан в 74e4 сверяет CRC.

с дримом тут жопно - читаются все два метра.
но если стоит задача сделать кастомный биос - обратите внимание на Sammy Atomiswave, по сути тот же дрим только сбоку (по крайней мере внутри стоит та же Holly), только биос там маленький всего 64к, и после записи 5f74e4 вычитываются (кста просто читаются и никуда не пишутся) адреса всего до 0xa678.

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

[SWAT]

Ага ничего не известно.
Интересное предложение, но к сожалению не жизнеспособное. С такого биоса не загрузишься, ибо загрузка идет с нулевого адреса, а алгоритм прокачки биоса через holly прописан в каждой программе, которая запускается. Если поставить джамп где то в коде биоса, то и проверку он не пройдет, а иначе никак не запустить свой код.
Для твоей идеи не обязательно брать биос от Sammy Atomiswave, можно просто поставить больше размером саму микруху, вот только смысла нет.

[MetalliC]

вы не поняли суть предположения.

есть два варианта как сделана защита:
1. после записи адреса в 74e4 Holly сама вычитывает данные и считает CRC начиная с нуля и до того адреса, а цикл "прокачки" просто выполняет роль idle loop, и в этом случае всё плохо и вставить нужный нам джамп нельзя.

2. как я уже говорил в предыдущем сообщении - Holly считает CRC "прокачиваемых" данных (в случае дрима начиная с адреса 0x100), и при совпадении адреса с записанным в 74e4 сверяет сумму.
если имеет место такой вариант, то всё хорошо и в области 0 - 0x100 джамп вставить всё-таки можно.

проверить это дело при наличии железа не особо сложно (у самого увы дрима для экспериментов сейчас нет под рукой) - если после смены одного байтика допустим в области 0x48 - 0x5f биоса гд-ром будет жив - нам повезло и железка работает по варианту 2, если нет то увы и ах вариант 1.

[cybdyn]

я это гдето предлагал уже давно, возможно не здесь. но идея такая же. код который прокачивает лежит до 0х100. изменив прокачивальщик можно после прокачки кудато прыгнуть или аппаратно сменить микруху...

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

[SWAT]

Биос прокачивается абсолютно весь, начиная с нуля, а не 0x100:

PHP код:

register unsigned long p, x;
*((volatile unsigned long *)0xa05f74e4) = 0x1fffff;
for(p = 0; p < 0x200000/4; p++)
    x = ((volatile unsigned long *)0xa0000000)[p]; 


Это 100% не idle loop, хоть и по коду кажется что он в общем то бессмысленный, так данные вроде как в никуда гоняются.
Но смысл здесь в том, чтобы прогнать данные биоса просто по самой шине G1, так как при обращении к нулевому адресу, задействуется шина G1, на которой он собственно и весит. И вот самое печально в этом всем то, что проверка происходит где то на аппаратном уровне, данные сверяются напрямую с шины и на это можно повлиять опять же только аппаратно и никак иначе.

[cybdyn]

эта интерпритация в Си не совсем правильная, асм код говорит о другом. переписыввается код не с нуля. а кажись с 0х100 биоса

в какихто примерах дисассемблинга в Си, видел участки прокачки меньшие чем объём биоса. но тот кусок асма не видел лично.

[MetalliC]

2SWAT
тот С-шный код врёт, вот как оно на самом деле в биосе
http://i44.tinypic.com/16icsk7.png
в R0 - собсно начало вычитываемых данных, и да в дриме не пустой цикл - биос копируется в оперативку, а в атоме пустой - лонги читаются но никуда не пишутся.

[cybdyn]

кстати эту вот менюшку с пошаговым дебагером легко найти и запустить? а то я хотел бы пошагово сис-кол фунции пройти

[SWAT]

Код этот правильный, он используется везде именно в таком виде и никаком больше.
Вы путаете 2 разных операции, при запуске биос зеркалируется в оперативку и именно этот процесс вы принимаете за проверку биоса.
В общем здесь можно посмотреть кое что: http://www.ludd.luth.se/~jlo/dc/bootROM.c
Лазейка конечно где-то есть, ибо получилось же сделать биос проходящий проверку, но вот она пока не найдена, а может это просто удачная случайность.

[MetalliC]

оукей, смотрим там самое начало

Код:

void boot()    /* 0xa0000000 - start of bootROM */
{

и в конце ее

Код:

/* copy small routine to RAM */
src = (uint16_t *)romcopy;
dst = (uint16_t *)0x8c0000e0;
for (i = 0; i < sizeof(romcopy); i++)
*(dst++) = *(src++);

/* copy BootROM to RAM and continue executing at boot2(0) */
(*(void (*)(void *, void *))0x8c0000e0)((void *)0x80000100, (void *)0x8c000100);

показать саму romcopy нам не соизволили, собсно асм ее можно увидеть на скриншоте что я раньше выложил, на C ее можно написать где-то так:

Код:

void romcopy(u32 *src, u32 *dst) { // src = 0x80000100, dst = 0x8c000100

[b]*HW16(0xa05f74e4) = 0x001fffff;[/b]

for (i = 0; i < ((0x200000 - 0x100)/4); i++)
*(dst++) = *(src++);

boot2(); // 0x8c000120
}

код одинаковый во всех версиях биосов.
процедурка/сисколл syBtExit(mode) /* _8c0002c8 */, из которой ваша копипаста - судя по всему какой-то обработчик ошибки, и при нормальных условиях не выстреливает.

по крайней мере под эмулятором запись в 74e4 делается только один раз, в этой процедурке на старте биоса и больше не пишется, что в дриме, что в наоми1/2, что в атомисваве.

cybdyn сорри, в публичных сборках Демул отладчика нет, пользуйся тем, что в NullDC например.

[MetalliC]

add:
по всей видимости защита всё же работает автономно , т.к. в биосе Атомисвавы цикл "прокачки" выполняется в роме а не в раме, так что скорее всего холли сама вычитывает данные до указанного адреса, а все эти прокачечные замуты - пыль в глаза чтобы сбить с толку реверсеров, защитаж всё таки.

[cybdyn]

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

про отладик я имел ввиду - хотябы тот что у вас на фото.

[MetalliC]

разница есть, код-то крутится в биосе а не в раме и проц читает из него команды, кроме того что сами команды потом читают из биоса данные, и одно и другое пролетает по G1.
отладчик это часть эмулятора, в публичных релизах он не вкомпилен.
с алгоритмом чексуммы тоже не просто, сега не настолько тупа, чтоб использовать стандартные алгоритмы, можно попробовать отреверсить алго из rom-test картриджей Naomi, но вероятность того, что они на столько дураки и использовали его же для защиты мала.

[cybdyn]

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

вообщемто это не самый важный вопрос. както ведь работает биос мод. а дальше с sd карты можно загрузить меню.

больше интерес как с приводом биос общается. в нэте есть какието наработки с эмулей железа или чего так ещё. но реверс (нверно) даст более точную картину. есть там кстати в этом дэбагере ловушки что бы отследить кто-там чё посылает в гдром и что тот отвечает?

[SWAT]

Половина кэша для инструкций, может быть использована нативно как RAM (есть такой режим) и в коде биоса эта функция используется, для размещения в него стэка.
MetalliC, возможно проверка биоса запускается автоматически при старте дрима, поэтому как раз первые 0x100 байт уже проверены и нет смысла прокачивать их еще раз, а вот остальное нужно прокачать. Иначе как то бессмысленно получается, ведь в регистр задается размер 2 Мб ровно, а не меньше. Это точка остановки фактически, видимо ее можно задать позже. И скорее всего так это работает только при запуске, в ином случае проверка начинается только при записи в этот регистр значения. Иначе это просто грубая дыра, которую уже давным давно бы нашли и использовали, но как ты сам выразился, да и я с этим полностью согласен, японцы далеко не дураки.