This is a much better experience than the previous Qualcomm debug experience, which was a hand-rolled set of read/write/execute primitives exposed over USB. It was hilariously undersecured, allowing a few of us to continually get root on various Qualcomm models.
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.
Most of those boards have a separate physical JTAG connector (at least in development kits, this article indicates JTAG over USB is disabled in production systems anyways so no difference there) which is what they are expecting you to use for low-level debugging. It only costs like 1,000 $ for a JTAG probe which is like 1 fully-burdened engineer-day of cost. Even fully featured probes enabling hardware trace and time-travel debugging only cost like 1 engineer-week.
> Most of those boards have a separate physical JTAG connector (at least in development kits, this article indicates JTAG over USB is disabled in production systems anyways so no difference there
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.
The probes cost enough to exceed individual purchasing limits at hardware companies, which means you need to go through the requisition process. That takes long enough that you have to plan ahead and you don't order more as your needs increase. Then everyone's fighting for the limited probes right before a ship date and they get jealously guarded like priceless jewels.
JTAG also isn't usually exposed through enclosures, so using the probe on a field unit might require destructive entry depending on the application.
Well the problem there is companies who are too stupid to invest in cheap tooling with massive ROI for their developers. A pretty constant problem in software development.
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".
It's just a UART; you can use the UART to debug the device in various ways.
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.
On the newer pixel phones (starting with the ones containing the titan chip) you can also mux the SBU pins to the security chip USB interface with "fastboot oem citadel suzyq".
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:
It will be really interesting to see what production devices this is enabled on - It mentions the OnePlus 6 at least which has it fused out but is still accessible.
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`.
but `devmem 0x162A000 4 0x1` causes the system to lock up and I see the following in ramoops:
```
[ 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
```
I'm not at all sure on the interpretation of this, but the reading at the efuse_addr (so I guess certain ones can be read from EL0?) is 0x0e000000 which has bits 25-27 set and QFPROM fuses seem to have a blown value of 1 according to Qualcomm docs, so it might be fused out?
yeah EDL loaders for a bunch of production devices exist here [0] also more on various XDA Forum posts for stuff like unbricking guides. It is worth noting for people who don't
But reading QFUSES specifically requires an EL3 loader "edl qfp qfp.bin -> To dump qfprom fuses (only on EL3 loaders)" and I don't believe most devices programmers (especially as relatively new as the OnePlus 6) run under that privilege level.
So just to get this straight, Qualcomm has a piece of custom silicon, as a peripheral controlled by registers, that when enabled reroutes the ARMs USB pins through it (adding a USB hub in the middle), and on that hub it adds a SWD programmer and a serial port that connect back to the ARM core's IOs? Amazing!
This is a much better experience than the previous Qualcomm debug experience, which was a hand-rolled set of read/write/execute primitives exposed over USB. It was hilariously undersecured, allowing a few of us to continually get root on various Qualcomm models.
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.
Most of those boards have a separate physical JTAG connector (at least in development kits, this article indicates JTAG over USB is disabled in production systems anyways so no difference there) which is what they are expecting you to use for low-level debugging. It only costs like 1,000 $ for a JTAG probe which is like 1 fully-burdened engineer-day of cost. Even fully featured probes enabling hardware trace and time-travel debugging only cost like 1 engineer-week.
> Most of those boards have a separate physical JTAG connector (at least in development kits, this article indicates JTAG over USB is disabled in production systems anyways so no difference there
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.
The probes cost enough to exceed individual purchasing limits at hardware companies, which means you need to go through the requisition process. That takes long enough that you have to plan ahead and you don't order more as your needs increase. Then everyone's fighting for the limited probes right before a ship date and they get jealously guarded like priceless jewels.
JTAG also isn't usually exposed through enclosures, so using the probe on a field unit might require destructive entry depending on the application.
Well the problem there is companies who are too stupid to invest in cheap tooling with massive ROI for their developers. A pretty constant problem in software development.
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".
> this article indicates JTAG over USB is disabled in production systems anyways
Well, should be. I bet there've been screwups now and then...
Google exposes serial Serial over the SBU pins on all the Pixel devices
What are the effective implications of this?
It's just a UART; you can use the UART to debug the device in various ways.
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.
On the newer pixel phones (starting with the ones containing the titan chip) you can also mux the SBU pins to the security chip USB interface with "fastboot oem citadel suzyq".
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...
It will be really interesting to see what production devices this is enabled on - It mentions the OnePlus 6 at least which has it fused out but is still accessible.
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`.
Well, no luck.
In the device tree I see (snippet):
but `devmem 0x162A000 4 0x1` causes the system to lock up and I see the following in ramoops: ``` [ 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 ```I'm not at all sure on the interpretation of this, but the reading at the efuse_addr (so I guess certain ones can be read from EL0?) is 0x0e000000 which has bits 25-27 set and QFPROM fuses seem to have a blown value of 1 according to Qualcomm docs, so it might be fused out?
yeah EDL loaders for a bunch of production devices exist here [0] also more on various XDA Forum posts for stuff like unbricking guides. It is worth noting for people who don't
[0]: https://github.com/bkerler/Loaders
But reading QFUSES specifically requires an EL3 loader "edl qfp qfp.bin -> To dump qfprom fuses (only on EL3 loaders)" and I don't believe most devices programmers (especially as relatively new as the OnePlus 6) run under that privilege level.
So just to get this straight, Qualcomm has a piece of custom silicon, as a peripheral controlled by registers, that when enabled reroutes the ARMs USB pins through it (adding a USB hub in the middle), and on that hub it adds a SWD programmer and a serial port that connect back to the ARM core's IOs? Amazing!
Just wait until you find out about Apple's magical USB shenanigans like the Chimp Cable https://www.theiphonewiki.com/wiki/Chimp_Cable