Autor Wątek: Gotowanie dla Toshiby G900  (Przeczytany 8985 razy)

Offline globalbus

  • GZU
  • Core
  • ****
  • Podziękowań: 77
  • N900 + Zest
Gotowanie dla Toshiby G900
« dnia: Piątek, 26 Wrzesień 2008, 14:45 »
Ostatnio zainteresowałem się tym urządzeniem, parametry niezłe, w miarę tanie itd.
Jeden szczegół, soft fabryczny jest skopany, normalnie jak eten :p

Pierwszy szczegół, na to zagadnienie kompletnie nic nie znalazłem. Na moim hermesie im mniejszy rom, tym więcej storage do dyspozycji. Na toshibie storage jest w jakiś sposób określony na stałe, wszystko wyjaśnił komunikat z imgfstonb "no storage region found".
Zmieniłem offset 0x0C w sekcji msflsh na "54", pokazało się "storage region was found", tylko ciągle pamięć storage jest nieruszona. Ponoć podobna sytuacja była na blueangel i himalaya, więc może ktoś ma dla mnie wskazówkę ;)

Sprawa druga, fabrycznie XIP jest kompresowany, ale jakoś idzie wstawić XIP bez kompresji w to samo miejsce. Na hermesie przywyczaiłem się do używania buildxip + insert, ale na tośkowym romie insert jakoś nie działa, ale nie wiem czemu. Odpalanie za każdym razem hex editora albo xipport jakoś mi się nie widzi. Jest jakiś dobry sposób wklepania xip'a z konsoli oprócz insert.exe ?

Offline utak3r

  • Global Moderator
  • Core
  • *****
  • Podziękowań: 140
  • Samsung Note 4
Odp: Gotowanie dla Toshiby G900
« Odpowiedź #1 dnia: Piątek, 26 Wrzesień 2008, 16:37 »
Stała wielkość ROMu i Storage to nawet na Wizardzie jest  :8) i zmniejszanie obrazu nic w tej materii nie daje, zostaje puste, niewykorzystane miejsce.
Jeśli mówisz o Hima, to tam była inna historia, po prostu zostały przeformatowane partycje Storage i ExtRom w jedną większą, więc to nie jest ten przypadek.

A co do XIPa.... jest 'pakowacz' XIPów, tylko za diabła teraz nie pamiętam nazwy... SRPX czy siakoś tak ;) gdybyś dał między buildem a insertem... powinno załapać, wczoraj miałem relację na żywo na GG ;) z budowania ROMu na HP614c, też ze skompresowanym XIPem i poszło :)



dodano: Piątek, 26 Wrzesień 2008, 16:36

acha... no i witamy w naszych skromnych progach  :D


Offline globalbus

  • GZU
  • Core
  • ****
  • Podziękowań: 77
  • N900 + Zest
Odp: Gotowanie dla Toshiby G900
« Odpowiedź #2 dnia: Piątek, 26 Wrzesień 2008, 17:21 »
Cytuj
Stała wielkość ROMu i Storage to nawet na Wizardzie jest   i zmniejszanie obrazu nic w tej materii nie daje, zostaje puste, niewykorzystane miejsce.
Czyli mówisz, że nic z tym nie wskóram? Szok, że tyle miejsca się marnuje, na hermesie 80MB wyciągam :oT

Fakt, SRPX można spakować, ale insert i tak się wywala. Poza tym chyba kompresja XIP to nie jest dobry pomysł?

No cóż, zostaje XIPPort i klepanie mu za każdym razem adresu, może da się go jakoś z konsoli mu podać  ?-?

Ehh, buildxip też się nie sprawdza, robi sieczkę z relokacją. Trzeba wrócić do archiwalnych metod...
« Ostatnia zmiana: Piątek, 26 Wrzesień 2008, 18:04 wysłana przez globalbus »


Offline utak3r

  • Global Moderator
  • Core
  • *****
  • Podziękowań: 140
  • Samsung Note 4
Odp: Gotowanie dla Toshiby G900
« Odpowiedź #3 dnia: Piątek, 26 Wrzesień 2008, 19:45 »
buildxip do poprawnego złożenia XIPa wymaga poprawnego pliku romhdr.bin. Masz go dobrego?
Jak się nie da... no cóż, powrót do korzeni ;) Ja np. na siłę się prawie zmuszam do tych nowych, wolę hardcore ;) Przynajmniej człowiek rozumie, co robi.

