Версия для печати темы

Автор: BigMike 15.11.2007, 0:02

В приложении роверовский XIP (любезно выковырянный k0ster'ом) и утилиты для ковыряния.
При распаковке этого XIP сталкиваюсь с проблемой: не могу построить карту (write map). Обращался к k0ster'у - у того карта строится.
Попробуйте, строится ли карта у вас?

Автор: Winterice 15.11.2007, 9:41

нет не строится вылетает ошибка, полное описание из дебугера

может поможет
спроси k0sterа какие системные коммпаненты стоят их версии впервую очереь netframework какой думаю просто не хватает системных бибиотек

Автор: BigMike 15.11.2007, 13:06

Как и у меня.
Ладно, буду пытать костера...
Что интересно - не строится карта только для наших прошивок (перепробовал уже все, включая все WM6). Для XIP профета, например, строится нормально.

Автор: BigMike 17.11.2007, 10:50

Дело сдвинулось с мертвой точки. Возможно, потому что скачал 3-й дотнет, то ли просто нашел наконец способ.
Короче, у меня теперь строится карта, если перед ее построением сделать Realloc.
Теперь все становится гораздо интереснее

Автор: alex_beda 17.11.2007, 11:43

Ну наконец то у кого то хоть что то сдвинулось.
Многое может проясниться.

Автор: BigMike 17.11.2007, 17:38

[attachment=18:XIPPORT_patched.zip]Новости с полей ковыряния XIP.
Как выясняется, стандартный xipport почему-то некорректно работает с нашими прошивками. Ниже приложил патченный - он уже корректно распаковывает и даже собирает почти без ошибок (хотя WinHEX все равно находит различающиеся блоки при просто распаковке-запаковке)...

Автор: alex_beda 18.11.2007, 9:30

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

Автор: BigMike 18.11.2007, 23:42

Дык то, что он меньше - это как раз нормально
Конец оригинального забит FF, в новом этого нет. При портировании недостающие байты добиваются FF.

Та версия xipport один фиг работает некорректно. Jiggs с xda-developers поделился еще более свежим xipport, который должен работать.
Пока нет времени проверить - поэтому выкладываю так.

Автор: Winterice 19.11.2007, 11:47

Короче данный хиппорт нормально извлекает и строит (на примере выще выложенного роверовского хипа), но не получается выдрать хип из существующих прошивок, что из атом что пытался из Геральда вытащить (нахожу начало и конец xip в файлах прошивки Disk_img.nb0 для атома и nk.nba для геральда копирую в новый файл) запускаю хиппорт извлекается только nk.exe ну и соответствееноо не карты нестроятся ниче. может кто знает в чем проблема?
Малость изменения выдрал xip их подопытного геральда
Все вопрос по разбору вроде решил, разобрался с началом и концом секции хип в атомовской прошивке

Автор: BigMike 19.11.2007, 23:30

Некоторые девайсы имеют два xip.
Первый действительно содержит только nk.exe

Я же дал точные адреса в топике "структура прошивок". Что ты еще искал?

Автор: AGC 24.12.2007, 8:53

Что то здесь давно не было сообщений Никто не поделится результатами, удалось ли пересобрать XIP?

Просто начал разбираться с XIP от ATOM и RW6815. Может информация уже и не очень актуальная, но напрямую ни в этой ни в соседней ветке четко выраженной не видел...

1. В XIP1 лежит первая часть nk.exe. Если менять его в ATOM-вской прошивке, то вроде бы нужно менять и первую часть... (???)

2. Дополнительные ссылки по смысловой части ядра:
http://msdn2.microsoft.com/en-us/library/aa908987.aspx
http://msdn2.microsoft.com/en-us/library/ms892238.aspx
ну и далее там по ссылкам.

В общем, xip-ы разобрал... Сейчас пытаюсь осмыслить инструкцию по reloc-у... И вообще разобраться с распределением памяти...

P.S. Метод грубой силы не прошел, после тупой замены без нормального релока коммуникатор не грузился
---
Пока текущий максимальный результат - доходит до надписи сброса в значения по умолчанию. Потом висит. Это после переноса ядра из ATOM в RW6815...

Автор: AGC 26.12.2007, 13:32

Удалось достигнуть некоторых результатов с RW6815 на почве пересборки XIP. Сейчас попробую несколькими сообщениями их изложить

По поводу XIP1 и nk.exe, похоже, что (цитата):

"Насчет nk.exe в универсале. Читай про процесс загрузки WM5 и структуру образа (DIO файла). Таблица в DIO идентична по формату с MBR в жестких дисках (сам можешь увидеть байты 55 AA в конце первого сектора, последующий после MBR сектор можно еще найти по строке MSFLSH50). В MBR может находиться до 4 разделов. Первый - image update loader (формат практически идентичен РОМам 2005 вынды, потому его понимает dumprom), там тоже находится своя копия nk.exe и куча других файлов, так сказать мини-ОС. Второй - уже загрузчик основной OS (формат тот же), там тоже находится nk.exe, но уже та копия, которая используется при обычной работе системы. Третий - IMGFS. Четвертый, необязательный - FAT партиция, которая может использоваться под persistent storage, хранение скажем radio ROM, или вообще не использоваться - это оставлено на совесть разработчика (в универсале не используется).
Первые 2 раздела могут быть не запакованы, в этом случае их очень удобно патчить на предмет отучения от сертификатов. Но могут быть и запакованы, и таких девайсов становится все больше."

взято: http://forum.wce.by/viewtopic.php?t=6750

В общем, пока не совсем ясно, нужно ли менять эту часть (XIP1), если собирать прошивку на своем родном ядре.

Автор: AGC 26.12.2007, 13:51

2. В результате изучения XIP удалось поднять прошивку ATOM_EXEC_TFED_RC3_PP8MB (http://forum.xda-developers.com/showthread.php?t=352622) для RW6815. Они там в последних версиях намудрили с оптимизацией памяти, в результате на оригинальной версии камера у меня не работала (запускалась, но висла при выполнении любых операций). Впрочем, судя по форуму там были проблемы и на самом ATOM EXEC с камерой и рядом других модулей. Сейчас пересобрал XIP, вроде бы все работает.

Что было сделано - восстановлено оригинальное распределение памяти (собственно это там на форуме и упоминалось).

Было в новой прошивке:

Правильное распределение (от WM5, так понимаю, с учетом выброса hd.dll и osax...dll):


Восстанавливается, самое простое, копированием папок nk.exe и giisr.dll из разобранного XIP "правильной" прошивки (например, ATOM_EXEC_WM607AWWE_20071117A1WWE_8MBPP).
Далее:
1. realoc'P
2. write maps
3. проверяем на всякий случай MAP.txt (адреса nk.exe и giisr.dll - vbase и realadr)
4. build xip_out.bin
5. Правим ниже адрес записи на 00180000, имя файла прошивки типа diskimage_Ver.nb0
6. write xip_out.bin to

Все.

Собранный XIP для ATOM EXEC 5.2.1948: http://forum.pda2u.ru/forum/index.php?s=&showtopic=41&view=findpost&p=629

Автор: AGC 26.12.2007, 14:16

3. Удалось пересобрать XIP чистого ATOM так, что теперь на RW6815 камера работает! Собственно, после долгих мытарств с портированием ядра RW6815 (напишу дальше) и возней с прошивками ATOM EXEC, ну и т.д. пришел к простому заключению, что нужно сдвинуть ядро ATOM на "правильные" адреса RW6815 (которые совпадают для nk и giisr с ATOM EXEC). Это и было проделано:

3.1. Оригинальное распределение памяти на ATOM:

3.2. Оригинальное распределение памяти на RW6815:


3.4. Нужна утилита M'Reloc_nk (http://forum.xda-developers.com/showthread.php?t=331094&highlight=physlast%3A)

3.5. Натравливаем утилиту M'Reloc_nk на подпапку nk.exe в модулях разобранной прошивки ATOM.
Видим: e32_vbase: 9AC00000, 032_realadr: 80500000
Меняем: e32_vbase: 9AC00000, 032_realadr: 80580000
Жмем: Doit

3.6. Натравливаем утилиту M'Reloc_nk на подпапку giisr.dll в модулях разобранной прошивки ATOM.
Видим: e32_vbase: 9AC95000, 032_realadr: 80566000
Меняем: e32_vbase: 9AC95000, 032_realadr: 805E6000
Жмем: Doit

3.7. В imageinfo.txt для nk.exe правим поля o32[2].o32_realaddr: R=80580000, o32[3].o32_realaddr: R=80586000

3.8. В imageinfo.txt для giisr.dll правим поле o32[1].o32_realaddr: R=805E6000

Ну и далее как и для XIP ATOM EXEC...


Собранный XIP для ATOM PDAVIET_ATOM_OS_5_2_2000: http://forum.pda2u.ru/forum/index.php?s=&showtopic=41&view=findpost&p=632

P.S. Досконально, конечно, работу пока еще не проверил. Но запускается, телефон, камера, интерфейсы работают. Хотя надо проверять дальше.
P.P.S. Наверное, проще сделать релокацию самой camera.dll, чем смещать ядро. Но это пока в стадии эксперимента

Автор: AGC 26.12.2007, 14:23

Как заключение. Портировать ядро оси с ATOM (и ATOM EXEC) на хардверное ядро RW6815 пока так и не удалось. Хотя собрал вроде все верно, но не запускается. Похоже, нужно глубже копать прежде всего nk.exe на предмет таблиц адресов и размещений... Те, кто собирал на xda-developers и т.д., как то информацией в форумах по этой части не делятся, только результатом... Впрочем, если на ядре ATOM все будет работать корректно, наверное, портирование железного ядра и не нужно...

P.S. Если что забыл написать, извиняюсь Слишком много было экспериментов и размышлений. Как опорные можно использовать те XIP, которые я приложил для ATOM EXEC (??? ОС 5.2.1948) и просто ATOM (PDAVIET ОС 5.2.2000).

P.P.S. А вот портировать новую версию ядра ОС по сути очень просто... Там таких проблем уже не возникает.

Автор: BigMike 26.12.2007, 15:44

Респект!

Автор: alex_beda 26.12.2007, 15:53

Ну что могу сказать лично от себя,
я хип'ом занимался только на уровне поиска картинки и поиска драйвера дисплея в нём.
Из прочтённого выше, я понял то, что нихрена не понял.
Допустим для пользователей Ровера и Орсио нет (к примеру в данный момент) необходимости портировать ядро.
Есть необходимость заменить драйвер дисплея.
Всётаки я наверное больше железячник, или сказывается постоянное недосыпание + мороз -15 (для нас это много),
недоспавшие мозги совсем в конец замёрзли ))))))

