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

**[ACL]** · #**1181** (**permalink**) 02-11-2011, 03:42 AM

Quote:

Originally Posted by Lmiller1708

Yup I did test it.... but it was still a no go. I haven't been able to make aa good bootable build all day.

I wasn't able to get ahold of JooJoBee666 today so hopefully tomorrow he willbe able to help.

ahh its all good. I ran a test with a small initrd and it didnt boot. So now im thinking that size isnt the only problem.

i barely had any time today so im looking forward to the weekend to tackle this

**Lmiller1708** · #**1182** (**permalink**) 02-11-2011, 08:16 AM

Quote:

Originally Posted by [ACL]

ahh its all good. I ran a test with a small initrd and it didnt boot. So now im thinking that size isnt the only problem.

i barely had any time today so im looking forward to the weekend to tackle this

Well that's good to know. I figured out how to change the partation table so I will play with it some more today.

I might have some time this weekend... The wife is already going to kill me anyways! But she is running Android too and I hope to have her switched over to NAND this weekend.

Now they got the Server_Bug figured out it she will be happy!

Update:

I was able to get it to boot this morning. What is your ETA on adding LZMA compression?

**[ACL]** · #**1183** (**permalink**) 02-11-2011, 10:55 AM

Quote:

Originally Posted by Lmiller1708

Well that's good to know. I figured out how to change the partation table so I will play with it some more today.

I might have some time this weekend... The wife is already going to kill me anyways! But she is running Android too and I hope to have her switched over to NAND this weekend.

Now they got the Server_Bug figured out it she will be happy!

Update:

I was able to get it to boot this morning. What is your ETA on adding LZMA compression?

woa really.. you were able to boot with a modded partition table ?

well i started studying the lzma patch yesterday and i can have it done by sat morning, but if you have it booting without it then there may be no need. The initrd is so huge because of all the busybox crap we have in there. Nate is right about that, its just really big. Can we get a smaller busybox with just the bare essentials.

I took apart some initrds from real android devices and they are tiny. Mainly because they dont have modded scripts or busybox to do the installation for them.

So correct me if im wrong here, but doesnt that mean we just need busybox to install and thats it? i think android already auto mounts everything else so thers is no need to mount it on the initrd. anyways just a theory..

**natemcnutty** · #**1184** (**permalink**) 02-11-2011, 12:14 PM

Quote:

Originally Posted by [ACL]

woa really.. you were able to boot with a modded partition table ?

well i started studying the lzma patch yesterday and i can have it done by sat morning, but if you have it booting without it then there may be no need. The initrd is so huge because of all the busybox crap we have in there. Nate is right about that, its just really big. Can we get a smaller busybox with just the bare essentials.

I took apart some initrds from real android devices and they are tiny. Mainly because they dont have modded scripts or busybox to do the installation for them.

So correct me if im wrong here, but doesnt that mean we just need busybox to install and thats it? i think android already auto mounts everything else so thers is no need to mount it on the initrd. anyways just a theory..

Hehe, ACL, the two files we need to consider changing are adbd and busybox. I've already looked into both busybox and mtd_utils (which has our flash_erase). It is possible to compile busybox with only the commands that we use during boot, and man are there a ton of them in there that we don't use... I think I can get busybox down to around 400K, compile flash_erase independently, and then maybe find a smaller version of adbd. Realistically, I think we can do this in the 1.1 MB envelope you were wanting

For mounting sys before Android does it for us, we need to mount it to make changes like keyboard layout, LCD density, and cmdline stuff.

**natemcnutty** · #**1185** (**permalink**) 02-11-2011, 12:19 PM

Quote:

Originally Posted by Lmiller1708

Well that's good to know. I figured out how to change the partation table so I will play with it some more today.

I might have some time this weekend... The wife is already going to kill me anyways! But she is running Android too and I hope to have her switched over to NAND this weekend.

Now they got the Server_Bug figured out it she will be happy!

Update:

I was able to get it to boot this morning. What is your ETA on adding LZMA compression?

That is really great news! Did you just hex edit the partition table? I'll be putting together some nice documentation on what I've done for busybox and tinboot once I get it all ironed out. I'm trying to get my hands on a couple TP2's from work to mtty and find the exact memory addresses we need

**[ACL]** · #**1186** (**permalink**) 02-11-2011, 12:23 PM

Quote:

Originally Posted by natemcnutty

Hehe, ACL, the two files we need to consider changing are adbd and busybox. I've already looked into both busybox and mtd_utils (which has our flash_erase). It is possible to compile busybox with only the commands that we use during boot, and man are there a ton of them in there that we don't use... I think I can get busybox down to around 400K, compile flash_erase independently, and then maybe find a smaller version of adbd. Realistically, I think we can do this in the 1.1 MB envelope you were wanting

For mounting sys before Android does it for us, we need to mount it to make changes like keyboard layout, LCD density, and cmdline stuff.

Its worth a shot. You handling that then ?

To test yesterday i took the initrd from a cyanogen build which was only abotu 200k. Thats when i realized there is absolutely nothing in there besides the empty directories to mount everything. The androird rc had all the mount points needed so no script work had to be done.

once we have that lets shoot it over to lmiller since he has it booting with a modded table

Dont worry about the keyboard poop at all. That is handled by the android update. What this does is permanently modify /system with the correct stuff so you dont need to mount bind it at all. thnk about it, would you replace your tp2 keyboard layout? Same goes for the density. Cmdline cannot change, it should not change. Its just bad practice.

**Lmiller1708** · #**1187** (**permalink**) 02-11-2011, 01:20 PM

Yes it was with the modded table.
I'm pretty sure we should be able to change the size of the NBH... But I haven't figured that out just yet.

If one of you could pass me the initrd.gz that would be great.

Here is what my table looks like:

Code:

NBInfo 2.1rc2

'..\rhod_payload' has valid boot sector

Partition table:

Partition 0
-----------
 File System:    0x23 (XIP RAM)
 Start Sector:   0x00000002
 Total Sectors:  0x0000063e
 Boot indicator: 0x00
 First Head:     0x02
 First Sector:   0x01
 First Track:    0x00
 Last Head:      0x3f
 Last Sector:    0x01
 Last Track:     0x18

Partition 1
-----------
 File System:    0x23 (XIP RAM)
 Start Sector:   0x00000640
 Total Sectors:  0x00000000
 Boot indicator: 0x00
 First Head:     0x00
 First Sector:   0x01
 First Track:    0x19
 Last Head:      0x3f
 Last Sector:    0x01
 Last Track:     0x1b

Partition 2
-----------
 File System:    0x25 (imgfs)
 Start Sector:   0x00000640
 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:   0x00000640
 Total Sectors:  0x00000000
 Boot indicator: 0x00
 First Head:     0x00
 First Sector:   0x01
 First Track:    0x1d
 Last Head:      0x3f
 Last Sector:    0x3f
 Last Track:     0x3ff

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: Wrong Table...