19 Apr, 2015

2 commits

  • The PCH (Platform Controller Hub) is on the PCI bus, so show it as such.
    The LPC (Low Pin Count) and SPI bus are inside the PCH, so put these in the
    right place also.

    Rename the compatible strings to be more descriptive since this board is the
    only user. Once we are using driver model fully on x86, these will be
    dropped.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • Move chromebook_link over to driver model for PCI.

    This involves:
    - adding a uclass for platform controller hub
    - removing most of the existing PCI driver
    - adjusting how CPU init works to use driver model instead
    - rename the lpc compatible string (it will be removed later)

    This does not really take advantage of driver model fully, but it does work.
    Furture work will improve the code structure to remove many of the explicit
    calls to init the board.

    Signed-off-by: Simon Glass

    Simon Glass
     

17 Apr, 2015

2 commits


15 Mar, 2015

1 commit


28 Feb, 2015

1 commit


07 Feb, 2015

1 commit


30 Jan, 2015

5 commits


24 Jan, 2015

1 commit


13 Jan, 2015

1 commit

  • This commit adds several APIs to decode PCI device node according to
    the Open Firmware PCI bus bindings, including:
    - fdtdec_get_pci_addr() for encoded pci address
    - fdtdec_get_pci_vendev() for vendor id and device id
    - fdtdec_get_pci_bdf() for pci device bdf triplet
    - fdtdec_get_pci_bar32() for pci device register bar

    Signed-off-by: Bin Meng
    Acked-by: Simon Glass
    Signed-off-by: Simon Glass
    (Include in fdtdec.h and adjust tegra to fix build error)

    Bin Meng
     

19 Dec, 2014

3 commits

  • Add support for the PCIe controller found on some generations of Tegra.
    Tegra20 has 2 root ports with a total of 4 lanes, Tegra30 has 3 root
    ports with a total of 6 lanes and Tegra124 has 2 root ports with a total
    of 5 lanes.

    This is based on the Linux kernel driver, originally submitted upstream
    by Mike Rapoport.

    Signed-off-by: Mike Rapoport
    Signed-off-by: Thierry Reding
    Signed-off-by: Simon Glass
    Signed-off-by: Tom Warren

    Thierry Reding
     
  • This controller was introduced on Tegra114 to handle XUSB pads. On
    Tegra124 it is also used for PCIe and SATA pin muxing and PHY control.
    Only the Tegra124 PCIe and SATA functionality is currently implemented,
    with weak symbols on Tegra114.

    Tegra20 and Tegra30 also provide weak symbols for these functions so
    that drivers can use the same API irrespective of which SoC they're
    being built for.

    Signed-off-by: Thierry Reding
    Signed-off-by: Simon Glass
    Signed-off-by: Tom Warren

    Thierry Reding
     
  • The AS3722 provides a number of DC/DC converters and LDOs as well as 8
    GPIOs.

    Signed-off-by: Thierry Reding
    Signed-off-by: Simon Glass
    Signed-off-by: Tom Warren

    Thierry Reding
     

02 Dec, 2014

2 commits


28 Nov, 2014

1 commit


27 Nov, 2014

1 commit


25 Nov, 2014

4 commits


22 Nov, 2014

1 commit


21 Nov, 2014

6 commits

  • Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in
    the board directory and the SDRAM SPD information in the device tree. This
    also needs the Intel Management Engine (me.bin) to work. Binary blobs
    everywhere: so far we have MRC, ME and microcode.

    SDRAM init works by setting up various parameters and calling the MRC. This
    in turn does some sort of magic to work out how much memory there is and
    the timing parameters to use. It also sets up the DRAM controllers. When
    the MRC returns, we use the information it provides to map out the
    available memory in U-Boot.

    U-Boot normally moves itself to the top of RAM. On x86 the RAM is not
    generally contiguous, and anyway some RAM may be above 4GB which doesn't
    work in 32-bit mode. So we relocate to the top of the largest block of
    RAM we can find below 4GB. Memory above 4GB is accessible with special
    functions (see physmem).

    It would be possible to build U-Boot in 64-bit mode but this wouldn't
    necessarily provide any more memory, since the largest block is often below
    4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large
    ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit
    kernels directly so this does not pose a limitation in that area. Also there
    are probably parts of U-Boot that will not work correctly in 64-bit mode.
    The MRC is one.

    There is some work remaining in this area. Since memory init is very slow
    (over 500ms) it is possible to save the parameters in SPI flash to speed it
    up next time. Suspend/resume support is not fully implemented, or at least
    it is not efficient.

    With this patch, link boots to a prompt.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • Microcode updates are stored in the device tree. Work through these and
    apply any that are needed.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • Sometimes an array can be of variable size up to a maximum. Add a helper
    function to decode this.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • Permit decoding of a named memory region from the device tree. This allows
    easy run-time configuration of the address of on-chip SRAM, SDRAM, etc.

    Signed-off-by: Simon Glass
    Reviewed-by: Tom Rini

    Simon Glass
     
  • Flash regions can optionally be compressed or hashed. Add the ability to
    read this information from the flashmap.

    Signed-off-by: Simon Glass
    Acked-by: Anatolij Gustschin
    Reviewed-by: Tom Rini

    Simon Glass
     
  • Use the correct FDT data types for this function. Also add more debugging.

    Acked-by: Anatolij Gustschin
    Signed-off-by: Simon Glass
    Reviewed-by: Tom Rini

    Simon Glass
     

23 Oct, 2014

4 commits


14 Sep, 2014

1 commit


11 Sep, 2014

1 commit


05 Sep, 2014

2 commits