We are now using an env_ prefix for environment functions. Rename these
for consistency. Also add function comments in common.h.
Suggested-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
We are now using an env_ prefix for environment functions. Rename these
two functions for consistency. Also add function comments in common.h.
Quite a few places use getenv() in a condition context, provoking a
warning from checkpatch. These are fixed up in this patch also.
Suggested-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
We are now using an env_ prefix for environment functions. Rename setenv()
for consistency. Also add function comments in common.h.
Suggested-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.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>
This patch brings the OMAP3 EVM to a bootable state, on master, as of
v2017.09-rc1.
Signed-off-by: Derald D. Woods <woods.technical@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Traditional KS2 devices supported NAND via the AEMIF peripheral. However,
66AK2G doesn't use the AEMIF but rather the GPMC for NAND. Therefore,
clarify some statements to indicate only certain devices have AEMIF and
in other places just say NAND instead of AEMIF NAND
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Acked-by: Roger Quadros <rogerq@ti.com>
The driver is for all boards 24XX and up, so let's eliminate the
extra option called CONFIG_SYS_I2C_OMAP34XX since the driver checks
for CONFIG_OMAP34XX we don't need CONFIG_SYS_I2C_OMAP34XX.
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
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>
BeagleBoard X15 revC board is similar to X15 revB1 except
with a SR2.0 where revB1 uses a SR1.1. Add board detection
support for revC.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
board_is*("rev", board_ti_get_rev()) uses strncmp() for
revison detection and assumes it is success if return value
is <= 0. This will fail in case of multiple versions, as
revb will be true for board_is_*revb() and board_is_*reva().
Fix it by looking for exact match of the string.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
K2G ICE evm will have its own dtb. Therefore, add it to the list of dtbs
located in the appended U-boot dtb FIT image. Therefore, when swapping out
dtbs K2G ICE boards can grab the correct one.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Enable CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG to allow "board_name" to
be set depending on the board it is being ran on.
Update findfdt to use this new dynamic board_name value to determine
which dtb should be used.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Certain peripherals used by K2G GP aren't used on K2G ICE evm. Or
configuration is slightly different. Therefore, use board detection to
deal with these variations.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Some code doesn't apply to K2G ICE evm. Therefore, use board detection to
wrap these calls.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add configuration settings used by the K2G ICE evm. Also use board
detection to determine which DDR3 configuration to use.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add basic pinmux data for new K2G ICE evm. Also add pinmuxing for a
generic K2G evm which includes I2C 0 and 1 used for board detection
purposes.
Since multiple K2G boards are supported that means initially generic
pinmuxing should be used when board detection hasn't ran. Once board
detection runs the proper pinmuxing can be reran to match the board
being ran on.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add a function that can be used to determine if the board being ran on is
a K2G Industrial Communication Engine EVM or K2G General Purpose EVM based
on values programmed on the EEPROM.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Different K2G evms may need to program the various
KS2_DDRPHY_DATX8_X_OFFSET registers in different ways. Therefore, use
the mask and val registers for each KS2_DDRPHY_DATAX_X_OFFSET to
properly program the register.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
K2G GP doesn't require the MR2 register to be programed since the
default is good enough. However, newer K2G boards do need to change
this register value. Therefore, instead of not writing this register if
ran on a K2G board just program the value to be written to match the
default/reset value.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Some K2G evms have their EEPROM programming while most do not. Therefore,
add EEPROM board detection to be used as the default method and fall back
to the alternative board detection when needed.
Also reorder board configuration. Perform bare minimal configuration
initially since board detection hasn't ran. Finish board configuration
once the board has been identified.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Now with support for U-boot runtime dtb selection each board needs to
define board_fit_config_name_match so U-boot can determine what the
correct dtb is within the FIT blob.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
For K2G, runtime DTB selection utilizes the embedded_dtb_select function.
Therefore, define the function which will perform a EEPROM read and then
retries selecting the correct dtb now that it can detect which board its
on. For other Keystone devices use an empty function since they will still
use the embedded FIT functionality but their FIT will only contain a single
dtb.
Most production K2G boards do not have their EEPROM programmed. Therefore,
perform a test to verify a K2G GP is currently being used and if it is then
set the values normally set by a EEPROM read.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
When the EEPROM is first read its contents are stored in memory as a
cache to avoid further I2C operations. To determine if the EEPROM was
previously read the easiest way is to check the memory to see if the
EEPROM's magic header value is set. Create a new function that can
determine if the EEPROM was previously read or not without having to
perform a I2C transaction.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
In some situations the EEPROM used for board detection may not be
programmed or simply programmed incorrectly. Therefore, it may be
necessary to "simulate" reading the contents of the EEPROM to set
appropriate variables used in the board detection code.
This may also be helpful in certain boot modes where doing i2c reads
may be costly and the config supports running only a specific board.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Franklin S Cooper Jr. <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The ti816x SoC revision of the ethernet IP block is handled by the
"davinci_emac" driver, rather than the "cpsw" driver as done by later
members of the family. Enable the relevant plumbing.
Signed-off-by: Sriramakrishnan <srk@ti.com>
Signed-off-by: Vitaly Wool <vitaly.wool@konsulko.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
commit 0650798824 ("board: am335x: Introduce scale_vcores")
updated voltages of each board based on efuse. It updated
beagle bone specific voltages under the condition board_is_bone().
But this is true only for BeagleBoneWhite. Due to which voltages
are not configured for BBB, BBW as wrong device is being probed.
So create a common function board_is_beaglebonex() which includes
am335x based beagle family. Use this for updating voltages.
Also remove extra if condition for selecting voltages which is
done later using a switch case and match usb current limit as
before the commit 0650798824.
Fixes: 0650798824 ("board: am335x: Introduce scale_vcores")
Reported-by: Emmanuel Vadot <manu@bidouilliste.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
One can obtain those variables using next commands:
$ fastboot getvar cpu
$ fastboot getvar secure
$ fastboot getvar board_rev
$ fastboot getvar userdata_size
Those variables are needed for fastboot.sh script.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
One can obtain those variables using next commands:
$ fastboot getvar cpu
$ fastboot getvar secure
$ fastboot getvar board_rev
$ fastboot getvar userdata_size
Those variables are needed for fastboot.sh script.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Update the board pinmux for AM572x-evm using latest PMT[1] and the
board files named am572x_gp_evm_A3a_sr2p0 and am572x_gp_evm_A2b_sr1p1
that were autogenerated on 30th January, 2017 by
"Ahmad Rashed <a-rashed@ti.com>" and "Tom Johnson <thjohnson@ti.com>".
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Update the board pinmux for AM571x-IDK board using latest PMT[1] and the
board files named am571x_idk_v1p3b_sr2p0 that were autogenerated on
23rd March, 2017 by "Ahmad Rashed <a-rashed@ti.com>" and
"Tom Johnson <thjohnson@ti.com>".
[1] https://dev.ti.com/pinmux/app.html#/default/
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Update the board pinmux for AM572x-IDK board using latest PMT[1] and the
board files named am572x_idk_v1p3b_sr2p0 that were autogenerated on
30th January, 2017 by "Ahmad Rashed <a-rashed@ti.com>" and
"Tom Johnson <thjohnson@ti.com>".
[1] https://dev.ti.com/pinmux/app.html#/default/
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Refactor OMAP3/4/5 code so that we have only one get_device_type()
function for all platforms.
Details:
- Add ctrl variable for AM33xx and OMAP3 platforms (like it's done for
OMAP4/5), so we can obtain status register in common way
- For now ctrl structure for AM33xx/OMAP3 contains only status register
address
- Run hw_data_init() in order to assign ctrl to proper structure
- Remove DEVICE_MASK and DEVICE_GP definitions as they are not used
(DEVICE_TYPE_MASK and GP_DEVICE are used instead)
- Guard structs in omap_common.h with #ifdefs, because otherwise
including omap_common.h on non-omap4/5 board files breaks compilation
Buildman script was run for all OMAP boards. Result output:
arm: (for 38/616 boards)
all +352.5
bss -1.4
data +3.5
rodata +300.0
spl/u-boot-spl:all +284.7
spl/u-boot-spl:data +2.2
spl/u-boot-spl:rodata +252.0
spl/u-boot-spl:text +30.5
text +50.4
(no errors to report)
Tested on AM57x EVM and BeagleBoard xM.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
[trini: Rework the guards as to not break TI81xx]
Signed-off-by: Tom Rini <trini@konsulko.com>
Add ddr voltage rail (dcdc3) configuration. Set the dcdc3
DDR supply to 1.35V.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Rather than relying on common.h to provide this include, which is going
away at some point, include it explicitly in each file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
- Switch to using <configs/ti_armv7_omap.h> and family. This lets us
drop lots of custom defines.
- Ensure that our default environment uses DEFAULT_LINUX_BOOT_ENV so
that Linux will boot correctly.
- Enable CONFIG_DISTRO_DEFAULTS
- Switch to using CONFIG_OF_CONTROL
- Various other cleanups to match other SoCs in the family line.
Signed-off-by: Tom Rini <trini@konsulko.com>
The ti816x/am389x SoC is the first generation in what U-Boot calls the
"am33xx" family. In the first generation of this family the DDR
initialization sequence is quite different from all of the subsequent
generations. Whereas with ti814x (second generation) we can easily work
the minor differenced between that and am33xx (third generation), our
attempts to do this for ti816x weren't sufficient. Rather than add a
large amount of #ifdef logic to make this different sequence work we add
a new file, ti816x_emif4.c to handle the various required undocumented
register writes and sequence and leverage what we can from
arch/arm/mach-omap2/am33xx/ddr.c still. As DDR2 has similar problems
today but I am unable to test it, we drop the DDR2 defines from the code
rather than imply that it works by leaving it. We also remove a bunch
of other untested code about changing the speed the DDR runs at.
Signed-off-by: Tom Rini <trini@konsulko.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>
- Add #undef CONFIG_DM_MMC_OPS to omap3_logic in the SPL build case, to
match other TI platforms in the same situation.
Signed-off-by: Tom Rini <trini@konsulko.com>
