[DEV] CyanogenMod 10.1

chad0989 · Mar 14, 2013

crpalmer said:
I don't have time to do any real work on this (this is my daily driver, use heavily for work phone and it's a time sink to backup/restore/fix /sdcard/0) today,but I took the boot.img and changed init.rc to include init.dlx.usb.rc instead of init.usb.rc and I believe that should get adb up and running for you.

To test, I booted viper 1.1.3 with the old kernel (no adb ever, but amazingly enough the display works enough for the boot animation) and booted it with the changed kernel which give me adb access.

I bet that was it for sure. I renamed some of the init scripts when I pulled them into the tree so it built a functional boot.img. I fixed it from my phone and updated. Hopefully if everyone re syncs and rebuilds the bootimage it should be good now.

Sent from my HTC6435LVW using xda app-developers app

EmericanX · Mar 14, 2013

crpalmer said:
I don't have time to do any real work on this (this is my daily driver, use heavily for work phone and it's a time sink to backup/restore/fix /sdcard/0) today,but I took the boot.img and changed init.rc to include init.dlx.usb.rc instead of init.usb.rc and I believe that should get adb up and running for you.

To test, I booted viper 1.1.3 with the old kernel (no adb ever, but amazingly enough the display works enough for the boot animation) and booted it with the changed kernel which give me adb access.

Lol. I over looked the /sdcard/0 issue but got back going last night. Could've just used a different phone for the time being but the DNA is my favorite of the bunch. I figured it would be something simple in ramdisk but needed to get to sleep lol... I'll make the adjustments you found and take another look tonight.

Sent from my HTC6435LVW using Tapatalk 2

---------- Post added at 09:40 AM ---------- Previous post was at 09:38 AM ----------

chad0989 said:
I bet that was it for sure. I renamed some of the init scripts when I pulled them into the tree so it built a functional boot.img. I fixed it from my phone and updated. Hopefully if everyone re syncs and rebuilds the bootimage it should be good now.

Sent from my HTC6435LVW using xda app-developers app

You're supposed to be out of town! Lol..

Sent from my HTC6435LVW using Tapatalk 2

Flyhalf205 · Mar 14, 2013

chad0989 said:
I bet that was it for sure. I renamed some of the init scripts when I pulled them into the tree so it built a functional boot.img. I fixed it from my phone and updated. Hopefully if everyone re syncs and rebuilds the bootimage it should be good now.

Sent from my HTC6435LVW using xda app-developers app

Always working even out of town lol..

But anyways. In the Jellybean branch you modified the init.target.rc but we don't have a init.dlx.usb.rc. We do have a init.usb.rc... Even if we did rename this...the init.rc calls for init.usb.rc so in the end we are good? I just confused myself typing this so I hope it makes sense. haha

chad0989 · Mar 14, 2013

Flyhalf205 said:
Always working even out of town lol..

But anyways. In the Jellybean branch you modified the init.target.rc but we don't have a init.dlx.usb.rc. We do have a init.usb.rc... Even if we did rename this...the init.rc calls for init.usb.rc so in the end we are good? I just confused myself typing this so I hope it makes sense. haha

Yeah. That was an mistake but I couldnt easily revert it from my phone. After I edited the other one I clicked on the jb branch, saw your last commit and thought I had deleted the line by accident. You can just revert it if you want.

Sent from my HTC6435LVW using xda app-developers app

t1gartist · Mar 14, 2013

what cxommands are you using after make finishes compiling i tried breakfast but no go and by no means trying to be funny im just not sure where you build file is for the dna as everyone seems to have a different location for something

chad0989 · Mar 15, 2013

t1gartist said:
what cxommands are you using after make finishes compiling i tried breakfast but no go and by no means trying to be funny im just not sure where you build file is for the dna as everyone seems to have a different location for something

. build/envsetup.sh
brunch dlx

Sent from my HTC6435LVW using xda app-developers app

EmericanX · Mar 15, 2013

Got adb. With boot animation. But "adv devices" yeilds "blahblahblah : offline" lol.. pulled a kernel log once it could get adb shell via recovery and its over and over adb service already running" or something along those lines.. anyone ever seen this?

Sent from my HTC6435LVW using Tapatalk 2

djh816 · Mar 15, 2013

sounds like stuck on rsa authentication (new to 4.2). could try just disabling it for now ro.adb.secure 0