Offline globalbus

  • GZU
  • Core
  • ****
  • Podziękowań: 77
  • N900 + Zest
Odp: Gotowanie dla Toshiby G900
« Odpowiedź #4 dnia: Piątek, 26 Wrzesień 2008, 20:30 »
Cytuj
poprawnego pliku romhdr.bin
romhdr jest na tyle poprawny, na ile przygotowała go toshiba/wyjmuje go dumprom.  ;)

Wygląda to mniej więcej tak (XIP oryginalny przebudowany buildxip przy użyciu oryginalnego romhdr.bin)
806f6000 - 806f6000 L00000000 Start: start of RAM
806f6000 - 80723000 L0002d000 initialized data of region_3 nk.exe
80723000 - 80724000 L00001000 initialized data of region_1 osaxst1.dll
80724000 - 80728000 L00004000 initialized data of region_1 osaxst0.dll
80728000 - 80729000 L00001000 initialized data of region_1 hd.dll
80729000 - 80736000 L0000d000 NUL
80736000 - 80749000 L00013000 initialized data of region_1 kd.dll
80749000 - 80750000 L00007000 NUL
80750000 - 80751000 L00001000 initialized data of region_1 giisr.dll
80750000 - 80751000 L00001000 !!!!!!!!!!!!!!!!!!
80750000 - 80756000 L00006000 uninitialized data of region_2 nk.exe
80751000 - 80756000 L00005000 !!!!!!!!!!!!!!!!!!
80751000 - 80751000 L00000000 ------ start of RAM free space
80751000 - 84000000 L038af000 NUL
84000000 - 84000000 L00000000 End: end of RAM
Więc wychodzi na to, że muszę poprawiać buildxip'a, bez sensu  :p

Obstawiam, że albo romhdr.bin jest skopany wewnętrznie w romie, albo dumprom nie potrafi go wyjąć.

Mam pytanie, czy przypadkiem pomiędzy romhdr.txt i pathhdr.txt (tworzonym przez xipport), a romhdr.bin nie zachodzi taka sama zależność jak pomiędzy imageinfo.txt, a imageinfo.bin?
Teoretycznie parę godzin porównywania romów różnych urządzeń i może bym znalazł poprawne romhdr.bin  :p

EDIT: dokładnie, romhdr.bin zawiera te same informacje co romhdr.txt
Jeden szczegół, wartości czytamy od tyłu :P
« Ostatnia zmiana: Piątek, 26 Wrzesień 2008, 20:43 wysłana przez globalbus »


Offline utak3r

  • Global Moderator
  • Core
  • *****
  • Podziękowań: 140
  • Samsung Note 4
Odp: Gotowanie dla Toshiby G900
« Odpowiedź #5 dnia: Piątek, 26 Wrzesień 2008, 20:44 »
No to faktycznie nakaszanione zdrowo  ?-?
A co na to funkcja Realloc P z XIPPorta? Zakładam, że .VM i .ROM w kuchni masz poprawne... więc może on sobie poradzi?

Offline globalbus

  • GZU
  • Core
  • ****
  • Podziękowań: 77
  • N900 + Zest
Odp: Gotowanie dla Toshiby G900
« Odpowiedź #6 dnia: Piątek, 26 Wrzesień 2008, 20:50 »
Realloc P nic z tym nie robi, zostawia tak jak jest.
.VM i .ROM też nie byłbym taki pewny ich poprawności, w końcu to toshiba ;)

Fakt, faktem .VM musi jakoś działać, bo po dodaniu kilku nowych modułów i przejechaniu G'Reloc ROM wstaje, dopóki nie użyję buildxip  :oT

hmm wydaje się, że romhdr.bin jest poprawny, zawiera te same dane co romhdr.txt z oryginalnego xip'a G900
« Ostatnia zmiana: Piątek, 26 Wrzesień 2008, 21:18 wysłana przez globalbus »

Offline utak3r

  • Global Moderator
  • Core
  • *****
  • Podziękowań: 140
  • Samsung Note 4
