Database Develop

[Solved] ChameleonOS-janice compiled, but wifi issue!

Hi guys,
i'm a new member and i've read forum rules, this is my first post, i hope i'm posting to the right section. I'm trying to build ChameleonOS from source for our device, after 7 hours everytime i get two errors saying "vibrator.c:76: error: undefined reference to "sendit"" and "vibrator.c:81: error: undefined reference to "sendit"", then the build stops with Error 1. I'm using Lubuntu 13.04 with ChaOS repo and Team Canjica's repos: device, vendor, kernel, libhardware and libhardware_legacy, i followed this guide: http://forum.xda-developers.com/showthread.php?t=2351504. Seems that these errors are related to libhardware_legacy's vibrator.c, i attach the image of the error in this post. Thanks
P.S. Sorry for my bad english, i'm Italian
EDIT: For error I made post #5 instead of edit this, sorry! :angel:

No one can help me? Also only to ignore the errors and continue the build, if there's a way, instead of automatically stop it. In this case I can extract libhardware_legacy.so from CM10.1's flashable zip and put it in builded ChaOS's flashable zip.

Add ifdef to the original vibrator c file
Sent from my GT-I9070 using Tapatalk 4

Shaaan said:
Add ifdef to the original vibrator c file
Sent from my GT-I9070 using Tapatalk 4
Click to expand...
Click to collapse
In which part of file I have to add it?

[HELP] ChameleonOS-janice compiled, but wifi issue!
Now I have compiled ChameleonOS for janice, everything works fine but low incall volume bug, same as CM, and wifi doesn't turn on with compiled boot.img... I've tested it with CM10.1 build 20130923's boot.img and wifi works, but in this way loses the customizations and possibility to use integrated theme manager, which are the strong point of this rom. When this problem will be resolved I share the rom in devs section. Any help will be appreciated

Tesla-MADAL93 said:
Now I have compiled ChameleonOS for janice, everything works fine but low incall volume bug, same as CM, and wifi doesn't turn on with compiled boot.img... I've tested it with CM10.1 build 20130923's boot.img and wifi works, but in this way loses the customizations and possibility to use integrated theme manager, which are the strong point of this rom. When this problem will be resolved I share the rom in devs section. Any help will be appreciated
Click to expand...
Click to collapse
compile again with our updated sources
Sent from my GT-S5367 using xda app-developers app

frapeti said:
compile again with our updated sources
Sent from my GT-S5367 using xda app-developers app
Click to expand...
Click to collapse
Okay, sources updated, now I'm rebuilding
EDIT: Recompiled, now wifi works

[celoxhd][SGH-I757M][CWM Advanced Edition] PhilZ Touch

Main thread + features + install instructions + dev support
http://forum.xda-developers.com/showthread.php?t=2201860
PhilZ Touch is a CWM Advanced Edition that adds all the features you could ever miss in CWM
It is a well proven recovery for many phones
It also adds a full touch interface a completely configurable GUI
Please give your feedback, what works, and any bug you could encounter
Read the features, and check if you are missing something
Also, do not forget to read about the powerful aroma file manager integration and double tap shortcut
Download links
Last version can be found here:
celoxhd
http://goo.im/devs/philz_touch/CWM_Advanced_Edition
Original dev supporter:
http://www.androidfilehost.com/?w=files&flid=12461
Click to expand...
Click to collapse
Huge thanks and credits to @titanic_fanatic
He ported the sources and provided all needed stuff to build it

