Details

Published: Wednesday, 06 November 2019 02:50

Hits: 4288

X window system (X11 or X, but not X windows) is a windowing system for bitmap displays. X provides basic framework for a GUI env: drawing and moving windows on the display device and interacting with mouse and keyboard. It originated at MIT in 1984. XFree86 is the implementation of X that was used on all Linux computers until mid 2000. However due to change in it's license terms, a fork was created and development moved on to X.org. The first version, X11R6.7.0, was forked from XFree86 version 4.4 RC2. X.org foundation leads this project as of today, and almost all Linux OS have moved on to X.org. It's available as open source under MIT license.

Official website: https://www.x.org/wiki/

Older defunct website for xfree86 (not supported anymore, so do not use this website): http://www.xfree86.org/

good intro here: http://linuxdocs.org/HOWTOs/XWindow-Overview-HOWTO/index.html

other detailed link here: http://www.linux-tutorial.info/modules.php?name=MContent&pageid=98

X uses client/server model. Usually, the local computer runs X server program. X server interactes with hardware, it takes i/p from mouse/keyboard and displays on the monitor. Programs such as Xterm, browser, etc are called X clients. X server communicates with various client programs. The server accepts requests for graphical output (windows) and sends back user input (from keyboard, mouse, or touchscreen). X clients don't interact with hardware directly. This way X clients need not worry about h/w, they just follow the protocol to interact with X server, and the X server handles the actual process of interacting with h/w.

X provides the library, Xlib, which handles all low-level client-server communication tasks. The client has to invoke functions contained within Xlib to get work done.

Windows manager (WM):

A window manager is a "meta-client", whose most basic mission is to manage other clients. The WM program decides where to place windows, gives mechanisms for users to control the windows' appearance, position and size, and usually provides "decorations" like window titles, frames and buttons, that give us control over the windows themselves. X window system provides policy but not implementation of that policy. This is handled by window managers. The most basic WM is twm, ad other more fancy ones are fluxbox, Xfce4, etc. These WM have toolkits or widget library. Using Xlib functions directly is pretty tedious, so libraries were developed thru which we could control widgets like menus, buttons, scroll bars, canvas, etc, much more easily. One of the earliest toolkits developed was Motif. However, Motif wasn't free, so alternatives were developed. One such very popular alternative was Gtk (aka GNU tool kit, or GIMP tool kit). Another very popular toolkit used in KDE was Qt.

Desktop Environment (DE):

Since there are hundreds of different toolkits and they all have different looks and behaviour, applications developed using different toolkits will look dihttps://www.computerhope.com/unix/startx.htmff even when lauched on same computer. Even the way of launching pgms vary from one wm to another(i.e on some we may have to type cmd, while some may have gui to launch, etc). DE provides a set of facilities and guidelines aiming to standardizing all this stuff. Under Linux, 2 most popular DE are KDE and GNOME. KDE has kwm as it's WM (which is mandated by KDE), but GNOME allows any WM (although it's preferred WM is sawfish). GNOME uses the Gtk toolkit, and provides a set of higher-level functions and facilities through the gnome-libs set of libraries. The whole idea of a desktop environment is consistency, so all apps developed for one DE, would look and feel the same (i.e scrolling, left/right clicks, etc). However, we are completely free to run apps developed for KDE on GNOME or vice versa, they would just look different compared to other apps.

GUI startup:

Assuming we have GNOME DE, this is what happens on powerup. As explained in Linux installation, after powerup and succesful login, xinit is called for GUI desktops. Even the login i/f may be GUI (instead of text login i/f as found in older versions of Linux) which is managed by Display manager (dm). Here, dm starts the X server. When a Linux system starts X, the X server comes up and initializes the graphic device, waiting for requests from clients. First a program called gnome-session starts, and sets up the working session. A session includes things such as applications I always open, their on-screen positions, and such. Next, the panel gets started. The panel appears at the bottom (usually) and it's sort of a dashboard for the windowing environment. It will let us launch programs, see which ones are running, and otherwise control the working environment. Next, the window manager comes up. Since we're using GNOME, it could be any of several different window managers, but in this case we'll assume we're running Sawfish. Finally, the file manager comes up (gmc or Nautilus). The file manager handles presentation of the desktop icons (the ones that appear directly on the desktop). At this point my GNOME environment is ready to work.

Files:

X server executable is at /usr/bin/X. This is the original X server executable from MIT, but due to license issues, Xorg was forked from X, and it's executable is at /usr/bin/Xorg. Xorg is what is run as X Window system server executable, X is just for compatibility, and it eventually passes cmds to Xorg. (on my centOS system, X is just a softlink to Xorg). However, we never call Xorg executable directly to start X window system server, instead we call a script "startx".

startx => On a text only terminal, X server doesn't start automatically. The wrapper script "startx" can be typed on the text terminal to start X server. The startx script is a front end to xinit that provides a somewhat nicer user interface for running a single session of the X Window System. More details here: https://www.computerhope.com/unix/startx.htm

