[DEV] Gear S: Cyanogenmod & Android Wear Ports

Given that all the other threads were about how amazing it would be to run Android on the Gear S and I'm actually trying, I though it was time for a new thread.

Android AOSP/Wear for Gear S​

This thread has a dedicated Q&A section: http://xdaforums.com/gear-s/help/qa-gear-s-android-port-t3177751
Please post questions there!
DISCLAIMER
NOTICE: THIS IS ONLY FOR GSM VERSIONS WITH UNLOCKED BOOTLOADERS. I DON'T KNOW IF VERIZON'S CDMA VERSION WILL BE LOCKED, BUT AT&T VERSION IS, SO NONE OF THIS WILL WORK. YOU WILL GET AN AUTH FAIL IN ODIN IF YOU TRY TO FLASH IT, AND IF YOU'RE STUBBORN, YOU WILL GET A BOOTLOADER ERROR MESSAGE SAYING THE DEVICE HAS BEEN TAMPERED WITH.

Current development stage
Kernel:: Working on it. Patched framebuffer, added android modules, fixed scheduler incompatibilities with ADB building in AOSP tree. A lot of work to do
Recovery:: Recovery boots and ADB is available. The screen doesn't work correctly so it's barely usable. ADB works though
Android: Fully booting. DPI set to 200 to keep things inside the screen. Except for the apps that need a bigger screen, it's usable


Want to look at the code that makes this tick?
Kernel: kernel / samsung / pontesolo
Device Tree: Device / Samsung / pontesolo
MSM8226-Common: Device / Samsung / msm8226-common
Vendor Tree: Vendor / Samsung / Pontesolo

