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

**natemcnutty** · #**1341** (**permalink**) 02-23-2011, 02:57 PM

Quote:

Originally Posted by Lmiller1708

ACL good idea about the compression.
I have been able to get it to now boot with adding the imgfs.bin by tinboot. @ @ Tinboot V 1.0 @ Very simple bootloader for H - Tinboot
My partition table is very close to what the partition table of the booting ones are. NBInfo 2.1rc2 '00_OS.nb.payload' has valid boot - Rhod_Payload

I made a couple of changes this morning adding in the imgfs.bin instead of the emptyimgfs. (lzx instead of xpr)

Stinebd also pointed out that night that a couple parts of our scripts are wrong. Both Nate's and what is on GIT.

For Nate's FullBuild.sh Line's 54, 70 and 76 need to have a - behind the $TOOLCHAIN_PATH... Like this $TOOLCHAIN_PATH-

This is also the same for the GIT. And line 27 has the wrong config.
It should be: make ARCH=arm htc_msm_nand_defconfig

As DZO stated the bad blocks should be handled by the SPL... So maybe this is not working like it should with some devices. So I would like someone with bad blocks (like arrrghhh or Nate

) to flash back to stock, and try it again.

I'm cooking up a ROM like now that I would like you guys to test and get back to me. I will attach the modules if successful. It also looks like ACL pushed the camera?

Happy Flashing!

EDIT: My Androidupdate.tar

Just a couple of things I wanted to add.

First, I have tried a combination of everything from the Vogue including flashing their partition table and their emptyimgfs with our initrd and zImage.

Second, my post with those scripts is insanely outdated. I've had the nand defconfig for quite a long time. The scripts on GIT have never worked for me, so I've always used my own script.

Third, it isn't bad blocks that are preventing people from booting. I have a couple of theories, but I'm pretty sure it has nothing to do with bad blocks. If you look at the reports of bad blocks, they have been assigned numbers outside of the possible number block. We would have to flash at least 10,000 times in order to wear out the flash, and the blocks just don't go bad that easily.

The frist theory I had was that some of us have a slightly different SPL. I know all of ours say SPL-1.00.OliNex, but they did update the SPL and then stated that if you already HSPL'd that you didn't have to do it again. I can't test this theory because I can't USB. If I relock, I'll be stuck on stock forever. Reference: http://forum.ppcgeeks.com/cdma-tp2-d...w-hardspl.html

**[ACL]** · #**1342** (**permalink**) 02-23-2011, 04:19 PM

Quote:

Originally Posted by natemcnutty

Just a couple of things I wanted to add.

First, I have tried a combination of everything from the Vogue including flashing their partition table and their emptyimgfs with our initrd and zImage.

Second, my post with those scripts is insanely outdated. I've had the nand defconfig for quite a long time. The scripts on GIT have never worked for me, so I've always used my own script.

Third, it isn't bad blocks that are preventing people from booting. I have a couple of theories, but I'm pretty sure it has nothing to do with bad blocks. If you look at the reports of bad blocks, they have been assigned numbers outside of the possible number block. We would have to flash at least 10,000 times in order to wear out the flash, and the blocks just don't go bad that easily.

The frist theory I had was that some of us have a slightly different SPL. I know all of ours say SPL-1.00.OliNex, but they did update the SPL and then stated that if you already HSPL'd that you didn't have to do it again. I can't test this theory because I can't USB. If I relock, I'll be stuck on stock forever. Reference: http://forum.ppcgeeks.com/cdma-tp2-d...w-hardspl.html

I'll do that last git script update but those shouldnt be used. They are good referece but everyone should really have their own scripts. So its good you have your own brew going.

Hmm.. how an i flash to another spl ? i want whatever arg has so i can replicate the issue. Can this be dumped somehow?

**arrrghhh** · #**1343** (**permalink**) 02-23-2011, 04:20 PM

Quote:

