Написал документик по использованию putusb для прошивки bp.
Восстановительная прошивка: тыц
Ахтнук: без бекапа ничего не шить.
Показаны сообщения с ярлыком bp. Показать все сообщения
Показаны сообщения с ярлыком bp. Показать все сообщения
понедельник, 12 октября 2009 г.
суббота, 26 сентября 2009 г.
Сказка про линейный процессор
Пока чинил минг, узнал много интересного. В этой и последующей заметках я попытаюсь последовательно изложить эту информацию. Все изложенное ниже - жуткий баян, известно очень давно и открыто не мной.
И так, жыла-была бабка, делала деревянные телефоны, типа E398, над которыми некоторые товарищи полюбили измываться, рисуя на них маркером слово "ЗУБ", заставля эти телефоны делать разную прикольную ерунду. В телефонах был процессор Neptune LTE. Потом бабка навострилась делать тонкие телефоны, уже не из дерева, а из фанеры - всякие L7, например, и делать их на процессоре Neptune LTE2.
Еще бабка решила поделать смартфоны из кирпича, но схитрила, ибо ленивая была. Взяла кусок деревянного телефона и засунула внутрь кирпичного КПК - так появились A780. А потом сделала то же самое с фанерным - так пявились минги и едва.
Телефоны продавала не сама бабка, а старый барыга-еврей, который продавал не всякие телефоны, а со справкой и печятью. А печять была у другого барыги, который был жадный жлоп, трус и кое-какер - потому боялся, что кто-то поломает телефонные провода и будет звонить так, чтобы не платить ему деньге.
Поэтому барыга печять ставил только на такие телефоны, на которых нельзя было написать волшебное слово "ЗУБ", для чего все телефоны нужно было продавать в гондонах. А если снять его с телефона, или сделать дырку - телефон должен ломаться и не звонить. Гондоны для телефонов делал старый слепой дед и делал их фигово.
Товарищи, любившие прикольную фигню, знамо дело, нашли в гондоне дырку, сували туда маркер и стали писать слово "ЗУБ", не снимая ево с телефона, за что бабка получала от барыги по жопе.
Чтобы телефон звонил и показывал картинки, ему нужна прошивка, а чтобы хранить прошивку в телефоне, нужна флешка, которую можно читать, начинается она с адреса 0x10000000. А чтобы прошивка могла работать, ему нужна память (RAM), которыю можно быстро-бытро читать и писать, начинается она с адреса 0x14000000. Еще телефон нужно бутать и шить - для этого в телефоне есть два загрузчика - иромовый и нормальный.
Иромовый загрузчик живет внутри процессора, в памяти IROM, которую писать нельзя и которая начинается с 0x0 и юзается не обычную RAM, а свою собственную IRAM, которая начинается с 0x03F80000. Нормальный загрузчик живет в начале флеша и при работе пользуется RAM.
Как происходит обычная загрузка: при включении, управление передается по адресу 0x0 (иром).
Иром включает флешку и проверяет, есть ли на флешке бут и проверяет подпись бута, которая лежит вконце блока, в котором он прошит. Если поправить бут, то подпись не сойдется и иром уйдет в режим "бланк" - включит usb и будет ждать, пока ему по usb скажут, что делать. Суть тестпоинта: замыканием ноги, флешка выключается, иромовый бут не находит нормальный и уходит в бланк.
Если иром проверил бут, то он читает из его заголовка адрес точки входа и передает туда управление. Пример заголовка:
0000000010 00 46 F4 00 00 00 B1 00 13 02 01 FF 00 09 84
00000010 01 13 02 FF 07 00 09 84 10 00 46 FC 10 00 00 00
00000020 10 00 EF D7 10 00 4A 9C10 00 E8 00 10 00 F0 00
00000030 10 35 08 00 00 00 00 0010 08 00 00 28 63 29 20
Красным выделен адрес точки входа, синим - адрес подписи бута, зеленым - адрес прошивки. Лирическое отступление: код бутлоадера заканчивается по адресу 0x10005E10, подпись начинается с адреса 0x1000E800, между ними неиспользуема область, забитая 0xFF, в которую можно совершенно спокойно записать слово "ЗУБ".
Загрузчик с флеша запускается и начинает проверять подпись самой прошивки, для этого он читает заголовок прошивки с адреса, который написан в заголовке бута. Заголовок прошивки:
0008000010 21 EF 95 00 00 00 B1 00 13 02 06 FF FF 11 52
....
000800A0 FF FF FF FF FF FF FF FF FF FF FF FF10 33 00 00
Красным выделен адрес точки входа, зеленым - адрес заголовка подписи прошивки. Заголовок подписи прошивки:
0033000010 33 00 10 00 00 00 B1 01 13 02 06 FF FF 11 52
Красным выделен адрес начала самой подписи.
Процесс проверки просходит так: узнаем адрес прошивки, узнаем адрес блока подписи прошивки и адрес самой подписи, читаем подпись, сверяем хеш блоков, адреса которых указанны в подписи с тем, что записан в подписи. Если все хорошо - запоминаем, что этот диапазон - доверенная область.
Затем читаем адрес точки входа - если он внутри доверенной обрасти, то передаем управление туда.
Зарытых собак тут несколько.
никто не проверят, находится ли заголовок прошивки внутри доверенной области (запатчено в буте минга),
адреса блоков, которые закрывает подпись, находятся в самой подписи,
между подписываемым блоком и подписью, есть область, в которую можно безболезненно писать.
Кроме самой прошивки, в телефоне есть другие подписанные области: сам бут и CG7. И в буте и в CG7 есть области между подписью и блоком, который она закрывает.
Блок CG7 лежит по адресу 0x10350000 и начинается с подписи, которая заканчивается на 0x1035045C, но сами данные начинается с 0x10350800.
На взломанной прошивке процедура походит так:
Вместо адреса настоящей подписи, подсовывается адрес подписи другого блока (CG7 или самого бута) и вместо самой прошивки, проверяется этот блок и заносится в доверенную зону.
Вместо адреса точки входа, указывается адрес удачного куска данных в этом блоке: "E5 9F", что является тумбовой инструкцией, делающей джамп на 0x59F (59f - отрицательное число, значит джампаемся на 0x59f ^ 0x7ff = 0x260 назад) и управление передается в неподписанную область между подписью и началом блока.
В итоге загрузчик доволен собой и думает, что проверил прошивку (а проверил CG7), при чем успешно. Адрес точки входа ведет как раз в CG7, которую он проверил, а значит туда можно передвать управление. Саму прошивку никто не проверял, а значит можно там все менять.
Теперь про загрузчики и процесс обновления прошивки.
Оба загрузчика (иромовый и нормальный) имеют набор комманд, которые можно выполнять через usb. Основные три: ADDR, BIN и JUMP. ADDR указывает адрес, на который нужно положить данные, BIN шлет сами данные, JUMP передает на них управление. В качестве данных выступает так называемый "лоадер" - программа, которая умеет шить флеш. Ее подпись тоже проверяется и она позволяет стирать, шить и читать только узкий диапазон адресов (нельзя заменить бут и pds).
В иромовом буте есть тупая дыра (срыв стека), через которую можно запустить любой код, например лоадер "ramldr2", который позволяет читать и писать любые адреса. Но иромвый бут запускается только тогда, когда не видит бут на флеше (или AP криво уходит в слип).
Про PDS. pds - область в телефоне, которая не меняется при его прошивке и лежит по адресам 0x10010000 и 0x10020000 (да, два раза - одна рабочая, вторая - запасная). В начале pds записана версия, которая меняется от прошивки к прошивке (в E2 - 4015, в A1200 - 4017). PDS разбит на нумерованые файлы, некоторые из которых зашифрованы уникальным ключем телефона. К закриптованным файлам относятся разные блокировки, например привязка к сети определенного оператора. Из-за этих криптованных файлов нельзя заливать PDS от одного телефона в другой.
Именно из-за PDS у меня и произошла вся эта история: прошивка E2 поменяла его версию и стерла зашифрованные файлы. Пришлось отрывать расшифровывалке руки, чтобы она не выдергивалась.
Еще в телефоне есть зона, в которую пишутся паники. Лежит по адресу 0x10030000.
ps. Свой ремонтный набор я скоро приведу в нормальный вид и выложу.
И так, жыла-была бабка, делала деревянные телефоны, типа E398, над которыми некоторые товарищи полюбили измываться, рисуя на них маркером слово "ЗУБ", заставля эти телефоны делать разную прикольную ерунду. В телефонах был процессор Neptune LTE. Потом бабка навострилась делать тонкие телефоны, уже не из дерева, а из фанеры - всякие L7, например, и делать их на процессоре Neptune LTE2.
Еще бабка решила поделать смартфоны из кирпича, но схитрила, ибо ленивая была. Взяла кусок деревянного телефона и засунула внутрь кирпичного КПК - так появились A780. А потом сделала то же самое с фанерным - так пявились минги и едва.
Телефоны продавала не сама бабка, а старый барыга-еврей, который продавал не всякие телефоны, а со справкой и печятью. А печять была у другого барыги, который был жадный жлоп, трус и кое-какер - потому боялся, что кто-то поломает телефонные провода и будет звонить так, чтобы не платить ему деньге.
Поэтому барыга печять ставил только на такие телефоны, на которых нельзя было написать волшебное слово "ЗУБ", для чего все телефоны нужно было продавать в гондонах. А если снять его с телефона, или сделать дырку - телефон должен ломаться и не звонить. Гондоны для телефонов делал старый слепой дед и делал их фигово.
Товарищи, любившие прикольную фигню, знамо дело, нашли в гондоне дырку, сували туда маркер и стали писать слово "ЗУБ", не снимая ево с телефона, за что бабка получала от барыги по жопе.
Чтобы телефон звонил и показывал картинки, ему нужна прошивка, а чтобы хранить прошивку в телефоне, нужна флешка, которую можно читать, начинается она с адреса 0x10000000. А чтобы прошивка могла работать, ему нужна память (RAM), которыю можно быстро-бытро читать и писать, начинается она с адреса 0x14000000. Еще телефон нужно бутать и шить - для этого в телефоне есть два загрузчика - иромовый и нормальный.
Иромовый загрузчик живет внутри процессора, в памяти IROM, которую писать нельзя и которая начинается с 0x0 и юзается не обычную RAM, а свою собственную IRAM, которая начинается с 0x03F80000. Нормальный загрузчик живет в начале флеша и при работе пользуется RAM.
Как происходит обычная загрузка: при включении, управление передается по адресу 0x0 (иром).
Иром включает флешку и проверяет, есть ли на флешке бут и проверяет подпись бута, которая лежит вконце блока, в котором он прошит. Если поправить бут, то подпись не сойдется и иром уйдет в режим "бланк" - включит usb и будет ждать, пока ему по usb скажут, что делать. Суть тестпоинта: замыканием ноги, флешка выключается, иромовый бут не находит нормальный и уходит в бланк.
Если иром проверил бут, то он читает из его заголовка адрес точки входа и передает туда управление. Пример заголовка:
00000000
00000010 01 13 02 FF 07 00 09 84 10 00 46 FC 10 00 00 00
00000020 10 00 EF D7 10 00 4A 9C
00000030 10 35 08 00 00 00 00 00
Красным выделен адрес точки входа, синим - адрес подписи бута, зеленым - адрес прошивки. Лирическое отступление: код бутлоадера заканчивается по адресу 0x10005E10, подпись начинается с адреса 0x1000E800, между ними неиспользуема область, забитая 0xFF, в которую можно совершенно спокойно записать слово "ЗУБ".
Загрузчик с флеша запускается и начинает проверять подпись самой прошивки, для этого он читает заголовок прошивки с адреса, который написан в заголовке бута. Заголовок прошивки:
00080000
....
000800A0 FF FF FF FF FF FF FF FF FF FF FF FF
Красным выделен адрес точки входа, зеленым - адрес заголовка подписи прошивки. Заголовок подписи прошивки:
00330000
Красным выделен адрес начала самой подписи.
Процесс проверки просходит так: узнаем адрес прошивки, узнаем адрес блока подписи прошивки и адрес самой подписи, читаем подпись, сверяем хеш блоков, адреса которых указанны в подписи с тем, что записан в подписи. Если все хорошо - запоминаем, что этот диапазон - доверенная область.
Затем читаем адрес точки входа - если он внутри доверенной обрасти, то передаем управление туда.
Зарытых собак тут несколько.
никто не проверят, находится ли заголовок прошивки внутри доверенной области (запатчено в буте минга),
адреса блоков, которые закрывает подпись, находятся в самой подписи,
между подписываемым блоком и подписью, есть область, в которую можно безболезненно писать.
Кроме самой прошивки, в телефоне есть другие подписанные области: сам бут и CG7. И в буте и в CG7 есть области между подписью и блоком, который она закрывает.
Блок CG7 лежит по адресу 0x10350000 и начинается с подписи, которая заканчивается на 0x1035045C, но сами данные начинается с 0x10350800.
На взломанной прошивке процедура походит так:
Вместо адреса настоящей подписи, подсовывается адрес подписи другого блока (CG7 или самого бута) и вместо самой прошивки, проверяется этот блок и заносится в доверенную зону.
Вместо адреса точки входа, указывается адрес удачного куска данных в этом блоке: "E5 9F", что является тумбовой инструкцией, делающей джамп на 0x59F (59f - отрицательное число, значит джампаемся на 0x59f ^ 0x7ff = 0x260 назад) и управление передается в неподписанную область между подписью и началом блока.
В итоге загрузчик доволен собой и думает, что проверил прошивку (а проверил CG7), при чем успешно. Адрес точки входа ведет как раз в CG7, которую он проверил, а значит туда можно передвать управление. Саму прошивку никто не проверял, а значит можно там все менять.
Теперь про загрузчики и процесс обновления прошивки.
Оба загрузчика (иромовый и нормальный) имеют набор комманд, которые можно выполнять через usb. Основные три: ADDR, BIN и JUMP. ADDR указывает адрес, на который нужно положить данные, BIN шлет сами данные, JUMP передает на них управление. В качестве данных выступает так называемый "лоадер" - программа, которая умеет шить флеш. Ее подпись тоже проверяется и она позволяет стирать, шить и читать только узкий диапазон адресов (нельзя заменить бут и pds).
В иромовом буте есть тупая дыра (срыв стека), через которую можно запустить любой код, например лоадер "ramldr2", который позволяет читать и писать любые адреса. Но иромвый бут запускается только тогда, когда не видит бут на флеше (или AP криво уходит в слип).
Про PDS. pds - область в телефоне, которая не меняется при его прошивке и лежит по адресам 0x10010000 и 0x10020000 (да, два раза - одна рабочая, вторая - запасная). В начале pds записана версия, которая меняется от прошивки к прошивке (в E2 - 4015, в A1200 - 4017). PDS разбит на нумерованые файлы, некоторые из которых зашифрованы уникальным ключем телефона. К закриптованным файлам относятся разные блокировки, например привязка к сети определенного оператора. Из-за этих криптованных файлов нельзя заливать PDS от одного телефона в другой.
Именно из-за PDS у меня и произошла вся эта история: прошивка E2 поменяла его версию и стерла зашифрованные файлы. Пришлось отрывать расшифровывалке руки, чтобы она не выдергивалась.
Еще в телефоне есть зона, в которую пишутся паники. Лежит по адресу 0x10030000.
ps. Свой ремонтный набор я скоро приведу в нормальный вид и выложу.
пятница, 25 сентября 2009 г.
вторник, 22 сентября 2009 г.
Обход RSA в BP минга
Пришлось запихнуть туда CG7 из E2 и понизить бут - тоже от E2.
CG1 (начало 0x10080000)
по оффсету 0x00 (0x10080000) точка входа в прошивку меняется на адрес
"удачных" данных в CG7 +1: 10350911
по оффсету 0x10 (0x10080010)- флаг B001FFFB
CG7 (0x10350000)
по оффсету 0x20910 (0x10350910) должно быть E5 9F C0 00 (джамп)
по оффсету 0x452 (0x10350452) помещается волшебный джамп:
48 01 68 00 47 00 10 04 00 00
CG18 (0x10330000)
по оффсету 0x0 (0x10330000) помещается адрес начала CG7: 0x10350000
это провоцирует бут проверять CG7 вместо CG1
Нужно понижать бут, так что делается только через TP. Как всегда, спасибо Vilko
ps. а теперь мерзкая прошивка ругается, что я понизил бут и все равно не грузится.
CG1 (начало 0x10080000)
по оффсету 0x00 (0x10080000) точка входа в прошивку меняется на адрес
"удачных" данных в CG7 +1: 10350911
по оффсету 0x10 (0x10080010)- флаг B001FFFB
CG7 (0x10350000)
по оффсету 0x20910 (0x10350910) должно быть E5 9F C0 00 (джамп)
по оффсету 0x452 (0x10350452) помещается волшебный джамп:
48 01 68 00 47 00 10 04 00 00
CG18 (0x10330000)
по оффсету 0x0 (0x10330000) помещается адрес начала CG7: 0x10350000
это провоцирует бут проверять CG7 вместо CG1
Нужно понижать бут, так что делается только через TP. Как всегда, спасибо Vilko
ps. а теперь мерзкая прошивка ругается, что я понизил бут и все равно не грузится.
воскресенье, 20 сентября 2009 г.
Чтение-запись флеша BP
вторник, 1 сентября 2009 г.
пятница, 21 августа 2009 г.
Про минг
Флеш не мертвый, флеш живой, с pds тоже все вроде бы в порядке. Дамп сделал.
Бороться с ramldr2, который стирает, но не пишет - пока не осиливаю.
Бороться с ramldr2, который стирает, но не пишет - пока не осиливаю.
воскресенье, 16 августа 2009 г.
чуть про магиксы, bp и что с ними делать :)
в общем и если кому интересно: на magx bp можно обойти подпись.. развлекаюсь этим третий день, поменял imei на телефоне, до субсиди пока не добрался, был занят на работе..
идея - если кто решит следовать - такая, вырубаем подпись ап - это давно уже сделано, грузим свой бут, дальше - есть в исходниках что мото изволила нам подарить.. sdma - в ядре кое что есть.
профит: локов не боимся, т.к. умеем писать шифрованные симы, да и вообще что угодно, pds вообще не боимся..
идея - если кто решит следовать - такая, вырубаем подпись ап - это давно уже сделано, грузим свой бут, дальше - есть в исходниках что мото изволила нам подарить.. sdma - в ядре кое что есть.
профит: локов не боимся, т.к. умеем писать шифрованные симы, да и вообще что угодно, pds вообще не боимся..
вторник, 11 августа 2009 г.
BUSTED!
И шо вы таки думаете? Во всем виноваты виндузятники:
Вобщем BP после саспенда работает. Осталась всякая ерунда и будет щасте.
Если кратко - таймауты и последовательность инициализации в hub.c все решили.
/*
* As of 2.6.10 we introduce a new USB device initialization scheme which
* closely resembles the way Windows works. Hopefully it will be compatible
* with a wider range of devices than the old scheme. However some previously
* working devices may start giving rise to "device not accepting address"
* errors; if that happens the user can try the old scheme by adjusting the
* following module parameters.
*
* For maximum flexibility there are two boolean parameters to control the
* hub driver's behavior. On the first initialization attempt, if the
* "old_scheme_first" parameter is set then the old scheme will be used,
* otherwise the new scheme is used. If that fails and "use_both_schemes"
* is set, then the driver will make another attempt, using the other scheme.
*/
Вобщем BP после саспенда работает. Осталась всякая ерунда и будет щасте.
Если кратко - таймауты и последовательность инициализации в hub.c все решили.
воскресенье, 9 августа 2009 г.
Магия линейного процессора
Кино и немцы: бутаем телефон, проходим хендшейк по gpio, девайс опознается на usb шине, как 0x3006 (драйвер ipc), на одном из интерфейсов которого есть ендпоинты для передачи и получения данных по ipc. Далее слипаю usb девайс (контроллер перестает посылать ему какие-то там периодические сообщения), bp это видит и со своей стороны тоже слипается, слипаю usb порт и ухожу в саспенд ap.
Врубаю обратно, usb не трогаю, вместо этого перевожу bp в флешмод (ставлю ногу flash в 1 и делаю ресет), прохожу хендшейк по gpio. Вот теперь включаю порт и девайс - драйвер usb контроллера замечает, что устройство изменилось во время слипа и опознает новое (0x4003).
А тепер без перевода в режим флеша. Бутаем телефон, проходим хендшейк, девайс опознается, саспендим usb девайс, саспендим usb порт, саспендим ap. Просыпаемся, врубаем порт, врубаем девайс - ДЕВАЙС ТУПИТ и не отвечает на контрольные запросы, но при этом моргает ногой (ааа! включите меня!) и потом валится в панику.
А теперь третий фокус:
Делаем все то же самое, что и в первом случае, но ресет bp делаем без перевода в флешмод - девайс проходит хендшейк, но по usb опять не отвечает.
Рабочая гипотеза - bp не замечает, что надо ресетнуть usb со своей стороны. Чисто теоретически, это должно делаться через single-ended zero - установку двух ног usb в 0 на 10 msec, но это не работает (или я неправильно делаю?), и ничего похожего я в старом ядре не вижу. Зато в старом ядре есть куча непонятной возни вокруг ног 90, 91 и 113 - те пины usb, что идут от хоста к устройству.
Врубаю обратно, usb не трогаю, вместо этого перевожу bp в флешмод (ставлю ногу flash в 1 и делаю ресет), прохожу хендшейк по gpio. Вот теперь включаю порт и девайс - драйвер usb контроллера замечает, что устройство изменилось во время слипа и опознает новое (0x4003).
[ 20.911537] flash: 0
[ 20.920759] flash: 512
[ 20.927860] reset bp
[ 20.934154] bp handshake entered!
[ 20.941279] ezx-bp: handshake step 1
[ 20.948080] ezx-bp: handshake step 2
[ 21.240547] BP rdy irq
[ 43.045223] usb 1-3: reset full speed USB device using pxa27x-ohci and address 5
[ 43.266384] usb 1-3: device firmware changed
[ 43.271897] usb 1-3: USB disconnect, address 5
[ 43.465206] usb 1-3: new full speed USB device using pxa27x-ohci and address 6
[ 43.697291] usb 1-3: configuration #1 chosen from 1 choice
А тепер без перевода в режим флеша. Бутаем телефон, проходим хендшейк, девайс опознается, саспендим usb девайс, саспендим usb порт, саспендим ap. Просыпаемся, врубаем порт, врубаем девайс - ДЕВАЙС ТУПИТ и не отвечает на контрольные запросы, но при этом моргает ногой (ааа! включите меня!) и потом валится в панику.
[ 25.704865] usb 1-3: reset full speed USB device using pxa27x-ohci and address 5
[ 25.718791] BP rdy irq
[ 25.838537] usb 1-3: USB disconnect, address 5
[ 26.194880] usb 1-3: new full speed USB device using pxa27x-ohci and address 6
[ 35.436193] BP rdy irq
[ 35.441631] BP Lowered WDI line. This is not good :(
[ 41.384807] usb 1-3: device descriptor read/64, error -110
[ 41.684849] usb 1-3: device descriptor read/64, error -62
[ 41.974861] usb 1-3: new full speed USB device using pxa27x-ohci and address 7
[ 42.164846] usb 1-3: device descriptor read/64, error -62
[ 42.454801] usb 1-3: device descriptor read/64, error -62
[ 42.744881] usb 1-3: new full speed USB device using pxa27x-ohci and address 8
[ 43.174716] usb 1-3: device not accepting address 8, error -62
[ 43.364761] usb 1-3: new full speed USB device using pxa27x-ohci and address 9
[ 43.794714] usb 1-3: device not accepting address 9, error -62
[ 43.805893] hub 1-0:1.0: unable to enumerate USB device on port 3
А теперь третий фокус:
Делаем все то же самое, что и в первом случае, но ресет bp делаем без перевода в флешмод - девайс проходит хендшейк, но по usb опять не отвечает.
Рабочая гипотеза - bp не замечает, что надо ресетнуть usb со своей стороны. Чисто теоретически, это должно делаться через single-ended zero - установку двух ног usb в 0 на 10 msec, но это не работает (или я неправильно делаю?), и ничего похожего я в старом ядре не вижу. Зато в старом ядре есть куча непонятной возни вокруг ног 90, 91 и 113 - те пины usb, что идут от хоста к устройству.
понедельник, 3 августа 2009 г.
Вроде живое
Не шейте на минг бп от E2. Ничего хорошего из этого не получилось - в бут попадаю только через тп.
За полтора года первый раз разбирал аппарат. Мерзость проведения тп в припаянных защитных кожухах на микросхемах (на картинке видны его контуры) - еле отцепил.
За полтора года первый раз разбирал аппарат. Мерзость проведения тп в припаянных защитных кожухах на микросхемах (на картинке видны его контуры) - еле отцепил.
пятница, 31 июля 2009 г.
Внезапный тестпоинт?
Проводил опыты с саспендом usb хоста. Единственное, что понял - система там очень хлипкая, зависит от кучи рейскондишинов и последовательности включения/выключения usb хоста и просыпания/засыпания bp.
И еще словил вот такой замечательный фокус:
То есть bp ВНЕЗАПНО перезагрузился и его бут подумал, что флешка чистая, предлагая его шить с ap. Повторить не удалось - все остальные разы bp не хотел подключаться после резюма. На всякий случай - лог этого безобразия: http://pastebin.com/f33b62daa
UPD: опять вылезло. видимо, это не случайный глюк, а закономерный баг. А я был почти уверен, что в этот раз получу обратно модем.
UPD2: и опять...
И еще словил вот такой замечательный фокус:
[ 8.480980] pxa27x-ohci pxa27x-ohci: GetStatus roothub.portstatus [2] = 0x00130103 PRSC PESC CSC PPS PES CCS
[ 8.493472] hub 1-0:1.0: unable to enumerate USB device on port 3
[ 8.505488] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0008
[ 8.517448] pxa27x-ohci pxa27x-ohci: GetStatus roothub.portstatus [2] = 0x00030101 PESC CSC PPS CCS
[ 8.529480] hub 1-0:1.0: port 3, status 0101, change 0003, 12 Mb/s
[ 8.699736] hub 1-0:1.0: debounce: port 3: total 100ms stable 100ms status 0x101
[ 8.829765] pxa27x-ohci pxa27x-ohci: GetStatus roothub.portstatus [2] = 0x00100103 PRSC PPS PES CCS
[ 8.899751] usb 1-3: new full speed USB device using pxa27x-ohci and address 6
[ 9.029666] pxa27x-ohci pxa27x-ohci: GetStatus roothub.portstatus [2] = 0x00100103 PRSC PPS PES CCS
[ 9.129612] usb 1-3: ep0 maxpacket = 8
[ 9.142082] usb 1-3: default language 0x0409
[ 9.151041] usb 1-3: udev 6, busnum 1, minor = 5
[ 9.156380] usb 1-3: New USB device found, idVendor=22b8, idProduct=4903
[ 9.167987] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 9.180013] usb 1-3: Product: S Blank Neptune LTE2
[ 9.185511] usb 1-3: Manufacturer: Motorola
[ 9.192990] usb 1-3: uevent
[ 9.215618] usb 1-3: usb_probe_device
[ 9.222460] usb 1-3: configuration #1 chosen from 1 choice
[ 9.249015] usb 1-3: adding 1-3:1.0 (config #1, interface 0)
[ 9.262191] usb 1-3:1.0: uevent
[ 9.289933] usbserial_generic 1-3:1.0: usb_probe_interface
[ 9.302780] usbserial_generic 1-3:1.0: usb_probe_interface - got id
[ 9.340334] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0008
[ 32.936371] rdy: 1
То есть bp ВНЕЗАПНО перезагрузился и его бут подумал, что флешка чистая, предлагая его шить с ap. Повторить не удалось - все остальные разы bp не хотел подключаться после резюма. На всякий случай - лог этого безобразия: http://pastebin.com/f33b62daa
UPD: опять вылезло. видимо, это не случайный глюк, а закономерный баг. А я был почти уверен, что в этот раз получу обратно модем.
UPD2: и опять...
вторник, 28 июля 2009 г.
Не верь глазам своим: магии не существует
Я все-таки нашел, почему BP не хотел идти спать.
Небольшая предыстория: в телефоне есть два проца AP и BP.
На ap имеем линупс, на bp имеем vrtx. Если кто не в курсе, bp - это LTE2 Neptune (arm7tdmi), огрызок старой платформы, отвечающий за GSM.
У процессоров есть два способа общения: первый - ноги gpio, их пять штук ( bp_rdy, ap_rdy, reset, flash и bp_wdi ), второй - usb.
По usb они гоняют данные, по ap_rdy и bp_rdy они при буте делаеют хендшейк (это их первое назначение). Когда bp что-то хочет от ap, он делает вот такой фокус:
смотрит, не спит ли ap, если спит, то:
ставит bp_rdy в 0, ждет чуть-чуть, ставит bp_rdy в 1 и опять смотрит.
Так до тех пор, пока AP не включится сам и не включит usb.
На это дело (мигание ноги bp_rdy) срабатывает прерывание и ap смотрит, чо там хочет этот убогий.
Если же ap что-то хочет от bp, он просто шлет по usb данные.
Дальше начинается самое интересное: когда ap хочет, чтобы bp ушел спать (сам ap не идет спать, пока bp не спит), он просто саспендит usb порт.
Если bp видит, что ap потормозил порт, но сам он еще имеет чего слать туда, то он саспендит порт, но при этом не саспендится сам, а один раз передергивает bp_rdy.
Когда ap видит, что bp дергает bp_rdy, он шлет по usb запрос на передачу.
Когда ap хочет что-то послать bp (например запрос на передачу), то сначала смотрит не спит ли bp если спит, то он передергивает ap_rdy, а потом уже врубает порт.
Что собственно происходило такого нехорошего и заставляло думать, будто bp не идет спать:
саспендим порт и видим, что дергается bp_rdy. BP не разрешает слип, думаю я.
BP не может отменять слип
BP не отменяет слип
BP совершенно незачем отменять слип
BP тупо пошел и слипнулся, как ему и сказали
...и поставил ногу bp_rdy в нуль.
А какой-то нехороший человек перепутал направление интеррапт лайна и генерит прерывание по переходу 1->0 (надо по 0->1, как в 2.4). В итоге ap думает, что bp отменило слип и врубает порт обратно. AP смотрит, что оно проснулося и спрашивает "нучо?". Тот молчит, потомучто нечего ему слать - он разрешил слип AP, сам тоже пошел спать, а тут к нему пристали.
Естественно, что после изменения типа ноги с IRQ_FALLING_EDGE на IRQ_RISING_EDGE все благополучно прошло.
UPD:... но ap он слипаться все равно не разрешает.
UPD: дергает ap из слипа через раз. ГРР
Небольшая предыстория: в телефоне есть два проца AP и BP.
На ap имеем линупс, на bp имеем vrtx. Если кто не в курсе, bp - это LTE2 Neptune (arm7tdmi), огрызок старой платформы, отвечающий за GSM.
У процессоров есть два способа общения: первый - ноги gpio, их пять штук ( bp_rdy, ap_rdy, reset, flash и bp_wdi ), второй - usb.
По usb они гоняют данные, по ap_rdy и bp_rdy они при буте делаеют хендшейк (это их первое назначение). Когда bp что-то хочет от ap, он делает вот такой фокус:
смотрит, не спит ли ap, если спит, то:
ставит bp_rdy в 0, ждет чуть-чуть, ставит bp_rdy в 1 и опять смотрит.
Так до тех пор, пока AP не включится сам и не включит usb.
На это дело (мигание ноги bp_rdy) срабатывает прерывание и ap смотрит, чо там хочет этот убогий.
Если же ap что-то хочет от bp, он просто шлет по usb данные.
Дальше начинается самое интересное: когда ap хочет, чтобы bp ушел спать (сам ap не идет спать, пока bp не спит), он просто саспендит usb порт.
Если bp видит, что ap потормозил порт, но сам он еще имеет чего слать туда, то он саспендит порт, но при этом не саспендится сам, а один раз передергивает bp_rdy.
Когда ap видит, что bp дергает bp_rdy, он шлет по usb запрос на передачу.
Когда ap хочет что-то послать bp (например запрос на передачу), то сначала смотрит не спит ли bp если спит, то он передергивает ap_rdy, а потом уже врубает порт.
Что собственно происходило такого нехорошего и заставляло думать, будто bp не идет спать:
саспендим порт и видим, что дергается bp_rdy. BP не разрешает слип, думаю я.
BP не может отменять слип
BP не отменяет слип
BP совершенно незачем отменять слип
BP тупо пошел и слипнулся, как ему и сказали
...и поставил ногу bp_rdy в нуль.
А какой-то нехороший человек перепутал направление интеррапт лайна и генерит прерывание по переходу 1->0 (надо по 0->1, как в 2.4). В итоге ap думает, что bp отменило слип и врубает порт обратно. AP смотрит, что оно проснулося и спрашивает "нучо?". Тот молчит, потомучто нечего ему слать - он разрешил слип AP, сам тоже пошел спать, а тут к нему пристали.
Естественно, что после изменения типа ноги с IRQ_FALLING_EDGE на IRQ_RISING_EDGE все благополучно прошло.
UPD:... но ap он слипаться все равно не разрешает.
UPD: дергает ap из слипа через раз. ГРР
четверг, 23 июля 2009 г.
Новости
В гите openezx традиционно все сломано. Первая вещь, которая перестала работать (тоже традиционно) - звук... шучу. Звук работает, но интерфейс микшера поменяли и кутопию надо патчить или лезть в alsamixer.
Что хуже - в ванильном ядре что-то такое опять сделали, что BP перестал работать вообще. При чем в самый интересный момент, когда я собрался с мыслями и сделал нормальный невелосипедный субдрайвер для usb-serial. Что там такое произошло - фиг его знает, но надо лезть и разбираться. Последний рабочий коммит - 0533a7bcf9a07863a145c6463985d561be76ef56.
Что еще хуже - даже до поломки BP все равно не хотел уходить в слип, так что я сейчас постепенно пробираюсь в его недра и буду его жестоко мучить, чтобы выяснить, почему именно он дает запрет.
Первые результаты этого вандализма - патч к boot_usb для чтения памяти (флеша) BP. Как оказалось, там все плохо: родной загрузчик проверяет подписи того что пишут (это патчится), того что запускают (это ломается на лету) и не дает возможности читать и писать произвольные адреса и объемы данных.
Читать он дает только флеш BP, да и то не весь (зону PDS не дает), а писать - только определенные кодовые группы, при чем целиком. Придется делать как на EZX и запускать из-под родного бута кастомный (олдскульных мотохакеров с мотофана), при чем запускать через дыру, чем я сейчас и занимаюсь.
Что хуже - в ванильном ядре что-то такое опять сделали, что BP перестал работать вообще. При чем в самый интересный момент, когда я собрался с мыслями и сделал нормальный невелосипедный субдрайвер для usb-serial. Что там такое произошло - фиг его знает, но надо лезть и разбираться. Последний рабочий коммит - 0533a7bcf9a07863a145c6463985d561be76ef56.
Что еще хуже - даже до поломки BP все равно не хотел уходить в слип, так что я сейчас постепенно пробираюсь в его недра и буду его жестоко мучить, чтобы выяснить, почему именно он дает запрет.
Первые результаты этого вандализма - патч к boot_usb для чтения памяти (флеша) BP. Как оказалось, там все плохо: родной загрузчик проверяет подписи того что пишут (это патчится), того что запускают (это ломается на лету) и не дает возможности читать и писать произвольные адреса и объемы данных.
Читать он дает только флеш BP, да и то не весь (зону PDS не дает), а писать - только определенные кодовые группы, при чем целиком. Придется делать как на EZX и запускать из-под родного бута кастомный (олдскульных мотохакеров с мотофана), при чем запускать через дыру, чем я сейчас и занимаюсь.
воскресенье, 24 мая 2009 г.
Двухпроцессорная архитектура EZX
Как известно, в телефонах серии ezx - два CPU с разными операционными системами. Тот что ближе к пользователю и отвечает за красивый графический интерфейс на современной библиотеке qt2 embedded - Intel PXA270, работающий под управлением сами знаете чего. Тот что спрятан в недрах и ближе к GSM сети - огрызок старой платформы (всяких E398, L7 и др.) - Neptune LTE2.
Поскольку общей памяти они не имеют (в отличии от SCM-A на багиксе или MSM в HTC), то данными они обмениваются по самому обычному USB. В качестве хоста выступает AP (pxa270), в качестве устройства - BP (LTE2). Архитектурно это больше всего похоже на кпк (например ipaq), к которому по usb прицепили какой-нибудь E398.
В очень-очень старых моделях, которые никто никогда не видел и в руках не держал, вместо USB был RS232, который наверное любил терять данные по дороге. Что делают хорошие корпоративные программисты, когда железо глючит? Пишут костыли, куда они денутся. USB такого безобразия не допускает и сам следит за корректностью данных, но костыли конечно же оставили.
продолжение следует
Поскольку общей памяти они не имеют (в отличии от SCM-A на багиксе или MSM в HTC), то данными они обмениваются по самому обычному USB. В качестве хоста выступает AP (pxa270), в качестве устройства - BP (LTE2). Архитектурно это больше всего похоже на кпк (например ipaq), к которому по usb прицепили какой-нибудь E398.
В очень-очень старых моделях, которые никто никогда не видел и в руках не держал, вместо USB был RS232, который наверное любил терять данные по дороге. Что делают хорошие корпоративные программисты, когда железо глючит? Пишут костыли, куда они денутся. USB такого безобразия не допускает и сам следит за корректностью данных, но костыли конечно же оставили.
продолжение следует
Подписаться на:
Сообщения (Atom)