Odp: Gotowanie dla Toshiby G900
« Odpowiedź #7 dnia: Piątek, 26 Wrzesień 2008, 21:17 »
No to uważaj, bo buildxip zmienia zawartość .VM i .ROM.....  :8)

Offline globalbus

  • GZU
  • Core
  • ****
  • Podziękowań: 77
  • N900 + Zest
Odp: Gotowanie dla Toshiby G900
« Odpowiedź #8 dnia: Piątek, 26 Wrzesień 2008, 21:42 »
dobra, może nie jest to ultra szybkie portowanie xip, ale jakoś działa.
1. na razie wszystko po staremu, przekładamy pliki i uruchamiamy buildxip
2. uruchamiamy xipport, robimy dump
3. podmieniamy pathhdr.txt i romhdr.txt oraz imageinfo.bin i imageinfo.txt w modułach giisr.dll i nk.exe z oryginalnego xip'a tosi
4. klikamy realloc p w xipport i już nie mamy zachodzących na siebie fragmentów ;)
Może komuś się to przyda.

Offline utak3r

  • Global Moderator
  • Core
  • *****
  • Podziękowań: 140
  • Samsung Note 4
Odp: Gotowanie dla Toshiby G900
« Odpowiedź #9 dnia: Piątek, 26 Wrzesień 2008, 21:48 »
 :ww:
aż mi brakuje odpowiedniej emotki ;)

Grunt, że działa.


Offline mobi

  • Administrator
  • Core
  • *****
  • Podziękowań: 351
  • Wizard/HD2/Kaiser/SGS3/HTC E8/HTC 10/Xiaomi MiA1
Odp: Gotowanie dla Toshiby G900
« Odpowiedź #10 dnia: Piątek, 26 Wrzesień 2008, 22:30 »
(zmieniłem Ci grupę, i już możesz nie Startować)

Offline globalbus

  • GZU
  • Core
  • ****
  • Podziękowań: 77
  • N900 + Zest
Odp: Gotowanie dla Toshiby G900
« Odpowiedź #11 dnia: Środa, 08 Październik 2008, 19:48 »
wracając do tematu, idzie jakoś usunąć partycję z ULDR? Tzn wiem, że można ją bez problemu usunąć z pliku z romem, ale nie trzeba przypadkiem czegoś poprawić w boot.bin, albo msflsh.bin ?-?

Wiem, że w hermesie ext_rom da się usunąć zmieniając boot.bin i sterownik partycji ;)

Ok, nie było pytania. pdocread -l wszystko wyjaśnił, jest ileś tam partycji trueffs, które składają się z part'ów. Part'ami można spokojnie żonglować...
« Ostatnia zmiana: Czwartek, 09 Październik 2008, 21:02 wysłana przez globalbus »


lupus

  • Gość
Odp: Gotowanie dla Toshiby G900
« Odpowiedź #12 dnia: Środa, 22 Październik 2008, 23:29 »
Clean & Clear ROM RC for G900
mocna i dobra rzecz można by tu wrzucić... :peace:

Offline globalbus

  • GZU
  • Core
  • ****
  • Podziękowań: 77
  • N900 + Zest
Odp: Gotowanie dla Toshiby G900
« Odpowiedź #13 dnia: Czwartek, 23 Październik 2008, 15:58 »
próbuję rozkminić tablicę partycji DoC ??? http://www.4shared.com/file/68081270/6073ab98/boot.html
Wiem, że hex 00-03 to nagłówek
hex 1CA-1CB - liczba sektorów pierwszego i jedynego XIPa (uldr wyleciał) Czytamy wspak, czyli jeśli mamy FE 19, to liczba sektorów to 19FE=6654
hex 1FE-1FF - stopka

ktoś może wie co oznacza reszta znaczków?

hex 1DA-1DC - liczba sektorów imgfs, czytane tradycyjnie wspak

czy to możliwe, że podział na TFFS odbywa się jeszcze gdzieś wyżej?
« Ostatnia zmiana: Czwartek, 23 Październik 2008, 18:27 wysłana przez globalbus »

Offline utak3r

  • Global Moderator
  • Core
  • *****
  • Podziękowań: 140
  • Samsung Note 4