Excellent, many thanks for all the work you put into this for us. We very much appreciate it
On the topic of bugs, I only have two (but I really don't mind at all). The screenshot works except for the resulting image is wavy coloured lines and no vibration regardless of the setting.
We've never had either, so I'm not missing them at all, but wanted to let you know.
Take care Phil
Sent from my SGH-I757M using XDA Premium 4 mobile app

titanic_fanatic said:
Excellent, many thanks for all the work you put into this for us. We very much appreciate it
On the topic of bugs, I only have two (but I really don't mind at all). The screenshot works except for the resulting image is wavy coloured lines and no vibration regardless of the setting.
We've never had either, so I'm not missing them at all, but wanted to let you know.
Take care Phil
Sent from my SGH-I757M using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Added you to credits on the device page in main thread and here in OP :good:
screen shots: forget it, I should disable it once for all on new devices. Sadly, we have no working thing for most new devices. Only some Sammy and the mako did work
vibration: can you provide the path for vibrator?, it should be in kernel drivers I guess. Currently I use:
Code:
/sys/class/timed_output/vibrator/enable
We echo some msec value there and it Bzzzzz for that msec

Phil3759 said:
Added you to credits on the device page in main thread and here in OP :good:
screen shots: forget it, I should disable it once for all on new devices. Sadly, we have no working thing for most new devices. Only some Sammy and the mako did work
vibration: can you provide the path for vibrator?, it should be in kernel drivers I guess. Currently I use:
Code:
/sys/class/timed_output/vibrator/enable
We echo some msec value there and it Bzzzzz for that msec
Click to expand...
Click to collapse
That's the correct path Maybe the driver isn't loading properly... I'll see if I can get a dmesg Log when booting recovery to see if the driver actually loads
Sent from my SGH-I757M using XDA Premium 4 mobile app

Vibrator Fixed
Hey @Phil3759, I did a whole lot of investigating tonight and have figured out and fixed the vibration issue. I discovered that it was trying to load the module from /system/lib/modules/vibrator.ko. This is my roms ko file and is currently for cm10.2. The kerenel I setup for this recovery is our cm11 kernel and uses a different module (compiled against that kernel). It was trying to load the cm10.2 module from my rom into the cm11 kernel which obviously doesn't work, so I split the recovery.img added the correct module at /tmp/system/lib/modules added the necessary lines to init.recovery.qcom.rc and repackaged the kernel and new ramdisk.
I have flashed this and tested it. it works like a charm now Can you replace the version in your repo with this new one?

titanic_fanatic said:
Hey @Phil3759, I did a whole lot of investigating tonight and have figured out and fixed the vibration issue. I discovered that it was trying to load the module from /system/lib/modules/vibrator.ko. This is my roms ko file and is currently for cm10.2. The kerenel I setup for this recovery is our cm11 kernel and uses a different module (compiled against that kernel). It was trying to load the cm10.2 module from my rom into the cm11 kernel which obviously doesn't work, so I split the recovery.img added the correct module at /tmp/system/lib/modules added the necessary lines to init.recovery.qcom.rc and repackaged the kernel and new ramdisk.
I have flashed this and tested it. it works like a charm now Can you replace the version in your repo with this new one?
Click to expand...
Click to collapse
If you update your device tree, it would be even better. That way, my next updates won't be affected again

Phil3759 said:
If you update your device tree, it would be even better. That way, my next updates won't be affected again
Click to expand...
Click to collapse
I just finished updating my device tree with the necessary fixes for the vibrator to work in recovery
https://github.com/titanic-fanatic/android_device_samsung_celoxhd/commit/6f005f4045551e48adfa0ac228641bf8d6a12128
Also, not that I care, but Amarullz was able to get screenshots working in the latest AromaInstaller (Flamboyan I think). If your interested, maybe ask him what he did to get it to work. He could probably point you to the commits
Take Care

titanic_fanatic said:
I just finished updating my device tree with the necessary fixes for the vibrator to work in recovery
https://github.com/titanic-fanatic/...mmit/6f005f4045551e48adfa0ac228641bf8d6a12128
Also, not that I care, but Amarullz was able to get screenshots working in the latest AromaInstaller (Flamboyan I think). If your interested, maybe ask him what he did to get it to work. He could probably point you to the commits
Take Care
Click to expand...
Click to collapse
Looking at it quickly: why that first extra / at end of copy files?
Also, won't be cleaner to use standard path like /lib/modules?
/tmp can be wiped and modified by installers and recovery

Phil3759 said:
Looking at it quickly: why that first extra / at end of copy files?
Also, won't be cleaner to use standard path like /lib/modules?
/tmp can be wiped and modified by installers and recovery
Click to expand...
Click to collapse
The first / is because it's part of a set of chained product copy files directives:
# Ramdisk
PRODUCT_COPY_FILES += \
device/samsung/celoxhd/ramdisk/init.qcom.usb.rc:root/init.qcom.usb.rc \
# BT firmware
PRODUCT_COPY_FILES += \
device/samsung/celoxhd/firmware/bcm4330B1.hcd:system/etc/firmware/bcm4330B1.hcd \
# Needed for vibrator to work in recovery
PRODUCT_COPY_FILES += \
device/samsung/celoxhd/recovery/root/lib/modules/vibrator.ko:recovery/root/lib/modules/vibrator.ko \
device/samsung/celoxhd/recovery/root/init.recovery.qcom.rc:recovery/root/init.recovery.qcom.rc
Click to expand...
Click to collapse
I did this only to adhere to the existing pattern in my device.mk file, the one appended to the first PRODUCT_COPY_FILES was already there from when I forked the project and took that as being a set of chained commands. If this is wrong, I will change it
I definitely see your point on the /tmp dir. I here the commit that fixes that
https://github.com/titanic-fanatic/android_device_samsung_celoxhd/commit/61da6be2d60a03797ddc31c0187cc5c62bb3a97a

titanic_fanatic said:
The first / is because it's part of a set of chained product copy files directives:
I did this only to adhere to the existing pattern in my device.mk file, the one appended to the first PRODUCT_COPY_FILES was already there from when I forked the project and took that as being a set of chained commands. If this is wrong, I will change it
I definitely see your point on the /tmp dir. I here the commit that fixes that
https://github.com/titanic-fanatic/android_device_samsung_celoxhd/commit/61da6be2d60a03797ddc31c0187cc5c62bb3a97a
Click to expand...
Click to collapse
I uploaded 6.01.2 with your fixed vibrator :good:
PRODUCT_COPY_FILES:
Maybe I am wrong, but usually, in make files, only the last element has no trailing /
Code:
# Ramdisk
PRODUCT_COPY_FILES += \
device/samsung/celoxhd/ramdisk/init.qcom.usb.rc:root/init.qcom.usb.rc
xxx-yyy \
zzz-pppp\
last_one
# BT firmware
PRODUCT_COPY_FILES += \
device/samsung/celoxhd/firmware/bcm4330B1.hcd:system/etc/firmware/bcm4330B1.hcd
# Needed for vibrator to work in recovery
PRODUCT_COPY_FILES += \
device/samsung/celoxhd/recovery/root/tmp/system/lib/modules/vibrator.ko:recovery/root/tmp/system/lib/modules/vibrator.ko \
device/samsung/celoxhd/recovery/root/init.recovery.qcom.rc:recovery/root/init.recovery.qcom.rc
Also, just for info, my full gui builds need these, often in cm.mk:
Code:
TARGET_SCREEN_HEIGHT := 1280
TARGET_SCREEN_WIDTH := 720

Phil3759 said:
I uploaded 6.01.2 with your fixed vibrator :good:
PRODUCT_COPY_FILES:
Maybe I am wrong, but usually, in make files, only the last element has no trailing /
Code:
# Ramdisk
PRODUCT_COPY_FILES += \
device/samsung/celoxhd/ramdisk/init.qcom.usb.rc:root/init.qcom.usb.rc
xxx-yyy \
zzz-pppp\
last_one
# BT firmware
PRODUCT_COPY_FILES += \
device/samsung/celoxhd/firmware/bcm4330B1.hcd:system/etc/firmware/bcm4330B1.hcd
# Needed for vibrator to work in recovery
PRODUCT_COPY_FILES += \
device/samsung/celoxhd/recovery/root/tmp/system/lib/modules/vibrator.ko:recovery/root/tmp/system/lib/modules/vibrator.ko \
device/samsung/celoxhd/recovery/root/init.recovery.qcom.rc:recovery/root/init.recovery.qcom.rc
Also, just for info, my full gui builds need these, often in cm.mk:
Code:
TARGET_SCREEN_HEIGHT := 1280
TARGET_SCREEN_WIDTH := 720
Click to expand...
Click to collapse
It seems that the extra \ was introduced in our JB branch and has never been fixed. Various examples in googles repo confirm that you are correct. I have removed the extra \ and added the properties you mentioned above to the cm.mk file. Here is the relevant commit:
https://github.com/titanic-fanatic/android_device_samsung_celoxhd/commit/6ce5f482d63cd70cf64a3d1428ad2428844e23cb

Hey @Phil3759, I just downloaded and flashed the latest version. Thanks kindly for the update
I see that I made a boo boo and forgot to update the path to the vibrator in the init.recovery.qcom.rc file and so the vibrator isn't loading. I've fixed that with the following commit:
https://github.com/titanic-fanatic/android_device_samsung_celoxhd/commit/b87b3267d75a0de1bb94f68850ae6986ac4dde92
One other thing, for some reason the background is tiled 4 times as if my devices dimensions were not set correctly. I do have that set in my cm.mk file. Here was the commit for that:
https://github.com/titanic-fanatic/android_device_samsung_celoxhd/commit/6ce5f482d63cd70cf64a3d1428ad2428844e23cb
Is there somewhere else I'm supposed to specify the device screen dimensions?
Thanks again for the new version and I apologize for missing that path in the init.recovery.qcom.rc.

titanic_fanatic said:
Hey @Phil3759, I just downloaded and flashed the latest version. Thanks kindly for the update
I see that I made a boo boo and forgot to update the path to the vibrator in the init.recovery.qcom.rc file and so the vibrator isn't loading. I've fixed that with the following commit:
https://github.com/titanic-fanatic/android_device_samsung_celoxhd/commit/b87b3267d75a0de1bb94f68850ae6986ac4dde92
One other thing, for some reason the background is tiled 4 times as if my devices dimensions were not set correctly. I do have that set in my cm.mk file. Here was the commit for that:
https://github.com/titanic-fanatic/android_device_samsung_celoxhd/commit/6ce5f482d63cd70cf64a3d1428ad2428844e23cb
Is there somewhere else I'm supposed to specify the device screen dimensions?
Thanks again for the new version and I apologize for missing that path in the init.recovery.qcom.rc.
Click to expand...
Click to collapse
About background image:
I think this is the cause:
https://github.com/CyanogenMod/android_device_samsung_celox-common/blob/cm-11.0/celox-common.mk#L45
called here:
https://github.com/titanic-fanatic/...xhd/blob/philz-recovery-cm-11.0/device.mk#L37
Your cm.mk settings are overridden
Maybe just move device resolution from cm.mk to device.mk after Line 37
About the vibrator: do you need exfat through kernel modules? If yes, let me know. It is much faster than fuse. For that, you'll need to compile the kernel with samsung exfat sources. I can guide you for that
Else, link me to what exactly is needed in your kernel for the vibrator to work. If it is just a change in defconfig, I can add it and compile along exfat

Phil3759 said:
About background image:
I think this is the cause:
https://github.com/CyanogenMod/android_device_samsung_celox-common/blob/cm-11.0/celox-common.mk#L45
called here:
https://github.com/titanic-fanatic/...xhd/blob/philz-recovery-cm-11.0/device.mk#L37
Your cm.mk settings are overridden
Maybe just move device resolution from cm.mk to device.mk after Line 37
About the vibrator: do you need exfat through kernel modules? If yes, let me know. It is much faster than fuse. For that, you'll need to compile the kernel with samsung exfat sources. I can guide you for that
Else, link me to what exactly is needed in your kernel for the vibrator to work. If it is just a change in defconfig, I can add it and compile along exfat
Click to expand...
Click to collapse
I see it, and now as you've recommended I reset the values after calling celox-common.mk. The commit is here:
https://github.com/titanic-fanatic/android_device_samsung_celoxhd/commit/cd44b44b7cbb0ddb3b649ac5c4f8d5d1f51d7998
As for exfat, I will be adding this when I have some time to rebuild this kernel. We can worry about exfat for the next time you do device updates and hopefully I'll have it ready by that time. I have your main thread in my subscriptions, so I'll know when your ready to release a new version and will remind you to sync with my repo at that time
Thanks for catching that issue with screen size

titanic_fanatic said:
I see it, and now as you've recommended I reset the values after calling celox-common.mk. The commit is here:
https://github.com/titanic-fanatic/android_device_samsung_celoxhd/commit/cd44b44b7cbb0ddb3b649ac5c4f8d5d1f51d7998
As for exfat, I will be adding this when I have some time to rebuild this kernel. We can worry about exfat for the next time you do device updates and hopefully I'll have it ready by that time. I have your main thread in my subscriptions, so I'll know when your ready to release a new version and will remind you to sync with my repo at that time
Thanks for catching that issue with screen size
Click to expand...
Click to collapse
np
Let me know if you need info to add exfat
I will update with the current fixes asap

Phil3759 said:
np
Let me know if you need info to add exfat
I will update with the current fixes asap
Click to expand...
Click to collapse
Can I get a link to these fixes please when you have it ready

titanic_fanatic said:
Can I get a link to these fixes please when you have it ready
Click to expand...
Click to collapse
https://github.com/PhilZ-cwm6/GE-Ed...mmit/a8963ca853cfd88466716f8a25434d5c469a2bb9
It is just adding the exfat folder in drivers and edit the makefile with -y to have it built as static. No need to separate modules

Phil3759 said:
https://github.com/PhilZ-cwm6/GE-Ed...mmit/a8963ca853cfd88466716f8a25434d5c469a2bb9
It is just adding the exfat folder in drivers and edit the makefile with -y to have it built as static. No need to separate modules
Click to expand...
Click to collapse
Excellent. I'll add it soon, it should be a pretty quick process.
Quick question though since we are currently having some issues with random reboots in all of my latest builds of cm-11.0. My kernel was updated at some point, and that's when my builds started having random reboots. They are actually not random, but seem rather consistent.
My question is this, do you think this will affect operation in recovery? I believe the reboots are due to kernel panic from a graphics related issue but am not sure if that will only affect the rom and not recovery.
If this might affect recovery, I think I'll build it as a module so I can just add it to my device tree instead of having to update the entire zImage. This will at least give us the old working kernel with the exfat module included.
What do you think?
Sent from my SGH-I757M using XDA Premium 4 mobile app

titanic_fanatic said:
Excellent. I'll add it soon, it should be a pretty quick process.
Quick question though since we are currently having some issues with random reboots in all of my latest builds of cm-11.0. My kernel was updated at some point, and that's when my builds started having random reboots. They are actually not random, but seem rather consistent.
My question is this, do you think this will affect operation in recovery? I believe the reboots are due to kernel panic from a graphics related issue but am not sure if that will only affect the rom and not recovery.
If this might affect recovery, I think I'll build it as a module so I can just add it to my device tree instead of having to update the entire zImage. This will at least give us the old working kernel with the exfat module included.
What do you think?
Sent from my SGH-I757M using XDA Premium 4 mobile app
Click to expand...
Click to collapse
you'll end up with magic number mismatch errors
There are some hacks to force loading on mismatch, but, in my previous experience, they failed on many devices
the drivers must be compiled along the zImage
Now, why don't we drop to celox-common kernel which seems to work fine on skyrocket and other phones?

Phil3759 said:
you'll end up with magic number mismatch errors
There are some hacks to force loading on mismatch, but, in my previous experience, they failed on many devices
the drivers must be compiled along the zImage
Now, why don't we drop to celox-common kernel which seems to work fine on skyrocket and other phones?
Click to expand...
Click to collapse
It is for the most part the same kernel with the few quirks of my device. More notably is my devices display drivers are mipi s6e8aa0_720hd and had to fork the kernel to apply some fixes to that driver as it's not maintained by cm.
Hmmm. I'll be the guinea pig. I will build with the new kernel and I'll test the recovery before you upload. I just think that the issue might be a memory leak in android causing the kernel to panic (overlay issue) and might not have an effect in recovery since its graphics are very basic.
I'll let you know when it's ready
Sent from my SGH-I757M using XDA Premium 4 mobile app

[WIP]Make KitKat run on new 4.3 kernel source

Since Sony has added new v45 Adreno graphics driver in .295,I think it will be good to compile a CM-like kernel and chances are that we can fix the blue flickers in this way.However,when I mananged to get the zImage booting CM properly(no reboot),I found the screen froze at Sony logo.In the logcat I can see the system is waiting for media.audio_policy,and BootAnim,or the whole display system, isn't working.though all the Adreno libs are loaded properly and the screen param is read correctly.
Related logcat:
Code:
E/Adreno-EGLSUB( 237): <CreateImage:1837>: Offset beyond buffer size.
W/Adreno-EGL( 237): <qeglDrvAPI_eglCreateImageKHR:4637>: EGL_BAD_PARAMETER
E/GLConsumer( 237): [BootAnimation] error creating EGLImage: 0x300c
W/GLConsumer( 237): [BootAnimation] updateAndRelease: unable to createImage on display=0x1 slot=0
E/qdhwcomposer( 237): Failed to call ioctl MSMFB_OVERLAY_SET err=Invalid argument
// And there are some "MDP: unknown ioctl (....)" errors in dmesg
Code:
I/ServiceManager( 670): Waiting for service media.audio_policy...
I/ServiceManager( 670): Waiting for service media.audio_policy...
I/ServiceManager( 670): Waiting for service media.audio_policy...
I/ServiceManager( 670): Waiting for service media.audio_policy...
I/ServiceManager( 670): Waiting for service media.audio_policy...
W/AudioSystem( 670): AudioPolicyService not published, waiting...
W/libc ( 236): WARNING: generic atexit() called from legacy shared library
I'm using Liquid Smooth 20140223(based on CM).And replaced the following files with stock 295.The other files are untouched.Now logcat shows nearly no error other than the ones mentioned above.
/system/etc/firmware/*
/system/etc/audio_policy.conf
/system/etc/sysmon.cfg
Click to expand...
Click to collapse
And here is how to update the Adreno libs in the system:
1.Delete these files
/system/lib/egl/* (except egl.cfg)
/system/lib/libC2D2.so
/system/lib/libc2d2_a3xx.so
/system/lib/libc2d2_z180.so
/system/lib/libgsl.so
/system/lib/libllvm-a3xx.so
/system/lib/libllvm-arm.so
/system/lib/libOpenCL.so
/system/lib/libOpenVG.so
/system/lib/libsc-a2xx.so
/system/lib/libsc-a3xx.so
Click to expand...
Click to collapse
2.Copy these files from stock 9.2.A.0.295 to the same directory(/system/vendor/lib, /system/lib will not work.)
/system/vendor/lib/egl/*
/system/vendor/lib/libadreno_utils.so
/system/vendor/lib/libC2D2.so
/system/vendor/lib/libc2d2_a3xx.so
/system/vendor/lib/libc2d2_z180.so
/system/vendor/lib/libCB.so
/system/vendor/lib/libgsl.so
/system/vendor/lib/libllvm-a3xx.so
/system/vendor/lib/libllvm-arm.so
/system/vendor/lib/libOpenCL.so
/system/vendor/lib/libOpenVG.so
/system/vendor/lib/libsc-a2xx.so
/system/vendor/lib/libsc-a3xx.so
/system/lib/egl/libGLES_android.so -> /system/lib/egl/
Click to expand...
Click to collapse
3.Boot.You can see all the libs are loaded without any error and driver info is read correctly.
Click to expand...
Click to collapse
And I will attach my kernel config and the full logcat.I didn't save dmesg...sorry...
I'm new to porting Android...Does that mean we need new HALs or something like that?Thanks!

I do not understand in porting Android. Can ask for help in the team FXP?

nnmka said:
I do not understand in porting Android. Can ask for help in the team FXP?
Click to expand...
Click to collapse
They should be already working on this...but any help is welcome

I've already got Kitkat running with 4.3 kernel sources - still no dice with the new Adreno blobs however. See the kernel source https://github.com/chirayudesai/laughing-octo-dangerzone/tree/omni/
As for the audio policy errors - they are what's causing the bootloops - you can fix that by either removing the camera HAL or fully updating it.

tilal6991 said:
I've already got Kitkat running with 4.3 kernel sources - still no dice with the new Adreno blobs however. See the kernel source https://github.com/chirayudesai/laughing-octo-dangerzone/tree/omni/
As for the audio policy errors - they are what's causing the bootloops - you can fix that by either removing the camera HAL or fully updating it.
Click to expand...
Click to collapse
THANKS A LOOOT MAN! :good::laugh:

tilal6991 said:
I've already got Kitkat running with 4.3 kernel sources - still no dice with the new Adreno blobs however. See the kernel source https://github.com/chirayudesai/laughing-octo-dangerzone/tree/omni/
As for the audio policy errors - they are what's causing the bootloops - you can fix that by either removing the camera HAL or fully updating it.
Click to expand...
Click to collapse
I used your source to compile the kernel.When I delete /system/lib/hw/vendor-camera*,booting process moves forward(the screen dims and Xperia logo gets lit,MediaScanner runs.I can even hear SMS notification sound)but there is "InputDispatcher" log spam,indicating that some window isn't responding so further input events are ignored.But after a reboot,there seems to be no problem in the logcat,except for the MSM_FB_OVERLAY/Invaild Argument error.Still nothing displayed on screen.
One weird problem:if I use Adreno libs from CM11,DDMS will grab screenshots correctly.But if stock updated ones are used,DDMS won't grab scrnshot properly.Just some lines on black ground:the attachment shows that.
If I add back the two files from stock 4.3,audio_policy error shows again.Let's see what else should be changed...

Well I've released a new omnirom test build which has everything working (except gps). The props repo is on my github and the patches for device configs are on omnirom gerrit.
Sent from my Xperia T using Tapatalk

tilal6991 said:
Well I've released a new omnirom test build which has everything working (except gps). The props repo is on my github and the patches for device configs are on omnirom gerrit.
Sent from my Xperia T using Tapatalk
Click to expand...
Click to collapse
Maybe replacing the whole arch/arm/mach-msm directory with old OmniROM one will do...I fixed GPS on CM by doing so,one and a half month ago.But I'm not sure which file causes this...

It occurred to me that if I leave CM11 unchanged and boot on 4.3 source,there will be "Bad OVInfo" log spam,which is the same as CM booting on previous Omni kernel...I should have tested the source with OmniROM.But why does CM change the ioctl/HALs? Related files in the kernel are the same...

Well I managed to get 4.3 source working on CM/LS/... roms...Just change "struct mdp_overlay_pp_params" definition in include/linux/msm_mdp.h to
struct mdp_overlay_pp_params {
uint32_t config_ops;
struct mdp_csc_cfg csc_cfg;
struct mdp_qseed_cfg qseed_cfg[2];
};
Click to expand...
Click to collapse
Things will be okay...

Now there is the long-lasting problem...ramdom reboots...I noticed there was some Watchdog:Modem Crashed logs in last_kmsg.I tried replacing /system/etc/firmware with stock one,which resulted in a not booting phone.It got stuck after the Recovery amber light with Sony logo still on screen.ADB is not running,or to say the kernel has died - removing battery with USB plugged in doesn't make the phone shut down.Any idea to upgrade the modem software?

Well I don't have enough time to test now...schoolwork is busy...sorry..

It's OK. I'll wait for it still... The CM11 is better than stock then the reboot issue would need kernel updated to help.
Sent from my Xperia V

@OP
New source have arrived:
http://developer.sonymobile.com/dow...es/open-source-archive-for-build-9-2-a-1-199/
Maybe these are somewhat easier to port :victory:

silasje1 said:
@OP
New source have arrived:
http://developer.sonymobile.com/dow...es/open-source-archive-for-build-9-2-a-1-199/
Maybe these are somewhat easier to port :victory:
Click to expand...
Click to collapse
Thanks~After the busy weeks I'll look into it.

Doesnt FXP usually incorporate the new kernels after Sony releases the source blobs?
Im not sure how long It usually takes them though...

Brewski606 said:
Doesnt FXP usually incorporate the new kernels after Sony releases the source blobs?
Im not sure how long It usually takes them though...
Click to expand...
Click to collapse
Yes.They are working on fusion3 and rhine devices now.Our devices are not active

Got a little free time...tried extract-files.sh,and new baseband is working now.Seems more stable than before...but camera & GPS & WiFi is broken.I have added new GPS blobs into proprieatry-files.txt but no use...logcat shows startFix() error...

You can look my omnirom commits - everything is now working.
Sent from my Xperia T using Tapatalk

tilal6991 said:
You can look my omnirom commits - everything is now working.
Sent from my Xperia T using Tapatalk
Click to expand...
Click to collapse
OK.I will be watching them.Thkx!
(Is light sensor working? Not until I removed /lib/hw/sensors.msm8960.so and pushed stock sensors.default.so did it start to work...no sure if it was my problem only.
And it seems that the stock lights.default.so can take the place of vendor/lib/hw/lights.qcom.so and lib/hw/vendor-lights.default.so. If that's common,we can remove the unnecessary files...)

section mismatch in android 2.3 v20s kernel

I am trying to compile android 2.3 v20s kernel and it is giving me 18 mismatch section ...I sorted out first three.....but I am not expecting the other 15.....has any one faced this.......I have use arm-eabi -4.4.3 and 4.4.0 and also 4.6 ...but no change.....
I know there are dev's who has successfully compiled it.....can any one tell me whether they saw so many mismatches ....because it is original source from lg......
I did not face these many mismatch or i think there were none during 4.0.4 compile.....
I know they can be fixed by putting of adding/removing __init etc but i am not expecting them
I have attached the build log ...

You can´t complete the compile ? Check if its complete, because if you are getting something like:
Code:
"WARNING: modpost: Found X section mismatch(es)."
Thats just a adice/warning and the compelition should be fine.

Duarte777 said:
You can´t complete the compile ? Check if its complete, because if you are getting something like:
Code:
"WARNING: modpost: Found X section mismatch(es)."
Thats just a adice/warning and the compelition should be fine.
Click to expand...
Click to collapse
They are just warnings....The build is complete
...But i think section mismatches are bad...and these are too many....
Sent from my LG-P970 using xda app-developers app

Duarte777 said:
You can´t complete the compile ? Check if its complete, because if you are getting something like:
Code:
"WARNING: modpost: Found X section mismatch(es)."
Thats just a adice/warning and the compelition should be fine.
Click to expand...
Click to collapse
Also the lines where mismatch is coming ...the code is same in 4.0.4 but they don't give warnings ...I used 4.6 for 2.3 also but same ....
Are there any compiler flags to be set in makefile which can take care of these.....
Sent from my LG-P970 using xda app-developers app

Can any more dev's put some light on this....
Sent from my LG-P970 using xda app-developers app

I downloaded arm-linux-androideabi-4.6 from https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.6/
and then only got one warning which I fixed and no warnings now.....
but if i use arm-eabi-4.6 https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/
or any arm-eabi- version then i get 14 mismatch ,,,,,,
AFAIK arm-eabi- is used to build kernels and androideabi is used to build android layer.......but the later also builds kernel and i don't get any warnings now.......
Also found one reference where arm-linux-androideab- is used to build nexus S kernel.....
http://glandium.org/blog/?p=2214
So is it safe to use kernel built by arm-linux-androideab-

I see there is no response .But that is OK,as I have fixed all the section mismatches .The issue was in LG's code..and now compiled with arm-eabi-4.6 with zero section mismatch errors....I will try the kernel after applying rmcc patch ..maybe this weekend.

got the kernel booting
see below post for info
http://forum.xda-developers.com/showpost.php?p=52409264&postcount=13
https://github.com/rajeshmk2011/lg_p970_gingerbreadkernel.git

[DEVS ONLY][BCM21553] Samsung Galaxy Pocket GT-S5300 (Cori) Development Discussion

General informations:
This thread's aim is only to represent a central meeting and discussion point for BCM21553 developers and, in particular, for the open Kernel/ROM sources development for the Samsung Galaxy Pocket GT-S5300 (codenamed Cori).
Information for common users:
As already described in the previous section, if you are not a developer, please restrict your posts to the general discussion thread so that developers can maintain good communication. Every post that is not strictly respecting these rules will be reported to the forum moderators. Thanks for your understanding.
For any other BCM21553 device related question or information, please, use this thread as a reference point, instead:
[DEVS ONLY][BCM21553 series] CyanogenMod 11 for BCM21553 Development Discussion

As someone already might know, I'm streambinder, from MoltenMotherBoard team.
I have already followed some projects for the GT-S5300, but especially kept in contact
with some of the events related to the porting of ROM and Kernel sources for BCM21553 chipset based devices.
In this precise moment, the sources in my possession allow you to be able to compile
a bugfree CWM 5.0.2.8 (based on CyanogenMod 7 code) with a kernel based on the Samsung stock one.
The only - fundamental - problem was due to the fact that unless I hadn't used the prebuilt INIT binary
token in the Samsung stock firmware boot.img, the phone would not work - or, better, boot up.
This means that until the situation - regarding this issue - doesn't change, our access to the porting of custom ROM
would be barred.
Recently, I decided to give Cori another chance and rework my sources, looking at the wonderful work brought
by the BroadcomCM team on CyanogenMod 9 (in particular, thanks to @bieltv.3 and @Alberto96) and @psyke83 on CyanogenMod 11.
They've not only been able to run these two ROMs in a more or less crude way, but this developer has been able to write
the necessary strings to make the INIT binary of some of these BCM21553 devices opensource.
Strong of this informations, I readjusted some of the sources of BroadcomCM's CyangenMod 9, which includes
all the progress carried out by both the team and psyke83, in order to make them work even on Cori,
and am now next to the first test of the CWM 6.X.X.X, based on IceCreamSandwich code.
At the same time, @akhbh is working on the KitKat code based CWM.
I hope I can give more information about any progress as soon as possible.

The General Discussion thread for non-development issues is here:
*.[DISCUSSION] CyanogenMod 11 For Galaxy Pocket GT-S5300 Discussion Thread

Made a first test of CWM based on CyanogenMod 9 code.
It seems it cannot flash it as it weighs so much compared to its partition configuration value: in fact, the maximum boot partition size is set up to 5.0MB, but the compiled boot.img weighs 5.3MB.
Will have to resize its weight in order to make it fill into the partition.
@akhbh, have you had any complication in these terms, with CyanogenMod 11 sources?
@psyke83, what do you suggest to do? Do you think an increasement of boot partition would be a better idea?

streambinder said:
Made a first test of CWM based on CyanogenMod 9 code.
It seems it cannot flash it as it weighs so much compared to its partition configuration value: in fact, the maximum boot partition size is set up to 5.0MB, but the compiled boot.img weighs 5.3MB.
Will have to resize its weight in order to make it fill into the partition.
@akhbh, have you had any complication in these terms, with CyanogenMod 11 sources?
@psyke83, what do you suggest to do? Do you think an increasement of boot partition would be a better idea?
Click to expand...
Click to collapse
No, I didn't faced those complications. My boot.img weighted around 4.5 MB in lzma compression mode. In gzip, it increased to more than 5 mb.

akhbh said:
No, I didn't faced those complications. My boot.img weighted around 4.5 MB in lzma compression mode. In gzip, it increased to more than 5 mb.
Click to expand...
Click to collapse
Perfect.
Which kernel have you based your build on?

streambinder said:
Perfect.
Which kernel have you based your build on?
Click to expand...
Click to collapse
Well, I took the GeTux kernel for cori, had to change the board name though and then compile it. CWM was booting even before changing the board name but there was no reaction from the phone on trying to boot cm9/cm11
And after changing board name, a black screen on trying to boot
Another info: When tried to merge cori source into the bcm21553 common one, it did compile but gave bootloop of GT-S5300 logo on trying to boot as well as when trying to go in CWM.
Bieltv.3 recommended to use cori source instead of the bcm21553 common one so we used cori sources

akhbh said:
Well, I took the GeTux kernel for cori, had to change the board name though and then compile it. CWM was booting even before changing the board name but there was no reaction from the phone on trying to boot cm9/cm11
And after changing board name, a black screen on trying to boot
Another info: When tried to merge cori source into the bcm21553 common one, it did compile but gave bootloop of GT-S5300 logo on trying to boot as well as when trying to go in CWM.
Bieltv.3 recommended to use cori source instead of the bcm21553 common one so we used cori sources
Click to expand...
Click to collapse
I suggest to use our Kernel sources for now, too: it will automatically bypass few errors/issues/bootloops that we cannot now fight with.
The most important thing is to make INIT working from sources (hope it will be working
on my CM9 sources, too) and check that every our configuration is correctly working and
making Cori boot into recovery.
Once we'll make it perfectly working without any kind of issue, will be the right time to try
to make Cori supported with the BC21553-common kernel.

streambinder said:
I suggest to use our Kernel sources for now, too: it will automatically bypass few errors/issues/bootloops that we cannot now fight with.
The most important thing is to make INIT working from sources (hope it will be working
on my CM9 sources, too) and check that every our configuration is correctly working and
making Cori boot into recovery.
Once we'll make it perfectly working without any kind of issue, will be the right time to try
to make Cori supported with the BC21553-common kernel.
Click to expand...
Click to collapse
Okay, I will use your kernel sources and try if something is changed once I reach home. For now, I neither have this device nor a PC, as I'm in another city.
Will be keenly watching your work. Will start after reaching home around the end of September

akhbh said:
Okay, I will use your kernel sources and try if something is changed once I reach home. For now, I neither have this device nor a PC, as I'm in another city.
Will be keenly watching your work. Will start after reaching home around the end of September
Click to expand...
Click to collapse
No problem, mate.
Here you have every source in my possession:
platform_kernel_samsung_cori
platform_device_samsung_cori
Keep in contact with me, as I will need some informations by you.
Anyway I'm now making another build, keeping some not so much important binaries excluded, so that I can make the compiled boot.img fill into our little Cori's boot partition. I know it's a dirty workaround, but if it works, I'll use it untill @psyke83 will suggest me a better way to do.

streambinder said:
No problem, mate.
Here you have every source in my possession:
platform_kernel_samsung_cori | github.com
platform_device_samsung_cori
Keep in contact with me, as I will need some informations by you.
Anyway I'm now making another build, keeping some not so much important binaries excluded, so that I can make the compiled boot.img fill into our little Cori's boot partition. I know it's a dirty workaround, but if it works, I'll use it untill @psyke83 will suggest me a better way to do.
Click to expand...
Click to collapse
have u tried to build cwm v6 from cm9 source ??

cleverior.ipul said:
have u tried to build cwm v6 from cm9 source ??
Click to expand...
Click to collapse
Of course, mate. I'm working on it, right now.
It doesn't seem to boot, strange if the same INIT binary sources are working for @akhbh.
#UPDATE
In order to troubleshoot, I'll give you some info.
For his build I used these sources:
platform_kernel_samsung_cori
platform_device_samsung_cori
android_device_samsung_bcm21553-common
Applied some lines on our bcm21553-bootimg.mk, too, in order to exclude parted and mke2fs and make the compiled boot.img weigh less.
@cleverior.ipul, can you link me your kernel sources, as akhbh said he used your ones for CM11.
@akhbh, which modifies have you applied in order to compile CWM based on CM11 code? Which device tree?
#UPDATE 2
Attached my compiled boot.img.
If anyone of you would extract it (you can easily use this tool: bootimgtools - read how to use it in the README) and make a diff with the CM11 one (just extract the ramdisk of both boot.imgs and - in the terminal - use this command: diff -urN /path/to/cm9/ramdisk /path/to/cm11/ramdisk > diff.patch), would make to me a huge favour.
Let me know.

streambinder said:
Of course, mate. I'm working on it, right now.
It doesn't seem to boot, strange if the same INIT binary sources are working for @akhbh.
#UPDATE
In order to troubleshoot, I'll give you some info.
For his build I used these sources:
platform_kernel_samsung_cori
platform_device_samsung_cori
android_device_samsung_bcm21553-common
Applied some lines on our bcm21553-bootimg.mk, too, in order to exclude parted and mke2fs and make the compiled boot.img weigh less.
@cleverior.ipul, can you link me your kernel sources, as akhbh said he used your ones for CM11.
@akhbh, which modifies have you applied in order to compile CWM based on CM11 code? Which device tree?
#UPDATE 2
Attached my compiled boot.img.
If anyone of you would extract it (you can easily use this tool: bootimgtools - read how to use it in the README) and make a diff with the CM11 one (just extract the ramdisk of both boot.imgs and - in the terminal - use this command: diff -urN /path/to/cm9/ramdisk /path/to/cm11/ramdisk > diff.patch), would make to me a huge favour.
Let me know.
Click to expand...
Click to collapse
I think we didn't had significant changes. Perhaps the same as totoro. But, that resulted in the internal_sd not mounting error in cwm.
Sadly, as said before, I am away from my home city and can't provide the files to you and can't do the boot.img diffs as well
Try to ask psyke83, he might have a solution for that

akhbh said:
I think we didn't had significant changes. Perhaps the same as totoro. But, that resulted in the internal_sd not mounting error in cwm.
Sadly, as said before, I am away from my home city and can't provide the files to you and can't do the boot.img diffs as well
Try to ask psyke83, he might have a solution for that
Click to expand...
Click to collapse
Then, if you didn't make any massive change upon the sources, then I'll only try using your kernel.
Can you give me your kernel sources, mate, please?

streambinder said:
Then, if you didn't make any massive change upon the sources, then I'll only try using your kernel.
Can you give me your kernel sources, mate, please?
Click to expand...
Click to collapse
Currently, I can provide you the boot.img only. For the sources, @cleverior.ipul can provide the kernel sources coz as said earlier, his kernel is used. Well, we were working together to bring cm11 but weren't successful

akhbh said:
Currently, I can provide you the boot.img only. For the sources, @cleverior.ipul can provide the kernel sources.
Click to expand...
Click to collapse
Ok, please send it to me, will compare it with my package.

streambinder said:
Ok, please send it to me, will compare it with my package.
Click to expand...
Click to collapse
Here it is:
http://www.4shared.com/zip/1nKFbOJ2ba/ccccGetux_CM11.html

streambinder said:
Of course, mate. I'm working on it, right now.
It doesn't seem to boot, strange if the same INIT binary sources are working for @akhbh.
#UPDATE
In order to troubleshoot, I'll give you some info.
For his build I used these sources:
platform_kernel_samsung_cori
platform_device_samsung_cori
android_device_samsung_bcm21553-common
Applied some lines on our bcm21553-bootimg.mk, too, in order to exclude parted and mke2fs and make the compiled boot.img weigh less.
@cleverior.ipul, can you link me your kernel sources, as akhbh said he used your ones for CM11.
@akhbh, which modifies have you applied in order to compile CWM based on CM11 code? Which device tree?
#UPDATE 2
Attached my compiled boot.img.
If anyone of you would extract it (you can easily use this tool: bootimgtools - read how to use it in the README) and make a diff with the CM11 one (just extract the ramdisk of both boot.imgs and - in the terminal - use this command: diff -urN /path/to/cm9/ramdisk /path/to/cm11/ramdisk > diff.patch), would make to me a huge favour.
Let me know.
Click to expand...
Click to collapse
here the link source https://github.com/cleverior/android_kernel_samsung_cori
i've changed the board name. If your device can not boot after using the zImage from this source, then rename init.bcm21553.rc to init.gt-s5300.rc.

@streambinder, what is grom? As bieltv.3 said that init built grom for cori is required to fix adb over cwm recovery. If adb gets working, then possibly the black screen while booting cm11 might get fixed

akhbh said:
@streambinder, what is grom? As bieltv.3 said that init built grom for cori is required to fix adb over cwm recovery. If adb gets working, then possibly the black screen while booting cm11 might get fixed
Click to expand...
Click to collapse
Sincerely don't what are you talking about.
Anyway, have to try to understand where's the problem with the not-booting CWM.
Will try with your sources and let you know.