[DEVS ONLY] CyanogenMod 11 for Samsung BCM21553 Development Discussion

psyke83 · May 29, 2014

WARNING: App2SD and Mounts2SD are not recommended for use with any OTA-enabled ROMs, as they break delta updates, and may cause problems during full upgrades. I suggest using my modified version of S2E, simple2ext_mod, instead.

NOTE 1: I recommend that everyone uses @Bhargav97's Google Apps package (cm11 v2.2 version or later). Other versions of gapps may cause issues or break delta updates.

NOTE 2: You must ensure that your phone is running the latest baseband available for your region, or else your device will not operate correctly when a SIM card is inserted. If you have a cooperve and tassve, you may need to flash the latest totoro baseband (which will work correctly on your device). Please see @marcussmith2626's stock ROM thread for links to the appropriate files.

Information for users:

This topic is intended only as a meeting point for other developers of the shared BCM21553 devices to discuss and solve issues related to development. If you are not a developer, please restrict your posts to the general discussion thread so that developers can maintain good communication. Thanks for your understanding.

First-time installation:

ClockworkMod v6.0.5.3 or later (MTD version) is mandatory to install CM11. If needed, download the latest recovery build here
Download the latest full OTA build for totoro from here
If necessary, flash the ClockworkMod v6 build, then reboot into recovery. If you can't flash the CWMv6 update package (.zip) in your existing recovery, use the Odin package (.tar.md5) instead.
Perform a data wipe - this is mandatory if upgrading from an older Android revision
Flash the OTA package and reboot.

How to update (via OTA):

Please consult the cm-ota instructions on Jenkins.

Current issues (06/10/2014)

OMX codecs (for accelerated audio/video - may never be solved)
SIM unlock doesn't work (you must remove your SIM lock in another device/ROM)
Video recorder

Summary of major work done:

Forked broadcomCM devices into androidarmv6 repository (forked from ics branches).
Initial changes needed for cm-11.0 have been committed to cooperve, tassve, totoro and bcm21553-common device trees.
All of Broadcom's code has been adapted for the cm-11.0 branch.
After some reverse engineering of the vendor binaries, "adbd" and "init" built from source now work correctly. ADB will now set the proper USB mode, can give a root shell, and no longer has a hardcoded dependency on /system/bin/sh, which should help a great deal with debugging. We also no longer need to use the init prebuilt binary - the source-built version is now compatible.
Implemented common kernel source for totoro, cooperve and tassve.
Implemented hybrid boot/recovery/charge ramdisk.
Fixed WiFi, Bluetooth, Bluetooth tether & mac addresses.
Fixed graphical performance regression on CM11 branch.
Fixed basic audio (speaker, microphone, software encoders/decoders)
Fixed GPS.
Fixed Gallery, wallpaper chooser, live wallpapers, RenderScript, and possible EGL crashes in other apps
Added workaround for SystemUI corruption
Fixed graphical corruption/stability issues (caused by buggy GL_EXT_discard_framebuffer extension)
Fixed RIL, telephony and audio routing to speakers, headset, earpiece, microphone and microphone mute.
Audio routing improvements/fixes, small graphics performance optimizations
Fixed camera
Fixed wifi tethering
Updated to newer bcmdhd wifi driver to resolve wifi instability
Fixed USB tethering (with caveats)
Improved audio routing and fixed BT headsets (SCO)

* = this code is work in progress, which means that it is not yet available in the OTA build.

XDA:DevDB Information
CyanogenMod 11 for Samsung BCM21553 series, ROM for the Samsung Galaxy Y GT-S5360

Contributors
psyke83

Version Information
Status: Testing

Created 2014-10-27
Last Updated 2014-10-27

bieltv3 · May 29, 2014

I will update cooperve device tree as soon as I can. I guess @Alberto96 could adapt tassve (his device). Lets get some fun here

Enviado desde mi Xperia SP mediante Tapatalk

Alberto96 · May 29, 2014

No problem

First I'll try adb/init changes, and then adapt repo.

bieltv3 · May 29, 2014