Originally Posted by natemcnutty

The frist theory I had was that some of us have a slightly different SPL. I know all of ours say SPL-1.00.OliNex, but they did update the SPL and then stated that if you already HSPL'd that you didn't have to do it again. I can't test this theory because I can't USB. If I relock, I'll be stuck on stock forever. Reference: http://forum.ppcgeeks.com/cdma-tp2-d...w-hardspl.html

Perhaps I should relock... For whatever reason you can relock via SD but not unlock... I'm assuming that's so the software can keep tabs on which phones have been unlocked before (they seem to want control over it and only want you to be able to unlock once...)

I'll give it a shot, relock try to flash. If that doesn't work, then unlock with the newest hSPL and see if there's any diffenot like those things really get updated much; once they work they work...rence.

No difference... so I wonder if you guys are on an older hSPL? I was reading IRC logs, and you guys definitely did hSPL before I had my RHOD... I did relock, wouldn't flash obviously... so unlock again with newest hSPL, same deal...

I would hope if the SPL version says it's the same it is the same...I see the line about the update, but no info on the update...? Hm. I'm not sure how I could get to the "old" hSPL unlocker either.

**natemcnutty** · #**1344** (**permalink**) 02-23-2011, 09:10 PM

Well, I think I got it figured out, and now that I'm looking at it, I don't understand how ACL and LMiller are actually working, lol. I had two major theories, and they may both be correct. I thought the SPL was requiring us to have specific partitions, especially the fatfs. The other theory was that the fatfs was initializing over the top of our existing data and wiping the device every time we rebooted. A simple fix would be to elimitate the fatfs or make it smaller. Removing it did not work, but making it smaller sure did (edit: but it still requires a substantial size instead of zeroing it out or making it 128KB)

Here's how I got there for anyone interested:

First, I was looking at our previous os.nb.payload and it's partition table. Here's a quick rundown of how it was formatted:

Partition 1 - Type 0x20 (boot) - Size 0x40 (128 KB)
Partition 2 - Type 0x23 (rawfs) - Size 0x6C0 (3456 KB)
Partition 3 - Type 0x25 (imgfs) - Size 0x40 (128 KB) -
Partition 4 - Type 0x04 (fatfs) - Size 0x39040 (467072 KB)

I noticed that the Tinboot portion started at 0x20000 which starts at 128K into NAND. This correlates with the start of the 2nd partition in the table, and if we get rid of the boot partition and start the rawfs partition at offset 0x2, then we need to move the Tinboot payload as well which was not being done.

The second thing I did was a little comparison of each step of the file the way we used to do it. Here's that breakdown:

Code:

Start
01 00 20 3F 01 00 02 00 00 00 3E 00 00 00 00 00
01 01 23 3F 01 1B 40 00 00 00 C0 06 00 00 00 00
01 1C 25 3F 01 1C 00 07 00 00 40 00 00 00 00 00
01 1D 04 3F 81 5D 40 07 00 00 40 90 03 00 55 AA

After osnbtool
01 00 20 3F 01 00 02 00 00 00 3E 00 00 00 00 00
01 01 23 3F 01 1B 40 00 00 00 00 05 00 00 00 00
01 1C 25 3F 01 1C 40 05 00 00 40 00 00 00 00 00
01 1D 04 3F 81 5D 80 05 00 00 40 90 03 00 55 AA

After imgfstonb
01 00 20 3F 01 00 02 00 00 00 3E 00 00 00 00 00
01 01 23 3F 01 1B 40 00 00 00 00 05 00 00 00 00
01 15 25 3F 01 15 40 05 00 00 40 00 00 00 00 00
01 16 04 3F 81 56 80 05 00 00 40 90 03 00 55 AA

