FPGA source code for a PMBus master on Xilinx KC705

Introduction

This post is best read after another post of mine, “Controlling the power supplies on a Xilinx KC705 FPGA board with PMBus“. C utilities for using the design outlined below can be found in another post of mine.

These are the sources for allowing a computer to monitor and control the power supplies of an Xilinx KC705 FPGA board (for Kintex-7) through the PMBus wires attached to the FPGA. This solution is based upon Xillybus, which is a somewhat ridiculous overkill for this task.

The base project is the demo bundle for KC705, which can be downloaded from Xillybus’ website. Even though it works with Linux as well as Windows, the utility sources in the other post are written for Linux. It’s not really difficult to port them to Windows (pay attention to open the files as binary and change the path to the device files) or use them using Cygwin.

Warning: Issuing the wrong command to a power supply controller can destroy an FPGA board in a split second. I take no responsibility for any damage, even if something I’ve written is misleading or outright wrong. It’s YOUR full responsibility to double-check any of your actions.

The following changes are made on the demo bundle (all detailed below):

  • Replace the Xillybus IP core with a custom IP core generated in Xillybus’ IP Core Factory.
  • Add pmbus_if.v source to the project
  • Change xillydemo.v to utilize the updated Xillybus IP core and instantiate pmbus_if.v + expose the pmbus_* ports
  • Add pin placement constraints to the XDC file

Setting up a Xillybus custom IP core

It’s recommended to make yourself acquainted with the Xillybus concept in general. The Getting Started guide for Xilinx available at the Documentation section may come handy for this purpose.

Download the bundle for KC705 from the website, and build the project in Vivado: Execute verilog/xillydemo-vivado.tcl in the demo bundle from within Vivado to set up the project.

Then enter Xillybus’ IP Core Factory, set up, generate and download a custom IP core for Kintex-7 with attributes as shown in the screenshot below (click to enlarge):

Screenshot of Xillybus IP Core parameters

The name of the device file must be accurate, as well as the other parameters, but the expected BW doesn’t have to.

Once the custom IP core zip file is downloaded, replace the project’s core/xillybus_core.ngc, verilog/src/xillybus.v and verilog/src/xillybus_core.v with those extracted from the zip file.

pmbus_if.v

pmbus_if.v (listed below) implements the logic that handles the PMBus interface. It’s a bit of a hack that I’ve been tweaking for different quick tasks for years, without ever trying to get it written properly. As such, it’s not covering corner cases well, and might not work with other I2C-bus like interfaces, or even with devices other than the one it’s intended for — TI’s UCD92xx series. In particular it has the following known issues:

  • A NAK from the device is ignored if it relates to the last byte of a write transaction.
  • Cycle extension by virtue of holding the clock signal by the slave is not supported — the master just goes on, ignoring this.

These issues are quite minor, in particular during proper operation.

The clk_freq parameter is set to 1000 MHz, which doesn’t reflect the actual frequency, 250 MHz. The reason is that even though it should have worked with clk_freq = 250 according to the spec, the device’s firmware appears not be quick enough to handle read requests arriving at higher rates, resulting in all-0xff responses occasionally.

Listing follows:

