Regression: vga term no longer active on Cavium ThunderX

[dann frazier]

Cavium ThunderX-based systems, such as the Cavium CRBs and Gigabyte implementations, have an ASPEED VGA controller that can be viewed remotely using a JAVA application exposed by the BMC. The kernel will use serial as the default console on this platform but, with the xenial GA (4.4) kernel, boot messages and a login prompt would also appear on the VGA display once the DRM stack was initialized during boot. You could also override the console default w/ console=tty0 if, for example, you wanted to do a d-i install over VGA instead of serial.

This is no longer the case with later kernels. The significant difference is that CONFIG_FB_EFI is now enabled, starting with this commit:

commit 44b343e7dd648d738a6b752a81c1ad60c8e0c9b0
Author: Seth Forshee <email address hidden>
Date: Tue Nov 15 13:45:04 2016 -0600

    UBUNTU: [Config] Enable various drivers for ARM platforms

This driver detects an EFI framebuffer device, and uses that as the default VGA device instead of the ASPEED:

[ 6.426569] efifb: probing for efifb
[ 6.430174] efifb: framebuffer at 0x10000000, using 1200k, total 1200k
[ 6.436703] efifb: mode is 640x480x32, linelength=2560, pages=1
[ 6.442623] efifb: scrolling: redraw
[ 6.446199] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 6.454324] Console: switching to colour frame buffer device 80x30
[ 6.462878] fb0: EFI VGA frame buffer device
...
[ 9.320983] ast 0004:21:00.0: enabling device (0002 -> 0003)
[ 9.321192] [drm] Using P2A bridge for configuration
[ 9.321195] [drm] AST 2400 detected
[ 9.321202] [drm] Analog VGA only
[ 9.321213] [drm] dram MCLK=408 Mhz type=6 bus_width=16 size=01000000
[ 9.321351] [TTM] Zone kernel: Available graphics memory: 65994474 kiB
[ 9.321353] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[ 9.321354] [TTM] Initializing pool allocator
[ 9.321386] [TTM] Initializing DMA pool allocator
...
[ 9.696100] ast 0004:21:00.0: fb1: astdrmfb frame buffer device

A workaround for this is to disable the efifb device using "video=efifb:off". With that in place, I again see output on the ASPEED device:

[ 8.799297] ast 0004:21:00.0: enabling device (0002 -> 0003)
[ 8.799449] [drm] Using P2A bridge for configuration
[ 8.799452] [drm] AST 2400 detected
[ 8.799459] [drm] Analog VGA only
[ 8.799470] [drm] dram MCLK=408 Mhz type=6 bus_width=16 size=01000000
[ 8.799602] [TTM] Zone kernel: Available graphics memory: 65994474 kiB
[ 8.799604] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[ 8.799605] [TTM] Initializing pool allocator
[ 8.799614] [TTM] Initializing DMA pool allocator
[ 8.954255] Console: switching to colour frame buffer device 128x48

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1755304

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[dann frazier (dannf)]

What should be happening here is that:

  1) The efifb driver initializes, detects a device.
  2) The console driver makes the efifb an active console, and output appears
  3) Later, the astdrmfb initializes, detects a device
  4) The kernel checks for an overlap in the framebuffers used by efifb & astdrmfb,
     to see if they're actually the same physical device.
  5) Overlap is found (they are the same device on ThunderX), so the console driver
     actives the preferred astdrmfb driver instead
  6) Console settings are adjusted, output continues

Indeed, this works just like this on a Gigabyte R120 system (same SoC) - but not on the Cavium CRB. The problem appears to be that UEFI on the CRB claims the efi framebuffer start address is at 0x10000000 - when it is really at 0x881010000000 (that's what the Gigabyte system shows). The kernel assumes this is valid and the efifb driver starts using that memory and the console driver activates this device... but this isn't the real location, so nothing appears on VGA. When the astdrm driver loads, the kernel finds no overlap with the astdrm driver (which is using the correct window), therefore the console does not attempt to switch to it, and we continue to not have output.

If I hack the driver to add the 0x8810 prefix, I do begin to see output at step #2 on the CRB, and the remaining steps work as they should. So, my assumption is that the framebuffer base is just truncated in firmware.

[dann frazier (dannf)]

Closing as Invalid, as I believe the problem is in firmware. Will reopen if that proves false.