Odp: Gotowanie dla Toshiby G900
« Odpowiedź #14 dnia: Piątek, 24 Październik 2008, 09:52 »
Zapodam Ci fragment nieukończonego (jak zwykle) ciągle jeszcze mojego artykułu. Wycinek dotyczy MSFLSH50:

Jest to najbardziej interesująca sekcja, zawierająca najważniejsze dane i parametry ROMu.
Zaczyna się od napisu "MSFLSH50", czyli od sekwencji 4D 53 46 4C 53 48 35 30, jej długość to maksymalnie 512 bajtów. Powinieneś znaleźć ją pod adresem 0x200, czyli tuż za sekcją Boot.
Tak naprawdę, te 512 bajtów jest zarezerwowane na przyszłe ewentualne wybryki speców robiących ROMy dla urządzeń Oczko Prawdziwa długość sekcji określona jest w 12 bajcie, i dla Wizarda najczęściej jest to wartość 56 bajtów, czyli całkiem sporo zostaje. Ta reszta zostaje wypełniona wartościami 0xFF.

Co możemy z tych 56 bajtów odczytać?
- Początek bloku imgfs (systemu plików). To 4 bajty, począwszy od adresu 0x19. Na przykład: 00 00 00 62, co przekłada się na adres 0x00620000.
Ciekawostka: Nothin, interesujący Cię OS.nb (wiesz, który) ma tutaj wprowadzony adres 0x00300000.
- Liczba sektorów w jednym bloku (0x1F-0x22). Na przykład: 00 80 00 00, czyli 128 sektorów na blok.
- Rozmiar jednego bloku (0x23-0x26). Na przykład: 00 00 00 01, czyli 65536 bajtów.
- Liczba bloków w całym imgfs (0x38-0x39). Na przykład: 2E 03, czyli 0x32E = 814 bloków.
- Powtórzona liczba sektorów w jednym bloku (0x3B-0x3E). Na przykład: 00 80 00 00, czyli 128 sektorów na blok.
- Powtórzony rozmiar jednego bloku (0x3F-0x42). Na przykład: 00 00 00 01, czyli 65536 bajtów.

Do tego dam Ci fragment z Platform Buildera, z pliku romldr.h:
#define ROM_SIGNATURE_OFFSET 64
#define ROM_SIGNATURE 0x43454345

#define ROM_EXTRA 9

typedef struct e32_rom {
    unsigned short  e32_objcnt;     /* Number of memory objects            */
    unsigned short  e32_imageflags; /* Image flags                         */
    unsigned long   e32_entryrva;   /* Relative virt. addr. of entry point */
    unsigned long   e32_vbase;      /* Virtual base address of module      */
    unsigned short  e32_subsysmajor;/* The subsystem major version number  */
    unsigned short  e32_subsysminor;/* The subsystem minor version number  */

    unsigned long   e32_stackmax;   /* Maximum stack size                  */
    unsigned long   e32_vsize;      /* Virtual size of the entire image    */
    unsigned long   e32_sect14rva;  /* section 14 rva */
    unsigned long   e32_sect14size; /* section 14 size */

    struct info     e32_unit[ROM_EXTRA]; /* Array of extra info units      */
    unsigned short  e32_subsys;     /* The subsystem type                  */
} e32_rom;

// o32_flags
#define IMAGE_SCN_COMPRESSED                 0x00002000  // Section is compressed
typedef struct o32_rom {
    unsigned long       o32_vsize;      /* Virtual memory size              */
    unsigned long       o32_rva;        /* Object relative virtual address  */
    unsigned long       o32_psize;      /* Physical file size of init. data */
    unsigned long       o32_dataptr;    /* Image pages offset               */
    unsigned long   o32_realaddr;       /* pointer to actual                */
    unsigned long       o32_flags;      /* Attribute flags for the object   */
} o32_rom;


