Bug 194952

Summary: uart(4) needs BayTrail support for Minnowboard Max
Product: Base System Reporter: Ed Maste <emaste>
Component: kernAssignee: Marcel Moolenaar <marcel>
Status: Closed FIXED    
Severity: Affects Some People CC: k, marcel, marcnarc
Priority: ---    
Version: CURRENT   
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192324
Attachments:
Description Flags
Proposed fix for BayTril as low-level console none

Description Ed Maste freebsd_committer freebsd_triage 2014-11-11 22:10:03 UTC
See PR 192324

Intel's BayTrail SoC has 16550-like UARTs with some extra functionality. They appear to require some special configuration as well; presumably the firmware performs this configuration and enables a compatibility mode for CSM booting. Just adding the PCI device IDs is not sufficient.

none7@pci0:0:30:3:      class=0x078000 card=0x72708086 chip=0x0f0a8086 rev=0x0c hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'ValleyView LPIO1 HSUART Controller'
    class      = simple comms
    cap 01[80] = powerspec 3  supports D0 D3  current D0
none8@pci0:0:30:4:      class=0x078000 card=0x72708086 chip=0x0f0c8086 rev=0x0c hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'ValleyView LPIO1 HSUART Controller'
    class      = simple comms
    cap 01[80] = powerspec 3  supports D0 D3  current D0

Related Linux commits are b15e5691 and 29897087
Comment 1 Marcel Moolenaar freebsd_committer freebsd_triage 2015-08-10 22:06:53 UTC
Created attachment 159741 [details]
Proposed fix for BayTril as low-level console

FreeBSD-current (at time of this writing) already supports the H/W, but not yet when used as low-level console. This patch fixes that.
Comment 2 commit-hook freebsd_committer freebsd_triage 2015-08-12 15:26:54 UTC
A commit references this bug:

Author: marcel
Date: Wed Aug 12 15:26:35 UTC 2015
New revision: 286667
URL: https://svnweb.freebsd.org/changeset/base/286667

Log:
  Better support memory mapped console devices, such as VGA and EFI
  frame buffers and memory mapped UARTs.

  1.  Delay calling cninit() until after pmap_bootstrap(). This makes
      sure we have PMAP initialized enough to add translations. Keep
      kdb_init() after cninit() so that we have console when we need
      to break into the debugger on boot.
  2.  Unfortunately, the ATPIC code had be moved as well so as to
      avoid a spurious trap #30. The reason for which is not known
      at this time.
  3.  In pmap_mapdev_attr(), when we need to map a device prior to the
      VM system being initialized, use virtual_avail as the KVA to map
      the device at. In particular, avoid using the direct map on amd64
      because we can't demote by virtue of not being able to allocate
      yet. Keep track of the translation.
      Re-use the translation after the VM has been initialized to not
      waste KVA and to satisfy the assumption in uart(4) that the handle
      returned for the low-level console is the same as later returned
      when the device is probed and attached.
  4.  In pmap_unmapdev() remove the mapping from the table when called
      pre-init. Otherwise keep the mapping. During bus probe and attach
      device resources are mapped and unmapped multiple times, which
      would have us destroy the mapping used by the low-level console.
  5.  In pmap_init(), set pmap_initialized to signal that we're not
      pre-init anymore. On amd64, bring the direct map in sync with the
      translations created at that time.
  6.  Implement bus_space_map() and bus_space_unmap() for real: when
      the tag corresponds to memory space, call the corresponding
      pmap_mapdev() and pmap_unmapdev() functions to construct and
      actual handle.
  7.  In efifb.c and vt_vga.c, remove the crutches and hacks and simply
      call pmap_mapdev_attr() or bus_space_map() as desired.

  Notes:
  1.  uart(4) already used bus_space_map() during low-level console
      setup but since serial ports have traditionally been I/O port
      based, the lack of a proper implementation for said function
      was not a problem. It has always supported memory mapped UARTs
      for low-level consoles by setting hw.uart.console accordingly.
  2.  The use of the direct map on amd64 without setting caching
      attributes has been a bigger problem than previously thought.
      This change has the fortunate (and unexpected) side-effect of
      fixing various EFI frame buffer problems (though not all).

  PR: 191564, 194952

  Special thanks to:
  1.  XipLink, Inc -- generously donated an Intel Bay Trail E3800
      based eval board (ADLE3800PC).
  2.  The FreeBSD Foundation, in particular emaste@ -- for UEFI
      support in general and testing.
  3.  Everyone who tested the proposed for PR 191564.
  4.  jhb@ and kib@ for being a soundboard and applying a clue bat
      if so needed.

Changes:
  head/sys/amd64/amd64/machdep.c
  head/sys/amd64/amd64/pmap.c
  head/sys/conf/files.amd64
  head/sys/conf/files.i386
  head/sys/dev/vt/hw/efifb/efifb.c
  head/sys/dev/vt/hw/vga/vt_vga.c
  head/sys/i386/i386/machdep.c
  head/sys/i386/i386/pmap.c
  head/sys/x86/include/bus.h
  head/sys/x86/x86/bus_machdep.c
Comment 3 commit-hook freebsd_committer freebsd_triage 2015-08-25 14:40:16 UTC
A commit references this bug:

Author: marcel
Date: Tue Aug 25 14:39:44 UTC 2015
New revision: 287126
URL: https://svnweb.freebsd.org/changeset/base/287126

Log:
  MFC r286667 & r286723

  Better support memory mapped console devices, such as VGA and EFI
  frame buffers and memory mapped UARTs.

  PR:		191564, 194952, 202276

Changes:
_U  stable/10/
  stable/10/sys/amd64/amd64/machdep.c
  stable/10/sys/amd64/amd64/pmap.c
  stable/10/sys/conf/files.amd64
  stable/10/sys/conf/files.i386
  stable/10/sys/dev/vt/hw/efifb/efifb.c
  stable/10/sys/dev/vt/hw/vga/vt_vga.c
  stable/10/sys/dev/vt/hw/vga/vt_vga_reg.h
  stable/10/sys/i386/i386/machdep.c
  stable/10/sys/i386/i386/pmap.c
  stable/10/sys/x86/include/bus.h
  stable/10/sys/x86/x86/bus_machdep.c