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

Нажмите сюда для просмотра этой темы в обычном формате

Форумы PDA2U.RU _ Шаманства для посвященных _ Разбираем XIP

Автор: Old Kind MadMike 15.11.2007, 0:02

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

 rover_xip.zip ( 1.1 мегабайт ) : 119
 

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

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

Код
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.ArgumentException: An entry with the same key already exists.
  at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
  at System.Collections.Generic.TreeSet`1.Add(T item)
  at System.Collections.Generic.SortedDictionary`2.Add(TKey key, TValue value)
  at XIPPort.Form1.CreateMap()
  at XIPPort.Form1.button2_Click(Object sender, EventArgs e)
  at System.Windows.Forms.Control.OnClick(EventArgs e)
  at System.Windows.Forms.Button.OnClick(EventArgs e)
  at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
  at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
  at System.Windows.Forms.Control.WndProc(Message& m)
  at System.Windows.Forms.ButtonBase.WndProc(Message& m)
  at System.Windows.Forms.Button.WndProc(Message& m)
  at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
  at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
  at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
   Assembly Version: 2.0.0.0
   Win32 Version: 2.0.50727.1378 (REDBITSB2.050727-1300)
   CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
XIPPort
   Assembly Version: 1.0.2702.33852
   Win32 Version:
   CodeBase: file:///C:/Documents%20and%20Settings/Winterice/Рабочий%20стол/xip/XIPPort.exe
----------------------------------------
msvcm80
   Assembly Version: 8.0.50727.1378
   Win32 Version: 8.00.50727.1378
   CodeBase: file:///C:/WINDOWS/WinSxS/x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.1378_x-ww_5c7e3652/msvcm80.dll
----------------------------------------
System.Windows.Forms
   Assembly Version: 2.0.0.0
   Win32 Version: 2.0.50727.1378 (REDBITSB2.050727-1300)
   CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
   Assembly Version: 2.0.0.0
   Win32 Version: 2.0.50727.1378 (REDBITSB2.050727-1300)
   CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
   Assembly Version: 2.0.0.0
   Win32 Version: 2.0.50727.1378 (REDBITSB2.050727-1300)
   CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
   <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

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

Автор: Old Kind MadMike 15.11.2007, 13:06

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

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

Автор: Old Kind MadMike 17.11.2007, 10:50

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

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

Цитата(Old Kind MadMike @ 17.11.2007, 12:50) *
Дело сдвинулось с мертвой точки. Возможно, потому что скачал 3-й дотнет, то ли просто нашел наконец способ.
Короче, у меня теперь строится карта, если перед ее построением сделать Realloc.
Теперь все становится гораздо интереснее smile.gif

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

Автор: Old Kind MadMike 17.11.2007, 17:38

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

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

Цитата(Old Kind MadMike @ 17.11.2007, 19:38) *
Новости с полей ковыряния XIP.
Как выясняется, стандартный xipport почему-то некорректно работает с нашими прошивками. Ниже приложил патченный - он уже корректно распаковывает и даже собирает почти без ошибок (хотя WinHEX все равно находит различающиеся блоки при просто распаковке-запаковке)...

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

Автор: Old Kind MadMike 18.11.2007, 23:42

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

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

 xipport_3.zip ( 67.32 килобайт ) : 169
 

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

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

Автор: Old Kind MadMike 19.11.2007, 23:30

Цитата
запускаю хиппорт извлекается только nk.exe ну и соответствееноо не карты нестроятся ниче. может кто знает в чем проблема?

Некоторые девайсы имеют два xip.
Первый действительно содержит только nk.exe
Цитата
разобрался с началом и концом секции хип в атомовской прошивке

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

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

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

Просто начал разбираться с 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. Метод грубой силы не прошел, после тупой замены без нормального релока коммуникатор не грузился smile.gif
---
Пока текущий максимальный результат - доходит до надписи сброса в значения по умолчанию. Потом висит. Это после переноса ядра из ATOM в RW6815...

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

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

По поводу 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, вроде бы все работает.

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

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

CODE
ATOM EXEC TRED RC3
~~~~~~~~~~~~~~~~~~