DISPLAY environment variable:

X server and X client need not be running on same computer. They can be on two computers. X client interacts with X server using TCP protocol via Port 6000 or higher, when they are on diff m/c. An env variable "DISPLAY" is used by X client to to find out where the X display server is (so that the client can interact with he user) and which screen it should use by default (on displays with multiple monitors). X client just sends it's display data to X server, and then X server displays it based on what display is connected to it, and what display the X client has asked it to use.

X server manages the display. A display consists (simplified) of:

• a keyboard,
• a mouse
• and a screen.

DISPLAY environment var indicates to graphical clients which display server (I/O devices) to connect to. It can be set to aanything desired by user.

The display var is of the form

hostname:D.S

where:

hostname is the name of the computer where the X display server runs. An omitted hostname means the localhost. So, if we provide a name/addr here, that means X server is located at this IP addr.

D is a Display number (usually 0). It can be varied if there are multiple displays connected to one computer. TCP port used for Display 0 is 6000, Display 1 is 6001 and so on. The phrase "display" is usually used to refer to collection of monitors that share a common keyboard and pointer. Most workstations tend to only have one keyboard, and therefore, only one display with display number 0. Display number is required. When we connect via vnc to a remote m/c, it allows us to open connections to separate multiple displays as mc1.abc.com:0, mc1.abc.com:1, and so on. So, if 5 users are going to connect to a m/c via vnc, vnc can open connections to same m/c with 5 different displays, so that all 5 users can have their own display, even though all their pgms are running on same m/c on same cpu. These are virtual displays and Linux gui is displayed on each of these virtual displays independently.

S is the screen number. A display can actually have multiple screens. The phrase "screen" refers to physical monitors that share the same keyboard and mouse. So, on a system with 2 monitors, screen can take 2 values 0 or 1. Usually there's only one screen though where 0 is the default.

ex: echo $DISPLAY => returns :0 on my m/c by default. This means display is set to localhost, display 0, and screen 0 (since screen is omitted, it defaults to 0). Any X client, before connecting to X server, reads this var, and figures out where X display server is, that it's supposed to connect to. Here, it says it is connecting to X server on local computer. It connects to X server on local m/c, and asks it to display the data it's sending to display number 0.

We can set DISPLAY var to any value we want, and in that shell, X clients launched will talk to X server indicated by the var.

In BASH shell, we set any env var using export:

ex: export DISPLAY=abc.com:0.0 => This makes any X client connect to X server on abc.com. This communication b/w X client and X server will be made over TCP on port 6000. Running a X client as "firefox" will connect to X server on computer named abc.com. Display and Screen used are 0. So, firefox window will end up showing on display connected to X server on abc.com. However, most of the times, computer abc.com won't allow just any computer to connect to it's X display server. So, we'll get an error as "Error: cannot open display: abc.com:0.0".

In Csh, we set any env var using setenv:

ex: setenv DISPLAY abc.com:0.0

Many Xclients allow them to specify Xserver to connect to via cmdline.

ex: xterm -display :0 => this opens new xterm window on local X server, display 0. Basically, xterm opens locally on same display as where you ran this cmd.

ex: xterm -display :1 => This will error out: "Can't open display: :1". This is because there is no display 1

Virtual display:

The question that comes to mind is how do we get multiple displays on a given computer. These multiple displays are called "virtual display".. Any Linux OS has 6 virtual display from 0 to 5. It's explained below under tty section,

TTY:

If we set multi-user.target (look in systemctl section for more details) as default target, then system will start in CLI. (cmd line i/f) Any Linux system starts multiple TTY sessions at boot up. Each TTY session can be thought of a copy of OS running. Most Linux OS install 7 TTY session by default. CentOS has 6 tty, while Linux Mint has 7. TTY stands for  Tele Type, an old piece of equipment which allowed typing, which would appear on typed paper and then on pressing <ENTER>that was sent to computer and then the response would be typed back on the same piece of paper. On modern computers, cmd environment (whether CLI or GUI,) is called a TTY or specifically a PTTY (Pseudo TTY). A TTY session is the environment you are in while interacting with your computer. We use mouse, keyboard to enter inputs, but we can use virtual terminals (i.e "xterm" etc) to enter inputs (which eventually get their inputs from mouse/keyboard) and send it to processes that need it. That psuedo terminal that sends cmds to processes constitutes a TTY session.

So, these 7 (or 6 for some distro) different TTY session can be used to log into by 7 different users at same time. They are useful during debug too. These 7 TTY sessions are rep by device special files /dev/tty1 thru /dev/tty7. Of these 7 sessions (or 6 in CentOS), all but one start in CLI mode. In Linux Mint, the 7th session is the default session that is presented to the user as login screen. It can be CLI or GUI depending on whether we are in multi-user target or graphical target. These 7 TTY sessions can be entered by pressing Ctrl + Alt + F1 (for 1st tty) to Ctrl + Alt + F7 (for 7th tty). In CentOS, the first tty session (tty1) is the default session, and it has only 6 tty sessions from tty1 thru tty6. On any Linux distro, one of these many tty will be the default terminal (GUI or CLI), while remaining ones will be CLI terminal. Ctrl + Alt +F1 takes to tty1 session, while Ctrl + Alt + F7 takes to tty7 session. Which of these is default depends on OS distro.