Есть два файла xip.bin + ddi.dll
ну или разобранный хип в папке и файл ddi. dll,
что нужно сделать чтоб этот долбанный ddi вставить в хип, чтоб не было порблем с дисплеем

Автор: AGC 26.12.2007, 16:57

А что за кухня?
ddi.dll в XIP не вставляется! Он идет в imgfs секции, т.е. обычной ОС, которая разбирается imgfstools.
Хотя сам файл относится к OEMDrivers...

P.S. Собственно, а в чем проблема? Ты же сам прикладывал imgfstools, когда ArHon опубликовал сообщение, как менять драйвера клавиатуры, экрана и звука в прошивке ATOM EXEC на RW6815 Или я что-то совсем не понял?
P.P.S. Собственно, даже в кухнях это кладется в OEMDrivers либо в SYS, либо что правельнее в OEM (зависит от корректности переразборки ОС).

Автор: AGC 26.12.2007, 17:08

2 alex_beda: Или речь идет совсем не о ddi.dll, а о проблемах с экраном? У нас на RW68xx после обычной замены ddi.dll на родную на прошивке от ATOM EXEC нужно было передергивать экран после вынимания аккумулятора, из-за этого собственно и нужна была прошивка от ATOM, где с экраном все было в порядке. Но на ATOM не работала камера на 6815

Если так, что можно просто взять мои XIP для той прошивки, на которой корректно работал экран после обычной замены ddi.dll, если версия ОС совпадает. Иначе пересобрать XIP как описано выше для нужной версии ОС.

Автор: ArHon 26.12.2007, 18:55

Молодец! Я долго ковырялся с хипами на предмет релокации модулей, но почему-то натравить на них M'Reloc_nk не догадался

А портировать ядрос WM5 даже не пытайся - слишком разные системы, там драйвера даже разными процессами грузятся, вот цитата с MSDN: "The Windows Embedded CE driver model has changed for Windows Embedded CE 6.0. In Windows CE 5.0 and earlier, drivers ran in the Device.exe process. In Windows Embedded CE 6.0, drivers run in the NK.exe process."

Автор: AGC 26.12.2007, 19:23

Ну... до M'Reloc_nk я сегодня утром дошел До этого пытался вручную откорректировать

А вот по 6.0 не согласен Windows Mobile 6.0 базируется на Windows CE 5.2. Windows CE 6.0 видимо будет в семерке...
Сам вчера и сегодня до упада пытался разобраться в нумерации осей от MS.

С другой стороны, там такое ощущение, что толи нужно еще ремапить родной nk.exe из-за ремапа драйверов, толи у нее в nk.exe где-то жестко прошит возврат версии 5.1. Хотя вроде бы это должно быть в ядре операционной системы, а не nk.exe. Такое ощущение, что те кто реально портировал свой nk.exe на другое устройство это нашли, но вот информации нет.

См., например, http://forum.xda-developers.com/showthread.php?t=315030&highlight=physlast%3A
И еще было в цепочке по прогрессу WM6 для Trinity. Там как раз сначала удалось тупо портировать файлы оси, просто понизив у них версию до 5.1. А уже потом видимо было найдено, где же эта версия прошита... Может быть в nk.exe, тогда результат закономерен

Автор: AGC 26.12.2007, 21:01

