The symbol CONFIG_TI81XX is used for the parts that are common to the
TI816x and TI814x SoCs and are not part of CONFIG_ARCH_OMAP2PLUS nor
CONFIG_AM33XX. It however has so few uses that we can just modify the
code to check for both and drop the symbol. The symbols CONFIG_TI816X
and CONFIG_TI814X are for the repective SoCs.
Signed-off-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>
On this platform, we can trace a general failure to boot to enabling /
disabling this option. When this is enabled, we go off into the
weeds during SPL and are unable to talk with the SD card and
mmc_initialize() fails.
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>
Rather than have a long and if check in the Makefile, mark the default
lowlevel_init function as weak (as we do on armv8) so that SoCs can
override it if needed, and it will still be discarded if unused.
Provide a weak s_init as well to allow for this to link and be
discarded.
Signed-off-by: Tom Rini <trini@konsulko.com>
Any TFTP or DHCP boot on the Davinci OMAP-L138 LCDK board requires
that the 'ethaddr' variable be defined. There are no e-fuses to store
the ethernet mac address for this platform, and neither is a MAC
address reserved in any format. So enable random MAC address support
so that networking boot can be supported.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
We used to have opencoded ehci_readl()/writel() which required no
external functions to be called.
Now with attempt to switch to generic readl()/writel() accessors
we see a missing declaration of those accessors in ehci-ppc4xx.
Something like that happens if applied
http://patchwork.ozlabs.org/patch/726714/:
--------------------------------->8---------------------------
CC drivers/usb/host/ehci-pci.o
In file included from drivers/usb/host/ehci-pci.c:14:0:
drivers/usb/host/ehci-pci.c: In function 'ehci_pci_init':
drivers/usb/host/ehci.h:108:36: warning: implicit declaration of function 'readl' [-Wimplicit-function-declaration]
#define ehci_readl(x) cpu_to_le32(readl(x))
^
drivers/usb/host/ehci.h:23:26: note: in definition of macro 'HC_LENGTH'
#define HC_LENGTH(p) (((p) >> 0) & 0x00ff)
^
include/linux/byteorder/generic.h:89:21: note: in expansion of macro '__cpu_to_le32'
#define cpu_to_le32 __cpu_to_le32
^~~~~~~~~~~~~
drivers/usb/host/ehci-pci.c:33:14: note: in expansion of macro 'ehci_readl'
HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
^~~~~~~~~~
--------------------------------->8---------------------------
This the same fix as we have for "ehci-ppc4xx" in
83cb46c286 "ehci-ppc4xx: Prepare for usage of readl()/writel() accessors".
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Stefan Roese <sr@denx.de>
First of all, it's inappropriate to call setup_internal_uart() in a
generic API fsp_init(), as CONFIG_INTERNAL_UART is an option that
is only available on BayTrail platform. Secondly even for BayTrail,
there is no need to call setup_internal_uart() at all, as Intel FSP
will do this for us.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
It was observed that when -DDEBUG is used to generate a debug build,
U-Boot does not boot on MinnowMax board. A workaround is to disable
CONFIG_DEBUG_UART. The real issue is that in order to have the debug
uart to work, BayTrail SoC needs to be configured so that its internal
uart is available to be used as the debug uart.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present lpe/lpss-sio/scc FSP properties are all boolean, but in
fact for "enable-lpe" it has 3 possible options. This adds macros
for these options and change the property from a boolean type to
an integer type, and change their names to explicitly indicate what
the property is really for.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Introduce various meaningful macros for FSP settings and switch over
to use them instead of magic numbers.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
"serial-debug-port-address" and "serial-debug-port-type" settings
are actually reserved in the FSP UPD data structure. Remove them.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
The default value of "fsp,mrc-init-tseg-size" should be 1 (1MB) per
FSP default settings. 0 is not valid.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that these symbols are in Kconfig, migrate all users. Use imply on
a number of platforms that default to having this enabled. As part of
this we must migrate some straglers for CMD_FAT and DOS_PARTITION.
Signed-off-by: Tom Rini <trini@konsulko.com>
Add fallbacks needed to keep all boards building
while they are migrated to use Kconfig symbols
instead of defines in <board>_config.h files for
FAT filesystem.
These should eventually go away once Kconfig select
or imply statements are put in place and duplicated
defines in <board>_config.h removed.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
[trini: Update logic since CMD_FAT / CONFIG_SPL_FAT_SUPPORT are
selecting FS_FAT]
Signed-off-by: Tom Rini <trini@konsulko.com>
Since config fallbacks contained in include/config_fallbacks.h
come into k2g_evm.h file through ti_armv7_keystone2.h, it should
be the last file included.
Without this, #define of FAT_WRITE when environment is in FAT
does not happen as the environment location is decided later
in the file.
Similar issues can come with other config fallbacks implemented.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Not all TI Keystone2 EVMs want environment in NAND flash.
K2G EVM which has an MMC/SD slot, keep environment in a
FAT partition on SD card.
Since ti_armv7_keystone2.h defines environment is in NAND,
boards which do not follow that have to #undef'ine that
configuration. This leads to ugly ordering issues around
where exactly the include of ti_armv7_keystone2.h can come
in within the k2*_evm.h files.
Move environment location to config file of each board.
This should make it easy to change it for any one board
without affecting all other boards.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add Kconfig symbols for various configurations
supported by FAT filesystem support code.
CONFIG_SUPPORT_VFAT has been left out since its
force enabled in include/fat.h and probably
should get removed at some point.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
[trini: add select FS_FAT for CMD_FAT and SPL_FAT_SUPPORT]
Signed-off-by: Tom Rini <trini@konsulko.com>
On MIPS systems DMA isn't coherent with the CPU caches unless an IOCU is
present. When there is no IOCU we need to writeback or invalidate the
data caches at appropriate points. Perform this cache maintenance in
the pch_gbe driver which is used on the MIPS Boston development board.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Use the virt_to_bus & bus_to_virt functions rather than phys_to_bus &
bus_to_phys, since the addresses accessed by the CPU will be virtual
rather than physical. On MIPS physical & virtual addresses differ as we
use virtual addresses in kseg0, and attempting to use physical addresses
directly caused problems as they're in the user segment which would be
mapped via the uninitialised TLB.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
The loop to set up buffer addresses in rx descriptors always operated on
descriptor 0, rather than on each descriptor sequentially. Fix this in
order to setup correct buffer addresses for each descriptor.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Using the EG20T gigabit ethernet controller on the MIPS Boston board, we
find that we have to reset the controller in order for the RGMII link to
the PHY to become functional. Without doing so we constantly time out in
pch_gbe_mdio_ready.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Dont flush dummy descriptors as they are already
allocated from a region with dcache off. Tested
this on Zynq(zc702) and ZynqMP(zcu102) boards.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Use wait_for_bit to be non breakable as using it with
breakable causes issue of un interruptible auto negotiation.
This is due to the ctrlc pressed will taken for wait_for_bit()
abort during phy_read() and hence not coming out of
auto negotiation.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
The 88E1518 code is programming the wrong registers for rgmii-id,
rgmii-txid and rgmii-rxid interfaces.
Since the PHY defaults to rgmii-id, it would appear that the code
was previously only used with sgmii and rgmii-id interfaces.
Tested on 88E1512 PHY in rgmii-id mode which is from the same family
as 88E1518.
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Checking if dev is NULL after dereferencing it does not make sense.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Abort CPSW driver init when auto-negotiation of link
times out. Currently, the code ignores return status
of phy_startup(), and goes ahead with network operation
(like DHCP) even though the link may be down.
Instead, abort init process if link is down or if there
is another error, so phy_startup() can easily be retried
again. This also helps quick fallback to next network interface
(like USB RNDIS) without inordinate delay.
Tested on AM571x IDK and AM335x BeagleBone black.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>