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

[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

[Lmiller1708]

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

[[ACL]]

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.

[natemcnutty]

Originally Posted by [ACL]

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.

LMiller is right, I had the math off when I was in bed last night. That's what I get for doing things so late. Those are the numbers that make sense to me, but I haven't had a chance to test them.

[Lmiller1708]

Originally Posted by natemcnutty

I'm curious why we would use 230MB on RAM SIZE? If you are going for the maximum amount of RAM, we have 288 MB (some is used for graphics though) which should be 0x12000000. I personally think they limited the amount of RAM to speed up boot (less memory to map).

For RAM_START, I'm thinking that is the pointer to the starting memory address we work from (where everything starts loading into RAM). This would cause initrd to get loaded into memory at the offset mentioned above.

Also, did you manually hex edit the rhod_payload file? I've been reading through [TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS) [ONLINE] - xda-developers but am not all that excited about doing the math out

Ummm... I guess I was a bit off. Sorry about that. Quick math = FAIL!
Yes you are correct we have 288 MB of RAM and 38 MB is for Video.
HTC Mobile Phones - T-Mobile Touch Pro2 - Overview


I did manually hex the rhod_payload file, I did hack my way though it... But it does seem to work.
Here where my steps:
Changed Partition 0 to 0x23 (xip ram). (Same as the Vogue)
Looked at a normal TP2 ROM and saw the Start sector was 640.
So I subtracted 2 from 640 and this gave me the Partition 0 Total Sectors.
I then set the start sector of Part1 to 640 and left total sectors 0 (same as the Vogue)
You get the picture for the rest of the start and total sectors...
For the Tracks and heads I played around with until I had the Geometry = 64 (same as the TP2 ROM). I tried matching them up to the original TP2 ROM the best I could.

If you can find a better process to do this by all means go for it!
I'm not saying these values are right but they work.

Originally Posted by [ACL]

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.

I would say go for it! I didn't seem to lose any settings today after a couple of reboots.

[[ACL]]

Originally Posted by Lmiller1708

Ummm... I guess I was a bit off. Sorry about that. Quick math = FAIL!
Yes you are correct we have 288 MB of RAM and 38 MB is for Video.
HTC Mobile Phones - T-Mobile Touch Pro2 - Overview


I did manually hex the rhod_payload file, I did hack my way though it... But it does seem to work.
Here where my steps:
Changed Partition 0 to 0x23 (xip ram). (Same as the Vogue)
Looked at a normal TP2 ROM and saw the Start sector was 640.
So I subtracted 2 from 640 and this gave me the Partition 0 Total Sectors.
I then set the start sector of Part1 to 640 and left total sectors 0 (same as the Vogue)
You get the picture for the rest of the start and total sectors...
For the Tracks and heads I played around with until I had the Geometry = 64 (same as the TP2 ROM). I tried matching them up to the original TP2 ROM the best I could.

If you can find a better process to do this by all means go for it!
I'm not saying these values are right but they work.



I would say go for it! I didn't seem to lose any settings today after a couple of reboots.

reboots are fine for me.. but are you loosing data after a kernel update ?

[Lmiller1708]

Originally Posted by [ACL]

reboots are fine for me.. but are you loosing data after a kernel update ?

Are you talking Reflashing?
If so then Yes, one would expect to lose everything no matter what your partition table looks like.

[natemcnutty]

Originally Posted by Lmiller1708

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.



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

I'm curious why we would use 230MB on RAM SIZE? If you are going for the maximum amount of RAM, we have 288 MB (some is used for graphics though) which should be 0x12000000. I personally think they limited the amount of RAM to speed up boot (less memory to map).

For RAM_START, I'm thinking that is the pointer to the starting memory address we work from (where everything starts loading into RAM). This would cause initrd to get loaded into memory at the offset mentioned above.

Also, did you manually hex edit the rhod_payload file? I've been reading through [TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS) [ONLINE] - xda-developers but am not all that excited about doing the math out