`timescale 1ns / 10ps

module pmbus_if
  (bus_clk, quiesce, user_w_pmbus_wren, user_w_pmbus_data,
   user_w_pmbus_full, user_w_pmbus_open, user_r_pmbus_rden, user_r_pmbus_data,
   user_r_pmbus_empty, user_r_pmbus_eof, user_r_pmbus_open,
   pmbus_clk, pmbus_data);

   input         bus_clk;
   input 	 quiesce;
   input 	 user_w_pmbus_wren;
   input [7:0] 	 user_w_pmbus_data;
   input 	 user_w_pmbus_open;
   input 	 user_r_pmbus_rden;
   input 	 user_r_pmbus_open;
   output 	 user_w_pmbus_full;
   output [7:0]  user_r_pmbus_data;
   output 	 user_r_pmbus_empty;
   output 	 user_r_pmbus_eof;
   output 	 pmbus_clk;
   inout 	 pmbus_data;

   reg [15:0] 	 div_counter;
   reg 		 sclk_logic;
   reg 		 sdata_logic;
   reg 		 sdata_sample;
   reg 		 pmbus_en;
   reg 		 pre_en;
   reg [3:0] 	 state;
   reg 		 first;
   reg 		 dir_write;
   reg 		 save_direction;
   reg [7:0] 	 write_byte;
   reg [7:0] 	 read_byte;
   reg [2:0] 	 idx;
   reg 		 write_byte_valid;
   reg 		 fifo_wr_en;
   reg 		 open_d;
   reg 		 stop_pending;
   reg 		 stop_deferred;
   reg 		 do_restart;

   parameter 	 clk_freq = 1000; // In MHz, nearest integer

   parameter st_idle = 0,
	       st_start = 1,
	       st_fetch = 2,
	       st_bit0 = 3,
	       st_bit1 = 4,
	       st_bit2 = 5,
	       st_ack0 = 6,
	       st_ack1 = 7,
	       st_ack2 = 8,
	       st_stop0 = 9,
	       st_stop1 = 10,
	       st_stop2 = 11, // Represented by "default"
	       st_startstop = 12;

   assign    user_r_pmbus_eof = 0;

   // Emulated open collector output
   // Note that sclk and sdata must be pulled up, possibly with
   // a PULLUP constraint on the IOB (or a 10 kOhm ext. resistor)

   assign    pmbus_clk = sclk_logic ? 1'bz : 1'b0 ;
   assign    pmbus_data = sdata_logic ? 1'bz : 1'b0 ;

   assign    user_w_pmbus_full = write_byte_valid || stop_pending;

   // pmbus_en should be high every 10 us
   // This allows a huge multicycle path constraint on pmbus_en

   // A stop condition is presented on the bus when
   // * in a write access, the write stream closes, and the read stream
   //   is already closed, or
   // * in a read access, the write stream closes
   // * a stop condition was prevented previously by an open read stream,
   //   and the read stream closes (in which case a start-stop is presented).

   always @(posedge bus_clk)
     begin
	pmbus_en <= pre_en;
	sdata_sample <= pmbus_data;
	fifo_wr_en <= pmbus_en && (state == st_ack0) && !dir_write;
	open_d <= user_w_pmbus_open;

	if (open_d && !user_w_pmbus_open)
	  begin
	     stop_pending <= 1;
	     do_restart <= user_r_pmbus_open;
	  end

	if (user_w_pmbus_wren)
	  begin
	     write_byte <= user_w_pmbus_data;
	     write_byte_valid <= 1; // Zeroed by state machine
	  end

	if (div_counter == ((clk_freq * 10) - 1))
	  begin
	     div_counter <= 0;
	     pre_en <= 1;
	  end
	else
	  begin
	     div_counter <= div_counter + 1;
	     pre_en <= 0;
	  end

	// State machine

 	if (pmbus_en)
	  case (state)
	    st_idle:
	      begin
		 sclk_logic <= 1;
		 sdata_logic <= 1;

		 stop_pending <= 0;

		 if (write_byte_valid)
		   state <= st_start;

		 // st_startstop is invoked only if the stream for reading data
		 // was open during the write session, which indicates that the
		 // next cycle will be a read session. This prevented a
		 // stop condition, so a restart can takes place. But then
		 // this stream closed suddenly without this read session,
		 // so a dirty stop condition needs to be inserted.

		 if (stop_deferred && !user_r_pmbus_open)
		   state <= st_startstop;
	      end

	    st_start:
	      begin
		 sdata_logic <= 0; // Start condition
		 first <= 1;
		 dir_write <= 1;
		 stop_deferred <= 0;

		 state <= st_fetch;
	      end

	    st_fetch:
	      begin
		 sclk_logic <= 0;
		 idx <= 7;

		 state <= st_bit0;
	      end

	    st_bit0:
	      begin
		 if (dir_write)
		   sdata_logic <= write_byte[idx];
		 else
		   sdata_logic <= 1; // Keep clear when reading

		 state <= st_bit1;
	      end

	    st_bit1:
	      begin
		 sclk_logic <= 1;
		 read_byte[idx] <= sdata_sample;

		 state <= st_bit2;
	      end

	    st_bit2:
	      begin
		 sclk_logic <= 0;

		 idx <= idx - 1;

		 if (idx != 0)
		   state <= st_bit0;
		 else
		   state <= st_ack0;
	      end

	    st_ack0:
	      // Don't handle the last ACK cycle until the outcome is known.
	      // This allows a NAK on the last received byte, and also ensures
	      // a stop condition at the end of a write cycle (and not a
	      // restart if the file was reopened by host for the next cycle).

	      if (write_byte_valid || stop_pending)
		begin
		   if (dir_write)
		     sdata_logic <= 1; // The slave should ack
		   else
		     sdata_logic <= stop_pending; // We ack on read

		   save_direction <= !write_byte[0];
		   state <= st_ack1;
		end

	    st_ack1:
	      if (!dir_write || !sdata_sample || stop_pending)
		begin
		   state <= st_ack2; // Read mode or slave acked. Or Quit.
		   write_byte_valid <= 0;
		end

	    st_ack2:
	      begin
		 sclk_logic <= 1;

		 if (write_byte_valid)
		   begin
		      if (first)
			dir_write <= save_direction;
		      first <= 0;

		      state <= st_fetch;
		   end
		 else if (stop_pending)
		   state <= st_stop0;
	      end

	    // The three stop states toggle the clock once, so that
	    // we're sure that the slave has released the bus, leaving
	    // its acknowledge state. Used only in write direction.

	    st_stop0:
	      begin
		 sclk_logic <= 0;
		 state <= st_stop1;
	      end

	    st_stop1:
	      begin
		 if (do_restart && dir_write)
		   begin
		      sdata_logic <= 1; // Avoid stop condition
		      stop_deferred <= 1;
		   end
		 else
		   begin
		      sdata_logic <= 0;
		   end
		 state <= st_stop2;
	      end

	    st_startstop:
	      begin
		 sdata_logic <= 0;
		 stop_deferred <= 0;
		 state <= st_idle;
	      end

	    default: // Normally this is st_stop2
	      begin
		 sclk_logic <= 1;

		 write_byte_valid <= 0;

		 // st_idle will raise sdata to '1', making a stop condition
		 // unless sdata_logic was driven low in st_stop1
		 state <= st_idle;
	      end
	  endcase

	if (quiesce) // Override all above.
	  begin
	     state <= st_idle;
	     stop_pending <= 0;
	     write_byte_valid <= 0;
	     stop_deferred <= 0;
	  end
     end

   fifo_8x2048 fifo
     (
      .clk(bus_clk),
      .srst(!user_r_pmbus_open),
      .din(read_byte),
      .wr_en(fifo_wr_en),
      .rd_en(user_r_pmbus_rden),
      .dout(user_r_pmbus_data),
      .full(),
      .empty(user_r_pmbus_empty));
endmodule

xillydemo.v

The file should be changed to this:

module xillydemo
  (
   input  PCIE_PERST_B_LS,
   input  PCIE_REFCLK_N,
   input  PCIE_REFCLK_P,
   input [7:0] PCIE_RX_N,
   input [7:0] PCIE_RX_P,
   output [3:0] GPIO_LED,

   output pmbus_clk,
   inout  pmbus_data,

   output [7:0] PCIE_TX_N,
   output [7:0] PCIE_TX_P
   );

   // Clock and quiesce
   wire    bus_clk;
   wire    quiesce;

  // Wires related to /dev/xillybus_pmbus
  wire  user_r_pmbus_rden;
  wire  user_r_pmbus_empty;
  wire [7:0] user_r_pmbus_data;
  wire  user_r_pmbus_eof;
  wire  user_r_pmbus_open;
  wire  user_w_pmbus_wren;
  wire  user_w_pmbus_full;
  wire [7:0] user_w_pmbus_data;
  wire  user_w_pmbus_open;

  xillybus xillybus_ins (
			 // Ports related to /dev/xillybus_pmbus
			 // FPGA to CPU signals:
			 .user_r_pmbus_rden(user_r_pmbus_rden),
			 .user_r_pmbus_empty(user_r_pmbus_empty),
			 .user_r_pmbus_data(user_r_pmbus_data),
			 .user_r_pmbus_eof(user_r_pmbus_eof),
			 .user_r_pmbus_open(user_r_pmbus_open),

			 // CPU to FPGA signals:
			 .user_w_pmbus_wren(user_w_pmbus_wren),
			 .user_w_pmbus_full(user_w_pmbus_full),
			 .user_w_pmbus_data(user_w_pmbus_data),
			 .user_w_pmbus_open(user_w_pmbus_open),

			 // Signals to top level
			 .PCIE_PERST_B_LS(PCIE_PERST_B_LS),
			 .PCIE_REFCLK_N(PCIE_REFCLK_N),
			 .PCIE_REFCLK_P(PCIE_REFCLK_P),
			 .PCIE_RX_N(PCIE_RX_N),
			 .PCIE_RX_P(PCIE_RX_P),
			 .GPIO_LED(GPIO_LED),
			 .PCIE_TX_N(PCIE_TX_N),
			 .PCIE_TX_P(PCIE_TX_P),
			 .bus_clk(bus_clk),
			 .quiesce(quiesce)
  );

   pmbus_if pmbus_if_ins(.bus_clk(bus_clk),
			 .quiesce(quiesce),
			 .user_w_pmbus_wren(user_w_pmbus_wren),
			 .user_w_pmbus_data(user_w_pmbus_data),
			 .user_w_pmbus_full(user_w_pmbus_full),
			 .user_w_pmbus_open(user_w_pmbus_open),
			 .user_r_pmbus_rden(user_r_pmbus_rden),
			 .user_r_pmbus_data(user_r_pmbus_data),
			 .user_r_pmbus_empty(user_r_pmbus_empty),
			 .user_r_pmbus_eof(user_r_pmbus_eof),
			 .user_r_pmbus_open(user_r_pmbus_open),
			 .pmbus_clk(pmbus_clk),
			 .pmbus_data(pmbus_data)
			 );
endmodule

Adding pin placement constraints

The following lines should be appended at the end of vivado-essentials/xillydemo.xdc:

set_property PACKAGE_PIN Y14 [get_ports pmbus_data]
set_property IOSTANDARD LVCMOS15 [get_ports pmbus_data]
set_property PACKAGE_PIN AG17 [get_ports pmbus_clk]
set_property IOSTANDARD LVCMOS15 [get_ports pmbus_clk]

Building the project

With the project set up as outlined above, generate the bitstream as usual.

Controlling the power supplies on a Xilinx KC705 FPGA board with PMBus

You probably don’t want to read all of this

First of all: There is a GUI tool offered by TI to monitor and control its power controller. In hindsight, I have to admit it’s probably the quick & painless way to modify the voltage of a power rail (see last post on this page). I went for the DYI approach, which turned out by far harder than I imagined. So I suggest reading this, if at all, for a better understanding of what’s going on under the hood. And maybe to understand why you probably don’t want to get into this.

Introduction

These are the notes I took while making my way to changing the VADJ power supply voltage from its default 2.5V to 1.8V on an KC705 board, for proper operation of an FMC card. One could imagine that it would be easy (remove a jumper?), but the thing is that a rather sophisticated power supply controller (TI UCD9248) is used. In order to make any changes to its output, several parameters need to programmed.

I should mention that similar controllers are used on other Xilinx boards, e.g. ML605, SP605, AC701, VC707, VC709, ZC702 and ZC706, or for short, all or virtually all official Xilinx boards. So the same techniques apply.

To make the necessary programming of the power controller, a rather obscured protocol is used: PMBus. One could, once again, imagine it to be fairly straightforward, as PMBus is based upon SMBus, which is a variant of I2C. The PMBus wires can be accessed from an external connector, or directly from the FPGA.

Unfortunately, the PMBus specification is a multi-nominee for the Oscar of the Worst Written Spec, competing only with Displayport, as far as I can tell. TI’s documentation of the power supply controller family is also somewhat unclear at times.

Xilinx doesn’t help with this issue much either. Even though there are many pointers to AR# 37561 and AR# 56811 in this matter, these offer a solution to return the settings to the factory defaults, or suggest to develop custom code for doing this. Actually, it suggests refraining from making any changes in AR# 37561. KC705′s User Guide, on the other hand, explicitly tells the board’s user to adjust the VADJ voltage, mentions TI’s GUI tool, hints on writing custom code, but doesn’t really say what way to go.

Bottom line: If your FMC card doesn’t work with 2.5V, good luck, and try not burning your FPGA board. Which brings me to:

Warning: Issuing the wrong command to a power supply controller can destroy an FPGA board in a split second. I take no responsibility for any damage, even if something I’ve written is misleading or outright wrong. It’s YOUR full responsibility to double-check any actions against the original documentation.

Quick facts for dropping VADJ to 1.8V on KC705

This is handy no matter what way is chosen:

  • The PMBus address of the relevant device is 52
  • The voltage rail is 4A, accessed as page 3.
  • The original voltage is 2.5V
  • All original voltage settings are tuned for 2.5V except for POWER_GOOD_ON = 1.7V and POWER_GOOD_OFF = 1.65 V. So changing just VOUT_COMMAND to 1.8V will probably work, but with an undervoltage fault asserted. Given that this voltage rail can be disabled with a jumper, it’s safe to assume that no other power source depends on it by virtue of sequencing, so this fault is probably harmless. Which is most likely the idea behind this parameter setting.

Resources

This post is by far not a substitute for reading the docs, and taking educated decisions. These are the main documents to get acquainted with:

There are a few other posts I’ve published along with this one:

The DYI approach: What needs to be done

In order to make a successful change of a rail voltage, the following is required:

  • Setting which power output to control (setting the page, explained below)
  • Being aware of, and possibly control the ON/OFF status of the power rail.
  • Setting the voltage-related attributes. It’s not just the requested voltage, but also several fault limits etc.
  • Writing the new setting into non-volatile memory.

PMBus vs. SMBus vs. I2C

The PMBus specification defines four pins, unlike the two pins (clock and data) most of us are used to from I2C and SMBus. UCD92xx devices present all four PMBus pins. One of the “new” pins is ALERT, which is defined in the SMBus spec as SMBALERT. This pin is used as an interrupt from the device to the master, in particular for reporting faults. For the purpose of changing voltages, this pin can be ignored.

The second pin is introduced in the PMBus spec: CONTROL. This pin is optionally used to turn all power rails on or off, possibly is a sequenced manner. It’s usually tied high on Xilinx boards, and doesn’t help much: If we want to control a specific power rail, it’s wiser to do so by sending commands, rather than turning the entire controller on and off with this pin. Assuming that the controller is configured to react to this pin, that is. More on this later.

For most purposes, PMBus is SMBus, and SMbus is I2C, so an I2C-compliant bus master will most likely do the trick. One needs to bear in mind that the byte following the bus address isn’t a register address, but a command. The difference is that when several data bytes are transmitted, there is no register address incrementation. For example, for setting the overvoltage fault limit, the bus address is followed by an 0x40 (VOUT_OV_FAULT_LIMIT command) which is then followed by a word — that is, two bytes. Had it been an I2C bus, the second byte would have gone to the register at 0x41. But there is no auto-incremented address with PMBUS. The command at 0x41, VOUT_OV_FAULT_RESPONSE remains intact.

Except for the lack of address auto-increment, PMBus is used like an I2C bus, where the command takes the place of a single-byte I2C address. In particular, reading takes place with a write operation without data, followed by an start-stop condition, and then a read cycle.

So the term “command” can be treated as an I2C register for most purposes.

But well, there’s another important exception, which is the set of no-data commands. It’s those having Transaction Type “Send Byte” in Table-1 of SLUU337. These transactions end immediately after the command, so from an I2C-register point of view, they did nothing. But on a PMBus, such a sequence can do serious things, for example, the RESTORE_DEFAULT_ALL command, which can have unpleasant consequences.

As for attempting to read from this “command address”, it could, in theory, result in the same effect as writing to it, because a read transaction’s first part is a command without data. There is a difference, however: There’s a restart after the first part, and not a STOP condition. My experiment with UCD9240 shows that the device noted this difference, and responded with not executing a CLEAR_FAULTS command (for other errors than this communication fault). As for the part after the restart condition, it acknowledged its own address (as it’s forced to per spec) but forced the PMBus clock signal low immediately after that, thus freezing the bus transaction, causing a recovery by means of an SMBus timeout. So this specific device played it well, but I wouldn’t rely on this.

SMBus allows for an extra PEC byte at the end of each transaction, which is a CRC. This is optional with PMBus. The UCD92xx devices support PEC, but work without it. I’ve personally verified that the device responds correctly with and without the PEC byte inserted or retrieved from the device. I’ve also verified that a write cycle with a faulty PEC is ignored by the device, which is the reason I use this mechanism myself: Given the price of a flipped bit (literally), I really want to know if the bus is anything but bulletproof.

UCD92xx’s PMBus robustness

It seems like the UCD92xx’s PMBus implementation doesn’t fall on its feet as well as other I2C / SMBus devices I’ve encountered: In particular, a previous version of my own hacky implementation of an I2C/SMBus master didn’t finish read transaction correctly, but issued a STOP condition after the last read byte, instead of NACKing and then issue a STOP, as it should per spec (this is fixed in the published code). A lot of other I2C devices I’ve worked with (many of which from TI) ignore this mishap, and followed the (unwritten?) rule that a STOP condition means forgive & forget, and the following START means a fresh start. The UCD9240 device, on the other hand, returned all 0xff on the read cycle that followed the offending one. And then returned correct data on the read cycle after that, even though it had exactly the same fault.

This anecdotal incident may imply that UCD92xx devices may not react well to bus masters that have protocol flaws that other slaves ignore silently. It doesn’t make UCD92xx devices safer, just a bit picky.

I also ended up with a bus clock frequency of 8 kHz only, even though the datasheet ensures up to 400 kHz. The reason was that when I tried two consecutive read commands with a 32 kHz clock, the second consistently returned an all-0xff answer, most likely because the device’s firmware didn’t keep up with the read requests.

Page vs. power rail

The UCD92xx devices on Xilinx boards are used to control several voltage sources. Each voltage source can be driven by one or more PWM-controlled power front ends (on Xilinx boards, there’s always one front-end for each voltage).

The PMBus specification facilitates the control of multiple power rails by a single controller with pages. So to control the voltage of a specific voltage source, the page is selected first by a write transaction with a PAGE (0x00) command. After this command, a certain set of commands relate to this page — effectively all commands that are bound to a voltage rail: Desired voltage, fault limits of voltage and current, the sensed voltage and current etc.

The relation between the page and the physical rail it controls is programmable. By no means should it be assumed that PAGE 0 relates to the lowest index of the physically controlled power lines or anything like that. In a given system, this mapping is obtained by issuing a PHASE_INFO (0xd2) read command, and analyzing the response. It’s of course crucial to make this connection correctly before changing the setting of any PAGE, or the wrong power rail is affected. Refer to TI’s reference on UCD92xx commands (SLUU337) section 10.1 for more on this, and the sample utils demonstrate how this relation is made. It can also be seen in Linux kernel’s driver (drivers/hwmon/pmbus/ucd9200.c), which issues a PHASE_INFO read command in its probe function, and deduces the number of pages according to the response. According to TI’s doc on UCD92xx commands (SLUU337) section 10.1.1, no gaps are allowed in the page allocation, so this way of telling the maximal allowed page number is correct.

A UCD92xx device refuses to switch to a PAGE command if the related page is unused, as reflected by the response to a PHASE_INFO read command. In other words, the device refuses to switch to a page for which no power rail phases are attached, according to PHASE_INFO. Such refusal takes the form of a PMBus NAK on the byte containing the requested page (the one followed by the command byte) and the current page remaining unchanged. This behavior seems not to be documented by TI or have any other written reference.

There is also a similar division of a page into phases, but this is irrelevant, as each page is mapped into a single phase (i.e. uses a single PWM output) on Xilinx’ boards. So this entire issue can be overlooked. Except for knowing which phase (PWM output) is mapped to which page, of course.

The on/off status

Mainly two commands control whether the power rail is on or off, and which voltage is supplies: OPERATION (0x01) and ON_OFF_CONFIG (0x02). UCD92xx devices follow the PMBus standard in this matter.

Except for these two commands, sequencing is controlled by the manufacturer-specific commands GPIO_SEQ_CONFIG (0xf3) and SEQ_TIMEOUT (0xd0). The former is a 29-bytes long block of configuration bitmaps, which is a bit of a story in itself. For those curious to understand how the J65 jumper on KC705 enables the VADJ power rail, this is where to look. Also if the powerup sequencing is of interest.

Otherwise, and in particular for the purpose of a single voltage modification, these two sequencing-related commands are not worth further attention.

As for OPERATION and ON_OFF_CONFIG, their somewhat tangled definitions can found in the PMBus spec. Apparently, the power rail can be controlled with these commands, but I never got down to the details of this, mainly because I didn’t want to make any unnecessary experiments with the FPGA board.

I should mention that the typical setting on all power rails is ON_OFF_CONFIG = 0x02 or 0x00, which means ignoring the CONTROL input pin for the rail, and OPERATION = 0x40, which means that the power rail is turned off (with sequencing). So why is the power rail on? The only possibility left is that sequencing brought it up. The docs are somewhat lacking.

For direct control of the power rail I would try (following the positive experience reported in the green frame on this post) setting ON_OFF_CONFIG to 0x1a, and then writing 0x00 to OPERATION for turning the power rail off, and 0x80 for turning it on. Note that the OPERATION state is never stored into non-volatile memory on an UCD92xx.

Storing to non-volatile memory

All commands change the values in the power controller’s RAM (“Operating Memory”). The next time it’s powered on, defaults are loaded from an on-chip flash.

To store the current setting as power-on defaults, an STORE_DEFAULT_ALL (0x11) command is issued. It’s one of those no-data commands.

Numeric representation

Several commands represent physical parameters, such as voltage, current and temperature. The numerical format of these values is unfortunately a bit of a disaster. There are three formats used by the UCD92xx family, named below as they appear in Table 1 in SLUU337:

  • LINEAR16: The primary format for voltages. It’s a 16-bit, unsigned fixed-point fractional 4.12 representation of the voltage. This spans between 0V and almost 16 V, with a 0.2441 mV resolution. The voltage is obtained from the 16-bit word with
    unsigned short word;
    double voltage = word / 4096.0;
  • LINEAR16, signed: Used by the VOUT_CAL_OFFSET command. Same as LINEAR16, only “word” is of signed short type.
  • LINEAR11: The format used for all other non-integer parameters. This is an unsigned 16-bit floating-point word with an 11-bit mantissa and a 5-bit exponent. The parameter is obtained with
    unsigned short word;
    double x = word & 0x7ff;
    int exponent = (word >> 11) & 0xf;
    
    if (word & 0x8000)
      x /= 1 << (16 - exponent);
    else
      x *= 1 << exponent;

Note that other PMBus-based controllers probably use other formats (the PMBus spec allows a variety).

The sample C utils include the conversions of the numeric formats, of course.

At last: How to change the voltage

This is the list of voltage commands to make in order to reduce the output voltage, without turning it off. The point is to avoid any faulty conditions on the way, so the transition is smooth. This is done by lowering the limits for undervoltage first, then dropping the actual voltage to the target voltage. After that, lower the limits for overvoltage.

But before any of these, change two parameters that are probably unused generally, and surely not in effect during the operation: VOUT_MARGIN_HIGH and VOUT_MARGIN_LOW. These are relevant only when one of the “margin” modes are selected with the OPERATION command, which is probably never. The idea is to start with commands that don’t make much difference anyhow, just in case something goes wrong.

Those choosing to turn off the power rail before making the changes may update the parameters in any order.

So these are the commands, in order of execution. The commonly used diversion from the nominal voltage is given in parentheses.

  • VOUT_MAX: This parameter is intended to protect the circuitry from a voltage too high. It stands at 3.6328V on almost all rails of KC705, so just leave it as is (On SP605 it’s on 10.6890V, which is rather pointless).
  • VOUT_MARGIN_HIGH (+5%): The voltage to output when OPERATION is set to output Margin High. Probably makes no difference.
  • VOUT_MARGIN_LOW (-5%): Same as VOUT_MARGIN_HIGH, only with Margin Low output.
  • POWER_GOOD_ON (-5%): The voltage threshold which turns the “power good” state on. Note that “power good” isn’t just an output pin, but may also influence the powerup sequencing machine.
  • POWER_GOOD_OFF (-8%): The voltage at which “power good” is deasserted. Being slightly lower than POWER_GOOD_ON, there’s a Schmitt-trigger effect.
  • VOUT_UV_WARN_LIMIT (-10%): The voltage under which a warning condition is issued (except during ramp-up and when the rail is turned off).
  • VOUT_UV_FAULT_LIMIT (-12% to -15%): The voltage under which a fault condition is issued (except during ramp-up and when the rail is turned off). This may, among others, lead to the rail’s shutdown, as defined in VOUT_UV_FAULT_RESPONSE. However sequencing interdependencies may take down other rails as well following such fault.
  • VOUT_COMMAND: The desired output voltage. The point of the entire saga.
  • VOUT_OV_WARN_LIMIT (+12% to +15%): The voltage over which a warning condition is issued.
  • VOUT_OV_FAULT_LIMIT (+10%): The voltage over which a fault condition is issued. VOUT_OV_FAULT_RESPONSE controls the behavior on such fault, and sequencing interdependencies have the same effect as with VOUT_UV_FAULT_LIMIT.

In order to change the target voltage upwards, reverse the order, except for keeping VOUT_MARGIN_HIGH and VOUT_MARGIN_LOW at the beginning.

Random notes

  • Current readings may be incorrect (usually zero) if no current sensors are connected to the rail’s CS input(s). This is the case on some power rails of SP605, for example. The power source functions properly nevertheless.
  • Appendix I of Part II of the PMBus spec outlines not only the commands, but the SMBus transaction types for each (most are trivial however).

Good luck, and may the power be with you.

fetchmail, openssl and a sudden failure to authenticate certificates

Since around the beginning of December 2017, fetchmail stopped retrieving mails form Gmail servers silently, without issuing any kind of error message. Only when starting fetchmail in the foreground, I got

fetchmail: Server certificate verification error: unable to get local issuer certificate
fetchmail: This means that the root signing certificate (issued for /C=US/O=Google Trust Services/CN=Google Internet Authority G3) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page.
140703549138760:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1060:
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from ...@pop.gmail.com
fetchmail: Query status=2 (SOCKET)

That’s really cute. The SSL connection fails, but fetchmail doesn’t think it should drop me a note about it (like it does when the server refuses for a long time, for example). I should mention that I’m using an old 6.3.17 fetchmail release.

So let’s try the connection following this post (or “man s_client”):

Connect to a secure POP server:

$ openssl s_client -connect pop.gmail.com:995
CONNECTED(00000003)
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = pop.gmail.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=pop.gmail.com
   i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
 1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
[ ... ]

Huh? No problem? So why doesn’t fetchmail accept the certificate? Because in my case, certificates were read from a local directory: In .fetchmailrc, I had the “sslcertpath /home/…/.certs/” directive for each and every entry related to Gmail. That made fetchmail accept certificate authorities only from the local directory, which failed suddenly, probably due to a change in Gmail’s certificate chain.

Where did I get this directive from? Probably from the automatic configuration made by fetchmailconf. Hurray.

So the obvious solution was to drop all those “sslcertpath” directives, and all was fine again.

Not really relevant, but…

Since I was playing with openssl, it’s also possible to talk with an HTTPS server directly this way (note the GET / request close to the end):

$ openssl s_client -connect www.google.com:443
CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = www.google.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEdjCCA16gAwIBAgIIWv4BLr9C/xUwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE
BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
cm5ldCBBdXRob3JpdHkgRzIwHhcNMTcxMjEzMTMyOTExWhcNMTgwMzA3MTMwMTAw
WjBoMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEXMBUGA1UEAwwOd3d3
Lmdvb2dsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDh3H8L
+wzppO5DrRgLvOOF8nM692sA/aaFv0Hr5pQuuDluOwEV+ocY8iKwBWH2XMNTDTDz
KIuqyqAbe/DvUQ+a8HjuEGepWdBe/VY0vuxrjKc7yJs6QImmSt9dUF01LI6zKjyR
B7MNyMCtHHn2DFvD9uGocNqFXAeJrWCs2VbIqP+jj2QdVJ2WK/gV0ybyGmdyZfbw
SdDKSYKt3KK3depWai7CKeYHHNpMY8OFBLi4uWIWA28ZTzIxqb2Ar7aiZUUEzWgf
8Ak4fLsNzEuiCmouhFdBwwxDGGqDgrM+3NFk7kGoBOf2mTH6qcQ+sg2G/rVylE94
2mUhlw2viW/bAzN7AgMBAAGjggFBMIIBPTATBgNVHSUEDDAKBggrBgEFBQcDATAZ
BgNVHREEEjAQgg53d3cuZ29vZ2xlLmNvbTBoBggrBgEFBQcBAQRcMFowKwYIKwYB
BQUHMAKGH2h0dHA6Ly9wa2kuZ29vZ2xlLmNvbS9HSUFHMi5jcnQwKwYIKwYBBQUH
MAGGH2h0dHA6Ly9jbGllbnRzMS5nb29nbGUuY29tL29jc3AwHQYDVR0OBBYEFMY4
s3yyzEnrwiJ/NsB1uEETOXq6MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUSt0G
Fhu89mi1dvWBtrtiGrpagS8wIQYDVR0gBBowGDAMBgorBgEEAdZ5AgUBMAgGBmeB
DAECAjAwBgNVHR8EKTAnMCWgI6Ahhh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lB
RzIuY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQAxixLtjbT18w3iXYj6psMVK2uK21Is
Z4Oi2y5533nHqZXhb3z9K7m1ejwgL/s+bb5+D4HQdKhopO81oBf2Li9ztQ255Q24
nA1p4xkTdPV3UvFPA6R6G4muFZQmJUvIgrH/uZAXQ36K9/8aI8SgawLo1RPDWOxW
pCw4/1SfQ8FgUQmvqb+OkQ5bCXXySRhidZkCUg4DXUNsJ++HATlSEeSb4kdu4Fny
mwRBZma5muwbwRxTHCnbs1A82Ehxi0+DBjifgJy0NMyZbsgiWnyuexNAxoDVIC0I
u2xlpTBqaS1HzPpJ7K9tJ7i6AYe2YCrKo/fYBYBWaw/Q7VNDWk7NvlTs
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 3481 bytes and written 439 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: A455441C733C2CDD844EEC39DEE96FA7C6D47D38F4A6021097891DF198E60C68
    Session-ID-ctx:
    Master-Key: EA9D1453E32865C2C4F04E969103ADA4E59C8ECC2FA09F6D8F2EDAE5E75E1DE40A18FF60CED7459A4F60679BB230C663
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 100800 (seconds)
    TLS session ticket:
    0000 - 00 26 5c 16 79 2f e1 46-a4 5b 34 30 72 a1 64 b7   .&\.y/.F.[40r.d.
    0010 - 79 20 15 87 62 cd 2a 05-8f 05 ac f7 d7 38 40 66   y ..b.*......8@f
    0020 - 87 0a a9 50 55 ba 5e d2-8f 90 c0 d0 83 25 b8 3e   ...PU.^......%.>
    0030 - b7 7b eb 5a ff 30 27 aa-1b c9 a1 d9 54 c3 aa 7e   .{.Z.0'.....T..~
    0040 - 05 96 83 76 49 90 fe 8e-d9 d7 55 e0 a3 0b 5b df   ...vI.....U...[.
    0050 - aa 28 12 81 02 84 b9 47-97 cd b8 81 b8 ee 2a 1c   .(.....G......*.
    0060 - c2 8b e0 e6 92 ae 4b a3-fb 2a 8e f3 eb f5 43 7b   ......K..*....C{
    0070 - a8 e9 58 c9 22 3a 15 3d-81 a7 0b a8 1a e4 3a 55   ..X.":.=......:U
    0080 - cd 72 04 8d 0e 70 5e 60-5d 19 d7 18 a1 1b ce d9   .r...p^`].......
    0090 - 87 60 78 ec c0 f7 6e 0f-c4 5c e7 06 1a e2 c1 d0   .`x...n..\......
    00a0 - e1 46 df c2 98 d0 da fd-87 eb 9b 0f 93 8a 4c e4   .F............L.
    00b0 - 95 db da 63 b3 e2 78 08-09 75 53 b7 d1 e3 6c d2   ...c..x..uS...l.
    00c0 - b6 6f 02 26 bd 16 e4 ae-a8 01 fa 81 3f e4 55 0d   .o.&........?.U.

    Start Time: 1515438093
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
GET /
HTTP/1.0 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Referrer-Policy: no-referrer
Location: https://www.google.co.il/?gfe_rd=cr&dcr=0&ei=E8BTWoO6GqfP8AeV05m4Cg
Content-Length: 272
Date: Mon, 08 Jan 2018 19:01:39 GMT
Alt-Svc: hq=":443"; ma=2592000; quic=51303431; quic=51303339; quic=51303338; quic=51303337; quic=51303335,quic=":443"; ma=2592000; v="41,39,38,37,35"

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="https://www.google.co.il/?gfe_rd=cr&amp;dcr=0&amp;ei=E8BTWoO6GqfP8AeV05m4Cg">here</A>.
</BODY></HTML>
read:errno=0

So it’s a bit like “nc”, only with encryption.

The pin assignment of an FMC connector in CSV format

As the title says: These are the labels of an HPC (High Pin Count) FMC connector, in plain CSV format for easy handling. It was a bit odd to me that I didn’t find this info on the web myself.

Just copy-paste:

A1,GND
A2,DP1_M2C_P
A3,DP1_M2C_N
A4,GND
A5,GND
A6,DP2_M2C_P
A7,DP2_M2C_N
A8,GND
A9,GND
A10,DP3_M2C_P
A11,DP3_M2C_N
A12,GND
A13,GND
A14,DP4_M2C_P
A15,DP4_M2C_N
A16,GND
A17,GND
A18,DP5_M2C_P
A19,DP5_M2C_N
A20,GND
A21,GND
A22,DP1_C2M_P
A23,DP1_C2M_N
A24,GND
A25,GND
A26,DP2_C2M_P
A27,DP2_C2M_N
A28,GND
A29,GND
A30,DP3_C2M_P
A31,DP3_C2M_N
A32,GND
A33,GND
A34,DP4_C2M_P
A35,DP4_C2M_N
A36,GND
A37,GND
A38,DP5_C2M_P
A39,DP5_C2M_N
A40,GND
B1,RES1
B2,GND
B3,GND
B4,DP9_M2C_P
B5,DP9_M2C_N
B6,GND
B7,GND
B8,DP8_M2C_P
B9,DP8_M2C_N
B10,GND
B11,GND
B12,DP7_M2C_P
B13,DP7_M2C_N
B14,GND
B15,GND
B16,DP6_M2C_P
B17,DP6_M2C_N
B18,GND
B19,GND
B20,GBTCLK1_M2C_P
B21,GBTCLK1_M2C_N
B22,GND
B23,GND
B24,DP9_C2M_P
B25,DP9_C2M_N
B26,GND
B27,GND
B28,DP8_C2M_P
B29,DP8_C2M_N
B30,GND
B31,GND
B32,DP7_C2M_P
B33,DP7_C2M_N
B34,GND
B35,GND
B36,DP6_C2M_P
B37,DP6_C2M_N
B38,GND
B39,GND
B40,RES0
C1,GND
C2,DP0_C2M_P
C3,DP0_C2M_N
C4,GND
C5,GND
C6,DP0_M2C_P
C7,DP0_M2C_N
C8,GND
C9,GND
C10,LA06_P
C11,LA06_N
C12,GND
C13,GND
C14,LA10_P
C15,LA10_N
C16,GND
C17,GND
C18,LA14_P
C19,LA14_N
C20,GND
C21,GND
C22,LA18_P_CC
C23,LA18_N_CC
C24,GND
C25,GND
C26,LA27_P
C27,LA27_N
C28,GND
C29,GND
C30,SCL
C31,SDA
C32,GND
C33,GND
C34,GA0
C35,12P0V
C36,GND
C37,12P0V
C38,GND
C39,3P3V
C40,GND
D1,PG_C2M
D2,GND
D3,GND
D4,GBTCLK0_M2C_P
D5,GBTCLK0_M2C_N
D6,GND
D7,GND
D8,LA01_P_CC
D9,LA01_N_CC
D10,GND
D11,LA05_P
D12,LA05_N
D13,GND
D14,LA09_P
D15,LA09_N
D16,GND
D17,LA13_P
D18,LA13_N
D19,GND
D20,LA17_P_CC
D21,LA17_N_CC
D22,GND
D23,LA23_P
D24,LA23_N
D25,GND
D26,LA26_P
D27,LA26_N
D28,GND
D29,TCK
D30,TDI
D31,TDO
D32,3P3VAUX
D33,TMS
D34,TRST_L
D35,GA1
D36,3P3V
D37,GND
D38,3P3V
D39,GND
D40,3P3V
E1,GND
E2,HA01_P_CC
E3,HA01_N_CC
E4,GND
E5,GND
E6,HA05_P
E7,HA05_N
E8,GND
E9,HA09_P
E10,HA09_N
E11,GND
E12,HA13_P
E13,HA13_N
E14,GND
E15,HA16_P
E16,HA16_N
E17,GND
E18,HA20_P
E19,HA20_N
E20,GND
E21,HB03_P
E22,HB03_N
E23,GND
E24,HB05_P
E25,HB05_N
E26,GND
E27,HB09_P
E28,HB09_N
E29,GND
E30,HB13_P
E31,HB13_N
E32,GND
E33,HB19_P
E34,HB19_N
E35,GND
E36,HB21_P
E37,HB21_N
E38,GND
E39,VADJ
E40,GND
F1,PG_M2C
F2,GND
F3,GND
F4,HA00_P_CC
F5,HA00_N_CC
F6,GND
F7,HA04_P
F8,HA04_N
F9,GND
F10,HA08_P
F11,HA08_N
F12,GND
F13,HA12_P
F14,HA12_N
F15,GND
F16,HA15_P
F17,HA15_N
F18,GND
F19,HA19_P
F20,HA19_N
F21,GND
F22,HB02_P
F23,HB02_N
F24,GND
F25,HB04_P
F26,HB04_N
F27,GND
F28,HB08_P
F29,HB08_N
F30,GND
F31,HB12_P
F32,HB12_N
F33,GND
F34,HB16_P
F35,HB16_N
F36,GND
F37,HB20_P
F38,HB20_N
F39,GND
F40,VADJ
G1,GND
G2,CLK1_M2C_P
G3,CLK1_M2C_N
G4,GND
G5,GND
G6,LA00_P_CC
G7,LA00_N_CC
G8,GND
G9,LA03_P
G10,LA03_N
G11,GND
G12,LA08_P
G13,LA08_N
G14,GND
G15,LA12_P
G16,LA12_N
G17,GND
G18,LA16_P
G19,LA16_N
G20,GND
G21,LA20_P
G22,LA20_N
G23,GND
G24,LA22_P
G25,LA22_N
G26,GND
G27,LA25_P
G28,LA25_N
G29,GND
G30,LA29_P
G31,LA29_N
G32,GND
G33,LA31_P
G34,LA31_N
G35,GND
G36,LA33_P
G37,LA33_N
G38,GND
G39,VADJ
G40,GND
H1,VREF_A_M2C
H2,PRSNT_M2C_L
H3,GND
H4,CLK0_M2C_P
H5,CLK0_M2C_N
H6,GND
H7,LA02_P
H8,LA02_N
H9,GND
H10,LA04_P
H11,LA04_N
H12,GND
H13,LA07_P
H14,LA07_N
H15,GND
H16,LA11_P
H17,LA11_N
H18,GND
H19,LA15_P
H20,LA15_N
H21,GND
H22,LA19_P
H23,LA19_N
H24,GND
H25,LA21_P
H26,LA21_N
H27,GND
H28,LA24_P
H29,LA24_N
H30,GND
H31,LA28_P
H32,LA28_N
H33,GND
H34,LA30_P
H35,LA30_N
H36,GND
H37,LA32_P
H38,LA32_N
H39,GND
H40,VADJ
J1,GND
J2,CLK3_M2C_P
J3,CLK3_M2C_N
J4,GND
J5,GND
J6,HA03_P
J7,HA03_N
J8,GND
J9,HA07_P
J10,HA07_N
J11,GND
J12,HA11_P
J13,HA11_N
J14,GND
J15,HA14_P
J16,HA14_N
J17,GND
J18,HA18_P
J19,HA18_N
J20,GND
J21,HA22_P
J22,HA22_N
J23,GND
J24,HB01_P
J25,HB01_N
J26,GND
J27,HB07_P
J28,HB07_N
J29,GND
J30,HB11_P
J31,HB11_N
J32,GND
J33,HB15_P
J34,HB15_N
J35,GND
J36,HB18_P
J37,HB18_N
J38,GND
J39,VIO_B_M2C
J40,GND
K1,VREF_B_M2C
K2,GND
K3,GND
K4,CLK2_M2C_P
K5,CLK2_M2C_N
K6,GND
K7,HA02_P
K8,HA02_N
K9,GND
K10,HA06_P
K11,HA06_N
K12,GND
K13,HA10_P
K14,HA10_N
K15,GND
K16,HA17_P_CC
K17,HA17_N_CC
K18,GND
K19,HA21_P
K20,HA21_N
K21,GND
K22,HA23_P
K23,HA23_N
K24,GND
K25,HB00_P_CC
K26,HB00_N_CC
K27,GND
K28,HB06_P_CC
K29,HB06_N_CC
K30,GND
K31,HB10_P
K32,HB10_N
K33,GND
K34,HB14_P
K35,HB14_N
K36,GND
K37,HB17_P_CC
K38,HB17_N_CC
K39,GND
K40,VIO_B_M2C

+5V voltage feed on HDMI cables and a failing HDMI2AV converter

HDMI to AV converter (Composite Video + Audio on RCA plugs)

After quite a while of working perfectly well, the mini HDMI2AV module I have (in the picture above, mentioned in this post) started producing an unstable picture, and in the end a completely garbled one. It took some time to nail down this specific component in the foodchain, because there was also an HDMI splitter involved.

The problem, as it turned out, was that this module takes voltage from the HDMI plug, if such is available, instead of the dedicated power plug. In my specific setup, it seems like there was some voltage was available, but not enough to drive the device — because the HDMI plug was connected to the HDMI splitter. I suppose some internal power supply switch went into some not-here-not-there kind of situation, and eventually got some permanent damage. The other HDMI2AV unit I have didn’t work either in the same conditions, but probably didn’t reach the point of permanent damage (so it’s working right now).

On an HDMI connector, Pin 18 is +5V, minimum 55 mA, intended originally to feed the monitor with voltage even if it’s shut off, so its DDC (EDID) information can be obtained. Some devices (e.g. cheap HDMI splitters and HDMI to AV converters) might use this voltage instead of the supplied external voltage in some cases.

HDMI connector pinoutNot all cables conduct this pin. It’s therefore advisable to check the cable before working with it, when the setup is more than just a direct connection. It’s not easy, even with a multimeter. Pushing a thin wire into the tiny holes at the front may give contact with the relevant pin, but this isn’t bulletproof. Possibly try with an HDMI/DVI adapter (pin 14 on a DVI connector is +5V). Or test with a device that is known to rely on this voltage (e.g. this HDMI2AV module).

The solution in my case was to replace the HDMI2AV module and all cables with such that don’t let the +5V wire through. In particular, it seems like the cable to the TV set (via HDMI) that went to the HDMI splitter (which connects to the HDMI2AV module on its other output) was the issue.

Lubuntu 16.04 on ARM: Turning off the “Suspend” etc. options

In short

On an embedded ARM-based Lubuntu 16.04, I had LXDE’s logoff dialog window offering suspend as an option, and when that was chosen, the system got itself into some nasty state with network and keyboard off. The serial console was still active, and yet, I was better off without it.

It turned out that the kernel was misconfigured to announce that it supported suspend to RAM:

# cat /sys/power/state
freeze mem

So no wonder that option was presented to the user on GUI. The solution: Turn off the CONFIG_SUSPEND kernel compilation flag. Recompile, deploy, and that’s it:

# cat /sys/power/state
#

And the faulty options were gone.

The rest of this post contains things I jotted down as I wasted time trying to find out what the problem was.

Irrelevant notes

  • There’s a systemd-inhibit utility for preventing suspends and sleeps while a certain program is running. Essentially, it issues an “Inhibit” command with what / who, why /mode info on DBus for”org.freedesktop.login1″.
  • polkit’s manual (“man polkit” lacks some info) directs to a list of directories with rules.d files written in JavaScript (!!!). The action/ directories are policy files, in XML, which describe who might be allowed what operation, and what to write (in several languages) in the dialog box asking for authentication (typically a password).
  • Obtaining the sources for the study below
    # apt-get source lxsession-logout
    # apt-get source systemd

A journey in the sources (more wasted time)

I tried to follow how lxsession-logout, which is LXDE’s program that displays the logout dialog box, decides which low-power modes to offer. And what actually happens when suspend is requested.

  • lxsession-logout.c learns if the system can suspend (and hence the button shall be presented) by calling dbus_systemd_CanSuspend().
  • which is implemented in lxsession-logout-dbus-interface.c, and calls systemd_query() with “CanSuspend” as its parameter
  • which (implemented in the same file) in turn opens a session with “org.freedesktop.login1″ over DBus and issues a query
  • Judging by the “BusName=org.freedesktop.login1″ directive in /lib/systemd/system/systemd-logind.service, systemd-logind.service, (running systemd-login) is answering this query.
  • Looking in systemd’s login-dbus.c, “CanSuspend” calls the method method_can_suspend(), which in turn calls method_can_shutdown_or_sleep() with “org.freedesktop.login1.suspend” as the key argument, which calls bus_test_polkit() for an answer on that.
  • Implemented in systemd/shared/bus-util.c, bus_test_polkit() makes a DBus query on “org.freedesktop.PolicyKit1″
  • There are also references to upowerd in lxsession-logout.c, but since stopping this service changes nothing, I focused on logind.
  • Judging by the “BusName=org.freedesktop.PolicyKit1″ directive in /lib/systemd/system/polkitd.service, polkitd.service (running /usr/lib/policykit-1/polkitd) answer this.
  • Back to login-dbus.c, a “Suspend” request causes a call to method_suspend(), which calls method_do_shutdown_or_sleep(), which calls bus_manager_shutdown_or_sleep_now_or_later(), which calls execute_shutdown_or_sleep(). The “unitname” parameter traverses these calls with the value SPECIAL_SUSPEND_TARGET. There are several checks on the way that may cancel the request, but this is the chain to fulfilling it.
  • execute_shutdown_or_sleep() issues a DBus request on “org.freedesktop.systemd1″ (I have a wild guess which process is on the other side).
  • Apparently (without following the execution chain), systemd/src/sleep.c is responsible for putting the system in suspend mode and such. Among others, it writes to /sys/power/state. This is where it hit me that maybe the kernel’s configuration was the problem.

systemd random jots

As systemd seems to be here to stay (or at least I hope so), this is a post of random notes to self that I jot down as I explore it. It will probably grow with time, and become a mixture of basic issues and rather advanced stuff.

Useful references

  • man systemd.service and man systemd.unit as well as others. Really. These are the best sources, it turns out.
  • The excellent Systemd for Admins series (with several relevant and specific topics).
  • The primer for systemd: Basic concepts explained.
  • Red Hat’s guide to creating custom targets (and daemons)
  • The FAQ (with actually useful info!)
  • On the Network Target (and how to run a target only when the network is up)
  • man systemd.special for a list of built-in targets, their meaning and recommended use

systemctl is the name of the game

Forget “service”, “telinit” and “initctl”. “systemctl” is the new swiss knife for starting, stopping, enabling and disabling services, as well as obtaining information on how services are doing. And it’s really useful.

To get an idea on what runs on the system and what unit triggered it off, go

# systemctl status

Note that “systemd status” lists, among others, all processes initiated by each login session for each user. Which is an extremely useful variant of “ps”.

And just a list of all services

# systemctl

Ask about a specific service:

# systemctl status ssh
 ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2017-12-01 10:37:21 IST; 1h 17min ago
 Main PID: 1018 (sshd)
   CGroup: /system.slice/ssh.service
           └─1018 /usr/sbin/sshd -D

Dec 01 12:26:26 machine sshd[2841]: Accepted publickey for eli from 192.168.1.12 port 45220 ssh2: RSA SHA256:xxx
Dec 01 12:26:26 machine sshd[2841]: pam_unix(sshd:session): session opened for user eli by (uid=0)

Really, isn’t it sweet?

Turning off a service: Find it with the “systemctl status” command above (or just “systemctl”), and then (this is an example of a service not found in the status, because it’s an LSB service);

# systemctl disable tvheadend
tvheadend.service is not a native service, redirecting to systemd-sysv-install
Executing /lib/systemd/systemd-sysv-install disable tvheadend
insserv: warning: current start runlevel(s) (empty) of script `tvheadend' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `tvheadend' overrides LSB defaults (0 1 6).