We login to default CLI/GUI TTY session. However, we can login to other CLI TTY sessions too. We just have to press "Ctrl+Alt+F2" to login to 2nd tty session from the current session. Similarly for other sessions. In these 5 or 6 CLI TTY sessions, we  login by providing username and passowrd. Then we can use it the same way as would use any shell terminal from within GUI (the same way as we use xterm within GUI). We can logout by typing "exit". From these 5 or 6 CLI terminals, we can enter into GUI windows by typing "startx". We can get out of GUI mode by logging out from GUI mode. That will bring us back to Command line.

tty => this cmd prints the current terminal session.  i.e /dev/tty4 etc for 4th CLI terminal (most likely the one on Ctrl + Alt +F4). For GUI sessions, it shows /dev/pts/1, /dev/pts2, etc for multiple terminals opened within GUI. pts means psuedo terminal. Whatever CLI this gui session started from shows the dev/tty number when typed on cmd line before GUI gets invoked.

Unix supports 'device files', which aren't really files at all, but file-like access points to hardware devices. A 'character' device is one which is interfaced byte-by-byte (as opposed to buffered IO). /dev/tty is a character device file, it doesn't contain anything but can be read from and written to.

Details

Published: Tuesday, 05 November 2019 01:24

Hits: 4705

In the startup sequence discussed before, we saw that init was the first process to start. However, on newer linux versions, init has been replaced by systemd (system mgmt daemon, d represents daemon) as the first process to start. Init was based on old SysVInit, while systemd is based on newer SystemD, This is a very good link explaining it:

https://www.tecmint.com/systemd-replaces-init-in-linux/

/bin/systemd is run instead of /sbin/init as the process with PID=1. Purpose is the same. A systemd, may refer to all the packages, utilities and libraries around daemon, instaead of just the daemon. However, on my Linux Mint 18, and other linux distro, I still see init as the first process to start, even though systemd is enabled.

Init and systemd have different ways of calling on a service (such as apache2, ssh, cron, etc). This link, explains diff b/w diff methods: https://askubuntu.com/questions/911525/difference-between-systemctl-init-d-and-service

There are 3 different methods:

1. SysVInit using init.d: Under init method, init scripts would be written for any service, and placed in /etc/init.d dir. Then the script in init.d dir would be called directly with options to start/stop/restart/etc for that service. This is not used anymore on new Linux distro, so no need to learn this anymore. It's mentioned briefly below, in case you encounter this on some systems (as Ubuntu).

Selected scripts in /etc/init.d dir are run at startup automatically. Whether the scripts in init.d dir should be run or not is decided by symbolic links to these scripts stored in various dir in /etc/rc*.d/ (rcS.d, rc0.d, ... rc6.d). dir rcS.d has all symlinks in it starting with S where "S" indicate that the service should be started. rc0.d has symlinks starting with S or K where "K" indicate that the service should be stopped (killed). These scripts in rc0.d are executed for runlevel0. Similarly rc1.d is for runlevel1 and so on. The default runlevel for Ubuntu is 2. 

In CentOS 6, this is what I see in dir: /etc/rc.d/rc2.d/

S10network -> ../init.d/network
K50netconsole -> ../init.d/netconsole

This indicats that "network" pgm would be started at startup, while "netconsole" won't.

If we want to add a new pgm to start at startup, we don't modify the links directly, but run "update-rc.d" to update the links to enable/disable pgm.

ex: sudo update-rc.d <pgm1> enable => This updates symlinks to remove "K" symlinks and replaces them with "S" symlinks for program "pgm1". So, now pgm1 would start by default at startup

ex: sudo update-rc.d <pgm1> disable => This updates symlinks to remove "S" symlinks and replaces them with "K" symlinks for program "pgm1". So, now pgm1 would not start by default at startup

NOTE: On most new installation of any Linux distro, you won't see any files in /etc/init.d/ as those files have moved to systemd. On CentOS 6, I don't see any pgm in /etc/init.d, while on Linux Mint 19 (Tara), I see about 50 or so pgms as apache2, bluetooth, sql, etc in that dir. This indicates that many pgms still install files in /etc/init.d/ to control their startup behaviour. In CentOS 6, I do see a README in /etc/init.d/README stating that all the files have moved. However, do note that on many linux distro, traditional init scripts continue to function on a systemd system (even though all the files have moved to systemd). An init script /etc/rc.d/init.d/foobar is implicitly mapped into a service unit foobar.service during system initialization. This is to maintain compatibility, so that existing scripts or any new scripts in /etc/init.d/ don't suddenly stop working.

ex: /etc/init.d/apache2 status => Here, apache2 process init script is called to check status of apache2

