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

[[ACL]]

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]

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]]

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]

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

[[ACL]]

Originally Posted by natemcnutty

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

its looking better. I would say increase recovery by 4 more to make it 8mb. And reduce it out of cache. Those two can balance themselves out so we can leave sys and data. Recovery can server both as boot/recovery since it will have another kernel initrd and anything needed to rebuild android from the inside out. Prob a beefy busybox and every nand tool around.

I'm trying to find out on average how much space is actually used on cache. Not much since it looks like it gets wiped often. So 32mb is enough to have a good androidupdate.tgz incase we wanna update from nand itself. Let see what lmiller has to say ..

Also this link was helpful. Im taking appart all these images and stealing what we can.

How to: Rooting your Nexus One - a definitive guide to what's involved - Nexus One - News

They talk about recovery images and root boot. i already took appart some and they are interesting. Lots to learn

Edit: ok tore appart the whole recovery and we can definitely used some of these tools. Unfortunately i did find this..

device mtd@misc 0460 radio diag

This is from the modaco recovery and cotulla mentioned the CWM recovery may use it as well. Just that no one know whats it used for. Some poople say you can do without it, but i guess only testing will show. I'm not sure if our radio needs access to it? so this may require research.

[natemcnutty]

Originally Posted by [ACL]

its looking better. I would say increase recovery by 4 more to make it 8mb. And reduce it out of cache. Those two can balance themselves out so we can leave sys and data. Recovery can server both as boot/recovery since it will have another kernel initrd and anything needed to rebuild android from the inside out. Prob a beefy busybox and every nand tool around.

I'm trying to find out on average how much space is actually used on cache. Not much since it looks like it gets wiped often. So 32mb is enough to have a good androidupdate.tgz incase we wanna update from nand itself. Let see what lmiller has to say ..

Also this link was helpful. Im taking appart all these images and stealing what we can.

How to: Rooting your Nexus One - a definitive guide to what's involved - Nexus One - News

They talk about recovery images and root boot. i already took appart some and they are interesting. Lots to learn

Edit: ok tore appart the whole recovery and we can definitely used some of these tools. Unfortunately i did find this..

device mtd@misc 0460 radio diag

This is from the modaco recovery and cotulla mentioned the CWM recovery may use it as well. Just that no one know whats it used for. Some poople say you can do without it, but i guess only testing will show. I'm not sure if our radio needs access to it? so this may require research.

From what I've been reading, you are able to flash different radios/modems from CWM, but it seems when people make their own custom partition layouts, most of them say NOT to flash radio's from it. Read through a ton of different dev threads at XDA, and that seems to be the common consensus.

I doubt the radio needs access since other devices like the vogue work and don't have it, but if it is in AOSP to cache some info about the radio into that partition, we can always create it later on

Also, I updated the partition layout for LMiller's spreadsheet. I just took 8 MB from data and moved it into recovery. I want to keep my cache at 64 MB until I can get a feel for the average size it gets up to. I've seen reports on native android phones that when people made it small like 24 MB, they were experiencing slowdowns because of the paging.

[[ACL]]

Originally Posted by natemcnutty

From what I've been reading, you are able to flash different radios/modems from CWM, but it seems when people make their own custom partition layouts, most of them say NOT to flash radio's from it. Read through a ton of different dev threads at XDA, and that seems to be the common consensus.

I doubt the radio needs access since other devices like the vogue work and don't have it, but if it is in AOSP to cache some info about the radio into that partition, we can always create it later on

Also, I updated the partition layout for LMiller's spreadsheet. I just took 8 MB from data and moved it into recovery. I want to keep my cache at 64 MB until I can get a feel for the average size it gets up to. I've seen reports on native android phones that when people made it small like 24 MB, they were experiencing slowdowns because of the paging.

Ok, then we will keep the recovery and cache. Whats the latest mtdparts then ?

Fukin boostmobile wont activate my tp2.. so im going to have to release a few rils and hope yall can help get this data set already. Arrg has come the closest manually but not stable. Lmillers logs show that it comes up, he gets an IP and everything but soon dies.

1. W/pppd ( 455): Couldn't allocate PPP unit 0 as it is already in use
2. E/pppd ( 455): Couldn't attach to PPP unit 1: Invalid argument

We have those errors that make no sense to me. Full paste bin below.

D/NetworkStateTracker( 140): setDetailed state, o

[odz]

Originally Posted by [ACL]

Ok, then we will keep the recovery and cache. Whats the latest mtdparts then ?

Fukin boostmobile wont activate my tp2.. so im going to have to release a few rils and hope yall can help get this data set already. Arrg has come the closest manually but not stable. Lmillers logs show that it comes up, he gets an IP and everything but soon dies.

1. W/pppd ( 455): Couldn't allocate PPP unit 0 as it is already in use
2. E/pppd ( 455): Couldn't attach to PPP unit 1: Invalid argument

We have those errors that make no sense to me. Full paste bin below.

D/NetworkStateTracker( 140): setDetailed state, o

I had a hard time activating my tp2 on boost too but then a friend told me about this site sprint2boost.com. It took about 6hrs for the guy to get it hooked up for me. Its $30 but if he cant get it hooked up for you you'll get refunded $25. I tried calling and all that but that got me nowhere. You could always put it on pay as you go and use it once and a while to test stuff.

[psu2fan]

"Fukin boostmobile wont activate my tp2.."

Keep tryin. It took me 7 or 8 calls. Your best chance is calling in the last half hour the CS reps are there. Do you have a boost account already? Check out this thread for helpful tips.. if you haven't already. You just need the right rep.

[Lmiller1708]

Originally Posted by natemcnutty

From what I've been reading, you are able to flash different radios/modems from CWM, but it seems when people make their own custom partition layouts, most of them say NOT to flash radio's from it. Read through a ton of different dev threads at XDA, and that seems to be the common consensus.

I doubt the radio needs access since other devices like the vogue work and don't have it, but if it is in AOSP to cache some info about the radio into that partition, we can always create it later on

Also, I updated the partition layout for LMiller's spreadsheet. I just took 8 MB from data and moved it into recovery. I want to keep my cache at 64 MB until I can get a feel for the average size it gets up to. I've seen reports on native android phones that when people made it small like 24 MB, they were experiencing slowdowns because of the paging.

I think for the radio we should just leave it alone. If we need to update the radio or anything like that we can just do it flash. It's more for Native android devices anyway.

Nate glad you got into the spreadsheet. I added in 4MB to your data, you want to make sure you have your left over the same value as your first starting location. Have you tried using these values yet?
Anyone wanting to look at the spreadsheet can go HERE.

@ACL,
I would say just go with this MTD Parts: (What we kinda decided on earlier) And boot can be recovery... I will leave that up to you...

mtdparts=msm_nand:0x20000000@0x0(nand),0x800000@0x4000000(root),0x0A000000@0x4800000(system),0xF800000@0xE800000(userdata),0x2000000@0x1E000000(cache)

Or If Nate has verified the starting location of 100000:

mtdparts=msm_nand:0x20000000@0x0(nand),0x800000@0x1000000(root),0x0A000000@0x1800000(system),0x12800000@0xB800000(userdata),0x2000000@0x1E000000(cache)

And remember... This can be changed by anyone who can open the NBH with a hex editor!