Profile cover photo
Profile photo
Alexander Tarasikov
Alexander's posts

Post has attachment
running without an ARM and a leg: Windows Mobile in QEMU
Introduction. One project I had in mind long time ago was getting Windows Mobile to run in QEMU. I think it's a lovely OS with a long history and the project seemed like a nice tecnhical challenge. Initially I started working on it two years ago back in 201...

Post has attachment
Trying out and debugging Open-Source OpenCL on AMD Radeon RX480
Introduction. I have decided to check out the state of OpenCL support for AMD GPUs in Linux Open-Source stack. In this post I will describe the experience of debugging issues across the whole stack trying to get a few basic apps up and running. I have the A...

Post has attachment
Fuzzing Vulkans, how do they work?
Introduction Disclaimer: I have not yet fully read the specs on SPIR-V or Vulkan. I decided to find out how hard it is to crash code working with SPIR-V. Initially I wanted to crash the actual GPU drivers but for a start I decided to experiment with GLSLang...

Post has attachment
Noted on firmware and tools
Introduction. In this blog post I mainly want to summarize my latest experiments at using clang's static analyzer and some thoughts on what could be further done at the analyzer, and open-source software quality in general. It's mostly some notes I've decid...

Post has attachment
On GPU ISAs and hacking
Recently I've been reading several interesting posts on hacking Windows OpenGL drivers to exploit the " GL_ARB_get_program_binary" extension to access raw GPU instructions. "Hacking GCN via OpenGL" by Tomasz Stachowiak ( @h3r2tic ) - Presentation on OneDriv...

Post has attachment
Abusing QEMU and mmap() or Poor Man's PCI Pass-Through
The problem. Another tale from the endless firmware endeavours. The other day I ended up in a weird situation. I was locked in a room with three firmwares - one of them was built by myself from source, while the other two came in binary form from the vendor...

Post has shared content
USB Type C’s Configuration Channel

I’ve been getting questions about why certain kinds of USB adapters or cables work to charge new Type-C devices, and why other adapters are necessary to charge legacy devices from Type-C chargers.

This post will explain why, and will do a deeper dive into Type-C’s Configuration Channel (CC).

USB Type-A and Type-B
But first, I will start out with a description of how USB worked before Type-C so that we all understand some of the basic concepts.

USB cables are directional, meaning that each end of a cable has physically different plug: Type-A plug (the rectangular port and plug we find on our PCs, hubs, and chargers), and a Type-B plug (the squareish plug, or the smaller mini-B and much more common micro-B variants).

USB systems always form a tree based structure with a single USB host at the root (typically your PC), and one or more devices as leaves. USB was designed this way for simplicity. Hubs always have exactly one Type-B port and one or more Type-A ports. Devices by definition only have one Type-B port. Type-A plugs always plug into something that is closer to the root, or in other words Type-A plugs point “upstream.” Type-B plugs always plug into something that is further away from the root, or in other words Type-B plugs point “downstream.”

This architecture prevents problematic loops that are possible with other systems that have the non-directional cables, for example, Ethernet. A user simply cannot set up an incorrect USB tree by virtue of the physically different plugs and connectors.

Enter Type-C and CC
Type-C does not just replace one of the two classic USB connectors. It replaces both A and B types, making completely symmetrical and reversible Type-C cables possible. This does beg the question though: Does this mean that since the connectors and the plugs are physically identical that the tree structure of USB is no longer enforced?

The answer is no. USB Type-C systems still maintain the same tree structure as before with one USB host and one or many USB devices. Instead of a physically different connector and plug to signify the direction of data and power, USB Type-C devices now indicate their roles electrically through a brand new mechanism: the Communication Channel or CC.

Each USB Type-C port has 2 CC pins, oriented in such a way that when you flip the cable over the the CC pins in the cable plug always land on one of the two CC pins.

The new USB specification defines a new set of terminology to represent different ports, now that both types of ports are now share the same formfactor:
* “Type-A” ports become Downstream Facing Ports (DFP)
* “Type-B” ports become Upstream Facing Ports (UFP)

A resistor is placed on CC to mark whether a Type-C port is a DFP or a UFP:
* DFP uses an Rp, or a pull-up resistor between CC and Vbus
* UFP uses an Rd, or a pull-down resistor between CC and Vbus

When a DFP (usb host) is connected to a UFP (usb device) by means of a cable, the CC on both sides are connected together, and the shared CC line has both a pull-up and a pull-down on it. Both sides read the voltage on this line and can recognize that a connection has just been made when the voltage becomes a predictable value.

There’s more! The CC lines are also how Type-C implements connector “flip”ability or cable twist. Remember I noted that there are actually 2 CC lines in the Type-C cable that happened to line up such that each CC on the plug side will always line up with a CC in the connector. By monitoring the voltage on both CCs, a host or device can figure out which orientation the cable is in and route the other wires appropriately.

Legacy cables and adapters
CC works great when you have all Type-C cables and ports, but Type-A hosts and Type-B devices will still exist. Type-A and Type-B ports and plugs do not have the new CC line, but what happens when you try to connect a Type-A host or Type-B device to a Type-C host/device?

The cables and adapters themselves must provide the proper CC pullup or pulldown in lieu of the Type-A or Type-B port that is missing the CC pin. Here are the two classes of cables :

