06 Jan, 2014

1 commit


03 Jan, 2014

1 commit


10 Dec, 2013

1 commit


02 Dec, 2013

1 commit


26 Nov, 2013

1 commit


25 Nov, 2013

2 commits


01 Nov, 2013

1 commit


15 Oct, 2013

1 commit


24 Jul, 2013

1 commit


26 Jun, 2013

4 commits

  • This patch adds LPC support for carrying out the cros_ec protocol.

    Signed-off-by: Randall Spangler
    Signed-off-by: Simon Glass
    Signed-off-by: Hung-ying Tyan
    Acked-by: Simon Glass
    Tested-by: Simon Glass

    Hung-ying Tyan
     
  • This patch adds SPI support for carrying out the cros_ec protocol.

    Signed-off-by: Hung-ying Tyan
    Signed-off-by: Randall Spangler
    Signed-off-by: Simon Glass
    Acked-by: Simon Glass

    Hung-ying Tyan
     
  • This patch adds I2C support for carrying out the cros_ec protocol.

    Signed-off-by: Randall Spangler
    Signed-off-by: Simon Glass
    Signed-off-by: Hung-ying Tyan
    Acked-by: Simon Glass
    Tested-by: Simon Glass

    Hung-ying Tyan
     
  • This patch adds the cros_ec driver that implements the protocol for
    communicating with Google's ChromeOS embedded controller.

    Signed-off-by: Bernie Thompson
    Signed-off-by: Bill Richardson
    Signed-off-by: Che-Liang Chiou
    Signed-off-by: Doug Anderson
    Signed-off-by: Gabe Black
    Signed-off-by: Hung-ying Tyan
    Signed-off-by: Louis Yung-Chieh Lo
    Signed-off-by: Randall Spangler
    Signed-off-by: Sean Paul
    Signed-off-by: Simon Glass
    Signed-off-by: Vincent Palatin
    Acked-by: Simon Glass
    Tested-by: Simon Glass

    Hung-ying Tyan
     

12 May, 2013

1 commit


10 May, 2013

1 commit

  • u-boot standard i2c register write prototype is
    i2c_reg_write(u8 addr, u8 reg, u8 val)

    twl4030_i2c_write_u8(u8 addr, u8 val, u8 reg)
    does not provide consistency, so switch the prototype to be
    consistent with rest of u-boot i2c operations:
    twl4030_i2c_write_u8(u8 addr, u8 reg, u8 val)

    Signed-off-by: Nishanth Menon

    Nishanth Menon
     

28 Apr, 2013

2 commits


01 Dec, 2012

2 commits

  • This command is useful to allow to observe messages generated by
    coreboot and u-boot until present. In particular it is handy when
    u-boot is instrumented to fall through into console mode on startup
    errors.

    Signed-off-by: Vadim Bendebury
    Signed-off-by: Simon Glass

    Vadim Bendebury
     
  • This patch builds upon the recently introduced CBMEM console
    feature of coreboot.

    CBMEM console uses a memry area allocated by coreboot to store
    the console output. The memory area has a certain structure,
    which allows to determine where the buffer is, the buffer size
    and the location of the pointer in the buffer. This allows
    different phases of the firmware (rom based coreboot, ram based
    coreboot, u-boot after relocation with this change) to keep
    adding text to the same buffer.

    Note that this patch introduces a new console driver and adds the
    driver to the list of drivers to be used for console output, i.e.
    it engages only after u-boot relocates. Usiong CBMEM console for
    capturing the pre-relocation console output will be done under a
    separate change.

    >From Linux, run the cbmem.py utility (which is a part of the coreboot
    package) to see the output, e.g.:

    vvvvvvvvvvvvvvvvv
    SCSI: AHCI 0001.0300 32 slots 6 ports ? Gbps 0xf impl SATA mode
    flags: 64bit ilck stag led pmp pio
    ...
    Magic signature found
    Kernel command line: "cros_secure quiet loglevel=1 console=tty2...
    ^^^^^^^^^^^^^^^^^

    Note that the entire u-boot output fits into the buffer only if
    the coreboot log level is reduced from the most verbose. Ether
    the buffer size will have to be increased, or the coreboot
    verbosity permanently reduced.

    Signed-off-by: Vadim Bendebury
    Signed-off-by: Simon Glass

    Vadim Bendebury
     

