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

[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

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

[coolsilver]

Commit and I'll flash away.

I've just been too lazy to rebuild my dev environment.

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

[[ACL]]

Originally Posted by Lmiller1708

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

ahh booo yeah thats what im tlaking about.


I have to flash like crazy to continue kernel dev. unless i kexec or go back to sdcard temporarily

[Lmiller1708]

Originally Posted by [ACL]

ahh booo yeah thats what im tlaking about.


I have to flash like crazy to continue kernel dev. unless i kexec or go back to sdcard temporarily

Yup! Sad part about being a developer... You are never done flashing!

I do like android a lot better then windows... Every time you flashed a ROM it took forever to get it back how you wanted it, that is why I started to cook my own ROM's. Now with android all you have to do is back up your data.img and wallah you are back to where you started! So that might be a option too via the replimenu.

Never heard of kexec before but it might work... Until a reboot then it will get overwritten by the original kernal.

Edit: Are you running Full NAND currently and do you have data working?

[Lmiller1708]

For Reference... Using OSbuilder:

WinMo Roms:
Vogue Dump
TP2 Dump

Nand:
Vogue_Nand_Dump
TP2_Nand_Dump (current)

[natemcnutty]

Originally Posted by [ACL]

ahh booo yeah thats what im tlaking about.


I have to flash like crazy to continue kernel dev. unless i kexec or go back to sdcard temporarily

Wonder if that's why magldr just uses the zImage and initrd.gz from the first partition. Then you could use the update utility to update them without having to ever flash again.

On a side note, I would double check with the Vogue guys to make sure everything does get wiped when they update their kernel. I'm still wondering if partition tables may have something to do with this. Hopefully I can finally get a break from work and home to actually do some serious testing. I find it really odd that the partition table has two partitions that start at the same location rather than simply erasing the second partition and moving the locations of everything.