Да, забыл еще написать. Я бы не стал слепо доверять утилитам типа M'Reloc_nk. Не было времени серьезно проверить, но похоже, что они даже не ведут разбор PE-заголовка (впрочем, его ведут другие утилиты, это так, общее замечание ) и вообще кода. Алгоритм похоже следующий - просто по выравниванию на двойное слово идет поиск по маске и замена. Удобно, но потом баги придется вылавливать. В общем, для окончательной версии (если она будет ), придется ручками проверять...

P.S. Это я к тому, что M'Reloc_nk отказался мне двигать pm.dll, когда я пытался собрать ядро на базе RW6815. А там как раз больше всего было пересчетов.

Автор: AGC 28.12.2007, 3:43

Нашел, может не очень полезную с практической точки зрения, информацию. Номер версии ОС жестко зашит в coredll.dll в теле функции GetVersionExW. Код имеет подобный вид:

Теоретически, нужно вытащить coredll.dll, дизассемблировать ее, найти функцию и посмотреть HEX-код, который уже и поменять на нужный в смысле версии. Практически, т.к. я не большой специалист по кодированию инструкций этих процессоров, то привожу поясняющую картинку, дешифровку и метод замены только для прошивок на базе WM6 ATOM и ATOM EXEC (смотрел штуки четыре, везде именно так). Менять можно либо в разобранной coredll.dll в S000 в XIP, либо напрямую в diskimage_Ver.nb0.

1. Кодирование версии ОС (5.2.1948):
MOVL R3, 0x79С ; 79 3E A0 E3 0C 30 83 E3

MOV R1, #5 ; 05 10 A0 E3
MOV LR, #2 ; 02 E0 A0 E3

2. Метод замены (см. иллюстрацию)
Ищем в diskimage_Ver.nb0 или S000 coredll.dll последовательность: 05 10 A0 E3 02 E0 A0 E3
Меняем по соответствующим смещениям билд.

Вроде все. Да, для других осей поисковая цепочка может быть иной, нужно смотреть реализацию функции в coredll.dll. Например, для WM5 на RW6815 (6828) цепочка поиска 05 20 A0 E3 01 10 A0 E3.

Основной источник: http://forum.xda-developers.com/showthread.php?t=294218&page=4

P.S. Теоретически, таких последовательностей вроде должно быть две, т.к. функций вроде бы две GetVersionEx и GetVersionExW. Но я не дизассемблировал полностью coredll.dll, нашел только одну. Может там просто ссылки на одну и туже функцию...

Автор: AGC 30.12.2007, 21:28

В общем, с портированием WM6 на аппаратное ядро RW6815 как то пока не очень получается. Вроде бы все верно, но WM6 с новым ядром не запускается. Почему верно - вставил собранный новый XIP с ядром ОС WM6 и аппаратным ядром от RW6815 в родную WM5 и она загрузилась! При этом в About показывает все верно - 5.2.1948, т.е. на чем и собирал. В чем загвоздка, непонятно... Публикую использовавшуюся технологию и результирующий собранный XIP, может у кого возникнут светлые мысли, в чем я неправ?

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

1. Взяд WM5 HP RW6815 WWE и вытащил из нее XIP. Разобрал его.
2. Взял XIP от WM6 ATOM EXEC сборки оси 5.2.1948
3. Из Modules XIP WM5 удалил отладочные hd.dll и osaxst0.dll (и без них все отлично работает )
4. Из XIP WM6 из Files и Modules перенес с заменой все файлы ОС WM6 из MSXIPKernel и MSXIPKernelLTK.
5. Взял из XIP WM5 библиотеки аппаратного ядра ceddk.dll, cecompr.dll, stratad_intel_l.dll и trueffs.dll и переместил их по vbase и realaddress XIP WM6 с помощью M'Reloc_nk. Они конфликтуют с pm.dll и regenum.dll от XIP WM6 (можно двигать и эти, но результат как то не меняется). Единственная хитрость, нужно добиться от M'Reloc_nk, чтобы после DoIT realaddress был правильный, для этого из нужного адреса вычитаем длину блока.
6. Заменил в XIP WM5 соответствующие библиотеки на исправленные.
7. Увеличил в ROMHDR.TXT physlast (на XIP WM6).
8. Запустил XIPPort и сделал Realoc_P, write_maps.
9. Заменил в S000 nk.exe адрес рома.
10. Собрал новый XIP.

Как результат - вставляю его в WM5 RW6815 WWE - грузится с новым ядром. Вставляю в WM6 - повисает на надписи сброса настроек (причем как бы правильно, т.е. секунд 7-8 горит яркая надпись, потом где-то на 18-20 она чуть притухает... дальше как бы должна грузиться ОС, а реально висим и надпись через какое-то время еще сильнее гаснет...).

Вот. Прикладываю собранный XIP, может кто посмотрит отладочные надписи на большом компьютере. Я себе, конечно, соберу кабель, но это долго XIP для прошивки ОС 5.2.1948 ATOM EXEC... Могу выложить и целиком diskimage_Ver.nb0 для RW6815.

Автор: AGC 1.1.2008, 16:24

Всех с наступившим Новым Годом! Успехов и счастья в новом году!

По поводу XIP с WM6 и аппаратным ядром RW6815, думается, скоро все заработает Перерыл кучу форумов, такое ощущение, что в конечном портировании WM6 на устройства с WM5 всегда принимал участие cnomex. Что конкретно делал этот волшебник, пока не ясно. Основное - правильный релок ядра, в трудных случаях - редактирование nk.exe и аппаратных драйверов (но это, надеюсь, не наш случай ). В общем, скачал с его сайта монументальные труды по редактированию ромов и релоку. Сейчас изучаю. К сожалению, они относятся к более ранним платформам, но общие принципы сохранились. Часть про WM5/WM6 устройства он обещает дописать в скором времени...

С другой стороны, сейчас выкачал и разобрал WM5 для ATOM. Что самое интересное - ядро практически (на том, что успел посмотреть просто полностью) идентично WM5 на RW6815! Осталось сделать последний маленький шажок - разобраться, что именно было сделано на шаге перехода от WM5 к WM6 на ATOM и повторить для RW6815. Так что, наверное, это дело нескольких дней.

Ну а если не получится, придется, как и всем предшественникам, обращаться к cnomex за помощью

Автор: AGC 1.1.2008, 18:31

Вот и все! Я нашел самое ключевое изменение!!! Правим в S000 в nk.exe:

25160: 01 02

Грузимся!!! WM6 на родном аппаратном ядре 6815!

Там идет ключевой код, о котором я писал несколько сообщений назад по проверке версии:

Соответственно меняем гениальные CMP R3, #1 на CMP R3, #2, т.е. 5.1 на 5.2. И все.

Нужно, конечно, еще дальше покапать. Там много всего, но ГРУЗИМСЯ!!!

P.S. Для других коммуникаторов можно попробовать поискать: 05 00 52 E3 0E 00 00 8A
Далее по смещению +0x10 должно быть 01 00 53 E3
Там и правим 01 на 02...

Автор: AGC 1.1.2008, 22:08

