• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root CM10 progress Update Thread

One of the few things I leave my house for is va appointments. That's where I'm at. As soon as I get home I'll be back on the job.

Stay groovy yall
 
isaacj87 said:
Okay, I believe it should be good to go now. Try seeing if that will get it to at least make it to the CM boot animation.

You can find my (current) replacement device tree here: https://github.com/ikarosdev/android_device_zte_elden/archive/master.zip

Make sure to clean out the whole source (make clobber), and run the extract-files script again. Any leftover stuff from previous builds will definitely cause booting to fail if not stop the build process.

If the thing won't build, post the error here, and I'll correct it and update my device tree. If you get a semi-booting build (or fully booting), I'll go ahead and send up a pull request. :)
Click to expand...

After fixing a couple typos, the build completed. Was left without the init.rc, it was left off the device.mk. So put in kitchen and added it. Then it didn't get past the splash screen. So I put it back in kitchen and replaced the init with the one from stock and it got past the splash and the android guy then a black screen again. Changed the ueventd.qcom.rc to ueventd.rc and got same result.
 
totlth said:
After fixing a couple typos, the build completed. Was left without the init.rc, it was left off the device.mk. So put in kitchen and added it. Then it didn't get past the splash screen. So I put it back in kitchen and replaced the init with the one from stock and it got past the splash and the android guy then a black screen again. Changed the ueventd.qcom.rc to ueventd.rc and got same result.
Click to expand...

Okay, thanks. Can you post the typos, so I can correct them?

I purposefully left out init.rc and the prebuilt init binary. Both of shouldn't be necessary. It didn't build with a init.rc because I forgot to remove this line in BoardConfig.mk:

Code: 
TARGET_PROVIDES_INIT_RC := true
Remove that line, and it will build and put a init.rc in the generated boot image. It's not going to work with the stock ROMs init.rc because you're not trying to boot the stock ROM. It needs to be the init.rc from CM (which gets auto included in the build after removing the line I suggested above).

I think you already found that one at /system/core/rootdir/init.rc

That's what will get CM booting, not the stock ROM init.rc. If you look at that file, you can see it will import the init for your particular hardware. That's why I named everything init.qcom.rc and ueventd.qcom.rc.
 
isaacj87 said:
Okay, thanks. Can you post the typos, so I can correct them?

I purposefully left out init.rc and the prebuilt init binary. Both of shouldn't be necessary. It didn't build with a init.rc because I forgot to remove this line in BoardConfig.mk:

Code: 
TARGET_PROVIDES_INIT_RC := true
Remove that line, and it will build and put a init.rc in the generated boot image. It's not going to work with the stock ROMs init.rc because you're not trying to boot the stock ROM. It needs to be the init.rc from CM (which gets auto included in the build after removing the line I suggested above).

I think you already found that one at /system/core/rootdir/init.rc

That's what will get CM booting, not the stock ROM init.rc. If you look at that file, you can see it will import the init for your particular hardware. That's why I named everything init.qcom.rc and ueventd.qcom.rc.
Click to expand...

Gotcha. Will do all suggestions. As for typos it was prebuilts to prebuilt on the egl config location and uneventd.rc on prebuilt side not changed with qcom in middle.
 
Also the qcomadreno that in our phone is 225 does that matter that the gpu is configured on board as 200
 
totlth said:
Also the qcomadreno that in our phone is 225 does that matter that the gpu is configured on board as 200
Click to expand...

The defines in BoardConfig trigger other makefiles in the rest of the CM source. I couldn't find

Code: 
TARGET_BOARD_PLATFORM_GPU := qcom-adreno225

anywhere. All the other MSM8960 devices use qcom-adreno200 (my device included), so that's what I went with.

I made some changes, and hopefully fixed the typos. You can see that here: https://github.com/ikarosdev/androi...mmit/84998783d191dbae198bd1fae2a098e46f14cf2c
 
isaacj87 said:
The defines in BoardConfig trigger other makefiles in the rest of the CM source. I couldn't find

Code: 
TARGET_BOARD_PLATFORM_GPU := qcom-adreno225

anywhere. All the other MSM8960 devices use qcom-adreno200 (my device included), so that's what I went with.

I made some changes, and hopefully fixed the typos. You can see that here: https://github.com/ikarosdev/androi...mmit/84998783d191dbae198bd1fae2a098e46f14cf2c
Click to expand...

I'm just asking to learn. I wasn't questioning your edits. I appreciate your help and input.
 
BOARD_EGL_CFG := device/zte/elden/prebuilts/lib/egl/egl.cfg
to
BOARD_EGL_CFG := device/zte/elden/prebuilt/lib/egl/egl.cfg