27 Nov, 2012

1 commit

  • It's arch code and not a driver, so move it where it belongs. When it
    originally went into drivers/misc there was no 8xxx CPU directory.

    This will make new-SPL support a little easier since we can keep the CPU
    stuff together and not need to pull stuff in from drivers/misc.

    Signed-off-by: Scott Wood
    Cc: Andy Fleming

    Scott Wood
     

14 Nov, 2012

5 commits


23 Aug, 2012

2 commits

  • When boot from PCIE, slave's core should be in holdoff after powered on for
    some specific requirements. Master will release the slave's core at the
    right time by PCIE interface.

    Slave's ucode and ENV can be stored in master's memory space, then slave
    can fetch them through PCIE interface. For the corenet platform, ucode is
    for Fman.

    NOTE: Because the slave can not erase, write master's NOR flash by
    PCIE interface, so it can not modify the ENV parameters stored
    in master's NOR flash using "saveenv" or other commands.

    environment and requirement:

    master:
    1. NOR flash for its own u-boot image, ucode and ENV space.
    2. Slave's u-boot image is in master NOR flash.
    3. Put the slave's ucode and ENV into it's own memory space.
    4. Normally boot from local NOR flash.
    5. Configure PCIE system if needed.
    slave:
    1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV.
    2. Boot location should be set to one PCIE interface by RCW.
    3. RCW should configure the SerDes, PCIE interfaces correctly.
    4. Must set all the cores in holdoff by RCW.
    5. Must be powered on before master's boot.

    For the slave module, need to finish these processes:
    1. Set the boot location to one PCIE interface by RCW.
    2. Set a specific TLB entry for the boot process.
    3. Set a LAW entry with the TargetID of one PCIE for the boot.
    4. Set a specific TLB entry in order to fetch ucode and ENV from
    master.
    5. Set a LAW entry with the TargetID one of the PCIE ports for
    ucode and ENV.
    6. Slave's u-boot image should be generated specifically by
    make xxxx_SRIO_PCIE_BOOT_config.
    This will set SYS_TEXT_BASE=0xFFF80000 and other configurations.

    In addition, the processes are very similar between boot from SRIO and
    boot from PCIE. Some configurations like the address spaces can be set to
    the same. So the module of boot from PCIE was added based on the existing
    module of boot from SRIO, and the following changes were needed:
    1. Updated the README.srio-boot-corenet to add descriptions about
    boot from PCIE, and change the name to
    README.srio-pcie-boot-corenet.
    2. Changed the compile config "xxxx_SRIOBOOT_SLAVE" to
    "xxxx_SRIO_PCIE_BOOT", and the image builded with
    "xxxx_SRIO_PCIE_BOOT" can support both the boot from SRIO and
    from PCIE.
    3. Updated other macros and documents if needed to add information
    about boot from PCIE.

    Signed-off-by: Liu Gang
    Signed-off-by: Andy Fleming

    Liu Gang
     
  • When compile the slave image for boot from SRIO, no longer need to
    specify which SRIO port it will boot from. The code will get this
    information from RCW and then finishes corresponding configurations.

    This has the following advantages:
    1. No longer need to rebuild an image when change the SRIO port for
    boot from SRIO, just rewrite the new RCW with selected port,
    then the code will get the port information by reading new RCW.
    2. It will be easier to support other boot location options, for
    example, boot from PCIE.

    Signed-off-by: Liu Gang
    Signed-off-by: Andy Fleming

    Liu Gang
     

15 May, 2012

3 commits


27 Mar, 2012

1 commit


04 Nov, 2011

1 commit


28 Oct, 2011

6 commits


01 Oct, 2011

1 commit