[Lmiller1708]

Originally Posted by natemcnutty

I'm curious as to why the data would get wiped off NAND when you flash a new kernel. The NAND addresses should not overlap if we have Tinboot set up properly. Did you flash via USB or sd card? I wonder if Task 28 is getting passed by the EXE you are using to flash. I'll get to play with this tomorrow at work

Every time you flash it's going to wipe everything. This is why I have never believed in using Task 29. It does the exact same thing.

Originally Posted by natemcnutty

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

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@0C000000(userdata)
This would give us the remaining 304 MB for data starting at 208 MB in.

For Ram Size we should use this. This is also posted a couple of posts back...
.equ RAM_SIZE, 0x0E600000

For the wiping of the last 24MB's of data this would make sense to me to just reduce the size of the userdata. I do see this issue after a reset by losing some data.

I do think we need to find out these values too...

.equ    LOAD_START,     0x10000000
.equ    RAM_START,     0x10000000
.equ    RAM_SIZE,     0x0E600000
.equ    INITRD_START,     RAM_START+0x00800000
.equ    KERNEL_OFFSET,  0x8000
.equ     XIP_END,     0x2ff000

Here is what I think they should be but it won't boot...

.equ    LOAD_START,     0x20000000
.equ    RAM_START,     0x20000000    <-----Not sure...
.equ    RAM_SIZE,     0x0E600000
.equ    INITRD_START,     RAM_START+0x00800000  <---- Does not make sense to me what this really does... Does RAM start before Main Memory?
.equ    KERNEL_OFFSET,  0x8000
.equ     XIP_END,     0x2ff000