* Legacy Host Port Adapter - Standard-A plug or Micro-B receptacle on one end - Requires a 56kΩ pullup from CC to Vbus
* Legacy Device Port Adapter - Micro-B plug, or Standard-A receptacle, or Standard B plug on one end - Requires a 5.1kΩ pulldown from CC to Gnd.

Many people ask me if “OTG” adapters are allowed in USB Type-C, and the answer I always give is that “OTG”, an older USB standard that allowed for devices to swap roles, doesn’t apply to USB Type-C, and that the adapter they are probably looking for is the Legacy Device Port adapter above that goes to a Standard-A receptacle for a USB flash drive, for example.

An example of a Legacy Host Port adapter for sale is this A-to-C cable from Google:
An example of a Legacy Device Port adapter for sale is this A-port-to-C adapter from Google:
So, the Type-C legacy cables that you can buy on the market today have (or at least are supposed to have) the correct resistor such that their roles are always fixed.

*On Legacy Host Port Adapters, power and data always flow toward the Type-C plug.
*On Legacy Device Port Adapters, power and data always flow from the Type-C plug.

This also answers the question that some have asked why they can’t simply chain together a clever series of adapters and non-compliant cables and hope it will charge their phone.

This leads to the topic that I’ve been quite vocal about in my Amazon reviews, which is power. The original USB port provided 500mA at 5V, or 2.5W of power. Ever since USB micro-B became the near universal standard for cell phone and other handheld device charging (thanks, Europe!) there’s been an arms race to increase the power that a USB charger or port can provide over the same wire to a device.

In the past decade, the USB-IF and other 3rd parties (most notably Apple) have responded by creating protocols that allow for chargers to deliver higher currents over the same wire to supported devices. They do this by signaling over USB’s data lines (D+ and D-). Chargers that support USB’s Battery Charging 1.2 specification may support up to 1.5A, while Apple’s protocols allow for 1A, 2A, and 2.4A levels.

With the USB Type-C specification, the requirements are beefed up so that every cable must be able to support 3A, however, that doesn’t mean that 3A is possible in every situation : the charger or power source must still be able to provide it, which is where CC comes in.

Remember before that every DFP (Downstream Facing Port or Host port) must use an Rp to identify itself as a DFP. The USB Type-C specification actually uses different values of resistance of Rp in order to allow the DFP to advertise its supply capabilities:

* Default USB Power - 56kΩ pullup
* 1.5A - 22kΩ pullup
* 3.0A - 10kΩ pullup

The bottom two modes are only allowed on non-legacy USB Type-C ports and cables, and only if the power supply has satisfied the electrical requirements to meet a 1.5A or 3.0A load. Under no circumstances may Legacy cables use 1.5A or 3.0A advertisements.

Legacy cables must use “Default USB Power” which at a minimum, means that it restricts it to 500mA for USB 2.0 or 900mA for USB 3.1. However, “Default USB Power” still allows for the negotiation on USB’s data lines D+ and D- using all of the protocols that would have worked on USB A-to-Micro-B cables, meaning that a Default USB Power legacy cable should be able to provide from 500mA to 2.4A of charging.

The specification allows a Type-C DFP power source to actually modify the Rp value in response to changing conditions.

For example, a 3A charger may be built with two USB Type-C ports. When one device is plugged in, it should advertise to that device a 10kΩ pullup to tell it that it can draw 3A. When a second Type-C device arrives, the charger can change the Rp on the first port to 22kΩ to tell it that it can only draw 1.5A. The second port may also be given a 22kΩ Rp, balancing the loads evenly across both ports.

When one of the devices is detached, the charger could even recognize that it's back down to 1 consumer, and give that port back its 10kΩ pullup, allowing it to draw 3A again.

Conclusion and Much More
USB Type-C’s configuration channel provides a ton of functionality. To summarize :
* Determines role, Host Vs. Device
* Determines when devices are attached to host
* Determines orientation, allowing for Type-C’s “flipability”
* Negotiates up to 3A power between charger and device.

There’s actually MUCH more that CC does, specifically, the configuration channel is integral for USB Power Delivery, a protocol that allows for much more robust, flexible and complex communication between both sides, and for Alternate Mode too…

Just as a preview for next time, CC, PD, and Alt Mode allow for :
 *Negotiated higher voltage and current, up to 20V, 5A for 100W of power
 * Power role switching, so your hub powers your laptop, instead of the other way around
 * Data role switching
 * Alt mode, so you can use your USB cable to display video, or much much more.

See you next time!

#USB   #TypeC   #USBC

Post has attachment
Porting legacy RTOS software to a custom OS.
So lately I've been working on porting a large-sized application from a well-known RTOS to a custom kernel. The RTOS is VxWorks and the application is a router firmware. Unfortunately I will not be able to share any code of the porting layer. I'll just brie...

Post has attachment
on making a DDE kit, kinda
So I have this task of porting a huge piece of software running on a proprietary OS to another OS.

And I don't even have a clue how to compile it (well I do but it builds on windows so it's almost irrelevant). But luckily all code is linked into a single ...

Post has attachment
GCOV is amazing yet undocumented
One useful technique for maintaining software quality is code coverage. While routinely used by high-level developers it is completely forgotten by many C hackers, especially when it comes to kernel. In fact, Linux is the only kernel which supports being co...
Wait while more posts are being loaded