yashsingh1/xdaforums huggingface dataset:
[HTC Rezound] kkozma:
Also found an inssue with the get_prebuilts script. It doesn't download and extract the prebuilts corretly if you call it from the root of your build...

ie ". /vendor/cm/get_prebuilts" does not work, I mean it works, but it downloads the files to where ever you run it from.

if you run it from vendor/cm it works correctly. Talk about banging my head against a wall!

I think I may have a good build going now, but I have to run out to take my daughter to a birthday party and won't have time test it. :(
[HTC Rezound] dmeadows013:
Do we have a working 3.4 kernel? I can get 4.3 booting if we do
[HTC Rezound] Flyhalf205:
Don't think anyone even wants to attempt that. I tried. I don't have any kernel knowledge...

Can you not get a working 3.0 kernel to boot?

My current builds will build. But it doesn't boot. Just eventually boots back into recovery.
[HTC Rezound] dmeadows013:
It'd be easier long term with a 3.4. I can try to make one when I get home from Canada
[HTC Rezound] Snuzzo:
[MENTION=2993552]dmeadows013[/MENTION]

Just mentioning;

Already got an ion base started @ Team Blackouts github. Just fork the tree, haven't started a thread yet for it.

Sent from my ADR6425LVW using Xparent ICS Tapatalk 2
[HTC Rezound] dlumberg:
Is it getting to logcat?