Уу...у! Ну ладно, раз никто не пишет, пойду тоже пить, все что горит

Я теперь тоже хочу высказать благодарности, как все мейкеры ядер... ArHon и alex_beda за то, что указали, что Светлый путь существует! И главное показали, куда идти! cnomex, bepe и mamaich за то, что этот путь нашли вообще!
В общем, еще раз хочу поздравить всех с Новым Годом и пожелать всего самого лучшего!

Автор: ArHon 2.1.2008, 0:57

AGC, молодец! Как просохнешь, собирай всю инфу в кучу - и в подробностях расписывай портирование ядра с wm5 на wm6! Поздравляю!!!

P.S. Проверил - все прошивается, главное не забыть ручками править файлы imageinfo.txt после M'Reloc_nk, правда есть одно НО - не смог сделать ХР (может я уже туплю, но ведь на 6815 ХР делается - обе трубки + питание + ресет?) - не реагирует, как и на атомовское питание+ресет. Пока вот.

P.S.S. Так... у меня с этим ядром те же проблемы, что и с атомовским - не ставятся кабы, не производится синхронизация с ББ, давай подробную инструкцию - может чего не сделал

Автор: AGC 2.1.2008, 7:17

Спасибо!

А инструкция грядет Сегодня-завтра допишу полностью. Хотя я вроде все описал в предыдущих сообщениях, но опишу более подробно именно для портирования с ATOM и ATOM EXEC. Правда сейчас, вроде бы, я уже представляю себе, как принципиально портировать если не с любого устройства, то с более менее совместимого (по процессору, строению, ну и т.п. естественно ). Главное не забыть еще OEMDrivers самой ОС. А желательно и весь OEM... Ну и сертификаты, будь они не ладны

С ХР сейчас посмотрю, я и забыл, что ядро поменялось. В результате сейчас опять вогнал устройство в перепрошивку Нажимая разные кнопочки...

По проблемам, честно говоря, этих не обнаружил. Кабы ставятся, как минимум ставил твой - эмуляции расширенного рома, еще ставил твой же каб камеры, т.к. забыл по первости ее вшить в прошивку. Все Ок. Синхронизация тоже проходит на ура, по крайней мере записную книжку тащит нормально. А что за ОС стоит на большом компьютере - случайно не Vista? В общем, на Windows XP SP2 + ActiveSync 4.5 все вроде работает...

P.S. Сейчас в нашей ветке выложу тестовую сборку. Попробуй на ней. Я просто, на самом деле, много чего менял, может что действительно забыл описать...

P.P.S. Прошу делать скидку на мою оговорку, что найдено именно "ключевое изменение" при переходе от ATOM WM5 к ATOM WM6 Там побайтное сравнение nk.exe дает 3610Kb отличий. Ясно, что 99,9% этих отличий связаны с релоком пары частей nk.exe в памяти (опять же, пока не очень понял, зачем они это делали, может просто подгоняли под то устройство, с которого портировали ОС, а может были более практические причины)...

--- Дописано позднее ---
Разобрался с остальными 3610Кб изменений. Первые три байта - смещение рома, последний байт - описанное ключевое изменение. Остальное - "мусор". Там картинку в S000 поменяли, а я сразу и не сообразил
Так что в S000 nk.exe действительно исправили лишь один байт в проверке версии...

Автор: ArHon 2.1.2008, 20:41

AGC, есть положительный результат! По твоей технологии все сделал, только вместо портирования ядра в родной хип, сделал наоборот - портировал устройство-зависимые файлы и модули в новый хип из родного. Т.е. те файлы, которые попадают в папку OEMXIPKERNEL после команды make pkgs в xipport3. Так что все ок, готовь полную инфу с учетом сказанного. И еще я сделал релок giisr.dll. Пока выложу новую сборку своей прошивки с ядром 1948. Если хочешь, могу сам инфу наклепать - а то роверовцы ждут, им тоже экран нормальный нужен. Правда вот с ХР надо будет еще ковыряться....

Автор: AGC 3.1.2008, 2:07

Молодец, здорово! Я же не зря писал, что сейчас начало появляться реальное понимание, как портировать WM6 на WM5-устройства практически с любого более-менее совместимого девайса. В плане осмысленности действий Во время экспериментов, я как только не извращался... Там даже не суть как важно, что и куда, главное "правильно" + ключевое изменение cnomex

