In seriousness, these debug ports are seriously lacking in most mobile chipsets. MediaTek still has the old-style approach in many of their devices, requiring some incantations which expose serial over USB, but not in the way you think -- it's serial over USB pins!
I've done tonnes of work with mobile chipsets and security and this seems like they've finally started down the road to making this functionality accessible. Don't be surprised if you don't see this supported out of the box in most places, though. Most OEMs will certainly disable this once they've adapted their bootloaders to it. The big G doesn't like debuggability in end user devices.
On Pixel devices, the UART is not configured or brought up by default in locked production mode (as things should be), but by unlocking the device and then using `fastboot oem uart enable` you can flip the bits to turn it on. On early Pixel devices it was on the headphone jack and on newer ones it's on the SBU pins.
By default I think it's still configured as the kernel console in the kernel command line, so once it's enabled it will show the kernel debug output and present a TTY. But of course you can subsequently configure it to do whatever you'd want a UART for: kgdb for kernel-debugging, earlier stuff in the bootloader, and so on.
So, the implications are just: there's a convenient debugging interface available to you that turns on if you unlock the device and ask for it.
On Chromebook devices there's a more complicated and fancy debugging system where the SBU pins can be muxed to the security processor's USB host interface by presenting a debug cable called a SuzyQ, which presents a whole suite of debugging facilities. This used to be used quite frequently for unbricking purposes.
And BTW, the SuzyQ cable is nothing more then two pull up resistors and a USB hub connected to the normal usb D+/D- pins on one port and the SBU pins on the 2nd port. Nothing fancy about it, people have even made their own (minus the hub) by soldering some wires and resistors to a usb-c breakout board. Google has also published the schematics for it:
https://www.chromium.org/chromium-os/ccd/951-00273-01_201806...
Also, the titan chip has been around since the Pixel 3 I believe, so "newer" might be a strong word :)
There's generally an entire phase of prototyping where engineers will be using production boards but still need JTAG, which is why it's fused and why these kinds of features exist. It's a lot easier to have your lower-level software team (drivers/BSP, perf, etc.) sitting with production-ready units provisioned with engineering keys and debug enabled than to have them having to use some kind of case-off JTAG header setup, cost aside.
JTAG also isn't usually exposed through enclosures, so using the probe on a field unit might require destructive entry depending on the application.
And I am not knocking JTAG over USB. It is certainly convenient and beneficial since you can enable it in production or deployed units. I was commenting on how the GP (and even article) was making it out to be missing capability. They just do not have the cheap tools that are the intended way to access that capability.
edit: The article even mentions how the "Qualcomm Landing Team at Linaro", which seems to be the team that works with pre-production hardware to get them working on launch day, has a development process where "debuggers have never been a staple of our work for all the typical reasons you'd expect (cost and complexity being the main ones)". That is literally the team that should have pre-production units in the lab which will have debug connectors and where JTAG probes should be par for the course, yet they are apparently hardly using them partly because of "cost".
Having read a lot of Qualcomm code myself, I don't envy their job.
Well, should be. I bet there've been screwups now and then...
Wasn't that only in their old feature-phone (MT62xx) SoCs? All the smartphone ones AFAIK (at least since the MT657x days) use USB CDC in their BootROM and preloader.
The ideal here is the standard approach where a user has to explicitly take some sort of action which can't be found accidentally and done without understanding the implications to activate debug mode. On Android that's tapping a specific item in the about menu way more times than you might think would be necessary. On iOS it's hooking up to a computer, then authorising the connection on the phone. Either way you get both the ability to run arbitrary(ish) software without someone picking up your device when left on a train being able to do so.
Edit: How are they reading the eFuses on a production OnePlus 6? Do they have a Qualcomm-signed EL3 EDL loader?
It seems to exist as qcom,msm-eud in the device tree of a (unfortunately production) SM4350 device I have along with an eud_enable_reg. Time to recompile the kernel with `/dev/mem`.
In the device tree I see (snippet):
qcom,msm-eud@1628000 {
compatible = "qcom,msm-eud";
interrupt-names = "eud_irq";
interrupts = <0x00 0xbd 0x04>;
reg = <0x1628000 0x2000 0x162a000 0x1000 0x3e5018 0x04>;
reg-names = "eud_base", "eud_mode_mgr2", "eud_tcsr_check_reg";
qcom,secure-eud-en;
qcom,eud-tcsr-check-enable;
status = "ok";
};
qusb@162b000 {
compatible = "qcom,qusb2phy-v2";
reg = <0x162b000 0x400 0x1b40268 0x04 0x162f014 0x04 0x162a000 0x04>;
reg-names = "qusb_phy_base", "efuse_addr", "refgen_north_bg_reg_addr", "eud_enable_reg";
qcom,efuse-bit-pos = <0x19>;
qcom,efuse-num-bits = <0x03>;
[ 433.720232] msm_watchdog f410000.qcom,wdt: Causing a QCOM Apps Watchdog bite!
[ 433.727381] msm_watchdog f410000.qcom,wdt: Wdog - STS: 0xb01a6, CTL: 0x3, BARK TIME: 0x57fdf, BITE TIME: 0x6ffd6
Feels like a weird thing to spend so much effort optimizing but neat as heck to see. https://www.phoronix.com/news/Linux-6.16-USB-Audio-Offload
How many shipping devices use USB for audio? I was under the impression that most phones/tablets/laptops support usb audio, but it is a niche/power user feature, and not the way the main device speakers are connected.
Do these same systems have bluetooth audio offload so the system can sleep for multiple minutes while a song is playing via bluetooth? (which seems to be a far more common usecase)
With 3.5mm stereo jacks gone, I do think there are some folks who use USB audio a lot now! But it also feels like it's gotta be a pretty small crowd! This sure feels like a long long way to go to give these select few a battery life boost! It'd be interesting to know how big the impact is, to at least weigh this long effort.
Like you, would love to know if there's anything cute folks have done for offloading Bluetooth! my gut says there are vastly vastly vastly more Bluetooth users.
Also, I guess there are a good bunch of devices that have audio interfaces that, internally, might be connected to the USB bus.
But I'm also thinking about sound "processing" oriented hardware that could run Linux. Sound recorders, mixers, synths, smart speakers... that could be based on an SBC or an ARM or similar processor.