80180000 - 80180000 L00000000 Start: start of RAM
80180000 - 80186000 L00006000 uninitialized data of region_2 nk.exe
80186000 - 801e1000 L0005b000 initialized data of region_3 nk.exe
801e1000 - 801e2000 L00001000 initialized data of region_1 giisr.dll
801e2000 - 801e2000 L00000000 ------ start of RAM free space
801e2000 - 84000000 L03e1e000 NUL
84000000 - 84000000 L00000000 End: end of RAM


Правильное распределение (от WM5, так понимаю, с учетом выброса hd.dll и osax...dll):
CODE
80580000 - 80580000 L00000000 Start: start of RAM
80580000 - 80586000 L00006000 uninitialized data of region_2 nk.exe
80586000 - 805e1000 L0005b000 initialized data of region_3 nk.exe
805e1000 - 805e6000 L00005000 NUL
805e6000 - 805e7000 L00001000 initialized data of region_1 giisr.dll
805e7000 - 805e7000 L00000000 ------ start of RAM free space
805e7000 - 84000000 L03a19000 NUL
84000000 - 84000000 L00000000 End: end of RAM


Восстанавливается, самое простое, копированием папок 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:

CODE
80500000 - 80500000 L00000000 Start: start of RAM
80500000 - 80506000 L00006000 uninitialized data of region_2 nk.exe
80506000 - 80561000 L0005b000 initialized data of region_3 nk.exe
80561000 - 80566000 L00005000 NUL
80566000 - 80567000 L00001000 initialized data of region_1 giisr.dll
80567000 - 80567000 L00000000 ------ start of RAM free space
80567000 - 84000000 L03a99000 NUL
84000000 - 84000000 L00000000 End: end of RAM


3.2. Оригинальное распределение памяти на RW6815:
CODE
80580000 - 80580000 L00000000 Start: start of RAM
80580000 - 80586000 L00006000 uninitialized data of region_2 nk.exe
80586000 - 805e1000 L0005b000 initialized data of region_3 nk.exe
805e1000 - 805e6000 L00005000 NUL
805e6000 - 805e7000 L00001000 initialized data of region_1 giisr.dll
805e7000 - 805e7000 L00000000 ------ start of RAM free space
805e7000 - 84000000 L03a19000 NUL
84000000 - 84000000 L00000000 End: end of RAM


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, чем смещать ядро. Но это пока в стадии эксперимента smile.gif

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

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

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

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

Автор: Old Kind MadMike 26.12.2007, 15:44

Респект!

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

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

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

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

Цитата(alex_beda @ 26.12.2007, 15:53) *
Есть два файла xip.bin + ddi.dll
ну или разобранный хип в папке и файл ddi. dll,
что нужно сделать чтоб этот долбанный ddi вставить в хип, чтоб не было порблем с дисплеем

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

P.S. Собственно, а в чем проблема? Ты же сам прикладывал imgfstools, когда ArHon опубликовал сообщение, как менять драйвера клавиатуры, экрана и звука в прошивке ATOM EXEC на RW6815 smile.gif Или я что-то совсем не понял?
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 smile.gif

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

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

Цитата(AGC @ 26.12.2007, 14:23) *
Как заключение. Портировать ядро оси с ATOM (и ATOM EXEC) на хардверное ядро RW6815 пока так и не удалось.


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

А портировать ядрос 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

Цитата(ArHon @ 26.12.2007, 18:55) *
Молодец! Я долго ковырялся с хипами на предмет релокации модулей, но почему-то натравить на них M'Reloc_nk не догадался biggrin.gif

А портировать ядрос 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."


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

А вот по 6.0 не согласен smile.gif 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, тогда результат закономерен sad.gif

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

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

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

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

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

CODE
EXPORT GetVersionExW
GetVersionExW
STMFD SP!, {R4,R5,LR} ; GetVersionEx
MOVL R3, 0x79С ; 1948
MOV R2, #0x114
MOV R1, #5
MOV LR, #2
MOV R4, #3
...
BX LR
; End of function 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, может у кого возникнут светлые мысли, в чем я неправ? smile.gif

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

