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

[arrrghhh]

Originally Posted by natemcnutty

I'll gladly try flashing the vogue's partition table and blank imgfs like they do it. Like I said, my phone is fairly useless with the USB being broken. I have to keep it on a charger almost all day long because the pins are broken inside keeping the current flowing through the USB all day long...

Thanks for takin the bullet...

I'm actually surprised you can charge at all, at least that still works!

You should hop on IRC sometime nate, haven't chatted with you on there in a while .

[[ACL]]

Originally Posted by natemcnutty

they are just using a blank imgfs which they are including at the end of tinboot:

kernel:
        .incbin "zImage"
initrd:
        .incbin    "initrd.lzma"
        .align
fin:
        .org XIP_END-0x20000,0xff
        .incbin "emptyimgfs"

I'll break down their imgfs and compare it with ours. I'll also dig a little deeper into the os.payload, but I really don't think that part matters for much of anything since the XIP is what we care about (since it contains the tinboot code).

I'll gladly try flashing the vogue's partition table and blank imgfs like they do it. Like I said, my phone is fairly useless with the USB being broken. I have to keep it on a charger almost all day long because the pins are broken inside keeping the current flowing through the USB all day long...

EDIT: OK, I just broke down and compared the hex of the blankimgfs from Vogue and our imgfs.bin, and they are identical.

Now I just have to figure out the difference between the partition table from Vogue and our os.nb.payload file. I believe that is the only difference between what we are doing and what they are doing. And like DZO said, they had to use a tiny partition table to only use one cell. Seems we should be able to do the same thing, so I'm going to try it.

I posted the difference yesterday between the partition tables, look at the pastebins.

also my vbin diff shows differences between the imgfs.bin. Looks like we use xpr while dzo uses lzx for compression. So how are you comparing your emptyimgs ?

[natemcnutty]

Originally Posted by [ACL]

I posted the difference yesterday between the partition tables, look at the pastebins.

also my vbin diff shows differences between the imgfs.bin. Looks like we use xpr while dzo uses lzx for compression. So how are you comparing your emptyimgs ?

Crap, you're right! I renamed the damned file when I was messing around with compiling tinboot and compared it to itself... Just downloaded them directly off the gits and compared with HxD, and I do see the differences from 0x2C to 0x32:

IMGFS.BIN: 4C 5A 58 00 82 46 02
EMPTYIMG:  58 50 52 00 FE C2 01

Unfortunately, my battery is dead at the moment, and I have to let it fully charge before I can flash these test tinboots. I might get lucky and be able to try this tonight. If not, tomorrow morning when I get in to work, I have a folder with 4 different tinboots to try out in order of least to most brick risk :P

[Lmiller1708]

Originally Posted by natemcnutty

Crap, you're right! I renamed the damned file when I was messing around with compiling tinboot and compared it to itself... Just downloaded them directly off the gits and compared with HxD, and I do see the differences from 0x2C to 0x32:

IMGFS.BIN: 4C 5A 58 00 82 46 02
EMPTYIMG:  58 50 52 00 FE C2 01

Unfortunately, my battery is dead at the moment, and I have to let it fully charge before I can flash these test tinboots. I might get lucky and be able to try this tonight. If not, tomorrow morning when I get in to work, I have a folder with 4 different tinboots to try out in order of least to most brick risk :P

You "should" be good on not bricking, they are pretty good at handling a bad flash! Once you build them you can try to extract them just as a test... If you can't do that then you shouldn't flash them.

I was trying to do the same thing today, had a couple of bad flashes...
I think I was missing something.

If you want I can test, probably better with a USB cord, send me a PM or stop over at IRC chat...

What did you do to get them made?


Our imgfs.bin is getting inserted during the making process with the ImgfsToNb.exe. The Vogue's emptyimgfs is just getting built right in the kernel, this is why we don't see it on the NBHInfo.exe.

So... We should be able to just add it do the kernel like you have it above and forget about it. We might not even need it however, I read somewhere that it was just there because some flashing utilitly's (older one's like the Vogue) can't handle it.

[MassStash]

i'll try anything not TOO risky haha rhod400 fullycharged

lmiller: yea, you try and get at joojoobee or something?

[CageOff]

Originally Posted by Lmiller1708

You "should" be good on not bricking, they are pretty good at handling a bad flash! Once you build them you can try to extract them just as a test... If you can't do that then you shouldn't flash them.

I was trying to do the same thing today, had a couple of bad flashes...
I think I was missing something.

If you want I can test, probably better with a USB cord, send me a PM or stop over at IRC chat...