2. SysVinit using service: Later on, service cmd was used for SysVinit based systems. It was intended to provide smoother transition into system dependency handling. In most cases,  this newer service cmd just linked scripts in /etc/init.d dir, while in some cases, it called scripts located in entirely diff dir. However, this method is not supported by all Linux distro, and most newer programs, don't even provide support for service. It's mostly there for legacy purpose, and should be avoided all together.

ex: sudo service apach2 status => may work on some distro

3. SystemD using systemctl: This is the newer method of controlling services. Earlier Linux OS used init system, whose fundamental purpose was to init the components that must be started after Linux kernel is booted, and then manage services and daemons. Now, most Linux distro have switched to using systemd, instead of init. However systemd also does same tasks as what "init" used to do. Moving forward, this is the only method that will be supported on all Linux systems. All others will be deprecated. So, use this as preferred method on newer Linux distro, that support it.

link with syntax of systemctl: https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units

systemctl => cmd to control systemd "system and services manager". It can be used to enable, start, stop, check status of system services as sshd, httpd, etc.

/etc/systemd/ => contains all systemd config files. systemd looks in /etc/systemd/system/<some_target>.target.wants file for autostart of any systemd application. We see such files for applications as basic, graphical, bluetooth, getty, network, sysinit, multi-user, etc. Each target is dependent on bunch of services that it runs. symbolic links for *.service files are created here from below dir, whenever we want to autostart any service at boot.

