WARNING! This ROM is for the SPH-L520 variant only!
Code:
/*
* Your warranty is now void.
*
* We are not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at us for messing up your device, we will laugh at you.
*
*/
Code:
[ROM]
[What works]
Boot Animation
Wifi/Teather
Bluetooth
Basic Sound
Adb/Usb/Charging
Camera
Notification LEDs
FM Radio
Calls
[Doesn't work right]
NFC
LTE/SMS/MMS/
GPS
IR Remote
[Untested]
Everything Else
[Bugs]
Camera crashes on startup if switched to external storage - to fix crash, go to settings -> apps -> all -> camera -> clear data
Code:
[Recovery]
[What works]
Nandroid backup
Nandroid Restore
Install Rom
Factory Restore
[Untested]
Everything else
[Bugs]
None Known
This is based off of arco's work at:
https://github.com/CyanogenMod/android_device_samsung_serranoltexx/tree/stable/cm-11.0
and all the rest of upstream.
Here's my github for gpl compliance/etc.
https://github.com/s0be/android_device_samsung_serranoltespr
Installation
Here's a simple list of what you need.
serranoltespr-cwm-6051.img
cm-12.1-20150815-UNOFFICIAL-serranoltespr.zip
CM12.1 Google Apps (Optional?)
THIS ROM ONLY WORKS WITH THIS RECOVERY. Do not use recoveries for other devices with the sprint s4 mini
Make sure to take a nandroid then wipe /data before installing this rom.
I'm too lazy to write proper install instructions, if someone would like to, I'll happily add them to this post.
I'm too lazy to update anything after this point. It's all old.
XDA:DevDB Information
CM11.0 for Sprint Galaxy S4 Mini, a ROM for the Samsung Galaxy S 4 Mini
Contributors
s0be
ROM OS Version: 4.4.x KitKat
ROM Kernel: Linux 3.4.x
Based On: CyanogenMod
Version Information
Status: Beta
Created 2014-03-04
Last Updated 2014-03-26
3/10
- First release.
- Waiting on goo.im account
3/11
- Resync'd with upstream
- no local changes
3/17
- Still using the 3/11 upstream
- Switched to init.carrier.sh from stock
- Switched to ril files from stock
- Lots of other changes to make the previous 2 things work.
- Now feature complete, stable, daily driver, etc.
3/23
- Resync'd with upstream
- First build based off of grand unified serrano vendor tree
- Based on arco68's device tree.
Welcome s0be! Been a while since I've seen you around, so it's great to see you here! Let me know if you need anything.
arco68 said:
Welcome s0be! Been a while since I've seen you around, so it's great to see you here! Let me know if you need anything.
Click to expand...
Click to collapse
Will do. Just flashed my recovery. If you check my github you'll see a .patch file for the cm msm8930 kernel tree. I suspect my change in the gpio's was, in fact, exactly as wrong as I suspected. When I booted the recovery, the phone vibrated continuously. I did a nandroid backup and that seemed to work, backing up to sdcard1. Going to alter my change to the gpio defines for the cypress touch panel so that it always uses 24 for sda and 25 for scl.
I was actually amazed at exactly how LITTLE invasion I had to do into areas outside devices/samsung/serranoltespr to get it to compile. The kernel was the only place any non trivial changes were required (aside from extract-files.sh, but that's so device/rom specific that it's not a surprise at all).
Woohoo, working recovery!
s0be said:
Woohoo, working recovery!
Click to expand...
Click to collapse
Getting closer. I've built a recovery that has working usb. Now I'm trying to get a kernel that both boots CM11, and has working USB.
I've added serranoltespr to the build barriers. Without it the HAL for camera, gps and a few other things won't build.
Which reminds me, I need to add it to vendor barrier as well.
arco68 said:
I've added serranoltespr to the build barriers. Without it the HAL for camera, gps and a few other things won't build.
Which reminds me, I need to add it to vendor barrier as well.
Click to expand...
Click to collapse
Cool, thanks. Once I get a msm8930-common kernel working with USB, I'll sync up. Are you a kernel-msm8930-common maintainer? Should kernel patches go through github fork/pull requests or ??
Yeah, I'm the only maintainer. Patches usually goes through gerrit: http://review.cyanogenmod.org/#/q/status:open,n,z
I have elevated permissions on that repo, so I sometimes bypasses gerrit and pushes patches directly to github. Especially when there's a bulk of patches that needs to be merged.
I have an 'only mostly broken' build done, is anyone actually waiting for this, or should I get it feature complete first. Currently missing:
3g/Cell calls.
Basically, LTE works, or you can force 1x, and calls work, no 3g at this time. Everything else seems to work.
arco68 said:
Yeah, I'm the only maintainer. Patches usually goes through gerrit: http://review.cyanogenmod.org/#/q/status:open,n,z
I have elevated permissions on that repo, so I sometimes bypasses gerrit and pushes patches directly to github. Especially when there's a bulk of patches that needs to be merged.
Click to expand...
Click to collapse
only 1 patch so far is even remotely intrusive, and it's just updating the serial_msm_hs driver (which is disabled for the other 8930 boards). Now that I have USB charging working, I'm going to verify I need that change and likely drop it if not. I'm fine with the slow gerrit review.
I noticed that the US variants might need their own base defconfig, so you're using msm8930_serrano_usa_defconfig, right? If so, make sure CONFIG_USB_ANDROID_SAMSUNG_MTP is not enabled. That should probably give you working USB.
Try with this base config. I've adjusted the US variant one to match CM's defconfig.
I'll try to adjust BoardConfig in serrano-common so it selects the base deconfig based on variant.
arco68 said:
I noticed that the US variants might need their own base defconfig, so you're using msm8930_serrano_usa_defconfig, right? If so, make sure CONFIG_USB_ANDROID_SAMSUNG_MTP is not enabled. That should probably give you working USB.
Click to expand...
Click to collapse
arco68 said:
Try with this base config. I've adjusted the US variant one to match CM's defconfig.
I'll try to adjust BoardConfig in serrano-common so it selects the base deconfig based on variant.
Click to expand...
Click to collapse
Oh, I just based it off of msm8930_serrano_spr_defconfig (which inherits cyanogenmod-serrano) then enabled the stuff to get USB going. The actual specific issue looks to have been needing:
CONFIG_MFD_MAX77693 along with the correct battery/charger/etc.
Here's my current 'working' spr_defconfig
Code:
# This needs cleaned up, I suspect a lot of this is unnecessary.
CONFIG_MACH_SERRANO_SPR=y
CONFIG_2MIC_QUP_I2C=y
CONFIG_2MIC_ES305=y
CONFIG_2MIC_QUP_I2C_GSBI11=y
CONFIG_AUTHENTEC_VPNCLIENT_INTERCEPTOR=m
CONFIG_KEYBOARD_CYPRESS_TOUCH=y
CONFIG_POWER_SUPPLY=y
CONFIG_CHARGER_MAX77XXX=y
CONFIG_CHARGER_MAX77803=y
CONFIG_MFD_PM8921_CORE=y
CONFIG_MFD_PM8821_CORE=y
CONFIG_MFD_PM8038_CORE=y
CONFIG_MFD_PM8XXX_SPK=y
CONFIG_MFD_PM8XXX_BATT_ALARM=y
CONFIG_MFD_MAX77693=y
CONFIG_PM8921_BMS=n
CONFIG_PM8921_CHARGER=y
CONFIG_PM8921_SEC_CHARGER=n
CONFIG_MFD_PM8921_CORE=y
CONFIG_FUELGAUGE_MAX17048=y
CONFIG_BATTERY_SAMSUNG=y
CONFIG_SEC_DEBUG=y
CONFIG_SEC_DEBUG_SCHED_LOG=y
CONFIG_SEC_DEBUG_SUBSYS=y
CONFIG_USB_SWITCH_TSU6721=n
CONFIG_SERIAL_MSM_HS=y
CONFIG_USB_CI13XXX_MSM_HSIC=y
The only broken bits right now are 3g/lte phonecall sms/mms handovers and notification LEDS.
There's one base config for all variants, and one that's specific for each variant. For the EU variants, the base config is msm8930_serrano_defconfig. This is for stock ROM, so for CM I've adapted it and enabled custom bits in a new defconfig called cyanogen_serrano_defconfig.
The US variants seems to be using msm8930_serrano_usa_defconfig as their base config, and most of the things you added to the spr_defconfig should be enabled there already.
Add the defconfig I attached earlier to your kernel tree, and modify BoardConfigCommon.mk in serrano-common with
TARGET_KERNEL_CONFIG := cyanogen_serrano_usa_defconfig
The msm8930_serrano_spr_defconfig can be left as original without your changes. Only change there should be removing CONFIG_AUTHENTEC_VPNCLIENT_INTERCEPTOR, as afaik it's not used in CM.
Are you sure you have a notification light? None of the other variants have one.
arco68 said:
There's one base config for all variants, and one that's specific for each variant. For the EU variants, the base config is msm8930_serrano_defconfig. This is for stock ROM, so for CM I've adapted it and enabled custom bits in a new defconfig called cyanogen_serrano_defconfig.
The US variants seems to be using msm8930_serrano_usa_defconfig as their base config, and most of the things you added to the spr_defconfig should be enabled there already.
Add the defconfig I attached earlier to your kernel tree, and modify BoardConfigCommon.mk in serrano-common with
TARGET_KERNEL_CONFIG := cyanogen_serrano_usa_defconfig
The msm8930_serrano_spr_defconfig can be left as original without your changes. Only change there should be removing CONFIG_AUTHENTEC_VPNCLIENT_INTERCEPTOR, as afaik it's not used in CM.
Are you sure you have a notification light? None of the other variants have one.
Click to expand...
Click to collapse
Yep, notification light works fine in stock. at least tri-color (r/g/b). Will switch to the .config you sent. When I tried with the original usa_defconfig, the phone wouldn't boot.
Wow! Lucky you!
I'm pretty confident that's it's the same LED as in the regular S4 and the Mega, so you should be able to use this liblights: https://github.com/arco/android_device_samsung_melius-common/tree/cm-11.0/liblights
Also, you need to make the following changes to enable it: https://github.com/arco/android_dev...mmit/d002c6ee304e7caae71829b33135e26b5ea4e5f8
I'll need to figure out how to add this so it doesn't conflict with the variants that doesn't support it. Likely we need to move some stuff into device repos.
Btw, is this a GSM or a CDMA phone? If it's CDMA that may explain the network issues you have.
Ah right. It's a CDMA device. Yeah that will require some device changes. I'll look into it.
Just downloaded the kernel sauce for SPH-L520. Seems like it's using msm8930_serrano_defconfig as base config, and not the usa one. I'll need to compare what's different from the 9195 kernel, and also probably merge some code changes.
I've been watching and waiting for the G900TUVU1ANCH source code on Samsung's website, but all they have available right now is G900TUVU1ANCD. Two questions:
1) How long does it typically take Samsung to release the latest version of source code after the firmware has been pushed to devices (or manufactured with said version)?
2) Are there any other avenues to obtain the source code (i.e. through carrier, via leaks, per request)?
I'm looking at trying my hand at porting native Ubuntu Desktop to the S5, but I would like to start with the current/latest kernel.
FYI, one of the reasons I moved from the S4 -> S5 was because of AT&T's ridiculously locked bootloaders, making native booting to Ubuntu Desktop or Ubuntu Touch very difficult - and impossible to make an "easy" way of switching between this and Android seamlessly (i.e. via a boot menu of sorts).
Aou said:
I've been watching and waiting for the G900TUVU1ANCH source code on Samsung's website, but all they have available right now is G900TUVU1ANCD. Two questions:
1) How long does it typically take Samsung to release the latest version of source code after the firmware has been pushed to devices (or manufactured with said version)?
2) Are there any other avenues to obtain the source code (i.e. through carrier, via leaks, per request)?
I'm looking at trying my hand at porting native Ubuntu Desktop to the S5, but I would like to start with the current/latest kernel.
FYI, one of the reasons I moved from the S4 -> S5 was because of AT&T's ridiculously locked bootloaders, making native booting to Ubuntu Desktop or Ubuntu Touch very difficult - and impossible to make an "easy" way of switching between this and Android seamlessly (i.e. via a boot menu of sorts).
Click to expand...
Click to collapse
Not sure about the platform source, but the CH release appears to use the same kernel sourced in the Samsung released labeled CD. They're both (rather erroneously) tagged as kernel version 3.4.0. I used the current source to build a kernel here http://forum.xda-developers.com/showthread.php?t=2729338 which works exactly as expected. I'm guessing CH was just a baseband release at this point.
Samsung has historically been pretty timely about pushing new sources, usually within a week or so.
Good luck.
zaventh said:
Not sure about the platform source, but the CH release appears to use the same kernel sourced in the Samsung released labeled CD. They're both (rather erroneously) tagged as kernel version 3.4.0. I used the current source to build a kernel here http://forum.xda-developers.com/showthread.php?t=2729338 which works exactly as expected. I'm guessing CH was just a baseband release at this point.
Samsung has historically been pretty timely about pushing new sources, usually within a week or so.
Good luck.
Click to expand...
Click to collapse
Gotcha. If it was indeed just a baseband update or something irrelevant to the open-source parts of the firmware, then I guess there wouldn't be anything to update on Samsung's website. I'll probably stick with the *CD source and use it like you did. Thanks.
For that matter, has anyone captured the *CD -> *CH update as a .zip? Would have required root at that time to snag it, and I came into the S5 game a few days late (not sure on the sequence of events here)... In any event, if it were captured, it would tell us exactly which components were updated, and if building stuff from the *CH source is required for anything specific.
Lastly, minor updates typically don't touch the kernel, so I think you are absolutely right, @zaventh.
I just built AOSP from source for my MTK6589 phone. This is my first time building android from scratch, luckily the rom is working great. The only problem I'm having is that there are some languages missing from it (probably changed by the original author of the source code).
How do I go about re-adding these languages?
Is there a config file I can edit before building the rom?
Any help would be greatly appreciated.
If your device makefile inherits the full product you should theoretically have all available locales.
To add custom ones you could use the CUSTOM_LOCALES variable in your buildspec.mk file. Look into build/buildspec.mk.default for further details on this file.
Or you add the locales to your device's config, but I can't recall the exact variable name atm.. May you want to look into other device trees for this method. It should be something like PRODUCT_LOCALES I think.
Sent from my AOSPA One m8 using XDA Free mobile app
Thanks! I managed to fix it by editing MTK_PRODUCT_LOCALES in ProjectConfig.mk
oddhap said:
Thanks! I managed to fix it by editing MTK_PRODUCT_LOCALES in ProjectConfig.mk
Click to expand...
Click to collapse
Great to hear
Has anyone tried to put the firmware of devices from meizu, xiaomi? For example, CM 13?Supposed to work? Support scanner available from meizu , and the seams are already stable
It's not possible to do that. Any ROM that you load into a phone must be built for that particular model. Although non-stock ROMs are available for many phones, including the P9000, they are all built using the kernel (which is the bit of code that controls the hardware - device drivers, if you like) of the stock ROM supplied by the manufacturer. So you can tweak the original ROM and sometimes add new features (if you have the skill to do it, of course, it's not a simple task), but you can't just load up CM13, for instance, from a Meizu phone.
RMcT said:
It's not possible to do that. Any ROM that you load into a phone must be built for that particular model. Although non-stock ROMs are available for many phones, including the P9000, they are all built using the kernel (which is the bit of code that controls the hardware - device drivers, if you like) of the stock ROM supplied by the manufacturer. So you can tweak the original ROM and sometimes add new features (if you have the skill to do it, of course, it's not a simple task), but you can't just load up CM13, for instance, from a Meizu phone.
Click to expand...
Click to collapse
thank you for such a detailed explanation, very grateful???