2020年1月16日 星期四

Signal and Encoding of USB System (Part 5/6)

Source  https://www.engineersgarage.com/tutorials/signal-and-encoding-of-usb-system-part-5-6/


Signal and Encoding of USB System (Part 5/6)

In this series, USB requests and descriptors have been already discussed. With the knowledge of USB descriptors, requests, transfer types, and transactions it is now easy to understand how data is communicated over USB interface.  Another aspect of the USB communication is line states and encoding, which is generally ignored by the system designers as a USB device can be designed without knowing the Signaling and Encoding schemes. The signaling and encoding schemes are implemented at the lower levels (usually on the controller IC) and usually gets abstracted during system designing. However, understanding the terms related to bus states and encoding would help in getting a comprehensive view of the USB System.

Bus States

The Bus state refers to the signal voltage level on the USB bus or the conditions that these voltages signify -:
Differential 0 and Differential 1: The Differential 0 state refers to the condition when D+ data line is logic low and D- is logic high. The Differential 1 state occurs when D+ is logic high and D- is logic low.
Single Ended Zero: This state is also known as SE0. It occurs when both D+ and D- are logic low. The SE0 state is used by bus when entering the Disconnect, Reset and EOP (End of Packet) states.
Single Ended One: Also known as SE1. It occurs when both D+ and D- are logic high. This state can be taken as a compliment of the SE0 state. SE1 should never occur as it is an invalid bus State.
Idle: This state occurs when bus remains idle or there is no exchange of packet. For a full speed device, the voltage at D+ will be more positive than D- while for a low-speed device, the voltage at D- will be more positive than D+
Data J and Data K: Data J and K states are used to define the Data States like the Differential 0 and 1 that refers to the bus states. They are defined by Differential 0 or 1 state and the speed of the bus.

Table Listing Flip-Flop Status for Differential 0 and Differential 1 Bus States
Fig. 1: Table listing Flip-Flop Status for Differential 0 and Differential 1 Bus States

The data states are used to describe an event even when the voltages at data lines are differential. For example, a Start of Packet state exists when the bus changes from Idle to the K state.
Start of Packet: Also known as SOP. This state occurs when there is a change from Idle to K state. Every transmission of the packet begins with SOP.
End of Packet: Also known as EOP. This state occurs when SEO state occurs for two-bit times, followed by a J state for 1-bit time.
Disconnect: A downstream port at which the device is connected enters disconnect state when an SE0 state has lasted for at least 2.5 uS.
Connect:  A downstream port enters connect state when there is an Idle state for a minimum 2.5 uS and not more than 2 mS

Some Other States and Signals

Keep Alive Signal: This signal is represented by a low-speed EOP. The main motive of this signal is to keep the device in an idle state. This signal is sent at least once every millisecond, to keep the device from entering suspend state.
Suspend State: The device enters Suspend state when there is no exchange of packet or the bus remains idle for 3 mS. This state has been incorporated in USB for power conservation. In Suspended state, the device must not draw more than 500 uA of current. A suspended device must recognize the reset and resume signal.
Resume:  Resume signal is used to wake the device from Suspend state. The Host wakes the device from suspend state by keeping the bus in K state for at least 20 ms followed by a low-speed EOP.
Reset State: A device enters Reset state if SE0 is applied for more than 2.5 uS. The reset sets the device to its default unconfigured state.
Detached State: This state occurs when the USB device is detached from the Host. In this state, the Host sees both data lines low.
Attached State: This state occurs when the USB device is attached to the Host. The host recognizes this state if it sees either D+ or D- high.
Table Listing Conditions for USB Bus States
  Fig. 2: Table listing conditions for USB Bus States

 

Signal Diagram for Different USB Bus States
 Fig. 3: Signal Diagram for different USB Bus States

Speed Identification

In USB System, the operating speed of the device is detected by checking which data line is pulled up. The data line is pulled up to 3.3V derived from voltage line. Normally, 1.5-kilo ohm resistor is used for a pull-up.
For Low speed, D- data line is pulled up. While for full speed, D+ data line is pulled up.  High-speed devices are initially detected as full speed devices.

Encoding Scheme

The USB employs NRZI (Non Return to Zero Inversion) encoding mechanism to encode the data on the bus. In NRZI encoding, a ‘1’ is represented by no change in level while a ‘0’ is represented by change in level. Together with NRZI encoding, bit stiffing and SYNC field is used for synchronization between host and device.
Signal Diagram Illustrating Non Return to Zero Inversion (NRZI) Encoding Scheme
Fig. 4: Signal Diagram illustrating Non Return to Zero Inversion (NRZI) Encoding Scheme

Bit stiffing

When long series of zeros are transmitted using NRZI, it causes a transition in the levels. But when long series of one’s is transmitted, no transition takes place as per NRZI encoding scheme. No transition in levels for a long time can confuse the receiver and makes it desynchronized.
Bit stiffing is a process in which a zero is inserted in raw data after every six consecutive ones. The inserting of zero causes transition in level. The receiver must recognize the stuffed bits and discard them after decoding the NRZI data.
In case if no transition takes place in NRZI signal after six consecutive one’s, then the receiver decides that bit stiffing has not been done and discards the data received.
Signal Diagram showing Bit Shifting in Non Return to Zero Inversion (NRZI) Encoding Scheme
 Fig. 5: Signal Diagram showing Bit Shifting in Non Return to Zero Inversion (NRZI) Encoding Scheme 