What did you do to get them made?


Our imgfs.bin is getting inserted during the making process with the ImgfsToNb.exe. The Vogue's emptyimgfs is just getting built right in the kernel, this is why we don't see it on the NBHInfo.exe.

So... We should be able to just add it do the kernel like you have it above and forget about it. We might not even need it however, I read somewhere that it was just there because some flashing utilitly's (older one's like the Vogue) can't handle it.

Master, Your bootloader put in os area of rhod___.Nbh ... write His in os area in NAND (OS mtd part)! Your Phone never bricking after flash!

[[ACL]]

modded partition table.

Hotfile.com: One click file hosting: rhod_payload

any brave souls ? just attach the empty imgfs to tinboot and hope the phone gods have mercy..

This is how it looks .. note no imgfs and 0 size in fat like vogue.

'rhod_payload' has valid boot sector
Partition table:
Partition 0
-----------
 File System:    0x20 (boot)
 Start Sector:   0x00000002
 Total Sectors:  0x0000003e
 Boot indicator: 0x00
 First Head:     0x02
 First Sector:   0x01
 First Track:    0x00
 Last Head:      0x3f
 Last Sector:    0x01
 Last Track:     0x00
Partition 1
-----------
 File System:    0x23 (XIP RAM)
 Start Sector:   0x00000040
 Total Sectors:  0x000006c0
 Boot indicator: 0x00
 First Head:     0x00
 First Sector:   0x01
 First Track:    0x01
 Last Head:      0x3f
 Last Sector:    0x01
 Last Track:     0x1b
Partition 2
-----------
 File System:    0x25 (imgfs)
 Start Sector:   0x00000700
 Total Sectors:  0x00000040
 Boot indicator: 0x00
 First Head:     0x00
 First Sector:   0x01
 First Track:    0x1c
 Last Head:      0x3f
 Last Sector:    0x01
 Last Track:     0x1c
Partition 3
-----------
 File System:    0x04 (FAT)
 Start Sector:   0x00000740
 Total Sectors:  0x00000000
 Boot indicator: 0x00
 First Head:     0x00
 First Sector:   0x01
 First Track:    0x1d
 Last Head:      0x3f
 Last Sector:    0x01
 Last Track:     0x25d
Geometry: flash has 64 virtual heads

MSFLSH50 header found at offset 0x800
  (0 Reserved Entries, 3 Flash Region Entries)
Flash Region Entry 0:
---------------------
  Region type:            XIP
  Start phys. block:      0x00000000
  Size in phys. blocks:   0x00000000
  Size in log. blocks:    0x0000001c -> Size in sectors: 0x00000700
  Sectors per block:      0x00000040
  Bytes per block:        0x00020000
  Compact blocks:         0x00000000
  -> Bytes per sector:    0x00000800
Flash Region Entry 1:
---------------------
  Region type:            READONLY_FILESYS
  Start phys. block:      0x00000000
  Size in phys. blocks:   0x00000000
  Size in log. blocks:    0x00000001 -> Size in sectors: 0x00000040
  Sectors per block:      0x00000040
  Bytes per block:        0x00020000
  Compact blocks:         0x00000002
  -> Bytes per sector:    0x00000800
Flash Region Entry 2:
---------------------
  Region type:            FILESYS
  Start phys. block:      0x00000000
  Size in phys. blocks:   0x00000000
  Size in log. blocks:    0xffffffff -> Size in sectors: 0xffffffc0
  Sectors per block:      0x00000040
  Bytes per block:        0x00020000
  Compact blocks:         0x00000002
  -> Bytes per sector:    0x00000800
Searching for IMGFS signature...
---

edit: ok tried it and so far no brick.. but cant boot since we dont have lzma support on the kernel. i can work on that but i really wanna test it. We need to put the initrd on a diet. right now its 1.6mb which is too big

[natemcnutty]

Originally Posted by [ACL]

modded partition table.

Hotfile.com: One click file hosting: rhod_payload

any brave souls ? just attach the empty imgfs to tinboot and hope the phone gods have mercy..

This is how it looks .. note no imgfs and 0 size in fat like vogue.

'rhod_payload' has valid boot sector
Partition table:
Partition 0
-----------
 File System:    0x20 (boot)
 Start Sector:   0x00000002
 Total Sectors:  0x0000003e
 Boot indicator: 0x00
 First Head:     0x02
 First Sector:   0x01
 First Track:    0x00
 Last Head:      0x3f
 Last Sector:    0x01
 Last Track:     0x00
