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

PPCGeeks (http://forum.ppcgeeks.com/index.php)

- Android On TP2 Development (http://forum.ppcgeeks.com/forumdisplay.php?f=319)

- - NAND Testing - 05-25 Update: New LK, Recovery.img, Kernel Updates through Recovery (http://forum.ppcgeeks.com/showthread.php?t=134598)

Re: NAND Boot Testing - 01-07: Panel power on/off fixes

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.

Re: NAND Boot Testing - 01-07: Panel power on/off fixes

Quote:

Originally Posted by Lmiller1708 (Post 2055780)

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

Re: NAND Boot Testing - 01-07: Panel power on/off fixes

Quote:

Originally Posted by natemcnutty (Post 2055807)

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

Re: NAND Boot Testing - 01-07: Panel power on/off fixes

Quote:

Originally Posted by [ACL] (Post 2055822)

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 :)

Re: NAND Boot Testing - 01-07: Panel power on/off fixes

Quote:

Originally Posted by natemcnutty (Post 2055860)

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.

Re: NAND Boot Testing - 01-07: Panel power on/off fixes

Quote:

Originally Posted by [ACL] (Post 2055877)

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.

Re: NAND Boot Testing - 01-07: Panel power on/off fixes

Quote:

Originally Posted by [ACL] (Post 2055830)

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.

:thumbleft:

Re: NAND Boot Testing - 01-07: Panel power on/off fixes

Quote:

Originally Posted by natemcnutty (Post 2055860)

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 (Post 2055892)

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

Re: NAND Boot Testing - 01-07: Panel power on/off fixes

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

Re: NAND Boot Testing - 01-07: Panel power on/off fixes

Quote:

Originally Posted by Lmiller1708 (Post 2056011)

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.