More info for anyone interested: http://stackoverflow.com/questions/15225991/android-4-2-2-rsa-disabling

EmericanX · Mar 16, 2013

that was definitely the ticket to initial adb issues. As of right now you'll get adb during first boot but after that you'll need to wipe data for it to even register the device again. I'm headed out for the night but I pulled logcats and kernel log if anyone wants to poke around...

Logcat is ---> PasteBIN

kmsg is ---> PasteBIN

FYI: as of right now display is definitely working. It is not recovering once it times out but will stay on as long as time out is not reached. Phone calls out but there is no audio currently. LTE is also functional.

crpalmer · Mar 16, 2013

I spent a little time working to figure out how to get the display back on.

Since adb in cm-10.1 was annoying for testing, I started out by working with my normal Viper 1.1.3 system. I pulled chad's commit into my kernel and experienced the same problem with. The following commit makes the display turn back on when running under viper:

https://github.com/crpalmer/android_kernel_htc_dlx/commit/03a49612fe2fc3c73ff11b58c0f915960de3cb9a

but when I put it into cm-10.1, the display_on function doesn't appear to be called and it doesn't work. I haven't spent any time looking into why, but I wanted to share the commit in case someone else wants to look at the display code. It will be much more pleasant working on other issues when the screen timeout doesn't force you to reboot...

chad0989 · Mar 16, 2013

crpalmer said:
I spent a little time working to figure out how to get the display back on.

Since adb in cm-10.1 was annoying for testing, I started out by working with my normal Viper 1.1.3 system. I pulled chad's commit into my kernel and experienced the same problem with. The following commit makes the display turn back on when running under viper:

https://github.com/crpalmer/android_kernel_htc_dlx/commit/03a49612fe2fc3c73ff11b58c0f915960de3cb9a

but when I put it into cm-10.1, the display_on function doesn't appear to be called and it doesn't work. I haven't spent any time looking into why, but I wanted to share the commit in case someone else wants to look at the display code. It will be much more pleasant working on other issues when the screen timeout doesn't force you to reboot...

display_on doesn't exist in the mako FB, only lcd_on/off. I noted the display issue but haven't gotten a chance to remedy it. I just got home so hopefully I'll have some time in the next couple days.

drewX2 · Mar 16, 2013

I thought I would give some tips for you guys.

For starters, the init files are way off. Much of getting it booting right and having things work properly after you get it to the UI have to do with this. Regarding libs/binaries, it's true that many of mako libs and binaries can be used, but you need to utilize more of the DNA. For wifi/bluetooth, I am not sure using your current method will work as the DNA doesn't use qualcomm's hardware/implementation (I was unable, but you might); the DNA has a gpio conflict as seen in kernel source (board-monarudo.c) therefore HTC created a work around for it. Even if you did get it working, I don't know that bluetooth would ever work.

chad0989 · Mar 16, 2013

drewX2 said:
I thought I would give some tips for you guys.

For starters, the init files are way off. Much of getting it booting right and having things work properly after you get it to the UI have to do with this. Regarding libs/binaries, it's true that many of mako libs and binaries can be used, but you need to utilize more of the DNA. For wifi/bluetooth, I am not sure using your current method will work as the DNA doesn't use qualcomm's hardware/implementation (I was unable, but you might); the DNA has a gpio conflict as seen in kernel source (board-monarudo.c) therefore HTC created a work around for it. Even if you did get it working, I don't know that bluetooth would ever work.

It turned out it was just the storage path not being exported that was preventing it from fully booting. I actually just fixed it earlier today and pushed something an hour or two ago. I'm working on cleaning up the init scripts / permission and moving them inline with the mako so we can ditch the prebuilt init.rc. I'm probably also going to ditch msm8960-common as we don't have much in common with them other than a couple scripts and pull everything into one tree.

Wifi and bluetooth utilize the same chip (broadcom) much like on the rezound and some other HTC devices. But honestly, I haven't even taken a look at them at all though as my next focus is audio.

drewX2 · Mar 17, 2013

chad0989 said:
It turned out it was just the storage path not being exported that was preventing it from fully booting. I actually just fixed it earlier today and pushed something an hour or two ago. I'm working on cleaning up the init scripts / permission and moving them inline with the mako so we can ditch the prebuilt init.rc. I'm probably also going to ditch msm8960-common as we don't have much in common with them other than a couple scripts and pull everything into one tree.