Also if we get to 3.4 it should be fairly trivial to keep going up to 3.8 and 3.9 where they're starting to merge a lot of the android drivers into the mainline Linux kernel.
[HTC Rezound] kkozma:
No, no logcat from mine. :( Kinda hard to troubleshoot when you don't even get an error.
[HTC Rezound] dmeadows013:
System isn't mounting then. You'll have to edit the mounts in the ramdisk
[HTC Rezound] Flyhalf205:
Thanks. I was wondering about that. I wish Google didn't change anything with the ramdisk. I have tried changing to what other devices reflect. Mind taking a look maybe? https://github.com/Flyhalf205/device_htc_vigor

[MENTION=2658396]kkozma[/MENTION] maybe you could take a look also. You also got a gmail to chat with? to make sure we have the same progress
[HTC Rezound] Flyhalf205:
Guys. Do be careful. I just bricked.
[HTC Rezound] kkozma:
Oh no! Is it a recoverable brick?

I'm not sure how much help I'll be, but my gmail is the same as my username. I'll be online for the next 20 or so minutes to fix a nagios monitoring issue for work..
[HTC Rezound] Flyhalf205:
Afraid it's not recoverable. I could be wrong. Won't find out for another couple of hours when I get off.
[HTC Rezound] kkozma:
What did you do before you bricked so I know not to do the same thing? Will that last commit you pushed to device/htc/vigor do it?
[HTC Rezound] Flyhalf205:
Nah. Last commit is safe still. I just tried some different flags in the fstab.

Hopefully the HTC One comes out next week. This is second time I bricked this phone.
[HTC Rezound] kkozma:
Well, the mrs just told me if I brick my phone, I'm not allowed to replace it and will have to use my work phone from now on out. The thought of being stuck with this POS iPhone as a daily driver is making me doubt keeping up on this... lol

I do have a thunderbolt to fall back on, but it needs a new digitizer...
[HTC Rezound] Flyhalf205:
I'll be working on the Thunderbolt tonight. Trying to get RIL working on cm10.1.

I just don't understand why the /system isn't being mounted in cm10.2. Everything is all set up correctly it looks like.

I miss chad!
[HTC Rezound] antp121:
I used the same gapps neo posted. Worked fine.
[HTC Rezound] Antoine.WG:
The only way I'm able to toggle between radio modes is with the *#*#INFO#*#* menu. The notification drawer widgets and the normal settings menu don't seem to work. They just toggle between GSM modes. It's done that since I started using ICS. Also, the signal strength and activity don't show for LTE. It just shows an empty triangle.
[HTC Rezound] dmeadows013:
Got AOKP JB building now. First 5 people to PM get a link to test. Just be sure you know what you doing cause I'm not responsible if you brick... I don't think you will, but still.
[HTC Rezound] dmeadows013:
Got 5. Testers will be sent a link when ready. Thanks
[HTC Rezound] dragonstalker:
D,

I'm going to post the link to my dropbox where i have the Nexus4dump that i've been working with. So far today i've sent my phone into a boot loop 3 times. But atleast its booting now which means i'm making progress. JB 4.2 here we come.

OK here's the JB 4.2 DUMP in raw format. https://www.dropbox.com/sh/ab1ezw9xyu3f8zt/hxLPfASDrK/Nexus4_System_Dump.zip

AS always i'm not responsible for coffee spillage, bricked phone, broken condemn or sunamis. Use at your own risk.
[HTC Rezound] dmeadows013:
Links sent out to 5 people
[HTC Rezound] The-Captain:
Thread Cleaned, this is a development ONLY thread. All post non-development related will be deleted. Please post those in the AOSP general discussion thread.

Developers, please report or PM me should you see a post that is non-development related. Thanks!

- The-Captain
[HTC Rezound] chad0989:
Okay so here's an update:

ION really smooths things out and fixes all the video tearing issues etc.... BUT unfortunately camera HAL nor libs utilize ION. So the camera/camcorder can't function using ION without the HAL and libs being updated.

Since we can't rely on HTC to ever update our libs, and the msm8960 libs use v4l2 and are not compatible. I'm working on a workaround.

Right now the gralloc library, which is required for the camera, doesn't handle multiple allocators, only one or the other. So when I build with TARGET_USES_ION, gralloc is built entirely without pmem support. I'm currently trying to modify the library to be built with pmem support and additionally modify the ion controller portion to detect that the camera libs are trying to allocate using pmem and that it should use the pmem controller instead.

---------- Post added at 06:54 PM ---------- Previous post was at 06:02 PM ----------

I can report semi-success. The camera comes up but the preview has some artifacting. I may have accidentally allocated some overlapping memory regions though, hopefully.
[HTC Rezound] chad0989:
Got rid of the artifacting. It was a memory overlap as I suspected. Still photos are fine camcorder isn't working yet.
[HTC Rezound] MaulingDeOso:
The CyanogenMod Samsung devices don't enable TARGET_USES_ION, but they can probably also allocate a big chunk of PMEM for applications since they have RAM to spare. You could try looking at the lge-iproj device for the LG Nitro, which is msm8660 and runs full ION, though I suspect LG had it running ION from the get-go and the camera blobs use it already.
[HTC Rezound] chad0989:
It's defined in samsung_msm8660_common.

Right now I can get either camera to function and video playback, or camera and camcorder but no video playback.

The other option is to try to use the samsung or LG HAL and libs. Not sure how well that will work out though.
[HTC Rezound] MaulingDeOso:
Didn't see that. :)

Under what conditions are each running? Could it potentially be a conflict in vidc?

I'm inclined to believe that the blobs are camera module-specific. If they were for just the msm_camera layer or interchangeable, they probably wouldn't be closed source.
[HTC Rezound] chad0989:
It is a vidc issue now. The camera allocates pmem from adsp/smipool. Since those pools no longer are used in ION, I can distinguish a request for them and modify gralloc to use the correct allocator. However, vidc (more specifically decode) allocates from the system pool. There is no way to distinguish a between a request to use ION or PMEM when allocating from the system pool with gralloc. It depends only on what the primary allocator is.

Now if vidc was the only thing that wanted to allocate from the system pool, then we would have no issues just telling all system pool request to be allocated as PMEM. Unfortunately, it seems that the EGL libs also want to allocate from the system pool, at least it seems that they will allocate from either the system pool, or the ION_SMI pool (which I can distinguish). So if I can force the EGL libs to allocate from the ION_SMI pool then I should be able to force everything else to allocate PMEM from the PMEM system pool. I haven't gotten to try that yet.

The other option is to modify the vidc kernel driver to use PMEM from encoding and ION for decoding (right now its only one or the other). This might be the better option, but likely a little more work.

Third option is to write some sort of wrapper that allocates all pmem requests through ION. The only issue there is that I'm not so sure how I can make sure that the memory allocated with ION through a wrapped pmem allocation request can be directly accessed through an ION request.

I agree, which is why I haven't really been desperate enough to try it yet.
[HTC Rezound] Vashypooh:
In CM9 and likely CM10 the device is unable to be encrypted. Posting here since development has moved here.

"Orig filesystem overlaps crypto footer region. Cannot encrypt in place."

I attempted to fix it with a few different tricks but had no real luck.
[HTC Rezound] chad0989:
Going to try for option #2 at some point soon when I get the time. Hopefully it works.
[HTC Rezound] chad0989:
Okay. I have camera, video camera, panorama, and playback working with a sort of dirty hack. I just have to clean up the kernel, rearrange memory regions, and try to lose as minimal memory as possible with this ridiculous config. Hopefully HTC will release JB for an msm8660 device (or even a leak would help) at some point in the near future that we can pull the camera libs and HAL from.
[HTC Rezound] SynisterWolf:
How about the HTC pyramid?

Sent from my iPhone...
[HTC Rezound] MaulingDeOso:
Congratulations. This using the vidc kernel module hack you mentioned?

Different board, different camera module. The reason we can share at least some code is because it's an msm8660, and HTC devices tend to be engineered the same way, but most of the peripheral hardware isn't the same, so it probably wouldn't work.

*edit* I could be wrong. I looked it up, and it has identical specs, so it might actually be the same camera.
[HTC Rezound] killahrey:
All of htc's 8mp cameras are the same up until the hox.
[HTC Rezound] SynisterWolf:
:D

:fingers-crossed: that this will work. if anyone can do it, it would be you and chad. thank you for all your work you do for the rez and android community.
[HTC Rezound] kkozma:
Eh, I think you can get it figured if your phone is recoverable. If it's not, what happens next? Are you done with the rezound then? That would REALLY suck. :(

Anyhoo, would the target CPU and arch variant's matter at all for this? I took a look at the skyrocket stuff and they have the arch variant set to cortex a8 and cpu variant to generic. You have cortex-a9 for both of them for us. I went ahead and changed them for the build I have running now, but I'm not sure if I want to flash it.

Again, not sure if it matters, but when looking at it that's all that really stands out to me.
[HTC Rezound] Flyhalf205:
I actually have 2 rezounds. I got a 2nd a few months ago because of my BT/WiFi chip went bad. I ran home and grabbed my second one for my next build which actually has the variant set to generic. So we will see if that is the problem. Build will be done in 20min.

Team-Hydra has theirs set to generic also. I am taking the cortex completely out of the msm8660 repo and putting in generic. Fingers crossed!

EDIT: Once we do get this booted. I will roll up all the commits into one so It will be cleaner on github.

My build keeps failing. Probably going to nuke everything and start from scratch (cm-10.1 branch)
[HTC Rezound] TheBr0ken:
Maybe S-on till mounting is figured out?

My build for the Galaxy s3 is failing and that's a supported device. Might have to wait till cm gets some more things fixed up
[HTC Rezound] kkozma:
Mine built, but I'm not going to flash it I don't think...

S-ON is probably a safe idea. If I'm running the latest 2.28 hboot and radios, do I need to RUU back to the ota to get back to S-ON?
[HTC Rezound] Flyhalf205:
Any chance you'll upload your build and pm the link to me? I'll test.

Changing to generic had no change either. I'll snoop around and see what else I can find.
[HTC Rezound] mjones73:
Far as I know, you can just set the flag, wouldn't hurt to revert back in case you need to RUU your phone s-on though.
[HTC Rezound] wlmeng11:
Make sure you have a signed HBOOT before writing the flag for S-ON, though.
[HTC Rezound] dmeadows013:
Looked at the tree. I'm assuming you messed up on a fstab name change somewhere but I can't tell because I don't have my desktop. Seems like a simple fix though
[HTC Rezound] Flyhalf205:
Made a more simple commit to the device repo. No names have been changed so still not sure why system can't mount. I haven't heard of any HTC msm8660 devices booting yet. Team-Hydra was working on theirs this morning.

Just flashed your build [MENTION=2658396]kkozma[/MENTION] and still no boot.
[HTC Rezound] kkozma:
Didn't figure it would. Oh well!
[HTC Rezound] Neo:
pbeeler, aka SaberMod suggested we check vendor binaries for the no boot issue. Additionally, he informed me that cm is having issues with sdcard mount since they changed mount and that it could be contributing to the problem.
[HTC Rezound] Flyhalf205:
Well if it was a lib(aka vendor binary) we would be able to at least mount system you would think. My last commit https://github.com/Flyhalf205/device_htc_vigor/commit/b9143971ff0e6cb1fd4176569b620592d1b943e4 is identical to what the cm team is doing to the official devices. Not sure at all. I haven't tested that last commit yet btw.

The HTC DNA was so easy getting it to boot. Nothing added. Basically same thing as commit above.
[HTC Rezound] antp121:
If you guys are in dire need of a guinea pig, my rezound's begging for some attention.
[HTC Rezound] GrayBoltWolf:
If I can get my upgrade Thursday then my rezound is up for testing also. I am s-on so no fear of a brick.
[HTC Rezound] dmeadows013:
I'll update the OP and work on booting when I get home Sunday :)
[HTC Rezound] Flyhalf205:
So it's a known issue for htc msm8660 to have problems getting it to boot. Someone said something that we require isn't supported. Go figure.
[HTC Rezound] dmeadows013:
Updated OP. Please let me know if I missed anything or messed up on info about the trees. Was rushing through it and didn't check to see if the trees were up to date. They should be though.
[HTC Rezound] kkozma:
The Galaxy SII guys have gotten theirs to boot. How'd they pull that off?
[HTC Rezound] dmeadows013:
Gonna check that out :)
[HTC Rezound] kkozma:
The order of the mounts in their fstab is different than ours. They have system first. I know that order is important, but surely it can't be *THAT* important...
[HTC Rezound] Flyhalf205:
I really don't think that it is the mounts. This is the only thing we did to the DNA to get it to work. https://github.com/CM10DNA/android_device_htc_dlx/commit/e3084bc6ae75783faf333a0d7ac0b4454f66df76 plus a few kernel commits to fix compile
[HTC Rezound] kkozma:
For kicks and giggles, is there any risk of brick status if I just change the order of the mounts?
[HTC Rezound] Flyhalf205:
I'm pretty positive you won't brick.
[HTC Rezound] dmeadows013:
Just make sure you're S-On :P
[HTC Rezound] kkozma:
My laziness doesn't want to S-on. I really don't feel like screwing around with ruu's and all that nonsense.