/usr/lib/systemd/system/*.service => This has service file for applications as gdm, bluetooth, NetworkManager, etc, target, wants, etc.

/lib/systemd/system/ => has all units as service, target, wants, etc. This is basically replica of above dir. This is where systemctl looks for, so whatever program is in this dir, is what is supported by systemctl ??

ex: sudo systemctl status apache2.service => This works on all systems supporting systemd. Here, it looks for file "/lib/systemd/system/apache2.service"

ex: sudo systemctl status apache2 =>Here, we omitted the extension, .service, but it still works, as by default, systemctl cmd looks for .service file.

 Some systemd cmds for xinit/graphical services are explained in "Linux Installation".

. 

Details

Published: Thursday, 31 October 2019 17:37

Hits: 4283

USB: widely used communication protocol. At it's core, it has a pair of differential pins for data xfer. There is no clk pin, as clk is embedded within data, and is recovered from there. USB is a confusing protocol with many different terminology and loosely used terms. It defines 2 kinds of spec. One relates to the data communication protocol over wires (i.e USB 1.0, etc), while other refers to the physical connectors (i.e Type C, etc). On top of data communication protocol, USB also defines power delivery communication protocol (PD 1.0, etc). Not all data/power communication protocol are valid over all connector types. On many occasions, the 3 specs are mixed together. We'll talk about these separately.

History:

• USB 1.0: Very earliest usb, came out in 1996. It is called LS (low speed) USB. It has speeds of 1.5Mbits/sec (or equivalently a clk with freq of 1.5MHz). It's power src is 5V @ 100mA (=0.5W max power)
  • USB 1.1: incremental update to USB 1.0, came out in 1998. It is called FS (full speed) USB. It has speed of 12Mbits/sec.
• USB 2.0: next gen of USB, came out in 2001. It is called HS (high speed), and has speeds of 480Mbits/sec (gigantic leap). Power src was also improved to allow more power to be delivered at 2.5W = 5V @ 500mA.
• Upto USB 2.0, usb connectors were identical. They were either Type A connectors, or Type B connectors. They had 4 pins = VBUS, GND, D+, D-. The data pins D+/D- were used for both transmitting and receiving data, so they were half duplex pins.
• USB 3.0: 3rd gen of USB, came out in 2008. It is called SS (super speed) USB. It had 10X higher speeds of 5Gbits/sec (equiv to 5GHz clk freq). However, such high clk freq of 5GHz was not neededto provide 5GBits/sec Bandwidth. Instead USB 3.0 std added new wiring for full duplex operation, i.e new pins do not need to be bidirectional, one pair was receiver, while other pair was transmitter. To have backward compatibility, D+/D- pins were left untouched as bidirectional. New TX+/TX- and RX+/RX- pins were added. New USB 3.x connectors were made, which were still backward compatible with USB connectors from prev gen. New USB 3.x connectors just added new superspeed pins for faster data transfer, either by changing shapes of type A, type B connectors, or getting new pins in b/w the existing pins w/o chnaging shapes. All std connectors as type A, type B in all forms were supported. It supported 8B/10B encoding. There were new type of connectors called Type-C (explained below) which exclusively carried USB 3.2 signals.
  
  • USB 3.1: incremental update to USB 3.0, came out in 2013. It is called SS+ (super speed plus) USB. It doubled the speeds to 10Gbits/sec. It was called USB 3.1 and replaced the older USB 3.0 std. However, to distinguish b/w the older 3.0 vs the new 3.1 std, the older USB 3.0 was renamed as USB 3.1 Gen 1 (with per lane speeds of 5Gbits/sec). The newer std of USB 3.1 was renamed as USB 3.1 Gen2 (with per lane speeds of 10Gbits/sec). USB 3.1 Gen2 still used 8B/10B encoding (same as the original USB 3.0 spec). USB 3.1 spec was backward compatible with USB 3.0 and USB 2.0. From now on, there was USB 3.1 spec and USB 3.0 became obselete (USB 3.0 got rebranded as USB 3.1 gen1).
  • USB 3.2: incremental update to USB 3.1, came out in 2017. It doubled the speeds to 20Gbits/sec, while still preserving SS and SS+ speeds from prev gen. It was called USB 3.2 and replaced the older USB 3.1 std.  In order to double the speeds, it used 2 lanes for data xfer, instead of single lanes that were used until now. To support dual lanes, it required new type of connectors, called Type C connectors. These Type C connectors introduced the concept of Alternate mode (explained later). In order to support all prev gen, it's naming got more complex. Below naming is what is used. x1 or x2 implies single or dual lane. Gen 1 implies lower speed per lane, while Successive Gen imply higher speed per lane. Gen 1 has speed of 5bps/Lane, Gen2 has 10gbps/Lane, Gen3 has 20gbps/Lane while Gen4 has 40Gbps.Lane.
    
    • USB 3.2 Gen 1x1 = this is USB 3.1 Gen1 (aka USB 3.0, SS). Still supported single lanes (x1), so could use older connectors. Speed = 5Gbps/Lane, Lanes=1, Net speed or throughput =5Gbps.
    • USB 3.2 Gen 2x1 = this is USB 3.1 Gen2 (aka SS+). Still supported single lanes (x1), so could use older connectors. Speed = 10Gbps/Lane, Lanes=1, Net speed or throughput =10Gbps.
    • USB 3.2 Gen 1x2 = This is proper USB 3.2, with lower speeds. This has same speed as USB 3.1 Gen2 (SS+) of 10Gbits/sec, but has higher throughput because of more efficient coding of 128B/132B. It supplies data over 2 lanes (x2) with SS speeds, so kind of similar to USB 3.1 Gen1, but repeated twice (effective clk freq = 5Ghz). It needed newer type C connectors, to support dual lanes. Speed = 5Gbps/Lane, Lanes=2, So Net Speed or throughput =10Gbps.
    • USB 3.2 Gen 2x2 = This is proper USB 3.2, with higher speeds. This has higher speeds of 20Gbits/sec. It supplies data over 2 lanes with SS+ speeds, so kind of similar to USB 3.1 Gen2, but repeated twice (effective clk freq = 10Ghz). It needed newer type C connectors, to support dual lanes. USB 3.2 Gen 1x2 and Gen 2x2 is what we commonly see in today's devices which have USB PD connectors. These use both lanes (lane0 and lane1) for data xfer. Speed = 10Gbps/Lane, Lanes=2, So Net Speed or throughput =20Gbps.
• USB4 (or USB 4.0): This new std announced in 2019, replaces all earlier std. It doesn't have a space b/w USB and 4 in it's name (it's written as USB4 and NOT "USB 4". However, most online docs and specs still write it as USB 4 which is incorrect), and is not expected to have further iterations as 4.1, 4.2, etc. It works only on Type C connector (with USB PD running too). It supports speeds from 20Gbps to 120 Gbps. It also supports more AltMode xfer than USB 3.2 (ThunderBolt3 as well as Display port). USB4 by itself does not provide any generic data transfer mechanism as USB 3.x, but serves mostly as a way to tunnel other protocols like USB 3.2, DisplayPort, and optionally PCI Express. The biggest advantage of USB4 is that it allows to share bandwidth b/w video and data.
  
  • USB4 Version 1: This is version 1.0 that was released on 2019. It has double the max speed of USB 3.2 with speeds up to 40Gbits/sec (20Gbits/sec per lane). It initially supported altMode DP 1.4 only, but in 2020, spec provided support for altMode DP 2.0 too. DisplayPort 2.0 can support 8K resolution at 60 Hz with HDR10 color and can use up to 80 Gbit/s which is same amount available to USB data, but just unidirectional. It's named as Gen2 for speeds similar to USB 3.2 and Gen3 for higher speeds. Below are USB4 Gen2 details:
    
    • USB4 Gen 2x1 = This has same speed as USB 3.2 Gen 2x1. It has single lane at 10Gbps. Speed = 10Gbps/Lane, Lanes=1, Net speed or throughput =10Gbps.
    • USB4 Gen 2x2 = This has same speed as USB 3.2 Gen 2x2. It has dual lanes at 10Gbps per lane for a total of 20Gbps. This is marketed as "USB4 20Gbps" or "20" written on peripheral instead of "SS 10" or "SS 20" that was written for USB3. Speed = 10Gbps/Lane, Lanes=2, So Net Speed or throughput =20Gbps.
    • USB4 Gen 3x1 = This is real USB4 where speed for single lane is doubled to 20Gbps. It has single lane at 20Gbps. Speed = 20Gbps/Lane, Lanes=1, Net speed or throughput =20Gbps.
    • USB4 Gen 3x2 = This has Gen 3 with dual lanes at 20Gbps per lane for a total of 40Gbps. This is marketed as "USB4 40Gbps" or "40" written on peripheral instead of "SS 10" or "SS 20" that was written for USB3. Speed = 20Gbps/Lane, Lanes=2, Net speed or throughput =40Gbps.
  • USB4 Version 2: This is Version 2 that was released in 2022. It doubled the speed to 80Gbps (40 Gbps per lane). It's named as Gen 4. It works in both Symmetric and Asymmetric mode where number of TX lanes doesn't need to be same as number of RX lanes. Below are USB4 Gen3 details:
    
    • USB4 Gen 4x1 = This is Gen 4 where speed for single lane is doubled to 40Gbps. It has single lane at 40Gbps. Speed = 40Gbps/Lane, Lanes=1, Net speed or throughput =40Gbps.
    • USB4 Gen 4x2 = This is Gen 4 with dual lanes at 40Gbps per lane for a total of 80Gbps. This is marketed as "USB4 80Gbps" or "80" written on peripheral? Speed = 40Gbps/Lane, Lanes=2, Net speed or throughput =80Gbps.
    • USB4 Gen 4x3 = This is Gen 4 with triple lanes at 40Gbps per lane for a total of 120Gbps. This works in Asymmetric mode, where 3 lanes are used for TX and 1 lane for RX or vice versa. Speed = 40Gbps/Lane, Lanes=3, Net speed or throughput =120Gbps.

USB connectors:

USB connectors also come in different types (for each type, they may come in different sizes):

1. Type A: This has standard 4 pins. It plugs into downstream facing ports (DFP), i.e host is the source. It came in one size called Standard USB connector. This is the most commonly used USB connector that is seen in USB drives, laptops, etc. Later in 2000, a mini usb connector was released, that was about half the width of standard connector. It was used in camera, Mp3 players, etc, but has been phased out since 2018. A successor to Micro USB is mini usb, which is even smaller and more flatter. This is the most compact form of usb connector, and is seen in phones, tablets, etc. which was flatterIt comes in 2 sizes: Standard and Micro.

Pins:    GND   D+   D-   VBUS => 4 pins 

2. Type B: This also has standard 4 pins. It plugs into upstream facing ports (UFP), i.e device is the sink. Here, the connector size is different. It's square shaped, and is mostly seen in printers.

3. Type C: This is totally new connector with 24 pins, is reversible and is round shaped. As the whole USB arch changed with type C, these required new connectors called as Type C connectors. Unlike Type A and Type B connectors, which came in diff sizes, Type C connectors come in only 1 size. Starting with proper USB 3.2, we need type C connectors to get higher speeds.

• D+/D- pins are retained to provide USB 2.0 functionality
• 2 lanes of TX1/RX1 and TX2/RX2 provide dual lane capability to do high speed data xfer for USB 3.0 and above (GHz speeds)
• SBU1/SBU2 pins are for providing side band signals.
• CC1/CC2 pins are for providing configuration channel signals (used for PD protocol explained below)

USB Protocol:

USB 2.0 and earlier had only 4 pins, with only D+ and D- for data line. Basically data was the only signal sent out, with no associated clock. Data was sent with enough transitions so that a clock could be recovered out of it. This makes it simple to understand the transactions. USB3 and later become overly complicated, and not so easy to understand transactions.

This video connects an oscilloscope to the 2 usb data wires (D+ and D-) going from keyboard to PC, and examines the traffic, and figures out all transactions by manually drawing them on a piece of paper. Excellent video if you want to understand basic packet communication for USB2.

How does a USB keyboard work (by Ben Eater) => https://www.youtube.com/watch?v=wdgULBpRoXk

Power Delivery (PD):

With type C came a whole new functionality for power delivery. Until now, USB was primarily for data xfer. However with advent of portable devices that did not need much power to operate, the power pins on such portable devices were omitted. Instead, portable devices started drawing their power from 2 USB pins => VBUS and GND. This was OK in 1990s, as power delivery of 0.5W in USB 1.0 from USB host was sufficient to power these small devices. However, power requirement of these portable devices started going up in early 2000. To accommodate that, USB standards added power delivering capability of up to 2.5W in USB 2.0.

Then battery charging protocol was released in 2010 for USB 2.0 known as BC 1.1. This allowed up to 7.5W power from USB ports. What power to deliver was based on Resistance values on D+/D- pins. Refined BC 1.2 spec was released later. BC protocols are very complex and confusing. We'll not go into more details on those.

PD 1.0:

However, with power requirements for portable devices further increasing, a new spec for power delivery known as PD 1.0 was released. This allowed >7.5W power to be delivered over USB power pins. It was supported over Type A and Type B connectors.  Devices can request higher power from host. Voltages of 5V, 12V and 20V on VBUS were now supported, with currents up to 5A, resulting in 100W max power delivery. However, for V>5V, and I>3A, dedicated power communication pins as CC1/CC2 were needed, which were part of USB Type C spec.

PD 2.0:

With the release of USB 3.1 spec, PD 2.0 was released as part of this spec. It allowed power delivery to happen over USB Type C connectors/cable with special dedicated pin for power delivery communication. These new pins for power related communication were CC1/CC2 pins. Power was delivered over 4 VBUS pins. However for backward compatibility, previous BC1.2 and PD1.0 were still supported over D+/D- pins.

PD 2.0 is :

- single wire protocol on CC wires

- DFP is bus master and initiates all communication

- All msg are 32 bit 4B/5B encoded. It uses BMC (Biphase Mark Coded) encoding, which is a version of Manchester coding.

- It has a Baud rate of 300K (i.e clk rate of 300KHz), so pretty low frequency (wich is OK, since power requirements do not change frequently, i.e in uS)

- It supports CRC error detection + message retries

Out of the 2 configuration channels, CC1/CC2, one of them is used for cable orientation detection, while the other one is used for PD purpose. CC wire for PD communication needs to have valid resistances tied to Power/Gnd. That is how the USB logic figures out which of CC1 or CC2 to use for PD purpose.

CC wire for PD should have 5Kohm resistance tied to GND for UFP (sink device such as mouse), and 10Kohm to 55Kohm resistance tied to VBUS for DFP (host device such as PC). These resistance serve as a voltage divider determining the final voltage level of CC wire. This voltage determines initial current level supported by USB.

Rd = pull down resistance = 5 Kohm

Rp = pull up resistance = 3 different values:

•  56 Kohm = default = 0.5A @ 5V for USB 2 and 0.9A @ 5V for USB 3. Voltage level on CC wire = 5/(56+5) * 5V = 0.4V
• 22 Kohm = 1.5A @ 5V. Voltage level on CC wire = 5/(22+5) * 5V = 1.0V
• 10 Kohm = 3.0A @ 5V. Voltage level on CC wire = 5/(10+5) * 5V = 1.65V

Any voltage > 1.65V on CC wire is taken as no connection, as then the pull down resistance is assumed to be much larger than 5 Kohms (ideally Rd is infinity, and voltage detected on CC wire would be 5V)

Successful attachment of connector would be indicated by presence of a valid voltage on one of the CC wires. that wire would be used for PD communication. Once a default power supply is provided based on resistance values, further PD communication can now happen on CC wire. This PD communication happens via messages sent b/w src and sink. Voltage level on VBUS and higher currents can only be supported after successful negotiation.

PD controller: There is a separate chip called "PD controller" chip that is provided by major vendors as TI, STM, etc that provides all the functionality to deal with PD communication. It takes in D+/D- lines as well as CC1/CC2 lines, and does all power negotiation work to put correct voltage and current on VBUS. High speed data lines go thru another chip which is the main USB data controller chip. D+/D- lines alo go to this main controller chip, as they carry data too. The reason D+/D- go to PD controller chip is to determine power delivery for USB 2.0 (they aren't used for data communication purpose at all in the PD controller chip).

Alternate Mode:

A very useful mode in USB Type C connectors is Alt Mode. Here, it allowed these connectors to support not only native USB mode data xfer, but also alternate mode data xfer (aka AltMode) for other protocols (as Display Port and HDMI protocols) on the same wires. 

Alternate modes are defined and configured via USB PD protocol. Same CC1/CC2 lines are used for AltMode configuration. Structured VDM (vendor defined messages) are used on CC lines to enter AltMode. Unused pins on USB-C are used for Alt Mode of operation.

Display Port (DP) AltMode: This is one of the Alt Mode supported on USB-C. DP protocol requires 4 lanes (8 pins, since differential signals) for data xfer, 1 lane as auxillary channel (2 pins, since differential signals), and 1 wire as HPD (hot plug detect = this line is used by upstream device to detect plugging of downstream device).

DP Alt Mode allows TX1/RX1 and TX2/RX2 lanes to be used as Data lanes for DP, and SBU1/SBU2 to be used as auxillary lanes (since auxillary lanes do not have high speed requirement, these 2 lines can be used as differential lines), and HPD line is provided by the USB PD controller. There is a mux that is controlled by the PD controller. This mux takes data from USB lines, and routes them to either USB contoller (for regular mode) or to Display devices (for AltMode). The 4 data lanes are all unidirectional as display data only goes from source to sink (to be consumed), so all 4 lanes are configured as TX lines. DP is called as simplex protocol (unidirectional xfer), while USB protocol is duplex protocol (bidir xfer).

ThunderBolt3 AltMode: This is another AltMode supported on USB-C for USB4 protocol.

USB4 AltMode: This is yet another AltMode

MultiFunction AltMode: A combination of regular mode on one of the lanes and AltMode on another, i.e USB3.2 + DP
 

Details

Published: Tuesday, 29 October 2019 23:42

Hits: 4571

openssh: This is the official link: https://www.openssh.com/

There are lot of programs available that allow you to remotely log into your machines. Openssh is open source and most popular on Linux. It has a client server model. So, in order to allow others to log into your machine, you need to install a server program on that machine. This server program keeps on looking for any incoming connections. If it finds an incoming connection, and credentials are valid, it allows you to log into this machine, just as a local user would. On the other computer (client computer) from which you are trying to connect to this server, you need to install a client program of openSSH.

Install:

Cient program of openssh are usually installed on all Lnux systems. We can verify this by typing cmd "which ssh" on terminal. It should show path as /usr/bin/ssh. ssh is the openssh client pgm. Server program of ssh is called "sshd" (ssh daeman) and is not installed by default. We can install it as follows:

On a terminal, type the below cmd:

sudo apt intsall openssh-server => This will install openssh server on your computer.

Now type, "which sshd", and it will show binary executable path as /usr/sbin/sshd.

sshd daeman by default runs on TCP port 22. It starts on boot time.

Syntax ssh/sshd:

ssh cmd syntax here: https://man.openbsd.org/ssh.1

ex: ssh This email address is being protected from spambots. You need JavaScript enabled to view it. => This is used to log into remote m/c maaldaar.com, with user name "hari" on that remote m/c.

sshd cmd syntax here: https://man.openbsd.org/sshd.8

We can manually start/stop sshd, or check status using various cmds (see in "init vs sytemd" section). Here, we'll show by 2 means: systemd based and init based.

1. init based: sudo /etc/init.d/ssh start

2. systemd based: systemctl status sshd

Adding New User for ssh:

If you want to allow any user from any machine to ssh into your server, then you need to create a new user with some name, give that user a password. Then others can login with that username and that password. Password can also be made optional. Follow the steps:

• Open a new terminal on ssh server m/c and type below cmds:
  • su adduser guest => here "guest" is the user name. It will ask for a new password for this user. It will then add this user, make a home dir for guest at /home/guest.
  • su passwd guest => You can change the password by using this cmd.
  • usermod -aG sudo newuser => This gives sudo access to "guest" user so that he/she can run any root cmd by being superuser. This is very risky and should only be done for trusted users.
• Once new user has been created on server m/c, log into client machine and make a ssh connection to server m/c:
  • ssh This email address is being protected from spambots. You need JavaScript enabled to view it. => It asks for the password, and if both username and password are correct, then it makes a ssh connection and opens a terminal on server m/c.

Linux ssh related cmds:

There are many cmds in linux that establish a connection b/w 2 machines. A lot of these are built on top of ssh. Either we establish a sssh before we can use these cmds, or ssh is inbuilt as part of these cmds. Either way sshd should be running on the server m/c or the cmds will fail. Few such cmds are below:

Linux Secure Copy (scp) cmd:

scp is the linux cmd to copy files from one computer to other. It's equivalent of cp or copy cmd, except that it's done to copy files between computers and is done securely so that files can't be seen by any third party. scp uses ssh under the hood, so scp can only work after sshd is installed and running. We need sshd, or server ssh, to be active and running on the remote machine that we are trying to connect to. If it doesn't has sshd running, scp to/from that remote machine won't work. Usage is simple:

scp <src_machine:src_file> <dest_machine:dest_file> => scp cmd asks for user's password on another machine, as it uses ssh for authentication.

ex: user1@laptop1$ scp user2@laptop2:test.txt project/. => This copies the file "test.txt" from remote machine "laptop2" in user2 home dir to "project" subdir of current dir in laptop1. Laptop1 is our local machine and user1 is logged on this machine. He's some dir "dir1". Now file is copied to dir1/project/test.txt.

ex: user1@laptop1$ scp project/test1.txt user2@laptop2:dir2/test2.txt => This is the reverse of above example, where we are copying from local machine (laptop1) to remote machine (laptop2). Here we are copying file test1.txt as test2.txt.

Linux remote sync (rsync) cmd: 

rsync is another linux cmd to copy and sync files b/w 2 m/c. rsync is very popular and is  included on most Linux distributions by default.

Detailed link: https://www.digitalocean.com/community/tutorials/how-to-use-rsync-to-sync-local-and-remote-directories

syntax: rsync <options> <src_files> <dest files>

Steps:

• Log into the client m/c (or server m/c). Establish ssh connection b/w the 2 m/c using ssh cmd with correct user name.
• cd ~; rsync -a ~/dir1/ dir2 => this copies files locally from dir1 to dir2. Since / is at end of dir1, dir1 itself is not copied to dir2. -a copies recursively preserving symbolic links, timestamps, etc. -anv option also used commonly which does a dry run of what the cmd is going to do (-n is for "not do it", -v is for verbose)
• rsync -a ~/dir1 guest@maaldaar.com:dest_dir => This is push method where we push files from local m/c (~/dir1) to remote m/c (dest_dir)
• rsync -a This email address is being protected from spambots. You need JavaScript enabled to view it.:/home/guest/dir1 ~/dest_dir => This is pull method where we pull files from remote m/c (/home/guest/dir1) to local m/c (~/dest_dir)