1. Взяд WM5 HP RW6815 WWE и вытащил из нее XIP. Разобрал его.
2. Взял XIP от WM6 ATOM EXEC сборки оси 5.2.1948
3. Из Modules XIP WM5 удалил отладочные hd.dll и osaxst0.dll (и без них все отлично работает smile.gif )
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, может кто посмотрит отладочные надписи на большом компьютере. Я себе, конечно, соберу кабель, но это долго sad.gif XIP для прошивки ОС 5.2.1948 ATOM EXEC... Могу выложить и целиком diskimage_Ver.nb0 для RW6815.

 xip_out.zip ( 1.02 мегабайт ) : 11
 

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

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

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

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

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

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

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

25160: 01 02

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

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

CODE
...
STR R3, [R5,#4]
CMP R2, #5
BHI 0x54
BNE loc_28
LDRB R3, [R5,#3]
CMP R3, #1
BHI 0x54
...


Соответственно меняем гениальные 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

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

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

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

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

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

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

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

Цитата(ArHon @ 2.1.2008, 0:57) *
AGC, молодец! Как просохнешь, собирай всю инфу в кучу - и в подробностях расписывай портирование ядра с wm5 на wm6! Поздравляю!!!

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

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

Спасибо!

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

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

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

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

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

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

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

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

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

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

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

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

Да, по результатам сегодняшней апробации в нашей ветке выяснилось, что вставлять все родные драйвера, не самая лучшая идея. Я сейчас откатился на сборку с базовым набором (камера, экран, звук, клавиатура). Это еще нужно уточнять. Как минимум от 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 и других собратьев
По сути вся технология описана в предыдущих сообщениях, ниже просто постарался изложить как то более системно и детально конкретные действия, да добавил небольшие общие комментарии smile.gif

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". Они должны быть просто полностью идентичны приведенным ниже.

CODE
RW6815 WM5 WWE
~~~~~~~~~~~~~~
00000000 - 01f901fd L01f901fd NUL

01f901fd - 01f901fd L00000000 Start: first DLL address
01f901fd - 01fd3000 L00042e03 NUL
01fd3000 - 01fd4000 L00001000 initialized data of region_1 ceddk.dll
01fd4000 - 01fe3000 L0000f000 initialized data of region_1 TrueFFS.dll
01fe3000 - 01fe4000 L00001000 initialized data of region_2 cecompr.dll
01fe4000 - 01ff1000 L0000d000 initialized data of region_1 stratad_intel_l.dll
01ff1000 - 01ff2000 L00001000 initialized data of region_1 devmgr.dll
01ff2000 - 01ff3000 L00001000 initialized data of region_1 busenum.dll
01ff3000 - 01ff4000 L00001000 initialized data of region_1 mspart.dll
01ff4000 - 01ff5000 L00001000 initialized data of region_1 regenum.dll
01ff5000 - 01ff6000 L00001000 initialized data of region_1 imgfs.dll
01ff6000 - 01ff7000 L00001000 initialized data of region_1 fatfsd.dll
01ff7000 - 01ff9000 L00002000 initialized data of region_1 crypt32.dll
01ff9000 - 01ffa000 L00001000 initialized data of region_1 pm.dll
01ffa000 - 01ffb000 L00001000 initialized data of region_1 fatutil.dll
01ffb000 - 01ffc000 L00001000 initialized data of region_1 fsreplxfilt.dll
01ffc000 - 01ffd000 L00001000 initialized data of region_1 diskcache.dll
01ffd000 - 01ffe000 L00001000 initialized data of region_1 fsdmgr.dll
01ffe000 - 01fff000 L00001000 initialized data of region_1 certmod.dll
01fff000 - 02000000 L00001000 initialized data of region_1 coredll.dll
02000000 - 02000000 L00000000 End: last DLL address

02000000 - 03d70000 L01d70000 NUL
03d70000 - 03d76000 L00006000 Virtual base address of ceddk.dll
03d76000 - 03d80000 L0000a000 NUL
03d80000 - 03dcc000 L0004c000 Virtual base address of TrueFFS.dll
03dcc000 - 03dd0000 L00004000 NUL
03dd0000 - 03dd7000 L00007000 Virtual base address of cecompr.dll
03dd7000 - 03de0000 L00009000 NUL
03de0000 - 03df6000 L00016000 Virtual base address of stratad_intel_l.dll
03df6000 - 03e00000 L0000a000 NUL
03e00000 - 03e0c000 L0000c000 Virtual base address of devmgr.dll
03e0c000 - 03e10000 L00004000 NUL
03e10000 - 03e16000 L00006000 Virtual base address of busenum.dll
03e16000 - 03e20000 L0000a000 NUL
03e20000 - 03e28000 L00008000 Virtual base address of mspart.dll
03e28000 - 03e30000 L00008000 NUL
03e30000 - 03e34000 L00004000 Virtual base address of regenum.dll
03e34000 - 03e40000 L0000c000 NUL
03e40000 - 03e4a000 L0000a000 Virtual base address of imgfs.dll
03e4a000 - 03e50000 L00006000 NUL
03e50000 - 03e63000 L00013000 Virtual base address of fatfsd.dll
03e63000 - 03e70000 L0000d000 NUL
03e70000 - 03ee2000 L00072000 Virtual base address of crypt32.dll
03ee2000 - 03ef0000 L0000e000 NUL
03ef0000 - 03efd000 L0000d000 Virtual base address of pm.dll
03efd000 - 03f00000 L00003000 NUL
03f00000 - 03f09000 L00009000 Virtual base address of fatutil.dll
03f09000 - 03f10000 L00007000 NUL
03f10000 - 03f19000 L00009000 Virtual base address of fsreplxfilt.dll
03f19000 - 03f20000 L00007000 NUL
03f20000 - 03f25000 L00005000 Virtual base address of diskcache.dll
03f25000 - 03f30000 L0000b000 NUL
03f30000 - 03f45000 L00015000 Virtual base address of fsdmgr.dll
03f45000 - 03f50000 L0000b000 NUL
03f50000 - 03f5b000 L0000b000 Virtual base address of certmod.dll
03f5b000 - 03f60000 L00005000 NUL
03f60000 - 03ff5000 L00095000 Virtual base address of coredll.dll
03ff5000 - 80580000 L7c58b000 NUL
...


CODE
ATOM EXEC TRED RC3
~~~~~~~~~~~~~~~~~~
00000000 - 01f901fd L01f901fd NUL

01f901fd - 01f901fd L00000000 Start: first DLL address
01f901fd - 01fd1000 L00040e03 NUL
01fd1000 - 01fd2000 L00001000 initialized data of region_1 ceddk.dll
01fd2000 - 01fe1000 L0000f000 initialized data of region_1 TrueFFS.dll
01fe1000 - 01fe2000 L00001000 initialized data of region_2 cecompr.dll
01fe2000 - 01fef000 L0000d000 initialized data of region_1 stratad_intel_l.dll
01fef000 - 01ff0000 L00001000 initialized data of region_1 regenum.dll
01ff0000 - 01ff1000 L00001000 initialized data of region_1 pm.dll
01ff1000 - 01ff2000 L00001000 initialized data of region_1 mspart.dll
01ff2000 - 01ff3000 L00001000 initialized data of region_1 imgfs.dll
01ff3000 - 01ff4000 L00001000 initialized data of region_1 fsreplxfilt.dll
01ff4000 - 01ff5000 L00001000 initialized data of region_1 fsdmgr.dll
01ff5000 - 01ff6000 L00001000 initialized data of region_1 fatutil.dll
01ff6000 - 01ff7000 L00001000 initialized data of region_1 fatfsd.dll
01ff7000 - 01ff8000 L00001000 initialized data of region_1 encfilt.dll
01ff8000 - 01ff9000 L00001000 initialized data of region_1 diskcache.dll
01ff9000 - 01ffa000 L00001000 initialized data of region_1 devmgr.dll
01ffa000 - 01ffc000 L00002000 initialized data of region_1 crypt32.dll
01ffc000 - 01ffd000 L00001000 initialized data of region_1 coredll.dll
01ffd000 - 01ffe000 L00001000 initialized data of region_1 certmod.dll
01ffe000 - 01fff000 L00001000 initialized data of region_1 cachefilt.dll
01fff000 - 02000000 L00001000 initialized data of region_1 busenum.dll
02000000 - 02000000 L00000000 End: last DLL address

02000000 - 03def000 L01def000 NUL
03def000 - 03df5000 L00006000 Virtual base address of ceddk.dll
03df5000 - 03e41000 L0004c000 Virtual base address of TrueFFS.dll
03e41000 - 03e48000 L00007000 Virtual base address of cecompr.dll
03e48000 - 03e5e000 L00016000 Virtual base address of stratad_intel_l.dll
03e5e000 - 03e62000 L00004000 Virtual base address of regenum.dll
03e62000 - 03e71000 L0000f000 Virtual base address of pm.dll
03e71000 - 03e79000 L00008000 Virtual base address of mspart.dll
03e79000 - 03e83000 L0000a000 Virtual base address of imgfs.dll
03e83000 - 03e8d000 L0000a000 Virtual base address of fsreplxfilt.dll
03e8d000 - 03ea2000 L00015000 Virtual base address of fsdmgr.dll
03ea2000 - 03eab000 L00009000 Virtual base address of fatutil.dll
03eab000 - 03ebe000 L00013000 Virtual base address of fatfsd.dll
03ebe000 - 03eca000 L0000c000 Virtual base address of encfilt.dll
03eca000 - 03ed0000 L00006000 Virtual base address of diskcache.dll
03ed0000 - 03edc000 L0000c000 Virtual base address of devmgr.dll
03edc000 - 03f4e000 L00072000 Virtual base address of crypt32.dll
03f4e000 - 03fe4000 L00096000 Virtual base address of coredll.dll
03fe4000 - 03ff0000 L0000c000 Virtual base address of certmod.dll
03ff0000 - 03ffa000 L0000a000 Virtual base address of cachefilt.dll
03ffa000 - 04000000 L00006000 Virtual base address of busenum.dll
04000000 - 80180000 L7c180000 NUL
...

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")
CODE
9ad20b2c - 9ad20b80 L00000054 rom_00 header: dlls=01f901fd-02000000 phys=9ac00000-9aea931c, 24 modules, 7 files, 4 copyentries ext=9ac0278c ram=80580000-84000000 cputype=000001c2

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

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

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

16. Ищем в новом map.txt строку (можно по rom_00)
CODE
9adb19d4 - 9adb1a28 L00000054 rom_00 header: dlls=01f901fd-02000000 phys=9ac00000-9afe2990, 24 modules, 8 files, 2 copyentries ext=9ac0271c ram=80180000-84000000 cputype=000001c2

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

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

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

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

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

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

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

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

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. Извиняюсь за столь подробное изложение, наверняка ряд вещей очевиден. Но со временем все забывается, чтобы самому потом мучительно не вспоминать. Да и писал сразу и для новичков с других устройств, чтобы не осталось неясностей и можно было при необходимости действовать по аналогии smile.gif Потом, если будут силы, попробую дописать уточненную общую инструкцию, которая приведена соседней ветке форума на английском, т.к. вещи по релоку модулей и правке nk.exe при портировании с WM6 на WM5 там как то не затронуты (да и вообще в явном и собранном виде этого нигде не нашел).

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

Огромное спасибо AGC за его труд, но я все-таки думаю, что портирование устройство-зависимых файлов правильнее, чем наоборот. Так что выкладываю свой вариант мануала по портированию. Подчеркиваю, что нашел всю информацию и собрал все в кучу AGC, за что ему хвала и благодарность! biggrin.gif
Итак:
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:

Код
[HKEY_LOCAL_MACHINE\MUI]
    "Enable"=dword:1
[HKEY_LOCAL_MACHINE\MUI]
   "SysLang"=dword:409
[HKEY_CURRENT_USER\MUI]
   "CurLang"=dword:409

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

4. Смотрим состав папки XIP_NEW_COPY\Out\Modules\OemXipKernel и копируем с заменой такие же файлы из XIP_OLD\Out\Modules в XIP_NEW\Out\Modules
скорее всего, состав файлов будет следующим:
Код
cecompr.dll\
ceddk.dll\
giisr.dll\
nk.exe\
stratad_intel_l.dll\
trueffs.dll\
cecompr.dll.txt
ceddk.dll.txt
giisr.dll.txt
nk.exe.txt
stratad_intel_l.dll.txt
trueffs.dll.txt


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. Мануал писался при портировании хипа для ровера, прикладываю его - надо проверить.







 

 xip_out.rar ( 953.02 килобайт ) : 36
 

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

Цитата(ArHon @ 3.1.2008, 15:28) *
P.S. Мануал писался при портировании хипа для ровера, прикладываю его - надо проверить.

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

Инфа выдаваемая отладчиком в СОМ порт:
Код
OEMIPLInit: Shutdown Device, step1 !!!

OEMIPLInit: Shutdown Device, step2 !!!

OEMIPLInit: Shutdown Device, step3 !!!

OEMIPLInit: Shutdown Device, step4 !!!

after InitDisplay
clear  bUpdateMode flag!!!

INFO: Jumping to image...
Windows CE Kernel for ARM (Thumb Enabled) Built on Apr 13 2006 at 16:34:56
ProcessorType=0411  Revision=7
sp_abt=ffff1000 sp_irq=ffff0800 sp_undef=ffffc800 OEMAddressTable = 9ac05a34
dwCleanBootSign =0x00000000
PSPR =8008
RCNR=1e4b2e 1e4b24
User required clean boot!!
===>v_pMEMC->msc1:23f9
+OEMInit
OSVer:1.10.00 RUS
+Reset the BSPArg(a00ff000)
-OEMInit
+===>v_pMEMC->msc0:12801282
+===>v_pMEMC->msc1:23f9
+===>v_pMEMC->msc2:7ffcfff4
change IPM to 416Mhz
change IPM to 416Mhz
1===>v_pMEMC->msc0:15d015d2
1===>v_pMEMC->msc1:23f9
1===>v_pMEMC->msc2:7ffcfff4
Sp=ffffc7cc
Data Abort: Thread=83fcf024 Proc=80616fd0 'filesys.exe'
AKY=ffffffff PC=9ac3843c(NK.EXE+0x0003843c) RA=4558c000(???+0x4558c000) BVA=0464010b FSR=00000003
Data Abort: Thread=83fcf024 Proc=80616fd0 'filesys.exe'
AKY=ffffffff PC=03f689d4(???+0x03f689d4) RA=03f6a5c4(???+0x03f6a5c4) BVA=9ac01cb8 FSR=0000000d
Data Abort: Thread=83fcf024 Proc=80616fd0 'filesys.exe'
AKY=ffffffff PC=03f69700(???+0x03f69700) RA=0001ba04(filesys.exe+0x0000ba04) BVA=9ac01d68 FSR=0000000d

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

Цитата(alex_beda @ 3.1.2008, 19:24) *
Приложенный ХИП не запускается. Висит на ХР.
Но экран после передёргивания аккума уже не рябит. Тоже уже достижение. smile.gif

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

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

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

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

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

Вся прошивка целиком для Ровер 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 biggrin.gif И экран был Ок, пока аккумулятор не передернул. А после передергивания экран ушел в аут, рябит. LCCR бы найти, где в ядре устанавливаются. Тогда можно было бы попробовать ручками отредактировать под 6815... Сейчас еще попробую на это ядро наложить аппаратные драйвера от 6815, будет тоже вариант.

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

 xip_out_RoverG5_OS_5_2_1948.zip ( 1.08 мегабайт ) : 18
 

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

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

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

Цитата(ArHon @ 4.1.2008, 18:39) *
AGC, а хард ресет на роверовской прошивке попробовал?

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

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

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, к примеру), или просто в ресет, или в бутлоадер, где уже производится проверка нажатия софт-клавиш (именно поэтому приходится долго их держать). А вот почему он на них не реагирует - загадка та еще sad.gif Кстати, ты на роверовской проше нажимал именно трубки для хард ресета? Т.е. клавиши в ядре нормально замапены? Не поменялись с софткеями?

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

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

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

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

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

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

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

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

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

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

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

Цитата(ArHon @ 5.1.2008, 12:42) *
ВСЕ! Решение с хард ресетом найдено! biggrin.gif

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

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

Автор: Old Kind MadMike 5.1.2008, 17:00

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

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

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

Цитата(Old Kind MadMike @ 5.1.2008, 17:00) *
Господа, утилитку M'reloc_nk выложите, плиз?

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

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

 M__Reloc_nk.zip ( 205.47 килобайт ) : 26
 

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

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

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

Цитата(ArHon @ 5.1.2008, 17:26) *
AGC, я описал технологию в скрытом разделе

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

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

Автор: Old Kind MadMike 7.1.2008, 21:38

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

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

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

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

Автор: Old Kind MadMike 9.1.2008, 9:41

Цитата(AGC @ 9.1.2008, 7:57) *
Вот, по поводу архитектуры и ассемблера нашел информацию. Может какой отдельный раздел создать по архитектуре CE и программированию под ARMы? smile.gif


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

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

Цитата(Old Kind MadMike @ 9.1.2008, 9:41) *
Может, для начала ограничиться темой?
Тему щас сделаю - наполнение за тобой, я в этом ламер wink.gif

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

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

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

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

Автор: Old Kind MadMike 6.2.2008, 15:03

Цитата
инструкция по портированию новой версии ОС

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

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

Цитата(Old Kind MadMike @ 6.2.2008, 15:03) *
Этот рецепт только для обновления сборки ОС применим.
При переходе на другой язык или с 5-й на 6-ю он уже вряд ли прокатит.

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

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

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

Автор: Old Kind MadMike 9.2.2008, 11:11

Цитата
А так... Ну другой язык - это отдельный разговор В принципе, тут как раз вроде сложностей особых нет, если есть нужные файлики MUI, я же описывал в ветке по русификации полный механизм... В смысле, XIP тут вообще не важен...

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

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

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

Цитата(Old Kind MadMike @ 9.2.2008, 11:11) *
Ой ли? Я когда общался с k0ster'ом на 4pda - он мне объяснял русификацию как раз через портирование системных модулей в XIP и imgfs.

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

Если более подробно, то язык в 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) - это принцип исполнения в вольном переводе "где лежу, там и пашу" smile.gif По нему работает не только ядро (собственно, из-за этого и нужен "правильный" релок ядра), но и многие модули ОС...

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

