[Samsung Gear S] biktor_gj:
All the small things

TL;DR

I'm alive and well, nothing else besides what I alredy stated is working, unless someone else has made some progress which I don't know

Long version:

Besides my obvious lack of time lately (Gear2 users are suffering from it too, it's not only you ;)) I've spent all the time I could on both watches. I have a million problems to solve and only tiny bits of time, so I don't move as fast as I'd wish. Samsung's GPL violation on the kernel doesn't make things easier, but well, I think I'm slowly making a bit of progress.

All my attempts on downgrading or migrating the kernel have failed. It was a long shot, I had to try, but it doesn't want to boot. Given the strange way Odin bootloader works on this device, I'm not even suprised. There's some random kernel fault at boot that doesn't even get logged in persistent memory, so I abandoned that idea entirely.

We're stuck with our kernel, now what?

We work with what we have. Samsung is in GPL violation by releasing:

1. A kernel source that isn't working in production

2. The kernel configuration used in the source DOES NOT match the one used by the released kernels

3. The provided kernel sources fail on display rendering on Tizen, and create artifacts and malfunctions in Android, so it doesn't really work in any case. The display panel driver works, at least, so we got that going well ;)

Given that we can accept this watch as dead for Samsung since the announcment of the S2, I don't expect any new kernel releases from them. You can try and ask if you want!

How's the rest going?

I've been working in three things. None of them work, but at least I got an idea on how it's supposed to work.

Bluetooth: With everything set in place, the bluetooth module is powered up. It correctly loads the firmware and starts, both user and kernel side. Unfortunately, the UART doesn't transmit or receive. I think this is caused by the modem not starting.

Wireless: I got to the same point as bluetooth. I can turn it on, it pushes both the firmware and the calibration data to the module, and starts. But the interface doesn't come up. Didn't try much more since it's probably Qmux related too.

Qualcomm Modem: Here comes the nightmare.

Wait a second while I grab a logcat...

Aaand I'm back. Let's start with the basics. The modem is a conglomerate of drivers, patches, firmware and binary libraries, all scattered across android/tizen, all of them linked toghether by some insane procedures.

We have:

Kernel:

Qdsp6v2 ADSP driver: Part of the MSM audio subsystem. It communicates with audio and the modem

Qdsp6v2 APR (uses version 2): Part of the above

MSM IPC Router: InterProcess Communication for the modem

PIL: Peripheral Image Loader, used to push the firmware to different parts of the MSM chipset (Venus=GPU, ADSP=Sound, MBA+MODEM=Modem)

SMD: I think it means Shared Management Driver. It's what puts stuff in /dev/smd* and through which other components communicate. More on that later.

QMI Interface: The QMI interface is what's been used by the QMI libraries (more on that later)

/drivers/base/dd: In *THIS* kernel (only our kernel does this from all the msm kernels I've seen) this driver gets called repeatedly to force a reprobe of the adsp/audio drivers during the kernel boot process. Why? Probably because something crashed and they didn't want to look up what the h*** was going on in there)

/drivers/char/smd_pkt: SMD packet driver. More on that later ;)

/sound/soc/msm: Various sound drivers, most importantly, there's the QDSP6 audio (tapan) driver here.

Android:

Qmuxd: Acts as a proxy for communication between all those devices