There's too many if's around this, so I'm just going to let it be for now.
[HTC Rezound] dlumberg:
I have 2 Rez's with cracked screens and I'm gonna asurion one this week, I'd be happy to brick one if someone wants to pm me a link before I motivate enough to dust off my cm tree and build it.

---------- Post added at 10:55 PM ---------- Previous post was at 10:18 PM ----------

alright... dusted off... has anyone played with the init.rc?

I see a bunch of mkdir and exports for the file systems on the dlx tree that aren't in vigor...

https://github.com/CM10DNA/android_device_htc_dlx/blob/cm-10.2/recovery/init.rc

https://github.com/Flyhalf205/device_htc_vigor/blob/cm-10.2/ramdisk/init.vigor.rc

checkout the init blocks
[HTC Rezound] Flyhalf205:
You know you linked to the "recovery" init.rc :p

Sent Chad a PM. He said that he thinks "it's something to do with an outdated display HAL and libs If that seems to be a possibility, try pulling the HAL that was being used from CM10.1 and merge that in as display-legacy and that might get you up and running until someone can hack together support for the newer code."
[HTC Rezound] dlumberg:
herp derp :o
[HTC Rezound] Snuzzo:
[MENTION=2993552]dmeadows013[/MENTION]

For CM9

https://github.com/VigorCM9