After nmberge (no changes this time)
01 00 20 3F 01 00 02 00 00 00 3E 00 00 00 00 00
01 01 23 3F 01 1B 40 00 00 00 00 05 00 00 00 00
01 15 25 3F 01 15 40 05 00 00 40 00 00 00 00 00
01 16 04 3F 81 56 80 05 00 00 40 90 03 00 55 AA

Long story short, the NB tools are changing values and probably doing some alignment that we don't have replicated when we cat them. So, I took one of the NBH's that I generated the old way and started messing around. Here are my results:

Completely removing the fatfs prevents the phone from booting. Setting it to 0x40 (128 KB) in size and adjusting the end block would not let the phone boot. Setting it to 0x4000 (32 MB) boots up just fine. I'll test smaller shortly, but using 32 MB, it boots and keeps all of the data on the NAND because we start our NAND partitions at 64 MB's into the NAND.

My thought is that the SPL is requiring fatfs of at least a specific size. fatfs partition was initializing over the top of where we had our mount points wiping the data every time we restarted. And BINGO, there you have it.

Edit: Here's the partition layout I'm using right now (starting at 3E0)

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
000003E0  01 00 20 3F 01 00 02 00 00 00 3E 00 00 00 00 00  .. ?......>.....
000003F0  01 01 23 3F 01 1B 40 00 00 00 80 05 00 00 00 00  ..#?..@...€.....
00000400  01 17 25 3F 01 17 C0 05 00 00 40 00 00 00 00 00  ..%?..À...@.....
00000410  01 18 04 3F 01 7C 00 06 00 00 00 40 00 00 55 AA  ...?.|.....@..Uª

**[ACL]** · #**1345** (**permalink**) 02-23-2011, 09:35 PM

Quote:

Originally Posted by natemcnutty

Well, I think I got it figured out, and now that I'm looking at it, I don't understand how ACL and LMiller are actually working, lol. I had two major theories, and they may both be correct. I thought the SPL was requiring us to have specific partitions, especially the fatfs. The other theory was that the fatfs was initializing over the top of our existing data and wiping the device every time we rebooted. A simple fix would be to elimitate the fatfs or make it smaller. Removing it did not work, but making it smaller sure did

Here's how I got there for anyone interested:

First, I was looking at our previous os.nb.payload and it's partition table. Here's a quick rundown of how it was formatted:

Partition 1 - Type 0x20 (boot) - Size 0x40 (128 KB)
Partition 2 - Type 0x23 (rawfs) - Size 0x6C0 (3456 KB)
Partition 3 - Type 0x25 (imgfs) - Size 0x40 (128 KB) -
Partition 4 - Type 0x04 (fatfs) - Size 0x39040 (467072 KB)

I noticed that the Tinboot portion started at 0x20000 which starts at 128K into NAND. This correlates with the start of the 2nd partition in the table, and if we get rid of the boot partition and start the rawfs partition at offset 0x2, then we need to move the Tinboot payload as well which was not being done.

The second thing I did was a little comparison of each step of the file the way we used to do it. Here's that breakdown:

Code:

Start
01 00 20 3F 01 00 02 00 00 00 3E 00 00 00 00 00
01 01 23 3F 01 1B 40 00 00 00 C0 06 00 00 00 00
01 1C 25 3F 01 1C 00 07 00 00 40 00 00 00 00 00
01 1D 04 3F 81 5D 40 07 00 00 40 90 03 00 55 AA

After osnbtool
01 00 20 3F 01 00 02 00 00 00 3E 00 00 00 00 00
01 01 23 3F 01 1B 40 00 00 00 00 05 00 00 00 00
01 1C 25 3F 01 1C 40 05 00 00 40 00 00 00 00 00
01 1D 04 3F 81 5D 80 05 00 00 40 90 03 00 55 AA

After imgfstonb
01 00 20 3F 01 00 02 00 00 00 3E 00 00 00 00 00
01 01 23 3F 01 1B 40 00 00 00 00 05 00 00 00 00
01 15 25 3F 01 15 40 05 00 00 40 00 00 00 00 00
01 16 04 3F 81 56 80 05 00 00 40 90 03 00 55 AA