В общем, сейчас постараюсь следующим сообщением собрать воедино изложенные ранее обещанные принципы портирования, большая просьба, если что забуду, поправь. У меня уже взгляд замылился, часть вещей делается на автопилоте (ты, кстати, абсолютно верно уточнил выше, что нужно после M'Reloc_nk править ручками imageinfo.txt, просто уже забыл это написать). Да и взгляд уже разбегается на русские прошивки, родной HTC Touch + VoiceCommander русский от ETEN M700 Постараюсь подробно, а там уж как получится...

Да, по результатам сегодняшней апробации в нашей ветке выяснилось, что вставлять все родные драйвера, не самая лучшая идея. Я сейчас откатился на сборку с базовым набором (камера, экран, звук, клавиатура). Это еще нужно уточнять. Как минимум от WM6 нужно оставлять драйвера miniSDHC. Еще у меня были какие-то проблемы с синхронизацией под Vista до отката, но это могло быть вызвано и просто подвисанием ActiveSync на коммуникаторе (я его перетыкал с WinXP на Vista). В общем, с драйверами тоже нужно будет еще поэксперементировать.

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

P.S. А проблема с синхронизацией то разрешилась? Если стоит Vista, то на 32-битной мне сегодня удалось его зацепить. Там MS буквально на днях выпустил какой-то патч к своему центру мобильных устройств, да и кто-то в форуме написал, что у него тоже получилось зацепить после обновления с MS. Так что все должно заработать после обновления...

Автор: AGC 3.1.2008, 5:35

Портирование ядра ОС из XIP WM6 ATOM/ATOM EXEC на аппаратное ядро из XIP WM5 RW6815 и других собратьев
По сути вся технология описана в предыдущих сообщениях, ниже просто постарался изложить как то более системно и детально конкретные действия, да добавил небольшие общие комментарии

1. Берем diskimage_Ver.nb0 от оригинальной WM5 WWE целевого устройства (если берется локализованная прошивка, то в дальнейшем нужно, видимо, будет править boot.rgu перед сборкой XIP на предмет замены локалей для русской 0419 на 0409, если донор WM6 WWE).

2. Вырезаем из нее XIP в виде блока 180000-53FFFF и сохраняем как xip.bin в папку для разборки.

3. Разбираем XIP с помощью XIPPort ("dump xip.bin" и затем "write maps").

4. Аналогичным образом берем diskimage_Ver.nb0 от прошивки-донора ОС WM6 ATOM/ATOM EXEC, вырезаем из нее XIP и разбираем в другую папку.

5. Из подпапки Out/Modules разобранного XIP WM5 сразу удаляем отладочные hd.dll и osaxst0.dll (удаляем папки и соответствующие текстовые файлы). Они не нужны.

6. В XIPPort WM6 генерируем пакеты ("make pkgs").

7. Из XIP WM6 из подпапок MSXIPKernel и MSXIPKernelLTK папки Out/Files переносим с заменой все файлы ОС WM6 в подпапку Out/Files WM5 (все файлы и папки).

8. Из XIP WM6 из подпапок MSXIPKernel и MSXIPKernelLTK папки Out/Modules переносим с заменой все файлы ОС WM6 в подпапку Out/Modules WM5 (все файлы и папки). Для RW6815 MSXIPKernelLTK была пустая.

9. Открываем сгенерированные ранее map.txt от WM5 и WM6. Смотрим секцию "Start: first DLL address - End: last DLL address" и следующую сразу за ней до "Start: start of RAM". Они должны быть просто полностью идентичны приведенным ниже.

10. Далее берем из XIP WM5 библиотеки аппаратного ядра ceddk.dll, cecompr.dll, stratad_intel_l.dll и trueffs.dll и перемещаем их по vbase и realaddress XIP WM6 с помощью M'Reloc_nk. Они конфликтуют с pm.dll и regenum.dll от XIP WM6. Для этого запускаем M'Reloc_nk и последовательно открываем в нем папки этих библиотек из XIP WM5.Единственная хитрость, нужно добиться от M'Reloc_nk, чтобы после DoIT realaddress был правильный, для этого из нужного адреса вычитаем длину блока. В общем, для указанных выше таблиц просто привожу значения для M'Reloc_nk:

ceddk.dll
e32_vbase: 03DEF000
e32_realaddr: 01FD0000 (после DoIT будет 01FD0000+1000=01FD1000)

trueffs.dll
e32_vbase: 03DF5000
e32_realaddr: 1FC3000 (после DoIT будет 1FC3000+F000=01FD2000)

cecompr.dll
e32_vbase: 03E41000
e32_realaddr: 01FE0000 (после DoIT будет 01FE0000+1000=01FE1000)

stratad_intel_l.dll
e32_vbase: 03E48000
e32_realaddr: 1FD5000 (после DoIT будет 1FD5000+D000=01FE2000)

11. У этих четырех библиотек редактируем imageinfo.txt, заменяя значения e32_vbase и o32[x].o32_realaddr на правильные (e32_vbase берем указанные выше для M'Reloc_nk, o32[x].o32_realaddr берем оттуда же, но скалькулированный в скобочках или их map.txt WM6, x- номер региона в map.txt [там не ошибиться, будут старые значения из map.txt WM5 типа D=01FE3000])

12. Увеличиваем в WM5 в ROMHDR.TXT physlast (ставим значение как в XIP WM6 = 9AFE2990). Впрочем, можно и точнее подогнать (я по аналогии с ATOM просто прибавил 100000...).

13. Ищем в map.txt WM5 строку старого смещения рома (можно по "rom_00")

Запоминаем из нее старый адрес смещения. Пример из указанной строки: 9ad20b2c (скорее всего, будет другой, берете свой)

14. Запускаем XIPPort WM5, делаем Realoc_P и write_maps.

15. Смотрим на всякий случай новый map.txt на предмет отсутствия восклицательных знаков (конфликты).

16. Ищем в новом map.txt строку (можно по rom_00)

Берем из нее новый адрес смещения. Пример из указанной строки: 9adb19d4 (скорее всего, будет другой, берете свой)

17. Ищем в S000 nk.exe старый адрес смещения рома (байты идут инвертно), меняем на новый.

18. Пробуем искать в S000 nk.exe: 05 00 52 E3 0E 00 00 8A
Если нашли, далее по смещению +0x10 должно быть: 01 00 53 E3
Там и правим 01 на 02...

Если не нашли, то плохо Будем думать...

19. Собираем новый XIP ("build xip_out.bin").

20. Закидываем в папку WM5 diskimage_Ver.nb0 от целевой WM6.

21. Шьем XIP назад (в полях вводим значения: 00180000 и diskimage_Ver.nb0, жмем "write xip_out.bin to")

Вроде ничего не забыл

P.S. По boot.rgu. Если берется WM5 русская, я бы попробовал поменять 419 на 409. К сожалению, на этой фазе у меня еще прошивка не заводилась, когда я пытался портировать с русской WM5, поэтому сказать, что будет без замены не могу.

P.P.S. В WM5 RW6815 в Files был mxip_initdb.vol, причем относился как бы к OEM. В WM6 ATOM это же лежало в IMGFS. Я дополнительно менял этот файл в XIP с коррекцией размера в текстовом файле описания. Но реально пробовал, это не оказывает какого-то влияния (по крайней мере, не заметил).

P.P.P.S. Извиняюсь за столь подробное изложение, наверняка ряд вещей очевиден. Но со временем все забывается, чтобы самому потом мучительно не вспоминать. Да и писал сразу и для новичков с других устройств, чтобы не осталось неясностей и можно было при необходимости действовать по аналогии Потом, если будут силы, попробую дописать уточненную общую инструкцию, которая приведена соседней ветке форума на английском, т.к. вещи по релоку модулей и правке nk.exe при портировании с WM6 на WM5 там как то не затронуты (да и вообще в явном и собранном виде этого нигде не нашел).

Автор: ArHon 3.1.2008, 13:28

Огромное спасибо AGC за его труд, но я все-таки думаю, что портирование устройство-зависимых файлов правильнее, чем наоборот. Так что выкладываю свой вариант мануала по портированию. Подчеркиваю, что нашел всю информацию и собрал все в кучу AGC, за что ему хвала и благодарность!
Итак:
1. Распаковываем родной XIP WM5 с картами (далее XIP_OLD)

2. Распаковываем XIP WM6 с картами (далее XIP_NEW), копируем его отдельно и создаем пакеты - make pkgs (далее XIP_NEW_COPY)

3. Смотрим состав папки XIP_NEW_COPY\Out\Files\OemXipKernel и копируем с заменой такие же файлы из XIP_OLD\Out\Files в XIP_NEW\Out\Files
Если язык родной WM5 прошивки и прошивки WM6 не совпадают, то делаем слудующее:
среди них будет boot.rgu - в нем находим ключи, отвечающие за MUI и изменяем их в соответствии с языком прошивки WM6:

в файле boot.hv WinHex'ом находим unicode строку MUI и изменяем соответствующие параметры тоже (см. рис.1)

4. Смотрим состав папки XIP_NEW_COPY\Out\Modules\OemXipKernel и копируем с заменой такие же файлы из XIP_OLD\Out\Modules в XIP_NEW\Out\Modules
скорее всего, состав файлов будет следующим:


5. Теперь нам понадобится утилита M'Reloc_nk. Для начала рассмотрим модули cecompr.dll, ceddk.dll, stratad_intel_l.dll, trueffs.dll, с ними попроще, рассмотрим на примере trueffs.dll:

5.1. Натравливаем M'Reloc_nk на модуль XIP_NEW\Out\Modules\TrueFFS.dll
5.2. Сравниваем файлы XIP_NEW\Out\Modules\FrueFFS.dll\imageinfo.txt и XIP_NEW_COPY\Out\Modules\OemXipKernel\FrueFFS.dll\imageinfo.txt. Я использую для этого команду "Сравнить по содержимому" Total Commader - очень удобно, но можно и любым другим способом.
5.3. В M'Reloc_nk показываются два значения - для e32 и Ram. Нам нужно синхронизировать оба. На рис.2 слева - XIP_NEW, справа - XIP_NEW_COPY.
5.4. Смотрим для e32_vbase значение из XIP_NEW_COPY и пишем его в M'Reloc_nk
5.5. Теперь для значения o32_realaddr в M'Reloc_nk заносим значение из XIP_NEW_COPY за вычетом o32_vsize (на рис.3 выделен синим цветом), для рис.3 это будет значение 01FD2000-0000F000=01FC3000.
5.6. Жмем Doit! - и видим результат - в M'Reloc_nk теперь значения, соответствующие XIP_NEW_COPY (см. рис.4)
5.7. Теперь в самом файле XIP_NEW\Out\Modules\FrueFFS.dll\imageinfo.txt исправляем эти значения на значения из XIP_NEW_COPY\Out\Modules\OemXipKernel\FrueFFS.dll\imageinfo.txt (рис.5,6)
5.8. Повторяем п.5.1.-5.7. для модулей cecompr.dll, ceddk.dll, stratad_intel_l.dll

6. Теперь рассмотрим модули giisr.dll и nk.exe - адресация там не прямая, а косвенная, возьмем к примеру giisr.dll:

6.1. Натравливаем M'Reloc_nk на модуль XIP_NEW\Out\Modules\giisr.dll
6.2. Сравниваем файлы XIP_NEW\Out\Modules\giisr.dll\imageinfo.txt и XIP_NEW_COPY\Out\Modules\OemXipKernel\giisr.dll\imageinfo.txt (рис.7)
6.3. Чтобы узнать значение P нужно сравнить файлы XIP_OLD\Out\ROMHDR.txt и XIP_NEW\Out\ROMHDR.txt (рис.8). Скорее всего (как и в данном случае), они совпадут.
6.4. Вычисляем e32_vbase для XIP_NEW_COPY и заносим его в M'Relock_nk (рис.8), o32_realaddr заносим аналогично другим модулям (рис.9). Doit! Правка imageinfo.txt - готово!
6.5. п.6.1.-6.4. повторяем для nk.exe

7. Теперь мы подошли к следующему этапу - правке nk.exe:

7.1. Открываем файл XIP_NEW\Out\Modules\nk.exe\S000 в WinHex, ищем байты 050052E3 (рис.10). Прямо под найденными байтами видим ключевой байт (выделен красным) - его-то и меняем на 02. Сохраняем.
7.2. Теперь запускаем Xipport и делаем для XIP_NEW Realoc P, Write maps.
7.3. Открываем файл XIP_OLD\Out\Map.txt и находим в нем строчку с rom_00 (рис.11). Красным выделен старый адрес rom_header. Открываем файл XIP_NEW\Out\Modules\nk.exe\S000 в WinHex и ищем этот адрес, помня, что реально адреса хранятся начиная с младших байтов, т.е. для данного случая ищем 2C0BD29A (рис.12). Теперь открываем XIP_NEW\Out\Map.txt и находим в нем строчку с rom_00 - там увидим новый адрес rom_header (рис.13). Вот его и заносим вместо старого в nk.exe, т.е. в данном случае заменяем 2C0BD29A на 686BD79A (рис.14).

8. Все! Теперь делаем build xip_out.bin - хип готов, осталось вставить его на место в прошивку!

P.S. Мануал писался при портировании хипа для ровера, прикладываю его - надо проверить.

Автор: alex_beda 3.1.2008, 19:24

Приложенный ХИП не запускается. Висит на ХР.
Но экран после передёргивания аккума уже не рябит. Тоже уже достижение.

Инфа выдаваемая отладчиком в СОМ порт:

Автор: AGC 4.1.2008, 17:09

Сейчас попробую поиграться с ядром Ровера и его прошивкой. Если получится загрузиться на 6815, выложу. Просто ты не написал, в какую прошивку пытался вставить этот XIP...

Автор: AGC 4.1.2008, 18:25

Зашился с ядром Ровера на базе ОС 5.2.1948. Все Ок. Прикладываю свой вариант xip_out.bin. Он собран из ATOM EXEC TRED RC3 на базе 5.2.1948. Теоретически, его туда же и нужно закидывать, т.к. версия ОС Попробуй его...

Сейчас закину в сеть и всю прошивку целиком, после этого отредактирую сообщение.

--- Дописано позднее ---

Вся прошивка целиком для Ровер G5: http://rapidshare.com/files/81210190/RoverG5_NEWKERNEL_TRED_ATOM_EXEC_RC3_OS_5_2_1948.zip.html

P.S. Прошивку собирал на коленке за 10 минут, поэтому имеет смысл проверить. Я засунул ddi.dll, wavedev.dll и pxa...keyboard.dll от Ровера, но у меня роверовская прошивка как то криво разобралась. Нужно проверять на ровере.

P.P.S. А вообще прикольно. У меня на 6815 с этим ядром Ровера наконец-то нормально заработала родная камера ATOM И экран был Ок, пока аккумулятор не передернул. А после передергивания экран ушел в аут, рябит. LCCR бы найти, где в ядре устанавливаются. Тогда можно было бы попробовать ручками отредактировать под 6815... Сейчас еще попробую на это ядро наложить аппаратные драйвера от 6815, будет тоже вариант.

P.P.P.S. Заоодно и проверил в boot.rgu MUI. В общем, это не важно, главное, что в оси установлено. Оставил 419 в boot-е.

Автор: ArHon 4.1.2008, 18:39

AGC, а хард ресет на роверовской прошивке попробовал?

Автор: AGC 4.1.2008, 18:49

А как он там делается? Сейчас попробую...

--- Дописано ---
Да, работает... Все Ок.

P.S. Значит, похоже, нам нужно искать клавиатурный обработчик в файлах ОС ядра. Править там сочетание клавиш... Наверное...

Автор: AGC 4.1.2008, 19:35

2 Arhon: Кстати, с Роверовским ядром уже реально попробовать сравнить ядро 6815. По размеру они практически идентичны, ощущение, что вышли просто из одной лаборатории, в исходниках просто поменяли аппартную часть и картинки. Можно попробовать дизассемблировать и то и другое, а потом каким-нибудь WinMerge поискать критические изменения...

Автор: ArHon 5.1.2008, 1:54

AGC, я так подозреваю, что все дело в nk.exe, а вот тут-то разница 6815 и ровера значительна, у ровера к тому же есть дополнительная картинка с трубками. Я почти уверен, что при нажатии ресета, именно nk.exe обрабатывает нажатые клавиши и уже сам отправляет либо в хард ресет (той же функцией KernelIOControl, к примеру), или просто в ресет, или в бутлоадер, где уже производится проверка нажатия софт-клавиш (именно поэтому приходится долго их держать). А вот почему он на них не реагирует - загадка та еще Кстати, ты на роверовской проше нажимал именно трубки для хард ресета? Т.е. клавиши в ядре нормально замапены? Не поменялись с софткеями?

Автор: AGC 5.1.2008, 2:36

Начну с конца. Да, трубки - все Ок. Правда я из ровероской прошивки дернул pxa....keyboard.dll. Но она тут вроде особо совсем не причем.

По остальному. Все верно, за исключением нюансов. Я сейчас попробую найти презентацию по работе CE 4.2. Там есть картинка с очень доходчивой иллюстрацией. Если не получится, кину просто картинку. Суть в том, что там идет спошной футбол между nk.exe и coredll.dll (ну и их сотилитами). Мое предстваление о ситуации сейчас следующее:

1. НЕЧТО похватывает комбинацию хард-ресета Питание + Ресет и шлет ее на обработку в nk.exe (скорее всего, это coredll.dll или ее смежники)
2. Наш nk.exe ловит совсем другую комбинацию, поэтому делает просто софт-ресет.

Выход - исправить это либо там, либо там. Проще видимо в нашем nk.exe.

P.S. Что касается дополнительной картинки с трубками. Различие в размерах там в полкилабайта... Скорее всего, просто в нашем nk.exe это ... назовем так ... "забыли". Впрочем, спорить тут особо не о чем Завтра, если смогу, дизассемблирую и сравню. Думается, все же больше правды в "идентичности" этих прошивок. Уж больно там много похожего...

Автор: ArHon 5.1.2008, 12:42

ВСЕ! Решение с хард ресетом найдено!

P.S. Правда теперь ХР будет делаться питание+ресет без дополнительных вопросов

Автор: AGC 5.1.2008, 16:43

Ура! Молодец, здорово!
А как?

Автор: BigMike 5.1.2008, 17:00

Господа, утилитку M'reloc_nk выложите, плиз?

И вообще, если чем-то из софта пользуетесь - не забывайте делиться

Автор: AGC 5.1.2008, 17:15

Так я вроде давал ссылку на первоисточник Там новые версии вроде появляются. Прикладываю ту, которой пользуюсь...

Автор: ArHon 5.1.2008, 17:26

AGC, я описал технологию в скрытом разделе

Автор: AGC 5.1.2008, 17:54

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

PS инфа уехала в другой топик - http://forum.pda2u.ru/forum/index.php?showtopic=76

Автор: BigMike 7.1.2008, 21:38

И по повду дизассемблирования тоже не мешало бы "раскрыть тему"
Чем дизассемблировали, как обратно собирать и т.п.

ЗЫ ответ AGC уехал в топик про программирование

Автор: ArHon 8.1.2008, 1:09

BigMike, сам файл nk.exe я вытащил sDuper'ом и натравил на него IDA Pro Advanced с установленным плагином для Pocket PC девайсов, ассемблера нет, поэтому пришлось ручками искать нужные коды и исправлять в WinHex'e. IDA, к сожалению, лишь дизассеблер

Автор: BigMike 9.1.2008, 9:41

Может, для начала ограничиться темой?
Тему щас сделаю - наполнение за тобой, я в этом ламер

Автор: AGC 9.1.2008, 22:25

Отлично! Спасибо. Положил туда еще и саму IDA Pro.

P.S. Я, к сожалению, до покупки коммуникатора тоже раньше с этими архитектурами ОС и процессоров никогда не работал. Так что на эксперта тяну с большущим трудом Впрочем, ассемблер он и есть ассемблер, читаю очередной монументальный труд...
Но вся основная надежда, конечно, на ArHon-а...

Автор: AGC 12.1.2008, 23:56

Вот. На xda-developers появилась инструкция по портированию новой версии ОС: http://forum.xda-developers.com/showthread.php?t=357249. Правда, на мой взгляд, частичная...

Автор: BigMike 6.2.2008, 15:03

Этот рецепт только для обновления сборки ОС применим.
При переходе на другой язык или с 5-й на 6-ю он уже вряд ли прокатит.

Автор: AGC 9.2.2008, 8:22

Так я именно это и написал Причем инструкция там даже "очень частичная", но автор грозился продолжением. Хотя, лично я не жду оттуда чего то выдающегося... Но кто знает, вдруг потом допишут... В том смысле, что будет именно полная общедоступная инструкция.

А так... Ну другой язык - это отдельный разговор В принципе, тут как раз вроде сложностей особых нет, если есть нужные файлики MUI, я же описывал в ветке по русификации полный механизм... В смысле, XIP тут вообще не важен...
А вот инструкции по переходу с 5-й на 6-ю WM не видел в принципе, только частичные отчеты о прогрессе и заявления о результате... Частный случай для наших устройств описан здесь же на предыдущих страницах. Причем это, пожалуй, самое полное и подробное описание из тех, с которыми я сталкивался А общий случай не особенно то и отличается, только как раз "частностями".

Меня тут сильно заинтересовала сейчас вторая часть "правильной" релокации - на уровне модулей ОС. Но это, наверное, отдельная ветка будет, т.к. пока ряд нюансов не очень ясен, разбираюсь пока сам...

Автор: BigMike 9.2.2008, 11:11

Ой ли? Я когда общался с k0ster'ом на 4pda - он мне объяснял русификацию как раз через портирование системных модулей в XIP и imgfs.

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

Автор: AGC 10.2.2008, 15:59

Ну...у, не знаю - "ну так работает же"

Если более подробно, то язык в XIP (ядре ОС) абсолютно безразличен. Свою русскую прошивку в пример не привожу, аналогичные решения применены в русской прошивке HTC Wizard 6.1 от ремембера и WWE прошивке TRED Touch RC3. В первой как и у меня стоит 0409 в ядре, во второй - 0804 в ядре. В самой ОС у первой естественно 0419, во второй 0409. Все работает, конечно. То есть язык устанавливается в реестре основной части ОС (IMGFS). В ядре ОС это было бы наверное критично, если выводить надписи на этапе загрузки на соответствующем языке, но они все на английском, поэтому без разницы. MUI на ядро накладывается потом поверх уже в самой ОС (и в основном через интерфейсы, в смысле другие библитеки обрабатывают и уже на них накладывается MUI).

Кстати, в прототипе русской сборки для G5 я воткнул аппаратное ядро Ровера с 0419, но что еще интереснее, в WM5 от него была куча файлов MUI от других языков. То есть он мог работать на разных языках, но в ядре все равно бы осталось 0419...

С другой стороны, тут нужно еще просто уточнить термин XIP. Может речь шла не совсем о ядре? XIP (eXecute In Place) - это принцип исполнения в вольном переводе "где лежу, там и пашу" По нему работает не только ядро (собственно, из-за этого и нужен "правильный" релок ядра), но и многие модули ОС...

Фух... В общем, для русификации минимум нужен MUI языка + правка реестра + несколько системных библиотек под язык (либо патчить ручками скины и проверки на 0419 для русского, либо позаимствовать с других устройств, например, минимум - библиотеки клавиатуры). По доброму, нужно патчить многие библиотеки под язык (как оказалось, опять же например, правка в реестре установок названия "My Documents" на русское "Мои документы" проблемы не решает, т.к. в куче модулей зашито именно "My Documents"). Ну и т.д.

Автор: BigMike 11.2.2008, 9:56

Мы с ним говорили не про перевод через MUI, а про перевод через портирование системы с русской WM6 для другого устройства.
k0ster говорил, что одной заменой SYS в imgfs не отделаешься - придется портировать и XIP.
Сейчас пытаюсь пересобрать WM6 для ровера с заменой SYS (и в xip, и в imgfs) на одну из русских сборок для Профета. Посмотрим, что получится
Кстати, мануал у вас с ArHon получился отличный - по нему сейчас и делаю.

Автор: AGC 11.2.2008, 14:45

Теперь понял, о чем шла речь Все правильно. Только это вообще общий случай портирования ОС с другой прошивки, тут даже не важно, какой язык. Действительно, в общем случае нужно тащить и ядро, т.к. на него завязана ОС (coredll.dll и другие части). Кстати, сейчас тоже вожусь с этим, только хочу утащить всю прошивку Rover G6...

P.S. На всякий случай, как дополнение к нашему варианту будущей инструкции по полному портированию ОС Если будешь тащить с пропета SYS в IMGFS, там теоретически нужно еще сделать релок (например, G'Reloc-ом или помодульно), только в SYS перед этим стоит заменить .ROM и .VM с наших прошивок (или посмотреть на них правильные значения параметров релока)...

Автор: BigMike 11.2.2008, 14:47

Помню конечно

Автор: k0ster 26.2.2008, 11:59

BigMike

Не совсем так.
Для руссификации не нужно манипулировать XIP-секцией.
Нужно после сборки системы удостовериться, что все значения в реестре касающиеся MUI и кодовых страниц имели верные значания.
Ну и естественно клавиатуру поставить от русской прошивки, а английскую выбросить.
Портировать XIP нужно было чтоб заиметь работающее ядро, т.к. на момент нашего разговора wm6 для ровера не было.
А при рабочем xip сделать полноценныю русскую систему для любого девайса - дело 15-ти минут при неполной доводке. (здесь основную сложность представляют OEM-приложения, которые надо переводить)

Автор: BigMike 26.2.2008, 12:04

Т.е. кроме реестра, сами системные модули "универсальные" - языка не имеют?
Получается, достаточно чтобы просто в SYS в XIP и IMGFS секциях были от одной сборки?

Автор: k0ster 26.2.2008, 15:06

Абсолютно верно.
Переводить нужно только файлы с ресурсами.

Пояснение:
Например, имеем работающий WM6 WWE для Rover и WM5 RUS для него же.
Хотим сделать русскую WM6.
Нужно сделать:
1. Распаковать образ WM6 в DUMP, разобрать на пакеты
2. Такая же манипуляция и для WM5-образа
3. Заменить SYS-часть в WM6-dump на русскую, от любого девайса.
4. Заменить OEM-часть в WM6-dump на WM5-dump.
5. Сгенерировать реестр, проверить что все значения MUI и кодовых страниц соответствуют кириллице.
6. Собрать образ ROM на базе WM6-rom
7. Прошиться

Вывод:
Чтобы получить русскую WM6 нам нужно:
1. Работающий XIP для нашего устройства.
2. SYS-часть с нужным языком от официальной версии от любого устройства.
3. ОЕМ-часть от официальной версии WM5 для нашего устройства.
4. Всё это собирается в кучу, проверяется на ошибки в реестре, оверлапы, исправляются ошибки.
5. Прошиваемся.

Автор: BigMike 26.2.2008, 15:14

Я правильно понимаю, что процедура настолько проста лишь потому, что WM6 - это на самом деле WM5.2?
Т.е. при более серьезной разнице между WM5 и WM2003 все будет заметно сложнее...

Автор: ArHon 26.2.2008, 15:34

да, я думаю также, по крайней мере, в WinCE600 (это уже WM7 будет вроде) совершенно другой подход к драйверам и их надо менять при переходе. В MSDN по этому вопросу http://msdn2.microsoft.com/en-us/library/aa931071.aspx.

Автор: AGC 26.2.2008, 19:07

Ну...у. Процедура не настолько уж и проста. Все это так, только если все используемые прошивки "правильные" и т.д. Тут много нюансов на реальном случае... Для самосборных вариантов нужно внимательно смотреть, что в OEM, а что в SYS. К тому же зачастую нужно тащить и часть OEM от донора (а то и большую часть). Потом и в SYS могут быть на самом деле зависимые от устройства модули (например, Bluetooth, dpi под разрешение экрана и т.п.). А если еще кто-нибудь наподписывал левыми сертификатами часть модулей, то и с этим придется разбираться, тогда без разборки OEM-части совсем не обойтись. Сам грешен подобными фокусами Так что не совсем все просто...

В принципе, в закрытой ветке я же начал обсуждение этой темы. Может ее в Шаманства просто вытащить? Или наоборот, туда перейти? А то это уже не совсем про XIP...


P.S. А с WM ниже 5-ки очень сложно, я как то почитал, что там cnomex творил, стало сильно грустно Но, в принципе, тоже реально, если ОЧЕНЬ-ОЧЕНЬ захотеть

Автор: salman DZ 2.3.2008, 12:27

Помогите разобраться как ХИП обратно в ром вставить прога Русский WinHex 13.5 SR-3 непойму где указать адрес с которого вставлять новый ХИП, если можно скришопы как это делается

Автор: AGC 2.3.2008, 14:37

Боюсь, для ответа мало информации Уточни, пожалуйста, какое устройство, какой XIP и откуда он был взят и т.д.?

Если речь о клонах атомов, то XIP лежит по адресам 180000-53FFFF (для файла прошивки с карты ОС). Если ты просто вырезал его из другой прошивки по этим адресам, то на эти же адреса его и нужно вставить в другой файл. Если у тебя xip_out.bin, то его нужно вставлять XIPPort-ом на 180000... Вот только не факт, что система после таких произвольных замен XIPа вообще загрузится...

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

Автор: BigMike 2.3.2008, 21:06

XIPPort отлично вставляет все, куда надо.
Кидаешь свой xip под именем xip_out.bin и полный образ оси (который diskimg.nb0), в который новый xip нужно вставить, в папку XIPPort'a, запускаешь xipport, указываешь во втором снизу поле адрес начала (для Atom Exec и клонов - 180000), в самом нижем - имя образа (diskimg.nb0). Все

PS Да, если образ оси будет с необрезанным заголовком (т.е. 65536012 байт) - то адрес будет 18000C

Автор: AGC 1.10.2008, 8:36

Для релока модулей XIPа можно использовать M'Reloc, а не M'Reloc.nk. В этом случае не нужно пересчитывать смещения, просто вводим целевые адреса. Естественно, речь не идет о самом nk.exe, а только об обычных модулях...