|
||||
Re: NAND Boot Testing - 01-07: Panel power on/off fixes
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. |
|
||||
Re: NAND Boot Testing - 01-07: Panel power on/off fixes
Quote:
/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. Last edited by [ACL]; 03-02-2011 at 02:43 PM. |
This post has been thanked 1 times. |
|
||||
Re: NAND Boot Testing - 01-07: Panel power on/off fixes
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 |
This post has been thanked 1 times. |
|
||||
Re: NAND Boot Testing - 01-07: Panel power on/off fixes
Quote:
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.. Code:
device mtd@misc 0460 radio diag Last edited by [ACL]; 03-02-2011 at 06:25 PM. |
|
||||
Re: NAND Boot Testing - 01-07: Panel power on/off fixes
Quote:
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. |
|
||||
Re: NAND Boot Testing - 01-07: Panel power on/off fixes
Quote:
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.
D/NetworkStateTracker( 140): setDetailed state, o |
|
||||
Re: NAND Boot Testing - 01-07: Panel power on/off fixes
Quote:
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. |
|
||||
Re: NAND Boot Testing - 01-07: Panel power on/off fixes
"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. |
|
||||
Re: NAND Boot Testing - 01-07: Panel power on/off fixes
Quote:
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... Code:
mtdparts=msm_nand:0x20000000@0x0(nand),0x800000@0x4000000(root),0x0A000000@0x4800000(system),0xF800000@0xE800000(userdata),0x2000000@0x1E000000(cache) Code:
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!
__________________
|
|
|
|