typedef struct ROMHDR {
    ULONG   dllfirst;               // first DLL address
    ULONG   dlllast;                // last DLL address
    ULONG   physfirst;              // first physical address
    ULONG   physlast;               // highest physical address
    ULONG   nummods;                // number of TOCentry's
    ULONG   ulRAMStart;             // start of RAM
    ULONG   ulRAMFree;              // start of RAM free space
    ULONG   ulRAMEnd;               // end of RAM
    ULONG   ulCopyEntries;          // number of copy section entries
    ULONG   ulCopyOffset;           // offset to copy section
    ULONG   ulProfileLen;           // length of PROFentries RAM
    ULONG   ulProfileOffset;        // offset to PROFentries
    ULONG   numfiles;               // number of FILES
    ULONG   ulKernelFlags;          // optional kernel flags from ROMFLAGS .bib config option
    ULONG   ulFSRamPercent;         // Percentage of RAM used for filesystem
                                        // byte 0 = #4K chunks/Mbyte of RAM for filesystem 0-2Mbytes 0-255
                                        // byte 1 = #4K chunks/Mbyte of RAM for filesystem 2-4Mbytes 0-255
                                        // byte 2 = #4K chunks/Mbyte of RAM for filesystem 4-6Mbytes 0-255
                                        // byte 3 = #4K chunks/Mbyte of RAM for filesystem > 6Mbytes 0-255

    ULONG   ulDrivglobStart;        // device driver global starting address
    ULONG   ulDrivglobLen;          // device driver global length
    USHORT  usCPUType;              // CPU (machine) Type
    USHORT  usMiscFlags;            // Miscellaneous flags
    void    *pExtensions;           // pointer to ROM Header extensions
    ULONG   ulTrackingStart;        // tracking memory starting address
    ULONG   ulTrackingLen;          // tracking memory ending address
} ROMHDR;
// followed by nummods <TOCentry>'s
typedef struct TOCentry {           // MODULE BIB section structure
    DWORD dwFileAttributes;
    FILETIME ftTime;
    DWORD nFileSize;
    LPSTR   lpszFileName;
    ULONG   ulE32Offset;            // Offset to E32 structure
    ULONG   ulO32Offset;            // Offset to O32 structure
    ULONG   ulLoadOffset;           // MODULE load buffer offset
} TOCentry, *LPTOCentry;

// followed by numfiles <TOCentry>'s
typedef struct FILESentry {         // FILES BIB section structure
    DWORD dwFileAttributes;
    FILETIME ftTime;
    DWORD nRealFileSize;
    DWORD nCompFileSize;
    LPSTR   lpszFileName;
    ULONG   ulLoadOffset;           // FILES load buffer offset
} FILESentry, *LPFILESentry;

typedef struct COPYentry {
    ULONG   ulSource;               // copy source address
    ULONG   ulDest;                 // copy destination address
    ULONG   ulCopyLen;              // copy length
    ULONG   ulDestLen;              // copy destination length
                                    // (zero fill to end if > ulCopyLen)
} COPYentry;

#define MAX_ROM                 32      // max numbler of XIPs
#define XIP_NAMELEN             32      // max name length of XIP
#define ROM_CHAIN_OFFSET        0x100   // offset for XIPCHAIN_INFO

typedef struct _XIPCHAIN_ENTRY {
    LPVOID  pvAddr;                 // address of the XIP
    DWORD   dwLength;               // the size of the XIP
    DWORD   dwMaxLength;            // the biggest it can grow to
    USHORT  usOrder;                // where to put into ROMChain_t
    USHORT  usFlags;                // flags/status of XIP
    DWORD   dwVersion;              // version info
    CHAR    szName[XIP_NAMELEN];    // Name of XIP, typically the bin file's name, w/o .bin
    DWORD   dwAlgoFlags;            // algorithm to use for signature verification
    DWORD   dwKeyLen;               // length of key in byPublicKey
    BYTE    byPublicKey[596];       // public key data
} XIPCHAIN_ENTRY, *PXIPCHAIN_ENTRY;

typedef struct _XIPCHAIN_INFO {
    DWORD cXIPs;
    //
    // may contain more than one entry, but we only need the address of first one
    //
    XIPCHAIN_ENTRY xipEntryStart;
} XIPCHAIN_INFO, *PXIPCHAIN_INFO;

#define PID_LENGTH 10
// pointed to by ROMHDR.pExtensions
typedef struct ROMPID {
  union{
    DWORD dwPID[PID_LENGTH];        // PID
    struct {
      char  name[(PID_LENGTH - 4) * sizeof(DWORD)];
      DWORD type;
      PVOID pdata;
      DWORD length;
      DWORD reserved;
    } s;
  };
  PVOID pNextExt;                 // pointer to next extension if any
} ROMPID, EXTENSION;