android - Repack existing boot.img using mkbootimg (cyanogenmod 12.1, lollipop) -

-

this cross-post xda-developers, here knows solution. have trouble re-packing existing boot.img cyanogenmod 12.1 (lollipop 5.1) d2spr (sprint s3). resulting image not boot. built mkbootimg/unpackbootimg source found here: https://github.com/osm0sis/mkbootimg . following:

$ mkdir boot2 $ ../unpackbootimg -i boot.img -o boot2 board_kernel_cmdline androidboot.hardware=qcom user_debug=31 zcache androidboot.bootdevice=msm_sdcc.1 board_kernel_base 80200000 board_name  board_page_size 2048 board_kernel_offset 00008000 board_ramdisk_offset 01500000 board_tags_offset 00000100

this unpacks boot.img into:

$ ls -l boot2 total 7360 -rw-rw---- 1 galets galets       9 apr 22 08:59 boot.img-base -rw-rw---- 1 galets galets       1 apr 22 08:59 boot.img-board -rw-rw---- 1 galets galets      81 apr 22 08:59 boot.img-cmdline -rw-rw---- 1 galets galets       9 apr 22 08:59 boot.img-kerneloff -rw-rw---- 1 galets galets       5 apr 22 08:59 boot.img-pagesize -rw-rw---- 1 galets galets  663238 apr 22 08:59 boot.img-ramdisk.gz -rw-rw---- 1 galets galets       9 apr 22 08:59 boot.img-ramdiskoff -rw-rw---- 1 galets galets       9 apr 22 08:59 boot.img-tagsoff -rw-rw---- 1 galets galets 6842760 apr 22 08:59 boot.img-zimage

then repackage files without modification:

$ ../mkbootimg --kernel boot2/boot.img-zimage \ >              --ramdisk boot2/boot.img-ramdisk.gz \ >              --cmdline "androidboot.hardware=qcom user_debug=31 zcache androidboot.bootdevice=msm_sdcc.1" \ >              --base 0x80200000 \ >              --pagesize 2048 \ >              --output boot2.img $ ../boot_info boot2.img  page size: 2048 (0x00000800) kernel size: 6842760 (0x00686988) ramdisk size: 663238 (0x000a1ec6) second size: 0 (0x00000000) board name:  command line: 'androidboot.hardware=qcom user_debug=31 zcache androidboot.bootdevice=msm_sdcc.1' base address: 2149580800 (0x80200000)

for comparison, original boot:

$ ../boot_info boot.img  page size: 2048 (0x00000800) kernel size: 6842760 (0x00686988) ramdisk size: 663238 (0x000a1ec6) second size: 0 (0x00000000) board name:  command line: 'androidboot.hardware=qcom user_debug=31 zcache androidboot.bootdevice=msm_sdcc.1' base address: 2149580800 (0x80200000)

all seems fine. flash it:

$ heimdall flash --boot boot2.img  heimdall v1.4.0  copyright (c) 2010-2013, benjamin dobell, glass echidna http://www.glassechidna.com.au/  software provided free of charge. copying , redistribution encouraged.  if appreciate software , support future development please consider donating: http://www.glassechidna.com.au/donate/  initialising connection... detecting device... claiming interface... attempt failed. detaching driver... claiming interface again... setting interface...  initialising protocol... protocol initialisation successful.  beginning session...  devices may take 2 minutes respond. please patient!  session begun.  downloading device's pit file... pit file download successful.  uploading boot 100% boot upload successful  ending session... rebooting device... releasing device interface... re-attaching kernel driver...

and device won't boot. help!

edit: here's hex dump of beginning of 2 images:

