NAND Testing - 05-25 Update: New LK, Recovery.img, Kernel Updates through Recovery - Page 123

**natemcnutty** · #**1221** (**permalink**) 02-14-2011, 12:11 AM

So, I just wanted to give a quick update. I apologize for the absence this weekend. Apparently there is this thing called Valentine's day on Monday, and the wife decided that we were going to the coast for the weekend as a surprise... Long story short, it was awesome, but I didn't get to do anything with my phone

I love the progress I see. Hopefully I can get a chance to play with it tomorrow. I'll do some of the math out on exactly what we need for space for everything and see if we can fix that partition 3 thing while allowing us to use the remaining space on the NAND.

**[ACL]** · #**1222** (**permalink**) 02-14-2011, 12:33 AM

Quote:

Originally Posted by Lmiller1708

I kept getting boot loops until I switched to my sysinit.rc... I think it is a couple of folders not being made... Maybe the sql folder?

Your int file is missing a fi in the automount data part... I'm sure you found that already though.

Still no data though.. This time I don't see the 3G icon at all.

We are getting there though...

ahh yes the damn FI.. lol thanks bro..

any others besides the sql you can think of ? last major one that was stopping boot for me was the /etc. I made a mistake of making the folder instead of allowing android to symlink it.

wifi isnt working for me since i commented that whole section out. But im working on that. One interesting thing is that when i reupload a new kernel, boom all nand is gone again. I guess we have to update the kernel from inside android now huh.. jeez..

**[ACL]** · #**1223** (**permalink**) 02-14-2011, 12:46 AM

Quote:

Originally Posted by natemcnutty

So, I just wanted to give a quick update. I apologize for the absence this weekend. Apparently there is this thing called Valentine's day on Monday, and the wife decided that we were going to the coast for the weekend as a surprise... Long story short, it was awesome, but I didn't get to do anything with my phone

I love the progress I see. Hopefully I can get a chance to play with it tomorrow. I'll do some of the math out on exactly what we need for space for everything and see if we can fix that partition 3 thing while allowing us to use the remaining space on the NAND.

You did goo bro... keep the wife happy. Remember what i always say .. "honor the gods, love your women, and write good code"

**natemcnutty** · #**1224** (**permalink**) 02-14-2011, 01:37 AM

Quote:

Originally Posted by [ACL]

ahh yes the damn FI.. lol thanks bro..

any others besides the sql you can think of ? last major one that was stopping boot for me was the /etc. I made a mistake of making the folder instead of allowing android to symlink it.

wifi isnt working for me since i commented that whole section out. But im working on that. One interesting thing is that when i reupload a new kernel, boom all nand is gone again. I guess we have to update the kernel from inside android now huh.. jeez..

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

**[ACL]** · #**1225** (**permalink**) 02-14-2011, 02:30 AM

Quote:

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

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.

**natemcnutty** · #**1226** (**permalink**) 02-14-2011, 04:01 AM

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.

gtmethod3 · #**1227** (**permalink**) 02-14-2011, 04:10 AM

Quote:

Originally Posted by [ACL]

You did goo bro... keep the wife happy. Remember what i always say .. "honor the gods, love your women, and write good code"

Thumbs up on this.

**Lmiller1708** · #**1228** (**permalink**) 02-14-2011, 08:31 AM

Quote:

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.

Quote:

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

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@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...

Code:

.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...

Code:

.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

**Lmiller1708** · #**1229** (**permalink**) 02-14-2011, 01:17 PM

Nate your numbers are off a bit for the starting of your userdata...
It should be: 0x13000000@0x0D000000(userdata)

**[ACL]** · #**1230** (**permalink**) 02-14-2011, 04:37 PM

Quote:

Originally Posted by Lmiller1708

Nate your numbers are off a bit for the starting of your userdata...
It should be: 0x13000000@0x0D000000(userdata)

so whats the final word ? commit this nand parts?

im waiting on a reply from one of the guys in the blackstone forum. They were able to get the ramsize from bootlog. not sure how.