@psyke83 , I have created some threads regarding development of this BCM21553 devices with the information I was able to get while developing:
HW drivers: http://xdaforums.com/showthread.php?t=2666566
Audio libs (source): http://xdaforums.com/showthread.php?t=2682819

Enviado desde mi Xperia SP mediante Tapatalk

Alberto96 · May 29, 2014

Ok, tested on CM9.

Hardware is fully initialized, but seems that there is an heavy memory corruption (like you said).

I/DEBUG ( 4743): debuggerd committing suicide to free the zombie!
F/libc ( 4747): Fatal signal 13 (SIGPIPE) at 0x0000128b (code=0)
F/libc ( 4748): Fatal signal 13 (SIGPIPE) at 0x0000128c (code=0)
F/libc ( 4749): Fatal signal 13 (SIGPIPE) at 0x0000128d (code=0)
F/libc ( 4750): Fatal signal 13 (SIGPIPE) at 0x0000128e (code=0)
F/libc ( 4751): Fatal signal 13 (SIGPIPE) at 0x0000128f (code=0)
F/libc ( 4752): Fatal signal 13 (SIGPIPE) at 0x00001290 (code=0)
F/libc ( 4753): Fatal signal 13 (SIGPIPE) at 0x00001291 (code=0)
F/libc ( 4754): Fatal signal 13 (SIGPIPE) at 0x00001292 (code=0)

I adapted almost all, i wasn't able to adapt just property_service.c & property_service.h so recovery/charging mode isn't working yet.

Great job @psyke83 !

psyke83 · May 30, 2014

Alberto96 said:
Ok, tested on CM9.
Hardware is fully initialized, but seems that there is an heavy memory corruption (like you said).
Great job @psyke83 !

Thanks for testing. To be clear, you're saying that CM9 boots into Android with the init built from the CM9 sources? I'm particularly curious to know if surfaceflinger is working OK. I suspected that something in the init may be causing problems either with the framebuffer or hgl libraries for CM11, but if it works on CM9, then I might be wrong.

I've merged the cm-11 bringup patches for tassve and cooperve. I can only confirm that it will allow the builds to complete (when all of the other integration patches are applied), but I imagine there will be more bugs that need fixing. If you find major bugs with the device configs, please submit them to gerrit or at least let me know,

We also need to organize a proper shared kernel source that we can integrate into the build system, and then get rid of the prebuilt kernels. Until then, you may need to recompile the kernel and modify your board files so that it doesn't use that generic "Thunderbird" name. The init.rc files are expecting the machine name to be "GT-S5360 Board", "GT-S5570I Board", etc. The init binary reads the machine name from the cmdline, and then converts to lowercase and filters spaces. So, the .rc file for the totoro would be "gt-s5360board" -> "init.gt-s5360board.rc".

Alberto96 · May 30, 2014

psyke83 said:
Thanks for testing. To be clear, you're saying that CM9 boots into Android with the init built from the CM9 sources? I'm particularly curious to know if surfaceflinger is working OK. I suspected that something in the init may be causing problems either with the framebuffer or hgl libraries for CM11, but if it works on CM9, then I might be wrong.

I've merged the cm-11 bringup patches for tassve and cooperve. I can only confirm that it will allow the builds to complete (when all of the other integration patches are applied), but I imagine there will be more bugs that need fixing. If you find major bugs with the device configs, please submit them to gerrit or at least let me know,

We also need to organize a proper shared kernel source that we can integrate into the build system, and then get rid of the prebuilt kernels. Until then, you may need to recompile the kernel and modify your board files so that it doesn't use that generic "Thunderbird" name. The init.rc files are expecting the machine name to be "GT-S5360 Board", "GT-S5570I Board", etc. The init binary reads the machine name from the cmdline, and then converts to lowercase and filters spaces. So, the .rc file for the totoro would be "gt-s5360board" -> "init.gt-s5360board.rc".

Yes, CM9 with source built init & adbd binaries boots fine.

True, a proper shared kernel is better. But we also need an updated kernel source (request processing by Samsung osrc)

Sent from my GT-I9500 using Tapatalk