$ hexdump -c boot.img | more 00000000  41 4e 44 52 4f 49 44 21  88 69 68 00 00 80 20 80  |android!.ih... .| 00000010  c6 1e 0a 00 00 00 70 81  00 00 00 00 00 00 10 81  |......p.........| 00000020  00 01 20 80 00 08 00 00  00 00 00 00 00 00 00 00  |.. .............| 00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 00000040  61 6e 64 72 6f 69 64 62  6f 6f 74 2e 68 61 72 64  |androidboot.hard| 00000050  77 61 72 65 3d 71 63 6f  6d 20 75 73 65 72 5f 64  |ware=qcom user_d| 00000060  65 62 75 67 3d 33 31 20  7a 63 61 63 68 65 20 61  |ebug=31 zcache a| 00000070  6e 64 72 6f 69 64 62 6f  6f 74 2e 62 6f 6f 74 64  |ndroidboot.bootd| 00000080  65 76 69 63 65 3d 6d 73  6d 5f 73 64 63 63 2e 31  |evice=msm_sdcc.1| 00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| * 00000240  bc 67 a2 74 d6 d0 01 0e  b4 56 47 6f bd ad 4d 85  |.g.t.....vgo..m.| 00000250  30 c1 ee 43 00 00 00 00  00 00 00 00 00 00 00 00  |0..c............| 00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| * 00000800  00 00 a0 e1 00 00 a0 e1  00 00 a0 e1 00 00 a0 e1  |................| * 00000820  02 00 00 ea 18 28 6f 01  00 00 00 00 88 69 68 00  |.....(o......ih.| 00000830  01 70 a0 e1 00 00 30 e3  00 80 a0 11 02 80 a0 01  |.p....0.........| 00000840  20 30 9f e5 00 00 93 e5  1c 10 9f e5 01 00 30 e1  | 0............0.| 00000850  06 00 00 1a 00 00 a0 e3  00 00 83 e5 0c 00 93 e5  |................| 00000860  08 10 93 e5 04 f0 93 e5  00 f0 ff ff 07 b0 5d 4a  |..............]j| 00000870  00 20 0f e1 03 00 12 e3  01 00 00 1a 17 00 a0 e3  |. ..............| 00000880  56 34 12 ef 00 20 0f e1  c0 20 82 e3 02 f0 21 e1  |v4... ... ....!.| 00000890  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 000008a0  5c 41 9f e5 65 00 00 eb  57 0f 8f e2 4e 1c 90 e8  |\a..e...w...n...|   $ hexdump -c boot2.img | more 00000000  41 4e 44 52 4f 49 44 21  88 69 68 00 00 80 20 80  |android!.ih... .| 00000010  c6 1e 0a 00 00 00 20 81  00 00 00 00 00 00 10 81  |...... .........| 00000020  00 01 20 80 00 08 00 00  00 00 00 00 00 00 00 00  |.. .............| 00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 00000040  61 6e 64 72 6f 69 64 62  6f 6f 74 2e 68 61 72 64  |androidboot.hard| 00000050  77 61 72 65 3d 71 63 6f  6d 20 75 73 65 72 5f 64  |ware=qcom user_d| 00000060  65 62 75 67 3d 33 31 20  7a 63 61 63 68 65 20 61  |ebug=31 zcache a| 00000070  6e 64 72 6f 69 64 62 6f  6f 74 2e 62 6f 6f 74 64  |ndroidboot.bootd| 00000080  65 76 69 63 65 3d 6d 73  6d 5f 73 64 63 63 2e 31  |evice=msm_sdcc.1| 00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| * 00000240  bc 67 a2 74 d6 d0 01 0e  b4 56 47 6f bd ad 4d 85  |.g.t.....vgo..m.| 00000250  30 c1 ee 43 00 00 00 00  00 00 00 00 00 00 00 00  |0..c............| 00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| * 00000800  00 00 a0 e1 00 00 a0 e1  00 00 a0 e1 00 00 a0 e1  |................| * 00000820  02 00 00 ea 18 28 6f 01  00 00 00 00 88 69 68 00  |.....(o......ih.| 00000830  01 70 a0 e1 00 00 30 e3  00 80 a0 11 02 80 a0 01  |.p....0.........| 00000840  20 30 9f e5 00 00 93 e5  1c 10 9f e5 01 00 30 e1  | 0............0.| 00000850  06 00 00 1a 00 00 a0 e3  00 00 83 e5 0c 00 93 e5  |................| 00000860  08 10 93 e5 04 f0 93 e5  00 f0 ff ff 07 b0 5d 4a  |..............]j| 00000870  00 20 0f e1 03 00 12 e3  01 00 00 1a 17 00 a0 e3  |. ..............| 00000880  56 34 12 ef 00 20 0f e1  c0 20 82 e3 02 f0 21 e1  |v4... ... ....!.| 00000890  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 000008a0  5c 41 9f e5 65 00 00 eb  57 0f 8f e2 4e 1c 90 e8  |\a..e...w...n...|

