Boot-magic...

Hej!

I min iver att lära mig hur saker hänger ihop i denna roliga telefon så har jag nu fattat lite mer om vad som skiljer PVT32A och PVT32B...i alla fall några av skillnaderna. Denna guide/information riktar sig till "advanced readers"...så var beredd på det.

För att kunna få "root" access i ett "adb shell" så måste en setting i "default.prop" vara satt, nämligen "ro.secure". Denna fil ligger dock på "ram-disken" och är "read-only"...dvs man kan inte ändra på den helt lätt.

För att kunna ändra i "default.prop" så måste man packa upp en "boot.img" (detta måste göras i Linux eller MacOS då alla host tools etc bara funkar där...), ändra i filen när den ligger upp-packad i Linux filsystemet...och sedan använda lite verktyg för att packa ihop den igen. (Se denna länk för detaljer.)

Dock så finns det ett litet problem. Det verktyg man kör "mkbootimg" (finns här i GIT-repot för Android) används för att packa ihop en kompilerad kernel samt en ram-disk (där default.prop ligger).

Verktyget "mkbootimg" kommer att bygga en fil (dvs boot.img) enligt detta (lånat från sidan som refas ovan):

Kod:

 +-----------------+
 | boot header     | 1 page
 +-----------------+
 | kernel          | n pages  
 +-----------------+
 | ramdisk         | m pages  
 +-----------------+
 | second stage    | o pages
 +-----------------+

 n = (kernel_size + page_size - 1) / page_size
 m = (ramdisk_size + page_size - 1) / page_size
 o = (second_size + page_size - 1) / page_size

 0. all entities are page_size aligned in flash
 1. kernel and ramdisk are required (size != 0)
 2. second is optional (second_size == 0 -> no second)

Det som är trixigt är att i "headern" så ligger information om vad som finns i filen, dvs var/hur stor ram-disken är, var/hur stor kernel är osv. Det finns också en "physical load address" för varje del. Detta är en adress som används när boot-strap (dvs den allra första booten...) laddar "boot.img" och skall kopiera upp ramdisk och kernel till RAM. Boot-strap kommer då att kopiera dem till RAM (de adresser som står i "boot.img")....och det är alltså en av de saker som skiljer en PVT32A och PVT32B. Man har lite olika konfigurationer (olika radio-hw t.ex.) och då är dessa adresser inte samma för A respektive B. Det är detta som gör att en "boot.img" från en PVT32B tvärhänger i en PVT32A. Om man däremot packar om den funkar den bättre (dock kan det ju vara mer i kernel/drivers som behöver ändras så det kanske tvärhänger ändå...fast någon millisekund senare).

Så....slutsaten (och jag har även provat) är då att om man packar ihop en ny boot.img med "mkbootimg" som finns i GIT (alltså det man får när man kompilerar Android sourcen från scratch) kommer alltså inte att passa för PVT32A! Även om det var en PVT32A boot.img man packade upp.

Det jag gjorde var att ta en "boot.img" från en PVT32A (via Nandroid backup) och titta på "physical load address" i denna (en hex-editor). Sedan tog jag helt enkelt och ändrade dessa i källkoden till "mkbootimg" och kompilerade om denna. Med denna nya version av mkbootimg så funkade det sedan att "packa ihop" denna upp-packade "boot.img" igen...dvs vi kan alltså "root:a" en "boot.img" även om vi inte har någon rootad "boot.img" innan!

Här ser ni (en del av källkoden) som jag ändrat och alltså de nya adresserna som behövs för en PVT32A HTC Magic (alltså INGEN ANNAN TELEFON!).

Kod:

...
    strcpy(hdr.name, board);

    hdr.kernel_addr =  0x19208000;
    hdr.ramdisk_addr = 0x1A200000;
    if(saddr) {
        hdr.second_addr =  0x00300000;
    } else {
        hdr.second_addr =  0x1A100000;
    }
    hdr.tags_addr   =  0x19200100;
    hdr.page_size = pagesize;

    memcpy(hdr.magic, BOOT_MAGIC, BOOT_MAGIC_SIZE);
...

Detta (nedanför) är från GIT-repot...och alltså även det som funkar för en PVT32B. Vet inte varför just denna version ligger i repot då de flesta tillverkare säkert måste meka en sådan mkbootimg själva om de inte bygger precis som en PVT32B.

