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

**[ACL]** · #**1411** (**permalink**) 03-01-2011, 10:42 AM

Quote:

Originally Posted by natemcnutty

Note: We never made some of the commits from Haret, so we don't want the navi_pad stuff or it messes up our buttons.

Also, no need for the following stuff since we moved these files into system:

Code:

cp -af /init.etc/keymaps/qwerty.kcm.bin /init.etc/keymaps/qwerty.kl /etc/keymaps/
mount --bind /etc/keymaps /system/usr/keychars
mount --bind /etc/keymaps /system/usr/keylayout

It seems that the init.android from our rootfs requires ueventd and ueventd.rc to be included. I have it to the point where the boot animation starts, but it just goes on forever and never finishes loading. Not really sure how to diagnose that without having ADB. I guess I could upload the files for someone else to take a look at it, but that seems like a lot of effort :P

I'm confused about the navipad stuff you mentioned. I'm a few commits behind but you are saying i should not commit anything navipad ?

I dont think i have any mountbinds. If i do, let me know. I should not since they cant be used. This was a complete hack we implemented back in the day which people got too comfy with.

Yes, uevend i saw while booting. I dont have it so it just errors out and skips it. what is it and what does it do ? I was actually going to remove it since i though it was more for gingerbread. Need more info on this service i suppose.

If i cant get a new ril today then simlink from /bin/pppd to /system/bin/pppd will be our solution.. falling behind on the next build.. I dont see any other reason now to fully release this to more people.

also fellas.. mtdparts.. someone do the math today we can agree on..

**Lmiller1708** · #**1412** (**permalink**) 03-01-2011, 11:35 AM

Quote:

Originally Posted by [ACL]

I'm confused about the navipad stuff you mentioned. I'm a few commits behind but you are saying i should not commit anything navipad ?

I dont think i have any mountbinds. If i do, let me know. I should not since they cant be used. This was a complete hack we implemented back in the day which people got too comfy with.

Yes, uevend i saw while booting. I dont have it so it just errors out and skips it. what is it and what does it do ? I was actually going to remove it since i though it was more for gingerbread. Need more info on this service i suppose.

If i cant get a new ril today then simlink from /bin/pppd to /system/bin/pppd will be our solution.. falling behind on the next build.. I dont see any other reason now to fully release this to more people.

also fellas.. mtdparts.. someone do the math today we can agree on..

I put together a Spreadsheet for figuring out NAND, only change the values in RED. See Attached

So here is what we currently have:

Code:

mtdparts=msm_nand:0x20000000@0x0(nand),0x01000000@0x04000000(root),0x08000000@0x05000000(system),0x13000000@0x0D000000(userdata)

This is with root set to 5MB, This would give the system 143 MB and Data 300MB:

Code:

mtdparts=msm_nand:0x20000000@0x0(nand),0x500000@0x04000000(root),0x8F00000@0x4500000(system),0x12c00000@0xD400000(userdata)

Again maybe we can change the starting point to a smaller value other then 4000000... But it's only 3.8MB of space... Maybe this is where the Kernal is kept which it 3.6MB currently...

**natemcnutty** · #**1413** (**permalink**) 03-01-2011, 11:51 AM

Quote:

Originally Posted by Lmiller1708

I put together a Spreadsheet for figuring out NAND, only change the values in RED. See Attached

So here is what we currently have:

Code:

mtdparts=msm_nand:0x20000000@0x0(nand),0x01000000@0x04000000(root),0x08000000@0x05000000(system),0x13000000@0x0D000000(userdata)

This is with root set to 5MB, This would give the system 143 MB and Data 300MB:

Code:

mtdparts=msm_nand:0x20000000@0x0(nand),0x500000@0x04000000(root),0x8F00000@0x4500000(system),0x12c00000@0xD400000(userdata)

Again maybe we can change the starting point to a smaller value other then 4000000... But it's only 3.8MB of space... Maybe this is where the Kernal is kept which it 3.6MB currently...

I'll look at this in a bit when I get in, but quick comment on it starting at 0x4000000. That is actually 64 MB into the NAND, and we certainly don't need that much space. Also, what exactly is the point of the root partition since I don't think we are using it? I'm really curious what its purpose is supposed to be

**Lmiller1708** · #**1414** (**permalink**) 03-01-2011, 11:56 AM

Quote:

Originally Posted by natemcnutty

I'll look at this in a bit when I get in, but quick comment on it starting at 0x4000000. That is actually 64 MB into the NAND, and we certainly don't need that much space. Also, what exactly is the point of the root partition since I don't think we are using it? I'm really curious what its purpose is supposed to be

Where do you get 64MB?

Also we can change and remove these MTDParts as need be... Maybe just leave it up to the cooks.
If we want to add the cache we can with no problem.

Edit: I think ACL has plans for the Root...