psyke83 · May 30, 2014

Good news: I just discovered that surfaceflinger works if I remove the hwcomposer.default library. However, there is some graphical distortion, and the colours are incorrect. Still, it's some progress. Will try to troubleshoot hwcomposer now.

savie · May 31, 2014

android_native.h similiar with ANativeObjectBase.h without include <android/native_window.h>

updater-script cant run in cwm5 so need modified wanna force try to flash zip package but still not luck for boot coz messy ramdisk code.

temporary cwm6 still black screen so since its not working modified ramdisk is 1st think to do with old cwm5 (in my case) to running dualboot (stock cm) at least to make it boot 1st.
@psyke83 great work and still follow ur update from behind

psyke83 · May 31, 2014

Alberto96 said:
Yes, CM9 with source built init & adbd binaries boots fine.

True, a proper shared kernel is better. But we also need an updated kernel source (request processing by Samsung osrc)

Sent from my GT-I9500 using Tapatalk

Was there a white-screen bug with the init you built from source? I notice on my totoro that the screen turns white when the screen returns from off. It happens both in charge mode and in Android itself. I'm not sure if it's a bug caused by init or just something related to the stock kernel. I haven't been working with this device for very long, so I'm not aware of any common issues with the kernel, etc.

Ashutos1997 said:
This means cm11 boots now ?

-CALIBAN666- said:
sorry for offtopic,but are you back????

There's a general thread for off-topic posts (linked in the first paragraph of my first post)... please use it in future. This thread is supposed to be for developers to collaborate and fix bugs only.

Alberto96 · May 31, 2014

psyke83 said:
Was there a white-screen bug with the init you built from source? I notice on my totoro that the screen turns white when the screen returns from off. It happens both in charge mode and in Android itself. I'm not sure if it's a bug caused by init or just something related to the stock kernel. I haven't been working with this device for very long, so I'm not aware of any common issues with the kernel, etc.