Kod:

...
   strcpy(hdr.name, board);

   hdr.kernel_addr =  0x10008000;
   hdr.ramdisk_addr = 0x11000000;
   if(saddr) {
      hdr.second_addr =  0x00300000;
   } else {
      hdr.second_addr =  0x10F00000;
   }
   hdr.tags_addr   =  0x10000100;
   hdr.page_size = pagesize;

...

Allt detta är goda nyheter för "kommande" telefoner. Om vi kan trolla ut en "boot.img" (via tex Nandroid eller liknande) så kan vi kanske packa om denna. Skulle det vara så att det är andra "physical load addresses" i den så kan vi skapa nya versioner av "mkbootimg" med detta koncept. Med lite tur så funkar det t.ex. för Galaxy etc.

För de som vill prova detta så skickar jag även med min kompilerade version av mkbootimg, kallad "mkbootimg-PVT32A" och den är kompilerad i senaste Ubuntu 9.04 32-bit (dvs beroende av de lib etc som finns där).

Mvh
Gruffy

 

bra jobbat.

 

Bra jobbat men vi hade redan en fungerande mkbootimage-h binary som just passade pvt32a kan gissa att det var samma som du har fixat . Men va kul! nu har vi en som KAN lite mera saker och kanske vi kan få ihop en ny kärna snart!
bra jobbat!

 

Hehe...jaja...jag lärde ju mig i alla fall en del på köpet... Nu vet vi ju vad som skiljer dem då ialla fall.
/Gruffy

 

Bra jobbat gruffy!

Har ni en fastboot för PVT32A också? Kollade precis koden, och samma offsets finns där och används om boot.img skapas av fastboot.

 

Hrm...skall kolla och se om source finns till den i repot, då borde jag kunna meka om den ganska smidigt. Återkommer i ärendet...sitter på kneget just nu så det får bli senare.
/Gruffy

 

Nu har jag ingen Magic, men vad jag förstått av diverse källor på nätet är en ganska stor skillnad mellan PVT32A och -B hur stor intern disk de har (minns inte vilken som är störst). En anledning till att en SPL för -A inte funkar för -B och tvärtom är att SPL:en partitionerar den interna disken (delar upp i bl.a. /data och /system) och en partitioneringstabell för -A funkar således inte för -B. Anledningen till att man behöver byta SPL för att köra Hero-ROM:s är att de ROM:arna behöver annan fördelning av de olika partitionerna (mer plats i /system tror jag det är) än vad orginal-SPL:en ger.

Om ni vill ha reda på fler skillnader alltså.

 

Mycket intressant information :-)

 

Hrm...funderade lite igen. Med min fastboot.exe i SDK funkar det att boota en "boot.img" som jag gjort med ovanstående sätt...just därför att "physical load address" är rätt i "boot.img". Vad är det som inte funkar för dig i denna? (...så jag vet vad jag skall leta efter.) Kan man alltså "skapa" en boot.img med fastboot? Har ni mer info om detta?

/Gruffy

 

Jag har PVT32B, så det är inget problem för mig. Jag blev bara nyfiken på vad fastboot gjorde när man anger enbart kärnan (alltså utan ramdisk), vilket känns som det naturliga när man kompilerar och testar kärnor.
Vad jag kan se så skapar fastboot en boot.img med tom ramdisk som sedan laddas upp till telefonen. Man borde då få precis samma problem som när man skapar boot.img med en mkbootimg som har felaktiga adresser. Har man däremot en färdig boot.img så laddas den upp direkt.

Kolla load_bootable_image i fastboot.c och mkbootimg i bootimg.c (båda filerna i katalogen core/fastboot). Jag kan ju ha läst koden fel

 

Japp du har helt rätt. Samma funktion finns i fastboot. Det man vill ha är väl en Windows-version...skall forska lite i om det går att kompilera den i cygwin (eller hur man nu gör...för det går ju uppenbarligen). Kanske man tom med skull modda den lite så att den läser in dessa från en config-fil i stället....med tanke på att det kommer en drös telefoner snart... Jag återkommer i ärendet.

En Ubuntu-version kan jag nog skapa på beställning (dvs jag måste orka editera filen och skriva make...;-)
/Gruffy