**natemcnutty** · #**1415** (**permalink**) 03-01-2011, 12:51 PM

Quote:

Originally Posted by Lmiller1708

Where do you get 64MB?

Also we can change and remove these MTDParts as need be... Maybe just leave it up to the cooks.
If we want to add the cache we can with no problem.

Edit: I think ACL has plans for the Root...

I get 64 MB by this:

0x04000000 (base 16) = 67,108,864 (base 10)
67,108,864 (bytes) / 1024 = 65,536 (kb) / 1024 = 64 (MB)

The kernel and tinboot code only occupy the first 6 MB or so of NAND. I think we could safely shrink the starting point to 16 MB without any fear of overwriting stuff. How does this look:

mtdparts=msm_nand:
0x20000000@0x0(nand) - 512 MB total
0x00800000@0x01000000(root) - 8 MB of space
0x0A000000@0x01800000(system) - 160 MB of space
0x14800000@0x0B800000(userdata) - 328 MB of space

I think 160 MB might be a bit much for system, but that does give the chefs a lot of space to work with. 328 MB for user data will really be 310 MB of usable space since we are eating up 18 MB with modules.

**[ACL]** · #**1416** (**permalink**) 03-01-2011, 01:03 PM

Quote:

Originally Posted by natemcnutty

I get 64 MB by this:

0x04000000 (base 16) = 67,108,864 (base 10)
67,108,864 (bytes) / 1024 = 65,536 (kb) / 1024 = 64 (MB)

The kernel and tinboot code only occupy the first 6 MB or so of NAND. I think we could safely shrink the starting point to 16 MB without any fear of overwriting stuff. How does this look:

mtdparts=msm_nand:
0x20000000@0x0(nand) - 512 MB total
0x00800000@0x01000000(root) - 8 MB of space
0x0A000000@0x01800000(system) - 160 MB of space
0x14800000@0x0B800000(userdata) - 328 MB of space

I think 160 MB might be a bit much for system, but that does give the chefs a lot of space to work with. 328 MB for user data will really be 310 MB of usable space since we are eating up 18 MB with modules.

You guys are better at this than me so whatever you think its best.

Nate: i explained the root, i need it for kexec. Its so we can make kernel updates without flashing. Now the everyday user doesnt really need this since they will stick to a stable releases, but for us it wll help so we dont burn our phones constantly flashing.

Also i thought you wanted a cache parititon. throw it in there if you want to mess with it. Not sure what to do with it but hey, let the creativity flow. ALso we can keep the kexec for dev only and share it for cache ?

Edit: also here is another test RIL

http://dl.dropbox.com/u/12183048/htc...ystem_bin_pppd

**Lmiller1708** · #**1417** (**permalink**) 03-01-2011, 02:33 PM

Quote:

Originally Posted by natemcnutty

I get 64 MB by this:

0x04000000 (base 16) = 67,108,864 (base 10)
67,108,864 (bytes) / 1024 = 65,536 (kb) / 1024 = 64 (MB)

The kernel and tinboot code only occupy the first 6 MB or so of NAND. I think we could safely shrink the starting point to 16 MB without any fear of overwriting stuff. How does this look:

mtdparts=msm_nand:
0x20000000@0x0(nand) - 512 MB total
0x00800000@0x01000000(root) - 8 MB of space
0x0A000000@0x01800000(system) - 160 MB of space
0x14800000@0x0B800000(userdata) - 328 MB of space

I think 160 MB might be a bit much for system, but that does give the chefs a lot of space to work with. 328 MB for user data will really be 310 MB of usable space since we are eating up 18 MB with modules.

Ok that makes sense thanks for the explanation!

Did you mean to start your root at 0x0100000 and not 0x01000000?
Just checking.
Also lets just set to root 5MB for now. That way ACL can commit.

If need be the cookers can always just hex the size.

This is what I have now:
mtdparts=msm_nand:
0x20000000@0x0(nand) - 512 MB total
0x500000@0x100000(root) - 5 MB of space
0xA000000@0x600000(system) - 160 MB of space
0x14B00000@0xA600000(userdata) - 331 MB of space
Unused: 100000 - .95 MB

Again I didn't test these...

MassStash · #**1418** (**permalink**) 03-01-2011, 03:41 PM

booting with new ril...

update: homescreen.... nah, nothing. APN change to #777, nothing anything else i try before work at 4:30?

**[ACL]** · #**1419** (**permalink**) 03-01-2011, 04:12 PM

Quote:

Originally Posted by MassStash

booting with new ril...

update: homescreen.... nah, nothing. APN change to #777, nothing

fak...

gonna have to test the symlink method..

MassStash · #**1420** (**permalink**) 03-01-2011, 04:13 PM

yea hows i do that? symlink of pppd eh?

Update: answer to my question is remake the initrd.
So i think acl's putting service on his beast tonight to knock this one out....
Did what i Could haha