Add support for board based on the popular Altera Cyclone V SoC.
This board has the following properties:
- 1 GiB of DRAM
- 1 Gigabit ethernet
- 1 USB gadget port
- 1 USB host port with an on-board hub
- 2 QSPI NORs connected to the Cadence QSPI core
- Multiple I2C EEPROMs and one I2C temperature sensor
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Chin Liang See <clsee@altera.com>
---
V2: Update the defconfig as per Tom's request
P2771-0000 is a P3310 CPU board married to a P2597 I/O board. The
combination contains SoC, DRAM, eMMC, SD card slot, HDMI, USB micro-B
port, Ethernet, USB3 host port, SATA, PCIe, and two GPIO expansion
headers.
Currently, due to U-Boot's level of support for Tegra186, the only
features supported by U-Boot are the console UART and the on-board eMMC.
Additional features will be added over time.
U-Boot has so far been tested by replacing the kernel image on the device
with a U-Boot binary. It is anticipated that U-Boot will eventually
replace the CCPLEX bootloader binary, as on previous chips. This hasn't
yet been tested.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This adds the bare minimum code to support Tegra186, with UART and eMMC
working.
The empty gpio.h is required because <asm/gpio.h> includes it. A future
cleanup round may be able to solve this for all Tegra generations at once.
mach-tegra/Makefile is adjusted not to compile anything for Tegra186, but
instead to defer everything to mach-tegra/tegra186/Makefile. This allows
the SoC code to pick-and-choose which of the C files in the "common"
mach-tegra/ directory to compile in based on the SoC's needs. Most of the
code is not valid for Tegra186, and this approach removes the need for
mach-tegra/Makefile to contain many SoC-specific ifdefs. This approach
may be applied to all other Tegra SoCs in a future cleanup round.
board186.c is introduced to replace board.c and board2.c. These files
currently contain a slew of SoC- and board-specific code that is not
valid for Tegra186. This approach avoids adding yet more ifdefs to those
files. A future cleanup round may refactor most of board*.c into board-/
SoC-specific functions files thus allowing the top-level functions like
board_init_early_f to be shared again.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Tegra186's MMC controller needs to be explicitly identified. Add another
compatible value for it.
Tegra186 will use an entirely different clock/reset control mechanism to
existing chips, and will use standard clock/reset APIs rather than the
existing Tegra-specific custom APIs. The driver support for that isn't
ready yet, so simply disable all clock/reset usage if compiling for
Tegra186. This must happen at compile time rather than run-time since the
custom APIs won't even be compiled in on Tegra186. In the long term, the
plan would be to convert the existing custom APIs to standard APIs and get
rid of the ifdefs completely.
The system's main eMMC will work without any clock/reset support, since
the firmware will have already initialized the controller in order to
load U-Boot. Hence the driver is useful even in this apparently crippled
state.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Tegra186's GPIO controller register layout is significantly different from
previous chips, so add a new driver for it. In fact, there are two
different GPIO controllers in Tegra186 that share a similar register
layout, but very different port mapping. This driver covers both.
The DT binding is already present in the Linux kernel (in linux-next via
the Tegra tree so far).
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org> # v1
Signed-off-by: Tom Warren <twarren@nvidia.com>
Future chips will contain different GPIO HW. This change will enable
future SoC support to select the appropriate GPIO driver for their HW,
in a future-looking fashion, using Kconfig.
TEGRA_GPIO is not simply selected by TEGRA_COMMON (even though all
current Tegra chips used this GPIO HW) to simplify the later addition
of support for Tegra SoCs that use different GPIO HW.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
According to the Tegra TRM, GPIOs are aggregated into /ports/ of 8 GPIOs,
not into /banks/. Fix <dt-bindings/gpio/tegra-gpio.h> to correctly reflect
this naming convention. While this seems like silly churn, it will become
slightly more important once we introduce the GPIO binding for upcoming
Tegra chips. This mirrors an identical commit in the Linux kernel.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This reverts commit 56adbb3872.
Since commit 56adbb3872 ("image.h: Tighten up content using handy
CONFIG_IS_ENABLED() macro."), I found my boards fail to boot Linux
because the commit changed the logic of macros it touched. Now,
IMAGE_ENABLE_RAMDISK_HIGH and IMAGE_BOOT_GET_CMDLINE are 0 for all
the boards.
As you can see in include/linux/kconfig.h, CONFIG_IS_ENABLE() (and
IS_ENABLED() as well) can only take a macro that is either defined
as 1 or undefined. This is met for boolean options defined in
Kconfig. On the other hand, CONFIG_SYS_BOOT_RAMDISK_HIGH and
CONFIG_SYS_BOOT_GET_CMDLINE are defined without any value in
arch/*/include/asm/config.h . This kind of clean-up is welcome,
but the options should be moved to Kconfig beforehand.
Moreover, CONFIG_IS_ENABLED(SPL_CRC32_SUPPORT) looks weird.
It should be either CONFIG_IS_ENABLED(CRC32_SUPPORT) or
IS_ENABLED(CONFIG_SPL_CRC32_SUPPORT). But, I see no define for
CONFIG_SPL_CRC32_SUPPORT anywhere. Likewise for the other three.
The logic of IMAGE_OF_BOARD_SETUP and IMAGE_OF_SYSTEM_SETUP were
also changed for SPL. This can be a problem for boards defining
CONFIG_SPL_OF_LIBFDT. I guess it should have been changed to
IS_ENABLED(CONFIG_OF_BOARD_SETUP).
In the first place, if we replace the references in C code,
the macros IMAGE_* will go away.
if (IS_ENABLED(CONFIG_OF_BOARD_SETUP) {
...
}
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.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>
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>
As the old ethernet PHY is not available any more, the x600 board has
been redesigned with the Micrel KSZ9031 PHY. This patch adds support
to autodetect the PHY and configure the Micrel PHY correctly.
Signed-off-by: Stefan Roese <sr@denx.de>
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
In order for CONFIG_IS_ENABLED(FOO) to work we need to move the changes
that CONFIG_FIT_DISABLE_SHA256 makes to be prior to the evaluation by
CONFIG_IS_ENABLED(foo)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
[trini: Move CONFIG_FIT_DISABLE_SHA256 parts to fix build breakage]
Signed-off-by: Tom Rini <trini@konsulko.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>
Populate the right dtb file and console for AM335x-ICEv2 board.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@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>
Re-org env sections so that we can fall back to env is in FAT on SD
card, for broader board compatibility
Signed-off-by: Tom Rini <trini@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
This follows on from commit d98b052 ("powerpc: Cleanup BOOTFLAG_*
references") and commit fc3d297 ("Drop bogus BOOTFLAG_* definitions").
Remove the definitions that have crept in since.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This provides a way to load a FIT containing U-Boot and a selection of device
tree files from a File system. Making sure that all the reads and writes
are aligned to their respective needs.
Tested-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[trini: Make this still apply with Michal's alignment change for 'fit']
Signed-off-by: Tom Rini <trini@konsulko.com>
Updated the CONFIG_SPL_TEXT_BASE to support secure parts (moving
the start address past secure reserved memory and the size of the
security certificate that precedes the boot image on secure devices).
Updated the related CONFIG_SPL_MAX_SIZE to properly reflect the
internal memory actually available on the various device flavors
(Common minimum internal RAM guaranteed for various flavors of
DRA7xx/AM57xx is 512KB).
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>
Updates configs/am43xx_evm.h to use CONFIG options from
SOC specific Kconfig file for various calculations.
On AM43x devices, the address of SPL entry point depends on
the device type, i.e. whether it is secure or non-secure.
Further, for non-secure devices, the SPL entry point is different
between USB HOST boot mode, other "memory" boot modes (MMC, NAND)
and "peripheral" boot modes (UART, USB)
To add to the complexity, on secure devices, in addition to the
above differences, the SPL entry point can change because of the
space occupied by other components (other than u-boot or spl)
that go into a secure boot image.
To prevent the user from having to modify source files every time
any component of the secure image changes, the value of
CONFIG_SPL_TEXT_BASE has been set using a Kconfig option that
is supplied in the am43xx_*_defconfig files
Using the CONFIG options also enables us to do away with some
compile time flags that were used to specify CONFIG_SPL_TEXT_BASE
for different boot modes.
On QSPI devices, the same problem described above occurs w.r.t. the
address of the u-boot entry point in flash, when booting secure
devices. To handle this, CONFIG_SYS_TEXT_BASE is also setup via
a Kconfig option and the defconfig files.
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>
This option is always enabled and is about to be removed. Drop references
to it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andreas Bießmann <andreas@biessmann.org>
It is well past the deadline for conversion to generic board init. Remove
the old code.
Stefan, can you test this please and perhaps send a follow-up patch if needed?
Signed-off-by: Simon Glass <sjg@chromium.org>
Some hardware that is supported by U-Boot can not handle DMA above 32bits.
For these systems, we need to come up with a way to expose the disk interface
in a safe way.
This patch implements EFI specific bounce buffers. For non-EFI cases, this
apparently was no issue so far, since we can just define our environment
variables conveniently.
Signed-off-by: Alexander Graf <agraf@suse.de>
This adds platform code for the Amlogic Meson GXBaby (S905) SoC and a
board definition for ODROID-C2. This initial submission only supports
UART and Ethernet (through the existing Designware driver). DTS files
are the ones submitted to Linux arm-soc for 4.7 [1].
[1] https://patchwork.ozlabs.org/patch/603583/
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that we can expose network functionality to EFI applications,
the logical next step is to load them via pxe to execute them as
well.
This patch adds the necessary bits to the distro script to automatically
load and execute EFI payloads. It identifies the dhcp client as a uEFI
capable PXE client, hoping the server returns a tftp path to a workable
EFI binary that we can then execute.
To enable boards that don't come with a working device tree preloaded,
this patch also adds support to load a device tree from the /dtb directory
on the remote tftp server.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
There are client identifiers specifically reserved for ARM U-Boot
according to http://www.ietf.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#processor-architecture.
So let's actually make use of them rather than the bogus 0x100 that
we emitted so far.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Drop the Xilinx define to 0x100 as it's not the correct value to
use].
Signed-off-by: Tom Rini <trini@konsulko.com>
This code does not currently build with driver model enabled for block
devices. Update it to correct this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexander Graf <agraf@suse.de>
We have a bunch of boards that define their vendor class identifier and
client archs in the board files or in the distro config. Move everything
to the generic Kconfig options.
We're missing the distinction between i386 and x86_64, as I couldn't find
any config variable that would tell us the difference. Is that really important
to people? I guess not, so I left it out.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
We can now successfully boot EFI applications from disk, but users
may want to also run them from a PXE setup.
This patch implements rudimentary network support, allowing a payload
to send and receive network packets.
With this patch, I was able to successfully run grub2 with network
access inside of QEMU's -M xlnx-ep108.
Signed-off-by: Alexander Graf <agraf@suse.de>
This shows a proper progress display and the total amount of data
transferred. Enable it for Raspberry Pi.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
A mailbox is a hardware mechanism for transferring small message and/or
notifications between the CPU on which U-Boot runs and some other device
such as an auxilliary CPU running firmware or a hardware module.
This patch defines a standard API that connects mailbox clients to mailbox
providers (drivers). Initially, DT is the only supported method for
connecting the two.
The DT binding specification (mailbox.txt) was taken from Linux kernel
v4.5's Documentation/devicetree/bindings/mailbox/mailbox.txt.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
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>
This will allow a driver's bind function to use the driver data. One
example is the Tegra186 GPIO driver, which instantiates child devices
for each of its GPIO ports, yet supports two different HW instances each
with a different set of ports, and identified by the udevice_id .data
field.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
The exynos5 platforms use DM in U-Boot and do not use DM in SPL. The serial
driver, serial_s5p.c, is DM-only. This is OK for U-Boot, but in SPL, this
will fail with the following compile error:
drivers/built-in.o: In function `get_current':
...u-boot/drivers/serial/serial.c:387: undefined reference to `default_serial_console'
This warning happens because common/console.c is compiled into U-Boot SPL
if CONFIG_SPL_SERIAL_SUPPORT . The common/console.c invokes serial_*()
functions and since exynos5 does not use DM in SPL, these functions come
from drivers/serial/serial.c . The serial_*() locate default serial port
by calling default_serial_console(), but because the serial_s5p.c is DM-only,
it does no longer define default_serial_console(). Thus the error.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Move CONFIG_SYS_TEXT_BASE to Kconfig, and add default values in board
Kconfig files matching what was present in their config headers. This
will make it cleaner to conditionalise the value for Malta based on 32
vs 64 bit builds.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Make use of device model & device tree to probe the UART driver. This is
the initial step in bringing Malta up to date with driver model, and
allows for cleaner handling of the different I/O addresses for different
system controllers by specifying the ISA bus address instead of a
translated memory address.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
The address of the UART differs based upon the system controller because
it's actually within the I/O port region, which is in a different
location for each system controller. Rather than handling this as 2
UARTs with the correct one selected at runtime, use I/O port accessors
for the UART such that access to it gets translated into the I/O port
region automatically.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
As arm64 has slightly different expectations about load addresses, lets
use a different set of default addresses for things like the kernel.
As arm64 kernels don't come with a decompressor right now, reserve some
more space for really big uncompressed kernels.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The current SPL header, created by the 'mksunxiboot' tool, has size
32 bytes. But the code in the boot ROM stores the information about
the boot media at the offset 0x28 before passing control to the SPL.
For example, when booting from the SD card, the magic number written
by the boot ROM is 0. And when booting from the SPI flash, the magic
number is 3. NAND and eMMC probably have their own special magic
numbers too.
Currently the corrupted byte is a part of one of the instructions in
the reset vectors table:
b reset
ldr pc, _undefined_instruction
ldr pc, _software_interrupt <- Corruption happens here
ldr pc, _prefetch_abort
ldr pc, _data_abort
ldr pc, _not_used
ldr pc, _irq
ldr pc, _fiq
In practice this does not cause any visible problems, but it's still
better to fix it. As a bonus, the reported boot media type can be
later used in the 'spl_boot_device' function, but this is out of
the scope of this patch.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The A80 uses the AXP809 as its primary PMIC.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Adds poweroff support for axp818 pmic.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The AXP818 has a switchable output, SW. This is commonly used for
controlling power to the LCD backlight.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Update several boards to use driver model for video. This involves changes
to the EDP and FIMD (frame buffer) drivers. Existing PWM, simple-panel and
pwm-backlight drivers are used. These work without additional configuration
since they use the device tree settings in the same way as Linux.
Boards converted are:
- snow
- spring
- peach-pit
- peach-pi
All have been tested. Not converted:
- MIPI display driver
- s5pc210_universal
- smdk5420
- smdk5250
- trats
- trats2
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Use 'priv' for a private pointer and 'regs' for a register pointer.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
These are used by peach_pit and peach_pi. Add them so they can be referenced
in the device tree files.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Some boards have the LCD enabled but I cannot test operation for the driver
model conversion. Disable the LCD on these to avoid build errors.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
This file currently requires an LCD. Adjust it to work without one.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
This is used for video signals in some drivers so provide a standard way
of representing it in an enum.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Put the pointer to this structure in struct vidinfo so that we can
reference it without it being global.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Drop these and use parameters instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
We always use device tree with video, so can drop these #ifdefs. Some of the
hardware addresses are not needed either.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Acked-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Add support for Exynos7420 SoC. The Exynos7420 SoC has four Cortex-A57
and four Cortex-A53 CPUs and includes various peripheral controllers.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Add a clock driver for Exynos7420 SoC. There are about 25 clock controller
blocks in Exynos7420 out of which support for topc, top0 and peric1 blocks
are added in this initial version of the driver.
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Add a helper to phy.h to identify whether the
phy is configured for SGMII all variables.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Move the phy_interface_is_rgmii to the phy.h
file for all phy's to be able to use the API.
This now aligns with the Linux kernel based on
commit e463d88c36d42211aa72ed76d32fb8bf37820ef1
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Add the device tree bindings and the accompanying documentation
for the TI DP83867 Giga bit ethernet phy driver.
The original document was from:
[commit 2a10154abcb75ad0d7b6bfea6210ac743ec60897 from the Linux kernel]
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Mugunthan V N <mugunthanvnm@ti.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Add the ability to read the phy-handle node of the
cpsw slave. Upon reading this handle the phy-id
can be stored based on the reg node in the DT.
The phy-handle also needs to be stored and passed
to the phy to access any phy data that is available.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Different TI platforms has to read with different combination to
get the mac address from efuse. So add support to read mac address
based on machine/device compatibles.
The code is taken from Linux drivers/net/ethernet/ti/cpsw-common.c
done by Tony Lindgren.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Since omap's spl doesn't support DM currently, do not define
DM_ETH for spl build.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Provide an api to check whether the given device or machine is
compatible with the given compat string which helps in making
decisions in drivers based on device or machine compatible.
Idea taken from Linux.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
The previous mv88e61xx driver was a driver for configuring the
switch, but did not integrate with the PHY/networking system, so
it could not be used as a PHY by U-boot. This is a complete
rework to support this device as a PHY.
Signed-off-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Acked-by: Prafulla Wadaskar <prafulla@marvell.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Marek Vasut <marex@denx.de>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
No boards are using this driver. Remove in preparation for a new
driver with integrated PHY support.
Signed-off-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Cc: Prafulla Wadaskar <prafulla@marvell.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Cc: Stefan Roese <sr@denx.de>
Cc: Marek Vasut <marex@denx.de>
Add function boot_get_fpga() which find and load bitstream to
programmable logic if fpga entry is present.
Function is supported on Xilinx devices for full and partial bitstreams
in BIN and BIT format.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Remove additional blankline in image.h
Add FIT_FPGA_PROP that user can identify an optional
entry for fpga.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Support RAM and MMC boot mode in SPL also with SPL_FIT images.
In MMC boot mode two boot options are available:
1) Boot flow with ATF(EL3) and full U-Boot(EL2):
aarch64-linux-gnu-objcopy -O binary bl31.elf bl31.bin
mkimage -A arm64 -O linux -T kernel -C none -a 0xfffe5000 -e 0xfffe5000
-d bl31.bin atf.ub
cp spl/boot.bin <sdcard fat partition>
cp atf.ub <sdcard fat partition>
cp u-boot.bin <sdcard fat partition>
2) Boot flow with full U-Boot(EL3):
cp spl/boot.bin <sdcard>
cp u-boot*.img <sdcard>
3) emmc boot mode
dd if=/dev/zero of=sd.img bs=1024 count=1024
parted sd.img mktable msdos
parted sd.img mkpart p fat32 0% 100%
kpartx -a sd.img
mkfs.vfat /dev/mapper/loop0p1
mount /dev/mapper/loop0p1 /mnt/
cp spl/boot.bin /mnt
cp u-boot.img /mnt
cp u-boot.bin /mnt
cp atf.ub /mnt
umount /dev/mapper/loop0p1
kpartx -d sd.img
cp sd.img /tftpboot/
and program it via u-boot
tftpb 10000 sd.img
mmcinfo
mmc write 10000 0 $filesize
mmc rescan
mmc part
ls mmc 0
psu_init() function contains low level SoC setup generated for every HW
design by Xilinx design tools. xil_io.h is only supporting file to fix
all dependencies from tools. The same solution was used on Xilinx Zynq.
The patch also change CONFIG_SYS_INIT_SP_ADDR to the end of OCM which
stays at the same location all the time.
Bootrom expects starting address to be at 0xfffc0000 that's why this
address is SPL_TEXT_BASE.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Add support for the zynqmpimage to mkimage.
Only basic functionality is supported without encryption and register
initialization with one partition which is filled by U-Boot SPL.
For more detail information look at Xilinx ZynqMP TRM.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Call this function before passing control from SPL.
For fpga case it is necessary to enable for example level shifters
when bitstream is programmed.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add support for on board eeprom with programmed MAC for using in u-boot
to have uniq address for every board.
Most of the time uniq MAC address is on a label on the board.
If address is not programmed use these command to program it.
On zcu102:
ZynqMP> mm.b 0
00000000: 00 ? 00
00000001: a0 ? 0a
00000002: 35 ? 35
00000003: 02 ? 02
00000004: 00 ? ef
00000005: 00 ? 67
00000006: 00 ? q
i2c dev 5
i2c write 0 54 20 6
i2c md 54 20
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Since commit ad1ecd2063 ("fdt: Build a U-Boot binary without device
tree"), u-boot-dtb.img is identical to u-boot.img, so SPL can always
load u-boot.img whether CONFIG_OF_SEPARATE is defined or not.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
The board supports following features:
- Boot media support: NAND Flash/SPI Flash
- Support ethernet
- Support USB mass storage
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Reviewed-by: Andreas Bießmann <andreas@biessmann.org>
Currently U-Boot environment address is at offset 0x7fe00 of a 8MB
SPI flash. When creating a partial u-boot.rom image without flash
descriptor and ME firmware, U-Boot actually occupies the last 1MB
of the flash, and reprograming U-Boot causes previous environment
settings get lost which is not convenient during testing.
Adjust the environment address to 0x6ef000 instead (before the MRC
cache data region in the flash).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>