Main components status
Boot paths: Normal/Recovery/Charge: Charge mode is dead, others are OK
Display: Working, limited ALPM coded. Not dying, but not working as it should
Touchscreen: Working
Vibration: working
Audio: partial (Audio Out + Mic works, bluetooth headset doesn't)
Bluetooth: Working* (Internet sharing, BLE, data connections, A2DP works. HFP/HSP is NOT working -help needed!-)
Wifi: Working
GPS: Working
AGPS: Working
Baseband: Working
Sensors: Partially working (accel, gyro, magnetic, light, HRM, tilt, Palm Down, OK,Context sensor is a Work in Progress)
Power management: Partially working
Thermal control: partial


Latest Android Wear Image:
Beta #4 : [url
https://mega.nz/#!QNABnCRJ!blKdj2t7LeKh8Ro_-ZR0-aEFDfTt0dgoF3SEKol44_Q
[/url]
Post Date: July 6th, 2016
Version: Android Wear MWD48B/ Android 6.0.1
Issues:
Sensor implementation is partial, but functional for casual use
Screen Always ON not working correctly, but not dying either
Battery drain is too high (it survives a day to me, about 16hours)
Hands Free Protocol non functional
Modem unsupported by Android Wear
Most of watchfaces are a bit screwed up because the screen is not square


Latest Cyanogenmod Image:
CM12.1http://www.mediafire.com/download/tiqhu53ve5hvj64/CM_20160221_Zipped.zip
Post Date: February 21, 2016
CM Tree sync date: February 20, 2016
Version: Cyanogenmod 12.1 / Android 5.1.1
Matching Google Apps (if you don't know what to pair it with): http://www.mediafire.com/download/e35w73s81q7u8im/open_gapps-arm-5.1-nano-20150925.zip

GOING BACK TO TIZEN
BE VERY VERY CAREFUL. PROBLEMS FLASHING THE RECOVERY IMAGE MAY RENDER YOUR DEVICE IN AN ENDLESS BOOTLOOP. TO HELP AVOID THIS, CLEAN UP WATCH'S USB CONTACTS, AND THE DOCK'S POGOPLUGS BEFORE FLASHING THE IMAGE. ALSO USE A STABLE COMPUTER TO FLASH THE IMAGE.
I've rearranged the package flashing order to help mitigate the situation and have a way out in most of the situations, but given the amount of issues this watch has, be prepared for anything. Check the post below for details.
Recovery Image #2: http://www.mediafire.com/download/pu44524rv2vn9st/TizenRecovery_v2.zip

USER DATA PARTITION TEMPLATE
EMERGENCY USE ONLY! Use it if you destroy your data partition and CM/TWRP stop booting: http://www.mediafire.com/download/patgdf2gpdxzkd8/user.zip
Gear S specifications
Qualcomm MSM8226. Quadcore @ 1.2 GHz
512 Mb of RAM
4 Gb of flash, divided in 25 partitions (see below)
Adreno 305 GPU
Qualcomm MSM8226 Audio + Audience ES705
BCM4334W Bluetooth/WLAN controller
Samsung SensorHub (STM32)

Partition layout
aboot -> mmcblk0p8 --> Odin / LK Bootloader
boot -> mmcblk0p16 --> Main Kernel + DTB
csa -> mmcblk0p2 --> Watch params (IMEI, calibration data for sensors, nvram etc)
csc -> mmcblk0p22 --> Localization settings (look csc.img in flash package)
dbi -> mmcblk0p9 --> unknown
ddr -> mmcblk0p10 --> unknown
fota -> mmcblk0p1 --> self explainatory
fsc -> mmcblk0p13 --> unknown
fsg -> mmcblk0p12 --> unknown
modem -> mmcblk0p21 --> Modem firmware files
modemst1 -> mmcblk0p3 --> unknown
modemst2 -> mmcblk0p4 --> unknown
module -> mmcblk0p20 --> Linux kernel modules (mounted on /lib/modules in Tizen)
pad -> mmcblk0p15 --> unknown
param -> mmcblk0p11 --> unknown, probably modem related
ramdisk1 -> mmcblk0p18 --> boot ramdisk - unused
ramdisk2 -> mmcblk0p19 --> recovery ramdisk, unused
recovery -> mmcblk0p17 --> Recovery Kernel + DTB, unused
rootfs -> mmcblk0p25 --> Main firmware (/ on Tizen)
rpm -> mmcblk0p5 --> Part of Trusted Zone firmware - don't touch this
sbl1 -> mmcblk0p7 --> Part of the bootloader chain, don't touch this
ssd -> mmcblk0p14 --> unknown
system-data -> mmcblk0p23 --> Part of personal data, Tizen won't boot if this is corrupt
tz -> mmcblk0p6 --> Trusted Zone for ARM, don't touch this
user -> mmcblk0p24 --> User data partition (2.5 Gb +-)

There seems to be a lot of people falling into the bootloops when coming back to Tizen, so I thought I would try to explain, again, what causes it, and how I got out of them every time.

The reason for the bootloops
The reasons for falling into the bootloop is a combination of some factors:
1. The bootloader in this watch is poorly coded The bootloader resets the power key status on each reboot, unlike most of other ODIN based bootloaders, so when the watch reboots, the key gets released and then reattached.
2. The kernel panic reboot time is set to 0 on stock kernel. The kernel is configured in a way when there's a critical error (a kernel panic), it automatically reboots without spending the DEFAULT 5 second delay before rebooting
3. When moving from Android to Tizen, or from Tizen to Android, the init binary is moved from one partition to another The way I'm building this ROM, moves /sbin/init from the 25th partition (/dev/mmcblk0p25 -rootfs- ) to the 19th partition (/dev/block/mmcblk0p19 -boot-). The thing is, if you, for example, mix and run the stock tizen kernel with the Android Root FS, it will look for the init binary in partition #25 instead of #19. As it won't find it there, it will panic and reboot endlessly. That means that if Odin fails after flashing the Tizen Kernel, but *before* the rootfs, you might end up in a boot loop.

Ways I've fallen into the bootloop
When modifying boot images and not setting correct permissions and/or making mistakes in permissions in boot files. If you're playing with the boot image for Android, and you set the wrong permissions to /init or /sbin/init, or you make a big mistake inside the init.*.rc, the kernel will panic just after mounting the boot partition, forcing a reboot.
When corrupting the rootfs partition in Tizen: If you took a backup of it and it wasn't in good condition, after you restore it if the Kernel cannot correctly mount it, it will panic and reboot all the time. Since the kernel needs about 2 seconds before mounting the partition, it will panic before you have your 5 seconds to force the hard-reboot
When flash process failed at the wrong time. You're there, reflashing Tizen, and the dock misbehaves and drops the USB connection, or your PC halts, or the watch reboots (all of them happened to me at some point). The flash process fails when it's in the middle of flashing the rootfs but the Gear's bootloader doesn't notice it. The rootfs partition gets corrupt, but when you reboot the watch, instead of automatically entering download mode and showing a screen saying "There was an error, connect to Kies to recover" the watch bootloops when trying to mount the root partition.
When flashing the wrong kernel It's possible that some kernels from some firmware don't contain the needed DTB board definition for the revision of your watch. Happened to me with some older firmwares.

HOW I GOT OUT OF THEM
So, you're stuck. You're pretty much f***d up, aren't you? Let's try some things.
1. Check if you're really f****d.
Let the battery drain, so the watch will shut down completely, and let it cool down. Depending on the battery you had it might get quite warm.
Got it? Good. Clean both the dock's pogoplugs (the connector), and the charging contacts on your Gear S.
If you have a backup battery equiped dock, have it with some charge, if you don't, have a wall charger available.

YOU HAVE A BATTERY BACKED DOCK:
Connect it to the watch, without connecting the dock itself to anything. If you see the battery logo, you're good.

YOU HAVE A DUMMY DOCK:
Connect the dock to the wall adapter, then connect it to the watch. If you see the battery logo, you're good.

*IF IN ANY CASE YOU CONNECT IT TO A USB PORT ON A COMPUTER, THIS WON'T WORK* The watch will detect it's connected to a computer and will start in a different boot mode.
*IF, WITH THE BATTERY BACKED DOCK, IT GOES STRAIGHT TO THE GEAR S LOGO, I DON'T HAVE A CLUE ON WHAT YOU CAN DO, NEVER GOT INTO THAT*

Let's say it's not as f****d up as to not show the battery logo, proceed to step 2.

1. Measure the time it takes, between the moment you connect the dock/charger and the moment the screen turns on to show the battery logo. Once you have it:
2. Disconnect it and let it shut down again.
3. Connect again, and start pressing the power button JUST BEFORE THE SCREEN TURNS ON. Timing is key, and IT IS HARD TO FIND. As I said numerous time, the first time I got it, I spent about four hours trying to get it right. I finally found the exact time, but I can't measure it in miliseconds. You will need a lot of patiente. Once you've been there once, if it happens again you will get out of it faster.

WAYS WE CAN HELP AVOID THE SITUATION.

My Android images are safe. No Android firmware I've posted should leave you in a bootloop. But, depending on your bootloader, and your model, my Tizen Restore Firmware can cause you issues while flashing which might end up in a boot loop.

1. Know your device. My Tizen Restore Firmware is based off R750XXU1BOA7. This means it's designed for SM-R750 / SM-R750Z. *THIS IS THE ONLY DEVICE I HAVE TESTED WITH, WHICH IS MY OWN*. A lot of other people has restored their watches with this same firmware, but obviously, there's a bunch of people who's having issues with it.
2. Backup your system-data partition You can use others' backup, but keep in mind you're exposing your data with it. Also keep in mind that your system-data partition is tied to the Tizen release you were running at the point of backup, so it might get messy when you restore another firmware on top of it.
3. Have a known full flash that you know works for your watch . I only provided my Tizen restore package as an emergency in the early days. People shouldn't flash it blindly. You should have a good full firmware package which you *have already flashed* before even trying to flash Android, so you know you have a good set to come back.
4. Clean the USB/Charging contacts before you begin, on both the watch and the dock . This is a watch, and has constant contact with your skin. It gets dirty. Before you do something sensible as wiping the NAND and flashing something over it, do your best to ensure that the connection to the computer will be stable while it's in this process. Numerous times Odin has failed on me because of this.
5. If you find this hard to handle, you shouldn't be doing it! This watch wasn't correctly made. You need to know what you're doing and in case you have problems you will need to have the necessary knowledge to fix it. This is not your average flashing, this is not a Nexus phone. This is a buggy watch made for a different OS, and might present different issues than those you may have found playing with other watches/phones.

WE CAN MAKE TIZEN RESTORE FIRMWARE VARIANTS TO HELP OTHERS, BUT I NEED YOUR HELP.
I can make recovery firmwares for the different watch variants, but I will need you to provide me with:
* Your Watch Model
* A backup of your system-data partition (better if it's a clean backup, with the watch unpaired and the least amount of settings configured)
* A Full firmware that you know runs on your device: You can know if it's a full flash if you open the TAR package and it has at least, some of the following files:
- dzImage
- aboot.mbn
- modem.bin
- rpm.mbn
- tz.mbn
- rootfs.img

You can post them in this thread and I will do my best to package them and post them in the first post.
I WON'T ANSWER PRIVATE MESSAGES REGARDING THIS ISSUE. If you want to PM me for helping me on development related stuff, feel free to do it. If you want to thank me, it's okay. If you're going to ask me for help because you didn't read the warnings, the instructions, or didn't do your job I won't reply. You have the Q&A section for Q&A related questions, and I have explained this quite some times already. I won't tell this everytime someone f*cks up. I simply don't have time to do that, and the little time I have I'd rather use it on actually working with the watch to make it run Android better.

To the lengths Samsung will go to avoid things to be made... I have to take back what I said about the Gear S kernel being cleaner... I just patched the memory driver (arch/arm/mach-msm/memory.c), the framebuffer (drivers/video/msm/msm_fb.c) and the DTS board file (arch/arm/boot/dts) just to reclaim the framebuffer memory that was stolen and making the recovery binaries drop a segmentation fault. WHAT THE HECK.

I have fixed the framebuffer for low power mode (charging) and recovery mode!

Proof or didn't happen
I know it's not a good picture but my phone can only do so much with this light and this screen!


So, to recap:
Kernel booting? Check
Graphics? Check
Device tree? Started, a lot of work remain
Automatic building? Half.
I have a problem with the kernel building. I fixed all the errors preventing CM's build system to do the actual build, but it doesn't produce a bootable kernel. The kernel is correctly compiled, but the DTB is not created in the same way, and it occupies more space than it should, not fitting the boot image. Also, there's the mkdzimage binary problem. I decompiled it and I'm trying to rebuild it so it can be compiled from source, but not sure if I can make that...

Anyway, one step at a time

Timberwolfhusky said:

I have seen idiotic lockdownds of devices by manufacturers before...This is one of the worst.. Don't give up! Don't let them get away with keeping us from getting an unreal device
A.K.A keep up the utterly amazing work.

Click to expand...

Click to collapse

The funny thing with this stupid approach is that, to save about 1Mb of RAM only in charge mode they seem to be using the GPU in full power mode when the watch is charging or making a factory reset... I understand they use it when doing the factory reset (only time recovery mode is started in tizen), but why on earth do they need to start the entire desktop enviromment just to unzip a file (opt.zip) or to show a battery icon with a percentage? Is it worth to consume 10 times cpu power to save 1Mb of ram when the device is (or should be)... Essentially off?

Sent from my D6603 using XDA Free mobile app

Okay, TWRP is here!


It has some issues though, when the screen shuts down it doesn't come back, but at least it fits in the screen

Now I can start working on the main firmware... Wish me luck!

Sent from my D6603 using XDA Free mobile app

hackerse7en said:

OMG, you make progresses at the speed of light, is it functional? wipe mount and flash?

Click to expand...

Click to collapse

Mount & wipe yes, flash I don't know, since I don't have anything to flash

Anyway these are the easy parts, we'll see how it goes with telephony, audio, sensors...

Sent from my D6603 using XDA Free mobile app

COA4178 said:

Too bad for me

Click to expand...

Click to collapse

Sorry but RM-750A (AT&T) has the bootloader locked, which makes it impossible to replace the bundled kernel. I think that is why they are so cheap at eBay...


Sent from my Xperia Z using XDA Free mobile app