SYNC field

The bit stiffing alone is not enough to take care of the synchronization between transmitter and receiver. To keep transmitter and receiver synchronized, SYNC field is used. In this mechanism, each packet begins with a SYNC field which enables the receiver to synchronize the clock
For low/full speed, SYNC field is of 8 bits: KJKJKJKK. The first k serves as Start of Packet. For high speed, SYNC field is of 32 bits: fifteen KJ repetitions, followed by KK. The alternate Ks and Js provide transitions for synchronizing and the final two KKs mark the end of SYNC field.

End of Packet

The End of Packet that is SE0 for 2-bit times followed by J state for 1-bit time marks the end of packet.
This is all needed to know about the signal and encoding schemes implemented in the USB system. In the final part of the series, selection of a controller chip for developing USB enabled custom devices is discussed.

2020年1月3日 星期五

Andriod version, API level, and Linux version

Source https://android.stackexchange.com/questions/51651/which-android-runs-which-linux-kernel

Linux version in AOSP

    Android Version    |API Level  |Linux Version in AOSP                    |Header Version
    ----------------------------------------------------------------------------------------
    1.5   Cupcake      |3          |(2.6.27)                                 |
    1.6   Donut        |4          |(2.6.29)                                 |2.6.18
    2.0/1 Eclair       |5-7        |(2.6.29)                                 |2.6.18
    2.2.x Froyo        |8          |(2.6.32)                                 |2.6.18
    2.3.x Gingerbread  |9, 10      |(2.6.35)                                 |2.6.18
    3.x.x Honeycomb    |11-13      |(2.6.36)                                 |2.6.18
    4.0.x Ice Cream San|14, 15     |(3.0.1)                                  |2.6.18
    4.1.x Jelly Bean   |16         |(3.0.31)                                 |2.6.18
    4.2.x Jelly Bean   |17         |(3.4.0)                                  |2.6.18
    4.3   Jelly Bean   |18         |(3.4.39)                                 |2.6.18
    4.4   Kit Kat      |19, 20     |(3.10)                                   |2.6.18
    5.x   Lollipop     |21, 22     |(3.16.1)                                 |3.14.0
    6.0   Marshmallow  |23         |(3.18.10)                                |3.18.10
    7.0   Nougat       |24         | 3.18.48 4.4.0                           |4.4.1
    7.1   Nougat       |25         | ?                                       |4.4.1
    8.0   Oreo         |26         | 3.18.72 4.4.83  4.9.44                  |4.10.0
    8.1   Oreo         |27         | 3.18.70 4.4.88  4.9.56                  |4.10.0
    9.0   Pie          |28         |         4.4.146 4.9.118 4.14.61         |4.15.0
   10.0   Q            |29         |                 4.9.191 4.14.142 4.19.71|5.0.3
Table compiled from:
Note: other “distributions” of Android might run different kernel versions.
Anyone is welcome to correct and expand this table. Please keep formatting.

Why Android OS/kernel version mismatches

OEMs tend to ship their major Android updates with a similar kernel to the one the device was initially released with. This is most likely to avoid hardware and driver incompatibility issues with a newer kernel. For example, a device that has been updated to run Android 8.0 Oreo but originally shipped with 6.0 Marshmallow may still be running Linux 3.18.x instead of Linux 4.10.x.

Vendor Test Suite (VTS) requirements on Linux version

According to a 2017 article on XDA-Developers (shortened):
One aspect that has been up to the OEM is the Linux kernel version but this is changing with Android Oreo.
As long as the OEM was able to pass the certification tests that Google lays out, then they didn’t care what kernel version was used in a new device. This generally wasn’t an issue as most OEMs would use the same version of the kernel for that generation that other OEMs were using, as it is tied heavily to what the hardware drivers support. However, some had been falling through the cracks and this started to cause security issues. This is something that Google has been taking seriously lately so it makes sense that they would want to start mandating this.
Starting this year with smartphones which ship with Android Oreo, Google is requiring that all SoCs productized in 2017 must launch with kernel 4.4 or newer.
Currently existing devices that are upgraded to Android Oreo are only required to run kernel version 3.18 or newer, and will not have to be upgraded to support Project Treble.
According to https://android.googlesource.com/platform/test/vts-testcase/kernel/, there was a requirement on the Linux version, VtsKernelConfigTest or VtsKernelVersionTest, on 8.0, 8.1, and 9.0, but later removed on 10.0. For 8.0 and 8.1, it requires the version to be either 3.18, 4.4, or 4.9. For 9.0, it requires the version to be at least 4.4.107, 4.9.84, or 4.14.42.
More technical and recent information available directly from the AOSP website: https://source.android.com/devices/architecture/kernel/core-kernel-reqs