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

[Lmiller1708]

Originally Posted by [ACL]

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

Not sure if this will work or not but add this command at the start of the init file. Then we should be able to remove most of the bin files. Even though they are just links...

#Create all the symlinks to /bin/busybox
busybox --install -s

Hello everyone, I am writing this post maybe doing OT, but reading what you are doing I feel compelled to thank you and urge you even more.

Sorry for my bad English but I'm Italian.
I just have one question: You can now mount NAND Android?

Thanks again and good work.

[Lmiller1708]

Originally Posted by LucaC.

Hello everyone, I am writing this post maybe doing OT, but reading what you are doing I feel compelled to thank you and urge you even more.

Sorry for my bad English but I'm Italian.
I just have one question: You can now mount NAND Android?

Thanks again and good work.

Yes we can mount and boot to Android!
But after a reboot everything is getting wiped out do the SPL resting a flag.

And everything what works on Haret is working in NAND too? And what about battery life?

Im really looking forward to day when I will use Android as system for everyday usage. Thank you soo much for your work!!

[Lmiller1708]

Originally Posted by Andr3Wcz

And everything what works on Haret is working in NAND too? And what about battery life?

Im really looking forward to day when I will use Android as system for everyday usage. Thank you soo much for your work!!

Currently there are some issues but for the most part Yes... Once we get data to stick after a reboot this will be caught up to Haret very quickly (Thanks to ACL!!!)

Lmiller1708 thanks for the reply but I did not understand what happens if you restart the terminal?
So I can flash my htc black stone without the risk of breaking it and a version of almost running Android?

Thanks again for your attention and still really good job because I appreciate what you are doing!

[Lmiller1708]

Originally Posted by LucaC.

Lmiller1708 thanks for the reply but I did not understand what happens if you restart the terminal?
So I can flash my htc black stone without the risk of breaking it and a version of almost running Android?

Thanks again for your attention and still really good job because I appreciate what you are doing!

Whooo... No Sorry I didn't see your device. This is For TP2's Only. Not sure at all for the Black stone. But you are in the wrong Form.

Currently only CDMA Device's too...

[Lmiller1708]

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

Didn't get mine to flash correctly...
Here was how I made it.

cat xip/$1 >> os.nb.payload
echo "Inserting blank imgfs into payload"
OS-new.nb.payload >> tools/log
echo "Creating os.nb portion of nbh"
tools/nbmerge < os.nb.payload> OS-new.nb
echo "Creating NBH"
wine tools/yang.exe -F ruu_signed.NBH -f OS-new.nb -t 0x400 -s 64 -d RHOD****0 -c 11111111 -v Tinboot -l WWE >> tools/log

Ideas?

[[ACL]]

Originally Posted by Lmiller1708

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)

Cant boot. Moving the imgfs to tinboot put a size restriction on us. Vogue had the same issue so they had to implement lzma compression on the kernel (which we dont have). I can port it over tonight, for now i just need to know if we can shrink down the initrd.gz to around 1.1mb. Harder than i thought. I erased the sbin , modem stuff and logo and still to big. May need to wipe a few symlinks too?

This line is the one causing issues when trying to make the xip with the gz file.

.org XIP_END-0x20000,0xff

The only good news here is that i didnt brick myself with the partition table.

[[ACL]]

Originally Posted by Lmiller1708

Didn't get mine to flash correctly...
Here was how I made it.

cat xip/$1 >> os.nb.payload
echo "Inserting blank imgfs into payload"
OS-new.nb.payload >> tools/log
echo "Creating os.nb portion of nbh"
tools/nbmerge < os.nb.payload> OS-new.nb
echo "Creating NBH"
wine tools/yang.exe -F ruu_signed.NBH -f OS-new.nb -t 0x400 -s 64 -d RHOD****0 -c 11111111 -v Tinboot -l WWE >> tools/log

Ideas?

This is what im using

cp $DIRECTORY/tools/rhod_payload os.nb.payload
echo Inserting tinboot into payload
cat xip/$1 >> os.nb.payload
echo Creating os.nb portion of nbh
tools/nbmerge < os.nb.payload > OS-new.nb
echo Creating NBH
wine tools/yang.exe -F ruu_signed.NBH -f OS-new.nb -t 0x400 -s 64 -d RHOD****0 -c 11111111 -v Tinboot -l WWE >> $DIRECTORY/tools/log

rm os.nb.payload
rm OS-new.nb

in tinboot change these lines

-.equ XIP_END, 0x0100000
+.equ XIP_END, 0x2ff000

and add to the bottom (i think you alreayd had that)
+ .org XIP_END-0x20000,0xff
+ .incbin "tools/emptyimgfs"