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

MassStash · #1 (**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]** · #2 (**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 · #3 (**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

**[ACL]** · #4 (**permalink**) 03-02-2011, 12:34 AM

I think i got it..

For now try this and tell me if it works.

adb into the phone and do the following

# /system/bin/pppd /dev/smd1 &
# ps w

Look for the rild service and kill it

kill <pid> <--- pid is the number shown when you do a "ps w"

Now that you have that look at your logcat and you will see pppd firing up. Try to browse the web and let me know how we cookin

**natemcnutty** · #5 (**permalink**) 03-02-2011, 03:36 AM

OK, regarding the mtdparts, I was thinking that maybe we should emulate the official Google dev phones which should help as we try to more closely stick to AOSP. If we get a bootloader that supports it, we should be able to use fastboot with this layout, and we may even be able to add CWM/ROM Manager support

mtdparts=msm_nand:
0x00480000@0x01000000(recovery) - (4,608 KB)
0x00300000@0x01480000(boot) - (3,072 KB)
0x09100000@0x01780000(system) - (148,480 KB)
0x05F00000@0x0A880000(cache) - (97,280 KB)
0x0F7E0000@0x10780000(userdata) - (253,824 KB)
0x000A0000@0x1FF60000(misc) - (640 KB)

The cache size may seem large, but that data is going to be cached somewhere, and it would ultimately end up in the userdata section anyway. We can conform to AOSP by having its own partition, and we should move the dalvik cache to that if it is being enabled. I think the more "best practices" we can use, the better performance we are going to get from our phone. Plus, roughly 250 MB of space for applications and such should be sufficient since we can just use app2sd.

For system, that should be more than enough space even if we were putting modules into the system. The latest Cyanogenmod systems are roughly 110 MB fully extracted. Not sure of the size of the sense builds, but I really think that should be plenty for the chefs.

I will be trying this partition layout tomorrow to make sure it works (don't see any reason it shouldn't). I'll also try changing /cache to mount on the cache partition and make sure that is working OK.

**[ACL]** · #6 (**permalink**) 03-02-2011, 02:29 PM

Quote:

Originally Posted by natemcnutty

OK, regarding the mtdparts, I was thinking that maybe we should emulate the official Google dev phones which should help as we try to more closely stick to AOSP. If we get a bootloader that supports it, we should be able to use fastboot with this layout, and we may even be able to add CWM/ROM Manager support

mtdparts=msm_nand:
0x00480000@0x01000000(recovery) - (4,608 KB)
0x00300000@0x01480000(boot) - (3,072 KB)
0x09100000@0x01780000(system) - (148,480 KB)
0x05F00000@0x0A880000(cache) - (97,280 KB)
0x0F7E0000@0x10780000(userdata) - (253,824 KB)
0x000A0000@0x1FF60000(misc) - (640 KB)

The cache size may seem large, but that data is going to be cached somewhere, and it would ultimately end up in the userdata section anyway. We can conform to AOSP by having its own partition, and we should move the dalvik cache to that if it is being enabled. I think the more "best practices" we can use, the better performance we are going to get from our phone. Plus, roughly 250 MB of space for applications and such should be sufficient since we can just use app2sd.

For system, that should be more than enough space even if we were putting modules into the system. The latest Cyanogenmod systems are roughly 110 MB fully extracted. Not sure of the size of the sense builds, but I really think that should be plenty for the chefs.

I will be trying this partition layout tomorrow to make sure it works (don't see any reason it shouldn't). I'll also try changing /cache to mount on the cache partition and make sure that is working OK.

So i found this online and wanted to share.

/misc - format raw: contains some storage for the SPL + means for some information to be transferred between the SPL/kernel

/recovery - bootable image (Kernel + ram disk see android documentation) the recovery image

/boot - bootable image (Kernel + ram disk see android documentation) contains the system kernel+ram disk

/system - the system data (not erased on factory restore) what is generally considered the "rom" (yaffs2 usually mounted at /system)

/cache - Temporary storage; or cached data.. usually persistent over reboots but not guaranteed (yaffs2 usually mounted at /cache) also used by recovery SPL for hboot/radio flashes; as the SPL must conduct these. Used by system/recovery for system initiated updates such as ota (not usually done from custom firmwares)

In terms of AOSP, we only need 3 partitions (sys, data and cache). Android doesn't deal with the others. Our SPL unlike the android ones may not actually use any of the partitions. And that will never change so we cant truly run like an oem phone. The other partitions are really for OEMs to decide if they want to implement. For example my galaxy S had a weird layout matching none ive seen before.

For example im sure a real android device may use the /misc mount to keep lets say its touch screen calibration points since spl reads it. But our spl writes it in some weird location we havent wiped (luckily) .. So that partition would be a real waste.

I guess we should table this until Alex decides how LK will be used. Until then i'm OK with adding cache for sure. And maybe 1 more for boot to allow kernel updates. But i doubt LK will be able to do things like update our radio.

With that said this is actually a tough decision. Cotulla himself will only make 3 parititons (sys, data, cache) and Stine doesnt really care much for cache since his OTA updates will be done another way. So with that said, we can use cache and possibly recovery. Rest will be a waste of space. How do you guys feel about that?

Edit: also the old sense was massive. I think 130mb just for system. So i can only imagine the newer sense builds.

**natemcnutty** · #7 (**permalink**) 03-02-2011, 04:20 PM

Thanks for the lowdown ACL. I'm not sure how much space you need for recovery/root, but I think you're right that we don't need a couple of the others. This is what I'll be using today, and maybe we can settle on this:

mtdparts=msm_nand:
0x00400000@0x01000000(recovery) - (4 MB)
0x0A000000@0x01400000(system) - (160 MB)
0x04000000@0x0B400000(cache) - (64 MB)
0x10C00000@0x0F400000(userdata) - (268 MB)

Gives extra headroom for Sense builds or future builds that get larger. Cache should be sufficient, but we would just take away from userdata and give to cache in the future if needed. And 250 MB are left for userdata (after modules) which is almost exactly what we have on Haret.

Let me know what you think and let's vote this thing