| Commit message (Collapse) | Author | Age | Lines |
|\ |
|
| |
| |
| |
| |
| |
| | |
Add AR933X_PLL_SWITCH_CLOCK_CONTROL_REG define for ar933x chip.
Signed-off-by: Wills Wang <wills.wang@live.com>
|
| |
| |
| |
| |
| |
| | |
Add code to ungate USB and ethernet controller on qca953x
Signed-off-by: Wills Wang <wills.wang@live.com>
|
| |
| |
| |
| |
| |
| |
| | |
This patch enable network function for ap121 board.
Signed-off-by: Wills Wang <wills.wang@live.com>
Acked-by: Marek Vasut <marex@denx.de>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Add a platform prefix for function name in order to make more readable,
and move it into ath79.h
Signed-off-by: Wills Wang <wills.wang@live.com>
Acked-by: Marek Vasut <marex@denx.de>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The various cache maintenance routines perform a number of loops over
cache lines. Rather than duplicate the code for performing such loops,
abstract it out into a new cache_loop macro which performs an arbitrary
number of cache ops on a range of addresses. This reduces duplication in
the existing L1 cache maintenance code & will allow for not adding
further duplication when introducing L2 cache support.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Allow L1 Icache & L1 Dcache line size to be specified separately, since
there's no architectural mandate that they be the same. The
[id]cache_line_size functions are tidied up to take advantage of the
fact that the Kconfig entries are always present to simply check them
for zero rather than needing to #ifdef on their presence.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
[removed CONFIG_SYS_CACHELINE_SIZE in include/configs/pic32mzdask.h]
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Move details of the L1 cache line sizes & total sizes into Kconfig,
defaulting to 0. A new CONFIG_SYS_CACHE_SIZE_AUTO Kconfig entry is
introduced to allow platforms to select auto-detection of cache sizes,
and it defaults to being enabled if none of the cache sizes are set by
the configuration (ie. sizes are all the default 0), and code is
adjusted to #ifdef on that rather than on the definition of the sizes
(which will always be defined even if 0).
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Those wrappers for linker symbols were once used in the MIPS
specific board.c implementation. Since the migration to generic
board.c, those wrappers are dead code and can be removed.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
|
| |
| |
| |
| |
| |
| | |
Add tune Kconfig option for MIPS 34kc.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Provide a default linker script for SPL binaries. Start address
and size of text section and BSS section are configurable. All
sections are arranged in a way that only relevant sections are
kept in the code section for maximum size reduction. All other
sections are kept but moved outside the code section to help
with debugging.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Both real Malta boards & emulators that mimic Malta (eg. QEMU) can
support MIPS64 CPUs. Allow MIPS64 builds of U-Boot for such boards,
which enables the user to make use of the whole 64 bit address space.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use CPHYSADDR to implement the virt_to_phys function for converting from
a virtual to a physical address for MIPS32, much as is already done for
MIPS64. This allows for virt_to_phys to work regardless of whether the
address being translated is in kseg0 or kseg1, unlike the previous
subtraction based approach which only worked for addresses in kseg0.
This allows for drivers to provide an address to virt_to_phys without
needing to manually ensure that kseg1 addresses are converted to
equivalent kseg0 addresses first.
This patch is equivalent to this Linux patch currently waiting to be
reviewed & merged:
https://patchwork.linux-mips.org/patch/12564/
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| | |
So far this is hardcoded to 2, but it should really be read
from the I/O APIC register.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
| |
| |
| |
| |
| |
| |
| | |
Generate quark platform-specific FADT/MADT tables.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This adds basic quark platform ASL files. They are intended to be
included in dsdt.asl of any board that is based on this platform.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is a device.h for quark on-chip devices, mainly for definitions
of internal PCI device numbers, but it's not ready to be included by
ASL files. Update to use hex numbers for PCI dev and __ASSEMBLY__.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The irqroute.asl file is already common enough to all x86 platforms.
Platform ASL files need only provide a irqroute.h to describe how
internal PCI devices and PCIe downstream port devices' INTx pins are
routed to which PIRQ pin.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Move the irqlinks.asl file currently in the BayTrail directory to
a common place to be shared among all x86 platforms. As the PIRQ
routing control programming interface is common to Intel chipsets,
leave the common part in the common file, and move the platform
specific part to the platform files.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For odroid-c2 (arch-meson) for now disable designware eth as meson
now needs to do some harder GPIO work.
Signed-off-by: Tom Rini <trini@konsulko.com>
Conflicts:
lib/efi_loader/efi_disk.c
Modified:
configs/odroid-c2_defconfig
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Enable CONFIG_BLK to move to using driver model for block devices. This
affects MMC booting in SPL, as well as MMC access in U-Boot proper.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This adds a sandbox mailbox implementation (provider), a test client
device, instantiates them both from Sandbox's DT, and adds a DM test
that excercises everything.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org> # v1
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The current reset API implements a method to reset the entire system.
In the near future, I'd like to introduce code that implements the device
tree reset bindings; i.e. the equivalent of the Linux kernel's reset API.
This controls resets to individual HW blocks or external chips with reset
signals. It doesn't make sense to merge the two APIs into one since they
have different semantic purposes. Resolve the naming conflict by renaming
the existing reset API to sysreset instead, so the new reset API can be
called just reset.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
u-boot only recognize okay to enable a node (Linux seems to be more
lenient here). So use okay instead.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add a definition for the gmac interface to the firefly device-tree.
Copied verbatim from the linux kernel.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Simon Glass <sjg@chromium.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add definitions for GRF_SOC_CON1 and GRF_SOC_CON3 which contain various
GMAC related fields.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
Setup the clocks for the gmac ethernet interface. This assumes the mac
clock is fed by an external clock which is common on RK3288 based
devices.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
All the output clock parameters of a DPLL needs to be programmed before
locking the DPLL. But it is being configured after locking the DPLL which
could potentially bypass DPLL. So fixing this sequence.
Reported-by: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since 1e6ad55c0582 ("armv8/cache: Change cache invalidate and flush
function"), this routine can be used for both cache flushing and
cache invalidation. So, it is better to not include "flush" in
this routine name.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
| |
| |
| |
| |
| |
| | |
We should say "clean & invalidate", or simply "flush".
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
__asm_dcache_all can directly return to the caller of
__asm_{flush,invalidate}_dcache_all.
We do not have to waste x16 register here.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: York Sun <york.sun@nxp.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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The CDCE913 and CDCEL913 devices are modular PLL-based, low cost,
high performance , programmable clock synthesizers. They generate
upto 3 output clocks from a single input frequency. Each output can
be programmed for any clock-frequency.
Adding support for the same.
Reviewed-by: Tom Rini <trini@konsulko.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>
|
| |
| |
| |
| |
| |
| |
| | |
Add initial DTS support for AM335x-BBG
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
| |
| |
| |
| |
| |
| |
| | |
Add initial DTS support for AM335x-evm sk.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
binding docs
As per mmc device tree binding documentation card detect gpio has
to be active low signal. When a hardware is designed with active
high card detect, gpio polarity has to be changed with
cd-inverted dt property.
In AM335x the card detect gpio is designed as active low gpio.
So correcting the dt card detect gpio definition.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Allow am335x-bone.dts to be built and enable uart and timer
for all beaglebones.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
| |
| |
| |
| |
| |
| |
| | |
Add initial DTS support for AM437x-IDK evm.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
| |
| |
| |
| |
| |
| |
| | |
Add initial DTS support for AM43-EPOS evm.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Adds an fdt.c file in that defines the ft_cpu_setup() function,
which should be called from a board-specific ft_board_setup()).
This ft_cpu_setup() will currently do nothing for non-secure (GP)
devices but contains pertinent updates for booting on secure (HS)
devices.
Update the omap5 Makefile to include the fdt.c in the build.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Update the CPU string output so that the device
type is now included as part of the CPU string that
is printed as the SPL or u-boot comes up. This update
adds a suffix of the form "-GP" or "-HS" for production
devices, so that general purpose (GP) and high security
(HS) can be distiguished. Applies to all OMAP5 variants.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Updates the SPL build so that when CONFIG_TI_SECURE_DEVICE
is in use (which it should be when building for secure parts),
the TI secure development package is used to create a valid
secure boot image. The u-boot SPL build processes is NOT aware
of the details of creating the boot image - all of that information
is encapsulated in the TI secure development package, which is
available from TI. More info can be found in README.ti-secure
Right now, two image types are generated, MLO and X-LOADER. The types
are important, as certain boot modes implemented by the device's ROM
boot loader require one or the other (they are not equivalent). The
output filenames are u-boot-spl_HS_MLO and u-boot-spl_HS_X-LOADER. The
u-boot-spl_HS_MLO image is also copied to a file named MLO, which is
the name that the device ROM bootloader requires for loading from the
FAT partition of an SD card (same as on non-secure devices).
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Modifies the config.mk to build secure images when building
the SPL for secure devices.
Depending on the boot media, different images are needed
for secure devices. The build generates u-boot*_HS_* files
as appropriate for the different boot modes. The same u-boot
binary file is processed slightly differently to produce a
different boot image, depending on whether the user wants to
boot off SPI, QSPI or other boot media.
Refer to README.ti-secure for more information.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Adds a centralized config_secure.mk in omap-common for
OMAP-style TI secure devices to use for boot image generation
Depending on the boot media, different images are needed for
secure devices. These commands generates u-boot*_HS_* files that
need to be used to boot secure devices.
Please refer to README.ti-secure for more information.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Defines CONFIG_TI_SECURE_DEVICE which needs to be turned on
when building images for secure devices. This flag is used
to invoke the secure image creation tools for creating a
boot image that can be used on secure devices. This flag
may also be used to conditionally compile code specific
to secure devices.
This terminology will be used by all OMAP architecture devices,
hence introducing to a common location.
With the creation of Kconfig for omap-common, moved the
sourcing of the Kconfig files for the omap3/4/5 and am33xx
devices from arch/arm/KConfig to the omap-common one.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Adding support for AM43xx secure devices require the addition
of some SOC specific config options like the amount of memory
used by public ROM and the address of the entry point of u-boot
or SPL, as seen by the ROM code, for the image to be built
correctly.
This mandates the addition of am AM43xx CONFIG option and the
ARM Kconfig file has been modified to source this SOC Kconfig
file. Moving the TARGET_AM43XX_EVM config option to the SOC
KConfig and out of the arch/arm/Kconfig.
Updating defconfigs to add the CONFIG_AM43XX=y statement and
removing the #define CONFIG_AM43XX from the header file.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Adds a new Kconfig file for AM33xx class devices. We
need a common place to define CONFIG parameters
for these SOCs, especially for adding support
for secure devices.
a) Adds a definition for ISW_ENTRY_ADDR. This is the
address to which the ROM branches when the SOC
ROM hands off execution to the boot loader.
CONFIG_SYS_TEXT_BASE and CONFIG_SPL_TEXT_BASE are set
to this value for AM43xx devices.
b) Adds CONFIG_PUB_ROM_DATA_SIZE which is used to
calculate CONFIG_SPL_MAX_SIZE. This value indicates the
amount of memory needed by the ROM to store data during
the boot process.
Currently, these CONFIG options are used only by AM43xx,
but in future other AM33xx class SOCs will also use them.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|