Partition 1
-----------
 File System:    0x23 (XIP RAM)
 Start Sector:   0x00000040
 Total Sectors:  0x000006c0
 Boot indicator: 0x00
 First Head:     0x00
 First Sector:   0x01
 First Track:    0x01
 Last Head:      0x3f
 Last Sector:    0x01
 Last Track:     0x1b
Partition 2
-----------
 File System:    0x25 (imgfs)
 Start Sector:   0x00000700
 Total Sectors:  0x00000040
 Boot indicator: 0x00
 First Head:     0x00
 First Sector:   0x01
 First Track:    0x1c
 Last Head:      0x3f
 Last Sector:    0x01
 Last Track:     0x1c
Partition 3
-----------
 File System:    0x04 (FAT)
 Start Sector:   0x00000740
 Total Sectors:  0x00000000
 Boot indicator: 0x00
 First Head:     0x00
 First Sector:   0x01
 First Track:    0x1d
 Last Head:      0x3f
 Last Sector:    0x01
 Last Track:     0x25d
Geometry: flash has 64 virtual heads

MSFLSH50 header found at offset 0x800
  (0 Reserved Entries, 3 Flash Region Entries)
Flash Region Entry 0:
---------------------
  Region type:            XIP
  Start phys. block:      0x00000000
  Size in phys. blocks:   0x00000000
  Size in log. blocks:    0x0000001c -> Size in sectors: 0x00000700
  Sectors per block:      0x00000040
  Bytes per block:        0x00020000
  Compact blocks:         0x00000000
  -> Bytes per sector:    0x00000800
Flash Region Entry 1:
---------------------
  Region type:            READONLY_FILESYS
  Start phys. block:      0x00000000
  Size in phys. blocks:   0x00000000
  Size in log. blocks:    0x00000001 -> Size in sectors: 0x00000040
  Sectors per block:      0x00000040
  Bytes per block:        0x00020000
  Compact blocks:         0x00000002
  -> Bytes per sector:    0x00000800
Flash Region Entry 2:
---------------------
  Region type:            FILESYS
  Start phys. block:      0x00000000
  Size in phys. blocks:   0x00000000
  Size in log. blocks:    0xffffffff -> Size in sectors: 0xffffffc0
  Sectors per block:      0x00000040
  Bytes per block:        0x00020000
  Compact blocks:         0x00000002
  -> Bytes per sector:    0x00000800
Searching for IMGFS signature...
---

edit: ok tried it and so far no brick.. but cant boot since we dont have lzma support on the kernel. i can work on that but i really wanna test it. We need to put the initrd on a diet. right now its 1.6mb which is too big

Looks awesome. I'll be playing with it tomorrow. One way to get the size down a bit would be better referencing the files in sbin since they already exist in bin, but I think LMZA doesn't matter about storing multiple copies of the same file. I was thinking of a ln -s ../bin/adbd and ln -s ../bin/busybox for all the rest of those files if we need to keep .gz. I can test that out tomorrow and see how it works. Still not even sure if we need the sbin folder...

If you are looking for more space by replacing busybox, we can look at toybox or something similar. And maybe a lighter version of adbd?

Edit: Also, good news! In a couple of weeks, I may have a TMOUS TP2 to test with. No data, but that would give me a GSM device with a working USB port to mess around with

[[ACL]]

Originally Posted by natemcnutty

Looks awesome. I'll be playing with it tomorrow. One way to get the size down a bit would be better referencing the files in sbin since they already exist in bin. I was thinking of a ln -s ../bin/adbd and ln -s ../bin/busybox for all the rest of those files. I can test that out tomorrow and see how it works. Still not even sure if we need the sbin folder...

Edit: Also, good news! In a couple of weeks, I may have a TMOUS TP2 to test with. No data, but that would give me a GSM device with a working USB port to mess around with

nice nice.. i tried wiping everything bro.. and the damn initrd can only get to about 1.5mb. We need it to go around 1.1 so we can boot. This is why they added lzma support on the vogue. I'll port it over tomorrow

[Lmiller1708]

Originally Posted by MassStash

i'll try anything not TOO risky haha rhod400 fullycharged

lmiller: yea, you try and get at joojoobee or something?

Yes JooJooBee666 from PPCK is looking into this for us.
He thinks the partition start offsets are hard coded.
He will hopefully have something later on in the day.


@ACL,
With your partition table are you able to get the data to stick?
It seems our XIP RAM should be starting out in the same location for both Partition 0 and Partition 1. (Just a guess though)