After nmberge (no changes this time)
01 00 20 3F 01 00 02 00 00 00 3E 00 00 00 00 00
01 01 23 3F 01 1B 40 00 00 00 00 05 00 00 00 00
01 15 25 3F 01 15 40 05 00 00 40 00 00 00 00 00
01 16 04 3F 81 56 80 05 00 00 40 90 03 00 55 AA

Long story short, the NB tools are changing values and probably doing some alignment that we don't have replicated when we cat them. So, I took one of the NBH's that I generated the old way and started messing around. Here are my results:

Completely removing the fatfs prevents the phone from booting. Setting it to 0x40 (128 KB) in size and adjusting the end block would not let the phone boot. Setting it to 0x4000 (32 MB) boots up just fine. I'll test smaller shortly, but using 32 MB, it boots and keeps all of the data on the NAND because we start our NAND partitions at 64 MB's into the NAND.

My thought is that the SPL is requiring fatfs of at least a specific size. fatfs partition was initializing over the top of where we had our mount points wiping the data every time we restarted. And BINGO, there you have it.

Woahh.. makes sense in theory. So ur able to boot with 32mb so lets see how low we can go.

So you are using the tools again instead of cat ? odd then how does this all work on the vogue? i guess overtime htc modded something huh. the tp2 gets weirder and weirder.

So plan out the agenda as to how we will do this for everyone. Lmiller and I will comply with the change that works for everyone.

I'm making the last commits for the camera. Once we have your change we can finaly get more cookers on board.

**arrrghhh** · #**1346** (**permalink**) 02-23-2011, 09:39 PM

Awesome work nate. Sounds like a plan [acl]. Can't wait to test it!

**natemcnutty** · #**1347** (**permalink**) 02-23-2011, 09:58 PM

Quote:

Originally Posted by [ACL]

Woahh.. makes sense in theory. So ur able to boot with 32mb so lets see how low we can go.

So you are using the tools again instead of cat ? odd then how does this all work on the vogue? i guess overtime htc modded something huh. the tp2 gets weirder and weirder.

So plan out the agenda as to how we will do this for everyone. Lmiller and I will comply with the change that works for everyone.

I'm making the last commits for the camera. Once we have your change we can finaly get more cookers on board.

Testing how low we can go right now. Just tried 8 MB and it worked! Unfortunately, my hope that when flashing it wouldn't wipe system and data did not happen.

For the Vogue, their SPL may not have the requirement for the fatfs or someone may have removed those limitations. Not all devices require fatfs, and it could be a simple revision change between your devices and ours.

I think for now, editing the old os.nb.payload and going back to the old method might work best for now.

**natemcnutty** · #**1348** (**permalink**) 02-23-2011, 10:04 PM

Here's the modified os.nb.payload that works for me.

I'm posting the NBH, but the modules were messed up (did the . instead of the directory), so this will let you play around a bit, but you'll have to install modules from something else.

**arrrghhh** · #**1349** (**permalink**) 02-23-2011, 10:20 PM

Quote:

Originally Posted by natemcnutty

Here's the modified os.nb.payload that works for me.

I'm posting the NBH, but the modules were messed up (did the . instead of the directory), so this will let you play around a bit, but you'll have to install modules from something else.

Holy hell you're awesome. Worked like a charm!!

**[ACL]** · #**1350** (**permalink**) 02-23-2011, 10:39 PM

Quote:

Originally Posted by natemcnutty

Here's the modified os.nb.payload that works for me.

I'm posting the NBH, but the modules were messed up (did the . instead of the directory), so this will let you play around a bit, but you'll have to install modules from something else.

And this is with a 8mb gap ? I'm hoping we can bring this bad boy down to like 2 or something..

Since it works for arg.. once Lmiller gives it the blessing, we can commit.