For AOKP (Both ICS & JB)

https://github.com/VigorAOKP
[HTC Rezound] kkozma:
Anyone else having build problems with 10.2? Mine stops with a whole bunch of errors dealing with HTCVigorQualcommRIL.java

example:

frameworks/opt/telephony/../../../device/htc/vigor/ril/HTCVigorQualcommRIL.java:
31: cannot find symbol
symbol : class IccCardApplicationStatus
location: package com.android.internal.telephony
import com.android.internal.telephony.IccCardApplicationStatus;
[HTC Rezound] brenuga:
This may be fixable by just merging in CM's HTC Qualcomm RIL, which flyhalf205 said is compatible with vigor again.

There have been several recent merged commits in June dealing with HTC Qualcomm RIL, which is part of frameworks/opt/telephony

https://github.com/CyanogenMod/android_frameworks_opt_telephony

This may also be relevant, based on your error message.

HTCQualcommRIL: optionally ignore IccCard states greater than 2

The htc fireball (Verizon) throws CARDSTATE_NOT_INITIALIZED corresponding

to card state 3. Include an option to ignore card states greater than 2

with an oldril prop.

http://review.cyanogenmod.org/#/c/44330/
[HTC Rezound] Flyhalf205:
I just took it out for now. Hopefully the HTCCDMAQualcommRIL gets merged soon and we can use that from CM.

