u-boot.git/README, branch v2011.12

README: add documentation for CONFIG_USB_ULPI*

2011-12-16T20:37:16+00:00

Add documentation for CONFIG_USB_ULPI and CONFIG_USB_ULPI_VIEWPORT
configuration options.

Signed-off-by: Igor Grinberg

Add board_pre_console_putc to deal with early console output

2011-12-09T13:44:22+00:00

This patch adds support for console output before the console is inited.
The main purpose of this is to deal with a very early panic() which would
otherwise cause a silent hang.

A new board_pre_console_putc() function is added to the board API. If
provided by the board it will be called in the event of console output
before the console is ready. This function should turn on all UARTs and
spray the character out if it possibly can.

The feature is controlled by a new CONFIG_PRE_CONSOLE_PUTC option.

Signed-off-by: Simon Glass 
Acked-by: Graeme Russ

MPC7xx: remove obsolete "BAB7xx" board

2011-12-08T19:51:28+00:00

The BAB7xx boards are almost deceased.  They cause build warnings, an
it's not worth the effort to fix these.  Remove the dead body.

Signed-off-by: Wolfgang Denk 
Cc: Frank Gottschling

Introduce generic TPM support in u-boot

2011-12-07T07:45:51+00:00

TPM (Trusted Platform Module) is an integrated circuit and
software platform that provides computer manufacturers with the
core components of a subsystem used to assure authenticity,
integrity and confidentiality.

This driver supports version 1.2 of the TCG (Trusted Computing
Group) specifications.

The TCG specification defines several so called localities in a
TPM chip, to be controlled by different software layers. When
used on a typical x86 platform during the firmware phase, only
locality 0 can be accessed by the CPU, so this driver even while
supporting the locality concept presumes that only locality zero
is used.

This implementation is loosely based on the article "Writing a
TPM Device Driver" published on http://ptgmedia.pearsoncmg.com

Compiling this driver with DEBUG defined will generate trace of
all accesses to TMP registers.

This driver has been tested and is being used in three different
functional ChromeOS machines (Pinetrail and Sandy Bridge Intel
chipsets) all using the same Infineon SLB 9635 TT 1.2 device.

A u-boot cli command allowing access to the TPM was also
implemented and is being submitted as a second patch.

Change-Id: I22a33c3e5b2e20eec9557a7621bd463b30389d73
Signed-off-by: Vadim Bendebury 
CC: Wolfgang Denk

powerpc/85xx: clean up and document the QE/FMAN microcode macros

2011-11-29T14:48:06+00:00

Several macros are used to identify and locate the microcode binary image
that U-boot needs to upload to the QE or Fman.  Both the QE and the Fman
use the QE Firmware binary format to package their respective microcode data,
which is why the same macros are used for both.  A given SOC will only have
a QE or an Fman, so this is safe.

Unfortunately, the current macro definition and usage has inconsistencies.
For example, CONFIG_SYS_FMAN_FW_ADDR was used to define the address of Fman
firmware in NOR flash, but CONFIG_SYS_QE_FW_IN_NAND contains the address
of NAND.  There's no way to know by looking at a variable how it's supposed
to be used.

In the future, the code which uploads QE firmware and Fman firmware will
be merged.

Signed-off-by: Timur Tabi 
Signed-off-by: Kumar Gala

arm, davinci_emac: fix driver bug if more then 3 PHYs are detected

2011-11-15T21:25:51+00:00

since commits:
davinci: emac: add support for more than 1 PHYs
062fe7d332c28ede25626f448681e43d76bb312e

davinci: remove obsolete macro CONFIG_EMAC_MDIO_PHY_NUM
fb1d6332b5430b90a8fa8ebab709f33a60e9f816

I get following warning on the enbw_cmc board:

Err:   serial
Net:    5 ETH PHY detected
miiphy_register: non unique device name 'KSZ8873 @ 0x01'
DaVinci-EMAC
Hit any key to stop autoboot:  0

Also I see some debug printfs:

=> run load
+ emac_close
+ emac_ch_teardown
- emac_ch_teardown
+ emac_ch_teardown
- emac_ch_teardown
- emac_close
+ emac_open
- emac_open
Using DaVinci-EMAC device