And “enable” for enabling a service.

Needless to say, services can be started, stopped and restarted with “systemctl X service” where X is either start, stop or restart.

For a list of all services (including disactivated):

$ systemctl --all

What makes a systemd service run (on boot)

  • It’s enabled, which means that there’s a symbolic link from some /etc/systemd/*/*.wants directory to the unit file. In the example below, it’s a .path file, so it activates a watch on the path specified, but if it’s a service, it’s kicked off at boot
    # systemctl enable foo.path
        Created symlink from /etc/systemd/system/paths.target.wants/foo.path to /etc/systemd/system/foo.path
  • In the unit file symlinked to, there’s an [Install] section, which says when it should be kicked off with the WantedBy directive. More precisely, which target or service should be active. Once again, for a plain .service unit file, this kicks off the service, and for an e.g. .path file, this starts the monitoring. man systemd.special for a list of built in targets, and targets can be generated, of course. The most common target for “run me at boot” is multi-user.target. Dependency on services is expressed by using the service name with a .service suffix instead.
  • By default, unit files such as .path files kick off the a .service file with the same non-suffix part (this can be changed with a directive in the file. But why?)

See /etc/systemd/system/multi-user.target.wants for a list of services that are activated on boot. In particular note that not all are symlinks to .service unit files.

General memo jots

  • Always run the systemctl daemon-reload command after creating new unit files or modifying existing unit files. Otherwise, the systemctl start or systemctl enable commands could fail due to a mismatch between states of systemd and actual service unit files on disk.
  • Services are best run in the foreground. Unlike classic UNIX services, there’s no point in daemonizing. All processes belonging to the relevant service are enclosed in a Cgroup anyhow, and systemd handles the daemonizing for Type=simple services. In a clean and uniform manner.
  • Unit files’ suffix indicate their type. When the non-suffix part of two files is the same, they indicate a functional relationship. For example, systemd-tmpfiles-clean.timer says when to launch systemd-tmpfiles-clean.service. Or that systemd-ask-password-console.path gives the path to be watched, and systemd-ask-password-console.service is the service to fire off.
  • After= doesn’t imply a dependency, and Requires= doesn’t imply the order of starting services. Both are needed if one service depends on the other running when it starts.
  • The Type= directive’s main influence is determining when the service is active, i.e. when other services that depend on it can be launched.
  • There’s also “loginctl” which lists the current users and their sessions

Where to find unit files

The configuration files are considered in the following order (later overrules earlier):

  • /lib/systemd/system — where installation scripts write to
  • /run/systemd/system — runtime files
  • /etc/systemd/system — per-system user preferences

Per-user files can be found in ~/.config/systemd/user and possibly also in ~/.local/share/systemd/user.

Enabling console autologin on tty1 and ttyPS0

Following this page and as explained on this page, add /etc/systemd/system/getty@tty1.service.d/autologin.conf (after creating the getty@tty1.service.d directory) as follows:

[Service]
ExecStart=
ExecStart=-/sbin/agetty -a root --noclear %I $TERM

Note that the filename autologin.conf has no significance. It’s suffix and the directory it resides in that matter.

The idea is to override the ExecStart parameter given in /lib/systemd/system/getty@.service template unit, which reads

ExecStart=-/sbin/agetty --noclear %I $TERM

but otherwise have it running the same. The reason for two ExecStart lines is that the empty assignment clears the existing assignment (or otherwise it would have been added on top of it), and the second sets the command.

Note the %I substitute parameter, which stands for the instance of the current tty.

The leading dash means that the exit value of the command is ignored, and may be nonzero without the unit considered as failed (see man systemd.service).

This can’t be repeated with ttyPS0, because systemd goes another way for setting up the serial console: At an early stage in the boot, systemd-getty-generator automatically sets a target, serial-getty@ttyPS0.service, which is implemented by the /lib/systemd/system/serial-getty@.service template unit.

# systemctl status

[ ... ]

         │ ├─system-serial\x2dgetty.slice
           │ │ └─serial-getty@ttyPS0.service
           │ │   └─2337 /sbin/agetty --keep-baud 115200 38400 9600 ttyPS0 vt220

So the solution is adding /etc/systemd/system/serial-getty@ttyPS0.service.d/autologin.conf saying

[Service]
ExecStart=
ExecStart=-/sbin/agetty -a root --keep-baud 115200,38400,9600 %I $TERM

… more to come …

A watchdog script for restarting Cinnamon hogging memory at startup

Introduction

Having installed Linux Mint 18.1 (kernel 4.4.0-53) with overlayroot on a Gigabyte Brix BACE-3160 (see other notes on this here and here) for my living room media center, I had an issue with bringing up the computer every now and then. Namely, I had a blank screen with mouse pointer only, 100% CPU on the cinnamon process, and some 50% on cinnamon-settings-daemon, eating all RAM (8 GB) gradually until the computer crashes (as it’s swapless).

The whole point with an overlayroot based media center is that it behaves like any electrical appliance. In particular, you know it will recover well from a power outage. And not crash because of some silly desktop manager messing up.

I’m not alone: There’s a bug report on this. There’s also this Git Hub issues page seems to point at the problem, in particular as it was closed pointing at a commit, which was merged into the main repository saying “Add detection for accountsservice background as it’s ubuntu only”.

It seems to be more common with SSD disks (because they’re faster).

And still there’s no solution available, almost a year later. Don’t tell me to upgrade. Upgrading means trading known bugs for new, unknown ones.

Which leaves me with making a workaround. In this case, a watchdog service, which monitors the resident memory usage of the process having the command line “cinnamon”. If it goes above 300 MiB during its first five minutes (more or less), restard the mdm service, which in turn restarts Cinnamon. Plain and disgusting.

The ironic truth is that I haven’t been able to test the watchdog for real, as I’ve failed to repeat the problem, despite a lot of power cycles. But I have verified that it works by lowering the memory threshold, and confirmed that the mdm service is indeed restarted. I also know from previous experience that restarting mdm helps.

The stuff

This should be copied to /usr/local/bin/cinnamon-watchdog.pl (executable at least by root):

#!/usr/bin/perl
use warnings;
use strict;

my $cmd = 'cinnamon';
my $limit = 200; # Maximal resident memory size in MiB
my $timeout = 300; # Approximately how long this script should run, in seconds

my $pid;
my $timer = 0;
my $rss = 0;

eval {
  while (1) {
    $timer++;

    if ($timer >= $timeout) {
      if (defined $pid) {
	logger("Quitting. cinnamon process seems to behave well with $rss MiB resident memory");
      } else {
	logger("Quitting without finding the cinnamon process")
      }
      last;
    }

    sleep(1);

    undef $pid if ((defined $pid) && !is_target($cmd, $pid));

    $pid = find_target($cmd) unless (defined $pid);

    next unless (defined $pid); # No target process running yet?

    $rss = resident_memory($pid);

    if ($rss > $limit) {
      $timer = 0;
      logger("Restarting cinnamon: Has reached $rss MiB resident memory");
      system('/bin/systemctl', 'restart', 'mdm') == 0
	or die("Failed to restart mdm service\n");
    }
  }
};

if ($@) {
  logger("Process died: $@");
  exit(1);
}

exit(0);

######## SUBROUTINES ########

sub find_target {
  my $target = shift;
  foreach my $entry (</proc/*>) {
    my ($pid) = ($entry =~ /^\/proc\/(\d+)$/);
    next unless (defined $pid);

    return $pid
      if (is_target($target, $pid));
  }

  return undef;
}
sub is_target {
  my ($target, $pid) = @_;
  my ($cmdline, $c);

  local $/;

  open (F, "/proc/$pid/cmdline") or return 0;
  $cmdline = <F>;
  close F;

  return 0 unless (defined $cmdline);

  ($c) = ($cmdline =~ /^([^\x00]*)/);

  return $target eq $c;
}

sub resident_memory {
  my ($pid) = @_;

  local $/;

  open (F, "/proc/$pid/statm") or return 0;
  my $mem = <F>;
  close F;

  return 0 unless (defined $mem);

  my @entries = ($mem =~ /(\d+)/g);

  return 0 unless (defined $entries[1]); # Should never happen

  return int($entries[1] / 256); # Convert pages to MiBs
}

sub logger {
  my $msg = shift;
  system('/usr/bin/logger', "cinnamon-watchdog: $msg") == 0
    or warn("Failed to call logger\n");
}

And this service unit file to /etc/systemd/system/cinnamon-watchdog.service:

[Unit]
Description=Cinnamon watchdog service

[Service]
ExecStart=/usr/local/bin/cinnamon-watchdog.pl
Type=simple

[Install]
WantedBy=multi-user.target

Enable service:

# systemctl enable cinnamon-watchdog
Created symlink from /etc/systemd/system/multi-user.target.wants/cinnamon-watchdog.service to /etc/systemd/system/cinnamon-watchdog.service.

That’s it. The service will be active on the next reboot

A few comments on the Perl script

  • The script monitors the memory consumption because it’s a simple and safe indication of the problem, not the problem itself.
  • It accesses the files under /proc/ directly rather than obtaining the information from e.g. ps. I suppose the proc format is more stable than ps’ output. The ps utility obtains its information from exactly the same source.
  • The script exits voluntarily after slightly more than $timeout seconds after its invocation or its last intervention. In other words, if the cinnamon process hogs memory after its first five minutes, the script won’t be there to do anything. Neither should it. Its purpose is very specific.
  • The 200 MiB limit is based upon experience with my own system: It usually ends up with 123 MiB or so.

Random vaguely related notes

Before going for this ugly solution, I actually tried to find the root of the problem (and obviously failed). Below are some random pieces of info I picked up while doing so.

The mdm setup files, in this order:

  • /usr/share/mdm/defaults.conf
  • /usr/share/mdm/distro.conf
  • /etc/mdm/mdm.conf

Things I tried that didn’t help:

  • removing Background line from /var/lib/AccountsService/users/ as suggested below (didn’t make any difference)
  • Replacing autologin with a timed login of 10 seconds (I suspected that the problem was that Accountservice wasn’t up when it was required to say which background to put).

Additional ramblings

It seemed to be a result of the Accountservice daemon attempting to fiddle with the background image.

So in /var/lib/AccountsService/users/ there’s a file called “eli” (my user name, obviously), which says

[User]
Background=/usr/share/backgrounds/linuxmint/default_background.jpg
SystemAccount=false

So what happens if I remove the Background line? Nothing. That is, the problem remains as before.

A sample .xsession-errors when things went wrong

initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/u
pstart: Connection refused
syndaemon: no process found
/etc/mdm/Xsession: Beginning session setup...
localuser:eli being added to access control list
** Message: couldn't access control socket: /run/user/1010/keyring/control: No s
uch file or directory
** Message: couldn't access control socket: /run/user/1010/keyring/control: No s
uch file or directory
SSH_AUTH_SOCK=/run/user/1010/keyring/ssh
SSH_AUTH_SOCK=/run/user/1010/keyring/ssh

(cinnamon-settings-daemon:2002): power-plugin-WARNING **: session inhibition not
 available, cinnamon-session is not available

(cinnamon-settings-daemon:2002): power-plugin-WARNING **: session inhibition not
 available, cinnamon-session is not available

systemd user services and Pulseaudio on Lubuntu 16.04

Introduction

These are my notes as I made Pulseaudio work on an ARM v7-based Embedded Lubuntu 16.04, which doesn’t support Pulseaudio otherwise.

The goal: On a mini-distribution based upon Lubuntu, for use of others, make Pulseaudio work even though the Lubuntu desktop won’t start it. In fact, it’s supposed to run even without any X server running.

Being an embedded distribution, basically everything (except for certain daemons that drop their privileges) runs as root. Nothing one should try on a desktop computer, but it’s a very common practice on embedded mini-distros. Raspbian excluded.

The problem

There are basically two ways to run pulseaudio: Per-user (actually, per-session) and in system mode, which is discouraged, mostly for security reasons. Given that pulseaudio runs as root on a system where the user is root, I’m not so sure it would have made such a difference. This way or another, I went for user mode.

Which bring me to the actual problem: On a systemd-based OS, pulseaudio expects the XDG_RUNTIME_DIR environment variable to be set to /run/user/UID on its invocation, where UID is the number of the user which shall have access to Pulseaudio. Not only that, this directory must exist when pulseaudio is launched.

Some systemd background

The /run/user/ tmpfs-mounted directory is maintained by pam_systemd (see man pam_systemd, and possibly this too), which adds an entry with a UID when the respective user starts its first session (typically by logging in somehow), and removes this directory (and its content) when the last session for this user is finished.

Among other things pam_systemd does when a user creates its first session, is starting a new instance of the system service user@.service, which runs the systemd user manager instance (typically the template service /lib/systemd/system/user@.service). Which in turn calls “/lib/systemd/systemd –user” with the user ID set to the relevant uid by virtue of a “User=” directive in the said service unit file. So this is how we end up with something like:

# systemctl status
[ ... ]
          └─user.slice
             └─user-0.slice
               ├─user@0.service
               │ └─init.scope
               │   ├─2227 /lib/systemd/systemd --user
               │   └─2232 (sd-pam)
               ├─session-c1.scope
               │ ├─2160 /bin/login -f
               │ ├─2238 -bash
[ ... ]

An important aspect of the systemd –user call is that User Services are executed as required: The new user-systemd reads unit files (i.e. the *.wants directories) from ~/.config/systemd/user/, /etc/systemd/user/ and /usr/lib/systemd/user/.

This feature allows certain services to run as long as a specific user has at least one session open, running with this user’s UID. Quite helpful for the Pulseaudio service.

From a practical point of view, the difference from regular systemd services is that the service files are put in the systemd/user directory rather than systemd/system. The calls to systemctl also need to indicate that we’re dealing with user services. The –user flag makes systemctl relate to user services that are enabled or disabled for each user separately, while the –global flag relates to user services that are enabled or disabled for all users. This is reflected in the following:

# systemctl --user enable tryuser
Created symlink from /root/.config/systemd/user/default.target.wants/tryuser.service to /etc/systemd/user/tryuser.service.

which is just for the user calling systemctl, versus

# systemctl --global enable tryuser
Created symlink /etc/systemd/user/default.target.wants/tryuser.service, pointing to /etc/systemd/user/tryuser.service.

which enables a user service for each user that has a session in the system. Note that in both cases, the original service unit file was in the same directory, /etc/systemd/user/.

Another little remark: Since the launch of a user service depends on a very specific event (at least one user having a session), the WantedBy directive is typically set ot default.target. No need to fuss.

And almost needless to say, there might be several user services running in parallel, one for each user having an active session. Note however that neither “sudo” or “su” generate a new session, as they merely start a process (with a shell) with another user (root).

A pulseaudio service

This solution isn’t perfect, but will probably work well for most people. That is, those who simply log in as themselves (or use auto-login).

Add this as/etc/systemd/user/my_pulseaudio.service:

[Unit]
Description=User Pulseaudio service
After=dbus.service
Requires=dbus.service

[Service]
Environment="XDG_RUNTIME_DIR=/run/user/%U"
ExecStart=/usr/bin/pulseaudio
Type=simple

[Install]
WantedBy=default.target

Note that the service depends and runs after dbus.service, since Pulseaudio attempts to connect to DBus, among others. Probably not very important, as DBus is likely to already run when a user session starts. Besides, in my specific case, the connection with DBus failed, and yet Pulseaudio worked fine. From /var/log/syslog:

Nov 30 16:28:18 localhost pulseaudio[2093]: W: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbu
s-daemon without a $DISPLAY for X11

Also pay attention to the %U substitution into the numeric UID, while setting the environment.

To enable this service for all users,

 # systemctl --global enable my_pulseaudio
    Created symlink /etc/systemd/user/default.target.wants/my_pulseaudio.service, pointing to /etc/systemd/user/my_pulseaudio.service.

The multi-user problem

In a way, it’s quite interesting that the standard method for using Pulseaudio gives access to a single user. In particular, as Pulseaudio was originally developed to allow simultaneous access of the sound hardware by several pieces of software. Even so, it ended up tuned to the single user scenario: One single user sitting in front the computer. If there are processes belonging to other users, they are bogus users, such as “apache” or “dovecot”, which are intended for controlling privileges.

In recent distributions, it seems like pulseaudio is started by the X server, with the user owning it (i.e. the one who has logged in, typically through the GUI login interface). Once again, access to the sound card is given to one single user, who is supposedly sitting in front of a computer. This is the model Microsoft grew its operating systems with.

There’s always the system mode alternative or allowing TCP connections, but these are not mainstream. In theory, there should have been some privilege access mechanism for Pulseaudio, allowing an arbitrary group of clients to connect as required. But since the by far most common usage scenario of sound is part of a GUI experience for the user in front of the machine, Pulseaudio was shaped accordingly.

The main problem of the solution above is that it doesn’t work in a multi-user scenario: The first user creating a session will have audio access. If another user creates a session, the attempt to launch pulseaudio will fail, leaving this user without sound.

To demonstrate how absurd it can get, suppose that user X connects to the system through ssh (and hence generates a session). This user will have pulseaudio running on its behalf, even though it can’t play any sound on the system. Then user Y logs in on the GUI console, but its pulseaudio service fails to launch, because there’s already one running. To make things even more absurd, if user X logs out, its pulseaudio service is killed, and a service for user Y doesn’t start, because what would kick it off?

It doesn’t help checking if the session that launched my_pulseaudio has a console (man loginctl for example), because user X might log in with ssh first (my_pulseaudio launched, but doesn’t activate a pulseaudio process) and then through the console (my_pulseaudio won’t be launched).

In reality, none of these problems are expected to happen often. We all end up logging into a computer with one specific user.

A less preferred alternative: Waiting for /run/user/0

As I tried to find a proper solution, I came up with the idea to launch the service when /run/user/o is created. It’s a working solution in my specific case, where only root is expected to log in.

The idea is simple. Make a path-based launch of the service when /run/user/0 is created.

/etc/systemd/system/my_pulseaudio.path is then:

[Unit]
Description=Detection of session for user 0 before launching Pulseaudio

[Path]
PathExists=/run/user/0

[Install]
WantedBy=paths.target

And the following is /etc/systemd/system/my_pulseaudio.service:

[Unit]
Description=Pulseaudio for user 0
After=dbus.service
Requires=dbus.service

[Service]
Environment="XDG_RUNTIME_DIR=/run/user/0"
ExecStart=/usr/bin/pulseaudio
Type=simple

and then enable the service with

# systemctl enable my_pulseaudio.path
Created symlink from /etc/systemd/system/paths.target.wants/my_pulseaudio.path to /etc/systemd/system/my_pulseaudio.path.

This works effectively like the user service for pulseaudio suggested above, but only for user 0. It might be modified to watch for changes in /run/user, and launch a script which evaluates which actions to take (possibly killing one pulseaudio daemon in favor of another?). But it will still not solve the case where a user logs in with ssh first, and then through the console. So the perfect solution should probably hook on session starts and terminations. However that is done.

The updated DVB-T channels in Israel

Background

On November 1, 2017, the Israeli broadcast authorities split Channel 2 into two channels, 12 and 13. To avoid unfair competition with the other channels, as channel 2 might lose viewers due to the confusion, channel 10 was moved to 14 as well. This requires a rescan of DVB receivers. The changes are rather minor, it turns out.

For the record, I still haven’t attempted to receive the DVT-T2 channels. Not enough motivation, and it probably requires some work with my DVB-T2 dongle (drivers etc.)

The scan

Running a scan in Haifa, Israel, on November 1st 2017 (quite evidently, I received on 538 MHz):

$ dvbv5-scan /usr/share/dvb/dvb-t/il-All
Cannot calc frequency shift. Either bandwidth/symbol-rate is unavailable (yet).
Scanning frequency #1 514000000
 (0x00)
Scanning frequency #2 538000000
Lock   (0x1f)
Service Ch 11, provider Idan +: digital television
Service Ch 23, provider Idan +: digital television
Service Ch 12 Keshet, provider Idan +: digital television
Service Ch 13 Reshet, provider Idan +: digital television
Service Ch 14 10, provider Idan +: digital television
Service Ch 99, provider Idan +: digital television
Service Tarbut, provider Idan +: digital radio
Service Bet, provider Idan +: digital radio
Service Gimmel, provider Idan +: digital radio
Service Makan, provider Idan +: digital radio
Service Moreshet, provider Idan +: digital radio
Service Kan88, provider Idan +: digital radio
Service Musica, provider Idan +: digital radio
Service Reka, provider Idan +: digital radio
Service Galatz, provider Idan +: digital radio
Service Galgalatz, provider Idan +: digital radio
Service Radios, provider Idan +: digital radio
Service Kol Hai, provider Idan +: digital radio
Service Kol Barama, provider Idan +: digital radio
Service Lev HaMdina, provider Idan +: digital radio
Service CLASSICAL bu, provider Idan +: digital radio

Looking at the new dvb_channel.conf, the following changes are evident:

  • “Ch 1″ has been renamed to “Ch 11″, and a new audio PID has been added to it (2563)
  • “Ch 2″ has been replaced with “Ch 12 Keshet”. Two subtitle PIDs has been dropped (2610 and 2609)
  • “Ch 10″ has been replaced with “Ch 14 10″, same PIDs for video/audio, but the subtitles have moved from 2642, 2641 and 2640 to 1039, 1038 and 1037.
  • “Ch 33″ has been replaced with “Ch 13 Reshet”, with subtitle PID 1033 added.
  • The radio channel “Aleph” has been renamed to “Tarbut”
  • The radio channel “Dalet” has been renamed to “Makan”
  • The radio channel “88FM” has been renamed to “Kan88″.
  • A new radio channel, “Kol Hai” has been added with service ID 40.

So from a DVB point of view, “Ch 12 Keshet” is the new Channel 2.

The updated dvb_channel.conf

Obtained with the dvb5-scan as shown above:

[Ch 11]
 SERVICE_ID = 1
 VIDEO_PID = 2561
 AUDIO_PID = 2562 2563
 PID_06 = 1025
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Ch 23]
 SERVICE_ID = 2
 VIDEO_PID = 3585
 AUDIO_PID = 3586
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Ch 12 Keshet]
 SERVICE_ID = 3
 VIDEO_PID = 2593
 AUDIO_PID = 2594 2595
 PID_06 = 2608
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Ch 13 Reshet]
 SERVICE_ID = 4
 VIDEO_PID = 2657
 AUDIO_PID = 2658
 PID_06 = 1033
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Ch 14 10]
 SERVICE_ID = 5
 VIDEO_PID = 2625
 AUDIO_PID = 2626 2627
 PID_06 = 1039 1038 1037
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Ch 99]
 SERVICE_ID = 6
 VIDEO_PID = 2689
 AUDIO_PID = 2690
 PID_06 = 2704
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Tarbut]
 SERVICE_ID = 21
 AUDIO_PID = 2817
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Bet]
 SERVICE_ID = 22
 AUDIO_PID = 2833
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Gimmel]
 SERVICE_ID = 23
 AUDIO_PID = 2849
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Makan]
 SERVICE_ID = 24
 AUDIO_PID = 2865
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Moreshet]
 SERVICE_ID = 25
 AUDIO_PID = 2881
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Kan88]
 SERVICE_ID = 26
 AUDIO_PID = 2897
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Musica]
 SERVICE_ID = 27
 AUDIO_PID = 2913
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Reka]
 SERVICE_ID = 28
 AUDIO_PID = 2929
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Galatz]
 SERVICE_ID = 29
 AUDIO_PID = 2945
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Galgalatz]
 SERVICE_ID = 30
 AUDIO_PID = 2961
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Radios]
 SERVICE_ID = 36
 AUDIO_PID = 3057
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Kol Hai]
 SERVICE_ID = 40
 AUDIO_PID = 3121
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Kol Barama]
 SERVICE_ID = 41
 AUDIO_PID = 3137
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[Lev HaMdina]
 SERVICE_ID = 42
 AUDIO_PID = 3153
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVBT

[CLASSICAL bu]
 SERVICE_ID = 45
 AUDIO_PID = 3201
 FREQUENCY = 538000000
 MODULATION = QAM/16
 BANDWIDTH_HZ = 8000000
 INVERSION = AUTO
 CODE_RATE_HP = 2/3
 CODE_RATE_LP = 1/2
 GUARD_INTERVAL = 1/4
 TRANSMISSION_MODE = 8K
 HIERARCHY = NONE
 DELIVERY_SYSTEM = DVB

The updated stream list

Obtained with ffplay, as shown on this post.

Program 1
 Metadata:
 service_name    : ?Ch 11
 service_provider: ?Idan +
 Stream #0:26[0x401](heb): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
 Stream #0:6[0xa01]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg), 720x576 [SAR 12:11 DAR 15:11], 25 fps, 50 tbr, 90k tbn, 50 tbc
 Stream #0:27[0xa02]: Audio: aac_latm (HE-AACv2) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Stream #0:28[0xa03]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 2
 Metadata:
 service_name    : ?Ch 23
 service_provider: ?Idan +
 Stream #0:0[0xe01]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg), 720x576 [SAR 12:11 DAR 15:11], 25 fps, 25 tbr, 90k tbn, 50 tbc
 Stream #0:1[0xe02]: Audio: aac_latm (HE-AACv2) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 3
 Metadata:
 service_name    : ?Ch 12 Keshet
 service_provider: ?Idan +
 Stream #0:17[0xa21]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg), 720x576 [SAR 12:11 DAR 15:11], 25 fps, 50 tbr, 90k tbn, 50 tbc
 Stream #0:18[0xa22]: Audio: aac_latm (HE-AACv2) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Stream #0:19[0xa23]: Audio: aac_latm (HE-AACv2) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Stream #0:20[0xa30](heb): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
 Program 4
 Metadata:
 service_name    : ?Ch 13 Reshet
 service_provider: ?Idan +
 Stream #0:15[0x409](heb): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
 Stream #0:7[0xa61]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg), 720x576 [SAR 12:11 DAR 15:11], 25 fps, 25 tbr, 90k tbn, 50 tbc
 Stream #0:16[0xa62]: Audio: aac_latm (HE-AACv2) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 5
 Metadata:
 service_name    : ?Ch 14 10
 service_provider: ?Idan +
 Stream #0:32[0x40d](heb): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
 Stream #0:33[0x40e](rus): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
 Stream #0:34[0x40f](ara): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
 Stream #0:29[0xa41]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg), 720x576 [SAR 12:11 DAR 15:11], 25 fps, 25 tbr, 90k tbn, 50 tbc
 Stream #0:35[0xa42]: Audio: aac_latm (HE-AACv2) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Stream #0:36[0xa43]: Audio: aac_latm (HE-AACv2) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 6
 Metadata:
 service_name    : ?Ch 99
 service_provider: ?Idan +
 Stream #0:21[0xa81]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg), 720x576 [SAR 12:11 DAR 15:11], 25 fps, 50 tbr, 90k tbn, 50 tbc
 Stream #0:22[0xa82]: Audio: aac_latm (HE-AACv2) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Stream #0:23[0xa90](heb): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
 Program 21
 Metadata:
 service_name    : Tarbut
 service_provider: Idan +
 Stream #0:30[0xb01]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 22
 Metadata:
 service_name    : Bet
 service_provider: Idan +
 Stream #0:24[0xb11]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 23
 Metadata:
 service_name    : Gimmel
 service_provider: Idan +
 Stream #0:31[0xb21]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 24
 Metadata:
 service_name    : Makan
 service_provider: Idan +
 Stream #0:12[0xb31]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 25
 Metadata:
 service_name    : Moreshet
 service_provider: Idan +
 Stream #0:11[0xb41]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 26
 Metadata:
 service_name    : Kan88
 service_provider: Idan +
 Stream #0:14[0xb51]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 27
 Metadata:
 service_name    : Musica
 service_provider: Idan +
 Stream #0:3[0xb61]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 28
 Metadata:
 service_name    : Reka
 service_provider: Idan +
 Stream #0:8[0xb71]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 29
 Metadata:
 service_name    : Galatz
 service_provider: Idan +
 Stream #0:13[0xb81]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 30
 Metadata:
 service_name    : Galgalatz
 service_provider: Idan +
 Stream #0:5[0xb91]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 36
 Metadata:
 service_name    : Radios
 service_provider: Idan +
 Stream #0:2[0xbf1]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 40
 Metadata:
 service_name    : Kol Hai
 service_provider: Idan +
 Stream #0:25[0xc31]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 41
 Metadata:
 service_name    : Kol Barama
 service_provider: Idan +
 Stream #0:9[0xc41]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 42
 Metadata:
 service_name    : Lev HaMdina
 service_provider: Idan +
 Stream #0:4[0xc51]: Audio: aac_latm (HE-AACv2) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
 Program 45
 Metadata:
 service_name    : CLASSICAL bu
 service_provider: Idan +
 Stream #0:10[0xc81]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp

Let’s hope they don’t fiddle with this anymore…