It is not necessary all omap5+ based uses the same PMIC
to poweron mmc. So add support for enabling mmc based on board.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
- Pass MTDPARTS kernel arguments to kernel
- Use Kconfig CONFIG_NAND instead of CONFIG_SYS_EXTRA_OPTIONS="NAND"
- Call 'usb_stop' on kernel start
- Update Falcon mode setup to match other OMAP3 boards
- Use "uEnv.txt" as boot script instead of "boot.scr"
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>
In order to be able to migrate the various SoC EHCI CONFIG options we
first need to finish the switch from CONFIG_USB_EHCI to
CONFIG_USB_EHCI_HCD.
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Now CONFIG_GENERIC_MMC and CONFIG_MMC match for all defconfig.
We do not need two options for the same feature. Deprecate the
former.
This commit was generated with the sed script 's/GENERIC_MMC/MMC/'
and manual fixup of drivers/mmc/Kconfig.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Drop use of this long-deprecated option.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
am335x supports various sysclk frequencies which can be determined
using sysboot pins. PLLs should be configures based on this
sysclk frequency. Add PLL configurations for all supported
frequencies.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
In non DM I2C read operations the address length passed in during a read
operation will be used automatically. However, in DM I2C the address length
is set to a default value of one which causes problems when trying to
perform a read with a differing alen. Therefore, before the first read in a
series of read operations set the alen to the correct value.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reading from the I2C EEPROM used typically requires using an address length
of 2. However, when using DM for I2C the default address length used is 1.
To fix this introduce a new function that allows the address length to be
changed. The logic to do so was copied from cmd/i2c.c.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
One some keystone2 platforms like K2G ICE, there is an option
to switch between 24MHz or 25MHz as sysclk. But the existing
driver assumes it is always 24MHz. Add support for getting
all reference clocks dynamically by reading boot pins.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
K2G supports various sysclk frequencies which can be
determined using sysboot pins. PLLs should be configured
based on this sysclock frequency. Add PLL configurations
for all supported sysclk frequencies.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-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>
A weak version of the function board_usb_init is implemented in:
common/usb.c
drivers/usb/host/xhci-omap.c
To fix the double implementations:
* Convert the board_usb_init function in drivers/usb/host/xhci-omap.c
normal (not weak).
* The function board_usb_init in drivers/usb/host/xhci-omap.c calls to
the weak function omap_xhci_board_usb_init.
* Rename board version of the function board_usb_init to
omap_xhci_board_usb_init.
Done only for boards that defines CONFIG_USB_XHCI_OMAP.
To achieve the same flexibility with the function board_usb_cleanup:
* Add a normal (not weak) implementation of the function
board_usb_cleanup in drivers/usb/host/xhci-omap.c
* The function board_usb_cleanup in drivers/usb/host/xhci-omap.c calls
to the weak function omap_xhci_board_usb_cleanup.
* Rename board version of the function board_usb_cleanup to
omap_xhci_board_usb_cleanup.
Done only for boards that defines CONFIG_USB_XHCI_OMAP.
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Uri Mashiach <uri.mashiach@compulab.co.il>
Acked-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>
As per the DM[1] Dated June 2016–Revised February 2017, Table 5-3,
DRA71 supports the following OPPs for various voltage domains:
VDD_MPU: OPP_NOM
VDD_CORE: OPP_NOM
VDD_GPU: OPP_NOM
VDD_DSPEVE: OPP_NOM, OPP_HIGH
VDD_IVA: OPP_NOM, OPP_HIGH
This patch add support for selection of the above OPPs instead of
using OPP_NOM for all voltage domains.
[1] http://www.ti.com/lit/ds/symlink/dra718.pdf
Reported-by: Vishal Mahaveer <vishalm@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
BeagleBone Blue is next grenation of boards from BeagleBoard.org, focusing
on robotics with a TI wl1835 wireless module for connectivity.
This board can be indentified by the BLAx value after A335BNLT (BBB)
in the at24 eeprom:
BLAx: [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 4c 41 30 |.U3.A335BNLTBLA2|]
http://beagleboard.org/bluehttps://github.com/beagleboard/beaglebone-blue
firmware: https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware
wl18xx mac address: /proc/device-tree/ocp/ethernet@4a100000/slave@4a100200/mac-address
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
CC: Tom Rini <trini@konsulko.com>
CC: Jason Kridner <jkridner@beagleboard.org>
CC: Will Newton <willn@resin.io>
Reviewed-by: Tom Rini <trini@konsulko.com>
SeeedStudio BeagleBone Green Wireless (BBGW) is an expansion of the
SeeedStudio Green (BBG) with the Ethernet replaced by a TI wl1835
wireless module.
This board can be indentified by the GW1x value after A335BNLT (BBB)
in the at24 eeprom:
GW1x [aa 55 33 ee 41 33 33 35 42 4e 4c 54 47 57 31 41 |.U3.A335BNLTGW1A|]
http://beagleboard.org/green-wirelesshttp://wiki.seeed.cc/BeagleBone_Green_Wireless/
firmware: https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware
wl18xx mac address: Stored in at24 eeprom at address 5-16:
hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom | cut -b 5-16
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
CC: Tom Rini <trini@konsulko.com>
CC: Jason Kridner <jkridner@beagleboard.org>
CC: Will Newton <willn@resin.io>
Reviewed-by: Tom Rini <trini@konsulko.com>
BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with
the Ethernet replaced by a TI wl1835 wireless module.
This board can be indentified by the BWAx value after A335BNLT (BBB)
in the at24 eeprom:
BWAx [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 57 41 35 |.U3.A335BNLTBWA5|]
http://beagleboard.org/black-wirelesshttps://github.com/beagleboard/beaglebone-black-wireless
firmware: https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware
wl18xx mac address: /proc/device-tree/ocp/ethernet@4a100000/slave@4a100200/mac-address
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
CC: Tom Rini <trini@konsulko.com>
CC: Jason Kridner <jkridner@beagleboard.org>
CC: Will Newton <willn@resin.io>
Reviewed-by: Tom Rini <trini@konsulko.com>
As per the latest pinmux data available for AM572x EVM,
rev A3, input should be enabled on MMC clock lines for
MMC2/2/3 for stable operation.
Further, AM572x TRM, SPRUHZ6, Revised June 2016, in
section 18.4.6.1.1 "Pad Configuration Registers" states
that input should be enabled for MMC 2/3/4 clock lines.
Enable input on MMC1 and MMC3 clock to match the latest
pinmux data. Input is already enabled on MMC2 clock for
BeagleBoard x15. Further, input is already enabled on all
MMCx clocks for other AM57xx boards (AM572x and AM571x
IDK).
Tested with HS and UHS SD card on AM572x EVM Rev A3.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
By making dram_init_banksize() return an error code we can drop the
wrapper. Adjust this and clean up all implementations.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
PRU ethernet MAC address range is present in the
board EEPROM. Parse it and setup eth?addr
environment variables.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-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>
AM571x IDK and AM572x IDK have optional LCD Kits that can be purchased.
These can be one of OSD101T2045 or the newer OSD101T2587. The LCD panel
itself has no registers that can be used to identify the panel, however,
the touchscreen controllers on the panels are different.
Hence to ease user experience, we can use the touch screen controller's
ID information to detect what kind of panel we use and select the
appropriate kernel dtb for the platform configuration.
NOTE: AM572x IDK default configuration is for LCD Connectivity, however
the AM571x IDK has a jumper (J51) that needs to be mounted for the IDK
to operate with LCD (Vs two PRUSS ethernet port option).
Touchscreen ID information is documented in:
http://www.osddisplays.com/TI/OSD101T2587-53TS_A.1.pdf
Acked-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Use the same convention that was used for ICSS1 Ethernet
- If pin is output, set as PIN_OUTPUT
- If pin is input and external pull resistor present set as PIN_INPUT
- If pin is input and external pull resistor absent, set pull to same
as that of the external PHY's internall pull.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
The board can support either ICSS1 Ethernet ports or LCD
based on J51 jumper. Factory default is ICSS1 Ethernet ports
(i.e. Jumper not populated).
Use the GPIO to detect the jumper setting and configure the
pinmux accordingly. Also select the right DT blob based on
the chosen configuration.
J51 absent -> ICSS1 Ethernet, no LCD on VOUT -> am571x-idk.dtb
J51 present -> LCD on VOUT, no ICSS1 Ethernet -> am571x-idk-lcd-osd.dtb
At present we only support the assume it is the Legacy LCD.
LCD detection mechanism needs to be added later to differentiate
between legacy vs new LCD.
For ICSS1 Ethernet pins use the following convention to set the pinmux
as PMT data is not yet finalized.
- If pin is output, set as PIN_OUTPUT
- If pin is input and external pull resistor present set as PIN_INPUT
- If pin is input and external pull resistor absent, set pull to same
as that of the external PHY's internall pull.
- Do not use SLEW_CONTROLon any pin.
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Keystone and OMAP platforms will need this to set ethernet
MAC addresses from board EEPROM.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Non OMAP platforms i.e. Keystone will also need to use the board
EEPROM helpers so let's make the macro platform independent.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
To keep a consistent MMC device mapping in SPL and in u-boot, let's
register the MMC controllers the same way in u-boot and in the SPL.
In terms of boot time, it doesn't hurt to register more controllers than
needed because the MMC device is initialized only prior being accessed for
the first time.
Having the same device mapping in SPL and u-boot allows us to use the
environment in SPL whatever the MMC boot device.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.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>
These particular SPL options are part of what the ROM provides, but for
compatibility with how we have previously used them, move them to being
implied by the board being selected.
Signed-off-by: Tom Rini <trini@konsulko.com>
serial# variable is used to correctly display device ID in
"fastboot devices". It also can be used further for displaying device ID
in "adb devices" (should be passed as "androidboot.serialno" to kernel
cmdline, via "bootargs" variable).
Serial number generating algorithm is described at [1].
[1] http://lists.denx.de/pipermail/u-boot/2015-March/207462.html
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
This reverts commit 70b26cd057.
This is not a strict revert as it is easier to fix
board/atmark-techno/armadillo-800eva/armadillo-800eva.c to now the
correct name (same value) than to revert that change too.
Signed-off-by: Tom Rini <trini@konsulko.com>
Move all of the status LED feature to drivers/led/Kconfig.
The LED status definitions were moved from the board configuration
files to the defconfig files.
TBD: Move all of the definitions in the include/status_led.h to the
relevant board's defconfig files.
Tested boards: CL-SOM-AM57x, CM-T335
Signed-off-by: Uri Mashiach <uri.mashiach@compulab.co.il>
commit: 65f83802b7 "serial: 16550: Add getfcr accessor"
breaks u-boot commandline working with long commands
sending to the board.
Since the above patch, you have to setup the fcr register.
For board/archs which enable OF_PLATDATA, the new field
fcr in struct ns16550_platdata is not filled with a
default value ...
This leads in not setting up the uarts fifo, which ends
in problems, when you send long commands to u-boots
commandline.
Detected this issue with automated tbot tests on am335x
based shc board.
The error does not popup, if you type commands. You need
to copy&paste a long command to u-boots commandshell
(or send a long command with tbot)
Possible boards/plattforms with problems:
./arch/arm/cpu/arm926ejs/lpc32xx/devices.c
./arch/arm/mach-tegra/board.c
./board/overo/overo.c
./board/quipos/cairo/cairo.c
./board/logicpd/omap3som/omap3logic.c
./board/logicpd/zoom1/zoom1.c
./board/timll/devkit8000/devkit8000.c
./board/lg/sniper/sniper.c
./board/ti/beagle/beagle.c
./drivers/serial/serial_rockchip.c
Signed-off-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Tested-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Before we can sync with the latest mach-types.h file from the Linux
Kernel we need to remove some instances of MACH_TYPE_xxx from our
sources. As these values have been removed from the canonical upstream
source we should not be using them either, so drop.
Cc: Tom Warren <twarren@nvidia.com>
Cc: Lucas Stach <dev@lynxeye.de>
Cc: Luka Perkov <luka@openwrt.org>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Thomas Weber <weber@corscience.de>
Cc: Lucile Quirion <lucile.quirion@savoirfairelinux.com>
Cc: Matthias Weisser <weisserm@arcor.de>
Cc: Suriyan Ramasami <suriyan.r@gmail.com>
Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Cc: Bo Shen <voice.shen@atmel.com>
Cc: Nick Thompson <nick.thompson@gefanuc.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Erik van Luijk <evanluijk@interact.nl>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Initialize EMIF OCP_CONFIG registers REG_COS_COUNT_1, REG_COS_COUNT_2,
and REG_PR_OLD_COUNT field for Beaglebone-Black and am335x-evm. With
the default values LCDC suffers from DMA FIFO underflows and frame
synchronization lost errors. The initialization values are the highest
that work flawlessly when heavy memory load is generated by CPU. 32bpp
colors were used in the test. On BBB the video mode used 110MHz pixel
clock. The mode supported by the panel of am335x-evm uses 30MHz pixel
clock.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The GPIO7 pad mux should be programmed to POWERHOLD value
as per board design. In cases where the PMIC is shut off the
mux is set to GPIO7 mode. So during initialization to be on the
safer side set the mode to POWERHOLD.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The bootrom may corrupt the area of SRAM used to store the ti_common_eeprom
structure. This patch makes sure that it's always read after a reset, even
if a valid MAGIC number is found in the SRAM.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The AM571x Industrial Development Kit (IDK) is a board based on TI's
AM571x SoC which has a single core 1.5GHz Cortex-A15processor. This
board is a development platform for the Industrial Market with:
- 1GB of DDR3L
- Dual 1Gbps Ethernet
- HDMI
- PRU-ICSS
- uSD
- 16GB eMMC
- CAN
- RS-485
- PCIe
- USB3.0
- Video Input Port
- Industrial IO port and expansion connector
The PRU/ICSS will be supported by 3rd party software for EtherCat,
Profibus, and other Industrial protocols.
The link to the data sheet and TRM can be found here:
http://www.ti.com/product/AM5718
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.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
20th October, 2016 by "Steve Kipisz <s-kipisz2@ti.com>" and
"Tom Johnson <thjohnson@ti.com>".
[1] https://dev.ti.com/pinmux/app.html#/default/
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Update the board pinmux for AM572x-IDK board using latest PMT[1] and the
board files named am572x_gp_evm_A3a_sr2p0 that were autogenerated on
19th October, 2016 by "Ahmad Rashed<a-rashed@ti.com>".
[1] https://dev.ti.com/pinmux/app.html#/default/
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Update the timing for RGMII0 interface based on
PCT_DRA75x_DRA74x_SR1.1_v1.3.10 version (Jan 2016). This update
is for SR1.1
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
BeagleBoard-X15 Rev B1 with SR1.1 platform have incompatible changes for HDMI
GPIO requiring new dtb support. This implies we have to properly identify
the platform now as well. Hence provide a different board name for the
Rev B1 variants.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
AM57xx evm Rev A3 with SR2.0 platform have incompatible changes for HDMI
GPIO requiring new dtb support. This implies we have to properly identify
the platform now as well. Hence provide a different board name for the
Rev A3 variations.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add DT support for dra71-evm and built it as part of FIT image.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add the pmic_data for LP873x PMIC which is used to power
up dra71x-evm.
Note: As per the DM[1] DRA71x supports only OP_NOM. So, updating
the efuse registers only to use OPP_NOM irrespective of any
CONFIG_DRA7_<VOLT>_OPP_{NOM,od,high} is defined.
[1] http://www.ti.com/product/DRA718/technicaldocuments
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Rev C version of EVM does require IODelay to be configured for RGMII
pins in MANUAL_1 configuration. Update the same based on PG2.0 initial
simulation values.
Data based on PCT_DRA72x_SR2.0_SR1.0_v1.3.0.7
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add mux and iodelay settings for dra71x-evm.
Data generated using PCT_DRA71x_SR2.0_v1.0.0.0 version (June 2016).
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The dra71x-evm is a board based on TI's DRA718 processor targeting BOM-optimized
entry infotainment systems such as display audio and is a software compatible
derivative of the highly successful DRA74 and DRA72 processor families.
More information can be found here[1].
Add epprom detection for dra71-evm.
[1] http://www.ti.com/product/dra718
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
It can be expected that different paper spins of a SoC can have
different definitions for OPP and can have their own constraints
on the boot up OPP for each voltage rail. In order to have this
flexibility, add support for dynamically selecting the OPP voltage
based on the board to handle any such exceptions.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Populate the corresponding TEE image processing call to be
performed during FIT loadable processing.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Populate the corresponding TEE image processing call to be
performed during FIT loadable processing.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Verification has to be done before booting any images on HS devices. So
default the boot to FIT on HS devices.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Verification has to be done before booting any images on HS devices. So
default the boot to FIT on HS devices.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Verification has to be done before booting any images on HS devices. So
default the boot to FIT on HS devices.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The config option TARGET_K2x_EVM is set by the k2x defconfigs to pick
a board target, but the header configs also set K2x_EVM. This config
is redundant, remove it and use TARGET_K2x_EVM everywhere in its place.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Starting with the changes to fix USB host on am57xx/am43xx we stopped
using usb_otg_ss1/related stuff and but we hadn't been enabling the
relevant options to cause the warnings until just recently.
Fixes: 55efadde7e (ARM: AM57xx: AM43xx: Fix USB host)
Fixes: a48d687c57 (configs: am57xx: Enable download gadget)
Signed-off-by: Tom Rini <trini@konsulko.com>
Detect the board very early and avoid reading eeprom multiple times.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Only a certain set of PLLM/D values are recommended to configure the DDR
at the required speeds for a given clock input frequency. Updating these
values as specified in Data Sheet[1] Table 5-18
[1] http://www.ti.com/lit/ds/symlink/66ak2g02.pdf
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
In most cases, the SPL and u-boot.img will be on the same boot media.
Since the SPL was loaded by the boot rom, the pinmux will already have
been configured for this media. This, the board will still be able to
boot successfully, or at least reach the u-boot console, where more
recovery options are available.
I've encountered this on a beaglebone black with a corrupted EEPROM.
Removing this check allowed the board to boot successfully. I've also
seen this on EVM-based boards with an unprogrammed EEPROM. On those
boards, for some reason there were no UART messages. This made it look
as if the SOC was dead.
Remove the hang(), as it is not a fatal error. Also reformat the error
message to be clearer as to the cause. The original message made it
appear as if the wrong binary was being loaded.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Current logic for query of revision, board_name, config returns
NULL. Users of these functions do a direct strncmp to compare.
Unfortunately, as per conventions require two valid strings to compare
against and the current implementation causes a crash when compared
with NULL.
We'd still like to maintain the simplistic usage of these APIs instead
of redundant if (string) res=strncmp(fn(),"cmp",n); flowing all over
the place.
Hence, since the version, name and config is already pre-initialized
with empty string, just dont check for invalid header in the first
place and return the empty string to the caller.
Reported-by: Brad Griffis <bgriffis@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Correct was'nt -> wasn't typo]
Signed-off-by: Tom Rini <trini@konsulko.com>
config should have been initialized along with others as defaults.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
We should have used TI_DEAD_EEPROM_MAGIC in the first place.
Fixes: d3b98a9eb9 ("ti: common: dra7: Add standard access for board description EEPROM")
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Ethernet ports might be used in the kernel even if CPSW driver
is disabled at u-boot. So always set ethaddr and eth1addr
environment variable from efuse.
Retain usbnet_devaddr as it is required for SPL USB eth boot.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Both ethernet ports can be used as CPSW ethernet (RMII mode)
or PRU ethernet (MII mode) by setting the jumper near the port.
Read the jumper value and set the pinmux, external mux and
PHY clock accordingly.
As jumper line is overridden by PHY RX_DV pin immediately
after bootstrap (power-up/reset), we have to use GPIO edge
detection to capture the jumper line status.
As u-boot doesn't provide any infrastructure for GPIO edge
detection, we directly access the GPIO registers.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
As a standard practice complex definitions should be protected
with parentheses, as it might fail when used in a complex if
statements.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add DTS support for dra72 evm Rev C which has the following
changes
* Two ethernet ports now instead of the single one in rev B.
* DP83867 ethernet phy instead of DP838865.
Cc: Vignesh R <vigneshr@ti.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
When CONFIG_FIT_IMAGE_POST_PROCESS or CONFIG_SPL_FIT_IMAGE_POST_PROCESS
is enabled board_fit_image_post_process will be called, add this
function to am33xx boards when CONFIG_TI_SECURE_DEVICE is set to
verify the loaded image.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Lokesh Vutla <lokeshvutla@ti.com>
EEC is being enabled based on the ddr size populated by SPD data.
But not all keystone platforms have SPD data to detect ddr3 size.
So, enable ECC using the detected DDR size.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Now, arch/${ARCH}/include/asm/errno.h and include/linux/errno.h have
the same content. (both just wrap <asm-generic/errno.h>)
Replace all include directives for <asm/errno.h> with <linux/errno.h>.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
[trini: Fixup include/clk.]
Signed-off-by: Tom Rini <trini@konsulko.com>
Update the README to add support for K2G EVM. Also
- Add steps on how to use MMC boot
- Fix load address when using CCS
- Update build target to u-boot.bin from u-boot-dtb.bin as all ks2
platforms uses DT.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
When beagleboard-X15 is booted, we see the following log:
Unidentified board claims BBRDX15_ in eeprom header
This is because of the missing check for x15 (the default) and reports
an error for a valid board configuration. Fix the same.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Felipe Balbi has move on from TI and the current email ID is no longer
valid. So, replacing with Lokesh.
While at it, update missing config file which was untracked.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
These config targets were added well before the Kconfig migration began
as a way to demonstrate how to make these platforms work with cut down
features. At this point in time they no longer serve a good purpose so
remove them.
Signed-off-by: Tom Rini <trini@konsulko.com>
Modify the SPL build procedure for AM437x high-security (HS) device
variants to create a secure u-boot_HS.img FIT blob that contains U-Boot
and DTB artifacts signed (and optionally encrypted) with a TI-specific
process based on the CONFIG_TI_SECURE_DEVICE config option and the
externally-provided image signing tool.
Also populate the corresponding FIT image post processing call to be
performed during SPL runtime.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Modify the SPL build procedure for AM57xx and DRA7xx high-security (HS)
device variants to create a secure u-boot_HS.img FIT blob that contains
U-Boot and DTB artifacts signed with a TI-specific process based on the
CONFIG_TI_SECURE_DEVICE config option and the externally-provided image
signing tool.
Also populate the corresponding FIT image post processing call to be
performed during SPL runtime.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Align the name of the defconfig file for high-security (HS) device variants
from the AM43xx family of SoCs with the corresponding name used for the
general purpose devices. This allows for easier cross-association of those
files and also provides room to grow from an HS device part number
perspective.
Furthermore, update and cleanup associated MAINTAINERS file.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Madan Srinivas <madans@ti.com>
Not only am335x supports booting from NOR, i.MX6 SoCs also
supports booting from NOR. Make NOR_BOOT a common
option to let different SoCs share it.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Christophe Ricard <christophe-h.ricard@st.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Francois Retief <fgretief@spaceteq.co.za>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
FIT allows for a multiple dtb in a single image. SPL needs away to
detect the right dtb to be used. Adding support for the same for am57xx
platforms.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
board/am57xx supports all boards based on am57xx. Rename the taget
as TARGET_AM57XX_EVM.
Fixes: 74cc8b097d ("board: ti: beagle_x15: Rename to indicate support for TI am57xx evms")
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Currently omap_vcores which holds pmic data is being assigned based
on the SoC type. PMIC is not a part of SoC. It is logical to
to assign omap_vcores based on board type. Hence over ride the
vcores_init function and assign omap_vcores based on the board type.
Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Use a single defconfig for all DRA7xx hs platforms by enabling FIT and delete
the platform specific defconfigs.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
BOOTCFG_RSTMUX8 register controls the reset mux associated with the ARM.
Timer5(dedicated to ARM) when used as WatchDog timer, the events it
generates are routed to the above mux.
Following are the 3 events that can controlled bt the reset mux:
- Device Reset
- An interrupt to the ARM_GIC
- An interrupt to the ARM_GIC followed by a device reset.
Right now to give a default watchdog behaviour "Device reset" is
being selected.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Currently omap_vcores is wrongly assigned a default value of
beagle_x15_volts. Hence populating a new structure for am572x-idk
and assigning it to omap_vcores in the vcores_init function.
Fixes: c020d355c4 ("board: ti: am57xx: Add support for am572x idk in SPL")
Reported-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
The voltage values for each voltage domain at an OPP is identical
across all the SoCs in the DRA7 family. The current code defines
one set of macros for DRA75x/DRA74x SoCs and another set for DRA72x
macros. Consolidate both these sets into a single set.
This is done so as to minimize the number of macros used when voltage
values will be added for other OPPs as well.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Define a set of common macros for the efuse register offsets
(different for each OPP) that are used to get the AVS Class 0
voltage values and ABB configuration values. Assign these
common macros to the register offsets for OPP_NOM by default
for all voltage domains. These common macros can then be
redefined properly to point to the OPP specific efuse register
offset based on the desired OPP to program a specific voltage
domain.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
CONFIG_USB_XHCI_OMAP can be set for host mode without setting
CONFIG_USB_DWC3 which is meant for gadget mode only.
board_usb_init() was not being defined for CONFIG_USB_XHCI_OMAP
resulting in a data abort on usb start.
Define board_usb_init() for CONFIG_USB_XHCI_OMAP case. Move
gadget specific handling to within CONFIG_USB_DWC3.
Fixes: 6f1af1e358 ("board: ti: invoke clock API to enable and disable clocks")
Signed-off-by: Roger Quadros <rogerq@ti.com>
Different AM335x based platforms have different serial consoles. As serial
console is Kconfig option a separate defconfig has to be created for each
platform. So pass the serial device dynamically.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Add minimal dts support for AM335x-ICEv2 board
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
In order to enable cpsw on AM335x ICEv2 board, the following needs to be done:
1)There are few on board jumper settings which gives a choice between
cpsw and PRUSS, that needs to be properly selected[1]. Even after selecting
this, there are few GPIOs which control these muxes that needs to be held high.
2) The clock to PHY is provided by a PLL-based clock synthesizer[2] connected
via I2C. This needs to properly programmed and locked for PHY operation.
And PHY needs to be reset before before being used, which is also held by
a GPIO.
3) RMII mode needs to be selected.
[1] http://www.ti.com/lit/zip/tidr336
[2] http://www.ti.com/lit/ds/symlink/cdce913.pdf
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
AM335x ICEv2 contains a 2Gbit(128Mx16) of DDR3 SDRAM(MT41J128M16JT-125),
capable of running at 400MHz. Adding this specific DDR configuration
details running at 400MHz.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Similar to other TI's AM335x platforms, AM335x ICEv2 also has an
eeprom populated for its unique identification. Adding this info
so that AM335x ICEv2 specific initialization can be done.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Use a single defconfig for all AM335x platforms by enabling FIT
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
FIT allows for a multiple dtb in a single image. SPL needs a way to
detect the right dtb to be used. Adding support for the same.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Use a single defconfig for all AM43xx platforms by enabling FIT and delete
the platform specific defconfigs.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
FIT allows for a multiple dtb in a single image. SPL needs a way to
detect the right dtb to be used. Adding support for the same.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Removing:
uart3_defconfig:
Now uart3 can be selected using menuconfig, removing separate
config for uart mode. Doing uart boot is not straight forward as ROM uses
uart3 as default serial console. In order to boot to prompt, concole in both
u-boot and kernel needs to be changed.
qspiboot_defconfig:
The only advantage of enabling QSPI_BOOT is selecting env in QSPI.
Eventually env needs to be selected by menuconfig so removing
qspiboot_defconfig. qspiboot can be done using dra7xx_evm_defconfig.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Use a single defconfig for all DRA7 platforms by enabling FIT and delete
the platform specific defconfigs.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
FIT allows for a multiple dtb in a single image. SPL needs a way to
detect the right dtb to be used. Adding support for the same.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Adds the board specific ft_board_setup() functions that
are called when CONFIG_OF_BOARD_SETUP is defined. These functions
will currently just call the ft_cpu_setup() function.
Adds CONFIG_OF_BOARD_SETUP to the defconfig files
for dra72_evm, dra74_evm, and am57xx_evm.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Adds code to detect AM43xx HS EVMS - the string in the
I2C EEPROM for HS EVMs differs from GP EVMs. Adds code to
for evm detection, regardless of whether the evm is for
GP or HS parts, and updates board init to use that.
Modifies findfdt command to pick up am437x-gp-evm.dtb for
the HS EVMs also, as the boards are similar except for
some security specific changes around power supply and
enclosure protection.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Since CONFIG_OF_BOARD_SETUP depends on CONFIG_OF_LIBFDT:
config OF_BOARD_SETUP
bool "Set up board-specific details in device tree before boot"
depends on OF_LIBFDT
...
remove superfluous tests of CONFIG_OF_LIBFDT when testing for
CONFIG_OF_BOARD_SETUP.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
[trini: Typo fix: s/ifdefi/ifdef/]
Signed-off-by: Tom Rini <trini@konsulko.com>
ABB should be initialized for all required domains voltage domain
for DRA7: IVA, GPU, EVE in addition to the existing MPU domain. If
we do not do this, kernel configuring just the frequency using the
default boot loader configured voltage can fail on many corner lot
units and has been hard to debug. This specifically is a concern with
DRA7 generation of SoCs since other than VDD_MPU, all other domains
are only permitted to setup the voltages to required OPP only at boot.
Reported-by: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
ABB TX_DONE mask will vary depending on ABB module. For example,
3630 never had ABB on IVA domain, while OMAP5 does use ABB on MM domain,
DRA7 has it on all domains with the exception of CORE, RTC.
Hence, move the txdone mask definition over to structure describing
voltage domain.
Signed-off-by: Nishanth Menon <nm@ti.com>
Not all Keystone2 devices has AEMIF NAND controller. So adding Kconfig
entry for CONFIG_TI_AEMIF and enabling it in respective defconfigs on
platforms with AEMIF controller.
Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The AM572x-IDK board (Industrial Dev Kit) is a board based on TI's AM5728x
SOC which has a dual core 1.5GHz A15 processor. This board is a development
platform for the Industrial market with:
- 2GB of DDR3L
- Dual 1Gbps Ethernet
- HDMI,
- PRU-ICSS
- uSD
- 16GB eMMC
- CAN
- RS-485
- PCIe
- USB3.0
- Video Input Port
- Industrial IO port and expansion connector
The link to the data sheet and TRM can be found here:
http://www.ti.com/product/AM5728
NOTE: DT support is still pending upstream kernel acceptance but we
should be able to get the base system support with this patch.
Signed-off-by: Schuyler Patton <spatton@ti.com>
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Update EMIF data based on recommendations from the now standard TI
EMIF tool version 1.1.1 based on 256MBx16 DDR3L Kingston D2516EC4BXGGB
data sheet
Update T_RRD from 5 to 6 based on AM57xx TRM -
Minimum number of DDR cycles from activate to ativate for a different
bank, minus 1.
Update T_CKESR from 4 to 3 based on AM57xx TRM - Minimum number of DDR
clocks cycles for which SDRAM must remain in self refresh, minus 1.
Signed-off-by: Schuyler Patton <spatton@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
- Move the CONS_INDEX selection out of CONFIG_SYS_EXTRA_OPTIONS and
into Kconfig proper.
- Edit the relevant am57x configs to remove the now unneeded
CONFIG_SYS_EXTRA_OPTIONS.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
init_sata() is done as part of scsi_init() in
arch/arm/cpu/armv7/omap-common/sata.c so no need to duplicate
it here.
This seems to fix SATA problems in the kernel when CONFIG_TI_PIPE3 is
configured as loadable module.
Cc: Cooper Jr., Franklin <fcooper@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Enable the TI DP83867 Giga bit phy on the
dra7 rev c board. The rx and tx internal
delays are need for this board so the usage
of RGMII_ID is required.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The MAC addresses for the PRU Ethernet ports will be available in the
board EEPROM as an address range. Populate those MAC addresses (if valid)
into the u-boot environment so that they can be passed on to the
device tree during fdt_fixup_ethernet().
Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add the pinmux data for rev C evm. This is different from previous
revisions of the platform thanks to the deltas introduced both from
silicon side and from SoC side.
Based on J6EcoES2_EVM_Base_Config-20160309b and PCT-DRA72x-v1.3.0.7 for
SR2.0 silicon.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
DDR configuration has changes from SR1.1 based Rev-A/B version of evm
to the SR2.0 based Rev C of the EVM. Rev C evm now uses the higher
density MT41K512M8RH-125-AAT:E (IT) which is of size 2GB.
Update the DDR configuration based on data from EMIF configuration
tool 1.1.1. NOTE: we use eeprom information (ram_size) to update the
configuration.
Tested-by: Vishal Mahaveer <vishalm@ti.com>
Signed-off-by: Ravi Babu <ravibabu@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
After power cycle of a K2G EVM dhcp fails due to a auto-negotiation
timeout. This commit increases the timeout to fix the issue.
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
After booting has finished, EFI allows firmware to still interact with the OS
using the "runtime services". These callbacks live in a separate address space,
since they are available long after U-Boot has been overwritten by the OS.
This patch adds enough framework for arbitrary code inside of U-Boot to become
a runtime service with the right section attributes set. For now, we don't make
use of it yet though.
We could maybe in the future map U-boot environment variables to EFI variables
here.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
There is no distinction between essential and non-essential mux configuration,
so it doesn't make sense to have an "essential" prefix.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Boards using the TWL6030 regulator may not all use the LDOs the same way.
Some might also not use MMC1 at all, so VMMC would't have to be enabled.
This delegates TWL6030 MMC power initializations to board-specific functions,
that may still call twl6030_power_mmc_init for the default behavior.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
All the mux configurations needs to be done as part of the IODelay
sequence to avoid glitch. Adding all the mux configuration, MANUAL/VIRTUAL
mode configuration as needed for DRA72-evm.
Also update the mux for SD card detect on DRA74-evm.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Updating the memory banks properly so that DT is populated accordingly.
And updating this only after DDR is properly detected by eeprom, so that
git bisect is still maintained.
Acked-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The REVH and later versions of DRA7-evm uses MICRON MT41K512M16HA-125 memory
chips which is of size 4GB(2GB on EMIF1 and 2GB on EMIF2). Add support for the
same.
Acked-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The newer versions of DRA7 boards has EEPROM populated with DDR
size specified in it. Moving DRA7 specific emif related settings
to board files so that emif settings can be identified based on EEPROM.
Acked-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
DRA7 EVM revH and later EVMs have EEPROM populated that can contain board
description information such as name, revision, DDR definition, etc. Adding
support for this EEPROM format.
Acked-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
There are certain EMIF timing failures seen on the some x15 boards. Updating
the EMIF settings to get rid of these timing failures.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
A few boards still use ns16550_platdata structures, but assume the structure
is going to be in a specific order. By explicitly naming each entry,
this should also help 'future-proof' in the event the structure changes.
Tested on the Logic PD Torpedo + Wireless.
I only changed a handful of devices that used the same syntax as the Logic
board. Appologies if I missed one or stepped on toes. Thanks to Derald Woods
and Alexander Graf.
Signed-off-by: Adam Ford <aford173@gmail.com>
V6: Add fix to arch/arm/cpu/armv7/am33xx/board.c
V5: Add fix to arch/arm/cpu/arm926ejs/lpc32xx/devices.c
V4: Fix subject heading
V3: Remove reg_offset out in all the structs. It was reverted out, and and if
it did exist, it would get initialized to 0 by default.
V2: I hastily copy-pasted the boards without looking at the UART number.
This addresses 3 boards that use UART3 and not UART1.
Reviewed-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Because KS2 u-boot works in 32 bit address space the existing ram_size
global data field cannot be used. The maximum, which the get_ram_size()
can detect is 2GB only. The ft_board_setup() needs the actual ddr3 size
to fix up dtb.
This commit introduces the ddr3_get_size() which uses SPD data to
calculate the ddr3 size. This function replaces the "ddr3_size"
environment variable, which was used to get the SODIMM size.
For platforms, which don't have SODIMM with SPD and ddr3 is populated to
a board a simple ddr3_get_size function that returns ddr3 size has to be
implemented. See hardware-k2l.h
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This commit replaces hard-coded EMIF and PHY DDR3 configurations for
predefined SODIMMs to a calculated configuration. The SODIMM parameters
are read from SODIMM's SPD and used to calculated the configuration.
The current commit supports calculation for DDR3 with 1600MHz and 1333MHz
only.
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The maximum device and arm speeds can be determined by reading
EFUSE_BOOTROM register. As there is already a framework for reading this
register, adding support for all possible speeds on k2g devices.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Its not compulsory that speed definition should be same on EFUSE_BOOTROM
register for all keystone 2 devices. So, allow for board specific
speed definitions.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Current AM57xx evm supports both BeagleBoard-X15
(http://beagleboard.org/x15) and AM57xx EVM
(http://www.ti.com/tool/tmdxevm5728).
The AM572x EValuation Module(EVM) provides an affordable platform to
quickly start evaluation of Sitara. ARM Cortex-A15 AM57x Processors
(AM5728, AM5726, AM5718, AM5716) and accelerate development for HMI,
machine vision, networking, medical imaging and many other industrial
applications. This EVM is based on the same BeagleBoard-X15 Chassis
and adds mPCIe, mSATA, LCD, touchscreen, Camera, push button and TI's
wlink8 offering.
Since the EEPROM contents are compatible between the BeagleBoard-X15 and
the AM57xx-evm, we add support for the detection logic to enable
support for various user programmable scripting capability.
NOTE: U-boot configuration is currently a superset of AM57xx evm and
BeagleBoard-X15 and no additional configuration tweaking is needed.
This change also sets up the stage for future support of TI AM57xx EVMs
to the same base bootloader build.
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Now that we have a generic TI eeprom logic which can be reused across
platforms, reuse the same.
This revision also includes fixes identified by Dave Gerlach
<d-gerlach@ti.com>
Cc: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Steven Kipisz <s-kipisz2@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Use the generic EEPROM detection logic instead of duplicating the AM
eeprom logic.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Steven Kipisz <s-kipisz2@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
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>
According to Data Manual(SPRS915P) of AM572x, TI QSPI controller on
DRA74 EVM(rev 1.1+) can support up to 64MHz in MODE-0, whereas MODE-3 is
limited to 48MHz. Hence, switch to MODE-0 for better throughput.
Also, add IODelay parameters for the same.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
remove board_eth_init when CONFIG_DM_ETH is defined
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Correct spelling of "U-Boot" shall be used in all written text
(documentation, comments in source files etc.).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
The WAKEUP_X pins are always an input no matter the pinmux mode.
However, the 18th bit that typical configures a pin as an input is
considered reserved for the WAKEUP_X pins. Therefore, for any WAKEUP
pin remove any configuration that sets that pin as an input. Since
those pins are only inputs remove any output configuration from those
pins.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Unify serial_omap, and use the generic binding.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Simon Glass <sjg@chromium.org>
SeeedStudio BeagleBone Green (BBG) is clone of the BeagleBone Black (BBB) minus
the HDMI port and addition of two Grove connectors (i2c2 and usart2).
This board can be identified by the 1A value after A335BNLT (BBB) in the at24 eeprom:
1A: [aa 55 33 ee 41 33 33 35 42 4e 4c 54 1a 00 00 00 |.U3.A335BNLT....|]
http://beagleboard.org/greenhttp://www.seeedstudio.com/wiki/Beaglebone_green
In Mainline Kernel as of:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79a4e64c679d8a0b1037da174e4aea578c80c4e6
Patch tested on BeagleBone Black (rev C) and BeagleBone Green (production model)
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
CC: Tom Rini <trini@konsulko.com>
CC: Jason Kridner <jkridner@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
BeagleBoard X15 (http://beagleboard.org/x15) support in u-boot does
actually support two different platform configuration offered by
TI. In addition to BeagleBoard X15, it also supports the TMDXEVM5728
(or more commonly known as AM5728-evm).
Information about the TI AM57xx EVM can be found here
http://www.ti.com/tool/tmdxevm5728
The EVM configuration is 1-1 compatible with BeagleBoard X15 with the
additional support for mPCIe, mSATA, LCD, touchscreen, Camera, push
button and TI's wlink8 offering.
Hence, we rename the beagle_x15 directory to am57xx to support TI
EVMs that use the AM57xx processor. By doing this we have common code
reuse. This sets the stage to have a common u-boot image solution for
multiple TI EVMs such as that already done for am335x and am437x. This
sets the stage for upcoming multiple TI EVMs that share the same code
base.
NOTE: Commit eae7ae1853 ("am437x: Add am57xx_evm_defconfig using
CONFIG_DM") introduced DT support for beagle_x15 under am57xx_evm
platform name. However, this ignored the potential confusion arising for
users as a result. To prevent this, existing beagle_x15_defconfig is
renamed as am57xx_evm_nodt_defconfig to denote that this is the "non
device tree" configuration for the same platform. We still retain
am57xx-beagle-x15.dts at this point, since we just require the common
minimum dts.
As a result of this change, users should expect changes in build
procedures('make am57xx_evm_nodt_defconfig' instead of 'make
beagle_x15_defconfig'). Hopefully, this would be a one-time change.
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Signed-off-by: Schuyler Patton <spatton@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Acked-by: Lokesh Vutla <lokeshvutla@ti.com>
On the BeagleBone these i2c1 pins are routed to the expanasion header, where
they can be defined as either pr1_usart0_Xxd/pwm0/spi0/i2c1, dont assume i2c1
Fixes: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/313894/1387696
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Reported-by: Matthijs van Duin <matthijsvanduin@gmail.com>
CC: Tom Rini <trini@konsulko.com>
A few config files have been added without updating MAINTAINERS.
Reported-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Signed-off-by: Tom Rini <trini@konsulko.com>
Currently omap_hsmmc driver doesn't use sdcd pin to detect
whether the card is present or not. Instead the same pin is used
as GPIO to detect card presence. So change the pin mux mode from
mmc0_sdcd to gpio0_6.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add MMC support for k2g
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Add Ethernet support for tftp support
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Phy mode is a board property and it can be different between
multiple board and ports, so it should not be hardcoded in
driver to one specific mode. So adding a field in eth_priv_t
structure to pass phy mode to driver.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Add clock information for Galileo
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Prepare board file so that ethernet registration are
commented for DM conversion
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This introduces omap_die_id_display to display the full die id.
There is no need to store it in an environment variable, that no boot script
is using anyway.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
Now that we have a common prototype to grab the omap die id, functions to figure
out a serial number and usb ethernet address can use it directly.
Those also get an omap_die_id prefix for better consistency.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
This introduces omap5 support for omap_die_id, which matches the common
omap_die_id definition. It replaces board-specific code to grab the die id bits.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
This introduces omap4 support for omap_die_id, which matches the common
omap_die_id definition. It replaces board-specific code to grab the die id bits.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
This replaces the previous get_dieid definition with omap_die_id, that matches
the common omap_die_id definition.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
board_name environment variable was not getting set correctly for Pandaboard A4 and ES
Signed-off-by: David Batzle <dbatzle@dcbcyber.com>
CC: Albert Aribaud <albert.u.boot@aribaud.net>; Tom Rini <trini@ti.com>; Peter Robinson <pbrobinson@gmail.com>
On keystone2 Lamarr and Edison platforms, the PA clocksource
mux in PLL REG1, can be changed only after enabling its clock
domain.
So selecting the output of PASS PLL as input to PA only after
enabling the clockdomain.
This is as per the debug done by "Vitaly Andrianov <vitalya@ti.com>"
and based on the previous work done by "Hao Zhang <hzhang@ti.com>"
Fixes: d634a0775bcf ("ARM: keystone2: Cleanup PLL init code")
Reported-by: Vitaly Andrianov <vitalya@ti.com>
Tested-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested on my TI186x rev E. (PG2.0) and take over maintainership.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Take over maintainership as well. Not tested as PG2.0 (which I have)
needs additional work over PG1.0 (which Matt has).
Cc: Matt Porter <mporter@konsulko.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
invoke enable_usb_clocks during board_usb_init and disable_usb_clocks
during board_usb_exit to enable and disable clocks respectively.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Implemented board_usb_init(), board_usb_cleanup() and
usb_gadget_handle_interrupts() in omap5 board file that
can be invoked by various gadget drivers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Implemented board_usb_init(), board_usb_cleanup() and
usb_gadget_handle_interrupts() in beagle_x15 board file that
can be invoked by various gadget drivers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
vbus_id_status is initialized in board_usb_init. So remove it
while creating dwc3_device objects.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
ARM supported speeds and init value of core_pll for SDP1200
are programmed wrong as part for the device speed cleanups.
Fixing it here.
Thanks to "Vitaly Andrianov <vitalya@ti.com>" for bisecting this issue
Fixes: c37ed9f11b61 ("ARM: keystone2: Fix dev and arm speed detection")
Tested-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
NAND boot mode, ROM expects an image with a gp header in the
beginning and an 8bytes filled with zeros at the end. The same is
true for SD boot on K2G platforms but the file name should be MLO.
Renaming u-boot-nand.gph to MLO, so that same image can be used for
NAND and SD boots. And also not including all the u-boot only images
under CONFIG_SPL_BUILD.
Reported-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
DP83865 ethernet phy used on DRA74x-evm is quirky and the datasheet
provided IODELAY values for standard RGMII phys do not work.
Silicon Revision(SR) 2.0 provides an alternative bit configuration
that allows us to do a "gross adjustment" to launch the data off a
different internal clock edge. Manual IO Delay overrides are still
necessary to fine tune the clock-to-data delays. This is a necessary
workaround for the quirky ethernet Phy we have on the platform.
NOTE: SMA registers are spare "kitchen sink" registers that does
contain bits for other workaround as necessary as well. Hence the
control for the same is introduced in a generic SoC specific, board
generic location.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
