| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Separate CMD_FASTBOOT from FASTBOOT and move code and configuration to
drivers/fastboot.
Switch dependencies on FASTBOOT to USB_FUNCTION_FASTBOOT as anyone who wants
FASTBOOT before this series wants USB_FUNCTION_FASTBOOT. Split
USB_FUNCTION_FASTBOOT from FASTBOOT so they retain their existing
behaviour.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At present we support multiple environment drivers but there is not way to
select between them at run time. Also settings related to the position and
size of the environment area are global (i.e. apply to all locations).
Until these limitations are removed we cannot really support more than one
environment location. Adjust the location to be a choice so that only one
can be selected. By default the environment is 'nowhere', meaning that the
environment exists only in memory and cannot be saved.
Also expand the help for the 'nowhere' option and move it to the top since
it is the default.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Move all of the imply logic to default X if Y so it works again]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
| |
|
|
|
|
|
|
| |
When we have MMC available we assume that we want to put the env as a
file on FAT.
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
| |
|
|
|
|
|
| |
Enable support for writing to FAT partitions on
TI's boards.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently these (board agnostic) commands cannot be selected using
menuconfig and friends. Fix this the obvious way. As part of this,
don't muddle the meaning of CONFIG_HASH_VERIFY to mean both 'hash -v'
and "we have a hashing command" as this makes the Kconfig logic odd.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
[trini: Re-apply, add imply for a few cases, run moveconfig.py, also
migrate CRC32_VERIFY]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This converts the following to Kconfig:
CONFIG_CMD_EEPROM
CONFIG_CMD_EEPROM_LAYOUT
CONFIG_EEPROM_LAYOUT_HELP_STRING
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Rework Kconfig logic slightly, define EEPROM location on TI eval
platforms]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of defining command options in every defconfig,
define a common Kconfig symbol that consolidates all command
options that are supported by any TI platform. Also use imply
keyword so that that specific option can be disabled if
not required.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
|
|
|
|
|
|
|
| |
In stead of defining the board EEPROM address in the board headers
let's define them in the board config files and make them
configurable by Kconfig.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
|
|
|
|
|
| |
The option that we had set in board/ti/common/Kconfig as default y are
best done with imply under the appropriate main Kconfig option instead.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
| |
|
|
|
|
| |
Move this option to Kconfig and tidy up existing uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| |
|
|
|
|
| |
Move this option to Kconfig and tidy up existing uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| |
|
|
|
|
| |
Move this option to Kconfig and tidy up existing uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| |
|
|
|
|
| |
Move this option to Kconfig and tidy up existing uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| |
|
|
|
|
| |
Move this option to Kconfig and tidy up existing uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| |
|
|
|
|
| |
Move this option to Kconfig and tidy up existing uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| |
|
|
|
|
| |
Move this option to Kconfig and tidy up existing uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| |
|
|
|
|
| |
Move this option to Kconfig and tidy up existing uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| |
|
|
|
|
| |
Move this option to Kconfig and tidy up existing uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| |
|
|
|
|
| |
Move this option to Kconfig and tidy up existing uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| |
|
|
|
|
| |
Move this option to Kconfig and tidy up existing uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| |
|
|
|
|
| |
Move this option to Kconfig and tidy up existing uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
Several TI EVMs have EEPROM that can contain board description information
such as revision, DDR definition, serial number, etc. In just about all
cases, these EEPROM are on the I2C bus and provides us the opportunity
to centralize the generic operations involved.
The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM,
AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format.
However, DRA-7* EVMs, OMAP4SDP use a modified format.
We hence introduce logic which is generic between these platforms
without enforcing any specific format. This allows the boards to use the
relevant format for operations that they might choose.
This module will compile for all TI SoC based boards when
CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for
platforms that require this support.
It is important to note that this logic is fundamental to the board
configuration process such as DDR configuration which is needed in
SPL, hence cannot be part of the standard u-boot driver model (which
is available later in the process). Hence, to aid efficiency, the
eeprom contents are copied over to SRAM scratchpad memory area at the
first invocation to retrieve data.
To prevent churn with cases such as DRA7, where eeprom format maybe
incompatible, we introduce a generic common format in eeprom which
is made available over accessor functions for usage.
Special handling for BBG1 EEPROM had to be introduced thanks to the
weird eeprom rev contents used.
The follow on patches introduce the use of this library for AM335x,
AM437x, and AM57xx.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
