All the Tegra boards borrow the files from board/nvidia/common/
directory, i.e., board/nvidia/common/* are not vendor-common files,
but SoC-common files.
Move NVIDIA common files to arch/arm/mach-tegra/ to clean up
Makefiles.
As arch/arm/mach-tegra/board.c already exists, this commit renames
board/nvidia/common/board.c to arch/arm/mach-tegra/board2.c,
expecting they will be consolidated as a second step.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Tom Warren <twarren@nvidia.com>
Cc: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The secure world code is relocated to the MB just below the top of 4G, we
reserve it in the FDT (by setting CONFIG_ARMV7_SECURE_RESERVE_SIZE) but it is
not protected in h/w.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Tested-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Upstream Linux is broken with default configs when PSCI, thus non-secure
mode is enabled. So the user should explicitly enable this mode, e.g.
when she disabled CONFIG_CPU_IDLE in Linux (in which case it's safe to
use). We can revert this workaround once Linux got fixed.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Make sure to enable the SMMU when booting the kernel in non-secure mode.
This is necessary because some of the SMMU registers are restricted to
TrustZone-secured requestors, hence the kernel wouldn't be able to turn
the SMMU on. At the same time, enable translation for all memory clients
for the same reasons. The kernel will still be able to control SMMU IOVA
translation using the per-SWGROUP enable bits.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
We only set CNTFRQ in arch_timer_init for the boot CPU. But this has to
happen for all cores.
Fixing this resolves problems of KVM with emulating the generic
timer/counter.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Tested-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Tom Warren <twarren@nvidia.com>
These registers can be used to prevent non-secure world from accessing a
megabyte aligned region of RAM, use them to protect the u-boot secure monitor
code.
At first I tried to do this from s_init(), however this inexplicably causes
u-boot's networking (e.g. DHCP) to fail, while networking under Linux was fine.
So instead I have added a new weak arch function protect_secure_section()
called from relocate_secure_section() and reserved the region there. This is
better overall since it defers the reservation until after the sec vs. non-sec
decision (which can be influenced by an envvar) has been made when booting the
os.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
[Jan: tiny style adjustment]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Tested-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This is based on Thierry Reding's work and uses Ian Campell's
preparatory patches. It comes with full support for CPU_ON/OFF PSCI
services. The algorithm used in this version for turning CPUs on and
off was proposed by Peter De Schrijver and Thierry Reding in
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/210881. It
consists of first enabling CPU1..3 via the PMC, just to powergate them
again with the help of the Flow Controller. Once the Flow Controller is
in place, we can leave the PMC alone while processing CPU_ON and CPU_OFF
PSCI requests.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Tegra boards will have to initialize power management for the PSCI
support this way.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Will be used for unpowergating CPUs.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Tested-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Tom Warren <twarren@nvidia.com>
In this case the secure code lives in RAM, and hence the memory node in
the device tree needs to be adjusted. This avoids that the OS will map
and possibly access the reservation.
Add support for setting CONFIG_ARMV7_SECURE_RESERVE_SIZE to carve out
such a region. We only support cutting off memory from the beginning or
the end of a RAM bank as we do not want to increase their number (which
would happen if punching a hole) for simplicity reasons
This will be used in a subsequent patch for Jetson-TK1.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
I will need mc_security_cfg0/1 in a future patch and I added the rest while
debugging, so thought I might as well commit them.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Tested-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Use a per-CPU variable for saving the target PC during CPU_ON
operations. This allows us to run this service independently on targets
that have more than 2 cores and also core-local power control.
CC: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Tested-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This algorithm will be useful on Tegra as well, plus we will need it for
making _psci_target_pc per-CPU.
CC: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Tested-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Tom Warren <twarren@nvidia.com>
_sunxi_cpu_entry can be converted completely into a reusable
psci_cpu_entry. Tegra124 will use it as well.
As with psci_disable_smp, also the enabling is designed to be overloaded
in cased SMP is not controlled via ACTLR.
CC: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Tested-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Move parts of sunxi's psci_cpu_off into psci_cpu_off_common, namely
cache disabling and flushing, clrex and the disabling of SMP for the
dying CPU. These steps are apparently generic for ARMv7 and will be
reused for Tegra124 support.
As the way of disabled SMP is not architectural, though commonly done
via ACLTR, the related function can be overloaded.
CC: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Tested-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Will be required for obtaining the ID of the current CPU in shared PSCI
functions. The default implementation requires a dense ID space and only
supports a single cluster. Therefore, the functions can be overloaded in
cases where these assumptions do not hold.
CC: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Tested-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Tom Warren <twarren@nvidia.com>
CONFIG_ARMV7_VIRT depends on CONFIG_ARMV7_NONSEC, thus doesn't need to
be taken into account additionally. CONFIG_ARMV7_PSCI is only set on
boards that support CONFIG_ARMV7_NONSEC, and it only works on those.
CC: Tang Yuantian <Yuantian.Tang@freescale.com>
CC: York Sun <yorksun@freescale.com>
CC: Steve Rae <srae@broadcom.com>
CC: Andre Przywara <andre.przywara@linaro.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Tested-by: Alison Wang <alison.wang@freescale.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Add full link training as a fallback in case the fast link training
fails.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Connect up the clocks and the eDP driver to make these displays work with
Tegra124-based devices.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Add the various host1x peripherals to allow an eDP display to be connected.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Add functions to provide access to the display clocks on Tegra124 including
setting the clock rate for an EDP display.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Create a function which sets the source clock for a peripheral, given
the number of mux bits to adjust. This can then be used more generally.
For now, don't export it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The get_pll() function can do the wrong thing if passed values that are
out of range. Add checks for this and add a function which can return
a 'simple' PLL. This can be defined by SoCs with their own clocks.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This peripheral is required to get the LCD display running. Add it to
tegra124 and also bring in the binding file from Linux 3.18
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Add required setup for the LCD display, and a function to provide the
board ID. This requires GPIOs to be available prior to relocation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Some LCDs require a PMIC to be set up - add a function for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This is only used by Nvidia boards, so move it into nvidia/common to
simplify things.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
When enabling a PWM, allow the existing clock rate and source to stand
unchanged.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This is needed for tegra124 also, so make it common and add a header file
for tegra124.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Remove board support for afeb9260, tny_a9260, and sbc35_a9g20.
They have not been converted into Generic Board yet.
See doc/README.generic-board for details.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Sergey Lapin <slapin@ossfans.org>
Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
Cc: Andreas Bießmann <andreas.devel@googlemail.com>
By making the board selections optional, every defconfig will include
the board selection when running savedefconfig so if a new board is
added to the top of the list of choices the former top's defconfig will
still be correct.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: Tom Rini <trini@konsulko.com>
This patch adds device tree for the ST Micro stv0991 board & enables
device tree control. Progressively device tree support for the drivers
being used will also be added.
Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add the stm32F4 board's serial ports support.
User can use it easily.
The user only need to edit the number of the usart.
The patch also fix the serial print out.
Last, this version of patch fix the first patch checkpatch.pl error.
Thanks to Kamil Lulko.
Signed-off-by: kunhuahuang <huangkunhua@gmail.com>
Switch to a more standard way of board select; put the SoC select
into arch/arm/Kconfig and move the board select menu under
arch/arm/mach-socfpga/Kconfig.
Also, consolidate SYS_BOARD, SYS_VENDOR, SYS_SOC, SYS_CONFIG_NAME.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Because all the SOCFPGA boards define CONFIG_SPL_FRAMEWORK
(see include/configs/socfpga_common.h), u-boot.img is automatically
added to the target image list by the top Makefile.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The compiler option "-Iboard/$(VENDOR)/$(BOARD)" just exists here
for iocsr_config.c to be able to include iocsr_config.h.
Use "..." instead of <...> to include a header in the same directory.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
By removing this default build target, the "u-boot.kwb" target is not
automatically generated. This fixes a temporary build error when using
out-of-tree builds, as buildman does per default (reported by Simon).
When the full SPL support is added for these targets with the DDR training
code, the "u-boot-spl.kwb" image will be generated automatically.
Users providing a special bin_hdr binary (binary.0) file can always add
this binary file and generate the full firmware image by issuing the
"make u-boot.kwb" command directly.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Prafulla Wadaskar <prafulla@marvell.com>
Cc: Luka Perkov <luka.perkov@sartura.hr>
This patch adds support for the Marvell DB-88F6820-GP Armada A38x
evaluation board.
Supported peripherals are:
- UART
- Ethernet (mvneta)
- I2C
- SPI (including SPI NOR flash)
Please note that this board support right now only supports the
main U-Boot. Without the bin_hdr integration (DDR training etc). This
will be added in a few days / weeks to complete this board port. But
till then this U-Boot version can be run on the target via the
original Marvell U-Boot via this command:
tftpboot 4000000 db-88f6820-gp/u-boot.bin;go 4000000
Signed-off-by: Stefan Roese <sr@denx.de>
Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
This solves some RX problems that have been seen, when using the
mvneta ethernet driver. The cache needs to be reset into a "clean"
state before using it.
Signed-off-by: Stefan Roese <sr@denx.de>
Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
We are not using the coherency feature in U-Boot at all. So lets remove
this configuration from the mbus driver.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
With the introduction of the Armada 38x support, its necessary to change
the mvneta ethernet driver init call from always 4 times to a
configurable value. Lets make this init call more flexible by moving
the actually used devices to the config header.
Additionally this patch takes care of the slightly different base
addresses for the ethernet controllers on A38x.
Signed-off-by: Stefan Roese <sr@denx.de>
Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
This patch adds support for the Marvell Armada 38x SoC family.
Supported peripherals are:
- UART
- Ethernet (mvneta)
- I2C
- SPI (including SPI NOR flash)
Tested on Marvell DB-88F6820-GP evaluation board.
Signed-off-by: Stefan Roese <sr@denx.de>
Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
This way, new MVEBU boards don't need to specifiy the common location
for the SPL linker script.
Signed-off-by: Stefan Roese <sr@denx.de>
Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
This define is used by the DDR training code for Armada XP. With the
upcoming addition of Armada 38x support, lets only define it for
Armada XP in this common header.
Signed-off-by: Stefan Roese <sr@denx.de>
Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
MAX_MVNETA_DEVS is not used anywhere in U-Boot. So lets remove it.
Signed-off-by: Stefan Roese <sr@denx.de>
Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
Since these files will be used for other MVEBU SoC's, lets reflect this
in the headers marcos as well.
Signed-off-by: Stefan Roese <sr@denx.de>
Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
Now that the mach-mvebu directory exists and is used by Armada XP we can
move the mvebu-common files into this directory as well.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
Move arch/arm/include/asm/arch-armada-xp/*
-> arch/arm/mach-mvebu/include/mach/*
Additionally the SYS_SOC is renamed from "armada-xp" to "mvebu". With this
change all these files can better be shared with other, newer Mavell
MVEBU SoC's. Like the upcoming Armada 38x support.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
Move arch/arm/cpu/armv7armada-xp/* -> arch/arm/mach-mvebu/*
Since this platform will be extended to support other Marvell SoC's as
well, lets rename it directly to mvebu.
This will be used by the upcoming Armada 38x suport (A38x).
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
Once we add support for the ohci controller the phy-init and phy-power-on
functions may be called twice (once by the ehci code and once by the ohci
code) protect them against this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The 2/3 usb-phys on the sunxi SoCs are really a single separate functional
block, and are modelled as such in devicetree. So once we've moved all the
sunxi usb code to the driver-model then phy_probe will be called once
for the entire block from the driver-model enumeration code.
Move to this now as this also avoids problems with phy_probe being called
multiple times once we introduce ohci support. This also allows us to get rid
of the sunxi_usb_phy_enabled_count variable as phy_probe now is guaranteed
to be called only once.
Since we're effectively rewriting the probe / remove functions, move them
to the end of the file while we are at it, as that is the most logical place
for them.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The usbc.? files now only contain usb-phy related code, rename them to make
this clear.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Rename the sunxi_usbc_foo functions to sunxi_usb_phy_bar to make it clear
that these are usb-phy functions. Also change the verbs & nouns in the suffix
to match the verbs & nouns used in the Linux kernels generic phy framework.
This patch purely renames things, it contains no functional changes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
This is the only function left in sunxi/usbc.c which is not phy related,
so remove it.
This is a preparation patch for turning the usbc.c code into a proper
usb phy driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The sunxi "usbc" code is mostly about phy setup, but currently also sets up
the host controller clocks, which is something which really belongs in the
host controller drivers, so move it there.
This is a preparation patch for moving the sunxi ehci code to the driver
model and for adding ohci support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Now that all sunxi boards are using driver-model for gpio (*), we can remove
the non driver-model support from the axp gpio code, and the glue to call
into the axp gpio code from the sunxi_gpio non driver-model code.
*) For the regular u-boot build, SPL still uses non driver-model gpio for
now, but the SPL never uses axp gpios support and we were already not building
axp-gpio support for the SPL.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
All sunxi boards now use the driver-model, so remove the non driver-model
code.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Now that we've everything prepared for it remove the DM settings from the
defconfig(s) and simply always set them for sunxi.
This makes all sunxi boards allways use the driver model for gpios and
ethernet, and allows us to move over more bits to the driver-model without
the need to introduce #ifdef-ery for boards which are not yet using DM.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
u-boot has support for a number of boards for which a dts file still needs
to be written, add minimal dts files for these boards so that we can switch
them over to driver-model / fdt.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We need dts files for all boards we support, so bring in a few unmerged ones,
these will be replaced with the upstream merged versions the next time we
sync dts files.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Bring all the sunxi dts files (and update existing ones) from
mripard/sunxi/dt-for-4.1 (which will be merged into upstream master any
day now). This is necessary so that we can move all sunxi boards over to
the driver model.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Modify the sunxi-emac eth driver to support driver model.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Reviewed-by: Stefan Roese <sr@denx.de>
netdev.h should not be included in driver-model enabled builds (doing so
causes compiler warnings about struct eth_driver not being declared), but
we do use sunxi_gmac_initialize in the driver-model case, so move it out of
netdev.h .
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Add driver-model support to the axp_gpio code, note that this needs a small
tweak to the driver-model version of sunxi_name_to_gpio to deal with the
vbus detect and enable pins which are not standard numbered gpios.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Move the axp-gpio code out of the drivers/power/axp*.c code, and into
a new separate axpi-gpio driver.
This change drops supports for the gpio3 pin on the axp209, as that requires
special handling, and no boards are using it.
Besides cleaning things up by moving the code to a separate driver, as
a bonus this change also adds support for the (non vusb) gpio pins on the
axp221 and the gpio pins on the axp152.
The new axp-gpio driver gets its own Kconfig option, and is only enabled
on boards which need it. Besides that it only gets enabled in the regular
u-boot build and not for the SPL as we never need it in the SPL.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Add support for the axp152 and axp209 PMICs to the pmic register access
helpers. This is a preparation patch for moving the axp gpio code to a
separate gpio driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Move the register helpers used to access the registers via p2wi resp.
rsb bus on the otherwise identical axp221 and axp223 pmics to a separate
file, so that they can be used by the upcoming standalone axp gpio driver
too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The driver-model gpio functions may return another value then -1 as error,
make the sunxi usbc properly handle this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Enable full support for the A33 SoC including display, otg-usb, etc.
Signed-off-by: Vishnu Patekar <vishnupatekar0510@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Add support for the new second DRAM PLL found on the A33 SoC.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
This is a preparation patch for adding A33 support, which will have a
mach name of sun8i-a33.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
sun6i and newer (derived) SoCs such as the sun8i-a23, sun8i-a33 and sun9i
have a various things in common, like having separate ahb reset control
registers, the SID living inside the pmic, custom pmic busses, new style
watchdog, etc.
This commit introduces a new hidden SUNXI_GEN_SUN6I Kconfig bool which can be
used to check for these features avoiding the need for an ever growing list
of "#if defined CONFIG_MACH_SUN?I" conditionals as we add support for more
"new style" sunxi SoCs.
Note that this commit changes the behavior of the gmac and hdmi code for
sun8i and the upcoming sun9i devices. This does not matter as sun8i does
not have gmac nor hdmi, and sun9i has new hardware-blocks for these so
the old code will not work there.
Also this is intentional as if a sun8i / sun9i variant which does use the
old hwblocks shows up then the GEN_SUN6I code paths will be the right ones
to use.
For completeness this also adds a SUNXI_GEN_SUN4I bool for A10/A13/A20.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
We do not use irqs in u-boot so remove the unused irq field, and all the
#ifdef-ery around the irq initialization.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
There is no reason not to and this make the #ifdef-ery easier to read.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
This is already invoked a few cycles later in monitor mode by
_secure_monitor (_sunxi_cpu_entry calls _do_nonsec_entry which triggers
_secure_monitor via smc #0). Drop it here, it serves no purpose.
CC: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Tested-by: Ian Campbell <ijc@hellion.org.uk>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The comment line in arch/arm/cpu/armv7/zynq/config.mk says that
the option "-mfpu=neon" is necessary for compiling lowlevel_init.S.
We do not have to give it to all the source files.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Added the SPI driver support for ZynqMP
The controller is same as zynq SPI controller
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Enable the i2c driver for ZynqMP
Also enable the eeprom for read and writes
to eeprom on ZynqMP
ZynqMP uses the same i2c controller as in Zynq
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Fix wrong timer calculation in get_timer_masked incase of
overflow.
This fixes the issue of getting wrong time from get_timer()
calls.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Add support for loading sw for R5 with enabling for zynqmp.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Disable all level shifters before enabling
the PS-to-PL level shifters as it would
be good to disable all level shifters before
enabling the PS-to-PL in order to ensure that
it is in proper state
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
We are about to change the location for ps7_init files, breaking the
current work-flows. It is good time to drop the legacy ps7_init.c/h
support.
Going forward, please use ps7_init_gpl.c/h all the time.
If you are still using old Xilinx tools that are only able to
generate ps7_init.c/h, rename them into ps7_init_gpl.c/h.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
The PicoZed is a System-on-Module board which is marketed as part of
the ZedBoard/MicroZed/etc. collection. It includes a Zynq-7000
processor.
This patch adds support that covers all the variants of the PicoZed
including the SKUs with Z7010/Z7020 and Z7015/Z7030 Zynq chips. This
patch set however only covers support for the System-on-Module and does
not cover any extra components that are available on carrier boards
(except those that are fanned out of the module itself).
More information on this board, its variants and available carrier
boards is available at: http://zedboard.org/product/picozed
Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