Автор: Old Kind MadMike 11.2.2008, 9:56

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

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

Цитата(Old Kind MadMike @ 11.2.2008, 9:56) *
Мы с ним говорили не про перевод через MUI, а про перевод через портирование системы с русской WM6 для другого устройства.
k0ster говорил, что одной заменой SYS в imgfs не отделаешься - придется портировать и XIP.

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

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

Автор: Old Kind MadMike 11.2.2008, 14:47

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

Помню конечно smile.gif

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

Old Kind MadMike

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


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

Автор: Old Kind MadMike 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. Прошиваемся.

Автор: Old Kind MadMike 26.2.2008, 15:14

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

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

Цитата(Old Kind MadMike @ 26.2.2008, 15:14) *
Я правильно понимаю, что процедура настолько проста лишь потому, что WM6 - это на самом деле WM5.2?
Т.е. при более серьезной разнице между WM5 и WM2003 все будет заметно сложнее...

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

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

Цитата(Old Kind MadMike @ 26.2.2008, 15:14) *
Я правильно понимаю, что процедура настолько проста лишь потому, что WM6 - это на самом деле WM5.2?
Т.е. при более серьезной разнице между WM5 и WM2003 все будет заметно сложнее...


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

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


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

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

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

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

Цитата(salman DZ @ 2.3.2008, 12:27) *
Помогите разобраться как ХИП обратно в ром вставить прога Русский WinHex 13.5 SR-3 непойму где указать адрес с которого вставлять новый ХИП, если можно скришопы как это делается

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

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

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

Автор: Old Kind MadMike 2.3.2008, 21:06

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

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

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

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

Русская версия Invision Power Board (http://nulled.cc)
© Invision Power Services (http://nulled.cc)