is the other typo, sorry I wasnt more clear in the other post. I was on my phone then.

and I thought the -DLGE_MSM8960 flag was intentional so I started my build without editing that. I just made commented out the line about providing the init.rc

should I cancel and start anew with that flag removed?
 
totlth said:
I'm just asking to learn. I wasn't questioning your edits. I appreciate your help and input.
Click to expand...

Oh, no worries! It good to ask because I've been out of the game so long. The last version of Android I was porting over was when ICS literally came out. That was well over a year ago. :o

I'm actually having to go back and try and catch up with all the changes that's happened so far. Concerning qcom-adreno200, I was trying to say that it's a conditional found in makefiles of source. It's an all encompassing term kinda. Even if you had a qcom-adreno205, you'd still use qcom-adreno200. Funny thing is, I combed through the source, and I can't find it anywhere anymore. I think it's actually useless now, but don't quote me on that. ;) I still see a lot of other MSM8960 devices using it, so I just followed along.

The -DLGE_MS8960 flag, I believe, is for LGE MSM8960 devices. I'm still trying to track down what exactly it does (in source), so I removed it for now. I figured since you guys have a ZTE device, it doesn't help to trigger a flag for LG devices.

It's my understanding that any changes to BoardConfig require a clean of the source. I've always done it that way, but it may have changed recently. Thanks for specifying the typo, I've fixed it now.

My guess is that you're pretty close to booting. If you getting to the splash screen, and then hit a black screen, at that point it's trying to boot the ROM. That should mean that your boot image is solid, minus a screwup somewhere in the inits. The Avid doesn't have a locked bootloader does it?
 
I'm wondering if an additional init.xxx.rc doesn't need to be made to include things that's not on the one in build system. Any suggestions anyone?
 
isaacj87 said:
Oh, no worries! It good to ask because I've been out of the game so long. The last version of Android I was porting over was when ICS literally came out. That was well over a year ago. :o

I'm actually having to go back and try and catch up with all the changes that's happened so far. Concerning qcom-adreno200, I was trying to say that it's a conditional found in makefiles of source. It's an all encompassing term kinda. Even if you had a qcom-adreno205, you'd still use qcom-adreno200. Funny thing is, I combed through the source, and I can't find it anywhere anymore. I think it's actually useless now, but don't quote me on that. ;) I still see a lot of other MSM8960 devices using it, so I just followed along.

The -DLGE_MS8960 flag, I believe, is for LGE MSM8960 devices. I'm still trying to track down what exactly it does (in source), so I removed it for now. I figured since you guys have a ZTE device, it doesn't help to trigger a flag for LG devices.

It's my understanding that any changes to BoardConfig require a clean of the source. I've always done it that way, but it may have changed recently. Thanks for specifying the typo, I've fixed it now.

My guess is that you're pretty close to booting. If you getting to the splash screen, and then hit a black screen, at that point it's trying to boot the ROM. That should mean that your boot image is solid, minus a screwup somewhere in the inits. The Avid doesn't have a locked bootloader does it?
Click to expand...

No its not locked
 
totlth said:
I'm wondering if an additional init.xxx.rc doesn't need to be made to include things that's not on the one in build system. Any suggestions anyone?
Click to expand...

You have it already. You have init.rc (the CM one that gets included when you complete a build). That will take care of booting CM. You also have init.qcom.rc, which I stole from the stock boot image (with no changes added) which will handle triggering the right services and binaries for your specific device. You also have ueventd.qcom.rc which will handle all the permissions necessary for your device.

You don't want to mess with init.rc because you shouldn't need to. You can play around with init.qcom.rc. If you find something with your hardware that doesn't get started correctly, that's where you look to start. However, since we're using the one from the stock boot image, it should be good to go. I only really glanced at it, but I didn't see anything funky in there.

If you're making it to the CM boot animation and it boot loops, that's when you start looking at system level stuff (RIL, EGL, bluetooth, etc.). I can tell you right now that you don't have all the shared libs for RIL. Running strace and looking at ADB will give you a clue at what's missing.

For example, usually I never get all the RIL libs on my first try. As the device boot loops, I will run adb shell, then I will run strace rild. That will tell me what libs I'm missing. Then I'll push the libs individually to the phone. I repeat the same process for all the other stuff too. Once you get everything it needs, it will boot.
 
totlth said:
Had to go back into the code cuz I was at a loss. But I did find a couple changes that needed to be made. So to answer your question, yes. How this build comes out will determine how much.

Stay groovy.
Click to expand...

Now it's just get a build to boot far enough for logcat so you have a better guidance system! Best of luck, can't wait for this tree to be finished so cyanogenmod can begin being worked on!
 
You must log in or register to reply here.
Back
Top Bottom