https://github.com/Flyhalf205/device_htc_vigor/commit/2884c355fc0e650a0ec832dfe562efc38b112d75
[HTC Rezound] kkozma:
Ok, surely I must be doing something wrong. I know people are building successfully, but mine hasn't been able to get passed this for 3 days now.
[HTC Rezound] Flyhalf205:
Same here man. I may hold off on trying to boot cm10.2 until more thing are settled with it.
[HTC Rezound] TheBr0ken:
Just a little insight on to some of the issues I was running into with building cm10.2 for the Galaxy s3. Fresh sync and brunch ended with a no boot issue. Messed with it for days until I went away from the stock cm kernel. Now it boots. If anybody is installing with twrp, once you install, go into advanced options and 'copy log to sd'. I first thought it was a mounting issue, but looking at the log, that wasn't the case.
[HTC Rezound] kkozma:
Well, it looks like the LPA Player thing is being worked on... http://review.cyanogenmod.org/#/c/46451/

I may try flashing twrp just to see what that log comes up with. I assume it's the kmsg log?
[HTC Rezound] Flyhalf205:
I need that link thanks. Btw does dspmanager work on current roms? I don't seem to noticed anything
[HTC Rezound] kkozma:
Well, when I built my hybrid cm10.1 rom with the 4.3 BT stack, DSP Manager FC'd every time audio played...

In order for that to work, I replaced the 10.1 repos with the following 10.2 repos:

android_external_bluetooth_bluedroid

android_hardware_libhardware

---------- Post added at 10:27 AM ---------- Previous post was at 10:24 AM ----------

I also found this today:

https://github.com/JellybeanDS/andr...mmit/d19453a01be65d65c9d2dc1987828cb5ab1abfd0

Different method for getting around the refcount issue in audiopolicymanager.
[HTC Rezound] Flyhalf205:
Why you building with 4.3 bt stack. It works just fine in CM10-1?

Find lpa audio and change the value in the build.prop
[HTC Rezound] kkozma:
I wanted to see if I could get AVRCP to work since that's all I really care about in 4.3 to be honest. I use BT audio DAILY.
[HTC Rezound] kkozma:
So I enabled SELinux in the kernel since I see that all the devices that are booting have it enabled and we don't..

Good news is that the filesystems ARE mounting.

Bad news is I still can't get it to boot.

Anyone got any ideas on this one?

[ 23.806610] init: critical process 'servicemanager' exited 4 times in 4 minutes; rebooting into recovery mode

I'll attach my last_kmsg if anyone wants to look it over and see if there's anything else in there we should be looking at.
[HTC Rezound] dlumberg:
I found this: https://code.google.com/p/rowboat/issues/detail?id=143

This error is mainly due to graphic files which are initiated.
Try to disable servicemanager in init.rc and if you still get same error then disable media(graphics) related things like camera. give a try like that

Other references were to making sure the kernel was compiled with "binder" support. http://android-code.blogspot.com/2011/09/android-porting-re-init-critical_15.html

