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

[[ACL]]

Originally Posted by arrrghhh

He did respond to my PM, but it took almost a week. He's certainly helpful, just busy. So if there's a specific question we have for him, I'm sure he'd be glad to help - just don't expect a quick turnaround .

well from what we can tell is that once we reboot the device, our nand data gets erased. We were able to write, dump and verify its there after install. But reboot seems to wipe everything.

Just want to know if vogue had the same issues once they started writing to nand. We prettpy much their same tinboot with a few exceptions plus their initrd.

[arrrghhh]

Originally Posted by [ACL]

well from what we can tell is that once we reboot the device, our nand data gets erased. We were able to write, dump and verify its there after install. But reboot seems to wipe everything.

Just want to know if vogue had the same issues once they started writing to nand. We prettpy much their same tinboot with a few exceptions plus their initrd.

Just shot the man a PM. I'll let you know what I dig up.

[natemcnutty]

Originally Posted by Lmiller1708

Guys here is my initrd.gz file. I added .zip so I can up it here just remove it.

Not working:
Keeping data after Reboot.
Data (3G/EV icon is there)
Wi-Fi
Keyboard. (Most likely in the init, all the files should be there.)
Might be others...

Everything else seem to work great.

My androidinstall.tar should not be too different from yours but it you want it let me know.

Edit: This also has Nate's latest SBIN folder with the addition of the adbd file. (tested)

Thanks for the post, I'll look through it when I get home. Just as an FYI, a lot of those files get copied over into the system when all is said and done, so we could just merge those into the system ahead of time and yank in out of initrd. That would give us a faster boot and reduce the overall size.

That being said, I don't think the size of initrd is the cause of the problem here. Because my phone is already hosed, I'm going to be making some risky changes to tinboot in an effort to mimic the WinMo OS layout and address ranges. I'm going to actually try compiling everything into an NBH and see what happens...

For data, have you tried manually setting it up in the APN settings?

[[ACL]]

Originally Posted by natemcnutty

Thanks for the post, I'll look through it when I get home. Just as an FYI, a lot of those files get copied over into the system when all is said and done, so we could just merge those into the system ahead of time and yank in out of initrd. That would give us a faster boot and reduce the overall size.

That being said, I don't think the size of initrd is the cause of the problem here. Because my phone is already hosed, I'm going to be making some risky changes to tinboot in an effort to mimic the WinMo OS layout and address ranges. I'm going to actually try compiling everything into an NBH and see what happens...

For data, have you tried manually setting it up in the APN settings?

Ballsy.... but let's hope we get something fruitful. Did u contact that person ?

I spent most of my day chatting with cotulla.. boucing ideas around. So tonight ill run more tests.

[arrrghhh]

Originally Posted by natemcnutty

Because my phone is already hosed, I'm going to be making some risky changes to tinboot in an effort to mimic the WinMo OS layout and address ranges. I'm going to actually try compiling everything into an NBH and see what happens...

I know it's partially busted, just don't do the 'full Woz' so to speak - wouldn't want another guy to bite the dust from bricking his phone!

[natemcnutty]

Originally Posted by [ACL]

i need you gurus help me determine if this os.nb.payload file is good in our tinboot. I dont think its the same as vogue but if it is, then we may need to use our own right ?

Edit: ok cotulla is pretty sure spl is wiping our nand each reboot. No idea how to even stop this. may need to contact dzo ..

Ours is different than theirs, and they added that emptyimgfs to theirs because they were having issues with the Windows flashing utility. I'm curious what their partition table is for and if that might be the key to what we are trying to do.

My theory right now is that the partition table they use contains the MBR that says where the partitions are, then we point to the beginning of each partition using mtdparts. If we want to change the size of the partitions, we would need to modify the partition table. I'd be worried about having others try this out at messing around with tinboot is a brick risk, and I'm willing to do it since my phone is already screwed up.

Also, I believe Wozzer did this, but anyone willing to get me a mtty bootloader log as explained here:

http://forum.xda-developers.com/show...55&postcount=6

Edit 2: Guess we also need a full dump of mtd to find out what address it actually starts on. I'm sure Wozzer did a lot of this, but still might be a good thing to double check and start it from the beginning.

[Lmiller1708]

Originally Posted by natemcnutty

Thanks for the post, I'll look through it when I get home. Just as an FYI, a lot of those files get copied over into the system when all is said and done, so we could just merge those into the system ahead of time and yank in out of initrd. That would give us a faster boot and reduce the overall size.

That being said, I don't think the size of initrd is the cause of the problem here. Because my phone is already hosed, I'm going to be making some risky changes to tinboot in an effort to mimic the WinMo OS layout and address ranges. I'm going to actually try compiling everything into an NBH and see what happens...

For data, have you tried manually setting it up in the APN settings?

Yeah I was looking at that stuff too, but didn't know for sure... Smaller is always better!

I'm not thinking it was the size now either. Did some testing and it didn't make a difference.
I think if we use the partition table we will need to change how the nbh file is being made (I think). It looks like it is made different on the vogue.

I did try to manually set the APN but then it just disappeared after I saved it. I then had to start all over... Haven't tried too much more with it yet. Once we get the data to stick I sure it won't take long to get it working.

[[ACL]]

Originally Posted by natemcnutty

Ours is different than theirs, and they added that emptyimgfs to theirs because they were having issues with the Windows flashing utility. I'm curious what their partition table is for and if that might be the key to what we are trying to do.

My theory right now is that the partition table they use contains the MBR that says where the partitions are, then we point to the beginning of each partition using mtdparts. If we want to change the size of the partitions, we would need to modify the partition table. I'd be worried about having others try this out at messing around with tinboot is a brick risk, and I'm willing to do it since my phone is already screwed up.

Also, I believe Wozzer did this, but anyone willing to get me a mtty bootloader log as explained here:

xda-developers - View Single Post - [android]Tinboot - NAND BOOTLOADER BETA *working*

Edit 2: Guess we also need a full dump of mtd to find out what address it actually starts on. I'm sure Wozzer did a lot of this, but still might be a good thing to double check and start it from the beginning.

To be honest we never got the real numbers from the bootloader log. I dont even know how to get this bootloader log. I know someone in the blackstone forum did it but we need to find out

Edit: still no luck with that bootloader log. But i did study that os.nb file..

http://pastebin.com/WvksyzNY

Hope it makes sense to you guys. Also Vogue's partition table is really small compared to what we have.

cp partition_table output.nb.payload < --- this is what vogue has while we just use whatever is on git.

Their partition table looks like this (different)

http://pastebin.com/anDEWXud

[coolsilver]

How many partitions are being created?

I would guess the vogue has a boot partition for only the initrd and neccessary files to load it. Once initrd loads in theory you can have the kernel and all other system files in the second. Third partition for user data.... although this could be the same as the system.

So two or three partitions.

-boot very small
- system rootfs
- data part

-boot still very small
- sys rootfs data

[arrrghhh]

dzo responded! Gotta love the guy. Here's what he told me... I think the HD2 guys came to the same conclusion, AFAIK: (seems like you have as well )

Originally Posted by dzo

Hi,

Yes I had a similar problem, there is a flag that gets cleared after a successful boot to stop it erasing the nand. You may be able to clear it with an spl command but that didn't work on vogue. What I did was make the imgfs partition very small and so only a single block is erased on boot. You should be able to do the same by changing the partition table that tinboot uses.

Hope that helps.

I hope it does too. Let me know how it goes!