/system/etc/*.acdb: These files are calibration data for the audio mixer inputs and outputs

/system/vendor/lib/*acdbloader* : What makes those calibration files get pushed into the DSP with the help of the rest of the audio libraries

/system/vendor/lib/libqmi*: The QMI interface libraries. This are used by the RIL Daemon to start the modem communication. Whereas the RILD in tizen seems to be called "data-router" (you can look it up at /usr/bin where it lives, along with qmuxd), on Android this daemon is directly responsible for all modem actions.

Aaand I got tired of describing everything.

To get to the point a little bit faster, we start the watch:

<6>[ 0.000000] Booting Linux on physical CPU 0

The kernel boots the ADSP and GPU:

<6>[ 0.442225] pil-q6v5-lpass fe200000.qcom,lpass: using secure boot

<6>[ 0.447084] pil_venus fdce0000.qcom,venus: using secure boot

We push the firmware:

<6>[ 2.973380] pil-q6v5-lpass fe200000.qcom,lpass: adsp: relocate start=0d800000, end=0ec00000

<6>[ 2.973430] pil-q6v5-lpass fe200000.qcom,lpass: adsp: loading from 0x0d800000 to 0x0ec00000

<6>[ 3.342148] pil-q6v5-lpass fe200000.qcom,lpass: adsp: Brought out of reset

<6>[ 3.443937] pil-q6v5-lpass fe200000.qcom,lpass: adsp: Power/Clock ready interrupt received

After some seconds, the ADSP tells us is alive and well:

<6>[ 3.468101] adsp-loader qcom,msm-adsp-loader.42: adsp_loader_do: Q6/ADSP image is loaded

Which we corroborate later with this beautiful message:

<6>[ 3.473018] apr_tal:Q6 Is Up

A lot of stuff later, we decide to push the kernel firmware in place:

<6>[ 169.557033] pil-q6v5-mss fc880000.qcom,mss: mba: non-relocate start=0c300000, end=0c33a000

<6>[ 169.557121] pil-q6v5-mss fc880000.qcom,mss: mba: loading from 0x0c300000 to 0x0c33a000

<6>[ 169.614568] pil-q6v5-mss fc880000.qcom,mss: mba: Brought out of reset

<6>[ 169.768397] pil-q6v5-mss fc880000.qcom,mss: modem: non-relocate start=08400000, end=0b300000

<6>[ 169.768526] pil-q6v5-mss fc880000.qcom,mss: modem: loading from 0x08400000 to 0x0b300000

<6>[ 170.608862] pil-q6v5-mss fc880000.qcom,mss: modem: Brought out of reset

<3>[ 170.660659] Notify: smsm init

<6>[ 170.689389] pil-q6v5-mss fc880000.qcom,mss: mba: Power/Clock ready interrupt received

<6>[ 170.689452] pil-q6v5-mss fc880000.qcom,mss: Subsystem error monitoring/handling services are up

<3>[ 170.689725] [QCTK-ANDERSON][driver_deferred_probe_trigger] queue deferred_probe_work

That QCTK-ANDERSON thing? That's the driver reprobe I was talking about earlier, the hack that does not exist in any other Qualcomm kernel .Thank you Samsung for your engineering work. Ahem, let's keep on.

Okay, DSP? Check. System initialized? Check. QmuxD is running? Check, Modem initialized? Check. Now we wait for about 3-5 seconds and the APR driver should respond this:

[ 8.170567] apr_tal:Modem Is Up

But what do we get in return?

<3>[ 190.684111] smd_pkt_open: wait on smd_pkt_dev id:0 allocation failed rc:-110

This. This is the error. This is where the Modem is apparently booting but not responding to the SMD interface.

As the people at Qualcomm thought of everything, we have a timer for the modem to start. Since the modem doesn't respond after starting, the kernel does what it's told:

<3>[ 210.717351] SMSM: Modem SMSM state changed to SMSM_RESET.

<3>[ 210.717440] Fatal error on the modem.

<3>[ 210.717473] modem subsystem failure reason: dog.c:1492:Watchdog detects stalled initialization.

<6>[ 210.717524] subsys-restart: subsystem_restart_dev(): Restart sequence requested for modem, restart_level = SYSTEM.

<0>[ 210.717585] Kernel panic - not syncing: modem crashed: subsys-restart: Resetting the SoC.

I have been able to provoke the same in tizen, removing one specific file: qmi_csi.so

I don't quite know what this particular library does, but makes the SMSM driver on the kernel create the same fault. I have pushed the qmi_csi library from Tizen (it also has one) and I didn't get any different behaviour. There's something I must be missing, I'm sure, but I guess everytime I fail, I get a little closer to make it work.

Maybe someone reads this and gets some inspiration too ;)