The author said that enable the setting of kernel(using 'make
menuconfig')
->device driver
->staging drivers
->android
->android binder ipc driver

Has anyone run a diff on a typical Rez .config and the s3?

---------- Post added at 12:24 AM ---------- Previous post was at 12:15 AM ----------

I haven't looked at a Rez kernel dump in too much depth before, are these normal?

[ 4.135284] type=1400 audit(1375406775.150:3): avc: denied { search } for pid=161 comm="ueventd" name="/" dev=mmcblk0p29 ino=2 scontext=u:r:ueventd:s0 tcontext=u:object_r:unlabeled:s0 tclass=dir
[ 4.148590] type=1400 audit(1375406775.160:4): avc: denied { search } for pid=161 comm="ueventd" name="/" dev=mmcblk0p21 ino=1 scontext=u:r:ueventd:s0 tcontext=u:object_r:sdcard_external:s0 tclass=dir
[ 4.148803] type=1400 audit(1375406775.160:5): avc: denied { read } for pid=161 comm="ueventd" name="q6.mdt" dev=mmcblk0p21 ino=4 scontext=u:r:ueventd:s0 tcontext=u:object_r:sdcard_external:s0 tclass=file
[ 4.149017] type=1400 audit(1375406775.160:6): avc: denied { open } for pid=161 comm="ueventd" name="q6.mdt" dev=mmcblk0p21 ino=4 scontext=u:r:ueventd:s0 tcontext=u:object_r:sdcard_external:s0 tclass=file
[ 4.149291] type=1400 audit(1375406775.170:7): avc: denied { getattr } for pid=161 comm="ueventd" path="/vendor/firmware/adsp/q6.mdt" dev=mmcblk0p21 ino=4 scontext=u:r:ueventd:s0 tcontext=u:object_r:sdcard_external:s0 tclass=file
...
...
...
[ 4.471740] type=1400 audit(1375406775.491:8): avc: denied { open } for pid=179 comm="adbd" name="__properties__" dev=tmpfs ino=4434 scontext=u:r:adbd:s0 tcontext=u:object_r:device:s0 tclass=file
[ 4.471954] type=1400 audit(1375406775.491:9): avc: denied { getattr } for pid=179 comm="adbd" path="/dev/__properties__" dev=tmpfs ino=4434 scontext=u:r:adbd:s0 tcontext=u:object_r:device:s0 tclass=file
[ 4.472930] adb_open
[HTC Rezound] Flyhalf205:
They /system partition still isn't being mounted. No idea why.
[HTC Rezound] kkozma:
Are you 100% sure on that? servicemanager is in system/bin/. So if we're seeing errors for it, you could logically assume that it tried to run it.
[HTC Rezound] hell_lock:
how did you fix it?
[HTC Rezound] kkozma:
I cherry picked this.

http://review.cyanogenmod.org/#/c/46451/
[HTC Rezound] hell_lock:
I used the cherry pick in the stagefright folder but I am getting this while compiling :(

frameworks/av/media/libstagefright/AwesomePlayer.cpp:1016: error: undefined reference to 'android::LPAPlayer::mObjectsAlive'
frameworks/av/media/libstagefright/AwesomePlayer.cpp:1088: error: undefined reference to 'android::LPAPlayer::LPAPlayer(android::sp<android::MediaPlayerBase::AudioSink> const&, bool&, android::AwesomePlayer*)'
frameworks/av/media/libstagefright/AwesomePlayer.cpp:1689: error: undefined reference to 'android::LPAPlayer::mObjectsAlive'
[HTC Rezound] kkozma:
Run the cherry pick from frameworks/av
[HTC Rezound] Jonman409:
There's also a kernel patch for binder with regards to selinux permissions. Its in Google's branch but not ours. I merged their branch minus ion and there doesn't seem to introduce any issues for 10.1.

---------- Post added at 11:43 AM ---------- Previous post was at 11:39 AM ----------

I've almost resolved all the conflicts for 3.4 with branches codeaurora/Google/stable. I'll post the link then start working on our board files.