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

[[ACL]]

I lost track and im trying to figure out what people tried and didnt try.

So last i heard the original NBHs work fine but obviously wipe nand. I'm assuming this is because our payload had some weird padding in there where the bad stuff may have been skipped? i never quite understood the internals of the payload.

We may need to work backwards here in this case and begin with the old payload and work backwards. Not sure what else to recommend at this point

[arrrghhh]

Originally Posted by [ACL]

I lost track and im trying to figure out what people tried and didnt try.

So last i heard the original NBHs work fine but obviously wipe nand. I'm assuming this is because our payload had some weird padding in there where the bad stuff may have been skipped? i never quite understood the internals of the payload.

We may need to work backwards here in this case and begin with the old payload and work backwards. Not sure what else to recommend at this point

This is how I understand where we are as well.... the old payload missed the bad blocks before, and are not now.

[[ACL]]

Originally Posted by arrrghhh

This is how I understand where we are as well.... the old payload missed the bad blocks before, and are not now.

How good is your hex edits?

[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS) [ONLINE] - xda-developers

You can always take the original payload and begin the butchering ..

Edit: Also i notice that we are still using a different compression that the vogue (XPR vs lzx).. Did anyone ever try out the other one? (i included a bin if anyone wants to try it.)

[Lmiller1708]

Originally Posted by [ACL]

How good is your hex edits?

[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS) [ONLINE] - xda-developers

You can always take the original payload and begin the butchering ..

Edit: Also i notice that we are still using a different compression that the vogue (XPR vs lzx).. Did anyone ever try out the other one? (i included a bin if anyone wants to try it.)

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

[arrrghhh]

Downloading now, thanks L_miller... I'll let you know how it goes!

Status quo... no double vibe :/

ACL, I'll read and re-read that page... hopefully start to mess with this stuff. First reading leaves me in a fairly glazed state to be honest... .

[[ACL]]

Originally Posted by arrrghhh

Downloading now, thanks L_miller... I'll let you know how it goes!

Status quo... no double vibe :/

ACL, I'll read and re-read that page... hopefully start to mess with this stuff. First reading leaves me in a fairly glazed state to be honest... .

Ok, so i want to shift gears a bit and just concentrate on at least getting the double vibe. Means the kernel is actually up. Lets not worry about the initrd for now.

Soooo.. can you build without the full initrd? or make a really small one. I say this because the original nhb missed the bad parts.. so the kernel is in a safe spot and most likely the initrd is broken. So we can either shrink it to a few K or move it far back. I say shrink it since Lmiller is able to append it on tinboot now. all we need is a initrd small enough to miss all the bad poop

[Lmiller1708]

Originally Posted by arrrghhh

Downloading now, thanks L_miller... I'll let you know how it goes!

Status quo... no double vibe :/

ACL, I'll read and re-read that page... hopefully start to mess with this stuff. First reading leaves me in a fairly glazed state to be honest... .

Did you flash back stock first? If so maybe we need to try relocking???


Can any ROM cooker help out?

[arrrghhh]

Originally Posted by Lmiller1708

Did you flash back stock first? If so maybe we need to try relocking???


Can any ROM cooker help out?

Hrm, I can try relocking... I did flash back to stock tho.

[[ACL]]

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

I didnt even know people use that build script .. I think everyone is mature enough to know how to compile a kernel right?

[natemcnutty]

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