Wifi and bluetooth utilize the same chip (broadcom) much like on the rezound and some other HTC devices. But honestly, I haven't even taken a look at them at all though as my next focus is audio.

I forgot to mention that about msm8960-common. I had initially written that in my post, but I was on my phone and it died on me, so had to retype it. I only use it as its inline with CM's git, but everything about it is different (which is why I was told way back by some CM/MSM8960 devs why they werent interested in working on DNA at the present time; they said it screwed up their tree)

I thought the same about wifi (I know its broadcom), here is HTC's implementation (I have not seen this for any other boards as they don't have this issue). HTC also mentions somewhere in kernel source (cant recall) that they use WCNSS as a wrapper

Code:

#if 1 /* Temp solution to turn on sleep clock, remove this after GPIO conflict is resolved */
	if (system_rev >= XC) {
		pm_config.direction = PM_GPIO_DIR_OUT;
		pm_config.output_buffer = PM_GPIO_OUT_BUF_CMOS;
		pm_config.output_value = 0;
		pm_config.pull = PM_GPIO_PULL_NO;
		pm_config.vin_sel = PM_GPIO_VIN_S4;
		pm_config.out_strength = PM_GPIO_STRENGTH_LOW;
		pm_config.function = PM_GPIO_FUNC_1;
		pm_config.inv_int_pol = 0;
		pm_config.disable_pin = 0;
		pm8xxx_gpio_config(PM8921_GPIO_PM_TO_SYS(PMGPIO(BCM4330_SLEEP_CLK_XC)), &pm_config);
		mdelay(50);
	}
#endif

And for audio, I havent had the chance to test it, but it loads for me, finds outputs, and sets volume levels on outputs. I could not get it to do the same with CM10

crpalmer · Mar 17, 2013

chad0989 said:
display_on doesn't exist in the mako FB, only lcd_on/off. I noted the display issue but haven't gotten a chance to remedy it. I just got home so hopefully I'll have some time in the next couple days.

As far as I can tell, it really needs to have the operations split between lcd_on and display_on. display_on is called much later in the power-up sequence. I just sent you a pull request that does this and successfully turns the display back on.

chad0989 · Mar 17, 2013

crpalmer said:
As far as I can tell, it really needs to have the operations split between lcd_on and display_on. display_on is called much later in the power-up sequence. I just sent you a pull request that does this and successfully turns the display back on.

Merged :good:

chad0989 · Mar 18, 2013

I have some changes I'll push later tonight. Mostly cleaning up and the start of some reorganization along with fixing adb. You will need to update to the latest platform tools for it to work properly.

Major things that need to be addressed (probably incomplete) if everyone wants to just pick something and work on that:
Audio
MTP storage
Wifi
Bluetooth

I haven't checked but I'm willing to bet these need work also:
Camera
GPS (might be pretty easy)

123421342 · Mar 18, 2013

chad0989 said:
I have some changes I'll push later tonight. Mostly cleaning up and the start of some reorganization along with fixing adb. You will need to update to the latest platform tools for it to work properly.

Major things that need to be addressed (probably incomplete) if everyone wants to just pick something and work on that:
Audio
MTP storage
Wifi
Bluetooth

I haven't checked but I'm willing to bet these need work also:
Camera
GPS (might be pretty easy)

Can you suggest a good starting point for any of these? I would love to help if I can.

t1gartist · Mar 18, 2013

if audio start with getting alsa to talk with the kernel then on to the routing and then audio flinger

chad0989 · Mar 19, 2013

Pushed the changes. In regards to adb:

You must update to the latest platform-tools. We're using adb secure (as it's default in 4.2.2) and only the latest version of adb supports it.
It will not function on first boot as its not enabled by default (since you need to accept the key), you must enable developer settings and then enable adb.
When you plug your phone in and try to adb to it for the first time it will display a key you have to accept for adb to function.

[DEV] CyanogenMod 10.1

Senior Member

Senior Member

Inactive Recognized Developer / Contributor

Senior Member

Senior Member

Senior Member

Senior Member

Inactive Recognized Developer

Senior Member

Inactive Recognized Developer

Senior Member

Senior Member

Senior Member

Senior Member

Inactive Recognized Developer

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Similar threads

Top Liked Posts