15 Nov, 2018

40 commits

  • When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
    bound before relocation. However due to a bug in the DM core,
    the flag only takes effect when devices are statically declared
    via U_BOOT_DEVICE(). This bug has been fixed recently by commit
    "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
    lists_bind_fdt()", but with the fix, it has a side effect that
    all existing drivers that declared DM_FLAG_PRE_RELOC flag will
    be bound before relocation now. This may expose potential boot
    failure on some boards due to insufficient memory during the
    pre-relocation stage.

    To mitigate this potential impact, the following changes are
    implemented:

    - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
    only supports configuration from device tree (OF_CONTROL)
    - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
    is statically declared via U_BOOT_DEVICE()
    - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
    drivers that support both statically declared devices and
    configuration from device tree

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass
    Reviewed-by: Patrick Delaunay

    Bin Meng
     
  • When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
    bound before relocation. However due to a bug in the DM core,
    the flag only takes effect when devices are statically declared
    via U_BOOT_DEVICE(). This bug has been fixed recently by commit
    "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
    lists_bind_fdt()", but with the fix, it has a side effect that
    all existing drivers that declared DM_FLAG_PRE_RELOC flag will
    be bound before relocation now. This may expose potential boot
    failure on some boards due to insufficient memory during the
    pre-relocation stage.

    To mitigate this potential impact, the following changes are
    implemented:

    - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
    only supports configuration from device tree (OF_CONTROL)
    - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
    is statically declared via U_BOOT_DEVICE()
    - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
    drivers that support both statically declared devices and
    configuration from device tree

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
    bound before relocation. However due to a bug in the DM core,
    the flag only takes effect when devices are statically declared
    via U_BOOT_DEVICE(). This bug has been fixed recently by commit
    "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
    lists_bind_fdt()", but with the fix, it has a side effect that
    all existing drivers that declared DM_FLAG_PRE_RELOC flag will
    be bound before relocation now. This may expose potential boot
    failure on some boards due to insufficient memory during the
    pre-relocation stage.

    To mitigate this potential impact, the following changes are
    implemented:

    - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
    only supports configuration from device tree (OF_CONTROL)
    - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
    is statically declared via U_BOOT_DEVICE()
    - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
    drivers that support both statically declared devices and
    configuration from device tree

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass
    Reviewed-by: Patrick Delaunay

    Bin Meng
     
  • If _debug_uart_putc() is called before _debug_uart_init(), the
    ns16550 debug uart driver hangs in a tight loop waiting for the
    tx FIFO to get empty.

    As this can happen via a printf sneaking in before the port calls
    debug_uart_init(), let's rather ignore characters before the debug
    uart is initialized.

    This is done by reading the baudrate divisor and aborting if is zero.

    Tested on socfpga_cyclone5_socrates.

    Signed-off-by: Simon Goldschmidt
    Acked-by: Simon Glass

    Simon Goldschmidt
     
  • Use the uclass_foreach_dev() macro instead of the open coded version.

    Signed-off-by: Liviu Dudau
    Reviewed-by: Simon Glass

    Liviu Dudau
     
  • Add REAME.virtio to describe the information about U-Boot support for
    VirtIO devices, including supported boards, build instructions, driver
    details etc.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • Now that we have a sandbox virtio transport driver, add some test
    cases to test virtio uclass driver.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • This driver provides support for Sandbox implementation of virtio
    transport driver which is used for testing purpose only.

    Two drivers are provided. The 2nd one is a driver that lacks the
    'notify' op.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • For v1.0 compliant device, it always assumes the member 'num_buffers'
    exists in the struct virtio_net_hdr while the legacy driver only
    presented 'num_buffers' when VIRTIO_NET_F_MRG_RXBUF was negotiated.
    Without that feature the structure was 2 bytes shorter.

    Update the driver to support the non-legacy device.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • By default QEMU creates legacy PCI transport devices, but we can
    ask QEMU to create non-legacy one if we pass additional device
    property/value pairs in the command line:

    -device virtio-blk-pci,disable-legacy=true,disable-modern=false

    This adds a new driver driver to support non-legacy (modern) device
    mode. Previous driver/file name is changed accordingly.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • Add test cases to cover the two newly added PCI APIs:
    dm_pci_find_next_capability() & dm_pci_find_next_ext_capability().

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • This introduces two new APIs dm_pci_find_next_capability() and
    dm_pci_find_next_ext_capability() to get PCI capability address
    and PCI express extended capability address for a given PCI device
    starting from a given offset.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • Add virtio drivers for QEMU x86 targets.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • Currently devices on the virtio bus is not automatically enumerated,
    which means peripherals on the virtio bus are not discovered by their
    drivers. This uses board_init() to do the virtio enumeration.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • This adds a Kconfig file in the board directory, so that some
    board-specific options can be specified there.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • This adds a transport driver that implements UCLASS_VIRTIO for
    virtio over pci, which is commonly used on x86.

    It only supports the legacy interface of the pci transport, which
    is the default device that QEMU emulates.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • At present the generic io{read,write}{8,16,32} routines only support
    MMIO access. With architecture like x86 that has a separate IO space,
    these routines cannot be used to access I/O ports.

    Implement x86-specific version to support both PIO and MMIO access,
    so that drivers for multiple architectures can use these accessors
    without the need to know whether it's MMIO or PIO.

    These are ported from Linux kernel lib/iomap.c, with slight changes.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • Introduce a new Kconfig option for architecture codes to control
    whether it provides io{read,write}{8,16,32} I/O accessor functions.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • With the virtio net and blk drivers, we can do more stuff with some
    useful commands. Imply those in the board Kconfig.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • Currently devices on the virtio bus is not automatically enumerated,
    which means peripherals on the virtio bus are not discovered by their
    drivers. This uses board_init() to do the virtio enumeration.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • Add 'virtio' command in U-Boot command line.

    Signed-off-by: Tuomas Tynkkynen
    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Tuomas Tynkkynen
     
  • This adds virtio block device driver support.

    Signed-off-by: Tuomas Tynkkynen
    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Tuomas Tynkkynen
     
  • This adds a new block interface type for VirtIO block devices.

    Signed-off-by: Tuomas Tynkkynen
    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Tuomas Tynkkynen
     
  • blk_next_free_devnum() can be helpful in some cases. Make it
    a public API.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • With the post_probe() changes, this API is no longer needed.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • part_init() is currently called in every DM BLK driver, either
    in its bind() or probe() method. However we can use the BLK
    uclass driver's post_probe() method to do it automatically.

    Update all DM BLK drivers to adopt this change.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • Currently the efi block driver uses priv_auto_alloc_size for the
    driver data, however that's only available after the device probe
    phase. In order to make it accessible in an earlier phase, switch
    to use platdata_auto_alloc_size instead.

    This patch is the prerequisite for the follow up patch of DM BLK
    driver changes to work with EFI loader.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • Currently the sandbox block driver uses priv_auto_alloc_size for
    the driver data, however that's only available after the device
    probe phase. In order to make it accessible in an earlier phase,
    switch to use platdata_auto_alloc_size instead.

    This patch is the prerequisite for the follow up patch of DM BLK
    driver changes to work with Sandbox.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • The blk_base test case creates a USB mass storage block device with
    the Sandbox host block device as its parent. This does not make any
    sense and causes potential issue, for example if the test case tries
    to read/write anything on the USB mass storage block device it will
    definitely fail as its parent is not on USB bus at all.

    Correct the test case by creating another Sandbox host block device
    instead of the USB mass storage one and adjust the case accordingly.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • This adds virtio net device driver support.

    Signed-off-by: Tuomas Tynkkynen
    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Tuomas Tynkkynen
     
  • VirtIO can use various different buses and virtio devices are
    commonly implemented as PCI devices. But virtual environments
    without PCI support (a common situation in embedded devices
    models) might use simple memory mapped device (“virtio-mmio”)
    instead of the PCI device.

    This adds a transport driver that implements UCLASS_VIRTIO for
    virtio over mmio.

    Signed-off-by: Tuomas Tynkkynen
    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • This adds support for managing virtual queue/ring, the channel
    for high performance I/O between host and guest.

    Signed-off-by: Tuomas Tynkkynen
    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Tuomas Tynkkynen
     
  • This adds a new virtio uclass driver for “virtio” [1] family of
    devices that are are found in virtual environments like QEMU,
    yet by design they look like physical devices to the guest.

    The uclass driver provides child_pre_probe() and child_post_probe()
    methods to do some common operations for virtio device drivers like
    device and driver supported feature negotiation, etc.

    [1] http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf

    Signed-off-by: Tuomas Tynkkynen
    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • This adds a call to dm_remove_devices_flags() to do_bootm_linux()
    so that drivers that have one of the removal flags set (e.g.
    DM_FLAG_ACTIVE_DMA_REMOVE) in their driver struct, may do some
    last-stage cleanup before the OS is started.

    arm and x86 already did such, and we should do the same for riscv.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • Add test case to cover uclass driver's child_post_probe() method.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • Some buses need to set up their child devices after they are probed.
    Support a common child_post_probe() method for the uclass.

    With this change, the two APIs uclass_pre_probe_device() and
    uclass_post_probe_device() become symmetric.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • Add some overview documentation that explains the purpose and some of
    the features and limitations of the regmap interface.

    Reviewed-by: Bin Meng
    Signed-off-by: Mario Six

    Mario Six
     
  • Add support for switching the endianness of regmap accesses via the
    "little-endian", "big-endian", and "native-endian" boolean properties in
    the device tree.

    The default endianness is native endianness.

    Signed-off-by: Mario Six
    Reviewed-by: Simon Glass
    Reviewed-by: Daniel Schwierzeck

    Mario Six
     
  • Add test for regmap_{set,get} functions.

    Reviewed-by: Anatolij Gustschin
    Reviewed-by: Simon Glass
    Signed-off-by: Mario Six

    Mario Six
     
  • It would be convenient if one could use the regmap API in conjunction
    with register maps defined as structs (i.e. structs that directly mirror
    the memory layout of the registers in question). A similar approach was
    planned with the regmap_write32/regmap_read32 macros, but was never
    used.

    Hence, implement regmap_set/regmap_range_set and
    regmap_get/regmap_range_get macros, which, given a register map, a
    struct describing the layout of the register map, and a member name
    automatically produce regmap_read/regmap_write calls that access the
    specified member in the register map.

    Reviewed-by: Anatolij Gustschin
    Reviewed-by: Simon Glass
    Signed-off-by: Mario Six

    Mario Six