reason is 062fe7d332c28ede25626f448681e43d76bb312e new define MAX_PHY.
This is set to 3! I get on this board 5 active phys, so
this leads in wrong memory writes ...

so I changed:

- define CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT to set
  the MAX_PHY value, add a description in README
  for the new CONFIG_SYS option.
- print an error message if more then MAX_PHYs are
  detected.
- fill the active_phy_addr array in a for loop with
  0xff
- changed printf() in debug_emac()

Signed-off-by: Heiko Schocher 
Cc: Sandeep Paulraj 
Cc: Albert ARIBAUD 
Cc: Wolfgang Denk 
Cc: Manjunath Hadli 
Cc: Prabhakar Lad 
Cc: Mike Frysinger 
Cc: Tom Rini 
Signed-off-by: Sandeep Paulraj

README: Fix supported i.MX SoC list for CONFIG_MXC_SPI

2011-11-04T21:06:37+00:00

CONFIG_MXC_SPI currently works on MX31/35/51 boards, so update the README file.

Signed-off-by: Fabio Estevam

spl, nand: add 4bit HW ecc oob first nand_read_page function

2011-11-03T21:56:25+00:00

similiar to commit dc7cd8e59ba077f3b4c1a4557c9cd86a31b9ab1f, only
adapted for the new spl framework.

Signed-off-by: Heiko Schocher 
Acked-by: Tom Rini 
Acked-by: Scott Wood 
Cc: Albert ARIBAUD 
Cc: Sandeep Paulraj 
Signed-off-by: Sandeep Paulraj

rtc: Make mc13783-rtc driver generic

2011-11-03T21:56:19+00:00

Rename mc13783-rtc so that it can be used for both MC13783 and MC13892 PMICs.

efikamx board, for example, does use a MC13892 PMIC, but the RTC selection is currently made as:

#define CONFIG_RTC_MC13783

,which is not very obvious.

Let the MC13783 and MC13892 RTC be selected by:

#define CONFIG_RTC_MC13XXX

Signed-off-by: Fabio Estevam 
Acked-by: Stefano Babic

e1000: Allow direct access to the E1000 SPI EEPROM device

2011-10-27T22:37:01+00:00

As a part of the manufacturing process for some of our custom hardware,
we are programming the EEPROMs attached to our Intel 82571EB controllers
from software using U-Boot and Linux.

This code provides several conditionally-compiled features to assist in
our manufacturing process:

  CONFIG_CMD_E1000:
    This is a basic "e1000" command which allows querying the controller
    and (if other config options are set) performing EEPROM programming.
    In particular, with CONFIG_E1000_SPI this allows you to display a
    hex-dump of the EEPROM, copy to/from main memory, and verify/update
    the software checksum.

  CONFIG_E1000_SPI_GENERIC:
    Build a generic SPI driver providing the standard U-Boot SPI driver
    interface.  This allows commands such as "sspi" to access the bus
    attached to the E1000 controller.  Additionally, some E1000 chipsets
    can support user data in a reserved space in the E1000 EEPROM which
    could be used for U-Boot environment storage.

  CONFIG_E1000_SPI:
    The core SPI access code used by the above interfaces.

For example, the following commands allow you to program the EEPROM from
a USB device (assumes CONFIG_E1000_SPI and CONFIG_CMD_E1000 are enabled):
  usb start
  fatload usb 0 $loadaddr 82571EB_No_Mgmt_Discrete-LOM.bin
  e1000 0 spi program $loadaddr 0 1024
  e1000 0 spi checksum update

Please keep in mind that the Intel-provided .eep files are organized as
16-bit words.  When converting them to binary form for programming you
must byteswap each 16-bit word so that it is in little-endian form.

This means that when reading and writing words to the SPI EEPROM, the
bit ordering for each word looks like this on the wire:

  Time >>>
------------------------------------------------------------------
  ... [7, 6, 5, 4, 3, 2, 1, 0, 15, 14, 13, 12, 11, 10, 9, 8], ...
------------------------------------------------------------------
  (MSB is 15, LSB is 0).

Signed-off-by: Kyle Moffett 
Cc: Ben Warren