Quote:
Originally Posted by [ACL]
my mtd parts doesnt match lmiller so i may be off. When yall test we can see whats up. Also removing the - sign will help, so lets figure out the math so we can finalize the mtd parts.
i flash via SD.
|
I was thinking another possibility for the data going missing is because we are erasing the partition table every time we flash tinboot. Just makes me wonder why they use the code below. I wish dzo had some sort of documentation for tinboot that we could read
Code:
fin:
.org XIP_END-0x20000,0xff
.incbin "emptyimgfs"
The emptyimgfs is our imgfs.bin, and I was thinking maybe they force it into the same place to prevent overwriting something.
For the math, I wouldn't necessarily use this code yet, but I wanted to post my thoughts so I can remember them for tomorrow :P
.equ RAM_SIZE, 0x03000000
I'm not positive, but I think this is RAM being allocated. This totals to 48MB, but the Vogue tinboot uses 0x06800000 which totals to 104MB.
.equ KERNEL_OFFSET, 0x8000
I believe this means the kernel is starting at 32KB.
.equ XIP_END, 0x2ff000
I believe this means we have almost 3 MB of space for XIP.
Now, we have 512MB of NAND available to us, but we may be similar to the HD2 where part of the NAND is still erased by SPL (for HD2, the last 24MB are always wiped). We'll have to figure this out later.
msm_nand:0x20000000@0x0(nand)
This should give us 512 MB, but as stated earlier, we may need to reduce part of it.
0x01000000@0x04000000(root)
This would give us 16 MB for root partition starting at 64MB in. Not sure why we start there, but probably for fear of overwriting tinboot stuff?
0x08000000@0x05000000(system)
This would give us 128 MB for system starting at 80 MB in.
0x13000000@0D000000(userdata)
This would give us the remaining 304 MB for data starting at 208 MB in.