View Single Post
  #1050 (permalink)  
Old 02-04-2011, 01:45 PM
[ACL]'s Avatar
[ACL]
VIP Member
Offline
Location: NY
 
Join Date: Feb 2010
Posts: 1,534
Reputation: 6350
[ACL] is a trusted member of the community[ACL] is a trusted member of the community[ACL] is a trusted member of the community[ACL] is a trusted member of the community[ACL] is a trusted member of the community[ACL] is a trusted member of the community[ACL] is a trusted member of the community[ACL] is a trusted member of the community[ACL] is a trusted member of the community[ACL] is a trusted member of the community[ACL] is a trusted member of the community
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Re: NAND Boot Testing - 01-07: Panel power on/off fixes

Quote:
Originally Posted by natemcnutty View Post
Well, this is going better than I expected. Unless someone tells me otherwise, I'm modifying the new bootenv/tinboot for the following:

1) Full NAND only (at least initially until it is stable)
2) Rhodium support only (taking out detection of other phones)
3) build.prop is now responsible for setting lcd density (currently 240 in FRX04 and makes our cmdline is redundant...)
4) Incorporating stinebd's OTA update.zip method
5) Froyo libs moved into system (see note below)

I've learned that you can't bind mount onto an initrd, so you have to use links and copy the data that way. Unfortunately, this poses a problem for our method of copying hw lib files based on the build type. For now, I am going to cook the libs into the system. This means we need to cook the libs and stuff into system for each build type (i.e. froyo, gingerbread, cynogen, etc.) that you want to try.

Here's the code I'm talking about:
Full nand is the only way to go.. you know my old saying ? "give me nand or give me death".. :-p

The other phones are so far behind nand its good if we wipe em out ..

Lets face it. Each build from now on will most likely need tweaking so moving the libs so we dont need to mount bind isnt a bad idea. Plus once the cookers get their hands on our precious code, bam they will release builds like wild fire. It will be up to them to move the modules to the right place. An alternative is to create a thin slice to hold the modules so we can mount bind them that way. But a new partition just for modules? i dunno if thats a good idea.

What about the rc files ? having a directory dedicated to just rc files like the haret rootfs limits us to builds. So we should just do the same as vogue (and every other build) and have the rc in the build itself.

i got so drunk last night and i had to call in sick. So im doing some small changes here and there to help out, but it sounds like you got it all under control. I'll have to commit the links for bin directly instead of the binaries and any patches you want to tinboot itself, let me know.

Also i'm uploading the frx04 now.. i'll post a link later.

Edit: Forgot about the screen calibration. ideas ?.
__________________

Last edited by [ACL]; 02-04-2011 at 02:20 PM.
Reply With Quote
This post has been thanked 2 times.