an obvious difference in 2 hexdumps word stored starting 20 bytes image - 0x81200000 in yours vs 0x81700000 in original - stands out because 0x20 space while 0x70 printable "p" appearing in right column.

examining bootimg.h, 

struct boot_img_hdr { unsigned char magic[boot_magic_size];  unsigned kernel_size;  /* size in bytes */ unsigned kernel_addr;  /* physical load addr */  unsigned ramdisk_size; /* size in bytes */ unsigned ramdisk_addr; /* physical load addr */  unsigned second_size;  /* size in bytes */ unsigned second_addr;  /* physical load addr */

where first element 8 bytes, appear ramdisk_addr, image trying load ramdisk lower address original.

further, both images try load kernel @ 0x80208000, , kernel 0x00686988 in size, loading ramdisk @ around 0x80700000 looks reasonable, while trying load @ 0x80200000 broken ramdisk @ size of 0x000a1ec6 won't fit before kernel starting 0x00008000 later, , end overwriting it. don't think result of different designed order of two, 1 of having ramdisk offset 0 result of never being configured.

the source code seems suggest there --ramdisk_offset <base offset> argument, might try that. have figure out of argument option should offset relative base, or absolute, examination of documentation, or source, or simple experiment , hexdump should sort out.

this may not issue (you can use commandline options diff find offsets of other differences) - looks @ least 1 of problems need deal with.


Comments

Post a Comment

Popular posts from this blog

java - Custom OutputStreamAppender not run: LOGBACK: No context given for <MYAPPENDER> -

-
i wish write custom appender on basis of outputstreamappender . wrote following class package tests; import java.io.ioexception; import java.io.outputstream; import ch.qos.logback.core.outputstreamappender; public class myappender<e> extends outputstreamappender<e> { public myappender() { system.out.println("myappender created"); setoutputstream(new outputstream() { @override public void write(int b) throws ioexception { throw new unsupportedoperationexception(); } }); } } then wrote following runner: package tests; import org.slf4j.loggerfactory; import ch.qos.logback.classic.logger; public class runner { private static final logger log = (logger) loggerfactory.getlogger(runner.class); public static void main(string[] args) { //log.addappender(new myappender<iloggingevent>()); log.info("hello world"); } } finall...
Read more

java - UML - How would you draw a try catch in a sequence diagram? -

-
Image
is there standard way of drawing try catch sequence diagrams? i've made attempt based on this feel end result doesn't feel right. code diagram based around: public static void save () { try { filehandle filehandle = gdx.files.external(file); filehandle.writestring(boolean.tostring(constantshandler.soundenabled)+"\n", false); (int = 0; < 5; i++) { filehandle.writestring(integer.tostring(constantshandler.highscores[i])+"\n", true); } } catch (throwable e) { } } my attempt note: know still need add loop. that's ok. fragments meant show conditional control flow in sequence diagram. superstructures puts limitations on use of fragments (see pp. 467 of ss2.1.1). should use critical region try part above. , option catch . however, keep telling can take quite freedom in using uml. it's language , such changes in life time. long reader ge...
Read more

c++ - No viable overloaded operator for references a map -

-
i trying use map can make tag names reference number. when try , use it, in code error (6 in total every time reference map): src/main.cpp:25:45: error: no viable overloaded operator[] type 'std::map<std::string, std::string>' const char* idcs = node.child_value(tagmap[3]); this code: #include "pugi/pugixml.hpp" #include <iostream> #include <string> #include <map> int main() { pugi::xml_document doca, docb; std::map<std::string, pugi::xml_node> mapa, mapb; std::map<std::string, std::string> tagmap {{"1", "data"}, {"2", "entry"}, {"3", "id"}, {"4", "content"}}; if (!doca.load_file("a.xml") || !docb.load_file("b.xml")) { std::cout << "can't find input files"; return 1; } (auto& node: doca.child(tagmap[1]).children(tagmap[2])) { co...
Read more