No white screen bug here. (i'm using my ramdisk but with source built init/adbd)

It should a bug related to missing backlight permissions:

chown system system /sys/class/backlight/aat1401-backlight/brightness
chown system system /sys/class/backlight/pwm-keypad-backlight.0/brightness

I had this bug when i've removed these lines

psyke83 · Jun 4, 2014

@bieltv.3, @Alberto96,

The shared kernel is working, but has only been tested with totoro. It only has basic functionality and certain drivers need updating, but for now, it can be a stable reference point. Can you please give me your current working defconfigs for your respective devices? I will update them to be compliant with CM11's configuration requirements and submit as initial defconfigs, to see if the kernel can work for your devices. Thanks.

bieltv3 · Jun 4, 2014

psyke83 said:
@bieltv.3, @Alberto96,

The shared kernel is working, but has only been tested with totoro. It only has basic functionality and certain drivers need updating, but for now, it can be a stable reference point. Can you please give me your current working defconfigs for your respective devices? I will update them to be compliant with CM11's configuration requirements and submit as initial defconfigs, to see if the kernel can work for your devices. Thanks.

I will push cooperve kernel source this afternoon. Thanks for your work done, really appreciate. I hope I can upload tassve too, if Alberto dont mind. I will base it though on your tototo config, but on cooperve. As far as I know, cooperve need changes on its modules to get the kernel work good, as it have a different canera driver (updated one for 5 MP and flash)

Enviat des del meu Xperia SP usant Tapatalk

bieltv3 · Jun 4, 2014

Kernel config source for cooperve has been updated. I'll push it gerrit as soon as I get home. I've updated on school, and I don't have the config of the server there. @psyke83 if you can take a look at it, I've made a pastebin, you can push to gerrit directly if you are OK with it, or make any changes you think are necessary:

http://pastebin.com/Svir6qtZ

Alberto96 · Jun 4, 2014

psyke83 said:
@bieltv.3, @Alberto96,

The shared kernel is working, but has only been tested with totoro. It only has basic functionality and certain drivers need updating, but for now, it can be a stable reference point. Can you please give me your current working defconfigs for your respective devices? I will update them to be compliant with CM11's configuration requirements and submit as initial defconfigs, to see if the kernel can work for your devices. Thanks.

You can find my defconfig on github. It's updated.

https://github.com/Alberto96/androi...arch/arm/configs/cyanogenmod_tassve_defconfig

Sent from my GT-I9500 using Tapatalk

graffixnyc · Jun 4, 2014

Thread cleaned. Please respect the dev's wish and do not post non development posts in this section

Alberto96 · Jun 4, 2014

@psyke83 :

On CM9 using tassve kernel with built-in gememalloc there are problems (with heavy heavy heavy graphic corruption and laggy screen). (this error in logcat: [v3d_opt.c:v3d_thread:1415] wait timed out [1500]ms )

your commit (https://github.com/androidarmv6/and...mmit/17cd93229df1ff8f5f7616398b8b792a8fbd1c92) should fix this.

If i use your egl commit and use built-in gememalloc all should work but it will work as is on CM11 with heavy graphic corruption.

Without using built-in gememalloc and your egl commit CM9 runs great with much less corruption than CM11.

We should investigate more on this....something is wrong here with memory allocation.

psyke83 · Jun 4, 2014

Alberto96 said:
@psyke83 :

On CM9 using tassve kernel with built-in gememalloc there are problems (with heavy heavy heavy graphic corruption and laggy screen). (this error in logcat: [v3d_opt.c:v3d_thread:1415] wait timed out [1500]ms )

your commit (https://github.com/androidarmv6/and...mmit/17cd93229df1ff8f5f7616398b8b792a8fbd1c92) should fix this.

If i use your egl commit and use built-in gememalloc all should work but it will work as is on CM11 with heavy graphic corruption.

Without using built-in gememalloc and your egl commit CM9 runs great with much less corruption than CM11.

We should investigate more on this....something is wrong here with memory allocation.

Good observations, thanks. CM11 seems to work exactly the same with or without the gememalloc modules loaded (in the case in which it's not compiled-in). However, I think that the gememalloc is only a wrapper module, and a lot of functions are bypassed in favour of bmem.

I was trying to avoid this, but I think it's best for me to download the ICS source and run a build. Maybe I can get some better ideas on solving these issue with CM11. In the meantime, please let me know if you make any more progress. Thanks.

Alberto96 · Jun 4, 2014

psyke83 said:
Good observations, thanks. CM11 seems to work exactly the same with or without the gememalloc modules loaded (in the case in which it's not compiled-in). However, I think that the gememalloc is only a wrapper module, and a lot of functions are bypassed in favour of bmem.

I was trying to avoid this, but I think it's best for me to download the ICS source and run a build. Maybe I can get some better ideas on solving these issue with CM11. In the meantime, please let me know if you make any more progress. Thanks.

Maybe I'll try something next week. I need to update first some stuff for another device (gt-i9500, samsung finally released 4.4.2 sources for it).

Sent from my GT-I9500 using Tapatalk

psyke83 · Jun 5, 2014

Alberto,

I'm up and running with ICS now. Performance is very good and I don't see graphics corruption, but it is unstable. I believe it's the same issue with bmem allocation that the alcatel code fixes.

Anyway, I'm about to test the built-in gememalloc, but something else that you can try is to disable loading of all modules in system/lib/modules with the regular kernel (no gememalloc built-in). I just tried it here on ICS, and I see absolutely no difference in graphics performance with or without the modules loaded. I suspect those modules are used for other things, possibly related to video decoding.

[DEVS ONLY] CyanogenMod 11 for Samsung BCM21553 Development Discussion

Inactive Recognized Developer

Senior Member

Recognized Developer

Senior Member

Recognized Developer

Inactive Recognized Developer

Recognized Developer

Inactive Recognized Developer

Senior Member

Inactive Recognized Developer

Recognized Developer

Inactive Recognized Developer

Senior Member

Senior Member

Recognized Developer

Retired Forum Mod / Inactive Recognized Developer

Recognized Developer

Inactive Recognized Developer

Recognized Developer

Inactive Recognized Developer

Similar threads

Top Liked Posts